Care and Feeding of Your Biostats Team

Scaling Best Practices in a Large Hybrid SAS/R Team

John Ehrlinger, PhD

Cleveland Clinic,
Heart, Vascular & Thoracic Institute,
Cardiovascular Outcome Registries and Research

April 27, 2026

Cardiovascular Outcome Registries and Research (CORR)

1997 CORR

SAS shop
Goal: any analyst can pick up any job
Folder structure with file naming conventions
A social contract — loosely enforced

Today

R and SAS hybrid
Team grows to 19 (and more)
Conventions extended to R

We built methods in-house. Now we maintain them too.

Discipline doesn’t scale under production pressure

I work in Cardiovascular Outcomes Registries and Research, we’re part of the Heart, Vascular and Thoracic Institute at the Cleveland Clinic. CORR was started in 1997 with the arrival of our director, Dr. Eugene Blackstone. We started as a pure SAS shop, with a small team. A guiding principle of CORR from day one has been the ability to hand off any study easily. These handoffs require a “social contract of practices”, that are held together by discipline within the team.

Our primary in house methods started with PROC hazard, a C program with tight SAS bindings. Over time, R entered by methodology evolution. Dr. Hemant Ishwaran developed randomForestSRC in R at CORR in 2007, random forest for survival, regression and classification. I wrote the ggRandomForests package to simplify plotting these forest outputs using ggplot.

As we’ve grown, we’ve found that discipline alone doesn’t scale easily.

CORR Production Scale

CORR Assembly Line

What a Biostatistician Delivers

Study Researcher	Analysis Report CORR	Manuscript Researcher
Research questions	Data ingestion	Introduction
Statistical approaches	Model building	Methods
Communication	Figures & Tables	Results
		Discussion

“Bus insurance” — any analyst can pick up any job.

Reproducibility at scale — Three Focus Areas

Data ingestion
Model building
Figures and tables

Make the safe path the easy path.

There are three areas where reproducibility breaks down in practice. We’ll address each of these areas with: here’s the failure mode, here’s what we’re doing about it.

Make the safe path the easy path. We currently do a lot of mental work to compensate for gaps in each of these areas — remembering which dataset is current, keeping track of which version of a function ran, manually assembling figures into a report. The goal isn’t to add process on top of that — it’s to replace that mental overhead with automation. Using checksums instead of memory. Package versions instead of tribal knowledge. Quarto instead of copy-paste.

Long term, the vision is an audit process that runs automatically — not a checklist someone fills out, but a system that tells you whether the analysis is reproducible before you have to ask. We’re not there yet, but every piece we put in place moves us closer.

Data Ingestion

Make the safe path the easy path.

Problem: Data file tracking

Jan 12

cohort.sas7bdat

Initial extract from Data Warehouse

Feb 3, 2:22 PM

cohort_final.sas7bdat

Exclusions applied — but which ones?

Feb 3, 4:47 PM

cohort_final2.sas7bdat

Researcher comments — additional exclusion added

Mar 15

cohort_final_USE_THIS.sas7bdat

PI changed date range — modified date reset on server sync

Apr 2 — today

cohort_final_USE_THIS_v2.sas7bdat

What changed? Nobody remembers.

Is this the right data? Has it changed?

How we’re addressing it In development

Layer governance on top of existing structure.

What we have

study_root/
  analyses/      ← jobs
  datasets/      ← *this problem*
  descriptive/
  distributions/
  documents/     ← deliverables
  estimates/     ← cached results
  graphs/        ← pdf

What we’re adding

Date in the filename
never overwrite
Dataset manifest
source, date, parameters
Checksum
detect silent changes
Audit trail
job ↔︎ manifest

Manifest + checksum in practice In development

datasets/built260430.manifest.yml

dataset:      built260430.sas7bdat
source:       Cardiopulse / STS registry v2.1
pulled_by:    data_manager
pull_date:    2026-04-30
sha256:       a3f8c2d1e4b7f093...
observations: 12847
variables:    428

Register explicitly — separate from build

digest::digest(
  "datasets/built260430.sas7bdat",
  algo = "sha256", file = TRUE)

Verify before analysis

stored  <- yaml::read_yaml(
  "datasets/built260430.manifest.yml")$sha256
current <- digest::digest(
  "datasets/built260430.sas7bdat",
  algo = "sha256", file = TRUE)
stopifnot(current == stored)

Filename says when. Checksum says whether.

Rebuild without re-registering → every downstream job fails.
That failure is the feature.

Model Building

Make the safe path the easy path.

Problem: R and SAS Environments

SAS

SAS version not locked to a study
Shared Macro library unversioned
Shared server

R & RStudio

R version is not locked to a study
Shared Package library — package versions drift
Shared server
Serialized models in estimates/ fail to load
Results don’t match — or the job won’t run

Can you reproduce this analysis six months from now?

R: `renv` with RStudio projects In flight

Without renv

Packages installed globally — shared across all projects

update.packages() breaks other analyses silently

Serialized models in estimates/ fail to load 6 months later

“Works on my machine” — but not yours

New analyst hunts down exact versions to reproduce results

→

With renv

Day 1 — any analyst, any machine

Isolate the project library and freeze it

renv::init() # isolate library
renv::install("ehrlinger/hvtiPlotR")
renv::snapshot() # freeze versions

renv.lock — R 4.4.1 · hvtiPlotR 0.3.2 · …
commit this; it travels with the project

6 months later — different analyst, different machine

Open .Rproj, run one command

renv::restore() # rebuilds library from renv.lock

Same packages. Same results. The job belongs to the team.

Problem: Shared function libraries aren’t versioned

SAS macro library

Centralized — everyone calls the same macros
Not versioned — no record of which version ran
Changes propagate silently

R functions

Copied at study creation — diverges immediately
Fixes stay local; no propagation
In-flight studies never get updates

SAS: did that update break something? R: did anyone else get that fix?

Versioned internal packages In development

An R package is a versioned, distributable library.

Functions in the study folder

Frozen at copy
Fixes don’t propagate
No version record

Code in a package

One canonical version
Pull fixes deliberately with renv::update()
Examples travel with code, double as tests

The hard problems shift — they don’t disappear.

Someone must own releases.
Improvements must be communicated — they don’t propagate automatically.
Studies must change versions deliberately — controlled, not automatic.

Problem: Code and results live separately

SAS — partially solved this

.lst pairs code and output
Figures still separate files

R scripts — no equivalent

Code and output in separate files
No standard structure
Figures disconnected from code

Can a new analyst navigate this job without asking whoever wrote it?

Quarto templates In development

report.qmd = job.sas

Code and output in one document
Figures inline
Renders to HTML, PDF, Word

Always render before committing.

Standard 4-section template

# Data.qmd
Ingestion, exclusions, cohort description

# Methods.qmd
Model specification and assumptions

# Explainability.qmd
Diagnostics, sensitivity checks

# Results.qmd
Tables, figures, interpretation

The structure is the contract.

Quarto is analogous to the sas job and lst files. A single unified report that includes R code and the output. The report has the advantage of including real figures inline. And renders to a deliverable report, in html, pdf or even word.

The pitch to SAS analysts isn’t just “learn this new tool” (I tried that) — it’s “get what you already have in .lst, but with real figures inline and a structure everyone agrees on.”

We’re working on a 4-section template structure as the standard: Short enough chunks to be understandable, consistent enough to navigate, flexible enough to cover every study type. We hava data ingestion report that passes clean data to the methods for model building. The model is then passed to explainability and results for communicating with researchers. Longer term, we’re designing a bookdown approach to possibly replace the manually assembled Analysis Report deliverable.

We still have an underlying copy/paste problem — both SAS jobs and R scripts are copied from a central templates folder, meaning in-flight studies don’t implicitly get updates. Quarto and R packages are the foundation we’re building first before tackling that propagation problem.

Figures and Tables

Make the safe path the easy path.

Problem: Publication-quality graphics

SAS: plot.sas

Hard-won publication quality
Each output target: more manual effort

R: ggplot2

Same per-target effort problem
No shared themes or palettes

