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)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>

Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

7. Risks

<List technical or political risks that will need to be considered to successfully field the profile.>

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