Integrating the Healthcare Enterprise (IHE)

The core of IHE's methodology. An Integration Profile is a precise, documented specification that describes how to solve a specific clinical information exchange need by orchestrating existing standards (HL7, DICOM, etc.).

• Actors: Define the functional components of a system (e.g., Order Placer, Image Display).
• Transactions: Specify the exact messages and protocols exchanged between actors.
• Options: Allow for specific, constrained variations within a profile.

For example, the Scheduled Workflow (SWF) profile defines how an order for a radiology exam flows from an ordering system to a modality and back to a PACS.

IHE's rigorous, face-to-face interoperability testing events held annually across multiple domains. Vendors test their implementations of Integration Profiles against other systems in a supervised, structured environment.

• Tests are based on detailed Connectathon test cases derived from profile specifications.
• Results are publicly documented, providing transparency for healthcare providers.
• Successful testing is a prerequisite for showcasing at the HIMSS Interoperability Showcase.

This process moves interoperability from a theoretical standard to a proven, functional capability.

The definitive, multi-volume technical documentation that defines each Integration Profile in exhaustive detail. These are the engineering blueprints for interoperability.

• Volume 1 (Integration Profiles): Clinical use cases, actors, and high-level transaction flow diagrams.
• Volume 2 (Transactions): The precise technical specification for each message, including message semantics, trigger events, and acknowledgements.
• Volume 3 (Content Modules): Defines the structure and content of clinical documents, such as those based on CDA.

These frameworks are the canonical reference for engineers implementing IHE profiles.

One of the most impactful IHE profiles, XDS defines a federated, standards-based architecture for sharing clinical documents across disparate healthcare organizations.

• Document Registry: A central index that stores metadata about documents, enabling powerful querying.
• Document Repository: A system that persistently stores the actual clinical documents.
• Document Source/Consumer: The systems that publish and retrieve documents.

XDS enables a Health Information Exchange (HIE) by allowing a clinician to locate and retrieve a patient's records from any connected source without a central database.

A pair of profiles that solve the fundamental challenge of patient identity management across different systems with disparate local identifiers.

• PIX (Patient Identifier Cross-Referencing): Queries a central manager to translate a patient's identifier from one domain to another. Essential for systems that need a known, cross-referenced ID.
• PDQ (Patient Demographics Query): Allows a system to search for a patient by demographics (name, DOB, gender) and retrieve their identifiers from all known domains. Used when the local ID is unknown.

These profiles are the backbone of the Master Patient Index (MPI) in an HIE.

The foundational security profile that establishes a baseline of trust and accountability for all other IHE transactions. ATNA defines two critical requirements:

• Node Authentication: Requires that every system (node) in the network authenticate its identity using X.509 certificates and TLS mutual authentication before any data exchange.
• Audit Trail: Mandates that every system record a standardized, syslog-based audit message for security-relevant events, including user authentication, data export, and patient record access.

This profile ensures that an interoperable network is also a secure and auditable one, a prerequisite for HIPAA compliance.