AI School · Level 1 · Lesson 1

Patient data and privacy

Léelo en español →

This lesson comes first for a reason: everything else you learn here stops being useful the day you paste something into a chat that should never have left the pharmacy. And the line is not where most people think it is.

The whole thing in one sentence. Identifiable health data does not leave the pharmacy, not even "just to ask". An AI assistant is not a colleague you consult in the back room: it is a third party, outside your control, and you are handing it special category data.

Why this is different from a web search

Searching "warfarin ibuprofen interaction" discloses nothing about anyone. Typing "my 78-year-old patient with atrial fibrillation on warfarin has just bought ibuprofen" does two things at once, and you only notice one: you ask a question, yes — but you also transfer health data to a company you do not control.

UK GDPR treats health data as special category (Article 9): processing is prohibited by default unless a specific condition applies. "I needed it to answer a question" is not one of them. On top of that sits your professional duty of confidentiality, which is yours regardless of what the service's small print says. If you practise elsewhere, the names change — EU GDPR, HIPAA, PIPEDA, the Australian Privacy Act — but the shape of the rule does not.

The mistake people make most. "I removed the name, so it's anonymised." No. Data is identifiable if it can reasonably single someone out, and in a village of 900 people "84-year-old woman on lithium" points at a person more precisely than her NHS number would. De-identification depends on context, not on whether you deleted the name.

What never goes in

What you can ask, and how

Almost every real question can be phrased without a single identifier. The question loses nothing; the only thing that disappears is what was never needed.

How it comes out naturally

"I've got Jane Smith, 78, NHS 943 476 5919, from the Baker Street surgery, on warfarin since 03/02/2024, asking for ibuprofen for her knee. What do I do?"

How it should come out

"An anticoagulated patient in her late 70s on warfarin asks for an NSAID for joint pain. What are the alternatives and what should I monitor?"

The second version actually answers better: with the noise gone, the model stays on the clinical question. Stripping identifiers is not a bureaucratic toll — it usually improves the answer.

The three-filter rule

  1. Does the answer need it? If the reply would be the same without that detail, drop it.
  2. Does it single anyone out? Think of your high street, not the country. If someone local would know who you mean, drop it.
  3. Would you say it out loud in the queue? If not, don't type it either.

Check it before you paste it

Paste the text you were about to send. It is checked in your browser: nothing is uploaded, nothing is stored, and it never reaches our servers.

And now the important part about this checker. It finds NHS numbers, National Insurance numbers, phone numbers, emails, postcodes and dates — patterns that can be described. It does not find "the lady from the corner shop", and that identifies someone just as well. A clean result means "I saw none of the patterns I know how to look for", never "you may paste this". The filter that matters is still yours.

Before you choose a tool

Services are not equivalent, and the difference matters even when no patient data is involved:

One practical step. Go into your account settings and turn off the use of your conversations for training. It takes a click, and it limits the damage of a future slip. It does not authorise you to enter patient data — but it is the difference between a contained mistake and one that ends up inside a model.

A full example, and what is wrong with it

This is a real counter question, written by someone who has already been careful: no name, no ID number, no phone. It passes the checker above clean. And there are still four things wrong with it, and none of the four shows up in the reply.

What gets pasted: "Woman, 84, from the village, on long-term lithium, admitted to the local hospital last week. Now she is asking me for ibuprofen for her back. What do I tell her?"

What it replies

In an 84-year-old woman on lithium who has recently been admitted, ibuprofen is not a good option. NSAIDs reduce renal lithium clearance and can push lithium levels into the toxic range within days; the risk is higher in older people, with already compromised renal function, and higher still after a recent admission, where there may have been dehydration or medication changes.

The reasonable alternative for mild-to-moderate back pain would be paracetamol, watching the total daily dose. If the pain does not settle, her doctor should review it before any NSAID is introduced, with lithium level and renal function checks.

If you like, tell me her creatinine and how long she has been on lithium and I will refine the advice. I can keep remembering this patient for future questions.

