IHE Fundamentals

IHE matters because standards alone do not guarantee interoperable workflows. HL7, DICOM, SOAP, and FHIR describe formats and transport options, but IHE profiles narrow those choices into repeatable implementation patterns.

An architect should think of IHE as a constraints-and-contract layer. A profile defines the actors that participate in a workflow and the transactions they must support, so vendors make fewer incompatible choices at integration time.

A radiology workflow is the easiest place to see why IHE exists. HL7 carries the patient and order context. DICOM handles modality worklists, image storage, retrieval, and imaging procedure state. If those two streams drift, the department ends up with patient mismatch, orphaned studies, or delayed reporting.

IHE profiles codify exactly where those transitions happen. That is why the same hospital can combine HL7 order management, DICOM imaging, and enterprise document sharing without inventing a custom integration contract every time.

The IT Infrastructure domain is the common platform layer for many IHE deployments. XDS.b governs cross-enterprise document sharing. PIX and PDQ handle patient identity and demographics. ATNA establishes secure nodes and audit expectations. MHD exposes mobile and FHIR-friendly document access on top of document-sharing concepts.

IHE document sharing is not one pattern. The profile family changes depending on whether the sender already knows the recipient, whether one community runs a shared discovery layer, or whether multiple communities keep their own infrastructure and federate through gateways.

Patient identity is a prerequisite for nearly every sharing workflow. Traditional PIX and PDQ use HL7 v2 or v3 patterns. PIXm and PDQm keep the same architectural question but expose FHIR-based transactions that are easier for browser and mobile applications to consume.