1) Learning Objectives

After reading this chapter, the reader should understand

• The regulatory basis for practices in selecting an EDC system

• Common requirements and functionality domains of EDC systems

• Key domains and criteria for pre-selection evaluation of EDC systems

• Process impact and redesign considerations at evaluation and selection time

• Initial system implementation within an organization

2) Introduction

Historically, data for clinical trials have been manually abstracted from medical records, electronically extracted from medical records, or recorded directly on Case Report Forms.¹ For multicenter clinical studies a variety of approaches have been reported and have evolved toward decentralized entry of data at clinical sites.² Advantages of relocating data entry closer to the data source with data checks that flag discrepant data on the user interface during entry have been well articulated as have barriers and challenges.² The latter have evolved over time and with technology advances and adoption have mostly been reduced to operational challenges overcome in most research contexts.

Reports of EDC predecessor systems and process, called Remote Data Entry (RDE) started appearing in the 1970s with the then increasing accessibility of computers.^{3,4,5,6,7,8,9} Widespread access to the internet at the beginning of this century offered opportunity to centralize technology management while maintaining the ability for clinical sites to enter and respond to queries about data. Several informative historical accounts of the development of web-based EDC as a technology are available.^2,10,11 Most EDC systems today are fully web-based and accessed through web browsers.

Choosing an EDC system can and should be a significant decision for an organization. EDC system selection decisions are complex. Such decisions involve choices about processes for collecting and managing data that involve the entire trial team. Adopting new information technology offers new opportunity for process redesign such as workflow automation and other decision support. It has been argued that the real gains from EDC come with use of the technology to re-engineer processes.^{10,12,13,14,15,16,17,18,19} Organizations must decide to what extent a new system needs to support existing processes for data collection, management, and monitoring versus offer new ways of working. EDC system selection and implementation usually involves many stakeholders including, but not limited to, project management, data management, clinical management, biostatistics, and information technology.

While sometimes EDC systems are chosen for an individual study, more frequently the chosen system will be used for multiple studies conducted by an organization and will impact operating procedures at clinical investigational sites and throughout clinical study operations. As the primary system for data collection and management in clinical studies today, EDC systems can be a cornerstone of, integral component of, and leaping-off point toward greater safety, quality, and efficiency in clinical studies.

3) Scope

This first of three chapters on web-based Electronic Data Capture (hereafter EDC) covers considerations in and criteria and processes for selection of software for web-based EDC in clinical studies. Topics covered include common EDC system functionality, evaluation of candidate systems and vendors, and consideration of process impact and potential for process redesign at the time of system selection. The primary focus in this chapter is the identification of requirements for the EDC platform itself. These include functionality important to human subject protection, data integrity, study conduct – including needs of system users, and Title 21 Part 11 compliance. Other important aspects of choosing an EDC system such as software delivery, acquisition models, vendor stability, and cost estimation are addressed as are initial software implementation considerations.

Recommendations for building a study within an EDC system, testing a built study, study start-up, and provisions for change control for an EDC study are covered in the second EDC Chapter titled “Electronic Data Capture –Study Implementation and Start-up.” Aspects of study conduct and study closeout are addressed in the third and final EDC Chapter entitled “Electronic Data Capture – Study Conduct, Maintenance, and Closeout”. The EDC chapters contain applications of good clinical data management practices specific to data collection and management using web-based EDC. General good clinical data management practices are not re-articulated here.

4) Minimum Standards

The International Council for Harmonisation (ICH) E6 (R2) contains several passages particularly relevant to EDC software selection and initial implementation.²⁰

Section 2.8 states, “Each individual involved in conducting a trial should be qualified by education, training, and experience to perform his or her respective tasks.”²⁰ Echoing similar statements elsewhere in ICH Good Clinical Practice (GCP) and in Title 21 CFR Part 11, this requirement applies to EDC software selection in that it applies to individuals involved in EDC system selection, installation, testing, use, and maintenance whether they are performed in-house or elsewhere. Where tasks are performed by other organizations, this requirement is met through vendor qualification assessments, usually part of software selection decision making. Functionality to record and track over time system privileges assigned to users, i.e., tasks that users are allowed to perform in the system, becomes criteria used in software evaluation and selection.

Section 2.10 states, “All clinical trial information should be recorded, handled, and stored in a way that allows its accurate reporting, interpretation, and verification.”²⁰ Functionality to meet this requirement becomes criteria used in software evaluation and selection.

Section 2.11 states, “The confidentiality of records that could identify subjects should be protected.”²⁰ Functionality to meet this requirement becomes criteria used in software evaluation and selection.

Section 4.9.0 states, “The investigator/institution should maintain adequate and accurate source documents and trial records that include all pertinent observations on each of the site’s trial subjects. Source data should be attributable, legible, contemporaneous, original, accurate, and complete. Changes to source data should be traceable, should not obscure the original entry, and should be explained if necessary (e.g., via an audit trail).”²⁰ This investigator site requirement applies to EDC systems because the EDC system can serve as the original capture of information, in which case the EDC system is maintaining source data. Where the EDC system is intended to be used in this way, functionality to meet this requirement becomes criteria used in software evaluation and selection.

Section 4.9.2 states, “Data reported on the CRF, that are derived from source documents, should be consistent with the source documents or the discrepancies should be explained.”²⁰ Functionality in EDC systems for triggering data to be source document-verified and tracking such verification supports this GCP requirement and becomes criteria used in software evaluation and selection.

Section 5.0 in the following passage recommends use of quality management systems and advocates risk management.

“The sponsor should implement a system to manage quality throughout all stages of the trial process.

Sponsors should focus on trial activities essential to ensuring human subject protection and the reliability of trial results. Quality management includes the design of efficient clinical trial protocols, tools, and procedures for data collection and processing, as well as the collection of information that is essential to decision making.

The methods used to assure and control the quality of the trial should be proportionate to the risks inherent in the trial and the importance of the information collected. The sponsor should ensure that all aspects of the trial are operationally feasible and should avoid unnecessary complexity, procedures, and data collection. Protocols, case report forms (CRFs), and other operational documents should be clear, concise, and consistent.

The quality management system should use a risk-based approach.”²⁰

A Quality Management System necessitates that executive leadership articulate and support a quality policy that documents leadership intent with respect to quality management. Because methods used to collect and manage data impact quality, executive leadership support for EDC selection and use is imperative. Further, leadership should assure that the quality management system extends throughout the organization and to vendors, suppliers, and sub-contractors where appropriate through a vendor qualification and management program.

Section 5.0.1 further advocates a process-oriented quality management system approach stating that “During protocol development the Sponsor should identify processes and data that are critical to ensure human subject protection and the reliability of trial results.”²⁰ Processes reliant upon EDC software may meet this requirement. EDC functionality to indicate, process, and report on data deemed critical is supportive of meeting this requirement and becomes criteria used in software evaluation and selection.

Section 5.1.1 further states, “The sponsor is responsible for implementing and maintaining quality assurance and quality control systems with written SOPs to ensure that trials are conducted and data are generated, documented (recorded), and reported in compliance with the protocol, GCP, and the applicable regulatory requirement(s).”²⁰ Title 21 CFR Part 11 also requires SOPs for data collection, entry, and changes²¹; in the case of EDC, these apply directly to clinical investigational sites as well as data sponsors. Functionality supporting auditable processes becomes criteria used in software evaluation and selection.

Section 5.1.2 protects access to source data and documents stating, “The sponsor is responsible for securing agreement from all involved parties to ensure direct access (see section 1.21) to all trial-related sites, source data/documents, and reports for the purpose of monitoring and auditing by the sponsor, and inspection by domestic and foreign regulatory authorities.”²⁰ Where the EDC system is used to collect and maintain source data, this criterion applies. EDC software functionality to support controlled and direct access to source data and documents supports this requirement and becomes criteria used in software evaluation and selection.

Section 5.1.3 states, “Quality control should be applied to each stage of data handling to ensure that all data are reliable and have been processed correctly.”²⁰ EDC system functionality to support automated detection, alerting, and tracking resolution of discrepant data directly supports this requirement as does functionality to support source document verification and reconciliation of data captured through EDC with externally collected or managed data. As such, this functionality becomes criteria used in software evaluation and selection.

Section 5.5.1 refers to qualifications of study personnel and states, “The sponsor should utilize appropriately qualified individuals to supervise the overall conduct of the trial, to handle the data, to verify the data, to conduct the statistical analyses, and to prepare the trial reports.”²⁰ This general requirement applicable to all data requires that personnel qualifications, including site users of EDC systems, with respect to the EDC software and its use be documented. The role of personnel qualifications in software selection decisions is described above in ICH E6R2 section 2.8.

Section 5.5.3 concerns validation of computerized systems and states, “When using electronic trial data handling and/or remote electronic trial data systems, the sponsor should, a) Ensure and document that the electronic data processing system(s) conforms to the sponsor’s established requirements for completeness, accuracy, reliability, and consistent intended performance (i.e., validation).”²⁰ This requirement echoes Title 21 CRF Part 11 and requires that the installation of the EDC system used for a study be validated.

Section 5.5.3’s first addendum states that validation of computer systems should be risk-based. “The sponsor should base their approach to validation of such systems on a risk assessment that takes into consideration the intended use of the system and the potential of the system to affect human subject protection and reliability of trial results.”²⁰ This general GCP requirement promotes right-sizing the type and extent of validation of system functionality to the assessed risk associated with functionality. In EDC systems, building a study within validated software has significantly less risk than developing new software. Open source software has different risks than commercial software or in-house custom-developed software. These risk differences are considerations in EDC software selection and initial implementation including system validation.

Section 5.5.3 addendum b states that an organization “Maintains SOPs for using these systems.”²⁰ The 5.5.3 addendum c-h introductory statement enumerates topics that should be covered in SOPs. “The SOPs should cover system setup, installation, and use. The SOPs should describe system validation and functionality testing, data collection and handling, system maintenance, system security measures, change control, data backup, recovery, contingency planning, and decommissioning.”²⁰ These requirements apply to system selection and initial implementation in that the processes covered by the requirement can be significantly impacted by the functionality available in an EDC system being used by a sponsor. Further, individual requirements in the section such as 5.5.3 addendum (e) “Maintain a list of the individuals who are authorized to make data changes”, (g) “Safeguard the blinding, if any”, and (h) “Ensure the integrity of the data, including any data that describe the context, content, and structure”²⁰ enumerate functionality that become evaluation criteria to the extent EDC system support of these requirements is required by the organization.

Section 5.5.4 concerns traceability and states, “If data are transformed during processing, it should always be possible to compare the original data and observations with the processed data.”²⁰ This requirement directly states functionality needed in EDC systems for GCP compliance.

Section 8.0 states that documents that “individually and collectively permit evaluation of the conduct of a trial and the quality of the data produced”²⁰ are considered essential documents and shall be maintained as controlled documents, i.e., “should provide for document identification, version history, search, and retrieval”. This requirement impacts EDC software selection and implementation in that EDC functionality to manage and control data specifications, including definition and specifications for programmatic operations performed on data, eases the external document control burden and includes the records maintained via this functionality as essential documents.

Title 21 CFR Part 11 also identifies regulatory requirements for traceability, training and qualification of personnel, and validation of computer systems used in clinical trials.²¹ Requirements in 21 CFR Part 11 Subpart B are stated as controls for closed systems (21 CFR Part 11 Sec. 11.10), controls for open systems (21 CFR Part 11 Sec. 11.30), signature manifestations (21 CFR Part 11 Sec. 11.50), and signature/record linking (21 CFR Part 11 Sec. 11.70). Requirements for electronic signatures are stated in in 21 CFR Part 11 Subpart C. The requirements in Title 21 CFR Part 11 directly impact EDC software selection and initial implementation. Where Part 11 compliance is required, the technical controls stipulated become software evaluation and selection criteria. Where the EDC system needs to be Title 21 CFR Part 11 compliant, which in the United States includes all studies submitted to the FDA for regulatory review as well as many studies funded by the National Institutes of Health (NIH), the Part 11 technical controls become software evaluation and selection criteria. In addition, a common interpretation of these regulations is that important functionality be documented on a traceability matrix that explicitly documents the functions and ways in which they were tested.²¹

The March 2018 FDA Study Data Technical Conformance Guide Technical Specifications Document is incorporated by reference into the Guidance for Industry Providing Regulatory Submissions in Electronic Format – Standardized Study Data. The appendix of the Study Data Technical Conformance Guide states, “In addition to standardizing the data and metadata, it is important to capture and represent relationships (also called associations) between data elements in a standard way”.²² As such, documenting associations between data elements becomes an EDC software selection criterion.

The Medicines and Healthcare products Regulatory Agency (MHRA) ‘GXP’ Data Integrity Guidance and Definitions provides considerations and regulatory interpretation of requirements for data integrity, such as:

Section 5.1 “Systems and processes should be designed in a way that facilitates compliance with the principles of data integrity.”²³ In E6(R2) the FDA defines data integrity as, “completeness, consistency, and accuracy of data” and goes on to state that “Complete, consistent, and accurate data should be attributable, legible, contemporaneously recorded, original or a true copy, and accurate (ALCOA).”²⁰ Section 6.4 of the MHRA guidance similarly defines data integrity as, “the degree to which data are complete, consistent, accurate, trustworthy, reliable and that these characteristics of the data are maintained throughout the data life cycle. The data should be collected and maintained in a secure manner, so that they are attributable, legible, contemporaneously recorded, original (or a true copy) and accurate”.²³ Functionality to assure data integrity becomes EDC software evaluation criteria.

Section 6.9 of the MHRA guidance states, “There should be adequate traceability of any user-defined parameters used within data processing activities to the raw data, including attribution to who performed the activity.”²³ Functionality to assure data traceability becomes EDC software evaluation criteria.

The General Principles of Software Validation; Final Guidance for Industry and FDA Staff points out relevant guidelines regarding documentation expected of software utilized in a clinical trial. This guidance discusses software validation processes rather than functionality; these are not enumerated here. For commercial systems, this criterion can be met through a Quality Management System assessment during vendor assessment. For in-house developed EDC software, this criterion is met through an internal Quality Management System that covers the software development lifecycle.²⁴

Good Manufacturing Practice Medicinal Products for Human and Veterinary Use (Volume 4, Annex 11): Computerised Systems provides the following guidelines when using computerized systems in clinical trials:

Section 1.0 echoes ICH E6(R2) stating, “Risk management should be applied throughout the lifecycle of the computerised system taking into account patient safety, data integrity and product quality. As part of a risk management system, decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system.” This impacts EDC system implementation in the level of testing and controls applied and, like ICH E6(R2), implies that a documented risk assessment should exist for the system.^20,25

Section 4.2 states, “Validation documentation should include change control records (if applicable) and reports on any deviations observed during the validation process.”²⁵ Functionality to track changes to the system set-up for a study becomes EDC software evaluation criteria.

Section 4.5 states, “The regulated user should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system.”²⁵ For commercial systems, this criterion can be met through a Quality Management System assessment during vendor assessment. For in-house developed EDC software, this criterion is met through an internal Quality Management System that covers the software development lifecycle.

Section 7.1 states, “Data should be secured by both physical and electronic means against damage. Stored data should be checked for accessibility, readability and accuracy. Access to data should be ensured throughout the retention period.”²⁵ The technical controls for data access become software evaluation and selection criteria. Readability, accuracy, and other data quality dimensions may be impacted by incorrect system operation. Thus, functionality enabling data accessibility, readability, and accuracy assessment during a study becomes EDC software evaluation criteria.

Section 7.2 states, “Regular back-ups of all relevant data should be done. Integrity and accuracy of backup data and the ability to restore the data should be checked during validation and monitored periodically.”²⁵ These functions become software evaluation and selection criteria.

Section 10.0 states, “Any changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure.”²⁵ For commercial systems, this criterion can be met through a Quality Management System assessment during vendor assessment. For in-house developed EDC software, this criterion is met through an internal Quality Management System that covers the software development lifecycle.

GAMP 5: A Risk-based Approach to Compliant GxP Computerized Systems pre-dated ICH E6(R2) in suggesting scaling activities related to computerized systems with a focus on patient safety, product quality, and data integrity. GAMP^® 5 provides guidance for maintaining compliant computerized systems fit for intended use. While GAMP^® 5 does not articulate additional functional requirements that impact EDC software selection, the evaluation of vendors, open source products, and development and evaluation of in-house software can all be informed by the approaches in GAMP^® 5. GAMP^® 5 provides the following guidelines relevant to systems used to collect and process clinical trial data:

Section 2.1.1 echoes the risk-based approach articulated in ICH E6(R2) and states, “Efforts to ensure fitness for intended use should focus on those aspects that are critical to patient safety, product quality, and data integrity. These critical aspects should be identified, specified, and verified.”²⁶ Like ICH E6(R2) this promotes right-sizing the type and extent of validation of system functionality to the assessed risk associated with functionality.

Section 4.2 states, “The rigor of traceability activities and the extent of documentation should be based on risk, complexity, and novelty; for example, a non-configured product may require traceability only between requirements and testing.”²⁶ Like ICH E6(R2) this promotes right-sizing the type and extent of traceability-related system functionality to the assessed risk associated with functionality.

Section 4.2 states, “The documentation or process used to achieve traceability should be documented and approved during the planning stage, and should be an integrated part of the complete life cycle.”²⁶ As such, these functions become software evaluation and selection criteria.

Section 4.3.4.1 “Change management is a critical activity that is fundamental to maintaining the compliant status of systems and processes. All changes that are proposed during the operational phase of a computerized system, whether related to software (including middleware), hardware, infrastructure, or use of the system, should be subject to a formal change control process (see Appendix 07 for guidance on replacements). This process should ensure that proposed changes are appropriately reviewed to assess impact and risk of implementing the change. The process should ensure that changes are suitably evaluated, authorized, documented, tested, and approved before implementation, and subsequently closed.”²⁶ Functionality to track changes to the system set-up for a study becomes EDC software evaluation criteria.

Section 4.3.6.1 states, “Processes and procedures should be established to ensure that backup copies of software, records, and data are made, maintained, and retained for a defined period within safe and secure areas.”²⁶ These functions become software evaluation and selection criteria.

Section 4.3.6.2 states, “Critical business processes and systems supporting these processes should be identified and the risks to each assessed. Plans should be established and exercised to ensure the timely and effective resumption of these critical business processes and systems.”²⁶ Business resumption becomes an evaluation and selection criterion for EDC vendors and an implementation consideration for internal and vended solutions.

Sections 5.3.1.1 and 5.3.1.2 inform organizational risk assessment procedures and respectively state, “The initial risk assessment should include a decision on whether the system is GxP regulated (i.e., a GxP assessment). If so, the specific regulations should be listed, and to which parts of the system they are applicable. For similar systems, and to avoid unnecessary work, it may be appropriate to base the GxP assessment on the results of a previous assessment, provided the regulated company has an appropriate established procedure.” and that “The initial risk assessment should determine the overall impact that the computerized system may have on patient safety, product quality, and data integrity due to its role within the business processes. This should take into account both the complexity of the process and the complexity, novelty, and use of the system.”²⁶

The FDA guidance, Use of Electronic Health Record (EHR) Data in Clinical Investigations, emphasizes that data sources should be documented and that source data and documents be retained in compliance with 21 CFR 312.62(c) and 812.140(d). It further states, “FDA’s acceptance of data from clinical investigations for decision-making purposes depends on FDA’s ability to verify the quality and integrity of the data during FDA inspections.”²⁷

Section IV defines interoperability as, “the ability of two or more products, technologies, or systems to exchange information and to use the information that has been exchanged without special effort on the part of the user”²⁷ and recognizes that “EHR and EDC systems may be non-interoperable, interoperable, or fully integrated, depending on supportive technologies and standards.”²⁷ Where integration or interoperability is desired by the sponsor, these become EDC software selection requirements. Such requirements may include system support for data interchange according to specific standards such as the Health Level Seven (HL7) Fast Healthcare Interoperability Resource (FHIR^®) standards or the Clinical Data Interchange Standards Consortium (CDISC) Operational Data Model (ODM) standard.

Section IV.C states, “FDA encourages sponsors to periodically check a subset of the extracted [from EHRs] data for accuracy, consistency, and completeness with the EHR source data and make appropriate changes to the interoperable system when problems with the automated data transfer are identified.”²⁷ Functionality in EDC systems accepting electronic EHR data to enter re-abstracted data and itemize and track resolution of discrepancies would support this guidance recommendation. Where desired, such functionality becomes an EDC software selection criterion.

Section V.C.1 echoes the eSource guidance and states that the EDC system should have the ability to identify the EHR as “the data originator for EHR data elements gathered during the course of a clinical investigation”²⁷ Where EHR interoperability is desired, this functionality becomes an EDC software selection criterion.

Section V.C.2 echoes the eSource guidance and states, “After data are transmitted to the eCRF, the clinical investigator or delegated study personnel should be the only individuals authorized to make modifications or corrections to the data.”²⁷ The section echoes Title 21 CFR Part 11 and further states, “Modified and corrected data elements should have data element identifiers that reflect the date, time, data originator, and the reason for the change” and that “Modified and corrected data should not obscure previous entries”.²⁷ The same section further states, “Clinical investigators should review and electronically sign the completed eCRF for each study participant before data are archived or submitted to FDA”, that “If modifications are made to the eCRF after the clinical investigator has already signed the eCRF, the changes should be reviewed and approved by the clinical investigator”, and that use of electronic signatures for records subject to Title 21 CFR Part 11 must comply with that regulation.²⁷ Where EHR interoperability is desired, this functionality becomes an EDC software selection criterion.

Further echoing the eSource guidance Section V.C.2 states, “If a potential for unblinding is identified, sponsors should determine whether the use of interoperable systems is appropriate or whether other appropriate controls should be in place to prevent unblinding.”²⁷ Where EHR interoperability is desired, this functionality becomes an EDC software evaluation and selection criterion.

Similarly, the FDA’s Guidance on Electronic Source Data Used in Clinical Investigations provides guidance on the capture, review, and retention of electronic source data in FDA-regulated clinical investigations. The guidance “promotes capturing source data in electronic form, and it is intended to assist in ensuring the reliability, quality, integrity, and traceability of data from electronic source to electronic regulatory submission”.²⁸

In the background section, the guidance states, “Source data should be attributable, legible, contemporaneous, original, and accurate (ALCOA) and must meet the regulatory requirements for recordkeeping.”²⁸ Record keeping requirements for clinical investigators and sponsors are detailed in Title 21 CFR 312.50, 312.58, 312.62, and 312.68 for drugs and biologics and Title 21 CFR 812.140 and 812.145 for medical devices.

Section III.A.1 states that all data sources (called originators in the guidance) at each site should be identified. “A list of all authorized data originators (i.e., persons, systems, devices, and instruments) should be developed and maintained by the sponsor and made available at each clinical site.”²⁸ The guidance states that each data element is associated with a data originator. It goes on to state, “When a system, device, or instrument automatically populates a data element field in the eCRF, a data element identifier should be created that automatically identifies the particular system, device, or instrument (e.g., name and type) as the originator of the data element.”²⁸ For a Title 21 CFR Part 11 audit trail, the association with the data originator and data changer is required at the data value level. Where the EDC system is the source, the EDC system should be on this list. In addition, EDC system functionality, where desired, for maintaining the data source list for each site, becomes a requirement in software evaluation and selection decisions.

Section III.A.1 of the guidance requires controls for system access and states, “When identification of data originators relies on identification (log-on) codes and unique passwords, controls must be employed to ensure the security and integrity of the authorized user names and passwords. When electronic thumbprints or other biometric identifiers are used in place of an electronic log-on/password, controls should be designed to ensure that they cannot be used by anyone other than their original owner.”²⁸ This functionality becomes an EDC software selection criterion.

Section III.A.2.d states that when data from an EHR are transmitted directly into the eCRF, i.e., electronically, the EHR is considered the source.²⁸ The stated rationale is that algorithms are often needed to select the intended data value and that this processing step necessitates verification. As such and where EHR-to-eCRF eSource data will be used, the ability to designate the EHR as the source for data values originating from the EHR becomes a requirement in EDC software evaluation and selection.

Section III.A.3 states, “Data element identifiers should be attached to each data element as it is entered or transmitted by the originator into the eCRF”²⁸ and that data element identifiers should contain (1) Originators of the data element, (2) Date and time the data element was entered into the eCRF (this data receipt milestone is also time point at which the EDC system audit trail begins), and (3) association with the subject to which the data belongs.²⁸ The guidance further states that the EDC system “should include a functionality that enables FDA to reveal or access the identifiers related to each data element”.²⁸ As such and where eSource data will be used, the ability to maintain these associations becomes a requirement in EDC software evaluation and selection.

Section III.A.4 states, “Only a clinical investigator(s) or delegated clinical study staff should perform modifications or corrections to eCRF data”.²⁸ Echoing Title 21 CRF Part 11, the section goes on to state, “Modified and/or corrected data elements must have data element identifiers that reflect the date, time, originator and reason for the change, and must not obscure previous entries”, that “A field should be provided allowing originators to describe the reason for the change”, and that “Automatic transmissions should have traceability and controls via the audit trail to reflect the reason for the change.”²⁸ Where the EDC system is used to capture source data, these items become EDC software evaluation and selection requirements.

Section III.A.5 states that the FDA encourages “use of electronic prompts, flags, and data quality checks in the eCRF to minimize errors and omissions during data entry”.²⁸ The rationale is that for eSource data, without an independent recording of the observation, the opportunity to make corrections to the source is gone after the time of the original observation or measurement has passed. For this reason and where the EDC system is used as the original capture of source data, this becomes a requirement for EDC software evaluation and selection.

The same section states, “clinical investigator(s) should have the ability to enter comments about issues associated with the data”.²⁸ Where the EDC system is used as the original capture of source data, this becomes a requirement for EDC software evaluation and selection.

Section III.B.1.a states that to comply with the requirement in 21 CFR 312.62(b) for drugs and biologics and 812.140(a)(3) for devices to maintain accurate case histories, “clinical investigator(s) should review and electronically sign the completed eCRF for each subject before the data are archived or submitted to FDA” and that such electronic signatures must comply with Title 21 CFR Part 11.²⁸ This requirement applies more broadly than just where the EDC system is used as the original capture of source data and as such is routinely a requirement in EDC software evaluation and selection.

Section III.B.1.b goes on to state that in the case where clinical investigators need to be blinded to certain data, the data are exempt from the aforementioned investigator review requirement.²⁸ Where the EDC system is used to capture eSource and blinding of investigators to data is intended, the functionality to do so becomes a requirement in EDC software evaluation and selection.

Section III.B.2 anticipates the eventuality that data changes may be needed after a clinical investigator’s review and signature. The guidance states that in this case, “the changes should be reviewed and electronically signed by the clinical investigator(s)”.²⁸ This requirement applies more broadly than just where the EDC system is used as the original capture of source data and as such is routinely a requirement in EDC software evaluation and selection.

Section III.C states, “clinical investigator(s) should retain control of the records (i.e., completed and signed eCRF or certified copy of the eCRF)”, that “clinical investigator(s) should provide FDA inspectors with access to the records that serve as the electronic source data”, and that data and documents to corroborate source data captured in the EDC system may be requested during an inspection.²⁸ As such, where the EDC system is to be used as the original capture of source data, provision of a certified copy of all such data and relevant context such as the audit trail, data element identifiers, and data originators to the clinical investigator becomes a requirement in EDC software evaluation and selection.

