epro Integration with Oracle Remote Data Capture

Transcription

1 epro Integration with Oracle Remote Data Capture BIAS Congress May 2010 Rome (IT) Davide Di Giovine, CROS NT Senior DM & CSV Manager AGENDA Changes in handling of clinical and device data Business Case epro Project / Architecture Results and Conclusion

2 Data Management Past CRF data Collection of paper CRFs Query handling by data correction forms Device data After end of usage collection of devices Some devices lost or data lost Transfer of data to computer Investigator and Sponsor do not have access to data (only though the display of the device) Data consistency Detection of inconsistencies between CRF and device data at a very late stage Data Management Present CRF data Collection with ecrf Accelerated query handling Device data Either collection of devices after end of usage Or electronic transfer into separate CDM database Investigator and Sponsor do not see the integrated data CRF+Device Data Consistency Detection of inconsistencies between EDC and device data at a late stage when merging different data sources Difficulties with device data in adaptive trial designs

3 Data Management Future CRF data Collection with ecrf Accelerated query handling Device data Real-time electronic transfer into ecrf database Investigator and Sponsor see integrated data immediately Data Consistency Real-time detection of inconsistencies between EDC and device data Adaptive trial designs possible for device data Due to faster data availability it is possible to have decision points during study conduct to stop the trail Real-time Integration Real-time is not defined by instantaneous action Real-time means action in the appropriate moment depending on User requirements With mobile phone technology Process the pre-visit data during the visit (USB)

4 Business Case (1) Phase III study: A 48-week, multicentre, multinational, randomized, doubleblind, 2-arm parallel group study, comparing the efficacy of two treatments as reliever in asthmatic subjects No. of patients: more than 1500 randomized Number of Sites: more than 200 in EU peak expiratory flow (PEF)(L/min) measured in the morning and afternoon as secondary efficacy variable epro: asthma symptoms and use of rescue medication selected by the sponsor ecrf (RDC or 4.5.3) Business Case (2) Already selected device, SPIROTEL Measurements: Biometric measures: (e.g. FEV, FEV1, PEF etc). Diary information (e.g. QoL): set of records reporting information recorded by the patient (patient s answers to QoL questions, compliance, etc).

5 Business Case (3) Problems encountered in previous studies performed with daily Spirometer measurements and data upload at the end of the study: Late detection of quality problems of measurements Late detection of device malfunctioning Missing days with measurements detected in the end No edit checks between device data and CRF data Lacking review of device data during the study by the Sponsor Investigator feedback The evaluation of patient data was too difficult during the visit when using the display of the device epro Project (1) Patient uses the device in the morning and afternoon At each visit the devices are connected to investigator s PC Data are downloaded to the OC DB through the investigator s PC The Investigator can see clinical data from the previous visit (both as row data and as descriptive statistics)

6 epro Project (2) Investigator required to review the pre-visit data collected by devices, e.g. spirometer, epro during the subject s visit Ubiquitous connectivity not required: Still costly with mobile phone technology Sufficient to process the pre-visit data during the visit epro Project (3) Project Duration: 10 months Project Team Project Management, OC experts, IT experts, and validation team at CROS Data Capture API and BDL API outsourced to RELICO IT and QA support from Device Company Implementation designed to obtain re-usability of the application for different studies and other devices Designed to support test devices for training purpose at the site (monitors with investigators, investigators with patients) Extensive beta testing (Several system stress tests, for example download with 100 devices launched simultaneously with 800 records each).

7 epro Project Design Modular Architecture Software development modules and related connections to be implemented. Architecture Portal with Web Service Device Investigator PC 2 RDC Database Server epro USB RDC and

8 Module 1 PC client software Normal executable not requiring installation with registry entries, any user can download and use it Transfers data from device s SD card to a dedicated server in the CROS NT LAN via HTTPS Does not write device data to the user s PC Device is connected to PC through USB User cannot read data in any way from the device Notifies the user of the overall upload result Module 2 Web service to manage the upload from the device through module 1 to a protected folder Decryption of data Transfer of data through ODBC to database

9 Module 3 Mainly based on validated Oracle Clinical batch data load module When data transferred by module 2 Oracle Clinical batch data load jobs are triggered to load the data into Oracle Clinical Special validation is required for Creating the BDL file Writing into the batch_jobs table and submitting a job using the rxcps_pkg.submit_batch_job function Module 3 Error handling and mitigation procedures required System related errors with instructions for fixing the error Database is down PSUB is not running ecrfs with derived information in usage Spirometer ID related errors with feedback to investigator what action to take The Spirometer ID is not found in RDC Check patient s device ID for correctness Device ID is assigned to the wrong patient Call hotline Device ID is assigned to more than one patient Check patient s ID for correctness, otherwise call hotline

10 Changing the device for a subject Module 4 One subject may have several devices One device can only be assigned to exactly one subject No re-use, in case of re-use the device ID will be changed Devices can be used intermittently in sequence, but not in parallel The incremental load algorithm will load data from any device assigned to the patient in RDC Only data newer than already loaded data will be loaded First device A Then device B Then device A Module 4 Device dedicated CRF pages are set up in order to show electronic data records Only a subset of the available record variables is shown according to the User Requirements Device pages are available as soon as electronic data upload is completed These pages are in read-only mode

11 Results (1) RDC Casebook Spreadsheet after loads Results (2) Raw data in RDC after loads

12 Results (3) RDC summary information after loads Feedback from Investigators Two Investigator meetings organized with workshop related to RDC and Download of epros into OC Both investigators and Sponsor very excited when seeing the applications in use First feed-back: "Useful for the study and also very useful for the normal practice: better understanding of patient health when at home"

13 Feedback from the Sponsor Medical Review Review of patients asthma control vs. exacerbation Rescue medication use > 4 per day Daily PEF evening and morning difference > 30% (% variability) Total daily symptom scores from Spirometers > 12 (morning + evening) Feedback from the CRO Integrated RDC plus epro Helpdesk Easy for the investigator: only one toll free number More frequently issues: Spirometer ID not entered correctly in RDC

14 WEB Demo Available ( Define wrong device in RDC Try load of spirometry data Correct device in RDC Load spirometry data Verify load in RDC Have a look at the derived data Conclusion Good convincing results Excellent Investigator feedback Sponsor more relaxed during the study, supervising data during the study Competitive with other solutions that oblige the use of two different application (one for the epro and the other for the ecrf) Looking into other medical devices (Cardiology) Extended Project: with PAD and Telephone devices

15 Q&A Davide Di Giovine 29