Thursday, October 10, 2024

The Power of RETAIN Statement in SAS Programming: Advantages and Use Cases

The Power of RETAIN Statement in SAS Programming: Advantages and Use Cases

The Power of RETAIN Statement in SAS Programming: Advantages and Use Cases

Author: Sarath

Date: October 10, 2024

Introduction

The RETAIN statement in SAS is a powerful tool used to control the behavior of variables across iterations in a data step. Unlike standard SAS variables, which are reset at the beginning of each iteration, RETAIN allows you to preserve the value of a variable from one iteration to the next. In this blog post, we will explore the advantages and use cases of the RETAIN statement in SAS programming, including controlling variable order, and provide practical examples.

Advantages of the RETAIN Statement

  • Preserve Values Across Iterations: The primary advantage of using the RETAIN statement is its ability to retain values across data step iterations. This feature is particularly useful when creating cumulative sums, counters, or when you need to remember values from a previous observation.
  • Improve Performance: The RETAIN statement can improve the efficiency of a program by eliminating the need for complex MERGE or PROC SQL steps. It simplifies the logic for tasks that require comparing current and previous observations.
  • Enhance Code Readability: By using RETAIN, you can avoid writing multiple lines of code to carry forward values. This makes your code cleaner and easier to understand.
  • Control Variable Order: The RETAIN statement allows you to explicitly specify the order in which variables appear in the output dataset. This is particularly useful when the default order (based on the order in which variables are created) does not meet your needs.

Common Use Cases of the RETAIN Statement

1. Cumulative Sums

The RETAIN statement is often used to calculate cumulative sums. For example, let's say you have a dataset with daily sales, and you want to calculate the total sales up to each day:

data cumulative_sales;
    set daily_sales;
    retain total_sales 0;
    total_sales = total_sales + sales;
run;
        

In this example, RETAIN ensures that the value of total_sales is carried forward from one observation to the next, allowing us to accumulate the total sales for each day.

2. Carry Forward Last Non-Missing Value

Another common use case is carrying forward the last non-missing value across observations. Here's an example where you want to carry the last valid value of a variable forward:

data carry_forward;
    set mydata;
    retain last_value;
    if not missing(value) then last_value = value;
run;
        

In this code, the RETAIN statement ensures that the variable last_value keeps its value until a new non-missing value is encountered.

3. Sequential Numbering or Counters

The RETAIN statement can also be used for counting occurrences or assigning sequential numbers to observations based on certain conditions:

data numbering;
    set events;
    retain event_count 0;
    if event = 'Yes' then event_count + 1;
run;
        

In this example, event_count increments by 1 whenever the event occurs, creating a sequential count of events.

4. Controlling Variable Order in the Output Dataset

In SAS, the default variable order in the output dataset is based on the order in which the variables are created. However, in some cases, you may want to control the order of the variables explicitly. The RETAIN statement allows you to achieve this. Here's an example:

data control_order;
    retain id name age salary; /* Specifying variable order */
    set employee_data;
    salary = salary * 1.1; /* Example of updating a variable */
run;
        

In this example, the RETAIN statement is used to specify the order in which the variables id, name, age, and salary will appear in the output dataset. Even though the salary variable is updated later in the data step, it will appear last in the specified order.

When to Use RETAIN vs. Other Methods

While the RETAIN statement is useful, there are other techniques such as FIRST. and LAST. variables, or MERGE with BY statements, that may serve similar purposes. However, RETAIN is generally more efficient for simple tasks such as accumulating values, counting, or controlling variable order.

Conclusion

The RETAIN statement is a valuable feature in SAS programming that can simplify your code and improve efficiency. Whether you're calculating cumulative sums, carrying forward non-missing values, creating counters, or controlling variable order, understanding how to use RETAIN will help you develop more effective SAS programs. Incorporate it wisely into your data steps to optimize your workflows!

