What is an EHR Slice and why is it relevant to the EHDS?

I coined the term ‘EHR Slice’ in April 2025 while working with the amazing Rachel Dunscombe on our joint pitch for IPS. It lay dormant for a year, but now it is back to life in the context of the EHDS.

First, a brief background: Last year, Rachel very kindly invited me to co-pitch with her on IPS for the first ‘Converge or Collide’ meeting between FHIR and openEHR in Amsterdam, which took place in 2025.

‘EHR Slice’ was the final item on the last slide of a pitch that we had to finish in five minutes. The bullet point on the slide read:

“We propose the idea of an EHR Slice. It consists of API definitions based on FHIR (profile, impl guide etc.) + openEHR models + technology-agnostic openEHR-FHIR mappings + metadata. An EHR Slice can, for example, provide a standalone implementation of an IPS Server. Think of it as a Clinical Microservice.”

At that point, Rachel was already exploring the idea of a package and having discussions with Ian McNicoll , and she gave me the green light to proceed with it. The idea did not provoke the excitement I was hoping for, but that’s hardly surprising given how many excellent, exciting ideas were flying around during that meeting.

I presented the idea again during an IHE Connectathon in Brussels earlier this year, this time with a strong focus on the EHDS and how IHE, FHIR, and openEHR can work together in that context. Here is the updated definition and my ultra-short pitch:

“An EHR Slice is an extended FHIR Implementation Guide that incorporates computable, technology-agnostic openEHR artefacts to enable bidirectional FHIR–openEHR mappings. This approach expands the role of an IG beyond messaging, positioning it as a technology-neutral system subset specification – hence the term ‘slice’.

An EHR Slice defines both a FHIR API and its partial, platform-independent implementation for any openEHR-based system, without introducing dependencies for non-openEHR consumers of the IG. This unique combination of FHIR and openEHR specifications supports a new model of system development, one that is highly relevant to stakeholders engaged in the evolving European Health Data Space (EHDS) ecosystem.”

Let’s unpack that second part: the EHDS and its stakeholders. Specifically, let’s look at why this matters so much to SMEs and startups.

If you are not familiar with the European Health Data Space (EHDS), suffice it to say that it is arguably one of the largest e-health initiatives in the world. It is incredibly ambitious, aiming to deliver arguably the most comprehensive, standardised pool of clinical data globally for 27 EU nations and around half a billion people.

The stakeholders are too numerous to count. They range from the citizens of the EU, right through to governments, pharmaceutical companies, academia, care providers, insurers, and more.

However, EHR Slices should be of particular interest to two groups on that list: SMEs and startups. According to MedTech Europe:

“There are more than 37,000 medical technology companies in Europe. The highest number of them are based in Germany, followed by Italy, the UK, Poland, Sweden and Switzerland. Small and medium-sized companies (SMEs) make up around 90% of the medical technology industry, the majority of which employs less than 50 people (small and micro-sized companies).”

This profile is unlikely to change quickly. According to tracxn.com, 4,080 HealthTech startups in Europe were founded in 2020—unsurprising at the peak of the global pandemic.

Beyond the sheer number of companies, there is also a massive financial motivation for these SMEs and startups to innovate. As noted by Galen Growth:

“Europe was the fastest-growing region in 2025, with funding rising 15% year-on-year to $6.2 billion, outpacing North America… American capital is actively targeting European category winners—particularly in Preventive Health and TechBio—to scale them within the U.S. market.”

Combining this influx of capital with the ambition of the EHDS, we are looking at an urgent need to help SMEs and startups adapt. The EHDS will become the foundational digital health infrastructure upon which all this well-funded innovation will be built.

In doing so, cost-effectiveness will be key, and that is exactly where the EHR Slice idea comes in. An innovative startup or SME should be able to align with the EHDS while minimising the amount of work required to support the FHIR APIs that EHDS compliance demands. openEHR-based platforms can make this possible if we implement EHR Slices as shared, reusable, technology-agnostic packages.

The idea is to extend a FHIR Implementation Guide (IG) with computable artefacts that are meaningful to an openEHR platform. Specifically: openEHR archetypes, templates, FHIRConnect mappings, and potentially AQL queries. There would almost certainly be metadata related to these artefacts as well.

Such an artefact extends a FHIR IG beyond an API specification and turns it into a sub-system specification. I use the term ‘sub-system’ because the FHIR resources that define the API also define the clinical data scope of the openEHR archetypes and templates; therefore, it is a subset of the data an openEHR platform can manage.

Making an EHR Slice an automatically deployable artefact is a challenge. I am not yet sure it can be done perfectly, but even pulling it off partially would automate critical aspects of supporting a FHIR-based API, saving massive amounts of effort.

Namely, it addresses the cost of mapping from the FHIR API definition to the internal, canonical representation of a clinical system. Normally, this mapping must be performed manually for every different non-standard system, and sometimes even between different deployments of the same system.

For openEHR-based systems, things are different. openEHR has a pre-defined logical structure that dictates the canonical representation and organisation of the data, which is supported by every single openEHR implementation. This means that a technology-agnostic mapping from FHIR to openEHR can be reused to automate this transformation across all systems based on openEHR.

Let me build the argument again, step by step:

1. You want to build a system that is compliant with the EHDS.
2. The EHDS is being implemented in the form of FHIR IGs.
3. You must therefore implement the FHIR API defined by these FHIR IGs.
4. Consequently, you must implement the mapping between the FHIR resource (structure and data types) and the canonical representation of your own clinical system.
5. You could get this mapping mostly for free if your internal representation is openEHR.
6. Most of the technology you would need to experiment with this idea is already available as free and/or open-source software and documentation.

There are many questions and points to discuss regarding the EHR Slice idea (and I expect objections, too). I will not go into those in this post, but based on the interest and feedback I’ve received so far, I anticipate some interesting discussions and collaborative work taking place very soon.