A research group requests data from your system, and someone assembles the delivery by hand from three tables and a spreadsheet. That route runs out of road.
The European Health Data Space (EHDS) is Regulation (EU) 2025/327, and it entered into force on 26 March 2025. It covers two things: how health data reaches patients and clinicians, and how the same data becomes available for research, policy, and product development. The second track is called secondary use. For anyone commissioning or changing software, the EHDS translates into a list of things the system has to be able to do. Below you'll find which standards, export paths, quality requirements, logging, and shielding that involves, and how to add them to a system that already runs.
What the EHDS asks of your software, and by when
The EHDS was published in the Official Journal of the European Union on 5 March 2025 and took effect three weeks later. It then applies in stages. By 26 March 2027, the European Commission has to adopt the implementing acts carrying the technical specifications. From 26 March 2029, the rules on secondary use apply to most data categories, and patient summaries, electronic prescriptions, and dispensations have to be exchangeable between member states. From 26 March 2031, medical imaging studies with reports, laboratory and other diagnostic results, and discharge reports follow, along with genetic data, clinical trial data, and data from biobanks.
2029 sounds far away. For software it isn't. A system going into production next year will still be running in 2029, and the data model you pick now decides how much work a delivery costs then. It lands on two parties at once: the vendor building the software and the care organization holding the data.
This article stays on the build side. What the EHDS asks of a system comes down to five points: speaking the right standards, delivering data without manual work, measurable quality, traceable deliveries, and shielding per person. Our healthcare page shows how we approach software in this sector.
The data standards: HL7 FHIR and the European exchange format
For exchange, the EHDS prescribes a European format, the European electronic health record exchange format. The Commission fills in the content through implementing acts due by March 2027. The technical work runs through HL7 FHIR: HL7 Europe publishes implementation guides based on FHIR R4, including ones for the European patient summary and the laboratory report.
On top of that sits a national layer, and that is where the work usually hides. Most member states already have their own information models and FHIR profiles. In the Netherlands these are the zibs maintained by Nictiz, which describe per clinical concept which data you record and how. Whichever country you build for, your system meets a European format layered over a national one.
Coding matters just as much. Clinical concepts belong in SNOMED CT, results and measurements in LOINC. A free-text field reading "blood pressure normal" is worthless for secondary use.
For the build, that means three things:
- Keep the mapping in code. Which field in your tables maps to which information model and which FHIR profile, with tests that run in the pipeline. A mapping document in a shared folder falls behind the schema within a year.
- Validate against the profile. Fail the build as soon as a resource doesn't pass profile validation.
- Version everything. Profiles and code systems get new releases. Record per delivery which version produced it.
The mechanics behind interfaces like this are covered in our article on API integration, and our API development page describes how we work.
The export path for secondary use
Secondary use doesn't run straight from your database to a researcher. Each member state sets up a health data access body that assesses applications, issues data permits, and runs a secure processing environment. Your system sits at the other end of that chain, as a health data holder.
Article 60 of the regulation gives the holder three months from a request to put the requested data at the access body's disposal, extendable by up to three months in justified cases. You also supply a description of your datasets for the national catalogue and check every year that it still matches reality.
The data then moves into a secure processing environment. Users work inside it and take only anonymized results out.
Here's what that asks of the software:
- An export path beside the primary process. A delivery must not slow down daily use. A read replica or separate analytical layer keeps the two apart.
- Reproducible selections. The same question over the same period should return the same set later. That calls for versioned selection logic and explicit reference dates instead of "now".
- Bulk delivery in a structured format, rather than a report someone assembles by hand.
- A machine-readable description per dataset: source, scope, period, counts, and main characteristics, generated from the system itself.
The interface toward an access body is an integration problem with the same concerns as any other system integration: format, frequency, error handling, and ownership.
Data quality and coding decide whether your export is usable
The regulation attaches a data quality and utility label to datasets. Article 78 groups that label into six topics: data documentation, technical quality, data quality management processes, assessment of coverage, information on access and provision, and information on data modifications. Where a dataset carries such a label, the holder supplies enough documentation to verify it.
Exports rarely fail on technology. They fail on content:
- free text where a code belongs
- measurements without a unit or a time zone
- local code lists that exist nowhere else
- empty fields that sometimes mean "unknown" and sometimes "not applicable"
- the same person recorded twice
You fix those problems at the input side: coded fields drawing on SNOMED CT or LOINC instead of homegrown tables, validation at the moment of recording, units and timestamps stored explicitly, and quality figures you can show. Completeness per field and coverage per period are measurable, so put them on a dashboard before anyone asks.
That discipline isn't new for software in regulated sectors. In the MRO software we build for aviation, every part carries a record of what happened to it and when. The same approach makes health data usable for research.
Logging, traceability, and shielding
For primary use, the EHDS requires two software components in systems handling the priority data categories. One handles import and export in the European exchange format. The other records who viewed which data.
Secondary use adds a second layer. People may opt out of secondary use of their data at any time, without giving a reason. That is a field in your data model and a filter in your export path, covering derived tables, caches, and files prepared earlier.
The degree of shielding is fixed too. Pseudonymized data is only in play when anonymized data isn't enough for the purpose, justified in the application and stated in the permit. For the build, that means four things:
- Key management outside the dataset. The link between pseudonym and person belongs in a separate environment with its own access rights.
- A distinct pseudonym per delivery. Two deliveries then can't simply be joined.
- Provenance per record. Which source system, which profile version, which moment of recording.
- A log nothing disappears from. Who delivered what, to whom, under which permit, and with which selection.
We build this kind of traceability outside healthcare as well. In RFID applications in the supply chain, every scan is an event that still has to be findable years later, with its source, moment, and location.
Building EHDS readiness into an existing system
Few vendors start with a blank screen. The reality is a system that has run for years, on a data model designed for something else. A workable order:
- Inventory what you hold. Which data sits in the system, from which source, and under which category of the regulation it falls. Article 51 lists seventeen categories, from records and administrative data to data from medical devices, registries, and biobanks.
- Build the mapping. From your fields to the information model and FHIR profile, with a list of everything that doesn't fit. That list is your real backlog.
- Measure quality first. Completeness, coding, and duplicates, before you commit to a deadline.
- Build the export path separately. A read layer or replica with its own schema, so the primary process stays untouched.
- Put shielding in the path itself. Opt-outs, pseudonymization, and selection belong in the export layer, not in a manual check afterward.
- Log every delivery and store the selection definition alongside it.
- Test with a real delivery before a three-month clock starts running.
For a system already straining at its limits, this work often coincides with modernization. The export layer is usually the first piece you pull loose, without opening up the whole system.
We've built and modernized software for more than 30 years in sectors where traceability counts, with 30+ engineers in Nijmegen and Sarajevo, 100+ projects, and ISO 9001 and ISO 27001 certification. The people who build a system keep it running afterward. If this question is on your desk, book a call and we'll look at your data model and export path.
Frequently asked questions
What is the EHDS?
The EHDS is the European Health Data Space, set out in Regulation (EU) 2025/327. It governs how health data becomes available across Europe for care itself and for secondary use: research, policy, innovation, and product development. It entered into force on 26 March 2025 and applies in stages, with key moments in 2027, 2029, and 2031.
When does my software have to comply?
By 26 March 2027 the European Commission adopts the technical implementing acts. From 26 March 2029 the secondary use rules apply to most data categories, and the first priority categories become exchangeable. From 26 March 2031 medical imaging, test results, discharge reports, and genetic data follow. Systems built now will still be running then.
Do we have to convert everything to HL7 FHIR?
No. Your internal data model can stay as it is. What gets added is a layer that translates it into the European exchange format and the matching FHIR profiles, plus coding in SNOMED CT and LOINC. Keep that translation in code, with tests, so it doesn't drift away from the schema.
What changes for existing custom software?
Usually three things: an export path beside the primary process, measurable data quality, and a log per delivery. Shielding comes on top, so that opt-outs and pseudonymization live in the export path itself. The rest of the application often stays unchanged.