Have questions or additional examples? Feel free to leave a comment below!

Tuesday, September 24, 2024

Understanding ADAPT in the SDTM TS Domain: Adaptive vs Non-Adaptive Trials

Understanding ADAPT in the SDTM TS Domain: Adaptive vs Non-Adaptive Trials

Understanding ADAPT in the SDTM TS Domain: Adaptive vs Non-Adaptive Trials

The Study Data Tabulation Model (SDTM) plays a critical role in organizing and submitting clinical trial data. One of the parameters that regulatory agencies look for in the Trial Summary (TS) domain is the ADAPT parameter (TSPARMCD=ADAPT), which indicates whether the trial follows an adaptive design. In this blog post, we will explore the meaning of ADAPT and provide examples of adaptive and non-adaptive trials.

What is ADAPT in the TS Domain?

The ADAPT parameter identifies whether the clinical trial is adaptive (ADAPT=Y) or non-adaptive (ADAPT=N). An adaptive trial allows for modifications to the study design based on interim results, making the trial more flexible and often more efficient.

"Adaptive clinical trials allow for changes in design or hypotheses during the study based on accumulating data, without undermining the validity or integrity of the trial."

Example 1: Non-Adaptive Trial (ADAPT = N)

A non-adaptive trial follows a fixed protocol and does not allow for any changes during the study. Most traditional randomized controlled trials (RCTs) fall into this category. For example, a phase III trial that tests a drug against a placebo in a predefined number of patients without any modifications would be classified as non-adaptive.

STUDYID TSPARMCD TSVAL
ABC123 ADAPT N

In this case, the study ABC123 is a non-adaptive trial with no pre-planned modifications allowed during the course of the trial.

Example 2: Adaptive Trial (ADAPT = Y)

An adaptive trial allows changes to be made during the study based on interim analyses. These changes might include modifying sample size, adjusting dosing regimens, or even dropping treatment arms. Adaptive trials are common in oncology and rare disease studies, where efficient trial design is crucial due to limited patient populations.

For example, a phase II oncology trial might allow for dose adjustments or early termination based on early data. In this case, the trial would be classified as adaptive.

STUDYID TSPARMCD TSVAL
DEF456 ADAPT Y

The study DEF456 is an adaptive trial where the protocol allows for changes based on interim analysis.

Key Considerations for Adaptive Trials

When implementing an adaptive trial, it's essential to plan for certain regulatory and statistical considerations:

  • Pre-Specified Rules: Adaptations must be pre-specified in the protocol and reviewed by regulatory bodies.
  • Interim Analyses: Interim analyses require statistical rigor to avoid bias or misleading results.
  • Regulatory Approval: Regulatory agencies such as the FDA and EMA provide specific guidelines for adaptive trials, which must be strictly followed.

When is TSVAL set to "Y" for TSPARMCD=ADAPT?

The TSVAL variable is set to "Y" (Yes) for TSPARMCD=ADAPT if the study incorporates an adaptive design. An adaptive design allows for certain changes during the trial without compromising its validity. Examples of common adaptive designs include:

  • Sample Size Re-estimation: Adjusting the sample size based on interim data to ensure adequate power.
  • Early Stopping for Efficacy or Futility: Halting the trial early based on strong interim results or low likelihood of success.
  • Dose Adjustment: Changing dose levels according to participant responses.
  • Group Sequential Design: Using planned interim analyses to decide if the trial should continue or be modified.

If any of these design aspects apply, TSVAL for TSPARMCD=ADAPT would be "Y". Otherwise, it would be set to "N" for non-adaptive, fixed designs.

Example TS Domain Table

Here’s an example representation in the TS domain:

TSPARMCD TSPARM TSVAL Description
ADAPT Adaptive Design Y Indicates that the study has an adaptive design approach.

In regulatory submissions, such as to the FDA or PMDA, defining adaptive design parameters helps reviewers understand study flexibility and methods for ensuring trial integrity.

