Consent Service
Component Detail
Description
Business logic layer for all consent lifecycle operations including gate evaluation, grant recording, version upgrade detection, coordinator paper-override, and GDPR-compliant withdrawal. Checks the assignment_consents table before any sensitive field is rendered and flags re-consent requirements when organization_settings contains a newer template version. Enforces role constraints so only coordinators can record paper-override entries.
consent-service
Sources & reasoning
Consent gate evaluation, version-aware re-consent detection, GDPR withdrawal, and coordinator override enforcement are non-trivial business rules that must be centralized. Scattering these checks across the UI or the assignment dispatch feature would create audit gaps and bypass risks for sensitive health data governed by GDPR.
No source references — this artifact was included based on reasoning alone (see above).
Responsibilities
- Evaluate whether a valid (non-revoked, current-version) consent exists for a given assignment and consent type
- Persist grant, paper-override, and revocation records to assignment_consents with full audit metadata
- Compare stored consent version against current template version from organization_settings and trigger re-consent flow on mismatch
- Enforce coordinator-only access for paper-override path via role check against role-based-access-control
- Execute GDPR withdrawal by setting revoked_at and notifying upstream screens to hide sensitive data
Interfaces
checkConsent(assignmentId, consentType): ConsentStatus
grantConsent(assignmentId, consentType, version): ConsentRecord
recordPaperOverride(assignmentId, consentType, auditNote): ConsentRecord
revokeConsent(consentId): void
getPendingReconsentItems(userId): Assignment[]
getConsentHistory(assignmentId): ConsentRecord[]
Relationships
Dependencies (3)
Components this component depends on
Related Data Entities (2)
Data entities managed by this component