WADO and beyond

1
WADO and beyond

• Emmanuel Cordonnier
• emmanuel.cordonnier_at_etiam.com
• ETIAM

2
Presentation Contents

• WADO Objectives Definition
• WADO Implementation Examples
• WADO Implementation Note
• WADO Evolution

3
WADO Objectives Definition
4
WADO Origin Proposal to DICOM ISO in 1999
DICOM WG10 NEMA Vienna - March 20, 1999 -

• Because no specific Ad Hoc Group on Biomedical
  Imaging will be set up in ISO / TC215, new works
  on medical imaging must be done into DICOM (with
  a Category A Liaison Group between both)
• More and more it will be important that DICOM
  makes recommendations on the medical imaging
  aspects within non pure DICOM protocols

DICOM object
DICOM world
DICOM world
non DICOM world
5
1999 Proposals to DICOM
DICOM WG10 NEMA Vienna - March 20, 1999 -
Item of the Proposals Supplement
MIME type and file extension 54 (2001)
URL reference to DICOM part 10 files 85 (2003)
URL reference to DICOM services accessible from IT (web, email...). 85 (2003)113 (2006)
DICOM references into XML 85 (2003)
Mapping of DICOM attributes to XML ??
6
Syntax of the WADO HTTP GET method

• Syntax defined by the RFC2396 (URI)
• http//ltauthoritygtltpathgt?ltquerygt
• e.g
• http//www.hosp.fr/dicom/wado.asp?studyUID1
• The  Web Access to DICOM Persistent Object 
  standard defines only the ltquerygt

Path of the Web Enabled DICOM Server
WADO Parameter(s)
7
Selection Parameters

• studyUIDseriesUIDobjectUIDframeNumber
• studyUID gt UID of the study containing the
  object(s)
• seriesUID gt UID of the series containing the
  object(s)
• objectUID gt UID of the single object (Service
  Object Pair SOP)
• frameNumber gt number of the selected frame
  (multiframe image objects) if NOT retrieved as
  application/dicom

8
Parameters when the object is return as
application/dicom

• transferSyntaxanonymizecharset
• transferSyntax gt DICOM UID of the transferSyntax
  to be applied to the image (lossy/lossless
  compression). Implicit and Big Endian TS shall
  not be used.
• anonymize gt yes for blanking all the personal
  healthcare information (patient name, study
  date) as described in Sup. 55. Potentially the
  server can refuse to deliver an object if there
  are some risk the personal information is burned
  into the image (secondary capture)
• charset gt for converting the text fields in a
  different character set (available also if object
  return as text/xxx)

9
Parameters when the object is return as image/xxx
(1)

• imageQuality
• presentationUID presentationSeriesUID
  windowCenter windowWidth
• imageQuality gt controls the level of compression
  (from 1 to 100)
• presentation gt UIDs of the Presentation State
  SOP and of its series to be applied on the image
  (P-values, and display size set to the original
  size if undefined)
• windowCenter / windowWidth gt controls the
  luminosity and the contrast of the BW image

10
Parameters when the object is return as image/xxx
(2)

• regionrowscolumnsannotation
• region gt part of the image to be displayed, in
  relative coordinates (top left hand corner and
  bottom right hand extent)
• rows gt maximum number of pixels (vertical)
• columns gt maximum number of pixels (horizontal)
• annotation gt text to be superimposed of the
  image (patient and / or technique for
  demographic information and technical
  information, respectively)

11
Providing a image as image/xxx
12
Implementation of DICOM

• Principles of implementation
• Initial examples
• WADO in IHE XDS-I

13
Principles of implementation
Web Client System
Web Access to Dicom Persistent Objects
Web Access to Dicom Persistent Objects
DirectInterface
Web Gateway
Gateway
DICOM Q/R
DICOM Interface
Web Interface
DICOM Q/R
DICOM Interface
DICOM Objects Database
DICOM Objects Database
Flexibility for the client to be implemented
either as new system or on existing system
14
A) retrieval of DICOM images in jpeg format

• Proof-of-concept implementation
• Windows NT-based host
• Microsoft IIS 5.1 Web Server
• WADO JPEG functionality added to the Web
  Extension for the DICOM server product
• Images retrieved using Internet Explorer 6.0
  running on Windows XP using pre-determined UIDs
• Full implementation, including retrieval of
  images in native DICOM format, likely available
  in next release of the product

15
B) WADO Trial available on Internet
16
C) Viewer using WADO
17
D) WADO Gateway for reports
18
Implementations Overview
19
IHE XDS-I

• The IHE Radiology Domain has defined a  XDS
  content profile  for linking a Cross-Enterprise
  Document Sharing to the PACS
• The solution has been proposed as a  Manifest 
  (DICOM KOS) stored in the Document Repository
• The images are still stored in the PACS and
  accessed through their reference
• Because the XDS Consumer is web enabled, WADO is
  the natural retrieving method
• XDS-I has been largely demonstrated

20
IHE XDS-I Diagram
21
WADO Implementation Note

• Retrieving Multiple Objects
• Managing WADO Reference
• Managing WADO URL Left Part
• Association of WADO and JPIP

22
Retrieving Multiple Objects

• OBJECTIVE
• Applications aim to manage a reference to
  multiple DICOM Information Objects
• WADO LIMITATION
• WADO does not provide any mechanism for
  retrieving multiple Objects
• PROPOSED SOLUTION
• Multiple references
• The Application maintains all the reference to
  individual DICOM objects
• Key Object Selection
• The Server can create a DICOM Key Object
  Selection for each set of DICOM Objects the
  Application has to access using WADO.
• The Application stores the link to this KOS and
  retrieve it first
