Diagnostic Imaging Repository Actor - Brief Proposal
1. Proposed Profile: Diagnostic Imaging Repository Actor
- Proposal Editor: David Heaney, David.Heaney@mckesson.com
- Date: August 25, 2009
- Version: 1.0
- Domain: Radiology
2. The Problem
The deployment of enterprise and regional long term archives for diagnostic imaging is becoming more widespread. However, IHE does not explicitly specify exactly which Actors and Profiles such a system should support, either in regards to general Radiology Profiles or when it comes to supporting XDS-I. In fact the IHE Radiology Profiles do not specify any Image Manager to Image Manager transactions which makes it ambiguous as to how local PACS should even connect to such a regional archive using IHE Profiles.
3. Key Use Case
A group of hospitals each have local PACS, and possibly other dedicated Image Managers for Mammography, Cardiology, etc. These local PACS are in turn connected to a regional central archive. The regional central archive is then expected to support integration with XDS based infrastructure. To prospective customers though it is somewhat ambiguous as to exactly which IHE Profiles such a regional archive should support and how. Vendors also run into many issues when trying to deploy such a system, or integrate their local PACS products as it is not clear which system should be responsible for certain functionality or how. For example, does the regional archive have to support IHE Scheduled Workflow, and if so how?
4. Standards & Systems
DICOM IHE XDS-I
A lot of experience has now been gained by those working on deploying such regional archives, both in connecting them with local PACS and also with integrating them into XDS-I based infrastructure. Such knowledge could be leveraged to define exactly which Profiles and Actors such a regional archive should support. For example, one of the fundamental decisions would have to be whether or not a regional archive could be 'DICOM only' or also needs to support HL7 based Scheduled Workflow transactions. I believe that experience from Canadian deployments (based on the Infoway blueprint) have shown that support for HL7 transactions is required.