2019-01-22 TC Meeting notes

Date

7am PST / 4pm CET

https://zoom.us/j/211353423

Attendees


Discussion items

TimeItemWhoNotes
5mAgenda and action item reviewJosh

SMSJosh ZamorNikodem 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.

DHIS2Craig Appl (Unlicensed)

Update / overview

  • upcoming decision on DHIS2 transport
(next time / forum post)Important flag of Notification serviceJosh Zamor

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?

Notes


SMS

  • 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)


DHIS2

  • 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


Action Items

OpenLMIS: the global initiative for powerful LMIS software