Application Hosting Lawrence Tarbox Ph D Chair WG

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

Motivation To create a mechanism where applications written by one party could be launched and run on systems created by multiple other parties n To create a framework for exchanging information about those applications n To support both research and clinical environments n

Initial Driver – Molecular Imaging n n n 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 – … n Hundreds of new agents anticipated

Problem Stakeholders in developing such agentspecific analysis applications typically are not the vendors/creators of the medical workstations n Little market incentive for medical workstation vendors n Stakeholders do not want to develop multiple versions of an application n

Typical Plug-in Concept A B C E … D F

Extended Plug-in Concept A A B C … D A E

Use Case – Agent-Specific Post Processing MR MR CT CT PET SPECT PACS 1. System identifies the agent 2. System selects ‘plug-in’ app based on agent 3. ‘Plug-in’ app performs agentspecific analysis Image Workstation Plug Extension -in Molecular Imaging Plug -in Server -- Agent Specific Acquisition/Recon -- Agent Specific Image Analysis

Use Case – SOP-Specific Post Processing n New or Private SOP classes may be unknown to a workstation – e. g. Radial IVUS images n 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 n ‘Plug-ins’ could run n – on the central archive – on a manufacturer-supplied server – as a remote service

Use Case – Mammography Image Storage n 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 n n 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 n Sites have multiple working environments n Trial coordinator would like to create a single analysis package that could be run at all sites n

Other Use Cases n Customized Reporting and Display – Site-specific reports n Print Composing – Custom printing across multiple systems n Analysis of Image Data in Repositories – Faster to move apps than data n …

Suggested Staging n n 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 n Meta-data XML Schema to Describe an Application – Allows selection of appropriate applications – Allows administrator to determine compatibility of host system and hosted application n Basic Launch and Control of a Hosted Application – Load, Unload, Start, Abort n 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 n Platform independent n IP independent n Extensible n Secure n

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 n Implementations on either side of the interface need not be created by the same entity n Interoperability is gained by adherence to the standard n

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 n n n 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. ) n Software environment (operating system, libraries present, database facilities, versions, etc. ) n

Application Description Document App Installation n 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 n n 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. n Verified or validated configurations, e. g. “Confirmed to work on product X version a. b” n Licensing information n

Interfaces n 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

Hosted. Application Interface How the Host System communicates with the Hosted Application n Hosted. Application startup (Hosting. System host) n Status create. Job (Dicom. Object [] objects) n void cancel () n Status shutdown ()

Hosting. System Interface How the Hosted Application communicates with the Hosting System n n n Object [] get. Configuration. Parameters () void progress. Update (String message, Job. Status status, Dicom. Object [] intermediate_objects) String create. UID () status results. Return (Dicom. Object [] result_objects) status job. Complete ()

DICOMObject Interface Information about how to access the objects, but not the objects themselves. n Multiple Access Styles possible: n – DICOM Network Access – File-mapped DICOM – Parsed DICOM n 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)