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.8 · Effective: 2026-07-18

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).
• 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.
• Free-text wearable annotations (Oura enhanced tags), when you connect an Oura ring — 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). Because they are free text — and may mention, for example, mental health or substance use — we treat them with maximum protection: visible only to you (excluded from family sharing), never shared with our AI provider (enforced fail-closed; any future AI use would require your new, explicit consent), never logged, and always deleted when you disconnect the wearable. 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 status in one tap — the pregnancy trimester (Section 3) never leaves your device except transiently during an analysis or chat you run, is never stored on our servers, and can be erased at any time in Profile › Privacy (or by turning off the pregnancy-state-1.0 consent); it 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-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