Anatomy of RTSM Change Requests: How Modern Platforms Are Eliminating Delays

Clinical trials are more complex than ever. Yet when you need to change something in your RTSM system – even something basic – you’re told to wait months. 

Why? Legacy RTSM systems were never built for rapid updates. They rely heavily on people, who can only do one thing at a time. The result? A simple change request can take months to implement. 

Let’s expose why these delays happen and how modern RTSM platforms are finally solving this decades-old problem. 

(Pressed for time? Skip down to our comparison table) 

 Anatomy of an RTSM system change request 

What’s happening behind the scenes that a simple change takes RTSM software vendors so much time? In the interest of transparency, let’s break down the process of executing a change request to expose the areas where needless lags can occur in the legacy RTSM model.  

Part 1: Change assessment  

So you have a protocol change, a feature you’d like added, or some other update you’d like made to the RTSM system. Great! Before your change request can be executed, your RTSM provider needs to do some work on their end and provide a scope, impact assessment, and cost for your review and approval.  

It is typically a project manager (PM) who acts as intermediary between you and their internal engineering, account management, and contracting teams. Here’s how that scoping process might play out:  

Step 1: Customer initiates change request to RTSM provider 

Your PM receives your change request. They first need to understand the specifics of your request, so that they can clearly communicate to the engineers exactly what outcome you expect. Most PMs are not empowered to do much more than act as a liaison between you and their internal teams, so they begin their project management by proceeding to engage with their technical resources, the engineering team, to explain your request. 

Potential lag: Many PMs are handling tremendous workloads and many clients simultaneously. One of the frequent complaints is the amount of time spent waiting for a PM to initially respond to your change request at the start. 

We often hear of a shared resource queue, where a PM needs to get in line to schedule time with a technical resource. Depending on staffing or the general workload of those internal resources, it can take several days—if not longer—to get a meeting on their calendars.  

Step 2: Change scope, timeline, and cost estimate 

This step is really two steps in one, as it requires the engagement of both engineering and account management teams at the RTSM vendor. First, a technical resource on the engineering team will determine the scope and impact of your requested change. Then, based on their assessment of the scope of the change, an account manager or—depending on the size of your RTSM vendor—the contracting team will determine pricing. 

Potential lags: The engineer will often identify multiple options to carry out your change and prepare assessments for each option they bring back to the PM. Legacy RTSM systems are typically individually built and configured using a copy of code heavily modified by the engineering resource assigned to build it. To properly assess each change, engineering must analyze the client’s specific codebase to answer three key questions: where to implement the change, how to execute it, and what effects it might have on other system components. This process can take extra time if the engineer doing the assessment is not already familiar with that specific system’s unique design and coding.  

Step 3: Customer review & approval of timeline & cost

The PM brings the impact assessment and pricing back to you. In effect, the PM tells you: here’s what we heard, this is what we can do to make that change happen, here are some possible ways that change can be made, here’s how much time each option will require, and this is how much each option will cost.  

Potential lag: If you feel the options presented aren’t what you need, you may need the PM to go back to the engineer again with more information, repeating Steps 1 to 4 all over again.  

Step 4: RTSM requirements update, review & approval

Once you have found the option you’re happy with, your PM will typically require your approval of the approximate turnaround time and cost to proceed with the change. It may involve an update to the user requirement specifications (URS) document, which would also require your sign-off.   

Potential lag: With many RTSM vendors, especially larger ones, the change request process involves so many layers of engagement that lags are inevitable due to miscommunication, queuing, waiting, and repeating for clarification.   

With all this timeline bloat, it can take two to four weeks for the PM just to provide you with cost, timeline, and URS update so that you can give approval to proceed, with no work yet started.  

Part 2: Change execution 

Once you give your approval to carry out the change request, the execution can take a further two to three months.  

Step 5: Customer queues for RTSM resource availability

First, you wait on availability of engineering resources to do the work. Because the same engineers are typically engaged in handling both new builds and system updates, it’s not uncommon for your change request to be deprioritized in the service of another client’s go-live timeline.  It will also be influenced by how many other projects your RTSM vendor has going live at the time, because go-live operations are much more lucrative than system enhancement requests.  

Potential lag: The same challenge that arose during the assessment comes up again when the time comes to carry out the change. Legacy RTSM systems are deeply customized at the code level, requiring a developer to first become familiar with the initial system to address the change request. Sometimes, getting a developer who was involved with building the specific customer’s RTSM system can be a matter of luck and timing. If it’s assigned to an engineer who doesn’t know the original system, they may take longer to understand what’s needed and may even introduce poor-quality changes that result in further delays and quality issues. 

Step 6: Engineers make the change   

The change gets made. Depending on how your RTSM system is built, the engineer will make the necessary coding changes or update the system’s data and configuration. The scope of the change and the nature of your RTSM system will determine the complexity of this step.    

Potential lags: If you’re working with a legacy RTSM system, this change may require extensive coding changes, testing, and troubleshooting. Again, the engineer’s level of familiarity with the system makes a huge difference in how long it takes to get the change made on a traditional custom-coded RTSM system. 

Step 7: Test engineers verify the change  

A test cycle is carried out. Quality assurance engineers at the RTSM provider will test to ensure the change achieves the desired effect. The customer may then choose to do further UAT testing as an additional Step 8.  

(Learn more: Automation Testing in RTSM Software: What It Is, and Why It Can Impact Your Trial Timelines and System Quality)   

Potential lags: Changes made to RTSM systems can often result in downstream glitches that are only revealed at the testing stage. Fixing these bugs often requires further cycles of coding changes and testing.  

Reducing timeline bloat with a modern, adaptable RTSM 

Legacy RTSM delays stem from two problems: outdated technology and inefficient processes. Every change requires engineers familiar with that specific system’s custom code, plus multiple handoffs between teams. 

Korio’s platform-based approach is different. Our standardized architecture and streamlined processes mean high-quality changes happen in a fraction of the time. Here’s why: 

• Nimble platform: Our RTSM systems are built on a standardized, configurable platform – not custom code. This means changes don’t require engineers to learn your specific system, and updates often don’t involve messy code modifications. With automated testing built in, we deliver higher quality changes faster. 

• Experienced project management: Our PMs aren’t just messengers – they’re RTSM experts who can assess impacts and recommend solutions immediately. They’re authorized to make minor changes directly and have instant access to engineering when needed. The result? Many changes are completed in just a day. 

If you shift to Korio for your next RTSM system, you’ll see the stark difference from traditional RTSM providers in both the technology and the level of service you receive. Schedule a demo and see how Korio gets you Ready for the Trials Ahead™.