Mobile access to Health Documents (MHD)
4.2.2 - Trial-Implementation International flag

Mobile access to Health Documents (MHD), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 4.2.2 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of and changes regularly. See the Directory of published versions

Test Plan

We expect the maturity of testing will improve over time independent of the versions of MHD.

This page was last updated May 2024.


MHD is an API between four actors. The transactions between actors specify semantics of the data exchanged. The MHD test plan focuses on these semantics and on the expected actions on the server-side actors (Document Recipient and Document Responder).

The overall scope of MHD testing is affected by the infrastructure that MHD is connected to. For example, where the Document Responder and Document Recipient are grouped with XDS or MHDS infrastructure, more tests apply.

MHD does not mandate the functionality to be provided by the data communicated via MHD transactions. How MHD actors use the data communicated via these transaction is out-of-scope for MHD testing, but may apply to other related Implementation Guides or IHE Profiles.

High-level Test Scope

Submit [ITI-65], [ITI-105], and [ITI-106]

  • Document Source publishes document and folder combinations
    • Note that the Document Content is not material to these tests. It could be a simple text file, CDA, FHIR-Document, PNG image, DICOM KOS, or anything that has a mime type
  • Document Recipient receives and responds as appropriate
    • Document Recipient may have policy against some content types.

[ITI-66] Find Document Lists, [ITI-67] Find Document References, [ITI-68] Retrieve Document

  • Document Consumer requests query for List (Submission Set & Folder), query for DocumentReference, and retrieve document
  • Document Responder responds to query and retrieve as appropriate

End-to-End testing

The best case testing would be to have Document Source submit various content, combinations, and transforms; and these are detected to have happened correctly by using a Document Consumer. This kind of end-to-end testing can’t be done in all cases, such as PUSH, but can be used when the Document Recipient and Document Responder are grouped with a Document Sharing infrastructure. Such as using the XDSonFHIR option, MHDS, or simply having MHD as a direct API to an XDS Registry/Repository.

Unit Test Procedure (Conformance Testing)

Unit testing this context entails testing a SUT with a simulator or validator tool. A simulator is a implementation of an actor that is designed specifically to test the opposite pair actor. The simulator might be a reference implementation or may be a specially designed test-bench. Often, when a reference implementation is used, the negative tests are harder to simulate. A validator is a implementation that can check conformance. A validator may be a simulator, but may also be a standalone tool used to validate only a message encoding. Some reference implementations may be able to validate to a StructureDefinition profile, but often these do not include sufficient constraints given the overall actor conformance criteria.

Available Tools for MHD Unit Testing

FHIR Toolkit (aka “Asbestos”) - Simulator and Validator

  • Provider: NIST (US National Institute of Standards and Technology)
  • FHIR Toolkit online status:
  • Tool distribution:
    • Release 4.x.x is compatible with IHE MHD version 3.x and 4.0.1
    • Features may be added to FHIR Toolkit in subsequent releases. Check release notes in the tool distribution link above
  • Documentation (installation):
  • Tool support:
  • Actors (options) tested: Document Source (minimal metadata), Document Source (comprehensive metadata), Document Source (minimal metadata), Document Source (comprehensive metadata)
  • Other notes:

Gazelle External Validation Service (aka “EVS Client”) - Validator

  • Provider: INRIA (Rennes, France), KEREVAL (, and Mallinckrodt Institute of Radiology (Saint Louis, USA)
  • Tool location:
  • Documentation:
  • Scope of testing: validation of FHIR Resources using StructureDefinitions for MHD
  • Other notes: StructureDefinitions available in EVSClient validation are published by IHE here:

Integration Test Procedure (Interoperability Testing)

Integration Testing in this context is where two SUT of paired actors test against each other. Integration testing is often limited by the capability of the client (Document Source or Document Consumer), which may support only a subset of the semantics required to be supported by the server (Document Recipient or Document Responder). Full message semantics and failure-modes are more thoroughly exercised with unit (conformance) tests.

The tests listed below are defined in Gazelle Master Model ( and are performed by systems testing MHD at IHE Connectathons. Note the following links into the Gazelle Master Model do require a account to view.

Document Source –> Document Recipient Interoperability Tests

Document Recipient - XDS on FHIR Option

Document Consumer –> Document Responder Interoperability Tests

XDS on FHIR Option

Additional Tests not included in Gazelle today

  • Update a Folder, where the test is focused on creating a Folder, but the ITI-65 supports updating an existing folder.
  • UnContained is not tested specifically for Practitioner not being contained
  • Should be tests for Replace, Transform, or Append for non XDS on FHIR situations (aka MHDS, or just push)
  • Test MHD as a direct API to XDS Registry/Repository. Where the MHD Document Recipient to XDS Document Source is logical and not exposed; and where the MHD Document Responder to XDS Document Consumer is logical and not exposed.

Simplified Publish Option

  • no tests for this option:

Generate Metadata Option

  • no tests for this option:

ITI-65 FHIR Documents Publish Option

  • no tests for this option