Pharmaceutical Applications

(1)

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:

Cumulative Cumulative

AEACN Frequency Percent Frequency Percent ƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒ DOSE INCREASED 2 0.01 2 0.01 DOSE NOT CHANGED 32999 95.44 33001 95.44 DOSE REDUCED 136 0.39 33137 95.84 DRUG INTERRUPTED 650 1.88 33787 97.72 DRUG WITHDRAWN 556 1.61 34343 99.33 NOT APPLICABLE 230 0.67 34573 99.99 UNKNOWN 3 0.01 34576 100.00

(2)

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.

(3)

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 Value Test 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) 10001 CREAT -10 -69 1.1 1.2 0.7, 1.4

Serum Creatinine (mg/dL) Non-exposed 123 10001 CREAT 0 1 1.1 1.1 0.7, 1.4

Serum Creatinine (mg/dL) 10001 CREAT 3 22 1.1 1.4 0.7, 1.4 Yes

Serum Creatinine (mg/dL) 10001 CREAT 6 43 1.1 1.2 0.7, 1.4

Serum Creatinine (mg/dL) 10030 CREAT -9 -63 0.9 1 0.7, 1.4

Serum Creatinine (mg/dL) Non-exposed 123 10030 CREAT 0 1 0.9 0.9 0.7, 1.4

Serum Creatinine (mg/dL) 10030 CREAT 3 13 0.9 1 0.7, 1.4

Serum Creatinine (mg/dL) 10030 CREAT 3 22 0.9 1 0.7, 1.4

(4)

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

(5)

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

VARIABLE

LABEL

TYPE/

LENGTH

DECODE/DERIVATION/COMMENTS

STUDYID Study Identifier

C/200

USUBJID Unique Subject Identifier

C/200

SUBJID

Subject Identifier for the Study

C/200

Also known as Randomized Patient Identifier.

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

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

FASFL

Full Analysis Set Pop Flag

C/1

Flag to identify FAS population for the primary

efficacy end point.

FASFN

Full Analysis Set Pop Flag,

Num

N/8

1: Included in FAS population

_{0: Excluded from FAS population}

ARM

Description of Planned Arm

C/200

TRT1P

Planned Treatment for Period 1

C/200

TRT1PN Planned Treatment Number for

Period 1

N/8

1: Placebo

_{2: Study drug}

RANDDT

Date of Randomization

N/8

TRTSTDT

Date of First Exposure to

Treatment

N/8

TRTENDT

Date of Last Exposure to

(6)

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]