Conclusion

Understanding whether a trial is adaptive or non-adaptive is crucial for interpreting clinical trial data. Adaptive trials offer flexibility and efficiency but come with additional regulatory and statistical challenges. The ADAPT parameter in the TS domain provides a quick way to identify whether a trial has an adaptive design, allowing for more informed data review and analysis.

References

SDTM Trial Summary Domain: ACTSUB vs Screen Failures

Understanding SDTM Trial Summary Domain: ACTSUB vs Screen Failures

In the world of clinical data management, the Study Data Tabulation Model (SDTM) plays a vital role in organizing and submitting clinical trial data to regulatory agencies. One of the most essential domains in SDTM is the Trial Summary (TS) domain, which provides key information about the clinical trial itself.

In this blog post, we will explore the Actual Number of Subjects (ACTSUB) and how it differs from screen failures. We will also reference regulatory guidelines and SDTM Implementation Guides to ensure a deeper understanding.

What is the TS Domain?

The Trial Summary (TS) domain contains high-level information about the clinical trial. This includes essential data such as the number of subjects, the start and end dates of the trial, trial objectives, and much more. The TSPARMCD variable defines various parameters such as the number of subjects or study arms in the trial.

What is TSPARMCD=ACTSUB?

ACTSUB stands for the "Actual Number of Subjects" in a clinical trial. This variable represents the number of participants who actually started the treatment or intervention after passing the screening phase.

"The actual number of subjects refers to the total number of participants who were enrolled in the study and received at least one treatment or underwent a key study procedure."

This means that screen failures—subjects who were screened but did not qualify to proceed—are typically excluded from this count. Regulatory agencies such as the FDA and EMA expect only those subjects who participated in the study to be counted under ACTSUB.

How Are Screen Failures Captured in the TS Domain?

Screen failures are accounted for separately from ACTSUB in most cases. For instance, the TS domain may contain a different variable like TSPARMCD=SCRSUB, which captures the number of subjects who were screened. This would include those who did not pass the screening process.

Example Scenario: ACTSUB and Screen Failures

Let’s consider a hypothetical trial with 200 subjects:

  • 250 subjects were screened.
  • 50 of those subjects were screen failures (they did not meet eligibility criteria).
  • The remaining 200 subjects were enrolled in the trial and participated in the treatment.

In this scenario, TSPARMCD=ACTSUB would be recorded as 200, while TSPARMCD=SCRSUB would be recorded as 250 to include all screened subjects, both successful and failures.

References and Guidelines

To further explore this topic, you can review the following references:

Tuesday, September 10, 2024

Understanding EC vs. EX Domains in SDTM: When to Use Each

Understanding EC vs. EX Domains in SDTM: When to Use Each

Understanding EC vs. EX Domains in SDTM: When to Use Each

In SDTM, the EC (Exposure as Collected) and EX (Exposure) domains are both used to capture data related to drug or therapy exposure, but they serve different purposes depending on how the exposure data is collected and whether the study is blinded or unblinded.

Key Updates from PharmaSUG Papers:

  • PharmaSUG 2017 Paper DS08 introduces the historical context of the EC domain, which was established in SDTMIG v3.2 to support the EX domain by providing detailed traceability for exposure data. EC helps capture deviations, titrations, and other variations from planned dosing, especially when the collected data doesn't match protocol-specified dosing.
  • PharmaSUG 2022 Paper DS121 emphasizes the importance of capturing dose modifications using the EC domain, which often occurs in oncology trials. By utilizing EC, sponsors can accurately document variations such as dose holds, eliminations, and reductions, which later assist in deriving the EX domain.
  • PharmaSUG 2018 Paper DS16 discusses the challenges in blinded studies, highlighting that the EC domain can be used to store blinded data until the study is unblinded, after which the EX domain can be derived. This paper also details the use of EC to capture missed doses that cannot be represented in EX.
  • PharmaSUG China 2021 Paper DS083 provides a detailed discussion of how to present exposure data in a reviewer-friendly manner. It also introduces two new domains from SDTMIG v3.3 — AG (Procedure Agents) and ML (Meals) — which, though not directly related to EC/EX, offer additional context for studies that involve substances administered during procedures or nutritional intake.
