dcm4che Architecture and Implementationforums.dcm4che.org/jiveforums/servlet/JiveServlet/download/5-4757...dcm4che Architecture and Implementation ... Computer Science Dr. Ralph Johnson

dcm4che Architecture and Implementation

Jason Danielson Eric Garland Andrew Holder Alejandro “aRod” Rodriguez

University of Illinois Computer Science Dr. Ralph Johnson

CS 527

Danielson, Garland, Holder, Rodriguez 2 of 39

Table of Contents

1. Abstract................................................................................................. 3

2. Key Definitions..................................................................................... 3

3. Introduction........................................................................................... 4

3.1 IHE Profile Example........................................................................................... 4

4. dcm4che................................................................................................ 5

4.1 dcm4che & IHE Profiles..................................................................................... 8

4.2 Interoperability.................................................................................................... 8

4.3 Efficiency.......................................................................................................... 10

4.4 Security ............................................................................................................. 11

4.5 Portability.......................................................................................................... 11

5. dcm4che Architecture ..........................................................................12

5.1 Allocation View Type....................................................................................... 14

5.1.1 Deployment Style...................................................................................... 15

5.1.2 Implementation Style ................................................................................ 15

5.2 Module View Type ........................................................................................... 22

5.2.1 Archive...................................................................................................... 22

5.2.2 Toolkit....................................................................................................... 24

5.3 Component and Connection.............................................................................. 26

5.3.1 Network Protocols .................................................................................... 26

5.3.2 Message Types and Contents.................................................................... 26

6. Project Patterns ....................................................................................31

6.1 Dcm4che2 Patterns ........................................................................................... 31

6.2 Dcm4chee Patterns............................................................................................ 34

7. Using Parallelism with dcm4che ..........................................................34

7.1 Extensions......................................................................................................... 35

7.2 Experiment........................................................................................................ 35

7.2.1 Setup ......................................................................................................... 35

7.2.2 Program Details ........................................................................................ 36

7.2.3 Findings..................................................................................................... 36

7.3 Conclusion ........................................................................................................ 38

8. Bibliography ........................................................................................39

1.


1. Abstract

To help manage communication between different medical imaging devices, standards

have been created for the medical field. Since the creation of these standards, different

toolkits have been created to help programmers to be able to access and use these

standards proficiently. The dcm4che is a toolkit that can be used in this way. Our

document explores the architecture found in dcm4che. To further understand the toolkit,

we have also implemented a GUI and tested it in parallel and non-parallel systems to

observe its performance.

2. Key Definitions

Term Definition

DICOM A standard for handling, storing, printing,

and transmitting information in medical

imaging that includes file format definition

and network communications protocol. i

HL7 A standard for the exchange, integration,

sharing, and retrieval of electronic health

information. Imaging systems use this

standard to interface with their “outside”

world. ii

PACS “Picture Archiving and Communications

Systems” (PACS) are computer systems

that store, retrieve, distribute, and present

medical images. These medical images are

usually stored in the DICOM standard

format. iii

RIS Radiology Information Systems (RIS) is a

“computerized database used by radiology

departments to store, manipulate and

distribute patient radiological data and

imagery. It generally consists of patient

tracking and scheduling, result reporting

and image tracking capabilities. RIS

complements HIS (Hospital Information

Systems) and are critical to efficient

workflow to radiology practices”. iv

HIS “Health Information Systems” (HIS) is a

system that includes Electronic Medical

Records (EMR) and functionality for

billing, scheduling, and research.v

Modality In medical imaging, any of the various


types of equipment or probes used to

acquire images of the body, such as

radiography, ultrasound and magnetic

resonance imagingvi

3. Introduction

Information Technology (IT) in the Healthcare industry has been fragmented for many

years due to the inherent complexity involved in managing patient care at an affordable

cost. With the Obama Administration under pressure to solve the high-rising costs of

medical services in our country, Healthcare IT has recently gained nation-wide attention

for providing more efficient access and distribution of patient information. This would

translate to better quality, safety, and streamline administrative workflows that would

ultimately decrease the cost of our healthcare system.

A major reason for this fragmentation is that disparate medical systems are not able to

communicate with each other very effectively. For this reason, standards for exchanging

and managing health and imaging information were created. More notably, the Digital

Imaging and COMmunication (DICOM) and Health Level 7 (HL7) standards. DICOM

is a standard for handling, storing, printing, and transmitting information in medical

imaging that includes file format definition and network communications protocoli. HL7

is a standard for the exchange, integration, sharing, and retrieval of electronic health

informationii. Even with these standards, there is still a need for identifying when these

standards are applicable. So the Integrating the Healthcare Enterprise (IHE) organization

was formed to provide profiles that would describe typical clinical workflows and

describe how existing standards can be used to fulfill these workflows. vii

3.1 IHE Profile Example

The Scheduled Workflow Profile “integrates the ordering, scheduling, imaging

acquisition, storage and viewing activities associated with radiology exams”viii

. A typical

scenario as shown in Figure 1 follows:

A patient registers and schedules an appointment with a medical facility for imaging-

related health care services. This information is fed into a Health Information System

(HIS), which is a system that includes Electronic Medical Records (EMRs), and

functionality for billing, scheduling, and researchv. The HIS forwards the patient’s

information to the clinician who makes an assessment on the patient’s condition. The

clinician then places examination orders based on the patient’s assessment. These

examination orders are sent from the HIS to a Radiology Information System (RIS). RIS

