Mobile access to Health Documents (MHD)
The IHE MHD profile and the HL7 FHIR activities are working together to revise and enhance the transactions profiled here. For details on HL7 FHIR See http://hl7.org/fhir
Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to a Document Sharing environment. The MHD profile is intended for any system that prefers the simplified HTTP RESTful technology rather than the more robust technology used in XDS. It defines transactions to
- submit a set of documents and metadata from the mobile device to a document receiver,
- find the document submission set metadata based on query parameters;
- find document entries containing metadata based on query parameters, and
- 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 constrained environments such as mobile devices, or other resource constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource constrained systems, 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 we recognize other architectures will be implemented.
RESTful interface to XDS and other Document Sharing environments
The Mobile access to Health Documents (MHD) Profile defines one standardized interface to health documents (a.k.a. an Application Programming Interface (API)) for use by mobile devices so that deployment of mobile applications is more consistent and reusable. The transactions defined here leverage the document content- and format-agnostic metadata concepts from XDS, but simplify them for access in constrained environments including mobile devices. The MHD Profile does not replace XDS. Mobile devices, and other resource-constrained systems, can use MHD to access to an XDS Repository. The following figure shows one possible way to implement MHD within a document sharing environment (that may be, but is not necessarily, XDS-based). This implementation choice is not mandatory and we recognize other architectures will be implemented.
The XDS Profile has separated Document Registry and Document Repository to support the needs of Cross-Enterprise deployment architectures and enable robustness, security, privacy, and interoperability. The MHD Profile has simplified the interactions in ways that are more consistent with use within a single policy domain. MHD transactions are not specifically tied to XDS; some of the system implementations envisioned may interface directly to an organizational EHR, or a multi-national PHR.
The MHD Profile supports a broad set of XDS use cases and functionality while keeping the technology as simple as possible. MHD focuses on a useful subset of the XDS use cases and does not try to reproduce the full scalability, flexibility, privacy, or security supported by the more robust XDS infrastructure. The following are examples of environments which may choose the MHD Profile over the XDS Profile:
- 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. (For example BlueButton+)
- 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.
Applications specific to resource-constrained and mobile devices are an emerging platform for healthcare-enhancing software. The MHD Profile is not limited to mobile devices, using the term “mobile” only as a grouping for mobile applications, mobile devices or any other systems that are resource and platform-constrained. These constraints may drive the implementer to use simpler network interface technology. There are numerous deployed implementations of Document Sharing that need a simpler network interface technology, for example those hosted by a Health Information Exchange (HIE), large health provider electronic health record (EHR), or personal health record (PHR).
The Mobile access to Health Documents (MHD) Profile defines one pair of actors and a transaction to submit or push new “document entries” from the mobile device to a receiving system. Another set of actors and transactions is used to query a list of “document entries” having specific metadata, and to retrieve a document.
This profile leverages the metadata concepts from XDS, but simplifies the transaction requirements for access by mobile devices. The MHD Profile does not replace XDS. Rather, it enables simplified access by mobile devices to an XDS (or a similar) document management environment containing health information.
Two options are defined
- Comprehensive Metadata -- Indicates that the actors will abide by the XDS definition of metadata cardinality (not minimal metadata)
- XDS on FHIR -- Indicates that the actors are expecting XDS implementation behind the Document Responder and Document Recipient.
One deployment model is to use the MHD as a FHIR based API to XDS, thus more friendly to applications. This is defined as the "XDS on FHIR" Option. In this option the MHD Document Responder is responsible for converting the XDS metadata into MHD metadata. This Document Responder is thus responsible for setting the DocumentReference.content.attachment.url so that a Document Consumer simply requests the document from that URL. This URL is fully in the control of the Document Responder. Thus the Document Responder might choose to encode the XDS Document Repository ID and the Document UniqueID into the URL. It might encode them as query parameters in a URL. The Document Responder might alternatively use UUIDs that it keeps a mapping table. The URL might be rooted at the same or a different server endpoint as the Document Responder. The important point is that the Document Responder is empowered to fill the URL anyway it wants. The URL must simply be used by the Document Consumer, meaning the Document Consumer shall not try to interpret the URL, it should just GET.
Systems involved in this profile are:
- Any application or service that would like to use RESTful interactions for Document Sharing.
Actors & Transactions:
Profile Status: Trial Implementation
Documents: MHD Supplement Revised 2019-03-06
Additional Supplements: Appendix Z on HL7 FHIR Revised 2019-03-06
- HL7 FHIR R4 http://hl7.org/fhir/R4
- RFC2616 IETF Hypertext Transfer Protocol – HTTP/1.1
- RFC3986 IETF Uniform Resource Identifier (URI): Generic Syntax
- RFC6585 IETF Additional HTTP Status Codes
FHIR Implementation Guide
Informatively this profile is also as a set of FHIR conformance resources, that are also registered at https://registry.fhir.org
These are not yet created due to lack of tooling that supports creation of FHIR R4 based conformance resources
Prior release aligned with FHIR STU3
Rev 2.4 -- July 24, 2018 https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD_Rev.2.4_TI_2018-07-24.pdf
The following CP have been received since publication of this MHD version. IHE addressed these in MHD version 3.0 when FHIR Release 4 is supported.
- CP-ITI-1101 -- Clarify Remts for MHD Doc Recipient supporting Comprehensive Metadata
- This seems clear to me. The volume one text is not the performance criteria, those are found in 220.127.116.11.3 Expected Actions
- CP-ITI-1102 -- MHD DocumentReference resource editorial changes and author role precision
- editorial fixes already represented in CP-ITI-1079-02
- Changes to author to include ProviderRole can not be done. We can't add to STU3
- CP-ITI-???? -- note 1 has a reference to a nonexistent section
- likely intended to just point at FHIR definition of contained
- CP-ITI-1077 -- HL7 has a new way to encode II in URN form
- CP-ITI-1089 -- Update to MHD for XDS on FHIR Option
- asks for more clear language, but does not yet offer any better language.
- CP-ITI-1095 -- MHD Provide Document Bundle handling of unsupported List resource
- Recognizes that MHD allows warnings on lost folders in the Provide transaction.
- This should be a failure.
- CP-ITI-1100 -- MHD should use created instead of indexed element
- CP-ITI-1113 -- MHD Generated References Documentation
- concern regarding response to Provide Document Bundle that is not compliant with FHIR.
- CP-ITI-1114 -- MHD Patient Management Guidance
- questions how to handle Patient in a Provide, and how to handle Patient in Find transactions
- The initial intent of MHD was to be FHIR friendly, so we chose to use the Patient resource, and not just the bare Patient ID that is more commonly used in XDS. The point is that a Document Source or Document Consumer in MHD is more likely to need the nicety of the Patient resource.
- CP-ITI-1115 -- MHD PDB Response Bundle
- questions how to handle provide response relative to location, and etag
- CP-ITI-1116 -- MHD alignment with FHIR transaction
- CP-ITI-1118 -- Check consistency for ‘no results found’ & ‘unrecognized domain’ text in PIXm, PDQm, Appx Z
- CP-ITI-1119 -- clarification on DocumentReference.identifier.use
- given that there is an indication of what use=official; what are the expected actions?
- I would say that when XDS-on-FHIR option is used, the interpreation must be the same as XDS. But when not, the interpretation would be up to the Recipient to decide
FHIR Implementation Guide
Note the following links are to current instances maintained in Simplifier. This URL may change over time, which is why the canonical URI is provided. The canonical URI can not be used for browser navigation, but can be used for lookup at registry or simplifier as search capability allows.
- IHE MHD Implementation Guide
- canonical URI http://ihe.net/fhir/ImplementationGuide/IHE.MHD
- FormatCode CodeSystem
- canonical URI http://ihe.net/fhir/ValueSet/IHE.FormatCode.codesystem
- Identifier urn:oid:18.104.22.168.4.1.19322.214.171.124
- FormatCode ValueSet
- Actor Capability Statements
- MHD Document Source Actor CapabilityStatement
- MHD Document Recipient Actor CapabilityStatement
- MHD Document Responder Actor CapabilityStatement
- MHD Document Consumer Actor CapabilityStatement
- Structure Definitions
- Document Manifest
- List (Folder)
- canonical URI http://ihe.net/fhir/StructureDefinition/IHE.MHD.List
- DocumentReference from Query with Comprehensive Metadata
- DocumentReference from Query with Minimal Metadata
- DocumentReference in Provide with Comprehensive Metadata
- DocumentReference in Provide with Minimal Metadata
- MHD Provide Document Bundle with Minimal Metadata (ITI-65)
- MHD Provide Document Bundle with Comprehensive Metadata (ITI-65)
Prior conformance resources have been registered, they should now be marked retired
The conformance resources are also available on the Implementation Material folder.
- Bill's notes from 2018 North American Connectathon
This profile supports the security/privacy model discussed in Health Information Exchange: Enabling Document Sharing Using IHE Profiles white paper.
- PDQm -- provides HTTP (RESTful) equivalent to PDQ and PDQv3; and basis set of FHIR methods and data-types
- IUA -- provides user token security for HTTP (RESTful) transactions
This page is based on the Profile Template
Current: IT Infrastructure Technical Framework.