Person-Centered Clinical Analytics

Explore an idea for a clinical reasoning and analytics demo that moves from raw, scattered patient data to structured, comparative evidence — without collapsing patients into rigid, single-disease silos. The system is person-centered first, and disease-, intervention-, or combo-centered analytics are projections on top of that person-centered data, not the starting point.

Original 3-phase roadmap.

Phase 1 — Scaffolding (infrastructure)

• Align data model with FHIR / SNOMED / LOINC.
• Select a pilot condition (e.g., snakebite envenomation, or CKD).
• Define “bucketing” logic: filter patients by diagnosis codes and timeframes.

Phase 2 — Reasoning layer (LLM integration)

• Build an extraction engine: prompts/scripts that pull “critical decision nodes” from narrative records.
• Build nested analysis: scripts that find a common decision point (e.g., “ASV dosage decision”) across multiple records and index the variation.

Phase 3 — Guardrail (clinical validation)

• Human clinician is the final interpreter and decision-maker; the system surfaces evidence, it does not decide.
• Dashboard must present AI findings in a clinically readable way: evidence, variation, and confounding context at a glance.

Rather than starting from a disease, the pipeline starts from the whole person:

Observations → Diagnosis → Interventions/Plan (atemporal) → Outcomes

3.1 — Knowledge graph structure

[ Patient / Person ]
       │
       ├──(Has Observation)──► [ Observations: Signs, Symptoms, Vitals, Labs ]
       │
       ├──(Has Diagnosis)────► [ Diagnoses: Coded terms, Lists, Descriptive one-liner ]
       │
       ├──(Receives Plan)────► [ Interventions / Plan: Meds, Procedures, Orders ]
       │                       (Atemporal: what was chosen, not strictly when)
       │
       └──(Results In)───────► [ Outcomes: Clinical status, resolution, complications ]

3.2 — Node types & attributes

3.3 — Relational edges

• (Observation) -[:SUGGESTS]-> (Diagnosis)
• (Diagnosis) -[:INDICATES_PLAN]-> (Intervention)
• (Intervention) -[:PRODUCED_OUTCOME]-> (Outcome)
• (ComorbidityDiagnosis) -[:MODULATES]-> (Intervention)
• (Observation) -[:CONSTRAINS]-> (Intervention)

3.4 — Technical pipeline

1. Ingestion & parsing — raw EMR notes, discharge summaries, or FHIR JSON bundles per patient.
2. Entity extraction (person-centered pass) — holistic scan for all active observations, full diagnosis set, full intervention bundle, and final outcomes (no disease pre-filter).
3. Graph construction — instantiate nodes/edges per individual.
4. Comparative aggregation — overlay multiple person-graphs to compare intervention bundles vs. outcomes across similar patients.

Time is modeled as an edge property, not a rigid node sequence, so the dashboard can toggle modes instantly.

[ Patient Node ]
       │
       ├──(HAS_OBSERVATION {timestamp: t1})──────► [ Observation ]
       ├──(HAS_DIAGNOSIS {onset: t1})────────────► [ Diagnosis ]
       ├──(RECEIVES_PLAN {atemporal_bundle: true})► [ Intervention / Plan ]
       └──(RESULTS_IN {time_to_outcome_delta: d})─► [ Outcome ]

Multi-patient / population view

• Cohort super-nodes: patients with similar baseline profiles dynamically grouped.
• Vectorized trajectory averaging instead of overlapping spaghetti lines, e.g.:
  • Path A (65%): Observation → Diagnosis X → Bundle 1 → Positive outcome (avg 4.2 days)
  • Path B (35%): Observation → Diagnosis X+Y → Bundle 2 → Complication (avg 2.1 days)

Dashboard modes

The same underlying person-centered graph can be re-anchored around three different centers without rebuilding it.

Selecting a lens re-indexes the graph layout and re-clusters trajectories around the new anchor.

A 3-part comparator framework.

6.1 — Population (disease or disease combo)

Anchor diagnosis/cluster, normalized globally via SNOMED CT so the same diagnosis matches across facility types and geographies.

6.2 — Intervention

Standardized via LOINC and procedural coding so different local names/workflows map to the same underlying intervention.

6.3 — Comparator (subgroup & context matrix)

• Outcome-based subgroups: rapid recovery vs. complications/prolonged stay.
• Intervention-based subgroups: dosing, timing, alternative combinations.
• Temporal subgroups: time-of-intervention (e.g., golden-hour vs. delayed).
• Individual vs. cohort vector: pin the current patient against any matched subgroup.

6.4 — Normalization for global context

• Facility tier weighting: primary / secondary / tertiary / quaternary — adjusts for baseline acuity differences and referral bias.
• Resource gradient scaling: resource-plenty vs. resource-constrained — flags/clusters decisions driven by infrastructure or cost constraints rather than clinical failure.

6.5 — Example query

“Show me patients with [disease combo] who received [intervention], filtered by [resource-constrained tertiary facilities], broken down by [temporal time-of-intervention subgroups], and map [my current patient’s] trajectory against that specific comparator curve.”

Existing prototype: “Critical Hub Node Navigation” ASV demo (12-case corpus), which already functions as an early Intervention Node view with meta-analysis/RCT evidence layered on individual case reports.

Integration plan

