Friday, December 6, 2024

Common P21 SDTM Compliance Issues and How to Resolve Them

By Sarath Annapareddy

Introduction

Pinnacle 21 (P21) is a cornerstone for validating SDTM datasets against CDISC standards. Its checks ensure compliance with regulatory requirements set by the FDA, PMDA, and other authorities. However, resolving the issues flagged by P21 can be challenging, especially for beginners. This post dives into common P21 compliance issues and provides actionable solutions with examples.

1. Missing or Invalid Controlled Terminology

Issue: P21 flags variables like LBTESTCD or SEX as non-compliant with CDISC Controlled Terminology (CT). This happens when values in your datasets are outdated or invalid.

Solution: Update your CT files regularly from CDISC’s website. Use validation scripts to cross-check your datasets against the CT list.

Example:

data lab_final;
    merge lab_data (in=a)
          cdisc_ct (in=b);
    by LBTESTCD;
    if a and not b then put "WARNING: Invalid value for LBTESTCD=" LBTESTCD;
run;

This code validates lab data against CDISC Controlled Terminology and flags invalid entries.

2. Missing Required Variables

Issue: P21 highlights missing essential variables such as USUBJID, DOMAIN, and VISITNUM. Missing these variables can result in non-compliance.

Solution: Create validation macros in SAS to check for the presence of required variables. Always refer to the SDTM IG for domain-specific requirements.

Example:

%macro check_vars(dataset, vars);
    proc sql noprint;
        select count(*) 
        into :missing
        from dictionary.columns
        where libname="WORK" and memname=upcase("&dataset")
              and name not in (&vars);
    quit;
    %if &missing > 0 %then %put ERROR: Missing required variables!;
%mend;
%check_vars(lab_data, "USUBJID, DOMAIN, VISITNUM");

3. Inconsistent Dates and Timestamps

Issue: Non-compliance with ISO 8601 date format is a recurring issue. Variables such as AESTDTC or VISITDY may have incorrect formats or incomplete components.

Solution: Convert dates to ISO format during mapping and ensure consistent formats across datasets using SAS functions like PUT and INPUT.

Example:

data ae_final;
    set ae_raw;
    if not missing(AESTDT) then AESTDTC = put(AESTDT, E8601DA.);
run;

4. Duplicate Records

Issue: Duplicate records are flagged when unique combinations of keys (like USUBJID and VISITNUM) appear multiple times in a domain.

Solution: Implement deduplication techniques in SAS and ensure proper use of keys during dataset creation.

Example:

proc sort data=dm nodupkey;
    by USUBJID VISITNUM;
run;

5. Incomplete Traceability

Issue: P21 flags issues when derived variables or supplemental qualifiers lack proper traceability.

Solution: Clearly document derivations in your dataset specifications and use RELREC or SUPPQUAL datasets for maintaining traceability.

Example:

data suppae;
    set ae;
    where AESER = "Y";
    IDVAR = "SEQ";
    QNAM = "AESER";
    QVAL = AESER;
run;

6. Inconsistent Metadata

Issue: P21 reports mismatches between Define.xml and dataset metadata.

Solution: Automate Define.xml generation using tools like Pinnacle 21 Enterprise. Manually cross-check metadata during QC.

7. Invalid Links in RELREC

Issue: RELREC relationships do not align with the protocol-defined data structure.

Solution: Double-check all relationships during dataset creation and validate RELREC against its source domains.

Conclusion

Resolving P21 compliance issues requires both a strategic approach and practical programming skills. By addressing these common problems, you can ensure your datasets are regulatory-compliant, saving time and avoiding costly re-submissions.

Tuesday, December 3, 2024

Comprehensive QC Checklist for Define.xml and cSDRG: Ensuring Quality and Compliance for FDA and PMDA SDTM Submissions

Define.xml and cSDRG QC Checklist for FDA and PMDA Submissions

Comprehensive QC Checklist for Define.xml and cSDRG

Ensuring Quality and Compliance for FDA and PMDA SDTM Submissions

Introduction

