LymeHQ · Privacy
Privacy, stated plainly and checked
LymeHQ is in demo, and accounts exist. This page says what is actually collected today, what every default is, and what must still happen before we ask anyone for real health information.
What we collect today
An account, if you create one
An email address and password, held by our authentication provider (Supabase), never as plain text. The name field is optional and does not have to be your legal name. Signing up does not reveal to anyone else whether an address has an account here.
Health information you choose to enter
Symptoms, lab results, medications, and household and pet records live in a database, scoped to your account by row-level access controls. Every sharing choice starts OFF: no provider, researcher or household member sees anything until you explicitly turn a toggle on, and a provider additionally needs a care connection you control. Each change to a consent is recorded in an append-only history written by the database itself.
Beacon conversations, only with consent
Beacon (our AI companion) is off by default. Your record is sent to the AI model only after you turn the Beacon toggle on, only server-side, and revoking consent takes effect on your next message. Conversations are logged to your account.
Less than you type
Your ZIP code is cut to its first three digits before it is stored — the full five digits appear nowhere, including in our own logs. Research outputs are aggregates only, and never describe a group smaller than five people.
No analytics, advertising or third-party trackers
No Google Analytics, no advertising pixels, no session recording, no cross-site tracking. All typefaces are served from our own domain, so reading these pages sends no request to Google or anyone else. We do not know which pages you read.
Cookies: session only
Reading LymeHQ requires no account and sets no tracking cookies. If you sign in, our authentication provider sets the session cookies that keep you signed in — that is their only job. A display preference (like whether your sidebar is collapsed) may be kept in your browser; it identifies nothing.
Standard server logs
Our host (Vercel) records ordinary request logs — IP address, timestamp, page requested — as essentially every web server does. We do not use these to build a profile of you, and we do not combine them with anything else.
Links that leave the site
We link to organisations such as ILADS and to CDC data pages, and some product pages carry disclosed affiliate links. Once you follow a link you are on their site under their privacy policy, not ours.
Consent is a gate, not a promise
Onboarding asks four, every one starts off, and this is what switching a single one on actually does.
- On — this channel is open
- Off — the read stops at the gate
Every read the site does for you runs as you: the database resolves your identity, applies the rule and decides which rows come back. Where a toggle governs sending data onward rather than reading it, the gate sits in front of the request instead — a row rule can ask whether you may read a row, not whether the server may forward it.
Onboarding asks four. More exist, and they are asked later, where the feature is offered — not at signup, for something the account cannot use yet.
Switch it off and the channel closes on the very next request.
The barrier is not a wall around the platform. System work — webhooks, scheduled jobs, audit writes — runs on a connection that is deliberately not subject to those row rules, and an aggregate already released into a scheduled research refresh moves on that schedule rather than on your next request.
Nothing on this drawing is a measurement. Both halves are tested on every build: turning sharing off reaches your clinician on their very next page load, in the session they already have open — and every consent change is recorded by the database itself, proved by changing a switch with the application removed from the loop entirely.
Five, or nothing.
A group small enough to count is a group small enough to identify.
- Released as an aggregate
- Held back — too few people
A group under five does not come back smaller, or rounded, or blurred. It does not come back at all — the cell is simply absent from the result.
Enforced in the database, so no query can reach around it.
The group sizes on this drawing illustrate how the rule behaves. They are not counts of anyone in the research commons, and none of them describes a real cohort.
We test this floor on every build: a group of fewer than five people is put into the underlying records, and it must appear in no released result. The group sizes drawn here illustrate the rule — they are not counts of anyone real.
Before LymeHQ asks for real health information
The demo runs on synthetic data, and the protections above are built and tested — but the paperwork that lets a health platform hold real records is deliberately not claimed early. Still ahead:
- Signed agreements (BAAs) with every vendor that could touch health data.
- A full privacy notice reviewed by counsel, replacing this page.
- An independent security assessment.
- Strict-mode operation: session timeouts enforced, demo affordances removed.
Contact
Questions about privacy, or something on the site that looks wrong, go to privacy@lymehq.com. LymeHQ is currently built by a solo founder, so replies come from a person rather than a queue — and may take a few days.
See also our accessibility statement.