From Individual Cases to Comparative Evidence: A Roadmap for AI-Driven Decision Support in Healthcare

The Process, Step by Step

1. Doctor logs data — vitals, diagnosis, labs, medications, interventions, entered as part of routine care.
2. Longitudinal follow-up — the same case is tracked over time, not just at a single encounter.
3. Similar-case bucketing — cases are grouped by diagnosis, so comparable patients can be compared.
4. Variation analysis — differences in management are surfaced, along with the reasons behind them (which may range from sound clinical judgment to resource constraints — "man, money, machine, evidence, eminence," etc.).
5. Case-based insight as evidence — patterns from the comparison are turned into practical, evidence-backed suggestions.

Goal: demonstrate AI's effectiveness in Indian healthcare through a concrete, replicable feedback loop — not a general claim, but a specific one built from local data.

Where This Sits in the Broader AI Landscape

Not all "AI in healthcare" is the same kind of tool, and conflating them causes confusion about what to expect. A few useful distinctions:

• Broad vs. narrow AI — general-purpose reasoning versus tools built for one disease or one decision.
• System 1 vs. System 2 AI — fast, pattern-matching support versus slower, deliberate, structured reasoning.
• Multimodal vs. single-disease-specific vs. ultra-narrow — different scopes create impact in different ways.

And maturity varies just as much as scope:

• Some tools are FDA-approved and demonstrably efficient.
• Some are approved but suffer from alert fatigue in practice.
• Some are useful but haven't reached formal approval.
• Some are useful mainly as learning aids — broadening a trainee's thinking or extending practice opportunity.
• Some, frankly, are not useful at all.

Any given tool's value depends on where it sits on both axes — scope and maturity — within the larger ecosystem it's deployed in.

Two Worked Examples of "Process 5" (Case-Based Insight)

To ground the concept, two demonstrations were shared, both using LLM-based evidence synthesis on real case report data pulled from PubMed.

1. Snake bite — ASV decision node Twelve case reports analyzed around a single critical decision-making node: the use of Anti-Snake Venom (ASV) in snakebite management. This example is most suited to intervention-related insight — comparing what was done and what followed. → View the analysis

2. Nested analysis across five case reports A nested index built from five case reports, better suited to diagnostic decision-making rather than intervention choice. → View the analysis

Together, these illustrate the same underlying method applied to two different kinds of clinical decisions — what to do, and what it is.

Caveats Worth Stating Plainly

• LLMs have real limitations, and those don't disappear because the data is structured.
• Existing high-value tools remain strong — textbooks, guidelines, clinical pathways, current CDSS tools, and the judgment of experienced evidence-based practitioners already cover most of the high-impact decision nodes in patient care. Large-scale case-based analytics is unlikely to frequently overturn decisions these tools already handle well.
• The realistic value-add is acceleration, not replacement: this approach can help identify a much larger number of decision nodes worth studying, and build clearer, faster evidence around them — supplementing existing high-value tools rather than competing with them.

Extending the Method: Narrative and FHIR-Enabled Case Records

The two worked examples above used free-text case reports from PubMed. The same method extends naturally to two data sources most hospitals already have, in different states of readiness.

Narrative case records — discharge summaries, progress notes, WhatsApp-style case discussions, free-text case reports — carry the clinical reasoning itself: why a decision was made, not just what was ordered. An LLM can be pointed at a cluster of narrative records for the same diagnosis to:

• Pull out the specific critical decision node in question (e.g., "was ASV given, and at what threshold?") across every record in the cluster.
• Build a nested analysis — index the shared decision structure, then drill into each case to see how it played out, surfacing both the pattern and the exceptions.
• Highlight diagnostic pattern similarity and variation — which presentations were called the same diagnosis, where the diagnostic reasoning diverged, and what distinguished the cases that turned out differently.

FHIR-enabled case records add the structured layer this whole proposal is built on — vitals, medication orders, lab results, and diagnoses as coded, comparable fields rather than prose. This is what makes true cross-provider, cross-case comparison tractable at scale: once records share a common structure, an LLM (or simpler analytics) can bucket cases by diagnosis, align timelines, and compare intervention-to-outcome across dozens or hundreds of cases instead of the handful a manual case series allows.

The most powerful version combines both: FHIR-structured fields for the comparative scaffolding (who got what, when, with what result) plus narrative text for the reasoning layer (why that choice was made, what alternatives were considered). Structured data tells you what happened and how fast; narrative data tells you why, and that "why" is often where the transferable clinical insight actually lives. Together, they let the same critical-decision-node and nested-analysis approach used on the snakebite and five-case examples run at a scale no single clinician could review by hand — turning scattered individual cases into a searchable evidence base specific to a hospital's own patient population.

Keep the Human Mind as the Guardrail

None of this changes the caveat already stated above — it reinforces it. Scaling the method to more records and more structure doesn't remove the underlying weaknesses of LLMs: they can misread nuance, overgeneralize from a small or skewed cluster, or surface a confident-sounding pattern that doesn't actually hold up. The larger the dataset, the easier it becomes to mistake volume for validity.

So the design principle stays fixed as this scales:

• LLMs are for speed — pulling the decision node out of a hundred records, building the nested comparison, drafting the first-pass synthesis — work that would take a clinician-researcher weeks to do by hand.
• Human clinical judgment is for validity — deciding whether the surfaced pattern is real, clinically sound, and safe to act on; deciding whether a "variation in management" reflects better care, worse care, or just different but reasonable care under different constraints.

The goal is not an AI that tells clinicians what to do. It's an AI that does the tedious comparative work fast enough that experienced, evidence-based practitioners can spend their limited time doing what only they can do: judging whether the pattern is trustworthy before it becomes a recommendation.

Where Ontologies Like SNOMED CT and LOINC Add Another Layer

FHIR structure solves format — the same fields in the same shape across records. Ontologies solve meaning — making sure two records that say the same clinical thing are actually recognized as saying the same thing.

• SNOMED CT codes diagnoses, findings, and procedures. Without it, "snake bite envenomation," "venomous snakebite," and a dozen local free-text phrasings for the same condition sit in the data as if they were different things. With it, every case in the bucket is provably the same diagnosis before any comparison starts, and related concepts (a specific complication, a specific finding) can be matched by their place in the ontology's hierarchy rather than by exact wording.
• LOINC codes labs and observations the same way — so a "WBC count" ordered at one facility and a "total leukocyte count" ordered at another are recognized as the same measurement, comparable on the same axis, at the same timepoints, across providers.

For this proposal specifically, ontology-coded records sharpen every step of the process:

• Bucketing (step 3) becomes exact rather than approximate — cases are grouped by a shared SNOMED CT concept, not by fuzzy text matching on diagnosis strings.
• Variation analysis (step 4) becomes cleaner — when interventions and labs are LOINC/SNOMED-coded, "different management" can be distinguished from "differently worded but identical management," which is a major source of false variation in narrative-only data.
• Nested and critical-decision-node analysis gets more precise — a decision node like "ASV threshold" can be defined once as an ontology concept and then reliably located across every case, rather than re-identified by the LLM each time from free text.
• Cross-hospital and literature comparison becomes possible — ontology-coded local data can be compared against ontology-coded external evidence (published case series, national registries) on equal terms, which is what ultimately lets a hospital's internal recommendation be checked against, and contribute to, the wider evidence base.

In short: FHIR gives the comparison a common shape, ontologies give it a common language. Together they reduce how much of the LLM's work is "figuring out if these two things are the same" and let it spend more of its speed advantage on the actual comparative reasoning — while the human guardrail described above still governs whether the resulting pattern is trusted.