Section III.D emphasizes that the FDA encourages viewing of the data early and by sponsors, CROs, data safety monitoring boards, and other authorized personnel to prompt detection of study-related problems. While prompt data review is not itself a regulatory requirement, adequate clinical trial monitoring is; i.e., “… ensuring proper monitoring of the investigation(s), ensuring that the investigation(s) is conducted in accordance with the general investigational plan and protocols contained in the IND…”.²⁹ As such, functionality to support, facilitate, or automate timely review of data become criteria in EDC software evaluation and selection.

Section III.D also suggests aspects of access control: (1) a list of the individuals with authorized access to the eCRF should be maintained, (2) only those individuals who have documented training and authorization should have access to the eCRF data, (3) Individuals with authorized access should be assigned their own identification (log-on) codes and passwords, and (4) log-on access should be disabled if the individual discontinues involvement during the study.²⁸ These access control requirements echo Title 21 CFR Part 11 and apply more broadly than just where the EDC system is used as the original capture of source data. As such these are common requirements in EDC software evaluation and selection.

With these requirements in mind, in Table 1 we state the following minimum standards for the selection of EDC systems.

5) Best Practices

Best practices, as stated in Table 2, were identified by both the review and the writing group. Best practices do not have a strong requirement based in regulation or recommended approach based in guidance, but do have supporting evidence either from the literature or consensus of the writing group. As such best practices, like all assertions in GCDMP chapters, have a literature citation where available and are always tagged with a roman numeral indicating the strength of evidence supporting the recommendation. Levels of Evidence are outlined in Table 3.

6) Stakeholders in the EDC System Selection Process

Choosing an EDC system involves multiple considerations including strategy, goals, business relationships, and capability of the selecting organization and their desired provisioning models, software functionality, system performance, and available funds. Thus, the list of stakeholders in EDC selection and implementation can be extensive. Operationally, data collection and management decisions such as whether EDC should be used and, if so, for which data and through what types of processes can impact most operational groups involved in clinical trials. Impacted operational groups include, but are not limited to, project management, data management, clinical operations, research pharmacy, biostatistics, information technology, and contracting. Individuals from all of these functional areas are possible stakeholders in the EDC selection and implementation process. [VI] The likelihood that all stakeholder needs will be reflected in the selection of an EDC system increases when those stakeholders and their responsibilities are identified early in the decision making process. [VI]

7) EDC System Selection Considerations

There are over 60 EDC system vendors in the EDC market.³² Companies enter and leave the marketplace often. Though functionality is the most important category of selection criteria with respect to data quality, other considerations such as regulatory compliance, cost, vendor stability, business model compatibility, system flexibility, implementation timing, global experience, and availability of support may narrow the number of appropriate vendors. Kush et al. categorize EDC system selection criteria as aspects of vendor background or product specifications. Product specifications are further categorized as regulatory, standards, usability, operational, and business.¹⁰ A sample Request for Proposals (RFP) including (1) vendor, software, and service characteristics; (2) business relationship information including the licensing model, service, maintenance, and other agreement terms; (3) pricing details; and (4) functional requirements. The Appendix illustrates the information one company found useful in EDC software and vendor selection and the functional requirements necessary for the conduct of their studies. Most organizations use a combination of functional and other criteria. Functionality can be a key differentiating factor among different EDC systems. However other factors such as vendor experience, past performance, financial stability, and pricing can significantly sway if not determine selection decisions. In this case, other business requirements may become a differentiator. Perhaps a lower priced system will be adequate for the simple, short-term studies, whereas a higher end system may be best for a complicated long-term study.

8) EDC Methods of Delivery

There are multiple business models for delivery of the EDC software or a study application. These include technical transfer, software as a service, and software as a service with services. The most used models today are software as a service and software as a service with services.

9) Selecting and Contracting

There are multiple activities associated with selecting and contracting an EDC vendor.

10) Recommended Standard Operating Procedures

In section 5.0.1, ICH E6 states, “During protocol development the Sponsor should identify processes and data that are critical to ensure human subject protection and the reliability of trial results.”²⁰ This implies that organizations should map out the processes involved in study design, start-up, conduct, and closeout and make explicit decisions about which are considered to impact human subject protection and the reliability of study results. Organizational processes may be partitioned differently leading to different scope and titles for SOPs. We provide the following as a list of processes commonly considered to impact human subject protection and the reliability of study results. Organizations may differ as to how these processes are covered in SOPs.

• Vendor or EDC system selection^20,21,40 (Refer to Title 21 CFR 312.52, ICH E6 R2 5.0, and Title 21 CFR Part 11.)

• EDC System Setup, Installation and Support^20,21 (Refer to Title 21 CFR Part 11 and ICH E6 R2 5.5.3 b.)

• Software Development Lifecycle including maintenance and change control²⁰ (Refer to ICH E6 R2 5.5.3 b.)

• Vendor auditing and oversight^20,40 (Refer to Title 21 CFR 312.52, ICH E6 R2 5.0.)

11) Literature Review Details

This revision is based on a systematic review of the peer-reviewed literature indexed for retrieval. The goals of this literature review were to (1) identify published research results and reports of EDC methods and evaluation and (2) identify, evaluate, and summarize evidence capable of informing the practice of selecting and implementing a web-based EDC system.

The following PubMed query was used:

(“electronic data capture” OR “EDC” OR (internet AND “data collection”)) AND (“clinical trial” OR “clinical trials” OR “clinical study” OR registry OR registries OR “observational study” OR “interventional study” OR “phase 1” OR “phase 2” OR “phase 3” OR “phase 4” OR “phase I” OR “phase II” OR “phase III” OR “phase IV” OR “first in man” OR “clinical research” OR “device study” OR “interventional trial” OR “phase 1” OR “phase 2” OR “phase 3” OR “phase 4” OR “phase I” OR “phase II” OR “phase III” OR “phase IV” OR RCT OR “randomized clinical trial” OR “non-interventional” OR “post-marketing authorization” OR “post authorization” OR “adaptive trials” OR “feasibility study” OR “phase 2/3” OR “phase II/III” OR “phase 2a” OR “phase 2b” OR “phase IIa” OR “phase IIb” OR “phase IIb/IIIa” OR “phase 2b/3a”)

The search query was customized for and executed on the following databases: PubMed (777 results); CINAHL (230 results); EMBASE (257 results); Science Citation Index/Web of Science (393 results); Association for Computing Machinery (ACM) Guide to the Computing Literature (115 results). A total of 1772 works were identified through the searches. The latest search was conducted on February 8, 2017. Search results were consolidated to obtain a list of 1368 distinct articles. Because this was the first review for this chapter, the searches were not restricted to any time range.

Two reviewers used inclusion criteria to screen all abstracts. Disagreements were adjudicated by the writing group. Forty-nine sources (mostly articles) meeting inclusion criteria were selected for review. The selected sources were read by the writing group and 109 additional sources identified through the review. Each of these 158 (49 + 109) sources was read for mention of explicit practice recommendations or research results informing practice. A total of 85 sources were deemed relevant to EDC and 73 were excluded by the full text review as not relevant to EDC. Of the 85 relevant sources, 53 were identified as informative for practice in one or more of the EDC GCDMP chapters and 32 were relevant but not informative of practice in any of the three EDC chapters. Sixteen articles provided evidence for this EDC chapter (Figure 1). Relevant findings from these sixteen articles have been included in the chapter and graded according to the GCDMP evidence grading criteria as described in Table 3. This synthesis of the literature relevant to web-based EDC was performed to support the transition of the EDC chapters to an evidence-based guideline.

Figure 1

Preferred Reporting Items for Systematic Reviews and Meta-Analysis (PRISMA) Diagram for Web-based EDC – Selecting an EDC System.

12) Version History

Competing Interests

The authors have no competing interests to declare.

The chapter authors would like to thank Emily Patridge, Katrina M. Donovan, Jennifer Price, and Sean Berryman for their invaluable help with the literature review for this text.

1. Collen MF. Clinical research databases – a historical review. Journal of Medical Systems. 1990; 14(6): 323–344. DOI:  http://doi.org/10.1007/BF00996713

2. Zozus, M. EDC past present and future: An introduction to the revised GCDMP chapters. Data Basics. 2020; 26(3).

3. Kronmal RA, Davis K, Fisher LD, Jones RA, Gillespie MJ. Data management for a large collaborative clinical trial (CASS: Coronary Artery Surgery Study). Comput Biomed Res. 1978; 11(6): 553–66. DOI:  http://doi.org/10.1016/0010-4809(78)90034-4

4. Jennett RJ, Gall D, Waterkotte GW, Warford HS. A computerized perinatal data system for a region. Trans Pac Coast Obstet Gynecol Soc. 1978; 45: 51–7.

5. Fendt K, Helms RW, Morrissey LJ. Some Examples of Implementing Longitudinal Data Management. In SAS. American Statistical Association 1979 Proceedings of the Statistical Computing Section.

6. Helms RW. A distributed flat file strategy for managing research data. In: ACM ‘80 Proceedings of the ACM 1980 annual conference. 1980: 279–285. New York: Association for Computing Machinery. DOI:  http://doi.org/10.1145/800176.809982

7. Neaton JD, Duchene AG, Svendsen KH, Wentworth D. An examination of the efficiency of some quality assurance methods commonly employed in clinical trials. Stat Med. 1990; 9(1–2): 115–23. DOI:  http://doi.org/10.1002/sim.4780090118

8. Christiansen DH, Hosking JD, Dannenberg AL, Williams OD. Computer-assisted data collection in multicenter epidemiologic research: The atherosclerosis risk in communities study. Control Clin Trials. 1990; 11(2): 101–15. DOI:  http://doi.org/10.1016/0197-2456(90)90004-L

9. Reynolds-Haertle RA, McBride R. Single vs. double data entry in CAST. Control Clin Trials. 1992; 13(6): 487–94. DOI:  http://doi.org/10.1016/0197-2456(92)90205-E

10. Kush RD, Bleicher P, Kubick W, et al. eClinical trials planning and implementation. Boston: Thompson Centerwatch Inc.; 2003.

11. Helms RW. Data quality issues in electronic data capture. Drug Inf J. 2001; 35: 827–837. DOI:  http://doi.org/10.1177/009286150103500320

12. Dimenas E, Johansson D, Palmblad M. Wrangstadh M. Clinical operations online (COOL)-a world wide web-based approach to running clinical trials: Results from two international multicenter gastrointestinal trials. Drug Inf J. 2001; 35: 745–753. DOI:  http://doi.org/10.1177/009286150103500313

13. Richardson A. Planing and running the eClinical trial. Appl Clin Trials. 2003; January.

14. Green JA. Realizing the value proposition of EDC. Innovations in Clinical Trials; 2003.

15. Lu Z. Electronic data-capturing technology for clinical trials, experience with a global postmarketing study. IEEE Eng Med Biol Mag. 2010; 29(2): 95–102. DOI:  http://doi.org/10.1109/MEMB.2009.935726

16. Mitchel JT, Kim YJ, Choi J, et al. The impact of electronic data capture on clinical data management perspectives from the present into the future. MONITOR. 2008; August.

17. Mitchel JT, Dean Gittleman D, Park G, et al. The impact on clinical research sites when direct data entry occurs at the time of the office visit: A tale of 6 studies. InSite. 2014; Second Quarter.

18. Kush R. Electronic Data Capture-Pros and Cons. BioExecutive International. 2006; 2(6): S48–52.

19. Laky D. The evolution of EDC into eClinical. epc magazine. 2007; 11(2). Available from: http://www.samedanltd.com/magazine/11/issue/2. accessed September 29, 2020.

20. Food and Drug Administration, US Department of Health and Human Services. ICH E6(R2) Good Clinical Practice: Integrated Addendum to ICH E6(R1), March 2018. Available from https://www.fda.gov/regulatory-information/search-fda-guidance-documents/e6r2-good-clinical-practice-integrated-addendum-ich-e6r1.

21. Food and Drug Administration, US Department of Health and Human Services. Electronic Records; Electronic Signatures, 21 CFR §11 (1997). Available from https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm.

22. Food and Drug Administration, US Department of Health and Human Services. Guidance for industry: Providing Regulatory Submissions in Electronic Format – Standardized Study Data. December 2014. Available from https://www.fda.gov/regulatory-information/search-fda-guidance-documents/providing-regulatory-submissions-electronic-format-standardized-study-data.

23. Medicines and Healthcare products Regulatory Agency (MHRA) ‘GXP’ Data Integrity Guidance and Definitions, Revision 1. March 2018. Available from https://www.gov.uk/government/publications/guidance-on-gxp-data-integrity.

24. Food and Drug Administration, US Department of Health and Human Services. General Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 2002. Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation.

25. European Commission Health and Consumers Directorate-general, EudraLex; The Rules Governing Medicinal Products in the European Union Volume 4: Annex 11: Computerised Systems (2011). Available from https://ec.europa.eu/health/documents/eudralex/vol-4_ga.

26. GAMP^® 5 A Risk-based Approach to Compliant GxP Computerized Systems. North Bethesda, MD: International Society for Pharmaceutical Engineering (ISPE). 2008.

27. Food and Drug Administration, US Department of Health and Human Services. Guidance for industry: Use of Electronic Health Record Data in Clinical Investigations. July 2018. Accessed September 17, 2020. Available from https://www.fda.gov/regulatory-information/search-fda-guidance-documents/use-electronic-health-record-data-clinical-investigations-guidance-industry.

28. Food and Drug Administration, US Department of Health and Human Services. Guidance for Industry: Electronic Source Data in Clinical Investigations. September 2013. Accessed August 8, 2018. Available from https://www.fda.gov/regulatory-information/search-fda-guidance-documents/electronic-source-data-clinical-investigations.

29. Food and Drug Administration, US Department of Health and Human Services. Investigational New Drug Application, General responsibilities of sponsors, 21 CFR §312.50 (2019). Available from https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=312.50.

30. Stead WW, Lin HS. National Research Council. Computational Technology for Effective Health Care: Immediate Steps and Strategic Directions. Washington, DC: The National Academies Press. 2009. DOI:  http://doi.org/10.17226/12572

31. Amatya S, Edgerton D. Vendor selection and management. Data Basics. 2020; 26(1).

32. Capterra Inc. Clinical Trial Management Software search website. Available from: https://www.capterra.com/clinical-trial-management-software/?utf8=%E2%9C%93&users=&feature%5B2%5D=31834&commit=Filter+Results&sort_options=. Accessed January 7, 2019.

33. McFadden ET, LoPresti F, Bailey LR, Clarke E, Wilkins PC. Approaches to data management. Control Clin Trials. 1995; 16: 3OS–65s. DOI:  http://doi.org/10.1016/0197-2456(94)00093-I

34. El Emam K, Jonker E, Sampson M, KrležaJeric K, Neisa A. The use of electronic data capture tools in clinical trials: web survey of 259 Canadian trials. J Med Internet Res. 2009; 11(1): e8. DOI:  http://doi.org/10.2196/jmir.1120

35. Franklin JD, Guidry A, Brinkley JF. A partnership approach for electronic data capture in small-scale clinical trials. J Biomed Inform. 2011; 44: S103–S108. DOI:  http://doi.org/10.1016/j.jbi.2011.05.008

36. Waife, RS. Transitioning clinical data management from the 1980s to the 2010s: Strategies for corporate decision making. Drug Inf J. 2001; 35: 713–719. DOI:  http://doi.org/10.1177/009286150103500309

37. Food and Drug Administration, US Department of Health and Human Services. Guidance for Industry: Computerized Systems Used in Clinical Investigations. May, 2007. Available from https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computerized-systems-used-clinical-investigations.

38. Spink C. Electronic Data Capture (EDC) as a means for e-clinical trial success, IBM Global Services (report BIWUK00002-2-0202-AP). Pharmaceutical Clinical Development. 2002; March.

39. Friedman CP, Wyatt JC. Evaluation Methods in Biomedical Informatics, Second Ed. New York: Springer Science Business Media, Inc.; 2006. DOI:  http://doi.org/10.1007/0-387-30677-3

40. Food and Drug Administration, US Department of Health and Human Services. Investigational New Drug Application, Transfer of obligations to a contract research organization, 21 CFR §312.52 (1997). Available from https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm.