BDS Windowing, Baseline & LOCF

This listing comes from a quality-control review of ADLB, the laboratory analysis dataset, built under the Analysis Data Model, or ADaM, and its Basic Data Structure, BDS. For the demo subject, identified by the study-site-subject key, two albumin records appear. On 2019-05-06 the value is 38.0 grams per litre at analysis day minus two; on 2019-05-17 it is 31.0 at analysis day ten, already carrying a baseline value of 38.0 and a change of minus 7.0. So the question is not arithmetic, it is a decision: which measurement becomes the analysis record, and which record supplies baseline? We answer that with three rule families: visit windowing, the baseline flag ABLFL, and last observation carried forward, LOCF.

A window is simply a day range that decides which collected records land on which analysis timepoint, that is, on which analysis visit, or AVISIT, and its numeric partner, AVISITN. The statistical analysis plan, or SAP, has usually already chosen the strategy, so programming preference does not decide this. The first option, explicit SAP ranges, lists a day range per target visit; it is auditable and your code matches the SAP table, but any gap between the ranges strands records silently. The second, anchor-based edges, computes boundaries per subject from an anchor such as first dose, so it absorbs rolling schedules; one wrong anchor contaminates every downstream window. The third, nearest-visit assignment, gives every record to the closest analysis visit, so nothing is orphaned, yet a very late visit can masquerade as an earlier timepoint.

Analysis Relative Day, or ADY, has no day zero; it jumps from minus one to plus one around the first-dose anchor. The derivation uses Treatment Start Date, or TRT01SDT, and Lab Relative Day, or LBDY: if LBDY is greater than or equal to TRT01SDT, then ADY equals LBDY minus TRT01SDT plus one; otherwise ADY equals LBDY minus TRT01SDT. Write boundary rules once, inclusive on both ends, and document the gap policy; otherwise every window shifts by a day. The canonical grid is DAY 1 at ADY equals 1, WEEK 2 for 2 to 11, WEEK 4 for 12 to 25, WEEK 6 for 26 to 39, and WEEK 8 for 40 to 60. Out-of-window records stay in the dataset unflagged, and the albumin screening row has LBDY -2, so it is pre-dose and belongs to screening, not an on-treatment window.

When a scheduled visit and an unscheduled recheck land together, you have two records in one window, and your Statistical Analysis Plan (SAP) must name the single winner: last record, first record, worst value, or nearest to target day. That winner receives Analysis Record Flag 01 (ANL01FL) equal to "Y", while the losing records remain in the dataset with the flag off. Do not silently drop them; an unscheduled record may fill an empty window only if a separate SAP sentence allows it, and if that sentence is missing, log a query. Also, do not de-duplicate just to avoid a duplicate Unique Subject Identifier (USUBJID)-Parameter Code (PARAMCD)-Analysis Visit Number (AVISITN) key downstream. Remember that Baseline Record Flag (ABLFL) names the baseline source, while ANL01FL names the analysis record, and both flags can sit on the same row.

This checkpoint tests three Analysis Data Model (ADaM) windowing rules: strategy selection, Analysis Day (ADY) boundary arithmetic, and choosing a winner when a window holds two records. For the first question, before creating ADaM analysis visit windows, you must choose a strategy that best safeguards against stranded records; the correct answer is B, define target-based windows and include a documented fallback mapping for eligible records that fall outside every window. That target-based fallback preserves eligible source records and supports reproducible analysis, unlike fixed calendar windows, exact nominal-day matches, or first-encounter processing. For the second question, which statements about ADY convention and inclusive analysis window boundaries are correct; the correct answers are A, B, and C. Under the no-day-zero convention ADY is never zero, an anchor or reference date maps to ADY=1, the day immediately before maps to ADY=-1, and inclusive boundaries treat the lower and upper declared ADY bounds as eligible values. For the third question, if an analysis window contains two candidate records for the same subject, parameter, and Analysis Visit (AVISIT), and Analysis Flag 01 (ANL01FL) can be assigned to only one record for the primary analysis, the correct answer is B: select the record whose ADY is closest to the visit window target, applying a pre-specified tie-breaker if necessary. That winner rule best represents the target analysis time point, whereas input order is not a stable or statistically meaningful basis for selection.

Here we compare what the Laboratory domain, or LB, collected with what the Laboratory Analysis Dataset, or ADLB, actually keeps. In the Study Data Tabulation Model, or SDTM, the demo subject has four screening results, including albumin at 38.0 grams per liter. One LB row, LBALL at CYCLE 1 DAY 1, is NOT DONE, so it never becomes an Analysis Data Model, or ADaM, row. In ADLB, that albumin row carries a Baseline Flag, or ABLFL, of Y, with a later value of 31.0 and a Change from Baseline, or CHG, of minus 7.0. Notice the Analysis Relative Day, or ADY, of 10 is labeled UNSCHEDULED 4.01, even though it falls inside a statistical analysis plan window. So derive the Analysis Visit, or AVISIT, from window rules, never from the collected visit label.

This next exercise is hands-on on the website at jaimeyan.com/learn, not in the video. You will practice assigning Analysis Visit, or AVISIT, from Analysis Day, or ADY, by typing or arranging the select-when blocks in the canonical order and applying that logic to real rows from the extract. After the video, try it yourself and check your Analysis Visit Number, or AVISITN, assignments against the window table before any analysis flag is set.

Baseline is not the Analysis Visit (AVISIT) label BASELINE; the Baseline Flag (ABLFL) keys on date relative to a first-dose anchor, usually Treatment Start Date (TRT01SDT). Your Statistical Analysis Plan (SAP) names one of three families: last non-missing on or before first dose, pre-dose only, or per-parameter exceptions, recorded in the spec with its section number. In the classic idiom, sort by Unique Subject Identifier (USUBJID) and Parameter Code (PARAMCD) with descending Analysis Relative Day (ADY), then keep the first non-missing Analysis Value (AVAL). For the real ALB row check, AVAL 38.0 at ADY -2 is the last non-missing qualifying record, so it supplies the baseline value; the ADY 10 record with AVAL 31.0 yields Change from Baseline (CHG) of -7.0. Keep the flagged baseline record; deleting it breaks listings, and the tiebreak belongs in the spec, not a comment.

Last Observation Carried Forward, or LOCF, fills a missing analysis timepoint with the last observed value, and the derived row carries a derivation type flag, DTYPE, set to LOCF. That flag, with locffl set to Y, keeps the carried value visible; the disguise is never hidden. Three rules travel with any carry-forward: window first, stop where the Statistical Analysis Plan, or SAP, stops, and keep carried rows out of observed-data listings so table counts reconcile by DTYPE. Canonical snippet 05 retains lastval across the unique subject identifier, USUBJID, and parameter code, PARAMCD, and sets locffl to Y on every carried value. For quality control, or QC, proc freq on locffl with missing counts every carried row; LOCF must never create values for a subject with no post-baseline data, and thin-table imputation is the analyst's decision.

Here are the five listings reviewers run first; each catches what structural checks miss. First, duplicate analysis records inside one analysis window: run PROC FREQ or NODUPKEY on the Unique Subject Identifier, Parameter Code, and Analysis Visit Number key to expose two winners in one window. Second, late baseline: list rows with Baseline Flag, ABLFL, equal to Y and Analysis Date, ADT, after Treatment Start Date, TRT01SDT, which usually means a same-day dose with a missing time component. Third, Last Observation Carried Forward, LOCF, past discontinuation without Statistical Analysis Plan backing; fourth, a carried value counted as observed, so cross-tab Derivation Type, DTYPE, against table populations to reconcile the Ns. Fifth, records stranded between analysis windows. Each listing runs in seconds; structural validation cannot catch these.

This checkpoint quiz has four questions on baseline flags, derivation types, and review-ready Basic Data Structures (BDS). In an Analysis Data Model (ADaM) BDS laboratory dataset, the Baseline Record Flag (ABLFL) marks the reference measurement, and the statistical analysis plan (SAP) defines baseline as the last valid pre-dose assessment free of visible study-drug influence. The correct answer is C: set ABLFL='Y' only on the latest pre-dose record with a non-missing numeric result that is not identified as study-drug influenced, because ABLFL must point to the single best record satisfying that baseline definition. For the next question, when a Last Observation Carried Forward (LOCF) value fills a missing post-baseline analysis row in an ADaM BDS dataset, the correct practices are A and C: set the Derivation Type (DTYPE) variable to 'LOCF' on the target row while leaving the observed source row's DTYPE unchanged, and during Quality Control (QC) rebuild the target value from the same subject, same analysis-parameter code and number, and the latest preceding non-missing analysis value at or before the target timepoint. That is because LOCF is an explicit derivation, so only the imputed target row gets DTYPE='LOCF', and QC must recreate the carried value from its source. For the short-answer question, before Study Data Tabulation Model (SDTM) and ADaM datasets are released, a model answer names at least four reviewer checks on every BDS build—for example, a duplicate-record listing using Unique Subject Identifier (USUBJID), parameter code (PARAMCD), and Analysis Visit (AVISIT); a baseline-flag listing using ABLFL, USUBJID, and Analysis Day (ADY); a LOCF carried-row check using DTYPE, USUBJID, and PARAMCD; and an analysis-flag check using Analysis Record Flag 01 (ANL01FL)—and explains that ABLFL marks the single baseline reference measurement within subject and parameter, while ANL01FL selects rows for a planned set of analyses. For the final question, when a reviewer checks a BDS that supports a change-from-baseline analysis, the correct distinction is D: ABLFL marks the measurement used as the baseline reference for a subject and analysis parameter, while ANL01FL selects the rows that will be included in a planned analysis. That is because ABLFL is a within-subject, within-parameter reference flag for a single baseline measurement, whereas ANL01FL is a row-selection flag that can include or exclude baseline depending on the statistical analysis plan.

The Statistical Analysis Plan, SAP, owns windowing, baseline, and imputation; you transcribe with citations, and silence becomes a logged query. Foundations: inclusive Analysis Day, ADY, bounds written once with no day zero; Baseline Flag, ABLFL, names BASE while Analysis Record Flag, ANL01FL, names analysis rows; Last Observation Carried Forward, LOCF, is always a Data Type, DTYPE, marked and cited rule. Keep the window table in metadata: one row per analysis visit with Analysis Visit, AVISIT, Analysis Visit Number, AVISITN, ADY bounds, winner rule, and SAP section; code reads it and define.xml generates from it. For agents, make them print implemented rules with citations, then diff against the SAP before reading code; fabricated boundary rules do not survive a diff. This pairs with the bootcamp source guide on visit windowing, baseline, and LOCF.