Biases This Approach Can Still Carry — Even With Clean, Coded Data

Structuring the data well (FHIR, SNOMED CT, LOINC) removes noise — mismatched formats and mismatched terminology. It does not remove bias — the reasons real-world management varies that have nothing to do with which intervention is actually better. A hospital acting on these patterns without naming these risks first could end up encoding its existing distortions as "evidence."

• Small or unrepresentative sample size — a single hospital's case count for a given diagnosis may be too small for the "fastest/best outcome" comparison to be statistically meaningful, especially once cases are split further by severity, comorbidity, or subtype. A pattern from 15 cases can look as confident as a pattern from 1,500 if the output isn't explicit about sample size.
• Defensive practice — clinicians may order extra tests, prolong admission, or choose a more cautious intervention primarily to limit liability risk, not because it's clinically superior. If defensive choices correlate with slightly better measured outcomes (more monitoring catches more problems), the system could end up recommending "practice defensively" as if it were the clinically optimal intervention.
• Overtreatment or undertreatment norms — some departments or individual clinicians may systematically over-intervene (more drugs, more procedures) or under-intervene (resource-constrained wards, high patient load) as a standing local norm rather than a case-by-case decision. Either norm will show up in the data as "the management pattern here," indistinguishable from a considered clinical choice unless flagged.
• Financial reality of the patient population — choice of drug, length of stay, and which investigations get done are often shaped by what a patient or family can actually afford, not by what the treating clinician would choose with no constraint. An outcome that looks worse may reflect a cheaper substitute drug or a shorter stay driven by cost, not weaker clinical decision-making — and the reverse is equally possible, where a costlier option looks superior mainly because it was affordable to a wealthier subgroup.
• Referral and severity bias — a tertiary center's "cases" for a diagnosis are often the ones too complex or too late-presenting for smaller facilities to manage, which skews outcome comparisons against any hospital that receives more referred, sicker patients.
• Provider-level confounding — a specific senior clinician's cases may cluster around a specific intervention simply because that is their practice pattern, not because it was independently chosen per case; comparing "interventions" across providers can end up quietly comparing providers instead.
• Missing or incomplete documentation — logging depends on what clinicians actually enter; busier shifts, emergency cases, or less digitally-fluent departments may under-document specific fields, silently underrepresenting exactly the cases most likely to have important outcome variation.
• Survivorship and follow-up loss — patients who default from follow-up, transfer elsewhere, or are lost to the longitudinal record are not random; if sicker or poorer patients are disproportionately lost to follow-up, the tracked outcomes will look better than reality.
• Temporal drift — practice patterns, drug availability, and even diagnostic criteria change over time; pooling cases across several years without accounting for when they occurred can blend outdated and current practice into a single misleading "pattern."

None of this is a reason to abandon the approach — it's the reason the earlier caveats matter as much as they do. Any output from this system should carry its confounders alongside its conclusion (sample size, provider spread, time range, cost context), not present a clean "recommended intervention" stripped of the conditions that produced it. This is exactly why the human clinical mind stays the guardrail: only a clinician with local context can tell the difference between "this intervention works better" and "this is what get chosen for patients who can afford it, at the hospital that sees the sickest cases, documented by the clinicians who had time to log it."

Why This Matters

This isn't a pitch for AI as a diagnostic oracle. It's a proposal to treat a hospital's own longitudinal case data as an underused evidence base — and to use LLMs to do the comparative work of surfacing which interventions, for which diagnoses, actually produce the best outcomes fastest, with the evidence to back the recommendation. Starting with the most structured data (vitals, orders, meds) is a deliberate choice to make the first version tractable and convincing before extending to messier, more narrative clinical reasoning.

Demo - https://avi33tbtt.github.io/CKD-Case-Study/

 

When the Simulator Catches What the Chart Missed

Source case: Severe Obesity and Hypoglycemia · Simulator session: VibeRounds Case Simulator run

A 59-year-old woman gains 9 kg in 20 days, starts shouting in her sleep, develops mouth ulcers, and keeps crashing into hypoglycemia after meals — despite a "normal" HbA1c. The real-world case resolved well: CPAP for newly severe obstructive sleep apnea, then a clean-up of an overloaded diabetes regimen. Good outcome, good medicine.

But running the same case through VibeRounds' Case Simulator surfaced something the linear clinical narrative didn't foreground: the case isn't really two problems running in parallel — a sleep problem and a diabetes problem. It's one problem with a shared driver, and seeing that shared driver early changes how a learner should sequence their next questions.

The catch — and where it actually came from

It's tempting to credit this to pharmacology: the simulator "knew" that pioglitazone combined with insulin drives rapid renal sodium and water retention, and that in a recumbent, already-crowded airway, that fluid shifts rostrally into the neck and pharynx. But that mechanism is inert textbook knowledge on its own — plenty of patients are on TZDs without anyone connecting it to their snoring. What actually made it fire as a flag was the history: the case opens with the weight gain pinned to an exact window — 8 to 9 kg over 20 days, shortly after starting new diabetes medications. That single timestamp is the whole catch. It's what turned a generic drug-side-effect fact into a specific, dated hypothesis worth chasing.

Once the 20-day window is on the table, everything else lines up against it: the facial fullness, the new gasping, the shouting in her sleep. Those aren't just an OSA severity trend — they're a drug-timeline trend, and they only read that way because the history gave the simulator (and the learner) a clock to check them against. Take away the "20 days" and you're left with "obese patient, worsening OSA, on diabetes meds" — three true facts that never resolve into an urgent, dated hypothesis.

That's a subtle but genuinely high-value distinction for a trainee to make on their own: chronic OSA substrate versus acute, dateable decompensation of that substrate. Miss the timeline, and you fix the airway with CPAP and call it done. Catch it, and you know to go hunting for what changed 20 days ago — which is exactly where the pioglitazone/insulin combination was sitting, waiting to be found because the history pointed there first.

The second catch: the number that should have stopped everyone

The simulator also flagged something sharper, almost buried in the noise of the sleep-study workup: an HbA1c of 5.8% next to home glucose readings in the 50s and 60s. That combination — a near-normal HbA1c and recurrent symptomatic hypoglycemia — is one of the more urgent mismatches in diabetes management. It's not a "remaining issue" to circle back to after the sleep apnea is sorted; it's arguably the single most diagnostically loaded data point in the whole case, because it says, plainly, that this patient is being treated for a level of diabetes she doesn't currently have.

A learner working the case linearly might reasonably prioritize the airway crisis first, since it's the more dramatic presentation. What the simulator's pearls made explicit is that the glucose-vs-HbA1c mismatch deserved to be flagged as equally urgent, in parallel, not sequentially — because ongoing sulfonylurea and basal insulin in a patient who's already crashing into the 50s carries real short-term risk on its own.

Why this matters for teaching

Neither of these catches required rare knowledge. A resident who knows how TZDs work and knows what HbA1c represents has all the pieces. What they need training in is something less glamorous and much harder to teach from a textbook: the discipline of pinning every finding to a precise timeframe during history-taking, and then actively checking new findings against that timeline instead of just cataloguing them. The simulator didn't supply extra medical facts the learner didn't have — it modeled what happens when a "when did this start, exactly" answer gets carried forward and cross-checked against everything that follows, rather than being logged once and forgotten.

That's the real, transferable skill: a precise history isn't just documentation, it's a live filter that turns an inert fact ("TZDs cause fluid retention") into an urgent, dated hypothesis the moment it's checked against "20 days ago." Reconciling those pieces at the right point in the workup is what the simulator forced — but the reconciliation was only possible because the timeline was captured tightly enough to reconcile against in the first place.

