DICOMwebTM 2015 Conference &
Hands-on Workshop
University of Pennsylvania, Philadelphia, PA
September 10-11, 2015
b<>com Rest DICOM Library
A portable DICOMweb™ toolkit
Amandine Le Maitre, Guillaume Pasquier, Eric Poiseau, Abdelghani Tassi,
Guillaume Gauvrit, Emmanuel Cordonnier, Yannick Morvan
Motivations
Increasingly, medical specialties incorporate
images for diagnostic and treatment
•
Image usage becomes distributed: enterprise
wide or even cross-enterprise
•
Software challenges of conventional DICOM
standard and PACS’s
(copyright Carestream Health)
•
Dedicated fixed radiology workstation
•
•
•
•
•
(copyright Carestream Health)
High complexity of the communication protocol
Low performances for specific dataset
Not adapted to web applications
Interrupted transfer of large objects (multiframe,
enhanced IOD, WSI, MPEG) cannot be resumed
• Difficult to deploy cross-enterprise
DICOMweb™ addresses a number of these
issues
Mobile imaging application
•
Next steps for DICOM is DICOMweb™
2
Part B
b<>com Rest DICOM Library
Server Module
3
Overview of our DICOMweb™ Server
• Goal: implement a gateway
providing DICOMweb™
interfaces to any PACS
• Universal: simple integration
into existing PACS
RESTful
DICOMweb
WADO, QIDO, STOW
DICOM
C-Store, C-Find, …
Rest DICOM Library
Gateway/DICOMweb-izer
• Lightweight: <3 MB
• Standalone: all included and
easy to deploy
• Working towards the
conformance to DICOMweb™
DB
proprietary
DICOM
C-Store
C-Find
PACS
4
Architecture of our DICOMweb™ Server
• Delivered as an Apache 2 module (tested version 2.2 and 2.4)
• Dependencies: DCMTK and POCO (all included)
• Tested on Centos 6.x, Debian 9/Stretch and Ubuntu 14.04
5
DICOMweb™ Server Backend
• DICOMweb™ requests can be converted either SQL, ODBC or DICOM
connections
RESTful DICOMweb WADO, QIDO, STOW
Rest DICOM Library
SQL proprietary
(preliminary tests on
Dcm4Chee)
ODBC proprietary
(tested on ETIAM®
Nexus™)
DICOM
C-Store
C-Find
6
Part C
b<>com Rest DICOM Library
Client Module
7
Overview of b<>com REST DICOM Client
• Goal: implement a toolkit that
enables the communication to a
DICOMweb™ server from a web
browser
• Zero-footprint: implemented in
JavaScript
• Working towards the
conformance to DICOMweb™
• AJAX-based
• Include goodies:
• Can parse DICOM objects in
the browser (JavaScript)
• Can create new DICOM
objects (e.g. KOS) in the
browser (JavaScript)
8
b<>com Rest DICOM Library in Action
DICOMweb™ QIDO-RS client - 1/3
• Build QIDO requests at all
levels (studies, series,
instances)
• JSON parsing of QIDO
response
• Simple integration of the
QIDO-RS response for
WADO-RS
9
b<>com Rest DICOM Library in Action
DICOMweb WADO-RS client - 2/3
• Get the series using
WADO-RS
• Parsing of the multipart
WADO-RS HTTP
response
• Wish list (1): WADO
rendering
• Wish list (2):
Cornerstone integration
10
b<>com Rest DICOM Library in Action
STOW-RS client - 3/3
• DICOM object parsing in
JavaScript
• Upload studies using a
STOW request
• JPEG-LS transfer syntax
conversion in JavaScript
(work in progress)
• KOS creation as first
object in the multipart of
STOW
• Goodie: we can resume an
interrupted STOW-RS
(requires a slight
modification of STOW-RS)
11
b<>com Rest DICOM Library
Grammar-Based Request Parsing
12
Grammar-Based Requests Parsing
• Take advantage of the supplement
183, “re-documentation” by Jim
Philbin
• Idea followed is to employ the
grammar definition to verify and
parse incoming DICOMweb™
requests (grammar-based parsing)
• Parsing includes
a) Syntax analysis (e.g. a typo
“study" instead of "studies“ in
the URI).
b) Semantic analysis age of the
patient is not formatted as an
AgeString VR.
• Why not integrating that validator
into IHE gazelle EVS client?
13
Grammar-Based Requests Parsing
Server Side
• Within the server, verify the
conformance of the incoming
messages
• Simplify the analysis of the
incoming request
• Extracted request parameters can
be forwarded to build an SQL or CSTORE query
14
Conclusions
• b<>com Rest DICOM Library includes a portable server and a zerofootprint JavaScript client module
• The toolkit provides a subset of the DICOMweb™ interfaces (part of
STOW-RS, QIDO-RS and WADO-RS)
• The server is employed as a gateway to a standard PACS
• The JavaScript client provides
• STOW-RS upload (JPEG-LS compression, DICOM de-identification
and resumable upload)
• Regular WADO-RS and QIDO-RS
• Software verification and validation following ISO 13485 guidelines
• Preliminary field tests performed with our partner (ETIAM)
• Future work: DICOM conformance statement, compatibility verification
(Windows, Mac OS X)
15
Author Contacts
Yannick Morvan
Connected Healthcare Lab Manager
[email protected]
b<>com Institute of Research and Technology
16