Standards Research
openEHR — The Agent-Native Standards Body Nobody Reads That Way
The main structural alternative to FHIR publishes real OpenAPI, a real llms.txt, Markdown twins of every specification page, and three JSON endpoints — and not one of its thirty-four coalition companies is in my catalog.
On the standard: openEHR · Updated September 2026 · Evidence as of 2 September 2026
This is my standing research position on openEHR, written after profiling it as a standards-body repo on 2 September 2026. It exists because the catalog held openEHR only as a row in the data-model inventory for a year, and reading it properly turned up three things I did not expect.
The specification site is agent-native, and that is rare
specifications.openehr.org serves a genuine llms.txt — 11,107 bytes of actual routing, not a
placeholder. Every specification page has a Markdown twin, reachable either by appending .md or by
sending Accept: text/markdown; the BASE architecture overview returns HTTP 200, text/markdown,
183,557 bytes either way. Three structured endpoints — /api/components.json, /api/classes.json,
/api/releases.json — publish the component catalog, the full RM/AM class index and the release
calendar as JSON.
The llms.txt even states its own limitation, which I have not seen anywhere else: the Markdown
representation carries the prose and drops the per-class attribute tables, and it tells a machine to
use /api/classes.json or the HTML class index to resolve a class name instead.
I have profiled a lot of standards bodies. This is the best machine-reader posture I have found in any of them, and openEHR does not market it.
The gap is the front door. openehr.org/llms.txt is a 404. The organization is less legible to a
machine than the specifications behind it, which is exactly backwards from how most bodies fail.
Free to read is not openly licensed
Every published ITS-REST OpenAPI declares license: Creative Commons Attribution-NoDerivs 3.0
Unported. The specifications are free to retrieve and free to implement — nothing is gated, nothing
403s an automated client — but ND means a modified redistribution of a specification document is
not permitted. The tooling repositories are Apache-2.0.
This is why the catalog tracks schema_access separately from licence. openEHR is open on access
and restrictive on derivation, and collapsing those into one field would lose the more
decision-relevant half.
The contracts are specifications, and they declare no security at all
Six REST surfaces ship as OpenAPI 3.0 — EHR, Query, Definition and System marked STABLE, Demographic
and Admin marked DEVELOPMENT — across 97 operations. Every one declares the templated server
https://{baseUrl}/v1. Zero absolute base URLs. That is correct behaviour for a specification and
it is the reason a standards body must never be read through the provider Kin Score composite.
Less correct: not one of the six declares a security scheme. components.securitySchemes is absent
throughout and the overview document carries security: []. For a specification family describing
lifelong patient records, leaving authentication entirely to the implementer is a real gap, and it is
the one thing here I would change first.
There is also no conformance programme to test a claim against. The CNF component exists and is
Development status, so where OGC has CITE, an assertion of openEHR conformance currently has nothing
public to check it against.
The coalition is fully public and completely missing from my catalog
openEHR publishes 59 named people with roles across the CIC Board, the openEHR Foundation Board, and the Specification, Clinical and Education program boards, with employers beside 37 of them. Unlike OGC — which publishes its results openly and its process privately behind a 401 — openEHR’s working surface is entirely open.
Matched against the api-evangelist network: 0 of 34 organizations have a repo. Better, Nedap Healthcare, Ocean Health Systems, DIPS, vitagroup, EHRbase, Medblocks, Cambio Healthcare Systems, Marand, CaboLabs, VeraTech for Health — the entire openEHR vendor ecosystem is a blind spot. That is the most actionable finding this profile produced.
On the score
openEHR scores 29.0 (thin) on the Kin Score against FHIR’s 21.3, CAMARA’s 25.6 and OGC’s 20.8.
I want to be blunt about what that does and does not mean: all four are scoring artifacts. The
rubric measures services, and none of these bodies publishes one. openEHR ranks above FHIR here
largely because its profile is freshly and completely declared — the developer portal, the API
reference, the llms.txt, the vocabulary and the JSON Schema bundles all point at surfaces that were
verified live on 2 September 2026 and simply had never been recorded.
The number that is actually comparable is the agent-readiness read, and even there the 22.7 understates the specification site badly, because the rubric looks at the provider host and openEHR’s machine surface lives one subdomain over.
Sources
https://openehr.org/governance/,/specification-program/,/clinical-program-board/,/education-program/— the rosters, read by handhttps://specifications.openehr.org/—llms.txt, the three JSON endpoints, the release calendarhttps://github.com/openEHR/specifications-ITS-REST— the OpenAPI 3.0 documentshttps://github.com/openEHR/specifications-ITS-JSON— 790 draft-07 JSON Schema fileshttps://ckm.openehr.org/ckm/— the Clinical Knowledge Manager
