IHE Explained: How HL7, DICOM and FHIR Are Actually Combined in Real Workflows

Oct 13, 2023 | Updated on Sep 20, 2026

Introduction

This article sits at the junction of my HL7 and DICOM series. I first wrote it in 2023 as a short overview, and it has always bothered me that it explained why IHE exists without ever showing you what an IHE profile actually looks like. So this is a rewrite for 2026: the same purpose, but with the vocabulary, the diagrams and the practical detail an engineer needs before opening a Technical Framework for the first time - including the FHIR-based profiles that did not feature much in the original.

Who this is for: developers, integration engineers, analysts and architects who already have a rough idea of what HL7 and DICOM are and who keep meeting acronyms like SWF, XDS, PIX or ATNA in vendor documentation, RFPs and conformance claims. If you have not read them yet, my introductions to HL7 v2 and DICOM are the natural prerequisites; my FHIR basics article helps but is not required.

The short version

IHE is not a standard. It is an organisation, and a method, for saying precisely how existing standards (HL7 v2, DICOM, FHIR, CDA, SOAP, OAuth...) should be combined to make a specific clinical workflow work end to end.
The unit of output is the Integration Profile. A profile names the actors (roles that systems play), the transactions between them (numbered, e.g. [RAD-5], [ITI-18]), and which underlying standard each transaction uses.
Profiles are grouped into domains - Radiology, IT Infrastructure, Cardiology, Pathology and Laboratory Medicine, Patient Care Coordination, Pharmacy and several more - each of which publishes a Technical Framework.
Vendors prove their implementations at annual Connectathons and then publish an Integration Statement listing exactly which actors and profiles a product supports. That statement, not the marketing sheet, is the document to read.
Two profiles account for most of what you will meet: Scheduled Workflow (SWF), which is the radiology order-to-image workflow, and Cross-Enterprise Document Sharing (XDS), which is how documents and images are shared between organisations. Both now have FHIR-flavoured relatives.

“Alone we can do so little; together we can do so much.” ~ Helen Keller

What IHE Is - and What It Is Not

Integrating the Healthcare Enterprise was started in 1998 by the Radiological Society of North America (RSNA) and the Healthcare Information and Management Systems Society (HIMSS). The trigger was a very specific frustration. By the late 1990s both HL7 and DICOM were mature, and yet a hospital that bought a "DICOM conformant" scanner, an "HL7 conformant" radiology information system and a "DICOM conformant" archive from three vendors still could not reliably get a scheduled patient's images to show up under the right order with the right identifiers. Each product was conformant. The combination did not work.

The reason is that both standards are deliberately broad. HL7 v2 leaves nearly every field optional and offers several ways to say the same thing; DICOM defines dozens of services without saying which of them a scanner and an archive should use together, or in what order. Neither standard says who generates the Study Instance UID, or whether the accession number goes in the DICOM header, or what the archive should do when the patient's name is corrected after the images have been stored. Those are integration questions, and no single standards body owned them.

IHE's answer was to get clinicians, vendors and IT people in the same room, pick a real workflow, and write down - unambiguously - which standard, which message, which fields, in which sequence. The result is called an Integration Profile. The first one, Scheduled Workflow, was demonstrated at RSNA in 1999 and is still the backbone of every radiology department. From radiology the method spread to IT infrastructure (document sharing, patient identity, security), cardiology, laboratory, pharmacy, devices, eye care, dental, radiation oncology and public health.

So when a vendor says a product is "IHE compliant", the correct follow-up question is always: which profiles, as which actors? There is no such thing as being generically IHE compliant, in the same way that there is no such thing as a generic HL7 interface.

The Vocabulary: Domains, Profiles, Actors, Transactions

Almost everything confusing about IHE documentation becomes clear once you know five words. I will use Scheduled Workflow's most famous transaction - the scanner asking the RIS what is on its schedule - as the running example.

Domain

