Lessons 1 through 5 all took a single case as the unit of reasoning — one patient, one differential, one advocate, one handover brief. That framing has a limit, and this lesson exists to name it: some of the most consequential clinical questions can't be answered by reasoning harder about one case. "Is this drug actually working across our patients?" or "which of our diabetics are falling out of follow-up?" are questions about a population, and a mind trained only on single-case reasoning will either refuse them or, worse, answer them by quietly generalizing from whichever cases happen to be memorable.
A scope note, honestly stated: like Lesson 5, this is a shorter lesson than Lessons 3, 4, and 7. The analytics modules are newer and less battle-tested than the core reasoning modules — several of the aggregate-query patterns below have been exercised against synthetic or de-identified registry extracts rather than a live clinical data warehouse. Read what follows as a way of thinking about scale, not a validated pipeline to deploy as-is.
Every attending who has ever asked "how are our patients actually doing on this?" was asking a population question with a single-case brain. This lesson is about noticing that shift in question type, and reasoning differently once you've noticed it.
This is the shift from a single-record lookup — SELECT * FROM patients WHERE id = ? — to a registry-level aggregate query — SELECT ... FROM patients GROUP BY .... Same underlying data model, but a different class of question, with its own failure modes.
Defining the Cohort: Module 5
Module 5 opens with the question every population query silently depends on and almost never states out loud: who, exactly, is "our patients"? Before any counting or trending happens, the module forces an explicit cohort definition — the inclusion criteria, the exclusion criteria, and the time window — written down as a sentence a colleague could audit, not left implicit in whatever the query happened to pull.
The reason this comes first is that most bad population claims aren't wrong arithmetic — they're a correct calculation over an unstated, badly-drawn cohort. "30% of our patients are non-adherent" means something completely different depending on whether the denominator is everyone ever prescribed the drug or only patients still active in the practice.
This is the same discipline as a well-built differential from Lesson 3, just applied one level up — a sloppy differential misdiagnoses one patient, a sloppy cohort definition misdiagnoses an entire practice's performance.
This is schema design before the query, not after — a WHERE clause you can't defend in a code review shouldn't ship, and a cohort definition you can't defend in a chart review shouldn't drive a population claim.
From Record to Registry: Module 6
Module 6 is where the single-record habits from Lessons 1–5 actively work against you. A clinician trained to weigh one patient's full context is, by instinct, resistant to collapsing that context into a number — and that instinct is correct at the bedside and wrong at the registry. The module's core move is teaching when to deliberately set aside case-level nuance in favor of a defensible aggregate, and when that trade is not worth making.
Its sharpest prompt is a discipline check, run before any number is reported rather than after:
The missing-data threshold is the whole lesson in miniature: a population statistic with a large silent gap isn't imprecise, it's potentially about a different population than the one being described — the patients who dropped out of data collection are rarely a random subset of the cohort.
The patients missing from your data are almost never missing at random — they're disproportionately the ones who moved, lost insurance, or stopped coming in, which usually correlates with worse outcomes, not neutral ones.
This is the difference between a single-record query and a registry-level aggregate query — a single NULL is a bug to fix on one row; a 30% NULL rate on an aggregated column is a validity threat to the entire statistic, and needs to be reported alongside it.
Where Aggregates Lie: Modules 22 & 23
Modules 22 and 23 catalog the specific ways an honestly-computed aggregate still misleads — Module 22 focused on denominator traps (Simpson's paradox, survivorship bias in a cohort that loses members over time), Module 23 focused on the comparison traps that show up once two cohorts are placed side by side (unadjusted comparisons across practices with different case mixes, trend lines drawn across a change in measurement definition). Together they function as a red-team pass over Module 6's output, the population-scale sibling of the bias audit from Lesson 4.
The module's own worked example is the one worth remembering: a clinic's "improved" readmission rate that, on inspection, tracked a change in how readmissions were coded rather than a change in patient outcomes. The aggregate was computed correctly at every step; the story built on top of it was false.
This is the population-level version of the anchoring bias from Lesson 4 — once a number moves in the direction you expected, it's tempting to stop checking whether the number is measuring what you think it's measuring.
This is a schema migration hiding inside a trend line — comparing metrics across a change in how the underlying data was collected or coded is the aggregate-query equivalent of joining two tables that changed their column definitions mid-history without a migration note.
Analytics Across Time: Module 27
Module 27 extends Module 6's snapshot discipline across a longitudinal registry — the same kind of tracking Module 3 (Lesson 5) did for one patient, run instead across a whole cohort's trajectory. Its distinguishing move is treating cohort attrition itself as a signal worth analyzing, not just a data-quality nuisance to work around: who stops appearing in the registry, and when, is often clinically informative in its own right.
The module closes with a step that mirrors Module 13's omission question from Lesson 5, applied at scale — what the aggregate report chooses not to say is as consequential as what it reports:
A registry that only reports on patients who stayed engaged is quietly reporting on the healthiest, most resourced slice of the population it claims to describe — the patients who disappeared are often the ones the report most needed to be about.
This is survivorship bias made concrete in a longitudinal query — rows that drop out of a time-series join don't vanish from reality, they vanish from the denominator, and a trend computed only over the rows that persisted is a trend about persistence, not about the outcome.
Homework for Lesson 6
- Take the case you've carried since Lesson 2 and imagine ten more patients like it. Write one sentence defining the cohort you'd need to answer "how are patients like mine actually doing?" — explicit inclusion criteria, exclusion criteria, and time window (Module 5).
- Pick one statistic you'd want to report about that cohort (a rate, an average, a proportion). State its denominator, numerator, and estimate what fraction of the cohort might have missing data on the relevant variable — and whether that missingness is likely random or not (Module 6).
- Describe one way a naive before/after comparison on this cohort could be misleading — a change in measurement, a change in who's included, or attrition that isn't random — and rewrite the comparison so it accounts for that trap (Modules 22–23, 27).
This lesson draws directly on Module 5 — Population Cohort Definition, Module 6 — Registry-Level Aggregate Analytics, Module 22 — Denominator Traps & Aggregate Bias, Module 23 — Cross-Cohort Comparability Audit, and Module 27 — Longitudinal Registry Analysis, all from the VibeRounds Prompt Directory. As noted at the top of this lesson, the analytics modules are newer and less validated than the core reasoning modules — treat the prompts here as a way of structuring population-level questions, not as a validated analytics pipeline. If you're coming from the evidence side, the companion Evidence-Based Medicine for Techies course pairs well with this one, particularly its lessons on statistics and confounding. Neither course is a clinical decision tool; see the VibeRounds disclosure statement for full terms.