Skip to content

consent

Purpose

consent manages the platform's consent type registry and per-patient consent records. It exposes a REST API for recording and querying consent, and responds to consent.check.requested events from orchestrator by evaluating a patient's consent status and emitting consent.check.completed. This allows workflow steps to gate downstream processing on explicit patient consent.

Key endpoints

POST /v1/consent/patients/:patientId/consents — record a consent decision for a patient GET /v1/consent/patients/:patientId/consents — list consent records for a patient GET /v1/consent/patients/:patientId/consents/:typeCode/status — get the current consent status for a type GET /v1/consent/patients/:patientId/consents/check — check consent across multiple types POST /v1/consent/admin/consent-types — create a consent type GET /v1/consent/admin/consent-types — list consent types GET /v1/consent/admin/consent-types/:id — fetch a consent type PATCH /v1/consent/admin/consent-types/:id — update a consent type DELETE /v1/consent/admin/consent-types/:id — remove a consent type POST /v1/consent/admin/consent-types/:id/text-versions — add a text version to a consent type GET /v1/consent/admin/consent-types/:id/text-versions — list text versions for a consent type

Database tables

ConsentType — consent type registry (code, name, active status) ConsentTextVersion — versioned consent text for each type ConsentRecord — per-patient consent decision records (granted / withdrawn, timestamp)

Events

consent.check.requested — consume — received from orchestrator; evaluates patient consent and responds consent.check.completed — emit — published after evaluating a consent check request; includes granted boolean

Dependencies

  • Redis — event transport via @sa-platform/events Redis Streams (consume consent.check.requested; emit consent.check.completed)
  • MySQL — primary store, accessed via Prisma 7 driver-adapter pattern
  • auth — JWT verification via @sa-platform/auth-client

Where to learn more