Difference between revisions of "Federated DICOM Query Retrieve - Proposal"

From IHE Wiki
Jump to navigation Jump to search
Line 15: Line 15:
  
 
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.
 
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==
 
==3. Key Use Case==

Revision as of 06:49, 13 August 2015

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

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, and 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 in the past 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.

Though federated DICOM query/retrieve is available in 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 has not been standardized
  • the integration with sources of patient identity mapping between identity domains, using PIX and/or PDQ
  • the mechanisms to perform patient identity mapping using DICOM C-FIND requests for patient demographics to be mapped.
  • the use of single identifiers that span identity domains (such as the NHS Number)


<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.>