Integration of ePro by Sheila Rocchio, MBA
Upcoming SlideShare
Loading in...5
×
 

Integration of ePro by Sheila Rocchio, MBA

on

  • 1,225 views

The Integration of ePRO with other eClinical Systems ...

The Integration of ePRO with other eClinical Systems

A review of what sponsors and sites need to know about ePRO, including the multiple types of ePRO systems, the history and rationale for using ePRO, and the integration of ePRO with other eClinical systems.

Statistics

Views

Total Views
1,225
Views on SlideShare
1,224
Embed Views
1

Actions

Likes
1
Downloads
21
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • (Personalized intro’s and thank you for your time)

Integration of ePro by Sheila Rocchio, MBA Integration of ePro by Sheila Rocchio, MBA Presentation Transcript

  • Sheila Rocchio Vice President, Marketing & Product Management 617.973.1666 Fax/Mobile [email_address] March 11, 2009 Electronic Data in Clinical Trials Integrating Electronic Patient Reported Outcomes with other eClinical Data Streams See what’s new at the award-winning phtcorp.com
  • Discussion Topics
    • Definitions
    • Rationale for Integration
    • Case Studies
    • Considerations for integration
    Today’s Speakers
  • Definitions
    • Patient Reported Outcomes (PRO)
      • The measurement of any aspect of a patient’s health status that comes directly from the patient (ie, without the interpretation of the patient’s responses by a physician or anyone else), including disease symptoms, patient functioning, and quality of life (QOL) - FDA Guidance for Industry: Patient Reported Outcome Measures
    • Electronic Patient Reported Outcomes (ePRO)
      • PRO data initially captured electronically. NOTE: Usually ePRO data is captured as eSource - CDISC Glossary
    • eSource data (electronic source data):
      • Source data captured initially into a permanent electronic record used for the reconstruction and evaluation of a trial. Permanent in the context of these definitions implies that any changes made to the electronic data are recorded via an audit trail – CDISC Glossary
  • Available ePRO Platforms
    • Integrated Voice Response Systems (IVRS)
    • Handhelds/Smart Phones
    • Integrated Web Response (IWR)
    • Tablets (primarily for sites)
  • Reasons for Integrating eClinical Data
    • Use of many different electronic data capture systems by sponsors
      • EDC
      • IVR/IWR Randomization
      • ePRO
      • Central Labs
      • Central ECGs/Respiratory
      • Imaging
      • Portals
    • Proliferation of technology at sites
      • Multiple passwords, helpdesks, and instructions
    • System integration capabilities have improved
      • CDISC standards are well supported (ODM)
      • Web services/APIs exist for the purpose of integration
    • System integration can provide real-time benefits for decision making e.g. randomizations, clinical monitoring, adaptive trials
  • Case Study: Rescue Medication
    • Integration Goal: Capture more accurate rescue medication data
    • Data Collection …
    • Subject or Caregiver completes Evening Diary on eDiary
    • Alarm sounds if needed to remind subject to complete diary before bedtime
    • Diaries transmitted nightly to ePRO Server
    • Evening diary includes Rescue Medication intake data
      • type of rescue medication
      • number of tablets
      • timestamp of rescue medication intake
  • Case Study: Rescue Medication (Continued)
    • Data Transfer …
    • Data is transferred to EDC system
    • Attributes of Data Transfer:
      • Cumulative data set – all rescue meds recorded for all subjects
      • ASCII file format
      • twice monthly transfers
      • data uploaded via secure FTP
      • Confirmation email sent after each upload of data
  • Case Study Participants ePRO Vendor CRO EDC Vendor Sponsor Diary Data Rescue Medication Intake Merged Data Rescue Medication Details
  • Case Study #2: Eligibility Criteria
    • Integration Goal: Combine separate sources of eligibility data
    • Data Collection …
    • An Eligibility Review screen is often included on the eDiary
    • Sites review eligibility criteria in Screening and determine if a subject can be randomized into the Treatment phase
    • Examples :
  • Case Study #2: Eligibility Criteria (continued)
    • Data Transfer …
    • Data is transferred to IVR system
    • IVR system also receives subject data from another system
    • Study Coordinator calls IVRS while subject is at the site and receives randomization decision
    • Attributes of Data Transfer:
      • Cumulative data set – key eligibility criteria sent for all subjects
      • ASCII file format
      • Transfer sent within 5 minutes of eDiary transmission
      • data uploaded automatically to IVRS via secure FTP
  • Case Study #3: Adaptive Trial Design for Migraine Study
    • Four key players in the adaptive randomization:
    Subject with Qualifying Headache eDiary System Adaptive Algorithm IVRS
  • Case Study #3: Adaptive Trial Design for Migraine Study Subject eDiary Adaptive Algorithm IVRS 1. Subject Call 2. Dose Regimen Code 3. Enter Dose Regimen Code 4. Dose Regimen revealed 5. Treat headache; complete post-dose assessments 6. Two-hour time point data used to update Adaptive Algorithm weekly 7. Update randomization boundaries
  • Case Study #3: Adaptive Trial Design for Migraine Study
    • Integration Goal: Optimizing adaptive randomization with real time data
    • Data Collection …
    • Subject receives eDiary and waits for qualifying headache to occur, calls IVR system for treatment code
    • Subject records start of headache and intake of study drug
    • A sequence of timed assessments are triggered based on treatment code
    • Subject indicates achieving perceptible or meaningful pain relief
    Example
  • Case Study #3: Adaptive Trial Design (continued)
    • Data Transfer …
    • Data collected in timed assessments is primary endpoint
    • Assessment data is transferred to Adaptive Trial Design system
    • System updates algorithm based on treatment data
    • Attributes of Data Transfer:
      • Cumulative data set – all timed assessments for all subjects
      • ASCII file format
      • Transfer data for each new set of 10 subjects
      • data uploaded automatically via secure FTP
  • Case Study #4: Peak Flow Meter Integration
    • Integration Goal: Combine subjective and objective data
    • Data Collection …
    • eDiary prompts subject to use peak flow meter twice daily
    • Peak Flow Meter (eSense PiKo) captures
      • Peak Expiratory Flow (PEF)
      • Forced Expiratory Volume in 1 Second (FEV1)
      • Time and quality of blows
    • ePEF has wireless radio frequency link to the eDiary
  • Case Study #4: Peak Flow Meter Integration (continued)
    • Data Transfer …
    • Peak flow Meter transfers PEF and FEV1 values to eDiary while subject completes morning and evening diaries
    • Diary data sent to ePRO portal includes both responses to diary questions and peak flow readings
    • Data Summaries developed to:
      • Track the peak flow meter linked to each eDiary
      • Track subject compliance in sending automatic vs. manual readings
  • Integration Considerations and Best Practices
    • Identify the integration goals
      • Who will benefit (sites, data management, subjects)?
      • Assess criticality – is the integration needed to meet study goals?
    • Define cost benefit
      • What is the cost of the integration?
      • What costs are avoided because of the integration?
    • Clearly define requirements
      • End user experience
      • Standards used (e.g. CDISC, other data formats)
    • One way data integration is simpler than two directions
      • Plan for how edits to existing data will be handled
    • Avoid possibility of multiple sources of conflicting data
      • Visit dates coming from 2 different systems
    • Plan for a User Acceptance Testing of the integrated systems
      • Identify unusual use cases
    • People need to communicate for systems to integrate
  • Thank you for your time! Questions? Sheila Rocchio 617.973.1666 [email_address]