Successful OpenLMIS Implementation Models - Aligning Funder/MoH/Implementor/Community Goals (GOV)

  • Description: What are possible/preferred OpenLMIS implementation models for the future? Identify strategies for addressing the conflicting goals of country implementations (time, specific requirements) and funder/community goals (code reuse/contributions to core).

Leads: Sarah


To Join Remotely: 

Join the call: https://www.uberconference.com/info3285

Optional dial-in number: 716-293-6106

PIN: 63498


Rapporteur/Notetaker: Sandy Hawley

Notes from Session:

Marketing and Communications follow up discussion - "speed marketing"- when you talk about OpenLMIS, what are the most exciting things that come to mind? 

We all wrote down key messages on note cards - themes were very aligned within the group:

  • Low Resource/Last Mile Appropriate
    • Designed w/low infrastructure as an assumption- informs design, features and architecture
    • Resiliency to operate at the last mile
    • APIs to support different mobile low/no internet situations

  • Configurable/Flexible
    • Responsible, Extensible, Adaptable 
    • Configurable, Can be tailored to fit country needs
      • allows for faster deployment 
    • Interoperable with other electronic systems**
    • Users can configure rather than only developers (to an extent)
    • Gives flexibility to customize, expand and evolve

  • Shared Benefit/Investment
    • Community Driven
    • Multi-organization
    • Open-Source! ("free")
    • doesn't lock you into a single vendor
    • Collaborate effort of many donors & countries
    • An ecosystem- a collection of country-owned, open tools that together form a health information system that helps countries improve health outcomes
    • Collaboration between many IPs - enables a community of contributors
    • Code reused/shared by many countries, leveraging our investment
    • Donors, implementers worked together to develop, benefiting from each other's investments
    • Public APIs

  • Developed and Driven by Diverse Expertise and Implementations
    • Many experts on SC and IT have contributed to ensure tool support best practices
    • The "Community" brings multiple skills and real open system management expertise for growth and stability
    • 6 projects, 6 lessons that can be shared based on common platform
    • features have been developed from many different implementations and use cases - tried and tested
    • Learning how to build from actual use

 

  • Other
    • promotes local capacity 
    • Implemented in 5 countries; growing interest
    • automated notification to inform status and pending action
    • standard report and registration form to ensure proper/correct data entry
    • automated tool to reduce human error on repeat to requisition
    • collective tool for analysis and decision making by management
    • sustainable support to system
    • visual dashboard

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

(See Also Sarah's Slides)

IMPLEMENTATIONS - LESSONS LEARNED

  • Process by which community can put together guidance  docs or implementations- taking SCMS docs and adopting them for reuse in OpenLMIS - more simple
  • How does this work in an OS community?
  • Work going forward- project mngmt piece= more cost; we just have to define that as a priority, as people do additional projects, this just needs to be part of the standards, one of the principals, and include cost in order to do that in funding proposals

Group feedback on current implementations- any country-focused work - sticky note activity (See also artifacts below)

  • WHAT IS NOT WORKING:
    • expecting reusable code with unrealistic timelines, inexperienced developers
    • assuming all online from beginning
    • expecting users were at the facility level (not true)
    • optimal resourcing - people and skills on project not adequate (VIMS, MOZ) - all around, element of recognizing what it requires to pull off, and whether or not we have enough funding, having to prioritize
      • how do you approach project - challenge, what we need to do - but not enough $ or time are limitations
      • desire to move quickly, but not adequately resources
      • WHAT WOULD BP tell us, advise us- what comes first? Have to know its funded end to end- it's our community's reputation on the line
        • scope, cost, quality
      • BP (CHAI): we have a different view of how things should get done, that limits us in moving forward, but it helps in long term
    • USAID- feel like we are now in a better place- because we have the core now, and can build upon it
    • change management- when we are requiring users to do more, takes more time (doesn't work, so slow)-they  reject
    • transparency and trust; lack of reporting, not complete reporting because people fear result; some people not finishing their tasks because their not being paid to do more (incentive)
    • Money- everybody waiting for $
    • TZ- started LMU at the same time as eLMIS (which one had the impact?) - we created it thinking all facility users were entering data; pain points

  • WHAT IS WORKING: 
    • Being face to face- draw out similarities and differences, establish comms channels
    • CHAI funded TW - vision for development, CHAI- side contract for last mile/expertise
    • able to reuse - defined requirements and dependencies for reuse (if they could wait for it, deliver by X date, we can reuse, if not, we will go on our own-- this took many months
      • came up with 2 separate delivery plans- with and without dependencies (Rene has examples to share)
    • When MOZ was evaluating LMIS- we knew what VIMS was doing, what LMIS
      • QUESTION (What is the common code- need to figure out what is sustainable for long run- decision was made to use eLMIS)
    • TW had to commit code back to core; TW was the tech lead - set the stage, VR had to support; there was a contingency plan so we didn't have to rush 
    • TW has a define process for Software dev - requirements gathering was very successful, good planning, understanding user needs
      • highly focused on software delivery 
    • Permission that delivering sub par wasn't an option- no pressure to deliver in unrealistic timeline
    • Planning for co-design

OTHER OPEN SOURCE EXAMPLES

  • iHRIS: Implementation Toolkit- completely reusable/adaptable- countries contributed more than 100 resources 
    • framework: Gov, PM, software, data sharing, data standards, data reporting
    • assess, plan, deploy, 
    • don't start from scratch
    • funded by through IntraHealth- USAID Global Capacity Project, resources were developed by bi-lateral (country level)

LOOKING FORWARD (New World 12+ months)

  • Core- doesn't change often, tested, proven
  • Community supported models (not all countries need- i.e bar code)- decision process where the community has to sign up and agree to support
  • Custom Modules 
  • Roadmap
  • Communication processes (See Sarah's Slides)

EXAMPLE PROJECT PLANNING THEMES

  • Countries on timelines, doesn't match with desire to bring it back - curating isn't cheap, so lets get it done right - but how do we police it- proof of concept is so important- HOW DO WE FUND IT?
  • Value from custom modules - some will be easy to contribute, some won't be - decide on whether or not its custom
    • just because they aren't core, there is still value
  • Documenting planning processes and realistic planning models: timelines and funding for donors
  • setting expectations about how reusable custom modules are in the beginning vs. with more use cases
  • When implementations start- want community to determine what is core or not; make funding available to implementers for items that the community wants
  • Assumes that we have an admin process in place: Is VillageReach funded? Community needs to be transparent. Gates grant (on the Wiki):
    • BUILD OUT CODE BASE (driven by Community)
    • BRINGING THE COMMUNITY TOGETHER
    • WORKING WITH BROADER AUDIENCE, STAKEHOLDERS, INCREASE AWARENESS
  • Set the expectations: OpenLMIS is not a custom solution-everybody has to give a little bit- little incentive for MOH to agree to that- if a Donor is funding that, it's easier to get donor to understand the need to build it right the first time; deadlines can't be arbitrary 
    • country doesn't care about the global good; need to get to the bottom of the timeline issue
    • emphasize the things that are unique to their needs
    • there is a cost to doing bespoke - if this is a priority, make it part of delivery plan
  • More flexible UI that can be customized more easily (small wins) 
  • Value: set expectation with Donors and Countries - Donors will fund the system if it's flexible/ Countries need to understand.

 

Artifacts:

 

 

 

 

 

 

 

OpenLMIS: the global initiative for powerful LMIS software