application hosting
DESCRIPTION
Lawrence Tarbox, Ph.D. Washington University in St. Louis School of Medicine Mallinckrodt Institute of Radiology, Electronic Radiology Lab. Application Hosting. Provocative Statement. - PowerPoint PPT PresentationTRANSCRIPT
Lawrence Tarbox, Ph.D.Washington University in St. Louis School of MedicineMallinckrodt Institute of Radiology, Electronic Radiology Lab
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.
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.
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. ...”
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’.
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.
Typical Plug-in Concept
……AA
EE
BB CC DD
FF
DICOM WG-23 Goal
Portable applications that ‘plug into’ any host that implements the standardized ‘socket’
Syngo
Cedara
caBIG
Advantage
Agfa
any WG23 Host
Idealized Goals
A Standardized API that is:
Easy to learn and use Language independent Platform independent Based on publicly available
technology Extensible Secure
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.
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
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
Model-Based Data Exchange
DataObjects
Conversion
Bulk Data(e.g. voxels)
AbstractData Subset
FullNativeData
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)
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
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
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.
What is the ?
Major Parts of the
XIP Reference Host XIP Libraries XIP Reference Applications
XIP Development Tools
The top 3 combine to form an XIP Workstation
XIP Application
(Can be replaced with any DICOM WG23-compatible Host)
XIP Host Adapter
XIP ModulesHost Independent
WG23
XIP HostWG23
WG23
Web-based Application
Medical Imaging Workstation
Standalone Application
Distribute
Distribute
DICOM, HL7, & otherservices per IHE
caGRID Services viaImaging Middleware
XIP Application Builder
XIP Class Library Auto Conversion Tool
Host-Specific Plug-in Libs
WG23
Distribute
ITK
VTK
XIP
LIB
. . .
XIP Development Process
An Application An Application Developer may Developer may
use the XIP use the XIP Builder tool Builder tool
from Siemens from Siemens Corporate Corporate
Research to Research to create the app’s create the app’s
scene graph scene graph and processing and processing pipelines from pipelines from XIP LibrariesXIP Libraries
The XIP Builder The XIP Builder tool can be used to tool can be used to test and debug the test and debug the
scene graphscene graph
Application Application Developer Developer
controls the controls the scene graph by scene graph by creating a GUI creating a GUI program (e.g. program (e.g.
via Java Swing)via Java Swing)
• 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
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