It pulls signals from every major module — appointments, labs, messages, payments, tasks, approvals, deliveries, and more — and surfaces them in a single, configurable experience.

Notifications are:

• clinic-aware (what the hospital cares about)

• role-aware (what your role must handle)

• user-aware (what you want to see and how)

The goal: the right person sees the right thing at the right time — without noise.

What Notifications Cover

Notifications can be generated by:

• Appointments & Online Booking

  • new bookings

  • cancellations

  • reschedules

  • no-show flags

• MsgBoard & Communications

  • new client messages

  • high-priority threads

  • RDVM messages via ReferralHub

  • MyPet messages requiring action

• Forms

  • new submissions

  • forms needing review

  • unsigned consent forms

• Labs & Diagnostics

  • new results

  • panic values (if configured)

  • results waiting DVM review

• Medications & Refills

  • refill requests

  • RXGuard advisory flags (for review)

  • controlled substance approval tasks

• E-DEA & Compliance

  • pending approvals

  • log discrepancies needing correction

  • failed logging events (where applicable)

• HomeDelivery

  • new delivery requests

  • ready-to-prepare

  • ready-to-dispatch

  • delivery completed

• Payments

  • payment failures

  • deposits received

  • refunds processed (if enabled)

• OurWork & Scheduling

  • PTO requests

  • shift swaps

  • schedule changes

  • missed or incomplete clockings

• MyTasks

  • task assignments

  • task escalations

  • overdue tasks

• ControlHub Events (Admin Only)

  • configuration changes

  • integration status issues (e.g., lab machine offline)

  • API key changes

Notification Layers

Notifications are structured in three layers to prevent overload:

1. System-Level (Clinic-Wide) Notifications

2. Role-Based Notifications

3. User-Level Preferences

1. System-Level (Clinic) Notifications

System-level alerts represent events the clinic as an entity must not miss.

Examples:

• lab integrations down

• payment processor connection issues

• controlled substance logging failures

• critical automation failures

• queue backlogs (e.g., too many pending refills)

Configured in ControlHub → Global / Clinic Settings and visible to admins and designated leaders.

2. Role-Based Notifications

Role-based notifications are tied to what a role is responsible for, not a person.

Examples:

• DVMs → lab reviews, refills, critical clinical questions

• Technicians → prep tasks, callbacks, workflow steps

• CSRs → bookings, arrivals, discharges, payment issues

• Managers → PTO/shift swaps, staffing alerts, compliance tasks

• Admins → system events, configuration, integration issues

This ensures work routes to the right bucket before it hits the individual.

3. User-Level Preferences

Each user can control how they receive notifications (and some of what they receive), without breaking clinic safety rules.

Users can configure:

• which channels (banner, sound, email)

• which categories to mute (e.g., non-urgent financial alerts)

• which task types they want top-priority

• snooze rules (e.g., pause non-critical alerts during surgery)

Clinically or legally critical notifications cannot be fully disabled — they’re safety-related.

Where Notifications Appear

Notifications surface in multiple, consistent places:

• Global Notification Center — the main “Notifications” page

• Top-bar Notification Icon — quick access to recents

• MyTasks — when an alert requires action

• MsgBoard — inline within conversations

• CaseFolder — as part of the patient’s care history

• Module-Specific Context — e.g., inside HomeDelivery or ReferralHub

Clicking a notification takes you to the relevant context (visit, message, task, workflow, etc.).

Notification Types & Behavior

1. Informational

• Example: “New appointment booked for Max at 3:00 PM.”

• Marked as low urgency.

• Can be muted per user if clinic policy allows.

2. Actionable

• Example: “New refill request for Luna requires approval.”

• Tied to a task or workflow.

• Opens directly to the action screen.

3. Critical / Safety

• Example: “Panic lab value detected,” “Controlled substance log mismatch.”

• Cannot be fully disabled.

• Escalates until acknowledged by an appropriate role.

How Notifications Work (End-to-End)

1. Event Occurs

   • client sends a message

   • lab result arrives

   • controlled prescription awaits approval

   • HomeDelivery reaches dispatch stage

2. Routing Rules Apply

   • system-level filters (clinic)

   • role-level rules

   • user preferences

3. Notification is Created

   • flagged with type (informational/actionable/critical)

   • tagged with patient/client/context

4. User Sees Notification

   • in the Notifications page

   • via top-bar icon

   • via email (if enabled)

   • via in-context banner

5. User Acts or Dismisses

   • complete task / review / approve / respond

   • or mark as read / dismiss

6. Event is Logged

   • action recorded in CaseFolder

   • audit trail updated

Notification Settings & Control

Clinic-Level Control (ControlHub)

Admins configure:

• which events generate notifications

• default notification behavior per role

• escalation behavior for critical alerts

• which categories are mandatory vs. optional

User-Level Settings

Users can:

• turn categories on/off where allowed

• choose channels (banner/sound/email)

• prioritize specific types (e.g., “Labs always top”)

• snooze non-critical notifications during certain workflows

Mute & Snooze

• Mute: turn off certain non-critical categories until re-enabled.

• Snooze: temporarily silence during surgery, rounds, or deep work.

Critical alerts are not affected.

Example in Action

A lab result returns with a critical potassium value.

1. Lab interface sends results into ClinicOS.

2. Notification engine recognizes a panic range.

3. A critical notification is generated for:

   • the assigned DVM

   • backup on-call DVM (if configured)

4. DVM clicks notification → taken directly to lab result in CaseFolder.

5. DVM reviews, contacts client, updates the plan.

6. Notification is marked as resolved once documented actions are complete.

7. Entire sequence is logged for audit.

No emails buried. No “I didn’t see it.” No guessing.

Integrations

MyTasks

Actionable notifications often create or link to tasks.

MsgBoard

Communication-related notifications open directly into the right conversation thread.

Forms

Forms that complete or require review trigger notifications to responsible roles.

Online Booking

New bookings and changes trigger configurable notifications to front desk or care team.

HomeDelivery

Each delivery stage can notify the appropriate team members.

ReferralHub

New referrals, RDVM questions, or updates generate targeted alerts.

ControlHub

Admins manage notification defaults and escalation logic here.

CaseFolder

Notifications involving a specific case are logged as part of that patient’s journey.

Why Notifications Matter

For Clinics

• fewer dropped balls

• faster reaction to critical events

• clear audit trails

• reduced dependency on inboxes and memory

For Teams

• clarity on what needs attention

• reduced noise when tuned correctly

• safer handoffs

• accountability without constant micromanagement

For Clients

• timely responses

• faster action on critical issues

• more consistent communication

Notifications turn chaos into a controlled signal system.

Important Notes

⚠️ Notifications are prompts, not decisions.

They highlight what needs attention — they do not replace clinical judgment, operational policy, or legal requirements.

⚠️ Critical notifications cannot be fully disabled.

ClinicOS is designed to protect patients, teams, and compliance.

⚠️ Clinics are responsible for configuring notification rules appropriately.

Misconfiguration of alerts, escalation paths, or roles remains the clinic’s responsibility.

⚠️ Email/sms notifications depend on external providers.

Network or provider outages can delay email/SMS, but in-app notifications will remain available.