Digital phenotyping is an innovative health monitoring method that involves collecting and analyzing longitudinal digital trace data to characterize individuals’ behavioral, psychological, and physiological states in real-world contexts [1]. This approach aims to provide a detailed and timely understanding of individual health as it naturally unfolds in everyday life. Smartphones are particularly well-suited for digital phenotyping due to their ubiquity, portability, and rich array of built-in sensors that enable real-time, continuous capture of diverse, high-frequency data streams. Complementary to electronic health records or web browsing histories, smartphone-based traces provide fine-grained insights into individual-specific dynamics across time and space, including mobility patterns, interaction behaviors, and media exposure. Prior studies have shown the predictive potential of these smartphone-based signals; for instance, using physical activity data and insulin injection logs to forecast hypoglycemic events in individuals with diabetes [2,3], and using screen activity to detect early signs of mental health crises [4]. As demonstrated in these studies, smartphone-based digital phenotyping holds significant promise as a foundation for delivering timely, adaptive medical and behavioral interventions that support individuals’ health.

Identifying and tracking the evolution of individuals’ health phenotypes requires sustained collection of continuous, real-time data from multimodal sensors and concurrent analysis of heterogeneous data streams. This poses significant engineering challenges due to the limited processing power, memory, and storage of smartphones [5-7]. These hardware constraints generally preclude the use of large-scale multiple-input or multiple-output models or extensive modality-specific preprocessing that would otherwise support interoperability across diverse data modalities. Consequently, most existing digital phenotyping systems adopt a sequential, cloud-centric processing model, in which data are collected on-device, processed in a linear task order, and periodically offloaded to external servers for retrospective analysis. This “traditional” model—defined here as sequential on-device ingestion with delayed cloud-based processing—constitutes the dominant architectural baseline in widely used open-source mobile sensing platforms, including Beiwe and AWARE, where raw sensor streams are written locally and batch-uploaded for offline feature extraction [8,9]. This sequential, cloud-centric pipeline has two key bottlenecks: a throughput bottleneck, where sequential processing limits data handled per unit time, and overall performance is constrained by the slowest task [10,11], and a bandwidth bottleneck, where data transmission capacity delays off-device processing [12,13]. When mobile resources (ie, CPU and memory) are strained by these bottlenecks, a third constraint, the power wall, emerges, wherein thermal and energy limitations prevent processors from scaling performance [14-16]. Hitting this power wall results in further performance degradation, heightened data loss, and an increased risk of OS app suspension. Ultimately, the constraints persistently threaten to interrupt ongoing data collection and introduce significant blind spots into longitudinal health records. In short, the promise of smartphone-based digital phenotyping and delivery of timely, adaptive medical and behavioral interventions that support individuals’ health cannot be realized if systems continue to rely on the bottleneck-prone sequential, cloud-centric architecture on which the current systems are built. Emerging applications—including just-in-time adaptive interventions, relapse prevention, acute stress detection, and context-aware behavioral coaching—require new architectures that can generate accurate and timely digital phenotypes. It is increasingly critical, for both patient safety and treatment efficacy, that we develop new architectures that are immune to network latency, data loss, and service interruptions.

To address the engineering challenges noted above, mobile systems researchers are increasingly exploring parallel processing [7,17,18] and edge computing architectures [13,19,20]. While these approaches have been successfully applied in domains such as consumer on-device AI, robotics, and social media personalization [21-26], where high data throughput and real-time responsiveness are essential, they have not been integrated into mHealth (mobile health) tools. We propose here how these approaches might be successfully leveraged into a new architecture to support continuous, real-time digital phenotyping and delivery of timely, context-sensitive interventions that better help individuals achieve their health goals.

Parallel processing accelerates task execution by dividing computation into smaller fragments that run simultaneously across multiple processor cores. This kind of processing is particularly effective for tasks that involve heavy computation, have strict time constraints, or can be divided into smaller subtasks. For example, in video recording with real-time filters, one core may handle video capture, while another performs image stabilization, and a third applies color correction or compression. In mHealth, the parallel idea would be to concurrently process physiological signals on one core, behavioral indicators on another, and contextual information on a third, enabling richer multimodal inputs that improve predictive performance for downstream digital phenotyping and health-related event detection.

