2
4
6
Digital Imaging and Communications in Medicine (DICOM)
8
Supplement 148: Web Access to DICOM persistent Objects by means of Web Services
10 Extension of the Retrieve Service (WADO Web Service)
12
14
16
18
20
22 Prepared by:
DICOM Standards Committee, 1300 N. 17th Street
24 Rosslyn, Virginia 22209 USA
Developed in accordance with: DICOM Workitem 2008-04-B, and New Work Item Proposal ISO/TC215/SC
26 WG2 N631
Contact: emmanuel.cordonnier@etiam.com / cor.loef@philips.com / rob.horn@agfa.com /
28 dclunie@dclunie.com / hclark@medicalimaging.org
VERSION: Version 13 WORKING DRAFT, 15 May, 2010
30
Supplement 148 WADO Web Services
Page 1
Table of Contents
2 Forward ........................................................................................................................................................... iii
Scope and Field of Application .......................................................................................................................iv
4 Open Issues .................................................................................................................................................... 1
1. CLOSED ISSUES .............................................................................................................................. 1
6 2 OPEN ISSUES .................................................................................................................................. 2
Discussion....................................................................................................................................................... 5
8 1 REQUIREMENTS ................................................................................................................................. 5
1.1 General requirements .................................................................................................................. 5
10 1.2 Analysis of use cases .................................................................................................................. 5
1.3 Functional description of the transactions addressing the use cases ......................................... 5
12 Original URI based WADO Use Case ............................................................................................... 5
DICOM (Encoded Content) Requestor .............................................................................................. 5
14 Rendered (JPEG/PDF) Requestor .................................................................................................... 5
Metadata (XML without pixel or signals) Requestor .......................................................................... 5
16 Information (XML Subset) Requestor ................................................................................................ 5
IHE ITI Compatibility .......................................................................................................................... 5
18 Proxy Agent for non-WS DICOM archive .......................................................................................... 5
1.4 Functional limitations of the present standard ............................................................................. 5
20 1.5 Security aspects .......................................................................................................................... 5
1.6 Request parameters .................................................................................................................... 5
22 1.5 Response parameters ................................................................................................................. 7
2 SERVICES IMPLEMENTATION ........................................................................................................... 8
24 2 ACRONYMS.......................................................................................................................................... 8
Changes to NEMA Standards Publication PS 3.18-2008 ............................................................................. 14
26 1 Scope ............................................................................................................................................... 14
6.1 INTERACTION ................................................................................................................................ 15
28 6.2 HTTP URI REQUEST ...................................................................................................................... 16
6.3 HTTP RESPONSE TO THE URI REQUEST .................................................................................. 16
30 6.3 WS REQUEST ................................................................................................................................. 16
6.4 WS RESPONSE .............................................................................................................................. 24
32 7.2 MULTI-FRAME AND VIDEO IMAGE OBJECTS ............................................................................. 24
7.2.1 Objects included ........................................................................................................... 24
34 8 Parameters of the request ............................................................................................................... 24
8.1 PARAMETERS AVAILABLE FOR ALL DICOM PERSISTENT OBJECTS ..................................... 24
36 8.1.1 Request type ................................................................................................................ 25
8.1.2 Unique identifier of the study........................................................................................ 25
38 8.1.3 Unique identifier of the series....................................................................................... 25
8.1.4 Unique identifier of the object....................................................................................... 25
40 8.1.5 MIME type of the response .......................................................................................... 25
8.1.6 Charset of the response ............................................................................................... 26
42 8.1.7 Anonymize object(s) ..................................................................................................... 26
8.1.9 Retrieve partial information from object(s) ................................................................... 27
44 8.2 PARAMETERS FOR DICOM IMAGE PERSISTENT OBJECTS .................................................... 27
8.2.1 Annotation on the object ........................................................................................................ 27
46 8.2.2 Number of pixel rows ................................................................................................... 28
Supplement xx WADO Web Services
Page 2
8.2.3 Number of pixel columns .............................................................................................. 28
2 8.2.4 Region of the image ..................................................................................................... 28
8.2.5 Window center of the image ......................................................................................... 29
4 8.2.6 Window width of the image........................................................................................... 29
8.2.7 Frame Number ............................................................................................................. 29
6 8.2.8 Image Quality ............................................................................................................... 30
8.2.9 Unique identifier of the presentation object .................................................................. 30
8 8.2.10 Unique identifier of the series containing the presentation object ................................ 30
8.2.11 Transfer Syntax UID ..................................................................................................... 31
10 9 Contents of the response ................................................................................................................. 31
9.1 CONTENTS OF THE RESPONSE IN URI BASED MODE ............................................................. 31
12 9.2 CONTENTS OF THE RESPONSE IN WS MODE ........................................................................... 31
Annex E – WADO WS Schemas and Examples (informative) ..................................................................... 34
14 E.1 WADO WS RNC SCHEMA .............................................................................................................. 34
E.2 WADO WS XSD SCHEMA .............................................................................................................. 34
16 E.3 WADO WS WSDL SCHEMA ........................................................................................................... 34
E.4 WADO WS REQUEST EXAMPLE ................................................................................................... 34
18 E.5 WADO WS RESPONSE EXAMPLE ................................................................................................ 34
Supplement 148 WADO Web Services
Page iii
Forward
2 The American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA)
formed a joint committee to develop a standard for Digital Imaging and Communications in Medicine
4 (DICOM). This DICOM Standard and the corresponding Supplements to the DICOM Standard were
developed according to the NEMA procedures.
6 DICOM is developed in liaison with other standardization organizations including ISO, thanks to its A-
Liaison, as well as CEN TC251 in Europe and JIRA in Japan, with review also by other organizations
8 including IEEE, HL7 and ANSI in the USA.
DICOM has been recognized as an ISO, CEN and AFNOR reference standard, under the number
10 (#12052).
This document is a Supplement to the DICOM Standard. It is an extension of the following part of the
12 published DICOM Standard:
PS 3.18 Web Access to DICOM Persistent Object
14 This supplement corresponds to the DICOM standard extension, as well as the development of the New
Work Item Proposal ISO/TC215/SC WG2 N631 of ISO “Health Informatics – Message and Communication
16 – Web Access to DICOM persistent Objects by means of Web Services”, itself defined as additional
services which extend the existing standard ISO17432:2004 “Health Informatics – Message and
18 Communication – Web Access to DICOM persistent Objects”, commonly called “WADO”.
This supplement deals only with the Retrieve Service, corresponding to the strict evolution of the
20 existing WADO to Web Service, so excluding any Query (QIDO) or Notification (NADO)
mechanisms, which will be developed later.
Supplement xx WADO Web Services
Page iv
Scope and Field of Application
2 This Supplement defines services offered by DICOM environments in the Web Services environment for
providing image access to healthcare professionals who work in the context of an Electronic Medical
4 Record/Electronic Health Record (EMR/EHR). It provides access to DICOM persistent objects. Access to
other DICOM objects, e.g., DICOM normalized objects, is not defined within this supplement.
6 It enables access to DICOM persistent objects from “non-DICOM World” (e.g. web based application) and
also can be used to convey DICOM persistent objects through such “non-DICOM World” from one “DICOM
8 World” to another one (e.g. opening a DICOM Viewer for displaying a study retrieved through a web
access from a PACS). It is able to preserve all the information contained in DICOM objects.
10 Security aspects are out of the scope of this supplement. However the proposed mechanism is fully
compatible with complementary generic mechanisms used in web services dealing with the security. The
12 purpose of the supplement is to enable communication of imaging-related personal health information
(PHI), mainly in clinical routine context, and absolutely not to propose or even to facilitate any data mining
14 in medical imaging databases relevant for other purposes as medical biosurveillance or clinical research.
The DICOM/ISO 12052 standard is well accepted in the medical imaging area, including radiology,
16 cardiology, pathology, radiotherapy, ophthalmology, endoscopy, and microscopy. The prescribers of
medical imaging studies and care providers are demanding rapid and reliable access to reports and
18 images. They are using Electronic Medical Record (EMR) systems for access to all of the patient's health
information in computerized environments, which are increasingly based on Web Services technologies,
20 from which they want to have access to relevant DICOM persistent objects without duplication of these
objects. They want to have in context access to either the imaging data itself, in the original DICOM format,
22 or converted into a generic image format that can be presented with an off the shelf application.
Service Oriented Architecture (SOA) is now widely recognized as the “post web” evolution of Information
24 Systems, and has entered the healthcare world. More and more Healthcare IT vendors are supporting
Web Services (WS) based access to their image management system from the point of service (POS)
26 systems in the healthcare enterprise. There is an increasing risk of lack of interoperability if such WS for
image access are not standardized. The DICOM Standard is the natural home for such a specification of
28 WS based medical imaging transactions. However, the DICOM Standard currently does not support Web
Services technology.
30 The purpose of this Supplement is to start with a modest extension of DICOM into the Web Services world,
and to start with simple yet powerful cohesive group consisting of an extension of “Web Access to DICOM
32 Persistent Objects”, WADO to Web Services. This is the purpose of this supplement. A “Notification
Service for the availability of DICOM Objects”, NADO, and a “Query Service based on ID(s) for DICOM
34 Objects” (not only based on UIDs), QIDO, are to be developed by further supplement(s). The objective is
to realistically advance on the WS without taking the risk to destabilize too much the present DICOM
36 Standards, and their implementations.
WADO: Extending WADO to WS makes sense because WADO already provides a mapping from some
38 DICOM Tags, WADO is increasingly widely used (e.g., IHE ITI XDS-I) and some limitations have shown up
by the present Http Get implementation, which enables only retrieval of individual instance.
40 For later work:
- NADO: WADO assumes that the Application retrieving the DICOM Object(s) is aware of it/their
42 existence and availability. But no mechanism has been provided for informing the application
that such DICOM Instance(s) are available. Similarly to the DICOM IAN (Instance Availability
44 Notification), a WS based transaction needs to be defined for notifying the availability of
Supplement 148 WADO Web Services
Page v
DICOM Object(s), “Notify the Availability of DICOM persistent Objects”, NADO. The
2 mechanism may imply a “subscription” by an application to be notified at different levels
(study/series/instance) and the notification message may include, in addition to UIDS, at least
4 the Patient Id, the Accession Number and the Modality.
- QIDO: Similarly to the IHE ITI Retrieve Document for Display (RID) transaction, the Application
6 can query the DICOM server to have a list of available DICOM objects, “Query through ID to
DICOM persistent Objects”, QIDO. Parameters may be similar to those used for RID (Patient
8 ID, date(s) and number of most recent) with the Accession Number (in addition to the Patient
ID required for security reasons).
10 Since this document proposes changes to existing Parts of DICOM the reader should have a working
understanding of the Standard.
12
Supplement 148 WADO Web Services
Page 1
Open Issues
2 1. CLOSED ISSUES
Closed Description Status
issue
1 Should a new DICOM Part created of extend the Part 18? Extend the Part 18 which
has a scope which covers
the purpose of the Work
Item on Web Services.
2 Should the defined services be idempotent (one requests is YES
independent from others and generates only one response)?
3 Should a generic mechanism for transposing DICOM Header YES. Use the XML schema
information from binary to XML be defined? defined by WG23 (Sup.
118).
4 Should the present (Http Get) WADO maintained? YES
5 Should the present (Http Get) WADO extended to multiple NO
instances?
9 Whether the request should allow multiple distinct YES. A mechanism is
objects/series/studies to be retrieved in the same request (e.g. 2 proposed through the
out of 5 series in a study, without pulling the whole study)? StudyRequest parameter.
Limited to one study.
12 Parameters to be returned (in XML) with the WADO response? Metadata or extract of
them based on XPath
14 How to support gradual retrieval of images and use of streaming A priori, some combined
protocols i.e., JPIP (important in certain clinical apps e.g., use of WADO and DICOM
pathology, mammography and environments with limited network JPIP have been shown in
bandwidth e.g., rural areas, northern territories in Canada)? DICOM Conference at
Chengdu. Mentioned in a
note.
16 How to deal with the multiple instance retrieval? MTOM/XOP indexed by
Instance UIDs
17 How to access to a selection of objects? Winthin a study, a list of
series/instances
18 Which format to use for the response parameters? MTOM/XOP of instance for
retrieve of contents, XML
DicomNativeModel (total or
partial) for information
retrieve
Supplement 148 WADO Web Services
Page 2
19 How to enable only part of a sequence to be retrieved? A priori extend the
frameNumber parameter
and revisit the multiframe
section
22 How to retrieve for a particular DICOM object all the information Either select the
but the object contents itself (i.e. pixels, waveform…) in a TransferSyntax without
readable format (i.e. XML)? pixel (binary format) or use
the metadata/information
transactions
23 How to retrieve relevant parameters for DICOM objects, beyond Query based on XPath
the ones included in the retrieved KOS? applied on the DICOM
object(s) header converted
in XML following the WG23
(Sup. 118) schema.
25 Are the returned image parts compressed/packed in a zip? NO
2 2 OPEN ISSUES
Open Description Status
issue
6 Should the parameters available in WADO be extended in order to This is considered to be
permit the use of WADO as an interoperable means for linking a outside of the scope of the
DICOM Viewer and a DICOM Image Server? WADO workitem.
7 Should the “fuzzy” display parameters (“annotation”, “anonymise”) A priori NO because it
available in WADO more precisely defined in order to permit the would be too complicated
“client” to control the information displayed or removed? and dependent of the
context of use
(regulations…).
8 How to deal with the WADO Conformance of both servers and May be proposing some
clients? wording for the relevant
section of the DICOM
Conformance Statement
10 Will the suggested contentType to be extended, beyond JPEG In the case the “client
(lossy), i.e. JPEG 2000, PNG? application” is not based
on a web browser (which
does not intrinsically
support JPEG 2000), the
use of JPEG 2000 might
be recommended as a
preferable value.
11 Do we need to expand the mechanism for retrieving a report, for At least we have to revisit
example by refining the mapping to CDA? the section of WADO
dedicated to contentType
for Textual objects.
Supplement 148 WADO Web Services
Page 3
13 How to support access restriction to data according to user roles It has been decided than
or patient consent directives? the security mechanisms
are not in the scope itself
but we have to check that
the mechanism we provide
is compliant with the
security mechanisms
15 How to handle the left part of the URI? A priori, it has to be
addressed by other bodies
more dedicated to the
implementation level
(IHE…).
20 How to deal with the retrieve of DICOM SR in form of CDA? A priori refer to the
mapping of SR to CDA
defined by DICOM WG20
21 How to deal with demands for retrieve only the URI instead of the Not supported (to be
pixels? supported by QIDO)
24 Is it possible to have a asynchronous version of the Web Services A priori no for the first step.
implementation of WADO enabling that the retrieved images May be an extension in the
(either in DICOM native format or in jpeg or similar format) are future
sent in batch?
26 Is RDF (Resource Description Framework) considered? Not for the moment
27 Anonymization mechanisms are largely more complicated to Suggested to wait the
implement that it was initially thought. Some work is presently finalization of the ongoing
done in DICOM and IHE relative to this issue. How to reflect this work before to update the
in the supplement? supplement.
28 What should be the response for requested objects that are Availability element in the
known by the server but not available or not in a quick answer response
(e.g. near online storage)?
29 Tests have shown that retrieving a large amount of data through Availability element in the
one unique WS transaction is not working properly. How to response
manage retrieval of series containing hundreds of instances (e.g.
CT)?
30 IHE ITI has published a White Paper on the Access Control Read the WP, complete
management. How to reflect its contents in the present the section 1.4 if
supplement? necessary, and check if
additional parameters are
required for the request or
the response
31 How to avoid this supplement is dealing with definition of XML Suggest to WG23 to
structures for the response containing DICOM related endorse the XML related
information? aspects of the supplement
and make references to
them in the present
Supplement 148 WADO Web Services
Page 4
supplement
32 Which kind of namespace to use? WG23 is using http based
syntax where IHE is
recommending urn based
syntax. This last one has
been chosen to be
consistent with EHR
applications
33 Propose a WSDL example describing the Http Get based WADO To be done if estimated
as a RESTFull service useful
34 Is it possible to retrieve an object by the Object UID only? Might be possible now
because of the evolution of
DICOM C-FIND at the
instance level.
35 Is it possible to retrieve all the instance from a DICOM encoded Not supported. The client
manifest (KOS), as retrieved in XDS-I.b? has to open the manifest
and to build the list of
object(s) UID(s).
36 Is it adequate to include the full ebXML Registry Service Schema IHE ITI will deal with it. For
only for dealing with the Registry Responses, when ITI RAD the moment maintain the
modified the ebRS schema itself for adding “PartialSuccess” IHE-RAD approach.
37 How to deal in WS if multiple content types are précised in the The section has to be
request and they can be applied on one type of object retrieved? revisited.
38 Which namespace to use for the IHE ITI RAD-69 transaction? For the moment, a new
“wado” has been defined,
to be updated in XDS-I.b.
39 Is it relevant to extend the error messages? Probably useful
40 Is it possible to retrieve all the instances depending from one To be studied.
study or one series by sending only one ID?
Supplement 148 WADO Web Services
Page 5
Discussion
2 This section will be removed in the final version of the Supplement. It is included only to reflect the state of
the thoughts concerning the supplement contents.
4
1.4 Functional limitations of the present standard
6 It is known that while WADO offers numerous advantages, the PRESENT version has numerous
limitations, specifically:
8 1. Does not provide access to all levels of the DICOM hierarchy (Patient, Study, Series, and
Object).
10 2. Requires the server to support Instance C-Find (mandatory by DICOM but not supported by
some systems).
12 3. Does not support multi-instance / multi-part retrieval.
4. Not well suited to be embedded in / integrated with clinical applications.
14 5. Does not utilize the full power of Web Services e.g., WSDL, UDDI, MTOM/XOP.
6. Limited integration with the modern Digital Imaging Repositories / EHR.
16 The above limitations form the basis for the requirements that need to be included and addressed in this
supplement.
18
20 1.6 Request parameters
The new service, based on WS, should continue to support all the request parameters defined by WADO,
22 for maintaining backward compatibility with the present URI based WADO, including the options to return
either native DICOM objects or a pre-rendered object (JPEG, PDF etc.). These are summarized as below:
24 Table 1.6.1.1 Summary of DICOM/Rendered URI based WADO Parameters
Parameter Allowed for? Mandatory in request?
requestType Both Yes
studyUID Both Yes
seriesUID Both Yes
objectUID Both Yes
contentType Both
charset Both
anonymize DICOM
annotation Rendered
rows / columns Rendered
region Rendered
windowCenter/ windowWidth Rendered
imageQuality Both
Supplement 148 WADO Web Services
Page 6
Parameter Allowed for? Mandatory in request?
presentationUID Rendered
presentationSeriesUID Rendered
transferSyntax DICOM
frameNumber Both
2
For the WS “DICOM Requester” transaction, the parameters will be the following:
4 Table 1.6.1.2 Summary of ―DICOM Requester‖ WADO-WS Parameters
Parameter Mandatory in request?
StudyRequest Yes
>SeriesRequest Yes, one or multiple
>>DocumentRequest Yes, one or multiple
>>>RepositoryUniqueId
>>>DocumentUniqueId Yes
>>>HomeCommunityId
TransferSyntaxUIDList
>TransferSyntaxUID One or more, if
TransferSyntaxUIDList
is present
FrameNumber
Anonymize
6 Table 1.6.1.2 Summary of ―Rendered Requester‖ WADO-WS Parameters
Parameter Mandatory in request?
StudyRequest Yes
>SeriesRequest Yes, one or multiple
>>DocumentRequest Yes, one or multiple
>>>RepositoryUniqueId
>>>DocumentUniqueId Yes
>>>HomeCommunityId
ContentTypeList Yes
>ContentType Yes, one or multiple
CharsetList
>Charset Yes, one or multiple if
CharsetList is present
Annotation
Rows / Columns
Region
Supplement 148 WADO Web Services
Page 7
Parameter Mandatory in request?
WindowCenter/ WindowWidth
ImageQuality
PresentationUID
PresentationSeriesUID
FrameNumber
Anonymize
2 Table 1.6.1.3 Summary of ―Metadata Requester‖ WADO-WS Parameters
Parameter Mandatory in request?
StudyRequest Yes
>SeriesRequest Yes, one or multiple
>>DocumentRequest Yes, one or multiple
>>>RepositoryUniqueId
>>>DocumentUniqueId Yes
>>>HomeCommunityId
Anonymize
4
Table 1.6.1.4 Summary of ―Information Requester‖ WADO-WS Parameters
Parameter Mandatory in request?
StudyRequest Yes
>SeriesRequest Yes, one or multiple
>>DocumentRequest Yes, one or multiple
>>>RepositoryUniqueId
>>>DocumentUniqueId Yes
>>>HomeCommunityId
XPathList Yes
>XPath Yes, one or multiple.
Anonymize
6
1.5 Response parameters
8 In the URI based WADO, the parameters of the response are limited to the one supported by the Http Get
response, besides the payload itself containing the DICOM object, in a DICOM format or in a rendered
10 one.
In the Web Services implementation, for the “DICOM Requester” and the “Rendered Requester”
12 transactions, the object(s) itself/themselves is/are embedded as parts using the MTOM mechanism.
Supplement 148 WADO Web Services
Page 8
For the “Metadata Requester” transaction, the response will contain the selected objects converted in XML
2 as described in section XXX of DICOM PS3.X . For the “Information Requester”
transaction, the response will contain an XML encoded part containing the information selected from the
4 retrieved object(s) header using the “XPath” filter.
6 2 SERVICES IMPLEMENTATION
The implementation architecture has to maximize interoperability, preserve or improve performance and
8 minimize storage overhead.
The technologies for implementing have to been selected using the following criteria:
10 a.Coherent
b.Firewall friendly but supporting security
12 c.Supported by multiple development environment and interoperable whatever the development was
d.Having a good performance, also for binary (and large) data
14 e.Potentially implemented into browsers
f.Easy to understand, learn and configure
16 g.Preferably official standards but more, really deployed and stable standards
18 The URI based (Http Get) WADO will be maintained, potentially updated with the parameters for retrieving
frames as discussed in the section 1.5 above, but not extended beyond the INSTANCE level.
20 The name of the request parameters are the same than for the http Get version, with the exception of the
first character which is upcase to be compliant with XML guidelines.
22 Note: The XML implementation of the messages are respecting the CamelCase word style as used in SOAP
1.2 (element names starting by a capital e.g. ElementOne , attribute names starting by a lowcase
24 character e.g. attributeOne).
The response will be provided as list of instances in MTOM/XOP (“DICOM” or “Rendered” Requesters) or
26 list of selected object metadata converted in XML in MTOM/XOP (“Metadata Requester”), or, XML
encoded additional information resulting from the XPath filter(s) applied on every objects selected
28 (“Information Requester”).
30
Supplement 148 WADO Web Services
Page 9
2 Changes to NEMA Standards Publication PS 3.17-2007
Digital Imaging and Communications in Medicine (DICOM)
4 Part 17: Explanatory Information
Insert the following Annex to Part 17
6
8 X USES FOR WADO WEB SERVICES
X.1 General requirements
10 Imaging information is more and more important in the context of EMR/EHR. But EMR/EHR systems are
often unable to support the DICOM protocol. The EMR/EHR users and vendors are requesting access
12 using web and web service technologies.
It is recognized that medical imaging information, especially images themselves, are different that other
14 information, mainly in two aspects: they are mainly produced by equipment (vs. created by humans), and
they are not mainly text based, requiring special way of display (e.g. viewers) and large capacity of
16 communication and storage (typically in the range of megabyte per image). This imaging information is
stored in a separate repository from the EMR/EHR (e.g., a Picture Archiving and Communication System
18 (PACS)) and the need is to give to users access to imaging information.
X.2 Analysis of use cases
20 Examples of use cases / clinical scenarios, as the basis to develop the requirements, include:
1. Providing access to images and reports from a point-of-service application e.g., EMR.
22 2. Providing references to significant images used to create an imaging report.
3. Providing references / links to relevant images and imaging reports in email correspondence
24 or clinical reports e.g., clinical summary
4. Providing access to anonymized DICOM images and reports for clinical research and teaching
26 purposes
5. Providing access to a DICOM encoded imaging report associated with the DICOM IE
28 (patient/study/series/objects) to support remote diagnostic workflows e.g., urgent medical
incidents, remote consultation, clinical training, teleradiology/telemedicine applications
30 6. Providing access to summary or selected information from DICOM object(s)
Supplement 148 WADO Web Services
Page 10
Examples of the use cases described in 1 above are:
2 a. The EMR displays in JPEG one image with annotations on it (patient and/or technique related)
b. The EMR retrieves from a “Manifest” document all the referenced objects in DICOM and
4 launches a DICOM viewer for displaying them (use case addressed by the IHE XDS-I.b
profile)
6 c. The EMR displays in JPEG one image per series with information describing every series (e.g.
series description)
8 d. The EMR displays in JPEG all the images of a series with information describing the series as
well as every image (e.g. instance number and slice location for scanner images)
10 e. The EMR populates in its database for all the instances referred in a manifest (KOS) the
relevant information (study ID/UID/AccessionNumber/Description/DateTime, series
12 UID/Modality/Description/DateTime, instance UID/InstanceNumber/SliceLocation)
To limit the complexity of every transaction to implement, the 1c use case is decomposed in the following
14 steps (all the other use cases can be implemented through a similar sequence of basic transactions):
A. The EMR sends to the DICOM server the list of the objects (“selection”), asking for the object
16 content
B. The DICOM server sends back the JPEG images corresponding to the listed objects
18 C. The EMR sends to the DICOM server the “selection” information for obtaining the general
information about the objects retrieved
20 D. The DICOM server sends back the corresponding information in the form of a “metadata”
document, converted in XML
22 E. The EMR sends to the DICOM server the list of the objects, asking additional information it
wants to display on the object, through a “filter” applied on all the objects metadata
24 F. The DICOM server sends back the corresponding information, organized by the instance UID of
the related objects
26 X.3 Functional description of the transactions addressing the use cases
28 Original URI based WADO Use Case
A. Requesting system: Web Browser or other such application,
30 B. Available information: URL or similar information
C. Request information:
32 1. Individual SOP Instance information
2. Desired format and subset selection
34 D. Response information
1. SOP instance, reformatted and subset as requested
36
38 DICOM (Encoded Content) Requestor
A. Requesting system: application capable of WS-* requests and able to process data encoded as a
40 DICOM File, per Part 10 encodings.
B. Available information: ?
Supplement 148 WADO Web Services
Page 11
C. Request Information
2 1. Requested Dataset
a) Individual SOP Instance information. (Same study/series issues)
4 b) Series UID
c) Study UID
6 d) List of SOP Instance UIDs
2. Desired subset information
8 a) Sup 119 subset information for selecting frames
b) No-pixel data request
10 c) Anonymize or not
D. Response Information
12 1. DICOM encoded per Part 10.
14 Rendered (JPEG/PDF) Requestor
A. Requesting system: application capable of WS-* requests. System has no capability or detailed
16 understanding of DICOM.
B. Available information: ?
18 C. Request information
1. Requested Dataset
20 a) Individual SOP Instance information.
b) Series UID
22 c) Study UID
d) List of SOP Instance UIDs
24 2. Desired format and subset information
a) JPEG/PDF/ etc selection, subset area, presentation information
26 b) Frame selection for subsets of multi-frame objects
c) What should be done for requests where image shapes and SOP classes vary and a
28 subset is requested?
d) Anonymize or not.
30 D. Response information
1. JPEGs
32 a) Should JPEGs include tag information within the JPEG? If so, what information?
b) How will JPEGs be related to multi-frame and multi-instance requests? Order? Tag?
34 2. PDFs
a) How will PDFs be related to multi-frame and multi-instance requests? One per frame?
36 One per instance? One for entire set?
3. XML encoded?
38 4. Other encodings?
40 Metadata (XML without pixel or signals) Requestor
A. Requesting system: application capable of WS-* requests. System has no capability or detailed
42 understanding of DICOM.
B. Available information: ?
Supplement 148 WADO Web Services
Page 12
C. Request information
2 1. Requested Dataset
a) Individual SOP Instance information. (Same study/series issues)
4 b) Series UID
c) Study UID
6 d) List of SOP Instance UIDs
2. Desired format and subset information
8 a) Native DICOM Model XML definition for dataset, without pixels
b) Anonymize or not.
10 c) Response information
3. XML encoded
12
Information (XML Subset) Requestor
14 A. Requesting system: application capable of WS-* requests, and using CSS/XPATH/etc as a
transform method for display of data.
16 B. Available information: ?
C. Request information
18 1. Requested Dataset
a) Individual SOP Instance information.
20 b) Series UID
c) Study UID
22 d) List of SOP Instance UIDs
2. Desired format and subset information
24 a) XPATH definition for subset
b) What should be done when SOP classes vary and a subset is requested? The XPATH
26 will fail.
c) Anonymize or not.
28 d) Response information
3. XML encoded
30
32 IHE ITI Compatibility
There is a strong desire that the ITI Transaction RAD-69 be a proper implementation of the DICOM WS-*
34 transaction. Note that RAD-69 is not the entire suite of XD* transactions. It is the “Retrieve Imaging
Document Set” transaction.
36 The RAD-69 transaction is quite simple, although I hope we can do a better job of organizing the
documentation. It is rather difficult to find all the ITI parts. In summary, the RAD-69 transaction is a WS
38 request to the IHE “RequestDocumentSet” action and related endpoints. The request is a list of
“DocumentRequest”, each “DocumentRequest” has three elements: mandatory OID, mandatory
40 RepositoryID, and optional CommunityID. The response is a list of “DocumentResponse”. Each
“DocumentResponse” has four elements: mandatory OID, mandatory RepositoryID, mandatory Document,
42 and optional CommunityID.
The mapping to DICOM for OID would be SOP Instance UID, and Document the DICOM contents.
44 RepositoryID is analogous to the AE Title. It is not a perfect mapping. IHE considers the configuration
Supplement 148 WADO Web Services
Page 13
where one system acts as a front end for multiple other systems, each identified by a RepositoryID. The
2 CommunityID is an extension of this to “communities” that exchange data through gateways. The
gateways will use the RepositoryID to identify internal repository systems.
4 RAD-69 requires no understanding of document contents. They are binary blobs that are identified by an
OID.
6
Proxy Agent for non-WS DICOM archive
8 Rapid acceptance will be enhanced if a proxy system that automatically converts between the WS notation
and the older DICOM C-FIND/etc transaction can be defined; and if this conversion can be simple. Proxy
10 systems can also simplify security configuration.
12
Supplement 148 WADO Web Services
Page 14
2 Changes to NEMA Standards Publication PS 3.18-2008
Digital Imaging and Communications in Medicine (DICOM)
4 Part 18: Web Access to DICOM Persistent Objects (WADO)
6
Item #1: Modify PS 3.18 Section 1 Scope as indicated.
8 1 Scope
This standard specifies a web-based service for accessing and presenting DICOM (Digital Imaging and
10 Communications in Medicine) persistent objects (e.g. images, medical imaging reports). This is intended
for distribution of results and images to healthcare professionals. It provides a simple mechanism for
12 accessing DICOM persistent object(s) from HTML pages or XML documents, through HTTP/HTTPs
protocol, using DICOM UIDs (Unique Identifiers). Data may be retrieved either in a presentation-ready
14 form as specified by the requester (e.g. JPEG or GIF) or in a native DICOM format. It does not support
facilities for web searching of DICOM images. This standard relates only to DICOM persistent objects (not
16 to other DICOM objects or to non-DICOM objects). Access control beyond the security mechanisms
generally available to web applications is outside the scope of this standard.
18
20 Item #2: Append PS 3.18 Section 3 Normative Reference as indicated.
IHE ITI WS IHE ITI IT Infrastructure Technical Framework Volume 2 (ITI TF-2)
22 Transactions Annex V (Web Services for IHE Transactions)
24 Item #3: Append PS 3.18 Section 5 Symbols and abbreviated terms as indicated.
IHE Integrating the Healthcare Enterprise
26 MTOM Message Transmission Optimization Mechanism
SOAP Simple Object Access Protocol (SOAP12 for SOAP version 1.2)
Supplement 148 WADO Web Services
Page 15
WS Web Services
2 WSDL Web Services Description Language
XOP XML-binary Optimized Packaging
4
6
8 Item #4: Modify PS 3.18 Section 6 Data Communication Requirements as indicated.
6.1 INTERACTION
Web Enabled
Web Client DICOM
System Server
Object(s) request
(Get/Post HTTP Request)
[Metadata or] Object(s) send
(HTTP Response to the Get/Post Request)
10
Figure 6-1 — Interaction Diagram
12 The interaction shall be as shown in Figure 6-1.
Two communications modes are possible:
14 URI based mechanism using HTTP Get: WADO Type request
Web Services (WS) using HTTP Post: WADO WS Service, containing:
16 a. DICOM Requester (Retrieve Imaging Document Set)
b. Rendered Requester (Retrieve Rendered Imaging Document Set)
18 c. Metadata Requester (Retrieve Imaging Document Set Metadata)
Supplement 148 WADO Web Services
Page 16
d. Information Requester (Retrieve Imaging Document Set Information)
2
6.2 HTTP URI REQUEST
4
Item #5: Modify PS 3.18 Section 6 Data Communication Requirements as indicated.
6
6.3 HTTP RESPONSE TO THE URI REQUEST
8
10
Item #5: Append PS 3.18 Section 6 Data Communication Requirements as indicated.
12 6.3 WS REQUEST/RESPONSE
One general section
14 The web service interface defines four action types. An implementation shall support at least one of these
four action types.
16 These four action types are:
1. RetrieveImagingDocumentSet
18 This action retrieves a set of DICOM objects and other objects. This action corresponds to the
IHE XDS-I transaction RAD-69.
20
2. RetrieveRenderedImagingDocumentSet
22 This action retrieves a set of DICOM objects that have been rendered into the requested
format. For example, if rendering into JPEG was requested, then these will be the JPEG
24 renderings for the requested set of DICOM objects.
26 3. RetrieveImageingDocumentSetMetadata
This action retrieves a set of DICOM objects with the image data removed, and other DICOM
28 information presented in an XML encoding. It is similar to the DICOM No Pixel Data transfer
syntaxes.
30
4. RetrieveImagingDocumentSetInformation
32 This action retrieves a set of DICOM objects with the image data removed, and other DICOM
information presented in an XML encoding. It is similar to the DICOM No Pixel Data transfer
34 syntaxes.
Supplement 148 WADO Web Services
Page 17
The Web Services actions shall be fully compliant with the Basic Profile of WS-I as defined in IHE IT
2 Infrastructure Technical Framework Annex V. All elements shall have the mustUnderstand
attribute set (mustUnderstand=”1”)
4 Four request sections.
6.3.1 WS - RetrieveImagingDocumentSet
6 6.3.1.1 - Request
For the “DICOM Requester” transaction:
8 The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set Request
message shall be an “ihe:RetrieveImagingDocumentSetRequest” as defined below.
10 The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve Imaging
Document Set Request message shall be
12 “urn:dicom:ws:wado:2010:RetrieveImagingDocumentSet”.
The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be defined as
14 “urn:dicom:ws:wado:2010:RetrieveImagingDocumentSet”.
These are the requirements concerning the WS request presented in the order in which they would appear
16 in the WSDL definition:
The following types shall be imported (xsd:import) in the /definitions/types section:
18 namespace="urn:ihe:rad:xdsi-b:2009",
schema="XDSI.b_ImagingDocumentSource.xsd"
20 The baseline XDS.b schema (namespace="urn:ihe:iti:xds-b:2007",
schema=”XDS.b_DocumentRepository.xsd”)
22 The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set Request
message shall be defined an “iherad:RetrieveImagingDocumentSetRequest” as defined below.
24 The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set Response
message shall be defined an “ihe:RetrieveDocumentSetResponse” as defined below.
26 The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve Imaging
Document Set Request message shall be “urn:ihe:rad:2009:RetrieveImagingDocumentSet”.
28 The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve Imaging
Document Set Response message shall be “urn:ihe:iti:2007:RetrieveDocumentSetResponse”.
30 The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be
“urn:ihe:rad:2009:RetrieveImagingDocumentSet”.
32 The element for use with the Retrieve Imaging Document
Set Request Message is defined as:
34 One or more elements each of which includes a “studyInstanceUID”
attribute identifying the study associated with the DICOM images/ objects being retrieved. Each
36 element shall contain:
o One or more elements each of which includes a
38 “seriesInstanceUID” attribute identifying the series associated with the DICOM images/
objects being retrieved. Each element shall contain:
40 One or more elements, each one representing an
individual document that the requestor wants to retrieve from the SCP. Each
42 element contains:
Supplement 148 WADO Web Services
Page 18
A required element that identifies the SCP
2 from which the document is to be retrieved. This value corresponds to
XDSDocumentEntry.repositoryUniqueId.
4 A required element that identifies the document
within the source. This value corresponds to the SOP Instance UID
6 referenced within the DICOM manifest.
An optional element that corresponds to the
8 home attribute of the Identifiable class in ebRIM.
A required element which contains a list
10 of one or more elements. Each of the
elements represent one of the transfer
12 syntax encodings that the Imaging Document Consumer is capable of
processing.
14 6.3.1.2 Response
An SCP shall provide the document(s) indicated in the request. The Imaging Document Source shall return
16 the document(s) or an error code when the document could not be returned. The pixel data shall be
encoded using one of the DICOM transfer syntaxes included in the Retrieve Imaging Document Set
18 Request Message. If the Imaging Document Source cannot encode the pixel data using any of the
provided transfer syntaxes then an error status shall be returned.
20 If the Imaging Document Consumer specifies a transfer syntax field of 1.2.840.10008.1.2.4.94 (DICOM
JPIP Referenced Transfer Syntax) or 1.2.840.10008.1.2.4.95 (DICOM JPIP Referenced Deflate Transfer
22 Syntax), the following behavior is expected:
If the DICOM Image Object(s) have a transfer syntax(es) that match the requested transfer syntax,
24 the Retrieve Imaging Document Set Response shall include the DICOM Image Objects unchanged.
If the DICOM Image Object(s) have a transfer syntax that differs from that of the request, the
26 Retrieve Imaging Document Set Response shall include the DICOM image with the transfer syntax
changed to the requested transfer syntax. In addition, the pixel data Attribute (7Fe0,0010 tag) will
28 have been removed and replaced with a Pixel Data Provider URL (0028,7FE0 tag). The URL
represents the JPIP request and will include the specific target information.
30 Upon receipt of this Retrieve Imaging Document Set Response, the Imaging Document Consumer
may request the pixel data from the pixel data provider using the supplied URL. Additional
32 parameters required by the application may be appended to the URL when accessing the pixel data
provider.
34 For example, a JPIP request for a 200 by 200 pixel rendition of the entire image can be constructed
from the Pixel Data Provider URL as follows:
36 Pixel Data Provider URL (0028,7FE0) = https://server.xxx/jpipserver.cgi?target=imgxyz.jp2,
URL Generated by the application =
38 https://server.xxx/jpipserver.cgi?target=imgxyz.jp2&fsiz=200,200
The conditions of failure and possible error messages are given in the ebRS standard and detailed in ITI
40 TF-2: 4.1.13 “Error Reporting”.
The element for use with the Retrieve Imaging Document Set
42 Response Message is defined as:
• A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse element
44 • An optional sequence of elements containing
• An optional element. The value of this element shall be the
46 same as the value of the
Supplement 148 WADO Web Services
Page 19
/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequ
2 est/HomeCommunityId element in the Retrieve Document Set Request Message. If
the element is not present in the Retrieve Document Set
4 Request Message, this value shall not be present.
• A required that identifies the Imaging Document Source
6 from which the document is to be retrieved. The value of this element shall be the
same as the value of the
8 /RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequ
est/RepositoryUniqueId element in the original Retrieve Imaging Document Set
10 Request Message. This value corresponds to XDSDocumentEntry.repositoryUniqueId.
• A required that identifies the document within the Imaging
12 Document Source. The value of this element shall be the same as the value of the
/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequ
14 est/DocumentUniqueId element in the original Retrieve Imaging Document Set
Request Message. This value corresponds to the SOP Instance UID referenced within
16 the DICOM manifest.
• A required element that contains the retrieved document in
18 base64binary encoded format
• A required element that indicates the MIME type of the retrieved
20 document
The /RetrieveDocumentSetResponse/rs:RegistryResponse/@status attributes provides the overall status
22 of the request: It shall contain one of the following values:
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success
24 urn:ihe:iti:2007:ResponseStatusType:PartialSuccess
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure
26 See ITI TF-2: 4.1.13 Error Reporting for the interpretation of these values.
For each document requested in a
28 /RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest element:
• If the document is successfully retrieved (without warning) then no
30 /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError
element shall be present and a
32 /RetrieveDocumentSetResponse/DocumentResponse/Document element shall be returned
containing the document as base64binary encoded data.
34 • If a warning is reported when retrieving the document, then a
/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError
36 element shall be returned with:
• @severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning
38 • @errorCode is specified
• @codeContext contains the warning message
40 • @location contains the DocumentUniqueId of the document requested
• The document shall be returned in an instance of
42 /RetrieveDocumentSetResponse/DocumentResponse/Document as base64binary
encoded data. The returned document and warning are correlated via the
44 DocumentUniqueId.
• If an error is reported when retrieving a document, then a
46 /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError
element shall be returned with:
48 • @severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error
Supplement 148 WADO Web Services
Page 20
• @errorCode is specified
2 • @codeContext contains the error message
• @location contains the DocumentUniqueId of the document requested
4 • No corresponding RetrieveDocumentSetResponse/DocumentResponse element shall be
returned
6 6.3.2 WS – RetrieveRenderedImagingDocumentSet
6.3.2.1 Request
8 For the “Rendered Requester” transaction:
a. The /definitions/message/part/@element attribute of the Retrieve Rendered Imaging
10 Document Set Request message shall be defined as
“wado:RetrieveRenderedImagingDocumentSetRequest”
12 b. The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve
Rendered Imaging Document Set Request message shall be defined as
14 “urn:dicom:ws:wado:2010:RetrieveRenderedImagingDocumentSet”
c. The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be
16 defined as “urn:dicom:ws:wado:2010:RetrieveRenderedImagingDocumentSet”
The element for use with the Retrieve Imaging
18 Document Set Request Message is additionally defined as:
20 hich contains a list of one or more
elements.
22
elements.
24
26 nal element.
28
30 onal element.
32 al element.
6.3.2.2 Response
34 d. The /definitions/message/part/@element attribute of the Retrieve Rendered Imaging
Document Set Response message shall be defined as
36 “ihe:RetrieveDocumentSetResponse”
Supplement 148 WADO Web Services
Page 21
e. The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve
2 Rendered Imaging Document Set Response message shall be defined as
“urn:ihe:iti:2007:RetrieveDocumentSetResponse”
4 f. The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be
defined as “urn:dicom:ws:wado:2010:RetrieveRenderedImagingDocumentSet”
6 The element for use with the Retrieve Imaging Document Set
Response Message, Retrieve Rendered Imaging Document Set Response Message and Retrieve Imaging
8 Document Set Metadata Response Message is defined as:
A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse element
10 An optional sequence of elements containing:
A element. The value of this element shall be the same as the value of
12 the StudyRequest/SeriesRequest/DocumentRequest/HomeCommunityId element in the Request
Message. If the element is not present in the Request Message, this
14 value shall not be present.
A required that identifies the Imaging Document Source from which
16 the document is to be retrieved. The value of this element shall be the same as the value of the
StudyRequest/SeriesRequest/DocumentRequest/RepositoryUniqueId element in the original
18 Request Message.
A required that identifies the document within the DICOM Server. The
20 value of this element shall be the same as the value of the
StudyRequest/SeriesRequest/DocumentRequest/DocumentUniqueId element in the original
22 Request Message. This value corresponds to the SOP Instance UID.
A required element that contains the retrieved document in base64binary
24 encoded format
A required element that indicates the MIME type of the retrieved document
26 The /RetrieveDocumentSetResponse/rs:RegistryResponse/@status attributes provides the overall status
of the request: It shall contain one of the following values:
28 urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess
30 urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure
For each document requested in a /StudyRequest/SeriesRequest/DocumentRequest element:
32 If a warning is reported when retrieving the document,
then a /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/
34 rs:RegistryError element shall be returned with:
@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning
Supplement 148 WADO Web Services
Page 22
@errorCode is specified
2 @codeContext contains the warning message
@location contains the DocumentUniqueId of the document requested
4 The document shall be returned in an instance of /RetrieveDocumentSetResponse/
DocumentResponse/Document as base64binary encoded data. The returned document and
6 warning are correlated via the DocumentUniqueId.
If an error is reported when retrieving a document,
8 then a /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/
rs:RegistryError element shall be returned with:
10 @severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error
@errorCode is specified
12 @codeContext contains the error message
@location contains the DocumentUniqueId of the document requested
14 No corresponding RetrieveDocumentSetResponse/DocumentResponse element shall be
returned
16 If the document is successfully retrieved (without warning) then no
/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/rs:RegistryError
18 element shall be present and a /RetrieveDocumentSetResponse/DocumentResponse/Document
element shall be returned containing the document as base64binary encoded data.
20 6.3.3 WS – RetrieveImagingDocumentSetMetadata
6.3.3.1 Request
22 For the “Metadata Requester” transaction:
a. The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set
24 Metadata Request message shall be defined as “wado:RetrieveImagingDocumentSet
MetadataRequest”
26 b. The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve Imaging
Document Set Metadata Request message shall be defined as
28 “urn:dicom:ws:wado:2010:RetrieveImagingDocumentSetMetadata”
c. The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be
30 defined as “urn:dicom:ws:wado:2010:RetrieveImagingDocumentSetMetadata”
6.3.3.2 Response
32 d. The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set
Metadata Response message shall be defined as
34 “ihe:RetrieveDocumentSetMetadataResponse”
Supplement 148 WADO Web Services
Page 23
e. The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve
2 Imaging Document Set Metadata Response message shall be defined as
“urn:ihe:iti:2007:RetrieveDocumentSetResponse”
4 f. The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be
defined as “urn:dicom:ws:wado:2010:RetrieveImagingDocumentSetMetadata”
6 The element for use with the Retrieve
Imaging Document Set Information Response Message is defined as:
8 A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse element
An optional sequence of elements containing:
10 A element. The value of this element shall be the same as the value of
the StudyRequest/SeriesRequest/DocumentRequest/HomeCommunityId element in the Request
12 Message. If the element is not present in the Request Message, this
value shall not be present.
14 A required that identifies the Imaging Document Source from which
the document is to be retrieved. The value of this element shall be the same as the value of the
16 StudyRequest/SeriesRequest/DocumentRequest/RepositoryUniqueId element in the original
Request Message.
18 A required that identifies the document within the DICOM Server. The
value of this element shall be the same as the value of the
20 StudyRequest/SeriesRequest/DocumentRequest/DocumentUniqueId element in the original
Request Message. This value corresponds to the SOP Instance UID.
22 Zero or more containing:
A required that contains the XPath request
24 A required that contains the text corresponding to the XPath “filter” applied to
the Native Dicom Model transposition of the object, as defined in PS 3.X (Sup 118).
26 6.3.4 WS – RetrieveImagingDocumentSetInformationRequest
6.3.4.1 Request
28 For the “Information Requester” transaction:
a. The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set
30 Information Request message shall be defined as “wado:RetrieveImagingDocumentSet
InformationRequest”
32 b. The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve Imaging
Document Set Information Request message shall be defined as
34 “urn:dicom:ws:wado:2010:RetrieveImagingDocumentSetInformation”
c. The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be
36 defined as “urn:dicom:ws:wado:2010:RetrieveImagingDocumentSetInformation”
All the elements used in the messages are defined in the section 8.2.
Supplement 148 WADO Web Services
Page 24
The element for use with the Retrieve Imaging
2 Document Set Request Message is additionally defined as:
XPathList/> element which contains a list of one or more elements.
4 6.3.4.2 Response
d. The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set
6 Information Response message shall be defined as
“wado:RetrieveImagingDocumentSetInformationResponse”
8 e. The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve
Imaging Document Set Information Response message shall be defined as
10 “urn:dicom:ws:wado:2010:RetrieveImagingDocumentSetInformationResponse”
f. The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be
12 defined as “urn:dicom:ws:wado:2010:RetrieveImagingDocumentSetInformation”
Item #6: Modify PS 3.18 Section 7.2 Multi-Frame Image Objects as indicated.
14 7.2 MULTI-FRAME AND VIDEO IMAGE OBJECTS
7.2.1 Objects included
16 In this category are all SOP classes defined in PS 3.3 that are multi-frame or video image objects.
18 Item #7: Modify PS 3.18 Section 7.3.2 MIME type constraints as indicated.
a "CDA" MIME type, in conformance to HL7 CDA R2, e.g. application/x-hl7-cda-level-one+xml
20 text/xml.
22 Item #8: Modify PS 3.18 Section 8 Parameters as indicated.
8 Parameters of the request
24 8.1 PARAMETERS AVAILABLE FOR ALL DICOM PERSISTENT OBJECTS
Parameters specified in this section are applicable to all supported DICOM SOP Classes.
26 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.,
28 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
30 UID and Series Instance UID to be defined when retrieving an SOP Instance, as defined in PS 3.4.
Supplement 148 WADO Web Services
Page 25
8.1.1 Request type
2 Type of request performed. This parameter is REQUIRED for URI based mode.
The parameter name shall be “requestType”.
4 The value shall be "WADO".
Note: This parameter allows other types of requests to be introduced in the future, using a similar syntax.
6
8.1.2 Unique identifier of the study
8 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
10 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
12 not be padded to an even length with a NULL character.
8.1.3 Unique identifier of the series
14 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
16 ―SeriesRequest‖ which is included into the above described ―StudyRequest‖ and which contains a
required ―seriesInstanceUID‖ attribute.
18 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.
20 8.1.4 Unique identifier of the object
SOP Instance UID as defined in the PS 3.3. This parameter is REQUIRED.
22 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
24 include each one:
a required ―DocumentUniqueId‖ which contains the Instance UID,
26 an optional ―RepositoryUniqueId‖ which contains the UID of the DICOM server, and
an optional ―HomeCommunityId‖ which contains the UID of the ―clinical affinity domain‖.
28 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.
30 8.1.5 MIME type of the response
MIME type(s) desired by the Web Client for the response from the Server, as defined in the IETF
32 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.
34 The parameter name shall be “contentType” for URI based mode, and, for the WS mode,
―ContentTypeList‖ which contains one or multiple ―ContentType‖.
Supplement 148 WADO Web Services
Page 26
In URI based mode, tThe value shall be a list of MIME types, separated by a "," character, and potentially
2 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.
4 In URI based mode, tThe 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
6 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
8 with any MIME types.
2. When this parameter is absent, the default content type of the response is dictated by the "MIME type
10 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
12 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
14 not be present in the other WS mode transactions.
The parameter name shall be “charset” for URI based mode, and ―CharsetList‖ containing one or
16 more element(s) ―Charset‖ for the WS mode.
For the URI mode, the value shall be a list of character sets, separated by a "," character, and potentially
18 associated with relative degree of preference, as specified in IETF RFC2616.
In URI based mode, tThe Web Client may provide a list of character sets it supports in the "Accept-
20 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.
22 The 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.,
24 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
26 in the requested character set (converted if necessary) and the Specific Character Set
(0008,0005) updated (if necessary)
28 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
30 marked one of the aliases as "preferred for MIME", the name used in DICOM shall be the value used for
WADO.
32 2. The table in Annex D provides an informative mapping of some IANA values to DICOM Specific
Character Set Defined Terms.
34
8.1.7 Anonymize object(s)
36 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
38 contentType is application/dicom.
This parameter is Optional.
40 The parameter name shall be “anonymize” for URI based mode, and ―Anonymize‖ for the WS mode.
The value shall be “yes”.
Supplement 148 WADO Web Services
Page 27
The Server may return an error if it either cannot or refuses to anonymize that(ese) object(s).
2 In WS mode, the metadata describing the object(s) or information extracted from it(them) in the
response SHALL be anonymized, too.
4 The Server shall return a new SOP Instance UID if the content of the object(s) has not already been
anonymized.
6 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
8 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
10 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
12 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
14 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
16 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
18 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.
20 8.1.9 Retrieve partial information from object(s)
Retrieval of additional information from the DICOM object(s), using a filtering mechanism based on
22 the XML mapping of DICOM IODs, as defined in PS 3.XX . This parameter shall be present only for the WS mode ―Information Requester‖
24 transaction. It shall not be present in the other ones.
The parameter name shall ―XPathList‖ for the WS mode ―Information Requester‖, including one or
26 multiple ―XPath‖.
28 8.2 PARAMETERS FOR DICOM IMAGE PERSISTENT OBJECTS
These parameters shall only be included when a request is made for a Single Frame Image Object(s) or
30 Multi-Frame Image or video Object(s) as defined in Section 7.2.
8.2.1 Annotation on the object
32 Annotation of an object(s) retrieved and displayed as an image. This parameter is OPTIONAL for the URI
based mode and the WS mode ―Rendered Requester‖ transaction. It shall not be present for other
34 WS mode transactions. It shall not be present if contentType is application/dicom, or is a non-image
MIME type (e.g., text/*). When it is not present for an image object(s), no annotation may be burnt in.
36 When used in conjunction with a presentation state object, it shall be applied after the presentation on the
image(s). When used in conjunction with the region parameter, it shall be applied after the selection of the
38 region.
The parameter name shall be “annotation” for URI based mode, and ―Annotation‖ for the WS mode. Its
40 value is a non-empty list of one or more of the following items, separated by a "," character:
"patient", for displaying patient information on the image(s) (e.g. patient name, birth date,…)
42 "technique", for displaying technique information of the image(s) (e.g. image number, study date,
image position,…).
Supplement 148 WADO Web Services
Page 28
Note: The exact nature and presentation of the annotation is determined by the Server. The annotation is
2 burned into the returned image pixels.
8.2.2 Number of pixel rows
4 The parameter name shall be “rows” for URI based mode, and ―Rows‖ for the WS mode.
The value shall be expressed as an integer, representing the image height to be returned. It is OPTIONAL
6 for the URI based mode and the WS mode ―Rendered Requester‖ transaction. It shall not be
present for other WS mode transactions. It shall not be present if contentType is application/dicom.
8 If both “rows” and “columns” are specified, then each shall be interpreted as a maximum, and a size will be
chosen for the image(s) within these constraints, maintaining the correct aspect ratio. If the number of
10 rows is absent and the number of columns is present, the number of rows shall be chosen in order to
maintain the correct aspect ratio. If both are absent, the image(s) (or selected region) is/are sent in
12 its/their original size (or the size of the presentation state applied on the image(s)), resulting as one pixel
of screen image for each value in the image(s) data matrix.
14 The value shall be encoded as an integer string (IS), as specified in PS 3.5.
8.2.3 Number of pixel columns
16 The parameter name shall be “columns” for URI based mode, and ―Columns‖ for the WS mode.
The value shall be expressed as an integer, representing the image width to be returned. It is OPTIONAL
18 for the URI based mode and the WS mode ―Rendered Requester‖ transaction. It shall not be
present for other WS mode transactions. It shall not be present if contentType is application/dicom.
20 If both “rows” and “columns” are specified, then each shall be interpreted as a maximum, and a size will be
chosen for the image(s) within these constraints, maintaining the correct aspect ratio. If the number of
22 columns is absent and the number of rows is present, the number of columns shall be chosen in order to
maintain the correct aspect ratio. If both are absent, the image(s) (or selected region) is/are sent in
24 its/their original size (or the size of the presentation state applied on the image(s)), resulting as one pixel
of screen for one pixel of the image(s).
26 The value shall be encoded as an integer string (IS), as specified in PS 3.5.
8.2.4 Region of the image
28 This parameter allows selection of a rectangular region of an image matrix to be retrieved. The purpose of
this parameter is to allow a user to view a selected area of the image matrix, for example at higher
30 magnification.
The parameter is OPTIONAL for the URI based mode and the WS mode ―Rendered Requester‖
32 transaction. It shall not be present for other WS mode transactions.
The parameter name shall be “region” for URI based mode, and ―Region‖ for the WS mode.
34 It shall not be present if contentType is application/dicom.
The value shall be expressed as a list of four positive decimal strings, separated by the ',' character,
36 representing the region of the source image(s) to be returned. These decimal values shall be values in a
normalized coordinate system relative to the size of the original image matrix measured in rows and
38 columns, with values ranging from 0.0 to 1.0, and representing in the following order:
the x position of the top left hand corner of the region to be retrieved, 0.0 corresponding to the
40 first column of the image matrix. In the WS mode, this value is encoded into a XML element
―XMin‖.
Supplement 148 WADO Web Services
Page 29
the y position of the top left hand corner of the region to be retrieved, 0.0 corresponding to the
2 top row of the image matrix. In the WS mode, this value is encoded into a XML element
―YMin‖.
4 the x position of the bottom right hand extent of the region, 1.0 corresponding to the last column
of the image matrix, 0.0 being forbidden. In the WS mode, this value is encoded into a XML
6 element ―XMax‖.
the y position of the bottom right hand extent of the region, 1.0 corresponding to the last row of
8 the image matrix, 0.0 being forbidden. In the WS mode, this value is encoded into a XML
element ―YMax‖.
10 Note: The Server may or may not support this parameter.
12 If this parameter is supported, an image matrix corresponding to the specified region shall be returned with
size corresponding to the specified normalized coordinate values otherwise the complete image matrix
14 shall be returned. If the presentationUID parameter is present, the region shall be selected after the
corresponding presentation state has been applied on the image(s).
16 8.2.5 Window center of the image
The parameter name shall be “windowCenter” for URI based mode, and ―WindowCenter‖ for the WS
18 mode.
Controls the luminosity of the image(s) as defined in PS 3.3. This parameter is OPTIONAL for the URI
20 based mode and the WS mode ―Rendered Requester‖ transaction. It shall not be present for other WS
mode transactions. It is REQUIRED if "windowWidth" is present. This parameter shall not be present if
22 there is a presentationUID parameter. It shall not be present if contentType is application/dicom.
The value shall be encoded as a decimal string (DS), as specified in PS 3.5.
24 8.2.6 Window width of the image
The parameter name shall be “windowWidth” for URI based mode, and ―WindowWidth‖ for the WS
26 mode.
Controls the contrast of the image(s) as defined in PS 3.3. This parameter is OPTIONAL for the URI
28 based mode and the WS mode ―Rendered Requester‖ transaction. It shall not be present for other
WS mode transactions. It is REQUIRED if "windowCenter" is present. This parameter shall not be
30 present if there is a presentationUID parameter. It shall not be present if contentType is application/dicom.
The value shall be encoded as a decimal string (DS), as specified in PS 3.5.
32 8.2.7 Frame Number
The parameter name shall be “frameNumber" for URI based mode, and ―FrameNumber‖ for the WS
34 mode.
Specifies that the single frame with that number within a multi-frame image object, as defined in PS 3.3,
36 shall be returned. It is OPTIONAL and shall be ignored in the case of all objects other than multi-frame
objects.
38 The value shall be encoded as an integer string (IS), as specified in PS 3.5.
Supplement 148 WADO Web Services
Page 30
8.2.8 Image Quality
2 The parameter name shall be “imageQuality" for URI based mode, and ―ImageQuality‖ for the WS
mode. It is OPTIONAL for the URI based mode and the WS mode ―DICOM requester‖ and ―Rendered
4 Requester‖ transactions. It shall not be present for other WS mode transactions. It shall not be
present if contentType is application/dicom, except if the transferSyntax parameter is present and
6 corresponds to a lossy compression.
If the requested MIME type is for a lossy compressed image (e.g. image/jpeg), this parameter indicates the
8 required quality of the image to be returned within the range 1 to 100, 100 being the best quality.
Note: Decompression and recompression may degrade the image quality if the original image was already
10 irreversibly compressed. In case the image has been already lossy compressed using the same format
as required (e.g. jpeg), it may be sent as it is without decompressing and recompressing it.
12
The value shall be encoded as an integer string (IS), as specified in PS 3.5.
14 Note: The specific interpretation of the meaning of this parameter is left to the interpretation of the
implementers of the standard.
16
8.2.9 Unique identifier of the presentation object
18 The parameter name shall be “presentationUID" for URI based mode, and ―PresentationUID‖ for the
WS mode.
20 SOP Instance UID of the presentation state storage object to be applied to the image(s). This parameter is
OPTIONAL for the URI based mode and the WS mode ―Rendered Requester‖ transaction. It shall
22 not be present for other WS mode transactions. It shall not be present if contentType is
application/dicom.
24 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.
26 If this parameter is combined with region and/or annotation parameter(s), the presentation state shall be
applied to the image(s) prior to selecting a region and burning in annotations.
28 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
30 columns parameters if present, otherwise the displayed area selected in the presentation state will be
returned without scaling.
32 Notes: 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
34 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
36 the rows and columns parameters, if present.
2. Any Displayed Area relative annotations specified in the presentation state are rendered relative to the
38 Specified Displayed Area within the presentation state, not the size of the returned image(s).
40 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 PS 3.14),
42 the grayscale or color space for the image(s) returned by the request is not defined by this standard.
8.2.10 Unique identifier of the series containing the presentation object
44 The parameter name shall be “presentationSeriesUID" for URI based mode, and
―PresentationSeriesUID‖ for the WS mode.
Supplement 148 WADO Web Services
Page 31
Series Instance UID of the series containing the presentation state storage object to be applied on the
2 image(s). This parameter is REQUIRED and shall only be present if "presentationUID" is present.
The value shall be encoded as a unique identifier (UID) string, as specified in PS 3.5, except that it shall
4 not be padded to an even length with a NULL character.
Note: As specified in DICOM, the Presentation State will be in the same study as the image(s) it applies to.
6
8.2.11 Transfer Syntax UID
8 The parameter name shall be “transferSyntax" for URI based mode, and ―TransferSyntaxUIDList‖
containing one or more ―TransferSyntaxUID‖ element(s) for the WS mode.
10 The Transfer Syntax(es) to be used within the DICOM image object(s), as specified in PS 3.6. This
parameter is OPTIONAL for the URI based mode and the WS mode ―DICOM Requester‖ transaction.
12 It shall not be present for other WS mode transactions. It shall not be present if contentType is other
than application/dicom.
14 By default the DICOM object(s) returned shall be encoded in Explicit VR Little Endian. Neither Implicit VR,
nor Big Endian shall be used. The response shall be the Transfer Syntax requested if possible. If it is not
16 possible for the response to be sent using the requested transfer syntax then the Explicit VR Little Endian
Uncompressed Transfer Syntax shall be used.
18 Note: The transfer syntax can be chosen as one of the values of TransferSyntaxUID corresponding to
JPIP, in case of which the returned objects will contain the URL of the JPIP session to launch for
20 retrieving the corresponding image.
The value shall be encoded as a unique identifier (UID) string, as specified in PS 3.5, except that it shall
22 not be padded to an even length with a NULL character.
24 Item #9: Append PS 3.18 by the following section.
9 Contents of the response
26 9.1 CONTENTS OF THE RESPONSE IN URI BASED MODE
In the URI based mode, the response will contain only the retrieved object.
28 9.2 CONTENTS OF THE RESPONSE IN WS MODE
The element for use with the Retrieve Imaging Document Set
30 Response Message, Retrieve Rendered Imaging Document Set Response Message and Retrieve Imaging
Document Set Metadata Response Message is defined as:
32 A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse element
An optional sequence of elements containing:
34 A element. The value of this element shall be the same as the value of
the StudyRequest/SeriesRequest/DocumentRequest/HomeCommunityId element in the Request
Supplement 148 WADO Web Services
Page 32
Message. If the element is not present in the Request Message, this
2 value shall not be present.
A required that identifies the Imaging Document Source from which
4 the document is to be retrieved. The value of this element shall be the same as the value of the
StudyRequest/SeriesRequest/DocumentRequest/RepositoryUniqueId element in the original
6 Request Message.
A required that identifies the document within the DICOM Server. The
8 value of this element shall be the same as the value of the
StudyRequest/SeriesRequest/DocumentRequest/DocumentUniqueId element in the original
10 Request Message. This value corresponds to the SOP Instance UID.
A required element that contains the retrieved document in base64binary
12 encoded format
A required element that indicates the MIME type of the retrieved document
14 The /RetrieveDocumentSetResponse/rs:RegistryResponse/@status attributes provides the overall status
of the request: It shall contain one of the following values:
16 urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess
18 urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure
For each document requested in a /StudyRequest/SeriesRequest/DocumentRequest element:
20 If a warning is reported when retrieving the document,
then a /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/
22 rs:RegistryError element shall be returned with:
@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning
24 @errorCode is specified
@codeContext contains the warning message
26 @location contains the DocumentUniqueId of the document requested
The document shall be returned in an instance of /RetrieveDocumentSetResponse/
28 DocumentResponse/Document as base64binary encoded data. The returned document and
warning are correlated via the DocumentUniqueId.
30 If an error is reported when retrieving a document,
then a /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/
32 rs:RegistryError element shall be returned with:
Supplement 148 WADO Web Services
Page 33
@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error
2 @errorCode is specified
@codeContext contains the error message
4 @location contains the DocumentUniqueId of the document requested
No corresponding RetrieveDocumentSetResponse/DocumentResponse element shall be
6 returned
If the document is successfully retrieved (without warning) then no
8 /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/rs:RegistryError
element shall be present and a /RetrieveDocumentSetResponse/DocumentResponse/Document
10 element shall be returned containing the document as base64binary encoded data.
The /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:ResponseSlotList element is not used in this
12 transaction. The /RetrieveDocumentSetResponse/rs:RegistryResponse/@requestId attribute is not used in
this transaction.
14 The element for use with the Retrieve
Imaging Document Set Information Response Message is defined as:
16 A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse element
An optional sequence of elements containing:
18 A element. The value of this element shall be the same as the value of
the StudyRequest/SeriesRequest/DocumentRequest/HomeCommunityId element in the Request
20 Message. If the element is not present in the Request Message, this
value shall not be present.
22 A required that identifies the Imaging Document Source from which
the document is to be retrieved. The value of this element shall be the same as the value of the
24 StudyRequest/SeriesRequest/DocumentRequest/RepositoryUniqueId element in the original
Request Message.
26 A required that identifies the document within the DICOM Server. The
value of this element shall be the same as the value of the
28 StudyRequest/SeriesRequest/DocumentRequest/DocumentUniqueId element in the original
Request Message. This value corresponds to the SOP Instance UID.
30 Zero or more containing:
A required that contains the XPath request
32 A required that contains the text corresponding to the XPath “filter” applied to
the Native Dicom Model transposition of the object, as defined in PS 3.X (Sup 118).
34 The error cases are managed in the same way than for other transactions, as described above.
Supplement 148 WADO Web Services
Page 34
Item #10: Append PS 3.18 by the following annex.
2 Annex E – WADO WS Schemas and Examples (informative)
E.1 WADO WS RNC SCHEMA
4 The following compact schema can be used for the WADO WS implementation:
TO BE COMPLETED AFTER THE PUBLIC COMMENT PHASE
6
8 E.2 WADO WS XSD SCHEMA
The following XSD schema can be used for the WADO WS implementation:
10 TO BE COMPLETED AFTER THE PUBLIC COMMENT PHASE
12 E.3 WADO WS WSDL SCHEMA
The following WSDL schema can be used for the WADO WS implementation:
14 TO BE COMPLETED AFTER THE PUBLIC COMMENT PHASE
16 E.4 WADO WS REQUEST EXAMPLE
Example of requesting the retrieval of images from a series in JPEG resized to 300 pixels max with
18 associated information on modality and instance number:
TO BE COMPLETED AFTER THE PUBLIC COMMENT PHASE
20
E.5 WADO WS RESPONSE EXAMPLE
22 Example of the response corresponding to the above request:
TO BE COMPLETED AFTER THE PUBLIC COMMENT PHASE
24