The openEHR CDR that speaks querying languages you already know

Bridge the gap between openEHR's powerful two-level data model and standard rapid application development without rewriting your stack or learning niche query languages.

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

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

query openEHR data
SELECT ehr_id, vital_signs.systolic FROM arcehr.compositions WHERE vital_signs.diastolic > 90 LIMIT 5;

One openEHR Backend. Four Powerful Paradigms.

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

Archetype Query Language (AQL) is brilliant for hierarchical health data, but it is a massive bottleneck for teams outside the openEHR ecosystem. ArcEHR leverages ArcadeDB to enable polyglot querying over openEHR data structures.

SQL

Query compositions and archetypes using classic relational table syntax and standard BI aggregations.

Cypher (openCypher)

A drop-in replacement for Neo4j Cypher. Leverage native pattern matching and projections to extract deeply nested clinical paths efficiently.

Gremlin

Achieve programmatic graph-traversal control across complex, longitudinal patient records and multi-facility semantic networks.

GraphQL

Fetch exactly the archetype payloads your client applications require—no over-fetching, wrapped in clean strongly-typed schemas.

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 researchers 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.

Current openEHR CDRs are black boxes for data stored in them. Querying is possible only with AQL. Data is persisted in a relational database but is unreadable with SQL. Persistence is where two-level modeling has quietly failed its users: the CDR works, but nobody can query the stored data using SQL.

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:

Familiar Tech Stack. Native Database Schema.

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.

What if you could use:

  • The tools most developers are already familiar with and use daily
  • Existing development approaches and paradigms
  • Existing tools and frameworks for UI components

ArcEHR bridges the structural elegance of standard openEHR archetypes with the pragmatic development velocity required by engineering teams today.

ArcEHR implements the openEHR Reference Model (RM) on ArcadeDB. Users can query using SQL/Cypher/Gremlin in ArcadeDB Studio (Apache 2.0 licensed).

ArcEHR is a candidate for both transactional and analytical openEHR CDR. It avoids the "black box" nature of existing CDRs which force users to use a niche querying language (AQL) to retrieve data.

Native openEHR Compliance

Fully compliant reference model data repository maintaining standard archetypes, templates, and full versioning natively.

openEHR REST API service endpoints for interacting with an openEHR CDR in a RESTful manner.

Familiar Protocols, Powerful Paradigms

Because ArcadeDB supports the PostgreSQL wire protocol, your team can use standard Postgres tools and drivers to connect to the server and run native or multi-model 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 without requiring an ecosystem rewrite.

openEHR uses a Two-Level Data Model

Does the two-level openEHR data model require a two-level storage model? Can we persist openEHR data using standard databases?

  • Standard SQL tools and frameworks could be used.
  • Use SQL to query stored data.
  • Having a 100% native schema supported by standard databases.

Yes, to all the above.

Open Source & Freedom from Vendor Lock-In

ArcEHR is built on a foundation of absolute transparency and vendor neutrality. I believe your data and your technology stack should belong entirely to you.

While ArcEHR is currently in private beta, the ultimate goal is to publish the entire platform under the Apache 2.0 license. I'm actively polishing the codebase and building the framework for a sustainable, community-driven ecosystem of maintainers before the public launch.

ArcEHR is currently owned and stewarded by Medical Ltd, which acts as the custodian of the project's name, code, and intellectual property during this initial growth phase. As the project matures, I plan to transition ownership to a community-driven foundation, ensuring that ArcEHR remains open source and vendor-neutral for the long term.

The Private Beta: Shape the Future of ArcEHR

I'm inviting forward-thinking organizations to join the private beta. This is a unique co-development opportunity designed for teams who want to actively shape the platform to fit their exact clinical data needs while supporting the journey toward a public open-source release.

This co-development model ensures you get dedicated, expert engineering to de-risk your deployment, while keeping ArcEHR firmly on the path to becoming a free, community-governed public good.

By joining the beta as a supporting partner, you get:

  • Full Source Code Access: You receive the complete source code for the entire running solution once you deploy to production, ensuring 100% vendor neutrality and zero lock-in.
  • 100% Vendor Neutrality: Total control over your data and infrastructure, completely free from vendor lock-in.
  • Direct Collaborative Engineering: To accelerate your implementation and ensure your team's requirements are baked into the core platform, I am available to work directly with your team as an independent consultant/architect/developer.
  • A True Partnership: Your funding and real-world feedback directly fuel the polishing of the code, making you a foundational co-creator of the ecosystem before it goes public.

Want to build a similar solution with a different database? Reach out and let's talk.