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.
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.
The basics are shown here.
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.
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.
Either end of an XDR could be implemented
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.
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.
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
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
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:
andThe MHD Profile enables many deployment models:
As and API to XDS environment
As an API to XCA environment
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
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
As an API to any document based system
The backend just needs to have a document conceptAs 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 Privacyare 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.