Date

22 Jan 2019

7am PST / 4pm CET

Meeting Link

Time	Item	Who	Notes
5m	Agenda and action item review	Josh
	SMS	Josh Zamor (Deactivated)	Nikodem Graczewski (Unlicensed) can't attend so we won't make a decision, however we will cover where the conversation is at and ask if anyone has any questions / comments.
	DHIS2	Craig Appl (Unlicensed)	Update / overview upcoming decision on DHIS2 transport
(next time / forum post)	Important flag of Notification service	Josh Zamor (Deactivated)	We have two definitions: That the message shouldn't be delayed, put in a digest, etc That user preferences should be ignored. Used by forgotten password flow. Is `important` implies too wide of a definition for this? What do we mean by important?

Govt already has a way to get free SMS
RapidPro can be costly to run, usually using the self-hosted TextIt is cheaper.
At OpenLMIS scale, it could be a low enough volume to use the direct phone integration (though rarely do MoH like this idea)
API connection to telco's SMS gateway (probably Kannel) usually takes an hour or so to configure
RapidPro could take on more of our lower priority scope:
- managing message content (translations)
- digests (with a well crafted flow)
- If we redesigned all of Notifications (including email, etc) around TextIt/RapidPro, we could be introducing significant costs to implementer.
Decision needed in 2-3 sprints, make it in sprint 118
- We'll keep up momentum, this week or next (forum post)

Notifications knowledge from eLMIS:

Country email limit, however no country wanted to pay for higher volume emails (over 500, 1000?)
20k emails a day, 90% are bouncing? Mark user account's email as bouncing.
Users would mass-migrate from one domain to another
It'd be useful to try to build two-way Notifications (e.g. unsubscribe), measuring whom is actively clicking on links in the email. (Service such as MailChimp)

Forum post and software spec (add links)
Overall goal is to post aggregate info (indicators, meta, periods) and get to DHIS2
Scope under discussion:
1. Reporting stack to be used for aggregation, visible to an OLMIS admin, and made available
2. (needs a decision): Transport & Crosswalk fields/meta data and make indicators available to a DHIS2 system
  1. Actual transportation of data from OpenLMIS to DHIS2
    1. could be a 3rd party system. i.e. interop layer (OHIE)
    2. in practice it tends to be the client system responsible for sending aggregate data to DHIS2 (as server)
Work in sprint 117 is on building indicators
Before sprint 118 we'll (as in Product Owner) be making a decision on scope (2) above

Josh Zamor (Deactivated) to update zoom link in meeting invite
Nikodem Graczewski (Unlicensed) to schedule meeting with Josh Zamor (Deactivated) to make decision on SMS
Josh Zamor (Deactivated) to start forum post on Important flag
Craig Appl (Unlicensed) to update TC in next call after scope decision has been made