Where your data lives, and who can touch it.

HOST · Hetzner Online GmbH · Falkenstein / Nuremberg, Germany

Your lab’s data lives on servers in Germany, under EU jurisdiction. Not a shared cloud in an unnamed region: a specific host, in a specific country, and we tell you which.

DATA CENTRE CERTIFICATION · ISO 27001

The data centres hold ISO 27001 certification. That certification belongs to the data centre, not to HealthFlow. We make that distinction so you don’t have to.

DPDP ACT · no data-localization mandate for this data

India’s DPDP Act does not currently mandate domestic storage for this data. We host in the EU and sign a data-processing agreement with every lab. The system is designed with DPDP in mind.

TRANSPORT · HTTPS everywhere, automatic TLS

Every connection to the platform is encrypted in transit. Certificates issue and renew automatically; there is no window where traffic travels in the clear.

AT REST · data encrypted at rest

Data is encrypted at rest as well as in transit, so a stolen disk is unreadable without the keys.

ROADMAP · HealthFlow ISO 27001

Beyond the data-centre certification above, HealthFlow is working toward its own ISO 27001 certification. It is on our roadmap, which is why we say roadmap and not a badge we do not yet hold.

DATABASE · one PostgreSQL database per lab

Your lab gets its own database: not a row filter, not a shared table with a lab_id column. Another lab’s query physically cannot touch your patients.

TOKENS · per-tenant JWT signing secrets

Each lab’s login tokens are signed with that lab’s own secret. A token issued at one lab is cryptographically useless at another.

IDENTITY · bound at login, never trusted from a header

Which lab you belong to is fixed the moment you sign in. A request cannot claim to be from a different lab by editing what it sends.

AUDIT LOG · append-only, enforced by a database trigger

Audit rows can be written but never updated or deleted. The database itself refuses, regardless of what the application asks. Application credentials cannot rewrite history.

REPORT ACCESS · every view and download logged

When a report is opened or downloaded, by staff or through a patient link, that access is recorded. You can answer “who saw this report, and when”.

DEMOGRAPHICS · patient edits change-logged

Changes to a patient’s name, age, sex or contact details are logged with the before-and-after values.

RETENTION · audit 2 years · error logs 180 days · request logs 90 days

Audit history is kept for two years. Technical logs age out on a fixed schedule so operational data doesn’t linger longer than it needs to.

STORAGE · integer paise, everywhere

Every rupee amount is stored as whole paise: no floating-point money anywhere in the system, so totals never drift by a paisa.

VALIDATION · schema checks on money-mutation routes

Any request that changes an amount is validated against a strict schema before it touches a bill. Malformed or out-of-range amounts are rejected at the door.

CONCURRENCY · optimistic-concurrency guards

Two people acting on the same bill at the same moment cannot produce a double refund or a double collection; the second write is caught and refused.

COMMISSION FLOOR · ₹0 on comped orders

An order billed at zero can never accrue a payable commission. Free work stays free; it doesn’t quietly become a payout.

ROLES · role-based access with a registration allowlist

Staff see what their role permits, and new accounts can only be created against an allowlist. Nobody can sign up and grant themselves a bigger role.

BRANCHES · bill access scoped to branch

A user at one branch works with that branch’s bills. Cross-branch visibility is a granted permission, not a default.

LOCKOUT · 12 failed attempts / 15 minutes, per tenant

Repeated wrong passwords lock the account, and the counter is scoped to your lab: an attack on one tenant can’t lock out another.

RATE LIMITS · API · WhatsApp resends · PDF generation · exports

The expensive and abusable paths are throttled, so a runaway script or a hostile client can’t exhaust the system or spam your patients.

CONSENT · WhatsApp opt-in respected

Patients who haven’t opted in don’t get messages. Consent is a stored fact, not a checkbox we ignore.

STOP · inbound STOP auto-opts out

If a patient replies STOP, the system opts them out on its own: no staff action needed, no further sends.

DEDUP · send cooldown prevents duplicates

A short dedup window means an impatient double-click at the counter doesn’t send the same report twice.

LINKS · tokenized and hashed, never public URLs

Report, bill and statement links carry an unguessable token, stored hashed. There is no public URL pattern to enumerate.

DPA · signed with every lab

A data-processing agreement is part of every engagement. What we may do with your data is written down and signed, not implied.

EXPORT · full database export on request

Ask, and you get a complete export of your database. It is your lab’s data, full stop.

OFFBOARDING · we hand you the data, then drop the database

If you leave, we give you everything and delete our copy. Because each lab has its own database, deletion means dropping it: not scrubbing rows out of a shared table.

REPORTS · snapshots immutable

A finalized report is served from an immutable snapshot. What the pathologist signed is exactly what the patient, the doctor and the QR code see, forever.