This page provides acts as the software requirement specification for the OpenLMIS and OpenSRP integration for the minimum viable product integration for stock management.

...

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.

...

• 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

...

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:

...

Currently, the business logic involved in consumption, wastage and prediction are all hardcoded based on the stockType. We will need to add the feature to dynamically define the stock card business logic that's run on the Android client based on the number of doses per vial for each trade item. This business logic needs to be scoped for each commodity type that is part of the vaccine program. This business logic can be defined based on the information we get from the OpenLMIS APIs.

Bulk Orderable Update

---START HERE---

The current stock control view focuses on single stock card transactions one orderable at a time. We will add a new area to the Android client that allows dispensary technicians to make changes to multiple orderables. This user interface is targeted at store managers who need to issue, adjust or receive multiple orderables in a single transaction. Examples include issuing multiple orderables to a single third party, stock take adjustments, large wastage adjustments and receive a shipment.

Discussion:

• Is there a better name for this section?
• Do we have story points for these activities?
• Is there a better way to layout this section? Currently, it's based on actions that need to be performed

Action 1: Issue Stock - Issue multiple orderables to a single third party

This action allows a store manager to issue multiple stock items to a single third party in a single transaction. The store manager will be presented with a form that allows them to define the destination and choose the quantity of each orderable to issue from the list of orderables that are currently in stock.

Data Entry Screen

• Section: Issue to - This section allows the user to select the third party who will receive the stock.
  • Field: Location - This list will be populated by the OpenSRP facility list.
  • Field: Person - This list is populated by users who are part of the facility as defined by the OpenSRP team management module
  • Business logic:
    • Only one location or person can be selected in this section.
    • Stock cannot be issued to the location that is currently active in the app
    • One of these fields must be selected to be able to save the form.
    • The selection in this section can be changed after the orderables are selected with no change to the orderable section
• Section: Orderables - This section allows the user to choose which orderables to issue and the quantity to issue
  • (The UI for this section has not yet been defined)
  • Field: Select Orderable by name and unit - This field allows the user to select an orderable of orderables that are currently in stock (value >0)
  • Field: Issue Quantity - This field allows the user to specify the quantity of units to issue
  • Field: VVM - If a VVM is available for this product, the user must select the VVM of the orderable (number 1 - 4)
  • Business logic:
    • Orderable name and unit are auto populated by the OpenLMIS metadata
    • Issue Quantity cannot exceed the available number of units on hand
    • Issue Quantity is a required field
    • VVM is only displayed if the orderable has a VVM. In which case, VVM is a required field.

Form Save Android Client Business Logic

• Once the form is saved each orderable is decremented by the issue quantity and values are updated across the entire stock management module
• The user is redirected to the Stock Control Landing View

Discussion:

• Does the user need to be able to issue stock up the OpenLMIS hierarchy?
• What is the OpenSRP server side business logic that needs to be captured before it is sent to OpenLMIS?
• Are there any other sections that should be added to this view?
• Do we need to handle the case where stock is issued to a community health worker who is able to login to the same Android device without requiring a sync to the server?
• Future Idea: Should we prepopulate the orderables section with any information based on the field selected in the "Issue to" section?

Action 2: Adjustment -  Stock take

This action allows a store manager to perform a stock take. The view includes a list of all orderables that are available to the facility. The list of available orderables are defined by OpenLMIS and maintained in the OpenSRP orderable map. The end user will not have the ability to add orderables that have not already been added in the OpenSRP server. Note that the Android client will need to sync if the system administrator has updated the list of available orderables.

Data Entry Screen:

• Section: Orderables - This section displays a tabular view of all orderables that are in available to this facility. Each orderable signifies a single row.
  • (The UI for this section has not yet been defined)
  • Column: Orderable name
  • Column: Orderable unit
  • Column: Stock on Hand - This shows the current stock on hand for the orderable
  • Column: Physical Count - This field allows the user to capture the number counted
  • Column: Calculated difference: - This is a calculated field that calculates the physical count minus the stock on hand values and displays in whole units
  • Column: VVM - If a VVM is available for this product, the user must select the VVM of the orderable (number 1 - 4)
  • Business logic:
    • Each orderable represents in a row in the table
    • Orderable name and unit are auto populated by the OpenLMIS metadata
    • All orderables are displayed on this screen
    • VVM is only displayed if the orderable has a VVM. In which case, VVM is a required field.

Form Save Android Client Business Logic

• Once the form is saved each orderable is adjusted to the physical count quantity and values are updated across the entire stock management module
• The user is redirected to the Stock Control Landing View

Discussion:

• Do we need to include open vials in this stock take?
• Do we need to account for different VVM?
• How do we define the order of the orderables that are displayed on this screen?
• What is the server side business logic?
• Future Idea: Facilities may request that we order the orderables specifically tailored to their environment so it's easier to take stock.

Action 3: Adjustment -  Bulk Wastage Event

This action allows a store manager to make bulk adjustments in the event of a large wastage like a Cold Chain Equipment failure or natural disaster. The view includes a list of all orderables that are currently in stock at the facility.

Data Entry Screen:

• Field: Wastage Reason - This single select field is populated from the program specific adjustment reason.
• Section: Orderables - This section displays a tabular view of all orderables that currently have a stock value greater than 0. Each orderable signifies a single row in the table.
  • (The UI for this section has not yet been defined)
  • Column: Orderable name
  • Column: Orderable unit
  • Column: Stock on Hand - This shows the current stock on hand for the orderable
  • Column: Amount Wasted - This field allows the user to capture the number wasted
  • Column: Calculated stock on hand: - This is a calculated field that calculates the new stock on hand value by subtracting the amount wasted from the stock on hand value (stock on hand - amount wasted). This field displays in whole units.
  • Business logic:
    • Each orderable represents in a row in the table
    • Orderable name and unit are auto populated by the OpenLMIS metadata
    • All orderables are displayed on this screen
    • Amount wasted cannot be greater than the current stock on hand.

Form Save Android Client Business Logic

• Once the form is saved each orderable is adjusted to the calculated stock on hand quantity and values are updated across the entire stock management module
• The user is redirected to the Stock Control Landing View

Discussion:

• Do we need to include open vials?
• How do we define the order of the orderables that are displayed on this screen?
• What is the server side business logic?

Action 4: Receive Stock - Receive multiple orderables from a single third party

This action allows a store manager to receive multiple stock items from a single third party in a single transaction. The store manager will be presented with a form that allows them to define the source and choose the quantity of each orderable that was received from the list of available orderables. The list of available orderables are defined by OpenLMIS and maintained in the OpenSRP orderable map. The end user will not have the ability to add orderables that have not already been added in the OpenSRP server. Note that the Android client will need to sync if the system administrator has updated the list of available orderables.

Data Entry Screen

• Section: Received from - This section allows the user to select the third party who sent the stock.
  • Field: Location - This list will be populated by the OpenLMIS facility list.
  • Field: Person - This list is populated by users who are part of the facility as defined by the OpenSRP team management module
  • Business logic:
    • Only one location or person can be selected in this section.
    • Stock cannot be received from the location that is currently active in the app
    • One of these fields must be selected to be able to save the form.
    • The selection in this section can be changed after the orderables are selected with no change to the orderable section
• Section: Orderables - This section allows the user to choose which orderables are received and the quantity received
  • (The UI for this section has not yet been defined)
  • Field: Select Orderable by name and unit - This field allows the user to select an orderable of orderables that are currently in stock (value >0)
  • Field: Quantity Received - This field allows the user to specify the quantity of units to that are received
  • Field: VVM - If a VVM is available for this product, the user must select the VVM of the orderable (number 1 - 4)
  • Business logic:
    • This section is prepopulated by the list of all available orderables to the facility as defined in the OpenSRP orderable map
    • Orderable name and unit are auto populated by the OpenLMIS metadata
    • Quantity Received is a required field
    • VVM is only displayed if the orderable has a VVM. In which case, VVM is a required field.

Form Save Android Client Business Logic

• Once the form is saved each orderable is updated by the quantity received and values are updated across the entire stock management module
• The user is redirected to the Stock Control Landing View

Discussion:

• Does the user need to be able to issue stock based on the OpenSRP hierarchy?
• What is the OpenSRP server side business logic that needs to be captured before it is sent to OpenLMIS?
• Are there any other sections that should be added to this view?
• Do we need to handle the case where stock is received from a community health worker who is able to login to the same Android device without requiring a sync to the server?
• Future Idea: Should we prepopulate the orderables section with any information based on the field selected in the "Issue to" section?

