HIPAA Security Architecture for Cloud-Native EHRs

Cloud changes the threat model

Traditional on-premise EHRs had a simple security perimeter: the clinic's network. Cloud-native EHRs have no perimeter. Data flows through APIs, is stored in managed databases, and is accessed from anywhere.

This is not inherently less secure. In many ways, cloud infrastructure offers better security primitives than on-premise. But it requires different architectural thinking.

The three pillars of HIPAA technical safeguards

Encryption

HIPAA requires encryption of ePHI at rest and in transit. For cloud-native systems:

In transit: TLS 1.2+ for all API communications. No exceptions. This includes internal service-to-service calls, not just external-facing APIs.

At rest: AES-256 encryption for databases, file storage, and backups. Use your cloud provider's managed encryption with customer-managed keys (CMK) for maximum control.

Application-level encryption: Consider encrypting sensitive fields (SSN, detailed clinical notes) at the application level before they reach the database. This protects against database-level breaches.

Access control

Role-based access control (RBAC) is the minimum. For clinical systems, you often need:

• Attribute-based access control (ABAC): Access decisions based on user role, department, patient relationship, and data sensitivity
• Break-the-glass procedures: Emergency access with mandatory audit documentation
• Minimum necessary standard: Users see only the data they need for their role

Implement access control at the API layer, not just the UI layer. A user who cannot see a field in the interface should not be able to retrieve it via API.

Audit logging

Every access to ePHI must be logged. Every modification must be logged. The log must include:

• Who accessed the data
• When they accessed it
• What data was accessed
• What action was performed
• From what IP/device

Audit logs must be:

• Immutable (write-once storage)
• Retained for 6 years minimum
• Searchable for incident response
• Monitored for anomalous patterns

Architecture decisions that matter

Multi-tenancy isolation

If you serve multiple clinics, tenant isolation is critical. Options:

• Database-per-tenant: Strongest isolation, highest operational cost
• Schema-per-tenant: Good isolation, moderate cost
• Row-level security: Lowest cost, requires careful implementation

Row-level security with PostgreSQL policies is practical for most EHR deployments, but every query must be tested to ensure tenant data cannot leak.

API security

• OAuth 2.0 with short-lived tokens
• Scoped permissions per endpoint
• Rate limiting to prevent abuse
• Request/response logging for audit

Backup and disaster recovery

• Encrypted backups with tested restoration procedures
• Geographic redundancy for business continuity
• Point-in-time recovery capability
• Backup access logging

The BAA chain

Every cloud service that touches ePHI needs a Business Associate Agreement. This includes:

• Cloud provider (AWS, GCP, Azure)
• Database services
• Email services
• Monitoring tools
• Any SaaS that processes patient data

Map your data flow. Every service in the flow needs a BAA.

Risk assessment

HIPAA requires an annual risk assessment. For cloud-native systems, this should include:

• Infrastructure vulnerability scanning
• Application penetration testing
• Access control review
• Incident response plan testing
• Employee security training verification

The standard to hold

Security is not a feature you add after launch. It is an architecture you design from the start. Every shortcut in security becomes technical debt with regulatory consequences.

Frequently Asked Questions

How do AI EHRs prevent hallucinations in clinical workflows?

A well-designed clinical AI should never operate on information it generated itself. Every piece of data it references, lab values, medication lists, diagnosis codes, vital signs, should come from the verified clinical record through FHIR interfaces. The AI synthesizes and drafts based on this data but cannot introduce new clinical facts. The second layer is deterministic rules for high-stakes actions: abnormal results get flagged for physician review before any message is sent, and critical values trigger immediate escalation regardless of what the AI suggests. The third layer is a complete audit trail for every AI-assisted action. Thyra implements all three layers.

How is auditability handled for AI-assisted actions?

Auditability for AI-assisted clinical actions requires logging every decision point: what the AI suggested, the data that informed the suggestion, the clinician's response, and the final action taken. This creates a complete chain of evidence for each interaction. Thyra logs every prioritization and routing decision with "why" signals (which data triggered the recommendation, what confidence level was assigned, who reviewed it, and what the outcome was). These audit trails integrate with existing compliance dashboards and support both internal quality review and regulatory requirements.

What safeguards exist for automated clinical suggestions?

Safeguards for automated clinical suggestions include human-in-the-loop review (clinicians approve any recommendation before it becomes an order or patient instruction), confidence thresholds (low-confidence classifications fall back to manual triage), escalation pathways (red-flag symptoms trigger immediate routing rather than waiting in a general queue), role-based access control, and HIPAA-aligned encryption and access logging. The core principle is that automation should support clinical decision-making without silently practicing medicine.