Skip to content

Specialism

Clinical safety and AI assurance for digital mental health and neurodevelopmental products

Mental health and neurodevelopmental services carry risks that generic hazard templates handle badly: disclosure, waiting lists, shared care, multi-informant assessment and long gaps between contacts. This is where we spend a large share of our clinical safety work.

Last reviewed: Guidance in this area changes. We re-check the primary sources when we review a page.

Products we work on

Where this applies

ADHD assessment and management platforms

Structured assessment, titration support, monitoring and shared-care communication with primary care.

Autism and neurodevelopmental pathways

Screening, triage into assessment, multi-informant data collection and long waits between contacts.

Mental health assessment software

Structured instruments, scoring, risk questions and the interpretation placed on a number.

AI clinical documentation and ambient scribes

Consultations where nuance, attribution and disclosure carry unusual clinical weight.

Clinical decision support

Prompts on medication, dose, monitoring intervals and escalation.

Remote monitoring and digital therapeutics

Between-appointment data, self-report, and what happens when a signal deteriorates.

Patient questionnaires and digital assessments

Self-completed instruments used at scale, sometimes without a clinician in the loop.

Medication monitoring

Controlled drugs, physical health monitoring, shared care agreements and titration safety.

AI triage and prioritisation

Ranking who is seen first, where an error is invisible to the person affected.

Digital mental health is a secondary specialism. We work across digital health and healthcare AI generally — see our services for the full picture.

Hazard patterns

What we look for first

  • Risk questions answered into a void

    A self-report instrument captures a disclosure of self-harm or suicidal ideation out of hours, and nothing in the product or the service defines who reads it, when, and what they do next.

  • Score treated as diagnosis

    A screening or rating scale is designed to inform clinical judgement. Presented as a headline number, it starts to substitute for it — inside the service, and in the patient's understanding.

  • Attribution in multi-informant assessment

    Neurodevelopmental assessment draws on the patient, family, school or employer. Recording an observation against the wrong source changes the clinical meaning.

  • Safeguarding content in generated notes

    An ambient or summarising tool omits, softens or misattributes a safeguarding disclosure, and the omission is invisible on review.

  • Shared care and physical health monitoring

    Medication pathways depend on timely physical health checks. If a monitoring prompt fails silently, nobody is looking for the absence.

  • Prioritisation error on long waiting lists

    A triage or ranking feature moves someone down a list. The harm accrues quietly over months and never presents as an incident.

  • Digital exclusion and accessibility

    The people most likely to be excluded by a design decision are often the ones the service most needs to reach.

  • Diagnostic overshadowing in the data

    Physical symptoms recorded in a mental health context are discounted. Products that summarise or filter can reinforce the pattern.

Why familiarity helps

Hazard identification is a questioning exercise. The quality of a hazard log depends almost entirely on whether the right questions were asked about the workflow, the user and the patient.

Knowing how a titration clinic runs, what a shared care agreement expects of a GP, how a long neurodevelopmental waiting list behaves, and where a disclosure typically surfaces in a consultation means we arrive with better questions — and challenge the answers that sound tidy but would not survive a busy Tuesday.

That familiarity supplements, and does not replace, the clinicians who use your product. The strongest hazard workshops we run have your clinical users in the room.

What we do not claim

Assurance AI is led by a UK registered pharmacist and independent prescriber with digital clinical safety training. We do not hold specialist psychiatric credentials, and we do not present ourselves as a mental health clinical service. Where specialist clinical input is needed, we name it as a gap rather than covering it ourselves.

About the practice →

How we work

From intended use to defensible evidence

The route is the same as any other clinical safety engagement, applied with the clinical context in mind. We start with intended use and the clinical pathway, run hazard identification with your clinical users, build a hazard log that names product-specific hazards rather than generic ones, and produce a clinical safety case that argues residual risk is acceptable — with controls your service can actually operate.

Where the product uses AI, the analysis extends to model behaviour, oversight design, change management and monitoring. That work is described in more detail on our AI clinical safety page, and the underlying process is set out in the DCB0129 guide.

If your NHS customer is running a baseline assurance process, the same evidence feeds your DTAC submission, and your named Clinical Safety Officer arrangements will be scrutinised alongside it.

FAQ

Frequently asked questions

Is this a separate service, or your normal clinical safety work?

It is the same clinical safety and AI assurance work — DCB0129 clinical risk management, DTAC readiness, safety cases and Clinical Safety Officer arrangements — applied to a product area where we spend a lot of time. Digital mental health and neurodevelopmental products are a specialism within our practice, not a separate business.

Does Assurance AI provide psychiatric or specialist mental health clinical advice?

No. Assurance AI is led by a UK registered pharmacist and independent prescriber with digital clinical safety training. We are not a psychiatry practice and we do not hold specialist mental health medical credentials. Where a hazard needs a psychiatrist, psychologist, specialist nurse or safeguarding lead, we say so and work with the clinicians you or your NHS customer bring to the table.

Why does clinical familiarity with this area matter for safety work?

Hazard identification is only as good as the questions asked. Familiarity with how mental health and neurodevelopmental services actually run — waiting lists, shared care, titration, multi-informant assessment, missed appointments, risk escalation — means we ask about the workflows and the harm scenarios that generic templates miss. It does not replace input from the clinicians who use your product.

Our product is not a medical device. Do we still need DCB0129?

Possibly. Medical device classification and DCB0129 applicability are separate questions. If your software is used in the delivery of NHS care in England, influences a clinical decision or moves clinical data, an NHS customer is likely to expect DCB0129 evidence regardless of device status. Where you conclude it does not apply, document the reasoning — that assessment is itself useful evidence.

We use an AI model to summarise or triage. What extra evidence will buyers want?

Beyond the standard clinical safety artefacts, expect questions about intended use limits, how the model behaves for the populations you actually serve, what human oversight exists and whether it is realistic under clinical load, how model or prompt changes are assessed, and what you monitor after deployment. Our AI clinical safety work covers each of these.

Next step

Talk about your product with someone who knows the pathway

A short conversation is usually enough to tell whether DCB0129 applies to your product, what your NHS customer is likely to ask for, and where the real clinical hazards sit.