Development and User Testing of a Dynamic Tool for Rheumatic Heart Disease Management

Abstract

Objective Most rheumatic heart disease (RHD) registries are static and centralized, collecting epidemiological and clinical data without providing tools to improve care. We developed a dynamic cloud-based RHD case management application with the goal of improving care for patients with RHD in Uganda.

Methods The Active Community Case Management Tool (ACT) was designed to improve community-based case management for chronic disease, with RHD as the first test case. Global and local partner consultation informed selection of critical data fields and prioritization of application functionality. Multiple stages of review and revision culminated in user testing of the application at the Uganda Heart Institute.

Results Global and local partners provided feedback of the application via survey and interview. The application was well received, and top considerations included avenues to import existing patient data, considering a minimum data entry form, and performing a situation assessment to tailor ACT to the health system setup for each new country. Test users completed a postuse survey. Responses were favorable regarding ease of use, desire to use the application in regular practice, and ability of the application to improve RHD care in Uganda. Concerns included appropriate technical skills and supports and potential disruption of workflow.

Conclusion Creating the ACT application was a dynamic process, incorporating iterative feedback from local and global partners. Results of the user testing will help refine and optimize the application. The ACT application showed potential for utility and integration into existing care models in Uganda.

Keywords

medical informatics - pediatrics - rheumatic heart disease - public health informatics

Background and Significance

Rheumatic heart disease (RHD) results from untreated Streptococcus pyogenes throat infections causing recurrent acute rheumatic fever, resulting in ongoing valvular damage. An estimated 40.5 million people are living with RHD and 306,000 people die from RHD annually.[1] There is a disproportionate RHD disease burden in low- and middle-income countries (LMICs) and within indigenous and marginalized populations in high-income countries.[1] [2] [3] [4] [5] [6] [7] [8] The most significant decreases in RHD disease burden over the past three decades have occurred in nonendemic regions, whereas 82% of RHD deaths are estimated to occur in endemic countries.[3]

The cornerstone of managing RHD is secondary antibiotic prophylaxis (SAP), which protects against recurrent S. pyogenes infection.[9] [10] [11] The gold standard for prophylaxis is intramuscular benzathine penicillin G (BPG), administered at 21- to 28-day intervals. Patients need to receive at least 80% of doses on time to achieve adequate protection.[10] [11] However, inadequate adherence is a major barrier to global RHD control. For example, in Uganda median adherence is only 54%.[12] [13]

Multiple barriers, both at the individual and systemic level, exist to improving prophylaxis adherence including deficient BPG availability at local sites,[14] distance to medical facilities,[15] [16] [17] [18] [19] insufficient health care workforce to meet needs,[20] [21] and access to expert care concentrated within larger cities.[18] The World Health Organization has long recommended that SAP be delivered through registry-based programs.[22] [23] [24] However, few countries utilize RHD registries outside of the tertiary setting. Further, most RHD registries are static collection tools and do not provide dynamic features to support adherence. As an example, Uganda's National RHD Registry is largely run by research staff, existent at only a select number of centralized locations and dependent on REDCap, a web-based research application that lacks the functionality of a real-time clinical management registry.[25] Innovative strategies such as a decentralized cloud-based registry integrated into the public health care system could improve providers' ability to support SAP adherence for people living with RHD.

Objective

The goal of this project was to design a cloud-based application to empower dynamic decentralized care of RHD patients within the public health system of Uganda.

Methods and Results

Application Design Group

A working group comprised of informaticians from Cincinnati Children's Hospital Medical Center (CCHMC), application developers, clinicians (both from Uganda Heart Institute [UHI] and CCHMC), and information security experts met weekly over the span of a year (July 8, 2020 to July 9, 2021) to design the Active Community Case Management Tool (ACT) and complete user testing. Design of the ACT application was based on the Integrated Data Environment to eNhnace ouTcomes in Youth registry, a CCHMC mobile application originally designed to improve care for children in protective services.[26]

Application Architecture

ACT was designed as a web-based application, compatible with Microsoft Edge, Mozilla Firefox, and Google Chrome and can be accessed via laptop, tablet, or smartphone. Information is stored in an Amazon Web Services (AWS) database, ensuring that Uganda owns the data but can also easily share across sites as the application use is expanded. The CCHMC information technology security team, in conjunction with the National Information Technology Authority Uganda, ensured that country-specific security and regulatory policies were upheld. The Patient's Charter of 2009 (notably Section 15 that grants patient privacy and informed consent), and the Data Protection and Privacy Act of 2019 (giving patients control over data collection, sharing, and disclosure), among others were referenced to guide system architecture with Ugandan privacy protection compliance as the requirement. We also noted that Ugandan privacy law was written in accordance with the Malabo Convention, giving the potential for future expansion into other African Union countries. There exists the potential for the application to expand to other regions, although these will need to be assessed on a case-by-case basis to ensure accommodations are made for the various differences in nations' privacy laws. Built in security features include password protected individual log on information, automatic logout for inactivity, and archiving of each user's data access to allow for review of a user's activity in case of security concerns. Additionally, secure sockets layer (SSL) encryption is used for all traffic to and from the application. The database and application have protections so that one cannot circumvent the application to directly access the database. The system uses two core open-source software libraries, React and Chalice. AWS is the only proprietary software used in the system. Data from ACT are currently exported as Comma Separated Values. However, other export formats could be implemented if preferable to users, such as SAS Script, R Script, JSON, and XML.

