Imaging Object Change Management - Detailed Proposal

1. Proposed Workitem:

• Proposal Editor: Kevin O'Donnell
• Whitepaper Editors:

Kinson Ho (Agfa)

David Heaney (McKesson)

• Domain: Radiology, Cardiology

Summary

On a regular basis, DICOM objects are copied, distributed to where they can be used (great), and modified in the course of being used (unavoidable). Differing modifications of different copies results in "outdated" objects or conflicting versions of the "same" object. We need a solution for managing/synchronizing these objects.

There is interest in adding the necessary mechanisms to DICOM, but a whitepaper is needed first to focus the work.

An IHE Whitepaper would document the uses cases, solution requirements, tricky issues, and problems currently being experienced in the field. The whitepaper would guide the DICOM work. When the DICOM work is complete, IHE could consider a profile to combine the whitepaper (Vol 1 material) and DICOM mechanisms (Vol 2 material).

Regional PACS deployments (specifically in Canada Infoway, and Europe) have reported these issues to be a problem. A variety of other problems not involving regional PACS can also be traced back to the same underlying issue of change & lifecycle management.

Agfa and McKesson have offered to lead development of the profile and several other vendors have expressed interest in helping. Agfa has already developed a proprietary, DICOM-oriented method of solving these issues (which provides proof-of-concept and domain experience) but would like to see IHE provide a solution that could be broadly implemented.

IHE Radiology and it's members have valuable experience with many of the relevant use cases, an interest in making the contents of imaging objects reliable and correct, and a desire for an open standards-based solution. The solutions will work best when many vendors support them.

2. The Problem

As the preferred protocol for distributing and storing medical imaging, vast numbers of DICOM objects are created and distributed every day.

For various reasons, it is common to create and distribute multiple copies of instances:

• Providing copies to other sites (or departments) caring for the same patient
• Sending copies for processing (3D, CAD, Clinical Analysis)
• Local caching of instances to compensate for network performance
• Mirroring instances on a Fail-over/Backup server
• Use of multiple "peer" archives
• Migrating to a new PACS system

For various reasons, it is also common to modify instances:

• Correction/update of demographics
• Splitting/combining studies
• Updating references to other related instances
• Taking “bad” images out of circulation
• Coercing instances to fit into local data models/workflow
• Permanently delete old images as may be required by institutional record retention policies

The combination of needing to distribute copies of instances and needing to modify instances leads to copies which are inconsistent which in turn creates the potential for confusion, error or loss of data.

It would be useful to have reliable, efficient mechanisms to know whether two copies of an instance have diverged, what has changed and if and how to synch them.

3. Key Use Cases

This is just a start to highlight some major use cases. The work item will involve fleshing out the details of these use cases and flushing out other significant use cases.

Central Archive, Local PACS

• i.e. Infoway model
• Each site has a local PACS for operational activities
• A regional Archive takes care of inter-site image exchange and both medium and long term archiving
• Also, local PACS may serve as a local cache (see next use case)

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

Quality Control

• A study received at a local PACS is sent to the regional Archive
• Later on mistake is noticed on the study (e.g. two different acquisitions incorrectly merged into one study due to incorrect worklist item selected)
• Quality control procedure reconcile the study at the local PACS
• Such reconciliation needs to be propagated to the regional Archive. Ideally this can be done automatically.

Features include

1. manual delete,
2. scheduled delete (e.g. due to data retention policy)
3. Undelete,
4. supercede/replace,
5. Update Patient Demographics,
6. Update Procedure Information,
7. Merge Patient Records,
8. Link/unlink Patient Records,
9. Update Study Level Attribute,
10. Update Series Level Attributes, and
11. Update Image Level Attributes;
12. Study Split (e.g. an incorrect worklist entry is selected for an acquisition. This causes the current acquisition to incorrectly merged into an existing study. The incorrect portion of the study needs to be split out)
13. Study Merge (e.g. After the incorrect portion of the study is split out, it is now updated with the correct order. There may already exists a study for the correct order. So in this case, the split out objects will be merged to the existing study)
14. Study Fix Up (e.g. an incorrect worklist entry is selected for an acquisition. A correct entry is selected later. This may change the study instance uid of the existing objects)
15. Subscribe/unsubscribe to change notification
16. Revision Log

4. Standards & Systems

• DICOM has prepared a work item for Data Consistency that could provide mechanisms, but is hesitant to approve the work item without a whitepaper to better document the use cases.

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

The primary goal of this workitem is to develop a whitepaper that maps out use cases and explores relevant issues, such as implementation questions, how the needed profiles might be organized, impact on existing installations, how it would work in a "mixed environment", etc.

The two key technical elements currently under consideration are:

• a DICOM "delta object" that records differences between two objects
• a hash code

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

Existing actors

• Image Manager
• Image Archive
• Acquisition Modality
• Image Display
• Evidence Creator
• Importer

New actors

• Change Initiator?
• Change Acceptor?

Existing transactions

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

New transactions (standards used)

• Notify Of Change (DICOM)
• Query For Changes (DICOM)
• Update Imaging Study (DICOM)
• Delete Object (DICOM)
• Delete Study (DICOM)

Impact on existing integration profiles

• Should have minimal impact to existing profiles

New integration profiles needed

Depending on how the use cases shape up, there might be several profiles to propose in later years, e.g.:

• Imaging Change Management (Basic change management of imaging objects)
• Imaging Study Quality Control (based on ICM, add quality control functions for higher order operations such as study split, study merge, etc.)

Breakdown of tasks that need to be accomplished

• Define detailed clinical use cases for change management
• Define desire requirements for the change management mechanism
• Work with DICOM WG to define any necessary addition in DICOM to support this mechanism
• Design how each use case can be realized using the defined existing or new transactions

High level requirements of the change management design

The following bullets are some proposed high level design goals for the change management design. Together with the use cases, these should be taken into consideration for the overall design of the solution:

• Change details are persistent
  • Provides a natural audit trail for the study
• Change details are captured in an object separate from the original object
  • Allows easy propagation of change (change can be propagated without transmitting the original objects)
  • Keeps the existing object intact
  • Changes are easily archive-able (works well with the Diagnostic Imaging Archive actor)
  • Consistent conceptual design as other DICOM sop classes such as GSPS, DICOM SR, KOS, Radiation Dose, etc.
  • Changes are now queryable using standard DIMSE C-Find service
• Change history is embedded
  • Change Acceptor can make an independent decision whether or not to accept the change (especially important in case of receiving conflicting changes)
  • Only interested parties (e.g. Change Acceptor) need to interpret the object (minimized impact on existing systems while allowing them to take advantage of the features in the future)
  • Alleviates the dependency on timing (not always possible to identify the order of changes. Two changes that affect the same attribute can occur in parallel)
• Easy adoption to XDS-I
  • When change details are captured in an object, this can easily be published to XDS-I by creating a manifest of the change object.
  • No addition work required to integrate with XDS-I.

6. Support & Resources

• Canada Health Infoway and different provincial project teams
• Enterprise archive providers:
  • GE
  • McKesson
  • Agfa

7. Risks

• Will very likely depend on new mechanism defined in DICOM.
  • We need to coordinate with DICOM and make sure this is also a workitem they can work on.
• Feature Creep
• Solving Half the Problem

8. Open Issues

The design for deletion (data retention, quality control) may need to synchronize with the design already specified in MAWF to avoid multiple designs with similar purpose.

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