---

When to Use the EC and EX Domains

EC (Exposure as Collected) Domain:

  • Use EC when dose modifications such as elimination, hold, delay, reduction, or mid-cycle adjustments are expected due to treatment-related factors (e.g., toxicities in oncology trials).
  • EC is suitable for blinded studies to store collected exposure information until unblinding.
  • EC captures exact details such as missed doses, variations from protocol-specified units, and planned or scheduled exposure using the `ECMOOD` variable.

EX (Exposure) Domain:

  • Use EX to represent planned exposure that aligns with the study protocol. This includes the administration of investigational products in protocol-specified units.
  • EX captures the actual administered dose after unblinding and can also reflect doses of placebos in clinical trials.
---

Key Takeaways for EC and EX Domain Usage

  • Blinded Studies: EC can capture blinded doses, and once unblinded, the EX domain should reflect the actual doses administered.
  • Dose Modifications: EC captures any variations from planned dosing, including dose holds, eliminations, and adjustments.
  • Missed Doses: Use EC to document missed doses and the reasons for those missed doses using `ECOCCUR` and `SUPPEC` for reasons like adverse events.
  • Protocol-Specified Units: EC can capture doses in collected units (e.g., volume of a dosing solution), while EX converts them into protocol-specified units (e.g., mg/kg).
---

Introduction to EC and EX Domains

The EC domain captures the exact exposure data as it is collected in the study. This is especially useful when exposure data varies between subjects, such as in cases of dose titrations, interruptions, or other adjustments. The key feature of the EC domain is its ability to reflect actual data, making it indispensable in complex trials where the administration schedule doesn’t always follow the protocol exactly.

For instance, if subjects are receiving doses that are adjusted based on their responses or lab results, or if subjects experience dose interruptions, the EC domain should be used to capture this variability. It provides an accurate picture of what really happened, even if the data does not align with the protocol-specified dose.

Example: Titration or Adjusted Dosing Scenario

In a trial where Drug B’s dose is titrated based on a subject's response, one subject might start at 25 mg and increase to 50 mg after 10 days. Another subject could remain at 25 mg due to adverse events, and a third subject might increase to 75 mg. These variations should be captured in the EC domain.

STUDYID USUBJID ECDOSE ECDOSU ECDOSFRM ECSTDTC ECENDTC ECREASND
ABC123 001 25 mg Tablet 2024-01-01 2024-01-10 Titration
ABC123 001 50 mg Tablet 2024-01-11 2024-01-14
ABC123 002 25 mg Tablet 2024-01-01 2024-01-15 Adverse Event

When to Use the EX Domain

The EX domain captures the planned exposure based on the study protocol. It is used when the actual exposure follows the protocol as intended. The EX domain should be used for trials where the dosing regimen is straightforward and subjects receive the planned doses at scheduled times.

For example, if a trial protocol specifies that subjects receive 50 mg of Drug A daily for 30 days, and all subjects follow this schedule without any variations, the EX domain can capture this data.

Example: Simple Dosing Scenario

In a study where Drug A is administered in a fixed dose of 50 mg daily, the EX domain captures the planned exposure:

STUDYID USUBJID EXTRT EXDOSE EXDOSU EXROUTE EXSTDTC
XYZ456 001 Drug A 50 mg Oral 2024-02-01
XYZ456 002 Drug A 50 mg Oral 2024-02-01

Using Both EC and EX Domains Together

In some cases, both domains can be used together to represent the planned vs. actual exposure. For instance, the EX domain captures the protocol-specified dose (e.g., 50 mg daily), while the EC domain captures deviations, such as dose interruptions or adjustments. This approach provides a complete picture of the exposure.

Example: Combined Use of EC and EX Domains

In a study where Drug D is administered as 50 mg daily but a subject misses doses due to personal reasons, the EX domain would capture the planned regimen, while the EC domain would record the missed doses.

EX Domain (Planned Dose):
STUDYID USUBJID EXTRT EXDOSE EXDOSU EXROUTE EXSTDTC
DEF789 001 Drug D 50 mg Oral 2024-03-01
EC Domain (Actual Doses with Missed Doses):
STUDYID USUBJID ECDOSE ECDOSU ECDOSFRM ECSTDTC ECENDTC ECREASND
DEF789 001 50 mg Tablet 2024-03-01 2024-03-05
DEF789 001 50 mg Tablet 2024-03-07 2024-03-30 Missed Dose

Additional Considerations for Submission

  • Do not duplicate EC and EX data unless necessary.
  • Use SUPPEC to provide additional reasons for missed or not-given doses in the EC domain.
  • Ensure proper representation of blinded and unblinded data in EC and EX to comply with regulatory expectations.
---

Conclusion

By leveraging the **EC** and **EX** domains appropriately, sponsors can ensure clear traceability of exposure data and provide regulatory reviewers with a complete and accurate story of how subjects were exposed to the study treatment. These domains, when used in tandem, help differentiate between collected and derived data, making it easier for reviewers to assess and understand study results.

Monday, September 9, 2024

Study Start Date in SDTM – Why Getting It Right Matters

Study Start Date in SDTM – Why Getting It Right Matters

Study Start Date in SDTM – Why Getting It Right Matters

The Study Start Date (SSTDTC) is a crucial element in the submission of clinical trial data, especially in meeting regulatory requirements. Since December 2014, the FDA has provided explicit guidance on defining and utilizing this data point, but many sponsors and service providers face challenges in its consistent application. Missteps in defining the Study Start Date can lead to technical rejection during submission reviews, delaying the regulatory process. This article explores the definition, importance, and proper implementation of the Study Start Date in SDTM (Study Data Tabulation Model) submissions, based on regulatory guidance and best practices.

FDA’s Definition of Study Start Date

The FDA, in its 2014 guidance, clarified that the Study Start Date for clinical trials is the earliest date of informed consent for any subject enrolled in the study. This approach ensures a data-driven, verifiable measure, using clinical trial data captured in the Demographics (DM) domain of SDTM. By anchoring the Study Start Date to the earliest informed consent, the FDA avoids manipulation of study timelines and enforces adherence to accepted data standards during study execution.[1]

Why is the Study Start Date Important?

The Study Start Date serves as a cornerstone in the clinical trial submission process. It plays a critical role in:

  • Compliance: The Study Start Date is used as a benchmark to assess the trial’s adherence to FDA’s data standards catalog. Standards implementation is tracked based on this reference date.
  • Consistency: A well-defined Study Start Date ensures uniformity across various study data elements, including SDTM domains, analysis datasets, and associated regulatory documentation.
  • Avoiding Rejections: Incorrect or inconsistent assignment of the Study Start Date can lead to technical rejection by the FDA during submission. Rule 1734, for instance, mandates that the Study Start Date be recorded in the Trial Summary (TS) domain, and failure to meet this criterion can result in a rejection of the submission package.[1]

Where to Record the Study Start Date

Accurate recording of the Study Start Date is essential for successful regulatory submissions. This date must appear in two key sections of the eCTD (electronic Common Technical Document) that are submitted to the FDA:

  1. SDTM TS Domain: The Study Start Date is stored in the variable TS.TSVAL where TSPARMCD = 'SSTDTC'. It must adhere to the ISO 8601 date format (YYYY-MM-DD).
  2. Study Data Standardization Plan (SDSP): The Study Start Date is also included in the SDSP, which contains metadata about the study, along with other relevant details such as the use of FDA-endorsed data standards.[1]

