Posts

Featured Post

PMDA SDTM Submission Requirements vs FDA: Where They Actually Diverge

StudySAS Blog | SDTM Programming | Regulatory Submissions 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. ...

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...