The quoted Washington text permits sharing health data with consent separate and distinct from the consent obtained. A caregiver app should treat each data type separately, share only what the older adult agreed to in plain terms, and test its revocation path. The quoted text also refers to how the consumer can withdraw consent.
If your device watches over an older adult, the family app is where the data model gets tested. Product and firmware leads must decide what the caregiver sees by default, what needs the older adult's own opt-in, and what happens when that person changes their mind. This guide gives a data-by-audience matrix and a revocation state machine as design inputs. It is an engineering summary of quoted text for general wellness products. It gives no legal advice and covers no medical device use. It covers adults and older adults only, and assumes the older adult gives consent and can see every sharing path.
What do the quoted sources say?
These are the only legal texts this page relies on. Each was read on October 31, 2026. We quote them so you can check the wording yourself.
| Source | What it says | Link |
|---|---|---|
| 15 U.S.C. 45 | The statute states the test: "the act or practice causes or is likely to cause substantial injury to consumers which is not reasonably avoidable by consumers themselves and not outweighed by countervailing benefits to consumers or to competition." | Original text, as of October 31, 2026 |
| RCW 19.373.030 (sharing consent) | The quoted text reads: "With consent from the consumer for such sharing that is separate and distinct from the consent obtained". | Original text, as of October 31, 2026 |
| RCW 19.373.030 (withdrawal) | The quoted text refers to "how the consumer can withdraw consent from future collection or sharing of the consumer's health data." | Original text, as of October 31, 2026 |
| RCW 19.373.010 (definition) | The definition of consumer health data reaches "bodily functions, vital signs, symptoms, or measurements" of the described information. | Original text, as of October 31, 2026 |
| 16 CFR Part 318 | A breach of security is "acquisition of such information without the authorization of the individual." Whether the rule applies to your product is a legal question this page does not answer. | Original text, as of October 31, 2026 |
This page quotes only the breach definition from 16 CFR Part 318. Whether the rule applies to your product is a question for counsel. We did not fetch HHS guidance on consumer devices or the California definition of sensitive data, so this page says nothing about HIPAA or the CCPA.
Which data should the family see?
The right-hand three columns below are our design proposals. No quoted source requires them. The second column ties each row to the quoted Washington definition where the text supports it, and marks the rest as open questions.
| Data type | Scope tag (WA text) | Default for the caregiver | Consent to build | On revoke |
|---|---|---|---|---|
| Fall alert | Inferred from motion sensor data. The quoted text does not address inferred data. Open legal question; treat it as sensitive in design. | Share with named caregivers once the older adult has agreed to alerts. | Opt-in during setup, in the older adult's own words and screen. | Alerts stop on revoke. Queued alerts are dropped and never delivered. |
| Heart-rate trend | A vital sign. The quoted definition names "vital signs", so treat it as in scope and confirm with counsel. | Do not share by default. Show it only after a separate opt-in. | Separate consent from collection, with the withdrawal path shown in the request. | Caregiver view empties on revoke. The device may keep collecting for the older adult's own use. |
| Location | The sources quoted on this page do not address location. Treat it as an open legal question. | Do not share by default. Offer "share while an alert is open" as a separate choice. | Separate opt-in, plus a visible on-device or in-app indicator while sharing is on. | Sharing stops on revoke. Cached last-known positions are removed from the caregiver app. |
| Voice (audio and transcripts) | The quoted text does not address audio or transcripts. Open legal question; treat it as sensitive in design. | Never share by default. Keep recording visible, with an indicator light and a spoken or on-screen notice. | Separate opt-in for each use. Do not build covert capture. | Stop capture and sharing at the same moment. Delete buffered clips that were not yet sent. |
| Sleep summary | A bodily function measurement. The quoted definition names "bodily functions", so treat it as in scope and confirm with counsel. | Do not share by default. Offer a summary view and keep raw sensor traces on the device. | Separate opt-in. | Caregiver summaries disappear on revoke. |
| Medication-reminder acknowledgment | Whether this is health data is a legal question. Treat it as sensitive in design. | Share only "acknowledged or not", and only after opt-in. | Separate opt-in, with the caregiver named. | Acknowledgments stop flowing on revoke. History is hidden from the caregiver app. |
Collection and sharing are different decisions. The device can collect a heart-rate trend for the older adult's own screen while the caregiver sees nothing. Keep that split in your schema, so a sharing grant is a separate record from a collection setting.
How should revocation work?
The quoted Washington text refers to how the consumer can withdraw consent from future collection or sharing. The states below make a withdrawal path concrete as a design proposal. Run one state machine per pair of data type and caregiver, so that revoking one grant does not touch the others.
| State | What is true | Event that leaves it | Next state |
|---|---|---|---|
| Not shared | Default after setup. The device collects for the older adult's own use only. | Older adult opts in for a named caregiver and a named data type. | Sharing |
| Sharing | The caregiver app receives that data type. The older adult sees who has access and can open the revoke control from the device or the phone. | Older adult taps revoke. Or the caregiver removes themselves. | Revoking |
| Revoking | The device and cloud stop new uploads, and flush or drop any buffered ones by a rule you chose in advance. The caregiver app shows "access ended" and nothing new. | Cloud confirms no further delivery for that pair. | Not shared |
| Revoking, device offline | The revoke is recorded on the phone or cloud, and the device receives it on reconnect. Decide in advance whether the cloud refuses buffered uploads that arrive after the revoke time. | Device reconnects and acknowledges the revoke. | Not shared |
The hard cases are the in-between ones: a revoke made while the device is offline, and data already queued on the device. Write down the rule for each before you build, and test it on your own hardware.
What are the common traps?
These follow from the quoted text and the matrix. They are engineering reasoning. None of them describes an incident at a real company.
- One toggle for "family sharing". The quoted Washington text refers to consent for sharing that is "separate and distinct from the consent obtained". Counsel should confirm how it applies. A single switch that bundles collection, sharing and every data type cannot show that separation. This is engineering reasoning from the quote.
- A caregiver who set up the device and also clicked consent. The quoted Washington text frames consent as the consumer's. If the caregiver taps accept during setup, the older adult's agreement is not recorded. Design the consent step so the older adult performs it, and log who did.
- Revocation that stops the screen but not the pipeline. The quoted text refers to how the consumer can withdraw consent from future collection or sharing. A revoke that hides data in the app while the device keeps uploading to the caregiver account leaves the sharing running. Check both ends.
- Buffered uploads after a revoke. A device that was offline when the older adult revoked may flush queued data on reconnect. Whether that data reaches the caregiver is a design decision you must make and test, because no source gives the answer for you.
- Silent access by a new caregiver. Adding a caregiver to a family group and inheriting the old caregiver's permissions is sharing nobody agreed to. The breach definition in 16 CFR Part 318 reads acquisition "without the authorization of the individual", and whether it applies to you is for counsel. The design lesson is that each grant should name its recipient.
- Sharing the older adult cannot see. Any sharing path the older adult cannot see, such as a listening mode without an indicator, removes the consent the rest of the design depends on. Do not build it.
What should you measure on your own board?
Revocation latency and offline behavior depend on your firmware, your radio and your backend. No result appears in this article, so measure them on your own board.
| What to measure | How to instrument or collect it | Raw data to record |
|---|---|---|
| Revocation latency | Timestamp the revoke tap on the phone, the cloud write, the device acknowledgment and the last caregiver-side delivery. Run it with the device online and with the device in each connectivity state you support. | Revoke event time, each hop timestamp, last data timestamp visible to the caregiver, build version. |
| Buffered uploads after revoke | Take the device offline, collect each data type, revoke, then reconnect. Watch what reaches the caregiver account and when. | Queue contents before reconnect, server receive log, caregiver app view after reconnect. |
| Offline-device revoke | Revoke from the phone while the device is unreachable. Record the state the device reports on reconnect and whether it keeps collecting for the caregiver. | State transitions with timestamps, device log, cloud log. |
| Per-type isolation | Grant one data type, then check that no other type reaches the caregiver app or its notifications. | Payload captures per type, caregiver app screenshots, notification content. |
| Consent record | Complete setup with the older adult and with a caregiver acting alone. Confirm the consent record shows who accepted, which type, which recipient, and which text version. | Consent records exported from the backend, text version identifiers, screenshots of the consent screens. |
| New caregiver access | Add a second caregiver and confirm the first caregiver's grants are not inherited. | Permission table before and after, caregiver app views for each account. |
Set the pass line yourself from your product requirements, and record the basis for it before you run the test.
What should you think through before you choose?
Take this list to your team and to any counsel reviewing the data model.
- Does the older adult, and nobody else, perform every consent step, and does our record prove it?
- Which data types are collected on the device but never shared, and is that visible to the older adult?
- For each data type, is the default "not shared", and who decided that?
- Does our consent request say how to withdraw, in the same place where consent is given?
- What happens to buffered data when a revoke arrives, and where is that rule written?
- What does the caregiver app show after a revoke, and can any cached data still be read?
- Which rows in the matrix has counsel reviewed, and which are still our guesses?
- Can the older adult see at any time who has access to what?
- Is there any sharing path with no indicator, and if so, why does it exist?
- Which of these assumptions have we measured on our own build, and which are guesses?
Questions about caregiver data sharing
Is this legal advice?
No. This is an engineering team's summary of quoted statute and rule text, with links to the originals. It does not constitute legal advice. Have counsel review your data model, your consent text and your state coverage.
Does the Washington law apply to my product?
This page does not decide that. It quotes the text on consent for sharing, the reference to withdrawal and the health data definition from RCW 19.373.030 and RCW 19.373.010 (accessed 2026-10-31) as design inputs. Applicability is a question for counsel.
Why does the matrix say "open legal question" for some rows?
Because the text we fetched does not address them. We did not retrieve federal HIPAA guidance for consumer devices or the California definition text, so this page makes no claims about either.
Can a caregiver consent for an older adult?
The sources here frame consent as the consumer's. This page designs for the older adult giving consent. Any case where someone else acts for an adult, such as a legal guardian, is a legal question to settle with counsel before you build it.
Is this a medical device guide?
No. This is an engineering overview for general wellness products. It does not cover diagnosis, treatment or any medical use. For how we scope companion devices, see AI companion device development.
If you are defining the data model for an elder or companion device, tell us about your device. You can also read how our engineering approach handles app, cloud and data ownership.
Sources
All pages accessed October 31, 2026. Engineering summary only. It does not constitute legal advice.
- Cornell Legal Information Institute, 15 U.S.C. 45: https://www.law.cornell.edu/uscode/text/15/45 (accessed 2026-10-31)
- Washington State Legislature, RCW 19.373.030: https://app.leg.wa.gov/RCW/default.aspx?cite=19.373.030 (accessed 2026-10-31)
- Washington State Legislature, RCW 19.373.010: https://app.leg.wa.gov/RCW/default.aspx?cite=19.373.010 (accessed 2026-10-31)
- eCFR, 16 CFR Part 318: https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-318 (accessed 2026-10-31)
Planning an AI companion or elder-care device? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →