Smart Database Design at the Center of Accelerated Trial Times

There is a lot of talk about accelerating trial times, and how to deal with missed timelines and delayed milestones, a concern shared by all stakeholders in clinical trials. Many, in the end costly, issues that keep coming up again and again could be avoided from the onset by paying more attention to the importance of solid database design.

In many ways the quality of database design influences not only study timelines and data quality, but the outcome, even the ultimate relevance of clinical trials. While database design is often pushed to the sidelines in the quest for moving a trial along as quickly as possible, it is crucial to remember the importance of great database design as a critical basic building block.

Naturally, sponsors want to start clinical studies quickly, want their first subject visit as soon as possible and need the database to be ready at the earliest date. Having the database up and running as fast as possible allows sponsors more time to prepare sites and ensures that their study does not run into delays from the onset, and can start at the desired date. It is in fact achievable to finalize quality database design within four to five weeks, significantly accelerating trials, resulting in big savings of sponsors’ time and financial resources.

To a large part, accelerated trial times stand and fall with the quality of Clinical Trial Data Management. It is essential to remember that if done well, Clinical Trial Data Management is so much more than simply collecting data electronically, cleaning it to match the source document, and sending it off to the next department. “Done well” means not losing track of why things are being done the way they should be done. “Done well” means to take a step back in order to take a look at the larger picture, and understanding the integral part database design plays at the center of outstanding Clinical Trial Data Management.

Outstanding Clinical Trial Data Management starts with database design, right from the beginning. A thorough understanding of the study protocol is the basis, the complete study team must have all their questions clarified and understand the purpose of the study. They must consult with all other involved departments to ensure that everyone is on the same page, and the system captures the data it needs to.

The database should then be designed with a focus on making the job of the “next person” easier. Who will be the “next person” using the database? Issues and delays usually arise if departments work in isolation, or the reality in the clinic, at the site, is different from anticipated.

It starts with site staff and data entry staff, who should find it easy to collect data and enter it into the database. The database should be as user-friendly as possible, with all related data on the same page, for example. Built-in edit checks should prevent a host of potential data entry errors, again aiding in the acceleration of trial times.

During the last few years, eSource has moved into the spotlight, and is fast becoming the most valuable tool for data collection and accelerating trial times due to skipping the entire data transcription process. It is a great development, improving both data quality and accuracy, as well as increasing speed of data collection while at the same time decreasing error rates with the help of in-app logic checks. It should be kept in mind though that eSource is only as good as the underlying database design. If the database design behind the scenes is flawed, even the most up-to-date eSource technology will produce flawed results.

Data collection and entry is followed by data review, which should again start with checking if the study purpose is being achieved. What are the data trends, what is the meaning behind the data collected, and how is the data quality? To prevent delays down the road, any noted irregularities should be addressed at the earliest possible, at the database design level, before large amounts of data are either collected or entered incorrectly. Query management should not wait until for example 25 – 30% of the data has been collected, but start immediately, by working closely with the site.

Another “next person” is the STDM programmer involved in the clinical trial. Smart database design should produce STDM-friendly raw data, since according to FDA standards all raw data, no matter what Electronic Data Capture system (EDC system) was used, must be mapped under Study Data Tabulation Model standards (SDTM standards).

Problems with database design should not be ignored and simply passed on to the STDM programmer. All data should be captured in a way that will ultimately save the STDM programmer time. Once again, accelerated trial times start with solid database design. One example would be setting up the case report form in grid format (if allowed by the EDC system). It is a small thing if done during the database design process, but will allow data to be exported as normalized data, ultimately adding a lot of value to the outcome.

Accelerated trial times rely to a large part on smart database design. The Clinical Trial Data Management group/EDC programmer should take pride in the fact that smart database design is one of the core building blocks of a successful clinical study. A CRO’s goal of handing over a quality clinical study to the sponsor in a timely manner, from data capture in the clinic to delivery of the final data package, rests heavily on the DM team’s ability to achieve quality database design.

Muhammad Bilal
Senior Director, Clinical Data Operation
BioPharma Services Inc.