Parameters specified in this section are applicable to all supported DICOM SOP Classes.
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 PS3.4.
Type of request performed. This parameter is REQUIRED for URI based mode.
The parameter name shall be "requestType".
The value shall be "WADO".
This parameter allows other types of requests to be introduced in the future, using a similar syntax.
Study Instance UID as defined in PS3.3. This parameter is REQUIRED.
The parameter name shall be "studyUID" for URI based mode, and "StudyRequest" that contains a required "studyInstanceUID" attribute for the WS mode.
The value shall be encoded as a Unique Identifier (UID) string, as specified in PS3.5, except that it shall not be padded to an even length with a NULL character.
Series Instance UID as defined in the PS3.3. This parameter is REQUIRED.
The parameter name shall be "seriesUID" for URI based mode, and, for the WS mode, one or multiple "SeriesRequest" that is included into the above described "StudyRequest" and that contains a required "seriesInstanceUID" attribute.
The value shall be encoded as a Unique Identifier (UID) string, as specified in PS3.5, except that it shall not be padded to an even length with a NULL character.
SOP Instance UID as defined in the PS3.3. This parameter is REQUIRED.
The parameter name shall be "objectUID" for URI based mode, and for the WS mode one or multiple "DocumentRequest" that is included into the above described "SeriesRequest" and that include each one:
a required "DocumentUniqueId" that contains the Instance UID,
an optional "RepositoryUniqueId" that contains the UID of the DICOM server, and
an optional "HomeCommunityId" that contains the UID of the "clinical affinity domain".
The value shall be encoded as a unique identifier (UID) string, as specified in PS3.5, except that it shall not be padded to an even length with a NULL character.
MIME type(s) 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" that contains one or multiple "ContentType".
In URI based mode, the 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, the 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.
Typically the Accept field will be sent by a Web Client as "*/*", which is compatible with any MIME types.
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).
Character set with which the returned objects are 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, the 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:
text based DICOM objects retrieved other than as application/dicom MIME type (e.g., text/plain) may be returned in the requested character set (converted if necessary)
DICOM objects retrieved as application/dicom MIME type have all contained strings returned in the requested character set (converted if necessary) and the Specific Character Set (0008,0005) updated (if necessary)
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.
The table in Annex D provides an informative mapping of some IANA values to DICOM Specific Character Set Defined Terms.
Removal of all patient identification information from within the DICOM objects, if not already done, as defined in PS3.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 these objects.
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 has not already been anonymized.
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.
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. 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.
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 PS3.19. This parameter is defined only for the WS mode "Information Requester" transaction.
The parameter name shall be "XPath".