Healthcare interoperability is the ability of different health IT systems, devices and organisations to exchange data and use it correctly, without someone retyping or reinterpreting it. A lab result from an analyser should land in the patient's record with the right test code and units; a referral should arrive at the specialist with the problem list and medications intact; a patient should be able to pull their record into an app.
That only works when systems agree on several things at once: how they connect, how messages are structured, what the codes mean, and who is allowed to see what. Healthcare interoperability standards are those agreements.
This post is the map: the four levels of interoperability, which standard does which job, how terminologies fit in, and the exchange frameworks by region. For implementation detail on HL7 v2 and FHIR R4 interfaces, see our HL7 FHIR integration guide; for the US policy layer, see our post on TEFCA, SMART on FHIR and CMS rules.
Interoperability in healthcare: meaning and the four levels
HIMSS describes four levels of interoperability, each building on the one before. TechTarget has a good summary of the four levels.
| Level | Question it answers | Example |
|---|---|---|
| Foundational | Can system A send data to system B at all? | A secure connection or file transfer exists |
| Structural | Is the data in a format B can parse? | An HL7 v2 message or FHIR resource with known fields |
| Semantic | Does B understand what the data means? | Codes from SNOMED CT, LOINC, ICD so "high blood pressure" and "hypertension" match |
| Organisational | Are governance, consent, policy and trust in place? | Data sharing agreements, consent rules, exchange membership |
Most real projects stall at the semantic and organisational levels. Sending a message is easy; making sure the receiver codes it the same way, and is allowed to use it, is the hard part.
The main healthcare interoperability standards
These are the standards you will meet most often, grouped by the job they do.
Messaging and data exchange
| Standard | What it does | Where it is used |
|---|---|---|
| HL7 v2 | Event messages (admissions, orders, results) in a pipe-delimited format | Inside hospitals: lab, radiology, ADT feeds |
| HL7 CDA and C-CDA | Structured clinical documents such as discharge summaries | Document exchange, especially in the US |
| HL7 FHIR | Web-friendly resources (Patient, Observation, MedicationRequest) over REST APIs | Apps, national exchanges, patient access, payer APIs |
| DICOM | Medical images and imaging metadata, plus network services | PACS, modalities, imaging exchange |
| X12 | Claims, eligibility, remittance and authorisation transactions | US healthcare payments |
| NCPDP SCRIPT | E-prescribing messages | US pharmacy prescriptions |
FHIR R4 is the version most regulations point to today. The next major release, R6, is in normative balloting; HL7's R6 ballot page tracks the changes, and publication is not expected before 2027. Build on R4 now and design for an upgrade path.
Terminologies and code systems
Structure without shared codes gives you semantic mismatches. These code systems supply the meaning.
| Code system | What it codes | Notes |
|---|---|---|
| SNOMED CT | Clinical findings, diagnoses, procedures, body structures | Very detailed clinical terminology; licensed via national release centres |
| LOINC | Lab tests and clinical observations | Lets a "haemoglobin" result mean the same in every lab |
| ICD-10 and ICD-11 | Diagnoses for statistics and billing | ICD-11 took effect in 2022; many countries, including the US, still use ICD-10 variants |
| CPT and HCPCS | Procedures and services for US billing | CPT is licensed by the AMA |
| RxNorm | Medications in the US | Local drug dictionaries apply elsewhere |
| UCUM | Units of measure | Prevents mg/dL vs mmol/L errors |
A practical rule: use SNOMED CT for clinical meaning in the record, map to ICD for reporting and billing, LOINC for lab and observations, and a national or standard drug vocabulary for medicines.
Profiles, security and app standards
- IHE profiles define how to combine standards for common tasks, such as document sharing (XDS), patient identity lookup (PIX and PDQ) and imaging workflow.
- SMART on FHIR defines how apps launch from an EHR and get authorised access to FHIR data, using OAuth 2.0 and OpenID Connect.
- CDS Hooks lets an EHR call an external decision support service at points in the workflow and show cards to the clinician.
- FHIR Bulk Data exports data for whole populations, for analytics and payer use.
- National FHIR profiles such as US Core, UK Core and India's ABDM profiles constrain FHIR resources for one country.
HL7 vs FHIR vs DICOM: which one do you need?
They are not competitors; each covers different data.
| Need | Standard to use |
|---|---|
| Hospital lab or ADT feed with an existing HIS | HL7 v2, usually through an integration engine |
| App reading or writing EHR data | FHIR with SMART on FHIR |
| National exchange or patient record sharing | FHIR (and CDA in some US networks) |
| Images from CT, MRI, X-ray | DICOM, with DICOMweb for web access |
| US claims and eligibility | X12 |
| Coding diagnoses and labs consistently | SNOMED CT, ICD, LOINC |
Most hospitals run all of these at once. Our healthcare integration work spends more time mapping codes and handling exceptions than on message formats themselves.
Worked example: one lab result across all four levels
Follow a single haemoglobin result from a hospital lab to a referring clinic's EMR.
- Foundational. The lab system and the hospital's integration engine have a secure connection; the result leaves the analyser and reaches the engine.
- Structural. The engine receives an HL7 v2 ORU result message and turns it into a FHIR Observation resource, with patient, value, unit, reference range and time in known fields.
- Semantic. The local test name "HB" is mapped to the correct LOINC code, the unit is expressed in UCUM, and the abnormal flag uses a standard value set, so the clinic's EMR files it as haemoglobin and can graph it against earlier results from other labs.
- Organisational. The patient has consented to sharing, the hospital and clinic are both members of the regional exchange, and access is logged for audit.
Remove any one step and the result either never arrives, arrives as unreadable text, gets filed as an unknown test, or should not have been shared at all.
Health information exchange frameworks by region
Standards define the language. Exchange frameworks define who connects, under what rules.
| Region | Framework | Core standards |
|---|---|---|
| USA | TEFCA with Qualified Health Information Networks; ONC certification; CMS API rules | FHIR R4, US Core, USCDI, C-CDA, X12 |
| UK | NHS Spine services, GP Connect, shared care records | FHIR UK Core, HL7 v2, NHS number as identifier |
| EU | European Health Data Space regulation, adopted in 2025, with phased obligations | EU-wide formats for patient summaries, prescriptions, images, labs |
| UAE | NABIDH (Dubai), Malaffi (Abu Dhabi), Riayati (federal), connected to each other | HL7 v2 and FHIR, emirate implementation guides |
| India | Ayushman Bharat Digital Mission: ABHA, HFR, HPR, health information exchange | FHIR R4 with ABDM profiles, SNOMED CT, LOINC |
Each framework adds identity, consent and trust rules on top of the standards. In India, for example, records move between a health information provider and a user only with consent through the ABDM consent manager; our ABDM integration guide covers the milestones. In the UAE, connecting to the right exchange is a licensing matter; see EMR software in the UAE.
Why interoperability projects fail
- Codes not mapped. Local test names and free-text diagnoses that never got mapped to LOINC or SNOMED CT.
- Patient identity. Duplicate or mismatched patient records across systems, without a reliable identifier or matching process.
- One-off interfaces. Point-to-point scripts with no monitoring, which fail silently.
- Consent and governance left to the end. Data cannot be shared because agreements and consent flows were never set up.
- Version drift. Partners on different FHIR or HL7 versions with no translation layer.
How to build an interoperability roadmap
- Inventory systems and data flows. List every system, what data it holds and where data is retyped today.
- Pick the identifier strategy. National ID (NHS number, ABHA, Emirates ID-linked records) plus a matching rule.
- Standardise codes at entry. Configure terminologies in the source systems, not only in the interface.
- Use an integration layer. One place for routing, transformation, logs and alerts, rather than many scripts.
- Connect to the regional exchange. Follow the national implementation guide and certification steps.
- Measure. Track message volumes, failures, mapping gaps and time to fix. Clean exchanged data also improves health data analysis.
How Algon approaches interoperability
Algon is a Kochi-based team that builds hospital systems and integrations for clients in India, the UAE and the USA. We start by listing where staff retype data today, then connect those systems with HL7 v2, FHIR or simpler interfaces, depending on what the other side supports, with message logs and alerts so failures are visible. Our hospital management system builds use the same approach for ABDM-ready and HL7/FHIR interfaces.
Conclusion
Healthcare interoperability is a stack, not a product. HL7 v2 still moves most data inside hospitals, FHIR carries most new exchange and app access, DICOM handles images, X12 handles US payments, and SNOMED CT, LOINC and ICD supply the meaning. Regional frameworks such as TEFCA, NHS services, the UAE exchanges and ABDM decide who can share with whom.
Get identity, codes and governance right, and the message formats are the easy part. For connecting a specific product to a specific EHR, read our EHR integration guide.
Frequently asked questions
What is interoperability in healthcare?
Interoperability in healthcare is the ability of different systems, devices and organisations to exchange health data and use it correctly without manual re-entry or reinterpretation. It depends on shared connections, formats, codes and governance.
What are the four levels of interoperability in healthcare?
HIMSS describes foundational (data can be sent), structural (data has a common format), semantic (data uses shared codes so meaning is preserved) and organisational (governance, consent, policy and trust are in place) interoperability.
What is the difference between HL7 and FHIR?
HL7 v2 is an older event-based messaging standard used heavily inside hospitals. FHIR, also from HL7, is a newer standard built on web APIs and resources, used for apps, national exchanges and patient access. Most organisations use both.
What are SNOMED CT, LOINC and ICD used for?
SNOMED CT codes clinical meaning such as findings and procedures, LOINC codes lab tests and observations, and ICD codes diagnoses for statistics and billing. Using them consistently is what makes exchanged data understandable.
Is DICOM part of HL7?
No. DICOM is a separate standard for medical images and imaging communication, maintained by its own standards committee. Systems often use DICOM for images and HL7 or FHIR for orders and reports.
What is a health information exchange?
A health information exchange is a network or service that lets organisations share patient records under common rules. Examples include TEFCA networks in the US, NABIDH and Malaffi in the UAE, and the ABDM health information exchange in India.
