Procedure
Alert rules
Walks an administrator through defining the rules for when an alert fires, so the right event raises the right alert to the right people.
An administrator defines the rules that decide when an alert fires. A rule ties an event to the alert it raises and the people it reaches, so the right event raises the right alert to the right people.
An alert rule is a definition that raises an alert when a stated event occurs. The rule is the single place where the event, the alert and the audience are bound together.
Before you start
Defining a rule
- 1
Open the rule library
Open Sentinel and choose New rule. The library lists every rule already in force, with its state and its author, so you build on a known set rather than a blank page.
- 2
Name the triggering event
Choose the event that fires the rule from the catalogue of events the platform records: a critical result verified, a dose missed, a deposit running low, a process step overdue. A rule watches one event.
- 3
Set the condition
Add the condition that narrows the event to the cases that matter. You bound it by ward, by severity, by threshold, or by any attribute the event carries. The condition is stated in plain terms and shown back to you in words.
- 4
Choose the alert it raises
Set the alert the rule raises, with its title and its severity. The title is the line a member of staff reads first, so write it as the action needed.
- 5
Choose who it reaches
Set the audience by role and relationship rather than by name. A rule addressed to the nurse caring for this patient follows the roster, so the alert lands with whoever is on shift.
- 6
Group related alerts
Choose the key that groups related alerts under one thread. Grouping by patient and cause holds one incident as one thread, so a single cause reads as one matter.
- 7
Set the escalation chain
Set how long an alert waits for acknowledgement and who it reaches next. The chain is recorded with the rule. Read the mechanism in escalation.
- 8
Simulate before it goes live
Run the rule against recent activity to see what it would have raised. Reading the result before you publish holds a noisy rule out of the ledger.
- 9
Publish the rule
Publish the rule. From that moment it watches its event, and every alert it raises carries a line back to the rule that raised it, so an alert stays traceable to its cause.
Reach a role, not a person
Address a rule to a role and a relationship rather than to a named individual. When staff change or the roster turns over, the alert still reaches the person on duty, so a shift change keeps every alert with a live recipient.
Parts of a rule
event string Required | The recorded event that fires the rule. |
condition expression | The bound that narrows the event to the cases that matter. |
severity string Required | How urgent the raised alert is. |
audience role Required | The role and relationship the alert reaches. |
grouping string | The key that gathers related alerts into one thread. |
escalation chain | How long the alert waits and who it reaches next. |
Severity levels
Severity sets how urgently a raised alert reaches its audience. Choose it to match the harm a delay would carry.
| Severity | When to use it | How it is delivered |
|---|---|---|
| Information | A signal worth logging for review | Held in the ledger |
| Warning | A matter that needs attention this shift | Raised to the on-duty role |
| Critical | A matter that needs attention now | Raised at once and escalated if it waits |
Common questions
Where does a rule get its events from?
The platform records events as work happens. A rule watches one of those events and raises an alert when its condition holds.
How do I keep a rule from firing too often?
Simulate the rule against recent activity before you publish, and tighten the condition until it raises only the cases that need a person.
Can I address an alert to one named person?
Address a rule to a role and a relationship. The alert then follows the roster to whoever holds that role on shift.
Read how an unacknowledged alert climbs its chain in escalation.