Trajectories, Not Averages: Why I Built Person-Centered Clinical Analytics

Most clinical dashboards are built to answer one question: what happened to the average patient? That's a useful question if you're managing a hospital budget. It's a much weaker question if you're trying to understand why this patient, sitting in front of a clinician, is deteriorating faster than the cohort average predicted.

That gap — between population-level statistics and individual clinical reasoning — is what I set out to close with Person-Centered Clinical Analytics, a client-side, browser-based tool for exploring synthetic patient cohorts as trajectories instead of averages.

You can try it here: Person-Centered Clinical Analytics, and read a fuller write-up of the thinking behind it here: Person-Centered Clinical Analytics — article

The core idea

Traditional clinical analytics tools flatten patient history into rows in a table. A diagnosis, a lab value, a medication — all disconnected snapshots in time. That's easy to aggregate, but it destroys the thing that actually matters clinically: the sequence of decisions and outcomes.

My model instead represents each patient's history as a directed graph:

Observation → Diagnosis → Plan → Outcome

Each edge in that graph carries intent — INDICATES_PLAN, PRODUCED_OUTCOME — so the causal reasoning behind a clinical decision is preserved, not just the isolated events. When you look at a cohort this way, you're not looking at a bar chart of outcomes; you're looking at hundreds of individual decision paths overlaid on top of each other.

Four things I focused on

1. Structure over flat tables. The tool models patient histories as graphs rather than exports, which is closer to how care actually unfolds — one decision shaping the next.

2. Hub nodes, not noise. Rather than surfacing every possible data point, the tool highlights the small number of "hub nodes" — checkpoints like diagnosis, initial plan, escalation, and disposition — where most patients' paths actually converge or diverge. This mirrors how experienced clinicians think: they don't scan everything, they prune to the few decision points that matter.

3. Confounders, front and center. Instead of hiding data gaps behind a clean-looking dashboard, the tool has a dedicated confounders layer and explicitly flags what the data can't prove — including which values weren't even seen elsewhere in the population. I wanted the tool to check cognitive bias, not enable it.

4. Pivoting around interventions, not just patients. Beyond viewing a single patient's trajectory, you can re-anchor the whole cohort around a specific diagnosis or intervention — "what happened to everyone on this regimen?" — and pin up to three pivots side by side to compare disposition breakdowns, stratified by age and sex.

What it actually looks like in practice

The tool has four working views:

• Generator — builds a synthetic cohort client-side (no server, no real patient data) from parameters like cohort size, comorbidity rate, and a condition mix across 20 conditions in three families. Same seed and parameters always reproduce the same cohort.
• Nested Viewer — a zoomable, pannable graph of the whole cohort's trajectories through six checkpoints (diagnosis → presentation → initial plan → escalation → advanced/recurrent → disposition), with node size reflecting how many patients converge there, and dashed nodes flagging outlier values not otherwise seen in the population. You can overlay one or two individual patients against the population to see where they diverge.
• Pivot Explorer — lets you re-center the graph around a diagnosis, intervention, or the combination of both, filtered by age band, sex, or escalation status, with a confounders panel and stratified breakdowns alongside it.
• Cohort Dashboard — the population-level view: age distribution, sex mix, condition prevalence, an escalation-rate leaderboard, and a comorbidity co-occurrence matrix (shaded by observed-vs-expected co-occurrence, so you can see which conditions cluster together more or less than chance would predict).

Every number in the tool is explicitly labeled synthetic, and generated for demonstration — this is an educational scaffold, not a clinical decision support product.

Where this fits (and doesn't) in the existing landscape

I didn't build this in a vacuum — patient journey analytics already exists in health economics tooling and academic informatics (OHDSI/OMOP-based cohort trajectory tools, for instance). What's different here is the combination:

• It's a single, self-contained, client-side tool — no data warehouse, no OMOP pipeline setup.
• It's built around a pruning philosophy — surfacing the few high-leverage decision points instead of showing every statistic with equal weight.
• It treats epistemic humility as a first-class feature, not an afterthought — the confounders and "what the data can't prove" layer is built into the interface itself, not buried in a footnote.

What's next

If I take this further toward real clinical research use, the honest next challenges are:

• Messy data — real EHR data has missing timestamps and inconsistent coding (ICD-10 vs. SNOMED); the graph rendering needs a real strategy for gaps, not just synthetic completeness.
• Interoperability — mapping the graph's nodes to FHIR resources (Observations, Conditions, Procedures) so it could ingest real-world data.
• Quantifying "hub-ness" — right now hubs emerge visually through convergence; adding a real graph-theoretic metric like betweenness centrality would give the pruning heuristic some objective backing.

For now, this project is what I wanted it to be: a tool that treats context as data, keeps the individual trajectory visible alongside the population, and refuses to pretend a dashboard knows more than it does.