Every module so far has assumed one actor holding the reasoning: a clinician or a learner, with the training to structure a case, retrieve a script, weight a probability, or audit a bias. This lesson turns the same loop outward, to two people who don't have that training but who carry real weight in the case anyway — a family member documenting and monitoring a loved one, and a student learning to see a case the way the patient living inside it actually experiences it.
A scope note, honestly stated: this is a shorter lesson than Lessons 3 and 4. The modules behind it are earlier-stage — Module 2 has been tested against one de-identified case, Module 13 is explicitly marked "not yet validated in a live clinical or educational environment." That's not a reason to skip them; it's a reason to read what follows as a working sketch rather than a finished map.
Everything in Lessons 1–4 lived inside your head or a colleague's. This lesson is about the reasoning that has to leave your head — documented clearly enough for a family member to carry, or translated well enough for a patient to actually use.
Think of this as the difference between an internal reasoning trace and a public API — the same underlying logic, but now it has to be structured, versioned, and safe for a consumer with no context on the implementation to call directly.
Structured Documentation: Module 2
Module 2 hands the same case-building discipline from Lesson 3 to someone with no medical training at all — a family member — and its first move is entirely about tone, not content. The opening prompt tells the advocate outright: "You are doing something important." Every step that follows keeps affirming effort, not just correctness, because an advocate who feels incompetent will under-report rather than risk looking foolish.
Structurally, it's a compressed version of the pipeline from Lesson 3 — symptom capture, examination guidance, medication transcription — closing in a SOAP note the advocate didn't know they were capable of producing. But the module's most consequential note isn't pedagogical at all. It's a data-security warning that exists because the advocate, by definition, is a non-technical user typing real identifying detail into a consumer AI account by default.
A SOAP note written by a frightened, untrained family member at 2am is still a SOAP note — Subjective, Objective, Assessment, Plan is a structure robust enough to survive being held by someone outside the profession, which is exactly why it's worth teaching them the shape of it.
This is onboarding a non-technical end user onto a system with real privacy stakes — and the fix isn't a longer terms-of-service notice, it's a design choice: ask for the text field instead of the photo upload, because the safer input path has to be the path of least resistance, not an opt-in.
Longitudinal State: Module 3
Module 3 extends Module 2 across time rather than a single encounter — tracking lifestyle, mood, medication adherence, and red-flag risk as four parallel domains, each checked in independently rather than folded into one vague "how's it going" update. That separation matters: a patient can be stable on medication adherence while deteriorating on mood, and a single combined check-in tends to let the stronger signal mask the weaker one.
The module's most important boundary is stated plainly in its own safety note, and it's worth restating because it's easy to misread the ALERT mechanism as more than it is:
A red-flag alert that only lives inside a chat window is not a safety net — it's a note to self. The module is honest about that limit rather than letting the word "ALERT" imply more than it delivers.
Four separate domains tracked independently is the longitudinal version of the qualifier-pair discipline from Lesson 3 — resist collapsing distinct signals into one impression, because the collapse is exactly where a deteriorating domain goes unnoticed.
This is a monitoring system with a critical gap between detection and action: the alert fires locally but has no delivery guarantee to the party who can actually act on it. Any real deployment of this pattern needs an explicit escalation path, not just a formatted warning block.
Seeing Through the Patient's Eyes: Module 11
Module 11 shifts the student's task entirely — not building a differential, but anticipating the questions a patient is silently carrying and may never voice. Its opening step generates ten to fifteen such questions, organized under headings like "What is happening to my body?" and "What does this mean for my life?" — and for each one, asks the AI to explain why patients commonly hold the concern but don't raise it. Naming the reason for the silence is the actual teaching point, not the question list itself.
The module's highest-yield step inverts the usual clinical direction entirely — instead of surfacing what the patient needs to ask, it surfaces what they need to know but wouldn't think to ask for:
The module also asks the student to draft a plain-language explanation using a memorable analogy, then to critique that explanation themselves for anything oversimplified to the point of inaccuracy — evaluating the AI's output is treated as part of the learning task, not a side effect of using it.
Every clinician has had the experience of a patient asking, on the way out the door, the one question that mattered most. This module trains the habit of surfacing that question before the patient has to work up the nerve to ask it unprompted.
This is proactive disclosure instead of reactive query-answering — surfacing what a user needs before they've formed the query for it, which is a materially harder and more valuable design target than a well-tuned FAQ.
Translating the Audit: Module 13's Advocate Brief
Module 13 is Lesson 3 and Lesson 4's machinery — interaction hunts, drug-disease conflicts, prescribing-cascade detection — but run with the student reasoning first and the AI filling only what's missed. Its closing step is the one that belongs in this lesson specifically: translating a completed pharmacology audit into something a non-medical advocate can actually use, without the advocate mistaking clinical detail for actionable safety guidance.
The module's own application note explains exactly why that omission question matters: an advocate who reads "MAJOR drug interaction" without context may stop a medication unilaterally, which could cause real harm. The correct advocate-facing brief communicates observable safety signals — watch for bleeding, watch for dizziness — rather than pharmacological mechanisms the advocate has no way to act on safely.
A technically accurate handoff that gets misread into a dangerous action isn't actually accurate — it's incomplete, because accuracy for a lay reader has to include what the words will make them do, not just what the words say.
This is the difference between a debug log and a user-facing error message — the debug log is complete and precise for an expert reader; the user-facing message has to be deliberately incomplete, translated down to what the reader can safely act on without triggering the wrong action.
Homework for Lesson 5
- Take the case you've carried since Lesson 2. Write the advocate-facing handover brief for it — maximum 150 words, plain language, the version a family member could read aloud to a new doctor in an emergency.
- Generate three "silently carried" questions a patient with this case would likely hold but not voice (Module 11, Step 11.1), and for each, name the one-sentence reason they wouldn't ask it out loud.
- If medications are part of your case, write one sentence you would deliberately choose to leave out of an advocate-facing medication brief, and explain why including it could do more harm than help.
This lesson draws directly on Module 2 — Patient-Advocate Case Documentation, Module 3 — Extended Patient-Advocate Monitoring, Module 11 — Patient Education Query Intelligence, and Module 13 — Medication Reconciliation & Polypharmacy, all from the VibeRounds Prompt Directory. As noted at the top of this lesson, Modules 2 and 13 carry the directory's own caveats about limited validation — treat both as structured starting points, not finished clinical tools. If you're coming from the evidence side, the companion Evidence-Based Medicine for Techies course pairs well with this one. Neither course is a clinical decision tool; see the VibeRounds disclosure statement for full terms.