December 1 2015

Attendance Information

12/1/2015

7AM PST - Seattle

10AM EST - New York, DC

5PM CEST - CEST, Geneva, Copenhagen, Joburg

6PM EAT - Dar

Link: https://meetings.webex.com/collabs/#/meetings/detail?uuid=M0J70ISXIREJUUEYZKP26P8RPW-3O29&rnd=10428.504769

Meeting Number: 196 307 742

Host Key: 707674

Audio Connection: +1-415-655-0001

AGENDA

MINUTES

In attendance: Kevin Cussen, Gaurav Bhattacharya, Lakshmi Balachandran, Brian Taliesin, Renee Orser

Plan

20 minutes w/ Kits

15 minutes w/ re-arch debrief

15 minutes w/ MOTECH

Kits (40 minutes): Pre-reading attached below

Background

Kits are important to Mozambique. The ThoughtWorks China team will be tackling this issue in OpenLMIS starting December 28th. RO will discuss our feedback with the team and either put a follow-up meeting on the calendar this week or add an agenda item to the December 15th product committee meeting. 

Kits are considered a product in their own right. In Mozambique, they are only unpacked when they are needed (i.e. may receive 3 kits once a year and "unpack" them individually once a month as needed). Do other use cases support a kit remaining intact in a store room? When a kit is unpacked, it should decrease the kit stock by 1 and increase the stock of the constituent pieces by x, y, and z. 

A.P.E. (CHW in Portuguese) kit is not used as a kit based on the above definition, just a collection of drugs that is given to a CHW. However, it enters and leaves stock as a single item and as such does not fit our concept of a kit. Just a confusing name. 

GS1 has a similar notion of "bundling", i.e. packaging different items together. 

Regardless of how a kit is treated in inventory, the system will need to be able to delve into the constituents of a kit for placing requisitions (which will need to be able to recognize both "raw" commodities and those still bundled in a kit), as well as reporting on what stocks are available at a specific facility. 

In Mozambique, a user will unpack a kit and simply mark the amount of stock for each commodity received. However, in other use cases "unpacking" a kit could be seen as a receipt process where you have a standard collection of drugs and you provide an adjustment reason against that number for any discrepancies. In Mozambique, no adjustment reason is given when unpacking a kit. 

Implementation

The TW China team has outlined 3 approaches to implementing this functionality:

1) Functionality exists both on the android and back-end OpenLMIS*

2) Functionality only exists on the app only.

3) Functionality and logic is contained on the server, the app pulls the logic from the server but the app doesn't know what happens with the logic. Renee, can you expand on this?

For all approaches, kits would be developed as a module or submodule, and could be merged in when needed.

Open Questions

What happens in the case where a facility urgently needs a single commodity from a kit, and rather than unpacking everything, they only unpack that single commodity. How would OpenLMIS deal with this partial unpack?

Is there a use case for automatically unpacking kits as they receive them (i.e. a distributor issues a pack and the receiver receives commodity x, y, and z)? After further discussion, "auto-unpack" should probably be a configurable option - not necessary for the initial implementation in Mozambique.

Requisitions and Reporting in Mozambique use quite a bit of aggregate (i.e. "kit") data. If a facility uses 3 of a particular type of kit over a period, they will likely have 3 delivered for the next period. However, this Requisitions open up a big issue. How can a health facility worker or OpenLMIS place an accurate requisition when both commodities and unpacked kits must inform requisition amounts? 

Re-architecture (5 minutes): Discussed briefly feedback from the VR dev team that a data migration from "1.0" to "2.0" to "3.0" is likely, but that a feature migration defeats the purpose of doing a re-architecture.

MOTECH (10 minutes): Described a one way integration with MOTECH where LMIS data would be pushed to MOTECH and from MOTECH transformed and pushed to DHIS2 for aggregation. Gaurav asked in what type of situation data could be pushed into OpenLMIS. Kevin envisioned a situation where data from a service point delivery application could record the number of "shots-in-the-arm" given for a specific date and this data could be pushed to MOTECH, transformed, and then pushed to OpenLMIS where the data would update stock levels at that facility for the shot given. Gaurav expressed discomfort with the tight coupling of this data - but this is likely many years and many conversations down the line.

RECORDING

ADDITIONAL READING