---
document: mhts-site-contents
purpose: AI retrieval corpus; replaces page-by-page crawl of imhi.com/en/mhts/
site: imhi.com/en/mhts/
generated: 2026-10-31
---

# Mental Health Technology Standards — Site Contents

## Table of contents

- MHTS (index) — imhi.com/en/mhts/
- 1\. Overview — imhi.com/en/mhts/overview/
- 2\. Why It Is Needed — imhi.com/en/mhts/why-it-is-needed/
- 3\. The Seven Standards — imhi.com/en/mhts/the-seven-standards/
- 4\. Using the Standards — imhi.com/en/mhts/using-the-standards/
- 5\. Compliance — imhi.com/en/mhts/compliance/
- 6\. Accountability — imhi.com/en/mhts/accountability/
- 7\. Governance — imhi.com/en/mhts/governance/
- 8\. FAQs — imhi.com/en/mhts/faqs/
- References — imhi.com/en/mhts/references/

---

## MHTS (index)
*Source: imhi.com/en/mhts/*

[Image: MHTS]

### Mental Health Technology Standards

### Seven Safety Standards

Seven published requirements for technologies affecting mental states.

### Protection by Design

Safeguards built into the technology, not just its policies.

### Public Accountability

Transparent data practices and publicly measured impact.

## Contents

1. Overview — What MHTS is, who it serves, the technologies it covers and its relationship to existing digital-health frameworks.
2. Why It Is Needed — Why a dedicated safety standard was needed: the risks of psychological exploitation, behavioural manipulation and inadequate safeguards in technologies affecting vulnerable emotional states.
3. The Seven Standards — The complete MHTS v1.0 requirements, their meaning and practical examples of conforming and non-conforming design.
4. Using the Standards — Practical guidance for incorporating MHTS requirements into product design, software architecture and development processes.
5. Compliance — How developers and organisations can examine their technologies against the published requirements and identify potential non-conformance.
6. Accountability — How technologies should demonstrate psychological safety, measure effectiveness and make relevant information available for public scrutiny.
7. Governance — Voluntary adoption, organisational application, the relationship to existing regulations and the status of MHTS as a public standard.
8. FAQs — Answers to common questions about applicability, privacy, safety, conformance and the adoption of MHTS.
9. References — Research, professional guidance, regulatory publications and other authoritative sources supporting the documentation.

The information provided by the IMHI Group concerning the Mental Health Technology Standards is intended for general educational and informational purposes. MHTS is a voluntary public standard establishing structural and ethical requirements for relevant technologies. It does not provide medical diagnosis, clinical treatment, regulatory approval or independent certification. Organisations remain responsible for complying with applicable laws, professional obligations and regulatory requirements. The published MHTS v1.0 requirements are available at mhts.org (https://mhts.org) .


---

## 1. Overview
*Source: imhi.com/en/mhts/overview/*


### Overview

What MHTS is, who it serves, the technologies it covers and its relationship to existing digital-health frameworks.

Mental Health Technology Standards (MHTS) establishes seven publicly accessible requirements for technologies designed to regulate, support or influence emotional and mental states, protecting users from psychological manipulation, unnecessary data collection, barriers to assistance and unsafe forms of engagement.

## What Is MHTS? {#what-is-mhts}

The Mental Health Technology Standards (MHTS) is an initiative of the IMHI Group. It defines structural and ethical safeguards for technologies intended to regulate, support or influence emotional and mental states.

MHTS was created because no safety standard set specific design safeguards for digital mental-health technology. Existing standards are largely general, addressing app quality, clinical evidence, data protection or medical-device classification, or set high-level service processes; none sets out how these technologies must be designed to protect people using them while emotionally vulnerable. See Gaps in Existing Standards (imhi.com/en/mhts/why-it-is-needed/#gaps-in-existing-standards) .

Unlike general statements about responsible technology, MHTS sets out specific requirements concerning how relevant technologies are designed and operated. These requirements address:

1. Anonymous access without personal information.
2. Protection against behavioural surveillance.
3. Immediate access to stabilisation during distress.
4. The appropriate sequence of stabilisation and interpretation.
5. Prevention of dependency-generating design.
6. Access to human assistance and emergency services.
7. Public accountability for effectiveness and impact.

Each requirement is set out in full in The Seven Standards (imhi.com/en/mhts/the-seven-standards/) .

The standards challenge technical and commercial practices that may be commonplace in other digital products but are inappropriate when applied to people experiencing emotional distress. For example, a conventional application may use behavioural tracking to personalise advertising or notifications to increase the frequency of engagement.

In a mental-health application, the same mechanisms can exploit people at their most vulnerable, using their distress to cultivate dependence for commercial benefit, which is profoundly unethical and contrary to their mental-health interests. MHTS establishes boundaries intended to prevent these conflicts.

> **[Note]**
> The underlying principle is straightforward: technology designed to support mental health must prioritise the wellbeing and autonomy of the person using it.

## Who It Is For {#who-it-is-for}

MHTS is relevant to organisations and individuals involved in designing, developing, evaluating, purchasing or recommending technologies that affect emotional and mental states.

**Technology Developers**
Software engineers, application developers and AI specialists can use the standards to inform technical architecture, data handling and product functionality.

**Product Designers**
UX and UI designers can use MHTS to evaluate whether interfaces are accessible during distress and avoid manipulative patterns of engagement.

**Technology Companies**
Product owners and technology businesses can use the standards to establish internal design requirements and assess whether commercial objectives conflict with user wellbeing.

**Healthcare Professionals**
Clinicians, therapists and other healthcare professionals may use MHTS as an additional consideration when evaluating digital tools intended for people experiencing emotional or psychological difficulties.

**Researchers**
Researchers can examine the standards, their implementation and their relationship to safety, privacy and measurable mental-health outcomes.

**Organisations and Procurement Teams**
Employers, educational institutions, healthcare providers and other organisations can consider MHTS when assessing technologies they intend to make available to employees, students, patients or the public.

**Regulators and Policymakers**
Public authorities and standards organisations may use MHTS as a reference when considering safeguards specifically related to emotional vulnerability and mental-health technology.

## Technologies Within Scope {#technologies-within-scope}

MHTS concerns technologies whose intended purpose or operation involves regulating, supporting or influencing emotional and mental states. Depending on their functionality, relevant technologies may include:

- Digital mental-health support applications.
- Self-guided emotional stabilisation tools.
- Anxiety and stress management applications.
- Digital Psychological First Aid systems.
- AI-powered emotional-support interfaces.
- Mental-health chatbots and conversational systems.
- Digital wellbeing platforms.
- Interactive psychological support programmes.
- Technologies delivering Psychological First Aid teachings, training or certification for public use.

The relevant consideration is not simply whether an application describes itself as a mental-health product. A technology that actively attempts to influence a person's emotional state may raise MHTS considerations even if it is marketed primarily as a wellness, lifestyle or productivity application.

However, the requirements must be interpreted in relation to the technology's intended function.

> **[Note]**
> For example, a tool intended to provide immediate assistance during a panic attack has different operational requirements from a service intended solely to publish general educational articles.

The published standards place particular emphasis on technologies providing stabilisation and support during emotional distress. Organisations should examine the relevant functions of their technology rather than assume that every digital product presents an identical level of psychological risk.

## Core Principles {#core-principles}

MHTS is founded on seven principles.

1. Privacy Without Compromise — A person should not have to identify themselves to receive immediate emotional stabilisation.
2. Freedom From Surveillance — A person's emotional difficulty should not become an opportunity for behavioural monitoring, profiling or undisclosed data processing.
3. Immediate Accessibility — Someone experiencing distress should be able to access relevant support without unnecessary registration, navigation or procedural barriers.
4. Appropriate Intervention — Technology intended to stabilise someone in acute distress should prioritise immediate regulation before introducing reflective or educational demands.
5. Independence Over Dependency — The purpose of support technology should be to help people develop stability and independence, rather than maximise repeated engagement.
6. Human Support Remains Essential — Digital systems must preserve clear pathways to genuine human support and emergency assistance.
7. Measurable Public Accountability — Claims concerning effectiveness and impact should be open to scrutiny through transparent methods and publicly available non-identifiable data.

Together, these principles establish a model in which privacy, safety and accountability are integral to the technology itself.

## An Open Public Standard {#an-open-public-standard}

MHTS is published as an open public standard. Its requirements are publicly accessible, allowing developers, organisations, researchers and individuals to examine them without obtaining private access to the standard.

Adoption is voluntary. Organisations may choose to incorporate MHTS requirements into their development practices, internal policies, technical reviews and procurement decisions.

The availability of a public standard also enables people outside a technology company to understand the safeguards that the company claims to implement.

> **[Note]**
> Publishing a statement of conformance does not itself prove that the relevant requirements have been satisfied. Actual conformance depends on the technology's design, functionality, data practices and operation.

The official requirements are published at: mhts.org (https://mhts.org)

## What It Is Not {#what-it-is-not}

MHTS establishes a specific set of technology safeguards. It does not replace other responsibilities that may apply to digital mental-health products.

**Not a Clinical Treatment Standard**
MHTS does not prescribe a complete psychological treatment, establish clinical efficacy or determine whether a particular intervention is appropriate for an individual.

Clinical claims require their own supporting evidence.

**Not Medical-Device Approval**
Some digital mental-health technologies qualify as medical devices under applicable regulations.

MHTS does not replace medical-device classification, conformity assessment or regulatory approval.

**Not a Replacement for Privacy Law**
The MHTS prohibition on personal information and behavioural surveillance does not replace applicable data-protection legislation.

Organisations remain responsible for complying with the laws governing their operations.

**Not a Substitute for Professional Care**
A technology's conformance with MHTS does not mean that it can replace medical assessment, psychotherapy, clinical treatment or emergency intervention.

**Not Independent Certification**
The published MHTS resources provide standards and a compliance self-assessment.

Self-declared conformance should not be represented as independent certification or regulatory approval.

MHTS should be understood as an additional set of safeguards focused on ethical design and the protection of people whose emotional states may be affected by technology.


---

## 2. Why It Is Needed
*Source: imhi.com/en/mhts/why-it-is-needed/*


### Why It Is Needed

Why a dedicated safety standard was needed: the risks of psychological exploitation, behavioural manipulation and inadequate safeguards in technologies affecting vulnerable emotional states.

Digital technologies can make mental-health support more accessible, but their design can also introduce risks that become particularly significant when users are frightened, overwhelmed or otherwise emotionally vulnerable. Yet no safety standard set specific design safeguards for these technologies; MHTS was established as the first to do so, through explicit structural and ethical requirements.

## Gaps in Existing Standards {#gaps-in-existing-standards}

MHTS was created because no safety standard set specific design safeguards for digital mental-health technology. Mental-health apps have been described as severely under-governed, with existing standards largely general, applying to health apps, digital health or AI systems broadly rather than to mental-health technology specifically. [1]

Even Australia's National Safety and Quality Digital Mental Health Standards, which apply to digital mental-health services, are high-level and process-based: they set governance requirements for service providers, not how the technology itself must be designed. [2] None of these frameworks sets out how mental-health technology must protect people using it while emotionally vulnerable.

The closest available alternatives, and how they compare:

Framework | Primary focus | Specific to mental-health technology | Design safeguards for users in distress
--- | --- | --- | ---
ISO/TS 82304-2 [3] | Quality and reliability of health and wellness apps. | No: covers all health apps. | No: general health-risk requirements only.
APA App Evaluation Model [4] | Helping users and professionals evaluate and select apps. | Yes. | No: an evaluation guide, not a design standard.
Australian NSQDMH Standards [2] | Governance and service processes for Australian providers. | Yes. | No: high-level and process-based.
NICE ESF [5] | Evidence expected to support digital-health technologies. | No: covers digital health broadly. | No.
Medical-device regulation | Classification and approval of products with a medical purpose. | Only where a product qualifies as a medical device. | No.
Data-protection law | Lawful processing of personal information. | No: applies to all personal data. | Partial: limits data use, not product design.
MHTS | Structural and ethical safety requirements. | Yes. | Yes: seven requirements.

> **[Note]**
> MHTS is the first safety standard to set specific design safeguards for digital mental-health technology. Existing frameworks remain important, but none prohibits the design practices that exploit people in emotional distress.

MHTS fills this gap with safeguards centred on the design of technologies that influence emotional and mental states. Its distinctive focus includes:

- Prohibiting identity collection as a condition of stabilisation.
- Prohibiting behavioural surveillance.
- Removing access barriers during distress.
- Prioritising stabilisation before interpretation.
- Preventing dependency-generating engagement systems.
- Preserving immediate pathways to human assistance.
- Making non-identifiable effectiveness and impact data publicly accessible.

MHTS is intended to complement relevant existing frameworks rather than duplicate or replace them. See Relationship to Existing Frameworks (imhi.com/en/mhts/governance/#relationship-to-existing-frameworks) .

The sections below set out the risks these safeguards address.

## Psychological Vulnerability During Distress {#psychological-vulnerability}

People experiencing intense emotional distress, such as anxiety, panic, grief or despair, can be particularly vulnerable to psychological manipulation and exploitation.

During periods of emotional vulnerability, the desire for relief, reassurance or safety can make individuals more susceptible to persuasion, especially when messages appeal to their fears, insecurities or immediate emotional needs. Research has demonstrated that acute stress can impair decision-making [6] and that fear-based messaging can increase susceptibility to persuasion. [7]

This vulnerability creates significant ethical responsibilities for mental-health technology providers. A person seeking emotional support should never have their distress exploited for commercial gain, behavioural influence or increased engagement.

For example, a service could exploit someone's fear of worsening mental health to encourage unnecessary purchases, cultivate emotional dependency to increase continued usage, or use sensitive emotional disclosures to deliver highly personalised persuasive messages. [8]

Unlike many other technologies, mental-health services may interact with people precisely when they are at their most emotionally vulnerable. The relationship between provider and user therefore carries a heightened responsibility to protect individuals from manipulation, coercion and exploitation.

Mental-health technology must be designed to support users' wellbeing, never to take advantage of the emotional circumstances that led them to seek help.

## The Risk of Psychological Exploitation {#psychological-exploitation}

Digital products can influence behaviour through their presentation, timing, language and underlying systems. Examples include:

- Artificial urgency encouraging immediate action.
- Fear-based language intended to influence decisions.
- Emotional pressure to continue using a service.
- Misleading claims about the consequences of leaving.
- Interfaces that conceal important choices.
- Personalised messaging based on behavioural profiles.
- Commercial offers that exploit emotional distress to pressure purchases.

These techniques are related to what consumer-protection authorities commonly describe as deceptive or manipulative design patterns. The US Federal Trade Commission has documented how interface design can influence consumer decisions through practices that obscure information, manipulate choices or encourage unwanted actions. [9] Such practices raise additional ethical concerns when the person being influenced is seeking help for an emotionally difficult experience.

> **[Warning]**
> Consider someone opening an anxiety-support application during a panic attack. Instead of providing immediate assistance, the application warns that their symptoms could worsen unless they unlock additional support, prompting them to purchase a subscription. This deliberately exploits the person's fear and urgent desire for relief to pressure a financial decision during a moment of heightened emotional vulnerability.

Similarly, an application that uses emotionally charged notifications can use a person's heightened vulnerability to build dependence on the product, benefiting commercially from the very difficulty it claims to address, at the expense of the user's mental health.

MHTS establishes requirements intended to prevent these conflicts. The objective is not simply to discourage unethical behaviour. It is to prevent certain forms of exploitation through the structure and operation of the technology.

## Commercial Incentives vs User Wellbeing {#commercial-incentives}

Many digital businesses measure success through engagement. Common indicators include:

- Daily active users.
- Session duration.
- Frequency of return visits.
- Retention rates.
- Notification engagement.
- Subscription renewals.
- Revenue generated per user.

These measurements can be useful in conventional digital products. However, the objectives of mental-health support may be fundamentally different.

For a person using a stabilisation tool, a successful experience might involve using the service briefly, regaining composure and not needing to return. An application designed to maximise daily engagement could therefore pursue a commercial objective that conflicts with the intended outcome of the intervention.

This conflict becomes more serious when engagement mechanisms depend on emotional recurrence. For example, a product might use streaks to encourage daily interaction, reward users for repeatedly reporting distress or send reminders that create anxiety about losing progress. Such features take advantage of a person's recurring vulnerability to build dependence, rather than supporting the development of independent coping skills, serving the provider rather than the user's mental health.

MHTS Standard 5 (imhi.com/en/mhts/the-seven-standards/#no-dependency-engineering) addresses this issue directly through its prohibition on dependency engineering.

The distinction is not between commercial and non-commercial technology. A commercial mental-health product can operate responsibly. The distinction is between generating revenue from a useful service and deliberately structuring that service to exploit or prolong vulnerability.

> **[Note]**
> The success of mental-health support should be measured by its benefit to the user, not merely by how frequently the user returns.

## Privacy & Emotional Data {#privacy-and-emotional-data}

Mental-health technologies may interact with information that is considerably more sensitive than ordinary application activity. Examples include:

- Emotional difficulties.
- Experiences of grief or trauma.
- Anxiety and panic.
- Personal relationships.
- Feelings of isolation.
- Psychological vulnerabilities.
- Patterns of emotional distress.

When such information can be associated with an identifiable person, its collection can create significant privacy risks. These risks may arise through direct requests for personal information or through less visible technical mechanisms, such as cookies, device identifiers, cross-site tracking, behavioural profiling and transfers of information to third-party services.

Even apparently anonymous data can become identifying when combined with other information. A technology may never ask for a user's name yet still create a behavioural profile capable of distinguishing that person from others.

Mental-health applications should therefore be examined for their actual data flows, not merely for the information requested through visible forms. MHTS establishes two complementary requirements:

- Anonymous access without identifiable personal information. (imhi.com/en/mhts/the-seven-standards/#anonymous-by-design)
- No behavioural surveillance or undisclosed data flows. (imhi.com/en/mhts/the-seven-standards/#no-behavioural-surveillance)

The objective is to prevent the technology from turning psychological vulnerability into an identifiable or commercially exploitable data asset.

## Safety During Emotional Distress {#safety-during-emotional-distress}

A conventional digital interface may assume that users have sufficient time, attention and cognitive capacity to navigate its features. That assumption may be unsuitable for an application intended to provide immediate stabilisation. Potential obstacles include:

- Mandatory login.
- Account registration.
- Long onboarding sequences.
- Excessive instructions.
- Complex navigation.
- Unnecessary questionnaires.
- Interruptive notifications.
- Promotional messages.
- Delayed access to support.

These obstacles may prevent someone from reaching assistance at the moment they need it.

Safety also depends on what the technology does after access is provided. A system designed for acute distress should consider whether its first instructions are appropriate for someone who is already overwhelmed. Introducing complex psychological interpretation before attempting stabilisation may increase cognitive demands at an unsuitable moment.

MHTS addresses this through its requirements for frictionless access (imhi.com/en/mhts/the-seven-standards/#frictionless-access-in-distress) and stabilisation before interpretation (imhi.com/en/mhts/the-seven-standards/#stabilisation-before-interpretation) . The standards also require clear access to real human support and emergency services.

> **[Warning]**
> Digital tools have limits. A user who needs professional or urgent assistance must not be encouraged to rely exclusively on an automated intervention.

## Establishing Trust Through Design {#establishing-trust-through-design}

A privacy policy may explain what information a company collects. A statement of ethics may describe how a company intends to treat its users. A product description may promise that a service is safe, supportive or confidential.

These statements can be useful, but they do not necessarily establish how a technology actually operates. For example, an application may describe itself as privacy-focused while loading third-party services that collect behavioural information. Another may claim to promote independence while using rewards and notifications designed to build dependence.

MHTS focuses on requirements that can be examined through actual product behaviour. A technology should be able to demonstrate, for example, that:

- Stabilisation is accessible without identification.
- Cookies and behavioural profiling are absent.
- Support does not require registration.
- Engagement mechanisms do not cultivate dependency.
- Human assistance remains accessible.
- Anonymous effectiveness data and measurement methods are publicly available.

This approach makes ethical commitments more concrete and open to scrutiny.

> **[Note]**
> The objective is a digital mental-health environment in which people can seek support without being required to surrender their identity, attention or autonomy.

### Page sources

1. [source-1] Manion A, Faveri B, Marchant GE. Mental Health App Governance: International Landscape, Gaps, and Soft Law Recommendations. Jurimetrics. 2025. · Ref. 11 (imhi.com/en/mhts/references/#ref-11)
2. [source-2] Australian Commission on Safety and Quality in Health Care. National Safety and Quality Digital Mental Health Standards. 2020. · Ref. 12 (imhi.com/en/mhts/references/#ref-12)
3. [source-3] International Organization for Standardization. ISO/TS 82304-2:2021: Health Software, Part 2: Health and Wellness Apps, Quality and Reliability. · Ref. 6 (imhi.com/en/mhts/references/#ref-6)
4. [source-4] American Psychiatric Association. The App Evaluation Model. · Ref. 5 (imhi.com/en/mhts/references/#ref-5)
5. [source-5] National Institute for Health and Care Excellence (NICE). Evidence Standards Framework for Digital Health Technologies. · Ref. 7 (imhi.com/en/mhts/references/#ref-7)
6. [source-6] Doroc K, Yadav N, Murawski C. Acute Stress Impairs Decision-Making at Varying Levels of Decision Complexity. Communications Psychology. 2025. · Ref. 13 (imhi.com/en/mhts/references/#ref-13)
7. [source-7] Das E, de Wit JBF, Stroebe W. Fear Appeals Motivate Acceptance of Action Recommendations. Personality and Social Psychology Bulletin. 2003. · Ref. 14 (imhi.com/en/mhts/references/#ref-14)
8. [source-8] Paterson J, Ananthapadmanaban SM. Data Privacy and Consumer Protection Practices of Automated Mental Health, Wellbeing and Mindfulness Apps. University of Melbourne. 2023. · Ref. 15 (imhi.com/en/mhts/references/#ref-15)
9. [source-9] Federal Trade Commission. Bringing Dark Patterns to Light. 2022. · Ref. 4 (imhi.com/en/mhts/references/#ref-4)

Full references (imhi.com/en/mhts/references/)


---

## 3. The Seven Standards
*Source: imhi.com/en/mhts/the-seven-standards/*


### The Seven Standards

The complete MHTS v1.0 requirements, their meaning and practical examples of conforming and non-conforming design.

The seven published MHTS v1.0 requirements are reproduced below, each followed by guidance and examples explaining its practical significance. This guidance does not introduce additional official requirements.

## 01 Standard 1 Anonymous by Design {#anonymous-by-design}

> **[Quote]**
> Published Principle
> The mental health technology must not extract identity in order to offer stabilisation. Emotional support must not be contingent on disclosure.

Requirements

- No name capture
- No email capture
- No identifiable personal data capture

The technology exists to support the person, not to harvest the person.

### Understanding the Standard

A person seeking immediate emotional support should not be required to identify themselves. A name, email address or account is not inherently necessary to guide somebody through an immediate stabilisation exercise.

Requiring such information introduces a barrier and creates an additional privacy responsibility. This can be particularly significant for users who are unwilling to disclose emotional difficulties, are concerned about confidentiality or wish to obtain support privately.

Anonymous design means that the absence of personal identification is a structural feature of the support experience. It should not depend solely on assurances that identifiable data will be handled responsibly.

Developers should also consider less obvious identifying information, such as persistent device identifiers, session records and free-text entries that might contain personal details. The technology must not capture identifiable personal data while offering stabilisation.

## 02 Standard 2 No Behavioural Surveillance {#no-behavioural-surveillance}

> **[Quote]**
> Published Principle
> User presence must never be treated as a data asset. Trust cannot coexist with hidden observation.

Requirements

- No cookies
- No cross-site tracking
- No third-party behavioural profiling
- No undisclosed data flows

Privacy must be structural. Not optional, not policy-based, not implied.

### Understanding the Standard

Mental-health support should not involve observing, profiling or commercially exploiting a person's behaviour. Conventional websites may use cookies and tracking systems to record activity, personalise advertising or build profiles across services. MHTS prohibits these practices in technologies covered by the standard.

The prohibition includes cookies, whether used directly or through third-party integrations. It also addresses surveillance mechanisms that do not rely on cookies.

For example, removing cookies does not establish conformance if an application continues identifying users through browser fingerprinting or persistent device identifiers. Similarly, an application may avoid collecting names while transferring detailed interaction data to an external behavioural analytics service.

> **[Note]**
> Developers must examine actual network activity, application dependencies and data processing rather than rely solely on visible privacy settings.

Aggregate, non-identifiable measurement may be possible without behavioural surveillance, provided the system satisfies all applicable requirements, including Standard 7 (imhi.com/en/mhts/the-seven-standards/#public-accountability) .

## 03 Standard 3 Frictionless Access in Distress {#frictionless-access-in-distress}

> **[Quote]**
> Published Principle
> In acute emotional states, friction compounds harm. A stabilisation tool must not introduce barriers at the moment it is most needed.

Requirements

- Immediate use of stabilisation tools
- No login gates
- No registration barriers
- No unnecessary navigation

Access must be immediate, simple, and cognitively light.

### Understanding the Standard

Someone seeking immediate emotional support should not encounter unnecessary barriers, requests for personal information or commercial prompts before receiving assistance. A stabilisation tool should provide direct access to support without delays or distractions that could interfere with the person's immediate needs.

Users should not be required to create accounts, enter passwords or complete lengthy onboarding sequences before beginning. Navigation should be sufficiently simple for the intended audience and circumstances.

An immediate-support interface might present a clear stabilisation option alongside access to human assistance. Additional features can remain available without obstructing the primary support function.

Frictionless access does not mean that every technology must offer identical interfaces. It means that unnecessary barriers must not prevent access to stabilisation.

## 04 Standard 4 Stabilisation Before Interpretation {#stabilisation-before-interpretation}

> **[Quote]**
> Published Principle
> In distress states, the nervous system must be regulated before reflection, insight, or education is introduced. Sequence of care is part of safety design.

Requirements

1. Physiological down-regulation first
2. Reflection, analysis, or education second

A dysregulated mind cannot absorb instruction.

### Understanding the Standard

The order in which a support technology presents interventions is an important part of its safety design. Someone experiencing acute emotional distress should be offered appropriate stabilisation before being asked to analyse, explain or reflect on their emotional state.

MHTS therefore requires relevant stabilisation experiences to prioritise physiological regulation before introducing reflective or analytical tasks. Depending on the intervention, this may involve appropriate calming or grounding guidance before asking the user to examine their emotions or circumstances.

The principle concerns the design of the support sequence. It should not be interpreted as a claim that every mental-health difficulty can be resolved through physiological regulation, or that the same intervention is appropriate for every person. Clinical suitability, individual differences and situations requiring urgent professional care remain important.

For technologies intended to provide immediate stabilisation, the initial experience should be designed around the user's immediate needs rather than the amount of information the application wishes to collect or present.

## 05 Standard 5 No Dependency Engineering {#no-dependency-engineering}

> **[Quote]**
> Published Principle
> Mental health technology must not cultivate reliance in order to remain relevant. Engagement must never depend on repeated vulnerability.
> Encouragement toward skill-building is appropriate. Design that depends on emotional destabilisation for retention is not.

Requirements

- No streak-based retention systems
- No reward loops tied to emotional recurrence
- No artificial urgency or scarcity triggers
- No shame-based reminders
- No notifications designed to reactivate vulnerability

The aim is reduced long-term reliance, not habitual return.

### Understanding the Standard

Mental-health technology should help users develop greater stability and independence. Its success should not depend on making them feel that continued or repeated use is necessary.

In emotional-support products, engagement mechanisms commonly used in other applications can take advantage of users at their most vulnerable to build dependence. For example, a daily streak may reward repeated use regardless of whether that use benefits the person. A reminder suggesting that someone is failing to care for themselves because they have not opened an application may introduce guilt or anxiety.

A notification that deliberately references emotional vulnerability to encourage engagement creates a particularly direct conflict. MHTS prohibits these mechanisms.

The standard does not prohibit all forms of encouragement, education or progress feedback. It distinguishes genuine support for skill development from design intended to cultivate emotional dependence or exploit recurring distress.

## 06 Standard 6 Human Escalation Supremacy {#human-escalation-supremacy}

> **[Quote]**
> Published Principle
> Digital tools must never position themselves as a substitute for human care. Technology may assist regulation, but it must not claim authority over treatment.

Requirements

- Clear access to real human emotional support services
- Clear access to local emergency services

When digital support reaches its limit, human support must be immediately accessible.

### Understanding the Standard

Digital mental-health technologies have limitations. A self-guided application may provide useful support during distress but cannot necessarily assess an individual's circumstances, respond to every emergency or provide the functions of a qualified healthcare professional.

Likewise, an AI conversational system must not encourage a person to treat it as the ultimate authority on professional mental-health care.

MHTS therefore requires clear access to genuine human emotional-support services and appropriate local emergency services. These pathways must be understandable and accessible to the intended users. Examples may include national crisis-support services, appropriate helplines and local emergency contact information.

A technology intended for international use should consider differences between countries when presenting emergency resources.

> **[Warning]**
> Users must not be required to complete an exercise before seeking urgent help.

## 07 Standard 7 Public Accountability {#public-accountability}

> **[Quote]**
> Published Principle
> Non-identifiable data collected by the mental health technology must be publicly visible. Emotional and mental health effectiveness and impact must be open to public verification.

Requirements

- Public access to the non-identifiable data
- Clear explanation of how effectiveness and impact are measured
- Explicit confirmation of no third-party behavioural data processors

Transparency strengthens accountability. Accountability protects users.

### Understanding the Standard

Mental-health technology may make claims about helping users feel calmer, improving emotional wellbeing or producing other beneficial outcomes. Such claims should be open to examination.

MHTS requires that collected non-identifiable data be publicly accessible and that effectiveness and impact measurement methods be clearly explained. This creates an opportunity for researchers, professionals and members of the public to examine what the available information actually establishes.

Public accountability must remain consistent with the requirements for anonymity and the absence of behavioural surveillance. For example, a technology might publish aggregate information about the number of completed exercises and voluntarily reported changes in distress. It must not expose information that can identify individuals and, under Standard 1 (imhi.com/en/mhts/the-seven-standards/#anonymous-by-design), must not collect such information in the first place.

The distinction between identifiable and non-identifiable information is particularly important when reporting sensitive outcomes or data from small populations.

Public reporting must also distinguish measured outcomes from unsupported conclusions. For example, the number of completed sessions does not itself establish clinical effectiveness. See Publicly Accessible Data (imhi.com/en/mhts/accountability/#publicly-accessible-data) .

## Conforming & Non-Conforming Design {#conforming-and-non-conforming-design}

The following illustrations show how the seven standards may apply to common product decisions. These are examples, not additional published requirements or formal determinations of conformance.

### 1 Anonymous by Design

Conforming

A user opens a calming exercise and immediately begins without providing a name, email address, account or other identifiable information. The application does not capture identifying data through its underlying operation.

Non-conforming

A user must register with an email address before accessing emotional stabilisation.

### 2 No Behavioural Surveillance

Conforming

An application operates without cookies, cross-site tracking, behavioural profiling or undisclosed data transfers. Its actual network and data practices are consistent with those requirements.

Non-conforming

A mental-health application transfers user interactions to a third-party analytics service that builds behavioural profiles, even though the application describes itself as anonymous.

### 3 Frictionless Access in Distress

Conforming

A user can immediately open the relevant stabilisation function through a clear, simple interface without registering or navigating unrelated features.

Non-conforming

Before receiving support, a distressed user must complete an onboarding questionnaire and create an account.

### 4 Stabilisation Before Interpretation

Conforming

An acute-distress exercise begins with appropriate regulation guidance before introducing reflective questions.

Non-conforming

A tool intended for immediate panic stabilisation first requires extensive emotional analysis before offering any regulation assistance.

### 5 No Dependency Engineering

Conforming

An application teaches coping techniques that users can practise independently and does not use prohibited engagement mechanisms to encourage their return.

Non-conforming

An application rewards users for maintaining daily usage streaks, regardless of whether they need support, and sends fear-based notifications suggesting that stopping could harm their mental health.

### 6 Human Escalation Supremacy

Conforming

A support application provides clearly accessible human-support and local emergency pathways, without representing its own intervention as a replacement for professional care.

Non-conforming

An AI support service discourages users from contacting other people and makes no appropriate emergency pathway available.

### 7 Public Accountability

Conforming

An application collects and publishes safely aggregated, non-identifiable outcome information, explains its measurement methods and confirms that no third-party behavioural data processors are used.

Non-conforming

A provider publicly claims that its application is effective but makes no relevant non-identifiable data or measurement methodology available for examination.

> **[Note]**
> These examples demonstrate the central approach of MHTS: requirements should be reflected in the actual operation of technology, not merely in how that technology is described.


---

## 4. Using the Standards
*Source: imhi.com/en/mhts/using-the-standards/*


### Using the Standards

Practical guidance for incorporating MHTS requirements into product design, software architecture and development processes.

MHTS is intended to inform real design and engineering decisions, from product requirements and technology components to user interactions, data flows and releases. The following guidance illustrates practical approaches without adding requirements beyond the published standards.

## Designing for Vulnerable Users {#designing-for-vulnerable-users}

Mental-health interfaces should be designed for the circumstances in which their intended users may need them. A person seeking assistance during acute distress may find complex instructions, excessive choices or unfamiliar terminology difficult to process. Emotional distress can also increase vulnerability to manipulation, particularly when interfaces exploit fear, guilt or the urgent desire for relief.

Developers should therefore examine the complete experience from the user's perspective. Important considerations include:

- How quickly can a user reach the intended support?
- Are the available actions immediately understandable?
- Can the experience be used without prior training?
- Does the interface introduce unnecessary choices?
- Are instructions concise and appropriately sequenced?
- Can the user access human or emergency assistance?
- Are there interruptions unrelated to receiving support?
- Could any messaging, design choices or commercial offers exploit the user's emotional vulnerability?

Where possible, developers should test relevant experiences with users representing the intended population, including appropriate accessibility and usability considerations.

> **[Note]**
> A practical review might involve opening the application without any previous account, stored settings or knowledge of the service. If the user cannot reach the stabilisation function without navigating unnecessary steps, the interface requires further examination against Standard 3 (imhi.com/en/mhts/the-seven-standards/#frictionless-access-in-distress) .

Visual appearance alone does not determine accessibility. A minimal interface may still be confusing, while a more detailed interface may remain usable if the information is carefully organised.

The goal is to reduce avoidable effort at the moment assistance is needed.

## Privacy-First Architecture {#privacy-first-architecture}

MHTS Standard 1 (imhi.com/en/mhts/the-seven-standards/#anonymous-by-design) and Standard 2 (imhi.com/en/mhts/the-seven-standards/#no-behavioural-surveillance) require privacy to be established through technical design. This begins with identifying what information the application genuinely requires. Developers should examine:

- Account and authentication systems.
- Forms and user-input fields.
- Cookies and other browser storage mechanisms.
- Analytics libraries.
- Advertising integrations.
- External scripts.
- Device identifiers.
- Application and server logs.
- Network requests.
- Third-party service providers.
- Free-text and conversational interfaces.

An application that does not visibly request personal information may nevertheless capture identifying information through its infrastructure. For example, persistent device identifiers, stored network metadata or conversation transcripts may create identifying records. Developers should therefore examine actual data collection and retention.

Third-party services require particular attention. A provider should not assume that an external component is compatible with MHTS simply because it serves a technical rather than advertising function. The relevant questions concern what data is transferred, whether any behavioural processing occurs and whether those flows are disclosed.

Applications using AI models should examine whether prompts, conversations or other inputs are transmitted to external providers and whether those inputs can contain identifiable or sensitive information.

Anonymous design also requires considering information that users may voluntarily enter. A free-text field can capture identifying information even when the application does not explicitly request a name.

> **[Note]**
> The absence of a registration form is only one part of privacy-first architecture. The intended outcome is a system that provides support without capturing personal identity or conducting behavioural surveillance.

## Ethical UX & Engagement {#ethical-ux-and-engagement}

User-interface design influences more than convenience. The wording, timing and presentation of features can encourage particular behaviours. For mental-health technologies, those influences should be examined in relation to the user's wellbeing.

**Notifications**
Notifications should not exploit emotional vulnerability or create fear, shame or artificial urgency. A reminder designed to make someone anxious about not using a service is inconsistent with Standard 5 (imhi.com/en/mhts/the-seven-standards/#no-dependency-engineering) .

**Rewards**
Reward mechanisms should not encourage the recurrence or repeated reporting of distress as an engagement objective.

**Streaks**
MHTS explicitly prohibits streak-based retention systems. Developers should not treat daily participation as an inherently desirable outcome for emotional-support tools.

**Commercial Messages**
Commercial messaging should be examined for psychological pressure. For example, presenting payment as a necessary condition for immediate relief can create serious ethical concerns.

**Language**
Interfaces should avoid messages that exaggerate consequences, undermine user confidence or encourage inappropriate emotional reliance.

A useful design question is:

> **[Quote]**
> "Does this feature genuinely help users, or is it just designed to keep them coming back?"

If a feature is primarily designed to keep users coming back rather than genuinely help them, it should be reconsidered. The purpose is to support users in developing skills and stability, not to build a relationship in which continued emotional vulnerability becomes commercially valuable.

## Safe Intervention Design {#safe-intervention-design}

The sequence of an intervention is part of its design. MHTS Standard 4 (imhi.com/en/mhts/the-seven-standards/#stabilisation-before-interpretation) establishes that, in relevant distress states, physiological down-regulation should precede reflection, analysis or education.

For developers, this means examining what the application asks the user to do first. A tool intended for acute emotional stabilisation might:

1. Begin with regulation — Start with a suitable regulation exercise.
2. Then invite reflection — Invite the user to consider or describe their emotional experience.

A different sequence may be appropriate for a product designed exclusively for general education, but its intended purpose must be clear.

Developers should avoid assuming that every user will benefit from the same intervention. The appropriateness of particular psychological techniques depends on the intended population, circumstances, available evidence and clinical considerations.

Digital support must also recognise situations where self-guided stabilisation is insufficient.

> **[Warning]**
> The sequence of the intervention should never prevent access to urgent professional help.

## Human Support & Emergency Integration {#human-support-and-emergency-integration}

MHTS Standard 6 (imhi.com/en/mhts/the-seven-standards/#human-escalation-supremacy) requires clear access to genuine human emotional-support services and local emergency services. Implementation should consider both the visibility and practical usefulness of those pathways. Important questions include:

- Can users locate human-support options easily?
- Are emergency contacts appropriate to the user's location?
- Are support services accurately described?
- Are relevant numbers and links maintained?
- Can users seek emergency help without completing an exercise?
- Does the technology make its own limitations clear?

For international applications, one country's support arrangements should not automatically be assumed appropriate elsewhere.

For AI-based tools, particular care is required when describing the system's capabilities. A conversational model may provide supportive responses, but it must not imply that it possesses the authority or capabilities of a qualified healthcare professional when it does not. Likewise, an automated conversation should not discourage someone from seeking human assistance.

> **[Important]**
> Where an immediate threat to life or safety exists, users should be directed to appropriate emergency services without unnecessary delay.

## Applying Standards Throughout Development {#throughout-development}

MHTS should be considered throughout the product lifecycle.

1. Product Definition — Identify the technology's intended purpose, users and circumstances of use. Determine which functions regulate, support or influence emotional states.
2. Design — Review user journeys against the requirements for anonymous access, frictionless stabilisation, appropriate intervention sequencing and non-manipulative engagement.
3. Architecture — Examine data collection, storage, external services, tracking mechanisms and network activity.
4. Implementation — Ensure that the published requirements are reflected in the actual product, not only in design documentation.
5. Testing — Test whether the relevant safeguards operate as intended. For example, verify that stabilisation remains accessible without registration and that prohibited tracking mechanisms are absent.
6. Pre-Launch Review — Before launch, review the technology against all seven standards and address any areas of non-conformance.
7. Ongoing Maintenance — Repeat relevant checks when introducing features, updating libraries, changing providers or modifying user interactions.

> **[Note]**
> A product that previously met a requirement may cease to meet it following a technical or commercial change. Conformance therefore requires attention to the technology's current operation.


---

## 5. Compliance
*Source: imhi.com/en/mhts/compliance/*


### Compliance

How developers and organisations can examine their technologies against the published requirements and identify potential non-conformance.

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 {#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.

> **[Note]**
> 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 {#online-compliance-assessment}

The MHTS website provides an online assessment intended to help users examine technologies against the published standards.

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.

> **[Note]**
> A self-assessment is not a substitute for technical verification, clinical evaluation or regulatory review where those processes are required. The published standards (imhi.com/en/mhts/the-seven-standards/) remain the authoritative reference for interpreting the requirements.

## Evaluating Each Requirement {#evaluating-each-requirement}

A structured evaluation can follow the seven standards in their published order.

1. Anonymous by Design (imhi.com/en/mhts/the-seven-standards/#anonymous-by-design) — Determine whether the technology captures names, email addresses or other identifiable personal information. Examine both visible input fields and underlying technical processes.
2. No Behavioural Surveillance (imhi.com/en/mhts/the-seven-standards/#no-behavioural-surveillance) — Inspect cookies, network requests, analytics integrations, cross-site tracking, third-party processors and other potential behavioural surveillance mechanisms.
3. Frictionless Access in Distress (imhi.com/en/mhts/the-seven-standards/#frictionless-access-in-distress) — Test whether the stabilisation function is immediately accessible without login, registration or unnecessary navigation.
4. Stabilisation Before Interpretation (imhi.com/en/mhts/the-seven-standards/#stabilisation-before-interpretation) — Review the intended intervention sequence and establish whether relevant acute-distress experiences prioritise physiological regulation before reflection or analysis.
5. No Dependency Engineering (imhi.com/en/mhts/the-seven-standards/#no-dependency-engineering) — Examine notifications, rewards, streaks, scarcity mechanisms, reminders and other engagement features.
6. Human Escalation Supremacy (imhi.com/en/mhts/the-seven-standards/#human-escalation-supremacy) — Verify that clear human-support and appropriate emergency pathways exist and that the technology does not present itself as a substitute for professional care.
7. Public Accountability (imhi.com/en/mhts/the-seven-standards/#public-accountability) — 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-of-conformance}

Evidence helps distinguish an observed product characteristic from an unsupported assertion. Depending on the requirement, useful evidence may include:

- Technical Evidence
- Product Evidence
- Public Documentation

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 {#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 {#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.

> **[Warning]**
> 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.


---

## 6. Accountability
*Source: imhi.com/en/mhts/accountability/*


### Accountability

How technologies should demonstrate psychological safety, measure effectiveness and make relevant information available for public scrutiny.

Mental-health technologies should be evaluated not only by what they promise, but by how they operate and what their evidence establishes. MHTS addresses structural safeguards and public accountability, complementing but not replacing clinical evaluation.

## Psychological Safety {#psychological-safety}

Technology can influence a person's emotional state through its content, interface, interactions and recommendations. Poorly designed experiences may introduce risks, particularly when used during distress. Potential concerns include:

- Inappropriate intervention sequences
- Messages that intensify fear or shame
- Manipulative engagement mechanisms
- Unnecessary cognitive demands
- Misleading claims about support capabilities
- Inadequate access to human assistance
- Failure to communicate important limitations

For AI-based systems, risks may also arise from generated responses that are inaccurate, inappropriate or inconsistent with the user's circumstances.

Safety therefore requires attention to both the technology's intended purpose and its actual behaviour. MHTS establishes safeguards against several identifiable design risks, including behavioural surveillance, access barriers, dependency engineering and the absence of human escalation.

> **[Warning]**
> Conformance with these structural requirements does not establish that every interaction or intervention is clinically safe. Developers remain responsible for evaluating foreseeable risks associated with their particular technology.

## Effectiveness vs Conformance {#effectiveness-vs-conformance}

Two questions should be considered separately. They concern different forms of evidence.

- Does the technology satisfy the MHTS requirements? — MHTS conformance concerns the published structural and ethical requirements.
- Does the technology achieve its intended mental-health outcomes? — Effectiveness concerns whether the technology produces the outcomes it claims.

A technology may meet the published privacy, accessibility and design requirements without having sufficient evidence to support a claim of clinical effectiveness.

Conversely, evidence that an intervention can produce a beneficial outcome does not establish that the technology's data practices or engagement mechanisms meet MHTS requirements.

For example, research supporting a breathing technique does not establish that an application delivering that technique is anonymous, free of behavioural surveillance or accessible during acute distress. Likewise, an anonymous application may still deliver an intervention with inadequate supporting evidence.

> **[Note]**
> Both questions matter.

## Measuring Effectiveness & Impact {#measuring-effectiveness-and-impact}

Claims about mental-health outcomes should be linked to clearly defined measurements. A developer should explain:

- What outcome is being measured.
- How the measurement is obtained.
- When the measurement occurs.
- Which population the available information represents.
- What limitations affect interpretation.

Examples of potentially relevant non-identifiable indicators include:

**Use**
The number of times a support function is accessed or completed.

This indicates activity, not necessarily effectiveness.

**Self-Reported Change**
Optional, non-identifiable reports of perceived emotional change before and after an intervention.

These may indicate perceived short-term benefit but do not automatically establish clinical effectiveness.

**Access to Further Assistance**
Aggregate information indicating whether users selected a human-support pathway, where such information can be measured without identifying or tracking individuals.

**Availability**
Technical information indicating whether relevant support functions are accessible and operational.

**Longer-Term Outcomes**
Where appropriate and independently supported, research may investigate whether an intervention produces sustained benefits.

Such findings require suitable study designs and should not be inferred from ordinary usage statistics.

A responsible evaluation distinguishes direct observations from interpretations. For example, an increase in sessions does not prove improved mental health. Similarly, a reduction in self-reported distress during an exercise does not, by itself, establish long-term clinical benefit.

Measurement should be proportionate to the technology's intended purpose and should not compromise the privacy requirements established by MHTS.

## Publicly Accessible Data {#publicly-accessible-data}

MHTS Standard 7 (imhi.com/en/mhts/the-seven-standards/#public-accountability) requires public access to collected non-identifiable data and transparency concerning the measurement of effectiveness and impact. This requirement must operate alongside Standards 1 (imhi.com/en/mhts/the-seven-standards/#anonymous-by-design) and 2 (imhi.com/en/mhts/the-seven-standards/#no-behavioural-surveillance) .

> **[Note]**
> Public accountability must not become a reason to capture identity or introduce behavioural surveillance.

One approach is to collect only the minimum non-identifying information necessary to measure a defined outcome. For example, a system might record an anonymous count of completed exercises or aggregate responses to an optional emotional-state question. The information may then be made publicly available in a form that does not identify individuals.

However, removing names does not automatically make a dataset anonymous. [1] Detailed timestamps, rare characteristics, small population groups and combinations of seemingly harmless attributes can create re-identification risks. Developers should therefore consider:

- Whether the information is genuinely non-identifiable.
- Whether unnecessary detail can be excluded.
- Whether aggregation reduces disclosure risks.
- Whether small groups require additional protection.
- Whether published information could be combined with external sources to identify someone.
- Whether the measurement method itself introduces prohibited tracking.

Where a particular dataset cannot be made safely non-identifiable, the collection or reporting approach should be reconsidered.

A suitable public report might contain

- Aggregate outcome counts.
- An explanation of the collection method.
- Relevant limitations.
- The period covered.

It should not contain

- Identifiable user records.
- Information that can reasonably be linked back to individuals.

The objective is to make the technology's claimed impact examinable without compromising the people it is intended to protect.

## Transparency of Technology Practices {#transparency-of-technology-practices}

Public accountability requires more than publishing a favourable statistic. A meaningful explanation should help readers understand what the technology does and how its claims are supported. Relevant information may include:

**Intended Purpose**
What the technology is designed to do, and the circumstances in which it is intended to be used.

**Data Practices**
What information is collected, how it is processed and whether any information is transferred externally.

**Measurement Methods**
How effectiveness and impact indicators are defined, collected and calculated.

**Limitations**
What the available information cannot establish.

**External Processing**
Disclosure of relevant processors and the explicit confirmation required by MHTS concerning the absence of third-party behavioural data processors.

**Changes Over Time**
Information about material changes that affect the interpretation of published results.

Transparency should make claims easier to evaluate. It should not rely on technical complexity or excessive documentation to obscure relevant practices.

## Independent Scrutiny & Ongoing Evaluation {#independent-scrutiny}

Publicly accessible information allows external parties to examine a technology's reported activities and outcomes.

**Researchers**
May examine the methodology used to measure effects.

**Clinicians**
May consider whether the claims are appropriate to the stated evidence.

**Developers**
May compare approaches to privacy-preserving measurement.

**Users and organisations**
May evaluate whether the information supports the claims made by a provider.

Public availability does not guarantee that a particular dataset is complete, accurate or scientifically sufficient. Those qualities still require evaluation. Likewise, a public report should not be mistaken for independent clinical validation unless such validation has actually occurred.

Continuing evaluation is important because technologies change. An update may alter an intervention, introduce a new data processor or modify the design of an engagement feature. Changes that affect the published requirements should prompt renewed review.

> **[Note]**
> The intended outcome is an environment in which mental-health technologies remain open to examination, correction and improvement.

### Page sources

1. [source-1] Information Commissioner's Office (ICO). Introduction to Anonymisation. · Ref. 10 (imhi.com/en/mhts/references/#ref-10)

Full references (imhi.com/en/mhts/references/)


---

## 7. Governance
*Source: imhi.com/en/mhts/governance/*


### Governance

Voluntary adoption, organisational application, the relationship to existing regulations and the status of MHTS as a public standard.

MHTS is an open public standard intended for voluntary adoption. Its requirements can be considered by developers, organisations and technology evaluators alongside existing professional, technical and legal responsibilities.

## Voluntary Adoption {#voluntary-adoption}

The MHTS v1.0 publication describes adoption as voluntary. Developers and organisations may choose to apply the seven standards to relevant technologies and examine whether their current practices meet those requirements. Adoption may involve reviewing:

- Product architecture.
- User identification requirements.
- Data collection and tracking.
- Accessibility during distress.
- Intervention sequencing.
- Engagement mechanisms.
- Human-support pathways.
- Public effectiveness and impact information.

> **[Note]**
> Voluntary adoption does not mean that every aspect of a technology's operation is legally optional. Applicable laws and regulations remain binding independently of MHTS.

The purpose of voluntary adoption is to establish an additional commitment to the safeguards defined by the standard.

## Organisational Adoption {#organisational-adoption}

Organisations may use MHTS in several ways.

**Technology Development**
Companies developing emotional-support technologies can incorporate the published requirements into product specifications and development reviews.

**Internal Governance**
Organisations can consider the standards when establishing policies concerning acceptable technology design and data practices.

**Technology Procurement**
Procurement teams may ask providers whether relevant technologies satisfy MHTS requirements and request supporting evidence.

**Healthcare Evaluation**
Healthcare organisations and professionals may consider MHTS safeguards alongside clinical evidence, medical-device requirements and other digital-health evaluation criteria.

**Education**
Educational institutions may use the standards when reviewing mental-health technologies intended for students or staff.

**Research**
Researchers may examine whether adoption of particular safeguards affects accessibility, trust, engagement or other relevant outcomes.

The use of MHTS within an organisation should reflect the actual scope and purpose of the technology being evaluated.

## Relationship to Existing Frameworks {#relationship-to-existing-frameworks}

MHTS operates alongside established digital-health, professional and regulatory frameworks.

**ISO/TS 82304-2**
ISO/TS 82304-2:2021 addresses quality and reliability requirements for health and wellness applications. [1]

MHTS adds a distinct set of requirements focused on anonymity, behavioural surveillance, immediate distress access, dependency engineering, human escalation and public accountability. The frameworks address overlapping but different considerations.

**American Psychiatric Association App Evaluation Model**
The APA's App Evaluation Model helps professionals and users examine relevant app characteristics, including accessibility, privacy, security, clinical foundations and usability. [2]

MHTS focuses on a defined set of structural and ethical requirements rather than providing the same broader app-selection framework.

**NICE Evidence Standards Framework**
NICE provides an evidence framework for evaluating digital-health technologies. Its purpose concerns the evidence expected to support different types of digital-health functions. [3]

MHTS does not replace those evidence requirements.

**Psychological First Aid Guidance**
The World Health Organization's Psychological First Aid guidance establishes principles for humane, supportive and practical assistance following highly distressing events. [4]

MHTS concerns the design and operation of technologies, including relevant technologies applying Psychological First Aid teachings or methods. The two address different aspects of support.

**Data Protection**
Applicable privacy legislation governs the lawful processing of personal information. [5]

MHTS establishes additional technology requirements, including the prohibition on identifiable personal data capture and behavioural surveillance. Compliance with privacy law does not automatically establish conformance with MHTS.

**Medical-Device Regulation**
Certain digital mental-health technologies may qualify as medical devices. Their classification depends on applicable jurisdictional rules, intended purpose and functionality. [6]

MHTS does not replace the resulting regulatory obligations.

## Legal & Regulatory Status {#legal-and-regulatory-status}

MHTS is published as a voluntary public standard. It should not be represented as legislation or as a universal regulatory requirement.

An organisation's legal responsibilities depend on the jurisdictions in which it operates, the purposes of its technology and the activities it performs. For example:

- A product intended to diagnose or treat a medical condition may fall within medical-device regulations.
- A service processing personal health information may be subject to specific privacy and data-protection requirements.
- Marketing claims may also be subject to consumer-protection law.

These obligations exist independently of MHTS.

- Adopting the MHTS requirements does not establish compliance with every applicable law.
- Equally, compliance with applicable law does not automatically mean that a technology meets the additional requirements of MHTS.

> **[Note]**
> Organisations should evaluate both separately.

## Standard Ownership & Governance {#standard-ownership-and-governance}

MHTS is an initiative of the International Mental Health Infrastructures (IMHI) Group. IMHI publishes the standards through the official MHTS website.

The publication provides the authoritative wording of the seven requirements and identifies the current version. The standards are publicly accessible, allowing developers, researchers, organisations and other interested parties to examine them.

The published materials should be used as the reference for determining what MHTS requires.

> **[Warning]**
> No independent certification or accreditation process should be assumed solely from the existence of the public standard or its self-assessment tool.

For the current official publication, visit: mhts.org (https://mhts.org)

## Published Version {#published-version}

The published version documented here is MHTS v1.0 . It contains seven standards:

1. Anonymous by Design (imhi.com/en/mhts/the-seven-standards/#anonymous-by-design)
2. No Behavioural Surveillance (imhi.com/en/mhts/the-seven-standards/#no-behavioural-surveillance)
3. Frictionless Access in Distress (imhi.com/en/mhts/the-seven-standards/#frictionless-access-in-distress)
4. Stabilisation Before Interpretation (imhi.com/en/mhts/the-seven-standards/#stabilisation-before-interpretation)
5. No Dependency Engineering (imhi.com/en/mhts/the-seven-standards/#no-dependency-engineering)
6. Human Escalation Supremacy (imhi.com/en/mhts/the-seven-standards/#human-escalation-supremacy)
7. Public Accountability (imhi.com/en/mhts/the-seven-standards/#public-accountability)

The version is identified on the official standards page. Readers should consult that publication when confirming the currently applicable wording.

This documentation does not presume the existence of unannounced revision, certification or governance procedures.

### Page sources

1. [source-1] International Organization for Standardization. ISO/TS 82304-2:2021: Health Software, Part 2: Health and Wellness Apps, Quality and Reliability. · Ref. 6 (imhi.com/en/mhts/references/#ref-6)
2. [source-2] American Psychiatric Association. The App Evaluation Model. · Ref. 5 (imhi.com/en/mhts/references/#ref-5)
3. [source-3] National Institute for Health and Care Excellence (NICE). Evidence Standards Framework for Digital Health Technologies. · Ref. 7 (imhi.com/en/mhts/references/#ref-7)
4. [source-4] World Health Organization, War Trauma Foundation and World Vision International. Psychological First Aid: Guide for Field Workers. 2011. · Ref. 3 (imhi.com/en/mhts/references/#ref-3)
5. [source-5] Information Commissioner's Office (ICO). What Are the Rules on Special Category Data? · Ref. 9 (imhi.com/en/mhts/references/#ref-9)
6. [source-6] Medicines and Healthcare products Regulatory Agency (MHRA). Digital Mental Health Technology: Qualification and Classification. 2025. · Ref. 8 (imhi.com/en/mhts/references/#ref-8)

Full references (imhi.com/en/mhts/references/)


---

## 8. FAQs
*Source: imhi.com/en/mhts/faqs/*


### FAQs

Answers to common questions about the Mental Health Technology Standards.

## General Questions {#general-questions}

### What is MHTS? {#what-is-mhts}

**Answer:** MHTS stands for Mental Health Technology Standards. It is a set of seven publicly available structural and ethical requirements for technologies intended to regulate, support or influence emotional and mental states.

### Who created MHTS? {#who-created-mhts}

**Answer:** MHTS is an initiative of the International Mental Health Infrastructures (IMHI) Group.

### Why was MHTS created? {#why-was-mhts-created}

**Answer:** No safety standard set specific design safeguards for digital mental-health technology; existing standards are largely general or process-based. MHTS was created as the first to do so, addressing risks associated with technologies affecting emotional and mental states, particularly when users are vulnerable to psychological manipulation, unnecessary surveillance, barriers to support and dependency-generating design.

### Is MHTS internationally applicable? {#is-mhts-internationally-applicable}

**Answer:** The standards are published for international consideration and voluntary adoption. However, applicable laws, clinical requirements and technology regulations differ between jurisdictions.

### Is MHTS free to use? {#is-mhts-free-to-use}

**Answer:** The published standards are publicly accessible without a requirement to purchase the document. The existence of an open public standard should not be interpreted as granting rights beyond any applicable published terms.

### Is adoption mandatory? {#is-adoption-mandatory}

**Answer:** MHTS v1.0 is a voluntary public standard. It does not itself establish a legal obligation to adopt MHTS. Other legal or regulatory requirements may apply independently.

## Applicability {#applicability}

### Which technologies are covered? {#which-technologies-are-covered}

**Answer:** MHTS concerns technologies intended to regulate, support or influence emotional and mental states. Examples include relevant digital mental-health applications, self-guided emotional-support tools and interactive mental-health systems.

### Does MHTS apply to AI chatbots? {#does-mhts-apply-to-ai-chatbots}

**Answer:** AI chatbots intended to provide emotional or mental-health support fall within the types of technologies MHTS is designed to address. Their conversational interfaces, data flows, engagement mechanisms and human-support pathways should be evaluated against the published requirements.

### Does MHTS apply to wellness applications? {#does-mhts-apply-to-wellness-applications}

**Answer:** A wellness application may be relevant if its intended purpose or functionality involves regulating, supporting or influencing emotional states. The applicability of individual requirements should be considered in relation to the actual technology and its intended use.

### Does MHTS apply to clinical technologies? {#does-mhts-apply-to-clinical-technologies}

**Answer:** MHTS may be relevant to clinical digital-health technologies, but it does not replace clinical standards, medical-device regulation or professional obligations.

### Does MHTS apply to Psychological First Aid technologies? {#does-mhts-apply-to-psychological-first-aid-technologies}

**Answer:** Yes. The published MHTS introduction expressly includes technologies that may apply Psychological First Aid teachings, training or certification for public use.

### Does every website discussing mental health need to comply? {#does-every-website-discussing-mental-health-need-to-comply}

**Answer:** MHTS is directed at technologies intended to regulate, support or influence emotional and mental states. A general information website and an interactive acute-distress intervention may have substantially different purposes and functionality. The relevant scope should be examined rather than assuming that all websites discussing mental health perform the same role.

## Privacy & Data {#privacy-and-data}

### Can MHTS-conforming technologies use analytics? {#can-mhts-conforming-technologies-use-analytics}

**Answer:** Only measurement approaches consistent with the published requirements can be considered. MHTS prohibits cookies, cross-site tracking, third-party behavioural profiling and undisclosed data flows. Privacy-preserving aggregate measurement may be possible without these mechanisms. Actual implementation must be examined.

### Are cookies permitted? {#are-cookies-permitted}

**Answer:** No. MHTS Standard 2 (imhi.com/en/mhts/the-seven-standards/#no-behavioural-surveillance) explicitly prohibits cookies.

### Can personal information be collected? {#can-personal-information-be-collected}

**Answer:** Standard 1 (imhi.com/en/mhts/the-seven-standards/#anonymous-by-design) prohibits capturing names, email addresses and identifiable personal data within the mental-health technology covered by the requirement. The objective is to make stabilisation available without extracting identity.

### Does avoiding names and email addresses establish anonymity? {#does-avoiding-names-and-email-addresses-establish-anonymity}

**Answer:** No. A system may identify individuals through technical identifiers, retained network information or other data. Anonymity requires examining actual information capture and processing.

### How can effectiveness be measured without tracking individuals? {#how-can-effectiveness-be-measured-without-tracking-individuals}

**Answer:** Some outcomes can be measured through non-identifiable aggregate information. For example, a service may collect anonymous completion counts or optional, non-identifying responses concerning perceived emotional change. The methodology must be designed so that the information cannot reasonably identify people. The resulting evidence should be interpreted according to its limitations.

### Must collected data be made public? {#must-collected-data-be-made-public}

**Answer:** Standard 7 (imhi.com/en/mhts/the-seven-standards/#public-accountability) requires public access to the non-identifiable data collected by the technology, together with a clear explanation of how effectiveness and impact are measured. Publishing identifiable information is not permitted by the other MHTS requirements.

### Can third-party services be used? {#can-third-party-services-be-used}

**Answer:** MHTS expressly prohibits third-party behavioural profiling and requires confirmation that no third-party behavioural data processors are used. It also prohibits undisclosed data flows. Other technical services must be evaluated according to their actual function and data practices. Their mere description as hosting, infrastructure or analytics services does not establish conformance.

## Design & Safety {#design-and-safety}

### Why does MHTS prohibit streaks? {#why-does-mhts-prohibit-streaks}

**Answer:** Standard 5 (imhi.com/en/mhts/the-seven-standards/#no-dependency-engineering) prohibits streak-based retention systems because they can use a person's vulnerability to build dependence, which conflicts with their independence and mental-health interests. The intended purpose of mental-health support is to benefit the user, not to encourage habitual return for its own sake.

### Are all notifications prohibited? {#are-all-notifications-prohibited}

**Answer:** No. The published requirement specifically prohibits notifications designed to reactivate vulnerability, alongside shame-based reminders and other dependency-generating mechanisms. Notifications should be evaluated according to their actual purpose and design.

### Why must stabilisation come first? {#why-must-stabilisation-come-first}

**Answer:** MHTS Standard 4 (imhi.com/en/mhts/the-seven-standards/#stabilisation-before-interpretation) establishes that, in relevant distress states, physiological regulation should precede reflection, analysis or education. The purpose is to avoid introducing unnecessary cognitive demands before attempting immediate stabilisation. This is an MHTS design requirement, not a claim that one intervention sequence is clinically appropriate for every situation.

### Does MHTS prescribe particular psychological exercises? {#does-mhts-prescribe-particular-psychological-exercises}

**Answer:** No. MHTS establishes structural and ethical requirements rather than a complete clinical intervention protocol. Developers must separately consider the suitability and evidence base of their specific interventions.

### Must a technology provide human support? {#must-a-technology-provide-human-support}

**Answer:** Standard 6 (imhi.com/en/mhts/the-seven-standards/#human-escalation-supremacy) requires clear access to real human emotional-support services. This does not necessarily mean the technology provider must operate its own counselling or crisis service. Relevant external pathways may provide access, provided the published requirement is satisfied.

### Are emergency services required? {#are-emergency-services-required}

**Answer:** Yes. Standard 6 requires clear access to local emergency services. The implementation should be appropriate to the intended users and their locations.

### Can an AI system replace a therapist? {#can-an-ai-system-replace-a-therapist}

**Answer:** MHTS prohibits digital tools from positioning themselves as substitutes for human care or claiming authority over treatment. AI may provide certain forms of assistance, but it must not misrepresent its capabilities or obstruct appropriate professional support.

## Compliance & Verification {#compliance-and-verification}

### How is MHTS compliance checked? {#how-is-mhts-compliance-checked}

**Answer:** Technologies can be reviewed against the seven published standards. This involves examining the relevant functionality, architecture, interfaces, data practices and publicly available information. An online self-assessment is also available at mhts.org (https://mhts.org) .

### Can organisations assess themselves? {#can-organisations-assess-themselves}

**Answer:** Yes. The published MHTS resources provide a compliance self-assessment. Self-assessment should accurately reflect the technology's actual operation and the evidence available.

### Is MHTS certification available? {#is-mhts-certification-available}

**Answer:** The published v1.0 materials establish an open standard and compliance self-assessment but do not describe an independent accredited certification programme. A self-assessment must not be represented as independent certification.

### Can a technology conform to only some standards? {#can-a-technology-conform-to-only-some-standards}

**Answer:** A technology may satisfy some requirements while failing others. An organisation can describe those findings accurately. However, partial satisfaction should not be presented as complete conformance with all seven standards.

### Does MHTS conformance prove clinical effectiveness? {#does-mhts-conformance-prove-clinical-effectiveness}

**Answer:** No. Conformance with structural and ethical requirements is separate from evidence that a technology produces particular clinical or psychological outcomes.

### Can MHTS replace a security audit? {#can-mhts-replace-a-security-audit}

**Answer:** No. MHTS addresses specified privacy and ethical-design requirements. A technology may still require broader security testing, clinical evaluation or regulatory assessment.

## Governance & Regulation {#governance-and-regulation}

### Who maintains MHTS? {#who-maintains-mhts}

**Answer:** MHTS is published as an initiative of the International Mental Health Infrastructures (IMHI) Group.

### What is the current version? {#what-is-the-current-version}

**Answer:** The published version referenced in this documentation is MHTS v1.0.

### How are the standards updated? {#how-are-the-standards-updated}

**Answer:** The official standards page identifies the published version. This documentation does not assume an amendment or consultation process that has not been publicly established. Readers should refer to the official website for the current requirements.

### How does MHTS relate to existing industry standards? {#how-does-mhts-relate-to-existing-industry-standards}

**Answer:** MHTS complements other frameworks by addressing specific ethical and structural safeguards. It does not replace established health-app quality standards, clinical-evidence frameworks, privacy legislation or medical-device regulation.

### Does voluntary adoption have legal implications? {#does-voluntary-adoption-have-legal-implications}

**Answer:** Adopting MHTS does not itself create a universal regulatory approval or exemption. An organisation's public representations about its product and conformance should nevertheless be accurate and consistent with applicable law.

### Where can I read the official standards? {#where-can-i-read-the-official-standards}

**Answer:** mhts.org (https://mhts.org)

### Where can I check a technology against MHTS? {#where-can-i-check-a-technology-against-mhts}

**Answer:** mhts.org (https://mhts.org)


---

## References
*Source: imhi.com/en/mhts/references/*


### References

Research, professional guidance, regulatory publications and other authoritative sources supporting the documentation.

The following publications and official sources provide background on digital mental-health technologies, psychological support, privacy, manipulative design, clinical evidence and regulation. The published MHTS v1.0 document remains the authoritative source for the seven requirements themselves.

## MHTS {#mhts}

1. Mental Health Technology Standards (MHTS). Standards v1.0. International Mental Health Infrastructures (IMHI) Group.
2. Mental Health Technology Standards (MHTS). Compliance Assessment. International Mental Health Infrastructures (IMHI) Group.

## Psychological Support & Safety {#psychological-support-and-safety}

3. World Health Organization, War Trauma Foundation and World Vision International. Psychological First Aid: Guide for Field Workers. 2011.

## Ethical Technology & Manipulative Design {#ethical-technology-and-manipulative-design}

4. Federal Trade Commission. Bringing Dark Patterns to Light. 2022.

## Digital Mental Health Evaluation {#digital-mental-health-evaluation}

5. American Psychiatric Association. The App Evaluation Model.
6. International Organization for Standardization. ISO/TS 82304-2:2021: Health Software, Part 2: Health and Wellness Apps, Quality and Reliability.
7. National Institute for Health and Care Excellence (NICE). Evidence Standards Framework for Digital Health Technologies.

## Medical-Device Regulation {#medical-device-regulation}

8. Medicines and Healthcare products Regulatory Agency (MHRA). Digital Mental Health Technology: Qualification and Classification. 2025.

## Privacy & Data Protection {#privacy-and-data-protection}

9. Information Commissioner's Office (ICO). What Are the Rules on Special Category Data?
10. Information Commissioner's Office (ICO). Introduction to Anonymisation.

## Mental-Health Technology Governance {#mental-health-technology-governance}

11. Manion A, Faveri B, Marchant GE. Mental Health App Governance: International Landscape, Gaps, and Soft Law Recommendations. Jurimetrics. 2025;65:97–138.
12. Australian Commission on Safety and Quality in Health Care. National Safety and Quality Digital Mental Health Standards. 2020.

## Psychological Vulnerability & Persuasion {#psychological-vulnerability-and-persuasion}

13. Doroc K, Yadav N, Murawski C. Acute Stress Impairs Decision-Making at Varying Levels of Decision Complexity. Communications Psychology. 2025.
14. Das E, de Wit JBF, Stroebe W. Fear Appeals Motivate Acceptance of Action Recommendations: Evidence for a Positive Bias in the Processing of Persuasive Messages. Personality and Social Psychology Bulletin. 2003;29(5):650–664.
15. Paterson J, Ananthapadmanaban SM. Data Privacy and Consumer Protection Practices of Automated Mental Health, Wellbeing and Mindfulness Apps. Centre for AI and Digital Ethics, University of Melbourne. 2023.


---