Data Retention - Brief Proposal

From IHE Wiki
Revision as of 12:39, 26 August 2009 by Lindop (talk | contribs) (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== ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

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.

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?

4. Standards & Systems

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

5. Discussion

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.