Youth mental health challenges are among the most pressing global health issues today [1,2]. Half of all lifetime mental disorders begin by age 14 [3,4]. Most go untreated—particularly in low- and middle-income countries (LMICs), where shortages of trained clinicians and fragile health systems produce a significant treatment gap [1,2,5,6]. Closing this gap requires care models that are cost-effective at scale, contextually grounded, and delivered beyond traditional clinical settings into community spaces [1,7,8].

Task-shifting—training nonprofessionals to deliver structured, evidence-based treatments under supervision—has emerged as a promising strategy for closing the treatment gap [9,10]. When embedded within stepped-care systems, where the intensity of care is matched to individual need [9-12], this approach maximizes scarce resources, reduces costs, and leverages community infrastructure for delivery [12,13].

The Shamiri model is an example of task-shifting within a stepped-care system: a 3-tier school-based mental health program delivered by lay providers and clinical staff (Figure 1) [14,15]. In the first tier, lay providers aged 18-22 years are trained and supervised to deliver brief, group-based psychological interventions—typically weekly sessions of 4 weeks with groups of 6 to 15 students [16,17]. Clinical supervisors with backgrounds in psychology or clinical social work form the second tier, providing oversight of lay providers and direct one-on-one psychotherapy where needed [16,18,19]. Severe or complex cases are escalated to clinical psychologists and psychiatrists in the third tier [16,18,19]. Randomized controlled trials demonstrate that the Shamiri model significantly reduces depression and anxiety symptoms in secondary school students, with effects sustained at least 7 months after the intervention [14,15,20,21]. Cost-effectiveness analyses place delivery at approximately US $7.48 per student in 2024—among the most affordable youth mental health interventions globally [22,23].

Despite these outcomes, scaling innovations like Shamiri while maintaining fidelity and efficacy across diverse contexts remains a challenge. Two main dissemination strategies have been used [24,25]. The centralized approach, where the originating organization retains direct control, allows for tighter quality control but limits reach [23]. The decentralized—or “train-the-trainer”—approach, where other organizations implement independently, enables rapid scale-up but carries risks to fidelity and consistency [24,25]. Recent research comparing both approaches in Kenya found both effective at improving youth outcomes, though decentralized models require more robust support structures and greater funding to maintain effectiveness and fidelity [23].

As implementation moves across contexts and implementers, additional operational challenges arise—particularly for small or resource-constrained community-based organizations [23,26,27]. Coordinating multitiered teams, managing logistics and financial workflows, tracking real-time outcomes, and maintaining consistent training and supervision all pose barriers to broader uptake of otherwise effective interventions [23,26,27].

Digital platforms can address these bottlenecks. Purpose-built technology can reduce administrative burden, standardize supervision workflows, enable real-time monitoring, and facilitate client transitions across care tiers [13,28,29]. For task-shifted stepped-care models specifically, digital tools can provide lay providers with structured session prompts, automate operational workflows, support triage, and coordinate across roles [13,28-31].

Most existing digital mental health tools fall short of what community-based delivery in Kenya—and similar contexts—requires [13,30-32]. Available platforms are typically designed for high-resource clinical environments, carry prohibitive licensing costs, lack customizability for task-shifted workflows, and offer little or no offline functionality [29,33,34]. Multiple recent reviews confirm this infrastructure gap: digital mental health interventions developed for LMICs remain limited in number, and those that exist rarely include the operational architecture needed for stepped-care delivery, provider supervision, or scalable implementation [29,35-37]. Platforms built to coordinate lay-provider delivery, integrate operational and clinical workflows, and function in bandwidth-constrained settings are largely absent from the literature [29,37]. This gap is not unique to Kenya: across sub-Saharan Africa, South Asia, and Southeast Asia—settings characterized by severe mental health workforce shortages and limited digital infrastructure—the distance between the promise of digital health tools and the availability of platforms suited for community-based delivery remains wide [1,38].

To address this gap, we developed shamiriOS—an open-source digital platform built to support the scalable delivery of task-shifted youth mental health services in Kenya and similar settings. The name reflects its purpose: an integrated operating system for service delivery, not a conventional computer operating system. The platform comprises 3 interoperable product suites—the Shamiri Digital Hub (SDH), the Shamiri Provider Platform (SPP), and Rafi—each designed for a distinct user group within a task-shifted care approach like the Shamiri model (Figure 2):

These 3 products function as a unified delivery ecosystem: SDH runs the program, SPP supports the providers, and Rafi connects young people to care. Each component can be deployed independently or in combination, depending on an implementing organization’s context and capacity. Additionally, each component is “modular” in design: its features can be configured and adapted to meet the specific needs of different implementing partners, contexts, and end users.

Although the broader vision for shamiriOS encompasses all 3 components, this paper focuses primarily on the development and deployment of SDH and Rafi—built from the ground up—and on the initial integration of SPP, adapted from an existing clinical platform. shamiriOS builds on the capabilities and limitations of existing platforms, including case management systems such as CommCare and OpenMRS (Open Medical Record System), and youth-facing tools reviewed in our environmental scan [29,35-37]. Its distinctive contribution is an integrated, 3-product architecture combining operational management, clinical workflows, and client-facing engagement within a single open-source, context-specific system—a combination not found in existing platforms in Kenya or comparable settings. Successful adaptation for other countries is feasible with appropriate participatory redesign; the findings reported here are specific to the Kenyan context in which the platform was developed and validated.

This paper has 3 aims. First, we present an environmental scan of existing digital platforms to characterize their limitations for stepped-care youth mental health delivery in Kenya. Second, we describe the iterative, user-centered design and development process of shamiriOS. Third, we evaluate early outcomes from its deployment across centralized and decentralized implementation settings in Kenya between 2023 and 2024, reporting on adoption, user satisfaction, and feature refinement.

Together, these 3 elements—environmental scan, platform development, and early deployment—establish a foundational evidence layer for the ongoing development, evaluation, and contextual adaptation of integrated digital mental health platforms in settings where such infrastructure is critically needed.

This section describes the review, development, and deployment processes underlying shamiriOS. We first describe the environmental scan of existing platforms that informed our decision to build a custom solution. We then outline the iterative development of each component—the SDH and Rafi, built from the ground up, and the SPP, adapted from an existing clinical system. We describe technical access specifications, the engagement measurement framework used to evaluate deployment outcomes, and the phased deployment of the platform across centralized and decentralized settings in Kenya between 2023 and 2024.

All shamiriOS components are web-based or app-based and require no operating system modification, installation privileges, or proprietary software. This was a deliberate design choice to maximize accessibility for nontechnical users and reduce dependency on institutional IT infrastructure across diverse Kenyan implementation settings.

SDH and SPP are web apps accessible via any modern browser on desktop, laptop, or mobile devices. Both incorporate offline-first data capture with automatic synchronization on reconnection. Rafi is a native mobile app available on Android and iOS; core self-help content and check-in features are accessible offline, while therapy booking, triage escalation, and data synchronization require an active internet connection. A supplementary web portal provides browser-based access for users without smartphone access, synced with app data. Table 3 summarizes the minimum technical requirements and offline capabilities for each component.

Engagement with digital health platforms is multifaceted and context-dependent. We adapted a framework defining engagement as the extent to which users interact with each shamiriOS component in ways intended by the design and required for operational or clinical benefit [50]. We distinguish four levels:

Engagement is reported separately for each component, reflecting their distinct purposes and user populations:

What constitutes meaningful engagement differs by user type and platform purpose. For youths using Rafi, therapy booking and triage pathway use may be more clinically significant than daily login frequency. For supervisors using SDH, weekly engagement aligned with supervision cycles was operationally sufficient. For clinicians using SPP, session-by-session engagement was anticipated. Engagement data were drawn from backend use logs, session analytics via Metabase, and NPS surveys administered after deployment [51].

Our evaluation used pragmatic metrics derived from implementation science instruments [50-53]: measures used were (1) usability—a single-item satisfaction rating on a 1-10 scale (“How easy is the platform to use?”), administered to supervisors and hub coordinators after deployment; (2) acceptability—a NPS item on a 1-10 scale (“How likely are you to recommend this platform to a colleague?”) [51]; (3) engagement—backend use analytics tracking login frequency, feature adoption rates, data entry completeness, and retention over time, reported separately by component; and (4) qualitative feedback—open-ended survey questions and semistructured interviews conducted during and after training sessions.

The choice of pragmatic over standardized measures reflected several constraints. Sprint-based development cycles required rapid, actionable feedback that standard implementation science instruments—which typically require extensive administration time and psychometric analysis—could not reliably provide. The simultaneous development and evaluation of the platform also blurred the boundary between formative user research and summative implementation evaluation, making it difficult to administer standardized instruments at appropriate intervals. Field teams requested brief feedback mechanisms to reduce survey fatigue during intensive deployment.

The activities described in this paper comprised platform development, an environmental scan of existing digital tools, operational evaluation of the SDH using routine program monitoring data and satisfaction surveys from adult implementation staff, participatory design consultations with university students during Rafi’s development, and aggregated platform use analytics. Per the National Guidelines for Ethical Conduct of Biomedical Research Involving Human Participants in Kenya [54], mandatory ethics review applies to research involving human participants who are “exposed to manipulation, intervention, observation, or other interaction with investigators” or who “become individually identifiable through investigators’ collection, preparation or use of biological material, or medical or other records.” The activities reported here did not meet these criteria: data collection was operational or design-oriented, no sensitive personal or health data were collected, and the intent was product development rather than systematic generation of new knowledge about individuals. Formal ethics committee review was therefore not sought. All data handling complied with Kenya’s Data Protection Act [55] and Shamiri’s institutional data governance framework.

This study documents the development and early deployment of shamiriOS, an open-source, modular digital platform for scalable, task-shifted youth mental health service delivery in Kenya [15,20,23]. Three principal findings emerge.

First, an environmental scan confirmed that no existing platform adequately met the combined operational, clinical, and youth engagement requirements of the Shamiri stepped-care model. Reviewed platforms failed on at least 2 of 6 evaluation criteria—most commonly cost, offline capability, and customizability for task-shifted workflows. This reflects not a critique of those platforms, but confirmation that the infrastructure gap in community-based mental health delivery in Kenya was real and unaddressed by the global product landscape [34].

Second, the SDH demonstrated strong early feasibility and acceptability. Deployed across 5 hubs by the end of 2023 and expanding to 11 sites supporting over 76,344 students by Q1 2024, SDH replaced fragmented operational systems with real-time, role-differentiated digital infrastructure. Implementation staff reported high satisfaction (usability: mean 8.36, SD 1.49; NPS: mean 8.63, SD 1.46), and qualitative feedback consistently identified reductions in administrative burden and improvements in data timeliness and completeness. These results are consistent with evidence that well-designed operational platforms improve efficiency and oversight capacity in task-shifted delivery systems in LMICs [29,31,35-37,56].

Third, Rafi demonstrated strong initial reach—74.7% (n=3737) registration among the targeted MKU cohort—but significant engagement attrition, with MAU rates declining from 7.4% in January 2024 to near 0 by September. This pattern is common in digital mental health globally [37,39,57-60], but operational analysis identified specific, modifiable causes beyond structural or population-level explanations [39,58-60]. Among users who engaged with self-guided features, 99.4% subsequently booked therapy appointments—a cross-sectional finding requiring cautious interpretation, but one suggesting that self-help engagement may function as a gateway to clinical help-seeking for those who remain on the platform.

shamiriOS contributes to a growing landscape of digital mental health platforms in LMICs [29-31,35-37]. What distinguishes it is not any single feature, similar apps exist, but 3 architectural characteristics that together address gaps in the current platform landscape [61,62].

First, shamiriOS integrates operational management (SDH), youth engagement (Rafi), and clinical workflows (SPP) within a single interoperable ecosystem. Most existing platforms address one of these functions; few attempt integration across all 3. This reflects our view that sustainable digital mental health infrastructure must support not just the end-user experience, but the full organizational and clinical system within which that experience is embedded [63,64].

Second, the platform uses a modular, component-based design in which each suite operates as an independent service with its own codebase, database, and deployment pipeline, connected through defined API contracts. An implementing organization could adopt SDH without deploying Rafi or adapt Rafi for a different clinical context without requiring the full SDH infrastructure. RBAC is configurable per deployment—the same instance can serve a secondary school program with 3 user roles or a university-based stepped-care service with 10—without code changes. This modularity is deliberate: no 2 implementation contexts share identical operational requirements, and platform rigidity is a common reason digital health tools fail when transferred across settings [63,64].

Third, the open-source architecture—built on Node.js, PostgreSQL, and React, with RESTful APIs and a phased Fast Healthcare Interoperability Resources compliance roadmap—lowers the barrier to adaptation by other technical teams [63-65]. Offline-first data capture, customizable reporting, and flexible intervention workflows are configurable features rather than hardcoded assumptions [63-65].

To the best of our knowledge, no comparable integrated open-source platform has been developed and deployed for community-based stepped-care mental health delivery in Kenya or comparable East African settings. We make no claim to novelty for the global landscape, where numerous digital mental health platforms exist [30,31,35]. The contribution is contextual: a platform built from the ground up for the operational, cultural, and infrastructural realities of implementation in Kenya and similar low-resource settings.

Extending shamiriOS to nonmental-health domains is a plausible future direction, but currently hypothetical. The modular architecture could, in principle, support other task-shifted, community-based delivery programs, but such extensions would require domain-specific user research and evaluation rather than direct platform transfer.

We believe publishing shamiriOS as open source serves an important purpose: making the architecture and code available for other teams to adapt, critique, and build upon. The precedent set by OpenMRS and DHIS2—adapted across dozens of countries while maintaining core architectural integrity—suggests that platform-level adaptability is achievable when accompanied by community-led localization [65-68]. Implementation toolkits, training modules, and documentation are being developed to lower the barrier for organizations in Kenya and comparable settings, with the explicit expectation that substantial localization will be required.

The SDH was feasible and acceptable across both centralized and decentralized implementation contexts. The transition from fragmented workflows—spreadsheets, manual stipend logs, and WhatsApp-based supervision coordination—to a unified real-time platform was achieved across 5 hubs in Q4 2023, expanding to 11 sites supporting 1195 fellows, 111 supervisors, and over 76,344 students by Q1 2024. A 3.7-fold increase in student reach within a single year, maintained alongside high satisfaction scores, suggests that the platform can scale without deterioration in usability or staff experience. An NPS of 8.63 and a usability rating of 8.36 are consistent with evidence that well-designed operational platforms improve efficiency and oversight capacity in task-shifted delivery systems [30,31,35,56]. Qualitative feedback highlighted 3 valued features: centralized real-time visibility of fellow attendance across sites; automated stipend workflows, which reduced manual verification errors; and Metabase analytics dashboards, which allowed nontechnical supervisors to interrogate program data without developer support. The last is particularly relevant for scale: building analytical self-sufficiency into the platform reduces long-term dependency on the central technical team [30,31,35,56].

Operational feedback from the wave 2 expansion revealed several implementation-relevant patterns. Adoption was strongest at sites where SDH mirrored and enhanced existing workflows rather than replacing them wholesale—consistent with implementation science evidence that technology adoption is smoother when tools augment rather than disrupt established practice [31,64]. Device sharing at some hubs created bottlenecks in timely data entry, temporarily reducing completeness in the first weeks of deployment. Offline-first data capture—introduced in version 3—addressed connectivity constraints but not device access. Future deployments to settings with low device-to-user ratios may need to treat hardware access as a precondition for adoption or consider lighter-weight interfaces optimized for brief interactions on shared devices.

The gap between registration and sustained engagement was striking. High initial registration confirms that broad uptake is achievable through institutional partnerships and peer-led outreach. The subsequent decline—with sustained active use falling well below the 4% at 6 months common in reviews of consumer mental health apps [39,58]—is consistent with the literature but requires careful disaggregation.

Qualitative feedback identified several contributing factors: low perceived ongoing need among students who registered out of curiosity during launch, feature overload from multiple simultaneous engagement pathways, device storage constraints, and notification fatigue. These represent different problems requiring different solutions—notification calibration addresses fatigue but does nothing for users with genuinely low perceived need or stigma concerns [69-71].

More structurally, Rafi was designed around continuous self-monitoring—daily check-ins, journaling, and affirmations—which requires users to perceive ongoing value in routine self-assessment. For a predominantly healthy student population, this model may not fit typical help-seeking patterns, which tend to be episodic and crisis-driven rather than habitual [69-71]. Future iterations should consider whether a shift toward episodic engagement—designed for crisis-prompted access to care rather than daily wellness tracking—would better match actual user needs [39].

The finding that 99.4% of Rafi users who engaged with self-guided tools subsequently booked a therapy appointment—though cross-sectional and not causal—suggests that for students who do engage, the platform functions effectively as a gateway to higher-intensity care [69,71]. This points to a segmented engagement strategy: prioritizing acquisition and early retention for students with active mental health needs, rather than sustained mass engagement across the full student population.

shamiriOS was designed to improve access to youth mental health services, but digital data collection introduces risks requiring explicit acknowledgment. Kenya’s Data Protection Act (2019) provides a legal framework [91], but enforcement capacity is limited, and the gap between legal protection and practical data security in community-based implementations remains significant [92-94].

Current data protection measures include end-to-end HTTPS encryption, data deidentification, RBACs, separation of operational data (SDH) from clinical and personal data (Rafi and SPP), secure cloud hosting with encrypted databases, and Open Authorization 2.0 authentication. Rafi does not collect passive sensor data. Anonymous community feed features allow engagement without linking posts to clinical data.

These measures reduce but do not eliminate risk [92-94]. Future work will strengthen protections through user-controlled data deletion and full data export; transparent disclosure about what data are collected, how they are stored, and scenarios under which they could be accessed by third parties; and, where technically feasible, local device storage options that reduce cloud dependency [92-94]. shamiriOS’s data governance policies will be published openly as part of the open-source repository to enable external scrutiny.

shamiriOS was developed through a user-centered design process [40,41]—not community-led development. End users informed design decisions as consultants and testers; strategic and architectural decisions were made by Shamiri’s technical and clinical leadership. This reflects pragmatic constraints of real-world development and believe that the level of inclusion on feature development, content priorities, and data governance is appropriate for platforms at this stage. Future governance structures should consider greater community ownership [42,45].

Several limitations should inform the interpretation of these findings. The environmental scan was structured but not exhaustive. Proprietary, region-specific, or non-English–language platforms may not have been captured, and the scan assessed market availability and feature coverage rather than clinical efficacy; it should not be read as a systematic review.

We did not use validated implementation science measures for feasibility, acceptability, or usability. Pragmatic industry metrics—NPS, MAU rates, and feature adoption rates—provided actionable feedback for development sprints but lack the reliability and cross-study comparability of instruments such as the System Usability Scale [95], Acceptability of Intervention Measure [53], or Feasibility of Intervention Measure [53]. Future evaluations of the stable platform should use these standardized instruments.

Barriers and facilitators were documented through operational feedback channels—training sessions, helpdesk tickets, monthly check-ins, and NPS qualitative responses—rather than formal implementation research using validated frameworks such as Consolidated Framework for Implementation Research or Exploration, Preparation, Implementation, Sustainment [96,97]. Our understanding of why engagement varied across sites and user groups is therefore incomplete. Future studies must prioritize rigorous implementation science methods.

Deployment results—particularly Rafi’s MKU engagement data—reflect a 9-month observation window. Longitudinal engagement patterns, clinical outcomes, and cost-effectiveness at scale have not been assessed. The 99.4% therapy-booking rate is a cross-sectional observation that cannot establish causality.

Finally, shamiriOS used user-centered design with consultation, not fully participatory or community-led design. Future studies should consider a full participatory approach and investigate the implications of different approaches on cultural grounding, local ownership, and long-term sustainability.

The development and early deployment of shamiriOS demonstrate the feasibility of modular, open-source digital infrastructure for scalable, task-shifted youth mental health service delivery in Kenya. SDH showed strong feasibility and acceptability at scale, with satisfaction scores comparing favorably with digital health benchmarks and a 3.7-fold expansion in reach over a single year. Rafi demonstrated broad initial reach but surfaced important, actionable lessons about the conditions required for sustained engagement—lessons specific enough to have directly informed deployment strategy for future cohorts.

shamiriOS is not a finished product. Its full value will only be realized once all 3 components are deployed, integrated, and rigorously evaluated. The evidence here establishes a foundation: the core infrastructure works, it is valued by its users, and the most significant obstacles to impact lie not in platform design but in implementation readiness, incentive structures, and institutional integration—all of which are addressable.

We envision shamiriOS as an open-source, contextually grounded infrastructure for decentralized mental health service delivery in Kenya, available for adaptation by teams in comparable settings—with adaptation requiring necessary contextual redesign. By publishing both the platform and an account of its early deployment, we aim to contribute not only a technical resource but a set of implementation lessons to the broader community working to close the youth mental health treatment gap in Kenya and beyond.