Mobile access to Health Documents (MHD)
4.2.3-current - ci-build
Mobile access to Health Documents (MHD)
4.2.3-current - ci-build
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.3-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.MHD/ and changes regularly. See the Directory of published versions
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.
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 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.
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 (https://gazelle.ihe.net/GMM) 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.
IG © 2020+ IHE IT Infrastructure Technical Committee. Package ihe.iti.mhd#4.2.3-current based on FHIR 4.0.1. Generated 2024-11-26
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change