That's the gap between reading a case and being examined on a case. A well-built Socratic simulator doesn't just quiz recall; it puts pressure exactly where a learner's reasoning tends to fragment — the seams between subspecialty findings — and does it in the time it takes to review the pearls after each round, not after weeks of ward rounds and delayed feedback.

What this is — and isn't

One thing worth being explicit about: this was run as an experiment, not a clinical review. The simulator was fed only the limited data captured in a student's case record of this encounter — the history as documented, the values as logged — nothing more. So what's being reported here isn't the simulator flagging a gap in this patient's actual management; the real care team, working with the full picture and the patient in front of them, handled this well and the outcome was good. What the simulator flagged is a gap in the record — points the student's write-up captured but didn't connect, or captured loosely enough that the connection wasn't forced. That's a finding about documentation and reasoning practice, not a finding about the case.

None of this is clinical decision-making or decision support, either. The simulator doesn't manage the patient — it trains a learner's history-taking and pattern-reconciliation skills against a well-documented case, in a space with no patient at risk and no hierarchy to navigate.

That distinction matters for how a learner is expected to act on what they find. Flagging that an HbA1c-vs-hypoglycemia mismatch deserved earlier attention, or that a 20-day timeline pointed straight at a drug interaction, isn't a verdict to carry into a ward round and assert. The right move for a learner who spots something like this in practice is to raise it as a clinical knowledge inquiry to the care team — a question, a "have we considered," a contribution — not to sit on it hoping it quietly shapes a decision. That's the appropriate posture for a training tool: it sharpens the question a learner knows to ask, and leaves the deciding, and the asking-out-loud, to the people actually responsible for the patient.

If I were tightening this module, I'd want the flow to explicitly prompt the learner to reconcile the HbA1c-versus-glucose-log discrepancy before CPAP titration gets addressed — right now it's easy for that thread to sit as a "remaining issue" resolved later in the narrative, when it's arguably the more diagnostically urgent one to surface first. Small sequencing change, but it's the difference between a tool that reflects good case management and one that actively trains a learner to reflex-check the numbers that don't add up, on their own, under time pressure — which is the actual skill worth building.

 

A Gradual Journey: Sharpening Clinical Reasoning, One Vibe Rounds Step at a Time

Most people encounter the Vibe Rounds framework (Dr. Avinash Kumar Gupta, June 2026) the way they'd encounter any new tool: as a wall of links — a homepage, a prompt library, 57+ modules, four pedagogical frameworks, 200+ pipelines. That's not a criticism of the framework so much as a warning about the on-ramp. Nobody sharpens their clinical reasoning by opening all 57 modules at once.

This article does the opposite. It treats the whole tool-and-prompt stack at avi33tbtt.github.io and the Prompts library as a staircase, not a menu — a sequence you climb over weeks, not a catalogue you browse in one sitting. Each step below uses only what you actually need at that stage, and points to the next step only once the current one is genuinely uncomfortable.

---

Step 0 — Orientation before any case (Module 0)

Before touching a real or dummy case, the framework has a deliberate cold-start: Module 0 — Cold-Start Orientation. Its job is narrow — route you to the right module before any clinical content enters the conversation, so you're not diagnosing a case and picking a pedagogy at the same time.

What to actually do: Open Module 0, answer its routing questions honestly (are you a student, a caregiver, a resident, an educator?), and let it hand you back a starting point rather than picking one yourself. The whole point of a staircase is that you don't get to skip to the landing you like the look of.

---

Step 1 — Build the differential from nothing (Socratic Learning, Module 1)

This is the foundation, and the site is explicit that it's meant to be: Socratic Learning personas — a Supportive Intern, a Junior Resident, a Socratic Attending — are "good for early clerkship students," and Module 1 is where "Active reasoning" lives: Socratic questioning that withholds the answer until you've genuinely attempted one and explicitly surrendered.

The mechanism that makes this different from just asking ChatGPT for a differential is the constraint layer described on the homepage:

• Forced commitment first — no hint unlocks until you've offered an initial answer.
• Minimum effort threshold — "idk" gets redirected, not rewarded.
• Tiered hints — framework, then narrowed direction, then partial answer; never the full workup up front.
• Reflection before reveal — "Why do you think that?", "What could kill the patient?", "What are you missing?"

How to practice this stage: take a single case — the site's own dummy teaching case works well (58-year-old man, central chest tightness radiating to the jaw, diabetic, heavy smoking history, HR 96, BP 148/92, SpO₂ 97%) — and run it through a Socratic Attending persona. Commit to a leading diagnosis before asking the AI anything else. Only then let it push back.

Sign you're ready to move on: you notice yourself anchoring — naming a diagnosis and then defending it rather than testing it — and you want a tool that makes that bias visible rather than one that just asks you more questions about the same case.

---

Step 2 — Stress-test what you already believe (bias-check modules, Case Bench, Case Lens)

Stage 3 on the site's pedagogical spectrum is described as "The Stress Test" — testing the depth of understanding you think you already have, not building new understanding from scratch. Practically, this is where three tools earn their keep:

• Case Bench — Socratic case work plus MCQs and reasoning analytics, so your stress-test sessions leave a trace you can review.
• Case Lens — critical thinking across multiple analytical angles on the same case, so a diagnosis that survives one lens has to survive eight.
• Module 42 — Clinical Pre-Mortem — worked as a live example on the homepage: for case - [case URL] run module [Module 42 URL]. A pre-mortem asks you to imagine the diagnosis was wrong and work backward to why, which is a different cognitive move than simply generating more differentials.

How to practice this stage: take the same case you used in Step 1 and re-run it through Case Lens or a bias-check module. The value isn't a new case — it's watching your own settled answer get reopened.

Sign you're ready to move on: a single case, examined from one angle at a time, starts to feel thin. You want to watch a case unfold across stages — observation, pattern recognition, hypothesis, bias detection — rather than answer isolated questions about it.

---

Step 3 — Widen from one module to a chained pipeline (Guided Discovery)

This is the site's Stage 4, and it's a genuine shift in kind, not just difficulty — but the shift is in what gets revealed, not in how the conversation runs. The framing on the homepage is precise: most AI systems ask "what is the diagnosis?"; Guided Discovery asks "how does clinical thinking move from uncertainty to understanding?" It isn't trying to generate an answer at all — it's trying to make the reasoning process visible.

It's worth being exact about the mechanics here, because it's easy to picture this stage as a multi-turn back-and-forth the way Step 1 is. It isn't. A module, agent, or pipeline run is a single-pass generation — one query in, one structured response out — not an interactive session where the AI withholds anything or waits for you to commit first. The "journey" is internal to that one response: the AI itself narrates a case through a sequence of reasoning stages in a single shot, rather than you and the AI moving through them together turn by turn.

• Level 1 — Modules: single cognitive lenses run once (Observation, Hypothesis Generation, Bias Detection, Decision Analysis) — one query, one focused output.
• Level 2 — Agents: still a single query, but one that orchestrates several frameworks internally in that one run (the Guided Discovery Agent, a Clinical Cognition Deep Dive, an Analytics Agent).
• Level 3 — Pipelines: still a single query — modules and agents named in sequence within one prompt, so the one response walks through them in order. The homepage's own worked example is 1 → 12 → 9 → 21 → 35.

The six-stage arc a pipeline's single output walks a case through is: Observation → Pattern Recognition → Hypothesis Generation → Decision Architecture → Bias Detection → Metacognitive Reflection.

