Shopping for an EDC platform can be an overwhelming assignment. There is a desire for high-end functionality, but not always the budget in place for high-end systems. Often, there is organizational inertia just to work with market leaders despite the difficulties of working with larger organizations. Over the next series of blogs, we will examine multiple strategies that make the procedure less confounding and more beneficial to your organization.
Phase 1: Complete an Internal Requirements Definition Process
You’ve chosen to implement an Electronic Data Capture (EDC) platform for your next clinical trial. This may have been an easy decision because you may already use an EDC application or you may simply rely on whatever electronic data management system your CRO uses. Other times companies are tempted to use the most popular systems. All of these approaches may result in a suitable system for your team, but not necessarily the optimal solution. However, neither of these approaches can be classified as a formal selection process and may lead to high dissatisfaction. Given that the data collected during your clinical trial is critical to demonstrating safety and efficacy, much more thought should be directed toward the selection of the software.
EDC selection, like other clinical technology selection, needs to really begin with requirements. The FDA requires a fully-validated system for the collection of clinical trial data. Validation presumes that you test your selected system against your pre-defined user requirements. And yes, by “pre-defined”, it means creating your list of requirements for an Electronic Data Management System before you look at existing EDC systems. Many sponsors or CROs will look at available EDC systems, participate in demonstrations and then create their requirements list based on those demonstrations. This, in essence, puts the selection ahead of the definition of need. The value of defining your requirements first is that you capture the functionality and features your company most needs. However, requirements definition is rarely conducted in advance. The most common detraction for defining your requirements ahead of time is the fear that all systems would be excluded. After all, could there really be an EDC system that meets all of your requirements? However, if you properly score the systems under evaluation, (see item 3) you will be able to identify the system that is a best fit for the organization, even though it may not meet all your requirements.
In building your requirements document, it is useful to understand primary functional areas where requirements should be built. Core functionality like data-entry, monitoring, querying and data exports becomes a laborious effort of evaluating your internal processes – but it needs to be done. It may provide some comfort to consider that a requirements definition document can be amended. That is, you can add to it as your experience with EDC grows. For those starting from scratch, one recommendation for addressing EDC requirements is requesting a list from EDC vendors. They will often provide requirement templates or RFP templates. You do have to exercise some caution though. Each vendor will build that list with a bias toward their product, so be sure to request lists from multiple vendors. Leverage the wording and the scope as the basis of your requirements document, and always enhance with how your company works in each area. The result should be bias-free and provide maximum coverage of functionality. But EDC is far along on the adoption curve, and technology is ever-evolving. You should expect more productivity features increasing the value you get out of a selected system. Here is a summary of major requirements categories:
Core Functionality: Speak with your clinical team regarding the features that they are expecting. EDC is no longer just about electronic data management. It is becoming more. Monitors are looking for features that streamline their work activity and support risk-based monitoring initiatives. Investigators are seeking easy access, patient profiling and patient engagement. Site coordinators appreciate streamlined entry features and aggregated query response capabilities. Don’t forget the SAS team and analytics downstream, the extract and data formatting capabilities are also quite important.
Integration: Clinical data is derived from many sources in addition to EDC. These sources include Patient Reported Outcome devices, laboratories, Interactive Response Technologies (IRT) or Clinical Trial Management Systems (CTMS). Collecting and cleaning the data correctly and quickly is critical to success of your trial, but often includes details from these other systems. Can the system that you are considering integrate easily? Is it using modern integration technology? If so, then the vendor should be able to provide published integration protocols and services that so that you may review and assess the ability to integrate with other systems that are currently used.
Work-flow: Consider the business processes your team has to follow for the handling of the data. Can the Electronic Data Capture system you are considering address these? Common tasks, like reviewing of the data, are difficult to enforce because the system does not track activity of users that are not relevant to changes in the data. Sites are overburdened with queries because the system does not give other clues for incomplete data. Monitors have maximized the efficiency on site visits and trip reports, because there are no productivity tools to help them streamline their tasks, like source data verification. Simple improvements like mapping to your clinical processes can help shorten the time each of these tasks take. These types of improvements will reduce cost, time and will help end users rave about your EDC.
Mobile capabilities: Data is moving quickly to the cloud, where it is aggregated and analyzed the quickest. This means that the members of the clinical team are expected to respond expeditiously to the events taking place within the trial. This drives many of us to access our clinical technology with mobile devices. Each day the percentage of engagement of clinical systems on mobile devices increases. It is no longer a matter of convenience, but also a way to engage with members of the research team and even patients. Mobile devices are providing the methodology for collecting data real time, enforcing protocol compliance, cleaning data faster and collecting data faster. Develop requirements that will reflect your organization’s position on mobile devices. Consider the different levels of engagement the software may have with these devices which may range from being viewable on such devices to a tool kit of apps that take full advantage of the capabilities of mobile devices.
Reporting: Reporting in EDC is no longer about data listings, it’s about information. Information gained from trending, portfolio profiles, patient insights, patient adherence and site productivity. The multiple data entry over time that can develop identification of key risk indicators (KRIs) or root causes for screen failures or withdrawals. Sponsors should expect alerts on enrollment issues that allow site and sponsor personnel to respond expeditiously to retain patients in the study. Data managers should be able to identify issues with data entry and safety. All this should be graphical presentations that make it easy to visualize what is happening in the study.
Developing requirements in each of these categories can be exhausting. The benefit is promoting the dialogue internally on how best to leverage the clinical technology. But it is more than just a good idea. It’s also part of regulatory compliance. Next week, we will examine compliance needs for an EDC system.
