Data Model
Database schema and core tables used by the Notification System backend.
👤 Development Team📅 Updated: Mar 16, 2026📁 Services🏷️ notifications🏷️ backend🏷️ data-model🏷️ schema
Data Model
The Notification System relies on a set of dedicated tables to model:
- Notification types and configuration
- User and lab preferences
- Individual notification instances
- Read/unread activity
- FCM device tokens
Entity-Relationship Diagram
The following ER diagram (also shown in the main Notification System overview) captures the core tables:
Table Overview
-
NotificationTypeMaster
- Catalogue of all notification types supported by the system.
- Fields capture category, name, description, and default message parameters.
-
LabNotificationTypes
- Lab-level configuration for each notification type.
- Controls whether a type is enabled/disabled and lab-specific message parameters.
-
UserNotificationPreferences
- Per-user overrides on top of lab defaults.
- Used to honour user-level opt-in/opt-out and preference management.
-
Notifications
- Stores each generated notification instance (who it is about, payload, when it was created).
- Links back to the lab-level notification type.
-
NotificationActivity
- Tracks per-recipient activity (e.g. when a notification was read).
- Used to derive read/unread status and audit trails.
-
FcmDevices
- Maps FCM device tokens to lab users/doctors and session keys.
- Stores topics subscribed for each device and last activity time.
These tables underpin the APIs described in the API Reference.