This analysis was submitted by John Brega and Jane Diefenbach of PharmaStat. It is based on methods they have developed through their eCTD submissions consulting practice.
We call the Data Guide document either tabulations-data-guide.pdf or analysis-data-guide.pdf, depending on which type of database it describes. In the submission it lives with the data, just like the define.pdf or define.xml. We did not call it a Reviewer’s Guide because that causes a name collision with the Reviewer’s Guide document typically included in Module 1, which is a guide to the entire submission and mainly the work of the Clinical and Regulatory groups.
We have provided links to examples of both the Tabulations Data Guide and the Analysis Data Guide. We have also described and provided an example of a Guide to Analysis Programs. The examples make it easier to visualize what we’re describing below in the analysis of the issues, but the issues can be addressed by many different styles of document. It is important to understand the issues and the rationales for the document contents to fully understand the examples.
Data Guide for an SDTM Database
Click Here for a generic example of an SDTM tabulations-data-guide.pdf document.
Click Here for a more detailed example of a Data Guide document for a public domain TB submission.
For an SDTM database the document has six sections:
1. Intro to the study and database
We provide one to three paragraphs at the top of the document, starting with the name and title of the study, followed by a few general observations about it such as whether the database includes screen failures, whether the study is ongoing, whether it is the pivotal study, which studies are included if it’s an ISS or ISE database, etc.
2. Table of Contents and bookmark panel
3. Where to Find Key Data
One of the difficulties reviewers have, even with SDTM data, is to figure out where to find the basic data they need to review, and which datasets to ignore because they’re just administrative data, like lab sample dates that are already reconciled with the LB dataset. We typically put most or all of the following subsections under this header:
· Demographics and Compliance
· Exposure to Study Treatment
· Subject Disposition
· Safety
· Efficacy
· Pharmacokinetics/Pharmacodynamics
· Trial Design Model Datasets
Each subsection gives the names and titles of the datasets relevant to that category of data. For example, if only Drug Accountability data was collected for the study, it would mention that DA (Drug Accountability) is the primary source for exposure data, and that the EX (Exposure) domain is derived from the DA data. The Efficacy section it might describe which custom domains address which study endpoints. For a phase I study it might simply say that no efficacy data were collected. There could be other subcategories as needed. For example, a Thorough QT study might have a section to identify the ECG and PK data, describe their relationships, indicate where to find the means of the replicates, etc.
4. Overview of Custom Domains
We typically don’t give descriptions of the standard domains, but we find that the custom domains can be very obscure, limited as we are to two-character dataset names and 40 character dataset labels. We provide a description of each custom domain. The description is usually just a short paragraph describing the dataset structure and purpose, what kind data it contains, how it relates to other datasets, and how to identify the subjects or records of particular interest. If it’s just administrative data we would mention that.
5. Datasets Not Submitted
It frequently happens that a study end up with no data collected for some domains. Since the SDTM rule is to not submit empty datasets, the database can have holes that make it appear that the sponsor was asleep at the switch. This most frequently happens in phase I healthy volunteer studies where, for example, there may not be any subjects with IE criteria not met, or any AEs. You’d kind of wonder if there weren’t an AE dataset, wouldn’t you? For later phase studies there might be a collection instrument for pregnancies, but none were reported. And so forth.
6. Derived Datasets
Sometimes SDTM datasets are completely derived, and in these cases it’s important to describe the derivation methods and the assumptions that are made. For example, if EX is derived from DA, you often end up with EX records that represent an average daily dose for each “continuous dosing interval” since you don’t have a record of each dose taken. It’s important to know this if you want to associate AEs and other data with specific cumulative dose levels, for example.
If a DV (Protocol Deviations) dataset is submitted it is essential for the reviewer to know what categories of deviations or violations were included in the dataset, and what rules or data sources were used to identify them. If you get a dataset with a handful of trivial deviations and no explanation, you have no idea whether those were all the deviations there were, or whether they were the only ones collected on a CRF, for example.
We put the descriptions of derivations in their own section because they can sometimes be lengthy and are a different kind of narrative from the descriptions of the datasets, which are focused on how to use and interpret them.
Data Guide for an Analysis Database
Click Here for a generic example of an ADaM analysis-data-guide.pdf document.
We use a similar template for other types of databases and adjust it to address the reviewer’s needs. We treat ADaM documentation the same as for any other legacy analysis database. The first three sections above are included and perform the same function. Section 4 is an overview of all datasets, since only ADSL is the only standard analysis domain. One thing we include in the description of ADSL is the list of the “Core” variables that are merged onto all the other analysis datasets.
There is no need for section 5 (Datasets not Submitted). Section 6 we typically roll up into the dataset overviews if the material is not too voluminous. This would include dataset-level and row-level descriptions of the structure, derivation and usage of the data. Occasionally a study will involve a large amount of complex derivation. In these cases we add another section on the end called Computational Methods. We have seen these sections get as large as 70 – 80 pages. A handbook for scoring a complex questionnaire is an example of a multipage derivation description that might be included in its entirety for the benefit of the reviewer.
Data Guide for an “Item 11” Legacy Database
The template we use for legacy “Item 11” database documentation is essentially the same as for an analysis database. In particular we include a description of every dataset since there are no standard datasets with commonly understood purposes and structures. Since this type of data is typically less derived than SDTM, a Computational Methods section is rarely needed.
Analysis Program Guide
Besides the define.xml/define.pdf, data guides and blankcrf.pdf, if a submission includes analysis programs we also include an analysis-program-guide.pdf document. This is because the names of sponsor SAS programs do not usefully describe their purpose, and without a guide to the program set a reviewer has little hope of making good use of them. The purpose of the guide is to identify every component of the submission that was produced by a program (e.g., analysis datasets, tables and figures), the program that produced it, and the inputs the program used. We put this document with the analysis data and related documentation because that’s where reviewers look for documentation. There is an obvious case to be made for putting it with the programs, especially if it were an expected document.
Click Here for a generic example of an analysis-program-guide.pdf document.
We build the program guide as a spreadsheet which we then convert to a pdf. It has four tabs:
1. Index Page
This tab serves as a table of contents for the other three tabs
2. Analysis Dataset Programs
This tab has an entry for each submitted analysis dataset. It specifies the dataset name and description (label), the program that creates it, and the complete list of inputs. Everything except the dataset label is a hyperlink to the named file.
3. Table and Figure Programs
This tab has an entry for each table and figure included in the Clinical Study Report, though not necessarily the in-text tables. We do not include listings, as their programs do not typically perform interesting derivations. The tab is ordered by table/figure number. It specifies the table or figure number, the title of the table or figure, the program that created it, and the complete list of inputs to the program. This table can be repetitive if many tables are produced by a single program, but it makes it very easy for a reviewer to identify a program of interest by looking up the table or figure number.
4. Macros
Frequently the analysis programs will employ a suite of SAS macros to perform common functions. There may be many such macros used, but usually only a few are of interest to a reviewer. This tab identifies the macros of interest. We define these to be macros that perform some substantive derivation that contributes to results in an analysis dataset, table or figure. We exclude utility macros that perform formatting, printing or common data manipulation functions. Out of a possible 70 – 100 macros used by the analysis programs we rarely submit more than about eight.
The tab has an entry for each submitted macro. It lists the macro name, a short description of its function, and the complete list of programs that call the macro. Everything except the description is a hyperlink to the referenced program file.