Difference between revisions of "MHD Status"

Latest revision as of 09:50, 20 December 2022

Published at Mobile access to Health Documents (MHD)

@@ Line 1: / Line 1: @@
-This page holds the status of the revision of the [[Mobile access to Health Documents (MHD)]] profile.
+Published at [https://profiles.ihe.net/ITI/MHD/index.html Mobile access to Health Documents (MHD)]
-= 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 [http://www.ihe.net/Technical_Frameworks/#IT "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.
-Note all IHE Profiles using FHIR are being updated under [[Updates of Profiles to FHIR DSTU2]]
-== Future Improvement Opportunities beyond this DSTU2 alignment ==
-later phase detailed writing (Need volunteer)
-# 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.
-# 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.
-# 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.
-# 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.
-# do we need to expand the XDS proxy description? Does this mean it goes into an appendix?
-# MHD_027 -- might explain informatively how a DocumentSource might have magic to host the document bits, or might use something like FHIR binary.
-# IUA asks for profiles to define scope values. might define in MHD a scope value that is "all MHD Queries", or something like that.

Difference between revisions of "MHD Status"

Latest revision as of 09:50, 20 December 2022

Navigation menu

Search