A clinical or technical area with its own committee and its own Technical Framework. The two you will meet first are Radiology (RAD) - the original domain - and IT Infrastructure (ITI), which owns everything that is not specific to a specialty: patient identity, document sharing, security, audit, time synchronisation, provider directories. The others are Cardiology (CARD), Pathology and Laboratory Medicine (PaLM), Patient Care Coordination (PCC), Pharmacy (PHARM), Devices (DEV), Radiation Oncology (RO), Quality, Research and Public Health (QRPH), Eye Care, Dental and Endoscopy. The transaction prefix tells you the domain: RAD-5 is a Radiology transaction, ITI-18 an IT Infrastructure one.

Integration Profile

A named solution to one integration problem: "get a scheduled patient's images from the scanner to the archive with the right identifiers" (Scheduled Workflow), "share a clinical document with another organisation" (XDS), "find the same patient across two identifier domains" (PIX). Each profile has a short code - SWF, XDS.b, PIX - and that code is how it is referred to everywhere. A suffix like .b means the profile was re-issued with a revised set of transactions and the original (.a) was retired; SWF.b moved the HL7 side from v2.3.1 ORM messages to v2.5.1 OMG/OMI, and XDS.b replaced the original SOAP 1.1 transactions with SOAP 1.2 and MTOM. There are also Content Profiles, which say nothing about transport and only define what goes inside a document - the CDA or FHIR template for a discharge summary, for example.

Actor

A role a system plays within a profile. Order Placer, Order Filler, Acquisition Modality, Image Manager, Document Registry, PIX Consumer. This is the most important word of the five, and the one that most often trips people up, because an actor is not a product. A single RIS is typically both the Order Filler and the Performed Procedure Step Manager in SWF, and a PACS is usually both the Image Manager and the Image Archive. Conversely a large EHR may claim a dozen actors across half a dozen profiles. When you read a vendor's IHE Integration Statement, what you are reading is a list of actors.

Transaction

A specific exchange between two actors, numbered within its domain and fully specified in Volume 2 of the Technical Framework: the trigger, the message, the required fields, the expected response and the error handling. [RAD-5] Query Modality Worklist is a DICOM C-FIND against the Modality Worklist SOP class. [ITI-18] Registry Stored Query is a SOAP call carrying an ebXML query. [ITI-65] Provide Document Bundle is a FHIR transaction Bundle POST. Every transaction rests on an existing standard; what IHE adds is the constraint - these attributes are required, this is the matching key, this value set applies.

Option

Named, optional behaviour within a profile that an actor may declare support for, so that two implementations of the same actor can differ in a controlled way. Options appear in Integration Statements next to the actor. Grouping rules also exist: some actors are only meaningful when grouped with others, for instance nearly everything in ITI is expected to be grouped with the Secure Node actor from ATNA.

Where it is all written down

Each domain's Technical Framework is split into volumes. Volume 1 describes the profiles - use cases, actor diagrams, which transactions are required for which actor, options. Volume 2 specifies every transaction in detail. Volume 3 holds content modules and cross-transaction specifications (document metadata, CDA templates), and Volume 4 holds national extensions. New profiles are published first as supplements - separate PDFs - and only later folded into the framework. The FHIR-based profiles are increasingly published as FHIR Implementation Guides at profiles.ihe.net rather than as PDFs, which is much easier to navigate. Start with Volume 1 of the domain you care about; it is written for humans.

One Profile, End to End: Scheduled Workflow

Scheduled Workflow is the profile everyone in imaging knows, and the clearest example of what IHE adds on top of the raw standards. I walked through the underlying HL7 and DICOM traffic in the DICOM introduction and in more depth in how HL7, DICOM and IHE come together. Here is the same workflow drawn the way the Radiology Technical Framework draws it: as actors and numbered transactions.

Read the diagram left to right and top to bottom and you have the whole story. The ADT actor announces the patient (RAD-1). The Order Placer - the physician's ordering system - sends the order to the Order Filler, which in radiology is the RIS (RAD-2), and the RIS confirms or amends it (RAD-3). The RIS schedules the procedure and tells the Image Manager - the PACS - to expect it (RAD-4). The Acquisition Modality pulls its worklist from the RIS (RAD-5), reports that the procedure step has started and completed (RAD-6, RAD-7 - the DICOM MPPS service, sent to both the RIS and the PACS), stores the images (RAD-8) and asks the PACS to commit to keeping them (RAD-10). The Image Display queries and retrieves them for reading (RAD-14, RAD-16).

