XX.3 USES FOR WADO WEB SERVICES

XX.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.

XX.3.2 Analysis of use cases

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

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

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

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

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

  5. 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.

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

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).

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.

XX.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:

These then become the following technical use cases.

XX.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:

  4. Individual SOP Instance

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

  6. The Response provides

  7. SOP instance, reformatted and subset as requested. This may be encoded as a DICOM PS 3.10 instance, or rendered into a generic image format such as JPEG.

XX.3.3.2 DICOM (Encoded Content) Requestor

  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 PS 3.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

  4. Requested Dataset

  5. Study UID

  6. List of Series UID

  7. List of SOP Instance UIDs

  8. Optionally, it may also specify subset information

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

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

  11. Anonymization

  12. The response provides

  13. SOP Instances, encoded per DICOM PS 3.10.

XX.3.3.3 Rendered (JPEG/PDF) Requestor

  1. The requesting system: application capable of making Web Service requests. System is not capable of decoding DICOM PS 3.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

  4. Requested Dataset

a) Study UID

b) List of Series UID

c) List of SOP Instance UIDs

  1. Desired format and subset information

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

  3. Frame selection for subsets of multi-frame objects

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

  5. Anonymize or not.

  6. Response information

  7. JPEGs

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

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

  10. PDFs

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

  12. Other encodings?

XX.3.3.4 Metadata (XML without pixel data, waveform data, etc) Requestor

  1. The requesting system: application capable of making Web Service requests. The requesting System is not capable of decoding DICOM PS 3.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

  4. Requested Dataset

a) Study UID

b) List of Series UID

c) List of SOP Instance UIDs

  1. Desired format and subset information

  2. XPath definition for subset or total metadata selection

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

  4. Frame selection for subsets of multi-frame objects

  5. Anonymize or not.

  6. Response information

  7. Response information

1. XML encoded metadata.