Inferensys

Glossary

Inclusion Criteria

Inclusion criteria are the specific clinical, demographic, and temporal characteristics a patient must possess to be eligible for enrollment in a clinical study or cohort definition.
Stylish WeWork-like workspace with hot desks and document wall, professional searching through enterprise knowledge base on a mounted ultrawide display, warm industrial pendants overhead.
COHORT DEFINITION

What is Inclusion Criteria?

Inclusion criteria are the specific clinical, demographic, and temporal characteristics that a patient must possess to be eligible for enrollment in a clinical study or cohort definition.

Inclusion criteria define the explicit, machine-executable rules that determine patient eligibility for a clinical study, forming the logical foundation of a computable phenotype. These criteria specify required attributes such as age ranges, diagnosis codes (e.g., SNOMED CT or ICD), laboratory result thresholds (e.g., LOINC codes), medication histories, and temporal sequences of events that must be satisfied for a patient to qualify for a cohort.

In federated clinical analytics, inclusion criteria are decomposed into distributed queries that execute locally at each institution against the OMOP Common Data Model, returning only aggregate counts or masked results. This allows researchers to perform federated cohort discovery across multiple sites while ensuring that individual patient-level data never leaves the local firewall, maintaining strict compliance with HIPAA and institutional Data Use Agreements.

COHORT DEFINITION FUNDAMENTALS

Core Characteristics of Robust Inclusion Criteria

Well-defined inclusion criteria are the bedrock of reproducible clinical research. They transform ambiguous medical questions into precise, computable algorithms that ensure consistent patient selection across distributed sites.

01

Unambiguous Semantic Standards

Criteria must map to controlled terminologies to eliminate the ambiguity of free-text clinical notes.

  • SNOMED CT for diagnoses and procedures
  • LOINC for laboratory tests and vital signs
  • RxNorm for medication orders
  • ICD-10-CM for billing and administrative codes Using these standards ensures that a 'type 2 diabetic' is identified identically across different EHR systems.
02

Temporal Constraints

A robust criterion specifies not just what happened, but when. This defines the index date and lookback windows.

  • Incident vs. Prevalent: First-ever diagnosis vs. any history of the condition
  • Lookback Period: e.g., 'No HbA1c > 6.5% in the 365 days prior to enrollment'
  • Temporal Logic: 'Procedure A must occur after Diagnosis B but before Medication C' Without temporal anchors, cohorts mix new cases with long-standing chronic patients.
03

Computable Phenotype Logic

Inclusion criteria must be translated into a computable phenotype—a machine-executable algorithm combining multiple data types.

  • Rule-Based Logic: Boolean operators (AND, OR, NOT) linking structured codes
  • Value-Based Thresholds: Laboratory results (e.g., 'eGFR < 60 mL/min')
  • Composite Scores: Calculated indices like BMI or Charlson Comorbidity Index This logic allows a distributed query engine to execute the exact same cohort definition across OMOP-mapped databases.
04

Demographic and Anthropometric Boundaries

Explicitly defining the population scope prevents confounding and ensures generalizability.

  • Age Ranges: '≥ 18 years at index date'
  • Sex/Gender: Aligning with study design and biological hypotheses
  • Geographic Constraints: Limiting to specific sites or regions
  • Vital Signs: Weight, height, or blood pressure ranges These boundaries are critical for matching cohorts to the target product label or research question.
05

Data Availability Requirements

A patient must have sufficient observational data to be evaluated. This prevents immortal time bias.

  • Minimum Observation Period: e.g., '≥ 365 days of continuous enrollment prior to index'
  • Data Completeness: Requiring at least one recorded visit or lab result in a window
  • Site Capability: Ensuring the institution records the specific data types needed (e.g., structured pathology reports) This ensures the absence of a criterion is a true negative, not missing data.
06

Exclusion as a Precision Tool

Exclusion criteria are the inverse of inclusion—they refine the cohort by removing confounders.

  • Contraindications: Removing patients with conditions that make the exposure unsafe
  • Competing Risks: Excluding patients with conditions that prevent the outcome (e.g., bilateral amputation prevents a foot ulcer outcome)
  • Data Quality Exclusions: Removing patients with implausible values (e.g., negative age) A clean cohort is defined as much by who is left out as who is let in.
CLINICAL COHORT DEFINITION

Frequently Asked Questions

Precise answers to common questions about defining and applying inclusion criteria in federated clinical research, focusing on privacy-preserving cohort discovery across distributed healthcare datasets.

Inclusion criteria are the specific clinical, demographic, and temporal characteristics that a patient must possess to be eligible for enrollment in a clinical study or cohort definition. These criteria operationalize the research question by defining the target population with precision. Common dimensions include age ranges, diagnosis codes (e.g., SNOMED CT or ICD-10), laboratory result thresholds, medication histories, and procedure codes. In traditional single-site studies, inclusion criteria are applied directly against a local data warehouse. In federated environments, these criteria are translated into a computable phenotype—a machine-executable algorithm that can be distributed to multiple institutions, executed locally against each site's OMOP Common Data Model or native schema, and aggregated without exposing patient-level data. Well-defined inclusion criteria balance specificity (excluding ineligible patients) with sensitivity (capturing all relevant cases), directly impacting the statistical power and generalizability of the resulting Real-World Evidence.

COHORT DEFINITION FRAMEWORKS

Inclusion Criteria vs. Related Cohort Definition Concepts

A comparison of the distinct roles that inclusion criteria, exclusion criteria, computable phenotypes, and query federation play in defining and identifying patient populations for clinical research.

FeatureInclusion CriteriaExclusion CriteriaComputable PhenotypeQuery Federation

Primary Function

Defines required attributes for study eligibility

Defines disqualifying attributes despite eligibility

Machine-executable algorithm to identify a cohort from EHR data

Distributed query technique to count patients across sites

Operational Context

Clinical trial protocol design

Clinical trial protocol design

Observational research and EHR data extraction

Privacy-preserving multi-site feasibility counts

Data Movement

Not applicable (design phase)

Not applicable (design phase)

Executed on centralized or local data warehouse

Query sent to data; only aggregate counts returned

Patient-Level Data Exposure

No data involved

No data involved

Yes, operates on identified or de-identified records

No, patient-level data never leaves the source institution

Standardization Requirement

Free-text protocol language

Free-text protocol language

Requires OMOP CDM, SNOMED CT, LOINC mapping

Requires common data model and distributed query engine

Primary Output

Eligible participant pool definition

Safety and confounding risk mitigation

Binary classification of patient membership in a cohort

Aggregate patient counts per site with zero data leakage

Temporal Component

May specify time windows for condition onset

May specify washout periods or recent exclusions

Encodes temporal logic via sequence of codes and visits

Executes temporal criteria locally at each node

Relationship to OHDSI/OMOP

Conceptual input to phenotype design

Conceptual input to phenotype design

Implemented as OHDSI cohort definition JSON

Executed via OHDSI ATLAS or similar distributed tools

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.