An AI front door should help a person reach appropriate human care; it should never become a locked door labelled “efficient triage”. The safest early uses collect structured information, identify missing fields and route messages under explicit clinical rules. Once software interprets symptoms, assigns urgency or recommends action, the clinical, evidence and medical-device stakes rise sharply.
This guide is current to 31 July 2026 and focuses on NHS and independent-provider workflows in England. Health services, assurance arrangements and incident routes differ across the four UK nations. Medical-device rules also distinguish Great Britain from Northern Ireland. Providers must obtain clinical-safety, information-governance, regulatory and legal advice for the actual product and intended purpose. This is not medical advice.
Separate intake, routing and clinical triage
Teams often call three different activities “triage”:
| Activity | Example output | Risk boundary | Appropriate first pilot |
|---|---|---|---|
| --- | --- | --- | ---: |
| Administrative intake | Correct patient and contact details | Identity and record accuracy | Yes |
| Message classification | Prescription, appointment, result or clinical query | Wrong queue or delay | With controls |
| Clinical prioritisation | Urgency or care disposition | Patient harm | Only with full clinical assurance |
| Diagnostic support | Possible condition or test recommendation | Medical-device and evidence risk | Not a first pilot |
| Safety-netting | What to do if symptoms worsen | Clinical communication | Approved rules and review |
Write an intended-purpose statement that names users, population, setting, inputs, output, decision and exclusions. “AI assistant for primary care” is inadequate. “Classifies authenticated online requests into six administrative queues; it does not assign clinical urgency” is testable.
Do not expand the purpose through prompts. A product procured for summarisation may still function as a medical device if configured to influence a medical decision. Ask the MHRA or competent specialist where classification is uncertain.
Map the existing care pathway
Document every entry route: telephone, walk-in, NHS App or web form, email, referral and carer contact. For each, record opening hours, identity checks, language and accessibility support, queue owner, response standard, escalation and downtime process.
The digital route must not degrade telephone or reasonable-adjustment access. Measure whether people abandon the form, cannot express a concern or switch channels repeatedly. Preserve the original patient words alongside any summary; clinical nuance can disappear when a model normalises language.
Build a hazard-aware state model:
- request received and timestamped;
- identity and contact route confirmed;
- immediate-emergency message displayed under approved policy;
- input completeness checked;
- administrative or clinical route proposed;
- trained person reviews according to the risk class;
- patient receives confirmation and expected response;
- action is documented in the clinical record; and
- safety-net or escalation remains visible until closure.
A queue is not closed because the AI produced text. Closure requires the defined human or system action and patient communication.
Apply clinical-safety standards locally
NHS England’s digital clinical safety assurance guidance explains DCB0129 for manufacturers and DCB0160 for deploying organisations. The supplier’s DCB0129 evidence does not replace the provider’s local DCB0160 assessment. Local staffing, integrations, patient population and fallback can introduce hazards the manufacturer did not evaluate.
NHS England published a national review of DCB0129 and DCB0160 in June 2026. Section 250 was amended in July 2025 to create a “must comply” route, but NHS England says bodies must continue to have regard to the current versions; future revisions are likely to use the enhanced power. Do not implement a consultation idea as though a revised standard has already commenced.
Appoint a qualified Clinical Safety Officer and maintain:
- clinical risk-management plan;
- hazard log with cause, control and residual risk;
- clinical safety case and safety case report;
- test evidence linked to each control;
- deployment configuration and interface map;
- staff competence and training record;
- incident and near-miss route; and
- post-deployment review schedule.
Model change, prompt change, new language, new queue or altered threshold can change the safety case. Put them through controlled change assessment.
Complete product and regulatory assurance
The current Digital Technology Assessment Criteria covers clinical safety, data protection, technical security, interoperability, and usability and accessibility. NHS England introduced a revised form in February 2026 and states the previous form should not be used from 6 April 2026. DTAC supports assurance; it does not replace medical-device certification or other approvals.
MHRA’s collection on software and AI as a medical device helps teams determine whether intended purpose brings a product within medical-device regulation. March 2026 guidance on when a device needs a clinical investigation applies to England, Scotland and Wales and was clarified in July 2026. Northern Ireland follows a different device route.
Keep a regulatory file with intended purpose, classification rationale, conformity status, device version, post-market obligations, serious-incident route and change-control plan. Do not rely on the vendor’s phrase “not diagnostic”; evaluate what the configured system actually does.
Use NICE’s evidence standards framework for digital health technologies to plan evidence appropriate to function and risk. NICE makes clear that meeting the framework is not itself endorsement or regulatory approval.
Design red flags and safety-netting
Emergency messaging should be written and approved by clinicians for the service and jurisdiction. Do not ask a generative model to improvise red flags from open-web content. Display emergency routes before a long form where delay could matter, while avoiding a design that sends every user to emergency care.
For each clinical presentation in scope, define:
- minimum information required;
- factors that prevent automated routing;
- maximum wait before human review;
- immediate escalation route;
- age, pregnancy or vulnerability exclusions;
- language and communication accommodations;
- approved patient acknowledgement; and
- safety-net wording and expiry.
Never suppress an explicit patient concern because other answers lower a score. Preserve negation and uncertainty: “not sure if chest pain” must not become “no chest pain”. Test spelling, colloquial language, multiple symptoms, copied text, third-party submissions and people who cannot complete structured fields.
If the system is uncertain, the safe response is the defined human queue, not a confident default. Monitor excessive escalation too; overwhelming the urgent queue can create harm elsewhere.
Validate on the local population
Overall routing accuracy hides dangerous minority failures. Build a test set from representative, lawfully used local cases plus synthetic edge cases reviewed by clinicians. Separate development and evaluation periods and prevent near-duplicate messages crossing them.
Report:
- sensitivity for each safety-critical route;
- false-negative and false-positive rates;
- time from request to appropriate review;
- under-triage and over-triage severity;
- “unable to classify” rate;
- performance by age, language, disability access and other justified groups;
- summary omission and negation errors;
- patient abandonment and channel switching; and
- clinician override with outcome.
Do not infer protected characteristics merely to create a dashboard. Establish the lawful, proportionate route for fairness evaluation and use minimum necessary data.
The target should compare with current practice, not perfection. Investigate discordant cases through blinded clinical review where practical. An algorithm agreement statistic is not evidence of better outcomes.
Protect confidentiality and patient choice
Map controller and processor roles, lawful basis, common-law confidentiality, purpose, retention, sub-processors, international transfers and patient-rights handling. A supplier should not reuse patient prompts to improve a general model unless a separate, lawful and transparent route supports that purpose.
Apply role-based access to original messages, summaries and hazard logs. Pseudonymise evaluation extracts and keep re-identification keys separately. Do not export entire records when the pilot needs only request text, route, timing and outcome.
All organisations accessing NHS patient data and systems are expected to use the Data Security and Protection Toolkit. NHS England’s June 2026 board and executive cyber-assurance guidance describes DSPT objectives and executive accountability.
Tell patients:
- that automation assists the process;
- what it does and does not decide;
- who can see the information;
- expected response time;
- how to provide additional context;
- how to use a non-digital route;
- how to report an error; and
- what to do if their condition changes.
Consent to receive care is not automatically consent for product training or unrelated research.
Secure every interface
Treat incoming text and files as untrusted. A malicious or accidental instruction in a document must not alter routing rules or reveal another patient’s information. Give the classifier only the minimum record context and no general write access to the electronic patient record.
Use single sign-on, multi-factor authentication, least privilege, network and tenant separation, encrypted transport, signed updates, monitored service accounts and immutable audit logs. Test:
- the wrong patient matched to a request;
- copied text containing another person’s details;
- an unavailable model or identity service;
- clock or queue failure during out-of-hours handover;
- prompt injection in an attachment;
- a vendor model update changing routes;
- duplicate submissions;
- hostile account takeover; and
- inability to write the final action to the record.
The fallback must be a staffed, rehearsed process with queue reconciliation after recovery. Never delete the original because a summary has been stored.
Pilot for 90 days with pause authority
| Period | Work | Release gate |
|---|---|---|
| Days 1–20 | Define purpose, pathway, baseline, hazard log and equity questions | CSO and accountable clinical leader approve scope |
| Days 21–40 | Complete DTAC, DCB0160, DPIA, regulatory and supplier review | No unresolved unacceptable risk |
| Days 41–60 | Offline validation and simulation across failure cases | Safety-critical sensitivity meets preset threshold |
| Days 61–78 | Shadow routing with existing process authoritative | Review burden and queue behaviour are safe |
| Days 79–90 | Limited live administrative routing with rapid rollback | Patient, safety, access and service gates hold |
Pause immediately after a possible under-triage harm, wrong-patient disclosure, missing original message, unreviewed clinical disposition, safety-net failure, inaccessible fallback, unexplained performance shift or severe cyber incident. The Clinical Safety Officer and clinical owner—not the vendor alone—decide restart after investigation and documented remediation.
Scale only when no severe event is attributable to the workflow, time to appropriate human review improves, urgent false negatives remain within the clinically approved threshold, digital exclusion does not worsen and staff can operate the fallback. Related archive guides cover clinical administration AI-uk), AI reception in healthcare and healthcare predictive AI.
A safer front door remains a human service
The final product is not a classification model. It is a care pathway with accountable people, verified messages, monitored queues and a patient who knows what happens next.
If the provider cannot reconstruct the original request, the route proposed, the clinician’s decision and the safety-net communicated, the system is not ready to influence access to care—however impressive its demo appears.