Design Approach

Development of the ACT application was focused on designing an application that was practical and effective in low-resource settings. Both quantitative and qualitative data were used to inform initial design and subsequent iterative refinement. While the focus of ACT is for RHD management, we believe the process is replicable and may be relevant to management of other chronic diseases in low-resource settings.

Phases of Design

Development of the ACT application was organized into three distinct phases including conceptual design (Phase 1), revision and refinement (Phase 2), and initial user testing (Phase 3). During each phase, the application design group consulted key partners including a Global Expert Network (Phase 1 + 2), a Ugandan RHD Steering Committee (Phase 1 + 2), and test users (Phase 3; [Table 1]). The Global Expert Network of 7 members included RHD clinicians and researchers, mobile health experts, and individuals with expertise of eHealth solutions in LMICs. The Ugandan RHD Steering Committee of 12 members included frontline health care workers, clinical researchers, a patient living with RHD, and representatives from the Ministry of Health and the District Health Offices. At phase 2, two new members were added to the Global Expert Network, and an additional consultation group was formed comprising six members from the Eastern Mediterranean Regional Office for the World Health Organization based on expressed interest and prior engagement with Reach ( www.stoprhd.org ), the nongovernmental organization that coordinated and conducted partner engagement. The test users consisted of 24 volunteers (physicians, nurses, and other allied health professionals) from the UHI who opted in to testing the ACT system for usability. No private or personal information (besides name, which was optional) was collected about test users. None of the test users were students and the design team did not have the power to affect job performance or employment. All user testing was performed using fictional patients with no real patient data; therefore, no patient consent was required for user testing of the ACT application.

Table 1 Active Community Case Management Tool application design phases with goals and key partner groups

Design phase	Goal	Partners supporting the application design group
Phase 1: Conceptual design	Identify key data elements and critical functionality	Global Expert Network Ugandan RHD Steering Committee
Phase 2: Revision and refinement	Evaluate the first iteration of the application against Phase 1 goals, design, and ease of use	Global Expert Network Ugandan RHD Steering Committee EMRO Consultation Group
Phase 3: Initial user testing	Test dynamic data entry through a predefined set of patient interactions and outcomes	UHI test users

Abbreviations: EMRO, Eastern Mediterranean Regional Office; RHD, rheumatic heart disease; UHI, Uganda Heart Institute.

Analysis Approach across Phases

Survey Data

Surveys were completed electronically using Google Surveys (Phase 1 and 2—key partner feedback) or via REDCap Survey (Phase 3—test user feedback). Descriptive statistics were used to examine Likert scale responses. Comments from surveys were compiled and reviewed by the primary researcher for examples and themes in the categories noted in [Table 2].

Table 2 User testing comments and feedback

Theme	General topics	Specific examples
Technical problems	Roadblocks to completing tasks	“I was able to open the RHD consultation update form but it will not allow me to save.”—test user C “Today I was meant to report that stocks for my patient was expected to be delivered on 31st May 2021 but unfortunately, the system couldn't allow! They could only accept 30th as the furthest date.”—test user B
Content issues	Difficulty finding content Lack of field to enter certain type of data	“There are some drugs that were not included on the list of drugs on the application (unable to recall now). Also where to record investigations like CT scan at tertiary care level.”—test user O “The application does not provide for an option to entering more than one admission diagnosis.”—test user E
Device issues	Problematic engaging with application on phone	“Thanks, the experience is getting better as we attend to tasks every week. I use a phone not PC or Tab(let) to access all my tasks, I have a challenge of reading all the words as they don't appear complete if something can be done with 'fonting' or any other way to make it better, thinking aloud...”—test user F “…however I have noted that using a phone is problematic. Forms cannot be saved easily. This requires the user to save the same file several times.”—test user E
Ease of use	User friendly, but challenging if not “computer savvy”	“In the beginning it was hard, but when you get used it is very easy.”—test user N “The ACT application is generally a user friendly application and easy to use.”—test user E “I was not able to log in. I don't know how to use computer and my smart phone was not helpful. I know you people tried to help us at the training, but I could not remember anything afterwards. I didn't have time for follow up but I also felt that coming to research office for such a complaint would disturb ‘people there.”—test user T
Pertinence to RHD care	Improving access Addressing and tracking BPG supply issues	“Care of RHD patients needs a dedicated application that is accessible at all levels and enables communication between levels. This application does just this. It is also instrumental in keeping up with BPG stock.”—test user I “We have had issues of BPG stock outs. This tool will be very helpful to stocking health centres.”—test user D
Feasibility	Concerns over sufficient time	“For RHD cases yes. I would gladly use it if we have clearly defined roles.”—test user M “During the entire pilot period I had challenges with time between my patients and to go to the tablet or phone to update. It is good for people who are not very busy and that can switch between writing in patient's book and phone/tablet. I don't normally have this much time. If I had enough time, this would be the best way to keep track of my patients.”—test user A

Abbreviations: ACT, Active Community Case Management Tool; BPG, benzathine penicillin G; CT, computed tomography; RHD, rheumatic heart disease.

Interview Data

Feedback was collected via Zoom calls using predetermined interview guides ([Supplementary Appendix A], available in online version). Sessions were recorded and later replayed for notation of direct quotes. Digital transcripts were not generated due to poor connections and/or interviewee accents. Quotes were synthesized and summarized in topic areas presented below.

Phase 1: Conceptual Design

Partner Engagement for Data Collection

Literature review of existing RHD registries and input from development team members were utilized to develop a survey of data fields and application functionality ([Supplementary Appendix B], available in online version). The Google survey was circulated by email to 14 of the 17 Phase 1 partners (specifically selected to represent key areas of application intersection or use), requesting grading on elements for the major content areas of the application as either essential, helpful, or nonessential. Partners were also asked to provide open-ended feedback on potential additional information to be captured. Following collation of the survey responses, 14 of the 17 Phase 1 partners were invited to participate in interviews and discussions via Zoom calls to further elicit feedback on application structure and function, broader health system considerations, integration with existing systems and applications, and considerations for user testing of the application. Partners were invited to interview either individually or in conjunction with another partner with similar role and function.

Results

The survey was completed by 10 of the 14 partners invited. Of the 84 surveyed data fields, 81 data fields were considered essential by most (≥6 individuals). Additionally, five critical functions were identified including: (1) support adherence to SAP, (2) provide a common medical record, (3) enable communication across the different levels of the health care system, (4) provide individual and aggregate data to quality improvement, and (5) provide tools to monitor and react to BPG stock supplies.

Eleven interview sessions were completed (nine individual, two combined: two nurses for one and two physicians for the other). Analysis of interviews revealed four key design considerations: (1) developing a minimal viable product to minimize provider time burden, (2) ensuring a user-friendly environment to reduce barriers to technology adoption, (3) addressing inconsistent network (internet and cellular) in RHD endemic settings, and (4) reflecting quality metrics to track outcomes of interest.

Impact on Active Community Case Management Tool Application Design

Survey data and key principles of design identified during interviews provided important guidance regarding operationalization of each data and functional element ([Table 3]). The team focused on developing a simple graphical user interface to ensure high uptake by providers with a range of technological experience ([Figs. 1],[2],[3],[4],[5]).

Table 3 Mapping the design of critical functionality to key interview themes

Critical functionality	Approach	Key themes addressed
Support sap adherence	Adherence automatically calculated based on patient's SAP prescription and BPG injections entered Patient card displays summary information without having to open full-patient chart Patient card graphically highlights adherence and type of prophylaxis Next injection information displayed in red (not covered), yellow (approaching), or green (covered) Provider and patient communication (SAP reminders) displayed on patient card	(1) Minimal product (2) User friendly (4) Quality metrics
Common patient record	Summarized care plan with critical elements in one place for review prior to or when data entry is not needed Forms for diagnostic results, cardiac medications, pregnancy, hospitalization, and interventions Mandatory fields for critical information, dynamic fields for clarifying or supplemental information Offline feature for critical data (prophylaxis administration), with upload once network is restored	(1) Minimal product (2) User friendly (3) Inconsistent network
Communication	Simple integrated in-application messaging system developed to connect care providers across levels of the health care system Communication prioritization (high or low urgency) with message resolution by initiating party	(1) Minimal product (2) User friendly
Guide quality improvement	Dashboard based on the RHD cascade of care[13] Sortable quality databased on facility, district, or national level Surgical prioritization score integrated into patient records	(4) Quality metrics (1) Minimal product (2) User friendly
Monitor and react to BPG stores	Capture of current stock critical for BPG administration (BPG, syringes, needles, lidocaine, sterile water) Calculates low (<50%), running out (<20%), and critical (<5%) stock alerts based on patient assignment to clinic and forecasted need at health care center	(4) Quality metrics (1) Minimal product (2) User friendly

Abbreviations: BPG, benzathine penicillin G; RHD, rheumatic heart disease; SAP, secondary antibiotic prophylaxis.

Fig. 1 Patient summary slides (data presented in this figure are imaginary). (A) Patient card demonstrating patient ID, prophylaxis prescription, adherence level, and BPG coverage. (B) Care plan demonstrating more detailed information regarding allergies, last echocardiogram, recommended interventions, RHD complications, and cardiac medications. BPG, benzathine penicillin G; RHD, rheumatic heart disease.

Fig. 2 Patient registry displays all active and inactive patients within the registry with various search features available to sort patient cards by desired features (such as prophylaxis management clinic, approaching BPG injection due, name, etc.). BPG, benzathine penicillin G.

