# IHE Profiles in Practice: The Integration Backbone of European Healthcare Systems > A practical guide to the IHE integration profiles most commonly used in European healthcare — XDS.b, PIX/PDQ, XCA, MHD, and ATNA — with real implementation patterns and architecture examples. Author: Ala Ben Aicha Canonical page: https://alabenaicha.me/insights/ihe-profiles-european-healthcare-integration Updated: 2026-09-15 ## 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:** | Code | Transaction | Direction | | ------ | --------------------------------- | ------------------------------ | | ITI-18 | Registry Stored Query | Consumer → Registry | | ITI-41 | Provide and Register Document Set | Source → Repository + Registry | | ITI-42 | Register Document Set | Repository → Registry | | ITI-43 | Retrieve Document Set | Consumer → Repository | **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:** | Code | Transaction | FHIR Operation | | ------ | ------------------------ | -------------------------- | | ITI-65 | Provide Document Bundle | POST /Bundle (transaction) | | ITI-66 | Find Document Lists | GET /List?... | | ITI-67 | Find Document References | GET /DocumentReference?... | | ITI-68 | Retrieve Document | GET /Binary/{id} | 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: | Classic Profile | FHIR Equivalent | Status in Europe | | --------------- | --------------- | ---------------------------------------- | | XDS.b | MHD | Adopted in Swiss EPD, growing elsewhere | | PIX V3 | PIXm | Available, limited deployment | | PDQ V3 | PDQm | Available, limited deployment | | XCA | mXDE | Early specification phase | | XUA | IUA (OAuth2) | Emerging, SMART on FHIR gaining traction | 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.