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 1 - 5

A DHIS2 App to enhance DHIS2 computational capabilities

Submitted by Marie-Hélène Wisecup (Bluesquare) on Fri, 07/20/2018 - 07:23 Last revised by Digital Square on Mon, 04/15/2019 - 05:59.

Primary Author: Antoine Legrand

Notice C Opportunity:

Announcement C0: Global Good Software Development and Support

Executive Summary

DHIS2 is increasingly used by Ministries of Health and their stakeholders to collect, manage, and analyze data for global health programs. While DHIS2 has powerful and flexible analytical capabilities, the system has limitations when it comes to doing complex calculations needed to implement, measure, and support decision-making for health programs. Governments and their partners currently use external tools to implement their performance monitoring and M&E frameworks that cannot be included in DHIS2. Enabling these more advanced computation and analytics functions to be performed from within DHIS2 would help streamline program management processes, utilize outputs generated from those equations within DHIS2, and increase availability and accessibility of that data to countries, donors and other partners.

ORBF is an open-source rules engine developed by Bluesquare to enhance DHIS2’s computational capabilities to support calculations for M&E and the allocation of performance-based incentives. It is interoperable with DHIS2 and currently used in eight countries (specifically Cameroon, Senegal, Malawi, Liberia, Uganda, DRC, Nigeria and Zimbabwe). However, ORBF is a standalone system that connects to DHIS2 via the API. The configuration of the rules and mapping to DHIS2 metadata is completed within the application. Despite ORBF being open source, the awareness and accessibility of the tool to the greater DHIS2 community of users remains limited, since it is a separate platform.

To enable broader community use of the tool, we propose to make the ORBF administration panel a DHIS2 app so that users can download it from the DHIS2 app store and use it to configure and manage rules and computations directly within DHIS2. This will make ORBF accessible from any DHIS2 instance and would actively draw on the DHIS2 community’s feedback to make future improvements. Additionally, digital square’s investment in ORBF will contribute to improving the user interface for designing rules, making program monitoring within DHIS2 easier for managers.

Consortium Team

Bluesquare is a technology company focused on universal health coverage. We build a set of tools that enhance the capabilities of DHIS2 to support governments and their partners to implement programs within DHIS2. Bluesquare has implemented data systems for governments and their partners in 24 countries. Bluesquare first launched ORBF in 2017 to support the calculations for incentive payments for RBF programs, but has since extended the capabilities to support broader M&E frameworks, based on project needs.

In addition, from a pure development perspective, Bluesquare is proud of its strong team of agile developers. They have broad experience in software development both in Bluesquare’s own products and with other custom products (i.e. we have a team working on a sleeping sickness elimination data platform). All of our developers have strong experience in interoperability of global public goods software. And at the heart of it all, the products we work with are all interoperable with DHIS2. From tools that link ODK to DHIS2 to a Data Visualisation tool enriching DHIS2.

Bluesquare will be the Prime. The company will lead the software engineering and create the documentation, as well as manage the project. Bluesquare’s team includes is comprised of software engineers, product managers, and project managers. Our team members have extensive backgrounds in technology and public health, and a long track record of developing, implementing, and delivering technology solutions for health systems strengthening. We provide their full CVs in appendix.

Bluesquare will partner with Abt Associates, an experienced program management partner working with DHIS2 systems across projects and countries. The identified partner will provide program management for the project in coordination with Bluesquare as the software developer, to carry out an agile software development, testing, and validation process, and ensure that the app creates value across a range of projects.

Abt Associates is a mission-driven, global leader in research and program implementation in the fields of health, social and environmental policy, and international development. Abt has more than 30 years of health systems strengthening and private sector experience working in more than 50 countries, tackling critical public health challenges in maternal, newborn and child health, family planning and reproductive health, HIV/AIDS, tuberculosis, malaria, and nutrition. Abt’s health systems strengthening work leverages technology solutions for robust monitoring and evaluation (M&E), and to deliver high-impact outcomes. Their team of programmers, developers, and system architects has deep experience in data systems, applications, usability assessments, implementing off the shelf solutions, web development, cybersecurity, e-learning, user experience (UX), quality assurance (QA) testing, and user acceptance testing (UAT). Abt also brings applied experience implementing and customizing DHIS2 solutions, including roll-outs across individual countries and multi-country M&E solutions through DHIS2.

For the DHIS2 App, Abt has relevant experience in developing, testing, and deploying applications. The team has developed more than 150 websites and applications using an agile development process that includes requirements analysis, design, testing and QA, implementation, and maintenance. This experience includes projects for USAID, NIH, and EPA. Abt has also been contracted to redesign or re-architect existing applications, including CDC’s TravWell and HUD’s HDX 2.0.

Related Work

Bluesquare is the developer of ORBF, and has implemented the tool at scale and trained users on the tool in 8 countries. To date, ORBF was developed in close collaboration with our partners to ensure that it meets their needs. Over time, those partnerships continue to play a key role in the iterative evolution of the the application.

Here is a list of the countries and use cases of where ORBF is currently being implemented.

Bluesquare has extensive experience in enhancing the capabilities of DHIS2 by creating tools that are interoperable with DHIS2. Bluesquare has developed and implemented a set of applications that are interoperable with DHIS2 including Data Collect, D2D, and DataViz. These tools are being used at scale in more than 20 countries. In addition, Bluesquare developed and has implemented OpenRBF, an open source Performance Based Financing Management and Data System that is deployed at scale in over 20 countries.

As a part of these and other projects, Bluesquare has extensive experience in setting up and maintaining DHIS2 systems. As a result, Bluesquare frequently encounters and has to overcome the limitations of DHIS2. To overcome those barriers, Bluesquare has implemented a series of open source tools, as well as built custom DHIS2 applications. Here we provide a selection of the DHIS2 applications we have implemented:

An app to control for data quality on historical data in the UNICEF WASH Data system in DRC, connected to the DHIS2 Tracker.
An app to support patient tracking, connected to the DHIS2 tracker for a Kangaroo Mother Care data system in Cameroon.
A facilities management app in the RBF data system in Cameroon.
A reporting app to enable navigation through linked reports for the PBF program in the HMIS in Liberia.

Abt has been conducting health systems strengthening and international M&E for more than 30 years. Technology and digital solutions, particularly DHIS2, have been critically important in providing cost-effective, usable, and timely monitoring to drive impact. Examples of Abt’s work include:

For USAID’s Health Finance and Governance (HFG) project (2012-2018) in 22 countries, Abt built an enterprise monitoring and evaluation system (MandE). The web-based platform features “out of the box” support for common needs like building work plans and indicators, and provides rapid start-up of high-quality M&E. Built-in tools allow non-programmers to design custom forms and indicators to capture each project’s distinctive data collection and reporting needs. MandE tracked more than 700 work plan elements and 100+ indicators involving more than 75 organizations.
For the President’s Malaria Initiative VectorLink project (2017-2022) in 23 countries, Abt is building out a DHIS2 instance for the spray operations and management to provide comprehensive M&E capabilities. A future phase of the project will also pull other data from available DHIS2 instances maintained by the country governments.
For USAID’s Health Systems 20/20 (2006-2012), Abt provided technical assistance to Kenya’s Ministry of Health for their roll-out of DHIS2.
For USAID’s Malawi-funded Support for Service Delivery Integration Systems (2011-2016) Abt provided technical assistance to Malawi to expand its DHIS2 capability and data reporting.

Number of years in operation

Bluesquare has been in operation since its founding in 2012. We are celebrating our 6th year.

Project Description

Problem Statement

Health Program Managers are stretched for resources and time. With more data available, they are looking for more efficient ways to understand their program’s progress. DHIS2 offers a platform to collect, manage, and analyze data in one place. By adding additional computational and analytic features in DHIS2, program managers would be able to make better use of the system for program monitoring and decision-making. Program managers would be able to better use the platform to manage programs and take action based on the data.

ORBF is a web-based, open-source rules engine that supports the computations needed for programs to implement M&E frameworks and the performance-based allocation of resources, such as in performance-based financing. It is a powerful tool that helps program managers better understand performance and where to target their support. It pulls data from DHIS2, runs the data through the algorithms configured in ORBF and sends the outputs back to DHIS2 as discrete data values of data elements. This enables the computed data to be used for analysis in DHIS2. However, ORBF is currently available as a separate application, which creates a barrier to access. ORBF is currently available on Github. There is an opportunity to enhance the accessibility of this tool to reflect the DHIS2 community’s requests for more advanced analytic features.

To make it easier for program managers to more proactively use their data and manage their performance using DHIS2, Bluesquare and Abt Associates propose to make an ORBF app available in the DHIS2 app store and to simplify the process of configuring rules within the app. As a DHIS2 app, ORBF will be a more relevant and sustainable application. It will also enable the DHIS2 community to provide feedback and help make ORBF an even more powerful resource.

Ways that ORBF will help to support data use in DHIS2 include the following:

Monitoring and Evaluation

Compare data between multiple periods (ex. Calculate the difference in performance of a facility between Q1 of 2016 and Q1 of 2017.
Group facilities based on performance (ex. Identify all facilities with at least a 10% increase in antenatal care between Q1 of 2016 and Q1 of 2017)
Conditional “if-then or AND” calculations (ex. If a health facility collects at least 20 patient satisfaction surveys, they they receive 50% of a score, and then if it also demonstrate that they made changes based on the feedback, they receive 100% of a score.)
Multi-part equations that need to be completed sequentially
Tracking progress towards targets

Understanding the relative performance to target resources

Risk-based algorithms (ex. Identifying which facilities need to be monitored most closely based on reporting rates and validity of self-reported data)
Categorizing facilities into high, medium, and low risk groups based on scores
Compute the relative scores of health facilities to distribute incentives within a budget envelope

Technical Approach

To improve ORBF’s accessibility and use within any DHIS2 instance, Bluesquare and its implementing partner will build a DHIS2 app that that connects to ORBF. The frontend for configuring and managing rules will be moved into the ORBF DHIS2 app.

System enhancements that would improve access and usability include:

Build an ORBF DHIS2 app available in the DHIS2 app store.
Move ORBF rules configuration and simulation into DHIS2.

Simplifying the process of building rules through the DHIS2 interface.
Create documentation for ORBF use, available from within DHIS2.
Create a forum for users to provide feedback on the tool.
Open the product roadmap.

Build an ORBF DHIS2 app

In this model, the whole front end of ORBF would be moved to the new DHIS2 App, allowing the RBF admin to manage its whole system without ever leaving DHIS2. This would be made possible by the creation of a REST API on top of ORBF2.

Configuring Rules within the App

The app will allow users to build complex rules, from within DHIS2, that are otherwise not supported by DHIS2. The ORBF DHIS2 app will allow the following activities (currently completed in ORBF) to be carried out directly from within DHIS2:

Select the DHIS2 metadata that will be used in the rules.
Configure the rules and computations by defining formulas and dependencies.
Define constants to be used in the computations.
Run simulations of the formulas within the application to test computation integrity before creating new metadata in DHIS2 and sending the results to DHIS2.
Select to which org units and org unit groups the computations should be applied.
Auto-generate metadata in DHIS2 to store the outputs of the equations (data elements, data sets, data element groups).
Track metadata created through ORBF for auditing purposes.

Improving the Rules Building UX

In improving the simplicity of using the rules building interface, we aim to offer the best tradeoff between a full rules engine, which would typically require knowledge in software development or highly specialized tools, and the simplicity and clarity of a well designed interface. We want to provide the user with parameterization and clear instructions for how to build rules, along with tools to validate their work at every step in the rules building process. This will to avoid mistakes early in the process, and give the user visibility into the consequences of each change.

How will each change modify the output?
How many org units, and which ones, will be impacted by the change?

This would enable the user to setup a complex system of interacting rules, without losing visibility to the consequences of each step in the computations.

In-application Rules Building Assistance

Providing DHIS2 administrators with a configurable rules engine provides a lot of autonomy, ORBF provides a lot of autonomy and flexibility, but it is also essential that users have a clear understanding of how the tools works to ensure that they are achieving the intended outputs. This is why, in addition to a standard manual, we propose setting-up the following documentation and support for users:

Open access to a live project for people to discover the software.
A wizard-like step-by-step guide to start and setup a new project.
Simulation at every step, enabling the user to run the engine without generating any real data, using randomly generated inputs if needed. This will show the outputs for validation of the rules at every step (so the user understands the consequences of their computations /edits).
Contextual help provided on each screen.
Description of fields displayed for easy reminders.
A visual representation of the decision-trees - the software will provide a visual representation of the rules in the project and how they are linked to each other.
A debug screen where the user can see all the values for every step of the process to be able to understand the source of possible misconfigurations.

Process

The project will be carried out through an agile methodology so that progress is being tested, validated, and iterated on an ongoing basis. This will ensure that partners are delivering the most robust results and they are able to deliver within the proposed timeline.

Use of Digital Health Technologies

ORBF - DHIS2 Interaction

ORBF is a rules engine that is interoperable with DHIS2. A foundational principle of ORBF is to avoid data duplication at all costs. This means that any data (values or metadata) that exist in the DHIS2 should stay there (and only there), and simply be used by ORBF.

To achieve this, ORBF uses the DHIS2 web API. Here is a (non exhaustive) list of data that is pulled from DHIS2:

Capture the health pyramid (Org Units)
Capture groups of facilities (Org Unit Groups)
Capture data set for the various input packages (Data Sets)
Retrieve input values (DataValueSets)

Once the process is done, ORBF again uses the API to send back the data to DHIS2, so that it is saved as discrete values in DHIS2.

In addition, ORBF provides the user with the ability to create the metadata necessary for using and storing the outputs in DHIS2 from within ORBF, and establish naming conventions for organization of data in DHIS2.

Rules construction and Dependencies between formulas

ORBF2 supports a wide array of rules, all able to use input and output from/to DHIS2. This includes, but is not limited to:

Rules using inputs from different periods

Using the past quarter value to generate a target for this quarter,
Generating a quarterly value based on monthly reported values

Rules using other org units as input. Example:

Generating an efficiency indicator compared to other similar org units
Using the price, weight, population defined at parent levels (country, region, district,...)

Distinguish if the value was set or not but default to 0 to allow smooth expression evaluation

Safe_div (obtained_points, possible_points) will return 0 if no possible_points are entered in the dataset instead of failing if there are no possible points or if the possible points are 0

Excel like expressions combining

Aggregation (avg, min, max, sum)
Conditional rules (If, Then, AND, OR, score table, safe_div)

Rules based on decision tables

if the value is in a specific region or group, get a specific input for the rule
If a given activity and org unit group, then apply “x” value

Target at different level - some rules are executed at the level of a single Data Element, some can act on a whole Data Set (example: multiplying number of activities by a price for each of them then summing altogether)
Cross reference between expressions of the same level or from the lower/upper levels example :

weighting the indicator obtained points by the total possible points,
spreading a district budget on all org units based on their performance score

Rules are constructed by:

Defining components
Grouping components that will be calculated together into Activities, and linking them to existing DHIS2 metadata
Grouping related Activities to which the same sets of rules will be applied into Packages and attributing qualities to those sets of components.
Generating rules per package, using the different components
Generaging rules that combine packages
Defining the outputs
Linking the outputs to DHIS2 metadata

Timeline

An anticipated timeline of 6 months is needed to build, test, iterate, and validate the software, as well as to create the documentation. Bluesquare will designate an additional three months to improving awareness of the app and building a community, finalizing documentation, and monitoring use of the application for the use cases over time.

While we propose here a prospective planning, our objective is to work in close collaboration with Abt, building on the use cases on an iterative basis. We’ll build the simplest system possible able to solve one of their use case, deploy it and collect their feedback. Once this element is working, we’ll work our way toward the next one. This will ensure that the system is built meet expectations along the way instead of evaluating it only at the end.

Note: The process that we use to work will be more iterative than is possible to reflect in a Gantt Chart. We work closely with our partners to build, test, and deploy the software one feature at a time at every stage to ensure that we are aligned throughout the process. Given the agile approach that we will take, these activities may shift during the implementation.

See here the full roadmap:

https://docs.google.com/spreadsheets/d/1i43DmkEhqEWbMz6YiBwjFnbicuN_WFLtTGt4SYJKDiE/edit?usp=sharing

Phases and Project Deliverables

Phase 1: Deployment of beta application within DHIS2 including simplified parameterization for building rules

Activities:

Software development to create the DHIS2 app
Software development to move the user interface for rules configuration into the DHIS2 app
Parameterization of the rules interface to simplify setting up rules
Improving the in-app wizard
Update documentation

Deliverables

Beta application that can be downloaded from DHIS2 (Bluesquare)

Timeline: Months 1 - 4

Global Maturity Model:

Core Indicator Improved	Sub-indicators Improved
Global Utility	Source Code Accessibility Digital Health Interventions
Community Support	User documentation
Software Maturity	Technical Documentation Software Productization Interoperability and Data Accessibility

Phase 2: Iterative testing and updates

Activities:

Setup use cases in test environment using ORBF DHIS2 App
Multiple Rounds of testing use cases - Abt will setup and test the use case
Open Jira Board to public for posting issues and feature requests

Feedback
Updates to app in accordance with feedback and prioritization

Deliverables:

ORBF DHIS2 App available for download in DHIS2 app store (Bluesquare)
Updated documentation available for download from within ORBF App (Abt and Bluesquare)
Open Jira board for posting issues (Abt and Bluesquare)

Timeline: Month 5 - 6

Global Maturity Model:

Core Indicator Improved	Sub-indicators Improved
Global Utility	Country Utilization
Community Support	Developer, Contributor, and Implementer Community Engagement Community Governance User Documentation
Software Maturity	Technical Documentation Software Productization

Phase 3: Expanding Awareness and Increasing Community Engagement

Activities:

Update and open the product roadmap on Jira
Hold a webinar to introduce the app to the DHIS2 community
Make video tutorials available from within the ORBF DHIS2 app and on the Bluesquare website
Write a blog and share it through various channels and listservs to introduce the ORBF DHIS2 app to the DHIS2 community
Update documentation, including a link to the product roadmap, and level of engagement on GitHub

Deliverables:

Webinar
Blog distributed
Tutorials publicly available

Timeline: Month 7

Global Maturity Model:

Core Indicator Improved

Sub-indicators Improved

Global Utility

Country Utilization

Community Support

Developer, Contributor, and Implementer Community Engagement

Community Governance

Software Roadmap

User Documentation

Phase 4: Monitoring and Evaluating use of the app over time

Activities

Ongoing feedback from Abt on implementation in the field
Ongoing review of feedback on the public Jira board, prioritization and incorporation of feedback into the product roadmap
Updates to the application based on feedback
Reaching out to known users to seek feedback

Deliverables:

Updated product roadmap (ongoing)
Updates to the app, tool, and community engagement requests based on feedback

Timeline: Months 7 - 9

Global Maturity Model: (Ongoing)

Core Indicator Improved	Sub-indicators Improved
Global Utility	Country Utilization
Community Support	Developer, Contributor, and Implementer Community Engagement Community Governance Software Roadmap User Documentation
	Technical Documentation Software Productization

Digital Health Atlas:

The following projects have been registered in the Digital Health Atlas:

Cameroon: http://digitalhealthatlas.org/project/CM4ed06188

Zimbabwe: http://digitalhealthatlas.org/project/ZWba1310dc

Sénégal: http://digitalhealthatlas.org/project/SN7c8f44e2

Description for a non-technical audience

The ORBF DHIS2 app will enhance the computational capabilities of DHIS2 to enable strategic purchasers, program managers and M&E staff to better utilize data in DHIS2 for program management, performance tracking, and decision-making.

What this investment from Digital Square will specifically fund?

The Digital Square investment will fund making ORBF easily accessible to a wider audience, and improving the ease of the use of the application. In addition, it will help to improve the awareness of the application by the DHIS2 community, and the ability of all to contribute into the ongoing development of the product to ensure that it evolves in line with the evolving needs of the community.

Community engagement

We recognize the power of the open source community to enhance applications to make them as relevant and usable as possible. To that end, ORBF will seek feedback from the DHIS2 community to evaluate whether the DHIS2 app is meeting the needs of the users, and adapt and build on the tool accordingly.

The consortium will foster and engage with a community o promote the use of the ORBF DHIS2 app, and receive feedback on the use of the app, as well as to raise awareness of the app and its use cases within the community through a multi-pronged approach.

Raising awareness of ORBF

Hold a webinar for the DHIS2 community and existing end users. The webinar will serve to introduce the tool, the use cases, and provide an explanation of where additional learning and implementation resources are available.
Create a blog with the Use Cases. The blog will be distributed to the registered community, as well as distributed through various digital and HIS channels including the DHIS2 listserv, global digital health network, ICTworks, The Digital Health & Interoperability Working group

Building and Engaging with the Community

Active engagement with developers on GitHub. Direct the developers oto the GitHub page for access to the code and to engage with Bluesquare developers to promote the use of the tool, as well as track ongoing updates to the code. This includes updating the technical documentation.
Creating a public Jira board. The Jira board will provide public access to the product roadmap, as well as provide a forum for users to report issues and product features requests.
Request community-wide feedback quarterly. Bluesquare will reach out to the community of existing ORBF users to request feedback on a quarterly basis on the architecture and design, user experience, existing use cases, and limitations of the software from the development community and implementer perspectives.
Hands-on engagement on specific projects. Bluesquare will identify and request ongoing feedback from specific projects to gain deeper insights into how ORBF is being used and what are the needs of the community.

Use Cases

Use Case 1: Abt is leading the Integrated Health Program in DRC (DRC IHP). It has demanding M&E requirements. Because of the complex calculations required to carry out these requirements and the limited computational capabilities of DHIS2 the program managers and M&E team need to manage the M&E in a tool external to DHIS2. By implementing the DHIS2 App we are proposing the M&E team will be able to set up dashboards within the DHIS2. It will also centralize the performance measurements. In addition, it provides the MoH with easy and transparent access to the DHIS2 dashboards on the program.

Use Case 2: Abt is leading the President’s Malaria Initiative VectorLink Project in 23 countries from 2017 to 2022. One component of the project is building out a DHIS2 instance for the spray operations and management. The M&E team is currently rolling out the first phase of DHIS2. Future phases will require linking indicators across the entire VectorLink portfolio of countries and generating dashboards for reporting metrics. The DHIS2 App would provide computational capabilities that are not currently available in DHIS2 and would greatly enhance the project’s M&E capabilities.

Use Case 3: The Ministry of Health in Liberia is updating their Result-Based Financing program indicators to match the evolutions in the program.t They currently distribute incentives based on the relative performance of health facilities. They calculate this based on the individual performance scores for a set of weighted indications. The MoH needs to be able to change not only these indicators but also the weighting of the indicators, and the set of additional parameters that are factored into calculating the relative performance, as well as the incentive distribution based on that performance.

Currently, the Ministry of Health uses ORBF, integrated with the HMIS DHIS2, to calculate the performance,the relative performance, and the incentive payments. In order to make the necessary changes, the HMIS will need to use the independent ORBF to update the rules. In the current format building rules leaves is not as detailed in the parameters leaving room for error, especially given the complex tree of rules to manage the set of equations. The Ministry of Health needs easy access to the tool, as well as a controlled setting for use that prevents changes that will break the existing rules to be able to independently maintain their PBF Data System. The new interface proposed directly within DHIS2 would be able to respond to both of these needs.

Self-Assessment on the Global Goods Maturity Model

The self-assessment on the Global Goods Maturity Model can be found here.

Tagging

Interoperability, M&E, Health Information Systems, DHIS2, Performance calculations, Performance-based incentives, Analytics

Application Status:

Approved - partially funded

An Instant OpenHIE

Submitted by Christopher Seebregts on Fri, 07/20/2018 - 05:33 Last revised by Digital Square on Mon, 04/15/2019 - 05:59.

Notice C Opportunity:

Announcement C0: Global Good Software Development and Support

Overview

Instant OpenHIE will radically reduce the costs and skills required for software developers to rapidly deploy OpenHIE architecture for quicker initial solution testing and faster production implementations. Instant OpenHIE will be a simple way for technical persons to install and see a complex system working for a real use case. It will allow technical persons to illustrate how interoperability will work to solve health challenges and show how a national interoperability architecture could be created with open source tools.

Digital Square funding will produce a preconfigured version of the OpenHIE architecture and reference technologies, optimized for LMIC workflows, in hosted demonstration environment. Particularly it will be going to fund time to invest in installation options, rapid configuration scripts and in creating needed mediators to meet the project needs.

Executive Summary

The OpenHIE community and architecture has grown in popularity and so has the demand for both an example of the instantiated architecture as well as a deployable option for new implementers to engage with. OpenHIE maintains a stance of being technology neutral and encourages each community to source examples of reference applications for each of the components.

Therefore there isn’t a preconfigured example of OpenHIE, and each implementer has to go through an audrigious process of setup and configuration for each solution, and its interoperability layer, before they can begin to test OpenHIE architecture, much less deploy a suite its components.

Instant OpenHIE seeks to bridge this gap and work with community partners to create a framework and deployment approach that will allow implementers to rapidly deploy a set of software tools that represent the OpenHIE architecture, complete with basic configurations to allow for quick initial testing and faster production implementations.

Instant OpenHIE will create a packaged version of OpenHIE architecture that is comprised of a set of the reference technologies and other appropriate tools. The packaged version will also have a published set of workflows available and be preconfigured to a particular use case, such as HIV case based surveillance, to allow implementers to engage with the solutions and test their applicability. This is also a starting point for implementers to customise and extend OpenHIE architecture for future country implementations.

Consortium Team

Jembi will coordinate and lead the consortium and in an agile manner work with partners to align work streams and deliverables to match the overall solution goal and plans.

Jembi Health Systems NPC (Jembi)

Jembi is an African non-profit company, headquartered in South Africa, and specialising in digital health and open source software development and implementation. Jembi has a successful track record developing and implementing open source software in the health sector including a number of African countries. It has contributed to many open source software development projects, including OpenMRS, OpenHIM and OpenHIE. Jembi curates the reference technology for the interoperability layer of the OpenHIE - OpenHIM (www.openhim.org) and related reference profiles like Hearth (https://github.com/jembi/hearth).

Carl Fourie, Senior Program Manager, has 10 years experience with the architectural teams, providing insight and guidance, and currently leads Jembi's OpenHIE activities.
Pierre Dane, Director of Technology, has over 15 years of technical experience and leads Jembi’s technical division with a strong focus on systems development and interoperability

IntraHealth International

IntraHealth International is a global health NGO with a long history in developing successful data tools for digital health applications. From mobile apps to management software to multilanguage interactive voice response, IntraHealth offers health workers and managers the tools and technology they need to do their very best work. As the developers and core contributors of the iHRIS workforce management solutions, the OpenInfoMan reference product for CSD and Interlinked Registry, as well as the mCSD profile for the FHIR specification, the IntraHealth team brings a passion for open source and open standards. The following IntraHealth staff will be the organizational leads for this project:

Richard Stanley, Senior Technical Advisor, has over 20 years of experience in information and communication technologies, including high-quality research and rapid data analytics for monitoring and evaluations in Somalia, South Sudan, Uganda, Egypt, and Sudan. He holds a PhD from the University of Oxford, UK.

Luke Duncan, Digital Health Assistant Director, has over 20 years experience in software development, including leading the developing of iHIRS, the flagship human resources solution for global health, and multiple data interoperability standards and reference designs to connect iHRIS, DHIS2, and OpenMRS.
Emily Nicholson, Technical Advisor, has over 10 years of experience leading and supporting digital health solutions including mHero, iHRIS, OpenHIE, DHIS2, and OpenMRS.

Project Description

Background

OpenHIE (https://ohie.org/) aims to improve the health of the underserved through the open collaborative development and support of country driven, large scale health information sharing architectures. The OpenHIE architecture and approach to Health Information Exchange design has grown in popularity over the past few years with many countries adopting the model and base architecture as a guiding principle for the foundations of national health information exchanges. The OpenHIE architecture is modelled around a component based approach with there being distinct architectural components that are responsible for key functional areas.

Figure: OpenHIE Architecture

Each component is represented by a community with curated reference technologies. Each community aims to be open and have multiple options of tools and technologies that are supporting the component. OpenHIE is first and foremost an architecture and an approach to health information exchange solutions and this is a message that the broader OpenHIE community has worked hard to bring to the forefront.

Problem

As OpenHIE has grown in popularity so has the demand for both an example of the instantiated architecture, i.e software that works as the OpenHIE architecture and workflows describes, as well as a deployable option for new implementers to engage with. While each community maintains the options of reference technologies there is not an available package of tools that will allow users to see OpenHIE architecture in action and test the system to understand its applicability.

Each implementer has to go through an audrigious process of setup and configuration for each solution, and the underlying interoperability layer, before they can begin to test OpenHIE architecture, much less deploy a suite its components. Both Jembi and IntraHealth have faced this issue first hand as they work with OpenHIE architecture in their respective programs, and have heard frequent complaints form the wider OpenHIE community that there should be an easier way to implement the framework so implementers can test and deploy the architecture while they still remember why they’re interested in OpenHIE functionality

Solution

This project aims to create a deployable version of the OpenHIE architecture that is preconfigured to work together and provide a demonstrable instantiation of the OpenHIE architecture. The project team will canvas the OpenHIE community, review existing components and their configurations, and create a viable deployable selection of OpenHIE technologies.

The Instant OpenHIE project is segmented into the following areas that are interrelated and build into each other and off of each other.

Step 1: Architecture and workflows

Working with the OpenHIE architecture community the team will review the OpenHIE workflows and identify a popular use case with wide applicability. At this point, the project team is proposing to take guidance from a generic HIV Case Based Surveillance set of requirements to ground the instantiation in a real world setting. The team may realign the case should an implementation partner wish to engage alongside the project. Then we will develop the set of workflows required of OpenHIE architecture to execute the chosen use case.

Step 2: Packaging and containerisation

The team will review OpenHIE component functionality and identify a minimum set that are required to meet the established workflows. The team will review existing deployment options of each tool and other existing works such as the SEDISH work undertaken by the I-TECH Haiti and SolDevelo teams where some of the OpenHIE components have been dockerized already.

Through this phase the team will engage with the tools and align the deployment strategies as well as configuration options and mechanisms to allow an easier implementation and instantiation of the OpenHIE architecture.

Outputs

Instant OpenHIE outputs include an instantiation of the OpenHIE architecture using a combination of reference technologies and updated workflows. The outputs will allow the OpenHIE community to point to an instantiation of the architecture in a set of tools that are easily deployable for implementers to engage with.

An additional output is a version of the architecture in hosted demo environment for the OpenHIE community that can form the basis for compliance testing of new components and interoperability.

Another critical set of outputs will be workflows based on the OpenHIE stacks, to include those common in LMIC contexts like a linked health worker and a facility registry (interlinked registry), connecting patient records to the RapidPro communications engine, and case-based patient tracking.

Table of Outputs

Name/Type	Description of outputs	Targeted environment	Technology stack
Packaging, image hosting, and documentation	Updated containerization and VM-oriented packaging for OpenHIM, OpenInfoMan, FHIR servers, mediators, OIM libraries. (Mediators are not containerized while prototypes exist for others.) Hosting of container images (e.g. Docker Hub) and other artifacts. Open source build files for anyone to reproduce Documentation Governance of image hosting and other repositories established and transitioned.	Desktop Datacenter Public cloud	Docker, APT, Ansible and similar
Provisioning with Docker compose and stack	Easy stack deployment for an HIE ecosystem using docker-compose and docker stack. Documentation.	Desktop Datacenter Public cloud	Docker compose Docker stack, Shell
Provisioning with Kubernetes	Kubernetes manifests for deployments, services, ingress, secrets, and configmaps. Code for public cloud deployment on one public cloud. Documentation on deploying prototype on desktop and how to deploy to public clouds.	Public cloud	Kubernetes, Shell
Provisioning of underlying servers	VM or VM with Docker provisioning tools. Documentation	Desktop Datacenter Public cloud	Vagrant, Terraform, Ansible, Shell
Configured workflow: RapidPro for patient reminders	Ready to use and reproducible tools to send reminders to patients in SHR or OpenMRS through RapidPro. End-to-end test harnesses to demonstrate the workflow. Documentation	Desktop Datacenter Public cloud	Shell
Configured workflow: Case-based patient tracking	Ready to use and reproducible tools to send track patients. End-to-end test harnesses to demonstrate the workflow. Documentation	Desktop Datacenter Public cloud	Shell

The development of packaged and deployable point of service or edge systems are out of scope of this project.

User Stories

The Instant OpenHIE project aims to address the primary needs of (i) allowing implementers to engage with a preconfigured HIE solution and running tools (based on the architecture) and test their applicability and functionality with a real health context problem; and (ii) having a packaged version of OpenHIE architecture that is comprised of a set of the reference technologies and other appropriate tools that form the building blocks of the HIE to be configured for particular use cases.

Below outlines the user stories:

Understanding OpenHIE Architecture

Sarah is part of a working group and project team that are responsible for investigating how to address a countries national health information system needs. Through their engagement they have highlighted a few key starting clinical areas that are covering many of the cross domain areas of work and data; such as human resources, facility information and identifying persons to name a few. Their working group has come across the OpenHIE architecture and workflows and would like to investigate it further. Sarah has been nominated to investigate the architecture and provide a review and technical demonstration of OpenHIE in action. While Sarah reaches out to other countries for opportunities to understand how OpenHIE has been implemented she also engages with the Instant OpenHIE deliverables. Sarah is able to provision a demonstration version of an OpenHIE architecture that is already configured to showcase a clinical workflow such as Case Based Surveillance.

Sarah is able to leverage the CBS Instant OpenHIE as a starting point for her implementation team, lead by Simon, to prototype and create a proof of concept solution that is contextualised to their setting and could be extended to meet the product need in future.

Testing OpenHIE Architecture

Sarah’s demonstration and implementation prototype has been successful and the working group has actioned a full scale implementation of the OpenHIE architectural solution for CBS for the country. Simon, team leader, is well aware that scale require innovative thinking around data centres and deployment architecture that is broader than “does the software do X”. Simon turns to the instant OpenHIE deliverables and leverages the packaged components and deploys them to the custom data centre architecture with the redundant services and load balancers required to maintain operations at scale. While the demo system covered the basics and the fundamentals Simon has extrapolated the learnings and configurations, identifying the pre-configurations that are not relevant to their deployment and which will be excluded from the live deployment, and engages with the clean deployment to customise the implementation and training materials to meet their needs. Simon works with Jeremiah (the technical and development lead) to ensure that any development changes are well understood and documented and changes are managed in the local implementations repositories (where the changes are not able to be contributed back to the core).

Digital Health Technologies

The project will leverage the OpenHIE architecture as the foundational architecture of the project and leverage the selected workflows from the OpenHIE workflows [https://wiki.ohie.org/display/documents/OpenHIE+Workflows]. The team will work with the architecture group and align to some of the workflows and emerging workflows that implementers have shown a strong interest in and the associated standards such as FHIR (http://fhir.hl7.org).

We are envisioning that the initial set of technologies under investigation will include, but are not limited to, the following tools:

OpenHIM (MPL v2 License) [http://www.openhim.org]

Associated workflow mediators

Hearth FHIR Server (BSD 3-Clause) [http://www.github.com/jembi/hearth]
OpenInfoMan (Apache License 2.0) [https://github.com/openhie/openinfoman]
ApelonDTS (Apache License 2.0) [http://www.apelondts.org/]

The project team will investigate other tools and solutions for the architectural components during the course of the project.

Community Feedback:

The OpenHIE community currently has a strong set of communities around each of the components of the architecture as well as a strong architecture community. The team will continue our engagement in these communities as well as leveraging the OpenHIE devops community to support the work direction and ideas that are being used.

The team will provide regular updates and assessment reports on the calls and use the teams and members of the communities to guide and affirm decisions and directions. A full list of OpenHIE communities are found here: https://wiki.ohie.org/display/SUB/Home

In addition to the core OpenHIE communities Jembi and IntraHealth will work with the teams in each of our own organisations and partners who are engaging with OpenHIE core components and workflows to have their needs and inputs form part of the end solution.

It is envisaged that the OpenHIE DevOps space would be the best space to convene this project’s discussions and inputs.

Self-Assessment on the Global Goods Maturity Model:

The following review is for the OpenHIE architecture:

Digital Health Atlas

Below is a link to the registered project on the Digital Health Atlas

http://digitalhealthatlas.org/project/ZA548b7c72

Work Plan and Schedule:

Activity		Deliverables	M 1-2	M 3-4	M 5-6	M 7-8	M 9-10	M 11-12
Architectural Review and Tool Selection		An Instant OpenHIE Technical Architecture document: Documented HIE architecture, component technologies and workflows selected to be instantiated Ongoing community engagement with OpenHIE DevOps community: community minutes
	- Review architecture and tools		x
	- Select tools to meet core architectural components		x
	- Identify and select key workflows		x
Containerisation and deployment strategies		Document outlining:For each tool an updated containerised (or appropriate) instantiation methodology The "containerisation" is committed back to the community Updated documentation on the tools community documentation / website links to solutions within each tool's space
	- For each tool review and identify the appropriate container/deployment approach			x	x
	- Work within the tools community to update or create standard deployment approaches			x	x
	- Update tool's documentation and advocate for community uptake for ongoing maintenance			x	x
HIE configuration and workflow instantiation		Repository of configuration scripts: - contains all configuration scripts required - links to the documentation on how to utilise scripts
	- Identify base configuration needs for each component and script the configuration options				x
	- Identify workflow interactions and mediator, HIM and component requirements				x	x
	- Create HIE workflow configuration scripting				x	x
	- Create workflow integration test scripts				x	x
HIE instantiation and testing		Hosted Demo HIE set of services that are "stood up" and "refreshed" at selected intervals
	- Action continuous deployment and "tear down" scripting to stand up HIE in hosted environment					x
	- Test deployment scripting on local machines					x
	- create documentation for cloud and local deployment					x
Use Case Configuration		Documented use case configuration needs Updated repository with use case configuration scripts Hosted HIE demo space with the use case demonstrated.
	- work with use case subcommittees within OpenHIE to identify the configuration requirements					x	x
	- create component configuration scripts to update "base" configuration to meet use case needs					x	x
	- update integration scripts and test scripts to demonstrate the use case in action						x	x
	- deploy updated scripts and documentation to repository and openHIE wiki for use						x	x

As the two teams leading on the work areas Jembi and IntraHealth will jointly address the work areas allocating work to each group as appropriate. Initially the work areas are envisaged to be allocated as follows:

Jembi	IntraHealth
An Instant OpenHIE Technical Architecture document Both teams will create an agreed architecture and workflow design document that outlines the components selected and workflows to instantiate
Containerisation and Deployment Solutions:
Jembi will lead in the developing of solutions for: Interoperability Layers Shared Health Record Client Registry Facility Registry and DHIS (jointly work on this with IntraHealth)	IntraHealth will lead in developing of solutions for: Health Worker Registry ILR ?Terminology Services? Facility Registry and DHIS (jointly work on this with Jembi)
Workflow selection and configuration scripts
Teams will jointly select core workflows and allocate component configuration scripts as best suited to each organisation.
Initial component configuration scripts responsibilities are: Interoperability Layers Shared Health Record Client Registry Facility Registry and DHIS (jointly work on this with IntraHealth)	Initial component configuration scripts responsibilities are: Interoperability Layers Shared Health Record Client Registry Facility Registry and DHIS (jointly work on this with IntraHealth
HIE instantiation and testing
Responsible for hosting solutions	Responsible for kubernetes and instantiation scripting
Allocation of testing and integration scripts for workflows	Allocation of testing and integration scripts for workflows
Use Case Configuration
Document Use case requirements and configuration document	Contribute to use case documentation
Update core component configuration scripts as allocated previously	Update core component configuration scripts as allocated previously
Develop integration tests for selected workflows	Develop integration tests for selected workflows

Project Deliverables:

The project will deliver the following high level outputs:

A documented and deployable solution that is based on the OpenHIE architecture. This includes

Updated documentation on OpenHIE wiki
Updates to core components code and project site of appropriate install solutions (see table for types)

Configuration scripts and solution to have the Instant OpenHIE meet the needs of a clinical use case (such as case based surveillance).

Deliverables	Timeframe
An Instant OpenHIE Technical Architecture document: Documented HIE architecture, component technologies and workflows selected to be instantiated	Month 1 - 2
Updated deployment and installation options for selected components	Month 5 - 6
Configuration scripts for each of the Instant OpenHIE components in a shared space/repository	Month 7 - 8
Hosted Demo HIE set of services that are "stood up" and "refreshed" at selected intervals	Month 7 - 8
Instant OpenHIE configured for particular clinical use case such as Case Based Surveillance	Month 11 - 12

Table of Outputs

Name/Type	Description of outputs	Targeted environment	Technology stack
Packaging, image hosting, and documentation	Updated containerization and VM-oriented packaging for OpenHIM, OpenInfoMan, FHIR servers, mediators, OIM libraries. (Mediators are not containerized while prototypes exist for others.) Hosting of container images (e.g. Docker Hub) and other artifacts. Open source build files for anyone to reproduce Documentation Governance of image hosting and other repositories established and transitioned.	Desktop Datacenter Public cloud	Docker, APT, Ansible and similar
Provisioning with Docker compose and stack	Easy stack deployment for an HIE ecosystem using docker-compose and docker stack. Documentation.	Desktop Datacenter Public cloud	Docker compose Docker stack, Shell
Provisioning with Kubernetes	Kubernetes manifests for deployments, services, ingress, secrets, and configmaps. Code for public cloud deployment on one public cloud. Documentation on deploying prototype on desktop and how to deploy to public clouds.	Public cloud	Kubernetes, Shell
Provisioning of underlying servers	VM or VM with Docker provisioning tools. Documentation	Desktop Datacenter Public cloud	Vagrant, Terraform, Ansible, Shell
Configured workflow: RapidPro for patient reminders	Ready to use and reproducible tools to send reminders to patients in SHR or OpenMRS through RapidPro. End-to-end test harnesses to demonstrate the workflow. Documentation	Desktop Datacenter Public cloud	Shell
Configured workflow: Case-based patient tracking	Ready to use and reproducible tools to send track patients. End-to-end test harnesses to demonstrate the workflow. Documentation	Desktop Datacenter Public cloud	Shell

The development of packaged and deployable point of service or edge systems are out of scope of this project.

Tagging:

Data interchange interoperability and accessibility
Facility management information systems
Health management information system (HMIS)
Human resource information system
Identification registries and directories
Public health and disease surveillance system
Shared Health Record and health information repository
OpenHIE
Architecture
Packaging and deployment

Application Status:

Not Governing Board Approved

Blood Safety Information System (BSIS) data exchange and device interfacing project

Submitted by Christopher Seebregts on Fri, 07/20/2018 - 05:46 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

Safe blood has been listed as an essential medicine by the World Health Organisation (WHO) and is used for treatment of things like; postpartum haemorrhage, trauma, childhood malaria and severe anaemia and malnutrition. Adequate access to safe blood can have a significant impact on developing countries ability to provide lifesaving care to vulnerable populations. For instance, the WHO and other international organisations estimate 25% of maternal deaths on the African continent could be prevented should health facilities have access to safe blood. This equates to an estimated 60,000 women's lives saved every year.

The Blood Safety Information System (BSIS) is designed as an Open Source digital health software tool to support low resource Blood Services to manage data about blood donors and blood donations from the point of donation to the point of transfusion. This includes the core blood services functions of transfusion transmissible infections (TTI) testing, serology testing and component processing, pack labelling and blood bank inventory management. It provides a low-cost option for information management and barcoded pack label printing for resource constrained blood services who cannot afford high cost proprietary systems built in and for the developed world, while maintaining the global standards for information management required to ensure that only safe blood can be labelled and issued.

BSIS has been successfully implemented and is in operational use in blood service centres in three countries Sub-Saharan Africa (Lesotho, Ghana and Ethiopia) with new implementations happening in Zambia and Cameroon this year. To date over 134,000 safe units have been processed, labelled and issued through BSIS. The Ghanaian, Ethiopian and Zambian blood services have plans to rollout BSIS to all their blood service centres in these countries (a total of 60+ additional sites) over the next few years. Jembi has also had interest in BSIS from blood services globally, including; Nigeria, Tanzania, Burkina Faso, South Sudan, Cambodia, Suriname and Mexico.

The proposed project will focus on both the development of significant new functionality for the Blood Safety Information System (BSIS) as well as the maintenance of the core product, including the existing codebase, over a 12-month period. The new functionality centres on 3 key areas: laboratory device interfacing, data synchronisation capability and multi-site interoperability. The requirements for the additional functionality proposed for BSIS have been identified and prioritised through a robust community-led process that includes the implementing Blood Services, their blood safety technical assistance organisations and the Africa Society for Blood Transfusion (AfSBT) accreditation requirements. In addition to meeting Blood Services' established requirements the additional laboratory device interfacing functionality should open up new possibilities for the BSIS business models by presenting an opportunity to generate revenue for sustainability through potential partnerships with laboratory device manufacturers, thereby facilitating the ongoing maintenance of the BSIS product.

Consortium Team

The BSIS product and technical team is housed at Jembi Health Systems in Cape Town, South Africa. This team works as part of a community of practice that includes Blood Service personnel from across Africa, their blood safety technical assistance organisations (AABB, Safe Blood for Africa and the WHO) and the Africa Society of Blood Transfusion (AfSBT). The team develop requirements for additional functionality in BSIS and manage the BSIS product roadmap according to community priorities to ensure that the new functionality will provide the most benefit to Blood Services where BSIS has been, and will in future, be implemented. Jembi is exploring possibilities to expand the technical development team to include contributors from in-country organisations in countries where BSIS has been, and will be, implemented. Jembi is also actively pursuing partnerships with lab equipment manufacturers. This forms part of our wider BSIS sustainability strategy.

Going forward we would like to expand this community of practice to include the OpenHIE community, AeHIN and additional members of the AfSBT. We will do this by making use of the existing community platforms (in which Jembi is currently active) to demonstrate the application and elicit feedback on the solution design, interoperability specifications and use cases, as well as the implementation design.

Jembi Health Systems NPC Capability and Experience Statement

Jembi is an African non-profit organisation registered in South Africa with country offices in Mozambique, Rwanda and Zambia. Since 2009, Jembi has established a reputation as one of the leading specialist health information systems organisations in Africa, delivering needs-driven solutions. Jembi has country programs in South Africa, Mozambique, Rwanda and Zambia, and a rapidly growing continental footprint through projects in other African countries. Our core competencies include: needs assessment and requirements gathering, analysis, system and solution architecture design, software development, implementation and capacity building, and monitoring and evaluation.

We act as ethical mediators, develop software, analyse and re-engineer health systems and undertake research on the application of health information systems (HISs) in developing countries. We are committed to independence and impartiality, and the utilisation of good practices in the digital health domain.

We have extensive experience in collaborative projects and implementation with inter-sectoral and multi-disciplinary groups of stakeholders from national governments, local and international organizations and consortia, academic and research institutions, non-profits and private companies. Our partners include: the Rwandan Ministry of Health, Rwanda Biomedical Center and the University of Rwanda, School of Public Health; the Mozambican Ministries of Health, Justice and Woman and Social Affairs; the South African National and Provincial Departments of Health; Broadreach; Health Enabled; K4Health; University of Eduardo Mondlane; University of Zimbabwe (HITRAC); the University of KwaZulu Natal Health Enterprise Architecture Lab; InSTEDD; HISP-South Africa; Partners in Health; Management Sciences of Health (MSH); University of California, San Francisco; Duke University; Greenfield Management Solutions; PLAN International, Tech4Life and the Regenstrief Institute.

Jembi's South African office manages several regional and international programmes including the Blood Safety Strengthening Programme (BSSP), the Open Health Information Exchange (OpenHIE) community and an Open Civil Registration and Vital Statistics (OpenCRVS) Initiative.

Key team members for this proposed project include:

Linda Taylor - Linda has been the BSIS Product Manager for the last 4 years and is responsible for gathering, analysing and documenting requirements as well as management of the software development roadmap. She acts a liaison between the community, programme staff and the technical development team and plays the role of scrum Product Owner during the agile development phase.
Rhonwyn Cornell - Rhonwyn is the BSIS Programme and Implementation Manager and has been responsible for the implementations in Lesotho, Ghana, Ethiopia and now Zambia and Cameroon. She is responsible for stakeholder management, capacity building and grant management.
Daniel Futerman - Daniel has been the technical lead on the BSIS project for 4 years and has been responsible for the overall design of both the front and back end of BSIS. While he has expanded his responsibilities into other programmes he remains the backup/standby product lead. Please see Appendix D for summary CVs for these team members.

Project Description

Why is BSIS needed?

Safe blood is critical to treatment of postpartum haemorrhage, a condition estimated to be the cause of 23% of maternal deaths in Africa annually. Safe blood is also used for the treatment of childhood malaria, severe malnutrition, emergency medicine and surgery. Most countries in Africa collect only half of the blood needed to meet their transfusion requirements. BSIS facilitates the production of safe blood by managing information within blood services from the point of donation to the point of transfusion. In this way BSIS facilitates improved blood collection processes as well as ensuring that only safe blood is labelled and released to health facilities. The BSIS implementation models ensures that the system is safely and sustainably implemented at low resource blood services. This approach focuses on capacity building that promotes local ownership of the information system as well as building skills and knowledge required for system use, management and maintenance.

In a landscape where expensive proprietary products are predominant BSIS is a license free open source software system that offers low resource blood services a low cost alternative for electronically managing their data regarding donors and donations. BSIS incorporates the requirements for Africa Society for Blood Transfusion (AfSBT) Accreditation standards, enabling the accreditation process for blood services using BSIS. BSIS is also designed specifically for low resource settings. While the initial recommended BSSP implementation model for introducing BSIS into blood services, with its intensive capacity building and validation phase, is resource intensive the open source nature of the system, which has no associated ongoing license fee, makes BSIS a frugal long term innovation for blood services in low resource settings. The focus of the of the implementation on capacity building in all aspects of the system’s use, management and maintenance also ensures that blood services are not locked into long term expensive support contracts. BSIS functionality and user interface is designed to be simple, intuitive and easy to use and focuses on the core processes of a safe blood service. In addition, the infrastructure and hardware requirements take into account cost and environmental factors, including low or on internet connectivity and generic hardware specifications. The data produced by BSIS supports the blood services’ operational planning and management reporting needs, including reporting requirements of the WHO Global Database on Blood Safety database and CDC. Very importantly BSIS provides blood services with the ability to produce printed, standardised, easily readable and accurate labels for safe blood units and discard labels for units flagged by BSIS as unsafe.

Where is BSIS already in use?

BSIS has been in operational use for a minimum of one year in three sites; the Lesotho Blood Transfusion Service Centre in Maseru, the National Blood Service Ghana’s Southern Area Blood Centre in Accra and the National Blood Bank of Ethiopia’s Addis Ababa Centre. Since BSIS was first implemented a total of 134,070 units have been issued to health facilities from these three sites. Of these blood services estimate that since BSIS went live in their services, 27% of units (36,198 units) they have issued went to maternal and child care services, benefitting women and children.

In operational use BSIS has proved to be very stable with minimal requests for technical support from Jembi. The capacity building activities undertaken as part of the BSSP implementations have resulted in a strong sense of local ownership and the long-term operational use of the BSIS at these facilities. Local staff are confident to provide system user training as well as troubleshoot problems and can adapt local processes as needed. The feedback from these staff who were trained on system management and maintenance is that they feel confident to roll-out the system to other blood centres, with limited support from Jembi. To find out more about these implementations, please see the Implementation profiles in Appendices A-C, as well as the WHO Digital Health Atlas entries for Lesotho,Ethiopia and Ghana.

What does BSIS do?

The Blood Safety Information System (BSIS) is designed as an open source digital health software tool to support low resource Blood Services to manage data about blood donors and blood donations from point of donation, through transfusion transmissible infections (TTI) and serology testing and component processing to labelling and inventory management. BSIS is licensed under the OSI-compliant BSD licence. When changes to the critical blood testing and blood labelling algorithm are being made, for safety reasons the repository is temporarily closed until the quality assurance testing is complete and the version has been signed off for release. The latest version (v1.4) is due for release at the end of September 2018.

Figure: component overview of BSIS functionality

How mature is the BSIS product?

Based on the Global Goods Maturity Model promoted by Digital Square BSIS is a medium matured global good. It is already in use in a number of African countries, with more implementations underway or planned. BSIS software development, quality assurance and implementation documentation are extensive and freely available under a creative commons license, on request. The software is scalable and is in use nationally via a secure WAN in Lesotho. The below diagrams illustrated the key maturity indexes for BSIS pre and post Digital Square Investment. Please see the detailed breakdown in the appendices attached.

Pre Digital Square Investment

Post Digital Square Investment

Proposed Project

The proposed project is to maintain the existing BSIS product as well as develop three additional sets of functionality for BSIS that will benefit all current and future implementing Blood Services. The proposed functionalities are (i) data synchronisation capability for system use at mobile sites and (ii) multi-fixed site interoperability (iii) the ability to electronically interface with laboratory analysis equipment. In addition to the above feature development, the BSIS team will create a model for the integration of BSIS into national level health information systems architectures. This work will focus on modelling and defining the data exchange patterns for BSIS to be interoperable with an OpenHIE compliant HIS and which components BSIS would be able to leverage to better support national health objectives.

These features have been identified as high priority needs by the Blood Services themselves and have been on the technical roadmap for the software from its early stages, although not as part of the initial critical functionality requested. The roadmap for BSIS has been developed and maintained using requirements gathered from African Blood Services, their blood safety technical assistance providers (AABB, Safe Blood for Africa and the WHO), AfSBT and independent international blood safety and system validation experts. We have already developed the business requirements and the initial technical specifications for these features based on our analysis of country needs and we already have a technical backlog of work that is dev-ready.

Data Synchronisation for mobile clinics

A priority requirement for blood services is to have the ability to synchronise donor and donation data between the central database and laptops that can be used at mobile clinics where the majority of blood donations take place. These mobile clinics are often held in areas with no internet connectivity so real time access to the central database is not possible. Currently, data is collected on paper forms and must be back-entered at the central service when the mobile team sends the blood packs, samples and forms back to the central service, often at the end of the work day.

Access to the donor database at point of blood collection is important in that it:

Enables correct identification of the repeat donor and verification of the donor’s eligibility to donate
Reduces the cost of collecting blood from ineligible donors that must then be discarded
Facilitates counsellors to provide on-site TTI and blood grouping results to repeat donors at remote donation clinic
Data capture can be done on site and does not require additional data capture staff for back entry of data, reducing costs and providing data to lab staff more quickly.

Multi-site Support

For the blood services where BSIS is in operational use and rollout to further sites within the country is already planned, a key priority is to be able to exchange data between the different instances of BSIS. BSIS has already been implemented in the Southern Area Blood Center (SABC) in Ghana with an implementation planned by the National Blood Service Ghana (NBSG) for a second site later this year in Tamale in the northern part of the country; the multi-site functionality with enable the blood service to track donors who are mobile between these regions. The Zambian National Blood Transfusion Service (ZNBTS) has included the rollout of BSIS to all 9 ZNBTS sites in its strategic plan for 2020. In Ethiopia the National Blood Bank Service (NBBS) has up to 50 sites that it plans to include in its national rollout of BSIS. Each of these countries has a considerable mobile population, so ensuring that donors can be tracked across sites is critical to ensuring blood safety and operational efficiency.

BSIS is currently designed to be used at a single site, but can also be used effectively in a client-server model on a larger scale across sites, with the conditions that it is hosted on a central server, and all sites have reliable network connections to the central server, usually through a secure Wide Area Network. Network infrastructure and connectivity are issues in many countries, so this centrally-hosted client-server model is not feasible for many services. Individual site instances that can operate independently but can also exchange data when connectivity allows is a more context-appropriate solution. The requirement is for a solution that would allow for separate instances of the system to be setup in a distributed architecture, with data synchronisation across these instances enabling a connected system.

Proposed Solution for Data Synchronisation

We believe there are synergies with these two requirements, whereby both problems could be solved by developing data synchronisation capabilities between regional sites, as well as between mobile clinic laptops and the site database. Some of the overlapping, key requirements for these features include:

The ability to generate globally unique identifiers and donor numbers
The ability for an authorised user to synchronise data between regional databases, or between a regional database and a mobile clinic laptop
The ability to identify and indicate if a record has been transferred between databases
The ability to identify and indicate if a record has been updated or voided on a database before or after data synchronisation
The ability for an authorised user to identify, manage and resolve data conflicts
The ability to transmit data between databases securely

To date, a significant amount of work has been done on identifying a solution and preparatory work. This work includes:

Technology Review

Having reviewed suitable approaches and technologies for data synchronisation, it is evident that other related applications have taken one of two approaches:

Develop custom data synchronisation functionality within the application, e.g.:

OpenMRS – API-level data sync module
Bahmni – Atom-feed based data sync
DHIS2 – Custom data and metadata synchronisation functionality

Leverage existing database replication technologies
OpenBoxes – Leverage SymmetricDS
OpenMRS – GSoC project to leverage SymmetricDS

In trying to keep things agile and lean, leveraging existing database replication technologies shows benefits over trying to develop this internally within the BSIS application, and this approach been prioritised.

Several open-source and commercial database replication tools were reviewed, including:

Postgres-R
Slony-I
ESCADA Replication Server
Pgpool-II
DBReplicator
SymmetricDS
Sybase Replication Server
Q-Replication Tools

In this review, we considered criteria including product maturity, features, stability, support, adoption rates, user reviews and success stories. JumpMind’s SymmetricDS was found to be the preferred option and capable of supporting the high-level requirements for data synchronisation in BSIS.

JumpMind’s SymmetricDS is an open-source database replication software licensed under the GPL license. A Pro (paid) version of the product is also available that adds a web interface GUI and a few additional features on top of the application.

Some of the benefits to using SymmetricDS as a data sync tool for BSIS include:

External application - there is minimal impact on the BSIS implementation qualification processes, which means it will not place an additional burden on blood services over installation and upgrades.
Can be phased in iteratively - it’s possible to focus on key use cases, and then extend those to cover more of the blood safety workflows and data elements.
Can be switched out for an improved solution at a later stage if needed.
Use of SymmetricDS is optional - for those blood services that do not require data synchronisation functionality, BSIS can be implemented as is.

SymmetricDS high-level features include:

Data Synchronisation - Change data capture for relational databases and file synchronisation for file systems can be periodic or near real-time, with an initial load feature to fully populate a node.
Central Management - Configure, monitor, and troubleshoot synchronisation from a central location where conflicts and errors can be investigated and resolved.
Automatic Recovery - Data delivery is durable and low maintenance, withstanding periods of downtime and automatically recovering from a network outage.
Secure and Efficient - Communication uses a data protocol designed for low bandwidth networks and streamed over HTTPS for encrypted transfer.
Transformation - Manipulate data at multiple points to filter, subset, translate, merge, and enrich the data.
Conflict Management - Enforce consistency of two-way synchronisation by configuring rules for automatic and manual resolution.
Extendable - Scripts and Java code can be configured to handle events, transform data, and create customised behaviour.
Deployment Options - The software can be installed as a self-contained server that stands alone, deployed to a web application server, or embedded within an application.

Proposed Architecture

Proof of Concept

An initial proof of concept was completed to evaluate the capabilities and suitability of SymmetricDS. The outcome of this proved positive, but highlighted some limitations with the free version and the lack of a graphical user interface (GUI):

The GUI adds major value - it makes it much quicker and simpler to develop and implement the data synchronisation solution, and provides an excellent interactive interface to monitor, manage and support use of the tool in production.
With the free version, the exact same solution can be developed, but it will take a lot more time and effort to do this programmatically.

Our development strategy therefore is:

Provide the BSIS technical team with access to the Pro version of SymmetricDS to effectively and efficiently develop the initial sync solution, which can be then exported for use in production.
SymmetricDS will run as a separate application to BSIS, using the “Standalone" or “Web Archive” approach that does not integrate or embed SymmetricDS within the BSIS application. Using this approach provides minimal impact on BSIS implementation qualification processes, and should avoid any issues with integrating software with conflicting licenses (BSIS uses BSD, SymmetricDS uses GPL). SymmetricDS will operate at the database level when used with BSIS. Implementing the sync solution has the effect of adding a set of database tables to each BSIS database that makes use of it. These database tables are used in managing and coordinating the synchronisation of data between data sources.
The free version of the software will be used in production, but will make use of, or import, the data synchronisation solution developed above. There will still be the limitation whereby there is no interface to monitor, manage and support use of the tool in production. Our goal therefore is the development of a basic application (separate to BSIS) to provide a simple means of monitoring the status of SymmetricDS, to allow administrators to ensure that data sync is operating as expected. This can be extended over time, if needed, to provide additional high priority monitoring and support features (essentially to provide some of the functionality that the Pro version web interface currently provides).

Use of UUIDs

In addition to the proof of concept, the development team have also adapted BSIS to make use of UUIDs in preparation for the use of a synchronisation tool. A universally unique identifier (UUID) is a generated number used to identify information in computer systems and is, for practical purposes, globally unique. This means that records can be created and shared across many instances of BSIS without the problem of duplicate identifiers. This work is complete and is due to form part of the next release in the last quarter of 2018.

Laboratory Device Interfacing

Currently one of the risk areas identified by stakeholders is laboratory staff transcription errors of blood sample test results, either from the automated testing machine printouts or from paper records used in manual testing. Although there is a is double-entry feature in BSIS which minimises this risk, supported by standard operating procedures (SOPs) to ensure only authorised staff can verify these results in BSIS before releasing a batch of blood samples, there is still a small risk that the incorrect test result may be captured. In addition, this double entry process is time consuming and requires two lab staff to be available. Laboratory device interfacing with BSIS will provide the ability to extract TTI test data from the automated testing machines and automatically populate these results in BSIS, thereby eliminating the risk of data transcription errors by the laboratory staff, reducing processing time and freeing up staff resources by reducing manual data entry. The laboratory testing machine/analyser identified as a priority use case is the Abbott Architect machine that is currently widely in use in the African blood services. Our aim however is to design and develop this feature in such a way that other manufacturers’ machines/analysers could be supported with as little customisation as possible. The first priority is to focus on Transfusion Transmissible Infections (TTI) testing as this is the type of testing that is most commonly automated in the blood services, followed by blood group serology testing in a later phase.

Abbott Architect, ASI and ASTM

The most common TTI analyser in use in African blood services is the Abbott Architect, so that will be the first analyser we will focus on. The Abbott Architect instruments support the Abbott Standard Interface (ASI), designed to enable interfacing Architect analysers to hospital or laboratory information systems using the serial RS-232 communications port. The ASI is implemented using the ASTM standards, specifically:

ASTM E 1381-91 - “Specification for Low-Level Protocol to Transfer Messages Between Clinical Laboratory Instruments and Computer Systems”
ASTM E 1394-91 - “Standard Specification for Transferring Information Between Clinical Instruments and Computer Systems”

Proposed Solution for Device Interfacing

The proposed solution seeks to leverage the OpenHIM as the means to exchange data between the analyser and BSIS but further analysis is needed to validate and describe the following to refine exactly what the solution would look like. The initial design is as follows:

This would require the development of an ASTM E 1394 mediator to accept, parse and transform messages received from the Architect. With similarities to HL7v2, HAPI / HAPI-FHIR) could potentially be adapted for this. The format that the ASTM messages are transformed to that BSIS will consume would have to be investigated and agreed. Possible candidates are ASTM to HL7v2 or possibly ASTM to FHIR (See the FHIR DiagnosticReport Resource.) BSIS would require the addition of HL7v2 / FHIR support so that BSIS can consume output from the ASTM mediator.

A lower priority is to develop an ASTM message generator to simulate and test the solution so that the development and testing phases are not dependant on having access to an Architect machine. We have had prior communications with the Abbott Johannesburg office about the possibility of collaborating with them to beta-test in their own simulation environment, but a message generator would be helpful to reduce the dependency on Abbott for further testing.

The following diagram describes the expected networking requirements to interface the Abbott Architect testing machine to BSIS.

Jembi has been in discussion with other groups who are also working on open source solutions for device interfacing to LIMS, and that have been utilising the OpenHIM as part of the solution. This project would provide an opportunity to harmonise efforts and share knowledge with the parties involved in:

System Interoperability

Whilst the initial country implementations of BSIS did not require an interoperable system, the long term vision has always included interoperability with other systems as an important feature. The technical design of BSIS already incorporates a web API (see Technical Architecture diagram below) that can support interoperability use cases and this new feature will build on this work. The device interfacing work would be a prelude to this. The core areas that we aim to focus on are:

Improvements to security, specifically implementing the use of self-signed certificates over https.

Minor changes to the BSIS REST API to make it public and also easier for developers to interact with
Document the potential / most likely interoperability use cases, for example:

○ Hospital patient system - for managing order and returns of blood units; for exchanging blood transfusion data to support haemovigilance.
○ Referral use case - sharing referral information about TTI positive donors with referral services to ensure linkage to further testing, treatment and care.
○ Device interfacing - with other laboratory devices such as weighing scales, in addition to the automated testing machines documented above.
○ DHIS2 aggregate reporting.
○ Shared Health Record - the ability to store a donor’s blood group

Investigate the use of the FHIR Diagnostic Resource as an appropriate standard for data exchange for blood service information.
The value of mapping this data exchange to OpenHIE profiles could also be considered.

BSIS Technical Architecture

Product Maintenance

In addition to this new functionality the technical team will maintain the existing core BSIS Product in line with the product roadmap. This includes four main areas:

Technical Maintenance, including dependency management, security updates and code maintenance as well as provide core technical support.
Product documentation already consists of

○ Software Roadmap

○ Requirements Specifications

○ Developer Guides

○ Implementation Guides

○ User Manuals

○ Release Notes

These will require updating to include the new features.
Quality assurance has been a critical aspect of the development of BSIS and our aim is to update and maintain the QA strategy documents, develop additional test cases and improve performance testing, and to introduce integration testing to support interoperability use cases.

Promotion of the BSIS, including the maintenance of the BSIS demo site demo.bsis.jembi.org, provision of demos to interested parties and updating promotional material in line with releases.

Conclusion

BSIS is a medium mature global good software that is having a substantial impact on improving blood safety in several Sub Saharan African countries. Investment in increasing the functionality of BSIS to include all the proposed new features will increase the ability of BSIS to improve blood safety in low resource setting and expand the ever growing potential user base for the system.

Work Plan and Schedule

The work plan consists of 4 separate work streams/work packages as shown in the diagram below. These are: Overall product and programme management, the Data Synchronisation work and the Device Interfacing and Interoperability work. Please see the work plan in excel spreadsheet format attached in Appendix E.

Key deliverables

Initial version of a synchronisation solution ready for beta testing
Basic application to monitor status of the synchronisation solution in operational use
A mediator that manages messages from the Abbott Architect machine to BSIS
Message specification for device interfacing, most likely in FHIR
Improvements to the existing REST API to support interoperability
Documented interoperability use cases
Updated versions of all product documentation including; systems specifications, quality assurance documentation, implementation/installation guides and user manuals

2-sentence overview of project

The project’s goal is to develop three additional sets of functionality for BSIS that will benefit all current and future implementing Blood Services, as well as supporting basic maintenance of the existing BSIS product. The proposed functionalities are (i) data synchronisation capability for system use at mobile sites and (ii) multi-fixed site interoperability (iii) the ability to electronically interface with laboratory analysis equipment.

Tagging:

Laboratory and diagnostic information system
Knowledge management system
Data interchange interoperability and accessibility
Shared health record and health information repositories
Client identification and registration
Referral coordination
Data storage and aggregation

Application Status:

Approved - partially funded

BUENDIA v2 (IT4LIFE)

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

Notice C Opportunity:

Announcement C0: Global Good Software Development and Support

IT4LIFE wants to achieve the development of a Data Management System, known as Buendia2. It is an Electronic Medical Record (EMR) system designed to be used on a tablet computer. It is built for use by a clinician performing a consultation and analysing individual patient records. It is capable of exporting aggregate data to be brought into a Health Information System (HIS), to be integrated in HIS as DHIS2. It is adapted to poor resource settings: built to function without internet access, reliable power, access to tech support, or a local network.
This technology has multiple potential applications in health care in emergencies humanitarian situations. It has been settled on the nutritional crisis as the clinical issue to address. Thanks to its flexibility it can be implemented in future nutritional crises or easily repurposed for other types of emergency.
Delivering high quality care in a nutrition program requires collecting and visualising data on large numbers of patients over time, often in remote and dusty locations; as such, a portable weatherproof EMR can: Increase quality of clinical decision-making by providing a faster, more accessible, and more error-free view of individual patient data, facilitating better decision-making. Increase reach to more decentralised sites, since the system should enable less highly-trained consultants to provide an acceptable standard of care and spend less time on paperwork.
Digital technologies facilitate communication, coordination, collection and analysis of data, enabling timely responses in humanitarian contexts, improve the health and social well-being of populations affected by both acute and protracted crises.Decisions in nutrition such as exit criteria are linked not only to current status, but to past clinical evolution. For example, a child with a specific weight-for-height at triage might not be admitted, but the same measurements partway through a course of treatment would still require ongoing care. Therefore a longitudinal view, including the whole history of the patient, is necessary to make the right decisions.
Buendia v2 technology can radically increase the efficiency (time savings) and productivity (cost savings) of humanitarian effort, and reshape aid so it is fit for the 21st century. This means being proactive in response to risks, collaborating across organizations, localizing response and thinking about all this from the perspective of those who are affected by crises. A better and faster quality of care will be provided, with lower rate of medical errors and long-term monitoring of patients, thanks to accurate and flexible digital technologies.
The reach of nutrition projects is often limited by HR,and by the amount of highly-trained consultants we can deploy.The ability of these staff to perform quality consultations, and to refer as needed, is a common limitation preventing projects from having more satellite sites.If nutrition consultations could be performed more reliably by local, less highly-trained staff, many projects might be able to open more decentralized sites, increasing the reach and life-saving potential of the projects.

The output of this innovation project will be a data management system that has been piloted and works, and can be implemented in future nutritional crises or easily repurposed for other types of emergency. The Buendia v2 system is well suited to the nutrition context, and with a few modifications will reach the desired state outlined above. it is unusually robust, intended to function in an extreme environment with no internet, intermittent power, little or no IT support, and comes packaged in a single, easily transported padded case. However, the more important aspects of the “fit” for nutrition relate to the workflow.

Step 1 : Buendia2 installation consists of tablets (in a nutrition context, one per consultant plus a spare), a microserver, and a Local Area Network (LAN) kit. The tablets run a clinical user application that allows the creation, retrieval, and modification of individual patient records. The patient records are synchronized to a local server via a secure private LAN, and therefore accessible to all authorized users (and can be downloaded by an authorized manager onto a laptop for importation into data tools for detailed analysis and/or integration into HIS platforms, current or future).
Step 2 : The tools will be piloted and evaluated in an agreed field site.This will be an opportunity to identify and correct bugs in a field setting, where the conditions will match the actual environment of the end users. At the same time, the team will work with the medical and operational managers to assess the appropriateness and impact of the tool; looking at the medical workflow and expected impact on patient outcomes rather than simply seeing if the tool performs technically as expected. The development of the nutritional tool will be done such that the system can be more easily modified for other use-cases in the future.
Buendia v2 is sustainable for resource-poor settings : the system is built to function without a need for internet access, reliable power, access to local IT or tech support, or a pre-existing local network.
Two sets of indicators will be designed to assess impact : the technical functioning of the system (does it do what it is says on the label) and medical/operational impact of the system (does it improve quality of data collection and clinical care).
Quality of nutritional care is evaluated based on SPHERE standard including recovery, default and death rates.Expected results are: Increases quality of clinical decision-making: Consultants have a faster, more accessible, and more error-free view of individual patient data, facilitating better decision-making. Consultants spend less time dealing with paperwork, allowing more time for the clinical interaction.Some amount of algorithmic guidance is built into the system, increasing the speed and proportion of correct decisions (either in direct clinical decisions or decisions to refer). Increases reach: The system should enable less highly-trained consultants to provide an acceptable standard of care. Hence, more decentralized sites can be managed, capturing more children and doing so earlier in the progression of their condition. Consultants spend less time looking for and filling out paperwork and making calculations, allowing them to see more patients while maintaining quality of care.

The team will work with the medical and operational managers to assess the appropriateness and impact of the tool; looking at the medical workflow and expected impact on patient outcomes rather than simply seeing if the tool performs technically as expected.
The tools will be piloted and evaluated in an agreed field site.This will be an opportunity to identify and correct bugs in a field setting, where the conditions will match the actual environment of the end users. The adaptation of the tool will proceed by first designing a tool to modify the system, then using that tool to build the nutrition application. This will “future proof” the system by making it more easily modifiable with minimal (or perhaps even no) input from expensive and hard-to-find software engineers.
The 2013 conflict in CAR has had dire consequences on an already very weak health system.The lack of qualified HR, essential medicine, effective gratuity of care combined with the financial difficulties met by the population hinder access to quality care. In 2018: the humanitarian situation is predicted to deteriorate, and access to people in need could be restricted by continued and escalating violence,2.2 million people, require immediate humanitarian assistance.
The local staff will be the direct beneficiary of this innovation, this will strengthen the ability of the local staff to perform quality consultations, and to provide better care for patients. Quality of care requires an overview of the patient's clinical evolution over time. Improvements on the application will be possible thanks to a proactive participation of the local staff; focusing on the specific needs of patients.

We plan to do it in consortium with previous collaborators on this project as Ivan GAYTON or Ka-Ping YEE and with ALIMA NGO.
Alima design programs so that impact can be measured continuously and incrementally, focusing on outcomes, not just outputs, using data responsibly according to international norms and standards.
ALIMA has teams of public health specialists and NICT experts both at the operational headquarter in Dakar and at the national coordination level. These teams are all supported by experts in finance, management and logistics.Currently, ALIMA manages grants from ECHO, OFDA, ELMA, AFD...ALIMA works hand-in-hand with a network of local and national medical organizations to provide life-saving care to neglected communities. ALIMA’s programs are managed in a decentralized manner. Each crisis is unique, and the response must be adapted to the context. Decisions are made in tandem with local partners at ground level.
Since its creation in 2009, ALIMA treated more than 2 million patients, conducted 56 programs in 13 countries and launched 10 research projects focusing on malnutrition, malaria, Ebola, and surgery. ALIMA has teams dedicated to acute emergencies and recurring crises. ALIMA invests in operational and clinical research to improve medical care in humanitarian emergencies, including trauma surgery, nutrition, paediatric care, and Ebola prevention and treatment.
As members of the international community and independent humanitarian organization, Alima respect the nine Principles for Digital Development (build for sustainability, design with the user, understand the existing ecosystem, design for scale, , be data driven, use open standards, open data, open source, and open innovation, reuse and improve, address privacy and security, be collaborative) and contribute to environmental awareness and behaviour change.

The Buendia technology will allow better health surveillance, performing a consultation and analysing individual patient records leading to effective interventions in line with SDG 3: Good health and well-being.

The project takes into account the specific needs of the most vulnerable beneficiaries (children and pregnant and lactating women), and raise awareness among teams, both at headquarters and in the field, to the analysis and integration of gender-related risks and to the implementation of appropriate measures in the activities carried out.
This proposal differs from other grants because it mainly takes into account the data lifesaving dimension in application not only to the nutritional context but also to different crisis contexts and easily repurposed for other types of emergency.

An extension of this project it to build a microserver powered by solar panels capable to run an instance of Bahmni or Odoo in an antena care or a mobile clinic.

#dhis2 #bahmni #openstreetmap #openmrs #tracker

Application Status:

Incomplete

Building an Open Child Helpline System(OpenCHS) Community of Practice

Submitted by James Kaminju on Sun, 07/29/2018 - 13:00 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

The Child Helpline System is an Open Source Case Management System that supports reporting and case management of abuse cases of children through various channels of communication including calls, SMS and CHAT. Child Helplines are operational in more than 147 countries around the World. They play a critical role in Child Protection Systems by providing a reporting mechanism by adults and children on incident or risk of any abuse, violence and exploitation happening against any child.

To date the Child Helpline System has been implemented in more than 7 countries in Africa including Kenya, Uganda, Tanzania, Zambia, Namibia, Ghana and Swaziland. The 3 Child Helplines in East Africa handle approximately 5,000 calls and 400 cases per day. More countries in Africa have expressed interest to deploy this year including Mozambique and Zimbabwe. Other regions that have expressed interest to implement the solution include Europe and Central Asia.

In 2016, the UNICEF East and South Africa Regional (ESAR) Office in Nairobi and Child Helpline International (CHI) conducted several activities to strengthen collaboration of the two organizations on activities geared towards reducing violence against children and ensure enhanced protection in ESAR. One of the key activities/ projects coming out of this collaboration was a study conducted by CHI and supported by the UNICEF ESARO which assessed the situation of child helplines in the ESAR with a focus on data collection systems including individual case management systems (software) being used by the countries in ESAR.

Through the study by CHI, which covered Burundi, Lesotho, Botswana, Swaziland, Malawi, Kenya, South Africa, Uganda, Tanzania, Madagascar among other countries, it was discovered that while most child helplines in the region use some kind of software for case management, the space was so fragmented with mostly bespoke solutions that often did not meet end-user expectations in all the country offices surveyed and most were struggling with limitations in scope and function and with no sufficient technical support from their original designers and developers.

While the initial cost of development was mostly covered by individual UNICEF offices in most countries many of the helplines supported did not have continued technical support for the installed platforms (case management software) and thus over time, the helplines were running on obsolete technology with frequent breakdowns and increased risk of data loss including privacy and data security issues.

Moreover, with the changing landscape for technology and communication channels, CHI discovered that most helplines would like to enable or include alternative channels of communication for reporting cases as well as outreach to clients, added to integration / interoperability with newly installed government owned child protection databases / management information systems (CPMIS but to make these critical software updates required making such individual bespoke updates to the individual platforms in all the countries which was considered very expensive and inefficient. In many of the countries, the original developers / consultants were not available to provide the technical services of upgrading the platforms.

To deal with these challenges, UNICEF and CHI international decided to embark on an effort to design and develop a generic child helpline case management solution for the ESAR starting with the upgrade of the helplines in three countries; Uganda, Kenya and Tanzania – including Zanzibar to the same helpline software. The generic helpline is designed with an architectural approach that favors configuration for specific use-cases / customizations as opposed to bespoke software engineering for each context.

Bitz IT Consulting has partnered with UNICEF ESARO to design and build the generic helpline case management system providing architectural provisions that allow each of the country offices that deploy the helpline software to customize key aspects of the project to their context, this includes integration/interoperability with country specific child protection management information systems as well as customization of case forms, call work flows and communication channels among other customizations.

To further build on these efforts, it’s been proposed that although the generic helpline is currently being built according to FOSS principles and practices, it is also very important to develop a strong open source community around the product to ensure continued development and evolution of a standard’s based, cost effective and reliable child protection case management software product with wide, cost effective and reliable technical support for the platform (especially local tech support) in each country guaranteeing long term sustainability of the helplines.

With this in mind and with the technical guidance and coordination by the UNICEF ESAR Office, three country teams from Uganda, Kenya and Tanzania comprising of child protection experts from UNICEF country offices, government stakeholders such as the Ministries in charge of child protection affairs including Ministry of Gender and Social Development in Uganda, Ministry of Interior and Ministry of Social Protection in Kenya and members of civil society and NGOs dealing with child welfare issues in those countries came together and conducted a requirements gathering and analysis exercise for a generic set of features that cut across all the three country context as well as assessing key customizations that are necessary for each of the individual country contexts.

Currently, it is estimated that there is an almost 80 percent overlap in features / required functionality across the three country offices giving a minimum viable set of requirements/features with enough value for all countries. It was also determined that the bulk of the required customization had to do with integration or interoperability with national child protection databases in each of the individual country offices.

The group therefore commissioned the development of a Generic Helpline system that can be deployed in different countries with minimal country specific customizations. The development exercise and support is expected to run for 2 years from 2018 to the year 2020 and is fully funded by UNICEF ESARO.

However, this support from UNICEF does not include the development of a vibrant open source community which, as explained above, is critical to the long-term sustainability and evolution of the helpline into a standards-based, cost effective, easy-to-deploy and reliable child protection case management system.

With this funding, the goal is to build an OpenCHS Community of Practice to coordinate and consolidate contributions and efforts from various partners. Therefore we intend to establish a curated and moderated one-stop virtual space for engagement, knowledge sharing and learning amongst OpenCHS implementers, developers and users.

Consortium Team:

We are a diverse team that has come together to make sure that the OpenCHS community of practice becomes a reality. Each member of the team brings onboard something different and unique to the community.

Child Helpline International is a collective impact organization working to defend the rights of children and youth worldwide. The network consists of 181 member organizations operating in 147 countries around the world (December 2017). Since its founding in 2003, it has supported the creation of new child helplines and strengthened the network by sharing what has been learned from the best of them, with all of them. Having helped to start Child Helplines across the globe and its diverse geographical reach in many countries CHI glues together the OpenCHS CoP to achieve its objectives.

UNICEF ESARO Located in Nairobi, the capital of Kenya, the Eastern and Southern Africa Regional Office (ESARO) coordinates and supervises UNICEF’s work in 21 countries: Angola, Botswana, Burundi, Comoros, Eritrea, Ethiopia, Kenya, Lesotho, Madagascar, Malawi, Mozambique, Namibia, Rwanda, Somalia, South Africa, South Sudan, Swaziland, Tanzania, Uganda, Zambia and Zimbabwe. The work is organized around UNICEF’s key priorities in the region: Young Child Survival and Development, Children and AIDS, Basic Education and Gender Equality, Child Protection, and Emergency Preparedness and Response. They support Child Helplines in the Eastern and Southern Africa (ESA) region. Over the years they have provided both Technical and Financial support to the Child helplines and to the development of the Child Helpline System. Their technical guidance and participation will be vital to the community of practice.

UNICEF Europe and Central Asia have also expressed interest in joining the community of practice. Their participation is key to the recruitment of members (countries) from this region.

3 Governments through the respective Ministries, departments of Children Services and Child Helplines are the principal clients of the Child Helpline System. The government of Kenya through the Ministry of Gender and Social Services supports Childline Kenya, The government of Uganda through the Ministry of Gender Labor and Social Development supports Sauti Child Helpline and the government of Tanzania through the Ministry of Community Development, Gender and Children supports C-Sema a Non-governmental organization that runs the Child Helpline in Mainland Tanzania and Zanzibar. Participation of government Ministries and departments is seen as vital to the success of the OpenCHS solution as it provides an avenue for integration to the governments Child Protection Information Management System.

Bitz IT Consulting Ltd (http://www.bitz-itc.com) is a leading Kenyan software development and consultancy firm that specializes in developing open source software for hotlines. The company was founded in 2007 and has delivered software projects across the African continent. Bitz ITC has collaborated with UNICEF in development of the Open Source Child Helpline System for integration with CPIMS and GBV systems in the continent for the last 5 Years. Bitz will use its experience to manage the development process of the OpenCHS community of practice and moderate on the collaboration and also use its team to set the collaboration environment. Together with our partners Bitz technical team will provide support to those who have deployed the solution and offer technical support to those new members who will be deploying the solution. They will also coordinate contributions and efforts within the community to improve the OpenCHS, documentation, training and offering technical support to the members in the community.

Project Description

The stakeholders aim is to support the building of a community of practice to serve as an organizational home for the open source Child Helpline System (OpenCHS). We intend to build a more diverse and collaborative contributor community responsible for expansion of the OpenCHS, making accessible documentation and support for users of the system. This collaboration and sharing of information will enable stakeholders in countries around the world where the Child helplines exist to receive a roadmap for documentation, technology transfer & training, code clean-up and governance through a mature fully Free and Open Source Software (FOSS). Initially the CHS has been maintained by a single organization which has led to fragmentation and siloes in the Child Protection ecosystem and Child Helpline Solution.

Initially CHS systems deployed around the continent have been rigid whereby for a country to change some aspects of the system such as location fields, Case Category fields and generally any country specific customization would require redevelopment and changes to be done from the source code. The new release has come with the use of dynamic forms (x-forms) whereby country specific customization can be done by the local support teams by adding those requirements in an Excel formatted sheet and uploading it into the deployed system. Because of the nature of the collaborative approach we are looking forward to in the community, such added functionalities which are required will be achieved more easily through contributions from other members who will be exposed to the solution. The matrix below shows the activities that have been completed so far:

Activity	Description	Status	Output	Funding Status
Inception Workshops	Workshops held in Uganda, Kenya and Tanzania to initiate the upgrade process	Completed	Inception Report	Fully Funded by UNICEF
Requirements Gathering	Requirements gathering exercise done in Uganda, Kenya, Mainland Tanzania, Zanzibar	Completed	Functional Requirements Document (FRD)	Fully Funded by UNICEF
System Design	Design of Helpline system Modules, data flow diagrams, data tables, metadata and integrations with external child protection systems	Completed	System Design Document (SDD)	Fully Funded by UNICEF
Release1 Core Modules	Core Modules include Case Registration, Case Management, Case Escalation & Follow-up, Quality Analysis, Dashboards and Reports.	Completed	Generic Helpline System	Fully Funded by UNICEF
Release2	Additional communication channels including SMS, CHAT, Mobile App, Teleworking	Ongoing	Additional Communication Channels	Fully Funded by UNICEF
Documentation	Training Manuals, User and Technical Manuals	Ongoing	Training Manual User Manual Technical Manual	Fully Funded by UNICEF
Building OpenCHS Community of Practice	Setup online OpenCHS CoP, Maintaining a shared online space for community member communication, documentation and supporting materials Member recruitments Promoting the CoP through events, build a shared roadmap for community collaboration, Identifying opportunities for merging of code bases, or migration to a shared code base	Pending	OpenCHS Community of Practice	Seeking Funding
Improvement and Enhancement of the OpenCHS	Better User experience, Multi-lingual support, Self-installing packaging	Pending	Better application, easy to deploy	Seeking Funding
Additional 3 Countries in 3 regions to deploy	Expand users by supporting 3 countries in 3 Continents to deploy	Pending	3 more Child helplines as Users across 3 continents	Seeking Funding

Use Cases, User Stories, and Activities

Use Cases

The OpenCHS use cases include Case Registration, Case Management, Case Escalation and Follow-up, Quality Analysis, User Roles dashboards, Reports representing functions or processes taking place in the Child Helpline call centers and externally for referrals of cases.

User Stories

During the writing of this proposal we have reached out to the wider OpenCHS community mostly implementers of the solution and they were excited with this initiative. Below are some of the feedback that we have received so far.

“This is a great move James. We have really struggled for support and sometimes response times have been very slow. The community will ensure that our internal IT personnel have capacity to support the solution.” Kenneth Ayebazibwe, Ministry of Gender Labor & Social Development – Uganda

“We are excited to be part of the community of practice. The system is required in Europe & Central Asia region and the community will provide a platform for developers to understand requirements for this region.” BP Panwar, UNICEF Europe and Central Asia region.

“We will be happy to assist developers integrate the Child Helpline System to the governments Child Protection Information Management System (CPIMS). Integrating Child Helpline System to the CPIMS makes CPIMS a better system.” Newton, Developer Department of Children Services – Kenya

“Wonderful initiative that is long overdue. Developers will have a platform to engage and come up with enhancements to the CHS. Am glad to participate on the backend technologies.” Jimmy Wanyama, Independent Consultant -Telecloud

Activities

Year 1: Develop and launch the Community of Practice platform, knowledge management (curation of resources), promotion of the Community of Practice, as well as relationship management and moderation of member engagement in order to build a strong, heterogeneous and active community,
Year 2: Develop strategies to sustain the Community of Practice
Creating a digital home for OpenCHS knowledge sharing, collaborations, and technology offerings thus Provide a Platform for technology transfer and training for users and implementers of the OpenCHS.
Coordination of activities and processes related to organization and integration of data collected from various sources, annotation, publication and presentation of the data in a format that adds value for all stakeholders.
Maintenance of international standards and best practices for CHS ensuring proper integration into workflows, transactions, and technologies.
Identifying opportunities for merging of code bases, or migration to a shared code base, to strengthen the efforts on CPIMS services;
Developing a shared technical roadmap for the solution where applicable; and,
Providing or coordinating technical support for members and projects through the community.
Development of specifications for interoperability of the OpenCHS to the CPIMS
Expand the OpenCHS software APIs and workflows for use with multiple Child Protection Systems;
Develop documentation and supporting materials for the OpenCHS software; and,
Provide technical support to community members for implementation and use of the software.
Fund raising strategy to support sustainability of the CoP beyond the 2 years of the initial funding.

Detailed Activities

Enlisting more Child Helplines from among the 147 countries to be members of the community. Their contributions will be factored in future upgrades and releases.
Identifying opportunities for interactions of members to strengthen the knowledge base, resource library, and technology offerings within the community
Building a shared roadmap for community collaboration on CHS tools and technologies, while encouraging the sharing of individual product and organization roadmaps within the community for identification of alignment and collaboration opportunities.
Performing an assessment of the open source CHS landscape (functions, technologies, implementations, support /community) to guide content prioritization, identify opportunities for consolidation, and engage additional community participants.
Promoting the Community of Practice in order to increase the pool of members and volunteers

Undertaking outreach presentations
Participating in outreach events
Marketing the Community of Practice via web and social media channels
Travel to promote the OpenCHS Community of Practice
Developing and distribution of Promotional Material

Managing content within the Community of Practice in order to ensure it is relevant and up-to-date

Developing and identifying content to share with Community of Practice
Curating content that is uploaded by Community of Practice members
Managing the taxonomy of content to make it easier for users to find what their looking for (e.g. through effective tagging of key words)
Signposting Community of Practice members to available content

Facilitating the engagement within the Community of Practice to connect members and encourage participation

Maintaining a Community of Practice members list
Identifying pools of experts within the Community of Practice and subsequently signposting members of Community of Practice in need of support towards them
Triggering discussions relevant to the Community of Practice within the community forum
Capturing and packaging learning within the Community of Practice
Gathering member feedback using polls/surveys, for example, regarding future system enhancements
Support facilitation of webinars/presentations through the Community of Practice
Sending out reminders to the community for contribution

Maintaining the Community of Practice platform

General platform administration
Maintaining a shared online space for community member communication, documentation and supporting materials, and other community functions as needed;
Troubleshooting issues associated with the use of the Community of Practice web platform

Expected outcomes from this funding include:

A robust OpenCHS community of practice that developers, implementers, and users can share and collaborate on technologies, materials, and informatics;
A community that identifies and builds out OpenCHS interoperability standards-based and needs-based workflows for integration into the larger facility-level and upper-level Child Protection ecosystem.
Expansion of the OpenCHS system that is flexible, easy to deploy and use, mature APIs for integration to external systems such as CPIMS, GBV or any other Health system.

OpenCHS Digital Health Technologies

We plan to utilize existing digital health tools and technologies. We will therefore bring together several existing mature common tools and technologies to incorporate in our development. Some of these mature tested tools include Enketo, X-Forms, RapidPro, Superset for dashboards among others. Choice of technologies are listed below:

2 - Sentence overview

OpenCHS is a system that captures abuse cases against children reported through calls, SMS, CHAT or other communication channels and is run by Child Helplines supported by Child Helpline International (A Network of more than 147 countries) and UNICEF. Our consortium aims to build a Community of Practice to serve as an organizational home for the OpenCHS whose main goal will be to bring together users, implementers, partners and stakeholders in the health domain to develop the workflows, transactions, technologies, and supporting materials therefore developing a more robust solution that is easy to deploy, accessible by many more countries and that can be implemented with local technical support.

The primary purpose of this proposal is to request funding support for advocacy activities for the initiatives of building a robust community of Practice that has a wide membership across the globe, improve the product for ease of deployment and use and support an initial 3 countries across 3 continents to deploy and use the current OpenCHS.

Community Feedback

The OpenCHS CoP will be a digital home for stakeholders, members, partners, developers and implementers to share knowledge, provide inputs and give feedback. It therefore provides a great platform for the wider Child Protection Information Management Systems (CPIMS).

Up to this point we have established support from partners / members we count on in this process of building the CoP.

UNICEF East and Southern Africa Region with 21 Member countries
UNICEF Europe and Asia Region with 21 Member countries
Child Helpline International with more than 147 members
Childline Kenya
C-Sema Tanzania () NGO that runs the Child Helpline in Tanzania & Zanzibar
Sauti Uganda that runs the Child Helpline in Uganda
Ministry of Gender and Social Services Kenya
University of Nairobi Department of Computer Science -Developers of the CPIMS Kenya`
University of Dar-es-Salaam developers of CPIMS Tanzania
Ministry of Gender Labor and Social Development Uganda

We expect this list to grow during the first and second year of the CoP even as more members join. We also have independent consultants onboard who bring specific skills to the community.

Feedback Mechanisms

We will make effort to present at conferences, symposiums and seminars as well as organize events to promote OpenCHS initially in the regions of Africa, Europe and Asia as well as receive feedback.

Social media (Facebook, Twitter, and LinkedIn) provides channels to promote the CoP. When possible, television and radio appearances also provide the opportunity to promote the CoP.

Initially we plan to have weekly feedback sessions which will be conducted online. As stated we will bring in the right innovative Enterprises through proper recruitment. We will bring relevant topics in the CoP for discussion and do a proper documenting of the CoP discussions and eventually implementing the best ideas in the best way possible.

The CoP will make public all ongoing work for input and feedback, as well as, directly request input on materials quarterly. Moreover the OpenCHS community will actively engage with the other global goods awardees to seek out collaboration and share their experience in building a CoP.

Self-Assessment on the Global Goods Maturity Model

https://docs.google.com/spreadsheets/d/1i6IFnzNh5vbwAxHrS9JoNIbB6vS_KGyYUySywvUlzYE/edit?usp=sharing

Digital Health Atlas

Please see the MAPS Toolkit on the link below:

http://digitalhealthatlas.org/app/164/maps/0/0

Work plan and Schedule

Our work plan is guided by the proposed activities listed above. Please see attached OpenCHS Gantt chart that enumerates milestones and indicates the member or partner responsible to oversee that particular process. The Gantt chart can also be accessed on Google docs link below:

https://drive.google.com/file/d/1L_47beCyQ5rvzFK2RNRD4Ik8bhzE9QAK/view?usp=sharing

Project Deliverables

Measures of Success:

We target to work with our partners to enroll as many implementers and users of the system as possible. Our partners Child Helpline International have a network of 147 countries. Our other partners UNICEF ESARO and UNICEF Europe & Central Asia have a combined membership of more than 42 countries. We will work with all stakeholders to define what metrics to use to measure the success of the OpenCHS community of practice. Initially we have grouped below deliverables over the period of 2 Years.

	6Months	12 Months	18Months	24Months	Comments
Create an Online Digital Home	Virtual Community Established housing appropriate communication tools and processes	Identify opportunities for interactions and collaborations	The community houses a group of organizations and a codebase for sharing CHS expertise, best practices, and code	Shared Roadmap Community members can easily see the OpenCHS roadmap and identify opportunities for overlapping goals and interests.	Processes for identifying and prioritizing content, goals and interests are clearly stipulated for the community members and partners.
CoP Members	5	10	15	20	Recruit as many members as possible including other domains of interest such as HIV, GBV
Implementers	3	2	2	3	Implementers are Child Helplines
Regions / Continents	Africa	Asia	Europe	More distribution in these 3 regions	Promotion to other continents /regions to use OpenCHS
Partners	5	1	2	2	Apart from the existing partners bring others on board
Developers		2	3	4	We intend to onboard developers in applications such as RapidPro, RapidSMS, Enketo, Superset, Druid and other applications / technologies in use by OpenCHS
Surveys / Success Stories		1	1	1	A safe platform for implementers, developers, users is provided for them to share their success stories
Workshops / Conferences		1		1	Hold 2 promotional workshops in 2 regions improving membership to the CoP (1 to be held in Africa and the other in Europe & Asia region)
Software Improvements	User Interface Enhancements	Multi-Lingual Support	API development and Self-installer Packaging	Roadmap strategy for development of release of version 2.0 Improved User, Training and Technical Manuals	As more members join the CoP more users of the solution will come onboard enhancing the global good of the OpenCHS solution.

*Based on community contributions start development of version 2.0 by end of Year 2

Governance Structure and Sustainability

Being an open source community the OpenCHS community will see social capital as the main capital. This will therefore mean prioritizing people management so that contributors feel a sense of belonging and needed and that their contributions add value to the project.

Governance Structure

The OpenCHS community will be governed through a well-developed charter that is simple and clearly understood by members. We have proposed to have a qualified Health Systems Management expert lead this process of developing a governance charter. While building this community of Practice we will aim to adopt a governance structure that balances between autonomy and control. At this early stage of building the community we will focus on expanding the CoP. In this regard the focus will be to expand the Child Helpline CoP by improving the Open Child Helpline System (OpenCHS) and by making moderate use of a wide selection of governance mechanisms. As many members across the different continents will be encouraged to join the community. Initially we will encourage knowledge sharing by members within the domain but eventually contributions from outside the organization will also be welcomed. Strong leadership of the community will be essential at this stage but with low disciplinary authority. By end of the 2nd Year we hope to have a probing community where knowledge is shared with members throughout (and outside) the OpenCHS CoP and focus will be on generating new practices, exploring new knowledge domains, improving operational efficiency supported by a governance structure that replaces direct managerial control with indirect nurturing of the communities routines.

Some of the guiding principles that will help in forging the sense of a community and management of the community will include:

Membership – Clearly defined criteria for membership hence promoting the feeling of belonging. The process will be open and transparent.
Influence - Establish a platform for members to influence community and community to influence members
Fulfillment of needs – Members will feel rewarded in some way for their participation
Emotional connection – Whether it’s the Child Helplines across the globe, government Ministries, donors such as UNICEF, PLAN International, Save the Children and any other stakeholders, they will have a sense of shared history and shared participation
Creating a community charter – This will indicate some of the values that the community lives up to as well as expectations in the community
Our technical team will create a dashboard that monitors metrics of contributors such as showing how active a particular members have been. These can help to show activities of volunteers. If say a particular volunteer who has been very active all of a sudden is not as active a decision can be done to may be call them and check on them.

Sustainability

Long-term sustainability of the OpenCHS community is important. Child Helpline International currently has a membership of 147 Countries. Out of these about 7 countries are using the OpenCHS. Apart from Africa, the enhanced OpenCHS has received interest from more countries in Europe and Asia. It is therefore very important that a sustainability strategy is adopted to ensure that the community benefits from the social and financial capital investment that will go into development of this community.

If successful, the funding will get the CoP up and running. We intend to build the Community of Practice by bringing on board more members who will become active contributors to the community. Since most of these members will also be implementers of the solution, we anticipate a robust OpenCHS community of practice. Tensions in the community may lead to a fork often with negative effects on the solution. Building a heterogeneous community of practice is therefore critical to us and therefore:

The community must be perceived as supportive, diversified and independent so that the governance will be appealing to both old and new contributors.
No legal obstacles that could hinder development or distribution of the OpenCHS across the community of practice membership
A culture that encourages re-use and distribution of the OpenCHS as much as possible.
Documentation of the source code and the OpenCHS solution to be properly done
Most importantly for the developer members is that the technologies utilized in this solution are also applicable in other domains. An example is the call, QA and case registration modules. These can independently be plugged into other solutions such as gender based violence and other health related systems with little customizations. We believe this will encourage developers to participate in contributing to the project and remain in the community.
Risks are reduced as there is no single firm or organization that has sole knowledge and monopoly of the OpenCHS as it is open and transparent

Overall the long-term sustainability of OpenCHS does present a challenge but we see good recruitment of contributors and right platforms to retain contributors as critical and fundamental to the success of the OpenCHS community of practice. Together with our partners and the steering sub-committee that will be formed we will work together to source for further funding in support of the community beyond the 2^nd year of the project.