4,725 computable clinical concepts by data category.
0
ICU stays
CORR-ICU
0
surgical procedures
CORR-OR
0
computable clinical concepts
consensus-defined, clinician-validated
~0
ICUs, IMCs and PACUs
350+ beds, 3 sites
Data cut: June 2026. Routine data since 2001 (COPRA) and 2006 (hospital information system); Philips monitoring at up to 500 Hz since 2025.
Why a raw EHR value is not a clinical concept
Take the PF-ratio, one of the most common variables in ICU research. Some blood-gas analyzers calculates a PF-ratio for every arterial sample, assuming an FiO₂ of 21% unless someone types in the real value. Clinicians do not use this stored value for patient care, but anyone who pulls this data for research gets values that are systematically inflated. CORR identified this error and created a consensus-based, clinically-curated concept. It was defined and validated once. Now, every CORR project can use it, without re-coding and inconsistencies across projects.
Try it: one blood gas, two answers
Move the sliders. The EHR ratio ignores the FiO₂ actually delivered.
Stored in EHR FiO₂ assumed 21%
381
No ARDS band
CORR concept pf_ratio matched FiO₂
133
Moderate band
Berlin bands are shown for illustration only; formal ARDS classification also requires PEEP, timing and radiographic criteria.
Calibration density, EHR-stored versus CORR-derived PF-ratio. Each diagonal band is one FiO₂ setting that the EHR silently replaced with 21%.
How the repository is structured
Two repositories share one concept layer. CORR-ICU is keyed by ICU stay, CORR-OR by surgical procedure, and both roll up to hospital case and patient. Because the identifiers link, a patient can be followed from the operating room to the ICU to the ward.
Observation levels
Click a level to see what it contains. One patient, two hospital cases, five ICU stays and five procedures, as in the manuscript's Figure 1B.
patient_id
The person. Every CORR concept can be extracted at this level, or segmented into the levels below.
patient_id
One person, stable across all admissions.
c_falnr
One hospital case, from admission to discharge.
icu_stay_id
One continuous ICU stay; the default unit of CORR-ICU.
procedure_id
One surgical procedure; the default unit of CORR-OR.
Sample size and overlap
Counted in hospital stays. Procedures and ICU stays overlap where surgery precedes or follows intensive care, which makes perioperative-to-ICU studies possible without record linkage.
CORR-OR
544,227 procedures
across 455,415 hospital stays, about 50,000 per year in 60+ operating rooms
CORR-ICU
255,878 ICU stays
across 231,605 hospital stays, about 27,000 per year in ~30 units
reprodICU: public ICU data, harmonized
reprodICU is part of CORR and harmonizes seven public ICU databases into one analysis-ready dataset, so studies built on CORR can be replicated on open data.
A computable clinical concept (CCC) is a consensus-defined, clinician-validated, version-controlled and machine-executable specification. Each is a dedicated extraction and transformation pipeline, documented with provenance, derivation logic, validation status and known caveats, and mapped to OMOP, SNOMED CT and ATC.
Composition by category
Number of concepts, log scale. Hover a bar.
Interoperability coverage
Share of concepts per category with a mapping to each standard. Overall: OMOP 99%, SNOMED CT 19%, ATC 78% of medications.
Four kinds of concept
Concepts are raw or derived, and static or dynamic. Static concepts come as one row per case (wide format); dynamic concepts as many rows per case over time (long format).
Raw, static
icu_admission_time
One value read directly from the record per observation level.
Raw, dynamic
paO₂, FiO₂
Each blood-gas or ventilator reading, with its timestamp.
Derived, static
first_pf_ratio
One computed value per case, e.g. the first PF-ratio after admission.
Derived, dynamic
pf_ratio
paO₂ divided by the temporally matched FiO₂, per measurement.
The Concepts Browser documents every concept: definition, derivation code, version history, clinical documentation and known caveats. Pick a concept, or follow a Requires link.
From study idea to analysis-ready cohort
The CORR package borrows the logic of an electronic case report form. A study variable is a concept, a time anchor, an observation window, a cleaning rule and an aggregation method. Scroll through one real example: the median PF-ratio in the first 24 hours after intubation.
Start from a validated concept
The study variable is built on the CCC pf_ratio, not on raw blood-gas rows. All matching of paO₂ to FiO₂ has already happened inside the concept.
Anchor it in time
Time anchors are themselves concepts. Here the window opens at first intubation and closes 24 hours later. time0, end of follow-up or any event can serve as anchor.
Declare the cleaning rule
Plausibility limits are explicit and versioned with the study, so a reviewer can see exactly which values were dropped.
Choose the aggregation
Median over the window. First, last, min, max, count or slope are equally one keyword. The result is one column in a wide, analysis-ready cohort table.
study_variables.pyCORR-Vars
1cohort.add_variable(
2NativeStatic(
3base_var="pf_ratio", # CORR CCC4tmin=("first_intubation", 0), # time anchor (lower)5tmax=("first_intubation", "24h"), # time anchor (upper)6where="10 <= value <= 1000", # data cleaning7select="median", # aggregation method8var_name="median_pf_ratio", # output name9 )
10)
The same derivation is available without code through the graphical cohort builder; reproducible code is generated in the backend.
One concept layer, three kinds of use
Retrospective studies, prospective trials and bedside applications all read the same validated ground truth. Nothing is recoded between them.
Retrospective: focus on methods, not wrangling
Target trial emulations and cohort studies start from validated concepts and an eCRF-style specification. Investigators spend their time on design and interpretation. More than 40 clinical projects currently run on CORR.
Prospective: the Sweet-Water trial
A pragmatic, embedded, stepped-wedge cluster-randomized trial across 6 hospitals and 11 ICU clusters, 6 of them at Charité. All Charité data came through CORR using 29 validated concepts, without case report forms or trial-specific extraction code. The analysis dataset took days rather than months.
Bedside: an extubation dashboard on the live feed
Among patients intubated in the ICU, the dashboard tracks primary extubation, re-intubation and related outcomes over time. All metrics are existing concepts and update automatically through the continuous data stream.
Airway outcomes of intubation episodes over one quarter.
How we validate concepts
Every concept passes the same eight stages before it can be used in a study, and stays under surveillance afterwards. A weekly cohort per ICU re-executes all concepts and archives their distributions, so drift in bedside documentation surfaces within days.
Define
From a project need to an agreed definition and harmonized sources.
01
Need-based identification
A concept is requested by an ongoing or planned project.
02
Consensus definition
The multidisciplinary team agrees the definition iteratively, informed by local documentation practice, in regular data-quality meetings.
03
Source exploration
All candidate EHR sources are screened for presence of entries, granularity, temporal distribution and data quality.
04
Source selection and harmonization
Sources are selected and aligned across systems for units, value ranges and documentation conventions.
Build and validate
From pipeline to specialist sign-off, then weekly surveillance.
05
ETL pipeline implementation
A single pipeline encapsulates all cleaning and transformation logic; definitions are versioned in Git.
06
Quantitative and qualitative validation
Plausibility checks against reference ranges, then chart review against original clinical records.
07
Specialist review
Intensivist (CORR-ICU) or anesthesiologist (CORR-OR) review; approval or refinement, residual issues recorded as known caveats.
08
Continuous quality surveillance
Weekly surveillance cohorts per ICU detect ingestion failures, structural changes and shifts in bedside documentation.
Build on it
Patient-level data stay at Charité for regulatory reasons. The package, the concept standard and the documentation are open, and collaboration proposals such as external validations are welcome at any time.