IHE Mobile access to Health Documents - Trial Implementation

Updated August 2014 -- IHE is updating the MHD profile to align with FHIR (DocumentReference, DocumentManifest). Please refer to the IHE Wiki MHD Status page for current information. Also see the mHealth topic for updated blog articles.


The Mobile Access to Health Documents (MHD) Profile is now in Trial Implementation. This blog is going to be in the form of a bloginar, webinar given in the form of a blog post. The source presentation is published and accessible.

Executive Summary of changes:
For those that saw the Public Comment. The big changes are (a) the resource is now a DocumentDossier which is more complete than a DocumentEntry; (b) Queries now include parameters for Document, SubmissionSet, and Folder; (c) Queries now return a list of DocumentDossier references in JSON and Atom; and (d) the PatientID is a parameter rather than a URL element allowing for more flexibility.

The Profile Explained
The profile has the goal of providing an interface to XDS that would be appropriate for a resource constrained environment such as a Mobile Device. It is not constrained to only be used by mobile devices. It is also not constrained to only serving documents from XDS, and includes descriptions for XCA as well as other environments. The client requirements were to use interface technologies that are the readily available on mobile platforms, thus could be used without a large, or any, footprint on the client side.

This interface clearly needs to work when that Document Sharing Infrastructure is indeed an XDS environment. The MHD profile gets described in IHE Actor/Transaction terms like this



This could be implemented natively on XDS infrastructure or could be supported using proxy services.




Now the MHD profile is not exactly one-for-one capable with XDS. We eliminated complexity but while doing that we needed to make tradeoffs on the side of simplicity that did eliminate some of the XDS capability.

• the MHD PutDocumentDossier can only publish one new document at a time into a new SubmissionSet.
• the MHD Put Document Dossier cannot be used to replace an existing document or provide a transform
• the MHD Get Document Dossier can get only metadata about one document at a time.
• the MHD Get Document can only pull one document at a time.
• the MHD Find Document Dossiers supports only the OR operator within parameters.
• the MHD Find Document Dossiers returns only references to Document Entries, requiring a MHD Get Document Dossier to retrieve the metadata
• the MHD Find Document Dossiers does not support the XDS Registry Stored Query GetRelatedDocuments stored query.

Or if you need to provide RESTful access to a much larger network of HIEs, through XCA federation




We also recognized that those that would be interested in this profile, or those that we want to be interested in this profile, are more use to looking at interfaces using the HTTP REST methods. So we also published a cross-walk table that translates the REST methods with the IHE Actor/Transaction method


HTTP Method

HTTP Method	Transactions on Document Dossier	Transactions on Document
GET	Get Document Dossier [ITI-66]	Get Document [ITI-68]
PUT	Prohibited	Prohibited
POST	Put Document Dossier [ITI-65]
DELETE	Prohibited	Prohibited
UPDATE	Prohibited	Prohibited
HEAD	Not Specified	Not Specified
OPTIONS	Not Specified	Not Specified
TRACE	Not Specified	Not Specified

One of the big changes we did was to encode the XDS Metadata in JSON. To do this we flattened it as much as possible, although we did preserve much of the value encodings (Future enhancement). When we flattened the XDS Metadata we also collapsed the references between objects, representing SubmissionSets, Folders, and Associations inline with the document entry. Thus we created a new object type, a DocumentDossier. It can be seen as:

documentDossier:{documentEntry:{…},submissionSet:[{…},{…}],folder:[{…}],association:[{…},{…}]}

Now this is a rather quick jump into JSON encoding, and I am not going to run a JSON encoding school here. But even if you don’t understand JSON completely you can see that a DocumentDossier is made up of the DocumentEntry plus any SubmissionSets that it is referenced by, and any Folders that it is referenced by, and any Associations that it is referenced by. Each of these is just folded into the one object/resource.

Next I give an example of a DocumentEntry. This is more carefully explained in the profile, but I provide it on the blog simply because looking at it is very educational. The XDS Metadata that we are used to, is simply encoded; and flat. An example of a DocumentEntry is:

