openEHR Archetypes Explained: The Clinical Content Layer of a Future-Proof CDR

Archetypes are the core building blocks of openEHR's two-level modelling approach: formal, reusable, computable definitions of clinical concepts — a blood pressure measurement, a body weight, a medication order — expressed in the vendor-neutral Archetype Definition Language (ADL) [2]. Under the two-level approach, a stable reference model constitutes the first level of modelling, defining generic data structures (compositions, entries, data values) that never change with clinical content, while archetypes and templates constitute the second level, expressing clinical meaning as constraints on that reference model [1]. Runtime data therefore conforms twice: concretely to the reference model, and semantically to the archetypes.

Each archetype is developed collaboratively by clinical and technical experts through the Clinical Knowledge Manager (CKM) — the openEHR Foundation's international repository, which supports the full lifecycle of archetypes and templates through a formalized review and publication process and provides governance over the shared knowledge base [3]. The result is a genuinely unusual asset in health IT: a global, openly licensed library of clinically validated data definitions that any conformant platform can consume.

Why Two Levels Change the Economics of a CDR

The architectural payoff of separating the reference model from the clinical content layer is blunt: the same persistence schema can store any clinical concept without structural changes. Because clinical semantics live in archetypes rather than in database tables or application code, deploying a new concept — a new assessment scale, a new device measurement, a pandemic-era symptom checklist — means loading a new archetype and template into the CDR, not scheduling a software release and a schema migration. The openEHR architecture documents describe exactly this contrast with "classic" systems, where domain semantics are encoded somewhere in the software or database and every clinical change becomes an engineering change [1].

For a CTO, this reframes the build-vs-evolve question. In our experience, the total cost of a clinical data platform is dominated not by the initial build but by the decade of clinical model churn that follows — and two-level modelling moves that churn from the engineering backlog to the (much cheaper, much faster) modelling workflow. Queries follow the same logic: openEHR's AQL queries data by archetype paths rather than physical schema, so the decoupling holds end to end.

What Architects Must Understand: Versioning, Specialization, Slots

• Versioning: Archetype identifiers carry their major version (e.g., openEHR-EHR-OBSERVATION.blood_pressure.v2), and CKM manages the lifecycle from draft through team review to published status [4]. Data committed against a given archetype version remains valid against it forever — so an upgrade strategy for the modelling layer (which archetype versions are in production, how new major versions are adopted, how queries span versions) belongs in your architecture, not in a wiki page discovered later.
• Specialization: When local requirements genuinely exceed a published archetype, specialization is the controlled extension mechanism: a child archetype adds or narrows constraints while remaining conformant to its parent, so data captured with the specialized archetype can still be processed and queried by anything that understands the parent. Notably, improved support for specialization and redefinition is one of the headline advances of ADL 2 over ADL 1.4 — the version most tooling and platforms grew up on, and the basis of the ISO 13606-2 standard [2].
• Slots and templates: Archetypes compose: a slot is a defined insertion point where one archetype allows others to plug in (a blood pressure observation embedding a device cluster, for example). Templates then assemble and further constrain archetypes for a concrete use case — a specific form, document, or API payload — producing the operational structures a CDR validates compositions against at commit time. Architecturally, archetypes are your reusable vocabulary; templates are the sentences your systems actually exchange.

Selection Strategy: Reuse First, Specialize Second, Invent Last

When selecting or designing archetypes for a deployment, the ordering that maximizes interoperability is consistent: adopt published CKM archetypes first — every published archetype you reuse is a data definition you share with every other openEHR deployment worldwide, at zero modelling cost. Where a published archetype almost fits, engage the CKM process (change requests, reviews) rather than forking locally; the federated model of international and national CKM instances exists precisely so local needs can flow back into shared assets [4]. Where local requirements are genuinely local, specialize rather than invent, preserving parent compatibility. Only when a concept has no published ancestor should you author from scratch — and then consider contributing it back.

Tooling supports this workflow end to end: web-based modelling tools such as Better's Archetype Designer, alongside the ADL Workbench reference compiler and the wider ecosystem catalogued by the openEHR Foundation [5], produce ADL 1.4 or ADL 2 artifacts suitable for loading into conformant CDR platforms. In our experience the tooling is rarely the bottleneck — modelling governance is: deciding who owns archetype selection, who signs off specializations, and how template changes reach production is what separates disciplined openEHR programs from archetype sprawl.

Where CaboLabs Fits

Archetypes are where CaboLabs lives. We have spent years engineering openEHR-based systems — clinical modelling, template design, CDR implementation, and integration with FHIR and HL7 ecosystems — and we built our clinical data repository, Atomik, openEHR-native from the ground up: it validates every composition against its templates at commit time, stores any archetype-defined concept without schema changes, and makes clinical data queryable through archetype paths. That is two-level modelling delivered as working infrastructure, not a slideware promise.

If you are evaluating openEHR for a clinical data platform, defining your archetype governance and modelling workflow, or looking for a CDR that turns published archetypes into production data, talk to us at cabolabs.com — we'll help you build on the clinical models the world has already agreed on.