Toward Sustainable Healthcare AI Infrastructure: A Lifecycle-Aware Federated Mobile Crowd Learning Framework

Abstract

Healthcare AI is becoming continuous rather than episodic, and the carbon and e-waste costs of this shift are rarely priced into architectural decisions. Federated learning (FL) keeps sensitive data local but can increase infrastructure demand. We formulate Federated Mobile Crowd Learning (FMCL), a reuse-centric alternative to dedicated edge deployment in which federated training runs preferentially on already-deployed consumer devices. A lifecycle carbon-accounting model compares centralized cloud training (which moves raw data off-site), dedicated edge FL, and FMCL under marginal, calendar-time, and shared-infrastructure allocation of embodied carbon. FMCL has a lower modeled footprint than dedicated edge under all three conventions and in 93.9% of 20,000 sampled scenarios over eight uncertain parameters; against cloud training, it leads only under marginal allocation, and device wear alone can reverse that comparison. Against pre-existing edge capacity, FMCL has a lower modeled footprint in 16.9% of sampled scenarios. A preliminary experiment on MIT-BIH arrhythmia classification compared convergence under energy-aware and random client selection, without comparing architectures; the policies did not differ detectably in rounds to a fixed balanced-accuracy target, and both met it while recognizing only two of the five classes. Applied to eight healthcare deployment contexts, the analysis identifies where FMCL reduces the infrastructure burden and where a dedicated alternative is preferable. Deployment measurements of wear, availability, communication energy, and convergence are still required.

1. Introduction

Clinical care is shifting from periodic encounters toward continuous monitoring. Wearables can support continuous rhythm monitoring, remote monitoring can extend care into the home, and deterioration models can process high-frequency intensive care unit (ICU) data. Artificial intelligence increasingly underpins these services, which also require computing, communication, storage, and supporting infrastructure. The computation required to deliver AI-assisted care carries carbon, resource, and e-waste costs that are rarely incorporated into clinical infrastructure planning [1,2].

1.1. The Environmental Cost of Healthcare AI

Clinical AI is already delivering documented advances: diagnostic imaging models approaching specialist sensitivity [3], sepsis-prediction and clinical decision-support systems [4], wearable arrhythmia classifiers [5], and clinical natural language processing (NLP) for documentation and triage [6,7]. Training a large transformer can emit carbon comparable to several transatlantic flights, with orders-of-magnitude variation depending on hardware and grid mix [8,9,10,11]. Less discussed is that inference, not training, dominates operational energy in most production systems [11]. In healthcare, where models query continuous physiological streams, that inference load is standing rather than one-time.

Embodied carbon adds to this burden: manufacturing, not operation, can account for more than half the lifecycle footprint of data center hardware, and this share grows under low utilization or frequent replacement [12]. Embodied carbon, however, is rarely captured in AI system evaluations that emphasize accuracy, latency, and throughput.

Several healthcare AI workloads, particularly medical imaging, multimodal modeling, and large-scale clinical language models, are among the most computationally demanding. Deployment is moving toward the bedside, the home, and wearable devices, where centralized infrastructure may be less efficient or less practical.

1.2. Architectural Evolution Toward Distributed Learning

Early clinical AI was centralized: institutional data was aggregated and shipped to cloud or on-premises infrastructure for training and inference. This approach was tractable and supported early validated clinical AI systems. But it concentrated compliance exposure and breach risk, often in direct tension with the data-governance frameworks that health systems were simultaneously strengthening. A first wave of distribution then moved inference to the edge while keeping training centralized [13]: lightweight models run locally without transmitting patient data per query. This reduced exposure at inference time but left training-time data pooling intact. It also multiplied infrastructure, since every deployed endpoint needs its own hardware, cooling, and maintenance.

A second, still-unfolding wave distributes training itself: federated learning (FL) [14] refines model parameters locally at each node and shares only gradient updates, not raw data, with an aggregating server. This reduces the need to transmit raw training data, although model updates can still leak information and require additional privacy protections. Institutions with heterogeneous governance and patient populations can collaborate without pooling data or enforcing standardization. FL has shown clinical viability, from multi-institutional brain tumor segmentation approaching centrally trained performance [15] to COVID-19 outcome prediction across distributed hospitals [16]. Deployment frameworks such as NVIDIA FLARE [17] and Intel OpenFL [18] have moved it toward production. Evaluation, however, remains narrow: convergence, communication cost, and privacy dominate, and sustainability is largely absent. For healthcare, this gap matters because distributed AI deployments involve clinical infrastructure, patient devices, and regulated data. Federated training may increase infrastructure demand when dedicated edge hardware is installed at each participating site. This can shift environmental burdens from data transfer to distributed infrastructure.

A third wave extends FL to devices that were never purposely built as computing infrastructure: smartphones, tablets, and wearables that patients and clinicians already carry [19]. However, deployment at scale in clinical practice remains limited. A smartwatch already measuring cardiac activity is also a processor with memory and a radio. It can train on that data locally and contribute to a shared model without new hardware being manufactured, shipped, or cooled. This reuse-centric model [20] changes the design question from how to power new infrastructure more efficiently to whether new infrastructure is needed at all.

1.3. The Missing Sustainability Lens in Federated Learning

FL has expanded rapidly from a data-minimization mechanism [14] into a broad design space of algorithmic variants, system architectures, and domain adaptations [21,22,23,24]. That expansion has been uneven: some dimensions are explored extensively, but sustainability is not. Evaluation typically focuses on predictive performance, convergence, communication cost, and privacy; hardware is treated as a fixed input. Whether to deploy dedicated edge infrastructure or reuse existing devices is rarely formalized as a choice with consequences. This follows from FL’s origins: it was motivated by privacy and communication constraints, and its metrics were built accordingly [14]. That framing is incomplete once systems move into operational environments, where they incur measurable environmental costs, where the presumed sustainability advantage of distributed learning does not hold under every configuration.

Communication illustrates the gap directly: cellular transmission costs substantially more energy per bit than Wi-Fi [25], yet communication-efficient FL is optimized for data volume, not energy [26]. Local training cost is likewise treated as uniform; however, on dedicated edge hardware, it depends on idle power and utilization [27]. On consumer devices, it depends on device state: computation scheduled during charging adds little marginal energy, while computation competing with active use adds more [28].

Embodied carbon is even less visible: hardware deployed specifically for FL carries a manufacturing footprint that must be amortized over its operational life, whereas consumer devices already bear that cost, and their participation does not add a manufacturing burden, provided it does not shorten device longevity [29]. Work in mobile crowd computing has examined device-level energy in terms of battery life and user experience [30,31]. System-level environmental accounting across marginal energy, embodied carbon, and lifecycle effects remains limited.

The appropriate architecture depends on the lifecycle boundary, workload, utilization, communication conditions, and clinical constraints. A lifecycle framework is needed to compare these trade-offs under common functional and accounting boundaries.

FMCL is not tied to a particular country or electricity grid, but its environmental performance depends on the local device mix, electricity carbon intensity, connectivity, and governance conditions. The quantitative analysis uses a geography-neutral reference scenario with generic device, server, and grid-intensity inputs.

The analysis addresses three questions: (i) under what conditions FMCL has a lifecycle-carbon advantage over dedicated-edge and cloud architectures, and how sensitive that advantage is to uncertain parameters; (ii) how the embodied-carbon allocation convention (marginal, calendar-time, or shared-infrastructure) affects the comparison; and (iii) how participant selection, device heterogeneity, connectivity, and reliability affect the practical applicability of FMCL.

1.4. Paper Contributions and Scope

This study derives lifecycle-carbon conditions under which reuse-centric distributed training may have an advantage over cloud and dedicated-edge architectures. It combines established FL techniques with a comparative lifecycle-carbon model and a reuse-first architectural design (Table 1).

Table 1. Research gaps in prior work and the contributions of this paper that address them.

Gap in Prior Work	Contribution
Infrastructure choice between dedicated edge and device reuse is rarely treated as a formalized, consequential design decision in FL evaluation.	A reuse-centric FMCL architecture, within a five-dimensional sustainability framework that treats infrastructure provisioning as a design variable.
Communication-efficient FL optimizes data volume without modeling energy, and treats local training cost as uniform across heterogeneous hardware and device states.	A formal energy and carbon accounting model spanning device energy, communication overhead, embodied carbon, and utilization, identifying the parameter regimes that favor each architecture.
System-level accounting for embodied carbon and marginal energy across a learning system’s full lifecycle remains limited, and allocation conventions are rarely made explicit or compared.	A lifecycle-carbon accounting model applied symmetrically across cloud, dedicated-edge, and FMCL architectures under multiple allocation conventions (Section 4.4 and Section 5.2.6).
Sustainability claims for distributed learning are rarely qualified by the clinical reliability, heterogeneity, and risk conditions under which they hold.	An analysis of healthcare-specific constraints (reliability, latency, data governance, and clinical risk) and of the statistical heterogeneity, participation variability, security exposure, and rebound effects that delimit where the sustainability comparison applies.
Lifecycle conclusions for federated architectures depend on uncertain inputs.	A lifecycle-carbon sensitivity analysis across eight parameters and three embodied-carbon allocation conventions (Section 5.2.6 and Section 5.3).
The convergence cost of a client-selection policy has to be assessed at matched model quality rather than at equal round counts.	A preliminary evaluation of convergence under energy-aware and random client selection, in rounds to a fixed balanced-accuracy target on MIT-BIH arrhythmia classification (Section 5.2.4); the architecture-level comparison rests on the analytical model.

2. Foundations of Sustainable AI-Enabled Healthcare Infrastructure

2.1. The Cloud–Edge Infrastructure Spectrum

Healthcare AI can be deployed across a continuum of cloud, edge, and hybrid infrastructures. Cloud data centers consume electricity at a large scale; for example, Google’s fleet consumed roughly 18.3 terawatt-hours in 2021 [32].

The principal advantage of cloud computing is resource pooling, which generally enables higher infrastructure utilization. Dedicated infrastructure supporting a hospital diagnostic workload may operate at only 20–30% utilization; its servers are idle much of the time yet still drawing power [33]. Shared cloud environments, by contrast, can reach 60–70% across aggregated demand. That gap affects how effectively the embodied carbon and capital cost of hardware are amortized over useful computation.

In many healthcare deployments, data governance, residency requirements, and institutional risk policies can limit centralization despite the efficiency of cloud computing, because regulation may restrict moving patient data off-site.

Edge computing addresses these governance constraints and latency requirements by moving computation toward the point of data generation [34,35]. But edge reintroduces the utilization problem that pooling was meant to solve: systems sized for local peak demand run at low average utilization, which raises the environmental cost per unit of computation [36]. Such hardware is also prone to early obsolescence as accelerators evolve. Facility efficiency widens the gap, as hyperscale providers push power-usage effectiveness (PUE, total facility power over IT power) toward 1.1 [37]. Hospital server rooms with general-purpose cooling often exceed 1.5, and cooling itself becomes a dominant overhead. Proximity is an unreliable proxy for sustainability: the merits of cloud, edge, and hybrid deployments depend on the combined effects of utilization, embodied carbon, cooling, and operational energy.

2.2. Federated Learning in Healthcare: Cross-Device and Cross-Silo Variants

FL provides a mechanism for distributed healthcare AI without requiring raw patient data to be pooled centrally. It was introduced to train models on data that cannot be centralized [14]. A hospital’s cardiology archive is a canonical case: patient electrocardiogram (ECG) records that data-governance policies prohibit from leaving the institution. Each device trains locally on private, on-device data, and only model updates are sent to a coordinating server, where weighted averaging combines them into a global model for the next round. Extensions address heterogeneity across nodes [22], differential-privacy guarantees [38], asynchronous participation [39], and hierarchical aggregation [40].

Non-independent and identically distributed (non-IID) data pose a further challenge, since clinical datasets differ across institutions and personal-device data reflect individual context, so local updates diverge and simple averaging can yield a model that is poor for many participants even when aggregate accuracy looks acceptable [41].

The consequences are not purely statistical: misaligned updates require more rounds, and each round incurs communication and energy overhead. Methods that address this, such as FedProx [42], SCAFFOLD [43], and FedNova [44], reduce round count but add per-node overhead, so heterogeneity raises resource consumption in either case. In clinical FL, this cost is concrete: an arrhythmia classifier trained across cardiology sites needs more communication rounds where non-IID patient cohorts diverge most.

FL also divides into cross-silo and cross-device settings [45]. Cross-silo settings link a few institutions, each with substantial local data and compute; cross-device settings span many consumer devices, each contributing little under tight constraints. A multi-hospital sepsis-prediction consortium is a typical cross-silo case; a population of patients’ smartwatches training an arrhythmia model is a typical cross-device case.

FMCL occupies an intermediate regime: consumer devices, as in the cross-device case, but in settings where participation is narrower and per-device data richer, closer to one patient’s cardiac rhythm accumulated over weeks than a single photo. This intermediate regime, with moderate numbers of already-deployed devices, is where reuse can offset both the manufacturing and operational costs associated with dedicated per-institution infrastructure.

2.3. Mobile Crowd Computing: Opportunistic Participation and Resource Reuse

The devices that support smart and remote healthcare, including phones, wearables, and home sensors, were not designed primarily for federated training. Mobile crowd sensing predates FL entirely, and its founding observation, from Guo et al. [30], was that consumer devices are sensors and computers at once: a smartwatch measuring heart rate already functions as both a sensor and a computing device. Crowdsourcing that dual capacity across many participants yields a distributed infrastructure of wide coverage without deploying a single dedicated node. Mobile crowd computing extends this from sensing to computation [46]: devices perform local inference or training and contribute processed outputs rather than raw readings. FMCL applies this to distributed training, with a strong preference for reusing existing devices.

Device availability is stochastic [47], and devices are eligible only when idle, sufficiently charged, and adequately connected [48], so participation is intermittent, with availability often higher during charging and Wi-Fi-connected idle periods, such as overnight. That intermittency complicates coordination but creates a sustainability benefit: computation scheduled while a device would otherwise sit idle draws only the marginal energy above its idle draw. Dedicated edge infrastructure, by contrast, draws power regardless of workload, often a large fraction of peak even when idle [33].

Device heterogeneity is a further feature: compute, memory, network, and battery vary widely across the population [49], complicating task allocation and requiring adaptive scheduling and failure handling [50]. In a patient-device population, this heterogeneity is amplified by clinical context: patients with older or lower-capacity devices may provide clinically important data despite limited computational resources. Participation also rests on consent and incentives rather than institutional mandate. Incentive design, reliability, and heterogeneous coordination have long been studied in mobile crowdsourcing [30,51], and they are treated here as design constraints on reuse.

Volunteer computing resembles FMCL but differs from it: systems such as BOINC-based platforms recruit idle capacity from a large, heterogeneous device population for computationally independent tasks, and have done so for two decades with no requirement that participating hardware coordinate on a shared model [52]. More recent work extends this approach to deep learning itself, training models collaboratively across unreliable, low-cost, and even donated compute [53]. FMCL shares the reuse-first premise of these approaches but differs in the objective of that reuse. Volunteer computing and collaborative training treat device heterogeneity as a constraint to engineer around; FMCL treats avoiding new hardware as the object of formal analysis. Neither approach involves the continuous physiological time series that make a smartwatch or glucose monitor a candidate for clinical model training.

2.4. Lifecycle Assessment Methodology Applied to Healthcare Computing Systems

Lifecycle assessment (LCA) measures impact across a product’s whole existence, from material extraction through manufacturing, use, and disposal, under ISO 14040 and 14044 [54,55]. Long used for physical products, it has been extended to computing as IT’s environmental weight has become clear. Applied to a hospital’s device fleet, the same accounting must include every clinical wearable and bedside monitor deployed to support a digital-health program, as well as the servers that coordinate them. The evaluation in this paper applies only the carbon-footprint part of the method: it quantifies global-warming potential and does not cover the other impact categories of a full multi-impact LCA.

System boundaries determine which environmental impacts enter the comparison. A boundary restricted to training energy excludes manufacturing, cooling, networking, and disposal, whereas a broader boundary captures these impacts and can change the ranking of architectures.

The functional unit should represent an equivalent model outcome or clinical service, such as maintaining a specified diagnostic or monitoring accuracy over a given number of patient-hours, so that architectures with different convergence behavior are compared on equal terms. Lifecycle carbon is then reported per functional unit, alongside the achieved accuracy, and not as an accuracy-to-carbon ratio.

Allocation across shared systems determines the attributed embodied impact. A consumer device serves many purposes, one of which is training, so charging its full embodied carbon to that secondary use misrepresents it. Marginal allocation assigns the training workload only the additional embodied burden that participation causes, which is near zero when the device exists and would persist regardless [12]. In healthcare, this is a defensible basis: a patient’s phone was acquired for reasons entirely independent of any research program, unlike institutionally issued hardware whose procurement might already be partly justified by the workload it will run. Alternative allocation rules could assign the same device a different, nonzero share. For infrastructure procured specifically for the workload, a larger share of embodied impact is attributable to that workload under the stated boundary.

The near-zero marginal assumption fails if participation accelerates battery degradation or shortens a device’s usable life, because part of the replacement impact then belongs to training. Quantifying it requires empirical data on device wear under sustained training load; such data is not available here, so it is left as an open parameter. In a wearable health-monitoring deployment, this matters directly: continuous overnight charging cycles used for training should not measurably shorten a device a patient depends on for daily monitoring.

