Starting an electronic LMIS project is a multi-step process, involving initial activities to evaluate the country landscape, secure stakeholder and partner engagement, develop rough cost estimates, and determine initial requirements. It is important to note that this step in the process of implementing an electronic LMIS can vary dramatically in time duration – for example this step alone could take a year or more to complete.
The steps in this section, 0-Get Started, are meant to provide high-level considerations for getting your project off the ground and beginning to engage with the OpenLMIS Community.
Sample User Stories Template
Sample High-Level OpenLMIS Requirements
Sample Business Requirements
ThoughtWorks – User Stories 101
OpenLMIS is both open source software and a community-based initiative to support and lead global logistics best practices. The Initiative is supported by an international community of nearly 20 donors, partners, implementers, and developers. This community is dedicated to providing continuous support to the countries, health programs and organizations that implement OpenLMIS, with a strong, ongoing focus on improving data visibility within health supply chains globally.
The OpenLMIS Community supports the initiative through volunteered time and resources. The Community is made up of a core team serving as the stewards of the OpenLMIS software product, a Community Manager, and health, technology, development, and financing partners.
The OpenLMIS Community comprises over 20 global health partners who collaborate openly during regularly scheduled community calls to discuss product feature development, community governance, country implementation opportunities, and the technical architecture of the software. See the Collaborators page on openlmis.org for a full list of community partners.
The Community provides the essential function of understanding the needs, deciding on best practices, and defining the product roadmap (prioritizing and scheduling) across the diverse pool of country implementations and funding stakeholders.
The OpenLMIS Initiative rallies around a belief in shared investment, shared benefit. This phrase refers to the commitment OpenLMIS has made as an open source, microservices-based tool to promoting code reuse and sharing learnings and best practices between implementations of the software. Through dialogue and processes within the OpenLMIS Community, current implementers of the software contribute back features developed for their specific implementation so that other current and future implementations can benefit from their investment in features.
The effort and funding expended on one implementation can benefit all other potential implementations. Implementers are able to take advantage of the features built for a previous implementation, expanding the functionality of the software and reducing overall expenditures.
As the number of implementations grows, the economies of scale for the shared value and benefit of OpenLMIS will increase for all countries involved.
Within the OpenLMIS Community, the processes described above to facilitate dialogue and encourage code reuse are well-defined.
Committees: Three committees (Governance, Product, and Technical) which meet regularly and are structured through official membership and charters. Each committee has its own public-facing wiki page describing the membership and scope of the committee, as well as meeting cadence and notes.
Requesting a New Feature: The OpenLMIS community welcomes suggestions and requests for new features, functionality or improvements to OpenLMIS. Visit this page for instructions on how to request a new feature to be built in OpenLMIS. Your request will be reviewed by the OpenLMIS committees and may or may not be scheduled for development dependent on Community review and prioritization.
All committee meeting notes are recorded and made publicly available online and all community discussions are visible via freely-accessible forums. All software development processes, including the product roadmap, ticket tracking, and project documentation, are entirely transparent and published through a variety of online resources. Anyone, whether an official member of an OpenLMIS committee or not, may follow OpenLMIS development and provide feedback or input at any time.
There are several excellent resources available online that have been developed by OpenLMIS Community members and other organizations to help guide the initial concept and planning phases of an LMIS project. Additional resources are available to guide the development of a national eHealth strategy as well as guidance on considerations specific to immunization supply chains.
OpenLMIS itself was conceptualized using the Public Health Informatics Institute (PHII) Finding Common Ground document, and initial requirements gathering for the software followed recommendations from PATH and PHII following the Collaborative Requirements Development Methodology (CRDM).
Several resources are available below
One of the major decisions to be made when planning an implementation is the scale, and how the scale is reached. Is the implementation a small pilot or a nation deployment? Will the initial deployment be followed by subsequent phases to scale-up the implementation?
A number of considerations should be made when determining the implementation scale and approach
Logistics factors that may affect the phasing or scale decisions, including number of users, availability for training and of training spaces
What is the overall scale that you want to achieve?
→ Geographic, level, number of programs etc.
Is it feasible (and reasonable) to achieve the target scale with the initial implementation? Some considerations:
→ Does the implementation have sufficient resources (funding, time, personnel, etc.) to set up, configure, and customize the system and roll it out (including training and support) to all users.
→ Do all deployment sites have the infrastructure and resources to use OpenLMIS in the project timeframe.
→ Are there external dependencies on other projects, organizations, or ministries?
→ Are there standardized or consistent business process in place, or are process changes or strengthening necessary to reach the target scale?
→ How much detail on requirements and specifications is known or available? Is there a need for a limited initial deployment to inform subsequent scale up?
Well defined, clear, and thorough requirements are critical to the success of the implementation. While iteration is an important part of the customization and development, and even well-defined requirements will likely change to some degree over the course of an implementation, most implementations will have defined deliverables, timelines, and limited resources.
Starting with a good understanding of what customization is needed is a key factor for an implementation to be successful within the constraints. There are many methods that can be used to identify, define, and develop requirements.
A few key methods are highlighted here
When developing requirements, it is important to consider all users at all levels – from a store clerk recording individual stock transactions at a facility to a warehouse clerk filling orders at the regional warehouse to a program manager at the national level pulling data and reports to inform forecasting and procurement.
Users will have different requirements based on their duties and focus, and even users performing the same or similar tasks may have different processes or slightly different needs. Further, it is important that all stakeholders have input into requirements development and validation (see CRDM).
Additionally, functional user requirements are generally the first thing that comes to mind when discussing requirements, but they are not the only type of requirements necessary for the implementation, and the others should not be ignored:
There are many ways to document requirements, but previous OpenLMIS implementations have defined requirements in user story format.
Download: Sample User Stories Template
Download: ThoughtWorks – User Stories 101
The first step towards understanding detailed system requirements and specifications is the development of business and high-level requirements.
Business requirements are a high-level overview of the business processes that OpenLMIS (or any system) needs to support for the implementation. The business requirements will ensure the OpenLMIS is the appropriate solution and provide a foundation for further research and decision-making about the scope and phasing of the implantation, the amount of customization required, and prioritization of requirements and features.
Download: Sample High-Level OpenLMIS Requirements
Download: Sample Business Requirements
Every OpenLMIS implementation will involve various internal and external stakeholders. Understanding who the stakeholders are, their interests and priorities, and their power and resources, is crucial to implementation success. Stakeholders may be government officials or departments (MoH, Central Medical Store), implementing partners, other organizations or health information systems, donors, or local communities/officials. Conducting a thorough stakeholder analysis prior to starting an implementation will allow you to understand stakeholders’ interests and provide a foundation for effective stakeholder engagement and ensuring mobilization, buy-in, and support throughout the implementation.
Suggested resources for stakeholder analysis
In addition to stakeholder analysis, understanding the environment and context for the implementation is important to develop early on. Many countries have or are developing eHealth or digital health strategies, standards, and policies to govern the use of health information management systems in the country. These policies and standards can address ownership of the system, governing bodies, and approval processes, as well as set standards or requirements for hosting, interoperability, system access, and more. Identifying and understanding these policies is key to ensure that the implementation complies with all requirements and aligns with country strategies and priorities. Identifying these standards and policies early on also helps ensure that there is adequate time to address any issues and avoid potential issues during implementation.
Along with understanding policies and strategies in the country, it is important to gain an understanding of the other HIS/MIS in place in the country to identify what domains each system operates in or includes. Knowing the landscape will also allow the team to identify when OpenLMIS may overlap or interact with other systems, and how, to feed into requirements and planning for interoperability (even if only in future stages).
One of the best ways to familiarize yourself with the country landscape in which you will be working is to review that country’s eHealth Strategy, sometimes called the eHealth Architecture or Situation.
HealthEnabled, a non-profit that arose from the mHealth Alliance in 2014, has published example eHealth Strategy documents from several countries. These example documents can be viewed by visiting this page.
The cost of an OpenLMIS implementation can vary widely based on the location and scope of the project.
Important factors to consider when creating a cost estimate include:
Major cost categories for an OpenLMIS implementation are shown in the table below
Major categories that are cost drivers for each workstream are listed below