The Real Reason Sites Need eSource

Most discussion about electronic source (eSource) documentation in the clinical research enterprise starts from a sponsor standpoint, with eSource being viewed as an extension-almost a mobile version of electronic data capture (EDC). In this view, sponsors provide sites with eSource systems that the sites use to collect data, which are then transmitted to the EDC system. This is a sensible view, but it misses a bigger opportunity. Independent of a sponsor mandate, sites need eSource technology for one fundamental reason: to manage complex operations in an efficient and high-quality manner.

Clinical research is a complicated business. Research protocols are nuanced, with numerous requirements for patient compliance, investigational product administration, clinical procedures, and data capture. To execute protocols properly requires extensive and rigorous project planning, task management, and data collection processes.

However, to date, few good technology options have existed that enable sites to manage these processes efficiently. Electronic health record (EHR) systems, for instance, are not optimized for clinical research and lack critical features sites need, such as the ability to easily build research-specific templates, pre-program visit windows, or provide isolated, study-specific views to clinical research associates (CRAs). As a result, 96% of site staff recently surveyed report using paper, and not EHR, as their primary data collection tool.

Without good technology, sites end up spending too much time on inefficient and error-prone pen-and- paper processes. This misallocation of time limits the attention site staff can devote to patient recruitment and retention, and serves as a drag on the financial health of the industry.

The Growing Complexity of Research Protocols

The complexity of clinical research seems to be an ever-growing trend. As Table 1* indicates, Phase III studies have more visits, procedures, endpoints, and eligibility criteria than they did 10 years ago. All of this complexity leads to greater data collection requirements, which in turn lead to more complex research procedures.

It is hard to execute many clinical trial procedures accurately using pen and paper. Take, for instance, a “simple” procedure such as contraception. The purpose of this procedure is to ensure that subjects do not become pregnant or cause pregnancy during the course of a study. Nearly every interventional drug study will have a requirement that women of childbearing potential agree to use contraception during the life of the study.

Table 2* depicts actual variations across study protocols in how the contraception requirement is to be fulfilled. As the table shows, protocols differ in their definition of “post-menopausal,” what procedures are considered surgical sterilization, how much and what kind of contraception is required, and what is required of male subjects.

This complexity is difficult to manage using paper templates. Figure 1* shows an actual example of a paper source template written by a research site against one of the “female contraception requirement” protocols above. Note how easy it is to miss checkboxes or branching logic. For example, a harried coordinator could check off “N/A [Male]” at the top, but then miss the requirement that the male subject be educated about refraining from sperm donation.

Coordinators routinely miss required data fields because paper is not interactive and does not provide the real-time alerts to ensure accurate data at point of capture. CRAs may come to visit a site weeks after the fact and catch a mistake, which means the coordinator then has to update the missing data field (often requiring a call to a patient for follow-up). Because the paper source was not adequately completed in the first place, a coordinator has to spend precious time on data correction down the road.

This “simple” procedure isn’t so simple then! The average study could easily have more than 20 procedures. Picture a small research site with five coordinators who manage 15 studies at any given time and have to collect data against 300 complex and unique requirement sets.

Collecting Data Outside Visits is Also Challenging

The above example is about data collected during a visit; however, research trials require extensive management of tasks before and after visits. For instance, coordinators have to schedule visits within precise visit windows (e.g., the Week 8 visit must be eight weeks from Baseline Visit, plus/minus three days). Coordinators must keep track of new informed consent form (ICF) versions and re-consent patients before conducting procedures at their next visit, and keep track of central lab results, ECG interpretations, third-party medical records, and other documents that come in between visits, and which are critical to determining eligibility.

Research staff have to manage patient compliance; they often have to schedule offsite procedures, train patients how to use diaries, and check online patient portals to track compliance. They must remind patients prior to certain visits of visit-specific requirements, such as medication wash-out, fasting, or exceptions from their normal study routine (e.g., skip the morning dose of study medication).

Here’s an example of a single protocol that had differing visit requirements within the same study:

• Visit A: Fasting visit
• Visit B: Fasting visit and skip morning dose
• Visit C: Take morning dose but time visit so pharmacokinetic sample can be done within two to four hours of dose
• All other visits: No fasting; take morning dose on the day of the visit

