IHE Profiles in Practice: The Integration Backbone of European Healthcare Systems

Introduction

If you work in healthcare integration in the US, you primarily deal with HL7 V2 messages and FHIR APIs. In Europe, there is a third critical layer: IHE (Integrating the Healthcare Enterprise) profiles. IHE profiles are the integration patterns that power national health data exchanges in Switzerland, Austria, France, Germany, Italy, and many other European countries.

Having implemented IHE-based integrations for European healthcare projects, I find that many developers — especially those coming from a US-centric HL7/FHIR background — underestimate the complexity and importance of IHE in the European market. This article is the practical guide I wish I had when I first encountered these profiles.

What Are IHE Profiles?

IHE profiles are not standards themselves — they are implementation guides that combine existing standards (HL7, DICOM, W3C, OASIS) into specific, testable integration patterns. Each profile defines:

• Actors — the system roles involved (e.g., Document Source, Document Consumer, Document Registry)
• Transactions — the specific data exchanges between actors (e.g., ITI-41: Provide and Register Document Set)
• Content — the structure and format of exchanged data

Think of IHE profiles as recipes: they take standard ingredients (HL7 CDA, SOAP, SAML) and define exactly how to combine them for a specific use case.

The Essential European IHE Profiles

XDS.b — Cross-Enterprise Document Sharing

XDS.b is the most widely deployed IHE profile in Europe. It defines a document-centric health information exchange where clinical documents are stored in repositories and indexed in a central registry.

Architecture:

                    Document Source
                    (EHR System)
                         │
              ┌──────────┤
              │          │
              ▼          ▼
    ┌──────────────┐  ┌──────────────┐
    │   Document   │  │   Document   │
    │  Repository  │  │   Registry   │
    │  (stores     │  │  (indexes    │
    │   documents) │  │   metadata)  │
    └──────────────┘  └──────────────┘
              ▲          │
              │          │
              └──────────┤
                         │
                    Document Consumer
                    (Requesting System)

Key Transactions:

Implementation Reality:

XDS.b transactions use SOAP/XML with ebXML metadata — a technology stack that most modern web developers find unfamiliar. The learning curve is steep. A typical ITI-41 transaction involves:

1. Constructing a SOAP envelope with WS-Addressing headers
2. Building an ebXML SubmitObjectsRequest with ExtrinsicObject metadata
3. Attaching the clinical document as a MIME multipart payload
4. Signing the request with the appropriate security token (XUA/SAML)

This is why integration engines like Mirth Connect, Rhapsody, or Open eHealth Integration Platform (IPF) are essential. They handle the SOAP/ebXML complexity and let you focus on the clinical data.

PIX — Patient Identifier Cross-Referencing

PIX (Patient Identifier Cross-reference Manager) solves a fundamental problem: the same patient has different IDs in different systems. PIX maintains a cross-reference map between identifiers.

Two versions exist in European deployments:

• PIX V2 (ITI-8, ITI-9, ITI-10) — uses HL7 V2 messages
• PIX V3 (ITI-44, ITI-45, ITI-46) — uses HL7 V3/SOAP messages (used by Swiss EPD)
• PIXm (ITI-83) — the FHIR-based version, increasingly adopted

Typical flow:

Hospital A                     PIX Manager                    Hospital B
(Patient ID: H-A-12345)                                      (Patient ID: H-B-67890)
       │                            │                              │
       │  ITI-44: Patient           │                              │
       │  Identity Feed             │                              │
       │  (register H-A-12345)      │                              │
       │───────────────────────────►│                              │
       │                            │◄─────────────────────────────│
       │                            │  ITI-44: Patient             │
       │                            │  Identity Feed               │
       │                            │  (register H-B-67890)        │
       │                            │                              │
       │  ITI-45: PIX Query         │                              │
       │  "What IDs exist for       │                              │
       │   H-A-12345?"             │                              │
       │───────────────────────────►│                              │
       │                            │                              │
       │  Response:                 │                              │
       │  H-A-12345 = H-B-67890    │                              │
       │  = MPI-ID-001             │                              │
       │◄───────────────────────────│                              │

PDQ — Patient Demographics Query

PDQ allows searching for patients by demographic criteria (name, date of birth, gender). It is commonly used when you need to find a patient but do not have their local identifier.

• PDQ V3 (ITI-47) — HL7 V3/SOAP, used in Swiss EPD and other national implementations
• PDQm (ITI-78) — FHIR-based, maps to GET /Patient?family=...&birthdate=...

XCA — Cross-Community Access

