Page Comparison

This is a living document that continues to be updated as development continues. Please reach out if you have questions.

...

• The Program identifies which programs offer the orderable. The system won't allow duplicate entries for the same program. Otherwise, it wouldn't be possible to determine which properties (like price, pack size) to use for the orderable.
• The Product Code is an identifier used to differentiate each product or orderable in the R&R form as well as other external systems the country operates. This code should be defined in your reference data.
• The Product Name is defined by the reference data gathered during OpenLMIS setup and is displayed on the R&R form for the user.
• The Description is an additional optional field that can be used to describe the product.
• The Active flag determines whether the product is available to select in the requisitioning process.
• The Full Supply flag determines if the product appears on the Full Supply tab. If the flag is FALSE, it will not appear, and if the flag is TRUE, it will appear on all requisition forms on the Full Supply tab. If the flag is set to FALSE, then no users will see this product to select in the requisitioning process within the Full Supply tab.
• The Display Order determines the line item where the product appears on the requisition form. This should match the paper requisition forms to assist in easy entry.
• If ordelable has a children it is kit.
• The Price Per Pack, Pack Rounding Threshold, Pack Size, Round to Zero, and Dispensing unit are defined by the reference data gathered for OpenLMIS setup, and may be displayed on the R&R form for the user. These fields are used in calculations within the R&R form and may affect the Total Requisition Cost.

  • The pack rounding threshold attribute affects how OpenLMIS calculates the number of packs to ship to restock a facility. Note that product inventory and usage are generally reported in "dispensing units," as part of the requisitioning process, where a dispensing unit is the basic unit that a patient is provided when the clinician or pharmacist gives them the product. However the warehouse will ship "packs" of a product, and a pack can contain one or more dispensing units. For example, a dispensing unit for an antibiotic might be a strip of 10 capsules, and the corresponding pack could be a box of 24 strips. OpenLMIS performs the initial calculations for the quantity of each product to ship an SDP in terms of dispensing units, rather than doses or packs. OpenLMIS's last step in these calculations is to round up or round down the number of packs to ship to the SDP. The value of this Rounding Threshold attribute determines when OpenLMIS rounds up or rounds down the number of packs to ship. 
    Returning to our example of strips of antibiotic capsules, if the rounding threshold is set to 6 for this product, then OpenLMIS will round up the number of packs to ship whenever the calculated order quantity of dispensing units that are beyond full packs is greater than this threshold value. For example, if the reorder quantity for the antibiotic is 52 strips, this would equate to 2 full packs plus 4 additional strips (2 x 24 + 4 = 52). Because the rounding threshold for this product is 6, OpenLMIS will round down the order to 2 packs. Conversely, if the reorder quantity for the antibiotic is 55 strips, this would equate to 2 full packs plus 7 additional strips (2x24 + 7 = 55). Because the rounding threshold for this product is 6, and the 7 additional strips exceeds this threshold, OpenLMIS will round up the order to 3 packs. Remember, packs are the units in which the warehouse ships products. Note also, OpenLMIS rounds up when the extra number of dispensing units is greater than the threshold, not when it is greater than or equal to the threshold.
    The can round to zero attribute determines whether OpenLMIS will round the number of packs to ship down to zero when the reorder quantity is less than one full pack and is less than or equal to the rounding threshold for this product. For our antibiotic example, if the reorder quantity was 6 strips (equal to the rounding threshold), then OpenLMIS would round the order quantity down to zero packs if can round to zeroes true. Conversely, it would round the order quantity up to one if can round to zeroes false. In other words, when can round to zeroes set to false, OpenLMIS will always ship at least one full pack when the reorder quantity is one or more dispensing units. If the reorder quantity is zero dispensing units, then OpenLMIS will ship zero packs, regardless of the value of can round to zero.

    
    

    Program (required)	Product Code (required)	Product Name (required)	Description (optional)	Active (required)	Full Supply (required)	Display Order (required)	Price Per Pack (optional)	packRoundingThreshold (required)	netContent (required)	roundToZero (required)	dispensingUnit (optional)	children (optional)
    Essential Meds	AA000300	Mercaptopurine		TRUE	FALSE	1	2154.65	1	1	FALSE	Each
    Family Planning	FP000400	Postinor (Levonogesterol)		TRUE	TRUE	1681	6940.30	1	1	FALSE	Each

    
    

...

A Processing Schedule must be defined for each Program so that you can determine the Requisition Groups that are required. Processing Schedules are required to determine the Requisition Group that is used to operate the Program at that facility. For requisition-based replenishment, facilities are expected to submit requisitions for each program, on a cyclical basis, based on which schedule their "pull" program operates on. There can be many different processing schedules for varying Programs in the same Requisition Group, but they cannot be different processing schedules for the same Program in the same Requisition Group. This scenario creates confusion on which schedule the program's requisition workflow follows.

