HHH.4 Uses For QIDO Services

HHH.4.1 General Requirements

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.

HHH.4.2 Analysis of Use Cases

Examples of use cases / clinical scenarios, used as the basis for the development of the QIDO-RS requirements, include:

  1. Search from EMR

  2. Populating FHIR resources

  3. Worklist in Viewer

  4. Study Import Duplication Check

  5. Multiple System Query

  6. Clinical Reconstruction

  7. Mobile Device Access

HHH.4.2.1 Search From EMR

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.

HHH.4.2.2 Populating FHIR Resources

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.

HHH.4.2.3 Worklist in Viewer

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.

HHH.4.2.4 Multiple Systems Query

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.

HHH.4.2.5 Clinical Reconstruction

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.

HHH.4.2.6 Mobile Device Access

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.

HHH.4.3 Description of The Use Cases

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:

  1. Does it prefer XML or JSON results?

  2. Does it need to perform searches at the Series and Instance level or can it process the full Study metadata?

  3. What attributes does it need to search against?

  4. What attributes does it need for each matching Study, Series or Composite Instance?

These questions can be applied to the use cases:

  1. Search from EMR

    1. JSON or XML

    2. Study

    3. Study Instance UID, Patient ID

    4. Accession Number, Issuer of Accession Number, Study Description, Study Date, Modality, Number of Series, Number of Instances

  2. Populating FHIR resources

    1. JSON or XML

    2. Study, Series and Instance

    3. Patient ID and Issuer of Patient ID

    4. All attributes required by the FHIR Imaging Study Resource (see http://www.hl7.org/implement/standards/fhir/imagingstudy.htm)

  3. Worklist in Viewer

    1. JSON or XML

    2. Study

    3. Study Instance UID, Patient ID, Issuer of Patient ID

    4. Series Instance UIDs, SOP Instance UIDs, patient demographics, Study Description, Study Date, Modality, Referring Physician

  4. Study Import Duplication Check

    1. JSON or XML

    2. Study

    3. Study Instance UID, Series Instance UID, SOP Instance UID

    4. Study Instance UID

  5. Multiple System Query

    1. JSON or XML

    2. Study

    3. Patient ID, Issuer of Patient ID, Patient Name, Patient Date of Birth

    4. Study Instance UID, Accession Number, Study Description, Study Date, Modalities in Study

  6. Clinical Reconstruction

    1. JSON or XML

    2. Study, Series, Instance

    3. Study Instance UID, Series Instance UID

    4. SOP Instance UID, Image Instance Level Attributes

  7. Mobile Device Access

    1. JSON

    2. Study, Series and Instance

    3. Patient ID, Issuer of Patient ID, Patient Name, Patient Date of Birth, Study Date, Referring Physician

    4. Instance Date/time, Modalities in Study

These then become the following technical use cases.

HHH.4.3.1 XML Study Search Use Case

  1. The requesting web-based application can make QIDO-RS requests, parse XML and then make WADO-RS requests

  2. The request specifies:

    1. Multipart XML

    2. Search parameters, including:

      1. Patient ID

      2. Issuer of Patient ID

      3. Patient Name

      4. Study Description

      5. Study Date

      6. Modalities in Study

      7. Referring Physician

      8. etc.

  3. The Response provides

    1. One PS3.19 XML NativeDicomModel element for each matching Study

    2. All requested DICOM attributes for each matching Study

    3. WADO-RS Retrieve URL for each matching Study

  4. The requesting system identifies the Studies of interest and uses WADO-RS to retrieve data

HHH.4.3.2 XML Study, Series and Instance Search Use Case

  1. The requesting system is a simple web-based application that can make QIDO-RS requests and parse XML and then make WADO URL requests

  2. The request specifies:

    1. Multipart XML

    2. Search parameters, including:

      1. Patient ID

      2. Issuer of Patient ID

      3. Patient Name

      4. Patient Date of Birth

      5. Study Description

      6. Study Date

      7. Modalities in Study

      8. Referring Physician

  3. The Response provides

    1. One PS3.19 XML NativeDicomModel element for each matching Study

    2. All requested DICOM attributes for each matching Study

  4. The requesting system identifies the Study of interest and uses Search For Series to identify a series of interest

  5. [repeat B-D for Series, Instance]

  6. The requesting system uses WADO URL to retrieve specific instances

HHH.4.3.3 JSON Use Case

  1. The requesting system is a mobile application that can make QIDO-RS requests, parse JSON and then make WADO URL requests.

  2. The request specifies:

    1. JSON

    2. Search parameters, including:

      1. Patient ID

      2. Issuer of Patient ID

      3. Patient Name

      4. Patient Date of Birth

      5. Study Description

      6. Study Date

      7. Modalities in Study

      8. Referring Physician

  3. The Response provides

    1. One DICOM JSON element containing all matching Studies

    2. All requested DICOM attributes for each matching Study

  4. The requesting system identifies the Study of interest and uses Search For Series to identify a series of interest

  5. [repeat B-D for Series, Instance]

  6. The requesting system uses WADO URL to retrieve specific instances