XCA enables document queries and retrieval across organizational boundaries. This is what makes cross-community and cross-border health data exchange possible.

Community A                    Community B
┌──────────────┐              ┌──────────────┐
│ Initiating   │              │ Responding   │
│   Gateway    │──ITI-38──►  │   Gateway    │
│              │  (Query)     │              │
│              │◄──────────── │              │
│              │  (Results)   │              │
│              │              │              │
│              │──ITI-39──►  │              │
│              │  (Retrieve)  │              │
│              │◄──────────── │              │
│              │  (Documents) │              │
└──────────────┘              └──────────────┘

XCA is used in:

• Swiss EPD — for cross-community queries between Stammgemeinschaften
• MyHealth@EU — for cross-border health data exchange between EU member states
• French DMP — for accessing the Dossier Médical Partagé across regions
• Austrian ELGA — for the Elektronische Gesundheitsakte

MHD — Mobile Health Documents

MHD is the FHIR-based alternative to XDS.b. It provides the same document sharing functionality using RESTful FHIR APIs instead of SOAP/ebXML.

Key transactions:

MHD is designed to work alongside XDS.b — an MHD facade can sit in front of an XDS.b infrastructure, translating FHIR requests to XDS.b transactions. This is exactly how newer integrations with the Swiss EPD work.

ATNA — Audit Trail and Node Authentication

ATNA is the security profile that underpins all IHE transactions. It requires:

• Node authentication — mutual TLS between all communicating systems
• Audit logging — every transaction must generate a DICOM audit message sent to an Audit Record Repository

ATNA compliance is mandatory in virtually all European national health data exchanges. Every integration project I work on includes ATNA audit trail implementation from day one — it is not something you bolt on later.

Implementation Architecture

Here is the architecture I recommend for European healthcare integrations that need to support IHE profiles:

Your Application
       │
       ▼
┌──────────────────────┐
│   Integration Engine  │
│   (Mirth Connect /   │
│    Apache Camel IPF)  │
│                      │
│  ┌────────────────┐  │
│  │ Channel: XDS.b │  │  ◄── SOAP/ebXML handling
│  │ Channel: PIX   │  │  ◄── Patient ID resolution
│  │ Channel: PDQ   │  │  ◄── Patient demographics
│  │ Channel: XUA   │  │  ◄── SAML token management
│  │ Channel: ATNA  │  │  ◄── Audit trail
│  └────────────────┘  │
│                      │
│  ┌────────────────┐  │
│  │ MHD ↔ XDS.b   │  │  ◄── FHIR-to-XDS.b translation
│  │ PIXm ↔ PIX V3 │  │  ◄── FHIR-to-V3 translation
│  └────────────────┘  │
└──────────────────────┘
       │
       ▼
  National/Community
  Infrastructure

Key design decisions:

1. Use an integration engine — do not try to implement SOAP/ebXML directly in your application code
2. Expose FHIR APIs internally — your application talks FHIR to the integration engine, which translates to IHE transactions
3. Centralize security — SAML token management and mutual TLS in the integration engine, not scattered across services
4. Audit everything — ATNA audit messages for every transaction, no exceptions

IHE Connectathons and Testing

IHE runs annual Connectathon events where vendors test their implementations against each other. If you are building IHE-compliant systems for the European market, I strongly recommend participating. The European Connectathon (organized by IHE Europe) specifically tests the profiles used in European deployments.

Testing tools you should know:

• Gazelle — the IHE testing platform used at Connectathons
• XDStoolkit — NIST's XDS testing tools
• HAPI FHIR — reference implementation for FHIR-based IHE profiles (MHD, PIXm, PDQm)
• Open eHealth Integration Platform (IPF) — Apache Camel-based toolkit for IHE profiles

The FHIR Transition

Europe is gradually transitioning from SOAP-based IHE profiles to FHIR-based equivalents. But this transition will take years. In the meantime, you need to support both:

My recommendation: build new integrations with MHD/FHIR where supported, but maintain the ability to fall back to classic IHE profiles for legacy infrastructure. The integration engine architecture above makes this manageable.

Conclusion

IHE profiles are the practical integration layer that makes European health data exchange work. They are complex, technically demanding, and very different from the REST/JSON world most developers inhabit. But they are also well-defined, rigorously tested, and supported by a mature ecosystem of tools and vendors.

If you are entering the European healthcare market, invest the time to understand IHE profiles — they will be part of your integration architecture for years to come.

Need help implementing IHE-based integrations? I work with these profiles regularly and can help you navigate the technical complexity.