Health data as national infrastructure

Cathie Sudlow’s opening keynote, Future of Population Health Research: a UK Health Data Perspective, described how the UK linked national health datasets and built secure data environments covering the whole population of England. Her underlying message: health data is any data relevant to our health, and it should be treated as shared national infrastructure with common sharing principles, not as a pile of separate project datasets.

I kept translating this to Morocco. Our data is fragmented across hospitals, national programmes and research teams, with no common layer connecting them. A Moroccan initiative in the spirit of Health Data Research UK, would be a major opportunity: researchers contributing data under shared principles, a common access framework, and eventually an agent layer that lets people query that data in natural language. None of this works without well-curated data, which is a practical problem I want to help solve.

My poster: interpretability as an estimand

I presented A Framework for Assessing Imputation Methods for Survival Prediction Models via Interpretability Distortion (with Roch Giorgi). The starting point: when a model is used to understand the outcome-covariate relationship, its interpretability summaries (partial dependence, time-dependent SHAP, permutation importance, calibration and Brier curves) are quantities we estimate, so they should be treated as estimands. That makes it possible to measure how much imputation distorts them relative to a complete-data reference, for machine learning models and not only for regression coefficients. In our benchmark, some methods preserved variable rankings while altering effect sizes: good prediction did not guarantee a stable interpretation.

The rest of this post covers the talks that stayed with me.

Are hazard ratios really hazardous?

Hernán’s 2010 commentary The hazards of hazard ratios argued that Cox hazard ratios carry a built-in selection bias: a hazard ratio that declines over follow-up may only reflect latent frailty, not a waning treatment effect. Many people have been uneasy about Cox regression since.

In the STRATOS symposium, Michal Abrahamowicz (How important are the Hazards of Hazard Ratios?) revisited the argument with extensive simulations. The selection bias turns out to be modest unless unmeasured frailty has a very strong effect. In simulations mimicking the trial Hernán discussed, an unmeasured risk factor alone could practically not reproduce the observed decline in the hazard ratio. Declining adherence and biological changes under prolonged treatment are more plausible explanations. Their conclusion: the concern is largely overstated.

This matters for anyone working on time-varying effects, as I do. A time-varying hazard ratio is often a real signal worth modelling, not an artefact to explain away. It also made me want to look again at alternatives to the classical proportional hazards test, and at reporting several models rather than one.

What are p-values good for?

In the same session, James Carpenter (P-values and hypothesis testing: beyond polemics to practical solutions) moved past the debate that has run since the 2019 Nature call to retire statistical significance. P-values are often used to justify a result rather than answer a question, and on their own they are not reproducible. As an attendee pointed out, neither are confidence intervals. The useful part was organising good practice around the goal of the analysis (description, prediction or causal explanation), supported by registration, initial data analysis and transparent reporting.

The point I liked most: in model building, a p-value can be a legitimate tuning parameter, for example as a selection threshold. Used that way it is a knob in an algorithm, not a claim about truth, and I think that distinction deserves more attention.

How much nonlinearity should a model be allowed?

My favourite methods talk was Tom Splittgerber’s LiD-GLM: Lipschitz-constrained Deep Generalized Linear Models (with Marvin N. Wright, Niklas Koenen and Werner Brannath). The model passes covariates through an invertible residual neural network before a GLM, and hard-constrains the network’s Lipschitz constant. That constant becomes an explicit dial between “this is just the GLM” and “this is a free neural network”. The model is initialised from a fitted GLM, so if nonlinearity adds nothing, you simply get the GLM back. In the summary slide’s words, the Lipschitz constant quantifies the compromise between expressiveness and interpretability, and tells you whether your problem needs complex ML at all.

In the same spirit, Ester Rosa’s poster on Interpretable Kolmogorov-Arnold Networks via Penalized Splines for Clinical Prediction Modeling showed KANs entering clinical prediction. KANs with spline edges sit naturally between additive models and neural networks, which is the space I am working in now for survival analysis.

Can explanations inherit bias?

A thread that ran through several sessions: SHAP values explain the model, not the data-generating process, so they can carry over confounding. When predictors are correlated or causally ordered, standard Shapley attributions can mislead. Asymmetric Shapley values, which respect a causal ordering (for example genetics before clinical variables), are one principled answer.

It left me thinking about variable importance for meaningful groups of variables (genomic, clinical, epidemiological) rather than single features.

Do our metrics behave badly?

Three talks fit together well. In the fairness session, Gary Collins (A Fractured Landscape: Evaluating Fairness in Clinical Prediction Models) pointed out that the c-statistic and calibration slope are non-collapsible, so an apparent subgroup “unfairness” can simply reflect case mix. Junfeng Wang showed that population-level net benefit can favour adopting a model even when overall utility does not improve. At STRATOS, Ben Van Calster scored 32 performance measures on properness and focus: only 17 pass both, and F1 fails both. His minimal reporting set is AUROC, a calibration plot, net benefit with a decision curve, and the distribution of predicted risks.

My takeaway: we spend a lot of effort building models and much less checking whether our metrics measure what we think. Fairness at the level of the individual, not only of groups, seems underexplored.

Causal inference for survival outcomes

Causal survival analysis still has real gaps. Two talks (at least was I was able to attend) approached them from very different angles: Yuan Liu’s two-step approach for survival outcomes under time-varying latent confounding, and Xinyuan Song’s conditional GANs for individualized causal mediation with survival outcomes. Both made me think about estimands. Hazard contrasts are hard to read causally, whereas restricted mean survival time is collapsible and easy to explain to clinicians. I would like to explore more causal survival work built on that kind of estimand, combined with flexible machine learning.

Other things I noted

• Sample size for ML. The pmsims R package (Olaniran, Carr and colleagues) estimates sample size by simulation with an assurance criterion: hitting target performance with high probability, not only on average. A natural framework to extend to survival models.
• Conformal prediction is not calibration. Giulia Zamagni showed that models with very different calibration can give similar conformal coverage and interval widths. Report both.
• Calibration with censoring. David van Klaveren’s LOESS for censored data gives calibration curves that hold up when censoring depends on predicted risk.
• Missing data in bioequivalence. Jakob Winkler simulated how missing PK sampling times affect AUC, Cmax and bioequivalence conclusions in 2x2 crossover trials: a small, concrete and important problem.
• Spline choices. My recurring question in spline talks: were the degrees of freedom and knot placement tuned? They shape the curve as much as the method does.
• Statistical analysis plans. Marianne Huebner’s SAPI checklist made me wonder why ML projects almost never have a statistical analysis plan?

Two impressions

Some of my best discussions happened at posters, and several deserved an oral slot, perhaps more than a few talks that felt less prepared. One example: Kerstin Rubarth and colleagues (FeMaR project) are replacing Germany’s 1986 rule-based pregnancy risk system with models trained on more than 110,000 pregnancies, with prospective validation under way. Very relevant to maternal health work in Morocco and great collaboration opportunity.

Talks on agentic AI, and agentic data science in particular, felt classic, even dated. The field moves faster than a submission cycle, and presenters likely stuck to abstracts written months earlier. Having built agentic data science tools myself, I expected the questions that matter now: how to evaluate an agent’s analysis against a known truth, how to keep every step reproducible and auditable, and how to control false positives when an agent iterates over analyses until something looks good. That last one is a classic multiplicity problem, and statisticians are well placed to solve it.

Coming home

I came for survival methods and machine learning, and I got plenty of both. What I kept thinking about on the train back to Frankfurt, though, was Sudlow’s keynote: good methods need data that exists, is connected, and can be trusted. Building that in Morocco is the part I most want to work on next.

Thanks to the organisers for this great management, in particular conference presidents Nadine Binder and Harald Binder, and to the ISCB and GMDS teams for an excellent week in Freiburg.

Talks mentioned

basetable

basetable is a fast in-memory data-manipulation package for R with a base-R interface and no dependencies. You write subset(), transform(), aggregate(), merge(), split(), and the work runs on the package’s own C++ engine. There is no data.table, no dplyr, no Arrow underneath, and nothing in Imports beyond the base and recommended packages (parallel, stats, utils).

Every verb returns a basetable: an ordinary data.frame with one extra class so it prints compactly and [ keeps the class. as.data.frame() strips it back to a plain frame.

This is a deliberately focused tool. It is aimed at

• people teaching or learning base R who want speed without the cognitive load of tidy evaluation or [i, j, by], and
• codebases already built on subset() / merge() / aggregate() that want a faster engine without a rewrite.

install.packages("basetable")

# install.packages("pak")
pak::pak("ielbadisy/basetable")

# nested
basetable::describe(
  basetable::transform(
    basetable::subset(mtcars, cyl == 6, select = c("mpg", "hp", "wt", "cyl")),
    power = hp / wt
  )
)

# basetable: 5 x 14
  column   class n missing missing_prop distinct       mean         sd
1    mpg numeric 7       0            0        6  19.742857  1.4535670
2     hp numeric 7       0            0        4 122.285714 24.2604911
3     wt numeric 7       0            0        6   3.117143  0.3563455
4    cyl numeric 7       0            0        1   6.000000  0.0000000
5  power numeric 7       0            0        6  39.927938 10.8533912
        min       q25    median      q75      max top
1  17.80000  18.65000  19.70000  21.0000  21.4000    
2 105.00000 110.00000 110.00000 123.0000 175.0000    
3   2.62000   2.82250   3.21500   3.4400   3.4600    
4   6.00000   6.00000   6.00000   6.0000   6.0000    
5  30.34682  34.98522  35.75581  40.1228  63.1769    

# pipe
mtcars |>
  basetable::pick(c("mpg", "hp", "wt", "cyl")) |>
  basetable::transform(power = hp / wt) |>
  basetable::aggregate(by = "cyl", value = c("mpg", "power"), fun = mean)

# basetable: 3 x 3
  cyl      mpg    power
1   4 26.66364 37.92533
2   6 19.74286 39.92794
3   8 15.10000 53.85964

# table-1 style summary
basetable::summarytab(
  basetable::transform(mtcars, am = factor(am, labels = c("Automatic", "Manual"))),
  vars = c("mpg", "hp"), by = "am", p_value = TRUE
)

# basetable: 2 x 6
  variable     level    Automatic       Manual      Overall p_value
1      mpg Mean (SD)   17.1 (3.8)   24.4 (6.2)   20.1 (6.0) 0.00137
2       hp Mean (SD) 160.3 (53.9) 126.8 (84.1) 146.7 (68.6)   0.221

basetable::subset(mtcars, cyl == 6 & hp > 100, select = c("mpg", "hp", "wt", "cyl"))

# basetable: 7 x 4
   mpg  hp    wt cyl
1 21.0 110 2.620   6
2 21.0 110 2.875   6
3 21.4 110 3.215   6
4 18.1 105 3.460   6
5 19.2 123 3.440   6
6 17.8 123 3.440   6
7 19.7 175 2.770   6

mtcars |>
  basetable::transform(power = hp / wt, efficient = mpg > mean(mpg))

# basetable: 32 x 13
    mpg cyl  disp  hp drat    wt  qsec vs am gear carb    power efficient
1  21.0   6 160.0 110 3.90 2.620 16.46  0  1    4    4 41.98473      TRUE
2  21.0   6 160.0 110 3.90 2.875 17.02  0  1    4    4 38.26087      TRUE
3  22.8   4 108.0  93 3.85 2.320 18.61  1  1    4    1 40.08621      TRUE
4  21.4   6 258.0 110 3.08 3.215 19.44  1  0    3    1 34.21462      TRUE
5  18.7   8 360.0 175 3.15 3.440 17.02  0  0    3    2 50.87209     FALSE
6  18.1   6 225.0 105 2.76 3.460 20.22  1  0    3    1 30.34682     FALSE
7  14.3   8 360.0 245 3.21 3.570 15.84  0  0    3    4 68.62745     FALSE
8  24.4   4 146.7  62 3.69 3.190 20.00  1  0    4    2 19.43574      TRUE
9  22.8   4 140.8  95 3.92 3.150 22.90  1  0    4    2 30.15873      TRUE
10 19.2   6 167.6 123 3.92 3.440 18.30  1  0    4    4 35.75581     FALSE
# 22 more rows

basetable::aggregate(airquality, by = "Month", value = c("Ozone", "Temp"), fun = mean, na.rm = TRUE)

# basetable: 5 x 3
  Month    Ozone     Temp
1     5 23.61538 65.54839
2     6 29.44444 79.10000
3     7 59.11538 83.90323
4     8 59.96154 83.96774
5     9 31.44828 76.90000

left <- data.frame(id = 1:4, x = letters[1:4])
right <- data.frame(id = c(2, 3, 5), y = LETTERS[2:4])

basetable::merge(left, right, by = "id", all.x = TRUE)

# basetable: 4 x 3
  id x    y
1  1 a <NA>
2  2 b    B
3  3 c    C
4  4 d <NA>

basetable::semimerge(left, right, by = "id")

# basetable: 2 x 2
  id x
1  2 b
2  3 c

basetable::describe(mtcars)

# basetable: 11 x 14
   column   class  n missing missing_prop distinct       mean          sd
1     mpg numeric 32       0            0       25  20.090625   6.0269481
2     cyl numeric 32       0            0        3   6.187500   1.7859216
3    disp numeric 32       0            0       27 230.721875 123.9386938
4      hp numeric 32       0            0       22 146.687500  68.5628685
5    drat numeric 32       0            0       22   3.596563   0.5346787
6      wt numeric 32       0            0       29   3.217250   0.9784574
7    qsec numeric 32       0            0       30  17.848750   1.7869432
8      vs numeric 32       0            0        2   0.437500   0.5040161
9      am numeric 32       0            0        2   0.406250   0.4989909
10   gear numeric 32       0            0        3   3.687500   0.7378041
      min       q25  median    q75     max top
1  10.400  15.42500  19.200  22.80  33.900    
2   4.000   4.00000   6.000   8.00   8.000    
3  71.100 120.82500 196.300 326.00 472.000    
4  52.000  96.50000 123.000 180.00 335.000    
5   2.760   3.08000   3.695   3.92   4.930    
6   1.513   2.58125   3.325   3.61   5.424    
7  14.500  16.89250  17.710  18.90  22.900    
8   0.000   0.00000   0.000   1.00   1.000    
9   0.000   0.00000   0.000   1.00   1.000    
10  3.000   3.00000   4.000   4.00   5.000    
# 1 more rows

The claim

A library has two audiences now. There’s the person who reads today’s documentation and writes code against the current version - that’s the old audience, still there. And then there’s every language model trained on the public record of how your library has been used across all its past versions, which is new and honestly enormous. That second audience doesn’t read your changelog. It has no way to tell a current idiom from one you retired four years ago. It just reproduces whatever pattern showed up most in its training data, and it does that with total confidence, no version awareness at all.

If your API hasn’t changed much, both audiences land on the same answer. If it has churned, the model turns into something that hands out code that no longer runs - or, worse, code that runs but doesn’t mean what it used to.

Interface stability used to be about usability. Now it’s closer to a correctness guarantee, because a lot of the code written against your library is going to be generated by something whose knowledge is an average over your whole history, not a snapshot of where you are today.

What actually changed

A few things happened around the same time.

People stopped searching and started generating. A few years ago, if you got stuck on an API you searched, skimmed a few results, checked the dates, and adjusted. That reconciliation happened in your head. Now people ask a model and paste what it gives them, and the model isn’t doing that reconciliation for you.

The training data skews old. The public writing about any library that’s been around a while is weighted toward its early, most-discussed years - every retired function, every old argument, every outdated convention, still indexed, still upvoted, still sitting in a tutorial nobody updated. More documentation doesn’t fix an unstable API. It just preserves every past state of it as competing advice with no dates attached.

And confidence doesn’t track how current something is. A stale forum post at least has a timestamp. A model’s answer doesn’t. It’ll hand you a deprecated idiom as fluently as a current one, and you won’t know anything’s wrong until it breaks - or, if the behavior just quietly changed instead of breaking outright, maybe you never find out at all.

Put together: the older and more heavily documented a moving API is, the more likely a model is to hand a newcomer something subtly wrong. Which runs against the usual instinct that more documentation is always better.

A few rules I try to follow

None of this is new advice. What’s changed is the cost of ignoring it.

Keep the surface small and orthogonal - a handful of verbs that compose (fit, evaluate, tune, cv, compare, interpret, estimate) beats fifty specialized functions. Fewer entry points means fewer things to explain, fewer ways to get it wrong, and less that can drift out from under you. It also means one person can actually hold the whole thing in their head, which is the only way it stays coherent for years.

Own your contracts. Decide for yourself what a fitted object contains, what predict returns, how a factor outcome gets handled, what a probability column looks like. Hand those decisions off to a stack of upstream packages and every design change they make becomes a change in your behavior that you didn’t choose and can’t veto.

Prefer shallow dependencies on stable parts. Calling ranger, glmnet, xgboost, and base stats directly means each dependency is small, single-purpose, and hasn’t moved much in a decade. Building on a large coordinated ecosystem instead means you’ve signed up to track that ecosystem’s lifecycle forever. Both are dependencies - only one of them is an ongoing maintenance bill.

Treat deprecation as a failure, not a feature. A formal deprecation process is honest and a long warning window is considerate, but a deprecation is still an admission that the interface was wrong and that everyone downstream now has work to do. For infrastructure code, the target rate of breaking changes should be close to zero. Depend on something that deprecates on a regular cadence and you’ve inherited that cadence.

Write documentation that ages well - examples that exercise the stable core rather than showing off a new argument, dates on your posts, and if you have to show an old way next to a new way, label them so there’s no ambiguity. Assume a model is going to ingest the page with zero context and reproduce whatever’s on it.

And where you can, make formulas and plain data frames the interface. They’re about the most stable contract R has, and an API built on them inherits that permanence instead of the churn of a bespoke specification object.

A pattern I distrust

The thing I’m most wary of is the wrapper built on a wrapper - a convenience package whose whole pitch is a simple front door, sitting on top of a deep, still-evolving stack of other packages.

I get the appeal. You get breadth fast, you inherit a big community’s testing, and the individual pieces are often genuinely good. But the reliability of the result isn’t something the author of the top layer actually controls - it’s the union of every layer’s failure modes underneath it. A change in low-level evaluation semantics, a reordering of columns somewhere in preprocessing, a shifted default three packages down, and any of it can surface as a wrong answer at the top, with the top-level author only able to wait it out or work around it.

You can see this in the release history of packages like this: lots of releases in a short window, most of them not adding anything new but fixing core behavior that turned out to be wrong, or patching around something upstream that broke. That’s not a package hardening on solid ground. That’s a package discovering its ground keeps moving - which is the opposite of what a long release history is usually taken to mean.

Automated ML wrappers get hit hardest here, since their entire job is to hide the stack. When the hidden stack shifts, users have no way to even notice, and the model they ask for help has been trained on years of the stack’s older shapes. The abstraction meant to protect the newcomer ends up being exactly what stops them from seeing what went wrong.

None of this is against large ecosystems in general - they’re fine for prototyping, fine for learning. It’s against building one underneath a package that’s marketed on durability and then acting surprised when the durability doesn’t show up.

Why I actually care about this

There’s a question underneath all of this about what we think a library even is.

One way to see it: a library is alive. It grows, sheds old parts, follows whatever the current best thinking is, and users are expected to move along with it. Deprecation is just healthy metabolism, and the old code sitting out there in the world is dead weight - not really the project’s problem if a model keeps resurrecting it.

The other way: a published interface is closer to a promise. Once people build on it, its shape stops being entirely yours to change. Base R takes this line - lm, predict, model.matrix have meant the same thing for decades, and that’s exactly what let a whole scientific literature of reproducible code pile up on top of them. The value isn’t in any one function being elegant. It’s that code written against them in 2005 still runs and still means the same thing today.

I hold the second view, and honestly the arrival of models that write code for people has only made me more sure of it. We’re now writing interfaces that will be consumed at scale by something with no sense of time, and everything we ship becomes training data eventually. A stable, modest, self-owned API is a small courtesy to a future where most of the code calling your library was written by something that learned it from your past, not your present.

Wanting to build something that lasts, with few parts and visible joints, has always been partly an aesthetic preference. Now it also happens to be the practical one. If the main reader of your code is going to be a model averaging over your history, the best thing you can do is not give it much history to average over.

What worked

Combining complementary evidence turned out to help with detecting treatment effect heterogeneity in the first place. I used three signals here - the GRF calibration test, an interaction test between treatment and the estimated subgroup, and a comparison of treatment effects between the subgroup and its complement - and decided by majority vote. That left me more convinced that HTE detection shouldn’t lean on a single diagnostic.

The consensus framework also did a reasonable job estimating how large the treatment-responsive subgroup was overall, even in cases where individual patient assignments were shaky. Ensemble methods seem to recover the population-level structure before they recover the individual-level labels.

What I would change

A few things didn’t hold up as well, and I’d do them differently next time.

The broader lesson

The thing I keep coming back to is that good subgroup discovery doesn’t automatically give you good treatment-effect estimation. “Heterogeneous treatment effect analysis” is really several different problems stacked on top of each other:

A method can be good at one of these and bad at another, and it’s easy to miss that if you only evaluate the pipeline end to end. Next time I’d rather design around these pieces separately - ensemble CATE estimation, consensus variable selection, continuous consensus subgrouping, cross-fitting, and independent effect estimation - and then wire them together, instead of treating the pipeline as one black box.

That’s probably the real value of entering a competition like this: not the ranking, but finding out exactly where a pipeline that looked fine end-to-end breaks once you check each piece on its own. I’ll be carrying these lessons into the next version.

One entry point for benchmarking: benchmark()

Comparing learners used to mean choosing between benchmark_default_survlearners() (plain k-fold CV) and benchmark_tuned_survlearners() (nested CV with per-learner hyperparameter tuning). benchmark() now dispatches to either from a single tune argument:

library(survalis)
library(survival)

times <- c(30, 90, 180)

res <- benchmark(
  Surv(time, status) ~ age + karno + celltype,
  data = veteran,
  learners = c("coxph", "rsf"),
  times = times,
  metrics = c("cindex", "ibs"),
  tune = FALSE,
  folds = 5,
  seed = 1
)

res

         splits    id fold metric value learner
1  list(trt.... Fold1    1 cindex 0.739   coxph
2  list(trt.... Fold1    1    ibs 0.173   coxph
3  list(trt.... Fold2    2 cindex 0.697   coxph
4  list(trt.... Fold2    2    ibs 0.156   coxph
5  list(trt.... Fold3    3 cindex 0.703   coxph
6  list(trt.... Fold3    3    ibs 0.166   coxph
7  list(trt.... Fold4    4 cindex 0.717   coxph
8  list(trt.... Fold4    4    ibs 0.168   coxph
9  list(trt.... Fold5    5 cindex 0.754   coxph
10 list(trt.... Fold5    5    ibs 0.152   coxph
11 list(trt.... Fold1    1 cindex 0.636     rsf
12 list(trt.... Fold1    1    ibs 0.171     rsf
13 list(trt.... Fold2    2 cindex 0.697     rsf
14 list(trt.... Fold2    2    ibs 0.172     rsf
15 list(trt.... Fold3    3 cindex 0.720     rsf
16 list(trt.... Fold3    3    ibs 0.158     rsf
17 list(trt.... Fold4    4 cindex 0.677     rsf
18 list(trt.... Fold4    4    ibs 0.188     rsf
19 list(trt.... Fold5    5 cindex 0.722     rsf
20 list(trt.... Fold5    5    ibs 0.151     rsf

tune = TRUE runs the same call as nested CV, dispatching to benchmark_tuned_survlearners() with outer_folds/inner_folds instead. benchmark_default_survlearners() and benchmark_tuned_survlearners() both remain available directly for callers who don’t need the dispatch.

Time-dependent discrimination: timeroc_survmat()

The C-index and the Brier score summarize discrimination and calibration at a single horizon. timeroc_survmat() adds a vectorized cumulative/dynamic AUC curve over a vector of evaluation times, matching timeROC::timeROC(weighting = "marginal") to about 1e-3 (Uno et al. 2007 / Heagerty and Zheng 2005):

y <- Surv(veteran$time, veteran$status)
mod_rsf <- fit_rsf(Surv(time, status) ~ age + karno + celltype, data = veteran, ntree = 200)
sp_rsf <- predict_rsf(mod_rsf, newdata = veteran, times = times)

timeroc_survmat(y, predicted = sp_rsf, times = times)

  time      auc
1   30 0.886782
2   90 0.882384
3  180 0.897919

A native Kaplan-Meier plot: plot_survcurve()

plot_survcurve() adds a survminer-style Kaplan-Meier curve with a confidence ribbon, a log-rank p-value annotation, and an aligned number-at-risk table, built directly on theme_survalis() / scale_color_survalis() rather than depending on the survminer package. The risk table is composed with patchwork.

plot_survcurve(Surv(time, status) ~ celltype, data = veteran)

A consistent visual system: theme_survalis() and the color scales

Every plotting function used to call theme_minimal() with its own base_size, and grouped plots fell back to ggplot2’s default hue palette except for plot_survcurve(). theme_survalis() and the colorblind-friendly scale_color_survalis() / scale_fill_survalis() (ColorBrewer “Dark2”-based, interpolated beyond 8 levels) were retrofitted across every plotting function, plot_ale(), plot_pdp(), plot_shap(), plot_interactions(), plot_calibration(), plot_counterfactual(), plot_surrogate(), plot_tree_surrogate(), plot_varimp(), plot_survmat(), plot_survmetalearner_weights(), plot_benchmark(), cv_plot(), plot_survcurve(), so package figures read as one system instead of thirteen independent styles. Single-series hardcoded colors ("steelblue", "pink", "tomato", ad-hoc green/red hex codes) were replaced the same way, and every plot that can show both positive and negative values now draws a dashed zero-reference line.

As of 0.9.0, every one of those functions also takes a title argument: pass a custom string, leave it out for the previous auto-generated title, or pass title = NULL to drop it entirely for journals that require caption-only figures.

Uncertainty in variable importance: plot_varimp()

compute_varimp() computes permutation-based importance by repeating a metric drop over n_repetitions permutations per feature. It used to summarize those repetitions down to a single point estimate and discard them. plot_varimp() now draws the full per-repetition distribution as a boxplot instead of a lone point, and compute_varimp() keeps the raw values as a "raw_scores" attribute so the plot can use them (falling back to the old point-plot for hand-built summary tables without that attribute):

mod_cox <- fit_coxph(Surv(time, status) ~ age + karno + celltype, data = veteran)
vi <- compute_varimp(mod_cox, times = times, metric = "ibs", n_repetitions = 15, seed = 1)

p <- plot_varimp(vi)
ggplot2::ggsave("featured.png", p, width = 7, height = 4.5, dpi = 150)
p

Migration to data.table

Every internal data-manipulation path, the CV/metrics engine (cv_survlearner(), cv_summary(), score_survmodel()), all nineteen tune_*() functions, cv_survmetalearner(), benchmark_tuned_survlearners(), compute_shap(), compute_calibration(), plot_survmat(), compute_varimp(), and the descriptive list_*() helpers, was migrated file by file from dplyr/tidyr/purrr/tibble to data.table. dplyr, tidyr, purrr, and tibble are no longer in Imports at all; data.table is now the sole data-manipulation engine. cv_summary()/score_survmodel() and summarise_benchmark() now round summary statistics to 3 decimals by default, consistently.

Corrections along the way

A few of these were silent correctness bugs, not just style:

• auc_survmat() case definition. Cases were defined as events with time <= t_star instead of the canonical Uno/timeROC time < t_star. This fed directly into the "auc" metric used throughout score_survmodel(), benchmark_*(), and fit_survmetalearner(), so it was corrected everywhere at once.
• Silently dropped learners in nested tuning. benchmark_tuned_survlearners() selected tuning-result columns with tuning_results[1, cols, drop = FALSE], relying on data.frame [ semantics; data.table’s [ doesn’t select columns from a variable the same way, so every fold for a data.table-migrated learner errored and the learner was quietly dropped with a warning. Fixed with a .select_cols() helper that works for both data.frame/tibble and data.table inputs.
• tune_survsvm(refit_best = TRUE) crashes. A top-ranked grid candidate could fail to refit on the full dataset (a quadprog QP infeasibility that only shows up on certain BLAS backends, including CRAN’s OpenBLAS check machine). It now falls back to the next-best candidate and only errors if every candidate fails.
• plot_interactions(type = "heatmap") readability. The white -> steelblue gradient had too little contrast in the mid-range and the zero-valued diagonal blended into the low end. Switched to a perceptually uniform viridis scale, flipped afterward so high interaction values read as dark rather than bright, matching conventional heatmap reading.
• plot_pdp() per-time facets. Free y-axis scales made survival-probability panels visually incomparable across facets; now fixed to [0, 1] via coord_cartesian().
• Stale generated docs breaking CI. Three .Rd files had hand-drifted out of sync with their roxygen source, using \donttest{} (which CI runs) instead of \dontrun{}, causing an example to fail on an undefined object. Regenerated from source and verified with R CMD check --run-donttest.

Links

• CRAN.R-project.org/package=survalis
• GitHub: github.com/ielbadisy/survalis

Core philosophy

Every learner in survalis follows the same pattern:

• fit_*() functions return a standardized mlsurv_model object
• predict_*() functions return a data.frame of survival probabilities, one row per subject, one column per requested time (t=100, t=200, …)
• Evaluation is fully modular: any fit_*/predict_* pair plugs into cv_survlearner() or score_survmodel()
• Everything downstream (benchmarking, calibration, interpretation) is designed to work on that same survival-probability matrix, regardless of which learner produced it

Why explicit fit_coxph() / fit_rsf() instead of one fit(learner = ...)

This is a deliberate departure from funcml, my general-purpose ML package, where fit(y ~ ., data, learner = "ranger") collapses every learner behind one verb and a string argument. survalis keeps a named function per learner, fit_coxph(), fit_rsf(), fit_survdnn(), and so on, instead of a single dispatcher.

The reason is that the survival setting is not just “regression with a different loss.” Every learner here already has to negotiate right-censoring, risk sets, and time-varying prediction targets on its own terms, and each one leans on a different underlying package (survival, randomForestSRC, xgboost, torch, flexsurv, …) with its own quirks around ties, time horizons, and baseline hazard estimation. Hiding fit_coxph and fit_rsf behind a shared fit(learner = "rsf") string would trade a small amount of typing for a layer of indirection between the call site and the model-specific machinery it actually invokes, machinery that, in survival analysis, is rarely interchangeable enough to be worth hiding. Keeping the learner name in the function name is a compactness choice: the API surface is larger (nineteen fit_*()/predict_*() pairs instead of one), but each call is self-describing and there is one fewer level of abstraction between what you write and what runs.

What survalis does unify is everything after fitting: predict_*() always returns the same survival-probability matrix shape, so cindex_survmat(), brier(), cv_survlearner(), and benchmark() never need to know which fit_*() produced it. The genericity lives at the evaluation/interpretation layer, not at the fitting layer.

That output shape was a deliberate constraint, not an incidental one. A Cox model naturally hands back a linear predictor or a hazard ratio; a random survival forest hands back an ensemble of terminal-node curves; a deep survival network hands back whatever its loss was trained on (a Cox partial likelihood, an AFT loss, a discrete-time hazard). fit_survdnn() itself can predict a linear predictor if asked, since its loss functions include a Cox-style formulation. survalis standardizes on the survival-probability matrix anyway, over times t=100, t=200, and so on, because a matrix is, by construction, a richer object than a scalar: a linear predictor collapses a subject’s entire risk trajectory into one number and one implicit ranking, while a survival curve preserves how that risk actually unfolds over the follow-up window, which is what a fixed-horizon metric, a time-varying AUC, or a calibration curve each need to read back out at a different point. Forcing every predict_*() to that one shape throws away learner-specific detail on the way out (a Cox model’s clean linear score, a forest’s raw ensemble votes), but it is exactly what makes cindex_survmat(), brier(), timeroc_survmat(), and every interpretation function in the package learner-agnostic, without asking any of them to reconstruct a survival curve from a scalar first. The alternative, keeping each learner’s native output format and writing metric functions that branch on model class, is the design survalis specifically avoids.

Nineteen learners, one interface

library(survalis)
list_survlearners()

           learner                 fit                 predict             tune
1            coxph           fit_coxph           predict_coxph             <NA>
2            aalen           fit_aalen           predict_aalen             <NA>
3           glmnet          fit_glmnet          predict_glmnet      tune_glmnet
4        selectcox       fit_selectcox       predict_selectcox   tune_selectcox
5           aftgee          fit_aftgee          predict_aftgee             <NA>
6      flexsurvreg     fit_flexsurvreg     predict_flexsurvreg tune_flexsurvreg
7            stpm2           fit_stpm2           predict_stpm2             <NA>
8          bnnsurv         fit_bnnsurv         predict_bnnsurv     tune_bnnsurv
9            rpart           fit_rpart           predict_rpart       tune_rpart
10            bart            fit_bart            predict_bart        tune_bart
11         xgboost         fit_xgboost         predict_xgboost     tune_xgboost
12        coxboost        fit_coxboost        predict_coxboost    tune_coxboost
13         fastgbm         fit_fastgbm         predict_fastgbm             <NA>
14          ranger          fit_ranger          predict_ranger      tune_ranger
15             rsf             fit_rsf             predict_rsf         tune_rsf
16         cforest         fit_cforest         predict_cforest     tune_cforest
17      blackboost      fit_blackboost      predict_blackboost  tune_blackboost
18         survsvm         fit_survsvm         predict_survsvm     tune_survsvm
19         survdnn         fit_survdnn         predict_survdnn     tune_survdnn
20        densemlp        fit_densemlp        predict_densemlp             <NA>
21            orsf            fit_orsf            predict_orsf        tune_orsf
22          rpsurv          fit_rpsurv          predict_rpsurv             <NA>
23          nbsurv          fit_nbsurv          predict_nbsurv             <NA>
24 survmetalearner fit_survmetalearner predict_survmetalearner             <NA>
   has_fit has_predict has_tune available
1     TRUE        TRUE    FALSE      TRUE
2     TRUE        TRUE    FALSE      TRUE
3     TRUE        TRUE     TRUE      TRUE
4     TRUE        TRUE     TRUE      TRUE
5     TRUE        TRUE    FALSE      TRUE
6     TRUE        TRUE     TRUE      TRUE
7     TRUE        TRUE    FALSE      TRUE
8     TRUE        TRUE     TRUE      TRUE
9     TRUE        TRUE     TRUE      TRUE
10    TRUE        TRUE     TRUE      TRUE
11    TRUE        TRUE     TRUE      TRUE
12    TRUE        TRUE     TRUE      TRUE
13    TRUE        TRUE    FALSE      TRUE
14    TRUE        TRUE     TRUE      TRUE
15    TRUE        TRUE     TRUE      TRUE
16    TRUE        TRUE     TRUE      TRUE
17    TRUE        TRUE     TRUE      TRUE
18    TRUE        TRUE     TRUE      TRUE
19    TRUE        TRUE     TRUE      TRUE
20    TRUE        TRUE    FALSE      TRUE
21    TRUE        TRUE     TRUE      TRUE
22    TRUE        TRUE    FALSE      TRUE
23    TRUE        TRUE    FALSE      TRUE
24    TRUE        TRUE    FALSE      TRUE

That list spans semiparametric (coxph, aalen), parametric (flexsurvreg, stpm2, aftgee), tree-based and ensemble (rpart, rsf, cforest, orsf), boosting (xgboost, blackboost), kernel (survsvm), and deep-learning (survdnn, bnnsurv) learners, plus survmetalearner for combining several of them. Most also ship a matching tune_*() function for grid or random hyperparameter search.

A minimal example

library(survival)

times <- c(90, 180, 270)

mod <- fit_coxph(Surv(time, status) ~ age + karno + celltype, data = veteran)
sp <- predict_coxph(mod, newdata = veteran, times = times)

head(sp)

       t=90      t=180       t=270
1 0.6640601 0.37822072 0.257579996
2 0.7361432 0.48310054 0.362410259
3 0.6104309 0.30966354 0.194867900
4 0.6541127 0.36490330 0.245015675
5 0.7375010 0.48521958 0.364629899
6 0.1897037 0.01929484 0.004055248

times_fine <- seq(0, 300, by = 10)
sp_fine <- predict_coxph(mod, newdata = veteran[1:8, ], times = times_fine)

p <- plot_survmat(sp_fine)
ggplot2::ggsave("featured.png", p, width = 7, height = 4.5, dpi = 150)
p

Discrimination and calibration are single function calls away, at a fixed horizon or cross-validated across folds:

y <- Surv(veteran$time, veteran$status)

c(
  cindex = cindex_survmat(y, sp, t_star = 180),
  brier  = survalis::brier(y, sp[["t=180"]], t_star = 180)
)

cindex.C index    brier.brier 
      0.733744       0.134603 

Swap fit_coxph/predict_coxph for any other pair in list_survlearners() and every downstream call, cindex_survmat(), brier(), cv_survlearner(), benchmark(), stays exactly the same.

Beyond prediction: interpretation

Because every learner returns the same survival-probability shape, survalis’s interpretability layer works uniformly across all of them: permutation variable importance (compute_varimp()), accumulated local effects and partial dependence (compute_ale(), compute_pdp()), SHAP-based attribution (compute_shap()), pairwise interaction strength (compute_interactions()), counterfactual recommendations (compute_counterfactual()), and surrogate-tree explanations (compute_surrogate(), compute_tree_surrogate()), each with a matching plot_*() function.

Install

install.packages("survalis")

Links

• CRAN.R-project.org/package=survalis
• GitHub: github.com/ielbadisy/survalis

What is unsurv?

unsurv (v0.6.0) takes a matrix of survival probabilities (rows are subjects, columns are time points) and returns cluster assignments, medoid curves, and a silhouette diagnostic.

Install:

install.packages("unsurv")

The core idea

Suppose you have estimated individual survival curves for patients on a shared time grid (from any model: Kaplan–Meier stratified by covariates, a Cox model, a random survival forest, or survdnn). Stack them into an matrix and pass it to unsurv().

The algorithm:

1. Optionally enforce monotone non-increasing curves.
2. Optionally smooth curves with a median filter.
3. Compute a weighted distance matrix ( or ) using trapezoidal weights by default, so time points in regions of faster change contribute more.
4. Run PAM on the distance matrix.
5. If is unspecified, select the that maximizes mean silhouette width.

Basic usage

library(unsurv)

# Simulate survival curves from two latent risk groups
set.seed(42)
n     <- 100
times <- seq(0, 5, length.out = 40)
grp   <- sample(1:2, n, replace = TRUE)
rates <- ifelse(grp == 1, 0.2, 0.8)
S     <- outer(rates, times, function(r, t) exp(-r * t))
S     <- S + matrix(rnorm(n * length(times), sd = 0.02), nrow = n)

# Cluster with automatic K selection
fit <- unsurv(S, times, K = NULL, K_max = 6, seed = 123)

fit$K               # selected number of clusters

[1] 2

table(fit$clusters) # cluster assignment per subject

 1  2 
44 56 

fit$silhouette_mean # mean silhouette width at the selected K

[1] 0.9393843

Distance and weighting options

# L1 (Manhattan) distance: more robust to outlier curves
fit_l1 <- unsurv(S, times, K = 2, distance = "L1")

# Custom time weights: emphasize early time points
w <- rev(seq_along(times))
fit_w <- unsurv(S, times, K = 2, weights = w / sum(w))

Monotonic enforcement and smoothing

Raw predicted survival curves from flexible models may not be strictly non-increasing. unsurv corrects this before clustering:

fit <- unsurv(
  S, times, K = NULL, K_max = 6, seed = 123,
  enforce_monotone   = TRUE,  # project each curve to isotonic
  smooth_median_width = 5      # median filter of width 5 over time
)

Predicting clusters for new subjects

# newdata: n_new x m matrix of survival curves for new patients
pred <- predict(fit, newdata = S[1:5, ])
pred

[1] 1 1 1 1 2

Plotting

plot(fit)

Combining with a survival model

A natural pipeline is:

1. Fit individualized survival curves with a model of your choice (e.g., survdnn, rfsrc, Cox with spline terms).
2. Predict on a common time grid.
3. Pass the resulting matrix to unsurv() to discover prognostic subgroups.
4. Use cluster membership as a stratification variable or as a phenotype to interrogate.

library(survival)
library(survdnn)
torch::torch_manual_seed(1)

dnn_fit <- survdnn(Surv(time, status) ~ age + sex + ph.ecog + ph.karno, data = lung,
                   hidden = c(64, 32), loss = "cox", epochs = 100, verbose = FALSE)

times_grid <- seq(0, 1000, by = 25)
S_hat <- as.matrix(predict(dnn_fit, newdata = lung, type = "survival", times = times_grid))

clust <- unsurv(S_hat, times_grid, K = NULL, K_max = 5, seed = 1)
table(clust$clusters)

  1   2   3 
113  70  43 

Methodological background

unsurv’s preprocessing choices, distance weighting, medoid-based clustering, and stability assessment are described in El Badisy (2026), “unsurv: Clustering Individualized Survival Curves”, Bioinformatics Advances, doi:10.1093/bioadv/vbag218, with a demonstration on the METABRIC breast cancer cohort using survdnn-predicted curves.

Links

• GitHub: github.com/ielbadisy/unsurv
• Paper: doi:10.1093/bioadv/vbag218

What is survdnn?

survdnn (v0.7.6) trains multilayer perceptrons for right-censored survival data. It supports four loss functions, built-in cross-validation, hyperparameter tuning, survival curve prediction, and standard evaluation metrics.

Install:

install.packages("torch")   # backend
install.packages("survdnn")

Fitting a model

The entry point is survdnn(), which takes a Surv() formula:

library(survival)
library(survdnn)
torch::torch_manual_seed(1)

fit <- survdnn(
  formula   = Surv(time, status) ~ age + sex + ph.ecog + ph.karno,
  data      = lung,
  hidden    = c(64, 32),
  activation = "relu",
  loss      = "cox",
  epochs    = 300,
  lr        = 1e-3,
  dropout   = 0.3,
  batch_norm = TRUE,
  verbose   = FALSE
)

fit

Loss functions

Four loss functions are available, covering the major families of deep survival models:

Prediction and survival curves

# predict linear predictor (risk score)
head(predict(fit, newdata = lung, type = "lp"))

[1]  0.1397203 -0.2062566 -0.9678885  0.1454131 -0.7345585 -1.1179752

# predict survival curves on a time grid
times <- seq(0, 1000, by = 50)
surv  <- predict(fit, newdata = lung, type = "survival", times = times)
head(surv)

        t=0      t=50     t=100     t=150     t=200     t=250     t=300
1 0.9951746 0.9361534 0.8451717 0.7604267 0.6144562 0.5117045 0.4266991
2 0.9965835 0.9543929 0.8877925 0.8238434 0.7085186 0.6224762 0.5473946
3 0.9984034 0.9784408 0.9459462 0.9134979 0.8513897 0.8014476 0.7547645
4 0.9951471 0.9358008 0.8443605 0.7592386 0.6127502 0.5097510 0.4246295
5 0.9979842 0.9728526 0.9322323 0.8920343 0.8161431 0.7561600 0.7009718
6 0.9986257 0.9814173 0.9533005 0.9250892 0.8706953 0.8265549 0.7849473
      t=350     t=400     t=450     t=500     t=550      t=600      t=650
1 0.3291391 0.2446004 0.1935003 0.1582133 0.1135787 0.08159666 0.05483936
2 0.4555458 0.3692460 0.3128289 0.2712947 0.2145830 0.16981532 0.12819513
3 0.6927352 0.6280267 0.5812417 0.5438405 0.4874379 0.43699172 0.38323199
4 0.3270575 0.2426419 0.1916944 0.1565566 0.1121769 0.08043761 0.05393788
5 0.6290261 0.5557598 0.5039996 0.4633978 0.4035571 0.35155256 0.29784911
6 0.7290997 0.6700901 0.6268990 0.5920222 0.5387818 0.49043253 0.43803954
       t=700      t=750       t=800       t=850       t=900       t=950
1 0.03171439 0.01237621 0.007940308 0.004207006 0.001865832 0.001865832
2 0.08701532 0.04471476 0.032664382 0.020839752 0.011723673 0.011723673
3 0.31981080 0.23436366 0.202402368 0.164090863 0.125440661 0.125440661
4 0.03109568 0.01206975 0.007724095 0.004077636 0.001800081 0.001800081
5 0.23701727 0.16006584 0.133011865 0.102049314 0.072695858 0.072695858
6 0.37488195 0.28688417 0.252875078 0.211093807 0.167527461 0.167527461
       t=1000
1 0.001865832
2 0.011723673
3 0.125440661
4 0.001800081
5 0.072695858
6 0.167527461

p <- plot(fit, newdata = lung[1:5, ], times = times)
ggplot2::ggsave("featured.png", p, width = 7, height = 4.5, dpi = 150)
p

Evaluation

evaluate_survdnn() computes the concordance index and integrated Brier score from the fitted model:

evaluate_survdnn(fit, metrics = c("cindex", "ibs"), times = seq(100, 800, by = 200), newdata = lung)

# A tibble: 2 × 2
  metric value
  <chr>  <dbl>
1 cindex 0.689
2 ibs    0.162

Hyperparameter tuning with cross-validation

tune_survdnn() runs a grid search over the hyperparameter space with K-fold cross-validation. param_grid is a named list crossed via tidyr::crossing(), and must include hidden, lr, activation, epochs, .loss_fn, and loss_name:

grid <- list(
  hidden     = list(c(16), c(32, 16)),
  lr         = c(1e-3, 1e-4),
  activation = c("relu"),
  epochs     = c(200),
  .loss_fn   = list(cox_loss, aft_loss),
  loss_name  = c("cox", "aft")
)

tuned <- tune_survdnn(
  formula = Surv(time, status) ~ age + sex + ph.ecog,
  data    = lung,
  times   = c(90, 300),
  metrics = "cindex",
  param_grid = grid,
  folds   = 5,
  return  = "summary"
)

Architecture

Under the hood, survdnn() builds an MLP via build_dnn(): linear layers with optional batch normalization and dropout between each hidden layer, terminating in a single linear output. The torch optimizer (Adam by default) is configurable via optimizer and optim_args.

Methodological background

survdnn’s design, loss functions, and benchmarks against classical and machine learning survival models are described in El Badisy (2026), “SurvDNN: Survival Deep Learning Models for Tabular Data”, The R Journal, RJ-2026-008.

Links

• GitHub: github.com/ielbadisy/survdnn
• Paper: RJ-2026-008

What is mimar?

mimar (v0.8.0) covers the full missing-data analysis cycle:

1. Amputation: artificially introduce missingness into a complete dataset for simulation studies
2. Imputation: single or multiple imputation via chained equations with a choice of statistical or ML imputers
3. Evaluation: diagnostic metrics comparing imputed distributions to observed and (when known) true values
4. Pooling: Rubin’s rules applied to post-imputation model estimates

Install:

install.packages("mimar")

Artificial amputation

ampute() introduces controlled missingness into a complete data frame, specifying the mechanism (MCAR, MAR, MNAR) and the proportion of missing cells:

library(mimar)

set.seed(1)
amp <- ampute(iris, prop = 0.25, mechanism = "MCAR")

head(amp$data)       # the amputed data frame

# basetable: 6 x 5
  Sepal.Length Sepal.Width Petal.Length Petal.Width Species
1          5.1         3.5          1.4         0.2  setosa
2          4.9         3.0           NA         0.2  setosa
3          4.7         3.2          1.3         0.2    <NA>
4          4.6         3.1          1.5          NA  setosa
5           NA         3.6          1.4          NA  setosa
6          5.4          NA          1.7         0.4  setosa

Multiple imputation

impute() runs chained equations with any registered imputer. The default is predictive mean matching ("pmm"), but ML-based imputers are equally accessible:

# PMM: the safe default
imp_pmm <- impute(amp, m = 5, imputer = "pmm", maxit = 5)

# Random forest imputation
imp_rf <- impute(amp, m = 5, imputer = "ranger")

# XGBoost imputation
imp_xgb <- impute(amp, m = 5, imputer = "xgboost")

class(imp_pmm)

[1] "mimar_imputation" "list"            

impute() returns a mimar_imputation object containing all m completed datasets alongside metadata for downstream steps.

Available imputers

imputer_registry()[, c("imputer", "implementation", "stochastic")]

# basetable: 25 x 3
   imputer implementation stochastic
1     mean          mimar      FALSE
2   median          mimar      FALSE
3     mode          mimar      FALSE
4    naive          mimar      FALSE
5     norm          mimar       TRUE
6      pmm          mimar       TRUE
7     spmm          mimar       TRUE
8   logreg          mimar       TRUE
9  polyreg          mimar       TRUE
10      rf        wrapped       TRUE
# 15 more rows

Evaluation

When the true values are known (after amputation, or from a simulation), evaluate() computes recovery metrics comparing imputed to true values:

diag <- evaluate(imp_pmm)
diag$distribution       # observed vs. imputed means, SDs, unique counts

# basetable: 5 x 9
      variable    type missing observed_unique imputed_unique observed_mean
1 Sepal.Length numeric      33              33             28      5.837607
2  Sepal.Width numeric      39              22             19      3.075676
3 Petal.Length numeric      34              42             38      3.755172
4  Petal.Width numeric      34              21             21      1.252586
5      Species  factor      31               3              3            NA
  imputed_mean observed_sd imputed_sd
1     5.987273   0.8377645  0.7791618
2     3.035385   0.4509014  0.4011957
3     3.770000   1.8037808  1.5557433
4     1.076471   0.7519784  0.7701759
5           NA          NA         NA

Completing and pooling

Extract a single completed dataset or pool regression estimates across all m imputations using Rubin’s rules:

completed <- complete(imp_pmm, which = 1)
head(completed)

# basetable: 6 x 5
  Sepal.Length Sepal.Width Petal.Length Petal.Width    Species
1          5.1         3.5          1.4         0.2     setosa
2          4.9         3.0          1.4         0.2     setosa
3          4.7         3.2          1.3         0.2 versicolor
4          4.6         3.1          1.5         0.2     setosa
5          5.1         3.6          1.4         0.5     setosa
6          5.4         3.3          1.7         0.4     setosa

# fit a model on each completed dataset, then pool the coefficients
completed_list <- lapply(seq_len(imp_pmm$m), function(k) complete(imp_pmm, which = k))
fits  <- lapply(completed_list, function(d) lm(Sepal.Length ~ Sepal.Width + Petal.Length + Petal.Width, data = d))
betas <- lapply(fits, coef)
vars  <- lapply(fits, function(f) diag(vcov(f)))

pool(betas, variance = vars)

mimar pooled results
# basetable: 4 x 14
          term   estimate  std.error statistic  df      p.value   conf.low
1  (Intercept)  2.1204880 0.23942658  8.856527 Inf 8.254583e-19  1.6512205
2  Sepal.Width  0.5861945 0.06375298  9.194779 Inf 3.757668e-20  0.4612410
3 Petal.Length  0.7034397 0.05719104 12.299822 Inf 9.077385e-35  0.5913473
4  Petal.Width -0.5639728 0.12879778 -4.378746 Inf 1.193641e-05 -0.8164118
   conf.high m within_variance between_variance total_variance
1  2.5897555 5     0.057325087                0    0.057325087
2  0.7111480 5     0.004064442                0    0.004064442
3  0.8155320 5     0.003270815                0    0.003270815
4 -0.3115338 5     0.016588867                0    0.016588867
  relative_increase_variance  rule
1                          0 rubin
2                          0 rubin
3                          0 rubin
4                          0 rubin

When to use mimar

mimar is designed for:

• Simulation studies: amputate, impute, evaluate recovery under controlled conditions
• Applied health research: handle missing covariates or outcomes before regression or survival analysis
• ML-driven imputation: when the imputation model is complex enough to warrant a tree ensemble or gradient booster

Links

• GitHub: github.com/ielbadisy/mimar

What is funcml?

funcml provides a unified, formula-first interface to supervised learning in R. Six top-level verbs cover the full ML workflow:

Install from CRAN:

install.packages("funcml")

A minimal example

library(funcml)

# fit a random forest
fit_rf <- fit(Sepal.Length ~ ., data = iris, model = "ranger")

# evaluate with 5-fold CV
evaluate(data = iris, formula = Sepal.Length ~ ., model = "ranger", resampling = cv(5), seed = 1)

<funcml_eval> model: ranger | task: regression
  metric   mean     sd n std_error conf_level conf_low conf_high
1   rmse 0.3391 0.0451 5    0.0202       0.95   0.2830    0.3951
2    mae 0.2771 0.0303 5    0.0136       0.95   0.2394    0.3147
3    mse 0.1166 0.0322 5    0.0144       0.95   0.0767    0.1565
4  medae 0.2428 0.0391 5    0.0175       0.95   0.1943    0.2913
5   mape 0.0478 0.0050 5    0.0022       0.95   0.0416    0.0540
6    rsq 0.8236 0.0552 5    0.0247       0.95   0.7550    0.8922

# compare to a regularized regression
compare(
  data = iris,
  formula = Sepal.Length ~ .,
  models = c("ranger", "glmnet"),
  resampling = cv(5),
  seed = 1
)

<funcml_compare> task: regression | tuned: FALSE
    model metric    mean     sd n std_error conf_level conf_low conf_high tuned
1  ranger   rmse  0.3391 0.0451 5    0.0202       0.95   0.2830    0.3951 FALSE
2  ranger    mae  0.2771 0.0303 5    0.0136       0.95   0.2394    0.3147 FALSE
3  ranger    mse  0.1166 0.0322 5    0.0144       0.95   0.0767    0.1565 FALSE
4  ranger  medae  0.2428 0.0391 5    0.0175       0.95   0.1943    0.2913 FALSE
5  ranger   mape  0.0478 0.0050 5    0.0022       0.95   0.0416    0.0540 FALSE
6  ranger    rsq  0.8236 0.0552 5    0.0247       0.95   0.7550    0.8922 FALSE
7  glmnet   rmse  0.8258 0.0670 5    0.0300       0.95   0.7426    0.9090 FALSE
8  glmnet    mae  0.6914 0.0683 5    0.0305       0.95   0.6066    0.7762 FALSE
9  glmnet    mse  0.6856 0.1110 5    0.0496       0.95   0.5478    0.8234 FALSE
10 glmnet  medae  0.6252 0.0687 5    0.0307       0.95   0.5399    0.7104 FALSE
11 glmnet   mape  0.1205 0.0104 5    0.0047       0.95   0.1076    0.1335 FALSE
12 glmnet    rsq -0.0175 0.0208 5    0.0093       0.95  -0.0433    0.0084 FALSE
   rank
1     1
2     1
3     1
4     1
5     1
6     1
7     2
8     2
9     2
10    2
11    2
12    2

Interpretability built in

interpret() wraps 14 methods, from permutation importance and partial dependence plots to SHAP values and accumulated local effects, behind a single call:

interpret(fit_rf, data = iris, method = "pdp", features = "Petal.Width")$result$curves |> head()

      feature     value     yhat
1 Petal.Width 0.1000000 5.555846
2 Petal.Width 0.2142857 5.567275
3 Petal.Width 0.3285714 5.573585
4 Petal.Width 0.4428571 5.654030
5 Petal.Width 0.5571429 5.644077
6 Petal.Width 0.6714286 5.656769

Causal estimation

When the research question goes beyond prediction, estimate() wraps plug-in g-computation to estimate average and conditional treatment effects:

set.seed(1)
n <- 200
X1 <- rnorm(n); X2 <- rnorm(n)
A <- rbinom(n, 1, plogis(0.3 * X1))
Y <- 1 + 0.5 * A + 0.4 * X1 - 0.2 * X2 + rnorm(n)
mydata <- data.frame(Y, A, X1, X2)

# ATE of treatment A on outcome Y, adjusted for covariates X
estimate(
  data      = mydata,
  formula   = Y ~ A + X1 + X2,
  model     = "ranger",
  treatment = "A",
  estimand  = "ATE",
  seed      = 1
)

<funcml_estimand> ATE via g-computation
Treatment: A (1 vs 0)
Estimate: 0.4531 | SE: 0.0156 | 95% normal CI [0.4225, 0.4836]

The learner registry

funcml ships with 26 learners spanning linear models, tree ensembles, SVMs, neural networks, additive models, boosting, and stacking. All are accessed by name:

list_learners()[, c("learner", "has_tune")]

        learner has_tune
17     adaboost     TRUE
24         bart     TRUE
11          C50     TRUE
20      cforest     TRUE
19        ctree     TRUE
7      densemlp     TRUE
8     e1071_svm     TRUE
13        earth     TRUE
26      fastgbm     TRUE
16          fda     TRUE
14          gam     TRUE
10          gbm     TRUE
1           glm     TRUE
3        glmnet     TRUE
12         kknn     TRUE
21          lda     TRUE
23     lightgbm     TRUE
6           mlp     TRUE
15   naivebayes     TRUE
5          nnet     TRUE
18          pls     TRUE
22          qda     TRUE
9  randomForest     TRUE
4        ranger     TRUE
2         rpart     TRUE
27     stacking     TRUE
28 superlearner     TRUE
25      xgboost     TRUE

Citation

@software{El_Badisy_funcml_2026,
  author  = {El Badisy, Imad},
  license = {GPL-3.0-only},
  month   = apr,
  title   = {{funcml}},
  doi     = {10.5281/zenodo.20707605},
  url     = {https://doi.org/10.5281/zenodo.20707605},
  version = {0.7.1},
  year    = {2026}
}

Links

• GitHub: github.com/ielbadisy/funcml
• CRAN: CRAN.R-project.org/package=funcml
• Citation: doi:10.5281/zenodo.20707605