1. Lawrence Tarbox, Ph.D. Washington University in St. Louis School of Medicine Mallinckrodt Institute of Radiology, Electronic Radiology Lab 12/1/2009 1 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. 12/5/2008 2 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! 12/1/2009 3 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. 12/5/2008 4 Lawrence Tarbox, Ph.D.

5. Reading Rooms at U. of Maryland 9/8/2010Lawrence Tarbox, Ph.D. 5 Nuclear Med PET/CT Images courtesy Eliot Siegel

6. From the SIIM 2007 Workflow Demonstrations  Cardio Workflow – Dr. Anwer Quershi “… 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....” 12/5/2008 6 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 12/5/2008Lawrence Tarbox, Ph.D. 7

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’. 12/5/2008 8 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. 12/5/2008 9 Lawrence Tarbox, Ph.D.

10. Typical Plug-in Concept … A E BCD F 12/5/2008 10 Lawrence Tarbox, Ph.D.

11. DICOM WG-23 Goal Portable applications that ‘ plug into ’ any host that implements the standardized ‘ socket ’ Syngo Cedara caBIG Advantage Agfa any WG23 Host 12/5/2008 11 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 12/1/2009 12 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 12/1/2009 13 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 12/1/2009 14 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 12/1/2009 15 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  … … 9/8/2010 16 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 12/1/2009Lawrence Tarbox, Ph.D. 17

18. Idealized Goals A Standardized API that is:  Easy to learn and use  Language independent  Platform independent  Based on publicly available technology  Extensible  Secure 12/5/2008 18 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. 12/5/2008 19 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 12/5/2008 21 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 12/5/2008 22 Lawrence Tarbox, Ph.D.

23. Model-Based Data Exchange Data Objects Conversion Bulk Data (e.g. voxels) Abstract Data Subset Full Native Data 12/5/2008 23 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) 12/5/2008 24 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 9/8/2010 25 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 9/8/2010Lawrence Tarbox, Ph.D. 26

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 12/1/2009Lawrence Tarbox, Ph.D. 27

28. WG23 / XIP Relationship WG-23 addresses clinical integration and vendor inter-operability by defining standardized “plugs” and “sockets” (APIs) 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 on WG 23 APIs caBIG XIP addresses an open- architecture, open-source, integrated environment for rapid application development based on WG 23 APIs Unix, Mac, PCInternet ServerCommercial Vendor #2 … Commercial Vendor #1  Clinical   Prototype & Collaboration  XIP developed Application Standard API 12/5/2008 28 Lawrence Tarbox, Ph.D.

29.  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. What is the ? 12/5/2008 29 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 12/5/2008 30 Lawrence Tarbox, Ph.D.

31. XIP Application (Can be replaced with any DICOM WG23- compatible Host) XIP Host Adapter XIP Modules Host Independent WG 23 XIP Host WG 23 Web-based Application Medical Imaging Workstation Standalone Application Distribute DICOM, HL7, & other services per IHE caGRID Services via Imaging Middleware XIP Builder Tool XIP Class Library Auto Conversion Tool Host-Specific Plug-in Libs WG 23 Distribute ITKVTK XIP LIB... XIP Development Process 12/5/2008 31 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 12/5/2008 32 Lawrence Tarbox, Ph.D.

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

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

35. 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 12/5/2008 35 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 12/5/2008 36 Lawrence Tarbox, Ph.D.

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