1. Introducing OpenLMIS
13 December 2016

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

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

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

5. 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 BETA was released in November, and the MVP (minimum viable product) of version 3.0 is set to be released in February, 2017

6. Key Features of OpenLMIS 3.0
OpenLMIS Features
Online/Offline data entry
Workflow approval management (hierarchy, rejections, etc.)
& 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

7. Configurability

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

9. Deployments

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

11. 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…

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

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

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

15. Thank You

16. Extension points Extend the integration by sending the order file
to a local folder
to an
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 (

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