Lawrence Tarbox, ChairWG-23 Status Report – SPIE 2008

Provocat i ve St at ement

DICOM WG-23 hopes to fundamentally change the way the medical imaging world thinks in regards to the distribution and deployment of medical imaging applications.

A Brave New Wor l d?

Separate the provision of infrastructure from the application.Infrastructure providers concentrate on the movement and storage of data and results, and on workflow management.Application providers concentrate on the processing and analysis of that data, providing results back to the infrastructure.Minimize the ‘reinvention of the wheel’.

Host i ng Syst em

Supplies common infrastructure needed by all applications

•Login

•Audit Trail

•Security

•Worklists

•Database

•Network Access

•Task/Resource Management

Host ed Appl i cat i on

Provides task specific business logic

•Works with any Hosting System that support the WG-23 Interface

•Depends on the Hosting System for common infrastructure

•Can work with abstract data models, independent of underlying storage format

Gui di ng Pr i nci pl es

Simple encapsulation of existing applications Self-contained applications Data exchange via files (e.g. Part 10 format)

Ease development of new applications for DICOM novices Simple abstract model Hosting System parses and builds DICOM objects Full native access available if needed

Use existing technology where practical

Out of Scope ( f or t he moment )

Full integration into the Hosting System GUI No standard GUI widgets However, host may provide rectangular screen

area recommendation to cooperating applications Discovery

No standard service for locating suitable applications on the Internet for installation

No mechanism for determining what applications are installed on the Hosting System

Access to DICOM services beyond storage

Two Mai n I nt er f aces

“Application” holds methods that the Hosting System uses to control and feed data to the Hosted Application.

“Host” holds methods that the Hosted Application uses to communicate outputs to the Hosting System, and to notify it of status and state changes.

One-to-one correspondence of instances of the “Host” and “Application” interfaces.

Interfaces are defined in WSDL to be language and platform independent.

Appl i cat i on I ni t i al i zat i on1. Hosting System locates desired Application

using mechanisms outside of the standard.2. Hosting System initializes the Hosted

Application using the equivalent of a “run” or “exec” command.

3. Hosted Application utilizes command line arguments passed by the Hosting System to connect to the “Host” interface, and to present the “Application” interface.

ExitExitDestroy instanceDestroy instance

IdleIdleWaiting for taskWaiting for task

InProgressInProgressDoing taskDoing task

CompletedCompletedHost grabbing outputHost grabbing output

SuspendedSuspendedTask pausedTask paused

CancelledCancelledTask abortingTask aborting

Hosted Application States

“Appl i cat i on” Met hods

setState(state : State) : boolean getState() : State bringToFront() : boolean

“Host ” Met hods

notifyStateChanged(state : State) : void notifyOutputAvailable() : void notifyStatus(status : Status) : void

getTmpDir() : String getOutputDir() : String generateUID() : String getAvailableScreen

(appPreferredScreen : Rectangle) : Rectangle

Condi t i on Handl i ng

If there is a notable condition (e.g. a progress report, an error) in the Hosted Application, it may inform the Hosting System via a notifyStatus() call.

The Status includes: statusType (i.e. INFO, WARN, ERROR, FATAL) codingSchemeDesignator codeValue messageString

Dat a Exchange

File Access Methods Simple exchange of files (e.g. DICOM Part 10) Can support other file formats (e.g. Analyze) Furthest along (essentially finished)

Model Access Methods Both Native (e.g. DICOM models) and Abstract

(e.g. Multi-Dimensional Image) versions Is independent of the underlying data format

Fi l e Access Met hods

getObjectDescriptors() : ObjectDescriptor[]

getAsFile(desireObjects : ObjectDescriptor[]) : ObjectLocator[]

Symmetric between host and application

Obj ect Descr i pt or

Consists of: UUID : String MIMEType : String SOPClassUID : String Grouping info

UUID used to: Avoid potential collisions with SOP Instance UID Maintain generality (i.e. can refer to non-DICOM

objects)

Obj ect Locat or

Consists of: referencedUUID : String uri : URI offset: Integer

referencedUUID, which identifies the object, is taken from the Object Descriptor

The URI identifies the location of the desired object (i.e., the file)

Fi l e Exchange Sequence

Recipient Sender

getObjectDescriptors()

return of ObjectDescriptors[]

getAsFile( desiredObjects: ObjectDescrptors[])

return of ObjectLocators[]

Model Access Met hods

Derived from Java Image IO concepts: Abstract access to common data Generic mechanism to access format-specific data

Utilize the “XML Infoset” concept Provider/Sender maintains a model of the referenced

data, e.g. using DOM tools Using DOM does not mean that the data ever existed

natively in XML form DOM is a convenient way to describe the layout of the

data, even if the data is in DICOM format Requestor/Recipient utilizes XPath to identify the

desired subset of data

Abst ract vs. Nat i ve Model s Abstract Models

Includes data common to multiple formats (e.g. DICOM, Analyze)

Application need not know the format of the native data Does include references to the native data from which the

abstract model was derived Native Models

