What Security Architecture Does a Custom EHR Actually Need?

$7.42 million. That’s the average cost of a healthcare data breach in 2025 – and healthcare has been the costliest industry for breaches 14 years running. Containment takes 279 days on average – 5 weeks longer than any other sector.

Now add this: HHS is finalizing major updates to the HIPAA Security Rule, targeted for May 2026, that eliminate many “addressable” implementation specs. Controls that were previously flexible are becoming mandatory. MFA for all remote ePHI access. AES-256 encryption at rest with no exceptions. Critical vulnerability remediation within 15 calendar days.

If you’re building a custom EHR, the security conversation isn’t “should we do this.” It’s “can we ship if we don’t?”

I. Why is EHR Security Different from General Application Security?

If you’ve secured a SaaS application or an e-commerce platform, you might think EHR security is the same problem with HIPAA paperwork on top. It’s not. Four things make it fundamentally different:

• PHI classification changes everything. Every data element in an EHR is potentially Protected Health Information. HIPAA’s “minimum necessary” rule means your access controls can’t just be role-based – they need to restrict data to the minimum required for each user’s function. A billing clerk sees billing data. A nurse sees clinical data. A behavioral health therapist sees therapy notes that are segmented under 42 CFR Part 2 from the rest of the record.
• Breach notification is legally mandated. Within 60 days of discovering a breach affecting 500+ individuals, you must notify HHS, affected patients, and prominent media outlets. There’s no “we’ll disclose when we’re ready.” The clock starts at discovery.
• The penalty structure has teeth. Average HIPAA settlement in 2025: $1.2 million. 21 penalties imposed in 2025, up 31% from 2024. And the 2026 rule changes will make more controls mandatory – expanding the surface area for enforcement actions.
• Healthcare takes the longest to detect breaches. 279 days average (IBM, 2025). That’s 9 months of exposed PHI before you even know something’s wrong. Your security architecture needs to prevent breaches AND detect them faster than the industry average.

The 2026 rule change to watch: HHS is eliminating the distinction between “required” and “addressable” implementation specifications under 45 CFR Part 164. What this means in practice: controls like encryption, MFA, and audit logging that organizations could previously skip with documented justification are becoming mandatory with no exception. Estimated finalization: May 2026. Compliance deadline: likely late 2026 or early 2027 (180-day window).

II. What Are the 6 Security Architecture Layers for Custom EHR?

Every custom EHR needs six layers. Skip one, and you’ll find out during a penetration test, an audit, or a breach.

A. Layer 1: Data Layer (Encryption)

• At rest: AES-256 minimum. Database-level encryption. Full-disk encryption on all endpoints. Encrypted backup storage.
• In transit: TLS 1.2+ (TLS 1.3 preferred). All API calls, all data exchange, all internal service communication.
• Key management: AWS KMS, Azure Key Vault, or GCP Cloud KMS. Keys rotated on schedule. Never store encryption keys alongside the data they protect.

Under the 2026 HIPAA Security Rule updates, AES-256 at rest and TLS 1.2+ in transit are no longer “addressable.” They’re mandatory for any system handling ePHI.

B. Layer 2: Access Control

Three mechanisms, layered:

1. RBAC (Role-Based Access Control): Clinician, nurse, admin, billing, patient roles with predefined permissions
2. ABAC (Attribute-Based Access Control): Dynamic policies based on attributes – department, location, time of day, device type
3. SMART on FHIR scopes: For third-party app authorization. Granular scopes define exactly which FHIR resources and operations an app can access.

The 42 CFR Part 2 requirement: Behavioral health and substance use disorder records require separate consent-based access controls. A PCP can’t automatically see therapy notes. The access control architecture must support record segmentation, not just role-based visibility.

C. Layer 3: Authentication

• MFA (Multi-Factor Authentication): Mandatory for all remote ePHI access under 2026 HIPAA updates. Not optional. Not “recommended.”
• OAuth 2.0 + OpenID Connect: For application-level authentication
• SSO (SAML/OIDC): For enterprise clients with existing identity providers
• Session management: Automatic timeout (15-minute inactivity for clinical workstations), re-authentication for sensitive operations

D. Layer 4: Audit and Logging

• Comprehensive logging: Every resource access, every modification, every query. Who accessed what, when, from where, what they did.
• Tamper-proof trails: Logs stored in append-only storage. Cannot be modified or deleted by the application or its administrators.
• Retention: Minimum 6 years (HIPAA requirement). Many organizations retain 7-10 years for legal protection.
• Real-time alerting: Anomaly detection on access patterns. If a user who normally accesses 20 records/day suddenly accesses 2,000, trigger an alert.

Why audit logging matters beyond compliance: It’s your breach detection mechanism. The 279-day average detection time (IBM, 2025) is partly because organizations don’t monitor access patterns in real time. Good audit architecture with anomaly detection can cut that to days.

E. Layer 5: Network Security

