PhUSE 2015

Paper CD13

ADaM Reviewers Guide Interpretation and Implementation

Steve Griffiths, GlaxoSmithKline, Stockley Park, UK

ABSTRACT
Throughout the course of a study, teams will make a lot of decisions about dataset design and interpretation of the
Implementation Guide. Unfortunately, the study programmer cant form part of the final submission package and so
this important information needs to be written down.

In addition to the myriad of mandatory ADaM submission components, the ADaM reviewers guide is optional, but
highly recommended as it provides the reviewer with the important information pertaining to the ADaM data, and
therefore hopefully reduces the number of questions to the sponsor. This paper discusses the implementation of the
ADaM reviewers guide and the interpretation of the sections from the perspective of a first time author.

INTRODUCTION
Like most standards, there can are many interpretations of the guidelines therefore leading to many different
possible implementations of these guidelines.

DISCLAIMER
The scope of this paper is to present the interpretations of these guidelines by a first time author of a Reviewers
Guide and as such any opinions, views or suggestions stated within this paper are those of the author, and they are
not necessarily correct.

It is understood that a review of this paper may invoke a reaction of this goes against the guidelines. Hopefully it will
also invoke a debate / discussion of some of my decisions.

OVERVIEW OF GUIDE
The ADaM Reviewers Guide (ADRG) consists of seven sections (Introduction, Protocol Description, Analysis
Considerations Related to Multiple Analysis Datasets, Analysis Data Creation and Processing Issues, Analysis
Dataset Overview, Data Conformance Summary, Submission of Programs) and optional appendices.

A varying number of sub-sections exist within each section; the majority of which are required. It is my opinion that
the very few optional sub-sections should not however be omitted. The rationale being the FDA Reviewer may be
used to a particular numbering convention and the inclusion of all sections both maintains this and removes any
doubt that sections were forgotten. A simple statement stating Not applicable should suffice.

Further justification for inclusion is that throughout the ADRG there are bulleted questions intended to assist the FDA
Reviewer which must be answered and should not be deleted if not applicable.

Each section will be discussed in turn.

SECTION 1 - INTRODUCTION
What is the purpose of the ADRG? It is recommended that you refer to the ADRG Template to use the standard text.

Non-industry standard / sponsor specific acronyms are listed in a tabular form. This acronym table is one of the
aforementioned optional sub-sections, but to maintain the numbering its easy to state No acronyms used.

Another table is supplied within this section to list the ADaM, SDTM and Define versions used within the study.
Although the guidelines say its not necessary to repeat dictionary and controlled terminology versions, I included
them for completeness. The versions of any published questionnaire and scoring algorithms used in analyses are
listed in the relevant sub-section relating to the dataset in question.

At first glance, the final component of this first section detailing the source data for analysis dataset creation looks
simple enough to complete, and if solely using SDTM as a source it remains so. Its possible that more and more
data will be provided in alternative formats (i.e. C.S.V. files), and whilst this data was incorporate into the SDTM data
I chose to mention this additional data within this section, for example:

1
 PhUSE 2015

PK concentrations provided from an external source as a CSV file were added to the source datasets, forming the
SDTM PC domain

SECTION 2 - PROTOCOL DESCRIPTION

Both protocol number and title are self explanatory. When listing the protocol versions (original and amendments)
the date from when applicable was also included.

A picture is worth a thousand words, so the use of a graphical protocol schema is easily the best way to display the
relationship between APERIOD, APHASE and TRTxxP / TRTxxA variables. I also opted to include text from the
Reporting Analysis Plan (RAP) to describe parts of the study design not evident from the schematic.

Whilst not in the template (in this section at least), the Pilot Study example briefly explained the population flags. I
expanded upon this by adding a new section containing a table summarizing the study populations. Each population
was hyper-linked to text to further explain the population and identify the population flags.

SECTION 3 ANALYSIS CONSIDERATIONS RELATED TO MULTIPLE ANALYSIS DATASETS

The first of the bulleted questions designed to aid the FDA Reviewer can be found in the initial sub-section in which
differences between the SDTM and ADaM data are discussed.

Has data (for example, run-in / screening failures) been removed? If so, then why? However, if these are present in
the data, then it is recommended that inclusions are discussed in the relevant discussion for that / those dataset(s).
Within my ADRG I chose to list the ADaM datasets containing run-in failures without discussion in the relevant
section 5.2.x

Are there any other ways in which SDTM and ADaM differ? I had to re-derive the baseline flags within the ADaM as
those used in SDTM did not allow for the more complex definition required for the safety data, especially when
dealing with ECG and vital sign triplicate readings (where a derived baseline value was generated).

By the very nature of the ADaM model, STUDYID and USUBJID will always be listed in the table describing the core
variables. These are those variables which exist in most (if not all) datasets, for example sex, age, race, population
flags, treatment / arm variables.

Three more of the bulleted questions follow to aid discussion of the relationship between planned arm (ARM) and
treatment (TRTxxP) variables; actual arm (ACTARM) and treatment (TRTxxA) variables, and the usage of planned
vs. actual treatment variables in the analysis. In the case of my experience, actual treatment was used for all safety
analyses, with planned treatment used for all other analyses.

It is not unheard of for subjects to receive the incorrect treatment, hence the actual vs. planned treatments. This,
along with anything else affecting the analysis of an individual subject is discussed within a sub-section. The
guidelines list examples of discussion topics. Although listed as closed questions, it is important to explain / describe
how to identify subjects, or how the situation was dealt with. Within my study there were subjects with incorrectly
defined strata. Variables were present within ADSL to identify these subjects and it was highlighted that analyses
were performed based upon actual strata.

Visit windowing and inclusion of unscheduled visits should be explained. Within my study there was quite a complex
visit windowing plan which differed from dataset to dataset. Rather than reference corresponding pages in the RAP,
the tables showing the plan were placed in an appendix within the ADRG itself. The rules regarding the slotting and
usage of unscheduled visits were also explained. With all this slotting, its possible for multiple assessments to
become assigned to the same analysis visit (AVISIT / AVISITN). The rules used to distinguish which assessments to
summarize were described (and the identifying variable), along with reference to the specific section in the RAP
should the reviewer require further explanation on the rationale.

In an ideal world, partial dates wouldnt exist. Reality holds a different story though and so the rules used across
multiple datasets should be explained. I chose to state that date imputation was performed and would be discussed
in more detail at the dataset level. In a similar manner, it was decided that the explanation of any usages of DTYPE
would also be discussed within the relevant dataset level.

SECTION 4 ANALYSIS DATA CREATION AND PROCESSING ISSUES

Submission size constraints exist and so it may be necessary to split ADaM datasets into smaller components. If this
is necessary then details must be provided as to how this was performed (for example lab category), and the need to
reassemble the data prior to analysis. Although this sub-section is only required if split dataset are present, I decided
to include with a simple There are no split datasets in the study. The design of the domains may also negate the

2
 PhUSE 2015

need to split datasets. My study had a lot of different types of questionnaire data all grouped together into the SDTM
QS domain. It was decided at an early stage to create a unique ADaM dataset for each type of questionnaire data as
opposed to have a huge ADQS.

As per definition, all ADaM datasets have a dependency upon ADSL. Other dependencies should be described
either in tabular form or flow chart.

The remaining two sub-sections are optional and discuss intermediate datasets and variable conventions. It is
recommended that you review the PhUSE guidelines for these two sections as they were not needed for the ADRG
for my study.

SECTION 5 ANALYSIS DATASET DESCRIPTIONS

The overview starts with one of the bulleted questions which must be answered. Do the analysis datasets support
all protocol and SAP specified objectives?

