Integrating the Healthcare Enterprise (IHE) Guide

Integrating the Healthcare Enterprise (IHE) is an international, non-profit standards-profiling initiative founded in 1998 by the Radiological Society of North America (RSNA) and the Healthcare Information and Management Systems Society (HIMSS) to eliminate implementation ambiguity across health IT systems. Rather than inventing new base data standards from scratch, IHE publishes domain-specific Technical Frameworks and Integration Profiles—such as PIX/PDQ, XDS.b, XCA, XCPD, ATNA, and MHD—that specify exactly how existing standards (including HL7 v2, HL7 v3, HL7 C-CDA, HL7 FHIR, DICOM, OASIS SAML, and W3C SOAP/ebXML) must be combined by named system Actors executing numbered Transactions.

Definition and Scope: How IHE Profiles, Actors, and Transactions Work

Base healthcare standards such as HL7 v2, DICOM, or HL7 FHIR deliberately offer broad optionality so they can support diverse global workflows. Without a coordinating implementation profile, two vendors can both claim “HL7 compliance” while remaining unable to exchange records without custom interface engineering. IHE resolves this through a three-part architectural model:

IHE Domains and Technical Frameworks: IHE organizes clinical and administrative workflows into specialized domains—most notably IT Infrastructure (ITI), Patient Care Coordination (PCC), Radiology (RAD), Cardiology (CARD), Pathology and Laboratory Medicine (PaLM), Devices (DEV), and Quality, Research and Public Health (QRPH).
IHE Actors: Functional software roles that a health IT system (such as an EHR, an Enterprise Master Patient Index [EMPI], a PACS archive, or a Health Information Exchange gateway) claims conformance to—for example, Document Source, Document Repository, Document Registry, Document Consumer, or Initiating Gateway.
IHE Transactions: Precisely constrained wire-level interactions between two Actors, identified by a domain prefix and transaction number (such as ITI-18, ITI-38, ITI-41, or ITI-65). Vendor implementations validate conformance against peer systems at annual hands-on IHE Connectathons using the open-source Gazelle test bed before claiming support in a published IHE Integration Statement.

Core IHE IT Infrastructure (ITI) Profiles Reference Matrix

The IHE IT Infrastructure (ITI) domain provides the foundational identity, document-sharing, and security backbone for regional Health Information Exchanges (HIEs) and national interoperability frameworks including Carequality, CommonWell Health Alliance, and eHealth Exchange / TEFCA:

IHE Profile Acronym & Name	Primary Purpose	Key Actors	Core Numbered Transactions	Underlying Base Standards
PIX / PIXV3 / PIXm Patient Identifier Cross-Referencing	Correlates local patient medical record numbers (MRNs) across separate affinity domains via a central cross-reference manager.	Patient Identity Source, PIX Manager, PIX Consumer	`ITI-8` (Patient Identity Feed), `ITI-9` (PIX Query), `ITI-44`/`ITI-45` (v3), `ITI-83` (PIXm FHIR `$ihe-pix`)	HL7 v2.5 (`ADT^A01/A04/A08/A40`, `QBP^Q23`), HL7 v3 XML, HL7 FHIR R4
PDQ / PDQV3 / PDQm Patient Demographics Query	Allows clinical applications to query a central MPI by demographic attributes (name, DOB, address) to retrieve matching patient IDs.	Patient Demographics Supplier, Patient Demographics Consumer	`ITI-21` (Patient Demographics Query), `ITI-47` (PDQV3), `ITI-78` (PDQm FHIR `GET /Patient`)	HL7 v2.5 (`QBP^Q22` / `RSP^K22`), HL7 v3 XML, HL7 FHIR R4
XDS.b Cross-Enterprise Document Sharing	Enables registration, indexing, and retrieval of clinical documents (C-CDA, PDF, DICOM KOS) within a single clinical Affinity Domain.	Document Source, Document Repository, Document Registry, Document Consumer	`ITI-41` (Provide & Register Document Set-b), `ITI-42` (Register Document Set-b), `ITI-18` (Registry Stored Query), `ITI-43` (Retrieve Document Set)	SOAP 1.2, OASIS ebXML Registry 3.0, MTOM/XOP binary attachments
XCPD Cross-Community Patient Discovery	Discovers whether a remote HIE community (identified by a `homeCommunityId` OID) holds records for a patient using demographic matching.	Initiating Gateway, Responding Gateway	`ITI-55` (Cross Gateway Patient Discovery)	SOAP 1.2, WS-Addressing, HL7 v3 `PRPA_IN201305UV02` / `PRPA_IN201306UV02`
XCA Cross-Community Access	Queries and retrieves clinical documents across autonomous HIE communities and national networks (TEFCA QHINs, Carequality).	Initiating Gateway, Responding Gateway	`ITI-38` (Cross Gateway Query), `ITI-39` (Cross Gateway Retrieve)	SOAP 1.2, ebXML 3.0, MTOM/XOP, `homeCommunityId` routing
ATNA Audit Trail and Node Authentication	Mandates mutual TLS (mTLS) node authentication and tamper-evident security audit logs for every ePHI access or query event.	Secure Node / Secure Application, Audit Record Repository	`ITI-19` (Authenticate Node), `ITI-20` (Record Audit Event)	TLS 1.2/1.3 (X.509 certificates), RFC 3881 / DICOM Audit Message XML over RFC 5424 Syslog, FHIR `AuditEvent`
XUA / IUA Cross-Enterprise / Internet User Assertion	Transmits authenticated clinician identity, NPI, role, and purpose-of-use (e.g., `TREATMENT`) across network boundaries.	X-Assertion Provider, X-Service User, X-Service Provider	`ITI-40` (Provide X-User Assertion), `ITI-71` (Get Access Token)	OASIS SAML 2.0 Assertions (XUA), OAuth 2.0 / OpenID Connect JWT (IUA)
MHD Mobile Access to Health Documents	Provides a lightweight HL7 FHIR RESTful API facade over XDS.b/XCA document-sharing infrastructure for mobile and web apps.	Document Source, Document Recipient, Document Consumer, Document Responder	`ITI-65` (Provide Document Bundle), `ITI-67` (Find Document References), `ITI-68` (Retrieve Document)	HL7 FHIR R4 (`Bundle`, `List`/`SubmissionSet`, `DocumentReference`, `Binary`)

How Do IHE XDS.b and XCA Support Cross-Enterprise Document Sharing?

Understanding how clinical documents flow across health systems requires distinguishing between intra-community exchange (IHE XDS.b) and inter-community federation (IHE XCPD + XCA):

1. Intra-Community Exchange With IHE XDS.b

Within a single regional HIE or health system Affinity Domain, participating hospitals share a common patient identity domain (governed by PIX/PDQ) and a centralized Document Registry (which stores searchable metadata such as patient ID, LOINC document class/type codes, service start/stop times, confidentiality code, and repository unique ID) alongside one or more distributed Document Repositories (which store the actual byte-for-byte C-CDA XML or PDF files):

Publishing (`ITI-41` & `ITI-42`): When a physician signs a discharge summary, the EHR (Document Source) sends a SOAP MTOM/XOP ITI-41 (Provide and Register Document Set-b) transaction to the Document Repository. The Repository saves the document binary, computes its SHA-1/SHA-256 hash and byte size, and forwards the metadata via ITI-42 (Register Document Set-b) to the central Document Registry.
Querying & Retrieving (`ITI-18` & `ITI-43`): An outpatient clinician’s EHR (Document Consumer) queries the Document Registry via ITI-18 (Registry Stored Query, e.g., FindDocuments) for the patient’s Affinity Domain ID. After reviewing the returned metadata list, the EHR fetches the specific document bytes directly from the holding Document Repository using ITI-43 (Retrieve Document Set) by passing the repositoryUniqueId and documentUniqueId.

2. Cross-Community Federation With IHE XCPD and XCA

At the national scale—such as across Carequality implementers, CommonWell, eHealth Exchange, and TEFCA Qualified Health Information Networks (QHINs)—no single central XDS Registry exists for the entire country. Instead, each network or health system operates a pair of Initiating and Responding Gateways identified by a globally unique OID called a homeCommunityId:

Patient Discovery (`ITI-55` — XCPD): Gateway A sends an ITI-55 demographic payload (accompanied by an ITI-40 XUA SAML 2.0 assertion declaring PurposeOfUse = TREATMENT) to Gateway B. Gateway B queries its local Master Patient Index and returns the patient’s remote identifier and Gateway B’s homeCommunityId.
Cross-Gateway Document Query (`ITI-38` — XCA): Gateway A sends an ITI-38 query to Gateway B requesting available document metadata for that patient ID.
Cross-Gateway Document Retrieve (`ITI-39` — XCA): Gateway A executes an ITI-39 call passing homeCommunityId, repositoryUniqueId, and documentUniqueId to stream the C-CDA R2.1 clinical summary back into the requesting clinician’s EHR chart.

What Is IHE MHD (Mobile Access to Health Documents)?

Because constructing SOAP 1.2 envelopes, OASIS ebXML 3.0 RIM structures, and MTOM/XOP multipart attachments is cumbersome for modern web portals, mobile health applications, and SMART on FHIR clients, IHE created the Mobile Access to Health Documents (MHD) profile. MHD maps the exact metadata model of XDS.b onto standard HL7 FHIR R4 RESTful resources:

`ITI-65` (Provide Document Bundle): The mobile or FHIR client (Document Source) executes an HTTP POST [base] with a FHIR Transaction Bundle containing a List resource (representing the XDS SubmissionSet), one or more DocumentReference resources (representing XDS DocumentEntry metadata), and the payload inside a Binary resource. A backend Document Recipient can either store those FHIR resources natively or translate the ITI-65 bundle directly into a downstream ITI-41 XDS.b SOAP call.
`ITI-67` (Find Document References): The client (Document Consumer) queries GET [base]/DocumentReference?patient=Patient/123&status=current&type=http://loinc.org|34133-9 to search document metadata without handling ebXML.
`ITI-68` (Retrieve Document): The client performs a simple HTTP GET against the URL specified in DocumentReference.content.attachment.url to download the C-CDA XML, PDF, or FHIR Document payload.

Where IHE Profiles Matter in Clinical Research and Trial Informatics

Beyond clinical care delivery, IHE profiles inside the Quality, Research and Public Health (QRPH) and Patient Care Coordination (PCC) domains standardize electronic source data capture (eSource) for clinical trials:

Retrieve Form for Data Capture (RFD): Allows an Electronic Data Capture (EDC) system (Form Filler / Form Manager) to launch a clinical trial electronic Case Report Form (eCRF) directly inside the investigator’s EHR and pre-populate it with C-CDA clinical data elements, reducing manual transcription errors under ICH E6(R3) GCP.
Clinical Research Document (CRD) and SDC: Profiles the structured capture of clinical trial screening and adverse-event forms so EHR-collected observations map cleanly to CDISC ODM and SDTM submission domains.

Common Misunderstandings About IHE

Misunderstanding 1: “IHE is a competing standard that replaces HL7 or DICOM.”Correction: IHE never creates base data formats. Every IHE transaction wraps an established standard from HL7 (v2, v3, C-CDA, FHIR), DICOM, IETF, OASIS, or W3C, constraining optionality so disparate systems interoperate out of the box.
Misunderstanding 2: “HL7 FHIR makes IHE profiles obsolete.”Correction: While FHIR provides a RESTful resource model and API specification, enterprise workflows still require multi-resource coordination profiles. IHE works directly with HL7 to publish FHIR-based profiles—including MHD (document sharing), PIXm/PDQm (patient identity matching), PMIR (Patient Master Identity Registry), and IUA (OAuth 2.0 authorization).

Frequently Asked Questions

What are IHE profiles in healthcare interoperability?

IHE Integration Profiles are detailed technical specifications published by Integrating the Healthcare Enterprise (IHE) that define how existing healthcare and IT standards (such as HL7 v2, C-CDA, HL7 FHIR, DICOM, and SAML) must be implemented to solve a specific clinical or administrative workflow problem. Each profile defines functional system roles called Actors and constrains the exact messages or API calls—called numbered Transactions—exchanged between them.

How do IHE XDS.b and XCA support cross-enterprise document sharing?

IHE XDS.b (Cross-Enterprise Document Sharing) enables healthcare organizations within a shared regional Affinity Domain to publish clinical documents to a Document Repository (`ITI-41`), index their metadata in a central Document Registry (`ITI-42`), search for available records (`ITI-18`), and retrieve documents (`ITI-43`). IHE XCA (Cross-Community Access) extends this model across autonomous health networks (such as Carequality and TEFCA QHINs) using Initiating and Responding Gateways that execute Cross-Gateway Queries (`ITI-38`) and Cross-Gateway Retrieves (`ITI-39`).

What is IHE MHD (Mobile Access to Health Documents)?

IHE MHD (Mobile Access to Health Documents) is an IHE IT Infrastructure profile that provides an HL7 FHIR RESTful API interface to XDS.b and XCA document-sharing networks. Using three transactions—ITI-65 (Provide Document Bundle), ITI-67 (Find Document References via GET /DocumentReference), and ITI-68 (Retrieve Document)—MHD allows web, cloud, and mobile applications to publish and query clinical documents using JSON/HTTP without building complex SOAP and ebXML stacks.

Sources

Integrating the Healthcare Enterprise (IHE) International. IHE IT Infrastructure (ITI) Technical Framework, Volumes 1, 2, and 3 (PIX, PDQ, XDS.b, XCA, XCPD, ATNA, XUA). https://profiles.ihe.net/ITI/TF/
Integrating the Healthcare Enterprise (IHE) International. Mobile Access to Health Documents (MHD) FHIR Implementation Guide (ITI-65, ITI-67, ITI-68). https://profiles.ihe.net/ITI/MHD/
Office of the National Coordinator for Health Information Technology (ONC / ASTP) & The Sequoia Project. Trusted Exchange Framework and Common Agreement (TEFCA) Qualified Health Information Network (QHIN) Technical Framework (QTF). https://rce.sequoiaproject.org/tefca-and-rce-resources/

Integrating the Healthcare Enterprise (IHE): Technical Frameworks, Actors & Transactions, PIX/PDQ, XDS.b, XCA, ATNA, and FHIR MHD Explained