Clinical technology solutions that support Interactive Response Technology (IRT, or IVR, IWR, RTSM) have been in use for over 25 years and are now a ubiquitous feature of the e-clinical toolkit in full development studies. In fact, the e-clinical solution software market, valued at $3 billion in 2014, is expected to grow at a CAGR of 13.8% from 2014 to 2020 to reach an estimated value of $6.52 billion in 2020[i]
Technology platforms have evolved with the market, focusing on functional re-usability, standardization and quality on the one hand and decreased cost and implementation timelines on the other. This e-clinical domain has seen a gradual shift toward solutions that are configured rather than individually programmed on a study by study basis, with Software-as-a-Service (SaaS) based offerings growing at five times the standard application market.[ii] This evolution presents a number of crucial business challenges. The IRT solutions need to support complex, business critical functionality while emphasizing quality and integrity as the foremost concerns of end users and consumers of the technology.
In contrast to most e-clinical software, the IRT application exists in a fluid environment managing highly sensitive-blinded data for a system that has direct patient impact, complex country drug packaging requirements and ever-evolving randomization and trial designs. In addition to complex functional requirements, IRT occupies a unique position in the e-clinical ecosystem, as a set of solutions with multiple masters and stakeholders who inevitably demand a diverse variety of functional requirements from any technology platform. Magnified by subtle variations between sponsors, therapeutic areas and individual protocol designs, the question begs, what is the best software architecture for an IRT application?
By definition a Single Tenant software application consists of an architectural setup in which a single client has a copied instance of the software application. Each tenant is a versioned copy of the application’s main code base and all customizations occur via data-driven configurations, customizations via Application Programming Interfaces (API), or programmatic intervention. All tenants are loosely coupled with the CORE application and individual customizations outside of the APIs and configuration can occur on the single tenant.
By definition a Single Instance Multi-Tenant (SIMT) software application consists of an architectural setup in which multiple clients share a single instance of the software application. The ‘Single Instance’ contains the application’s main code base and all tenants consist of a data-driven configuration or customizations via Application Programming Interfaces (API). In this setup, all tenants are tightly coupled with the CORE application and any customization outside of the APIs and configuration requires updates to the core instance.
While there are known benefits to this architectural design such as cost-savings, release management, reporting and feature sharing, we continue to ask if this is the right design for an IRT application.
In contrast to the obvious benefits of Multi-Tenancy, there are a number of questions that come to mind while thinking about this software structure in a highly diverse, regulated e-clinical environment.
How can I rapidly introduce features for my upcoming protocol?
Multi-Tenancy architecture limits the ability to rapidly customize the application on a per-trial basis. “…you can’t simply write custom code to customize the end-user experience—anything you do to customize the application for one customer will change the application for other customers as well. Instead of customizing the application in the traditional sense, then, each customer uses metadata to configure the way the application appears and behaves for its users.”[iii]
If the functional requirements are outside the scope of the metadata, the core product does not have the necessary ability to configure the trial within the confines of the validated instance and the sponsor is at an impasse with the vendor. The customization will need to go into a product backlog and be integrated with the shared instance. Once the feature is developed, integrated, and validated then it will be deployed and available for use for all tenants tied to the system.
In contrast, a configurable Single-Tenancy architecture application allows for the ability to introduce customized functionality to meet the needs of the specific trial. The feature is developed and validated on the single tenant and does not need to compete with other sponsor’s needs and priorities. Once the feature is developed, it can be integrated into the core product or customized on other tenant systems as needed.
How can I guarantee that the feature set is right for my company?
Based on each sponsor’s IRT use case, the SIMT architecture may not be best suited for sponsors or CROs. A sponsor must fully understand the limitations and constraints of the core application and ensure that the protocol design fits neatly within the vendor’s available customizations. If protocol amendments are instituted during the design or maintenance phase that fall outside the scope of the product’s feature set, the sponsor may be exposed and the protocol in jeopardy. This process may prove difficult, requiring commitments such as:
Flexible requirements and mid-stream changes naturally lend themselves to Single-Tenancy software architecture. This Single-Tenant may become a set of sponsor specific standards, and then becomes the customized base for all subsequent builds. This trend of sponsor specific Template IRT Systems is in direct opposition to an architecture promoting Multi-Tenancy. A software architecture that allows for the branching, customization and validation of a template system, while also maintaining the ability to assume a desired feature set from the core-single instance may be most suited for sponsors.
How can I guarantee that ‘instance upgrades’ do not impact my validated state?
There are a number of questions that a software vendor and clinical sponsor must consider when introducing upgrades and new features in a Multi-Tenant architecture, such as:
According to GAMP5, documentation, procedures, records and process must be in place to maintain a validated state of the software.[iv] Any change to the application in a SIMT model could potentially impact the individual tenants, regardless of the upgrade, enhancement, or fix is pertinent to your software configuration. This may unknowingly and inadvertently introduce defects across all systems associated with the shared instance. Regardless of the quality of software development, automated testing and risk mitigation, once a software application is validated and in-use with production data limiting the number of updates and enhancements, the qualified application is of the utmost importance.
What is the best model for my company?
In order to gain all of the benefits of a Multi-Tenant application, without incurring the risk and lack of flexibility, a highly structured Single-Tenant approach can yield positive results within the industry. Having a well-managed Core Instance that can be propagated, configured and customized at different levels allows for rapid agile development on a sponsor level without the need for long product development timelines and turn around.
The Core Instance consists of all features incorporated into the base product cross sponsor. This concept parallels to the single instance, however, is not tied to individual tenants. The core application is developed, validated, versioned and maintained in an isolated fashion. The Tenant is a cloned version of the CORE system and can be customized and configured from sponsor specific (sponsor instance) needs without impacting the CORE application or other applications. The Protocol is a single instance of the customized or CORE application that can be further configured to meet the timelines and needs of individual protocols. Each entity exists on its own development and validation cycle so it can be readily extended and managed without impacting other systems. The product functionality at each level is modularized for portability across instances.
There are different types of software architecture that can be utilized while creating and customizing an IRT application. Both Single-Tenant and Multi-Tenant applications have benefits and restrictions. For Multi-Tenant applications, in order for enterprise adoption to occur, the sponsor must be confident that their protocol designs can fit within the confines of the configurable application and that their processes are in place to handle deviations. Additionally, a sponsor may have to tailor their external software applications and infrastructure to be compatible with the Multi-Tenant’s existing functionality. The sponsor must also understand the SIMT architecture in order to maintain quality and compliance on all trials.
Underlying business workflows supported by IRT solutions are trending towards greater standardization. This trend is significant as IRT solutions evolve towards supporting an ever increasing breadth of functional requirements. Until this alignment is fully realized, a well-managed single-instance application may be desirable for sponsors. With the correct processes, controls and development standards in-place, a hybrid approach leveraging robust configurations and sponsor specific customizations may be the most effective IRT solution.
[i] Transparency Market Research (TMR), E-Clinical Solution Software Market- Global Industry Analysis, Size, Share, Growth, Trends and Forecast, 2014 – 2020, http://www.transparencymarketresearch.com/e-clinical-solution-software-market.html (July 21, 2014)
[ii] OptifiNow Enterprise Sales Entertainment Solutions, SaaS in the Pharmaceutical Industry, http://blog.optifinow.com/thought-leadership/saas-in-the-pharmaceutical-industry/ (October, 2013).
[iii] Microsoft Developer Network (MSDN), Architecture Strategies for Catching the Long Trail, https://msdn.microsoft.com/en-us/library/aa479069.aspx (April, 2006).
[iv]GAMP, GAMP5 A Risk-Based Approach to Compliant GxP Computerized Systems (2008), 334 Appendix G2
Author: Jeff Rubesin – Manager, Product Development
Call us from within the United States:
Calling from outside the United States?