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.
- IHE stands for Integrating the Healthcare Enterprise. IHE is an international body that “promotes the use of established standards to address specific clinical needs in support of optimal patient care”.
- Exchange means securely providing, locating and retrieving medical records across a network.
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.
- Routine imaging Referral. The referring physician in his office requests that a patient have an examination done at an imaging facility. The physician expects to have electronic access to the imaging report and to the images if needed after the examination has been performed on his patient.
- Course of treatment referral. An emergency physician orders an imaging examination for a patient at his hospital. After reviewing the preliminary report the ER physician decides to consult a surgical specialist at the regional hospital for advice on a course of action. For this, the surgical specialist accesses the images and preliminary report and reviews them in order to propose, on the phone, a course of action for the patient.
- Clinical consult. A general practitioner performs a routine imaging referral, reviews the shared imaging report and chooses to send the patient for evaluation by a specialist (e.g., an oncologist). The specialist needs access to the imaging report and full image set produced at the imaging facility where the patient had been sent by his general practitioner to perform the examination.
- General Imaging Access Record. A patient relocates or decides to change her physician. The new physician needs to retrieve relevant information from the patient record, review its content, including recent labs and imaging studies. A similar situation occurs when a patient is admitted for an emergency and timely access to the patient’s past information is required, including prior imaging studies.
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.
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;
- A01: Inpatient admission
- A04: Outpatient registration
- A05: Inpatient preadmission
- A08: Update to an existing patient record
- A40: Patient record merge
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!