Get Started
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.
Downloads available on this page
Sample User Stories Template
Sample High-Level OpenLMIS Requirements
Sample Business Requirements
ThoughtWorks – User Stories 101
Engaging with the Community
What is the OpenLMIS Community?
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.
Why Community?
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.
What are Community Processes?
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.
Common Ground
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
- Public Health Informatics Institute: Finding Common Ground
- PATH: Common Requirements for Logistics Management Information Systems
- PATH: Planning an Information Systems Project
- JSI: eLMIS Selection Guide
- JSI: Computerizing Logistics Management Information Systems: A Program Managers Guide
- ITU: National eHealth Strategy Toolkit
- D4M: Guidance on Dashboards for Immunization Supply Chains
Scoping
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?
Requirements
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
- Interviews Interviews of individuals or small groups can be useful for requirements gathering. Interviewees can be asked to describe the process that they go through (that the system should support), the issues or pain points they encounter, how they address abnormalities or edge cases, and what the reality is versus the SOP (since they are not always the same).
- Process mapping Creating process maps can help define and visualize how the process flows, where the decision points or bottle necks might be, and what needs to happen in the system or outside the system.
- Observation Shadowing future users and observing them as they complete the tasks that will be done in OpenLMIS can be very informative for requirements development. It is especially helpful if you can observe people after a brief interview, to see if there are any differences in the actual process versus the process that was described, different edge cases that weren’t discussed, additional steps, or issues. It also provides an opportunity to validate the understanding gained from interviews or provide clarification.
- Review of existing materials Reviewing the existing software, forms, reports, or other data sources can provide insight into what information needs to be captured, in what form, and how that information needs to be made available to users. Understanding how and when the materials are used can also inform knowledge of the processes in place.
Developing requirements
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:
- Non-functional requirements (how many products, facilities, or users must the system support, what are the performance expectations etc.)
- Data migration requirements (is there a legacy system, and is data being migrated to OpenLMIS? If so, how much data, how will it be mapped, how will errors or inconsistencies be handled, does this data need to be available and how in OpenLMIS?)
- Configuration (Reference/master data) requirements (how should programs, products, facilities, geographic areas and other reference and master data be set up in OpenLMIS?)
Documenting requirements
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
Sample business and high-level requirements
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
Country landscape
Getting familiar with the country (or other) landscape and “ecosystem” in which the implementation will take place is key to ensuring a successful implementation. Understanding stakeholder priorities, the country’s electronic health information strategy (eHealth) and current system landscape will be crucial to long-term success and maintainability. Implementing without understanding the ecosystem is challenging and may be perceived as an unwillingness to collaborate.
Stakeholder priorities
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
- USAID: Stakeholder Analysis, a Vital Tool for Strategic Managers
- WHO: Stakeholder Analysis Guidelines
- World Bank: What is Stakeholder Analysis
- DFID: Guidance Note on How to do Stakeholder Analysis of Aid Projects and Programmes
Country strategies
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.
Cost Estimates
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:
- Amount of custom development expected
- Hosting costs
- Software licensing costs (for 3rd party reporting solution, development or issue tracking software, project management programs, system monitoring and maintenance
- Hardware – do project staff need additional hardware? Will the project provide computers or other devices (mobile devices, dongles, etc.) to users or deployment sites?
- Airtime/data services – are sites connected? If not or not reliably, will the project provide airtime or an alternate connection?
- Training costs – one of the biggest variables for a project: How many users will be trained? How long will the training last? Will attendees need to travel (and how far) for the training? Do large amounts of materials need to be printed?
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
