sdtm adam validation sas cdisc baseline Retiring --BLFL Without Breaking Baseline: Rebuilding SDTM Findings for --LOBXFL July 28, 2026 ClinPilot Insights SDTM’s baseline flag has always carried more weight than one character variable should. `--BLFL` looks harmless. Set it to `Y`, leave the other rows blank, move on. Except the word *baseline* depends on the protocol, SAP, endpoint, treatment period, parameter, visit-window rules, and sometimes a committee decision made after the SDTM specification was signed off. That’s analysis logic wearing an SDTM badge. The proposed SDTMIG v4.0 direction removes `--BLFL` and retains `--LOBXFL`, the Last Observation Before Exposure Flag, in Findings domains. That’s a cleaner separation. SDTM identifies a reproducible pre-exposure observation. ADaM identifies the record used as baseline for a stated analysis. They may be the same record. They don’t have to be. One correction before anyone starts deleting columns: SDTMIG v4.0 isn’t final yet. CDISC currently lists it as resolving public-review comments, with publication projected for 2027. Existing studies must still follow their declared SDTMIG version and the regulator-supported version in force for that submission. Don’t retrofit a draft rule into a locked study because somebody updated the corporate macro library on Friday afternoon. We’ve all seen how that ends. ## `--LOBXFL` Isn’t a Renamed Baseline Flag For a domain such as LB, `LBLOBXFL = "Y"` identifies the last non-missing result before the subject’s exposure reference datetime. In the current model description, that reference is `DM.RFXSTDTC`. The operative pieces are: - The result must be non-missing. - The assessment occurs before exposure. - Selection is made within the relevant Findings grouping, not once per subject across the whole domain. - The flag contains `Y` or null, not `Y` and `N`. - Datetime precision must support the comparison being claimed. `LBBLFL`, by contrast, says a record is baseline. That sounds similar until the SAP defines baseline as the average of two predose samples, the last scheduled predose assessment, the value before each treatment period, or a central-lab result chosen ahead of a local-lab result. `--LOBXFL` can’t express all of that. It isn’t supposed to. A useful mental split is: | Question | Proper layer | |---|---| | What was the last non-missing observation before first exposure? | SDTM `--LOBXFL` | | Which observation or derived value does this analysis call baseline? | ADaM `ABLFL`, `BASE`, and possibly `BASETYPE` | | How was baseline selected or calculated? | ADaM metadata and analysis programming | | Why did the analysis baseline differ from the SDTM pre-exposure observation? | Traceability metadata and, when needed, reviewer documentation | Once that boundary is explicit, a lot of ugly conditional code disappears. ## First Fix the Exposure Anchor The usual macro assumes `RFSTDTC` is good enough. It isn’t the stated anchor for `--LOBXFL`. `RFSTDTC` represents the subject reference start. `RFXSTDTC` represents the first study treatment exposure. Those dates can differ. Run-in periods, screening procedures, delayed dosing and randomized-but-never-treated subjects make that difference visible very quickly. Parse `RFXSTDTC` only when enough precision exists for the required comparison. ```sas data dm_anchor; set sdtm.dm(keep=studyid usubjid rfxstdtc); length rfxstdtm 8; format rfxstdtm e8601dt.; if prxmatch('/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}(:\d{2})?$/', strip(rfxstdtc)) then rfxstdtm = input(strip(rfxstdtc), e8601dt.); run; ``` That code deliberately doesn’t impute a missing time. Quietly converting `2026-05-14` to midnight and then calling a 07:30 sample “post-exposure” is fabricated ordering. If the source supports date only, route the subject and parameter through a documented policy. Possible outcomes include leaving the flag blank, using a date-level comparison only where ordering remains certain, or obtaining a better exposure timestamp. No mystery defaults buried in `%sysfunc(inputn())`. Please. ## Derive the Flag at the Right Grain The selection group must reflect the domain’s test identity and relevant qualifiers. For LB, that often means `USUBJID`, `LBTESTCD`, specimen, method and fasting status. The exact key depends on the data. If you group only by `USUBJID` and `LBTESTCD`, a serum central-lab result can wipe out a plasma local-lab result because it happened five minutes later. The code will run beautifully. The output will be wrong. Here’s a restrained SAS pattern for full datetimes: ```sas proc sql; create table lb_candidates as select a.*, b.rfxstdtm, input(a.lbdtc, e8601dt.) as lbdtm format=e8601dt. from sdtm.lb as a left join dm_anchor as b on a.studyid = b.studyid and a.usubjid = b.usubjid where not missing(a.lbstresc) and prxmatch('/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}(:\d{2})?$/', strip(a.lbdtc)) and not missing(b.rfxstdtm); quit; proc sort data=lb_candidates; by studyid usubjid lbtestcd lbspec lbmethod lbfast lbdtm lbseq; run; data lb_pick(keep=studyid usubjid lbseq); set lb_candidates; by studyid usubjid lbtestcd lbspec lbmethod lbfast lbdtm lbseq; if lbdtm < rfxstdtm; if last.lbfast then output; run; proc sql; create table lb_final as select a.*, case when not missing(b.lbseq) then 'Y' else '' end as lblobxfl length=1 from sdtm.lb as a left join lb_pick as b on a.studyid = b.studyid and a.usubjid = b.usubjid and a.lbseq = b.lbseq; quit; ``` A few details matter here. The comparison is strict: `LBDTM < RFXSTDTM`. A record at the exact exposure datetime isn’t demonstrably before exposure. `LBSTRESC` is used to establish a non-missing standardized result. Your implementation may need more specific handling for character versus numeric findings, “NOT DONE” records, or domain-specific result conventions. `LBSEQ` breaks exact datetime ties. That makes the result deterministic, but it doesn’t make the clinical choice correct. If duplicate qualifying rows share a timestamp, write them to an exception dataset and review the distinguishing qualifiers. Sequence number should be the last technical tie-breaker, not the first business rule. And check the sort logic carefully. SAS `LAST.` processing follows the complete BY hierarchy; if you change the key, rerun tie and cardinality tests. One extra qualifier can change which row receives the flag. ## Don’t Copy `--LOBXFL` Straight into `ABLFL` This is the bit that causes the most damage. FDA’s technical conformance guidance says ADaM datasets should be derived from SDTM. It doesn’t say every ADaM analysis flag must copy the similarly named SDTM flag. ADaM exists to support the actual analysis with clear derivations and traceability. Suppose the SAP defines baseline systolic blood pressure as the mean of three predose readings. SDTM may mark the third reading as `VSLOBXFL = "Y"` because it’s the last non-missing observation before exposure. ADaM may instead create a derived mean record and flag that: ```sas proc sql; create table predose_mean as select studyid, usubjid, vstestcd, mean(vsstresn) as aval, max(input(vsdtc, e8601dt.)) as adtm format=e8601dt. from sdtm.vs where vstestcd = 'SYSBP' and vsstresn is not missing and vstptnum in (1, 2, 3) group by studyid, usubjid, vstestcd; quit; data advs_baseline; set predose_mean; length paramcd $8 avisit $20 dtype $8 ablfl $1; paramcd = 'SYSBP'; avisit = 'Baseline'; avisitn = 0; dtype = 'AVERAGE'; ablfl = 'Y'; base = aval; run; ``` Here, no single SDTM row is the analysis baseline. That’s fine. The source readings remain traceable, and the ADaM derivation explains the mean. Another common case is repeated treatment periods. `--LOBXFL` is tied to first exposure, while analysis may require period-specific baselines. `BASETYPE` can distinguish those baseline definitions in a BDS dataset. Trying to make one SDTM flag represent four period baselines is how specifications acquire comments longer than the derivation itself. ## Build the Transition as a Metadata Change Don’t solve this with a global string replacement from `BLFL` to `LOBXFL`. The variable names are different because the concepts are different. A proper standards update touches: - Domain metadata and controlled terminology assignments - Source-to-SDTM mapping specifications - Reusable derivation macros - Define-XML origins and comments - SDTM reviewer’s guide text - ADaM baseline derivations - Unit tests and independent QC programs - Validation configuration by SDTMIG version - Legacy-study exceptions Run both derivations in a comparison environment before switching any production output. ```sas proc sql; create table flag_diff as select studyid, usubjid, lbtestcd, lbspec, lbseq, lbblfl, lblobxfl from lb_transition where coalescec(lbblfl, '') ne coalescec(lblobxfl, ''); quit; ``` Those differences aren’t automatically defects. They’re your test inventory. Classify them: analysis-defined baseline, missing exposure time, derived baseline average, repeated period, qualifier mismatch, no non-missing predose result, or actual programming error. That classification gives standards leads something auditable instead of a spreadsheet full of unexplained red cells. ## Validation Needs Version Awareness CDISC already changed the core status of `--BLFL` to Permissible in Findings domains where `--LOBXFL` became Expected. Its published SDTMIG v4.0 scope goes further: `--BLFL` is slated for removal because baseline flags belong in ADaM. Validators don’t interpret intent. They execute rule packages against a selected standard version. Pinnacle 21 has documented that the old SD0006 baseline check was retired for SDTMIG v3.3 and later when `--BLFL` isn’t included, with separate checking expected for `--LOBXFL`. If a team runs an older rule configuration against newer metadata, it can spend days explaining warnings created by its own setup. Been there. Very little joy in that meeting. Pin these items in every validation run: - SDTM and SDTMIG versions - Controlled Terminology date - Validator and engine version - Agency rule package - Define-XML version - Date and checksum of the submitted files Treat an unexpected `--BLFL` warning as a version question first. Don’t add a deprecated variable merely to silence a validator configured for the wrong IG. ## The QC Checks Worth Keeping Row-by-row double programming isn’t enough here. Add assertion-style checks. - No `--LOBXFL = "Y"` record has a missing standardized result. - Every flagged datetime is strictly before `RFXSTDTC`. - There is at most one flag per declared selection group. - Every selected row is the latest qualifying row in that group. - Partial or ambiguous datetimes appear in an exception report. - Exact-time ties appear in an exception report. - Untreated subjects aren’t assigned a flag against an invented exposure datetime. - Define-XML describes the operational derivation and grouping variables. - ADaM baseline records follow the SAP rule even when they differ from `--LOBXFL`. - The selected validation package matches the declared standard. The payoff isn’t just a quieter validation report. It’s a traceability chain that says what each layer actually did: SDTM identifies the observation before exposure; ADaM identifies or derives the analysis baseline; metadata explains the difference. That separation is overdue. Recommended Insights sdtm define-xml validation Stop Hand-Coding VLM: Compile CDISC Dataset Specializations into Study Metadata Compile CDISC Dataset Specializations into governed study VLM before test codes, units, origins, and codelists drift apart. Jul 28, 2026 Read More sdtm clinicalprogramming sas RELREC That Reviewers Can Follow: Linking PR, TU, TR, and RS for RECIST 1.1 Build reviewer-readable links across scans, lesions, measurements, and RECIST 1.1 responses without relying on dates or sequence numbers. Jul 28, 2026 Read More
sdtm define-xml validation Stop Hand-Coding VLM: Compile CDISC Dataset Specializations into Study Metadata Compile CDISC Dataset Specializations into governed study VLM before test codes, units, origins, and codelists drift apart. Jul 28, 2026 Read More
sdtm clinicalprogramming sas RELREC That Reviewers Can Follow: Linking PR, TU, TR, and RS for RECIST 1.1 Build reviewer-readable links across scans, lesions, measurements, and RECIST 1.1 responses without relying on dates or sequence numbers. Jul 28, 2026 Read More
