Privacy Policy

Clinexas is software used by diagnostic laboratories and imaging centres. That means we handle two kinds of information under two different legal roles, and your rights differ depending on which one applies to you.

• Patient and clinical data — we are a processor. When a laboratory registers a patient, records a sample or approves a result, the laboratory decides what is collected and why. It is the controller. We only store and process that data on its instructions, to provide the service.
• Laboratory account data — we are a controller. The details of the laboratory itself, its staff logins, its billing with us and its support correspondence are ours to manage, and this policy governs them directly.

If you are a patient asking what a laboratory holds about you, your request goes to that laboratory, not to us. We cannot lawfully hand over or amend a laboratory’s clinical records on a patient’s request, and we will refer you back to them.

Laboratory account data (we are controller)

• Laboratory name, subdomain, contact details and registered address.
• Staff accounts: name, email address, assigned role and branch. Passwords are stored only as a salted hash — never in a form we can read.
• Billing records: charges accrued, invoices we raise, and payments recorded.
• Your acceptance of our Terms when you register a laboratory: the date and time, the version of the Terms you were shown, and the IP address and browser you accepted from. We keep this as evidence that the agreement was formed, and we cannot do that with the timestamp alone.
• Support correspondence you send us.

Patient and clinical data (we are processor)

• Patient demographics, contact details and next of kin, as entered by the laboratory.
• Requests, samples, results, reference ranges, flags, imaging reports and the PDF documents generated from them.
• Invoices, payments and receipts raised against a patient’s request.

This is health data, and it is treated as sensitive personal data in every jurisdiction we operate in.

Technical data

• An audit log of privileged actions inside a laboratory’s workspace — which user did what, and when — including the IP address and browser recorded at sign-in. This exists so a laboratory can hold its own staff accountable.
• Standard server logs needed to run and secure the service.

Our public website sets no cookies and runs no analytics or advertising trackers. See the Cookie Policy.

Every laboratory is provisioned its own separate database when it is onboarded, reached through its own subdomain. Laboratories are not rows sharing a table with a tenant identifier, so there is no query — mistaken or malicious — that could return one laboratory’s patients to another.

Data is hosted in [Hosting region]. Where providing the service requires a transfer outside your country, we rely on the safeguards required by the Nigeria Data Protection Act 2023, and by the UK GDPR and EU GDPR where those apply.

• To provide the service under our contract with the laboratory — this covers all processing of patient data carried out on its instructions.
• To bill for usage, and to keep the accounting records the law requires us to keep.
• To secure the service — detecting abuse, rate-limiting, and investigating incidents. Our legitimate interest, and the laboratory’s.
• To show that a contract was agreed — the acceptance record described above, including the IP address it came from. Necessary for the contract itself, and our legitimate interest in being able to evidence it later. Collected once, at registration; we do not log your IP as you browse the site.
• To support you when you contact us.

We do not sell data. We do not use patient data to train machine-learning models. We do not use it for advertising, and we do not share it between laboratories.

We use a small number of sub-processors to run the service. Each is bound by contract to protect the data and to use it only for the service we buy from them.

• Cloud hosting and managed databases — to run the application and store each laboratory’s database.
• Email delivery — to send the reports a laboratory chooses to email to a patient, and transactional mail such as password resets.

A current list of sub-processors is available on request from [email protected]. We will give laboratories notice before adding a new one that processes patient data.

Our own staff do not browse laboratory data. Access for support is requested, recorded, and granted by the laboratory.

Approved reports carry a QR code and a verification link that anyone holding the report can open without an account. This is deliberate — it lets a hospital or employer confirm a report is genuine.

The page is built to confirm provenance, not content. It shows the laboratory, lab number, test name and result date. It shows no parameter values, no diagnosis and no contact details. An unknown code and a not-yet-approved code return the identical response, so the page cannot be used to probe whether a particular record exists.

Patient and clinical data is kept for as long as the laboratory’s account is active, because retention periods for medical records are set by the laboratory’s own regulator, not by us.

When a laboratory closes its account, we make its data available for export for a reasonable handover period and then delete the database. Backups age out on their own cycle. We keep the billing and accounting records we are legally required to keep, and nothing more.

The record of your acceptance of our Terms outlives the account, because it is evidence of an agreement rather than operational data — a deleted acceptance proves nothing about a period during which the service was used. It is kept for as long as a claim under that agreement could still be brought.

• Separate database per laboratory, reached only through its own subdomain.
• Passwords stored as salted hashes; session tokens held in memory with the long-lived refresh token in a cookie the browser will not expose to scripts.
• A session token is bound to the laboratory it was issued for and rejected if presented against another.
• Role-based access control, plus rules a role check cannot express — a result cannot normally be approved by the person who entered it.
• Encryption in transit, and rate limiting on authentication endpoints.

More detail is on our Security page. To report a vulnerability, write to [email protected].

Under the Nigeria Data Protection Act 2023 — and under the GDPR where it applies to you — you may ask to access the personal data we hold about you, to correct it, to have it deleted, to restrict or object to how we use it, and to receive it in a portable form. You may also complain to your data protection authority; in Nigeria that is the Nigeria Data Protection Commission.

For laboratory account data, send the request to [email protected] and we will respond within the statutory period.

For patient data, the laboratory is the controller. Send your request to them. If they ask us to help them fulfil it, we will.

If we change this policy in a way that materially affects how we handle personal data, we will tell account holders before it takes effect rather than quietly updating the date at the top.

AYSON Technologies, Lagos, Nigeria. Data protection enquiries: [email protected].