Lawrence Tarbox, Ph.D. Washington University in St. Louis School of Medicine Mallinckrodt Institute...

APPLICATION HOSTING

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

12/1/2009 1Lawrence Tarbox, Ph.D.

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.


The 1st Driver – Molecular Imaging

A ‘bright dot’ in the image is not sufficient

Ideal is a quantitative number, with normal ranges derived from population, as now done in lab analysis

Newer agents will require more sophisticated analysis: Agent uptake/decay rates Pre/post comparisons Comparisons with

surrounding tissue Calibration …

Hundreds of new agents could lead to hundreds of new 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.


Reading Rooms at U. of Maryland

9/8/2010Lawrence Tarbox, Ph.D. 5

Nuclear Med

PET/CT

Images courtesy Eliot Siegel

No single workstationprovides all needed functions

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


Stakeholder Concerns

Users Want one workstation that supports any

needed functionality IT Administrators

Tired of changing infrastructure to accommodate new workstations simply to add functionality

Application Developers Do not have time to customize

applications for each of the dozens of vendor systems 12/5/2008Lawrence Tarbox, Ph.D. 7

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

Typical Plug-in Concept

…A

E

B C D

F


DICOM WG-23 Goal

Portable applications that ‘plug into’ any host that implements the standardized ‘socket’

Syngo

Cedara

caBIG

Advantage

Agfa

any WG23 Host


Use Case – CAD/Screening Applications

‘Plug-in’ applications are fed sets of DICOM objects to analyze, from which they produce DICOM Evidence Documents

‘Plug-ins’ could run on a common server on the central archive on a manufacturer-supplied server as a remote service


Use Case – SOP-Specific Post Processing

New or Private SOP classes may be unknown to a workstation e.g. Radial IVUS images

Workstations could look for a ‘plug-in’ application that does know how to handle the unknown SOP Class


Use Case – Mammography Image Storage

Desire to archive both raw and processed data Processed data to show what was

used for the diagnostic report Raw data for potential future

enhancements No desire to double storage

requirements!

Solution – store raw plus reference to a processing application


Use Case – Multi-site Trials/Research

Need to perform the same analysis on images collected at multiple sites

Sites have multiple working environments

Trial coordinator would like to create a single analysis package that could be run at all sites

By constraining the analysis, measurement variability is reduced


Other Use Cases

Customized Reporting and Display Site-specific reports

Print Composing Custom printing across multiple systems

Analysis of Image Data in Repositories Often faster to move apps to the data

than to move the data to the apps

… 9/8/2010 16Lawrence Tarbox, Ph.D.

Speed Up the Translation from Research to Clinical Practice

“Clinical applications of image analysis have lagged far behind the technologies that have been developed in academic and even industrial laboratories. A substantial portion of this gap, in my view, has arisen from the difficulties of migrating new techniques from offline research workstations into the flow of actual clinical practice. … “

“Because application hosting has the potential to make the migration process substantially easier, I expect and hope that we will see many new applications in the clinic, and that the effort [WG-23 has] initiated will, over the next three to five years, transform daily practice in many areas of medical imaging.”

– David Haynor, MD, PHD, Univ. of Washington


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.


Application Hosting

Utilizes Web Services Description Language and XML Schemas to define the interfaces between a “Hosting System” (e.g. a PACS workstation) and a “Hosted Application” (e.g. a CAD application)

Utilizes XPath and XML Infoset concepts to access selected portions of DICOM objects

Commonly available tools can be used to implement the interfaces

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 bindings12/5/2008 22Lawrence Tarbox, Ph.D.

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)12/5/2008 24Lawrence Tarbox, Ph.D.

Pushing for Adoption

Standardization being done via DICOM with participation from both medical imaging vendors and users

Open-source, commercial friendly reference implementations being created XIP – the eXtensible Imaging Platform

(Java) CTK – the Common Tool Kit (C++)

WG-23 participants (vendors and the XIP developers) have been exchanging test implementations to insure interoperability


Current Status

DICOM Supplement 118 “Application Hosting” holds the API and model definitions Passed letter ballot Final text edits approved Publication in progress

Commercial implementations appearing Closed-source toolkits, free to app

developers Products, some announced, others

rumored, that support DICOM Application Hosting


Regulatory Issues

In general, FDA regulates entire devices, not portions of devices. Testing is of entire system Adding a ‘plug-in’ changes the system Impact analysis, risk assessment,

targeted retest Proposal is to create a framework for

communicating verification/validation status For example, digital signature certifying

application X was tested with host Y Hosting System decides whether it is OK

to run


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

Unix, Mac, PC Internet ServerCommercial Vendor #2

…Commercial Vendor #1

Clinical Prototype & Collaboration

XIP developed

Application

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 Host™ DICOM Application Hosting APIs Sample Applications XIP Libraries™

XIP Development Tools XIP Builder™

The top 4 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 Builder Tool

XIP Class Library Auto Conversion Tool

Host-Specific Plug-in Libs

WG23

Distribute

ITK

VTK

XIP

LIB

. . .

XIP Development Process


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


The XIP Builder tool can be used to test and debug the

scene graph



Application Developer

controls the scene graph by creating a GUI program (e.g.

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

DICOM Application Hosting introduces a new paradigm for writing and distributing medical imaging applications

The DICOM Application Hosting interfaces allow those applications to run on any workstation that supports the standard interfaces XIP™ includes a reference host

implementation Other implementations now exist Products are beginning to appear


More Info

DICOM Supplement 118 “Application Hosting” can be downloaded from http://dicom.nema.org

Additional information about XIP™ as well as downloadable software is available at http://www.OpenXIP.org

Please feel free to e-mail me at [email protected] if you have questions


http://dicom.nema.org/

http://www.openxip.org/

mailto:[email protected]

Date post:	25-Dec-2015
Category:	Documents
Upload:	shana-kelly
View:	215 times
Download:	0 times