Fig. 3 Reports display aggregate information on ACT registrants, RHD care (including referral and completion of surgical or catheter-based intervention), and BPG adherence which can be filtered by clinics at various health system levels. ACT, Active Community Case Management Tool; BPG, benzathine penicillin G; RHD, rheumatic heart disease.

Fig. 4 Offline BPG entry and reconciliation. (A) Offline BPG entry form used to enter an individual's BPG injection when internet connection is unavailable. (B) Stored BPG Form that automatically populates upon logging in to the ACT application once internet connection is reestablished. Users have the ability to view all offline BPG injections entered, fix any invalid forms, and then submit after which all valid entries are automatically reconciled and placed in the appropriate patient chart. Invalid forms are stored within an invalid BPG form repository where they can be addressed at a later date. ACT, Active Community Case Management Tool; BPG, benzathine penicillin G.

Fig. 5 Survey responses from partners regarding ease of ACT application tasks (A) and from test users regarding the ACT application (B). Responses regarding ease of tasks were rated from easy (1) to impossible (5). ACT, Active Community Case Management Tool.

Phase 2: Revision and Refinement

Partner Engagement for Data Collection

Members from key partner groups—Ugandan Steering Committee (6), Global Advisory Group (7), and Eastern Mediterranean Region Consultation Group (6)—were provided an introductory video, abbreviated user guide, and screen shot instructions as an overview of the ACT application. Topics covered included navigation to various forms, overview of data elements, and key functionality. Partners received a password and were instructed to sign into the application at their convenience. While unstructured browsing was encouraged, each test user also received a task guide to ensure all critical features were tested. Feedback was elicited via an electronic survey regarding evaluation on critical functions, user-friendliness and design, and applicability of the application in partner settings ([Supplementary Appendix C]; available in online version). Users were also invited for semistructured interviews.

Results

A total of 11 partners provided feedback (5 from the Global Expert Network, 2 from the Ugandan RHD Steering Committee, and 4 from the Eastern Mediterranean Region Consultation Group). Of these, four completed only the survey, four completed only interviews, and three completed both the survey and interviews. Survey responses regarding ease of completing seven core tasks were overall favorable ([Fig. 5A]). Additionally, most partners felt the ACT application would save valuable clinical work time (5/7, 71%), help health workers follow-up with patients (6/7, 86%), keep patients linked to care (4/7, 57%), and maintain BPG stock at lower-level health centers (6/7, 86%). Feedback from the surveys and interviews was combined and grouped into the categories of questions, technical problems, design concerns and suggested additions, and implementation concerns and suggestions. Most questions, such as those on how adherence was calculated, were answerable through development of a user guide. Three technical errors were discovered around application navigation and offline data entry.

Partners suggestion for additional features, such as application-generated reminders, ability to customize data export, and augmenting metrics on the quality reports,

Phase 2 data also identified partner implementation concerns and offered suggestions. These included considerations for transferability of the application to other contexts, attention to cyber security, consideration of in-country technical support, and sensitivity to the burden the application may create for providers in resource-limited settings.

Partners commented on the ACT applications transferability to other regions, ensuring buy-in and involvement of local governments and performing a situation assessment of a country to ensure ACT is tailored to the current health system setup. They pointed out potential barriers including poor internet availability, limited access to personal computers, and burden on already resource-limited areas.

An additional consideration was integration of clinical workflow with the reporting workflow, focusing on use of the mobile-friendly application as primary point of data entry. As a result, our training emphasizes real-time data integration—rather than using paper initially and then transferring the data to the application. Partners also stated the necessity for local IT expertise and ministry of health buy-in to ensure application sustainability beyond the timeframe of the project. Finally, partners raised that the application should comply with regulatory, institutional, and national requirements and ideally integrate with local health management information systems, all of which, except for integration with other systems, were achieved.

Impact on Active Community Case Management Tool Application Design

Design concerns and suggested additions were presented back to the Application Design Group for consideration and ranking of importance based on cost for development and increasing complexity of the application. The group determined by consensus if each suggestion was high, medium, or low priority and if it would be tackled immediately, postponed for future iterations, or excluded ([Table 4]).

Table 4 Phase 2 application suggestions, rankings, and rationale

Suggestion	Timeframe	Priority	Rationale
Field to note breakthrough ARF infections	Immediate	High	Easily added data field on complications form
Freeze the header bar to allow header visibility while scrolling	Immediate	Medium	Easily modified
Alert status column: wrap text/make small enough to see all text at once	Immediate	Low	Easily modified
Application-generated reminders for patients and health workers	Future	High	Outside current scope, but parallel pilot testing of approaches underway
Ability to customize export of data	Future	High	Costly to develop data download features, need more consultation with teams to determine critical outputs
Include other NCDs to improve quality of care	Future	High	Outside current scope, but need recognized
Additional metrics on the reporting page (RF/RHD annual incidence; an additional measure for quality of patient care)	Future	Medium	Additional key metrics to be developed in field testing within health systems
An interesting graphic/metric: how long clinics stayed in critical stock status (to show how soon BPG runs out and how quickly the supplies are refilled)	Future	Medium	Concern for overcomplexity of stock page, consider as report in future iterations
Consider added functionality to give recommendation on how low adherence be improved	Future	Low	Complex to develop and integrate global recommendations for adherence improvement. Considered outside current scope

Abbreviations: ARF, acute rheumatic fever; BPG, benzathine penicillin G; NCD, noncommunicable disease; RF, rheumatic fever; RHD, rheumatic heart disease.

Phase 3: Initial User Testing

Active Community Case Management Tool Uganda Heart Institute User Testing

A 60-day virtual user testing of the β version of the ACT application was performed at the UHI from April 26, 2021 to July 1, 2021. Physicians (9), nurses (11), pharmacists (2), and administrators (2) volunteered to be test users and were assigned user roles ([Fig. 6]). Fifty-two fictional patients each with a detailed narrative, including unique events and interactions with the health care system, were created for the user testing. These events were then used to create a master calendar, which was utilized by the clinical research coordinator (CRC) to facilitate the user testing.

Fig. 6 Assigned roles for ACT user testing assigned role is indicated first, followed by users fulfilling the role noted in parenthesis, and the users' position at UHI in italics. The * denotes that these roles were fulfilled by the same user. ACT, Active Community Case Management Tool; UHI, Uganda Heart Institute.

In brief, the CRC triggered actionable events for the test users through an individualized weekly email that detailed each user's responsibilities by day and daily email reminders of tasks. These activities varied by role but included things such as entering an SAP injection, documenting a patient reminder about an upcoming injection, or checking performance of an individual clinic through the quality dashboard. Using this approach, each data entry field, form, feature, and function of the application was tested multiple times by multiple users. Task completion was monitored and supported to ensure that the failure of one user to complete a task did not have downstream effects on tasks assigned to other users.

A REDCap survey was employed in real time for test users to enter feedback or encountered errors. A standardized postuser testing survey elicited further feedback and comments ([Supplementary Appendix D], available in online version). If a test user had not completed a survey, they were approached and responses to the questions obtained via interview.

Results

In total, 24 employees signed up to be test users at UHI; 22 obtained access to and successfully interacted with the application with a total of 332 patient-based events, some of which required completion of multiple tasks. A patient-based event was considered fully complete if all tasks for the event were accurately reflected in the application. Events were considered partially completed if not all assigned tasks were performed or if any of the assigned tasks were performed inaccurately. Of the 332 patient-based events, 62% (205/332) were fully completed, 0.08% (28/332) partially completed, and 30% (99/332) not attempted. Tasks not performed were considered “Critical” if the data not captured would: (1) impact accurate SAP management (e.g., prophylaxis prescription not added), (2) have significant theoretical impact on patient health (e.g., prescription not changed after allergic reaction to penicillin), or (3) have significant implications on patient status (name change not recorded). The most frequently missed critical task was failure to record BPG injection, accounting for 60% (34/54) of all critical missed tasks, followed by failure to record patient death, 9% (5/54). “Noncritical” missed tasks were those not recorded but without significant implications on BPG adherence, patient health, or crucial patient status. Of missed noncritical tasks, failure to record a reminder was the most common, accounting for 30% (25/75) of all noncritical missed tasks, followed by failure to record consult note, 24% (20/75). For tasks that were completed inaccurately (10), 80% were due to creation of a duplicate patient within the application rather than recording tasks within the preexisting record.

All 24 test users were invited to complete a postuser testing survey and 22 (92%) completed it. Two respondents provided comments only and no responses to Likert Scale questions. Responses to the Likert scale questions can be seen in [Fig. 5B]. Responses were overall favorable, with many strongly supporting ease of use, a desire to use the application in their regular practice, and a sense that the application would improve RHD care in Uganda. The main area of hesitancy was around the potential impact on workflow. Comments and feedback fell into six themes: technical problems, content issues, devices issues, ease of use, pertinence to RHD care, and feasibility. Examples within each theme are provided in [Table 2]. Specific feedback included refining the communication feature (pointing out that most urgent communication is accomplished using the phone) and improving the BPG stock out display.

Impact on Active Community Case Management Tool Application Design

As a result of the user testing and final partner review, several additional technical modifications were made to the application. These included: (1) improved display of application on phones/mobile devices, (2) improved autosave of BPG delivery form, including offline saving feature, (3) addition of a “Contact Us Form” (users can notify administrators of issues without ever having logged on) and “Duplicate Patient Entry Notification,” (decrease risk of adding the same patient given potential spelling errors/interpretations), and (4) improved application organization (such as including subheadings, simplification of the BPG stock alerts, and improved sorting to facilitate application navigation).

Concerns raised about application feasibility allowed for tailoring training materials to address some of these issues. For example, training will clearly delineate proper indications for using the communication feature and continuing to use phone calls for more urgent issues.

Discussion

