DocumentationSupportCosta Rica · Contact
ESENPT
Let’s talk
  • Technical
  • Organizational

IHE XDS.bCross-Enterprise Document Sharing

In short

XDS.b is an IHE profile that lets hospitals, clinics and practices share a patient's clinical documents, such as discharge summaries, reports or results, without centralizing them in a single system. Each institution keeps its documents and a common registry makes them findable. National programmes such as ELGA in Austria and Switzerland's electronic patient record use it.

Type
Implementation guide
Steward
IHE International
Current version
ITI TF Rev. 20.2
Reviewed
October 25, 2026

Explanation

What it is

Cross-Enterprise Document Sharing (XDS.b) is an integration profile in IHE's IT Infrastructure (ITI) Technical Framework. It facilitates registering, distributing and accessing clinical documents across institutions, from a private physician office to a hospital. As of October 2026, the current revision of the ITI Technical Framework is 20.2, from November 2025. IHE notes that the term XDS now refers only to XDS.b.

Affinity domain

XDS.b assumes that institutions belong to an XDS Affinity Domain: a group that has agreed to work with common policies and a shared infrastructure, such as a regional network, a national programme or an oncology network. The profile does not define those policies: each domain decides how patients are identified, how consent is obtained, how access is controlled and which document formats it uses.

Actors and transactions

ActorRole
Document SourceProduces and publishes documents (ITI-41)
Document RepositoryStores documents and returns them (ITI-43)
Document RegistryIndexes metadata and answers queries (ITI-18)
Document ConsumerFinds and retrieves documents
Patient Identity SourceFeeds patient identities to the registry (ITI-8 or ITI-44)

Metadata use the ebXML registry model. A single registry can index documents from many repositories.

Requirements often overlooked

Every XDS.b actor must be grouped with Consistent Time (CT) and with an ATNA Secure Node or Secure Application actor. ATNA is the audit and node authentication profile. Without ATNA, an implementation is not conformant.

Common misconceptions

  • XDS.b is content-neutral: it shares text, PDF, CDA documents or DICOM images, but it does not guarantee that the receiver understands the content. Content profiles and the domain define that.
  • It works within an affinity domain. To query other communities, use XCA.
  • It requires a common patient identifier in the domain, usually solved with PIX or a national identifier.
  • Transactions are SOAP web services; for lightweight or mobile clients, IHE offers MHD, a FHIR interface that can sit in front of XDS.b.

Usage examples

  1. In Austria, ELGA registers CDA documents through IHE XDS, and its "XDS Metadaten" implementation guide (version 3.0.2, July 2024) defines how the metadata are derived.

  2. In Switzerland, Supplement 1 to Annex 5 of the EPDV-EDI ordinance (issue 8, in force since 1 June 2025) sets the national extensions to XDS, XCA and ATNA for the electronic patient record.

  3. The IHE XDS-I.b profile extends XDS.b to imaging: it shares DICOM Key Object Selection manifests that point to the studies.

  4. The IHE XCA profile lets systems query and retrieve documents from other communities, which may themselves be XDS Affinity Domains.

  5. The "XDS on FHIR" option of the MHD profile turns a FHIR publication into an XDS.b Provide and Register Document Set-b transaction.

  6. A clinic's system publishes a discharge summary to the regional repository, and the family doctor finds it by querying the registry with the patient's identifier.

Relation to other terms

Relies on4

  • IHE ATNARequired

    Every XDS.b actor must be grouped with an ATNA Secure Node or Secure Application actor.

  • MPI / EMPIMedium

    XDS.b requires a common patient identifier in the affinity domain; it can be solved with an MPI (for example, via PIX) or with a national identifier.

  • CDALow

    XDS.b is content-neutral; many domains share CDA documents, but the profile does not require it.

  • HL7 v2Low

    The registry must implement Patient Identity Feed in HL7 v2 (ITI-8) or HL7 v3 (ITI-44), so it can work without HL7 v2.

Depend on this one2

  • HIEMedium

    A document-based HIE can use XDS.b; others use HL7 v2 messages or FHIR APIs.

  • IHE MHDMedium

    MHD reuses XDS metadata and can be the API to an XDS.b network (XDS on FHIR option), but it also works without one.

Sources

  1. IHE ITI Technical Framework (Revision 20.2)profiles.ihe.net
  2. IHE ITI Technical Framework Vol. 1 — Cross-Enterprise Document Sharing (XDS.b)profiles.ihe.net
  3. IHE ITI Technical Framework Vol. 1 — Cross-Community Access (XCA)profiles.ihe.net
  4. IHE — Mobile access to Health Documents (MHD)profiles.ihe.net
  5. gesundheit.gv.at — ELGA Implementierungsleitfädengesundheit.gv.at
  6. Fedlex — Ergänzung 1 zu Anhang 5 EPDV-EDI (Ausgabe 8, 2025)fedlex.admin.ch
Health interoperability glossary