Features

• System architecture:  Modular, microservices based architecture and extension points for all major services.
• Reference web user interface (UI):  A reference UI allows for customization and multi-language support to match implementor needs. Implementers can also build a completely new interface to meet project needs. It is component based so that it builds one UI from multiple services

Requisitions

• An administrator has the ability to configure a requisition and report template to support the Calculated Order Quantities based on the estimated need
• Support the routine Requisitioning Process (high-level) with a configurable multi-step approval process
• Review and authorize a requisition
• Approve a requisition (can have multiple levels of approvals)
• Confirm approved quantities for re-order
• Reject a requisition for edits or changes by the initiator
• Delete a requisition
• Emergency Requisitions: Create, authorize, approve and convert to order emergency requisitions outside of the normal processing period schedule
• Input data offline

Forecasting and Estimation

• Import ideal stock amounts (ISA) by product, program, facility to support the process of calculating the order amounts within the requisitioning process.

Stock Management

• View Stock on Hand for a specific item or summary of all commodities.
• Conduct a Physical Inventory (aka. stock count/take) workflow by saving a draft and providing a final confirmation.
• Track the ins and outs of stock by making adjustments or recording issues and receipts:
• Create an Adjustment
• Record an issue/receive
• Print the bin card or summary of stock on hand.
• Manage lots centrally and track stock movements at the lot level in alignment with GS1 standards.

Stock Management for Vaccines

• Notification of low stock
• Record the Vaccine Vial Monitor (VVM) status with recording a receipt of stock
• Record the VVM status Additional features needed to support the management of vaccines

External Fulfillment

Ability to view orders and export those orders to external systems for fulfillment.  Features supporting the external fulfillment process, by which requisitions are fulfilled by an external warehouse outside of OpenLMIS, include:

• Configure an order file template to define the columns included in the file export
• Generate an order for external transfer
• Transfer an order file via FTP

Local Fulfillment

Orders are created within OpenLMIS from approved requisitions in specific programs. Each order contains a list of products and corresponding Order Quantities. The user reviews the list of orders, selects an order to fulfill, and sets the fill quantities. Once an order is fulfilled a proof of delivery document is printed and sent as part of the shipment.

• Process incoming orders (generated from requisitions)
• Lots are sorted by first to expire to support FEFO
• Determine the ‘fill quantities’ and allocate stock to the shipment
• Print pick and pack list
• View and record VVM status (when applicable)
• Generate a Proof of Delivery

Reporting and Analytics

The OpenLMIS reporting system is composed of the following:

• Data ingestion using Apache NiFi;
• Data warehousing in the Hadoop File System (HDFS);
• Stream processing using Apache Kafka;
• OLAP database storage using Druid;
• Visualization using Apache Superset

• Product Registry: GS1 OpenLMIS provides functionality for medical commodity logistics: ordering, shipping, receiving, and managing stock. In the OpenLMIS version 3 series, the model for storing and managing this data has been redesigned to align with the Global Standards One (GS1) standards and the Global Health Logical Reference Model. OpenLMIS is currently working to support the identification of trade items which can be ordered, invoiced, fulfilled, shipped, and inventoried using Global Trade Item Numbers (GTINs) and classification systems for assisted ordering.
• Facility Registry: mCSD w/ FHIR STU3, GLN OpenLMIS is expanding its support for IHE’s mCSD Facility Registry profile, which enables federated facility list management using HL7’s widely popular FHIR STU3 standard. Leveraging public GLN registries and the GLN’s ability to be embedded in supply chain barcodes with FHIR’s support for adding GLN identifiers to the facility registry, OpenLMIS will be able to follow where medical products are, where they have been, and where they’re going, aligned with point of care systems, internet-of-things monitoring systems, and aggregated reporting systems.
• Equipment Registry: FHIR STU3 Device (inventory location) OpenLMIS has leveraged IHE’s FHIR Device Resource to align the Location (aka Facility) where cold chain equipment is physically located with Nexleaf’s Coldtrace. This gives both OpenLMIS and Nexleaf a standard, interoperable means of aligning facility lists without brittle custom formats or bespoke mapping lists.
• Supply Chain transactions: EDI OpenLMIS wants to leverage supply chain and software architecture best practice and turn many of the transactional messages exchanged between OpenLMIS Services into GS1 EDI messages. In this way, typical messages such as an Order, Advanced Shipment Notice, Proof of Delivery, etc., can arrive to, and be sent from, OpenLMIS services to other systems that support supply chain transactions. This not only furthers the total interoperability OpenLMIS provides, but also furthers our goal of OpenLMIS services being interchangeable with other supply chain software.