Privacy policy
What LabFlow handles, and on whose instructions.
This policy covers the public LabFlow site and the LabFlow product. It is written in two halves because we are in two different positions depending on which one you are using, and every other question on this page depends on which half you are in.
Who we are, and which of two roles we are in#
LabFlow is built and operated by the LabFlow team and served from labflow.aoneahsan.com; the provider in law is Ahsan Mahmood, an independent developer. There is no company behind it and no support rota. That is stated first because several answers below only make sense once you know it.
On the public pages you are reading now, and on the laboratory directory, we decide what is collected and why. In data-protection language we are the controller, and you deal with us.
Inside a laboratory's tenant, we decide nothing. The laboratory that runs the tenant chooses which patients exist, which tests are ordered, which results are entered and who may see them. It is the controller; we are its processor, acting on its instructions. If you are a patient whose record is in a LabFlow tenant, your relationship is with that laboratory, and its own privacy notice governs it.
That split is not a formality. It is the reason clause 06 can reserve a right over some content and cannot reserve it over clinical records.
What is handled, in three separate groups#
Grouping matters more than listing, because the three groups are treated differently at every point below.
| Group | What it contains | Who decides |
|---|---|---|
| Visitor | What you type into the contact form: your name, your email address and your message. Nothing else on the public pages is recorded against you. | We do |
| Account | Your name, email address, role, which tenant you belong to, and a record of sign-in and permission events. | Your laboratory |
| Clinical | Patients, orders, specimens, results, reports, quality-control runs, the address of a home visit, and the audit trail behind all of them. | Your laboratory |
Clinical content is the laboratory's, held on its behalf. We do not read it, mine it, sample it or move it anywhere the laboratory has not asked for.
The five companies that see anything#
A privacy policy that says "trusted partners" has told you nothing. These are all of them, with what each one actually receives.
| Processor | What it is for | What it receives |
|---|---|---|
| Supabase | The database, sign-in, and the server functions that run beside it. | Everything in all three groups. It is where the product lives. |
| FilesHub | File storage and every outbound email the product sends. | Files you upload, and the address and body of mail we send you. |
| OneSignal | Push notifications, on mobile and on the web. | A device identifier and the text of the notification. Never a result value. |
| Firebase Hosting | Serving the static site and app files to your browser. | Ordinary web request data. It never sees anything you type or store. |
| Google Maps | Placing a home visit on the map its phlebotomist drives, and measuring the distance between two stops. | The address text of a home visit, once, when the visit is booked. Never a name, never a patient identifier, never a result, and nothing at all for a laboratory that has not configured a mapping key. |
Push is switched off entirely when its configuration key is empty, which is the state a self-hosted deployment starts in. When it is off, OneSignal receives nothing at all.
Where these run is a per-deployment fact. A laboratory is told which region its tenant is created in before it is created, and that answer is part of the tenant record rather than a sentence on this page.
What never leaves the boundary#
Patient information does not go into a web address, an analytics event, a log line, an error report or a text message. That is enforced at the point where data leaves the product, not by asking developers to remember it at each place they write code, because a convention has no failure mode anybody notices.
A record is addressed by an opaque internal identifier. The accession number and the medical record number stay in the response, never in the path, because a path reaches browser history, referrer headers and every screenshot.
An error reaches us as a class, a route pattern and whether it was handled. Request bodies, query strings and user context are stripped before anything is sent.
The mobile app can open your own messaging app with a prefilled nudge. That message may never contain a value, a test name or a diagnosis, and it can only draw from a fixed set of templates rather than from free text.
Clinical data is never sold, rented or shared with an advertising network, and no advertising, attribution or cross-site identifier is loaded on a signed-in clinical route. The Android app declares the advertising identifier permission and LabFlow expects to carry advertising in non-clinical places; what this limit says is that a patient record is never one of them, on any plan. App permissions clause 05 is the detail.
Measurement, stated so it stays true later#
Product measurement, where it is switched on, receives event names and route patterns only. It does not receive a patient identifier, an accession number, a result value, a free-text note or the contents of any record. Those are dropped at the boundary by an allowed-list, so a field nobody anticipated is dropped rather than forwarded.
If a session-replay tool, a heatmap, or an advertising or attribution service is ever added, it will appear in the table in clause 03 and in the table on the cookies page before it is switched on, and it will be blocked from every signed-in clinical route. That commitment is written this way on purpose: a flat promise never to measure anything is the kind of sentence that quietly becomes false, and a privacy policy contradicting its own cookies page is the cheapest false statement a site can make.
Advertising is named in that sentence rather than denied elsewhere on the page, because LabFlow expects to carry it. The Android app already declares the advertising identifier permission for that reason, which the app permissions page sets out in clause 05. None of it changes clause 04: an advert is a thing that can appear beside marketing pages and non-clinical screens, and never beside a patient record.
How the content is used to improve the product#
We may use non-clinical content from free accounts, meaning support messages, product feedback and bug reports, together with aggregate, de-identified usage statistics, to improve the features we build. Patient records, orders, results and any clinical content are never used this way, on any plan. Nor is anything a patient writes in a satisfaction answer — clause 09. Content in a paid plan is not used to improve features without your explicit consent.
The reason clinical content is carved out is the split in clause 01. Inside a tenant we are a processor acting on the laboratory's instructions, and a processor using its controller's data for its own purposes is not permitted under data-protection law regardless of which plan the tenant is on. The same holds under United States health-privacy law, where a business associate may only use protected health information for the purposes its agreement sets out.
One word in that clause is doing specific work. Aggregate means a count across all tenants with no tenant, laboratory or person identifiable in it: how many result entries happen per session, not which laboratory made them. So the statement made elsewhere on this site, that a tenant's data never leaves its own boundary, stays true beside this clause rather than in tension with it. Nothing that could be traced back to a tenant is used for anything.
You can object to the non-clinical use at any time by writing to us, and moving to a paid plan stops it as well. Objecting does not reduce anything about the product you can use.
How long anything is kept#
Clinical retention is not a preference. Results and reports are kept for at least two years, pathology material and slides for ten, the audit trail for six, and specimen movement records for two. A laboratory can extend any of these for its own tenant; it cannot shorten them below the floor its accreditation requires.
Clinical records are archived rather than erased, which is the honest consequence of those floors: a request to delete a patient record does not delete the laboratory's obligation to be able to produce it. Everything else, including your account and anything you sent through the contact form, is deleted on request.
The full table, with what each window is anchored to and what a deletion request actually does, is on the data deletion page.
Your rights, and which door to knock on#
You can ask for a copy of what is held about you, ask for it to be corrected, ask for it to be deleted, object to a particular use, and ask for it in a portable form. Which door you knock on depends on the group from clause 02.
If you ask us for something that belongs to a laboratory, we will tell you which laboratory holds it and pass the request on, rather than leaving you without an answer.
If you are asked how the laboratory did#
A laboratory may send you a link asking how a particular episode went. Answering is optional, and nothing about your care depends on whether you do. The link opens one page with a score from one to five and a box you may leave empty; it does not sign you in, it shows you no results, and it cannot be used to look anything up.
The laboratory can see which episode an answer belongs to, because an answer nobody can place is not useful to it. What it publishes from those answers are counts and a mean — no answer is republished with a person beside it, and no comment is quoted into a report.
The box is not a clinical channel and nobody replies to it. It reaches the laboratory's quality team, not a clinician, and nobody reading it can act on a symptom. That is said on the page itself, above the box, rather than only here — a warning that lives in a policy is one nobody reads before typing.
The link expires after ninety days and closes once it has been answered. Both limits exist for the same reason: a link that never expires keeps working after it has been forwarded, printed, or left in an old inbox, and an answer that can be quietly changed later is not worth reading.
🔴 These answers belong to the laboratory, not to us, and clause 06 does not reach them. A satisfaction comment is content a patient wrote to their laboratory; it is never used to improve this product, on any plan, with or without consent — that decision is not ours to offer.
Children#
LabFlow accounts are for laboratory staff and are not offered to children. A patient record inside a tenant may of course concern a child, and that record belongs to the laboratory under the same terms as any other. We do not knowingly create an account for anyone under sixteen, and we delete one if we find it.
What this policy does not cover#
It does not cover what a laboratory does with your data once it has it, which is that laboratory's own notice. It does not cover a system LabFlow sends a result to, such as a hospital record system, once the result has arrived there. It does not cover the sites linked from these pages. And it is not a business associate agreement, which is a separate document and is discussed on the HIPAA statement.
Changes, and how you find out#
Every revision of this document is dated at the top and published as an entry in the site feed, so a change is a thing you can subscribe to rather than a thing you have to notice. A change that materially affects what is handled or who sees it is also sent to account holders by email.
Questions about anything above go through the contact page. The LabFlow team reads it, with no rota, which is stated there as well.