sdtm adam define-xml pinnacle21 validation clinicalprogramming Solving the Define-XML 2.1 Validation Loop: Resolving DD0113 and DD0029 Without Sacrificing Compliance July 13, 2026 ClinPilot Insights If you have ever spent the night before a regulatory submission dry-running a Define-XML package through Pinnacle 21, only to be hit with a wall of validation errors, you are not alone. The transition to Define-XML 2.1 was supposed to be our salvation. It introduced dataset-level standard declarations and codelist-level terminologies, moving us away from the rigid constraints of the 2.0 schema. Instead, it introduced a fresh batch of validation quirks. Two validation rules in particular have become major pain points for clinical programming teams: DD0113 (which flags external dictionary references) and DD0029 (which checks ADaM coded values). When these rules misfire, they create a frustrating dilemma: do you compromise your metadata's technical accuracy to satisfy a validator, or do you leave the errors in and spend days writing justifications in your Study Data Reviewer's Guide (SDRG)? Let us look at why these rules fail, how to resolve them, and how to stop wrestling with raw XML. ## Understanding the DD0113 Loop: Character vs. Numeric MedDRA References Rule DD0113 is designed to verify that external dictionaries, such as MedDRA or WHO Drug, are properly declared and referenced. In Define-XML 2.1, character variables controlled by MedDRA—like AEDECOD or AELLT—require an external codelist reference. The validation bug occurs when you try to populate the MedDRA reference for paired numeric variables, such as AEPTCD or AELLTCD. In a standard setup, you might declare a single MedDRA codelist with a text data type: ```xml ``` If you link this codelist to your character variables (DataType="text"), the validator is happy. But when you link it to a numeric variable like AEPTCD (DataType="integer"), the validator throws a "Codelist/Variable Data Type mismatch" error because the codelist’s data type is text, but the variable is an integer. To solve this, some programmers attempt to declare a second MedDRA dictionary reference with an integer data type. However, the Pinnacle 21 validation engine historically assumes a single MedDRA dictionary definition per Define-XML document. When it detects a second reference, it triggers a DD0113 false positive. ### The Resolution Strategy There are two schools of thought on resolving this: 1. **The Workaround (Omission):** Only populate the external codelist reference for character variables (AEDECOD, AELLT) and omit it entirely for numeric variables (AEPTCD, AELLTCD). Since the numeric variable represents the paired coded value of the text variable, omitting the reference satisfies the validator and eliminates the DD0113 error. 2. **The Compliance-First Approach (Traceability):** Keep the external dictionary references on both the character and numeric variables, and document the resulting DD0113 validation errors as false positives in your SDRG. As industry metadata experts often emphasize, the purpose of a submission package is to provide comprehensive, accurate metadata for regulatory reviewers, not just to satisfy validation software. ## Decoding DD0029: Coded Values and the ADaM Asterisk Problem Another common bottleneck occurs with rule DD0029, which validates that CodedValue attributes in your Define-XML match the actual values present in your datasets. In ADaM datasets, we frequently group parameters or utilize wildcard-like structures in our metadata. For example, you might have parameter codes defined with wildcards in your specifications, or where-clauses that use asterisks: ```sas /* Typical ADaM parameter grouping where asterisks are used as wildcards */ PARAMCD = "SYSBP*" ``` When you generate the ADaM Define-XML, these asterisks may carry over into the `` elements. Pinnacle 21’s validation engine reads these asterisks literally. Because your actual ADaM dataset contains exact values (like "SYSBP") rather than literal asterisks (like "SYSBP*"), the parser throws a DD0029 validation error, claiming a mismatch between your metadata and your datasets. ### The Resolution Strategy To resolve the DD0029 asterisk issue without breaking your ADaM traceability: 1. **Avoid Literal Wildcards in CodedValues:** Ensure your metadata specifications define explicit, discrete values for parameters rather than relying on wildcard groupings in the codelist definitions. 2. **Utilize Where-Clauses Correctly:** If the asterisk is part of a selection criteria, ensure it is written within a proper `` using standard relational operators rather than embedding it as a wildcard value inside a ``. 3. **Escaping Characters:** Ensure that any special character or asterisk required by the design is properly escaped in the XML. ## Moving Beyond Spreadsheet Specs The real reason these errors cost biometrics teams so much time is our reliance on manual, spreadsheet-based specification workflows. Programmers spend hours writing custom SAS macro generators or Python scripts to convert Excel specs into XML. Every time a validation rule changes or a false positive is identified, the underlying script must be rewritten, tested, and re-executed. Transitioning to unified clinical metadata repositories (MDRs) that natively understand Define-XML schemas changes this paradigm. Moving away from manual, spreadsheet-bound workflows toward schema-aware metadata environments allows teams to programmatically manage the relationships between variables and external dictionaries. By structuring where-clauses according to CDISC schemas and validating codelist data types early, you can flag known inconsistencies before even running a validator check. The ultimate outcome is a substantial reduction in Define-XML compilation cycles, yielding cleaner submission packages and saving programming teams from debugging complex XML tags late at night. 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