Once a schedule has been created, you need to define the individual periods that comprise the schedule. Processing Periods define individual start and end dates associated with a Processing Schedule. OpenLMIS allows you to specify any "start date" and "end date" for each period in a schedule and makes no assumptions about automatically creating periods for a new schedule. New periods are not automatically created so the administrator must create them as needed, to not delay the creation of requisitions. The start date can be further back in time to support migration of data from a legacy system, however there can be no gaps between two consecutive periods. As you are creating periods, the system automatically sets the start date for the new period as one day after the end date of the preceding period. The system does not allow deleting periods once replenishment activity has been initiated for that period, and also does not allow deleting a period from the middle of a schedule.

...

(In here we will also need to explain the process of how locations are created, the resources used and unused, how the update process works, and the association between facility and geographic zone: Chongsun Ahn (Unlicensed) to update)

There are two primary use cases that can benefit from an FHIR server implementation in terms of OpenLMIS serving mCSD locations as a provider and consuming locations as an update consumer.

Use case 1: OpenLMIS serving mCSD Locations (Care Service Update Provider)

...

Understanding Ideal Stock Amounts

The Ideal Stock Amount is a yearly estimate of the “target” number of doses of a vaccine you should have based off of your population served (i.e. catchment population). This model for estimating the number of vaccine doses you need is irrespective of vial size, packaging, manufacturer, etc. so that you focus on a single number of doses that you should have at any given time. For more rural service delivery points, this time is typically the number of doses you should have in a year, divided by 12 months with the idea that your refrigerator can only hold up to about a month's worth of vaccines at a time. The Ideal Stock Amount (ISA) can be used in reordering calculations for OpenLMIS for a vaccine program.

Setting up ISA by Facility, Commodity Type and Period

Ideal Stock Amounts (ISAs) are configured by facility code, commodity type, and period. An initial load of ISAs is done by uploading a .csv file with the following columns:

• Facility Code is the Facility that will be associated with the ISA.
• Commodity Type can be the UNSPSC code from https://www.unspsc.org/ 
• Period is the period or schedule that the ISA will be applied to, for example an ISA for the year may be 200,000 while broken down by a monthly reporting period would only equal to 
• ISA

...

In this example there are three facility types (Clinic, Private Hospital and Warehouse) and six facilities of each type.

Valid Destinations table, apart from program code, consists of facilityTypeCode and destination columns.

...

In organizationName column there should be a name of a supplying organization if there is such.

The Valid Sources table for these configuration is created below:

In the table there are warehouses’ facility codes (FAC03, FAC06) in the facilityCode column. It means that these facilities supply facilities of privC and privH facility types.

...

Setup Supervisory Nodes, Requisition Groups, Supply Lines 

...

...

Supply lines are the mechanism that OpenLMIS uses to route orders to the correct warehouse or facility, to be packed and shipped. Supply lines are specified on a per-program basis. Orders for all programs can be routed to the same warehouse or facility, or can be routed selectively, based on how your supply chain operations are structured. Orders for most programs might be fulfilled by a regional or national warehouse, while orders for a vaccination program might be fulfilled from a local facility which has adequate cold-storage capacity.
Supply lines for external fulfillment are specified for supervisory nodes that are at the top node of their supervisory hierarchy, because this is the point from which the orders are released to a warehouse to be filled. For local fulfillment, the supply lines may be defined at an intermediary level in the supervisory node hierarchy. Then the approval at that intermediary level is considered a final approval that will create an order to fulfill. Each supervisory node at the top of their hierarchy must have a supply line specified for each program that is supported by the requisition groups under its supervision. This includes both requisition groups under its immediate supervision, as a supervisory node only has one requisition group it directly supervises.

Example:

• The Supervisory Node attribute is the supervisory node code from the section above. It identifies all facilities that this supervisory node supervises, directly or indirectly. For example, all member facilities in this node's requisition group and member facilities from requisition groups from child supervisory nodes. If an intermediary level supervisory node fulfills locally, then they are considered the final approval and should have their own supply line to allow for fulfillment.
• The Program attribute identifies the program that the requisition group supports. This field must be one of the program codes defined during the program setup process and is required. 
• The Supplying Facility attribute identifies the warehouse or facility that will fulfill the orders and is required. This field must be one of the facility codes defined during the facility setup process.
• The Description attribute is for any additional descriptive information that will be helpful when setting up or managing supply lines. This field is optional.

In the Supply Lines list view, you are able to view the facilities that the Supervisory Node supervises by hovering your mouse over the Supervisory Node column.

...

...

Messages are translateable pieces of content that are a part of the OpenLMIS-UI. The best way to update a message is by configuring the OpenLMIS-UI to use your implementation's Transifex settings and editing the message directly in Transifex. What Transifex does is replace a message key, which is defined in the UI, with a human readable message. This is how the OpenLMIS-UI supports multiple languages.

See the example below:

<!-- HTML similar to this, will be updated by Transifex once the OpenLMIS-UI is built and run in a browser --> <p>{{ 'example.instructions' | message }}</p> <!-- The above message will be displayed to a person using the OpenLMIS-UI as: --> <p>These are some instructions</p>

The strategy in the OpenLMIS-UI is to not reuse specific message keys, and let the tools in Transifex group messages that are the same together into a single spot for translation. This allows an implementer to further customize small messages such as 'Search' to 'Search Facilities' if the needs of their implementation require more specificity.

...