One of the things we try to do with our weekly hot topics is bring to the forefront the latest excitements, ideas, and controversies surrounding clinical trials and Interactive Response Technology (IRT/IVR/IWR).
Among the most hopeful initiatives touted in recent industry conferences is the goal of implementing a 2 week rollout for an IRT system, from Contract Approval to Release for Client Testing (UAT).
Smoke and mirrors? Pie in the sky?
Or is it actually feasible?
The answer hinges on how successful we are at modifying the traditional approach to building the User Requirements Specification (URS) and producing a system for final client review.
In the traditional ‘waterfall’ approach, the study team works through numerous meetings and draft iterations of a URS to produce an agreed-upon written version of how the project system will function. A signature round follows, with varying timelines, and then, and only then, does system development work begin. It is generally agreed that beginning prior to approval may result in a need for re-work; and re-work is expensive, time-consuming, and a circumstance to be avoided. Once a trial system is produced, the client team gets to see for the first time what the URS was trying to tell them.
In the modified approach – which we like to call the ‘Laser-Focused Team (LFT)’ model because it requires a solid working team of client and vendor devoted to expedition– the following occurs: An initial build of the project system is completed based on the protocol. The project team ‘walks’ the system in its initial meeting. Comments and clarification about system functionality are collected in that initial session, including any custom requirements that may be needed for the project.
The next meeting would be an agreed-upon work session for half a day or better with the entire LFT (all decision makers) in the room, and the updated system as the star. No one needs to try to digest a large document to see what the system will look like, because there is no large document as yet. The system in progress speaks for itself. Any errors in the developer’s initial interpretation of requirements can be quickly spotted and addressed earlier in the process, with the accompanying time savings rendering obsolete traditional concerns about ‘re-work’.
At this critical review meeting, it’s the LFT’s job to mold the system into the final configuration – e.g., confirming which visit windows are hard or soft, what ranges are acceptable, what labels are used CTM and visits, whether the unblinding process require additional questioning or authorization, and whether the vendor’s understanding of the custom requirements was correct… and so on.
After the system review meetings have gained agreement from the team that system meets the requirements of the project, the URS document is produced from the system. The URS is approved and formal testing is completed by the vendor, followed quickly by client testing (UAT). The URS in this model would include all project configuration specifications without concern about it becoming ‘too difficult’ a document for client reviewers. Client reviewers will have already had an active role in its creation!
What has essentially changed here is a sidestep from the following time-honored rule in system development: First document what needs to be done, then develop, test, and show that you’ve done it. The new rule might be described more like this: Produce a system that has been agreed upon by the LFT as satisfactorily capturing the needs of the protocol and all specific project goals, and then provide the URS to document that agreement.
What is required to make such a change happen?
Two things: Adventurous Sponsors/CROs and who are willing to make the time commitment and embrace a pioneering system life cycle strategy– and software vendors who are willing to trek the potentially rocky trails around the waterfall.
Share this Post