Registry-based care has been identified as a potentially powerful tool to improve outcomes in LMIC for diseases ranging from traumatic injury to cancer to RHD, while also recognizing potential barriers to optimal use in these settings.[18] [27] [28] [29] [30] Registry-based care for RHD has demonstrated improved adherence to SAP,[31] [32] but registries are often static and concentrated at tertiary care centers. ACT emphasizes provider-facing tools to improve support of SAP adherence at the community health care center level, incorporating functions to address barriers to successful implementation of registry-based care in LMIC such as: (1) focus on capturing most pertinent data and utilization of tailored user roles to decrease burden on users and improve accurate data entry,[27] [28] [29] [30] [33] (2) incorporation of a communication feature to link lower-level health care centers to RHD centers of excellence to improve transition of care,[29] (3) ability to enter SAP data while offline recognizing unreliable internet in many remote communities, (4) tools to monitor and manage prophylaxis supplies to address barriers around SAP availability,[14] [29] and (5) integrated quality dashboards reflecting real-time metrics available to individual providers and members of regulatory bodies, thus facilitating dissemination of knowledge to stakeholders and allowing for timely identification for areas of improvement.[28] [29] [30]

Coupled with other strategies, such as task shifting of screening echocardiography, ACT has the potential to not only improve SAP adherence but to aid the advancement of RHD care by helping establish reliable estimates of RHD disease burden.[3] [18] [34] Success in this area has been demonstrated by programs in Brazil, such as Circulo de Coracoa, which improved detection, quantification, and management for congenital heart disease.[35] [36] Enhanced quantification of RHD burden could aid efforts advocate for greater investment this underfunded disease.

Despite intentional design to optimize utility within LMIC, successful integration of ACT will require not only training, but also addressing other potential barriers to uptake. Remote facilities often face staff shortages and high turnover. One potential solution may involve empowerment of community health workers to help facilitate RHD care and maintain continuity for those with RHD.[29] Maintenance of this type of registry also requires significant financial and human resources. Additional financial and political investment from the Ugandan government to support the program (technical experts, repair of essential equipment, improved internet access, standardization of ACT utilization country wide, integration with electronic health records) will be critical for ACT to be sustainable. We continue to partner with the Ugandan Ministry of Health and other stakeholders to help facilitate this process.

Creating the ACT application was a dynamic process, incorporating iterative feedback from local and global partners. We started with a minimal viable product approach, with an emphasis on the most common end users to create a responsive RHD application to enable community case management of RHD. User testing and partner feedback informed not only the ACT application, but also the development of training materials and methods to help address concerns over computer literacy and ease of some test users in using the application, with particular focus on community health workers. The next stage of implementing the ACT application is within select health centers of the public health system in Uganda, which will add critical information to the feasibility of integrating this registry into standard practice and help advise strategies for success.

Limitations

While iterative feedback and user testing of the ACT application was crucial in refining its design, testing was completed with artificial scenarios. Hence, we were unable to refine the platform based upon barriers that may become evident only within real-world conditions. Moreover, during the testing users received reminders of critical tasks, which were not yet completed in order facilitate dependent scenario events. This testing was thus more controlled and not reflective of regular clinic workflow. Surveys eliciting feedback on the ACT application either required (key partners) or offered the option (test users) of providing the respondent's name. We recognize that having personal information tied to survey feedback has the potential to negatively impact volunteers. Finally, the ACT application was designed and tested by individuals from the UHI who may have greater health technology literacy than end users in a national scale up. Testing was also not performed in real-world circumstances and thus the impact it will have on workflow, data accuracy, and resource utilization will only become evident with future expanded use. Recognizing this limitation, a field pilot with select community health workers was planned prior to rolling out more broadly.

Conclusion

Partner engagement and feedback from design conception through user testing greatly informed and guided development of the ACT application. The user testing was crucial in identifying not only technical glitches not encountered during prior testing, but also user preferences and desirable features to further enhance the application and make it more user friendly. Investment in iterative expertise input and user feedback shaped the ACT application to better address the needs of the end user, creating a system tailored to improving RHD care for those in Uganda, which can also be adapted and expanded to other health systems within other countries and for management of other chronic diseases.

Clinical Relevance Statement

Creating dynamic and impactful applications for chronic disease management in low-resource settings must take into consideration the specific needs and challenges this poses. Utilizing an iterative process incorporating expert input and test user feedback allowed for the development and refinement of a web-based application tailored to the end user and specific quality metrics to improve RHD outcomes. We believe this model would translate easily to other chronic disease management in low-resource settings.

Multiple-Choice Questions

1. Compared with most other registry-based programs for SAP, the ACT application is innovative in that:

   • It will be used solely in tertiary centers

   • It will provide dynamic features to support adherence

   • It will be integrated into the existing electronic health record in Uganda

   • It will be most useful for use in high-income settings

   Correct Answer: The correct answer is option b. The World Health Organization recommends use of registry-based programs for secondary antibiotic delivery. However, most current registries are static, collecting data but lacking dynamic features to help support ideal adherence of at least 80%. ACT is specifically designed for use in low-resource settings and aims to decentralize care away from district and tertiary facilities, moving care closer to where patients live and allowing nurses at the lower-level health facilities to utilize ACT to improve SAP management. Ideally, Uganda will someday have a national electronic health record, which ACT can integrate with; however, at this time ACT is not integrated into any electronic health records.

