Low- and middle-income countries (LMICs) have, over the last decade, seen an exponential increase in the adoption of digital health solutions. Among the systems being actively implemented in these settings are electronic health record (EHR) systems. These are deployed to largely replace or supplement existing paper-based records, with the aims of improving quality of patient care and supporting the monitoring and evaluation of programs [1-3]. Several LMICs have gone beyond initial pilot EHR system implementations to large-scale rollout of these systems in government-run public facilities. Countries like Kenya, Uganda, Nigeria, and Mozambique now run nationally endorsed EHR systems that are deployed in hundreds to thousands of public health facilities across each country [4-7].

In most LMICs, national-level EHR system initiatives have largely been driven by the need to support HIV care and treatment, with significant funding coming from donor organizations such as the U.S. President’s Emergency Plan for AIDS Relief. EHR systems targeting HIV care largely focus on the HIV care continuum, which emphasizes (1) finding patients who are HIV-positive (through active screening approaches), (2) linking HIV-positive patients to care, (3) ensuring that patients are on appropriate treatment, and (4) actively following patients to retain them in care [8-10]. The continuum of care paradigm is widely applicable for numerous other chronic diseases and is employed within other EHR systems to support longitudinal care in LMICs.

There are several core functionalities needed within EHR systems to support longitudinal care, key among them being the abilities to register patients, review historical patient information, and collect new data on patients. Features such as computerized decision support, order entry capabilities, and electronic prescribing are often incorporated at varying levels [11]. In many settings, retrospective entry of data is still employed, though efforts are underway to increase use of EHR systems at the point of care [12]. Point-of-care EHR systems still face the challenges of inadequate infrastructure, unreliable system uptime, cost, busy care settings, and provider discomfort with real-time entry of data while caring for patients.

The most widely employed modality of EHR system implementation in LMICs involves standalone EHR system implementations at individual facilities [13]. This implementation model entails installation of a local server, local area network, and end user terminals. The model relies on a dependable electrical supply and readily available information technology personnel [14]. Unfortunately, these infrastructure and personnel requirements are prohibitive in many LMIC settings, particularly in remote areas—exacerbating the “digital divide.” Facilities in areas with limited power, internet connectivity, and technical support are thus less likely to implement EHR systems [15]. Further, population health programs and community-based care services occurring outside of care facilities, such home-based HIV screening, testing, and patient tracing, are often poorly supported when access to EHR systems is limited to facilities.

To address some of the challenges and gaps with tethered EHRS that can only be accessed from within facilities, mobile health (mHealth) solutions are increasingly being adopted in LMICs [16,17]. Ideally, these mHealth systems should exchange data with the predominant EHR system, but a majority do not [18]. Instead, most mHealth systems often collect and transmit data to their own independent repositories that are separate from facility-based EHR systems—adding to the problem of siloed information for patients spread across multiple systems [19]. In the absence of interoperability with facility-based EHR systems, mHealth solutions cannot receive and display comprehensive historical patient and treatment information that are stored in the separate EHR systems, adversely affecting quality of care. Even when mHealth systems are able to share data with facility-based EHR systems, there is often lack of robust deduplication approaches for patient data, causing further challenges. Other common challenges observed with attempts to synergize mHealth solutions with facility-based EHR systems include (1) a lack of robust mechanisms to generate subsets of patients from EHR systems to be availed on mobile devices that have limited data storage capacities; (2) inefficient data synchronization, with mHealth applications requiring a complete wiping of existing data prior to new updates, resulting in increased expenses from use of paid internet data known as data bundles; (3) suboptimal mechanisms for updating or adding new forms, with some mHealth solutions requiring a new version of the application to be installed every time new forms are deployed; and (4) inability to handle forgotten log-in credentials that are aligned with EHR system credentials when providers are off-site.

With renewed emphasis on reaching the “last digital mile” while ensuring health information exchange with existing EHR systems, mHealth solutions are needed that can seamlessly interoperate with existing EHR systems in LMICs. This exchange is needed even in settings where health information exchange infrastructure is yet to mature [20]. In this paper, we present one such mobile application, mUzima [21], a UNICEF-recognized digital global public good [22], as a demonstration of a successful extension of existing national-level EHR systems in several LMICs, with the aim of increasing access and reach of digital technologies for providers and patients. We report on mUzima’s features and functionality, guided by the mHealth Evidence Reporting and Assessment (mERA) guidelines [23] and referencing the World Health Organization (WHO) Principles for Digital Development framework [24] where relevant. We also provide real-world examples of how the mUzima application has been scaled to support care across several countries and disease domains.

mUzima is a robust and adaptable Android-based mHealth platform that can seamlessly interoperate with the OpenMRS EHR system (Figure 1) [25,26]. The OpenMRS EHR system was chosen for the mHealth extension, as it is the most widely endorsed EHR system for national use by Ministries of Health (MoHs) across numerous LMICs. OpenMRS is currently in use in over 40 countries, with national deployments for HIV and tuberculosis care in Kenya, Mozambique, Nigeria, and Uganda, among others [27]. The hardware requirements for mUzima include an Android smartphone device and an OpenMRS EHR system instance. In Africa, over 85% of smartphones use the Android operating system [28]. mUzima was developed to work with Android versions 4.4 and above, as low-end Android smartphones predominate in LMICs. mUzima has robust offline functionality to address limited internet connectivity in many LMICs, allowing for health providers using mUzima to care for patients even when disconnected from the EHR system server. These infrastructure considerations align with the Digital Development Principles of “Understanding the Existing Ecosystem” by recognizing that power and internet connectivity challenges exist in the LMIC settings where mUzima is intended for use and that low-end Android smartphones predominate in these settings.

mUzima serves as an HIS for collecting primary health data, which are then exchanged with the associated EHR system. Health information exchange between mUzima and OpenMRS is achieved through use of the same concept dictionary terms, locations, providers, and patient identifiers that are common between the 2 systems. The REST API is used to connect mUzima to OpenMRS for bidirectional data exchange (Figure 1) [33]. This multifaceted approach for direct system-to-system exchange has been adopted to overcome the lagging implementation of robust health information exchange mediators and mechanisms in many LMICs. To facilitate future integration and health information exchange with other systems, several fast health care interoperability resources (FHIR) such as patient, provider, and observation FHIR are being developed for mUzima [34].

The WHO, in its “Recommendations on digital interventions for health system strengthening,” strongly advocates that “recommended interventions should be accessible via mobile devices at a minimum” [35]. mUzima is primarily for use by health providers through smartphones that are often owned by the care program. Access to mUzima is on-demand when the provider logs in with the relevant credentials. The providers use mUzima to access cohorts and historical data on patients under their care, as well as to capture new data on patients. Significant time and effort were expended to ensure that mUzima can auto-update changes in cohort membership, forms, and historical data elements (ie, managing delta), without the need to re-download data that had previously been downloaded onto the mobile device. This allows for seamless update of content to the mobile device through mUzima’s synchronization mechanism with OpenMRS.

Over half of the recommended digital interventions by the WHO pertain to mobile-based EHR solutions and include “digital tracking of clients’ health status combined with decision support; targeted client communication; digital provision of educational and training content to health workers; provider-to-provider telemedicine; and client-to-provider telemedicine” [35]. mUzima satisfies all of the WHO mobile-based EHR system recommendations. Core features currently available within the mUzima application are described in the following sections.

In line with the Digital Development Principles of “Building for Sustainability” and “Be Collaborative,” mUzima relies on a community of developers and implementers for content and user acceptance testing. As of February 2021, the mUzima community had 112 members, with a total of 31 unique contributors to the mUzima codebase. This community has made over 3800 contributions or commits to the codebase. Over 250 individuals have used, contributed, or reviewed mUzima documentation through mUzima’s Wiki platform [37], and more than 190 have contributed in the mUzima discussion forums [38]. The community is made up of stakeholders supported through various funded projects and agencies.

User testing for mUzima is conducted by a core team, as well as by community members prior to any mUzima release. Each feature in an mUzima release is documented as a JIRA ticket [39,40]. These tickets are used to track testing findings, with changes made based on feedback received. Final acceptance testing is conducted prior to deploying a new version of the application. Multimedia Appendix 5 provides a screenshot of release testing for a ticket in mUzima version 2.7.0, with details of testing status for each ticket in this version shared in a publicly available release plan [40].

A user-centered design approach is employed in developing core mUzima functionality and features and in adapting the application for various use cases. An engaged Implementer Community provides suggestions for features, as well as feedback on developed application components and content. This feedback is primarily gathered via weekly community calls and through the mUzima forum [38]. Additional user inputs are gathered through reviews of the application using the feedback mechanism in Google Play Store, where mUzima has thousands of downloads and a 5-star rating [41].

mUzima increases access to clinical data for providers who work outside of care facilities and in settings disconnected from the EHR system server. It is a provider-facing application and not available for direct use by patients. The application can leverage both WiFi-based or phone-based data bundles for data transmission. As an Android application, mUzima is not available to health providers who do not have Android smartphones and has limited utility to providers who are illiterate or unfamiliar with using smartphones. To use mUzima, providers need to have credentials to access an OpenMRS EHR instance, and this will limit utility of mUzima for those without such access or those using other EHR systems.

A formal cost assessment has yet to be done on mUzima. Although mUzima is available free of charge to users, there are still several associated costs to implement it. Key costs include customization costs that involve creating relevant forms for a program; development of queries that define cohorts of patients; smartphone purchase; costs associated with hosting an OpenMRS instance (if one does not exist); connectivity costs to the server through WiFi or Internet; and costs of personnel to support users, maintain infrastructure, and conduct training. Comparatively, in instances where care is conducted outside of facilities, mUzima implementation should be cheaper than using laptops equipped with OpenMRS—given the higher cost associated with laptops and managing multiple OpenMRS instances. Although paper-based systems have historically been used to support care in LMICs, they have recurrent costs given that pieces of paper can only be used once to record data, and there are personnel costs associated with retrospective entry of data collected on paper into the EHR system [42]

mUzima is freely available on the Google Play Store [41], with all changes and enhancements in any new version shared broadly via multiple channels, as well as fully documented in the collaborative wiki space [37]. Within the wiki space are documents on setting up the system, as well as training materials. Multiple introductory and educational videos on mUzima are also available through the mUzima YouTube channel [43]. mUzima training often involves technical personnel as well as training of end user providers. Technical team members, comprised of developers and implementing information technology personnel, often need to understand how to customize mUzima and to set up the server and smartphone devices for use. The technical team training is largely hands-on, with the mUzima community forums and weekly meetings available for answering questions from community members. End users are often trained by the technical team members from their organization. These trainings typically cover core mUzima features and also the customized elements relevant to that program. For most end users, training on mUzima typically takes 1 to 2 days. Refresher trainings are available especially when there are upgrades to the application.

The Digital Development Principle “Design for scale” is highly relevant to mUzima. Scalability was considered at the outset, allowing for the system to support any type of clinical condition, various workflows, and multiple versions of both OpenMRS and Android. Load testing is a core part of all mUzima version releases to ensure that mUzima works with larger patient populations and data needs. mUzima’s ability to scale is evidenced by its successful large-scale adoption across multiple clinical settings and countries (Table 2). As a testament of its scalability and implementation success, mUzima has been recognized as a digital global public good since 2019 [22] and is listed as a global project in the WHO “Digital Health Atlas” [44].

Despite having scaled to national levels, further expansion of mUzima is limited by the fact that it only currently extends 1 EHR system, OpenMRS. mUzima’s FHIR resources are under development to allow seamless health information exchange with other FHIR-compliant systems [34]. Customization of mUzima requires knowledge of form programming using HTML and basic knowledge on creating cohorts and queries within OpenMRS—both of which can limit scaling of mUzima implementations. Further, as a native Android application, mUzima will not work with smartphones that run on different operating systems.

mUzima has been used across various health domains (Table 2), with most use in primary contexts that have limited internet connectivity, especially in Sub-Saharan Africa. mUzima provides localization support for use in various languages and is currently available in 6 languages, namely English, Portuguese, French, Swahili, Gujarati, and Hindi. The application comes with multiple configurable settings that are not hard coded into the application. Examples of configurable settings include whether to capture GPS location of activity, default font size, auto-synchronization feature, time setting for automatic time-outs, form auto-save time interval, among other features. Forms, cohorts, and clinical observations within the application can be customized without any need for reprogramming.

Content related to mUzima is organized in the application’s website that highlights key application features and provides a demonstration instance for those interested in exploring the application [21]. This website provides links to all other mUzima-related resources and documentation. Detailed documentation on mUzima is available on the wiki page and includes user guides, technical documentation, and implementation guides, among others [37]. Multimedia content such as demonstration videos is also available on the mUzima YouTube channel [43]. mUzima code is shared via GitHub [47], and as of February 2021, there had been 650 pull requests and over 120 forks to the mUzima code.

mUzima is developed to enable the primary clinical implementing partners to remain full custodians of all data collected and transmitted to OpenMRS through mUzima. As such, identifiable patient information is only accessible to those given access through the EHR system. In line with the Principle for Digital Development to “Address privacy and security,” the mUzima application has incorporated several security features. Access to the mUzima is done through a username and password validated initially with the EHR system. Users who forget their password have to be re-authenticated within the EHR system by an administrator. mUzima contains a feature for automatic time-outs where users are logged out after a program-defined period of inactivity. Bidirectional exchange of data between mUzima and the EHR system is secured through use of an https protocol. All mUzima-related data are stored in an encrypted format in the mobile device.

Implementations using mUzima have full control of locations of servers where patient data from mUzima are stored. It is advocated that these implementations comply with data residency guidelines and laws for the country of operation. Organizations that opt to use mUzima are advised to contact relevant statutory bodies within countries that oversee mHealth applications. mUzima allows users to configure forms, patient identifiers, and concept dictionary terms to be used in each implementation. Compliance with national guidelines for these items is thus at the discretion of the implementers but is highly advocated. Forms and data elements can be easily developed to align with approved forms in countries and using any national dictionary should one be available. As an example, implementations in Kenya leverage the standards-based Columbia International eHealth Laboratory (CIEL) concept dictionary [46].

Performance of the mUzima application is gathered using the Firebase Crashlystics plugin [48]. These performance metrics indicate that it takes <5 seconds for the application to launch and <1 second to upload each completed form payload to the OpenMRS EHR system from within mUzima. Over the most recent 3-month period (December 2020 to February 2021), the percentage of mUzima users without crashes in any of their usage sessions was 92.88%. mUzima also uses Firebase Crashlystics to monitor locations where mUzima has been used over a period of time, as well as high-level details of the users, broken down by user-provided gender and age (Multimedia Appendix 8). For individualized and detailed usage statistics, mUzima has also been programmed to collect paradata through logs of key components of the application while it is in use. Although performance and workflow analytics can be conducted on the logged paradata, there is a need to create a user-friendly and personalized dashboard highlighting a user’s work performance on mUzima that can be availed to support decision making around work patterns.