Gap Analysis: eLMIS Tanzania & Zambia and OpenLMIS 3.x
Goals/Scope
The purpose of the gap analysis is to identify the gaps between the current features (and roadmap) of eLMIS in Tanzania and Zambia and the feature roadmap for OpenLMIS 3.x. Based on the outcomes of this activity, an informed decision can be made on the need to add these “gap features” to the OpenLMIS roadmap and whether a migration path makes sense, and if so, the priority of such an undertaking.
Background
The version of eLMIS in Tanzania (mainland and Zanzibar) and Zambia is built on a previous OpenLMIS code base which was subsequently developed further by a JSI-led development team. In 2015, work began on a re-architectured version (3.x) of OpenLMIS which is designed in an extensible, micro-services based architecture, with work led by VillageReach.
Migrating to OpenLMIS 3.x would have advantages for Tanzania and Zambia as they would benefit from new features developed for this global public good. However in order to consider the case for migration, Tanzanian and Zambia users and stakeholders require that OpenLMIS 3.x include the useful features developed in their own versions of eLMIS so that they don’t lose any functionality in migrating.
This has led to this gap analysis work, which aims to document features which are needed in OpenLMIS 3.x in order to ensure it provides at least the same level of functionality to Tanzanian and Zambian stakeholders as their current eLMIS does. This document is focused specifically on the Tanzanian mainland gap analysis.
Additional background:
The original monolithic architecture of OpenLMIS and eLMIS does not easily support the re-use of features from country to country. At the OpenLMIS Stakeholder Conference in September 2015, the OpenLMIS community identified this barrier to “shared investment, shared benefit” as the greatest barrier to long term success and adoptability of OpenLMIS as an LMIS standard in LMICs. For this reason, the community undertook a re-architecture effort to re-create the system on an extensible, micro-services based architecture dubbed version 3.0. The initial 3.0 release is schedule for February 2017.
However, since Tanzania and Zambia are both on the older, monolithic version of OpenLMIS, they will not be able to take advantage of any features developed with the new architecture. To ameliorate this, the OpenLMIS Community has undertaken a “gap analysis” to identify the complexity of re-creating features from the existing Tanzania and Zambia implementations of eLMIS to the OpenLMIS 3.x code line.
Project Information
In the summer of 2017, a team from PATH and JSI conducted an assessment of the eLMIS features and compared them to the OpenLMIS 3.x version with the support of VillageReach. The output of the team's efforts include a list of features which should be added to OpenLMIS 3.x to reach feature parity and provide additional value to Tanzania and Zambia.
USAID via Digital Square, has funded the feature development of the identified features. See the Gap Analysis Development Project for more details about the software development scope, timeline, teams and meeting notes.
Features
Documents
Prioritized features are here.
Requirement gathering and assessment Documents are here in Google Docs to request access, please contact @Amanda BenDor (Unlicensed)
Tanzania Gap Analysis Document: here. Each feature will be documented in confluence for the OpenLMIS community to review. See the sub-pages for details.
From 2016
August 2018 Update:
During my trip to Tanzania, I have participated in a number of conversations about the eLMIS in Tanzania Mainland and Zanzibar (not Zambia). I want to share a few personal reflections on the Gap Analysis Priorities:
Overall, I feel more optimistic that we can close enough of the gap to give Tanzania eLMIS an upgrade path to version 3.
I also feel like an incremental approach may be feasible to run v2 and v3 in parallel and migrate one feature at a time from v2 to v3. For example, if we migrate Reference Data, Requisitions and Fulfillment to v3, other features like the Lab Equipment Module could stay running on v2. This is something we will explore the feasibility of as part of the Year 3 GHSC-TA-TZ project.
Prioritizing Features in Use: Given the resource constraints, it is my personal opinion that we should de-prioritize features that are not used. Specifically, the "Regimens" tab in Tanzania eLMIS is no longer used (it was marked "in use" previously), and we may now want to de-prioritize it, as I have noted in a comment: Requisition - R&R extra ARV regimen patient information tab. Another feature not in use is the "Send New SMS" feature, which was tested but is not used in production.
Complex Solutions: I am concerned that we might "over-engineer" complex solutions in some cases where simple solutions are sufficient. I have added comments on the following pages about this: Configuration - Setting landing/home page, Requisition - Convert requisition to order.
I have an overall thought about the complexity of our software solutions. Some parts of OpenLMIS need complex solutions. The "engine" of the supply chain needs to be robust and heavily engineered--this includes the R&R feature and fulfillment. But other features, like the Regimens tab or even the Epicor 9 integration, could be built in a light-weight or even a hard-coded/single-country way rather than making a full-blown or configurable solution. Add-on features that are not part of the core "engine" of OpenLMIS do not need the same level of robust engineering. I elaborate on this specifically in my comment on Requisition - R&R extra ARV regimen patient information tab.
Lab Equipment Module: I interviewed a lab expert about the Lab Equipment Module in eLMIS and I am adding my notes and attachments to this page: Equipment Module. The feature is not used in production, though it is desired in Tanzania.
As noted above, the incremental upgrade/migration might be feasible. Perhaps eLMIS (v2) can stay online to power the Lab Equipment Module even if the R&R feature is powered by v3. Alternatively, it may be possible to "fork-lift" the LEM from v2 into a microservice for v3. I don't suggest a full re-design/rewrite or making it more configurable or generic, but just fork-lifting the exact feature as built in eLMIS into an optional add-on module for v3. Finally, I also think it's worth evaluating whether other lab software platforms or asset management tools could power some of the features.
Reports: The eLMIS in Tanzania has many reports not in version 3. Of course this is a big priority of the Gap scope. I feel like reporting-building should be done in collaboration with in-country developers/implementers so they are prepared to build additional reports that don't get finished during the gap project, and keep building/tweaking reports on an ongoing basis.
Administration: There are lots of admin screens in eLMIS-Tanzania, and I am not sure they are all reflected in the Gap documentation. I particularly like the Administration>Upload screen that allows you to configure roughly 30 different lists by CSV upload. That's like an Admin UI on top of the RefData Seed Tool. That said, my personal feeling is that admin tools are a lower priority in the gap than end-user-facing features.
Other Gaps: I notice a few small customizations in eLMIS that are not reflected in the Gap documentation. One small example is the "Excel" button on many reports that allows export of the data. Another example is that eLMIS now has a feature where R&R Rejection Reasons pops up a drop-down for a user to categorize why they are rejecting the requisition. I believe there is a new database table with the list of reasons so it can be configured in Administration>Upload. But @Hussein Hassan reports that this was a very quick/small feature to build which could easily be rebuilt into version 3 if/when needed. So I don't think we need to add it in the Gap scope. Instead, we should help make sure in-country developers have support to build these sort of small features/customizations in a modular/extensible way.