130 likes | 272 Vues
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.
E N D
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 • 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
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
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
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
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
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
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
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
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