Long Term Archiving - Brief Proposal

1. Proposed Workitem: Long Term Archiving

• Proposal Editor: Pim Philipse
• Editor: Pim Philipse
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology

2. The Problem

The life cycle of a radiological image often spans a much longer time than the life cycle of a PACS. Moreover, since the tail of the image life cycle mostly has to do with medico-legal reasons, older images are preferably stored on slow media on specialized storage systems. When a PACS is replaced, the conventional method of migrating the data can therefore be a very costly and time-consuming procedure. The storage system may be shared between departments of an institution, but if the system is only a bin where the departments dump their data, the 'silo-syndrome' is enforced.

By using existing transactions and profiles it is possible to 'inform' the new PACS of the images that are residing in the storage system, by merely migrating some or all of the metatada. Migration can then be either instantaneous or a matter of days. A specification that tells a PACS when to query for patient data on the storage system can increase accessibility of the departmental silo's.

3. Key Use Case

• A department wants to replace its PACS. The new vendor requires that all existing data are copied from the old PACS to the new PACS. This takes months, during which the two systems have to run simultaneously, bandwidth is wasted, the storage system is occupied, and extra support personnel is active.
• A department wants to share its data with other departments and gives them Q/R access to the PACS. However, the department users now have to share bandwidth and CPU cycles with the guests. Some guests have displays that support the Multiple Archives option, but most people have to switch back and forth between all systems. It is also hard to manage all Move Destinations on all Image Managers.

If the PACS and the storage system conform to the Multiple Identity Resolution of the SWF profile, the following scenario's are feasible:

• A department wants to replace its PACS. The old PACS has sent all data to the storage system, which has also received ADT/ORM and IOCM to keep the information up-to-date. The new PACS is informed of the DICOM services of the Storage System and starts receiving new data from the modalities. When there is a need for priors, it queries the Storage System and retrieves them, either through prefetching or on demand from a workstation.

• If the old database isn't 'rich' enough for the new PACS, it may retrieve selected images to fill in the missing information from the header, or preferably retrieve only the header through the "Composite Instance Retrieve Without Bulk Data" C-GET, or through WADO-WS's RetrieveImagingDocumentSetInformation web service.

• When data from other department is desired, the workstation user may query via a special AET on the PACS, which then combines the local query results with the information of other departments that was found on the Storage System. Privacy concerns should be accounted for. Possibly the remote query may only be executed for a patient who already has examinations in the PACS that issues the query.

• Since the user only access the PACS of their department, the complexity of Move AET management is greatly reduced. The local PACS acts as a C-MOVE proxy for the user, using itself as the Move Destination AE, then forwarding the received instances to the workstation. Other retrieval methods like C-GET, Wado, Wado-WS can be handled in this manner as well.

The UK Imaging Informatics group is requesting the functionality of maintaining separate long term storage in its VNA Specification:

[1].b Customer may wish to consolidate images held in multiple PACS systems—Radiology PACS, Cardiology PACS, Ophthalmology PACS, etc in the same hospital. The departmental PACS are left with 1 year or so of image data, & the rest being stored in the VNA.

4. Standards and Systems

Systems: Image Manager / Image Archive

Standards: SWF+MIR, PIR+MIR, IOCM

5. Discussion

IHE has already defined the profiles and transactions that lead the way for resolving the issues. The only thing that is left is to profile their use (i.e. the 'expected behavior') in order to obtain the desired resolution.

If a Q/R operation is spread out over multiple systems, the chance that some of them will not respond timely or at all increases. C-MOVE has the concept of a Failed SOP Instances List, so that can be used to inform the user that not all images were retrieved. C-FIND does not have a Warning status. The local IM can return its own responses and those of the systend that did react, then it can send a Success (SCU-friendly but misinforming the user) or an Unable to Process with an explanation (informing the user but breaking possibly 8 out of 10 clients). It can also send a fake pending response with an attribute appropriate for the Q/R level that makes it evident for the ser that there are possibly more results on one or more systems that were not accessible.

The privacy issue was already mentioned. Logging might have to be more specific, and being able to know the user of an Image Display would be great, but the adoption of User Identity Negotiation is required for that to happen. Still, if an institution can live with these limitations, it should not be denied the possibility of DICOM-based inter-department sharing.

The storage system could take a part in the XDS-I Document Source Actor. The PACS may publish the KOSD, but place the AET or Location UID of the storage system inside the items of the ReferencedSeries sequence(s).

If an IM claims conformance to the profile, it should thereby guarantee that it does not alter images without informing the storage system of the change in a standardized way.

The burden of conformance would lie on the new PACS, which has to deal with the fact that some of the historical data is residing on another system. Each vendor should be able to design a solution that he thinks works best for hs customers, as long as the result is that the users can access the historical data from day one. The storage system is basically a standard SWF/PIR/MIR/IOCM Image Manager. Since it is going to be around for a long time, it should be possible to add new Storage SOP Classes and Transfer Syntaxes through configuration.

Note that this proposal is not an attempt to define a 'VNA'.