1. Lawrence Tarbox, Ph. D. Washington University in St
Lawrence Tarbox, Ph.D. Washington University in St. Louis School of Medicine Mallinckrodt Institute of Radiology, Electronic Radiology Lab
Application Hosting
Lawrence Tarbox, Ph.D.
4/9/2008

2. 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.
Lawrence Tarbox, Ph.D.
4/9/2008

3. Status Quo Medical imaging workstations generally are closed systems.
There is no common, standardized method for adding new functionality to a medical workstation.
The key stakeholders who wish to see new functionality added often are not the workstation provider.
New ‘cool’ tools often require adding entire workstations to a site’s infrastructure.
Lawrence Tarbox, Ph.D.
4/9/2008

4. From the SIIM 2007 Workflow Demonstrations
Cardio Workflow – Dr. Anwer Quershi
“… going back and forth to various workstations and the use of different equipment is disruptive and slows treatment …”
Nuclear Workflow – Dr. Eliot Siegel
“... This case illustrates the disruptions that can be introduced due to multiple systems and the need to go back and forth. ...”
Lawrence Tarbox, Ph.D.
4/9/2008

5. 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’.
Lawrence Tarbox, Ph.D.
4/9/2008

6. Proposed Solution
Create a mechanism where applications written by one party could be launched and run on systems created by multiple other parties.
Allow launched applications to efficiently access images and other resources controlled by the hosting system.
Provide a framework for exchanging information about those applications.
Support both research and clinical environments.
Lawrence Tarbox, Ph.D.
4/9/2008

7. Typical Plug-in Concept… A E B C D F
Lawrence Tarbox, Ph.D.
4/9/2008

8. DICOM WG-23 Goal
Portable applications that ‘plug into’ any host that implements the standardized ‘socket’
Syngo
Cedara
caBIG
Advantage
Agfa
any WG23 Host
Lawrence Tarbox, Ph.D.
4/9/2008

9. Idealized Goals A Standardized API that is: Easy to learn and use
Language independent
Platform independent
Based on publicly available technology
Extensible
Secure
Language independence – the API is defined in such a way that programs written in any common programming language could utilize it.
Platform independence – the API is defined in such a way that it is not dependent on any particular computing platform or operating system.
Extensible – the API can be extended in a backwards compatible fashion. Old applications still work even with new extensions in place, while new applications that are aware of the extensions can gain access to a richer set of functionality.
Protected – the API design insures that intellectual property rights can be protected, and that appropriate permissions and licenses are in place. In other words, a Hosting System will be able to launch a Hosted Application without being able to ‘see’ the internals of that Hosted Application, nor will the Hosted Application be able to steal internal code of the Hosting System. The Hosting System would not be able to launch a Hosted Application without permission or license from the owner of the Hosted Application.
Secure – the Hosted Application’s access to data on the Hosting System would be controlled via the API by the Hosting System. The Hosting System would be responsible for access controls and audit logging, since it is the one providing the data to the Hosted Application
Lawrence Tarbox, Ph.D.
4/9/2008

10. “Life is a compromise” Reality Check
Language and platform independence often translates into reduced performance.
Choice of development environment often restricts portability.
The real goal is to come as close to the ideal as practical, and minimize the impact where we fall short. Take one step at a time.
Lawrence Tarbox, Ph.D.
4/9/2008

11. Suggested Staging
Stage one – Access to DICOM Datasets and Results Recording
Stage Two – Access to Non-Interactive Application Services (e.g. print, archive)
Stage Three – Access to Interactive Application Services (e.g. GUI, ‘skins’, rendering)
Stage Four – Standard Workflow Descriptions, and Interactions Between Hosted Software
Lawrence Tarbox, Ph.D.
4/9/2008

12. Targets for Stage One Basic Launch and Control of a Hosted Application
Load, Unload, Start, Abort
Simple Interchange of Data Between a Hosting System and Hosted Applications
File-based data exchange for existing applications
Model-based data exchange for new applications
Manual Configuration
Java and .net technology bindings
Lawrence Tarbox, Ph.D.
4/9/2008

