Radiology Data Migration - Brief Proposal

1. Proposed Workitem: Radiology Data Migration

Proposal Editor: Dave Harvey
Editor: Dave Harvey
Date: N/A (Wiki keeps history)
Version: N/A (Wiki keeps history)
Domain: Radiology

2. The Problem

Migration of radiology data (images, reports and possibly request) is currently a difficult and expensive integration job, requiring specialist skills from specialist vendors, and often requires goodwill (which may or may not be available) from the vendor(s) of the system(s) from whose systems the data is being migrated. Quite part from the data itself, there are ambiguities and problems relating to demographic updates, and ancillary data such as annotations.

A defined integration profile to standardise the manner in which the data is to be presented by the "Source" system, and acquired by the "Recipient" system could hugely simplify this process and reduce costs.

3. Key Use Case

A user has RIS and PACS from vendors A and B respectively, and wishes to migrate all historical data to new systems from vendors C & D. If all systems conformed to this profile, then the process would be well-defined and simpler/cheaper than it is now.

The same profile could be used for various other scenarios such as:

Migration to/from combined RIS/PACS
Migration to/from a vendor neutral archive
Bulk export to regional archives

4. Standards and Systems

PACS (Image Manager/Image Archive in Radiology profiles)
RIS (Report Manager in Radiology profiles)

Content Standards:

Images: DICOM
Reports: DICOM SR and/or HL7 V2 and/or HL7 V3 and/or HTML

Possible Communication Standards:

DICOM
FTP/HTTP (for a push model)
SMB/CIFS (for a pull model)

5. Discussion

This is a longstanding problem, which has not been solved by industry alone, but there is enough experience of good practice for IHE to be able to use as the basis for standardisation, and hence it is a good candidate a profile. There have also been extensive discussions, involving senior experts in the field on public discussion boards, and it has good user support, at least in the UK!

As a starting point, and for the purpose of this discussion, let's assume the following 2 actors:

Migration Source
Migration Recipient

The transaction details would depend on the transfer model selected.

The particular issues to be addressed would include:

Format of the data to migrate

For the images, this would obviously be DICOM, but in order to achieve best interoperability, constraints such as a limited list of transfer syntaxes would need to be specified. For reports, there is more room for discussion, as there are several competing possibilities, and it might be necessary to adopt few as listed above, with the rule that a Source could choose one of several formats, but a recipient must be able to accept all.

It is assumed that users would wish to migrate image annotations, and this might be via mandatory conversion to DICOM presentation state objects, but the scope and choice of exact SOP classes to be allowed would need clarification.

Patient Demographic Details

There would need to be rules detailing how demographic updates (and possibly other correction) applied to images and other data post acquisition should be communicated, with at least 3 possibilities:

Modify data sent to reflect latest status, losing/ignoring the history
Modify data sent to reflect latest status, and an additional means to capture the history
Send original data + update history

Push vs. Pull model

It is possible for data tansfer to be initiated by either the Source (push model) or Recipient (pull model) - both have their advantages and disadvantages, and this then impacts on the choice of transport mechanism.