Download The Use of SAS Software as a Data Base for Compiling Safety Data on New Pharmaceuticals

THE USE OF SAS SOFTWARE AS A DATA BASE FOR COMPILING
SAFETY DATA ON NEW PHARMACEUTICALS
David E. Tappe, Syntex Research
I. ABSTRACT
analyzed, just prior to submitting a New Drug
Application (NDA) to the regulatory agency.
The problem of having to pool and summarize
safety data from many clinical trials to
satisfy governmental requirements for
approving an investigational new drug for
marketing was simplified using a SAS' data
base.
Safety data from each trial was
collected on an ongoing basis and saved in a
SAS data library of 5 files, each containing
related or similarly structured data. In
this way, the data were stored in a uniform
manner in one identifiable place and
ambiguities or inconsistencies in the data
were identified and resolved at the time the
study was analyzed, when such resolutions
could easily be obtained. The system was
facilitated by incorporating the creation of
files of safety information for individual
studies into selected programs in a
standardized library of SAS software used in
analyzing each study.
Figure 1 shows the steps necessary to
transform clinical trial data entered into
our clinical data base into the reports to be
submitted as part of an NDA.
III. THE PROBLEM
Our department of Biostatistics and Clinical
Information Processing was committed to
analyzing a large number of studies involving
Syntex' new cardiovascular drug Nicardipine
with indications in both angina and
hypertension.
An integral part of this
analysis was to be the overall safety summary
that out of necessity would include safety
data pooled across all studies, regardless of
indication.
Pooling across many studies like this
presents a number of problems. One is that
each study usually is of a different deSign,
and the pertinent data will have been
collected in a slightly different manner.
This leads to the same information being
contained in different variables with
different logic behind how the data from each
study are entered. In order to pool this
information, each study must have its data
modified to make it compatible with the other
studies. Interim inspections of safety data
are often requested. Each time one is to be
done, all available data from each study to
be included must be collected and modified as
necessary so the data can be compiled as one
unit.
II. INTRODUCTION
In order to obtain the regulatory approval
necessary to bring a newly developed
pharmaceutical product to the market, farge
quantities of data relating to patient
experiences on the drug must be collected.
This normally involves compiling data from
many large scale clinical trials that are
designed to demonstrate both the efficacy and
the safety of the drug.
Depending on the particular characteristics
of the investigational drug, the disease or
condition It Is deSigned to treat, the
available resources and other factors, data
from several thousand patients, from 20 or
more studies may be collected over a period
of several years. Each individual study is
analyzed independently for its efficacy and
safety once its data collection is complete.
Another problem in pooling over a large
number of studies is that each study has its
own data inconsistencies that are best
handled on a case by case basis. The report
tables may be modified to display the problem
data as it is resolved, but often there is no
way to reflect the correct resolution within
the structure of our clinical trial data
base. As a result, the pooled data could end
up with many inconsistencies that may never
be identified or be resolvable because of the
often long time lag between the study
completion and the final pooled analysis.
Demonstrating the safety of a new drug in a
!arge population of patients is just as
Important as demonstrating that the drug is
effective. This involves reporting the
incidence of patient adverse experiences as a
function of other parameters. For example,
adverse experiences may be summarized by age,
by sex, and by dose of therapy. In addition,
other factors such as the concomitant
medications a patient was on may be used to
explain certain adVerse experiences reported.
In order to obtain sufficient numbers of
patient experiences on the new drug, data on
adverse experiences, concomitant medications
and diseases, laboratory analyses, demographiCS, and dosing regimens from all
available studies must be pooled and
The circumstances surrounding the preparation
of data for an NDA submission are often such
that the manpower needs for analyzing studies
are greatest right before a submission when
deadlines are very tight. Since the overall
safety analysiS cannot be done until all the
data is in, any time saved in conducting the
pooled analysis is even more valuable.
380
I,
,
SASSOFTWARE
LIBRARY STANDARDIZED
PROGRAMS
MODIFIED FOR STUDY
DATA IS
EXTRACTED FROM
DATABASE INTO
SASDATASET
~
/
ANALYSIS
T
OAT A LISTINGS
SAFETY DATA
FILE FOR STUDY
ADDED TQ THE
SAFETY DATABASE
(COMBINED WITH
CLINICAL
L-
REPORT
STATISTICAL
REPORT
OTHER STUDIES)
1
/
'\
SHORT·TERM
SAFETY SUMMARY
REPORTS!
SUMMARIES
L-
COMPILED AND
LONG-TERM
REVIEWED
SAFETY
SUMMARY
j
SENTTO
REGULATORY
AGENCY
FOR APPROVAL
TO MARKET
Figure 1. Flow of the analysis of clinical trial data in
preparation for a New Drug Application.
Working with a biostatistician, each study
typically was analyzed by one bioanalystl
programmer who would be responsible for
collecting the safety information into files
in the study's SAS data library that were of
the exact same structure as the safety data
base flies. Once the study analysis was
complete, the new Information from that study
would be added to the safety data base.
IV. THE SOLUTION
A Safety Data Base
For our purpose, the best way to solve all
these problems proved to be creating a data
base of safety 'information using SAS
software. Since all of our individual study
analyses are performed using SAS software
with data stored in SAS data libraries, it
was a natural step to create a library of SAS
files containing only relevant safety
Information across all stUdies for the
Nicardipine project. The key to the suceess
of this solution was in collecting and
cleaning up the data as soon as it was
available and in saving like data from
different studies in exactly the same way,
matching up data formats and variable names
and saving as one file.
One advantage of this solution was in
creating a single repository of data that
could be monitored and controlled by one
individual or a small group. This helped
ensure the security of the data base and also
improved the efficiency of monitoring the
completeness and compatibility of each
study's safety data, most of which were
prepared by different people. This also
greatly simplified taking "snapshots" of the
safety data for interim inspections and
summaries.
381
Another advantage to this solution was In the
way data problems could be handled. Data
inconsistencies, om missions, patients to be
excluded and other data questions are best
resolved at the time the study is analyzed.
This is necessarily done during the course of
analyzing a study. However. due to the
nature of some data resolutions, it may not
be possible to update our clinical trial data
base to reflect the correct resolution of the
problem. By structuring the safety files
appropriately and Incorporating changes where
necessary, all problems could be accounted
for In the safety data base. For example, a
patient may experience an adverse experience
on the same day he changes treatment
regimens. Our case report forms filled out
by the patient's doctor only Indicate the
date of onset of the adverse experience. In
most cases, the adverse experience occurred
after the change In regimens and would be
attributed to the new regimen. However,
occasionally there Is uncoded information on
the form that Indicates that the adverse
experience occurred before the change in
treatments and should therefore be attributed
to the previous regimen.
While the
statistical report for the study would count
the experience under the correct regimen,
there is no way to change the clinical data
base to reflect the proper treatment without
altering otherwise correct Information. The
safety data base file however could be
designed to contain a fl-ag variable to
indicate how this problem should be resolved
when it occurred.
3.) An adverse experience file with one
observation per patient report of an adverse
experience, containing variables such as
adverse experience, date of onset, severity,
etc.
4.) A file identifying other (non -study
design) medications taken by a patient
concomitantly with their study medication or
prior to the start of the study. This file
contained one observation per patient report
of concomitant meds or diseases/conditions
and contained such variables as med, disease,
date med started, date med stopped, etc.
5.) A file of lab data having one
observation for each treatment summarized for
each lab test. The data were counts of
patients whose lab data changed in a
specified way from baseline measurements.
Additionally, although not related to safety,
we included a sixth file of efficacy data
that would be used later in computing a
simple measure of efficacy across all stUdies
of the same indication.
Creatin9 the Files
All the data for a particular study to be
analyzed was extracted from our clinical
trial data base and saved in a SAS data
library on disk as one large data set called
MASTER. Additional permanent SAS data files
created during the course of analysis were
also saved in the study SAS data library.
Since the main function of the safety files
was for use In producing the overall safety
summary,the flies could be designed to
facilitate this analysis. In effect, by
spending some extra time along the way to
prepare the safety files during the course of
analyzing each study, the overall safety
summary could be carried out much more
quickly and efficiently at the end when time
was the shortest and deadlines the tightest.
A library of standardized SAS software was
developed for analyzing and reporting
uniformly collected data from each study in
the project. Certain programs from this
library that process safety information in
order to produce listings and/or analyses
were modified to also create and save the
appropriate safety data file in the study SAS
data library. This file would be of the
exact same structure as the corresponding
safety data base file. An unanticipated
advantage of creating and saving these safety
files in the study SAS data library was that
several programs from the standard software
library were able to use them as uniform
input data sets without discrepancies. See
"Developing a Standardized SAS Software
Library for Analysis of Numerous Large Scale
Clinical Trials" by Debra Bingham -Barnes,
Betty Nelson and David Tappe in the 1985. SUGI
Proceedings for further information on the
standardized software library.
The Safety Files
A fter careful consideration, we decided upon
maintaining 5 separate files of related or
similarly structured data that collectively
would form the safety data base. The five
safety files were as follows:
1.) A Demographic file with one observation
per patient containing such information as
age, weight, height, sex, etc.
Once all the files had been created, the
contents were listed out and the data checked
for accuracy and completeness. Documented
modifications such as setting flag variables
or resolving key miSSing values were then
made to the safety files using SAS/FSP'.
2.) A Dosing/Treatment file having one
observation per patient visit containing such
Information as visit number, visit date,
treatment regimen at that visit, etc. This
file associated dosing and treatment
Information. for each visit so that given a
date for a patient, the correct treatment
regimen for that patient on that date could
be identified.
When the study safety files were all deemed
ready, the person in charge of maintaining
and updating the safety data base was
382
notified. After verifying the completeness
of the files and their compatibility with the
safety data base files, he would append each
study safety file onto the corresponding
project safety file. Figure 2 Illustrates
the process by which raw safety data stored
In the SAS data library were processed and
added to the safety data base.
V. CONCLUSION
Although extra time was spent preparing the
individual study safety files, the overall
safety analysis at the end went very
smoothly. The time saved in performing the
final analysis and periodic interim analyses
when the time pressures were greatest more
than offset the additional time spent along
the way.
Once the data from all studies to be included
in the filing were in the safety data base,
the final safety analysis could begin.
Dosing/Treatment
Standardized
I
I
Demographic
SAS Software
Library
Adverse Experience
I
Concomitant Mad
I
Standard
Programs
lab Summary
L
StudySAS
MASTER
Data library
OosingJTreatment
I
I
Demographic
Adverse Experi8f1ce
I
Com:omitant Mad
I
lab Summary
Study
Safety
Files
I
~
Review
to Safety Data
and Correct as
Base
Necessary
DosinglTreatment
I
I
Demogrephic
Adverse Experience
Concomitant Mad
Lab Summary
I
Project
I
Safety
Data
Base
L
Figure 2. Steps by which standard programs from the software library
created study saiety files from raw Input data (SAS data set MASTER)
which were then added to the safety data base.
383
The availability of standardized programs
that could be modified to produce the safety
files for each study was a definite asset in
building the safety data base files. The
Individual study safety files also proved to
be useful as uniform files that could be used
by other software in preparing the final
statistical and clinical reports for that
study.
The biggest problem we had compiling the
safety data base was In resolving data
problems in each study·s safety files.
Although this problem would have plagued any
system of pooling safety information, the
problems we had pOinted out ways of utilizing
the standardized software more to lessen this
task. Additional algorithms were developed
and incorporated into the software to handle
the commonly occurring problem situations.
To maximize the usefulness of such a safety
data base, several conditions must be met.
First, the projected analyses and summaries
to be needed for ttle overall safety summary
must be well defined In advance. This will
help ensure that only necessary data be
retained In the data base, yet minimize both
wasted storage space and time spent cleaning
up unnecessary data. Second, the data must
be collected In a consistent manner In order
to facilitate the creation of individual
study safety files.
Ideally, standard
programs could be developed to automatically
create the safety flies.
VI. ACKNOWLEDGEMENTS
I would like to credit Dr. Greg Schwemer of
Syntex Research for his concept of a data
base for safety information, and Mark
Holdbrook, also of Syntex Research, for his
help in developing the framework for the
safety data base.
'SAS and SAS/FSP are registered trademarks
of SAS Institute Inc., Cary, NC, USA.
For further Information or comments,
please contact the author at:
Syntex Research
Mailstop A3-434
3401 Hillview
Palo Alto, CA 94303
384