Five principles behind every decision
Each measure on this page comes from one of these five rules. When a new question comes up, we answer it with them.
Every person, key and system gets only what its job needs. A booking assistant can book; it cannot read treatment notes.
We don't keep what we don't use. Records are trimmed on arrival, personal details are removed from conversations, and everything has an expiry date.
Each clinic's data lives in its own database, hosting and code accounts. Nothing is shared with any other client.
No single control is trusted alone. If one layer fails, the next one still holds.
Sign-ins, changes and views of patient data are logged and can't be edited, so any question can be answered from the record.
These principles came from building for clinics specifically. A clinic system holds the most sensitive data most people ever share, so we design as if every layer above it might one day be tested.
Where your data goes
A patient sends a WhatsApp message asking to move an appointment. This is every place that message travels, and exactly what moves at each step.
Two details matter here. First, the patient's identity is confirmed by matching their WhatsApp number exactly to the clinic record, with only a known country code allowed in front of a locally typed number. A different number that happens to share the last digits does not pass.
Second, your clinic system stays the record. The booking service reads what it needs for that one request and writes the change back. There is no second copy of your patient list sitting anywhere else.
Four layers, each locked separately
Your system has four layers: the app your team uses, the hosting it runs on, the database, and the code. Each has its own accounts, its own short list of people, and two-factor sign-in.
Why the code counts as a layer
Anyone who can change the code can change what runs in production. So the code repository is locked down exactly like the hosting and the database, with the same two people and two-factor sign-in.
Test builds never see patient data
Every change is first built as a private test version. Those test builds are connected to no database holding patient data and sit behind a login. Patient data exists only in the live system.
Connecting to Cliniko, Plato or your clinic system
This is where most of the risk sits, because your clinic system holds clinical records. We limit the connection twice: once in your clinic system, and again in our own code.
A dedicated, booking-only user
We never ask you to share an owner or administrator login. Instead, your team creates a separate user for the booking assistant with the lowest role that can still book, and generates the connection key from that user. Whatever that user can't see, we can't see either.
If you'd rather we set it up, we do it with you on a screen-share while your administrator stays signed in, or through a temporary Zelix user that you create for an agreed time and remove the same day. Either way we create only the booking user or key, and confirm in writing what we created. See API keys, explained.
Each clinic system limits access differently. Plato limits a key to chosen actions, while Cliniko limits it to what its user can do. Our connection guides show exactly what to tick in Plato, Cliniko, Zenoti, Nookal, Halaxy and Pabau.
Some projects also need treatment history or package balances, for example to space out treatments or redeem a package. Only then do we ask for an optional read-only add-on covering invoices and packages, agreed with your clinic before the key is created.
A fixed list of allowed actions in our code
On top of the user's limits, our code carries an explicit list of the functions it may call: clinics, practitioners, availability, patient name and phone, appointments, and reading recalls. A request for anything else is refused before it leaves our system, even if the key would allow it.
The only changes the system can make are creating a patient (first name, last name and mobile), and booking, rescheduling or cancelling an appointment. It cannot delete a patient or any other record, edit an existing patient record, or touch billing.
Recalls stay in your system
If you use recall reminders, your team keeps planning them in your clinic system as usual, however far ahead. We only read them: each day the system looks for recalls due in the next seven days and sends that patient one WhatsApp reminder. We never create, change or delete a recall, and we keep no copy of your recall list.
Handing over the key, with no downtime
A booking-only user, used by nothing else.
You send the key through a link that works once. Never WhatsApp or email.
We connect the new key and confirm bookings work.
Only after we confirm, so bookings never stop.
What we store, and for how long
The safest data is data we never kept. Everything we do keep has a reason and an expiry date, and deletion runs automatically every day.
| Kind of data | Do we store it? | Detail |
|---|---|---|
| Treatment notes, medical alerts, attachments | Never | Blocked in our code and by the booking-only user. |
| Invoices and payments | Never | Not requested, not readable. |
| Date of birth, address, email from the clinic record | Never | Dropped the moment a record arrives. |
| Your patient list | Never copied | Read one record at a time, only when a request needs it. |
| WhatsApp conversations | Redacted, 14 days | Names, numbers, IC numbers and emails removed before storage. |
| Booking request logs | 90 days | Phone kept only as a one-way code. |
| Leads (WhatsApp enquiries) | Until 12 months quiet | Deleted after 12 months with no messages either way. |
| Dashboard activity log | 2 years | Can't be edited or deleted early. Holds ids, never patient details. |
Personal details removed from conversations
Before a WhatsApp conversation is stored, or read by our AI reviewer, it passes through a redaction step. Names, phone numbers, IC and NRIC numbers and email addresses are replaced with placeholders.
Phone numbers stored as one-way codes
Request logs need to group one patient's requests together without holding their number. So each number is turned into a one-way code with a secret key (HMAC-SHA256). The same number always gives the same code, but the code can't be turned back into the number.
Dashboard access
Your team's dashboard shows leads, bookings and conversation checks, so it gets the strongest sign-in we can give it without passwords to steal.
Sent only to numbers your owner has added.
Fingerprint, face or screen lock on their own device.
Session lasts 7 days at most.
Each person sees only what their role needs
You hear about every sign-in
Whenever someone finishes signing in, the owner and Zelix support get a WhatsApp alert with who it was, when, the browser and the approximate location. If it wasn't expected, one tap opens the team list.
👤 Aisha Rahman (Outlet manager) has opened the team dashboard.
🕒 Thu 22 Oct, 9:15am
💻 Chrome on Mac · Kuala Lumpur, MalaysiaReview team
Deactivating someone signs them out everywhere at once. Their open sessions end immediately, so a departing staff member's access is gone the moment the owner removes it.
Lost or replaced phone? The owner resets that person's passkey from the team page, which also signs them out, and they set up a new one at their next sign-in.
An activity log that can't be edited
Every sign-in, failed attempt, change and view of patient data is recorded with who, when, the browser, the IP address and the approximate location. The log is append-only: the database itself refuses edits, and refuses deletion for two years.
| Time | Who | What | Where from |
|---|---|---|---|
| 09:02 | Owner | Signed in with passkey | Safari on iOS · Kuala Lumpur |
| 09:15 | Outlet manager | Opened a booking check | Chrome on Mac · Petaling Jaya |
| 10:41 | Unknown | Wrong WhatsApp code | Chrome on Windows · Singapore |
| 11:08 | Owner | Deactivated a team member | Safari on iOS · Kuala Lumpur |
AI safeguards
AI handles the conversation, but it never holds the keys. It can only act through the same narrow booking functions described above, and a second check reviews what it said.
- The AI can't reach clinical data. Its only route to your clinic system is the booking service, with its fixed list of allowed actions.
- Instructions hidden in messages are ignored. Patient messages are treated as data, never as commands. A message saying "ignore your rules" changes nothing.
- Every booking reply is checked. The AI reviewer compares what the assistant told the patient with what the booking system actually did, and alerts your staff when they don't match.
- The reviewer only sees redacted text. Names, numbers and IC numbers are removed first. Staff alerts carry no phone numbers or links.
- No training on your data. We use an established AI provider through its business service, under commercial terms that prohibit training its models on customer content.
Keys and secrets
Connection keys are the most valuable thing in the system, so they follow strict rules from the day they're created to the day they're revoked.
New to API keys? API keys, explained covers what they are and how scoping works, in plain terms.
Before launch, the built site is searched for anything that looks like a secret key. Only keys designed to be public, such as the address of a booking page, may appear in what a browser receives.
How we build
Security isn't a final step. It's part of how every change reaches your clinic.
- ChangeWritten with testsEvery library and route has its own automated tests, including tests that prove what must never happen, such as reading a blocked record.
- TestsThe full suite runsNothing goes live unless every test and the production build pass.
- PreviewPrivate test buildBehind a login, connected to no patient data.
- ReviewSecurity review on major releasesA full review of the codebase for security weaknesses, with every finding verified independently before it is fixed or formally accepted.
- LiveReleased with a changelog entryEvery visible change is written up on your project's changelog page in plain words, so you always know what changed and when.
The pre-launch security gate
Before a clinic's system first goes live, and before any major relaunch, it must pass our security gate. Nothing launches until every item passes or has a written reason it's accepted.
| Check | What we confirm |
|---|---|
| Data map | Exactly where data lives: database region, hosting region, every outside service that touches it. Written into the project's security file. |
| Database lock-down | Row-level security on every table; tables with secrets readable only by the server, never by a browser. |
| Sign-in failure tests | Wrong codes lock out, errors stay generic, and nothing reveals whether a phone number belongs to a team member. |
| Leak checks | No secret keys in anything a browser receives, no excess data in responses, no personal details in logs. |
| Rate limits | Limits on sign-in attempts and on anything that costs money to call. |
| Security review | Full codebase review with independent verification of every finding. |
| Sign-off | A dated, ticked security file committed with the code, which you can ask to see. |
People and policy
Technology only holds if the people around it follow the same rules. These apply to everyone at Zelix.
Ryan Chua and Stephanie Lim, both based in Singapore, are the only Zelix people with access to your system.
Every Zelix team member has signed a non-disclosure agreement.
Every account on every layer, plus the WhatsApp platform, is checked each quarter. Anyone who no longer needs access is removed.
When someone leaves either team, their access goes on every layer that day, and any key they could have seen is replaced.
Encrypted laptop disks, passkeys and two-factor sign-in on every account, and no live keys stored on laptops.
Zelix Labs carries professional indemnity and cyber insurance.
If something goes wrong
We plan for incidents before they happen, so the response is a checklist rather than a scramble.
- DetectSomething looks wrongFrom a sign-in alert, the activity log, an automated check or a report from your team.
- ContainStop it firstSwitch off outgoing messages, end sessions, deactivate accounts and revoke keys as needed. Each of these is a single action.
- ≤ 24 hWe tell youWithin 24 hours of confirming an incident that affects your data: what happened, what was affected, and what we've done.
- FixClose the causeFix the root cause, replace every key that could be affected, and add a test so it can't quietly return.
- ReportWritten reportA plain-language account for your records, and help with any notice you need to give regulators or patients.
You never need us to cut access. Deactivate the booking user in your clinic system to stop all reads and writes. Deactivate a person on the team page to end their dashboard access at once.
Compliance
You stay in control of your patients' data. We process it on your behalf, only for the purposes you set.
- Singapore PDPA 2012. We act as your data intermediary: we process personal data on your behalf, protect it, and keep it only as long as needed.
- Malaysia PDPA 2010, as amended. For clinics serving Malaysian patients, the same controls support your obligations as the data user.
- Data processing agreement. Every client is offered a signed agreement setting out what we process, why, for how long, and our security duties.
- A privacy notice per project. Your dashboard has its own privacy notice listing what it holds and each retention period.
- Where data lives. Your database is hosted in Singapore. The servers that talk to your clinic system run in the region closest to it, to keep bookings fast. They pass data through and store nothing.
We don't hold SOC 2 or ISO 27001 certification. Our hosting and database providers do, and our own controls are set out in full on this page, in your data processing agreement and in each project's security file.
Third parties we use
Patient data passes through as few outside services as the system allows. Every one of them is an established provider chosen for its security record, and each falls into one of five roles.
| Role | What it does | What it receives |
|---|---|---|
| Your clinic system | Appointments and patient records (Cliniko, Plato or similar) | Booking requests through the booking-only user |
| WhatsApp messaging platform | Patient conversations and your team inbox | Messages between your clinic and patients |
| Cloud hosting | Runs the booking service and dashboard | Requests passing through; nothing stored |
| Managed database | Your own database, Singapore region | The records listed under "What we store" |
| AI provider | The assistant's reply checks and enquiry sorting | Redacted text only; no training on it |
Once we start working together, your data processing agreement names every provider and subprocessor, where each one stores data, and what it receives. We tell you before adding or changing any of them.
Onboarding a new clinic
Setting up the security for a new clinic takes a few short steps on your side. We handle the rest.
The data processing agreement, before any data moves.
In Cliniko, Plato or your system, with the lowest booking role. See the guides.
Through the one-time link we give you.
Who needs the dashboard, and which outlets each covers.
After the security gate passes, with the sign-off on file.
Behind the scenes, your clinic gets its own database, hosting team and code organisation on day one, limited to the two named Zelix people.
Questions clinics ask
Can anyone at Zelix read our treatment notes?
No. The booking user you create can't see them, our code refuses to request them, and nothing in our system stores them.
A staff member lost their phone. What do we do?
The owner resets their passkey or deactivates them from the team page. Either one ends every session that person has open, immediately.
Where exactly is our data stored?
In your own database in Singapore. Your clinic system keeps its records wherever your clinic system provider hosts them; we don't copy them.
Will our patients' messages be used to train AI?
No. Our AI provider's business terms prohibit training on customer content, and the reviewer only ever sees redacted text.
What happens if we stop working together?
On request we export your data to you. We then delete your database, hosting and code accounts within 30 days and confirm the deletion in writing. Revoke the booking user's key in your clinic system on the same day.
Can we review your security ourselves?
Yes. We'll walk your team through this page, your project's security file and its activity log, and answer any written security questionnaire.
Questions about this standard?
Talk to the team at Zelix Labs. We're happy to go through any part of this page with your clinic, your IT support or your data protection officer.
Zelix Labs Pte Ltd · UEN 202619950K · 60 Paya Lebar Road, #06-28 Paya Lebar Square, Singapore 409051