Embodied carbon, the emissions from manufacturing and supply chains, can account for 30–80% of lifecycle emissions for computing hardware, depending on utilization and context [12]. For short-lived consumer devices, it sits toward the high end, so an operational-only assessment understates the total. Standard IT sustainability reporting in healthcare systems typically omits it.

2.5. The Reuse-First Principle

The reuse-first principle prioritizes existing computing capacity over new hardware procurement when the existing devices can support the workload without disproportionate increases in operational energy or communication cost. It follows from marginal allocation (Section 2.4) and from a broader principle in industrial ecology and circular-economy research that treats provisioning decisions as prior to operational tuning. A health system choosing between provisioning new bedside edge servers and reusing the monitoring devices patients already carry is making a provisioning decision.

The principle is motivated by the material and energy requirements of manufacturing. Semiconductor fabrication runs on continuous high power, large volumes of ultrapure water, and globally distributed supply chains [56]. The embodied carbon of high-performance parts is large: server-class accelerators reach several hundred kilograms of CO₂e each [12], all incurred before any computation runs.

Reuse alters the accounting boundary by reducing or avoiding new hardware procurement: when existing devices stand in for newly built infrastructure, the manufacturing phase and its cost fall outside the system boundary [57].

The advantage of reuse is conditional on device capability, workload characteristics, connectivity, and participation-attributable wear. If constraints force inefficient execution, long training, or expensive transmission, the savings from avoiding new hardware can be canceled by higher operational demand; a rural clinic’s patchy cellular coverage, for example, can turn a nominally reuse-favorable deployment into one that trades manufacturing emissions for transmission emissions.

A second-order effect works against the saving: lower per-instance cost can drive wider adoption and raise total consumption even as each instance improves, so reductions in per-deployment emissions should be distinguished from reductions in total emissions.

The reuse-first principle is consistent with the waste-management hierarchy, which ranks prevention above reuse and recycling because avoiding manufacture avoids emissions that recycling can only partially recover [58].

2.6. Existing Approaches to Sustainable Federated Learning in Healthcare

FL’s carbon and lifecycle costs are addressed unevenly by prior work. Existing sustainability research in FL has focused primarily on operational energy, communication efficiency, and energy-aware training. Recent surveys collect this work under green FL. Thakur et al. [59] group over a hundred studies across client selection, compression, communication reduction, and energy-aware training. Yan et al. [60] catalog strategies for mobile edge, and Güler and Yener [61] give an early energy-accuracy formulation.

Communication is the most developed target: compression and sparsification cut FL payloads by one to two orders of magnitude [26]. But the target is data volume, not energy or grid intensity, so a halved payload over cellular can still cost more than an unhalved one over Wi-Fi.

Participant selection is the second lever: Oort [62] selects clients by data utility and speed, but its objective has no energy or carbon term; selection, therefore, does not account for differences in electricity carbon intensity. FMCL keeps Oort’s utility terms (Section 4.3) and adds the marginal-energy term it omits.

GRACE-FL [63] tunes learning rate, epochs, and bit-width to each client’s available energy and is closer to FMCL’s approach. Its objective addresses energy constraints but does not evaluate grid carbon intensity or embodied emissions.

CAFE [64] and later carbon-aware schedulers [65] defer training into low-carbon grid windows. This shares FMCL’s premise that operational carbon depends on when and where computation runs, but assumes that the infrastructure already exists.

FedProx [42], SCAFFOLD [43], and FedNova [44] bound client drift, and adaptive methods match model depth to device capability [66]. These make crowd-scale participation feasible, which FMCL needs. But they treat heterogeneity as an accuracy problem, not an energy one. Lower-capacity devices may require more time or energy per useful update, depending on the workload and hardware, and this energy cost is not in their objective.

Cao [67] comes closest to FMCL’s lifecycle framing. It measures the carbon footprint of cross-silo FL across storage, transmission, and training in real deployments, which have the same organizational form as a multi-hospital consortium. But its boundary is still the existing infrastructure: organizational silos on cloud compute, with embodied hardware carbon taken as given.

Table 2 indicates that the reviewed approaches address selected operational or optimization dimensions, whereas explicit comparison of hardware provisioning and consumer-device reuse remains limited.

Table 2. Coverage of sustainability dimensions across existing FL approaches.

Approach	Operational Energy	Embodied Carbon	Communication Efficiency	Consumer-Device Reuse	Lifecycle Comparison Across Architectures	Healthcare Framing
Green FL surveys [59,60,61]	Yes	Partial	Yes	No	Partial	No
Communication-efficient FL [26]	Indirect	No	Yes	No	No	No
Efficiency-driven selection (Oort) [62]	Indirect	No	Partial	No	No	No
Energy-capacity-aware training (GRACE-FL) [63]	Yes	No	Yes	No	No	No
Carbon-aware scheduling (CAFE, successors) [64,65]	Yes	No	No	No	Partial	No
Heterogeneity adaptation [42,43,44,66]	Indirect	No	No	Partial	No	No
Lifecycle FL accounting, cross-silo [67]	Yes	No	Partial	No	Yes	No
FMCL [this paper]	Yes	Yes	Yes	Yes	Yes	Yes

3. Sustainability Dimensions in Healthcare AI Infrastructure

Operational energy efficiency alone does not capture the lifecycle impact of healthcare AI infrastructure. A system can be operationally efficient and still impose a high environmental cost if it involves resource-intensive manufacturing, operates at low utilization, depends on inefficient supporting infrastructure, or contributes to premature device disposal [12]. A model that reduces per-query inference energy but requires hospitals to provision new bedside servers, for example, can increase lifecycle impact.

Figure 1 summarizes the sustainability costs of healthcare AI infrastructure along five dimensions: economic cost, embodied environmental impact, cooling and infrastructure overhead, energy proportionality, and electronic waste. These dimensions are coupled, and no single architecture is expected to dominate across all of them. Cloud deployments benefit from resource pooling and managed infrastructure but face the data-locality constraints imposed by patient records. Dedicated clinical edge reduces data movement but introduces additional embodied carbon and may suffer from lower utilization. Reuse-based approaches avoid infrastructure expansion but require careful management of heterogeneity and reliability across a patient-device population.

Figure 1. Interdependent sustainability dimensions in distributed AI architectures.

3.1. Economic Cost: Capital Expenditure Versus Operational Expenditure

Healthcare infrastructure procurement and utilization are constrained by budget, which affects both deployment feasibility and environmental impact.

Infrastructure costs are commonly divided into capital expenditure (CapEx) and operational expenditure (OpEx). Dedicated edge deployments require upfront hardware and integration costs, followed by ongoing power, cooling, and maintenance. Cloud deployment shifts this balance toward OpEx, reducing the risk of underutilized capital but introducing scaling costs for high-demand workloads. A hospital deciding between a dedicated FL edge cluster and reuse of its patients’ own devices is making a CapEx-versus-OpEx trade-off.

FMCL occupies a different position within this structure: it uses smartphones, wearables, and tablets that patients and clinicians already own for primary purposes unrelated to the AI system. From the health system’s perspective, the associated capital cost is generally outside its IT budget. The remaining costs relate to coordination: aggregation services, communication overhead, and participation management. These costs are non-negligible but are typically lower than those a hospital would incur for provisioning and maintaining dedicated infrastructure.

This advantage is context-dependent, because the total cost of ownership for crowd-based systems includes additional factors, such as patient incentive mechanisms, engineering complexity arising from device heterogeneity, and the validation overhead needed to keep model quality clinically acceptable across non-uniform patient data [19]. Reuse is economically beneficial when its total cost is lower than that of procuring and maintaining dedicated infrastructure.

3.2. Embodied Environmental Impact

Manufacturing servers and smartphones generates embodied carbon, the upstream emissions from material extraction, fabrication, assembly, and shipping, before the devices enter service. Operational carbon comprises emissions associated with energy consumed during use and is what most system evaluations report; embodied carbon is frequently comparable in magnitude but far less consistently accounted for.

Analyses of computing hardware have quantified this imbalance: for mobile devices, manufacturing and associated infrastructure can account for the majority of total emissions [12]. For data centers, the relative contribution depends on utilization and energy source: low utilization and low-carbon energy sources increase the relative significance of embodied emissions, whereas high utilization on a carbon-intensive grid has the opposite effect. Either way, embodied carbon cannot be neglected in system-level evaluation.

Dedicated edge infrastructure adds an upfront embodied-carbon burden that a health system must amortize over the hardware’s useful life [68]. The environmental benefit of such infrastructure depends on whether operational savings offset this initial cost within a reasonable period. When workloads are migrated from high-utilization, energy-efficient cloud environments, this offset may be delayed. Under the low utilization typical of a single-site clinical deployment, or early hardware replacement, the initial embodied cost may never be recovered.

Under the marginal allocation defined in Section 2.4, the manufacturing footprint of pre-existing consumer devices is not assigned to the training workload unless participation accelerates battery degradation or device replacement. Engineering controls, such as restricting computation to charging periods and limiting thermal exposure, may reduce this effect but do not eliminate the uncertainty.

3.3. Cooling and Infrastructure Overhead

Cooling contributes to facility energy consumption but is not part of the computational workload. Its overhead is commonly represented by PUE, the ratio of total facility power to IT equipment power. The most efficient data centers report PUE near 1.1, while industry averages remain higher, around 1.5 or above [37]. Hospital data centers and clinical FL aggregators incur this overhead regardless of whether the workload involves diagnostic inference or federated training.

Hyperscale facilities employ optimized airflow management, advanced cooling technologies, and site selection strategies that reduce thermal overhead. Such optimizations are typically not available in distributed edge environments. Edge systems deployed in hospital or clinical settings often rely on general-purpose cooling infrastructure, and their effective PUE may be 1.5 to 2.0 [69].

Smartphones and wearables operate at low power levels and are built for passive heat dissipation. Participant devices require no facility-level cooling allocation within the stated system boundary, although sustained computation can cause local heating, thermal throttling, and additional charging losses. This accounting convention does not imply that device-level thermal overhead is zero; PUE is a facility-level metric and does not apply at device scale.

Consumer devices are not uniformly more efficient: server-class hardware provides higher computational throughput per unit energy for large-scale operations, particularly in matrix-intensive workloads. For compact models, the relative contribution of infrastructure overhead depends on hardware utilization, communication demand, and the efficiency of the execution platform. Lower auxiliary energy consumption may offset lower computational throughput in some deployment configurations.

3.4. Energy Proportionality and Idle-State Waste

Energy proportionality is how closely a system’s power draw tracks the work it actually performs, ideally approaching zero when idle and rising in step with utilization. Most systems remain substantially less than energy-proportional [33]. Dedicated hospital infrastructure continues to consume idle power between training rounds.

Empirical observations from large-scale server deployments indicate that utilization levels are typically low to moderate, while idle power remains substantial. Servers operating at a fraction of their peak utilization may still consume a majority of their peak power. Provisioning hospital IT capacity for peak demand can create substantial standing energy consumption unrelated to active workload execution.

Because FL computation occurs in discrete rounds, this standing consumption accumulates between rounds as baseline load rather than productive clinical work.

Mobile devices can execute scheduled training bursts and return to low-power states between rounds, so they add less standing-energy demand than continuously powered clinical infrastructure. This pattern aligns with the bursty execution model of FL, where local training occurs intermittently rather than continuously.

Communication overhead is a limiting factor: energy consumed during data transmission, particularly over cellular networks, can be comparable to or exceed local computation costs. Uplink energy per bit runs substantially higher over cellular than over Wi-Fi [70], a real constraint for a rural clinic’s patient population without reliable home broadband. Gradient compression and sparsification reduce communication volume by orders of magnitude with limited impact on model performance [26], and scheduling communication over lower-power networks such as Wi-Fi further lowers communication energy.

3.5. Electronic Waste and Device End-of-Life Trajectories

Electronic waste is a substantial component of the environmental footprint of computing. Healthcare contributes through its own device fleet of monitors and imaging consoles and, increasingly, through millions of patient-owned wearables. The Global E-waste Monitor 2024 [71] documented that 62 million tons of e-waste was generated globally in 2022, nearly double the 2010 figure. The same report projects this will reach 82 million tons by 2030. Of the 2022 total, only 22.3% was formally collected and recycled, and informal processing of the remainder has well-documented consequences for human health and local ecosystems.

Computing hardware contributes directly to this stream through finite device lifecycles and accelerating replacement rates. In AI systems, this effect is amplified by rapid advances in hardware capability, which shorten the functional lifespan of existing equipment. Devices may remain operational yet become inadequate for evolving computational requirements, leading to early replacement. Hospital tablets, monitoring stations, and clinician-issued phones face the same pressure.

The destination of this waste depends heavily on the architecture. A cloud-only system generates e-waste at the data center level, where large operators have formal decommissioning and recycling programs. A dedicated edge deployment generates e-waste distributed across many sites: server rooms, equipment closets, and clinical spaces, where decommissioning is less formalized and equipment is less likely to reach certified recyclers. Dedicated-edge e-waste intensity may exceed that of pooled cloud infrastructure under lower utilization, shorter replacement cycles, and less formalized end-of-life management; this should be assessed empirically.

FMCL does not eliminate e-waste from participant devices [72]. Consumer devices have their own replacement cycles, driven by personal upgrade decisions and planned obsolescence, largely outside the AI system’s control. Its potential benefit is the avoidance of additional hardware procurement when existing devices displace dedicated infrastructure, provided participation does not accelerate device replacement.

Research in sustainable product design finds that extending device useful life reduces emissions more than improving end-of-life recycling rates, since manufacturing carbon is avoided rather than partially recovered [73], whereas FMCL does not, by itself, extend device life.

4. System Model for Federated Mobile Crowd Learning

FMCL comprises participant devices, regional aggregators, and a global coordinator. The system model below specifies how these tiers are organized; how participants are modeled, selected, and trained; and how energy, carbon, and privacy are accounted for.

4.1. Architectural Overview and Design Rationale

The reference FMCL configuration assumes no dedicated hardware is procured solely for the FL workload. Protocol design, task allocation, aggregation strategy, and privacy mechanism all follow from this constraint and the resulting trade-offs among participation, reliability, privacy, and sustainability.

FMCL adopts a three-tier organization, as shown in Figure 2. Participant devices, including consumer smartphones, wearables, and tablets already in circulation, train locally during periods of opportunistic availability on data generated as a byproduct of their primary function. Regional aggregators running on existing cloud or institutional server capacity collect updates from device clusters. The global coordinator performs final aggregation, model versioning, and parameter redistribution.

Figure 2. Three-tier architecture of FMCL.

The three-tier organization follows established hierarchical FL designs [40,74]. FMCL differs in its hardware provenance: the middle tier reuses existing infrastructure, and the base tier consists of devices already in circulation. Participant selection (Section 4.3) treats the device energy state as a first-class criterion alongside standard data-utility and system-performance metrics. Grid carbon intensity enters the lifecycle accounting of Section 4.4 but not the per-round score, as in Oort [62].

4.2. Participant Device Model: Capability, Availability, and Heterogeneity

Each participant device, $d_i$, is represented by a time-varying state comprising compute capacity $c_i\left(t\right)$, battery state $b_i\left(t\right)$, network type $n_i\left(t\right)$ (Wi-Fi, LTE, 5G), and data availability $a_i\left(t\right)$, the volume of locally accumulated training samples since the last round. These properties vary over time and may be correlated: a charging, Wi-Fi-connected, idle device is highly available, whereas a device with low battery, active foreground use, or limited connectivity may be ineligible for a training round.

Definition 1 (availability).

For device$d_i$with state$\left(c_i\left(t\right),b_i\left(t\right),n_i\left(t\right),a_i\left(t\right)\right)$, the availability indicator$A_i\left(t\right)\in \left\{\mathrm{0,1}\right\}$equals$1$when the device is idle, charged above a threshold$b_i\left(t\right)\ge b_{min}$, and connected to a network meeting the deployment’s minimum bandwidth and reliability requirements, and$0$otherwise. Only devices with$A_i\left(t\right)=1$are eligible for a round at time$t$. Wi-Fi connectivity is preferred but not required for eligibility; the network type enters the communication-energy term rather than gating participation, so a cellular-connected device remains eligible but incurs a higher energy cost.

Compute capacity spans a wide range: a current flagship smartphone sustains tens of INT8 TOPS on its neural processing unit (NPU) [75], potentially sufficient for the compact convolutional and recurrent models used in physiological signal classification [76]; an older mid-range device delivers an order of magnitude less. Execution time depends on model size, batch size, epoch count, hardware acceleration, and thermal state, so device-specific benchmarks are needed to determine feasible local-training configurations. Task configuration should therefore track device capability, with batch size, epoch count, and model depth set per device tier. The FedOps Mobile framework [66] follows a similar approach, adjusting inference depth and local load from runtime capability assessments.

Each device’s availability is modeled as a semi-Markov process whose transitions between available and unavailable are governed by device-specific parameters estimated from historical participation [77].

Assumption 1 (availability dynamics).

Each availability process,$\left\{A_i\left(t\right)\right\}$, is semi-Markov, with a stationary transition kernel and a holding-time distribution estimable from historical participation data. The aggregator then holds a consistent estimate of the expected available population,$E\left(\sum _i{A}_i\left(t\right)\right)$, for scheduling.

