In our last post we looked at changes in E6 R3 that affect specification, build, and deployment of IRT systems.  In Part 2 we look at changes that affect use of these systems. Some of these changes are new to GCP; others were always in place for data capture systems, but now E6 R3 is making explicit the fact that IRT systems should be considered data capture systems. Below are issues we typically see during audits and inspection prep - your mileage may vary!

• Data changes. Per III. 3.16.1 (i), the sponsor "should not make changes to data entered by the investigator...unless justified, agreed upon in advance by the investigator and documented." Ideally, sites would make all changes to IRT data, but because IRT systems tend to have a strict workflow, many IRT vendors have a mechanism for their help desk or a study team user to make data changes. Some vendors capture the investigator's approval in the text of a help desk ticket, but that information is rarely exported and filed in the TMF. We've also seen sponsors make those types of changes without explicitly capturing an investigator's approval. Sponsors should consider how they will demonstrate that the change is justified and "agreed upon in advance" by the investigator.
• Endorsement.  Per III.2.12.5, "the investigator should review and endorse the reported data at important milestones agreed upon with the sponsor."  PIs typically "endorse" eCRF data by applying electronic signatures to completed casebooks, but they seldom sign off on IRT data. Should they?  In many cases IRT data such as subject numbers and kit numbers are integrated into EDC, so PIs would be endorsing these data along with eCRF data; however, not all data captured by an IRT system are integrated. 
• Control.  Per III. 2.12.11, "the investigator/institution should have control of all essential records generated by the investigator/institution before and during the conduct of the trial." Per III. 3.16.1 (k), "The sponsor should not have exclusive control of data captured in data acquisition tools in order to prevent undetectable changes." As with EDC systems, the site exhibits "control" of an IRT system by its ability to access the system, so the site can detect unauthorized changes by comparing it to source.  When the site's read access is removed, and they are not able to download a certified copy of their data, the sponsor (in theory) could make changes on the back end that could not be detected.  Thus, just as sites must be able to download or be provided with copies of eCRFs post-lock but before decommissioning, they must also be able to download or be provided with copies of IRT data at the same time.  Some IRT vendors routinely provide sites with these reports, but not all.
• Bugs. Per III. 3.16.1 (x) (v), sponsors should "ensure that there is a process in place for service providers and investigators to inform the sponsor of system defects identified."  Most IRT systems feature some kind of help desk support; many sponsors, however, do not have a formal process for reviewing help desk tickets on a regular basis to spot trends that could indicate configuration or security issues. This is a good practice that demonstrates oversight and helps alert the sponsor to configuration issues with the system before they become widespread.
• Retention. Per III. 3.16.3, the sponsor should retain essential records in accordance with applicable regulatory requirements. The requirement for retention is not new, although the deferral to local requirements is; however, we frequently find that sponsors don't have a complete record of IRT data at the end of a study.  Some sponsors get reports, but not audit trails or user history data. As we saw in our previous post, most sponsors do not retain their vendors' testing and validation documents.  As a general rule, we recommend leaving no documents with the vendor that you might potentially need during an inspection OR other activity that requires reconstruction of trial activity.