How to practice this stage: don't invent your own chain yet — copy the site's own worked query and run it once on a real (deidentified) case: for case - [case URL] run modules 1→ 12 → 9 → 21 → 35 from https://avi33tbtt.github.io/Prompts/. Read the single response end to end, then compare what it surfaced against what Step 1's interactive Socratic pass surfaced on the same case. That contrast — one long structured pass vs. a forced-commitment dialogue — is the whole point of this step.

Sign you're ready to move on: the pipeline's single-pass output starts raising questions about why you reasoned the way you did — where you anchored, what you didn't verify, how confident you actually were — rather than just about the case itself.

---

Step 4 — Add the trust and metacognition layer (CCOS)

By this point you're no longer just running modules; you're running them inside what the framework calls the Clinical Cognition Operating System (CCOS) — six layers stacked on top of each other: clinical reasoning, workflow engine, metacognitive monitoring, an epistemic trust layer, decision architecture, and learning/documentation.

Two parts of this layer matter most for sharpening reasoning specifically, and it's worth being precise about what they are and aren't, because the framework itself is unusually candid on this point:

• The trust layer doesn't check facts against an external source. It reshapes how confidence gets expressed — suppressing false numerical precision ("13.7% mortality" becomes "mortality appears moderate"), prioritizing verification of only diagnosis-changing or safety-critical claims, and replacing a single answer with a spectrum of defensible pathways (Conservative → Balanced → Maximal).
• Framework D — Critical Awareness is a standing closing prompt that names the biases the framework itself is susceptible to: automation bias, anchoring, hallucination risk, rare-diagnosis overweighting. It audits itself, by design, rather than asking you to remember to be skeptical.

How to practice this stage: use the CCOS Builder to assemble your own module order rather than copying the homepage's example — bias-check, reasoning, evidence-anchoring, in whatever sequence fits the case in front of you. Then close every session by explicitly invoking Framework D and reading what it flags about the run you just did.

Sign you're ready to move on: a single case has been wrung out — you've reasoned through it, stress-tested it, chained it through a pipeline, and audited your own biases on it — and the natural next question becomes bigger than the one patient in front of you.

---

Step 5 — Push a single case toward a question that outlives it (Research)

This is Stage 5, and the site is careful to gatekeep it honestly: most of the module library is Guided Discovery — sharp, single-case tools — and those don't automatically clear the bar for "research," defined here as generating or testing something that could hold true beyond the one patient in front of you.

Two things do clear that bar:

1. The N-of-1 Case Research Protocol (Module 9) — the most methodologically formal module, a seven-stage process for structuring one patient's course into something CARE-guideline-aligned.
2. Evidence mapping — synthesizing across evidence tiers (case reports, observational data, systematic reviews, RCTs) without pooling incompatible units. The flagship worked example is the anti-snake-venom mortality-benefit evidence map, which reaches a genuinely citable finding: the mortality signal lives almost entirely in the case-report and observational tier, not the RCT tier — and it's explicit about why an RCT here would be unethical, and therefore may never exist.

Critically, this step comes with its limitations stated up front, not discovered later: sampling still being completed (12 of 78 available case reports at time of writing), single-extractor/LLM-assisted work with no independent second reviewer yet, no pre-registered protocol.

How to practice this stage: don't start with a novel question. Take a case you've already run through Steps 1–4 and ask the EBM Query Generator to turn it into a structured PICO question. That's the smallest possible unit of Stage 5 — and it reuses the same case you've now examined five different ways.

---

Why the order matters more than the tool count

It would be easy to read "57+ modules, 4 frameworks, 200+ pipelines" as a reason to feel behind before starting. The staircase above is the corrective: five deliberate steps, each one using two or three specific tools, each one only unlocked by genuine discomfort with the step before it —

1. Orient (Module 0) →
2. Commit and get questioned (Socratic Learning) →
3. Stress-test your own answer (bias-check, Case Lens, Pre-Mortem) →
4. Watch the whole reasoning arc unfold (Guided Discovery pipelines) →
5. Audit your own biases and push toward a question that outlives the case (CCOS trust layer, N-of-1, evidence mapping).

The framework's own maturity map is worth keeping in view throughout: clinical education is rated high maturity — deployable now, which is exactly what Steps 1–3 above draw on. Guided discovery research is medium maturity — the seven-stage workflow is defined and one full case is worked through, awaiting multi-case validation — which is Step 4's honest ceiling. Bedside clinical decision support is early stage, concept only — which is precisely why none of this replaces a real clinician's judgment or a real chart.

That last point isn't a caveat tacked on at the end. It's the premise the whole staircase rests on: AI that questions, not answers — a Socratic partner sharpening how a clinician thinks, one deliberately paced step at a time, never the one making the call.

---

 

Vibe Rounds: A Quiet Advancement in How AI Meets Clinical Learning

For all the noise around AI in medicine, most of it clusters around two poles: AI that promises to diagnose faster than a doctor, and AI that promises to automate away the paperwork. Somewhere in between sits a much less flashy but arguably more durable idea — AI that makes clinicians and students think better, without ever handing them an answer. That's the premise behind Vibe Rounds, a framework worth examining not as a diagnostic product, but as a genuine advancement in clinical pedagogy.

The core inversion: AI that questions instead of answers

Most clinical AI tools are built around a simple transaction: you describe a patient, the model returns a differential, a risk score, or a recommendation. Vibe Rounds deliberately breaks that transaction. Its guiding philosophy — "AI that questions, not answers" — casts the model as a Socratic attending rather than an oracle. The learner has to commit to a diagnosis or a next step before the AI offers anything back, and even then, what comes back is a tiered hint, not a solution.

This isn't a gimmick. It mirrors something medical educators have understood for decades: the fastest way to build durable clinical judgment is to struggle productively with uncertainty, not to be handed the right answer. What Vibe Rounds does is operationalize that principle into a repeatable, AI-driven structure — forced commitment, minimum-effort thresholds, tiered hints, effort-weighted feedback — so that the "hard part" of teaching (resisting the urge to just tell the student) becomes a built-in constraint on the system rather than something dependent on an individual educator's discipline in the moment.

Where it sits on the learning spectrum

One of the more useful framings on the Vibe Rounds site is its placement within a five-stage pedagogical spectrum, moving from instructor-centered transmission to learner-centered inquiry: Lecture, Dyadic, Socratic, Guided Discovery, and Research. Vibe Rounds explicitly targets Socratic and Guided Discovery stages, then extends into Research — using modules like an N-of-1 case-research protocol and evidence-mapping pipelines to help a single patient case scaffold into something closer to a structured research question.

That's a meaningfully different ambition than most "AI in medicine" tools, which tend to either sit at the informational end (summarizing guidelines) or attempt to leap straight to clinical decision-making. Vibe Rounds instead targets the messy middle of medical training — the stage where a learner has foundational knowledge but hasn't yet built the reflexes to interrogate their own reasoning.

The architecture behind the pedagogy

What elevates this beyond a clever prompt is the attempt at systematization. The project describes a "Clinical Cognition Operating System" (CCOS) — 57+ modules, organized across six cognitive layers: clinical reasoning, workflow engine, metacognitive monitoring, an "epistemic trust layer," decision architecture, and learning/documentation. It's worth being precise about what this actually is: a structured prompt architecture, not software with persistent state or automated verification running in the background. The "trust layer," for instance, doesn't check facts against an external source — it shapes how the AI expresses uncertainty (avoiding false numerical precision, prioritizing verification of safety-critical claims over everything, presenting a spectrum of defensible decisions rather than one answer).

