201801 Apps for Imaging Research

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:

• Implement the API defined here to retrieve clinical data: S4S API calls
• Implement the API defined here to retrieve imaging data: Research App S4S Imaging Requirements

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:

• Implement the API defined here: Token Introspection Service S4S Imaging 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

Scenario Step 1 Access Token

Action: Research App obtains access token from SMART on FHIR Enabled EHR.

Precondition: Research App and EHR have previously configured this relationship

Success Criteria: With the token, Research App is able to pull a Patient resource from the EHR.

Bonus point: Research App retrieves problem list from EHR. The FHIR resource is Condition.

Scenario Step 2 ImagingStudy

Action: Research App retrieves list of ImagingStudy resources from S4S FHIR Broker.

Precondition: Research App has previously obtained an access token as described in Step 1.

Success Criteria: The S4S FHIR Broker logs will indicate if the request was received and returned. The real proof will come in Step 3.

Bonus point: Update the PACS on the backend with new data acquired today. Ask the Research App to retrieve data that has been updated. The Research App should only see the new data and not the original imaging studies.

Scenario Step 3 Retrieve Images For a Specific ImagingStudy

Action: Research App retrieves the images for at least one of the imaging studies retrieved in Step 2.

Precondition: Research App has previously obtained completed Step 2.

Success Criteria: The Research App does not have requirements on what it must do with the images. We will have to consult logs for both the Research App and the FHIR Broker to determine success.

Bonus point: