How to Build a Telehealth Platform With Integrated Vitals

The global telehealth market hit $186 billion in 2025, according to Fortune Business Insights, and is on pace for $219 billion in 2026. Those numbers track spending on video visits, asynchronous messaging, remote triage, and the platforms that hold it all together. What they don't capture is the growing gap between what telehealth platforms promise and what they actually measure. Most video visits still produce zero objective health data. The clinician sees a face on a screen, asks questions, and documents subjective findings. To build a telehealth platform with integrated vitals that captures real biometric data during the visit itself changes the clinical value of every session.

"Remote photoplethysmography extracts cardiovascular signals from ordinary video by detecting subtle color changes in facial skin caused by blood volume pulses. The same camera feed used for a video call contains enough information to estimate heart rate, respiratory rate, and blood oxygen saturation." — Verkruysse, Svaasand, and Nelson, Optics Express, 2008 (foundational rPPG study, cited in over 1,400 subsequent papers)

Why telehealth platforms need native vital signs

The telehealth visit without vitals is an incomplete encounter. Clinicians know this. A 2024 survey published in the Journal of Telemedicine and Telecare found that 67% of physicians reported lower diagnostic confidence in virtual visits compared to in-person, with the absence of vital signs cited as the primary reason. That confidence gap limits what conditions get treated virtually and pushes patients back to in-person visits for things that could have been handled remotely.

Adding vitals changes the math. When a patient's heart rate, respiratory rate, HRV, and SpO2 are captured during the video visit, the clinician has objective data to work with. Chronic care follow-ups become more meaningful. Post-surgical check-ins produce actual measurements. Mental health sessions can correlate physiological stress markers with patient-reported symptoms.

The technology exists to do this without asking patients to buy hardware. Camera-based physiological measurement, specifically rPPG, extracts vital signs from the same front-facing camera the patient is already using for the video call. No pulse oximeter, no blood pressure cuff, no wearable. The patient sits in front of their phone or laptop, and the platform captures vitals passively.

Architecture decisions that matter

Building a telehealth platform with integrated vitals requires making a few architecture calls early. Get these wrong and you'll spend months refactoring.

Where the measurement runs

The rPPG processing can happen client-side (on the patient's device), server-side (processing the video stream in the cloud), or in a hybrid model. Each has real trade-offs.

Architecture	Latency	Privacy	Device requirements	Bandwidth cost	Offline support
Client-side SDK	Low (sub-200ms)	Strong (video stays on device)	Moderate (needs processing power)	None additional	Yes
Server-side processing	Higher (network round-trip)	Weaker (video transmitted)	Low (thin client)	High (streaming video)	No
Hybrid (client extraction, server analysis)	Medium	Moderate	Low-moderate	Low (sends signals, not video)	Partial

Most production telehealth platforms choose client-side SDK integration. The privacy argument alone usually settles it. Sending raw video to a server for vital sign extraction creates HIPAA headaches that nobody wants, and the bandwidth costs add up when you're processing thousands of concurrent sessions.

The Circadify SDK, for example, runs entirely on-device. The camera feed never leaves the patient's phone or laptop. The SDK extracts the vital sign signals locally and sends only the processed measurements (heart rate values, SpO2 percentages, waveform data) to the platform's backend. As covered in our SDK getting started guide, this on-device approach also means measurements work on spotty connections, which matters for rural telehealth programs.

When to capture vitals in the visit flow

There are two schools of thought here, and I've seen platforms succeed with both.

Pre-visit capture runs the vital sign scan before the clinician joins. The patient opens the app, completes a 30-second face scan in a guided flow, and the results are waiting in the chart when the doctor connects. This approach is cleaner from a UX perspective. The patient knows they're being measured and cooperates (holds still, faces the camera). The measurements tend to be more reliable because the patient isn't talking or moving.

During-visit capture runs the rPPG analysis on the live video feed throughout the session. This is more ambitious technically but produces richer data. You get continuous heart rate and HRV trends over a 15-minute visit, not just a single point measurement. The trade-off is signal quality. When the patient talks, gestures, or shifts in their seat, the rPPG signal degrades. Good SDKs handle this with motion artifact rejection, but there will always be gaps in the continuous stream.

The pragmatic move is to support both. Run a clean pre-visit scan for baseline measurements, then optionally capture continuous trends during the visit for clinicians who want that data.

Data format and EHR integration

This is where most telehealth startups underestimate the work. Capturing vital signs is one thing. Getting those measurements into the patient's medical record in a format that other systems understand is another project entirely.

HL7 FHIR (Fast Healthcare Interoperability Resources) is the standard. A 2025 review in JMIR Medical Informatics confirmed that FHIR R4 has become the baseline for vital signs interoperability across U.S. health systems, driven partly by CMS interoperability mandates and the ONC's Cures Act Final Rule. Your vital sign measurements need to map to FHIR Observation resources with proper LOINC coding.

Here's what that looks like in practice:

Vital sign	LOINC code	FHIR resource type	Unit
Heart rate	8867-4	Observation	beats/min
Respiratory rate	9279-1	Observation	breaths/min
Blood oxygen (SpO2)	2708-6	Observation	%
Blood pressure (systolic)	8480-6	Observation	mmHg
Blood pressure (diastolic)	8462-4	Observation	mmHg
Heart rate variability (SDNN)	80404-7	Observation	ms

If your SDK provider gives you raw numbers without FHIR-ready output, you'll need a mapping layer. Some SDKs include FHIR bundles in their API responses. Others leave that to the platform developer. Check before you commit to an integration.

The technology stack for vitals-enabled telehealth

A working telehealth platform with integrated vitals typically has five layers. Not all of them are unique to vitals-enabled platforms, but the interaction between them is.

Video infrastructure

WebRTC for real-time video. Twilio, Vonage, or Agora for the managed service, or roll your own if you have the team. The important thing: the rPPG SDK needs access to the raw camera frames, not just the encoded video stream. If your video pipeline compresses frames before the SDK can process them, you'll lose signal quality. Most SDKs hook into the camera feed at the capture layer, before encoding.

rPPG measurement SDK

This is the layer that turns camera frames into vital sign measurements. It runs on the patient's device and outputs structured data. The Circadify API reference covers the specific endpoints and data formats. Key capabilities to look for: real-time streaming mode for continuous capture, batch mode for point-in-time scans, and motion artifact detection that tells you when a measurement is unreliable rather than silently returning bad data.

Clinical data service

A backend service that receives vital sign measurements, validates them against clinical ranges, stores them with proper timestamps and patient context, and serves them to the clinician's interface. This layer also handles alerting. If a patient's SpO2 drops below 92% during the visit, the clinician should see that flagged immediately.

EHR integration layer

FHIR APIs connecting to Epic, Cerner (now Oracle Health), Athenahealth, or whatever EHR the health system uses. Dr. Amy Avakian and colleagues at UCLA published a 2025 framework in Cureus for automated vital sign integration with cloud-based EMRs, describing a middleware approach that normalizes measurements from different source devices (including camera-based systems) into a single FHIR-compliant pipeline. That kind of middleware layer becomes necessary when your platform needs to work across multiple health systems with different EHR configurations.

Patient-facing application

The mobile or web app where the patient actually has the visit. The UX challenge here is making the vital sign capture feel seamless rather than clinical. The best implementations run the measurement transparently. The patient sees their vitals appear on screen during the waiting room experience or during the visit itself, but the process of capturing them requires no extra steps.

What the research says about camera-based vitals in telehealth

The academic literature on rPPG has grown rapidly. A 2025 systematic review in Frontiers in Digital Health found that 81.4% of the rPPG research bibliography was published between 2015 and 2025. The technology is mature enough for production use, but it's worth understanding where the evidence is strongest.

Heart rate measurement via rPPG is well-established. Multiple peer-reviewed studies, including work by Dr. Daniel McDuff (formerly Microsoft Research, now at Google) and Dr. Wenjin Wang at Philips Research, have demonstrated accuracy within 1-2 BPM of contact-based sensors under controlled conditions. Respiratory rate estimation is slightly less precise but clinically useful for trend monitoring. SpO2 estimation via camera is newer and works best as a screening tool rather than a diagnostic replacement. Blood pressure estimation from facial video remains an active research area, with promising results from teams at the University of Toronto and ETH Zurich but wider confidence intervals than traditional cuffs.

For telehealth platform builders, the practical takeaway: heart rate, respiratory rate, and HRV are ready for clinical workflows today. SpO2 is useful for screening and trending. Blood pressure should be positioned as an estimate, not a measurement.

Regulatory and compliance considerations

Telehealth platforms operate under a web of regulations. Adding vital signs introduces new ones.

HIPAA applies to the vital sign data the same way it applies to any PHI. If your SDK processes data on-device and only transmits measurements (not video), you've simplified your compliance story. The measurements themselves are still PHI and need encryption in transit and at rest.

FDA clearance is the bigger question. The FDA has been evolving its approach to software as a medical device (SaMD). General wellness claims (stress tracking, fitness monitoring) don't require clearance. Clinical diagnostic claims (detecting atrial fibrillation, diagnosing hypertension) do. Where your platform sits on that spectrum determines your regulatory path. Many telehealth platforms position camera-based vitals as wellness and trending tools that supplement clinical judgment rather than replace diagnostic devices.

CMS reimbursement for remote physiological monitoring (RPM) codes 99453-99458 can apply to camera-based vital sign capture, but the billing rules require specific documentation and the data must be collected on FDA-cleared devices for some payers. This is evolving, and the rules differ by payer and state.

Frequently asked questions

Can rPPG measure vitals accurately through a telehealth video call?

Yes, for heart rate and respiratory rate, accuracy is comparable to contact sensors when the patient is reasonably still and well-lit. The rPPG signal is extracted from subtle color changes in facial skin, and modern SDKs include algorithms to handle common real-world conditions like movement and variable lighting. SpO2 estimation works as a screening tool. The quality depends heavily on the SDK implementation and the device camera.

Do patients need special hardware for vitals-enabled telehealth?

No. That's the whole point of rPPG integration. The patient uses the same smartphone or laptop camera they already use for video visits. No wearables, no pulse oximeters, no additional equipment. The SDK processes the existing camera feed.

How long does a vital sign measurement take?

A dedicated scan typically takes 30 seconds of the patient sitting still and facing the camera. Continuous monitoring during a video visit captures data throughout the session, though signal quality varies with patient movement and talking.

What EHR systems support camera-based vital sign data?

Any EHR that accepts FHIR Observation resources can receive camera-based vital signs. The data format is identical to measurements from traditional devices. Epic, Oracle Health (Cerner), and Athenahealth all support FHIR-based vital sign ingestion through their standard APIs.

Where this goes from here

The telehealth platforms being built right now will look different from the ones built during the pandemic rush. The first generation focused on video connectivity. The second generation is adding clinical intelligence, and vital signs are the most immediate form of that intelligence.

Circadify is building the SDK layer that makes this possible for development teams that want to add contactless vitals without building measurement infrastructure from scratch. If you're architecting a telehealth platform and evaluating how vitals fit into your stack, the developer documentation at circadify.com/custom-builds covers the integration paths in detail.

The technology is here. The reimbursement codes exist. The patient experience is frictionless. The remaining question for telehealth builders is whether to treat vitals as a differentiator now or a commodity later.