Regulation EU 2025/327 has been in force since March 2025. The first hard obligations land in 2029. The architecture decisions that determine your cost are already on the table.
The European Health Data Space (EHDS, Regulation (EU) 2025/327, entered into force on 26 March 2025. If you’re building a digital health product in Austria and this hasn’t changed anything in your architecture discussions, you’re not behind yet. You’re making the same tradeoff that made the mySugr database migration necessary: deferring a cost that only gets harder to pay.
Table of Contents
What EHDS requires?
EHDS is a mandate for how health data moves across the EU, not a privacy law, and not a medical device regulation like MDR. It defines the formats, the access rights, the consent structure, and who can use what data for what purpose.
The regulation works on two levels. Primary use covers patient access to their own data across borders. Under EHDS, an Austrian patient can retrieve their electronic health record from any EU country via MyHealth@EU, collect a prescription in Munich, and share their clinical summary with a treating physician in Warsaw. Secondary use covers anonymized data flows for research and public health, governed by Health Data Access Bodies (HDABs) that each member state must establish.
The timeline under EHDS: member states must designate supervisory authorities by March 2027. Primary use activates in March 2029 — patient summaries must be available in International Patient Summary (IPS) format, electronic prescriptions must be cross-border compatible, and secondary use infrastructure must be operational. March 2031 brings the second wave: medical imaging, laboratory results, and hospital discharge reports.
Why March 2029 is not 3 years away?
The deadline is 2029. The architectural decisions that determine whether you meet it with clean code or a migration project need to happen before your next sprint.
FHIR is the data exchange standard under EHDS not a best practice, a regulatory requirement. Patient summaries must conform to HL7 Europe’s FHIR Implementation Guides for EHDS. Clinical terminology must map to SNOMED CT and LOINC. Any API surface that exposes patient data needs to produce the formats the European ecosystem expects.
If your data model stores clinical data in a proprietary schema, EHDS conformance is a migration, not a configuration. The question is whether that migration happens in a planned sprint or under deadline pressure on a live product.
Audit logging for MDR certification looked like a two-sprint task. One team spent three months on it. Getting to certification standard meant reworking the data model, access controls, and retention policies everything built before anyone had thought hard about audit requirements. EHDS works the same way, except it applies to the data layer from the start.
What changes specifically if you’re building in Austria
Austria already has ELGA, the national electronic health record system. EHDS connects ELGA to the MyHealth@EU infrastructure, which means Austrian data eventually needs to comply with European standards, not just national ones. Four things change technically.
FHIR profiles. Austria has its own FHIR profiles for ELGA. EHDS introduces EU-level profiles that either supersede or coexist with national ones. Building on ELGA profiles alone today creates a gap you’ll close on a timeline set by regulation, not your roadmap.
Consent architecture. A patient consenting to your app accessing their health record for their own care is making a different decision than one allowing anonymized data to feed research datasets. Under EHDS, those two consent contexts need different flags, different audit trails, and different UI affordances. Adding that distinction after the data model exists means reworking multiple layers at once.
Secondary use opt-out. Every EU patient has the right to opt out of having their data used for secondary purposes. That opt-out isn’t a feature you add in a later sprint it belongs in the data model before your first patient registers.
API surface. EHDS assumes health data moves through defined API contracts. Products built on batch exports or proprietary integrations face a harder path to conformance than products with an API layer built to be opened.
The architectural decisions that get expensive later
Three questions, asked before committing to an architecture, determine most of what EHDS compliance will cost.
What’s your FHIR strategy? Native FHIR R4 data models make conformance significantly cheaper than adapter layers on top of proprietary schemas. Adapters work until they break at the edges that matter for certification.
Where does your consent model draw the line? Consent architectures that treat all health data as one category get rebuilt when they need to separate primary and secondary use. That rebuild touches authentication, the data model, the API layer, and every UI surface where patients manage their preferences.
What terminology are you storing? EHDS implementation guides require specific bindings to SNOMED CT and LOINC. The cost of mapping to those standards scales with how far your current schema is from them today.
The products in our portfolio that handle regulatory changes without disrupting the roadmap are the ones where these questions were answered before the architecture was set.
Where to start?
Preparation for EHDS conformance typically takes over a year once you account for data model review, FHIR profile alignment, consent architecture, and terminology mapping. March 2029 is roughly thirty months away.
If you’re starting a health product in Austria now, the right time to design for EHDS is before the first sprint. If you’re already a few years in and EHDS hasn’t come up in a technical conversation, the useful next step is an honest gap analysis: what’s already aligned, and what will cost you if you leave it until 2028.
Either way, it’s a better conversation to have before a deadline forces it. Let’s talk.
