A record of how this project moved from an idea — modeling a patient as a graph instead of a diagnosis — through a working, coded FHIR + SNOMED CT pipeline, to a backward-reasoning engine and, finally, a closed loop that drafts its own next research question.
Skip everything below if you only need the headline: this project builds a pipeline where deterministic code — not a language model — computes every clinical statistic (cohort counts, comorbidity lift, escalation rates, hub nodes), and an LLM sits in a narrow, clearly bounded role on top of it: turning a plain-language question into a coded query, reading the ranked results, deciding what's worth a reviewer's attention, and — in the final "closed loop" phase — proposing the next question to ask based on what it just found. A human always has to sign off before any finding is treated as real. That loop — code computes, LLM interprets and re-directs, human approves — is what the four project phases below build up to and what the worked example demonstrates concretely.
The full report below runs long. If you only need the headline for your role, start here — everything else is the detail behind these two paragraphs.
This is a research and audit tool, not a diagnostic or treatment aid. Ask a plain-language question about a group of patients — or start instead from something that already happened, like a readmission — and the pipeline returns a coded, traceable cohort report: who matched, what recurred before the outcome, and how much more often than baseline. Every number is a direct read from coded data, never a generated guess, and every finding is a correlation flagged for a human to check, not a directive to act on. Two mandatory human checkpoints sit inside the automated loop; nothing re-enters the system as a confirmed pattern without a reviewer's sign-off. Built and tested on synthetic and public sandbox data only — a working proof of concept, not a validated clinical system.
In practice today: nothing to install or log into — every phase links to a click-through browser demo with a query box and preloaded examples, results in a few seconds. But it isn't wired into any real EHR, order set, or workflow yet, so this is something to explore and stress-test, not something you'd open at the bedside.
On real data, at real scale: the pipeline is the easy part — real charts are the hard part. Comorbidities live in free-text notes as often as problem lists, symptoms get under-coded, and "no finding" can mean "never happened" or just "never coded." A real hospital's history would also generate far more candidate patterns than one person can triage by hand, so the two checkpoints shown here would need to sit inside a real governance process — a committee or protocol deciding which leads even reach a reviewer. And before any finding could touch real care, it would need what any decision-support tool needs: a validation study, IRB oversight, and a defined role in the workflow — not just working software. Once those pieces are in place, though, the payoff is real: what today takes a specialist days of manual chart review — tracing a handful of readmissions back to a shared cause by hand — becomes something a quality or research team can run continuously across an entire population, with every candidate traced to the specific coded records behind it, ready to accept or dismiss in minutes instead of reconstructing from scratch.
Runs client-side against the open SMART Health IT R4 sandbox (no auth, no backend of its own): a plain-language phrase resolves through a curated ~50–100-concept SNOMED CT dictionary with ECL-style descendant expansion, translates to a coded FHIR search, and returns pre-computed cohort analytics via fixed output templates. Generative AI is scoped to exactly one deterministic step (phrase → concept, currently a lookup table, not a model call), plus — in the closed-loop phase — choosing which ranked finding clears a threshold and drafting the next query; it never computes a lift ratio, matches a cohort, or writes an outcome rate itself. Known gaps: negated or compound queries are aggregated post-fetch rather than encoded in the FHIR search, ready-made templates only run against the bundled offline Pneumonia cohort, and a full ECL server would need a UMLS Metathesaurus license. Architecture and worked examples are below.
In practice today: every phase is static client-side HTML/JS — no server to stand up, forkable and deployable as-is on something like GitHub Pages, so it's cheap to clone and poke at. Pointing it at a real health system would mean swapping the open sandbox for an authenticated FHIR endpoint, growing the concept dictionary past its current ~50–100 terms, and adding the access control and audit logging a demo doesn't need.
On real data, at real scale: production FHIR servers are messier than the sandbox — partial SNOMED adoption, mixed ICD-10/SNOMED coding, non-conformant resources — so the dictionary and query translation need real mapping and validation, not just more entries. A live deployment also needs everything a demo skips: an authenticated, HIPAA-compliant endpoint behind the institution's firewall, PHI-aware access control and audit logging, monitoring for concept or coding-practice drift over time, and a plan for keeping lookup-table coverage honest as it scales past a few hundred concepts. None of that is exotic, but it's a second build's worth of work, not a config change. Once that infrastructure exists, though, it scales well: adding a new use case is mostly a matter of expanding the concept dictionary and cohort templates rather than re-architecting the pipeline, and because every output traces back to a coded FHIR resource, the system stays auditable even as it's asked more questions.
A concrete run of the pattern the two summaries describe, using an illustrative, synthetic Type 2 diabetes cohort — not a real result.
Problem statement: among coded Type 2 diabetes patients, which treatment combination correlates with the strongest glycemic response — and at what safety cost?
Metformin alone; metformin + GLP-1 agonist; metformin + SGLT2 inhibitor; basal insulin initiation; metformin + structured lifestyle program — each a coded medication/procedure combination pulled straight from the cohort, not a hand-picked comparison.
HbA1c reduction ≥1.0 point at 6 months (primary); hypoglycemic event within 90 days; weight change at 6 months; ED visit for hyperglycemia within 6 months — one primary outcome, three safety/secondary outcomes tracked alongside it.
| Intervention set | Patients | HbA1c response rate | vs. baseline | Hypoglycemia (90d) |
|---|---|---|---|---|
| Metformin + GLP-1 agonist | 142 | 68% | 2.1× | 3% |
| Metformin + SGLT2 inhibitor | 118 | 61% | 1.9× | 2% |
| Basal insulin initiation | 96 | 57% | 1.8× | 14% |
| Metformin + structured lifestyle program | 87 | 49% | 1.5× | 1% |
| Metformin monotherapy | 210 | 32% | 1.0× (baseline) | 2% |
The project moved through four distinct but connected builds. Each one kept a discipline the last one established, then added a new capability on top of it.
The throughline is a single design rule that survives every stage: generative AI is never allowed to invent a clinical fact. It can help turn a plain-language phrase into a coded concept, and it can propose the next question to ask — but every cohort count, hub node, lift figure, and outcome rate is a direct read from computed or coded data. What starts as a modeling idea about representing a person as a graph ends, four builds later, as a pipeline that can find its own next hypothesis and hand it to a human for a decision.
The foundational idea: stop modeling "the diagnosis" and model the person instead. Every patient, whatever disease they have, is represented as the same four-stage graph — so comparing across diseases becomes a matter of re-slicing one dataset rather than building a new dashboard each time.
The analytics model is a direct application of an earlier idea, the Avinash Principle: a real clinical journey modeled as a full decision tree explodes into hundreds of millions of theoretical paths (a snakebite case alone comes out to roughly 244 million), yet clinicians never calculate any of that.
Two refinements matter here: nodes are either explainable (grounded in known pathophysiology) or experiencable (narrative/behavioral — a missed dose, a financial stressor — observed repeatedly without a clean mechanistic story), and every high-leverage node is a bifurcation point — the same lever that saves a patient can also harm them, so identifying a hub node isn't enough; it needs an expected outcome, a red-flag failure mode, and a pre-positioned safety response.
Five node types, five relational edges, and — critically — time modeled as a property on the edges rather than a rigid sequence, which is what makes the atemporal/temporal toggle possible without duplicating the data.
| Node | Carries |
|---|---|
PatientNode | Anonymized ID, baseline demographics, immutable context |
ObservationNode | Raw text / SNOMED–LOINC code, severity, timestamp |
DiagnosisNode | Term/phrase, confidence, primary vs. comorbidity |
InterventionNode | Action type, target, dose/frequency |
OutcomeNode | Status, response to plan, adverse events, discharge state |
Edges: SUGGESTS · INDICATES_PLAN · PRODUCED_OUTCOME · MODULATES (comorbidity → intervention) · CONSTRAINS (observation → intervention)
T1D and T2D are both "diabetes" colloquially, but as data-generating processes they look almost nothing alike — which is exactly why they were chosen to test whether one schema and one set of rendering functions could honestly represent both without special-casing either.
Irregular, acute glycemic-spike events, insulin-dependent from diagnosis. The clinically interesting question is delivery device: pump vs. injection.
Smooth, branching regimen progression — diet → oral agents → insulin — escalated over years. The interesting question is timing: early vs. delayed insulin initiation.
The idea's very first pilot, notably, was not diabetes at all: it was sketched against ASV (anti-snake-venom) treatment for envenomation — a single-encounter, acute-care scenario where the comparator question was dosing timing (a "golden hour" administration within 2 hours vs. a delayed one past 6). T1D/T2D was deliberately picked second because chronic, decades-long regimen management stresses the same schema in the opposite direction from a bounded acute decision window.
Each step is a self-contained, client-side HTML/JS page — no server, no upload — and downloads a JSON file the next step loads.
| Step | Question | Produces |
|---|---|---|
| 1 · Corpus generator | Where does the data come from? | dm_corpus.json (9 T1D + 9 T2D synthetic FHIR bundles) |
| 2 · Graph builder | How does raw data become a graph? | cohort_graph.json |
| 3 · Dashboard | What does the graph look like per patient/cohort? | Atemporal (Mode A) / Temporal (Mode B) toggle |
| 4 · Pivot lens | Re-center on a diagnosis or intervention instead of a patient? | Disease / Intervention / Combo anchor |
| 5 · Comparator filter | How do I compare matched subgroups? | Population × timing × outcome/facility/resource matrix |
| 6 · Clinical output view | How is this shown to a clinician, plainly? | Evidence cards, variation table, sticky Confounders banner |
| 7 · Generalization check | Does the code actually generalize across diseases? | A written audit of the Step 2–6 source |
patientHasPumpEvidence() infers pump-vs-injection from free text meaningful only for T1D (flagged in-UI as an amber assumption). Step 5's timing filter intentionally branches on condition_type because device choice and initiation delay are genuinely different clinical questions — an honest, disease-appropriate exception rather than a hidden gap.
Steps 3–6 each show one lens at a time. The Nested Analysis View goes further: every patient — T1D and T2D — is walked through the same six generic checkpoints, and where two or more patients land on the same value, their lines converge onto one shared node instead of drawing in parallel, so hub nodes emerge automatically rather than being asserted.
At larger scale (a 4,000-patient example — 1,500 T1D + 2,500 T2D) the tool also demonstrated a real confounder worth flagging on its own: T1D populates "Escalation" and "Advanced/recurrent" far more densely than T2D, simply because the synthetic corpus gives T1D more recurring event density — a genuine data-density difference, not a rendering artifact.
A 16-year-old presents with polyuria, polydipsia, and weight loss; glucose 420 mg/dL, ketones positive; admitted, stabilized on insulin, discharged — then eight months later returns in DKA after a missed dose on a school trip. Traced through the model: the atemporal view flattens this to one gestalt ("new-onset T1D, one DKA recurrence"); the temporal view shows two distinct spikes at month 0 and month 8 — T1D's characteristic shape; the pivot lens re-centers on "insulin therapy" to show who else shares that intervention; the comparator filter checks this patient's DKA recovery time against a matched under-18 subgroup; and the nested checkpoint view shows this patient's line converging with other T1D patients at Escalation — which is what makes Escalation a hub rather than an assertion.
The synthetic-cohort demo becomes a real, coded pipeline: a clinician's plain-language phrase resolves to SNOMED CT concepts, runs as a live query against real FHIR patient data, and returns pre-computed cohort analytics — with no backend server of its own.
Why SNOMED CT is the enabling layer: for a "query" to match a "cohort" and a "hub node" to mean the same thing every time, clinical concepts have to be coded, not just written. SNOMED CT gives one canonical concept ID regardless of phrasing, a compositional grammar (not a flat code list), a hierarchy built for roll-up, formal logic that catches nonsense before it reaches a clinician, and cross-mapping to LOINC and drug terminologies.
| Phase | What it does |
|---|---|
| 1 — FHIR connectivity | Shared client, retry-with-backoff, typed search wrappers for Condition/Encounter/Procedure/MedicationRequest/Observation/Patient |
| 2 — SNOMED CT layer | Curated concept dictionary (~50–100 concepts), ECL-style descendant (<<) expansion, deterministic phrase→concept lookup |
| 3 — Query translation | Concepts → http://snomed.info/sct|<id> tokens → real FHIR search URL with pagination |
| 4 — Cohort analytics | Presentation clusters, decision/hub nodes, intervention timelines, tracking correlations — batch-computed, cached by concept ID |
| 5 — Output templates | Clinical Intelligence Brief + Insight Report — fixed templates, fields are data lookups, never generated prose |
| 6 — Visualization | Single-patient trajectory view + cohort radial graph with trend-over-time toggle |
| 7 — Integration | One "Run query" action, explicit "unresolved concept" fallback, preloaded example queries |
Plain-language question → SNOMED concepts (with descendant expansion) → real matching patients, live from a FHIR server.
Clinical junctions a meaningful share of the cohort passes through, highlighted in the trajectory graph.
Comorbidity co-occurrence, time-to-escalation, polypharmacy burden, symptom-to-diagnosis proximity, composite risk scoring.
It also ships an offline bundled Pneumonia cohort (6 exported patient trajectories, seed concept SCT 233604007) so the whole pipeline can be explored even if the shared public sandbox is slow or unreachable, and it includes a first "backward" query mode — scanning the raw timeline data first and synthesizing the query statement that would reproduce a finding — flagged with a distinct badge everywhere it appears, as an early version of Phase 3 below.
| Property | Value |
|---|---|
| Endpoint | https://r4.smarthealthit.org |
| FHIR version | R4 |
| Auth | None — open reads, standard REST search |
| Data | Pre-loaded synthetic (Synthea-style) patients maintained by SMART Health IT |
Query translation today only encodes Condition.code into the FHIR search itself — compound or negated phrases (e.g. "pneumonia without diabetes") are handled by aggregating after the fetch, not by the query. The readymade query templates currently only run against the bundled offline Pneumonia dataset, not any concept fetched live. A full terminology + ECL server would need a UMLS Metathesaurus license. Dictionary-based NL extraction is auditable but brittle on real phrasing.
Instead of a clinician specifying what to look for, start from an outcome that already happened — an escalation, a readmission, a flagged claim — and let the pipeline walk backward through the coded timeline to generate the questions a human would otherwise have to build by hand.
Hypothesis → Query → Records → Confirm/deny. An auditor picks a rule and the system checks compliance one chart at a time. Coverage is limited to rules someone already wrote.
Outcome → Timeline replay → Candidate causes → Cohort test → Question. The system replays the coded timeline into an outcome and surfaces what precedes it most often, then tests the pattern cohort-wide.
Illustrative, not a real patient — an ICU escalation coded at day 0. Working backward: two coded vital-sign observations trending toward the threshold two days prior with no logged intervention in between ("was the trend acted on, or only recorded?"); an antibiotic switched to a second-line agent five days prior ("did the switch correlate with a culture result, or precede one?"); a pre-existing comorbidity already on the problem list two weeks prior ("does this comorbidity recur across other patients who escalated?"). Every trace step ships with the query that produced it.
Running the same replay across every patient who shares the outcome turns an anecdote into a comparison — the same arithmetic an epidemiologist runs by hand for a case-control study, just triggered automatically by the seed outcome.
| Comorbidity present | Patients | Escalation rate | vs. baseline |
|---|---|---|---|
| Chronic kidney disease | 18 | 61% | 2.4× |
| Type 2 diabetes | 26 | 46% | 1.8× |
| COPD | 11 | 39% | 1.5× |
| No flagged comorbidity | 34 | 25% | 1.0× (baseline) |
| Use case | Seed outcome |
|---|---|
| Retrospective quality review | Adverse event, code blue, unplanned ICU transfer |
| Claims / billing audit | Denied or flagged claim |
| Readmission root-cause | 30-day readmission |
| Research hypothesis generation | Any outcome of interest in a registry |
| Pharmacovigilance signal detection | Reported adverse drug event |
What happens when the backward pipeline's top finding becomes the forward pipeline's next query, run on a different dataset, whose new outcome data feeds the backward pipeline again — with two human checkpoints keeping it from running away.
Everything except the two red checkpoints runs without a person present. An orchestrating LLM reads the ranked lift table, drops findings below a threshold, and drafts the next plain-language query from the strongest surviving pattern — but never computes a lift ratio, decides a cohort match, or fabricates a comorbidity link.
Reads the ranked lift table. Chooses which finding clears the threshold. Phrases the next plain-language query. Decides when to stop iterating.
Compute a lift ratio. Decide a cohort matches a concept. Write an outcome rate. Fabricate a comorbidity link.
| Step | Output |
|---|---|
| Backward pass | Pneumonia cohort, seed = ICU escalation. Top finding: CKD → 2.4× lift, n=18. |
| Query drafted | "pneumonia patients with chronic kidney disease" |
| Reviewer approves | Adequate cohort size, clinically plausible, not already a known trigger |
| Forward pass | Second FHIR endpoint, 22 matched patients |
| New outcome | Escalation rate 58% — close to the original 61% |
| Reviewer validates | Pattern replicated within a reasonable band → logged as a confirmed lead, not a clinical rule |
A pattern that clears both checkpoints doesn't just get filed away — it re-enters the system as the next seed outcome. That makes it the same category of fact as a textbook or guideline association (found through trials, registries, and expert consensus), just reached by a different, machine-assisted route: logged with its cohort, its lift, the dataset it replicated on, and the reviewer who signed off, so it can be cited and built on the same way — while still sitting at the "replicated correlational lead" rung, not outranking a guideline that contradicts it.
Causation — lift against a baseline stays a screening signal no matter how many datasets it replicates on. A predictive model — the loop reports observed historical rates, never fits or calibrates a risk model. Coverage of what was never coded — a hallway conversation can't enter round one, and round fifty doesn't recover it. And no license to skip the checkpoints — they're the only place the loop's output is checked against clinical plausibility and independent replication.
An in-browser illustrative demo scans all three tagged lanes (comorbidity, symptom, intervention) across 8 candidate factors on a Pneumonia cohort, computing the ranking, query drafting, forward replication, and pass/fail validation live as you click. A second section goes further and calls the real, public SMART Health IT R4 sandbox live — pulling up to 100 real patients for any of ten SNOMED CT-coded seed diseases, scanning all three lanes exhaustively, and drafting a query card for every candidate, each awaiting a human's approve or reject.
The other four phases each demo one mechanism at a time. This run instead builds a single synthetic 500-patient cohort — 14 SNOMED-coded diagnosis categories, each case carrying age, sex, comorbidities, symptoms, medications, length of stay, and escalation outcome — and pushes it through twelve independent statistical passes end to end, entirely on dummy data, with an LLM reading the output of each pass rather than computing any of it.
The original backward-generated findings ranked by lift, then re-run through a second, independent pull to see which patterns replicate.
Comorbidity co-occurrence matrix, polypharmacy burden, time-to-escalation, symptom→diagnosis proximity, composite risk scoring (with calibration), 30-day readmission drivers, a subgroup equity check, and a hub-node comorbidity network.
Diagnostic ambiguity zones, a high-utilizer cohort (top decile by 90-day encounters), and a Dataset A vs. B drift check — each flagged by the LLM as worth adding after reviewing the first nine passes.
Every pass is followed immediately by a short note distinguishing what was an LLM judgment call from what was deterministic arithmetic, and the page ends with a per-case explorer over all 500 synthetic patients plus the actual FHIR-fetch code, runnable wherever network access allows it.
The full write-up: the four-stage schema, the T1D-vs-T2D stress test, all seven build steps, and the Nested Analysis View.
The tour sitting between the concept article and the build log, with direct links into every one of the seven live tools.
The concept explainer tracing the model back to the Avinash Principle, plus two embedded live demos: the Nested Cohort Trajectory Map and the Comorbidity & Intervention Pivot explorer.
The interactive cohort generator, nested trajectory viewer, pivot explorer, and cohort dashboard, all running client-side against a synthetic 300-patient cohort with 20 conditions.
A stop-by-stop live pipeline: bedside question → concept extraction → ECL query → cohort match → patient cases → brief → insight report → cohort graph.
The full v2 project plan and live demo: seven build phases, the SMART Health IT R4 data source, a bundled offline Pneumonia cohort, and the open risks list.
Starting from an outcome instead of a question: case-level backward traces, cohort-level lift tables, audit and research applications, and a four-phase build order.
Wiring the forward and backward pipelines together with two human checkpoints, plus two live demos — an illustrative in-browser loop and a real SMART Health IT sandbox query generator.
All prior mechanisms combined against one synthetic cohort: backward lift, closed-loop replication, and nine further analytic passes — comorbidity co-occurrence, polypharmacy, time-to-escalation, symptom proximity, risk scoring, readmission drivers, equity check, hub network, diagnostic ambiguity, high-utilizer cohort, and an A vs. B drift check — every number computed deterministically, with an LLM reading and interpreting each pass on synthetic dummy data.
Everything above was built and tested against an open sandbox. A real health system starts from a stronger baseline — its EMR already exposes FHIR and codes to SNOMED CT — which removes the biggest interoperability barrier but not the rest of the work. What remains splits into two tracks.
| Advancement | Why it's needed here |
|---|---|
| Full terminology service integration | Move from a curated ~50–100-concept dictionary to the EMR's own terminology server (or a licensed UMLS-backed ECL engine), so coverage matches what the system actually codes, not a hand-picked subset. |
| Negation & compound query support | Encode "without," "excluding," and multi-condition logic directly into the FHIR search itself instead of aggregating after the fetch, so accuracy holds as questions get more specific. |
| SMART on FHIR / CDS Hooks launch | Launch in-context from the clinician's existing EMR session rather than a standalone page, inheriting the user's identity, role, and patient/encounter context automatically. |
| Production backend & PHI-aware storage | Replace the client-side, no-backend architecture with a proper service layer: encrypted storage, role-based access control, and audit logging on every query and every finding a reviewer sees. |
| Scale-tested analytics compute | Move cohort analytics from live, on-demand FHIR search to a pre-aggregated data mart (an OMOP CDM-style layer, for instance) so lift tables return quickly across a real population, not a sandbox-sized cohort. |
| Concept & coding-drift monitoring | Re-validate the phrase→concept lookup against each new SNOMED CT release and actual local coding patterns — a stale dictionary degrades query accuracy silently. |
| Coverage-confidence scoring | Flag, per finding, how completely the relevant fields are actually coded in that population, so a sparse comorbidity list doesn't quietly read as "no comorbidity." |
| Automated regression testing | Given the deterministic-answer promise, a test suite proving the same query returns the same answer across EMR versions, terminology updates, and code changes. |
| High-speed evidence analytics & generation (LLM-assisted) | Once a pattern clears both human checkpoints, an LLM can cross-reference it against published guidelines and trial evidence, draft the reviewer-facing explanation, and generate audit-ready documentation in minutes — the same "generate fast, ground in real sources" pattern used to compile, cross-reference, and format this report itself. |
| Advancement | Why it's needed here |
|---|---|
| Formal validation protocol | A retrospective study comparing the pipeline's flagged patterns against known, guideline-confirmed associations, before any finding is trusted operationally. |
| Governance charter | A defined committee, review cadence, and escalation path deciding which findings get reviewed, by whom, and what happens once a pattern is confirmed. |
| Clinically meaningful thresholds | Agreed-upon lift, sample-size, and confidence cutoffs for what counts as "worth a reviewer's time," replacing the illustrative thresholds used in this report. |
| Equity & bias review | Check whether cohort definitions and findings hold consistently across age, sex, race, and insurance-status subgroups, so the pipeline doesn't quietly encode existing disparities as "patterns." |
| Clinician training & explainability materials | Teach reviewers what a lift table can and can't say, so "correlation, not causation" survives contact with a busy clinical shift. |
| Regulatory classification review | Determine early, with legal and compliance, whether specific uses cross into FDA software-as-a-medical-device territory as the tool's scope grows. |
| Narrow-scope pilot before broad rollout | Start on a small number of high-volume, well-coded conditions — readmissions, sepsis escalation — before generalizing to the full concept dictionary. |
| Outcome feedback loop | Track what happens after a confirmed pattern changes practice, closing a third, slower loop around the two checkpoints already in the design: did acting on it actually help? |
None of the four phases or the full analytics run change the pipeline's shape — coded query in, deterministic computation, LLM interprets, human signs off. What changes per use case is only which statistic gets computed and which cohort it's computed over. The lists below are the range of clinical, public-health, patient-centered, and evidence-based-medicine analytics that shape supports without any new architecture — just a new query, a new grouping variable, or a new outcome column.
Which conditions cluster together; conditional probability of B given A; comorbidity networks and hub nodes.
Symptom-to-diagnosis time, diagnostic odyssey length for rare conditions, misdiagnosis / diagnostic-ambiguity zones.
First-line vs. second-line therapy rates, time-to-treatment, treatment switching and escalation sequences.
Drug counts per patient, interaction-risk flags, deprescribing candidates by age or renal function band.
Time-to-escalation curves, early-warning-score drift, ICU transfer and code-blue precursor patterns.
Trend-before-event analysis (the "was it acted on, or only recorded" question), threshold-crossing detection.
LOS distribution by diagnosis and comorbidity load, discharge-disposition mix, delayed-discharge drivers.
Test-ordering patterns relative to guideline indication, repeat-test rates, low-yield test flagging.
Multi-factor risk indices built from coded variables, with calibration checked against observed outcome rates.
Incidence and prevalence trends by concept, geography, or time window; outbreak or cluster detection.
Outcome and access differences across age, sex, race, and insurance-status strata — flagging disparities rather than asserting cause.
Outcome correlation with coded SDOH factors (housing, food access, insurance gaps) where the EMR captures them.
Guideline-adherence rates for screening intervals, vaccination coverage, gap-in-care identification.
Adverse-drug-event rate by medication and comorbidity combination, backward-traced from the event to plausible triggers.
Top-decile utilization identification for care-management targeting, drivers of repeat encounters.
30/90-day readmission rate by cause, comorbidity, and prior utilization pattern.
Registry-wide tiering for outreach or case-management prioritization, using the same composite-risk logic as a single cohort.
Time-series decomposition of coded diagnoses to separate seasonal signal from genuine anomaly.
One patient's coded timeline as a graph — diagnosis, presentation, plan, escalation, disposition — nested against peers who share checkpoints.
How this patient's course compares to a matched subgroup on age, diagnosis, and comorbidity load.
Coded, traceable "patients like you" statistics — not a recommendation, a transparent base rate.
Missed follow-ups, medication-refill gaps, and screening intervals overdue for a specific patient.
Coded symptom frequency and overlap across visits as a rough burden proxy where PROMs aren't captured.
Multi-year view of a chronic condition's escalations, remissions, and intervention changes for one patient.
Backward-generated candidate causes for an outcome, cohort-tested for lift before a human ever writes a hypothesis by hand.
Rate of coded care matching a specific guideline's recommended pathway, with deviations flagged for review.
Re-running a finding against an independent dataset or a later time window to see whether the pattern holds (Dataset A vs. B drift).
Observed-rate tables (not trial data) usable as a screening signal ahead of, or alongside, a formal study.
Outcome rate in an exposed vs. unexposed coded cohort, computed the way an epidemiologist would by hand, just automatically triggered.
Every finding traceable to the coded records and query that produced it — built for chart audit or IRB review, not just a chart.
| Advantage | Why it matters here |
|---|---|
| Deterministic, reproducible numbers | Every statistic is a direct read from coded data via fixed arithmetic — two people running the same query get the same answer, and the answer doesn't drift with model version or prompt wording. |
| Full traceability / auditability | Every finding carries the query, the cohort, and the coded records behind it, so a reviewer, auditor, or IRB can walk back from conclusion to source without re-deriving anything. |
| LLM scoped to a narrow, checkable role | The model interprets and prioritizes; it never computes a rate or fabricates a link — which keeps hallucination out of the one place (the numbers) where it would be most costly. |
| Speed at scale | What takes a specialist days of manual chart review — tracing readmissions back to a shared cause by hand — runs continuously across a whole population in minutes. |
| One architecture, many questions | Clinical, public-health, patient-centered, and research questions all reduce to the same coded-cohort-in / statistic-out shape, so adding a use case is a new query and grouping variable, not a rewrite. |
| Coded-terminology consistency | SNOMED CT concepts (not free text) mean "pneumonia" means the same thing in every query, every cohort, and every comparison, regardless of how a clinician phrased it. |
| Human checkpoints built in, not bolted on | Findings can't silently re-enter the system as "confirmed" — a reviewer signs off before a pattern is treated as real, keeping correlation from quietly becoming a clinical rule. |
| Cheap to extend and deploy | Static client-side demos are forkable and deployable as-is; a new analytic pass is a new statistical function against the same cohort structure, not new infrastructure. |
| Equity and bias visibility | Because subgroup splits are just another grouping variable, disparities across age, sex, race, or insurance status surface as a normal analytic output instead of requiring a separate special-purpose audit. |
| Bridges research and bedside timeframes | The same backward-lift logic that generates a research hypothesis can, once validated, feed a patient-facing comparator statistic — one pipeline serving both the population and the individual view. |
Five builds, one shape. The top row is the project's actual chronology; everything it can compute today fans out underneath it, all passing through the same two checkpoints before anything counts as a finding.