Madalin
Development enhanced by AI

Where Is Your Patient Data Actually Stored?

Every clinic in the EU has legal obligations around patient data. But most can't answer one basic question: where is that data actually stored right now?

A doctor or clinic administrator stands in front of a large 
transparent map of Europe, with glowing data points scattered 
across different countries connected by lines. The person 
looks thoughtful and slightly concerned, holding a clipboard. 
Clean clinical environment. Flat 2D editorial illustration, 
cool muted tones with soft blue and teal accents, no text 
in the image.

Here is a question worth asking at your next management meeting.

Not a complicated question. Not a technical one. Just this:

Where is our patient data actually stored right now?

Not which software you use to access it. Not which vendor manages it. Where is the data itself — physically, legally, and contractually — at this moment?

If the honest answer is “I’m not entirely sure,” you’re not alone. And you’re not in a comfortable position.


Why this question matters more than it used to

Patient data has always been sensitive. But the legal and operational stakes around where it lives and who controls it have grown significantly in recent years.

Under GDPR, healthcare organisations are classified as processors of special category data — the most sensitive tier. The obligations that come with that classification include knowing exactly where data is stored, being able to demonstrate who has access to it, and being able to respond to patient requests — access, correction, erasure — within defined timeframes.

These aren’t aspirational standards. They are legal requirements with real consequences for non-compliance.


The problem with most clinic software

Most software used by clinics today is hosted by the vendor.

That means your patient records — appointments, diagnoses, treatment history, contact details — live on servers owned and operated by a company that isn’t you. Those servers might be in Ireland, or Germany, or the United States. The terms of service govern what the vendor can do with that data, how long they retain it, and what happens to it if they are acquired, go bankrupt, or simply decide to change their pricing model.

You are responsible for that data. You did not choose where it lives. You may not be able to move it without significant disruption. And you may not be able to delete it completely if a patient asks you to.

That is the situation many clinics are operating in without fully realising it.


The questions you should be able to answer

A simple audit starts with these:

Where is the data stored? In which country, under which jurisdiction, on whose infrastructure?

Who has access to it? Beyond your own staff — does the vendor have access? Their subcontractors? Their cloud provider?

Can you export it? If you needed to move to a different system tomorrow, could you take your data with you in a usable format?

Can you delete it? If a patient invoked their right to erasure, could you delete their data completely and verifiably — including from backups?

What happens if the vendor shuts down? Is there a contractual guarantee around data return or destruction?

If any of these questions produces an uncertain answer, that uncertainty is a compliance risk worth addressing.


What data sovereignty actually looks like in practice

Data sovereignty doesn’t require building your own data centre. It requires knowing — with certainty — that your data lives where you put it, under conditions you control, with access limited to people you have authorised.

For the clinics I work with, this means software running on private infrastructure hosted in an EU data centre of their choosing. The data doesn’t move unless they decide to move it. The vendor — in this case, me — cannot access patient records without explicit authorisation. Backups are encrypted and stored under the same conditions as the primary data.

When a patient asks what data the clinic holds about them, the answer comes from one place, under one data policy, that the clinic controls entirely.

That’s not a technical luxury. For a healthcare organisation operating under GDPR, it’s the standard you should be holding yourself to.


A practical starting point

You don’t need to overhaul everything at once. Start with the audit.

Map your current tools. For each one, find out where the data is stored, what the vendor’s data processing agreement says, and whether you could export and delete your data if you needed to.

That exercise alone will tell you where your risks are — and which ones are worth addressing first.


If you go through that process and find gaps you’re not sure how to close, I’m happy to talk through what a vendor-free approach might look like for your clinic.

Connect on LinkedIn or reach out directly at hi@madalin.me.

Madalin

Madalin

AI integrator

🚀 Senior Architect | SRE & Database Expert | AI Orchestrator 👋 Building the future at the speed of thought. ⚡️ I don't just write code; I architect high-performance, bulletproof ecosystems. With a foundation in Systems Engineering and a mastery of Go and TypeScript, I bridge the gap between heavy-duty backend reliability and seamless, high-conversion frontends.

Continue the conversation

If this article reflects the challenges your organisation is navigating, explore more practical guidance across Madalin.