Gap Analysis Development Project

Table of Contents


The consortium team (VillageReach, JSI, Ona) will support the OpenLMIS community and build out the features identified in the gap analysis discovery. Given that this award is less than the total amount needed to both support the OpenLMIS community completely and deliver all the features, we have focused on outlining the scope in terms of the prioritized features.


Feature development under this subaward will include features identified in the gap analysis assessment.  During the gap analysis, the OpenLMIS community collected and identified 24 gap features and 12 reports that exist in the Tanzania and Zambia eLMIS (TZM eLMIS) instances but not in OpenLMIS v3. Of the identified gaps, five of the features/reports are either not in use in TZM eLMIS or are requests for new functionality, but the team felt it important to document those requests in case the community has an opportunity to fund high-priority backlog items for the Zambia and Tanzania implementations.

We have organized the features into the following three categories to support work being done in parallel and achieve scope across all three priority areas:

  • Reporting & Analytics (across levels)
  • Interfaces to external systems (includes ERP, mobile, and offline applications)
  • Features
    • Requisition enhancements (favoriting products, columns, usability improvements, budgets)
    • Fulfillment and re-supply features and enhancements
    • User personalization and self-service (configuration, notifications, dashboards)
    • Equipment tracking

Please reference this high-level presentation for a quick overview of the project.

The project is structured in two phases: planning and development.

  1. Phase 1: Planning. Will include a in-person meeting to review scope, conduct estimations, schedule work and present the roadmap to the Product Committee. This phase will entail both creating the work plan for development teams and onboarding the teams for phase 2. We anticipate that there are two in-person meetings, one for planning and one for ‘kicking-off’ the development work for onboarding.
  2. Phase 2: Feature development. Will include the work associated with building out the features in accordance to the roadmap. May include in-person meetings between teams or with customers when approved by the community and with adequate funding available.

Consortium Team

 Click here to expand...


VillageReach was established in 2000 to address the challenges of delivering quality healthcare at the last mile to the most underserved communities. In addition to focusing on a particular segment of the healthcare delivery challenge at the last mile, VillageReach’s focus is to improve the effectiveness and efficiency of the health system services that support the delivery of healthcare and services.

Support from the Bill and Melinda Gates Foundation (BMGF) helped VillageReach establish a dedicated OpenLMIS Global Core (Core) team. The Core team has served as the backbone support organization for the continued development of OpenLMISv3 and the OpenLMIS Governance, Product and Technical communities. OpenLMISv3 was released February 2017, and new features have been released on a monthly and quarterly basis since then. In addition to the maintaining the core source code, the Core team’s dedicated Community Manager has helped formalize the committees and practices that guide the management and direction of OpenLMIS.


In business for more than 35 years, John Snow, Inc. (JSI) is a public health management consulting and research organization dedicated to improving the health and wellbeing of individuals and communities throughout the world. With a portfolio of over 150 health supply chain projects in over 100 countries over three decades, JSI has deep experience optimizing supply chains that are more responsive to public health needs while contributing to global best practices in data visibility and use, system design, human resources for supply chain management, and commodity security.

In recent years, JSI enhanced an earlier code branch of OpenLMIS for Tanzania, Zambia, Côte d’Ivoire and, most recently, Guinea ("eLMIS"). In both Tanzania and Zambia, the applications were deployed at national scale and are fully institutionalized within the health sector, exchanging data routinely with warehouse management systems in the medical stores of each country. As such, JSI’s subject matter expertise and ongoing operational engagement are crucial for bridging the existing gaps between the TZM code base and the OpenLMIS 3.x architecture.


Ona is a Nairobi-based software and consulting company that offers technical consulting, design, and software-related services for organizations and projects of all sizes. The company’s consulting clients include WHO, UNDP, HNEC - Libya, The World Bank, UNICEF, and DFID. The Ona team has nearly a decade of experience designing, developing and implementing ICT enabled solutions for humanitarian, development and global health contexts. This includes developing one of the first national-level SMS facility-based reporting tools. When possible, the company tries to build on top of supported platforms and tools like Ona, RapidPro, DHIS2, and OpenMapKit, allowing them to build reliable, scalable solutions for lower cost.

Ona follows an agile methodology to ensure projects are delivered on time and on budget. The team has extensive experience developing in Java, JavaScript, and Android as well as robust Sight Reliability Engineering practices.

