What is MHD beyond XDS-on-FHIR?

I have been working on a Profile in IHE now for three years. It normally doesn’t take this long, but in my case I had the good luck of being the in the right place at the right time. I saw the tidal wave of “HTTP RESTful” coming, felt it strongly back when I was on “The Direct Project” creating a sub-optimal solution. At that time, IHE only had the XDS solution, which is based on Web-Services using SOAP, SAML, and ebRegistry. This XDS solution was and is still the best solution for business-to-business. However this solution is very hard to use if one is using programming tools more common on lightweight systems such as Mobile.

So back in 2011 I wrote the first profile in IHE that was targeting ‘ease of use by lightweight application platforms such as Mobile Health Applications”. Thus it targeted use of HTTP RESTful, using JSON encoding. The Mobile Health Documents (MHD) profile was born to provide a more simple API to an XDS environment. This happened to be the same timeframe that Grahame was fanning the FHIR flames. So we joined forces and brought the concepts needed for XDS into FHIR®. So now, I take those FHIR based Resources and re-write the profile.

Note there will be yet-another re-write (hopefully just tweaks) this summer after HL7 completes their DSTU2 ballot process. There are a set of gaps identified this winter that we have fixed in the proposed content for DSTU2.

The Mobile Health Documents (MHD) is the result.

Mobile Access to Health Documents (MHD) - Revised 2015-03-12

I am not going to go into deep details, but take the perspective here that the reader is a FHIR expert, and wants to understand this MHD profile. I will assume you also have some understanding of XDS, but only as an overall concept.

The basics are shown here.

The MHD abstract actors are:

Document Source - the producer and publisher of documents and metadata
Document Recipient - receives documents and metadata
Document Consumer - queries for documents metadata, and requests to retrieve documents
Document Responder - responds to requests for document metadata entries and documents.

The MHD abstract transactions are:

Provide Document Bundle - This transaction is used to transfer documents and metadata, and is analogous to a Provide and Register Document Set-b transaction.
Find Document Manifests – This transaction is used to provide parameterized queries that result in a list of Document Manifest resources.
Find Document References – This transaction is used to provide parameterized queries that result in a list of Document Reference resources.
Retrieve Document – This transaction is used to get documents.

MHD uses few FHIR Resources:

and

The MHD Profile enables many deployment models:

As and API to XDS environment

This is what is mostly talked about, but this was just the master pattern. The functionality provided is a more simplified API to a backbone that is fundamentally based on XDS. This simplified API is based on the HL7 FHIR RESTful API. It is therefore available in simple XML, or JSON. The elements of the metadata are thus more accessible to a Java Script application.

As an API to XCA environment

Just like with XDS, this is a more simplified API to a federated set of Document Sharing infrastructure. The interactions of the Document Source and Document Consumer MHD actors are just the same as with XDS. The implementation of the Document Recipient and Document Responder MHD actors might be more specialized.

As a standalone Document Sharing infrastructure

Similar to XDS or XCA, but without the need for XDS or XCA on the backend.

As an API to XDR environment

Either end of an XDR could be implemented

As a standalone PUSH environment

Similar to XDR without XDR. Use your imagination that everywhere XDR might be used, the MHD Document Source to Document Recipient could be used.

As an API to the Direct Project HISP

Either as PUSH based API, or including support for Query side interaction. The Direct Project is a secure email protocol for pushing documents from one place to another. There are value-add service providers that provide a hosted environment for this. They offer a few different APIs to their hosted service. Some are the secure email, some are based on XDR, some have their own HTTP REST API. These could be augmented through the addition of the MHD API as the front-end of the HISP.

As an API to any document based system

The backend just needs to have a document concept

As simply a profiled FHIR service

At the IHE Connectathon we showed that Document Sources and Document Consumers could just direct their API toward FHIR Servers and it would simply work.

Security and Privacy

As with any Interoperability API dealing with Healthcare information, Security and Privacy
are important. IHE doesn’t mandate a specific Security or Privacy model, as that would be Policy. But IHE does encourage the use of ATNA, and IUA.This also described on the FHIR Site on the Security page.

For More information

User Identity and Authentication
Patient Privacy Controls
Access Control (including Consent Enforcement)
Audit Control
Secure Communications
Document Sharing Management (Health Information Exchange - HIE)
Patient Identity
mHealth
Meaningful Use
The Direct Project