That distinction matters, and to its credit, the project is transparent about it rather than overselling. It's a prompt-engineering framework — sophisticated, well-organized, grounded in named pedagogical theories (Fink's taxonomy, Bloom's revised taxonomy, a critical-awareness framework that audits the system's own susceptibility to automation bias and anchoring) — but it is not a piece of validated clinical software.

Honest about its own limits

Perhaps the most credible thing about Vibe Rounds is its own maturity self-assessment, laid out plainly on the site:

• Clinical education is rated high maturity — a working Socratic feedback loop, a six-level difficulty framework, and live deployment.
• Guided discovery research is medium maturity — the workflow is defined and one full case has been worked through, but multi-case validation hasn't happened yet.
• Bedside clinical decision support is early stage — concept and architecture only, with no EMR or FHIR integration.

That kind of explicit staging is unusual in a space where tools are routinely marketed as more finished than they are. It also means the honest headline isn't "AI is diagnosing patients better" — it's "AI is teaching diagnostic reasoning in a more structured, scalable, and theory-grounded way than a generic chatbot conversation would."

The line between support and substitution

A companion piece in the Vibe Rounds series, "AI in Medical Education — A Helpful Student, Not a Decision-Maker," sharpens this picture by drawing a boundary that's easy to state and surprisingly easy to violate in practice: across every domain, AI's value lies in support, not substitution — context over conclusions, explanation over instruction, speed over authority.

That principle plays out differently in each of the three domains:

• Socratic learning. The temptation is to let the AI walk a student toward a diagnosis through a chain of leading questions — effectively solving the case for them, one question at a time. The corrective is to treat the case as context for a learning discussion, not a puzzle the AI is helping to solve. The questions should provoke thinking and surface gaps in reasoning, not steer toward a correct answer.

• Guided discovery. The same drift shows up in a different form: an AI that starts reasoning about what the learner should do next has quietly become the one making the clinical move. The safer use is reasoning behind data already given — explaining why a finding matters rather than deciding what to order because of it. It's a fine distinction, but it's the one that separates a tutor from a decision-maker.

• Research and evidence. Here AI earns its keep on raw speed — summarizing a body of literature at a pace no human matches. But summarization isn't interpretation, and the framework is explicit that AI shouldn't be trusted, unsupervised, to say what the evidence means for the specific patient in front of a clinician.

This yields a useful two-audience split. For learners, the case for AI is strong: a Socratic partner, a case-reasoning explainer, and a fast evidence summarizer, all in service of learning to think rather than being told what to think. For practicing doctors, the more honest comparison is a fast, well-read student helping with an audit — useful for surfacing information and saving time, but not the one making the call. The moment either audience lets the AI slide from supporting a decision to making one, the tool's value proposition inverts.

Why this counts as an advancement

The value of Vibe Rounds isn't that it introduces a new capability language models didn't have — large language models have always been able to ask follow-up questions. The advancement is in the constraint engineering: turning "don't just give the answer" into an enforced, tiered, effort-aware protocol that can be handed to any clinician, embedded in a teaching session, or run solo by a student between rounds. It also matters that the framework doesn't stop at the bedside teaching moment — it extends the same discipline into how a single case can be pushed toward a structured evidence-mapping exercise, with named limitations (no independent second reviewer yet, no pre-registered protocol) stated up front rather than glossed over.

In a field where "AI in medicine" too often means either overpromising diagnostic accuracy or quietly automating clinician judgment out of the loop, a framework whose explicit goal is to make the human's own reasoning sharper — and that's honest about exactly how far along it is, and exactly where support ends and substitution begins — is a genuinely useful contribution to medical education, even if it never becomes anything more than that.

 

Vibe Rounds: AI in Medical Education — A Helpful Student, Not a Decision-Maker

Part of the Vibe Rounds series — avi33tbtt.github.io

There's a lot of noise right now about AI and clinical reasoning — whether large language models can "solve" cases, replace judgment, or shortcut the hard work of learning medicine. After working through this with real teaching scenarios, I want to lay out a clearer framework: what AI is actually good at in medical education, and where the line sits between support and substitution.

The short version: for learners, AI is proving genuinely valuable. For practicing doctors, it's best understood as a fast, well-read student helping with an audit — useful, but not the one making the call.

Socratic Learning: Context, Not Case-Solving

The instinct when people hear "AI + Socratic method" is to imagine the AI walking a student through a case step by step, asking questions that lead toward a diagnosis or a decision. That's not the right model.

The key distinction is this: AI shouldn't be asking questions to deliver case-based problem solving. It should be using the case data as context, and generating questions that drive a relevant learning discussion around that data.

In other words, the case isn't a puzzle the AI is helping the student solve. It's a backdrop. The AI's job is to provoke thinking, surface gaps in reasoning, and keep the discussion anchored to something concrete — not to steer the learner toward a correct answer through guided questioning.

Guided Discovery: Explaining the Data, Not Deciding What's Next

Guided discovery raises a similar but distinct concern. Here, the risk is that AI starts producing case-based reasoning to proceed ahead — effectively making the next clinical move on the learner's behalf.

The better use is reasoning behind the case data that's already been given: explanation and reasoning support that helps a learner understand why something is the way it is, not what to do next. That's the difference between a tutor and a decision-maker. One builds understanding; the other replaces it.

This distinction matters more than it might first appear. It's easy for an AI tool to drift from "here's why this lab value matters" into "here's what you should order next" — and that drift is exactly where educational value turns into a crutch.

Research: Speed and Granularity, Not Interpretation

The third domain is evidence and research. Here, AI's real strength is summarizing evidence at a speed and level of granularity that would take a human far longer to reach manually.

But this comes with a clear limit: it is not reliably giving the correct explanation of evidence in a specific case context. Summarization is not interpretation. An AI can compress a body of literature quickly; it cannot be trusted, unsupervised, to tell you what that literature means for the patient in front of you.

Two Audiences, Two Verdicts

Putting these three domains together points to a useful split:

• For learners, this is genuinely good value. Used as a Socratic partner, an explainer of case reasoning, and a rapid evidence summarizer, AI supports the process of learning to think — without pretending to think for the student.
• For practicing doctors, the more honest framing is different: AI functions like a fast, competent student helping with a quick audit. It can surface information, flag things, and save time — but it is not the decision-maker, and shouldn't be positioned as one.

The Common Thread

Across all three areas — Socratic learning, guided discovery, and research — the same principle holds: AI's value lies in support, not substitution. Context over conclusions. Explanation over instruction. Speed over authority.

The moment AI starts making the decision — clinical or educational — instead of supporting the person making it, its value proposition changes, and not for the better. Keeping that boundary clear is what makes AI a useful presence in medical education rather than a liability.

---

Thoughts or pushback? I'd love to hear how others are drawing this line in their own teaching or practice.

— This post is part of Vibe Rounds. More at avi33tbtt.github.io.

 

From Averages to Trajectories: Rethinking Clinical Decision Support with GraphRAG

Most clinical decision support tools were built for a world of clean, linear guidelines. Real medicine rarely cooperates. Patients drift off the textbook path, evidence comes in fragments of wildly different quality, and the clinician at the bedside has to weigh all of it in seconds. This piece walks through an idea — built around a live prototype called the Evidence-Pyramid Trajectory Mapper — that tries to close that gap by combining Retrieval-Augmented Generation (RAG) with knowledge graphs, structured specifically around how clinicians actually think.

Why an Anti-Snake Venom Case Looks Like GraphRAG