The Ona team is comprised of Matt Berg, CEO who will be acting as an adviser on the project. Peter Lubell-Doughtie, Roger Wong and Craig Appl will work as shared resources for Reporting Architecture, UI-UX and Requirements Subject Matter Expertise. The Ona Technical team is comprised of Craig Appl who is the technical project manager, Clay Crosby who is the data project manager, two senior engineers and two engineers. Each engineer is specialized in Sight Reliability Engineering (SRE) and reporting infrastructure.

Team Structure


In-person Meetings

Pre Award: Initial Project Discussion on  at JSI office in DC.

 Click here to expand...

Recap of the meeting and key outcomes:

Meeting Agenda and Presentation:

Only made it to slide 33.

Phase 1: Estimation Meeting on  -  at JSI office in DC

 Click here to see the Agenda...


To understand the scope, estimate and create a roadmap of the work (which includes an order based on priority), and begin to assign work to teams. We will need to get the schedule approved by the Governance committee. Once that is done, we can submit deliverables to PATH and begin the second phase of the project, feature development.

We will go deeper into the specific work areas than we did during our   meeting in DC. We will have attendees from each organization so we can conduct estimation activities and so we can assign initial work items to different teams.



The person leading the conversation is identified in BLUE.

Wed. April 11Thurs. April 12Fri. April 13

Visva (morning)

Potentially David and Michael from DIAL join. 
Morning 1

9:00am Eastern

Welcome & Kick-off - Mary Jo

9:00am Eastern

Day 2 Welcome - Mary Jo

