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 TransactionsIgras 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 in the third actor, Document Registry, which is basically a registry of pointers or metadata. This is where information about the documents themselves is stored. The fourth actor, Document Consumer, is the application that issues queries to find the information needed to retrieve the document. In addition, the profile uses two imaging-specific actors. The first, Imaging Document Source, is a producer and publisher of imaging documents, responsible for providing documents, metadata, and imaging manifests to the Document Repository and for supporting the retrieval of DICOM objects referenced on a published imaging manifest. The second imaging-specific actor, Imaging Document Consumer, accepts the imaging manifests and retrieves documents from the imaging document source using DICOM and WADO. Vital to trafficking, the manifest created by the Imaging Document Source is a document that identifies the author of an image, when it was captured, who the patient is, and many other data points about the image itself. The manifest is published in the Document Repository and stored as a document. Subsequently, the manifest is registered in the Document Registry, which facilitates document discovery. Document Consumer may, for instance, request all documents on a patient generated in the past six months, and the registry replies with a list of 12 items. The care provider can then choose the items that he or she wants and retrieve the manifests from the Document Repository, identifying the Imaging Document Sources where the images reside so that Document Consumer can retrieve the DICOM objects. “The system provides you with the capabilities not only to store this information—specifically, the report and the manifest in the Document Repository—but also to link them,” Igras notes. “This is critical so that you know what is linked to what: They are not stand-alone pieces.”Distributed Image and Document SharingIgras says that the architecture of XDS-I can support enterprise image sharing, as well as a document-centered health record in which the documents are stored in a persistent way. Because the source documents remain autonomous, you don’t have to push the images anywhere; you just access the data from the PACS. It uses the publish-and-subscribe method, and the registry, which Igras calls the heart of XDS-I, is based on the standard called Electronic Business Using XML. The advantages of an architecture based on XDS-I include—in addition to the fact that documents can be stored in all kinds of formats—that the architecture is scalable and that it is based on health-care, Internet, and business IT standards. “If you have a solution today composed of multiple systems, you can always add new systems or remove some of the existing systems,” Igras says. Another benefit of an XDS-I architecture is that it allows a single PACS to operate as the Imaging Document Source, effectively transforming that PACS into a superPACS. “This is practical if you have multiple (and many smaller) sites, and they have multiple PACS vendors,” Igras explains. In this scenario, the PACS are implemented in such a way that they push information to a diagnostic imaging repository, and that becomes the Imaging Document Source. “It’s a PACS on steroids; it is capable of doing extra things—more than a customary PACS does,” Igras says. “It reduces complexity and cost because, in this case, the only interface I have to implement from my consumer system is to the registry. It improves access, it facilitates the discovery and retrieval of data, it does the integration quite cleanly, and it improves the quality of information.” XDS-I is not, however, a panacea. A major interoperability issue is finding a way to integrate this document-centered system with other systems based on (or capable of) transactions that deal with discrete data. “We don’t have a good standard that embraces how to support data synchronization between local/feeder systems and the XDS-I infrastructure in a standards-based way,” he notes. “There are a number of proprietary solutions, but nothing that would be one recipe that would bring it all together.” Other issues include verifying the quality of data that have been transferred among multiple systems, lack of uniformity across terminology (an underestimated issue), and establishing policies for unaffiliated organizations that use the XDS-I infrastructure. Nonetheless, recognition of XDS-I is on the rise, with more than 30 health IT vendors fully or partially supporting the profile at present, Igras says.