Difference between revisions of "Data Retention - Brief Proposal"

From IHE Wiki
Jump to navigation Jump to search
(New page: ==1. Proposed Profile: Data Retention== *Proposal Editor: David Heaney, David.Heaney@mckesson.com *Date: August 25, 2009 *Version: 1.0 *Domain: Radiology, Cardiology ==2. The Problem== ...)
 
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
 +
__NOTOC__
 
==1. Proposed Profile: Data Retention==
 
==1. Proposed Profile: Data Retention==
  
*Proposal Editor: David Heaney, David.Heaney@mckesson.com
+
* Proposal Editor: David Heaney, David.Heaney@mckesson.com
*Date: August 25, 2009
+
* Domain: Radiology, Cardiology
*Version: 1.0
 
*Domain: Radiology, Cardiology
 
  
 
==2. The Problem==
 
==2. The Problem==
  
To contain storage costs and support data retention policies defined by customers, there is the need to support study deletion across multiple systems. The integration of multiple PACS as federated system is becoming more widespread, as is the deployment of enterprise and regional long term archives. This can result in multiple copies of data being stored on different systems. So there needs to be a standardized transaction so that when a study is deleted on one 'Image Manager', this system can notify other 'Image Managers' to perform the same action. There could also be the desire to create a separate system that handles data retention policies, so this would require the same type of transaction to notify one or more 'Image Managers' that a particular study should be deleted.  
+
To contain storage costs and support data retention policies defined by customers, there is a need to support study deletion across multiple systems. In particular, to support delete at the study/patient level, rather than trying to hit all the individual instances.
 +
 
 +
Federated PACS, enterprise and regional long term archives can result in multiple copies of data being stored on different systems. When a study is deleted on one 'Image Manager' there is no way to notify other 'Image Managers' to perform the same action.
  
 
==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. These local PACS are in turn connected to a regional central archive.  
+
A group of hospitals each have local PACS, and possibly other dedicated Image Managers for Mammography, Cardiology, etc.  
Data retention policies trigger the condition that particular types of studies older than a certain number of years should be deleted. How can all these systems be notified that they must delete any data they may have related to these studies?  
+
 
 +
These local PACS are in turn connected to a regional central archive.  
 +
 
 +
Data retention policies trigger the condition that particular types of studies older than a certain number of years should be deleted.  
 +
 
 +
How can all these systems be notified that they must delete any data they may have related to these studies?  
 +
 
 +
If a separate system handles data retention policies, it also requires the same type of transaction to notify one or more 'Image Managers' that a particular study should be deleted.
 +
 
 +
'''Features'''
 +
:#Delete Study - Delete an entire Study record and all its content
 +
:#Delete Specific Study Content - Maintain the Study record but delete a specific type of content. For example, a transaction for conveying that all imaging objects should be deleted from a Study but all reports should be maintained.
 +
 
  
 
==4. Standards & Systems==
 
==4. Standards & Systems==
Line 20: Line 33:
  
 
==5. Discussion==
 
==5. Discussion==
 +
 +
This proposal is similar to the Imaging Object Change Management proposal in that they both will define use cases where one system needs to update the Study content of another system. The difference is that the Object Change Management deals with data synchronization issues that arise in scheduled workflow use cases and exception management, whereas Data Retention deals with Information Lifecycle Management use cases.
  
 
Vendors are already implementing Web Services based solutions for data retention related messaging but in a proprietary manner. There is a strong demand for this to be supported by IHE and this would likely result in quick uptake and implementation by vendors if such a Profile is developed.
 
Vendors are already implementing Web Services based solutions for data retention related messaging but in a proprietary manner. There is a strong demand for this to be supported by IHE and this would likely result in quick uptake and implementation by vendors if such a Profile is developed.

Latest revision as of 17:52, 15 September 2009

1. Proposed Profile: Data Retention

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

2. The Problem

To contain storage costs and support data retention policies defined by customers, there is a need to support study deletion across multiple systems. In particular, to support delete at the study/patient level, rather than trying to hit all the individual instances.

Federated PACS, enterprise and regional long term archives can result in multiple copies of data being stored on different systems. When a study is deleted on one 'Image Manager' there is no way to notify other 'Image Managers' to perform the same action.

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.

Data retention policies trigger the condition that particular types of studies older than a certain number of years should be deleted.

How can all these systems be notified that they must delete any data they may have related to these studies?

If a separate system handles data retention policies, it also requires the same type of transaction to notify one or more 'Image Managers' that a particular study should be deleted.

Features

  1. Delete Study - Delete an entire Study record and all its content
  2. Delete Specific Study Content - Maintain the Study record but delete a specific type of content. For example, a transaction for conveying that all imaging objects should be deleted from a Study but all reports should be maintained.


4. Standards & Systems

Web Services transactions similar to those used in IHE XDS-I.

5. Discussion

This proposal is similar to the Imaging Object Change Management proposal in that they both will define use cases where one system needs to update the Study content of another system. The difference is that the Object Change Management deals with data synchronization issues that arise in scheduled workflow use cases and exception management, whereas Data Retention deals with Information Lifecycle Management use cases.

Vendors are already implementing Web Services based solutions for data retention related messaging but in a proprietary manner. There is a strong demand for this to be supported by IHE and this would likely result in quick uptake and implementation by vendors if such a Profile is developed.