An assistant inside the system — with hard limits on what it sees
We added a floating assistant that answers questions about how the system works and about your clinic's numbers today. The hard part was never the answering — it was guaranteeing that no clinic can reach another clinic's data.
The most frequently asked questions in any clinic are not clinical. They are operational: where do I record this payment, why can't I open reports, how many appointments are left today. Each one interrupts somebody else to answer, and most of them have exactly one correct answer.
So we put an assistant inside the system: a floating icon in the corner of the screen that opens into a conversation, and that can be dismissed for good by anyone who does not want it. But the work did not go into the chat window or the quality of the answers. It went into one question: how do we guarantee — not hope — that no clinic ever sees another clinic's data?
What it answers
The assistant answers two kinds of question and refuses everything else outright, at no cost to the clinic. The first kind is about the product itself. The second is about your own clinic's numbers, within the permissions of whoever is asking.
- How the system behaves: the invoice lifecycle, the order of lab-order statuses, why nursing cannot open the billing screen.
- Your day's numbers: appointments and their statuses, how many patients are waiting right now, what has been collected today.
- One patient's operational status by MRN: next appointment, last visit date, outstanding balance, open lab orders.
- A billing summary for a period: what was invoiced, what was actually collected, and the gap between them.
Two kinds of question, two very different costs
"How do I take a payment?" has one answer for every clinic on the platform and involves nobody's database. "What did we collect today?" cannot be answered without reading your data. Separating the two paths is what makes this affordable — and because the first kind of answer contains no clinic's data at all, it is safe to store once and serve to everyone.
| Kind of question | Reads clinic data? | Is the answer stored? |
|---|---|---|
| Entirely out of scope | No — refused locally at zero cost | Nothing to store |
| How the product works | No — answered from fixed notes, no tools attached | Yes, because it belongs to no clinic |
| Your clinic's numbers | Yes, through tools pinned to your clinic | No — live figures are never replayed |
How one clinic's data stays one clinic's data
The guarantee is not an instruction telling the model not to read another clinic's data. Instructions get broken, and models can be talked round. The guarantee is that the clinic identifier is not something the model can name at all: not one tool accepts it as a parameter. It is read from the signed-in session and written into every query on the server. Four layers hold it:
- No tool takes a clinic id. The session settles it, so there is no argument the model — or anyone typing into the chat box — could change.
- Every query carries the clinic id, and the database guard rejects any query that lost it, failing the request rather than returning unscoped rows.
- The tool list is filtered by role before the model ever sees it, so a nurse's request does not carry the billing tool and cannot call it.
- Every argument the model produces is validated and clamped on the server: a malformed date is refused, a search term is truncated, an unpermitted tool is rejected before touching the database.
Work at one site, ask about that site
A staff member assigned to a site gets a site-scoped assistant, exactly like every other screen they open. Head office, with no site assigned, sees the whole clinic.
What actually leaves your clinic
Answers are generated by an external model, which means part of the question and the tool results leave our servers. That is the same principle behind how we protect patient records and sign-in: the least data possible leaves, by the shortest path. So we were precise about what is allowed out, and the rule is that only operational facts travel:
- No clinical content leaves: no diagnosis, no notes, no vitals, no medication, no allergies.
- No contact detail leaves: no mobile number, no email, no national ID, no date of birth.
- Operational facts do: counts, times, statuses, amounts, and an MRN the staff member uses to open the real screen.
Patient names are the one genuine judgement call, and we left it to the clinic rather than making it for them. The default sends no names at all: the assistant answers with the MRN, and you open that patient's file to see the name rendered by our own servers. A clinic that has done its own data-protection assessment and wants friendlier answers can switch names on explicitly — but that is a decision about their patients and their regulator, so it is not the default.
Built for a phone at the front desk
The real usage happens on a phone, one-handed, with a patient waiting. So on mobile the conversation opens as a full-height sheet rather than a shrunken desktop popover, the composer stays above the keyboard instead of disappearing underneath it, and every control clears the size a thumb needs. The floating icon sits on the opposite side from the menu button so the two never fight for the same corner.
What it will not do
The limits are part of the design rather than gaps in it, and stating them up front beats discovering them at a bad moment:
- It gives no clinical advice: no diagnosis, no drug dose, no treatment plan. That call belongs to the treating clinician.
- It changes nothing. Every tool is read-only, so it books no appointment, issues no invoice, and edits no record.
- It does not exceed the asker's permissions. What you cannot see in the screens, you cannot see through the assistant.
- It does not invent figures. If a lookup returned nothing, it says so instead of filling the gap with an estimate.
Try the assistant in your own clinic
It ships as part of the system for every administrative and clinical role, right inside the screens your team already works in.
See what the system does