HL7 v2, FHIR, DICOM and IHE explained

HL7 v2 moves event messages between hospital systems, such as admissions, orders and results. FHIR exposes clinical data as standard resources through a web API for applications, exchange and national reporting. DICOM stores and transmits medical images. IHE profiles specify how these standards are combined for a defined workflow, so that systems from different suppliers behave predictably together. A national or hospital architecture needs all four, each in its proper place.

Procurement documents often ask for "HL7 compliance" or "FHIR integration" as if one standard could carry every kind of health data. In practice a single outpatient visit can generate an admission message, a laboratory order, an analyser result, a chest X ray and a discharge summary, and each is best carried by a different standard. This guide sets out what each standard does, where it fits, and how to specify them so that the systems a ministry or hospital buys can actually work together.

Why one standard is not enough

Health information exchange has distinct jobs: notifying other systems that something has happened, sharing structured clinical data on request, moving very large image files, and agreeing how all of this behaves in a specific workflow. The standards bodies have divided this work accordingly.

Standard	Maintained by	What it carries	Typical use
HL7 v2	HL7 International	Event messages	Admissions, orders, results inside a hospital
FHIR	HL7 International	Resources through a web API	Applications, exchange between organisations, national data
DICOM	DICOM standard, with NEMA as secretariat	Images and imaging metadata	Modalities, PACS, viewers
IHE profiles	IHE International	Rules for combining standards	Defined workflows such as radiology scheduling or document sharing

Terminologies sit underneath all four. A message or resource can be perfectly formed and still meaningless if one system codes a diagnosis in ICD 10 and another in free text. Code systems are covered separately in clinical terminologies: ICD, SNOMED CT and LOINC.

HL7 v2: the messaging layer inside hospitals

HL7 Version 2 was first published in October 1987 [1]. HL7 describes it as one of the most widely implemented standards for healthcare information in the world, supporting both central patient care systems and distributed departmental systems [1]. HL7's product description reports that more than 95 per cent of healthcare organisations in the United States use it and that implementations exist in more than 35 countries [1].

HL7 v2 is organised by domain. Its chapters cover patient administration, orders, queries, financial management, observations, master files, medical records, scheduling, patient referral, patient care and clinical laboratory automation, among others [1]. A message is triggered by an event: a patient is admitted, an order is placed, a result is verified. The receiving system acts on it.

Its strengths are maturity and reach. Laboratory analysers, radiology information systems and many hospital interfaces already use it. Its limits are equally well known to integration teams: messages are designed for point to point interfaces, local variation between sites is common, and each interface usually needs its own mapping and testing. A systematic review of 80 FHIR implementation studies concluded that FHIR might take years or decades to replace legacy standards [12], which means any hospital system bought today must still exchange HL7 v2 messages competently.

FHIR: resources and APIs for exchange beyond the hospital

FHIR defines resources as the common building blocks for all exchanges, each with defined data elements and an extensibility framework, accessed through a web API using ordinary HTTP interactions [2]. Release 4 includes 145 resource types and, published in 2019, was the first FHIR release with normative content, including the RESTful API, the JSON and XML formats and the Patient and Observation resources [3].

Where HL7 v2 notifies, FHIR lets a system ask. A referral system can query the record for a patient's current medications; a national platform can request a population extract; an approved application can open on the patient the clinician is viewing. FHIR also supports document and message exchange, so the same resources can be packaged as a discharge summary or sent as a notification [2]. The SMART App Launch guide adds a standard way to authorise applications using OAuth 2.0 and scopes [13].

The implications for national programmes, including SMART on FHIR and bulk export, are covered in FHIR R4 explained for ministries of health.

DICOM: the standard for medical imaging

DICOM describes itself as the international standard to transmit, store, retrieve, print, process and display medical imaging information [4]. It integrates image acquisition devices, PACS, workstations, vendor neutral archives and printers from different manufacturers, and it is free to download and use [4]. The International Organization for Standardization publishes ISO 12052, whose 2026 edition is equivalent to part 1 of DICOM and covers imaging in radiology, cardiology, pathology and image based therapies [6].

A DICOM object holds both the pixel data and the metadata that identifies the patient, the study, the series and the acquisition. This is why images from a CT scanner can be opened in a viewer from a different manufacturer and still be attributed to the right patient.

DICOMweb is the web based part of the standard: a set of RESTful services that let developers work with images using common web tools [5]. It defines four services: QIDO RS to search for DICOM objects, WADO RS to retrieve them, STOW RS to store them, and UPS RS to manage worklist items [5]. DICOMweb can also act in front of traditional DICOM network services, so existing modalities do not all need to be replaced [5]. For hospitals without a radiologist on site, DICOMweb is what makes browser based reading and remote reporting practical.

IHE profiles: rules for combining standards

Integrating the Healthcare Enterprise (IHE) is, in the words of the Radiological Society of North America, an initiative by health care professionals and industry to improve how health care computer systems share information [7]. IHE does not write new base standards. It publishes detailed specifications, called IHE profiles, that build on established standards, and suppliers implement them from the IHE technical frameworks [7]. Suppliers test their systems against each other at an annual Connectathon and may publish integration statements describing the IHE capabilities of their products [7].

The IT Infrastructure technical framework contains the profiles most relevant to national architecture [8]. Among them:

Patient Identifier Cross referencing (PIX) and its mobile form PIXm, for linking the different identifiers a patient carries across facilities.
Patient Demographics Query (PDQ) and PDQm, for finding a patient by demographic details.
Cross Enterprise Document Sharing (XDS.b), with document source, consumer, registry and repository actors.
Mobile access to Health Documents (MHD), the FHIR based approach to document sharing.
Mobile Care Services Discovery (mCSD), for facility and health worker directories.
Audit Trail and Node Authentication (ATNA), covering secure nodes, audit record repositories and secure transport.
Consistent Time (CT) and Internet User Authorization (IUA).

The OpenHIE architecture, a reference pattern for national health information exchange, names IHE profiles as the building blocks of its data exchange workflows, alongside FHIR resources [10]. Patient identification in particular is discussed in master patient index and unique health identifiers.

A worked example: one imaging request across every standard

The IHE Scheduled Workflow profile shows how the standards divide the work. It integrates the ordering, scheduling, image acquisition, storage and viewing activities of a radiology examination, so that patient and order data stay consistent from registration to report [9]. It specifies HL7 messaging across registration, order entry and the radiology information system, and links those systems to DICOM devices such as modalities and PACS [9].

Step	What happens	Standard used
Registration	Patient is registered or admitted	HL7 v2 patient administration
Order	Clinician requests a chest X ray	HL7 v2 order message, or FHIR ServiceRequest
Worklist	The modality receives patient and order details	DICOM Modality Worklist [9]
Acquisition status	The modality reports the study as started and completed	DICOM Modality Performed Procedure Step [9]
Storage	Images move to PACS, which confirms custody	DICOM storage and Storage Commitment [9]
Viewing	The image is read in a browser or workstation	DICOM or DICOMweb [5]
Report	The report returns to the ordering clinician	HL7 v2 result message, or FHIR DiagnosticReport
Sharing	The report is available to another facility	FHIR, or IHE document sharing [8]

The value of the worklist step is easy to underestimate. Without it, a radiographer types the patient's name at the modality, and spelling errors create images that cannot be matched to the order or the record.

How the standards fit a national architecture

The WHO Global strategy on digital health promotes syntactic and semantic interoperability, built on WHO norms and standards, as a cornerstone of health information, and asks countries to adopt open health data standards [11]. In practice ministries tend to arrive at a layered arrangement:

Inside the hospital, HL7 v2 and DICOM continue to connect departmental systems, analysers and modalities.
Between facilities and to the national level, FHIR is used for exchange, applications and population data, following national profiles.
For shared services such as the client registry, facility registry and document sharing, IHE profiles specify behaviour so that suppliers can be tested against them.
For aggregate reporting, indicators calculated from coded records are submitted to the national platform.