Implementing parallel processing in mHealth tools requires sophisticated task scheduling. Beyond minimizing total completion time, scheduling must ensure that time-sensitive computations (eg, crisis-detection alerts) take precedence over lower-priority tasks. Developers often rely on the OS-level thread schedulers due to the complexity of custom scheduling and variability in hardware capabilities across devices, including differences in core architectures and memory bandwidth. However, OS-managed scheduling has key limitations: limited developer control over timing and execution order, potential disregard for task priorities or dependencies, and unpredictable delays introduced by system-wide multitasking. Concurrency debugging is also more difficult when execution is dynamically determined by the OS. Health-related priorities may get downgraded by OS-level schedulers.

Manual task scheduling allows explicit control over task priorities, dependencies, and computational load when determining execution order and timing. A manual scheduler can manage queues, allocate resources, and adapt execution based on system load, battery status, task progress, and/or clinical priority. However, it is difficult to implement due to the need for variable execution times, intermodule coordination, and constrained CPU, memory, and battery resources. A common compromise is heuristic scheduling, which approximates near-optimal task ordering for complex workflows. In the hybrid approach, the OS manages low-level thread execution while a higher-level platform scheduler coordinates tasks, prioritizes critical processes, and optimizes resource use. When combined with modular design—where task-specific modules internally track dependencies and computational load—heuristic scheduling can outperform both fully OS-driven and fully manual scheduling in efficiency and reliability. By dividing intensive workloads into subtasks and coordinating their uninterrupted execution through hybrid scheduling, intelligent parallel processing can enable the handling of more complex and fine-grained multimodal data streams, improving information fidelity to support more accurate health event detection.

Edge computing refers to performing data processing, storage, and analysis directly on the device where data are generated, rather than transmitting raw data to centralized servers [13,27]. For example, modern smartphones can perform on-device speech recognition, converting audio to text locally without cloud infrastructure. By keeping computation at the data source, edge computing reduces latency, lowers bandwidth consumption, and minimizes energy costs associated with continuous network communication.

Despite its potential to complement parallel processing and further improve performance, edge computing is often constrained by limited mobile hardware resources. Unlike cloud servers that scale elastically on demand, on-device computation requires careful preallocation of CPU and memory. Overestimation can trigger OS-level interventions such as thermal throttling or application termination. These constraints become more pronounced when synchronizing fragmented data streams generated through parallel processing, which must be merged into a coherent local state for joint analysis. Ensuring efficient synchronization without exceeding CPU or memory limits is significantly more complex than offloading coordination to centralized cloud servers.

Recent advances in mobile systems, however, suggest that architectural strategies enabling more efficient resource allocation might make edge computing more feasible. One approach is software decomposition into micromodules tailored to specific hardware targets [13,28,29]. This modular design is often paired with a reactive resource manager that monitors system telemetry—thermal state, battery level, and available memory—and dynamically adjusts execution. For instance, if a device approaches thermal limits, the manager may reduce parallelism or defer tasks to a single-threaded queue to prevent throttling [30-32]. Replacing centralized on-device storage with a logically distributed storage layer further improves efficiency by enabling modules to share processed outputs directly [33,34]. In-memory caching is central to this design: intermediate results are stored in RAM rather than disk, enabling reuse without redundant computation. By minimizing data movement between storage and processing units, in-memory caching reduces latency, alleviates bandwidth bottlenecks, and lowers energy consumption during continuous multimodule execution. Coupling edge computing with a reactive resource manager, therefore, can enable continuous on-device, parallel processing of rich multimodal data under constrained resources, advancing mHealth toward always-on and low-latency digital phenotyping and intervention delivery.

Together, with careful implementation, mobile apps that require both high computational throughput and real-time responsiveness can benefit substantially from combining parallel processing and edge computing within a modular architecture. In such systems, task-specific modules manage their own CPU, memory, and storage demands, while a reactive resource manager dynamically balances system load based on battery, thermal, and memory conditions and informs modules’ scheduling decisions. Strategies such as asynchronous task pipelines, distributed storage across modules, and data caching reduce throughput and bandwidth bottlenecks that would otherwise arise from sequential cloud processing. By integrating careful task scheduling with local computation and adaptive resource management, these architectures can exploit the speed advantages of parallelism while minimizing energy costs and addressing the power wall limitations. In turn, systems with these architectures can handle heavier data loads with improved energy efficiency, greater data fidelity, and more stable operation over extended periods [5,20,35-37]. The gains in efficiency and reliability of real-time processing should, in principle, enable faster phenotype detection and timelier adaptive mHealth interventions, which are critical for real-world deployment.

