Healthcare AI Triage System

Symptom Checker and Care-Level Routing

Design a patient-facing symptom checker that asks follow-up questions, recommends a level of care and hands the case to a clinician, without missing the warning signs of an emergency.

Overview

A triage system answers one question: how soon, and where, should this person get care? A patient describes symptoms in their own words; the system asks follow-up questions, then recommends a care level: call 911, be seen today, book a visit in the next few days, or look after yourself at home with advice on what to watch for. It then passes a structured summary to a nurse or clinic. It does not name a disease.

The engineering is ordinary: a chat service, a language model that turns free text into structured symptoms, a decision engine, a handoff. The risk is not. The errors are unequal: sending a healthy person to urgent care costs money and time, while sending someone with stroke signs home can cost a life. Published evidence shows how hard this is: an audit of 23 online symptom checkers in the BMJ (2015) found appropriate triage advice in 57% of standardized patient cases, and in 80% of emergencies.

Questions to ask first

Who uses it? — Adult patients of one health system, in the US, on web and app chat
What does it output? — A care level and a clinician-facing summary, never a diagnosis
Is a human available? — Yes, a 24-hour nurse line takes handoffs
How many assessments? — 200,000 a day, about 8 questions each
Can it read the patient's record? — Yes, allergies, conditions and medicines, when the patient is signed in
Where does the language model run? — Only with a provider that signs a HIPAA business associate agreement

What you will be able to do

Explain why triage outputs a care level and not a diagnosis, and what that changes in the design.
Layer fixed red-flag rules, a model with asymmetric thresholds and an uncertainty rule so that doubt moves care upward.
Estimate the load and show why even 99% sensitivity needs a human safety net.
Keep an audit trail that can find every session a faulty model version touched.
Name the HIPAA safeguards and the FDA questions that shape the system.

Key concepts

Care level, not diagnosis
Red-flag rules
Crisis pathway
Asymmetric thresholds
Calibration
Clinical vignette testing
Model version per session
HIPAA safeguards
FHIR handoff

Functional requirements

Run a chat assessment: take a free-text complaint, ask follow-up questions, and finish in a few minutes
Check every message for red flags and crisis language, and interrupt the flow with emergency instructions at once
Recommend one of four care levels with plain-language next steps
Use the signed-in patient's allergies, conditions and medicines when available
Hand off to the nurse line or book a visit, with a structured summary (FHIR QuestionnaireResponse)
Let clinicians record the level they actually chose, to measure the system

Non-functional requirements

Emergency cases recommended emergency care at least 99% of the time on the clinical test set (a target we chose)
Red-flag check under 100 ms per message; a full reply under 3 seconds at p95 (targets we chose)
Available around the clock; if the model is down, fall back to a fixed questionnaire, and if everything is down, show emergency instructions
HIPAA technical safeguards on all patient data; language-model vendors only under a business associate agreement
Every assessment records the model, prompt and rule versions that produced it

Interview questions

How do you make sure the system never misses an emergency?
Why not let a large language model make the triage decision?
What does calibration mean here, and why does it matter?
How do you handle HIPAA when using a third-party LLM?
A model version is found to under-triage abdominal pain. What do you do?
Is this a medical device?
How do you know the system is working after launch?