medical informatics - algom dicom viewer plusoleg pianykh [email protected] 1 medical informatics...

Oleg Pianykh [email protected] 1

Medical Informatics

Oleg Pianykh, PhD

[email protected]

Oleg Pianykh [email protected]

Networking and Teleradiology


Part 1: Networking standards


Teleradiology

& WWW


Digital Hospital

Digital

Hospital

HIS

(Hospital Information System )

PACS

(Picture Archiving and

Communication System)

HL7

(Health Level 7)

DICOM

(Digital Imaging and

Communications in Medicine)

Integration

EVN|A08|2006010

80823||||||PID|1||31

75875|1127278|SA

MPLE^JOE^^^ |̂|1

9901334|M|||5400

Lake Villa

Dr^^Metairie^LA^7

0001-1230||(

EVN|A08|2006010

80823||||||PID|1||31

75875|1127278|SA

MPLE^JOE^^^ |̂|1

9901334|M|||5400

Lake Villa

Dr^^Metairie^LA^7

0001-1230||(

Text Images


The Radio Doctor – Maybe !

� The concept of

remote data

analysis is

certainly not new,

but it took a while

to develop the

best approaches

and technology.


The first Skype prototype@



Why teleradiology


� Optimization

� 15% annual data growth vs. 2% annual radiology growth

� Access to remote areas

� Balance of knowledge

� Full use of digital formats

Why teleradiology


http://www.nytimes.com/2010/06/03/business/03dartmouth.html


Why teleradiology


http://www.acshpri.org/documents/SurgeonAtlas_BOOK.pdf


PACS: Picture Archiving and

Communication System

Modalities

Archive Workstations

Acquire

Store

View

- DICOM network


DICOM Networking layout


TCP/IP networking:

basic standard for modern computer networks

Low-level DICOM: association

negotiation and PDU. Also known

as DICOM Upper Layer protocol

High-level DICOM: DIMSE and SOP

DICOM networking:Email (SMTP)

Web (HTTP)

File transfer

(FTP)

Netw

ork

applic

atio

n la

yer

DICOM Software Email

Web browser

FTP client


DICOM networking

� DICOM controls data exchange over computer networks (TCP/IP).

� AE – “Application Entity” – any DICOM-compatible device in DICOM

network

� AEs can use DICOM networking commands to verify connectivity,

search for data, and send data to each other.

� “DICOM Conformance Statement” - describes to what extent each

AE supports DICOM (18 volumes!)

� DICOM is service-based standard: any two connected AEs provide

services to each other. For instance, DICOM printer “serves”

DICOM CT scanner, printing CT images.

Must have !


Network service model


Service

Class

Service

Class

SCPSCP

SCUSCU

Service

Class

SCP

SCU

Image storage

SCU

Image storage

SCU

Image storage

SCP

Image storage

SCP

Image storage

SCU

Image storage

SCU

ArchiveArchive

Image storage

SCP

Image storage

SCPImage storage

SCU

Image storage

SCP

Image storage

SCU

Archive

Image storage

SCP

DICOM networking is implemented with

service rendering model: Service Class

Providers (SCPs) provide services to

Service Class Users (SCUs).

SCP/SCU role depends

on the particular task


Connecting DICOM AEs:

IP, Port, AE Title.

Configuration is easy, assuming you are in

control of your DICOM devices.



DICOM services

� DICOM units (AEs) request and provide services to each other.

� Main DICOM services include:

� Echo (verification) - verifies in network partner (AE) is available

� Store - stores DICOM objects on specified AE

� Find - searches for DICOM objects on specified AE

� Get - retrieves DICOM objects from specified AE

� Move - moves DICOM objects from AE1 to AE2

� Each service includes command (such as Find) and command data (such as Find parameters).

� Service and its data form Service-Object Pair (SOP)

DICOM Message Service Elements

(DIMSE)



C-Echo (Verification SOP)


Slang:

DICOM-ping

Send DICOM verification Request

C-Echo SCU

(Example: Archive)

C-Echo SCP

(Example: Modality)

Send DICOM verification Response

� “Client” (Service Class User, SCU) is asking for a service.

� “Server” (Service Class Provider, SCP) is providing the service.

� SCU/SCP roles may change depending on the task.

� Verification SOP UID: 1.2.840.10008.1.1

Servers can

be SCUs!


C-Find

� “Client” (Service Class User, SCU) is asking for a service.

� “Server” (Service Class Provider, SCP) is providing the service.

� SCU/SCP roles may change depending on the task.

Find all MR studies for patient

J*son

C-Find SCU

(Example: Radiology workstation)

C-Find SCP

(Example: Archive)

List of studies found

Important: DICOM can search medical databases

remotely.



C-Store

� Store images to C-Store SCP

Sends CT images to be stored

(requests CT Storage service)

CT Storage SCU

(Example: CT scanner)

CT Storage SCP

(Example: Archive)

Slang:

DICOM-push

Accepts CT images for storage

(provides CT Storage service)


C-Get

� Retrieve images from C-Get SCP (using the same connection)

Retrieve study (images) with Study

UID 123456789

C-Get SCU


C-Get SCP

(Example: Archive)

Images (sent with C-Store)

Slang:

DICOM-pull



C-Move

� Ask C-Move SCP to send images to “third party” destination

Retrieve study (images) with Study UID 123456789

C-Move SCU


C-Move SCP / C-Store SCU

(Example: Archive)

Images (sent with C-Store)

C-Store SCP

(Example: Workstation)

Slang:

DICOM-pull

MWL (Modality Worklist)


Radiology Information

System (RIS)

Send current patient

scanning schedules

C-Find-Rsp: Provide current

scanning schedules

MWL SOP, based on C-

Find DIMSEFetching patient/schedule info from RIS

into MWL SCP, converting it into DICOM

C-Find-Rq: Find current scanning

schedules for this modality

MWL SCU

(Example: Modality)

MWL SCP

(Example: Archive)


DICOM Services around us (!)


DICOM & HL7 Networking Basics

� C-Echo, C-Find, C-Store, C-Get (C-Move) is all you

need to run a medical imaging (DICOM) network.

� There are lots more in DICOM: printing (becoming

extinct), encapsulating various formats (PDF, video

MPEG, screenshots, reports).

� HL7 provides similar query/retrieve mechanism:

� http://www.interfaceware.com/hl7-standard/hl7-

messages.html – browse HL7 pages, very informative

� Example:

http://www.mexi.be/documents/hl7/ch200151.htm



Can I make my own PACS?

Absolutely. The recipe:

� Make sure your modalities are on the hospital network (ping

them). Find DICOM settings in their interfaces.

� Make sure your modalities “speak” DICOM (use C-Echo).

� Install DICOM software (trial or not) on any hospital-

networked computer - your “pilot server.”

� Configure DICOM modalities to store data on the pilot server.

� Configure DICOM workstations to retrieve data from the pilot

server (using DICOM software on the workstations).

� Let the pilot server run for two weeks to estimate your storage

volume and bottlenecks. Then buy the real server

accordingly.Oleg Pianykh [email protected]

Can we build a DICOM Dropbox?

DICOM Dropbox: Dropping DICOM file into a “dropbox”

folder automatically forwards it to a preset PACS archive

Q: Which DICOM service will you need:

C-Echo C-Find C-Store

C-Get C-Move

?


PACS Archive

File drop DICOM upload


Part 2: Getting “tele” done (right)


Getting “tele” done (right)

� Q: OK, we know that DICOM and HL7 work well on local

hospital networks.

Can they scale to WWW?



Hidden problems

� Conceptually, remote clinical networking is expected to

use the same standards and protocols as local hospital

networks, but@

� In reality, making things work remotely calls for much

more reliable, functional, integrated solutions, which

cannot be found in a local, static environment.


What about tele ?

� Classical clinical standards such as DICOM have pros

and cons:

� Pros:

� DICOM association establishment (handshake)

mechanism ensures device/app compatibility.

� Default data format is always defined.

� Advanced functionality (such as remote searches –

far better than FTP!)

� Fast (although there are many myths about “DICOM

overheads”)



What about tele ?

� Cons:

� No error recovery, no solid error-reporting

mechanism (errors like “reason-not-specified”)

� No idea of transmission progress

� Static IPs (DICOM AEs find each other by IP

addresses)

� Cannot specify certain important parameters (such

as image compression ratio)

� Heavyweight: you cannot run DICOM in a web

browser

� Poor support for internationalization (localization)



Hospital PACS

Teleradiology – “Online radiology”

Mobile workstation

Remote workstation

Remote PACS



Teleradiology vs. PACS

Teleradiology DICOM

(data)Network

(connection)

Making the

damn thing

work !!!

= + +

PACS

Teleradiology Proprietary=

OR


Important aspects of teleradiology

� Standardization (!!!)

� Image compression and quality

� Flexible data access clients (lightweight, OS- and

browser-independent)

� Fault tolerance

� Prefetching and other methods to avoid slow networks

� Information protection and security

� Seamless integration into hospitals’ electronic records

� Use of consumer computers

� Staying away from simplistic models (email attachments,

Dropbox, Skype, remote desktop, etc.)



Opening hospital network to WWW

WWW

Hospital

Telerad server

Remote viewing

PACS server

Open PACS server

Isolated clinical

network

Never share your servers !


Opening hospital network to WWW

WWW

Hospital

Telerad server

Remote viewing

PACS server

RDP into hospital



Data volume

Typical sizes of digital images and studies.

Image modality Typical image matrix

(height width, bytes

per pixel)

Image size,

kilobytes

(KB)

Typical number

of images in a

study

Typical

study size,

megabytes

(MB)

Nuclear medicine,

NM

128 × 128 × 1 16 100 1.5

Magnetic

resonance, MR

256 × 256 × 2 128 200 25

Computed

tomography, CT

512 × 512 × 2 512 500 250

Color ultrasound,

US

600 × 800 × 3 1400 500 680

Computed

radiography, CR

2140 × 1760 × 2 7356 4 30

Color 3D

reconstructions

1024 × 1024 × 3 3000 20 60

Digital

mammography,

MG

Up to 6400 × 4800 × 2 60000 4 240


Dealing with volume: compression

Illustrating excessive lossy compression with images and text patterns.

Overdone JPEG creates highly-visible blocking artifacts; overdone

JPEG2000 creates blur.



Dealing with volume: prefetching

Hospital PACS

Prefetching

server

DICOM images

Fast network

Slow network

DICOM images

Remote viewing

Fast network


Load balancing: thin and thick

Thin client server Thick client server

Computing on

the server

Sending the

results

Sending the

data

Computing

the results

Thin client Thick client

Know how to balance your loads !


Web clients and their advantages


Cross-platform, cross-

browser

“Zero footprint” ensures

confidentiality

Diagnostic quality

Web-based, using well-

known web protocols

Displaying full multimedia

information: imaging,

reports, charts, @

Patient reports

Diagnostic

images

Well, what about the disadvantages?

� Name a few problems with web clients:



Web clients: limitations


Universality limits

functionality

Limited memory

Limited processing

power

Require lighter (and

often proprietary)

versions of DICOM and

HL7

Complex vs. universal


Failed to start

More complex web

technologies may not be

widely supported.



Implementation: facade


Implementation: behind the facade

Do your doctors

have 15 minutes?






Failed DICOM

image display






http://www.slate.com/articles/business/bitwise/2013/10/what_went_wrong_with_healthcare_gov_the_front_end_and_back_end_never_talked.html


Implementing web client

� ActiveX? Java? HTML5? .NET?

� True web-based client is the best way to go. Good for

stealth radiology as well (leaving no traces on the client

computer)

� Load-balancing should be considered in the context of

your implementation technology. Example: adjusting

image brightness interactively

� Can you do this on your client?

� Price for doing this on your server?


Implementing web client

� Performance optimization is essential for web clients.

� Example: image compression

� Compress ahead of time, or on the fly?

� Hi-res, or thumbnails?

� Choice of algorithm: ZIP? JPEG? PNG?

� Choice of implementation: Multithreaded? DB-based?

Separate server for compression? Separate PACS

archive?

� Choice of hardware: GPU/CPU? Processor cores?

Location?



Implementation

� Heavyweight teleradiology (inter-connected PACS) –

great for large imaging projects with well-defined

boundaries. Example: Radiologists from hospital A

assist radiologists from hospital B.

� Lightweight teleradiology is perfect for mobile, “cloudy”

projects with many moving targets. Example: setting up

a virtual radiology network business, to consult

understaffed hospitals.



Web-alternatives: PACS networks

WWW

LAN

Remote hospital

PACS server

Connecting several PACS via VPN

channels is used in large, static regional

projects.

VPN



Web-alternatives: peer-to-peer networking

WWW

LAN

Remote viewing

PACS server

Isolated clinical

LAN

Can be used for dynamic remote

access

Peer-to-peer server connects remote to

local using outgoing requests only


Data-sharing channels

� DICOM (data and network) – the best

� DICOM email (Germany)

� FTP and such (file sharing)

� Proprietary formats

� Remote viewing clients

� Multimedia (JPEG, AVI, @)

� Hard copies (CD, DVD, @)


Data quality


Screenshots, scanned, copiedDICOM (original)

Early approach to teleradiology: transmit data

by any means. Result: lost data, horrified

medical community.

Viewing quality: image interpolation

The goal of any interpolation algorithm is to preserve the

frequency content (local details) of the original image.

Linear Cubic


iPad high-res display phenomenon?


Automatically

checking mailboxes

and retrieving DICOM

images

DICOM over email (the right way)


Automatically wrapping DICOM images into MIME

and emailing to clients:

[email protected]

[email protected]

WWW email

server

DICOM

PACS workstation

(with DICOM email)

at HospitalA

PACS workstation

(with DICOM email)

at ClinicB

Ubiquitous and inexpensive fax

machine

� Anything works, as long as it makes sense!

� The framework and its successful use are explained in [Rothpearl].

A special software plug-in can automatically register incoming

DICOM studies, and receive faxes, related to them—converting

them into DICOM images, and storing them in the PACS to

accompany the original image data from the modalities. If you add

the simplicity of the fax machine (compared even to a flatbed

scanner), that even the most computer-averse hospital staff can

handle, you will certainly appreciate the efficiency of the fax-to-

PACS interface.

� I can’t wait for DICOM Twitter.

[Rothpearl] Allen Rothpearl, Rafael Sanguinetti, John Killcommons, “Development of a Fax-Based System for Incorporating Nondigital Paper-Based Data into DICOM Imaging

Examinations”, Journal of Digital Imaging, 2010 February; 23(1): 81–86.



Multimedia


Modality 2

Modality 1

PACS

ServerMultimedia

Server

DICOM MultimediaMultimediaData format:

Multimedia support is essential for robust implementation.

Robustness is not about “spare parts”;

it’s about functional alternatives !

DICOM for WWW: WADO and MINT

� WADO (DICOM Part 18) – Web Access to DICOM persistent

Objects

� MINT – Medical Imaging Network Transport

https://YourHospitalServer/imageaccess.js?requestType=WADO

&studyUID=1.2.250.1.59.40211.12345678.678910

&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789

&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2

&contentType=image%2Fjp2;level=1,image%2Fjpeg;q=0.5

&annotation=patient,technique

&columns=400

&rows=300

&region=0.3,0.4,0.5,0.5

&windowCenter=-1000

&windowWidth=2500




Working on any platform/environment

Mobile modalities and workstations


FDA approved “if you do not have a

workstation”


Know your gadget!


Do not get fancy, get practical !

VS.

Patients in charge


Patients are getting

more and more

involved. Is your

hospital ready?


Nationwide PACS

� Nationwide PACS does not mean

single PACS provider !

� The most essential question is

always the data, and not the

implementation. For example, do

you have a mechanism for

nationwide Patient ID?


Worldwide PACS: Parlez-vous

Deutsch? (not yet)


Start with planning for

multilingual data.



Convenience

Reading images remotely can be fun !

Teleradiology in the US


Hospital size (number of radiologists)

Pe

rce

nt o

f h

osp

ita

ls u

sin

g te

lera

dio

log

y

From 2003 to 2007


Predators or allies?

� There is one important item in any teleradiology project that has

absolutely nothing to do with DICOM: personal relationships.

� Many hospitals tend to view expanding teleradiology practices as

predators, threatening their business, jobs, and quality standards.

Moreover, when patients and referring physicians learn that their

images will be read somewhere else, they may get concerned as

well.

� Therefore, the pros and cons of any teleradiology project should be

weighed ahead of time, with very clear boundaries of responsibility

defined for the local and remote radiology groups.

� If anything is questionable, prioritize the quality, and the quantity

will follow.

� http://www.youtube.com/watch?v=mXgmX0k1se8


Starting your (teleradiology) project

� Estimate the required time to transmit your data

(volume/speed).

� If necessary, use compression or prefetching to reduce

data transfer delays.

� Decide on Pull (retrieving remote data on demand) vs.

Push (having remote data sent to you) models. Pull is

best if you need only a small fraction of all data, and if

you want to be entirely mobile.

� Establish a local server to store your data (especially if

the data is pushed to you).



Starting your project

� Choose viewing solution and software that accommodate

the widest range of devices (smartphones included).

Favor solutions with better multimedia support.

� Avoid hard-coded, impossible to change, static

configurations. Favor inter-independent, modular

solutions.

� Hire your own IT support (you may have it part-time, but

you have to have it).


Starting your project

� Integrate your solution into the other systems you and

your doctors are using. The data should flow

automatically.

� Always plan for scaling and growth.

� Have a fully functional plan B for your entire setup.


medical informatics - algom dicom viewer plusoleg pianykh [email protected] 1 medical informatics...

Documents