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:
- Vibe Rounds — Research
- ASV Evidence-Pyramid Trajectory Mapper (full demo)
The Avinash Principle — blog series (classworkdecjan.blogspot.com):
- The Avinash Principle: Critical Hub-Node Navigation
- The Avinash Principle: From Trajectory...
- The Avinash Principle: From One...
- From Averages to Trajectories: Mapping...
- From One Trajectory to Every Trajectory
- From Averages to Whole Pyramid: Mapping...
- Evidence-Pyramid Trajectory Mapper
