1 / 31

Application Hosting

This project aims to create a mechanism for launching and running medical imaging applications on different systems, as well as exchanging information about those applications. It supports both research and clinical environments.

eshelley
Download Presentation

Application Hosting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related