Make clinical data exchange usable beyond one hospital wall
An EHDS interoperability layer maps clinical records to governed exchange datasets, preserves terminology and provenance, validates imports and exports, and records the evidence needed for a changing EU and national specification landscape. It is more than exposing an API.
EHDS is binding law. The exchange details and deadlines are phased.
The EHDS Regulation entered into force on 26 March 2025. It does not make every health application immediately compliant or non-compliant. The Commission's implementation timeline places key implementing acts in March 2027, the first priority categories in March 2029, and the second in March 2031.
| Milestone | Status | Implementation consequence |
|---|---|---|
| EHDS Regulation | In force since 26 March 2025 | Determine whether the product is in the Regulation's EHR-system scope and begin evidence, architecture and product-roadmap work. |
| Implementing acts | Several key acts due by March 2027 | Do not freeze an internal API as the final EEHRxF contract before the applicable common specifications are adopted. |
| First priority group | Commission timeline: March 2029 | Prepare patient summaries and electronic prescriptions / dispensations exchange paths and the first EHR-system group. |
| Second priority group | Commission timeline: March 2031 | Extend planning to medical images and related reports, medical test results and discharge reports. |
| FHIR implementation | Engineering choice, not a standalone legal conclusion | Use profiles, terminology, validation and versioning that can align to adopted EEHRxF specifications and national requirements. |
Scope the product before building the adapter
The Commission's EHR-system guidance distinguishes software intended for patient care or patient access to priority health-data categories from products that only process other data, such as appointment booking. That boundary changes both the product claims and the compliance work.
Likely EHR-system questions
Does the manufacturer intend this product for providers during patient care or for patients accessing records? Does it store, intermediate, import, export, convert, edit or view a priority health-data category?
Exchange category questions
Which priority categories are represented? Is the system the clinical source, a viewer, a transformation service, a patient-facing access application, or a gateway between systems?
Deployment questions
Which Member States, care settings, national services, professional identities, healthcare organisations and cross-border pathways must the product support?
Data-protection questions
Who is controller or processor, how is access authorised, what is the purpose and legal basis, and how are minimum necessary data, retention and data-subject rights handled?
Do not call a data export an interoperable record
A CSV, PDF or proprietary JSON document may be useful operationally but does not establish shared clinical meaning. An exchange implementation needs agreed data structure, code systems, units, cardinality, identifiers, authorship, timestamps, provenance, validation and a documented response to unavailable or ambiguous data.
Build a clinical translation boundary, not a database tunnel
EEHRxF is intended to include harmonised datasets, coding systems and values, plus technical interoperability specifications. A connector should preserve the clinical context that lets another system use the record safely; it should never silently invent a code, unit, author or time.
Source adapters
Read only the clinical data, identifiers, authoring context and audit information needed from each EHR, LIS, RIS, pharmacy or patient application. Record source schema and version.
Canonical clinical model
Map source records to a versioned internal representation. Separate raw source values from normalized codes and expose the mapping rules rather than hiding them in transformation code.
Terminology service
Validate and translate code systems, value sets, units and display values. Preserve original coding where needed and surface unknown, deprecated or unmapped concepts for clinical review.
FHIR / EEHRxF adapters
Generate and receive the required exchange representation through profile-specific adapters. Treat FHIR resources, profiles and implementation guides as versioned contracts, not generic blobs.
Identity and authorisation
Resolve patient, professional and organisation identifiers; enforce the applicable authorisation decision before data retrieval or delivery; minimise the response to the permitted purpose.
Provenance and logs
Carry source, author, time, transformation version and validation result with the record. Create access and delivery events without duplicating unnecessary health-data payloads into logs.
| Connector capability | Contract | Evidence |
|---|---|---|
| Export | Request a defined patient and category in a named profile and version | Source fields, transformation version, terminology results, validation output and response hash |
| Import | Receive a supported profile with explicit source and document context | Schema/profile validation, identity match outcome, duplicate policy, clinical-review queue and final status |
| Query | Search only through permitted patient, encounter, category and time boundaries | Authorisation decision, request parameters, policy version, result count and access event |
| Error handling | Return machine-readable failures without leaking a patient's existence or unrelated data | Error code, safe message, correlation ID, retry rule and support escalation path |
| Version change | Announce and accept only documented compatibility transitions | Consumer impact assessment, fixture results, release approval, rollback plan and retirement date |
Make conformance evidence a product output
The Commission describes two harmonised EHR-system components: interoperability and logging. Manufacturers will need to test components and retain technical documentation before placing covered systems on the market. The final conformance route depends on the applicable specifications; build the evidence discipline before the deadline arrives.
Own the profiles
Name the implementation guide, version, priority category, code systems and local extensions. Approve each change with product, clinical and compliance owners.
Test realistic fixtures
Cover incomplete records, missing codes, incompatible units, duplicate identities, out-of-range dates, changed display values, multiple authors and historical corrections.
Validate both directions
A valid export proves little if the system cannot safely receive, reconcile and explain an external record. Test import, export, error and downgrade paths.
Preserve traceability
Link each test and production exchange to source version, mapping version, terminology version, validator result, operator decision and release version.
Separate policy from payload
Authorisation, country deployment rules, partner routing and retention constraints should be configurable and auditable—not scattered in transformation logic.
Prove one safe clinical handoff before expanding the catalogue
A focused pilot exposes the real hard parts: clinical semantics, identity matching, authorisation, local code systems, exception handling, performance and the operational handoff when a clinician cannot trust the received data.
Choose the pathway
Select one priority-category use case, one sending system, one receiving system and a named clinical owner. Define who can access it, for what care purpose and across which boundary.
Map and validate
Create source-to-canonical-to-exchange mapping, terminology rules, field-level provenance and fixtures for normal, incomplete and conflicting records.
Integrate security
Test professional and patient identity resolution, delegated access where relevant, least-privilege data scope, secure transport, rate limits and audit records.
Run clinical review
Have clinicians evaluate whether the record remains understandable and safe after transformation. Engineering validity is necessary but not sufficient for clinical use.
Exercise failures
Simulate unavailable source data, invalid payloads, duplicate matches, unknown codes, unauthorised callers, partner timeouts and compatibility breaks.
Publish the evidence
Deliver the profile version, mapping and terminology documents, test results, deployment constraints, operational runbook and a dated gap list against applicable requirements.
EHDS EHR interoperability FAQ
Does an FHIR API make an EHR system EHDS compliant?
No. FHIR can be a useful implementation building block, but EHDS compliance depends on the applicable legal scope, EEHRxF datasets, coding systems, technical specifications, common specifications, security, logging and conformity evidence. The Commission is still adopting the detailed implementing acts needed to operationalise parts of the Regulation.
Which software is an EHR system under EHDS?
The Regulation covers systems intended by their manufacturer to be used by healthcare providers in patient care, or by patients accessing their electronic health data, where they store, intermediate, export, import, convert, edit or view priority-category personal electronic health data. A system that only processes other data, such as appointment booking, is not an EHR system under that definition.
When do EHR-system interoperability requirements apply?
The Commission's current timeline states that the first group of priority categories is due in March 2029 and the second in March 2031. The Regulation entered into force in March 2025, but its application is phased and detailed rules are being established through implementing acts. A product roadmap should track the final applicable specifications rather than treating the entry-into-force date as the full compliance date.
What is the difference between primary and secondary use under EHDS?
Primary use concerns a person's access to and sharing of electronic health data for their care. Secondary use concerns secure reuse for purposes such as research, innovation, policy-making and regulatory activity. An EHR connector can support primary-use exchange, but it does not by itself establish a lawful secondary-use access process or a HealthData@EU connection.
What should a MedTech team build before the detailed specifications are final?
Build the capabilities that make later alignment tractable: a versioned clinical data model, terminology governance, export and import boundaries, consent and authorisation handling where applicable, provenance, access logs, test fixtures, a conformance evidence trail and replaceable integration adapters. Keep national requirements and final EU common specifications configurable.
Primary sources and status
Reviewed 4 September 2026. Regulation (EU) 2025/327 is binding law but its application is phased. The Commission's timeline and EHR-system certification page explain the implementation status and should be read with the Regulation; detailed common specifications and implementing acts remain material to product conformance. Recommendation (EU) 2019/243 is non-binding foundational guidance. Yarify's architecture, mapping, test and delivery recommendations are engineering guidance, not legal or clinical advice.
- Regulation (EU) 2025/327 — European Health Data SpaceBinding EHDS Regulation, including EHR-system definitions, obligations and phased application.
- European Commission — EHDS Regulation implementation timelineCommission overview of entry into force, implementing acts and the March 2029 / March 2031 milestones.
- European Commission — certification of EHR systemsScope of an EHR system, EEHRxF components, manufacturer duties and the staged harmonised-component timeline.
- Commission Recommendation (EU) 2019/243 on a European EHR exchange formatFoundational Recommendation for the European Electronic Health Record Exchange Format.