On-Device Processing vs Cloud: Vitals Architecture Tradeoffs

On device vs cloud vitals architecture has become a live engineering question for telehealth platforms, not a whiteboard debate. Once a team decides to add camera-based vital signs to a video visit, it has to decide where the hard work happens: on the patient's phone or laptop, in the vendor's cloud, or in some hybrid path that splits signal extraction from storage and orchestration. That choice affects latency, privacy posture, browser compatibility, operating cost, and how much control the platform keeps over the clinical workflow.

"Edge computing can reduce latency in healthcare patient monitoring by 68% to 87% compared to cloud-only approaches," according to the review "Edge Computing for Healthcare" published in 2023 on PMC.

On device vs cloud vitals architecture starts with one practical question

Where should raw video frames turn into usable physiological signals?

For telehealth teams, that question usually hides four others:

• How quickly does the clinician need a usable reading?
• How much raw video or biometric data should leave the device?
• How expensive will processing become at scale?
• How much variability can the platform tolerate across browsers, phones, and webcams?

In an on-device design, the browser, mobile app, or local SDK handles signal processing close to the camera. In a cloud design, video frames or derived streams are sent to backend services for processing. A hybrid design usually keeps the first stage local and sends summarized measurements, confidence scores, or session metadata to the backend.

McKinsey's Technology Trends Outlook 2025 does not focus on rPPG specifically, but it makes the bigger point that matters here: computing demand is rising fast, trust is becoming a board-level concern, and companies are rethinking where workloads belong. Telehealth platforms feel all three pressures at once.

| Architecture model | Main processing location | Strengths | Weak points | Best fit | |---|---|---|---|---| | On-device | Browser, phone, tablet, kiosk | Lower latency, less raw data transfer, lower cloud cost | Device variability, browser constraints, harder QA | Live visits, consumer telehealth, privacy-sensitive flows | | Cloud | Central backend or GPU service | Centralized control, easier model updates, consistent runtime | Higher latency, more bandwidth, more PHI in transit | Highly managed enterprise workflows, heavy analytics | | Hybrid | Initial extraction on device, orchestration in cloud | Balanced latency and control, easier scaling path | More architectural complexity | Most telehealth platforms building for growth |

Why latency changes the architecture conversation

Cloud-first thinking is familiar to most software teams. It simplifies release management, gives engineering one environment to monitor, and avoids the mess of debugging fifty browser-device combinations. But vital signs are not a typical API workload.

When a patient is sitting in front of a clinician, even small delays start to matter. Zahid Hasan, Emon Dey, Sreenivasan Ramasamy Ramamurthy, Nirmalya Roy, and Archan Misra made this point in their SMARTCOMP 2022 paper, "RhythmEdge: Enabling Contactless Heart Rate Estimation on the Edge." Their system was designed for real-time, contactless heart rate estimation on resource-constrained edge devices. The research matters because it showed that useful rPPG workloads do not automatically need a remote server farm to run.

That does not mean cloud processing is wrong. It means cloud processing has to earn its place. If a cloud hop adds round-trip delay, jitter, and retransmission overhead during a video visit, the platform may spend a lot of money to get a worse user experience.

Our earlier piece on WebRTC and rPPG architecture gets into the transport layer, but the short version is simple: if the visit stack already fights for stable frame timing, moving vitals extraction off device adds another moving part.

Privacy and compliance look different in each model

NIST Special Publication 1800-30, "Securing Telehealth Remote Patient Monitoring Ecosystem," is still one of the most useful anchors here. NIST's 2022 guidance stresses that telehealth and RPM systems involve multiple actors, distributed infrastructure, and a mix of people, process, and technology controls. That is exactly why architecture choices matter.

With on-device processing, the privacy argument is straightforward. Fewer raw frames need to leave the endpoint. In many deployments, the backend only receives derived measurements, timestamps, quality markers, and audit data. That can reduce exposure in transit and narrow the amount of sensitive material that lands in centralized storage.

Cloud processing changes the control surface. It can still be compliant, but the burden shifts toward secure transmission, cloud storage governance, access controls, logging, and vendor oversight. The data path gets longer. The number of systems touching sensitive content usually goes up.

NIST does not say "always process locally." That would be too simple. What it does say, in effect, is that distributed telehealth systems need explicit risk management. Teams should not assume that security will fall out of the architecture by accident.

Cost tradeoffs are less obvious than they first appear

On paper, on-device processing looks cheaper because cloud compute bills shrink. Often that is true. If every live measurement session requires backend GPU or CPU time, cloud processing can become expensive fast, especially when usage spikes during business hours across multiple provider groups.

But on-device processing is not free. Engineering teams pay in other ways:

• More QA across browsers, chipsets, camera stacks, and OS versions
• More work to optimize for weak devices and unstable lighting
• More support burden when a patient's hardware underperforms
• More product decisions around fallbacks and degraded modes

Michael Nissen and colleagues highlighted part of this in their WebPPG study, "Feasibility and Usability of Self-Performed, Browser-Based Smartphone Photoplethysmography." In their at-home experiment with 25 Android users, the browser-based system earned a strong System Usability Scale score of 82 plus or minus 9, but browser flashlight support blocked recording in nine cases. That is the reality of local processing: lower friction in one area, more edge-case behavior in another.

Cloud processing flips the equation. Runtime consistency gets better. Release control gets easier. Infrastructure cost rises.

Accuracy is not just an algorithm problem

A lot of architecture discussions get framed as if the algorithm alone determines measurement quality. In practice, architecture and accuracy are tangled together.

A 2024 Frontiers review on deep learning and remote photoplethysmography noted that illumination, camera frame rate, body motion, and equipment variation all affect rPPG performance. Those factors show up differently in on-device and cloud systems.

On-device processing can react quickly to local device state. It may adapt measurement windows, guide the patient in real time, or reject low-quality frames before sending anything upstream. That is useful.

Cloud systems, on the other hand, may benefit from more uniform inference environments, centralized observability, and easier model rollback when something breaks. That is useful too.

So the real question is not "Which architecture is more accurate?" It is closer to this: which architecture gives your team the best chance of managing measurement conditions reliably across the users you actually serve?

For many telehealth vendors, that leads to a hybrid answer. Do the first-pass extraction on device. Let the cloud handle session management, storage, analytics, audit trails, and downstream integrations.

Where each architecture works best in telehealth

On-device works best during synchronous visits

If the clinician wants a reading during the appointment, local processing usually has the edge. The patient is already using a camera-equipped endpoint, and the platform needs speed more than centralized compute control.

Cloud works best when standardization matters most

Some enterprise deployments care deeply about a controlled runtime, unified monitoring, or post-session analytics across large populations. Cloud processing can support that, especially when the measurement does not need to appear instantly.

Hybrid works best for scaling platforms

This is where many telehealth teams land after the first few design cycles. The local SDK handles time-sensitive extraction. The cloud handles policy, storage, tenant controls, EHR integration, and measurement lifecycle management. It is more complicated than picking one side, but it tends to age better.

That pattern also fits well with multi-tenant design. We explored that in our article on multi-tenant vitals architecture for telehealth SaaS platforms. Once multiple health systems are involved, cloud orchestration still matters even if the signal work starts on the endpoint.

Current research and evidence

Several sources are especially useful for teams evaluating on device vs cloud vitals architecture:

• NIST SP 1800-30 (Jennifer Cawthra and colleagues, 2022) lays out the cybersecurity and privacy issues inside telehealth RPM ecosystems and argues for a full-stack risk approach rather than a narrow tool choice.
• McKinsey's Technology Trends Outlook 2025 describes the broader computing environment: rising infrastructure demand, stronger emphasis on trust, and more pressure to place workloads intelligently.
• Michael Nissen and coauthors' WebPPG study shows that browser-based, installation-free physiological capture is practical enough to be taken seriously, even if device support remains uneven.
• Zahid Hasan, Emon Dey, Sreenivasan Ramasamy Ramamurthy, Nirmalya Roy, and Archan Misra's RhythmEdge work demonstrates that real-time contactless heart rate estimation can run on edge hardware rather than defaulting to the cloud.
• The 2023 healthcare edge computing review cited earlier reports latency improvements of 68 to 87 percent for edge-oriented patient monitoring compared with cloud-only designs.

Read together, the research does not point to one universal winner. It points to a design principle: put the time-sensitive work as close to the camera as practical, and keep the cloud for the jobs the cloud is genuinely good at.

The future of vitals architecture probably belongs to hybrid systems

Pure cloud designs feel increasingly hard to justify for live telehealth vitals. Network costs, privacy expectations, and latency constraints all push against them.

Pure on-device designs have limits too. Telehealth vendors still need centralized analytics, clinical auditability, configuration management, tenant controls, and EHR connectivity.

That leaves hybrid architecture as the most likely long-term default. Not because it sounds balanced, but because it matches how telehealth software actually operates. Real-time work stays near the endpoint. Governance, storage, and platform coordination stay in the backend.

I suspect this will become even more obvious as browser runtimes improve and WebAssembly-based inference matures. The more capable the endpoint becomes, the weaker the case for shipping raw video into the cloud just to get basic vitals back.

Frequently asked questions

Is on-device processing better for HIPAA?

Not automatically, but it can reduce risk by limiting how much raw data leaves the device. A cloud architecture can still be compliant if transmission, storage, access control, and audit practices are strong.

Why would a telehealth platform still use the cloud for vitals?

Because the cloud is useful for centralized model management, monitoring, multi-tenant controls, storage, analytics, and integrations with systems like EHRs.

Does cloud processing always hurt latency?

Not always, but it adds network dependency and usually increases round-trip time. In live telehealth workflows, that tradeoff has to be tested carefully.

What is the safest default for new telehealth platforms?

For most teams, a hybrid model is the safest starting point. It preserves low-latency measurement paths while keeping the operational benefits of a backend platform.

Telehealth platforms evaluating this space are usually not choosing between "modern" and "outdated" architecture. They are choosing where each workload belongs. Solutions like Circadify are being built around that reality, giving product and engineering teams a way to add camera-based vital signs without forcing every function into the same processing layer.