Skip to main content

Querying an openEHR CDR with SQL, Cypher, and GraphQL? Yes, it’s possible.

· 3 min read
Borut Jures
Borut Jures
Author of ArcEHR

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:

AQL Query

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:

  • SQL: Extended with graph traversal, full-text search, vector, and time-series functions.
  • Cypher (openCypher): A drop-in replacement for Neo4j Cypher.
  • Gremlin: Apache TinkerPop graph traversal.
  • GraphQL: Schema-driven queries natively over HTTP.
  • MongoDB QL: Document-oriented queries via the MongoDB protocol.
  • GQL: Native Graph Query Language support coming soon.

The best part? Because ArcadeDB supports the PostgreSQL wire protocol, your team can use standard Postgres tools and drivers to connect to the server and run these queries. For advanced use cases, even more power can be unlocked directly via the Java API.

SQL and Cypher are particularly powerful for handling the deeply nested, interconnected nature of clinical models.

Here is how that exact same blood pressure AQL query looks when translated into SQL and Cypher, along with the clean JSON output you get back.

The SQL Approach (Using ArcadeDB's Extended SQL)​

SQL Query

Resulting JSON:

Result of the SQL Query

The Cypher Approach (Graph & List Comprehension)​

If your team comes from a Neo4j or graph background, they can use Cypher's native pattern matching and projections to extract the exact schema they want:

Cypher Query

You don't have to rewrite your architecture or force your team to learn a niche query language just to use openEHR.

Moving from a working multi-model query proof-of-concept to building the official openEHR REST API layer is where this transforms from a cool database experiment into a production-ready, interoperable Clinical Data Repository (CDR).

Where the Project Stands Today (and What's Next)​

I have built a working proof of concept of an openEHR CDR using the Apache 2.0 licensed ArcadeDB. Currently, it can successfully load any openEHR COMPOSITION and make the data immediately available for multi-model querying.

Next up on the roadmap: Adding the official openEHR REST API layer on top of this engine to handle standardized EHR management and composition ingestion compliance.

Since ArcadeDB is already handling the heavy lifting of storing and querying the raw COMPOSITIONs via its multi-model engine, the REST API layer will essentially act as the compliance and translation gateway.

What do you think? Would giving your dev team SQL or Cypher access accelerate your openEHR adoption, or do you prefer sticking strictly to native AQL? Let me know in the comments! 👇