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 XDS-I based infrastructure surrounds the manner in which systems should deal with data synchronization issues. The IHE XDS-I Profile does not explicitly define how to update values specified in a DICOM SOP Instance after it has been published. Added complexity arises when implementing the Canada Infoway Architecture for XDS-I deployment because it specifies the use of a Digital Imaging Repository (DI-R) for long term archiving of all DICOM SOP Instances. This raises questions of how local PACS acting as Image Manager Actor should interact with a DI-R acting as an Archive Actor, This becomes evident in the use cases where it is necessary to delete, modify, or replace archived SOP Instances. The IHE Canada XDS Implementation Group has been working on developing solutions for these issues.
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 archive, 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 2
- 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, to be replaced in SWF 2 with the IHE PAM Transaction ITI-30. By grouping the Patient Demographic Source with the Image Manager and Patient Demographic Consumer with the Archive could be applied to existing patient records when it is necessary to (4) Update Patient Demographics and (6) Merge Patient Records. This is the approach in SWF 2 for replacing IHE Transaction RAD 12 Patient Update.
Transaction Procedure Update RAD-13, to be replaced in SWF 2 with the Transaction Enhanced Procedure Update RAD-xx13. With the existing definition of Transaction Procedure Update RAD-13, the requirements for (5) Update Procedure Information and Merge Study Records. The base standard, HL7 OMI will require further examination in order to utilize it's fullest potential with respect to meet the needs
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.
Tranactions 8) Update Study Level Attribute, 9) Update Series Level Attributes, and 10)Update Image Level Attributes have no clear solution. Most vendors either have a DICOM proprietary interface or a specialized HL7 OMI to handle these requirements. DICOM has no mechanism to modify. Possibly a KIN extension could be developed for this need. 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
See Technical Approach summary above.
8. Open Issues
See Technical Approach summary above.
9. Tech Cmte Evaluation
Effort Evaluation (as a % of Tech Cmte Bandwidth):
Candidate Editor:
- Christopher Lindop, Christopher.Lindop@ge.com
- David Heaney, david.heaney@mckesson.com
- Genady Knizhnick, genady.knizhnik@agfa.com