is a “computerized database used by radiology departments to store, manipulate and

distribute patient radiological data and imagery”iv

. Communication within a HIS and to a

RIS follows the HL7 messaging format standardiii

.


The RIS now sends the patient ID and examination orders to a Modality via the DICOM

communication standard. In medical imaging, a Modality is any of the various types of

equipment used to acquire images of the body, such as radiography, ultrasound and

magnetic resonance imagingvi

. The Modality creates images of the patient and forwards

them, in DICOM format, to a Picture Archiving and Communications System (PACS).

A PACS is a collection of computer systems that store, retrieve, distribute, and present

medical imagesiii

. The radiologist retrieves the patient’s images from the PACS and

makes a diagnosis. The radiologist creates a Diagnosis Report and saves it on the RIS.

Finally, the Diagnosis Report is sent back to the HIS via HL7iii

.

images

stored

patient

information

RIS

examination orders

images

retrieved

HIS

PACS

procedure

scheduledPrefetch any relevant

prior studies

modality

worklist

report

report

Registration

Orders Placed

Orders Filled

Film

FilmFolder

Image Manager& Archive

Film

Lightbox

reportReport

Repository

DiagnosticWorkstation

Modality

acquisitionacquisition

inin--progressprogress

acquisition

completed

acquisition

completed

images

printed

AcquisitionModality

Imaging Scheduled Workflow

HL7HL7HL7HL7

DICOMDICOMDICOMDICOM

Figure 1: Example IHE Profileix

4. dcm4che

Dcm4che is a collection of open source applications and utilities for the healthcare

enterprise that consists of two parts: (1) Dcm4che2 toolkit, an open source

implementation of the DICOM standardx, and (2) Dcm4chee, an archive and image

manager that has the potential of being a full-blown PACS system. xi


The Image Archive acts as a DICOM Service Class Provider (SCP) and included with

the toolkit are several command utilities that act both as SCP’s and DICOM Service

Class Users (SCU). In any DICOM interaction between Application Entities, one entity

acts as the provider of a service (SCP), and the other acts as a user of the service (SCU).

However, the same software can act as a SCP and also as an SCU for different

transactions. For example, the Image Archive acts as an SCP when other entities try to

query from it or push images to it. If the Image Archive pushes an image to another SCP,

on the other hand, the Image Archive would be acting as an SCU in this case.

The dcm4che toolkit provides almost all of the foundation required for an application that

would act as a software entity in the world of medical imaging. For example, the

networking and DICOM image file input / output functionality provided by the toolkit

would make it easy to develop application to retrieve digital versions of X-rays, CT

scans, MR studies, Ultrasound images (and many other study types, known as modalities,

that have become standard in present day medical practice) from the actual machines that

take these images from patients. This application could then, for example, display the

images as a radiologist workstation with only some additional code around the display

and manipulation of the pixel data internal to the DICOM image files. Another

application could be easily built using dcm4che to fetch images from a storage (like the

dcm4chee archive) in the background of a viewing application (for example, exams

previously taken of the same patient know as historical patient studies). The possibilities

are nearly endless, but the dcm4che toolkit takes most of the grunt work out of handing

the DICOM image file standard around the world of medical imaging.


Mainframe

Mainframe

Workstation

Workstation

Workstationdcm4che-tool-dcmsnd

dcm4che-coredcm4che-net

dcm4che-imageio dcm4che-image

dcm4chee

Data

dcm4che-tool-dcmqr



dcm4che-tool-dcmecho

dcm4che-net

dcm4che-core

dcm4che-tool-rcv



DIC

OM

C-F

ind

DIC

OM

C-M

ove

DIC

OM

C-F

ind

DIC

OM

C-M

ove

DICOM C-Store

DICOM C-Echo

DIC

OM

C-E

ch

o

DIC

OM

C-E

ch

o

DIC

OM

C-E

ch

o

TCP/IP DICOM Upper Layer Protocol

DIC

OM

C-S

tore

Figure 2: Diagram depicting command line utilities of dcm4che2 interact with each other and with

the archive SCP


4.1 dcm4che & IHE Profiles

In general, Dcm4chee provides a variety of services that support the workflow

requirements of an imaging environment as described in the IHE profiles. Dcm4chee

implements the “Image Manager/Archive” and “Performed Procedure Step Manager”

actors of Figure 3.xi

Figure 3: Actors & transactions involved in the “Scheduled Workflow” profile. viii

4.2 Interoperability

There are several existing systems that implement the DICOM & HL7 standards to meet

some level of interoperability, but this does not mean that they can communicate with

each other. These systems create their own, unique implementation of the DICOM &

HL7 standards and, hence, are not compatible with each other. DICOM & HL7 are very


general to provide greater flexibility, but it has also led to the creation of systems that

cannot communicate with each other. For this reason, IHE profiles were created to

describe how the DICOM & HL7 standards should be used in systems that facilitate

clinical workflows. Therefore, systems that implement IHE profiles provide a higher

level of interoperability than standards.

The Dcmchee archive meets the minimum requirements for interoperability in an

imaging environment by supporting DICOM & HL7 services and interfaces. It contains a

DICOM Server that sends incoming service requests (from Modalities for example) to

registered DICOM services

