Difference between revisions of "Diagnostic Imaging Repository Actor - Brief Proposal"

Latest revision as of 19:33, 15 September 2009

1. Proposed Workitem: Diagnostic Imaging Repository Actor

Proposal Editor: David Heaney, David.Heaney@mckesson.com
Domain: Radiology

2. The Problem

Enterprise and regional long term archives for diagnostic imaging are being deployed.

Such architectures involve transactions between local PACS and a regional long term archive, with both types of systems normally being considered Image Manager 'actors'.

However, IHE does not define such transactions and does not clearly describe the role of such a Diagnostic Imaging Repository Actor. There are no Image Manager to Image Manager transactions defined in the framework. It is also not clear which Profile Actors should be supported by the local PACS as opposed to the regional archive. For example, does the regional archive have to support Scheduled Workflow transactions, and if so as what Actor and how should it manage the multiple ordering 'contexts'? Also, which XDS-I Profile Actors should the local PACS and regional archive support?

Vendors are running into issues when trying to deploy such systems, or integrate their local PACS products.

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.

This Work Item is certainly related to the Object Change Management and Data Retention Work Items in that we would want to define how a Diagnostic Imaging Repository 'actor' would support these new Profile transactions. However, even if these other new Work Items are not approved it would still be worthwhile to define the manner in which this new Imaging Repository 'actor' would support existing Profiles such as Scheduled Workflow and XDS-I. So this Work Item is not dependent on these other two related ones being approved.

@@ Line 1: / Line 1: @@
-==1.	Proposed Profile: Diagnostic Imaging Repository Actor==
+==1.	Proposed Workitem: 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.
+Enterprise and regional long term archives for diagnostic imaging are being deployed.
+Such architectures involve transactions between local PACS and a regional long term archive, with both types of systems normally being considered Image Manager 'actors'.
+However, IHE does not define such transactions and does not clearly describe the role of such a Diagnostic Imaging Repository Actor. There are no Image Manager to Image Manager transactions defined in the framework. It is also not clear which Profile Actors should be supported by the local PACS as opposed to the regional archive. For example, does the regional archive have to support Scheduled Workflow transactions, and if so as what Actor and how should it manage the multiple ordering 'contexts'? Also, which XDS-I Profile Actors should the local PACS and regional archive support?
+Vendors are running into issues when trying to deploy such systems, or integrate their local PACS products.
 ==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.
+A group of hospitals each have local PACS, and possibly other dedicated Image Managers for Mammography, Cardiology, etc.
-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?
+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==
@@ Line 22: / Line 32: @@
 ==5.	Discussion==
-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.
+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.
+This Work Item is certainly related to the Object Change Management and Data Retention Work Items in that we would want to define how a Diagnostic Imaging Repository 'actor' would support these new Profile transactions. However, even if these other new Work Items are not approved it would still be worthwhile to define the manner in which this new Imaging Repository 'actor' would support existing Profiles such as Scheduled Workflow and XDS-I. So this Work Item is not dependent on these other two related ones being approved.