Digital Imaging and Communications in Medicine (DICOM)
WADO Implementation Note (INFORMATIVE)
Prepared by:
DICOM Standards Committee, Working Group 10
1300 N. 17th Street
Rosslyn, Virginia 22209 USA
VERSION:
Version 0.1, Authored by Emmanuel Cordonnier, ETIAM
June 13, 2007
Template for DICOM
Page i
Table of Contents
Forward ............................................................................................................................................................ii
1
RETRIEVING SEVERAL OBJECTS ........................................................................................................ 2
1.1
OBJECTIVE ............................................................................................................................. 2
1.2
WADO LIMITATION................................................................................................................. 2
1.3
2
3
4
PROPOSED SOLUTION ......................................................................................................... 2
1.3.1
Multiple references ......................................................................................................... 2
1.3.2
Key Object Selection ...................................................................................................... 2
MANAGING WADO REFERENCE .......................................................................................................... 2
2.1
OBJECTIVE ............................................................................................................................. 2
2.2
WADO LIMITATION................................................................................................................. 2
2.3
PROPOSED APPROACH ....................................................................................................... 2
MANAGING WADO URL “LEFT PART” .................................................................................................. 2
3.1
OBJECTIVE ............................................................................................................................. 2
3.2
WADO LIMITATION................................................................................................................. 2
3.3
SUGGESTED APPROACH ..................................................................................................... 2
3.3
INCLUDING THE WADO LINK INTO A TEXT DOCUMENT .................................................. 3
ASSOCIATION OF WADO and JPIP ....................................................................................................... 3
3.1
OBJECTIVE ............................................................................................................................. 3
3.2
WADO LIMITATION................................................................................................................. 3
3.2
PROPOSED APPROACH ....................................................................................................... 3
Template for DICOM
Page ii
Forward
WADO is defined in DICOM PS 3.18. This mechanism enables a “web client application” (called the
Application) to retrieve one particular DICOM object fro a “web enabled DICOM system” (called the
Server), using the http protocol, through the “GET” command.
This supplement aims to help the implementers and may be the users to see where, when and how WADO
can be used to facilitate the access to medical imaging information.
There are many ways of implementing WADO and this note pretends neither to list all of them nor to
suggest the best way, but only to give some helps for those who need to be guided in their first steps using
WADO.
It is based on the feed-back from vendors and users on WADO, what it actually does, what it does not, and
how it can be combined with other DICOM mechanisms, as JPIP for example.
All the sections of the present document are informative.
1
2
1.1
RETRIEVING SEVERAL OBJECTS
OBJECTIVE
Some applications as Electronic Health Record (EHR) or Electronic Medical Record (EMR) or any
Information System (IS), called in the following section “the Application”, aim to manage a reference to
multiple DICOM Information Objects in order to enable the user of their system to access the relevant
6 imaging information while accessing the patient record.
4
1.2
8
10
WADO LIMITATION
WADO does not provide any mechanism for retrieving multiple DICOM Information Objects.
1.3
PROPOSED SOLUTION
1.3.1
Multiple references
In the absence of other mechanisms described below, the Application has to maintain all the reference to
individual objects (e.g. images within a certain series or study). The user will select each one in the
Application, and then visualize image (or object) by image, either using a “simple viewer” if the object is
14 retrieved in a non DICOM format (e.g. JPEG for images) or using a “DICOM viewer” if the object is
retrieved in DICOM.
12
16
1.3.2
Key Object Selection
As suggested by some integration profiles (e.g. IHE IT Infrastructure Cross-Enterprise Document Sharing
18 for Imaging XDS-I), the Server can create a DICOM Key Object Selection for each set of DICOM Objects
the Application has to access using WADO. So the Application will only manage the link to this object and
20 retrieve first this object in DICOM, open it, and enable the user to access any one of the object referenced
into the Key Object Selection. It implies either the application to be able to open such Key Object
22 Selection, or to call a “KOS helper” for doing it. The interest of such approach is to facilitate the display of
all the images in one operation (layout presentation).
Template for DICOM
Page 2
2
MANAGING WADO REFERENCE
2
2.1
4
The Application implementers and users aim to use the flexibility of WADO to easily view the DICOM
objects without necessarily activate a DICOM enabled system (e.g. viewer).
2.2
OBJECTIVE
WADO LIMITATION
Because WADO is using the URL/URI protocol to convey all the necessary parameters for accessing the
DICOM Information Objects, all these parameters have to be sent in one unique operation. Use of
8 URL/URI is very common and Application implementers are tempted to store only one URL/URI string for
each DICOM Object reference. But such an approach limits the possibility of visualization to only one
10 option (e.g. either DICOM retrieve or JPEG retrieve in a particular size).
6
2.3
12
PROPOSED APPROACH
As defined in the HL7 Reference Information Model for External Observation relative to images, it is
suggested the Application manages at least five parameters for any reference to DICOM Object:
a. Reference of the (WADO enabled) Server (see section of the WADO URL “left part”);
b. DICOM UID of the Study;
16
c. DICOM UID of the Series;
d. DICOM UID of the SOAP Instance;
18
e. DICOM UID of the Class of the Object.
The Application may then build any WADO request to the Server as a combination of these information,
20 the last one (Class of the object) being used for deciding which other WADO parameters have to be set
(e.g. “region” for objects containing image pixels).
14
3
22
3.1
MANAGING WADO URL “LEFT PART”
OBJECTIVE
24
The Application has to know the exact content of the left part of the WADO URL/URI to be able to
construct it.
26
3.2
28
DICOM WADO standard does not define the “left part” of the URL/URI, letting its definition on the
implementation side.
3.3
WADO LIMITATION
SUGGESTED APPROACH
The URL/URI is a simple string consisting of a “left part” containing the path of the script to activate on the
Server, and a “right part” defining the WADO parameters, separated by a question mark “?”. The first one
32 is the same for all the DICOM Objects accessed into the Server, while the second one is different for each
Object.
30
34
The simplest way is to manage a simple “URL Start” (e.g. http://server234/scripts/wado.js) but it is
preferable to manage a “WADO Server ID” enabling to update the Server address without having to update
Template for DICOM
Page 3
all the references to the objects stored into this Server. One way may be to define this Server ID as an
Application Entity Title (AET), as suggested in the IHE ITI XDS-I Integration Profile. It offers the advantage
to give to the application the possibility to access the object using the DICOM Store Service. It implies that
4 the Application is managing a configuration table maintaining the correspondence between the Server ID
and the WADO script URL Path.
2
6
3.3
INCLUDING THE WADO LINK INTO A TEXT DOCUMENT
When the WADO link is included inside a persistent document (PDF for example), the only way to store
the WADO information in a usable form is to effectively encode it as a complete URL string. If the
document is transmitted from one site to another one having a different DICOM environment, the WADO
10 link will not work on the recipient side. One approach may be to use namespace mechanism defining a
“virtual” DICOM server (e.g. http://LocalDICOMServer/WADO) and to map it on both emission and
12 reception sides on the relevant actual WADO Server. It implies a double configuration:
8
a. Local DNS proxy for defining the correspondence between the server names (e.g.
“LocalDICOMServer” alias of “server234”);
b. Correspondence between the URL invocation and the actual script page, thanks to the URL
rewrite mode in the web server configuration (e.g. “WADO” alias of “scripts/wado.js”);
14
16
4
ASSOCIATION OF WADO and JPIP
18
3.1
OBJECTIVE
20
The Application aims to provide to the users a mechanism enabling to have rapidly to one DICOM Image
in a “thumbnail” mode, and if interest to manipulate such image by regions using image progressive
retrieve.
22
3.2
24
WADO proposes means to retrieve only a reduced images, thanks to the “rows / columns” parameters,
and/or only a part of the image, thanks to the “region” parameter, but no mechanism for retrieving only the
“missing part” (either a region or a more detailed sampling) for optimizing the bandwidth.
26
3.2
WADO LIMITATION
PROPOSED APPROACH
DICOM defines a JPIP Transfer Syntax for images. The pixels are in such case “replaced” by the URL
enabling to start a JPIP session giving access to the image through a progressive protocol. The WADO /
JPIP approach consists in retrieving first the image in WADO précising the Transfer Syntax is the JPIP one
30 (which implies the object is retrieved in DICOM) and then extract from the DICOM object the URL of the
JPIP session which can then been open by the Application for a progressive access to the image.
28
32