Engineering for the European Health Data Space: What MedTech SaaS Must Change by 2027
The European Health Data Space regulation is not an abstract Brussels document that will affect someone else in a future release cycle. If you run a MedTech SaaS serving patients, clinicians, or health institutions in the EU, the EHDS is a concrete deadline with concrete technical obligations, and it starts phasing in 2025 with full primary-use requirements expected to land by 2027. Understanding what engineering changes it demands — and sequencing those changes so they do not blow up your feature roadmap — is now a core responsibility for any CTO in this space.
This post works through the key architectural changes EHDS requires, what each one means at the code level, and how to approach the phasing on a realistic Symfony + Next.js stack. It is not legal advice; use your compliance counsel for the regulatory interpretation. What follows is the engineering translation.
What EHDS Actually Requires at the Architecture Level
The regulation distinguishes between two categories of use. Primary use covers the direct care context: a clinician using your app to view, enter, and act on patient records. Secondary use covers research, policy, and public health analysis — pulling de-identified or pseudonymized data out of your system and into national Health Data Access Bodies (HDABs), the new EU-level infrastructure that will aggregate data across member states.
Both categories impose technical obligations, but they affect your architecture in different ways.
For primary use, the main requirement is interoperability. Your platform must be capable of exporting and, where required, importing patient data using HL7 FHIR R4 (or R5 where member states adopt it early). The regulation references the European EHR Exchange Format, which is being built on FHIR profiles. In practice this means every entity you store — patient demographics, clinical observations, prescriptions, lab results, imaging metadata — needs a machine-readable FHIR representation that can be produced on demand. That is not a cosmetic API endpoint change; for most SaaS products built on relational data models, it requires a non-trivial mapping layer.
For secondary use, the obligation is more complex. Patients must be able to grant and withdraw consent for their data to be used for specific secondary purposes — research categories are defined and coded. Your system must track that consent with enough granularity to exclude a patient''s data from a specific research category while still including it in another. Withdrawal must be processed within defined timeframes, and you must be able to demonstrate at audit that withdrawal was respected retroactively where technically feasible. This is purpose-binding metadata at the record level, not just a GDPR consent checkbox in a settings screen.
FHIR Compatibility: The Engineering Reality
If your product was not designed with FHIR in mind, adding FHIR support is a project, not a ticket. Here is what the work actually involves.
First, you need a resource mapping layer. Every clinical concept in your domain model — diagnosis, prescription, observation, encounter — needs to map to the corresponding FHIR resource type (Condition, MedicationRequest, Observation, Encounter). This is not a one-to-one mechanical translation. FHIR has specific conventions for coding systems (SNOMED CT, LOINC, ICD-10), extension patterns for concepts that the base spec does not cover, and profile constraints that member-state implementations impose on top of the base resources.
On a Symfony stack, the sensible approach is to implement this as an explicit domain service layer — a FhirResourceMapper that takes your internal domain objects and produces FHIR-conformant JSON. There are PHP libraries that provide the FHIR resource classes (the tightenco/fhir package or the dcarbone/php-fhir package), so you are not hand-rolling JSON shapes. But the mapping logic — which of your internal coding values maps to which SNOMED code, how you represent nulls and unknown values — is business logic that no library can provide.
Second, you need a FHIR-compliant API surface. The EHDS implementation guides reference SMART on FHIR for authorization, which layers OAuth 2.0 scopes onto FHIR resource types in a specific way. Your existing OAuth or session-based auth needs to be extended or wrapped to support SMART launch sequences, particularly if you need to support EHR-embedded launch contexts. This is meaningful work on both the Symfony backend and the Next.js frontend if your app uses the patient-facing or clinician-facing launch patterns.
Third, FHIR validation. Resources your system produces must be schema-valid. Running FHIR validation in CI — using the HAPI validator or a lighter JSON schema check — prevents the silent drift where a mapping produces malformed resources that only fail when submitted to an HDAB. Add this to your pipeline early, not as an afterthought before submission deadline.
Secondary-Use Consent Architecture
This is the part most MedTech SaaS teams underestimate. GDPR gave you the general framework; EHDS adds specific purpose categories and specific obligations for health data secondary use.
The architecture you need has three components.
Purpose registry: A table or structured store that defines the secondary-use categories your jurisdiction exposes. These are not arbitrary — the EHDS regulation and national implementations define the allowed categories (disease registries, clinical research, policy analysis, public health monitoring, etc.). Your system needs to know the current catalogue.
Per-patient consent records: For each patient in your system, you need a record of which secondary-use categories they have consented to, when that consent was given, and whether it has been modified or withdrawn. This needs to be a first-class entity in your domain model, not a JSON blob in a settings column. It should be append-only with timestamps — you are creating an audit trail, not a mutable preference.
Data export filtering: When your system exports data to an HDAB (either on request or via a scheduled batch), the export pipeline must join against consent records and exclude patients who have not consented to the relevant purpose category, or who have withdrawn consent. If you have a reporting or analytics pipeline, that same filtering must apply there. The consent record is not just for the export endpoint — it is a gate on any secondary-use data flow.
Withdrawal handling is where teams tend to cut corners. EHDS requires that withdrawal be processed within a defined window and that you be able to demonstrate it was respected. For batch exports, that means re-running or amending previous exports if a patient withdraws between export cycles. Whether retroactive withdrawal is technically required depends on the specific data use and member-state implementation, but designing your export pipeline to be re-runnable with a current consent snapshot is the correct default. It avoids the painful case where you have to explain to an HDAB why data was included after a patient withdrew.
Audit-Grade Access Logs
Both primary and secondary use under EHDS require patients to be able to see a log of who accessed their data, when, and for what purpose. This is not a nice-to-have — it is a patient right under the regulation, analogous to the GDPR right of access but more specific to health data access events.
The engineering requirement is an immutable access log that captures: the accessing entity (clinician, researcher, downstream system), the data category accessed (clinical note, prescription, imaging, lab result), the timestamp, the stated purpose, and the legal basis. This log must be queryable per patient and must be surfaced through a patient-facing interface.
If you are using Symfony, the canonical approach is an event subscriber or Doctrine lifecycle listener that writes access events to a separate append-only table or audit log service. The key design constraint is that this table must not be modifiable by the same application code that reads and writes clinical data — you want a logical (or physical) separation that makes tampering harder and audit trails credible. A write-once log table with a separate schema user that has only INSERT privileges, or an event-sourced log written to a separate service, are both reasonable patterns depending on your scale.
On the frontend in Next.js, the patient-facing access log view is a read-only timeline component. The harder part is the UX: making the log legible to patients who are not technical. "API request from clinical_user_47239 to /fhir/r4/Observation" is not useful. You need human-readable descriptions ("Your GP accessed your lab results on 14 May 2026") which requires enriching log events with the right metadata at write time.
Phasing the Work Without Stalling Your Roadmap
None of this has to be delivered in a single big-bang release. The approach that works is to phase it by obligation type and by risk.
Phase 1 — Foundation (now through end of 2025): Implement the consent data model and the purpose registry. This has no external dependency and low risk — you are adding tables and a consent management UI, not changing existing clinical data flows. Build the audit log infrastructure in parallel. These are foundational investments that everything else builds on.
Phase 2 — FHIR mapping layer (Q1–Q2 2026): Build the resource mapper for your most important entity types. Start with the ones most likely to be requested first: Patient demographics, Observation, Condition. Get FHIR validation running in CI. Do not expose the FHIR API externally yet — use this phase to validate the mapping quality internally.
Phase 3 — FHIR API and SMART on FHIR (Q3 2026): Add the FHIR REST API surface and the SMART launch integration. Test against a sandbox HDAB if your member state provides one. Run a limited pilot with a partner institution.
Phase 4 — Secondary-use export pipeline and patient access log UI (Q4 2026 – Q1 2027): Wire up the export pipeline with consent filtering. Build the patient-facing access log view. This is when you engage seriously with your HDAB registration process, which has its own timeline and documentation requirements.
This phasing keeps production risk low, allows you to ship clinical features throughout, and avoids the situation where you are scrambling to implement everything in the six months before the deadline.
Where External Help Accelerates This
The FHIR mapping work and the secondary-use architecture are well-understood problems a specialist moves through quickly. The mapping layer is tedious but not novel; someone who has done it before knows the edge cases — nullFlavor handling, extension URLs, profile version differences — and writes production-quality mappers faster than a team encountering FHIR for the first time.
If your team is strong but EHDS-unfamiliar, a focused engagement on architecture and code review at the start of each phase typically yields better results than a full handoff. You retain ownership of the code; external expertise ensures you are not building toward a wall.
Wolf-Tech works with MedTech SaaS teams on compliance-driven engineering like this. If you are mapping your EHDS phasing plan and want a technical review of your architecture, reach out at hello@wolf-tech.io or visit wolf-tech.io.
FAQ
When does EHDS enforcement actually start? The regulation entered into force in 2024. Primary-use obligations for EHRs are expected to apply from 2025, with secondary-use infrastructure and HDAB integration phasing in through 2027. Member-state transposition timelines vary — verify the current status for your jurisdiction.
Do we need to implement all FHIR resource types? No. The regulation specifies categories of health data: patient summary, prescriptions, lab results, medical images, hospital discharge reports, and genomics. You need FHIR representations for the data categories your product actually handles. A platform focused on lab results has a narrower mapping scope than a full EHR.
How does EHDS interact with GDPR? EHDS is lex specialis to GDPR for health data — it adds obligations on top of, and in some cases modifies, how GDPR applies to the specific context of health data sharing. Your GDPR compliance infrastructure (consent records, data processing agreements, subject access request handling) is a foundation you build on, not replace.
What is the penalty for non-compliance? Enforcement mechanisms exist, but specifics are being defined at member-state level. The reputational risk of being excluded from HDAB connectivity — unable to serve institutions that require EHDS-compliant suppliers — is likely a stronger driver than fines for most SaaS companies.