XDS-I: Blueprint for Image Exchange

Twitter icon
Facebook icon
LinkedIn icon
e-mail icon
Google icon

In 2005, Integrating the Healthcare Enterprise (IHE) published the Cross-enterprise Document Sharing for Imaging (XDS-I) integration profile, extending the capabilities of XDS by incorporating DICOM instances and providing a blueprint for image exchange among disparate institutions. Nonetheless, the will remained weak through the latter half of the decade when it came to sharing images among institutions, and few projects were mounted that employed the profile.

Six years later, health-care reform, a growing campaign to limit radiation exposure, and a federal push for interoperability in health IT have heightened interest in XDS-I and other image-sharing strategies. On December 2, 2010, at the annual RSNA meeting in Chicago, Illinois, during a session called “Image Exchange and Distribution,” Eugene Igras, president of IRIS Systems (Calgary, Alberta) delivered a high-level review of XDS-I in the context of real-world applications, including large-scale Canada Health Infoway projects.

The typical scenario that Igras lays out is quite familiar: A primary-care physician issues a request for an exam to be performed at a community hospital or a specialty center, frequently by printing a requisition on a piece of paper that is handed to the patient; the technologist at the community hospital acquires the image and stores it in the local PACS; and the radiologist sitting in a diagnostic imaging outpatient clinic (or another hospital) issues a report and stores it in that facility’s own RIS.

The images and reports sought by primary-care physicians; the prior examinations required by radiologists; and the laboratory data, medication history, patient demographics, and patient history are all available in segmented places, so making them available with the push of a single button is a complex and expensive proposition that can involve multiple interfaces.

“If you have 10 organizations involved in the provision of care, then you have 10 times nine interfaces—a very expensive enterprise to run,” Igras says. “This is part of the challenge: a complex and expensive venture.”

Apart from cost, Igras enumerates a number of other challenges: limited support for access due to the lack of a universal discovery/retrieval mechanism; difficulties in integrating diagnostic imaging records due to differences in format, semantics, and structure; the difficulty of creating a longitudinal patient record; and the limited assurance of data accuracy, relevance, comparability, and integrity.

“Care organizations store lots of information,” Igras notes. “You may have a single study that stores 256 slices. Which image is relevant to the case?”

Actors and Transactions

Igras notes that IHE, an organization formed to improve the way that we share information, has published several integration profiles that tackle sharing patients’ diagnostic imaging records, including XDR (to exchange records electronically using system-to-system messaging) and XDM (to exchange various media, such as CDs or DVDs, that contain imaging information).

XDS was first introduced in 2003 for sharing documents across a network, and XDS-I, introduced in 2005, builds on the profile to share diagnostic images, diagnostic imaging reports, key image notes and overlays, postprocessing measure-ments, presentation states, and relevant images associated with a report. XDS-I is typically used with several other profiles: Consistent Time, Audit Trail and Node Authentication, Patient Identifier Cross-referencing, and Patient Demographics Query.

Figure.The XDS-I profile uses a set of actors from the XDS profile, as well as two imaging- specific actors, to facilitate the transactions required for enterprise image and document sharing. Green denotes actions based on the HL7 standard, blue indicates DICOM, red indicates EB XML, and purple denotes HTTP Get (a WADO–HTTP based transaction designed to access DICOM objects from a Web browser using HTTP); image courtesy of Eugene Igras, IRIS Systems Inc (Calgary, Alberta).

XDS-I employs four XDS actors (see figure). The first, Document Source, is typically the publisher of the document, and it creates document descriptions (metadata) and supports the submission of document sets. Usually, there would be multiple document sources, either RIS or other repositories that store documents of all kinds. The second actor, Document Repository, is responsible for the persistent storage of documents and imaging manifests, and for their registration