How Modern Software Architecture is Revolutionizing IRT Solutions
By Evan Hahn, senior vice president, IRT Solutions, YPrime
Prior to the advent of eClinical technologies designed to support study management, the manual processes involved in randomizing study participants were primarily conducted using paper envelopes. As clinical trials advanced in scope and complexity, sponsors began to adopt systems first introduced in the banking industry, employing interactive voice response (IVR) technologies to perform randomization and dispensation of investigational products. The introduction of IVR to clinical trials represented a significant leap forward. It was now possible to perform centralized randomization, better track compliance, manage IP more efficiently, and more.
Despite the advantages conferred by IVR, there were clear limitations to the technology. The effort necessary to build out these systems, which required customized coding for each study, often resulted in extensive, time-consuming development and testing. Furthermore, interacting with the system via a phone keyboard was not an optimal user experience for clinical sites. Because of the innate challenges of a customized phone-based system, the industry shifted to web solutions. This represented the second major shift in RTSM approaches, brought to bear by changes in the underlying technology.
While the first generation of interactive web response (IWR) technologies offered users a more streamlined experience, they were effectively IVR brought to the web. Studies still required high levels of customized programming, with the long lead times and the risks inherent to that approach. Additionally, although IWRs were better suited to integration with other related technologies, pursuing these was still difficult, and often relegated to older technologies such as file transfer platforms (FTPs) and batch transfer.
In response to these challenges, a third shift in the space occurred with new solutions developed under a new paradigm that disrupted the status quo, which was again made possible by advances in broader software technology. These advances allowed for IRT solutions to be based on configurable modules for common functionality, augmented by custom programming to meet the requirements of individual studies (perhaps best explained as “modular IWR”). This represented another significant leap forward from earlier generations of IRT, due largely to the reduction in custom coding required for each study. Pharmaceutical companies quickly saw the benefits conveyed by these new technologies and pivoted toward these systems en masse.
Since their introduction, these systems have undergone some incremental improvements, with most investment geared toward building up core code bases to incrementally introduce features such as direct-to-patient shipments and improved dashboarding. However, the foundational architecture on which these systems have been built has remained unchanged, and over time has become a barrier to innovation.
This can be attributed to a few factors. Almost all are derived from a monolithic code base, which by its nature is highly , incorporating any code updates within an existing code structure, in contrast to the “forking” structure of a single-tenant solution. The impact of this approach is that it is very costly and time consuming to implement new functionality. This requires customization to be done at the study level – it would simply take too long add the functionality to the base code. Furthermore, while there have been significant advances in software architecture over the last 10 years, IRT solutions have not taken advantage of these new approaches – leaving them unable to make foundational improvements to the systems.
While the underlying, fundamental technology approaches supporting IRT systems have remained unchanged for more than 10 years, complexity for both studies and therapeutics has increased. In particular, the frequency of study amendments continues to grow, often requiring several weeks to implement during a live study. To better meet these challenges, solution providers need to invest in new IRTs built on modern technology. An approach that is currently being deployed successfully in other industries is microservices. This model is capable of improving data access and visibility, enabling better integration across other eClinical platforms, reducing the burden of user testing, and, ultimately, reducing the potential for risk. Furthermore, a microservices approach is designed to scale for future needs, both anticipated and yet unknown.
The Pitfalls of Monolithic Code Bases for IRTs
Trial complexity and the costs associated with investigational product continues to advance significantly. In just five years, the share of new drug approvals classed as small molecules dropped more than 10 percent, from 71 percent in 2018 to 59 percent in 2022, owing to an increase in research for advanced therapeutic modalities. This inversion has been largely driven by a more widespread understanding of the underlying molecular and genetic causes of disease, spurring research into the large molecules that may offer more targeted treatments for more intractable diseases.
Many more treatments in the modern development pipeline are biologics or cell and gene therapies. Because of this, approaches that were once acceptable for clinical trial management, such as ending up with more drug than is needed for a participant population, have become infeasible. Likewise, the highly individualized nature of certain drugs, such as autologous cell therapies, makes managing drug distribution a more crucial and complex endeavor than ever before. An example is in the cell and gene space, where distribution of personalized medicine studies (such as cell and gene therapies) can be challenging for even existing IRT systems to handle, as they do not follow the typical flow of depot to site to patient.
Enabling this kind of flexibility for a typical IRT would likely prove highly constraining, as adding to the repository of a monolithic code base has the potential to introduce risk and complexity by inadvertently impacting other areas of the code. For monolithic, single-tenant architectures, any new code forks from a pre-validated code base; in the case of multi-tenant monolithic architectures, any code updates are made within the existing code structure, foregoing the “forking” structure of a single-tenant solution. Single-tenant monolithic solutions suffer from issues caused by trying to pull new code back into the base, creating the potential for regression impacts and for inconsistent or difficult implementation of customizations across an IRT portfolio. For multi-tenant monolithic solutions, because all changes are made on a product level, the majority of customizations are forced upgrades that must be made to an IRT regardless of whether it impacts a specific trial protocol.
Enabling Transformational Improvements through Microservices Models
As a technology, existing IRTs built around the approaches that spawned modular IWRs have likely reached their ceiling in terms of new innovation. They are also likely to become increasingly risky for the organizations that retain them. Trials are becoming more complex and are undergoing more mid-study changes than ever before, relying on architectures that take significant time and testing to adapt, creating untenable inefficiencies in a landscape driven by speed-to-market. While mid-study changes are good for the science of clinical development, they can present a significant challenge to traditional IRTs. In the end, if a sponsor is forced to limit a trial’s scope in some respect due to the limitations of its supporting technologies, that technology has created an unacceptable threshold for risk.
With a few exceptions (DtP support, improved reporting), the industry has seen limited improvements to IRTs in recent years. This can be attributed to more than the typical risk aversion that pervades the industry – the underlying technology serves as a limitation to introducing transformational improvements. While other industries have moved to more modern platforms for their software solutions, the IRT space is largely comprised of tools built with a monolithic code base. This increases the level of effort that must be repeated between studies seeking the same customization as integrating them reliably within the larger base cannot be accomplished in the time frames needed for a study to launch.
In a microservices model, smaller independent applications are connected via APIs.
In contrast, a microservices model is intended to handle scaling while reducing . It enables faster introduction of new functionality without risking meaningful impacts to other functionality. This is because for these systems, smaller, independent applications, connected via application programming interfaces (APIs), are overlayed with a user interface and without the need for interconnecting code. For these IRTs, each service lives separately, allowing users to pick and choose services that are then integrated via API to provide a unified experience on the front end. Functionality for one of these microservices can be made available to other studies moving forward, and the smaller, discrete code bases for each microservice serve to vastly simplify UAT when new functionality is introduced. As a result, an IRT can achieve a platform for which all of its functionality is pre-validated and available via configuration. And if a study requires functionality not currently available via configuration, it can be added as pre-validated functionality within the timelines of a normal study build – completely removing study specific coding and validation.
Saving Time, Reducing Risk, and Accelerating Innovation: A New Model for IRT
Another key advantage of the microservices model is its improved capacity for integrating with other eClinical platforms. Because microservices are natively connected by APIs, any part of the system can seamlessly exchange data bi-directionally to a variety of other technologies, including data lakes, temperature monitoring solutions and analytics tools, more easily than current IRT solutions. The highly segmented structure of microservices also enables “right-sizing” of a sponsor’s IRT, eliminating any superfluous functionality and simplifying the user experience, which can be critical for a space plagued by study sites struggling with overly complicated technologies. This type of model could also introduce the potential for “headless architecture,” enabling users to take a microservice and push it into a different front-end system, such as electronic data capture (EDC).
Because all the system functionality is available as pre-validated configuration, study builds can be reduced to as low as 1-2 weeks. But perhaps more importantly, mid-study changes which can often take several weeks or months to implement, can be reduced to just days. This is extremely important, as any delay in study conduct slows the time to market for novel treatments.
Microservices do not just present immediate benefits for running clinical trials. The architecture is by design meant to handle scaling and potential uncertainties that will come. One known example is GS1 standards. The database structure of existing IRT solutions are not well equipped to handle these standards (and are likely part of the reason that they have not been widely adopted). However, the normalized structured database of a microservices-built IRT is meant to handle standardization. This could also apply to other areas such as AI (Artificial Intelligence)-driven forecasting, blockchain, or any other application that requires normalized data.
Microservices models have seen widespread adoption across the broader tech industry as they are simply more suited to the demands of modern software. Faster development, seamless and secure integrations, accessible data, and scalability are all advantages from this architecture. For the clinical trial industry to reap similar benefits, sponsors and technology suppliers must agree to undertake a paradigmatic shift toward a new architecture, one that can support the innovations likely to transpire in the coming years. Pioneering more standardized, configurable IRT systems with the flexibility necessary to turn functionality on and off, adding new functionality without creating undue risk, and making data more secure and accessible are the keys to ensuring the IRTs are positioned to adapt alongside emerging technologies and evolving trial protocols.
