The Integrating Healthcare Enterprise (IHE) Cross Enterprise Document Sharing (XDS) profile has been widely implemented and many vendors have tested and demonstrated its functionality at the previous connectathons, however, actual deployments have been very limited. Reasons for the very sparse implementations range from infrastructure issues, to lack of detail in the specifications, and the need to specialize and customize the metadata that is used to register and maintain the documents that are managed. The underlying issue is that XDS is not merely an interface standard but, more importantly, very much a workflow profile, which means that the differences between different institutions and even more different regions or even countries make it hard to have a one-size-fits-all implementation.
This four-part discussion will attempt to examine the issues in more detail. In part one I am going to give a high level overview of the XDS, followed by the XDS-ITI relationship discussion, the discussion of the XDS family (XDR, XDM, XCA). In part four will talk about the issues that have arisen during early implementations.
XDS is an IHE integration profile that facilitates the registration, distribution, and access of electronic health records across healthcare enterprises. It provides a framework for sharing documents, which includes images between practitioners and organizations. Some of the typical use cases are the publishing of patient care summaries by healthcare providers, the access of patient records, regardless of where they are stored in case a patient is admitted to an ER, sharing relevant information between a primary physician and specialists, sharing radiology images and reports, lab results, and exchange pharmacy information.
If a system claims support for XDS, the first question to always ask is which of the possible actors is implemented. For example, a system such as a PACS can send information about its documents that are to be shared using XDS, a Vendor Neutral Archive or VNA can archive and manage documents and/or images and have an XDS interface to register it with a regional Health Information Exchange (HIE). A physician can access the HIE to search for relevant documents and pull them from a XDS compliant archive. The actors with corresponding functionality and transactions that are defined include the so-called Document Source, Repository, Registry, Document Consumer, and Patient Identity to provide unique patient identification. It is uncommon for a system to provide all of this information; most vendors use as one or more of these actors. To make sure that there are no gaps, one should map all of the actors using the vendor’s IHE integration profile definitions, which are available from the vendor.
The XDS-I, i.e. Cross Enterprise Document Sharing for Imaging has exactly the same structure, and number of actors. The difference is that the document source is an imaging document source instead and the same applies to the consumer. The transactions are obviously different as well, as we use DICOM transactions to exchange the image documents.
The transactions between the different actors are well defined in the IHE technical framework documents, for the XDS it is the ITI or IT Infrastructure framework and for the radiology it is the RAD or Rapid Application Development framework. In some cases, there are different options for the transactions, for example, there is a HL7 version 2 and version 3 option for the patient identity feed, which basically translates into a traditional ADT (Admit-Discharge-Transfer) transaction (A01, A04, A05, A08, A40) for V2 or a XML encoded one for V3. Similarly, for the image retrieval one can select the traditional DICOM WADO http URI transaction or the newer SOAP based messaging WADO version.
I like to compare XDS to an engine, which has several components, for example, it has a transmission, cylinders, alternator, etc. The same is true with XDS, it consists of several actors and all are needed to make it work. It is important to validate that all parts are present to make it work. Expanding on the engine analogy, it needs other parts such as a chassis, wheels, steering controls, etc. to make it into a fully functioning device such as a car, truck, or motorcycle. That is where the other ITI profiles play a role, such as security, patient information management, workflow, provider, personnel and content management. These will be discussed in part two. For a more extended coverage of this subject see the video.