AIHealth
On-premise clinical platform with local LLMs, RAG on FHIR/DICOM data, diagnostic support, remote follow-up. Architecture designed for the MDR pathway.
Discover AIHealth →
Digital Health
Medical software development compliant with CE and MDR regulatory standards. Clinical decision support systems, AI integration in clinical workflows.
Discover →The problem IHE solves
Standards like HL7 CDA R2 and DICOM specify how to represent clinical documents and images respectively. They do not say how two or more healthcare systems belonging to different organisations — hospitals, laboratories, clinics — should exchange documents within a shared infrastructure. Between the standard and the concrete implementation there is room for a further layer: rules for orchestrating actors, services and metadata, with interoperability profiles that implementers can claim to support.
This layer is the domain of IHE — Integrating the Healthcare Enterprise — an international initiative launched in 1998 in the United States and subsequently organised into national and regional affiliates (IHE Europe, IHE Italia among others). IHE does not create new standards but publishes Technical Frameworks structured into Integration Profiles, each of which combines and constrains existing standards — HL7, DICOM, W3C, OASIS — around a use case.
Affinity Domain
The organisational concept IHE relies on is the Affinity Domain: a group of healthcare facilities that agree on shared policies (patient identification, user authentication, terminologies, consent model) and exchange documents among themselves. A typical Affinity Domain in Italy corresponds to a Region: the regional FSE is the domain, providers are the actors, clinical documents are the shared objects.
Different domains meet when documents must be exchanged across Regions, or across States in the case of cross-border services.
XDS and XDS.b
The central profile of the framework is XDS (Cross-Enterprise Document Sharing), born in the early 2000s in IHE’s ITI (IT Infrastructure) domain. The currently used version is XDS.b, which adopts SOAP transport with MTOM/XOP for binary document attachments.
The actors in XDS are:
- Document Source — the system that produces and publishes a document (a hospital HIS, a LIS, a RIS)
- Document Repository — the archive that physically stores documents, typically hosted at the provider or in a regional data centre
- Document Registry — the registry that indexes document metadata, enabling search
- Document Consumer — the client that queries the Registry and retrieves the document (an EHR, the FSE portal, a clinical viewer)
- Patient Identity Source — the authoritative source of patient identity in the domain
Standardised transactions (identified by ITI-xx codes) cover:
- ITI-41 Provide and Register Document Set-b — the Document Source publishes a document to the Repository and registers the metadata in the Registry
- ITI-42 Register Document Set-b — metadata registration when the document is already in the Repository
- ITI-18 Registry Stored Query — the Consumer queries the Registry
- ITI-43 Retrieve Document Set — the Consumer retrieves the document from the Repository
Metadata: ebXML and classifications
XDS document metadata are modelled according to OASIS’s ebXML Registry Information Model (ebRIM). Every document is an ExtrinsicObject with associated Slot, Name, Description and Classification. Classifications anchor the document to controlled vocabularies:
- classCode — document type (report, discharge letter, patient summary)
- typeCode — more specific subtype (e.g. abdominal CT radiology report)
- formatCode — technical format (CDA R2 HL7 Italia PSS, CDA R2 LDO, PDF, …)
- confidentialityCode — confidentiality level
- practiceSettingCode — practice context (cardiology, paediatrics, general practice)
- healthcareFacilityTypeCode — facility type
- eventCodeList — codes of the clinical events documented
- languageCode — document language
Each Affinity Domain publishes a Value Set for each classification: vocabulary alignment is a necessary condition for meaningful cross-provider search.
Patient identification: PIX and PDQ
XDS assumes that patient identity is unique within the Affinity Domain. Since each provider keeps local identifiers, IHE provides complementary profiles for demographic alignment:
- PIX (Patient Identifier Cross-referencing) — a Patient Identifier Cross-reference Manager keeps matches across identifiers of different domains; systems can ask “which local MPI corresponds to this regional identifier?”
- PDQ (Patient Demographics Query) — querying the patient’s demographic data
- PIX V3 and PDQ V3 — versions using HL7 v3 instead of v2; cleaner formally, less adopted in practice
FSE integration with the National Registry of Assisted Persons and with regional demographic records passes, in Italian implementations, through variants of these profiles.
XCA: between Affinity Domains
When a patient moves across Regions, document requests leave the Affinity Domain of residence and enter that of destination. The dedicated profile is XCA (Cross-Community Access):
- ITI-38 Cross Gateway Query — query through the home community gateway towards those of other communities
- ITI-39 Cross Gateway Retrieve — document retrieval through the gateway
The INI (National Interoperability Infrastructure) model run by Sogei for the Italian FSE is an application of XCA: regional FSEs talk to one another through national XCA gateways.
Security and privacy: ATNA, CT, BPPC, XUA
XDS and XCA lean on cross-cutting profiles:
- ATNA (Audit Trail and Node Authentication) — mutual TLS node authentication and RFC 3881-conformant audit trail in syslog format
- CT (Consistent Time) — NTP synchronisation of nodes for timestamp consistency in logs
- BPPC (Basic Patient Privacy Consents) — management of patient consents through a dedicated CDA document, referenced as access policy for documents
- XUA (Cross-Enterprise User Assertion) — SAML assertions on the identity of the end user originating the request, propagated between nodes
In the Italian context these profiles integrate with national mechanisms (SPID, CIE, CNS, regional operator cards) for strong authentication.
Content Profiles
On top of the XDS transport infrastructure sit Content Profiles — definitions of which documents are exchanged and how they must be structured. The most relevant:
- XDS-SD (Scanned Documents) — encapsulation of a signed PDF in a CDA R2 wrapper
- XDS-MS (Medical Summaries) — clinical summaries
- XPHR (Personal Health Records) — patient PHR documents
- XDS-I.b — sharing of DICOM imaging within the XDS frame (with a CDA manifest containing references to DICOM objects)
HL7 Italia’s Italian CDA R2 profiles — LDO, Laboratory Report, ED Report, PSS — are de facto Content Profiles adopted by regional FSEs, with the corresponding formatCodes registered in the regional Value Set.
Tools and testing
IHE conformance is verified at Connectathons: annual events (Vienna for years, now itinerant) where vendors, healthcare organisations and researchers run their systems against test tools and peer partners. The testing platform — Gazelle — is open and developed by the IHE consortium.
On the implementation side, the open source ecosystem includes:
- OpenXDS — Apache-licensed Java reference implementation of Document Registry and Repository
- IHE Profile Kit — Java libraries for implementing actors
- Gazelle Test Management — conformance testing platform
- XDS integrations in the main open source integration engines (Mirth Connect with IHE channels)
In the Italian FSE
All Italian regional FSEs adopt the IHE frame as architectural reference: XDS.b for intra-Region sharing, XCA via INI for national interoperability, PIX/PDQ for demographic alignment, ATNA for audit and security, BPPC for consent management. Italian CDA R2 profiles provide the content layer.
The model’s compactness — register metadata, keep documents where they are produced, retrieve on demand — works well for consultation use cases. It shows its limits on secondary use, analytics and integration with clinical AI — where a resource-structured model (FHIR) or an observational data model (OMOP CDM) offers clearer advantages. This is the space in which FSE evolution will move in the second half of the twenties.
References: IHE IT Infrastructure Technical Framework (profiles XDS.b, XCA, PIX, PDQ, ATNA, CT, BPPC, XUA). ebXML Registry Information Model (OASIS). OpenXDS. IHE Gazelle.