Boojee Companion Care
Privacy & Data Protection

Because the consumer product sits outside HIPAA by default, the laws that govern it are the FTC and the state consumer-health-data statutes — and two of them carry a private right of action, which is where the litigation risk lives.

1 · Washington My Health My Data Act (MHMDA) — top litigation risk

Our mood, loneliness, depression, anxiety, screening scores, crisis flags, and voice are all "consumer health data" under the Act's very broad definition (RCW 19.373). MHMDA requires separate, opt-in consent; a dedicated Consumer Health Data Privacy Policy linked from the homepage; no sale without a distinct authorization; an honest list of who data is shared with; working deletion; and it bans geofencing. It has a private right of action — the first class actions were filed in 2025.

2 · Illinois BIPA (voice) — strict, statutory damages

BIPA regulates voiceprints with a private right of action and $1,000–$5,000 statutory damages. Our defense is a speech-to-text-only, no-voiceprint, discard-the-audio design — we do not identify anyone by voice. We add belt-and-suspenders written (e-signature) voice-processing consent anyway. This becomes a serious problem if voice ID or vocal biomarkers are ever added.

3 · FTC Health Breach Notification Rule — the tracker trap

The 2024 amendments (effective July 29, 2024) cover exactly this kind of health app, and a "breach" now includes an unauthorized disclosure — meaning sending health data to an ad or analytics vendor is itself a federally reportable breach (individuals + FTC within 60 days; media at 500+). This is why no ad/analytics trackers touch the companion surfaces.

HIPAA regulates who holds data, not "health information." It applies only to Covered Entities and their Business Associates.

• Consumer / direct-to-consumer (default): Boojee is neither — HIPAA does not apply. The FTC Act, FTC Health Breach Notification Rule, and state consumer-health-data laws govern instead. We do not claim "HIPAA compliant."
• Payer/provider channel: if Boojee delivers check-ins/screenings on behalf of a health plan or provider, it becomes a Business Associate — requiring a signed BAA with the client and a downstream BAA with AWS (currently NOT_EXECUTED), plus the Security/Privacy/Breach Rules and minimum-necessary.

Already in the backend / design

• Consent lifecycle API (grant / withdraw / get) + dedicated consent table.
• Audit log table for accountability.
• Minimized data schema — no SSN, financial, or extraneous PII.
• No-voiceprint, speech-to-text-only design; no geofencing; no sale path — strong, defensible negatives.
• HTTPS everywhere (encryption in transit).

Must build before a real launch

• Data-subject delete & export — user-facing UI — the backend now implements both delete_user_data (hard-deletes all personal data across all 7 care tables, CCPA/MHMDA/GDPR-compliant) and export_user_data (portable JSON of all records). Backend: implemented. What remains: user-facing buttons (delete, export, withdraw-consent) wired into the member interface. See privacy-analysis.md §Errata and the Trust & Evidence Center for the reconciled status.
• Separate plain-language consent UI that actually gates collection, plus user-facing withdraw/delete/export buttons.
• Capacity gate + surrogate-consent path for older adults who may lack decisional capacity.
• Retention TTL on DynamoDB records + confirmed audio-discard.
• Correction workflow + identity verification for rights requests; Global Privacy Control handling.
• DPIA/DPA documents + a written incident-response / breach runbook (72h GDPR / 60d FTC-HIPAA).
• AWS BAA (and client BAAs) before any PHI / payer channel.
• Confirm encryption-at-rest KMS, IAM least-privilege, and no trackers on companion pages.

The companion uses Amazon Polly (text-to-speech output — not biometric) and speech recognition (voice input). The narrow legal question is whether we create a voiceprint used to identify a person. We do not.

• We do not enroll, extract, store, or match speaker-recognition templates.
• We discard raw audio after transcription; we keep only the text needed for the check-in/screening.
• We document the negative in the policy and DPIA — the factual basis for the position that BIPA/CUBI/WA biometric duties are not triggered.

• Adding voice ID / authentication — creates a biometric identifier → full BIPA-grade consent + retention schedule required.
• Vocal-biomarker health inference from voice characteristics — same trap, plus MHMDA biometric-data provisions attach.