The results were brutal:

❌ My CDR: 15 ms to commit a composition

⚡ EHRbase: 1 ms

Humble pie served. I immediately went down the profiling rabbit hole to figure out where my architecture was bleeding performance. After two days of profiling, I accepted that the best I could do with my CDR was 6 times slower than EHRbase.

Fast forward to today: I started benchmarking read performance. To do that, I needed the UIDs of the inserted EHRs and compositions. But EHRbase wasn't returning them in the response body.

That’s when the dominoes started falling:

• I was expecting openEHR REST API 1.1.0 responses, but EHRbase follows 1.0.2 (which returns UIDs in the ETag response header).
• While investigating responses, I noticed something strange: EHRbase was also returning errors on every single EHR creation.
• The issue? EHRbase expects an EHR_STATUS with PERSON, whereas the latest spec example uses PARTY_SELF.

The plot twist: That 1 ms benchmark wasn't committing compositions at lightning speed. It was just reporting creation errors in record time. The contributions were never actually processed. 😂

Once I fixed the payload and reran the benchmarks properly:

🐢 EHRbase real speed: 9.62 ms

⚡ My optimized CDR: 4.43 ms

The first test involves creating 100 EHRs, each with 1000 compositions. I’m using an 885-line Vital signs composition to make the test realistic:

The second test is querying the compositions using all seven different ways to use the GET COMPOSITION endpoints (700k queries):

I’m running this on my 5-year-old Apple M1 Pro with 16 GB RAM, while simultaneously running 3 IDEs and Docker.

Moral of the story: Always check your HTTP status codes before you start questioning your entire architecture.

When I finished my openEHR CDR, it was hitting 15ms per committed composition. Humanly fast—but I wanted to test the limits.

Because ArcEHR gives customers full source code access—and uses an open-source database written in the same language—I ran the IntelliJ IDEA profiler across the entire stack.

The Profiler's Trail​

1. The flame graph pointed to high execution time inside CreateCompositionHandler:

2. Drill-down revealed the culprit: lookupByUid(), an innocent check to see if a UID already exists.

3. Following the query into the database engine exposed why the SQL query was lagging.

The Fix​

The UID lookup index was using an LSM Tree. Switching to a Hash Index brought lookup time down to O(1)—ensuring lookups stay instant no matter how large the CDR grows.

Conclusion​

Why source code matters: Without visibility into the full stack, a bottleneck like this remains invisible. Source code access turns black-box performance limits into solvable engineering problems.

Have you encountered performance bottlenecks or scaling issues with your openEHR CDR? How are you profiling your health data architecture?

In ArcEHR, we map the openEHR Reference Model directly to a graph database using ArcadeDB. It also comes with a free and open-source data browser ArcadeDB Studio.

Best of all? You can still query and manipulate this graph data using standard SQL through any PostgreSQL GUI client or library.

Here is a quick look at how INSERT and SELECT work under the hood.

Inserting openEHR Data​

To insert openEHR data, we use a simple SQL INSERT statement targeting the create_composition table. Behind the scenes, a database trigger automatically processes this payload, shredding the JSON and storing the composition directly into RM Document nodes and relationship edges.

INSERT INTO create_composition (ehr_id, content) VALUES ("ehr-1", {
    "archetype_node_id": "openEHR-EHR-COMPOSITION.encounter.v1",
    "name": {"value": "Vital Signs"},
    "uid": {"_type": "OBJECT_VERSION_ID", "value": "8849182c::openEHRSys.example.com::1"},
    "archetype_details": {
        "archetype_id": {"value": "openEHR-EHR-COMPOSITION.encounter.v1"},
        "template_id": {"value": "Example.v1::c7ec861c-c413-39ff-9965-a198ebf44747"},
        "rm_version": "1.0.2"
    },
    "language": {"terminology_id": {"value": "ISO_639-1"}, "code_string": "en"},
    "content": [{"_type": "COMPOSITION"}]
})

The schema of our create_composition table strictly mirrors the openEHR REST API, keeping integration painless.

Querying openEHR Data (Zero Joins Needed)​

Because this is a graph database, we use the database's native out() function to traverse edges. To find all blood pressure records for an EHR or Composition, we simply traverse the corresponding edge. No JOINs, no performance degradation as your dataset grows.

Scenario A: Simple SELECT with One Archetype​

Let’s fetch the blood pressure data for a specific EHR:

SELECT $blood_pressure.$event AS blood_pressure
FROM   EHR
LET    $blood_pressure = out(`openEHR-EHR-OBSERVATION.blood_pressure.v2`)
WHERE  $ehr = "ehr-1"

Result:

{
  "blood_pressure": [[[
    {"_type": "ELEMENT", "archetype_node_id": "at0004",
      "name": {"_type": "DV_TEXT", "value": "Systolic"},
      "value": {"_type": "DV_QUANTITY",
        "magnitude": 140.5,
        "units": "mm[Hg]"
      }
    },
    {"_type": "ELEMENT", "archetype_node_id": "at0005",
      "name": {"_type": "DV_TEXT", "value": "Diastolic"},
      "value": {"_type": "DV_QUANTITY",
        "magnitude": 80.1,
        "units": "mm[Hg]"
      }
    }
  ]]]
}

Scenario B: Querying Multiple Archetypes with Filters​

What if we want both blood pressure and pulse for a patient, filtered by specific clinical thresholds?

We can leverage the CONTAINS operator to traverse and filter nested collections in a single, readable query:

SELECT $blood_pressure.$event AS blood_pressure, $pulse.$event AS pulse
FROM   EHR
LET    $blood_pressure = out(`openEHR-EHR-OBSERVATION.blood_pressure.v2`),
       $pulse = out(`openEHR-EHR-OBSERVATION.pulse.v2`)
WHERE  $ehr = "ehr-1"
  AND  $blood_pressure.$event CONTAINS (
          archetype_node_id = "at0004" AND  -- Systolic
          value.magnitude > 140 AND value.units = "mm[Hg]")))
  AND  $pulse.$event CONTAINS (
          archetype_node_id = "at0004" AND  -- Rate
          value.magnitude > 80 AND value.units = "/min")))

This returns a clean, structured JSON object containing both clinical data points simultaneously—without a single SQL JOIN:

{
  "blood_pressure": [[[
    {"_type": "ELEMENT", "archetype_node_id": "at0004",
      "name": {"_type": "DV_TEXT", "value": "Systolic"},
      "value": {"_type": "DV_QUANTITY",
        "magnitude": 140.5,
        "units": "mm[Hg]"
      }
    },
    {"_type": "ELEMENT", "archetype_node_id": "at0005",
      "name": {"_type": "DV_TEXT", "value": "Diastolic"},
      "value": {"_type": "DV_QUANTITY",
        "magnitude": 80.1,
        "units": "mm[Hg]"
      }
    }
  ]]],
  "pulse": [[[
    {"_type": "ELEMENT", "archetype_node_id": "at0004",
      "name": {"_type": "DV_TEXT", "value": "Rate"},
      "value": {"_type": "DV_QUANTITY",
        "magnitude": 83.7,
        "units": "/min"
      }
    }
  ]]]
}

Developer Tooling​

If you want to visualize your graph traversals, you can use the open-source ArcadeDB Studio browser to run and analyze your queries visually. Or, simply stick to your favorite PostgreSQL client and libraries — ArcEHR speaks PostgreSQL natively.

If you are using ArcEHR, you don't need any of that. You can query and insert graph-mapped openEHR data using the standard, vanilla pg library in TypeScript.

Because ArcEHR presents a PostgreSQL-compatible interface over ArcadeDB, your existing database drivers, parameterized queries, and connection pools work out of the box.

Here is how easily you can handle openEHR CRUD operations in TypeScript:

1. The Setup​

No custom database clients required. Just import the standard pg driver, initialize your client, and connect.

import { Client } from 'pg'
const client = await new Client({
    database: 'arcehr',
    port: 5432,
    user: 'root',
    password: 'arcadedb'}).connect()

2. Inserting openEHR Data with Type Safety​

When inserting openEHR data, you pass your structured JSON payload directly as a parameterized query. A trigger on the create_composition table handles the heavy lifting, automatically shredding the JSON into RM Document types and graph edges.

// Insert a new composition
const content = {
  archetype_node_id: 'openEHR-EHR-COMPOSITION.encounter.v1',
  name: {value: 'Vital Signs'},
  uid: {_type: 'OBJECT_VERSION_ID', value: '8849182c::openEHRSys.example.com::1'},
  archetype_details: {
    archetype_id: {value: 'openEHR-EHR-COMPOSITION.encounter.v1'},
    template_id: {value: 'Example.v1::c7ec861c-c413-39ff-9965-a198ebf44747'},
    rm_version: '1.0.2',
  },
  language: {terminology_id: { value: 'ISO_639-1' }, code_string: 'en'},
  content: [{ _type: 'OBSERVATION' }]
}
const insert = `INSERT INTO create_composition (ehr_id, content) VALUES ($1, $2)`
await client.query(insert, ['ehr-1', content])

The Response: You receive a clean response back, confirming the target EHR and returning the database record ID (@rid):

{
  ehr_id: 'ehr-1',
  content: '{"archetype_node_id":"openEHR-EHR-COMPOSITION.encounter.v1","name":{"value":"Vital Signs"},"uid":{"_type":"OBJECT_VERSION_ID","value":"8849182c::openEHRSys.example.com::1"},"archetype_details":{"archetype_id":{"value":"openEHR-EHR-COMPOSITION.encounter.v1"},"template_id":{"value":"Example.v1::c7ec861c-c413-39ff-9965-a198ebf44747"},"rm_version":"1.0.2"},"language":{"terminology_id":{"value":"ISO_639-1"},"code_string":"en"},"content":[{"_type":"COMPOSITION"}]}',
  prefer: 'return=minimal',
  content_type: null,
  accept: null,
  '@rid': '#72:1'
}

3. Querying openEHR Data (Zero-Join Graph Traversal)​

Because ArcEHR stores this data as a graph under the hood, we can traverse nested clinical paths in a single query without performance-killing relational JOINs.

Scenario A: Fetching Blood Pressure​

Lets pull all blood pressure records for a specific EHR. Note how we use standard $1 placeholders to prevent SQL injection:

const select = `SELECT $blood_pressure.$event AS blood_pressure
                FROM   EHR
                LET    $blood_pressure = out("openEHR-EHR-OBSERVATION.blood_pressure.v2")
                WHERE  $ehr = $1`
await client.query(select, ['ehr-1'])

Resulting JSON: You get back clean, structured openEHR Reference Model JSON elements directly in your application:

{
  blood_pressure: [[[
        {"@type":"ELEMENT","_type":"ELEMENT","archetype_node_id":"at0004","name":{"@type":"DV_TEXT","_type":"DV_TEXT","value":"Systolic"},"value":{"@type":"DV_QUANTITY","_type":"DV_QUANTITY","magnitude":746.5,"units":"mm[Hg]"}},
        {"@type":"ELEMENT","_type":"ELEMENT","archetype_node_id":"at0005","name":{"@type":"DV_TEXT","_type":"DV_TEXT","value":"Diastolic"},"value":{"@type":"DV_QUANTITY","_type":"DV_QUANTITY","magnitude":526.1,"units":"mm[Hg]"}}
    ]],[[
        {"@type":"ELEMENT","_type":"ELEMENT","archetype_node_id":"at0004","name":{"@type":"DV_TEXT","_type":"DV_TEXT","value":"Systolic"},"value":{"@type":"DV_QUANTITY","_type":"DV_QUANTITY","magnitude":746.5,"units":"mm[Hg]"}},
        {"@type":"ELEMENT","_type":"ELEMENT","archetype_node_id":"at0005","name":{"@type":"DV_TEXT","_type":"DV_TEXT","value":"Diastolic"},"value":{"@type":"DV_QUANTITY","_type":"DV_QUANTITY","magnitude":526.1,"units":"mm[Hg]"}}
  ]]]
}

Scenario B: Multi-Archetype Queries with Path Filtering​

What if you need to fetch both blood pressure and pulse, but only return records where the patient's vitals exceed specific safety thresholds?

We use the CONTAINS operator to query inside the nested clinical arrays:

const select = `SELECT $blood_pressure.$event AS blood_pressure, $pulse.$event AS pulse
                FROM   EHR
                LET    $blood_pressure = out("openEHR-EHR-OBSERVATION.blood_pressure.v2"),
                       $pulse = out("openEHR-EHR-OBSERVATION.pulse.v2")
                WHERE  $ehr = $1
                  AND  $blood_pressure.$event CONTAINS (
                           archetype_node_id = "at0004" AND -- Systolic
                           value.magnitude > 140 AND value.units = "mm[Hg]")
                  AND  $pulse.$event CONTAINS (
                           archetype_node_id = "at0004" AND -- Rate
                           value.magnitude > 80 AND value.units = "/min")`
await client.query(select, ['ehr-1'])

Result:

{
  blood_pressure: [[[
        {"@type":"ELEMENT","_type":"ELEMENT","archetype_node_id":"at0004","name":{"@type":"DV_TEXT","_type":"DV_TEXT","value":"Systolic"},"value":{"@type":"DV_QUANTITY","_type":"DV_QUANTITY","magnitude":746.5,"units":"mm[Hg]"}},
        {"@type":"ELEMENT","_type":"ELEMENT","archetype_node_id":"at0005","name":{"@type":"DV_TEXT","_type":"DV_TEXT","value":"Diastolic"},"value":{"@type":"DV_QUANTITY","_type":"DV_QUANTITY","magnitude":526.1,"units":"mm[Hg]"}}
    ]],[[
        {"@type":"ELEMENT","_type":"ELEMENT","archetype_node_id":"at0004","name":{"@type":"DV_TEXT","_type":"DV_TEXT","value":"Systolic"},"value":{"@type":"DV_QUANTITY","_type":"DV_QUANTITY","magnitude":746.5,"units":"mm[Hg]"}},
        {"@type":"ELEMENT","_type":"ELEMENT","archetype_node_id":"at0005","name":{"@type":"DV_TEXT","_type":"DV_TEXT","value":"Diastolic"},"value":{"@type":"DV_QUANTITY","_type":"DV_QUANTITY","magnitude":526.1,"units":"mm[Hg]"}}
  ]]],
  pulse: [[[
        {"@type":"ELEMENT","_type":"ELEMENT","archetype_node_id":"at0004","name":{"@type":"DV_TEXT","_type":"DV_TEXT","value":"Rate"},"value":{"@type":"DV_QUANTITY","_type":"DV_QUANTITY","magnitude":636.7,"units":"/min"}}
    ]],[[
        {"@type":"ELEMENT","_type":"ELEMENT","archetype_node_id":"at0004","name":{"@type":"DV_TEXT","_type":"DV_TEXT","value":"Rate"},"value":{"@type":"DV_QUANTITY","_type":"DV_QUANTITY","magnitude":636.7,"units":"/min"}}
  ]]]
}

No database schema migrations, no nested relational mapping code, and no performance loss. Just standard PostgreSQL queries executing lightning-fast graph traversals in Node.js.

The Takeaway​

When building modern clinical applications, you shouldn't have to compromise between the rich standards of openEHR and developer-friendly tooling. ArcEHR lets you use the standard Node/TypeScript ecosystem you already know and love to query complex health data seamlessly.

I think there’s a third option that is changing the game: Natural Language via AI.

Instead of wrestling with syntax, you type:

Get EHR data where systolic blood pressure > 140 mm[Hg] and pulse > 80/min

In ArcEHR, I use SQL as the main querying language, allowing developers to either write queries by hand or let the integrated AI assistant do the heavy lifting.

Modern LLMs excel at translating intent to precise database queries. If they can navigate complex codebases, a few lines of SQL is a breeze.

What’s your preferred approach for openEHR?

1. By hand (SQL/AQL) – Complete control and precision.
2. Visual Builder – Drag-and-drop, low-code, accessible.
3. AI/Natural Language – Fast, intuitive, zero syntax overhead.

ArcEHR Studio is a great example of the first and third approach in action:

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.

Simple SELECT with one archetype​

Let's say we want to get the blood pressure data for a given encounter.

We can use the out() function to get all the blood pressure records for a given encounter. The out() function takes an edge type name as an argument. The out() function returns a list of all the records that have the specified edge type. The out() function can be used to traverse the graph database to get the data.

Result:

SELECT with multiple archetypes​

Let's say we want to get the blood pressure and pulse data for a given encounter. We can use the out() function to get all the blood pressure and pulse records for a given encounter. We can use the CONTAINS operator to filter the records. The CONTAINS operator takes a sub-query as an argument. The CONTAINS operator returns a list of all the records that satisfy the sub-query.

Result:

Result:

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:

• 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)​

Resulting JSON:

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:

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! 👇

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?

openEHR uses a two-level data model. Does a two-level openEHR data model require a two-level storage model? Can we save openEHR data using a standard relational model?

I remember Thomas' remark that we would need 10000+ tables. I agreed. But what if tables are generated and migration is handled using tools like Liquibase?

• Standard SQL tools and frameworks could be used.
• Use SQL for stored data.
• Having a 100% relational schema.

However a pure SQL approach lacks constructs like inheritance, logic in triggers, and events (it has them, but they are not powerful enough). In short, it lacks the object-oriented constructs that make complex development manageable. Forcing SQL to do too much wasn't productive.

Instead of treating archetypes as SQL, I tried treating archetypes as code.

My first pick was Jmix.io. It is a rapid application development platform with everything included. It includes Jmix Studio to customize the UI.

I also tried:

• https://www.odoo.com/
• https://orm.drizzle.team/
• https://typeorm.io/
• https://formkit.com/
• https://frappe.io/framework

So far, Jmix is the best suited full-stack platform for the complexity we are dealing with in openEHR.

I'm currently researching graph databases for storing openEHR data. I'm making great progress with ArcadeDB.

A few screenshots of the code (all the code is generated, not handwritten):

Jmix​

Drizzle​

ArcadeDB​

This can be queried using the following SQL:

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

I see ArcadeDB as a candidate for both transactional and analytical openEHR CDR. It would avoid the "black box" nature of existing CDRs which force users to use a niche querying language (AQL) to get any data out of the CDR.

Another "feature" is skipping at-codes for querying, substituting them with readable property names familiar to experts who query traditional relational databases:

This can be queried using the following SQL: