This page provides a high level design of This page provides acts as the software requirement specification for the OpenLMIS and OpenSRP integration for the minimum viable product integration for stock management (Phase 1).

Overview

...

Commodity Type: Classification of commodity. An example in OpenLMIS is product code BCG20. BCG20 is a 20 dose vial of BCG. When we order items in OpenLMIS, we don't care which trade item is sent, we just need the specific commodity type.
Dispensing Unit: A dispensing unit is the basic unit that a patient receives when the clinician or pharmacist provides them a product. Product inventory and usage is generally tallied and reported in dispensing units, as part of the requisitioning process.
Lot: A collection of trade items of the same type that were all manufactured at the same time from a single manufacturer. Each lot has an identification number and expiration date. Each lot has passed laboratory to test composition before release to the market.
Net Content: The amount of dispensing units contained in each pack
Program: A program is an independently funded project that is implemented in OpenLMIS and OpenSRP. Each Program has a specific set of Orderables, a complex configuration including Requisition Form settings and Program-specific user permissions, and a network of Facilities that are participating in the Program.
Trade item: An item meant for trade that commonly has a specific manufacturer and are defined outside of OpenLMIS. An example of a trade item in OpenLMIS is product code Intervax BCG 20. This is a trade item that is branded by Intervax and fulfills the BCG20 commodity type that would be ordered.

...

• Make a Bulk Trade Item Issue/Receive - This is a feature in OpenLMIS, but not in SIGLUS.
• Make a Bulk Trade Item Adjustment - This is a feature in OpenLMIS, but not in SIGLUS.
• Automatic receive at a location that was generated from an issue. We will require each health worker to enter the appropriate stock event on their device, if a trade item is issued to another location. This includes sub locations.
• Adding trade items or commodity types from the OpenSRP Android client.
• VVM ← We need to verify this with the OpenLMIS community

Core Workflows

As an Immunization Nurse I need to...

...

• OpenLMIS GET Endpoints:
  • Reference Data Service
    • CommodityTypes - Returns an array of all commodityTypes in the system
    • CommodityTypes/{id} - Returns a specific commodity type
    • facilities/minimal - Returns an array of facilities with id and name only
    • facilities/{id} - Returns a specific facility
    • geographicLevels - Returns an array of geographicLevels
    • programs - Returns an array of all programs
    • programs/{id} - Returns a specific program
    • stockAdjustmentReasons - Returns an array of stockAdjustmentReasons
    • stockAdjustmentReasons/{id} - Returns a specific stock adjustment reason
    • tradeItems - Returns an array of tradeItems
    • tradeItems/{id} - Returns a specific tradeItem
  • Stock Management Service
    • stockCardLineItemReasons - Returns an array of stockCardLineItemReasons
    • stockCardLineItemReasons/{id} - Returns a specific stock card line item reason
    • stockCards - Returns an array of stock cards, result is an intersection of user rights and request parameters.
    • stockCards/{id} - Returns a specific stock card
    • validDestinations - Get a list of valid destinations of a program and a facility type.
    • validReasons - Return a list of valid reasons based on program and facility type.
• OpenLMIS POST Endpoints:
  • Stock Management Service
    • stockEvents - Create a new stock event with one or more orderables

• OpenSRP GET Endpoints:
  • stockresource/getall - Returns a list of stock events
• OpenSRP POST Endpoints:
  • stockresource/add - Add a stock event to the OpenSRP server

There are a number of resources that may need to be created in OpenSRP server. Below is a list of items that may need to be created:

• GET a list of locations by geographic hierarchy
• GET a list of programs, trade items and commodity types
• GET a list of reasons
• POST additions and updates to programs, trade items and commodity types
• POST additions and updates to reasons

...

This section includes the functional requirements and views to be developed in the OpenSRP Android client Stock Management Module. The current stock management views focus on presenting a simplified "stock card" system, where the high level landing page lists the stock cards available and subsequent screens focus on tracking the stock related transactions for that stockTypeimmunization. The core development in the Android client focuses on building dynamic views of stock card items the main screen to support grouping by commodity type and trade item based on the information in OpenLMIS . The first major features will focus on augmenting the current stock management features available in the OpenSRP Android client with dynamic views and updated business logic to support the concept of orderables. The second major feature will focus on creating a dispensary focused "bulk update" view that allows for issuing, adjusting and receiving multiple orderables in a single transactionas well as supporting stock ledger views down to the lot level. Additionally, we will introduce a new physical inventory screen that allows us to perform a physical inventory in the stock management module.

Introducing Orderables to the Android Client

The OpenSRP Android client currently has the ability to track stock issues and wastage from the perspective of the nurse giving the immunizations. The stock cards are currently hardcoded based on the stockType, not the orderable. This interface will be reworked to allow for dynamic population of orderables, expanded fields on wastage and modified business logic linking the patient consumption to the orderable.

Stock Control Landing View - List of available Stock Cards

This view presents the list of available stock cards that can be managed in the system. The user touches a particular card to view, transact and plan for the use of that single orderable. The OpenSRP stockType (i.e. OPV) will be converted to an orderable item on the stock management home screen. The current view includes the stockType as you can see below. This view will now be populated by the orderable name that's defined in the OpenSRP Orderable to stockType map and the screen will have additional orderables such as syringes, based on what has been defined in the map. The items in this view will be configured from the OpenSRP server and updated when there is a sync.

Image Removed

