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 Knizhnick, genady.knizhnik@agfa.com

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

2. The Problem

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

When an image manager determines it is neccessary to;

delete,
Undelete,
superseed/replace,
Update Patient Demographics,
Update Procedure Information,
Merge Patient Records,
Link/unlink Patient Records,
Update Study Level Attribute,
Update Series Level Attributes, and
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

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

Form a working group with the Image Manager vendors
Perform an analysis of the existing methods utilized by vendors today for performing Study Synchronization.
Develop a consensus on the approach with the vendors to perform study synchronization.
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.
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

Relying on the trial implimentation transaction for MAWF. This transaction is untested.
Scope Creep. Splitting the image Manager from the Image Archive is not the intent of this profile.
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 Federated Storage or also Distributed Workflow.

A: This proposal is not looking not at federated storage or Distributed workflow, but a single image manager with a long term storage model between intelligent image managers. This profile is not to address Distributed Workflow.

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

A: 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: Kevin asks, 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.

A: Not clear what is meant by a remote system. 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):

90% - given no acknowledgement of risks or open issues or detailed breakdown of tasks

Candidate Editor: