MARGARITA MONTAÑEZ DAVENPORT · WEARABLE HEALTH DATA · A WORKING DEMONSTRATION
Being the only holder of a consent record is a liability, not an asset.
You keep your record. The user gets one too — signed by them, and neither of you can rewrite it.
This is a working demonstration. It takes fitness-tracker readings, formats them the way health systems exchange data, and puts a signed permission record in front of it — one the person who granted access holds themselves. You can read how it was built, watch it run, or connect a wallet and reproduce every claim on this page.
The same pattern runs through every system where one party grants another permission — health data, a bank account, a background check, a benefits enrollment, any "allow this app" screen. The record of that grant is kept by the party who received it, because the party who received it built the system. Wearable health data is where this demonstration runs, since the stakes of a disputed disclosure are highest where the data is most sensitive. The layer itself never touches the data; it records one event, so it moves between domains without redesign.
A user taps "allow." If that consent is ever disputed, the only evidence is the app's own database entry. This page shows what changes when the user holds a signed copy too.
Most published blockchain-consent designs stop at architecture — proposed, simulated, or piloted, not deployed.
This one runs. LIVE
The consent signature, the chain write, and the read-back are live — verifiable from this page, right now. The wearable readings are sample data pending API credentials.
This runs on Sepolia testnet. No real funds, no purchase, no cryptocurrency changes hands. The only thing published is a fingerprint of a consent record.
The layer is built on a blockchain, but only to do one job: hold a fingerprint of the consent record somewhere no single party can change it afterward. A database would work for storage, but a database belongs to whoever runs it. No health data goes on the blockchain. No money is involved. Only the fingerprint.
Full context
What follows is a normal-looking health dashboard, then the consent record underneath it, then the proof that record has not been altered.
Most work on patient-controlled health consent has stayed in the research phase. A 2025 systematic review of the field found that adoption remains largely conceptual or proof-of-concept, usually tested on simulated data rather than in real systems.
This is a working demonstration of how wearable health data moves today, and one layer added on top of it. The data comes from a fitness tracker. The layer gives the person who generated it a signed, verifiable record of who they shared it with. What is demonstrated here is a scaffold, not a single product: the login, consent record, attestation, and dashboard are the same regardless of which metrics are collected or what they are collected for.
Connecting a wallet is optional. You can read every section, view the architecture, and watch the recorded clips without connecting. The live verification path is for reviewers who want to reproduce the claims themselves.
Sample health data is used. No real health data is collected from you.
Readings are formatted as FHIR R4 Observations — FHIR is the common format hospitals and health apps use to exchange health data, so a reading from one system means the same thing in another.
Where does a user's wearable data go, and who can read it? This layer shows the data flowing. It does not show who authorized the flow or whether that authorization is verifiable — which is what the consent layer answers.
Why this matters
In every current system the consent record lives with the party that benefits from the consent — the clinic, the app vendor, the study sponsor. The person who gave it holds nothing but a confirmation email.
- Proving the negative: "I never authorized that" is unprovable without a record of what the participant did authorize.
- Surviving the vendor: the Fitbit migration preserved data, not consent history.
- Changing providers: re-consenting from scratch leaves prior authorizations unauditable.
- Filing a complaint: an OCR or state privacy request needs dates and scope, not recollection.
- Research participation: proof of enrollment consent and withdrawal date, currently held by the study.
- Legal and family disputes: behavioral health disclosures surface in custody and employment matters, where who authorized what and when is what's contested.
Behavioral health was chosen as the build case because the stakes of a disputed disclosure are highest where the data is most stigmatized.
Today a company's proof of consent is its own database record. In a dispute, that record is the weakest possible evidence, because the company wrote it. A consent record signed by the participant, timestamped independently, and verifiable by anyone is stronger evidence — and the company did not have to build or maintain it.
- Data the company never holds cannot be breached. The recipient reads for a short window rather than keeping a copy, which narrows what a breach notification would cover.
- Audits get cheaper. An OCR inquiry, IRB review, or state request is answered with proof of scope and timing rather than screenshots and log exports.
- Consent survives platform changes. When Fitbit moved infrastructure, every downstream app lost its consent state and had to re-ask. Portable consent means an acquisition or replatform does not reset the user base.
- It protects both sides. The same record that shows a participant did not authorize something also shows when they did.
- It removes a staffed task. HIPAA requires a covered entity to tell a patient who received their information and when, on request — today that means reconstructing history from logs by hand. Here the participant already holds that record and can retrieve it themselves. Records-request fulfillment is a real cost center, and right of access is the most enforced provision in HIPAA.
- Protocol amendments force re-consent. A site must show which consent version each participant agreed to and when. Today that is a paper trail assembled per participant, per amendment.
- Inspection readiness. Consent findings are among the costliest audit outcomes, and the evidence is currently reconstructed by hand.
- Withdrawal has to be evidenced. Both the participant and the sponsor need a record of when access ended, and neither holds one the other did not write.
Participant-controlled consent is not something a company gives up. It is the company no longer being the sole custodian of the truth about what was agreed.
This covers the consent and disclosure record — not the clinical chart, and not trial data itself.
This does not remove HIPAA obligations. Scope is set by who the entity is and what data it handles, not by how consent is recorded. What it changes is how much the organization is exposed to and how easily it can prove compliance.
- Less to lose: the recipient reads for a short window rather than keeping a copy, so there is less data sitting in the organization's systems to breach, disclose, or produce under subpoena.
- Evidence already owed: accounting of disclosures and right-of-access responses are existing obligations that today take staff time. Here the record already exists and the participant can retrieve it.
- De-identification is separate: taking data out of scope entirely is a question of what is in the data, not how consent is stored.
For consumer wearables, most of this data is already outside HIPAA and governed by the FTC Health Breach Notification Rule instead — which is why participant-held consent matters here specifically.
Connect a wallet and sign a consent grant to populate this layer.
Watch: connecting a wallet and signing a consent grant.
This layer shows the signed grant. It does not show whether that grant can be independently verified or whether the consent history has been tampered with — which is what the integrity layer answers.
This record is stored in this browser only. It does not sync, and clearing browser data removes it.
Sign a consent grant first.
This layer shows the anchored root and the match state. It does not show what happens when consent is withdrawn — which is what the revoke action answers.
Anchoring — Posting that fingerprint publicly, so nobody can quietly swap the list later and claim it always said something else. Including us.Public ledger — A record thousands of computers keep at the same time, so no single company owns it or can edit it.
Watch: anchoring that consent record on-chain. The confirmed transaction and its decoded event are in the screenshots below.
Connect a wallet to sign a consent grant and verify it on-chain.
Wallet — An app on your phone or in your browser that holds a secret key. Only you have it. Most people know wallets from cryptocurrency, but the key does something else too: it can stamp a message so everyone knows the message came from you.Wallet login — Instead of a username and password stored on a company's computer, you prove it's you by stamping with your key. The key never leaves your device, so there's no password for anyone to steal.
Choosing a wallet
Wallets differ in how recovery works, and that difference is a tradeoff between convenience and independence. Neither end is correct in the abstract.
- Coinbase Smart Wallet (recommended for anyone new) — passkey-based (a passkey is the fingerprint or face unlock that is replacing passwords — your phone holds the secret and never sends it anywhere). No seed phrase. The key syncs through your device keychain, so recovery works like any other app. Easiest to start with. Tradeoff: your key is tied to a device ecosystem, so Apple or Google is part of the picture.
- Brave Wallet — built into the Brave browser, nothing to install. Self-custody with a seed phrase. Lose the phrase, lose the account.
- MetaMask — most widely used. Also self-custody with a seed phrase, same recovery consequence.
It does not matter to this system which you choose. The consent layer accepts any key that can sign. The wallet picker has no allowlist, so a passkey account and a seed-phrase account produce equally valid consent records. The choice is the participant's, not the platform's.
Getting test funds
Ethereum — Thousands of computers around the world keep the same list, and they check each other constantly. Anyone can add to the list. Nobody can go back and change what's already on it. Adding costs a small fee, paid in something called ETH.
Sepolia — Sepolia is the test version of Ethereum. Developers use it to try things out before doing them for real. The money on it isn't real and can't be traded for anything. This page runs on Sepolia, so nothing here costs anyone anything.
When you need it: connecting and signing a consent grant is free and needs no funds at all. You only need test ETH if you want to anchor your own root on-chain, which is optional. Everything else on this page works with an empty wallet.
Getting onto Sepolia: most wallets hide test networks by default. MetaMask: Settings → Advanced → Show test networks. Brave Wallet: same pattern under network settings. Coinbase Smart Wallet: handled for you. This page will ask your wallet to switch to Sepolia automatically — approve the prompt.
Two ways to get test ETH (both free):
Instant, requires an account: Google Cloud Sepolia Faucet — sign in with Google, paste your address, receive funds in seconds.
No account needed: Sepolia PoW Faucet — paste your address and leave the tab open for a few minutes. Your browser quietly does the network's math in the background; when it has done enough, you claim your test ETH. Nothing is asked of you and nothing about you is recorded.
Why it matters which one you use: the first faucet asks you to sign in with Google, which permanently links your real identity to this address. On a public ledger that link does not expire — anyone able to connect the two can see every consent grant this address ever signs. The second asks nothing about who you are, so no link exists to find.
For a demonstration this hardly matters. For someone sharing behavioral health data, it matters a great deal: privacy on a public ledger comes from what you attach to your address, not from the ledger itself.
Test ETH has no monetary value and cannot be bought, sold, or converted. It exists so developers can test without spending money.
Anchoring writes the Merkle root to your own address slot on MerkleAnchor (Sepolia). It costs testnet gas (the fee paid to write something to the network — on Sepolia it is free and worthless; on the real network it is real money) only — no real funds. The root is stored at roots(your address) and can be read by anyone.
Your wallet may show a simulation warning — the contract is verified on Blockscout, which some wallets do not read. The transaction is valid.
What the proof looks like
Details tab — covers points 1, 2, 3 and 5 below.
Transaction details on Blockscout — covers points 1, 2, 3 and 5 below. Transaction 0x929310…dad808 on Ethereum Sepolia.
Logs tab — covers point 4.
The decoded event log — covers point 4. The root value here is the one the dashboard computes.
- Status and block — this happened at a specific point in time and cannot be undone or backdated.
- From — the participant's own address. Not the platform's, not a server's. The person published this themselves.
- To — the MerkleAnchor contract, showing its verified badge. Anyone can read exactly what the code does, because the source is public.
- The decoded event — RootAnchored, with root value
0x72251e2d…3fe1a4. This matches the root the dashboard computes from the stored consent record — verified against the event, the on-chain read, and the live page. - Gas used — a fraction of a testnet cent. Nothing was bought, sold, or transferred.
- What is NOT here — no health data, no consent text, no provider name. Only a fingerprint. Anyone can confirm something was published at that moment and has not changed, and learn nothing about what it was unless the participant chooses to show them. That is the design, not a limitation.
The transaction linked above is the one shown in the screenshots, so a reader can compare them directly.
Current state
How wearable data sharing works today
A user taps "allow" in a health app, the app stores that permission through the vendor's OAuth flow (the "allow this app to connect" screen everyone has seen a hundred times — the user taps allow, and the app gets permission to read something on their behalf), and the record of what they agreed to lives with the vendor. The user can revoke access through the vendor's settings, but neither the user nor the recipient gets a durable record of what was granted, when, or when it was revoked.
What breaks
Fitbit's Web API is deprecated, with a September 2026 cutoff. The gap table below shows what that exposes — and what it shares with every other vendor-held consent model.
| Gap | Evidence | Who feels it | Impact |
|---|---|---|---|
| Consent state is vendor-held | The September 2026 Fitbit deprecation requires every user to re-consent because Fitbit tokens do not transfer. The user did not revoke anything — the vendor changed infrastructure. | Participants, developers who built on the Fitbit API | Every consent decision made through Fitbit is lost. No programmatic migration path for consent state. |
| Scope is coarser than user intent | Google Health scopes grant category-level access. A user who wants to share step count but not caloric intake cannot express that distinction. | Participants with mixed comfort levels, researchers needing narrow consent for ethics review | Users over-share relative to their preference because the scope boundary is wider than their intent. |
| Revocation is opaque to the recipient | When a user revokes access, the app's next API call returns a 401. There is no revocation event, no timestamp, and no record the recipient can cite. | Clinicians and researchers who need to demonstrate when access ended, IRB reviewers | Neither party can prove when access was revoked. Consent history exists only as inferred from API access patterns. |
| No portable consent record survives platform migration | When Fitbit was deprecated, the history of which apps a user had authorized disappeared with the OAuth server. Google's migration preserved the data but not the consent metadata. | Researchers conducting longitudinal studies, participants wanting a record of who they granted access to | Consent history is coupled to the vendor's infrastructure. A migration, acquisition, or shutdown erases it. |
Where this lands operationally
Who fields the question
When a partner integration goes live, someone owns the answer to "what is this app authorized to read, and since when." Today that answer lives in an OAuth server's state, which is a point-in-time fact with no history behind it.
What breaks at the seams
Partner onboarding repeats consent capture because the prior grant is not portable. A vendor migration voids authorizations that were never the user's to keep. A downstream consumer cannot demonstrate the basis on which it received data — only that it received it.
What changes
The authorization becomes a record with a history, held by the person who granted it and readable by anyone they show it to. Scope is explicit rather than inferred from a token. Revocation is an event with a timestamp rather than a state change nobody logged.
What does not change
The API stays. The OAuth flow stays. Data stays where it is. Nothing enters the request path, and a failure in this layer does not affect a single user-facing operation.
Thirty years in clinical practice is why the failure modes above are ones I watched rather than ones I imagined.
Where this applies
The demonstration runs on wearable data, but the gap it closes is not specific to wearables.
| Pain point | Where it shows up | What this layer does | Status |
|---|---|---|---|
| Consent state held by the vendor | Fitbit's Web API deprecation — OAuth tokens did not transfer and every downstream app had to re-ask | The grant is signed by the participant and survives the vendor | DEMONSTRATED HERE |
| The same failure on Android | Google Fit's REST APIs deprecated in favour of Health Connect, with apps rebuilding permission and sync logic | Same mechanism, no dependency on which platform holds the data | SAME MECHANISM |
| Portable, checkable consent | Data moving between apps and platforms with no way to establish who authorized what, when | A signed record with explicit scope and a revocation history | DEMONSTRATED HERE |
| Interoperability without provenance | FHIR is widely adopted, but the authorization basis under which data was collected does not travel with it | Consent recorded as an event that can accompany the data | ARCHITECTURE |
| Consent across multiple EHRs | A patient's authorization at one system is unreadable at the next | The record is held by the participant rather than any single system | ARCHITECTURE |
| Network-level audit trail | TEFCA's individual access exchange purpose requires establishing who authorized a request across participants | Participant-signed grants with an independently verifiable history | NOT BUILT |
Rows marked ARCHITECTURE or NOT BUILT are not claims about what exists. They are where the same primitive would apply.
What I added
The consent layer
The consent grant is signed by the participant's wallet, not stored on the vendor's server. The vendor can shut down entirely — the consent record remains intact because it was never stored there. Revocation adds an entry to the permission tree, recomputes the root, and can be anchored on-chain.
Signing — You tap approve, and your key stamps the message. Anyone can check the stamp is really yours, and nobody can fake it or change the message afterward without breaking the stamp. That's the only thing your key is used for here. Nothing is bought or sold.The access-token model
The consent signature authorizes a token scoped to one metric with a 15-minute expiry. Expired or revoked tokens return nothing. Revoking consent invalidates all tokens immediately.
Where this is going
Passkeys are replacing passwords; the same key material that authenticates a user can sign a consent grant. Passkey-backed smart accounts remove the seed phrase entirely.
The same problem in clinical trials
Clinical trials use electronic informed consent — eConsent — to present study information and collect a participant's agreement to enroll. The revised Common Rule (45 CFR 46.117, 2018) explicitly authorizes electronic signatures for informed consent. For FDA-regulated trials, electronic consent records must also satisfy 21 CFR Part 11, which requires secure, computer-generated, time-stamped audit trails for every action that creates, modifies, or deletes an electronic record (§11.10(e)), and requires that electronic signatures be linked to their records so they cannot be excised, copied, or transferred (§11.70).
The version problem
Protocols amend. When they do, participants must re-consent to the updated version. A site must be able to show which version each participant consented to and when — and that evidence currently lives in the site's own system, assembled per participant, per amendment.
The withdrawal problem
A participant can withdraw at any time without penalty (45 CFR 46.116(b)(8)). The trial must evidence when access ended. Both the participant and the sponsor need a record of that event, and neither currently holds one the other did not write.
What this layer does about both
The consent grant is signed by the participant, not the site. The scope field names what was consented to — including a version identifier. Revocation is an entry in the permission tree rather than a deletion, so the history of grants and withdrawals is preserved and verifiable without the sponsor's own database being the only witness.
This is not a validated system, has not been through 21 CFR Part 11 validation, and is not in use in any trial. It demonstrates the mechanism — signed consent, versioned scope, evidenced withdrawal, independent verifiability — against a live chain, not a production trial.
Future scope
- Passkey-backed smart accounts NOT BUILT — Biometric replaces seed phrase; no extension, no crypto vocabulary.
- Per-metric consent scopes NOT BUILT — Share activity data without sharing cardiac data.
- Proving completeness NOT BUILT — Selective disclosure works; proving the set is complete is an open problem.
- Payment rails NOT BUILT — Consent primitive authorizes compensation; authorization and payment share one record.
- Real-world cost — One fingerprint per day, Layer 2 reduces fees further, the organization pays.
How this gets adopted
- Stage 1 — Consent attestation. Signed, verifiable consent events. Data stays in existing systems. BUILT
- Stage 2 — Access instead of export. Recipients read for a bounded window rather than receiving a copy. NOT BUILT
- Stage 3 — Progressive decentralization. Custody changes, designed with institutions. Years out. NOT BUILT
The common failure in this space is leading with stage three.
What adopting stage one involves
Stage one is additive. Nothing in an existing product has to move.
- What stays the same: data, OAuth flow, and the app's own consent record.
- What gets added: a signature step, a user-held permission record, one periodic ledger write.
- What it touches: wherever consent is recorded — a handful of code paths, not architecture.
- What it does not require: no new database, no chain in the request path, no cryptocurrency.
Last verified August 2026. Regulation in this area changes quickly.
HIPAA generally does not cover consumer wearable data. A wearable feeding a consumer app is typically neither a covered entity nor a business associate, so the protections most people assume are in place do not apply. Coverage comes instead from the FTC Health Breach Notification Rule and state law.
- HIPAA Privacy Rule — governs use and disclosure of protected health information by covered entities. hhs.gov
- HIPAA Security Rule — requires safeguards for electronic protected health information. hhs.gov
- 21st Century Cures Act (2016) — prohibited information blocking, penalties up to $1M per violation. congress.gov
- ONC HTI-1 Final Rule (2024) — required FHIR-based APIs, USCDI v3 baseline. healthit.gov
- FTC Health Breach Notification Rule (16 CFR Part 318) — covers consumer health apps outside HIPAA. Does not apply to HIPAA-covered entities (§318.1(a)). 2024 amendments clarified health app developer coverage.
16 CFR Part 318 (eCFR) · FTC rule page · 2024 amendments - Washington My Health My Data Act (2023) — first comprehensive state consumer health data law. Effective July 23, 2023. leg.wa.gov
- GDPR (EU, 2018) — explicit consent, data portability, right to erasure for personal data including health. gdpr.eu
- CCPA/CPRA (California, 2023) — consumer data rights. Note: exempts certain medical information. oag.ca.gov
- 21 CFR Part 11 — electronic records and electronic signatures. Audit trails (§11.10(e)), signature linking (§11.70), revision control (§11.10(k)). ecfr.gov
- 45 CFR 46 (Common Rule, revised 2018) — informed consent, including electronic format (§46.117). Withdrawal without penalty (§46.116(b)(8)). ecfr.gov
- 21 CFR Part 50 — informed consent for FDA-regulated clinical investigations. ecfr.gov
What this does not solve
- Revocation stops future access but cannot recall data already received.
- Selective disclosure works — a Merkle proof reveals one grant, nothing else.
- Proving completeness does not — a participant cannot yet prove no grants were withheld.
- De-identification is separate — this covers consent records, not the data itself.