1. WADO evolution Multipart ? JPIP ? Or Web Services? With help from Emmanuel Cordonnier (ETIAM) - Thanks to him Multipart ? JPIP ? Or Web Services? With help from Emmanuel Cordonnier (ETIAM) - Thanks to him

2. Why a WADO evolution ?  Lot of request to support multipart for series/study retrieve  Some would like to see WADO supporting JPIP (part of JPEG 2000)  Lot of request to support multipart for series/study retrieve  Some would like to see WADO supporting JPIP (part of JPEG 2000)

3. Multipart (1)  IHE XDS  Multipart is neither understood nor well accepted by the vendors even it’s a part of XDS (the same document could be ”single-file" or "multi-files" and in this case "multipart“).  The "XML guys" would like to do everything embedded into XML. They think that a complex document is a big file (unique XML) with a lot of binary documents inside.  As example given, scanned PDF documents converted as CDA, the “full XML” approach was chosen vs. multipart.  IHE XDS  Multipart is neither understood nor well accepted by the vendors even it’s a part of XDS (the same document could be ”single-file" or "multi-files" and in this case "multipart“).  The "XML guys" would like to do everything embedded into XML. They think that a complex document is a big file (unique XML) with a lot of binary documents inside.  As example given, scanned PDF documents converted as CDA, the “full XML” approach was chosen vs. multipart.

4. Multipart (2)  Retrieving several images from a series/study could be done with two processes:  Using (present HTTP GET based) WADO and KOS  the server publishes a "manifest" (DICOM Key Object Selection) get by the “web client" (as DICOM using WADO)  the client builds queries using WADO (for DICOM objects or Jpeg images) from the references to DICOM objects contained in KOS, image by image or as a ”set" to display it together. This approach was retained for IHE XDS-I profile.  KOS retrieval as HTML (XML?) using WADO would allow to have WADO links directly accessible but image per image.  Evolution of WADO to Web Services  The communication is no longer in HTTP Get but uses HTTP POST + SOAP that means web services, using the MTOM/XOP as transport mode for the answer.  It is too early to define it, but in one or two years, following the approach used in IHE XDS  Retrieving several images from a series/study could be done with two processes:  Using (present HTTP GET based) WADO and KOS  the server publishes a "manifest" (DICOM Key Object Selection) get by the “web client" (as DICOM using WADO)  the client builds queries using WADO (for DICOM objects or Jpeg images) from the references to DICOM objects contained in KOS, image by image or as a ”set" to display it together. This approach was retained for IHE XDS-I profile.  KOS retrieval as HTML (XML?) using WADO would allow to have WADO links directly accessible but image per image.  Evolution of WADO to Web Services  The communication is no longer in HTTP Get but uses HTTP POST + SOAP that means web services, using the MTOM/XOP as transport mode for the answer.  It is too early to define it, but in one or two years, following the approach used in IHE XDS

5. Multipart (3)  The initially considered solution (an unique UID possible and retrieval of a ”set of images" using multipart - that means all in DICOM or all in JPEG) could be rejected by the vendors because actual browsers do not support the multipart. It may change in the future.  Despite the fact that with IE, if one put a multipart - related or mixed - with several jpeg images inside using the right file extension, one obtains the images on line (like digital photos sent by mail).  The initially considered solution (an unique UID possible and retrieval of a ”set of images" using multipart - that means all in DICOM or all in JPEG) could be rejected by the vendors because actual browsers do not support the multipart. It may change in the future.  Despite the fact that with IE, if one put a multipart - related or mixed - with several jpeg images inside using the right file extension, one obtains the images on line (like digital photos sent by mail).

6. JPIP (1)  The JPIP large supremacy (vs. multiple exchange of JPEG images) in the present implementation context is not yet technically proved, despite several trials.  JPIP is based on JPEG 2000 (vs. JPEG).  The place where JPIP use is particularly justified is pathology WSI (100.000 x 50.000 images to 4 Go compressed) and DICOM has not selected the JPIP approach (vs. JPEG tiles), yet.  The JPIP large supremacy (vs. multiple exchange of JPEG images) in the present implementation context is not yet technically proved, despite several trials.  JPIP is based on JPEG 2000 (vs. JPEG).  The place where JPIP use is particularly justified is pathology WSI (100.000 x 50.000 images to 4 Go compressed) and DICOM has not selected the JPIP approach (vs. JPEG tiles), yet.

7. JPIP (2)  Lot of vendors are implementing ”gizmos” like "web + JPIP + jpeg2000", most are doing it using proprietary stuffs without really using the “pure” DICOM Jpeg 2000 format.  One of the most important differences between jpeg and jpeg 2000 is that it exists basic jpeg codec on client PC or Mac but not for jpeg 2000 and so the codec shall be incorporated in the workstation software. It’s the same for JPIP.  Lot of vendors are implementing ”gizmos” like "web + JPIP + jpeg2000", most are doing it using proprietary stuffs without really using the “pure” DICOM Jpeg 2000 format.  One of the most important differences between jpeg and jpeg 2000 is that it exists basic jpeg codec on client PC or Mac but not for jpeg 2000 and so the codec shall be incorporated in the workstation software. It’s the same for JPIP.

8. JPIP (3)  WADO allows to do progressive display in jpeg using an "intelligent" client (like JPIP) controlling the image size and the displayed region.  The most important difference vs. JPIP is that the entire displayed image is send when JPIP allows to send only the difference… IF THE SERVER KEEP TRACK OF THE "CONTEXT" for this specific terminal.  WADO allows to do progressive display in jpeg using an "intelligent" client (like JPIP) controlling the image size and the displayed region.  The most important difference vs. JPIP is that the entire displayed image is send when JPIP allows to send only the difference… IF THE SERVER KEEP TRACK OF THE "CONTEXT" for this specific terminal.

9. JPIP (4)  WADO allows also to retrieve the DICOM images and to choose the transfer syntax.  So it is possible to do it for a WADO+JPIP:  Retrieve the image in DICOM (contentType=application%2Fdicom&transferSynt ax=1.2.840.10008.1.2.4.94 or 95).  Open the JPIP session on the basis of information read in the "image" containing the JPIP URL in place of pixels.  So it is possible to do WADO+JPIP without any WADO specs evolution  WADO allows also to retrieve the DICOM images and to choose the transfer syntax.  So it is possible to do it for a WADO+JPIP:  Retrieve the image in DICOM (contentType=application%2Fdicom&transferSynt ax=1.2.840.10008.1.2.4.94 or 95).  Open the JPIP session on the basis of information read in the "image" containing the JPIP URL in place of pixels.  So it is possible to do WADO+JPIP without any WADO specs evolution

10. Recommendation  The DICOM and ISO joint group can publish an "implementation guide" on the subject but there is not clear reason to revisit the ISO 17432 standard, yet.  Add the multipart option now can be quite controversial and put “trouble” in WADO which is more and more adopted by vendors.  At the opposite, a WADO evolution could be considered next year or in 2 or 3 years  implementing the web services  including the frequently requested function for whole series or study retrieval.  The DICOM and ISO joint group can publish an "implementation guide" on the subject but there is not clear reason to revisit the ISO 17432 standard, yet.  Add the multipart option now can be quite controversial and put “trouble” in WADO which is more and more adopted by vendors.  At the opposite, a WADO evolution could be considered next year or in 2 or 3 years  implementing the web services  including the frequently requested function for whole series or study retrieval.