Lawrence Tarbox, ChairWG-23 Status Report – SPIE 2008

Provocative Statement

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 World?

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’.

Hosting System

Supplies common infrastructure needed by all applications

•Login

•Audit Trail

•Security

•Worklists

•Database

•Network Access

•Task/Resource Management

Hosted Application

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

Guiding Principles

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 (for the 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 Main Interfaces

“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.

Application Initialization1. 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 Destroy instanceinstance

IdleIdleWaiting for Waiting for

tasktask

InProgreInProgressss

Doing taskDoing task

CompletedCompletedHost grabbing Host grabbing

outputoutput

SuspendSuspendeded

Task pausedTask paused

CancelleCancelledd

Task Task abortingaborting

Hosted Application States

“Application” Methods

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

“Host” Methods

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

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

(appPreferredScreen : Rectangle) : Rectangle

Condition Handling

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

Data 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

File Access Methods

getObjectDescriptors() : ObjectDescriptor[]

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

Symmetric between host and application

Object Descriptor

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)

Object Locator

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)

File Exchange Sequence

Recipient Sender

getObjectDescriptors()

return of ObjectDescriptors[]

getAsFile( desiredObjects: ObjectDescrptors[])

return of ObjectLocators[]

Model Access Methods

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

Abstract vs. Native Models 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’

Abstract 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 domain 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

Abstract Model Example

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 Methods

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’)

Example XPath for DICOM 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 SequenceRecipient 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 It 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 is the ?

WG23 / XIP Relationship WG-23WG-23 addresses clinical addresses clinical

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

caBIG XIPcaBIG XIP addresses an addresses an open-architecture, open-open-architecture, open-source, integrated source, integrated environment for rapid environment for rapid application development application development based onbased 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

XIP Builder™

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

Supplement 118 Timetable

Review for Public Comment Spring 2008

Frozen Draft Summer 2008 May decide to ballot early if

implementations are far enough along Ballot Winter 2008

After 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