Reporting Sample Flow and Imputation Outputs

Why Sample Flow and Imputation Counts Belong in the Report

Readers need to know not only how an imputation was run, but also which records and variables it involved. A compact accounting table can answer practical questions: How many records were screened? How many entered the analysis? Which variables were imputed? How many completed datasets were actually retained? Without clear counts, even a technically detailed description can leave the analyzed sample difficult to reconstruct.

This tutorial focuses on reproducible accounting. It does not use counts to explain why values were missing or to assess the adequacy of the imputation. Those are different tasks. A sample-flow table records the sequence of defined data-processing stages; a variable-level table records the observed and missing values before imputation and what happened to each variable; and an output summary records the completed datasets available for subsequent analysis.

Set the Counting Rules Before Making the Table

A count is interpretable only when its unit and stage are clear. The unit might be a person, visit, specimen, or record; these are not interchangeable. For example, 500 people can contribute 620 visits. If the analysis uses one row per visit, reporting “500 observations” would not describe the data supplied to MICE. State whether each count refers to unique participants, records, or another unit, and use that unit consistently within each flow.

Define the starting point and each transition. If a stage removes records, give both the number removed and the rule for removal. When exclusions have multiple reasons, make the categories mutually exclusive or say explicitly that reasons can overlap. Otherwise readers may add overlapping counts and incorrectly expect them to equal the total excluded. For a sequential flow with mutually exclusive exclusions, the basic reconciliation is:

The equality is a useful audit check, not a statistical assumption about the missing-data process. It requires the same unit to be counted on both sides and exclusions to be assigned to the stated transition. Keep counts from different stages separate: the number screened is not automatically the number eligible, and the number eligible is not automatically the number analyzed.

Report Variable Counts and Imputation Roles

The flow table describes units; it does not show how much data were missing in particular columns. For that, report variable-level counts at a specified pre-imputation stage, usually the analysis data supplied to MICE. For each relevant variable, give the number observed and the number missing. If the analysis sample has \(n\) records and each record has either an observed or missing value for that variable, the counts should satisfy:

Also state each variable’s role. An imputation target is a variable for which missing entries are filled in during imputation. A predictor may be used to help impute other variables without itself being imputed. An identifier may be retained for record linkage but excluded from the imputation model. These roles should not be conflated: appearing in the imputation model does not by itself mean that a variable was imputed.

A useful table can include the variable name, observed count, missing count, and role. If a variable has no missing values, reporting it as a predictor or as “not imputed” can make its status clear. If a variable has missing values but was not imputed, state that fact and the analysis decision in neutral, specific terms. Do not let readers infer that every incomplete variable was an imputation target.

Account for the Completed Datasets

A MICE run may be configured to create a requested number of completed datasets, often denoted \(m\). In the report, distinguish the requested number from the number that were actually completed and retained for analysis. If all requested datasets were produced and retained, these counts agree; if not, report the discrepancy and the disposition of incomplete or failed outputs. The number of iterations used to generate imputations is not the number of completed datasets.

Also state the record count in each retained completed dataset. If the workflow is designed to retain every analysis record, the row count should agree with the analysis-sample count. A discrepancy should be investigated and explained, rather than hidden by reporting only a total number of rows after stacking datasets. The stacked total counts repeated representations of the same analysis records across completed datasets; it is not a count of unique participants or records.

Assemble and Audit the Accounting Table

A clear report can use one table for the sample flow and a second for variables and outputs, or a single carefully structured table with separate panels. Combining everything into one undifferentiated list can make the units hard to follow. The following sequence is a practical construction method.

For a final audit, verify that each row’s stage is named, each count has a stated unit, and the variable counts correspond to the same analysis sample described by the flow. Check the arithmetic rather than assuming a table is correct because it looks plausible. If exclusions can overlap, label them accordingly instead of presenting their sum as a unique total. If a completed dataset has fewer records than expected, explain the difference using the actual workflow record rather than silently changing the denominator.

What the Accounting Does—and Does Not—Show

This style of reporting is useful because it supports reproducibility and interpretation of the study’s sample without requiring a reader to reconstruct counts from prose. A flow diagram can make the sequence of inclusions and exclusions visually prominent; a table can give more detail about variable roles and missing counts; a concise narrative can explain unusual decisions. These are complementary presentation choices. Whatever format is used, the same count and definition should not change from one part of the report to another.

Accounting is not a substitute for reporting the implemented workflow, software information, or diagnostics. In particular, counts of missing values do not establish a missingness mechanism, prove that the imputation model is appropriate, or show that the MICE algorithm behaved well. Likewise, a large retained \(m\) does not by itself establish convergence or satisfactory imputation. Those questions require other information and checks; the accounting table should not be asked to answer them.

Common Mistakes

• Adding variable missing counts and calling the sum “people with missing data.” The sum counts missing cells; one record can contribute more than one cell. Report the number of distinct incomplete records only if it was separately counted.
• Reporting only a final sample size. A final count does not reveal the starting population, exclusions, or reasons for exclusions. Show the stages needed to explain how the analysis sample arose.
• Calling predictors imputed variables. A variable can help predict missing values in other variables without having its own missing values filled in. Report predictor and target roles separately.
• Equating iterations, stacked rows, and completed datasets. Iterations are part of the computational procedure; stacked rows count repeated dataset-record pairs; \(m\) counts completed datasets. State each quantity by its proper name.
• Treating a reconciled table as evidence of a valid imputation. Arithmetic checks support accurate accounting, but they do not establish model adequacy, convergence, or a missingness mechanism.