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. … A B C D E F Typical Plug-in Concept

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

7. SPECT SPECT MR MR CT CT PET PET PACS PACS PACS SPECT SPECT MR MR CT CT PET PET Image Workstation Image Workstation Plug Plug - - in Extension in Extension Molecular Imaging Plug Molecular Imaging Plug Molecular Imaging Plug - - - in Server in Server in Server -- -- -- Agent Specific Acquisition/Recon Agent Specific Acquisition/Recon Agent Specific Acquisition/Recon -- -- -- Agent Specific Image Analysis Agent Specific Image Analysis Agent Specific Image Analysis 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 versusOpen 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 versusOpen 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. Custom Research/University Prototype OEM Classes(e.g. watsyn™, IDL) Custom Classes Prototype Plug-In Development Environment API (Plug) API (Socket) Hosting System (e.g. Medical Workstation) Research Support

19. API (Plug) API (Socket) Hosting System (e.g. Medical Workstation) 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 • HostedApplication startup(HostingSystem host) • StatuscreateJob(DicomObject [] objects) • voidcancel() • Statusshutdown() How the Host System communicates with the Hosted Application

28. HostingSystem Interface • Object []getConfigurationParameters () • voidprogressUpdate (String message, JobStatus status, DicomObject [] intermediate_objects) • StringcreateUID () • statusresultsReturn (DicomObject [] result_objects) • statusjobComplete () How the Hosted Application communicates with the Hosting System

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 • Define Use Cases • Derive Requirements • Review available technology • Create draft for public comment • Freeze for trial use • Revise after feedback from implementers • 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)