ADaM BDS: Building ADLB & ADVS

Picture an afternoon quality control, QC, listing: a change-from-baseline, CHG, table shows a mean shift in a vital sign nobody expected to move. The cause is a flag, not arithmetic. For eleven subjects, the baseline value, BASE, came from the first record — a screening value — while the Statistical Analysis Plan, SAP, says the last value on or prior to first dose. ABLFL, the baseline flag, picked the wrong record, and every CHG table inherited it. By the end you can read the Basic Data Structure, BDS, grain, build AVAL, PARAM, BASE and CHG, window visits, and set ABLFL and ANL01FL. Then ADVS and ADLB — vital signs and laboratory — both Analysis Data Model, ADaM, datasets. Agenda: BDS skeleton, the baseline rule, ADVS step by step, ADLB extras, QC checkpoints, then practice on the demo study records.

Basic Data Structure, BDS, is a grain contract: one record per subject, parameter, and analysis timepoint. Duplicate that Unique Subject Identifier, Parameter Code, Analysis Visit Number key—USUBJID, PARAMCD, AVISITN—and downstream summaries double-count. The demo subject's Body Surface Area, BSA, row shows PARAMCD as the code and PARAM as the output label. Analysis Value, AVAL, is 2.08; Analysis Day, ADY, is 1; AVISITN is 2.0; Baseline Flag, ABLFL, is Y; Baseline Value, BASE, is 2.08; Analysis Flag 01, ANL01FL, is Y. Derivation Type, DTYPE, is absent because this is a collected row, not a derived assumption. Remember Subject-Level Analysis Dataset, ADSL, stays one row per subject, Occurrence Data Structure, OCCDS, is one row per occurrence, while BDS datasets merge treatment variables onto every row.

Baseline is a Statistical Analysis Plan decision: last non-missing value on or prior to first dose. It keys on date relative to Treatment Start Date, or TRT01SDT, not a visit label like SCREENING. Sort by Unique Subject Identifier, or USUBJID, Parameter Code, or PARAMCD, descending Analysis Day, or ADY, then keep the first non-missing Analysis Value, or AVAL: if first.PARAMCD and AVAL is non-missing, then Baseline Flag, or ABLFL, equals Y. That row earns ABLFL equals Y; baseline value, or BASE, copies to every subject-parameter record, and Change from Baseline, or CHG, follows as AVAL minus BASE. In the demo Body Surface Area, or BSA, data, the qualifying row is CYCLE 1 DAY 1, ADY 1, 2019-05-08, not SCREENING with ADY negative 2 and date 2019-05-06, so ABLFL equals Y and BASE equals 2.08 travel to every BSA row.

This checkpoint confirms the Analysis Data Model (ADaM) Basic Data Structure (BDS) grain and the baseline rule before we build datasets. The BDS grain question asks which variables uniquely identify a row, and the correct answer is C: one Unique Subject Identifier (USUBJID), one Parameter Code (PARAMCD), and the analysis-timepoint key, such as Analysis Visit Number (AVISITN) or Analysis Day (ADY). USUBJID alone or USUBJID plus PARAMCD alone cannot make a row unique because a subject can have many records per parameter across visits. The baseline question asks which pre-dose record gets the Baseline Record Flag (ABLFL) using the Date of First Dose of Study Drug (TRT01SDT), and the correct answer is B: the record closest to, but not after, TRT01SDT, with the Statistical Analysis Plan (SAP) tie-breaker if records are tied. That matches the date-anchored rule: baseline is the last non-missing assessment before first dose, chosen by assessment date and time, not source order or value. The ABLFL versus Analysis Record Flag 01 (ANL01FL) question has two correct answers, A and B. ABLFL marks one baseline record per subject-parameter, while ANL01FL marks the one or many records selected for a particular analysis.

Here we trace Body Surface Area (BSA) for the demo subject from Vital Signs (VS) to Analysis Dataset Vital Signs (ADVS). Raw VS holds one row per measurement; this subject has five BSA records. Vital Signs Standard Result in Standard Units 2.08 maps to Analysis Value (AVAL) 2.08 at screening, and 2.06 maps to 2.06 at cycle 1 day 8, where Change from Baseline (CHG) is 2.06 minus 2.08, or -0.02. Baseline (BASE) stays 2.08 on every row. The build order is Parameter Code (PARAMCD) with unit, then Analysis Date (ADT) and Analysis Day (ADY) anchored to Treatment Start Date (TRT01SDT), then windowing, then Baseline Flag (ABLFL) and Analysis Flag 01 (ANL01FL). ANL01FL marks rows the analysis uses; unscheduled 4.01 and 4.03 stay in ADVS but unflagged, so a change analysis restricted to that flag will not count them.

ADLB, the Analysis Data Model Laboratory dataset, uses the same Basic Data Structure, or BDS, build as ADVS, the Analysis Data Model Vital Signs dataset, but adds reference-range logic. For demo subject, the raw lab SCREENING row shows 38.0 with limits 35.0 and 52.0, class NORMAL; the ADLB SCREENING row has analysis value 38.0 and baseline 38.0. The ADLB UNSCHEDULED 4.01 row, analysis relative day 10, has value 31.0, baseline 38.0, change negative 7.0. Shift logic compares baseline class to worst post-baseline class against subject's own range: 38.0 is within 35.0 to 52.0, 31.0 is below 35.0, but whether 4.01 enters worst-class is the Statistical Analysis Plan's rule. LOCF, last observation carried forward, rows appear only when the SAP requests them; mark them with DTYPE, derived type, LOCF or LOCFFL, LOCF flag, Y, and audit them so no assumption hides.