Challenges in Defining the Study Start Date

One major challenge in defining the Study Start Date arises from the varied interpretations among stakeholders. For example:

  • Data Managers may consider the go-live date of the data collection system as the Study Start Date.
  • Safety Teams might prioritize the first dose date of the investigational product.
  • Clinical Operations could focus on the date of the first patient visit at the clinic.

However, the correct interpretation, as per FDA guidance, is the earliest informed consent date, ensuring a consistent and regulatory-compliant approach.[1]

How to Verify the Study Start Date

Verifying the Study Start Date requires careful examination of clinical data. The following steps can help:

  1. Examine the DM Domain: The DM.RFICDTC variable (date of informed consent) is cross-checked against the protocol and Statistical Analysis Plan (SAP) to ensure it aligns with enrolled subjects.
  2. Exclude Screen Failures: Screen failures must be excluded from the analysis as they do not contribute to the Study Start Date. Only enrolled subjects should be included in this determination.
  3. Programmatic Check: The following SAS code can be used to programmatically select the earliest informed consent date for the enrolled subjects:
    proc sql noprint;
       select min(rficdtc) from SDTM.DM
       where rficdtc is not null and armcd in ('TRTA', 'TRTB');
    quit;
    
                

Global Considerations

While the FDA’s definition is clear, other regulatory authorities such as the PMDA in Japan and the NMPA in China have slightly different approaches. For example, the PMDA evaluates standards based on the submission date rather than the Study Start Date. As more global regulators adopt machine-readable clinical data standards, alignment with FDA guidance may serve as a reference point for future harmonization efforts.[1]

Multiple Ways to Derive Stusy Start Date (SSTDTC) in SDTM

Several SAS-based methods can be used to derive the Study Start Date (SSTDTC) in SDTM. Below are a few approaches:

1. Using PROC SQL

PROC SQL can compute the minimum date directly from the dataset:

proc sql noprint;
    select min(rficdtc) into :mindate
    from SDTM.DM
    where rficdtc is not null and armcd ne 'SCRNFAIL';
quit;

    

2. Using DATA STEP with RETAIN

This approach retains the minimum date as the dataset is processed:

data earliest_consent;
    set SDTM.DM;
    where rficdtc is not missing and armcd ne 'SCRNFAIL';
    retain min_consent_date;
    if _N_ = 1 then min_consent_date = rficdtc;
    else if rficdtc < min_consent_date then min_consent_date = rficdtc;
run;

proc print data=earliest_consent(obs=1);
    var min_consent_date;
run;

    

3. Using PROC MEANS

PROC MEANS can be used to calculate the minimum date:

proc means data=SDTM.DM min noprint;
    var rficdtc;
    output out=min_consent_date(drop=_type_ _freq_) min=MinRFICDTC;
run;

proc print data=min_consent_date;
run;

    

4. Using PROC SORT and DATA STEP

This approach involves sorting the dataset and extracting the first record:

proc sort data=SDTM.DM out=sorted_dm;
    by rficdtc;
    where rficdtc is not missing and armcd ne 'SCRNFAIL';
run;

data min_consent_date;
    set sorted_dm;
    if _N_ = 1 then output;
run;

proc print data=min_consent_date;
    var rficdtc;
run;

    

Conclusion

Accurately defining and recording the Study Start Date is essential for compliance with FDA regulations and avoiding submission rejections. Ensuring consistency across study data and metadata is key to a successful clinical trial submission process. Various methods in SAS, including SQL-based and procedural approaches, offer flexible options for deriving the study start date (SSTDTC) in SDTM.

References

Best Practices for Joining Additional Columns into an Existing Table Using PROC SQL

Best Practices for Joining Additional Columns into an Existing Table Using PROC SQL

Best Practices for Joining Additional Columns into an Existing Table Using PROC SQL

