OMOP cohort definitions: the logic behind every real-world evidence study

A cohort is not a code list

The Book of OHDSI defines a cohort as a set of persons who satisfy one or more inclusion criteria for a duration of time. It is explicit that a cohort is not a code set: it needs logic for how codes are used, such as first occurrence versus any occurrence, and a well-defined cohort specifies how a person enters and how they exit¹.

A few properties follow: one person can belong to several cohorts, can belong to the same cohort in different periods, but not twice in the same period, and a cohort can be empty¹. Cohorts are also defined independently and reused, so the same outcome cohort can serve many studies¹.

The building blocks

Rule-based definitions combine four components¹:

• Domain: where the data lives in the CDM, such as drug exposures or procedures.
• Concept set: a data-agnostic expression of standard concepts for the clinical idea, portable across databases.
• Domain-specific attributes: days' supply for a drug, a measurement value or range.
• Temporal logic: when one criterion must occur relative to another, for example within 365 days before the index event.

Assembled, they answer three questions: what event sets the index date, which inclusion criteria apply, and what ends cohort membership¹. In OHDSI tools there are no separate exclusion criteria; "exclude prior hypertension" becomes "include people with zero occurrences of prior hypertension"¹.

Definitions as code

Definitions built in ATLAS are stored as JSON and compiled to SQL for each database platform, and tools such as CohortGenerator run them in analysis pipelines². That is what makes OHDSI network studies possible: the same definition, run unchanged at many sites.

For a data platform, I treat cohort definitions as versioned artefacts: stored in a repository, reviewed, tested against data quality checks as in OMOP data quality checks, and linked to every result produced with them.

Where LLMs fit

Turning a clinical question into a cohort definition is skilled, slow work, which makes it a natural target for language models. Research is exploring this, including an MCP server that exposes the OHDSI WebAPI's cohort tools so a model can assemble definitions from natural language³. That design is the right shape: the model calls structured tools that produce standard definitions, rather than writing free-form SQL.

The risks are clinical, not technical. A plausible definition with the wrong concept set, a missing washout period or an exit rule that silently drops patients will run perfectly and produce wrong evidence. My rules:

1. Generate into the standard format, never ad hoc SQL, so definitions can be reviewed in familiar tools.
2. Require clinical review of concept sets and temporal logic before any use.
3. Check against data: counts, attrition by criterion and patient profiles, before trusting results.
4. Prefer reuse. Start from established, validated definitions where they exist, and let the model adapt rather than invent.

The tool-based approach also follows the governance patterns in MCP Apps and tool annotations: read-only tools for exploration, review before anything is saved or run.

How I can help

I design OMOP platforms and research pipelines where cohort definitions are versioned, tested and reproducible, and help teams apply AI to them safely. See healthcare data architecture, or analyse your challenge and bring the result to a call.