Regulatory Considerations are Key in eSource Data Integration

Jun 01, 2016
Volume 25, Issue 6

FDA defines electronic source (eSource) data as data initially recorded in electronic format. Now that direct data entry (DDE) at the time of the clinic visit, mobile devices, telemedicine, and remote monitoring of clinical trials are all realities, and are no longer “pie-in-the-sky” concepts, it is time for a transformational change in our processes as we plan, design, and execute trials, as well as how we will collect, analyze, and use the potentially huge amount of data coming off mobile devices. 

While the pharmaceutical industry has always used and analyzed data from multiple sources, such as central laboratories, ECG and diagnostic devices, MRIs, etc., the “mobile apps” that are currently flooding the market, if used in the clinical trial space, will provide challenges to data quality as we deal with the large volumes of data collected and with the different operating systems and hardware. Therefore, the current eSource transformation is fraught with challenges that must be overcome, including regulatory compliance, cooperation, and acceptance by the patients and clinical research sites, who are the customers of our trials, and strict approaches to validation of these electronic tools. We must also separate the “toys from the tools.” Just having a “neat app” won’t fly in the regulated ecosystem we all must live in.

Fortunately, the regulators have beat us to it. There are now FDA and EMA guidance on eSource, eInformed consent, mobile devices, and risk-based monitoring, with more to come. In terms of data integration, there are also active programs to integrate the electronic medical record (EMR) with clinical trial electronic data capture (EDC) systems, and companies are starting to include the use of FDA-approved mobile devices such as glucometers, blood pressure monitors, and ECG devices as part of their clinical trials. 

It’s critical to involve regulators when the use of these devices impacts the management of subject safety and the evaluation of primary and secondary endpoints. Also, as potentially non-regulated devices are used or regulated devices are used “off-label,” we must be ever-vigilant on the software validation process, the impact of app performance when used with various operating systems and devices, as well as the impact of system upgrades on the validated state of software.

As we collect continuous data, such as ECG readings, number of steps taken during wake time, or number of awakenings when participating in a nocturia trial, the software should have validated algorithms to summarize the outcomes rather than requiring the pharma or device company to do the analysis from scratch. This will be one of the main advantages of using FDA-cleared devices presenting with validated software. For example, the Vicor PD2i Analyzer is a software algorithm for recording heart rate variability (HRV) using the point correlation dimension algorithm (PD2i). The intended use of the tool is to display and analyze electrocardiographic information and to measure HRV. 

The following quality measures were applied to the development of the system and given to FDA as part of the approval process: 

  • Level of concern and hazard analysis 
  • User requirements 
  • Software requirement specification 
  • Software design specification 
  • IQ/OQ/PQ 
  • Software release

This is an exciting time in drug and device development, where the goal is to improve processes and reduce the time to get safe and effective drugs and devices to the patients who need them. However, we must make sure that as we “do more with less” (the words first coined by visionary Buckminster Fuller), we do not add more complexity to an already complex system.

 


 

Jules Mitchel, MBA, PhD, is President, Target health inc. 

native1_300x100
lorem ipsum