None of those transactions is new. RAD-5 is plain DICOM Modality Worklist; RAD-8 is plain C-STORE; RAD-2 is a plain HL7 order. What the profile contributes is the connective tissue that neither standard specifies:

Who mints the identifiers. In SWF the Order Filler generates the Accession Number, the Requested Procedure ID and - crucially - the Study Instance UID, and delivers them in the worklist. Left to itself a scanner would generate its own Study Instance UID, and the RIS would have no way to link the images to the order except by fuzzy matching on patient name and time. This single rule is the reason a report in the EHR can open the right study in the PACS.
Which fields must be populated where. SWF states that the Accession Number goes into DICOM (0008,0050), that the Scheduled Procedure Step ID goes into the Request Attributes Sequence, which HL7 OBR and ORC fields they came from, and which character set rules apply.
What happens when things change. A patient is registered under a temporary ID in the emergency room and later merged; a procedure is cancelled after the scanner has already picked it up; an order is modified. SWF specifies RAD-12 Patient Update and RAD-13 Procedure Update and says which actors must act on them. Its companion profile Patient Information Reconciliation (PIR) covers the harder case where the images were acquired before the patient was properly registered - the unconscious trauma patient - and must be reconciled afterwards.
Status visibility. MPPS (RAD-6/7) is optional in DICOM. SWF makes it a required part of the workflow, so that the RIS can show that the exam is in progress, and the PACS can tell whether a study is complete before a radiologist opens it.

If you write code against a modality worklist or MPPS - my Java (worklist, MPPS) and .NET articles do exactly that - you are implementing RAD-5, RAD-6 and RAD-7, whether or not anyone calls them that.

Scheduled Workflow lives inside one department. The second profile family you will meet solves the opposite problem: sharing a document - a discharge summary, a lab report, an imaging study - between organisations that do not share a database, a patient identifier or a vendor. That is Cross-Enterprise Document Sharing (XDS.b), from the IT Infrastructure domain, and it is the foundation of most regional and national health information exchanges built in the last two decades.

The design is a deliberate separation of metadata from content. A Document Source submits a document and its metadata - patient ID, document type, author, creation time, confidentiality code, format - to a Document Repository (ITI-41). The repository keeps the bytes and forwards only the metadata to the Document Registry (ITI-42). A Document Consumer searches the registry (ITI-18) and, once it has found what it wants, retrieves the document from whichever repository holds it (ITI-43). The registry is small and central; repositories can be many and distributed - each hospital can keep its own documents while the region shares one index. A Patient Identity Source - usually the regional master patient index, itself an IHE PIX Manager - tells the registry which patient identifiers are valid (ITI-8).

The imaging extension, XDS-I.b, is the part of the original version of this article that I got wrong, so it is worth being precise. It does not convert images into documents, and the images do not move into the repository. Instead the PACS, acting as Imaging Document Source, publishes a small DICOM Key Object Selection (KOS) object - a manifest listing the Study, Series and SOP Instance UIDs and where they can be retrieved from. The manifest is what goes through ITI-41. A consumer that finds it in the registry reads the manifest and then fetches the actual images directly from the PACS, using RAD-69 Retrieve Imaging Document Set or, increasingly, DICOMweb WADO-RS. The radiology report, being an ordinary document, is shared as a plain XDS document alongside it.

XDS.b is built on ebXML Registry, SOAP 1.2, MTOM and WS-Addressing - a stack that made sense in 2005 and is heavy by today's standards. Its FHIR-based successor, Mobile access to Health Documents (MHD), maps the same four actors and four transactions onto FHIR DocumentReference, List and Binary resources over plain HTTPS (ITI-65 to ITI-68). MHD was designed so that it can sit as a facade in front of an existing XDS infrastructure, which is how most deployments use it: the region keeps its XDS registry and repositories, and mobile apps and modern EHRs talk to it through MHD. For sharing between communities that each have their own XDS, Cross-Community Access (XCA) adds gateway actors that federate the query and retrieve (ITI-38, ITI-39), with XCPD (ITI-55) to discover which community knows the patient. The US nationwide networks (Carequality, eHealth Exchange and now TEFCA) and the EU's MyHealth@EU cross-border service all run on XCA and XCPD at their core.

