Target release Release name or number Epic Document status Priority eLMIS Status Implemented OpenLMIS Status Not Implemented PATH  Jenny Thompson (Unlicensed) OpenLMIS  Mary Jo Kochendorfer (Deactivated) JSI  Ashraf Alpha Nsaghurwe (Unlicensed)

Goals/Scope

To include the ARV&OI program “regimens” tab as a third tab in ARV&OI R&Rs.

Status in eLMIS: In eLMIS and in use

Status in OpenLMIS: Not in OpenLMIS

Medium priority - not core to OpenLMIS scope, but needed to match eLMIS functionality

Background

The ARV&OI program in Tanzania has an extra tab (after the full-supply and non-full-supply products tabs) where regimen data is reported.  A regimen is a combination of drugs (e.g., “TDF+3T+EFV”).  The tab lists regimens under two headings: adult regimens and then pediatric regimens (with some regimens with the same name appearing separately under both headings).  There are four columns:

• “Number of patients given ARVs in this quarter”
• “Estimate of new patients” (i,e., who will begin during the next quarter)
• “Number of patients who died or stopped”
• “Remarks”

Specific mapping between the orderable products and these regimens are not in eLMIS, and there aren’t any linkages such as data triangulation or checking between this data and the data on the other two tabs of the R&R.  The CTC pharmacy module (another system in use at facility level) does contain this mapping between ARV regimens and MSD orderable products so that it can do cross-checks and comparisons between dispensing data and patient records data which records regimens - the mapping shows all the different combinations of products which can be used to make up each regimen. In other words, this regimen-product mapping is possible to do, but it is not in eLMIS.  There is no validation on this data besides checking that the first three columns are positive numbers.

It could be argued that this data is not core to the scope of eLMIS, and belongs more in a system such as DHIS.  The main argument for including it seems to be to allow district pharmacists to see this data in one R&R screen so they can manually triangulate regimen data against the main R&R data, and for national level staff to be able to analyse data by regimen.

NOTE:

THIS DATA IS NEEDED FOR LOGISTICS PURPOSES AND NOT FOR HMIS/DHIS, THEREFORE IT IS REQUIRED TO BE INCLUDED IN THE LMIS FORMS AND ITS PER SOPs OF NACP PROGRAM

Assumptions

• In this story user means or one of the following, Health Facility incharge, DMO, Community and Regional Management Team (C/RHMT), Logistics officer/Advisors, Senior level decision maker, M&E officer/Advisor etc

User Stories

Diagrams

Dependencies

Identify initial dependencies that are on the critical path for this functionality and may affect the delivery time and serving of business goals. Include links to stories.

Open Questions

Initial communication between stakeholders and the development team to help understand scope and estimates.

Below is a list of questions to be addressed as a result of this requirements document:

Out of Scope

Notes from Gap Estimation 4/11/2018

• Attendees: Mary Jo Kochendorfer (Deactivated), Matt Berg, Josh Zamor, Ashraf Islam, Peter, Craig Appl, Muhammad, Elias, Brandon
• How are the categories defined?
  • The categories are defined in the database. (Elias would need to check to confirm.)
• Does the admin UI "ProductsCombination" tab influence the Regimen(s) tab?
  • No. The ProductCombinations is primarily used for.... The Central Edition has 1 code repository shared between TZ and ZM. These regimen configurations are set in the Central Edition.
  • The Constituents tab Admin UI is also connected.
  • Essentially these combinations allow you to redefine the product list.
  • Adult doses can be different from child doses.
• Question: How often are these configurations changed? How much do they use these Admin UIs?
  • Not sure.
  • Only 1 person in a country is ever going to reconfigure this. It is very specialized. Couldn't this configuration just be in Excel or elsewhere?
  • Can we simplify the administration of this rather than the admin screens?
• Question: Has anyone looked at RxNorm or other standards for defining treatment regimens?
• These combinations are NOT shipped together. But they are dispensed to patients together.
  • So why is this part of the LMIS?
• OpenLMIS version 0.8 had the Regimens tab on the form, but the other two admin UI tabs were not.
• SDP has its own calculations about this....
• Josh: We need to figure out how much of this fits in the Gap project.
• Question: Does this information help you to actually fill out your requisition and order products?
  • The facility edition might actually use this information to fill out your requisition/order amounts.
• SDP = Service Delivery Point a.k.a Facility Edition.
• Question: Is the system ordering a combination of products all in one line item? 
  • Elias: Yes, for some. No for others (they might have different line items).
• Form Builder
  • Can we leverage an existing form builder to do this?
• DHIS2
  • Is there a requirement for this data to flow into DHIS2 for reporting?
    • Not in the required Gap feature.
    • But maybe using DHIS2 simplifies this work?
• Question: Do these numbers get used to populate the re-order amount?
  • No. We are not sure why. This is a flag about "data use" – why collect and use all this data if it does not inform the re-order amounts? Why is this not reported on?
  • Elias: In Cote d'Ivoire they wanted to add additional columns to report on Male versus Female. I have also heard TB program requirements: they wanted to see 3 fields for TB for # of TB patients, Children, Adults, and MDR-TB Adults. Those would have different dosages.
• Idea:
  • Add a separate tab, use a generic form builder, and have that tab collect the arbitrary form of information. To view what is supposed, you have to look in that other system, eg DHIS2.
  • Josh: This is the Program Data solution the core team had been discussing (to integrate with a form builder tool such as DHIS2).
  • Mary Jo: I would go for the integrated approach. We know these requirements keep changing. We should integrate with a form builder. This feature is important for up-take, including Cote d'Ivoire, Zambia, etc.
• Excel Idea:
  • The system has an Excel file which is an empty template. The users get that blank Excel and fill it in and upload it with their R&R.