DRAFT: openEHR Tooling and Software overview

Software Program
1

openEHR Tooling: A Comprehensive Guide - Introduction

[!info] Tooling changes frequently
The openEHR tooling landscape changes frequently. Always cross-check against openehr.org/modelling-tools and the openEHR Discourse forum for the latest status.

If you see errors in these Wiki guides, please comment so that we can update them.

openEHR Tooling and Software overview

openEHR has accumulated tools over more than twenty years. Some are still the recommended choice. Some are deprecated but still downloadable and occasionally referenced in older tutorials. Some are commercial products that sit on top of open foundations. This guide tries to be honest about all of them in one place.

Tools are grouped by purpose, because that is how most people approach this: they want to author archetypes, or design templates, or run a clinical data repository, or query it.

This guide is split into separate Discourse Topics to make them a little more manageable:

  1. Introduction and key concepts (you are here)
  2. Archetype Authoring Tools
  3. Template Authoring Tools
  4. Clinical Data Repositories (CDRs)
  5. Knowledge Management and Repositories
  6. Developer Tooling - SDKs, Libraries and Extensions
  7. Query Tools, Form Builders and Clinical Decision Support
  8. Deprecated and Obsolete Tools
  9. Quick Comparison Table and Where to Get Help

Key openEHR terms and concepts

Before surveying tools, it helps to understand what each tool category does:

Archetypes

are reusable clinical content models written in ADL (Archetype Definition Language). They define what clinical concepts mean and what data they hold (e.g. “Blood Pressure” or “Body Weight”). Archetypes are shared internationally via the CKM. Archetypes are intended to be (primarily) clinically authored, using clinician-friendly GUI tools.

Templates

assemble archetypes together for a specific clinical use case (e.g. an ED discharge summary). A template can be localised or use-case-specific. Templates are also authored using GUI tools and stored in a CKM.

Operational Templates (OPTs)

are the compiled, flattened output of a template, exported from a CKM and consumed by CDR platforms and form renderers.

CDRs (Clinical Data Repositories)

store actual patient data in openEHR format and expose it via REST APIs and AQL queries.

Archetype Definition Language versions

ADL 1.4 vs ADL 2 - ADL 1.4 is the current workhorse version, universally supported. ADL 2 is the newer specification that unifies archetypes and templates into a single formalism and is progressively gaining support, but is not yet universally deployed.

Next: Part 2 - Archetype Authoring Tools

1 Like
2

This is a bit of a ‘starter’ attempt to create a Wikified entrypoint which we can build on. Feedback welcome. I have rough draft content for each of the sections enumerated above, but will post them one by one so I can edit for style and triple-check the details for accuracy.

3

This is a solid and much needed initiative. From a software engineering perspective, having a centralized and honest overview of the openEHR tooling landscape is extremely valuable, especially given how fragmented and historically layered this ecosystem has become.
I particularly like the decision to group tools by purpose rather than by project or vendor. That aligns well with how engineers and solution architects actually approach system design, starting from use cases like modeling, templating, storage, and querying.
A few thoughts that could strengthen this further:
First, it may help to explicitly map each tool category to a typical system architecture flow. For example, showing how archetype authoring flows into template design, then into OPT generation, and finally into CDR consumption and querying. A simple end to end pipeline view would make this much more actionable for developers who are new to openEHR.
Second, the distinction between ADL 1.4 and ADL 2 is important, but from an engineering standpoint, it would be useful to include practical guidance such as compatibility risks, migration considerations, and current production readiness. Most teams will prioritize stability over specification elegance.
Third, for each tool category, it would add a lot of value to indicate real world maturity signals. For example: active maintenance status, community adoption, production usage, and integration capabilities. This helps engineers make decisions faster without needing to research each tool independently.
Lastly, since many implementations involve integrating openEHR with external systems, it could be helpful to briefly highlight how these tools fit into broader architectures such as API gateways, event pipelines, or analytics layers.
Overall, this is a strong foundation. With a bit more emphasis on practical usage patterns and system integration context, it could become a go to reference for both engineers and solution designers working with openEHR.