And now, what is wrong with that reply:

  1. The reply is good, and that is why nothing goes off. Clinically it is right: NSAID + lithium is a textbook interaction and the alternative is the correct one. The failure had already happened before you pressed send, and from then on there is no signal at all: no warning, no colour, no flag. This is what makes this lesson different from every other one here — elsewhere the error is in the reply and you can catch it by reading. Here there is nothing to read.
  2. "From the village" does the job the name used to do. Woman + 84 + lithium + admitted last week + local hospital. In a village of 900 people that is not a description: it is an identification, and one anybody local resolves in two seconds. The checker does not see it because there is no pattern to look for — it is not an ID number, it is a combination. Four facts that say nothing apart and pin down one person together is the literal definition of identifiable in recital 26 of the GDPR.
  3. The reply repeats it, and so does the chat title. Look at how it opens: "In an 84-year-old woman on lithium who has recently been admitted…". The detail was there once and now it is there twice. And almost every service titles the conversation by itself with a summary of your first question, so the sidebar — and the browser tab on the counter computer, in full view of whoever is standing there — reads something like "Lithium and NSAIDs in 84-year-old admitted patient". Deleting your message deletes neither copy.
  4. And the last line is the one to read twice. "Tell me her creatinine and how long she has been on lithium" is a reasonable question that invites two more facts, and answering it is the natural thing to do. "I can keep remembering this patient" is worse: that is the account's persistent memory, and it takes the detail out of this conversation and into every future one — including the ones somebody else opens on the same account. The conversation ratchets upward on its own, and every single step looks harmless.

The clean version of that same question fits on one line: "elderly patient on long-term lithium asks for an NSAID for back pain; what alternatives and what do I watch?". The clinical answer is exactly the same — try it — and nothing is left anywhere.

And that is the test worth internalising: if removing the detail does not change the answer, the detail was not there for the answer.

And if your pharmacy is not like that

Rural pharmacy, small village. The hardest case, and almost nobody treats it as one. Here the age alone singles someone out, and the diagnosis even more: there is one patient with multiple sclerosis in the village and everybody knows who. The practical rule is to round to the decade ("an elderly patient", "around 80") and never put two uncommon traits in the same sentence. If the question does not stand up without that combination, then the question is a clinical one and it goes to the doctor, not to a chat.
Busy city-centre pharmacy. Here singling somebody out is far harder, so the risk moves: it is the shared computer. The session stays open, the next shift sees the conversation history, and anybody leaning over the counter can read the screen. A separate account per person where possible, log out when you finish, and history off where the service allows it. The slip here is not writing too much: it is leaving it up.
Pharmacy doing blister packs or care homes. The danger is not what you type: it is what you upload. A blister-pack sheet or a care-home list carries the name, date of birth, centre and full medication of twenty people at once, and one photo sends every one of them without you reading a single one. If you need help with a regimen, type the regimen. And if you genuinely need to work on the list itself, that is no longer a question: it is data processing that needs a contract, and without one it does not happen.
Owner with staff. Always forgotten, and it is exactly the same problem: your technician's sick note is health data, about somebody you also happen to be the employer of. "My assistant has been off since March with a back problem, how do I word the letter?" is treated the same as a patient question. You ask about the procedure, not about the person.

When it does not work first time

The checker comes back clean and I am still not comfortable.
Trust that feeling: it is a better detector than the one above. The checker only sees patterns — ID numbers, phones, dates — and what actually identifies somebody in a pharmacy almost never has the shape of a pattern. Apply the third filter as written: if you would not say it out loud with five people queuing, do not type it. And if in doubt, take the detail out and see whether the answer changes; it almost never does.
I have already pasted it. What now?
In order, and without panicking: delete the whole conversation (not just your message: the reply repeats the detail and so does the title), go into settings and turn off training on your conversations and persistent memory, and clear anything already stored in memory. Be clear about what that buys you: it removes your copy and stops future uses, but you cannot guarantee nothing has been processed already. If what you pasted made someone identifiable, this is a breach and it has a procedure — incident log and an assessment of whether it must be notified — not a quiet delete.
Without that detail the answer is no use to me.
Almost always that means you are giving the identifying detail instead of the clinical one, which is a different thing. "84 and from the village" is no use to the model: "reduced renal function" is. "Admitted to the local hospital last week" is no use: "recent medication change and possible dehydration" is. Translate each fact into the variable that actually moves the answer and the identifying part drops out by itself, because it was never contributing anything.
My pharmacy software has added an AI button. Can I use that one with real data?
The button does not decide it: the paperwork does. Ask the vendor for the data processing agreement, where the data is processed, how long it is kept and whether it is used for training. If you get that in writing, that route is genuinely different from an open chat and may be legitimate. If the answer is "it is all encrypted, don't worry", that answers none of the four questions. And bear in mind that being built into your software does not make it safer: it makes it more convenient, which is exactly what gets it used without thinking.

Before moving on

Sources. UK GDPR, Articles 4(1), 5 and 9 and Recital 26 (reasonable identifiability) · Data Protection Act 2018 · ICO guidance on anonymisation and on AI and data protection · GPhC standards for pharmacy professionals (confidentiality). Outside the UK, check your own regulator and data protection authority.

← Back to the AI School