{"id":3309,"date":"2024-06-10T11:22:44","date_gmt":"2024-06-10T15:22:44","guid":{"rendered":"https:\/\/cytel.agencyukdev.com\/perspectives\/visualizing-adam-a-practical-guide-through-examples\/"},"modified":"2024-08-22T07:38:37","modified_gmt":"2024-08-22T11:38:37","slug":"visualizing-adam-a-practical-guide-through-examples","status":"publish","type":"perspectives","link":"https:\/\/cytel.agencyukdev.com\/fr\/perspectives\/visualizing-adam-a-practical-guide-through-examples\/","title":{"rendered":"Visualizing ADaM: A Practical Guide Through Examples"},"content":{"rendered":"

Written by Silvia Faini, Principal Statistical Programmer, in collaboration with Angelo Tinazzi<\/em><\/p>\n

 <\/p>\n

An important component of clinical trial data submission to the FDA is CDISC’s Analysis Data Model, or ADaM<\/span>, which defines dataset and metadata standards. However, implementation of ADaM is not always straightforward, leading to inaccuracies and inconsistencies.<\/p>\n

At this year’s CDISC EU+TMF Interchange in Berlin, I had the opportunity to present “visualizing ADaM: A Practical Guide Through Examples,” co-authored with Angelo Tinazzi, where I shared how visualizing ADaM provides a guided approach that can address these issues and streamline the process.<\/p>\n

Here, we share some of the key takeaways.<\/p>\n

 <\/p>\n

<\/p>\n

Why a visual approach to ADaM?<\/strong><\/h2>\n

Over the years, the CDISC and CDISC ADaM teams have released additional documents with handy ADaM use cases to the Implementation Guidance (IG), demonstrating how ADaM can be used to support the most common statistical methods1<\/a><\/sup> or specific settings such as medical devices studies,2<\/a><\/sup> while maintaining good traceability.3<\/a><\/sup>\u00a0Additionally, several CDISC Therapeutic Area User Guides (TAUGs) provide specific analysis examples addressing various ADaM requirements in those particular settings.4<\/a><\/sup><\/p>\n

Typically, the ADaM datasets development process begins with study documents such as the Statistical Analysis Plan (SAP), accompanied by applicable CDISC ADaM guidance. By leveraging gathered knowledge and support from the company’s data governance structure, which includes tailored templates, guidance, and subject matter experts (SMEs), the statistical programmer initiates the design of ADaM datasets needed to support the analytical outputs outlined in the SAP. Despite continuous efforts to support team members with regular updates, we frequently encounter incorrect or inconsistent implementation of the standard, across multiple clients and therapeutic areas.<\/p>\n

\"\"<\/p>\n

To enhance the implementation of ADaM by statistical programmers at Cytel, we have developed visual shells based on our standard SAP table shells. These visual shells incorporate annotations to illustrate the ADaM dataset and variables to be utilized, variables to group or categorize, as well as any filters and additional conditions. These visual shells are accompanied by sample ADaM datasets and corresponding standard specifications tailored for Cytel automation tools.5<\/sup><\/a><\/p>\n

Furthermore, our development efforts extend to slide sets designed to train programmers through practical examples, ensuring a comprehensive understanding of ADaM’s application.<\/p>\n

\u00a0<\/em><\/p>\n

A simple example: A demographics table<\/strong><\/h2>\n

The following example makes use of the standard ADSL dataset, with its standard variables, either copied from SDTM or derived in ADaM. The table shell is completed with details of variables to be selected and the rationale. For example, this demographic table filters for the safety population; as such, we expect to have in the ADSL dataset a variable containing the actual treatment received. In this case, we choose the TRT01AN variable, and the variable to filter for the applicable subjects, SAFFL. Furthermore, given the fact that our standard tools work well with numeric variables, in addition to character versions of variables such as SEX, AGEGR1, etc., we need to plan to include variables SEXN and AGEGR1N.<\/p>\n

Figure 1: ADSL Dataset <\/strong><\/span><\/p>\n

\n\n\n\n
 <\/p>\n

\"\"<\/td>\n

ADaM Class: <\/span>ADSL<\/strong><\/span><\/p>\n

Because the table is on the Safety Population subset (SAFFL=Y<\/strong>), the Actual Treatment Variable should be used as column group (e.g., TRT01AN<\/strong>)<\/p>\n

Despite numeric version of variables such as SEX<\/strong> and RACE<\/strong> are permissible, it is a good practice to also add the numeric version to facilitate tool automation and the desired sorting in the outputs (not alphabetic) e.g., SEXN <\/strong>and RACEN.<\/strong><\/p>\n

In addition to AGE<\/strong> analyzed with continuous descriptive stats (copied from SDTM), the age is required to be analyzed in category, and the standard ADSL variable AGEGR1<\/strong> and its numeric version AGEGR1N<\/strong> are added to ADSL.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

 <\/p>\n

Treatment<\/strong>–emergent adverse events table<\/strong><\/h2>\n

For the analysis of treatment-emergent adverse events, we discussed two types of outputs.<\/p>\n

In the first output, the requirement is to analyze the occurrence of the treatment-emergent adverse events and their incidence using a hierarchical medical dictionary, MedDRA, through which we summarize the occurrences by system organ class and preferred term.<\/p>\n

Figure 2: ADAE Dataset<\/strong><\/span><\/p>\n

\n\n\n\n
\"\"<\/td>\nADaM Class: OCCDS \/ Sub-Class: <\/span>ADVERSE EVENT<\/strong><\/p>\n

In addition to the Safety Population subset (SAFFL=Y<\/strong>), and the appropriate treatment variables (e.g., TRT01AN<\/strong>), the Actual Treatment Variable should be used as column group (e.g., TRT01AN<\/strong>).<\/p>\n

ADVERSE EVENT is a sub-class of the OCCDS class, as such the variables AEBODSYS<\/strong> and AEDECOD<\/strong> became \u201a\u00c4\u00faRequired.\u201a\u00c4\u00f9<\/p>\n

For this type of analysis only the treatment emergent adverse event (TRTEMFL<\/strong>) should be used.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

In the second output, our objective is to provide an overview of the types of adverse events that occurred. This includes determining the number of subjects who experienced at least one adverse event, the number who experienced at least one serious adverse event, identifying the most severe adverse event, and quantifying the subjects who experienced adverse events leading to either treatment or study discontinuation, among other metrics.<\/p>\n

We could have used the same ADAE dataset created for previous output and applied selection and calculation in the analytical output program. However, to improve traceability, reproducibility (quality control), and to make the ADaM dataset analysis as ready as possible, we also have the option to create another ADAM dataset, ADAESUM, derived from ADAE, and applying a BDS structure. The annotated output shows both versions, with ADAESUM (BDS) and with ADAE (OCCDS).<\/p>\n

Again, our example provides detailed explanations and an extract of the ADAESUM dataset.<\/p>\n

Figure 3: ADAESUM Dataset<\/strong><\/span><\/p>\n

\n\n\n\n
\"\"<\/td>\nOption 1 – ADaM Class: OCCDS \/ Sub-Class: <\/span>ADVERSE EVENT<\/strong><\/p>\n

Filters on specific variables, e.g., TRTEMFL<\/strong>, AESER<\/strong>, AEACN<\/strong>.<\/p>\n

 <\/p>\n

Option 2 – ADaM Class: <\/span>BDS<\/strong><\/p>\n

In addition to the Safety Population subset (SAFFL=Y<\/strong>), and the appropriate treatment variables (e.g., TRT01AN<\/strong>), the Actual Treatment Variable should be used as column group (e.g., TRT01AN<\/strong>).<\/p>\n

Each condition needed for the summary output can be represented by a specific PARAMN<\/strong> \/ PARAMCD<\/strong> \/ PARAM<\/strong>, with AVAL<\/strong> (AVALC<\/strong>) containing whether the condition for the subject was satisfied or in case of severity the AVAL will contain the maximum observed severity among all AE each subject had. PARAMN<\/strong> will be also used to display each condition in the order as per planned table shell.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

\"\"<\/p>\n

 <\/p>\n

<\/h2>\n

Change from baseline with phantom baseline visit <\/strong><\/h2>\n

In this last example, I presented a table summarizing the change from baseline at each visit for vital sign parameters. For each visit, we present summary statistics for the actual observed value and the change from baseline. The peculiarity of this example is the baseline definition, defined by SAP as the average between observed value at screening and day-0 visit.<\/p>\n

Figure 4: ADVS Dataset<\/strong><\/span><\/p>\n

\n\n\n\n
\"\"<\/td>\nADaM Class: <\/span>BDS <\/strong><\/p>\n

Safety Population is used (SAFFL=Y<\/strong>), but results are presented without any split\/group by treatment (we do recommend keeping TRT01AN in ADVS).<\/p>\n

The Analysis Visit is derived in ADVS (AVISITN<\/strong> \/ AVISIT<\/strong>). This might be derived from SDTM VISITNUM \/ VISIT by applying some change in the wording to fulfill SAP requirement or apply some visit-windowing. As per the example dataset below the baseline visit (AVISITN<\/strong>=0 \/ AVISIT<\/strong>=Baseline) is a derived record \/ visit.<\/p>\n

AVAL<\/strong> and CHG<\/strong> are used for observed and change from baseline respectively. CHG is calculated from AVISIT=Baseline<\/strong>.<\/p>\n

Not all records \/ visit will be used in analysis (ANL01FL=Null<\/strong>) but kept in ADVS for traceability.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

\"\"<\/p>\n

 <\/p>\n

From the above ADVS dataset:<\/p>\n