We've finally moved on from our series of posts about Quality by Design, but we're continuing our series on implementing E6 R3.  Today we look at a few new requirements tucked into the revised guideline regarding data changes. So many unrealized Oxford Comma opportunities!  

The Sponsor Responsibilities section now includes these details:

"The sponsor should provide guidance to investigators/institutions, service providers and trial participants, where relevant, on the expectations for data capture, data changes, data retention and data disposal (III.3.16.1 (h))."  These are common practices; however, this is the first time they have been outlined explicitly in E6. 

"The sponsor should allow correction of errors to data, including data entered by participants, where requested by the investigators/participants. Such data corrections should be justified and supported by source records around the time of original entry (III.3.16.1 (j))."  Again, this is a common practice in cases where data are obviously incorrect, such as when a site registers a participant under the wrong number or enters a participant twice. The practice of changing participant-entered data is much less common. Generally, we accept the fact that these data will be messy and leave them as is; most studies do not really have a mechanism for participants to change data or to request changes to data they entered, either through the ePRO tool or through a verbal request. So we can anticipate that sponsors will be making changes to those data.  However... 

"The sponsor should not make changes to data entered by the investigator or trial participants unless justified, agreed upon in advance by the investigator and documented" (III.3.16.1 (i)).  Previously, E6 R2 specified that data changes must be documented and traceable in the audit trail; however, there was no expectation that sponsor-initiated data changes were a special occurrence requiring justification, despite the fact that the industry's adoption of EDC has made sponsor changes to clinical data increasingly rare.

The challenge, of course, is not necessarily with EDC data, which sites can change themselves, but with EDC "edge cases" as well as data from other data capture systems, like IRT, RTSM, ePRO, and eCOA, which cannot always be changed through standard system functionality. 

In the past several months, we've encountered the following scenarios in which sponsors and CROs are making data changes:

• A study team captures protocol deviations in the EDC system.  They change the protocol deviation plan so that deviations for screen-failed participants do not need to be reported; the Data Management group then deletes protocol deviations for screen-failed participants from the EDC system. The rationale is captured in a note-to-file, which is filed in the TMF at the study level under the Protocol Deviations artifact.
• A site enters a participant in the EDC system under the wrong participant number.  Because the site does not have permission to delete a participant from the database, the Data Management group deletes the participant, capturing the action as a change control, which is filed in the TMF in the Data Management zone at the site level.
• Due to a programming error, an eCOA system calculates an assessment score erroneously for several participants. The issue is reported as a deviation, and after an investigation, the team decides to have the sponsor's statistical programming team recalculate the score. The plan is captured as a CAPA in the quality issue, and the execution is documented in an email ("All done"), which is filed in the Site Management zone of the TMF at the study level. 
• An IRT vendor's system does not permit sites to make changes to metadata (e.g., incorrect visit dates or participant numbers), so site staff contact the help desk to make the changes. The details regarding the change are captured in the help desk's ticketing system, which is not filed in the TMF.

We can see how these situations would need to be handled differently under R3. First, we would need documentation justifying these types of changes.  This could be done on a case-by-case basis as issues arise; however, taking the earlier requirement into account, it would be far better to have the DMP outline and justify every case where the sponsor or CRO might need to change data. 

Second, we would need documentation to be completed to show that the investigator agreed with each change before the change was made. It is not clear whether the investigators, as a body, could agree to broad categories of changes in advance, as they used to do with self-evident changes in systems where sponsors were entering all the data off of three-part NCR CRFs. For the young folks, "no carbon required" CRFs were three-layer paper forms--white, yellow, and pink--that made two copies on the layers underneath when the top layer was written on with a pen. CRAs had to source verify the forms and then pull them apart and hand-carry the pink and yellow copies back to the Data Managers, who would store the yellow copy and annotate the pink copies with any corrections they made to the database as a result of queries or "self-evident" corrections. 

It will be interesting to hear EMA inspectors' opinions as these cases are inspected.  Given that sponsor changes to data are not supposed to be routine, however, we would recommend a conservative approach of documenting investigator agreement on each individual change. To ensure adherence to ALCOA++ principles, we would also recommend a dated signature for each change.  

We also suspect it would be best to capture that dated signature before the change was made, rather than having the investigator sign off at the end of the study that they had agreed to the particular change, just so there is no ambiguity about the timing.

Ideally, this signature would be captured within the data capture system, so it is part and parcel of the audit trail - however, this is not a common function of most data capture systems, so it would likely be documented in a file note. To ensure retrievability, all file notes capturing investigator agreement to changes should be filed in the same place - not as they are in the examples above, where they are filed at different levels and in different zones of the TMF - or, in the last case, in help desk tickets that never made it to the TMF.

*Fun fact - NCR, which stands for No Carbon Required, is a "backronym," derived from the name of the company that invented it, National Cash Register.  A cash register was a machine that captured the amount of a sale and calculated the amount of change that was due to the buyer, based on the cash that was given to the seller.  Believe it or not, the machine also had a drawer to store the cash, because back in the day, even though we had credit cards, we only used them for big purchases, like airplane tickets.  Your forebears would have been embarrassed to pay for a Gatorade and a candy bar with a credit card.