OpenSRP Server Side Configurable Views, Business Logic and Data Model

OpenSRP Server has a mechanism for defining configurable views and data models for the Android Client and syncing those from the server down to the client. This feature allows system administrators to define a view and data model in JSON. Every time the Android client syncs, the view and data model is able to update. This feature is essential for the dynamic list of orderables and associated business logic in OpenLMIS.

These configurable views and data model will remain manually configurable in the OpenSRP server. They will not be dynamically updated based on changes in OpenLMIS. This allows the OpenSRP system administrators to carefully consider the impact of changing the view and data model, thoroughly test the change and implement it.

Below is a running list of views, business logic and data models that need to be configured from the server:

• Stock control landing view:
  • List of stock cards
  • Orderable item metadata (name, unit of measure, dose)
  • Assumption: The order of the JSON will be the order in which the item is displayed on this view
• Stock card views:
  • Each orderable item has its own metadata that populates the view (name, unit of measure, dose)
  • Each orderable item has specific business logic when performing calculations on the wastage view
  • Each orderable item has specific business logic in the Stock Card - Stock Planning view
  • Each orderable item has an associated program adjustment reason
• Location Hierarchy:
  • The OpenLMIS location hierarchy is used to define stock issues and receipts. This widget will need to be populated from OpenSRP server
• Stock issue and receipt from Community Health Workers (suballocation):
  • Stock issues to community health workers need to be dynamically populated based on the names of the users registered in the team for that facility or zone.
• Orderable metadata
  • Name is required
  • Unit of measure is required
  • Number of doses is required
  • VVM is required
• Program metadata
  • Program name is required
  • Adjustment reasons are required
  • Program specific orderables are required - so we can link the adjustment reasons to the program for a specific orderable

Feature Configurable Views-1: Upgrade the stock management module to work with configurable views

Currently, the stock management module is static. We need to update this module to be able to work with configurable views that are synced from the server.

Feature Configurable Views-2: Add the ability to sync business logic as a server configuration for each orderable.

Currently, the views and data model are configurable in Enketo forms. Each orderable will require specific business logic and calculations. We will need to define a way to systematically sync business logic and calculations so we can guarantee that the calculations in the user interface and on the tablet are appropriately calculated when there are updates to an orderable from the server.

FROM ABOVE:

We need to develop a data model and REST API to store orderables in OpenSRP to be able to track the orderable products on the server side. This will allow us to populate the fields in the android client, map orderables to immunizations and interact with the OpenLMIS server. Note: We only need to store a subset of orderables in the OpenSRP server, not the entire OpenLMIS orderable list.

This data model needs to be based off of the following data models in OpenLMIS:

• Orderables
  • productCode
  • name
  • dispensingUnit
  • netContent - Number of doses available
• CommodityType - Allows for grouping of orderables (See discussion point below in Orderable Feature-2)

DO WE NEED TO CREATE A REST API OR CAN'T THIS JUST BE STORED AS A STATIC JSON OBJECT.  WE WOULD ONLY NEED AN API IF WE ARE GOING TO BE DISTRIBUTING DIFFERENT ORDERABLES TO DIFFERENT WORKERS.  IT MIGHT BE EASIER TO JUST A FILE PER PROGRAM.  WE COULD THEN JUST HAVE OPENSRP LOOK FOR THE FILE FOR WHATEVER PROGRAMS ARE REFERENCED.  THIS MIGHT BE A LOT EASIER THEN TRYING TO MANAGE AN API.  WE COULD ALSO POTENTIALLY GENERATE THE FILE IN AN EXTERNAL MIDDLEWARE OR VIA SOMETHING LIKE NIFI.

ON APP SIDE WE NEED TO FIGURE OUT WHAT WE DO WHEN WE HAVE TWO DIFFERENT PROGRAMS.  IE) ONE OPENSRP APP WITH SAY CHILD HEALTH AND FAMILY PLANNING.  WE PROBABLY ONLY WANT TO HAVE ONE STOCK MODULE BUT THEN ALLOW SWITCHING BETWEEN PROGRAMS FOR THAT HEALTH WORKER WITH THE STOCK APP. 

Orderable Feature-2: Allow system administrators to configure the list of orderables that will be stored in OpenSRP and link them to the immunization schedule

