Application Hosting

1
Application Hosting

• Lawrence Tarbox, Ph.D.
• Chair WG 23
• Mallinckrodt Institute of Radiology
• Washington University in St. Louis School of
  Medicine

2
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

3
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

4
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

5
Typical Plug-in Concept
6
Extended Plug-in Concept

C
B
E
D
7
Use Case Agent-Specific Post Processing
2. System selects plug-in app based on agent

• Plug-in app performs agent-specific analysis

1. System identifies the agent
8
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

9
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

10
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

11
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

12
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

13
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

14
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

15
Goals

• A Standardized API that is
• Language independent
• Platform independent
• IP independent
• Extensible
• Secure

16
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

17
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

18
Research Support
19
Commercialization
Hosted Application (Plug-in)
20
Caution!
WARNING What you are about to see are
preliminary ideas that may change at any moment!
21
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.

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

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

24
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)

25
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

26
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

27
HostedApplication Interface
How the Host System communicates with the Hosted
Application

• HostedApplication startup (HostingSystem host)
• Status createJob (DicomObject objects)
• void cancel ()
• Status shutdown ()

28
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 ()

29
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

30
Work Cycle

1. Define Use Cases
2. Derive Requirements
3. Review available technology
4. Create draft for public comment
5. Freeze for trial use
6. Revise after feedback from implementers
7. Ballot

31
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)