MARGARITA MONTAÑEZ DAVENPORT · WEARABLE HEALTH DATA · A WORKING DEMONSTRATION
Being the only holder of a consent record is a liability, not an asset.
This working demonstration takes fitness-tracker readings, formats them the way health systems exchange data (FHIR), and puts a signed permission record in front of them — held by the person who granted access, not only by the app. It runs on Sepolia testnet: no real funds, and the only thing published is a fingerprint of the consent record. Read how it was built, watch it run, or connect a wallet and reproduce every claim on this page.
Most published blockchain-consent designs stop at architecture — proposed, simulated, or piloted, not deployed.
This one runs. LIVE
Connecting a wallet is optional — every section and clip works without one. The live verification path is for reviewers reproducing the claims.
Sample health data is used; none is collected from you.
Readings are formatted as FHIR R4 Observations — the common format hospitals and health apps use to exchange data.
This layer shows the data flowing; the consent layer answers who authorized it.
Why this matters
The consent record lives with whoever benefits from it; the person who gave it holds only a confirmation email.
- Proving the negative: "I never authorized that" needs a record of what was authorized.
- Surviving the vendor: the Fitbit migration kept data, not consent history.
- Changing providers: re-consenting from scratch leaves old authorizations unauditable.
- Filing a complaint: an OCR or state privacy request needs dates and scope.
- Research participation: proof of enrollment consent and withdrawal date.
- Legal and family disputes: behavioral health disclosures surface in custody and employment matters.
A company's proof of consent is its own database record — the weakest evidence in a dispute, because the company wrote it. A participant-signed, verifiable record is stronger, and the company did not build it.
- Data never held cannot be breached; short read windows narrow breach notices.
- Audits: proof of scope and timing, not log exports.
- Consent survives migrations — Fitbit's reset every downstream app.
- Right of access: the participant already holds the record the entity must produce.
Covers the consent and disclosure record — not the clinical chart or trial data.
This does not remove HIPAA obligations; scope depends on the entity and its data, not on how consent is recorded. It changes exposure and proof.
- Less to lose: short read windows leave less data to breach, disclose, or subpoena.
- Evidence already owed: disclosure accounting and right-of-access answers exist; the participant retrieves them.
- De-identification is separate: it depends on what is in the data, not how consent is stored.
Most consumer wearable data is already outside HIPAA, under the FTC Health Breach Notification Rule instead.
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; the integrity layer answers whether it can be verified independently.
The record is stored in this browser only; clearing browser data removes it.
Sign a consent grant first.
This layer shows the anchored root and the match state; the revoke action shows withdrawal.
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 is in the screenshots below.
Searching for wallets…
Connect a wallet to sign a consent grant and verify it on-chain.
Wallet — An app holding a secret key only you have. It can stamp a message so anyone can check it came from you.Wallet login — You prove it's you by stamping with your key. No password sits on a company's computer, so none can be stolen.
Choosing a wallet
- Coinbase Smart Wallet — best for first-timers: passkey-based, no seed phrase, recovers through your device.
- Rainbow — easiest for reviewers who already have a wallet.
- Brave Wallet — built into Brave; seed phrase, and losing it loses the account.
- MetaMask — most widely used; seed-phrase recovery.
Disconnect here ends the session; fully revoke access in your wallet's settings.
This page asks your wallet to switch to Sepolia automatically — approve the prompt.
Getting test funds
Sepolia is the test version of Ethereum; its money is not real. Signing a consent grant is free — test ETH is needed only to anchor on-chain.
Two free faucets: the Google Cloud Sepolia Faucet (instant, but the Google sign-in publicly links your identity to the address) and the Sepolia PoW Faucet (no account; your browser does the work).
Anchoring writes the Merkle root to your own address slot on MerkleAnchor (Sepolia). It costs testnet gas 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; 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 — it happened at a specific moment and cannot be undone or backdated.
- From — the participant’s own address; the person published this themselves.
- To — the MerkleAnchor contract with its verified badge; anyone can read its public source.
- The decoded event — RootAnchored, root
0x72251e2d…3fe1a4, matching the root the dashboard computes. - Gas used — a fraction of a testnet cent; nothing bought, sold, or transferred.
- What is NOT here — no health data, no consent text, no provider name; only a fingerprint. By design.
The linked transaction is the one in the screenshots, so a reader can compare them directly.
Current state
How wearable data sharing works today
A user taps "allow," the app stores that permission through the vendor's OAuth flow, and the record of what was agreed lives with the vendor. 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 — shared with every 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
When an integration goes live, someone owns "what is this app authorized to read, and since when" — today that is OAuth-server state, with no history. Onboarding re-asks consent; migrations void authorizations; a downstream consumer cannot show its basis for receiving data.
Here the grant is a history-bearing record held by the grantor: explicit scope, timestamped revocation.
Thirty years in clinical practice is why I watched these failures rather than imagined them.
Where this applies
The demonstration runs on wearables; the gap is not wearable-specific.
| Pain point | Where it shows up | What this layer does | Status |
|---|---|---|---|
| Vendor-held consent | Fitbit deprecation — tokens did not transfer | Signed grant survives the vendor | DEMONSTRATED HERE |
| Same failure on Android | Google Fit APIs deprecated for Health Connect | Platform-independent mechanism | SAME MECHANISM |
| Portable consent | No cross-app authorization trail | Signed scope, revocation history | DEMONSTRATED HERE |
| Provenance | Authorization basis does not travel with FHIR | Consent travels as an event | ARCHITECTURE |
| Consent across EHRs | Authorization unreadable across systems | Participant-held record | ARCHITECTURE |
| Network audit trail | TEFCA individual-access exchange | Participant-signed, verifiable grants | NOT BUILT |
ARCHITECTURE and NOT BUILT rows are where the primitive would apply, not claims of what exists.
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 and the record remains. 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 can sign a consent grant. Passkey-backed smart accounts remove the seed phrase entirely.
The same problem in clinical trials
Trials collect consent electronically (eConsent; 45 CFR 46.117, 2018). FDA-regulated records must meet 21 CFR Part 11: time-stamped audit trails (§11.10(e)) and signatures linked to records (§11.70). Amendments force re-consent per version; withdrawal (45 CFR 46.116(b)(8)) must be evidenced.
Here the grant is participant-signed with a versioned scope, and revocation preserves history.
Not validated, not through Part 11 validation, not used in any trial — a mechanism demonstration.
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
- 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.