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.

Demo phase · last updated 14 September 2026

Privacy, plainly

Left: the short version, written for someone reading on a bad day. Right: the same promise in the exact words, with a real number wherever the code holds one. If they ever disagree, the exact words win, and we would treat the disagreement as a bug.

  • What we keep

    We keep what you put in, and where it came from.

    Your symptoms in five words, your lab results, your medicines by name and date, and your household. Next to each one we keep where it came from. We do not keep a score about you, because we do not make one.

    The exact terms

    Patient-entered records live in a database scoped to the account by row-level access rules. Lab results carry a data-origin field recorded at ingestion. No risk score, probability or composite metric about a person is computed or stored; the tracker’s vocabulary is words, and a composed figure is refused by rule.

    • Ruled outA wellness score, a streak, or any number that grades you
  • What leaves

    Nothing leaves until you turn a switch on. Every switch starts off.

    None is asked for at signup. The switches are on the consent page in your account, and a few are decided beside the thing they govern. If you never touch one, nothing leaves, and that is a complete answer. We will not nag you about it.

    The exact terms

    Every consent defaults to off and is written only by the patient. Each change appends to a history the database itself writes, which no application code can edit. The dashboard shows every switch and its state; an all-off state is rendered as a decision, never as an incomplete setup.

  • A clinician

    Two locks. You share your record with them, and you turn sharing on.

    Being on your team shows a clinician nothing. Turning sharing on shows them nothing unless they are on your team. Both together do. Turn either off and it is gone the next time they load the page.

    The exact terms

    A provider read requires an active care relationship and the provider-sharing consent, both checked inside the database policy. Revocation is effective on the provider’s next request; nothing is cached. Every read is written to an append-only audit log under the reader’s identity.

    Next page loadaccess ends on revoke — no grace period

  • Beacon

    Beacon reads your record only if you say so, and only on our server.

    Beacon is off to start. If you turn it on, your record is sent to the model from our server, never from your browser. Turn it off and the next message is refused. Every answer is read in full before you see it.

    The exact terms

    The Beacon consent gates every model call; the context that a call requires can only be minted by the function that checks it. Revocation applies on the next message. Replies are buffered and judged whole by a safety floor before delivery; a withheld reply is recorded as a refusal.

    Next messagerevocation has no grace period

  • Research

    Researchers get counts, not you. Some things cannot be un-counted.

    If you turn research on, your record joins others. A researcher sees how many people match a question, never your row. Groups under five are hidden. You can stop future use. A count already published cannot be pulled back.

    The exact terms

    Research contribution exposes aggregates only: cells under five withheld inside the database, geography no finer than three ZIP digits with restricted prefixes collapsed, ages in ten-year bands with ninety and over grouped. Withdrawal removes the record from every later query; analyses already run are not altered, and the consent copy says so.

    Next querywithdrawal applies to every analysis run after it

    • Ruled outAny export that could identify a person
  • People who work here

    There is no screen that opens your record for us.

    The patient pages refuse an administrator’s login. Administrators see queues and counts. That is tested, not promised.

    The exact terms

    Route access is a role matrix enforced in the middleware and re-checked on every protected page; the administrator role is refused the patient route group, and the refusal is written to the audit log. The matrix is exercised by a check against real logins.

  • How long

    As long as you have an account. Ask, and the record is erased.

    Your record stays while your account does. To delete it, email us from your signup address; a person acts on it, and the record is erased then. Three things stay with your name removed: the history of your consent choices, the log of who looked at what, and any note a clinician wrote about their own thinking while you shared with them. No end date has been set for any of them yet.

    The exact terms

    Deletion on request erases the record, including check-ins and journal, labs and every uploaded file, medications, costs, the entries written in the person’s own words, the health profile and the current switch settings, claims and connections with their credentials, care grants, messages, notifications, any tick-bite reminders for the same address, and the login; the household and its pets too when the person was its only member. Three things survive: the consent history and the access log, both append-only, against an internal identifier that no longer names anyone; and a clinician’s note about their own reasoning, with its link to the person cut. The two append-only tables cannot be minimised after the fact, and no retention limit for any of the three has been decided; counsel will set one.

    No limit seton what survives a deletion — stated, not hidden

  • Reminder emails

    A reminder address is kept for the reminders, then deleted.

    If you ask for the three tick-bite reminder emails, we keep your address for those sends and nothing else. Stop them with one press. After the sequence ends, the row is deleted.

    The exact terms

    A reminder row holds a contact, the signup day, what was sent and the stop switch. Stopped and completed rows are deleted 60 days after they finish, on every environment, by the same sweep that sends.

    60 daysafter the sequence ends or is stopped

  • Signed-in sessions

    Walk away and you are signed out.

    In strict mode, thirty minutes without activity signs you out. The demo tracks that time but does not sign you out yet, and this page says so rather than pretending.

    The exact terms

    The middleware tracks last activity for every session and enforces a thirty-minute inactivity timeout when HIPAA mode is on. In the demo the timeout is tracked and not enforced, so turning strict mode on needs no backfill.

    30 minutesidle, enforced in strict mode; tracked only in the demo

  • Getting it out

    You can take the whole thing with you.

    One download gives you your whole record in a standard health-record format. You do not need to turn anything on. Nobody is told.

    The exact terms

    The patient export is a FHIR R4 Bundle of every resource the patient owns, downloaded by the patient. It creates no consent and no notification; the one write is the audit row every access carries.

    • Ruled outAny export that could identify a person
  • If something goes wrong

    We would tell you. The clock for that is not built yet.

    If your data were exposed, we would tell you what happened and what we did. There is no timer for that in the software yet. It is on the list of things that must exist before anyone enters real health information.

    The exact terms

    No breach-notification process exists in the codebase: no incident queue, no notification clock. It is listed below under what must still happen before real health information, and this page will change when it is built.

  • What we will never do

    No score about you. No identifying export. No ratings. No paid placement.

    These are decisions, not plans. Each one is in the public register with its reason, and a page that contradicts the register is a bug.

    The exact terms

    Each line is a RULED_OUT row in the capability register, checked against the codebase on every push. How the platform is paid for, and why consented research access is a purpose rather than a sale, is on its own page.

    • Ruled outA wellness score, a streak, or any number that grades you
    • Ruled outAny export that could identify a person
    • Ruled outRatings and reviews of clinicians
    • Ruled outPaid placement changing a grade or an order

Every switch on this site says what it shares and what still works if it stays off, on your data, your rules. How the platform is paid for is on how this is funded.

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: signing in, and your time zone

    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. Inside the signed-in app we also keep one cookie holding your device’s time zone (for example America/New_York), so an entry you make at nine in the evening is filed on that day rather than tomorrow. It holds nothing else and identifies nobody. A display preference may also 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.

Every claim above is the kind we can check, and most map to a verification script we run against the real product. If you ask us to delete your account — email privacy@lymehq.com from the address you signed up with — the record is erased, including symptoms and journal, labs and their uploaded files, medications, costs, connections and their credentials, and the login itself. Three things survive, by design and told to you plainly. Two are evidence: the history of your consent choices and the log of who accessed what. Both are append-only — they are the proof your permissions were honoured — and they remain attached to an internal identifier that no longer names you: no email, no name, no birth date, no location. The third is not ours: if a clinician wrote a note about their own reasoning while you were sharing with them, that note stays with them, and its link to you is cut. It is their record of how they practised, in their words, and it can describe your case; what it can no longer do is point at you. We would rather describe exactly that than promise an erasure of the evidence that protected you.

Five, or nothing.

A group small enough to count is a group small enough to identify.

The five-patient floor on released research aggregatesResearch results are released only for groups of five people or more. Groups are drawn in descending size: groups of twelve, eight and six people clear the five-patient floor and are released as aggregate counts, while groups of four, three and two fall below it and are held back. Nothing smaller, rounded or blurred is returned in their place — the cell is simply absent from the result. The floor is enforced in the database rather than in application code, and the sizes shown illustrate how the rule behaves rather than describing any real cohort.PEOPLE MATCHING A QUERY1286432The five-patient floorRELEASEDHELD BACK
  • 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 against a real database before changes are merged: 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 breach-notification process with a visible clock, and a retention limit for the retained consent history and access log, both set with counsel.
  • A full privacy notice reviewed by counsel, replacing this page.
  • An independent security assessment.
  • Strict-mode operation: session timeouts enforced, demo affordances removed.
Until then, we make no compliance claims — and please do not enter real health information. There is somewhere to put it now, which is exactly why we say this here: the demo is for exploring with made-up data. The banner on every page means what it says.

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.