Co-authored by Reeshav Mittal (Clinical Trial Subject Matter Expert)
Within the clinical trial industry, Risk-Based Monitoring (RBM) is another rising trend that empowers research teams and stakeholders to conduct clinical trials with greater flexibility in monitoring visits whilst continuing to gather reliable data. By identifying patterns indicative of lower risk, RBM allows reduced monitoring visits to research sites when these visits are not necessary. RBM has a number of benefits, the most obvious being an increase in monitoring visits to research sites with identified higher risks that may disrupt data quality.
But while increased monitoring is remedial in and of itself, RBM does more than that. By identifying patterns indicative of higher risk at research sites, RBM allows for the examination and possible resolution of risk causes, thereby reducing the need for more frequent monitoring visits at clinical sites which initially required more attention.
A consequent benefit of reduced monitoring visits at low-risk sites and risk-remedied sites is cost reduction. Cost reduction leaves more room in the budget to increase other expenditure areas in clinical studies. Or it saves money for the purpose of saving money, which could be great for Contract Research Organizations (CROs) if their contracts allow them to pocket all or some approved cost reduction differences towards their profit margin.
There are however impediments towards the universal application of RBM. This blog post will outline some of the most common problems an organization may face in applying RBM during certain clinical trials. It will also illustrate some solutions based on software integration and services. The service aspect of software integration is as significant as the implementation aspect, as the software solutions section will clarify.
The Problems
Sponsors, CROs, and stakeholder organizations involved in research are already dealing with myriad issues pertaining to; existing and evolving regulations, following various safety protocols and legal procedures, as well as monitoring ongoing consent processes, and so much more. It’s all very well to tell them that implementing Risk-Based Monitoring will simplify these issues in the long run. Great. But what happens in the stage of initial implementation? Who has the bandwidth to deal with more changes to how things are done? Specifically if there’s no immediate imperative to do so? Add the complexity often associated with the initial phases of RBM implementation for first-time teams and you’ll realize you’ve basically added complexity to a situation that might not have been very simple in the first place.
But where in particular does the complexity of Risk-Based Monitoring lie? The complexity of RBM is primarily due to the difficulty in ascertaining which protocol deviations and unfulfilled recruitment expectations constitute higher risks for different clinical sites. At which point of detecting protocol deviations should a trigger for higher monitoring frequency be implemented?
Within the same study, the number of protocol deviations which should trigger higher monitoring frequencies can differ from clinical site to clinical site. Within the same study, the shortage of the number of recruits becoming a risk factor can also differ from site to site. One of the factors is that every site has its protocols, and whereas in some cases, a large number of protocol deviations is not indicative of any risk, in other cases, even a single protocol deviation should trigger an increase in monitoring visits.
More complexity arises from the fact that the triggers do not only concern increasing or reducing monitoring visits. For example, there are triggers for initiating risk mitigation protocols as well. There are also triggers that issue study-specific warnings. It’s not all about increasing or decreasing monitoring visits. Overall, the number of triggers identified as necessary for a study and implemented across different sites can be difficult to manage without the right tools and training, at least from a data analysis perspective. For example, one trial implemented a full 38 triggers across 42 sites.
The options for RBM software and tech implementation models are numerous. They only continue to grow. In fact, today, as opposed to just a few years ago, the vast majority of Clinical Trial Management Systems (CTMS) software packages have some sort of built-in RBM solution available. Some CTMS packages can even integrate with external RBM solutions. But “not all RBM solutions were developed equal”. There are RBM solutions that depend on established patterns in previous data for analysis, without the technological capacity to consider the indications of very recent data and its effect on emerging patterns. Some RBM solutions severely lack in every analytical application and tend to assess risk separately from context.
Some RBM software solutions will serve very well for specific study needs, whilst others offer a wider variety of features that may be required in numerous types of clinical studies. Unless your organization specializes in studies that only require the same RBM features every time, buying type-specific tech is not the most advisable course of action. On the other hand, if you’re newly implementing RBM, you don’t want to overwhelm your team with a wide variety of features which they may not need.
Supposing the powers that be sat down with a paper and pen (read: tablet) and planned ways around the above-mentioned impediments to the implementation of RBM. After delivering the decision to implement RBM to the monitoring personnel, the management may (and often does) encounter resistance from them. This resistance may have good reason rather than necessarily being simple insubordination.
Being expected to learn a complex new approach without support may generate a natural procrastinative resistance which doesn’t deliberately reject learning a new approach, but rather puts off the more difficult task till the other, simpler, tried & tested processes are accomplished. Of course, tried & tested tasks end only for more tried & tested tasks to arise so learning can take a very long time.
Some of the learning challenges occur due to unfamiliarity with RBM as opposed to more conventional monitoring, which is based on scheduling fixed monitoring visits. As such, there is unfamiliarity with the data which factors into identifying risk patterns and defining their parameters. There is also a lack of experience with regards to mitigation plan application. As a result of poor risk detection and management, there may be a reduction in monitoring visits for clinical sites which should see an increase in them. This may affect the quality of the data from these sites, as well as the overall performance of the study from all aspects.
Another cause for resistance is the requirement for schedule flexibility on the part of many monitors when RBM is applied. During timeline-based monitoring, monitors know ahead of time when they should visit a site, where they’ll be going and they know this information well ahead of time. Under a Risk-Based Monitoring system, Monitors should be able to visit clinical sites as soon as possible after a communication protocol is triggered by the identification of a risk pattern. People who have been basing all their monitoring work around fixed schedules may have trouble adjusting to this new system. Applying RBM means fewer overall monitoring visits but more risk observation, which can be time-consuming without the right solution.
The Software Solutions
The problems mentioned above, as well as other common impediments to RBM implementation, can often be addressed in two components. The two components in question are usually made possible by hiring a specialized third-party “Software as a service” (SaaS) company, which can provide a white-glove implementation of a fully integrated software solution as well as extended training & support.
White-glove service helps with solving the high complexity problem because it allows the SaaS company to examine the existing process and introduce the simplest and most intuitive possible implementation. It also allows your organization to select a Risk-Based Monitoring solution rich with all of the necessary features without worrying about overwhelming your teams, since the interface can be tailored to your teams’ exact requirements, which addresses the issue of selecting the best technology.
The extended training & support service offered by the SaaS provider is also important in overcoming the third of the above-mentioned problems. Resistance from monitors due to learning difficulties. With a SaaS provider contracted, stakeholders don’t need to worry about freeing up bandwidth to implement a good RBM training program. The SaaS provider’s dedicated teams examine the organization’s processes and determine how to implement training with the Risk-Based Monitoring software along the path of least resistance, so that the monitors can be fully empowered to carry out the management’s decision to adopt RBM.
But what do we look for in a highly integrated RBM solution? Any RBM software solution your organization selects should at least be able to generate alerts & communications to relevant parties when certain events are triggered, generate audit trails, support risk identification & assessment & categorization, provide a list of risk libraries relevant to the trial, convey data related to risk changes, offer damage control/risk mitigation protocol initiations & plans, allow tracking of issue management (identification, risk scoring & categorization, communication, escalation, and resolution).
RBM solutions with visual analytic tools built into them offer interfaces that enable stakeholders to integrate data from numerous sources and display them in bar graphs, trend charts, and other visual data mediums. Carefully selecting the correct SaaS provider allows the interfaces to be customized to very specific needs to avoid overwhelming organizations with irrelevant functionalities. It also allows easy redefinition for the events which trigger warnings and other communications to relevant personnel. Research staff and other stakeholders can ideally change the parameters which trigger automated communications themselves without requiring backend configuration from the SaaS provider every time.
Good RBM solution packages also offer more advanced predictive features. While this can never compare to the stable schedule of timeline-based monitoring, it can make visits a little less erratic, which is good for monitors’ adjustment to the new approach. Extensive support in using the software could also help monitors automate risk observation to a great degree, which would also strain their schedules less.
There are more common challenges towards the implementation of RBM in some clinical studies than those mentioned in this article, but all of the impediments towards RBM implementation mentioned here, and many others that are not, can be addressed satisfactorily by selecting the right SaaS provider. Using software technology to address impediments to RBM has taken Risk-Based Monitoring several steps forward. The demonstrated success of this software technology seems to indicate a promising future towards further integrating RBM for some clinical studies in organizations that have not yet widely adopted Risk-Based Monitoring.
Cloudbyz Unified Clinical Trial Management (CTMS) is a comprehensive, integrated solution to streamline clinical trial operations. Built on the Salesforce cloud platform, our CTMS provides real-time visibility and analytics across study planning, budgeting, start-up, study management, and close-out. Cloudbyz CTMS can help you achieve greater efficiency, compliance, and quality in your clinical operations with features like automated workflows, centralized data management, and seamless collaboration. Contact us today to learn how Cloudbyz CTMS can help your organization optimize its clinical trial management processes.
To know more about the Cloudbyz Unified Clinical Trial Management Solution contact info@cloudbyz.com