Healthcare interoperability — the ability of different information systems, devices, and applications to access, exchange, integrate, and cooperatively use data — has moved from aspirational goal to regulatory mandate. In 2026, HL7 FHIR (Fast Healthcare Interoperability Resources) has emerged as the dominant standard for health data exchange, fundamentally changing how hospitals, clinics, pharmacies, labs, and payers share patient information. Understanding these standards is no longer optional for healthcare IT leaders; it is essential for compliance, care coordination, and competitive advantage.
This guide provides a thorough examination of healthcare interoperability standards, the transition from legacy HL7v2 to modern FHIR APIs, regulatory requirements under ONC rules, and practical implementation strategies for healthcare organizations of all sizes.
Quick Comparison: HL7v2 vs. HL7 FHIR vs. CDA
| Characteristic | HL7v2 | CDA (C-CDA) | HL7 FHIR R4/R5 | |---|---|---|---| | Architecture | Message-based | Document-based | Resource-based (RESTful API) | | Data Format | Pipe-delimited | XML | JSON, XML, RDF | | Adoption | Ubiquitous (legacy) | Widespread | Rapidly growing | | Ease of Implementation | Complex | Moderate | Easy to Moderate | | Real-Time Exchange | Yes (point-to-point) | No (batch) | Yes (API + subscriptions) | | Mobile/Web Friendly | No | No | Yes | | Granularity | Message-level | Document-level | Resource-level | | Developer Ecosystem | Limited | Limited | Extensive | | ONC Certification | Legacy support | Required | Required (primary) | | Future Direction | Maintenance only | Limited updates | Active development |
Understanding Healthcare Interoperability
The Four Levels of Interoperability
The Healthcare Information and Management Systems Society (HIMSS) defines four levels of interoperability that organizations must address:
1. Foundational Interoperability
- The ability to send data from one system to another
- Does not require the receiving system to interpret the data
- Example: Sending a PDF lab report via secure email
2. Structural Interoperability
- Defines the format and syntax of data exchange
- The receiving system can parse the data at the field level
- Example: Sending an HL7v2 ADT message with structured patient demographics
3. Semantic Interoperability
- Shared understanding of the meaning of data
- Uses standardized vocabularies (SNOMED CT, LOINC, RxNorm, ICD-10)
- Example: Both systems recognize LOINC code 2339-0 as "Glucose [Mass/volume] in Blood"
4. Organizational Interoperability
- Governance, policy, and legal frameworks enabling data sharing
- Includes data use agreements, consent management, and trust frameworks
- Example: Participating in a Health Information Exchange (HIE) network
HL7v2: The Legacy Standard
HL7 Version 2 has been the backbone of healthcare data exchange for over 30 years. Despite its age, HL7v2 messages still power the majority of clinical interfaces worldwide.
How HL7v2 Works
HL7v2 uses a pipe-delimited message format with segments, fields, and components:
MSH|^~\&|SENDING_APP|SENDING_FAC|RECEIVING_APP|RECEIVING_FAC|20260221||ADT^A01|MSG001|P|2.5
PID|1||12345^^^MRN||Doe^John^A||19800101|M|||123 Main St^^Anytown^ST^12345
PV1|1|I|ICU^101^A|E|||1234^Smith^Jane|||MED||||||||V12345|||||||||||||||||||||20260221
Common HL7v2 Message Types
| Message Type | Trigger Event | Description | |---|---|---| | ADT | A01-A62 | Admit, Discharge, Transfer events | | ORM | O01 | Order messages (labs, radiology, pharmacy) | | ORU | R01 | Observation results (lab results, vital signs) | | SIU | S12-S26 | Scheduling information | | DFT | P03 | Detailed financial transactions | | MDM | T01-T11 | Medical document management | | RDE | O11 | Pharmacy/treatment encoded orders | | BAR | P01-P06 | Billing account records |
Limitations of HL7v2
Despite its widespread use, HL7v2 has significant limitations:
- No standardized implementation guide — each interface is custom-negotiated
- Point-to-point architecture requiring dedicated connections between every system pair
- Limited support for modern web and mobile applications
- Inconsistent use of coded values across organizations
- Difficult to query — designed for push-based messaging, not data retrieval
- Poor support for complex data types like images, genomics, and social determinants
HL7 FHIR: The Modern Standard
FHIR (Fast Healthcare Interoperability Resources) represents a fundamental reimagining of healthcare data exchange. Built on modern web standards, FHIR uses RESTful APIs, JSON, and a resource-based data model that developers from any background can quickly learn and implement.
FHIR Core Concepts
Resources: The building blocks of FHIR. Each resource represents a discrete clinical or administrative concept:
- Patient — demographic and administrative information
- Encounter — a clinical interaction between a patient and provider
- Observation — measurements and findings (lab results, vital signs)
- Condition — diagnoses and problems
- MedicationRequest — prescriptions and medication orders
- AllergyIntolerance — patient allergies and adverse reactions
- Procedure — clinical procedures performed
- DiagnosticReport — grouped observations with clinical interpretation
- DocumentReference — references to clinical documents
RESTful API: FHIR resources are accessed using standard HTTP methods:
| Operation | HTTP Method | Example |
|---|---|---|
| Read | GET | GET /Patient/12345 |
| Search | GET | GET /Patient?name=Smith&birthdate=1980-01-01 |
| Create | POST | POST /Patient with JSON body |
| Update | PUT | PUT /Patient/12345 with JSON body |
| Delete | DELETE | DELETE /Patient/12345 |
| History | GET | GET /Patient/12345/_history |
FHIR Versions in 2026
| Version | Status | Key Features | |---|---|---| | FHIR R4 (4.0.1) | Normative (Stable) | Core resources, US Core profiles, required for ONC certification | | FHIR R4B (4.3.0) | Stable | Minor additions, subscriptions framework | | FHIR R5 (5.0.0) | Published | Enhanced subscriptions, new resources, improved search | | FHIR R6 | In Development | Next-generation features, broader coverage |
Most organizations should target FHIR R4 as their primary implementation version, as it is the version required by ONC certification and supported by all major EHR vendors.
SMART on FHIR
SMART (Substitutable Medical Applications, Reusable Technologies) on FHIR is a standards-based framework for building applications that integrate with EHR systems. SMART on FHIR enables a "write once, run anywhere" approach to healthcare app development.
How SMART on FHIR Works
- App Registration: The application registers with the EHR's FHIR server
- Authorization: The user (patient or clinician) launches the app and authorizes access via OAuth 2.0
- Data Access: The app accesses FHIR resources scoped to the authorized context (patient, encounter, user)
- Interaction: The app displays data, collects input, or performs calculations within the EHR workflow
SMART on FHIR Use Cases
- Clinical decision support apps that analyze patient data and provide recommendations
- Patient-facing apps that allow patients to view and contribute to their health records
- Population health dashboards that aggregate data across patient panels
- Research recruitment tools that identify eligible patients for clinical trials
- Specialty calculators for risk scores, dosing, and clinical assessments
- Quality measure reporting applications that calculate and submit quality metrics
Bulk Data Access
FHIR Bulk Data Access (also known as "Flat FHIR") enables the export of large volumes of data for population-level analytics, reporting, and research. This capability is critical for:
- Population health management — analyzing health trends across entire patient populations
- Quality reporting — submitting data to CMS and other quality programs
- Research — extracting de-identified datasets for clinical studies
- Payer data exchange — sharing claims and clinical data with insurance companies
- Public health reporting — submitting surveillance data to health departments
Bulk Data Export Process
- Client initiates a bulk export request:
GET /Patient/$export - Server processes the request asynchronously and returns a polling URL
- Client polls the URL until the export is complete
- Server returns links to NDJSON (Newline Delimited JSON) files
- Client downloads the files for processing
ONC Regulations and Information Blocking
The ONC (Office of the National Coordinator for Health IT) has established rules that fundamentally impact how healthcare organizations handle interoperability.
ONC Cures Act Final Rule
Key requirements that affect healthcare organizations in 2026:
- Certified Health IT must support FHIR R4 APIs for patient and population-level data access
- Standardized API for patient services — patients must be able to access their EHI using FHIR-based APIs
- Standardized API for population services — bulk FHIR export for payer and population health use cases
- EHI Export — certified health IT must allow export of all electronic health information
Information Blocking Rules
The Information Blocking Rule prohibits healthcare providers, health IT developers, and health information networks from practices that unreasonably limit access, exchange, or use of electronic health information.
Exceptions to the Information Blocking Rule (practices that are NOT considered information blocking):
| Exception | Description | |---|---| | Preventing Harm | Withholding data to prevent patient harm | | Privacy | Complying with privacy laws and patient preferences | | Security | Implementing reasonable security measures | | Infeasibility | When sharing is technically infeasible | | Health IT Performance | Maintaining system uptime and performance | | Content and Manner | Fulfilling requests in an alternative manner | | Fees | Charging reasonable fees for data access | | Licensing | Reasonable licensing terms for interoperability |
Penalties for Information Blocking
- Healthcare providers face civil monetary penalties up to $1 million per violation
- Health IT developers risk loss of ONC certification
- Health information networks face civil monetary penalties and reputational damage
CDA Documents
Clinical Document Architecture (CDA) documents, particularly C-CDA (Consolidated CDA), remain important for document-based exchange even as FHIR adoption grows.
Common C-CDA Document Types
- Continuity of Care Document (CCD) — summary of patient's current health status
- Discharge Summary — documentation at hospital discharge
- Consultation Note — findings from a specialist consultation
- Progress Note — documentation of a clinical encounter
- Referral Note — information sent with a patient referral
- Transfer Summary — documentation for patient transfers between facilities
C-CDA and FHIR Coexistence
In 2026, most organizations need to support both C-CDA and FHIR:
- C-CDA for document exchange via Direct messaging and HIE networks
- FHIR for real-time API access, patient apps, and modern integrations
- Conversion tools that transform C-CDA documents into FHIR resources and vice versa
API-First Architecture for Healthcare
An API-first architecture treats FHIR APIs as the primary interface for all data access, rather than building APIs as an afterthought.
Principles of API-First Healthcare Architecture
- Design APIs before building applications — define the data model and endpoints first
- Use FHIR as the canonical data model — even for internal system communication
- Implement API gateways for security, throttling, and monitoring
- Version APIs to maintain backward compatibility as standards evolve
- Document comprehensively using OpenAPI/Swagger specifications
- Test continuously with automated integration testing against FHIR conformance suites
Benefits of API-First Architecture
- Faster integration with new partners, vendors, and applications
- Reduced integration costs through standardized interfaces
- Improved developer experience attracting top talent and innovation
- Future-proof design that adapts as standards evolve
- Better security through centralized API management
- Ecosystem development enabling third-party applications and innovation
Practical Implementation Guide
Step 1: Assess Current State
- Inventory all existing interfaces (HL7v2, custom, file-based)
- Document data flows between systems
- Identify gaps in semantic interoperability (inconsistent coding)
- Evaluate EHR vendor FHIR capabilities and certification status
Step 2: Define Interoperability Strategy
- Prioritize use cases based on clinical and business value
- Select target FHIR Implementation Guides (US Core, Da Vinci, CARIN)
- Determine build vs. buy vs. partner approach for each use case
- Establish governance for API management and data quality
Step 3: Build the Foundation
- Deploy a FHIR server (HAPI FHIR, Microsoft Azure FHIR, Google Cloud Healthcare API)
- Implement OAuth 2.0 and SMART on FHIR for authentication and authorization
- Set up terminology services for code translation (SNOMED CT, LOINC, RxNorm)
- Configure API gateway for security, monitoring, and rate limiting
Step 4: Migrate and Connect
- Begin with high-volume, high-value interfaces (lab results, orders, ADT)
- Implement FHIR facades over legacy HL7v2 interfaces for gradual migration
- Connect to Health Information Exchanges (HIEs) using FHIR endpoints
- Enable patient-facing FHIR APIs for portal and mobile app access
Step 5: Optimize and Scale
- Monitor API performance, error rates, and usage patterns
- Implement FHIR Subscriptions for event-driven workflows
- Enable Bulk Data Access for population health and reporting
- Participate in national networks (TEFCA, Carequality, CommonWell)
How to Choose the Right Interoperability Solution
When evaluating healthcare API standards platforms and interoperability tools, consider:
Technical Requirements
- FHIR version support: Does the platform support R4 and plan for R5?
- Implementation Guides: Which FHIR profiles are supported out of the box?
- Terminology services: Are standard code systems included and maintained?
- Legacy support: Can the platform bridge HL7v2 and FHIR?
- Scalability: Can it handle your transaction volume and growth projections?
Compliance Requirements
- ONC Certification: Is the platform certified under the ONC Health IT Certification Program?
- Information Blocking compliance: Does it help you meet information blocking requirements?
- Security certifications: SOC 2, HITRUST, or other relevant certifications?
- Audit logging: Comprehensive audit trails for all data access and exchange?
Operational Requirements
- Monitoring and alerting: Real-time visibility into interface health and errors
- Error handling: Automated retry, dead-letter queues, and escalation workflows
- Documentation: Developer portal with interactive API documentation
- Support: Technical support with healthcare interoperability expertise
Why Consider HospitalOS and MedSoftwares
HospitalOS is built with an API-first architecture that embraces modern healthcare interoperability standards. Unlike legacy systems that bolt on FHIR support as an afterthought, HospitalOS uses FHIR as a core component of its data architecture.
Key interoperability capabilities of HospitalOS include:
- FHIR R4 API — full support for patient, clinical, and administrative resources
- HL7v2 interface engine — connect with legacy systems through standard HL7v2 messaging
- SMART on FHIR — enable third-party application integration within the HospitalOS workflow
- Bulk Data Export — population-level data access for reporting and analytics
- Terminology services — built-in support for ICD-10, SNOMED CT, LOINC, and RxNorm
- API gateway — secure, monitored access to all system capabilities
- HIE connectivity — ready to connect with Health Information Exchange networks
PharmaPOS leverages FHIR-based medication and pharmacy resources to ensure seamless data exchange between pharmacy operations and clinical systems, supporting e-prescribing workflows and medication reconciliation.
Ready to build a connected, interoperable healthcare ecosystem? Contact MedSoftwares for a consultation on your interoperability strategy.
