Annex XX - Evolution of WADO to Web Services (Informative)

This annex discusses the design considerations that went into the definition of the WADO extension to Web services.

Add Annex XX to Part 17

XX.1 REQUEST AND RESPONSE PARAMETERS

XX.1.1 Request Parameters

The new service based on WS should continue to support all the request parameters defined by WADO, for maintaining backward compatibility with the present URI based WADO, including the options to return either native DICOM objects or a rendered object (JPEG, PDF etc.). These are summarized as below:

Table XX.1-1 Summary of DICOM/Rendered URI based WADO Parameters

Parameter Allowed for Requirement in Request
requestType DICOM & Rendered Required
studyUID DICOM & Rendered Required
seriesUID DICOM & Rendered Required
objectUID DICOM & Rendered Required
contentType DICOM & Rendered Optional
charset DICOM & Rendered Optional
anonymize DICOM Optional
annotation Rendered Optional
Rows, columns Rendered Optional
region Rendered Optional
windowCenter, windowWidth Rendered Optional
imageQuality DICOM & Rendered Optional
presentationUID Rendered Optional
presentationSeriesUID Rendered Optional
transferSyntax DICOM Optional
frameNumber DICOM & Rendered Optional

For the WS “DICOM Requester” transaction, the parameters will be the following:

Table XX.1-2 Summary of “DICOM Requester” WADO-WS Parameters

Parameter Requirement in Request Multiplicity
StudyRequest Required One
>SeriesRequest Required One or more
>>DocumentRequest Required One or more
>>>RepositoryUniqueId Optional One
>>>DocumentUniqueId Required One
>>>HomeCommunityId Optional One
>>>FrameNumber Optional One
>>>Anonymize Optional One
>>>TransferSyntaxUIDList Optional One
>>>>TransferSyntaxUID Required One or more

Table XX.1-3 Summary of “Rendered Requester” WADO-WS Parameters

Parameter Requirement in Request Multiplicity
StudyRequest Required One
>SeriesRequest Required One or more
>>DocumentRequest Required One or more
>>>RepositoryUniqueId Optional One
>>>DocumentUniqueId Required One
>>>HomeCommunityId Optional One
>>>Annotation Optional One
>>>Rows / Columns Optional One
>>>Region Optional One
>>>WindowCenter/ WindowWidth Optional One
>>>ImageQuality Optional One
>>>PresentationUID Optional One
>>>PresentationSeriesUID Optional One
>>>FrameNumber Optional One
>>>Anonymize Optional One
>>>ContentTypeList Required One
>>>>ContentType Required One or more
>>>CharsetList Optional One
>>>>Charset Required One or more

Table XX.1-4 Summary of “Metadata Requester” WADO-WS Parameters

Parameter Requirement in Request Multiplicity
StudyRequest Required One
>SeriesRequest Required One or more
>>DocumentRequest Required One or more
>>>RepositoryUniqueId Optional One
>>>DocumentUniqueId Required One
>>>HomeCommunityId Optional One
>>>Anonymize Optional One
>>>XPath Required One

XX.1.2 Response parameters

In the URI based WADO, the response is the single payload returned in the HTTP Get response. It may be the DICOM object in a DICOM format or in a rendered format.

In the Web Services implementation, for the “DICOM Requester” and the “Rendered Requester” transactions, one or more DICOM objects are returned using the MTOM/XOP mechanism as well as associated metadata.

For the “Metadata Requester” transaction, the response will contain the an XML encoded part containing the information selected from the retrieved objects header using the “XPath” filter as described in the Native DICOM Model defined in PS3.19.

XX.2 WEB SERVICES IMPLEMENTATION

The implementation architecture has to maximize interoperability, preserve or improve performance and minimize storage overhead.

The Web Services technologies have been selected to:

  1. be firewall friendly and supporting security,

  2. be supported by and interoperable between multiple development environments, and

  3. have sufficient performance for both large and small text and for binary data.

The XML implementation of the messages uses the CamelCase parameter style used in SOAP 1.2 (element names starting with an upper case character, e.g., ElementOne, attribute names starting with a lower case character e.g. attributeOne).

The response will be provided as list of instances in MTOM/XOP (“DICOM” or “Rendered” Requesters), XML encoded additional information resulting from the XPath filters applied on every objects selected (“Information Requester”)

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.

XX.4 IHE ITI COMPATIBILITY

There is a strong desire that the ITI Transaction RAD-69 be a proper implementation of the DICOM WS-* transaction. Note that RAD-69 is not the entire suite of XD* transactions. It is the “Retrieve Imaging Document Set” transaction.

The RAD-69 transaction is quite simple, can be difficult to find all the parts of the ITI documentation. In summary, the RAD-69 transaction is a WS request to the IHE “RequestDocumentSet” action and related endpoints. The request is a list of “DocumentRequest”, each “DocumentRequest” has three elements: required OID, required RepositoryID, and optional CommunityID. The response is a list of “DocumentResponse”. Each “DocumentResponse” has four elements: required OID, required RepositoryID, required Document, and optional CommunityID.

The mapping to DICOM for OID would be SOP Instance UID, and Document the DICOM contents. RepositoryID is analogous to the AE Title. It is not a perfect mapping. IHE considers the configuration where one system acts as a front end for multiple other systems, each identified by a RepositoryID. The CommunityID is an extension of this to “communities” that exchange data through gateways. The gateways will use the RepositoryID to identify internal repository systems.

RAD-69 requires no understanding of document contents. They are binary blobs that are identified by an OID.

XX.5 PROXY AGENT FOR NON-WS DICOM ARCHIVE

Rapid acceptance will be enhanced if a proxy system that automatically converts between the WS notation and the older DICOM C-FIND/etc transaction can be defined; and if this conversion can be simple. Proxy systems can also simplify security configuration.