Imaging Object Quality Control and Maintenance - Detailed Proposal

1. Proposed Workitem:

• Proposal Editor: Kinson Ho (Agfa)
• Profile Editors:

Kinson Ho (Agfa)

• Domain: Radiology, Cardiology, or other imaging domains

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. We also need services supporting object Lifecycle Management, such as data retention.

2. The Problem

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 or entire Studies 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.

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.

Recall Wrong or Poor Objects

• Technologist performed acquisition
• Later discovered that the left/right marker was wrong
• Technologist wants to recall the objects
• Ideally all systems that have received the initial object should also stop any further circulation

Data Retention Management

• Data retention policies trigger the condition that particular studies (i.e. based on age) should be deleted
• Need to be able to notify all systems that they must delete any data they may have related to these studies
• If a separate system handles data retention policies, it also requires the same type of transaction to notify one or more 'Image Managers' that a particular study should be deleted.

Features include

1. manual delete,
2. scheduled delete (e.g. due to data retention policy)
3. supercede/replace,
4. 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)
5. 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)
6. 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)

4. Standards and 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.
• IHE Mammography Acquisition Workflow (MAWF) defines a way to communicate deletion of objects from Modality to Image Manager by using DICOM Key Object Selection Document.

5. Technical Approach

Existing actors

Existing actors in order of "vested interest" would be:

• Image Manager/Archive
• Acquisition Modality
• Evidence Creator
• Imaging Document Source

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)

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
• [New in 2010] Confirm if there are any new use cases for synchronization
• [New in 2010] Review the existing text for use case description, proposed solution and other issues
• [New in 2010] Include existing use cases identify in PIR and MAWF and expand them to cross enterprises (either via XDS-I or MIMA)

6. Support & Resources

• Agfa offered to lead development of the profile

• Canada Health Infoway and different provincial project teams could potentially be recruited for identifying clinical use cases.

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.
• "Right-sizing" the scope may be a challenge
  • Avoid Feature Creep
  • Avoid Solving Half the Problem

• It's OK to talk about data sharing in general as the context for change managment
  • Need to keep the whitepaper focussed on solving the change management

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.

Who should be responsible for recording differences between objects? Who is responsible for notifications or polling?

Do we need to differentiate between the handling of changes during the period right after creation, vs after distribution, vs after "stable" archiving?

Do we need to rationalize our solutions with the concepts of data that can be preliminary, final, verified, etc.

Consider scoping the whitepaper down to the "deletion-oriented" use cases and test the MAWF delete-flag mechanism.

9. Tech Cmte Evaluation

Discussion:

• Propose making this work item be an updated (focused) whitepaper and a profile for the deletion cases.

Estimate: 30% of technical cmte effort

Candidate Editors:

Kinson Ho