The Profiles You Will Actually Meet

IHE has published well over a hundred profiles. In practice a relatively small number account for nearly everything you will see in RFPs, conformance statements and integration projects. This table is the cheat sheet I wish I had had.

Profile	Domain	What it solves	Standards underneath
SWF / SWF.b Scheduled Workflow	RAD	Radiology order → worklist → images → archive, with consistent identifiers	HL7 v2 ADT/ORM (SWF) or OMG/OMI (SWF.b); DICOM MWL, MPPS, C-STORE, Storage Commitment, Q/R
PIR Patient Information Reconciliation	RAD	Fix up images acquired before the patient was properly registered (trauma, unidentified patients)	HL7 v2 ADT, DICOM
XDS-I.b Cross-Enterprise Document Sharing for Imaging	RAD	Share imaging studies across organisations by publishing a manifest	DICOM KOS + XDS.b; RAD-69 / WADO
WIA Web-based Image Access	RAD	Query and retrieve images over HTTP	DICOMweb (QIDO-RS, WADO-RS)
IID Invoke Image Display	RAD	Launch a viewer on a given patient or study from the EHR	HTTP URL launch
REM Radiation Exposure Monitoring	RAD	Collect dose information from modalities into a registry	DICOM Radiation Dose SR
AIR / AIW-I AI Results / AI Workflow for Imaging	RAD	Get AI-generated findings and segmentations into the PACS and worklists	DICOM SR, SEG, UPS
XDS.b Cross-Enterprise Document Sharing	ITI	Publish, index and retrieve documents across organisations	ebXML Registry, SOAP 1.2, MTOM
MHD Mobile access to Health Documents	ITI	The same document sharing over a REST API	FHIR DocumentReference, List, Binary
XCA / XCPD Cross-Community Access / Patient Discovery	ITI	Federate document query and patient lookup across separate communities	SOAP gateways over XDS-style queries
PIX / PIXm Patient Identifier Cross-Referencing	ITI	Given patient ID 123 in domain A, what is the ID in domain B?	HL7 v2 ADT + QBP/RSP (PIX); FHIR Patient `$ihe-pix` (PIXm)
PDQ / PDQm Patient Demographics Query	ITI	Search for a patient by name, DOB, etc.	HL7 v2 QBP^Q22 (PDQ); FHIR Patient search (PDQm)
PAM Patient Administration Management	ITI	Feed patient identity and encounter (ADT) events between systems	HL7 v2.5 ADT
ATNA Audit Trail and Node Authentication	ITI	Mutual TLS between nodes; a standard audit record for every access	TLS, syslog, DICOM audit message schema (PS3.15)
CT Consistent Time	ITI	All nodes agree on the time to within a second, so audit trails and timestamps line up	NTP
XUA / IUA Cross-Enterprise / Internet User Assertion	ITI	Carry the identity of the user making a request	SAML 2.0 (XUA); OAuth 2.0 / OpenID Connect (IUA)
BPPC Basic Patient Privacy Consents	ITI	Record a patient’s consent and enforce it on document access	CDA consent document + XDS metadata
DSUB Document Metadata Subscription	ITI	Notify me when a new document appears for this patient	WS-BaseNotification
mCSD Mobile Care Services Discovery	ITI	Directory of organisations, locations, practitioners and services	FHIR Organization, Location, Practitioner
LTW / LAW Laboratory Testing / Analytical Workflow	PaLM	Lab orders and results between the LIS and the analyzer	HL7 v2 OML/OUL
CATH / ECHO / STRESS	CARD	Cardiology equivalents of Scheduled Workflow	HL7 v2, DICOM
DEC / ACM Device Enterprise Communication / Alert Communication Management	DEV	Get vital signs and alarms from bedside devices into the EHR	HL7 v2 ORU, IEEE 11073 nomenclature
HMW / CMPD Hospital / Community Medication Workflow	PHARM	Prescription, validation, dispense and administration	HL7 v2, CDA
IPS International Patient Summary	PCC	A minimal, cross-border patient summary	HL7 FHIR IPS / CDA

