Notification System – Overview

Asynchronous notification system that keeps users informed about lab report statuses, critical alerts, and important updates across the Crelio Health platform.

Overview

The Notification System provides a unified way to inform labs, doctors, and internal users about important events in Crelio Health. It delivers asynchronous (non‑real‑time) updates over multiple channels, all backed by a common data model and delivery pipeline.

• Browser Push Notifications – Receive alerts even when the app is closed (typically 1–10s delay via FCM)
• In‑App Notifications – Asynchronous updates within the app shell
• Notification Center / Inbox – Centralised place to view and manage all notifications

Note: This is not a real‑time notification system. Notifications are delivered asynchronously with typical delays of 1–10 seconds via FCM (Firebase Cloud Messaging), and in some cases additional processing delays depending on the underlying workflow.

Related JIRA Tickets

• Epic
  • EN-11322 – Notification System
• Backend & data model (examples)
  • EN-11323 – DB Schema Changes
  • EN-11318 – Preparing Master Data – Notification Types
  • EN-11364 – FCM Device and existing table changes
  • EN-11351 – User Logged In Token Generation & Saving
  • EN-11352 – User Refreshed the page & Update Activity
  • EN-11354 – Send Notification API & Fusion Call
  • EN-11355 – Get API for the Notifications list
  • EN-11357 – Read Notification Functionality
  • EN-11446 – Activity log for notifications & Subscribe to topic
  • EN-11448 – Delay Notification & Report Ready – re‑check statuses before sending
  • EN-11356 – Keep Mobile Notification Flexibility to the APIs
  • EN-11353 and related tickets – Unsubscribe/delete token on logout and session cleanup
• Frontend & UX (examples)
  • EN-11366 – Notification Inbox Implementation in UI
  • EN-11367 – Show unread count in sidebar
  • EN-11360 – Display Notification on the Frontend
  • EN-11368 – OrgReportReady – Open Review Modal
  • EN-11369 – Critical Report Notification
  • EN-11370 – Application‑level notification message
  • EN-11371 – Organisation Notification screen in lab login

For the full implementation breakdown and status, refer to:

• Whimsical: Notifications (MVP)
• Roadmap sheet: Roadmap 2026 – B2B & Finance

Prerequisites

At a high level, the following must be in place before the Notification System can be used end‑to‑end:

• Firebase / FCM setup

  • Firebase project created per environment (e.g. US‑UAT, production regions) with Firebase Cloud Messaging enabled.
  • Server credentials / service account JSON or FCM server key generated and stored as backend secrets.
  • Web/mobile apps configured with the correct Firebase web configuration (apiKey, projectId, messagingSenderId, appId, VAPID key, etc.).

• Database & master data

  • All notification‑related tables created and migrated (e.g. NotificationTypeMaster, LabNotificationTypes, Notifications, NotificationActivity, FcmDevices).
  • Seed/master data for notification types (Critical Report, Org Report Ready, Delay Notification, Application Message, etc.) loaded for each environment.

• Application secrets & environment variables

  • Backend environment variables for FCM credentials and feature flags (for example: project identifiers, credentials path/JSON, topic prefixes, NOTIFICATIONS_ENABLED or equivalent).
  • Frontend environment variables for Firebase web SDK configuration and public VAPID key.

• Secrets configuration (secrets.local.json)

  • A firebase_livehealth_frontend service account entry must be present in the backend secrets file (for example secrets.local.json), with at least the following keys:
    • type
    • project_id
    • private_key_id
    • private_key
    • client_email
    • client_id
    • auth_uri
    • token_uri
    • auth_provider_x509_cert_url
    • client_x509_cert_url
    • universe_domain
  • The actual values are environment-specific and must correspond to the Firebase project used for web notifications (see the firebase_livehealth_frontend object in secrets.local.json).

• Application/session integration

  • Login flow generates device tokens and sends them to the backend, which stores them and subscribes to appropriate topics (lab, organisation, role, doctor).
  • Logout and session‑end flows unsubscribe/delete tokens so devices stop receiving notifications when users log out.
  • Backend APIs for sending, listing, and marking notifications as read are deployed and reachable from the frontend.

For detailed frontend setup (dependencies, service worker, exact endpoint contracts), see the LiveHealth frontend prerequisites at /docs/product-engineering/features/notification-system/frontend/prerequisites.

---

Workflow Guide: For a step‑by‑step UI walkthrough of how users access, filter, and act on notifications in LiveHealth, see /docs/product-engineering/features/notification-system/frontend/workflow-guide.

What is it for?

The Notification System exists to:

• Surface time‑sensitive events

  • Alert users when critical reports are ready or when their status changes in ways that impact patient safety.
  • Inform users about report delays, organisation‑level announcements, and other important operational updates.

• Provide a central, auditable inbox

  • Give labs and organisations a Notification Center where all relevant messages are listed with read/unread status, timestamps, and activity history.
  • Maintain an audit trail for compliance and support.

• Standardise notification behaviour across modules

  • Use a single model for notification types, routing rules, delivery channels, and user preferences instead of ad‑hoc alerts in each feature.

• Respect user and lab preferences

  • Allow users and lab admins to enable/disable types, choose channels (in‑app vs push), and configure behaviour without code changes.