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 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 create a framework for exchanging information about those applications To support both research and clinical environments To support both research and clinical environments

3. Initial Driver – Molecular Imaging A ‘bright dot’ in the image is not sufficient 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 Ideal is a quantitative number, with normal ranges derived from population, as now done in lab analysis Newer agents will require more sophisticated 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 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 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 Little market incentive for medical workstation vendors Stakeholders do not want to develop multiple versions of an application Stakeholders do not want to develop multiple versions of an application

5. Typical Plug-in Concept … A E BCD F

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

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

8. Use Case – SOP-Specific Post Processing New or Private SOP classes may be unknown to a workstation 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 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-in’ runs on a server that is fed sets of DICOM objects to analyze, and produces DICOM Evidence Documents ‘Plug-ins’ could run ‘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 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! No desire to double storage requirements! Solution – store raw plus reference to a processing application 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 Need to perform the same analysis on images collected at multiple sites Sites have multiple working environments Sites have multiple working environments Trial coordinator would like to create a single analysis package that could be run at all sites 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 Customized Reporting and Display –Site-specific reports Print Composing Print Composing –Custom printing across multiple systems Analysis of Image Data in Repositories 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 one – Access to DICOM Datasets and Results Recording Stage Two – Access to Non-Interactive Application Services (e.g. print, archive) 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 Three – Access to Interactive Application Services (e.g. GUI, ‘skins’, rendering) Stage Four – Standard Workflow Descriptions, and Interactions Between Hosted Software Stage Four – Standard Workflow Descriptions, and Interactions Between Hosted Software

14. Targets for Stage One Meta-data XML Schema to Describe an Application 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 Basic Launch and Control of a Hosted Application –Load, Unload, Start, Abort Simple Interchange of Data Between a Hosting System and Hosted Applications 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 Language independent Platform independent Platform independent IP independent IP independent Extensible Extensible Secure Secure

16. 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

17. Open Interface Standard versus Open Source Implementations of Open Standard Interfaces can be Open Source or proprietary 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 Implementations on either side of the interface need not be created by the same entity Interoperability is gained by adherence to the standard Interoperability is gained by adherence to the standard

18. Research Support Hosting System (e.g. Medical Workstation) API (Socket) Custom Research/University Prototype API (Plug) Custom Classes OEM Classes (e.g. watsyn™, IDL) Prototype Plug-In Development Environment

19. Hosting System (e.g. Medical Workstation) API (Socket) Commercialization API (Plug) 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 by name, version, etc. Identification of functional categories and possible sub categories. Identification of functional categories and possible sub categories. Identification descriptively, so that a person understands what the application is. 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.) Hardware (memory required, swap required, disk space required, processor considerations, special hardware, etc.) Software environment (operating system, libraries present, database facilities, versions, etc.) Software environment (operating system, libraries present, database facilities, versions, etc.)

23. Application Description Document App Installation The executable portion of the Hosted Application The executable portion of the Hosted Application Short (and long?) user manual ensured to be available as part of the 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. 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. 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) 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. 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” Verified or validated configurations, e.g. “Confirmed to work on product X version a.b” Licensing information Licensing information

26. Interfaces Interfaces will be defined as web-services or grid services 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) HostedApplication startup (HostingSystem host) Status createJob (DicomObject [] objects) Status createJob (DicomObject [] objects) void cancel () void cancel () Status shutdown () Status shutdown () How the Host System communicates with the Hosted Application

28. HostingSystem Interface Object [] getConfigurationParameters () Object [] getConfigurationParameters () void progressUpdate (String message, JobStatus status, DicomObject [] intermediate_objects) void progressUpdate (String message, JobStatus status, DicomObject [] intermediate_objects) String createUID () String createUID () status resultsReturn (DicomObject [] result_objects) status resultsReturn (DicomObject [] result_objects) status jobComplete () status jobComplete () How the Hosted Application communicates with the Hosting System

29. DICOMObject Interface Information about how to access the objects, but not the objects themselves. Information about how to access the objects, but not the objects themselves. Multiple Access Styles possible: Multiple Access Styles possible: –DICOM Network Access –File-mapped DICOM –Parsed DICOM Access Styles negotiaged Access Styles negotiaged

30. Work Cycle 1. Define Use Cases 2. Derive Requirements 3. Review available technology 4. Create draft for public comment 5. Freeze for trial use 6. Revise after feedback from implementers 7. 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)