Language

1 – Plan

Plan

Planning for an electronic LMIS project requires several major steps and activities, including developing a project plan, test plan, and training approach (among other activities). 

The steps in this section, 1-Plan, are meant to provide guidance and templates for preparing a successful implementation. 

Downloads available on this page


Project Plan Sample (Excel)
OpenLMIS Test Plan Template
USAID How to Note: Project MEL Plan

Community

Why engage with the Community at the start of your implementation?

Engaging with the OpenLMIS Community at the planning stage of your implementation can benefit your project in multiple ways:

  • Understand the latest code development and features in the latest release
  • Identify potential software development and implementation partners who can help make your project a success
  • Benefit from the expertise of over 20 major global health partners with years experience in implementing OpenLMIS and other health information systems (HIS) in a variety of contexts

How to engage with the OpenLMIS Community

Project Planning

Detailed Budget

Once the scope of the implementation is clear, including an understanding of the requirements and the customization needed for the implementation (or initial phase of the implementation), a detailed budget should be created based on the scope, timeline, selected tools, and personnel making up the implementation team.

Please refer to the cost estimates section to ensure that the budget includes all the required line items for a management information system implementation.

Project Plan

The development of a project plan is key to ensure all key activities are identified, completed on schedule, necessary deliverables or outputs are produced, and dependencies are clearly identified. The project plan can be used to track progress on activities and milestones so adjustments can be made when necessary.

The table below lists the general workstreams and high-level activities that would generally occur in an OpenLMIS implementation, along with a description of what the workstream or activity would include and the expected outputs and deliverables. Depending on the scope and objectives of the implementation, there may be additional workstreams and/or activities.

A sample project plan incorporating these workstreams is available for download.

This can be used as a template, but there are many project planning tools and templates available, and each implementation can choose the tool that they are most familiar with and/or suits them best.

Download: Project Plan Sample (Excel)

 

+ More

Test Plan

Testing and quality assurance is critical to any software development project, and an implementation of OpenLMIS is no different. Any customization needed for an implementation, whether minor user interface changes or adding completely new features, should undergo thorough testing to ensure that any changes work as intended and do not create any issues.

Additionally, testing is important to ensure that the requirements correctly captured the need, that system configuration and reference/master data is accurate, and that non-functional requirements are met. Several types of testing should occur throughout the implementation, including automated unit tests and manual quality assurance completed during active development, functional testing by the implementation team, and user acceptance testing.

The standards and plans for testing should be documented in a test plan (see template below).

Resources


Download: OpenLMIS Test Plan Template

Training Plan

Training is a major component of an OpenLMIS implementation, and often can be one of the longest and most resource-intensive parts of the entire project. Developing a training plan is crucial to ensuring this critical process is managed smoothly. The training plan should include several important pieces of information:

  • Training approach
    • How will training be facilitated?
    • How many trainings will be held?
    • Who will attend and/or attend which sessions?
  • Training budget
  • Training schedule
  • Staffing plan
    • Facilitators (and support or supervisors, if necessary)
    • Logistics support/admin staff
  • Logistics/infrastructure requirements
    • Number of computers needed
    • Consistent and reliable power and connectivity (and/or back up methods)
    • Food and accommodations
  • Training materials
  • Risks and mitigation strategies
    • If people don’t attend
    • If there are internet or other infrastructure issues
    • If there are conflicting activities

Important note: A sample training plan will be available for download in the Implementer Toolkit as more resources are added. Check back often for updates!

Training Curriculum and Materials

Additionally, training curriculum and materials will need to be developed to support training activities. The curriculum will lay out what information is covered and how. Depending on the training approach, it is recommended that the training curriculum(s) is tailored to the needs of the users attending the sessions.

The curriculum will also dictate the materials that are needed for the training. Though the exact materials will vary, a sample list is included below. Keep in mind that if trainings are targeted to different groups, several versions of most of the materials may be needed.

+ More

Monitoring and Evaluation

Monitoring and evaluation should be included in any implementation to track the progress, outcomes and impact of the implementation. The results from monitoring and evaluation can identify issues during and after the implementation to allow the team to make appropriate adjustments and/or change the approach for future expansion or scale up.

Developing an M&E plan at the beginning of the project provides a resource to guide the ongoing M&E throughout the implementation and post-deployment.

Resources

USAID Project MEL Plan
Download: USAID How to Note: Project MEL Plan

Site Assessment

A site assessment should be conducted at the beginning of the project, ideally as part of the planning stage, to gain an understanding of the on the ground situation at deployment sites. A site assessment can be used either to plan for deployment at sites that are preselected, and/or to select the most appropriate deployment sites. The site assessment should consider several factors:

  • Electricity (is it available, by what means, is it reliable, is a secondary source available)
  • Internet connectivity and/or strength of data network (specifically in the pharmacy and/or locations where staff would use OpenLMIS
  • Hardware (computer, dongles, etc.) 
  • Staff/human resources (are there IT staff based at or responsible for the facility, how many staff are there that would use OpenLMIS)

Project Governance and Management

Project Charter

One of the first activities to complete when planning an OpenLMIS implementation is a project charter. A project charter is a succinct document that clearly outlines what the project is, the objectives, scope, and roles and responsibilities.

Additionally, the project charter would include staffing plans and summary budget information, and ensure that relevant assumptions and risks are documented. This document serves as the initial governing document to clearly define and communicate what the project will accomplish and start more in-depth planning.


Download: Project Charter Template

Interoperability and Standards

As electronic health and logistics information systems and tools proliferate and more countries utilize these systems to assist in managing health and supply chain data, interoperability between these systems is now more critical than ever. No single system will ever be capable of managing all the complex transactions and information in a health supply chain; therefore, having systems that are capable of working together to share data and selecting systems that are designed to utilize and recognize globally accepted standards for data exchange are two critical issues to consider when planning and electronic LMIS project.

OpenLMIS strives to be interoperable with other systems in a larger health information ecosystem.

Achieving interoperability requires a balance between allowing for flexibility and controlling for consistency.OpenLMIS aims to achieve this by:

  • designing for and implementing customizable data storage, processing and reporting that’s accessible through published APIs & formats
  • encouraging expansion and customization through modularity
  • maintaining a consistent and robust data-model and reporting interfaces so that a field/column/report means the same thing from implementation to implementation
  • maintaining a consistent look & feel so that using OpenLMIS anywhere always looks and behaves in a predictable manner

 

OpenLMIS interoperability is driven by API endpoints for each of the major services available in the software.

Visit the OpenLMIS ReadtheDocs site to understand the Architecture of OpenLMIS as well as view a list of OpenLMIS’s Components and APIs. 

OpenLMIS as a community and initiative is moving the needle on a variety of interoperability and standards discussions in order to advance system capabilities and features

  • 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 supply chain software.

OpenHIE

OpenLMIS is closely aligned with the Open Health Information Exchange (OpenHIE),  a global community working to help resource-constrained environments better leverage their healthcare data. We work to improve the health of the underserved through open, collaborative development and support of country driven, large scale health information sharing architectures. Learn more about OpenHIE at https://ohie.org/.

As countries contemplate their implementation approaches to health data sharing, many are beginning to discern how the work of the health supply chain intersects with the overall health enterprise architecture.  Many within the OpenHIE community see substantial synergies between supply chain workflows and OpenHIE conventions.  To that end, OpenLMIS is a leading partner in a working group designed to represent and codify the needs of supply chain, and directly influence overall OpenHIE conventions and standards so that they are directly supportive. This working group is comprised of individuals who are either implementation “practitioners” of supply chain infrastructure, standards-savvy professionals, and others interested in supporting this work in a substantive way.

+ More