Written by Silvia Faini, Principal Statistical Programmer, in collaboration with Angelo Tinazzi

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

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.

Here, we share some of the key takeaways.

Why a visual approach to ADaM?

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 methods or specific settings such as medical devices studies, while maintaining good traceability. Additionally, several CDISC Therapeutic Area User Guides (TAUGs) provide specific analysis examples addressing various ADaM requirements in those particular settings.

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.

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.

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

A simple example: A demographics table

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.

Figure 1: ADSL Dataset

Treatment-emergent adverse events table

For the analysis of treatment-emergent adverse events, we discussed two types of outputs.

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.

Figure 2: ADAE Dataset

ADaM Class: OCCDS / Sub-Class: ADVERSE EVENT In addition to the Safety Population subset (SAFFL=Y), and the appropriate treatment variables (e.g., TRT01AN), the Actual Treatment Variable should be used as column group (e.g., TRT01AN). ADVERSE EVENT is a sub-class of the OCCDS class, as such the variables AEBODSYS and AEDECOD became “Required.” For this type of analysis only the treatment emergent adverse event (TRTEMFL) should be used.

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.

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).

Again, our example provides detailed explanations and an extract of the ADAESUM dataset.

Figure 3: ADAESUM Dataset

Option 1 – ADaM Class: OCCDS / Sub-Class: ADVERSE EVENT Filters on specific variables, e.g., TRTEMFL, AESER, AEACN.   Option 2 – ADaM Class: BDS In addition to the Safety Population subset (SAFFL=Y), and the appropriate treatment variables (e.g., TRT01AN), the Actual Treatment Variable should be used as column group (e.g., TRT01AN). Each condition needed for the summary output can be represented by a specific PARAMN / PARAMCD / PARAM, with AVAL (AVALC) 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 will be also used to display each condition in the order as per planned table shell.

Change from baseline with phantom baseline visit

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.

Figure 4: ADVS Dataset

ADaM Class: BDS Safety Population is used (SAFFL=Y), but results are presented without any split/group by treatment (we do recommend keeping TRT01AN in ADVS). The Analysis Visit is derived in ADVS (AVISITN / AVISIT). 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=0 / AVISIT=Baseline) is a derived record / visit. AVAL and CHG are used for observed and change from baseline respectively. CHG is calculated from AVISIT=Baseline. Not all records / visit will be used in analysis (ANL01FL=Null) but kept in ADVS for traceability.

From the above ADVS dataset:

• Lines 3 and 9 show the derive baseline visit with DTYPE variable, which identifies it and the method used for the derivation (AVERAGE). ABLFL is set to ‚ÄúY.‚Äù
• Lines 1, 2, 7, and 8 will not be used in the analysis (ANL01FL=Null) because they occurred before the phantom derived ‚Äúbaseline‚Äù visit, but were kept in the ADaM dataset showing traceability, e.g., from which the baseline visit was derived.
• Lines 5 and 11 will not be used in the analysis (ANL01FL=Null) because they were unscheduled visits. However, the records are kept in the ADaM dataset showing traceability so that reviewer is aware which information was not used in the analysis. Eventually, if AVISIT/AVISTN are derived using some windowing.
• All records post baseline have the change from baseline (CHG) derived, including the unscheduled visits.

Key takeaways

By visualizing ADaM, the choice of the ADaM structure is guided and lets the programmer select the proper dataset structure, check the need of specific variables (e.g., population flags, treatment variables), and check the presence of the data required in the analysis (e.g., collected/derived parameters, hierarchical variables).

The visual approach is highly beneficial to ADaM newcomers, streamlining ADaM specifications and programming and standard outputs production, and it gives more time to focus on non-standard outputs, which are usually more challenging than standard ones.

Internally, this is another step to improve the Cytel automation tools suite (Lighthouse, ALPS, PRISM) and to move toward a more efficient process.

“Sharing is caring” — I feel this motto well captures my feeling when presenting at conferences. It is always a great experience: sharing what we implemented or how we overcame common challenges allows a good discussion with the attendees.

Interested in learning more?

Download Angelo Tinazzi’s new ebook, “The Good Data Submission Doctor on Data Submission and Data Integration to the FDA”:

Share Via