Notice how many of the ITI profiles come in pairs - PIX and PIXm, PDQ and PDQm, XDS and MHD. The lower-case m originally stood for "mobile" and today simply means "the FHIR version". They are designed to interoperate with their older siblings, and in most real deployments both exist side by side: the hospital's core systems speak the v2 and SOAP versions, and the FHIR versions are exposed for apps and partners. If you are starting a new project in 2026, learn the FHIR versions first, but expect to meet the originals at the boundary with any established system.

From Profile to Product: Trial Implementation, Connectathon, Integration Statement

IHE's process is at least as important as its documents, because it is the process that makes "IHE compliant" mean something.

A profile begins as a proposal to a domain's planning committee - typically from a vendor, a hospital or a national body with a concrete problem. If accepted, the technical committee writes a supplement, which is published for public comment and then, after revision, for trial implementation. At that point vendors are invited to build it. The first real test is the Connectathon: a week-long event (there is one in North America, one in Europe, and others in Japan, Australia, China and elsewhere) at which vendors bring their systems and test every transaction they claim against other vendors' systems, supervised by neutral monitors using the Gazelle test platform. Results are published per product, per actor, per profile. A profile that has been implemented and tested successfully is promoted to final text and merged into the Technical Framework; one that turns out to have problems is revised - which is where the .b suffixes come from. Some profiles, including several in active daily use, have remained in trial implementation for years; this is normal and not a sign of immaturity.

The document that matters at purchase time is the vendor's IHE Integration Statement: a short, formally structured declaration that product X version Y implements actors A, B and C of profiles P and Q with options O. Read it the way you would read a DICOM conformance statement, and read it alongside one. The Integration Statement tells you the product claims to be a Document Consumer; the conformance statement tells you which SOP classes and transfer syntaxes it will actually accept when it gets there. IHE maintains a Product Registry where vendors publish these and where Connectathon results can be searched. IHE Europe additionally runs a formal Conformity Assessment scheme, which is closer to a true certification, and several national programmes reference it.

The Parts Nobody Warns You About

Everything above is what IHE says. Here is what implementing and procuring against it teaches you.

"IHE compliant" is per actor, per profile, per version

A product that is a conformant Image Manager in SWF may be nothing at all in XDS-I. A product that is an XDS Document Consumer may not be a Document Source. When you write a requirement, name the profile, the actor and the options; when you read a claim, look for the Integration Statement and the Connectathon result, and check that the version tested is the version being sold.

National extensions change the rules

National deployment committees - IHE USA, IHE Europe and its member countries, IHE Canada, IHE Japan and others - publish extensions (Volume 4 of the Technical Framework) that constrain or modify the international profiles for local identifiers, code systems, languages and privacy law. A German XDS deployment and an Ontario one use the same transactions but different metadata value sets, and a product tested at the North American Connectathon may not have been tested against the extension you need. Ask which national extension a claim covers.

Profiles overlap, and the newer one is not always the right one

MHD and XDS solve the same problem; so do PIX and PIXm, WIA and XDS-I. The FHIR versions are easier to build against, but the installed base runs the older ones, and a regional exchange that took ten years to build on XDS is not going to be replaced because a new profile exists. The right architecture is usually a facade: FHIR profiles on the outside, the established ones underneath. Budget for both.

Security profiles are assumed, not optional

Nearly every ITI profile expects its actors to be grouped with ATNA's Secure Node and with Consistent Time, and a real deployment will also need XUA or IUA to carry user identity and BPPC or a successor for consent. These are rarely mentioned in the use-case description of the profile you are actually interested in, and they are where most of the effort goes on a first project: certificates, mutual TLS, audit message formats, NTP on every node, and an audit repository that someone will actually look at. Regulations such as HIPAA in the US, PIPEDA and provincial health privacy acts in Canada, and GDPR in Europe are what make these non-negotiable.

