Transcript Tarbox_Application Hosting.ppt

Application Hosting
Lawrence Tarbox, Ph.D.
Chair WG 23
Mallinckrodt Institute of Radiology
Washington University in St. Louis School of Medicine
1300
Motivation



To create a mechanism where
applications written by one party could
be launched and run on systems
created by multiple other parties
To create a framework for exchanging
information about those applications
To support both research and clinical
environments
Initial 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
anticipated
Problem



Stakeholders in developing such
agent-specific analysis applications
typically are not the vendors/creators
of the medical workstations
Little market incentive for medical
workstation vendors
Stakeholders do not want to develop
multiple versions of an application
Typical Plug-in Concept
A
B
C
E
…
D
F
Extended Plug-in Concept
A
A
A
A
B
C
…
D
A
E
Use Case – Agent-Specific Post Processing
MR
MR
CT
CT
PET
PET
SPECT
SPECT
Image Workstation
Plug-in Extension
Molecular Imaging Plug -in Server
-- Agent Specific Acquisition/Recon
-- Agent Specific Image Analysis
PACS
1. System
identifies
the agent
2. System selects
‘plug-in’ app based
on agent
3. ‘Plug-in’ app
performs agentspecific analysis
Use Case – SOP-Specific Post Processing

New or Private SOP classes may be
unknown to a workstation
– e.g. Radial IVUS images

Workstation could look for a ‘plug-in’
application that does know how to
handle the unknown SOP Class
Use Case – CAD/Screening Applications


‘Plug-in’ runs on a server that is fed
sets of DICOM objects to analyze, and
produces DICOM Evidence Documents
‘Plug-ins’ could run
– on the central archive
– on a manufacturer-supplied server
– as a remote service
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
Other Use Cases

Customized Reporting and Display
– Site-specific reports

Print Composing
– Custom printing across multiple systems

Analysis of Image Data in Repositories
– Faster to move apps than data

…
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

Meta-data XML Schema to Describe an Application
– Allows selection of appropriate applications
– Allows administrator to determine compatibility of host
system and hosted application

Basic Launch and Control of a Hosted Application
– Load, Unload, Start, Abort

Simple Interchange of Data Between a Hosting
System and Hosted Applications
– Data inputs and outputs described using DICOM Semantics
– DICOM messages/objects need not be used directly,
instead the API could give access to parts of the objects
Goals
A Standardized API that is:





Language independent
Platform independent
IP independent
Extensible
Secure
Open Interface Standard versus
Open Source
Analogy to traditional DICOM:
– The content and encoding of objects is
standard
– The means for transporting the objects
(e.g. the network) is standard
But …
– How to do the implementation is not
standard
Open Interface Standard versus
Open Source



Implementations of Open Standard
Interfaces can be Open Source or
proprietary
Implementations on either side of the
interface need not be created by the
same entity
Interoperability is gained by adherence
to the standard
Research Support
Custom Research/University Prototype
Custom Classes
OEM Classes
(e.g. watsyn™, IDL)
Prototype Plug-In Development Environment
API (Plug)
API (Socket)
Hosting System (e.g. Medical Workstation)
Commercialization
Hosted Application (Plug-in)
API (Plug)
API (Socket)
Hosting System (e.g. Medical Workstation)
Caution!
WARNING – What you
are about to see are
preliminary ideas that
may change at any
moment!
Application Description Document
App ID



Identification by name, version, etc.
Identification of functional categories
and possible sub categories.
Identification descriptively, so that a
person understands what the
application is.
Application Description Document
App Prerequisites


Hardware (memory required, swap
required, disk space required,
processor considerations, special
hardware, etc.)
Software environment (operating
system, libraries present, database
facilities, versions, etc.)
Application Description Document
App Installation



The executable portion of the Hosted
Application
Short (and long?) user manual ensured to
be available as part of the application.
A Hosted Application installer, which may be
provided as part of the Hosted Application
package or which may merely be identified
by the Hosted Application package.
Application Description Document
Parameters


Information equivalent to the DICOM
Conformance Claim, e.g. SOP Classes
accepted and produced, languages
and character sets, constrains on
combinations of datasets, etc.
Specific parameters that the Hosted
Application needs to execute (e.g.,
provided in a SR templates)
Application Description Document
Security



Application integrity check, by means
of digital hash, digital signature, or
similar techniques.
Verified or validated configurations,
e.g. “Confirmed to work on product X
version a.b”
Licensing information
Interfaces

Interfaces will be defined as
web-services or grid services
– Can be implemented in any language
– Can be local or remote
(initial focus is local)
– Is platform independent
HostedApplication
Interface
How the Host System communicates with the
Hosted Application




startup (HostingSystem host)
Status createJob (DicomObject [] objects)
void cancel ()
Status shutdown ()
HostedApplication
HostingSystem Interface
How the Hosted Application communicates
with the Hosting System





Object [] getConfigurationParameters ()
void progressUpdate (String message,
JobStatus status,
DicomObject [] intermediate_objects)
String createUID ()
status resultsReturn
(DicomObject [] result_objects)
status jobComplete ()
DICOMObject Interface


Information about how to access the
objects, but not the objects
themselves.
Multiple Access Styles possible:
– DICOM Network Access
– File-mapped DICOM
– Parsed DICOM

Access Styles negotiaged
Work Cycle
1.
2.
3.
4.
5.
6.
7.
Define Use Cases
Derive Requirements
Review available technology
Create draft for public comment
Freeze for trial use
Revise after feedback from implementers
Ballot
Volunteers Solicited
WG 23 welcomes your input. We
would be even happier with your
assistance in creating this new
standard.
– Join the mailing list and contribute ideas
– Join us at future meetings
(next is planned for April 26 in Austin
prior to SCAR)