Today, we start our new series on implementing E6 R3, focusing on changes that are complex or represent a new(ish) way of thinking for the industry. 

In the past, we've categorized changes to E6 R3 in three buckets:

• Changes that represent common practice in industry, but which were absent from the GCP guideline and now have been added. For example, sponsors typically handle submissions to central IRBs/IECs; this is newly reflected in R3.
• Changes that represent EMA and MHRA "soft requirements," but may not have been fully implemented by sponsors, especially US sponsors.  For example, EMA's "Q&A" has long maintained that sponsors should not have exclusive control of data, and this point was added to EMA's Guideline on Computerized Systems and Electronic Data in Clinical Trials in 2023, but many US sponsors are unfamiliar with this concept.
• New principles designed to be applied as appropriate, in lieu of requirements. For example, R2 had a list of essential documents required for all studies; R3 gives us principles of "essentiality."

We start our series with a topic that straddles the first and second categories:  IRT systems. Part 1 will look at changes that affect IRT specification, build, and deployment, and Part 2 will look at changes that affect use. 

First, a bit of background. IRT refers to "interactive response technology," which is a modernization of the term "interactive voice response system," which is a throwback to the before times when people used touch-tone telephones to interact with simple computer systems - including those that randomized patients in clinical trials. This technology, which was developed in the 1970s and reached its zenith in the pre-internet nineties, has been largely replaced browser- and app-based systems today. The term "interactive response technology" is not very descriptive, considering that all computer applications could meet that definition, but it's generally understood in clinical research as a system that randomizes participants to a treatment group and generates randomization and kit numbers in response to prompts entered by investigational site staff. Systems that perform these functions and also manage IMP inventory are known by the newer term Randomization and Trial Supply Management (RTSM). We'll use IRT in this post to align with the terminology in E6 R3.

The terms "interactive response technology" and "IRT" did not appear in E6 R2.  We always interpreted the R2 terms "computerized systems," "data processing systems," "electronic trial data handling" and "electronic trial data systems" to include IRT, but we've audited sponsors and vendors who did not agree that IRT systems fell into the category of data capture systems.  In R3, "IRT" is cited as an example of a data acquisition tool, so there is no doubt that controls in the Data Governance section apply to IRT systems.

Most IRT vendors already implement many of the controls in the Data Governance section: Validation, security, tech support, user management, protection of confidential data, and security are typical controls for IRT systems.  There are, however, a few requirements that sponsors and vendors do not always observe, in our experience.

• Validation.  Per III. 4.3.4, "validation should generally include defining the requirements and specifications for the system and their testing, along with the associated documentation, to ensure the system is fit for purpose for use in the trial, especially for critical functionality, such as randomization, dosing and dose titrations and reductions, and collection of endpoint data."  No sponsor or IRT vendor would argue against validating IRT systems; however, we frequently see approaches that leave key steps undocumented.  For example,
  • The IRT vendor performs robust testing but does not share the documentation with the sponsor.  IRT vendors may use testing systems that don't "package" documents nicely, and the vendor's rationale is that they will always provide this documentation if requested during an inspection...but vendors go out of business; their retention times may not align with sponsor needs; and sponsors cannot show demonstrate oversight if they don't have access to these documents. Taking this a step further, we recommend that for critical functionality, sponsors review this documentation at a high level before starting UAT, so they can see for themselves how robust their vendor's testing is.
  • The sponsor performs a robust UAT but documents only the issues that were found. This approach leaves no record of what was tested. If an issue is encountered later, the team won't know if a particular function was fully tested.
  • The sponsor performs robust UAT for the initial release, but not for changes, because the scope is seen as narrower and then less risky.  This represent faulty risk assessment, because changes to IRT systems can be extremely risky, especially for data related to participants who are being rescreened or who are midway through the screening process.
• User access. Per III. 4.3.8, "authorized users and access permissions should be clearly documented, maintained and retained. These recors should include any updates to a user's roles, access permissions and time of access permission being granted (e.g., time stamp)." Most IRT systems (not all!) can report user access information easily, but many sponsors do not have requirements to retain these reports before their IRT systems are decommissioned. Sponsors should verify that this information (including audit trail) is accessible without a custom report and ensure it is downloaded to the TMF.
• Visible permission sets.  Per III. 3.16.1 (x) (iii), sponsors should ensure that "access permissions granted to investigator site staff are in accordance with delegations by the investigator and visible to the investigator." The second half of this requirement - ensure that access permissions are "visible to the investigator" - could be difficult to meet. Most data acquisition system users do not have on-screen visibility into the permissions associated with various roles. A summary of roles and permissions in the user manual might be the easiest way to fulfill this requirement. 
• Timely access.  Per III. 2.12.3, "the investigator should be provided with timely access to data by the sponsor and be responsible for the timely review of data, including relevant data from external sources that can have an impact on, for example, participant eligibility, treatment or safety... The protocol may provide exceptions for access...to protect blinding." Site staff must typically have access to the IRT system before study start, but the PI's access frequently lags behind.  We've audited studies where PIs for some sites never completed their training or never logged in. 
• Ability to unblind. Per III. 2.11, "the investigator should be prepared and capable from the start of the trial to perform unblinding."  This step anchors the term "timely" to the period "from the start of the trial." For investigators to be "prepared and capable" to perform unblinding, they must be trained, logged in, and have a role with appropriate permissions to unblind.  

In our next post, we'll look at changes that affect use of IRT systems.