Federated DICOM Query Retrieve - Proposal

1. Proposed Workitem: Federated DICOM Query/Retrieve (FDQR)

• Proposal Editor: David Clunie, Neelam Dugar, Kinson Ho
• Editor: Kinson Ho and David Clunie
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology

2. The Problem

Patients are often treated in multiple hospitals within a clinical Network, e.g., an Oncology Network, Trauma Network, etc. Clinicians and radiologists managing patients need access to the full consolidated imaging history to provide efficient and effective treatments.

The medical scientific literature describes the consequence of the lack of such access as duplicate imaging with the attendant delays in care, costs and unnecessary radiation dose.

This continues to be a problem despite the use of CDs, the ability to "push" images on demand, proprietary imaging sharing solutions and other centralized architectures that presume the availability of non-trivial infrastructure resources and significant upgrades in functionality by each network participant.

Though federated DICOM query/retrieve is available in some commercial products, there is value in standardizing:

• the package of capabilities necessary to satisfy the use cases and the handling of identifiers in the query and retrieve requests and in the returned retrieved objects
• the integration with sources of patient identity mapping between identity domains
• the mechanisms to perform patient identity mapping using demographics returned in queries
• the use of non-local identifiers that span identity domains (such as the NHS Number)

3. Key Use Case

Clinical review of patients in a network

• Medical staff managing patients need access to all available images for a patient who may or may not have had imaging performed elsewhere in the network
• When viewing images for a patient, all images available anywhere in the network are listed and accessible for side-by-side display with local images at the users request

• within a clinically acceptable response time
• grouped together and labelled with the patient's local Patient ID and related demographic information

Trauma or other emergency transfer

• When medical staff at a receiving site are evaluating a patient for possible transfer from a remote site for advanced care, images acquired at the remote site are accessible to the evaluating staff

Reporting radiologist views priors

• When reporting locally acquired images, all available images for a patient elsewhere on the network are accessible as easily as locally acquired priors, and can be displayed side-by-side display with local images.

Prefetching

• For any use case, to the extent that the need for local viewing of images from elsewhere in the network can be anticipated, selective or complete pre-fetching may be needed to provide sufficient responsiveness to be clinically usable.

4. Standards and Systems

• DICOM C-FIND and C-MOVE
• IHE SWF
• IHE PIX
• IHE PDQ
• IHE MIMA (wrt. aspects of communicating multiple identifiers and issuers if needed)

All installed base PACS support the DICOM Query/Retrieve Service Class (C-FIND, C-MOVE) and those that are Image Managers/Archives in the Scheduled Workflow profile already support a significantly enhanced set of query matching and return keys, likely sufficient to support the use cases in this proposal.

Performing a federated query requires a new Actor that:

• is configurable to know the addresses (IP, port, AET) of participating remote sites that will respond to queries
• is configurable to know the identity domain identifier of each site (e.g., "Patient Identification Domain Assigning Authority for PIX)
• has access to a means of mapping local identifiers in the query from the local site to the identifiers to be used in the query to each remote site

Identity mapping may be performed by:

• PIX
• PDQ
• recognition of a common identifier that spans identity domains (e.g., NHS Number)
• the equivalent of PDQ performed using demographic information obtained by DICOM C-FIND

Performing a federated retrieval requires the new Actor:

• is configurable with the same addresses as for the query
• is configurable with the same identity domain information as for the query
• is able to apply the same identity mapping as for the query
• is configurable as a C-MOVE destination in each of the remote sites
• is configurable to accept incoming C-STORE operations from the remote sites
• can coerce the identifiers in all of the retrieved DICOM instances to from the remote site identifiers to the local site identifiers so that the local site can seamlessly integrate the images (without the local site needing to recognize foreign identifiers or issuers)
• can forward the retrieved (identity coerced) images to the local site (requires the local site is configurable to accept incoming C-STORE operations from the new actor)

5. Discussion

Experience and Feasibility

The federated query concept is not particularly "novel", but rather is well proven and successful and hence is appropriate for standardization in a profile.

Relationship to existing profiles

This is a "cross enterprise" scenario, but in the absence of the necessary infrastructure or additional funding or resources or political will, Cross-enterprise_Document_Sharing_for_Imaging and Cross-Community_Access_-_Images_(XCA-I) may not be available. There is a huge installed base of "conventional" PACS with DICOM Query/Retrieve Service interfaces that can be leveraged without requiring upgrades or new systems at every participating network site.

Various proprietary solutions have been developed to address this problem, including transmission to centralized archives and federated DICOM queries, and each may be appropriate to address specific deployment scenarios and best leverage available resources. The centralized archive approach has already been addressed by the MIMA profile.

Security and Information Governance Considerations

The requirements to use DICOM protocols such as C-FIND, C-MOVE and C-STORE outside a single enterprise ("beyond the firewall") are well established and require such approaches as:

• secure connections, which are achievable using DICOM over TLS, or more commonly, VPNs.
• firewall configurations open to incoming DICOM connections (associations) from a constrained range of sources to a specific port forwarded to appropriately secured servers
• business agreements to share access to (subsets of) patient data including demographics and images

In practice these requirements are likely no more or less burdensome than agreeing to and implementing shared access using any mechanism (DICOM or not).

Open Issues

• Which of the many forms of PIX (Patient Identifier Cross-Referencing HL7 V2, Patient Identifier Cross-Reference HL7 v3, or RESTful mPIX should be required)
• Access to images and image-related information such as annotations and modality-generated Structured Reports is clearly within scope; a more complicated issue is access to radiologist-generated reports - if these are available as DICOM SRs, or DICOM encapsulated CDAs, then there is no reason not to share them using the same mechanism (no special action is required), but mandating that reports be made available that way may be beyond the scope of this profile.