Evolution of WADO towards Web Services - Dicom

squabbletownmushyΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

236 εμφανίσεις


1

Evolution of WADO towards Web Services

Missions of DICOM

-

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
Type

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


Present limitation of WADO

-

One SOP Instance (no way for retrieving all the images of a series/study in one call)

-

Suited for Web Browser bas
ed solution, less for direct communication to DICOM
server

-

The URL based query is easy to write, but not adapted for being parsed

-

No easy way to help the application development through WSDL mechanism

Web Services… why
should we add
?

-

Performance, cost, co
mpatibility, new capabilities,

development schedule, customer
integration

-

WS enable to integrate with many of the shelf products (e.g. dashboard, switchboard)

-

Developers familiar with WS are more available the developers familiar with DICOM

-

IT managers are

mo
re familiar with WS than DICOM

o

long term development

o

Internet configuration is more familiar (routers, firewalls…)

-

Because DICOM is service based, it would be logical to define WS for DICOM
communication

-

New technologies we want to integrate with are of
ten based on WS

Web Services…
can we add now
?

-

The WS are now in the “maturing process”

-

The deployment beyond web server to web server is emerging (appli. to appli.)

-

The WS, which are mature in other industries, are now emerging in Healthcare,
especially to

integrate multiple applications

-

The WS
-
I Profiles are defining a real interoperable solution, including (more or less!)
the security and reliability aspects

-

There are emerging mechanisms for conveying

binary con
tent (MTOM
/XOP
, Fast
Infoset)
now supported
by
multiple
development platforms (.Net, Java…)

Web Services for Dummies

-

When 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


2

-

WS are using such me
chanism 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)

MTOM
/XOP

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_Bounda
ry

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/200
4/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:B
ody></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:/resou
rce1.jpeg>

Content
-
Type: image/jpeg

Content
-
Transfer
-
Encoding: binary


ÿØÿà_JFIF____ÿÛ (IMAGE 2 in BINARY)

--
MIME_Boundary
--

WADO in WS, which form?

-

IHE ITI defined a White Paper on WS implementation of profile, based on WS
-
I

-

The
IHE ITI
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

Draft of the WSDL for WADO RetrieveDicomObject

Service

<w
sdl:service name="WS
-
WADO_Service">


<wsdl:port name="WS
-
WADO_Port" binding="tns:WS
-
WADO_Binding">


3



<soap:address location="http://localhost/WebServicesExample.php"/>


</wsdl:port>

</wsdl:service>

Binding

<wsdl:binding name="WS
-
WADO_Binding" type="tns:WS
-
WADO_PortType">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>


<wsdl:operation name="RetrieveDicomObject">



<soap:operation soapAction="urn:dicom:ws
-
wado:2007:RetrieveDicomObject"/>



<wsdl:input><soap:body use="literal
"/></wsdl:input>



<wsdl:output><soap:body use="literal"/></wsdl:output>


</wsdl:operation>

</wsdl:binding>

Ports

<portType name="WS
-
WADO_PortType">


<wsdl:operation name="RetrieveDicomObject">



<wsdl:documentation>Retrieve an objectContent from a PACS
se
rver</wsdl:documentation>



<wsdl:input message="tns:RetrieveDicomObjectRequest_Message"/>



<wsdl:output message="tns:RetrieveDicomObjectResponse_Message"/>


</wsdl:operation>

</portType>

Messages

<wsdl:message name="RetrieveDicomObjectRequest_Message">


<wsdl:part name="body" element="tns:RetrieveDicomObjectRequest"/>

</wsdl:message>

<wsdl:message name="RetrieveDicomObjectResponse_Message">


<wsdl:part name="body" element="tns:RetrieveDicomObjectResponse"/>

</wsdl:message>

Request

<xsd:element name="Retri
eveDicomObjectRequest">


<xsd:complexType>



<xsd:sequence>




<xsd:element name="requestType" type="xsd:string"/>




<xsd:element name="studyUID" type="xsd:string"/>


<xsd:element name="seriesUID" type="xsd:string" minOccurs="0"/>



<xsd:eleme
nt name="objectUID" type="xsd:string" minOccurs="0"/>



<xsd:element name="contentType" type="xsd:string" minOccurs="0"/>



<xsd:element name="charset" type="xsd:string" minOccurs="0"/>



<xsd:element name="anonymize" type="xsd:string" minOccurs="0"/>




<!
--

… + ALL WADO ATTRIBUTES
--
>



</xsd:sequence>


</xsd:complexType>

</xsd:element>

Response

<xsd:element name="RetrieveDicomObjectResponse">



<xsd:complexType>




<xsd:sequence>




<xsd:element name="objectContent" type="tns:objectContent"
minO
ccurs="0" maxOccurs="unbounded"/>



</xsd:sequence>


</xsd:complexType>

</xsd:element>


4

Object

<xsd:complexType name="objectContent">


<xsd:sequence>



<xsd:element name="studyUID" type="xsd:string"/>



<xsd:element name="seriesUID" type="xsd:string"/>



<x
sd:element name="objectUID" type="xsd:string"/>



<xsd:element name="sopClassUID" type="xsd:string" minOccurs="0"/>



<xsd:element name="contentType" type="xsd:string" minOccurs="0"/>



<xsd:element name="data" type="xsd:base64Binary" minOccurs="0"/>


</xs
d:sequence>

</xsd:complexType>

Other Operations

Introduction

Additionally

to the Retrieve Dicom Object operation, two additional transactions might be
defined in order to enable a “non DICOM protocol enabled” application to communicate with a
DICOM equipme
nt:

-

Notification of the availability of DICOM Object(s)

-

Query
based on ID(s)
for DICOM Objects (and not only
based on
UIDs)

Notification of Availability
of
DICOM Object(s)
(NADO)

WADO is supposing the Application retrieving the DICOM Object(s) is aware of
it/their
existence and availability. But no mechanism has been provided for
informing the application
that such DICOM Instance(s) are available.

Similarly to the DICOM IAN (Instance Availability Notification), a WS based transaction may
be defined for noti
fying the availability of DICOM Object(s). It addresses similar use cases than
some targeted by the ISO TC215/WG2 “WARM” work item and it may correspond to an
evolution of this one.

The mechanism may imply a “subscription” by an application to be notified
at different levels
(study/series/instance) and the notification message may include, in addition to UIDS, at least the
Patient Id, the Accession Number and the Modality.

The Application may be implementing a WS server (so the DICOM system will act as a cl
ient to
notify it) or as a WS client (so it has to query regularly or use the asynchronous mode of WS).

Query based on ID for DICOM Object(s) (QIDO)

Similarly to the IHE ITI Retrieve Document for Display (RID) transaction, the Application can
query the DIC
OM server to have a list of available DICOM objects. Parameters may be similar to
those used for RID (Patient ID, date(s) and number of most recent) with the Accession Number
(in addition to the Patient ID required for security reasons). The Application wi
ll act as a WS
client, while the DICOM Server will act as a WS server.