The **Define.xml** and **Clinical Study Data Reviewer’s Guide (cSDRG)** are critical components of SDTM submissions to regulatory agencies like the FDA and PMDA. These documents help reviewers understand the structure, content, and traceability of the datasets submitted. A robust QC process ensures compliance with agency requirements, minimizes errors, and enhances submission success. This blog outlines a detailed manual QC checklist for both Define.xml and cSDRG, emphasizing key differences between FDA and PMDA requirements.

Define.xml QC Checklist

1. Metadata Verification

Verify all datasets listed in Define.xml are included in the submission package.
Check that all variable metadata (e.g., variable names, labels, types, and lengths) matches the SDTM datasets.
Ensure consistency between controlled terminology values and the CDISC Controlled Terminology files.
Confirm all mandatory fields (e.g., Origin, Value Level Metadata, Comments) are correctly populated.

2. Controlled Terminology

Ensure variables like AEDECOD, LBTESTCD, and CMTRT align with the latest CDISC Controlled Terminology.
Check NCI Codelist codes for correctness and proper linkage to variables.
Verify that SUPPQUAL domains reference appropriate `QNAM` and `QVAL` values.

3. Links and Traceability

Ensure all hyperlinks in Define.xml (e.g., links to codelists, Value Level Metadata, and external documents) are functional.
Verify traceability for derived variables to source data or algorithms.

4. Value Level Metadata

Check that Value Level Metadata is used for variables with differing attributes (e.g., QVAL in SUPPQUAL).
Validate metadata application to specific values, ensuring alignment with dataset content.

5. Technical Validation

Run Define.xml through Pinnacle 21 or a similar validation tool to identify errors or warnings.
Validate XML structure against the CDISC Define-XML schema (e.g., UTF-8 encoding).

6. Documentation

Ensure accurate descriptions in the Comments section for clarity and traceability.
Check consistency between Define.xml and cSDRG descriptions.

cSDRG QC Checklist

1. Content Consistency

Ensure alignment with Define.xml in terms of datasets, variables, and controlled terminology.
Verify consistency with CDISC guidelines for SDRG structure and content.

2. Document Structure

Ensure all required sections are present:
- Study Design Overview
- Dataset-Specific Considerations
- Traceability and Data Processing
- Controlled Terminology
Verify the inclusion of Acronyms and Abbreviations.

3. Dataset-Level Review

Check that all datasets referenced in cSDRG are included in the Define.xml and the submission package.
Verify clear descriptions of dataset-specific issues (e.g., imputed values, derived variables).

4. Traceability and Data Processing

Ensure documentation of traceability from raw data to SDTM datasets.
Validate derivation rules for key variables.

5. Controlled Terminology

Ensure controlled terminology usage aligns with Define.xml.
Document any deviations or extensions to standard controlled terminology.

6. Reviewer-Focused Content

Provide explanations for unusual scenarios (e.g., partial/missing dates, adverse event relationships).
Tailor descriptions to a reviewer’s perspective for clarity and usability.

7. Formatting and Usability

Ensure consistent fonts, headings, and numbering throughout the document.
Verify hyperlinks and table of contents functionality in the PDF format.

FDA vs. PMDA Considerations

While FDA and PMDA share many requirements, there are some critical differences:

Aspect	FDA	PMDA
Encoding	UTF-8	UTF-8 (focus on Japanese character encoding)
Validation Tools	Pinnacle 21 Community/Enterprise	Pinnacle 21 with PMDA-specific rules
Trial Summary (TS)	Focus on mandatory fields	Greater emphasis on PMDA-specific fields
Language	English	English and Japanese

Conclusion

Ensuring high-quality Define.xml and cSDRG documents is crucial for successful regulatory submissions to FDA and PMDA. Adhering to the detailed QC checklists outlined above will help identify and address issues early, saving time and reducing the risk of rejection. Tailoring your approach to the specific requirements of each agency ensures a smooth review process and enhances submission success rates.

Data Quality Checks for SDTM Datasets: FDA vs. PMDA: Understanding Regulatory Requirements for Submission Success

FDA vs PMDA Data Quality Checks

Differences in Data Quality Checks Between FDA and PMDA

Introduction

