Interoperability in Healthcare: FHIR, HL7, and the Path to Connected Care
Interoperability in healthcare is crucial for enabling seamless data exchange among providers. The integration of FHIR over current HL7 standards lays the groundwork for connected care, facilitated by regulations and the need for improved patient outcomes.
A patient visits a cardiologist who orders blood work. The lab results go to the cardiologist's EHR. The patient's primary care physician, who manages their diabetes, does not see the results. The endocrinologist, who is adjusting their medication, does not see them either. The patient has three doctors making medication decisions based on incomplete information, because the systems that hold the data do not talk to each other.
This is not a theoretical scenario. It is the daily reality of American healthcare. Despite $36 billion in federal incentives for EHR adoption over the past 15 years, health data remains trapped in siloed systems. The electronic health record was supposed to be the foundation of connected care. Instead, it became a walled garden that stores data beautifully and shares it reluctantly.
Despite $36 billion in federal incentives for EHR adoption, health data remains trapped in siloed systems.
- Industry Analysis
FHIR (Fast Healthcare Interoperability Resources) is changing this, slowly. The question is not whether FHIR will enable connected care. It is how quickly healthcare organizations will adopt it beyond the regulatory minimum.
Understanding the Standards Landscape
HL7v2 is the legacy standard that most healthcare systems use today. It is messaging-based (point-to-point), uses a pipe-delimited text format, and was designed in the 1980s for batch data exchange between hospital systems. HL7v2 interfaces are brittle, expensive to maintain, and require custom mapping for every pair of systems that need to exchange data. Despite its limitations, HL7v2 remains the workhorse of healthcare integration because it is deeply embedded in existing infrastructure.
FHIR (HL7 Fast Healthcare Interoperability Resources, Release 4) is the modern standard built on web technologies: RESTful APIs, JSON data format, OAuth 2.0 authentication, and standardized resource types (Patient, Observation, MedicationRequest, Encounter). FHIR is what HL7v2 would be if it were designed today.
The CMS Interoperability and Patient Access Rule requires CMS-regulated payers and providers to implement FHIR-based APIs for patient data access. ONC's 21st Century Cures Act Final Rule mandates that EHR vendors support FHIR APIs and prohibits information blocking. These regulations are creating the forcing function that voluntary standards adoption never achieved.
The Practical Interoperability Architecture
The architecture that works in 2026 is not ripping out HL7v2 and replacing it with FHIR. It is building a FHIR integration layer on top of existing HL7v2 infrastructure.
An integration engine (Rhapsody, Mirth Connect, Microsoft Azure Health Data Services) sits between the legacy systems and the FHIR API layer. It translates HL7v2 messages into FHIR resources, maps legacy codes to standard terminologies (SNOMED CT, LOINC, ICD-10), normalizes data formats, and exposes the translated data through FHIR-compliant APIs.
This approach preserves the existing HL7v2 infrastructure (which works reliably for intra-organizational data flow), adds FHIR capability for inter-organizational data sharing and patient-facing applications, and creates a path to gradually migrate internal integrations from HL7v2 to FHIR as legacy systems are replaced.
The Consent and Security Layer
Healthcare data sharing requires patient consent management that is more granular than most other industries. A patient may consent to sharing lab results with their primary care physician but not with a research organization. They may consent to sharing mental health records with their psychiatrist but not with their employer's wellness program.
The FHIR Consent resource provides a standardized way to express and enforce these preferences, but implementing granular consent in practice requires a consent management platform that captures patient preferences through a clear user interface, stores consent decisions as machine-readable policies, and enforces those policies at the API level (filtering FHIR responses based on the requesting party's consent status).
Healthcare interoperability is ultimately not about technology standards. It is about the willingness of healthcare organizations to share data in service of better patient outcomes. FHIR lowers the technical barriers. Regulation creates the compliance incentive. But the organizations that achieve genuine connected care are the ones that treat interoperability as a clinical imperative, not just a technical requirement.
Adopting FHIR standards effectively bridges the gaps in healthcare data exchange, making connected care a feasible reality.
Building FHIR-based integrations? Talk to Flynaut about healthcare application development and interoperability at flynaut.com/application-development.