Start Your CLIF Project

Before you build, sharpen your research question and confirm it's feasible across CLIF sites — every site is different. Each site's CLIF data is governed by its own IRB cohort inclusion criteria, so the population it covers varies. Map your question to that reality:

• Does your cohort exist at every site? Inclusion ranges from admissions with an ICU stay to all acute care (every inpatient and ED encounter); some sites use a physiology/registry trigger (ICU/IMC, supplemental oxygen, SBP < 90, or vasoactives). A question that begins in the ED or on the wards only runs at sites that capture those encounters.
• Do you need to rebuild full hospitalizations? Multi-encounter questions — like the consortium's ten-health-system ICU readmissions study — need encounter stitching to link ED, ward, and ICU encounters into one stay (clifpy does this with configurable time windows). A single-ICU-stay question (e.g., the prone positioning or SAT/SBT studies) usually doesn't.
• Mind the data window. Available years and ED/ward coverage differ by site, so the same cohort can shrink — or shift — depending on where it runs.

CLIF members can review every site's exact cohort inclusion criteria, data sources, and date ranges on the portal before committing.

Helpful starting points: clifpy (load tables, stitch encounters, check data quality), the federated proof-of-concept case studies, and an example project, CLIF-eligibility-for-mobilization.

Start from the template. Click "Use this template" on the CLIF Project Template, or:

gh repo create my-clif-project \
  --template Common-Longitudinal-ICU-data-Format/CLIF-Project-Template --private

You get a ready structure:

my-clif-project/
├── README.md                     # the run-it-yourself guide each site reads
├── config/config_template.json   # site settings (copy to config.json)
├── code/templates/{Python,R}/    # numbered pipeline scripts
├── output/
│   ├── final_no_phi/             # aggregate, shareable results
│   └── intermediate_phi/         # patient-level working data, NEVER shared (gitignored)
├── utils/                        # config loaders for Python & R
└── guides/                       # creator guide, primer, buddy-testing guide

Full walkthrough: Creator Guide.

Reach out on #general on CLIF Slack to find a buddy site. Before consortium release, one other site clones the finished repo and runs it end to end on their own data, catching site-specific assumptions, setup gaps, and any data-security issues. They record the outcome in the Buddy Test Report. See the Buddy Testing Guide for what gets checked.

After buddy testing and before consortium release, the project shares a preliminary methods and aggregated results report so the consortium can review the approach up front and minimize rerun requests. At a minimum it should include:

1. Methods summary
2. Results summary
3. Aggregated Table 1
4. Two primary figures intended for release or publication

Once buddy testing passes, the PI releases the project for the consortium run. Release the project on the #run_requests channel on Slack. Each site clones it, points config.json at their data, runs it, and returns the contents of output/final_no_phi/: aggregate results only, never patient-level data.