Integrated Safety Reporting Anemone Thalmann elba - GEIGY Ltd (PH3.25), Basel

Transcription

1 ntegrated Safety Reporting Anemone Thalmann elba - GEGY Ltd (PH3.25), Basel Abstract: Most of the regulatory health authorities approving pharmaceutical products consider the ntegrated Safety Summary to be an essential part of the registration dossier for human pharmaceuticals. The ntegrated Safety Summaries we produce at CBA are based on pooled data from clinical trials performed in several countries, regardless of the trial objective and design. The integrated evaluation includes all reported trials available at the moment of registration dossier compilation. n the medical department of CBA's pharmaceutical division we recently switched from NQURE to ORACLE as the database systems for clinical trial data storage. The necessitiy of integrated safety reporting implies the need to standardize data from these different data sources. This paper describes the necessary steps that have to be performed as a prerequisite for an ntegrated Safety Summary and how the SAS system is involved as a data manipulation and reporting tool in this process. ntroduction Many employees of the pharmaceutical industry have a more or less profound knowledge of what the phases of clinical development of pharmaceuticals are. Since not all computer scientists are directly involved in the process like the statisticians for example, this presentation will start with a short and rather simplified overview of the clinical development process and its phases (see figure 1). For each phase several clinical trials have to be performed. All data collected over the life cycle of a preparation has to be presented to the health authorities, who decide upon the marketing permit in their countries. What is an ntegrated Safety Summary? The basic document stating something about what we call an ntegrated Safety Summary is the "Guideline for the Format and Content of the Clinical and Statistical Sections of an Application", published by the Food and Drug Administration in July 1988 (l.h., pp ). On page 33 it states: "... the integrated summary is an overall analysis, examining all studies together. This allows examination of differences among population subsets not possible with the relatively small number of patients in individual studies and, especially important, allows evaluation of more serious adverse effects too rare to be detected with assurance in single studies." With other words, an integrated summary of all trials performed on one drug emphasizing adverse events evaluations (=tolerability, safety) is called an ntegrated Safety Summary. 670

