Skip to main content

Overview

The prescription notification system sends email and push notifications to patients when their prescriptions change status or when new requests are created. The system is designed to be simple, reliable, and compliant with notification delivery standards. Key Features:
  • Multi-channel notifications - Email and push notifications via SendGrid and Expo
  • Manual triggering - Notifications sent via direct edge function calls for precise control
  • Event-based system - Supports prescription status changes and request creation
  • Patient preferences - Granular control over notification types and channels
  • Marketing preferences - Separate opt-in for marketing communications
  • Clinic-based organization - Preferences organized by patient and clinic

Architecture

How It Works

1. Manual Notification Triggering

Notifications are triggered manually via direct calls to the prescription-notifications edge function from other edge functions:
  • Request Created: When a patient submits a reorder request via checkout-submit-order
  • Prescription Status: When prescription status changes via create-prescription-order
  • Manual Calls: Direct API calls for testing or administrative purposes

2. Event-Based Processing

The prescription-notifications function processes different event types:
  • request_created - New patient app requests
  • prescribed - Prescription signed by doctor
  • checkout_received - Prescription ready for patient review
  • dispatched - Prescription shipped
  • delivered - Prescription delivered

3. Multi-Channel Delivery

Based on patient preferences, notifications are sent via:
  • Email - Professional HTML emails via SendGrid
  • Push - Mobile notifications via Expo Push Service

Edge Functions

prescription-notifications

  • Purpose: Send email and push notifications for prescription events
  • Technology: Deno with SendGrid and Expo Push integration
  • Key Functions:
    • Patient preference checking
    • Email and push content generation
    • Multi-channel delivery
    • Notification event logging
Usage Example:

manage-patient-notifications

  • Purpose: CRUD operations for patient notification preferences
  • Technology: Deno with Supabase client
  • Key Functions:
    • Get patient preferences (GET)
    • Update patient preferences (PUT/PATCH)
    • Authorization checking (patient or clinic staff)
    • Default preference creation
Usage Example:

Email Templates

Status-Based Email Content

Email Template Configuration

SendGrid Template IDs:
  • request_created & checkout_received: d-5c933e93f5f246898b90dce3301cadab
  • prescribed: d-e5525d6f7afa49029fed564a54854b9a
Template Data Structure:

Push Notifications

Expo Push Integration

Push notifications are delivered via Expo’s push notification service:

Push Notification Content

Database Schema

Patient Notification Preferences

Automatic Preference Creation

When a new patient is created, default notification preferences are automatically created:

User Linking

When a patient creates a mobile app account, their notification preferences are automatically linked:

Database Triggers

Trigger Status: DISABLED

Database triggers for prescription notifications have been disabled as of migration 20250117_disable_prescription_notification_triggersNotifications are now handled manually via direct edge function calls for better control and to prevent duplicate notifications.

Historical Trigger Implementation

Previously, the system used database triggers to automatically send notifications when prescription status changed. These triggers have been disabled to prevent duplicate notifications and provide better control over notification timing. Disabled Triggers:
  • prescription_created_notification - Previously triggered on INSERT to prescription_orders
  • prescription_updated_notification - Previously triggered on UPDATE to prescription_orders
Migration Details:
The trigger functions (handle_prescription_created, handle_prescription_updated, send_prescription_notification) remain in the database but are no longer actively used.

Row Level Security (RLS)

Patient Access

Patients can view and update their own notification preferences:

Clinical Staff Access

Clinical staff can manage patient preferences within their clinic:

Preference Checking Logic

The notification function checks multiple preference levels:

Implementation Examples

Manual Trigger for Request Created

Manual Trigger for Prescription Status

Direct API Call for Testing

Status Change (Manual Trigger Required)

Managing Patient Preferences

Configuration

SendGrid Settings

  • Sender: welcome@adhdsimple.co.uk
  • Name: ADHD Simple
  • Authentication: SPF, DKIM, DMARC configured
  • Format: HTML emails with professional styling

Expo Push Settings

  • Service: Expo Push Notification Service
  • Authentication: Expo Access Token
  • Priority: High for prescription notifications
  • Sound: Default notification sound

Security Considerations

Authentication

  • All functions require valid JWT authentication
  • Service role key used for database triggers
  • Patient data access controlled by RLS policies

Data Privacy

  • Patient PII protected in notification content
  • Email and push events logged for audit compliance
  • Notification preferences isolated per patient and clinic
  • Marketing preferences require explicit opt-in

Notification Security

  • Email authentication via SPF, DKIM, DMARC
  • Push tokens securely stored and managed
  • Preferences cannot be modified by unauthorized users

Monitoring and Debugging

Check Notification Events

Edge Function Logs

Monitor the prescription-notifications function logs for:

Common Issues

  • Verify SendGrid API key is configured
  • Check patient has valid email address
  • Verify patient notification preferences are enabled
  • Check function logs for SendGrid errors
  • Ensure database triggers are disabled (migration 20250117_disable_prescription_notification_triggers)
  • Check that manual function calls aren’t duplicated in edge functions
  • Verify only one notification call per event
  • Check if email_events table exists and has correct permissions
  • Verify the logging doesn’t fail the main notification flow
  • Look for Email event logged: { error: {}, success: false } in logs
  • Verify clinic data is fetched and passed to notification function
  • Check clinic_snapshot field in prescription data
  • Ensure clinic_id is valid on patient record

Troubleshooting Guide

  1. Check Function Execution: Look for 🚀 === PRESCRIPTION NOTIFICATIONS FUNCTION INVOKED === in logs
  2. Verify Event Processing: Check for event-specific log messages like 📧 Sending email notification for request_created event...
  3. SendGrid Response: Look for 📮 SendGrid response status: 202 (success) or error codes
  4. Database Triggers: Ensure triggers are disabled to prevent duplicates
  5. Patient Preferences: Verify patient_notification_preferences table has correct settings

Future Enhancements

Advanced Scheduling

  • Notification frequency limits
  • Quiet hours by timezone
  • Custom notification schedules
  • Batch notification processing

Rich Content

  • Dynamic SendGrid template integration
  • Rich push notifications with images
  • Branded email template designs
  • Multilingual template support

Analytics

  • Notification delivery analytics
  • Patient engagement metrics
  • A/B testing for notification content
  • Delivery success rate monitoring
The notification system prioritizes reliability and patient control. All notifications respect patient preferences and provide granular control over notification types and delivery channels. Marketing communications require explicit opt-in and are separate from medical notifications.