1. MHD-I: The Future Brad Genereaux February 2014

2. Agenda Review summary of original scope Review summary of high level feedback Highlight five different directions Proposed (and prepared) option Two high level questions Introduction to MHD-I MHD-I Profile Review

3. Original Scope RESTful access to XDS-I repositories A separate profile – Not an option on XDS-I profile Read only access Simple JSON data format – Not based on QIDO data model (at the time, work was underway in DICOM standard, not approved) Modelled after trial MHD profile and extended

4. Feedback from November’s F2F Don’t like it is tied to “mobile”; it will work across all platforms Don’t like that it is restricted to just XDS-I repositories; it should also provide access to normal DICOM repositories – Desire to bring QIDO-RS to Connectathon Don’t like that it is tied to MHD; that profile is not stable and won’t be for some time

5. Five Options for Moving Forward Discussions with some stakeholders - – DICOMweb and XDS-I scenarios One profile, two providers, one consumer One profile, one provider, one consumer Two separate profiles – Just XDS-I scenarios FHIR XDS-I.c

6. One Profile: Two providers, One consumer Create a new profile, modelled after ARI (Access to Radiology Information), called WARI (W = Web) One consumer, two possible providers (DICOMweb QIDO-RS, and RESTful XDS-I format defined by profile) Same query to both providers, but different response PRO: Logically separated for the provider CON: Burden placed onto consumer who must cope with two different data formats

7. One Profile: One provider, One consumer Have only one consumer, and one provider, and one data type (QIDO-RS) Still connects to XDS-I, but as a named option with details on how to map queries PRO: Much easier for the consumer CON: Much harder for an XDS Registry to conform

8. Two Separate Profiles Create a QIDO-RS based profile Create an XDS-I based profile for RESTful access PRO: Straight-forward and logically separated CON: A consumer wishing to use both methods have to implement both profiles

9. FHIR using ImagingStudy It has already made a link to possibly serving up XDS-I resources PRO: For XDS-I REST response, data format already specified CON: FHIR not stable, FHIR not necessarily suited for DICOM-based systems, FHIR child objects (i.e., patient) unnecessarily complicated for use cases, some information not available to XDS-I unless objects are pulled

10. XDS-I.c Natural evolution of the XDS-I profile PRO: Feels like a complete solution, more buy-in from implementers CON: Bolder than initial scope, not necessarily an “extension” of XDS

11. Proposed Option (that I have Prepared) One profile for MHD-I (for XDS-I) – True to both original scope, and to desire from last F2F meeting – Add WADO-RS to this profile – MHD-I title will stand QIDO-RS will be shelved for a future profile proposal

12. INTRODUCTION TO MHD-I

13. MHD-I Key Points