Gap Scope Review/Estimation (cont'd)

Features are grouped here

  • Team 1: Reporting and dashboards - Ashraf and Peter
  • Team 2: Interfaces - Josh (Craig support)

8:30am: Day 3 Welcome - Mary Jo

8:30 - 10:30: Sustainability discussion - Jake

  • Open to Governance Committee members.
  • David and Michael from DIAL may join
Morning 2

How to Estimate - Brandon

  • Break into Teams
  • Reports from Teams - Brandon

Summarize - Mary Jo

  • Review the total estimates
LunchFail Fest: Past OpenLMIS lessons learned - BrandonUI and Mobile Discussion (Ashraf and Josh)
Afternoon 1

Gap Scope Review/Estimation 

Features are grouped here

Gap Scope Review/Estimation (cont'd)

Features are grouped here

  • Team 1: Fulfillment modifications - Brandon (Mary Jo support)
  • Team 2: Equipment - Ashraf and Elias

How we collaborate (1hr) - Brandon

Prioritize/order the work - Mary Jo

Afternoon 2
  • Reports from Teams - Mary Jo
  • Day 1 Wrap-up
  • Reports from Teams - Brandon
  • Day 2 Wrap-up

Next Steps / Wrap-up - Mary Jo

Dinner/EveningGroup Dinner aka "Feed the Gap"
Depart DC


Notes from the Estimation Meeting

 Click here to expand NOTES...

Day 1
  • Welcome & Kick-off
    • Introductions (Lead: MJ)
    • Why OpenLMIS 

       Click here to expand...

    • Recap Project Background (Lead: MJ)
      • News/Announcements (to provide context)
        • 3.3 release marks end of Vaccine phase
        • GAVI presentations including OpenSRP integration, open source Reporting stack
      • Quick review of Dec. 7, 2017 group kick-off outcomes
        • Team Canvas (Brandon has photos/paper canvas)
        • Budget (from slides)
        • Timeline (from slides)
        • Team Composition 
        • Review structure diagram (also below)
        • Parking Lot (Brandon has photos/paper)
    • Agenda Review (Lead: MJ)
    • Ground Rules (Lead: MJ)
  • Meeting Notes

    • Ground Rules:

      • Be Present

      • Inclusive Conversation with no assumptions (as much as possible)

      • Clarifying between decision making and brainstorming

      • Voting for temperature takes

      • Time box & stay on task

      • Take notes and be transparent in communication

    • Introductions:

      • Elias - JSI eLMIS core developer

      • Craig - Ona Health Technical Lead

      • Peter - CTO Ona

      • Vishva - JSI QA

      • Ashraf - JSI Team lead

      • Josh - Village Reach OpenLMIS Architect

      • Brandon - VillageReach OpenLMIS Core Team Dev Manager

      • Matt - Ona CEO

      • Mary Jo - VillageReach OpenLMIS Product Manager

      • Muhammad - JSI logistics information system support team

    • Announcements:
      • VillageReach Staffing Updates
        • Brandon will be shifting into a strategy and leadership governance role
        • Nick Reid, the UI developer, is no longer with VillageReach
      • Please review Mary Jo's key trip takeaways
      • If you're not familiar with the OpenLMIS 3.3 demo, please connect and begin to familiarize yourself with it.
      • The Implementer Toolkit is a document that describes how you implement OpenLMIS
    • Project Review
      • Why are we here?
        • We want to globally harmonize versions of eLMIS and OpenLMIS
        • Provide an upgrade path for implementations so they can more easily upgrade
        • Deliver feature parity in line with other current requests
      • Can we flag who we can build with?
        • Malawi, Zambia and Tanzania are potential candidates
        • Zambia and Tanzania have added the requirements in this Gap analysis. Malawi has reviewed these and added additional complimentary features
      • Goals of funding
        • We want to close the gap in Tanzania and Zambia
        • Provide an upgrade path for Tanzania and Zambia
        • Grow the community
        • Create a development workforce regionally based that can improve sustainability of the platform and leverage diverse opinions and experiences
      • Deliverables
        • Phase 1 (April and May)
          • Scheduled and approved roadmap
          • Team diagram with roles
          • Environments setup and development team up to speed
        • Phase 2 (see slide)
  • How to Estimate (Lead: Brandon)
    • WHY we estimate
      • acknowledge the super rough estimate and prioritization (show google sheet)
    • Story Points and Epic Sizes – setting common baselines
    • Skillsets - how we identify
    • Team assignments - how we will do it (later)
    • Priority (later)
    • Flag areas where we can take a phased approach or simplify scope to meet the goal.
    • Break into teams
    • Prep: Create template for estimate/component/skillsets cards; ask Craig and Josh for review. ALSO create a slide to summarize team assignment.
    • Meeting Notes
      • Why are we estimating? - So we can track our progress throughout this engagement
      • They want a schedule with monthly outputs
      • We will be developing in an agile methodology internally and report out externally to donors
      • We are estimating now so we can identify how difficult each task is, we will identify the components affected, skills, dependencies and flags for errors
      • How we will do it?
        • Each group will get a color coded card. There is one card for each of the 24 features. Each color indicates a grouping of features
        • If there are multiple ways to solve a problem, we need to clearly define this in a separate sheet
        • If there are subtasks that can be done independently, we need to define these as separate sheets
        • Dependencies: If it's related to another feature, we need to write the title of the dependency. We likely won't get down to fine grained detail.
        • Size: We want to put work into buckets. The initial size is meant to be rough. After that, we need to assign points numerically to be able to measure. We will not convert to points this week. We just want to leave with Ticket, Small, Medium, Large, Infinate
          • We are defining epics here, not features
          • The epic defines a set of new functionalities that add value. They are categories of work that have many lower-level features, ideas and work to begin achieving it.
        • We should have someone taking notes in each story describing the solutions that we are proposing
        • Priority will be assessed at a later point
  • Lunch: Fail-Fest: Past OpenLMIS lessons learned (Lead/introduce: Brandon)
    • share lessons learned? history of forking? examples of multiple partners re-doing work or going in separate directions?
    • Discussion had:
      • Ashraf asked about micro-services and versioning. specifically asking about Malawi.
      • Brandon shared that over the last year, we worked hard on the backend JAVA code extensibility however we didn't go deep into the UI side. 
  • Gap Scope Review/Estimation (Lead: Mary Jo and Craig)
    • Overview of Gap features spreadsheet
      • Mary Jo: Requisitions
      • Craig: User Personalization (and notifications)
    • 24 feature pages (some large in scope, some small)
    • reports (13 wiki pages with 2 pages listing out multiple reports)
    • Discuss any other priorities not reflected or any changes to requirements the team recommends
  • Wrap-up (Lead: Mary Jo)
    • Mini-retrospective: what's working and what's not
    • Remind about parking lot and ground rules
Day 2
  • Day 2 Welcome (Lead: MJ)
    • Agenda Review
    • Any changes to agenda, ground rules, etc.
  • Gap Scope Review/Estimation (Lead: Ashraf/Peter )
    • Overview of Gap features spreadsheet
      • Ashraf and Peter: Reports
    • 24 feature pages (some large in scope, some small)
    • reports (13 wiki pages with 2 pages listing out multiple reports)
    • Discuss any other priorities not reflected or any changes to requirements the team recommends

Reporting by Muhammad Ahmed (Unlicensed)Ashraf


Gap Reports OpenlmisV3.pptx

  • Reporting Complexities
    • PDF/xls outputs are by Jasper
    • HTML is done with Angular
    • Permissions - can be home facility or supervision
    • Canned Reports
    • Custom Reporting "tool" - There's a syntax built-in to OpenLMIS
    • Operational Reports like a pick list
  • Craig: Are there any performance hits/issues?
    • Ashraf: Yes, we experienced so we had to do discrete improvements. We did use some batching approaches to address the performance.
    • These batching approaches can use PostgreSQL materialized views as well as an ETL process, if needed.
  • Themes from the day:
  • User facilities
    • User access model is derived from role, program, and supervisory node assigned to the user.
  • Report features
    • Exports
      • PDF and Excel downloads
      • Send data to Jasper, then Jasper returns the reports
    • Permissions
      • Does a supervisor with permission in a district and permissions to specific facilities in the district have permission to only those facilities or all district facilities?
        • Right now only to the facilities they have explicit access to
        • Facility managers would like to see aggregate reports, but only dis-aggregate to facilities they have access to
          • This may expose information facility managers shouldn't have access to (if there are a total of 4 facilities, and they have access to 3 facilities plus the aggregate they can deduce the 4th, which they do not have explicit access to)

OpenLMIS Reporting Strategy

  • data pump patterns
    • Goal to implement upgrading and services
    • Data pump for microservices is defined by the service providing it (similar to an API) and publishes it (ATOM feed)
  • Lunch: UI discussion (Lead: Ashraf and Josh)
    • Spike on JS Frameworks - Ashraf summarize/report out
    • Mobile Strategy - Josh to summarize Mobile Strategy doc and way forward
    • Resourcing for the Gap (VR no longer has a UI lead resource)

Discussion Notes:

  • Josh highlighted that there is a significant amount of code that is already in OpenLMIS that is written in AngularJS 1.x.
  • Josh referenced Nick's proposal: UI Architecture v7 (moving business logic outside of java script, progressive web apps, webpack)
  • Ashraf's presentation: 
  • Peter asked if we could look into re-usability as another framing question.
  • Josh - One approach is to find a part of the app that can be rewritten in another framework.
  • Josh - UI Router is the core component that we should probably spike with other technologies.
  • From the mobile strategy document consider re-writing stock management.
  • Most of the performance issues that were observed were not because of API calls and back and forth with the server.
  • Spikes were written to test if ng-react and ng-vue to see if it benefits the performance. 
  • Matt: Preference for going with react over vue for mobile stock management.
  • The design process and developer on boarding was not discussed.
  • There is no funding to rewrite the whole application in a new framework.
  • This brainstorming session did not include everyone that that this issue concerns. Eg: SolDevel Developers who have the most knowledge about the current application. 
    • It would be better to move this conversation to technical meetings as well as the developer forum.
  • Matt: We need to quickly decide on this. This influences staffing for the gap project.
    • Josh Zamor as the architect, would be the contact person for this issue.
  • Matt: are there reports that need to be mobile? is there space to discuss the vision and strategy to accommodate new features that would position OpenLMIS better in the market.


Unfortunately it was challenging to take notes during this conversation and it was very circular.

  • OpenLMIS is not a facility registry. We will follow HL7 FHIR for facilities (locations)
  • When countries don't have a functioning facility registry?
    • We will be the master temporarily.

What we have today?

  • representations of location and devices in FHIR

What we need to do?

  • spike on tooling for facility registry ?? 


  • Gap Scope Review/Estimation (Lead: Ashraf/Elias and Brandon)
    • Overview of Gap features spreadsheet
      • Brandon: Fulfillment
      • Ashraf/Elias: Equipment
    • 24 feature pages (some large in scope, some small)
    • reports (13 wiki pages with 2 pages listing out multiple reports)
    • Discuss any other priorities not reflected or any changes to requirements the team recommends
  • Day 2 Wrap-up (Lead: MJ)
Day 3
  • Welcome (Lead: MJ)
  • Sustainability Discussion (Lead: Jake) (Brandon Bowersox-Johnson do you have other notes?)

    • Goal: reduce the donor dependency of OpenLMIS
    • Notes: Jake walked through the presentation and many thoughts/ideas were discussed and shared. Some key thoughts from the donors:
      • Kaleb
        • Wants more regional partners and vendors to be part of the community
        • Would like there to be deadlines and a way which the governance committee engages on these topics
        • Define the evaluations metrics so they can compare across
        • How do we engage implementers consistently? Let them know of the upcoming features on OpenLMIS core features. And let implementers share their roadmaps and upcoming features with the larger OpenLMIS community.
        • Visibility on the country work plans and implementations
        • Guinea will be looking to upgrade
        • Get to know more in the next two months or so
    • Outcomes:
      • Will not take OpenLMIS to non-health industry
      • Ruled out closed sourcing
    • Next Steps communicated to the Governance committee (see April 17, 2018 for more details)
      • Need to list out the open questions where we external support to help answer
      • Weigh the different options (with pros and cons)
      • Understand the market need/size

  • Summarize and prioritize (Lead: MJ)

  • Notes: Mary Jo will draft the longer roadmap and work with team leads. Team identified the first work items to start on between now and May (which will be the governance approval time)

  • How we collaborate (Lead: Brandon)
    • See section 4 from Dec 7 slidesBrandon update it for LESS scrum and for our team structure
    • Prep: Updated slides + Josh content; also Team ILL sync up about what team we are bringing/proposing
    • Team Composition
      • Talk through each partner's team membership and their contribution to the global services
    • Team autonomy, component ownership and success - Josh?
      • smaller teams (~2 people) not the entire organization
      • contract with each team has criteria for team success
      • milestones to check on whether team is on track
      • global leadership won't get involved in the team's business unless/until it is not meeting expectations
        • if so, we reserve right to dissolve and reform the team


Java developers (Java 8, Springboot)

Java 8, Springboot 1.4+Java 8Java 8, Swing, Spring, Spring boot

Knows v3 codebase (back and front)

Back and front built most of the existing 7+ feature servicesMinimal Understanding
Microservices architectureDesign, Consul and domain splitting (right sizing)Understanding of Components

RESTful API Design

Yes and evolvingKnowledgeable in API Design for other projects Yes

SCRUM knowledge methods

Scrum of scrums, LeSSAgile teams, but minimal understanding of OpenLMISYes (moderate level)
DevOps (dockerization, AWS, Ansible, monitoring)Basic AWS, strong on Docker, not on Ansible ours is outdated in Chef, good log centralization and search, need to get better on tracing and internal service monitoring for useAWS, Ansible, Docker, Monitoring, Automation, Security, Terraform, Packer, Basic Kubernetes and ECS experience, RabbitMQ, MQTTDocker, AWS, Jenkin
Frontend framework (Angular, React, etc.)AngularReact, OmAngular, vue.js
MobileNoAndroid Native, React Native, Syncing
Reporting stack (Druid, Superset, NiFi, Kafka, HDFS, Jasper, Metabase)Jasper, Tableu, "data pumps"Druid, Superset, NiFi, Kafka, HDFSJasper, Metabase, Talend, learning about NiFI and cloud computing
Integrations (list out the systems which are potential for OpenLMIS to integrate with)RapidPro, Nexleaf ColdtraceDHIS2, RapidPro, Chatbots, OpenMRS, ODKIntegration with EPICOR, MACS, mSupply, DHIS2
Domain (supply chain and logistics) Experience and knowledge of end usersStrong LMIS historyDeep Health Domain experienceSupply chain, logistics, forecasting, quantification
Business analysis skillsetSupply chainHealth domain, scalable solutions, defining requirements, end user designSupply chain, user requirements, landscape analysis
UI/UX Design

Drop shadows, design workshop

Deep understanding of web service and mobile, HCI process, running design workshops
Enterprise architecture

Vision for domain boundaries and standards based teams... Interop standards of building one-offs.

Understanding of best practices in developing national health infrastructure in partnership with MOH. Robust experience in developing multiple national and global scale products.
Standards (FHIR, mCSD, GS1, OAUTH2)mCSD, GS1, Oauth2CSD, HL7 v2, IHE PIX/PDQ, XForms, OAUTH
Database skillsPostgres, MySQL, SQL Server

PostgreSQL, MySQL, CouchDB, MongoDB, ElastiCache, Redis, InfluxDB, ActiveMQ

Oracle, MySQL, PostgreSQL, SQL Server
Open Source CommunityStrong transparency actions (open documentation and guidance), community engagement, mentoring developers on working in the open.Running OpenSRP and partnering with other communities (OpenMRS, DHIS2, RapidPro, ODK), Strong code review, constructive criticism, architecture review, always-be-commiting, and knowledge sharing culture
Build tooling and developer practicesJenkins, Trunk based developmentTravis-CI, Drone, Github Flow, Git Flow

Team started to discuss what each team wants to work on:

  • Area where we want to catch up on and learn about (micro services and whatever UI framework we move forward with, the reporting stack - DRUID)
  • We bring experiences in everything else
  • Desire to focus on the weaker areas (interfaces, micro services, reporting)
  • Bring a lot of knowledge and experience on what was implemented in TZ and Zambia
  • JSI would like to support lead on the designing and application of the reporting
  • Experience on Docker and would like to share that knowledge
  • Elias: not so interested in reports. Interest in React. Everything else from reports
  • M: reports and analytics and cloud computing, containers, etc.
  • Would like to lead on the infrastructure and devops of reporting
  • Devops on microservices
  • Mobile, when possible
  • Interfaces (DHIS2, sms)
  • Would like to avoid using Angular
  • Strategic areas we’d like to learn/gain
    • Transparency approach
    • Governance process
    • SCRUM approach
  • Standards based interoperability and knowledgeable about FHIR and standards
  • Can work across the full stack (strong docker experience)
  • Weaker on AWS and other devops since we aren’t implementing
  • Leading arch and micro services (REST, web architecture, extensibility)
  • Strong transparency on everything and working in the open (continuous delivery/integration)

  • Next Steps (Lead: MJ)
    • Plan June or July development kick off meeting in East Africa (Kenya/Zambia/?)
    • Read-out and approvals to Product Committee, PATH/DS or Governance Committee

Team Structure

Tentative team structure based on Dec. 7, 2017 meeting:


Follow up from the Estimation Meeting

 Click here to expand...


Items which need to be discussed for the Gap Project:

  • Need to decide on UI Strategy (see notes from the estimation meeting)
  • Who is responsible for tooling and devops support for the teams?
  • Development process (trunk based development)
  • How does the Gap team interface and work with the committees (Product, Technical and Governance)
  • Domains and boundaries
  • Automated and manual testing

Additional Conversations which are wider than the Gap Project

  • Implementer conversation 
  • Competitive Landscape
    • OpenLMIS compared to our peers (Logistimo, mSupply, others?)
    • Call in Jake or Kaleb to set the stage?

Phase 2: Development Kick off - TBD

Location: TBD

Attendees: TBD

Call Meeting Notes

Coordination Call on  

 Meeting Notes, click here to expand

Participants: Edward, Jake, Mary Jo, Matt


1.) Agree on funding mechanism

  • Jake gave the background on the funding.
  • Proposed the two options. a) blanket agreement with one prime b) discrete pieces of work with each organization 
  • Matt would like a general sense of teams so we can have consistency. 
  • Agreed upon VillageReach being the prime and decided to rethink the team structure given the change in funding scope.

2.) Schedule in-person (JSI-Ona-VR+USAID/PATH) for week of GDHF week? Perhaps Thursday, Dec 7th or Friday, December 8th?

For the in-person in DC (which should probably include Lindabeth, Carl and maybe Kaleb), we’d like to discuss the following:

Next Steps:

  • Edward - Will work with his team on reviewing the order of magnitude LOE estimates, confirm people from their side
  • Mary Jo - propose two example team compositions to edward and matt for feedback thoughts pros/cons
  • Need to still confirm date/time to meet at the GDHF

OpenLMIS: the global initiative for powerful LMIS software