MHD Status

This page holds the status of the revision of the Mobile access to Health Documents (MHD) profile.

Meeting

Bi-Weekly starting November 13, 2015, 8:00 am Central Mondays -- https://himss.webex.com/himss/j.php?MTID=m18e9822c24f333dc50b3ed6fbc5034f2

Purpose

The MHD profile was created in 2012 as a simple RESTful API to the Document Sharing environment (XDS, XCA, XDR, and XDM). This was at the same time that HL7 initiated their FHIR standard using REST. The profile, while in "Trial Implementation", inspired the creation of the necessary Resources within the HL7 FHIR standard. HL7 FHIR is now in "Draft Standard for Trial Use" (DSTU), so IHE is adjusting the MHD profile to utilize HL7 FHIR.

After the completion of FHIR DSTU1, IHE updated MHD (2014-2015 work item), informally referred to as MHD2, produced a new "Trial Implementation" version. This work item also produced a number of change proposals upon the FHIR specification.

Detailed Mapping of Document Sharing (e.g. XDS) to MHD (FHIR) can be found at MHD-rev2-vol-3. This material will continue to evolve over 2014, so is only published on the Wiki. Implementers will find additional guidance and examples at MHD Implementation Guide

DSTU2 alignment

These FHIR change proposals have now resulted in FHIR DSTU2. The FHIR DSTU2 specification has indicated that the DocumentReference, DocumentManifest, and other resources used by MHD are to be considered Mature and 'Frozen'. This is an indication by HL7 that there is no expected major changes to these Resources, but as DSTU there still could be changes. IHE will now update MHD (2015-2016) to the DSTU2 version of FHIR. This work is initially started under IHE ITI CP 886, but given the scale of the changes might become a full work-item.

Note that while both FHIR is in Draft Standard for Trial Use (DSTU), and MHD is in Trial Implementation; the community should expect that experience with these specifications will result in change proposals which will result in changes to the specification. Both HL7 and IHE have governance that covers this phase, governance that allows radical changes to reflect experience.

Improvement Opportunities

Note all IHE Profiles using FHIR are being updated under Updates of Profiles to FHIR DSTU2

first phase bulk alignment (mostly editorial cross-reference work)

1. changes in the FHIR structure of DocumentReference and DocumentManifest
   • DocumentReference.location.uri ... is now in content...
   • change from atom to bundle
2. MHD_030 -- support for referenceIdList
3. add references as necessary to PIXm, now that it exists. Look for PDQm and make appropriate addition.
4. Address MHD addition to Volume 3.
   • is the current method of using a table sufficient?
   • would like to remove the references to the wiki, as the wiki content is not maintainable.
   • Drop the second column in these Vol3 tables, as it just duplicates the definition of the XDS element name. 12/14/2015
   • Keep Vol3 tables. Note that FHIR has a cross-walk as well that we are actively maintaining. Any differences are not intended, except as the specification evolves. The IHE specification should be considered normative.
5. support for PracticeSettingCode

first phase detailed writing (Need volunteer)

1. Explain how to fill out DocumentManifest given only a FindSubmissionSets --> Using DocumentManifest.content.attachment.url, not attachment.data; and predicting the URL space that your proxy implementation owns for DocumentReferences given SubmissionSet and GetAssociations query results.
2. MHD_031 -- need to add Replace
3. MHD_032 -- support for other Association types (transform, signs, appends)
4. MHD_033 -- support for folder
5. How to handle minimal-metadata. There is a need to define DocumentSource as wanting to use minimal-metadata, where as DocumentRecipients don't want to have to 'fill in' the missing metadata.
   • Do we define named options for this?
   • do we define well-defined error handling?

second phase priority

1. MHD_034 -- resolve the issues around 'contained' use of Patient and Provider. -- Might be too hard to fix this in this CP, may thus need an additional CP to address.
2. MHD_035 -- explain how to resolve the different models for extensions between XDS and FHIR. In FHIR they must be formal extensions, where as in XDS they are just 'well named' slots. Thus there needs to be a translation mechanism. Likely won't define a translation mechanism, but will explain that it is needed.

less priority, as they are not specifically DSTU2 and/or could be handled in independent CP

1. do we need to expand the XDS proxy description? Does this mean it goes into an appendix?
2. MHD_027 -- might explain informatively how a DocumentSource might have magic to host the document bits, or might use something like FHIR binary.
3. IUA asks for profiles to define scope values. might define in MHD a scope value that is "all MHD Queries", or something like that.