Image Management Enhancements - Detailed Proposal

1. Proposed Workitem: Image Management Enhancements

• Proposal Editor:

Christopher Lindop, Christopher.Lindop@ge.com

David Heaney, david.heaney@mckesson.com

Genady Knizhnik, genady.knizhnik@agfa.com

• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology

2. The Problem

When multiple copies of the same object instance are maintained on different systems, changes (including, in some cases, deletion) to one copy of an instance should be reflected in the other instances.

A key issue for deployment of systems relying upon IHE Profiles surrounds the manner in which systems should deal with data synchronization issues in environments where there are multiple Image Manager/Archives. Recently, due to the increased consolidation of the healthcare providers into integrated delivery networks (IDN, RHIO, Canadian Jurisdiction, NHS Cluster, etc) the need has arisen to share the radiology studies among different facilities (i.e. different PACS systems). The current version of the DICOM standard enables this sharing and is widely adopted. That approach works well for cases where shared radiology studies do not undergo any changes after leaving the originating PACS system. However, as soon as there is a need to update the study once it has been shared there is no standard mechanism to keep multiple copies of the same study synchronized. Even in cases where XDS-I is being used there are use cases and deployment architectures where data synchronization cannot be completely achieved using XDS Manifest delete/deprecate based mechanisms.

3. Key Use Case

<Really need to clarify what use cases are being considered and what capabilities are in scope>

Local Cache

• A group of three hospitals each have local PACS.
• When a patient is transfered to another hospital (e.g. for specialist care), a copy of recent images are transfered to the second hospital.
• The first hospital identifies a demographic change and updates their Master Copy of the images.
• ?? What happens at the second hospital, how??

(Laundry List of Features)

When an image manager determines it is neccessary to;

1. delete,
2. Undelete,
3. superseed/replace,
4. Update Patient Demographics,
5. Update Procedure Information,
6. Merge Patient Records,
7. Link/unlink Patient Records,
8. Update Study Level Attribute,
9. Update Series Level Attributes, and
10. Update Image Level Attributes;

for an image or image set located in an common archive managed by a seperate image manager, there needs to be a mechanism to perform these actions.

An archive may also support many image managers. There neeeds to be a subscription mechanism for image managers to records. The image manager will need to know of updates to those records.

When image or image sets are updated, consideration for some sort of auditable revision log should be part of this profile.

4. Standards & Systems

• IHE Integration Profile PGP
• IHE Integration Profile MAWF
• IHE Integration Profile SWF
• IHE Integration Profile PAM
• IHE Integration Profile ATNA

• HL-7
• DICOM

5. Technical Approach

Concepts:

• Should probably establish a "master copy" of each instance which is owned by a certain system (e.g. the Source Image Manager).
• "Non-master" copies should not be updated?
• Mechanisms are needed for other systems to know about changes to the master (notification or polling?).

Where possible, IHE Transactions existing and currently under development will be leveraged.

Image Rejection Note RAD-66 is a method that could be applied when images exist in an archive that would subsequently be (1)deleted or (3)superseded/replaced. For images which need (2) undeletion, the Image Rejection Note RAD-66 could be used to undo the action of the previous Image Rejection Note RAD-66 .

Transaction Patient Update RAD-12, and/or the IHE PAM Transaction ITI-30 could be applied to update existing patient records when it is necessary to (4) Update Patient Demographics and (6) Merge Patient Records.

Transaction Procedure Update RAD-13, could be applied to update existing procedure record requirements for (5) Update Procedure Information and (6) Merge Study Records.

For 7) Link/unlink patient records can leverage the existing IHE PGP transactions for linking. Unlink can use the Image Rejection Note RAD-66. Note that in order for images to be linked in DICOM, the images must all exist in the Study. This would require the image or image set to be merged into the study first.

In cases where errors are identified in image SOP Instances that have already been exported to another system it would really be ideal if there were mechanisms for correcting individual Attribute values without having to create new SOP Instances with the corrected values, particularly when dealing with very large imaging SOP Instances due to the large storage and and with costs of having to re-export such data. Ideally there would be new transactions for 8) Update Study Level Attribute, 9) Update Series Level Attributes, and 10)Update Image Level Attributes that would allow one system to correct Attributes of a SOP Instance on another system. Most vendors either have a DICOM proprietary interface or a specialized HL7 OMI to handle these requirements. DICOM has no mechanism for such modifications. Possibly a KIN extension could be developed for this need where a KIN with a newly defined Document Title could convey just the list of Attribute values to be corrected. The other possibility would be to utilize the Enhanced Procedure Update Transaction. The base standard, HL7 OMI will require further examination. Possibly a mix of the two approaches could be applied.

Support update notifications for multiple image managers will require a subscription mechanism. The image manager will need to know of updates to those records. This is current work that is ongoing in DICOM Web Services and ITI Web Services. Would recommend we not consider these requirements at this time until the DICOM Web Services Workitem is complete.

Finally, consideration will be necessary regarding change management. When images and image sets are modified, how would the changes be recorded? Certainly use of ATNA will be necessary. An auditable change history log will be necessary. ATNA should be evaluated to meet this requirement.

Existing actors

• Image Manager
• Image Archive

New actors

None

Existing transactions

• See Technical Approach summary above.

New transactions (standards used)

See Technical Approach summary above.

Impact on existing integration profiles

None

New integration profiles needed

One new profile proposed.

Breakdown of tasks that need to be accomplished

1. Form a working group with the Image Manager vendors
2. Perform an analysis of the existing methods utilized by vendors today for performing Study Synchronization.
3. Develop a consensus on the approach with the vendors to perform study synchronization.
4. If significant gaps are identified to the standards, identify standards to be modified. Submit CPs as necessary. If CPs are too significant, then no profile will be created.
5. If no profile created, a white paper will be written outlining the approach.

6. Support & Resources

Vendors Who develop Image Managers and Archives.

7. Risks

1. The Use Cases have not been fully mapped. The scope and difficulty could be much greater.
2. Relying on the trial implimentation transaction for MAWF. This transaction is untested.
3. Scope Creep. Splitting the image Manager from the Image Archive is not the intent of this profile.
4. DICOM/HL7 Gaps Risks. Need to ensure we do not use IHE to patch DICOM and HL7 Gaps.

8. Open Issues

See Technical Approach summary above.

Issue: Is this covering just Synchronized (Federated or Hierarchical) Storage or also Workflow.

At what point in the workflow are the images replicated? How quickly/completely are synchronizations required to propogate? I.e. these capabilities are not required to function in "short" time intervals (minutes to a day or so).

Issue: Is this covering tight Synchronization (SWF) or also loose synchronization (XDS-I).

Expect to address tight Synch only. We would probably need to use different mechanisms in the loose case than in the tight case anyway, so it could be handled separately.

Issue: Copy all the issues that have been raised in the past about splitting Image Manager/Archive

We will review the issues to see if they are applicable. This profile is addressing only specific needs for a multi-image manager environment. We only are addressing Image Synchronization between two image managers. Separating the Image Manager from the image archive is out of scope.

Issue: Is undelete needed on remote systems? says it seems like undelete should be a function for the data master. His proposal is to resend if necessary to remotes.

Not clear what is meant by a remote systems. The data master is always the source of the data. The method for undelete may include this as part of the solution based on the outcome of this workitem.

9. Tech Cmte Evaluation

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

20% - to only introduce an image rejection capability between image managers

The risk is that this does not address general image synchronization and when we address that we could find ourselves "pulling an XDS" and introducing a new/different mechanism to do the same thing causing confusion for users, incompatibility and extra work for vendors.

60% - to address general image synchronization in a "tightly grouped" environment (e.g. multiple PACS in a single "workspace", like rad & card, or a group of local hospitals, etc, possibly multiple order placers/fillers, etc)

(not estimated) - to address image synchronization in a "loosely grouped" environment (e.g. a RHIO, XDS-I, where ADTs and OP/OF are not shared or even visible to each other)

Candidate Editor:

David Heaney

Radiology_Proposals_2008-2009