Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

What FerroFED claims

FerroFED claims what a release ships and a test holds. This page lists the standing decisions and what each release shipped, and the limitations to know before you deploy it. The changelog has the detail of every change.

Decided

The architecture of record was decided on 2026-10-01 and is docs/architecture.md. These decisions hold across every release:

  • The specification is the authority. The Federation Tier with AQL text decides; its reference implementation is read as evidence, never as an oracle. Where the specification is silent, the decision is FerroFED’s own and is labelled that way in the code and in this book.
  • The openEHR surface comes from the published openehr-* crates. The ITS-REST contract, the AQL parser and printer, the RM and the typed identifiers are those crates. A gap in one of them is fixed in that crate.
  • No clinical data of its own. The gateway holds the registry, the ehr_id index and the stored-query definitions it is authoritative for. The record stays on the nodes.
  • Identifier hygiene is a hard rule. Nothing the gateway composes for a node carries a directly identifying patient identifier, and every carrier the specification names has a negative test (§5.4, N33).
  • Pure Rust, a single binary, as across the FerroHEALTH family.

Shipped

v0.0.3: the federated query and identity resolution

  • POST {base}/v1/query/aql answers one ITS-REST RESULT_SET over every member of a registry, with no federation syntax needed (N1, CP-1).
  • The patient is resolved outside AQL through an IHE PIXm PIX Manager (ITI-83) on either patient-identifier carrier, and each member that knows the patient receives standard AQL keyed on its own ehr_id (§5, §7.1, N7).
  • The rewrite refuses a query that would carry the identifier to a node, and an outbound gate checks every request again before it leaves (§5.4, CP-26).

v0.0.6: the federated answer, routing and targeting

v0.0.6 carries the milestones v0.0.4, v0.0.5 and v0.0.6; no v0.0.4 or v0.0.5 was tagged.

  • The full per-endpoint report in meta.federation, all-or-nothing completeness with the best-effort opt-in, the per-node and overall budgets with Prefer: wait, and the §11.2 statuses with stable error codes (§9.5, §11.1 to §11.5).
  • ORDER BY with LIMIT re-applied at the Tier, bounded OFFSET pages, SELECT DISTINCT, recombined COUNT, SUM, MIN, MAX and AVG, and opt-in version-identity de-duplication (§10, §11.6).
  • Routing of the EHR resources under a path ehr_id to the one node that holds the EHR, byte for byte, through the targeting headers, the ehr_id index and the ask-all probe; the creating_system_id map learned from every answer (§7a.1, §12.2, §12.5).
  • The FROM ENDPOINT and ORGANISATION directive, the targeting headers, and ENDPOINT attributes in rows (§8, §9.3).
  • The registry document in FHIR form, OPTIONS {base}/, and the stored-query registry with immutable versions invoked by name (N19, §7a.2, §12.7).
  • Track 10, the identifier-leakage suite, run against two FerroEHR nodes.

v0.0.7: definitions and membership

Released on 2026-10-03.

  • Definition requests routed to one named node, the opt-in fan-out template upload, and stored-query distribution with drift reporting and an operator’s repair (§12.6, §12.7, N43, N44).
  • Versioned writes, CONTRIBUTIONs included, sent only to the CDR that controls the version; a new EHR created only at a named node; ehr_id collisions refused and raised as integrity incidents (§12.4, §12.5.2, §12a.1, N23, N42).
  • GET {base}/v1/ehr by subject, the GET forms of query execution, both ehr_id forms of N29, the provenance headers, a configurable base path, and the DEMOGRAPHIC area routed to one declared endpoint (§4.1, §7a.3, N28, N29, N31, N32).
  • ferrofed admission check for the identifier-integrity conditions of §12b.2 (N42a), the registry reload on SIGHUP, the stored-query registry on redb, PostgreSQL or read-only files, health probes, and metrics.

v0.0.8: security and the bindings

Released on 2026-10-04. It carries §13 to §15, Annex A and Annex B.

  • Client authentication at the gateway: RFC 9068 access tokens checked by key set or by introspection, SMART on openEHR scopes per route, the purpose of use, and an explicit edge mode for a proxy that authenticates callers (§13.1, N25, CP-17; #80, Client authentication).
  • OAuth 2.0 client credentials to each node with an RFC 7523 assertion signed ES384, the node tokens cached, and the gateway’s JWK Set published at {base}/.well-known/jwks.json (§13.1, N25, N30, CP-17; #81).
  • RFC 8693 token exchange per endpoint, which gives each verified caller a token of its own at a node, and node tokens bound to a key of the gateway’s with DPoP (RFC 9449), the proof written and a node’s nonce answered by the openehr-its 0.0.87 client (#439, #448, Onward credentials).
  • The two authentication tracks of the Dutch binding as onward credentials: the Nuts grant, a Verifiable Presentation of the gateway’s credentials for a DPoP-bound token (Annex B §B.4, Nuts RFC021), and the FAPI 2.0 grant of the BgZ/eOverdracht track: client credentials or token exchange with a private_key_jwt assertion, DPoP-bound tokens, and the healthcare attributes in an RFC 9396 authorization_details object (Annex B §B.4a) (#88, #497, The Nuts grant, The FAPI 2.0 grant).
  • A patient/ grant honoured only for an issuer the deployment binds to one member: the token’s ehrId resolved through the cross-reference at every member (§5.2), every request held to the patient’s own {node, ehr_id} pairs with nothing sent beyond them, and each node told the patient’s ehr_id there; a bare ehrId is never compared across members (§12.5, N26; #443, Patient grants).
  • The caller’s identity conveyed on every request to a node, in a token the gateway signs for that node and a node verifies against the published JWK Set (§13.1, N24, CP-16; #82, What a node is told about the caller).
  • Consent left to the node, with the optional Step-1 pre-filter on every patient route, the read of an EHR by subject included, its outage carried in meta.federation, on the health report and in the metrics, and a node’s own refusal reported as consent-denied (§13.2, N27, N27a; #83, #399, #400).
  • Mitz as that pre-filter in the Netherlands: the closed authorization question asked once per data holder, a member Mitz denies reported consent-denied and never asked (Annex B §B.6, N27a; #475, Dutch consent).
  • The §13.4 deployment decisions, answered for the gateway, with an operator’s template for the rest (CP-39; #84, The §13.4 deployment decisions).
  • Undirected patient queries localized by IHE XCPD ITI-55 or by the PIXm resolver, which shares one ITI-83 answer between localization and resolution. A member no localizer names is not-localized and never asked, and a localizer that does not answer fails closed, with its error on every member and in meta.federation. The read of an EHR by subject is localized too, the localizer is on the health report and in the metrics, and every XCPD exchange is audited to a log target (N4, N10, §14.1, §14.2, Annex A.3, CP-5; #85, #408, #409, #410).
  • NVI localization in the Netherlands: an undirected patient query asks the national index which care providers hold data for the patient’s pseudonym, and the members that hold those providers’ data are the candidates, with the custodian map read from the URAs a care services directory with the LRZa as its source publishes (Annex B §B.1, §B.2; #87, Dutch localization).
  • A PDQm step ahead of localization and resolution, for a patient named by an identifier the cross-reference does not know: the Patient Demographics Supplier is asked with ITI-78 or ITI-119 for the patient’s identifier in the master domain, and an ambiguous match is never picked (Annex A §A.2, §A.7; #487, Demographics first).
  • The XCPD audit sent to an ATNA Audit Record Repository with ITI-20: the DICOM PS3.15 audit message in RFC 5424 syslog over TLS, stored in a bounded spool on disk first and delivered from it, so a repository outage fails no discovery and a full spool fails it closed (ITI TF-2 §3.20, §3.55.5.1.1; #418, #512, The audit repository).
  • Every other IHE transaction the gateway makes or receives audited as its profile requires: ITI-83, ITI-78, ITI-119, ITI-90, ITI-91, ITI-93 and ITI-94, each as a FHIR AuditEvent on the IHE Basic Audit Log Patterns (BALP), sent to the repository with the FHIR Feed of ITI-20 through the same spool, and a transaction whose record cannot be stored failed (#486, #469, The audit trail).
  • The registry read from an IHE mCSD care services directory with ITI-90 and kept in step with ITI-91, a shared directory included, with in-scope deletions recorded in the replica so a dangling listing is judged the same at a start and on a refresh, and a deleted endpoint dropped (§15.1, §15.2, N21, Annex A.5; #86, #423, #433).
  • The §12.5.1 resolution bindings kept per verified caller (N41; #412).
  • The identity lifecycle over IHE PMIR: an ITI-94 subscription at a Patient Identity Registry, and an authenticated ITI-93 feed whose merges and deletes drop the resolution bindings they could have made stale; track 8 stays deferred, since the specification marks it provisional (Annex A.4; #147, The identity feed).
  • A credential or a patient identifier sent only over https outside the development profile, and the stored-query store’s PostgreSQL password only over TLS (#402, #416).
  • A Kubernetes example that starts, checked in CI (#428).
  • Traces exported through OpenTelemetry over OTLP, with a sample ratio and a traceparent of the gateway’s own trace on every node request; nothing of a client’s trace context is recorded, so no client-chosen trace id reaches the collector (#353, #437, #446, Tracing).
  • The texts this work cites, vendored with their provenance: the SMART on openEHR source and the IHE IUA supplement (#414), PMIR, BALP, the Dutch Generic Functions IG, the Nuts specifications, and the country research corpora (#498). The Mitz documents state no licence, so they are pinned by digest and fetched into a local cache, never committed (#501).
  • One client build and one TLS type for every outbound identity client, one credential mapping per credentials section, and mutual TLS toward the PIX Manager, the PDQm Supplier, the PMIR Registry and the mCSD directory (#507).
  • An audit record still queued behind another spool write when its exchange’s time runs out is written once that write ends, and delivered in the order it was queued (#532).

v0.0.9: conformance and the operator console

Released on 2026-10-05. It carries §16 and §17.

  • Every conformance point of §17 scored by a marked test, or deferred by a recorded decision with its actor and reason, and the conformance statement that claims the Federation-Gateway profile from that matrix (#89, #95).
  • The Connectathon tracks 1 to 7 and 9 to 11 of §16.3 as runnable scenarios against two FerroEHR nodes, with node-side wire capture for track 10 and a per-track and per-point report (§16.4; #90, #91, #92).
  • The Federation-Node profile of §16.2 checked against FerroEHR and EHRbase (#93, #549).
  • A differential run against the reference implementation, each difference judged against the specification text (#94).
  • ferrofed conformance run, which scores your own deployment (#546, #573, Scoring a deployment).
  • The operator console’s skeleton and its operator views, over a read-only operator surface on the gateway (#275, #276, The operator console).
  • The console’s query console, signing out, and its browser journeys in CI (#274, #277, #584, #608).
  • Each regional binding one module behind one feature, binding-ihe and binding-nl, wired through one Binding trait, with the RFC 8414 checks from the family’s ferrohealth-smart (#489, #551, #1342).
  • Mutual TLS to a node with RFC 8705 client authentication and certificate-bound tokens, with a token endpoint alias accepted on a host the operator names (#492, #560, Mutual TLS to a node).
  • An ES256 [signing] key beside ES384, a FAPI 2.0 client key rotated with an overlap, the Nuts grant toward the NVI, and the gateway’s did:web DID document (#513, #514, #539, #503).
  • A deployment setting that keeps a consent exclusion out of the answer, and a pre-filter that says it did not ask, with a closed reason (N27a; #493, #496, #568, Consent exclusions).
  • PIXm ITI-83 sent as POST, so the patient identifier stays out of the request URL, and the verified caller named as the user agent of each IHE audit record (#494, #500).
  • FerroFED’s intended purpose and its classification as an EHR system under the EHDS Regulation (#520, Regulatory status).

v0.0.10: EHDS readiness and the production gaps

Released on 2026-10-15. It implements the 1.0.0 release of the specification (#17).

  • Every access to patient data recorded with the verified caller, the professional, the assurance level the issuer states, the client’s address behind a trusted proxy, the categories of the data per origin and the period the record is kept, as Annex II, point 3.2, of Regulation (EU) 2025/327 asks of the European logging component, and ehds-logging as a library, published from the FerroHEALTH audit library (FerroAUDIT) (#623, #742, #722, #694, #795, The access log).
  • The FHIR face: the patient summary in the HL7 Europe exchange format, the document list and the read of a listed document, and the receipt of a patient summary document into the member you declare for it, with the published eehrxf crate as a library (#809, #810, #802, #803, The patient summary over FHIR, Receiving a document).
  • The information sheet, the instructions for use, the clinical safety risk file, this page’s claims review, and the post-market and Cyber Resilience Act procedures, with security fixes published for five years after each release, only in the newest release (#670, #673, #674, #672, #762, #763).
  • Identity resolution in production through a PIX Manager the members feed (#622, Identity resolution).
  • Restarts with no dropped request, several replicas, inbound metrics behind an authenticated admin listener, overload protection and TLS on the listeners (#625, #626, #627, #629, #635, #631, #632).
  • The production, upgrade, data-protection, threat-model, hardening and troubleshooting pages (#624, #630, #633, #634, #640, A production deployment).

v0.0.11: prescriptions, configuration revisions and the console

Released on 2026-10-16.

  • Electronic prescriptions and dispensations on the FHIR face, in the HL7 Europe MPD profiles, passed through from the members that serve them: the search and the read of a patient’s prescriptions, and a received dispensation written to the member that owns its prescription and read back, with no dispensability, count or lock computed at the gateway (FerroHEALTH/FerroBRIDGE#1321, Prescriptions and dispensations over FHIR).
  • A received document written under a person’s own grant, or under a representative’s, marked as theirs in every entry and in its access record, and a person’s own patient summary through an electronic health data access service (#992, #1003, #991).
  • Access records that carry a security label per category and origin, name the patients a population query read up to a bound, name the version a write and the EHR a create left at the member, and log each semantic transformation the FHIR face applies (#797, #819, #946, #983, #985, Labelling the access records).
  • The export of the routing state a gateway learned, for a system that replaces it (Annex II, point 2.6; #798, Exporting the identity state).
  • Configuration as versioned revisions under config.ui = "managed": saved, compared, applied, confirmed and rolled back on the admin listener and from the operator console, exported and imported as TOML, and followed by every replica on the store; [auth] and the listener certificates reload without a restart (#576, #577, #578, #579, #954, #636, Configuration revisions).
  • The operator console redesigned, with a dashboard, a page per member, the routing table, the stored queries by namespace, the query console as an editor and a results card, the configuration in tabs, a light and a dark theme, and the operator’s two admin actions (#1074, #909, The operator console).
  • The Annex II checklist, the technical documentation with its Annex III index, the EU declaration of conformity written for each release once the manufacturer issues it, the register of economic operators, the rights of natural persons, the cybersecurity risk assessment, the CRA information to the user, the decommissioning page, and security fixes as patch releases of the newest release (#941, #671, #940, #787, #961, #1058, #1059, #1063, #1064, Annex II checklist, Technical documentation).
  • The openehr-* crates at 0.0.87 with FHIRconnect 0.1.117 on the same release (#714).

v0.0.12: the console rebuilt on FerroUI, and every finding judged

Released on 2026-10-24.

  • The operator console rebuilt on FerroUI 0.3.6 as ferrofed-console, its own image ghcr.io/ferrohealth/ferrofed-console: every page drawn on the server from FerroUI’s components and every action a form post that works with no WebAssembly, the pages of FerroUI’s reviewed FerroFED design, and every word from a catalog, English the one language that ships (#1219, #1230, #1233, #1162, The operator console).
  • Client authentication, the SMART on openEHR grants and the gateway’s own OAuth 2.0 clients on ferrohealth-smart, the resource-server crate the FerroHEALTH products share, with every static bearer token removed: a machine authenticates with HTTP Basic or the client credentials grant (#1174, #1163, #1186, Client authentication).
  • The audit trail and the access record from the published FerroAUDIT crates, and the identity crates from FerroPIX, with what the gateway records unchanged (#1177, #1211, #367).
  • The patient summary’s term-mapping rule: a mapping that is no equivalence is written into the section’s narrative and never as a coding (#926).
  • Each release scanned in full, its images and binaries at every severity, and refused while a finding has no OpenVEX statement that judges it; each image scanned before it is tagged, and the published images every week (#1238).
  • A Security section that names each fix’s advisory and, beside other changes, says why the fix did not ship alone (#1237).

v0.0.13: the national contact point, and full validation of a received document

Released on 2026-10-25.

  • A national contact point’s national connector served on the FHIR face: it reads the patient summary, the document list and the prescriptions and posts a dispensation, held by an end-to-end test over two FerroEHR nodes with a harness connector, and a restricting member leaves no trace in any answer (#524, #735, A national contact point). Decisions A67 to A72 re-checked against the Xt-EHR deliverables and the public MyHealth@EU material, vendored with its provenance (#1265, #1290, #1306).
  • A patient looked up by identifier on the FHIR face, resolved at the gateway with no member asked, and recorded in the access log when it finds the patient (#1294).
  • A received document validated in full by FerroBRIDGE’s ferrobridge-validator: every invariant, binding and entry profile, with each constraint it did not evaluate named in the outcome (#808, #1291, Receiving a document).
  • A summary code in no preferred code system translated through the configured terminology server, asked through FerroBRIDGE’s ferrobridge-term (#1213, #925).
  • A read by locator id held to the consent pre-filter, a document list that asked no member recorded as an access, and an ITI-20 record no longer lost when the gateway ends its repository connection (#1270, #1271, #1278).
  • The Kubernetes package, with the gateway and console images pinned by digest; the OTLP export over TLS; the 95th percentile latency beside the median; the running configuration on the admin listener with the console’s settings and Authentication tabs; and the operator console in the release’s compose file (#638, #644, #1220, #1235, #1269, #1258, The Kubernetes package).

v0.0.14: no patient index, and the safety controls of the clinical review

Released on 2026-10-28.

  • No patient index in any profile: the static development cross-reference [dev] is refused at load, every patient resolves through a PIX Manager, and the quickstart runs FerroPIX seeded over ITI-104 (#1377).
  • The patient summary’s safety controls from the clinical review: a probable duplicate medicine across members marked in the narrative, the medical alert and functional status sections written as unavailable, the medication order selected for the medication summary, and a composition that holds a mapped archetype twice left out and named rather than merged (#1343, #1344, #1350).
  • A received dispensation checked against the owner’s dispensations by its business identifier before it is written (#1346).
  • A CONTRIBUTION in XML answered 415 before it is routed, as a node answers it (#1391).
  • Consent before release (CP-19) observed at FerroEHR on a restriction of processing the harness sets, and honoured by the federated query (#1389).
  • The family crates on ferrohealth-smart 0.8, with a Basic credential cached for five minutes and each access record’s labels on its entities (#1390).

v0.0.15: the family’s server crates, and the MyHealth@EU catalogue

Released on 2026-10-30.

  • The listeners, their TLS and drain, the configuration loader, the health routes, the secrets, the request log, the telemetry export, the panic line and the installation report taken from the FerroHEALTH family’s shared crates, with FerroFED’s own copies deleted: TLS 1.3 by default, a client certificate asked under an explicit client_auth, --set on every subcommand, a liveness route of its own, one OTLP collector for spans and metrics, and responses compressed for a client that accepts it (#1397, #1408, #1418, #1421, #1448, #1453).
  • Every error outside the FHIR face an RFC 9457 problem details document, and a member’s problem details refusal reported by its detail (#1412, #1413).
  • The operator console hydrates the whole page on FerroUI 0.5 and runs on the same shared crates; every page still reads and every action still posts with no WebAssembly (#1397, #1414, #1445).
  • FerroFED’s reading of the MyHealth@EU Requirements Catalogue v10.0.0, a self-assessment and no MyHealth@EU compliance check, with the gateway’s changes it found: the missing Annex attributes of a contact point’s token named, a member’s own refusal of a dispensation relayed, and an imported copy of a composition listed once in the patient summary (#1423, #1424, #1426, #1427, #1428, MyHealth@EU self-assessment).
  • The interoperability component taken as the published eehrxf from FerroBRIDGE, and the access record of a routed openEHR read or write naming its object as what.identifier (#813, #1416).

v0.0.16: laboratory reports, prescriptions from openEHR, and Federation Tier 1.0.1

Released on 2026-11-05.

  • The laboratory report, Art 14(1)(e), on the FHIR face: received at a [[fhir.receive]] member as an HL7 Europe Laboratory Report 2.0.0 document, written from a member’s laboratory composition as a Bundle-eu-lab and listed, and a member’s own reports, served as an EU Health Data API Document Access Provider, passed through the document list with only their attachment URL readdressed to the gateway’s (#1432, #1555, #1556, #1404).
  • Prescriptions served and dispensations written in the map mode, from a member’s openEHR medication orders through FerroBRIDGE’s MPD project, and a received dispensation withdrawn as entered-in-error (#1559, #1560, #1561, #1468, #1450).
  • The Federation Tier with AQL 1.0.1: an EHR-scoped version request that names no node reaches the member that created the version (#1478).
  • The patient summary’s medication entries selected by the template section that holds them (#1551).
  • The operator console drawn whole on its server with FerroUI 0.6, with no WebAssembly and a Content-Security-Policy of its own origin alone, signing in through the family’s ferrohealth-session, with a session watch (#1457, #1465, #1504, #1505, #1512).
  • The [server] keys 0.0.15 still read under their old names refused, as any unknown key (#1490).

v0.0.18: discharge and imaging reports, and the national contact point

Released on 2026-11-10. v0.0.17 was tagged and never released, so v0.0.18 ships what it holds.

  • The discharge report, Art 14(1)(f), and the medical imaging report, Art 14(1)(d), on the FHIR face: written from a member’s composition as an HL7 Europe Hospital Discharge Report and Imaging Report and listed, a member’s own passed through the document list with only their attachment URL readdressed, and the discharge report received at a [[fhir.receive]] member (#1405, #1406, #1714, #1777).
  • A national contact point held to the MyHealth@EU profile: its token bound to the connector’s certificate and checked by ferrohealth-smart’s eHDSI validator, each patient-data request held to the patient of its treatment relationship confirmation on both faces, the emergency access limit of eHDSI Section II §2.5 counted across replicas, a dispensation and its discard under the catalogue’s rules, and every refusal naming its catalogue exception code (#1620, #1622, #1623, #1631, #1632, #1633, #1640).
  • FerroFED’s own PostgreSQL store, [store], for the state every replica shares: the stored queries, the emergency counts, the DPoP proofs and a contact point’s dispensations (#1636, #1637).
  • Every issuer an [[auth.issuer]] of its own kind on ferrohealth-smart 0.13.0, no Basic caller, and each node request a caller originates sent under a token exchanged for that caller (#1682, #1703, #1704, #1705, #1749).
  • Every outbound client on the family’s TlsClient, at TLS 1.3 unless its tls sub-table lowers it (#1750, #1766).

v0.0.19: imaging reports received, and what a report loses declared

Released on 2026-11-11.

  • The medical imaging report, Art 14(1)(d), received at a [[fhir.receive]] member over the HL7 Europe Imaging Report package closure, validated in full and written at its member (#1716).
  • Each received category compiled with the declarations of the project eehrxf ships for it, so what a received report loses is relayed to the sender as not carried, and a written report names what its mapping declared it left out; a written report names its member the custodian (#1785, #1826, #1827, #1838).
  • Every outbound service, the identity and Dutch service clients included, configured with one endpoint table: its address, TLS, timeouts and credential (#1805, #1806, #1815).
  • The family crates on ferrohealth-smart 0.18, with a password in the userinfo of any configured URL masked in every rendering of the configuration, and the quickstart on FerroPIX 0.0.26 under client credentials tokens, published as a self-contained compose.yaml (#1825, #1838, #1849).

v0.0.20: FerroEHR nodes reached under the caller

Released on 2026-11-12.

  • A FerroEHR 5.7.0 node reached under the caller, through an onward lane of kind persons on each of its endpoints, in the quickstart, the end-to-end harness and the release compose example; no quickstart node is reached under a Basic user (#1615).
  • The professional, the organisation and the purposes of use a caller’s token states read only through its issuer’s [[auth.attributes]] or [[auth.federation]] table, by ferrohealth-smart (#1615, #1704).
  • A received imaging report’s performing organization carried into the member’s structured record, and a performer that is no organization declared to the sender as not carried (#1860).
  • The family crates on ferrohealth-smart 0.19, with the issuer of every [auth] table masked in every rendering of the configuration, and the quickstart on FerroPIX 0.0.29 (#1864, #1474).

Limitations

Regulation (EU) 2025/327 Art 28(b) forbids “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”. These are the ones to know before you deploy FerroFED; the claims review records how this list is kept.

  • The specification is release 1.0.1. FerroFED implements the 1.0.1 release of the Federation Tier with AQL, the erratum of 2026-11-01 to the 1.0.0 release the openEHR SEC approved on 2026-10-12, and reports spec_version "1.0" in OPTIONS {base}/, since a patch release keeps the wire contract (§7a.2). Upstream has not tagged 1.0.1, so the vendored text is its untagged release commit (#1478). Releases up to v0.0.15 implement 1.0.0, and releases up to v0.0.9 the 0.9.0 release candidate, which report "0.9"; v0.0.10 re-pinned it (#17).
  • No EHDS harmonised component is complete. The gateway records every access to patient data as Annex II, point 3.2, asks of the European logging software component (Art 25(1)), read at your Audit Record Repository with ITI-81 (point 3.3), each record stating its retention by origin and category (point 3.4). A query over many patients’ data names the patients its delivered rows project by ehr_id, up to a bound, and otherwise records only its scope, which shows a person that a query ran over a member holding their EHR, never that it read their record. Each record carries a security label per category and per origin, which your repository applies as access rights (Labelling the access records). The European interoperability software component writes the patient summary and receives a document in the exchange format on the gateway’s FHIR face, and passes prescriptions and dispensations through from the members that serve them in the HL7 Europe MPD profiles on their own FHIR endpoint, or maps them from a member’s openEHR medication data in the map mode (Prescriptions and dispensations over FHIR). It lists, reads and receives laboratory reports (Laboratory reports over FHIR), with hazard I-16 of the clinical safety risk file open and I-18 closed at S4, P1. It lists and reads discharge and imaging reports and receives both (Discharge reports over FHIR, Imaging reports over FHIR), with hazards I-19 and I-20 closed at S4, P1 (#1826) and I-21 and I-22 open at S4, P3 (#1794, #1716). No EU declaration of conformity has been drawn up, and no release carries the CE marking (Regulatory status).
  • The access records are kept by your Audit Record Repository. Every federated query, stored-query execution, routed read and routed write that reaches a node, a query from the operator console included, is recorded with the verified caller and the patient, and an access whose record cannot be stored is refused 503 access-unrecorded, a write before any member is asked (The access log). The gateway keeps no copy, so who reads the records is the repository’s, and it keeps each for the period the record states from [access_log.retention], at least three years (How long a record is kept). FerroFED ships no category map: until you declare one in [access_log], the categories of the data an access reached are recorded ehds-unclassified. The record names the professional the token names, and the assurance level when the issuer declares one (The person behind an access). An access whose token declares a purpose of use you name in [[access_log.emergency_purpose]] is marked an emergency access (Art 11(5)); FerroFED names none, and the mark records what the caller asserted, never whether restricted data were released, which the node decides (Emergency access).
  • The assurance level is yours to set. Patient data needs a natural person behind the token, or a client application you declare to act for the professional its token names; any other token is refused 401 natural-person-required. The gateway reads and requires an assurance level only for an issuer with [auth.issuer.assurance], and config check names each issuer without one (Professionals and assurance). Your issuer authenticates the person; the gateway verifies the token.
  • Consent exclusions are shown by default. A member a consent pre-filter excludes is reported consent-denied, as the specification requires (N27a). Art 8 of the Regulation forbids showing that restriction to a healthcare provider, so a deployment in the EU sets [federation.consent] disclose = false (Withholding consent exclusions). A node’s own consent refusal fails the query 424 until you list the codes that node uses (Consent).
  • One silent member fails the query. A federated query is all-or-nothing by default (N37): when a member that was asked does not answer, the client gets no rows. A client that accepts a partial answer asks for one per request (Queries and API areas).
  • A write body travels as the client sent it. The gateway keeps the patient identifier out of every request it composes for a node, but a committed COMPOSITION reaches its node byte for byte, a DV_IDENTIFIER inside it included (§5.4, N22; Where the patient identifier stops).
  • A received document is checked only as far as the validator can evaluate it. A constraint ferrobridge-validator cannot evaluate is listed in the outcome of the write as a warning, not refused, and a required binding the packages cannot decide is listed as not evaluated when no terminology server is configured (The check against the profiles).
  • Part of ITS-REST is not served. The gateway never federates the DEMOGRAPHIC area: it answers 501 there unless you name one member to serve it, and 501 for any ITS-REST path it does not serve (The DEMOGRAPHIC area).
  • The listener speaks plain HTTP by default. Terminate TLS in front of the gateway, or set [server.tls], with a client CA to admit only your proxy, when the hop from the proxy to the gateway crosses a network others share (TLS on the listeners).
  • Members in several Member States are not detected. FerroFED neither detects nor refuses a federation whose members sit in different Member States (Regulatory status).

Not claimed

FerroFED claims a conformance point only when a test carries its marker and CI runs it. The conformance statement is that claim for the Federation-Gateway profile, with every deferral and its reason. The conformance matrix records where each point stands, and the obligations checklist does the same for every normative statement of the specification. Both are held to the 1.0.1 release, to which the vendored text was re-pinned from 1.0.0 (#1478), itself re-pinned from the 0.9.0 release candidate (#17).