openEHR

openEHR is an open specification family for electronic health records, and it is the most serious structural alternative to FHIR that healthcare has. Where FHIR ships a library of resources you profile and constrain, openEHR splits the problem in two: a small, stable Reference Model that software implements once and rarely changes, and a large, evolving body of archetypes and templates authored by clinicians rather than developers. The information model is a governed artifact in its own right, not something baked into an API contract — which is why openEHR shows up as a persistence and modelling layer underneath systems that still speak FHIR at the edge.

• Two-level modelling - A stable Reference Model (BASE, RM) underneath, with clinical meaning expressed separately as archetypes and templates, so the data model can change without changing the software.
• ADL and the Archetype Model - The Archetype Definition Language (ADL 2), Archetype Object Model, and Operational Templates give the clinical layer a formal, versioned, machine-readable grammar.
• AQL - The Archetype Query Language queries by archetype path rather than by physical schema, so a query survives the storage design underneath it.
• A published REST API - The ITS-REST component defines System, EHR, Query and Definition APIs, with Demographic and Admin in development, all shipped as OpenAPI 3.0.
• Clinical Knowledge Manager - CKM is a public, governed registry of the archetypes themselves, reviewed by clinicians internationally.

On artifacts, openEHR is stronger than its reputation suggests. The ITS-REST component publishes real OpenAPI 3.0 YAML — seven API surfaces in codegen, HTML and validation variants — in a public Apache-2.0 repository, which puts it in Tier A alongside CAMARA and OGC API rather than in the documented-model tier where most information models land. It also ships JSON Schema (ITS-JSON — 790 draft-07 files, including consolidated Reference Model bundles with 134 definitions), XSD (ITS-XML), and BMM model files (ITS-BMM). One caveat worth carrying: every published OpenAPI declares Creative Commons Attribution-NoDerivs 3.0. Nothing is gated and nothing 403s an automated client, so access is open — but ND means you may not redistribute a modified specification document. Free to read is not the same as openly licensed.

What surprised me most is the agent posture. specifications.openehr.org serves a genuine llms.txt, gives every specification page a Markdown twin — reachable either by appending .md or by sending Accept: text/markdown — and exposes three structured JSON endpoints for the component catalog, the class index, and the release calendar. That is a standards body that has actually thought about machine readers, and very few of the ninety-eight in this catalog have. The gap is on the organizational side: openehr.org itself has no llms.txt, so the front door is less legible than the specifications behind it.

For anyone governing healthcare APIs, openEHR and FHIR are not a choice you make once. The pattern I keep seeing is openEHR as the durable clinical record and FHIR as the exchange contract on top of it — and if you are running both, the archetype layer is where the governance work actually lives.