Configuration Guide for Implementer/Administrator

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

The OpenLMIS community believes in a world where all countries have the data they need to manage their health supply chains and lead to healthier communities. We are a community initiative and a software platform working to make this vision a reality.

The OpenLMIS software is an open source electronic logistics management information system (LMIS) purpose-built to manage health commodity supply chains. OpenLMIS is rooted in the "Common Requirements for Logistics Management Information Systems" using the Collaborative Requirements Development Methodology (CRDM). OpenLMIS supports a wide range of business process needed to manage complex (multi-program and multi-level) supply chain(s). 

Additional Resources: 

• A better world through OpenLMIS Video (3:00) : 

• What is OpenLMIS? Video (20:18) : 

In accordance with the "Common Requirements for Logistics Management Information Systems" using the Collaborative Requirements Development Methodology (CRDM), the following business process are supported within OpenLMIS version 3.x:

1. Requisition Business Process with the objective to ensure timely ordering of the right vaccine/drug/supply in the right quantity.

   • In OpenLMIS, the features supporting this are found within the Requisition service and enabled by the reference data configurations of products (known as orderables), min, max and targets.

2. Receiving Business Process with the objective to receive verified quantity and quality of goods into store and determine need for remedial action when necessary.

   • In OpenLMIS, the features supporting this are found within the Fulfillment service, specifically the Manage the Proof of Delivery portion.

3. Storage Business Process with the objective to maintain chain of custody and appropriate environmental conditions for stock and inventory.

   • In OpenLMIS, the features supporting this are found within the Stock Management service and supported by the CCE Management service.

4. Dispatch Business Process with the objective to identify and prepare accurate quantities of items packed correctly from store needed for transport by lower level is partially supported.

   • In OpenLMIS, the features supporting this are found within the Fulfillment service, specifically the Fulfill Orders portion. At the moment we do not support the process of planning a distribution as defined by the CRDM.

5. Transport Business Process with the objective to manage the movement of supplies between locations is partially supported.

   • In OpenLMIS, the features supporting this are found within the Fulfillment service and are limited to providing the details of the shipment and a notification when a shipment is created.

6. Dispense Business Process, both the generic and administer vaccine, with the objective to dispense effective treatment in the correct quantity and quality to the correct client with appropriate information for proper use. 

   • In OpenLMIS, the features supporting this are found within third-party applications, mainly mobile systems like OpenSRP, and are interoperable with OpenLMIS.

7. Forecasting Business Process with the objective to provide accurate estimation of goods and material needs for a specified time period.

   1. In OpenLMIS, the features supporting this are found within the Reference Data service and defined by implementers. OpenLMIS supports consumption based forecasting, minimum and maximum policies and implementer defined targets (such as target populations, etc.).

8. Capacity Planning Business Process is not yet supported.

9. Distribution Planning Business Process in not yet supported.

10. Contracts and Grants Management Business Process is not yet supported.

11. Procurement Business Process is not yet supported.

In accordance with the APICS Supply Chain Operations Reference Model (SCOR) framework, the following business processes related to Stocked Product are supported within OpenLMIS version 3.x:

Open

What features are included in OpenLMIS? 

New features are added continuously with each release. For details on what features were added when, it is best to review the Functional Documentation page in combination with the release notes. 

OpenLMIS supports "pull" (requisition-based replenishment). This is configurable on a per-program basis. 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. 

 The entire list of terms used in this document are located here (Glossary/Definitions) for reference as you are reviewing the Configuration Guide.

Replenishment Process and Requisition Workflow in OpenLMIS

The following is an introduction to some of the basic concepts and objects used in OpenLMIS. The words that are linked below refer to specific objects that must be created in OpenLMIS as part of setting up the system (e.g., Program, Orderables). When setting up OpenLMIS for a production deployment, a system administrator will need to create these objects in the system, in addition to several other types of objects described below that are intrinsic to OpenLMIS's operation.

OpenLMIS supports customizable Geographic Hierarchy for Geographic Zones or administrative areas. This includes customization of the number of Geographic Levels in the hierarchy, as well as the labels for each level in their hierarchy (for example: Country | Province | Region | District or alternatively as: Country | State | County ).

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). OpenLMIS also supports custom Facility Types which can be used to segment product availability, and for reporting purposes.

OpenLMIS supports one or more Programs, all of which are customizable. For example, a healthcare network could operate a general ART program or it could operate distinct ART programs, such as a Pediatrics ART program and a separate Adult ART program. Hypothetically, these distinct Pediatrics and Adult ART programs could be differentiated by the products available in each program.

OpenLMIS supports grouping Orderables or Products by category (e.g., antibiotics, analgesics, etc.). OpenLMIS uses the terms Products and Orderables interchangeably as shown in more detail in the Orderables section below. The choices for Product Categories are customizable. OpenLMIS allows segmenting products on a per-program basis (e.g., Depoprevara would be offered in a Reproductive Health program, but not in a Malaria program). Individual products can be assigned to one or more programs (e.g., Doxycycline could be used in both the Essential Medicines and Malaria programs). Products are typically further segmented by facility type (e.g., experimental ARVs could be available to teaching hospitals, whereas only fully qualified ARVs would be available at village dispensaries, since there is less concern about risks from undocumented side effects. Note that medical supplies are commonly referred to by several different terms, including orderables and products. 

OpenLMIS supports customizable Processing Schedules that define the Processing 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. For example, there could be three different quarterly schedules, each staggered to start on a different month of a calendar quarter. When performing replenishment calculations, OpenLMIS automatically takes into account the length of each replenishment interval and calculates order quantities accordingly. This is configurable on a per-program basis. 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. 
OpenLMIS uses a mechanism called Requisition Group to manage the replenishment process. A requisition group is a "container" for gathering together a group of facilities that run the same programs, on the same schedule, rely on the same supervisory hierarchy for review and approval of their requisitions, and rely on the same warehouse to fill their approved orders. The requisition group provides a convenient mechanism for managing the schedule and workflow for all these ART clinics, on a group basis.

Now that you understand the replenishment requisition and fulfillment processes, the next step will be to gather and prepare the reference data to complete the OpenLMIS setup.

There are several sets of data that the team must gather, in preparation for setting up OpenLMIS. These will include (in the recommended order of loading/setting them up):

• a list of all Programs and their configuration that will be supported in your health care system

• your preferred classification scheme for facilities (FacilityTypes and FacilityOperators)

• a list of all geographic zones, plus a determination of how your geographic hierarchy will be structured (GeographicLevels and GeographicZones)

• a list of all Facilities that will be part of your health care network, including service delivery points and supply depots or warehouses; each facility includes a list of programs that are supported at that facility.

• a list of adjustment reasons available (for modifying the stock levels in requisitions and during stock management) and their assignemnts to specific programs and facility types (StockAdjustmentReasons, ValidReasons)

• a list of valid source assignments and valid destinations for shipments, proofs of delivery, and stock issuing/receiving (ValidSources and ValidDestinations)

• a list of categories to group the orderables (OrderableDisplayCategories)

• a list of all Orderables and Trade Items that will be available to health care facilities

• your classification scheme for Commodity Types

• your determination for how orderables and trade items will be segmented by program, as well as by facility type (ProgramOrderables and FacilityTypeApprovedProducts)

• your determination of the schedule(s) on which facilities will get replenished (ProcessingSchedules and ProcessingPeriods)

• your determination of how requisitions will be routed for review and approval and how many review steps will be required (SupervisoryNodes)

• your determination of how facilities will be grouped, to get replenished on the same schedule segmented by program (RequisitionGroups + RequisitionGroupProgramSchedules)

• your determination of what facilities will supply for requisitions in the given program and supervisory node (SupplyLines)

• a list of all users and their roles that will be working with OpenLMIS to support the replenishment process (Users, Roles)

Many of these sets of data may already be contained in legacy systems, stand-alone databases, or spreadsheets. The configuration steps listed below include a list of attributes or fields that must be assembled for each of the objects that you will create in OpenLMIS, e.g. facilities or orderables, and should be used to your gathering of the data. OpenLMIS has a tool that can help implementers in loading the above data: https://github.com/OpenLMIS/openlmis-refdata-seed

The default administrator account that is initialized when OpenLMIS is first installed is username = Administrator password = password.

These login credentials are in the public domain and are maintained here, so the first step is to create a new user account with administrator rights, and then disable this default account. Log in with above credentials, then from the main menu, go to: Administration, Users.

Click on the [Add User] button, then enter the basic information for the new user account as well as creating a password for the account by selected the Reset Password link below.

Open

Now the new user account needs administration rights. To set this up, go to Administration, Search for the User: Administrator, then select Edit. It will bring you to the Edit User Roles screen where you can assign the Administration type role to the user as shown below and Save User Roles. Once the user has been assigned the Administration role the OpenLMIS set up can begin.

Open

OpenLMIS relies on three different methods to fully configure the system: 

• Configuring various objects in OpenLMIS, by means of various administrative user screens

• SQL statements, executed by a database administrator that insert data into the system

• Importing CSV files, as bulk uploads of various objects

Each of these methods will be used at different stages of the overall setup process to fully configure the system. Working with administrative user screens is required at various points in the setup process, starting with setting up an OpenLMIS administrator account (as shown above). Administrative user screens will also be used in the latter stages of the setup process, for example, to define the schedule(s) that your replenishment cycles will operate on, to configure requisition forms, create additional user roles, and assign new users to specific roles.

First, you will learn more about each set of data within the system. Then you will be shown how to set it up, and given an example to reference as you are completing this process. Now let's begin the process of setting up OpenLMIS.

Google translations affect the calculations. The translation plugin changes the markup causing the calculated quantities to be incorrect and breaking their update. We recommend not to use Google Translate but rather OpenLMIS built-in translations.

In this step you will learn about setting up OpenLMIS. This step involves creating various attributes and associating reference data. The setup must be followed in this order to ensure data exists for the next attribute. This setup process includes the following:

• Setup Basic Attributes that are used to characterize Products and Facilities

• Setup Orderables, TradeItems, CommodityTypes

• Setup Programs, Processing Schedules, and Periods  

• Setup Geographic Hierarchy, Levels, and Zones 

• Setup Facilities and Facility Types

• Setup Facility Type Approved Products

• Setup Associated Facilities and Programs

• Setup Ideal Stock Amounts

• Setup Stock Management including Adjustment Reasons

• Setup Supervisory Nodes, Requisition Groups, Supply Lines 

• Setup User, Roles, and Rights 

• Setup Facility FTP 

• Setup Requisition & Report Template by program and facility type

• Setup Order File

• Setup CCE Catalog

Setup Basic Attributes that are used to characterize Products and Facilities

Product Categories are used to sort products by a logical order within the R&R form. These categories should make sense to any user that views R&R forms so they can associate the section they are working in as they are completing or reviewing the forms.

Setup Product Categories

Example:

• The Category Code is the shorthand name that is not visible to users. The code must be unique and is case-sensitive.  

• The Category Name is the description of the Product Category that is displayed and visible to all users. The name must make sense to the general users and have enough detail so they can identify which section of the R&R form they are viewing. When transitioning from paper requisitions to OpenLMIS, it may be helpful to categorize products the same way as they appear on the paper form. 

• The Display Order determines where on the R&R form the category and associated products are listed. 

Dosage Units are the different units in which individual doses or items that are given to a patient can be quantified. 

Setup Dosage Units

Example:

• The Dosage Unit Code should correspond with the dosage units for each product. 

• The Display Order determines the order in which the available dosage units are presented to a user when creating a new product or editing an existing product.

Understanding Orderables, TradeItems, and CommodityTypes

This is example will explain how to set up Orderables within OpenLMIS but does not complete any associations with Trade Items or Commodity Types as referenced above. The reference data for Orderables or Products within your organization will determine which setup process (Orderables, Commodity Types, Trade Items) to use when creating these objects in OpenLMIS.

Full Supply orderables are Full-supply products that are assumed to have a "max periods stock" or "ideal stock amount" defined by the MoH, and OpenLMIS calculates reorder amounts to replenish SDPs up to this target amount. Non Full Supply orderables are products that are assumed to be available on an irregular basis, with no guaranteed ideal stocking level. When an Orderable is designated as Full Supply, it will appear on the standard program requisitions. Identifying when a product is Full Supply or Non Full Supply begins in the example below.

  Only include products which are needed, especially for non full supply products because it can impact performance if the list reaches into the thousands, and can decrease usability by making it challenging for users to find products.

Example of two Orderables:

• 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.

Now that you've used your reference data to complete the setup of Orderables, the next step is to set up the objects for Programs, Processing Schedules, and Periods.

Understanding Programs, Processing Schedules, and Periods

A Program is a grouping of Orderables and Trade Items. Each Program has:

• A specific set of Orderables

• A complex configuration including Requisition Form settings and Program-specific user permissions

• 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 though 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. 

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.

Setting up Programs

• Program Codes are the short hand description of the Program and are only visible to the administrator, but can be reused when naming the Supervisory Nodes. 

• The Name is the detailed description of the Program and is visible to all users. The name should provide enough detail that the user knows the difference between multiple programs if they have access to more than one program that have small variations. For example there may be more than one HIV program because they operate on different budgets. If this is the case you must make sure that the name provides enough information for the administrator to choose the correct program during assignment. 

• The Description is not required but is used to provide more detail to the name. The Description is not visible to users other than the administrator.

• The Active flag determines whether the Program is available to use in the requisition process. If a Program is set to Active = TRUE, then this means users can see this program to start requisitioning. If the Active flag is set to FALSE, then the Program is not available for the requisition process. This is helpful if a new program needs to be set up early. Once the program is ready to use the administrator would change the designation to TRUE.

• The Allow Skipping Periods designation identifies if a requisition for the next period can be skipped. This is typically enabled when OpenLMIS is first set up and processing schedules have been created for prior periods. A requisition must be created for the next available period, unless the administrator has allowed to skip periods. For example if the next available requisition period in OpenLMIS is July 2017, but the current calendar date is October 2017, then the user would need to enter in requisitions for July, August, and September before they could start October. If the administrator has allowed to skip periods, then the user could skip July through September and start on October. If this designation is set to TRUE, then the administrator has enabled skipping periods. This is also useful if users have not completed requisitions for previous periods, but need to enter a requisition for the current period. If this is set to FALSE then the requisition must be completed for every period in the order of the defined schedule. This feature addresses issues with data capture on a routine basis when a facility hasn't been reporting for awhile. In this case, there are empty requisitions for the missed reporting periods, but they need to complete a requisition for the current period. This does cause issues with reporting for the skipped periods so it should not be used often. 

• The Show Non Full Supply tab designation determines whether a program shows the Non Full Supply tab within a requisition. An orderable is considered Non Full Supply because they are available on an irregular basis. If the designation is TRUE means that the Non Full Supply tab will appear for the Program. If the designation is set to FALSE, then there will not be a Non Full Supply tab when viewing the requisition for that program. 

• The Skip Authorization Step flag determines whether the authorization step is enabled in the requisition workflow for this program. When this flag is set to true, the authorization step will not take place and the submit operation will bring requisitions of this program directly to the AUTHORIZED state (ready for approval). The changes to this setting are applied immediately to all requisitions. This means that the additional step of Convert to Order is no longer required and a requisition will automatically update to the Released without order status. This must be configured as TRUE when a facility and program are fulfilled locally.

 If the requisition has already been submitted though, and had its authorization step skipped, it will still be available for approval, even after disabling this flag.

Example:

Open

 Any changes to Program Settings are effective immediately

Setting up Requisition Date Physical Stock Count Completed

An optional setting allows you to configure whether the Requisition Form for each program will prompt users to enter a 'Date Physical Stock Count Completed' or not. 

Open

Administrators can enable or disable this under Administration > Programs > Program Settings (screenshot above). By default, this is disabled for each Program. If you Enable it and click Save, it will take effect for all Requisitions for that Program. 

When this setting is enabled for a program, any user Submitting or Authorizing a Requisition in that program will be prompted to enter a date that the Physical Stock Count was completed:

Open

The date prompt first appears when a user Submits a Requisition. A date is required at that time. The date prompt appears again when a user Authorizes the requisition, allowing the authorizing user to view and change that date, if desired. For requisitions where this date has been entered, the date appears in the gray header at the top of the Requisition for all users who can view the Requisition.

The Requisition form saves some of its data in the Stock Management service so that it can be viewed on stock cards. When the setting is enabled, the date captured during the Requisition submission and authorization will be used by the Stock Management service to record the stock quantities as of that specific date. When the setting is disabled, then no such date is captured from users, and the Stock Management service will record stock quantities by using the ending date of the requisition period.

The benefit of enabling this setting is more accurate stock transaction records, although it does require users to conduct data entry of a date during the requisition process.

This setting takes effect immediately, including for in-progress Requisitions. Administrative permissions (to the Program Settings page) are required to change this setting. As soon as this setting is enabled or disabled, users Submitting or Authorizing a requisition will notice this change. This feature was first introduced with OpenLMIS 3.2.0. For background about this feature, see the ticket https://openlmis.atlassian.net/browse/OLMIS-3023 as well as the wiki documentation Connecting Stock Management and Requisition Services.

Setting up Processing Schedules

• The Processing Schedule Code is a shorthand description for the Processing Schedule that is only used during initial set up. 

• Processing Schedule Name should clearly identify how the schedule will be set by an administrator. This example shows Monthly schedule, but there could also be a Quarterly Schedule. When the administrator creates processing periods they will select the Processing Schedule by this name and create the periods to match. The Monthly Schedule would have a period for each month. 

• The Processing Schedule Description is an optional field that could provide more detailed information on the processing schedule.

Example:

Open

Setting up Processing Periods

• Processing Periods must be defined by the administrator to ensure that requisitions can be entered. Processing Periods are not automatically set up and the administrator must create periods for all the future requisition processing periods so that requisitions are not delayed.

• The Name is a short hand description of the Processing Period and is visible to the users when completing the requisition workflow. The name should provide enough information for a user to understand the period they are completing for their requisitions. This example shows a processing period for each month. If the Processing Schedule was Quarterly, the Processing Period names could be Q1-2017, Q2-2017, Q3-2017, Q4-2017, Q1-2018, etc. 

• The Description is a more detailed explanation of the Processing Period. The example shows the Monthly Processing Period, but if the Processing Period was Quarterly the description could be: Processing Period for First Quarter of 2017, then Second Quarter of 2017, and so on.

• The Start Date is the date when the period will start, and the first start date should match when your organization will begin requisitioning. In this example the start date is the first day of the month, but does not have to start on the first day of the first month. If your organization begins using OpenLMIS in the middle of the year, the first start date could be July 1, 2017. If the Processing Period was Quarterly, the start date could be January 1, 2017 for the first period, and then April 1, 2017 for the second period. 

• The End Date is the date when the period will end, and must be at least one day after the Start Date. In this example the end date is the last day of the month. If the Processing Period was Quarterly, the end date could be March 31, 2017 for the first period, and then June 30, 2017 for the second period.

• Once the first period is created, the system pre-populates the next period's start date as one day after the previous period created for this schedule.

• The Processing Schedule is the Processing Schedule code created above. To complete the creation of the Processing Schedules you must assign the Processing Period their related Processing Schedule. In this example the Processing Schedule is Monthly (MPS). If the Processing Periods were quarterly, the Processing Schedule could be Quarterly (QTR). 

• The Report Only flag allows the administrator to configure requisition processing periods to no longer require a user to enter a requested quantity into a requisition. The report only flag default is false (unchecked). When the flag is set to True (checked) then this period is considered a report only period and this requisition will not result in a requisition being converted to an order. This flag only applies to regular requisitions.

Example: 

Open

Now that you have completed set up of the Programs and associated schedules, you will setup your geographic hierarchy.

(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.

In this use case, the assumption is that the OpenLMIS implementation is a Care Service Update Provider. OpenLMIS owns an authoritative list of some or all of the Locations and provides those to the federated master facility list management infrastructure. Parts of the facilities that OpenLMIS owns includes supply chain locations like stores, dispensary units.  To support such an implementation with as standard compliant service as possible, OpenLMIS can expose read-only FHIR Location resources. In the OpenHIE Architecture, a mediator is able to access the FHIR Location resources that are exposed from OpenLMIS and populate the Interlinked registry. 

OpenLMIS v3.5 uses a FHIR server running as a microservice in OpenLMIS. 

Open

Assumes that there is an implementation of an Authoritative Master Facility List that supplies mCSD conforming Location resource. In this case, OpenLMIS needs to be able to consume those Locations and Updates as mCSD update consumer. The Locations from the other owners are created in the OpenLMIS as appropriate entities like geographic zones and facilities. However, In OpenLMIS, no update is allowed to be made on these Locations that are created and owned by others. 

Open

Understanding Geographic Hierarchy, Levels, and Zones

OpenLMIS identifies facility locations using a Geographic Hierarchy that is made up of Geographic Levels and Zones. A Geographic Hierarchy helps in outlining the characteristics that make up each level and zone. Geographic Hierarchy also supports reporting, especially when doing comparison reporting of certain trends by region or district. An example of a Geographic Hierarchy is Country, Region, District, where the first level in the Hierarchy is the Country, the second level is Region, and the last is District. A Geographic Level is each level within the hierarchy. A Geographic Zone is the lowest level of the hierarchy and facilities are assigned to a Geographic Zone in the Facility setup detailed in the next section. Although a Geographic Zone is the lowest level of the hierarchy, it does not need to be a the lowest possible level a facility is identified. For example, you would not set up a separate Geographic Zone for every facility, but instead determine the lowest level that reporting needs to use, unless the system is only supporting one facility. Then the setup would only have one zone and one level.

Setting up Geographic Levels and Zones

When defining Geographic Levels you should consider the level that your organization operates on, and which level has the highest rank. If you are operating only regionally, then the Region or Province would be at your highest level, but if you are operating Nationally, then the Country would be your highest level. When creating the hierarchy and levels there is a natural parent to child hierarchy that needs to be defined in the system. The Geographic Zone should be the lowest level that your organization needs to use for reporting because it defines the location of a facility, and the zone is used when creating facilities to associate in reporting. A system intended for use at the national level should use something analogous to “Country” as the highest-defined Level. Likewise, an instance of OpenLMIS intended for use no higher than at a regional Level should something like “Region” as the highest-defined Level. In all cases, the lowest-defined Level should correspond to the most specific  granularity within which facilities should be defined.

Geographic Level Example:

• The Geographic Level explains the facility hierarchy and in this example is defined by country, zone, district. For Geographic Levels in this example the Country is the highest level, Malawi. The Zone is Northern, Southern, and Central, and the Districts are Lilongwe, Ntcheu, and Balaka as examples, which happen to be cities in Malawi. Other examples of Geographic Levels is Country, Province, Region or Country, State, County.

• When setting up Geographic Level, the Code should describe the different levels that exist within your hierarchy. This example shows Country, Zone, District, but the code can also be a shorthand description:

  • Country: CTRY

  • Zone: ZN

  • District: DST

• The Name should describe the Code in more detail, in this example they are the same. 

• The Level Number determines the order of each level in the hierarchy and must be a number. In this example Level 1 is at the top of the hierachy, which is the Country level, and the next level is 2 - Zone, then 3 - District.

Geographic Zone Example: