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.