There has been some effort in mobile digital phenotyping to improve efficiency within existing system constraints via task-level optimizations such as adaptive sensor sampling, energy-aware scheduling, and simplified analytical models [1,38]. While these approaches mitigate some performance limitations, they cannot fully overcome fundamental throughput and memory constraints inherent in high-frequency multimodal data collection on resource-constrained smartphones. Here, we propose, implement, and evaluate a new software architecture that integrates parallel processing with edge computing to enable real-time mobile digital phenotyping through modular systems design. As these system-level advances were not integrated into the currently used mHealth frameworks, the conventional smartphone data processing architecture used in most digital health apps requires a fundamental redesign. We thus establish the Stanford Screenomics platform as the first software reference architecture designed to support clinically responsive, real-time mobile digital phenotyping.

The key novelty lies in the architectural integration of parallel processing and edge computing through modular decomposition, in which each module processes a given data source independently and in parallel, supported by distributed storage and in-memory caching to enable localized on-device computation. A reactive resource manager dynamically schedules asynchronous task pipelines across modules based on device conditions, while a custom multimodal data fusion pipeline performs early-phase data standardization, transforming heterogeneous inputs through modality-specific preprocessing into a unified format for cross-module compatibility. Figure 1 illustrates the structural shift from traditional sequential, cloud-based models to the Stanford Screenomics platform reference architecture, specifically highlighting the embedded data processing layers and the dual engines driving automated care: the phenotype engine and the intervention engine.

While traditional architectures have successfully enabled retrospective digital phenotyping via delayed cloud-based analytics—such as predicting schizophrenia relapse or estimating addiction cravings—their sequential pipelines introduce substantial latencies ranging from minutes to days [39,40]. The primary aim of this study is to formally describe and evaluate the proposed parallel, on-device architecture relative to a traditional sequential, cloud-based phenotyping system that defines the field’s current data-ingestion status quo. We hypothesize that shifting computation to the edge and enabling modular parallel execution would significantly improve system efficiency and performance, demonstrating its potential to enable a robust, scalable, and real-time digital phenotyping to safely support automated clinical interventions in the wild.

To evaluate real-time mobile digital phenotyping performance, we developed and compared two system prototypes: the Stanford Screenomics platform system architecture and a traditional system architecture representing the prevailing sequential, cloud-based processing model (Figure 1). The Stanford Screenomics platform is a modular, edge-centric architecture consisting of a data collection layer using a unified fusion standard, a distributed data management layer leveraging distributed storage, a phenotype engine, and an intervention engine. Parallel processing, asynchronous task scheduling, and in-memory caching enable localized, real-time phenotype generation while dynamically balancing computational load. In contrast, the traditional system architecture uses a sequential processing pipeline in which raw data streams are written to local storage and periodically batch-uploaded to a centralized server for retrospective feature extraction. Detailed technical specifications for both architectures are provided in Multimedia Appendix 1.

We conducted two 48-hour real-time health monitoring experiments, using the two system prototypes and architectures, to evaluate system performance across four system-level benchmarks: resource usage, energy efficiency, data fidelity, and processing speed. Resource usage was measured using continuous CPU and RAM consumption, energy efficiency by battery consumption, data fidelity by the completeness and integrity of collected data streams, and processing speed by throughput and execution latency. These benchmarks determine the feasibility of sustained real-time digital phenotyping on resource-constrained mobile devices. To support real-time health interventions, a mobile platform must optimize these metrics to sustain stable, continuous background monitoring while simultaneously delivering rapid and adaptive responsiveness, required for real-time health interventions, thereby preventing clinical blind spots and intervention decay [8,38]. By evaluating both architectures across these dimensions under varying data-load conditions, we isolated the impact of architectural design choices on the technical viability of real-time mobile digital phenotyping.

To evaluate performance differences between architectural designs, we implemented both the Stanford Screenomics platform architecture—a distributed, parallel in-memory processing pipeline—and the traditional architecture—a centralized, cloud-dependent sequential pipeline. Each of these Android apps was developed in Android Studio and integrated with Firebase (Google LLC) services—including Firestore, Cloud Functions, and Cloud Storage—for backend data management and remote computation. The apps were installed on physical Samsung Galaxy S21 devices (model SM-G991B), equipped with an Exynos 2100 Octa-core processor (1×2.9 GHz Cortex-X1, 3×2.8 GHz Cortex-A78, 4×2.2 GHz Cortex-A55), 8 GB RAM, and running Android 14. Each app operated continuously and silently in the background, collecting five data streams: ambient audio, screenshots, GPS, accelerometer, and gyroscope.

In the Stanford Screenomics platform architecture, each sensor modality was handled by an independent module responsible for local preprocessing and standardization. Collected data were cleaned, deduplicated, compressed, and analyzed for secondary information extraction, then encoded in a uniform timestamped numeric format. Ambient audio was processed to compute minute-level mean decibel values using Android’s AudioRecord API with custom Java/Kotlin signal processing. Screenshots underwent optical character recognition via Google ML Kit’s Text Recognition API, followed by sentiment analysis using an on-device TensorFlow Lite model fine-tuned for sentiment classification (scored 1‐10, the higher indicating more positive sentiment). GPS coordinates triggered real-time weather retrieval through the OpenWeatherMap API, integrated using Retrofit. Motion sensor data (accelerometer and gyroscope) were converted to step counts using Android’s SensorManager API and local step detection algorithms. Real-time phenotyping analysis was performed every 30 minutes. Specifically, the most recent 30 minutes of derived data were held in memory and analyzed using a simple random forest model, implemented via TensorFlow Lite, to identify the single strongest predictor among sentiment, noise, and weather for forecasting physical activity levels (step counts). Cleaned and deduplicated raw media files (audio and screenshots) were compressed with Android’s MediaCodec API and image compression, reduced to ≈10% of original size, and uploaded in batches to Firebase Cloud Storage (for media files such as audio and screenshots) and Firebase Realtime Database (eg, for structured text data such as GPS coordinates and sensor logs). On-device phenotype analysis results were immediately passed to the intervention controller when a newly generated phenotype analysis result differed from the prior one, updating intervention decisions.

By contrast, the traditional architecture used a centralized data collection approach, in which a single node continuously collected raw sensor data without any local preprocessing or secondary information extraction. All collected data were sequentially stored in a single storage, then transmitted to Firebase Cloud Storage (media) and Firebase Realtime Database (text data). Every hour, the most recent 30 minutes of stored data were retrieved from Firebase and processed in a cloud-based computation stage (analogous to cloud 2 in the traditional system architecture), which performs data cleaning, deduplication, and standardization. Secondary information was then extracted within this processing using the same methods as the Stanford Screenomics platform architecture: screenshots were processed using Google ML Kit’s Text Recognition API for optical character recognition, followed by sentiment scoring using a fine-tuned TensorFlow Lite model; audio was processed to compute mean decibel levels via cloud-executed Java signal processing routines; weather scores were retrospectively retrieved by querying the OpenWeatherMap API via HTTP requests for conditions nearest to each GPS timestamp and location coordinate (functionally equivalent to Retrofit calls on Android); and accelerometer and gyroscope data were converted into step counts using reimplemented versions of the Android SensorManager API logic and step detection algorithms, executed in cloud functions. Once all data streams were standardized, phenotype analysis was conducted in the same cloud-based computation stage (cloud 2) using the same random forest model deployed in the Stanford Screenomics platform architecture, identifying the strongest predictor—among sentiment, noise, and weather—of physical activity levels as measured by step counts. In this architecture, the intervention controller was implemented as a separate cloud function (conceptually analogous to cloud 3), which receives phenotype analysis outputs from the computation stage and updates intervention decisions.

Two controlled experiments were conducted to assess the effects of system architecture (traditional vs Stanford Screenomics platform) and varying data load conditions over time on app performance. Both systems were implemented as complete, self-contained applications so that the experiments could evaluate the performance of the architectures holistically (rather than evaluating the various components of each architecture in isolation). Each app was run for 48 hours at four distinct data collection load profiles that differed in the frequency and size of collected sensor data streams—very heavy (≈60 MB/min), heavy (≈40 MB/min), medium (≈30 MB/min), and low (≈10 MB/min). These four load profiles were invoked by using different sampling rates: for very heavy load, one 10-second audio recording was captured per minute alongside sensor data collected every 3 seconds; heavy load involved 7.5-second audio and 5-second intervals for other sensors; medium load used 5-second audio and 8-second sensor intervals; and low load collected 2.5-second audio and 10-second sensor intervals. These load profiles were selected to reflect real-world trade-offs between resolution and processing constraints. In the first experiment, systems ran completely offline to stress-test local device performance, with continuous monitoring of CPU and RAM usage, battery drainage, and data loss events. In the second experiment, the same load conditions were applied over a stable, uninterrupted high-speed Wi-Fi connection to evaluate end-to-end processing latency, with timestamps recorded at key stages of data handling. Data from both experiments are displayed visually and analyzed statistically.

Experiment 1 was designed to directly compare the two architectures in terms of resource efficiency and data completeness under varying load conditions. In this experiment, both systems ran completely offline—without any network connectivity—to stress-test local device performance. Virtual users followed a scripted loop of six everyday smartphone activities, switching tasks every 5 minutes in the following fixed sequence: watching a movie on YouTube, reading eBooks, browsing TikTok, web surfing, listening to Spotify, and scrolling Instagram Reels. Devices were tethered to desktop USB ports supplying 2.5‐5 W power, sufficient to sustain uninterrupted operation while still permitting observable battery depletion. System behavior was continuously monitored under these conditions, with minute-by-minute logging of CPU usage, RAM usage, battery level, and data loss events. Data loss was defined as any failure to capture or store new data due to system overload—caused by excessive CPU usage, RAM usage, or insufficient storage—or failure in secondary data retrieval (eg, null or invalid return values from services).

Experiment 2 repeated these conditions over a 250 Mbps Wi-Fi connection, representative of average US network speeds, to evaluate end-to-end processing latency across both systems. For the Screenomics platform system architecture, five event-based timestamps were recorded per 30-minute processing instance (“trial”): completion of parallel local write operations across all modules; completion of on-device preprocessing and secondary data extraction; parsing and loading of standardized data into memory; completion of phenotype analysis; and delivery of results to the intervention controller. Similarly, for the traditional system architecture, five event-based timestamps were recorded per trial: completion of centralized local write, completion of raw data upload and retrieval of the 30-minute data segment on the cloud for processing, completion of cloud-based preprocessing and secondary data extraction, completion of phenotype analysis, and delivery of results to the cloud-based intervention controller. Although data collection and processing occurred concurrently in both systems, processing timestamps were captured at the completion of each major stage for each 30-minute data window. These timestamps served as logical boundaries, reflecting real-world execution timing where steps are not strictly sequential or isolated.

For experiment 1, CPU (%) and RAM usage (MB), battery drainage rate (%/h), and data loss (%) were summarized descriptively across the four load conditions for both the Stanford Screenomics platform and traditional system architectures. The minute-by-minute measurements (2880 observations per load condition) were used to compute means, SDs, and ranges. Differences between architectures were assessed for each load condition using two-sample t tests (P<.05). CPU and RAM trends were visualized with density plots to assess stability and consistency, where wider distributions indicate greater variability. Data loss was quantified as the proportion of expected sensor data not captured or stored during each one-minute interval, with cumulative trajectories plotted over the 48-hour experiment. Exponential growth rates were calculated to quantify the rate of data loss under each condition.

For experiment 2, the hierarchical structure of the data, with repeated trials—each representing a processing instance initiated every 30 minutes using a 30-minute data segment, during which multiple key-stage timestamps were recorded—nested within each combination of architecture and load condition; differences in total processing time were analyzed using a linear mixed-effects model. As sustained processing can lead to memory accumulation and thermal-induced CPU throttling, later trials were expected to exhibit progressively longer processing times. Accordingly, architecture (Stanford Screenomics platform and the traditional) and load condition (very heavy, heavy, medium, and low) were included as fixed effects, and trial index (ie, sequential processing cycle initiation number) as a covariate to capture temporal effects. This model allowed us to quantify the effects of architecture and load while controlling for systematic variation across sequential trials.

This study did not involve human participants or identifiable personal data. All experiments consisted of technical evaluations on mobile software and performance metrics derived from scripted simulations. Accordingly, the Stanford University Institutional Review Board confirmed that formal ethical approval was not required for this research.

Digital phenotyping is increasingly being used to support health monitoring, clinical assessment, risk detection, and adaptive intervention delivery. To date, much of this progress has been enabled by traditional cloud-centric architectures that support large-scale longitudinal monitoring, retrospective behavioral analysis, population-level risk stratification, and the development of many foundational digital phenotypes. These systems remain well suited for applications in which phenotype generation can occur over extended time horizons, such as epidemiologic research and treatment survival surveillance. However, as digital health tools transition from small proof-of-concept studies to large-scale, long-term clinical deployments, the ability to generate accurate and timely digital phenotypes becomes increasingly critical for patient safety and treatment efficacy. Emerging applications—including just-in-time adaptive interventions, relapse prevention, acute stress detection, and context-aware behavioral coaching—require phenotype updates that closely reflect an individual’s current state. Existing architectures commonly rely on sequential, cloud-dependent processing workflows that are vulnerable to network latency, data loss, and service interruptions, which can compromise the timeliness and completeness of digital phenotype generation. To address these challenges, we developed, implemented, and evaluated the Stanford Screenomics platform architecture, a modular framework combining parallel processing, early-stage multimodal data standardization, and edge (on-device) computation. Experimental results demonstrated substantially improved computational efficacy, reliability, and responsiveness relative to the traditional sequential, cloud-based architecture being used in current systems. By supporting real-time phenotype generation while maintaining longitudinal analytic capabilities, the Stanford Screenomics platform has the potential to extend the utility of digital phenotyping beyond retrospective monitoring and improve both the scalability and clinical viability of smartphone-based digital phenotyping.

The Stanford Screenomics platform architecture advances mobile digital phenotyping by eliminating data transmission delays, making real-time phenotyping feasible on standard consumer smartphones. The core innovation lies in a tightly integrated two-layer architecture—comprising a data collection layer and a data management layer—designed to operate in tandem for low-latency, clinically actionable analysis. While traditional systems defer transformation until after raw data are uploaded to the cloud, our data collection layer implements an early-phase standardization framework that resolves data heterogeneity directly at the source. Although the concept of metadata-guided early-phase standardization has been suggested previously, prior mHealth systems were unable to realize it effectively due to technical and practical challenges [41-44]: early smartphones lacked the capability to process multiple real-time data streams [13,45], and building robust standardization frameworks required substantial technical infrastructure and development resources [46,47]. Furthermore, clinical risk aversion and established workflows historically favored centralized, postcollection cloud processing, resulting in widespread reliance on simpler but less responsive methods [48-50]. Traditional systems have thus introduced significant delays, particularly under heavy data loads. Delays of even a few minutes can result in phenotype estimates that no longer reflect a patient’s current behavioral or medical state. Now, leveraging advances in smartphone technology and the associated software development tools, the Stanford Screenomics platform architecture opens the possibility to resolve heterogeneity at the source, obtain standardized outputs in real time, and eliminate the need for downstream parsing and formatting, thereby reducing computational complexity and speeding up phenotyping.

In this new architecture, the data management layer leverages edge computation to facilitate real-time phenotype analysis without the overhead of disk I/O and network delays. Incoming data streams are continuously evaluated in memory to identify complex, context-specific individual-level phenotypic traits, such as prolonged sedentary behavior when a patient is alone during adverse weather. The intervention controller then consumes these dynamic phenotype outputs to generate continuous, moment-by-moment intervention decisions tailored to the individual’s current state. This localized computation further enhances energy efficiency and fault tolerance by isolating processing to temporary data segments [13,19,20]. Together, early-phase standardization and in-memory processing form a scalable, resilient pipeline optimized for real-world phenotyping on mobile devices. In our experiment 1, the Stanford Screenomics platform architecture consistently achieved 34- to 57-fold faster end-to-end processing than a traditional cloud-based architecture, maintaining total processing times from data acquisition to phenotype update below 10 seconds across all data load conditions. These findings affirm that reducing cloud dependency—by shifting transformation and analysis to the device—is a critical design principle that supports high-performance, real-time phenotyping on smartphones, with potential applications for proactive adaptive interventions, real-time alerts, and interactive individual monitoring.

Another critical strength of the Stanford Screenomics platform architecture is its modular design with distributed file storage, which together enable parallel data collection and processing throughout the entire pipeline. By allowing each data node to operate independently, the system avoids the storage contention and blocking common to the centralized, sequential writes found in traditional designs [51]. The modularity enhances throughput, prevents delays caused by sequential data handling, and allows for efficient resource management and reliable data handling on consumer devices, particularly under heavy data loads [7,17,18]. The results from experiment 1 validate the operational reliability of this approach: the Stanford Screenomics platform architecture maintained uninterrupted data capture for 48 hours across all data load levels, while the traditional architecture failed between 44 and 9 hours in medium to very heavy load conditions. These accumulated failures followed exponential data loss trajectories alongside rising device CPU and memory usage, leading to severe performance instability under high data loads. This contrast underscores the clinical risk of traditional architectures under stress, whereas our modular, memory-aware design mitigated cascading degradation. Narrow statistical variances (IQRs) in processing times further demonstrate our system’s stability and consistency, whereas the traditional system’s unpredictable performance could lead to critical gaps in patient monitoring. This level of technical reliability is especially crucial for real-world clinical deployments where patient internet connectivity is often limited, unstable, or intermittent. When a stable network is available, data are regularly uploaded and deleted from the device to free storage space. However, during offline periods, data accumulate locally and cannot be offloaded, increasing vulnerability to storage and processing failures. Any local capture failure under these conditions leads to permanent, unrecoverable data loss. Therefore, the ability to securely store and process data entirely on-device—without relying on network availability—is essential for supporting continuous phenotyping, long-term monitoring, and timely interventions.

Although the experiments benchmarked the Stanford Screenomics platform architecture against a traditional architecture under controlled conditions, several limitations warrant consideration. This study relied on scripted virtual users (5 min per task) and fixed device and network configurations. This experimental setup enabled precise measurement but does not fully capture real-world variability, such as highly idiosyncratic individuals’ multitasking and app switching behaviors, smartphone models, OS versions, memory capacities, background processes, or battery health. Experiments were limited to 48 hours, which was sufficient for evaluating short-term device burden and revealing key architectural differences. Longer-term deployments could reveal cumulative effects on memory management, thermal performance, battery longevity, and overall system stability—effects we expect to be even more favorable for the Stanford Screenomics platform architecture, as its dynamic task scheduler increasingly optimizes performance over time. Network conditions were idealized with stable, high-speed Wi-Fi; in real-world scenarios, individuals frequently encounter cellular dead zones or intermittent connectivity, which may introduce latency, data loss, or integrity issues that disrupt continuous care [52,53]. The current study focused on a limited set of data streams with fixed sampling rates, whereas nonfixed sampling—such as event-based, random, or context-triggered data, including user-smartphone interactions or physiological signals—could impose unpredictable demands on device processing [54,55]. The outcome metrics focused primarily on system-level performance (CPU/RAM usage, battery drain, and storage use); however, operational outcomes directly affecting individual experience—such as app responsiveness, intervention timing, and the downstream impact of partial or corrupted data on phenotype accuracy—were not assessed. Data loss measured at discrete points may underestimate the cascading consequences on real-time processing or the timely delivery of critical health interventions. Importantly, this study evaluated the computational architecture underlying digital phenotyping rather than the validity or clinical utility of the resulting phenotypes. Future work should examine whether these architectural improvements translate into more accurate and robust phenotype generation and improved downstream clinical outcomes in real-world deployments. In sum, future studies should extend evaluations to longer-term real-world deployments across diverse devices, OSs, and network conditions, incorporate additional high-bandwidth or continuous streams, and assess operational outcomes to better understand practical performance and guide the development of adaptive strategies for reliable, scalable digital phenotyping.

We also note some critical operational considerations surrounding the deployment of parallel processing and edge computing in mHealth systems. Parallel modules improve throughput but can introduce latency and reduce real-time responsiveness when threads wait for shared resources or for other modules to complete their processing window [56,57]. This issue is common in mobile parallel computing, particularly with high-frequency or high-volume data streams. The Stanford Screenomics platform mitigated most locking and buffering problems by isolating preprocessing within each module, sending only small, standardized outputs to shared memory, and performing lightweight in-memory fusion, minimizing thread contention and OS-induced delays. While these hardware limitations cannot be entirely eliminated, careful pipeline design—such as module-level preprocessing, data conversion or compression, and in-memory analysis—can make their impact negligible. Another consideration is diminishing returns, as described by Amdahl’s law, where overall system speedup is limited by the portions of the code that cannot be parallelized [58]. In our platform, this limitation was not observed because the data pipeline was highly parallelizable across all stages—data collection, preprocessing, storage, and memory load—with each sensor processed independently. Potential bottlenecks, such as writing aggregated data to storage, were largely avoided through distributed module-level storage. By contrast, even a highly parallelized system that relies on centralized storage, as in traditional sequential architectures, can experience contention, limiting overall throughput [59-61]. Developers of mHealth systems should therefore maximize parallelism across all stages, identifying and optimizing nonparallelizable components (such as steps requiring synchronized multisensor streams during multimodal feature extraction) and exploiting often-overlooked opportunities such as preprocessing, distributed storage, and memory load [62-64]. In such cases, best practices include incremental or rolling computation, asynchronous buffering, prioritizing lightweight operations for time-sensitive tasks, decoupling pipelines to isolate sequential fusion steps, and optimizing nonparallelizable algorithms to minimize latency. The shared Stanford Screenomics platform’s reference architecture codebase implements these strategies, with structured cross-references throughout to help digital health researchers trace how each best practice is realized.

Edge computing enables real-time, on-device analytics for mobile digital phenotyping but comes with trade-offs [25,65]. High-complexity algorithms—such as deep neural networks for psychiatric risk prediction, temporal sequence models, or advanced multimodal fusion—can easily exceed standard smartphone capacity, particularly when multiple high-frequency streams are active simultaneously. Long monitoring windows or large-scale temporal modeling can increase device processing demands. Mobile sensor streams are notoriously prone to data missingness, noise, and misalignment, which can distort clinical feature extraction and reduce diagnostic accuracy if not handled robustly. Real-time, in-memory analyses often permit only incremental updates rather than full model retraining or comprehensive statistical evaluation, limiting interpretability and the detection of subtle or long-term trends, which requires careful balancing between temporal fidelity, model complexity, and available device resources. To mitigate these constraints without compromising clinical utility, several optimization strategies can be implemented: lightweight, incremental, or rolling-window feature extraction reduces memory footprint while preserving temporal fidelity; simplified or approximate fusion methods prioritize critical modalities without overtaxing the device; robust preprocessing, interpolation, and confidence thresholds handle noisy or incomplete streams; and adaptive scheduling or offloading of noncritical tasks during idle periods balances computational load [66,67]. As a recommended strategy for future implementations, investigators could use a hybrid approach: lightweight proxy models run continuously on-device to process critical streams and trigger immediate, time-sensitive interventions, while heavier, more complex models run intermittently on buffered data to update the proxy’s parameters and maintain predictive alignment. Cloud processing can further support large-scale, longitudinal, or multiparticipant population-level analyses that exceed on-device capacity, enabling more complex epidemiologic modeling, long-term trend detection, and cross-user insights. In the Stanford Screenomics platform, portions of preprocessed data are temporarily loaded into memory and discarded afterward to reduce memory pressure and support continuous responsiveness, and standardized module outputs produce small, uniform representations that simplify computation, minimize thread contention, and facilitate multimodal fusion. Future systems could extend efficiency through dynamic buffer resizing, prioritized caching, shared memory pooling, lightweight streaming compression, and memory-aware sampling, while checkpointing with rollback, incremental cleanup, and adaptive model selection can ensure memory usage remains bounded under variable workloads. By combining these strategies, investigators can preserve real-time responsiveness, leverage advanced diagnostic models, and maintain device performance within safe limits, enabling adaptive, on-device digital phenotyping without overloading the device or relying on cloud computation.

The Stanford Screenomics platform architecture resolves the chronic latency and reliability issues of traditional sequential, cloud-based digital phenotyping by adopting a modular architecture design that successfully integrates parallel processing with edge computing. By synergizing resource monitoring, adaptive task scheduling, metadata-guided multimodal data fusion, distributed storage, and in-memory caching, this framework shifts high-intensity computation directly to the mobile device, maintaining high data fidelity even during network outages. This study contributes the field’s first validated software reference architecture for smartphone-based real-time digital phenotyping, providing a standardized blueprint that overcomes the fundamental engineering hurdle of resource management on constrained hardware. By releasing the validated prototype architecture as an open-source reference, this work allows digital health researchers and clinical trialists to bypass the steep engineering barriers of data synchronization and system instability. Instead, investigators can focus their resources on high-level phenotype discovery and validation. Ultimately, this platform establishes a highly resilient, scalable foundation to support the next generation of reliable, context-aware digital health interventions deployed directly on patients’ mobile devices.