MHD Status

From IHE Wiki
Jump to navigation Jump to search

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.

Edits Done

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
  6. MHD_031 -- need to add Replace
  7. MHD_032 -- support for other Association types (transform, signs, appends)
    • Fixup pointers to metadata cardionality table in Volume 3
    • Add specific error code for not cardiolality

Improvement Opportunities

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

New questions - December 28, 2015

  1. Seems the introduction already has a good definition of "Mobile". Need someone to suggest specific edits. We agreed we should all be describing Mobile the same way.
  2. Do we really need to fully add Folders? It isn't hard to do on the Submission side, but the Query side requires we add another Find transaction for Folders (List), when this is either obvious and a waste of space to write, or this is no longer really an important function of XDS given that ReferenceIdList seems to be used more often now.
  3. need someone to look into CORS use. Do we need to reference it? Should we reference it? If we do, then we need to explain it a bit more.
  4. on ITI-65 we seem to indicate http://ihe.net/fhir/tag/iti-65 as a mandatory value in the Bundle.meta. Is this really necessary? Does it imply a specific profile also must be built? Is it a problem as is today?
  5. Please review new text
  6. Do we need to have an Appendix Z section to describe bundle anymore? Seems we can just reference the FHIR Bundle by URL, and let their specification stand.
  7. There are FHIR elements that are References. I expect we could allow these to be Contained, within Bundle, or URL addressible. For example DocumentReference.authenticator, and DocumentManifest.recipient.
  8. Those FHIR elements that are References and for which we indicate they are contained. We should explain that contained must stay contained. Document Recipient is not allowed to replace with addressable resources. But we should also warn Document Consumer that they might not be contained, so to be robust.
  9. Do we really need to make masterIdentifier, or Identifier manditory? What about PUSH?

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_033 -- support for folder. Is this really needed? Can we just ignore Folder now that ReferenceIDList is supported?
  3. 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? There is concern from Document Recipient implementers that want a way to declare that they will not accept minimal metadata, and thus a way application writers would indicate that they fully fill out metadata. Thus not getting into the condition of minimal-metadata client never able to succeed against a full-metadata service.
    • we could create FHIR profiles with the different cardionality, but this would not likely change anything except give us a better way to prove conformance. So possibly a later add when have engagement with HL7.

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.
Retrieved from "http://wiki.ihe.net/index.php?title=MHD_Status&oldid=92136"