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.