Dr Vibe

Guides

Privacy & GDPR for doctors who build

Building your own tools is a great way to fix everyday problems in care. It also makes you responsible for data you may not realise you are handling. These are the habits that keep you, your patients and your hospital out of trouble.

1. The golden rule: no patient data

Never put data about real patients into a prompt, a prototype, a test file, a screenshot, a Git repository or a log file. This includes "just one" anonymised-looking example. Most privacy incidents in hobby projects start with real data that was meant to be temporary.

  • Use synthetic data. Ask the AI to generate realistic but fake patients, lab values or schedules. Label them clearly as fake (for example "Test Patient 001").
  • Pseudonymised is not anonymous. Data with names removed but with a patient number, date of birth, rare diagnosis or admission date can often still be traced back to a person. Under the GDPR, pseudonymised data is still personal data.
  • Small numbers identify people. "The 34-year-old with a heart transplant on ward 5 last Tuesday" is identifiable, even without a name.
  • Free text is risky. Clinical notes, referral letters and discharge summaries are full of names, dates and places. Don't paste them into AI tools.

2. The rules that apply

You don't need to be a lawyer, but you should know which rules exist so you know when to ask for help.

  • GDPR (in Dutch: AVG). Health data is a special category of personal data (Article 9). Processing it is prohibited unless a specific exception applies, and you need a lawful basis, a clear purpose, data minimisation, security and a limited retention period. Large-scale processing of health data usually requires a Data Protection Impact Assessment (DPIA).
  • Medical confidentiality (WGBO, beroepsgeheim). Sharing patient information with a third party, including an AI provider, without a legal basis can breach your duty of confidentiality, whatever the tool's terms of use say.
  • NEN 7510, 7512 and 7513. The Dutch standards for information security in healthcare. They cover access control, secure data exchange and logging who accessed which record. Hospital systems must comply; a tool that touches patient data becomes part of that responsibility.
  • Your employer's policy. Most hospitals and practices have rules on AI tools, cloud services and apps. Your data protection officer (functionaris gegevensbescherming, FG) and information security officer (CISO) are your allies: involve them early, not after launch.
  • EU AI Act. AI systems that are part of a medical device count as high-risk and come with extra obligations. Another reason to keep personal prototypes away from clinical decisions.

3. Using AI tools safely

  • Know where your prompts go. Consumer chatbots and coding assistants may store prompts and use them for training. Check the settings and turn off "use my data to improve the model" where you can.
  • Prefer business or enterprise accounts with a data processing agreement (verwerkersovereenkomst), no training on your data, short or zero retention and, ideally, EU data residency. Ask your hospital which tools are approved.
  • Never paste secrets such as passwords, API keys, connection strings or tokens into a chat. If you do it by accident, revoke the key and create a new one.
  • Mind your context. AI coding tools can read your whole project folder. Don't run them in a folder that also holds exports, spreadsheets or documents with patient data.
  • Browser extensions and meeting bots can read everything on your screen or in your calls. Don't use them alongside the electronic health record.

4. Screenshot checklist

Screenshots are the most common way patient data leaks into presentations, social media and showcases like this one. Before you share any screenshot, check:

  1. Only fake demo data is shown: no names, initials, dates of birth, BSN, patient or hospital numbers, addresses, or photos.
  2. No electronic health record or other clinical system is visible in the background, in another window, or in a browser tab title.
  3. No notifications, email previews, chat messages or calendar items are visible.
  4. No colleague names, usernames, internal URLs, IP addresses or server names are shown.
  5. No API keys or tokens appear in a terminal, code editor or settings screen.
  6. Don't rely on blurring: crop or replace instead. Blurred text can sometimes be reconstructed.
  7. Check the file itself: photos taken with a phone can contain location data (EXIF). Dr Vibe strips metadata on upload, but other platforms may not.

5. Code, repositories and secrets

  • Keep secrets in environment variables or a .env file that is listed in .gitignore, never in your code.
  • Make repositories private by default, and check the full Git history before making one public: deleted files still live in old commits.
  • Never commit data exports, databases, logs or test files that came from a clinical system.
  • Front-end code is public. Anything in the browser, including API keys, can be read by anyone who opens the page.
  • Keep dependencies up to date and turn on automated security alerts (for example GitHub Dependabot).
  • Ask the AI for a security review of your code, then ask a human to review anything that matters.

6. If you ever need real data

Sometimes a tool is only useful with real data. That is the moment to stop building alone and to make it a formal project with your organisation.

  • Start with a clear purpose and a lawful basis, and collect only the data you really need (data minimisation).
  • Do a DPIA together with your data protection officer.
  • Use hosting inside the EU from a provider that signs a data processing agreement and meets NEN 7510 or ISO 27001.
  • Encrypt data in transit (HTTPS) and at rest, use strong authentication (MFA), give each user only the access they need, and log access.
  • Agree how long data is kept and how it is deleted, and who maintains the tool when you change jobs.
  • Report data breaches immediately through your organisation's incident procedure. In the Netherlands, breaches may have to be reported to the Autoriteit Persoonsgegevens within 72 hours.

7. When your tool becomes a medical device

Under the EU Medical Device Regulation (MDR), software that is intended to support diagnosis, prognosis, monitoring or treatment of individual patients can be a medical device. Under Rule 11 most such software is class IIa or higher, which requires a notified body and CE marking before it may be used in patient care.

  • Calculators, decision aids and risk scores used for real patients usually fall in this category, even when they are simple.
  • Educational tools, simulations and administrative tools (rosters, phone lists, logistics) usually do not.
  • The MDR allows some in-house development by health institutions (Article 5(5)), under strict conditions. This is a decision for your organisation, not for an individual doctor.
  • Until it is clarified, label prototypes clearly: "For education and demonstration only. Not for clinical decisions."

8. Before you share or go live

  • The tool and everything around it contain only synthetic data.
  • No secrets are in the code, the repository history or the screenshots.
  • You know which AI services your prompts and data went to, and under which terms.
  • You know whether the tool could count as a medical device, and it is labelled accordingly.
  • If it will handle personal data: your data protection officer and information security officer are involved, and a DPIA has been done where needed.
  • Someone is responsible for maintenance, updates and switching it off.

This guide is general information, not legal advice. Ask your data protection officer or a lawyer about your specific situation.