01Why start here
Most clinical data tools do one of two things. They either reduce a patient to a diagnosis code and a handful of averaged lab values, or they reduce a population to a summary statistic — a mean HbA1c, a percentage readmitted, an odds ratio. Both moves throw away the thing that actually matters at the bedside: the path a specific person took to get where they are.
Person-Centered Clinical Analytics is a small, synthetic-data demo built to ask a different question: what if the unit of analysis was never "the diagnosis" or "the average patient," but the trajectory — the actual sequence of observations, decisions, and outcomes a person passes through — and what if every patient's trajectory could be laid on top of everyone else's, so you could see at a glance where a given person's path is ordinary and where it diverges?
That idea didn't come out of nowhere. It's a direct application of something called the Avinash Principle, a way of thinking about clinical cognition developed across an earlier series of pieces. Understanding the principle first makes the analytics model much easier to read, so this post covers both — briefly.
02The Avinash Principle, in short
The starting observation is almost a math joke: model a real clinical journey as a full decision tree — every actor, every choice, every physiological branch — and the number of theoretical paths explodes into the hundreds of millions. A loosely modeled snakebite case, for instance, comes out to roughly 244 million possible trajectories from bite to discharge.
And yet clinicians don't calculate any of that. They don't run a search algorithm over a quarter-billion branches before acting. So what are they actually doing?
The answer the series arrives at: expert clinical cognition isn't a pathfinding engine, it's a pruning engine. It doesn't try to compute every branch — it identifies the small number of nodes, usually well under 1% of the theoretical total, that actually carry the case's "gravity." Everything else is managerial noise that experts correctly ignore.
This maps onto ideas from complexity science — scale-free networks where a few hub nodes hold disproportionate influence, self-organized criticality (a system sitting at a threshold where one more small input triggers a large shift), and flow systems that reorganize toward the path of least resistance.
Two things make this more than a restatement of the 80/20 rule:
- Nodes come in two flavors. Explainable nodes are grounded in known pathophysiology (insulin resistance as a hub linking vascular, lipid, and renal pathways). Experiencable nodes are narrative or behavioral — a sleep disruption, a financial stressor, a pattern of leaving care early — observed repeatedly in practice even without a clean mechanistic story. Ignoring the second category is exactly how a clinically "correct" plan still fails in the real world.
- Every high-leverage node is a bifurcation point. The same lever that saves a patient can also be the one that harms them — ASV can stop envenomation or trigger anaphylaxis. So identifying a hub node isn't enough; each one needs an expected outcome, a red-flag failure mode, and a safety preparation (the circuit breaker that has to be ready before acting, not after).
This principle was later extended from single cases to bodies of evidence — mapping trajectories across case series, then across case-control, cohort, cross-sectional, RCT, and meta-analysis designs, each with its own honest constraints on what the data can and can't claim (an odds ratio is never allowed to masquerade as absolute risk; a cross-sectional snapshot never gets drawn with a directional arrow it can't support). The throughline across all of it is one rule that never changes: never let a visualization imply a stronger causal, temporal, or evidentiary claim than the underlying design was built to prove.
Person-Centered Clinical Analytics takes that same discipline and applies it one level further — not to a single case, and not to a body of literature, but to a whole patient cohort, viewed as a set of comparable trajectories.
03The model: person first, diagnosis second
The core structural choice is to model every patient as one graph, built from the same four-stage skeleton regardless of disease:
Five node types populate that graph — Patient, Observation, Diagnosis, Intervention, Outcome — connected by relational edges (SUGGESTS, INDICATES_PLAN, PRODUCED_OUTCOME, MODULATES, CONSTRAINS). Every patient's graph is built the same way, then merged into a single cohort graph. Nothing about the code branches by disease — a deliberate constraint that Step 7 of the build (a written audit) checks by scanning the actual source for any place disease type influences logic rather than just labeling or filtering.
On top of that single graph structure, the demo offers several different lenses, each answering a different question:
Atemporal vs. temporal (Mode A/B)
Strip timestamps and cluster a patient's whole profile into a gestalt snapshot, or plot the same events on a shared timeline (years since diagnosis), with spikes and severity sized visually. The same rendering logic produces a spiky trajectory for one condition and a smooth branching one for another, with no special-cased code — an echo of the case-series-mapper idea that a textbook path and its outlier forks should emerge from the data, not be hand-drawn.
Pivot lens
Re-anchor the same graph around a diagnosis, an intervention, or a diagnosis×intervention combination, instead of around a patient. Same data, different center of gravity.
Comparator filter
Layer population, timing, and outcome/facility/resource filters over the cohort to build matched subgroup comparisons — the analytics equivalent of the "divergence path" concept from case-control mapping: where do two groups' trajectories pull apart most sharply, and by how much.
Clinical output view
A plain-language re-presentation of everything above, organized the way a clinician would actually want to read it — evidence, variation, and, deliberately placed front and center, a confounders section naming every approximation and data gap. This is the same "state what the data can't prove" discipline carried over from the evidence-pyramid work.
Nested Analysis View
The newest piece, and the most direct descendant of that hub-node logic. Every patient — regardless of diagnosis — is walked through the same six generic checkpoints: Diagnosis → Presentation → Initial plan → Escalation → Advanced/recurrent → Disposition. Wherever two or more patients land on the same checkpoint value, their lines converge onto a shared node instead of drawing in parallel. The result is a single map where hub nodes emerge automatically — the checkpoints most patients pass through become visually dense, and the checkpoints only one patient reaches stand out as genuine divergence, the same hub-vs-noise distinction a clinician would otherwise have to make by instinct, now made visible for a whole cohort at once.
04Patient vs. population: the comparative layer
The newest extension pushes the nested view one step further: load a population's cohort graph as the background network, then overlay a single patient's trajectory on top of it as a highlighted line. Where the patient's checkpoint value doesn't exist anywhere in the loaded population, that step is placed off to the side with a dashed connector and flagged "not seen in population sample" — an honest way of surfacing a genuinely atypical path rather than forcing it onto the shared map.
This layer also handles multi-morbidity directly: a patient with three comorbidities contributes three extra diagnosis rows to the graph, each carrying its own presentation-through-disposition course, plus the primary condition — four rows total for a three-comorbidity patient. That's the mechanism for asking, in the terms of the earlier framing: does this specific patient's path look like the textbook trajectory for each of their conditions, or does it diverge — and at which checkpoint?
Percentile cards underneath the map show where the patient falls on age, event count, and comorbidity burden relative to the full loaded population, so the comparison isn't only visual — it's quantified against a stated baseline.
05A worked example: one Type 1 diabetes patient through the model
Abstractions are easier to trust once they're run against one concrete case. Here's a single synthetic T1D patient, walked through each layer of the model above — the same patient, viewed through a different lens each time.
A 16-year-old presenting with polyuria, polydipsia, and unintentional weight loss over three weeks. Labs show a random glucose of 420 mg/dL and positive urine ketones. No prior diagnosis. Admitted, started on an insulin infusion, transitioned to a basal-bolus regimen, discharged with outpatient endocrinology follow-up. Eight months later, an emergency visit for diabetic ketoacidosis (DKA) tied to a missed insulin dose during a school trip.
This single history becomes: an Observation node (polyuria/polydipsia/weight loss, glucose 420, ketones positive) that SUGGESTS a Diagnosis node (T1D, new-onset), which INDICATES_PLAN an Intervention node (IV insulin → basal-bolus transition), which PRODUCED_OUTCOME an Outcome node (stabilized, discharged). The later DKA episode adds a second pass through the same skeleton — a new Observation (missed dose, ketosis) SUGGESTS a recurrence-flagged Diagnosis state, INDICATES_PLAN a new Intervention (ED insulin/fluids), PRODUCED_OUTCOME a second Outcome (resolved, adherence counseling added). Nothing in this structure is T1D-specific — the same four boxes would hold a T2D patient's slower, medication-titration story just as well.
Strip the timestamps and this patient's whole profile clusters into one gestalt: new-onset T1D, insulin-dependent, one DKA recurrence flagged. Useful for a quick "what is this person's overall picture," but it flattens the eight-month gap between onset and the DKA episode into a single snapshot.
The same data plotted on a shared axis — years since diagnosis — shows two distinct spikes: the initial diagnostic event at time zero, and a second acute spike at month eight. This is where T1D's characteristic shape becomes visible: irregular, acute-spike events rather than the smooth, slowly branching regimen typical of a T2D trajectory. Nothing was hand-drawn to make it look that way — the same rendering logic just responds to genuinely different underlying data.
Re-anchor the view around "insulin therapy" instead of around this one patient, and the same node — the basal-bolus intervention — now sits at the center, with every T1D and T2D-on-insulin patient in the cohort radiating outward from it. This reframes the question from "what happened to this patient" to "who else in the cohort shares this patient's core intervention, and how did their outcomes compare."
Filter the cohort to T1D patients under 18 with at least one DKA episode, grouped by facility tier. If this patient's DKA recurrence resolved faster (or slower) than the matched subgroup average, that becomes visible directly, alongside a stated confounder — e.g., that "missed dose during travel" is a narrative/adherence factor the graph tags but doesn't weight, echoing the earlier point that a biographical detail like this can matter more than a lab value.
Walking this patient through the six generic checkpoints — Diagnosis → Presentation → Initial plan → Escalation → Advanced/recurrent → Disposition — their line passes through "Escalation" and "Advanced/recurrent" (the DKA episode), which is exactly where the tour's own framing predicts T1D lines will keep forking, while most T2D lines in the same cohort land on "No escalation recorded" and stop. This patient's line converging with other T1D patients at the Escalation checkpoint, rather than standing alone, is what makes that checkpoint a hub — a pattern the graph reveals rather than one a clinician has to assert by hand.
Load this one patient's graph on top of the full cohort's nested network, and their trajectory is drawn as a highlighted line, with percentile cards showing where they sit on age, event count, and comorbidity burden relative to the loaded population. If this were a three-comorbidity patient — say T1D plus early nephropathy plus depression — the graph would carry four diagnosis rows total (the primary T1D course plus one row per comorbidity), each sharing the same presentation-through-disposition chain, so the patient could be checked against three separate textbook trajectories at once rather than being forced into a single blended one.
Read against that same framework: the DKA-recurrence checkpoint here is functioning as this patient's phase-transition node — the moment a small input (a missed dose) had disproportionate downstream effect. The graph doesn't calculate that significance; it just makes the convergence and divergence visible enough for a clinician's own pruning instinct to land on it faster.
06Why this pairing makes sense
The principle is fundamentally about where a single expert's attention should go — which handful of nodes, out of millions of theoretical possibilities, actually carry a case's gravity. Person-Centered Clinical Analytics takes that same question and asks it structurally, across a cohort: which checkpoints turn out to be hubs empirically, because many patients converge there, and which checkpoints turn out to be genuine outliers, because almost nobody else's trajectory passes through them?
Put differently — it describes how an expert prunes a decision tree in their head, in real time, for one patient. The nested cohort graph is what that pruning looks like when you do it visually, after the fact, across many patients at once, and let convergence and divergence patterns surface on their own rather than being asserted by a single clinician's intuition.
Neither replaces the other, and neither claims to be more than what it is: a synthetic-data demo and a cognitive-training scaffold, not a validated system, not clinical decision support, and not a substitute for judgment at the bedside.