Privacy policy

LabPilot is used by laboratories to hold patient records. This explains what the software stores, who can reach it, and what each party is responsible for.

Last updated 10 August 2026

Draft — not yet in force. Every value in square brackets is a placeholder that must be completed, and this document must be reviewed by a qualified lawyer in each market you operate in before you rely on it. LabPilot's authors are not your legal advisers.

1Who this is between

LabPilot (“the Service”) is operated by [LEGAL ENTITY NAME], registered at [REGISTERED ADDRESS] (“we”, “us”).

The Service is sold to laboratories, not to patients. Where this policy says “you” it means the subscribing laboratory. Patients whose records are held in the Service should contact the laboratory that tested them — we do not have a direct relationship with them and, in most cases, cannot lawfully act on their instructions without the laboratory's involvement.

Privacy contact: [PRIVACY CONTACT EMAIL]
Postal address: [REGISTERED ADDRESS]
Data protection officer: [DPO NAME AND EMAIL, or “not appointed”]
Hosting region: [REGION — e.g. eu-west-1, ap-south-1]

2Who controls the data

This is the distinction that decides nearly every other question in this document.

You are the controller: For patient records, results, orders, invoices, and anything your staff enter. You decide what is collected, why, how long it is kept, and who in your laboratory may see it. You are responsible for having a lawful basis to hold it.
We are the processor: We store and process that data only to provide the Service, and only on your instructions. We do not decide what goes in it, we do not use it for our own purposes, and we do not sell it or use it to train machine-learning models.
We are the controller: For your own account data: staff names, email addresses, login credentials, billing details, and the operational logs we need to run and secure the Service.

3What the Service stores

Categories, as the software actually holds them. Health data is special-category personal data in every regime below and is treated as such.

Patient identity: Name, MRN, sex, date of birth, contact details, and any address or referring-doctor link your workflow records.
Clinical data: Orders, specimens, test results and their reference ranges, verification and amendment history, critical-result alerts and their acknowledgements, microbiology and quality-control records.
Financial data: Invoices, payments, discounts, expenses, and ledger entries. This is your business data, though it is linked to patients.
Staff data: Name, email, role and permissions, profile photograph and bio if supplied, and API tokens issued to that person (stored only as a hash — the token itself is unrecoverable once shown).
Audit records: Who did what and when: logins, result entry and amendment, verification, critical-result acknowledgement, discounts and voids. These exist so misuse can be detected and are deliberately not editable from the application.
Technical data: IP address, browser and device information, and error logs, retained to keep the Service secure and working.

4Why we process it, and on what basis

As processor, our basis is your instruction under the Terms of Service. For the data we control ourselves, we rely on:

Performance of a contract — providing the Service you subscribed to, and billing you for it.
Legitimate interests — securing the Service, preventing abuse, and diagnosing faults. We do not rely on this for anything involving patient records.
Legal obligation — where we are required to retain or disclose information.

We do not run advertising, we do not profile patients, and no automated decision produces a legal or similarly significant effect on any individual. Clinical flags the software raises — out-of-range values, delta checks, critical alerts — are decision support presented to a qualified person, never a decision.

5Who else touches the data

We use the following sub-processors. This list reflects what the Service actually depends on; the optional ones only receive data if you enable and configure that channel.

Supabase: Database, authentication, and file storage. Holds all patient and laboratory records. Region: [REGION].
Vercel: Application hosting, and anonymous usage analytics for the marketing site.
Twilio (optional): SMS delivery, if you enable SMS. Receives the recipient number and the message you compose.
WhatsApp Business (optional): WhatsApp delivery, if you enable it. Same data as SMS.
Your email provider (optional): Report and notification email, via Resend or an SMTP server you configure.
Browser push services: Google, Apple, or Mozilla, depending on the device. See section 6 — these carry no patient data.

We will give you notice before adding a sub-processor that handles patient data. We do not sell personal data, and we do not share it with anyone else except where you instruct it or the law compels it — and where we are compelled, we will tell you unless legally prohibited from doing so.

