How this handles your data

This is the Elite Clinic booking desk, built by Noorflows. This page says where data lives, who can reach it, what is kept — including the one thing that is kept deliberately — and, the part most pages leave out, which independent security reviews we have not had.

We hold no SOC 2 report, no ISO 27001 assessment, and no third-party security assessment of any kind. Nobody outside Noorflows has assessed these claims. If your procurement process requires one, we do not meet it today, and we would rather you learned that here than three weeks into an evaluation.

Where the data lives

The demo you are looking at holds invented records only.: Every patient, enquiry and refusal in it was made up for the purpose. No real patient record has ever been copied into it, for any reason, including our own testing.
A live system for a clinic holds that clinic's data and nothing else.: Not one database with a column saying which customer a row belongs to — a separate store, separately deployed. A shared database with a filter is one mistaken query away from showing one clinic another clinic's patients, and that mistake cannot be undone by apologising.
The demo and the live system are kept separate from each other too.: A build running for a clinic holds its own store, and this demo holds another. They never touch, and nothing has ever crossed between them in either direction.

What the booking desk reads, and what it refuses to decide

It reads an enquiry — who is asking, what they are asking for, and their date of birth — and it books nothing it is not allowed to book.

Date of birth is here for one reason: in England, making an appointment for anti-wrinkle injections or injected filler for someone under eighteen is itself the criminal offence. The booking is the offence, so age has to be established before a booking exists, not at the door.

It holds no clinical notes, no medical history, no photographs and no payment details. A booking desk does not need them, and a field that does not exist cannot leak.

The two sides are not one rule. On the aesthetic side it refuses outright, because the law does. On the dental side it refuses to decide — whether a young patient is suitable for a given treatment is a clinician's judgement, and a booking desk making it would be practising. It hands the enquiry to a person either way, with what was asked and what was answered.

It gives no clinical advice of any kind, and it never tells anyone whether a treatment is right for them.

The one thing that is kept on purpose

Refusals are recorded and retained. That is not an oversight — it is the product.

The defence in law is not that the patient turned out to be eighteen. It is showing what the business did to find out, at the time. A refusal that leaves no trace protects nobody, so the register keeps what was asked, what was answered, what was decided and when. Entries cannot be edited or deleted.

That makes this build's retention the opposite of the others, and a clinic should understand it before it goes live: this register is evidence, it concerns a named person, and how long it is kept is the clinic's decision to take with its own advisers — not a default we set quietly. In the UK it is personal data, and where a health condition can be read from it, it is special category data under UK GDPR. We are not the clinic's data protection adviser and we do not pretend to be.

Who can reach it

One set of credentials per build.: No key exists that can read across two customers. That is a property of how they are deployed, not a rule someone remembers to follow.
No personal data in shared logging.: A shared log is a shared database by another name. Logs carry references — an enquiry reference, a register entry id — never names, dates of birth or contact details.
This build accepts no uploads at all.: It runs on the enquiry in front of it. Where another build does take a file, it is read in memory, used, and not written to disk — but saying so here would imply this one takes them, and it does not.

What we do not do

We do not	Because
Train any model on your data	Your records are yours. Nothing you send is used to improve anything we sell to anyone else.
Send your data to a model provider unless the build needs one	Where a build uses a language model it is named on that build's page, and it only ever rephrases facts the code has already established.
Decide anything clinical	Suitability, competence and treatment are a clinician's to judge. This desk asks, refuses where the law refuses, records it, and hands over.
Move money, send messages, or take an irreversible action on our own	Every one of those ends at a person choosing it. This is the same rule in every build.

What is written down

A build running for a clinic keeps a record of what was asked, what the desk decided and who decided what — with the version of the rules that applied at the time, so an old entry stays readable after the rules change. Entries cannot be edited or deleted. A record that can be tidied is one nobody can rely on, and the day it matters is the day somebody would most want to tidy it.

This demo keeps nothing at all. What you see on the page in front of you is all there is, and it is gone the moment you reload it — including the refusals register, which exists here only to show you what the real one would hold.

What we would need before handling real records

A signed data agreement, before any access is given — not after. Where the data concerns people in the UK or the EU, that agreement has a cross-border section a lawyer has to complete, and it is the customer who is exposed without it, which is why their lawyer is the one who stops the deal. We do not accept access to a live system before it is signed.

Back to the demo · Plain text version of the demo page · Noorflows

Written 12 August 2026. If anything on this page stops being true, it is a defect and we would like to be told.