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)

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. The federated query concept is not "novel", but is indeed well proven and successful and hence is appropriate for standardization in a profile.

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 use

the local site identifiers so that the local site can seamlessly integrate them

• 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)

<List existing systems that are/could be involved in the problem/solution.>

<If known, list standards which might be relevant to the solution>

5. Discussion

<Include additional discussion or consider a few details which might be useful for the detailed proposal>

<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>

<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>

<What are some of the risks or open issues to be addressed?>

<This is the brief proposal. Try to keep it to 1 or at most 2 pages>

<Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>