Health Node.js in a Postmodern EHR World – What’s Still Missing?

„We don’t need a revolution – just the ability to work with what we already have: open, modular, scalable.“
– Tomaž Gornik, openEHR Co-Chair

Backstory

Two weeks ago I asked:
Why isn’t there a ‚Health Node.js‘ – a lightweight, open bridge between FHIR and openEHR?

The response? Remarkable:

• a lot of comments,

• practical tools and specs shared,

• honest industry feedback – even from openEHR leadership.

What We Learned

1. The gap is real.
Yes, there are mapping tools and conversion engines. But:

• they’re scattered,

• poorly documented for developers,

• rarely built with modern web stacks in mind (e.g., JavaScript/TypeScript).

2. The community is active – but fragmented.
FHIR Connect, openFHIR Atlas, HIVEConnect, openEHR2FHIRquestionnaire, SMART on openEHR – all great efforts. But no shared architecture, no developer onboarding, no visual map.

3. Node.js was a metaphor.
Several voices pointed out:
“It’s not about Node.js per se – it’s about something open, composable, testable.”
Whether written in Java, Go, or Python – the point is:
👉 We’re still missing a lightweight connector that makes both FHIR and openEHR usable for real-world application devs.

Enter: The Postmodern EHR

Tomaž Gornik recently framed the need for a “Postmodern EHR”:

• Open platforms,

• API-based architectures,

• Vendor-neutral health data layers.

This is where Health Node.js fits naturally:

• A bridge between semantic richness (openEHR) and pragmatic exchange (FHIR),

• A developer-friendly interface into clinical data,

• A configurable orchestration layer in a loosely coupled architecture.

What Should Happen Next?

Maybe we don’t need a new spec.
But what we do need:

• 🗂️ A GitHub index of all relevant FHIR ↔ openEHR projects,

• 📊 A simple visual model (e.g., Onion Architecture),

• ⚙️ A minimal reference implementation, no matter the language.

As one commenter put it:

“FHIR and openEHR are the core of the onion. Now we need tools to handle the outer layers more flexibly.”

To the community: What do you think?

• Would an open radar help you find existing tools faster?

• Should we organize a small working group or open repo?

• Is anyone already working on a practical starter kit?

Let’s not just talk about a missing bridge – let’s co-create one.

Final Thought

Health Node.js was never a concrete tool – it was a question.
But great questions shape architecture.
And sometimes all it takes is one community that starts drawing the map.