EHDS compliance checklist

The European Health Data Space is the EU regulation that makes electronic health data exchangeable across all Member States - for care delivery and, separately, for research and policy. The dates come from the European Commission and the regulation text itself.

The two exchange deadlines are the ones integration projects plan against - the first priority categories in 2029, the second group in 2031, both flowing through MyHealth@EU.

The engineering checklist reduces to three items. First, align data to the European EHR Exchange Format (EEHRxF) - the common format the regulation mandates, being expressed through HL7 Europe FHIR implementation guides published since 2025. Second, support cross-border exchange via MyHealth@EU - your national contact point is the gateway, your systems feed it. Third, structure the priority categories - patient summaries, e-prescriptions and e-dispensations first, images, lab results and discharge reports following.

For EHR vendors the regulation additionally introduces mandatory self-certification of EHR systems' interoperability components. The integration layer is what fills the gap between what your systems store today and what the exchange format requires - aggregation, transformation and delivery.

This page is the scoping checklist for EHDS specifically - the deadlines and the capability list. The FHIR in European healthcare projects page covers the broader landscape - country programs like Germany's e-Rezept and France's FR Core, the MyHealth@EU rollout by country and the EMA pharmaceutical timelines - each with its own code.

A patient summary is an aggregation - one subject, several resource types, one document - and an e-prescription lookup is a search. Both are Python services exposed through REST channels, with the FHIR side handled by outgoing connections.

# -*- coding: utf-8 -*-

# Zato
from zato.server.service import Service

class BuildPatientSummary(Service):
    """ Aggregates the resources a patient summary consists of.
    """
    name = 'demo.ehds.build-patient-summary'

    def handle(self) -> 'None':

        client = self.fhir['FHIR.Sample']
        patient_id = self.request.payload['patient_id']

        # The subject of the summary ..
        patient = client.get('Patient', patient_id)

        # .. their active problems ..
        conditions = client.resources('Condition').search(
            subject = f'Patient/{patient_id}',
        ).fetch_all()

        # .. and what they are taking.
        medications = client.resources('MedicationStatement').search(
            subject = f'Patient/{patient_id}',
        ).fetch_all()

        # One JSON document, returned to whoever called our REST channel
        self.response.payload = {
            'patient': patient.serialize(),
            'conditions': [item.serialize() for item in conditions],
            'medications': [item.serialize() for item in medications],
        }

Writing data flows the other way - HL7 v2 feeds from hospital systems arrive over MLLP channels and become FHIR resources, as the mapping reference shows field by field.