EHR integration is one of the more consistently underestimated technical challenges in healthcare software. On paper, it’s an API connection problem. In practice, it combines vendor-specific API inconsistencies, strict regulatory compliance requirements, and an ongoing maintenance burden that compounds over time. Teams that approach it with a generic API integration mindset routinely absorb significant unplanned cost during testing and after launch.
This piece covers the architecture decisions that matter — the ones that determine whether an EHR integration platform is maintainable and compliant two years after launch, not just functional at go-live.
The Standards Layer: FHIR, HL7, and Why Both Matter
Healthcare data exchange runs on two dominant standards:
- HL7 v2 — a message-based format developed in the 1980s and still the backbone of hospital data exchange. Most clinical labs, radiology systems, and legacy EHR installations produce HL7 v2 messages for lab results, ADT events (patient admissions, discharges, transfers), and clinical orders.
- FHIR R4 — a modern, REST API-based standard developed by HL7 International and now required by federal regulation for patient-facing data access. Epic, Cerner, and Athenahealth all expose FHIR R4 endpoints. CMS mandates FHIR R4 for Patient Access and Provider Directory APIs.
The practical challenge is that organizations often run both. A large health system might use HL7 v2 feeds for lab results and ADT events while exposing FHIR endpoints for patient-facing applications. A well-designed integration platform needs to handle both — and do so through abstraction layers that decouple the application from the specific message format.
Why Production Behavior Doesn’t Match Documentation
This is the most common source of unplanned cost in EHR integration projects, and it’s almost never surfaced during initial scoping.
EHR vendors publish FHIR implementation guides that describe how their APIs should behave. Production environments at individual health systems frequently diverge from those guides because:
- Health systems configure their EHR deployments extensively — activating or deactivating modules, setting custom extensions, restricting endpoint access
- Vendor implementations of FHIR are profiles of the standard, not the standard itself — Epic’s Patient resource looks different from Athenahealth’s
- Version drift is common — a health system may be running a version of Epic that was released 18 months ago, with different API behavior than the current sandbox
The mitigation is early production access, not extended sandbox testing. Build time for integration testing against the actual target environment, and budget for data mapping work as its own discrete phase.
Compliance Architecture: What HIPAA Requires at the Platform Level
Any platform that transmits, stores, or processes protected health information is subject to HIPAA’s Security Rule. The architecture requirements are specific:
- Encryption in transit and at rest — TLS 1.2 or higher for all data in transit; AES-256 for stored PHI
- Audit logging — immutable logs of every access event involving PHI, with sufficient detail to answer who accessed what data, when, and from where
- Access control — role-based access with minimum necessary data principles enforced at the application layer, not just the database layer
- Business Associate Agreements — signed BAAs required with every third-party service in the data flow, including cloud infrastructure providers, monitoring tools, and any analytics services
The critical design decision is data segregation: PHI and non-PHI data should be separated at the architecture level from the start. Retrofitting data segregation into a system that was built with a unified data model is expensive and error-prone. It’s also a common audit finding when organizations that built quickly in 2020-2021 have undergone formal HIPAA risk assessments.
The Abstraction Layer Problem
EHR vendors push updates on their own schedules. Epic releases three major updates per year. Oracle Health (Cerner) has been consolidating platform versions following its acquisition, with significant API changes in some areas. Athenahealth has been migrating customers across API generations.
Healthcare software that calls EHR APIs directly from application code breaks on vendor updates. The maintenance response — identifying which calls broke, updating them, testing, and redeploying — becomes an emergency every time a vendor pushes a release.
The solution is an abstraction layer between application logic and the EHR API client: a translation service that maps internal data models to vendor-specific formats. When an Epic update changes how a FHIR resource is structured, the fix is isolated to the translation layer rather than distributed across the application codebase. This is the single architecture decision that most reduces long-term maintenance cost in EHR integration work.
When to Build vs. When to Use a Purpose-Built Platform
The build-vs-buy question for EHR integration has a different answer depending on the type of healthcare software being built. Integration platforms like Redox and Rhapsody provide pre-built connectors for major EHR systems, handling some of the vendor-specific translation work.
Integration platforms like Redox and Rhapsody provide pre-built connectors for major EHR systems, handling some of the vendor-specific translation work. They’re appropriate when the integration needs are relatively standard — patient demographics, appointment data, lab results — and when the organization doesn’t have strong healthcare IT engineering expertise in-house.
Custom development makes more sense when the integration requirements are complex (custom clinical workflows, specialty-specific data models), when the data volumes make per-transaction pricing on an integration platform expensive at scale, or when the integration architecture needs to serve as a competitive differentiation rather than a commodity layer.
A purpose-built EHR integration platform developed by a team with production healthcare experience covers the full scope: HL7 and FHIR data mapping, HIPAA-compliant infrastructure design, vendor-specific API handling for Epic, Cerner, and Athenahealth, and the abstraction layers required to stay current as EHR vendors push updates.
Key Takeaways
- Treat EHR integration as an architecture constraint, not an implementation detail — decisions made early determine long-term maintenance cost
- Build abstraction layers between application logic and EHR API clients to isolate vendor update impact
- Separate PHI and non-PHI data at the architecture level from the start
- Budget for production environment testing against actual target EHR deployments, not just sandboxes
- Require signed BAAs with every third-party service in the data flow before PHI is transmitted