13. Model-Based Data Exchange
Abstract Data Subset
Data Objects
Conversion
Full Native Data
Bulk Data (e.g. voxels)
Lawrence Tarbox, Ph.D.
4/9/2008

14. 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
File name (URI) plus offset (for performance)
Lawrence Tarbox, Ph.D.
4/9/2008

15. Pushing for Adoption
Standardization being done via DICOM with participation from both medical imaging vendors and users
Open-source, commercial friendly reference implementation being created
XIP – the eXtensible Imaging Platform
WG-23 participants (vendors and the XIP developers) exchange test implementations to insure interoperability
Lawrence Tarbox, Ph.D.
4/9/2008

16. XIP developed Application  Prototype & Collaboration 
WG23 / XIP Relationship
WG-23 addresses clinical integration and vendor inter-operability by defining standardized “plugs” and “sockets” (APIs)
caBIG XIP addresses an open-architecture, open-source, integrated environment for rapid application development based on WG 23 APIs
XIP developed Application
Standard API
For those of you that were not able to attend Fred Prior’s talk, I’ll first desc …
Commercial Vendor #1
Commercial Vendor #2
Unix, Mac, PC
Internet Server
 Clinical 
 Prototype & Collaboration 
Lawrence Tarbox, Ph.D.
4/9/2008

17. What is the ?
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 a new DICOM Plug-in interface first implemented in XIP.
XIP serves as a reference implementation of the DICOM WG-23 Application Hosting interfaces.
Lawrence Tarbox, Ph.D.
4/9/2008

18. Major Parts of the XIP Reference Host XIP Libraries
XIP Reference Applications
XIP Development Tools
The top 3 combine to form an XIP Workstation
Lawrence Tarbox, Ph.D.
4/9/2008

19. XIP Development Process
XIP Application Builder
Medical Imaging Workstation
XIP Development Process
Distribute
XIP Application
XIP Modules
Host Independent
Web-based Application
XIP Host Adapter
XIP LIB
ITK
VTK
. . .
WG23
WG23
WG23
WG23
Distribute
XIP Host
(Can be replaced with any DICOM WG23-compatible Host)
Host-Specific Plug-in Libs
DICOM, HL7, & other services per IHE
caGRID Services via Imaging Middleware
Distribute
Standalone Application
XIP Class Library
Auto Conversion Tool
Lawrence Tarbox, Ph.D.
4/9/2008

20. An Application Developer may use the XIP Builder tool from Siemens Corporate Research to create the app’s scene graph and processing pipelines from XIP Libraries
Lawrence Tarbox, Ph.D.
4/9/2008

21. The XIP Builder tool can be used to test and debug the scene graph
Lawrence Tarbox, Ph.D.
4/9/2008

22. Application Developer controls the scene graph by creating a GUI program (e.g. via Java Swing)
Lawrence Tarbox, Ph.D.
4/9/2008

23. Host
Provides the infrastructure in which XIP or DICOM WG-23 Applications run
Authenticates user
Manages installation, launching, and termination of XIP Applications
Provides data and services to XIP Applications
Accepts status information and results back from XIP Applications
Deals with auditing and controls access to services and data
Isolates the XIP application from the nature of databases, archives, networks, and possibly image data formats
Manages access to DICOM networks, objects, and services
Creates Abstract Models from input data
Handles workflow issues
IHE General Purpose Worklist support
Supports any application that follows the DICOM WG-23 Application Hosting Interface Standard
Lawrence Tarbox, Ph.D.
4/9/2008

24. Summary
XIP provides the ability to create rapidly create applications customized to specific tasks.
The DICOM WG-23 Application Hosting interfaces allow those applications to run on any workstation that supports the standard interfaces
XIP includes a reference host implementation
Other vendors may eventually host applications
XIP with DICOM WG-23 represent new paradigm for writing and distributing medical imaging applications
Lawrence Tarbox, Ph.D.
4/9/2008