Change Proposal to Reconcile XDS-I.b with XDS.b

From IHE Wiki
Jump to: navigation, search

This template is for one or two page IHE workitem proposals for initial review. To create a new proposal, first log in to the Wiki (or create an account if you don't already have one). Then create an appropriately named new Wiki page (see the editing instructions linked to "Help" at left. Then come back to this page, click "edit" above, select and copy the contents of this page and paste the contents into your newly created page.

<Delete everything in italics and angle brackets and replace with real text. This means delete the angle bracket character and the two quote marks too.>

1. Proposed Workitem: Change Proposal to Reconcile XDS-I.b with XDS.b

  • Proposal Editor: Chris Carr
  • Editor: Steve Moore
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Radiology

2. The Problem

Currently, cross-enterprise image exchange requires specialized infrastructure and transaction capabilities in consuming systems. Integrating image exchange capabilities into a health information exchange designed for other transactions requires making extensive changes to the transactions registries and repositories perform and the way they store metadata. Likewise consuming systems in image-enabled health information exchanges are required to have the ability to process and interpret a DICOM KOS object in order to be able to retrieve imaging data. These obstacles in the current environment of XDS-compliant systems, mean that health information exchanges set up to share medical documents are rarely capable of exchanging imaging information as well.

The goal of reconciling XDS-I transactions and metadata with XDS would be to facilitate the exchange of medical images and other kinds of medical documents through a single exchange.

3. Key Use Case

A health information exchange is able, through a single unified infrastructure, to provide access to medical documents and imaging information. Authorized care providers using consuming systems capable of displaying images and medical documents gain convenient access to a broader patient records.

4. Standards and Systems

Electronic health record systems, imaging systems, health information exchange infrastructure (registry/repository).

Imaging Document Source systems would use the ITI-41 Provide and Register Transaction. Imaging Document Consumer systems would use the ITI-43 Retrieve Document Set transaction. Images and reports would be sent to the Repository as part of the Submission Set, or references to the images would be included in the metadata of a Registry Stored Query using the ITI-18 transaction.

5. Discussion

IHE Radiology adapted the model of XDS to its needs a time when there the prospect of convergence between imaging systems and electronic health record systems seemed remote. It made changes to suit specific requirements of imaging based on assumptions about cost and efficiency relevant to the moment. Now the close integration of these systems seems both possible and highly advantageous. Making it to possible to access both imaging and other health documents across institutions through a single infrastructure is an immediately relevant goal.

Sending images directly to the repository does replicate storage, but it does enable other functions. There are use cases where the images may need to be available for only a short period of time. Placing the images in the repository simplifies the issue of deprecating or deleting the imaging data after a timeout period. This model also allows an imaging center to act as a push only system as are other Document Source actors. This might be attractive to some organizations that do not want to support pull requests from external systems.

Imaging Document Consumers already have the ability to perform the ITI-43 Retrieve Document Set transaction to retrieve the KOS object. It would seem that Document Repositories could be defined to support only that transaction to retrieve images, or perhaps a new Imaging Document Repository could be defined that supports both that transaction and the WADO retrieve.