Health Node.js – the missing bridge between FHIR and openEHR?

FHIR is widely adopted in many healthcare systems. openEHR is considered one of the most powerful semantic models for structured clinical data.
Both serve different purposes, both are open, and both are community-driven.

And yet: anyone trying to connect the two usually ends up working in isolation.

Two standards, no shared language

FHIR describes resources – lightweight, API-friendly, and flexible.
openEHR organizes knowledge in archetypes and templates – deeply structured, long-term oriented, and semantically precise.

Both are valid.
Both solve problems left by older standards.
But together? Rarely.

In practice, systems tend to be either „FHIR-first“ or „openEHR-native.“ The bridge is often missing – or ends in fragile, one-off mappings.

The technical gap

There are JavaScript libraries for FHIR – for REST interfaces or validation.
openEHR, on the other hand, lives mostly in Java ecosystems. AQL, templates, composition structures – all of it is hard to integrate into modern web stacks.

The result:
Anyone looking for a lightweight, API-ready platform that connects FHIR and openEHR will find… nothing.

No community project. No SDK. No middleware.
No “Health Node.js.”

But why not?

Possible reasons:

• The mapping is too complex.

• There’s no standardized way to reliably convert between FHIR resources and openEHR structures.

• Deep interoperability at this level is expensive – and rarely rewarded.

• And maybe no one takes Node.js seriously in healthcare IT.

It might also be a cultural issue:
FHIR is pragmatic, fast, developer-centric.
openEHR is rigorous, model-driven, long-term.

And yet, these contrasts could make them ideal complements.

Regulatory friction – the silent blocker

Another overlooked challenge:
Real-world healthcare solutions must be auditable, traceable, and compliant – whether under ISO 13485, MDR, EHDS, or national rules.

This means:

• Validated data flows

• Logging and traceability

• Separation of medical device logic and infrastructure

• Documented transformation logic

A Health Node.js that integrates these aspects — not just technically functional, but regulatorily ready — could be a serious enabler for innovation.

Health Node.js – just an idea?

What if there was a middleware that could:

• Validate, store and transform FHIR resources?

• Make openEHR data accessible via AQL?

• Bridge both with configurable, bidirectional mapping?

• Provide audit-ready architecture?

• Be built with JavaScript/TypeScript – open, modular, scalable?

The technology exists.
What’s missing is the will to combine them – and a regulatory mindset from the beginning.

Final thought

Maybe this is one of the most overlooked gaps in digital health:
Not the next new standard – but the bridge between the existing ones.

“Health Node.js” isn’t a product. Not yet.
Maybe it’s just an idea. Or a question.
But one that deserves to be asked.

💬 What do you think?

Are there technical, political or regulatory reasons why this gap remains?
Or are we just waiting for the right project at the right time?