Features
Notifications
The hard part of alerting is not sending. It is deciding what is worth a person's attention, routing it to somebody who can actually do something, and escalating when nobody does. Get the first part wrong and you have built an inbox everyone learns to ignore, which is worse than no alerting at all.
- Biomedical engineering
- Hospital operations
- Clinical engineering
What is the notification system?
Definition
Rydya notifications and escalation
The notification system turns meaningful events from every module into messages routed by role and assignment, delivered in-app and through configured channels, deduplicated against repeats, escalated when an acknowledgement does not arrive, and always constrained by what the recipient is permitted to see.
Two words carry the weight. Meaningful, because the alternative is emitting everything and calling the resulting noise transparency. And escalated, because an alert that nobody acknowledges is a fact the organisation has not learned.
It is driven by the same events that drive everything else, written to an outbox in the same transaction as the change they describe. There is no separate notification pipeline that can silently disagree with what happened.
Why alerting systems get muted
Because every alert costs attention, the cost is paid by someone other than the person who configured it, and nothing in the system ever charges for a false alarm.
Alert fatigue is not a discipline failure by clinical staff, it is arithmetic working exactly as it should. If a channel produces mostly things that do not need you, the rational response is to stop reading it, and people are rational. The volume is the problem; the muting is the symptom, and adding a policy about muting fixes nothing.
The second failure is routing to the wrong altitude. Sending everything to a manager because a manager is accountable produces a person who reads none of it, while the technician who could have acted in ten minutes finds out at the morning meeting. Accountability and capability are not the same thing, and notifications need the second one.
The third is the alert that goes nowhere and stops. Nobody acknowledges it. Nothing happens. The system has done its job in the narrowest possible sense: a message was sent. The device is still broken, the ward has worked around it, and the first anyone hears is a complaint two weeks later.
How an event becomes an acted-upon alert
Event, meaningful filter, routed by role and assignment, deduplicated, escalated on silence, and stopped when it is resolved.
- 1
A real event fires
From the outbox, written in the same transaction as the change it describes. A notification cannot exist for something that did not happen, and something that happened cannot silently fail to notify.
- 2
It is routed by role and assignment
To the people who can act, and to whoever it is assigned to. Not broadcast to a department, which is how an alert becomes everybody's to read and nobody's to action.
- 3
Repeats are deduplicated
The same fault does not generate the same alert every sweep. A queue that repeats itself is a queue people stop reading, and then the one that mattered is in there too.
- 4
Silence escalates
An alert nobody acknowledges is followed up and then escalated, on the configuration you set. This is the mechanism that converts a message into an outcome, and it is the piece most often missing.
- 5
Resolution stops the chase
Once the thing is acknowledged, attended or fixed, the reminders stop. An escalation that keeps running after the problem is solved teaches people that the escalation means nothing.
The rules that keep the queue readable
Each one exists because breaking it is how notification systems become wallpaper.
A notification never leaks scope
It carries only what its recipient is permitted to see, enforced by server-side permission checks and row level security rather than by careful message-writing. A notification is not a side channel around access control.
Severity is not decoration
Colour is never the only signal, and the semantic contract holds throughout: green is operational, amber is warning, red is fault. If everything is urgent then nothing is, and a system that inflates severity is training its own users to discount it.
Channels are configured, not assumed
In-app is real and always there. Email, push, webhooks and chat channels are configured by you, with secrets stored once and redacted thereafter, never displayed back.
Delivery is not a promise of attention
The system reports what it actually did: delivered, retried, failed, dead-lettered. A tick that means "we tried" is the kind of small dishonesty that costs trust the first time somebody checks.
When to add a notification, and who should decide
When somebody would do something differently on receiving it. That test removes most candidates, which is the point.
The instinct when configuring alerting is completeness: every event that could matter should reach someone. It produces a channel that nobody reads within a month. The better instinct is scarcity. Ask what the recipient would do differently, and if the honest answer is nothing, it belongs on a dashboard where somebody can go and look, not in a queue that interrupts.
The decision belongs to the people receiving them, not the people configuring them. A department that owns its own notification rules will prune them, because they feel the cost directly. Rules imposed from outside accumulate, because the person adding them pays nothing and the person reading them cannot say no.
Questions
How do you stop people muting the alerts?
By sending fewer of them. Alert fatigue is arithmetic rather than indiscipline: if a channel is mostly things that do not need you, ignoring it is the rational response. The useful test for any rule is whether the recipient would do something differently on receiving it, and an honest answer of "no" means it belongs on a dashboard rather than in a queue.
What happens if nobody acknowledges an alert?
It is followed up and then escalated on the configuration you set, rather than simply having been sent. An alert nobody acknowledged is a fact the organisation has not learned, and escalation is the mechanism that turns a message into an outcome. Once the thing is acknowledged, attended or fixed, the chasing stops.
Can a notification show someone data they should not see?
No. A notification carries only what its recipient is permitted to see, enforced by server-side permission checks and row level security at the database rather than by careful wording. Notifications are inside the isolation boundary, not a side channel around it.
Which channels are supported?
In-app is real and always present. Email, push, webhooks and chat channels are configured by you, with credentials stored once and redacted afterwards rather than displayed back. Delivery reports what actually happened, including retries, failures and dead-lettered messages, because a tick that means "we tried" costs trust the first time someone checks.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us