Most EHR security failures are not exotic. A shared account nobody disabled, a database reachable from a flat internal network, an API that checks login but not whether this user may see this patient, or an audit log that an administrator can quietly edit. Each is an architectural gap, and each is easier to prevent in design than to fix after launch.
This guide sets out a layered EHR security architecture for teams building or modernizing clinical systems: identity, network, application, data and audit. It maps each layer to the HIPAA technical safeguards in 45 CFR 164.312, draws on NIST's zero trust guidance and notes what the ONC certification criteria add for certified health IT.
What is EHR security architecture?
Designing a secure EHR?
Our HIPAA guide for software teams explains the safeguards your architecture needs to meet.
EHR security architecture is the set of design decisions that protect electronic health records across five layers: identity, which proves who each user is; network, which limits what can reach what; application, which decides what each user may do; data, which protects records at rest and in backups; and audit, which records every access.
Layering matters because any single control will fail at some point. A stolen password should still be stopped by multi-factor authentication; a compromised server should still be unable to reach the database directly; and if something gets through, the audit layer should show exactly what happened.
How do the layers of an EHR security architecture fit together?
The layers fit together as a series of checks every request passes through. A clinician signs in through the identity layer, the request crosses network controls to reach the application, the application checks permissions for the specific patient and action, the data layer decrypts only what is allowed, and the audit layer records the event.
- Identity: Unique accounts, multi-factor authentication, single sign-on, session limits and emergency access.
- Network: Segmentation, private connections between services, encrypted transport and no implicit trust by location.
- Application: Authorization on every request, patient-level access rules, API scopes and secure handling of secrets.
- Data: Encryption at rest, key management, protected backups and controlled copies for analytics.
- Audit: Tamper-resistant logs of access and changes, with monitoring and regular review.
Each layer should assume the others may fail. Designing that way avoids the common pattern where strong perimeter controls protect an application that trusts everything inside.
What does HIPAA require at the technical level?
HIPAA's technical safeguards in 45 CFR 164.312 cover five standards: access control, audit controls, integrity, person or entity authentication, and transmission security. Some specifications are required and others are addressable, meaning an organization must implement them where reasonable and appropriate or document why an equivalent alternative is used.
- Access control: Unique user identification and emergency access procedures are required; automatic logoff and encryption and decryption are addressable.
- Audit controls: Mechanisms that record and examine activity in systems containing electronic health information.
- Integrity: Policies and mechanisms that protect information from improper alteration or destruction.
- Authentication: Procedures to verify that a person or entity seeking access is the one claimed.
- Transmission security: Measures against unauthorized access to information sent over networks, with integrity controls and encryption addressable.
Addressable does not mean optional. For a modern cloud-hosted EHR, it is hard to justify not encrypting data at rest and in transit or not logging users off automatically, so treat these as baseline design requirements.
How should the identity layer work?
The identity layer should give every person and system a unique identity, verify it strongly and limit how long a session lasts. Shared logins at nursing stations and service accounts used by several integrations are two of the most common weaknesses in clinical environments.
- Single sign-on: Integration with the organization's identity provider, so accounts are disabled centrally when staff leave.
- Multi-factor authentication: Required for remote access and privileged users, with fast options such as badge tap or push approval for clinicians.
- Session limits: Automatic logoff after inactivity, tuned by location so shared workstations lock faster.
- Emergency access: A break-glass process that grants temporary access with a reason, extra logging and later review.
- Machine identities: Separate credentials for each integration, rotated and limited to the scopes it needs.
Clinician workflow must shape these choices. Security that adds a minute to every login leads to propped-open sessions and shared accounts, so invest in fast authentication methods rather than long timeouts.
Patients and outside users need identity design too. Portal accounts, proxy access for parents and caregivers, and accounts for referring clinicians at other organizations each carry different risks. Verify identity at enrollment, limit proxy access to what the patient has approved, and expire outside accounts when the care relationship ends.
How should the network layer be designed?
The network layer should be designed on zero trust principles. NIST Special Publication 800-207 describes zero trust architecture as an approach in which no implicit trust is granted to users or assets based on their network location, and each access request is evaluated on its own.
In practice this means segmenting the environment so the database accepts connections only from the application services that need it, placing administrative access behind separate authenticated paths, encrypting traffic between internal services as well as at the edge, and exposing only the endpoints that must be public through a gateway with rate limits.
Hospital networks often contain medical devices and legacy systems that cannot be patched quickly. Isolate these in their own segments with tightly defined connections to the EHR, rather than letting them share a network with workstations and servers.
Integrations deserve the same scrutiny. Interface engines, lab connections and partner VPNs often get broad network access because it was easier during setup. Limit each connection to the specific hosts and ports it needs, and review those rules whenever an integration changes or ends.
How should the application layer protect records?
The application layer should check authorization on every request, at the level of the specific patient and action, not just confirm that the user is logged in. Broken object-level authorization, where changing an ID in a request returns another patient's record, is one of the most damaging and common flaws in health APIs.
- Role and context rules: Access based on role, care relationship, location and purpose, enforced in one shared service.
- API scopes: Third-party apps limited to the scopes and patients granted, using SMART on FHIR authorization.
- Sensitive records: Extra protection for categories such as behavioral health or substance use treatment records.
- Secrets handling: Keys and credentials kept in a managed vault, never in code or configuration files.
- Secure development: Code review, dependency scanning and testing for authorization flaws before each release.
Centralize authorization logic. When each feature implements its own checks, gaps appear; a single policy service that every endpoint calls is easier to test, audit and change.
Test authorization as deliberately as features. Automated tests that try to read another patient's data, use an expired token or call an endpoint outside a granted scope catch regressions that manual review misses, and they should run on every build.
How should data be protected at rest and in backups?
Data should be encrypted at rest with keys managed separately from the data, and backups should be protected from deletion or alteration. Ransomware attacks on healthcare often target backups first, so a backup that an attacker with admin access can delete offers little protection.
Use a managed key service with access policies and rotation, encrypt databases, file storage and backups, and keep at least one backup copy that is immutable or held in a separate account. Test restores regularly, since an untested backup is a guess.
Copies of data for analytics, testing and machine learning are a frequent source of exposure. Use de-identified or synthetic data outside production where possible, and apply the same controls to any identifiable copy as to the primary record.
Plan recovery as part of the architecture. Define how quickly the EHR must be back after an outage and how much data the organization can afford to lose, then design replication, backups and runbooks to meet those targets and rehearse them.
How should audit logging work?
Audit logging should record who accessed or changed which record, when, from where and through which application, and the logs should be protected from alteration. HIPAA requires audit controls, and the ONC criterion in 45 CFR 170.315(d)(2) expects certified systems to record auditable events, prevent the log from being changed and detect any alteration.
- Coverage: Views, creates, updates, deletes, exports, prints and permission changes, including actions through APIs.
- Tamper resistance: Logs written to separate storage the application cannot modify, with integrity checks.
- Monitoring: Alerts for patterns such as access to many records in a short period or access to a colleague's chart.
- Review: Regular, documented reviews, with a process for investigating and responding to findings.
Logs are useful only if someone looks at them, and in a busy health system no one can read them all by hand. Automated monitoring with clear escalation turns audit data into a working control rather than an archive consulted after a breach.
What do ONC certification criteria add?
For certified health IT, the ONC criteria in 45 CFR 170.315(d) add specific privacy and security functions on top of HIPAA's general standards. They include authentication, access control and authorization in (d)(1), auditable events and tamper resistance in (d)(2), automatic access time-out in (d)(5) and end-user device encryption in (d)(7).
The criteria also include attestations on encrypting stored authentication credentials in (d)(12) and on multi-factor authentication in (d)(13). Even teams not seeking certification can use the criteria as a practical checklist, since hospitals evaluating vendors often ask about them.
How Agnotic can help
Agnotic Technologies designs and builds EHR platforms and health APIs with security in each layer: identity integration and break-glass access, segmented cloud networks, centralized authorization, managed encryption and protected backups, and tamper-resistant audit logging with monitoring.
We also review existing systems against HIPAA technical safeguards and ONC criteria, and fix the gaps in order of risk, starting with the issues an attacker would find first.
Build security into your EHR
Read our HIPAA guide for software teams, or explore more EHR integration articles.
Related reading on Agnotic
See healthcare data security, the HIPAA API safeguards guide, best practices for healthcare security and the EHR tech stack.
