De EHDS maakt gebruik van nogal wat standaarden, profielen en concepten om interoperabiliteit en hergebruik van data te realiseren. Het is op het eerste oog niet altijd helemaal duidelijk hoe die elkaar aanvullen. Daarom was er tijdens de Connectathon in Brussel een openEHR Plugathon, waarbij aan de hand van een IHE-profiel heel duidelijk de kracht werd geschetst die ontstaat als je openEHR, IHE-profielen en FHIRconnect samen gebruikt.
Door: Marc van Aalten, interoperability expert bij Interoplab
Iedereen die betrokken is bij IHE weet: IHE-profielen zijn een van de meest praktische manieren om interoperabiliteit te realiseren. Ze zetten standaarden om in implementeerbare profielen en testbare workflows, waardoor leveranciers iets krijgen dat ze daadwerkelijk kunnen bouwen, testen en in productie kunnen gebruiken. Die praktische focus is belangrijk nu de EHDS de markt richting schaalbare, organisatie-overstijgende interoperabiliteit stuwt.
Combinatie IHE en openEHR
Dit werd des te meer duidelijk tijdens de openEHR Plugathon in Brussel. Wat dit evenement zo relevant maakte, was de discussie hoe openEHR en FHIRconnect bestaande IHE-profielen kunnen versterken. De deelnemers aan de plugathon waren het er snel over eens dat openEHR iets toevoegt wat IHE niet zelf probeert op te lossen: persistentie en semantisch beheer. OpenEHR-archetypen helpen de betekenis in de loop der tijd te behouden, zodat gegevens niet alleen succesvol worden uitgewisseld, maar ook worden opgeslagen in een vorm die later begrijpelijk, herbruikbaar en betrouwbaar blijft.
Uitwisselen én opslaan voor hergebruik
Dit wordt heel concreet als je naar het QEDm-profiel kijkt. Met 54 systemen die al in productie zijn, is dit precies het soort IHE-profiel waar de toevoeging van openEHR snel waarde kan creëren. Als de onderliggende gegevens consistent worden gemodelleerd in openEHR en worden gemapt via FHIRconnect, wordt QEDm meer dan een uitwisselingsformaat. Het wordt een patroon voor semantisch consistente persistentie, zodat de gegevens niet alleen via QEDm worden uitgewisseld, maar ook op een zinvolle manier worden opgeslagen en hergebruikt.
Het onderscheid tussen uitwisselen enerzijds en opslaan en hergebruik anderzijds is belangrijk. Een IHE-testharness kan bevestigen dat QEDm-transacties slagen, dat FHIR-bundels worden uitgewisseld, dat profielen correct worden gevalideerd en dat IHE-actoren samenwerken. Maar het vraagt niet wat er met de gegevens gebeurt na de uitwisseling. Zijn ze opgeslagen en in welke vorm? Betekent het aan de ontvangende kant nog steeds hetzelfde? Kan het volgende maand door een ander systeem worden hergebruikt? Kan het analyses of secundair gebruik ondersteunen? Dat is waar openEHR waarde toevoegt.
OpenEHR en FHIR verbinden
FHIRconnect maakt dit praktisch. In plaats van dat elke leverancier zijn eigen verborgen mappinglogica bouwt, maakt FHIRconnect de mapping tussen openEHR en FHIR expliciet, deelbaar en controleerbaar. Dat is een grote stap voorwaarts, vooral in de context van de EHDS.
Eén van de scherpste vragen die in Brussel werd gesteld, was wie alle aangepaste logica gaat betalen die nodig is om systemen alleen via FHIR API’s compliant te maken. Als elke leverancier dat probleem privé oplost, creëren we simpelweg opnieuw fragmentatie achter een gestandaardiseerde interface. Een betere aanpak is om mappings onderdeel te maken van de publicatie van archetypen en templates, zodat ze door iedereen kunnen worden hergebruikt en met beperkte inspanning kunnen worden aangepast voor lokale gebruikssituaties.
Bewijs
Gasper Andrejc liet zien dat dit niet alleen een sterk architecturaal idee is, maar iets dat in de praktijk al werkt. In zijn IPS-on-openEHR-demo (https://ips.open-fhir.com) presenteerde hij een live end-to-end voorbeeld van hoe interoperabiliteit eruit kan zien wanneer openEHR en FHIR elk hun eigen rol spelen in een hybride architectuur, in combinatie met IHE-standaarden.
Klinische data bevindt zich in een openEHR CDR, wordt op aanvraag beschikbaar gesteld via FHIR en wordt weergegeven als een International Patient Summary-dashboard. Nog belangrijker was dat het werkte met meerdere live openEHR CDR’s van verschillende leveranciers. Dat maakte de boodschap moeilijk te negeren: één mapping kan IPS-uitwisseling tussen openEHR-platforms ondersteunen. Dat is precies het soort herhaalbare interoperabiliteit dat de markt nodig heeft.
De conclusie
De samenvatting van de dag: de juiste architectuur gebruikt zowel openEHR voor persistentie als FHIR-gestuurde IHE-profielen voor uitwisseling. Dat is de combinatie die EHDS kan helpen om van beleidsambitie naar implementatierealiteit te komen.
De belangrijkste conclusie is dus duidelijk. IHE blijft de ruggengraat voor praktische interoperabiliteit. openEHR voegt de persistentie en semantische governance toe die nodig zijn om uitgewisselde data herbruikbaar te maken. FHIRconnect verbindt beide werelden via expliciete mappings. Laten we die architectuur volgend jaar in Den Haag testen met leveranciers aan de hand van een concrete use case. Dat zou de juiste volgende stap zijn.
English:
Why the IHE openEHR Plugathon in Brussels mattered
At the IHE openEHR Plugathon in Brussels, one thing became very clear: IHE is one of the most practical ways to make interoperability real. It turns standards into implementable profiles and testable workflows, giving vendors something they can actually build, test, and use in production. That practical focus is exactly why IHE matters, especially now that EHDS is pushing the market toward scalable, cross-organizational interoperability.
Why an openEHR Plugathon?
What made the discussions in Brussels especially relevant was not the idea that openEHR should replace IHE. Quite the opposite. The most productive direction was how openEHR and FHIRconnect can strengthen existing IHE profiles.
We quickly aligned on the fact that openEHR adds something IHE does not try to solve on its own: persistence and semantic governance. OpenEHR archetypes help preserve meaning over time, so data is not only exchanged successfully, but also stored in a form that remains understandable, reusable, and trustworthy later on.
Which IHE profile did we discuss?
That becomes very concrete when you look at QEDm. With 54 systems already in production, this is exactly the kind of IHE profile where adding openEHR can create value quickly. If the underlying data is modeled consistently in openEHR and mapped through FHIRconnect, QEDm becomes more than an exchange format. It becomes a pattern for semantically consistent persistence, so the data is not just exchanged through QEDm, but also stored and reused in a meaningful way afterward.
That distinction matters. A test harness can confirm that QEDm transactions succeed, that FHIR bundles are exchanged, that profiles validate correctly, and that IHE actors interoperate. But it does not ask what happens to the data after the exchange. Was it persisted, and in what form? Does it still mean the same thing on the receiving side? Can it be reused next month by another system? Can it support analytics or secondary use? That is where openEHR adds value.
Connecting openEHR and FHIR
FHIRconnect is what makes that practical. Instead of every vendor building its own hidden mapping logic, FHIRconnect makes the mapping between openEHR and FHIR explicit, shareable, and auditable. That is a major step forward, especially in the context of EHDS.
One of the sharpest questions raised in Brussels was who is going to pay for all the custom logic required to make systems compliant through FHIR APIs alone. If every supplier solves that problem privately, we will simply recreate fragmentation behind a standardized interface. A better route is to make mappings part of the publication of archetypes and templates, so they can be reused by everyone and adapted with limited effort for local use cases.
And then came the proof
Gasper showed that this is not just a strong architectural idea, but something that already works in practice. In his PS-on-openEHR demo (https://ips.open-fhir.com), he presented a live end-to-end example of what interoperability can look like when openEHR and FHIR each play their own role in a hybrid architecture, in combination with IHE standards.
Clinical data lives in an openEHR CDR, is exposed on demand through FHIR, and is rendered as an International Patient Summary dashboard. Even more importantly, it worked across multiple live openEHR CDRs from different vendors. That made the message hard to ignore: one mapping can support IPS exchange across openEHR platforms. That is exactly the kind of repeatable interoperability the market needs.
The conclusion
For me, the Better slide captured the day best: the right architecture uses both openEHR for persistence and FHIR-powered IHE profiles for exchange. That is the combination that can help move EHDS from policy ambition to implementation reality.
So the real takeaway from Brussels is straightforward. IHE remains the backbone for practical interoperability. openEHR adds the persistence and semantic governance needed to make exchanged data reusable. FHIRconnect links both worlds through explicit mappings.
Let’s test that architecture next year in Amsterdam with vendors around a concrete use case. That would be the right next step.