6Two design decisions worth stating plainly

These are the places where the software makes a privacy choice that a policy would usually gloss over.

Push notifications carry no patient data: A push message is relayed by Google, Apple, or Mozilla and may appear on a lock screen in a waiting room. So the text that leaves our servers is fixed and generic — “A result needs verification” — and never names a patient, a test, or a value. The recipient opens the application to find out what it concerns.
Report links expire and can be revoked: A patient report shared by link is reachable without a login, because the alternative is asking patients to hold an account. Each link carries a random token, expires, and can be revoked by the laboratory at any point. An expired, revoked, or unknown token is refused identically, so a link cannot be probed to learn whether a report exists.

7How long it is kept

You decide retention for patient records, because the requirement is set by the medical and accreditation rules that apply to your laboratory, not by us. We keep what you put in for as long as your subscription is live.

On termination — you may export your data. After [EXPORT WINDOW, e.g. 30 days] we delete it from live systems, and it ages out of backups within [BACKUP RETENTION, e.g. 35 days].
Audit records are retained for the life of the account and are not deletable from the application. That is deliberate: an audit trail a user can erase evidences nothing.
Billing records are kept as long as tax law requires, which is typically longer than the account itself.

8Security

Data is encrypted in transit (TLS) and at rest. Access inside the Service is enforced at the database with row-level security, so a laboratory's records are unreachable from another laboratory's session regardless of what the application asks for. Staff see only what their assigned role permits, and permissions can only narrow a role, never widen it.

Passwords are hashed by the authentication provider. API tokens are stored only as SHA-256 hashes and are shown once at creation. Every token resolves to its owner's live account, so deactivating a member of staff immediately invalidates their tokens.

No system is perfectly secure. If a breach affects your data we will notify you without undue delay and, where a regime below sets a deadline, within it.

9Rights, by regime

Because the Service is used in several markets, the specifics differ. If a patient contacts us directly we will refer them to the laboratory holding their record and assist that laboratory in responding.

GDPR / UK GDPR — where you operate in the EU or UK

Data subjects have rights of access, rectification, erasure, restriction, portability, and objection. As processor we assist you in meeting them within one month. A data processing agreement is available at [DPA URL] and forms part of the Terms.

Transfers outside the EEA/UK, where they occur, rely on Standard Contractual Clauses. You may complain to your supervisory authority — in the UK, the ICO.

HIPAA — where you are a US covered entity

Patient records in the Service are Protected Health Information and we act as a Business Associate. A Business Associate Agreement is required before you place PHI in the Service; request one at [BAA CONTACT EMAIL]. In the absence of a signed BAA you should not use the Service for PHI.

We will report a breach of unsecured PHI to you without unreasonable delay and no later than 60 days after discovery, and will make available the information you need for your own notifications.

Pakistan and other markets

Where the Personal Data Protection Act or an equivalent local health-records rule applies, we process patient data solely on the laboratory's instructions and store it in [REGION]. Data-subject requests are handled through the laboratory. Where local law requires in-country storage, tell us before onboarding — [PRIVACY CONTACT EMAIL] — because it may not be available on every plan.

Everywhere else

Independently of any statute, we commit that we will not sell your data, will not use patient records for any purpose other than running the Service for you, will not train models on them, and will return or delete them on request when your subscription ends.

10Cookies and analytics

The application itself sets only what is necessary: a session cookie so you stay signed in, and browser storage for your own display preferences such as theme and reduced motion. There is no advertising or cross-site tracking anywhere in the Service.

The public marketing site uses privacy-preserving analytics that count visits without building a profile of the visitor.

11Changes

We will update this policy as the Service changes. For any change that materially reduces your protections we will give you [NOTICE PERIOD, e.g. 30 days] notice by email before it takes effect. The date at the top always reflects the current version.

12Contact

Privacy questions, data protection agreements, and breach reports: [PRIVACY CONTACT EMAIL], or write to us at [REGISTERED ADDRESS].

For how the Service may be used and what each party owes the other, see the Terms of Service.