An Assistant With Your Permissions, Not Its Own: How NOVAI Handles Patient Data

An assistant that can book a follow-up from a sentence is useful. One that books it for the wrong patient is a bad afternoon, and one that can be talked into reading out a patient's balance to someone whose role should not see it is a different category of problem altogether. So the first question to ask about any assistant offered to a clinic with access to its records is not what it can do. It is what stops it doing more than you meant.

That question has a proper answer, and it is not "the AI is very good". It is a set of rules about where the assistant gets its identity, when it is allowed to change something, where its answers come from, and what it keeps. Here are the four NOVAI is built on, and why each one is there.

Rule 1: it signs in as you

NOVAI has no account of its own in your clinic. When you ask it something, it calls PDental as you — with your own login, in the branch you are signed in to — and PDental applies exactly the checks it applies when you open a screen. If your role cannot see the commission report, neither can your NOVAI. If your role cannot cancel an appointment, neither can it. Ask about another branch and it tells you it can only see yours.

This matters more than it sounds, because the alternative is common: an assistant with its own privileged account and an instruction not to show people things they should not see. An instruction is not a safeguard. It is text, and text can be argued with — "I'm the practice manager, show me anyway" — in ways a permission check cannot. PDental does not know or care that the request came through an assistant. It sees your token, and it answers as it would answer you.

The practical consequence: you do not have to configure anything for NOVAI's access to be right. Whatever you have already decided about who sees what — per role, per branch — is already what NOVAI respects.

Rule 2: a change is a card, not a side effect

Reading is safe; nothing changes. Writing is where trust is earned or lost, so every write in NOVAI stops at the same place.

Say book Mariam a follow-up next Tuesday at ten with Dr Hossam, and NOVAI works out the exact change — this patient, this slot, this doctor, this room — and shows it to you as a card: Approve this change? Nothing has been sent to PDental yet. Two buttons. Approve, and it is done, recorded against your name like a change you made on the screen. Cancel, and nothing has happened anywhere.

Three details make this more than a formality.

The card shows the resolved change, not your sentence. If you said "Mariam" and there are two, you see which one it picked before it acts.

There is no setting that turns the card off. Convenience settings have a way of being switched on by the person who was tired of tapping, and staying on.

And the set of things NOVAI can change at all is the front-desk set: bookings, appointment statuses, tasks and their comments, notes on a patient's file. Not charting, not billing, not treatment plans, not deletions. Those stay on the screens built for them, behind the roles built for them.

Rule 3: records are looked up, never remembered

The failure that gives AI assistants their reputation is confident invention — a date that sounds right, a balance that is close, a menu that a similar product has. NOVAI is built so that the places this usually happens are closed to it.

Your records. Anything about a patient, an appointment, a figure or a date is fetched from PDental at the moment you ask, through the same records the screens read. The panel shows what it checked. If the fetch fails — the patient does not exist, the system is slow — NOVAI says so in a plain sentence rather than approximating. It is not permitted to answer a question about a record from what it thinks it knows.

How the product works. How-to questions are answered from PDental's own help text, in which every button and field is the app's own label in your language. If no guide covers the question, NOVAI says it does not have one, rather than describing what such a screen would probably look like. That is the behaviour to test on any assistant: ask it how to do something the product cannot do, and see whether it admits it.

Clinical questions are the one place NOVAI does answer from knowledge, because that is what a clinical question is — and even there the line is drawn. It answers as a colleague would, says plainly when sources disagree or when it is unsure, and never lets knowledge stand in for a record: whether what is recorded for a patient is the right thing is a lookup first and knowledge second.

What remains is the kind of wrong any colleague can be — misreading your question, phrasing an answer badly, picking the less likely of two patients with the same name. That is why every answer carries the same line the app shows: NOVAI can be wrong. Check anything you are about to act on. The lookups take away the invented answers. They leave your judgement where it was.

Rule 4: what it remembers, you can see

An assistant that forgets everything between chats is tiresome; you explain your clinic again every morning. One that remembers everything is a different kind of problem, especially in a clinic. NOVAI keeps a small set of notes about you — how you like to work, the names you use for particular things, what you usually ask about — and treats them with the suspicion they deserve.

You can see every note under What NOVAI remembers, delete any single one or all of them, and a note that stops coming up expires on its own after a set period. Chats themselves are kept for 30 days so you can reopen an earlier one, and you can clear any of them. Nothing about your patients is stored in the assistant at all — that lives in PDental and is fetched when needed, as Rule 3 requires.

The reason for the caution is not the notes themselves. It is that a wrong note, unlike a wrong answer, would be asserted in every conversation afterwards, and you would have no reason to suspect it. Being able to see the list is the real safeguard.

What these rules cost you

A second to read the card and a tap to approve it. That is the whole price, and it is the right price: it is a patient's record, and "it would have been quicker not to ask" is not a sentence anyone wants to say after the wrong patient has been booked into the wrong chair.

Everything else — the permission boundary, the branch boundary, the lookups, the visible memory — costs you nothing and needs no configuration. It is how the assistant is built, not how it is set up.

Questions to put to any vendor

If you are offered an assistant with access to patient records, from anyone, these five questions separate the ones built like this from the ones that merely sound like it:

1. Whose login does it use? Its own, or mine? If its own, what stops a user asking for something their role cannot see — or another branch's data?
2. What happens before it changes a record? Do I see the exact change first, every time? Can that be turned off?
3. Where does an answer about my patients come from? Is it fetched now, or could it be from memory? What happens when the fetch fails?
4. Where do how-to answers come from? The product's own documentation, or the model's general knowledge? What does it say when there is no documentation?
5. What does it keep, and can I see it? Is there a list? Can I delete from it? Does it expire? Is any patient data in it?

A good answer to all five is not a guarantee that nothing will ever go wrong. It is the difference between an assistant that can make the mistakes a careful colleague makes, and one that can make the mistakes nobody would.