Add Image Repository to SWF/XDS-I - Detailed Proposal

1. Proposed Workitem: Diagnostic Imaging Repository Actor

• Proposal Editor: David Heaney, David.Heaney@mckesson.com
• Domain: Radiology

Summary

The existing Radiology Technical Framework Profiles do not specify what Profiles a regional Diagnostic Imaging Repository (DI-r) should support or how such a system should actually support them. This makes it difficult for both prospective buyers of such systems and implementers to know what Standards related features should be supported and how.

IHE already leverages the existing HL7 and DICOM Standards to define how a local PACS, Image Manager/Archive, should manage Scheduled Workflow. In addition, XDS-I makes it clear how XDS infrastructure can be used to federate existing local PACS. However these existing Profiles do not make it clear how a DI-r should support these existing Profiles and the corresponding Standards they are based on.

This Work Item proposes to solve these issues by modifying the existing IHE SWF and XDS-I Profiles so that contain a new DI-r Actor. New Transactions would be added between the appropriate existing Actors of these Profiles and the new DI-r Actor.

Canada Infoway has expressed interest in assisting with the development of this work as it would assist in the mapping of the Infoway blueprint for diagnostic imaging to the IHE Profiles that they have specified as being approved for use in deploying systems based on this blueprint.

IHE would be a good venue for solving these problems as one of the main purposes of IHE is to simplify the purchasing decisions for customers. Currently a customer wishing to deploy a DI-r type of solution cannot refer to particular IHE Profiles that must be supported by such a system because it is not clear which Profiles such a system should support or how it should support them.

2. The Problem

Enterprise and regional long term archives for diagnostic imaging are being deployed. Such architectures involve transactions between local PACS and a regional long term archive, with both types of systems normally being considered Image Manager/Archive 'actors'.

However, none of the existing IHE Profiles define transactions between Image Manager/Archives and they also do not clearly describe the role of such a DI-r Actor. It is also not clear which Profile Actors should be supported by the local PACS as opposed to the DI-r. For example, does the DI-r have to support Scheduled Workflow transactions, and if so as what Actor and how should it manage the multiple ordering 'contexts'? The existing IHE SWF Profile really assumes that there is a single patient id assigning authority and ordering system but the DI-r will most likely have to handle many such patient and ordering contexts. In addition, the XDS-I Profile does not make it clear which Actors the local PACS and the DI-r should actually support when they are part of an XDS-I Infrastructure.

Vendors are running into issues when trying to deploy such systems, or integrate their local PACS products.

3. Key Use Case

A group of hospitals each have local PACS, and possibly other dedicated Image Managers for Mammography, Cardiology, etc.

The PACS systems are in turn connected to a regional Diagnostic Imaging Repository (DI-r), that is used as the common long-term archive location for all imaging data. The local PACS typically maintain only a limited cache of recent diagnostic Studies, relying upon query-retrieval of previously flushed Studies from the DI-r. In addition, some small imaging centers and clinics may not have any local PACS at all. Instead their modalities send directly to the DI-r, and these images are accessed for diagnostic review. There is thus the need to handle scheduled workflow coordination between the local systems and the DI-r.

In addition, the DI-r is often to be integrated with an XDS Infrastructure in order to facilitate the cross-enterprise exchange of such diagnostic imaging data. An XDS Affinity Domain may incorporate multiple DI-r's and Consumer systems, such as the local PACS, need to also act as XDS-I Consumers so they can access all imaging data, not just the particular DI-r that they are archiving to.

4. Standards & Systems

DICOM

HL-7

IHE Cross-enterprise Document Sharing for Imaging (XDS-I)

IHE Scheduled Workflow (SWF)

5. Technical Approach

A lot of experience has been gained by those working on deploying such regional archives, both in connecting them with local PACS and also with integrating them into XDS-I based infrastructure. Such knowledge can be leveraged to define exactly which Profiles and Actors such a regional archive should support.

Extension of Scheduled Workflow

