SDTM IG 3.4: SR, OE, LB Domain Expansion, and Revised SUPPDS Assumptions
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 reference an "ON" domain in the context of SDTM IG 3.4. There is no domain with the two-letter code ON in any version of the SDTMIG. The ophthalmic domain code is OE — Ophthalmic Examinations — introduced in v3.3. Section 9 of v3.4 introduced OI (Non-Host Organism Identifiers) as a Study Reference dataset, not a clinical observations domain. This post uses OE throughout.
SR — Skin Response Domain
SR was introduced in SDTM IG 3.2 as one of eleven new domains in that release.[2] It is a Findings Sub-Class domain — not a general Findings domain and not a Findings About domain.[3] One record per test per visit per subject. It captures dermal responses to antigens typically assessed from skin-prick or intradermal challenge: wheal diameter, erythema diameter, induration size. The structure did not change in v3.4. What changed is the precision of the boundary condition that determines whether data belongs in SR at all.
The Three-Way Routing Decision Formalized in v3.4
The IS scope expansion in v3.4 is the driver here. Under v3.2 and v3.3, the IS domain was scoped narrowly to data from assessments describing whether a study therapy provoked an immune response. Specimen-based immune testing in other contexts ended up in LB or MB depending on version. In v3.4, IS is redefined to cover all specimen-based assessments that measure the presence, magnitude, and scale of an immune response upon any antigen stimulation or encounter — not restricted to study therapy.[4]
That expansion creates a three-way routing that v3.4 defines explicitly for allergy and vaccine programs.[4] First split: is the immune response specimen-based or surface-based? Specimen-based data — anything measured from a collected sample: serum IgE levels, antibody titers from blood or plasma, cellular immune assays from PBMCs — goes to IS. Surface-based responses split further on intent. A wanted, expected localized dermal response to a substance administered to provoke that response goes to SR. A tuberculin PPD skin test wheal is SR. An allergen skin prick test wheal-and-flare is SR. An unwanted, symptomatic allergic reaction — injection-site erythema coded as an adverse event, vaccine reactogenicity — goes to AE or CE.
Specimen-based immune response (serum IgE, antibody titers, ELISPOT, neutralization assays) → IS
Localized surface response, wanted and expected (PPD induration, allergen prick wheal) → SR
Localized surface response, unwanted or symptomatic → AE or CE
SR Domain Structure
The variables that programmers most often underuse or misuse in SR: SRANTREG captures the anatomical region of the test application site — not the general body area. SRLAT (laterality) must be populated for bilateral comparisons. SRCAT captures test category (ALLERGEN PANEL, TUBERCULIN) and SRSCAT the subcategory. When a protocol tests multiple antigen concentrations on the same visit, each concentration generates a separate record. The structure below shows a standard bilateral allergy panel with one NOT DONE record handled correctly:
/* SR — Bilateral allergen panel, one NOT DONE record */
STUDYID DOMAIN USUBJID SRSEQ SRTESTCD SRTEST SRORRES SRSTRESC SRSTRESN SRSTRESU
-------- ------ --------------- ----- -------- ----------------- ------- -------- -------- --------
ABC-001 SR ABC-001-001-01 1 WHEAL Wheal Diameter 12 12 12 mm
ABC-001 SR ABC-001-001-01 2 ERYTHEMA Erythema Diameter 25 25 25 mm
ABC-001 SR ABC-001-001-01 3 WHEAL Wheal Diameter (null) (null) (null) (null)
SRSTAT SRREASND SRANTREG SRLAT SRDTC SRDY VISIT
-------- -------------- ------------ ------ ----------- ---- ------
(null) (null) LEFT FOREARM LEFT 2023-03-15 8 WEEK 4
(null) (null) LEFT FOREARM LEFT 2023-03-15 8 WEEK 4
NOT DONE SUBJECT REFUSED RIGHT FOREARM RIGHT 2023-03-15 8 WEEK 4
What v3.4 Changed for SR in Practice
If your program was routing anti-allergen IgE antibody titers into LB — which was correct under v3.2 and v3.3 for pre-exposure baseline data — those records move to IS under v3.4.[4] SR itself is structurally unchanged, but its boundary with IS is now formally defined in the IG rather than left to interpretation. FDA reviewers are expected to confirm appropriate domain selection when allergy or vaccine data is present in a submission, so your Reviewer's Guide should document the routing decision explicitly.
OE — Ophthalmic Examinations Domain
OE was introduced in SDTM IG 3.3 as one of several body-system Findings domains developed through TAUG work.[5] It was not new in v3.4. What changed in v3.4 is that the MO (Morphology) domain was formally decommissioned, and the IG explicitly directs sponsors to use body-system domains — OE among them — rather than MO for morphological findings data.[1] For ophthalmology programs, this means OE is now the only compliant home for both functional and morphological eye data under v3.4.
What Goes in OE
OE captures structured findings from ophthalmic assessments: visual acuity by Snellen chart or ETDRS letter score, intraocular pressure by Goldmann applanation tonometry or non-contact methods, slit-lamp biomicroscopy findings, fundoscopy results, optical coherence tomography retinal thickness measurements, visual field parameters, color vision test results, and corneal topography. Quantitative and categorical results from any structured ophthalmic examination go in OE.
The Laterality Requirement
This is the most consistent error in OE datasets at submission. OELAT is Expected, not Permissible. Every record must document whether the finding applies to the LEFT eye, RIGHT eye, or BILATERAL. When an assessment is bilateral and results are collected per eye, two records are required — one per laterality value. Reviewers use OELAT to reconstruct the patient-eye-visit trajectory across timepoints. Automated review tools cannot do this when OELAT is missing or inconsistently populated. The example below shows a correctly structured bilateral baseline assessment:
/* OE — Bilateral baseline: visual acuity and IOP, one eye per record */
STUDYID DOMAIN USUBJID OESEQ OETESTCD OETEST OELAT OELOC
-------- ------ --------------- ----- -------- --------------------- ------ -----
XYZ-002 OE XYZ-002-005-03 1 VATOTSC Visual Acuity Total LEFT EYE
XYZ-002 OE XYZ-002-005-03 2 VATOTSC Visual Acuity Total RIGHT EYE
XYZ-002 OE XYZ-002-005-03 3 IOP Intraocular Pressure LEFT EYE
XYZ-002 OE XYZ-002-005-03 4 IOP Intraocular Pressure RIGHT EYE
OEORRES OESTRESC OESTRESN OESTRESU OEMETHOD OEDTC VISIT
------- -------- -------- -------- -------- ----------- --------
72 72 72 letters ETDRS 2023-06-01 BASELINE
68 68 68 letters ETDRS 2023-06-01 BASELINE
14 14 14 mmHg GAT 2023-06-01 BASELINE
16 16 16 mmHg GAT 2023-06-01 BASELINE
OELOC captures the anatomical location within the eye — CORNEA, RETINA, MACULA, OPTIC DISC — and becomes essential when multiple findings from different eye structures are collected at a single visit. OEMETHOD distinguishes assessment methods, which matters for IOP where Goldmann applanation, non-contact tonometry, and iCare rebound produce systematically different values with different reference ranges.
ETDRS vs Snellen and the STRESC Problem
Ophthalmic trials frequently collect Snellen notation on the CRF while the protocol specifies ETDRS letter equivalents as the analysis variable. These are not interchangeable. OEORRES should capture what the CRF collected — the Snellen fraction if that is what was entered. OESTRESC and OESTRESN hold the standardized numeric result. If the CRF collected 20/40 Snellen and you are putting 50 in OESTRESN, that conversion must be documented in the Define.xml Comments column and explained in the Reviewer's Guide, including which reference conversion chart was used. OETESTCD must also distinguish method: VATOTSC with OEMETHOD = ETDRS is a different concept from VATOTSC with OEMETHOD = SNELLEN. These should not share a single TESTCD if their results are not interchangeable for analysis.
MO Decommissioning and Backward Compatibility
The IG recommends that sponsors submitting under v3.4 use body-system domains and leave MO behind entirely — even if earlier studies in the same program mapped to MO.[1] For programs with ophthalmology data across multiple studies where some were submitted under v3.3 (OE) and earlier studies used MO, the Reviewer's Guide must document this version-based domain difference. The ADaM programmer needs to know the source domain for each study when tracing derivations back to tabulation data.
LB — Laboratory Test Results: Confirmed New Variables and Narrowed Scope
LB in 3.4 changed in two directions at once: it gained new variables designed to decompose complex assay metadata, and it lost a large category of data to IS. The CDISC IG documentation states that LB was updated to include 10 new variables in v3.4.[1] The complete list requires CDISC Library access. The variables below are confirmed from publicly available CDISC sources.[1][4][6]
Confirmed New Variables in LB for v3.4
| Root Variable | LB-Prefixed Name | Label | Role | Shared With | Primary Purpose |
|---|---|---|---|---|---|
TSTCND |
LBTSTCND |
Test Condition | Variable Qualifier | IS, CP | Stimulus condition under which the test was performed (e.g., EX VIVO STIMULATION, UNSTIMULATED) |
CNDAGT |
LBCNDAGT |
Test Condition Agent | Variable Qualifier | IS, CP | Specific agent used to create the test condition (e.g., LPS, PHA-M, PHYTOHAEMAGGLUTININ) |
BDAGNT |
LBBDAGNT |
Binding Agent | Variable Qualifier | IS, CP | Binding target or detection agent (antibody, probe) used in the assay — separates analyte from detection method |
TSTOPO |
LBTSTOPO |
Test Operational Objective | Variable Qualifier | IS | What the test is operationally designed to accomplish: DETECTION, QUANTIFICATION, CHARACTERIZATION |
TSTDTL |
LBTSTDTL |
Test Detail | Variable Qualifier | IS | Additional granularity beyond --TEST — distinguishes assay variants that share a TESTCD (e.g., NT50, NT80, PRNT50) |
LBCOLSRT |
domain-specific | Collection Sort Order | Variable Qualifier* | LB only | Ordering of collection records when multiple tubes are taken at a single timepoint; role corrected by errata |
LBLOINC |
domain-specific | LOINC Code | Record Qualifier† | CP, MB, MS (parallel) | Formal LOINC mapping for the test — role corrected by errata from Synonym Qualifier to Record Qualifier |
* LBCOLSRT was published with role "Record Qualifier" and corrected by errata to "Variable Qualifier."[1-errata] † LBLOINC was published with role "Synonym Qualifier" and corrected by errata to "Record Qualifier."[1-errata]
Why These Variables Were Added: The TESTCD Overloading Problem
Under v3.2 and v3.3, a complex immunogenicity assay had to compress all meaningful metadata into LBTESTCD (max 8 characters) and LBTEST (max 40 characters) — resulting in NCI C-codes substituted for readable TESTCDs, truncated TEST values, and supplemental qualifiers created to carry context that had no standard home.[6] v3.4 post-coordinates this into structured variables. The same test now looks like this:
/* v3.2/3.3 — pre-coordinated, truncated, supplemental qualifier required */ LBTESTCD = NRSVIGG /* NCI C-code used because human-readable name exceeds 8 chars */ LBTEST = Neut. Respirat. Syncytial Virus IgG NT50* /* truncated to fit 40-char limit */ /* SUPPRS: QNAM = "50% NEUTRALIZATION TITER", QVAL = "PRNT" */ /* v3.4 — post-coordinated across structured variables, IS domain */ ISTESTCD = MBIGGNAB /* Neutralizing Microbial-induced IgG Antibody */ ISTEST = Neutralizing Microbial-induced IgG Antibody ISBDAGNT = RESPIRATORY SYNCYTIAL VIRUS ISTSTDTL = 50% NEUTRALIZATION TITER /* No supplemental qualifiers needed */
LBTESTCD remains human-readable under v3.4. Context that was pre-coordinated into compound test names now has its own standard variable home, and SUPP-- qualifiers created to carry BINDING AGENT, CONDITION, or ASSAY VARIANT information can be retired.
The LBLOINC Errata: Define.xml Impact
This errata entry has a direct consequence in Define.xml that is easy to miss. LBLOINC was published in the original v3.4 release with the role of Synonym Qualifier.[1-errata] The errata corrects it to Record Qualifier. In Define.xml, Synonym Qualifier variables are treated as alternate labels for the topic variable — they do not carry independent origin, method, or codelist metadata. Record Qualifiers do. If your Define.xml for LB was templated against the originally published role assignment, the metadata for LBLOINC is wrong. FDA review tools validate against the model metadata. Fix it before submission. The same errata applies to CPLOINC, MBLOINC, and MSLOINC — all had the same role error and the same correction.
The Scope Contraction: ~400 CT Terms Leave LB for IS
This is the part that breaks existing lab standards programs. Under v3.4, LB no longer contains most immune response assessments or non-host organism tests.[6] Approximately 400 antibody-related TESTCD and TEST controlled terminology values are deprecated from LB (and MB) and remodeled in IS using IS domain standard variables including ISTESTCD, ISBDAGNT, and ISTSTDTL.[6] CDISC publishes a mapping file updated quarterly to help sponsors map deprecated concepts to their new post-coordinated IS equivalents.
What LB retains: clinical chemistry, hematology, urinalysis, coagulation, PK-supporting bioassays, and autoantibodies driven by pre-existing conditions not related to antigen stimulation. The boundary test is: is this measuring an immune response to an antigen? If yes, IS. If it is a general biochemical or hematological measurement, LB.
SUPPDS — Three Revised Assumptions in v3.4
Three changes in v3.4 directly affect what goes in SUPPDS and what does not. Two of them prohibit things that were common practice under v3.2 and v3.3. One removes a restriction that was forcing inaccurate DS modeling.
Population Flags Are No Longer SDTM Data
This is stated explicitly in v3.4 DM domain assumptions: population flags — COMPLT, FULLSET, ITT, PPROT, and SAFETY — should not be included in SDTM data.[7] Under v3.2 and v3.3 guidance, many sponsors included these in SUPPDM, on the reasoning that they were subject-level qualifiers derivable from disposition and protocol data. v3.4 closes that. These values are ADaM population derivation outputs. When they appear in both SDTM and ADaM, reviewers cannot establish the direction of derivation — whether the flag drove the analysis or was derived from it. The circular traceability dependency is the problem. If your SUPPDM template includes population flags, that template needs to change for any v3.4 submission.
EPOCH Restriction for PROTOCOL MILESTONE Records Removed
Under earlier guidance, the DS domain assumption was that EPOCH should not be populated when DSCAT = "PROTOCOL MILESTONE".[7] The logic was that milestones like Informed Consent and Screen Failure are not tied to a treatment epoch. In practice this prevented accurate representation of programs with multiple consent events — re-consent procedures, optional substudy consent, adaptive design consent updates — where the EPOCH context was needed to distinguish which record represented which consent event within which trial phase. v3.4 removes this restriction. EPOCH may now be populated for PROTOCOL MILESTONE records. If you use this capability, your SE and TV domains must define and include the EPOCH values you reference in DS.
DSSCAT: Formalizing the Treatment vs Participation Split
v3.3 formalized the use of DSSCAT to distinguish study treatment disposition from study participation disposition. v3.4 reinforces this structure and clarifies the SUPPDS boundary that results from it.[7] The correct architecture is: DSCAT holds the high-level category (DISPOSITION EVENT, PROTOCOL MILESTONE). DSSCAT distinguishes study treatment disposition from study participation disposition within each DSCAT category. When a subject discontinues treatment but continues in follow-up, that is two DS records — one with DSSCAT = "STUDY TREATMENT DISPOSITION" and one with DSSCAT = "STUDY PARTICIPATION DISPOSITION".
SUPPDS is appropriate when additional context cannot be captured in standard DS variables — a free-text withdrawal reason when DSDECOD controlled terminology is insufficient, or a sponsor-specific sub-reason below the level of standard coding. It is not appropriate for data that could go in DSCAT, DSSCAT, or DSDECOD with the correct controlled terminology applied. The more common audit finding is sponsors using SUPPDS for data that belongs in DSSCAT or as a DSDECOD value.
What Still Belongs in SUPPDS
With population flags prohibited and DSSCAT formalized, the legitimate use cases for SUPPDS narrow considerably. SUPPDS is appropriate for: protocol deviation sub-reason text that does not map to standard DSDECOD values, sponsor-specific categorization of withdrawal reason at a level below CDISC controlled terminology, and date-level detail for milestones where a second date variable is needed and no standard variable exists. It is not appropriate for data that has a standard DS variable — including DSSCAT, EPOCH, and DSCAT — even if those variables have not been used historically in your company standards.
Transition Checklist for v3.4
For each of the areas covered, the practical re-mapping work is specific and auditable.
For SR: audit any allergy or vaccine program where antibody titer data was routed to LB at baseline and IS post-exposure. Under v3.4, antigen-induced antibody records should all be in IS regardless of collection timing relative to study product exposure. Update or retire any SUPP-- qualifiers that were carrying immune response context that now has IS standard variable homes. Document the routing decision in the Reviewer's Guide explicitly.
For OE: if any prior studies in the same program mapped ophthalmic data to MO, document the version-based domain difference in the Reviewer's Guide. Audit OELAT population across all OE datasets — Expected variables with missing values are a P21 finding. Confirm that OETESTCD values distinguish assessment method when different methods produce non-interchangeable results. Verify that any Snellen-to-ETDRS conversions are documented in Define.xml Comments and the Reviewer's Guide.
For LB: run your master LBTESTCD library against the CDISC deprecation mapping file to identify the test codes that must migrate to IS. Remove those codes from LB routing logic and add them to IS controlled terminology mappings. Fix the LBLOINC role in your Define.xml metadata template from Synonym Qualifier to Record Qualifier. Also apply the same fix for CPLOINC, MBLOINC, and MSLOINC if those domains are in your submission. Evaluate the confirmed new variables — LBTSTCND, LBCNDAGT, LBBDAGNT, LBTSTOPO, LBTSTDTL — against your therapeutic area's existing SUPP-- qualifiers to determine whether any SUPPQUAL content can be retired in favor of standard variables.
For SUPPDS: remove population flags from any SUPPDM or SUPPDS template. Update VLM for DSDECOD to reflect separate controlled terminology codelists by DSSCAT value. Confirm that EPOCH is populated for PROTOCOL MILESTONE records where epoch context is meaningful for the study design. Audit SUPPDS content to confirm that each QNAM cannot be mapped to a standard DS variable under v3.4 assumptions.
None of this is optional for studies submitted under v3.4. FDA's Data Standards Catalog lists v3.4 as the current supported version. P21 Enterprise validation runs against v3.4 conformance rules. The time to update the standards is before the study starts, not during submission preparation. If your standards still reflect 3.2 or 3.3 assumptions, these are the areas that will surface first in review.
Sources and Verification
[1] CDISC. Study Data Tabulation Model Implementation Guide: Human Clinical Trials v3.4 (Final). July 2022. cdisc.org/standards/foundational/sdtmig/sdtmig-v3-4 — Primary source for all v3.4 domain specifications, errata (LBLOINC role, LBCOLSRT role, CPLOINC/MBLOINC/MSLOINC role corrections), and SUPPDS assumption changes.
[2] CDISC. SDTMIG v3.2. 2013. cdisc.org/standards/foundational/sdtmig/sdtmig-v3-2 — Source confirming SR introduced in v3.2 (with EC, PR, HO, DD, IS, MI, MO, RP, SS, TD); SR errata confirming Findings Sub-Class classification.
[3] PharmaSUG 2016, Paper DS04. Wittle et al. Moving up! — SDTM v3.2 — What is new and how to use it. — Confirms SR structure: one record per test per visit per subject; dermal responses to antigens from skin-prick assessments.
[4] CDISC Knowledge Base. IS Domain Scope Update for the SDTMIG v3.4: A Development History and the Difficulties of Standardizing Complicated Biological Processes. cdisc.org/kb/articles — Source for three-way routing decision (SR vs IS vs AE/CE), IS scope redefinition, and antigen definition in v3.4.
[5] CDISC 2024 China Interchange. Fan Yang. An In-Depth Analysis of the Updates and Challenges in SDTM IG 3.3 and 3.4. cdisc.org — Confirms OE (Ophthalmic Examinations) introduced in v3.3, not v3.4; MO decommissioned in v3.4.
[6] CDISC Webinar. Li et al. LB, MB & IS Domain Scope Changes for the SDTMIG v3.4 and Impact on Controlled Terminology. June 2023. cdisc.org (PDF) — Primary source for: confirmed new LB/IS/CP variables (BDAGNT, TSTCND, CNDAGT, TSTOPO, TSTDTL), TESTCD overloading rationale, ~400 CT term deprecations from LB/MB to IS, LB scope definition under v3.4.
[7] PHUSE-US 2024. Bheemagani et al. What's New in the SDTMIG v3.4 and the SDTM v2.0. lexjansen.com — Source for: population flags prohibition in SDTM (DM domain assumption), EPOCH restriction removal for PROTOCOL MILESTONE records, DSSCAT treatment vs participation split.