4 posts tagged with "ArcadeDB"

I made some progress with SQL queries using graph traversal over openEHR data:

COMPOSITION.encounter.v1 has OBSERVATION.blood_pressure.v2

Since ArcEHR maps openEHR Reference Model (RM) to the graph database, we can use graph traversal to query the openEHR data. The data stored in the graph database is much more efficient than the relational database. No joins are needed to retrieve the data. We use out('has_openEHR-EHR-OBSERVATION.blood_pressure.v2') to get all the blood pressure records for a given COMPOSITION or EHR.

If you work with openEHR, you already know Archetype Query Language (AQL). It’s a brilliant technical achievement designed specifically for hierarchical health data.

But let’s be honest: most developers and analysts outside the openEHR ecosystem have never heard of it. When onboarding new engineers to a health tech project, teaching them AQL from scratch is a massive bottleneck. Usually, they have to write or look at something like this just to get blood pressure data:

What if you could build an openEHR Clinical Data Repository (CDR) but let your team use the technologies they already know? You can even treat the CDR as a PostgreSQL database.

By leveraging ArcadeDB, we can enable polyglot querying over openEHR data structures. Your developers and analysts can pick the exact query language that fits their background:

Is an openEHR CDR without integrated forms a developer’s nightmare? Anyone who has worked with openEHR knows the power of its two-level data model. But they also know the friction: forcing developers to abandon their familiar daily tools, reinvent the wheel for UIs, and grapple with complex data storage.

How can we bridge the gap between openEHR’s complexity and standard rapid application development?

What if we could use:

• the tools most developers are already familiar with and use daily
• existing development approaches
• existing tools and frameworks for UI

What if we didn't have to reinvent the wheel for openEHR projects?

Sidharth Ramesh proposes openEHR archetypes as SQL tables and I'm one of the few sympathizers of that approach 😊

I tried it with 4 different SQL/ORM libraries, but those pure SQL approaches aren't a good match for openEHR highly hierarchical data.

My current attempt involves implementing the openEHR Reference Model (RM) on ArcadeDB. The POC works well. Users can query using the standard ArcadeDB flavor of SQL in their browsers (all Apache 2.0 licensed).