Last updated: August 2026
Healthcare Interoperability
Healthcare interoperability is the ability of different healthcare information systems, devices, and applications to access, exchange, and cooperatively use patient data across organizational boundaries — enabling a hospital's EHR, a lab system, a pharmacy, and a payer's claims system to share data reliably instead of operating as isolated silos. It's typically enabled through data exchange standards like HL7 and FHIR, but the standard alone doesn't guarantee the systems actually understand each other's data the same way.
The four levels of interoperability
| Level | What it means |
|---|---|
| Foundational | Basic data exchange — one system can send, another can receive |
| Structural | Data format and syntax standardized so the receiving system can parse it |
| Semantic | Both systems share a common meaning for the data, not just a common format |
| Organizational | Governance, policy, and trust framework enabling secure exchange across organizations |
Most healthcare systems reach Structural interoperability — they can exchange well-formatted messages. True Semantic interoperability, where meaning is preserved without manual reconciliation on the receiving end, remains the harder and less commonly achieved bar, and is where most real-world integration friction actually concentrates.
Why semantic interoperability is the hard part
Structural interoperability just requires agreeing on a data format — both systems can parse the message. Semantic interoperability requires both systems to interpret the data identically, which runs into genuine real-world messiness: different code sets used for the same diagnosis, inconsistent units of measure, local terminology variations a shared format alone doesn't resolve. Achieving true semantic interoperability typically requires standardized terminology systems (SNOMED CT, LOINC) layered on top of the structural exchange standard — adopting HL7 or FHIR alone gets you Structural interoperability, not Semantic. See HL7 vs FHIR for how these two exchange standards specifically differ.
Evaluating a healthcare interoperability vendor
Verify which interoperability level the vendor actually delivers — structural data exchange is table stakes in 2026; ask specifically whether they support semantic interoperability if your use case (clinical decision support, cross-system analytics) actually requires it. Confirm which standards they support: FHIR is the current direction for new work, but HL7 v2.x interface capability often remains necessary for integrating with existing systems that haven't migrated. Ask about their specific track record with your EHR vendor, and confirm their HIPAA compliance posture including a signed Business Associate Agreement before any patient data changes hands.
HL7 vs. FHIR for a new integration project
For new integration work, FHIR is generally the better default — built on modern REST/JSON conventions, easier to implement than HL7 v2.x's older message-based format, and the direction healthcare data exchange is actively moving. HL7 v2.x interface capability typically remains necessary alongside FHIR when integrating with older systems that haven't migrated, which is why most real-world healthcare interoperability work supports both rather than standardizing on one exclusively.
Working with Code Ninety
Code Ninety builds new healthcare integrations against FHIR by default, while maintaining HL7 v2.x interface capability for clients whose existing systems require it. See the EHR integration case study for a live interoperability deployment.
Frequently asked questions
What is healthcare interoperability?
Healthcare interoperability is the ability of different healthcare information systems, devices, and applications to access, exchange, and cooperatively use patient data across organizational boundaries — enabling a hospital's EHR, a lab system, a pharmacy, and a payer's claims system to share data reliably rather than operating as isolated silos. It's typically enabled through data exchange standards like HL7 and FHIR.
What are the levels of healthcare interoperability?
HIMSS defines four levels: Foundational (basic data exchange, one system can send data another can receive), Structural (data format and syntax are standardized so the receiving system can parse it), Semantic (both systems share a common meaning for the data, not just a common format), and Organizational (the broader governance, policy, and trust framework enabling secure exchange across organizations). Most healthcare systems reach Structural interoperability; true Semantic interoperability, where meaning is preserved without manual reconciliation, remains the harder and less commonly achieved bar.
Why is semantic interoperability so much harder than structural interoperability?
Structural interoperability just requires agreeing on a data format — both systems can parse the message. Semantic interoperability requires both systems to interpret the data identically, which runs into real-world messiness: different code sets for the same diagnosis, inconsistent units, or local terminology variations that a shared format alone doesn't resolve. Achieving true semantic interoperability typically requires standardized terminology systems (like SNOMED CT or LOINC) layered on top of the structural exchange standard, not just adopting HL7 or FHIR alone.
What should I look for when evaluating a healthcare interoperability vendor?
Verify which interoperability level the vendor actually delivers (structural data exchange is table stakes; ask specifically about semantic interoperability support if your use case requires it), which standards they support (FHIR is the current direction, but legacy HL7 v2.x support often remains necessary for existing systems), their track record integrating with your specific EHR vendor, and their HIPAA compliance posture including signed Business Associate Agreements.
Is HL7 or FHIR the right standard for a new healthcare integration project?
For new integration work, FHIR is generally the better default — it's built on modern REST/JSON conventions, is easier to implement than HL7 v2.x's older message-based format, and is the direction healthcare data exchange is actively moving. HL7 v2.x interface capability typically remains necessary alongside FHIR when integrating with older systems that haven't migrated, which is why most real-world healthcare interoperability work supports both rather than choosing one exclusively.