When working with large datasets, it's common to add new columns from another table to an existing table using SQL. However, many programmers encounter the challenge of recursive referencing in PROC SQL when attempting to create a new table that references itself. This blog post discusses the best practices for adding columns to an existing table using PROC SQL and provides alternative methods that avoid inefficiencies.

1. The Common Approach and Its Pitfall

Here's a simplified example of a common approach to adding columns via a LEFT JOIN:

PROC SQL;
CREATE TABLE WORK.main_table AS
SELECT main.*, a.newcol1, a.newcol2
FROM WORK.main_table main
LEFT JOIN WORK.addl_data a
ON main.id = a.id;
QUIT;

While this approach might seem straightforward, it leads to a warning: "CREATE TABLE statement recursively references the target table". This happens because you're trying to reference the main_table both as the source and the target table in the same query. Furthermore, if you're dealing with large datasets, creating a new table might take up too much server space.

2. Best Practice 1: Use a Temporary Table

A better approach is to use a temporary table to store the joined result and then replace the original table. Here’s how you can implement this:

PROC SQL;
   CREATE TABLE work.temp_table AS 
   SELECT main.*, a.newcol1, a.newcol2
   FROM WORK.main_table main
   LEFT JOIN WORK.addl_data a
   ON main.id = a.id;
QUIT;

PROC SQL;
   DROP TABLE work.main_table;
   CREATE TABLE work.main_table AS 
   SELECT * FROM work.temp_table;
QUIT;

PROC SQL;
   DROP TABLE work.temp_table;
QUIT;

This ensures that the original table is updated with the new columns without violating the recursive referencing rule. It also minimizes space usage since the temp_table will be dropped after the operation.

3. Best Practice 2: Use ALTER TABLE for Adding Columns

If you're simply adding new columns without updating existing ones, you can use the ALTER TABLE statement in combination with UPDATE to populate the new columns:

PROC SQL;
   ALTER TABLE WORK.main_table
   ADD newcol1 NUM, 
       newcol2 NUM;

   UPDATE WORK.main_table main
   SET newcol1 = (SELECT a.newcol1 
                  FROM WORK.addl_data a 
                  WHERE main.id = a.id),
       newcol2 = (SELECT a.newcol2 
                  FROM WORK.addl_data a 
                  WHERE main.id = a.id);
QUIT;

This approach avoids creating a new table altogether, and instead modifies the structure of the existing table.

4. Best Practice 3: Consider the DATA Step MERGE for Large Datasets

For very large datasets, a DATA step MERGE can sometimes be more efficient than PROC SQL. The MERGE statement allows you to combine datasets based on a common key variable, as shown below:

PROC SORT DATA=WORK.main_table; BY id; RUN;
PROC SORT DATA=WORK.addl_data; BY id; RUN;

DATA WORK.main_table;
   MERGE WORK.main_table (IN=in1)
         WORK.addl_data (IN=in2);
   BY id;
   IF in1; /* Keep only records from main_table */
RUN;

While some might find the MERGE approach less intuitive, it can be a powerful tool for handling large tables when combined with proper sorting of the datasets.

Conclusion

The best method for joining additional columns into an existing table depends on your specific needs, including dataset size and available server space. Using a temporary table or the ALTER TABLE method can be more efficient in certain situations, while the DATA step MERGE is a reliable fallback for large datasets.

By following these best practices, you can avoid common pitfalls and improve the performance of your SQL queries in SAS.

Saturday, September 7, 2024

Comprehensive SDTM Review

Comprehensive SDTM Review

Mastering the SDTM Review Process: Comprehensive Insights with Real-World Examples

