Complete the work on Imaging Object Change Management

From IHE Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

1. Proposed Workitem:

  • Proposal Editor: Kinson Ho
  • Whitepaper Editor: Kinson Ho (Agfa)
  • Domain: Radiology, Cardiology

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. delete,
  2. Undelete,
  3. superseed/replace,
  4. Update Patient Demographics,
  5. Update Procedure Information,
  6. Merge Patient Records,
  7. Link/unlink Patient Records,
  8. Update Study Level Attribute,
  9. Update Series Level Attributes, and
  10. Update Image Level Attributes;
  11. Subscribe/unsubscribe to change notification
  12. Revision Log

4. Standards & Systems

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

5. Discussion

  • A whitepaper from IHE to document the detailed use cases could be an excellent companion piece of work to the DICOM work item
  • Doing the whitepaper now would help inform/direct the DICOM work
  • If both are successful, a profile could be built from the completed use cases and mechanisms.
  • The whitepaper has already been reviewed a few times during the 2009-2010 season within the Radiology Technical Committee. Due to time constraint, it has not been completed and published.
    • The goal of this proposal is to complete the whitepaper and published for public comment as well as available for DICOM as a reference for their data consistency work.

Questions:

  • Is this ready to do a Profile this year or continue with Whitepaper?
    • Last years WP has several use cases, some are more understood/complete/consensus'ed than others
  • Should we include discussion of HL7 MDM or ebXML as an alternative mechanism?
    • This would move away from handling DICOM with DICOM and move toward mixing protocols and manipulating DICOM with general protocols.