Next-Generation Interactive Response Technologies (IRT): The Impact Of Modern Architecture On UX
By Ryan Ridge, VP, IRT Operations, YPrime
Modern software developments have transformed e-commerce applications, and many of the innovations that have been pioneered in other industries are likewise helping to improve the flexibility and scalability of eClinical technologies. One of these core technologies supporting the clinical trial space, Interactive Response Technology (IRT), is designed to help trial sponsors manage the distribution of medications, forecast trial supply, and integrate workflows with other technology platforms.
Typically, the purpose of IRT is twofold, functioning as both a clinical supply management technology and as a tool to enable optimized patient randomization. The IRT generates information based on patient data to inform trial logistics, whether related to the volume of drug substance that must be shipped to a repository or clinical site, or to determine which patients are set to receive a treatment and when. This contrasts with traditional trial supply management, which has historically been enacted by individual personnel assigned a set number of trial participants to manage manually. As clinical trials continue to grow in number and complexity, the value of an IRT for a given sponsor may compound, enabling fewer personnel needed to manage logistics while reducing the potential for error.
Within the larger framework of a trial’s management, IRTs are very niche. Yet their importance in the overall administration of a trial cannot be overlooked – an IRT, poorly calibrated for a trial design or logistical paradigm, can serve to invalidate a trial. Yet many of the IRTs employed across the clinical trial space today are largely unchanged from those introduced a decade or more ago, built around monolithic code bases and updated to introduce new functionality. This has the potential to create significant lift for vendors and sponsors, but new IRT models, built around discrete microservices, have emerged to address many of the challenges that exist for traditional IRT systems, which can likewise be better streamlined through improved vendor support.
The IRT Solutions of Today: Single-Tenant and Multi-Tenant Monolithic Architectures
The oldest and most widely employed model for delivering an IRT is a monolithic, single-tenant architecture wherein any new code forks from a pre-validated code base. In this scenario, both the IRT’s original code base and any subsequent additions exist in a single, interconnected repository, which can create issues when any part of the code is changed. This is because changes to one segment of the code have the potential to impact other parts of it, and identifying those regression impacts can require significant investment in risk assessment and retesting.
While customization can be performed on single-tenant IRTs, pulling that customized code back into the pre-validated code base can be difficult. Certain customizations may not be supported by the code base; in such cases, the pre-validated base and the new, forked code base function as two distinct sets of code. The result is customizations that are inconsistently implemented or implemented with heavy effort in order to achieve parity across IRTs. In a portfolio of 10 distinct IRTs, this means 10 slightly different versions of the same customization, and 10 separate risk-based evaluations. The chances of unintentional impacts to part of a system as a result of new customizations is likely in this paradigm; identifying those impacts is often a challenge that requires external expertise to adequately address.
Some IRT solutions are instead built around a multi-tenant monolithic code base, which incorporates any code updates within the existing code structure, foregoing the “forking” structure of a single-tenant solution. For these platforms, all changes are made on a product level, and as such, the majority of customizations are forced upgrades that must be made to an IRT regardless of whether it impacts a specific trial protocol. Because the code for these platforms lives in a single repository, the result is an increasingly large code base designed to meet the needs of every client and every new customization. This can, in turn, lead to an even greater probability of unintended regression impacts, as well as slower updates as developers work to ensure that new code doesn’t impact the broader IRT ecosystem.
There are benefits to the multi-tenant, monolithic approach: unlike in single-tenant systems, updates are more easily made backward compatible. Additionally, if functionality exists within the code base already, it can be rapidly introduced to a customer’s IRT. This is rare, however – often, how a project starts and how it ends are very different paradigms. As such, vendors managing multi-tenant monolithic systems will often need to make a product update to integrate customizations, particularly if those changes are going to impact a protocol amendment. This can be especially challenging for vendors with multiple competing priorities to manage. In contrast, single-tenant platforms allow for more agility on the project level, but can leave vendors behind on the broader portfolio level.
Modern Architecture: A Microservices Model Overview
While customization requests are often highly similar from client to client, there are almost always slight variations in individual requirements for a given protocol. This can make supporting multiple clients across their distinct IRT platforms a challenge. While the transition to IRT in the last decade or so has resulted in improved reporting and analytics, it has also necessitated significant buildout around testing, establishing realistic timelines, and creating a paradigm wherein vendors must carefully balance quality with the rate-limiting potential of increasingly cumbersome code bases.
Today, a more modern approach has emerged to supplant the monolithic code base systems that have previously dominated the IRT space. In a multi-tenant microservices IRT system, smaller, independent applications, connected via 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 which of those services they need for a given protocol. Those services are then integrated via API to provide a unified experience on the front end. As with the multi-tenant monolithic approach, the code exists in a single repository, limiting project-level customization; however, a microservices multi-tenant system allows for the rapid customization of a code base. This is because the segmentation inherent to those distinct microservices significantly limits the potential for unintended regression changes.
If a vendor is asked to make a change or upgrade to the randomization portion of an IRT, for example, they are able to limit the scope of that change and its concomitant regression evaluation to that single microservice. This enables a paradigm in which developers are able to execute changes more rapidly, as seen in single-tenant models, while achieving the backward compatibility and more limited regression impacts of a multi-tenant monolithic model. Because it is interconnected using API, a microservices model is also capable of more simplified integrations, made even more seamless by incorporating the right documentation, such as a well-defined software development kit (SDK).
Because a microservices model is a distributed system, there exists a layer where all data is housed securely, enabling users to scrape the database to create additional functionality, such as populating data within an executive dashboard. Likewise, if a client wants to be able to view reporting across all of its studies, the vendor can simply create a new report, as all of that data is already housed together. Such reports can be made as granular as needed – a client may, for example, want to view reports at the drug compound level. All of this results in the flexibility of the last-minute customizations possible for a single-tenant approach coupled with the functionality of a multi-tenant monolithic code system.
Pursuing a Better Approach to IRT User Experience
YPrime, a long-standing provider of technologies and services designed to streamline and optimize clinical trial management, has been working to establish and improve both its monolithic database and microservices models to better respond to the evolving needs of modern trials. One of its ongoing efforts has been to establish a “functionality library” for IRT similar to the questionnaire libraries that exist for many eCOA platforms. For example, if a client requests that its drug ordering work a certain way, YPrime may feature flag drug ordering to include this bespoke variation on that microservice. This way, if another client requires this approach, YPrime can, in its single-tenant model, access this library to turn on the correct feature.
For its modular microservices model, the sponsor’s ability to select the microservices relevant to their trial or trials allows them to achieve a right-sized IRT with only the necessary functionality. Although this provides streamlined delivery in terms of initial build, the current complexity of clinical trial management often means that vendors can only move as quickly as their clients. The true benefit of this modularity as it relates to speed is most often seen during change management in response to protocol amendments. This is also supported by the functionality library, which can greatly reduce timelines for mid-study changes by enabling very targeted configuration and validation. Even for functionality not present in the library, the more targeted, iterative approach promoted by a microservices model can support a faster, simpler deployment than its monolithic counterparts. Moreover, the much smaller functionality subset of a microservice allows for much more robust automated testing, greatly reducing the number of errors present in new code before it reaches the validation phase.
Ultimately, the microservices model provides faster initial builds, more rapid change management, and improved built-in test automation. It also improves data integration and access, giving sponsors the latitude to change their minds about which data is relevant and integrate new data and reports mid-study with ease. Moreover, because these data warehouses exist natively, integrating external data sources is greatly simplified. This all serves to create the potential for an improved user experience, as an IRT can be embedded in other systems, right-sized to simplify and streamline its functionality, and tweaked on the front end to create as seamless an interface as possible. Taken together, these advancements can result in an IRT primed for improved data speed and accuracy, reduced investigator burden, and optimized, centralized workflows.
