Data Privacy in the Circadify SDK: Architecture and Compliance

Health data is the most expensive data to lose. IBM's 2024 Cost of a Data Breach Report put the average healthcare breach at $9.77 million, up again from the year before. Healthcare has topped every other industry in breach costs since 2011. When developers integrate a vitals SDK into their application, the privacy architecture of that SDK becomes their privacy architecture. Whatever the SDK collects, transmits, and stores is now on them. Data privacy in the Circadify SDK architecture matters because it determines how much compliance work the integrator inherits.

"The most effective privacy strategy is to avoid collecting sensitive data in the first place. When biometric processing happens on-device, you eliminate entire categories of risk that no amount of encryption can address after the fact." — Dr. Latanya Sweeney, Harvard University, former Chief Technologist for the FTC

How on-device processing changes the privacy equation

The standard approach to health data collection goes like this: capture raw data on the device, ship it to a cloud server, process it there, store the results, send computed values back to the client. Every step is an exposure point. The data crosses network boundaries, sits in transit buffers, lands on servers that need their own security posture, and spawns copies that have to be tracked and eventually deleted.

On-device processing collapses most of that chain. The camera captures video frames, the SDK processes them locally on the device's CPU and GPU, and vital sign values come out the other end. Heart rate, respiratory rate, blood oxygen, stress — all computed on the phone. Raw video frames never leave the device. Only the final numbers get transmitted, and even that is optional depending on how the integrator builds their application.

That difference is not cosmetic. A 2025 paper in the World Journal of Advanced Research and Reviews found that on-device architectures reduced data exposure surface area by over 90% compared to cloud-first approaches. Edge processing also eliminated latency-related privacy risks — the kind where sensitive data sits in transmission queues waiting its turn.

The Circadify SDK follows this model. Signal extraction, blood volume pulse analysis, heart rate calculation, HRV computation — all local. The integrating application receives numbers, not raw biometric data. The developer never handles facial video, never stores camera frames on their servers, never has to build infrastructure to protect raw biometric input.

Architecture model	Raw biometric data transmitted	Server-side storage required	Data exposure surface	Compliance complexity	Breach risk category
Cloud-first processing	Yes — video frames sent to servers	Yes — raw + processed data	High	High — must secure transmission + storage + processing	Raw biometric data at risk
Hybrid (edge + cloud)	Partial — some preprocessing on device	Yes — partially processed data	Medium	Medium — reduced raw data but still handles biometrics	Processed biometric data at risk
On-device SDK (Circadify model)	No — only computed values optionally sent	Optional — numerical results only	Low	Lower — no raw biometric handling needed	Numerical health metrics only
Fully offline	No data transmitted	No server involvement	Minimal	Minimal — no external data flow	Device-local only

HIPAA and what it means for SDK integrators

HIPAA applies when an entity handles protected health information in connection with covered health activities. For developers building health applications, the question is whether the vitals data their app collects counts as PHI. If the application is used in a clinical context, by a covered entity, or in connection with health plan activities, the answer is almost always yes.

HIPAA's Security Rule requires administrative, physical, and technical safeguards for electronic PHI. Section 45 CFR § 164.312 spells out access controls, audit controls, integrity controls, and transmission security. For SDK integrators, the SDK needs to support these requirements at the architectural level — documentation alone doesn't cut it.

The 2025 proposed HIPAA updates, analyzed by researchers at CharlesIT among others, pushed toward stronger encryption mandates, explicit multifactor authentication requirements, and stricter network segmentation for ePHI systems. Regulators are making it plain: they want privacy enforced by technical architecture, not just written policies.

An on-device SDK simplifies HIPAA compliance in concrete ways. The facial video never leaves the device, so it never enters the integrator's infrastructure as ePHI. Computed values like a heart rate of 72 bpm or an HRV score may still qualify as health information if linked to an identifiable individual, but the risk profile is different. Encrypting a number in transit is straightforward. Protecting a raw facial video stream crossing network boundaries is a much harder problem.

The HIPAA Journal reported that 2025 saw 32 fewer large healthcare breaches and nearly 79% fewer individuals affected compared to the prior year. Some of that improvement traces to better architectural decisions — including wider adoption of edge processing and data minimization in health technology stacks.

What integrators still need to handle

The on-device architecture takes the hardest biometric security problems off the integrator's plate, but it doesn't eliminate all HIPAA obligations. If the application stores computed vital sign values alongside patient identifiers, those records are ePHI. The integrator still needs:

• Encryption at rest for stored health data
• Access controls with unique user identification
• Audit logging for data access events
• A Business Associate Agreement with any third party that handles the data
• Breach notification procedures

The SDK can't enforce these application-level requirements, but it can avoid creating additional compliance burdens through its own data handling.

GDPR and biometric data as a special category

GDPR treats biometric data as a special category under Article 9. When biometric data is processed to uniquely identify a person, it gets the highest level of protection the regulation offers. Penalties for mishandling special category data can reach €20 million or 4% of annual global turnover, whichever is higher.

For an rPPG SDK, the key question is whether the facial video processing constitutes biometric data processing under GDPR. The answer depends on purpose. If the SDK processes facial video to extract vital signs (not to identify the person), the facial video processing may fall outside Article 9's scope for biometric identification. However, the UK's Information Commissioner's Office guidance notes that if biometric data is used to "learn something about an individual," it likely qualifies as special category data regardless of the identification question.

On-device processing maps directly onto GDPR's data minimization principle (Article 5(1)(c)), which requires personal data to be "adequate, relevant, and limited to what is necessary." An SDK that processes facial video locally and only exports numbers is minimizing personal data by design. The facial video exists transiently in device memory during the scan and gets discarded after processing.

Article 25's privacy by design requirement says data protection should be built into the technology, not bolted on after the fact. The European Data Protection Board has been consistent on this: privacy by design means the system's default behavior protects personal data. An on-device SDK meets that standard through its architecture, not through policy documents.

Regulation	Scope	Biometric data treatment	Key obligation for SDK integrators	On-device advantage
HIPAA (US)	Covered entities and business associates	PHI when linked to individual	Technical safeguards, BAAs, breach notification	Raw biometric data never enters integrator infrastructure
GDPR (EU/EEA)	Any entity processing EU residents' data	Special category under Article 9	Lawful basis, DPIA, data minimization, privacy by design	Structural data minimization; transient processing only
PIPEDA (Canada)	Private-sector organizations	Sensitive personal information	Consent, limited collection, retention limits	Reduced collection footprint; no server-side biometric storage
LGPD (Brazil)	Any entity processing Brazilian residents' data	Sensitive personal data	Explicit consent, purpose limitation, security measures	Minimal sensitive data in integrator's environment
POPIA (South Africa)	Any entity processing personal info in SA	Special personal information	Prior authorization or exemption, security safeguards	Reduced exposure of special personal information

The data flow in practice

Here is what actually happens during a scan when a developer has integrated the Circadify SDK:

The user taps scan in the host application. The SDK activates the camera and starts capturing frames. Those frames feed into the on-device rPPG algorithms in real time. The SDK picks up blood volume pulse signals from subtle skin color changes that track cardiac cycles, then computes heart rate, respiratory rate, HRV, blood oxygen estimation, and stress indicators from that signal.

Raw video frames live in a rolling buffer and get discarded after each computational cycle. They are not written to storage, not cached, not queued for later transmission. Once the vitals are computed, the SDK hands those numbers to the host application through its API. What happens to those numbers after that is the integrator's call.

Because of this architecture, the SDK itself does not need to function as a HIPAA-covered entity or a GDPR data processor for biometric video. It is a local computation tool. Video enters, gets processed, and is destroyed in the same memory space on the same device, all within a 30-second scan.

What about the camera permission?

A question that comes up regularly in security reviews: the SDK needs camera access, which triggers platform-level permission dialogs on iOS and Android. Apple's App Tracking Transparency framework and Google's updated privacy dashboard both show users which apps access the camera and how often.

The host application needs to justify camera access in its privacy policy and app store listing. For rPPG, the justification is simple: the camera measures health signals, it doesn't capture images, store video, or perform facial recognition. No photos or videos are saved. Say that plainly in the privacy explanation.

Data Protection Impact Assessments

Under GDPR, processing special category data usually requires a Data Protection Impact Assessment before you start. Article 35 mandates a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons."

On-device processing simplifies the DPIA considerably. The assessment still needs to cover data flows, risks, and mitigations, but when no raw biometric input is transmitted off-device, several standard risk categories shrink or disappear:

• Risk of unauthorized access during transmission: eliminated (no transmission of raw data)
• Risk of server-side data breach exposing biometric data: eliminated (no server-side biometric storage)
• Risk of data retention beyond purpose: reduced (transient processing only)
• Risk of re-identification from stored biometric templates: eliminated (no templates stored)

What remains are risks around the computed health values and how the integrating application handles them — all within the integrator's control.

A 2025 PMC study proposed a blockchain-based healthcare data management framework with automated compliance mechanisms. The Circadify SDK doesn't use blockchain, but the study's core finding applies broadly: the most robust compliance architectures are those where compliance is a property of the system design, not a manual process layered on top.

How this compares to cloud-based vitals SDKs

Not every vitals SDK works this way. Some send raw camera data to cloud servers for processing — the argument being that server-side hardware can run heavier models. Others use a hybrid model where preprocessing happens on-device but the actual vital sign computation needs a server round-trip.

The trade-offs go beyond privacy. Cloud processing adds latency and requires a network connection to complete the scan. Hybrid approaches still transmit partially processed biometric data that may qualify as special category data under GDPR. Fully cloud-based SDKs force the vendor to maintain HIPAA-compliant infrastructure and sign BAAs with every integrator.

Compliance workload scales with how much biometric data crosses system boundaries. An on-device SDK that exports only numbers puts the lowest burden on the integrator. Security reviews can focus on the application's own data handling instead of auditing the SDK vendor's cloud setup.

Frequently asked questions

Does the Circadify SDK store any biometric data on the device?

No. The SDK processes camera frames in a rolling memory buffer during the scan. Frames are discarded after processing, and no biometric templates, facial images, or raw video data are written to device storage. Only computed numerical values (heart rate, respiratory rate, etc.) are available to the host application.

Do I need a BAA with Circadify to use the SDK?

It depends on your application's context. If your application handles PHI and you're working with covered entities, consult your compliance team about whether the SDK's role in your architecture triggers BAA requirements. Since the SDK processes data on-device without transmitting biometric data to Circadify's servers, the analysis is different than it would be for a cloud-based SDK.

Is a DPIA required when using the SDK in the EU?

Organizations processing health data in the EU should evaluate whether a DPIA is needed based on their specific use case. The SDK's on-device architecture reduces several standard risk categories, but the overall processing context (what your application does with the computed values, how it identifies users, where it stores data) determines the DPIA requirement.

How does on-device processing work on older or lower-powered devices?

The SDK is optimized for a range of device capabilities, including lower-powered hardware. The rPPG algorithms run efficiently on mobile processors without requiring dedicated AI accelerators, though processing performance varies by device generation. The SDK performance optimization guide covers device requirements and optimization strategies in detail.

Where SDK privacy architecture is heading

The broader direction in health technology is toward what researchers call "data sovereignty" — individuals and organizations controlling where their health data lives and how it moves. Edge computing adoption in healthcare grew substantially between 2023 and 2025, pushed by regulatory pressure and the practical realization that centralizing sensitive health data creates concentrated risk.

For SDK developers and integrators, privacy architecture is becoming a product differentiator. Engineering teams evaluating vitals SDKs now ask about data flows, processing location, and compliance burden during technical evaluation, not after procurement.

The Circadify SDK was built around this reality. As regulations tighten and breach costs keep climbing, the SDKs that minimize data exposure by design are the ones that will hold up under technical and legal scrutiny. Developers building health applications can explore the SDK architecture and compliance documentation at circadify.com/custom-builds.