Notice C

Promoting the collaborative development of proposals for investments in digital health global goods

Digital Square supports investments in digital health global goods, which are tools that are adaptable to different countries and contexts. Mature digital health global good software is software that is (usually) Free and Open Source (FOSS), is supported by a strong community, has a clear governance structure, is funded by multiple sources, has been deployed at significant scale, is used across multiple countries, has demonstrated effectiveness, is designed to be interoperable, and is an emergent standard application.

We are using an open proposal process. Your concept notes and proposals will be publicly posted, giving you and other submitters the opportunity to find collaborators and provide and receive feedback from your peers.

Communication Channels and Information OPP&P Directions

Concept-Notes (48 total)

Displaying 31 - 35

OpenELIS Community Building through Documentation, and Participation within LIS Community of Practice

Submitted by Nancy Puttkammer on Fri, 07/20/2018 - 17:27 Last revised by Caitlin Bowman (Digital Square) on Thu, 01/16/2020 - 12:31.

Notice C Opportunity:

Announcement C0: Global Good Software Development and Support

Executive Summary

Laboratory information systems (LIS) are a critical component of national health information systems architectures. Clinicians, lab professionals, national health sector leaders, and the donor community look to lab data to improve patient care and treatment, assist laboratories in achieving accreditation, support disease surveillance efforts, and inform outbreak responses. Effective national laboratory systems typically include clinical laboratories as well as reference laboratories at regional or national levels. Reference laboratories have distinct information management needs, such as the need to manage a large catalogue of test options, to handle batch processing of samples, to run test samples for quality control, and to receive orders and dispatch results to lower-level laboratories at high volume.

The primary open-source product which fills the distinct use cases and workflows of reference labs is OpenELIS (https://sites.google.com/site/openelisglobal/). OpenELIS was originally developed in several state public health laboratories within the US, and has since been adapted and deployed in Vietnam, Haiti, and Cote d’Ivoire at wide scale, and has also been integrated into and deployed with the leading OpenMRS distribution, Bahmni. Key features available within OpenELIS include: flexible test catalogue management; batch processing of bio-samples; barcode generation and printing capability; “plug and play” integration with automated analyzers covering a wide range of test types; integration with a data visualization dashboard to display indicators for national surveillance; generation of CSV file exports to facilitate flexible indicator reporting to a variety of stakeholders; and language localization in English and French.

The proposed project will significantly improve resources which enable health sector personnel to efficiently deploy, adopt, and use OpenELIS, advance awareness of the features and value proposition of the OpenELIS product within the laboratory sector in LMIC, and widen the community of stakeholders interested in maintaining and enhancing OpenELIS and other open-source LIS for long-term sustainability of system implementations and software products. Together the activities will contribute to improved availability of viable open-source LIS which support quality of laboratory practice in low and middle income countries (LMICs).

Consortium Team

The consortium team is led by the University of Washington (UW), including two groups which will come together to carry out this proposal: the International Training and Education Center for Health (I-TECH) (https://www.go2itech.org/) and the UW Clinical Informatics Research Group (CIRG) (http://cirg.washington.edu/). I-TECH is a Center within the UW Department of Global Health (DGH) that leads health systems strengthening initiatives in more than 20 countries. I-TECH has led OpenELIS development and implementation in Haiti and Cote d’Ivoire since 2009 and 2010 respectively. In Haiti and Cote d’Ivoire, I-TECH has supported implementation of OpenELIS in more than 75 national public health reference labs as well as in large-volume clinical laboratories. As a part of the Haiti project, I-TECH has established integration between OpenELIS and OpenMRS, and has established an OpenHIE-based interoperability layer, which is suitable for supporting data exchange between LIS and EMRs as well as between LIS and the DHIS2-based national aggregate data reporting system.

As of October 2018, I-TECH is supporting the launch of a unified Global Health Information Systems (GHIS) Unit, which will serve as a central hub within I-TECH and the UW DGH for health informatics expertise, under the leadership of faculty member Dr. Nancy Puttkammer. The GHIS Unit brings together experienced I-TECH staff from separate country teams with a range of expertise relevant for health informatics in global settings, including in requirements gathering and technical design, software development, implementation planning, technology project management, human capacity building and training, data analytics, and assessment and evaluation of digital health solutions. The GHIS Unit is set up as a distinct business unit with a flexible mechanism for contracting technical assistance services to serve digital health project needs for Principal Investigators (PIs) from across UW, or to serve clients outside of UW. This mechanism offers the potential to harness expertise from faculty, staff, and students from the UW’s Schools and Departments including Health Sciences, Computer Science and Engineering, Bioengineering, Information Sciences, Business and others.

I-TECH also brings to the project the expertise in laboratory systems in LMIC, through ourLaboratory Systems Strengthening (LSS) Team. Led by Dr. Lucy Perrone, a public health laboratory advisor specializing in infectious disease diagnosis, surveillance and response, and laboratory capacity building in LMICs, the team leverages partnerships within UW and with external collaborators globally on supporting laboratory capacity building. The team’s mission is to improve laboratory operations for optimal patient care and treatment, disease surveillance and response, and biosecurity. The team has conducted training and mentoring in laboratory leadership and management, supported policy development for laboratories, and worked with reference and clinical laboratories on advancement toward accreditation. As part of reinforcing good laboratory practice, the team has also supported customization and implementation of LIS for improved information management within the laboratory. The LSS team is available to contribute expertise in the fit between LIS and laboratory workflows and systems to the proposed project.

The UW team also includes CIRG, one of the premier HIS and LIS community building and software development teams, under leadership from Jan Flowers. CIRG designs, develops, builds, and operates information systems that securely manage health information for projects in clinical, public, and global health settings. CIRG has led numerous lab informatics projects involving OpenELIS and BLIS, founded OpenLabConnect, developed LIS interoperability projects, and has worked in Haiti, Cote d’Ivoire, Kenya, Mozambique, Cameroon, Namibia, and Vietnam. Ms. Flowers serves on the board of directors for both OpenELIS Foundation and OpenMRS, and is one of the founders and lead for the LIS COP, which was funded under Digital Square Notice B to develop and share common standards and best practices amongst the open-source LIS community.

Resumes for key staff from the UW team including the GHIS Unit and LSS team at I-TECH, and CIRG are included as attachments to this proposal.

Project Description

Problem Statement

Complete and accessible documentation is a key component to the success of any digital product and open-source community. Well written and easily accessible documentation can make selecting, using, and/or contributing to an open-source product a positive experience for a Ministry of Health, a software developer, an implementer, and a user. Although OpenELIS is a robust LIS, knowledge of the product and its potential value within the community of global health informatics practitioners is lagging. Limitedcore product investment results in gaps in documentation and stewardship to build a strong community around this open-source product. Basic documentation exists in some areas for OpenELIS, including a variety of information for developers on the OpenELIS Github Wiki (https://github.com/openelisglobal/openelisglobal-core). However, a more robust set of documentation could improve engagement and increase implementation success by all those roles involved in OpenELIS, and help strengthen a community that shares and builds knowledge among experts, stakeholders, developers, implementers, and users.

Demonstrated Need and Potential for Health Impact

LIS are a critical component of national health information systems architectures. Clinicians, laboratory professionals, national health sector leaders, and the donor community look to laboratory data to improve patient care and treatment, assist laboratories in achieving accreditation, and support disease surveillance efforts and inform outbreak responses. First, LIS play an integral role in laboratory quality management (ISO 15189) by improving organization and management of bio-samples and testing queues, by reducing transcription errors in laboratory results, and by reducing turnaround time for diagnostic test results. Second, LIS can facilitate a critical link between the laboratory and clinical services, so that patients can be appropriately diagnosed and managed in light of accurate and timely laboratory test results. Finally, LIS can contribute to disease surveillance by improving the availability of laboratory data at regional and national levels. As low and middle income countries progress in development of coordinated eHealth investments, LIS can be leveraged to integrate with other clinical information systems and with disease surveillance and reporting systems.

Presently, OpenELIS is a leading open-source product with particular value for use in high-volume reference laboratories. Effective national laboratory systems typically include clinical laboratories as well as reference laboratories at regional or national levels. Reference laboratories have distinct information management needs, such as the need to manage a large catalogue of test options, to handle batch processing of samples, to run test samples for quality control, and to receive orders and dispatch results to lower-level laboratories at high volume.

There are several existing open-source LIS products focused on smaller clinical laboratories, such as Basic Laboratory Information System (BLIS) and Senaite Labs (formerly Bika Labs). These systems address different use cases than OpenELIS and are optimized for the workflows of basic clinical labs operating within clinics and smaller hospitals, where a limited array of laboratory test types and a limited volume of tests are run. These systems can play complementary roles to OpenELIS within national laboratory networks.

In contrast, OpenELIS fills the distinct use cases and workflows of reference labs. OpenELIS features such as batch processing, barcode generation, and analyzer integration provide laboratories processing high sample volumes with a means of reducing turnaround time.

The value of OpenELIS in LMICs is demonstrated by the persistent use of the product in more than 20 high-volume regional laboratories in Haiti more than 18 months after withdrawal of external donor funding. It is also illustrated in Cote d’Ivoire, where the Ministry of Health has shown its commitment to the OpenELIS product by expanding its use in regional labs over an alternative open-source LIS.

Technical Approach

This proposal seeks to a) improve and expand OpenELIS documentation as an open-source product; and b) raise visibility of OpenELIS within the landscape of open-source LIS through engagement with the LIS COP. Documentation and visibility will be expanded in such a way as to reflect the unique niche for OpenELIS as serving high-volume laboratories, within the context of a national laboratory network which includes multiple levels (from basic clinical labs to regional and national reference labs).

By building awareness and interest in OpenELIS as well as the broader open-source community, we expect to enhance the user base of the products and widen the community of developers and contributors with a stake in maintaining the OpenELIS product and its documentation. Situating the work within I-TECH’s GHIS Unit offers a model to sustain the functions of documentation, community management, and knowledge sharing over the medium to long term. As the user base for OpenELIS widens, the GHIS Unit can offer fee-based technical assistance in small to large units of service to organizations adopting and using OpenELIS, thereby generating revenue which can contribute to maintenance of the product, development and curation of resources, and stewardship of OpenELIS within the broader open-source LIS community. This is the type of model which University of Oslo and other organizations have successfully used to build a sustainable community related to DHIS2.

Project Description

Workstream 1: Improve OpenELIS Global Documentation

Considering that developers, implementers, and end users seek different information for different purposes, documentation for a software product such as OpenELIS must be created and maintained on several different levels. Additionally, OpenELIS is used in both Anglophone and Francophone countries, and so documentation must be maintained in both English and French, and created in such a way as to be easily translated into further languages as needed. Much of the existing documentation for OpenELIS was last updated in 2013-15, is available primarily in French, and does not reflect the current strengths of the product. In this activity area, resources for all three types of contributors (developers, implementers, and end users) will be expanded and redesigned to make gaining knowledge about and contributing to any facet of OpenELIS a positive experience.

With this documentation-focused workstream, we will pursue a documentation process which is highly relevant to the broader community of OpenELIS stakeholders and builds on best documentation practices and tools used by other open source products, such as OpenLMIS and OpenMRS. We seek to have stakeholders inform what should be documented, how documentation should be organized, and how it should look and feel. Such stakeholder engagement in the documentation process has the potential to build interest and engagement in the OpenELIS community and broader open-source LIS COP (see Workstream 2, below). Documentation will only be helpful if it is actually used.Carefully planned and packaged documentation has the potential to generate wider interest and participation in OpenELIS development, implementation, and use. The UW OpenELIS team will ensure that key documentation for implementers and end users is available in English and French.

Activity 1.1: Strengthen documentation for software developers seeking to contribute to OpenELIS. Figure 1 demonstrates the type of documentation for software developers and implementers which can improved. Updates to this documentation will include:

Orientation to the OpenELIS code base and database model;
Tutorial on setting up the OpenELIS development environment;
Repository of requirements and specification documents for existing features;
Documentation updates on all aspects of the technology overhaul currently underway to replace the Java framework, and to replace all end of life components as well as other security changes;
Tutorials on creating new analyzer plugins to the level that analyzer interfaces could be built by developers who are previously unfamiliar with OpenELIS;
Fully documented API available to help new parts of the health information ecosystem to easily interface with OpenELIS;
Links to existing tutorials on development processes (ie: requirements gathering, user-centered design, testing) and laboratory services.

Activity 1.2: Improve OpenELIS implementation documentation and guidance.With the move from tailored forks of OpenELIS for each laboratory toward a unified software which is highly configurable, there is a need to guide implementers on the ways that OpenELIS can support varied and diverse lab workflows. Currently, it is difficult to understand the implications of each option and how they work together without prior experience configuring the system. Figure 1 shows an example of standard operating procedure (SOP) for implementers, which would be updated and augmented. Documentation of this system would unlock its potential for new implementers trying to get started. Specific improvements to implementer documentation include:

Building a repository for current SOPs for OpenELIS installation and administration;
Providing a comprehensive “Quick Start” guide for implementers, covering everything from procurement guidance to how to install the analyzer plugins;
Setting up a file section to host existing analyzer plugins, installers and other software needed for implementation, as a companion to the installer to setup the software;
Creating an interactive mechanism for implementers to share feedback and contribute new documentation and analyzer plugins.

Figure 1: Updated Documentation for OpenELIS Developers and Implementers Is Needed

Activity 1.3: Redesign and enhance user-facing documentation for OpenELIS. I-TECH intends to revolutionize the way that OpenELIS users obtain help based on their context-specific needs. Currently, instructions on using OpenELIS are contained in a single user manual that users can find tedious and time-consuming to navigate. Some users, particularly new ones, appreciate having access to a broad array of materials that they can browse and learn along the way. Other users, especially those who are more experienced and familiar with a specific digital product such as OpenELIS, will want to quickly locate and use a specific resource in order to complete a data entry or reporting task. Figure 2 illustrates the existing user manual and the direction for the possible design of indexed, context-specific user documentation and help resources. Specific activities will include:

Enhancing the help menu to be integrated into the application and to be context-specific to the page a user is viewing. This work will be done as a model for others to continue to contribute to with additional contextual help information and integrations;
Converting the existing User Manual into a comprehensive, up-to-date library of job aids and written tutorials on all current functionality (including newer functionality, such as test management, barcode scanning, batch entry, and analyzer results import);
Providing users with access to a “Top 10” list of the most frequently accessed job aids.
Offering user-facing resources with a cohesive landing pad with a consistent look and feel, organized in a manner which reflects how end users tend to learn to navigate the system.

Figure 2: Updated Documentation for OpenELIS End Users Is Needed

Activity 1.4: Update the OpenELIS Global website. The OpenELIS public-facing website has lagged far behind the rest of the project, with many sections last updated in 2013-14, and is in dire need of an update (see Figure 3). As part of this activity, we will update the look and feel as well as the content of the website to reflect the distinct interests of the core audiences of software developers, implementers and end users. We will make sure that the updated website links to all of the improved documentation and has a navigation structure which is appropriate for each type of audience. We will also work to link the OpenELIS Global website to the LIS COP’s website and pool of resources. We will work with the COP to ensure that all documentation is complete, relevant and easily accessible and that implementation advice follows best practices. The UW OpenELIS team will work with the eDGH Center within the UW Department of Global Health (https://edgh.washington.edu/) for web development.

Figure 3: Updates to the OpenELIS Website Are Needed

Workstream 2: Community Building for OpenELIS and Other Open-Source LIS

In LMICs, where investments in eHealth are often supported by central resources, there is a tendency to look to a single LIS to meet all of the information needs in the laboratory sector. However, this perspective neglects the distinct needs of laboratories at different levels of the health system. Unless an ecosystem perspective is considered when LIS are selected and implemented, laboratories will continue to struggle with key gaps and mismatches in the tools they use for information management. In conjunction with the LIS COP, we seek to raise the visibility of open-source LIS products in such a way that highlights the complementary nature of these products. The goal of this Workstream is to broaden the user base of open-source LIS products, including OpenELIS.

In this area, we propose a series of awareness raising conversations, events, and discussions designed to meet the following objectives:

Strategically position open source LIS products to address laboratory information needs according to a country’s laboratory network context;
Expand knowledge about open-source LIS products and their integration into laboratory networks within the global community

Activity 2.1: Build evidence base on best practices for open-source LIS. Through robust participation in the LIS COP, such as via joining regular conference calls, the UW OpenELIS team will contribute to the evidence base and set of resources created through the LIS COP. In conjunction with core members of the LIS COP, the UW OpenELIS team will facilitate and participate in a series of discussions via community calls that leads to common, shared documentation across LIS products. These discussions will reflect best practices in: LIS product design, alignment of LIS products to various laboratory workflows, management of open-source product development, implementation of open-source LIS within various lab settings, and training and capacity building for laboratory and IT personnel who maintain and use LIS. Specific actions will include:

Invite I-TECH’s Laboratory System Strengthening (LSS) team and other laboratory experts (Association of Public Health Laboratories / APHL, African Society for Laboratory Medicine / ASLM, and others) to provide insight into laboratory processes, such as quality assurance monitoring, proficiency testing, and accreditation requirements.
Document user stories and use cases in a common manner useful for OpenELIS and other open-source LIS products.
Identify LIS COP best practices for documentation and artifacts from the LIS software development and implementation process which have common relevance for the open-source LIS community.
Participate in drafting, review, and finalization of shared documents and resources contributing to the LIS COP.

The output of these activities will be coordinated with LIS COP contributors, resulting in effective online documentation vetted and endorsed by the broader open-source LIS COP. These resources will help laboratory and health sector decision-makers compare products and learn from others about successful practices in LIS implementation.

Activity 2.2: LIS “Road Show”. The concept of a LIS “Road Show” will be planned in conjunction with the LIS COP. The aim will be to raise awareness of integrating open-source LIS products into the laboratory and eHealth system, including the possible role of OpenELIS in the context of a national laboratory network. The Road Show will involve building knowledge of LIS technologies, features, and implementation approaches, including OpenELIS. The LIS Road Show will include several activities playing out over the course of the 12-month project. These include:

Presentations and discussions in public forums, such as monthly webinars and “show and tells” with other members of the LIS COP. The UW OpenELIS team will help organize and will participate in at least 3 such events.
An “Open-Source LIS Marketplace” event to be held in conjunction with the annual Global Digital Health Forum Conference or the annual OpenHIE Implementers meeting. The UW team will plan, organize, and market the event. To facilitate participation of laboratory-sector leaders from at least two LMICs, the UW team will sponsor at least two attendees, based upon an open application process for the sponsored slots. This event will be participatory and involve the opportunity to interact with demonstration versions of the various LIS software products.
A traveling “LIS Road Show” event showcasing OpenELIS and other open-source software products. A team including at least one member of the UW OpenELIS team will complete visits to at least two resource-limited countries (such as Angola, Democratic Republic of Congo, Malawi, Cameroon, Mozambique, Kenya, Zimbabwe) to demonstrate the LIS COP products and to evaluate fit for their national laboratory system information management needs. As an output of the visits, we will create sample implementation plans for the appropriate LIS product, outlining the considerations for each particular setting should they choose to deploy one of the LIS products.

Use of Digital Health Technologies

Across the two workstreams, the UW team will collaborate with the LIS COP. Technologies which will be used during the proposed work include: OpenELIS Global v8.4 (https://github.com/openelisglobal/openelisglobal-core), the OpenELIS Global website (https://sites.google.com/site/openelisglobal/), and other LIS products such as BLIS, Bika, and Senaite.

OpenELIS is a standards-based open source laboratory information system that was initially developed by state public health laboratories in Iowa and Minnesota to support standard laboratory business processes as defined by the Association of Public Health Laboratories (APHL). It was forked and adapted into OpenELIS Global in 2009 by I-TECH and CIRG at UW to support both the basic and advanced clinical laboratory workflows in low-and-middle income countries. Since then, it has been continuously improved upon by multiple organizations to meet both a broader set of LMIC laboratory use cases and needs, and adapted by implementers for specific local and regional context. It has been implemented in Haiti, Cote d’Ivoire, Vietnam, Kenya as part of the national eHealth architectures, and is integrated as part of the core offering of the Bahmni HMIS distribution, used across multiple countries. In recent years, I-TECH has led software development and implementation of the global fork of OpenELIS, now in version 8.3. OpenELIS is built on a platform using Java, PostgreSQL, Tomcat, Struts, and Ubuntu 16, and I-TECH plans to update the core product by moving from Struts to Spring (https://spring.io) in 2018-19 in order to ensure compliance with data security frameworks required in US government-supported laboratories.

OpenHIE LIS Community of Practice (LIS COP) is a new open source sub-community of practice under OpenHIE that serves to coordinate efforts on several widely-used mature open source LIS products - OpenELIS Global, BLIS, Senaite (formerly Bika) an open source independent lab instrument interface software called OpenLabConnect, and the integration of these technologies into the broader facility-level and upper-level HIS ecosystem. Created in 2013, the OpenHIE collaborative has defined a comprehensive design pattern for the national eHealth architecture in low-and-middle income countries. The collaborative offers example reference applications, and health information standards to serve as the component or external system functions, with published implementation guides, defined standards, and other resources available.

The Basic Laboratory Information System (BLIS) was developed in 2009 by Georgia Tech C4G with support from the U.S. Centers for Disease Control (CDC). Using the initial implementation in Cameroon as the setting of required functionality, the system focused on “keeping it simple” for facility-based laboratories in LMIC. Since then, multiple organizations have forked the codebase to improve upon those functions, modernize the technologies, and adapt for specific local context needs. Widely used under CDC funded programs, BLIS is a mature product that maintains its mission to be simplistic for its user base, while providing some more advanced functions behind the scenes to automate the workflow processes. BLIS will be part of the LIS “Road Show.”

SENAITE (formally Bika LIMS) was built from the ground up as a modern web application server in 2004 and was released publicly as open source software in 2005. Since then the system has added support for microbiology and branches for health care, water quality management and inter-laboratory proficiency testing. It is a derivative work of Bika LIMS software, built on top of Plone CMS with Python as its main programming language. It is developed under the paradigm of continuous integration (CI) and continuous delivery (CD) ensuring that can be reliably released at any time. There have been many architectural changes with respect to its predecessor Bika LIMS; SENAITE is developed as a system of independent add-ons. This makes the application much easier to maintain and to contribute to. Now the system focuses on high performance and stability, interoperability (it ships with an integrated JSON API), and ease of use through an intuitive user interface (UI) and –experience (UX). Today, SENAITE is sustained by a collective of users, developers and sponsors to keep to professional standards and away from proprietary pricing models. SENAITE will be part of the LIS “Road Show.”

Workplan and Schedule

The project is planned for a 12 month period. The workplan below lists tasks for each workstream and activity, and identifies who will be responsible (R), accountable (A), consulted (C), or informed (I). The workplan also shows the due dates for each deliverable as noted with “X”.

Project Deliverables

Documentation for developers:

Revised GitHub wiki with updates to support the new frameworks and security features
Fully documented API available on GitHub
Tutorial on analyzer interface building

Documentation for implementers:

OpenELIS Quick Start Guide (A-Z generalized implementation guidance)
Documentation on administrator functions added to User Guide and Quick Start guide

Documentation for end users:

Restructured Help page featuring job aids and tutorials for users at different experience and knowledge levels
Updated job aids on test management, batch entry, barcode printing and scanning, analyzer results import, and other emerging features

OpenELIS Global website:

Complete design for updated OpenELIS Global website
Updated content and links to OpenELIS documentation

Community building:

At least three webinars or conference presentations on open-source LIS products and best practices, including OpenELIS role within a national lab system
“Open-Source LIS Marketplace” event organized and held in conjunction with an existing global conference, with sponsored participation from laboratory-sector leaders from at least two LMICs
“LIS Road Show” visits to at least two countries to demonstrate OpenELIS and other open-source LIS products
Exemplary implementation plans for LIS in at least two LMICs
Links to all documentation hosted within LIS COP

Digital Health Atlas

OpenELIS is registered as a project within the Digital Health Atlas.

Overview Summary

The requested investment from Digital Square will fund stewardship of, and curation and documentation for the OpenELIS community, and participation of OpenELIS within the LIS COP, to enhance the availability of viable open-source LIS which support quality of laboratory practice in LMICs. This work includes an updated OpenELIS website to effectively communicate the features and value proposition of this software product, and documentation for developers, implementers and end users to facilitate their use of OpenELIS.

Community Feedback

The UW OpenELIS team seeks to engage in a regular manner with the LIS COP, funded under the Digital Square Notice B, and project deliverables will be highly dependent upon community input and feedback channeled through this forum.

Other key stakeholders with which we will engage include laboratory-sector representatives from I-TECH’s LSS team, the Association of Public Health Laboratories (APHL), and the African Society of Laboratory Medicine (ASLM), as well as existing developers (e.g. Bahmni Coalition), implementers, and users of OpenELIS. We will seek community feedback so that our documentation is highly relevant to the broader community of OpenELIS stakeholders, including developers, implementers and end users. Community engagement and feedback will be critical to building interest in the OpenELIS community and broader open-source LIS COP and to achieving the goal of an expanded user base for OpenELIS and other open-source LIS products in LMIC.

As laboratory systems are critical components to a country’s national health, there are many other groups within the global goods sector that we anticipate engaging with to work through the guidance around interoperability aspects between these systems. Interactions will be mostly through the LIS COP, and can be anticipated to include:

OpenMRS - interactions of patient identification, test orders, and test results;
DHIS2 - interactions of sending aggregate lab data for program monitoring;
Bahmni - LIS is a core component of Bahmni, and has sought the support of an LIS community to support that component within its system;
OCL - terminology to be utilized across the HIS systems, including LIS;
OpenLMIS - we would seek interactions to be developed for logistics and stock management of laboratory inventory within LIS workflows.

Beyond these direct and sought out interactions, the consortium will identify opportunities for presentation and publication of knowledge in informatics forums, participation in open-source health systems discussion boards, and will broadly disseminate knowledge about the experience and knowledge gained in this project.

User Stories

Workstream 1 User Stories

User Story 1.1a

As a software developer, I want to be able to read the documentation regarding the current code so that I can understand and make decisions for how to adapt or expand the code base.

User Story 1.1b

As a software developer, I want quick guidance at hand for setting up the OpenELIS development environment so I can get started in my development tasks as quickly and easily as possible.

User Story 1.1c

As a software developer, I want to have help on how to do specific things within OpenELIS so that I can know how to adapt the OpenELIS code base or modules to the requirements of the implementation I am working on.

User Story 1.1d

As a software developer, I want to access the previous requirements documents of the system features so that I can better understand the decisions that were made for how to code those features and how to interact with or modify that code as needed.

User Story 1.2a

As a systems implementer, I want to have guidance and instructions on how to implement the OpenELIS system into the different levels of laboratories so that I can be sure to follow best practices, ensuring a successful and sustainable implementation.

User Story 1.2b

As a systems implementer, I want to use existing SOPs for setting up the procedures around my implementation so I don’t have to build everything from scratch.

User Story 1.2c

As a systems implementer, I want to share my experiences, lessons learned, and implementation tools with other implementers to compare ideas and build upon best practices for OpenELIS implementation.

Conditions of Satisfaction:

Make sure contributors have a way to collaborate and contribute both synchronously and asynchronously
Make sure that contributors have a clear process for making contributions and how their contributions are vetted and accepted and acknowledged

User Story 1.3a

As a system user, I want to quickly find relevant help for the specific issues I’m experiencing without disrupting my workflow so that I can get back to completing my tasks at hand.

User Story 1.4a

As a stakeholder in an OpenELIS implementation, I want to be able to easily find and access information about the OpenELIS system and others’ experiences with it, and understand how to utilize that content for my context, so that I can make informed decisions about my work related to OpenELIS.

Workstream 2 User Stories

User Story 2.1a

As a member of the OpenHIE LIS COP, I want to learn what other LIS teams and communities are doing so that I can leverage the good work and lessons learned in the community we are forming and the products we are making.

Conditions of Satisfaction:

Make sure there is a shared space both synchronously and asynchronously for members to share and collaborate on their experiences and knowledge
Make sure share documentation and tooling is free and open for members and consumers to use and modify

User Story 2.1b

As a consumer of the OpenHIE LIS COP products and information, I want to be able to know that the community documentation and guidelines are vetted by laboratory experts so that I can feel comfortable using it in my system selection, implementation, and use.

User Story 2.2a

As a stakeholder in an LIS TWG, I want to be able to compare and contrast the various open source LIS products available to my Ministry of Health for implementation, so that I can decide what is best suited for my country’s context and the different levels of laboratories that will be involved in using LIS.

Conditions of Satisfaction:

Make sure comparison data is available as a one-stop shop rather than having to figure out how to curate the appropriate information across sources
Make sure product information makes it easy to identify which use cases those products best serve

Self-Assessment on the Global Goods Maturity Model

A self-assessment of the OpenELIS software product is included as an Appendix.

OpenLabConnect: An OpenHIE LIS community of practice development project to improve the Laboratory Analyzer Interface software

Submitted by Jan Flowers (University of Washington) on Thu, 07/19/2018 - 16:11 Last revised by Digital Square on Mon, 04/15/2019 - 05:58.

Notice C Opportunity:

Announcement C0: Global Good Software Development and Support

I. Executive Summary

As critical components of a national health system, laboratories must utilize standardized systems to collect, analyze, report, and provide laboratory data. The systems must be accurate, reliable, and timely for both the effective management and operation of a clinical laboratory and the assurance of reliable and timely laboratory results for clinical decision making. Data generated by these laboratories must be shared throughout the enterprise health (eHealth) architecture, or the health information systems (HIS) ecosystem, that manages information in a care, treatment, and prevention program for clinical decision making, disease screening, monitoring, blood safety and surveillance.

A common workflow of laboratories is the need to provide to and gather data from the various laboratory analyzers for the sample testing process. Not only is this process time consuming, but it is also highly subject to error because of the manual transcription of data between the order, the machine, and the results report. In addition, testing processes have very precise algorithms and rules for quality assurance and validation, which are often haphazardly followed in paper driven laboratories or those that only use an LIS alongside a manual analyzer resulting process. To mitigate these issues, an electronic interface can be used to bridge the exchange between an LIS and the laboratory analyzers. Historically though, much of the interfacing with laboratory testing instruments has been specific for that implementation, and tightly coupled to its software. This results in an intensive and burdensome process for additional or upgraded instruments to be added, and impossible to generalize for broader use.

This proposal aims to work under the OpenHIE LIS community of practice (COP) to collaboraitvely address this specific use case of laboratory analyzer interfacing by improving the open source laboratory interface software, OpenLabConnect into a generalized tool that is platform-independent and interoperable among multiple LIS. This tool will then be able to have collaborative development for these critical interfaces, despite laboratories using different LIS software. In addition, as part of the COP and building onto previous funding, this team will begin exploring and specifying interoperability of LIS with other key OpenHIE technologies for future collaborative development.

II. Consortium Team

The consortium will be led by University of Washington Clinical Informatics Research Group (CIRG) (http://cirg.washington.edu). Partners in the consortium include IntelliSOFT Consulting, RTI International, and Naralabs.

UW CIRG designs, develops, builds, and operates information systems that securely manage health information for projects in the Clinical, Public, and Global Health Informatics. CIRG is one of the premier lab informatics expert organizations, having led numerous lab informatics programs and projects throughout the world; including on OpenELIS and BLIS, founders of OpenLabConnect, and developing LIS interoperability projects. CIRG has worked in Haiti, Cote d’Ivoire, Kenya, Mozambique, Cameroon, Namibia, and Vietnam. CIRG leadership serves in multiple open source foundations and communities in both contributor and leadership roles. IntelliSOFT Consulting (http://www.intellisoftkenya.com/) is a leading Kenyan health informatics firm, focusing on HMIS, LIS, and Research Support Systems. IntelliSOFT has partnered with University of Washington for nearly a decade on multiple projects throughout Africa, including development and support for OpenELIS Global, BLIS, and interoperability. RTI International (https://www.rti.org/) works with governments and NGOs in 92 countries. RTI possesses an array of subject-matter expertise, including: HIS, ICT, health informatics, epidemiology, and disease surveillance. In Tanzania and Zimbabwe, RTI provided technical assistance to the ministries of health in areas that included strategy, capacity building, ICT, and data demand and information use. In both countries, RTI led the national rollout of the DHIS2. In Zimbabwe, for the CDC-funded Zimbabwe Health Information and Support Project (ZimHISP), RTI also led the LIMS deployment. Naralabs (https://naralabs.com/) is an implementer and founding member of the Bika Open- Source LIMS project. Based in Barcelona, Spain, Naralabs is a company specializing in LIMS and offers professional technology services and engineering, such as consulting, implementation, training, system maintenance, and technical support. BikaLIMS is currently being used in Argentina, Australia, Canada, Colombia, Costa Rica, France, Germany, Guatemala, India, Liberia, Namibia, Nigeria, Portugal, Puerto Rico, South Africa, Spain, Trinidad and Tobago, United States, and Zimbabwe.

III. Proposal Project Description

The OpenHIE LIS COP was created with the mandate to specifically be a virtual coordinating center for developers from different digital LIS to work together to identify opportunities for merging of code bases, or migration to a shared code base, to strengthen the efforts on LIS products. Our team aims to collaborate on the first development project under the OpenHIE LIS Community of Practice, formed in Digital Square Notice B. The coalition proposes to resource a technology development team to focus on a specific use case commonly required to address by most LIS implementations, bridging data exchange between the LIS and the automated laboratory analyzers. Part of this team’s mission will be to create a community development process and structure that will foster further open source collaboration on LIS technologies. The second focus of team will be to work towards solving this specific use case utilizing that community development process. The third focus of the team will be to look towards additional high-impact interoperability use cases for future collaborative development initiatives.

A unique aspect of laboratory informatics is automation with laboratory analyzer instruments. Historically in open source LIS, interfacing with these instruments has been accomplished through a labor-intensive process of point-to-point programming to access these proprietary machines data. With the release of the open source software OpenLabConnect (https://github.com/OpenLabConnect/OpenLabConnect), connecting to instruments can now be accomplished through a decoupled mediator which transports and transforms the data and commands to the proper destination in a standardized format for consumption. Currently, this software is limited to use with OpenELIS. But there has been strong consensus among LIS developers that this is needed for any LIS. Therefore, we propose having a dedicated funded team to work within the community to:

Expand the OpenLabConnect software APIs and workflows for use with multiple LIS for instrument interfacing;
Develop documentation and supporting materials for the OpenLabConnect software; and,
Provide technical support to community members for implementation and use of the software.

Actvity 1: Community Development Process

Since open source communities cannot always rely on long-term engagement of a core team of developers, it is imperative that the LIS community prioritize the creation and implementation of a community development process that will enable productive collaboration from distributed team of multiple contributors coming as freelance individuals or from an organization, with varying levels of commitment. This activity will result in a community that is not owned by a single organization, and is not reliant upon a single organization’s core team and contributions for long-term sustainability of the community.

Specifically, the coalition will need to work with the COP to ensure the following is ready for use:

Shared software development tracking tools, such as a shared JIRA instance
Process for prioritizing roadmap(s) for collaborative technologies development
Process for validating design and architecture proposals prior to development
Asynchronous discussion tools
Community agreed upon development policies, including, coding conventions, developer privileges such as commits, and onboarding processes for new developer contributors

Activity 2: Technologies Development

As part of this proposal, the core technology development team will work on expanding the decoupled laboratory interface tool, OpenLabConnect. The goal of the development will be to expand the compatibility with two additional LIS (BLIS and Senaite), and to improve the mediators for additional laboratory analyzer support. In doing so, the following activities will be conducted:

Assessment of existing analyzer interface approaches with BLIS and Senaite to leverage lessons learned, identify technical specifications for compatibility with those systems, and to identify possible code for supporting the expansion of OpenLabConnect
With the community, design and build specification to expand OpenLabConnect; Validate specifications with community;
Development of prototype, QA, initial release
Develop documentation and supporting materials
Engagement of Implementation Partner for Pilot Testing and Feedback

After successfully completing the initial phase of OpenLabConnect interoperability with BLIS and Senaite, the team will explore and conceptualize additional services for OpenLabConnect, such as, bi-directional communication; enhanced administrator controls; enhanced alerting, notifications, and data quality interactions; enhanced queuing functionality for offline processing; cloud hosted solution; and exchanges with other health systems.

Activity 3: Interoperability with OpenHIE

In addition, laboratory data must be accessible beyond the laboratory information system to support high quality clinical care, early warning systems, supply chain management, and program monitoring. To further LIS integration with the larger HIS ecosystem and to start towards providing reference LIS applications for use with the OpenHIE design pattern and technologies, our team would propose leading the following activities under this effort:

Development of specifications for interoperability of LIS to the Shared Health Record, DHIS2, and OpenMRS; and,
Assessment of efforts to develop interoperability of both OpenELIS, BLIS, and Senaite to that specification.

Outcomes

Expected outcomes from this funding include:

Finalizing the community development structure, processes, and policies for collaborative development projects;
Testing the community development structure, processes, and policies in a real-world project and identifying areas for improvement;
Expansion of the decoupled OpenLabConnect software for instrument interfacing with additional LIS products;
Specifications for integration into the larger facility-level and upper-level HIS ecosystem, and assessment for efforts to implement into specific LIS products;

IV. Tagging

Laboratory and diagnostics information system
LIS
LIMS
interoperability
OpenHIE

Application Status:

Out of Scope

OpenLMIS: advancing a collaborative, open and growing community

Submitted by Mary Jo Kochendorfer on Fri, 07/20/2018 - 12:30 Last revised by Digital Square on Mon, 04/15/2019 - 05:59.

Notice C Opportunity:

Announcement C0: Global Good Software Development and Support

Executive Summary

OpenLMIS has a growing number of implementations deploying the shared global version 3 with increasing demand and interest in new country implementations. This proposal seeks funding to support these new and future adoptions, help them contribute improvements back to the open source community, and provide ongoing releases as the community grows to a critical mass. The OpenLMIS initiative started in 2008 and already powers health supply chains for over 11,000 health facilities across 9 country implementations. OpenLMIS:

Serves as a critical electronic system in the health supply chain ecosystem in multiple countries and across multiple programs (Essential Medicines, Family Planning, EPI, etc.). For example, in Malawi it is nationally deployed and supporting five different programs.
Is a designated Global Good by the Digital Square initiative.
Adheres to and supports the Principles for Digital Development.
Engages in global initiatives striving to set standards for digital health supply chains (from leading the OpenHIE Supply Chain sub-committee to participating in the Health Data Collaborative working group for Logistics Management and Information System).

OpenLMIS is supported by a community of health, technical, and financing partners working collaboratively to improve product availability by providing accurate, timely data enabling informed decision-making to improve the reliability, responsiveness, agility and efficiency of health supply chains. We believe that ensuring the right product is in the right place at the right time using an electronic logistics management information system (LMIS) is critical for quality healthcare delivery to patients.

This Notice C consortium proposal is being submitted on behalf of the OpenLMIS community to seek support for community-requested feature development (see the Project Description section for details). With this funding, the community can support the growing number of countries deploying OpenLMIS, while still remaining responsive to the needs of existing implementations. Specifically, the community will support the current deployment in Malawi and the upcoming deployments in Angola, Mozambique, and potentially in Benin and Cameroon. Notice C activities will include new community-requested features to support new implementations, conducting releases and maintenance/fixes, and helping implementations contribute their enhancements back to the shared global version, resulting in greater capacity for this open source community to support a larger number of adoptions on one shared, common codebase.

OpenLMIS received Notice B funding to support a basic level of advocacy and community coordination on responding to prospective implementation opportunities in 2019. To compliment the advocacy work, it is essential for the community to obtain support for software development to continue improving the core codebase as the OpenLMIS community determines its long-term sustainability plan (see Sustainability process slides and watch the Governance meeting notes for updates every month). Implementers rely on ongoing support and continued improvements, both in performance and new usability features, so they can continue to scale their implementations and expand their use of OpenLMIS. Scaling implementations in terms of the number of facilities and users to increasing the number of programs leveraging the system from Essential Medicines to EPI.

Why support OpenLMIS?

The OpenLMIS philosophy and feature set is what sets OpenLMIS apart from other products in the supply chain space. OpenLMIS is grounded in the vision of:

Fulfilling shared investment and benefit by promoting code reuse through a microservice architecture and community approach to defining features and building software.
Building towards interoperability by identifying and supporting industry best-practice standards and implementing an API-driven strategy to facilitate integrations across the electronic health system ecosystem.
Designing with the goal of configurability and extensibility by leveraging a modular architecture and extension mechanisms to support ongoing upgrades and continued benefit from future releases.
Developing high-quality, enterprise-level code with a highly inclusive team rooted in a collaborative and transparent culture of excellence.
Working towards sustainability of the open source community through multiple initiatives, including building capacity for software development closer to end users and implementations in Sub-Saharan Africa, as well as undergoing a sustainability planning process funded by the Bill & Melinda Gates Foundation.

Background Context

In the last 2 years, the OpenLMIS community has made significant strides towards its vision of shared investment and benefit by releasing version 3. Version 3 was re-designed to allow country implementations to share the same core code base while still facilitating country-specific configurations and extensions. One country is already using Version 3 at national scale across five programs and demonstrated how the new architecture supports reusability and shared benefit by facilitating contributions back to the core codebase.

In addition to the new implementation, a handful of countries are in different stages for adopting version 3, including active implementations in Angola and Mozambique, and likely implementations in Benin and Cameroon as well as other prospects in the evaluation and planning phases. During 2019, we will also continue outreach to all 9 existing country implementations for them to upgrade to the shared global version of OpenLMIS, so that the entire OpenLMIS community is contributing and working on a common codebase. For details on these countries, the new implementations and status, visit the wiki for updates.

Consortium Team

We propose leveraging a consortium of team members that have a strong track record of working together to deliver value for the OpenLMIS community. All work of the consortium is governed by the OpenLMIS community through a transparent open source process including Governance, Product, and Technical Committees with stakeholders representing the whole global community. Size and number of organizations will depend on funding levels. For more details see the Project Description section.

VillageReach

VillageReach was established in 2000 to address the challenges of delivering quality healthcare at the last mile to the most underserved communities. VillageReach works with ministries of health to solve healthcare delivery challenges in low-resource environments. In addition, VillageReach serves as current stewards for the OpenLMIS community and software development of re-architected OpenLMIS version 3 and subsequent releases. As OpenLMIS stewards, VillageReach provides key leadership roles within the OpenLMIS community. VillageReach manages the software development and community coordination by supporting the core community processes and managing the software development across the four development teams.

JSI

In business for almost 40 years, John Snow, Inc. (JSI) is a public health management consulting and research organization dedicated to improving the health and wellbeing of individuals and communities throughout the world. JSI has over three decades of experience optimizing supply chains in lower and middle income countries and contributing to global best practices in data visibility and use, system design, human resources for supply chain management, and commodity security. JSI was one of the initial members of the OpenLMIS community and enhanced an early version of OpenLMIS for Tanzania, Zambia, Côte d’Ivoire and, most recently, Guinea. In all these countries, the applications are deployed at national scale and are fully institutionalized within the health sector. As such, JSI’s subject matter expertise and ongoing operational engagement are crucial for bridging the existing gaps between those implementations and the OpenLMIS Version 3. JSI is actively working on Version 3 to implement priority features from those implementations.

Ona

Ona is a Nairobi-based software and consulting company that offers technical consulting, design, and software-related services for organizations and projects of all sizes. Ona is a core member of the OpenLMIS governance committee and is actively developing an Android client based on OpenSRP and the OpenLMIS data warehouse. The company’s consulting clients include WHO, UNDP, HNEC - Libya, The World Bank, UNICEF, and DFID. The Ona team has nearly a decade of experience designing, developing and implementing ICT enabled solutions for humanitarian, development and global health contexts. This includes developing one of the first national-level SMS facility-based reporting tools. When possible, the company tries to build on top of supported platforms and tools like Ona, RapidPro, DHIS2, and OpenMapKit, allowing them to build reliable, scalable solutions for lower cost. Ona follows an agile methodology to ensure projects are delivered on time and on budget. The team has extensive experience developing in Django, Clojure, Javascript, and Android.

SolDevelo

A dynamic IT company focused on delivering high-quality software and innovative solutions. SolDevelo started contributing to OpenLMIS in 2016 during the re-architecture effort and continues to support the global community since then. It has a deep expertise in the IT projects management and development, gathering experience in various projects during the last decade. SolDevelo has been involved in many opportunities that required skill sets relevant to this particular project, especially OpenMRS (core contributors), HL7 FHIR (OpenMRS Sync 2.0 module), nation-wide micro-service based implementations (OpenLMIS), and nation-wide OpenHIE architecture based implementations (National Health Infrastructure project with such components like OpenELIS, DHIS2, OpenMRS and many other HIE compatible applications, health standards-based workflows for the Client Registry, Facility Registry, Health Management Information System, Shared Health Record, and Interoperability Layer).

Project Description

Notice C funding will allow the OpenLMIS Consortium Team to support new implementations, help them contribute improvements back to the open source community, and provide ongoing releases as the community grows to a critical mass. OpenLMIS uses an agile process, and this proposal team has a track record of delivering features with that process throughout 2018. The agile process means that we do not have a waterfall-style timeline for the exact specifications that will be delivered during the proposed project. Instead, we have identified priority features (below) that we wish to build if fully funded. At the same time, the community will continue to be responsive and flexible during this project to act on the needs of country implementations. The open source community’s governing committees review and approve the roadmap on an on-going basis, and our track record of outputs (below) is transparently shared at all times.

Key Features

The following are the highest priority features. A full list of requested features is here.

Support for distributions and reallocating stock between facilities (user stories). The OpenLMIS community wants to enhance the local fulfillment workflows to support an end user in planning a distribution to multiple facilities at once and identify excess stock in nearby facilities. If a facility is running low on stock they will have visibility to nearby facilities. These features support a high-value supply chain workflow requested by many current and prospective country users.
Offline support for stock management features (user stories). There is a need to integrate with third party mobile applications and support offline web browser features. Some facilities will have a desktop computer while others can leverage a tablet device. At the moment OpenLMIS supports online stock management features in the web application and integration with two mobile applications (OpenSRP and SIGLUS). Benin, Malawi, and Mozambique have all expressed the need for offline stock management features so that they can leverage the current desktop computers in facilities with intermittent connectivity. OpenLMIS would like to support both integrations with third-party mobile/tablet applications and offline features within the web application to reach the last mile.
Collect program data alongside supply chain processes (user stories) to support user-friendly customization of data collection forms by implementers. This work allows collection of health metrics and indicators during supply chain reporting workflows. We propose to build this feature via an integration with a third-party open source application (our specifications to date focus on ODK and/or DHIS2). This featureset allows implementers to collect programmatic data alongside of supply information. The community sees a need for this in HIV and within immunization programs.
Request, order, receive/unpack and ship “kits”, or bundles of products (user stories). Kits are common within HIV and essential medicines. This feature is a high priority for Mozambique (where implementation work is underway) and requested by other countries because bundling products together is key to supporting reordering for patient regimens and other related products.

Software Development Track Record

The consortium team is already delivering features using the agile methods proposed here. See the OpenLMIS Software Development Methodology.
Throughout 2018, this process has delivered consistent releases, each with significant improvements for country implementations and users. See the Release Notes which each contain a section on New Features.
For version 3.4 (just released), the consortium team completed 7 epics and 210 tickets (worth 477.5 story points). OpenLMIS always shares progress in a transparent manner using JIRA and the wiki.

Three committees--the OpenLMIS Product Committee, Technical Committee, and Governance Committee--allow the whole community to make requests, give input on new features and priorities, and govern the roadmap that guides development. All community activity is public and shared in the wiki. See the Community Committees with meeting agendas, notes, roadmap approvals.

Technical Approach

Over the past year, the OpenLMIS Global Software Development Team has evolved from one larger team to four smaller teams to meet the goal of locating developers closer to end-users. We expect the OpenLMIS Team Structure to continue to evolve in 2019 to support the growing number of Country Implementations using OpenLMIS version 3 and based on funding available to sustain global activities.

The depth of Global OpenLMIS Facilitation activities will depend on available funding in 2019 from Digital Square. For Notice C, we have prepared to different budgets for review. Option 1 is for minimum funding and Option 2 is for proposed funding. BMGF has supported Global OpenLMIS Facilitation in previous years (through 2018). With minimal funding, we propose to conduct the “bare bones” activities on the left (see diagram below) to keep the product available for use. If funding in 2019 matches the level in Option 2 (proposed funding), we propose to conduct the additional activities on the right to keep the product competitive and relevant to make a positive impact on supply chains in global health.

Technology Approach

OpenLMIS version 3 uses a micro-services architecture to allow multi-country customization and sharing of features. Software development uses Docker, Java, and AngularJS with an open source contribution process that follows community conventions. The community leverages a wide number of open source tools including ReadTheDocs, GitHub, Jenkins and more. Each of the new features the community hopes to build will be within the re-architected framework. Reference the linked user stories in the Product Description for more details on the technical approach for each feature group.

Expected outcomes

Below we list the direct outcomes of the fully funded proposal. We are providing two different budgets and narratives, one for minimal funding (Option 1) and one for the full proposed funding to support new features (Option 2). If the proposal is not fully funded (if the minimal or a smaller amount is approved), the following will need to be modified. In combination with these outcomes we believe OpenLMIS not only enables implementers to improve product availability by providing accurate, timely data enabling informed decision-making to improve the reliability, responsiveness, agility and efficiency of health supply chains, but also provides a shared investment and benefit model to pool resources across implementations. LMIS is a critical component to health service delivery and improving patient outcomes.

Quarterly software releases (plus additional patches or release if necessary) so implementers can pick up and leverage key new features on an ongoing basis. All software features will be ready for implementers to use immediately and are configurable, performant, translatable, fully tested (both manually and automated), and documented.
Releases will include fixes to blocker and critical bugs plus new features prioritized by the community.
Full transparency through working documentation in the wiki, finalized versioned documentation at docs.openlmis.org and through the three committees governing the OpenLMIS community.
Coordination and alignment with other projects, including coordination with country implementations, other open source projects that are integrated (such as OpenSRP, OpenHIE, DHIS2, and more), coordination with global donors, and coordination with Notice B activities (which are funding the OpenLMIS community advocacy work, including trips and outreach to implementers and country users).
Support enabling 2 to 4 new adoptions of OpenLMIS version 3 (Angola and Mozambique, and potentially Benin and Cameroon plus other prospects).

Workplan and Schedule

The estimated timeline for the project is January 2019 to December 2019 or 12 consecutive months.

Quarterly releases will include development of new features, fixes to critical bugs and improvements for code quality and performance. Each release includes detailed release notes and critical information for implementers in using the new release. New features are governed by the community prioritization process and available funding.
Technical and product committees meet every two weeks to review the status of the development, prioritize the roadmap, decide on technical frameworks and discuss any key risks/concerns.
Governance committee meets monthly to review progress and make decisions on the long-term sustainability and direction of the community.

The following release schedule estimates which features would be available for each quarterly release.

Please see the Project Deliverables section for additional information on when deliverables are available within the agile development cycles.

Project Deliverables

OpenLMIS operates on a two week sprint cycle following our agile methodology. The following project deliverables will be available on an ongoing basis. Some deliverables depend on level of funding and the project start date.

Four releases, following a quarterly calendar schedule, which include fixes to Blocker and Critical bugs. See definitions on priority ranking here. Bugs are submitted by implementers and the core development team.
Based on level of funding, each of the four releases will also include new features requested and prioritized by the community. The current top-priority roadmap features are listed above (see Project Description). The roadmap is updated and adopted based on input from the OpenLMIS committees, and Notice C features will be prioritized once 2019 funding levels are known in Q4 of 2018.

Each month the development team will review a burndown chart to evaluate progress towards defined feature goals (scope of features is dependent on funding amounts). The feature goals will be determined by the community in Q4 of 2018. Example burn down chart below:

Each software development team will be tracked using this dashboard to monitor the status of development daily within each sprint. Each sprint will produce the deliverable of sprint reports.
Shared value and investment will be monitored by tracking if implementers on version 3 continue to pick up available releases and contribute back features which they develop locally.
Monitor the number of new feature requests from community members and which are implemented to track the responsiveness of the community. This information will be reporting within the Release Notes of the quarterly release. See past examples here.
Bugs are monitored on a weekly basis and stats are available at any point in time (here) around how long they have been around and resolution date. A list of bugs addressed will be available in each quarterly release.
The codebase quality is measured by automated testing and the manual test strategy for each ticket, sprint and release.
Community participation measured in Slack, JIRA, Confluence, the 3 committees meetings and google groups. Stats will be available within the monthly reports to Digital Square.

User Stories

This Notice C proposal focus on two types of user stories:

User stories to support OpenLMIS country implementations
User stories to support OpenLMIS end users

The following user stories are derived from the needs of the community.

User stories to support OpenLMIS country implementations

Username: Implementer

Definition: A team which supports the country implementation of OpenLMIS. This team is responsible for deploying the system and providing both end user and developer support. The team will have the capacity to support software development.

User Stories:

As an Implementer, I want to receive quarterly releases that include fixes to critical and blocker bugs so that those bugs are addressed and that code is maintained long-term.
As an Implementer, I want to influence the new features developed in OpenLMIS so that I can continue to offer my users new features on the OpenLMIS platform with minimal financial investment.
As an Implementer, I want to submit pull requests to the OpenLMIS core codebase for review and acceptance so that I do not need to maintain the new feature locally long-term.
As an Implementer, I want new releases with improvements and enhancements so that my country deployment can continue to offer more valuable features, with limited financial investment, over time.

User stories to support OpenLMIS end users

Username: storeroom manager

Definition: an individual that uses OpenLMIS to record and manage their physical stock (from a small fridge of vaccines to a larger storeroom supplying larger hospitals). For simplicity, we are grouping multiple user profiles together to highlight high-level use cases the community aims to address within the desired new features (see the Project Description section for links to more user stories).

User Stories:

Distributions and Reallocations

As a storeroom manager, I want to see nearby facilities with excess stock so that I can inquire about transferring stock to avoid a stock out.
As a storeroom manager, I want to prepare a shipment of stock to multiple facilities so that I can distribute my stock among multiple facilities at one time.
As a storeroom manager, I want to distribute stock to multiple facilities so that I can allocate my current stock on hand efficiently to those in need.

Offline Stock Management

As a storeroom manager, I want to undertake stock transactions (issue, adjust and receive) when my browser or tablet does not have access to the internet so that I can easily record transactions when they happen and there is no connectivity.
As a storeroom manager, I want all my stocking data to be saved so that when connectivity returns I do not lose the data I have captured.
As a storeroom manager, I want my stocking data to automatically update whenever my device or computer is able to reconnect to the internet.
As a storeroom manager, I want to print a summary of my stock on hand information so that I can conduct a physical inventory or check stock levels even when the internet is down.

Programmatic Data Collection

As a storeroom manager, I would like to record additional data HIV regimen data when I request new stock so that upstream facilities know what stock to send my facility.
As a storeroom manager, I would like to easily record usage data alongside the stocking data I report so that my supervisors can see the usage and stocking data together.

Support bundling products together for “kits”

As a storeroom manager, I would like to “unpack” a kit or bundle of products to update individual stock cards so that my stock on hand is accurate.

The above user stories are further detailed within the OpenLMIS ticketing system. As a team begins researching a feature set, more user stories are defined and outlined. The above list is subject to change based on the level of funding received.

OpenLMIS leverages user stories to drive feature development. For more information on how the community submits new feature requests is here. To see the current list of feature requests, in the form of user stories, made directly by the community and through conversations with community members is here.

Community Feedback

The OpenLMIS community provides multiple channels for engagement both internally within the community and externally with the broader digital health community. To manage the OpenLMIS direction the community is organized into three governing committees:

Governance Committee: Provides leadership to the OpenLMIS community including defining community processes, leading fundraising and advocacy efforts and building a sustainable community. The governance committee meets monthly, and is made up of key donor and trusted implementation partners. Facilitated by OpenLMIS Community Manager in conjunction with the rotating committee chair.
Product Committee: Evaluates the product roadmap, requirements and incorporation of features into the product. The Product Committee meets every two weeks to review direction, update the OpenLMIS backlog as needed, share information regarding implementations and their relevance to the OpenLMIS platform, and decide what work from implementations should be incorporated back into OpenLMIS. Topics and agenda is populated based on member input and facilitated by the OpenLMIS Product Manager.
Technical Committee: Purpose is to “build the product the right way”. It makes strategic decisions on the “how” features will be implemented and the overall architecture of OpenLMIS. For more information on historical discussions, please visit our wiki and reference the charter, participant list and notes from all the meetings. The committee meets every two weeks and the agenda is populated by its members. All community members can use this committee and listserv to propose ideas for evaluation by the technical committee. Here is an example how any member and make a proposal with is discussed and evaluated. Meetings are facilitated by the OpenLMIS Architect in conjunction with community members making proposals or suggested changes.

For large decisions on roadmap direction and community processes in the OpenLMIS community calls for the Product Committee, which collaborates with the Technical Committee, to provide advice and present options to the Governance Committee. The Governance Committee then deliberates and decides upon a course of action following the posted voting process.

External Coordination Efforts

OpenLMIS values integration and following industry standards and best practices. As such, the community coordinates with other efforts in the digital health space either by active participation, like in the OpenHIE supply chain subcommittee or by welcoming external parties or other communities to present and discuss opportunities for future integration or collaboration. Examples of how this coordination happens is below:

Product Committee invites OpenELIS for discussion on overlap with lab equipment management and reordering of stock and reagents, here. There is also a Notice C proposal, pending funding, to create detailed specifications of the valuable points of integration. We hope this work is funded so we continue to explore the valuable integration between lab management and supply chain.
Key OpenLMIS members attend OpenHIE community meeting, trip report here.
Product Committee invites LoMIS to present on functionality to identify potential use cases for integration around transport management, call notes here.
OpenLMIS participates in the PSM-GHSC MIS deep dive conversation on information system maturity model, discussion and notes here.
OpenLMIS leadership participates in the DHIS2 Symposium to explore partnerships and stay informed on the DHIS2 community direction and product. Trip report here.
An OpenLMIS member, JSI, has submitted a Notice C proposal to open source an application they have supported. If funded, JSI will be responsible for presenting the application to the OpenLMIS community for evaluation of integration and long-term coordination.

Digital Health Technologies

The majority of health supply chains have a wide variety of needs for data management that cannot be met by a single electronic system. OpenLMIS is moving the needle on a variety of interoperability and standards discussions in order to advance system capabilities and features, but requires additional funding to continue to advance in line with the Maturity Model Core Indicator Software, sub-indicator Interoperability and Data Accessibility. The OpenLMIS philosophy and vision is to enable and encourage interoperability with other HIS tools utilized for health data management and to embrace global industry standards in order to create high-performing supply chains. Interoperability can provide a large number of benefits for health systems, unlocking potential to reduce the burden of data entry and management on health workers, providing responsive and comprehensive views of supply chain behaviors to decision-makers and facilitating integrated supply chains to increase efficiencies and accountability. Leveraging global standards pushes OpenLMIS toward the core of industry interoperable systems and puts the software at the forefront of critical conversations to advance the maturity of data management tools.

OpenLMIS will continue to utilize the following tools, technologies and standards:

Architecture. The architecture of the OpenLMIS software is designed specifically with interoperability at its core - providing RESTful API endpoints for all system components in a microservices architecture, allowing other systems to connect with independent services for different functional areas.

Standards

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

Mobile Architecture: OpenLMIS is actively defining a mobile architecture which extends the reach of the software, and visibility, to last-mile supply chain. This includes the development of a reference mobile application and a robust set of APIs to enable other applications to interface with OpenLMIS along with an evaluation of optical barcode support. Interoperability is completed with OpenSRP, a potential integration is under discussion with SIGLUS, and a side-car concept is being evaluated to enable supply chain best practices to be bundled into any third party health and logistics software.
Big Data Visualizations: To help OpenLMIS users make better sense of their supply chain data, the initiative has implemented a modern open source big data tool set and streaming architecture. With this we hope to establish a standardized community approach for consuming, processing, analyzing and visualizing logistics data from OpenLMIS. This infrastructure allows for ingestion of data from multiple systems to support analysis of information across systems in near real-time. This allows for the consolidation of big data processing across systems and enables the creation of composite indicators sourced from many disparate IT systems.
Tools: OpenLMIS uses a variety of open source tools to support the development and software. Some include: Jenkins, dockerhub, Maven Central Repository, IntelliJ, github, sonar, fisheye, Nexus, AWS, ReadtheDocs, Superset, PostGres, Kafka, Nifi, Boardthing.

Self-Assessment on the Global Goods Maturity Model

OpenLMIS Self-Assessment, here.

Digital Health Atlas

OpenLMIS is registered, here. Country specific implementations are registered as well.

Tagging

#SupplyChain
#OpenLMIS
#Interoperability
#Community
#Standards
#GS1
#End-to-Visibility
#OpenSource
#BestPractices
#Principles4DigitalDevelopment

2-sentence overview

OpenLMIS requests support in providing its growing and thriving community with new feature development, performance improvements and essential maintenance to support current and new country implementations. These features and updates aim to achieve the shared investment and benefit by providing value to all members while leveraging work done within each country implementation.

Technical Requirements Disclosure

OpenLMIS satisfies the technical requirements for C0 as noted below:

OpenLMIS is currently deployed and capturing data for over 10,000 health facilities across 9 country implementations. In addition, 2019 will bring at least 1-2 new country implementations and at least 1-2 upgrades to the latest version.
OpenLMIS is open sourced under the GNU AGPL v3 license (code is available on Github).
Software has been applied to multiple health domains, including essential medicines, reproductive health, immunizations, tuberculosis, HIV, and nutrition.

Application Status:

Not Governing Board Approved

OppiaMobile core development and new functionalities

Submitted by Roman Blanco on Tue, 07/17/2018 - 09:30 Last revised by Digital Square on Mon, 04/15/2019 - 06:00.

Notice C Opportunity:

Announcement C0: Global Good Software Development and Support

Executive Summary

Research on the introduction of ICT for training has shown that it is effective only when developers understand the strengths and weaknesses of the technology and integrate the technology into appropriate pedagogical practices. OppiaMobile, an innovative open source mobile learning platform for delivering learning content, video and quizzes, is specifically designed for low income countries and it is already being used in several countries, including Ethiopia, Nigeria, India, Pakistan, Liberia, Zambia, Lebanon,Ghana to deliver mobile-adapted training content for primary health care professionals. This system has a huge potential to become an open-source mobile learning platform standard for health professionals education and other learning areas.

OppiaMobile assumes that the user has limited Internet connectivity, so all features of the learning content and activities are stored directly on the phone and therefore function even when offline. When a connection is available, the stored tracking information, quiz scores, details of videos watched are sent back to the server. The OppiaMobile platform consists of three main components: a Moodle plugin for authoring, the OppiaMobile server, and an Android phone client application. All of the code is open source, enabling anyone to set up their own server/client application and customize as necessary.

The main expected outcomes of this proposal would be implementing the OpenBadges and xAPI standards, core platform development and maintenance, and building a larger development community.

Team

Digital Campus, a mobile learning development programme at the Fundacion General de la Universidad de Alcala, Madrid, Spain, is the creator and lead developer of the open source OppiaMobile learning platform, and have previously provided technical and training support to different organizations for other implementations of OppiaMobile. At Digital Campus we have extensive experience working with mobile technology worldwide. Since the OppiaMobile content is entirely open-source, it can be re-adapted to fit into training curricula across many countries and learning areas.

Project Description

The main work packages of this project will be to integrate the OpenBadges and xAPI standards, core OppiaMobile platform development and maintenance, and building a larger development community.

i) OpenBadges Integration

As part of the OppiaMobile gamification system, users receive badges when they complete courses. One interesting development would be to make the badging system comply with the OpenBadges specifications, as a way to share in a standard way skills and achievements after completing the learning content. OpenBadges are not just visual symbols of accomplishment. They contain detailed descriptions of recipients’ achievements and may link to evidence of individuals’ work toward earning the badge. Then, they are stored in Mozilla Backpack or other displayer where they get verified, so users are able to make them publicly available for others.

This development will include:

Redesign OppiaMobile badges system: system goals, criteria, how to manage evidence and categorisation.
Implementation of the server functionality to issue badges complying to the OpenBadges specifications.
Development of a system to easily create new badge images from templates and badge baking (embed assertion data into the badge image).

ii) Integration with xAPI

The Experience API (or xAPI) is a specification for learning technology that makes it possible to collect data about the wide range of experiences a person has (online and offline). This API captures data in a consistent format about a person or group’s activities from many technologies. This way, very different systems are able to securely communicate by capturing and sharing this stream of activities using xAPI’s simple vocabulary. It would provide a single integration requirement for different products/organizations to be compatible with a national integrated system.

This development will include:

Design meaningful xAPI statements that reflect the OppiaMobile learning activity.
Implement xAPI in the OppiaMobile server to fetch user activity.

iii) OppiaMobile Core codebase improvements

As with all technical development, frameworks are regularly updated and ongoing core maintenance is always needed to keep up to date. Also, the frameworks that OppiaMobile is based on (Python, Django, Android SDK, Moodle and so on) evolve and the project codebase has to keep up to date with aspects that are managed differently and functions that get deprecated.

A line of work would be to analyze code quality different metrics such as cyclomatic complexity, integration complexity and test code coverage to improve maintainability. This would result in a core codebase improvements for both the app and server side, with the following objectives in mind:

Make codebase follow recommended programming style guidelines
Make codebase more testable using standard design patterns, to increase the automated testing coverage.
Improve the project structure to reflect current logical structure and adapt to each framework guidelines.

iv) Building open source development community

Although many other organisations have implemented OppiaMobile, there have been very limited code contributions. Our development approach adheres to the Principles of Digital Development and liinked to the code improvements, this project would also look at how to make it easier to new OppiaMobile developers to set up and contribute to the OppiaMobile platform codebase, specifically, guidelines, issue/pull request templates, branch guidelines etc.

How your solution is interoperable with national health information architectures

OppiaMobile is already the content delivery system for the OpenDeliver process (combined with mPowering’s ORB training content library). Using the xAPI standard we feel is the best route for interoperability, given that OppiaMobile is a training platform, so the data generated and how it could link to national health information systems is different to data on patient/case management, decision support systems and others. Using xAPI is not intended to replace any existing standards that are in use, more to use an appropriate standard for the type of data.

Some initial prototype work on xAPI and integration with other platforms has already been done, most notably in Pakistan, with linking up patient/case data generated from OpenSRP with training data from OppiaMobile.

How your solution furthers the development of openIMIS and fits within the priorities and roadmap

There is evidence that improvements in primary health workers training help deliver better universal health (UHC). We are also building OppiaMobile to be interoperable with other systems using open standards (eg. xAPI).

Tagging

Mlearning
Primary Healthcare education
OpenBadges
XAPI
OppiaMobile
Mobile learning
Primary healthcare workers

Application Status:

Approved - partially funded

PIC2LIFE / TCHANDRA (IT4LIFE)

Submitted by Sébastien KUSZNIER on Fri, 07/20/2018 - 08:34 Last revised by Digital Square on Mon, 04/15/2019 - 05:58.

Notice C Opportunity:

Announcement C0: Global Good Software Development and Support

The idea is to create a mobile application enrolling pregnant women by matrones thanks to groups of 3 pictograms very easy to memorize, printable or reproducible. So to minimize the technical means available.
Once registered, the matrone still using pictogram can simply indicate the progress of pregnancy status.
The PIC2LIFE innovation and advantage in relation to existing tools consists in the ability to track, authenticate non literate people in the simplest way possible ( pictograms) but also being able to give them a precise geographical identity, easily exploited by persons having the code.
By relying on open source standards such as Odoo and DHIS2, the application will directly populate medical database together with the integrated GIS in offline mode based on Open Street Map.
And then medical teams can follow future mothers and complete their EMR through an adaptation or Odoo.
Concerning the data collection we will rely on Odoo. The application will be developed under Androïd and available in APK format so that it can be deployed in white areas on all types of compatible devices.
In the white areas, we will have to equip the health centers with radio coverage by using Ubiquiti technology, which allows a wide coverage at a lower cost.
Once the project is deployed, it is possible to rely on the infrastructure for epidemic monitoring; mandatory disease declarations; medical follow-up through SMS alerts; PB tracking with an extension of the PIC2LIFE application.

Application Status:

Incomplete

Notice C

Promoting the collaborative development of proposals for investments in digital health global goods

Concept-Notes (48 total)

OpenELIS Community Building through Documentation, and Participation within LIS Community of Practice

Executive Summary

Consortium Team

Project Description

Problem Statement

Demonstrated Need and Potential for Health Impact

Technical Approach

Project Description

Workstream 1: Improve OpenELIS Global Documentation

Workstream 2: Community Building for OpenELIS and Other Open-Source LIS

Use of Digital Health Technologies

Workplan and Schedule

Project Deliverables

Digital Health Atlas

Overview Summary

Community Feedback

User Stories

Self-Assessment on the Global Goods Maturity Model

Tags

OpenLabConnect: An OpenHIE LIS community of practice development project to improve the Laboratory Analyzer Interface software

I. Executive Summary

II. Consortium Team

III. Proposal Project Description

Actvity 1: Community Development Process

Activity 2: Technologies Development

Activity 3: Interoperability with OpenHIE

Outcomes

IV. Tagging

OpenLMIS: advancing a collaborative, open and growing community

Executive Summary

Consortium Team

VillageReach

JSI

Ona

SolDevelo

Project Description

Technical Approach

Technology Approach

Expected outcomes

Workplan and Schedule

Project Deliverables

User Stories

Community Feedback

Digital Health Technologies

Self-Assessment on the Global Goods Maturity Model

Digital Health Atlas

Tagging

2-sentence overview

Technical Requirements Disclosure

OppiaMobile core development and new functionalities

Executive Summary

Team

Project Description

Tagging

PIC2LIFE / TCHANDRA (IT4LIFE)

Pages