1 / 13

MHD-I: The Future

MHD-I: The Future. Brad Genereaux February 2014. 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. Original Scope.

leena
Download Presentation

MHD-I: The Future

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

More Related