WADO Enhanced URI Work Item timothy.culp@harris.com

DICOM WG-27 RSNA November 2011

Agenda Overview Open Issues Enhanced URI Request/Response   Questions/Comments

Overview Explain to everyone what we’ve done to get

here…

Open Issues Normalized Metadata

Currently metadata will be returned using the same schema as WADO Web Services defined in PS3.19.

It would be more efficient to return metadata in a normalized form when requesting it at the study or series level.

WG-06 is submitting a multiframe work item that will address the normalization of metadata across a series or study.

This supplement will inherit those changes when they become available.

Open Issues (cont) Returning a list of SOP Instances

Is there a standard way to represent a list in a URL? For returning a list of SOP Instances, are we going to

concatenate the list of UIDs into the URL? Are there limitations on the the length of a URL? The URL could not be generated by hand but the

intention for this interface is for enabling machine to machine transfers of data, not human to browser display.

For purposes of this design, we suggest the following: To return a single instance (GET):

/studies/{studyid}/series/{seriesid}/instances/{uid} To return a set of instances from a series (GET or POST):

/studies/{studyid}/series/{seriesid}/instances{?uid1,uid2,uid3}

Open Issues (cont) HTTP Accept Headers

When requesting a study, series, or instances through the Enhanced URI Interface, the data can be returned as DICOM objects or zip file containing XML and/or binary.

The format of the request is indicated in the HTTP Accept Header.

The accept header will specify application/dicom for the former and application/wado for the latter.

Open Issues (cont) Transfer Syntax

Transfer syntax can also be part of the content negotiation since it is requesting the same information in another format.

The response shall be the Transfer Syntax requested if possible. If it is not possible for the response to be sent using the requested transfer syntax then the Explicit VR Little Endian Uncompressed Transfer Syntax shall be used.

There are probably two main uses cases that account for 95% of user requests: User wants data returned in the format in it’s native format User wants the data uncompressed because they do not

have the necessary codecs to decompress

Open Issues (cont) Private metadata

If we use the metadata schema as defined in PS3.19, is there a mechanism for including private XML tags without making a change to the schema?

How are new tags incorporated within this schema – does it affect the XSD?

Open Issues (cont) Metadata Info vs Xpath

Is there a use case for Study Metadata Info? The original use case was to be able to get high level summary

of studies on a server for sorting/filtering/searching/indexing without having to download and parse all of the metadata.

XPath filtering would provide the same information, although it puts more burden on the end user to formulate the query and more burden on the server to return the result.

It also prevents the study info from getting cached. However, XPath is more flexible than “info” because users can select the information that’s important to them.

Since the use case we identified is more a function of “searching” versus “transporting” DICOM, our suggestion is to drop the info resource and leave it up to the QIDO search engine.

Open Issues (cont) Parameters vs resource

Most proxy servers do not cache URL’s with a ? in the URL (browsers do but that isn’t our target client). We want to support greater caching capability to a larger audience (proxy servers as well as browsers). This supports greater caching capability for all base URL resources which point to static resources where parameter notation is better for user specific requests.

Our recommendation is static content should be in the base URL, and any custom request such as a region of an image, etc should and could be URL params and those should be not expected to be cached.

An important caching use case is reverse proxies at edges, where the same study is likely to be looked at by multiple people, e.g. techs, rads, referrings.

For a good discussion on best practices for caching, see http://code.google.com/speed/page-speed/docs/caching.html.

Enhanced URI Request/Response The DICOM WADO Enhanced URI Interface defines

several resources. An implementation shall support at least one of these endpoints. The endpoints are: RetrieveStudy - This resource retrieves the full set of DICOM

instances related to the study returned in a multipart mime response

RetrieveSeries - This resource retrieves a series as a set of DICOM objects returned in a multipart mime response

RetrieveInstance - This resource retrieves a range of SOP Instances as a set of DICOM objects returned in a multipart mime response

RetrieveMetadata - This action retrieves the study level metadata or a subset as defined by an XPath filter.

All XML responses shall be encoded as described in the Native DICOM Model defined in PS3.19.

By default, DICOM objects returned shall be encoded in Explicit VR Little Endian (see 8.2.11 for more information on Transfer Syntax UID).

RetrieveStudy Request

Resource {SERVER_ROOT}/studies/{StudyInstanceUID}

SERVER_ROOT is the base url for the web servers WADO URI service. This may be a combination of host, port, and protocol(http or https)

{StudyInstanceUID} is the unique StudyInstanceUID for a single study. Method

GET Accept

application/dicom Specifies to the URI service the response should be in DICOM

object format. application/wado

Specifies to the URI service the response should be zip file including study level metadata as XML and bulk data as binary format.

RetrieveStudy Response

The response format can depend on the Accept header the request specified. The two possible response formats are application/dicom and application/wado. Both response formats have a content type of multipart/x-mixed-replace with a boundary separation of “BinaryItemBoundary-7afb50349c2148c3a5d6a324891a481c”

Type: application/dicom (Content-Type: multipart/x-mixed-replace) Each binary item in the multipart response represents a DICOM

SOP instance object. The entire multipart response contains every instance for the study specified.

Type: application/wado (Content-Type: multipart/x-mixed-replace) The first item in the response is study level metadata. Each

following binary item is the binary data portion of a SOP instance.

RetrieveSeries Request

RetrieveSeries Response

RetrieveInstance Request

RetrieveInstance Response

RetrieveMetadata Request

RetrieveMetadata Response