NESUG 2010

Pharmaceutical Applications

Integrated Summary of Safety and Efficacy

Programming for Studies Using Electronic Data Capture
Changhong Shi, Merck & Co., Inc., Rahway, NJ
Qing Xue, Merck & Co., Inc., Rahway, NJ
ABSTRACT
The Integrated Summary of Safety (ISS) and Integrated Summary of Efficacy (ISE) are essential components of a successful
submission. In legacy studies where different types of data are frequently collected through diverse systems by various
vendors, programming ISS and ISE analysis can be a daunting job because all study data need to be converted and
harmonized to the same format before programming and analysis work can begin. Studies that utilize the Electronic Data
Capture (EDC) system have similar structured views which can greatly ease the harmonization process. However, even
though harmonization is limited there remain many unique challenges to be addressed by programmers in multi-study data
integration for ISS and ISE. This paper discusses specific tips and techniques to efficiently program integrated analyses which
focus on the following areas: (1) data source checking, (2) "spread and convene" programming approach, and (3) consistent
data and folder structure.
Keywords: ISS, Integrated Summary of Safety, Integrated Summary of Efficacy

INTRODUCTION
The Integrated Summary of Safety (ISS) and Integrated Summary of Efficacy (ISE) are essential components of a successful
submission. They differ from a regular study since: (a) there is a larger amount of data, (b) usually each study has been
locked for frozen file before ISS and ISE, and (c) in the component individual study, different folder structures might have been
used since these studies could have been locked for a long period of time which means that they may have followed different
standards. This paper will detail the techniques to efficiently handle and accommodate these challenges which include:
(1) data source checking
(2) "spread and convene" programming approach
(3) consistent data and folder structure.

1. DATA SOURCE CHECKING

ISS and ISE typically contain more than one study as well as a large amount of data. In order to achieve accurate integrated
analyses, data must be scrutinized in order to catch important scenarios that need special attention. Also, due to the number
of patients and large amount of data involved, it is impossible to "eyeball" everything in ISS or ISE as is sometimes done
against a single small study. The following techniques, although simple, prove to be efficient for checking the data source
before programming:
A). Frequency procedure
By checking the values of variables using a frequency procedure, it can be determined if special attention is required
and can be used to propose suggestions to the statistician on data handling. The following example checks the values
of "Action Taken with Study Treatment" (AEACN variable in SDTM AE domain, SDTM 3.1.1. IG) across the pooled ISS
studies:

proc freq data=iss.ae;

tables aeacn/list;
run;
Result obtained:

AEACN
DOSE INCREASED
DOSE NOT CHANGED
DOSE REDUCED
DRUG INTERRUPTED
DRUG WITHDRAWN
NOT APPLICABLE
UNKNOWN

Cumulative
Cumulative
Frequency
Percent
Frequency
Percent

2
0.01
2
0.01
32999
95.44
33001
95.44
136
0.39
33137
95.84
650
1.88
33787
97.72
556
1.61
34343
99.33
230
0.67
34573
99.99
3
0.01
34576
100.00
Frequency Missing = 7

-1-

NESUG 2010

Pharmaceutical Applications

In the frequency distribution above, there are seven AE records with AEACN as blank and three with wording as
'Unknown'. Rather than going directly to the table production, further investigation and reports to the statisticians
and database team to consult for a final decision is recommended.

B). Missing values and blank values are our "friends" in ISS or ISE
Statistical programmers have to deal frequently with missing or blank values, and this is especially important in an
ISS or ISE when dictionary leveling is involved.
Commonly, ISS data is leveled to use the same dictionary version across all studies. This may result in missing data
due to expired terminology. For example, consider the following hierarchy in the drug dictionary:
CMDECOD (Standardized Medication Name)
Then
CMCLAS (Medication Class)
If one CMDECOD expires and cannot be leveled per the dictionary version used by an ISS or ISE, no corresponding
CMCLAS is able to be assigned. This data leveling issue in the resulting ISS or ISE could be identified by performing
a simple frequency procedure against the leveled variables (CMDECOD and CMCLAS in the above example) to
ensure blanks do not occur. Due to the large amount of data in an ISS or ISE, this programmatic checking is
important as it can be overlooked by manual methods. Therefore, missing or blank values are our "friends" for an
ISS or ISE in that they help to identify harmonization issues for integrated analyses.

2. PROGRAMMING APPROACH
It is possible to put the raw data for all studies together and write one set of programs for ISS or ISE, but this approach
becomes problematic to debug and determine the source of problems, especially when there are a large number of
component studies. To save debugging and validation time, the approach adopted for our 19 ISS studies was to first program
by individual study and then reuse the code from the clinical summary report (CSR) or other existing programs. The results
are then compared with the existing CSR or other published results.
After the programming work is done for each individual component study of an ISS or ISE and all programs for individual
studies have been developed and validated, we then just need simple stacking programs to stack the analyses datasets
together. A simple set of stacking programs were written to stack the analysis datasets in ADaM format with the same data
structure; further work was completed on the stacked analysis data. We called this approach "spread and convene".
The advantage of this approach can be seen in the laboratory safety (LAB) and predefined limit of change (PDLC) analysis.
For the example listed in the next page, i.e. we produced a PDLC listing table for an ISS consisting of 19 studies, which had
11 columns as follows:
lab test name
treatment group name
protocol number
patient allocation number
lab test code (CDISC code)
analysis time point (week)
lab measurement day relative to the reference start date (here, it is the trial start date, i.e. the date for the first non-zero
dose medication date)
baseline value (for simplicity in this example, baseline value is defined using the last measurement with
measurement day relative to the reference start date <=1)
test value for the analysis time point
upper limit of normal range (UL)/lower limit of normal range (LLN)
hit (indicates if the specific record meets in the PDLC criterion in the row header)

In this example, we show three patients: two from Prot123 with allocation number (AN) as10001and10030, and one from
Prot456, with AN as 1000. Since Prot456 was a Phase IIB study, and Pro123 was a Phase III study, the study design was
somewhat different, and the baseline definition was different. Therefore, in order to obtain the table below where baseline
value is in one column, the most efficient approach was to "spread" first, i.e. set up the lab data for Prot456 and Prot123
separately, compare the results against the original CSR or other exploratory outputs, and then "convene", i.e. stack the
analysis dataset where baseline value is set as one column. This is also suitable for the analysis time point column where the
way to define weeks was different for each study. Note that the table should only contain those patients who had at least one
dose of study medication. Using the "spread and convene" approach instead of trying to integrate all data together - in this
case data from 19 studies running the program took considerably less time.

-2-

NESUG 2010

Pharmaceutical Applications

Listing of Patients With Two or More Consecutive Serum Creatinine Measurements

with an Increase from Baseline of 0.3 mg/dL or of 50%
Pooled Studies

Lab Test

Treatment

Proto
col

Alloc
ation
Numb
er

Endpoint(s)
Assessed
for Test

Week

Relative
Day

Baseline
Value

Test
Value

LLN,
ULN

Hit

Criterion: Two or more consecutive measurements with an increase from baseline of >=0.3 mg/dL or of >= 50%
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)
Serum Creatinine (mg/dL)

Non-exposed

Non-exposed

Non-exposed

123

123

456

10001
10001
10001
10001
10001
10001
10001
10001

CREAT
CREAT
CREAT
CREAT
CREAT
CREAT
CREAT
CREAT

-10
0
3
6
6
12
18
18

-69
1
22
36
43
91
127
141

1.1
1.1
1.1
1.1
1.1
1.1
1.1
1.1

1.2
1.1
1.4
1.4
1.2
1.3
1.2
1.2

0.7, 1.4
0.7, 1.4
0.7, 1.4
0.7, 1.4
0.7, 1.4
0.7, 1.4
0.7, 1.4
0.7, 1.4

10030
10030
10030
10030
10030
10030
10030
10030
10030

CREAT
CREAT
CREAT
CREAT
CREAT
CREAT
CREAT
CREAT
CREAT

-9
0
3
3
6
12
18
18
24

-63
1
13
22
43
85
114
125
167

0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9

1
0.9
1
1
1.2
1.2
1.2
1.2
1.2

0.7, 1.4
0.7, 1.4
0.7, 1.4
0.7, 1.4
0.7, 1.4
0.7, 1.4
0.7, 1.4
0.7, 1.4
0.7, 1.4

1000
1000
1000

CREAT
CREAT
CREAT

-7
-2
0

-49
-14
1

0.7
0.7
0.7

0.8
0.8
0.7

0.7, 1.4
0.7, 1.4
0.7, 1.4

-3-

Yes
Yes

Yes
Yes
Yes
Yes
Yes

NESUG 2010

Pharmaceutical Applications

3. CONSISTENT DATA and FOLDER STRUCTUE

For an ISS or ISE that only contains studies where data are collected using EDC, we may have a consistent data structure at
database lock. However, if for some reason such as standard changes, or a non-EDC study within an ISS or ISE, we may
have different folder and data structures for each study. To fully realize the advantage of data and folder structures in ISS and
ISE, a consistent data and folder structure which has exactly the same naming convention is necessary. This way it is possible
to use virtually the same code for defining the input and output directory paths at startup. Listed below is a folder structure we
found helpful:

ISS Directory Structure

(
|

-- folder

-- file)

ISS2009
| OverallISS
| dataanalysis
| adlab.sas7bdat
| adpdlc.sas7bdat
| pgmsetup
| pgmanalysis
| utility
| startup.sas
| p456
| sdtmplus
| dm.sas7bdat
| lb.sas7bdat
| dataanalysis
| adlab.sas7bdat
| adpdlc.sas7bdat
| pgmsetup
| pgmanalysis
| utility
| startup.sas
| p123
| sdtmplus
| dm.sas7bdat
| lb.sas7bdat
| dataanalysis
| adlab.sas7bdat
| adpdlc.sas7bdat
| pgmsetup
| pgmanalysis
| utility
| startup.sas
| p789
|
p012
.

-4-

NESUG 2010

Pharmaceutical Applications

The following is a consistent data structure example for our ADSL dataset within each component study:
LABEL

TYPE/
LENGTH

STUDYID

Study Identifier

C/200

USUBJID

Unique Subject Identifier

C/200

SUBJID

Subject Identifier for the Study

C/200

SITEID

Study Site Identifier

C/200

ETHNIL

Ethnicity

C/200

ETHNIN

Ethnicity, Num

N/8

1: Hispanic or Latino
2: Not Hispanic or Latino

AGE

Age

N/8

Age in Years

SEX

Sex

C/2

RACE

Race

C/200

FASFL

Full Analysis Set Pop Flag

C/1

FASFN

Full Analysis Set Pop Flag,

Num

N/8

ARM

Description of Planned Arm

C/200

TRT1P

Planned Treatment for Period 1

C/200

TRT1PN

Planned Treatment Number for

Period 1

N/8

RANDDT

Date of Randomization

N/8

TRTSTDT

Date of First Exposure to

Treatment

N/8

TRTENDT

Date of Last Exposure to

Treatment

N/8

VARIABLE

DECODE/DERIVATION/COMMENTS

Also known as Randomized Patient Identifier.

AMERICAN INDIAN OR ALASKA NATIVE:

American Indian or Alaska Native | ASIAN: Asian
| BLACK OR AFRICAN AMERICAN: Black or
African American | MULTI-RACIAL: Multi-Racial
| NATIVE HAWAIIAN OR OTHER PACIFIC
ISLANDER: Native Hawaiian Or Other Pacific
Islander | WHITE: White
Flag to identify FAS population for the primary
efficacy end point.
1: Included in FAS population
0: Excluded from FAS population

1: Placebo
2: Study drug

-5-

NESUG 2010

Pharmaceutical Applications

CONCLUSION
This paper provides some basic techniques and tips for ISS and ISE programming. The steps help to enable the efficient and
accurate creation of multiple ISS and ISE studies. If all the component study data are collected using the SDTM format, more
development can be made to standardize the programs for each component study analysis, when applicable, and further
improve efficiency.

REFERENCES
CDISC Study Data Tabulation Model Implementation Guide: Human Clinical Trials Version 3.1.1(SDTM 3.1.1 IG)
SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in
the USA and other countries. indicates USA registration.

ACKNOWLEDGEMENTS
The author would like to thank the management team for their review of this paper.

CONTACT INFORMATION
Your comments and questions are valued and encouraged. Contact the authors at:
Changhong Shi
Merck Co. & Inc.
RY34-A320
P.O. Box 2000
Rahway, NJ 07065
[email protected]
Qing Xue
Merck Co. & Inc.
RY34-A320
P.O. Box 2000
Rahway, NJ 07065
[email protected]

-6-