8.1 Parameters available for all DICOM Persistent Objects

Parameters specified in this section are applicable to all supported DICOM SOP Classes.

Note: To identify a DICOM Object, only one UID is required, because any UID is globally unique. However, the standard requires that the UID of the higher levels in the DICOM Information Model are specified (i.e., series and study), in order to support the use of DICOM devices that support only the baseline hierarchical (rather than extended relational) Query/Retrieve model, which requires the Study Instance UID and Series Instance UID to be defined when retrieving an SOP Instance, as defined in PS 3.4.

8.1.1 Request type

Type of request performed. This parameter is REQUIRED for URI based mode.

The parameter name shall be “requestType”.

The value shall be "WADO".

Note: This parameter allows other types of requests to be introduced in the future, using a similar syntax.

8.1.2 Unique identifier of the study

Study Instance UID as defined in PS 3.3. This parameter is REQUIRED.

The parameter name shall be “studyUID” for URI based mode, and “StudyRequest” which contains a required “studyInstanceUID” attribute for the WS mode .

The value shall be encoded as a Unique Identifier (UID) string, as specified in PS 3.5, except that it shall not be padded to an even length with a NULL character.

8.1.3 Unique identifier of the series

Series Instance UID as defined in the PS 3.3. This parameter is REQUIRED.

The parameter name shall be “seriesUID” for URI based mode, and, for the WS mode, one or multiple “SeriesRequest” which is included into the above described “StudyRequest” and which contains a required “seriesInstanceUID” attribute .

The value shall be encoded as a Unique Identifier (UID) string, as specified in PS 3.5, except that it shall not be padded to an even length with a NULL character.

8.1.4 Unique identifier of the object

SOP Instance UID as defined in the PS 3.3. This parameter is REQUIRED.

The parameter name shall be “objectUID” for URI based mode, and for the WS mode one or multiple “DocumentRequest” which is included into the above described “SeriesRequest” and which include each one:

The value shall be encoded as a unique identifier (UID) string, as specified in PS 3.5, except that it shall not be padded to an even length with a NULL character.

8.1.5 MIME type of the response

MIME types desired by the Web Client for the response from the Server, as defined in the IETF RFC2616. This parameter is OPTIONAL for URI based mode, it shall be present for the WS mode “Rendered Requester” and shall not be present in the other WS mode transactions .

The parameter name shall be “contentType” for URI based mode, and, for the WS mode, “ContentTypeList” which contains one or multiple “ContentType” .

In URI based mode, t T he value shall be a list of MIME types, separated by a "," character, and potentially associated with relative degree of preference, as specified in IETF RFC2616. In WS mode, it contains one or more “ContentType” elements containing each one MIME type.

In URI based mode, t T he Web Client shall provide list of content types it supports in the "Accept" field of the Get method. The value of the ContentType parameter of the request shall be one of the values specified in that field.

Notes: 1. In URI based mode, typically the Accept field will be sent by a Web Client as “*/*”, which is compatible with any MIME types.

2. When this parameter is absent, the default content type of the response is dictated by the "MIME type constraints" sub-sections of Section 7 (i.e. 7.1.2, 7.2.2, 7.3.2, 7.4.2).

8.1.6 Charset of the response

Character set with which the returned object s is to be encoded, as defined in the IETF RFC2616. This parameter is OPTIONAL for URI based mode, and for the WS mode “Rendered Requester” and shall not be present in the other WS mode transactions .

The parameter name shall be “charset” for URI based mode, and “CharsetList” containing one or more elements “Charset” for the WS mode .

For the URI mode, the value shall be a list of character sets, separated by a "," character, and potentially associated with relative degree of preference, as specified in IETF RFC2616.

In URI based mode, t T he Web Client may provide a list of character sets it supports in the "Accept-charset" field of the Get method. If this field is present, the value of the charset parameter of the request shall be one of the values specified in it.

The Web Server may or may not support character set conversion. If character set conversion is supported:

Notes: 1. The IANA Character Set registrations specify names and multiple aliases for most character sets. The standard value for use in WADO is the one marked by IANA as "preferred for MIME." If IANA has not marked one of the aliases as "preferred for MIME", the name used in DICOM shall be the value used for WADO.

2. The table in Annex D provides an informative mapping of some IANA values to DICOM Specific Character Set Defined Terms.

8.1.7 Anonymize objects

Removal of all patient identification information from within the DICOM object s , if not already done, as defined in PS 3.15. This parameter is OPTIONAL. In the URI based mode, it shall only be present if contentType is application/dicom.

This parameter is Optional.

The parameter name shall be “anonymize” for URI based mode, and “Anonymize” for the WS mode .

The value shall be “yes”.

The Server may return an error if it either cannot or refuses to anonymize that these object s .

In WS mode, the metadata describing the objects or information extracted from them in the response shall be anonymized if requested.

The Server shall return a new SOP Instance UID if the content of the object s has not already been anonymized.

Notes: 1. This standard does not introduce any security-related requirements. It is likely that the information contained within DICOM objects identifies the patient. The protocol used (that is HTTP) can be replaced by HTTPs, which is its secure extension, to protect the information in transit. The underlying DICOM implementation decides whether or not to grant access to a particular DICOM object based on whatever security policy or mechanism it has in place. A server is unlikely to fulfill a request from an unknown user (e.g., accessed via the HTTP protocol) unless it is certain that the data requested has no patient identifying information within it and has been approved for public viewing.

2. The Anonymize object enables, for example, teaching files systems or clinical trial applications to offer an access to original images stored in a PACS, without disclosing the patients identity, and requiring storage of a (de-identified) copy of the original image s . Anonymization is the responsibility of the Server. In order to preserve patient confidentiality, the Server likely will refuse to deliver an anonymized SOP instance to an unknown or unauthorized person unless the Server is certain that the SOP instance holds no patient identifying information. This would include "blanking out" any annotation area(s) containing nominative information burned into the pixels or in the overlays.

8.1.9 Retrieve partial information from objects

Retrieval of additional information from the DICOM objects, using a filtering mechanism based on the XML mapping of DICOM IODs, as described in the Native DICOM Model defined in PS 3.19. This parameter is defined only for the WS mode “Information Requester” transaction.

The parameter name shall be “XPath”.