The contracts have been signed, the study teams are in place (at the Sponsor/CRO and vendors), and it’s time to hold the startup meeting for one of the first data collection tools that will be used for your clinical trial – namely, the Interactive Response Technology (IRT/IWR/IVR) system.
An IRT is the tool of choice for subject randomization and management, drug assignment and inventory management, and shipping, and as such is often the first point of entry for subject data – data that is then typically pushed to the EDC housing the clinical database. But what do you need to bring to the table to help get the IRT efficiently up and running on your project?
Here are some tips for Sponsor/CRO PMs – for convenience, let’s call you ‘Client PM’ - on how to approach the startup meeting with your IRT vendor:
- Make sure you study team has a demo of the IRT system prior to the startup meeting. This helps enormously in visualizing potential issues, special needs, and new questions related to your use of the system for your project.
- Don’t triangulate – make sure ALL stakeholders/decision makers are in the IRT startup meeting. These include (at a minimum) the Client PM and representatives from Clinical Operations (perhaps the Lead CRA), Biostatistics, Data Management, and Clinical Supplies. In addition, you may want to include leads from Regulatory Affairs (for medical monitoring), Drug Safety, and Quality Assurance. Be sure both blinded and unblinded users are represented at the meeting.
- Realize that while the IRT vendor has studied the protocol, YOU are the expert on the protocol’s requirements, idiosyncrasies, special needs, etc. that the trial entails. The IRT study team will have made basic assumptions and interpretations based on the protocol document, but their expectation is always that the Client PM will bring the fleshed-out details, procedures, concerns, and caveats of the project into the meeting room. The Client PM’s prep for the IRT startup meeting should therefore be a detailed checklist of protocol specifics to share and confirm with the IRT study team. The goal is to enable the IRT vendor to produce a credible first draft of the User Requirements Specification (URS) for the project.
- To assist with the development of this checklist, don’t hesitate to ask for a general Table of Contents from the vendor’s standard URS. Here’s a list of key topics that traditionally apply to IRT systems and which, if applicable to the study, will be ironed out during the URS development process:
- Visit Schedule – the types and windows for scheduled visits that will be utilized by IRT – types of data to be collected at each visit
- Potential unscheduled activities – e.g., unblinding, screen fails, early withdrawals, unscheduled visits, etc. – and data to be collected at each activity
- Treatment groups and CTM types
- Dosing and titration schemes
- CTM sources – manufacturer(s) – distributors -- central warehouses, regional depots
- Resupply types – static or predictive – automatic and/or on demand – across sites
- The type of randomization scheme to be used for the study – e.g., a traditional randomization schedule, a dynamic/minimization approach, adaptive or forced randomization, etc.
- Strata variables and rules – e.g., questions to be asked? A drop down of options?
- Cohort information and rules -- e.g., cohorts opening sequentially or concurrently?
- Countries, regions, sites
- Users, user types, and types of access (including blinded vs. unblinded)
- Data formats – e.g., subject IDs, randomization IDs, CTM IDs, dates, and so on
- Data labels – e.g., kits vs. vials vs bottles (or any other label for the drug)
- Types of notifications and identification of recipients – e.g., for one study, Notification A is fine; for another it might be unblinding. The Client PM and IRT PM work together to determine how the blind will be protected.
- Tracking temperature excursions
- CTM accountability and how it works – unit vs content level accountability – how drug returns, destruction processes will work (e.g., will only certain kits be returned to/destroyed at certain depots?)
- Limits – set the initial number of subjects:
- By Country
- By Site
- By Region
- By Strata
- By Cohort
- Confirm how subject randomization and kit lists (planned and available) are to be generated (by whom, and when) and imported into the system, how dummy lists are used, etc.
- Subject diaries – if these apply to the study, discuss details and expectations to see if any potential issues arise
- Let the IRT PM know of any additional, atypical processes/documents that might be utilized in the study. For example:
- Lab worksheets
- Worksheets to determine strata
- Special calculations
- Expect the IRT PM to bring the contracted Scope of Work (SOW) to the meeting, and confirm your understanding of the scope – i.e., system functionality/modules -- with the IRT team. Note that it is not uncommon for study needs to change between bid and startup, resulting in a needed change in the SOW. For example, the initial scope may have included a static automatic resupply but during startup discussions it may become obvious to the IRT PM that a predictive approach would better serve the study. Similarly, it may originally have been thought that temperature deviation was not important for study analyses, only to learn that temperature information will need to be captured in the IRT after all. Use the startup meeting as a good place to clarify the SOW and identify any contract modifications that might be required.
- Ideally, the logistics of team interaction are put in place at the IRT startup meeting. For example:
- Share contact information for all Client and IRT study team members
- Agree on communication and meeting plans and procedures – expect a draft communication manual from the IRT PM before go-live
- Understand signoff processes – who will be authorized to sign which types of documents (including specifications, data or configuration change requests, data imports, etc.)
- Engage the IRT PM in a description of the startup and change processes to be used on the study, including all documentation/signoff points you can expect. For example, how does the system moves from validation by the IRT team to User Acceptance Testing by the Client team to a final Release to Production authorization? What are all the signoff points that will arise during the study? How are mid-course configuration changes handled?
- Basic timelines – expect the IRT PM to provide a general outline of the timelines for deliverables, and expect a follow-up after the meeting with more specific dates and any potential issues
The key take-home message for Client PMs is this: bring to the IRT startup meeting all the things you are worried about, things you believe are pivotal to the study, and all the potential critical risks you see. Your effort will be rewarded by an enhanced ‘smooth sailing’ from early startup to IRT live.
Share this Post