Skip to content

Backfill consent rows for existing patients with hipaa_allowsms=YES #113

@kojiromike

Description

@kojiromike

Problem

#111 closes the chart-driven opt-in gap going forward by listening on patient_data transitions and calling ConsentService::optIn(). It does not address patients who were already in the database with hipaa_allowsms=YES and phone_cell populated but no row in oce_sinch_patient_consent. Those patients remain blocked from AppointmentReminderService and any other service that gates on hasActiveConsent() until staff manually toggle the chart flag.

On the canary tenant this is the entire patient base — the consent table is empty and no reminders are being sent.

Desired outcome

A safe, idempotent way to record an opt-in consent row for every existing patient whose chart already indicates SMS consent, without sending a confirmation SMS to patients who never expected one (since the original consent was captured outside the module).

Acceptance criteria

  • After running, every patient with hipaa_allowsms='YES' and a non-blank phone_cell has a row in oce_sinch_patient_consent with opted_in=TRUE, opted_out=FALSE.
  • Patients with hipaa_allowsms='NO' or blank are not touched.
  • Patients who already have a consent row are not double-written or re-confirmed.
  • The opt-in confirmation SMS is suppressible for the backfill (one-time bulk action, not a per-patient consent capture).
  • Per-tenant invocation, with a dry-run mode that reports counts before writing.

Notes

Implementation shape (CLI command, migration, admin UI button) is open. Out of scope for #111 since the AC there only covers new transitions.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions