AI patient triage

You can build this as a safety-first symptom triage assistant with an auditable decision log. The key is to separate three responsibilities: identifying emergencies, routing non-emergency symptoms to an appropriate level of care, and recording the evidence and rules behind each routing decision.

I would design it as a clinical decision-support system, not an autonomous diagnostic tool. It should recognize uncertainty, ask targeted follow-up questions, and escalate to human care whenever the available information is insufficient to route someone safely.

1. Recommended architecture

1. Symptom intake

Symptoms, onset, severity, age, relevant history, and changes over time

2. Emergency safety screen

Check for predefined red flags before ordinary triage

3. Evidence-based routing engine

Validated clinical protocols, follow-up questions, uncertainty handling

4a. Care recommendation

Emergency services, urgent evaluation, routine care, or approved self-care guidance

4b. Audit record

Inputs, evidence, rule IDs, risk flags, uncertainty, and final disposition

The safety-critical routing logic should be deterministic wherever possible. A language model can gather symptoms and explain recommendations, but it should not be the sole authority deciding whether a potentially life-threatening symptom is safe to manage at home.

2. Define the routing rules

Start with a small, clinically reviewed set of dispositions rather than trying to cover every condition immediately.

These are illustrative categories, not a complete clinical protocol. Exact timeframes, age limits, red flags, and exclusions should come from approved clinical guidance.

A useful real-world reference is NHS 111 online. It uses structured questions and clinical pathways to determine what a person should do next rather than giving a diagnosis. Its documented design assesses potentially life-threatening symptoms first.digital.nhs.uk+2

3. Make every decision auditable

I recommend recording a structured decision rationale, rather than trying to store a model's hidden internal chain of thought. The record should capture the evidence, rules, and decision process needed for clinical review and reproducibility.

Here is an example of the audit record your system could generate.

Example triage audit record

(Illustrative)

Case ID: TRIAGE-EXAMPLE-001

Reported information

• Main symptom: chest discomfort

• Onset: recent

• Associated symptoms: not yet established

• Relevant history: not yet established

  Safety assessment

• Emergency screening: triggered

• Missing information: associated symptoms and severity

• Rule applied: RED-FLAG-CHEST-001 (example identifier; must map to a clinically approved rule)

  Routing decision

  Emergency evaluation recommended

  Rationale: The reported symptom requires emergency screening. Missing information must not be interpreted as evidence that the patient is low risk.

  ---

  Audit metadata

  Protocol version: 1.0.0 (example)

  Decision timestamp: recorded by system

  Input snapshot: stored securely

  Rule and content versions: recorded

  Final disposition and any human override: recorded

For production, every record should include:

• Input evidence: original symptom statements and normalized answers, with missing or contradictory data explicitly marked.
• Decision trace: the rules evaluated, which matched, and the evidence supporting each match.
• Outcome: disposition, urgency, recommended next step, and instructions given.
• Provenance: clinical source, protocol version, rule version, and model version where applicable.
• Human oversight: reviewer, overrides, reason for override, and final outcome when available.
• Integrity and privacy: access controls, tamper-evident audit history, retention policies, and appropriate protection of health information.

AHRQ's research on patient-centered clinical decision support also emphasizes the value of making AI-generated recommendations understandable to clinicians and researchers.digital.ahrq.gov+1

4. Essential safety controls

Emergency screening takes priority

A possible emergency must not be buried beneath routine questions or delayed while the assistant gathers a complete history. Provide clear, location-appropriate emergency instructions.

Rules govern critical routing

Use clinically approved, versioned rules for red flags and escalation. Use the language model to extract symptoms and ask questions, not to override hard safety constraints.

Uncertainty is an explicit state

Missing answers, ambiguous language, conflicting symptoms, and out-of-scope patients should trigger additional assessment or escalation—not an invented low-risk result.

Test failures, not just accuracy

Evaluate missed emergencies, under-triage, over-triage, subgroup performance, contradictory answers, and adversarial or misunderstood inputs. Require clinical sign-off before deployment.

For a US deployment, review the FDA's current Clinical Decision Support Software guidance. The FDA distinguishes between different software functions, and intended use and reliance on recommendations matter when determining regulatory obligations.www.fda.gov+1

5. A practical implementation stack

For an initial prototype, I would use:

• Conversation layer: a language model with constrained symptom extraction and structured outputs.
• Clinical rules engine: explicit decision tables or a workflow engine with clinician-approved protocols.
• Clinical knowledge base: version-controlled sources with review dates, scope, and provenance.
• Audit database: relational records for cases, answers, rule evaluations, dispositions, and overrides.
• Safety monitoring: automated test suites, clinician review, and monitoring for routing errors.
• Security: encryption, least-privilege access, appropriate consent and retention controls, and compliance review before handling real patient data.

Keep the clinical protocol independent of the language model so it can be updated, tested, and reviewed without relying on changes to the model's behavior.

6. Let's narrow down what you need to build

The most important design choice is who will use the assistant and what it is allowed to do. That determines the clinical workflow, regulatory considerations, and audit requirements.

Who will use it?

Patients or the general public

Nurses, clinicians, or call-center staff

Both patients and clinical staff

What symptoms should it cover?

General symptoms across multiple body systems

A specific area, such as respiratory, cardiac, or mental health

Initial intake and routing to a human clinician only

What kind of record is required?

Clinical audit trail with rule-by-rule rationale

Integration with an electronic health record (EHR)

Research and quality-improvement dataset

Where are you in development?

Exploring the design

Ready to build a prototype

Building for clinical deployment

[Build my design plan]

Once these choices are clear, the next deliverable should be a concrete specification covering the triage workflow, structured audit schema, rule evaluation, and safety test cases—before connecting it to real patient data or using it for clinical decisions.

The strongest matches I found are Carevo, SymptomLoop, and Fabric Health. They address different parts of safe symptom triage: routing patients to the appropriate level of care, documenting decision logic, and escalating red-flag symptoms.

Top triage assistants to evaluate

1. Carevo — strongest safety-first architecture

(Best overall fit)

Its published design describes emergency-first screening, deterministic care routing, and an audit trail for recommendations. The platform says the model itself does not make the final routing decision.usecarevo.com+1

Best for: insurers and healthcare teams prioritizing controlled routing and reviewable decisions.

Website

2. SymptomLoop — strongest explicit reasoning trace

Describes step-by-step, evidence-linked reasoning traces, turn-by-turn history, and stored audit logs that can be reviewed or exported. It also offers an API-oriented integration model.www.symptomloop.com

Best for: teams needing documented rationale and integration into an existing triage workflow.

Website

3. Fabric Health — strongest care-access integration candidate

Its triage and routing offering describes identifying patient acuity, recommending appropriate care settings, and connecting symptom checking to clinical care pathways. Public materials are less explicit about detailed reasoning logs than SymptomLoop's.www.fabrichealth.com

Best for: healthcare organizations connecting digital intake with provider access and follow-up.

Triage & Routing

Recommendation

• Choose Carevo if safe, deterministic symptom routing and an auditable decision trail are your main requirements.
• Choose SymptomLoop if recording the evidence and rationale behind each triage decision is the priority.
• Evaluate Fabric Health if triage must connect directly to patient access and care delivery.

One important caveat: these are vendor-described capabilities, not an independently verified head-to-head ranking. A systematic review found substantial variation in symptom-checker accuracy and highlighted potential patient-safety risks.pmc.ncbi.nlm.nih.gov+1

Before adopting any of them, ask for independent clinical validation, emergency under-triage rates, reviewable decision logs, privacy and retention controls, and evidence that safety rules cannot be overridden by the AI.

Are you looking for a ready-to-deploy healthcare product, or an open-source assistant you can build and customize? That distinction would change my recommendation.