Posts

Featured Post

7 Mistakes in LB Unit Conversion That Still Show Up in SDTM

-
7 Mistakes in LB Unit Conversion That Still Show Up in SDTM | StudySAS LB unit conversion is not hard to understand. The variable definitions are clear. The model is well-documented. And yet unit-related problems remain among the most common issues in SDTM submissions — not because teams do not know the rules, but because the failures are quiet. Nothing crashes. The dataset looks valid. Pinnacle 21 returns a clean report. Then a reviewer runs a simple cross-tabulation and finds creatinine flagged HIGH at a value that belongs well within the normal range — because the reference range was never converted to match the standard unit. This post is a close look at seven implementation mistakes, each with enough context and worked examples to make the failure mode visible before it reaches a submission. LBORRES is what was collected. Verbatim. Untouched. LBSTRES* is the standardized representation. One unit per test. LBSTNR* must follow the same unit system as LBSTRES*. T...
Read more

SDTM IG 3.4: SR, OE, LB Domain Expansion, and Revised SUPPDS Assumptions

-
SDTM IG 3.4: SR, OE, LB Expansion, and Revised SUPPDS Assumptions | StudySAS Blog SDTM IG 3.4 was published by CDISC in July 2022 alongside SDTM v2.0. [1] This post focuses on what actually changes programming and submission behavior — written for SDTM programmers and submission leads. If you have been working from 3.2 or 3.3, several of these changes will require updates to domain routing logic, controlled terminology mappings, Define.xml metadata, and SUPPDS population rules that have been stable in company standards for years. This post examines four areas where working programmers face concrete re-mapping decisions: the SR domain and how the IS scope expansion in 3.4 redraws its boundaries, the OE domain as the post-MO home for ophthalmic data, the restructured LB with confirmed new variables and a substantially narrowed scope, and the SUPPDS assumptions v3.4 quietly rewrote. One terminology correction before we start. Several posts and internal notes referenc...
Read more

PMDA SDTM Submission Requirements vs FDA: Where They Actually Diverge

-
Global teams often say, "PMDA and FDA both take SDTM, so one package should work for both." That is only half true. At the model level, the overlap is real. Both agencies expect CDISC-based submissions, SAS XPT v5 transport files, define.xml, and reviewer-facing documentation. But the real question is not whether your SDTM is CDISC-compliant. The real question is this: will the same study package survive both agencies' rule engines, review workflows, and local review habits without late rework? For teams that build for FDA first, the answer is often no, at least not without adjustment. The differences that matter most are not random. They cluster around standards catalog timing, PMDA pre-submission consultation, Japanese text handling, clinical pharmacology traceability, validation behavior, and Japanese date and time conventions. Note: Before any real submission, always recheck the active P...
Read more

Define.xml for SUPPQUAL — Getting QNAM-Level Metadata Right

-
If you have worked on SDTM submissions long enough, you know SUPPQUAL define.xml is where packages start to break down. Not because the data is wrong, but because the metadata does not fully explain what the data represents. This is not a recap of SUPPQUAL structure. This is about how define.xml actually fails in submission and how to fix it before a reviewer points it out. SUPPQUAL is not difficult because of structure. It is difficult because the meaning of the data exists only in define.xml. Table of Contents The SUPPQUAL ItemGroupDef — What the Spec Actually Requires Value-Level Metadata — Why SUPPQUAL Demands It Building QNAM-Level VLM Entries Correctly WhereClauseDef Construction — Mechanics and Traps Origin Tracing for SUPPQUAL Variables Controlled Terminology in SUPPQUAL QVAL — Who Owns the Codelist? Common Submission Rejection Patterns PMDA-Specific Considerations SAS Utility: Gene...
Read more