Table Of Contents
| Table of Contents | ||
|---|---|---|
|
Introduction
@TODO
Configuration
...
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 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
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 | Originator | Status |
|---|
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.
- Originator: the name of the rule (or system, or module) that generated this 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.
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 | Status | Timestamp | UpdatedBy |
|---|
Where:
- Id: unique id of each entry.
- AlertId: the id of the alert this entry refers to.
- Status: the new status of the alert.
- Timestamp: when the alert status was changed.
- UpdatedBy: 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.