Application Hosting

1
Application Hosting

• Lawrence Tarbox, Ph.D.Washington University in
  St. Louis School of MedicineMallinckrodt
  Institute of Radiology, Electronic Radiology Lab

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.

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 sites infrastructure.

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

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.

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.

7
Typical Plug-in Concept
8
DICOM WG-23 Goal

• Portable applications that plug into any host
  that implements the standardized socket

9
Idealized Goals

• A Standardized API that is
• Easy to learn and use
• Language independent
• Platform independent
• Based on publicly available technology
• Extensible
• Secure

10
Reality Check

• Life is a compromise
• 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.

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

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

13
Model-Based Data Exchange
AbstractData Subset
DataObjects
Conversion
FullNativeData
Bulk Data(e.g. voxels)
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)

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

16
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 onWG 23 APIs

XIP developed Application
Standard API

Unix, Mac, PC
Internet Server
Commercial Vendor 2
Commercial Vendor 1
? Prototype Collaboration ?
? Clinical ?
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.

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

19
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
. . .
Distribute
WG23
WG23
WG23
WG23

XIP Host
(Can be replaced with any DICOM WG23-compatible
Host)
Host-Specific Plug-in Libs
DICOM, HL7, otherservices per IHE
caGRID Services viaImaging Middleware
Distribute
Standalone Application
XIP Class Library Auto Conversion Tool
20
An Application Developer may use the XIP Builder
tool from Siemens Corporate Research to create
the apps scene graph and processing pipelines
from XIP Libraries
21
The XIP Builder tool can be used to test and
debug the scene graph
22
Application Developer controls the scene graph by
creating a GUI program (e.g. via Java Swing)
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

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