A dataset becomes useful for analysis when its records, variables, and metadata support the intended statistical question. Renaming columns or adding analysis flags is not sufficient. The central task is to make decisions explicit enough that the intended result can be produced consistently and reviewed independently.
CDISC ADaM provides the analysis data framework. The working practices below concern how teams translate a statistical plan into an understandable analysis package.
1. Define the analysis unit
Before deriving a variable, identify whether one record represents a participant, a participant at a visit, an event, or another analysis unit. State the keys expected to be unique. A duplicate participant-visit record can be a legitimate repeated assessment or an unintended consequence of joining source tables; the dataset structure alone will not resolve the question.
For a hypothetical repeated laboratory endpoint, specify how unscheduled assessments interact with scheduled visits. Decide which observation is selected when two values fall within a window, how ties are resolved, and whether selection differs across analyses. These rules belong in controlled specifications.
2. Make flags explainable
Population membership and analysis selection flags should have clear definitions and testable consequences. For each flag, identify its inputs and review edge cases: partial dosing, missing baseline, a protocol deviation, or an assessment after rescue treatment. Do not allow a convenient default to silently become a statistical policy.
ICH E9(R1) helps anchor the treatment-effect question. An analysis population, handling of intercurrent events, and missing-data assumption must be considered together, rather than inferred from whichever records happen to remain after filtering.
3. Preserve derivation evidence
For important derived values, retain enough information to explain the result at record level. A baseline value should be connected to its contributing assessment; a change-from-baseline result should identify both components. More complicated derivations need specifications and implementation references in addition to source identifiers.
The CDISC traceability examples are useful reading for this problem. Our recommendation is to select several clinically important records and walk backwards from analysis value to source observation. Include examples that exercise exceptions, not only the simplest participant.
4. Test readiness through outputs
A dataset review is incomplete until representative outputs are generated. Check denominators, missing categories, visit labels, treatment assignments, and parameter ordering against the plan. An analysis dataset may be structurally sound while encouraging the wrong aggregation in a downstream program.
Use a small acceptance suite of representative tables and participant-level checks. Keep expected behavior independently documented, so tests do not merely repeat the derivation code. Separate unresolved statistical questions from programming defects; they require different owners.
Analysis readiness is demonstrated when a qualified colleague can understand and implement the intended analysis from the package. It is not demonstrated by a successful file export or by the absence of validation messages alone.
A worked selection check
Suppose a hypothetical analysis window contains assessments on days 27 and 29, with day 28 as its target. If the approved rule selects the closest assessment and then the later assessment on a tie, day 29 is selected. Reverse the tie rule and the selected record changes without any source value changing. That is why window boundaries, distance calculation, and tie-breaking belong in the specification.
For each selected record, retain the actual day, assigned analysis visit, selection flag, and relevant source identifier. Check uniqueness at the intended participant–parameter–analysis-visit level. Test an observation exactly on each boundary and two equidistant observations. Then check that the output program uses the intended selection flag rather than aggregating every eligible record.
The acceptance criterion is the independently specified behavior, not agreement with a second copy of the same selection function.
