IHE ITI mHealth Profile - Public Comment

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 IHE IT Infrastructure domain has published one new supplement for Public Comment. The supplement is formally “Mobile access to Health Documents (MHD)”, but is often referred to as the mHealth profile.

The Mobile access to Health Documents (MHD) profile defines a simplified RESTful interface to an XDS like environment. It defines transactions to a) submit a new document from the mobile device to a document receiver, b) get the metadata for an identified document, c) find document entries containing metadata based on query prameters, and d) retrieve a copy of a specific document.

These transactions leverage the document content and format agnostic metadata concepts from XDS, but simplify them for access by mobile devices. The MHD profile does not replace XDS. It can be used to allow mobile devices constrained access to an XDS health information exchange. The following figure shows one possible way to implement MHD with a document sharing environment (that may, but is not necessarily, XDS based). This implementation choice is not mandatory and other architectures will be implemented.

Figure 1: Mobile access to a Document Sharing environment.

The XDS profile is specifically designed to support the needs of Cross-Enterprise security, privacy, interoperability, and includes characteristics to support this level of policy and operational needs. The MHD profile has simplified the interactions in ways that are more consistent with a single policy domain use. The MHD transactions are not specifically tied to XDS, and some of the system implementations envisioned would interface directly to an organizational EHR, or a multi-national PHR.

The following lists a few examples of the environments which might choose to use the MHD profile instead of the XDS profile. The MHD profile supports a broad set of the XDS use cases and functionality while keeping the technology as simple as possible.

• Medical devices such as those targeted by the Patient Care Devices (PCD) domain or Continua organization, submitting data in the form of documents.
• Kiosks used by patients in hospital registration departments, where it is anticipated that a hospital staff member will review, edit, and approve the document before it is allowed into the hospital system. 
• PHR publishing into a staging area for subsequent import into an EHR or HIE.
• Patient or provider application that is configured to securely connect to a PHR in order to submit a medical history document.
• Electronic measurement device participating in an XDW workflow and pulling medical history documents from an HIE.
• A General Practitioner physician’s office with minimal IT capabilities using a mobile application to connect to an HIE or EHR.

Technical Details

The choice for technology are simple HTTP (using RESTful pattern) and JSON for encoding.

RESTful Fundamentals

In order to fit into a RESTful model, we needed to determine what the “Resource” was that would be operated on. We naturally first thought about the Document, but eventually realized that the Resource that is fundamental to XDS is the DocumentEntry, the metadata about the document. Once we determined that this is the fundamental resource the profile falls very quickly in place.

• The HTTP “Put” (POST) operator is used to create a new instance of Document Entry (metadata). 
• The HTTP “Get” operator is used to get a copy of an instance of a Document Entry (metadata)

Thus we needed to define the URL in a way that works with these operators. We looked at hData and found a general pattern with the patientID low followed by types of objects. IHE already has a unique ID for a DocumentEntry, so the entryUUID was a natural. Although we haven’t folded hData into the specification, it is likely to happen at the Trial Implementation stage simply because hData brings along already written foundational concepts.

http://<location>/<patientID>/DocumentEntry/<entryUUID>/

This works great for DocumentEntry as the resource, but we also need to be able to pull the document it-self. At this point it became clear how to modify our URL to return the Document itself.

http://<location>/<patientID>/Document/<entryUUID>/

Not RESTful

The last bit of work is NOT RESTful as it doesn’t really follow the same pattern. It is HTTP based, and it is simple. We needed to bring in a XDS Stored Query, specifically FindDocuments. This was brought in one way, but might change in Trial Implementation. I propose that this is just a special case of the DocumentEntry URL without an entryUUID and with parameters. But the result would not be a single DocumentEntry, which I think is minor.

http://<location>/<PatientID>/FindDocumentEntries?<parameters>

DocumentEntry encoded in JSON

We gained much of our simplification through making the XDS metadata flat, and choose JSON encoding as it is favored by many in the mobile space. Plus JSON is different than XML and thus it will be easy to discuss JSON encoding in the context of the MHD profile while XML continues to be the domain of XD*.

Here is an example of a DocumentEntry encoded in JSON (I am sure there are mistakes given that I hand coded it)

{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:“350”,
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 “}

OPEN Issues

As a Public Comment version there are many issues that have come up during the development that are not fully locked down. Most of them are due to the learning-curve of the committee. Thus I really want constructive comments on the whole Profile but specifically on these Open Issues. The open issues are far more detailed in the document, they are basically:

• Restricted “Create” to ONE document, with derived SubmissionSet
• No access to SubmissionSet, Folders, and Associations
• Patient ID is needed as part of URL
• Bring in hData as framework and thus ATOM in GET path for multiple entries?
• Conditional get is not supported due to the differences between the semantics of HTTP and XDS concepts of resource age.
• Do we need more on Security, specifically Audit?
• JSON use of anonymous objects or not?

How to Comment?

The IHE IT Infrastructure Technical Committee has published the supplement for public comment in the period from June 5 through July 5, 2012. Comments submitted by July 5, 2012 will be considered by the IT Infrastructure Technical Committee in developing the trial implementation version of the supplement.  On the same web site is the instructions for submitting comments.

Updates:
I have covered Security in some past articles Securing RESTful services and Securing mHealth - the role of IHE profiles.