This wiki has undergone a migration to Confluence found Here
Difference between revisions of "201801 Apps for Imaging Research"
Jump to navigation
Jump to search
Stephenmoore (talk | contribs) (→Roles) |
Stephenmoore (talk | contribs) |
||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 8: | Line 8: | ||
==Justification== | ==Justification== | ||
| − | Image Share | + | 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. |
| − | |||
| − | |||
| − | to | ||
| − | The approach uses a combination of FHIR resources and DICOM web services with | ||
| − | |||
==Proposed Track Lead== | ==Proposed Track Lead== | ||
| Line 29: | Line 24: | ||
==Roles== | ==Roles== | ||
The NIH Sync for Science program is described here: [http://syncfor.science Sync for Science]. | The NIH Sync for Science program is described here: [http://syncfor.science Sync for Science]. | ||
| − | This program defines communication between a Research App and an EHR that use | + | 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. | The RSNA and NIH have expanded this to include imaging data with details listed below for each role. | ||
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | <!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | ||
===Research App=== | ===Research App=== | ||
The Research App will be expected to: | The Research App will be expected to: | ||
| − | * Implement the API defined here to retrieve clinical data: [http://syncfor.science/api-calls] | + | * Implement the API defined here to retrieve clinical data: [http://syncfor.science/api-calls S4S API calls] |
| − | * Implement the API defined here to retrieve imaging data: | + | * Implement the API defined here to retrieve imaging data: [https://docs.google.com/document/d/e/2PACX-1vTvp0iLc9JMjbkoaYbl3w3jW8BJ64qDEbBkJtfLoI6oSiC4hKYeZlrltF-DCi3RR-P5EgRjj5SvB-YK/pub Research App S4S Imaging Requirements] |
| − | |||
| − | + | ===SMART on FHIR Enabled EHR=== | |
| − | === | ||
The EHR will be expected to: | The EHR will be expected to: | ||
| − | * Implement the API defined here to retrieve clinical data: [http://syncfor.science/api-calls] | + | * Implement the API defined here to retrieve clinical data: [http://syncfor.science/api-calls 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: | + | * Communicate with a Token Introspection Service to allow a broker system (FHIR Broker) to request authorization for image retrieval. Specifications are here: [https://docs.google.com/document/d/e/2PACX-1vRnHr2wL0hQvqZum0fneD45GyqIjaHs144iApike-AxVUPwhQP3matTV-SjdAZlTZ3xGd_ySKh3u4Bk/pub EHR S4S Imaging Requirements] |
* (Optional) Directly support the FHIR ImagingStudy resource to support image search | * (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: | + | * (Optional) Support DICOM QIDO-RS and WADO-RS queries that will be passed through to a PACS. Detailed specifications are here: [https://docs.google.com/document/d/e/2PACX-1vRnHr2wL0hQvqZum0fneD45GyqIjaHs144iApike-AxVUPwhQP3matTV-SjdAZlTZ3xGd_ySKh3u4Bk/pub EHR S4S Imaging Requirements] |
===S4S FHIR Broker=== | ===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 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: | The FHIR Broker is required to: | ||
| − | * Accept .. | + | * Accept requests from a Research Application for image retrieval as defined here: [https://docs.google.com/document/d/e/2PACX-1vScikaB3h8RbEUudNeV9iE9BvM8hnaoBnlCWhvz0jGMOeHfpbJ7fK_flzk9m8_Nz3AqWMrwUOcVCNFY/pub 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=== | ===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: [https://docs.google.com/document/d/e/2PACX-1vQxbPf6OsstRyCD_SvGTEiuBFChlLJqm9FLiu7PmmfV2YCWPkpYbvoVmRdMFautZuKuC3wFfwVnWFBF/pub Token Introspection Service S4S Imaging Requirements] | ||
===PACS=== | ===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== | ==Scenarios== | ||
<!-- What will be the actions performed by participants? --> | <!-- What will be the actions performed by participants? --> | ||
| + | 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: <!--Who does what? (Use the role names listed above when referring to the participants -->The FHIR Broker makes direct QIDO-RS and WADO-RS requests of the PACS. | ||
| + | :Precondition: <!-- What setup is required prior to executing this step? -->PACS needs to be loaded with specific image sets that match patient MRN's known by the EHR. | ||
| + | :Success Criteria: <!-- How will the participants know if the test was successful? -->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: <!-- Any additional complexity to make the scenario more challenging -->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)== | ==TestScript(s)== | ||
Latest revision as of 17:12, 4 December 2017
Apps for Imaging Research
Submitting WG/Project/Implementer Group
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
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.