• VPC isolation: EHR infrastructure in a private VPC. No public subnets for databases or application servers.
• WAF (Web Application Firewall): Protects API endpoints from injection, XSS, and other OWASP attacks
• DDoS protection: AWS Shield, Cloudflare, or equivalent. Clinical systems can’t go down because of a volumetric attack.
• Network segmentation: Database tier separated from application tier. Each microservice has minimum required network access.
• Zero Trust Architecture: The 2026 HIPAA Security Rule explicitly references ZTA as the expected security model. Verify every request, trust no network segment by default.

F. Layer 6: Application Security

• Input validation: All user input sanitized before processing. FHIR resource validation against profiles.
• OWASP Top 10: Addressed in code review and automated scanning. Injection, broken auth, sensitive data exposure, XML external entities, broken access control, security misconfiguration, XSS, insecure deserialization, component vulnerabilities, insufficient logging.
• Dependency scanning: Automated scanning for known vulnerabilities in third-party libraries. Patch critical CVEs within 15 days (2026 HIPAA requirement).
• Container security: If running in Kubernetes, scan images for vulnerabilities. Enforce pod security policies. No running as root.

III. How Do You Architect HIPAA Compliance for Custom EHR?

HIPAA has three safeguard categories. All three apply to custom EHR.

A. Technical Safeguards (what the system does)

• Access controls with unique user identification
• Emergency access procedures (break-glass with audit trail)
• Automatic logoff (15-minute clinical standard)
• Encryption at rest and in transit (mandatory under 2026 updates)
• Audit controls with comprehensive logging
• Data integrity controls (checksums, validation)
• Transmission security (TLS 1.2+)

B. Administrative Safeguards (what the organization does)

• Security Risk Assessment (annual requirement – not optional)
• Workforce security training
• Information access management policies
• Security incident response procedures
• Contingency/disaster recovery plan
• Business Associate Agreements (BAAs) with every vendor handling PHI

C. Physical Safeguards (where the data lives)

• Facility access controls (for any on-prem components)
• Workstation use policies
• Device and media controls
• For cloud-hosted custom EHR: Cloud provider’s physical security inherits (AWS SOC 2, Azure compliance) – but you still need cloud-specific controls (S3 bucket policies, IAM, encryption configuration)

The BAA chain for a Medplum-based custom EHR:

Your organization -> Mindbowser (BAA) -> Medplum (BAA) -> AWS (BAA)

Each link in the chain needs a signed BAA. If any link is missing, you have a HIPAA gap. We handle this as part of every custom EHR engagement – the BAA chain is established during Phase 1 (Discovery), not Phase 4 (Deployment).

IV. When Do You Need SOC 2 vs HITRUST?

Both are compliance frameworks. They solve different problems.

The 2026 update: Practice administrators must now obtain annual written verification from cloud vendors, including SOC 2 Type II or HITRUST certification reports. This isn’t new guidance – it’s becoming a mandatory verification requirement.

A. Our recommendation for custom EHR builders:

1. Start with SOC 2 Type II. Lower cost ($50K-$150K), faster to achieve (3-6 months), covers most buyer requirements.
2. Pursue HITRUST when selling to large payers or IDNs. They’ll ask for it. It’s the healthcare gold standard.
3. If building on Medplum: Medplum is SOC 2 ready by design and pursuing HITRUST certification in 2026. Your application layer needs its own compliance posture, but the platform handles infrastructure-level controls.

We use PHISecure – our HIPAA-compliant data handling accelerator – on every custom EHR build. It provides the encryption, access control, and audit logging framework so compliance is infrastructure, not a project. For builds on Medplum, PHISecure layers on top of the platform’s baseline to handle edge cases: migration data handling, bulk processing, multi-system integration, and custom audit requirements.

Need the security architecture right from day one? Tell us about your compliance requirements and we’ll scope the security layers alongside the clinical build.

V. What Does Security Testing Look Like for Custom EHR?

Four testing cadences. All are required, not optional.

A. Penetration Testing (Annual + Major Release)

• External pen test by a third-party firm
• Scope: API endpoints, authentication, access controls, FHIR resource authorization, data exposure
• For custom EHR: include SMART on FHIR scope testing – can an app with patient/read scope access data it shouldn’t?

B. HIPAA Security Risk Assessment (Annual)

• Required by HIPAA. Not optional. Not “recommended.”
• Covers: all ePHI-containing systems, risk identification, risk ranking, mitigation plan
• The 2026 rule changes strengthen this: risk assessments must be more thorough and documented

C. Vulnerability Management (Continuous)

• Automated dependency scanning (Dependabot, Snyk, or equivalent)
• Critical CVEs: remediate within 15 calendar days (2026 HIPAA requirement)
• High CVEs: remediate within 30 days
• Medium/low: scheduled patching cycle

D. Third-Party Audits (Annual or Per-Requirement)

• SOC 2 Type II audit (if pursuing certification)
• HITRUST assessment (if pursuing certification)
• Custom security reviews for enterprise clients who require them
• Budget $50K-$150K/year for ongoing security testing and audit costs