IHE MHDMobile access to Health Documents
In short
MHD is an IHE profile that offers a simple FHIR-based API to publish, find and retrieve a patient's clinical documents. It lets mobile apps, portals and other lightweight systems access document sharing networks without the technical complexity of XDS.b. France and Switzerland use it in their national specifications.
- Type
- Implementation guide
- Steward
- IHE International
- Current version
- 4.2.5
- Reviewed
- October 25, 2026
Explanation
What it is
Mobile access to Health Documents (MHD) is a profile in IHE's IT Infrastructure domain. It defines a standardized interface (an API) for health document sharing, based on FHIR R4. As of October 2026, the published version is 4.2.5, with trial-use status.
"Mobile" does not restrict the profile to phones: IHE designed it for any system with constrained resources or a simple programming environment (JSON, HTTP, a browser), and also for more capable systems with simple needs, such as showing the patient's latest summary. The goal is to spare the client from handling SOAP, WS-Security, MTOM/XOP or ebRIM, technologies that XDS.b uses.
Actors and transactions
| Transaction | What it does |
|---|---|
| Provide Document Bundle (ITI-65) | Publish one or more documents with their metadata |
| Find Document Lists (ITI-66) | Find submission sets and folders |
| Find Document References (ITI-67) | Find documents by their metadata |
| Retrieve Document (ITI-68) | Download a document |
| Simplified Publish (ITI-105) | Publish a document with a single DocumentReference resource |
| Generate Metadata (ITI-106) | Publish a CDA or FHIR document and let the recipient generate the metadata |
The actors are Document Source and Document Recipient (publishing) and Document Consumer and Document Responder (querying). XDS metadata are represented with the DocumentReference and List resources.
How it combines with other profiles
MHD is not a document sharing network by itself. It can be the API to an XDS.b or XCA network, part of IHE's MHDS solution, or used just to push documents. With the XDS on FHIR option, the Document Recipient is grouped with an XDS.b Document Source and turns each ITI-65 into an XDS.b transaction.
Common misconceptions
- Having an MHD API does not create content interoperability: the document can be a PDF or a CDA document, and its meaning is defined by other profiles.
- Options matter. A Document Recipient without the Comprehensive Metadata option may accept minimal metadata that an XDS.b network would reject.
- Security is not built in: MHD refers to IHE's mobile security considerations and to IUA for OAuth-based authorization.
Usage examples
France's Agence du Numérique en Santé bases its "Partage de Documents de Santé en mobilité" (PDSm) specification, version 3.1.1, on MHD.
Switzerland's CH EPR FHIR guide (version 5.0.0) includes MHD with national extensions for the electronic patient record, such as its own transaction for updating metadata.
IHE's Mobile Health Document Sharing (MHDS) solution uses MHD as its document sharing interface.
The IHE mXDE profile combines MHD with QEDm to give access to individual clinical data elements extracted from shared documents.
The IHE IUA profile adds MHD-specific scope values for authorizing its transactions with OAuth.
A patient app uses ITI-67 to find a person's documents in the regional network and downloads the latest summary with ITI-68.
Relation to other terms
Relies on2
Depend on this one0
No glossary term depends on this one.
Sources
- IHE — Mobile access to Health Documents (MHD) 4.2.5profiles.ihe.net
- IHE MHD — Actor Optionsprofiles.ihe.net
- IHE MHD — Cross Profile Considerationsprofiles.ihe.net
- IHE MHD — FHIR Maps (metadatos XDS en FHIR)profiles.ihe.net
- ANS — Partage de Documents de Santé en mobilité (PDSm)interop.esante.gouv.fr
- eHealth Suisse — CH EPR FHIR (R4)fhir.ch