HIPAA statement
HIPAA-conscious, and the difference that word is doing.
The address of this page contains the word compliance because it was published under that address and is indexed there. The page itself does not claim it, and clause 01 explains why that is not a technicality.
Why the word is conscious and not compliant#
Compliance is a state an organisation is in, not a property software has. It is made of signed agreements, a documented risk analysis, workforce training, access reviews, an incident procedure, a named security official and periodic audits. A piece of software can support all of that and none of it makes the software compliant, because most of the obligations are not about software at all.
So a vendor who tells you their software satisfies HIPAA is either describing their own organisation, which tells you nothing about yours, or making a claim nobody can check. HIPAA-conscious means something narrower and verifiable: the design assumes protected health information is present, and the safeguards in clause 03 exist because of it.
The relationship HIPAA would put us in, and why it does not exist yet#
A laboratory in the United States handling protected health information is a covered entity. A vendor handling that information on its behalf is a business associate, and the relationship is created by a signed business associate agreement, not by using the product.
The safeguards that are actually built#
Each of these is a design decision with a consequence you could observe, not a value.
| Safeguard | What it does | Its limit |
|---|---|---|
| Tenant isolation | Every row belongs to a tenant, and every read proves the tenant from its own filters rather than trusting the caller. | Proven by a live test as a non-privileged user, not by reading the policy. A policy that reads a field the query never filters on returns a clean, wrong answer. |
| Role-based access | What a person may see and do is decided on the server, on every request. | A role a user could write themselves would be worthless, so roles are not writable by the account they describe. |
| Append-only audit trail | Who did what, when and from where, written in the same transaction as the change. | No application role holds update or delete on it. A trail the application can rewrite proves nothing. |
| Minimum necessary | A phlebotomist sees the collection list, not the whole record. | It is only as good as the roles a laboratory assigns, which is the laboratory's decision. |
| Information out of URLs | Records are addressed by opaque identifiers, so nothing identifying reaches history, referrers or screenshots. | It does not protect a screenshot of the page content itself. |
| Electronic signature | Releasing a report requires re-authentication, and the signature is bound to the exact version signed. | Signing fails when the proof is missing or stale. That is deliberate and it will occasionally be inconvenient. |
| No information in text messages | The mobile nudge draws from fixed templates and cannot carry a value, a test name or a diagnosis. | It is sent from a staff member's own phone, which is why it may only ever be a nudge. |
The six things that are not in place#
A statement listing only what exists is an advertisement. These are the gaps, and each is a real reason a laboratory might decide against LabFlow today.
Clause 02. It is the first thing that would have to change.
No SOC 2 report, no HITRUST certification, no ISO 27001. None has been started, so none is imminent.
The safeguards in clause 03 are tested only by the LabFlow team that wrote them, which is the weakest form of assurance there is.
Several administrative safeguards assume an organisation with staff to train and roles to separate. The LabFlow team is not that organisation.
What we would do is in clause 06. What we have committed to in writing is nothing, because there is no agreement to carry it.
The contingency-plan requirement expects a stated recovery objective. There is not one, and the terms say so as well.
Minimum necessary, expressed as roles#
The rule is that a person sees the least information needed to do their job. In software that is not a policy document, it is a role model, and a role model that nobody can explain in a sentence will be worked around within a week.
LabFlow's roles are shaped around the laboratory's real division of work: collection, reception and accessioning, analysis and result entry, validation and release, quality management, and administration. A laboratory can narrow them further. It cannot widen a role to see another tenant, because that boundary is not a role at all.
If something went wrong#
If we discovered unauthorised access to information inside a tenant, we would tell the affected laboratory without delay, in writing, with what we know and what we do not, and we would preserve the audit trail rather than tidy it. The laboratory then notifies the people affected and its regulator, because that duty is the covered entity's and cannot be delegated to a vendor.
There is no contractual timetable behind that paragraph. It is what would happen, not what has been promised, and clause 04 lists that gap as one of the six.
Retention, because HIPAA sets one of the windows#
The audit trail is kept for six years, which is the documentation-retention period HIPAA sets. Results and reports are kept for at least two years and pathology material for ten, which come from clinical laboratory rules rather than from HIPAA. A laboratory may extend any window; it may not take one below its own regulator's floor.
All four windows, with what each is anchored to, are on the data deletion page.
Outside the United States#
HIPAA is United States law. A laboratory elsewhere has its own regime, and in Europe the relevant structure is the controller and processor split described in clause 01 of the privacy policy, together with a written processing agreement that is subject to the same gap as the business associate agreement: it does not exist yet.
The safeguards in clause 03 are not jurisdictional. They are the same wherever the tenant is.
What your laboratory still owes, whichever vendor you choose#
This is the useful part of the page, and it stays true if you pick a different product.
- A documented risk analysis covering the whole environment, of which the software is one part.
- A signed agreement with every vendor that touches protected health information, this one included.
- Workforce training, and a record that it happened.
- An access review with a real cadence, so a role granted for one week does not survive for three years.
- An incident and breach procedure that names people rather than functions.
- A contingency plan that has been tested, not only written.
- Physical safeguards, which no software vendor can supply.
If a vendor tells you their product covers these, they have described a product that does not exist.