Skip to main content

Parent Triage — Chart-Anchored, 24/7

A patient-facing AI assistant that lives inside the Starlight parent app and helps parents decide "do I bring my kid in?" — anchored to the child's actual medical record, the parent's records, and the doctor's prior notes.

This is not a generic LLM medical advice tool. It's narrowly different in a way that matters. The tool only operates inside an active doctor-patient relationship, with the patient's real chart as context. Generic LLM advice is what people are already getting from ChatGPT — billions of weekly messages worth of it, mostly without their own chart in scope and with no oversight loop. We are doing the opposite.

The pain we're attacking​

Two pains, on opposite sides of the doctor-parent boundary:

For parents: any time of day or night, every parent has the question: "Is this serious? Should I take my kid to the ER, call the doctor in the morning, or handle it at home?" The current options are bad. Call the practice (if it's open), text the doctor (and feel guilty for bothering them), Google their kid's symptoms (and end up in WebMD-induced panic), or ask an LLM that has none of their kid's history and confidently answers anyway.

For the doctor: a meaningful fraction of after-hours messages are concerns the parent could reasonably handle themselves with better information ("my kid has a splinter," "viral cough at night," "another diaper rash"). They burn doctor bandwidth that should be reserved for things that actually need a doctor. DPC pediatrics already promises 24/7 access to the doctor, which is a big part of why families pay subscription rates — making that 24/7 access more valuable for both sides is core to the value proposition.

How it works​

The parent opens the Starlight app. Either via a "Ask about my kid" button or via the existing message thread, they describe what's going on:

"Sofia has a fever of 101.4 and woke up coughing again. She had this same thing last month."

The triage assistant has the following in context before it answers:

  • Sofia's full medical record (this practice's chart, plus any imported records).
  • Active conditions and medications (peanut allergy, Epi-pen, prior eczema).
  • Yogini's prior visit notes about Sofia's recurring viral URI pattern.
  • Recent messages between Lisa and Yogini.
  • Vitals trend (recent weights, percentiles).
  • Family history relevant to the chief complaint.

The assistant produces a structured response that always includes:

  • What this looks like, given Sofia's history. ("This pattern matches the viral URIs Sofia had in February and November. Her allergies and eczema are stable — those don't usually drive fever.")
  • What to watch for. ("Watch for: breathing that feels labored, fever above 102.5 sustained, decreased fluid intake. Any of those — call us or go to ER.")
  • What you can do at home. ("Acetaminophen 5 mL every 4–6 hours for fever, push fluids, humidifier in her room.")
  • The recommended path. ("Tomorrow morning we can see her if you'd like — I can hold a 9:30 slot now. If she gets worse tonight, you can text Dr. Yogini directly or go to ER.")
  • What's been logged in your chart already. ("This conversation is saved to Sofia's chart. Dr. Yogini will see it in the morning.")

The response never says "this is an emergency, go to ER" without offering the ability to also alert the doctor in real-time — and it always offers the option to escalate to a direct text with the doctor.

Why the liability case is better, not worse​

This is the key product insight Erik articulated:

The liability actually gets better because you're anchoring to the patient's own medical record and the doctor's prior judgment, not just generic LLM knowledge.

Specifically:

  • Anchored to the chart. The reasoning is built on the doctor's documented care for this specific patient. We are not doing population-level medical advice; we are doing patient-specific reasoning with that patient's record as ground truth.
  • The doctor stays in the loop. Every conversation is logged to the chart. The doctor reviews it. The doctor can disagree with the triage advice and override. The doctor's standing care plan informs the assistant's answers — if Yogini documented "Sofia's mom is a worrier and we tend to recommend in-office checks for her even for minor things," that shapes the triage tone for that family specifically.
  • Sources are visible. When the assistant says "this matches Sofia's prior viral URI pattern," the parent can tap to see the actual prior visits referenced. Not "AI says X" — "here's the chart entry that informed this."
  • Explicit framing every time. The assistant always tells the parent "I'm an AI assistant. I have access to your kid's chart and Dr. Yogini's notes. The decision rests with you, and Dr. Yogini reviews these conversations." Same liability principle Erik articulated for AI medical advice in general.
  • Sister feature: the Agentic Safety Monitor watches the conversation in real time for red-flag patterns (abuse, neglect, mental-health crisis, medication misuse) and SMS-alerts the doctor on a hit.

The contrast with what's happening today: parents are already asking ChatGPT about their kid's symptoms — billions of weekly messages worth, with no chart, no doctor oversight, no escalation path, no logging. Our version is better-grounded, supervised, and accountable. That's a stronger liability posture than the current alternative, not a weaker one.

What it isn't​

Drawing the four "is nots" rigid, like we did for the Diagnostic Game:

  • It is not a chatbot for medical questions in general. It only operates inside an active patient-doctor relationship, with that patient's chart as context.
  • It is not a substitute for the doctor. Every response routes back to the doctor; every conversation is reviewed.
  • It is not a triage gate the parent has to go through. The parent can always still text the doctor directly. The triage assistant is offered alongside, not instead of.
  • It is not unsupervised. The agentic safety monitor watches every conversation for red flags and pages the doctor on a hit.

Engineering implications for v1​

We are not building this in v1. But v1 architectural decisions should keep the door open:

  • Patient + Family + Guardian model must support a clean "this conversation belongs to this patient and is anchored to this chart" relationship. (Already a v1 requirement for the parent app.)
  • Chart RAG infrastructure — the substrate that lets an LLM operate against a structured patient record — is going to be needed for the AI scribe and the AI risk panel anyway. Build it generic; the triage assistant will reuse it.
  • Doctor's standing care plan as a structured artifact in the chart, not just free-text in notes. This lets the assistant respect "for this family, recommend in-office for X" without re-reading every note every time.
  • Conversation log as a first-class entity in the chart — every parent-app message thread, AI-assisted or otherwise, lives in the chart timeline.
  • Synthetic-data testing must include realistic parent-side conversational queries; this is already part of the Compliance synthetic-data program.

Open questions​

  • Pricing. Does parent triage stay bundled with the standard Starlight subscription, or does it become a premium tier? Probably bundled — the value to the doctor (fewer low-value after-hours messages) and the value to the parent (24/7 reassurance) both reinforce subscription stickiness.
  • Liability policy. Even with strong technical safeguards, the practice's malpractice carrier needs to be in the loop early. The patient-facing AI advice surface is novel ground for medical malpractice insurers.
  • State variation. Some states have specific rules around telemedicine and patient-directed advice. Survey before launching.
  • Volume ceiling. Parents who get good triage advice at 11pm may use it more often, which is fine; the question is whether the doctor's "I'll review every conversation" workflow scales as the practice grows. Bulk review, AI-summarized review of routine conversations, etc., are all addressable.
  • FDA Software-as-a-Medical-Device line. A patient-anchored triage assistant that gives advice on whether to seek care sits near the SaMD line. We need to design for "software is informational; the doctor is the diagnostic authority" carefully. See Compliance · regulated SDLC notes on FDA SaMD.

Cross-references​