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:

• Fixing/Splitting/Combining studies
• Taking “bad” images out of circulation
• 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,

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

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

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

• [RAD-66] Image Rejection Note Stored

• Can be used as a generalized image deletion mechanism. Need to extend to include different reasons for deletion.

• [RAD-8] Modality Images Stored
• [RAD-9] Modality Presentation State Stored
• [RAD-18] Creator Images Stored
• [RAD-19] Creator Presentation State Stored
• [RAD-70] Image Manager Instances Stored

• Include references to objects that are going to be replaced by the new ones (e.g. using the Purpose of Reference Code Sequence (0040,A170) in the Referenced Instance Sequence (0008,114A)

Breakdown of tasks that need to be accomplished

The two main tasks that involved are

1. Define a deletion mechanism, based on RAD-66
2. Define a replacement / deprecation mechanism using the Purpose of Referenced Code Sequence

In more details, the following tasks are involved

• Define use cases the involve Quality Control and Maintenance in Volume 1 (most work can be borrowed from IOCM whitepaper)
• Extend RAD-66 to include other reasons for deletion

• May require some refactoring of the transaction to be non-MAWF specific

• Extend the various Image Stored transactions to include references for replacement / deprecation support
• Define expected behaviour on receiving actor so that it can stay synchronized with the source actor that communicates the change
• For the QC tasks, certain use cases require generation of new UIDs. May need a new transaction for this.
• Discuss how this mechanism is compatible with XDS-I.

6. Support & Resources

• Agfa offered to lead development of the profile
• Ellie Avraham from Phiilips offered to help writing the profile
• Fred Behlen also offer to help working on the profile, in particular, from the DICOM compliant perspective
• Canada Health Infoway and different provincial project teams could potentially be recruited for identifying clinical use cases.
• David Heaney and Chris Lindop will recruit end user input to the discussion from their contacts in deployed projects.

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

• Should the profile be limited to communication between multiple Image Managers?

• Or in general, how distributed the synchronization should cover?

• What are the auditing requirement for communicating and applying synchronization?
• Is it necessary to keep track of the data source?
• What about the use case of receiving same object (i.e. same sop instance uid) that is different from what is known?

• What is the receiver required/permitted to do?
• E.g. ignore the "new" object, replace it regardless, create a "hybrid" reconciled object?

• Success-Failure Details
  • Would any use cases benefit from the receiving actor being able to know if the delete/replacement was performed or not, and if not, what the reasons for the failure were?
  • If so, how can this information be provided?
  • If the information cannot be reliably provided, should some use cases be documented as out of scope or incompletely addressed?

9. Tech Cmte Evaluation

Discussion:

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

Estimate: 35% of technical cmte effort

Candidate Editors:

Kinson Ho