WADO

1
WADO Web Access toDICOM Persistent Objects
Partnerships

• Emmanuel Cordonnier
• ETIAM

2
Context

• Users of medical information systems require
  rapid and reliable access to reports and images
• Within computerized environments such access is
  increasingly based on web technologies
• Access to relevant DICOM persistent objects is
  required without the need for duplication of such
  data objects
• Clinicians need to have access
• either in native DICOM format for advanced use,
• or rendered into a generic format (e.g. JPEG,
  PDF) that can be presented with off-the-shelf
  applications

3
ISO and DICOM effort

• ISO TC215 (Medical Informatics) / WG2 (Messages
  and Communication) and DICOM / WG10 (Strategy
  Advisory) have decided to jointly develop a new
  standard for defining a web hook  on DICOM
• After 2 years of work, a couple of face to face
  meetings and T-cons involving a douzen of key
  experts from user and vendor sides,  WADO  is
  ready for ballot

4
Scope of the Standard

• New web-based service for accessing and
  presenting DICOM persistent objects
• Simple mechanism for accessing a DICOM persistent
  object from HTML pages or XML documents, through
  HTTP/HTTPs protocol, using the DICOM UIDs (study,
  series, instance)
• NOT a way for searching DICOM images from the
  web, using parameters such as the Patient ID
• This standard relates only to DICOM persistent
  objects (e.g. images, reports, NOT workflow msg)

5
Normative references

• DICOM PS 3.0
• Digital Imaging and COmmunication in Medicine
• IETF RFC2045 to 2049
• Multipurpose Internet Mail Extension (MIME)
• IETF RFC2396
• Uniform Resource Identifiers (URI) Generic
  Syntax
• IETF RFC2616
• Hypertext Transfer Protocol -- HTTP/1.1
• IETF RFC3240
• Application/dicom MIME Sub-type

6
Retrieving Persistent Objects
Objects
7
Terms and definitions (1)

• DICOM Persistent Object
• An instance of a data object as defined by DICOM
  PS 3.3 that has been allocated an unique
  identifier in the format specified for SOP
  Instance UID in DICOM PS 3.3 and has been
  chosen as an object to be saved securely for some
  period of time. Within the DICOM Standard, a
  DICOM Persistent Object is referred to as a
  Composite Service Object Pair (SOP) Instance.

8
Terms and definitions (2)

• Web Client System
• A system using Internet technologies (web,
  e-mail) interested in retrieving DICOM
  Persistent Objects from a Web Enabled DICOM
  Server, through HTTP/HTTPs protocol
• Web Enabled DICOM Server
• A system managing DICOM Persistent Objects and
  able to transmit them on request to the Web
  Client System
• Web Access to DICOM Persistent Objects
• Service enabling Web Client System to retrieve
  DICOM Persistent Objects managed by Web Enabled
  DICOM Server, through HTTP/HTTPs protocol.

9
Applications

• Referencing an image or a report from an
  electronic patient record (EPR)
• Including references to images in an e-mail
  (second opinion, hospital to doctor distribution)
• Providing access by outside referring doctors to
  a hospital web server that contains references to
  reports, images and waveforms
• Providing access to anonymized DICOM reports,
  images and waveforms via a web server, for
  teaching purposes and for clinical trials

10
Scenario form the reference
Radiology dept
Clinical dept
11
Typical scenario form the reference

• The radiologist performs an acquisition creating
  DICOM images
• He interprets the images producing a DICOM SR
  including reference to some significant images
• He exports the DICOM SR as an HL7 CDA including
  those references to  external observations 
  (instance, series and study UIDs as different
   id  sets, and  path  of the DICOM System in
  the  reference )
• The CDA is stored into the EMR/EPR/EHR database,
  using patient information for selecting the right
  record

12
Scenario web access
Radiology dept
Web Access to DICOM Persistent Object
Clinical Document Consultation
Clinical dept
13
Typical scenario web access

• A clinician consults the CDA (the stylesheet
  builds the  URI  using the  reference  of the
   custodian  which provided the CDA, completed
  by the  Web Access to DICOM Persistent Objects 
  parameters)
• The clinician clicks on one  image  link
• The WADO service, implemented as an HTTP script,
  build a  DICOM FIND  message using the
  parameters (studyUID1.2.32.seriesUID1.2.32.),
  and retrieve the image form the DICOM server
• It creates the HTTP response body as a MIME part
  (either application/dicom, or image/jpeg)

14
Examples 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
15
Interaction Diagram
Web Enabled DICOM Server
Web Client System
Object(s) request (HTTP GET)
Object(s) send (HTTP response header and body)
16
Syntax of the 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)
17
Consistency with IHE IT Infrastructure Approach

•  Inspired  by the WADO work, IHE IT
  Infrastructure has defined a  Retrieve
  Information for Display (RID) integration
  profile, enabling
• To retieve a list of  typed  documents
  available for a patient (thanks to PatientID)
• To retrieve a document using its UID
•  Inspired  by the IHE IT Infrastructure work,
  WADO has defined a requestType(WADO) parameter
  for compatibility with extensions

18
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

19
MIME type of return object

• The MIME type of the object contained in the
  contentType parameter, compatible the ltacceptgt
  parameter of the GET method
• application/dicom for all objects, or a different
  MIME type for converting the DICOM object,
  depending of the nature of the object
• image/jpeg for still image object
• text/html or text/plain for text object, or
• other optional formats

20
MIME type of a Structured Report

• application/dicom
• application/x-hl7-cda-level-onexml for
  converting the SR into CDA (see HL7 Imaging SIG
  /DICOM WG20)
• text/plain for  minimal  version of document
• text/rtf for  Word  version of document
• application/pdf for  stable  version of
  document, potentially containing images
• text/html a priori without the images (to
  contained into only one file). The reference to
  the images can used the WADO syntax.

21
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)

22
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

23
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)

24
Security aspects

• It is clear that the information contained within
  DICOM objects may be considered as protected
  healthcare information (PHI). The protocol used,
  that is HTTP, can be replaced by HTTPs, which is
  its secure extension, for that purpose.
• Two optional parameters, anonymize and
  annotation, control respectively the absence of
  patient identification in a retrieved DICOM
  object and the presence of patient identification
  burned in to the pixel data of images.

25
Providing a image as image/xxx
26
Client flexibility

• The WADO functionality supports access to
• Native (un-rendered) DICOM data
• Associated rendering data e.g. Gray Scale
  Presentation State
• Rendered information e.g. JPEG image
• So client design can be
• Simple, relying on basic features of the web
  browser
• Complex, providing advanced functionalities by
  taking raw DICOM data and deciding the
  processing and rendering to be applied

27
Conclusion

• A small standard but a precious  missing link 
  offering the modernity of the Web to DICOM
  equipement and all the DICOM richness and
  stability to the (messy) Web
• Will be implemented largy soon in large and small
  systems ( where is WADO? )
• To be extended (multiple objects retrieval, WSDL
  definition) after implementations
• Thanks to Hidenori Shinoda and Nick Brown for
  chairing the WADO ad hoc group, as well as to all
  the contributors of that group