MyHealth — List of Subprocessors and Record of Processing Activities (ROPA)
Controller (LGPD Art. 5, VI / GDPR "controller"): BAS AI — BAS ARTIFICIAL INTELLIGENCE LTDA CNPJ (Brazilian company ID): 64.106.409/0001-70 Website: www.bas-ai.com Data Protection Officer (DPO) (LGPD Art. 5, VIII): Guilherme Bastian — dpo@bas-ai.com Product: MyHealth — iOS personal health-record app with an educational AI reading (pt/en/es). Document version: 2.1 — 2026-06-23
Nature of the product. MyHealth organizes your health history and offers an educational, prudent reading. It is not a medical device, does not diagnose, and does not prescribe. Every AI observation is marked "(to be confirmed)" and must be validated with your physician. The AI does not check drug interactions, does not check contraindications, and does not cross-check allergies against medications.
Distribution. MyHealth is distributed on the App Store worldwide, except in the European Union/EEA and the United Kingdom at launch. Even so, GDPR/UK-grade protections are adopted as a global baseline applied to every data subject (strictest common denominator).
Effective date. This record is in force as of 2026-06-23. The processing agreements (DPA/SCC) referenced below are signed and in force (see Section 3). The public version of this list is at https://www.bas-ai.com/myhealth/legal/subprocessadores; the version history is published at https://www.bas-ai.com/myhealth/legal/versoes, and each accepted version remains archived.
1. How to read this document
This document has two complementary parts:
- Part A — List of Subprocessors (Section 3): all third parties that process personal data on behalf of BAS AI, with role, data processed, purpose, location/international transfer, and safeguards.
- Part B — Record of Processing Activities (ROPA, Sections 4 to 7): the inventory of processing activities (GDPR Art. 30 / LGPD Art. 37 style), the purpose → legal basis → retention matrix, the retention and deletion policy, and the account/data deletion procedure.
BAS AI acts as the controller of the personal data processed in MyHealth. The third parties listed in Part A act as processors/sub-processors (LGPD Art. 5, VII / GDPR Art. 28), processing data solely under BAS AI's instructions. There are only three: Supabase, Anthropic, and Resend. Platforms and sources that act as independent controllers (Apple, Oura, WHOOP) are not subprocessors and are described in Section 3.5.
1.1 Principles governing the subprocessor chain
- Minimization. Each subprocessor receives only the minimum data necessary for its function.
- Separation of identity from clinical data. Direct identifiers (PII) are encrypted in a vault (
identity_vault), kept apart from the clinical tables, which reference the data subject only by a pseudonymous identifier (profile_id). The cipher is authenticated, deterministic field-level encryption (AEAD) via pgsodium (AES-256), applied to name, contact email, phone, and national ID. - On-device redaction before AI (best-effort, not de-identification). Before sending a document to the AI, the app applies — on the device itself — a redaction targeting the four direct identifiers of the holder (name, national ID, email, and phone), and it is the redacted copy that goes to the AI. This redaction is best-effort and is not de-identification: when the redaction runs and no identifier matches, or when the identity vault is empty, the original document may proceed; moreover, a report may contain other printed identifiers that the redaction does not cover. We therefore recommend not entering identifying information into free-text fields.
- No training. The AI provider is contractually prohibited from using the data to train or improve models.
- No data sale. No personal data is sold to third parties.
- Controlled chain. No subprocessor may engage a new subprocessor to process your data without an equivalent contractual obligation and without our right to object.
2. Categories of data processed (glossary)
For use in the tables that follow:
| Code | Category | Examples |
|---|---|---|
| PII | Direct identification (encrypted AEAD/AES-256 in identity_vault) | Name/nickname, contact email, phone, national ID |
| PHI | Health / sensitive data | Exams and markers; conditions/systems; medications; allergies; vaccines; appointments; vital signs and body composition (weight, fat, glucose, blood pressure, HR); symptoms and complaints; physical activity (incl. wearable workouts); sleep (sessions and stages — sleep_sessions); continuous wearable metrics (resting HR, HRV, VO2max, steps, energy, skin temperature); proprietary wearable-provider scores (Oura readiness/sleep/stress/resilience; WHOOP recovery/strain — daily_scores); device events (ECG — classification and metadata only, never the raw tracing/waveform; irregular rhythm; high/low HR; atrial fibrillation burden; fall detected — health_events); medication intake log (med_intakes); daily wellness check-in; menstrual cycle and reproductive health (flow, intermenstrual bleeding, ovulation test, cervical mucus, pregnancy test — imported from HealthKit into cycle_entries; sexual activity is not imported); self-declared lifestyle facts (smoking — incl. smoking years —, alcohol, activity, sleep perception, and menopause status — self-declared opt-in, not imported from HealthKit — lifestyle_facts); conversations with the AI assistant (persisted questions and answers — chat_messages/conversations); documents/reports; family history; care team |
| DEMO | Pseudonymous clinical-demographic profile | Biological sex; age; birth year (no day/month) (in profiles, no PII) |
| LOC | Optional locality and language | Country (country_code — sent to the AI, see 3.2, to regionalize educational guidance)/state/city; language (locale) |
| ACCT | Account, authentication, and consent | Account identifier, Sign in with Apple email/identifier, session tokens, MFA factor (TOTP), versioned consent events |
| TECH | Technical and usage metadata | Access logs (metadata, no clinical content), de-identified usage data, crash/performance telemetry |
| PAY | Subscription billing | Subscription status, receipt/transaction (payment processing is done by Apple; BAS AI does not receive card data) |
| CONN | Wearable connection data | OAuth connections (wearable_connections: status, scopes, encrypted access/refresh tokens AES-256-GCM server-side, sync cursors) and anti-CSRF states (oauth_states). Not health data — connection data, deleted on disconnection of the source |
3. Part A — List of Subprocessors
3.1 Supabase — infrastructure, database, storage, and authentication
| Field | Detail |
|---|---|
| Subprocessor | Supabase, Inc. |
| Role | Processor/sub-processor (backend hosting) |
| Purpose | Host MyHealth's infrastructure: database (PostgreSQL), document/report storage, account authentication, and edge functions. Supports the clinical_processing purpose and, in AI routing, ai_processing. |
| Data processed | Structured PHI and documents/reports (referenced by pseudonymous profile_id); field-level encrypted PII (deterministic AEAD via pgsodium, AES-256) in the identity_vault; DEMO; LOC; ACCT (incl. MFA/TOTP factor and consent_events); TECH (access logs access_log). Supabase operates the infrastructure but does not access the vault PII in cleartext in normal operation (decryption only via a secure function, under the user's own identity). |
| Location / international transfer | Region sa-east-1 (São Paulo, Brazil) — data residency in Brazil. Ancillary administrative processing (e.g., support) may involve access from other jurisdictions by subprocessor staff, under the safeguards below. For security, the project ref and the anon/JWT key are not publicly exposed on this page or external materials. |
| Safeguards | DPA signed 2026-06-18, with EU Standard Contractual Clauses (SCC) and equivalent safeguards for any transfers, and an equivalent mechanism under the LGPD; encryption in transit (TLS 1.3, with certificate pinning in the app) and at rest; additional field-level encryption (pgsodium AEAD/AES-256) under our key management; isolation via Row-Level Security (RLS) per verb; audit trail (access_log append-only / pgaudit best-effort); NO-TRAINING clause. |
3.2 Anthropic — language model (Claude) for educational reading and exam extraction
| Field | Detail |
|---|---|
| Subprocessor | Anthropic, PBC |
| Role | Processor/sub-processor (AI processing) |
| Purpose | Process, via the Claude API, the user's own content to: (a) extract/structure documents and exams; (b) generate an educational, NON-diagnostic reading (longitudinal record analysis); and (c) answer the educational assistant chat. Maps to the ai_processing purpose and, when leaving Brazil for the US, intl_transfer. Web search exists only in the assistant chat: the model is instructed to use only generic clinical terms, without values, dates, age, names, or user identifiers — protection by model instruction, not an infallible technical filter; the search is run by Anthropic's infrastructure. The record-analysis and document-extraction functions do not perform web search. |
| Data processed | The user's own clinical content (PHI), sent subject to AI-processing consent. Anthropic receives: the REDACTED copy of the document image/PDF (not direct PII — see 1.1); sex + age + country (country_code) and the birth year (no day/month); and the clinical content of the record in the longitudinal analysis (exam markers and trends, measurements and body composition, medications, vaccines, allergies, symptoms, appointments and notes, family history, physical activity, sleep and wearable scores, device events — ECG classification, irregular rhythm, fall, never the raw tracing —, menstrual cycle and reproductive data, self-declared lifestyle facts — smoking (incl. smoking years)/alcohol/activity/sleep/menopause status — and blood type). Chat conversations (questions and answers) also transit. Anthropic does NOT receive: the direct identifiers (name, national ID, email, phone — encrypted in the identity_vault), the emergency-card contacts, account data, or connection tokens (CONN). Redaction caveat: the redaction is best-effort; when it runs and nothing matches, or the vault is empty, the original document may proceed, and a report may contain other printed identifiers. When a wearable source is connected (Section 3.5), the data enters as aggregates in the longitudinal analysis context (sleep trends, resting HR, HRV always with the SDNN/rMSSD method, steps, energy, and provider scores labeled by brand, without recalculation); raw continuous series are not sent (server-side aggregation, limit of 90 points per metric). Transient processing; retention limited by the subprocessor (see Safeguards). |
| Location / international transfer | Processing via Anthropic's API, with infrastructure in the United States. International transfer of sensitive personal data from Brazil, carried out only with the data subject's specific consent, under the contractual safeguards below. |
| Safeguards | Processing governed by Anthropic's Commercial Terms (in force since 2026-06-17), with Standard Contractual Clauses (SCC) for the international transfer and an equivalent mechanism under the LGPD; NO-TRAINING clause (inputs and outputs are not used to train or improve models — contractual commitment); limited retention by the subprocessor (as a rule, deletion within ~30 days, except retention required by law or for abuse prevention); transmission over TLS 1.3 with certificate pinning of api.anthropic.com; strict payload validation; anti-injection safeguards (instruction fencing); no clinical body in our Edge Functions' logs. |
3.3 Resend — transactional email delivery
| Field | Detail |
|---|---|
| Subprocessor | Resend |
| Role | Processor/sub-processor (transactional email provider) |
| Purpose | Deliver the account's transactional emails: access/OTP authentication code and operational account notices. Does not take part in any clinical or AI flow. |
| Data processed | Only the recipient's email and the email content (code/notice). No health content (PHI), no sensitive account data beyond what is needed to send, no clinical PII. |
| Location / international transfer | US / global. International transfer. |
| Safeguards | DPA in force (2026-06-17), with a transfer basis via the EU-US Data Privacy Framework (DPF) + Standard Contractual Clauses (SCC) and an equivalent mechanism under the LGPD; no-training/no-secondary-use clause; minimization (no health data is shared); TLS in transit. |
RevenueCat is NOT used. MyHealth's monetization runs on native In-App Purchase (StoreKit) — subscription and add-on packs (pages/prompts) — with Apple as the merchant of record (see 3.5). There is no third-party subscription intermediary.
3.4 What is NOT a subprocessor
- What happens on the iPhone. HealthKit reading and on-device caching involve no third parties. The redaction of the holder's identifiers happens locally, before sending to the AI (best-effort — see 1.1 and 3.2). There is no local OCR or on-device de-identification.
- Platform and sources that are independent controllers. Apple (platform/IAP/Sign in with Apple/HealthKit) and the wearable providers Oura and WHOOP act as independent controllers of their own platforms — not as BAS AI processors (see Section 3.5).
- No third-party tracking SDK. The app does not embed any advertising/tracking SDK that sees health data. We currently use no third-party analytics or tracking; if that changes, we will update this page and the Privacy Policy before activation, with a new notice (see Section 9).
- Licensed open vocabularies/standards (LOINC® / UCUM). To recognize the same exam under different names/abbreviations/languages as a single parameter (canonical marker catalog) and to standardize units, the app embeds a reference dictionary derived from LOINC® (Regenstrief Institute, Inc.) and UCUM. It is embedded licensed content — it works locally as a lookup table. Regenstrief Institute does not receive any personal/clinical data, does not process data on behalf of BAS AI, and is not a subprocessor; this is an attribution/IP license obligation (met in the Privacy Policy §6.4 and in the app's notices screen), not a data-processing chain. The LOINC License is free, including for commercial use, and requires visible attribution and tracking of updates (~2x/year).
3.5 Platform and data sources — Apple, Oura, and WHOOP (independent controllers; NOT subprocessors)
These entities do not process data on behalf of BAS AI: each is an independent controller of its own platform. Apple is the distribution, optional authentication, push, and payment platform; Oura and WHOOP are data sources/originators connected by the data subject. The wearable flow is inbound only (from the provider into the user's record), via an OAuth connection authorized by the holder and source-specific consent (wearable_sync_oura / wearable_sync_whoop, dual basis LGPD Art. 11, I + GDPR Art. 9(2)(a), revocable). The provider does not receive record data.
Apple Inc. — distribution and OS-services platform, merchant of record for subscription and add-on-pack purchases via native In-App Purchase (StoreKit), provider of Sign in with Apple (when chosen) and push notifications. Read access to Apple Health (HealthKit) is optional and happens locally, on the device (consent wearable_sync_apple_health) — Apple does not take part in the transit of that data to our backend and does not receive MyHealth's clinical base. In payment, BAS AI does not receive or store card data. Compliance with Apple Guideline 5.1.3 (health data never used for marketing, third-party sharing, or AI training) and Guidelines 3.1.1/3.1.2 (digital purchases). Location: US / Apple's global infrastructure, under the Apple Developer Program License Agreement.
| Field | Oura | WHOOP |
|---|---|---|
| Entity | Oura Health Oy (Finland / EEA) — independent controller; integration under Oura's API terms | WHOOP, Inc. (US) — independent controller; integration under WHOOP's Developer Terms |
| Role | Data source connected by the holder | Data source connected by the holder |
| Data collected (per authorized scopes) | Sleep (sessions/stages), daily scores (readiness, sleep, activity, stress, resilience), metrics (resting HR, HRV rMSSD, temperature, SpO2, VO2max), daily activity, workouts | Sleep (sessions/stages), daily scores (recovery, strain), metrics (resting HR, HRV rMSSD, SpO2, skin temperature), workouts |
| Connection data (CONN) | OAuth tokens encrypted (AES-256-GCM) server-side only; the app never sees tokens; deleted on disconnection | Same |
| Location / international transfer | Collection from the Oura API (Finland/EEA) → storage in Brazil (sa-east-1) | Collection from the WHOOP API (US) → storage in Brazil (sa-east-1) |
| Disconnection / purge | Token revocation at the provider + consent_events granted=false; the holder chooses to keep or delete the already-imported data | Revocation (DELETE /v2/user/access) + consent_events granted=false + mandatory purge of all data originating from WHOOP (provider contractual requirement — no option to keep) |
| Safeguards / contracts | Oura API terms (60-day cache and transfer basis assessed); mandatory brand attribution; scores never recalculated/combined | WHOOP Developer Terms (require Privacy Policy URL and brand-guideline compliance); brand attribution; prohibition on deriving scores |
Apple Health (HealthKit) does not appear in the wearable network-traffic table because the reading is local, on the device — there is no data traffic between Apple and BAS AI's backend.
4. Part B — Record of Processing Activities (ROPA)
Inventory of processing activities (GDPR Art. 30 / LGPD Art. 37). Per-purpose consents are kept in an append-only record (consent_events), versioned by policy_version, and the Edge Functions verify consent at runtime (has_active_consent gate).
| # | Activity | Data categories | Categories of data subjects | Recipients / subprocessors | International transfer |
|---|---|---|---|---|---|
| 1 | Sign-up, authentication, and account security (MFA TOTP) | ACCT, PII (encrypted) | Adult users; legal guardians | Supabase; Resend (email/OTP); Apple (Sign in with Apple — independent controller) | No (BR), except Resend and Sign in with Apple (US/global) |
| 2 | Record organization (extraction, timeline, trends; daily routine — medication intake med_intakes and wellness check-in; lifestyle facts lifestyle_facts) | PHI, DEMO, documents/reports | Holders and dependents (minors) | Supabase | No (BR) |
| 3 | Educational reading and document extraction by AI (incl. wearable, cycle, lifestyle, and device-event aggregates in the longitudinal analysis context — see 3.2) | PHI (user's own content, with sex+age+country+birth year); redacted copy of the document/image at extraction | Holders and dependents | Anthropic (Claude) | Yes — US |
| 4 | Educational AI assistant chat (questions/answers persisted in chat_messages/conversations; web search with generic terms only — see 3.2) | PHI (user's own content); conversations | Holders and dependents | Anthropic (Claude); Supabase (persistence) | Yes — US (Anthropic); persistence BR |
| 5 | Family sharing (opt-in, read-only) | PHI, DEMO | Holder and linked relative | Supabase | No (BR) |
| 6 | Apple Health (HealthKit) sync — optional, local on-device reading, continuous (background delivery) | PHI (measurements, continuous metrics, sleep, workouts, device events, cycle/reproductive) | Holders | Local reading (iPhone); Supabase storage | No (local reading; storage BR) |
| 7 | Portability / export (FHIR R4, PDF) — includes wearable data, lifestyle, AI conversations, and routine records | PHI, DEMO, PII | Holders and dependents | Generated in app/backend; delivered to the holder | No |
| 8 | Account, subscription, and add-on packs (native In-App Purchase / StoreKit); usage telemetry and AI billing (ai_usage, credit_ledger) | ACCT, PAY, TECH (no PHI in the payment flow) | Subscribers; guardians (minor billing) | Apple (merchant of record — independent controller); Supabase | Yes — Apple (US/global); persistence BR |
| 9 | Awaiting available quota/usage — holding of an already-redacted document without analysis until quota or a pack is available, with automatic analysis when available usage allows | PHI (redacted copy of the document, at rest) | Holders and dependents | Supabase | No (BR) — AI analysis (activity 3) only occurs when triggered |
| 10 | Security, audit, and abuse prevention | TECH (access metadata, no PHI) | All users | Supabase | No (BR) |
| 11 | Stability / diagnostic telemetry | TECH (no PHI) | All users | BAS AI — currently no observability third party; if adopted, it will be listed on this page before activation | No (BR) — currently no third party |
| 12 | Versioned consent management (de-linked/pseudonymized record — see 6.7) | ACCT (consent_events) | All users | Supabase | No (BR) |
| 13 | Age attestation (age_attestation) — 18+ declaration; minor sign-up blocking; immutable record with server timestamp | ACCT | All users | Supabase | No (BR) |
| 14 | Oura sync — OAuth connection, API collection, and webhook (sleep sleep_sessions, scores daily_scores, metrics, workouts) | PHI (wearable), CONN | Holders | Oura Health Oy (source/independent controller — see 3.5); Supabase | Yes — collection from Finland/EEA → BR |
| 15 | WHOOP sync — OAuth connection, API collection, and webhook (sleep, recovery/strain, metrics, workouts) | PHI (wearable), CONN | Holders | WHOOP, Inc. (source/independent controller — see 3.5); Supabase | Yes — collection from US → BR |
| 16 | Wearable connection management (encrypted tokens, OAuth state, revocation and purge on disconnection) | CONN | Holders | Supabase (access restricted to service_role; the app never reads tokens) | No (BR) |
5. Purpose → Legal Basis → Retention Matrix
| Purpose | LGPD legal basis | GDPR legal basis | Retention |
|---|---|---|---|
Clinical processing (clinical_processing) — organize the record | Art. 7, I and Art. 11, I (specific, highlighted consent for sensitive data) | Art. 6(1)(a) + Art. 9(2)(a) (explicit consent) | While the account exists; deleted on request (Section 7) |
AI processing (ai_processing) — document extraction, educational reading, and assistant chat | Art. 7, I and Art. 11, I (specific consent) | Art. 6(1)(a) + Art. 9(2)(a) | Transient processing at Anthropic, with limited retention by the subprocessor (as a rule, deletion within ~30 days); result kept in the record while the account exists; chat conversations persisted until the holder deletes them |
International transfer (intl_transfer) — outbound to Anthropic/US in AI processing | Art. 7, I; Art. 11, I; Art. 33 | Art. 6(1)(a) + Art. 9(2)(a); Arts. 44–49 | Transient; limited retention at destination (~30 days), per Anthropic's terms; transfer under SCC |
Family sharing (family_sharing) — opt-in, read-only | Art. 7, I and Art. 11, I (consent) | Art. 6(1)(a) + Art. 9(2)(a) | Active link until revocation; invitation expires in 7 days |
Wearable sync (wearable_sync_apple_health / wearable_sync_oura / wearable_sync_whoop) — source-specific consent, recorded before any read/pull | Art. 7, I and Art. 11, I (specific, highlighted consent; revocable) | Art. 6(1)(a) + Art. 9(2)(a) (explicit consent; revocable) | Imported data: general rule (while the account exists). On disconnection: tokens/connection (CONN) always deleted; WHOOP — mandatory purge of imported data (provider contractual requirement); Oura/HealthKit — the holder chooses to keep (under active consent) or delete |
| Minor data under guardianship | Art. 14 (best interest; guardian consent) | Art. 6(1)(a)/Art. 8 + Art. 9(2)(a), exercised by the guardian | While the guardian's account exists; deleted on request. The minor's identity is DELETED at the moment of deletion (no fiscal identity track for minors) |
Age attestation (age_attestation) — 18+ declaration at sign-up | Art. 14 + Law 15.211/2025 (Digital ECA) | Art. 8 | Immutable record while the account exists (compliance proof) |
| Account, subscription, and add-on packs (In-App Purchase) — maintain the account and process the AI subscription and add-on packs of usage (as a rule, 1 page of quota per document page); a minor's AI use is billed to the guardian | Art. 7, V (contract performance); Art. 7, II and Art. 16, I (mandatory fiscal retention of receipts) | Art. 6(1)(b); Art. 6(1)(c) (fiscal retention) | Account: while it exists. Fiscal/billing receipts and the minimal identity of those who transacted are retained for the jurisdiction's fiscal period even after account deletion — 5 years (Brazil, US, and others), 6 years (UK, Canada), 10 years (EU) — see Section 6 (dual-track) |
| Security, audit, and abuse prevention | Art. 7, II (legal obligation) and Art. 10 (legitimate interest) — not Art. 11, II "f" (health protection) | Art. 6(1)(c) (legal obligation) and Art. 6(1)(f) (legitimate interest) — not Art. 9(2)(h) | Access logs (timestamp + IP, metadata with no clinical content): 6 months (Brazilian Internet Bill of Rights, Law 12.965/2014, art. 15 — legal floor). This floor refers to access logs, which are not health data and do not justify retaining record content |
| Technical / stability telemetry | Art. 7, IX (legitimate interest) | Art. 6(1)(f) | Up to ~12 months, by minimization self-limitation (LGPD art. 6, III) — the Controller's internal policy, not a legally imposed term; no PHI |
Clinical-core legal basis (decided). The primary basis of the entire clinical core (record organization, AI reading/extraction, assistant chat, international transfer, family sharing, and wearable sync) is specific, highlighted consent for sensitive data — LGPD Art. 11, I/II "a" / GDPR Art. 9(2)(a) — consistent with the "sovereign record" positioning and revocable at any time. As a subsidiary basis — limited to the security and integrity of processing, compliance with a legal obligation, and carrying out deletion itself — LGPD Art. 7, II and Art. 10 / GDPR Art. 6(1)(c) and (f) apply. The health-protection ground (LGPD Art. 11, II "f" / GDPR Art. 9(2)(h)) is not invoked: GDPR Art. 9(3) conditions that basis on processing by a professional bound by secrecy in the flow, and there is no physician in the loop in MyHealth — the assistant never communicates diagnosis, prognosis, or a therapeutic decision.
HIPAA does not apply. MyHealth is a B2C product under the data subject's own control; BAS AI is not a HIPAA covered entity or business associate. We therefore do not publish "BAA" or "HIPAA compliant".
6. Retention and Deletion Policy (dual-track)
- General rule (clinical track). Record data (PHI/DEMO, documents, AI conversations, wearables, routine) is kept while the account exists and the holder wants to keep the record organized; it is deleted upon account deletion (Section 7).
- Dual identity track. Direct identity (name/email, encrypted in the
identity_vault) is retained only for those who TRANSACTED (subscribed or bought add-on packs), for the jurisdiction's fiscal period: 5 years (Brazil, US, and others), 6 years (UK, Canada), 10 years (EU). For minors and non-payers, identity is DELETED at the moment of deletion — there is no fiscal identity track. - Fiscal receipts. Billing/fiscal receipts (subscription and add-on-pack purchases) follow the same jurisdictional fiscal period above (Brazil: CTN, arts. 173 and 174), even if the account is deleted earlier.
- Access logs. The
access_log(audit/security metadata — who, when, which table, action, source IP) is kept for 6 months (Brazilian Internet Bill of Rights, art. 15). It is metadata with no clinical content; this term does not justify retaining record content. - AI processing. Content sent to Anthropic is transient; the subprocessor retains it for a limited period and then deletes it (as a rule, within ~30 days), except retention required by law or for abuse prevention. The result incorporated into the record follows the general rule; assistant chat conversations are kept until the holder deletes them.
- Technical telemetry. Stability/diagnostic telemetry (no PHI) is kept for up to ~12 months, by minimization self-limitation (LGPD art. 6, III) — the Controller's internal policy, not a legally imposed term.
- Immutability and de-linking of records. The
access_logis append-only (UPDATE/DELETE blocked by trigger). Theconsent_eventsare de-linked/pseudonymized (HMAC key kept outside the database) — not "anonymous": they preserve proof of when consent was granted/revoked without directly re-identifying the data subject. Revoking consent means inserting a newgranted=falseevent; revocation does not retroactively erase processing already lawfully carried out, but stops future processing for that purpose. - Deletion on request. Deletion is carried out at the request of the holder (or legal guardian, in the case of minors), per the Section 7 procedure, within 30 days.
7. Account and Data Deletion Procedure
Account deletion is available in the app itself (Apple requirement) and can also be requested from the DPO (dpo@bas-ai.com).
- Request. The holder (or legal guardian, for a minor dependent) initiates deletion in the app or by contacting the DPO.
- Scope. Deletion erases all PHI, documents/reports in Storage, family-sharing links, wearable and routine data (
sleep_sessions,daily_scores,health_events,med_intakes, measurements withprovider/external_id), lifestyle facts (lifestyle_facts), AI assistant conversations (chat_messages/conversations), AI service-usage records (ai_usage,credit_ledgerand related, except the fiscal retention of purchase receipts), wearable connection data (wearable_connections,oauth_states— encrypted tokens), and account data. Clinical tables are deleted in cascade fromprofile_id(on delete cascadeforeign keys). - Managed dependents. Account deletion also erases the data of managed dependents (minor profiles) under that account. Before deleting a minor, the app offers to MIGRATE guardianship of the minor to an existing co-guardian — in which case the minor's profile survives under the new guardian, rather than being deleted.
- Identity (dual-track). If the holder transacted, their minimal identity (name/email) is retained encrypted only for the jurisdiction's fiscal period (Section 6). If they did not transact — and always for minors — identity is DELETED at the moment of deletion.
- Effective deletion. Permanent, cascade removal of records and documents; clearing of cached data on the device at logout/deletion. Deletion is permanent, but destruction of encryption keys (crypto-shredding) and absolute irreversibility in backups are not claimed — any backups expire per the infrastructure's retention cycles.
- Minimum legal retention. Even after deletion, the following are kept: (a) the minimum metadata the law requires (record that deletion occurred); (b) the access logs for the 6-month floor (art. 15) — metadata, no clinical content; and (c) the fiscal track (receipts + minimal identity of those who transacted) for the jurisdiction's fiscal period (Section 6). None of this reconstitutes the record, which is deleted.
- Timeframe and confirmation. Deletion is an immediate operation in the database. No automatic receipt is issued; the holder may request confirmation of completion from the DPO — dpo@bas-ai.com — who responds based on the minimal deletion record (LGPD art. 6, X).
- Subprocessors. Deletion is propagated to the infrastructure (Supabase). Content sent to Anthropic is transient and retained for a limited period (~30 days) and then deleted by the subprocessor, per its terms. For Apple (incl. purchase/subscription data via In-App Purchase, as an independent controller) and Resend (email), the respective platform's deletion mechanisms apply to the data each one processes. RevenueCat is not used.
- Wearable disconnection (selective per-provider purge, without deleting the account). Available on the Integrations screen. Disconnection: (a) revokes tokens at the provider (Oura:
oauth/revoke; WHOOP:DELETE /v2/user/access); (b) deletes connection data (CONN); (c) writesconsent_events granted=falsefor the source's purpose; (d) applies the imported-data policy — WHOOP: mandatory purge of all data withsource='whoop'(contractual requirement, verifiable by zero count); Oura/HealthKit: the holder chooses to keep or delete. Connect/disconnect/purge events are recorded in the audit log.
8. Minimum age and minors' data
Protection of children and adolescents observes Brazil's Statute of the Child and Adolescent (Law 8.069/1990), Law 15.211/2025 (Digital ECA), LGPD Art. 14, GDPR Art. 8 (reference standard), and COPPA (US).
- Single age of 18 for one's own account, in any country (or the country's civil age of majority, if higher). This requirement relates to account ownership and is not the same as GDPR's age of autonomous digital consent (Art. 8, between 13 and 16 depending on the country). The age attestation (
age_attestation) is recorded immutably, with a server timestamp; sign-up of an under-18 with their own account is blocked. - The minor has no account or email of their own: they exist only as a managed profile (
profiles.kind='minor',profiles.managed_by) within an adult guardian's account, who exercises the minor's rights (LGPD Art. 14). - Multi-guardian. A profile may have more than one guardian: the primary one invites another adult via a time-limited invitation code. Each invitee receives a role — guardian (view and edit) or companion (read-only). Every authorization is verified on the server at each operation (protection against improper object access / IDOR). Consent relating to the minor is recorded identifying which adult granted it. On deletion of the primary guardian's account, the app offers to migrate guardianship of the minor to an existing co-guardian (see Section 7).
- Billing. Paid AI features require a guardian role and are billed to the responsible adult who performs the action; the dependent has no quota, pack, or payment method of their own. The usage record remains linked to the minor's profile for audit.
- Wearable and Apple Health data never follow a minor's profile — they are always recorded on the account's adult holder's profile.
- The same protections (PII encryption, identity separation, AI no-training) and the best interest of the child/adolescent apply to minors' data. The minor's identity is DELETED at the moment of deletion (Section 6).
- US (COPPA): MyHealth does not offer accounts to minors or collect data directly from children; any minor data is entered and controlled by a responsible adult, who exercises verifiable parental consent.
Age verification (Law 15.211/2025 — Digital ECA, in force since 2026-03-17). Age verification is done by self-declaration at sign-up, with the attestation recorded at acceptance (age_attestation, immutable, with a server timestamp).
9. Notice of new subprocessors and right to object
- Prior due diligence and a DPA with equivalent obligations (minimum: no-training; international-transfer safeguards — Standard Contractual Clauses / SCC and an equivalent mechanism under the LGPD; contractual retention limits where applicable).
- Prior notice with a 30-day objection window before the new subprocessor processes data, except for security/continuity urgency.
- Right to object to the DPO (dpo@bas-ai.com); where the purpose depends on consent (
ai_processing,intl_transfer,family_sharing,wearable_sync_*), the new processing does not occur without the recorded consent.
10. Data subject rights (multi-jurisdiction)
Regardless of jurisdiction, the data subject may, via the app or the DPO (dpo@bas-ai.com): access and export their data (FHIR R4/PDF portability), correct, delete (Section 7), revoke consent at any time, and object to processing based on legitimate interest.
- LGPD (Brazil): Art. 18 rights (confirmation, access, correction, anonymization/deletion, portability, information on sharing, revocation).
- GDPR (global reference standard): rights of access, rectification, erasure, restriction, portability, and objection (Arts. 15–21).
- US — CCPA/CPRA (California): right to know, delete, correct, and opt out of "sale"/"sharing" — BAS AI does not sell or share personal data for behavioral advertising; there are no third-party tracking signals.
- US — Washington My Health My Data (MHMDA): "consumer health data" is processed subject to consent; the data subject may withdraw consent and request deletion; BAS AI does not sell health data.
- Canada (PIPEDA + provincial laws): access, correction, and consent withdrawal, with 6-year fiscal retention where applicable.
11. Version history
| Version | Date | Change |
|---|---|---|
| 2.1 | 2026-06-23 | Code×policy alignment (authoritative survey). (a) Subprocessor list corrected to three — Supabase, Anthropic, and Resend; Apple, Oura, and WHOOP reclassified as independent controllers/sources (Section 3.5), not subprocessors. (b) DPAs declared IN FORCE: Supabase (signed 2026-06-18, EU SCC + safeguards; sa-east-1/Brazil), Anthropic (Commercial Terms 2026-06-17 + SCC; NO-TRAINING; ~30 days), Resend (EU-US DPF + SCC, 2026-06-17). (c) Anthropic receives the REDACTED copy of the image/PDF (not the raw one), + sex+age+country+birth year (no day/month), without direct identifiers and without emergency contacts; redaction is on-device best-effort, not de-identification. (d) Cipher corrected to deterministic AEAD via pgsodium (AES-256). (e) Dual-track retention: identity retained only for those who transacted (fiscal period per jurisdiction — 5/6/10 years); minors and non-payers have identity deleted at deletion; consent_events de-linked/pseudonymized (HMAC outside the database); access_log 6 months. (f) Account deletion erases PHI + files + managed dependents' data, with the option to migrate guardianship of a minor to a co-guardian. (g) New ROPA activity Awaiting available usage/quota (redacted document held until usage/quota is available, then analyzed automatically). (h) SaMD/HIPAA made explicit: not a medical device, AI does not check interaction/contraindication/allergy×medication, HIPAA does not apply. (i) DPO updated to dpo@bas-ai.com; worldwide distribution except EU/EEA+UK; GDPR/UK protections as a global baseline. policy_version 2.1. |
| 2.0 | 2026-06-22 | Go-live: final pricing, updated AI model routing, Legal 2.0. |
| 1.6 | 2026-06-14 | Factual alignment (reproductive health and AI context). |
| 1.5 | 2026-06-12 | Canonical marker catalog (LOINC®/UCUM) embedded — licensed content, not a subprocessor. |
| 1.4 | 2026-06-11 | Concrete retention terms in the ROPA; clinical-core legal basis decided (consent as primary). |
| 1.3 | 2026-06-11 | Factual correction: Anthropic = US infrastructure; ~30-day retention; RevenueCat removed (native IAP); Resend added. |
| 1.1 | 2026-06-10 | Wearable integrations: new PHI and CONN categories; Oura/WHOOP as sources; wearable_sync_* purposes. |
| 1.0 | — | Initial publication. Subprocessors: Supabase (BR) and Anthropic (AI); Apple as platform. |
The version history is published at https://www.bas-ai.com/myhealth/legal/versoes; each accepted version remains archived.
Non-diagnosis note. MyHealth organizes your health history and offers an educational, prudent reading. It is not a medical device, does not diagnose, and does not replace a healthcare professional's assessment. The AI does not check drug interactions, contraindications, or cross-check allergies against medications. In an emergency, seek medical care immediately.