Submitting SDTM datasets to regulatory authorities like the FDA (U.S. Food and Drug Administration) and PMDA (Japan's Pharmaceuticals and Medical Devices Agency) involves rigorous data quality checks. While both agencies adhere to CDISC standards, their submission guidelines and expectations differ in certain aspects. This blog explores the key differences in data quality checks for FDA and PMDA submissions.

Similarities in Data Quality Checks

Both FDA and PMDA share several common expectations for SDTM datasets:

Adherence to CDISC Standards: Both agencies require compliance with the SDTM Implementation Guide (SDTM-IG).
Controlled Terminology (CT): Variables such as AEDECOD and LBTESTCD must align with CDISC CT.
Traceability: Ensures that derived datasets and analysis results can be traced back to the raw data.
Define.xml Validation: Both agencies expect a complete and validated Define.xml file for metadata documentation.

Differences in Data Quality Checks

The FDA and PMDA have distinct preferences and requirements that need careful attention.

Aspect-wise Comparison

Aspect	FDA	PMDA
Validation Tools	Primarily uses Pinnacle 21 Community or Enterprise for validation. Emphasis on "Reject" and "Error" findings.	Relies on Pinnacle 21, but PMDA-specific validation rules are stricter. Additional checks on Japanese language and character encoding (e.g., UTF-8).
Validation Rules	Focuses on U.S.-specific regulatory rules. Requires adherence to SDTM-IG versions commonly used in the U.S.	Requires alignment with Japanese-specific validation rules. More emphasis on Trial Summary (TS) and demographic consistency.
Trial Summary (TS) Domain	FDA expects a complete TS domain but is less stringent on content beyond mandatory fields.	PMDA places greater importance on the TS domain, especially for regulatory codes specific to Japan.
Japanese Subjects	Less emphasis on Japanese-specific requirements.	Requires additional checks for Japanese subjects, such as proper handling of kanji characters.

1. Data Validation and Tools

FDA:

Relies on specific validation tools like Pinnacle 21 Community/Enterprise to check data compliance.
FDA has stringent validator rules listed in their Study Data Technical Conformance Guide.
Focus is on ensuring conformance to CDISC standards such as SDTM, ADaM, and Define.xml.

PMDA:

Uses a custom validation framework with a focus on Study Data Validation Rules outlined in PMDA guidelines.
PMDA also emphasizes conformance but requires additional steps for documenting electronic data submissions.

2. Submission File Formats and Organization

FDA:

Requires datasets in SAS Transport Format (.xpt).
Submission files need to adhere to the eCTD format.
Technical specifications like split datasets (e.g., DM datasets with large record counts) need clear organization.

PMDA:

Aligns with the same .xpt requirement but often asks for additional metadata and dataset-specific documentation.
Detailed instructions on submission through the PMDA Gateway System.
PMDA requires notification submissions and extensive Q&A clarifications on data contents.

3. Controlled Terminologies and Dictionaries

FDA:

Requires compliance with the latest MedDRA and WHODrug versions.
MedDRA coding consistency is emphasized for all terms and values.

PMDA:

Accepts MedDRA and WHODrug but requires detailed mapping between collected data and coded terms.
Has additional checks for Japanese coding conventions and translations.

4. Define.xml

FDA:

Emphasizes alignment between dataset variables, labels, and metadata.
Requires accurate representations of origins (e.g., CRF, Derived).

PMDA:

Additional scrutiny on variable origins and alignment with Japanese electronic standards.
PMDA often requires clarifications for variables derived from external sources or referenced across multiple studies.

5. Reviewer’s Guides (cSDRG and ADRG)

FDA:

Provides guidance through templates like the cSDRG and ADRG.
Focus on study-level explanations for data inconsistencies, derivations, and non-standard elements.

PMDA:

Requires more detailed explanations in cSDRG and ADRG, especially regarding:

Variables annotated as Not Submitted.
Handling of adjudication or screen failure data.

6. Data Quality Focus

FDA:

Prioritizes ensuring datasets conform to the FDA Technical Specifications.
Consistency across study datasets within a submission is critical.

PMDA:

Prioritizes consistency between variables and detailed documentation of derivations.
More focused on mapping between raw data and analysis-ready datasets.

7. Study Tagging Files (STF)

FDA:

Requires STF to categorize and link datasets, programs, and metadata documents in the submission.

PMDA:

Similar to the FDA but emphasizes alignment between the STF and Japanese Gateway system submission requirements.

Regulatory Submission Context

Historical Context: The FDA and PMDA have embraced CDISC standards to enhance global harmonization, ensuring data transparency and reproducibility in clinical trials.

Key Objectives: Both agencies aim to ensure data integrity, accuracy, and traceability, facilitating efficient review processes and better regulatory oversight.

Specific Guidance from FDA and PMDA

FDA: The FDA emphasizes adherence to the Study Data Technical Conformance Guide and Data Standards Catalog to align submissions with their expectations.

PMDA: PMDA focuses on their Notifications on Electronic Study Data and their FAQs for addressing specific queries regarding Japanese regulatory requirements.

Operational Challenges

Language Considerations: Handling multi-language data, such as English and Japanese, introduces encoding and translation challenges, particularly for kanji characters.
Validation Tools Usage: Differences in Pinnacle 21 Community vs. Enterprise versions can create discrepancies in validation reports.

Lessons from Common Errors

Data Compliance Errors: Issues such as incomplete Define.xml, inconsistent controlled terminology, and incorrect TS domain entries are common pitfalls.

Mitigation Strategies: Conduct comprehensive pre-submission reviews, cross-checking both FDA and PMDA guidelines to preempt rejections.

Summary of Key Considerations

Aspect	FDA	PMDA
Validation Tools	Pinnacle 21	PMDA-specific validation rules
Submission System	eCTD	PMDA Gateway
Focus	Conformance to CDISC Standards	Metadata and mapping clarifications
Dictionaries	MedDRA/WHODrug	MedDRA/WHODrug + Japanese translations
Define.xml	Focus on CRF origins and labels	Additional variable origin documentation
Reviewer’s Guide	General inconsistencies and derivations	Non-standard elements and adjudication

Conclusion

While FDA and PMDA share a common foundation in CDISC standards, their data quality expectations have nuanced differences. Understanding these distinctions is critical for ensuring smooth submissions. By tailoring your SDTM programming and validation processes to address these unique requirements, you can enhance your submission success rate and streamline regulatory review.

Advanced SDTM Programming Tips: Streamline Your SDTM Development with Expert Techniques

Advanced SDTM Programming Tips

Streamline Your SDTM Development with Expert Techniques

Tip 1: Automating SUPPQUAL Domain Creation

The SUPPQUAL (Supplemental Qualifiers) domain can be automated using SAS macros to handle additional variables in a systematic way. Refer to the macro example provided earlier to simplify your SUPPQUAL generation process.

Tip 2: Handling Date Imputation

Many SDTM domains require complete dates, but raw data often contains partial or missing dates. Use the following code snippet for date imputation:

                
data imputed_dates;
    set raw_data;
    /* Impute missing day to the first day of the month */
    if length(strip(date)) = 7 then date = cats(date, '-01');
    /* Impute missing month and day to January 1st */
    else if length(strip(date)) = 4 then date = cats(date, '-01-01');
    format date yymmdd10.;
run;

Tip: Always document the imputation logic and ensure it aligns with the study protocol.

Tip 3: Dynamic Variable Label Assignment

Avoid hardcoding labels when creating SDTM domains. Use metadata-driven programming for consistency:

                
data AE;
    set raw_ae;
    attrib
        AESTDTC label="Start Date/Time of Adverse Event"
        AEENDTC label="End Date/Time of Adverse Event";
run;

Tip: Store labels in a metadata file (e.g., Excel or CSV) and read them dynamically in your program.

Tip 4: Efficient Use of Pinnacle 21 Outputs

Pinnacle 21 validation reports can be overwhelming. Focus on the following key areas:

Major Errors: Address structural and required variable issues first.
Traceability: Ensure SUPPQUAL variables and parent records are linked correctly.
Controlled Terminology: Verify values against the CDISC CT library to avoid deviations.

Tip: Use Excel formulas or conditional formatting to prioritize findings in Pinnacle 21 reports.

Tip 5: Debugging Complex Mapping Issues

When debugging mapping logic, use PUTLOG statements strategically:

                
data SDTM_AE;
    set raw_ae;
    if missing(AEDECOD) then putlog "WARNING: Missing AEDECOD for USUBJID=" USUBJID;
run;

Tip: Use PUTLOG with conditions to reduce unnecessary log clutter.

Tip 6: Mapping RELREC Domain

The RELREC domain is used to define relationships between datasets. Automate its creation using a data-driven approach:

                
data RELREC;
    set parent_data;
    RELID = "REL1";
    RDOMAIN1 = "AE"; USUBJID1 = USUBJID; IDVAR1 = "AESEQ"; IDVARVAL1 = AESEQ;
    RDOMAIN2 = "CM"; USUBJID2 = USUBJID; IDVAR2 = "CMSEQ"; IDVARVAL2 = CMSEQ;
    output;
run;

Tip: Validate RELREC with Pinnacle 21 to ensure all relationships are correctly represented.

Tip 7: Using PROC DATASETS for Efficiency

Leverage PROC DATASETS for efficient dataset management:

                
                
proc datasets lib=work nolist;
    modify AE;
        label AESTDTC = "Start Date/Time of Adverse Event"
              AEENDTC = "End Date/Time of Adverse Event";
    run;
quit;

Tip: Use PROC DATASETS to modify attributes like labels, formats, and lengths without rewriting the dataset.

Tip 8: Deriving Epoch Variables

EPOCH is a critical variable in SDTM domains, representing the study period during which an event occurred. Automate its derivation as follows:

                
data AE;
    set AE;
    if AESTDTC >= TRTSDTC and AESTDTC <= TRTEDTC then EPOCH = "TREATMENT";
    else if AESTDTC < TRTSDTC then EPOCH = "SCREENING";
    else if AESTDTC > TRTEDTC then EPOCH = "FOLLOW-UP";
run;

Tip: Ensure EPOCH values are consistent with the study design and align with other SDTM domains like EX and SV.

Tip 9: Validating VISITNUM and VISIT Variables

VISITNUM and VISIT are critical for aligning events with planned visits. Use a reference table for consistency:

                
proc sql;
    create table validated_data as
    select a.*, b.VISIT
    from raw_data a
    left join visit_reference b
    on a.VISITNUM = b.VISITNUM;
quit;

Tip: Cross-check derived VISITNUM and VISIT values against the Trial Design domains (e.g., TV and TA).

Tip 10: Generating Define.XML Annotations

Define.XML is a crucial deliverable for SDTM datasets. Use metadata to dynamically create annotations:

                
data define_annotations;
    set metadata;
    xml_annotation = cats("<ItemDef OID='IT.", name, "' Name='", name, 
                          "' Label='", label, "' DataType='", type, "'/>");
run;

proc print data=define_annotations noobs; run;

Tip: Validate the Define.XML file using tools like Pinnacle 21 or XML validators to ensure compliance.

Advanced SDTM Programming Tips: Automating SUPPQUAL Domain Creation

Advanced SDTM Programming Tip: Automating SUPPQUAL Domain Creation

Optimize Your SDTM Workflows with Efficient Automation Techniques

Introduction to SUPPQUAL Automation

The SUPPQUAL (Supplemental Qualifiers) domain is used to store additional information that cannot fit within a standard SDTM domain. Manually creating the SUPPQUAL domain can be time-consuming and error-prone, especially for large datasets. In this article, we’ll explore an advanced tip to automate its creation using SAS macros.

Use Case: Adding Supplemental Qualifiers to a Domain

Imagine you have an SDTM AE domain (Adverse Events) and need to capture additional details like the investigator’s comments or assessment methods that are not part of the standard AE domain.

Code Example: Automating SUPPQUAL Domain

                
/* Macro to Create SUPPQUAL Domain */
%macro create_suppqual(domain=, idvar=, qnam_list=);
    %let domain_upper = %upcase(&domain);
    %let suppqual = SUPP&domain_upper;

    data &suppqual;
        set &domain;
        length RDOMAIN $8 IDVAR $8 QNAM $8 QLABEL $40 QVAL $200;
        array qvars{*} &qnam_list;
        do i = 1 to dim(qvars);
            if not missing(qvars{i}) then do;
                RDOMAIN = "&domain_upper";
                USUBJID = USUBJID;
                IDVAR = "&idvar";
                IDVARVAL = &idvar;
                QNAM = vname(qvars{i});
                QLABEL = put(QNAM, $40.);
                QVAL = strip(put(qvars{i}, $200.));
                output;
            end;
        end;
        drop i &qnam_list;
    run;

    /* Sort SUPPQUAL for submission readiness */
    proc sort data=&suppqual;
        by USUBJID RDOMAIN IDVAR IDVARVAL QNAM;
    run;
%mend;

/* Example Usage: Automating SUPPAE */
%create_suppqual(domain=AE, idvar=AETERM, qnam_list=AECOMMENT AEASSESS);

Explanation of the Code

RDOMAIN: Captures the parent domain name (e.g., AE).
array qvars{*}: Iterates through the list of supplemental qualifiers provided as macro parameters.
IDVAR: Represents the key variable in the parent domain (e.g., AETERM).
QLABEL: Automatically assigns a label to the qualifier variable.
QVAL: Stores the actual value of the supplemental qualifier.

Advantages of This Approach

Eliminates manual effort in creating SUPPQUAL domains.
Highly reusable and scalable across different domains.
Ensures consistency in handling supplemental qualifiers.

Pro Tip: Validation and Quality Control

Always validate the output SUPPQUAL dataset against CDISC compliance rules using tools like Pinnacle 21. Ensure that all required columns and relationships are correctly populated.

Hash Objects

Advanced SAS Programming Tip: Using HASH Objects

Unlock the Power of SAS for Efficient Data Manipulation

Introduction to HASH Objects

In SAS, HASH objects provide an efficient way to perform in-memory data lookups and merge operations, especially when dealing with large datasets. Unlike traditional joins using PROC SQL or the MERGE statement, HASH objects can significantly reduce computational overhead.

Use Case: Matching and Merging Large Datasets

Suppose you have two datasets: a master dataset containing millions of records and a lookup dataset with unique key-value pairs. The goal is to merge these datasets without compromising performance.

Code Example: Using HASH Objects

                
/* Define the master and lookup datasets */
data master;
    input ID $ Value1 $ Value2 $;
    datalines;
A001 X1 Y1
A002 X2 Y2
A003 X3 Y3
;
run;

data lookup;
    input ID $ LookupValue $;
    datalines;
A001 L1
A002 L2
A003 L3
;
run;

/* Use HASH object to merge datasets */
data merged;
    if _n_ = 1 then do;
        declare hash h(dataset: "lookup");
        h.defineKey("ID");
        h.defineData("LookupValue");
        h.defineDone();
    end;

    set master;
    if h.find() = 0 then output;
run;

/* Display the merged data */
proc print data=merged;
run;

Explanation of the Code

declare hash h: Creates a HASH object and loads the lookup dataset into memory.
h.defineKey: Specifies the key variable (ID) for the lookup.
h.defineData: Identifies the variable to retrieve from the lookup dataset.
h.find(): Searches for a match in the HASH object and retrieves the data if found.

Advantages of HASH Objects

Faster lookups compared to traditional joins, especially with large datasets.
In-memory operations reduce I/O overhead.
Provides greater flexibility for advanced operations.

Advanced SAS Programming Tip: Mastering Macro Variables

Unleash the power of SAS with this advanced technique.

Introduction

Macro variables are a powerful tool in SAS that allow you to dynamically generate code. By understanding and effectively using macro variables, you can write more efficient and flexible SAS programs.

The Basics of Macro Variables

A macro variable is a placeholder that is replaced with its value during macro processing. You define a macro variable using the %LET statement and reference it using the %SYSFUNC or %SYSEVALF functions.

Advanced Techniques

1. Conditional Logic

You can use the %IF-%THEN-%ELSE statements to create conditional logic within your macro code. This allows you to dynamically generate code based on specific conditions.

2. Iterative Processing

The %DO loop can be used to iterate over a range of values or a list of items. This is useful for repetitive tasks, such as generating multiple datasets or reports.

3. Custom Macro Functions

You can create your own custom macro functions to encapsulate complex logic and reuse it throughout your code. This can help to improve code readability and maintainability.

Example: Dynamically Generating SQL Queries

Here's a simple example of how to use macro variables to dynamically generate SQL queries:

```sas %let table_name = my_data; %let where_clause = age > 30; proc sql; select * from &table_name where &where_clause; quit; ```

Conclusion

By mastering macro variables, you can take your SAS programming skills to the next level. Experiment with these techniques to create more powerful and efficient SAS programs.