Your data · Consent is architectural

Not a policy promise — the way it is built

Every sharing switch, what it shares, what still works with it off, and how fast off takes effect.

Before you make an account, here is what each switch shares, what still works if you leave it off, who can see what, and how you leave. Every switch starts off — not as a setting we default kindly, but as the only state the database will create. Nothing here nags.

Off is not a default — it is the only thing that can be created

When an account is made, a row of sharing choices is created for it automatically, with every switch false. Two separate mechanisms guarantee it: each column refuses to be created as anything but false, and a trigger creates the row so that a missing row and a row of all-offs can never be confused with each other. Nobody has to remember to set them, because there is no code path that sets them.

All-off is a complete, legitimate answer. It is not an incomplete setup, it is not a score, and nothing on your dashboard will nag you about it. Access to LymeHQ is never conditional on sharing anything — no switch gates the tracker, the education library, finding care, or applying for help with a bill.

A rule we hold to, and its name

A switch that unlocks something is a price, not a consent. So the test we apply when a new feature meets a new switch is narrow: does this switch govern what the feature discloses, or does it merely sit near it? Only the first may gate. Beacon needs your record to answer questions about your record, so that switch gates it and Beacon says so when it is off. A positive tick test on a household pet warns the people in that household whatever the sharing switches say — that alert is the household's own safety signal, and charging for it in data would be exactly the thing this rule exists to stop.

On your consent page — every one off

In the same words the switch itself uses. This page renders that text rather than a paraphrase of it, so the sentence you read while deciding is the sentence the switch is described by everywhere else.

  • Contribute to Lyme research

    Adds your health data to the de-identified research commons that approved researchers can query.

    Exactly what is shared

    Symptoms, lab values, treatments and outcomes — stripped of your name, email, exact birth date and street address. Location is reduced to the first three ZIP digits, ages 90+ are grouped, and no result is ever released for a group smaller than five people.

    If you leave it off

    Nothing changes. Every part of LymeHQ works exactly the same.

    Contributing is a gift, never a requirement, and it is not a condition of receiving a grant. Nothing about you is sold or licensed — this is a purpose you are switching on, and what it returns is findings rather than money.

  • Let Beacon see your health record

    Lets Beacon reference your symptoms, labs and history when you ask it something.

    Exactly what is shared

    Your record is sent to the AI model only while you are in a conversation, and only the parts relevant to what you asked. Conversations are logged to your account so you can read them back.

    If you leave it off

    Beacon stays available for general Lyme and tick-borne disease questions — it just will not know anything about you.

    Beacon provides health information and education only — not medical advice, diagnosis or treatment.

  • Share with your providers

    Lets a provider you have connected with view your LymeHQ record.

    Exactly what is shared

    Only providers you have explicitly connected to, and only for as long as that connection is active — you can also give one an end date, and their access stops on its own that day. What they see includes the days you marked too unwell to record — how many, and which dates. Turning this off cuts off every provider at once. A clinician’s own notes about their reasoning stay with them, even after you end sharing; what ends is their ability to look at your record or write a new one.

    If you leave it off

    You can still open your own record to share at an appointment. Nothing is sent automatically.

  • Contribute pet sentinel data

    Sharing pet results beyond your household isn’t built yet. Nothing leaves your household.

    Exactly what is shared

    Nothing.

    If you leave it off

    You still get your own sentinel alerts.

Nothing asks you to turn any of these on when you sign up: setting up your account explains sharing and points you to the consent page, and has no switch of its own. More switches are decided where the feature is offered, beside the thing they govern — never up front, for something the account cannot use yet. They are listed below, and they are born off alongside these.

And the rest, asked where the decision is real

A form covering every switch would be asking about screens nobody has seen. The argument for sharing belongs at the point of decision, beside the thing being decided — so the remaining switches split two ways. Every one of them is born false, exactly like the four above, by the same column default and the same trigger.

Asked at the point of connection — the surface exists

  • Import your insurance claims

    Lets you connect your Medicare account so LymeHQ can pull in your claims history — what care you received, when, and what it cost.

    Nothing is connected and nothing is pulled. Turning it off later stops all syncing and disconnects your insurer account; claims already imported stay in your record.

  • Let your provider generate visit summaries

    Lets a provider you share with generate a written summary from your record before an appointment.

    Your provider still sees your live record exactly as before. Nothing is generated or sent.

In the database, born false, and gating nothing yet

  • Share within your household

    Will let the adults in your household see your symptom trends and exposure history, once household sharing is built. Nothing is visible to anyone today, whichever way this is set.

    Your household still works for pets. Sharing within your household isn’t built yet, and nothing is shared.

  • Appear in community aggregates

    Will include your data in the anonymous patterns shown to other patients, once the community surface is built. Nothing is counted or shown today.

    This only controls whether you are counted. Reading community patterns will never require contributing to them — access is not a price.

Who sees what

  • You

    Everything, always — nothing about you is hidden from the person it is about. And a copy of it in one file whenever you want one, in the format clinical systems read. No request, no waiting, no reason required.

    Working

  • A clinician on your team, with sharing on

    Both locks, or nothing: you have shared your record with them, and the sharing switch is on. They see the record under your name for as long as both stay true. You can also give a clinician a last day, after which their access stops on its own — nothing reminds them and nothing renews it. Switch sharing off, or remove them, and their very next page load has lost it.

    Working

  • A researcher

    Groups of five or more, never a record and never a name. Location is reduced to the first three ZIP digits and ages 90 and over are grouped before anything is counted, and the threshold is enforced in the query rather than in the page that draws it.

    Working

Beacon reads your record only if you turn that switch on; with it off it still answers general tick-borne disease questions, from nothing of yours. An insurer is not one of the account types that exist here — they are a patient, a clinician, a researcher, an industry researcher, labelled as one wherever it appears, an administrator.

Changing your mind — where a switch bites, and how fast

Three different answers, because the mechanisms genuinely differ. Averaging them into one reassuring sentence would make two of them false.

  • Sharing with a clinician

    Their very next page load

    Their view is rebuilt on every request and the database re-checks the rule each time, so there is no cached screen still showing your record. We test this against a real database before changes are merged — including against a deliberately stale screen, so we know the test would notice if it stopped being true.

  • Letting Beacon see your record

    Your next message

    Consent is re-read before every reply. There is no grace period and no context kept from the previous conversation. We test this against a real database before changes are merged.

  • Contributing to research

    The next rebuild of the aggregates

    This is the one place revocation is not immediate, and the reason is mechanical rather than a policy choice: researchers query a pre-computed table of group counts, and you leave it when that table is next recomputed. Nothing individual about you was ever in it.

Reading your own consent history back

Working

You can open the history of your own sharing choices — every change, when it happened, and a revocation travelling out to whoever it reached.

What a change leaves behind

Switching something off stops the sharing. It does not erase the record that you once switched it on — that history is written by the database itself, and no update or delete can touch it. That is deliberate, and it cuts both ways: a consent trail that can vanish is not evidence that consent was ever given, so the same permanence that protects you also means we cannot quietly rewrite what you agreed to.

Leaving, and taking it with you

  • Working

    Take a copy with you

    Everything you have put in, as one file in FHIR — the format clinical systems read — downloaded by you. It creates no sharing and notifies nobody; the only thing it writes is the same audit row every read of your own record writes.

  • Working

    Delete the account

    Your record goes — every row, every file, every stored credential. What stays is the evidence that the deletion happened: an append-only log entry pointing at a tombstone that names nobody. We keep that because a deletion nobody can verify is a deletion you have to take on faith.

Deleting is not a button, and that is deliberate for something irreversible: you ask us, from the address you signed up with, and a person acts on it. Exporting asks nobody for anything. What the export file contains, field by field, is on the element set.

Proven, not promised

Turning sharing off reaches your clinician on their very next page load, in the session they already have open. Every consent change is recorded by the database itself, on a table no update or delete can touch — so the history never depends on application code remembering to write it. Both are tested against a real database before changes are merged, and the first is tested against a deliberately stale screen, so a check that had stopped noticing would fail rather than pass quietly.

The mechanisms behind all of this — where the rules are enforced, the script that proves each one, and what we deliberately do not claim — are on the security page.

Where to go next