Exploring Alternatives to Investigators Signing eCRFs

KCR Chief Technology Officer, Doug Bain

For over 25 years, EDC vendors have provided the means for investigators to electronically sign eCRFs within an EDC system to say that they confirm the integrity of the data that has been entered. The need to do this dates back to before EDC and eCRFs, when paper CRFs were wet ink signed. Regulations have attempted to apply the principles of the wet ink signature to EDC and eCRFs. This has been further expanded and detailed in Guidelines from EMA (March 2023).

Here are the questions often asked as a result:

• when should an investigator electronically sign?
• what should the scope of the signature be?
• does the investigator actually need to sign at all?

Current regulations

We have two major regulations that define this from the EMA and FDA. In each case, we also have ‘guidance’ documents that go beyond the regulations and describe how regulators will typically interpret the regulations.

For the EMA, we have ICH E6 R2. Section 4.9.1; it indicates that

“The investigator should ensure the accuracy, completeness, legibility, and timeliness of the data reported to the sponsor in the eCRFs and in all required reports.”

In addition, section 8.3.14 requires the maintenance of the signed/dated and completed eCRF, at site and at sponsor, to document that the investigator or authorized member of the investigator’s staff confirms the observations recorded.

Of course, like all regulations, they are open to interpretation. The last statement permits an authorized member of the investigator’s staff — to be delegated responsibility if trained accordingly — so potentially not the investigator.

A quote from the definition of an electronic signature, according to the EMA is as follows:

“Whenever ICH E6 requires a document to be signed and an electronic signature is used for that purpose, the electronic signature functionality should meet the expectations stated below regarding authentication, non-repudiation, unbreakable link, and timestamp of the signature. The system should thus include functionality to:

• authenticate the signatory, i.e. establish a high degree of certainty that a record was signed by the claimed signatory;
• ensure non-repudiation, i.e. that the signatory cannot later deny having signed the record;
• ensure an unbreakable link between the electronic record and its signature, i.e. that the contents of a signed (approved) version of a record cannot later be changed by anyone without the signature being rendered visibly invalid;
• provide a timestamp, i.e. that the date, time, and time zone when the signature was applied is recorded”

The EU — Guideline on computerized systems and electronic data in clinical trials (March 2023) includes guidance on when to ‘Sign-off Data’ (section 6.3). This is very specific and makes it clear that signing at the end of the study is considered insufficient. This goes beyond the FDA guidance. It even goes as far as stating that batch signing may not be adequate. The guidance continues by stating that the investigator should carry out ongoing reviews of the quality of the data.

EDC system support

EDC tools do not typically facilitate an investigator review. For this to function, the system would need to maintain records of what has and what has not been reviewed by the investigator, AND the investigator would need to provide an input to confirm their successful review (checking a box at item, form, or visit level).

Would the eSign process be a sufficient record of a successful review? This depends on the scope of the signature. If the scope covered a large group of pages, then there is no way to determine that the investigator did in fact look at any particular data prior to signing.

In September 2013, the FDA published the “Guidance for Industry on Electronic Source Data in Clinical Investigations,” and indicated that to comply with the requirement to maintain accurate case histories, clinical investigator(s) should review and electronically sign the completed eCRF for each subject before the data are archived or submitted to the agency.

Site, patient, visit, form or field signing?

It is very difficult to operationalize investigator signatures.

When should an investigator (or delegate) sign? Should they sign each patient? Should they sign each eCRF page? Can the eCRF implementation meet all sites modes of work where an investigator may only have small segments of time to carry out a signing activity? If the investigator (or signing delegate) enters the data themselves, what is the actual benefit of an eSign by that same person?

From a technical perspective, good EDC systems tend to implement a signature with a configurable scope. This means when the study builders sit down, they configure the study to be signed to a pre-defined scope of eCRF page, group of eCRF pages, visit or patient.

However, things get more complicated when the study is running, and a signature is ‘broken’. This typically occurs when a datapoint value in scope of the signature is modified. This breaks the signature at the datapoint level, and this break bubbles up to the scope of the form or whatever the whole scope of the signature applies to.

This results in a task (or a counter increment) for the investigator to re-sign. This means as data changes, the investigator is requested again and again to re-sign data.

The question though is what MUST be signed for an interim lock, versus what should eventually be signed? Prioritization is next to impossible to determine.

Do Investigator signatures mean better quality data?

So — when an investigator logs into an EDC system and follows the flows to sign patients, visits, or forms, do they review all of the data in the scope of that signature? No evidence for or against their review is maintained and systems don’t typically audit trail a user ‘looking at data’. The only information recorded on the topic is that the investigator logged in and eventually signed.

