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 mirror the Mobile access to Health Documents (MHD) profile for Cross Document Sharing (XDS) for XDS-I, by defining a simple HTTP interface and structure for retrieving manifest/study information. By approaching this in an interoperable way, accessibility to XDS-I repositories is improved, both cross-vendor and cross-client.

The Problem

Participating as a client in XDS-I is straight-forward in a controlled, robust, server/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 consult urgently on a patient with an acute condition, and needs to review the patient's images remotely. 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 what imaging data for the patient is available, and if any is available, to access it.

Using MHD-I, the EHR web page content, acting as the MHD-I client ("Imaging Document Consumer"), queries the MHD-I provider ("Imaging Document Responder") for imaging studies for the patient. A list of image instances is returned with their WADO-URL or WADO-RS locations, which the EHR web page content can retrieve and render for the physician. How this is done is not specified by MHD-I, but some methods may include directly performing a client or server side rendering from the WADO-URL/WADO-RS calls, or by building an IHE IID request from the information returned.

The list of instances and the images themselves comes from an XDS Document Registry, Document Repository and an XDS-I Imaging Document source, to which the MHD-I services act as a proxy.

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-URI: ftp://medical.nema.org/medical/dicom/2011/11_18pu.pdf
    • 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 XDS-I profile, except that all transactions will be replaced with RESTful equivalents from IHE ITI MHD profile, and additional transactions will be defined to describe the specialized payload.

HTTP requests will be used to obtain a list of JSON-encoded Manifests for a particular set of query parameters from the responder, using a RESTful syntax.

When retrieving a particular imaging study, XDS-I provides a binary DICOM KOS object. In the environments that MHD-I would be used, this binary object is unwieldy to process, and a JSON encoded equivalent is desirable. Ideally this would be constrained to only the relevant content of an XDS-I DICOM KOS manifest, rather than being a literal transcoding of the entire DICOM content into JSON (as might be the case if the current WG-27 QIDO JSON encoding were used; see open issue below).

MHD defines four transactions - Find Document Dossiers [ITI-67], Get Document Dossier [ITI-66], Get Document [ITI-68], and Put Document Dossier [ITI-65]. An MHD Dossier is more or less equivalent to an XDS Document Set. For the time being, submission is out of scope, so the Put Document Dossier [ITI-65] transaction is not relevant. MHD-I will re-use the existing Find Document Dossiers [ITI-67] and Get Document Dossier [ITI-66] without specialization (this allows other documents, such as reports, to also be referenced in the Dossier). The Document Dossier retrieved with ITI-66 may contain multiple documents, one of which may be a JSON-encoded MHD-I Manifest, in which case a new Get Imaging Manifest [RAD-x1] transaction may be used to retrieve the Imaging Manifest. Get Imaging Manifest [RAD-x1] mirrors Get Document [ITI-68] but is constrained to return only an MHD-I Manifest.

Once the Manifest has been retrieved, various options exist for using it, depending on whether the client (Imaging Document Consumer) is a viewer that requires the images, whether those images are to be rendered client or server side (DICOM or JPEG payload required, respectively), or whether the client wants to request a viewer be invoked by some other actor (via IID). What the client does with the response is not defined in MHD-I, and left to the implementor.

The existing XDS-I WADO Retrieve [RAD-55] transaction (which DICOM now refers to as WADO-URI) is capable of returning either DICOM or JPEG payloads, and suffices for many use cases. The new DICOM-RS services may also be appropriate, particularly if meta-data or separate binary bulk-data retrieval is required, and an open issues is whether or not to add to this profile a new transaction for WADO-RS Retrieve [RAD-x2].

It is probably not necessary to include support for the existing DICOM DIMSE services for retrieval (Retrieve Images [RAD-16]), since any mobile client (e.g., a thick client "app") that can perform a C-MOVE and C-STORE can use a C-FIND instead of a RESTful web or XDS-I transaction. The one retrieval mechanisms that is out of scope is the XDS-I.b Retrieve Imaging Document Set [Rad-69] (WADO-WS) transaction, since the point of this profile is not to burden the mobile device with SOAP-based web services.

It would be possible for a mobile client to use IID to invoke a viewer instead of acting as a viewer itself, but this profile would be of little use in this scenario, given the matching capabilities of IID itself, except perhaps as a means of discovering an IID end-point that may be implicit in the URL information for the instances in the Manifest and not otherwise known.

For the time being, the cross-community access equivalent of XCA-I (which depends on the SOAP-based RAD-69 transaction to span communities with different identifiers) is out of scope, though the lessons learned from developing XCA-I will be considered when defining the MHD-I transactions so as not to preclude XCA-MHD-I in the future.

Existing actors

• Imaging Document Consumer

New actors

• Imaging Document Responder: This actor can be considered a proxy for an XDS-I Document Registry, Document Repository and Imaging Document Source

Existing transactions

• Find Document Dossiers [MHD ITI-67]
• Get Document Dossier [MHD ITI-66]

New transactions (standards used)

• Get Imaging Manifest [RAD-x1]: Specializes Get Document [MHD ITI-68] to returns a JSON-encoded equivalent of the XDS-DICOM KOS Manifest
• WADO-RS Retrieve [RAD-x2]: Retrieve instances using WADO-RS instead of WADO-URI or WADO-WS

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

• MHD-I

Breakdown of tasks that need to be accomplished

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

Risks

• There is a possibility that the proposed DICOM JSON may change, but a new manifest-specific encoding is probably needed anyway
• DICOM WG-27 is addressing the lack of describing KOS objects RESTfully, and aligning with this approach may be important in the future
• MHD is being reviewed and may be updated due to enhanced FHIR integration

Open Issues

• MHD defines a secondary response type based on an XML ATOM-like structure. Should MHD-I include that? Currently, that answer is no.
• The JSON encoding of the Manifest returned by the Get Imaging Manifest remains to be determined (e.g., whether the WG-27 QIDO response encoding should be re-used, or not; what of the FHIR ImagingStudy resource as an alternative).
• The use of WADO-RS permits more complex scenarios, such as to retrieve an entire imaging study with one request, which may or may not be appropriate for a mobile device; does the additional complexity warrant requiring the responder to support it, as opposed to depending on WADO-URI only? For this case, do we assume that WADO-URI and MHD-I are sourced from the same server?
• Is there value in providing a means of explicitly retrieving thumbnails only? Or, can we rely/recommend on using WADO-URI to somehow provide this service?
• 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 (obtaining demographics and orders) and the lower priority relative to retrieval.
• XDS-I specifies that reports can be included, as CDA or PDF format. How should they be represented in MHD-I? (i.e., by examining the document association, or by using a returned accession number to then query an MHD peer server)
• MHD (not I) has seen very limited adoption so far (only one vendor at Connectathon). If we model MHD-I on MHD there is a risk that MHD might get tweaked to encourage adoption.

• MHD-I is more based on WADO-RS than on FHIR (like MHD), so while we want to be aligned with XDS/MHD, we are slightly buffered
• If we move forward we should talk to ITI to stay in the loop on their plans
• Some of the implementers of Mobile may be small/in-house at hospitals with preliminary implementations, who might be less likely to come to connectathon but they still depend on the profile.
• Perhaps we should cast it as MAI or Mobile ARI and isolate it from MHD. This tactical choice should be resolved through discussion with ITI early in the profiling process. Also need to be clear about the relation to IID.
• Don't lose track of the primary use cases/workflows though. How do we envision this being used in the healthcare system?
• Also need to engage the "IHE Mobile Task Force".

Tech Cmte Evaluation

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

• 25% (30% if extended to include XCA)

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Brad G.