Ingress/Case Studies/Healthcare HIPAA Cloud

HIPAA-compliant cloud migration for a 12-hospital health system.

Three separate EHRs, a legacy data warehouse, and HIPAA risk findings from a prior OCR investigation. We unified the clinical data environment, documented every PHI flow, and passed the follow-up federal review.

Healthcare and Life Sciences Cloud Transformation HIPAA Compliant HL7 FHIR R4
Compliance posture
HIPAA ยท HL7 FHIR R4
PHI boundary enforced at every layer
AI delivery
Clinical-grade
Otonmi, PHI inside boundary
3
EHRs Integrated via FHIR
28%
Clinical Documentation Time Reduction
0
PHI Incidents Post-Migration
Engagement Overview

Three EHRs, a legacy warehouse, and an open OCR finding.

A 12-hospital regional health system was operating clinical and operational data across three separate EHR platforms, a legacy on-premises data warehouse, and two third-party analytics vendors. Patient data was moving between these systems through unsecured integration patterns, including unencrypted sFTP transfers that had been flagged in a HIPAA risk assessment.

The health system had been the subject of a prior HHS Office for Civil Rights investigation and had signed a resolution agreement requiring remediation of specific technical safeguard deficiencies within an 18-month window. The OCR follow-up review was scheduled. The migration and integration work was not optional.

Engagement snapshot
Client type12-hospital regional health system
Compliance driverHIPAA resolution agreement, OCR review
Cloud platformAWS (HIPAA-eligible services)
Integration standardHL7 FHIR R4
EHRs integrated3 (Epic, Cerner, Meditech)
AI layerOtonmi (inside PHI boundary)
The Challenge

Unsecured PHI flows and a federal review deadline.

The OCR resolution agreement identified three specific deficiencies: inadequate technical access controls on PHI systems, insufficient audit logging of PHI access, and unencrypted PHI in transit between systems. Each had a remediation requirement with a deadline. Non-compliance at the follow-up review would trigger escalated enforcement.

Simultaneously, the clinical informatics team had an initiative to deploy AI-assisted documentation to reduce physician administrative burden, a priority for retention and burnout reasons. But deploying AI that touched PHI required the secure foundation to be in place first. The two workstreams were sequentially dependent, compressing the effective timeline for the AI work.

  • Three separate EHR platforms with inconsistent patient identifiers and no unified patient record, causing duplicate records and care coordination gaps.
  • Unencrypted PHI in transit flagged by OCR, transmitted via legacy sFTP integrations between EHRs and the analytics environment.
  • Insufficient audit logging to demonstrate who accessed PHI records and when, a specific OCR resolution agreement requirement.
  • AI deployment blocked until the compliant foundation was in place, compressing the timeline for the clinical documentation use case.
The Work

Secure the boundary, then build inside it.

The sequencing was deliberate: establish the HIPAA-compliant cloud foundation, replace every insecure integration pattern, then layer the clinical data platform and AI capabilities on top. No PHI touched the new environment until the boundary was complete and verified.

01.
HIPAA-compliant cloud foundation
AWS HIPAA-eligible services architecture: VPC with private subnets for all PHI workloads, encryption at rest (AES-256) and in transit (TLS 1.2+ enforced), CloudTrail and AWS Audit Manager for comprehensive PHI access logging, and GuardDuty for threat detection. Business Associate Agreement executed with AWS.
AWS HIPAAEncryptionAudit logging
โ†’
02.
HL7 FHIR R4 integration layer
All three EHR systems (Epic, Cerner, Meditech) integrated via HL7 FHIR R4 APIs, replacing the legacy sFTP transfers entirely. AWS HealthLake used as the FHIR data store. Patient identity matching resolved using probabilistic matching across the three systems, reducing duplicate patient records by 94%.
HL7 FHIR R4AWS HealthLakeEpic, Cerner
โ†’
03.
Clinical data repository and analytics
Unified clinical data repository built on the FHIR data store, enabling cross-EHR patient views, population health analytics, and operational dashboards for care coordination teams. All analytics queries executed inside the PHI boundary with no PHI moving to external analytics environments.
Clinical CDRPopulation health
โ†’
04.
AI clinical documentation via Otonmi
Otonmi AI clinical documentation assistant deployed inside the PHI boundary, with no PHI egressing to external model APIs. The system reads structured FHIR data from the CDR to pre-populate note templates, reducing the time physicians spend on documentation after patient encounters. Deployed to 340 physicians across six facilities in the pilot cohort.
Otonmi AIPHI boundaryClinical NLP
โ†’
Results

OCR review passed. Zero PHI incidents.

All three HIPAA resolution agreement deficiencies were remediated and documented before the OCR follow-up review. The health system passed the review without findings. The OCR investigator specifically noted the completeness of the PHI access audit trail as meeting the resolution agreement requirements in full.

All three EHRs are now integrated via FHIR R4, with duplicate patient records reduced 94% through identity matching. Clinical documentation time for physicians in the Otonmi pilot cohort dropped 28%, a result the Chief Medical Officer cited in a retention context with the medical staff committee. Zero PHI incidents have occurred in the post-migration environment.

OCR follow-up review passed without findings

All three HIPAA resolution agreement deficiencies remediated. PHI access audit trail cited by OCR investigator as fully compliant.

Three EHRs integrated via HL7 FHIR R4

Legacy sFTP transfers fully replaced. Unencrypted PHI in transit eliminated. Patient duplicate records reduced 94%.

28% reduction in clinical documentation time

For the 340-physician Otonmi pilot cohort, post-encounter documentation time reduced 28%. Cited by CMO in physician retention context.

Zero PHI incidents post-migration

No unauthorized access, no PHI in transit violations, no audit logging gaps since migration completion.

Stack and Frameworks

What we built with.

Cloud and security

AWS HIPAA-eligible.

VPC with PHI boundary controls, encryption at rest and in transit, CloudTrail, AWS Audit Manager, GuardDuty. BAA executed. Private subnets for all PHI workloads.

AWS HealthLakeCloudTrailGuardDuty
Integration

HL7 FHIR R4 pipelines.

FHIR R4 APIs for Epic, Cerner, and Meditech. AWS HealthLake as the FHIR data store. Probabilistic patient identity matching across all three systems.

HL7 FHIR R4AWS HealthLakeEpic ยท Cerner ยท Meditech
AI

Otonmi clinical AI.

Clinical documentation assistant operating entirely inside the PHI boundary. Reads FHIR-structured patient data to pre-populate note templates. No PHI egresses to external model endpoints.

OtonmiClinical NLPPHI boundary
Related

More from this practice.

Start a conversation

Working through a HIPAA cloud challenge?

// 30 minutes to a written brief.

Bring the compliance requirement or platform challenge. We return with a written approach covering PHI boundary design, integration architecture, and a realistic timeline.

Emailconnect@ingressits.com
GSA MAS#47QTCA26D000K
Reply< 24 hrs