eIDAS-Compliant eSignature for Clinic Consent Forms (2026 Guide)

eIDAS-Compliant eSignature for Clinic Consent Forms (2026 Guide)

EU Regulation No 910/2014 (eIDAS) defines the legal framework for electronic signatures across the European Union. For clinics using electronic consent forms, eIDAS determines what kind of electronic signature is legally sufficient, what evidence is required to support it, and what a compliant audit trail must contain.

The most important thing to understand is that eIDAS compliance is not a binary certificate or a product feature — it is a combination of the signature level you choose, the process you implement, and the evidence you retain. A platform that claims "eIDAS compliance" may mean SES (Simple Electronic Signature) with minimal evidence, or AES (Advanced Electronic Signature) with strong identity verification. These are not equivalent, and the difference matters for which consent use cases each level supports.

The Three eIDAS Signature Levels

Simple Electronic Signature (SES)

Definition: Any data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign. (eIDAS Article 3(10))

In practice: The broadest category. An email reply saying "I agree," a typed name in a form field, a signature drawn on a touchscreen, or a checkbox confirming acceptance — all qualify as SES if there is a reasonable connection between the signer and the electronic act.

Evidence typically retained:

• Email address the signing invitation was sent to
• Timestamp of the signature event
• IP address and device type at time of signing
• Document hash (to prove the document wasn't modified after signing)

Legal standing: SES signatures are legally valid under eIDAS Article 25(1) — they cannot be denied legal effect solely on the grounds of being in electronic form. However, they do not carry the evidential presumption of authenticity that AES and QES carry.

When SES is appropriate for clinic consent:

• Routine patient registration agreements
• Terms and conditions of service
• Standard privacy notices and GDPR consent
• Follow-up and reactivation consent
• Non-clinical administrative agreements

Advanced Electronic Signature (AES)

Definition: SES that additionally satisfies the requirements of eIDAS Article 26: uniquely linked to the signatory, capable of identifying the signatory, created using data under the signatory's sole control, and linked to the signed data such that any subsequent change is detectable.

In practice: AES requires stronger identity verification before signing. Common implementation: OTP (one-time password) sent to the signer's verified phone number before they can access and sign the document. This provides "sole control" evidence — only the person with access to that phone could have completed the signing.

Evidence typically retained: All SES evidence, plus: OTP delivery confirmation and entry event; signer phone number match against patient record; certificate chain if a signing certificate is used.

Legal standing: AES carries a higher evidential weight than SES. Under eIDAS Article 25(2), qualified electronic signatures (QES) have the equivalent effect of a handwritten signature — AES approaches but does not equal this presumption. In most EU member states, AES is considered strong evidence of signer identity in civil proceedings.

When AES is appropriate for clinic consent:

• High-value clinical consent forms (surgical consent, high-risk procedure consent)
• Consent where signer identity is legally significant (anaesthesia consent, mental health treatment authorisation)
• Consent for sensitive treatments where disputed identity could create liability
• Staff employment agreements and contractor agreements
• Supplier and partner contracts

Qualified Electronic Signature (QES)

Definition: AES created by a qualified electronic signature creation device and based on a qualified certificate for electronic signatures. (eIDAS Article 3(12))

In practice: Requires a qualified trust service provider (QTSP) to issue a certificate to the signer, involving identity verification equivalent to in-person ID check. This is the most rigorous level — and the most complex and expensive to implement.

When QES is appropriate for clinic consent:

• Notarially significant documents
• Cross-border legal agreements requiring the highest evidential certainty
• Situations where the identity of the signer must be unambiguously established for legal proceedings

For most clinical consent, QES is disproportionate to the risk. AES is generally sufficient for high-risk clinical consent; SES is sufficient for routine agreements.

What Makes a Consent Form Audit Trail eIDAS-Consistent

An audit trail for an eIDAS-consistent consent form must include, at minimum:

Event	Required record
Document sent	Timestamp, recipient email, document version hash
Document opened	Timestamp, IP address
Identity check (AES only)	OTP sent timestamp, OTP verified timestamp, phone number used
Signature applied	Timestamp, signature data, IP, device, document hash at signing
Document sealed	Final document hash (proves no modification after signing)
Document stored	Storage location, retention reference

Every event in this chain should be immutable — once recorded, it cannot be altered. The immutability is what gives the audit trail its evidential value. A system where administrators can edit timestamps or signature events produces audit records that are not credible evidence.

Consent Form Implementation Controls

Template version control

Consent forms must be versioned. When a clinical practice or legal requirement changes the content of a consent form, the new version must be:

• Dated and versioned (v1.2, effective 2026-03-01)
• Stored separately from prior versions
• Linked to each signed record (which version did this patient sign?)

A patient who signed version 1.1 in January and returns in May has not signed version 1.2, which may contain different risk disclosures. The clinic needs to know which version each patient signed.

Signer identity context at form delivery

The consent form should be delivered to a verified channel — the patient's confirmed email address or phone number — not to a generic link that anyone could access. The delivery event creates the identity chain: the invitation was sent to the registered contact, which establishes a reasonable connection between the signer and the account holder.

Retention and accessibility

Signed consent records must be:

• Retained for the applicable clinical records period (typically 8–10 years for adult patients, longer for minors, depending on the EU member state)
• Accessible for data subject access requests (the patient can request their signed consent records)
• Accessible for regulatory audit (professional registration bodies or health regulators may request consent records)

Setting Up in Tregovia

Tregovia's Contracts eSign module (EUR 15/month) implements AES-level electronic signatures for clinic consent forms:

• SES by default: Signature with timestamp, IP, device, and document hash
• AES upgrade: Optional OTP verification step before signing — configurable per template
• Template versioning: Full version history; each signed record links to the specific version signed
• Immutable audit trail: All events recorded with timestamp; no edit capability for audit records
• Identity confirmation: Signer verifies date of birth or staff-assigned identifier before accessing form
• Retention: Configurable retention period per template type; deletion workflow at end of retention
• processor terms: Data processing agreement review recommended; consent data processed in the EU

Pricing: Contracts eSign module EUR 15/month flat rate for envelope and template workflows. Base plan EUR 47/month.

FAQ

Is eIDAS compliance only a technical issue?

No. The technical platform provides the mechanisms — timestamping, document hashing, audit logging — but compliance also requires governance and documented procedures. A technically capable platform used without version control, without defined retention policies, and without training on the exception workflow is not compliant in practice. The clinical governance lead and the compliance owner need to own the procedures; the technology supports them.

What should clinics validate before going live with electronic consent?

Three things: the identity flow (test that the identity verification step works correctly and that the audit trail captures it), the audit export quality (generate a test audit report and confirm it contains all required events in a usable format), and the exception handling (test what happens when a patient cannot complete the form online — is the exception workflow documented and functional?). Go-live should be conditional on all three passing.

Which eIDAS level is appropriate for surgical consent?

AES is appropriate for most high-risk clinical consent including surgical procedures. The OTP-based identity verification provides strong evidence that the person signing is the patient (or their legally authorised representative), and the sealed document hash proves the consent text was not modified after signing. QES would add no practical clinical value for most surgical consent situations and would impose significant operational complexity on both the clinic and the patient. If your clinical governance lead or medical defence organisation advises QES for a specific consent type, follow that advice — but for standard surgical consent, AES is sufficient and proportionate.

Who owns compliance assurance for electronic consent?

The compliance lead owns the policy (what level of signature is required for which consent type, what retention period applies, what the exception workflow is). Operations owns the implementation (ensuring staff follow the policy, exceptions are documented, and the system is configured correctly). The system administrator maintains the technical configuration (template versions, signature levels, retention settings). This three-way ownership is intentional: no single person can both set the policy and verify their own compliance with it.

What is the most important audit artifact?

The end-to-end signature event record with immutable timestamps — specifically, the chain from document delivery through signer identity verification through signature application through document sealing. This chain is what a court, regulator, or professional registration body would request if consent were disputed. If any link in the chain is missing or editable, the evidential value of the consent record is compromised.