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.