This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

201801 Apps for Imaging Research

From HL7Wiki
Jump to navigation Jump to search


Apps for Imaging Research

Submitting WG/Project/Implementer Group

RSNA Image Sharing Project

Justification

The RSNA Image Share network was created (under a contract with NIH/NIBIB) to enable radiologists to share medical images with patients using personal health record (PHR) accounts, giving patients control over their medical images and radiology reports. Beginning in 2017, Image Share has worked with the NIH Sync for Science (S4S) program, which is designed to allow patients to consent to have their medical records used for research and to enable research apps to search for and retrieve records from consenting patient from clinical systems for relevant research. Image Share is working on adding medical images and radiology reports to the body of records available for sharing through S4S. The approach uses a combination of FHIR resources and DICOM web services with SMART on FHIR authorization to first search for (FHIR resources) and then retrieve (DICOM web services) radiology images.

Proposed Track Lead

  • Chris Carr (RSNA): ccarr@rsna.org
  • Steve Moore: moores@mir.wustl.edu -- skype id = stephenmmoore

Expected participants

This track would exercise systems in the following roles:

  • Research apps that will use FHIR and DICOM web services to retrieve images
  • EHR systems that will support retrieval of clinical data using the NIH Sync for Science program
  • DICOM web services enabled (QIDO-RS, WADO-RS) Picture, Archive and Communication Systems (PACS) that can supply imaging data.
  • Existing PACS who have not yet implemented DICOM web services

Roles

The NIH Sync for Science program is described here: Sync for Science. This program defines communication between a Research App and an EHR that use SMART on FHIR for authorization. The RSNA and NIH have expanded this to include imaging data with details listed below for each role.

Research App

The Research App will be expected to:

SMART on FHIR Enabled EHR

The EHR will be expected to:

  • Implement the API defined here to retrieve clinical data: S4S API Calls
  • Communicate with a Token Introspection Service to allow a broker system (FHIR Broker) to request authorization for image retrieval. Specifications are here: EHR S4S Imaging Requirements
  • (Optional) Directly support the FHIR ImagingStudy resource to support image search
  • (Optional) Support DICOM QIDO-RS and WADO-RS queries that will be passed through to a PACS. Detailed specifications are here: EHR S4S Imaging Requirements

S4S FHIR Broker

The FHIR Broker is designed to serve as a delegate for an EHR that supports the Sync for Science API but does not implement the imaging extensions. The FHIR Broker is required to:

  • Accept requests from a Research Application for image retrieval as defined here: FHIR Broker S4S Imaging Requirements
  • Communicate with a Token Introspection Service to determine if the Research Application is authorized to retrieve images for the specific patient (same document as above)
  • Use DICOM QIDO-RS and DICOM WADO-RS to query for and retrieve images from a PACS or DICOM-RS broker (same document as above)


S4S Token Introspection Service

The Token Introspection Service is intended to assist a FHIR Broker application that wants to use SMART on FHIR to authorize access to imaging studies. The FHIR Broker itself does not know how to issue OAuth bearer tokens (by design) and wants to use tokens issued by an EHR that does understand and implement SMART on FHIR. The Token Introspection Service provides an API to a FHIR Broker to allow the broker to determine if the token that the broker has is legal and permits the research application to have access to imaging data for a specific patient.

The Token Introspection Service has these requirements:

PACS

A PACS can participate in the S4S implementation by supporting the DICOM Web services (QIDO-RS, WADO-RS) or the traditional C-FIND and C-MOVE commands. In this FHIR Connectathon, we would only recruit PACS that implement the DICOM Web services. The PACS does not implement any direct FHIR resources. It does have these requirements:

  • Implement DICOM QIDO-RS. Allow inbound requests from an EHR or FHIR Broker without further security.
  • Implement DICOM WADO-RS. Allow inbound requests from an EHR or FHIR Broker without further security.

Scenarios

This track has a single end to end goal of allowing a Research App to retrieve images from a clinical PACS with the assistance of a SMART on FHIR enabled EHR. The scenario defines a set of transactions that can be implemented through an EHR or through the combination of an EHR and a FHIR Brokerk application. We will define test steps for both configurations. We also define test steps to enable a back end PACS to participate.

The first configuration tests a PACS that implements DICOM QIDO-RS and DICOM WADO-RS. We will attach the PACS to our S4S FHIR Broker and use test scripts to drive this work. Once this is successful, we can integrate the PACS into the larger workflow. If no PACS is available, we can skip this and use PACS simulators that we have.

In the second configuration, we are testing the communication between a Research App and a SMART on FHIR Enabled EHR. The S4S project defines how the Research App can obtain an access token from the EHR and retrieve data for a research subject. We will test that first (a necessary condition) and then test the retrieval of imaging studies. The second scenario assumes the EHR will support the S4S workflow but not necessarily the imaging requirements. If no EHR registers for this role, we can use an EHR that the S4S project has available online.

The third configuration is an extension of the second configuration. In the third configuration, the EHR actually supports the imaging requirements directly. The FHIR Broker is not needed. The EHR can communicate directly with the PACS to retrieve a list of imaging studies and to retrieve images to be returned to the Research App.

Configuration 1: PACS Testing

Action: The FHIR Broker makes direct QIDO-RS and WADO-RS requests of the PACS.
Precondition: PACS needs to be loaded with specific image sets that match patient MRN's known by the EHR.
Success Criteria: Logs on the FHIR Broker will indicate if the QIDO-RS and WADO-RS requests were successful. The FHIR Broker is a tool that has been developed by WUSTL. We have the ability to update the code and log what we need to demonstrate success.
Bonus point: The S4S protocol supports requests for new data after a certain point in time. It would be interesting to have the FHIR Broker send queries to the PACS that include date ranges to make sure the PACS filters appropriately.


Configuration 2: Research App / EHR / FHIR Broker / PACS

  • Research App obtains access token from SMART on FHIR Enabled EHR.
  • (Optional) Research App retrieves problem list from EHR. The FHIR resource is Condition.
  • Research App sends a search to the FHIR Broker for the ImagingStudy resources for a patient who has opted in to the research study.
    • FHIR Broker validates the request and sends a QIDO-RS request to the PACS to determine the answer.
    • FHIR Broker takes the response from the PACS, packages the response as a FHIR response, and returns that data to the Research App.
  • Research App performs a WADO-RS retrieve to the FHIR Broker for the images for a particular DICOM Study Instance UID.
    • FHIR Broker validates the request and sends a WADO-RS request to the PACS to retrieve the images.
    • FHIR Broker takes the response from the PACS and returns the WADO-RS quest to the Research App.


Configuration 3: Research App / EHR / PACS

This configuration removes the FHIR Broker because the EHR is able to support the imaging requests directly.

  • Research App obtains access token from SMART on FHIR Enabled EHR.
  • (Optional) Research App retrieves problem list from EHR. The FHIR resource is Condition.
    • EHR validates the request and sends a QIDO-RS request to the PACS to determine the answer.
    • EHR takes the response from the PACS, packages the response as a FHIR response, and returns that data to the Research App.
  • Research App performs a WADO-RS retrieve to the EHR for the images for a particular DICOM Study Instance UID.
    • EHR validates the request and sends a WADO-RS request to the PACS to retrieve the images.
    • EHR takes the response from the PACS and returns the WADO-RS quest to the Research App.

Simulators / Tools Provided

These are provided to fill in gaps.

  • PACS: We will bring a PACS implementation that implements the QIDO-RS and WADO-RS protocols.
  • FHIR Broker: This application supports the S4S imaging requests. It is used if no EHR supports them directly.
  • Introspection Service: This serves as a bridge between the FHIR Broker and EHR and enables the FHIR Broker to determine if the Research App is authorized to retrieve images for a specific subject.
  • Scripts to simulate a Research App: These are scripts and procedures that will allow us to obtain a bearer token from an EHR and use that token to perform queries. This is needed if no Research App is available.

TestScript(s)

Security and Privacy Considerations

Retrieved from "https://wiki.hl7.org/w/index.php?title=201801_Apps_for_Imaging_Research&oldid=149586"