Introducing OpenLMIS 13 December 2016

What is OpenLMIS? OpenLMIS is a state-of-the-art, open source, web-enabled, enterprise class electronic logistics management information system (LMIS) purpose-built to manage medical commodity supply chains The OpenLMIS initiative incorporates a community-focused approach to develop open source and customizable LMIS systems specifically designed for low-resource settings

OpenLMIS Community OpenLMIS wiki Governance, Product & Technical Committees Bi-weekly community calls Community meetings General info mailing list It’s a resource and a support network. Members of the community meet several times a month to discuss specific projects and the future of the product.

OpenLMIS Software Vision 1. Shared Investment / Shared Benefit 2. Interoperable with other Information Systems 3. Adaptable to the Unique Requirements of Each Country

Re-Architecture In an effort to address issues with code forking, the community agreed in September, 2015 to work toward a common master code branch This effort to re-work the OpenLMIS code is referred to as the "Re-Architecture" of OpenLMIS The re-architecture will take OpenLMIS from version 2.0 (current) to version 3.0 3.0 BETA was released in November, and the MVP (minimum viable product) of version 3.0 is set to be released in February, 2017

Key Features of OpenLMIS 3.0 OpenLMIS Features Online/Offline data entry Workflow approval management (hierarchy, rejections, etc.) Email & SMS notifications Export functionality (PDF, CSV) Role-based security Configurable schedules and periods Jasper reporting framework Reference User Interface Third party BI tool support Supports Pull based requisitioning of stock Emergency requisitions Multiple languages (Transifex) Integrations via FTP and API Low bandwidth environments Set-Up via CSV Upload Files Standard operating reports User management Associations between Product Codes and GS1 Trade Items Mature facility management Complex product configuration

Configurability

Interoperability ONE System Deployment of a standalone logistics management information system like OpenLMIS is considered a best practice in enterprise health information systems architecture Through interoperability, OpenLMIS can “talk” to other health information systems, for example DHIS2 or SAGE.

Deployments

Modular Architecture Point out that we will dive deeper into extensibility shortly, but this visually depicts how they are coupled together.

Extensibility Services Extension Points and Modules Extra data Allow for wholly new and independent feature sets and concepts For example, adding an ‘informed push’ service Extension Points and Modules Allow existing features to define where that feature might be changed or added to For example, new variation on a re-stocking calculation Extra data A storage mechanism that allows for more and previously un-accounted for data to be added to an existing concept Extend the facility record to include “max occupancy” Reference UI Modular user interface allowing for extension and allows for partial or entire replacement For example, to expose/display the fields in the Facility UI screen Service defines the interface and default behavior Extension point/module - Uses the service’s extension point(s) to define a new behavior Extra Data - A way to add data to a component or concept without modifying it Need an example of an extension module or what this is…

External Fulfillment via ERP Requisition Workflow Requisition Service Fulfillment Service Facility District Warehouse Facility External Fulfillment via ERP Storeroom Clerk Store Manager District Manager Warehouse Clerk Storeroom Clerk Idea here, is to give an overview of scope while showing what ‘services’ are behind which business processes. Blue is fulfillment Orange is Requisition Create Requisition Authorize Requisition Approve Requisition Convert & Create Order POD: Confirm Received Quantities Example workflow. Actual workflow can be configured to match target fulfillment process.

3.0 Fulfillment Service An order object and file is generated The order file is sent to an FTP server External ERP retrieves the order file from the FTP server and performs fulfillment Shipment file is retrieved from the FTP server Received quantities are confirmed manually (via UI) against the electronic POD (populated from the shipment file) Received quantities populate the next requisition Refers to the graphic in slide 10 Need to work through delivery of the information with LEGOs Drilling down on the Fulfillment service and then we will talk about extensions.

Putting it into action! Three steps: Requisition process using external fulfillment Extending that process – how could the requisition process be modified? What functionality could program managers be interested in adding? Separating orders based on program or supplier Barcoding Adding driver names What else? Creating a totally new service – local fulfillment

Thank You

Extension points Extend the integration by sending the order file to a local folder to an email Extend the order generation Separating the approved requisition into two orders based on program Extend the shipment file retrieval process by scanning a barcode Retrieve shipment data via scan versus FTP server Extend the shipment file to include driver’s name Use extra data to record the drivers name, use an extension to the UI to show that driver's name Benefits Shared benefit by contributing back the extension modules Continue on the upgrade* path for the service Extend the order generation - Meaning certain programs need an order file separated out so it can be fulfilled by a different entity *using semantic versioning approach (http://semver.org/)

New Service: Local fulfillment Creating new functionality to replace the existing fulfillment service process Local fulfillment functionality Instead of order filling occurring via file transfer to an ERP, a facility can fulfill the order placed entirely within OpenLMIS Benefits Can contribute the service back for others to leverage No longer contains external fulfillment