1 / 37

Application Hosting

Lawrence Tarbox, Ph.D. Washington University in St. Louis School of Medicine Mallinckrodt Institute of Radiology, Electronic Radiology Lab. Application Hosting. Provocative Statement.

eyal
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. Lawrence Tarbox, Ph.D.Washington University in St. Louis School of MedicineMallinckrodt Institute of Radiology, Electronic Radiology Lab Application Hosting Lawrence Tarbox, Ph.D.

  2. Provocative Statement DICOM WG-23 hopes to fundamentally change the way the medical imaging world thinks in regards to the distribution and deployment of medical imaging applications. Lawrence Tarbox, Ph.D.

  3. The 1st 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 could lead to hundreds of new applications! Lawrence Tarbox, Ph.D.

  4. Status Quo • Medical imaging workstations generally are closed systems. • There is no common, standardized method for adding new functionality to a medical workstation. • The key stakeholders who wish to see new functionality added often are not the workstation provider. • New ‘cool’ tools often require adding entire workstations to a site’s infrastructure. Lawrence Tarbox, Ph.D.

  5. Reading Rooms at U. of Maryland Nuclear Med No single workstationprovides all needed functions Images courtesy Eliot Siegel PET/CT Lawrence Tarbox, Ph.D.

  6. From the SIIM 2007 Workflow Demonstrations • Cardio Workflow – Dr. AnwerQuershi “… going back and forth to various workstations and the use of different equipment is disruptive and slows treatment …” • Nuclear Workflow – Dr. Eliot Siegel “... This case illustrates the disruptions that can be introduced due to multiple systems and the need to go back and forth. ...” Lawrence Tarbox, Ph.D.

  7. Stakeholder Concerns • Users • Want one workstation that supports any needed functionality • IT Administrators • Tired of changing infrastructure to accommodate new workstations simply to add functionality • Application Developers • Do not have time to customize applications for each of the dozens of vendor systems Lawrence Tarbox, Ph.D.

  8. A Brave New World? Separate the provision of infrastructure from the application. • Infrastructure providers concentrate on the movement and storage of data and results, and on workflow management. • Application providers concentrate on the processing and analysis of that data, providing results back to the infrastructure. Minimize the ‘reinvention of the wheel’. Lawrence Tarbox, Ph.D.

  9. Proposed Solution • Create a mechanism where applications written by one party could be launched and run on systems created by multiple other parties. • Allow launched applications to efficiently access images and other resources controlled by the hosting system. • Provide a framework for exchanging information about those applications. • Support both research and clinical environments. Lawrence Tarbox, Ph.D.

  10. A B C D E F Typical Plug-in Concept Lawrence Tarbox, Ph.D.

  11. any WG23 Host caBIG Agfa Syngo Cedara Advantage DICOM WG-23 Goal Portable applications that ‘plug into’ any host that implements the standardized ‘socket’ Lawrence Tarbox, Ph.D.

  12. Use Case – CAD/Screening Applications • ‘Plug-in’ applications are fed sets of DICOM objects to analyze, from which they produce DICOM Evidence Documents • ‘Plug-ins’ could run • on a common server • on the central archive • on a manufacturer-supplied server • as a remote service Lawrence Tarbox, Ph.D.

  13. Use Case – SOP-Specific Post Processing • New or Private SOP classes may be unknown to a workstation • e.g. Radial IVUS images • Workstations could look for a ‘plug-in’ application that does know how to handle the unknown SOP Class Lawrence Tarbox, Ph.D.

  14. 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 Lawrence Tarbox, Ph.D.

  15. 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 • By constraining the analysis, measurement variability is reduced Lawrence Tarbox, Ph.D.

  16. Other Use Cases • Customized Reporting and Display • Site-specific reports • Print Composing • Custom printing across multiple systems • Analysis of Image Data in Repositories • Often faster to move apps to the data than to move the data to the apps • … Lawrence Tarbox, Ph.D.

  17. Speed Up the Translation from Research to Clinical Practice “Clinical applications of image analysis have lagged far behind the technologies that have been developed in academic and even industrial laboratories.  A substantial portion of this gap, in my view, has arisen from the difficulties of migrating new techniques from offline research workstations into the flow of actual clinical practice.   …   “  “Because application hosting has the potential to make the migration process substantially easier, I expect and hope that we will see many new applications in the clinic, and that the effort [WG-23 has] initiated will, over the next three to five years, transform daily practice in many areas of medical imaging.” – David Haynor, MD, PHD, Univ. of Washington Lawrence Tarbox, Ph.D.

  18. Idealized Goals A Standardized API that is: • Easy to learn and use • Language independent • Platform independent • Based on publicly available technology • Extensible • Secure Lawrence Tarbox, Ph.D.

  19. Reality Check “Life is a compromise” • Language and platform independence often translates into reduced performance. • Choice of development environment often restricts portability. The real goal is to come as close to the ideal as practical, and minimize the impact where we fall short. Take one step at a time. Lawrence Tarbox, Ph.D.

  20. Application Hosting • Utilizes Web Services Description Language and XML Schemas to define the interfaces between a “Hosting System” (e.g. a PACS workstation) and a “Hosted Application” (e.g. a CAD application) • Utilizes XPath and XML Infoset concepts to access selected portions of DICOM objects • Commonly available tools can be used to implement the interfaces

  21. 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 Lawrence Tarbox, Ph.D.

  22. Targets for Stage One • Basic Launch and Control of a Hosted Application • Load, Unload, Start, Abort • Simple Interchange of Data Between a Hosting System and Hosted Applications • File-based data exchange for existing applications • Model-based data exchange for new applications • Manual Configuration • Java and .net technology bindings Lawrence Tarbox, Ph.D.

  23. Model-Based Data Exchange AbstractData Subset DataObjects Conversion FullNativeData Bulk Data(e.g. voxels) Lawrence Tarbox, Ph.D.

  24. Abstract vs. Native Models • Abstract Models • Includes data common to multiple formats (e.g. DICOM, Analyze) • Application need not know the format of the native data • Does include references to the native data from which the abstract model was derived • Native Models • Gives full access to all information available in the native data • Allows an application to just access those parts of the native data that are of interest • Bulk Data Access • File name (URI) plus offset (for performance) Lawrence Tarbox, Ph.D.

  25. Pushing for Adoption • Standardization being done via DICOM with participation from both medical imaging vendors and users • Open-source, commercial friendly reference implementations being created • XIP – the eXtensible Imaging Platform (Java) • CTK – the Common Tool Kit (C++) • WG-23 participants (vendors and the XIP developers) have been exchanging test implementations to insure interoperability Lawrence Tarbox, Ph.D.

  26. Current Status • DICOM Supplement 118 “Application Hosting” holds the API and model definitions • Passed letter ballot • Final text edits approved • Publication in progress • Commercial implementations appearing • Closed-source toolkits, free to app developers • Products, some announced, others rumored, that support DICOM Application Hosting Lawrence Tarbox, Ph.D.

  27. Regulatory Issues • In general, FDA regulates entire devices, not portions of devices. • Testing is of entire system • Adding a ‘plug-in’ changes the system • Impact analysis, risk assessment, targeted retest • Proposal is to create a framework for communicating verification/validation status • For example, digital signature certifying application X was tested with host Y • Hosting System decides whether it is OK to run Lawrence Tarbox, Ph.D.

  28. WG23 / XIP Relationship • WG-23 addresses clinical integration and vendor inter-operability by defining standardized “plugs” and “sockets” (APIs) • caBIG XIP addresses an open-architecture, open-source, integrated environment for rapid application development based onWG 23 APIs XIP developed Application Standard API … Commercial Vendor #1 Commercial Vendor #2 Unix, Mac, PC Internet Server  Prototype & Collaboration   Clinical  Lawrence Tarbox, Ph.D.

  29. What is the ? • The eXtensible Imaging Platform (XIP™) is the image analysis and visualization tool for caBIG. • XIP is an open source environment for rapidly developing medical imaging applications from an extensible set of modular elements. • XIP may be used by vendors to prototype or develop new applications. • Imaging applications developed by research groups will be accessible within the clinical operating environment, using a new DICOM Plug-in interface first implemented in XIP. • XIP serves as a reference implementation of the DICOM WG-23 Application Hosting interfaces. Lawrence Tarbox, Ph.D.

  30. Major Parts of the • XIP Host™ • DICOM Application Hosting APIs • Sample Applications • XIP Libraries™ • XIP Development Tools • XIP Builder™ The top 4 combine to form an XIP Workstation Lawrence Tarbox, Ph.D.

  31. XIP Builder Tool Medical Imaging Workstation XIP Development Process Distribute XIP Application XIP Modules Host Independent Web-based Application XIP Host Adapter XIP LIB ITK VTK . . . Distribute WG23 WG23 WG23 WG23 XIP Host (Can be replaced with any DICOM WG23-compatible Host) Host-Specific Plug-in Libs DICOM, HL7, & otherservices per IHE caGRID Services viaImaging Middleware Distribute Standalone Application XIP Class Library Auto Conversion Tool Lawrence Tarbox, Ph.D.

  32. An Application Developer may use the XIP Builder tool from Siemens Corporate Research to create the app’s scene graph and processing pipelines from XIP Libraries Lawrence Tarbox, Ph.D.

  33. The XIP Builder tool can be used to test and debug the scene graph Lawrence Tarbox, Ph.D.

  34. Application Developer controls the scene graph by creating a GUI program (e.g. via Java Swing) Lawrence Tarbox, Ph.D.

  35. Host • Provides the infrastructure in which XIP or DICOM WG-23 Applications run • Authenticates user • Manages installation, launching, and termination of XIP Applications • Provides data and services to XIP Applications • Accepts status information and results back from XIP Applications • Deals with auditing and controls access to services and data • Isolates the XIP application from the nature of databases, archives, networks, and possibly image data formats • Manages access to DICOM networks, objects, and services • Creates Abstract Models from input data • Handles workflow issues • IHE General Purpose Worklist support • Supports any application that follows the DICOM WG-23 Application Hosting Interface Standard Lawrence Tarbox, Ph.D.

  36. Summary • DICOM Application Hosting introduces a new paradigm for writing and distributing medical imaging applications • The DICOM Application Hosting interfaces allow those applications to run on any workstation that supports the standard interfaces • XIP™ includes a reference host implementation • Other implementations now exist • Products are beginning to appear Lawrence Tarbox, Ph.D.

  37. More Info • DICOM Supplement 118 “Application Hosting” can be downloaded from http://dicom.nema.org • Additional information about XIP™ as well as downloadable software is available at http://www.OpenXIP.org • Please feel free to e-mail me at TarboxL@mir.wustl.edu if you have questions Lawrence Tarbox, Ph.D.

More Related