Mobile access to Health Documents for Imaging - Detailed Proposal

Proposed Profile: Mobile access to Health Documents for Imaging

• Proposal Editor: Brad Genereaux
• Profile Editor: Brad Genereaux
• Other Contributors: David Clunie, Kinson Ho
• Domain: Radiology

Summary

XDS-I provides a method to share imaging documents across enterprises by a query and retrieve mechanism, but the technology is burdensome for lightweight web and mobile clients. The combination of XDS-I and MHD profiles with DICOMweb RESTful services provides the framework to resolve the barriers for mobile access. This proposal calls for the creation of a profile to mimic the Mobile access to Health Documents (MHD) profile for Cross Document Sharing (XDS) for XDS-I, by defining a simple HTTP interface. By approaching this in an inter-operable way, access to XDS-I repositories can truly become universal, cross-vendor and cross-client.

The Problem

Participating as a client in XDS-I is straight-forward in a controlled, robust, server or desktop configuration. There are libraries that exist that can make MTOM/XOP requests for manifests with DICOM KOS parsers for SOP instance retrieval. However, in environments that are HTML5 web-based or where processing resources or bandwidth are constrained, the XDS mechanisms simply do not work effectively. There needs to be a lightweight mechanism to simply request, retrieve, and parse the manifest without putting undue pressure on the client. The client, in this case, is browser-based and capable of making HTTP requests and parsing web-friendly formats, like XML and JSON.

By not solving this problem, vendors are forced to either not serve up this data at all to this particular segment of audience, or to provide a proprietary server-client solution, one that likely would not be interoperable with other solutions.

Key Use Case

A physician, away from the hospital, is asked to provide a preliminary review of a patient's file of who is in crisis. He launches the electronic health record (EHR) web application on his mobile device, authenticates, and then opens the particular patient's record. He reviews documents regarding the patient stored in his facility’s XDS repository using MHD, and now would like to know if imaging data for the patient is available.

Using MHD-I, the EHR web page, acting as the MHD-I client, makes a query for studies available for the patient to the MHD-I provider. A list of instances are returned with WADO-RS locations to retrieve the relevant instances, which the EHR website can retrieve and render for the physician (either directly, or through building an IHE-IID style URL call from the information returned). The list of instances provides enough information for the physician to determine if retrieval is warranted. This list comes from the XDS-I repository.

Standards & Systems

• Standards:
  • XDS-I, XDS-I.b: http://wiki.ihe.net/index.php?title=Cross-enterprise_Document_Sharing_for_Imaging
  • MHD: http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_MHD.pdf
  • DICOMweb services
    • WADO-RS: ftp://medical.nema.org/medical/dicom/final/sup161_ft.pdf
    • DICOMweb JSON format (found in QIDO-RS, currently in ballot): ftp://medical.nema.org/medical/dicom/supps/LB/sup166_lb.pdf
  • JSON: http://www.ietf.org/rfc/rfc4627.txt
  • HTTP: http://www.ietf.org/rfc/rfc2616.txt
  • IID: http://www.ihe.net/Technical_Framework/upload/IHE_RAD_Suppl_IID.pdf
• Systems:
  • Electronic Health Record (EHR) systems and Patient Health Record (PHR) systems
  • XDS-I Repositories
  • Web-based / mobile imaging study viewers

Technical Approach

The approach will follow the same framework as the IHE ITI MHD profile, by using similar constructs (introducing a "responder" actor, who is essentially a proxy to a full XDS-I repository). The consumer will request, over HTTP, a list of studies for a particular patient identifier from the responder, using a RESTful syntax. The responder will provide a response, using JSON, over HTTP, a list of available artifacts for the patient.

When retrieving a particular imaging study, XDS-I provides a DICOM KOS object. In the environments that MHD-I would be used, this binary object would not be of much use - and thus, a JSON rendition is suitable. Wherever possible, DICOMweb-style JSON should be selected as the format of the returned content. DICOM WG-27 may introduce a KOS format which could also be used.

MHD defines four transactions - Find Document Dossiers, Get Document Dossier, Get Document, and Put Document Dossier. MHD-I will only mirror Find Imaging Study Dossiers (which will mirror ITI-67), and Get Imaging Study Dossier (which will mirror ITI-66). A "Get Imaging Study" transaction (which could mirror ITI-68) is less relevant as we don't necessarily know what the client wants to do with the DICOM instances (for example, WADO-RS to retrieve a particular rendition for preview or thumbnail, or IID to launch a mobile image viewer). These are left as open issues, and could be considered as part of a "phase 2" if there is significant interest.

Existing actors

• Imaging Document Consumer

New actors

• Imaging Document Responder: This actor can be considered a proxy for Document Repository

Existing transactions

• None

New transactions (standards used)

• Find Imaging Document Dossiers: This transaction takes some query metadata (patient ID, creation time) and responds with a list of imaging document dossier URLs
• Get Imaging Document Dossier: This transaction takes a particular imaging document dossier, and returns a rendition of details regarding that particular study (a JSON format of the stored DICOM KOS)

Impact on existing integration profiles

• XDS-I: This would supplement XDS-I with a RESTful web compatible methodology
• MHD: This would complement MHD with an imaging-centric retrieval methodology

New integration profiles needed

• None

Breakdown of tasks that need to be accomplished

• Review MHD profile to ensure coverage of imaging paradigms
• Account for possible changes with FHIR enhancements

Risks

• As with all these proposals, we should confirm the need/business case does exist for these profiles.
• Lack of Participation from vendors is a risk.
• There is a possibility that the proposed DICOM JSON may change.
• MHD is being reviewed and may be updated due to enhanced FHIR integration

Open Issues

• Currently, the structure of the "Query Imaging Study Dossiers" is intended to be built as MHD has defined it. However, would it make more sense to return a JSON response structured like QIDO-RS? Or FHIR's JSON ImagingStudy object (only returning the Study level)?
  • MHD defines a secondary response type based on an XML ATOM-like structure. Should MHD-I include that? Currently, that answer is no.
• Currently, the structure of the "Get Imaging Study Dossier" is intended to be based on the QIDO-RS JSON structure, with guidance from WG-27 on how to structure a KOS document (which should be made as part of a DICOM CP or work item this year). However, would it make more sense to use a structure like FHIR's JSON ImagingStudy object (with children)?
• Should a "Get Imaging Study" be defined, and simply use the WADO-RS standard? It doesn't seem likely that a mobile device would attempt to whole-handedly pull down an imaging study - something like IID seems much more likely, or a possible thumbnail grab.
• Should a "Put Imaging Study Dossier" be defined (as defined by MHD), or, a "Put Imaging Study" based on STOW-RS? It has been specifically left out due to the workflow complications and the less-likelihood that it would be important at this juncture.

Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• TBD

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA