01 Forward audits ask questions. Backward generation finds them.
Most clinical audit and research tooling is forward-directed: someone decides what to check for — a guideline, a hypothesis, a compliance rule — and the system queries records to confirm or deny it. That works well when the reviewer already knows what to suspect. It works poorly when the interesting signal is exactly the thing nobody thought to ask about.
An auditor picks a rule ("was antibiotic X given within 4 hours?") and the system checks compliance one chart at a time. Coverage is limited to rules someone already wrote.
The system starts from an outcome that already occurred, replays the coded timeline leading into it, and surfaces the comorbidities, delays, and interventions that precede it most often — then asks whether that pattern holds across the cohort.
The mechanism is deliberately unglamorous: no free-text generation stands between the outcome and the finding. Every candidate cause is a SNOMED CT / FHIR-coded item that already sits on the patient's or the cohort's timeline; the pipeline's job is ordering, filtering, and comparing those items against a baseline, not inventing explanations.
02 Architecture: outcome-in, evidence-trail-out
The pipeline sits downstream of a standard FHIR + SNOMED CT store. It doesn't replace forward querying — it adds a second entry point that starts at the end of the timeline instead of the beginning.
Because every stage stays inside coded data, the artifact produced at step 5 is auditable in the literal sense: a reviewer can re-run the attached query against the source records and get the same table back.
03 Case-level: replaying one patient backward from the event
At the single-patient level, backward generation looks like a reverse chart review that a human would normally do by scrolling up through the record. The difference is that the pipeline does the scrolling, tags each item by clinical lane, and proposes the question a reviewer would eventually ask anyway.
Worked trace — ICU escalation, day 0
Illustrative, not a real patientWhat makes this "generated" rather than manual
- The lookback window, lane tagging, and ordering are computed once per outcome type and reused — a human doesn't re-decide "how far back should I look" for every chart.
- Each trace step ships with the query that produced it, so the case-level narrative is a rendering of data already pulled, not a separate write-up a reviewer has to trust blind.
- The candidate questions are templated from the pattern found (a gap, a switch, a pre-existing condition), not composed freely — the same gap type always produces the same question shape.
04 Cohort-level: turning recurring traces into lift
A single backward trace is an anecdote. Running the same replay across every patient who shares the seed outcome turns it into a comparison: does this comorbidity, this delay, this medication pattern show up more often among patients who escalated than among the baseline?
| Comorbidity present | Patients | Escalation rate within group | vs. cohort 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) |
This is the same arithmetic an epidemiologist runs by hand for a case-control study — baseline rate, subgroup rate, ratio — just triggered automatically by the seed outcome instead of a pre-registered hypothesis. It doesn't replace a designed study; it tells a reviewer or a researcher where a designed study might be worth running.
Which finding would a quality committee want first?
- Rank by lift, then by cohort size, so rare-but-huge-lift artifacts don't crowd out common, actionable patterns.
- Surface the counterfactual too — patients with the same comorbidity who did not escalate — so the finding reads as a lead, not a verdict.
Which pattern is worth a pre-registered hypothesis?
- Treat the ranked list as hypothesis-generation output, explicitly separate from any confirmatory analysis.
- Attach the exact cohort-selection query so a second team can reproduce the same pool before designing a real study on top of it.
05 Where this fits in audits and research
| Use case | Seed outcome | What backward generation adds |
|---|---|---|
| Retrospective quality review | Adverse event, code blue, unplanned ICU transfer | Auto-drafts the "what led up to this" section reviewers currently assemble manually from scrolling charts. |
| Claims / billing audit | Denied or flagged claim | Traces the coded justification chain backward to see whether the denial pattern clusters around a specific documentation gap. |
| Readmission root-cause | 30-day readmission | Compares discharge-window coded events across readmitted vs. non-readmitted patients with the same index diagnosis. |
| Hypothesis generation for research | Any outcome of interest in a registry | Produces a ranked, reproducible shortlist of candidate exposures before committing study design and funding to one. |
| Signal detection for pharmacovigilance | Reported adverse drug event | Surfaces which pre-event medication changes or comorbidities recur across reports at a rate above baseline. |
06 Build order
Single-case backward trace
- Fixed lookback window per outcome type; lane-tag coded items (comorbidity, symptom, intervention, escalation).
- Render the trace with the query attached to every step — no narrative generation yet.
Cohort roll-up and baseline comparison
- Repeat Phase 1 across all patients sharing the seed outcome; pool into frequency tables.
- Compute baseline outcome rate and per-item lift; require a minimum group size before surfacing a lift figure.
Templated audit / research artifacts
- Turn ranked findings into a standard brief format (presentation → intervention → tracking) built entirely from computed fields.
- Attach a reproducibility footer: exact query, cohort size, and whether the result came from cache or a fresh run.
Reviewer sign-off loop
- Every generated question routes to a human reviewer before it becomes an audit finding or a study hypothesis.
- Log accept/reject decisions to see which finding types are actually useful, and prune the templates that never survive review.