The distinction that matters in procurement is between interoperability, where systems exchange data through named standards, and integration, where a supplier builds a private connection between two specific products. Interoperability survives a change of supplier; integration usually does not.

How Moana approaches interoperability

Moana uses each standard for the job it was designed to do, around one patient record shared across the Moana EHR, MOANA Desktop, MOANA Mobile and the patient portal.

HL7 v2. Moana exchanges HL7 v2 messages with hospital systems, and MOANA LIS integrates with laboratory analysers and instruments, so that results arrive in the record without transcription.
FHIR R4. The record is available as FHIR R4 resources. SMART on FHIR app launch lets approved applications open inside the record with the patient in context, and FHIR bulk export provides population level extracts for ministries and authorised researchers.
DICOM. MOANA PACS provides DICOM storage, a browser based viewer, worklists and reporting. Where a hospital already operates a PACS, Moana integrates with it rather than requiring it to be replaced.
Terminology. Diagnoses can be coded in ICD 10 and ICD 11, laboratory tests in LOINC and clinical concepts in SNOMED CT, with production use of SNOMED CT subject to the country's affiliate licence.
National reporting. Indicators are calculated from coded encounters and reported into DHIS2 as the national aggregate platform.

Every exchange is subject to the same role based access, consent for sharing and audit log that govern use of the record itself. The full list of standards is maintained on the interoperability page, and the hospital view on the hospitals solutions page. Moana's position is that the organisation that collects the data owns it, and named standards are what allow that organisation to move its data without depending on any one supplier.

Key questions for procurement

Should a ministry choose HL7 v2 or FHIR?

Both, for different purposes. Require HL7 v2 for interfaces with existing hospital systems and analysers, and FHIR R4 for exchange between organisations, applications and national data. The evidence suggests legacy messaging will remain in use for many years [12].

What should a tender say about DICOM?

Require DICOM storage and retrieval, support for DICOM Modality Worklist so that patient details reach the modality from the order, and DICOMweb services for browser based viewing and remote reporting [5][9]. Ask whether the system can work alongside an existing PACS.

Are IHE profiles necessary if a supplier supports FHIR?

Yes, where a workflow involves several systems. FHIR defines the data; an IHE profile defines which actors do what, in which order, with which standards. Ask suppliers which profiles they support and for any published integration statements [7].

How can a ministry verify interoperability claims?

Ask for a demonstration with the ministry's own test data and profiles, not a supplier's sample. Require evidence of the specific message types, FHIR resources and DICOM services named in the tender, and include acceptance testing before payment milestones.

Does interoperability remove the need for a national data governance framework?

No. Standards make exchange possible. Who may access which data, for what purpose and with what consent remains a policy decision for the ministry, which the systems must then enforce.

Sources

HL7 Version 2 product description, HL7 International, accessed 2026
FHIR R4 overview for developers, HL7 International, 2019
FHIR Version History Fact Sheet, Office of the National Coordinator for Health IT, 2021
DICOM standard home, NEMA as DICOM secretariat, accessed 2026
DICOMweb, NEMA as DICOM secretariat, accessed 2026
ISO 12052:2026 Health informatics, Digital imaging and communication in medicine including workflow and data management, International Organization for Standardization, 2026
Integrating the Healthcare Enterprise, Radiological Society of North America, accessed 2026
IHE IT Infrastructure Technical Framework, Volume 1, IHE International, accessed 2026
Scheduled Workflow integration profile, IHE International, accessed 2026
OpenHIE Architecture Specification, OpenHIE, accessed 2026
Global strategy on digital health 2020 to 2025, World Health Organization, 2021
The FHIR standard: systematic literature review of implementations, applications, challenges and opportunities, JMIR Medical Informatics, 2021
SMART App Launch implementation guide, STU 2.2, HL7 International, 2024

HL7 v2, FHIR, DICOM and IHE: which health standard does what