search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
TECHNOLOGY & INNOVATION


Stakeholder engagement: the foundation of a successful IRT build One of the most critical aspects of IRT system design is ensuring that all stakeholders are engaged from the outset. An IRT system serves a wide array of stakeholders, each with distinct needs:


• Clinical operations: ensures the system effectively represents protocol requirements and is user-friendly for site users.


• Clinical supply chain: focus on control over supply chain process while prioritizing data visibility, and reporting.


• Data management: prioritises data integrity and seamless integration with other systems like electronic data capture (EDC).


• Biostatistics: requires protocol-aligned randomization and access to clean, well-structured data for analysis.


Engaging stakeholders early and maintaining continuous involvement is crucial to accurately capture, implement, and test their needs and expectations.


The critical role of URS development The development of a user requirements specification (URS) is the cornerstone of a successful IRT build. The URS defines the IRT system’s operations in every scenario, recognising that the system will perform exactly as programmed.


During the build timeline it is important to


carefully consider every aspect of your trial, especially those ‘nooks and crannies’ or uncommon scenarios that make up the 10% of cases that don’t follow the path laid out in the protocol.


The 10%: planning for uncommon scenarios Consider a study where patients can choose either a one-month or a three-month supply of investigational product (IP) at each dispensing. What if there’s less than three months remaining in the study and the patient wishes to skip dispensing until the end?


• Should the IRT offer two months of IP? • Should the IRT require the patient to return for each visit?


This scenario must be clearly defined in the URS, or it will be open to interpretation by IRT programmers. Ambiguity can lead to site-level confusion, patient dissatisfaction, and supply chain inefficiencies. Additionally, consider how the IRT will behave


over time. For example, if dispensing a three- month supply, how should the IRT adapt?


• Will the IRT predict for three months of IP at a time or just one month?


• Does this logic change if the patient switches between one- and three-month dispensing?


• How does this impact the site, site users, and the supply chain?


The importance of user acceptance testing (UAT) User Acceptance Testing (UAT) is the final opportunity to identify and correct issues before the system goes live. Allocate adequate time for a thorough UAT, focusing on bespoke or customised features that carry higher risks. Test scripts are the backbone of a successful


UAT. A good test script should outline user inputs and expected IRT system outcomes before testing begins. While some IRT providers offer test scripts, these often serve as a starting point and may not fully test the bespoke aspects of your system. Customised features inherently carry more


risks. You can generally assume that standard modules used across all protocols are mostly error-free and require minimal testing. However, the bespoke features—like dispensing one or three-month supply of IP —need focused testing. As another example, consider a double-blind


protocol that includes an open label extension (OLE). How will the IRT system handle the transition as subjects approach and enroll in the OLE?


• Will the predicted demand for the IP automatically adjust as subjects move into this phase?


• Could this lead to over- or under-supply issues?


These are the kinds of edge cases that should be rigorously tested during UAT.


Clinical Trial Supply Handbook | 23


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44