sdtm validation clinicalprogramming sas cdisc fda The Demographics Dilemma: Mapping Re-Screenings and Multiple Enrollments via the New SDTM DC Domain July 13, 2026 ClinPilot Insights Any programmer who has sat through a late-stage validation cycle knows the sheer panic of seeing thousands of orphaned laboratory or vital signs records. It usually happens because a patient screen-failed, waited out a temporary exclusion window, re-screened under a new ID, and successfully enrolled. For years, the industry was stuck in a mapping deadlock. The Study Data Tabulation Model Implementation Guide (SDTMIG) strictly dictated that the Demographics (DM) domain must contain exactly one record per unique subject identifier (`USUBJID`). If you mapped both screening attempts as separate rows in DM, your validation engine flagged it as a critical error. If you deleted the first failed attempt to satisfy DM's one-row-per-subject constraint, you orphaned the laboratory tests, physical exams, and eligibility data collected during that first attempt. To bridge this gap, the FDA Study Data Technical Conformance Guide (TCG) recommended placing supplemental or failed screening records in a custom "demographics-like" domain. This custom fix led to years of compliance friction. Lacking a standard model, programmers built bespoke custom domains like `ZDM` or `XDM`. Validation tools had no baseline metadata for these structures, triggering warnings such as "Dataset class not recognized" or flagging the use of subject identifier (`SUBJID`) in non-DM domains. The release of SDTM v3.0 and SDTMIG v4.0 officially introduced the **Demographics for Multiple Participations (DC)** domain. Developed by the CDISC Submission Data Standards (SDS) Multiple Subject Instances (MSI) team, the DC domain provides a standardized repository to capture every distinct participation event—screen failures and enrollments alike—while keeping DM clean, standardized, and limited to one record per subject. ## The Structural Mechanics of DM and DC Under the new paradigm, `DM` and `DC` work in tandem. * **Demographics (DM):** Still restricted to exactly one record per human being (`USUBJID`). This record represents the *primary* or *active* participation (typically the successful enrollment). If the subject never enrolled and only screen-failed, DM contains their primary screening record. * **Demographics for Multiple Participations (DC):** A standard Special Purpose domain that permits multiple records per `USUBJID`. Every screening attempt, re-screening, and enrollment is logged here as a distinct row, identified by a unique `SUBJID` and distinguished by the date of collection (`DMDTC`). Crucially, SDTM v3.0 elevated `SUBJID` to the "Identifiers for All Classes" metadata table. This subtle change means `SUBJID` is now officially recognized as a permissible variable across all clinical domains (such as `AE`, `LB`, `VS`, and `DS`). You can link events in finding or event domains back to the specific screening or enrollment attempt by populating `SUBJID` alongside `USUBJID`, without triggering conformance errors. ## Designing the Pipeline: A SAS Blueprint The primary programming challenge is taking raw demographics and screening logs from your Electronic Data Capture (EDC) system—which typically records multiple rows for re-screened patients—and split them into compliance-ready `DM` and `DC` structures. The following program demonstrates how to process a raw source dataset containing multiple screening records for a single patient, identify the primary enrollment record for `DM`, and map all participations to the `DC` domain. ```sas /* Step 1: Simulate raw EDC demographics containing multiple participations */ data raw_demog; length usubjid $20 subjid $15 birthdt $10 sex $1 r_site $5 dmdtc $10 status $20; input usubjid$ subjid$ birthdt$ sex$ r_site$ dmdtc$ status$; datalines; US-101-001 101-001 1978-05-12 M 101 2026-01-10 SCREEN_FAILURE US-101-001 101-001R 1978-05-12 M 101 2026-02-15 ENROLLED US-101-002 101-002 1965-11-23 F 101 2026-01-12 SCREEN_FAILURE US-101-003 101-003 1989-08-04 F 101 2026-01-15 ENROLLED ; run; /* Step 2: Establish mapping logic and prioritize the primary record */ /* Enrollment takes priority for DM. If not enrolled, keep the primary screening. */ proc sort data=raw_demog out=sorted_demog; by usubjid descending status dmdtc; run; /* Step 3: Map and output the DM Domain (One record per USUBJID) */ data sdtm_dm(keep=studyid domain usubjid subjid brthdt sex siteid dmdtc arm armcd); set sorted_demog; by usubjid; length studyid $10 domain $2 brthdt $10 siteid $5 arm armcd $20; studyid = "PROT-001"; domain = "DM"; brthdt = birthdt; siteid = r_site; /* Set planned treatment arm variables based on enrollment status */ if status = "ENROLLED" then do; arm = "Active Treatment"; armcd = "ACTIVE"; end; else do; arm = "Screen Failure"; armcd = "SCRNFAIL"; end; /* Output only the prioritized primary participation record */ if first.usubjid; run; /* Step 4: Map and output the DC Domain (All participations) */ data sdtm_dc(keep=studyid domain usubjid subjid brthdt sex siteid dmdtc status); set raw_demog; length studyid $10 domain $2 brthdt $10 siteid $5; studyid = "PROT-001"; domain = "DC"; brthdt = birthdt; siteid = r_site; /* All collected instances are written to the DC domain */ output; run; ``` ### Key Mapping Considerations 1. **Date Derivations:** When deriving relative study days (`--DY`) in parent domains, ensure your date logic is relative to the correct reference start date (`RFSTDTC`) associated with that specific participation. In cases of multiple screenings, your utility macros must leverage both `USUBJID` and `SUBJID` as composite join keys to avoid assigning baseline lab evaluations to the wrong screening window. 2. **Controlled Terminology:** The `DC` domain inherits its core controlled terminology from `DM`. However, because it contains multiple participations, variables like actual arm (`ACTARM`) and planned arm (`ARM`) must reflect the status of that specific screening or enrollment record. ## Managing Downstream and Validation Impacts While the implementation of the `DC` domain solves trace integrity issues, it requires adjustments to your downstream validation strategies. ### Pinnacle 21 Validation Engines If you are validating your package using older Pinnacle 21 engines, the software may not fully recognize the metadata rules for the newly introduced `DC` domain. You might encounter `SD9999` (Dataset class not recognized) or `SD0058` (Variable appears in dataset, but is not in SDTM model) warnings for populating `SUBJID` in finding domains like `LB` or `VS`. These warnings are typical when using transitional validation profiles. To address them: * Verify that your Pinnacle 21 validation configuration is aligned with the SDTMIG v4.0 standards. * If your target regulatory agency has not fully updated its automated validation engines to match the latest CDISC release, you must document this structural approach in your Study Data Reviewer’s Guide (SDRG). Use Section 3.3 (Data Conformance Summary) to explain that the `DC` domain and the inclusion of `SUBJID` across findings domains are modeled in strict alignment with CDISC SDTMIG v4.0 and the FDA TCG to maintain complete clinical traceability for re-screened subjects. ### ADaM and Traceability In ADaM, the Subject-Level Analysis Dataset (ADSL) remains structurally aligned with the `DM` domain, maintaining one record per `USUBJID`. However, you can read the comprehensive screening history from `DC` to derive critical safety baseline parameters, such as total screening attempts, duration of washout periods, or safety events that occurred during failed screening windows. By standardizing this mapping process, you protect your clinical data pipelines from manual validation overrides and ensure that every clinical observation, regardless of when it was collected, remains auditable and fully traceable. 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
