Monday, March 16, 2015

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.
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
  • Searching for an ATNA Audit Record Repository

    I have received more than a few requests lately for a listing of the Implementations (vendors or open-source) of the ATNA "Audit Record Repository". I was hoping that a simple internet search on "IHE Integration Statement ATNA Audit Record Repository" would be enough, but that seemed to fail. Mostly digging up articles about ATNA, not about available implementations. This search should have worked, so there is either very few implementations of the IHE Audit Record Repository, or the ones that are out there are not publishing their IHE Integration Statement on the internet where it can be indexed.

    Most worrying is that there is a lack of standalone implementations, that is vendors that specialize in Audit Record Repository functionality. I know these exist, but they don't show up on the search.

    It is very important for the success of the IHE process that vendors publish their "IHE Integration Statement" on the internet. This is not just true for ATNA, but for all Profiles.

    I expect that my blog followers are the likely audience to be these Implementations, or at least those that know some. So I ask that if you have an implementation of the IHE ATNA Audit Record Repository, please post a comment on this article that points at your IHE Integration Statement for that product. I am fine with you explaining your implementation capabilities in a few sentences, but please don't make me regret this offer.

    If you know of an ATNA Audit Record Repository and don't see it show up, please let me know. Or better, let THEM know.