Project Overview and Business Context
The client was a private urgent care group operating walk-in centres across England. Their triage process was informal: a receptionist collected presenting complaint information, a triage nurse made a visual assessment and assigned a waiting priority (urgent, soon, routine), and patients were called in order. The system had no structured documentation, no audit trail, and no mechanism for flagging deteriorating patients who had been in the waiting room for an extended period. A missed deterioration event had led to an adverse outcome and a CQC improvement notice, triggering the project. The requirements were specific: a structured digital triage intake form that collects presenting complaint, key symptoms, vital signs if available, and relevant history; an AI scoring engine that produces a five-level priority score (equivalent to the Manchester Triage System levels) with a plain-English rationale; a clinician override mechanism that allows the triage nurse to adjust the AI score with a documented reason; a waiting room queue display showing current priority assignments; and an alert system for patients whose time in queue exceeds the threshold for their priority level. The CQC clinical governance requirement drove the audit log design: every triage assessment, AI score, clinician override, and queue time alert needed to be logged with timestamps and user IDs for retrospective review.
Technical Architecture and Stack Decisions
The system is built on a Next.js frontend with a Python FastAPI backend, both deployed on AWS. PostgreSQL stores all triage records, audit logs, and configuration data. The triage intake form is a structured multi-step form in Next.js that collects presenting complaint from a controlled vocabulary list (reducing transcription ambiguity), free-text symptom description, available vital signs, and a flag for any red-flag symptoms from a prompted checklist. Completed intake data is sent to a FastAPI endpoint that runs two processes in parallel: a deterministic rules engine that checks for immediate red-flag combinations (any combination that mandates Level 1 - Immediate priority regardless of other factors) and an Anthropic Claude API call that scores the presenting complaint and symptom profile against the Manchester Triage System criteria. The rules engine result takes precedence over the Claude score if it returns Level 1. Claude's output is a structured JSON object: a priority level (1-5), a confidence band, the top three clinical considerations that drove the score, and a plain-English rationale for the triage nurse. The frontend displays the AI triage card to the nurse, who can accept or override with a documented reason. The queue management dashboard updates in real time via WebSocket, showing all current waiting patients with their priority, wait time, and an alert flag if their wait has exceeded the Manchester Triage System target for their level. AWS handles the infrastructure: EC2 for the FastAPI service, RDS PostgreSQL, and CloudWatch for alerting.
Key AI and ML Components
Anthropic Claude is the scoring engine for the AI triage assessment. The system prompt encodes the Manchester Triage System (MTS) criteria in structured form: the five priority levels, the clinical discriminators that define each level, and the presenting complaint categories with their associated discriminator trees. Claude receives the structured intake data (presenting complaint category, free-text symptoms, vital signs, red-flag checklist) and is instructed to apply MTS criteria to assign a priority level, identify the discriminators that drove the assignment, and produce a rationale that a triage nurse can read in under 30 seconds. The system prompt includes explicit instructions for ambiguous presentations: when symptom combinations could map to multiple priority levels, Claude is instructed to assign the higher priority and flag the ambiguity for nurse review. This conservative bias is a clinical safety design principle, consistent with MTS guidance on triage uncertainty. The deterministic red-flag rules engine runs independently of Claude and is encoded in Python. It checks for combinations that mandatorily require Level 1 regardless of other factors: suspected myocardial infarction, signs of sepsis, signs of stroke, severe respiratory distress, and others defined by the clinical team. This layer exists precisely because the AI should never be the sole mechanism preventing a missed Level 1 presentation.
Challenges Solved and How
The primary clinical safety challenge was ensuring clinician primacy. The AI score is advice, not instruction. The UI was designed to present the AI triage card as a recommendation with explicit visual cues that the nurse's clinical judgment takes precedence, and the override mechanism is prominent and requires a reason for every change. The audit log records both AI scores and nurse decisions separately, so retrospective review can identify patterns of agreement and disagreement to improve the system prompt over time. Integration with the existing patient management system was the primary technical challenge. The client's system was a legacy SQL Server application with no API. SpeedMVPs built a lightweight integration layer using SQL Server linked queries from PostgreSQL via a foreign data wrapper, allowing the triage system to write triage record references back to the legacy system without replacing it. NHS DTAC documentation required evidence of clinical safety case documentation, which SpeedMVPs produced in collaboration with the client's clinical safety officer: a Hazard Log, a Safety Case Report covering the AI scoring component, and a Clinical Risk Management Plan per DCB0129 requirements.
Outcome and Measurable Results
The system was piloted at two urgent care centres over ten weeks. AI-nurse triage score agreement (where the nurse accepted the AI score without override) was 78%, consistent with inter-rater reliability figures for human triage nurses using MTS. In 19% of cases the nurse adjusted the AI score upward (higher priority), and in 3% they adjusted downward. The CQC clinical governance team reviewed a sample of 200 AI-nurse disagreement cases and found that in 76% of upward adjustments, the nurse had access to visual or contextual information not captured in the digital intake form, validating the override mechanism design. Queue time alerts triggered 847 times across the pilot period, catching 23 instances where a patient's condition had deteriorated while waiting. The client reported that the CQC improvement notice was formally closed following submission of the DTAC documentation and the clinical governance audit log evidence.
Lessons for Similar Projects
Build the audit log before anything else. In a CQC-regulated environment, the ability to retrospectively review every decision made by the system is not a nice-to-have, it is the foundation of clinical governance. Design the audit schema before building the triage logic. Never let the AI be the only safety layer. The deterministic red-flag rules engine is not an afterthought, it is the most important component in the system. An LLM can fail in ways that a rules engine will not. For any clinical AI system, you need at least one safety layer that is not AI-driven. Involve a clinical safety officer in the system prompt design. The Manchester Triage System has specific rules around discriminators and priority boundaries that require clinical expertise to encode correctly. A clinician reviewing and signing off the system prompt is part of your DCB0129 clinical risk management process, not an optional step. Finally, design the UI for triage nurse cognitive load. A triage nurse making 50-100 assessments per shift needs to read and act on an AI recommendation in under 10 seconds. Typography, layout, and information hierarchy matter more in this product than in most.