The process of ensuring compliance with Study Data Tabulation Model (SDTM) standards can be challenging due to the diverse requirements and guidelines that span across multiple sources. These include the SDTM Implementation Guide (SDTMIG), the domain-specific assumptions sections, and the FDA Study Data Technical Conformance Guide. While automated tools like Pinnacle 21 play a critical role in detecting many issues, they have limitations. This article provides an in-depth guide to conducting a thorough SDTM review, enhanced by real-world examples that highlight commonly observed pitfalls and solutions.

1. Understanding the Complexity of SDTM Review

One of the first challenges in SDTM review is recognizing that SDTM requirements are spread across different guidelines and manuals. Each source offers a unique perspective on compliance:

  • SDTMIG domain specifications: Provide detailed variable-level specifications.
  • SDTMIG domain assumptions: Offer clarifications for how variables should be populated.
  • FDA Study Data Technical Conformance Guide: Adds regulatory requirements for submitting SDTM data to health authorities.

Real-World Example: Misinterpreting Domain Assumptions

In a multi-site oncology trial, a programmer misunderstood the domain assumptions for the "Events" domains (such as AE – Adverse Events). The SDTMIG advises that adverse events should be reported based on their actual date of occurrence, but the programmer initially used the visit date, leading to incorrect representation of events.

2. Leveraging Pinnacle 21: What It Catches and What It Misses

Pinnacle 21 is a powerful tool for validating SDTM datasets, but it has limitations:

  • What it catches: Missing mandatory variables, incorrect metadata, and value-level issues (non-conformant values).
  • What it misses: Study-specific variables that should be excluded, domain-specific assumptions that must be manually reviewed.

Real-World Example: Inapplicable Variables Passing Pinnacle 21

In a dermatology study, the variable ARM (Treatment Arm) was populated for all subjects, including those in an observational cohort. Since observational subjects did not receive a treatment, this variable should have been blank. Pinnacle 21 didn’t flag this, but a manual review revealed the issue.

3. Key Findings in the Review Process

3.1 General Findings

  • Incorrect Population of Date Variables: Properly populating start and end dates (--STDTC, --ENDTC) is challenging.
  • Missing SUPPQUAL Links: Incomplete or incorrect links between parent domains and SUPPQUAL can lead to misinterpretation.

Real-World Example: Incorrect Dates in a Global Trial

In a global cardiology trial, visit start dates were incorrectly populated due to time zone differences between sites in the U.S. and Europe. A manual review of the date variables identified these inconsistencies and corrected them.

3.2 Domain-Specific Findings

  • Incorrect Usage of Age Units (AGEU): Misuse of AGEU in pediatric studies can lead to incorrect data representation.
  • Inconsistent Use of Controlled Terminology: Discrepancies in controlled terminology like MedDRA or WHO Drug Dictionary can cause significant issues.

Real-World Example: Incorrect AGEU in a Pediatric Study

In a pediatric vaccine trial, the AGEU variable was incorrectly populated with "YEARS" for infants under one year old, when it should have been "MONTHS." This was not flagged by Pinnacle 21 but was discovered during manual review.

4. Optimizing the SDTM Review Process

To conduct an effective SDTM review, follow these steps:

  • Review SDTM Specifications Early: Identify potential issues before SDTM datasets are created.
  • Analyze Pinnacle 21 Reports Critically: Don’t rely solely on automated checks—investigate warnings and study-specific variables manually.
  • Manual Domain Review: Ensure assumptions are met and variables are used correctly in specific domains.

5. Conclusion: Building a Holistic SDTM Review Process

By combining early manual review, critical analysis of automated checks, and a detailed review of domain-specific assumptions, programmers can significantly enhance the accuracy and compliance of SDTM datasets. The real-world examples provided highlight how even small errors can lead to significant downstream problems. A holistic SDTM review process not only saves time but also ensures higher data quality and compliance during regulatory submission.

"""

Learn how to view SAS dataset labels without opening the dataset directly in a SAS session. Easy methods and examples included!

Quick Tip: See SAS Dataset Labels Without Opening the Data Quick Tip: See SAS Dataset Labels With...