Compliance briefing
NHS medical device classification assessment
Holdfast's self-assessed position on an unresolved question: whether Holdfast is a medical device at all under the UK Medical Device Regulations 2002, and if so, why Class I would most likely apply - reached by testing Holdfast against MHRA's own published worked examples for stand-alone software.
Revised after reading MHRA's published stand-alone software guidance and appendices in full. Every claim below about "MHRA guidance says..." is drawn directly from that source, with page references given inline.
This is a self-assessment written by the product team, not a legal or regulatory determination, and it does not resolve the scope question itself. Whether Holdfast falls within the definition of a medical device - and if so, which class - is a legal judgement that should be confirmed in writing by the MHRA (via its borderline/classification advice service) or a qualified UK Responsible Person/regulatory consultant. Holdfast is not currently registered with the MHRA, is not UKCA-marked, and makes no claim of completed regulatory certification. Until that confirmation exists, Holdfast should be read as an NHS digital workflow tool of unconfirmed regulatory status, not as a declared medical device.
Product one-liner: Holdfast is a digital check-in and risk-monitoring tool for NHS Trust/ICB mental health waiting lists. Patients complete short structured check-ins while they wait; each check-in is scored against explainable, rules-based clinical safety criteria; scores above threshold auto-escalate to a named support worker or clinician, with every state change written to an audit trail. It is not a diagnostic tool, not a chatbot, and does not use AI/ML in any clinical-safety-relevant path.
Section 1
What Holdfast is, precisely
Holdfast is a waiting-list monitoring and escalation tool, not a diagnostic or treatment device. It:
- Collects structured, patient-reported responses (a short check-in and standard NHS-used questionnaires - PHQ-9, GAD-7, and similar validated instruments) from people already referred into an NHS mental health care pathway and already on that service's waiting list.
- Applies a fixed, published, deterministic set of scoring rules to those responses to produce a Red/Amber/Green prioritisation label and a set of named reasons.
- Where the label crosses a threshold, notifies a named human clinician or support worker - it does not itself deliver, recommend, or withhold any clinical intervention.
- Displays the resulting caseload, in priority order, to staff who are already responsible for that patient's care under their existing clinical governance.
What Holdfast never does
- It does not produce or display a diagnosis.
- It does not recommend a treatment, medication, dose, or care pathway change.
- It does not use AI, machine learning, or any non-deterministic/probabilistic model anywhere in the check-in-to-escalation path - every point in every score traces to a single named, human-readable rule, and the scoring logic is treated as the single highest-risk piece of the product, held to a correspondingly high automated test-coverage standard.
- It does not interpret free-text patient input algorithmically - concerning free text is flagged for a human to read, never scored or acted on by the software itself.
- Patients never see a score, rating, or risk category - only a plain acknowledgement and, where risk is disclosed, crisis signposting to existing NHS/third-sector crisis services (NHS 111 option 2, Samaritans, Shout, 999) that already exist independently of Holdfast.
- It does not replace, delay, or gate access to any clinical decision a human would otherwise make - the person remains on the same waiting list, under the same service, regardless of what Holdfast shows.
Section 2
Is Holdfast a medical device at all?
Under the UK MDR 2002, a device is a medical device if intended by the manufacturer to be used for one of a list of medical purposes: prevention, diagnosis, monitoring, treatment/alleviation, compensation, investigation/replacement/modification of a physiological process, or control of conception (MHRA stand-alone software guidance). Purely administrative software - booking, patient education, general fitness/wellbeing monitoring, or reference information a clinician weighs with their own knowledge - falls outside that definition. Two readings of Holdfast are possible; MHRA's own published examples make one of them materially stronger than the other.
| Reading | Position |
|---|---|
| A - not a medical device | Holdfast digitises the collection of already-validated, standard NHS assessment instruments (PHQ-9, GAD-7, and similar) and structures communication and staff attention around them, which could be argued as an administrative/workflow function comparable to non-device NHS digital PROMs tools. The strongest support for this reading is MHRA's "clinical calculators" guidance: scoring that is a simple addition of integer points against listed criteria, easily verified by the intended user, is unlikely to be a device - and Holdfast's scoring engine is exactly that shape (named weights, summed, compared against a threshold, every point traceable in the reasons shown to staff). |
| B - in scope as a device | MHRA's guidance on the "Monitoring" medical-purpose category states almost exactly Holdfast's shape: software that monitors a patient and collects information entered by the user "may qualify as a medical device if the output is intended to affect the treatment of an individual." The "Diagnosis" category separately distinguishes patient-specific risk output (likely a device) from population-level risk output (unlikely to be a device) - Holdfast's score is calculated per patient, per check-in. And MHRA's decision-support test states that software which performs a calculation the healthcare professional does not then re-derive from raw data "may be considered a medical device" - which describes how staff act on Holdfast's RAG label and escalation, not a manual re-check of the raw check-in answers. |
On balance, this assessment now treats Reading B as the better-supported reading. The calculator carve-out in Reading A addresses only the mechanical simplicity of the scoring; it does not answer the Monitoring category's separate test, which turns on intended effect (an automated, patient-specific output intended to affect an individual's care), not on how the number was computed. Holdfast's automatic, threshold-triggered escalation is the feature that MHRA's own "simply replace a written diary/log" carve-out explicitly excludes ("the addition of features that enhance the data presented may bring it into the remit of the UK MDR 2002"). This is a self-assessed lean, not a determination - MHRA has not confirmed this classification, which is precisely why the next-steps section below recommends putting this reasoning to MHRA directly, with the specific guidance sections cited, so they can confirm or correct it quickly rather than starting from a blank page. The section below sets out the classification analysis that follows if Reading B is confirmed.
Section 3
If Holdfast is a medical device: classification analysis - why Class I
This section is conditional on Reading B in Section 2 being confirmed - it does not argue Holdfast is in scope, only that if MHRA or a regulatory advisor determines it is, Class I is the most defensible class, for the reasons set out below.
The relevant rules: Implementing rule 2.3 and Rules 9/10/12/14 - not "Rule 11"
An earlier version of this document analysed classification under "Rule 11 (software)," borrowed from the EU MDR 2017/745 Annex VIII software rule. This was a mis-citation, corrected here: UK MDR 2002 was never updated to the EU's 2017 classification annex and has no dedicated software rule. MHRA's own guidance sets out the rules that actually govern standalone software in Great Britain:
- Implementing rule 2.3 - software that drives or influences the use of a physical device takes that device's classification. Not applicable - Holdfast does not drive or influence any physical device.
- Rule 9 - active therapeutic devices that administer/exchange energy are Class IIa (or IIb if hazardous). Not applicable - Holdfast does not administer or exchange energy.
- Rule 10 - active devices intended for diagnosis are Class IIa, but specifically only those that "allow direct diagnosis" - defined as providing a diagnosis itself, providing decisive information for making a diagnosis, or claiming to perform/support a clinician's diagnostic task.
- Rule 14 - devices for contraception/STI prevention are Class IIb. Not applicable.
- Rule 12 - the catch-all: "all other active devices are class I."
The question this actually turns on, if Holdfast is confirmed in scope, is narrower than the previous "Rule 11" framing suggested: does Holdfast's escalation function "allow direct diagnosis" under Rule 10 (→ Class IIa), or does it fall to the Rule 12 catch-all (→ Class I)? MHRA's own symptom checker appendix answers this exact question for the closest published analogue to a check-in-and-triage tool: a severity/red-flag output plus signposting to a human is "may be a device," and "symptom checker devices will be class I unless considered to 'allow direct diagnosis', in which case they will be class IIa." Holdfast never labels a condition, provides a diagnosis, or claims to perform a clinician's diagnostic task - it produces a prioritisation label - so on this analogy it does not "allow direct diagnosis," and Class I via Rule 12 is the better-supported outcome.
Where Holdfast sits, and why
Holdfast's argument for Class I rests on the distinction MHRA guidance draws between software that makes or drives a clinical decision (Rule 10, "allows direct diagnosis") and software that supports the operational workflow around a decision a human already makes (Rule 12, the catch-all) - the same distinction the symptom-checker appendix draws explicitly:
| Factor | Holdfast's position |
|---|---|
| Does it diagnose? | No - it never labels a condition. It scores a check-in for prioritisation only. |
| Does it recommend treatment? | No - the product has no treatment-recommendation logic anywhere. |
| Does it act autonomously on a patient? | No - every escalation is a notification to a human; no automated action is ever taken on the patient's care. |
| Is the underlying logic explainable and human-auditable? | Yes - a fixed, versioned rules table, not a model. A clinician/CSO can read every rule that can ever fire. |
| Does a clinician retain full decision-making authority? | Yes - Holdfast surfaces information and a queue order; the named worker/clinician decides what to do, exactly as they would from a phone call or spreadsheet today. |
| Could a software fault directly cause death or irreversible harm on its own, without a human decision in the loop? | The realistic failure mode is a missed or delayed prioritisation signal - a workflow failure that could contribute to a delay in an existing care pathway, not a device that itself administers or withholds care. The product's own clinical-safety hazard log rates the relevant hazards as HIGH-initial/MEDIUM-residual after mitigation, rather than catastrophic-severity Class III/IIb failures. |
On this basis, Holdfast's manufacturer position is that it functions as a clinical workflow/triage support and communication tool that operates around an existing, human-led care pathway - analogous to other Class I software used to structure and prioritise clinical workload - rather than software whose output is itself used to diagnose or determine treatment.
The honest counter-argument within Reading B (documented, not hidden)
Even accepting Reading B (Holdfast is in scope), a conservative reviewer could argue the self-harm escalation function is providing "decisive information for making a diagnosis" of imminent risk - one of the three limbs of MHRA's "allow direct diagnosis" test above - which would move Holdfast to Class IIa under Rule 10 rather than Class I under Rule 12. This assessment does not dismiss that reading - it is precisely why:
- This document recommends formal confirmation by the MHRA, a UK Responsible Person, or a regulatory consultant - covering both whether Holdfast is in scope at all and, if so, whether the escalation function "allows direct diagnosis" under Rule 10 or falls to Rule 12 - before Holdfast is marketed or self-declared as any specific class.
- The product has been deliberately engineered to keep every safety-relevant decision human-in-the-loop and explainable, which is the single strongest mitigating factor available regardless of how the scope question or the class question here is ultimately resolved.
- Should Class IIa be the confirmed outcome, most of the technical and clinical-safety evidence collected here remains directly reusable - the DCB0129 hazard log, the audit trail, the explainable scoring - since Class IIa conformity assessment builds on the same clinical risk management foundation, with the addition of a notified-body conformity assessment rather than pure self-declaration.
Section 4
Regulatory and safety standards - status
| Requirement | What it means | Status |
|---|---|---|
| MHRA scope/classification determination | Before registration or marking can happen, whether Holdfast is a medical device at all, and if so which class, needs formal confirmation. | Not yet sought - this is the gating step for everything below. |
| MHRA registration | If confirmed in scope, Class I software manufacturers must register with the MHRA before placing the device on the UK market. | Not applicable yet / not registered - gated on the scope and classification determination above. |
| UKCA marking | If confirmed in scope as Class I, devices are UKCA-marked via manufacturer self-declaration of conformity (no notified body required for Class I, unless the device has a measuring function or is supplied sterile - neither applies to Holdfast). | Not applicable yet / not self-declared - requires the scope determination, a Declaration of Conformity, a Technical File, and MHRA registration first. |
| UK Responsible Person | A manufacturer based outside the relevant jurisdiction, or as a matter of good governance, typically designates a UK Responsible Person to interface with the MHRA. | Not yet appointed - relevant once the scope determination confirms Holdfast is in scope as a device. |
| DCB0129 (manufacturer clinical risk management) | Requires a named Clinical Safety Officer and a maintained hazard log through the product lifecycle. | Partial - hazard log exists and is live-evidenced in the product; independent CSO sign-off against the full DCB0129 template is outstanding. |
| DCB0160 (deploying organisation's clinical risk management) | Applies to each NHS Trust/ICB that deploys Holdfast into their own care pathway - their own CSO must risk-assess the local deployment. | Deploying org's responsibility - Holdfast's hazard log and audit evidence are designed to be the primary input for it. |
| Technical File | The MDR-required design/manufacture/risk-management documentation package supporting the Declaration of Conformity. | Partial - this assessment and the DTAC self-assessment together constitute most of the evidence, but have not been assembled into the MDR Technical File format. |
| Post-market surveillance plan | An ongoing obligation under UK MDR to monitor and act on safety issues after market placement. | Not yet documented as a standalone plan; the product's existing audit trail and security-event telemetry provide the underlying data source. |
Section 5
Evidence already in place supporting a Class I safety case
This section collects all of the concrete evidence a regulatory reviewer would look for.
Deterministic, auditable logic
A fixed, testable rules engine drives every risk score, held to a minimum 90% automated test-coverage standard, with every score traceable to a named rule.
Hazard log with live monitoring evidence
Eleven formally logged clinical hazards, each with documented existing controls and a live query against production data as evidence the control is actually operating - not a static compliance claim.
Complete audit trail
Every check-in, escalation, notification, and record change is written to an immutable audit log capturing who acted, what they did, on which record, and when.
No autonomous clinical action
Confirmed by design and code review - every escalation is a notification record, never an automated care-pathway change.
Independent crisis safety net
Crisis signposting always points to pre-existing NHS/third-sector services (NHS 111, Samaritans, Shout, 999), not to any Holdfast-operated response capability - the software routes people to safety mechanisms that already exist, rather than claiming to be one itself.
Human-in-the-loop by design
Patients never see their own score; only named staff, already responsible for that patient's care, see escalations and caseload prioritisation.
Section 6
Recommended next steps (not yet complete)
- Put this self-assessed reasoning to MHRA directly and ask them to confirm or correct it - citing the specific sections of their own guidance this document relies on (the "Monitoring" category, the patient-specific-vs-population- level "Diagnosis" test, the decision-support test, the clinical calculators appendix, and the symptom checkers appendix and its Class I/Class IIa split) via MHRA's Customer Services Centre, a UK Responsible Person, or a regulatory consultant - before any public claim about device status or class is made. Leading with a guidance-referenced position, rather than an open question, should get a faster and more useful response than a cold borderline query. This is the gating step; everything below depends on its outcome.
- If confirmed in scope: confirm Class I under Rule 12 vs Class IIa under Rule 10 as part of the same advice, then compile the MDR Technical File from the evidence already assembled in this assessment and the DCB0129 hazard log, register with the MHRA, and self-declare UKCA conformity.
- If confirmed out of scope: document that outcome and continue on the DTAC-only route already in place - DCB0129 clinical risk management still applies as NHS good practice regardless of MDR status, but MHRA registration/UKCA marking would not be required.
- Commission independent DCB0129 sign-off by a named Clinical Safety Officer external to the development team - worth doing in parallel with step 1, since it is required either way.
- Document a post-market surveillance plan drawing on the existing audit trail and security-event telemetry as its data source, if the device route (step 2) is confirmed.
- Re-seek classification advice if the product's scope changes - in particular, if any future feature moves toward recommending a specific treatment, medication, or care-pathway decision (rather than prioritising existing human review), the position in Section 2 must be re-assessed, as that would materially strengthen the case for being in scope as a device.
Summary for NHS stakeholders: Holdfast's self-assessed, evidence-weighted position - reached by testing the product against MHRA's own published worked examples for stand-alone software, not yet confirmed by MHRA - is that Holdfast is more likely than not a medical device, and, if so, most likely Class I under the Rule 12 catch-all, on the strength of the direct analogy to MHRA's published symptom-checker guidance. It is, in any case, an explainable, rules-based clinical workflow and communication tool that helps an existing NHS care team notice and respond to a person on their waiting list, without ever diagnosing, recommending treatment, or acting autonomously on a patient. Class IIa under Rule 10 remains a credible alternative reading if the escalation function is judged to provide decisive diagnostic information. The clinical safety engineering (deterministic scoring, complete audit trail, human-in-the-loop escalation, crisis signposting to existing services) is built to a standard that supports either outcome. Putting this reasoning to MHRA for confirmation is the outstanding next step before any device-status or class claim should be relied upon commercially.