Ringholm-Logo Ringholm Ringholm page header
Training    |   Whitepapers    Blog    Events    About us    Partners    Clients    Contact
Home > Current column | Ringholm bv | rene.spronk@ringholm.com

EHDS questions from the Rotterdam HL7 Meeting

Publication date: May 26, 2026

The top 5 concerns EHDS implementers indetified during the recent HL7 meeting in Rotterdam

EHDS questions from the Rotterdam HL7 Meeting

The HL7 WGM in Rotterdam had an EHDS track. On Tuesday I hosted a 90-minute 'unconference style' session without a pre-published agenda. The around 50 persons in the room were each provided with some sticky notes and pens. when it comes to the implementation of EHDS, what are the main challenges you see? They were asked to identify a maximum of 3 issues, and to place their sticky notes on a table, grouped by topic. Those were the topics for discussion on the agenda.

The topics covered, in order of decreasing importance (the number of sticky notes related to a particular topic):

  1. Unclarity as to what one should implement. Using the wording of session participants: Vague an incomplete specifications, understanding what is the minimum to implement.

    We didn't actually discuss this during the session - this is a given at this point in time. The preparatory Xt-EHR project has just been finalized and its work packages have been published. Some of these work packages are exploratory in nature, and won't have any impact before the 2029 or 2031 EHDS deadlines. Other work packages serve as input into the Comitology process, a joint effort by the EU (officials on behalf of DG SANTE, its 'healthcare ministry') and the member states. It is by no means ensured that the contents of the Xt-EHR packages will be used, or that their contents will escape modification. The Comitology process will result in 'implementing acts' which define the implementation details of the EHDS.

    Both Xt-EHR as well as the Comitology process are subject to lobbying by member states as well as other stakeholder groups. The political process mostly leads to a weakening of the requirements. This would seem undesirable from a technical or semantic interoperability perspective - it is however a necessity from a political perspective. Better to have something done as a result of this first release of the EHDS, we can always add requirements later when we find out something doesn't work. We'll have to wait for the implementing acts to find out what the real requirements are going to be. Xt-EHR work packages give us an idea of what could be the requirements. The FHIR and IHE Implementing Guides are a non-normative specification which aims to support the Xt-EHR (and in future: the implementing act) requirements. As such these implementation guides should be considered speculative: changes will have to be made.

  2. Terminology. Using the wording of session participants: No harmonized mandatory terminologies, terminology mappings, loss of nuanced important semantics.

    The latest Xt-EHR logical models show that coded data has (as the strictest option) Preferred bindings with a value set. On the assumption that the meaning of such a binding in logical models will be similar to that in FHIR this means that effectively (apart from FHIR structural attributes) there are no Required terminology bindings in logical models. The EEHRxF format won't contain any Required terminology bindings, allowing healthcare professionals and member states to continue the use of whatever terminologies are currently in use.

    Myhealth@EU, where it comes to the cross-border exchange of data between NCPs of member states, will be using a variation of the EEHRxF, one where there will be Required terminology bindings for some of the data items. These are the data items where member states agree that use of a certain terminology is desirable for cross-border exchanges. The mapping of any local terminologies to the one required for cross-border exchange could be done by the sending EHR system, but will most likely be left to the NCP.

  3. EU-wide versus national versus local. Using the wording of session participants: Variation across member state implementations, alignment of EU and national IGs.

    The EHDS and the implementing acts contain a mixture of requirements for member states (and their national health It infrastructure), healthcare provider organisations and IT systems. These requirements in turn lead to indirect requirements, for example: the EHDS requires that a patient be able to view all of their data that's within scope of the 6 priority categories, which is a requirement on the member state. The member state can only achieve this by passing its own legislation which requires healthcare provider organisations to share such data with the national infrastructure. In turn, healthcare providers can only achieve this by contracting their system vendors to provide suitable interfaces for such data.

    The EHDS contains quite a lot of such indirect requirements. Please keep in mind that the EU can't state any direct requirements when it comes to the organization of healthcare within member states, or the architecture of the national health data infrastructure - by EU law, that's left up to the member states to decide. The only way they can influence such things is by defining indirect requirements.

    Member states can add their own requirements, as longa s these don't conflict with those of the EHDS. As such they're free to create their own national FHIR IGs. The burden of keeping those in sync with the EU specifications lies with the member state in question.

  4. Lack of motivation of stakeholders. Using the wording of session participants: How to wake up the vendors ? There is a lack of feeling of urgency on management level, unclear need, insufficient carrot and/or stick.

    To most, the EHDS deadlines are far away. Member States are the most active stakeholders right now: they have to update their national infrastructures, set up NCP, HAD and HDAB, etc.. There are however some member states where (expected) changes in government effectively cause a standstill ' those countries simply won't be ready by 2029. Large system vendors and large healthcare provider organizations will already have create EHDS teams comprised of people with legal, architectural and technical backgrounds. They understand that time is short and that a lot of things have to accomplished before the 2029/2031 deadlines.

    Smaller vendors, as well as smaller healthcare provider organizations currently have a wait-and-see attitude. They have read various publications, perhaps seen a high level tutorial video or two, but they don't feel a sense of urgency. If I were a 1-person dental practice, the impact of the EHDS would not be on my radar, there are many other things to care of first.

    On the one hand member states and the EU will continue their work to inform the various stakeholders. The EHDS is a pretty big 'stick' (as a firm regulatory requirement), perhaps we need to put more 'carrot' (subsidies, other advantages) into the mix to convince the smaller stakeholders to get going.

  5. Versioning of specifications. Using the wording of session participants: Locking to FHIR R4 or the first version of the IGs for the unforeseeable future, evolving specs, lack of a maintenance framework.

    In a project of this size versioning will be a challenge. There will be versions of the formal specifications (the Implementing Acts, once every 2 years, probably longer) and the FHIR/IHE implementation guides (on their own publishing cycle, but unlikely to be updated more than once every 2 years or so, because of the wide impact on implementations). EHDS implementation guides will probably start based on FHIR R4, and it was observed by participants of the discussion that may well mean we'll be stuck with that release for quite a few years, even after the publication of FHIR R6. Any switch to a new set of FHIR/IHE implementation guides will have to be gradual, where for a limited time systems may have to support two different versions, and/or use translation services.

    As for maintaining the specs: the ultimate responsibility will rest with the EHDS board, which is likely to outsource this to the EEHRxF support centre. It is unlikely that they'll have the resources to maintain and develop FHIR/IHE implementation guides, some form of formal relationship between the SDOs (HL7/IHE Europe) and the EEHRxF support centre will be necessary.

The final, tongue-in-cheek topic, was the probably most famous EHDS question: 'what is an EHR?' There is a formal definition, which has been elaborated upon time and time again in the EHDS FAQ. One of the participants had news however: the commission has informally indicated that the determination of whether a system is an 'EHR' is to be based on the wider intent of the definition, and that edge use cases can always be found where the formal definition breaks. For example:
  1. One could argue that a Laboratory Information System (LIS) isn't a an EHR, given that it's not 'intended by the manufacturer to be used by healthcare providers when providing patient care'. A LIS should be considered to be an EHR however.
  2. One could also argue that a 'smart thermometer' is an EHR given the current definition, whereas that's not the intent of the definition.
As such: be aware of edge use cases, and take the intent of the definition into account.

In our EHDS-on-FHIR training course, aimed at implementers, we'll make sure to discuss these concerns.

-Rene

PermaLink to this page: https://www.ringholm.com/column/ehds-unconference-session-rotterdam-wgm.htm

Index of columns:

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
See https://www.ringholm.com for additional information.
Rene's Column (English) Rene is the Tutor-in-chief of Ringholm.
[e-mail]