The study objectives were copied from the RAP into a table, along with the ADaM dataset(s) used to assess that
objective. For example:
Objective ADaM Dataset
Assess the effect of study drug on Health-related ADALSFRS, ADALSAQ, ADCGI, ADCRSS, ADEQ5D
quality of life of ALS patients
Assess the safety and tolerability of intravenous (IV) ADAE, ADEG, ADLB, ADVS, ADPSRAE, ADLIVER
study drug

Details of datasets supplied for supportive purposes but not used in analyses should also be provided.

What follows is an introduction to the analysis datasets in the form of an inventory, best displayed in a tabular format
(as opposed to textual). Starting with ADSL, alphabetically list all analysis datasets with a separate row for each
entry, hyperlinked to further information in the Dataset Dataset label where additional explanation is required.
Each row must have ADaM class, functional categories and structure.

Since all studies have ADSL, section 5.2.1 is titled ADSL Subject Level Analysis Dataset. Although not a bullet
question it is worth mentioning if ADSL has the same number of records / subjects as in the SDTM DM domain and
explaining any differences. The guidelines suggest listing the analysis populations here, which I had placed in
section 2.

I chose to supply two tables, one for covariates (and associated variables) and the other to list variables created to
support additional analysis.

As already mentioned a separate section then exists for each analysis dataset needing further explanation. For
those datasets not having a BDS class I started by explaining how the dataset was constructed. For example ADAE
was constructed according to the draft ADaM Hierarchical Occurrence Data Standard v1.0.

If not obvious, I also provided traceability back to the SDTM data by explaining how the SDTM data was subset, or if
the ADaM was created by using SUPP, or FA domains, for example:
ADALS contains data from the MH and FAMH SDTM domains, sub-setting MH where
MHTERM='AMYOTROPHIC LATERAL SCLEROSIS'.

or

ADEQ5D contains records from QS where QSCAT eq 'EQ-5D-5L'.

The rules for dealing with partial dates and times were explained:
If the partial date is a start date, a '01' was used for the day and 'Jan' was used for
the month. However, if this created a date prior to start of treatment (Week 0 Day 1)
and the event could possibly have occurred during treatment from the partial
information, then the Week 0 Day 1 date was assumed to be the start date. The AE
will then be considered to start on-treatment (worst case).
If the partial date is a stop date, a '28/29/30/31' was used for the day (dependent on
the month and year) and 'Dec' was used for the month

3
 PhUSE 2015

There was one instance where the PARAMCD had to be built based upon the values of several SDTM variables to
ensure uniqueness. In this case I described how the parameter values were created so that the AVAL could be
traced back to the correct SDTM value
The first six letters of PARAMCD is slowly built-up based upon the values of MKTESTCD, MKLAT
and MKLOC. The first two letters indicate if the test is Extension, Flexion or Abduction. The next
letter provides the side; left or right, with the next three letters giving the body location. If needed the
final two letters indicate if the value is Best Response, or Able to break.

Where derivations have taken place, for example in providing domain scores in questionnaire data, I supplied a table
to summarize the domain name, total, associated PARAMCD values and which original items contribute to the score,
thus:
Domain PARAMCD Question DTYPE
items
Physical mobility ALSASUB1 1-10 SUM
Activities of daily living and independence ALSASUB2 11-20 SUM
Eating and drinking ALSASUB3 21-23 SUM
Communication ALSASUB4 24-30 SUM
Emotional reactions ALSASUB5 31-40 SUM
Total score ALSATOT 1- 40 SUM
ALSAQ-5 ALSAQ5 9,11,22,25,34 SUM
In some instances, these tables were taken directly from the RAP.

As in common in a lot of safety data, the maximum at any time-point is often provided in summary tables. For those
datasets I provided information describing how these records can be identified, typically DTYPE=MAX, and
AVISITN=285 (AVISIT=Max On-Treatment).

If visit windowing was applied, then a simple statement was added to that affect, with reference to section 3.5 in the
ADRG.

Where (non-population) flags exist in any dataset, they were described. Typically they were flags to identify records
for a particular analysis.

SECTION 6 DATA CONFORMANCE SUMMARY

This section of the ADRG is for the purpose of describing how the ADaM data was validated, and has two sub-
sections - one dealing with conformance inputs and the other to summarize any issues.

The first of these has three bulleted questions which must be answered. If the analysis datasets were evaluated
with conformance with CDISC ADaM Validation Checks then further information about which software and versions
used should be supplied:

All datasets were evaluated for conformance with CDISC ADaM Validation Checks, using
OpenCDISC Validator v2.01, with config-adam-1.0.xml and CDISC Controlled Terminology
Version 2011-07-22

The final two questions pertain to the define.xml file. Namely were the ADaM datasets evaluated in relation to
define.xml, and was define.xml itself evaluated.

Unless you are very lucky, there will be issues in the OpenCDISC (or equivalent other) validation report. The findings
are summarized in a table, giving the dataset(s) name, diagnostic message, severity, count (i.e. how many
instances), and explanation.

As the study used APHASE without APERIOD, most datasets had warning message AD1015. I chose to explain this
to state that APHASE was used to differentiate pre-treatment, on-treatment and follow-up periods of the study, rather
than a categorization of APERIOD which was not needed for a parallel-group study.

Unfortunately, current versions of OpenCDISC validator do not recogise ODS style datasets other than ADAE, and
report lack of AVALC / AVAL as errors. This was easily explained stating datasets were not BDS structure.

In order to facilitate the use of internal reporting tools, the treatment variables needed a very specific naming
convention which was at odds to the validator rules. These expect TRTxxAN etc, but TRTAN was needed. Again a
simple statement was provided to explain their presence in the data. Note that the expected variables were also
present.

4
 PhUSE 2015

There was one error which was data specific. One of two possible questions was asked / answered depending upon
the medical history of the subject. Unfortunately as the PARAMCD was the same for both types of question, there
were two different sets of AVALC for the same values of AVAL. It was decided to keep the data as per the CRF and
SDTM data and thus explanation was required in the report.

SECTION 7 SUBMISSION OF PROGRAMS

This final section of the ADRG is needed if programs are to be included in the submission. Since this was not
needed in the instance discussed within this paper, it is advised you refer to the PhUSE guidelines for creating the
ADRG.

CONCLUSION
The ADaM Reviewers Guide has potential to be a very long document, depending upon how much information you
put in. I decided to copy sections of the RAP into the ADRG to ensure a consistent text between the two documents
and to make it easier for the reviewer.

I would recommend that its creation is not left until the end of the reporting process, especially when describing the
analysis datasets themselves, and if a team has worked on the creation of the analysis datasets then I would
suggest that the individual programmers write about their own datasets.

Most of the content of the ADRG is of a high level overview. The guide comes into its own when discussing the
analysis datasets themselves and when combined with any visit slotting and derivations / imputation rules, it should
be possible to fully explain everything, thus taking information from the head onto paper.

The ultimate aim is to reduce the amount of questions back to the sponsor, and so I think the development of
ADRGs is a cyclic learning experience. If sponsors receive questions then learnings can be made to address similar
questions in subsequent study guides.

My experience has shown that there are areas open for interpretation, and I accept there could well be parts better
suited for different sections. This was my first ADRG, and I doubt it will be my last.

RECOMMENDED READING
PhUSE ADaM Reviewers Guide contained within the package located here:
http://www.phusewiki.org/wiki/index.php?title=Analysis_Data_Reviewer%27s_Guide

CONTACT INFORMATION
Your comments and questions are valued and encouraged. Contact the author at:
Steve Griffiths
GlaxoSmithKline
1-3 Iron Bridge Road
Stockley Park West
Uxbridge
Middlesex UB11 1BU
stephen.j.griffiths@gsk.com

Brand and product names are trademarks of their respective companies.