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

Every day 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, and an interest in making the contents of imaging objects reliable and correct. 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 Case

Central Archive, Local PACS

• i.e. Infoway model

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

Features

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. Subscribe/unsubscribe to change notification
13. Revision Log

4. Standards & Systems

• DICOM is considering a work item for Data Consistency that could provide mechanisms.

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

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

• Imaging Study Update (DICOM)
• Object Delete (DICOM)
• Study Delete (DICOM)
• Change Available Notification (DICOM)
• Change Availability Query (DICOM)

Impact on existing integration profiles

• Should have minimal impact to existing profiles

New integration profiles needed

• Imaging Study Change Management (Basic change management)
• Imaging Study Quality Control (based on ISCM, add quality control functions 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 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 is persistent
  • Provides a natural audit trail for the study
• Change is captured in a separate object
  • Allow easy propagation of change (change can be propagated without transmitting the original objects)
  • Keep 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 at any time
• Change history is embedded
  • Change Acceptor can make 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)
  • Alleviate the dependency on timing (not always possible to identify the order of changes. Two changes that affect the same attribute can occur in parallel)

6. Support & Resources

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

7. Risks

• Will likely depend on new mechanism defined in DICOM. That means we need to work together with DICOM WG and make sure this is also a workitem that they can work on.

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