BreezeFill Privacy Policy
Last updated 9 August 2026
The short version. BreezeFill helps a doctor fill an insurer's claim form from a consultation note. To do that, the note is sent to the BreezeFill server, which strips out the patient's identifying details and sends only the de-identified remainder to an AI model to answer the form's questions.
Nothing is stored. There is no database, no account, and no file on disk — the note exists only for the seconds it takes to answer one request, and is gone when that request finishes. The patient's name, NRIC, date of birth, phone, address and policy number are never sent to the AI model at all.
Who this covers
This policy covers the BreezeFill Chrome extension, the BreezeFill website, and the BreezeFill server that both talk to. BreezeFill is currently a private pilot operated by its author, not a registered company.
The people whose data is involved are usually not the people using BreezeFill: the user is a doctor, and the data is their patient's. Both are addressed below.
What BreezeFill handles
Everything BreezeFill sees comes from one action: a doctor pasting a consultation note into the side panel. BreezeFill does not connect to any clinic system, patient record, or practice-management software, and holds no credentials to any of them.
From that pasted text, two kinds of information are separated:
- Patient details — name, NRIC/FIN, date of birth, phone number, address, policy number, insurer. These are found by pattern matching alone. No AI model is involved in finding them, and that ordering is deliberate: a model asked to pick the name out of the paste would have read the name before the list that removes it from the note existed.
- Clinical text — the rest of the note: history, diagnosis, dates, treatment.
What leaves the browser, and where it goes
| When | What is sent | To whom |
|---|---|---|
| You paste a note and BreezeFill fills in the patient details | The pasted text, as-is | BreezeFill server only. Matched against patterns in memory and discarded. No AI model, no storage, no log. |
| You press Map fields | The pasted text and the patient details you confirmed | BreezeFill server, which removes the identifiers and then sends only the de-identified text to Anthropic. The last stage of that removal is itself an AI call, over text already stripped by the two passes before it — see De-identification. |
| You press Map fields on a form BreezeFill does not have a stored description for | The wording of the questions on that page — labels only, never the values already in the boxes, never headings or surrounding prose | BreezeFill server, then Anthropic, so the questions can be answered at all. |
What is never sent to the AI model
- The patient's name, NRIC/FIN, date of birth, phone number, address or policy number. These are used to remove those same details from the clinical text, and are copied onto the form directly by the extension.
- The web address of the claim page. Insurer claim links often carry a token that acts as a password to one patient's claim, so BreezeFill records the site's hostname and never the full address.
- The contents of any field already filled in on the insurer's page.
- Anything from any other browser tab. BreezeFill cannot see them.
De-identification: the AI never learns who the patient is
This is the core protection in BreezeFill, so it is worth being exact about what it does and does not cover.
The guarantee
The patient's identity is never sent to the AI model. Their name, NRIC/FIN, date of birth, phone number, address and policy number are held back from every AI call without exception — not redacted from it, simply never included. Those details are instead used as the dictionary that removes the same information from the clinical text, and are copied onto the claim form directly by the extension.
So the model answering the form's questions is working from a note in which
the patient appears only as [PATIENT], [NRIC] and
[DOB]. It is told what happened clinically. It is never told to
whom.
How the clinical text is stripped
Three passes run before the note is used to answer the form's questions, each catching what the last could not:
- The patient's own details are replaced using the list taken from the paste — including every common way a date or an NRIC gets written, and the name in either order and part by part.
- Anything shaped like an identifier — an NRIC/FIN, a Singapore phone number, an email address — is replaced next. This is what catches identifiers belonging to other people mentioned in the note: a family member, another patient.
- A checking pass re-reads the stripped text and removes anything identifying that the first two missed.
The third pass is itself an AI call, and we would rather say so here than have you assume otherwise. It runs over text the first two passes have already stripped, it is given no patient details, and it is asked one question only — is anything identifying still in here — never to answer anything about the claim. But it is the pass that exists precisely because something may have survived the first two, so if anything did, this is where it would be seen. It goes to the same provider as the mapping call described below, under the same terms.
Questions read off the insurer's page are scrubbed twice over — once in your browser before they are sent, once again on arrival — so a label reaches the AI only if both passes missed it.
Where it stops, stated plainly
De-identification covers what is sent to the AI. Two parts of the process necessarily handle the real details, and no honest description of this product can claim otherwise:
- Reading the paste. The pasted note arrives at the BreezeFill server as you wrote it, and is separated into patient details and clinical text by pattern matching. It has to work this way round: the list of the patient's details is what the stripping uses, so it must be read before anything can be stripped. No AI is involved at this step, nothing is written down, and it exists only for the seconds that one request takes.
- Filling the form. An insurance claim identifies a patient by name and NRIC — that is what the insurer needs in order to pay it. Once you have reviewed each answer, the real details are written into the insurer's own form on your screen, ready for you to submit.
And the stripping itself is careful rather than infallible. The second pass
finds identifiers by their shape, and a name has no shape:
Tan Wei Ming looks the same to a pattern as
Tan Tock Seng. The patient's own name is removed because your
paste tells BreezeFill what it is — but a third party named in the note, and
not otherwise identified, may not be caught. Treat this as a strong reduction
in what is exposed, not a guarantee that nothing identifying can ever
pass.
Who else is involved
| Anthropic | Provides the AI model that answers the form's questions. Receives de-identified clinical text and the questions being answered. See Anthropic's privacy policy; retention of API data is governed by their terms, not by BreezeFill. |
| Vercel | Hosts the BreezeFill server and website. Sees requests in transit and keeps standard operational logs. See Vercel's privacy policy. |
There is no analytics, no advertising, no tracking pixel and no third-party script anywhere in the extension or the website. Nothing is sold or shared with anyone else.
Where processing happens
Two stages, in two different places. The distinction matters, so it is worth reading rather than skimming.
| Your patient's identifying details Name, NRIC/FIN, date of birth, phone, address, policy number |
Stay in Singapore. The BreezeFill server runs in
Singapore (Vercel's sin1 region), and these details are read,
used to strip the clinical text, and discarded there. They are never sent
to the AI model, so they never leave. |
| The de-identified clinical text The note with the patient replaced by [PATIENT],
[NRIC], [DOB] |
Leaves Singapore. It is sent to Anthropic to answer the form's questions, and Anthropic's API routes inference to the United States or globally. There is no Singapore option available to BreezeFill today. The checking pass described above is a second call to the same provider, and leaves Singapore on the same terms. |
This is the most important limitation on this page. The de-identified text is stripped of identifiers, but it is still the clinical substance of a consultation — the history, the diagnosis, the dates — and it is processed outside Singapore.
Singapore's Personal Data Protection Act does not require that processing stay in the country. It does require an organisation transferring personal data overseas to take steps to ensure the recipient is bound to a comparable standard of protection — and replacing names and numbers with tokens does not by itself put the data outside the Act, because the replacement is reversible.
No such agreement is currently in place between BreezeFill and the AI provider. What protects this transfer today is the de-identification described above, the fact that nothing is retained anywhere, and the provider's own standard terms. That is a real reduction in what is exposed. It is not the same as the contractual protection the Act contemplates, and we would rather state that here than leave you to assume otherwise when deciding whether to use BreezeFill for a given patient.
Moving inference into Singapore would remove this transfer altogether rather than protect it, which is the cleaner resolution and is the direction being taken. This section will be updated when that lands — openly, not quietly.
Retention
BreezeFill stores nothing. Every part of the server is stateless: there is no database, no session, no claim record, and no uploaded file. A note exists in server memory for the duration of the one request that carried it, and is gone when the response is sent. There is nothing to export and nothing to delete, because nothing was kept.
Error logs record the type of a failure and nothing else — never the text that caused it, because that text is the clinical note.
In the extension, the note lives in the side panel's memory while it is open. The extension does not request permission to write to disk and cannot do so; closing the panel discards the note.
What the extension can and cannot do
The extension requests three permissions: activeTab,
scripting and sidePanel.
- It can read and fill the page only on the tab where you clicked the BreezeFill icon, and only after that click. Switching tabs means clicking again.
- It cannot see your browsing history, your other tabs, or their addresses. It does not request the permission that would allow this.
- It cannot store anything on your computer.
- It never submits a form. It writes proposed answers into the fields and stops. You review them, correct them, and submit the form yourself.
Review before anything is written
Every answer BreezeFill proposes is shown with where it came from — a quote
from your note, or a marker saying it was inferred, or a blank saying the note
did not answer the question. Anything not quoted directly from your note
requires an explicit confirmation before it can be written into the insurer's
form. Dates are held for confirmation even when quoted directly, because a date
written 03/07 is 3 July in Singapore and 7 March in much of the
world, and no model can settle that from the note alone.
Real consultation notes
BreezeFill is built for ordinary clinical use. You paste the consultation note as it sits in your system — real patient details, real history, real dates — and BreezeFill maps it onto the insurer's form in front of you. There is no separate test mode and no expectation that you anonymise anything first; anonymising the note would remove the very details the form is asking for.
What that means for the patient's information is set out above: their identifying details are used to strip the same details out of the clinical text, are copied onto the claim form directly, and are never sent to the AI model. Where each part of that processing physically happens is set out below.
Responsibilities of the doctor using it
You remain the data controller for your patients' information and remain responsible for the accuracy of anything you sign and submit. BreezeFill assists with completion; it does not practise medicine, does not check your clinical judgement, and does not submit anything on your behalf. Please satisfy yourself that using it is consistent with your obligations to your patients and your regulator before using it with real data.
Changes to this policy
Material changes will be reflected in the date at the top of this page. As BreezeFill is a pilot with a small, known group of users, significant changes will also be communicated directly.
Contact
Questions about this policy, or about data handled by BreezeFill: privacy@breezefill.com.