2 ,!,?S"':';"t'1q!'?("""f';--::ft' (4",('_',,!' ;:-"?;1" 1 'n:: _"-H_":?'-C' --'.'-<::';' "\_>{V;--T" :-1>;n:::':'1'-'' :_'-'-'-"V,-<"-"';_,-c,,,-,.. Phases of clinical development (simplified) W 0\ -...l, Phase healthy volunteers pharmacology Phase small set of patients pharmacokinetics pharmacodynamics teratogenity Phase s. Registration /+ large number of patients efficacy tolerability carcinogenity genetical toxicity Health Authority Phase V Monitoring, 1,,,. Figure 1 ciba PH3.25

3 History Ciba Basel and its group companies worldwide, have used for many years several platforms for storing trial data, like BM mainframe, VAX systems and several types of PCs. As database management systems NQURE, ORACLE and SAS were used. The main datapool was in NQURE on an BM mainframe (operationg system: MVS/ESA). n 1991 we switched from nquire to Oracle using the same platform. Before the switch a data standardization project was completed and a centralized trial inventory database was implemented. All new trials use the standardized formats, ranges and codes now. n CBA-Pharma there are 3 main data centres: Basel, Summit (USA) and Takarazuka (Japan). At present data from Basel and Summit can be accessed via a distributed database link. Since we use the same database structure and the same software, data can easily be pooled. The link to Japan is technically already realized, but because of the different database structure of our Japanese colleagues, distributed links are not possible at the moment. All main group companies from (Western) Europe and South America have access to the Basel host. Today only in small countries PCs with local Software are used. The situation a described above works for individual trials. With the requirements for ntegrated Safety Summaries we face the problem of pooling and jointly evaluating data of several sources, formats, different dates of origin and, sometimes, even several languages. Aim The aim is one ORACLE database, out of which data can be directly pooled and evaluated jointly. This will be a distributed database with data physically stored in our 3 main data centres. For the time being and the next few years, as long as we have to deal with our current heterogenious surrounding, a solution has to be found. One of its requirements would be to minimize the amount of work associated with old trials, and preferably reduce this even further in the future. Problem Description The first idea was to use the SAS system both as the database and the reporting system, to convert all data irrespective of source into SAS datasets and evaluate them. What we didn't want is storing the same data several times. Because of 672

4 r'zt:::<:,t't:--::-::--"t-'-" i!, j the distributed data storing concept and because our US colleagues used the Oracle database management system for several years, this system was chosen. After checking Oracle's reporting tool it was decided to retain the SAS system for reporting. t was chosen not only for historical reasons (everyone was familiar with this software) but also for the facilities it provides. Our Solution Within this context the solution was an Oracle database with the same structure as the single Oracle trial databases, using the standards defined by the data standardisation project. This database is called Central Safety Database. t includes only the variables of general importance which are therefore recorded in all trials. The next step is to convert all old trials, irrespective of their origin, into the above mentioned format. t was decided to use the SAS software for this purpose, since it is very powerful in data manipulation and all colleagues of our department are familiar with it from statistical evaluations. The conversion of a trial is a very hard and timeconsuming job which is rather unspectacular to be presented to an audience. Raw data, trial protocols and clinical trial reports have to be checked. Conversion rules and assumptions concerning missing data have to be discussed with the medical advisors responsible for the individual trials. Vetting Because programming errors do happen (nobody is perfect), the outcome of the conversions has to be checked for inconsistencies. Therefore a menu-driven SAS AF application was written. Taking advantage of the standardization between projects this application is now used for all drugs. The following figure presents the selection panel for the items to be vetted. i,. 673." '-.: -", " -- -:- -' ---,

5 f&...,::;;;;;?if,,"-&""":l;';e."'-->r.."' "O"R;';:;=-""'_"''l..,,'".'"=_,-...,,-- ' Please enter identification of the trial to be vetted: --- Select one or more of the following: 1 Patient data 2. Visit data 3. Medical history 4. Concomitant medication 5. Adverse experiences 6. Premature discontinuation 7. Trial treatment 8. Vital signs 9. Lab values and normal ranges 10. ECG 11. Cross check on valid trial identification _ 12. Cross check on premature discontinuation and reason _ 13. Cross check on reason for premo discontinuation and adverse 'experiences 14. Cross check on link core - extention trials Submit End i.. i,. Figure 2: Selection panel for vetting programs After the corection of errors the clean data is loaded into the Central Safety Database. At this stage all the data is in the required format. Now we are able to perform whatever evaluation is needed. A standard set of ouput tables to be included into the ntegrated Safety Summary was defined. A menu driven application was implemented, which allows the user to produce the tables he wants without knowing the SAS/AF, SAS/FSP, SAS SCL and SAS MACRO programs performing them. A condensed overview on how data is processed before an integrated safety report can be produced is shown in figure 3 (see next page). The upper part shows the different data sources of the raw data, the middle part shows data conversion, vetting, cleaning and loading into the Central Safety Database. Below, the distributed link of databases for individual trials and the Central Safety Database (Oracle) is shown, and the final data tabulation for ntegrated Safety Summaries (SAS). n the upper left corner the conversion tool MSST (abreviation of Medical Statistics Software Tool) is mentioned. t is a Ciba tool for extracting data from 674

6 'v ;r'p':l1t..:.tft;tt"'.1 t:",,(.(fj:..!1m;.''':m;:,.o:: t;:'0'?7r'."i::"".:" c't":!g ;."-f;'-:}.';:!-'y:""'!""':.""':""_7';:;;';:-;:-_0"7t_:i--"_;'"_'-">- Clinical Trials (NQURE) ntegrated Safety Reportina - Diskettes (SAS ds) Hardcopies :i!...---,, p'; r.; r'. conversion into standard format 0\ Ul n> error + warning lists _ Medical Advisor nternat. Clinical Trial System (ORACLE) SOL NET t ORASAS.. SAS datasetsl SOL_LOADER Central Safety Database (ORACLE) SAS Output Tables for ntegrated Safety Summary. Figure 3 ciba PH , ", ':, "

7 the nquire database into SAS datasets considering several criteria the user can select. This tool was presented by Edgar Klausmann (Ciba-Geigy Ltd, Basel) at the DSC Proc ORASAS is a Ciba tool for data extraction from Oracle to SAS, based on SAS Toolkit and PU1 Programs. t was programmed by our USA colleagues, since no standard SAS procedure fulfilling our needs was available on the MVS platform we use. The following figures show some of the screens th user has to deal with while running the application for production of output tables for the ntegrated Safety Summary. Command ===> STANDARD OUTPUT REPORTNG Please identify necessary Data-Sources ORACLE user: ORACLE password: Selection set: Give the owner and the name Which database should be searched: (Just type ENTER at the appropriate line) (don't forget OPS$) -----of the selection set Basel Summit both Press F3 to continue or type CAN at the Command line to exit Figure 4: Entry panel of the reporting application On the entry panel of the reporting application (figure 4) the user is asked for a selection set and whether he wants to access the Basel, the Summit or both databases. The selection set the user is required to type is a name he is free to choose for a subset of trials he wants to perform the evaluations on. For example, the selection set could be all double blind trials performed after 1990, a possible name could be DOUBLE90. Via accessing the trial inventory database the program selects all identifications of the trials with the criteria defined and it can now extract data of the respective trials from one of the Oracle databases. A permanent SAS library with the selection set's name is created where the extracted data will be stored. This database is a shapshot of the database's content at a certain time point. 676

8 '-. - -, ',- - Command ===> STANDARD OUTPUT REPORTNG To select: TAB to your selection and type ENTER 1. PERFORM COMPLETE TRAL SELECTON FROM ORACLE 2. PRODUCE STANDARD OUTPUT TABLES Press F3 to continue or type CAN at the Command line to exit Figure 5: Selection panel for whether to perform data extraction from Oracle databases or run the output tables On the next panel (figure 5) the user is asked whether he wants to perform the data extraction or run the tables. On one set of extracted datasets he can produce several sets of tables, e.g. on consecutive days. Because of the permanent storing he is guaranteed that he uses the same data pool. Changes performed since his last extraction are not considered. A new extraction can either overwrite the old one ( if the same selection set name is used) or will be stored into a new library. This gives the user the flexibility to define and evaluate several database shapshots. STANDARD OUTPUT REPORTNG Please select the tables you need Number of selections made: ALL All Tables 001 Miscellaneous 101 T Patients with Adverse Expriences 101 D Patients with Adverse Experiences - Dose Ranges 102T Adverse Experiences by Body System 102D Adverse Experiences by Body System - - Dose Ranges 103T Adverse Experiences by Frequency 104T AEs by Demographic Subsets 105 Adverse Experiences by Severity 106 Adverse Experineces by Relationship 107 AEs by Severity and Relationship 108 Most Frequently Reported AEs Figure 6: 1 st page of a set of tables the user can choose from \ \, 677

9 Currently a standard set of 40 tables, some of them with up to 10 options can be produced. ncluding all options 810 different tables are possible. Of course nobody realy needs all options for one ntegrated Safety Summary. But with this flexible application the greatest part of the user's needs are covered. The following figure shows a sample output table. CBA - DRUG CENTRAL SAFETY DATABASE RUN DATE: 10-MAY-93 Table 602D SUMMARY OF THE NUMBER OF PATENTS EVALUATED FOR SAFETY BY TREATMENT. TRAL AND TOTAL DALY DOSE TOTAL DALY DOSE DOSE1 DOSE2 DOSE3 ALL DOSES TRAL D N % N % N % N % ALL TRALS Patients who received more than one dosing regimen are counted in each dose received. Patients are counted only once in the 'ALL DOSES' column. Documentation # 389. Selection set name: DOUBLE90. Comment: Test for SEUG93 Figure 7: Sample output table This menu-driven application for producing output tables for the ntegrated Safety Summary guarantees the uniformity of the tables presented to health authorities for all Ciba human pharmaceuticals. A central maintenance assures that the tables are at any time up to date and fulfilling the latest requirements of the health authorities. Conclusion The SAS system provides powerfull tools for - data entry - processing (convertion) - checking (vetting) - storing and - evaluation. 678

10 This paper describes the procedure to produce an ntegrated Safety Summary as it is currently implemented at Ciba. t can, at all times, be adopted to meet any changes in regulatory requirements. Author: Anemone Thalmann, Medical nformation Management PH3.25, K , 4002 Basel, Switzerland tel fax SAS software, SAS/AF, SAS/FSP, SAS/TOOlKT are registered trademarks of SAS nstitute nc., Cary, NC, USA BM is a registered trademark, MVS/ESA is a trademark of nternational Business Machines Corporation. ORACLE, SQl *loader, SQl *NET are registered trademarks of ORACLE Corporation. NQURE is a trademark of nfodata Systems nc. \ \.. 679