Imaging information is important in the context of EMR/EHR. But EMR/EHR systems often do not support DICOM service classes. The EMR/EHR vendors need access using web and web service technologies to satisfy their users.
Examples of use cases / clinical scenarios, used as the basis for the development of the QIDO-RS requirements, include:
Search from EMR
Populating FHIR resources
Worklist in Viewer
Study Import Duplication Check
Multiple System Query
Clinical Reconstruction
Mobile Device Access
A General Practitioner (GP) in a clinic would like to check for imaging studies for the current patient. These studies are stored in a PACS, Vendor Neutral Archive (VNA) or HIE that supports QIDO functionality. The GP launches an Electronic Medical Record (EMR) application, and keys in the patient demographics to search for the patient record within the EMR. Once the record is open, the EMR, using QIDO, makes requests to the back-end systems, supplying Patient ID (including issuer) and possibly other parameters (date of birth, date range, modality, etc.). That system returns the available studies along with meta-data for each study that will help the GP select the study to open. The meta-data would include, but is not limited to, Study Description, Study Date, Modality, and Referring Physician.
HL7 has introduced FHIR (Fast Healthcare Interoperability Resources) as a means of providing access to healthcare informatics information using RESTful web services.
While FHIR will not replicate the information contained in a PACS or other medical imaging storage system, it is desirable for FHIR to present a view of the medical imaging studies available for a particular patient along with the means of retrieving the imaging data using other RESTful services.
A Radiologist, is reading studies in the office, using software that maintains diagnostic orders for the facility. This system produces the radiology worklist of studies to be read and provides meta-data about each scheduled procedure, including the Study Instance UID. When the next study is selected to be read on the worklist, the system, using the Study Instance UID, makes a QIDO request to the local archive to discover the instances and relevant study meta-data associated with the procedure to display. Subsequent QIDO requests are made to the local archive and to connected VNA archives to discover candidate relevant prior studies for that patient.
For each candidate relevant prior, the full study metadata will be retrieved using WADO-RS and processed to generate the list of relevant priors.
A Radiologist is working in a satellite clinic, which has a system with QIDO functionality and small image cache. The main hospital with which the clinic is affiliated has a system with QIDO functionality and a large historical image archive or VNA. The viewing software displays a worklist of patients, and a study is selected for viewing. The viewer checks for prior studies, by making QIDO requests to both the local cache and remote archive using the Patient ID, Name and Date of Birth, if available. If the Patient Identifier isn't available, other means (such as by other demographics, or a Master Patient Index) could be utilized. Any studies that meet relevant prior criteria can be pre-fetched.
A Neurologist is preparing a surgical plan for a patient with a brain tumor using three-dimensional reconstruction software, which takes CT images and builds a 3D model of various structures. After supplying the patient demographics (or Patient Identifier), the software requests a list of appropriate studies for reconstruction (based on Study Date, Body Region and Modality). Once the user has selected a study and series, the software contacts the QIDO server again, requesting the SOP Instance UIDs of all images of a certain thickness (specified in specific DICOM tags) and frame of reference to be returned. The software then uses this information to retrieve, using the WADO-RS service, the appropriate DICOM objects needed to prepare the rendered volume for display.
A General Practitioner (GP) has left the medical ward for a few hours, and is paged with a request to look at a patient X-Ray image in order to grant a discharge. The GP carries a smart phone that has been pre-loaded with credentials and secured. The device makes a QIDO request to the server, to look for studies from the last hour that list the GP as the Referring Physician. The GP is able to retrieve and view the matching studies, and can make a determination whether to return to the ward for further review or to sign the discharge order using the phone.
The use cases described above in terms of clinical scenarios correspond to the following technical implementation scenarios. In each case the use is distinguished by the capabilities of the requesting system:
Does it prefer XML or JSON results?
Does it need to perform searches at the Series and Instance level or can it process the full Study metadata?
What attributes does it need to search against?
What attributes does it need for each matching Study, Series or Composite Instance?
These questions can be applied to the use cases:
Search from EMR
JSON or XML
Study
Study Instance UID, Patient ID
Accession Number, Issuer of Accession Number, Study Description, Study Date, Modality, Number of Series, Number of Instances
Populating FHIR resources
JSON or XML
Study, Series and Instance
Patient ID and Issuer of Patient ID
All attributes required by the FHIR Imaging Study Resource (see http://www.hl7.org/implement/standards/fhir/imagingstudy.htm)
Worklist in Viewer
JSON or XML
Study
Study Instance UID, Patient ID, Issuer of Patient ID
Series Instance UIDs, SOP Instance UIDs, patient demographics, Study Description, Study Date, Modality, Referring Physician
Study Import Duplication Check
JSON or XML
Study
Study Instance UID, Series Instance UID, SOP Instance UID
Study Instance UID
Multiple System Query
JSON or XML
Study
Patient ID, Issuer of Patient ID, Patient Name, Patient Date of Birth
Study Instance UID, Accession Number, Study Description, Study Date, Modalities in Study
Clinical Reconstruction
JSON or XML
Study, Series, Instance
Study Instance UID, Series Instance UID
SOP Instance UID, Image Instance Level Attributes
Mobile Device Access
JSON
Study, Series and Instance
Patient ID, Issuer of Patient ID, Patient Name, Patient Date of Birth, Study Date, Referring Physician
Instance Date/time, Modalities in Study
These then become the following technical use cases.
The requesting web-based application can make QIDO-RS requests, parse XML and then make WADO-RS requests
The request specifies:
Multipart XML
Search parameters, including:
Patient ID
Issuer of Patient ID
Patient Name
Study Description
Study Date
Modalities in Study
Referring Physician
etc.
The Response provides
One PS3.19 XML NativeDicomModel element for each matching Study
All requested DICOM attributes for each matching Study
WADO-RS Retrieve URL for each matching Study
The requesting system identifies the Studies of interest and uses WADO-RS to retrieve data
The requesting system is a simple web-based application that can make QIDO-RS requests and parse XML and then make WADO URL requests
The request specifies:
Multipart XML
Search parameters, including:
Patient ID
Issuer of Patient ID
Patient Name
Patient Date of Birth
Study Description
Study Date
Modalities in Study
Referring Physician
The Response provides
One PS3.19 XML NativeDicomModel element for each matching Study
All requested DICOM attributes for each matching Study
The requesting system identifies the Study of interest and uses Search For Series to identify a series of interest
[repeat B-D for Series, Instance]
The requesting system uses WADO URL to retrieve specific instances
The requesting system is a mobile application that can make QIDO-RS requests, parse JSON and then make WADO URL requests.
The request specifies:
JSON
Search parameters, including:
Patient ID
Issuer of Patient ID
Patient Name
Patient Date of Birth
Study Description
Study Date
Modalities in Study
Referring Physician
The Response provides
One DICOM JSON element containing all matching Studies
All requested DICOM attributes for each matching Study
The requesting system identifies the Study of interest and uses Search For Series to identify a series of interest
[repeat B-D for Series, Instance]
The requesting system uses WADO URL to retrieve specific instances