Claims review

Every public text about FerroEHR is read, once per release, against EHDS Art. 28 (Regulation (EU) 2025/327). The article reads: “In the information sheet, instructions for use or other information accompanying EHR systems, and in the advertising of EHR systems, it shall be prohibited to use text, names, trademarks, pictures and figurative or other signs that may mislead the professional user […] with regard to their intended purpose, interoperability and security by:

• (a) ascribing functions and properties to the EHR system which it does not have;
• (b) failing to inform the professional user of likely limitations related to interoperability or security features of the EHR system in relation to its intended purpose;
• (c) suggesting uses for the EHR system other than those stated to form part of the intended purpose in the technical documentation.“

This page is the record of those reviews: what was read, what was found, what was changed. It also carries the re-assessment of EHDS Annex II 2.5. The measure for point (c) is the intended-purpose statement.

• What is reviewed, and how
• The review of 2026-10-06
  • Changed
  • Read and kept
  • Left open
• The review of 2026-10-08
  • Changed on 2026-10-08
  • Read and kept on 2026-10-08
  • Left open on 2026-10-08
• Annex II 2.5, re-assessed
• Review record

Warning

The quotations are from the Official Journal text vendored at docs/law/eu/ehds/text.html (EUR-Lex). Art. 28 takes “professional user” from Article 3, point (8), of Regulation (EU) 2018/1807, which the repository does not carry, so these pages do not restate that definition. A text that passes this review has been read against Art. 28 by the manufacturer; no authority has examined it.

What is reviewed, and how

The texts in scope, each release:

• the repository README.md and the landing page at ferroehr.eu;
• every page of this book, except the pages generated from the tracker and from committed measurement records, whose generators are reviewed instead;
• SECURITY.md;
• the READMEs of the published openehr-* crates;
• the OCI labels of the three images (docker/Dockerfile, docker/viewer/Dockerfile, docker/postgres/Dockerfile) and the Helm chart’s description;
• the public sandbox at sandbox.ferroehr.eu.

Each claim about a function, a property, interoperability or security is checked against the code, the configuration defaults and the committed records, and against the intended-purpose statement. A misleading claim is fixed in the same change as the review. Measured numbers are never typed into a text: the conformance and performance figures come from generators over the committed run records, and a CI check fails a page whose numbers disagree with them.

The review of 2026-10-06

Read on the tree after commit d6539d470, before FerroEHR 4.3.5.

Changed

Read and kept

• The conformance and performance figures on the README, the landing page and the book: rendered from docs/conformance/ferroehr/ by scripts/render/conformance-stats.sh and scripts/render/perf-assets.sh, and checked in CI. No number is typed.
• “openEHR-spec-conformant”, on the Conformance page, in the openehr-* crate READMEs, in the org.opencontainers.image.description label of the server image and in the Helm chart description: a claim about the openEHR specifications, backed by the committed record (CORE and STANDARD, every case passed) and explained on that page. It makes no claim about any regulation.
• “aims to be the first openly developed, source-available openEHR CDR with a published, tracker-backed EU compliance posture” (the compliance overview, Why FerroEHR exists, Comparison): stated as an aim, beside the statement that FerroEHR holds no certification and no declaration.
• The compliance pages, the DPIA and the go-live checklist: each says it does not make a deployment compliant with anything.
• The image labels: the server image carries eu.ferroehr.image.carries-sandbox-posture="true", which tells an operator the shipped profile; the manufacturer label names Cadasto B.V.
• SECURITY.md: its commitments match the procedures in docs/post-market.md and the release procedure.
• The public sandbox: the viewer shows the sandbox notice on every page, the README calls its content demo data, wiped nightly, and the landing page calls it a live demo.

Left open

• The Helm chart’s description (Chart.yaml, and the chart README that helm-docs generates from it) says “hardened-by-default security posture” and lists the workload hardening, which is accurate, but does not say that a stock install runs the sandbox profile. The chart now declares config.deployment_profile: sandbox in its values, and the chart README says so under “Before you install”; the Chart.yaml description still does not.

The review of 2026-10-08

Read on the tree after commit de648fcc3, for FerroEHR 4.3.6. This release removes the in-tree FHIR connector (#3080) and moves the deployment gaps off the public status document (#3671), so those two facts were checked in every text in scope.

Changed on 2026-10-08

Read and kept on 2026-10-08

• The README’s integration list and the book’s Beyond the core: both state that FHIR R4 mapping is FerroBRIDGE’s and name the two uses of FHIR FerroEHR keeps.
• Single tenancy: the README, the landing page and the book state one instance per organisation; “multi-tenant” appears only where the book quotes openEHR’s placement of multi-tenancy outside one system.
• The Helm chart’s description: it now says a stock install runs the sandbox profile (#3637), which closes the item left open on 2026-10-06.

Left open on 2026-10-08

Nothing.

Annex II 2.5, re-assessed

EHDS Annex II 2.5: “The harmonised software components of an EHR system shall not include features that prohibit, restrict or place an undue burden on authorised access, personal electronic health data sharing or use of personal electronic health data for permitted purposes.” The text does not define “undue”.

The EHDS readiness page marks the row “Shipped” with two pieces of evidence: the query surface over the whole stored record, and an authorisation layer that refuses or permits without a commercial gate. The question re-assessed here is whether the authorisation defaults change that, now that production refuses the open EHR_ACCESS default unless it is accepted by name.

• What “authorised” means here. The deploying organisation decides who is authorised, and expresses it in RBAC roles, ABAC policy and per-EHR EHR_ACCESS settings. A refusal of a caller the organisation has not authorised is not a burden on authorised access.
• The restricted default. Under ehr_access_default = "restricted", an EHR with no settings is reachable only by the admin role, so a professional the organisation means to authorise is refused until someone writes that EHR’s settings. That is a burden, and it is the organisation’s choice: the open default remains available, production accepts it by name, and the restrictive one exists because GDPR Art. 25(2) asks that personal data are not by default “made accessible without the individual’s intervention to an indefinite number of natural persons”. The settings take role entries (role:nurse), so one entry covers a whole role, and the admin role can always reach the record to write them (per-EHR access control).
• Restriction of processing. A record under restriction is refused on every read path. The controller sets the mark under GDPR Art. 18; it is a restriction the organisation decides on, not one the software imposes (retention, restriction and objection).
• Small-cell suppression. A cohort query that would serve fewer distinct EHRs than cohort.small_cell_threshold (default 5) withholds its rows and says so. It applies only to population queries across the pseudonymisation boundary, and the deployment sets the threshold.
• Rate limits and the admission limit. On by default, set above the server’s own measured whole-server ceiling, so they refuse abuse and leave normal load alone (request limits).
• The licence. The licence in force changes only the stamp on new identifiers; it gates no feature, endpoint, limit or message (app/ferroehr/src/licence/mod.rs).

Outcome. No feature found prohibits or restricts access, sharing or use that the deploying organisation has authorised, and the burdens found are settings the organisation chooses and can change. The “Shipped” status stands on this reasoning, which the readiness page will cite.

Review record

One row per release. The release procedure adds the row when the release is cut, after the texts in scope have been read.