...
This table contains the configuration about alerts. Each alert can be configured in a different way for each of the rooms in workspaces in an organization.
When an alert fires, its configuration is retrieved from this table using the room of the alert's source patient and the specific rule name that generated the alert.
The structure of this table is:
| Id | Name | Description | RuleNameKey | RoomIdWorkspaceId | SendNotification |
|---|
Where:
- Id: unique id of this configuration.
- Name: a decriptive name of this configuration.
- Description: a human friendly description of the configuration.RuleName: the
- Key: a system-friendly key for this configuration. In the case of alerts generated by a rule, this value is the name of the rule that this particular configuration belongs to.
- RoomIdWorkspaceId: The configuration is valid only for this roomworkspace. Different rooms workspaces could have different configurations.
- SendNotification: boolean value that specifies whether a notification should also be sent along with the alert.
If a rule is fired, and there is no particular entry in this table for the name of the rule or for the room workspace where the room rule got executed (this information comes from the patient that generated the alert), the alert is going to be generated without any specific recipient (user or role). This kind of alerts are only going to be visible to users with permission 'read_alerts_only_from_associated_patients'. Generally speaking, these alerts are intended only to the providers that are associated (currently or in the future) to the patient that generated it.
| Note |
|---|
| Because of a limitation in the current implementation, the combination between RuleName Key and RoomId WorkspaceId MUST BE UNIQUE. In the case of time-based rules, we may want to have different cron expressions for the same rule so, for example, we could have different recipients. The only workaround for this situation is to duplicate the rule in Survey Agent and give it a different name. Both rules could still share the same template id though. |
...
AlertConfigurationRoleRecipient Table
This table is an extension of AlertConfiguration table that allows to register specific roles as recipients for a specific alert.
The structure of this table is:
| Id | AlertConfigurationId | RoleId |
|---|
Where:
- Id: unique id of this entry.
- AlertConfigurationId: the id of the Alert Configuration where this recipient belongs.
- RoleId:the id of the targeted Role.
| Note |
|---|
| Roles with 'read_alerts_only_from_associated_patients' permission shouldn't have any entry in this table. These roles are going to omit this table and read straight from AlertPatient table. Entries for these roles in this table are thus redundant. |
TimeBasedAlertConfiguration Table
This table is an extension of AlertConfiguration that allows the configuration of alerts that are generated by a cron job instead of by the submission of a form. When the system starts-up, a Quartz job is created for each of the entries in this table. The job will be configured using the cron expression provided by this table and using the timezone of the facility where the associated Alert Configuration belongs to (given by the RoomId WorkspaceId column of AlertConfiguration).
The structure of this table is:
| Id | AlertConfigurationId | CronExpression | FactName | JobKey |
|---|
Where:
- Id: unique id of this configuration.
- AlertConfigurationId: the id of the Alert Configuration where this recipient belongs.
- CronExpression: the cron expression used to register a job in Quartz.
- FactName: This string is used by the time-based rules to know when they should be fired.
- JobKey: The Quartz job key associated with this entry. If this entry doesn't have a Quartz job associated, this value is null.
Entity Model
.png?version=1&modificationDate=1407921896520&cacheVersion=1&api=v2)
Alert Entries
Introduction
Whenever an alert rule is fired, one or more entries in the Alert table are inserted according to the configuration described in the previous section.
Alert Table
This table contains the specific data of an alert such as body, title, timestamp, etc. This table is the replacement of current 'alertticket' and 'alertstatus' tables. The patient/s associated to an alert are now placed in a separate table: AlertPatient.
The structure of this table is:
| Id | Timestamp | Title | Description | Payload | Priority | AlertConfigurationId | Status | Source | Originator | UserId |
|---|
Where:
- Id: unique id of the alert.
- Timestamp: the creation timestamp.
- Title: the title of the alert.
- Description: the description of the alert.
- Payload: any payload (as text) that the alert has.
- Priority: the priority of the alert. Possible values are: High, Medium, Low. These values come from an enum defined in the application and not from another table.
- AlertConfigurationId: the id of the AlertConfiguration entry that generated this Alert. The associated AlertConfiguration can be used to retrieve information such as the recipients of the Alert (users or roles) and the rule that originated the Alert.
- Status: the status of the alert. Possible values are: New, Read, Archived. These values come from an enum defined in the application and not from another table.
- Source: A string identifying the source of this alert. This is free text that can be used to display purposes.
- Originator: A string identifying the originator of this alert. This is free text that can be used to display purposes.
- UserId: the id of the user that generated this alert. In the case of time-based alerts, this value is NULL.
Alerts could be shared among different users. In this case, the status of the alert is also shared: when a user marks the alert as 'Read', the alert is now 'Read' for all the users sharing it.
AlertStatusAudit Table
This table serves as a log of how the status of an alert has changed in time.
The structure of this table is:
| Id | AlertId | StatusoldStatus | newStatus | Timestamp | UserId |
|---|
Where:
- Id: unique id of each entry.
- AlertId: the id of the alert this entry refers to.
- OldStatus: the old status of the alert (null when the alert is created).
- StatusNewStatus: the new status of the alert.
- Timestamp: when the alert status was changed.
- UserId: who (userId) updated the status of the alert.
AlertPatient Table
This table contains the different patients an Alert is related to.
| Id | AlertId | PatientId |
|---|
Where:
- Id: unique id of each entry.
- AlertId: the id of the alert this entry refers to.
- PatientId: the patient related to the alert.
Entity Model
.png?version=1&modificationDate=1407921876160&cacheVersion=1&api=v2)
Alert's Workflow
Alert Generation
.png?version=1&modificationDate=1408020031389&cacheVersion=1&api=v2)
Alert Retrieval
.png?version=1&modificationDate=1407234107170&cacheVersion=1&api=v2)