OpenSRP server only needs to 'know' about a subset of orderables and link them to the immunization schedule concept in the health domain. This definition will need to be defined in the OpenSRP server by a system administrator. This list of orderables will be used to create views in the android client.

Sample ZEIR Vaccine Schedule JSON

Sample Orderable map:

OpenSRP marks all vaccines with a "name" and "type" in the vaccine schedule. The "name" represents the type and sequence for multi-sequence vaccines (OPV 1, OPV 2, etc.). The "type" does not include sequence information (OPV). The OpenSRP_Stock_Type should map to the vaccine type in the immunization schedule and the Orderable_productCode should map to the OpenLMIS orderable productCode. This productCode links back to the data model setup in Orderable Feature-1.

...

INSTEAD OF SAYING OPENSRP_STOCK_TYPE WOULD IT MAKE MORE SENSE TO SAY HEALTH EVENT OR SOMETHING LIKE THAT? 

\Discussion:

• Do we need to have a concept of a grouped consumption package for orderables? For example, the OPV consumption package includes 1 unit of productCode OPV20 and 1 unit of oralSyringe5ml. (Assumption: Yes) . I DON'T KNOW IF WE HAVE TO WORRY ABOUT THIS USE CASE FOR IMMUNIZATION. 
• Is CommodityType a better grouping mechanism here?
• We don't need all orderables that are in OpenLMIS, only a subset. What is the best mechanism to filter this subset of orderables? Should we filter this by program, or by the map?   CAN ORDERABLES BE IN MULTIPLE PROGRAMS IN OPENLMIS OR IS IT A 1-1 RELATIONSHIP? IF WE CAN CREATE PROGRAMS WITH ARBITRARY ORDERABLES THEN IT WOULD BE IDEAL POTENTIALLY USE THE PROGRAM AS THE FILTER.  THAT WAY WE CAN MANAGE THIS ON THE OPENLIMS SIDE.  I SEE THE MAPPING AS A POTENTIAL CONSTANT WE WOULD WANT TO STORE IN OPENLMIS.  IE) AN ORDERABLE TO PROGRAMMATIC MAPPING.  WE SHOULD PROBABLY CALL IT THAT VS. OPENSRP 

Program Information

OpenLMIS has a representation of a program, which is tightly linked to requisitions, funding and orderables. The current scope of work focuses on supporting one program in OpenSRP and we must ensure that we represent the core program information within the OpenSRP server.

Program Feature-1: Store program metadata in OpenSRP server so it can be used in transactions with OpenLMIS

We must store the following program information in OpenSRP Server:

• program_name
• program_code

Both of the above are needed when sending information to the OpenLMIS API?

We need to store Program specific Stock Adjustment Reasons (Named Stock Card Line Item Reasons). This allows us to track the adjustment reasons that need to be collected in the client.

• Name
• reasonType
• reasoncategory
• isFreeTextAllowed

Other Features Not Yet Specified

Cold Chain Equipment

The SOW includes an activity to track the status of cold chain equipment at the facility. These workflows need to be defined jointly. The feature could be as simple as an SMS interaction from OpenLMIS directly to the health worker, a Boolean toggle on in the OpenSRP Android client, or more complex to keep track of Cold Chain Equipment serial numbers.

Could also view functionality over time in the Android, probably not needed, but I'd assume time series functionality will be important in the reporting.

Advanced Stock Notification / Proof of Delivery

The Advanced Stock Notification (ASN) and Proof of Delivery (POD) are currently being specified by OpenLMIS. These workflows will need to be jointly defined by the OpenLMIS and OpenSRP teams. In theory, OpenSRP server could receive a JSON payload from the OpenLMIS server, push that down to the Android client, and prep the proof of delivery for easy validation in the UI. The teams need to specify the workflows and features independent of the activities that have been specified in this document.

Which may include extensions so that OpenLMIS can push data to external servers

Mobile Role Based Access Controls

As of the MVP, all users will be able to access the stock management module and perform all activities. In the future, we should introduce a role based access control system in the mobile app that allows only a subset of users to access the stock management transactions.

Out of Scope

This section includes a list of items that are out of scope for phase 1.

...

Physical Inventory

This action allows a store manager to perform a stock take or physical inventory of all items they have in their store. The view includes a list of all trade items that are available to the facility sorted by program and commodity type. The list of available programs, commodity types and trade items are defined by OpenLMIS and maintained in the OpenSRP server. The end user will not have the ability to add programs, commodity types or trade items that have not already been added in the OpenSRP server. Note that the Android client will need to sync if the system administrator has updated the list of available programs, commodity types or trade items.