IHE does not fix ambiguity in the standards underneath

SWF says the Accession Number goes in (0008,0050). It does not say what to do when the RIS sends a sixteen-character accession number and DICOM allows sixteen, but the modality vendor truncates to twelve. It does not say how to handle a middle name with a hyphen that HL7 escapes one way and DICOM another. Real IHE projects still involve interface specifications, sample messages and a validator - everything I described in the HL7 article - and they involve DICOM troubleshooting. IHE narrows the search space dramatically; it does not eliminate it.

The documents are long, but Volume 1 is short

The ITI Technical Framework runs to well over a thousand pages across its volumes and has intimidated many people into not reading it. Do not start with Volume 2. Read the Volume 1 chapter for the profile you need - typically fifteen to thirty pages, with the actor diagram, the use cases and the actor-to-transaction table - and only then open the transaction sections you are implementing. For the FHIR-based profiles, the implementation guides at profiles.ihe.net are far easier to navigate and include example resources.

IHE, HL7, DICOM and FHIR: Where Each One Lives

Engineers new to this field regularly ask whether IHE competes with HL7 or DICOM, or whether FHIR makes IHE unnecessary. It does not compete, and FHIR has if anything given it more to do. The four organisations sit in different layers.

	HL7 International	DICOM (NEMA / MITA)	IHE International
What it is	A standards development organisation	A standards development organisation	An initiative of clinical societies and vendors that profiles the standards
What it publishes	HL7 v2, v3, CDA and FHIR - the message and resource formats for clinical and administrative data	The DICOM standard - image and object formats, network services, DICOMweb, security profiles, audit schema	Integration Profiles and Technical Frameworks - which standard to use, which fields, in which sequence, for a named workflow
What it does not say	How a message relates to a DICOM study; which transactions make a workflow	What HL7 message should trigger a worklist entry; how to share a study with another hospital	Anything about the format of the data - it always defers to HL7, DICOM or another standard
Conformance	Conformance profiles; FHIR implementation guides and validators	Conformance statement per product, self-declared	Connectathon results and Integration Statements; Conformity Assessment in Europe
Where you meet it	Every interface engine; every FHIR API	Every scanner, PACS and viewer	RFPs, procurement, regional exchanges, national infrastructures, vendor claims

FHIR has changed IHE's work rather than reduced it. HL7 defines the FHIR resources; IHE defines how to use them for document sharing (MHD), patient identity (PIXm, PDQm), provider directories (mCSD), and a growing list of imaging and public-health workflows, publishing them as FHIR Implementation Guides. The two organisations collaborate formally - the joint Gemini projects and the shared FHIR tooling are examples - and many national FHIR programmes, including the pan-Canadian and European ones, cite IHE profiles by name. Meanwhile DICOM and IHE Radiology remain so closely intertwined that they hold joint meetings: DICOMweb's RESTful services were designed in parallel with the IHE profiles (WIA, MHD-I) that use them.

Where to Go Next

This article is the map. From here, depending on what you are trying to do:

See the workflow in code: how HL7, DICOM and IHE come together follows one radiology exam through every SWF transaction, and the Java (Modality Worklist, MPPS, Storage Commitment) and .NET articles implement the DICOM side of it.
The standards underneath: my introductions to HL7 v2, DICOM and FHIR, and DICOM and FHIR for how ImagingStudy and DICOMweb fit together.
The wider landscape: chapter 10 of my healthcare standards tutorial places IHE next to the other standards bodies and regulatory frameworks.
The source: the Technical Frameworks, the FHIR-based profiles, the full profile list, and the IHE wiki, which is often the quickest way to find a profile's one-page summary.
Test yourself: the IHE interactive quiz covers the material above and goes deeper into the individual profiles by domain.

If you work with healthcare software, or with standards such as HL7, FHIR or DICOM, and want to compare notes with other engineers doing the same, join the discussion in my LinkedIn group on healthcare interoperability engineering - questions, war stories and lessons learned welcome.