Experience from Canadian DI-r deployments (based on the Infoway blueprint) have shown that support for HL7 transactions is required so that the data in the DI-r can stay reasonably synchronized with the data and status of scheduling systems. Relying purely on the header information from archived DICOM objects is not adequate. For this reason it is proposed to add a new Diagnostic Imaging Repository Actor to the existing Scheduled Workflow Profile. This will require the addition of new Transactions, between this new DI-r Actor and the existing DSS/Order Filler, and Imaging Manager/Archive Actors. Given the possible deployment architectures I would also argue that it is necessary to add Transactions between the DI-r and Acquisition Modality, Performed Procedure Step Manager, Evidence Creator, and Image Display. It might be better to actually create a new 'local' Actor (that could also be either an Imaging Manager/Archive, Acquisition Modality, Evidence Creator, or Image Display) and define the new Transactions that must be supported between such a local Actor and the DI-r.

An argument can be made that the DI-r is just another 'type' of Image Manager/Archive and thus there just needs to be some clarifications or extensions added so that Image Manager/Archive to Image Manager/Archive transactions are supported. However, there is a critical difference in that the existing Scheduled Workflow Transactions assume that there is a single enterprise involved. As a result of this there is no mandatory requirement to explicitly identify the Assigning Authority of a Patient ID or of a Study identifier. This will often not be the case for a DI-r Actor so simply specifying the use of the existing Transactions will not be sufficient. For example, I would argue that the new DI-r Actor should support Transactions that are very similar to the existing Query Images and Retrieve Images Transactions supported by the existing Image Manager/Archive system but that it should be mandatory for the DI-r to return the Issuer of Patient ID in these Transactions.

Extension of XDS-I

The existing XDS-I Profile makes it very clear how an existing local PACS should integrate with XDS infrastructure, as an XDS-I Source and Consumer. However it is not explicitly clear how a DI-r or local PACS archiving to it should integrate using XDS-I. Experience from DI-r deployment, particularly from Canadian deployments, has demonstrated that support for XDS-I by such systems is being implemented in a very specific manner and it is felt that it would be useful to leverage this experience to update the XDS-I Profile accordingly.

Essentially, all DI-r systems are being deployed as XDS-I Sources, usually as combined XDS-I Source/Repositories although I don't think it is necessary (or advisable) to mandate the latter. So the XDS-I Profile would be extended to explicitly deal with how a DI-r should support XDS-I and also detail the manner in which local systems connecting to the DI-r, such as a local Image Manager/Archive PACS, must interact. Similarly to the extensions to SWF, I feel that some changes to make the sending of Patient ID Assigning Authority mandatory in DICOM Transactions should be considered.

Recent experience has shown that the existing language in the XDS Profile regarding the Patient ID value to be sent by an XDS Source is causing some confusion among implementors and we may want to take this opportunity to address this issue as well.

Breakdown of tasks that need to be accomplished

Extension of Scheduled Workflow

• Define new Diagnostic Imaging Repository (DI-r) Actor
• Update SWF Diagram and Actor/Transaction Tables with new DI-r Actor and Transactions
• Modify existing Transactions and/or add new ones where appropriate for Transactions between DI-r and other Actors

(i.e. Modify existing Retrieve Images [RAD-16] Transaction, or create a similar one based on it) to support the DI-r Actor and mandate the use of the Issuer of Patient ID attribute)

Extension of XDS-I

• Update Use cases to make it clear how a DI-r would integrate into an XDS-I based infrastructure
• It is not clear to me if any existing XDS-I Transactions need to be modified but it may be necessary, or advantageous, to do so in order to address patient context related issues.

6. Support & Resources

The IHE Canada sponsored XDS Implementation Group has already spent a lot of time and effort discussing the issues involved with this proposal. A number of members have expressed interest in assisting with the development of this Work Item and there is also the possibility that Canada Infoway may directly assist as well.

7. Risks

There is the potential risk that key philosophical differences about exactly which Transactions should be supported and how could slow the extension of these Profiles.

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

• Talking about putting the DI-r in the SWF map, need to decide whether it just talks to the Image Manager or also to other actors, and whether it just gets image transactions or also the order management and PIR

• Key question is whether the DI-r can't be a dumb archive, but instead has to be a "full fledged" Image Manager

9. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• 25%
  • (new actor, new option in one profile, clarifying XDS-I)

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA