Buzzwords like “analytics” and “visualization” have been used in the clinical trial space since the ability to collect massive quantities of clinical trial data became a reality. Everyone wants the instant gratification of real-time trend detection, and software developers have responded in kind by providing a dizzying array of analytics options. How do you make an informed decision about which option is the right fit?
The roots of analytic software in the pharmaceutical industry lie in pre-clinical development for big data problems, such as genomic data processing, analyzing cell lines, and synthesizing data from natural history studies. However, these “advanced analytics,” aren’t a neat fit for clinicians’ needs. Even the largest phase 3 clinical trials do not collect anywhere near the amount or scale of data that advanced analytics are designed to handle. Clinicians want software that will output graphs and other visuals to enable patient care, but advanced analytics software output raw data that need to be processed to produce graphics. That’s where “descriptive analytics” come in handy. Generally speaking, this class of platform is distinct from advanced analytics in that they prioritize generating user-friendly graphics over analyzing vast amounts of data. The users of descriptive analytics software are overwhelmingly clinicians who care far more about quickly assessing patient safety than about detailed data information, so ease of use and clarity of information are paramount.
The ideal analytics software for clinical trials would be a tool for both data visualization and risk-based quality management (RBQM). Identifying risks that emerge through the course of a study is difficult given traditional methods. Analytics can step in here, to detect suspicious trends in data that may merit monitoring, such as a country, or even an individual site, with a higher than normal rate of adverse events. However, while there is a need for data visualization and risk based monitoring, it is rare to find one analytics service that does both comprehensively. Software that performs both services is usually designed with only one of those objectives in mind, with the result that one function will be more robust than the other. Organizations should be prepared to make compromises when considering what data descriptives are necessary and should prioritize the search for solutions that are “just right.”
