Download - Application Hosting
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