With all this complexity, before, during, and after a visit, is it any wonder that sites struggle to keep up with the demands of modern protocols?

The Research Industry Needs Operational Technology

Every modern industry utilizes technology to streamline and automate operations. Can you imagine a bank balancing its ledgers with paper books? Or a major retailer managing inventory from paper logs?

Just like banks or retailers, research sites are running complex operations, but unlike other industries, too many sites are running these operations using pen-and-paper processes. Inventory is kept on paper logs (the “investigational product [IP] logs”); design specifications (the source templates) are done in Word and then printed out and delivered by hand to the production staff (the research teams); production (data capture) is done manually, with no technological guardrails.

In such an environment, quality of output rises and falls with the individual skill and commitment of the person doing it. This is why site-centric eSource technology can significantly improve operations. Well-designed eSource technology allows sites to construct and put in place technological guardrails against protocol deviations, and to automate processes that are routine, such as ICF version tracking, visit window calculation, or body mass index and other calculations. It standardizes workflow and makes output less dependent on the individual coordinator’s skills.

Site-centric eSource technology features should, at minimum, allow sites to:

• design and manage all of their own studies in a single platform;
• house research-specific templates and create their own for future use;
• collect data and receive real-time alerts to ensure accurate data collection;
• provide CRAs with study-specific, anonymized access to view and quality control subjects and visits;
• enables routing, digital annotation, and e-signature of lab reports, ECG tracings, and other documents; and
• take advantage of research-specific workflows such as visit scheduling, ICF version tracking, internal quality control, patient reminders, and task management.

What would be the impact of a technology like this on site operations? Technology like this should:

• Save significant time by reducing the need to print and manage paper binders, populate data fields that can be automated, reduce re-work, and eliminate the need to transport binders. A site that recently adopted eSource, in fact, reported productivity gains of 20% compared to its previous paper-based process.
• Enhance principal investigator (PI) oversight by allowing them to access and modify source data at any time. For instance, if a patient has a high-risk adverse event (AE) while the PI is offsite, the PI could log into the eSource record to review the AE and related information, thus facilitating timely assessment and action.
• Improve quality through the use of real-time alerts to guide investigators and coordinators as they complete data entry. A third-party auditor, for instance, found that well-designed eSource provides safeguards against 50% of the most commonly cited deviations.
• Enable more rapid onboarding of new employees by standardizing their workflow, and enable more coverage among site staff. For instance, back-up coordinators are much more likely to be successful if they can work with interactive eSource, and not to have to rely on soft knowledge of a protocol that the prime coordinator has through extensive training.

What are the Challenges and Caveats to Implementation?

The biggest challenge comes from the learning curve faced in the adoption of any new technology and workflow. Every member of the site must adopt the technology and accompanying process changes.

For many, real-time EDC will be a new experience. It may not feel as “real” or as substantive as handwritten paper templates. The templates will likely present themselves differently than on paper; there will be new features and workflows to master. To overcome these challenges, site management needs to implement a staged roll-out accompanied by extensive staff training and communication.

Sites must also develop, or outsource, a strong eSource design capability. As with paper source templates, eSource templates need to be thoughtfully designed and tailored to protocol requirements. In addition, they should incorporate appropriate use of technological features such as alerts and branching logic. Only when the templates are well designed will the site realize significant efficiency and data quality gains, so site management should identify, at the outset, who will be designing their eSource templates and how they will be trained. They should also develop robust processes for eSource template design and quality control.

In addition, site leaders must ensure that any eSource system used complies with local regulations. The PI is ultimately responsible for compliance (not the vendor), and this means that sites should have in place an eSource standard operating procedure governing the use of the technology as well as documentation concerning the system’s compliance with regulatory requirements. For the U.S., this means compliance with expectations regarding electronic records and electronic signatures found in 21 CFR Part 11 of the Code of Federal Regulations. For the European Union, this means compliance with Annex 11 to Volume 4 of the Rules Governing Medicinal Products in the European Community, Computerized Systems.

Sites also may need to manage other stakeholders. For large healthcare networks, that may mean the engagement and approval of groups tasked with procurement, compliance, technology, or governance. If site leaders anticipate that only staff members and not patients will use the system, they will likely not need local institutional review board (IRB) approval, although they should check their IRB’s requirements first.

For industry-funded trials, sites need to develop a policy on how and when to notify sponsors and provide access to, and train, the CRAs. While the PI has the absolute right to use electronic instead of paper source, site management must factor in the sponsor’s right to ascertain compliance and the CRAs’ need for access.

Finally, site personnel should understand that while there are basic regulatory requirements that govern the use of eSource, the technology is new and no standards have emerged. Since eSource is an internal workflow tool, sites do not need interoperability with other systems to reap the benefits. However, site leaders may want to consider how eSource can or will integrate with other systems, such as sponsor EDC systems. If using an outside vendor, they may ask about interoperability with EDC systems and the vendor’s adherence to Clinical Data Interchange Standards Consortium (CDISC) standards, which are a set of protocols that govern the transference and presentation of data within the clinical research industry.

How Would This Work with EDC Systems?

Many eSource systems start with the needs of the EDC system; however, as discussed above, a good eSource system should start with the needs of the site. Ideally, the two systems “talk” to each other to enable seamless flow of data from eSource to EDC.

Figure 2* depicts the ideal relationship between eSource and EDC. The left-hand side depicts eSource as a workflow tool optimized for research sites. The right-hand side depicts EDC as a workflow tool optimized for the sponsor’s data management group.

The eSource template contains all the data required to populate the electronic case report form (eCRF) plus all the compliance data required to document protocol compliance. For example, while eCRF might require that only the systolic and diastolic blood pressure be entered, the equivalent eSource might include documentation on the patient’s position (e.g., sitting), the time of position, the time of vitals, and the arm used. All of these data elements are important to document that the vitals were obtained in a manner consistent with the protocol.

In this model, a subset of the eSource data fields are mapped to their eCRF-equivalent data fields. These data fields should be edit locked, so that the user does not “break” the integration by modifying them. The rest of the eSource data fields relate to protocol compliance and site workflows, and have no analogous eCRF fields. These fields can be configured by the site. This arrangement has numerous advantages:

• It preserves site independence since the site’s data are housed in a separate database.
• It allows sites to configure source templates to match site workflow requirements, while standardizing the fields that are required to preserve the integrity of the eCRF mapping for sponsor analysis.
• It enables an “opt in” strategy, in which sponsors can standardize their data collection on a single, global platform across the trial, while individual sites can opt to use an eSource system or traditional manual data capture with subsequent data entry.

A data model like this ensures that site staff can use a workflow tool that meets their needs, while realizing the efficiency of EDC integration. When free to choose their own system, site leaders are incentivized to select one that maximizes their own staff productivity.

Conclusion

Increasingly, sites are recognizing the advantages of technology and incorporating it into workflows. Many have adopted the recent spate of purpose-built eRegulatory or eSource solutions provided by vendors, without waiting for data integrations that will take longer to mature. In going paperless, these sites are furthering the evolution of the industry to a more technology-centric approach, which will be critical to manage the ever-growing complexity of clinical trials.

PEER REVIEWED

References

1. Milam D. 2017. Society for Clinical Research Sites presentation. eSource – A Research Site Perspective. www.cbinet.com/sites/default/files/files/Milan_ Dan_Pres-updated.pdf
2. Bolten B. 2017. Sites wrestle with protocol design complexity. CenterWatch Monthly 24(3) (citing Tufts Center for the Study of Drug Development). https://www.centerwatch.com/news-online/2017/03/01/post-june-sites-wrestle-protocol-design-complexity/
3. Clinical Research IO case study. 4. Audit letter provided to Clinical Research IO from ClinPharm Networks.

Raymond Nomizu, JD is cofounder of Clinical Research IO, owner of Beacon Clinical Research, and cofounder of Bench Core LLC, all in Massachusetts.

[DOI: 10.14524/CR-17-0022]

*To see all figures and/or tables published originally in this article, please visit the full-issue PDF of the August 2017 Clinical Researcher