Notifications - Push Reminders

Target release
Epic	Notifications
Document status	DRAFTED
Priority	HIGH
eLMIS Status	Partial Implementation, not in use
OpenLMIS Status	Partially Implemented
PATH	Jenny Thompson (Unlicensed)
OpenLMIS	Mary Jo Kochendorfer (Deactivated)
JSI	Ashraf

Goals/Scope

For a range of user-controlled SMS and email communications to be handled and tracked within OpenLMIS.

Status in eLMIS: Some automated email in use, other features (e.g., user-pushed communications) in eLMIS but not in use

Status in OpenLMIS: Automated email feature in OpenLMIS, other features (push reminders, SMS features) not in OpenLMIS

Priority: High priority

Background

An email notification feature is currently in use in eLMIS - this automatically sends emails as follows:

on authorisation, an email is sent to the approver to ask them to review/approve
on approval by the first approver, an email is sent to the second level approver (if applicable) to ask them to review/approve
when all approvals are complete for an R&R, an email is sent to the MSD sales officer for the zone (to remind them to convert the R&R into an order)

This feature can be turned on or off for particular users by the user administrator through a tick box “receive supervisory notification email” on the administration screen for that user. It is often turned off as users find the volume of emails too high, and logging into eLMIS to carry out the above approvals/orders work is part of their routine work.

There are currently no emails sent when R&Rs are rejected (to the facility/district who submitted the R&R), although users have said this might be more useful than the above approval notifications.

See the “communications features” section above which describes the current automated email notifications of R&R authorisations/approvals which are in use in eLMIS in Tanzania. Some users request the user administrator to turn this off because the volume of notifications is too high, and the notifications simply remind them to do tasks which are part of their routine work in any case. Users say that it would be more useful to send automated notifications of R&R rejections to the facility/district who submitted the R&R.

In addition there is an email and SMS feature which is in development in eLMIS but not yet completed or in use. This comprises a link from the “reporting rate” report which leads to an interface where the user can manually push reminders to late reporters.

Assumptions

For SMS communications, implementations have budget to support SMS features (which charges per message)

User Stories

#	Title	User Story	Label	Importance	Notes
1	SMS and email functionality	As a facility I want for a range of user-controlled SMS and email communications to be handled and tracked within OpenLMIS so that functionality can be automated and tracked in the same system.	eLMIS Tanzania	Must have
2	Automatic R&R rejection notice via email and SMS	As a facility (or districts who submit R&Rs on behalf of facilities reporting on paper) I want to receive automated SMS and email notification when an R&R I submitted has been rejected so that I can address the issue sooner.	eLMIS Tanzania	Must Have
3	Supervisor Reports and Push Notification Interface	As a supervisor, I want to have an interface where I can perform functions so that I can perform regular tasks and push reminders to late reporters.	eLMIS Tanzania	Must Have	see lists of facilities which have not reported yet for the current period, together with the facility’s contact details. The interface should allow showing of late-reporters across all programs or a selected program. select one or multiple facilities and click on a button leading to an option to send an SMS and/or an email to the facility(ies) based on a pre-filled template (but editable before sending) in cases where the user is a higher level supervisor (eg zonal), click on a button to notify lower level supervisor (eg district), leading to an option to send an SMS and/or an email to the lower level supervisor based on a pre-filled template (but editable before sending) The templates should contain customisable general text as well as placeholders/”form fields” for the facility’s name and the period of the report, which are pre-filled by the system.
4	Log of SMS and emails sent	As a supervisor or administrator I need the system to log SMSes and emails sent so that I have a historical record of the communications sent.	eLMIS Tanzania	Must Have

Technical Scope

Each of the numbered items below relate to the user stories above.

SMS and email functionality
1. This functionality assumes that the user wants to be able to track all email and SMS transactions in a single OpenLMIS system. We need to discuss this as something that's architecturally appropriate. There are many third party tools that do this as their core activity and an integration with these tools may be best.
Automatic R&R rejection notice via email and SMS
1. Rejection emails are not currently in OpenLMIS (Josh Zamor please verify). We can add this to the requisition service as a core feature
2. SMS would require a different interface and featureset that's independent because it's not currently supported.
Supervisor Reports and Push Notification Interface
1. This has multiple components:
  1. They would like to see a list of late reporters for the current reporting period. This should be done as a built in report or custom user interface
  2. They want to add a checkbox widget to this report that will allow the user to submit a form that sends an email or SMS notification to the facility manager
    1. This report will somehow need to know if the user has a validated phone number or email address by which they can send a notification
      1. If not, there should be a way for the supervisor to add that to the user account if they have it
    2. Before the message is sent, the user would like to customize the message that's sent
  3. There should be some type of feedback loop that shows how many messages were sent and when
Log of SMS and emails sent
1. SMS and emails should be logged differently
  1. SMS could be linked to a bill at some point in the future
2. This should be a report in the system that's available for system administrators.

Diagrams

Dependencies

Description	Link

Open Questions

Below is a list of questions to be addressed as a result of this requirements document:

#	Question	Outcome
1	For Tanzania user stories: review the users, "so thats" added, review the label, and review the priority level.
2	Josh Zamor Do we currently expose the content of email messages that were sent? The Notification service doesn't seem to have a database element	Craig Appl (Unlicensed): we do not currently.
3	Currently the emails are sent to an email server that performs the actual sending of messages. The email server should keep a unified view of all messages that were sent and OpenLMIS does not track these. Logically, it seems that notifications should be managed in third party tools with a link to the third party tool exposed in OpenLMIS such as an email server or SMS Gateway like RapidPro or frontlineSMS. Should this be considered an integration instead of a feature that should be built into OpenLMIS? The way I'd approach answering this is to consider what to display to the end user (not admin) when the 3rd party service isn't available. Still might want to record the message and the status of handing it off to the third party. If we need to determine if the 3rd party sent it, then we're moving into interop needs. - Josh
4	Instead of SMS, could we use a chat system like Telegram or Facebook messenger? These systems don't charge per message and could be cheaper than SMS.
5	Does the user need to be actively connected to the OpenLMIS server to send messages? What features should be available when offline?
6	What should we do when the SMS gateway has run out of money and needs to be recharged?
7	The current system posts emails in realtime. Do we need to somehow queue messages? What about automated retries?
8	Do we need to keep a log of the message content, or just a list of which messages were sent?
9	How long should we keep this log? Does it need to be in a database, or will a text file with logrotate be fine? Database entries could get big quickly. Fair question. If the data access is append-only and our selects are based on a user's id, I wouldn't have any concerns for this table guessing that the number of new messages a month is likely below 80k (4000 requisitions in a month * 10 messages per requisition * 10 messages for the order to pod that results)