SEE NOTES ABOVE.  WE PROBABLY NEED TO ADD A PROGRAM TOGGLE IF YOU HAVE MORE THEN ONE PROGRAM.  IE) IF WE HAVE FAMILY PLANNING, ANC AND CHILD HEALTH ON OPENSRP. I'D LIKE TO HAVE A SINGLE STOCK COMPONENT AND NOT 3.  SO WE WOULD NEED TO BE ABLE TO SWITCH BETWEEN PROGRAMS HERE.  THIS CAN JUST BE A PULL DOWN FILTER.  WE SHOULD SEE IF THERE IS EVER A SCENARIO WHERE THEY WOULD WANT TO VIEW STOCK ACROSS PROGRAMMES (PROBABLY UNLIKELY AND NOT WORTH THE ADDED COMPLEXITY)

Feature Stock Management-1: Allow for the dynamic population of the stock landing view based on server side configuration

Discussion: The OpenSRP child immunization module has a concept of service delivery zones, allowing for groups of CHWs to manage a group of patients as a component of a facility. Users are mapped as part of a team to these zones. Should we include this as part of the Stock Control module? The bigger question is whether we expect CHWs to use the stock management module on their tablets to perform suballocation activities. If so, this view and all subsequent views would have to be tailored to account for business logic.

PROBABLY NOT AT THIS TIME.  I THINK WE SHOULD CHECK TO SEE IF OPENLMIS CAN HANDLE TRANSFER BETWEEN FACILITIES.  IE) WE CAN INCLUDE AS OPTION THE FACILITY LIST IF YOU WANT TO TRANSFER TO ANOTHER PLACE. RIGHT NOW I THINK YOU JUST TYPE SOMETHING IN TEXT.  OPENSRP SIDE WE DON'T REALLY HAVE TO SUPPORT ANY SPECIAL LOGIC OTHER THEN A FACILTY LIST SELECTOR.  WE'LL HAVE TO MAKE SURE OPENLMIS CAN SUPPORT IT THOUGH ON THE BACKEND.

Stock Card View - Current Stock

...

Server Side Configurable fields

A number of items will need to be configured in the OpenSRP server  and made dynamic in the Android client. This section lists those features:

• programs - Programs will be configured in the OpenSRP server down to the facility level. A facility can have 0 to N programs. If a facility has 0 programs, no program information will be displayed
• commodity types - Commodity types will be configured in the OpenSRP server down to the facility level. If a program is active, there will be a list of available commodity types by program.
• trade items - Trade items grouped by program and commodity types will be defined in the OpenSRP server at the facility level. This dynamic list defines which trade items, down to the lot level are available at each facility. These trade items will determine which items display in the stock management landing view.
• lots - Lots are optional for the entire OpenSRP implementation and can be set in a global configuration variable. If a lot is not defined, we will not include displaying lot information in the Android client. If lots are defined, they are required at all facilities. Lots will be defined in OpenLMIS and pushed to OpenSRP server. If lots are enabled, this impacts what is displayed in the stock management landing view as well as what information is collected in the stock event transactions and physical inventory.

Introducing Commodity Types and Trade Items (Orderables) to the Android Client

The OpenSRP Android client currently has the ability to track stock issues and wastage from the perspective of the nurse giving the immunizations. The stock cards are currently hardcoded based on the immunization type, not the commodity type or trade item. This interface will be reworked to allow for dynamic population of trade items grouped by commodity types.

Stock Control Landing View - List of available Trade Items grouped by Program and Commodity Type

This view presents the list of available stock cards that can be managed in the system. The user touches a particular card to view, transact and plan for the use of that single trade item. The OpenSRP stockType (i.e. OPV) will be converted to a trade item on the stock management landing view. The current view includes the immunization type as you can see below. This view will now be populated with a list of trade items grouped by commodity type. The items in this view will be configured from the OpenSRP server and updated when there is a sync.

This page will also include a program toggle in the top right corner that allows the user to choose the program to manage for this particular view. If no programs exist, this toggle does not display. If the user toggles to a different program, the list of available items in this view changes.

Image Added

Feature Stock Management-1: Allow for the dynamic population of the stock landing view based on server side configuration of programs, commodity types and trade items.

Stock Card View

Once a user touches the trade item from the landing view, they are directed to the Stock Card View. This view is the primary area where stock is managed for a particular orderabletrade item. This view will not change significantly but the information on it will be populated from the Orderable trade item and lot metadata that is imported from OpenLMIS.

...

• Stock Control > OPV: The text "OPV" will be populated based on the orderable trade item name that's imported by OpenLMIS
• OPV Stock: This will be populated based on the orderable name that's mapped in the OpenSRP stockType to Orderable maptrade item name
• 13 vials: The number of vials will be populated based on the metadata from the orderable trade item information imported by OpenLMIS, including the unit of measure
• (New) Number of Doses: We will add an item approximating the number of doses available based on the metadata that's imported from OpenLMIS
• (New) Days out of Stock: We will add an indicator to this screen that measures the days this orderable has been out of stockLot and Expiration Date: Display the lot and expiration date information if activated
• Note: stock numbers are in vials: This item in the bottom will be populated based on the unit of measure for the orderabletrade item.

Navigation:

The navigation buttons of Received, issued Issued and Loss/Adj will not be changed

Stock Card View - Received

---START HERE---

When the user touches the "received" button on the screen above, they will be redirected to a page to enter new orderables that were received.

...