Consent Management Workflow in Clinic CRM (2026 Guide)

Consent Management Workflow in Clinic CRM (2026 Guide)

Consent management in a clinic CRM is the operational infrastructure that ensures the right consent exists before the right action is taken — and that when consent expires, changes, or is withdrawn, the downstream workflows respond accordingly.

The gap in most clinic consent management isn't the capture step. Most clinics have some process for collecting consent at registration or before treatment. The gap is everything that comes after: consent records are captured but not versioned, not linked to specific communication types, not checked before actions are taken, and not tracked for expiry. Marketing emails go out to clients who withdrew consent six months ago. Reminders are sent under GDPR Article 6(1)(b) contract performance basis without checking whether the reminder type requires separate consent. Clinical procedures proceed without confirming that the current consent version has been signed.

A properly designed consent management workflow in a clinic CRM treats consent as an operational input, not just an administrative record.

Consent Type Catalogue

The first step is defining what consent types the clinic actually uses. Different types of consent have different legal bases, different capture methods, different expiry rules, and different downstream implications:

Consent Type	Legal Basis	Channel	Expiry
Marketing email	Art. 6(1)(a) explicit consent	Opt-in checkbox at registration or standalone form	24 months from last interaction, or review annually
Marketing SMS	Art. 6(1)(a) explicit consent	Separate opt-in (can't be bundled with email)	24 months
Appointment reminders	Art. 6(1)(b) contract performance	No separate consent required for transactional reminders	No expiry while client relationship active
Clinical procedure consent	Art. 9(2)(h) health care	Signed form per procedure	Per procedure; some require re-consent if procedure changes
Photography/video consent	Art. 6(1)(a) explicit consent	Standalone form	Annual review recommended
Research or study participation	Art. 6(1)(a) + Art. 9(2)(i)	Separate research consent form	Per study period; withdrawal at any time
Data sharing with third parties (e.g. insurers, referral recipients)	Art. 6(1)(a) or Art. 9(2)(h) depending on recipient	Specific consent per sharing purpose	Per episode or ongoing depending on purpose

The catalogue defines the complete set of consent types the clinic manages. Every consent type should have a named owner — the staff member responsible for ensuring that the consent capture process works and that records are maintained.

Consent Capture Method and Evidence

For each consent type, define how consent is captured and what evidence is recorded:

Method options:

• Electronic form (online): Client completes and signs a form via the portal or a shared link. Audit trail includes IP, timestamp, document version, signature event.
• Electronic form (in-person on device): Receptionist provides a tablet; client signs in the waiting room. Same evidence as online.
• Paper form (scanned): Paper form signed at reception, scanned and attached to the client record. Evidence: scan with handwritten signature. Weaker than electronic but acceptable for regulatory purposes.
• Verbal consent (documented): For low-risk situations. Staff member records the verbal consent with timestamp, what was consented to, and who witnessed it. Weakest form; only appropriate where written consent is impractical and the risk is low.

Evidence requirements by legal basis:

• Art. 6(1)(a) consent must be demonstrable and specific — the system must record what the client consented to, when, and by what method. A checkbox ticked without retaining the record is legally insufficient.
• Art. 9(2)(h) clinical consent must link the consent record to the specific procedure or treatment plan it covers.

Consent Version Control

Consent forms change. Privacy policies are updated. Clinical risk information changes. GDPR requires that where processing is based on consent, the data subject can verify what they consented to — which requires that the specific version of the document they signed is retained and accessible.

Version control requirements:

• Every consent form should have a version number and effective date (e.g., "Patient Privacy Notice v2.3, effective 2026-01-15")
• Each signed consent record must reference the version signed, not just "Privacy Notice signed"
• When a new version is published, identify which existing clients have signed old versions — do they need to re-consent? (If material changes were made that affect the scope of consent, re-consent may be required under GDPR.)
• Old versions must remain accessible in the system — you cannot delete version 1.2 just because version 1.3 has been published

Expiry and Renewal Tracking

Consent has a practical lifetime. Consent given three years ago by a client who hasn't visited since may not reflect the client's current intentions. While GDPR does not mandate a specific expiry period for consent, the ICO (UK) and other data protection authorities recommend that consent is reviewed and renewed periodically.

Recommended expiry settings by consent type:

• Marketing email/SMS: Review at 24 months from last interaction; send a re-consent request before the record lapses
• Photography consent: Annual review
• Research participation consent: Per study period; consent expires when the study ends unless extended
• Clinical procedure consent: Per procedure; ongoing treatment plans may require annual renewal

The renewal workflow:

1. System flags consent records approaching expiry (configurable alert threshold, e.g., 60 days before)
2. Owner reviews the list: which clients need re-consent?
3. Re-consent request sent (email with clear description of what consent is requested and a link to confirm)
4. Non-respondents: remove from the applicable communication list; do not assume silence is continued consent

Enforcement in Downstream Workflows

Consent management is only operationally useful if the consent status is checked before the relevant action is taken. This is where most clinic consent systems fail — consent is captured but not enforced.

Enforcement points:

• Marketing email send: Before a bulk email campaign is sent, the system confirms that every recipient has active marketing email consent. Clients without active consent are excluded automatically, not manually filtered.
• Marketing SMS send: Same — active SMS consent required; separate from email consent.
• Clinical procedure booking: Appointment booking for procedures requiring specific consent checks that the current consent version is signed. If not, the consent form is sent before the appointment is confirmed.
• Data sharing with third parties: If a referral or data transfer requires specific sharing consent, the system confirms that consent is active before the data is shared.
• Communication on sensitive topics: Any communication that references clinical details (not just appointment logistics) should confirm that the appropriate clinical communication consent is active.

Automated enforcement at these points removes the reliance on staff memory and reduces the risk of consent violations caused by human oversight.

Audit Requirements

Every consent event must be logged:

Event	What to log
Consent given	Timestamp, consent type, version, method (electronic/paper/verbal), staff member if in-person
Consent updated	Timestamp, what changed, old and new version
Consent withdrawn	Timestamp, channel (e.g., "client emailed requesting removal"), downstream actions taken
Re-consent sent	Timestamp, channel, document version
Re-consent received	Timestamp, version signed
Consent checked before action	Timestamp, what action was being taken, consent status at time of check
Consent expired (no renewal)	Timestamp, downstream actions taken (removed from marketing list)

Every log entry should include the actor (who performed or triggered the action) and be immutable — once recorded, it cannot be edited.

Setting Up in Tregovia

Tregovia's CRM includes consent management across multiple modules:

Forms Intake module (EUR 15/month):

• Consent form templates with version control
• Online and in-person (tablet) capture modes
• Completion status per client, per form type
• Automated reminders for incomplete forms
• Audit trail for all consent events

Follow-up Sequences module (EUR 8/month):

• Marketing communication sequences automatically filtered by active consent
• Consent status checked at send time; non-consented contacts excluded
• Consent withdrawal processed immediately; client removed from active sequences

Contracts eSign module (EUR 15/month):

• Clinical procedure consent with eIDAS SES/AES signature capture
• Version control; each signed record linked to the specific version signed
• Expiry date per template; renewal workflow triggered before expiry

Core CRM (included in base plan):

• Consent status visible on client record
• Role-based access to consent records
• GDPR Article 15/17 export and erasure support

Privacy controls: Configure access roles, consent records, exports, deletion requests, and retention rules before publishing this workflow.

Pricing: EUR 47/month base plan flat rate, modules from EUR 8/month. 14-day free trial.

FAQ

Why is consent versioning important?

It proves which specific policy text the client accepted at a specific point in time. If a client disputes what they consented to — or if a regulator asks to see the consent records — the versioned record shows exactly what language was in the form they signed, on the date they signed it. Without versioning, the clinic can show that consent was given but cannot prove what was consented to if the form has since changed.

Should expired consent block downstream actions automatically?

Yes, for consent-required workflows. The system should not allow marketing communications to be sent to a client whose consent has expired — this should be an automatic block, not a manual check. For clinical workflows where consent is required, the appointment booking or procedure scheduling step should check consent status and flag or block if the required consent is missing or expired. The exception path (what happens when a client needs an appointment but hasn't re-signed their consent form) should be defined and workable — but the default should be enforcement, not bypass.

Who owns consent policy updates in a private clinic?

The compliance owner sets the policy (what consent is required for what activities, what the expiry periods are, what re-consent triggers look like). Operations implements the policy in the CRM configuration (template settings, enforcement rules, renewal workflows). The clinical lead is consulted when consent policy affects clinical workflows. Changes to consent policy that affect clients who have already given consent must be communicated to those clients — a unilateral change to what consent covers without re-consent is a GDPR violation.

What metric shows consent management maturity?

Expired-consent action attempts prevented — the number of times the system blocked an action (email send, appointment booking, procedure approval) because the required consent was absent or expired. Early in implementation, this number may be surprisingly high, revealing gaps that were not visible without automated enforcement. Over time, as the renewal workflows run and clients update their consents, the number should trend toward zero. A high and stable number suggests that the renewal workflow is not working effectively.

How should consent withdrawal be handled?

Immediately and comprehensively. When a client withdraws consent for marketing communications, they should be removed from all active marketing sequences within 24 hours — not at the next scheduled system sync, not at the next manual review. The withdrawal should be logged with timestamp and channel. Any pending communications to that client (scheduled but not yet sent) should be cancelled. Delayed processing of consent withdrawals is a GDPR violation and a client trust issue.