Proactive planning and cross-functional collaboration help streamline the design and build of an efficient, effective clinical trial data collection platform. Electronic data capture (EDC) systems are essential technologies for collecting, storing, and analyzing patient data in clinical trials. Building an EDC system is a shared responsibility among multiple stakeholders—including the sponsor, CRO, software vendor, project management, clinical, clinical science analytics & insights, medical monitors, safety, and biostatisticians—making timely go-live a team effort. Though it may seem complex, EDC go-live is a sequential process that, if followed, can avoid costly delays.
In our experience, sponsors may not always consider the myriad factors that drive the build of their EDC. In this article, we provide insight into the key aspects of EDC design and build to help sponsors gain clarity around the steps involved to help them optimize their workflows.
Factors That Drive EDC Timelines
EDC builds follow a disciplined process that begins with the execution of a sponsor work order and ends with EDC go-live. Once the sponsor work order has been executed and the sales order with the EDC vendor has been finalized, the database build can begin.
A critical consideration in the EDC timeline is the status of the protocol. Ideally, the protocol has been finalized. If the protocol is stable but not yet final, this introduces potential risk to both the timeline and the bottom line due to costly rework. Electronic case report form (eCRF) development can begin but is subject to re-work and multiple rounds of review if the protocol changes. Proactively factoring in time for future feedback and eCRF specification finalization in anticipation of changes is helpful for managing expectations and staying on track.
You play an important role in keeping clinical trial EDC timelines on .
The EDC build involves a number of well-defined development phases, each of which can be rate-limiting without intelligent planning. By understanding the detailed timeline requirements, providing timely feedback, and collaborating openly with the partner CRO, expected database open dates can be met more confidently.
Defining the eCRF design specifications: Ensuring the eCRF design specification process is well-understood by all stakeholders before starting this process helps maintain focus on content and analysis. Keeping the system simple yet flexible and designing it with all users in mind helps ensure ease of use and a seamless workflow, both of which contribute to reducing entry errors and enhancing data quality. At Precision for Medicine, we adhere to pre-approved and reviewed design specifications rules, which reduce extraneous effort and timeline crunches. In this phase, it is important to check that decision-makers from each functional group responsible for eCRF can commit to review periods and attend review meetings. With each successive review meeting, there should be fewer comments and change requests, streamlining finalization of the eCRF design specifications.
Aligning on database configuration specs: Determining the key elements of a database up-front can have a positive waterfall effect on the rest of the process. Elements such as subject numbering conventions, site numbering, and medical coding dictionary versions are important structural elements of a database. Altering these configurations in late-stage development can have costly downstream implications and may delay go-live.
Programming the eCRF: Once all stakeholders have signed off on the eCRF design specifications, screen programming can begin. The better the specifications are, the better the programming will be. If the forms are stable, some programming can be done in parallel, but there is inherent risk in working in a non-linear fashion. A common pitfall involves trying to shave down timelines by cutting corners or skipping steps in the programming protocols.
Establishing edit check specifications: Edit checks are automated, auditable processes for assessing the content of a data field against its expected properties to reduce the likelihood of errors in data entry. Establishing the specifications for edit checks should begin only when the eCRFs are stable and fully programmed.
Programming edit checks: Once the edit check specifications are finalized, programming of the edit checks can start. The approved specifications drive what will be built in the EDC for go-live. While changes are expected and should be built into the overall timeline, substantive changes will impact the go-live date.
Performing user acceptance testing (UAT): The length of time that should be allotted to this phase of the EDC build will depend on the level and intensity of the sponsor’s UAT process. Each EDC platform has its nuances, and each build is unique. Consequently, it is important to understand the sponsor’s and the team’s experience with the platform to support efficient UAT. In our experience, it is useful to have each team member take the EDC eLearning as a prerequisite, so they understand how to navigate the system and perform data entry prior to UAT.
Integrating the interactive response technology (IRT) system: Sponsors often ask if IRT can go live in advance of EDC. The answer to this question depends on what pieces of the EDC platform are needed to build out the IRT system and which fields will be integrated. At Precision for Medicine, we recommend limiting integrated fields to only those that add discrete value.
We generally advise against integrated data from external vendors, like safety lab data or other biomarker data.
These integrations require substantial effort and rigorous validation, which competes with—and distracts from—focused EDC go-live efforts and may create unnecessary data redundancy. Rather than trying to pull disparate data sources into an EDC system, sponsors may want to consider purpose-built data aggregation platforms such as QuartzBio® that are specifically designed for multiomics data integration and interrogation.
See the importance of timely approvals for an on-time go-live of your EDC.
Follow up: If this is to be a header, recommend adding line space after the image and before the header, and using initial caps, no end punctuation.
Key Takeaway for and Effective EDC Go Live
Ultimately, the goal of an EDC build is to create a clean, simple, efficient, straightforward database that can be analyzed. Intelligent planning and intentional multi-stakeholder commitment are fundamental to successfully meeting the EDC go-live timeline without sacrificing quality. Having well-thought-out specification blueprints helps sponsors, software developers, and CROs proactively plan and execute the design, build, and launch of an EDC system. In addition, developing collaborative partnerships and adhering to review and timeline commitments across extended teams helps streamline the process and ensure the quality and usability of the final product.
At Precision for Medicine, we have extensive experience working with sponsors on designing and building EDC systems, either as a full-service clinical trial solutions provider or a functional service provider. To learn more about our clinical data management services and our EDC experience, click here.
About the Author
Michelle Martell is an Executive Director of Data Management with over 20 years of data management experience, having worked in both the CRO and pharmaceutical company space. A Certified Clinical Data Manager (CCDM), Michelle excels as an outside-the-box thinker who emphasizes quality and good clinical practice, while respecting client needs, budget, and timeline considerations. With proven success as a study leader, Michelle also contributes regularly to the technical aspects of the job, including database builds and programing from study start up to database lock. She has successfully managed multiple studies across several therapeutic areas and deployed a number of clinical data management systems.