14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 1
New Structure of Part 18
Open Issues

5
URI or URL
Notice and Disclamer
Forward
1 Scope
2 Conformance
3 Normative References
10
4 Term and Definitions
DICOM Terms
Attribute
Tag
Instance
15
instanceUID
object
objecID
Series
seriesUID
20
Study
studyUID
HTTP Terms
Content Coding
25
An encoding transformation that can be applied to a representation. Content codings are
primarily used to allow a representation to be compressed or otherwise transformed without
losing the identity of its underlying media type and without loss of information. See [rfc7231,
Section 3.1.2.1< https://tools.ietf.org/html/rfc7231#section-3.1.2.1 >] for details.
Version
Method
30
Resource
Target Resource
Header Fields
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 2
Payload
Status Code
35
Reason Phrase
Web Terms
URI Terms
Scheme
Authority
40
Path
Query Component
Query Parameter
Fragment
5 Symbols and Abbreviated Terms
45
6 Web Services Overview
READ THIS SECTION FIRST!!!! These requirement apply to all DICOMweb services.
This section is intended to be a preamble for sections 7, 8, and 9..
6.1 HTTP/HTTPS Transactions
6.2 HTTP fundamentals
50
Case-Sensitivity
URIs
Defined in http://tools.ietf.org/html/rfc3986#section-3.4 and http://tools.ietf.org/html/rfc3986#section-6

55


URI – for all URIs % encoded triplets are case insensitive and should be normalized to
uppercase.
Scheme and Host are case insensitive and should be normalized to lowercase
All other part of the URI are defined by HTTP 3280 to be case sensitive
HTTP Header Field Names are case insensitive
All transfer-coding names are case insensitive
Connection options are case insensitive
60
Conventions we are following
6.3 Service Description
Each service defined in this standard is described according to:
65
1. The components of the request messages;
2. The behavior of the Origin-Server; and
3. The components of the response message.
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 3
6.3.1 Request Message
GET {
The request message is composed of:
70




A required resource,
zero or more query parameters,
a set of header fields, and
a possibly empty payload.
Note
75
None of the protocols or services defined in this Part of the Standard use the Fragment Component
[ref] of the request URI.
6.3.1.1
Resource
DICOMweb uses the URI syntax as defined in [RFC 3986 Uniform Resource Identifier (URI): Generic
Syntax< https://tools.ietf.org/html/rfc3986 >].
6.3.1.2
80
85
Query Parameters
DICOMweb uses the Query Component of the URI [RFC 3986< https://tools.ietf.org/html/rfc3986 >] to
specify parameters, called Query Parameters. Query parameters are used to further specify the meaning
of request messages.
DICOMweb extends the URI grammar defined in [RFC 3986< https://tools.ietf.org/html/rfc3986 >] by
defining the syntax of Query Parameters using [RFC 5234 Augmented BNF for Syntax Specifications:
ABNF< https://tools.ietf.org/html/rfc5234 >].
The syntax of query parameters is defined as follows:
90
95
100
105
query-component
parameter
name
value
char
unreserved
pct-encoded
special
=
=
=
=
=
=
=
=
parameter [ *("&" parameter) ]
name "="" value
1*(ALPHA) *( ALPHA / DIGIT / "_")
*char [ *(“,” *char) ]
unreserved / pct-encoded / special
ALPHA / DIGIT / "-" / "." / "_" / "~"
"%" HEXDIG HEXDIG
"/" / "?" / ":" / "@" / "!" / "$" / "'"
/ "(" / ")" / "*" / "+" / ";"
query-component
parameter
name
value
pchar
unreserved
pct-encoded
special
=
=
=
=
=
=
=
=
parameter [ *("&" parameter) ]
name "="" value
*qchar *( ALPHA / DIGIT / "_")
*pchar [ *(“,” *pchar) ]
unreserved / pct-encoded / special
ALPHA / DIGIT / "-" / "." / "_" / "~"
"%" HEXDIG HEXDIG
"/" / "?" / ":" / "@" / "!" / "$" / "'"
/ "(" / ")" / "*" / "+" / "," / ";"
Note
1. This grammar allows the query component to contain any legal characters as defined by RFC 3986.
14 November 2014
110
Sup 183 Web Services Re-Documentation (v4)
Page 4
2. No whitespace is permitted in URIs. Whitespace around line breaks and the line breaks themselves
should be stripped before parsing the URI (See RFC 3986 Appendix C).
3. If the "?" appears in the URI then there must be a legal query parameter in the URI. [RFC 3986] does
not permit an empty query component.
4. The grammar above uses <char> instead of <pchar> to limit the scope of parameter names to legal
identifiers in most programming languages.
115
5. The <unreserved>, and <pct-encoded> rules above are defined in [RFC 3986].
6.3.1.3
Header Fields
6.3.1.3.1
120
Content Negotiation
All DICOMweb service requests that expect to receive a response with a payload should provide one or
more of the following content negotiation header fields [ref https://tools.ietf.org/html/rfc7231#section-5.3].
Accept
The Accept header field is used by User-Agents to specify a list of media types that are
acceptable in the response payload. See [RFC7231, Section 5.3.2 <
https://tools.ietf.org/html/rfc7231#section-5.3.2] >].
125
The media types in the Accept header can be given a priority ordering by using [Quality Values<
https://tools.ietf.org/html/rfc7231#section-5.3.1 >].
DICOMweb has extended the use of this header field and recommends that all requests use this
header field.
Accept-Encoding
130
The Accept-Encoding header field is used by User-Agents to specify a list of content-codings
[RFC7231, Section 3.1.2.1< https://tools.ietf.org/html/rfc7231#section-3.1.2.1>] that are
acceptable in the response payload.
Accept-Charset
135
The Accept-Charset header field is used by User-Agents to specify a list of character set names
that are acceptable in the response payload with one of the textual media types. See [RFC7231,
Section 5.3.3< https://tools.ietf.org/html/rfc7231#section-5.3.3>].
Textual media types are identified in Table x.y.z.
140
Character set names are case-insensitive. The User-Agent shall use IANA Character Set Names
if defined in the [IANA Character Sets registry < http://www.iana.org/assignments/character-sets
>].
Appendix XX lists DICOM character sets with links to their corresponding names in the IANA
Character Set registry.
Accept-Language
145
The Accept-Language header field is used by User-Agents to specify a list of natural languages
that are preferred in the response payload. See [IETF RFC7231, Section 5.3.5 <
https://tools.ietf.org/html/rfc7231#section-5.3.5>].
DICOMweb does not define any use of this header field.
6.3.1.3.2
150
Representation Metadata
The header fields described in this section are used to specify the representations contained in the
payload of a message. All messages that contain a payload should include the following header fields.
Content-Type
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 5
The Content-Type header field is used to specify the media type of the payload. Depending on
the media type this header field may not fully specify the contents of the payload. See [RFC7231,
Section 3.1.1.5< https://tools.ietf.org/html/rfc7231#section-3.1.1.5 >].
155
Content-Location
The Content-Location header field is used to specify a URI that references the specific resource
corresponding to the representation in this message's payload. See [RFC7231, Section 3.1.4.2<
https://tools.ietf.org/html/rfc7231#section-3.1.4.2 >].
Content-Length
160
The Content-Length header field is used to describe the length of the payload.
When the payload does not include the length of the payload, the Content-Length header field is
required.
for messages with that include a payload body, the Content-Length field-value provides the
framing information necessary for determining where the body (and message) ends. For
messages that do not include a payload body, the Content-Length indicates the size of the
selected representation (Section 3 of [RFC7231]).
165
This header field shall be present when there is a payload that without content codings
The following optional header fields are used to specify information about the payload:
Content-Encoding
170
TODO
Content-Language
TODO
6.3.1.3.3
Header Field Parameters
Quality Values
175
6.3.1.4
Payload
180
The message body (if any) of an HTTP message is used to carry the payload body or payload of that
request or response. The message body is identical to the payload unless a transfer coding has been
applied, as described in [RFC 7230, Section 3.3.1< https://tools.ietf.org/html/rfc7230#section-3.3.1 >].
This standard uses the terms payload, payload body, and message payload interchangeably to denote
the message body before any transfer coding has been applied to it.
All messages have payloads, but the payload may be empty, i.e. length = zero.
The rules for when a payload is allowed in a message differ for requests and responses.

185

The presence of a message body in a request is signaled by a Content-Length or TransferEncoding header field.
The presence of a message body in a response depends on both the request method to which it
is responding and the response (status code)< https://tools.ietf.org/html/rfc7230#section-3.1.2 >.
6.3.2 Behavior
The Behavior section of the Service describes processing that occurs on the Origin-Server base on the
information in the request message, in order to create the information in the response message.
190
[We need to discuss the semantics of the request, target resource set, and what media types are use,
DICOMweb behavior is different from 7231.5.3.2]
The Origin-Server shall return an error if it cannot provide the representation in any acceptable media
type. This constrains the behavior defined in [RFC7231, Section 5.3.2< >].
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 6
There are no requirements for language negotiation in DICOM.
195
6.3.3 Response Message
The response message is composed of:
200




A required status code,
an optional reason phase,
a set of header fields, and
a possibly empty payload.
The following sections explain the contents of these components.
6.3.3.1
Status
This part of the service description defines the status codes and associated reason phrases that are
available in the response.
205
6.3.3.2
Header Fields
This part of the service descriptions defines the header fields that are required, conditionally required, or
optional in the response.
If the response has a payload some or all of the Representation Metadata header fields (see [ref]) should
be present.
210
6.3.3.3
Payload
The presence of a payload in a response depends on both the request method to which it is responding
and the response (status code)< https://tools.ietf.org/html/rfc7230#section-3.1.2 >.
6.3.4 Media Types
215
Each protocol, and in some cases services, have a section that describes the media types supported by
the protocol or service.
7 URI Protocol (WADO-URI)
7.1 Introduction
[explain why it is called URI and give some history]
Include references
220
7.2 URI Services
The URI Protocol is composed of the following services:
Retrieve DICOM Service
Returns a single DICOM instance by retrieving the resource in the ‘application/dicom’ media type.
Retrieve Rendered Service
225
Returns a single image by rendering the resource in an acceptable media type.
Retrieve Rendered Presentation State Service
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 7
Returns a single image by rendering the presentation state specified by the resource in an
acceptable media-type.
7.2.1 Request
230
All URI Services have the following request message format.
GET { +service } { ?query } HTTP/1.1 CRLF
{ headers } CRLF
CRLF
Note
235
1.
Literal characters in the format are in bold face, parameters are specified using URI
Templates<ref>, the symbol CRLF stands for the US-ASCII carriage return (0x12) and linefeed
(0x13) literal characters.
2.
The URI protocol uses the HTTP protocol version 1.1.
All URI Protocol request messages
240
245





use the GET method,
use the HTTP/1.1 protocol,
use the standard content negotiation[RFC7230, Section < >] header fields, and
require the object identification query parameters,
comply with the following sections.????
7.2.1.1
Service
{ +service } specifies the address of the service. It is composed of the authority and path
components of the URI.
7.2.1.2
Query Parameters
7.2.1.2.1
250
Object Identification Parameters
User-Agents shall include all parameters in this section in all URI requests. The Origin-Server shall
support all parameters in this section.
7.2.1.2.1.1
Request Type
requestType = WADO
The “requestType” specifies that this is a URI (WADO) request. Its value shall be "WADO".
255
7.2.1.2.2
Unique Identifier of the Study
studyUID = { uid }
The “studyUID” parameter identifies the study that contains the object of this request. Its value shall be
a Study Instance UID, as defined in PS 3.3 [ref], except that it shall not be padded to an even length with
a NULL character.
260
7.2.1.2.3
Unique Identifier of the Series
seriesUID = { uid }
The “seriesUID” parameter identifies the series that contains the object of this request. Its value shall be
a Series Instance UID, as defined in PS 3.3 [ref].
7.2.1.2.4
265
Unique Identifier of the Instance
objectUID = { uid }
The “objectUID” parameter identifies the instance that contains the object of this request. Its value shall
be a SOP Instance UID, as defined in PS 3.3 [ref].
14 November 2014
7.2.1.3
Page 8
Other Query Parameters
7.2.1.3.1
270
Sup 183 Web Services Re-Documentation (v4)
De-Identify
TODO
7.2.1.3.2
Media Type of the Response (Retired)
This section was previously defined in DICOM. It is now retired. See PS 3.18-2014b.
Media types are specified using the Accept header field. See [Section < # >].
7.2.1.3.3
275
Transfer Syntax UID (Retired)
This section was previously defined in DICOM. It is now retired. See PS 3.18-2014b.
Transfer syntax is specified as a media type parameter in the Accept or Content-Type header fields as
appropriate. See …
7.2.1.3.4
Charset of the Response (Retired)
This section was previously defined in DICOM. It is now retired. See PS 3.18-2014b.
280
Character set is specified using the Accept-Charset header field. See Section x.y.z< >.
7.2.1.4
Header Fields
User-Agents shall support all parameters in this section in all URI requests.
Required:
Accept
285
[move ]The Accept header field is used to specify a list a media types that are acceptable to the
User-Agent in the response payload. It is recommended that the Accept header be used in
preference to the “contentType” query parameter (see ref) and that it be included in all request
messages. (See ref)
Optional:
290
Accept-Charset
[move] The Accept-Charset header is used to specify the character sets that are acceptable to
the User-Agent in the response payload. It is recommended that the Accept header be used in
preference to the “charset” query parameter (see ref) and that it be included in all request
messages. (See ref)
295
7.2.1.5
Request Payload
URI Services have an empty request payload.
7.2.2 Behavior
300
The Origen-Server uses the object identification query parameters to specify the instance that is the
target of the request. The processing of that instance and the response are specified in the individual
URI services define below.
7.2.3 Response
7.2.3.1
Status Codes
Table 7.2-x specifies status codes that URI services can return.
Table 7.2-x Status Codes for URI Services
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 9
Status Reason Phrase Description
200
400
404
406
410
503
305
Note
7.2.3.2
OK
Bad Request
Not Found
Not Acceptable
Gone
Busy
The requested resource is contained in the payload.
Malformed resource
Specified resource does not exist
Accept type, Transfer Syntax or decompression method not supported
Specified resource was deleted
Service is unavailable
The Reason Phrase listed in Table 7.2-x are those suggested in the HTTP standard, but they should not
be relied upon. The reason phrase is designed to be human readable and the Origin-Server is free to
provide its own reason phrase.
Header Fields
Recommended:
310
Content-Type
See [ref].
Content-Location
See [ref].
Recommend If:
Content-Length
The payload has no transfer codings applied to it.
See [ref]’.
Optional:
315
Content-Encoding:
See [ref].
Content-Language:
See [ref].
7.2.3.3
Payload
Each of the URI Services define the media types available in their response payloads.
7.3 Retrieve DICOM Service
320
The Retrieve DICOM Service specifies a single DICOM SOP Instance in the request and receives a
single DICOM SOP Instance in PS 3.10 format in a successful response.
7.3.1 Request
The Retrieve DICOM Service request message has the same format as all URI request messages,
except for the following differences:
325
7.3.1.1
Resource
Specifies the address of this service.
7.3.1.2
Query Parameters
This service supports the object identification query parameters and the anonymize query parameter.
7.3.1.3
330
Header Fields
The value of the Accept header field shall be ‘application/dicom’ media type.
7.3.1.4
Payload
The request payload is empty.
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 10
7.3.2 Behavior
335
The Origin-Server retrieves the instance specified in the object identification query parameters and
returns it in the response.
7.3.3 Response
7.3.3.1
Status Codes
See section [ref].
7.3.3.2
340
Header Fields
Required:
Content-Type
See [ref].
Content-Location
See [ref].
Required If:
Content-Length
345
See [ref].
Optional:
Content-Encoding
See [ref].
Content-Language
See [ref].
7.3.3.3
350
The response payload has no transfer codings applied to it.
Payload
The Retrieve DICOM response payload is a composite DICOM object in the format defined in PS
3.10[ref].
7.3.4 Media Types
The Retrieve DICOM service only supports the ‘application/dicom’ media type (see ref).
7.4 URI Retrieve Rendered Service
The URI Retrieve Rendered Service retrieves instances in a rendered media type.
355
7.4.1 Request
The URI Retrieve Rendered request message has the same format as all URI request messages, except
for the following differences:
360
1. The referenced object may not be a presentation series on instance object.
3. The service provides additional query parameters that specify how the Origin-Server should
render the DICOM object.
7.4.1.1
Resource
The resource component of the URI specifies this service.
7.4.1.2
365
Query Parameters
In addition to the object identification query parameters available to all URI services [ref], This service
supports additional query parameters that specify how the identified object is rendered.
The following rules pertain to all parameters defined in this section:
14 November 2014
370
Sup 183 Web Services Re-Documentation (v4)
Page 11
1. All parameters in this section are optional.
2. These parameters only apply to image and video media types, as defined in Section X.X,
and therefore, shall not be present for any DICOM media types.
3. The data types of the parameter values are defined in Section [ref]
4. Unless otherwise specified the image (or selected region) is sent in its original size.
7.4.1.2.1
Annotation on the Object
annotation = { patient | technique }
375
The “annotation” parameter specifies that annotations should be applied to the retrieved image. Its value
shall be a non-empty, comma separated list of one or more of the following items:
patient
– displays patient information (e.g., patient name, birth date, etc.)
technique – displays technique information (e.g., image number, study date, image position, etc.).
When used in conjunction with the region parameter, it shall be applied after the selection??? of the
region.
380
The exact nature and presentation of the annotation is determined by the Origin-Server.
7.4.1.2.2
Number of Pixel Rows
rows = { integer }
The “rows” parameter specifies the height in pixels of the returned image. The returned image shall have
the same aspect ratio as the original image.
385
Note:
7.4.1.2.3
If both "rows" and "columns" are specified, then the Origin-Server will choose one arbitrarily.
Number of Pixel Columns
columns = { integer }
The “columns” parameter specifies the width in pixels of the returned image. The returned image shall
have the same aspect ratio as the original image.
390
Note
7.4.1.2.4
See note in Number of Pixel Columns above.
Region of the Image
region = { top, left, bottom, right }
The “region” parameter requests a rectangular region of the original image. Its value shall be a list of four
comma separated, positive secimal strings, representing in the following order:
395
400
top
left
bottom
right
the top row of the region,
the left column of the region,
the bottom row of the region,
the right column of the region,
The region is specified using a normalized coordinate system relative to the size of the original image,
measured in rows and columns. Where
0.0 corresponds to the top row and left column of the image,
1.0 corresponds to the bottom row and right column of the image, and
0.0 <= top < bottom <= 1.0, and
0.0 <= left < right <= 1.0.
405
Note:
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 12
The Origin-Server may not support this parameter. If this parameter is supported, an image
corresponding to the specified region shall be returned with size corresponding to the specified
normalized coordinates.
7.4.1.2.5
410
Window Center of the Image
windowCenter={ decimal }
The “windowCenter” parameter controls the luminosity of the returned images, as defined in PS3.3. If the
“windowWidth” parameter is present, this parameter shall also be present.
7.4.1.2.6
Window Width of the Image
windowWidth={ decimal }
415
The “windowWidth” parameter controls the contrast of the returned images, as defined in PS3.3. If the
“windowCenter” parameter is present, this parameter shall also be present.
7.4.1.2.7
Frame Number
frameNumber = { integer }
420
The “frameNumber” parameter specifies the frame number of an image within the multi-frame object
specified by the object identification query parameters. It shall be ignored for all objects other than multiframe objects.
7.4.1.2.8
Image Quality
imageQuality = { integer }
425
The “imageQuality” parameter controls the relative quality of lossy compressed images. Its value is an
Integer string that ranges from 1 to 100 inclusive, 100 having the best quality.
Note
1. Decompression and re-compression may degrade the image quality if the original image was already
irreversibly compressed. If the image is in already in a compressed format, it may be sent as it is
without decompressing and re-compressing it.
430
2. The meaning of this parameter depends on the media type and is determined by the Origin-Server.
7.4.1.3
Header Fields
See Section 5.3.1.4< >.
7.4.1.4
Payload
The request payload shall be empty.
435
7.4.2 Behavior
7.4.3 Response
The URI Rendered Retrieve service response message has the properties defined below.
7.4.3.1
Status Codes
See Section [ref].
440
7.4.3.2
Header Fields
Recommended:
Content-Type
See [ref].
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 13
Content-Location See [ref].
Recommended If:
445
Content-Length:
See [ref].
Optional:
Content-Encoding See [ref].
Content-Language See [ref].
7.4.3.3
450
Payload
A successful response payload contains a DICOM instance rendered in one of the requested media types
7.4.4 Media Types
**** Start Here ****
455
Table 7.3-x below defines the default, required, and recommended media types for the URI Retrieve
Rendered service. Other media types may be supported and should be included in the conformance
statement.
TODO insert table
7.5 URI Retrieve Presentation State Service
460
The URI Retrieve Presentation State Service retrieves a rendering of the instance specified by the object
identification query parameters [ref], where the seriesUID specifies a presentation state series and the
instanceUID specifies a presentation instance.
7.5.1 Request
Transactions in this service use the GET method. The request syntax is:
465
GET {+service} {? query} CRLF
{*headers} CRLF
CRLF
The request message has the same format as all URI request messages, except for the following
differences:
470
1. The referenced resource shall be a presentation state instance object.
2. The media types specified in the request shall not be ‘application/dicom’.
4. The Retrieve Presentation State service provides additional query parameters that specify how the
Origin-Server should render the DICOM object before returning it in the payload.
7.5.2 Transactions
This service supports one transaction:
475
Retrieve Rendered Presentation State Instance
For this transaction the User-Agent requests that the Origin-Server render the instance referenced by the
target presentation state series and instance and return it in the response.
14 November 2014
7.5.2.1
480
Sup 183 Web Services Re-Documentation (v4)
Page 14
Resource Path
The resource path specifies the address of this service. The User-Agent shall only specify resources that
reference presentation states.
7.5.2.2
Query Parameters
7.5.2.3
Query Parameters
7.5.2.3.1
Unique Identifier of the Presentation Object
presentationUID={UID}
485
The “presentationUID” parameter specifies a SOP Instance UID of a presentation state object. It is
required. 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.
If this parameter is combined with region and/or annotation parameter(s), the presentation state shall be
applied to the images prior to selecting a region and burning in annotations.
490
If the Presentation Size Mode in the presentation state is SCALE TO FIT or TRUE SIZE, then the
displayed area specified in the presentation shall be scaled to fit the size specified by the rows and
columns parameters if present, otherwise the displayed area selected in the presentation state will be
returned without scaling.
Note
495
1.
The intent of the TRUE SIZE mode in the presentation state cannot be satisfied, since the physical size
of the pixels displayed by the web browser is unlikely to be known. If the Presentation Size Mode in the
presentation state is MAGNIFY, then the displayed area specified in the presentation shall be magnified
(scaled) as specified in the presentation state. It will then be cropped to fit the size specified by the rows
and columns parameters, if present.
500
2.
Any Displayed Area relative annotations specified in the presentation state are rendered relative to the
Specified Displayed Area within the presentation state, not the size of the returned image.
Though the output of the presentation state is defined in DICOM to be in P-Values (grayscale values
intended for display on a device calibrated to the DICOM Grayscale Standard Display Function
PS3.14), the grayscale or color space for the images returned by the request is not defined by this
standard.
505
7.5.2.3.2
Unique Identifier of the Series Containing the Presentation Object
presentationUID={UID}
510
The “presentationSeriesUID” parameter specifies the Series Instance UID of the series containing the
presentation state instance specified by the “presentationUID”. It is required. The value shall be encoded
as a unique identifier (UID ), except that it shall not be padded to an even length with a NULL character.
Note:
7.5.2.3.3
As specified in DICOM, the Presentation State will be in the same study as the images it applies to.
De-Identify
deidentify
515
The “deidentify” parameter requests that all Personally Identifiable Information [ref] be omitted from the
returned object(s). See PS 3.15, Annex E.
7.5.2.3.4
Volume of Interest Lookup Table (VOI LUT)
voiLutSequenceItemNumber = { integer }
The “voiLutSequenceItemNumber” parameter specifies the VOI LUT Sequence (0028,3010) Item to be
used to render the returned images.
14 November 2014
520
7.5.2.4
Sup 183 Web Services Re-Documentation (v4)
Page 15
Response Header Fields
Same as above. See…
7.5.2.5
Response Payload
The response payload will contain the object referenced by the “presentationUID” rendered in one of the
requested media types as specified by the presentation state instance.
525
7.5.3 Media Types
See Table x.y.z.
8 WS Protocol
Three services with one transaction each.
8.1 Overview
530
What query parameters.
8.2 WS Services
8.2.1 Request
535
8.2.1.1
Resource
8.2.1.2
Query Parameters
Explain how study, series and instance parameters are used to specify one presentation instance to
return.
8.2.1.3
Header Fields
8.2.1.4
Payload
8.2.2 Behavior
540
8.2.3 Response
8.2.3.1
Status Codes
8.2.3.2
Header Fields
8.2.3.3
Payload
8.2.4 Media Types
545
8.3 WS Retrieve Imaging Document Set Service
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
8.3.1 Request
550
8.3.1.1
Resource
8.3.1.2
Query Parameters
8.3.1.3
Header Fields
8.3.1.4
Payload
8.3.2 Behavior
8.3.3 Response
555
8.3.3.1
Status Codes
8.3.3.2
Header Fields
8.3.3.3
Payload
8.3.4 Media Types
8.4 WS Retrieve Imaging Document Set Service
8.4.1 Request
560
8.4.1.1
Resource
8.4.1.2
Query Parameters
8.4.1.3
Header Fields
8.4.1.4
Payload
8.4.2 Behavior
8.4.3 Response
565
8.4.3.1
Status Codes
8.4.3.2
Header Fields
8.4.3.3
Payload
8.4.4 Media Types
8.5 WS Retrieve Rendered Imaging Document Set Service
Page 16
14 November 2014
570
575
Sup 183 Web Services Re-Documentation (v4)
8.5.1 Request
8.5.1.1
Resource
8.5.1.2
Query Parameters
8.5.1.3
Header Fields
8.5.1.4
Payload
8.5.2 Behavior
8.5.3 Response
580
8.5.3.1
Status Codes
8.5.3.2
Header Fields
8.5.3.3
Payload
8.5.4 Media Types
8.6 WS Retrieve Imaging Document Set Metadata Service
8.6.1 Request
585
8.6.1.1
Resource
8.6.1.2
Query Parameters
8.6.1.3
Header Fields
8.6.1.4
Payload
8.6.2 Behavior
8.6.3 Response
590
8.6.3.1
Status Codes
8.6.3.2
Header Fields
8.6.3.3
Payload
8.6.4 Media Types
9 Restful Web Services Protocol
Page 17
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
9.1 RS Services
595
9.1.1 Request
9.1.1.1
Resources
9.1.1.2
Query Parameters
9.1.1.3
Header Fields
Required:
Accept
600
(see [ref])
Optional:
Accept-Charset
9.1.1.4
605
(see [ref])
Payload
9.1.2 Behavior
9.1.3 Response
610
9.1.3.1
Status Codes
9.1.3.2
Header Fields
9.1.3.3
Payload
9.1.4 Media Types
9.2 RS Retrieve DICOM Service
9.2.1 Transactions
9.2.2 Request
615
9.2.2.1
Resources
9.2.2.2
Query Parameters
9.2.2.3
Header Fields
9.2.2.4
Payload
9.2.3 Behavior
Page 18
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 19
9.2.4 Response
620
9.2.4.1
Status Codes
9.2.4.2
Header Fields
9.2.4.3
Payload
9.2.5 Media Types
9.3 RS Retrieve Rendered Service
625
9.3.1 Transactions
9.3.2 Request
630
9.3.2.1
Resources
9.3.2.2
Query Parameters
9.3.2.3
Header Fields
9.3.2.4
Payload
9.3.3 Behavior
9.3.4 Response
635
9.3.4.1
Status Codes
9.3.4.2
Header Fields
9.3.4.3
Payload
9.3.5 Media Types
9.4 RS Retrieve Rendered Presentation States Service
The RS Retrieve Rendered Presentation State service enables User-Agents to request rendered images
using resources that reference DICOM presentation states.
640
9.4.1 Transactions
This service supports three transactions
1. Retrieve Rendered Presentation State Study
For this transaction the User-Agent requests that the Origin-Server render all the instances
referenced by each presentation state series in the target study and return them in the response.
645
2. Retrieve Rendered Presentation State Series
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 20
For this transaction the User-Agent requests that the Origin-Server render all the instances
referenced by the target presentation state series and return them in the response.
3. Retrieve Rendered Presentation State Instance
For this transaction the User-Agent requests that the Origin-Server render the instance
referenced by the target presentation state series and instance and return it in the response.
650
9.4.2 Request
Transactions in this service use the GET method. The request syntax is:
GET {resource} {? query} CRLF
{*headers} CRLF
CRLF
655
9.4.2.1
Resources
This service has three resources: Study, Series, and Instance. The User-Agent shall only specify
resources that reference presentation states.
660
Study
references all presentation state series and the instances they contain.
Series
references a single presentation state series and the instances it contains.
Instance
references a single presentation state instance.
Table 9.4-1: Retrieve Rendered Presentation State Resource Templates
Resource
URI Template
Study
Series
Instance
{+svc}/studies/{studyUID}
{+svc}/studies/{studyUID}/series/{seriesUID}
{+svc}/studies/{studyUID}/series/{seriesUID}/instances/{instanceUID}
9.4.2.2
Query Parameters
9.4.2.2.1
De-Identify
deidentify
665
The “deidentify” parameter requests that all Personally Identifiable Information [ref] be omitted from the
returned object(s). See PS 3.15, Annex E.
9.4.2.2.2
Volume of Interest Lookup Table (VOI LUT)
voiLutSequenceItemNumber = { integer }
670
The “voiLutSequenceItemNumber” parameter specifies the VOI LUT Sequence (0028,3010) Item to be
used to render the returned images.
9.4.2.3
Header Fields [move to 9.1]
Required:
Accept
675
(see [ref])
Optional:
Accept-Charset
9.4.2.4
(see [ref])
Payload
This request message has no payload
14 November 2014
Sup 183 Web Services Re-Documentation (v4)
Page 21
9.4.3 Behavior
680
The Origin Server shall render each presentation state instance referenced by the resource. Rendering a
presentation state requires rendering each instance referenced (include tag number and name) by the
presentation state using the rendering pipeline specified in PS 3.4, Annex N.
The Origin-Server shall render the returned images in acceptable media types. See x.y.z.
9.4.4 Response
685
The Origin-Server shall return an appropriate status code and payload.
a status code of 200 if it successfully rendered all of the instances referenced by the resource and a
payload containing the rendered images.
A failure response will have one of the status codes from Table X.Y-Z, and shall not have a payload
The User-Agent should be prepared to handle other non-success codes. See Section x.x.x.
690
9.4.4.1
Status Codes
Status
Code
The Origin-Server successfully rendered all of the instances referenced by the
resource
200
The Origin-Server successfully rendered only some of the instances referenced
by the resource.
206
If the Origin-Server was unable to render any of the instances successfully then it
will return an error status code.
See Table x.y.z
9.4.4.2
Header Fields
Required:
Content-Type
Content-Location
695
(see [ref])
(see [ref])
Required If: the payload does not have a transfer encoding.
Content-Length
(see [ref])
Optional:
Warning
9.4.4.3
700
(see [ref])
Payload
The Origin-Server shall include all successfully rendered images in the payload. If no instances were
successfully rendered then the payload will be empty.
9.4.5 Media Types
See Table X.Y-Z Rendered Media Types.
9.5 RS Store Service
14 November 2014
705
Sup 183 Web Services Re-Documentation (v4)
9.5.1 Transactions
9.5.2 Request
710
9.5.2.1
Resources
9.5.2.2
Query Parameters
9.5.2.3
Header Fields
9.5.2.4
Payload
9.5.3 Behavior
9.5.4 Response
715
9.5.4.1
Status Codes
9.5.4.2
Header Fields
9.5.4.3
Payload
9.5.5 Media Types
9.6 RS Search Service
9.6.1 Transactions
9.6.2 Request
720
9.6.2.1
Resources
9.6.2.2
Query Parameters
9.6.2.3
Header Fields
9.6.2.4
Payload
9.6.3 Behavior
725
9.6.4 Response
Page 22
14 November 2014
9.6.4.1
Status Codes
9.6.4.2
Header Fields
9.6.4.3
Payload
Sup 183 Web Services Re-Documentation (v4)
9.6.5 Media Types
730
9.7 RS Retrieve Service Capabilities Service
9.7.1 Transactions
9.7.2 Request
735
9.7.2.1
Resources
9.7.2.2
Query Parameters
9.7.2.3
Header Fields
9.7.2.4
Payload
9.7.3 Behavior
9.7.4 Response
740
9.7.4.1
Status Codes
9.7.4.2
Header Fields
9.7.4.3
Payload
9.7.5 Media Types
9.8 RS Unified Workflow and Procedure Step (UPS) Service
9.8.1 Transactions
745
9.8.2 Request
Page 23
14 November 2014
750
9.8.2.1
Resources
9.8.2.2
Query Parameters
9.8.2.3
Header Fields
9.8.2.4
Payload
Sup 183 Web Services Re-Documentation (v4)
9.8.3 Behavior
9.8.4 Response
755
9.8.4.1
Status Codes
9.8.4.2
Header Fields
9.8.4.3
Payload
9.8.5 Media Types
Appendix A. Parameters
Query Parameter grammar
Appendix B. DICOM Media Types
A.1
760
application/dicom
A.1.1
Definition
A.1.2
Examples
A.2
765
application/dicom+xml
A.2.1
Definition
A.2.2
Schemas
A.2.3
Examples
A.3
A.3.1
Definition
A.3.2
Examples
A.4
770
application/dicom+json
application/wadl+json
Appendix C. WS Schema
Page 24