August 7, 2017
The first IRT systems in the 1990s were completely custom coded. Each application was built from scratch and therefore could meet all the sponsor’s needs for a study because it was 100% customized. End-users loved them since they met their study needs, but they took forever to build and were very expensive.
In the early 2000s, the first parameter-driven, web-based systems were introduced. They were less expensive to build and saved time but only if the system fit the sponsor’s needs out of the box.
So, the industry went from 100% customizable (coded) systems to partially configurable systems. Those systems were off-the-shelf, meaning that the end-user needed to take the system as it was and force-fit it to their internal processes, or even more disruptive, change their internal processes to fit the technology. These systems were more than likely considered “enterprise” systems and they were so ingrained into the organization that there was a very high probability organizations would stay with older systems purely for the change management it would take to free themselves from “the way it’s always been done.”
As technology continues to evolve, either driven by regulatory shifts or scientific breakthroughs (just think about all the new technologies that were spurred on by the RBM guidance or the shift toward biologics and immunotherapies), they can no longer be implemented into the fabric of the organization, but rather need to ebb and flow with the needs of clinical trials.
This brings us back to the partially configurable, off-the-shelf concept. The core of the system stays the same, but certain features can be customized to fit the needs of the specific organization and study. From an operational perspective that may sound great. However, it is important to understand that any amount of customization involves coding. Coding requires more time and resources and ultimately limits future use of that product for anything beyond that specific study. You can’t just flip a switch and turn off the new add-ons when you don’t need them. It also makes future changes cumbersome and costly. I’ve seen companies customize so much that they lose sight of the core function of what is really needed from the system, and eventually (and painfully) they decided to pare them back.
How can the industry achieve the benefits of customization with the flexibility to adapt to changing study needs as well as the introduction of new requirements (driven by science or regulations)?
The answer is 100% configurability.
The pendulum has swung all the way from 100% customization to 100% configurable, and here is why. Configurable systems are designed to adapt to client needs.
Flexibility is literally built into the system itself.
The good news is that configurable systems DO allow you to flip a switch. Do you need this feature for study A? Great. You don’t need it for study B? That’s fine too. Do you want the system flow and vernacular to match your internal SOPs and processes? Done.
A word of caution, though. Not all configurable systems are created equal. For the above to work, the system needs to be 100% configurable, not just use a configurable tool (because that is where custom coding creeps back into the picture). Even if the system is 80–90% configurable, the remaining 10–20% is custom coded, or customizable. If we operated in an industry where what you needed on day one was exactly what you needed on day 10, 30, 90, etc., there would be no issue. In your experience, has that ever happened?
Want to know one of the top benefits of working with a 100% configurable and agile RTSM system? All additional features added on are now part of the core product. If a feature is built for one client, it is not only available for that client’s multiple studies but it is now available for all other clients. Each can have its own flavor of that feature – again that flexibility is built right in. And since you can turn them on and off when they are needed, changes are no longer a disruption to your study.
Hopefully the next time you are presented with the terms customization and RTSM configuration (with respect to any clinical systems), you will know what questions to ask, and what benefits and limitations each approach offers.
Tag(s):
Study Start-Up