Multiple Imputation in Stata: mi impute and mi estimate

Stata’s official multiple-imputation suite is the mi command family — not a single command, but a workflow: mi set declares the dataset’s imputation style, mi register tells Stata which variables are actually missing, mi impute fills in the missing values across multiple copies of the data, and mi estimate runs an analysis model on every copy and pools the results into one answer using Rubin’s rules. This page covers the Stata mechanics specifically — the commands, options, and syntax traps. For what multiple imputation is doing conceptually and why it beats listwise deletion or single imputation, see Multiple Imputation: A Practical Protocol; for the pooling formulas mi estimate runs under the hood, see Rubin’s Rules for Pooling Multiply Imputed Estimates.

Setting up mi data: mi set and mi register

Before Stata will let you impute anything, the dataset has to be declared as an mi dataset:

mi set flong

mi set takes one of four storage styles, and the choice only affects file size and command speed, not the statistical result:

• flong — one long dataset with an _mi_m variable marking which imputation each observation belongs to (m=0 is the original data). The most common choice and the easiest to inspect with ordinary list/tabulate commands.
• mlong — like flong but stores only the imputed cells that actually changed, not a full copy of every variable for every imputation. Smaller on disk for large datasets with few missing cells.
• wide — one row per original observation, with a separate set of variables (var_1_, var_2_, …) for each imputation. Least commonly used with mi impute directly.
• flongsep — each imputation stored as a fully separate .dta file. Rare; mainly a compatibility format for older ice-based workflows.

Next, every variable that will receive imputed values has to be registered as imputed, and it is a common source of “variable not registered” errors to skip this step:

mi register imputed bmi age_at_diagnosisnmi register regular female hospital_id

mi register imputed marks variables that contain missing values mi impute will fill in. mi register regular is optional but good practice — it explicitly marks fully-observed variables you plan to use as predictors in the imputation model or analysis model, which makes Stata flag it if one of them unexpectedly turns out to have missing values later.

Chained vs. monotone vs. mvn imputation

mi impute supports several different algorithms, and picking the wrong one for the missingness pattern is a real, common mistake:

• mi impute chained — fully conditional specification (FCS), sometimes called “imputation by chained equations” (the same method the standalone ice command implemented before mi absorbed it). Each variable with missing values gets its own conditional regression model, specified separately, and Stata cycles through them iteratively. This is the right default for an arbitrary (non-monotone) missing-data pattern, and the only built-in method that lets you mix model types — regress for a continuous variable, logit for a binary one, ologit for an ordinal one — in the same run:

  mi impute chained (regress) bmi age (logit) smokes = female hsgrad attack, add(20) rseed(12345)

• mi impute monotone — for a monotone missing pattern specifically (if variable B is missing, every variable after it in a fixed order is also missing, as in some longitudinal dropout designs). Faster and doesn’t need the iterative cycling chained does, but it will produce nonsense on a genuinely arbitrary pattern, so confirm the pattern is actually monotone first (misstable patterns is the usual check) before reaching for it over chained.
• mi impute mvn — multivariate normal data augmentation. Imputes several continuous variables jointly under a multivariate normal assumption, rather than one conditional model per variable. Handles arbitrary missing patterns like chained does, but assumes joint normality across all the imputed variables at once, which chained does not require.

For a single variable with a simple missingness pattern, univariate methods work directly with any of the multivariate commands’ single-variable syntax — regress and pmm (predictive mean matching) for continuous variables, logit for binary, ologit for ordinal, mlogit for unordered categorical, poisson/nbreg for counts, and truncreg/intreg for truncated or interval-censored outcomes.

The add() option sets how many imputed datasets to create — add(20) above creates 20. See How Many Imputations Do You Need? for how to choose that number rather than defaulting to a round figure; Stata will run whatever m you specify without warning you it’s too low for your fraction of missing information.

Pooling results with mi estimate

Once the imputed datasets exist and the data are mi set, run the analysis model through mi estimate instead of running the estimation command directly:

mi estimate: regress outcome bmi age female hospital_id

Stata fits regress separately on each of the m imputed datasets, then combines the m sets of coefficients and standard errors into one pooled result using Rubin’s rules — the pooled coefficient is the simple average across imputations, but the pooled standard error also incorporates the between-imputation variance (how much the estimate itself moved from one imputed dataset to the next), not just the within-imputation sampling variance each individual model reports. That is the entire statistical point of running multiple imputations rather than one: a single imputed dataset’s standard errors are too small because they treat the filled-in values as if they were observed with certainty.

Two options worth knowing:

• mi estimate, dftable and mi estimate, vartable — show the per-coefficient degrees of freedom (with the Barnard-Rubin small-sample correction Stata applies by default) and the relative variance increase / fraction of missing information for each parameter, rather than just the final pooled table. A parameter with a high fraction of missing information relative to its degrees of freedom is a signal the imputation model for that variable may need more predictors, not just more imputations.
• mi estimate, post — posts the pooled coefficients and VCE back into e() in the usual way, so command-specific postestimation tools (margins, lincom, test) work on the pooled result exactly as they would after a single-dataset model.

Common mistakes

• Running the analysis model on _mi_m == 1 alone, or with bysort _mi_m: regress ..., instead of mi estimate. This produces a result for one imputed dataset (or a set of separate, unpooled results), not the correctly-combined estimate Rubin’s rules require — the whole reason to impute multiple times is lost if the results are never pooled.
• Including the outcome variable as a predictor for imputing itself, or omitting the outcome from the imputation model entirely. Either produces biased imputations for other variables; the outcome should generally be included as a predictor in the imputation models for other missing predictors, precisely because it carries real information about them, even though it is never itself the target of imputation in that model.
• Not setting rseed(). mi impute is stochastic — without a fixed seed, re-running the same command produces different imputed values and a slightly different pooled result each time, which makes the analysis non-reproducible.
• Forgetting mi register regular for fully-observed predictors used only in the imputation model, then later finding out mid-analysis that one of them had missing values Stata never flagged as a problem.

Frequently asked questions

What’s the difference between mi impute and the old ice command?

ice was a user-written command implementing chained-equations imputation before Stata built native multiple-imputation support into mi. mi impute chained is the built-in, officially supported successor covering the same method; new work should use mi impute chained rather than ice, which is no longer actively maintained.

Can I use mi impute with survey weights or a complex design?

Yes — declare the survey design with svyset before or after mi set, then run the analysis step as mi estimate: svy: regress ... (nesting svy inside mi estimate, not the reverse). The imputation step itself (mi impute) does not take survey-design options; only the analysis model does.

Does it matter whether I impute before or after mi set?

mi set has to come first — mi register and mi impute both require the dataset to already be declared as an mi dataset, and will error if it isn’t.

See also: Propensity Score Matching in Stata and Mann-Whitney (ranksum) Test in Stata for the same command-level-detail treatment of other Stata procedures, and Propensity Score Matching: How It Works and What It Cannot Fix and Handling Missing Values in SPSS for the equivalent methodology and software-specific treatments elsewhere on this site.