1 / 33

WADO and beyond

Explore WADO objectives, implementation examples, and evolution in the DICOM world. Learn about key parameters and principles of implementation for accessing DICOM objects via the web.

phyllisa
Download Presentation

WADO and beyond

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WADO and beyond Emmanuel Cordonnier emmanuel.cordonnier@etiam.com ETIAM

  2. Presentation Contents • WADO Objectives & Definition • WADO Implementation Examples • WADO Implementation Note • WADO Evolution

  3. WADO Objectives & Definition

  4. DICOM WG10 NEMA Vienna - March 20, 1999 - WADO Origin: Proposal to DICOM & ISO in 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. DICOM WG10 NEMA Vienna - March 20, 1999 - 1999 Proposals to DICOM

  6. Syntax of the WADO HTTP GET method • Syntax defined by the RFC2396 (URI) • http://<authority><path>?<query> • e.g: • http://www.hosp.fr/dicom/wado.asp?studyUID=1… • The « Web Access to DICOM Persistent Object » standard defines only the <query> Path of the Web Enabled DICOM Server WADO Parameter(s)

  7. Selection Parameters • studyUID&seriesUID&objectUID[&frameNumber] • studyUID => UID of the study containing the object(s) • seriesUID=> UID of the series containing the object(s) • objectUID => UID of the single object (Service Object Pair SOP) • frameNumber => number of the selected frame (multiframe image objects) – if NOT retrieved as application/dicom

  8. Parameters when the object is return as application/dicom [transferSyntax][anonymize][charset] • transferSyntax => DICOM UID of the transferSyntax to be applied to the image (lossy/lossless compression). Implicit and Big Endian TS shall not be used. • anonymize => “=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 => 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 => controls the level of compression (from 1 to 100) • presentation => 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 => controls the luminosity and the contrast of the B&W image

  10. Parameters when the object is return as image/xxx (2) [region][rows][columns][annotation] • region=> part of the image to be displayed, in relative coordinates (top left hand corner and bottom right hand extent) • rows => maximum number of pixels (vertical) • columns => maximum number of pixels (horizontal) • annotation => text to be superimposed of the image (“patient” and / or “technique” for demographic information and technical information, respectively)

  11. Select the object studyUID&… presentationUID&…or windowCenter… Apply the presentation Select a region region Build the pixel area CT WC-800 WW200 rows…&columns… Burn the annotations annotation Content-Type: image/jpeg; name="Image.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Image.jpg" /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wgARCABkAGQDASIA AhEBAxEB/8QAGwABAQEBAQEBAQAAAAAAAAAAAAUEAwECBgf/xAAYAQEAAwEAAAAAAAAAAAAAAAAA AQIDBP/aAAwDAQACEAMQAAAB/qgAAAAAAABNpnSTVc6Sbpm2lO6RG0a7gAcZWztzcORR8tef9+6a 09xdPZncOjtAfH3Opls+oOrHlq8+Eubfoc3LpfXRn4ZaZUtOTXr0BfVPoKZxud1lzRdFJN5PSklI 8sIjJrNegLXAAAAAAAAAAAAAA//EACEQAAMAAQQCAwEAAAAAAAAAAAECAwQREhMUACAQNFAk/9oA CAEBAAEFAvyksxxl7DILsYJ2GVSyIrXoJVbf6zoKeT+lPscTS48WUWM8lSMQHWSPTs+r42rcI4EG Generate the MIME type contentType DOE 2003-9-22 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://LocalDICOMServer/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 <JPIP> • 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 18:47:52 GMT Server: Apache/2.0.48 (Win32) mod_ssl/2.0.48 OpenSSL/0.9.7d Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: Multipart/Related;boundary=MIME_Boundary;type=application/xop+xml;charset=UTF-8;start-info="application/soap+xml" --MIME_Boundary Content-ID: <mymainpart@crf.canon.fr> Content-Type: application/xop+xml;charset=UTF-8;type="application/soap+xml" Content-Transfer-Encoding: binary <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xmlmime="http://www.w3.org/2004/06/xmlmime" xmlns:xop="http://www.w3.org/2004/08/xop/include"><soap:Header></soap:Header><soap:Body><ns1:EchoTest xmlns:ns1="http://example.org/mtom/data"><ns1:Data xmlmime:contentType="image/jpeg"><xop:Include href="cid:thismessage:/resource0.jpeg"></xop:Include></ns1:Data><ns1:Data xmlmime:contentType="image/jpeg"><xop:Include href="cid:thismessage:/resource1.jpeg"></xop:Include></ns1:Data><ns1:Data xmlmime:contentType="image/jpeg"><xop:Include href="cid:thismessage:/resource2.jpeg"></xop:Include></ns1:Data></ns1:EchoTest></soap:Body></soap:Envelope> --MIME_Boundary Content-ID: <thismessage:/resource0.jpeg> Content-Type: image/jpeg Content-Transfer-Encoding: binary ÿØÿàJFIF, (IMAGE 1 in BINARY) --MIME_Boundary Content-ID: <thismessage:/resource1.jpeg> Content-Type: image/jpeg Content-Transfer-Encoding: binary ÿØÿàJFIFÿÛ (IMAGE 2 in BINARY) --MIME_Boundary--

  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

More Related