Every Basic Data Structure (BDS) build chooses an order: parameters-first derives one parameter code at a time and stacks, fitting few parameters with different logic but risking record-order surprises; rows-first builds the full long set and flags by parameter code, fitting many parameters with shared logic but burying parameter-specific rules. Run five quality control (QC) listing checks as pipeline steps: duplicates on unique subject identifier, parameter code, and analysis visit number; baseline flag equals Y with analysis date after treatment start date; more than one baseline flag equals Y per subject-parameter; baseline absent from final set via anti-join; and recompute change from baseline as analysis value minus baseline value. Structural conformance checking will not catch a wrong baseline, and a baseline off the wrong record makes every change-from-baseline table inherit the error, so baseline flags are checked, not merely computed.

In Statistical Computing Environment, or SCE, Vital Signs Analysis Dataset, or ADVS, and Laboratory Analysis Dataset, or ADLB, build after Subject-Level Analysis Dataset, or ADSL, from locked Study Data Tabulation Model data. The spec owns parameters, windows, and Baseline Flag rules; define.xml comes from same metadata, preventing drift. Quality Control, or QC, is independent double programming, side-by-side listings, plus Clinical Data Interchange Standards Consortium Open Rules Engine, or CORE, structural checks. Structural checks catch a missing parameter or bad variable length, but not a wrong-record baseline—the five QC listings catch that. Agents draft analysis dataset shells, Baseline Flags, and change-from-baseline code, yet invent plausible rules instead of the Statistical Analysis Plan, or SAP, sentence. Ask the agent to state its baseline rule and source, diff that against the SAP, hand-check three subject-parameter listings.

This scene is hands-on, so you will work it on the website at jaimeyan.com/learn rather than watch me click through it. It drills three things: picking the record that earns ABLFL, the Baseline Flag, for the demo subject, reconstructing BASE, the Baseline Value, and CHG, Change from Baseline, and then sorting which rows qualify for ANL01FL, the Analysis Flag 01. Run it right after the video, and let the instant feedback show you why a baseline pulled from the wrong record corrupts every downstream change-from-baseline value.

This final checkpoint verifies integrated understanding of Analysis Data Model (ADaM) Basic Data Structure (BDS) variable roles, baseline and analysis flags, derived-record rules, and Quality Control (QC) arithmetic. For the first question, in the Vital Signs Analysis Dataset (ADVS) and Laboratory Analysis Dataset (ADLB), after windowing the analysis visit is carried by Analysis Visit (AVISIT) and Analysis Visit Numeric (AVISITN), while Analysis Record Flag 01 (ANL01FL) marks the record used in the analysis, so the correct answer is A. Baseline Record Flag (ABLFL) only identifies the baseline record, and Derivation Type (DTYPE) only marks derivations such as Last Observation Carried Forward (LOCF), not visit selection. For the second question, Baseline Record Flag (ABLFL) identifies the record supplying the baseline value, while Analysis Record Flag 01 (ANL01FL) identifies the records included in the analysis, and a row such as UNSCHEDULED 4.01 without ANL01FL equal to Y remains in ADVS or ADLB for traceability but is not selected, so the correct answers are A and B. For the third question, under the study Statistical Analysis Plan (SAP), a Last Observation Carried Forward (LOCF) value is allowed when a scheduled post-baseline analysis visit has no observed measurement and the last available value within the analysis window can be carried forward; the carried value is written to Analysis Value (AVAL) and the record must be marked Derivation Type (DTYPE) equal to LOCF so it is not mistaken for an actual measurement. For the fourth question, with Analysis Value (AVAL) equal to 2.06 and Baseline Value (BASE) equal to 2.08, Change from Baseline (CHG) recomputes as 2.06 minus 2.08 equals minus 0.02, and the QC listing that shows Analysis Day (ADY) or assessment date, Baseline Record Flag (ABLFL), and Date of First Study Treatment (TRT01SDT) would catch an ABLFL equal to Y row whose assessment date is after TRT01SDT, so the correct answer is B.

Before this leaves your desk, lock the grain: one record per subject, parameter, and analysis timepoint — the basic data structure, or BDS, grain. Duplicate-check the subject identifier USUBJID, parameter code PARAMCD, and analysis visit number AVISITN first. Baseline flag ABLFL keys on first treatment date TRT01SDT per the Statistical Analysis Plan, or SAP, and takes the last qualifying non-missing value, never a visit label. LOCF — last observation carried forward — and AVERAGE rows are derived records with derivation type DTYPE, only when the SAP calls for them. Shift tables compare each subject's baseline and post-baseline values against their own reference range; structural checks miss a wrong baseline, but duplicate checks and listings catch it. Next, the subject-level analysis dataset, ADSL, covers the spine every BDS build merges in; then occurrence data structure OCCDS and time-to-event ADTTE.