Table of Contents

The Glossary is a living document. Please leave a comment if you'd like to see new terms or modify current definitions.

Adjustment

An Adjustment is a predefined type of stock movement that is configured with reasons for a user to select and associate with the movement.

Approval Hierarchy

An approval hierarchy is the combination of Requisition workflow rights (initiate, create, authorize, approve) and the approval tiers in a Supervisory Node tree.

Catchment Population

The Catchment Population is the nominal population for the Geographic Zone and is used to calculate coverage rates, or compare consumption relative to population.

Civil Registration and Vital Statistics (CRVS)

WHO definition: A well-functioning civil registration and vital statistics (CRVS) system registers all births and deaths, issues birth and death certificates, and compiles and disseminates vital statistics, including cause of death information. It may also record marriages and divorces.

Despite the well-documented benefits of CRVS, many countries do not have adequate systems in place. The births of tens of millions of children are known to be unregistered every year, and it is estimated that two-thirds of deaths are never registered and are thus not counted in the vital statistics system.

Commodity Types

CommodityTypes represent classifications of commodities. These may be hierarchical or may be flat. Widely-used examples include UNSPSC and GPC. Multiple classification systems can be in use at the same time in a single OpenLMIS implementation. The ability to handle hierarchy and branching follows GS1 best practice and allows an implementation to mix and match existing classification systems in practice. For these reasons, each TradeItem may be tied to one CommodityType in each classification system (e.g., one in UNSPSC and one in GPC).

A Orderable can be constructed from one Commodity Type (or, alternatively, it could be connected to a TradeItem, as above). We refer to this as CommodityType's Orderable. With this kind of Orderable, an end-user is ordering a classification of commodities. A CommodityType's Orderable is the more typical kind used in OpenLMIS. That is typical because often an end-user does not need to order a specific manufacturer's Trade Item (Advil Extra Strength 100mg), but instead wants to order a classification (Ibuprofen 100mg). Later, when a requisition becomes an actual shipment and delivery, some tangible item—a real TradeItem like Advil Extra Strength—can fulfill that order. That is allowed as long as the TradeItem is compatible with the CommodityType (see more about Fulfillment below).

Delivery Zone

Delivery Zones are a collection or grouping of facilities that have the following three characteristics in common:

run the same allocation-based programs or subsets of these programs
operate individual programs on the same replenishment schedule
rely on the same warehouse to distribute products for restocking each facility

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.

Display Order Categories

The Display Order Categories provide a name and display order for a given Orderable applied to a Program. This allows Orderable items to be grouped into categories within the OpenLMIS user interface, such as on a requisition order form. This grouping does not need to match any of the CommodityTypes categories or any official classifications such as UNSPSC. OrderableDisplayCategories provide complete freedom to configure whatever groupings make sense for any given Program. In most cases though it's assumed that an implementation following a well-sourced classification system could simply use that Classification System for its OrderableDisplayCategories.

Distribution resource planning (DPS)

Wikipedia definition: Distribution resource planning (DRP) is a method used in business administration for planning orders within a supply chain. DRP enables the user to set certain inventory control parameters (like a safety stock) and calculate the time-phased inventory requirements. This process is also commonly referred to as distribution requirements planning.

DRP uses several variables:

the required quantity of product needed at the beginning of a period
the constrained quantity of product available at the beginning of a period
the recommended order quantity at the beginning of a period
the backordered demand at the end of a period
the on-hand inventory at the end of a period

DRP needs the following information:

the demand in a future period
the scheduled receipts at the beginning of a period
the on-hand inventory at the beginning of a period
the safety stock requirement for a period

Dosage Unit

A Dosage Unit is the different units of individual doses or items that are given to a patient that can be quantified.

Emergency Requisition

An emergency requisition is a type of requisition that is not limited to one per processing period. A user can enter many emergency requisitions within a processing period.

Emergency Order Point

The Emergency Order Point (EOP) attribute is intended to specify the emergency order point for a facility. As is the case with max month, this attribute is not used by OpenLMIS for replenishment calculations. It is included as a convenience and listed in the header of each requisition as a general guideline.

EPI

Expanded Programme on Immunization. The Expanded Programme on Immunization remains committed to its goal of universal access to all relevant vaccines for all at risk. Within each country, there is a specific EPI programme aiming to expand the targeted groups to include older children, adolescents and adults and work in synergy with other public health programmes in order to control disease and achieve better health for all populations, particularly the underserved populations. See the WHO website for additional details on the programme.

External Fulfillment

