.. _report rules: =============== Report rules =============== Report rule (Report CC) model is used to define who should get copied on sent from the system. The rule model is tied to a single :term:`institution` and can group multiple recipients (:term:`users`), :term:`wards`, :term:`forms
`. .. seealso:: To understand how report rules behave with the level property, please refer to the :ref:`levels` documentation. Actions ---------------------------------------------- Defines which e-mail-triggering action will use this rule. Create Observation The chosen user(s) will receive an alert at the point a form is submitted, for the forms and areas chosen. .. note:: For advanced options like only triggering the alert based off certain criteria in the form please contact support@megit.com Edit Observation The chosen user(s) will receive an alert at the point a form is edited, for the forms and areas chosen. .. note:: For advanced options like only triggering the alert based off certain criteria in the form please contact support@megit.com Create Issue The chosen user(s) will receive an alert at the point an :term:`issue` is created. Edit Issue The chosen user(s) will receive an alert at the point an :term:`issue` is edited. Edit Issue Status The chosen user(s) will receive an alert at the point the status of an :term:`issue` is edited. Schedule The chosen user(s) will receive an alert at a scheduled interval (i.e daily, weekly, monthly). Schedules must be created in the schedule section of our settings area before adding them to a report rule. Received e-mail message For use with our "observation emails" functionality allowing 2 way communication from within MEG with an external email address contained in a form. The chosen user(s) will be alerted when an email is received. Ideal for patient feedback forms or incident forms where the staff member does not need a log in to MEG .. note:: Note: This is not an outright email offering, there can only be one email address per feedback form or incident Alert Triggered For use with our "smart alerts" functionality. This allows users to receive an alert when certain time sensitive criteria is met. For example, "7 Medication Incidents within a week" Target period For use with the "Target Notification" content type. A new target period is starting (or halfway through) for wards which have had targets configured. Content ---------- Which predefined e-mail content will be sent Public Report For use with create :term:`observation` and edit observation - (Advised for auditing) User will receive a confirmation email with a link to their submission report Summary Table Email For use with create :term:`observation` and edit observation - (Advised for incident management) User will receive an email with a link to the observation that has just been submitted. For example, A medication manager could receive an email when a medication incident is reported by any staff member. Issue Detail For use with our schedule functionality - users will receive a periodic email summarizing the :term:`QIP` issues linked to their account Blank For use when needing to send the content in note field in only QIP Update For use with Create Issue, Edit Issue, and Edit Issue Status - User can be alerted when certain aspects of :term:`QIP` happen for the chosen forms Summary of Reminders For use with our schedule functionality - users will receive a periodic email summarizing the :term:`QIP issues`, Scheduled Audits, Observation Reviews, and Documents with pending actions linked to their account Target Notification A notification summarizing ward target performance for monthly, bimonthly, quarterly and yearly targets. This notification can only be sent to :term:`ward managers`. For each target period an email is sent at the start and at the mid point of the target period. * Monthly target period: each calendar month. Start emails are sent on the 1st day. Mid point emails are sent on the 15th. * Bimonthly target period: January -> February, March -> April, May -> June etc. Start emails are sent on the 1st day of the 1st month in the period. Mid emails are send on the 1st day of the second month in the period. * Quarterly target period: January -> March, April -> June etc. Start emails are sent on the 1st day of the 1st month in the quarter. Mid emails are send on the 15th day of the second month in the period. * Yearly target period: Full calendar year, January -> December. Start emails are sent on the 1st January. Mid emails are sent on the 1st July. .. note:: The above schedule is configured in ``megforms.constants.TARGET_PERIOD_CRONTAB_MAP`` Recipients ------------------ Options for defining who shall receive the e-mail. Recipients Individual users who will receive this alert. Recipient Teams Teams who will receive this alert. All team members will receive the alert. Send to originator If enabled, the person who sent the initial submission will receive the alert. For submissions generated via :term:`web forms `, if the user is unauthenticated (or doesn't have access to the :term:`form` via ringfencing) the originator is the default :term:`auditor` of the :term:`web form`. If this user has an e-mail address and accepts e-mail notifications they will receive updates as the originator. If the user is authenticated and has access to the :term:`form` via ringfencing they can receive updates as the originator. Send to :term:`ward managers` The manager of the :term:`ward ` the :term:`observation`/:term:`issue` originated in will receive the notification. Schedule E-mails ------------------ Link to a schedule to trigger e-mails periodically Filter logic: -------------- Allows filtering-down observations included in the e-mail. For example: .. code-block:: json { "compliance_range": [0.0, 0.5], "observation_filters": { "operator": "and", "field": [ { "answer_operator": "=", "field": "field_1", "answer": "1" }, { "operator": "or", "field": [ { "answer_operator": "=", "field": "field_2", "answer": "2" }, { "answer_operator": "=", "field": "field_3", "answer": "3" } ] } ] }, "date_filter_field": "date_field", } one_off When set to ``true``, this option ensures that a notification for an ``Edit Observation`` action is sent **only once** per observation. This is useful for preventing repeated notifications if an observation is edited multiple times. For example, a manager can be alerted the first time an incident report is updated, without receiving further alerts for subsequent minor corrections. To use this feature: 1. The rule's action must be set to ``Edit Observation``. 2. The ``one_off`` key must be added to the filter logic and set to ``true``. Example of a simple ``one_off`` configuration: .. code-block:: json { "one_off": true } Example combined with other filters: .. code-block:: json { "one_off": true, "observation_filters": { "operator": "and", "field": [ { "answer_operator": "=", "field": "field_1", "answer": "1" } ] } } Config -------------- Allows custom configuration of the report rule. sms_link_format For SMS messages the default is to include a link to the :term:`observation` or :term:`issue` that triggered the report rule. You can override that by setting ``sms_link_format`` to ``"id"``. sms_custom_template For SMS messages allows you to fully customize the template used to send the sms message. The available template variables are * ``note`` : The report rule note * ``links`` : links to the observations or issues related to the report rule (may also be a list of ids if ``sms_link_format`` is configured). The below snippet shows how to configure these options: .. code-block:: json { "sms_link_format": "id", "sms_custom_template": "Your complaint is well received. We will get back to you within 5 working days {links}" }