Short answer: health data moves through four layers of standards. Exchange standards carry the data between systems: HL7 v2 messages, CDA documents, FHIR resources and DICOM for images. Modelling and storage standards say how a record is structured inside a system: openEHR for clinical records, OMOP for research databases. Terminologies give every concept a code that both sides understand: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. Identity and security standards decide who may read what: OAuth 2.0 and SMART on FHIR, plus IHE profiles that combine all of the above into tested recipes. Nobody uses just one; a hospital typically runs all four layers at once.
The map
Healthcare interoperability standards form four layers. Exchange standards (HL7 v2, CDA, FHIR, DICOM and DICOMweb) move data between systems, and IHE profiles combine them into tested recipes. openEHR structures the stored record and OMOP structures research databases. Terminologies such as SNOMED CT and LOINC, and identity standards such as SMART on FHIR, are used inside all of them.
| Layer | Standard | What it is | Where you meet it in 2026 |
|---|---|---|---|
| Exchange | HL7 v2 | Pipe-delimited messages (ADT, ORU, ORM, SIU) over MLLP | Inside hospitals: admissions, lab results, orders, scheduling. Still the most common interface |
| Exchange | CDA / C-CDA | XML clinical documents with a human-readable part and coded entries | Discharge summaries, referral letters, the US C-CDA, cross-border summaries in MyHealth@EU |
| Exchange | FHIR (R4, R4B, R5) | Web resources (Patient, Observation, Condition…) over REST and JSON | Patient apps, national APIs, EHR APIs, US Core, the IPS, the EHDS exchange format |
| Exchange | DICOM and DICOMweb | Image objects with embedded metadata; DICOMweb is its REST face | Every scanner, PACS and radiology viewer; web viewers use DICOMweb |
| Recipes | IHE profiles | Tested combinations of the above for one use case (XDS, PIX/PDQ, XCA, SWF) | Document sharing between hospitals and regions, patient identity, radiology workflow |
| Storage | openEHR | Archetype-based clinical data model for the record itself | Hospital and national EHR platforms in parts of Europe, Scandinavia, Brazil |
| Research | OMOP CDM | A common relational model for observational research | Research networks, real-world evidence, EHDS secondary use |
| Terminology | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | Codes for findings, tests, diagnoses, medicines, units | Inside every one of the standards above |
| Identity | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | Who the user is and what the app may access | Every patient-facing app and every EHR app platform |
How the layers fit together
The layers of healthcare interoperability standards fit together by each doing one job in the same workflow: an HL7 v2 message carries a lab order, LOINC and UCUM code the result, an openEHR platform stores it, a FHIR API serves it to a patient app after a SMART on FHIR login, and a CDA document shares it with another hospital.
A blood test shows all four layers in one afternoon. The order leaves the ward as an HL7 v2 ORM message (exchange). The analyser result comes back as an HL7 v2 ORU, with the test coded in LOINC and the unit in UCUM (terminology). The hospital stores it in its own database, perhaps an openEHR platform (storage). The patient's app reads it through a FHIR API as an Observation, after the patient logged in with SMART on FHIR (identity). If the hospital shares the full report with another hospital, it may do so as a CDA document through an IHE XDS registry. If the result later joins a research cohort, it is converted into OMOP.
The standards are not competitors. Each was built for a different job, and replacing one with another usually means rebuilding something that already works.
Which one do you need?
Which healthcare interoperability standard you need depends on the job: FHIR R4 with SMART on FHIR for patient or clinician apps, HL7 v2 for connecting to existing hospital systems, DICOM and DICOMweb for images, CDA or FHIR documents for whole documents, openEHR for long-term record storage, OMOP for research, and IHE profiles when two systems must behave identically.
- You are building an app for patients or clinicians: FHIR R4, with the profiles of your market (implementation guides), SMART on FHIR for login.
- You are connecting to a hospital's existing systems: expect HL7 v2 first; FHIR where the vendor offers it. See HL7 v2 messages explained.
- You handle images: DICOM for storage and transfer, DICOMweb for anything in a browser, FHIR ImagingStudy only for the metadata. See DICOMweb explained and ImagingStudy vs DICOMweb.
- You exchange whole documents (summaries, letters): CDA where it is mandated, FHIR documents (a Bundle of type
document) where you can choose. See CDA and C-CDA explained. - You design how a record is stored for decades: openEHR, with FHIR as the exchange layer. See openEHR vs FHIR.
- You run research on many records: OMOP, with FHIR as the source. See Secondary use of health data.
- You need two systems to behave the same way: pick the IHE profile for your use case and test against it.
Where Anpheros sits
Anpheros Platform sits in the exchange layer of the standards map as a FHIR R4 server with OAuth 2.0 access and webhooks for change notifications, receiving lab results through a connector from HL7 v2 ORU, CSV or JSON. It does not store DICOM images and does not offer a CDS Hooks service; those stay in hospital systems.
Anpheros Platform is a FHIR R4 server with the resources a patient-centred record needs (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance and others), OAuth 2.0 for access, and webhooks for change notifications. Lab results arrive through the lab connector from HL7 v2 ORU, CSV or JSON. It does not store DICOM images and does not offer a CDS Hooks service; those stay in the hospital's systems, and the record points to them.
Reading order
A good reading order for healthcare interoperability standards starts with what FHIR is and how it differs from HL7 v2, then the FHIR Observation resource, then the LOINC and SNOMED CT terminologies used inside it, then DICOMweb for images, CDA for documents and finally openEHR compared with FHIR for how records are stored.
If you are new to the field: What FHIR is → HL7 vs FHIR → FHIR Observation → LOINC and SNOMED CT → DICOMweb → CDA → openEHR vs FHIR.
Related pages
- HL7 vs FHIR
- HL7 v2 messages explained
- CDA and C-CDA explained
- DICOMweb explained
- openEHR vs FHIR
- FHIR implementation guides
- FHIR R4 vs R5
- What is a LOINC code?
- What is SNOMED CT?
- DICOM vs FHIR for developers
- FHIR profiles and extensions explained
- FHIR terminology servers explained
- Health data regulation map
- National electronic health records in Europe and the US
- Hospital system integration explained
- AI on medical data
- Secondary use of health data
- Security and identity in health apps
Sources
- HL7 International: standards
- HL7 FHIR R4 specification
- DICOM standard, current edition
- IHE technical frameworks
- openEHR specifications
- OHDSI OMOP Common Data Model
- SMART App Launch
Frequently asked questions
Is FHIR replacing all the other standards?
No. FHIR is replacing custom APIs and, slowly, some CDA document exchange. HL7 v2 remains the workhorse inside hospitals, DICOM remains the only standard for images, and openEHR and OMOP answer questions (storage, research) that FHIR was not designed to answer.
What is the difference between a standard and an IHE profile?
A standard such as FHIR or DICOM defines building blocks. An IHE profile picks specific blocks, fixes their options and says exactly how systems must use them for one task, so that two vendors who both pass the IHE tests can work together without a project.
Which standard do national health systems use?
Most European systems started with CDA documents and HL7 v2, and are adding FHIR APIs; the EHDS exchange format is built on FHIR and the IPS. The US mandates FHIR US Core for patient access and C-CDA for document exchange.
Where do SNOMED CT and LOINC fit?
They are not exchange standards; they are vocabularies used inside all of them. A LOINC code identifies the test in an HL7 v2 OBX segment, a CDA entry and a FHIR Observation alike.
Try it free in the sandbox
Your first FHIR call in 5 minutes. An HL7 FHIR R4 API with the patient's consent built in: try it in the sandbox, then connect your own app or clinic system.
Free · 30 synthetic patients · no card
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
