MyHealth — Washington Consumer Health Data Privacy Policy

Required by the Washington My Health My Data Act (MHMDA), RCW chapter 19.373 (RCW 19.373.020 / .030 / .040).

Version (policy_version): 3.13 · Effective: 2026-07-25

This is a standalone Consumer Health Data Privacy Policy. It supplements, and is read together with, our general Privacy Policy and our Subprocessors page. Where this policy and the general Privacy Policy differ for consumer health data covered by the MHMDA, this policy controls for that data.

1. Who this policy is for

This policy applies to "consumer health data" as defined by the Washington My Health My Data Act when it relates to a "consumer" under that Act — that is, a natural person who is a Washington State resident, or a natural person whose consumer health data is collected in Washington — and who is acting in an individual or household capacity (not in an employment context).

Under the MHMDA, consumer health data means personal information that is linked or reasonably linkable to a consumer and that identifies the consumer's past, present, or future physical or mental health status — including health conditions, diagnoses, treatments, medications, vaccinations, bodily functions, vital signs, symptoms, diagnostic testing, reproductive or sexual health information, and any data that identifies a consumer seeking health care services.

Important position. Because MyHealth is a health application, we treat the fact that a person has a MyHealth account — and the identifiers tied to it (name, email, and the account number we assign) — as consumer health data when that person is a Washington consumer. This affects how we handle deletion (see Section 8). Upon deletion we do not retain these identifiers in readable form: what survives is only an irreversible HMAC code (a one-way cryptographic transformation) of your search identifiers, kept in a minimal forensic security index held apart from any health record and containing no health data — and because it is not readable and is retained solely for security and fraud prevention, we do not treat it as the consumer health data subject to your deletion right (see Section 8).

This policy does not change rights you may have under our general Privacy Policy or under other laws.

2. Who we are

The entity responsible for the MyHealth app is:

BAS ARTIFICIAL INTELLIGENCE LTDA ("BAS AI", "MyHealth", "we", "us")

Tax ID (CNPJ): 64.106.409/0001-70

Address: Rua Gomes de Carvalho, 911, Vila Olímpia, São Paulo/SP, ZIP 04547-003, Brazil

Website: www.bas-ai.com

Data Protection Officer (Encarregado): Guilherme Bastian.

Privacy contact for consumer health data requests: privacidade@bas-ai.com (also reachable at dpo@bas-ai.com).

3. The categories of consumer health data we collect

We collect consumer health data only that you provide or authorize — there is no background or passive collection of health data. Depending on how you use MyHealth, the categories may include:

• Health conditions, diagnoses, and health problems you record or that the AI extracts from documents you upload (and that you confirm before saving).
• Lab and exam results (markers, values, units, reference ranges, trends over time).
• Medications (name, active ingredients, dose, schedule) and vaccinations (vaccine, disease, dose).
• Allergies (allergen and class).
• Measurements and vital signs, including body composition / bioimpedance. For glucose imported from Apple Health, days produced by a continuous glucose monitor (CGM) are stored as daily aggregates only — mean, minimum, maximum, variability (CV), and the percentage of the day within the 70–180 mg/dL range of the industry display standard (AGP) — and the raw continuous readings are never stored; spot/capillary readings remain normal measurements. The displayed aggregates are a factual, industry-standard display — never an individual target or a judgment about your glucose control.
• Symptoms, appointments, procedures/surgeries, and clinical notes you record.
• Family medical history you record.
• Reproductive and menstrual data you record or import — menstrual flow, intermenstrual bleeding, ovulation tests, cervical mucus quality, and, if you are female and 40 or older, a self-declared menopause phase (with the option not to answer). We do not import sexual activity records.
• Pregnancy status (a self-reported trimester) — on-device only. If you are an adult account holder whose sex at birth is female, you may optionally record a pregnancy stage as a trimester (not pregnant, first, second, or third trimester, or postpartum), with a "prefer not to say" option that records nothing. For the pregnancy feature this is the only reproductive-timing data we use: we do not collect or derive your last menstrual period (LMP) or estimated due date (EDD) — only the trimester enum. It is stored only on your device, in the iOS Keychain scoped to this device only (excluded from iCloud Keychain and from device backups), per profile; it is never written to our database, never placed in your lifestyle facts, and never synced. It expires on its own after about 40 weeks and can be deleted in one tap. It is available only on your own adult profile — not on minors' or managed profiles (enforced fail-closed on our server; see Sections 5 and 7). Only when you run an analysis or send a chat message is the trimester sent to our AI provider, transiently and never stored by us, to calibrate the reading of your labs for pregnancy/lactation ranges (see Sections 5 and 7).
• Mental-health data (Apple Health) — separate, per-category consent; not shared with our AI provider. If you log your mood (State of Mind) or answer well-being questionnaires (GAD-7 for anxiety, PHQ-9 for depression) in Apple Health, we collect them only after you turn on a dedicated, separate consent (mind_import, off by default, presented apart from our Terms and from the general clinical consent — a per-category authorization under RCW 19.373.030). This is consumer health data relating to your mental health: we keep only the daily mood average (a −1 to +1 score) and, for the questionnaires, only the total score and Apple Health's own classification (the item-by-item answers are discarded). It lives in your record (with a home in the Journal and the "Mental health" system), never on the home screen and never in a notification. Only the weekly mood trend may be shared with our AI provider, descriptively, and only while you also keep the sensitive Health Diary (daily_journal_ai) on — a double consent; the GAD-7/PHQ-9 questionnaires and the ring's stress index are never shared with our AI provider. Not available on minors' or managed profiles. Withdrawing consent deletes everything (mood and questionnaires).
• Contraceptive and lactation states — on-device only (reproductive complement). In the same on-device design as the pregnancy trimester (above), you may record a contraceptive (in use) or lactation state to contextualize the educational reading of your labs (they shift reference ranges, as pregnancy and menopause already did). They are held only on your device (iOS Keychain, excluded from iCloud Keychain and backups), are never written to our database and never synced, and are shared with our AI provider only transiently, at the moment you run an analysis — never stored by us, and never recorded by the AI as a condition. Separately, cycle deviations imported from Apple Health (infrequent/irregular cycles, persistent intermenstrual bleeding, prolonged periods) appear as descriptive findings within cycle tracking, under the cycle import you already control, always suggesting a conversation with your gynecologist. The AI chat does not receive cycle data, and none of this becomes a notification. We still do not import the Apple Health "pregnancy test" and do not import sexual activity. We never sell or share reproductive data (RCW 19.373.070 / .110).
• Observed medication adherence (Apple Health, iOS 26 or later). If you log that you took a medication dose in Apple Health, we collect only the doses marked as taken, matched to a medication you already registered (we never create a new medication from Apple Health). This is adherence memory for you, not surveillance: the absence of a log is never treated as a missed dose, and the app never sends a "missed-dose" notification. Only a factual aggregate is shared with our AI provider — how many days, within a 30-day window, had a dose logged — never a percentage, judgment, or causal claim. Collected under the per-source and AI consents you already granted (a new source for a data point you already share, not a new category). Not available on minors' or managed profiles.
• Clinical Records (United States only) — conditional. We have built, and will make available only for US accounts and only once Apple grants the required authorization (an external Apple process, outside our control, that can take weeks), the read-only import of your own structured clinical records from Apple Health via the international FHIR standard — lab results (matched via LOINC), immunizations, medications, conditions/diagnoses already recorded by clinicians, procedures, and allergies — each integrated into your record with the same protections as any other consumer health data of yours. Free-text clinical notes and insurance/coverage records are never imported. Until Apple grants the authorization, the feature stays invisible and inactive. No new processor and no new international transfer.
• Sleep, daily wearable scores, and device events (e.g., ECG classification, irregular rhythm, fall) imported only from connected sources you authorize (Apple Health, Oura, WHOOP). We store the classification and metadata only — never the raw ECG trace/waveform, which stays on your device.
• Wearable annotations (Oura enhanced tags), when you connect an Oura ring — category code only — the annotations you record yourself in the Oura app (a type such as coffee, alcohol, symptom, medication, or travel, plus a custom name and a free-text comment). The free text (custom name and comment) — which may mention, for example, mental health or substance use — is discarded at import and never stored (it does not reach your record, our records, or our logs). We keep only the standardized category code (the "type"), visible only to you (excluded from family sharing), never logged, and always deleted when you disconnect the wearable. That standardized code — aggregated by week and never as free text — may be shared with our AI provider only when, and only while, you keep the sensitive Health Diary (daily_journal) on; without that consent it is not shared with the AI. They require Oura's additional "tag" OAuth scope; connections made before this version only start syncing them after you reconnect Oura.
• Lifestyle habits you declare (smoking and years of use, alcohol, physical activity, sleep).
• Non-sensitive daily contexts you record when asked, occasionally and optionally: coffee/caffeine, energy levels, hydration, how your workout felt (light/normal/hard), and routine changes during the week (e.g., travel, a new workout, changes in diet or sleep). When your AI-processing and international-transfer consents are active, these are shared with our AI provider only in weekly aggregated form — day counts and the routine-change category, never the individual daily entry, never free text (see Section 6).
• Daily self-observed entries you record, when enabled: alcohol consumption (substance use) and stress / night context (mental health) — dated daily entries. Opt-in, off by default, not available on minors' profiles. These entries stay on your device and in your health record and are not shared with our AI provider. Your mood check-in remains part of the existing well-being feature.
• Progress reports and follow-up decisions you record — your own reports about the evolution of a tracked item (for example, the outcome of a verbal assessment by a professional), including the report text, your keep/close decision, the date, and the version of the text you confirmed, kept in an immutable trail. These are always stored and displayed as your report (never as a documented clinical fact), the app does not verify or endorse the reported course of care, and only you can close follow-up of an item, always with express confirmation; professionals' names are optional in the report. On minors' profiles, the legal guardian records in representation, identified in the entry.
• Emergency card information (blood type, allergies, and notes). Emergency-contact details on the card are not sent to our AI provider.
• Documents and images you upload (photos, PDFs of exams and records) and the structured data the AI extracts from them.
• Messages you send to our support channel — both the in-app support tickets you write and any email you send to our support address — to the extent you include health information in them (see Section 5 for how support is handled).
• AI-generated educational outputs about your record (e.g., conditions, alerts, insights) — produced as supportive, non-diagnostic information with a human in the loop and no significant effect on access to care, credit, or insurance.
• The identifiers linked to your account (name, email, and the account number we assign — a random, non-sequential 8-digit number we generate for each profile and display in-app, used to locate your account for support; generated by us, not collected from you) — which, because this is a health app, we treat as consumer health data for Washington consumers (see Section 1).

We do not collect precise geolocation, your phone contacts, or microphone data. We do not use third-party trackers or analytics SDKs that see health data.

4. How we collect consumer health data

• Directly from you, when you type, record, or import data into the app, or when you write to our support channel.
• From documents and photos you choose to upload, from which our AI extracts structured records that you confirm before they are saved. The camera and photo gallery are accessed only at the moment you decide to upload (just-in-time permission).
• From sources you connect, with your authorization — Apple Health (HealthKit), Oura, and WHOOP — which act as independent sources you control, not as our vendors.

We collect consumer health data only with your consent for a specified purpose, or as strictly necessary to provide the product or service you have requested (RCW 19.373.030). Our system only performs a given operation when the matching consent is active; this is enforced automatically on our server on every operation. You can turn a purpose off at any time.

Consent for the sensitive health journal — separate collection authorization. The daily alcohol/stress journal is consumer health data and is not necessary to provide the core product, so we obtain your separate, specific consent BEFORE collecting it (purpose daily_journal), presented separately from our Terms and from the general clinical consent, off by default, and revocable at any time. Our server refuses to write this data unless the consent is active. This section does not apply to minors' profiles, where the sensitive journal is unavailable.

These sensitive-journal entries (alcohol, stress/night context) are not shared with our AI provider. This differs from the non-sensitive daily contexts (coffee/caffeine, energy levels, hydration, workout perception, routine changes), which — under your active AI-processing and international-transfer consents — are shared with our AI provider only in weekly aggregated form (day counts and the routine-change category, never the individual daily entry, never free text). We do not sell consumer health data and do not seek a "valid authorization" to sell.

You may access/confirm, delete, and withdraw consent at any time (RCW 19.373.040). Withdrawing consent stops collection and deletes these entries.

5. Why we collect it (purposes) and how it is used

We use consumer health data to:

• Organize and structure your health record — extracting values from documents, building your timeline and trends, and classifying records.
• Provide AI-assisted, educational analysis of your record (supportive reading, alerts, insights) — assistant only, never a medical device, never a diagnosis or prescription, with a human (you) in the loop and no significant decision made about you. The AI does not check drug interactions or contraindications and does not cross-reference your allergies against your medications.
• Calibrate the reading of your labs to a pregnancy or postpartum stage — only when you run an analysis, and only with your separate consent. If you have recorded a pregnancy trimester (Section 3), then at the moment you yourself run an analysis or send a chat message, we include that trimester in the request to our AI provider so it can read your exams against ranges appropriate to pregnancy or lactation. Because this is derived from consumer health data and is not necessary to provide the core product, it requires your separate, specific affirmative consent (purpose pregnancy-state-1.0, RCW 19.373.030), presented apart from the general clinical consent and from our Terms, off by default, and revocable at any time in Profile › Privacy (opting out deletes the value from your device). This consent also authorizes the transient international transfer of the trimester to Anthropic in the United States under our DPA/SCC (Section 7). Automatic/proactive analyses and the large-record (batch) path never receive it — it travels only in the analysis or chat you trigger, in memory, and is not stored by us. Our AI is instructed never to write "pregnant," "gestation," "breastfeeding," or the like into your conditions, alerts, problem list, or summary, and we additionally run a deterministic server-side scrub of the AI output as a backstop (covered by a regression test).
• Power the in-app assistant (chat), which can read your record and, at your request, propose draft records for you to review and save (the AI never saves on its own).
• Personalize the educational referral with your Care Team. If you registered professionals in your Care Team, the AI analysis context includes their name and specialty (and, if you provided them, the institution and the reason) so the educational guidance can point to the professional you already registered instead of a generic suggestion — never their phone, email, address, or registration number. This is the same handling the chat already applied, runs only under your active AI-processing and international-transfer consents, and involves no new processor.
• Show educational, age/sex-based screening reminders — on your device, in-app only. Using only your date of birth and sex at birth (data you already provided), a deterministic, fixed-rule engine on your device may show an in-app card (never a notification) suggesting a conversation with your doctor about screenings that population guidelines commonly indicate for your age group. It uses no test results, no conditions, and no individual risk assessment; suppression is calendar-based and never reads report contents; it is adult self-only, dismissible, and can be turned off; no consumer health data is shared to provide it (nothing new goes to any server or to the AI).
• Show a generic, AI-generated educational library. The educational texts shown for markers, measurements, and conditions may be AI-generated — but each text is generated once per abstract topic (a catalog name plus generic direction/range/population categories), is identical for every user of that topic, and no consumer health data of yours is sent for the generation; your data is used only on your device to select which generic texts are relevant to show.
• Answer and resolve your support requests. We store and read the messages you send us so that a person can help you. A human reviews every reply before it is sent. We may use AI assistance to draft or translate a reply, but only with consent and never using your clinical record — the AI sees the support conversation only. In particular:
• If you are a logged-in MyHealth user, an operator can request an AI-assisted draft reply or an AI-assisted translation of your ticket only when you have granted a new, dedicated, unbundled consent (support_ai_share) — separate from, and independently refusable of, the general AI-processing consent (it is off by default, and the paid product works fully if you decline it) — together with your international-transfer consent. Before your ticket is sent, its text is minimized by best-effort removal of identifiers (this is not de-identification); your clinical record (prontuário) is never sent. A human reviews every draft or translation before you receive it.
• If you email support without a MyHealth account, we handle your message consent-first: we first reply asking for two separate consents — (1) to process your message to prepare a reply, and (2) to transfer it to our AI provider (Anthropic / Claude) in the United States — with a link to this Consumer Health Data Privacy Policy. Only after you grant both does AI draft or translate that ticket, and a human reviews it before it is sent. If you do not consent, a person replies with no AI. Nothing is sent to AI without your own consent.
• The transfer to Anthropic (United States) is covered by our existing Data Processing Agreement and EU Standard Contractual Clauses with Anthropic — the same terms that govern record analysis, document extraction, and chat, and that apply to all data we submit to Anthropic's API. Contractual non-training applies, and retention follows Anthropic's own contractual limit (as a rule about 30 days, subject to legal or abuse-prevention exceptions — not a MyHealth-guaranteed deletion date, and not zero-retention) (see Section 7).
• Send you the notices you turn on (e.g., when an analysis is ready) — notice content is generic and contains no health data.
• Send you an opt-in "novelty" notice when your connected wearable or health data produces a new finding (for example, after your wearable indicates poorer sleep, an elevated resting heart rate, or a drop in heart-rate variability) — because deciding to send this notice is derived from consumer health data, it is off by default and requires your separate consent (RCW 19.373.030); the notice content is generic and contains no consumer health data, and no consumer health data is shared to deliver it — Apple's push service (APNs) receives only a delivery token and fixed generic text ("something new is in your data"), never the finding itself.
• Operate billing and prevent abuse — using only metadata of AI usage (function and token count) and usage/quota balance, never the analyzed health content.
• Keep the service secure and working — security, integrity, fraud prevention, and stability diagnostics that contain no health content.

We do not use consumer health data for targeted advertising, and we do not use it to train AI models.

6. The categories of sources from which we collect consumer health data

• The consumer (you) — directly entered, recorded, or uploaded data, and messages you write to our support channel.
• Documents and images you upload to the app.
• Health and wearable sources you connect and authorize — Apple Health (HealthKit), Oura, and WHOOP.

7. Sharing: categories of consumer health data shared, and with whom

We do not sell consumer health data, and we do not seek any "valid authorization" to sell it (RCW 19.373.070 / .110). We do not share consumer health data for advertising, marketing, or behavioral targeting.

We share consumer health data only with a minimal set of processors ("vendors"), each under a binding data processing agreement that limits them to processing data on our documented instructions (RCW 19.373.060), and only as necessary to provide the service you requested or as you separately consent. We do not have corporate affiliates that receive your consumer health data.

On redaction before AI processing. Before clinical content is sent to Anthropic, we replace your direct identifiers with sex, age, country, and year of birth (without day/month), used only to regionalize educational guidance. For uploaded documents, the app attempts an on-device, best-effort redaction (covering) of four of your identifiers — name, national document (CPF), email, and phone — and the redacted copy is the one sent; the original file stays intact in your record. This redaction is best-effort and is not de-identification: it is directed only at your own four identifiers, and when the redaction process runs but finds nothing to cover (for example, because your identity vault is empty), the original may proceed to the AI. We do not represent that identifiers are guaranteed to be removed.

How support messages are handled (not a document-redaction path). The best-effort redaction described above applies to documents you upload. Support handling is different and is described in Section 5. AI-assisted drafting/translation of support replies is active, but only with consent and never using your clinical record. For logged-in users, it runs only under a new, dedicated, unbundled consent (support_ai_share) — separate from and independently refusable of the general AI-processing consent, off by default — together with your international-transfer consent; before the thread is sent, its text is minimized by best-effort identifier removal (not de-identification), so it may still include health information you chose to type. For people who email support without an account, nothing goes to the AI until they grant, in response to our request, two separate consents (to process the message and to transfer it to Anthropic in the United States); if they decline, a person replies with no AI. A human reviews every draft or translation before it is sent, your clinical record is never sent for this purpose, and no new processor is involved — the transfer is covered by the existing Anthropic DPA/SCC that governs all data we submit to Anthropic's API (see the Anthropic row above).

Apple processes your subscription and in-app purchases as merchant of record; no health content is in the payment flow. Apple Health, Oura, and WHOOP are sources you connect, not recipients — they do not receive data from your health record.

Reproductive data — no sale, no share, no advertising. We never sell or share your reproductive or pregnancy data, and we do not seek any "valid authorization" to sell it (RCW 19.373.070 / .110). Your self-reported pregnancy status stays on your device (Section 3) and is transmitted to our AI provider only transiently, at the moment you run an analysis or send a chat message, solely to calibrate your lab reading — never for advertising, profiling, any secondary purpose, or a data broker, and never stored by us. It is available only on your own adult profile — not on minors' or managed profiles.

7.1 Sharing you direct between consumers: hereditary conditions with linked family members

MyHealth offers two consumer-directed sharing features, in which the recipient is a family member you choose (who must also be a user of the app) — not a vendor, affiliate, or advertiser:

• Read-only family link: you may invite a family member to view your record (read-only, all-or-nothing, single-use code, revocable at any time), under your specific consent.
• Hereditary-condition sharing (item by item): you may enable, item by item, tracked health conditions (a condition, its year of onset, and status — never exams, documents, values, medications, free text, or routine; this minimization is enforced in code by the database) to be offered to your linked family members, who may incorporate them into their own family history only by express, item-by-item acceptance.

For the hereditary-condition feature we obtain, before any sharing occurs, a valid authorization consistent with RCW 19.373.070: the authorization screen names the specific consumer health data shared (the named condition, year of onset, and status), the purpose (the recipient's family history), the recipient (your linked family members), and states that the authorization is revocable at any time, in one tap, free of charge and without justification — revocation immediately withdraws the offer from all linked family members. We keep a record of the authorization (who, when, and the version of the text displayed).

Permanence notice (shown at the moment you enable each item): an item a family member has already accepted becomes part of their family history, as their own record — deactivation does not delete it from their record; only they can remove it, and they may do so at any time. If you request deletion of your data or delete your account, we remove from the recipient's record every reference to your identity and account, keeping only the degree of kinship, condition, and period, which is consumer health data of the recipient themselves. Minors' profiles do not participate as a source by their own decision.

7.2 Data manager you authorize (consumer-directed delegation by an adult)

You may authorize another adult you choose (the "Manager" — who must also be a user of the app) to view your full health record and to register, edit, and upload documents on your behalf. This is consumer-directed sharing — the Manager is not a vendor, affiliate, or advertiser, and declares to act under your authorization, in your interest, in a personal, family, non-commercial context.

Before any access is granted we obtain the separate, distinct consent required by RCW 19.373.030(2), on your device, after reinforced identity confirmation: the consent screen names who the Manager is, the specific consumer health data covered (your full record), what the Manager can do (view; register, edit, and upload documents) and what the Manager can never do (change your consents, delete your account, manage sharing/links, change your credentials, make purchases, or bulk-export your record — the block on consents, account deletion, links, and credentials is enforced technically server-side; the block on purchases and bulk export is enforced technically in the app), and states that the authorization is revocable at any time, in one tap, free of charge and without justification, with immediate effect — revocation immediately ends the management powers; the read-only link remains until you also remove it (both options are shown side by side in the app). We keep a record of the consent (who, when, and the version of the text displayed), an immutable authorship trail of everything the Manager records (shown to you), and show you an in-app activity summary the Manager cannot turn off. What the Manager records is your consumer health data and remains in your record after revocation, under your rights (access, deletion, withdrawal of consent). Minors' profiles cannot appoint a Manager.

8. Your rights as a Washington consumer (RCW 19.373.040)

If you are a Washington consumer, you have the right to:

• Confirm and access — to confirm whether we are collecting, sharing, or selling your consumer health data, and to access that data, including a list of all third parties and affiliates with whom we have shared it, together with an active email address or other online mechanism you may use to contact those third parties (RCW 19.373.040(1)(a)). (We do not sell your data and have no affiliates that receive it; the third parties are the processors listed in Section 7, and you may reach them through us at privacidade@bas-ai.com, or directly using the contact details on each processor's own privacy page.) You can also export your record in the app (FHIR R4 and PDF).
• Delete — to have your consumer health data deleted. When we receive and authenticate a deletion request, we delete your consumer health data from our active systems and instruct our processors to do the same. Because our processors only hold your data within our own database and storage (Supabase), or held only transiently by Anthropic, which we require by contract to delete within a limited period (as a rule about 30 days, subject to legal or abuse-prevention exceptions), or with no health content at all (Resend), removing it from our systems removes it at the processor as well. Residual copies present in routine backups roll off within the backup retention window and are not restored to active use.
• Withdraw consent — to withdraw your consent to the collection and sharing of your consumer health data at any time. You can turn off a processing purpose (for example, "AI Processing" or "International Transfer") directly in the app; after withdrawal we stop the corresponding processing.
• Delete your on-device pregnancy, contraceptive, and lactation states in one tap — the pregnancy trimester and the contraceptive/lactation states (Section 3) never leave your device except transiently during an analysis you run, are never stored on our servers, and can be erased at any time in Profile › Privacy (or by turning off the corresponding on-device consent); the pregnancy trimester also expires on its own after about 40 weeks. We never sell or share reproductive or pregnancy data (RCW 19.373.070 / .110).

No discrimination for exercising your rights (RCW 19.373.100). We will not discriminate against you for exercising any right under this policy — for example, by denying you goods or services, charging you a different price or rate, or providing a different level or quality of service — except to the limited extent that your consumer health data is strictly necessary to provide a product or service you have specifically requested and you have withdrawn or withheld consent for that data, in which case we may be unable to provide that specific feature.

How deletion works in MyHealth. You can delete your account directly in the app, in Profile › Privacy › Delete my account. On confirmation we permanently remove, in cascade, your encrypted identity vault and all clinical data (exams, conditions, medications, vaccines, documents, measurements, history, appointments, AI conversations, sleep, wearable scores, device events, lifestyle habits, medication-intake and check-in logs), your uploaded files, your support tickets, your wearable connection data, and your AI usage/quota metadata — including the data of any dependents you manage — and we close your account. Where you manage a minor, deletion offers you the option to transfer guardianship of that minor to an existing co-guardian (so the minor's record survives with them) instead of deleting it.

For Washington consumers, we treat the identifiers tied to your health account (name, email, and the account number we assign) as consumer health data and delete them, in readable form, on your request — we do not keep them as text. Two categories of minimal, dissociated data may survive, neither treated as your consumer health data: (1) a minimal tax/accounting record for a consumer who actually completed a purchase, kept encrypted and dissociated from the health-account context and held solely to meet a legal accounting obligation; and (2) a minimal, pseudonymized forensic security index — described below — retained for every deleted account (including minors) solely for security and fraud prevention. Neither is used to infer your health status.

What remains after deletion is at most: (a) a de-linked, pseudonymized record of consent events (cryptographically dissociated from your identity), kept only to evidence that consent was given and withdrawn; (b) security/access logs kept for a short period (up to six months) that record metadata of access (time, action, source IP, and device user-agent) and never the clinical content — used only for security and fraud detection, never to infer your health status; and (c) a minimal, pseudonymized forensic security index that survives for every deleted account, containing at most (i) irreversible HMAC-SHA256 codes of your search identifiers (email, Apple ID, and, where collected, phone and national ID), computed with a dedicated secret ("pepper") guarded in a vault (Vault), encrypted by a root key managed outside the database and never exposed, so the code cannot be reversed to the original value; (ii) the recent IP addresses from your access log, in text; and (iii) your pseudonymous account number (account_ref) and minimal custody metadata (account creation/deletion dates, jurisdiction, retention term) — with no health data, no name, and no email in readable form. Because this index is not readable and is held apart from any health record solely to answer a lawful request from an authority and to establish, exercise, or defend legal claims and prevent fraud, we do not treat it as the consumer health data subject to your deletion right. It is retained for the prescriptive period applicable to the exercise or defense of legal claims and response to authorities — set by default to the same duration as the applicable tax-record term (about 5 years in Brazil, the United States, and most jurisdictions; 6 years in the UK and Canada; 10 years in the EU), a period we consider proportionate to that purpose, after which it is purged. Minors are included, but on a reduced term proportionate to the fraud-prevention purpose (never the tax term, which does not apply to a minor who does not transact), subject to a best-interest-of-the-child proportionality assessment and DPO/COPPA sign-off.

9. How to exercise your rights, and how to appeal

To make a request (confirm/access, delete, or withdraw consent), use either:

• In the app — most actions are self-service: review and export your record, delete your account, and turn purposes on or off in Profile › Privacy and Profile › Consents.
• By email — write to privacidade@bas-ai.com (or dpo@bas-ai.com) with the subject "Washington MHMDA request" and tell us which right you wish to exercise.

We take prompt steps to authenticate your request (to protect your data we may ask you to verify your identity or your control of the account). We respond within 45 days of receiving the request; if reasonably necessary, we may extend once by an additional 45 days and will tell you why within the first 45 days.

Authorized agents. You may use an authorized agent to make a request on your behalf; we may require proof of the agent's authority and verification of your identity.

Appeals. If we decline to act on your request, we will tell you why. You may appeal by replying to our decision or writing to privacidade@bas-ai.com (or dpo@bas-ai.com) with the subject "Washington MHMDA appeal." We will respond to the appeal within a reasonable time and explain our decision. If your appeal is denied, you may contact the Washington State Office of the Attorney General (https://www.atg.wa.gov/file-complaint).

10. No sale; no targeted advertising

We do not sell consumer health data and do not seek valid authorization to sell it. We do not use consumer health data for targeted advertising, profiling for advertising, or sharing with data brokers. Sharing with the processors listed in Section 7, under contracts that limit them to our documented instructions, is processing — not a sale under the MHMDA. If this ever changes, we will update this policy and obtain any consent or authorization the law requires before doing so.

11. Geofencing

We do not use geofences around health care facilities, and we do not use precise location to identify or track consumers seeking health services (RCW 19.373.090). We do not collect precise geolocation at all.

12. Security

We protect consumer health data with encryption in transit and at rest, authenticated field-level encryption (AES-256 via pgsodium) of the identifiers held in a separate vault, strict row-level isolation between accounts, server-side enforcement of consent on every operation, access controls with security/access logging, and restriction of access to only the personnel and processors for whom it is necessary (RCW 19.373.050). No method of transmission or storage is perfectly secure, but we maintain technical and organizational measures appropriate to the sensitivity of health data.

13. Changes to this policy

We will not collect, use, or share categories of consumer health data, or use it for purposes, not described here without first updating this policy and, where required, obtaining your affirmative consent. Material changes will be posted here with a new version and effective date. A prominent link to this standalone Consumer Health Data Privacy Policy is published in the footer of our MyHealth homepage (www.bas-ai.com/myhealth), distinct from the general Privacy Policy link, as required by RCW 19.373.020(1)(b).

Changelog:

• 2026-07-25 (v3.13): The come-back invitation may also be delivered by remote push — delivery means only. The neutral invitation to return after a stretch without using the app already existed (v3.6). Its trigger is only the time since you last opened the app — an app-usage signal, which is not consumer health data under RCW 19.373.010(8): it does not identify past, present, or future physical or mental health status, and no inference about health is drawn from it. The body remains fixed and neutral, carrying no consumer health data. What changed is that the notice may now be sent from our server (APNs) instead of only being scheduled on the device, using the same technical delivery token already disclosed. No new collection, no sharing, and no sale (RCW 19.373.100) — no consumer health data is transmitted in the push. Withdrawal remains immediate and free in Profile › Notifications.
• 2026-07-19 (v3.12): Personalized notifications with your own consumer health data — a display change, not a new collection or share. By founder (sole Controller/DPO) directive of 2026-07-19, notifications on your device may now include, in the body, a summary of your own consumer health data already in your record — e.g., last night's sleep (duration/efficiency/deep sleep) versus your own average; your daily glucose average and time in range (descriptive, never an alarm or clinical threshold); your activity versus your average and milestones; a lab marker's name and how it changed over time; a weekly/monthly summary with real numbers; and your own analysis-ready notice may name the analysis theme/panel. This is a change in how consumer health data you already share is displayed to you, on your own device — not a new collection, and not a sale or share (RCW 19.373.070 / .110 — we continue to neither sell nor share). Non-sensitive personalized summaries are on by default with a per-category opt-out in Profile › Notifications; iOS hides lock-screen previews until you unlock (default "When Unlocked," or "Never"); they are adult self-only (minors'/managed profiles never carry health data in the body); and they stay descriptive — never a diagnosis, medical judgment, cause, efficacy claim, or urgency. Sensitive-category domains keep their existing protections: mental-health and cycle/reproductive content remain out of any notification; alcohol/substance and medication-adherence content stays off by default, appearing only under the dedicated per-category consent (RCW 19.373.030) you already gave plus that category's own notification toggle, and medication notices never frame a missed or late dose. No new processor and no new international transfer. Basis: for personalized service notices from your own data to your own device, performing the service you configured with granular opt-out; for the sensitive categories, your affirmative, per-category consent (RCW 19.373.030). Triggers re-acceptance (the acceptance screen reappears).
• 2026-07-19 (v3.10 + v3.11): Two consolidated rounds, four disclosures. We continue not to sell consumer health data and do not use it for targeted advertising; there is no new processor and no new international transfer in any of them. (A) Mental-health data — separate, per-category consent (Sections 3 and 8): mood (State of Mind) and well-being questionnaires (GAD-7 for anxiety, PHQ-9 for depression) imported from Apple Health only after a dedicated, separate consent (mind_import, off by default, presented apart from the Terms and the general clinical consent — RCW 19.373.030 per-category authorization). We keep only the daily mood average and, for the questionnaires, only the total score plus Apple Health's classification (item-level answers discarded). Only the weekly mood trend may be shared with our AI provider, and only under a double consent (also the sensitive Health Diary, daily_journal_ai); the GAD-7/PHQ-9 questionnaires and the ring's stress index are never shared with the AI; no mental-health content on the home screen or in notifications; unavailable to minors/managed profiles; withdrawing consent deletes everything. (B) Contraceptive and lactation states — on-device only (Sections 3, 8): the same on-device design as the pregnancy trimester (iOS Keychain, never written to our database, never synced), sent to our AI provider only transiently at the moment you run an analysis to calibrate lab reference ranges; cycle deviations from Apple Health (infrequent/irregular cycles, persistent intermenstrual bleeding, prolonged periods) surface as descriptive findings under the cycle import you already control; the AI chat still receives no cycle data; we still do not import the Apple Health "pregnancy test" or sexual activity; reproductive data is never sold or shared (RCW 19.373.070 / .110). (C) Observed medication adherence (Section 3; iOS 26+): only doses marked as taken, matched to a medication you already registered — no surveillance (absence is never a missed dose; no missed-dose notification); only a day-count aggregate over a 30-day window is shared with the AI (never a percentage or judgment); unavailable to minors/managed. (D) Clinical Records — United States only (Section 3): read-only FHIR import of your own lab results (LOINC), immunizations, medications, clinician-recorded conditions/diagnoses, procedures, and allergies — free-text notes and insurance/coverage never imported — available only for US accounts and only once Apple grants the entitlement (invisible and inactive until then). All are collected only with your consent or as strictly necessary (RCW 19.373.030), treated with the same protections as the rest of your consumer health data, and shown descriptively — human-in-the-loop, never a diagnosis, staging, or significant decision. Enumerated in full in the general Privacy Policy (v3.10 and v3.11). This triggers re-acceptance (the acceptance screen reappears): the mental-health/reproductive additions carry a dedicated per-category consent, while adherence and US-only Clinical Records are a transparency update under consents you already granted.
• 2026-07-19 (v3.9): Added more Apple Health / wearable categories of consumer health data now imported under your existing per-source consent (RCW 19.373.030) — sleep-apnea events, sound-exposure (audio) notices, at-home spirometry (FVC/FEV₁/peak flow) and inhaler use, Oura hypnogram / sleep-window detail, symptoms, nutrition, gait/mobility, audiogram / audiometry, an eyeglass prescription (display-only), insulin and alcohol entries (display-only), and the ring's vascular age, pulse-wave velocity, and temperature-deviation estimates. They are collected only that you provide or authorize, treated with the same protections as the rest of your consumer health data, and shown descriptively — never a diagnosis, staging, or target; insulin and alcohol are display-only and are not shared with our AI provider. Oura enhanced-tag annotations reconciled (Sections 3 and 7): the free text (custom name, comment) is now discarded at import and never stored (stronger minimization than the v3.8 description); we keep only the standardized category code, which — aggregated by week, never free text — may be shared with our AI provider only while you keep the sensitive Health Diary (daily_journal) on; the "separate, explicit consent" previously described as absent now exists = daily_journal. We also now store a pseudonymous identifier of your WHOOP profile (the numeric user_id the records already carry — never your name or email) solely to route WHOOP/Oura update-and-deletion webhooks to the right connection; the webhook carries no consumer health data. We continue not to sell consumer health data and do not use it for targeted advertising; there is no new processor (Supabase, Anthropic, Resend unchanged). Enumerated in full in the general Privacy Policy (v3.9). This is a transparency update under the consents you already granted and triggers re-acceptance (the acceptance screen reappears; whoever already accepted v3.8 simply confirms they have read it — no new mandatory affirmative consent).
• 2026-07-18 (v3.8): Consolidated round, six changes. (a) Free-text Oura wearable annotations added as a category of consumer health data (Section 3): the annotations you record in the Oura app (type, custom name, free-text comment) are imported with maximum protection — visible only to you (excluded from family sharing), never shared with our AI provider (fail-closed; also stated in the Anthropic row of Section 7), never logged, and always deleted when you disconnect the wearable; they require Oura's additional "tag" OAuth scope (older connections must reconnect). Collection remains under your existing per-source Oura consent (RCW 19.373.030); no sale, no advertising use. (b) Continuous glucose monitor (CGM) minimization (Section 3): CGM days imported from Apple Health are stored as daily aggregates only (mean, min, max, variability CV, and % of the day within the 70–180 mg/dL AGP display range) — raw continuous readings are never stored; spot/capillary readings remain normal measurements; only the aggregates can enter the consented AI context (Section 7). (c) Care team in the AI analysis context (Sections 5 and 7): the name and specialty (and, if provided, institution and reason) of your registered Care Team professionals are included in the consented AI analysis context — never their phone, email, address, or registration number; the same handling the chat already applied; no new processor. (d) Educational, age/sex-based screening reminders (Section 5): a deterministic, on-device, fixed-rule engine may show an in-app card (never a notification) using only your date of birth and sex at birth (already collected); no test results, conditions, or individual risk assessment; adult self-only; dismissible/deactivatable; no consumer health data is shared to provide it. (e) Generic AI-generated educational library (Section 5): educational texts may be AI-generated per abstract topic with no consumer health data sent for the generation; on-device selection only. (f) Retention minimization for wearable series: raw daily wearable metric series may be condensed after 13 months into weekly summaries (min/mean/max/count) and after 36 months into monthly ones — a storage-limitation measure that reduces, and never expands, retained consumer health data; manually entered and clinical measurements are never condensed. No new processor (Supabase, Anthropic, Resend unchanged); we continue not to sell consumer health data. Triggers in-app re-consent.
• 2026-07-18 (v3.7): Added self-reported pregnancy status as an on-device-only category of consumer health data (Section 3) and a new purpose with separate affirmative consent for it (Section 5, purpose pregnancy-state-1.0, RCW 19.373.030). You may optionally record a pregnancy stage as a trimester enum (not pregnant / first / second / third trimester / postpartum, plus "prefer not to say"); for this feature we collect only the trimester — never your last menstrual period (LMP) or estimated due date (EDD). It is stored only on your device in the iOS Keychain scoped to this device (excluded from iCloud Keychain and backups), per profile, never in our database, never in your lifestyle facts, and never synced; it expires after ~40 weeks and is deletable in one tap. It is available only on your own adult profile — not on minors' or managed profiles (enforced fail-closed on our server). Only when you run an analysis or send a chat message is the trimester sent to Anthropic (United States), transiently and never stored by us, to calibrate the reading of your labs for pregnancy/lactation ranges — reflected in the Anthropic row of the Section 7 sharing table ("self-reported pregnancy status (trimester enum), transient, only at the moment of analysis, under pregnancy-state-1.0 consent"); automatic/proactive and large-record batch analyses never receive it, and our AI is instructed never to write pregnancy into your conditions/alerts/problem list/summary, backstopped by a deterministic server-side scrub with a regression test. We reaffirm we never sell or share reproductive or pregnancy data (Sections 7 and 8, RCW 19.373.070 / .110). We also stopped reading and persisting Apple HealthKit's pregnancy-test data and purged the legacy (migration 0322); the imported-cycle list no longer names it (Section 3), while imported menstrual-flow data is unchanged. No new processor (Supabase, Anthropic, Resend unchanged). Triggers in-app re-consent.
• 2026-07-18 (v3.6): Refined three notification behaviors (Section 5, uses/disclosures), with no new consumer health data collected, used, or shared. (a) The come-back reminder after a stretch without opening the app (around one and three weeks) moves from the inference-based headline consent to the neutral service track (pre-enabled alongside the other local reminders), because it is triggered only by the time since you last opened the app — an app-usage/engagement signal, not consumer health data — and its body is neutral (no health data, no number, no blame; the timer resets each time you open the app). (b) The Question of the Day notice may carry the question itself in its body, but only for a closed list of everyday, non-sensitive prompts (coffee, energy, hydration, a change in routine, and a generic "how did your body respond to your workout") — already disclosed as non-sensitive daily contexts — never a sensitive prompt (alcohol, night context, stress), a symptom, a medication/appointment prompt, or any inference; days that land on a tracked complaint keep the neutral text. (c) The local analysis-ready notice may state how many exams were organized (an aggregate count), never a name, marker, or value. Because the come-back reminder now applies by default to all users, we treat this as a change to the described treatment and trigger in-app re-consent; no new processor; no new category of consumer health data collected (dormancy is engagement metadata, not consumer health data; the count is aggregate).
• 2026-07-17 (v3.3): Reconciled Sections 1 and 8 with the code that runs account deletion, correcting the prior statements that the account identifiers are simply "deleted" and that "minors have their identity deleted with the rest of the record." We now disclose that, on deletion, we do not retain these identifiers in readable form: what survives is only an irreversible HMAC code of your search identifiers, kept in a minimal forensic security index apart from any health record, which — because it is not readable and is held solely for security and fraud prevention — we do not treat as the consumer health data subject to your deletion right (Section 1). The "what remains after deletion" list (Section 8) is opened with item (c): a minimal, pseudonymized forensic index retained for every deleted account (including minors), containing at most (i) irreversible HMAC-SHA256 codes of email/Apple ID/phone/national ID (the HMAC "pepper" guarded in a vault (Vault), encrypted by a root key managed outside the database and never exposed); (ii) recent IP addresses in text; and (iii) the pseudonymous account number (account_ref) and minimal custody metadata (creation/deletion dates, jurisdiction, term) — no health data, no name, no email in readable form. Its term is the prescriptive period for the exercise/defense of legal claims and response to authorities, set by default to the applicable tax-record duration (≈5y BR/US/most; 6y UK/CA; 10y EU) as a proportionality proxy; minors are kept on a reduced, proportionate term subject to best-interest and DPO/COPPA sign-off. Also disclosed that access-log metadata includes the device user-agent (Section 8). No new processor; no new category of consumer health data collected — a disclosure-accuracy correction over data the deletion routine already retains; a site-published clarification, effective on posting.
• 2026-07-16 (v3.2): Activated AI-assisted support (drafting and translation), updating Sections 5 and 7 from the prior "built but not currently operating" framing to the active state, truthfully and hedged. For logged-in users, AI-assisted support runs only under a new, dedicated, unbundled consent (support_ai_share) — separate from and independently refusable of the general AI-processing consent, off by default (the paid product works fully if declined) — together with the existing international-transfer consent; the support text is minimized (best-effort identifier redaction, not de-identification) before sending, and the clinical record is never sent. For people who email support without an account, handling is consent-first: nothing is sent to AI until the sender grants two separate consents (to process the message, and to transfer it to Anthropic in the United States); if they decline, a person replies with no AI. A human reviews every draft/translation before it is sent. The transfer is covered by our existing Data Processing Agreement and EU Standard Contractual Clauses with Anthropic — the same terms governing record analysis, extraction, and chat, which apply to all data we submit to Anthropic's API (no support-specific agreement is required — this supersedes the v3.1 note below stating that a support-scoped agreement "remained to be executed": on review, the existing Anthropic DPA/SCC governs all data submitted to Anthropic's API and is not scoped by use case, so no separate support agreement was ever required); contractual non-training applies and retention follows Anthropic's own contractual limit (as a rule ~30 days, subject to legal/abuse-prevention exceptions — not a MyHealth-guaranteed deletion date, not zero-retention). No new processor (Supabase, Anthropic, Resend unchanged) and no new category of consumer health data. This is a Washington-state disclosure document reflecting the activation of an already-listed capability; the underlying dedicated support_ai_share consent is captured in-app under the general Privacy Policy and Terms.
• 2026-07-16 (v3.1): Clarified how the support channel is handled (Sections 3, 5, and 7), to match how it actually operates today: support you send by email without a linked account is handled only by a person and is never sent to any AI (enforced fail-closed); and the account-linked AI-assisted draft / translation capability is built but not currently operating — described as an optional, consent-conditioned use that would run only under your active AI-processing and international-transfer consents, with a human in the loop, and has not processed any support message to date. Recorded that a data-processing agreement scoped specifically to support content remains to be executed, and that we will not enable the capability until it is in force; the general Anthropic terms in effect cover record analysis, extraction, and chat. Named translation alongside drafting. Also applied MHMDA-completeness and accuracy fixes: restored and strengthened the mandatory prominent-homepage-link statement (Section 13, RCW 19.373.020(1)(b)); added a non-discrimination clause (Section 8, RCW 19.373.100); tightened the third-party contact mechanism in the access right to the statutory "active email address or other online mechanism" standard (Section 8, RCW 19.373.040(1)(a)); qualified the "no direct identifiers" statement in the Anthropic row so it does not over-state (best-effort redaction may leave an identifier in an uploaded document copy); and attributed the ~30-day Anthropic retention figure to Anthropic's own contractual term (with a legal/abuse-prevention exception — not a MyHealth-guaranteed deletion date, not zero-retention) in Sections 7 and 8. No new processor; no new category collected; no new or expanded processing (Supabase, Anthropic, Resend unchanged) — this update only describes support handling more conservatively and accurately (email support is human-only; the account-linked AI capability is built but not operating) and adds MHMDA-completeness detail, so it does not require re-consent. It is a site-published clarification, effective on posting.
• 2026-07-15 (v3.0): Added an optional "derived detail" in headline notices (Section 5): with the daily-headline consent on, the adult account holder may opt to include, in notices derived from their own consumer health data, a small detail of the data (e.g., minutes left to their own activity goal; that they slept above their usual — no "below" variant). This is a new use/disclosure surface and therefore requires separate affirmative consent (RCW 19.373.030), recorded with date/version, off by default, set per device (local, not synced), revocable at any time with immediate effect; minors and managed profiles are categorically excluded; the phrase list is closed — never a diagnosis, lab value, judgment, or urgency; 100% local (nothing is transmitted to Apple's push service). Also added closed-list fixed-body headline types (sleep/goal/new-lab-entry/partial-week/consistency), an appointment-eve prep notice, and a technical sensor-quiet notice — all fixed generic bodies under existing consents. No new processor; no new category collected. Triggers in-app re-consent.
• 2026-07-14 (v2.9): Added two optional lock-screen details, both off by default and available only to the adult account holder over their own records (Section 5, uses/disclosures): (a) the medication name and dosage in medication reminders, chosen separately per device; and (b) the vaccine name and dose in vaccine reminders. Each is a new use/disclosure of consumer health data on a device surface and therefore requires your separate affirmative consent (RCW 19.373.030), distinct from accepting the Terms, given at the point of the toggle after a notice that the lock screen can be seen by others and read aloud by Siri; each is revocable at any time with immediate effect. The content is a factual echo of what you recorded — never a purpose, drug class, due-date calculation, booster recommendation, or urgency. Minors and managed profiles are categorically excluded (hard-disabled in client and server) — a dependent's reminder always stays generic. Everything is 100% local: the medication/vaccine name is never transmitted to Apple's push service. Also added an opt-in refill / low-stock reminder (local, neutral fixed body, under the existing medication-notification consent). No new processor; no new category collected (display change only). Triggers in-app re-consent.
• 2026-07-13 (v2.5): Disclosed the non-sensitive daily contexts (coffee/caffeine, energy levels, hydration, workout perception, and routine changes) as a category of consumer health data (Section 3) and their sharing with our AI provider only in weekly aggregated form — day counts and routine-change categories, never the individual daily entry, never free text — under your active AI-processing and international-transfer consents (Sections 4 and 6). The sensitive daily journal (alcohol, stress/night context) remains not shared with the AI provider. Triggers in-app re-consent of the updated policy. No new processor (Supabase, Anthropic, Resend unchanged).
• 2026-07-07 (v2.5): Added an opt-in "novelty" notification to our purposes (Section 5): when your connected wearable or health data produces a new finding (currently poorer sleep, elevated resting heart rate, or reduced heart-rate variability), we may send you a notice that something new is in your data. Because deciding to send it is derived from consumer health data, it is off by default and requires your separate consent (RCW 19.373.030); the notice content is generic with no consumer health data, and no consumer health data is shared to send it — Apple's push service (APNs) receives only a delivery token and fixed generic text, never the finding. No new processor (Supabase, Anthropic, Resend unchanged; Apple/APNs already the push transport).
• 2026-07-05 (v2.4): Added the sensitive daily health journal — opt-in daily entries of alcohol consumption (substance use) and stress / night context (mental health) — to the categories of consumer health data (Section 3), and a separate collection authorization for it (Section 4): the journal is off by default, requires your separate, specific consent before collection (purpose daily_journal), is server-enforced, is not available on minors' profiles, and is not shared with our AI provider; withdrawing consent stops collection and deletes these entries. No new processor (Supabase, Anthropic, Resend unchanged).
• 2026-07-05 (v2.3): Added in-app support messages (to the extent you include health information) and the account number we assign to the categories of consumer health data treated as CHD; added answering and resolving support requests to our purposes. No new processor (Supabase, Anthropic, Resend unchanged).

14. Contact

• Privacy contact (DPO/Encarregado): privacidade@bas-ai.com (also dpo@bas-ai.com)
• Entity: BAS ARTIFICIAL INTELLIGENCE LTDA — www.bas-ai.com — Rua Gomes de Carvalho, 911, Vila Olímpia, São Paulo/SP, ZIP 04547-003, Brazil
• General Privacy Policy: https://www.bas-ai.com/myhealth/legal/privacidade
• Subprocessors page: https://www.bas-ai.com/myhealth/legal/subprocessadores
• Washington Attorney General (complaints): https://www.atg.wa.gov/file-complaint