Interoperability Rules Are Coming for Medical Device Software, Not Just Hospitals
If you've heard about the European Health Data Space, you probably filed it under "someone else's problem." Sounds like an EHR thing. A hospital IT thing. Not something that touches your medical device software. That's not quite right, and the gap between what people think this rule covers and what it actually covers is worth closing now, not in three years.
What this rule actually is
The EHDS is an EU regulation built to let patient health data move across borders and systems. Think prescriptions, patient summaries, later on medical images and lab results too, all able to flow between a doctor in Poland and a hospital system in the Netherlands without someone manually re-entering everything.
It became law in March 2025. But here's the part that matters for device makers specifically: under Article 27, if your medical device or IVD processes any of these priority categories of health data, you don't get to sit this one out. You're required to build in two things: a piece of software that handles interoperability with other EU systems, and a piece that logs what happens to that data. Both of these then need to go through their own CE marking conformity check.
That's not an EHR vendor's job. That's your engineering team's job.
Why the timeline is trickier than it looks
Right now, this can feel distant. The detailed technical specifications aren't even finalized yet, they're expected by 2027. The first real deadline, where this actually has to work in practice, is 2029 for prescriptions and patient summaries. A second wave covering images and lab reports follows in 2031.
That sounds like plenty of time. It isn't, really. Once the technical specs land in 2027, you're looking at maybe two years to design the components, build them, document them the way a regulated device needs, and get through a new kind of conformity assessment nobody's fully practiced yet. Anyone who's shipped software into a certified device knows two years disappears fast when a chunk of it is spent figuring out what a brand-new requirement even means in practice.
Why it's easy to miss
Most regulatory attention right now is going to the EU AI Act and to MDR itself, because those get the headlines. EHDS is quieter. It reads like data policy, not device engineering. So it's easy for a device software roadmap to not have a line for it at all, right up until someone realizes their product touches exactly the kind of data this regulation is about.
What's worth doing now
A few things are worth figuring out early, not later:
- Check honestly whether your device touches the priority data categories this rule covers.
- Start scoping what an interoperability component and a logging component would actually mean for your architecture, before the specs are final, not after.
- Build with this in mind now, so it's part of the design instead of something bolted on under deadline pressure later.
This is really the same argument as always with regulated software: the requirements that arrive quietly are the ones that catch teams off guard, because nobody budgeted time for them. Staying close to where EU health data rules are heading, instead of reacting once they're finalized, is exactly the kind of unglamorous work we pay attention to at Thaumatec.
Nobody's asking you to have this solved today. But in two years, "we didn't know this applied to us" won't be much of an answer.