(http://www.dcm4che.org/confluence/display/ee2/DICOM+Server). Some notable

DICOM services that it supports are:

1. Storage Commitment – This service is used to “confirm that an image has been

permanently stored by a device (either on redundant disks or on backup media,

e.g. burnt to a CD). The Service Class User (SCU – similar to a client), a modality

or workstation, etc., uses the confirmation from the Service Class Provider (SCP -

similar to a server), an archive station for instance, to make sure that it is safe to

delete the images locally

(http://en.wikipedia.org/wiki/Digital_Imaging_and_Communications_in_Medicin

e)”.

2. Modality Worklist (MWL) – A service that can provide Patient Demographics

and Study Details when queried by modalities

(http://www.medicalconnections.co.uk/wiki/How_Modality_Worklist_works).

3. Modality Performed Procedure Step (MPPS) - A service that accepts information

from modalities about the imaging they are performing

(http://www.medicalconnections.co.uk/wiki/MPPS).

By following the DICOM standard, several DICOM image viewers can work with the

archive such as OsirixX (Objective-C), K-PACS (Microsoft Visual Studio language),

ImageJ (Java), and many more.

HL7 services that it provides are:

1. ADT HL7 Service - Receives and processes incoming ADT messages. ADT,

which stands for Admit Transfer Discharge, are messages containing patient

demographic information (http://www.corepointhealth.com/resource-center/hl7-

resources/hl7-adt).

2. ORM HL7 Service – “Creates, updates, deletes entries of the Modality Worklist

provided by the MWP SCP service according to received ORM messages”

(http://www.dcm4che.org/confluence/display/ee2/ORM+Service). ORM’s, which

stand for Order Messages, are used to transmit information about an order such as

new orders, cancellations, information updates, discontinuation, etc.”

(http://www.corepointhealth.com/resource-center/hl7-resources/hl7-orm-

message).


3. ORU HL7 Service - Converts ORU messages into structured reports so that a

viewer can simply access the report from a PACS

(http://www.dcm4che.org/confluence/display/ee2/ORU+Service). ORU, which

stands for Observation Result, messages are used to transmit result data from

producing systems to medical record archival systems

(http://www.corepointhealth.com/resource-center/hl7-resources/hl7-oru-message).

Finally, the archive takes the next step of interoperability by assuming the role of several

actors in IHE profiles such as Patient Administration Management, Patient Information

Reconciliation, Performed Procedure Step Manager, and many more listed at

http://www.dcm4che.org/confluence/display/ee2/IHE+Integration+Statement.

One of the main interoperable highlights of the archive is its impersonation of the

Repository actor of the XDS/XDS-I profile. XDS/XDS-I profiles stand for Cross-

enterprise Document Sharing and Cross-enterprise Document Sharing for Imaging

respectively. These profiles provide a standards-based specification for managing the

sharing of documents between any healthcare enterprise. It consists of a Document

Repository (which the archive assumes the role of), Document Registry, Document

Sources, and Document Consumers

(http://wiki.ihe.net/index.php?title=Cross_Enterprise_Document_Sharing).

4.34.34.34.3 Efficiency Efficiency is not the primary focus of dcm4che. Much more thought and energy has gone

into some of the other software qualities, like interoperability. For example, because

dcm4che is written in Java, there is some efficiency lost from being run in a non-native,

managed environment.

As we showed with our Parallelism experiments, there is room for improvement in

exploiting concurrency for rapid file transfers. However, there is not really all that much

room for efficiency in dcm4che in general. It is a barebones kit for inputting, outputting

and transferring files in a standard format. Although the dcm4chee archive does have a

means to view the pixel data associated with an image, it is simply loading the pixel data

from a file, usually in a lossless jpg or bitmap format, in a web browser and does not

really have to worry about rapidly doing any sort of computational intense work.

Because the TCP/IP, DICOM, and JPG formats are all standardized and pretty mature at

that, there is not really a need to seek out efficiency improvements in the use of these

standardized transfer protocols to transfer these standardized file formats. There would,

however, be a much greater room and need for efficiency optimization in the Radiologist

workstation applications. The pixel data from many exams can be opened at once,

multiple slice studies can be animated to scroll through the various layers of a human

body automatically, pixel data can be manipulated and annotated, etc. etc.


As you can see in Vazquez A et. elxii

, efficiency was not even an evaluated

quality attribute of the DICOM Framework comparison. There was, however, a lot more

weight placed on Maintainability, Extendibility and Interoperability, in all of which

dcm4che appears to be very robust.

4.4 Security

When talking about security in dcm4che, there are two modules that need to be

addressed. The first is the web server. Dcm4che has a web interface for viewing of

stored images, etc. This web interface requires that credentials be given in order to

access the site. This is handled by Jboss. The JBoss security model is declarative in that

you describe the security roles and permissions in a standard XML descriptor rather than

embedding security into your business component. This isolates security from business-

level code because security tends to be more a function of where the component is

deployed than an inherent aspect of the component's business logic. Since this is a 3rd

party library that dcm4che uses, we will not go into more detail of JBoss's security

model.

The second module that will need to be addressed is the DICOM module. In this module

there are two aspects related to security, sending images into the database, and auditing.

In order to send images using dcm4che there is certain information that needs to be

known:

• IP address of receiving server

• Port on the receiving server

• Application Entity Title (AE Title)

There are no credentials that need to go along with an image send. So if an attacker did

have all this information, they could flood the database with images. There is known

performance degradation when the number of images reaches the 100 millions. Of

course, the attacker will mostly likely not have the AE title, in which case a dictionary

type attack can be used to figure it out. In this implementation, there is no security

measures in place that will block an IP address that constantly gives an invalid AE title.

Along with images sending comes the second aspect of DICOM when it comes to

security, the audit record repository, ARR. The DICOM standard does not have any sort

of security built into it, so most implementations add an ARR and dcm4chee is no

different. Whenever an image is added, removed, or modified, an event is recorded in the

ARR detailing where the command came from and which image has been affected. The

only thing preventing someone modifying the system maliciously is the fact that it is

monitored in this manner.

4.5 Portability

The dcm4che was created with portability in mindxiii

. This can be seen in the different

tools that dcm4che is built on. The dcm4che project is written in Java, a program

language known for its mantra of “Write Once, Run Anywhere”. By using Java you can


ensure that you will be able to run the code on any machine that can run the Java Virtual

Machine.

Another sign of dcm4che’s portability are the prepackaged JAR files. These files are

small code libraries that allow a programmer to import dcm4che functionality without

having to import or write each individual class and method. In our dcm4che parallelism

example we did not have to write or modify any of the dcm4che code, all that was needed

was the importation of the JAR files. Because of this the dcm4che functionality can be

easily used on any machine that runs Java.

Another important aspect of dcm4che’s portability is the fact that it is build on Open

Source Software. Open Source refers to software that can be used and modified freely

without any (or very little) restrictions. Since dcm4che is considered Open Source you

can download the tools and use them however you want without having to pay any fees

or sign any contracts.

When working with a complex toolkit or system there is usually some underlying 3rd

party software that is used to perform different tasks. For the dcm4che this includes

JBOSS and MySQL. Both of these systems are also Open Source Software. Since all the

supporting tools for dcm4che are Open Source the cost of deploying the toolkit and

archive is nothing. Also by using Open Source users of dcm4che can modify any part of

the code and supporting libraries to meet any extra needs that they might have.

The one problem with dcm4che and portability is its reliance on JBOSS. JBOSS is

integrated throughout the entire project. Because of this JBOSS must be installed.

Fortunately since JBOSS is Open Source Software downloading and using JBOSS costs

nothing (as mentioned above).

5. dcm4che Architecture

Dcm4chee follows a Service-Oriented Architecture (SOA) in that it has a modular design

for the support of services such as:

1. Web-based User Interface

2. DICOM Interfaces

3. HL7 Interfaces (Health Level 7- healthcare messaging protocol)

4. WADO Interfaces (Web Access to a DICOM Object)

5. Audit Record Repository (ARR)

6. Media Creation

7. XDS/XDS-I (Image document sharing protocol) xiv


Figure 4: dcm4chee Archive Server Components

The archive also follows a typical 3-tier architecture that includes the Presentation,

Business Logic, and Database tiers.


Presentation Tier

WADO (Client)WEB

Business Logic Tier

SARHL7XDS

Database Layer

EJB

3 Tier Model

WADO

(Server)

DICOM Library

CDW

ARR

Figure 5: dcm4che Archive 3-tier Architecture

5.1 Allocation View Type

A useful way to understand how Dcm4che is used in a hospital’s enterprise is to visually

see where the different software components are allocated within physical entities. The


Deployment Style captures the physical “boxes” where the Dcm4che2 toolkit and

Dcm4chee archive are deployed. It is also useful to understand how the source code is

organized in a version control system. The Implementation Style diagrams show this by

illustrating the code’s directory structure and their dependencies.

5.1.1 Deployment Style

As with many systems in industry, the physical deployment architecture follows a client-

server model. The Dcm4chee archive acts as a server while application tools that make

use of the Dcm4che2 toolkit act as clients, alongside DICOM Viewers and Modalities.

Dcm4chee archive is deployed within the JBOSS application server, and can work with

various relational databases such as MySQL, Oracle, MSSQL, and many more. Images

stored in the archive can be either online or just offline. Online storage (e.g RAID array)

is persistent storage for images that are readily available when requested on-demand by

clients. Offline storage (e.g. tape libraries or DVD jukeboxes) is persistent storage that

requires image retrieval into online storage in order to be used by clients.

Server

Client

Client

Client

JBOSS

<<Application Server>>

DCM4CHEE

<<DICOM Clinical Data Manager System>>

DCM4CHE

<<DICOM Toolkit>>

Client

OsiriX

<<DICOM Viewer>>

ClearCanvas

<<DICOM Viewer>>

Server

RDBMS

<<Database>>

PostgreSQL 8.1+

MySQL 4.1+

SQL Server 2000+

Oracle 9i+

DB2 8.1+

Firebird 2.1+

Hypersonic SQL

Storage Device<<Online Storage>>

Storage Device<<Offline Storage>>

Web Browser

<<DICOM Viewer>>

CT Scanner MRI Mammogram

MODALITIES

Figure 6: dcm4che Modality Diagram

5.1.2 Implementation Style


This style shows how the source, build, resource, and other files are organized in a

directory structure. Though this section is intended to be more of a reference, it can “be

used to highlight those elements that are used for special purposes, such as testing, or to

analyze the configuration management for a system”xv

. The orange packages are folder

directories, the purple components are jar libraries, the blue components are build files,

and the rest identify other types of files.

dcm 4 che -

audit

«file» pom . xml «library»

dcm 4 che - core . jar src / main / java src / test /

java «library» log 4 j . jar

log 4 j

helpers net «file» AuditMessageFilter . java

message util

org . dcm 4 che 2 . audit . message org . dcm 4 che 2 . audit

Figure 7: dcm4che-audit

D c m 4 c h e -C o r e

s r c /m a in /j a v a

s r c /te s t /ja v a

s r c /m a in /r e s o u r c e s

s r c /te s t /r e s o u r c e s

« fi le »p o m .x m l

s lf 4 j -a p i. ja r

d a ta io m e d ia u t i l d a ta io u t i l

M E T A - IN F /d c m 4 c h e

o r g /d c m 4 c h e 2 /

d a ta u t il

o r g .d c m 4 c h e 2

o r g .d c m 4 c h e

Figure 8: dcm4che-core


d c m 4 c h e -h p

s r c /m a in /ja v a

s r c / te s t /ja v a

s r c / t e s t /r e s o u r c e s

« f ile »

p o m .x m l

« l ib ra ry »

d c m 4 c h e -c o re . ja r

p lu g in s s p i

o r g .d c m 4 c h

e 2 .h pN e u r o s u r g e ry P la n .x m lN e u ro s u rg e r y P la n .d c m o r g .d c m 4 c h e 2 .

h p

Figure 9: dcm4che-hp

d c m 4 c h e -

im a g e

s r c /m a in /ja v a « f i le »

p o m .x m l« l ib r a r y »s lf4 j- a p i

« l ib ra ry »d c m 4 c h e - c o r e . ja r

o r g .d c m 4 c h

e 2 . im a g e

Figure 10: dcm4che-image

d c m 4 c h e -

im a g e io

s r c /m a in /

ja v a

s r c /m a in /

r e s o u r c e s

s r c / te s t /

ja v as r c /te s t /

r e s o u r c e s

« lib ra ry »

d c m 4 c h e -c o re .ja r : ja r

« l ib ra ry »

d c m 4 c h e -im a g e . ja r : ja r

« l ib ra ry »

s lf4 j - a p i. ja r : ja r

« l ib ra ry »

ja i_ im a g e io . ja r : ja r

« fi le »

p o m .x m l : P ro je c t O b je c t M o d e l

im a g e io

p lu g in s .d c m p lu g in s .d c m

o r g .d c m 4 c h

e 2 . im a g e io i

m p l .p lu g in s

.d c mM E T A - IN F /

s e r v ic e s

o r g /

d c m 4 c h e 2 /

im a g e io

« f ile »

lo g 4 j .p ro p e r t ie s : P ro p e rt ie s

ja v a x . im a g e io .s p i. Im a g e R e a d e rS p ija v a x . im a g e io .s p i. Im a g e W r ite rS p i

« f ile »

Im a g e R e a d e rF a c to ry .p ro p e r t ie s : P ro p e r t ie s

« f i le »

Im a g e W r ite rF a c to ry .p ro p e r tie s : P ro p e r t ie s

o r g .d c m 4 c h e 2

im a g e io im p l

Figure 11: dmc4che-imageio


d c m 4 c h e -im a g e io - r le


s r c /m a in /r e s o u r c e s /M E T A - IN F /

s e r v ic e s

« l ib r a ry »s lf4 j-a p i. ja r : ja r

« f i le »p o m .x m l : P ro je c t O b je c t M o d e l

ja v a x . im a g e io .s p i. Im a g e R e a d e rS p i o r g .d c m 4 c h e 2 . im a g e io im p l .p lu g in s .r le

Figure 12: dcm4che-imageio-rle

d c m 4 c h e -io d

s rc /m a in /ja v a

« l ib ra r y »d c m 4 c h e -c o re . ja r : ja r

« f i le »p o m .x m l : P ro je c t O b je c t M o d e l

c o m p o s item o d u lev a l id a t io nv a lu e

c o m p o s it e c rd xg e n e r a l lu tm a c r oo v e r la yp r s p a t i a l s r

o rg .d c m 4 c h e 2 . io d

Figure 13: dcm4che-iod


d c m 4 c h e -n e t


o r g .d c m 4 c h e 2 .n e t

p d u

« l ib ra ry »d c m 4 c h e - c o r e . ja r : ja r

« l ib ra ry »s lf4 j- a p i . ja r : ja r

« f i le »p o m .x m l : P r o je c t O b je c t M o d e l

s e r v ic e

Figure 14: dcm4che-net

d c m 4 jb o s s - e jb

s rc / ja v at e s t/ ja v as rc /r e s o u r c e s b u i ld .p ro p e r t ie s .d e fa u lt b u ild .x m l

o r g .d c m 4 c h e x .a rc h iv e

c o m m o n e jbe x c e p t io n s t o o ls u t i l

c o n f e n t i t y in t e r fa c e jd b cs e s s io n

o r g .d c m 4 c h e x .a rc h iv e .e jb

e n t i t y jd b c s e s s io n

o r g .d c m 4 c h e x .a rc h iv e . t o o ls« f i le »

lo g 4 j.p r o p e r t ie s : P ro p e r t ie s

Figure 15: dcm4jboss-ejb


d c m 4 jb o s s -h l7

s r c / ja v a

o r g .d c m 4 c h e x .a r c h iv e .h l7

b u ild .p ro p e r t ie s .d e fa u lt b u i ld . x m l« l ib ra r y »

x h l7 . ja r : ja r

Figure 16: dmc4jboss-hl7

d c m 4 jb o s s - r id

s r c / ja v a

o r g .d c m 4 c h e x .r id

b u i ld .p ro p e r t ie s .d e fa u l t b u ild .x m l

te s t . tx tc o m m o nm b e a nw e b

e c g x m l

x m l

Figure 17: dcm4jboss-rid


d c m 4 jb o s s -s a r

s rc /j a v a

o rg .d c m 4 c h e x .a rc h iv e

b u i ld .p ro p e r t ie s . d e fa u l t b u i ld .x m l d c m 4 c h e e - lo c a l . la u n c h« l ib ra ry »

c o m m o n s .c o m p re s s . ja r : ja r« l ib ra ry »

d c m 4 c h e -a u d it . ja r : ja r« l ib ra ry »

s a a j- a p i . ja r : ja r

d c mc o d e cc o d e c e m f h s mm a w fm b e a n n o t i fp e r fs e c u r ity tc eu t i l x d s i

g p w ls c u h p s c p ia n s c p ia n s c u m c m s c u m o v e s c u m p p s s c p m p p s s c u m w ls c p m w ls c uq r s c ps tg c m ts to re s c p s ty m g t

Figure 18: dcm4jboss-sar

d c m 4 jb o s s - w a d o

s r c / ja v a

o r g .d c m 4 c h e x .w a d o

b u ild .p ro p e r t ie s .d e fa u lt b u ild .x m l

c o m m o nm b e a nw e b

c a c h e x m l

Figure 19: dcm4jboss-wado


d c m 4 jb o s s - w e b

s r c / ja v a

o rg .d c m 4 c h e x .a rc h iv e .w e b

b u i ld .p ro p e r t ie s .d e fa u l t b u ild . x m l

c o n f m a v e r ic k

a d m in a ea r rg p p p s g p w l m c m c m o d e lm p p sm w l p e r m is s io n s h u n tt ft r a s h u t il x d s i

p e rmm o d e l m o d e l

m o d e lm o d e lm o d e l

« lib ra ry »

c o m m o n s -b e a n u t i ls .j a r : ja r

« li b ra ry »

m a v e r ic k .ja r : ja r

« lib ra ry »

jd o m . ja r : ja r

Figure 20: dcm4jboss-web

5.2 Module View Type

The following diagrams depict the different dependencies the dcm4che packages

have. It is important to note that the Library package is depended on by all other

packages for both the toolkit and the archive.

5.2.1 Archive


Figure 21: Dependencies between modules in the archive. Everything is dependent on the DICOM

library, which is included in the toolkit

Descriptions of the modules in the archive

• arr – The audit record repository uses the IHE ATNA (Audit Trail and Node Authentication) integration profile for audit logging. The ARR contributes to

access control by limiting network access between nodes and authorized users.

The ARR module is only dependent on the DICOM library, which is included in

the toolkit.

• cdw – CD Export manager creates ISO images of DICOM files for use with

another (external) CD/DVD creation tool. It uses the DICOM Storage and Media

Creation Management system to start the media creation process. These services

create media containing a set of composite SOP instances that are already been

transferred to the media creation device use the storage service class

• ejb – contains the DAO (Data Access Object). The ejb encapsulates any data

access to the database. This improves efficiency and performance of data layer

accesses.


• hl7 – an integrated HL7 server for processing ADT, ORM, and ORU message

types. It can also be sued to forward HL7 messages to other receivers

with/without modification. The translations of HL7 messages are done with XSL

transforms. This allows for changing the way the HL7 messages are handled in

order to work with many different RIS systems without modifying source code.

• sar – the sar module contains all of the DICOM specific MBean services. It also

contains common MBean services that are found in the archive.

• wado – The implementation for the DICOM Web Access to DICOM Persistent

Objects. This service provides a simple mechanism for accessing a DICOM

persistent object (image, medical reports, etc) from HTML or XML using

HTTP/HTTPS

• web – the web interface for archive administration. The application framework is

built using Maverick (a MVC framework for web publishing in Java) and XSL

transformations as a view. Using XSLT allows for the user interface to be

customized without modifying source code.

• xds – the XDS module contains the IHE XDS repository implementation. The

XDS repository manages the sharing of documents between healthcare

enterprises. These can range from a private physiscan’s office to a personal

health records system.

5.2.2 Toolkit


Figure 22: The dependencies between each module as well as 3rd party libraries. The toolkit consists

of eight modules. This diagram omits the tools that exist in the toolkit and just focuses on the core

libraries that the tools use.

Descriptions of the modules in the toolkit

• audit – generates XML messages that are formatted to the ATNA integration

profile standard.

• core – contains the DICOM library & DICOM tools

• imageio-rle – used for decoding images that use run length encoding. Extends the

java ImageReader class

• hp – implements the DICOM Hanging Protocol

• image – Used to get information from image files. These include window level,

overlay information, etc

• iod – used to model DICOMs Information Object Definition which represents

parts of several entities included in the DICOM Model.

• net – contains classes used for sending and receiving messages over the TCP/IP

DICOM Uper layer protocol

• imageio – Used for reading and writing image data


5.3 Component and Connection

5.3.1 Network Protocols

The following diagram depicts the type of connection used by the server components for

the archive. Note that every component uses TCP except for the auditing communication,

which uses UDP.

Figure 23: Audit Record Repository is the only component that uses UDP. All others use TCP

5.3.2 Message Types and Contents

The following diagram shows the protocol and syntax used to communicate with each

component. Obviously the HL7 components use HL7 and the DICOM components use

DICOM. The other components use a variety of methods to communicate data across.


Dcm4chee Server

DICOM Server

Outbound DICOM

Client

Modalities

PACS

Workstations

DICOM

Figure 24: Components that use the DICOM next to the basic DICOM headerxvi

DICOM

The DICOM object is the typical object used within the dcm4che. It is composed of a

structured header to help different medical devices share images. Details about the

DICOM format are beyond the scope of this project so will not be mentioned here. More

information can be found at http://medical.nema.org/


Dcm4chee Server

Client

HL7

HIS

RISCVIS

eMPI

PIX

HL7 ServerOutbound

HL7

Figure 25: Components using the HL7 format

next to a HL7 v2.5 message header

HL7

Health Level 7 (HL7) is a non-profit organization that creates important standards used in

the health field. These standards focus more on patient data that is commonly found in an

EMR than images. Usually when people discuss HL7 they are referring to the standard

also named HL7. In the case of dcm4che this is HL7 v2.5. The details about the standard

or its organization are not in scope for this project. For more information on HL7 visit

http://www.hl7.org/


Dcm4chee Server

Client

HTML

HTTP Server

Web User

Interface

WADO

Requests

RID Requests

Figure 26: Components using HTML next to

a Screenshot of the Web User Interfacexvii

HTML

The dcm4che Archive has a web-based user interface to help access the different services

that the Archive offers.

Figure 27: Screenshot of the User Interfacexvii


Figure 28: Components that use XDS, TAR, POSIX, and SOP components and objects.

XDS

Cross Enterprise Document Sharing (XDS) is a process that performs what it name

implies. It is a standard created and maintained by IHE. More information on the process

can be found at http://www.ihe.net/ and

http://www.ihe.net/Participation/upload/iti15_ihewkshp07_implementing_xds_reg_rep_

majurski.pdf

TAR

To perform offline storage dcm4che uses TAR files. TAR’s are a common archive format

much like ZIP and WAR. The process will create an archive of files to be stored and then

send it to the other components for long term storage.

POSIX


Portable Operating System Interface [for Unix] or POSIX is a common interface used

when handling remote file system operations. These calls are used for managing remote

file systems used by the dcm4che.

SOP

Service/Object Pair (SOP) defines a specific syntax when using services. The media

creation manager uses a wide array of formats to handle communications. These syntaxes

are all specific ways a file can be represented and read for the CD Jukebox. The media

creation manager handles the following SOP syntaxes.

Image

• JPEGLossless

• JPEGLossless14

• JPEGLSLossless

• RLELossless

• JPEG2000Lossless

• ExplicitVRLittleEndian

• ImplicitVRLittleEndian

• JPEGBaseline

• JPEGExtended

• JPEGLSLossy

• JPEG2000Lossy

Video

• JPEGBaseline

• MPEG2

Waveform



Structure Report

• DeflatedExplicitVRLittleEndian



6. Project Patterns

6.1 Dcm4che2 Patterns

Since the dcm4che2 toolkit is just a library, it doesn’t necessarily have a backbone

architectural pattern. However, there are a couple of design patterns that the toolkit uses.

Dcm4che-core:

This project uses the Visitor pattern quite extensively. AbstractDicomObject and its

subclasses BasicDicomObject & FilteredDicomObject create, implement, and accept a

Visitor. ElementDictionary, ElementSerializer, VRMap, and IntHashTable<T> also

create, implement, and accept a visitor. But there are two types of Visitor interfaces.

One defined within the DicomObject interface and another defined within the

IntHashTable<T> class.


Visitors that use the IntHashTable.Visitor interface will be stored in a hashtable and will

execute their visit operations when the accept() method of the IntHashTable class is

called.

Dcm4che-iod:

This project makes use of the composite pattern with the Composite class containing the

component interface. init() and validate() are the only methods in this interface. So

when a client calls these methods, the Composite class will in turn call these same

methods on its children.


Dcm4che-net:

The Association class uses the IntHashtable.Visitor interface from the dcm4che-core

project to create, implement, and add new visitors in methods checkIdle() and

onClosed(). As was the case in the dcm4che-core project, the implementation of these

visitors will execute when the accept() method in the IntHashTable class is called.

Dcm4che-imageio:

This project contains ImageReaderWriterFactory class and its subclasses

ImageReaderFactory & ImageWriterFactory. No implementation calls the

ImageReaderWriterFactory class for an object directly. Instead they directly call the

getInstance() method of its subclasses ImageReaderFactory & ImageWriterFactory.

Only methods within the DicomImageReader class make use of the ImageReaderFactory

and only methods within the DicomImageWriter class make use of the

ImageWriterFactory.


6.2 Dcm4chee Patterns

DCM4che-web

This project contains FolderPermissonsFactory class and its subclasses

DummyPermissonsFactory and FolderPermissonsPropertyFactory. Just like in the

toolkit, no implementation calls the FolderPermissonFactory class for an object directly.

Instead they call the getInstance() method of its subclasses

DCM4che-xds

This project contains XDSQueryObjectFactory class and its subclasses SQLQueryObject

and StoredQueryObject. This behaves the same as the factory in the web module.

7. Using Parallelism with dcm4che


7.1 Extensions

The nature of a tool kit allows for easy incorporation and extension of bits and pieces of

it. As a part of this project, we used dcm4che2 toolkit to produce a GUI implementation

of the DICOM C-STORE command. This was GUI was based strongly on the “dcmsnd”

command line tool that was included with dcm2che2. For the remainder of this section

we will discuss this “dcmsnd multithreaded gui” and compare it to the “dcmsnd”

command line tool in use and in performance.

Figure 29 dcmsnd multithreaded gui screenshot

Figure 29 above shows a screenshot of our GUI application. It is just a simple means to

get all of the minimal required information from the user to make a C-STORE call. The

source needs to identify itself with an Application Entity Title, port, and address of the

destination all with a list of DICOM image files to send. Note that this is exactly the same

minimum information that is required for the dcmsnd command line utility to make a C-

STORE call. The GUI, with build in Windows file / folder browsing popup on to choose

files and directories to add, makes for a much more user friendly experience in single

send situations. In a scripting environment, however, the command line approach would

be better. Still for our experimental purposes decided to pursue a GUI.

7.2 Experiment

7.2.1 Setup

We selected 3 represented data sets: Small at 16.5 MB, Medium at 0.99 GB, and Large at

7.95 GB). These data sets consisted of 124, 587 and 11486 files respectively of various


CT and MR DICOM image data files. We sent these data sets to the dcmrcv host running

on the local machine to minimize the variability of local area network traffic.

To attempt to make this experiment as fair as possible, we tried to keep the environments

similar among the different machines. Unfortunately we did not have the funds or

equipment to allow for test environments that were exactly the same except for differing

number of cores.

For our experiments, we prepared 3 machines: A single core 2.2 GHz machine running

Windows 2000 with 1 GB of memory; A dual core 2.4 GHz machine running Windows

XP Professional with 3.5 GB of memory; And an octo (8) core 2.67 Ghz machine

running Windows XP Professional with 1 GB of memory. To be fair, we chose to run the

single threaded dcmsnd tool on the dual core system for comparison.

7.2.2 Program Details

Upon starting the GUI, our program creates a Threadpool with the number of threads

equal to the number of cores available to the system. The start up time of threads is

masked from the user while he/she inputs all the parameters and browses for files. When

the user clicks send, the files and directories selected are recursed through, counted, and

divided evenly among the available cores to the system. The idea is that each core will

have its own thread waiting in the pool to perform their perspective tasks.

7.2.3 Findings

11486 files (7.95 GB)

0

200

400

600

800

1000

dcmsnd

dcmsnd multithreaded gui 1-core

dcmsnd multithreaded gui 2-core 873.308


1

Figure 30 Timings of Large Data Set


As you can see in Figure 30, there was a dramatic improvement moving from 2 cores to 8

cores on the dcmsnd multithreaded GUI. Unfortunately the data set appears to have been

too large for the single core system running the GUI or the dual core system running the

traditional command line dcmsnd causing the tests to not complete successfully.

587 files (0.99 GB)

0

50

100

150

200

250

dcmsnd 169.397




1

Figure 31 Timings of Medium Data Set

The Medium Data set proved to be more interesting. In Figure 31 the fastest machine in

was the 2-core dcmsnd multithreaded GUI, which surpassed even the dcmsnd running on

the same data set on the same machine by more than 20%. We expected the 8 core

machine to do even better but it proved to be worse than all other set ups save the single

core machine. We speculate that this was caused by the system trying to cram too many

large files across the same network card at the same time, causing a sort of 3-stooges

syndrome where everyone is trying to get through the same door which prevents any one

from going through it.


124 files (16.5 MB)

0

2

4

6

8

10

12

dcmsnd 5.532




1

Figure 32 Timings of Small Data Set

The Small Data Set provided the results most in line with what we were expecting before

the experiment. The dcmsnd command line was faster than our GUI on the single-core

system. However, all of our multi-core setups proved to be faster. The 8-core system was

surprisingly more than 11 times faster than the original command line version!

7.3 Conclusion

It seems that in general, our dcmsnd multithreaded GUI proved to be faster on 2-core

systems than the dcmnd command line program running on the same setup. The 8-core

system appears to have been much better yet on a data set of small or very large sizes.

Perhaps some of this can be explained by how we set up our program to create threads

while the user was inputting the parameters.


8. Bibliography

i http://en.wikipedia.org/wiki/Digital_Imaging_and_Communications_in_Medicine ii http://en.wikipedia.org/wiki/Health_Level_7

iii http://en.wikipedia.org/wiki/Picture_archiving_and_communication_system iv

http://en.wikipedia.org/wiki/Radiology_information_system v http://en.wikipedia.org/wiki/Electronic_medical_records vi

http://en.wikipedia.org/wiki/Modality vii

http://en.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise viii

http://wiki.ihe.net/index.php?title=Scheduled_Workflow ix

ftp://ftp.ihe.net/Radiology/iherad-2000/IHE_in_Practice_Y2_rev7.ppt x http://www.dcm4che.org/ xi

http://www.dcm4che.org/confluence/display/ee2/Home xii Vazquez A, Bohn S, Gessat M, Burget O, Evaluation of Open Source DICOM

Frameworks, Universitat Leipzig http://www.dcm4che.org/confluence/download/attachments/271/ossdicom.pdf?version=1&modificationDate=1178887181318 xiii

http://www.dcm4che.org/confluence/display/proj/The+Project xiv

http://www.dcm4che.org/confluence/display/ee2/Home xv

Clements, Paul; Bachmann, Felix; Bass, Len; Garlan, David; Ivers, James; Little, Reed; Nord, Robert;

Stafford, Judith. Documenting Software Architecture. Addison-Wesley. Copyright 2003. pg. 178 xvi

http://www.sph.sc.edu/comd/rorden/dicom.html xvii http://www.dcm4che.org/confluence/display/ee2/Archive+Content+Administration

dcm4che Architecture and Implementationforums.dcm4che.org/jiveforums/servlet/JiveServlet/download/5-4757...dcm4che Architecture and Implementation ... Computer Science Dr. Ralph Johnson

Documents