Gives full access to all information available in the native data

Allows an application to just access those parts of the native data that are of interest

Bulk Data Access (separate from the model) File name (URI) plus offset (for performance) ‘Cooked’ or ‘Raw’

Abst ract Model

Make life easier for the application developer Draws simplified concepts from the new DICOM

enhance multi-frame objects Only commonly used dimensions included References the source native models if an application needs

full details

Assumes ‘cooked’ data, e.g. Modality LUT applied ‘Clean’ data (sign extended, no overlay bits) Data from old style SOP Classes reorganized

Signed & unsigned integers, single & double floats Semantic intent and units included

Spec of domai n and range

Range (components) Scalar

Data-type, e.g. int32 Semantics, e.g. T1 weighted MRI signal intensity Units

Vector Nb-components ; table of (Data-type, Semantics, Units)

Domain (variables) Nature of interval

Regular-interval Nb-samples ; inter-sample-distance ; sample-width

Non regular interval Nb-samples ; origin ; table of (dist-to-origin, sample-width )

Semantics : e.g. space, time, energy

Abst ract Model Exampl e

T1weighted MR dataset Scalar Range

Data-type=int32 Semantics = ‘T1weightedMRsignalintensity’

3 variables Regular interval

Nb-samples=256, inter_sample-dist=1mm, sample-width=1mm semantics = ‘space along X’

Regular interval Nb-samples=256, inter_sample-dist=1mm, sample-width=1mm semantics = ‘space along Y’

Regular interval Nb-samples=120, inter_sample-dist= 4mm, sample-width=4mm semantics = ‘space along Z’

Model Access Met hods

Get Object Descriptors Descriptors for all native objects

Get Abstract Object Descriptors Alternative to getObjectDescriptors() Hosting System creates Abstract Models as needed Returns Native Descriptors if not part of an Abstract

Model

Query XPath May return single values or Infosets Multiple queries to multiple objects in one call

Get Bulk Data (‘cooked’ or ‘raw’)

Exampl e XPat h f or DI COM Model

/DicomObject/Element[@name=“View Code Sequence”]

/Item[@number=1] /Element[@name=“Code Meaning”] /value[@number=1]

Can access by Name or Group+Element Tags Will have provisions for proper Private Data

Element access

Model Exchange Sequence

Recipient Sender

getAbstractObjectDescriptors()

return of ObjectDescriptors[]

queryModel( targetModels:UUID[], xpath:String[])

return of Infosets

getBulkData( desiredData:DataDescriptors[])

return of DataLocators[]

How You Can Prepare

Use the WG-23 Application Hosting interfaces in your own work

Encourage your developers to do the same Start discussing with vendors their support

for the WG-23 Application Hosting interfaces Eventually include WG-23 Application

Hosting interface support in RFPs

Can I Get I t Now?

The eXtensible Imaging Platformhttp://www.openXIP.org or http://www.caBIGimaging.org

Includes a reference implementation of the WG-23 Application Hosting interfaces

Includes examples of a Hosting System and several Hosted Applications

Part of NCI’s caBIG™ program Commercial friendly open source license

Commercial implementations with SDKs starting to appear (prototypes)

The eXtensible Imaging Platform (XIP™) is the image analysis and visualization tool for caBIG.

XIP is an open source environment for rapidly developing medical imaging applications from an extensible set of modular elements.

XIP may be used by vendors to prototype or develop new applications.

Imaging applications developed by research groups will be accessible within the clinical operating environment, using the DICOM Application Hosting interface.

XIP serves as a reference implementation of the DICOM WG-23 Application Hosting interfaces.

What i s t he ?

WG23 / XI P Rel at i onshi p

WG-23WG-23 addresses clinical integration addresses clinical integration and vendor inter-operability by and vendor inter-operability by defining standardized “plugs” and defining standardized “plugs” and “sockets” (APIs)“sockets” (APIs)

caBIG XIPcaBIG XIP addresses an open- addresses an open-architecture, open-source, integrated architecture, open-source, integrated environment for rapid application environment for rapid application development based ondevelopment based onWG 23 APIsWG 23 APIs

Unix, Mac, PC Internet ServerCommercial Vendor

#2

……Commercial Vendor #1

Clinical Clinical Prototype &Collaboration Prototype &Collaboration

XIP developed XIP developed

ApplicationApplication

Standard API

XI P Bui l der™

Visual editing/debugging tool for rapidly developing imaging applications

•Usable for hosted applications as well as standalone apps

•Extensible framework• Open Inventor® base• ITK & VTK cores• GPU based GLSL

rendering/processing• High quality MPR• Remote rendering• Overlays/Measurements• Custom Additions

Suppl ement 118 Ti met abl e

Review for Public Comment Spring 2008 Frozen Draft Summer 2008

May decide to ballot early if implementations are far enough along

Ballot Winter 2008

Af t er Supp. 118?

Additional Work Item proposals expected Phase 2 will fill holes from Phase 1 (e.g. some

of the ‘out of scope for 118’ issues) New features depend on user demand