1. Population layer (disease + context) — Move beyond “snake bite” alone to a full baseline profile per case (age group, rural/urban, time from bite to admission, etc.) — group by “patient gestalt,” not just diagnosis label.

2. Intervention layer (ASV critical node) — Treat each ASV decision (high vs. low dose, FFP adjuncts) as a comparative node. Tag each node with facility tier (e.g., quaternary = resource-plenty; rural = resource-constrained).

3. Comparator layer (subgroup engine) — Outcome subgroup: recovery without neuro deficit vs. recovery with sequelae. Temporal subgroup: “golden hour” (ASV <2h) vs. “delayed” (ASV >6h) — test whether RCT/meta-analysis evidence aligns with local case-report results within each temporal band.

Action plan

1. Tag the 12 cases with a JSON metadata layer:

   {
     "facility_tier": "primary | secondary | tertiary",
     "resource_status": "plenty | constrained",
     "presentation_delay": "<hours>"
   }

2. Define the pivot function: a filter over the existing “Unified Case Insights” view, e.g., “show trajectories from secondary facilities where ASV was delayed >4 hours.”
3. Use this tagged, filterable ASV dataset as the working prototype for the global comparator framework (Section 6) before generalizing to other conditions.

The ASV/snakebite pilot (Section 7) is a good fit for the acute, single-encounter case: a short decision window, a bounded intervention, and outcomes resolved within days. But the person-centered model (Sections 3–4) is equally, if not more, meant for longitudinal care — conditions where the observation → diagnosis → intervention → outcome loop repeats over years or decades, and where the “Intervention/Plan” node isn’t a single choice but an evolving regimen.

Diabetes mellitus is a useful example precisely because Type 1 and Type 2 stress the model in two different, complementary ways:

Type 1 diabetes (T1D) — acute-resource-heavy, chronic condition

• Diagnosis is typically early-onset and abrupt (often presenting as DKA), but management is lifelong.
• Within the longitudinal trajectory, care demand is episodic and unpredictable: hypoglycemic events, DKA admissions, sick-day management, insulin pump/CGM failures. These are acute-care spikes layered on top of a chronic baseline.
• Temporal Mode (Section 4, Mode B) needs to render this as a trajectory with irregular, high-acuity spikes rather than a smooth curve — the interesting comparator question is less “did outcomes converge over time” and more “how did the system absorb the spikes” (time-to-ER, time-to-stabilization, spike frequency per patient-year).
• Facility-tier and resource-gradient tagging (Section 6.4) matter acutely here: a T1D patient in a resource-constrained setting with unreliable insulin/CGM supply chains has a fundamentally different risk profile than one in a resource-plenty setting, even with an identical HbA1c history.

Type 2 diabetes (T2D) — balanced, decades-long chronic management

• Diagnosis is typically gradual, often incidental (screening-detected), with a long asymptomatic runway.
• Management is a slow-moving, multi-decade regimen: lifestyle intervention → oral agents → combination therapy → insulin, with comorbidity accumulation (hypertension, dyslipidemia, CKD, retinopathy) modulating the plan at each stage (ComorbidityDiagnosis -[:MODULATES]-> Intervention, Section 3.3).
• Temporal Mode here is closer to the model’s original intent: a long, gradually branching trajectory where the comparator question is “at what point did management diverge, and how did that divergence compound over years” — e.g., early vs. delayed insulin initiation, and its effect on complication-free years.
• Resource gradient scaling matters differently: it’s less about acute-supply failure and more about sustained access — years of consistent follow-up, medication adherence support, and screening for complications, which resource-constrained settings may not sustain at the same cadence as resource-plenty ones.

Why pairing T1D + T2D is useful for the demo

Running both through the same person-centered graph structure stress-tests whether Mode A (Atemporal/Gestalt) and Mode B (Temporal Trajectory) genuinely generalize:

• T1D exercises the model’s ability to represent acute spikes within a chronic timeline (irregular edges, high-acuity subgroups).
• T2D exercises the model’s ability to represent slow divergence and comorbidity accumulation over a much longer time horizon (smooth but branching trajectories, multi-decade time_to_outcome_delta).

If the same graph schema and dashboard toggle can meaningfully represent both without special-casing, that’s a reasonable signal the underlying architecture (Sections 3–4) is sound — independent of whether the pilot itself is clinically deployable (see scope note, top of document).

• Confirm pilot case(s): ASV/snakebite (acute, single-encounter) remains the primary demo; evaluate adding T1D vs. T2D (Section 7b) as a second, longitudinal demo, and/or CKD in parallel.
• Finalize EMR data format assumption: FHIR resources (Patient, Observation, Condition, MedicationRequest, Encounter) confirmed as source.
• Build FHIR-to-graph ingestion mapping (HTML/JS, in-browser — no Python; Neo4j-ready CSV export for later). Done: step2_graph_builder.html.
• Define full tagging schema for facility tier / resource status / temporal delay across the case corpus.
• For a longitudinal pilot (T1D/T2D), define how multi-decade sequences are chunked/sampled for the dashboard (Section 7b) without losing acute-spike detail for T1D.
• Prototype the Pivot Lens selector and Atemporal/Temporal toggle in the dashboard UI.
• Design the “clinically readable” validation dashboard for Phase 3 (evidence + variation + confounders at a glance).