• It opens it, and accesses all the referenced
  DICOM Objects

23
Managing WADO Reference

• OBJECTIVE
• The Applications aim to display DICOM objects
  without necessarily activate a DICOM viewer
• WADO LIMITATION
• WADO URL string implies only one kind of display
  (e.g. Jpeg thumbnail)
• PROPOSED APPROACH
• As defined in the HL7, the application manages
  the link as follow
• a. Reference of the (WADO) Server (WADO URL left
  part)
• b. DICOM UID of the Study
• c. DICOM UID of the Series
• d. DICOM UID of the SOP Instance
• e. DICOM UID of the Class of the Object.
• The Application may then build any WADO request

24
Managing WADO URL left part

• OBJECTIVE
• Application have to maintain persistent links to
  DICOM objects
• WADO LIMITATION
• DICOM WADO does not define the left part of the
  URL/URI
• SUGGESTED APPROACH
• The Application maintains a WADO Server ID
  enabling to update the Server address for each
  object
• INCLUDING THE WADO LINK INTO A TEXT DOCUMENT
• Into a document (e.g. PDF), the left part is a
  virtual DICOM server (e.g. http//LocalDICOMServ
  er/WADO), mapped on both emission and reception
  sides on the actual WADO Server
• Local DNS proxy for defining the correspondence
  between the server names (e.g. LocalDICOMServer
  alias of server234)
• Mapping between the URL invocation and the actual
  script page (e.g. WADO alias of
  scripts/wado.js)

25
Association of WADO and JPIP

• OBJECTIVE
• Providing streaming on referenced images
• WADO LIMITATION
• WADO does not propose means for gradual
  retrieving of images
• PROPOSED APPROACH
• Set WADO transferSyntax attribute to ltJPIPgt
• Initiate a DICOM JPIP session

See presentation made by Lev Weisfeiler
26
Evolution of WADO

• Limitation of WADO
• Web Services
• New Work Item and Planning

27
Limitation of WADO

• One SOP Instance only in one call (no way for
  retrieving all the series/study)
• Suited for Web Browser based solution, less for
  direct with applications
• The URL based query is easy to write, but not
  adapted for being parsed
• No easy way to help the application development
  through WSDL

28
Web Services why now?

• The WS are now maturing
• The deployment beyond web server to web server is
  emerging (application to appli.)
• The WS-I Profiles are defining a real
  interoperable solution, including (more or less!)
  the security and reliability aspects
• The MTOM mechanism for conveying binary content
  is now supported by development platforms (.Net,
  Java)

29
Web Services for Dummies

• Submitting a form to a Web Server, you are using
  http POST based structured message, containing
  the  input fields 
• It may also contain files to be uploaded
• WS are using such mechanism for the request and
  the response, and define the structure of message
  in XML SOAP
• A WSDL (XML) file defines the syntax of the
  communication (request and response)

30
MTOM for Dummies

• Date Thu, 09 Sep 2004 184752 GMT
• Server Apache/2.0.48 (Win32) mod_ssl/2.0.48
  OpenSSL/0.9.7d
• Keep-Alive timeout15, max100
• Connection Keep-Alive
• Transfer-Encoding chunked
• Content-Type Multipart/RelatedboundaryMIME_Boun
  darytypeapplication/xopxmlcharsetUTF-8start-
  info"application/soapxml"
• --MIME_Boundary
• Content-ID ltmymainpart_at_crf.canon.frgt
• Content-Type application/xopxmlcharsetUTF-8ty
  pe"application/soapxml"
• Content-Transfer-Encoding binary
• ltsoapEnvelope xmlnssoap"http//www.w3.org/2003/
  05/soap-envelope" xmlnsxmlmime"http//www.w3.org
  /2004/06/xmlmime" xmlnsxop"http//www.w3.org/200
  4/08/xop/include"gtltsoapHeadergtlt/soapHeadergtltsoa
  pBodygtltns1EchoTest xmlnsns1"http//example.org
  /mtom/data"gtltns1Data xmlmimecontentType"image/j
  peg"gtltxopInclude href"cidthismessage/resource
  0.jpeg"gtlt/xopIncludegtlt/ns1Datagtltns1Data
  xmlmimecontentType"image/jpeg"gtltxopInclude
  href"cidthismessage/resource1.jpeg"gtlt/xopInclu
  degtlt/ns1Datagtltns1Data xmlmimecontentType"image
  /jpeg"gtltxopInclude href"cidthismessage/resour
  ce2.jpeg"gtlt/xopIncludegtlt/ns1Datagtlt/ns1EchoTestgt
  lt/soapBodygtlt/soapEnvelopegt
• --MIME_Boundary
• Content-ID ltthismessage/resource0.jpeggt
• Content-Type image/jpeg
• Content-Transfer-Encoding binary
• ÿØÿàJFIF, (IMAGE 1 in BINARY)

31
WADO in WS, which form?

• IHE ITI wrote White Paper on WS implementation,
  based on WS-I
• The XDS.b Retrieve Document Set transaction is
  similar to WS/WADO
• All the WADO query parameters can be directly
  transposed  as is  in WS
• The response structure can be derived from the
  Retrieve Document Set structure

32
WADO  brothers 

• WADO implies to have the reference
• A notification mechanism may be developed on WS
  (NADO)
• A Query by IDs mechanism may enable an
  application to obtain the reference (QIDO)
• A New Work Item will be propose at the next DSC
  (April 11, 2008)

33
Conclusion (for today)

• WADO is still in its emerging implementation,
  but promising
• WADO contributes to facilitate to co-existence of
  IS and PACS (e.g. XDS-I)
• Its evolution through Web Services may enhance
  the integration between PACS and EHRs