External Fulfillment is the process of exporting an order file that will be filled using an external order handling system such as an ERP.

Facility and Facility Types

OpenLMIS supports facilities that function as Service Delivery Points, and facilities that function as warehouses or "supply depots" to replenish other facilities. A single facility can be an SDP or warehouse, or both an SDP and a warehouse. Facilities can be further classified by type (e.g., dispensary, health center, regional hospital, teaching hospital), which can be used to segment product availability, and for reporting purposes. An example where this type of product segmentation within individual programs can be useful is with experimental ARVs. These experimental medications could initially be made available only to teaching hospitals that have staff on hand that are trained to watch carefully for undocumented side effects. Conversely, fully qualified ARVs would be available at all village dispensaries because the side effects of these medications are well understood, and there is much less concern about possible risks to patients from undocumented side effects.

Facility Operator

The Facility Operator can be defined in terms of the types of organizations that are operating at facilities. The Facility Operator is used to provide reporting to the organization identified. Examples are Ministry of Health or Doctors with Borders.

FEFO

FEFO is an acronym for First Expiry First Out.

FIFO

FIFO is an acronym for First In First Out.

Fulfillment

Fulfillment is the process of a warehouse fulfilling orders via a supply line on a per-program basis.

Full Supply

Full Supply orderables are Full-supply products that are assumed to have a "max months stock" or "ideal stock amount" defined by the MoH, and OpenLMIS calculates reorder amounts to replenish SDPs up to this target amount.

Geographic Hierarchy

The Geographic Hierarchy naturally helps users recognize where facilities are located, as well as helps differentiate two facilities that may have nearly identical names. The geographic hierarchy is made of different geographic levels that are further identified by geographic zones. The geographic hierarchy is also intrinsic to most reporting – for example, in comparing reporting rates or stock out rates by district (or by region, county, etc.).

Geographic Level

The Geographic Level is the defined position in the geographic hierarchy for facility locations. This is shown in OpenLMIS by Country, Province, Region, or Country, Region, District, and should be defined in a way to support reporting based on geographic levels.

Geographic Zone

The Geographic Zone supports a facility at its lowest level for location identification. For example, the Geographic Zone for a facility would be the District, not the Country, because the Country is the highest level in the hierarchy and would not be detailed enough to understand the location of the facility for requisition or fulfillment purposes.

Home Facility

A Home Facility is the facility which a user is responsible for completing actions to receive or dispense stock. Enabling a Home Facility for a user allows the system provide a default facility where most of their actions are performed, although a Home Facility is not required for a user setup. If a user isn't set up with a Home Facility they will not be able to initiate or create a requisition as part of the requisition workflow, but could have access to supervisor functions for one to many facilities through a supervisory type role.

Ideal Stock Amount

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) is configured by the Implementer/Administrator and can be used in reorder calculations for OpenLMIS.

Issue

Issue is a type of stock movement that happens when a facility needs to issue stock that isn't requested through the regular requisition workflow.

Local Fulfillment

Local Fulfillment is the process of fulfilling an order locally because the facility has adequate cold-storage capacity. So in this case the order will not need to be fulfilled externally (by a national warehouse).

Order

An Order is a requisition that has completed the approval process, converted to an order (manually by a user or automatically by system configuration), and is ready to be fulfilled.

Orderables

An Orderable represents any item that may be ordered. For example, an item may be ordered on a Requisition form by a storeroom manager in a medical facility. An Orderable in OpenLMIS 3.0 must be connected to either a TradeItem (a specific item by a manufacturer/brand owner) or to a CommodityType (one category of medicines or commodities). Each of those is described further below.
An Orderable is identified uniquely within an implementation by its Product Code. A Product Code is an implementation specific identifier that assists people filling out paper forms as well as external systems all reference the same commodity that may be ordered. Orderable's may also answer a number of questions that typically arise when one needs to order them:

how many patients may I dispense to if I order one?
what Programs may I order this through? and what does that Program stipulate about ordering this?
what other commodities may also be used to fulfill the given Orderable if it is out of stock?

Net Content

Net Content was previously defined as pack size which is the amount of dispensing units contained in each pack. While individual patients receive one or more dispensing units of a product, a warehouse typically ships one or more "packs" to an SDP as part of the replenishment process. Depending upon the product, a pack could be a single vial of a vaccination, or it could be a box of strips of antibiotic capsules. In the latter case, the dispensing unit might then typically be a strip of 10 antibiotic capsules.

Non Full Supply

Non Full Supply products are assumed to be available on an irregular basis, with no guaranteed ideal stocking level. These products and items are not required to be ordered on a routine basis but should be available to requisition or order on an as-needed basis.

Pack Rounding Threshold

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.

Processing Schedule

OpenLMIS supports customizable schedules that define the periods or calendar intervals at which facilities are replenished. Each schedule is typically divided into uniform periods, such as months or quarters. OpenLMIS supports having multiple schedules tailored to how each program and/or geographic region is managed.

Processing Period

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.

Product

A Product is another term for an Orderable that is used to describe any item that can be ordered.

Product Category

Typical categories might include Antibiotics, Antiseptics, Vitamin and Mineral Supplements, Anesthetics - General, Anesthetics - Local. Each product in the system can be assigned to a particular category, on a per Program basis.

Product Code

A 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 may be predetermined by the country and can vary.

Program

OpenLMIS can handle multiple Programs operating at once. 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. For example, a Malaria program may be operating in a country in parallel with a Family Planning program. The Malaria and Family Planning programs may have their own sets of Orderables, users, warehouses, clinic facilities, and configurations.
Sometimes TradeItems and Orderables may overlap between Programs. A specific medicine may be provided by two different programs backed by two different funders and/or supply chains. Even thought it is the same TradeItem, it may have a different configuration in each program. Perhaps a different cost to account for or a different hierarchy of approvals, for example.

R&R

R&R stands for Requisition and Report because information is both gathered and reported from the user. This is a form used by storeroom managers to input stock information and request new stock.

Receive

Receive is a type of stock movement that happens when a facility has received stock that wasn't requested through the regular requisition workflow.

Reference Data

Reference Data is data that is sourced from a database or documents outside of OpenLMIS. Reference Data is used to complete the setup of certain objects within OpenLMIS such as Orderables or Product information.

Requisition Form (R&R Form)

A Requisition Form, or R&R Form is the form that is used by storeroom managers to input stock information and request new stock.

Requisition Group

A Requisition Group is a way to manage the replenishment process for multiple facilities or approval hierarchies. A requisition group is a grouping of facilities that have the following characteristics in common:

run the same programs or subsets of programs
operate individual programs on the same replenishment schedule
rely on the same supervisory hierarchy for review and approval of their requisitions
rely on the same warehouse to fill their orders for each program

Requisition Template (R&R Template)

Each implementation of OpenLMIS configures their requisition templates according to the programmatic needs. There is one requisition template per program. Using the new architecture, implementers can extend the template to meet specific needs for new formulas and options. For example, one example desired extension would be to display values as packs versus dispensing units. Take care configuring the template as many columns are dependent on either user input or reference data.

Rights

Rights are specific user actions that are enabled through the assignment of a role. There are default rights for each role. Rights are broken into types and the types supported are requisition, fulfillment, supervisory, admin, and reports.
Requisition Rights are associated with Requisition-based programs and allow a user to initiate, update, submit, approve, authorize, delete, and view requisitions. For example, the Requisition-based programs role includes rights for creating, authorizing, and approving requisitions. In some cases, a single user may only be given access to create with a separate user required to authorize and approve. Rights are typically 1:1 where one right as described will equal the capability in the system. For example, the right to view requisitions gives you the ability to view requisitions. Except in some scenarios there are additional rights allowed. For example, the create requisition right allows a user to initiate, update, submit, view, and delete a requisition in OpenLMIS. A detailed explanation of roles are rights and how they are used in the system is located here: Role Based Access Control.

Roles

Users' permissions in OpenLMIS are based on assigning them to one or more roles. Roles in turn, are custom-configured by an administrator, and are combinations of one or more rights available in OpenLMIS. Rights relate to individual actions that a user can take, such as view a report, or create a requisition. OpenLMIS classifies rights into five different categories: Supervision, Fulfillment, Reports, Administration.

When assigning a role to a user, only the role-based rights are available to allocate to that specific user. A user can have multiple role assignments for a program especially in the case where a user creates and approves requisitions, as well as views reports. A detailed explanation of roles are rights and how they are used in the system is located here: Role Based Access Control.

Stock Cards

Stocks are maintained in the facility in the form of stock cards. Every inventoriable product that is present in the facility has its own stock card. A stock card is like a log book in which every in and out is documented along with the reason.

Supervisory Node