The aggregation layer maintains a probabilistic estimate of the number of available participants per round and adjusts its scheduling thresholds accordingly. Availability often follows temporal patterns, with the highest fractions of devices idle, charging, and on Wi-Fi commonly occurring at night (Section 6.2); the pattern depends on the deployment and should be confirmed with telemetry. For workloads without real-time constraints, scheduling rounds in such windows can improve energy efficiency and communication conditions.

4.3. Task Allocation and Aggregation Protocol

A federated round in FMCL proceeds through five stages: announcement, selection, local training, gradient submission, and aggregation.

In the announcement stage, the global server broadcasts round parameters to all registered devices: the current global weights, the local training configuration (batch size, epochs, and learning rate), and a submission deadline. Devices meeting the participation criteria (sufficient battery level, connectivity, and no active primary use) register their availability with the regional aggregator.

Participant selection is conventionally random or based on performance proxies; some schemes add data utility and system efficiency [62,78]. FMCL adds a third dimension, marginal energy cost. For each candidate device, a sustainability score, $s_i$, is computed as follows:

$$s_i=\alpha \cdot U_i^{data}+\beta \cdot U_i^{sys}-\gamma \cdot E_i^{marginal}$$

where $U_i^{data}$ is a data utility proxy (e.g., divergence of local distribution from global distribution, higher for devices whose local data is less represented in the aggregate); $U_i^{sys}$ is a system utility proxy (inverse of expected completion time); and $E_i^{marginal}$ is the estimated marginal energy cost of executing the training task on device $d_i$, given its current state and network conditions. Divergence alone does not distinguish a clinically valuable outlier from a noisy, biased, or malicious one, so the data-utility proxy is necessarily approximate.

These three terms also differ enough in scale and units that an unnormalized weighted sum would not be meaningful: each raw feature is clipped at its 5th and 95th historical percentiles and linearly mapped to a common [0,1] range before the weights are applied, using a normalization window that is fixed or periodically updated from non-sensitive telemetry. Unless noted otherwise, the three score components above denote these normalized, [0,1]-scaled quantities throughout the remainder of this section, including in Proposition 1 below.

The weights $\alpha ,\beta ,\gamma \ge 0$ control the relative importance of these factors and are normalized such that $\alpha +\beta +\gamma =1$. Their values are deployment-specific: a sustainability-first configuration increases $\gamma$ relative to $\alpha$ and $\beta$, while a data-quality-first configuration does the reverse. Devices are selected in descending order of $s_i$ up to a round budget, $K$.

Proposition 1 (selection crossover).

Take two eligible devices,$i,j$, with$U_i^{data}>U_j^{data}$. Under the score$s_k=\alpha U_k^{data}+\beta U_k^{sys}-\gamma E_k^{marginal}$, device$j$is ranked above$i$if and only if

$$\gamma \left(E_i^{marginal}-E_j^{marginal}\right)>\alpha \left(U_i^{data}-U_j^{data}\right)+\beta \left(U_i^{sys}-U_j^{sys}\right).$$

Local training uses FedProx [42] rather than FedAvg, because device heterogeneity is higher in FMCL than in cross-silo settings. Its proximal term penalizes local models that drift from the global model. This matters most for devices with highly skewed data, as when a device holds one patient’s data rather than a multi-patient institutional dataset.

After local training, each device compresses its gradient before transmission. Sparsification, which zeros all but the top-$k$ elements by magnitude, reduces payload by one to two orders of magnitude with modest convergence impact [26], and so lowers communication energy in a mobile setting. The regional aggregator then averages the received updates, weighting by local sample count to correct for dataset-size imbalance, and forwards the intermediate model to the global server for final fusion.

4.4. Formal Energy and Carbon Accounting Framework

Evaluating FMCL against alternative architectures requires an accounting model that captures the principal energy-consuming components and maps them to carbon using the relevant intensity factors. Throughout this section, lifecycle carbon denotes the carbon attributable to the AI deployment within the stated accounting boundary. It excludes the absolute lifecycle footprint of physical devices and infrastructure that would exist independently of the FMCL deployment.

The accounting model rests on four simplifications.

Assumption 2 (marginal energy attribution).

The energy attributable to the learning task is marginal relative to each device’s baseline draw in its charging-idle state, the condition under which FMCL schedules participation. Unplugged-idle, active-use, and low-power states carry potentially different counterfactual draws that this assumption does not separately model.

Assumption 3 (bounded participation wear).

Participation causes bounded wear, so the marginal embodied term satisfies$w_i\approx 0$.

Assumption 4 (known grid carbon intensity).

Grid carbon intensity$I_i\left(t\right)$is known or estimable per location and round.

Assumption 5 (aggregation capacity reuse).

Aggregation runs on reused capacity, so its embodied term$C_{agg}^{emb}\approx 0$.

Let $S=\{d_1,\dots ,d_N\}$ denote the device fleet and let $T$ be the total number of training rounds. For a single round $t\in \{1,\dots ,T\}$ with participant set $K_t\subseteq S$, where $\mid K_t\mid =K$, the total operational energy consumed by the FMCL system is as follows:

$$E_{\mathrm{op}}^{\mathrm{FMCL}}(t)=\underset{\mathrm{device} \mathrm{energy}}{\underbrace{\sum _{i\in K_t}\left(E_i^{\mathrm{train}}\left(t\right)+E_i^{\mathrm{comm}}\left(t\right)\right)}}+\underset{\mathrm{aggregator} \mathrm{energy}}{\underbrace{E_{\mathrm{agg}}\left(t\right)}}$$

where $E_i^{train}$ is the marginal compute energy of local training on device $i$, defined as the energy consumed above the device’s idle baseline during the training interval, and $E_i^{comm}$ is the communication energy for uploading compressed gradients and downloading updated model parameters. Communication energy includes protocol overhead and radio-tail effects, in addition to payload transmission. $E_{agg}$ is the energy consumed by the aggregation process, including update reception, aggregation, and redistribution.

The marginal framing of $E_i^{train}$ reflects that only incremental energy above baseline is attributable to the learning task: a device consuming 0.5 W at idle and 2 W during training contributes 1.5 W of marginal power. A dedicated edge server, by contrast, incurs both active and idle costs regardless of workload. If it consumes $P_{idle}$ at baseline and $P_{active}$ under load, the marginal training power is $\left(P_{active}\right|P_{idle})$, but the idle consumption persists. When servers are not exclusively dedicated to the FL workload, only a fraction $\rho \in [0,1]$ of idle energy is attributable to the system.

The embodied carbon contribution is allocated differently across architectures. For each participating device, $d_i$, the embodied carbon, $C_i^{emb}$, is attributed primarily to its original purpose. The marginal embodied contribution of participation is modeled as follows:

$$\mathrm{\Delta }{C}_i^{emb}=w_i\cdot C_i^{emb},w_i\approx 0$$

where $w_i$ captures potential acceleration of device wear due to participation. Under controlled participation policies, $w_i$ is assumed to be small.

The total lifecycle carbon for FMCL across $T$ rounds is then as follows:

$$C^{\mathrm{FMCL}}={\displaystyle \sum _{t=1}^T}\left[\sum _{i\in K_t}\left(E_i^{\mathrm{train}}\left(t\right)+E_i^{\mathrm{comm}}\left(t\right)\right)\cdot I_i\left(t\right)+E_{\mathrm{agg}}\left(t\right)\cdot I_{\mathrm{agg}}\right]+\sum _{i\in S}\mathrm{\Delta }{C}_i^{\mathrm{emb}}+C_{\mathrm{agg}}^{\mathrm{emb}}$$

where $I_i\left(t\right)$ is the location-dependent grid carbon intensity for device $d_i$ at time $t$, and $I_{\mathrm{agg}}$ is the intensity associated with the aggregation infrastructure. $\mathrm{\Delta }{C}_i^{\mathrm{emb}}$ is the marginal embodied contribution of participation defined above, near zero under Assumption 3 and examined directly in the sensitivity analysis of Section 5, and $C_{\mathrm{agg}}^{\mathrm{emb}}$ is the embodied carbon of aggregation resources that would not exist without the system, small but not strictly zero under reuse assumptions.

Communication energy is assigned the carbon intensity of the originating device’s grid location. A full network-level assessment would separately model access-network, backbone, and data-center energy and their respective carbon intensities, which need not match the device’s own.

For a dedicated-edge FL system with $M$ servers, the lifecycle carbon is given by the following:

$$C^{\mathrm{edge}}={\displaystyle \sum _{t=1}^T}M\cdot \left[E_{\mathrm{srv}}^{\mathrm{active}}\left(t\right)+\rho \cdot E_{\mathrm{srv}}^{\mathrm{idle}}\left(t\right)\right]\cdot I_{\mathrm{edge}}\hspace{0.25em}+\hspace{0.25em}M\cdot C_{\mathrm{srv}}^{\mathrm{emb}}\cdot {\displaystyle \frac{D}{L_{\mathrm{srv}}}}$$

where $E_{\mathrm{srv}}^{\mathrm{active}}$ is the server’s total energy draw during the active training interval, not incremental above idle. $E_{\mathrm{srv}}^{\mathrm{idle}}\left(t\right)=P_{\mathrm{idle}}\cdot \mathrm{\Delta }{t}_{\mathrm{idle}}$ is the idle energy accrued during the remaining, non-overlapping portion of that same interval, so that idle duration in round t satisfies $\mathrm{\Delta }{t}_{\mathit{idle}, \mathit{t}}= D_t-\mathit{\Delta }{t}_{\mathit{active}, \mathit{t}}$ for the interval $D_t$. The two durations sum to the full campaign, $\sum _t(\mathrm{\Delta }{t}_{active, t} + \mathrm{\Delta }{t}_{idle, t}) = D$. $I_{\mathrm{edge}}$ is the carbon intensity at the deployment site, $D$ is the duration of the training campaign, and $L_{\mathrm{srv}}$ is the server lifetime in the same calendar units. Embodied carbon is amortized over calendar time because the server’s service life advances independently of the training schedule. Operational carbon, by contrast, varies with workload frequency.

For a cloud-only deployment, the lifecycle carbon is as follows:

$$C^{\mathrm{cloud}}={\displaystyle \sum _{t=1}^T}\left[\left(E_{\mathrm{cloud}}^{\mathrm{comp}}\left(t\right)+E_{\mathrm{cloud}}^{\mathrm{data}}\left(t\right)\right)\cdot I_{\mathrm{cloud}}\right]+C_{\mathrm{cloud}}^{\mathrm{emb}}$$

where $E_{cloud}^{comp}$ is the server-side compute energy per round; $E_{cloud}^{data}$ is the data transmission energy associated with moving training data or intermediate outputs to the cloud; $I_{cloud}$ is the carbon intensity of the cloud provider’s energy supply; and $C_{cloud}^{emb}$ is the AI-attributed share of embodied carbon from cloud infrastructure, which, under a shared multi-tenant model, is small per workload but not strictly zero.

The conditions $C^{FMCL}<C^{edge}$ and $C^{FMCL}<C^{cloud}$ together represent the regime in which FMCL yields a lifecycle carbon advantage.

Proposition 2 (embodied-carbon advantage).

Under Assumptions 2–5, suppose the device and aggregation embodied terms of FMCL are zero, the limiting case of Assumptions 3 and 5, so that its total and operational carbon coincide. Suppose the dedicated-edge system provisions$M\ge 1$servers with embodied carbon$C_{srv}^{emb}>0$, and the operational carbon of FMCL over the horizon does not exceed that of the edge system,$C_{op}^{FMCL}\le C_{op}^{edge}$. Then,$C^{FMCL}<C^{edge}$. With nonzero residual embodied terms, the result holds whenever the edge embodied term exceeds them.

Remark 1.

The inequality holds whenever FMCL’s operational carbon is no worse than the edge system’s, because the edge system incurs an amortized manufacturing cost that reuse avoids. The edge total also carries idle energy,$\rho \hspace{0.17em}{E}_{srv}^{idle}$, that persists regardless of workload, whereas FMCL is charged only the modeled marginal device energy.

4.5. Privacy and Incentive Mechanisms in FMCL

Privacy in FMCL operates under a stricter threat model than in institutional FL because it cannot be assumed that all participants adhere to predefined organizational constraints. In cross-silo FL, participating institutions are subject to legal accountability and governed by data-use agreements. In contrast, participant devices in FMCL operate under no such enforceable guarantees, and privacy protection must therefore be ensured at the protocol level rather than assumed through external controls. Client-side privacy mechanisms assume that the released update is generated by the specified client software. A compromised client may not honor clipping or noise addition, so production deployment requires attestation, code integrity controls, secure aggregation, anomaly detection, or a threat model that explicitly excludes malicious clients.

Device-level differential privacy (DP) provides an appropriate mechanism in this setting, applying noise to each device’s update rather than to individual records before local aggregation. The privacy unit is defined as the participant device’s complete local dataset, so neighboring datasets differ in the presence or absence of one device’s data. Since FMCL’s participant devices are predominantly personal, single-patient devices, this corresponds to patient-level privacy for most of the use cases considered here. A shared or multi-user device would require a correspondingly broader privacy unit. This is a client-level protection applied to the aggregated local update, rather than the record-level randomization used in local differential privacy (LDP), where each data point is independently perturbed before any local computation.

Noise is applied locally at each device before transmission, not at the aggregator after raw gradients are received [79]. After local training, device $d_i$ forms a local update, ${\mathrm{\Delta }}_{\mathrm{i}}$, the difference between its post- and pre-training weights. It clips this update as ${\overline{\overline{\mathrm{\Delta }}}}_{\mathrm{i}}={\mathrm{\Delta }}_{\mathrm{i}}·min(1,C/\Vert {\mathrm{\Delta }}_i{\Vert }_2)$ so that its $l_2$-norm does not exceed $C$. It then adds Gaussian noise, $N(0,{\sigma }^2{C}^{2}I)$, releasing ${\overline{\tilde{\mathrm{\Delta }}}}_{\mathrm{i}} = {\overline{\overline{\mathrm{\Delta }}}}_{\mathrm{i}} + N(0,{\sigma }^2{C}^{2}I)$ as the transmitted, perturbed update. Clipping is applied to the full local update, not to per-example or per-minibatch gradients. The noise scale, $\sigma$, determines the privacy–utility trade-off: larger values provide stronger $\left(\epsilon \right|\delta )$-DP guarantees but degrade gradient quality and slow convergence.

Privacy loss accumulates across rounds. Each participating round adds privacy loss for the device, counted toward the final cumulative guarantee, $\epsilon$. After $T$ rounds, the cumulative loss must stay within acceptable limits. The accumulation is tracked through the Rényi differential privacy (RDP) composition framework [80], which bounds the cumulative loss more tightly than sequential composition would. In FMCL, this applies per device: each round in which device $d_i$ participates contributes additional loss toward that device’s cumulative budget, ${\epsilon }_i$. When training persists over long periods, privacy-budget management becomes a design constraint on participation frequency.

Remark 2 (per-device privacy budget).

With the Gaussian mechanism at noise multiplier,$\sigma$, and${\mathcal{l}}_2$-sensitivity bounded by$C$, each round satisfies$\left(\lambda ,\lambda /\left(2{\sigma }^2\right)\right)$-RDP. Over the$T_i$rounds in which device$d_i$participates, RDP composes additively to$\left(\lambda ,T_i\lambda /\left(2{\sigma }^2\right)\right)$-RDP, which converts to$\left({\epsilon }_i,\delta \right)$-DP with${\epsilon }_i=O\left(\sqrt{T_{i}log\left(1/\delta \right)}/\sigma +T_i/{\sigma }^2\right)$. The bound combines a square-root term from optimizing over the Rényi order with a residual term that grows linearly in the round count. Which term dominates depends on σ, δ, and the number of participating rounds: the square-root term governs at small round counts, and the linear term gains weight as the number of participating rounds grows. This is a simplified, non-subsampled Gaussian-mechanism bound, so a deployment that uses client subsampling, multiple local steps per round, adaptive client selection, or secure aggregation would require a mechanism-specific privacy accountant. In the protocol assumed here, a device that does not participate in a round transmits nothing, so whether and when a device participated is visible to the aggregator and to the selection mechanism and lies outside the noise mechanism. Participation privacy would require a separately specified communication and anonymity protocol, which this paper does not model; secure aggregation alone does not provide it. The bound applies to adjacent datasets that differ by the presence of one device’s update, with an absent device contributing the zero update in a fixed participant slot, so that the l2 sensitivity equals the clip norm. Under replacement adjacency, in which one participating device’s dataset is replaced by another, two clipped updates can differ by up to twice the clip norm, and the noise multiplier would have to be calibrated to that sensitivity.

Proposition 3 (privacy-energy coupling).

Under the Gaussian mechanism of Remark 2, increasing the noise multiplier,$\sigma$, reduces the achieved ε for fixed$\delta$. This does not change the size of the transmitted gradient payload, holding update dimensionality, compression, quantization, and cryptographic protocol fixed. It does, however, degrade gradient signal quality, which can increase the number of rounds$R$needed to reach a target model accuracy relative to a noiseless baseline. Since FMCL’s operational energy in Section 4.4 accumulates linearly in$R$via$E_{comm}$and$E_{train}$, a stricter privacy budget raises the total lifecycle carbon, with the other components held fixed, only to the extent that it raises the round count$R$rather than through per-round payload size. Privacy and carbon are coupled through$R$alone: any privacy configuration that increases the number of rounds needed for convergence proportionally increases the operational terms in Section 4.4 and Section 5.2. If the campaign duration is held fixed, the additional rounds imply a higher effective training frequency, narrowing the margin$f^{\ast }- f$in Proposition 4. A campaign that instead runs at fixed frequency and takes longer would not narrow the margin in the same way.

Remark 3.

Privacy parameters and the carbon budget should be evaluated jointly when both are constrained. Figure 3 shows schematically how the required rounds rise as the privacy budget, ε, tightens; the curve is illustrative and not derived from the analytical model.

Figure 3. Schematic relationship between privacy budget, ε, and required training rounds.

Incentive design matters wherever participation is voluntary, and FMCL participation cannot be mandated as it can in institutional FL. However, healthcare offers a natural alignment: the individuals whose devices train the model are also its potential beneficiaries. Informed consent should specify the computation performed, the data used, and the expected clinical benefit. Whether this alignment is sufficient to sustain participation remains an empirical question. Where intrinsic motivation falls short, lightweight extrinsic mechanisms (personalized insights, reduced service costs, and recognition of contribution) can supplement it, as studied in mobile health participation [81,82].

Trust verification adds further constraints: because participant devices cannot be pre-validated, robustness has to be enforced algorithmically. Gradient-norm monitoring gives a first-level filter, flagging updates that fall outside expected ranges; stronger defenses use Byzantine-resilient aggregation such as coordinate-wise median [83], which limits the impact of adversarial updates. These add computational overhead and can affect convergence, a robustness–efficiency trade-off examined in Section 7.3.

5. Lifecycle-Aware Comparative Architecture Analysis

Operational metrics alone do not reveal the lifecycle consequences of an architectural choice. The analysis defines the learning objective and compares computational location and hardware provisioning requirements.

5.1. Baseline Architectures

Cloud-only training runs on third-party servers and requires moving raw training data to central locations, unlike FMCL and dedicated-edge FL, which keep raw data local and transmit only model updates. Cloud-server utilization is high, and the infrastructure is professionally managed, often on an increasingly renewable energy supply. Healthcare data-governance requirements, contractual obligations, data-residency constraints, and institutional risk policies can complicate its use, and the transfer itself carries nontrivial energy.

Cloud-coordinated FL, in which the cloud aggregates gradients rather than receiving raw data, is separate from this cloud-only baseline. It is not a fourth hardware category alongside cloud-only, dedicated edge, and FMCL, because FMCL itself already permits aggregation hosted on existing cloud capacity (Section 4.1). Cloud-coordinated FL and FMCL differ in flat versus hierarchical aggregation and in which devices hold training data, not in whether a cloud coordinator is present. A cloud-coordinated deployment that trains on the same reused participant devices as FMCL would share FMCL’s device-side accounting and differ only in the aggregation layer.

Dedicated edge keeps data local by placing purpose-built servers at or near clinical sites and transmitting only model updates. Existing healthcare FL deployments also use institutional servers and cloud coordination; the dedicated-edge configuration carries the full embodied carbon of newly procured hardware.

FMCL distributes training across consumer devices already in the environment (patient smartphones, wearables, and clinical tablets), so no participant hardware is provisioned specifically for the learning workload; as set out in Section 4, embodied carbon stays attributed to each device’s primary use. Table 3 compares the three architectures across the five sustainability dimensions of Section 3.

Table 3. Qualitative comparison of lifecycle characteristics across distributed AI architectures.

Evaluation Factor	Cloud-Only	Dedicated Edge	FMCL
Embodied carbon (AI-attributed)	Moderate (shared, amortized)	High (per-site servers)	Near-zero under stated allocation assumptions (Section 3.2)
Operational PUE	~1.1–1.2	~1.5–2.0	Not applicable at device scale; no dedicated facility overhead allocated
Utilization rate	High	Low–medium	Opportunistic
Communication energy	High (data transmission)	Low (gradients only)	Variable (Wi-Fi low, cellular high)
E-waste contribution	Low (managed lifecycle)	Medium–high	Potentially low incremental burden under bounded wear; empirical measurement required

Note: The FMCL embodied-carbon and e-waste entries are attributional marginal-allocation results under the assumptions of Section 3.2 (pre-existing devices and bounded wear), not claims that participant devices carry zero absolute embodied emissions. Entries throughout are qualitative tiers for cross-architecture orientation, not precise thresholds; Section 4.4 and Section 5.2 give the quantitative comparison.

5.2. Carbon and Energy Comparison Under Bounded Assumptions

Using the accounting framework from Section 4.4, lifecycle carbon, $C^{\mathrm{arch}}$, is compared across $T$, training rounds, under a mix of cited literature estimates and illustrative scenario assumptions selected for this comparison. Unless stated otherwise, figures in this section assume a grid carbon intensity of 400 g CO₂e/kWh and a campaign of 200 training rounds per year.

5.2.1. Operational Energy

For cloud-only training, data transmission dominates. Moving raw imaging or physiological data over long-haul wide-area network (WAN) links, including the associated networking and security overhead, can cost more energy than the computation it feeds [25]. This cost can weaken the environmental case for cloud-based training in some healthcare settings. Where cloud training is viable, servers at 60–70% utilization keep active training energy low. Illustrative figures here take a 50 MB payload per device per round, 0.06 kWh/GB for wide-area transmission, 20 Wh per round of server-side compute before PUE, with PUE 1.15 applied, and 2 kg CO₂e/year for amortized shared data-center hardware.

For dedicated edge, the dominant cost is idle draw between rounds. Servers at 10–30% average utilization can still pull 50–70% of peak power while idle, as discussed in Section 3.4. Over a week with four one-hour training windows, a server drawing 120 W idle and 200 W active spends approximately 96% of its weekly energy outside the four active training windows. Under the marginal-allocation boundary, the model does not assign a dedicated standing-energy term to participant devices, because no device exists solely to participate.

Reuse avoids the additional embodied carbon associated with procuring dedicated hardware under marginal allocation; it does not eliminate operational costs. Device wear is addressed directly in Section 5.3 (Proposition 6). For FMCL, per-round operational energy is marginal compute plus communication. A round of $K_t=100$ devices running five local epochs on a mid-range smartphone system-on-chip (SoC), at roughly 2 W of marginal power over a 90 s interval, aggregates to about 5 Wh of compute.

Communication energy depends strongly on network type: for a compressed payload near 1 MB per device, Wi-Fi transmission runs 0.001–0.01 Wh per device, so 0.1–1 Wh across a round [70]. LTE uplink for the same payload costs five to ten times as much, making communication the dominant term under cellular conditions.

5.2.2. Embodied Carbon

Data center operational energy has grown comparatively slowly [12] even as infrastructure expands, shifting a larger share of lifecycle emissions onto manufacturing. Where new servers are required, embodied carbon becomes the primary determinant of total impact.

For dedicated edge, procuring $M$ servers, each with embodied carbon, $C_{\mathrm{srv}}^{\mathrm{emb}}$ (on the order of 200–500 kg CO₂e per server, depending on specifications [84,85]), introduces a manufacturing burden. This burden is incurred before any training runs and is amortized over the server’s operational lifetime.

Consider a fleet sized to one dedicated server per clinical site across 50 sites. At a 5-year lifetime and 200 training rounds per year, the embodied carbon per round for this fleet of 50 servers, using a mid-range embodied carbon estimate of 350 kg CO₂e per server consistent with [12], is as follows:

$${\displaystyle \frac{50\times \mathrm{350,000}{ \mathrm{g} \mathrm{CO}}_2}{5\times 200}}=\mathrm{17,500}{ \mathrm{g} \mathrm{CO}}_2 \mathrm{per} \mathrm{round}$$

On higher-specification hardware, the term reaches 40,000 g CO₂e per round at 800 kg per server. It is independent of operational efficiency and weighs most heavily when training is infrequent.

FMCL introduces no participant hardware specifically for the learning workload under the stated allocation boundary. Under marginal allocation, its embodied contribution is approximately zero, provided participation does not appreciably shorten device lifetimes. The advantage over dedicated edge is therefore largest at low-to-moderate training frequencies, the regime typical of healthcare FL, where data accumulates gradually and rounds occur intermittently.

The relative contributions of operational and embodied carbon across architectures are illustrated in Figure 4, computed over a one-year campaign of 200 training rounds at a grid carbon intensity of 400 g CO₂e/kWh. Edge operational energy is split into active and idle components; FMCL’s AI-attributed embodied carbon is zero under the stated marginal-allocation boundary, and neither cloud nor FMCL carries an attributable idle term. The figure assumes $C_{\mathrm{srv}}^{\mathrm{emb}}=350$ kg CO₂e per server, consistent with [12]; it is sensitive to higher-specification hardware (800 kg), as noted above.

Figure 4. Operational and embodied carbon by architecture (log scale, illustrative scenario).

5.2.3. The FMCL Advantage Condition

Combining operational and embodied terms, the condition $C^{\mathrm{FMCL}}<C^{\mathrm{edge}}$ can be expressed as follows:

$$\begin{gathered} {\displaystyle \sum _{t=1}^T}\left[\sum _{i\in K_t}\left(E_i^{\mathrm{train}}\left(t\right)+E_i^{\mathrm{comm}}\left(t\right)\right)\cdot I_i\left(t\right)+E_{\mathrm{agg}}\left(t\right)\cdot I_{\mathrm{agg}}\right] \\ <{\displaystyle \sum _{t=1}^T}M\cdot \left[E_{\mathrm{srv}}^{\mathrm{active}}\left(t\right)+\rho \cdot E_{\mathrm{srv}}^{\mathrm{idle}}\left(t\right)\right]\cdot I_{\mathrm{edge}}+M\cdot C_{\mathrm{srv}}^{\mathrm{emb}}\cdot {\displaystyle \frac{D}{L_{\mathrm{srv}}}} \end{gathered}$$

Device-side energy is weighted by location-dependent carbon intensity, $I_i\left(t\right)$. The edge cost is multiplied across $M$ servers, including idle overhead scaled by $\rho$. Embodied carbon appears only on the edge side under reuse assumptions.

FMCL yields a lifecycle advantage when the following is present:

• Embodied carbon of dedicated infrastructure is non-negligible relative to operational savings,
• Edge utilization is moderate to low,
• Device participation can be aligned with favorable energy conditions (e.g., Wi-Fi, charging periods, and lower-carbon grid intervals).

The FMCL advantage diminishes when participation becomes communication-dominated, as in cellular-heavy regimes, when the device set grows without matching gains in data utility, or when edge infrastructure runs at high utilization on a low-carbon grid.

However, the condition $C^{\mathrm{FMCL}}<C^{\mathrm{cloud}}$ is not guaranteed. It holds when

$${\displaystyle \sum _{t=1}^T}\left[\sum _{i\in K_t}{E}_i^{\mathrm{train}}\left(t\right)+E_i^{\mathrm{comm}}\left(t\right))\cdot I_i(t)+E_{\mathrm{agg}}(t)\cdot I_{\mathrm{agg}}\right]<{\displaystyle \sum _{t=1}^T}\left[\left(E_{\mathrm{cloud}}^{\mathrm{comp}}\left(t\right)+E_{\mathrm{cloud}}^{\mathrm{data}}\left(t\right)\right)\cdot I_{\mathrm{cloud}}\right]$$

Device-side communication energy dominates the left, cloud data transmission the right. FMCL holds the advantage when governance constraints make bulk data transfer infeasible, when $I_{\mathrm{cloud}}$ is high, or when cloud compute energy per round is substantial. Cloud can become the lower-carbon option when providers run near-renewable grids at high utilization and transmission is limited to gradient-sized payloads.

The inequality compares totals at a fixed number of rounds. The edge-embodied term is expressed in calendar time, not in rounds, because a provisioned server ages and its capital is committed regardless of whether a given round is scheduled. Under the marginal-allocation boundary, the model assigns no counterpart standing-energy term to FMCL for this component, since participant devices exist and depreciate independently of whether they train.

Standing and round-dependent carbon are separated as follows. Let $D$ be the campaign duration and let $\Phi$ collect the carbon the edge deployment incurs per unit time, $\Phi =M\left(\rho \hspace{0.17em}{P}_{\mathrm{idle}}\hspace{0.17em}{I}_{\mathrm{edge}}+{\displaystyle \frac{C_{\mathrm{srv}}^{\mathrm{emb}}}{L_{\mathrm{srv}}}}\right)$, with $L_{\mathrm{srv}}$ read in calendar units. Let $c_{\mathrm{edge}}$ be the marginal carbon of one round on that fleet, counting the active draw in excess of the idle draw already attributed to the standing term, and let $c_{\mathrm{FMCL}}$ be the carbon of one FMCL round. Then,

$$C^{\mathrm{edge}}=\Phi \hspace{0.17em}D+c_{\mathrm{edge}}\hspace{0.17em}T,\hspace{1em}{C}^{\mathrm{FMCL}}=c_{\mathrm{FMCL}}\hspace{0.17em}T$$

and only the round-proportional terms respond to how often training runs.

Proposition 4 (frequency crossover).

Under identical functional output between architectures, a fixed campaign duration,$D$, and with$\Phi$and$c_{\mathrm{edge}}$, as defined above, capturing all edge-side standing and marginal terms, FMCL holds the lifecycle advantage over dedicated edge if and only if$T\left(c_{\mathit{FMCL}}-c_{\mathit{edge}}\right)<\Phi \hspace{0.17em}D$. If$c_{\mathit{FMCL}} \le c_{\mathit{edge}}$, the advantage holds across all training frequencies. Otherwise, it holds exactly when$f={\displaystyle \frac{T}{D}}$satisfies$f<f^{\ast }$, where f denotes training rounds per unit calendar time (so$T=fD$;$f$is in rounds/year when$D$is in years), and

$$f^{\ast }={\displaystyle \frac{\Phi }{c_{\mathit{FMCL}}-c_{\mathit{edge}}}}$$

Remark 4.

The threshold rises with the standing carbon of the edge deployment and with a smaller per-round gap between FMCL and edge. Above it, the edge deployment’s standing carbon is spread over enough rounds for its lower per-round carbon to outweigh it.

Figure 5 illustrates Proposition 4 under the adverse FMCL regime (large-model computation and cellular-dominant communication) against a single-server baseline, the case closest to a crossover. Figure 4 uses a 50-server fleet whereas this scenario uses one server, so the two are not numerically comparable. The two totals intersect at $f^{\ast }$ ≈ 19,462 rounds per year, roughly 53 per day, a frequency substantially higher than the training schedules evaluated for any clinical use case in this paper. In this illustrative single-server adverse scenario, the modeled FMCL total is therefore below the modeled edge total across the whole range considered for the clinical scenarios in this study (up to 1500 rounds per year). With one server at ρ = 1.0, the edge standing carbon is 350.32 kg CO₂e per year (280.32 kg of idle operation at 80 W and 0.4 kg CO₂e/kWh plus 70.00 kg of embodied carbon over a five-year life), the marginal edge carbon is 0.0012 kg CO₂e per round (120 W above idle for 90 s), and the adverse FMCL regime draws 48 Wh per round, or 0.0192 kg CO₂e per round, so the threshold of Proposition 4 evaluates to 350.32/(0.0192 − 0.0012) ≈ 19,462 rounds per year. Table 4 lists the parameter values underlying both figures.

Figure 5. Lifecycle carbon vs. training frequency (single-server baseline, adverse FMCL regime, illustrative scenario).

Table 4. Parameter values used in Figure 4 and Figure 5.

Parameter	Value/Range	Applies to	Source/Scenario
Campaign duration and training frequency	1 year of operation at 200 rounds/year	Figure 4	Assumed
Grid carbon intensity	400 g CO2e/kWh	Figure 4	Assumed
Edge server embodied carbon (mid-range)	350 kg CO2e/server	Figure 4	Literature-derived [12]
Edge server embodied carbon (range)	200–500 kg CO2e/server	Figure 4 (sensitivity)	Literature-derived [84,85]
Edge server embodied carbon (high-spec)	800 kg CO2e/server	Figure 4 (sensitivity)	Illustrative
Edge server lifetime	5 years	Figure 4	Assumed
Edge fleet size	50 servers	Figure 4	Illustrative
Edge server power	80 W idle, 200 W active; idle draw attributed to the campaign at ρ = 1.0; no PUE applied	Figure 4	Illustrative
Edge round duration	90 s per round (active power drawn for the 200 rounds)	Figure 4	Illustrative
Edge standing carbon, Φ (one server, ρ = 1.0)	350.32 kg CO2e/yr (280.32 idle operation + 70.00 embodied)	Figure 5	Derived
Edge marginal carbon per round	0.0012 kg CO2e (120 W above idle for 90 s)	Figure 5	Derived
FMCL energy per round, adverse regime	48 Wh (0.0192 kg CO2e), compute plus cellular communication	Figure 5	Illustrative
FMCL compute energy per round	≈5 Wh (100 devices, 5 local epochs, ≈2 W marginal, 90 s)	Figure 4	Illustrative
FMCL communication, Wi-Fi	0.1–1 Wh/round	Figure 4	Literature-derived [70]
FMCL communication, LTE	5–10× Wi-Fi	Figure 4	Literature-derived [70]
Cloud data payload	50 MB/device/round	Figure 4	Illustrative
Cloud WAN transmission energy	0.06 kWh/GB	Figure 4	Illustrative
Cloud server compute	20 Wh/round before PUE; PUE 1.15 applied	Figure 4	Illustrative
Cloud amortized hardware	2 kg CO2e/year	Figure 4	Illustrative
Baseline fleet size	Single server (not the 50-server fleet of Figure 4)	Figure 5	Illustrative
Regime	Adverse: large-model computation, cellular-dominant communication	Figure 5	Illustrative
Crossover frequency, f*	≈19,462 rounds/year (≈53/day)	Figure 5	Derived
Practical comparison range	<1500 rounds/year	Figure 5	Illustrative

An additional assumption is that one training round represents equivalent progress in both architectures; this assumption does not generally hold. Non-IID data across personal devices, partial participation, dropout, and the noise added for device-level differential privacy all slow FMCL relative to a cross-silo deployment on provisioned hardware, so comparing at equal round counts favors FMCL by construction. A matched-quality comparison requires architectures to be evaluated at equivalent predictive performance. The convergence penalty, κ, relates the rounds needed to reach matched model quality: $T_{\mathrm{FMCL}}=\kappa \hspace{0.17em}{T}_{\mathrm{edge}}$. In principle, $\kappa$ could fall below 1 if a reuse-based participant pool offers greater data diversity than a data-limited edge baseline; the analysis below focuses on the conservative $\kappa \ge 1$ regime, where FMCL converges no faster than the edge.

Proposition 5 (Convergence tolerance).

At matched model quality, FMCL retains the lifecycle advantage if and only if$\kappa <{\kappa }^{\ast }$, where

$${\kappa }^{\ast }={\displaystyle \frac{\Phi \hspace{0.17em}D+c_{\mathit{edge}}\hspace{0.17em}{T}_{\mathit{edge}}}{c_{\mathit{FMCL}}\hspace{0.17em}{T}_{\mathit{edge}}}}$$

Remark 5.

The standing-carbon term increases the allowable convergence multiplier, because the numerator carries the standing term$\Phi \hspace{0.17em}D$that FMCL never pays while its denominator carries only FMCL’s round costs. On the illustrative parameters used earlier,${\kappa }^{\ast }$reaches two orders of magnitude against a single-server baseline and is higher against a provisioned fleet. Convergence penalties reported for federated optimization under heterogeneity are typically small multiples, well below$\kappa \ast$. The bound represents a lifecycle-carbon break-even condition; it does not imply that such a convergence slowdown would be clinically acceptable.

5.2.4. Preliminary Computational Evaluation of Client Selection at a Fixed Balanced-Accuracy Target

Proposition 5 treats the convergence penalty κ analytically, as a multiplier on round count that a deployment either absorbs or does not. The experiment is a preliminary evaluation of optimization behavior under client selection, one input to that multiplier: whether FMCL’s energy-aware selection rule changes the number of rounds needed to reach a fixed predictive target, relative to random selection. The task is five-class arrhythmia classification on the MIT-BIH Arrhythmia Database. Excluding four paced-rhythm recordings leaves 44 of the 48 recordings, each treated as one client; records 201 and 202 come from the same subject, so the 44 clients represent 43 subjects. Up to six clients are selected per round, and local training uses FedProx (proximal coefficient 0.01, two local epochs) under the FMCL protocol of Section 4. Both policies train the same architecture on the same client pool, so the experiment does not compare FMCL, dedicated-edge, and cloud training at matched performance, and it neither validates the lifecycle-carbon comparison of Section 5.2 and Section 5.3 nor measures clinical model performance.

Each beat is a 300-sample window (130 samples before and 170 after the annotated R peak, at 360 Hz, both leads) labeled with one of the five classes of the Association for the Advancement of Medical Instrumentation (AAMI) EC57 standard: normal (N), supraventricular (S), ventricular (V), fusion (F), and unclassifiable (Q). Beats with unmapped annotation symbols, or whose window would cross a recording boundary, are excluded, which leaves 100,688 beats. All beats of a recording form that client’s local training set, and there is no train, validation, or test partition: the global model is scored after every round on one class-stratified sample of 2000 beats (up to 200 per class, remaining places filled at random) drawn once per run from the pooled client data. Balanced accuracy here therefore measures how quickly the federation fits the pooled data, not generalization to unseen recordings or patients, and rounds to target compare optimization speed between selection policies.

Rounds to target are counted until ResNet1D, a one-dimensional residual network, reaches 0.30 mean per-class recall (balanced accuracy), credited only once the value has been held for five consecutive evaluation rounds, with a cap of 150 rounds. The round counted is the first of those five, and the balanced accuracy reported at target is the lowest of the five, averaged over seeds. The value 0.30 is a computational benchmark 0.10 above the 0.20 chance level of a five-class problem, not a clinical acceptability threshold. Balanced accuracy is used in place of raw accuracy because the majority class of MIT-BIH alone yields 63.5% raw accuracy without the model distinguishing a single arrhythmia. The two policies are FMCL’s energy-aware score (Section 4.3) and uniform random selection, the natural proxy for conventional federated learning without a sustainability-aware selection mechanism. Each is run with ten seeds under paired client-availability draws, so both policies face the same availability sequence in every round of a given seed.

Carbon to target is estimated from the counted training workload of the sparsified ResNet1D (floating-point operations and transmitted bytes per client-round), which is converted to device and communication energy with the two-term device energy model and the radio-overhead communication model of the reproducibility package. Energy is priced at 0.156 kg CO₂e/kWh and is combined with a marginal embodied term derived from the battery wear implied by this energy across a population of 1000 devices. Rounds are charged through the first qualifying round only; the four later confirmation rounds and the evaluation computation are not charged, and including the confirmation rounds would add the same four rounds to both policies and leave the difference in rounds unchanged. Six clients are charged in every round, regardless of which devices were selected, so carbon to target is proportional to rounds to target and restates the round counts in kg CO₂e; the experiment cannot register a difference in per-round energy between policies. The coefficients differ from those of the Table 4 scenario (100 devices, 200 rounds), so the roughly 2.9 g CO₂e per round obtained here is not comparable with the FMCL figures of Section 5.2.6.

In the baseline run (run A), ResNet1D reached the target in all ten seeds under both policies (Table 5, rows 1 and 2). Rounds to target were 25.2 for energy-aware selection and 26.6 for random selection, a mean paired difference of −1.4 rounds (bootstrap 95% confidence interval −8.4 to +6.2; paired t-test p = 0.73; Wilcoxon signed-rank p = 0.72). The experiment detected no difference: the interval permits convergence several rounds slower or faster under energy-aware selection, and the seed-to-seed spread (15 to 37 rounds) is much larger than the difference between policies. This is a null result, not evidence of equivalence, since no equivalence margin was fixed in advance. The participation level also limits the comparison (each client available with probability 0.1 per round, about 4.4 candidates on average for six slots): the selection rule chooses among more candidates than slots in only about 17% of rounds, and in the remaining rounds both policies take every available client. Table 5 also reports run B, an independent replication (rows 3 and 4), and two exploratory conditions, higher availability (rows 5 and 6) and held-out recordings (rows 7 and 8), described below.

Table 5. Rounds to target and estimated carbon to the first qualifying round, by client-selection policy and condition (ResNet1D, ten seeds per policy).

Selection Policy	Rounds to Target (Mean, Range)	Balanced Accuracy at Target (Mean)	Estimated Carbon to First Qualifying Round, kg CO2e (Mean, Range)
Energy-aware (FMCL), run A	25.2 (17–37)	0.318	0.074 (0.050–0.109)
Random, run A	26.6 (15–37)	0.315	0.078 (0.044–0.109)
Energy-aware (FMCL), run B	24.0 (17–36)	0.316	0.071 (0.050–0.106)
Random, run B	27.3 (15–48)	0.313	0.080 (0.044–0.141)
Energy-aware (FMCL), availability 0.3	16.6 (6–33)	0.311	0.049 (0.018–0.097)
Random, availability 0.3	23.2 (11–35)	0.316	0.068 (0.032–0.103)
Energy-aware (FMCL), held-out (exploratory)	17.1 (6–33)	0.440	0.050 (0.018–0.097)
Random, held-out (exploratory)	17.9 (6–33)	0.440	0.053 (0.018–0.097)

Run B repeated the configuration of run A as an independent replication and recorded per-class output. Energy-aware selection needed 24.0 rounds and random selection 27.3, a paired difference of −3.3 rounds (bootstrap 95% confidence interval −10.1 to +3.7; paired t-test p = 0.40; Wilcoxon p = 0.23), with fewer rounds in five seeds, equal rounds in two and more in three, so neither run detected a difference. Figure 6 plots the rounds to target of each seed under both policies in run B and in the held-out condition described below, with gray lines joining the two policies within each seed and a black line joining the means over ten seeds. Run A is the reference for the weight-grid and stress-test comparisons below, and run B for the per-class diagnostics.

Figure 6. Rounds to target by seed under energy-aware and random selection: Run B (left) and held-out condition (right).

Table 6 gives per-class recall in run B at the first round of the qualifying streak, with the mean over the classes present and the lowest balanced accuracy within the streak repeated from Table 5. Under energy-aware selection, mean recall was 0.98 for normal beats and 0.73 for ventricular beats, against 0.97 and 0.69 under random selection. Recall for the other three classes was 0.00 under both policies, except for fusion beats under random selection (0.01); across all seed-specific evaluation samples, no supraventricular or Q-class beat was assigned to its own class. The mean of these recalls is above the balanced accuracy in Table 5 because the table reports the lowest of the five evaluations in the streak, whereas recall is taken at its first round. A classifier that separates normal from ventricular beats and recognizes no other class can therefore pass the 0.30 target, so rounds-to-target measures how quickly the federation learns the two dominant classes. The same pattern held at availability 0.3.

Table 6. Mean per-class recall at the first round of the qualifying streak (ResNet1D, ten seeds per policy).

Condition and Policy	N	S	V	F	Q	Mean Over Classes Present	Lowest Value in Streak
Run B, energy-aware	0.975	0.000	0.730	0.000	0.000	0.341	0.316
Run B, random	0.973	0.000	0.686	0.010	0.000	0.334	0.313
Held-out, energy-aware	0.976	0.000	0.851	0.000	n/a	0.457	0.440
Held-out, random	0.966	0.000	0.860	0.000	n/a	0.457	0.440

In the exploratory higher-availability condition, specified after the baseline analysis, availability was raised from 0.1 to 0.3 (about 13 candidates for six slots), so that selection was binding in 97.5% of energy-aware rounds and 98.2% of random rounds. Energy-aware selection reached the target in 16.6 rounds against 23.2, with fewer rounds in eight of ten seeds and a paired difference of −6.6 rounds (bootstrap 95% confidence interval −13.0 to +0.6; paired t-test p = 0.10; Wilcoxon p = 0.08). The interval includes zero, so no effect was detected at the 0.05 level, although the direction agrees across most seeds. The energy-aware policy selected devices with a lower mean energy multiplier (1.11 against 1.27).

An exploratory held-out condition scored the model on nine recordings withheld from training and used only for scoring, with records 201 and 202 kept on the same side of the split. They contain no Q-class beats (shown as n/a in Table 6), so balanced accuracy was taken over four classes, for which chance is 0.25. The 0.40 target was set post hoc from a three-seed probe without early stopping, which gave median balanced accuracies of 0.43 to 0.46 over 150 rounds and used seeds also present in the ten-seed comparison. The nine recordings therefore informed the design and do not form an untouched test set.

Energy-aware selection needed 17.1 rounds and random selection 17.9, a paired difference of −0.8 rounds (bootstrap 95% confidence interval −4.2 to +1.8; paired t-test p = 0.65; Wilcoxon p = 1.00), with identical round counts in six of ten seeds, because selection was binding in only 9% of rounds at this availability (Figure 6, right panel). Held-out recall was 0.98 and 0.97 for normal beats and 0.85 and 0.86 for ventricular beats under energy-aware and random selection, and 0.00 for supraventricular and fusion beats under both (Table 6), so the target was again met by a two-class classifier. The result describes performance on one held-out, subject-grouped split and does not establish reliable generalization across patient populations.

The selection score of Section 4.3 uses weights (α, β, γ) = (0.4, 0.3, 0.3). Four alternative triples, (0.6, 0.2, 0.2), (0.2, 0.2, 0.6), (0.2, 0.6, 0.2), and (0.33, 0.33, 0.34), were run on ResNet1D, with seeds 0 to 2, under the paired protocol. Every triple reached the target in the same number of rounds as the default in every seed (21, 36, and 18 rounds) and therefore at the same lifecycle carbon (Table 7). That is consistent with the participation regime described above: the weights only matter in the roughly 17% of rounds where candidates outnumber slots, and no such round changed the credited round.

Table 7. Rounds to target and estimated carbon under five selection-weight triples (seeds 0 to 2).

Weights (α, β, γ)	Rounds to Target, Seeds 0, 1, 2	Carbon to Target, kg CO2e, Seeds 0, 1, 2
0.4, 0.3, 0.3 (default)	21, 36, 18	0.062, 0.106, 0.053
0.6, 0.2, 0.2	21, 36, 18	0.062, 0.106, 0.053
0.2, 0.2, 0.6	21, 36, 18	0.062, 0.106, 0.053
0.2, 0.6, 0.2	21, 36, 18	0.062, 0.106, 0.053
0.33, 0.33, 0.34	21, 36, 18	0.062, 0.106, 0.053

A stress test with the energy-aware policy and ten seeds, again on ResNet1D, combined tier-dependent availability (0.06, 0.10, and 0.14 per round for low-, medium-, and high-tier clients, averaging 0.10 as in the baseline), temporally correlated dropout (a two-state Markov process with lag-1 autocorrelation 0.5 and the same stationary availability), and a restriction of each client to its three most frequent classes. The natural per-recording MIT-BIH split is already strongly label-skewed: the dominant class makes up 91% of a client’s beats on average, and 26 of 44 clients are more than 95% single-class, so the class restriction changed only 88 of 100,688 beats, and the test mainly varies availability. All ten seeds reached the target, in 21.8 rounds on average (range from 13 to 33) against 25.2 in run A (difference −3.4 rounds; bootstrap 95% confidence interval −9.7 to +2.8; paired t-test p = 0.34), and selection was binding in 23.6% of rounds against 17% at baseline. Under the tested availability and dropout configuration, FedProx reached the target without a statistically detectable increase in rounds. FedProx limits client drift but does not guarantee convergence under arbitrary heterogeneity, and one configuration does not bound the effect of harsher ones; unequal sample counts, heterogeneous local computation budgets and completion times, and stronger label skew were not varied, alone or in combination.

5.2.5. Cost–Sustainability Trade-Off Surfaces

Dedicated edge incurs high upfront embodied carbon and persistent idle overhead, both of which require sustained, high-frequency training to amortize; in clinical settings, where training is intermittent, that condition is rarely met. Cloud removes the embodied burden, but cost and carbon scale linearly with use, and large medical datasets push the transfer term high. FMCL removes AI-attributed participant-device embodied carbon from the stated accounting boundary, leaving communication energy and coordination overhead as the drivers, which stay modest under Wi-Fi-dominant scheduling and rise sharply when participation is cellular-heavy.

5.2.6. Allocation Convention and the Architecture Comparison

The analytical model of Section 4.4, Section 4.5, Section 5, Section 5.1, Section 5.2, Section 5.2.1, Section 5.2.2, Section 5.2.3, Section 5.2.4 and Section 5.2.5 charges the dedicated edge fleet calendar-amortized embodied carbon and charges FMCL’s already-owned participant devices approximately zero under Assumption 3. In Table 8, the marginal column charges provisioned hardware (the dedicated edge fleet, a cloud aggregator, and cloud hardware) an assumed 0.5% of its embodied carbon, on the view that a single campaign induces only a small share of any procurement. The factor is a modeling assumption, not an established minimum burden. Charging the edge fleet its calendar-amortized share instead (3500 kg CO₂e per year) raises its marginal-column total to 17,528 kg and changes no ranking. Treating shared infrastructure as a cost center amortized across its tenants, or charging a device’s full lifecycle footprint to whichever workload uses it, gives different numbers from the same hardware.

Table 8. Annual lifecycle carbon by architecture under three allocation conventions (kg CO₂e/year).

Architecture	Marginal (kg CO2e/yr)	Calendar-Time (kg CO2e/yr)	Shared-Infrastructure (kg CO2e/yr)
Cloud-only	25.85	27.84	27.84
Dedicated edge	14,115.50	17,528.00	18,403.00
FMCL	0.44	1439.64	72.40
Cloud-coordinated FMCL	2.20	1509.65	89.91

Table 8 compares the three architectures of Section 5.1 and cloud-coordinated FMCL under three conventions: marginal, as defined above; calendar-time, full embodied carbon amortized in proportion to the campaign’s share of a unit’s rated service life, measured in calendar time without a workload-occupancy term; and shared-infrastructure, full embodied carbon divided across the number of equivalent workloads a unit serves over its life. Cloud-coordinated FMCL is the variant in which aggregation capacity is provisioned rather than reused, the case of a nonzero aggregator embodied term discussed in Section 5.3.1.

The ranking depends on the allocation convention: FMCL and its cloud-coordinated variant have the lowest footprint under marginal allocation, whereas cloud-only has the lowest footprint under calendar-time and shared-infrastructure allocation. Dedicated edge has the highest footprint under all three conventions in the tested configuration, because the reference fleet is large and retains substantial operational and allocated manufacturing burdens.

The inputs behind Table 8 are those of Table 4 together with the following. Cloud-only operational energy per round is 0.30 kWh of transmission (100 devices at 50 MB, at 0.06 kWh/GB) plus 0.023 kWh of compute (20 Wh before the PUE of 1.15); over 200 rounds at 0.4 kg CO₂e/kWh, this gives 25.84 kg. The marginal column adds 0.5% of the 2 kg annual hardware figure, and the other two columns add all of it. The dedicated edge fleet comprises 50 servers, each with 350 kg CO₂e of embodied carbon and a five-year life, charged one year of that life under the calendar-time convention and one quarter of its full embodied carbon under the shared-infrastructure convention, which assumes the fleet serves four one-year campaigns over its five-year life. For FMCL, calendar-time and shared-infrastructure allocation use 35.98 kg CO₂e per phone [73] across a fixed cohort of 100 devices, with a 2.5-year service life in the first case and one of 50 equally weighted uses of the device in the second. The cloud-coordinated variant adds one 350 kg aggregation server with a five-year life that draws 80 W for 5 s per round and is shared by 20 tenants under the shared-infrastructure convention. The 0.5% allocation factor, the tenant counts, the 2.5-year life, and the equal weighting of device uses are modeling choices, not measurements.

Shared-infrastructure allocation attributes embodied carbon according to the assumed distribution of hardware use among tenants, and under the present assumptions it favors cloud infrastructure. The comparison therefore reflects the allocation rule as well as the architecture and should not be read as a direct estimate of the emissions a single training campaign generates.

5.3. Sensitivity Analysis

The thresholds derived so far rest on point estimates of the inputs, several of which are uncertain. Device wear is examined first because the reuse argument depends on it, followed by the operational parameters, joint variation in all eight parameters, and the case of a pre-existing edge fleet.

5.3.1. Device Wear

Assumption 3 in Section 4.4 set the marginal embodied term $w_i\approx 0$ and deferred its examination to this section. It carries more weight than the other assumptions, because the reuse argument rests on it. Wear enters the account once per campaign rather than once per round: if $N$ devices each carry embodied carbon, $C_{\mathrm{dev}}^{\mathrm{emb}}$, and participation consumes a fraction $w$ of remaining service life, the FMCL total becomes $c_{\mathrm{FMCL}}\hspace{0.17em}{T}_{\mathrm{FMCL}}+N\hspace{0.17em}w\hspace{0.17em}{C}_{\mathrm{dev}}^{\mathrm{emb}}$.

Proposition 6 (Wear tolerance).

With wear included, FMCL retains the advantage if and only if$w<w^{\ast }$, where

$$w^{\ast }={\displaystyle \frac{\Phi \hspace{0.17em}D+c_{\mathit{edge}}\hspace{0.17em}{T}_{\mathit{edge}}-c_{\mathit{FMCL}}\hspace{0.17em}{T}_{\mathit{FMCL}}}{N\hspace{0.17em}{C}_{\mathit{dev}}^{\mathit{emb}}}}$$

Remark 6.

The wear term is treated as a fixed campaign-level quantity, not one that scales with cumulative computation, thermal exposure, or charging cycles. It is charged once while the operational terms accumulate, so its relative weight falls as a campaign lengthens and wear matters more in short, intensive deployments than in long, intermittent ones. A degradation model tied to cumulative usage intensity could weight this differently, for example${\mathit{\Delta }C}_{\mathrm{i}}^{\mathrm{emb}} = C_{\mathrm{i}}^{\mathrm{emb}}·g(h_{\mathrm{i}}, {\theta }_{\mathrm{i}}, z_{\mathrm{i}})$, where$h_{\mathrm{i}}$is training time,${\theta }_{\mathrm{i}}$is thermal exposure, and$z_{\mathrm{i}}$is charging-cycle stress. Empirical estimation of$g(·)$remains future work.

Taking per-device embodied carbon at the scale of tens of kilograms of CO₂e across a hundred-device fleet and measuring against a single-server baseline, the wear tolerance $w^{\ast }$ remains below 10% of remaining service life across the plausible range of grid intensity; against the fifty-server fleet used earlier, it exceeds unity, which would require participation to consume more than the entire remaining life of every device.

Measured against the cloud-only architecture under the same marginal convention, the threshold tightens considerably: $w^{\ast }$ falls to approximately 0.7% of a device’s remaining service life, so wear at only a fraction of the scale considered above is enough to erase FMCL’s advantage over cloud specifically.

Direct empirical estimates of participation-attributable wear are not available; battery-aging studies measure capacity loss under charge cycling and not the marginal effect of intermittent background training.

Assumption 5 sets $C_{\mathrm{agg}}^{\mathrm{emb}}\approx 0$ on the grounds that aggregation runs on reused institutional or cloud capacity. This assumption does not always hold: a deployment may provision dedicated aggregator hardware rather than reusing existing infrastructure. In that case, Proposition 2 shows the threshold shifts rather than disappears. The embodied-carbon advantage requires $M\cdot C_{\mathrm{srv}}^{\mathrm{emb}}\cdot D/L_{\mathrm{srv}}>C_{\mathrm{agg}}^{\mathrm{emb}}$ in place of simple positivity. This condition may hold when a small aggregation layer coordinates a substantially larger dedicated-edge fleet. The aggregator is then a small number of nodes relative to the fleet, so $C_{\mathrm{agg}}^{\mathrm{emb}}$ may be well below the fleet-wide server term it is compared with; whether it is should be checked against deployment-specific hardware inventories rather than assumed. This assumption may fail for small fleets with disproportionately provisioned aggregation capacity, a configuration this paper’s healthcare use cases do not approach.

5.3.2. Operational Sensitivity Parameters

The operational parameters considered are connectivity mix, model complexity, grid carbon intensity at device locations, and participation churn.

Connectivity mix: If participant devices connect predominantly over cellular rather than Wi-Fi, a realistic scenario in mobile patient populations, communication energy rises by a factor of five to ten per round. Under LTE, a fleet of several hundred devices can match or exceed the active training energy of a dedicated edge deployment. Wi-Fi-conditional scheduling and gradient compression (Section 4.3) remain the primary mitigations. Cellular-dependent participation is relevant for ambulatory and rural monitoring populations, which frequently rely on it for remote cardiac or glucose monitoring.

Model complexity: Very large models, such as transformer-based clinical language models with hundreds of millions of parameters, generate gradient payloads that limit the effectiveness of compression. At such scales, communication energy becomes the dominant component of the FMCL energy budget and can reduce or eliminate the advantage over dedicated edge. FMCL is therefore more appropriate for compact models and lightweight architectures typical of edge-deployable healthcare applications.

Grid carbon intensity at device locations: The operational advantage of FMCL depends on the distribution of devices across grids with moderate or mixed carbon intensity. If participant devices are concentrated in regions with high values of $I_i\left(t\right)$, while edge servers operate under low $I_{edge}$, the operational carbon comparison may favor dedicated edge. The energy-only score of Section 4.3 does not include grid intensity as a criterion, as carbon-aware participant selection techniques from the literature do [64]; adopting them would mitigate this without changing the embodied-carbon terms.

Participation churn: Dropout occurs when devices register availability but fail to complete training, and high dropout rates require additional rounds to reach equivalent model quality. Under independent, homogeneous dropout with per-round completion probability $1-q$, the expected number of clients that must be invited to obtain $K$ completions is $K/(1-q)$; at $q\approx 0.4$, the expected invitation count is approximately 1.67 K, or two-thirds more than the completion target. The added communication and training costs for those who ultimately drop out materially erode the efficiency advantage in the illustrative parameterization used here. Correlated or subgroup-specific dropout, and dropout that occurs before versus after local training completes, must be modeled separately, since either can also shift the effective training distribution. Redundant selection, inviting more devices than needed and keeping only the first $K$ successful contributors, is a standard mitigation, though it adds communication overhead.

Model complexity and cellular-heavy connectivity matter most on the FMCL side, since both raise its per-round cost. On the edge side, how much of a shared server’s idle draw is actually charged to the workload matters most, since that alone can erode the advantage down to embodied carbon. Table 9 recomputes the comparison across this $\rho$ sensitivity: at $\rho =1$ (fully dedicated capacity), $\rho =0.5$ (partially shared), and $\rho \approx 0$ (consequential, incremental-only allocation), together with the plausible range of each other parameter named in this section, varying one parameter at a time with the others held at the Table 4 baseline. Because $\rho$ multiplies only the idle-power term of $\Phi$ and leaves its embodied-carbon term unchanged, $f^{\ast }$ falls toward the value set by the embodied term alone as $\rho$ decreases toward zero.

Table 9. One-way sensitivity of the FMCL comparison to the eight named parameters.

Parameter	Range Tested	vs. Dedicated Edge	vs. Cloud
Device wear (w)	0 to 0.05	FMCL leads throughout	FMCL leads below ≈0.7%; reverses above
Communication mode (Wi-Fi to LTE)	1× to 10× per-round communication energy	FMCL leads throughout	FMCL leads throughout
Grid carbon intensity	0.05–0.70 kg CO2e/kWh	FMCL leads throughout	FMCL leads throughout
Participation dropout (q)	0–0.7	FMCL leads throughout	FMCL leads throughout
Edge fleet size (M)	1–100 servers	FMCL leads throughout	FMCL leads throughout
Convergence penalty (κ)	1–50	FMCL leads throughout	FMCL leads throughout
Training frequency (f)	10–20,000 rounds/year	FMCL leads throughout	FMCL leads throughout
Edge idle-energy attribution (ρ)	0–1	FMCL leads throughout	FMCL leads throughout

Varying all eight parameters simultaneously rather than one at a time, drawing each independently and uniformly over the ranges in Table 9, FMCL retains the advantage over dedicated edge in 93.9% of 20,000 joint draws and over cloud in 43.3%. These are fractions of sampled model scenarios, not probabilities of superiority for any deployment. Sampling used Python’s random generator with seed 0; fleet size and annual rounds were rounded to integers, and the baseline values are those of Table 4. The ranges are independent: they ignore dependence among fleet size, training frequency, dropout, convergence, and wear, and they do not exclude combinations that cannot be scheduled within a year. The grid-intensity parameter moves all architectures together, so asymmetric cases such as a high-carbon participant grid against a low-carbon cloud region are not sampled. Within these limits, the comparison with dedicated edge holds in most scenarios; the comparison with cloud does not. Device wear is the only one of the eight parameters whose variation alone reverses the comparison with cloud, and no single parameter reverses the comparison with dedicated edge.

5.3.3. Asymmetric Grid Intensities and a Pre-Existing Edge Fleet

The joint sampling was repeated with the participant, edge, and cloud grid intensities drawn independently over the same 0.05 to 0.70 kg CO₂e/kWh range, so that a high-carbon participant grid can face a low-carbon cloud region. FMCL then had a lower footprint than dedicated edge in 92.8% of 20,000 sampled scenarios, against 93.9% with a common grid, and a lower footprint than cloud in 48.1%, against 43.3%.

The comparison changes if the edge fleet already exists. The dedicated-edge results above assume that the fleet is procured for the campaign. If the servers already exist and run whether or not training is scheduled, the campaign causes only the power it adds above idle during its active rounds, and no embodied carbon. At the Table 4 baseline (200 rounds of 90 s at 120 W above the 80 W idle draw, 0.4 kg CO₂e/kWh, no PUE applied to the edge fleet), the campaign then emits 0.24 kg CO₂e per server, or 12.0 kg for the 50-server fleet, against 0.44 kg for FMCL. FMCL stays lower when the fleet has two or more servers, narrowly at two (0.44 against 0.48 kg), and is higher against a single server. Across the joint sampling, it is lower in 16.9% of scenarios, or 23.2% with independent grid intensities, so that against spare capacity the outcome depends on fleet size, round count, convergence penalty, and wear and not on avoided procurement.

5.4. Relation of the Results to Prior Work

Embodied-carbon estimates for computing hardware are uncertain [85]. In the sensitivity analysis, the ranking of FMCL against dedicated edge holds under every convention and in most joint scenarios, whereas the ranking against cloud turns on the allocation convention and on device wear, for which direct empirical evidence is most limited [12].

Studies of the carbon cost of federated learning point to the client-side operational terms that remain within the FMCL accounting boundary. A model-based estimate puts the carbon cost of federated learning well above that of centralized training [86], and a field measurement found client-side computation and communication dominating emissions [87]. FMCL removes the dedicated-hardware term from the accounting boundary but keeps the client-side terms, and the cloud-only result in Table 8 and the 43.3% joint fraction against cloud describe the cost that remains. These studies report estimated or measured emissions of federated deployments, whereas the comparison here is scenario-based. Their figures therefore provide context and not validation of the modeled totals.

The selection experiment evaluates convergence under two selection policies and does not bear on the architecture-level comparison above. It relates to carbon-aware scheduling work [64,65], whose reported savings are largest for small recruited populations. In the participation regime tested, selection chose among more candidates than slots in about 17% of rounds, which is consistent with the absence of a detected difference but does not test those schedulers, since they weight grid intensity and the score used here does not. FedProx [42] limits client drift without guaranteeing convergence under greater heterogeneity, so the stress-test result does not generalize beyond the tested configuration. At an availability probability of 0.3, where selection was binding in nearly every round, energy-aware selection needed fewer rounds in eight of ten seeds, but the confidence interval for the difference included zero.

6. Clinical Deployment: Scale, Use Cases, and Governance

The framework developed in Section 2, Section 3, Section 4 and Section 5 applies to healthcare deployments that have distributed data generation, adequate device access, suitable connectivity, reliable operation, and appropriate governance.

6.1. Scale of Healthcare AI Deployment

The healthcare AI market was valued at approximately USD 19 billion in 2023 [88] and USD 37 billion in 2025 [89]. Growth in deployment increasingly involves imaging, diagnostics, remote monitoring, and clinical decision support.

Healthcare AI growth is distributed across heterogeneous clinical and home settings, including hospitals, clinics, community health centers, home care platforms, and remote patient monitoring systems, and is not concentrated in a small number of data centers with professionally managed energy infrastructure. Each deployment adds demand for compute, communication, and cooling at sites that are not typically optimized for energy efficiency, and the aggregate footprint of this expansion remains largely unquantified and is rarely reflected in existing sustainability reporting. Data is generated at the point of care, and patient-associated devices increasingly provide local computational capabilities, so learning can be co-located with data generation without centralized infrastructure expansion.

6.2. Mobile Health Sensing and Opportunistic Device Availability

The device-density argument for FMCL in healthcare is supported by the large and growing installed base of connected consumer devices. Global wearable shipments reached approximately 538 million units in 2024, according to IDC data, as reported by industry sources [90]. Within this installed base, healthcare-oriented usage has expanded rapidly, with a growing population using smartwatches and connected monitoring devices that incorporate increasingly capable sensing functionality [91]. Devices such as consumer smartwatches with ECG capability, continuous glucose monitors paired with smartphones, and wearable sensors for blood pressure and oxygen saturation generate continuous streams of physiological data in everyday settings.

These devices also provide computational capability beyond sensing. A mid-range smartphone SoC can sustain on the order of hundreds of billions of operations per second under typical benchmark conditions, though sustained throughput varies with numerical precision, thermal state, and workload. Mid-range smartphones may therefore support local training of compact physiological-signal models, although suitability depends on sustained computational performance and device-specific energy measurements. During some charging and idle periods, devices may have unused compute capacity, and participation in those periods is assumed to add only marginal energy above the device’s idle draw (Assumption 2).

Longitudinal physiological data can capture transient cardiac events, dietary- and behavior-associated glucose dynamics, and activity patterns during recovery or rehabilitation that may be missed during controlled clinical visits. Models trained on such data may better reflect real-world patient conditions than those trained exclusively on institutionally collected datasets. However, home-collected data can also introduce greater measurement noise, missingness, and selection bias that may be easier to manage under controlled institutional data collection.

Device availability exhibits diurnal patterns tied to routine charging and connectivity behavior. In the largest reported production federated-learning deployment, device participation varied by roughly a factor of four between its daily low and high points, with devices more likely to be idle and charging, and therefore eligible, at night [92]. Whether healthcare populations show the same pattern requires validation. Where it holds, the pattern aligns with opportunistic scheduling strategies described in Section 4.2, in which devices are simultaneously charging, connected via Wi-Fi, and computationally idle.

6.3. Representative Healthcare Use Cases

Healthcare AI tasks suited to FMCL involve compact models, longitudinal data, and privacy-sensitive measurements. Eight contexts were selected purposively to span sensing modality, workload size, retraining requirements, ownership, connectivity, and institutional control. Federated electronic health record (EHR) analytics was included as a boundary case outside the intended consumer-device setting. The cases are illustrative rather than exhaustive or statistically representative. Applicability to other settings depends on the criteria summarized in Table 10.

Table 10. FMCL fit assessment across the healthcare use cases of Section 6.3.

Use Case	Model Compact	Continuous Data	Low-Mod. Frequency	Device Density Adequate	Governing Constraint
Cardiac arrhythmia (wearables)	Likely	Likely	Likely	Likely	No specific constraint identified
Chronic disease monitoring	Likely	Likely	Likely	Likely	No specific constraint identified
Oncology symptom monitoring	Likely	Likely	Likely	Conditional	Device density
Federated EHR analytics	No (institutional)	Likely	Likely	N/A	Not device-based
ICU deterioration prediction	Likely	Likely	Uncertain	Uncertain	Potential frequency mismatch (requires estimation)
Rural/remote telehealth	Likely	Likely	Likely	Conditional	Cellular-dominant communication
Dementia smart-home monitoring	Likely	Likely	Likely	Likely	No specific constraint identified
Maternal/neonatal monitoring	Likely	Likely	Likely	Conditional	Device penetration (equity)

