## 1 Introduction  
Smartwatches that integrate sensors for measuring heart rate (HR) and activity are available in the commercial marketplace from multiple vendors. Originally used for fitness and activity tracking, these devices now find applications in monitoring the health and well-being of individuals and groups [1, 2]. These wearable, minimally invasive devices provide an alternative pathway to clinical diagnostics that can be operated continuously in near real time [3]. For example, recent studies have demonstrated that the wearables can detect viral respiratory infections, such as influenza or COVID-19, before symptoms manifest themselves [4, 5, 6, 7]. Other studies have shown the potential of wearables for detecting atrial fibrillation and sleep apnea [8, 9]. Smartwatches have also been considered for monitoring the real-time performance status of military personnel and first responders [10, 11, 12]. In studies of wearables, signals recorded by smartwatch-integrated sensors were typically collected by a mobile application (app) provided by the original equipment manufacturer (OEM), which users install on their smartphones (Figure 1). After the smartphone and the watch are paired, the mobile app collects the signals. The data stream is typically transmitted to an OEM-operated cloud server that utilizes proprietary algorithms for further processing [13]. Examples of metrics that are extracted from sensor signals include step counts, HR, respiration rate, stress, and sleep quality [14]. The metrics, their changesover time, and various statistical measures can then be accessed through the mobile app, giving device users the ability to track their physical activity and vital signs. Third-party developers can access this health information for a group of individuals (e.g., a study cohort) once granted permission using an application programming interface (API). Although the OEM-provided cloud services are essential for the broad use of smartwatches, wearables systems based on OEM-provided cloud services have limitations. For example, real-time health monitoring in remote locations and other resource-constrained environments may be hampered by intermittent Internet connection, which limits communication to the vendor cloud where more advanced health metrics (e.g., readiness) are calculated [11]. While some smartwatches can process and display health data on the watch, baselines of 7+ days are often needed to compute more complex health indicators such as heart rate variability (HRV) anomalies, and these are only available on higher-end devices. These requirements limit the ability to rapidly deploy monitoring systems for military personnel and first responders in tactical operations or emergency situations in which insight into an individual's current health status is critical. Modifications to the current OEM data collection and analysis paradigm are also needed in sensitive situations in which data can only be stored and processed on approved enterprise servers and cannot leave the controlled network [10; 15]. For example, only selected cloud-based solutions are approved for housing the controlled unclassified information (CUI) generated from wearables worn by military, homeland security, and in some cases, first responder personnel. In addition to the use cases focused on military and first responder personnel, researchers also need higher-resolution data and more insight into the calculations being performed than is traditionally made available through OEM services. Vendor-provided metrics are heavily processed (e.g., averaged over minutes or hours), and data access is traditionally limited to daily summary and windowed information (which can vary in reporting frequency from 15 s to 15 min depending upon the vendor and metric). Algorithm calculations are vendor proprietary and not transparent for interpretation by the end user. For example, sleep metrics (e.g., sleep quality, sleep duration) can vary widely between smartwatch models and compared to gold-standard polysomnography [16].