A supervisory node is not a physical entity or location, but rather a sort of logical control point through which requisitions are routed for review and approval, and must always exist for a requisition to be approved. Supervisory nodes are thus a mechanism that OpenLMIS uses to control the workflow of requisitions, and to manage related rights for individual users of the system. Typically, a user would be given review-and-approval rights for requisitions passing through a particular supervisory node, and these rights could be assigned for one program or multiple programs that the requisition group handles.
There will always be exactly one supervisory node that oversees a requisition group. However multiple supervisory nodes can also be linked together, to create a hierarchy through which requisitions will be routed for a succession of reviews and approvals. For example, requisitions may undergo an initial review and approval by a supervisor at a district office, then route to an additional review and approval by a program officer at the provincial office, before being routed to the warehouse. When supervisory nodes are linked together, they form a "parent-child" relationship, meaning that requisitions are always routed upwards from a child node to its parent node, for subsequent review and approval; there is no bi-directional routing of requisitions between supervisory nodes.
One or more users can be assigned the rights to review and approve requisitions routed to a Supervisory Node. These rights can be assigned on a per-program basis, such that one user could handle both programs, or each program is assigned to separate users. The program assignment is part of the user setup. When a requisition reaches a supervisory node that has no parent, this indicates it has reached the top of the hierarchy, which is the final step in the approval process, and can be released as an order once it passes the final approval.

Supply Lines

Supply lines are the mechanism that OpenLMIS uses to route orders to the correct warehouse, to be packed and shipped.

Trade Items

A TradeItem in OpenLMIS follows the GS1 concept and is, as the name implies, an item meant for trade. These are most often items that have a specific manufacturer or brand owner and are typically identified and defined by that manufacturer or brand owner outside of OpenLMIS. A TradeItem can have an associated GS1 GTIN (Global Trade Item Number) if GTINs are being used. OpenLMIS can provide basic GTIN check digit validation.
Every Orderable can be connected to one TradeItem (or, alternatively, it could be connected to a CommodityType, described below). We refer to this as a TradeItem's Orderable. With this kind of Orderable, an end-user is ordering a specific, real item. A TradeItem should only have at most one Orderable in OpenLMIS. That gives it a single product code by which it is known in that entire OpenLMIS implementation. A TradeItem Orderable can have different settings that vary for different Programs; more on Programs below.
When a TradeItem's Orderable appears on an order form (a Requisition form), it means the end-user is ordering a specific (likely manufactured) item. For example, an end-user may order 10 units of an Orderable, and its TradeItem may be used to fulfill that order. TradeItems may have a GTIN and may are the only concept that may have Lots/Batches or serial numbers. Tracking expiration dates or handling product recalls are made possible by tracking these Trade Item attributes end-to-end through the supply chain. Furthermore, each location where the stock of that item is ordered, warehoused, delivered and stored can be associated with a GS1 GLN (Global Location Number).

User

A user in OpenLMIS is a person who accesses the system to either create, initiate, authorize, approve, fulfill, and report on requisitions; or is a user who manages and sets up controls for the system.
There are also different types of Users involved in OpenLMIS that include System and Database Administrators, Program Specialists, Pharmacists, Logisticians, and Front end users. Configuring a new Logistics Management Information System requires the expertise of multiple people from multiple disciplines:

Pharmacists, who help determine the segmentation of products by program and by type of health care facility, and the classification of individual products as full-supply or non full-supply.
Program Specialists, who help define the optimum stocking levels for individual products, for each of the programs supported at each facility.
Logisticians, who help determine the optimal scheduling of replenishment cycles, the most efficient approach to operating warehouses, and the most efficient use of the delivery fleet.
Database Administrators and System Administrators, who organize the data necessary to configure the system in accordance with the operational requirements identified by the by the above groups, and then perform the actual set up of the system.

This guide does not address pharmacological issues or delivery route optimization. It is a guide designed to be a resource for individuals from all the disciplines above to ensure everyone has a common frame of reference, and common vocabulary, as they work together on setting up OpenLMIS.

VAN: Visibility Analytics Network

At its most basic, VAN encourages adopting relevant private sector supply chain techniques by looking at health through three primary lenses: technology, processes and people. Read this VillageReach blog post for more details.

VVM : Vaccine Vial Monitor

A vaccine vial monitor (VVM) is a label containing a heat sensitive material which is placed on a vaccine vial to register cumulative heat exposure over time. VVM is the only tool among all time temperature indicators that is available at any time in the process of distribution and at the time a vaccine is administered indicating whether the vaccine has been exposed to a combination of excessive heat over time and whether it is likely to have been damaged. It clearly indicates to health workers whether a vaccine can be used. Reference the WHO bulletins for more information.

Browser not supported