TMLE Design

Existing Packages

• tmle
• ltmle
• stremr
• tmlecte - TMLE for conditional treatment effects
• TargetedLearning.jl and ctmle.jl
• ctmle or via Mireille Schnitzer

Planned Features

Minimum

• Ability to define new parameter estimators

  • Estimator comprised of loss function, sub-model, and the parameter map as a function of the nuisance parameters (Q and g) to define the substitution procedure.

• Arbitrary estimation strategies

  • Iterative
  • recursive
  • weights vs clever covariate (these are probably just different sub-model options)

• deterministic Q and g function

• obsWeights (either prespecified weights or functions, or a function of the nuisance parameters to be fitted). Weights can be used in fitting target parameter, and also for assessing variance estimates.

• Clustered variance estimate (specify independent units)

Nice-to-have

• Collaborative TMLE algorithm

Supported Parameters

• Total causal effects (longitudinal and point exposure)
• Mediation effects (longitudinal and point exposure)
  • NDE
  • NIE
• Stochastic interventions (longitudinal and point)
• Variable Importance
• Optimal Treatment Effects
  • resource constrained
  • Optimal Rule
  • Value under optimal rule (CV-TMLE)
• MSMs
• Continuous exposure

Design

As much as possible, recycle model fits that are common across parameters. Adapt stremr code to work with origami, add additional features described above.

Data Structure

A parameter specification object, containing all the details about how a parameter should be fit including:

• Functions that can be applied to the tmledata object described below which specify
  • A parameter definition
  • Clever covariate(s)
  • Influence curve
• A sub-model and loss function
• a treatment rule or stochastic treatment distribution (functions of the covariates, where appropriate) If MSM, then also specify MSM model.
• Observations weights (same comments as above)

A tmledata object containing:

• the observed data
• initial estimates (where appropriate) for
  • outcome mechanism
  • treatment mechanism
  • censoring mechanism This will be in long format for L-TMLE.

A list of nodes indicating which variables are covariates, treatments, censoring, and outcome.

Algorithm

We'll port the bulk of the core stremr functionality into a new package, and then develop the additional features on top of that. stremr gets us l-tmle with a range of parameter types on long form data. From there, we'll add support for origami, so that we can do split-specific SuperLearning. Additionally, we'll add gentmle-style support for parameter definitions.

Choice of loss function

We should use negative (quasi)-binomial log likelihood loss by default, but other losses can be supported via the specification of sub-model and loss function as is currently done in gentmle2. Where possible the SuperLearner loss function for Q should match the TMLE loss function.

Bounded continuous parameters

Currently there is strange behavior when we bound continuous outcomes between 0 and 1 and then use the binomial family for SuperLearner. Some algorithms (e.g. Rpart, RandomForest, and svm) are expecting truly binary data and behave strangely when given quasi-binomial data. We need to resolve this, likely by using the regression behavior for these learners in the case of quasibinomial models.

[CK: this is a misunderstanding of the family argument to SuperLearner, as has been discussed. Binomial just means binary classification, so yes "gaussian" (i.e. regression) needs to be used. Recommend removing this item.]

[JC: Typically TMLE for bounded continuous parameters uses a negative quasibinomial log likelihood loss. This will be infinite for initial Q estimates outside the bounds. This means we need to guarantee that our initial Q estimates generated by Super Learner are not outside the bounds. There's ways to do that outside of modifying the SuperLearner behavior (e.g. warn bounds may be too tight, truncate predictions, or transform the outcomes to be on a (-Inf,Inf) scale before running regression Super Learner), but it's not clear if these are the best solution. I think we need to discuss further]

CV-TMLE

We can use SplitSpecific CV-TMLE by default, as it doesn't increase computational burden over standard TMLE, but results are more robust. We should provide an option to run standard TMLE, as it will still be useful (e.g. for simulation).