1. Who this is about
LabSureX is laboratory management software made and sold by
KeyCode Technology Pvt Ltd (“we”, “us”).
It is used by pathology laboratories and diagnostic centres (“the
laboratory”) to register patients, run tests, record results and print
reports.
This policy covers the website at this address, the LabSureX application a
laboratory signs in to, the patient report portal, the referring-doctor and
partner-hospital portals, and the LabSureX mobile app.
2. Two kinds of data, and they are not ours in the same way
Patient records inside a laboratory's account belong to that
laboratory, not to us. The laboratory decides what is collected,
why, and for how long; we hold and process it on their instruction. In the
language of the Digital Personal Data Protection Act, 2023, the laboratory
is the Data Fiduciary and we are a
Data Processor acting for them.
So a patient asking for their record to be corrected or removed should ask
the laboratory that tested them. We will not alter or hand
over a laboratory's patient records on anybody else's request, including
the patient's — not to be unhelpful, but because we have no way to verify
who is asking and no right to act behind the laboratory's back.
Separately, we hold data of our own: the enquiry a laboratory sends us before
it becomes a customer, and the account and billing details of laboratories that
are customers. For that data, we are the Data Fiduciary and this policy is the
whole of it.
3. What is collected
3.1 When you use this website
-
What you type into the sign-up or demo form — laboratory
name, contact name, mobile number, email, city, number of branches, the
plan you are interested in, anything you write in the message box, and a
referral code if somebody gave you one.
-
The IP address the form was sent from, stored with the
enquiry. It is there to rate-limit the form so it cannot be used to send
thousands of junk enquiries; it is not used to identify or locate anybody.
This site runs no analytics and no advertising. There is no
Google Analytics, no advertising pixel, no social-media tag and no tracking
cookie. Every script, stylesheet, image and font is served from this site
itself, so browsing these pages does not tell any other company that you were
here.
3.2 When a laboratory's staff use the application
-
The account — login id, name, role, branch, and the
contact details the laboratory chooses to record. Passwords are stored as
a PBKDF2 hash and never in a form we or anybody else can read back.
-
The session — a token, the time it started and the address
it started from, so that one account being used in two places is noticed
and the first person is told.
-
A signing doctor's own details, where they choose to file
them: qualification, council registration number, and a signature image
that is printed on the reports they approve.
-
A record of changes — who altered a discount, a result, a
referrer or a test's rate, and what it was before. See §7.
3.3 What the laboratory records about its patients
Entered by the laboratory, held for the laboratory: the patient's name, age,
sex, contact number and address as the laboratory records it; the referring
doctor; which tests were ordered, what they cost, what was paid and how; the
sample, its barcode and its progress through the bench; the measured results
and the doctor's remarks; and the report as it was printed.
This is health data and it is treated as such. It is not read by us in the
ordinary course of running the service, it is never used to train anything, and
it is never sold, shared or aggregated across laboratories — see §5.
3.4 Messages
Where a laboratory has switched SMS on, we record which message was sent, to
which number, when, and whether the gateway accepted it. A test result
is never put in a text message. The two messages the product sends say
that a case has been booked or that a report is ready, and carry a link to the
patient portal — because a result in a text message is a medical record
sitting in a phone's message list and in whatever that phone backs up to.
3.5 The mobile app
The app signs in against the same accounts and holds a token on the device so
you are not asked for a password every time; what is stored on our side is a
hash of that token, not the token. The app reads data and does not
write any. It contains no advertising and no third-party analytics SDK.
A patient looking up their own report gives the report code and the mobile
number the case was booked under. Both are needed on purpose: the link gets
forwarded, and a forwarded link is worth nothing without the number.
4. Cookies and what the browser stores
We use no advertising or tracking cookies of any kind. What is set is what the
application cannot work without:
Because none of these is used for tracking or advertising, there is no consent
banner. A banner asking permission for cookies we do not set would be theatre.
One exception worth naming: a help video, where one has been added to a screen,
is loaded from YouTube's no-cookie domain and only after Play is
pressed. Nothing is fetched from Google unless somebody chooses to
watch.
5. What it is used for — and what it is never used for
Data is used to:
- run the service the laboratory is paying for;
- answer an enquiry, give a demonstration and set an account up;
- bill for a subscription and keep a record of what was paid;
-
support the laboratory when they ask — and only then, and only as far
as the question needs;
- keep the service secure, and investigate misuse.
It is never:
- sold, rented or given to a data broker;
- used for advertising, ours or anybody's;
- used to train a machine-learning model;
-
shown to another laboratory. One laboratory cannot see another's records at
all — that is enforced by the database itself, not by our screens
remembering to filter, so a mistake in our code cannot leak one customer's
patients to another;
-
pooled or aggregated across customers, even anonymously, for statistics or
a benchmark.
6. Who else sees it
Very few, and each for one job:
-
The laboratory's own SMS gateway. The message and the
number go to whichever provider the laboratory has an account with. Where
the laboratory bought its own account, we never see the credentials in a
readable form — they are stored encrypted.
-
A payment gateway, when a subscription is paid online. Card
and bank details are entered on the gateway's own page and
never reach us or this software; what comes back is
whether the payment succeeded and a reference.
-
Whoever hosts the server. Where we host for a laboratory,
that is a data-centre in India. Where the laboratory runs LabSureX on its
own server, the data never leaves their premises and this clause does not
apply to them at all.
-
A court or a lawful authority, where we are legally obliged
to. Where we are permitted to tell the laboratory that it happened, we will.
There is no other sharing. We use no advertising network, no analytics
processor and no third-party support tool that can read a laboratory's data.
7. The record of changes, and why parts of it cannot be deleted
LabSureX keeps an append-only record of changes to cases,
results, referrers and the test list — what changed, when, and which
account changed it. The database refuses to update or delete a row in it,
and that refusal applies to us as much as to anybody.
That is deliberate. A laboratory has to be able to answer “who altered
this result”, and a record the person being asked about can quietly tidy
up is not a record. The consequence is honest and worth stating plainly:
erasing a patient's data will not erase the fact that a change was made
to it, though what the entry says can be reduced to the change itself.
Where a laboratory has a legal obligation to erase, tell us and we will do what
can be done without breaking the trail that other patients' safety depends on.
8. How long it is kept
-
Patient records — for as long as the laboratory keeps
its account, because they are the laboratory's clinical records and Indian
practice expects a laboratory to be able to produce a past report. The
retention period is the laboratory's decision, not ours.
-
Enquiries — kept while we are in touch about them and
removed on request.
-
Accounts and billing records — kept while the account
is live, and afterwards only as long as tax and company law require.
-
Backups — a working set, held for a few days and then
overwritten. A record deleted from the live system may still exist in a
backup until that backup ages out.
When a laboratory leaves, we will give them their data in a usable form and then
remove it from our systems on their written instruction. We will not hold a
laboratory's data hostage over a bill.
9. How it is kept safe
-
One laboratory cannot see another's data, enforced by the
database. Every table that holds a laboratory's records is filtered
at the data layer by whose connection is asking, so a forgotten condition in
our code cannot leak anything — the filter is not something a query
has to remember.
- Passwords are hashed (PBKDF2), never stored or shown as text.
-
Repeated wrong passwords are blocked for a period, so a
login cannot be guessed at by brute force.
-
One account, one place. Signing in somewhere else warns and
ends the earlier session, so a shared password is noticed rather than
convenient.
-
Closing the window signs you out — a laboratory
counter is a shared machine.
-
Gateway keys are encrypted in the database and never
displayed again after they are saved.
-
Backups are taken on a schedule and verified, not simply
written and hoped for.
-
Traffic is served over HTTPS where we host. Where a
laboratory hosts LabSureX itself, obtaining and installing the certificate
is theirs to do and we will help.
No system is perfect, and anybody who says otherwise is selling something. If we
become aware of a breach affecting a laboratory's data we will tell that
laboratory without delay, tell them what we know and what we are doing, and make
the reports the law requires of us.
10. Your rights
Under the Digital Personal Data Protection Act, 2023 you may ask for a copy of
the personal data held about you, ask for it to be corrected or completed, ask
for it to be erased, nominate somebody to act for you, and complain about how it
has been handled.
Where to ask depends on whose data it is:
-
A patient — ask the laboratory that tested you. They
hold the record and they are the ones who can verify who you are. We will
help them answer you.
-
A laboratory, its staff, or somebody who sent us an
enquiry — write to us at the address in §12 and we will
answer within the period the Act allows.
You may also complain to the Data Protection Board of India if you are not
satisfied with our answer.
11. Children
This website and the application are not meant for children and we do not
knowingly take a child's data through them. A laboratory does, of course, test
children — that record is created by the laboratory in the course of
treating a patient, with the consent of a parent or guardian, and it is the
laboratory's to hold and to answer for.
12. Changes to this policy, and how to reach us
When this policy changes the date at the top changes with it, and a change that
materially affects a laboratory is told to that laboratory rather than left to
be noticed. Earlier versions are available on request.