Start Inventory Screen

---START HERE---

Data Entry Screen:

• Section: Orderables - This section displays a tabular view of all orderables that are in available to this facility. Each orderable signifies a single row.
  • (The UI for this section has not yet been defined)
  • Column: Orderable name
  • Column: Orderable unit
  • Column: Stock on Hand - This shows the current stock on hand for the orderable
  • Column: Physical Count - This field allows the user to capture the number counted
  • Column: Calculated difference: - This is a calculated field that calculates the physical count minus the stock on hand values and displays in whole units
  • Column: VVM - If a VVM is available for this product, the user must select the VVM of the orderable (number 1 - 4)
  • Business logic:
    • Each orderable represents in a row in the table
    • Orderable name and unit are auto populated by the OpenLMIS metadata
    • All orderables are displayed on this screen
    • VVM is only displayed if the orderable has a VVM. In which case, VVM is a required field.

Form Save Android Client Business Logic

• Once the form is saved each orderable is adjusted to the physical count quantity and values are updated across the entire stock management module
• The user is redirected to the Stock Control Landing View

Discussion:

• Do we need to include open vials in this stock take?
• Do we need to account for different VVM?
• How do we define the order of the orderables that are displayed on this screen?
• What is the server side business logic?
• Future Idea: Facilities may request that we order the orderables specifically tailored to their environment so it's easier to take stock.

OpenSRP Server Side Configurable Views, Business Logic and Data Model

OpenSRP Server has a mechanism for defining configurable views and data models for the Android Client and syncing those from the server down to the client. This feature allows system administrators to define a view and data model in JSON. Every time the Android client syncs, the view and data model is able to update. This feature is essential for the dynamic list of orderables and associated business logic in OpenLMIS.

These configurable views and data model will remain manually configurable in the OpenSRP server. They will not be dynamically updated based on changes in OpenLMIS. This allows the OpenSRP system administrators to carefully consider the impact of changing the view and data model, thoroughly test the change and implement it.

Below is a running list of views, business logic and data models that need to be configured from the server:

• Stock control landing view:
  • List of stock cards
  • Orderable item metadata (name, unit of measure, dose)
  • Assumption: The order of the JSON will be the order in which the item is displayed on this view
• Stock card views:
  • Each orderable item has its own metadata that populates the view (name, unit of measure, dose)
  • Each orderable item has specific business logic when performing calculations on the wastage view
  • Each orderable item has specific business logic in the Stock Card - Stock Planning view
  • Each orderable item has an associated program adjustment reason
• Location Hierarchy:
  • The OpenLMIS location hierarchy is used to define stock issues and receipts. This widget will need to be populated from OpenSRP server
• Stock issue and receipt from Community Health Workers (suballocation):
  • Stock issues to community health workers need to be dynamically populated based on the names of the users registered in the team for that facility or zone.
• Orderable metadata
  • Name is required
  • Unit of measure is required
  • Number of doses is required
  • VVM is required
• Program metadata
  • Program name is required
  • Adjustment reasons are required
  • Program specific orderables are required - so we can link the adjustment reasons to the program for a specific orderable

Feature Configurable Views-1: Upgrade the stock management module to work with configurable views

Currently, the stock management module is static. We need to update this module to be able to work with configurable views that are synced from the server.

Feature Configurable Views-2: Add the ability to sync business logic as a server configuration for each orderable.

Currently, the views and data model are configurable in Enketo forms. Each orderable will require specific business logic and calculations. We will need to define a way to systematically sync business logic and calculations so we can guarantee that the calculations in the user interface and on the tablet are appropriately calculated when there are updates to an orderable from the server.

FROM ABOVE:

We need to develop a data model and REST API to store orderables in OpenSRP to be able to track the orderable products on the server side. This will allow us to populate the fields in the android client, map orderables to immunizations and interact with the OpenLMIS server. Note: We only need to store a subset of orderables in the OpenSRP server, not the entire OpenLMIS orderable list.

This data model needs to be based off of the following data models in OpenLMIS:

• Orderables
  • productCode
  • name
  • dispensingUnit
  • netContent - Number of doses available
• CommodityType - Allows for grouping of orderables (See discussion point below in Orderable Feature-2)

DO WE NEED TO CREATE A REST API OR CAN'T THIS JUST BE STORED AS A STATIC JSON OBJECT.  WE WOULD ONLY NEED AN API IF WE ARE GOING TO BE DISTRIBUTING DIFFERENT ORDERABLES TO DIFFERENT WORKERS.  IT MIGHT BE EASIER TO JUST A FILE PER PROGRAM.  WE COULD THEN JUST HAVE OPENSRP LOOK FOR THE FILE FOR WHATEVER PROGRAMS ARE REFERENCED.  THIS MIGHT BE A LOT EASIER THEN TRYING TO MANAGE AN API.  WE COULD ALSO POTENTIALLY GENERATE THE FILE IN AN EXTERNAL MIDDLEWARE OR VIA SOMETHING LIKE NIFI.

ON APP SIDE WE NEED TO FIGURE OUT WHAT WE DO WHEN WE HAVE TWO DIFFERENT PROGRAMS.  IE) ONE OPENSRP APP WITH SAY CHILD HEALTH AND FAMILY PLANNING.  WE PROBABLY ONLY WANT TO HAVE ONE STOCK MODULE BUT THEN ALLOW SWITCHING BETWEEN PROGRAMS FOR THAT HEALTH WORKER WITH THE STOCK APP. 

Orderable Feature-2: Allow system administrators to configure the list of orderables that will be stored in OpenSRP and link them to the immunization schedule

OpenSRP server only needs to 'know' about a subset of orderables and link them to the immunization schedule concept in the health domain. This definition will need to be defined in the OpenSRP server by a system administrator. This list of orderables will be used to create views in the android client.

Sample ZEIR Vaccine Schedule JSON

Sample Orderable map:

OpenSRP marks all vaccines with a "name" and "type" in the vaccine schedule. The "name" represents the type and sequence for multi-sequence vaccines (OPV 1, OPV 2, etc.). The "type" does not include sequence information (OPV). The OpenSRP_Stock_Type should map to the vaccine type in the immunization schedule and the Orderable_productCode should map to the OpenLMIS orderable productCode. This productCode links back to the data model setup in Orderable Feature-1.

INSTEAD OF SAYING OPENSRP_STOCK_TYPE WOULD IT MAKE MORE SENSE TO SAY HEALTH EVENT OR SOMETHING LIKE THAT? 

\Discussion:

• Do we need to have a concept of a grouped consumption package for orderables? For example, the OPV consumption package includes 1 unit of productCode OPV20 and 1 unit of oralSyringe5ml. (Assumption: Yes) . I DON'T KNOW IF WE HAVE TO WORRY ABOUT THIS USE CASE FOR IMMUNIZATION. 
• Is CommodityType a better grouping mechanism here?
• We don't need all orderables that are in OpenLMIS, only a subset. What is the best mechanism to filter this subset of orderables? Should we filter this by program, or by the map?   CAN ORDERABLES BE IN MULTIPLE PROGRAMS IN OPENLMIS OR IS IT A 1-1 RELATIONSHIP? IF WE CAN CREATE PROGRAMS WITH ARBITRARY ORDERABLES THEN IT WOULD BE IDEAL POTENTIALLY USE THE PROGRAM AS THE FILTER.  THAT WAY WE CAN MANAGE THIS ON THE OPENLIMS SIDE.  I SEE THE MAPPING AS A POTENTIAL CONSTANT WE WOULD WANT TO STORE IN OPENLMIS.  IE) AN ORDERABLE TO PROGRAMMATIC MAPPING.  WE SHOULD PROBABLY CALL IT THAT VS. OPENSRP 

Program Information

OpenLMIS has a representation of a program, which is tightly linked to requisitions, funding and orderables. The current scope of work focuses on supporting one program in OpenSRP and we must ensure that we represent the core program information within the OpenSRP server.

Program Feature-1: Store program metadata in OpenSRP server so it can be used in transactions with OpenLMIS

We must store the following program information in OpenSRP Server:

• program_name
• program_code

Both of the above are needed when sending information to the OpenLMIS API?

We need to store Program specific Stock Adjustment Reasons (Named Stock Card Line Item Reasons). This allows us to track the adjustment reasons that need to be collected in the client.

• Name
• reasonType
• reasoncategory
• isFreeTextAllowed