MHTS provides published requirements against which developers and organisations can review relevant technologies. A compliance assessment should examine whether the technology actually satisfies those requirements.
Understanding Conformance
Conformance means that a technology satisfies the applicable published requirements of MHTS. The seven standards include different types of requirements:
- Technical
- Some are directly technical. For example, the presence of cookies or third-party behavioural tracking can be examined through technical inspection.
- Product behaviour
- Others require reviewing product behaviour and design decisions. For example, determining whether an interface uses dependency-generating mechanisms may require examining notifications, rewards, user journeys and the purpose of engagement features.
- Public information
- Public accountability also requires reviewing what information is made available and how the technology measures its stated outcomes.
An assessment should therefore consider more than a company's written assurances. Relevant evidence may include technical observations, product demonstrations and published documentation.
A positive finding concerning one requirement does not establish conformance with the remaining requirements. MHTS contains seven standards, and complete conformance should be evaluated against all seven.
Online Compliance Assessment
The MHTS website provides an online assessment intended to help users examine technologies against the published standards.
Check Your Compliance
Review a technology against the seven published standards on mhts.org.
The assessment provides a convenient starting point for reviewing relevant requirements. Developers and organisations should approach the questions using the technology's actual design and operation. Where answers are uncertain, further examination may be necessary.
A self-assessment is not a substitute for technical verification, clinical evaluation or regulatory review where those processes are required. The published standards remain the authoritative reference for interpreting the requirements.
Evaluating Each Requirement
A structured evaluation can follow the seven standards in their published order.
-
Determine whether the technology captures names, email addresses or other identifiable personal information. Examine both visible input fields and underlying technical processes.
-
Inspect cookies, network requests, analytics integrations, cross-site tracking, third-party processors and other potential behavioural surveillance mechanisms.
-
Frictionless Access in Distress
Test whether the stabilisation function is immediately accessible without login, registration or unnecessary navigation.
-
Stabilisation Before Interpretation
Review the intended intervention sequence and establish whether relevant acute-distress experiences prioritise physiological regulation before reflection or analysis.
-
Examine notifications, rewards, streaks, scarcity mechanisms, reminders and other engagement features.
-
Verify that clear human-support and appropriate emergency pathways exist and that the technology does not present itself as a substitute for professional care.
-
Examine the public availability of non-identifiable data, the explanation of measurement methods and the confirmation concerning third-party behavioural processors.
These checks should be conducted against the requirements as published in MHTS v1.0.
Evidence of Conformance
Evidence helps distinguish an observed product characteristic from an unsupported assertion. Depending on the requirement, useful evidence may include:
-
Technical Evidence
- Inspection of network requests.
- Cookie and browser-storage checks.
- Review of analytics integrations.
- Data-flow documentation.
- Examination of application dependencies.
-
Product Evidence
- Screenshots of relevant interfaces.
- Demonstrations of the user journey.
- Examples of notifications and reminders.
- Confirmation of available support pathways.
- Tests of access without an account.
-
Public Documentation
- Published data-handling information.
- Descriptions of measurement methods.
- Public non-identifiable datasets or appropriate aggregate information.
- Statements identifying relevant external processors.
- Explanations of product scope and limitations.
Evidence should relate to the current version of the technology. Documentation describing intended behaviour is useful, but direct examination may still be required to establish actual behaviour.
Interpreting Assessment Results
An assessment should identify which requirements are supported by sufficient evidence and which require further investigation or corrective action. For practical purposes, reviewers may distinguish between three findings:
-
Requirement Satisfied
Available evidence supports the conclusion that the examined requirement is met.
-
Requirement Not Satisfied
The technology contains a feature or practice inconsistent with the published requirement.
-
Insufficient Evidence
The available information does not establish whether the requirement is met.
These are practical evaluation categories, not an assertion about the exact scoring system used by the MHTS online assessment.
Where a requirement is not satisfied, developers should identify the relevant feature or practice and determine what changes are necessary. For example:
- A non-conforming analytics integration may need to be removed or replaced.
- A registration barrier may require redesigning the access flow.
- An inappropriate engagement mechanism may require changes to notifications or reward systems.
After corrective action, the relevant requirement should be assessed again.
Claims of Compliance
Organisations should accurately distinguish between different forms of evaluation.
- Self-Declared Conformance
- The organisation has assessed its own technology against the published requirements and declares that they are satisfied.
- Independent Verification
- A separate party has examined the technology and supporting evidence. Whether such a review is independent depends on the actual relationship and process involved.
- Formal Certification
- A certification process involves an established scheme, defined assessment criteria and an authorised certification body or equivalent arrangement.
The published MHTS v1.0 resources describe an open standard and voluntary adoption. They do not establish an independent accredited certification programme. Organisations should therefore avoid describing self-assessment as certification or official approval.
If a technology satisfies only some requirements, that distinction should be stated accurately. A claim of complete MHTS conformance should not conceal known non-conforming requirements.
Transparency about both strengths and limitations is an important part of responsible technology evaluation.