Diagnostic Imaging Repository Actor - Brief Proposal: Difference between revisions
No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
The deployment of enterprise and regional long term archives for diagnostic imaging is becoming more widespread. | The deployment of enterprise and regional long term archives for diagnostic imaging is becoming more widespread. | ||
Such architectures involve transactions between two image managers. IHE does not define such transactions and does not clearly describe the role of such a Diagnostic Imaging Repository Actor. | |||
Vendors run into issues when trying to deploy such a system, or integrate their local PACS products. | |||
It is not clear which system should be responsible for which functionality or how. For example, does the regional archive have to support IHE Scheduled Workflow, and if so how? | |||
==3. Key Use Case== | ==3. Key Use Case== | ||
A group of hospitals each have local PACS, and possibly other dedicated Image Managers for Mammography, Cardiology, etc. | A group of hospitals each have local PACS, and possibly other dedicated Image Managers for Mammography, Cardiology, etc. | ||
To prospective customers | |||
The PACS systems 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 it is ambiguous which IHE Profiles such a regional archive should support and how. | |||
==4. Standards & Systems== | ==4. Standards & Systems== | ||
| Line 22: | Line 33: | ||
==5. Discussion== | ==5. Discussion== | ||
A lot of experience has | A lot of experience has 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 fundamental decision would be whether a regional archive should be 'DICOM only' or also support HL7-based Scheduled Workflow transactions. I believe experience from Canadian deployments (based on the Infoway blueprint) have shown that support for HL7 transactions is required. | |||
Revision as of 21:47, 26 August 2009
1. Proposed Workitem: Diagnostic Imaging Repository Actor
- Proposal Editor: David Heaney, David.Heaney@mckesson.com
- Domain: Radiology
2. The Problem
The deployment of enterprise and regional long term archives for diagnostic imaging is becoming more widespread.
Such architectures involve transactions between two image managers. IHE does not define such transactions and does not clearly describe the role of such a Diagnostic Imaging Repository Actor.
Vendors run into issues when trying to deploy such a system, or integrate their local PACS products.
It is not clear which system should be responsible for which functionality or how. For example, does the regional archive have to support IHE Scheduled Workflow, and if so how?
3. Key Use Case
A group of hospitals each have local PACS, and possibly other dedicated Image Managers for Mammography, Cardiology, etc.
The PACS systems 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 it is ambiguous which IHE Profiles such a regional archive should support and how.
4. Standards & Systems
DICOM
IHE XDS-I
5. Discussion
A lot of experience has 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 fundamental decision would be whether a regional archive should be 'DICOM only' or also support HL7-based Scheduled Workflow transactions. I believe experience from Canadian deployments (based on the Infoway blueprint) have shown that support for HL7 transactions is required.