documentEntry:{patientID: "144ba3c4aad24e9^^^&1.3.6.1.4.1.21367.2005.3.7&ISO" ,
classCode: {code:" 34133 -9 ",codingScheme:“2.16.840.1.113883.6.1", codeName:“Summary of Episode Note"},
confidentialityCode:{code:”N”,codingScheme:”2.16.840.1.113883.5.25”,codeName:”Normal sensitivity”},
formatCode:{code:”urn:ihe:lab:xd-lab:2008”,codingScheme:” 1.3.6.1.4.1.19376.1.2.3”,codeName:”XD-Lab”},
typeCode:{code:””,codingScheme:””,codeName:””},
Author:{…},
practiceSettingCodes:{code:" 394802001 ",codingScheme:“2.16.840.1.113883.6.96 ", codeName:“General Medicine"}
Title:"document title",
creationTime:“20061224”,
hash:“e543712c0e10501972de13a5bfcbe826c49feb75”,
Size:“35”,
languageCode:“en-us”,
serviceStartTime:“200612230800”,
serviceStopTime:“200612230900”,
sourcePatientId:“89765a87b^^^&3.4.5&ISO”,
mimeType:” text/xml ”,
uniqueId:” 1.2009.0827.08.33.5074”,
entryUUID:”urn:uuid:14a9fdec-0af4-45bb-adf2-d752b49bcc7d “}
The API

So the RESTful interface for a DocumetDossier all operates on a core URL that is made up of a local part, a fixed resource type identification, case specific entryUUID identifier, and the Patient Identifier. The Patient Identifier is a parameter to allow for supporting the fact that the patient ID tends to need to be flexible to support Patient ID lookup, Cross-References, Master Patient Indexes, and Partially specified values.

documentDossierSectionURL := http://<location>/net.ihe/DocumentDossier/<entryUUID>?PatientID=<PatientID>
To Create a new object one uses the POST method to the root, without a entryUUID. This allows the service to create a unique UUID that will be used to hold this object from then on. To retrieve a Document’s Dossier, you simply use the GET method on the root URL with the entryUUID filled out. To retrieve the document it-self is a similar GET method on a similar root URL for the Document. Yes, I am being short in my description because the Profile has the details, and this is just an introduction bloginar.

To discover resources there are some search methods that generally follow the XDS FindDocuments, FindSubmissionSets and FindFolders all combined. Essentially the client can request any of the parameters found in all of these be matched in an OR relationship. The result returned can be a list of DocumentDossiers in JSON or Atom format. Thus allowing for a RESTful subscription model.

SecurityConsiderationsThere are many security and privacy concerns with mobile devices, simply because they are harder to physically control. Many common information technology uses of HTTP, including the RESTful pattern, are accessing far less sensitive information than health documents. These factors present an especially difficult challenge for the security model. It is recommended that application developers utilize a Risk Assessment in the design of the applications, and that the operational environment utilize a Risk Assessment in the design and deployment of the operational environment.

There are many reasonable methods of securing the interoperability transactions. These security models can be layered in without modifying the characteristics of the MHD profile transactions. The use of TLS is encouraged, specifically the use of the ATNA profile. User authentication on mobile devices is typically handled by a more lightweight authentication system such as HTTP Authentication, OAuth, or OpenID Connect. IHE does have a good set of profiles for the use of Enterprise User Authentication (EUA) on HTTP-based devices, with bridging to Cross-Enterprise User Assertion (XUA) for the backend. In all of these cases the network communication security, and user authentication are layered in at the HTTP transport layer thus do not modify the interoperability characteristics defined in the MHD profile.

The Security Audit logging (e.g., ATNA) is recommended. Support for ATNA-based audit logging on the mobile health device may be beyond the ability of this constrained environment. This would mean that the operational environment must choose how to mitigate the risk of relying only on the service side audit logging.

The Resource URL pattern defined in this profile does include the Patient ID as a mandatory argument. The advantage of this is to place clear distinction of the patient identity on each transaction, thus enabling strong patient-centric privacy and security controls. This URL pattern does present a risk when using typical web server audit logging of URL requests, and browser history. In both of these cases the URL with the patient identity is clearly visible. These risks need to be mitigated in system or operational design.

Relationship to other RESTful content standards and Security definitions is shown graphically below. The IHE MHD profile is just one effort underway right now to define RESTful content access methods. Each of these methods is being carefully coordinated so that they respect the space that the other standards fill while adding their own value. Each of these requires that the Security layer can be provided independent, for this we are looking toward and working with efforts like the FHA/S&I Framework RHEx.

More Information
I have said enough for now. There is the  source presentation that is published and accessible.  It has some more details, but the profile is the right place to go.
The Mobile Access to Health Documents (MHD) Profile is now in Trial Implementation. This blog is going to be in the form of a bloginar, webinar given in the form of a blog post. The