Note: These are conceptual assessments derived from the model assumptions of Section 4 and Section 5, not empirical deployment evaluations; entries should be read as plausible or conditional fits pending device-penetration, connectivity, and retraining-frequency data specific to each deployment.

6.3.1. Cardiac Arrhythmia Detection on Wearables

Cardiac arrhythmia classification from wearable ECG and photoplethysmography is among the more mature mHealth applications. Consumer devices now support long-term ambulatory rhythm monitoring at relatively low cost, which provides a continuous sensing substrate for model training [93].

On the distributed learning side, federated approaches have been used for collaborative arrhythmia classification across distributed nodes without transmitting raw ECG data to a central server [94]. Similar approaches have been applied across related mHealth domains, including stress monitoring and neurodegenerative disease detection, using physiological data collected from mobile devices [95].

FMCL places participating training clients on already-deployed smartwatches rather than purpose-built edge hardware. Under the marginal-allocation convention in Section 4.4, the manufacturing footprint of already-owned smartwatches contributes approximately zero to the AI-attributed embodied-carbon term, provided participation does not shorten device life. A dedicated-edge deployment, by contrast, incurs the allocated manufacturing footprint of newly procured servers.

6.3.2. Chronic Disease Monitoring

Diabetes, hypertension, and heart failure share a common monitoring pattern: continuous physiological data from devices patients already keep at home. Individually, these data streams provide limited training signals; collectively, they form a distributed dataset across large populations.

Distributed learning approaches have been applied to a range of conditions beyond cardiac monitoring, including Parkinson’s disease, mental health assessment, and stress detection using wearable physiological signals [95,96]. In addition, decentralized FL has been shown to support seizure detection on resource-constrained wearable platforms [97].

Across these conditions, deployment feasibility depends on device capabilities, data quality, consent, connectivity, model monitoring, and clinical validation.

6.3.3. Oncology Treatment-Response and Symptom Monitoring

Randomized evidence has reported fewer emergency admissions and improved survival associated with reporting symptoms between visits, rather than relying on clinician recall at scheduled appointments [98]. Wearable-derived measures, including step count, heart rate variability, and sleep continuity, extend this signal beyond what a symptom questionnaire alone can capture, and have been linked to treatment tolerability and unplanned hospitalization in oncology cohorts [99].

Two characteristics of this setting align well with FMCL: the signal is longitudinal and physiological rather than a single scan or biopsy, and the model classifying symptom trajectories or activity decline is compact relative to imaging or genomic models.

Data sensitivity is also high: treatment-response signals are both clinically and psychologically sensitive, thus strengthening the case for the device-level differential privacy mechanism in Section 4.5 over transmitting raw symptom or sensor logs to a central server.

6.3.4. Federated EHR Analytics Across Hospital Networks

In institutional cross-silo settings, such as federated analysis of electronic health records across hospital networks, FMCL is less directly applicable because participating nodes are institutional servers rather than consumer devices. The same accounting principle applies to aggregation infrastructure: using existing servers may avoid additional embodied carbon when new hardware would otherwise be required.

6.3.5. ICU Deterioration Prediction: A Boundary Case

Sepsis and other acute deteriorations in intensive care evolve on a timescale of hours, not weeks. Federated approaches have shown clinical value here: a federated LSTM model trained across multiple ICUs using hourly-aggregated vital signs detected sepsis onset on average two hours earlier than models trained locally at each site [100].

ICU deterioration prediction differs from the other use cases because bedside monitors operate continuously at fixed institutional locations and may require frequent model updates. These conditions do not match the intermittent availability assumed for consumer-device participation. Low-latency inference is a separate requirement from retraining cadence, and cadence depends on the task and on governance. Where local protocols call for frequent model updates, the retraining frequency may approach the crossover frequency, $f^{\ast }$, of Proposition 4, above which the carbon advantage derived for FMCL does not hold. A dedicated edge, shared institutional infrastructure, or cloud-coordinated FL may be preferable, depending on latency, governance, reliability, and retraining requirements (Section 6.5).

6.3.6. Rural and Remote Telehealth Monitoring

Wearable-based remote patient monitoring is an established application of AI in telehealth. Its clinical value is particularly relevant where in-person care is least accessible: rural and underserved populations who would otherwise depend on infrequent clinic visits for conditions that need continuous tracking [101].

This setting presents a trade-off between dedicated regional infrastructure and communication-intensive participation. For geographically dispersed populations, dedicated edge infrastructure may require servers near each population cluster to meet latency or data-locality requirements, and may be poorly utilized when capacity is provisioned separately for small clusters. Reusing patients’ phones avoids that provisioning, but whether this reduces lifecycle carbon depends on connectivity, workload requirements, and the availability of shared infrastructure.

The principal incremental terms under the stated marginal-allocation boundary are communication, local compute, coordination, and any participation-attributable device wear. Cellular-dependent rural participation incurs the five-to-tenfold LTE communication penalty described in Section 5.3.

6.3.7. Smart-Home Monitoring for Dementia and Independent Living

Multi-modal sensing in the home, which tracks motion, sleep, speech, and activity patterns together rather than any single physiological signal, has moved from research prototype to field-tested system. ADMarker, deployed in a four-week clinical trial across 91 elderly participants, used a three-stage federated architecture to detect digital biomarkers of Alzheimer’s disease directly from home sensor data. It reached 88.9% accuracy in early identification without centralizing any participant’s daily activity record [102].

Among the illustrated use cases, dementia smart-home monitoring most closely matches the operating conditions assumed by FMCL. The sensors are stationary, continuously powered, and connected to a stable home Wi-Fi network, closer to an always-available device than any wearable discussed elsewhere in this section. ADMarker’s own deployment used purpose-built hardware; running the same detection, at least in part, on smart speakers, tablets, and phones that households already own would apply the reuse accounting of Section 4.4, but whether such devices can support the workload has not been evaluated.

6.3.8. Maternal and Neonatal Monitoring in Low-Resource Settings

Maternal and neonatal mortality remain concentrated in the settings where continuous monitoring is hardest to deliver. A wireless, soft-sensor maternal-fetal monitoring platform, field-tested with 576 pregnant women across both a high-resource site (Chicago) and a low-resource site (Lusaka, Zambia), found that low-cost, mobile-compatible vital-signs monitoring performs comparably across both settings. Such settings combine a strong need for continuous monitoring with limited feasibility for conventional infrastructure-intensive deployments [103].

Unequal device access, discussed in Section 7.5, is especially consequential here. Reuse-based designs may broaden feasible monitoring options where dedicated infrastructure is not viable, although inexpensive shared platforms or hybrid models may do the same in other settings. The device-ownership gradient that motivates the deployment also determines who is covered by it: patients most likely to lack a compatible smartphone, or to have unreliable connectivity or constrained access to charging, are concentrated in the intended target populations, and the populations least likely to participate carry the greatest clinical need.

6.4. Regulatory and Data-Governance Constraints

Healthcare data governance often determines which system designs are permissible, well before any architectural questions of efficiency or cost arise. Regulatory frameworks such as the Health Insurance Portability and Accountability Act (HIPAA) in the United States, the General Data Protection Regulation (GDPR) in the European Union (EU), and comparable regimes elsewhere impose strict constraints on data residency, access control, consent, and auditability.

The device-level differential privacy mechanism described in Section 4.5 can support data-minimization and risk-reduction objectives relevant to these requirements: raw patient data remains on the device, and only perturbed model updates are transmitted. It does not, however, independently establish compliance with HIPAA, GDPR, or other regulations. Compliance requires a deployment-specific assessment of legal basis, roles, consent, security safeguards, data flows, retention, auditing, and residual re-identification risk. Whether gradient updates fall outside the scope of regulated data at all remains an evolving area of legal interpretation [104].

Consent design for FMCL participation must therefore be explicit and structured. Participants should be informed about which data streams are used for local training, what information is transmitted, the purpose of the model being trained, and the intended clinical benefit. This requires more explicit information than passive data collection, but it aligns more closely with expectations for informed consent in healthcare. Evidence from mHealth participation studies indicates that transparency regarding purpose and data use improves willingness to participate [81].

6.5. FMCL Fit Analysis for Healthcare Settings

FMCL is a plausible candidate when the following conditions are empirically verified. Models must be sufficiently compact to be trained on consumer devices within short time windows. Relevant data must be generated continuously by devices already used by the patient population. Device density and connectivity, with Wi-Fi preferred, must be adequate to sustain participation, and clinical need must not require training more often than the crossover frequency defined in Proposition 4. Proposition 5 further determines how much slower FMCL may converge before the lifecycle comparison no longer favors FMCL under the stated assumptions. Under the model’s stated assumptions, cardiac monitoring in smartphone-enabled adult populations and chronic disease management applications involving connected glucometers, blood pressure monitors, and activity trackers are candidates under these conditions.

FMCL is less suitable for applications requiring real-time model updates, very large model architectures, or certified hardware tightly coupled to regulated medical devices, such as diagnostic imaging systems or implantable technologies. It is also less suitable in settings with limited smartphone penetration or where connectivity is predominantly cellular, as the energy cost of communication becomes significant. In such cases, dedicated edge or cloud-based architectures remain more appropriate. Deployment choice should be based on measured model size, retraining cadence, connectivity, device access, and lifecycle parameters. Table 10 applies these criteria directly to the eight use cases in Section 6.3, assessing each use case according to model compactness, data continuity, training frequency, and device density.

7. Risks, Trade-Offs, and Boundary Conditions in Healthcare Deployment

FMCL deployment introduces statistical, operational, security, equity, and rebound risks that can alter both the sustainability estimates and the clinical applicability of the architecture.

7.1. Statistical Heterogeneity and Model Convergence

The non-IID nature of data in consumer-device FL is substantially more pronounced than in institutional cross-silo settings, with direct consequences for convergence and model quality. When local datasets reflect individual patients rather than aggregated institutional cohorts, class distributions across devices become highly skewed. For instance, a patient with atrial fibrillation may generate almost exclusively arrhythmic ECG segments, whereas a healthy participant contributes almost none. Such label skew is a primary driver of client drift [105], the phenomenon in which locally trained models diverge from each other and from the global optimum. This results in slower convergence, degraded global accuracy, and unstable training dynamics.

Within FMCL, this heterogeneity is further compounded by variation in device capability. Unequal local computation can alter the effective influence of clients, and sample-count weighting alone does not necessarily correct this effect. The proximal regularization term in FedProx, incorporated into the FMCL protocol (Section 4.3), partially constrains local divergence. However, its effectiveness remains sensitive to parameter selection and does not fully mitigate severe label skew.

Mitigation strategies exist—among them, clustered FL and personalized aggregation—but each introduces trade-offs. Clustered FL improves convergence but increases server-side computation. Personalized FL improves local accuracy, which is clinically relevant when patient subgroups differ, but increases communication overhead. Neither approach is cost-neutral relative to the baseline in Section 4.4. Heterogeneity mitigation therefore cannot be evaluated on accuracy alone; its effect on convergence rate, communication rounds, and energy consumption, dimensions that standard FL benchmarks underreport, determines FMCL’s sustainability profile.

7.2. Reliability, Dropout, and Round Completion

Consumer devices cannot be assumed to remain available throughout a training round. A participant that registers availability at the start of a round may still fail to complete it: the device may become unavailable during patient use, the battery may fall below the participation threshold, or a cellular handover may interrupt communication. Two failure modes are typically observed: straggler failures, in which updates are submitted after the round deadline, and dropout failures, in which updates are not submitted at all. Both occur more frequently in consumer-device settings than in institutional environments.

Under such conditions, convergence behavior becomes sensitive to participation patterns. FedAvg does not guarantee convergence under realistic dropout conditions. This is particularly true when failing devices exhibit systematically different data characteristics from those that complete [106]. When dropout is non-random, for example, when devices of older adults with limited connectivity fail more often than others, the effective training distribution shifts away from the intended patient population. The resulting model reflects both data heterogeneity and participation bias.

A common mitigation is redundant recruitment: selecting more patient devices per round than the required minimum and accepting only the first completed updates. This improves round completion but increases communication energy by roughly the same factor as the oversampling ratio, which partially offsets the efficiency gains established earlier. Missing or systematically biased client updates can affect convergence; the magnitude depends on participation patterns, data heterogeneity, and the aggregation protocol [107].

Scheduling strategies provide partial mitigation: the overnight participation window introduced earlier increases the probability of device availability, stable connectivity, and sufficient battery levels. However, dropout is not eliminated; it remains an inherent property of consumer-device participation. Reliability must therefore be treated as a probabilistic constraint rather than a guaranteed condition in FMCL system design.

Redundant recruitment increases attempted-client computation and communication. Dropout may separately increase the rounds required to reach the target, particularly when it changes the effective training distribution; the sensitivity analysis prices the first effect as a per-round inflation of 1/(1 − q) and the second through the convergence penalty. Where dropout does lengthen training, it consumes part of the same convergence margin that Remark 5 shows can reach two orders of magnitude under illustrative parameters.

7.3. Security Surface Expansion

Extending FL to a health system’s patient-device population expands the security surface from a small number of controlled, contractually bound institutional participants to a large and largely unverified one. A malicious actor could install the client application, register a device, and submit updates that appear statistically ordinary while degrading a clinical model or extracting information from it. Institutional cross-silo FL can, however imperfectly, rely on the fact that participating hospitals have reputational and legal incentives not to attack the system they are part of. The FMCL architecture cannot rely on the same institutional incentives, and the resulting risks affect both model robustness and the privacy guarantees the architecture is built to provide.

7.3.1. Gradient-Based Attacks

Malicious participants may submit gradient-poisoned updates designed to degrade the model or introduce backdoors, and even Byzantine-robust aggregation can be circumvented when poisoning is carefully calibrated [108]. Mitigations such as gradient-norm monitoring and coordinate-wise median aggregation [109] trade robustness for convergence speed rather than eliminating the risk. Because reduced model quality directly affects clinical utility, the security configuration needs to be calibrated explicitly for each deployment.

Telemetry-based client selection introduces an additional manipulation surface. The selection score of Section 4.3 uses expected completion time, marginal energy cost, and local-data divergence. Client-reported values may be manipulated unless independently verified. A client that understates its energy cost or overstates its speed raises its own score and is chosen in more rounds, thereby giving a poisoning client more opportunities to submit updates; one that inflates its data-utility proxy can pass as an unusual but clinically valuable site. Changing weights alone does not ensure the integrity of reported inputs. Selection of this kind is sound only if the aggregator measures these inputs or the client software attests to them; otherwise, it assumes honest reporting.

7.3.2. Privacy Inference Risks

The device-level DP guarantee formally bounds distinguishability between neighboring datasets under the mechanism and adjacency relation defined in Section 4.5; it does not protect information outside that scope. Model inversion [110] and membership inference [111] attacks remain feasible against device-level DP-protected updates when the privacy budget is sufficiently large to preserve utility, or when a small local dataset allows a single record to dominate the gradient. The risk is not uniform: devices with rare physiological patterns contribute more easily distinguishable gradients and may require stronger, not weaker, protection. Whether privacy budgets should be calibrated per device based on data rarity, and how to do so without inadvertently weakening protection for the participants who most need it, are open questions.

7.4. Rebound Effects and Deployment Scope Expansion

A reduction in per-deployment environmental cost does not necessarily translate into a reduction in total impact. If deployment becomes cheaper and easier, it may be adopted more widely, including in settings where it was previously not considered viable. In such cases, total compute demand can increase, offsetting the gains achieved at the individual deployment level. A monitoring program that is carbon-favorable at pilot scale can lose that advantage once adopted network-wide across a health system. This is an instance of the rebound effect: efficiency improvements can lead to increased overall usage rather than absolute reduction [112].

This risk is directly relevant to FMCL, whose premise is lowering the hardware barrier to deployment. That same barrier reduction can enable healthcare AI deployment in smaller clinics, remote settings, or lower-resource environments that could not previously justify the infrastructure. While this is desirable from an access perspective, it also increases the total number of active deployments and, with it, aggregate energy consumption.

Proposition 7 (rebound break-even multiplier).

Let$N_0$denote the number of deployments that would exist under a dedicated-edge baseline, each carrying lifecycle carbon$C^{edge}$per Proposition 2, and let$\mu$denote the adoption multiplier by which FMCL’s lower barrier increases the number of active deployments relative to$N_0$. FMCL then supports$\mu \cdot N_0$deployments each carrying lifecycle carbon$C^{FMCL}$. Aggregate carbon under FMCL exceeds the counterfactual dedicated-edge baseline exactly when$\mu \cdot N_0\cdot C^{FMCL}>N_0\cdot C^{edge}$, that is, when$\mu >C^{edge}/C^{FMCL}$. Because$C^{FMCL}$is small relative to the edge carbon, as it is where FMCL’s per-deployment advantage is largest, this ratio is large and adoption would need to expand substantially before the rebound effect fully erodes the aggregate saving.

Remark 7.

The comparison reverses once the adoption multiplier exceeds the break-even ratio. The framework does not estimate$\mu$, the demand-side adoption multiplier. The break-even ratio$C^{edge}/C^{FMCL}$is nonetheless a quantity a deployment can measure directly and should track as adoption scales.

7.5. Representational Bias and Digital Equity

The reuse-first principle that gives FMCL its sustainability advantage rests on a demographic assumption that is not explicitly modeled in the present framework: participation requires owning a compatible device, keeping it charged, and consistently connecting it to a network, with Wi-Fi preferred, to be selected for training rounds. These requirements may exclude patients with limited device access, unreliable connectivity, or constrained access to charging. Wearable ownership in the United States varies with age, income, education, and urban residence: adults 65 and older own wearables at roughly one-fifth the rate of adults under 25. Ownership in the lowest income bracket runs at less than half the rate seen in higher brackets [113]. Smartphone ownership shows a milder version of the same gradient, and among low-income, safety-net patient populations, ownership does not reliably translate into the sustained connectivity and technical familiarity that federated participation assumes [114].

A model trained under opportunistic participation is trained on participants with compatible devices and adequate connectivity, and that population skews younger, wealthier, better educated, and more urban than the patient population the model is meant to serve. Elderly patients, who carry the heaviest burden of the chronic conditions this paper’s use cases target, are among the least likely to contribute training data under this architecture.

Declining to provision new hardware makes FMCL’s carbon accounting favorable under the model in Section 4.4. In a population with low device penetration, though, closing the equity gap requires provisioning that accounting was built to avoid. This reintroduces embodied carbon that Section 4 and Section 5 otherwise exclude. Device subsidies may improve participation among underserved populations. Proposition 8 represents their embodied carbon through an additive term, and the associated operational, participation, and convergence effects remain outside the model. Differential incentive structures that raise the value of participation for underrepresented groups, and hybrid deployments that supplement dedicated edge infrastructure in low-penetration regions, both partly mitigate it.

Proposition 8 (coverage-sustainability trade-off).

Let π denote the fraction of the target patient population owning a compatible, sufficiently connected device, and let the embodied-carbon advantage of FMCL over dedicated edge, established in Proposition 2, hold under Assumptions 2–5 at device penetration, π. Extending coverage to the uncovered fraction$\left(1-\pi \right)$by subsidizing devices introduces an embodied-carbon term proportional to the number of devices subsidized,$\left(1-\pi \right)\cdot N$, each with embodied carbon$E_{sub}$. The coverage-adjusted lifecycle carbon is then$C^{FMCL}\left(\pi \right)=C^{FMCL}+\left(1-\pi \right)\cdot N\cdot E_{sub}$, which, holding the baseline FMCL lifecycle carbon and per-device subsidy footprint constant, strictly decreases as existing device penetration, π, rises toward 1: populations that already have the least organic access face the steepest carbon cost to reach full coverage.

Under this linear subsidy model, increasing subsidized coverage increases embodied carbon, so the resulting carbon objective may conflict with an equity objective that favors full coverage. Effects that increasing π could have on participation, convergence, or communication energy are not captured here.

Remark 8.

Under the stated linear cost model, every device added to close the coverage gap costs one embodied-carbon unit,$E_{sub}$, regardless of how the rest of the fleet behaves. There is no scale effect that would make equitable expansion cheaper per device. Figure 7 plots the coverage-adjusted carbon over the full range of coverage. Potential mitigation strategies include a shared subsidy pool amortized across multiple health systems, or targeted device donations from already decommissioned but functional hardware, which would substitute reuse for new manufacture even during the subsidy term.

Figure 7. Lifecycle carbon vs. device coverage under Proposition 8 (illustrative).

7.6. Model Currency and Accountability Under Diffused Participation

Two further risks follow from the same property that makes FMCL sustainable: infrequent training can leave the deployed model out of date, and training happens across a population of devices outside the operator’s direct hardware administration.

The first is staleness. Section 4 and Section 5 establish that FMCL’s carbon advantage grows as training frequency falls, and Proposition 5’s convergence tolerance shows that FMCL can absorb a substantial multiple of the rounds a comparably accurate cross-silo model would need before that advantage erodes. The carbon analysis does not determine whether the deployed model remains clinically current. Clinical guidelines, diagnostic codes, treatment patterns, and a population’s baseline physiological patterns can all shift, including during a novel epidemic, in ways no amount of local computation on unchanged data will capture [115]. A model retrained continuously on an institutional cross-silo network incorporates these shifts as they occur, while one retrained on a lower-frequency, carbon-favorable schedule incorporates them only after a longer delay, a cost this analysis does not price.

Corollary 1 (joint frequency-currency condition).

Let$f^{\ast }$denote the carbon-crossover frequency of Proposition 4 and let$f_{min}$denote the minimum retraining frequency clinical currency requires for a given condition, as discussed above. FMCL is simultaneously carbon-favorable and clinically current if and only if$f_{min}<f^{\ast }$, that is, the clinical requirement falls within the carbon-favorable frequency range rather than exceeding it; at equality, the two are at carbon parity. Where$f_{min}>f^{\ast }$, the deployment faces a conflict: retraining at the cadence that clinical currency requires means forfeiting part or all of the carbon advantage established in Section 5, and the frequency threshold is a carbon-optimal bound rather than a clinically sufficient one. Both frequencies count training rounds per unit time: a retraining campaign that needs R, rounds, and recurs c times per year corresponds to f = cR, so a cadence stated in campaigns must be converted before it is compared with f∗.

Whether a use case of Section 6.3 satisfies $f_{min}<f^{\ast }$ depends on deployment-specific drift in the modeled condition, the availability of labels, and the governance requirements on retraining cadence, none of which this paper estimates.

The second is accountability. Institutional cross-silo FL preserves a clear chain of custody: every contributing node is a hospital or clinic with a name, a data protection officer, and a contractual relationship with the model’s operator. A failure can therefore be traced to its source and excluded. FMCL distributes participation across individuals who lack this institutional contractual relationship: a device owner who lets their phone train overnight while it charges has not signed a data-processing agreement and cannot reasonably be held responsible for how the aggregate model behaves. The system operator retains that responsibility regardless of where computation occurred, but auditing which participants contributed to a specific model version is considerably harder across an anonymous population of consumer devices than across known institutional partners. Existing regulatory frameworks, including HIPAA, GDPR, and the emerging EU AI Act, were built with institutional accountability chains in mind and have not been tested against an architecture that disperses training across participants who are, from a governance standpoint, essentially anonymous [116].

Clinical deployment requires a governance layer (participant registration, audit logging, and a defined escalation path) that the base architecture described in Section 4 does not supply on its own.

7.7. Conditions Under Which Alternative Architectures Are Preferable

Dedicated clinical edge deployment becomes preferable under several conditions. The AI model may be large enough that training on patient hardware would require prohibitive numbers of rounds. Regulatory frameworks may mandate certified medical-grade hardware at each training node, as for an FDA-cleared diagnostic device. Inference latency requirements may be tight enough to require always-on local compute, as in an ICU deterioration alert. The grid carbon intensity at the aggregation server may be substantially lower than at participant device locations, reversing the operational carbon comparison. The institution may already operate spare edge capacity, which removes the procurement term and most of the idle term from the comparison (Section 5.3.3).

Cloud deployment warrants reconsideration when patient-data-governance constraints can be satisfied through synthetic data generation, federated transfer learning from pre-trained models, or institutional data-sharing agreements between hospitals, each of which can reduce the need for distributed training in specific settings. Cloud-based inference following centralized training may be architecturally simpler and, in some configurations, environmentally comparable to FMCL for low-volume clinical use cases.

8. Open Research Challenges

8.1. Carbon-Aware Scheduling and Participant Selection

The FMCL selection score is energy-aware but not carbon-aware: it does not currently weight candidates by grid carbon intensity, which varies hourly. A carbon-aware version would therefore need to address both which participants to recruit and when. Carbon-aware schedulers already defer training into lower-carbon windows [64,65], but their reported savings are largest for small recruited populations and shrink as the population grows. This is a specific problem for healthcare, where the recruited population needs to reflect clinical diversity and not only avoid excluding individual clients. A scheduling policy for FMCL would need to weight representativeness separately from carbon and fairness, and evaluate them at the population sizes that healthcare FL actually uses. The selection experiment of Section 5.2.4 does not test a carbon-aware score, which would need an accounting that resolves per-device energy and location-specific intensity, and candidate pools larger than the cohort.

8.2. Embodied Carbon Estimation for Consumer-Device Workloads

FMCL’s primary accounting convention attributes a device’s embodied carbon to its original purpose rather than to its share of compute cycles (Section 3.2). Section 5.2.6 recomputes the architecture comparison under an alternative, calendar-time convention, which allocates embodied carbon to a workload in proportion to its share of a device’s rated service life, and finds that it changes the ranking: cloud-only, rather than FMCL, has the lowest footprint once embodied carbon is amortized this way. What that convention does not provide is a standardized usage-based methodology applicable beyond this paper’s own calculation. One candidate methodology for usage-based allocation exists outside the FL literature: the Software Carbon Intensity (SCI) specification, now ISO/IEC 21031:2024 [117], already allocates embodied carbon to software by usage share. It has not been evaluated against a population of heterogeneous consumer devices with no single controlling party, and manufacturers do not publish workload-level power draw at the granularity it would need [12]. Adapting the specification and securing manufacturer disclosure of the data it would need remain open questions.

8.3. Standardized Sustainability Metrics for Distributed AI

Even a validated allocation method establishes only what one deployment reports, not whether its results are comparable with those of another. One model-based estimate puts FL’s carbon cost at up to two orders of magnitude above centralized training [86]; a separate field measurement across millions of devices found client-side computation and communication dominated emissions [87]. These are not measuring the same thing, and without a shared standard neither can be checked against the other. SCI [117] is the closest existing candidate, already an ISO standard, but it has not yet been evaluated for cross-device federated settings where no single party instruments the hardware. The EU AI Act’s energy-documentation rules, phasing in from 2025, do not yet specify what that documentation must contain either, and their relationship to HIPAA, GDPR, and medical-device approval pathways is unsettled for clinical deployments that use heterogeneous patient-owned devices.

8.4. Multi-Objective Optimization Across Conflicting Sustainability Dimensions

Accuracy, fairness, and clinical representativeness must be balanced against objectives that minimize carbon and communication energy: recruiting for representativeness can mean pulling in devices on high-carbon grids, and cutting communication energy can cost accuracy. Standard FL aggregation does not explicitly represent this multi-objective trade-off, treating sustainability as something to check afterward rather than trade off against accuracy directly. Pareto-optimal FL work exists [118] but stops short of carbon as an explicit axis; folding carbon-aware scheduling, embodied-carbon attribution, and clinical representativeness into one frontier remains unresolved.

8.5. Incentive Ecosystem Design for Sustainable Participation

FMCL’s case depends on voluntary contribution from device owners who may receive no direct individual benefit, and the mHealth literature shows participation decaying over time even among motivated participants [81]. Three constraints make this harder than standard FL incentive design: incentives strong enough to matter risk selection bias, participation must stay voluntary and revocable under GDPR and HIPAA, and the mechanism must be cheap enough to operate and administer, or it undermines the sustainability case it serves.

8.6. Retraining-Trigger Theory Under Carbon and Clinical-Currency Constraints

The frequency threshold from Section 5 specifies how often training can occur before the carbon advantage erodes; it does not specify when the deployed model has drifted far enough from clinical reality to warrant an additional round. Developing such a trigger requires drift detection that works without centralized data access, a way to weigh the carbon cost of an extra round against the clinical cost of a missed one, and a decision rule stable under noisy drift signals.

9. Limitations and Future Scope for Healthcare Deployment

9.1. Limitations

The model covers the distributed learning architecture but excludes the environmental costs of data collection (acquiring training data, operating sensing networks, and maintaining data pipelines), clinical validation, regulatory review, and model monitoring. These activities may contribute materially to the total lifecycle footprint. Model architecture optimization, hardware co-design, and specialized AI accelerators are considered only insofar as they affect the energy and embodied carbon of the broader system.

This scope may need to be revisited as consumer devices acquire capabilities previously associated with dedicated accelerators. Such devices could eventually support diagnostic models that are currently deployed on dedicated edge systems. Flagship smartphones already carry NPUs delivering tens of TOPS [75], and on-device large-model inference on mobile NPU and GPU hardware is now an active research area [75,76]. The reuse-first argument holds only so long as this capability remains incidental to the device’s primary purpose rather than a feature provisioned with federated participation in mind. If manufacturers begin marketing on-device AI capacity as a service to third parties, the embodied-carbon attribution FMCL relies on would need re-examination.

The accounting is further limited to carbon: it does not capture water consumption in semiconductor fabrication, or the geopolitical and environmental costs of extracting critical minerals such as gallium, rare earth elements, and high-purity silicon. These costs are drawing increasing scrutiny as AI infrastructure scales [119], and that scrutiny extends to a health system’s own procurement decisions.

The lifecycle comparison is model-based and parametric, and the only learning experiment is the client-selection comparison in Section 5.2.4, a preliminary evaluation of optimization behavior that does not test the architecture-level lifecycle comparison. The lifecycle model has not been validated against an instrumented healthcare FMCL deployment. The case studies in Section 6 are illustrative and report no measured outcomes. The incentive and governance discussion in Section 4.5 and Section 8.5 is conceptual, and empirical data on long-term participation in healthcare FMCL systems at scale is not yet available.

The computational experiment uses one architecture on one dataset and scores the global model mainly on a sample of the pooled training data and, in one exploratory condition, on nine held-out recordings from a single split. Both policies reach their targets with a classifier that recognizes only two of five classes, so the results concern optimization speed and not diagnostic performance. Carbon is priced through round counts and not metered energy, so carbon to target is proportional to rounds to target and the experiment does not resolve differences in per-round energy between the policies.

The experiment trains without differential-privacy noise and without adversarial clients, so its rounds to target are those of an honest, noiseless deployment. It omits the additional rounds that Proposition 3 attributes to privacy noise and that a robust aggregator may cost (Section 7.3.1), and it does not measure exposure to poisoning or membership inference, which needs a threat model and attack implementations of its own and is treated analytically here.

A further practical constraint exists at the operating-system level: mobile operating systems increasingly restrict background execution and throttle battery-intensive processes by default. These OS-level and manufacturer-level battery-management policies can silently terminate or delay FMCL training rounds independent of user intent or consent [120]. These implementation constraints are not represented in the present model.

The model treats grid carbon intensity as a known input (Assumption 4). In practice, intensity varies at sub-hourly timescales and is forecast with nontrivial uncertainty, and the deployment may not know in advance which grid regions its participants will occupy. These uncertainties affect the aggregate carbon estimate and may alter scheduling decisions. Their interaction with training quality has not been characterized, and the carbon-savings estimates referenced in Section 8.1 are simulation-based, not measured in production healthcare settings.

Healthcare FMCL’s participation model requires patients to own smartphones with sufficient computational capability, adequate connectivity (Wi-Fi preferred), and consistent overnight charging behavior. These conditions correlate with income, age, digital literacy, and geography (Section 7.5), so the results apply most directly to populations that meet them, and equity is not an explicit term in the present carbon accounting.

9.2. Future Scope

A deployment study, most plausibly in cardiac monitoring, given the maturity of wearable ECG technology and the established FL literature in that domain, should measure client- and server-side energy, participant-location carbon intensity, round completion, and model performance over clinically meaningful time periods. These measurements would permit evaluation of the principal accounting assumptions under operational conditions.

The same study would measure what this paper treats analytically: the round-count cost of device-level privacy noise and of robust aggregation, and exposure to poisoning and membership inference under a realistic participant population. It would also measure the battery degradation attributable to participation, which sets the wear term of Section 5.3.1 and which the present analysis can only bound.

The formal accounting model and most worked examples assume high smartphone penetration and reliable Wi-Fi. Evaluations in low-resource settings should examine how device access, connectivity, participation scheduling, and incentive structures affect the lifecycle-carbon comparison.

10. Conclusions

FMCL is a reuse-based architecture for healthcare FL, and its applicability depends on device availability, workload characteristics, connectivity, participation reliability, and governance. The illustrative use cases do not establish clinical effectiveness.

The accounting results depend on how embodied carbon is allocated. FMCL had lower modeled lifecycle carbon than the dedicated-edge reference configuration under all three allocation conventions at the reference parameterization and throughout the reported one-way sweeps. Under jointly varied inputs, it kept that advantage in 93.9% of 20,000 sampled scenarios, a fraction that is not a probability of superiority in any deployment.

These comparisons are with edge hardware procured for the campaign; against servers that already exist, FMCL had the lower footprint in 16.9% of the joint scenarios. Against cloud training, FMCL leads under marginal allocation at the reference parameterization, but in only 43.3% of the joint scenarios, and device wear of about 0.7% of a device’s remaining life reverses the comparison.

The computational experiment is a preliminary evaluation of convergence under two client-selection policies and does not test the architecture-level comparison. Energy-aware and random client selection reached the balanced-accuracy target in 25.2 and 26.6 rounds on average (paired difference, −1.4 rounds; 95% confidence interval, −8.4 to +6.2), so no difference was detected. A replication run and two exploratory conditions, higher availability and held-out recordings, likewise detected no difference at the 0.05 level; however, at higher availability, energy-aware selection needed fewer rounds in eight of ten seeds. Every condition met its target with a classifier that recognizes only normal and ventricular beats, so the results concern optimization speed and not diagnostic performance. Privacy noise, adversarial participants, and measured device wear remain to be tested in deployment.