Unlike monitoring or data management functions, no tools are specifically provided to the investigator to record when they reviewed any of the data. We have already determined that the investigator is unlikely or unwilling to repeatedly go through eCRFs to confirm the values entered by themselves or their delegates are correct.

There is simply no effective argument in enforcing a data review flow for the investigator prior to signature. As a result, EDC systems don’t provide them.

This means the investigator signature process is what might be referred to as a ‘box ticking’ exercise. It has next to no value. It does not truly assert that the data is any better than when it was originally keyed.

AutoSign(*) based on audit trailing and roles

All EDC systems on the market today are provided with audit trails. This allows them to meet ALCOA. Typically, this is to meet the regulatory requirements for 21 CFR Part 11, but EU regulations also define what constitutes as electronic audit trail.

Those reading the above article that are familiar with the technical definition of “proof of an eSignature” will note that this is very similar in form to “proof of data change.” Both store and achieve the same thing. The only real difference between an audit trail record and a signature record is that the meaning of the signature is different. Audit trails assert a record of change. Signature records assert a confirmation of the data previously entered and audit trailed.

For data to be entered or changed, a user must login and maintain an active session. This provides irrefutable proof that the entry or change is made by an authorized person. If the person that is making the entry or change of data is also the person that is approved to sign the data, then why does the entry not also constitute the electronic signing of the data?

On this basis, provided the person entering is the investigator or a confirmed delegate for the investigator, there is no technical reason that the system could not stamp the audit trail as an eSigned change.

If, at the foot of the eCRF, a statement is added for autosign enabled systems, that data entered or revised will be automatically eSigned. Then, the regulations are not only achieved, but they are actually exceeded as they confirm the signed integrity of every add or change to each datapoint individually. A group of fields is then signed as a roll-up of the fields. A form is signed as a roll-up of groups, a visit is signed as a roll-up of forms in that visit and patients are signed as a roll-up of signed visits.

What about a signing session?

A definition exists for a ‘signing session’ in an FDA guidance. This explains that a person required to perform eSigning need only enter their two-part credentials (username / password) once within a ‘signing session’. This is to avoid the user having to enter their username and password 50 times to sign 50 pages.

If an investigator logs in, they are beginning a signing session. Once they have finished, they logout. Their active session is a signing session and therefore beyond their username / password entry at the start, they do not need to re-enter their credentials. They can enter and change data (potentially with Reason for Change). Combined with autosign, they are entering, changing and eSigning data at the same time.

Data review

The one potential problem area in applying an autosign method within EDC is verifying the definition of a ‘review’ in the guidance. It could be argued, as part of a risk-based assessment when designing a clinical trial, that provided the staff entering the data are classed as sufficiently trained to review the data, then these members of staff would qualify for both entry/change and review. As such, autoSign might be applicable. Therefore — based on specific role definitions and a risk statement, an autoSign method might adequately be applied to meet both regulations and guidelines.

Fit for purpose?

With regards to supporting eSignatures, the majority of EDC products specifically (but extending to other source data solutions such as eCOA,) are not sufficiently supportive when it comes to meeting the regulations and guidelines set out by the FDA and EMA as of March 2023.

EDC has implemented many overlapping methods of data checking and cleaning from edit checks to dynamic forms, monitoring data review, source data verification, data management review and medical monitoring review. When applied in comparison to the data quality checking in EHR system, this is vastly extensive.

Conclusion

Maybe the answer to the problem, if a problem does indeed exist, is not to add more ‘eyes’ to the data review cycle.

The exhaustive, and exhausting technologies that are provided to sites to run clinical trials undoubtably result in systems usage being delegated to more junior staff. This may be conjecture, but this could result in a greater need for a review of the integrity of the reported data by the investigator. This may be where the regulators are coming from.

To fix this, let’s try and do better with less, rather than adding more and more layers of inefficiency. Maybe it is time that regulators recognize the root cause of quality and efficiency problems — the prevalence of disconnected single study technology solutions for sites.

Regulatory guidance is necessary against sponsors that ask sites to use multiple disconnected systems on each single trial. This common approach is not just inefficient but leads to reductions in quality and oversight.

About the author: KCR Chief Technology Officer, Douglas Bain, is responsible for the technology strategy for all KCR group entities. He comes to KCR with over 30 years of experience in the development and implementation of clinical trial technology solutions. Prior to joining KCR, Bain worked for eRT, Medidata and eClinicalHealth, specializing in next-generation clinical trial/patient and site engagement technology.