Skip to main content

How Source Code Access Cut openEHR CDR Query Times to O(1)

· 2 min read
Borut Jures
Borut Jures
Author of ArcEHR

Judging openEHR CDR performance is tough. You can stress-test by inserting millions of compositions and benchmarking queries. But even if it feels fast, how do you know it can’t be faster?

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:

Check for duplicate UID

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

lookupByUID method

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

Database engine SQL equals condition evaluator

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?