Can we capture that effort once — make figures consistent?

R: graphics pipeline In flight

The package does the hard work. The analyst decorates.

Package owns

The statistical transform
The base figure — correct by construction
Themes: manuscript, PowerPoint, poster

Analyst owns

Axis labels, annotations
Nothing else needs to change

# Package handles the figure
fig <- plot(corr_analysis(data))

# Analyst decorates to context
fig +
  hv_theme("manuscript") +
  scale_color_brewer(palette = "Set1") +
  annotate("text", ...)

If it looks like the package example, it’s correct.

Our visualization packages In flight

ggRandomForests — github.com/ehrlinger/ggRandomForests

Variable importance, partial depth, minimal depth — ggplot2 for randomForestSRC.

hvtiPlotR — github.com/ehrlinger/hvtiPlotR

Survival curves, hazard plots, forest plots in CORR themes.

Bridges ggplot2 to plot.sas standards.

As the science keeps moving and CORR evolves, so do the packages.

Survival curves — `ggRandomForests`

Survival difference between two treatment groups (blue, red)
randomForestSRC fits a survival forest; ggRandomForests plots the results.

Problem: Publication-quality Tables

Right now, this is all SAS.

gt and gtsummary exist — they aren’t tamed to our standards yet.

That’s next.

Honestly

	Status
Data Ingestion
Study folder structure	Adopted — standard
Dataset naming + manifests + checksums	In development
Model Building
RStudio Projects + `renv`	In flight — “easy” win
Quarto templates	In development
`hazard` (SAS), `randomForestSRC` (R) `TemporalHazard` (R)	Adopted In development
Figures & Tables
`ggRandomForests`, `hvtiPlotR`	In flight
`hvtiRtables`	Aspirational — coming “soon”

The framing shift that mattered

“Reproducibility” → “Production reliability”

“Any biostatistician can pick up any job.”

To wrap up, I’ve been working on these pain points in CORR for a long time. The Reproducibility framing failed — it reads as an academic virtue, something you do for reviewers when asked. The Production reliability framing lands differently with the team: it’s about whether someone else can pick up your job on a Monday morning when you’re out sick. Same tools, same practices — but the reason to adopt them shifts from “good science hygiene” to “your teammates won’t be stranded.” The second framing can help with buy-in.

Make the safe path the easy path means the standards have to be lower-friction than the workaround, or people will always take the workaround. Being transparent, it still takes work for people to change their ways — even if the path is “hypothetically easier”, roll out is still a learning experience and being done under production pressure.

Make the safe path the easy path.

Resources

https://github.com/ehrlinger

Package
`hazard` (SAS)	github.com/ehrlinger/hazard
`TemporalHazard`	github.com/ehrlinger/temporal_hazard
`randomForestSRC`	cran.r-project.org/package=randomForestSRC
`ggRandomForests`	github.com/ehrlinger/ggRandomForests
`hvtiPlotR`	github.com/ehrlinger/hvtiPlotR
`hvtiRutilities`	github.com/ehrlinger/hvtiRutilities

These slides: github.com/ehrlinger/CareFeedingBiostats

Contact: ehrlinj@ccf.org

We’re hiring a biostatistician — Contact me!

Care and Feeding of Your Biostats Team

Cardiovascular Outcome Registries and Research (CORR)

1997 CORR

Today

CORR Production Scale

CORR Assembly Line

What a Biostatistician Delivers

Reproducibility at scale — Three Focus Areas

Data Ingestion

Problem: Data file tracking

How we’re addressing it In development

What we have

What we’re adding

Manifest + checksum in practice In development

Model Building

Problem: R and SAS Environments

R: renv with RStudio projects In flight

Problem: Shared function libraries aren’t versioned

Versioned internal packages In development

Problem: Code and results live separately

Quarto templates In development

Figures and Tables

Problem: Publication-quality graphics

R: graphics pipeline In flight

Our visualization packages In flight

Survival curves — ggRandomForests

Problem: Publication-quality Tables

Honestly

The framing shift that mattered

Resources

R: `renv` with RStudio projects In flight

Survival curves — `ggRandomForests`