Healthcare Interoperability

A Gentle Introduction to XDS-I.b

XDS-I.b is a well known standard in the imaging world that has been around for some time.  It’s a useful, way to move images between healthcare providers, but it has something of a scary reputation.  The standards are long and complex and can be quite intimidating.

I think a gentle introduction is in order.   So, let’s take a wander through the world of consumers, registries, and repositories. Hopefully, at the end all will be clear.

What is XDS.b?

To understand XDS-I.b first we must consider XDS.b, also known as the Cross-Enterprise Document Sharing profile.

XDS.b is an IHE standard for exchanging a variety of different document types across a network of independent healthcare providers. Let’s break that down a little.

XDS.b is a widely used standard in regional health networks and is supported by a large number of products.  Each year IHE holds a series of Connectathons where vendors can prove their interoperability. The results for vendors who passed testing for XDS-I.b can be found here.

What is XDS-I.b?

XDS-I.b extends XDS.b to medical imaging. Instead of just exchanging documents, institutions using XDS-I.b can exchange DICOM files, PDF reports, and CDA documents related to imaging reports. Furthermore, XDS-I.b allows for four additional use cases. I’ve copied them from the standard for reference here.

The Affinity Domain

One of the most important concepts in XDS is the idea of an “Affinity Domain”, which is defined as;

a group of healthcare enterprises that have agreed to work together using a common set of policies and share a common infrastructure

Policies within affinity domains are, in part, a political construct that exist to deal with complex issues such as patient consent and a provider’s right to access. Policies also have a technical component insomuch as the selection of standards used ensures that records stored within them are accessible and interpretable by all parties. Without policies within the affinity domain true interoperability of documents could not be achieved.

A typical affinity domain would be a federation of hospitals run by multiple different corporations who have agreed to share policies and infrastructure.


Security within the affinity domain can be handled in many ways. IHE recommends either Enterprise User Authentication (EUA) or cross enterprise user authentication (XUA) profiles.

EUA makes use of Kerberos and an HL7 standard called CCOW to exchange user identity. XUA takes this to a more modern approach by making use of SAML 2.0 assertions. Neither of these standards is required, and in fact, other schemes are acceptable if all parties agree to their use.

Patient Identity

XDS requires a well defined patient identity system. As you might suspect, using local identifiers across an affinity is a non-starter as they will inevitably collide with other insitutions. XDS uses the IHE PIX/PDQ patient identity profile to resolve these conflicts. Let’s talk about how that works.

Participants in the affinity domain are responsible for sending data through an identity feed to a central registry when certain triggers occur. In hospitals running HL7 v2 it’s typical to see patient identity events occuring in response to the following messages;

The data from these messages is stored in the PIX (Patient Identifier Cross Referrencing) manager and made available for queries using a profile called PDQ (Patient Demographics Query).  XDS.b, and consequently XDS-I.b, both make use of PDQ to lookup patients.

The basic XDS flow

Here’s a very high level diagram from IHE showing how XDS works.  As we’ll see later, XDS-I.b has some subtle differences, but this should give a decent idea of how data flows.

Populating the registry

XDS-I.b introduced the concept of the “Imaging Document Source”, a system that can produce either sets of DICOM instances (imaging files), or a CDA imaging report, or a CDA wrapped text report or a PDF report. A classic example would be a PACS within the radiology department.

Imaging document sources generate files and group them into document sets that are sent to a document repository. The repository registers its document set to one or more registries that holds metadata about the data within the repository. Note that both the registry and the repository are XDS.b constructs and XDS-I.b simply piggybacks on top.

It’s not uncommon to group the imaging document source and document repository into a single system, particularly when the source is an enterprise class system such as a medical archive. The registry is usually a separate system and is intended to hold metadata from repositories within the affinity domain.

Querying and Retrieving from the Registry

Once data has been stored in the registry and repository, how does a consumer retrieve the data? It’s actually pretty straightforward.  Here’s that diagram again – this time focus on the right side.

The document consumer (client) performs a query against the registry to get a set of metadata that can be used to find the repository hosting the data. XDS-b.I specializes the XDS-b fields to include query by date, modality, body part/anatomical region, document type, and author of the document.

The Document Consumer reaches out to the Document Repository and pulls the needed document sets. These are passed to the “Imaging Document Consumer” which talks directly with the Imaging Document Source to retrieve the actual data, including images, presentation states,, key image notes, and evidence documents.   Non-DICOM reports are typically pulled straight from the document repository without the involvement of the imaging source.


This is a very simple introduction to XDS-I.b. There’s a lot more detail in the profile and I encourage you to read it in conjunction with my explanations!