Gap Analysis Development Project

VillageReach

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.

JSI

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

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

Open

Source: https://boardthing.com/board/5a2f5126b2d40b061d0c0e19

Recap of the meeting and key outcomes:

Meeting Agenda and Presentation:

Only made it to slide 33.

Goals

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 Dec 7, 2017  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.

Attendees

• JSI: @Ashraf, @Elias Muluneh, @Muhammad Ahmed (Unlicensed), @Visva Kandasamy (Unlicensed) (Wed. morning)

• Ona: @Matt Berg (Unlicensed), @Peter Lubell-Doughtie (Unlicensed), @Clay Crosby (Unlicensed) (Thurs), @Craig Appl (Unlicensed), Roger

• VillageReach: @Mary Jo Kochendorfer (Deactivated), @Josh Zamor (Deactivated), @Brandon Bowersox-Johnson, @Jake Watson (Deactivated) (Friday)

Schedule

The person leading the conversation is identified in BLUE.

PRESENTATION: https://docs.google.com/presentation/d/1TWIpRNIG21nTGO_sTDjRXkirFb3HlV3-HeYTPK17Ttg/edit?usp=sharing

Day 1

• Welcome & Kick-off

  • Introductions (Lead: MJ)

  • Why OpenLMIS 

  • 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

    • BY FRIDAY - A PRIORITIZED BACKLOG DUE

    • 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

Presentation: https://docs.google.com/presentation/d/1ZJjvb8hoUC_k3RK06Bw0eeQz4c1yepBgFTA7hGuNufc/edit?usp=sharing

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:

  • Shared User Accounts and Role Based Access Controls (RBAC) across OpenLMIS and reporting systems are going to be critical (some details on v3 roles Configuration Guide for Implementer/Administrator#SetupRoles)

• 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 (Deactivated) 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.

Interfaces

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)