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. Discussion

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.

For example, one fundamental decision would be whether a regional archive should be 'DICOM only' or also support HL7-based Scheduled Workflow transactions. I believe experience from Canadian deployments (based on the Infoway blueprint) have shown that support for HL7 transactions is required.

This Work Item is certainly related to the Object Change Management and Data Retention Work Items in that we would want to define how a Diagnostic Imaging Repository 'actor' would support these new Profile transactions. However, even if these other new Work Items are not approved it would still be worthwhile to define the manner in which this new Imaging Repository 'actor' would support existing Profiles such as Scheduled Workflow and XDS-I. So this Work Item is not dependent on these other two related ones being approved.

5. Technical Approach

<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>

<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>

<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>

Existing actors

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>

Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

New transactions (standards used)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>

Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

7. Risks

<List technical or political risks that will need to be considered to successfully field the profile.>

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.>

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):

• 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA