Consumer Health Data Privacy Policy

What this document answers

This is the consumer health data policy the Washington My Health My Data Act requires. It is deliberately narrow, because that Act asks for a standalone document carrying only what it calls for.

What counts as my health data here? Sections 2 and 3.
Where does it come from, and who else sees it? Sections 4 and 5.
What can I switch off? Section 7.
What are my rights, and how long do you have? Sections 8.1 and 8.2.
What does deleting actually reach? Section 9.
What if you say no? Section 10.

If you are in Nevada, your rights and deadlines are different and they are set out in our Nevada Consumer Health Data Privacy Notice. Everything in sections 2 to 5 and 9 below applies to you too, and that notice points here for it.

Everything else about your data, legal bases, security, children, international transfers, the website, is in the Privacy Policy, which applies to you as well.

1. Who we are and what this policy covers

This document is only about consumer health data. Washington law requires it to be kept separate from our general Privacy Policy, so it is narrower: it does not repeat the Privacy Policy’s sections on legal bases, security, children, international transfers, or the glumea.com website. For all of that, read the Privacy Policy.

What it does cover is the glumea app: what it collects, where that goes, and what you can switch off or have deleted. Paweł Milewski Software Development (the Operator, “we”, “us”, “our”) provides glumea (the App) and glumea.com (the Website); this policy is about the App. Our postal address and email are in section 13.

Two further documents apply alongside this policy and the Privacy Policy: the Terms of Service and the Medical Disclaimer.

It applies to you if you are a resident of Washington, or if your consumer health data was collected while you were in Washington (My Health My Data Act, RCW 19.373).

Nevada has its own notice. Nevada’s law (NRS 603A.400 et seq.) gives you different rights on different deadlines and asks us for four disclosures Washington does not, so those live in the Nevada Consumer Health Data Privacy Notice rather than here. Sections 2 to 5 and 9 of this document describe what glumea does with health data, and they apply wherever you live.

2. What we mean by consumer health data

Under the Washington My Health My Data Act, consumer health data is personal information that is linked or reasonably linkable to you and that identifies your past, present, or future physical or mental health status, expressly including bodily functions, vital signs, measurements, diagnoses, treatment, and medication.

Most of what glumea records falls inside that definition. A blood glucose reading, an insulin dose, and a medication name are clear examples.

Because glumea is a diabetes app, the fact that you have an account is itself health-revealing. We therefore treat your account identifier and the email address on your account as consumer health data for the purposes of this policy, even though they are not health measurements. For the same reason we treat the pseudonymous device identifier and the server request logs described below as consumer health data.

3. The categories we collect, and why

Category	What is in it	Why we collect it
Blood glucose readings	Value, date and time, context tags (including tags you type yourself), free-text notes	To show you your readings, charts, and Time in Range statistics, and to schedule the recheck reminders described in the Medical Disclaimer
Food and carbohydrate entries	Carbohydrates, optional protein, fat and calories, and the name you type	To let you log and review what you ate alongside your readings
Insulin, tablet, and injectable doses	Units, counts, dose times, and which medication they belong to	To let you log and review your treatment
Your medication catalogs	Medication names (for example an insulin brand), type, strength, dosing interval, and pharmacokinetic parameters	So doses can be logged against a real medication and the App can display them correctly
Medication schedules	Which medication, the time of day, the weekdays, and whether the reminder may fire during Quiet hours	To deliver the medication reminders you set up
Check reminders and notification settings	The times and weekdays for your glucose-check reminders, your Quiet hours window, sick-day mode, and whether reminder detail is shown on your lock screen	To deliver the reminders you asked for, and to hold the settings for reminders that are not built yet. Scheduled glucose-check reminders are not delivered today: you can set the times, and nothing arrives. Medication reminders and the recheck reminders after a very low or very high reading are delivered. Your Quiet hours and lock-screen settings stay on your device
Body measurements	Weight history and height	To show weight over time and to display your entries in your chosen units
Diabetes and treatment profile	The nickname you choose, your age, your gender if you give it, diabetes type, insulin delivery method, and whether you treat with tablets, injectables, or diet	To set the App up for the way you actually manage your diabetes
Therapy settings	Your glucose target range, insulin sensitivity factor (ISF), and insulin-to-carbohydrate ratio (ICR)	To show your target range on charts and keep your figures in one place. Your target range is written into the PDF glucose report if you generate one, and your insulin-to-carbohydrate ratio is too when the report’s window contains an insulin dose. The CSV export carries neither, and the insulin sensitivity factor is in neither the CSV nor the PDF, it is in the encrypted `.glumea` archive, which carries your whole account. The App never uses them to calculate or recommend a dose. The insulin sensitivity factor is used for one other thing, though: the hypo-risk wording shown beside active insulin, as the Medical Disclaimer describes
Data imported from Apple Health or Health Connect	Blood glucose, weight, and carbohydrate records	Only if you connect it: to save you re-typing readings your other devices already recorded. Imported records become ordinary entries and follow the same path as anything you type, including to our servers when cloud sync is on
Values the App derives on your device	Estimated active insulin, and the hypo-risk wording and approximate lowering range shown beside it; average glucose and its spread; Time in Range; estimated A1C (GMI); the suggested time for your next reading; and the Good / Fair / Critical label on your latest reading	To show you a summary of what you logged. These are calculated on your device, and the Medical Disclaimer sets out what each of them is and is not
Account identifier and email	Your account UUID and sign-in email	To give you an account and to sync your entries to it
Subscription status	Your account identifier and whether glumea+ is active, as reported by Apple or Google through RevenueCat	To unlock what you paid for. It carries no readings, medications, or entries
Product-analytics events	That an entry of a given kind was saved (glucose, insulin, tablet, injectable, food, weight), whether you saved it from the form or from a reminder’s action button, how many rows that save wrote, and whether you logged it within about fifteen minutes of the moment, later the same day, or backdated; that you opened the entry form, and which kind it opened on; that the App was launched, and separately that it was launched for the first time after install; that you completed sign-up or sign-in, and that an emailed code was verified or refused, with which flow it belonged to; which onboarding steps you finished, including the ones about diabetes type and treatment, and that you finished your profile; which screens you opened, as fixed route names; that you tapped a reminder, and which kind; that you were asked for notification permission, and whether you allowed it; whether you connected Apple Health or Health Connect, whether the operating system granted or refused the permission, that you asked for an import, and counts of imported records with what triggered the import; that you generated an export, in which format, and whether you shared it; that you turned analytics off; subscription and purchase events; and your language, theme, unit preferences and subscription status. Never a value, a name, a note, or anything else you typed. Signed-in events use the account identifier; pre-sign-in events use a pseudonymous device identifier	To understand which parts of the App are used. These events carry health inferences. Current builds enable the analytics setting by default, which is not an affirmative opt-in design
Technical and device information	The pseudonymous device identifier used for pre-sign-in analytics; device model, operating system, app version, release, build and similar values added by PostHog, Sentry and RevenueCat SDKs; and the network address seen by their servers	The SDKs collect these values. Current builds enable analytics and diagnostics settings by default. None of these fields is a reading, medication or value you typed
Server request logs	The address, path and time of the requests your device makes to our servers, and, when a request fails, the status, the path, the time and the error message	To run the backend and investigate failures. They hold no entries, medications, or readings, and nothing you typed. They are listed here because a request to glumea’s backend is linked to your use of a diabetes app

We use consumer health data for those purposes and no others. We do not use it for advertising, ad targeting, profiling, credit or insurance decisions, or research, and we do not use it to make automated decisions about you.

Some of the above never leaves your device at all: your check-reminder times, your Quiet hours, sick-day mode, your lock-screen setting, and your health-connection settings are stored locally only and are not sent to our servers. Your medication schedules are the exception: they belong to the diary, so they are copied to our servers when Cloud sync is on, because a medication reminder has to survive a new phone.

4. Where it comes from

There are six sources:

You, when you type entries into the App or set up your profile, medications, and reminders.
Your device’s health platform: Apple Health or Health Connect, when you connect it and grant the operating-system permission. This is read-only: glumea never writes anything back into Apple Health or Health Connect, and on iOS it has no entitlement that would let it.
The App itself, when it derives values on your device from what you entered.
Apple, Google, and RevenueCat, which tell us whether your glumea+ subscription is active. That is a payment fact attached to your account identifier; it carries no readings, medications, or entries. It reaches us both in the App and as a server-to-server message from RevenueCat to our backend.
The PostHog, Sentry and RevenueCat SDKs inside the App, which collect the device and network values listed in section 3 by themselves. We do not set them.
Our hosting platform and our backend, which record the server request logs described in section 3.

Apple Health and Health Connect count as a source. The readings they hold were recorded by something else, and importing them brings them into glumea as ordinary entries, including to our servers when cloud sync is on.

We do not buy consumer health data. Apart from the health platform you connect and that subscription signal, we do not receive it from anyone, not from data brokers, advertising networks, health-care providers, or insurers.

5. Who else handles it, and what they get

Nothing in this section is a sale. The table identifies the companies that operate parts of glumea and the data each service can receive. Apple and Google are included for completeness: they operate the stores, hold their own purchase records and act independently for that store data. A provider SDK inside the App can also collect device and network information that we neither configure nor receive. RevenueCat’s SDK does so, and RevenueCat describes that processing in its own privacy notice.

Who	What they receive	Why	Contact
Google Cloud (Google), Cloud Run and Cloud SQL, region `europe-west1`	Your account email, your profile and your therapy settings, which are held on our servers whether or not you use cloud sync; and, when Cloud sync is on, your diary as well: entries, medication catalogs and medication schedules	They host our backend and database. This is where the server copy of your data lives. Google Cloud Logging also holds our server request logs, described in section 3	support.google.com/policies/contact/general_privacy_form
Zoho ZeptoMail	If production email delivery is enabled: the destination email address and verification, password-reset or email-change message. No entries, medications or readings	To deliver account emails when that function is enabled	[email protected]
PostHog (EU Cloud)	While analytics is enabled: the events listed above, the account identifier after sign-in or a pseudonymous device identifier before sign-in, selected preference attributes, SDK-added technical properties, and the network address: PostHog receives it with each request and derives an approximate location from it; we have not switched on PostHog’s option to discard it, so it is stored with the event	Product analytics	[email protected]
Sentry (diagnostics, European Union region)	While diagnostics is enabled: filtered crash and error reports, SDK-added device and app data, the network address (the App is configured not to send it, so no IP address is attached to the report, but Sentry’s servers necessarily see the address the report arrives from), and platform release-health signals that can bypass the App filter	To find and fix crashes	[email protected]
RevenueCat	Your account identifier and your glumea+ purchase and subscription state. Our code attaches nothing else to it: we set no email address, no name, no device identifier and no subscriber attribute of our own. RevenueCat may hold subscriber attributes of its own about you, and where it does they travel back to us inside the messages it sends our backend, which we store as they arrive, section 9 says what happens to those. Their own SDK collects some device and network information by itself that our code neither sets nor suppresses: the network address, from which it infers an approximate location, the device type, the operating system and app version, and the store purchase history it reads; our code does not switch on its device-identifier collection, so no advertising identifier is attached. No entries, no medications, no readings	To tell the App whether your subscription is active	[email protected]
Apple and Google, which operate the stores glumea+ is sold through	Purchase and subscription records. No entries, no medications, no readings	They take the payment and hold the billing relationship with you; who the seller of record is depends on the store and your territory, as the Terms of Service explain. We never see your card details	apple.com/legal/privacy/contact · support.google.com/policies/contact/general_privacy_form

No affiliate of Paweł Milewski Software Development receives consumer health data, and we do not disclose it to advertisers, data brokers, insurers or employers. A binding legal order can require disclosure. Any notice about such a disclosure is governed by applicable law.

The table states why each service is used and what it can receive. The App has no separate provider-by-provider sharing switch; the available controls are described in section 7. Provider terms and privacy notices also govern data that an SDK collects independently of fields configured by our code.

Two points about what analytics and diagnostics can and cannot carry:

Analytics cannot receive a reading, note, medication name, user-entered tag or email through the App event schema. The App uses fixed event and property allowlists. PostHog still receives health inferences about the kind and timing of activity. The current default does not provide the affirmative choice required for consent-based processing.
Diagnostic reports are rebuilt from an allowlist before they are sent, and the report carries no user, no account identifier, and no message text. Two limits: the label naming the failed operation can reveal which category of data an operation concerned (for example a glucose import), never a value; and native crash, app-not-responding, and watchdog events are produced by the operating system’s crash handler and can reach Sentry without passing through that filter.

5.1 Copies you make yourself

The PDF and CSV glucose reports, and the encrypted .glumea archive, go wherever you send them. Once you hand a file to another app, an email, or a person, it is outside our control. The .glumea archive is encrypted with a password only you know, we cannot open it, and neither can anyone you do not give the password to.

5.2 Device backups

The App’s local database is encrypted on your device with a key held in the platform keystore that never leaves that device. On Android, backup and device-to-device transfer are switched off for glumea entirely. On iOS, a copy of the database file may still be included in your iCloud backup, but it cannot be read without the key. Apple and Google therefore do not receive readable consumer health data through this path, and moving to a new phone has to go through cloud sync or a .glumea archive.

6. We do not sell consumer health data

We do not sell consumer health data and we have never sold it. Washington law requires a separate signed “valid authorization” from you before any sale; we hold none and have not asked you for one. A sale could only happen through an authorization you choose to give, which has to say exactly what is being sold and to whom, and which you can revoke.

glumea contains no advertising SDK, no advertising identifier, no attribution or measurement SDK, and no location SDK. glumea never asks for location permission and collects no precise location data: neither platform build declares a location permission, so the App cannot read your device’s location at all. The one thing carrying any geographic signal is the network address your device connects from, which our servers and the providers in section 5 see as any web service does, and from which an approximate region can be inferred. We do not use it to locate you and we do not derive or store a location from it. We do not process consumer health data for advertising, we do not share it for cross-context behavioral advertising, and we do not and cannot operate a geofence around any health-care facility.

7. Why we collect it, and what is yours to switch

Most health entries are provided deliberately by typing or importing them. Analytics and diagnostics are different: current builds enable their stored settings by default, so the present implementation does not support a claim that all optional collection begins only after an affirmative request.

Cloud sync: whether your entries are copied to our servers at all, is a glumea+ feature, and it is off until you turn it on. Turning it on takes two steps. Without an active glumea+ subscription the App shows you the subscription screen instead of switching anything on. With one, it then asks you to confirm, in a step of its own, that you agree to your health data being stored on our servers. That confirmation is your consent, it is asked every time the switch goes on rather than only the first time, and turning the switch off again withdraws it. You will find it in the Sync sheet, which opens from the cloud button at the top of the Summary or History screen; the switch inside it is called Cloud sync. With it off, new entries stay on your device. Entries already on our servers stay there until you delete them, and turning sync back on re-uploads the entries kept on your device.

Your answer to this switch is held on your account on our servers rather than on the phone. It survives signing out and it follows you to a new device, and turning it off is recorded the same way, if you turn it off while offline, the App keeps that answer and delivers it at the next opportunity rather than dropping it. If glumea+ ends, backup pauses and the sheet reads Paused, glumea+ has ended: nothing is deleted, your stored answer is left as it was, and subscribing again resumes backup on that answer without asking you a second time. Turning the switch off, and the delete your data link beside it, stay available whether or not a subscription is live.

Three things are yours to switch, in the App, at any time:

Apple Health / Health Connect: off until you connect it, and each of the three data types can be turned off individually. Settings → Integrations → Apple Health (on iPhone) or Health Connect (on Android).
Usage analytics: Settings → Data & privacy → Privacy & diagnostics. Current builds store this setting as enabled by default. Turning it off changes the stored preference, but already queued events can still be delivered on the SDK’s schedule.
Error reporting: the separate switch on the same screen. Current builds also store this setting as enabled by default. Signing out clears stored preferences but does not reliably disable an SDK that was already initialized in the running process. These defaults and lifecycle limits do not constitute affirmative consent.

The in-app delete your data control requires a live sign-in. If the session has expired, the Sync sheet reads Paused and the control requires sign-in before it can run. Mandatory rules prohibit penalizing a valid withdrawal of consent.

Your diabetes and treatment profile and your therapy settings are not covered by the switches above. Deleting the account is the only implemented way to remove them from our production database. No profile-only removal workflow is currently available through [email protected].

8. Your rights

Section 8.1 sets out the rights Washington gives you, and section 8.2 is how to exercise them. If you are in Nevada, your rights and deadlines are in the Nevada Consumer Health Data Privacy Notice instead.

8.1 If you are in Washington

Under the My Health My Data Act you have the right to:

Confirm whether we collect, share or sell your consumer health data, and access it, including the third parties and affiliates with whom it has been shared and a way to contact them. The currently published recipient and contact list is the table in section 5.
Withdraw your consent to the collection of your consumer health data and to sharing it (section 7).
Delete your consumer health data.

Washington law requires a response within 45 days after receiving a request. It permits one additional 45-day period where reasonably necessary, with notice and a reason during the first period. It also sets the rules on charges and manifestly unfounded, excessive or repetitive requests. Those statutory requirements apply independently of this policy.

8.2 How to exercise these rights

In the App: Delete account (Settings → Account details) hard-deletes your account and everything synced with it from our servers, and wipes the local database from your device. The delete your data link (inside the Sync sheet, once sync is turned off) deletes the server copy of your entries, your medication catalogs, and your medication schedules, while keeping your account and the copy on your device. It reaches no further than that: your diabetes and treatment profile and your therapy settings stay on our servers until you delete your account.
[email protected] is the general privacy contact, but no email one-time-code, off-app deletion, custom access or manual identity-verification workflow is currently implemented. Deleting your glumea account describes the supported in-app route. The implemented controls do not provide the full request process required by Washington law.