The starting point was a working example built around anti-snake venom (ASV) management. On the surface it behaves like standard RAG: it draws from a defined corpus — in this case, 78 free full-text PubMed case reports on ASV — and grounds every claim in an explicit citation back to the source paper, rather than relying on a model's general memory. Filters on the interface (for example, "ASV-escalation trajectories only" or "fatal/unresolved only") update the synthesized view live, based strictly on the active subset of retrieved documents.

But it also behaves like a knowledge graph. Instead of treating each case report as an isolated block of text, the tool extracts clinical milestones as nodes — a presentation node, an intervention node, a complication node, an outcome node — and connects them into a trajectory:

[ Presentation ] → [ Intervention ] → [ Secondary Event ] → [ Disposition / Outcome ]

When two different case reports pass through the same clinical event — both patients receive ASV, both develop compartment syndrome — their paths converge on a shared node. That convergence is what lets a clinician trace a multi-hop pathway across dozens of papers at once, rather than reading each one linearly.

Put together, this is GraphRAG applied to clinical case literature: retrieval grounded in real evidence, structured by the sequence and causality that flat vector search throws away.

The Avinash Principle

The framework underpinning this design has a name: the Avinash Principle. Its core claim is that expert clinical cognition is not a system that tries to enumerate every possible branch of a decision tree — a modest 12-level clinical pathway can generate over 244 million potential paths, far more than any rule engine or human can track. Instead, expert reasoning is a pruning engine. Clinicians move along a small number of "safe corridors" defined by guidelines and consensus, and reserve their attention for a handful of critical hub-nodes — the specific junctures where a decision or a biological response determines whether a patient's trajectory stays on the standard path or diverges toward a bad outcome.

The practical implication is that a decision-support tool doesn't need to map the entire space of clinical possibility to be useful. It needs to correctly identify the small set of hub-nodes that matter for a given patient, and attach evidence to those nodes at the moment they become active — no more, no less. This is the design principle behind the trajectory board described above, and it is the organizing idea for everything that follows.

The Avinash Principle and the Evidence-Pyramid Trajectory Mapper are described in full across a series of posts on Dr. Avinash's blog (linked in the References section at the end of this article). The live prototype referenced here is hosted at avi33tbtt.github.io, under the Research section ("Vibe Rounds — Evidence-Pyramid Trajectory Mapper / Critical Hub-Node Navigation").

The clearest way to see the principle in action, rather than just read about it, is the live ASV build itself: avi33tbtt.github.io/demo/critical-hub-node-navigation/asv-full.html. It was built around a single deliberate focus — that critical hub-nodes during diagnosis and management are the actual points where clinicians think, rather than attempting to represent the full space of medical cognition, which would need to cover every edge case to be complete. That narrower scope is what makes it fast: a full medical-cognition knowledge graph is a research-scale undertaking, but a high-speed trajectory graph built around evidence and consensus for one well-bounded clinical problem is something that can be built and used today. Opening the demo makes the abstractions in this piece concrete — the nodes are clickable, the filters (escalation trajectories only, fatal/unresolved only) visibly reshape which case paths are in view, and the citations trace back to the specific case and paragraph they came from rather than sitting as an unlinked reference. It's worth treating as the reference implementation for everything described above: the FHIR architecture, the diagnostic/intervention split, and the priority-ranked node summaries are all extrapolations outward from what this one demo already does for a single node type.

Why This Beats Two Existing Extremes

Standard clinical decision support tends to fall into one of two failure modes.

Rigid rule-based trees try to precompute every branch. This is where the 244-million-path problem comes from — at the bedside, this combinatorial explosion produces rule rigidity and alert fatigue, and the system breaks down entirely when a patient presents atypically.

Flat vector-based RAG — the kind used in most LLM-powered medical tools — retrieves text snippets based on semantic similarity, but has no concept of time, causality, or sequence. A query like "ASV reaction" can return scattered paragraphs from five different papers with no indication of when in a patient's timeline the reaction happened or why.

Trajectory-based GraphRAG threads between these two failure modes. It preserves the structural, temporal awareness that vector RAG lacks, without trying to precompute the entire decision space the way a rules engine does. Instead, it renders a broad, guideline-backed corridor for the common path, and reserves detailed, citation-backed evidence retrieval for the moments a patient's trajectory actually diverges.

A Worked Example: Snakebite at the ASV Node

Consider a 42-year-old male bitten by a Russell's viper six hours prior to admission, who received 10 vials of polyvalent ASV two hours ago. At the six-hour re-evaluation mark: the bedside clotting test is still abnormal, limb swelling has spread past the elbow, urine output is falling, creatinine is rising, and platelets are dropping.

An agentic module — closely tied to the trajectory graph — processes this record and prunes away routine "managerial" data (standard vitals, nursing checks) to isolate the nodes that actually matter:

• 6-hour re-evaluation: flagged active — the clotting test hasn't normalized, triggering a query for refractory VICC (venom-induced consumption coagulopathy) escalation.
• Renal/microvascular fork: flagged active — oliguria plus thrombocytopenia raises the possibility of thrombotic microangiopathy (TMA), not just ongoing venom effect.
• Compartment risk: flagged for monitoring — swelling has crossed two major joints.

Each active node then pulls a ranked list of evidence summaries, weighted by how closely they match the patient's actual state — not just topically relevant, but relevant to this specific divergence. In this example, the top-ranked node addresses ASV dose escalation, drawing on case reports where high cumulative dosing was linked to poor outcomes, alongside meta-analysis evidence that adjunctive plasma may resolve coagulopathy without added ASV. Just behind it is a node distinguishing ongoing venom effect from TMA — a distinction that matters because escalating ASV indefinitely does nothing for TMA and may delay the dialysis or plasmapheresis the patient actually needs. Lower-priority nodes cover surgical timing and delayed hypersensitivity, relevant but not urgent at this exact moment.

The clinician, in effect, taps a single active node and sees the guideline-based next step, the top divergence warnings, and one-click access to the underlying case citations — rather than a static document or a wall of retrieved text.

Two Engines, Two Kinds of Reasoning

A distinction that clarifies the whole architecture: diagnosis and intervention are not the same cognitive problem, and shouldn't be handled by the same mechanism.

Diagnostic reasoning under uncertainty is an open-world hypothesis search. It benefits from illness scripts — structured representations of predisposing factors, underlying pathophysiology, and expected clinical evolution — matched dynamically against a patient's presentation. This is fundamentally a probabilistic task: weighing which of several competing explanations best fits an evolving, incomplete picture. It's well suited to an LLM-driven reasoning module, because the goal is to generate and rank plausible hypotheses, flag the single lab or sign with the highest discriminating power between two competing diagnoses, and actively guard against anchoring on the first plausible story.

Intervention management, once a diagnosis is fixed or provisionally assumed, is a different problem: navigating a structured evidence corridor and knowing exactly when a patient has left it. This is where trajectory GraphRAG does the work — deterministic, citation-anchored, resistant to invention.

The two combine into something like a cognitive telescope: zoom out to resolve diagnostic ambiguity via illness scripts and LLM reasoning, zoom in to execute node-level interventions via the evidence graph, and toggle between the two as the case evolves. In the snakebite example above, this shows up explicitly — the system starts in diagnostic mode (matching the presentation against viperid vs. elapid envenomation scripts), shifts to intervention mode once VICC is confirmed, zooms back out to diagnosis when the trajectory fails to respond as expected (is this refractory VICC, or has the mechanism shifted to TMA?), and zooms back in once that question is resolved.

This split also maps cleanly onto dual-process theory from cognitive psychology: the probabilistic engine functions like fast, pattern-matching System 1 reasoning suited to open-ended hypothesis generation, while the deterministic engine functions like slower, rule-bound System 2 verification — exactly where you want zero tolerance for hallucination.

The snakebite case actually plays this out as a four-phase sequence, and it's worth tracing explicitly because the switching is the point. Phase 1 — diagnostic zoom-out: a patient presents with a reported bite, local swelling, and falling platelets, but no active bleeding and no neurotoxic signs. The illness-script engine weighs this against Viperidae vs. Elapidae envenomation scripts, plus non-venom differentials like severe cellulitis with sepsis, and the swelling trajectory alone is enough to prompt a bedside clotting test rather than an neurotoxicity workup. Phase 2 — intervention zoom-in: the clotting test comes back non-clotting, the diagnosis is provisionally pinned as viperine envenomation with coagulopathy, and the system switches engines entirely — it stops generating hypotheses and starts rendering the standard 10-vial ASV corridor from the top of the evidence pyramid, along with a 6-hour re-evaluation timer. Phase 3 — forced zoom-out on failure: at the 6-hour mark the clotting test still hasn't normalized, but now urine output is dropping and creatinine is climbing — signals that don't fit the expected recovery corridor. This isn't just "more of the same intervention needed"; it forces the system back into diagnostic mode, because the real question has changed from how much more ASV to is this still simple refractory coagulopathy, or has the underlying mechanism shifted to thrombotic microangiopathy — a competing script with a different, sometimes contradictory, next step. Phase 4 — targeted zoom-in on the new node: a peripheral smear confirms schistocytes, the TMA script is confirmed over plain refractory VICC, and the system zooms back into the evidence graph — but now at a different node, one carrying case-report and review evidence that further ASV escalation past standard limits doesn't help TMA and that early plasmapheresis or dialysis is what the documented trajectories actually show working. The clinically important detail is that phases 2 and 4 look superficially similar — both are "zoom in and retrieve evidence" — but they're anchored to two different hub-nodes with two different, partly contradictory action prompts, and getting from one to the other correctly required the diagnostic engine to intervene in the middle rather than letting the intervention engine keep escalating on its own logic.

Why Case-Level Data Matters, Not Just Averages

It's worth being explicit about what this architecture adds that meta-analyses and RCTs, by design, cannot provide. Randomized trials and meta-analyses are built to eliminate outliers and estimate a population mean — and that's genuinely valuable for the large majority of patients who fall inside the expected range of response. But a patient with an extreme divergence — refractory coagulopathy, an unexpected toxicity, a rare multi-organ overlap — is, by definition, outside that range. The guideline runs out of steps exactly where the patient needs help most.

Case reports are the long tail of this distribution. Structuring them as trajectories rather than flattening them into statistics means the system doesn't force incompatible data into a single average — it preserves the individual path, so a clinician facing a rare divergence can ask, in effect: has anyone published a patient who followed this exact sequence, and what happened next? Because case reports follow a fairly standard chronological structure — presentation, intervention, state transition, outcome — this kind of extraction is feasible to run at scale across large open-access archives (PubMed Central, Cureus, BMJ Case Reports, and similar sources), building toward something like a searchable, collective memory of documented patient trajectories.

What Would Make This Deterministic Enough to Trust

A recurring concern with any LLM-adjacent clinical tool is hallucination — invented recommendations presented with false confidence. The proposed answer here is architectural, not just a prompting trick: the evidence pyramid is treated as a strict hierarchy, and each tier is assigned a specific function, not just a ranking.

Evidence Tier	Role in the System
Meta-analyses & clinical guidelines	Hard boundaries — dosing caps, mandatory safety checks
RCTs	Probabilistic guidance for the standard patient cohort
Case reports & series	Structural maps of rare, non-linear divergences

Under this scheme, the LLM's role is restricted to routing — matching a patient's active node to the right sub-graph of evidence — rather than generating clinical content from scratch. Every recommendation shown to a clinician should be traceable on one side to the exact patient data that triggered it, and on the other to the exact citation backing it. That two-sided traceability is what separates this from an LLM simply "sounding confident."

Extending this into a live EMR only sharpens the requirement. If patient state is streamed in via FHIR resources, the same agentic layer that prunes routine noise from a case report can, in principle, prune routine noise from a live encounter — watching for the same phase-transition moments (a lab crossing a threshold, a trajectory branching) rather than firing on every discrete observation. That's also the point at which alert fatigue becomes a design constraint rather than a footnote: a system that treats every encounter as worthy of deep trajectory exploration will drown clinicians in exactly the noise it was meant to remove. The architecture needs a gate — stay on the standard corridor by default, and only activate deep graph exploration when a patient actually crosses an uncertainty threshold.

Concretely, this points toward a dual-graph architecture. On one side sits a Patient State Graph, derived in real time directly from FHIR resources — FHIR is already graph-shaped, since resources like Observation, Condition, and MedicationRequest reference each other and time-stamp a patient's state as it evolves. On the other side sits the Evidence Trajectory Graph described throughout this piece — the multi-tier pyramid of meta-analyses, RCTs, and case reports. The Agentic Vibe Rounds module functions as the bridge between them: a topological compiler that continuously reads the FHIR stream, discards the routine 95% (stable vitals, standard diet orders), and matches whatever remains against active hub-nodes on the evidence side. Critically, this ingestion isn't uniform across a patient's stay — it needs to flex with where the patient is in their care. At early admission, the surface worth watching is narrow (chief complaint, triage vitals, allergies) and the priority is catching divergence and misdiagnosis early, so case-report-tier warnings about atypical presentations rank above guideline corridors. Near discharge, the relevant surface widens to the full longitudinal record — multi-day lab trends, procedure history, medication changes — and the priority inverts: readmission-risk evidence from meta-analyses and systematic reviews takes precedence, with rare delayed-complication case reports (like late serum sickness) held in reserve as secondary warnings. The same underlying graph-matching mechanism, in other words, needs different tuning depending on whether the question is "are we missing something at the start" or "are we about to send this patient home into a blind spot." A further implication worth naming: because FHIR is bi-directional, a clinician acting on a graph recommendation — say, ordering a peripheral smear to check for TMA — could in principle have that action written back automatically as a FHIR ServiceRequest, closing the loop between the reasoning layer and the actual medical record rather than leaving the recommendation as a suggestion the clinician has to re-enter by hand.

What Separates a Novice from an Expert — and Why That Matters for Design

There's a deeper point buried in all of this that's easy to miss: the gap between a novice and an expert clinician isn't just a difference in how much knowledge each has stored. It's a difference in salience weighting — knowing, instantly, which one or two signals in a noisy picture actually matter, and assigning near-zero weight to the rest. A novice evaluates everything in parallel and gets overwhelmed. An expert has already decided, before consciously reasoning about it, that 95% of the incoming data isn't worth their attention.

This is exactly what the critical hub-node mechanism is trying to encode computationally — not more knowledge, but better pruning. It also explains why the tool shouldn't be "on" for every encounter. Uncomplicated, guideline-conforming cases don't need trajectory exploration; they need the system to stay quiet and let the standard corridor run.

How This Differs From What Already Exists

It's worth being precise about where this sits relative to existing systems, since each adjacent category solves a different part of the problem:

• Traditional CDSS (rule-based alerts in systems like Epic or Cerner) encode static IF-THEN logic and tend to fail — or fire irrelevant alerts — the moment a patient presents atypically.
• Standard medical LLM/RAG tools retrieve semantically similar text but have no structural or temporal awareness — they can't tell a clinician when in a trajectory something happened or what caused it.
• Medical knowledge graphs (such as PrimeKG or UMLS) capture static biomedical relationships — that a toxin causes a syndrome — but not longitudinal, patient-specific state transitions.
• Recent academic GraphRAG frameworks extract entity-relation structure from literature to give LLMs better context, but generally stop at summarizing text; they don't build temporal, multi-tier evidence trajectories or apply the kind of cognitive pruning described here.

Trajectory-based GraphRAG, as sketched out through the ASV prototype, sits in a gap between these categories — combining the structural rigor of a graph, the grounding of RAG, and a pruning heuristic modeled on expert cognition rather than exhaustive search.

The Honest Caveats

Two things are worth holding onto before treating any of this as more than a promising direction.

First, the engineering is the easy part. Clinical medicine is not a domain of clean abstractions — it's full of ambiguity, incomplete information, and consequences that can't be undone. A well-structured evidence graph doesn't remove that uncertainty; at best, it clears away administrative and cognitive clutter so a clinician has more room to reason through the parts that genuinely require judgment.

Second, and just as important: sometimes the correct clinical action is no action at all. Tools like this carry a structural bias toward surfacing more — more evidence, more divergence warnings, more nodes to explore — which can subtly encourage overtreatment or diagnostic overreach. A system built on this paradigm is only mature once it can represent restraint as rigorously as it represents escalation — showing, when the evidence supports it, that watchful waiting is the best-supported path on the graph.

Closing Thought

The underlying bet here is simple: clinical decision support should be shaped around how expert clinicians actually allocate attention — a small number of high-leverage decision points, embedded in an otherwise quiet, guideline-conforming path — rather than around the idea that a system should be ready to explain everything, all the time. Whether or not this exact architecture is the one that gets built, that reframing — from covering every edge case to correctly finding the few that matter — seems like the more durable idea.

References

Live prototype:

1. Vibe Rounds — Research
2. ASV Evidence-Pyramid Trajectory Mapper (full demo)

The Avinash Principle — blog series (classworkdecjan.blogspot.com):

1. The Avinash Principle: Critical Hub-Node Navigation
2. The Avinash Principle: From Trajectory...
3. The Avinash Principle: From One...
4. From Averages to Trajectories: Mapping...
5. From One Trajectory to Every Trajectory
6. From Averages to Whole Pyramid: Mapping...
7. Evidence-Pyramid Trajectory Mapper

 

Beyond System 1 and System 2: Why Clinical Medicine Needs "System 3" Thinking — and Why AI Can't Do It Alone

Daniel Kahneman gave us a durable vocabulary for how humans think. System 1 is fast, intuitive, pattern-matching — the gestalt "something's off about this patient" a nurse feels walking into a room. System 2 is slow, deliberate, analytical — working through a differential diagnosis step by step, weighing probabilities, checking them against guidelines.

Clinical medicine, though, has always run on a third mode that this framework doesn't fully capture. Call it System 3: the layer where raw data collection and analytical reasoning are fused with situated judgment — the ability to gather the right information in context, sense what matters, and interpret it against a particular patient, in a particular room, at a particular moment. It's not just faster System 1 or more rigorous System 2. It's the integration of perception, technique, and meaning-making that happens at the bedside, not on a spreadsheet afterward.

This distinction matters enormously right now, because AI is getting very good at two of the three ingredients of clinical reasoning — and this is exactly where the "AI will replace doctors" conversation goes wrong.

Breaking down clinical reasoning into its parts

Clinical decision-making can be roughly decomposed into three stages:

1. Data collection — history-taking, physical examination, ordering and performing tests, observing the patient over time.
2. Data analysis — pattern recognition, probabilistic reasoning, weighing differentials, applying evidence and guidelines.
3. Contextualization and judgment — deciding what data even matters here, how to elicit it, and what it means for this particular human being, including things that never make it into structured data at all.

AI — particularly large language models and predictive/probabilistic clinical decision support (CDS) systems — is increasingly strong at stages 1 and 2 in a narrow, delegated sense. It's stage 3 where things get far harder, and where the "replacement" narrative overreaches.

Where AI genuinely helps

Data collection, assisted. Ambient scribes can listen to a consultation and draft structured notes. Chatbot intake tools can gather a structured history before a visit. Wearables and remote monitors generate continuous physiological data no human could collect by hand. In this narrow sense, AI can do some data collection — or at least pre-process and structure it — faster and more consistently than a tired resident at 2 a.m.

Data analysis, augmented. This is where AI shines brightest. Give a model a set of symptoms, labs, and imaging findings, and it can generate a probabilistically ranked differential, flag drug interactions, predict deterioration risk (sepsis scores, early warning systems), or catch a subtle finding on a radiograph that a fatigued eye might miss. These are pattern-matching and probability-estimation tasks over well-structured inputs — exactly what modern ML is built for. Decision support tools like this have shown real value in reducing diagnostic error and cognitive load.

So far, so promising. This is where most "AI in medicine" headlines live, and the enthusiasm is largely earned.

Where it breaks down: perception in context

Here's the catch. Steps 1 and 2 above are only as good as the framing that produces them — and framing is a System 3 act.

Consider a clinical examination. A skilled clinician palpating an abdomen isn't just running a fixed protocol and recording "tenderness: yes/no." They're integrating the patient's guarding, their breathing pattern, a flicker of hesitation before answering a question, the smell of ketones on the breath, the fact that this patient minimized their pain last time and is underreporting again, the socioeconomic context that means they delayed seeking care by two weeks. They decide, in real time, which question to ask next based on the answer to the last one — a branching, adaptive process, not a checklist.

None of this is "data" in the sense an algorithm consumes. It becomes data only after a human has already decided it's relevant, elicited it skillfully, and interpreted it — and that decision is inseparable from embodied presence, trust-building, and situational awareness that current AI does not have. An AI reading a transcript of the encounter is working with the residue of judgment already exercised by a person in the room; it cannot go back and re-perform the exam itself, feel the mass, notice the wince, adjust its questioning based on a shift in the patient's affect.

This is the crux: AI is strong at analyzing well-posed data, and weak at deciding what "well-posed" even means for this patient, in this moment. The contextualization step — perception, technique, empathic calibration, ethical judgment about what to disclose and when — is not a data problem. It's a situated problem, entangled with a physical body, a relationship, and a history that a probabilistic model, however sophisticated, hasn't lived through with the patient.

So: replacement, or partnership?

None of this means AI's role is trivial — quite the opposite. A realistic division of labor looks like this:

• AI as scribe and pre-processor: structuring what's said and observed into usable data.
• AI as second reader: offering probabilistic differentials, risk scores, and guideline checks that widen the clinician's view and catch blind spots.
• Clinician as elicitor and interpreter: performing the exam, asking the next question, sensing the unsaid, deciding what the data collected even means for this patient's life and values.
• Clinician as final integrator: taking the AI's probabilistic output and re-contextualizing it — because a 92% likelihood of condition X means something different for a 34-year-old marathon runner than an 80-year-old with three comorbidities and a fear of hospitals, and that recontextualization is a judgment call, not a calculation.

The "AI will replace doctors" narrative tends to collapse stages 1–3 into a single pipeline and assume that because AI is encroaching on 1 and 2, 3 will inevitably follow. But System 3 thinking — the fusion of perception, technique, and contextual judgment — isn't a harder version of the same task. It's a different kind of task, one built on embodied presence and relational trust that data, however well-analyzed, doesn't substitute for.

The more honest framing isn't "AI vs. doctors." It's AI absorbing the mechanizable middle of clinical reasoning — freeing clinicians to spend more, not less, of their time on the part that was always hardest to automate: sitting with a person, asking the right next question, and making sense of what's in front of them.