2. Considerations that were raised regarding transferability of the ACT application to other regions include all of the following except:

   • Availability of reliable internet access

   • User access to personal computers

   • Involvement of local government

   • Availability of consistent power sources

   Correct Answer: The correct answer is option d. Partners commented on considering potential barriers to transferring the ACT application to other regions including a, b, and c as well as the burden on already resource-limited areas. Availability of consistent power sources was not raised by partners.

Conflict of Interest

None declared.

Acknowledgments

The authors would like to thank all partners and test users who gave their time and efforts to design an application with a vision toward impacting and improving RHD care. The authors would also like to thank Adriana Navarro Sainz, Gavin Durman, and other members from the design team who contributed to the application build.

Protection of Human and Animal Subjects

All study related activities were approved by the CCHMC Institutional Review Board (IRB) as well as the Makerere IRB and was conducted in compliance with the World Medical Association Declaration of Helsinki on Ethical Principles for Medical Research Involving Human Subjects.

• References

• 1 Roth GA, Mensah GA, Johnson CO. et al; GBD-NHLBI-JACC Global Burden of Cardiovascular Diseases Writing Group. Global burden of cardiovascular diseases and risk factors, 1990-2019: update from the GBD 2019 Study. J Am Coll Cardiol 2020; 76 (25) 2982-3021
• 2 Roth GA, Johnson CO, Abate KH. et al; Global Burden of Cardiovascular Diseases Collaboration. The burden of cardiovascular diseases among US states, 1990-2016. JAMA Cardiol 2018; 3 (05) 375-389
• 3 Watkins DA, Johnson CO, Colquhoun SM. et al. Global, regional, and national burden of rheumatic heart disease, 1990-2015. N Engl J Med 2017; 377 (08) 713-722
• 4 Baker MG, Gurney J, Oliver J. et al. Risk factors for acute rheumatic fever: literature review and protocol for a case-control study in New Zealand. Int J Environ Res Public Health 2019; 16 (22) 4515
• 5 Katzenellenbogen JM, Bond-Smith D, Seth RJ. et al. Contemporary incidence and prevalence of rheumatic fever and rheumatic heart disease in Australia using linked data: the case for policy change. J Am Heart Assoc 2020; 9 (19) e016851
• 6 Oliver J, Robertson O, Zhang J. et al. Ethnically disparate disease progression and outcomes among acute rheumatic fever patients in New Zealand, 1989-2015. Emerg Infect Dis 2021; 27 (07) 1893-1902
• 7 Beaudoin A, Edison L, Introcaso CE. et al; Centers for Disease Control and Prevention (CDC). Acute rheumatic fever and rheumatic heart disease among children–American Samoa, 2011-2012. MMWR Morb Mortal Wkly Rep 2015; 64 (20) 555-558
• 8 de Loizaga SR, Arthur L, Arya B. et al. Rheumatic heart disease in the United States: forgotten but not gone: results of a 10 year multicenter review. J Am Heart Assoc 2021; 10 (16) e020992
• 9 Carapetis JR, Beaton A, Cunningham MW. et al. Acute rheumatic fever and rheumatic heart disease. Nat Rev Dis Primers 2016; 2: 15084
• 10 de Dassel JL, de Klerk N, Carapetis JR, Ralph AP. How many doses make a difference? An analysis of secondary prevention of rheumatic fever and rheumatic heart disease. J Am Heart Assoc 2018; 7 (24) e010223
• 11 Manyemba J, Mayosi BM. Penicillin for secondary prevention of rheumatic fever. Cochrane Database Syst Rev 2002; 2002 (03) CD002227
• 12 Musoke C, Mondo CK, Okello E. et al. Benzathine penicillin adherence for secondary prophylaxis among patients affected with rheumatic heart disease attending Mulago Hospital. Cardiovasc J S Afr 2013; 24 (04) 124-129
• 13 Longenecker CT, Morris SR, Aliku TO. et al. Rheumatic heart disease treatment cascade in Uganda. Circ Cardiovasc Qual Outcomes 2017; 10 (11) e004037
• 14 Wyber R, Taubert K, Marko S, Kaplan EL. Benzathine penicillin G for the management of RHD: concerns about quality and access, and opportunities for intervention and improvement. Glob Heart 2013; 8 (03) 227-234
• 15 Huck DM, Nalubwama H, Longenecker CT, Frank SH, Okello E, Webel AR. A qualitative examination of secondary prophylaxis in rheumatic heart disease: factors influencing adherence to secondary prophylaxis in Uganda. Glob Heart 2015; 10 (01) 63-69.e1
• 16 Chamberlain-Salaun J, Mills J, Kevat PM, Rémond MG, Maguire GP. Sharing success - understanding barriers and enablers to secondary prophylaxis delivery for rheumatic fever and rheumatic heart disease. BMC Cardiovasc Disord 2016; 16 (01) 166
• 17 Barker H, Oetzel JG, Scott N, Morley M, Carr PEA, Oetzel KB. Enablers and barriers to secondary prophylaxis for rheumatic fever among Māori aged 14-21 in New Zealand: a framework method study. Int J Equity Health 2017; 16 (01) 201
• 18 Dougherty S, Beaton A, Nascimento BR, Zühlke LJ, Khorsandi M, Wilson N. Prevention and control of rheumatic heart disease: overcoming core challenges in resource-poor environments. Ann Pediatr Cardiol 2018; 11 (01) 68-78
• 19 Hjortsberg C. Why do the sick not utilise health care? The case of Zambia. Health Econ 2003; 12 (09) 755-770
• 20 Anyangwe SC, Mtonga C. Inequities in the global health workforce: the greatest impediment to health in sub-Saharan Africa. Int J Environ Res Public Health 2007; 4 (02) 93-100
• 21 Kinfu Y, Dal Poz MR, Mercer H, Evans DB. The health worker shortage in Africa: are enough physicians and nurses being trained?. Bull World Health Organ 2009; 87 (03) 225-230
• 22 Kumar RK, Antunes MJ, Beaton A. et al; American Heart Association Council on Lifelong Congenital Heart Disease and Heart Health in the Young; Council on Cardiovascular and Stroke Nursing; and Council on Clinical Cardiology. Contemporary diagnosis and management of rheumatic heart disease: implications for closing the gap: a scientific statement from the American Heart Association. Circulation 2020; 142 (20) e337-e357
• 23 Remenyi B, Carapetis J, Wyber R, Taubert K, Mayosi BM. World Heart Federation. Position statement of the World Heart Federation on the prevention and control of rheumatic heart disease. Nat Rev Cardiol 2013; 10 (05) 284-292
• 24 Karthikeyan G, Zühlke L, Engel M. et al. Rationale and design of a global rheumatic heart disease registry: the REMEDY study. Am Heart J 2012; 163 (04) 535-40.e1
• 25 Harris PA, Taylor R, Thielke R, Payne J, Gonzalez N, Conde JG. Research electronic data capture (REDCap)–a metadata-driven methodology and workflow process for providing translational research informatics support. J Biomed Inform 2009; 42 (02) 377-381
• 26 Greiner MV, Beal SJ, Dexheimer JW, Divekar P, Patel V, Hall ES. Improving information sharing for youth in foster care. Pediatrics 2019; 144 (02) e20190580
• 27 Rosenkrantz L, Schuurman N, Arenas C, Nicol A, Hameed MS. Maximizing the potential of trauma registries in low-income and middle-income countries. Trauma Surg Acute Care Open 2020; 5 (01) e000469
• 28 Pramesh CS, Badwe RA, Bhoo-Pathy N. et al. Priorities for cancer research in low- and middle-income countries: a global perspective. Nat Med 2022; 28 (04) 649-657
• 29 Eissa S, Lee R, Binns P, Garstone G, McDonald M. Assessment of a register-based rheumatic heart disease secondary prevention program in an Australian Aboriginal community. Aust N Z J Public Health 2005; 29 (06) 521-525
• 30 van Dam J, Musuku J, Zühlke LJ. et al. An open-access, mobile compatible, electronic patient register for rheumatic heart disease (‘eRegister’) based on the World Heart Federation's framework for patient registers. Cardiovasc J S Afr 2015; 26 (06) 227-233
• 31 Culliford-Semmens N, Tilton E, Webb R. et al. Adequate adherence to benzathine penicillin secondary prophylaxis following the diagnosis of rheumatic heart disease by echocardiographic screening. N Z Med J 2017; 130 (1457): 50-57
• 32 Okello E, Longenecker CT, Scheel A. et al. Impact of regionalisation of a national rheumatic heart disease registry: the Ugandan experience. Heart Asia 2018; 10 (01) e010981
• 33 Yen PY, Lara B, Lopetegui M. et al. Usability and workflow evaluation of “RhEumAtic Disease activitY” (READY). A mobile application for rheumatology patients and providers. Appl Clin Inform 2016; 7 (04) 1007-1024
• 34 Marijon E, Celermajer DS, Jouven X. Rheumatic heart disease - an iceberg in tropical waters. N Engl J Med 2017; 377 (08) 780-781
• 35 Mattos SdaS, Hazin SM, Regis CT. et al. A telemedicine network for remote paediatric cardiology services in north-east Brazil. Bull World Health Organ 2015; 93 (12) 881-887
• 36 de Araújo JS, Regis CT, Gomes RG, Mourato FA, Mattos SD. Impact of telemedicine in the screening for congenital heart disease in a center from northeast Brazil. J Trop Pediatr 2016; 62 (06) 471-476

Publication History

Received: 17 January 2023

Accepted: 08 August 2023

Article published online:
01 November 2023