Image Management Enhancements - Detailed Proposal
1. Proposed Workitem: Image Management Enhancements
- Proposal Editor:
- Christopher Lindop, Christopher.Lindop@ge.com
- David Heaney, david.heaney@mckesson.com
- Genady Knizhnick, genady.knizhnik@agfa.com
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: Radiology
2. The Problem
A key issue for deployment of systems relying upon IHE Profiles surrounds the manner in which systems should deal with data synchronization issues in environments where there are multiple Image Manager/Archives. Recently, due to the increased consolidation of the healthcare providers into integrated delivery networks (IDN, RHIO, Canadian Jurisdiction, NHS Cluster, etc) the need has arisen to share the radiology studies among different facilities (i.e. different PACS systems). The current version of the DICOM standard enables this sharing and is widely adopted. That approach works well for cases where shared radiology studies do not undergo any changes after leaving the originating PACS system. However, as soon as there is a need to update the study once it has been shared there is no standard mechanism to keep multiple copies of the same study synchronized. Even in cases where XDS-I is being used there are use cases and deployment architectures where data synchronization cannot be completely achieved using XDS Manifest delete/deprecate based mechanisms.
3. Key Use Case
When an image manager determines it is neccessary to;
- delete,
- Undelete,
- superseed/replace,
- Update Patient Demographics,
- Update Procedure Information,
- Merge Patient Records,
- Link/unlink Patient Records,
- Update Study Level Attribute,
- Update Series Level Attributes, and
- Update Image Level Attributes;
for an image or image set located in an common archive managed by a seperate image manager, there needs to be a mechanism to perform these actions.
An archive may also support many image managers. There neeeds to be a subscription mechanism for image managers to records. The image manager will need to know of updates to those records.
When image or image sets are updated, consideration for some sort of auditable revision log should be part of this profile.
4. Standards & Systems
- IHE Integration Profile PGP
- IHE Integration Profile MAWF
- IHE Integration Profile SWF
- IHE Integration Profile PAM
- IHE Integration Profile ATNA
- HL-7
- DICOM
5. Technical Approach
Where possible, IHE Transactions existing and currently under development will be leveraged.
Image Rejection Note RAD-66 is a method that could be applied when images exist in an archive that would subsequently be (1)deleted or (3)superceded/replaced. For images which need (2) undeletion, the Image Rejection Note RAD-66 could be used to undo the action of the previous Image Rejection Note RAD-66 .
Transaction Patient Update RAD-12, and/or the IHE PAM Transaction ITI-30 could be applied to update existing patient records when it is necessary to (4) Update Patient Demographics and (6) Merge Patient Records.
Transaction Procedure Update RAD-13, could be applied to update existing procedure record requirements for (5) Update Procedure Information and (6) Merge Study Records.
For 7) Link/unlink patient records can leverage the existing IHE PGP transactions for linking. Unlink can use the Image Rejection Note RAD-66. Note that in order for images to be linked in DICOM, the images must all exist in the Study. This would require the image or image set to be merged into the study first.
In cases where errors are identified in image SOP Instances that have already been exported to another system it would really be ideal if there were mechanisms for correcting individual Attribute values without having to create new SOP Instances with the corrected values, particularly when dealling with very large imaging SOP Instances due to the large storage and andwidth costs of having to re-export such data. Ideally there would be new transactions for 8) Update Study Level Attribute, 9) Update Series Level Attributes, and 10)Update Image Level Attributes that would allow one system to correct Attributes of a SOP Instance on another system. Most vendors either have a DICOM proprietary interface or a specialized HL7 OMI to handle these requirements. DICOM has no mechanism for such modifications. Possibly a KIN extension could be developed for this need where a KIN with a newly defined Document Title could convey just the list of Attribute values to be corrected. The other possibility would be to utilize the Enhanced Procedure Update Tranaction. The base standard, HL7 OMI will require further examination. Possibly a mix of the two approaches could be applied.
Support udate notifications for multiple image managers will require a subscription mechanism. The image manager will need to know of updates to those records. This is current work that is ongoing in DICOM Web Services and ITI Web Services. Would reccomend we not concider these requirements at this time until the DICOM Web Services Workitem is complete.
Finally, consideration will be necessary regarding change management. When images and image sets are modified, how would the changes be recorded? Certainly use of ATNA will be necessary. An auditrable change history log will be necessary. ATNA should be evaluated to meet this requirement.
Existing actors
- Image Manager
- Image Archive
New actors
None
Existing transactions
- See Technical Approach summary above.
New transactions (standards used)
See Technical Approach summary above.
Impact on existing integration profiles
- ATNA - Radiology Option
New integration profiles needed
One new profile proposed. See Technical Approach summary above.
6. Support & Resources
Vendors Who develop Image Managers and Archives.
7. Risks
- Relying on the trial implimentation transaction for MAWF. This transaction is untested.
- Scope Creep. Splitting the image Manager from the Image Archive is not the intent of this profile.
See Technical Approach summary above.
Risks: Will this involve IHE trying to patch over a DICOM Gap?
8. Open Issues
See Technical Approach summary above.
Issue: Is this covering just Federated Storage or also Distributed Workflow.
- A: This proposal is not looking not at federated storage or Distributed workflow, but a single image manager with a long term storage model between intelligent image managers. This profile is not to address Distributed Workflow.
Issue: Copy all the issues that have been raised in the past about splitting Image Manager/Archive
- A: We will review the issues to see if they are applicable.
This profile is addressing only specifif needs for a multi-image manager environment. We only are addressing Image Syncronization beteen two image managers.
Issue: Undelete needed on Remote systems?
- Kevin says it seems like undelete should be a function for the data master. His proposal is to resend if necessary to remotes.
9. Tech Cmte Evaluation
Effort Evaluation (as a % of Tech Cmte Bandwidth):
- 90% - given no acknowledgement of risks or open issues or detailed breakdown of tasks
Candidate Editor:
- Christopher Lindop, Christopher.Lindop@ge.com
- David Heaney, david.heaney@mckesson.com
- Genady Knizhnick, genady.knizhnik@agfa.com