Healthcare interoperability standards are more mature than ever. FHIR R4 is widely adopted on paper, HL7 v2 is ubiquitous, and CMS regulations now mandate patient data access. Yet anyone who has tried to build a real integration between two healthcare systems knows the standards tell only part of the story.
The Standards Gap
FHIR (Fast Healthcare Interoperability Resources) was designed to make healthcare data exchange as approachable as modern REST APIs. The vision is compelling: structured, queryable patient data accessible through standardized endpoints that any compliant system can consume. In practice, the gap between specification and implementation is significant.
Every EHR vendor implements FHIR differently. Epic's FHIR API exposes different resource coverage than Cerner's, which differs again from Athena's. The standard defines what resources should look like — it doesn't mandate which resources must be supported, how deeply they must be populated, or how extensions to the standard should be handled. A FHIR-compliant endpoint can return a Patient resource with almost no useful clinical data and still technically conform to the spec.
HL7 v2: The Incumbent That Won't Go Away
While the industry migrates toward FHIR, HL7 v2 remains deeply embedded in healthcare operations. Lab results, ADT (admit/discharge/transfer) notifications, order messages, and radiology reports often still flow as HL7 v2 pipe-delimited messages across VPN tunnels and SFTP drops. Any serious healthcare integration layer needs to handle both.
HL7 v2 has its own conformance challenge: the standard is highly permissive, and vendors exercise significant latitude in how they populate segments and fields. Two systems sending "conformant" HL7 v2 ADT messages may structure patient identifiers, encounter numbers, and provider details in ways that require custom mapping logic for every new source system.
What Actually Works in Practice
The teams that successfully build healthcare integrations tend to share a few approaches:
- Treat each source system as unique. Don't assume that because two EHRs are both "FHIR R4 compliant" they will return data in the same shape. Budget time for per-system mapping and validation.
- Build a canonical data model. Rather than mapping every source system directly to every destination, translate each source into a well-defined internal model. This keeps integration complexity linear rather than combinatorial as you add sources.
- Invest in data quality validation. Healthcare data arrives incomplete, inconsistently coded, and sometimes contradictory. Validation rules that catch anomalies before they propagate downstream are worth the investment.
- Plan for ongoing maintenance. EHR vendors update their APIs, change data structures, and modify authentication requirements. Healthcare integrations are not set-and-forget — they require monitoring and regular maintenance cycles.
- Engage your EHR vendor early. Epic, Cerner, and other major EHR vendors have formal integration programs and support processes. Engaging them early surfaces constraints and requirements that aren't always visible in public documentation.
The Regulatory Tailwind
The 21st Century Cures Act and CMS interoperability rules have meaningfully expanded patient data access rights and mandated FHIR-based APIs for covered entities. This is creating real pressure on EHR vendors to improve their FHIR implementations — and providing legal leverage for organizations that need data access their vendor has historically resisted providing.
The regulatory environment won't solve the technical complexity of healthcare integration, but it is raising the floor on what "FHIR compliant" means in practice. For organizations building integrations today, understanding the regulatory requirements — and your counterparts' compliance obligations — is as important as understanding the technical standards.