guided tour · read this between the idea and the build

Person-Centered Clinical Analytics: Guided Tour

A walkthrough for a learner/ analyst who wants to understand what this demo is, how the seven build steps fit together, and where to click to try each tool yourself — before diving into the concept article or the raw build log.

Read this first This is a self-contained, in-browser demo built on a synthetic patient corpus (no real PHI). It is for learning, exploration, and post-hoc audit of a person-centered analytics idea — it is not a validated system, and it is not clinical decision support. Keep that framing in mind as you click through the tools below.

The two source documents

This tour sits between these two pages. Read the idea first if you want the "why," the build log if you want the "how it was actually made" — or skip both for now and go straight to the tools below.

💡 Idea — Person-Centered Clinical AnalyticsPart 1 · concept

The architecture sketch this whole demo is built on: why the model starts from the whole person (observations → diagnosis → interventions → outcomes) rather than a single diagnosis, the knowledge-graph structure and node/edge schema, the atemporal vs. temporal toggle, the three pivot lenses (disease / intervention / combo), the global comparator framework (Section 6), and the T1D-vs-T2D longitudinal pilot rationale (Section 7b) that Steps 1–7 implement. Also states the scope limits plainly: idea-stage, not clinically deployable, not a CDS/SaMD tool.

Read the idea (Part 1) →
🛠️ Build — Building the Person-Centered Analytics DemoPart 2 · implementation log

The working build log for the T1D vs. T2D pilot: seven ordered steps, each a self-contained HTML/JS page (no Python, no server), with what was asked for, what was actually built, and the outcome/output file for each step — from the synthetic corpus generator through the graph builder, the four dashboard views, and the final generalization audit. Includes the exact prompt block used to kick the build off in a fresh Claude session.

Read the build log (Part 2) →
The two source documents How to use this tour The map: idea → graph → dashboard Step 1 — Corpus generator Step 2 — Graph builder Step 3 — Dashboard (atemporal/temporal) Step 4 — Pivot lens Step 5 — Comparator filter Step 6 — Clinical output view Step 7 — Generalization check Nested Analysis View — unified trajectory map What to read next
00

How to use this tour

The seven tools below form a pipeline: each one downloads a JSON file that the next one loads. You don't need to run them in strict order to understand the idea, but if you want to reproduce the whole pipeline yourself, follow this sequence:

  1. Open Step 1 and generate the synthetic corpus → download dm_corpus.json.
  2. Open Step 2, load that file, and build the graph → download cohort_graph.json.
  3. Open Steps 3–6 in any order, loading cohort_graph.json into each via the file-load control on the page.
  4. Read Step 7 — it's a written audit, not an interactive tool, and doesn't require a file load.
  5. Optionally, load cohort_graph.json once more into the Nested Analysis View for a single unified map of every patient's trajectory instead of one lens at a time.

Every tool runs entirely in your browser — nothing is uploaded anywhere, and no real patient data is involved at any stage.

01

The map: idea → graph → dashboard

Before you touch any tool, it helps to hold the shape of the whole thing in your head. The concept starts from a person, not a disease:

Observations → Diagnosis → Interventions/Plan → Outcomes

That single graph structure, repeated per patient and merged into a cohort, is what every step below reads and re-presents in a different way. Steps 1–2 build the data and the graph. Steps 3–6 are four different lenses on that same graph — a toggle, an anchor, a filter, and a clinician-readable summary. Step 7 checks whether that reuse was honest (i.e., whether the code actually generalizes across the two example conditions, T1D and T2D, or secretly special-cases them).

StepQuestion it answersReadsProduces
1Where does the data come from?— (generates it)dm_corpus.json
2How does raw data become a graph?dm_corpus.jsoncohort_graph.json (+ CSV/GraphML)
3What does the graph look like per patient / per cohort?cohort_graph.json— (read-only view)
4What if I re-center on a diagnosis or an intervention instead?cohort_graph.json— (read-only view)
5How do I compare matched subgroups?cohort_graph.json— (read-only view)
6How is this shown to a clinician, plainly?cohort_graph.json— (read-only view)
7Does the code actually generalize across diseases?the Step 2–6 sourcewritten verdict
NestedHow does my patient's path compare against everyone else's?cohort_graph.json— (read-only view)
02

The seven tools

Each card below explains what the tool does, what to look for while you try it, and links directly to the live page.

1Corpus generatorgenerates data

Produces a small synthetic cohort — 9 Type 1 and 9 Type 2 diabetes patients, seeded so results are reproducible — as FHIR-flavored JSON bundles (Patient, Condition, Observation, MedicationRequest, Encounter), tagged with facility_tier, resource_status, and a disease-appropriate timing field.

Try this: generate the corpus, open the JSON, and compare one T1D record against one T2D record — notice the irregular acute-spike events in T1D versus the slow, branching regimen in T2D. That contrast is the whole point of the pilot (see Section 7b of the concept article).

Try Step 1 →
2Graph builderbuilds the graph

Loads dm_corpus.json and instantiates the five node types (PatientNode, ObservationNode, DiagnosisNode, InterventionNode, OutcomeNode) and the relational edges (SUGGESTS, INDICATES_PLAN, PRODUCED_OUTCOME, MODULATES, CONSTRAINS) — all client-side, no server. Merges per-patient graphs into one cohort graph.

Try this: load your Step 1 output, then look at the node/edge table it renders. Download cohort_graph.json — you'll reuse this exact file in Steps 3–6.

Try Step 2 →
3Dashboard — atemporal / temporal toggleread-only

Loads cohort_graph.json and renders it two ways behind one toggle: Mode A (Atemporal/Gestalt) strips timestamps and clusters each patient's full profile; Mode B (Temporal trajectory) plots timestamped edges on a shared axis (years since diagnosis), with spike markers and severity sizing.

Try this: pick one T1D patient and one T2D patient, flip the toggle on each, and notice how the same rendering logic produces a spiky trajectory for one and a smooth branching one for the other — with no disease-specific code path.

Try Step 3 →
4Pivot lensread-only

Loads the same cohort_graph.json and re-indexes it around a chosen anchor instead of a chosen patient: Disease-centered, Intervention-centered, or the Disease + Intervention combo hyper-node (defaults to T1D × insulin therapy).

Try this: switch between the three lenses on the same cohort and watch the dropdown(s) and the view change without re-loading any data — it's the same graph, just re-anchored.

Try Step 4 →
5Comparator filterread-only

Three independent filter layers over the cohort: a population filter (T1D/T2D/all), a disease-appropriate intervention-timing filter, and a comparator matrix (outcome, facility tier, resource status) with a group-by control.

Try this: click the one-click “Load Section 6 example query” button to reproduce the worked example from the concept article end-to-end, then build your own query by hand and compare.

Try Step 5 →
6Clinical output viewread-only

Re-presents what Steps 3–5 already established, organized for a clinician: an Evidence pair of T1D/T2D cards, a Variation table broken out by facility tier and resource status, and a Confounders section listing every approximation and data gap in one place. A sticky banner keeps the scope note visible throughout.

Try this: read the Confounders section first — it's the most honest part of the whole demo, and it tells you exactly which numbers to trust less.

Try Step 6 →
7Generalization checkwritten report

A written audit, not an interactive tool. It scans the actual source of Steps 2–6 for every place the disease type is referenced and classifies each occurrence as generic (used only to filter or label) or special-cased (the logic itself branches by disease). Verdict: mostly confirmed, with two flagged exceptions.

Try this: read this after you've clicked through Steps 3–6 yourself — it will make a lot more sense once you've seen the toggle and the lens in action.

Try Step 7 →
Nested Analysis View — unified trajectory mapnew · read-only

A newer, eighth tool, added after the original seven-step pipeline. Steps 3–6 each show one lens on the cohort at a time. This page instead nests every patient's trajectory — T1D and T2D together — into a single network, modeled on the case-report trajectory mapper this whole project takes its "hub / textbook-path / divergence" reading style from (see the Evidence-Pyramid Trajectory Mapper demo). Every patient is walked through the same six generic checkpoints — Diagnosis → Presentation → Initial plan → Escalation → Advanced/recurrent → Disposition — and wherever two or more patients land on the same checkpoint value, their lines converge onto one shared node instead of drawing in parallel. Pick any single patient from the dropdown and their line lights up against the rest of the cohort, with their own checkpoint chain spelled out underneath — a direct answer to "how is my patient moving compared to everyone else on the same map."

Try this: load cohort_graph.json, then pick a T1D patient and a T2D patient in turn — notice how T1D lines keep forking through Escalation and Advanced/recurrent (the acute-spike pattern from Section 7b), while most T2D lines land on "No escalation recorded" and stop there.

Try the Nested Analysis View →
03

What to read next

Person-centered clinical analytics — guided tour · synthetic data only · not for clinical use