HHH Evolution of WADO to Web and Rest Services (Informative)

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

HHH.1 Request and Response Parameters

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

The WADO-RS and STOW-RS requests have no parameters because data is requested through well defined URLs and content negotiation through HTTP headers.

The WADO-WS request parameters are summarized as below:

Table HHH.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 HHH.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 HHH.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 HHH.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


HHH.1.2 Response Parameters

HHH.1.2.1 URI WADO-URI

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.

HHH.1.2.2 WADO-WS

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.

HHH.1.2.3 WADO-RS

The WADO-RS Service is a transport service, as opposed to a rendering service, which provides resources that enable machine to machine transfers of binary instances, pixel data, bulk data, and metadata. These services are not primarily intended to be directly displayable in a browser.

In the REST Services implementation:

  • For the "DICOM Requester", one or more multipart/related parts are returned containing PS3.10 binary DICOM instances of a Study, Series, or a single Instance.

  • For the "Frame Pixel Data Requester", one or more multipart/related parts are returned containing the pixel data of a multi-frame SOP Instance.

  • For the "Bulk Data Requester", one or more multipart/related parts are returned containing the bulk data of a Study, Series or SOP Instance.

  • For the "Metadata Requester", an item is returned containing the XML encoded metadata selected from the retrieved objects header as described in the Native DICOM Model defined in PS3.19.

HHH.1.2.4 STOW-RS

The STOW-RS Service provides the ability to STore Over the Web using RESTful Services (i.e., HTTP/1.1 based functionality equivalent to C-Store).

  • For the "DICOM Creator", one or more multipart/related parts are stored (posted to a STOW-RS Service) containing one or more DICOM Composite SOP Instances.

  • For the "Metadata and Bulk Data Creator", one or more multipart/related parts are stored (posted to a STOW-RS Service) containing the XML encoded metadata defined in PS3.19 and one or more parts containing the bulk data of a Study, Series or SOP Instance.