Electronic Signatures and System Validation

Part of Clinical Data Management and Integrity: Audit Trails and Electronic Records.

About 5 minutes. Free, in your language, no account needed.

Why this matters

Two questions underlie every electronic record in a trial. Can we rely on the system that produced it, and can we rely on the signature that approved it?

Both have formal answers in regulation, most familiarly in 21 CFR Part 11 in the United States and in Annex 11 of the European Union's good manufacturing practice guidelines, with equivalent expectations elsewhere. The frameworks differ in detail and agree substantially in substance, and the substance is what a data manager needs.

Electronic signatures

A signature is a person's commitment to something: that they reviewed it, approved it, or are responsible for it. Electronically, three things must hold.

It must be uniquely attributable to one individual. Two components, typically an identifier and a password, with the combination belonging to one person and never shared. A signature applied from a shared account is not a signature.

It must be linked to the specific record, such that the signature cannot be copied to another record or survive the record being altered. The link is what makes it mean something about that content.

Its meaning must be recorded, and this is the one most often treated loosely. Reviewed, approved, authored and acknowledged are different commitments, and a signature whose meaning is not stated does not establish which was made.

The practical failure is the shared account, again. A coordinator signing with a supervisor's credentials because the supervisor is away has produced a record that asserts something false about who approved it, and the assertion is not correctable afterwards.

System validation

Validation is documented evidence that a system does what it is specified to do, consistently.

It is not a certificate, not a vendor's assurance, and not a one-time event. It has a shape:

The specification says what the system must do, in terms specific enough to be tested.

Testing demonstrates it does, including the failure cases, because a system that behaves correctly on good input and unpredictably on bad input is not validated.

Change control ensures a change does not silently invalidate what was demonstrated.

Periodic review confirms the system still behaves as validated, since environments change underneath applications.

The sponsor's obligation is not discharged by a vendor's validation package. A vendor validates its product; the sponsor must be able to evidence that its own configured instance, with its own edit checks, its own forms and its own user roles, does what it is supposed to do. That configuration is where study-specific defects live.

The configuration question

Most clinical data systems are configured rather than built, and it is the configuration that carries the study's logic: the forms, the checks, the derivations, the visit structure, the user permissions.

A defect here is a study defect, not a software defect, and it will not be caught by the vendor's testing.

The mundane version is most common. An edit check that compares the wrong two fields. A derived variable using the wrong denominator. A visit window calculated from the wrong anchor date. Each behaves consistently and produces wrong results consistently, which makes it far harder to notice than an intermittent fault.

In practice

A data manager takes over a study and asks for the user access list.

It has 340 active accounts. The study has 42 sites and has been running for two years.

Reviewing it against current staffing finds 61 accounts belonging to people who have left their sites, 14 belonging to sponsor staff no longer on the study, and 3 with permissions that allow data modification for every site rather than one.

Nothing has gone wrong. Every entry in the audit trail is attributable to a real account and the data is sound.

The exposure is that 75 people who should have no access have it, and three accounts could modify any participant's data anywhere in the study without that being unusual for their role. Access review is one of those controls that costs a day per quarter and is skipped because nothing visibly depends on it.

What this looks like when it goes wrong

A study's system calculates a derived variable, body mass index, from height and weight.

Height is collected in centimeters at most sites and in inches at three. The system's derivation assumes centimeters.

The derivation is consistent and produces a value for every participant. Nothing fails, no check fires, and the values at the three sites are wrong by a large and regular factor.

Validation testing exercised the derivation with centimeters and confirmed the formula. Nobody tested it with the alternative unit the form permitted, because the specification said the field was centimeters and the form allowed inches.

The defect is not in the calculation. It is in the gap between what the specification assumed and what the form accepted, and that gap is exactly where configuration defects live.

Key takeaways