Investigator electronic signature

An electronic signature is a legally significant confirmation by the investigator (PI) that the data under their responsibility is correct. It is designed for the requirements of 21 CFR Part 11: what is signed is not a “checkbox” but a specific snapshot of the data, and the signature automatically loses force if that data is later changed.

Signatures are available to those who hold the signature.apply permission at the site (@ SI) — usually the principal investigator and sub-investigators. Coordinators and monitors do not sign data.

0:000:00

The PI's electronic signature: the meaning, choosing coverage with a cost preview, and re-authentication

A signature is not a 'task sign-off'

A PI signature captures the state of the data at the moment of signing and stays in history forever. Even an invalidated signature is not deleted — it is needed to reconstruct the full picture of “who confirmed what, and when”. This is the key difference between an electronic signature and an ordinary “acknowledged”.

What exactly you are signing

Every signature has three components. They are worth understanding, because all three go into the signature record and the audit trail.

Signature meaning

Before signing, you choose the meaning — an option fixed in the design that explains what your signature means. The meaning is not a free-form phrase but one of two canonical options:

Meaning	What it confirms
Responsibility for data	“I accept responsibility for this data” — the data under the PI’s responsibility
Review / approval	“I have reviewed and approve this data” — the fact of a medical/process review

The meaning text is shown in your language, but a canonical code is what goes into the signature record — so changing the interface language does not change the legal meaning of what you signed.

Coverage

Coverage is the scope of data that the signature spans. In the signing dialog you pick one of three options, and next to each you immediately see its “cost” — how many forms it will cover and how many of them are already signed:

• This form only — a single completed form (FormInstance);
• All forms of this visit — all forms of one subject visit;
• The entire casebook of the subject — the subject’s entire dataset (all visits and forms).

Below the choice the system shows a line like “One Part 11 act will cover N forms” and a list of the exact forms with their statuses — you sign deliberately, not “blindly”. Signing the entire casebook is a single Part 11 act over the whole subject; it requires the signing permission at the subject scope, otherwise that option is disabled in the dialog.

Data snapshot

At the moment of signing, the system computes a cryptographic digest (covered_hash) of all covered values. It is what makes the signature unambiguous: it always shows whether the covered data changed after signing — and it is what triggers automatic invalidation.

How to sign data

Signing is done on the form page, not in the queue. The signature queue is only a list of “what awaits signing”; each row leads to the form where you sign.

1. Open the study signature queue (or go to the relevant form directly). A queue row opens the form via the “Open form” link.

2. On the form, choose the coverage: form, visit, or the whole casebook. In the preview, check exactly what falls under the signature.

3. Read the meaning of the signature in the signing dialog.

4. Complete re-authentication: re-enter your password and/or confirm sign-in via MFA. This is a separate identity check — an active session is not enough.

5. Confirm the signature. The system creates a signature record (SignatureRecord) with your name, the meaning, the data snapshot, and a UTC timestamp. A signature badge appears on the covered forms.

Why re-authenticate for every signature

21 CFR Part 11 requires that each act of signing be confirmed by a signer’s factor — a password and/or a second factor. So even in an open session the system asks you to re-authenticate. Several failed attempts temporarily block signing and are recorded in the audit.

Automatic invalidation

This is the signature’s most important property. Any change to covered data — by anyone, including a coordinator or a module — immediately invalidates the signature.

Changing data breaks the signature — this is irreversible

Signature invalidation cannot be disabled or undone: it is a built-in platform invariant. An invalidated signature is marked invalid, a core.signature.invalidated event is emitted, and the form returns to the signature queue — it must be re-signed. The record itself remains in history as a fact.

Several practical consequences:

• The signature is whole, with no “partial validity”. If you signed a casebook and then changed one field in one form — the entire casebook signature is invalidated. “A signature on 80% of the data” does not exist as a concept: legally, a signature is indivisible.
• Editing a covered form warns you in advance. When a coordinator tries to change a value covered by your signature, the system shows a “the change will invalidate the signature” warning — the edit is possible only after confirmation.
• Data changed between preview and signature. If, in the seconds between preview and confirmation, the data has changed, the system will not let you sign a stale snapshot — it shows the discrepancy and offers to review again.
• Open queries. By default, signing a coverage that has open queries shows a warning with a list; a study may configure this as a hard block.

The signature lifecycle is simple: it stays valid only until the covered data changes; any edit moves it to invalidated — terminally. Re-signing is always a new record, and the old one remains in history.

1. Validcovered value changes
2. Invalidated
   • re-signNew signature · valid

A signature is indivisible and terminal: editing any covered value invalidates it; re-signing is always a new record, and the prior one remains in history.

The signature queue

The signature queue (study page → Signature queue) collects forms that are complete (complete) and do not yet have a valid signature, and routes them to you by your signature.apply permission at the corresponding site.

• The list is grouped by subject; each row is a link to the form.
• If you have no signing permission anywhere in the study, the queue honestly tells you that signing is not your role (instead of a blunt access denial).
• Invalidated signatures automatically return forms to the queue — it is impossible to “forget” to re-sign.

Note

Re-authentication confirms precisely your identity as the signer. The signing permission can be temporarily delegated to a colleague through access administration, but a personal electronic signature is not delegated — signing is always done by a specific person under their own factor.

Next

Electronic signatures and Part 11The compliance view: 21 CFR Part 11 requirements and how the platform is designed for them.

Database lockInvalidated signatures are one of the hard-lock readiness items.

QueriesOpen queries affect the ability to sign a coverage.

AmendmentsMigration to a new design version invalidates the affected signatures.