When you delete in the App, deletion from the production account tables occurs when you confirm it. Section 9 states where that deletion reaches and what survives it.

9. What deletion actually reaches

The table below sets out how a deletion is applied in each system and at each service provider.

Destination	What happens
Your device	Deleting an entry removes it from this device, and from this device only. The server copy stays, so the entry can come back on a reinstall, on a new phone, or after you sign out and sign in again, only delete your data or deleting your account clears the server. Readings imported from Apple Health or Health Connect cannot be deleted one at a time in the App at all. Delete account and sign-out wipe the local database. The database is encrypted with a device-bound key, so any copy of it that leaves this device is unreadable
Our production database (Google Cloud, `europe-west1`)	When you delete your account, the account row and everything attached to it are hard-deleted immediately, with no recovery. A single entry is different: if a deletion of one entry ever reaches our servers, the row is kept as a tombstone that still carries its value, tags and notes, so that the deletion can travel to your other devices
Our server backups	Copies of already-deleted rows persist until the backups expire, at most 7 days, and no more than six months after authentication where Washington’s statutory limit applies. Individual records are not edited inside a backup. A disaster-recovery restore can temporarily reintroduce deleted rows because no job replays past deletions
Our server logs	Our hosting platform records the address, path and time of the requests your device makes to us, and our backend writes its own line whenever a request fails, the status, the path, the time, and the error message. Neither holds entries, medications, or readings. Retention: 30 days
Zoho ZeptoMail	If email delivery is enabled, it can hold delivery records for verification and reset messages. Retention: up to 60 days of delivery logs, ZeptoMail’s standard retention. The current deletion flow does not send a provider-deletion request
PostHog (analytics)	The database cascade does not reach the analytics profile, and deleting the glumea account does not remove it. Pre-sign-in events use a device identifier instead of an account identifier. No profile-deletion request is currently sent to PostHog
Sentry (diagnostics)	The App does not attach an account identifier, email address or user record to a diagnostic report. Native reports can bypass the App filter, and no supported identifier exists for locating and deleting an individual user’s reports
RevenueCat	Keeps the account identifier and subscription history. It holds no entries, medications or readings. The cascade does not reach it, and no deletion request is currently sent to RevenueCat
Our subscription event log	Our backend stores each subscription message RevenueCat sends, including the account identifier and any subscriber attributes in that message. The rows are not attached to the account record, so account deletion does not remove them. A scheduled job removes each row 90 days after arrival; there is no earlier manual-deletion workflow
Apple / Google subscription records	Held by them under their own policies, outside our control
Copies you exported yourself	Outside our reach, see “Copies you make yourself” above

The implemented in-app deletion removes the account from our production account tables, but it does not pass a deletion request to PostHog, RevenueCat or an email provider. It also does not remove the subscription event log, which expires on its own 90-day schedule. Washington law requires deletion requests to be passed to relevant processors, affiliates and third parties; the implemented flow does not perform that statutory step.

10. If we say no

Washington law requires a written explanation and an appeal process when a request is refused. It also requires a written appeal decision within 45 days and, after a denied appeal, a method for contacting the Washington Attorney General.

No separate appeal workflow is currently implemented at [email protected], so the current process does not provide Washington’s required appeal route. Nothing in this policy limits a complaint to the Washington State Office of the Attorney General or any other right under Washington law.

11. Changes to this policy

The current version describes the categories and purposes currently used. Washington law can require an updated policy, advance notice or consent before a new category or purpose is introduced. Publication of an updated policy does not replace consent where consent is required.

12. Language

This policy is published in English, Russian, Polish and Ukrainian. The English version is the legally binding one. The other three are translations, published so that you can read the policy in your own language. Where a translation and the English text differ, the English text is the one that governs.

The exception is the law itself. Where the country you live in gives the language you were addressed in a status of its own, as the consumer protection law of several countries does, that rule applies instead of this one, and nothing here takes away a right you have under it.

A translation is published when it is ready, so it can lag behind the English text after an update. If you find a place where a translation and the English text say different things, tell us at [email protected].

13. Contact us

Email: [email protected]
Post: Paweł Milewski Software Development, ul. Franciszka Bohomolca 3 lok. 7, 31-416 Kraków, Poland