This article was written based on an interview. Exploring SAS courses: thoughts on my learning journey My journey started with programming eLearning courses that got me hooked and curious about a wide range of topics. These online lessons were great because they were short and focused on technical stuff. But […]
Reflecting on learning as both a student and an educator was published on SAS Users.
In today’s fast-paced business environment, effective project management is crucial for the successful completion of tasks and achieving organizational goals. As technology evolves, so do the tools we use to facilitate project management. One such tool…
SAS has a programming language, but IS that all it is? Nope, but it still ranks high as a most marketable programming skill.
The post Is SAS a programming language? appeared first on The SAS Dummy.
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.
The EC domain is intended to capture exposure data exactly as it is collected in the study. This is useful when the collected exposure data is complex or variable, such as when doses or regimens vary between subjects or over time.
The EX domain is designed to represent planned exposure data—what was intended or scheduled in the study protocol. EX typically includes drug administration data that reflects the planned dosage, route, and frequency, regardless of minor deviations in administration.
The SDTM IG 3.4 version introduces more clarifications on when to use EC vs. EX, emphasizing the importance of using EC when there is variability in exposure that cannot be easily captured in EX. SDTM IG 3.4 also provides additional examples and details on mapping complex exposure data, particularly for biologics or therapies with varying administration schedules.
In summary, EC is used for more complex, collected exposure data, while EX is used for planned, consistent exposures based on the protocol. The SDTM IG 3.3 and 3.4 versions emphasize using EC when there is significant variation in the collected data.
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.
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 |
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.
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 |
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.
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 |
The SDTM IG (Implementation Guide) versions 3.3 and 3.4 provide specific guidance on when to use the EC and EX domains:
The EC and EX domains both play important roles in capturing exposure data in clinical trials. By understanding when to use each domain, you can ensure that your study data accurately reflects both the planned and actual administration of investigational treatments. As the SDTM guidelines evolve, leveraging both domains appropriately helps ensure that data is captured comprehensively and consistently.
Fitting a Gradient Boosting Model – Learn how to fit a gradient boosting model and use your model to score new data In Part 6, Part 7, and Part 9 of this series, we fit a logistic regression, decision tree and random forest model to the Home Equity data we […]
Getting Started with Python Integration to SAS Viya for Predictive Modeling – Fitting a Gradient Boosting Model was published on SAS Users.
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 meeti…
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.
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.
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.
ALTER TABLE for Adding ColumnsIf 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.
DATA Step MERGE for Large DatasetsFor 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.
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.
html_content = “””
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.
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:
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.
Pinnacle 21 is a powerful tool for validating SDTM datasets, but it has limitations:
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.
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.
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.
To conduct an effective SDTM review, follow these steps:
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.
“””