HHH.3 Uses For WADO-WS, WADO-RS and STOW-RS Services
Prev  HHH Evolution of WADO to Web and Rest Services (Informative)  Next

HHH.3 Uses For WADO-WS, WADO-RS and STOW-RS Services

HHH.3.1 General Requirements

Imaging information is important in the context of EMR/EHR. But EMR/EHR systems often do not support the DICOM protocol. The EMR/EHR vendors need access using web and web service technologies to satisfy their users.

HHH.3.2 Analysis of Use Cases

Examples of use cases / clinical scenarios, as the basis to develop the requirements, include:

  • Providing access to images and reports from a point-of-service application e.g., EMR.

  • Following references to significant images used to create an imaging report and displaying those images.

  • Following references / links to relevant images and imaging reports in email correspondence or clinical reports e.g., clinical summary.

  • Providing access to anonymized DICOM images and reports for clinical research and teaching purposes.

  • Providing access to a DICOM encoded imaging report associated with the DICOM IE (patient/study/series/objects) to support remote diagnostic workflows e.g., urgent medical incidents, remote consultation, clinical training, teleradiology/telemedicine applications.

  • Providing access to summary or selected information from DICOM objects.

  • Providing access to complete studies for caching, viewing, or image processing.

  • Storing DICOM SOP Instances using HTTP over a Network from PACS to PACS, from PACS to VNA, from VNA to VNA, from clinical application to PACS, or any other DICOM SCP.

  • Web clients, including mobile ones, retrieving XML and bulk data from a WADO-RS Service and adding new instances to a study.

Examples of the use cases described in 1 above are:

  1. The EMR displays in JPEG one image with annotations on it (patient and/or technique related), based upon information provided in a report.

  2. The EMR retrieves from a "Manifest" document all the referenced objects in DICOM and launches a DICOM viewer for displaying them (use case addressed by the IHE XDS-I.b profile).

  3. The EMR displays in JPEG one image per series with information describing every series (e.g., series description).

  4. The EMR displays in JPEG all the images of a series with information describing the series as well as every image (e.g., instance number and slice location for scanner images).

  5. The EMR populates in its database for all the instances referred in a manifest (KOS) the relevant information (study ID/UID/AccessionNumber/Description/DateTime, series UID/Modality/Description/DateTime, instance UID/InstanceNumber/SliceLocation).

  6. The EMR displays patient demographics and image slices in a browser by accessing studies through URLs that are cached and rendered in a remote data center.

  7. A hospital transfers a DICOM Study over a network to another healthcare provider without needing special ports opened in either firewall.

  8. A diagnostic visualization client, during post-processing, adds a series of Instances containing measurements, annotations, or reports.

  9. A healthcare provider transfers a DICOM Study to a Patient Health Record (PHR) at the request of the patient.

As an example, the 1c use case is decomposed in the following steps (all the other use cases can be implemented through a similar sequence of basic transactions):

  1. The EMR sends to the DICOM server the list of the objects ("selection"), asking for the object content.

  2. The DICOM server sends back the JPEG images corresponding to the listed objects.

  3. The EMR sends to the DICOM server the "selection" information for obtaining the relevant information about the objects retrieved.

  4. The DICOM server sends back the corresponding information in the form of a "metadata" document, converted in XML.

HHH.3.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:

  • Does it prefer the URI based requests, or the web-services based requests.

  • Does it have the ability to decode and utilize the DICOM PS3.10 format or not.

  • Does it need the metadata describing the image and its acquisition, and/or does it need an image to be displayed.

These then become the following technical use cases.

HHH.3.3.1 URI Based WADO Use Case

  1. The requesting system is Web Browser or other application that can make simple HTTP/HTTPS requests,

  2. Reference information is provided as URL or similar information that can be easily converted into a URL.

  3. The request specifies:

    1. Individual SOP Instance

    2. Desired format and subset selection for information to be returned

  4. The Response provides

    1. SOP instance, reformatted and subset as requested. This may be encoded as a DICOM PS3.10 instance, or rendered into a generic image format such as JPEG.

HHH.3.3.2 DICOM (Encoded Content) Requester

  1. The requesting system is an application capable of making Web Service requests and able to process data encoded as a DICOM File, per DICOM PS3.10 encodings.

  2. Reference information may come in a wide variety of forms. It is expected to include at least the Study UID, Series UID, and Individual SOP instance information. This may be encoded as part of an HL7 reference within a CDA document, a DICOM SOP Instance reference, or other formats.

  3. The request specifies

    1. Requested Data set

      1. Study UID

      2. List of Series UID

      3. List of SOP Instance UIDs

    2. Optionally, it may also specify subset information

      1. Instance and Frame Level Retrieve SOP classes subset information for selecting frames

      2. No-pixel data request (using the Transfer Syntax parameter)

      3. Anonymization

  4. The response provides

    1. SOP Instances, encoded per DICOM PS3.10.

HHH.3.3.3 Rendered (JPEG/PDF) Requester

  1. The requesting system: application capable of making Web Service requests. System is not capable of decoding DICOM PS3.10 formats. The system is capable of processing images in JPEG or other more generic formats.

  2. Reference information may come in a wide variety of forms. It is expected to include at least the Study UID, Series UID, and Individual SOP instance information. This may be encoded as part of an HL7 reference within a CDA document, a DICOM SOP Instance reference, or other formats.

  3. Request information

    1. Requested Data set

      1. Study UID

      2. List of Series UID

      3. List of SOP Instance UIDs

    2. Desired format and subset information

      1. JPEG/PDF/etc. selection, subset area, presentation information

      2. Frame selection for subsets of multi-frame objects

      3. What should be done for requests where image shapes and SOP classes vary and a subset is requested?

      4. Anonymize or not.

  4. Response information

    1. JPEGs

      1. Should JPEGs include tag information within the JPEG? If so, what information?

      2. How will JPEGs be related to multi-frame and multi-instance requests? Order? Tag?

    2. PDFs

      1. How will PDFs be related to multi-frame and multi-instance requests? One per frame? One per instance? One for entire set?

    3. Other encodings?

HHH.3.3.4 Metadata (XML Without Pixel Data, Waveform Data, etc.) Requester

  1. The requesting system: application capable of making Web Service requests. The requesting System is not capable of decoding DICOM PS3.10 formats. The system is capable of processing metadata that describes the image, provided that the metadata is encoded in an XML format. The system can be programmed based upon the DICOM definitions for XML encoding and attribute meanings.

  2. Reference information may come in a wide variety of forms. It is expected to include at least the Study UID, Series UID, and Individual SOP instance information. This may be encoded as part of an HL7 reference within a CDA document, a DICOM SOP Instance reference, or other formats.

  3. Request information

    1. Requested Data set

      1. Study UID

      2. List of Series UID

      3. List of SOP Instance UIDs

    2. Desired format and subset information

      1. XPath definition for subset or total metadata selection

      2. What should be done when SOP classes vary and a subset is requested? The XPath will fail.

      3. Frame selection for subsets of multi-frame objects

      4. Anonymize or not.

      5. Response information

  4. Response information

    1. XML encoded metadata.

HHH.3.3.5 DICOM Requester

  1. The requesting system is an application capable of making HTTP Service requests and able to process data encoded as a DICOM File, per DICOM PS3.10 encodings.

  2. Requesting information for DICOM Instances may come from a wide variety of forms. It is expected to include at least the Study UID. This may be encoded as part of an HL7 reference within a CDA document, a DICOM SOP Instance reference, or other formats.

  3. The request specifies

    1. Requested Data set

      1. Study UID

    2. Optionally, it may also specify subset information

      1. Series UID

      2. SOP Instance UID

  4. The response provides

    1. SOP Instances, encoded per DICOM PS3.10.

HHH.3.3.6 Frame Pixel Data Requester

  1. The requesting system is an application capable of making HTTP requests and able to process pixel data.

  2. Requesting information for pixel data may come in a wide variety of forms. It is expected to include at least the Study UID, Series UID, Individual SOP Instance, and Frame List information. This may be encoded as part of an HL7 reference within a CDA document, a DICOM SOP Instance reference, or other formats.

  3. The request specifies

    1. Requested Data set

      1. Study UID

      2. Series UID

      3. SOP Instance UID

      4. Frame List comprised of one or more frame numbers

  4. The response provides pixel data

HHH.3.3.7 Bulk Data Requester

  1. The requesting system is an application capable of making HTTP requests and able to process bulk data.

  2. Requesting information for bulk data may come in a wide variety of forms. It is expected to include the Bulk Data URL as provided by the RetrieveMetadata resource. This may be encoded as part of an HL7 reference within a CDA document, a DICOM SOP Instance reference, or other formats.

  3. The request specifies

    1. Requested Data set

      1. Bulk Data URL

  4. The response provides bulk data

HHH.3.3.8 Metadata Requester

  1. The requesting system is an application capable of making HTTP requests and able to process data encoded as a XML, per DICOM PS3.19 encodings.

  2. The Study UID may be obtained as part of an HL7 reference within a CDA document, a DICOM SOP Instance reference, or other formats.

  3. Request information

    1. Requested Data set

      1. Study UID

  4. The response provides full study metadata encoded in XML, encoded per DICOM PS3.19.

HHH.3.3.9 DICOM Creator

  1. The requesting system is an application capable of making HTTP/1.1 Service requests and able to process data encoded as PS3.10 binary instances.

  2. The request specifies

    1. The STOW-RS Service to store POST requests.

    2. Optionally, it may also specify Study Instance UID indicating all POST requests are for the indicated study.

    3. SOP Instances, per DICOM PS3.10 encoding.

  3. The response is a standard HTTP/1.1 status line and an XML response message body. The meaning of the success, warning, or failure statuses are defined in PS3.18.

HHH.3.3.10 Metadata and Bulk Data Creator

  1. The requesting system is an application capable of making HTTP/1.1 requests and able to process data encoded as PS3.19 XML metadata.

  2. The request specifies

    1. The STOW-RS Service to store POST requests.

    2. Optionally, it may also specify Study Instance UID indicating all POST requests are for the indicated study.

    3. XML metadata, per DICOM PS3.19 encodings, and bulk data.

  3. The response is a standard HTTP/1.1 status line and an XML response message body. The meaning of the success, warning, or failure statuses are defined in PS3.18.

Prev  Up  Next
HHH.2 Web and Rest Services Implementation  Home  HHH.4 Uses For QIDO Services