Obviously, we are in the third decade of the eClinical revolution in clinical trials, driven by pivotal technologies such as electronic data capture (EDC) software, which first began to gain traction in the 1990s. While there have been some bumps in the road along the way, particularly in the use of EDCs for Phase I trials and in emerging markets, EDC systems have gradually become mainstays of clinical research and drug development. Between half and three-fourths of all clinical trials in 2017 incorporated EDC tools.
Beyond EDCs, other eClinical solutions have become popular, too, including systems for tracking labs and safety, coding clinical data, and managing trial sites. Additional innovations such as big data, AI, and machine learning are on the horizon as well. They may have the potential to reshape clinical trial development.
Understanding the Data Challenges in eClinical Environments
The industry’s ongoing technological evolution shouldn’t be mistaken for the elimination of all of its age-old challenges.
The unification of data from various eClinical systems is still a titanic challenge. That’s despite the clear benefits (e.g., improved safety detection, faster time to submission, etc.) when clinical development teams have full visibility into in-stream data. Moreover, operations managers and other personnel still struggle to access the data they need, in many cases having to wait months for complex data repositories to be fully scoped before they can begin harnessing the power of analytics.
More than 30 years into the eClinical revolution, why do these types of problems remain so prevalent? One recent survey provided some insight: 41% of respondents reported that data aggregation was their biggest single obstacle related to analytics, and one that complicated the transition to cloud-based applications. But why are they struggling with aggregation?
Digging a bit deeper, we have noticed that customers consistently identify two big reasons for their difficulties:
- Source systems aren’t built for analytics
The EDC system, where subject data lives, is the inevitable focal point whenever your team seeks to investigate potential safety signals or check if clinical research associates are making good use of their on-site time. In truth, though, EDCs were not designed with such use cases in mind.
EDC solutions were built for secure, accurate, and efficient data capture. However, they don’t always work so well for analytics-related purposes, despite being a good fit on paper:
- For starters, in-stream data from EDCs isn’t initially standardized, and its forced standardization often doesn’t happen until near the very end of the trial. Until then, teams work with a variety of configurations across electronic case report forms (eCRFs). No standardization means analytics can’t be readily applied.
- Data points are also not optimized for use in analytics engines. That is, eCRFs are intended basically as simple electronic equivalents of paper CRFs. They’re convenient for site teams capturing protocol-specific endpoints, but less useful for gathering data that might enhance workflows like in-stream safety review.
- Data projects don’t prioritize the needs of individual users
Not all data is created equal. Clinical information is only useful insofar as it fits into a specific context and meets the requirements of its user(s). Making it valuable for individuals in particular roles usually requires standardization and the use of high-quality sources.
For example, if someone needs to set up risk-based monitoring, then they will have to have real visibility into what is happening at the targeted sites. That ranges from subject recruiting to supply chain oversight. Getting that visibility could necessitate data aggregation from many source systems and vendors, especially if the person is at a contract research organization. On the other hand, if they’re only reviewing data for safety purposes, EDC and lab data could be sufficient. In that case, data standardization efforts may be focused just on those specific systems. In other instances, the scope will naturally be wider.
The problem with such vast data aggregation projects is that they typically have to serve a large set of stakeholders, sometimes with divergent needs. Immense effort gets channeled into so much pulling, mapping, storing, and distributing data. Before long, the needs of any given user can easily get lost in the whirl of trying to render all the information usable.
It’s the classic problem of not being able to please all of the people all the time. The resulting analytics might meet some of the requirements of some users, but not all of the needs of any single one. Accordingly, change management becomes more challenging and analytics end up not being all that practical in everyday workflows.
How to Make Data Aggregation Less Painful
Data aggregation doesn’t have to be an ordeal. Here are two pathways for making it easier.
- Remember what your data is really for
Don’t try to meet all of your present and future analytics needs with one generic solution - such a platform doesn’t exist. Looking for it will only waste precious time and compound current problems. Instead, get as granular as you can and determine what is required for achieving the specific visibility you require.
Figure out the clinical questions you need to answer, the teams you’ll need to work with, and the data sources that might be of the highest utility. Remember that although it’s crucial to ultimately find a solution that’s powerful and feature-rich, it’s ok to start simple and expand as needed.
- Make the most of the data You have
What if you can’t find answers to your questions in your source data, for example when trying to set up risk-based monitoring? This is often due to source systems not being designed for collecting the right types of data for assessing risk.
In this case, it may be prudent to begin risk assessment based on data originally collected for different purposes, with the goal of quantifying and demonstrating the benefits of data analytics processes. Establishing a culture of analytics won’t happen overnight, but it can be furthered by such actions, which can cut time from query closures and database locks.
Read more here on data aggregation in clinical development.