Introduction

FerroFED is a pure-Rust openEHR federation gateway, one of the FerroHEALTH family. It sits in front of several openEHR CDRs as a transparent ITS-REST intermediary. A client sends it an ordinary AQL query with no federation syntax, and gets back an ordinary ITS-REST result set whose meta.federation names each node with its status. The gateway resolves the patient first, outside the query, through an identifier cross-reference service. It then sends each node standard AQL scoped to that node’s own ehr_id, so no request the gateway composes for a node carries a directly identifying patient identifier, and it merges the answers with each node’s provenance. It holds no clinical data of its own.

FerroFED implements the openEHR Federation Working Group’s Federation Tier with AQL specification, release 1.0.1, and reaches every node over openEHR ITS-REST 1.1.0.

This book covers FerroFED alone. What every FerroHEALTH product shares is in the family book: how the products fit together, the manufacturer, Cadasto B.V., with its security policy and the Cyber Resilience Act from the manufacturer’s side, and licensing and trademarks.

See how it works: the gateway in diagrams.

What it does today

The latest release ships the ferrofed binary for Linux and the image ghcr.io/ferrohealth/ferrofed, both signed, and a compose.yaml that runs the gateway alone in front of your own CDRs (The gateway from a release). The quickstart runs it beside four member CDRs. This book describes the gateway as it is built on main, and the changelog says which release first shipped each part. Over the members of a registry, the gateway:

• answers the federated query, POST {base}/v1/query/aql and its GET form, with one ITS-REST RESULT_SET and a meta.federation report that names every member with its status;
• resolves the patient through an IHE PIXm PIX Manager (ITI-83), after an IHE PDQm query (ITI-78 or ITI-119) where the client names the patient by an identifier the cross-reference does not know, and refuses any query that would carry the patient identifier to a node;
• can ask only the members that may hold the patient, localized through IHE XCPD (ITI-55), the Dutch NVI or the PIX Manager, can leave out the members a consent pre-filter such as the Dutch Mitz denies, and can read its members from an IHE mCSD care services directory;
• authenticates to each node as itself, with an OAuth 2.0 token, by client credentials or token exchange and optionally bound with DPoP, a token of the Dutch Nuts or FAPI 2.0 track, or a static credential, and tells each node who is asking in a token it signs for that node;
• audits every IHE transaction it makes or receives to an ATNA Audit Record Repository;
• fails a query when a node it asked does not answer, unless you ask for a partial answer, and shapes the merged rows as one CDR would: ORDER BY with LIMIT, bounded OFFSET pages, DISTINCT, recombined aggregates and opt-in de-duplication of copied versions;
• lets you direct a query at named nodes, in the AQL or in a header;
• routes the EHR resources under a path ehr_id to the one node that holds that EHR, and a versioned write only to the CDR that controls the version;
• sends a template or another definition request to the node you name, and can fan a template upload out to several;
• holds stored queries itself, as immutable versions it runs by name, and can distribute them to the members;
• describes itself at OPTIONS {base}/;
• gives you, the operator, a check to run before you admit a node, a registry reload on SIGHUP, health probes, metrics for Prometheus or an OpenTelemetry collector, and traces over OTLP.

Every client authenticates with an access token from an issuer you trust (Client authentication). Each page says what is built, and the claims page lists the limitations to know before you deploy it.

How this book is organised

The four parts follow what you came to do.

• Evaluate: whether FerroFED fits your problem. How the gateway works, one question per page, what the Federation Tier is, what FerroFED claims, the conformance matrix and the obligations checklist, the version pins and the licence.
• Integrate: what a client sends and what it gets back.
• Operate: installing, configuring and running the gateway, what it needs around it, and what each release added.
• Contribute: how the work is tracked and which checks a change has to pass.

The tracker is the scope. Open issues are the worklist, milestones are releases, and the milestones page is the public view of both.

How it works

This part of the book explains the gateway in diagrams, one question per page. Each diagram cites the section of the Federation Tier specification it shows, and its requirements (N) or conformance points (CP). Each one shows what is built on main. A part drawn with a dashed border is planned, and the text names its issue and milestone.

The gateway between clients and member CDRs

The specification puts a Federation Tier between the applications and the member CDRs (§3.1). A client sends it ordinary AQL over openEHR ITS-REST and reads one ordinary RESULT_SET back (N1, N17). Before anything is sent to a node, the gateway resolves the patient outside AQL, through services of its own tier (§4.1, N3). Each node then receives standard AQL scoped to its own ehr_id and never learns that it is part of a federation (N7). The diagram follows the three tiers of the specification’s own figure in §3.1.

flowchart TB
    subgraph app["Application tier"]
        client["Client application"]
    end
    subgraph tier["Federation Tier"]
        gw["FerroFED gateway"]
    end
    subgraph step1["Step 1, outside AQL"]
        loc["Localizer"]
        pix["PIX Manager"]
    end
    subgraph nodes["Node tier"]
        a["Node A"]
        b["Node B"]
    end
    client -->|"1. AQL"| gw
    gw -->|"2. where?"| loc
    gw -->|"3. which ehr_id?"| pix
    gw -->|"4. ehr_id A"| a
    gw -->|"4. ehr_id B"| b
    gw -->|"5. RESULT_SET"| client

Step 2 is optional. Under federation.node_selection = "ask-all" every registry member is a candidate, and the gateway asks the PIX Manager about all of them (§4.3, N4). Under "localized" a localizer names the candidates first (§14.1). Four localizers are built: IHE XCPD ITI-55 (Annex A.3), the NVI of the Dutch binding (Annex B §B.1), the PIX Manager itself, whose one ITI-83 answer both localizes and resolves (§14.2), and the development cross-reference.

The parts of the gateway

The second diagram opens the gateway box. The names in it are the names every other page of this part uses.

flowchart TB
    client["Client application"]
    subgraph gw["FerroFED gateway"]
        gate["Gate<br/>token, scope,<br/>purpose of use"]
        facade["Façade<br/>ITS-REST"]
        store[("Stored-query<br/>store")]
        rewrite["Rewrite<br/>AQL per node"]
        seams["Identity<br/>seams"]
        registry[("Registry<br/>snapshot")]
        engine["Engine<br/>fan-out, routing,<br/>outbound gate"]
        merge["Merge<br/>rows and<br/>meta.federation"]
        admin["Admin<br/>listener"]
        keys["Signing key<br/>and JWK Set"]
    end
    pix["PIX Manager"]
    xcpd["XCPD responding<br/>gateways"]
    nodes["Member CDRs"]
    client -->|"requests"| gate
    gate -->|"verified caller"| facade
    store -->|"definitions"| facade
    facade -->|"parsed query"| rewrite
    facade -->|"patient"| seams
    seams -->|"ITI-83"| pix
    seams -->|"ITI-55"| xcpd
    rewrite -->|"node queries"| engine
    registry -->|"members"| engine
    keys -->|"assertion,<br/>signed caller"| engine
    engine -->|"ITS-REST"| nodes
    engine -->|"outcomes"| merge
    engine -->|"counts"| admin
    merge -->|"RESULT_SET"| facade

• Gate: verifies the caller’s access token against the issuers you trust, and checks the operation’s scope and the purpose of use before anything else reads the request (§13.1, N25). A refused request reaches no node (Trust and keys).
• Façade: serves the ITS-REST surface the client sees, from the generated route tables of openehr-its (§7a, N1). It takes the query apart, picks the path a request takes, and writes the answer.
• Rewrite: parses the AQL with openehr-query, finds the patient on both carriers, and prints one standard query per node with printer::to_aql (§7.1, N2, N7). It refuses a query it cannot reduce safely (§5.4.3).
• Identity seams: one trait per role of §5.2, §13.2.1 and §14: the resolver (the PIX Manager over ITI-83), the localizer (XCPD over ITI-55, the Dutch NVI or the PIX Manager), the consent pre-filter, and the optional demographics step ahead of them (a PDQm Supplier over ITI-78 or ITI-119, Annex A §A.2). The pre-filter has a development binding and a production binding, the Dutch Mitz (Dutch consent).
• Engine: sends one request per node under one deadline (§11.5, N38), routes a follow-up to the node that owns it (§12), and passes every outbound request through the outbound gate (§5.4.1, N33). Each request carries the node’s own credential and the caller’s identity, signed by the gateway for that node (§13.1, N24, N25).
• Signing key and JWK Set: the gateway’s ES384 key signs its client assertions to each node’s token endpoint and the caller’s identity on every node request. Its public half is served at {base}/.well-known/jwks.json (§13.1, N30).
• Merge: orders, de-duplicates and cuts the rows across nodes, and reports every member with its status (§9 to §11, N13, N16, N37, N39).
• Registry snapshot: the members you admitted, read from a reviewed document or an mCSD care services directory into an immutable snapshot, and the follow-up routing table (§12b, §15.1, N21).
• Stored-query store: the definitions the gateway holds when you offer the stored-query registry (§12.7, N44).
• Admin listener: a second listener for your operators only: the metrics and the stored-query repair. No client of the federation reaches it.

What the gateway holds, and what it does not

The gateway holds no clinical data. The specification is silent on storage, so where each piece of state lives is FerroFED’s own design.

It never writes a patient identifier, a value derived from one, or a result row to disk. A stored query names its patient through a $parameter, and a definition with a literal patient identifier is refused (§5.4.1, N33).

A federated query, end to end

You send POST {base}/v1/query/aql with a patient query, as you would to one CDR. This page follows that request through the gateway in two halves: Step 1 resolves the patient, and Steps 2 and 3 send the node queries and merge the answers (§4.1). The two closing diagrams show the status each member gets and the HTTP status of the whole answer. The names match the overview.

Step 1: resolve the patient, outside AQL

The client names the patient the openEHR way, for example WHERE e/ehr_status/subject/external_ref/id/value = 'ffd-test-0001' with its namespace (§7, N2). The gateway takes that value out of the query and asks the identity seams where the patient is and under which local ehr_id (§5.2, N3, CP-3). The order is fixed: the registry snapshot, then the localizer, then the consent pre-filter, then the resolver. Only a member the resolver answers with an ehr_id, and the pre-filter did not deny, is sent a query (N8, CP-36).

%%{init: {"sequence": {"actorMargin": 24}}}%%
sequenceDiagram
    participant C as Client
    participant F as Façade and rewrite
    participant L as Localizer
    participant P as Consent
    participant X as PIX Manager
    C->>F: POST /v1/query/aql,<br/>Bearer token
    Note over F: the gate: token,<br/>scope, purpose of use,<br/>or 401, 403
    Note over F: parse, bind,<br/>find the patient,<br/>or answer 400
    Note over F: take the registry<br/>snapshot
    opt node_selection = localized
        F->>L: candidates?
        L-->>F: members, or fail closed
    end
    opt a consent pre-filter is configured
        F->>P: may each be asked?
        P-->>F: denied, or no signal
    end
    F->>X: ITI-83 $ihe-pix
    X-->>F: ehr_id per domain, or none
    Note over F: {node, ehr_id}<br/>pairs, kept for<br/>this caller

• Node selection is a declaration you make (§4.3, N4, N10). Under federation.node_selection = "ask-all", every active member is a candidate. Under "localized", the localizer names the candidates, and a member it does not name is not-localized and never asked. A directed query is never localized (§8).
• A localizer that fails fails closed: no member is asked, every member is not-localized with the localizer’s error, and meta.federation.localization.error carries the same error, so an outage never reads as a patient with no data. Only federation.localization.on_failure = "ask-all" widens instead (§14.1, N4, CP-5).
• The localizer is one of four (Identity resolution). IHE XCPD asks every responding gateway by the patient identifier alone which communities hold the patient (ITI-55, Annex A.3). The NVI of the Dutch binding names the care providers that hold data for the patient’s pseudonym (Annex B §B.1, Dutch localization). Without either, the PIX Manager localizes: its candidates are the members whose domain holds an identifier for the patient, and the resolution reuses that one ITI-83 answer (§14.2). The read of an EHR by subject is localized the same way.
• The consent pre-filter is optional and never the gate: a member it denies is consent-denied, never resolved and never sent a request, and every other member is asked so its node can decide (§13.2.1, N27, N27a). When the pre-filter cannot answer, every candidate is asked. The pre-filter is the Dutch binding, Mitz (Dutch consent).
• “No identifier in this domain” is an answer: that member is not-resolved and does not fail the query (N6). A PIX Manager that cannot answer is a failure, reported on the member and failing the query 424 under the default (§11.4).
• The PIX Manager is the one service that receives the patient identifier, because resolving it is its role (§5.2). The gateway never records the request URL of that call.

Steps 2 and 3: dispatch and merge

The rewrite builds one query per resolved node from the parsed AST. The subject predicate becomes e/ehr_id/value = '<that node's ehr_id>', the canonical form of N29, and printer::to_aql prints it (§7.1, N7, CP-4). The engine sends every node query at once, under one deadline fixed when the request arrived (§11.5, N38), and each request passes the outbound gate first (Where the patient identifier stops). Each request carries that node’s own credential and the caller’s identity in a token the gateway signs for that node (Trust and keys).

%%{init: {"sequence": {"actorMargin": 24}}}%%
sequenceDiagram
    participant C as Client
    participant F as Façade and rewrite
    participant E as Engine
    participant A as Node A
    participant B as Node B
    Note over F: one AQL per node,<br/>printed by to_aql
    F->>E: fan out, one deadline
    Note over E: outbound<br/>gate
    par every resolved node at once
        E->>A: AQL, ehr_id A,<br/>node token, signed caller
        A-->>E: rows
    and
        E->>B: AQL, ehr_id B,<br/>node token, signed caller
        B-->>E: rows, error,<br/>or time-out
    end
    E-->>F: outcome per member
    Note over F: merge
    F-->>C: RESULT_SET with<br/>meta.federation

A node that answers after the deadline is ignored, and abandoning one node never cancels another (§11.5). meta.federation.timeout reports the budget that applied, and each dispatched endpoint reports the latency_ms the gateway saw (N38, N40, CP-31).

The merge

The gateway reads every node’s rows by position against your own SELECT, never against the column names a node sends back. It then shapes them the way one CDR would (§9 to §11.6). The order of the steps is FerroFED’s own where the specification gives none.

flowchart TB
    rows["Rows of each active node"] -->|"by position"| check["Check each node's<br/>visible order"]
    check -->|"accepted rows"| dedup["De-duplicate copies,<br/>on request"]
    dedup -->|"one copy per version"| order["ORDER BY, then<br/>endpoint_id and uid"]
    order -->|"one global order"| distinct["DISTINCT"]
    distinct -->|"distinct rows"| cut["OFFSET and LIMIT"]
    cut -->|"the page"| inject["Re-inject subject and<br/>ENDPOINT columns"]
    inject -->|"rows and columns[]"| out["RESULT_SET"]

• ORDER BY with LIMIT n: each node is sent LIMIT n, and the gateway orders the union and cuts it to n again (§11.6.1, N39, CP-32). A node that returned n rows out of the Tier’s order is node-error, because its cut may hide a row.
• OFFSET k: each node is sent LIMIT k + n, up to a window you configure, and the gateway slices the merged order (§11.6.2, N39).
• Aggregates: COUNT, SUM, MIN, MAX and AVG over several nodes come back as one row, recombined exactly; any other undirected aggregate is a 400 (§11.6.3, N14, CP-10).
• De-duplication: off by default. openEHR-federation-dedup: version-identity keeps one copy of a version held at several nodes, the one from the CDR that created it, and meta.federation.dedup names the copies dropped (§10, N15, CP-9).
• The subject column: a selected subject is the value you sent, put back by the gateway. No node is asked for it (N5, CP-7).

The status of each member

Every registry member appears in meta.federation.endpoints[] exactly once, with one status from the set of §11.1 (N16, CP-11). The diagram shows how a member reaches each status.

flowchart TD
    m["A registry member"] -->|"node selection"| sel{"In scope?"}
    sel -->|"left out or<br/>suspended"| excl["excluded"]
    sel -->|"not a<br/>candidate"| nloc["not-localized"]
    sel -->|"in scope"| pre{"Consent<br/>pre-filter"}
    pre -->|"denied"| cden["consent-denied,<br/>no latency_ms"]
    pre -->|"not denied"| res{"Resolver"}
    res -->|"no ehr_id"| nres["not-resolved"]
    res -->|"no answer"| nresf["not-resolved,<br/>with the error"]
    res -->|"ehr_id"| sent["Sent the<br/>node query"]
    sent -->|"rows"| act["active"]
    sent -->|"no<br/>connection"| off["offline"]
    sent -->|"deadline"| tout["time-out"]
    sent -->|"error or<br/>unusable"| nerr["node-error"]
    sent -->|"403, a listed<br/>consent code"| cref["consent-denied,<br/>with latency_ms"]

A member settled before dispatch carries no latency_ms, and a member the gateway sent a request carries the time it observed (N40). That is why the two consent-denied boxes differ. ITS-REST defines no consent signal, so a node’s refusal is consent-denied only when it is a 403 whose ITS-REST Error carries a code the registry lists for that endpoint in consent_refusal_codes; every other refusal is node-error (Consent). The list is empty by default, and the key is FerroFED’s own design.

The status of the whole answer

The default is all-or-nothing: a node that was asked and did not give a usable answer fails the query, and the failing answer still carries meta.federation (§11.4, N37, CP-30). Best-effort is an opt-in per request with openEHR-federation-completeness: partial.

flowchart TD
    start["Every member settled,<br/>meta.federation built"] -->|"read the header"| mode{"completeness<br/>header"}
    mode -->|"all, or none"| t{"In-scope node<br/>offline or<br/>time-out?"}
    t -->|"yes"| s504["504 with<br/>meta.federation"]
    t -->|"no"| e{"node-error, or<br/>resolver failed?"}
    e -->|"yes"| s424["424 with<br/>meta.federation"]
    e -->|"no"| s200["200 with every<br/>active node's rows"]
    mode -->|"partial"| p200["200 with the<br/>rows that arrived"]
    s200 -->|"set the flag"| c{"Every in-scope<br/>member active?"}
    p200 -->|"set the flag"| c
    c -->|"yes"| yes["complete: true"]
    c -->|"no"| no["complete: false"]

• not-resolved and consent-denied are answers. They clear complete and never fail the query (§11.3, N6). A patient no member holds is a 200 with no rows.
• A localizer that failed closed leaves every member not-localized, so the answer is a 200 with complete: true and no rows. Read meta.federation.localization.error to tell that apart from a patient no member holds (§14.1).
• excluded and not-localized members were never in scope, so they do not clear complete (§11.1).
• Read meta.federation.complete, never the status code: a 200 can carry complete: false (§11.4).
• A partial request for an aggregate the gateway recombines is a 400, because a sum over the nodes that answered is a wrong value.

The client contract and Errors and status codes list every field and code.

Where the patient identifier stops

The patient identifier you put in a query is resolution input. The gateway consumes it, resolves it to each node’s own ehr_id, and then locates every node by that ehr_id alone. No part of a request the gateway composes for a node carries the identifier: not the AQL, not the path, not the query string, not a header (§5.4.1, N33). This is the central safety property of the specification, and its adversarial test track (§16, track 10). A pseudonym is handled exactly like a direct identifier (§5.3).

The identifier’s path through the gateway

The diagram shows §5.4.3 and §7.1 with the conformance points CP-2, CP-26 and CP-38. Two independent layers stop the identifier: the rewrite, which builds the node query from the parsed AST, and the outbound gate, which re-reads each finished request before it leaves.

flowchart TD
    q["Your query:<br/>AQL and parameters"] -->|"parsed"| scan["Rewrite: find the<br/>patient on both carriers"]
    scan -->|"cannot consume<br/>exactly"| refuse["400, names the<br/>position, never<br/>the value"]
    scan -->|"consumed"| ref["Patient reference,<br/>redacted everywhere"]
    ref -->|"ITI-83"| pix["PIX Manager"]
    pix -->|"ehr_id per member"| rw["Rewrite: subject becomes<br/>e/ehr_id/value"]
    rw -->|"one AST per node"| print["printer::to_aql"]
    print -->|"node AQL"| gate["Outbound gate"]
    gate -->|"a consumed<br/>value found"| stop["Not sent"]
    gate -->|"clean"| node["Node: its own<br/>ehr_id only"]

• Both carriers resolve. The patient may sit in EHR_STATUS.subject.external_ref, or in an ENTRY-level subject with its issuer or type. Both are resolution input on equal terms (§5.4.3, CP-38).
• Strip or refuse, nothing in between. A value the gateway resolved on is removed with its namespace. A second patient value, a subject under OR, != or LIKE, the subject in ORDER BY, or the patient value anywhere else in the query is a 400 before any dispatch (§5.4.1, §5.4.3).
• The value is the test. A clinician or facility identifier on composer or health_care_facility is ordinary query material and is sent (CP-2). The same value as the patient’s, on any path, is refused (CP-26).
• Text the parser drops never travels. The node query is printed from the rewritten AST, so a comment or a string spliced around it cannot reach a node.
• A selected subject comes back from the gateway. The node is asked for ehr_id rows, and the gateway re-injects the value you sent (N5, CP-7).

What the outbound gate reads

Every request to a node passes the gate, a federated query and a routed follow-up alike. The gate searches each part a node can read for every value resolution consumed, in plain and in escaped form. For a routed request it also decides which of the client’s own parts travel at all, from the parameters the matched ITS-REST operation declares.

flowchart LR
    subgraph client["From the client"]
        ch["Headers"]
        cq["Query string"]
        cb["Write body"]
    end
    subgraph composed["Composed by the gateway"]
        aql["Node AQL<br/>and paging"]
        path["URL path with<br/>the node's ehr_id"]
        conv["openEHR-federation-client<br/>caller claims"]
    end
    ch -->|"declared"| gate["Outbound gate"]
    ch -->|"Authorization,<br/>X-Request-Id,<br/>openEHR-federation-*"| held["Withheld"]
    cq -->|"all declared"| gate
    cq -->|"undeclared"| q400["400"]
    cb -->|"byte for byte"| node["Node"]
    aql -->|"searched"| gate
    path -->|"searched"| gate
    conv -->|"searched"| gate
    gate -->|"clean"| node
    gate -->|"value found"| stop["Not sent"]

• The URL authority and the Host header come from your registry, never from a request, so the gate does not read them (§5.4.1).
• The openEHR-federation-client token the gateway signs for each node carries claims about the verified caller. The gate reads each of them before it is signed, and a caller claim that would carry the identifier refuses the request with nothing sent (What a node is told about the caller).
• A write body is clinical content. A DV_IDENTIFIER inside a committed COMPOSITION reaches the node byte for byte, because the gateway has no right to alter it (§5.4 scope note, N22).
• GET {base}/v1/ehr?subject_id=… names the patient in its query string. The gateway resolves that subject and sends the node GET {base}/v1/ehr/{ehr_id} with no query string (Reading an EHR by subject).
• An ask-all probe carries the path ehr_id. It is sent only for an ehr_id that is a bare UUID, because any other HIER_OBJECT_ID form could be a patient identifier, and the probe would send it to every member.

The gateway’s own surfaces

The rule covers what a node receives. FerroFED holds its own records to the same rule, because a log pipeline or a metrics store is read by people the patient never dealt with. No specification governs these surfaces: our own design.

The identity resolution page configures the PIX Manager the identifier goes to.

Follow-ups and writes

A row of a federated answer leads to a follow-up: you read the composition, or you commit a new version of it. Every such request goes to exactly one node, unchanged, and its answer comes back as that node sent it (§12, N22, N31). Four identifiers decide which node, and §12a says which one governs which request:

Routing a path ehr_id

An ehr_id carries no system component, so a path that names one does not say which node holds the EHR (§12.5). The gateway asks five sources in a fixed order and stops at the first that names exactly one node (§12.5.1 as release 1.0.1 sets it, N41, CP-33). It never chooses between two claimants (§12.5.2, N42).

flowchart TD
    req["Request under<br/>{base}/v1/ehr/{ehr_id}"] -->|"step 1"| s1{"Header names<br/>one endpoint?"}
    s1 -->|"yes"| route["The owning node"]
    s1 -->|"no, step 2"| s2{"Binding of<br/>this caller?"}
    s2 -->|"one node"| route
    s2 -->|"none, step 3"| s3{"ehr_id index?"}
    s3 -->|"one node"| route
    s3 -->|"two nodes"| c409["409 ehr-id-collision"]
    s3 -->|"none, step 4"| s4{"Path names a version<br/>whose creating_system_id<br/>the registry maps?"}
    s4 -->|"one node"| route
    s4 -->|"no"| rw{"Read or write?"}
    rw -->|"write"| t400["400 target-required"]
    rw -->|"read, step 5"| probe["Ask-all probe:<br/>GET ehr/{ehr_id}<br/>at every member"]
    probe -->|"one holder"| route
    probe -->|"two holders"| c409
    probe -->|"none"| n404["404 no-destination"]
    route -->|"forwarded once"| answer["The node's answer"]

• Step 1 is the one you should use: the row you act on carried its endpoint_id, so name it in openEHR-federation-endpoint (§12.5.1).
• Step 2, the resolution binding your earlier query left behind, is kept per verified caller (issuer, subject and client), in memory, for federation.binding_ttl after the last resolution that returned it, and up to federation.binding_capacity bindings over every caller; another caller never sees it, and a consent denial of a member drops the bindings naming it (§12.5.1, N41).
• Step 3, the ehr_id index, is in memory and learns from resolutions and from the nodes’ successful answers. A miss costs one fallback step, never a wrong route.
• Step 4 applies when the path carries a version uid, an OBJECT_VERSION_ID: the member whose system_id is that uid’s creating_system_id, as the registry maps it (a member’s own system_id or a [[creating_system]] entry, never a route learned from answers). The gateway asks it only when steps 1 to 3 named no node, so it never sends your ehr_id to the creator while an earlier step named another node (§12.5.1).
• Step 5, the probe, runs for reads only, and only for an ehr_id that is a bare UUID (§5.4.1). A member that fails or times out during the probe fails the read 424 or 504, because the owner is then unknown. Two holders also raise an integrity incident for the operator (N42).

A read of one version, such as GET {base}/v1/ehr/{ehr_id}/composition/{uid}, routes by its path ehr_id the same way, because every ITS-REST version read is EHR-scoped (§12.3, §12a.1, N22). When the node it reaches holds an imported copy, you get the copy, and the openEHR-federation-system-id response header names that node: a value that differs from the creating_system_id in the uid you asked for tells you it is a copy. To read the original, address the creator with its own ehr_id for the patient (§12.3, §7a.3).

A versioned write

A versioned write amends a version that exists. It routes by its path ehr_id through steps 1 to 4, never through the probe, and is then held to the version it names: the registry must map that version’s creating_system_id to the routed node (§12.4, §12a.1, N23, CP-15). A write that lands on a node holding only a copy is refused 409 naming the controlling system, and is never redirected to the owner under the holder’s ehr_id (§10.3 copy-write-reject, N36).

flowchart TD
    w["PUT or DELETE naming<br/>a version, or a CONTRIBUTION"] -->|"read If-Match,<br/>path or body"| pv{"One preceding<br/>version each?"}
    pv -->|"no"| b400["400 preceding-<br/>version-invalid"]
    pv -->|"yes"| r["Route by the path<br/>ehr_id, steps 1 to 4"]
    r -->|"the routed node"| ctl{"Registry maps the<br/>creating_system_id<br/>to that node?"}
    ctl -->|"yes"| send["Forward once to<br/>the controlling CDR"]
    ctl -->|"another node,<br/>or none known"| c409["409 controlling-system-<br/>unreachable, sent<br/>to no node"]

A route the gateway learned from answers never makes a node the controller, because a node that holds versions of a system need not have created them (§12.2). The sequence below is the hazard of §10.3: node A created a composition, node B holds an imported copy, and de-duplication kept node A’s row (N36, CP-29).

%%{init: {"sequence": {"actorMargin": 24}}}%%
sequenceDiagram
    participant C as Client
    participant G as Gateway
    participant A as Node A
    participant B as Node B
    C->>G: PUT under B's ehr_id<br/>If-Match: …::node-a.example::1
    Note over G: path routes to B,<br/>node-a.example is A
    G-->>C: 409, names node A
    Note over B: sent nothing
    C->>G: the same PUT<br/>under A's ehr_id
    G->>A: forward once
    A-->>G: 200, ETag, Location
    G-->>C: node A's answer

The gateway refuses without asking node A, so the refusal holds while node A is down too. It never falls back to writing at the copy.

Creating an EHR

A new EHR has no owner yet, so it goes only where you send it (§12.4, N23). A PUT that chooses its own ehr_id is checked against what the gateway already knows, so one ehr_id never lands at two members (§12.5.2).

flowchart TD
    c["POST {base}/v1/ehr, or<br/>PUT {base}/v1/ehr/{ehr_id}"] -->|"targeting headers"| h{"Endpoints<br/>selected?"}
    h -->|"none"| t400["400 target-required"]
    h -->|"several"| s400["400 endpoint-several"]
    h -->|"one"| known{"ehr_id known at<br/>another member?"}
    known -->|"yes"| held["409 ehr-id-held,<br/>sent to no node"]
    known -->|"no"| fwd["Forward to the<br/>endpoint you named"]
    fwd -->|"on success"| idx["The ehr_id index<br/>learns the node"]

Two creates of one ehr_id that race past the check both reach their nodes. The second to succeed raises the index-insert alarm of §12b.2, and from then on a request for that ehr_id must name its endpoint.

The follow-ups page lists every header, code and case.

Definitions and stored queries

A template lives at the node it was uploaded to, and a COMPOSITION built on it validates only there. A gateway that hid that from you would let you upload a template at one node and commit against it at another (§12.6). So the definition area goes to one node you name, with two opt-in exceptions your deployment declares in OPTIONS {base}/: a template upload fanned out to several members, and a stored-query registry the gateway holds itself (§12.6, §12.7, N43, N44).

Where a definition request goes

The diagram shows §12.6 with N43 and CP-34.

flowchart TD
    d["Request under<br/>{base}/v1/definition/"] -->|"which path?"| sq{"Stored query, with<br/>the registry on?"}
    sq -->|"yes"| reg["The gateway's<br/>stored-query registry"]
    sq -->|"no"| tgt{"Targeting<br/>headers"}
    tgt -->|"one endpoint"| one["Forward to that node,<br/>its answer as sent"]
    tgt -->|"none"| t400["400<br/>target-required"]
    tgt -->|"several, a template<br/>upload, fan-out on"| fan["Send the upload to<br/>each named member"]
    tgt -->|"several,<br/>otherwise"| bad["400"]
    fan -->|"outcome per member"| out{"How many<br/>accepted?"}
    out -->|"all"| s200["200"]
    out -->|"some"| s207["207, complete: false,<br/>nothing rolled back"]
    out -->|"none"| s5xx["504 or 424"]

• The gateway never picks a node for you and never merges two nodes’ template lists into one catalogue (§12.6, N43).
• Fan-out template upload is off by default and declared as definition.fan_out_template_upload (§7a.2). A member that accepts keeps the template whatever the others answer, and a partial success is never reported as success (§12.6 template-fanout).
• The fan-out answer carries meta.federation with one entry per member, in the shape of a federated query’s (§9.5).

The stored-query registry

With [stored_queries] set, the gateway is authoritative for each stored query (§12.7, N44, CP-40). A version is immutable: a second PUT of a held name and version is refused, before and after a restart. You invoke a stored query by name, and the gateway runs its AQL over the members exactly as an inline query.

%%{init: {"sequence": {"actorMargin": 24}}}%%
sequenceDiagram
    participant C as Client
    participant G as Gateway
    participant S as Stored-query store
    participant A as Node A
    C->>G: PUT /v1/definition/query/<br/>org.example::compositions/<br/>1.0.0
    G->>S: insert if absent
    S-->>G: stored, or held
    G-->>C: 200 with Location,<br/>or 409 stored-query-held
    C->>G: POST /v1/query/<br/>org.example::compositions
    G->>S: highest version
    S-->>G: the stored AQL
    Note over G: resolve, rewrite<br/>per node
    G->>A: AQL scoped to ehr_id A
    A-->>G: rows
    G-->>C: RESULT_SET, name<br/>of the stored query

• A definition names its patient through a $parameter. A literal patient identifier is refused, because the store would hold it at rest (§5.4.1, N33).
• The store is redb for one gateway, PostgreSQL for several replicas, or read-only files your operator publishes (Queries and API areas). Reads go through an in-memory cache of immutable versions, so no query waits on the store while it talks to nodes.

Distribution, drift and the repair

With federation.fan_out_stored_queries set beside the registry, a PUT that names members in the targeting headers is stored first and then sent to each named member, on the template fan-out’s four terms (§12.7 stored-query-fanout). A member’s copy can drift later: a failed distribution, a local PUT at the node, a restore, or a member admitted after the distribution (§12.7 stored-query-drift). An invocation always runs the registry’s copy, so drift never changes an answer. The drift check and the repair show it to you and fix it.

flowchart TD
    chk["GET the version,<br/>naming members"] -->|"each member's copy"| cmp{"Same canonical<br/>AQL as the<br/>registry's?"}
    cmp -->|"yes"| act["active"]
    cmp -->|"differs"| diff["node-error<br/>definition-differs"]
    cmp -->|"no copy"| miss["node-error<br/>definition-missing"]
    diff -->|"operator names them"| rep["Admin listener:<br/>POST /admin/stored-queries/<br/>{name}/{version}/distribute"]
    miss -->|"operator names them"| rep
    rep -->|"the held copy"| nodes["The named members"]

The repair runs on the admin listener only, because the specification gives drift repair no request and a second PUT of a held version is always refused (§12.7, N44). No specification governs the repair action: our own design. A definition that carries a FROM ENDPOINT directive is never distributed, because a node cannot run a directive that names other members (§12.7 fanout-endpoint-targeted-refused).

The stored queries and templates pages give every request and code.

Trust and keys

The gateway stands in two trust relationships. Callers trust it with their access tokens, and the nodes trust it to say who is asking. The specification requires both: the client authenticates to the gateway, the gateway authenticates onward to each node, and the client’s identity travels with every request (§13.1, N24, N25, CP-16, CP-17).

All three are built on main for v0.0.8: client authentication (#80), OAuth 2.0 to each node with the gateway’s own key (#81) and the caller’s identity conveyed to each node (#82), with token exchange per caller and DPoP-bound tokens where a node asks for them (#439).

The gate

Every request to the ITS-REST surface, and OPTIONS {base}/, passes the gate before anything else reads it: the caller’s access token is verified, the operation’s scope and the purpose of use are checked, and a refused request reaches no node (Client authentication).

flowchart TB
    client["Client application"] -->|"HTTPS, Bearer<br/>access token"| proxy["Your reverse proxy:<br/>TLS"]
    proxy -->|"HTTP"| gate["The gate: token,<br/>scope, purpose of use"]
    gate -->|"401, 403, 503"| client
    gate --> gw["FerroFED gateway"]
    gw -->|"its own credential,<br/>the signed caller"| node["Node A"]

A caller’s Authorization header never reaches a node. A proxy that authenticates callers itself uses the explicit edge mode, signing an assertion the gate verifies. Each onward credential is a file named by a _file key, sent only to its own endpoint.

Two trust relationships

flowchart TB
    as["Callers' authorization servers<br/>one signing key each"]
    subgraph gwbox["FerroFED gateway"]
        trust["Trust list<br/>of issuers"]
        key["Gateway key pair, ES256 or ES384<br/>private half: a _file secret"]
        jwks["{base}/.well-known/jwks.json<br/>current and previous kid"]
    end
    subgraph nodebox["Member node A"]
        tok["Token endpoint"]
        cdr["CDR"]
    end
    as -->|"each issuer's JWKS"| trust
    key -->|"public half"| jwks
    jwks -->|"verifies the<br/>client assertion"| tok
    jwks -->|"verifies openEHR-<br/>federation-client"| cdr
    tok -->|"access token"| cdr

• Callers to the gateway (#80): each calling organisation’s authorization server signs its own access tokens. The gateway keeps a trust list of issuers and reads each issuer’s JWKS, so it holds many public key sets and no caller’s private key.
• The gateway to each node (#81, §13.1, N25, N30): the gateway has one key pair of its own, on P-256 (ES256) or P-384 (ES384). A deployment whose nodes hold to the FAPI 2.0 Security Profile uses P-256, since that profile admits ES256 and not ES384 (§5.4.1). The private half is a secret file; the public half is published at {base}/.well-known/jwks.json and declared as federation.auth.jwks_uri in OPTIONS {base}/, so a node finds it without an out-of-band arrangement (§13.1 jwks-discovery). A rotation keeps the current and the previous kid in the set for one overlap window. The gateway needs no node’s key for this.
• The identity sent to the node (#82): the openEHR-federation-client header is a JWS signed with the same gateway key, so the node verifies it against the same JWKS.

The token flow

%%{init: {"sequence": {"actorMargin": 24}}}%%
sequenceDiagram
    participant AS as Caller's AS
    participant C as Client
    participant G as Gateway
    participant T as Node A token<br/>endpoint
    participant N as Node A
    C->>AS: token request
    AS-->>C: JWT, aud: the gateway
    C->>G: request, Bearer<br/>(caller token)
    G->>AS: read JWKS, cached
    Note over G: verify alg, iss,<br/>aud, exp, scope,<br/>purpose of use
    G->>T: client credentials, or the<br/>caller token exchanged,<br/>RFC 7523 assertion
    T->>G: read the gateway JWKS
    T-->>G: node token, cached
    G->>N: request, Bearer (node token),<br/>openEHR-federation-client
    N-->>G: answer
    G-->>C: answer

Checking the caller (#80). The access token is a JWT (RFC 9068), checked against the issuer’s JWKS, and every check fails closed. The issuer must be on the trust list, and the algorithm on an allow-list (ES256, ES384, PS256, RS256), so none and HMAC are refused (RFC 8725). The audience must name this gateway, and the token must not have expired. Any of those is a 401. The scopes are read in the SMART on openEHR grammar with openehr-sdt, and a token without a scope that covers the operation is a 403. A token without a purpose of use is a 403 too, unless your deployment declares it optional (§13.4). For a deployment whose proxy already authenticates callers, the edge mode is configured explicitly: the proxy signs an assertion of the caller, the gateway verifies it like a token and records which identity the proxy asserted. A patient/ scope grants nothing at the gateway, because no token claim defines the patient in a form the gateway can confine across nodes, unless the deployment binds the token’s issuer to one member. The gateway then resolves the token’s ehrId as an identifier of that member through the cross-reference service (§5.2), sends only to the patient’s own {node, ehr_id} pairs, and tells each node the patient’s ehr_id there (Patient grants).

Authenticating to the node (#81, §13.1, N25). The gateway sends the node’s token endpoint an OAuth 2.0 client credentials request with a client assertion of RFC 7523 §2.2. The assertion lives 300 seconds at most, carries a unique jti, and names the node’s token endpoint as its audience. The token endpoint verifies it against the gateway’s JWKS and issues an access token. The gateway caches that token per node until 30 seconds before it expires, and drops it on a 401. A token it cannot obtain fails that node node-error; the gateway never sends a request without one.

A token per caller, and a token bound to a key (#439). Where a node’s authorization server supports token exchange (RFC 8693), the gateway asks it for a token per verified caller instead: the caller’s token is the subject, a second assertion of the gateway the actor, the node the resource (RFC 8707), and the scope only the caller’s scopes that cover the operation (N26). The node then sees the caller in its own token as well as in the signed statement below. A caller the edge asserted has no token of its own, so that node fails node-error with nothing sent. Where a deployment requires sender-constrained tokens, a grant binds its tokens to a key of the gateway’s with DPoP (RFC 9449): every request to that node and its token endpoint carries a proof of the key over its method and URL, and a node that demands a nonce is answered once more with it.

Telling the node who asks (#82, N24, §12.4). Every request to a node carries openEHR-federation-client: a query, a routed read or write, a definition request, the ask-all probe and the read of an EHR by subject alike. It is a JWS signed with the gateway key, ES256 or ES384 as the key’s curve says, typed openehr-federation-client+jwt, that lives 60 seconds, addressed (aud) to that node’s endpoint id. It names the verified caller (sub) and its issuer (iss_upstream), how the gateway verified it (verified_by, edge for an identity the edge asserted), the caller’s organisation, the purpose of use and the caller’s scopes as granted. It never carries a patient identifier (N33): the outbound gate reads every caller claim, and a request whose claims would carry the identifier the query was resolved on is refused before it is sent. A request that reaches the dispatcher with no verified caller is a 500, with nothing sent. The gateway’s own requests for its operator, the admission check and the redistribution of a held stored query, name the gateway itself as sub. The specification leaves end-user conveyance open (§13.1), so the header and its claims are FerroFED’s own; a node verifies it as Verifying it at the node describes.

The caller’s token is never forwarded

The caller’s token was issued for the gateway: its audience is the gateway. Forwarding it would hand every node a credential that unlocks every other member that accepts the same issuer (RFC 9700 §2.3), and a node could replay it at its neighbours. So the gateway authenticates to each node as itself, with a token the node’s own authorization server issued, and conveys the caller as a signed statement the node can verify. Under token exchange the caller’s token reaches the node’s authorization server, which exchanges it, and never the node. It never asks a node for more than the caller holds: the caller’s scopes are enforced at the gateway and conveyed, so the node applies them too, and an exchanged token is asked for only the scopes that cover the operation (N26). Consent stays the node’s decision either way (§13.2, N27).

The §13.4 decisions a deployment must publish, such as which identity is verified across each boundary and who authenticates the end user, are answered for the gateway, with a template for the rest, in The §13.4 deployment decisions (#84, CP-39).

The Nuts track of the Dutch binding (Annex B §B.4) is built: an endpoint whose [credentials] name a nuts grant obtains its token with a Verifiable Presentation of the gateway’s credentials, bound to a key of the gateway’s with DPoP (The Nuts grant, #88). So is the harmonised BgZ and eOverdracht track (Annex B §B.4a): an endpoint whose oauth grant sets security_profile = "fapi2" discovers an authorization server under the FAPI 2.0 Security Profile, authenticates with an ES256 private_key_jwt assertion naming its issuer, sends the configured Rich Authorization Requests authorization_details, and binds its token with DPoP (The FAPI 2.0 grant, #497).

Deployment

The gateway is one static binary in one container image. What it needs around it is the roles of §4.1: member CDRs over ITS-REST, an identifier cross-reference, and the registry that addresses each member (§15, N21). This page draws the two shapes the book describes: the quickstart you run on one machine, and a production layout. No specification governs the process model or the topology: our own design.

The quickstart

The repository’s compose.yaml runs the gateway beside four member CDRs, four FerroEHR instances, on one PostgreSQL server that holds a database per node (The quickstart). The gateway runs in the development profile and resolves every patient through FerroPIX, the FerroHEALTH patient index, which Compose runs beside it on its own PostgreSQL and seeds with four synthetic patients over ITI-104 before the gateway starts; a one-shot seed creates their EHRs at the nodes. It trusts one development issuer, a service whose network namespace the gateway shares, and signs with a key you write once beside compose.yaml (The quickstart issuer).

flowchart TB
    you["You: curl"]
    keys["./secrets:<br/>signing key"]
    subgraph compose["docker compose"]
        iss["issuer, :8190<br/>tokens"]
        gw["ferrofed, :8080<br/>in the issuer's namespace"]
        ehrseed["ehr-seed<br/>ITS-REST, once"]
        pix["ferropix<br/>PIXm Manager"]
        seed["ferropix-seed<br/>ITI-104, once"]
        subgraph nodes["Four member CDRs"]
            a["ferroehr-a<br/>:8081"]
            b["ferroehr-b<br/>:8082"]
            c["ferroehr-c<br/>:8083"]
            d["ferroehr-d<br/>:8084"]
        end
        pg[("ferroehr-postgres<br/>ferroehr_a to ferroehr_d")]
    end
    you -->|"client credentials"| iss
    you -->|"AQL, Bearer"| gw
    keys -->|"a secret"| gw
    ehrseed -->|"seed over ITS-REST"| nodes
    gw -->|"AQL, Basic auth,<br/>the signed caller"| nodes
    gw -->|"ITI-83"| pix
    seed -->|"ITI-104"| pix
    nodes -->|"a database each"| pg

• Every port binds the loopback interface, so nothing is reachable from the network until you name an interface.
• The seed writes over each node’s ITS-REST API only, with identifiers in the example arc urn:oid:2.999.
• The node credentials and database passwords are development values that must not reach anything real.

A production layout

In production the gateway sits behind your reverse proxy, from the release’s compose.yaml or the Kubernetes example (The gateway from a release, Kubernetes). It resolves patients through your PIX Manager and, when you configure them, asks a PDQm Supplier first, localizes through XCPD or the Dutch NVI, and pre-filters on consent through Mitz.

flowchart TB
    clients["Client applications"] -->|"HTTPS, Bearer"| proxy["Your reverse proxy"]
    proxy -->|"HTTP"| gw["FerroFED gateway"]
    cfg["ferrofed.toml, registry,<br/>secret files, signing key"] -->|"start, SIGHUP"| gw
    issuers["Callers' issuers"] -->|"key sets"| gw
    subgraph identity["Step 1 services"]
        pdq["PDQm Supplier<br/>ITI-78, ITI-119"]
        pix["PIX Manager<br/>ITI-83"]
        xcpd["XCPD responding<br/>gateways, ITI-55"]
        nvi["NVI<br/>Dutch localization"]
        mitz["Mitz<br/>consent pre-filter"]
        mcsd["mCSD directory<br/>ITI-90, ITI-91"]
    end
    subgraph member["Each member"]
        tok["Token<br/>endpoint"]
        cdr["CDR"]
    end
    subgraph ops["Your operations"]
        store[("redb, PostgreSQL<br/>or files")]
        logs["Log pipeline,<br/>ferrofed::audit"]
        spool[("Audit spool,<br/>encrypted volume")]
        arr["ATNA Audit Record<br/>Repository"]
        admin["Admin listener<br/>/metrics, /admin"]
    end
    gw --> identity
    gw -->|"assertion"| tok
    gw -->|"node token,<br/>signed caller"| cdr
    gw -->|"definitions"| store
    gw -->|"events"| logs
    gw -->|"IHE audit<br/>records"| spool
    spool -->|"ITI-20, syslog<br/>or FHIR Feed"| arr
    gw -->|"serves"| admin
    pmir["PMIR Patient<br/>Identity Registry"] -->|"ITI-93 feed"| gw
    gw -->|"ITI-94<br/>subscription"| pmir
    prom["Prometheus"] -->|"scrapes"| admin
    gw -->|"spans, OTLP"| otel["OpenTelemetry<br/>collector"]

• The proxy terminates TLS. The gateway authenticates each caller itself, against the key sets of the callers’ issuers, or verifies the assertion of a proxy in the explicit edge mode (Client authentication).
• The configuration is your reviewed files. The registry reloads on SIGHUP with no restart, and every credential and the signing key is a file named by a _file key (Configuration).
• The Step 1 services. The PIX Manager resolves each patient to an ehr_id per member, and without [xcpd] or [nl_gf.nvi] it is the localizer too. The XCPD responding gateways localize when you configure [xcpd], and the NVI when you configure [nl_gf.nvi]. A PDQm Supplier, under [pdqm], names the master identity of a patient the cross-reference does not know by the client’s identifier, and Mitz, under [nl_gf.mitz], is the consent pre-filter (Identity resolution). The mCSD directory, when you read the registry from one instead of a document, is asked with ITI-90 at start and with ITI-91 every refresh interval, off the clinical path (The registry).
• Each member’s token endpoint, where its oauth section names one, issues the gateway an access token for a client assertion its client key signs, and checks that assertion against {base}/.well-known/jwks.json. With an onward table beside it the token is issued per verified caller, and with a DPoP key it is bound to the gateway’s key. A nuts section, or an oauth section under the FAPI 2.0 profile, obtains the token on a track of the Dutch binding instead. A member without one is sent its static credential, if it has one (Trust and keys, Onward credentials).
• The audit of each IHE transaction goes to your ATNA Audit Record Repository: written to a spool on disk first, then sent with ITI-20, so a repository outage delays the audit and fails no query. An XCPD exchange, under [xcpd] audit = "repository", is a DICOM audit message over syslog on TLS; the PIXm, PDQm, mCSD and PMIR transactions, under [audit], are FHIR AuditEvents sent with the FHIR Feed. The spool holds audit records that name patients, so it belongs on an encrypted volume (The audit trail). Under [xcpd] audit = "log" or [audit] destination = "log" the records go to the log target ferrofed::audit instead, without the patient or the caller; a production gateway with a registry refuses log for [audit], because its access records must name both.
• The PMIR Patient Identity Registry, under [pmir], takes the gateway’s ITI-94 subscription and sends each identity change to the gateway’s feed route, which drops the resolution bindings the change could have made stale (The identity feed).
• The admin listener is a second listener for your operators, off unless [metrics] listen is set and on loopback unless you allow otherwise (Metrics).
• The OpenTelemetry collector, when [telemetry.otlp] names one, receives the gateway’s spans and metrics over OTLP (Tracing, Metrics).

Several replicas

Replicas share nothing in memory: each holds its own resolution bindings, ehr_id index and learned routes, and a miss costs a probe or an explicit target, never a wrong route. A follow-up write is never probed for, so a write that names no node is routed only by the replica that resolved the patient and refused 400 target-required by the others: clients name the node on every write, or the balancer keeps each client on one replica (Running several replicas). The stored-query registry is the one state they must share, because a stored version must be the same on every replica and a second PUT refused on every replica (§12.7, N44).

flowchart TB
    lb["Your proxy or<br/>Kubernetes Service"] -->|"any request"| r1["Replica 1<br/>own index in memory"]
    lb -->|"any request"| r2["Replica 2<br/>own index in memory"]
    r1 -->|"stored queries"| pg[("One shared<br/>PostgreSQL database")]
    r2 -->|"stored queries"| pg
    r1 -->|"node queries"| nodes["Member CDRs"]
    r2 -->|"node queries"| nodes

A redb file opens in one process at a time, so replicas that store queries use the postgres backend, or the read-only files backend when your operator publishes the definitions (Running several replicas). The Kubernetes example runs two replicas under a PodDisruptionBudget.

Replicas behind one address share the PMIR subscription that names it, and a draining replica leaves it for the others (Several replicas). A new signing key is published by every replica before any replica signs with it (Rotating the signing key).

The Federation Tier with AQL

This page is a plain account of the specification FerroFED implements. It cites the sections of the vendored text at docs/specs/federation-spec/ and adds nothing of FerroFED’s own; the next page does that.

Three tiers

The specification adds a Federation Tier to openEHR querying, so that a client can run one query across several openEHR CDRs as though they were a single repository (§1). The system has three tiers (§3.1):

• the application tier, where a client sends AQL and reads the combined result;
• the Federation Tier, one or more gateways that act as the intermediary;
• the node tier, member CDRs that run ordinary openEHR queries scoped to a single EHR and need not know they belong to a federation.

The gateway is a technically transparent intermediary (§3.2). The client interface is a conformant openEHR Query API, and a conformant ITS-REST surface generally, so a basic patient query needs no federation-specific syntax.

The flow

Federation keys on each node’s local ehr_id. Patient identity is resolved outside the query, and each node receives standard AQL scoped to its own ehr_id (§4).

flowchart LR
    C[Client] -->|"AQL with a subject predicate"| G[Gateway]
    G -->|"patient identifier"| X[Cross-reference service]
    X -->|"ehr_id per node, or not found"| G
    G -->|"standard AQL scoped to ehr_id A"| A[Node A]
    G -->|"standard AQL scoped to ehr_id B"| B[Node B]
    A -->|rows| G
    B -->|rows| G
    G -->|"one RESULT_SET with meta.federation"| C

1. The façade. The client sends POST {base}/v1/query/aql and may identify the patient the openEHR way, with WHERE e/ehr_status/subject/external_ref/id/value = <patientId> (§4.1, §7).
2. Resolution. The gateway resolves the identifier to a set of {node, ehr_id} pairs through a localization service, a directory and an identifier cross-reference service. The proposed bindings are IHE XCPD, mCSD and PIXm (§4.1, §5, Annex A). Without a localization service the gateway asks every known node (§4.3).
3. Fan-out. Each node with a resolved ehr_id receives the node AQL: the subject predicate replaced by e/ehr_id/value = '<resolved>', every other patient identifier removed or the query refused, and everything else forwarded unchanged (§7.1).
4. Combine. The gateway concatenates the rows, applies DISTINCT and ORDER BY across nodes, and reports every node it asked under meta.federation.endpoints[] with a status (§9, §11.1).

What the specification insists on

• No identifier leaves the gateway. The patient identifier used for resolution is consumed at the gateway and never reaches a node, in the query, its path or its headers (§5.4, N33).
• A partial answer is never presented as a whole one. When a node that was asked does not answer, the default is to fail the query, and every response carries meta.federation.complete (§3.2, §11.4).
• Consent stays at the node. A node enforces consent before it releases data; a gateway pre-filter is optional and never replaces that check (§1, N27).
• Follow-up reads and writes go to the owning CDR. The registry maps each creating_system_id to its CDR, and a versioned write goes only to the CDR that created the version (§12.2, §12.4, N21, N23). A request under a path ehr_id is routed to the node that holds that EHR (§12.5).
• Transparency is bounded. Where a gateway cannot behave as one repository (federated demographics, object creation across nodes, OFFSET paging, undirected aggregates), it says so in OPTIONS or refuses the request, and never returns an approximation the client cannot detect (§3.2). A new object is created at one node the client names (§2.3, N23).

The specification closes with a consolidated list of numbered conformance points (§17) and a Connectathon-style test approach (§16).

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).

Claims review

FerroFED’s manufacturer reviews what its public texts claim, once per release, against two provisions of Regulation (EU) 2025/327 on the European Health Data Space. This page is the method, the record of each review, and the assessment of the features that could burden access to health data. Every quotation is from the Official Journal text, vendored at docs/specs/eu-ehds/reg-eu-2025-327-en.xhtml. This page is not legal advice.

What the Regulation asks

Art 28 forbids, “in the information sheet, instructions for use or other information accompanying EHR systems, and in the advertising of EHR systems”, any text or sign 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.”

Annex II, point 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.” Art 7(1) gives a person the right to have their data transmitted to another healthcare provider “without hindrance from the healthcare provider or from the manufacturers of the systems used by that healthcare provider”.

How a review is done

The review reads every public text: README.md, SUPPORT.md, SECURITY.md, llms.txt and CITATION.cff; every page of this book; the landing page at https://ferrofed.eu; the README and the manifest description of each crate; and the title, description and labels of both container images. Each statement about FerroFED’s intended purpose, interoperability or security is held to three questions, one per point of Art 28:

1. Does a release ship it, and does a test hold it? A statement that ascribes more is rewritten, (a).
2. Does it leave out a limitation a professional user would need? The limitation goes on the Limitations list and next to the statement, (b).
3. Does it suggest a use outside the intended purpose? It is rewritten, (c).

A review runs before every release cut (docs/release.md, Before the tag), and adds a row to the record below. A finding that is not about a claim, such as a broken command, is fixed in the same change.

The record

Findings of 2026-10-06

Read in full: README.md, SUPPORT.md, SECURITY.md, llms.txt, CITATION.cff, the landing page, the book’s introduction, the Evaluate pages written by hand, the self-description section of the client contract, the README and manifest description of every crate, and the image labels. Every other page of the book was searched for absolute and security words (never, always, guarantee, certified, compliant, secure, safe, “never learns”) and each hit read in its paragraph.

Against Art 28(a), a function or property FerroFED lacks:

1. README.md, the book’s introduction, the landing page and llms.txt said a client “never learns it was federated”. A client reads every member with its status in meta.federation. Now: a client sends an ordinary query with no federation syntax and gets back an ordinary result set whose meta.federation names each node.
2. README.md and the book’s introduction said no directly identifying identifier “travels to a node”. The rule covers every request the gateway composes; a body the client writes reaches its node byte for byte (§5.4, N22). Now said that way.
3. The landing page’s card “No identifier reaches a node”, for the same reason. Now “No identifier in what the gateway sends a node”, with the write body named.
4. The landing page credited mutual TLS to a node to v0.0.8. It shipped in v0.0.9 (#492).
5. The landing page said the conformance statement “scores every conformance point … against FerroEHR and EHRbase”. Some points are deferred with a recorded reason, and EHRbase is checked for the node profile only.
6. The landing page’s quickstart sent a query with no access token and started the gateway with no signing key, so it answered 401. It now writes the key and mints the token as the README does.
7. The README’s quickstart sent the body 5820 in place of the query. It now reads the query from standard input.

Against Art 28(b), a limitation left out:

8. Nothing listed the limitations a professional user needs before deploying FerroFED. The claims page now carries them: Limitations.
9. README.md claimed ITS-REST 1.1.0 “on both faces” without saying that the DEMOGRAPHIC area is not federated and an unserved path answers 501. Now said beside the claim.

Stale or wrong statements, which read as claims about the release a user runs:

10. README.md named v0.0.7 as current and v0.0.8 as unreleased.
11. llms.txt named v0.0.8 as on main.
12. The claims page listed v0.0.9 as unreleased and its query console as planned.
13. The engine’s and the console’s READMEs listed follow-up forwarding and the query console as planned. Both shipped.
14. The client contract said OPTIONS {base}/ declares no auth.jwks_uri because the gateway publishes no JWK Set. Every federating gateway publishes one and declares it.
15. CITATION.cff dated v0.0.9 2026-10-04; its tag and its changelog section are of 2026-10-05.

Not fixed here:

16. The openehr-federation README says version-identity de-duplication “follows in build order”; it shipped in v0.0.6. The text under-claims, so Art 28 is not breached. A change to that README is a change to the packaged crate and moves its version, which is that crate’s own pull request.

No text suggested a use outside the intended purpose, (c).

Findings of 2026-10-15

The review at the v0.0.10 cut. Read in full: README.md, llms.txt, CITATION.cff, the landing page, the book’s introduction, the Evaluate pages written by hand, the instructions for use, the patient summary page, and the README and manifest description of ehds-logging, eehrxf and openehr-federation. Every other page of the book, SUPPORT.md and SECURITY.md was searched for “planned” and “yet” next to an issue that is closed, and for the words of the first review.

Against Art 28(a), a function or property FerroFED lacks: none found.

Against Art 28(b), a limitation left out:

17. The instructions for use did not say that a received document is not yet checked in full (#808), that the terminology rules are not yet applied to the summary the gateway writes (#926), or that behind several replicas a follow-up write that names no node can be refused (#641). All three are now listed.

Stale or wrong statements, which read as claims about the release a user runs:

18. README.md described v0.0.10 as being built on main and planned the reporting procedure and the support period, which ship in it (#762, #763).
19. llms.txt said retention by origin and category is planned and the gateway does not serve the interoperability component; both ship (#795, #809).
20. The landing page named v0.0.9 as current. It now names v0.0.10 and has a card for it.
21. The claims page planned the re-pin to 1.0.0, the reporting procedure and the support period for v0.0.10 and listed no v0.0.10 section under Shipped.
22. The instructions for use listed the professional’s identification and the assurance level as missing from the access record (#742).
23. The regulatory status page planned the Art 14 reporting procedure, the support period and the end-of-support notice (#762, #763, #782), and put the remaining EHDS work in the v0.0.10 milestone; it is in v0.0.11.
24. The information sheet planned the support period of each release (#763). It now states the end date of 0.0.10.
25. The information sheet’s standards table left out the HL7 Europe packages, the Xt-EHR models, FHIRconnect and the TLS versions the release uses. They are added, held to the pin matrix where it pins them.
26. The data-protection page and the threat model said the records are kept for no period by origin and category; each record states its period (#795). The data-protection page also planned the serious-incident procedure, which is written (#672).
27. The clinical safety risk file said the gateway does not serve the interoperability component, and marked as planned controls that shipped (#742, #722, #663, #687, #688, #734, #802). Its review row for 0.0.10 records the update.
28. The patient summary page planned the FHIR Validator lane, which CI runs (#688).
29. This page said the harmonised components are not built; the logging component’s access record and the interoperability component’s FHIR face are.
30. The release notes repeated two upgrade notes and two security entries, and told an operator to read GET /health/dependencies, which v0.0.10 no longer serves (#751). The duplicates are merged and the note names the operator surface.

Not fixed here: finding 16 stands, and the clinical safety file’s X-01 cites server tests planned with #689, which is closed without them.

No text suggested a use outside the intended purpose, (c).

Findings of 2026-10-15, after the cut

Read against the log work that shipped: this page and the clinical safety risk file.

Stale or wrong statements, which read as claims about the release a user runs:

31. This page planned the export of the gateway’s state for a replacement product (Annex II, point 2.6) with #660. It shipped with #798.
32. The clinical safety risk file held L-07 open until #660, although the review of the records with ITI-81 is built and tested. L-07 is re-rated and its review row records it.

Findings of 2026-10-16

The review at the v0.0.11 cut. Read in full: README.md, llms.txt, CITATION.cff, the landing page, the Evaluate pages written by hand, the instructions for use, the prescriptions page, the Upgrading page, and the assembled release notes. Every other page of the book, SUPPORT.md, SECURITY.md and the README and manifest description of each crate was searched for “planned”, “not yet” and “v0.0.1” next to an issue that is closed or a release that has shipped.

Against Art 28(a), a function or property FerroFED lacks:

33. The claims page listed electronic prescriptions and dispensations among what v0.0.10 shipped. They ship in v0.0.11 (#1039, #1040, #1041, #1042), and the bullet moved to a new v0.0.11 section.
34. The instructions for use said the record of a query over many patients’ data names no patient. Since #819 it names the patients behind the ehr_ids its rows project, up to a bound, and records only its scope otherwise. Now said that way.

Against Art 28(b), a limitation left out:

35. The instructions for use and the claims page did not say that a member holding its prescriptions only as openEHR data is not served (FerroHEALTH/FerroBRIDGE#1322), that the gateway offers no log access interface of its own (#660), or which settings stay in the file under config.ui = "managed" and that the console reads one replica at a time. All are now listed.

Stale or wrong statements, which read as claims about the release a user runs:

36. README.md named v0.0.10 as current and planned the rest of the interoperability component with no word of prescriptions. It now names v0.0.11, what it adds, and the planned work by issue.
37. The landing page named v0.0.10 as current and v0.0.11 as planned. It now names v0.0.11 and has a card for it.
38. llms.txt said every priority category other than the patient summary is planned. Prescriptions and dispensations are passed through from the members that serve them.
39. The claims page planned for v0.0.11 work that shipped in it or moved to v0.0.12 and v0.0.13; the regulatory status page put the remaining EHDS issues in the v0.0.11 milestone, left prescriptions out of what the interoperability component does, and planned the Annex II checklist and the technical documentation, which are written. Each now says where the work stands.
40. The configuration page planned the export and import of a revision (#579), which ships.
41. The information sheet listed the HL7 Europe MPD package twice in its standards table. It is listed once, and the operator console’s OpenID Connect sign-in is added beside the standards.
42. The release notes described the console’s top bar, navigation and system theme as the styling change of #1037 left them; the new shell of #1075 in the same release replaced all three. The entry now describes the styling and points at the shell.
43. The release notes named fhirconnect 0.1.111 on openehr-* 0.0.86 as where the mapping engine moves (#1028); the release ships the later versions of #714. The entry now says so.

Not fixed here: finding 16 stands.

No text suggested a use outside the intended purpose, (c).

Findings of 2026-10-24

The review at the v0.0.12 cut. Read in full: README.md, llms.txt, CITATION.cff, the landing page, the Evaluate pages written by hand, the instructions for use, the Upgrading page, the configuration revisions page and the assembled release notes. Every other page of the book, SUPPORT.md, SECURITY.md and the README of each crate was searched for “planned”, “not yet”, “v0.0.1”, ferrofed-viewer, FERROFED_VIEWER and bearer_token next to an issue that is closed, a release that has shipped or a name the release removes.

Against Art 28(a), a function or property FerroFED lacks:

44. The Upgrading page says a key is never renamed or removed at once and the old key is read for at least one release. v0.0.12 moves the issuer policy of [auth] to [trust], removes every static bearer token and renames the console’s FERROFED_VIEWER__ overrides with no release that reads the old keys (#1174, #1163, #1219). The page now says so under the rule, and the upgrade notes list each key.
45. The landing page said v0.0.12 brings the national contact point’s connector. Its end-to-end test waits on a published FerroPIX image and moved to v0.0.13 (#524, #735). The page now names what v0.0.12 ships, and the claims page plans the connector for v0.0.13.

Against Art 28(b), a limitation left out:

46. The instructions for use and the configuration revisions page left [trust] out of the bootstrap core that stays in the file under config.ui = "managed"; the gateway holds it there beside [auth]. Both pages now list it.

Stale or wrong statements, which read as claims about the release a user runs:

47. README.md named v0.0.11 as current and planned the logging component’s log access interface (#660), which is closed: the records are read at the Audit Record Repository with ITI-81. It now names v0.0.12, what it adds, and plans the Art 36(1) re-check (#799).
48. The landing page named v0.0.11 as current. It now names v0.0.12 and has a card for it.
49. llms.txt named only the gateway image, called the gateway’s outbound authentication “a static credential”, and planned the logging component’s review tools. It now names the console image, says HTTP Basic, and says where the records are read.
50. The claims page planned the national contact point’s connector for v0.0.12 and the log access interface of #660 for v0.0.13; the regulatory status page put the remaining EHDS issues in the v0.0.12 milestone, planned the logging component’s review, retention and export, which are built, and listed #526, which is closed. Each now says where the work stands, and the claims page has a v0.0.12 section.
51. The release notes described the console as each FerroUI step from ferrohealth-ui 0.1.3 to 0.3.6 left it, so an entry described a theme toggle in the top bar that a later entry removes and named paths under app/ferrofed-viewer/. The console entries now describe the console this release ships, on FerroUI 0.3.6.
52. The release notes’ upgrade note for the console said the theme cookie keeps its name, which holds only from the first FerroUI 0.3 build on main; from v0.0.11 it moves from ferrofed_viewer_theme to ferrofed_console_theme, so each operator chooses the theme again. The note now says so.
53. The release notes’ Removed entry for the Tailwind CSS pin named scripts/release/viewer-tools.sh, which the rename made scripts/release/console-tools.sh. The entry now names it.
54. The cybersecurity risk assessment said deny.toml holds two exceptions and that the console’s site build runs a CSS tool. It holds one, paste, whose OpenVEX statement gives the argument, and the site build runs only its WebAssembly tools. Point (a) now says so, with the release’s full scans.
55. The record held finding 16 as standing at the v0.0.10 and v0.0.11 reviews. The openehr-federation README lost the “follows in build order” sentence in the v0.0.10 version bump (commit ef7e3084), so the finding is closed there.

No text suggested a use outside the intended purpose, (c).

Findings of 2026-10-25

The review at the v0.0.13 cut. Read in full: README.md, llms.txt, CITATION.cff, the landing page, the Evaluate pages written by hand, the instructions for use, the Upgrading page and the assembled release notes. Every other page of the book, SUPPORT.md, SECURITY.md and the README of each crate was searched for “planned”, “not yet”, “plain gRPC” and the issues the v0.0.13 milestone closed next to a statement that the work is still to come.

Against Art 28(b), a limitation left out:

56. The instructions for use said a received document is not yet checked in full (#808), which v0.0.13 builds, and the claims page’s list of limitations said nothing of the received document. Both now name what stays: a constraint the validator cannot evaluate is listed as a warning, not refused, and a required binding the packages cannot decide needs the terminology server.

Stale or wrong statements, which read as claims about the release a user runs:

57. README.md named v0.0.12 as current and planned the national contact point’s connector (#524), which v0.0.13 serves. It now names v0.0.13 and what it adds.
58. The landing page named v0.0.12 as current and said v0.0.13 continues the connector. It now names v0.0.13, has a card for it, and plans v0.0.14.
59. The claims page planned for v0.0.13 the connector and the operations packaging (#735, #638, #644, #645), which shipped, beside work the v0.0.14 milestone holds. It now has a v0.0.13 section and plans v0.0.14.
60. The regulatory status page planned the national route in #524 and put the remaining EHDS issues in the v0.0.13 milestone, and the rights page called the Art 7(2) route planned. Both now say the FHIR face serves a national connector, and the remaining issues are in the v0.0.14 milestone.
61. The threat model called the OTLP export plain gRPC with #644 open, and left egress to the deployment pending #638. An https:// collector is now reached over TLS with mutual TLS on request, and the Kubernetes package’s egress component restricts egress; the row and both residual risks now say so.
62. The clinical safety risk file kept I-03 open on #808 and #1213, both closed by v0.0.13. The release’s review row names what keeps it open: the medical alert and the functional status, which no openEHR content feeds yet.
63. llms.txt did not name the national connector the FHIR face serves. It now does.

No text suggested a use outside the intended purpose, (c).

Findings of 2026-10-28

The review at the v0.0.14 cut. Read in full: README.md, llms.txt, CITATION.cff, the landing page, the Evaluate pages written by hand, the instructions for use, the Upgrading page and the assembled release notes. Every other page of the book, SUPPORT.md, SECURITY.md and the README of each crate was searched for “planned”, “v0.0.14”, “cross-reference” and the issues the v0.0.14 milestone closed next to a statement that the work is still to come.

Stale or wrong statements, which read as claims about the release a user runs:

64. README.md named v0.0.13 as current. It now names v0.0.14.
65. The landing page named v0.0.13 as current and said v0.0.14 brings prescriptions from openEHR medication data (FerroHEALTH/FerroBRIDGE#1322), which this release does not ship. It now names v0.0.14, has a card for what it ships, and plans no prescription mapping in FerroFED.
66. The claims page planned for v0.0.14 the other priority categories and the prescription mapping, which move to FerroBRIDGE with the interoperability component (#813). It now has a v0.0.14 section, says where that work is built, and lists the re-checks that wait on the EU apart.
67. The regulatory status page put the remaining EHDS issues in the v0.0.14 milestone. It now says which wait on an adopted act and that the prescription mapping moves to FerroBRIDGE.
68. llms.txt planned the further categories without saying where, and did not say the gateway keeps no patient index (#1377). It now says both.

Against Art 28(b), a limitation left out:

69. A draft EU declaration of conformity carried the Annex IV point 4 statement of conformity under a banner that said only “Not issued”. The draft now says it claims no conformity, that no conformity assessment has been carried out and that the Article 40 testing environment does not exist yet (#940).

No text suggested a use outside the intended purpose, (c).

Findings of 2026-10-30

The review at the v0.0.15 cut. Read in full: README.md, llms.txt, CITATION.cff, the landing page, the Evaluate pages written by hand, the instructions for use, the Upgrading page and the assembled release notes. Every other page of the book, SUPPORT.md, SECURITY.md and the README of each crate was searched for “planned”, “v0.0.15”, “v0.0.16”, the configuration keys and health routes the release renames, and the issues the v0.0.15 milestone closed next to a statement that the work is still to come.

Stale or wrong statements, which read as claims about the release a user runs:

70. README.md named v0.0.14 as current. It now names v0.0.15.
71. The landing page named v0.0.14 as current. It now names v0.0.15 and has a card for what it ships.
72. The claims page planned the rest of the conformity work for v0.0.15, which the v0.0.16 milestone holds (#525, #940). It now has a v0.0.15 section and plans v0.0.16, with the gateway half of the categories FerroBRIDGE maps (#1403 to #1406).
73. The claims page’s v0.0.14 section gave no release date. It now says 2026-10-28.

Against Art 28(b), a limitation left out:

74. The instructions for use did not say that the gateway keys this release moves out of [server] are read for one release only. Their maintenance table now says FerroFED 0.0.16 refuses them, and the Upgrading page has notes for v0.0.15 (#1408).

No text suggested a use outside the intended purpose, (c).

Findings of 2026-11-05

The review at the v0.0.16 cut. Read in full: README.md, llms.txt, CITATION.cff, the landing page, the Evaluate pages written by hand, the instructions for use, the Upgrading page, the new Laboratory reports over FHIR page and the assembled release notes. Every other page of the book, SUPPORT.md, SECURITY.md and the README of each crate was searched for “planned”, “v0.0.16”, “v0.0.17”, the laboratory report, the map mode, the configuration keys the release refuses, and the issues the v0.0.16 milestone closed next to a statement that the work is still to come.

Stale or wrong statements, which read as claims about the release a user runs:

75. README.md named v0.0.15 as current. It now names v0.0.16.
76. The landing page named v0.0.15 as current. It now names v0.0.16 and has a card for what it ships.
77. The claims page planned discharge reports and imaging for v0.0.16, which the v0.0.17 milestone holds (#1405, #1406). It now has a v0.0.16 section and plans them for v0.0.17.
78. The information sheet named eehrxf =0.1.142, and the pin matrix named eehrxf, fhirconnect, openehr-mapping-core and ferrobridge-validator at the versions before #1551 and #1590, behind the root Cargo.toml. Both now name the pins the release builds with.
79. The information sheet had no row for the HL7 Europe Laboratory Report package and said the gateway serves only the patient summary and serves prescriptions only through members that serve them. It now lists the package, says the gateway serves laboratory reports, and names the map mode.

Against Art 28(b), a limitation left out:

80. The instructions for use did not say that a console whose [oidc] names issuer alone needs the identity provider reachable at its start. Their maintenance table now says so, and the Upgrading page has the note for v0.0.16 (#1504).
81. The instructions for use described the laboratory reports the gateway writes and not the reports a member serves itself, which are listed as the member holds them. Their limitations now link the new page (#1404).

No text suggested a use outside the intended purpose, (c).

Findings of 2026-11-09

The review at the v0.0.17 cut. Read in full: README.md, llms.txt, CITATION.cff, the landing page, the Evaluate pages written by hand, the instructions for use, the Upgrading page, the Discharge reports and Imaging reports over FHIR pages and the assembled release notes. Every other page of the book, SUPPORT.md, SECURITY.md and the README of each crate was searched for “planned”, “v0.0.17”, “v0.0.18”, the discharge and imaging reports, the national contact point, the configuration keys the release refuses, and the issues the v0.0.17 milestone closed next to a statement that the work is still to come.

Stale or wrong statements, which read as claims about the release a user runs:

82. README.md and the landing page named v0.0.16 as current. Both now name v0.0.17, and the landing page has a card for what it ships.
83. The release notes, the information sheet and the Receiving a document page said the gateway receives imaging reports. The component maps them, but a Medical-Imaging [[fhir.receive]] entry refuses the start until the gateway’s package set holds the imaging package’s dependency closure (#1716). The notes, the sheet’s table of the categories received and the page now say so, and the Annex II checklist’s point 2.2 no longer counts imaging.
84. The claims page planned discharge reports and imaging for v0.0.17 and cited their closed issues as remaining work. It now has a v0.0.17 section and plans the receipt of an imaging report for v0.0.18.
85. The regulatory status page, the rights page and the Chapter III record named discharge reports and imaging as a gap with no interface, citing #1405 and #1406, both closed. They now say what is served and received, and cite #1716 and #1794.
86. The MyHealth@EU self-assessment rows 08 and 08.01 said the face serves no laboratory, discharge or imaging document. They are marked not-assessed until they are read again against the catalogue (#1795).
87. The pin matrix named ihe-atna and ehds-logging at 0.4.0, behind the root Cargo.toml at 0.8.0. It now names the pins the release builds with, and the information sheet adds the HL7 Europe Imaging Report and Hospital Discharge Report packages.
88. The Receiving a document page and the clinical safety review of 2026-11-06 left the rating of a received discharge or imaging report’s lost content to #1405 and #1406, which closed with the served reports rated and the received ones not. The page and the release’s review row now say the rating is open (#1794).

Against Art 28(b), a limitation left out:

89. The instructions for use said imaging and discharge reports are neither produced nor received. Their limitations now say what the gateway writes, lists and receives of each, with hazards I-19 and I-20 and the imaging receipt that waits.
90. The instructions for use did not name the keys 0.0.17 refuses. Their maintenance table now does, with the Upgrading page’s notes for v0.0.17.
91. The instructions for use did not name the backup of FerroFED’s own store or the rotation of a node grant’s private key, both new with this release. Their maintenance table now names both.

No text suggested a use outside the intended purpose, (c).

Findings of 2026-11-11

The review at the v0.0.19 cut. Read in full: README.md, CITATION.cff, the information sheet, the claims page, the instructions for use, the Upgrading page, the clinical safety risk file’s hazards I-20 to I-22 and the assembled release notes. Every other page of the book and README.md was searched for “planned”, “v0.0.18”, “v0.0.19”, the imaging report’s receipt, the FerroPIX and ferrohealth-smart versions and the keys the release moves, next to a statement that the work is still to come.

Stale or wrong statements, which read as claims about the release a user runs:

92. The information sheet said the gateway receives each category but the imaging report. It now says each is received, as its table of the categories received already did (#1716).
93. The claims page had no section for the release. It now has one for v0.0.19.
94. Hazard I-22 named the declaration of what a received imaging report loses as planned. The risk file now names it as a control in place, every loss declared to the sender, and keeps the hazard open at S4, P3 because no reader of the member’s record is told (#1827, #1838).

Against Art 28(b), a limitation left out:

95. The instructions for use did not name the keys 0.0.19 moves, or that the keys 0.0.18 refused by name are now refused as unknown keys. Their maintenance table now does, with the Upgrading page’s notes for v0.0.19.

No text suggested a use outside the intended purpose, (c).

Findings of 2026-11-12

The review at the v0.0.20 cut. Read in full: README.md, CITATION.cff, the information sheet, the claims page, the instructions for use, the Upgrading page, the page on receiving documents, the onward credentials page, the clinical safety risk file’s hazards I-21 and I-22 and L-03 and L-04, and the assembled release notes. Every other page of the book and README.md was searched for “planned”, “v0.0.19”, “v0.0.20”, FerroEHR 5.6, a Basic user at a node, the IUA extension and authorization_details, the performing organization, the eehrxf, ehds-logging, FerroPIX and ferrohealth-smart versions and the keys the release removes, next to a statement that the work is still to come.

Stale or wrong statements, which read as claims about the release a user runs:

96. The information sheet named the interoperability component as eehrxf 0.3.2, and seven rows of docs/VERSIONS.md named the component and audit crates of releases ago. Both now name the root Cargo.toml requirements, eehrxf 0.7.0 among them, and scripts/checks/versions.sh fails when one drifts again (#1874).
97. The instructions for use and the page on receiving documents said a received imaging report keeps its performing organization only in the original document, and that the answer names none of a received report’s losses. Both now say the organization reaches the member’s composition and each loss is declared to the sender and told to no reader of the member’s record (#1827, #1860).
98. The release notes said a deployment adds a FerroEHR node’s persons issuers “from this release” without naming the release. They and the onward credentials page now name v0.0.20 as the first FerroFED release that reaches a FerroEHR node under the caller (#1615).
99. The claims page had no section for the release. It now has one for v0.0.20.

Against Art 28(b), a limitation left out:

100. The instructions for use did not name the [[auth.attributes]] table a purpose-of-use issuer needs from 0.0.20, the imaging template it needs, or that the keys 0.0.19 refused by name are now refused as unknown keys. Their maintenance table now does, with the Upgrading page’s notes for v0.0.20.

No text suggested a use outside the intended purpose, (c).

Annex II, point 2.5

Point 2.5 binds the harmonised software components, which are partly built (Regulatory status). The patient summary of the FHIR face runs on the same query path, and the rest of the interoperability component is planned on it (#522), so the features of that path that can stop or delay an answer are assessed here, with Art 7(1), which names the manufacturers of the systems a healthcare provider uses. The Annex II checklist takes its reasoning for point 2.5 from this section.

The completeness default

A federated query is all-or-nothing by default: when a member that was asked does not answer, the query fails 504 or 424 with no rows, and meta.federation names every member with its status (§11.4, N37). A client that accepts a partial answer asks for one per request with openEHR-federation-completeness: partial, and gets the rows of the members that answered, with every missing member named (Completeness).

Assessment: no undue burden. The default is the one the Federation Tier specification requires (N37), and it keeps a clinician from reading part of a record as the whole of it, which Annex II, point 1.1, asks of an EHR system (“does not put at risk patient safety”). Access is not withheld: the partial answer is one header away, and both answers name what is missing. Two settings can turn the default into a burden, and the instructions for use say so:

• [federation] best_effort = false withdraws the partial answer, so one silent member blocks every answer. Keep the default, true.
• A node’s consent refusal fails the query 424 until its codes are listed in consent_refusal_codes (Consent). List them for every node that refuses on consent.

The budgets

A member’s request has per_node_timeout (10 seconds by default) and the whole fan-out overall_timeout (25 seconds); a client may shorten the wait, never lengthen it (Timeouts). The gateway serves at most max_concurrent_requests at once and answers 503 with Retry-After past it, may rate-limit each caller with 429 and Retry-After, and sends a member at most max_in_flight_per_node requests at once (Overload protection).

Assessment: no undue burden. The budgets bound how long one request or one slow member can hold the gateway, so one caller cannot take access away from the others. Every limit is configurable, the time budget is declared in OPTIONS {base}/, the per-caller rate is off by default and the same for every caller, and a refused request gets a status and a Retry-After that say when to try again. A deployment that sets the limits below what its members need can delay access; the instructions for use give the sizing.

The consent pre-filter

The pre-filter is optional and off by default. It leaves out a member only where the consent service denies the request, which carries out a restriction the person chose (Art 8). When the consent service cannot answer, every candidate is asked and each node checks consent itself (§13.2.1, N27a) (Consent).

Assessment: no undue burden. The pre-filter removes access only where the person restricted it, and its outage never blocks an answer. A deployment in the EU sets [federation.consent] disclose = false, so an exclusion is not shown to the healthcare provider (Withholding consent exclusions).

Art 7(1): transmission without hindrance

FerroFED holds no clinical data of its own: a record stays at the member CDR that holds it. A write goes, as the client sent it, to the member that controls the record, or for a new object to the member the client names (§12.4, N22, N23), and a routed read comes back as the node answered. The gateway adds no fee, no export limit and no format of its own to either. Exporting the gateway’s own state for a replacement product is Annex II, point 2.6: an operator exports the routing state the gateway learned with POST /admin/identity-state/export (Exporting the identity state), and the access records are exported from the Audit Record Repository.

Conformance statement

FerroFED claims the Federation-Gateway profile of the Federation Tier with AQL specification, at the version and commit the claim table names. This page is that claim. It names the specification text the claim is made against, the node products the tests ran against, every conformance point of §17 and every test track of §16.3 with how each is scored, and every deferral with its reason.

The part between the statement markers is rendered by scripts/conformance/matrix.sh --statement-write-into when the site is built, from the conformance matrix, docs/VERSIONS.md, the vendored specification and the // conformance: markers on the tests. The docs build and the conformance-matrix guard both fail when it disagrees with them, so the statement cannot claim more than the matrix holds. The conformance matrix shows the same points by requirement, and the obligations checklist covers every normative statement of the text.

What the claim covers

• Scored by a test means at least one test carries the point’s marker and CI runs it. The conformance tests page lists each test by point and track. A test in an e2e module runs in the CI e2e job, with FERROFED_E2E=1, against the node products below.
• The Federation-Gateway profile only. FerroFED holds no clinical data and is not a CDR, so it makes no Federation-Node claim. A point whose actor is Node or Operator is scored against that actor, and a gateway is not marked down for it (§17, §16.2). FerroFED assists those actors with the node profile checks and the admission check, and the last section of the generated part records what each found.
• CP-20 and CP-39 are tested without a marker. A marker on a Node or Operator point belongs to a harness check under tools/, which writes the finding the report reads. The gateway’s part of each is tested in its own crate: the registry load refuses an endpoint with a FHIR connection type (CP-20, app/ferrofed-registry/tests/it/refusal.rs::a_fhir_rest_connection_type_is_refused), and the book answers each §13.4 deployment decision in a section of its own (CP-39, app/ferrofed-server/tests/it/deployment_decisions.rs).
• A deferral is the owner’s decision, recorded on the issue its row names, with the reason the specification gives for it.

The claim

The nodes

The scored matrix

Deferrals

Track 8

• Actor: Gateway: no conformance point scores the track (§16.3), and N3 falls in the Federation-Gateway profile (§16.2)
• Requirements: N3
• Decision: provisional in section 16.3, and section 18 lets its subject matter be deferred; the binding lifetime, the invalidation hook and the PMIR ITI-94 subscription that drives it from ITI-93 merges are built (#48, #147), and propagation to a later resolution is not claimed
• Recorded on: #48, #147

Points scored against another actor

• CP-18, Node: a Node obligation, scored against the harness CDR products and never the gateway (section 16.2); the gateway’s node profile checks assist it, which the harness runs against its products and conformance run –node-profile against each member of a deployment: they ask FerroEHR and EHRbase for an EHR they do not hold and for an unparsable query and read the ITS-REST error status, and read whether an EHR the node withholds from one principal is refused on GET /ehr/{ehr_id} and on both ehr_id-scoped query forms while it is served to another: FerroEHR started with Basic authentication and authz.rbac.ehr_access_default restricted withholds every EHR from a clinician, and EHRbase started with Basic authentication withholds the request path of one EHR from its user role through security.additionalAuthorizations, its narrowest access control; FerroEHR from 4.3.3 refuses that EHR on the read and on both query forms (FerroEHR #3562, #566), and EHRbase refuses the read and releases the EHR’s rows on both query forms; the verdicts are the report node class per product, never a gateway pass, and no specification governs the choice of products: our own design (#83, #93, #549, #573).
• CP-19, Node: a Node obligation, scored against the harness CDR products and never the gateway (section 16.2); the node profile consent check reads a consent refusal an operator arranges at the node, on the read and on both ehr_id-scoped query forms; at FerroEHR the harness arranges a restriction of processing (GDPR Art. 18) through the node’s ADMIN API, outside ITS-REST, and the restriction check reads the restricted composition withheld on the read and the composition query, and the federated query through the gateway leaves it out (#1389); EHRbase records no consent decision, and ITS-REST defines no consent resource, so the point reads node-not-observable there; the gateway half is CP-36, and no specification governs the choice of products: our own design (#83, #93, #549, #573, #1389).
• CP-20, Operator: verified at admission or in the registry, not on a request (section 16.2); the gateway assists: its registry load refuses a Query API endpoint whose connectionType is hl7-fhir-rest or no defined code (#74).
• CP-27, Node: a Node obligation, scored against the harness CDR products and never the gateway (section 16.2); the gateway’s node profile checks assist it, which the harness runs against its products and conformance run –node-profile against each member of a deployment, against FerroEHR and against EHRbase: whether the node serves an EHR, its EHR_STATUS and its compositions by the ehr_id alone, with no patient identifier in any request the capturing proxy journals, whether an EHR created with no EHR_STATUS is read and queried by its ehr_id, and the ehr_id exchange the admission check reports over a PIXm Manager stub; the verdicts are the report node class per product, never a gateway pass, and no specification governs the choice of products: our own design (#93, #549, #573).
• CP-33a, Operator: verified at admission or in the registry, not on a request (section 16.2); the gateway assists: ferrofed admission check reports each identifier-integrity condition of section 12b.2 as pass, fail or cannot-check with its evidence, and the registry load refuses a second member with an existing system_id; the harness applies the check as the operator of track 11 to a FerroEHR candidate sharing a member’s system_id (#91); the node profile runs the same check against a FerroEHR member and an EHRbase member, each under a system_id of its own, and records each condition with its evidence (#93, #549) (#79, #91, #93, #549).
• CP-39, Operator: verified at admission or in the registry, not on a request (section 16.2); FerroFED’s own answers to the five section 13.4 obligations, each naming the configuration that changes it, and the operator’s template are the book page website/book/src/operate/deployment-decisions.md, held to one section per obligation by app/ferrofed-server/tests/it/deployment_decisions.rs (#84).

Not observable

Some obligations cannot be observed from outside the node that holds them.

• CP-18 and CP-19 in a deployment run. ferrofed conformance run --node-profile records the CP-18 access check and the CP-19 consent check as not-observable. The refusal under test is the node’s own access policy or consent decision, which an operator cannot arrange through ITS-REST, and ITS-REST defines no consent resource (Scoring a deployment).
• CP-18 in the harness. The harness starts FerroEHR and EHRbase with an access policy that withholds one EHR from one principal, and its checks read the node’s answer on the read and on both ehr_id-scoped query forms.
• CP-19 in the harness. Neither product records a consent decision, so the harness arranges no consent refusal and the point reads node-not-observable for both. The gateway’s own part of consent is CP-36 and track 7, both scored by tests (N27, N27a).
• Track 10 in a deployment run. The run reports it not-run, because only node-side wire capture shows what reached a node (§16.3). The harness scores it with a capturing proxy in front of each node.

Where the specification disagrees with itself

CP-14 scores N22: a follow-up read of a version is routed on its creating_system_id first. The EHR-scoped rule of §12a.1 routes every request under {base}/v1/ehr/{ehr_id}/… on the ehr_id binding, “not on creating_system_id”, and N41 orders the steps for every path ehr_id (§12.5.1). Every ITS-REST version read sits under a path ehr_id, so the two rules disagree for every such read. FerroFED routes by N41, scored under CP-13 and CP-33, and defers CP-14 until the text settles it. The other half of N22, that a uid is never rewritten, is held by tests the obligations checklist names.

Every defect, contradiction or silence found in a specification while scoring is reported on the standing upstream-reports issue, #212. That includes the findings of the differential run (#94), which sent the same Connectathon requests to FerroFED and to the reference implementation over the same FerroEHR nodes and judged each difference against the specification text.

Rerunning the suite

The record, offline: the matrix against the vendored specification, every marker, and the generated pages.

bash scripts/checks/conformance-matrix.sh

The tests, and then the per-track and per-point report of a run over the whole workspace with the e2e harness, which needs Docker. The report lands in target/conformance/report.md.

cargo nextest run --workspace --locked --all-features
scripts/conformance/report.sh --run

To score your own deployment, run ferrofed conformance run (Scoring a deployment).

After a change to a status or a pin, render the matrix page again. The statement and the tests page are rendered when the site is built, so a new marker needs nothing; scripts/site/assemble.sh shows them locally:

scripts/conformance/matrix.sh --render-write

When the specification is re-pinned

The pinned text is the 1.0.0 release, re-pinned from the 0.9.0 release candidate (#17); the release moved no point, requirement or track. When a later release is pinned, scripts/conformance/matrix.sh --derive refreshes the derived columns. A point new to the text arrives planned, and the guard refuses it until the re-pin scores it with a test or records the owner’s deferral. This statement then names the new version and commit. CP-14 and the other choices the reports on #212 bear on are revisited against the 1.0.0 text (#354).

Conformance tests

Every test that carries a // conformance: marker, under each point and track the marker names, grouped by file. A file marked (e2e) runs in the e2e harness, with FERROFED_E2E=1, against the node products the conformance statement names. A point or track with no marked test is not listed.

CP-1

10 tests.

• app/ferrofed-server/tests/it/e2e/crossref.rs (e2e): one_result_set_over_two_cdr_nodes_and_no_identifier_on_the_wire
• app/ferrofed-server/tests/it/e2e/track1.rs (e2e): an_unmodified_client_gets_one_single_cdr_shaped_result_set
• app/ferrofed-server/tests/it/facade/query.rs: a_patient_query_is_one_result_set_over_both_nodes
• app/ferrofed-server/tests/it/query_get.rs: a_client_ehr_id_in_the_query_string_is_dropped, a_malformed_query_string_is_a_400_body_invalid_that_asks_nobody, a_malformed_stored_get_query_string_is_a_400_body_invalid_that_asks_nobody, a_quoted_get_parameter_binds_the_string_a_post_body_binds, a_stored_get_reads_a_q_key_as_a_query_parameter, a_stored_query_runs_by_get_with_and_without_a_version, get_and_post_send_every_node_the_same_request_and_answer_the_same

CP-2

4 tests.

• app/ferrofed-server/tests/it/e2e/crossref.rs (e2e): one_result_set_over_two_cdr_nodes_and_no_identifier_on_the_wire
• app/ferrofed-server/tests/it/e2e/track1.rs (e2e): an_unmodified_client_gets_one_single_cdr_shaped_result_set
• app/ferrofed-server/tests/it/e2e/track2.rs (e2e): the_pix_manager_resolves_both_carriers_to_each_nodes_own_ehr_id
• app/ferrofed-server/tests/it/facade/query.rs: a_patient_query_is_one_result_set_over_both_nodes

CP-38

5 tests.

• app/ferrofed-server/tests/it/e2e/crossref.rs (e2e): both_patient_carriers_resolve_to_the_same_rows_over_two_cdr_nodes
• app/ferrofed-server/tests/it/e2e/track2.rs (e2e): the_pix_manager_resolves_both_carriers_to_each_nodes_own_ehr_id
• app/ferrofed-server/tests/it/outbound.rs: a_clinician_predicate_reaches_the_node_unchanged
• crates/openehr-federation/tests/it/aql/entry.rs: both_carriers_rewrite_the_same_patient_query_to_the_same_node_query
• crates/openehr-federation/tests/it/aql/guard.rs: a_clinician_or_facility_predicate_is_dispatched_unchanged

CP-3

13 tests.

• app/ferrofed-identity/tests/it/pixm.rs: a_member_whose_domain_holds_nothing_does_not_know_the_patient, an_unknown_patient_is_unknown_at_every_member, one_call_resolves_the_patient_at_every_member_by_its_domain
• app/ferrofed-server/tests/it/ask_all.rs: an_undirected_patient_query_over_three_members_dispatches_to_the_two_that_resolve
• app/ferrofed-server/tests/it/e2e/pixm.rs (e2e): a_patient_fed_at_both_members_resolves_through_pix_at_both, a_pix_resolved_query_asks_only_the_member_that_knows_the_patient
• app/ferrofed-server/tests/it/e2e/santempi.rs (e2e): a_patient_each_member_fed_to_santempi_is_answered_by_both
• app/ferrofed-server/tests/it/e2e/track2.rs (e2e): the_pix_manager_resolves_both_carriers_to_each_nodes_own_ehr_id
• app/ferrofed-server/tests/it/identity_grant.rs: the_manager_is_asked_with_a_token_the_grant_obtained_and_refreshed
• app/ferrofed-server/tests/it/pdqm/flow.rs: an_iti_119_match_finds_the_master_identity_the_pix_manager_resolves, an_iti_78_search_finds_the_master_identity_the_pix_manager_resolves
• app/ferrofed-server/tests/it/resolution.rs: one_pix_call_resolves_the_patient_and_both_members_answer, the_identifier_and_namespace_reach_the_pix_manager_and_no_node

CP-4

3 tests.

• app/ferrofed-server/tests/it/e2e/crossref.rs (e2e): one_result_set_over_two_cdr_nodes_and_no_identifier_on_the_wire
• app/ferrofed-server/tests/it/e2e/track2.rs (e2e): the_pix_manager_resolves_both_carriers_to_each_nodes_own_ehr_id
• app/ferrofed-server/tests/it/facade/query.rs: a_patient_query_is_one_result_set_over_both_nodes

CP-5

50 tests.

• app/ferrofed-engine/tests/it/fanout/localization.rs: a_localizer_failure_is_carried_in_meta_federation_and_on_every_endpoint, a_localizer_that_answered_leaves_no_localization_member
• app/ferrofed-identity/tests/it/atna.rs: a_full_spool_fails_the_discovery_closed
• app/ferrofed-identity/tests/it/nvi_directory.rs: the_directory_maps_each_custodian_to_its_members
• app/ferrofed-identity/tests/it/nvi_localizer.rs: a_refusing_service_fails_the_localization_closed_with_its_status, a_silent_service_runs_out_the_budget, the_members_holding_the_returned_custodians_are_the_candidates
• app/ferrofed-identity/tests/it/pixm_localizer.rs: a_manager_that_fails_leaves_the_localization_unavailable, a_patient_the_manager_does_not_know_has_no_records, the_candidates_are_the_members_whose_domain_holds_the_patient, the_resolution_of_the_same_query_reuses_the_localization_call
• app/ferrofed-identity/tests/it/xcpd.rs: a_community_outside_the_federation_adds_no_member, a_discovery_whose_audit_is_not_stored_by_the_deadline_fails_closed_in_time, a_discovery_whose_audit_is_refused_fails_closed, a_silent_gateway_runs_out_the_budget, an_audit_failure_outranks_another_gateway_s_timeout, no_match_anywhere_is_no_records, one_failing_gateway_fails_the_whole_discovery_closed, the_communities_a_broadcast_names_are_the_candidates
• app/ferrofed-server/tests/it/audit_repository.rs: a_full_spool_fails_the_query_closed_and_asks_no_member
• app/ferrofed-server/tests/it/e2e/track3.rs (e2e): an_undirected_query_asks_only_the_members_the_localizer_names
• app/ferrofed-server/tests/it/e2e/xcpd.rs (e2e): an_undirected_query_asks_only_the_member_ferropix_names_over_iti_55
• app/ferrofed-server/tests/it/localization.rs: a_directed_query_is_never_localized, a_localizer_silent_past_its_budget_fails_closed, a_localizer_that_finds_no_records_leaves_every_member_not_localized_without_error, a_localizer_that_is_down_fails_closed_dispatches_nothing_and_names_its_error, a_member_the_localizer_does_not_name_is_not_localized_and_never_asked, an_undirected_query_that_names_no_patient_is_refused_under_localization, ask_all_on_failure_asks_every_member_only_where_it_is_declared, the_fixed_cross_reference_localizes_to_the_members_that_know_the_patient, without_the_declaration_a_failed_localizer_is_never_widened_to_ask_all
• app/ferrofed-server/tests/it/localizer_audit.rs: a_discovery_still_recording_its_audit_at_the_budget_fails_closed_under_ask_all
• app/ferrofed-server/tests/it/localizer_surface.rs: a_localizer_outage_still_widens_under_a_declared_ask_all, a_subject_no_member_holds_by_localization_is_no_destination, a_targeted_read_by_subject_is_never_localized, an_unaudited_exchange_fails_closed_even_under_ask_all, an_unaudited_read_by_subject_fails_closed_even_under_ask_all, the_read_by_subject_asks_every_member_when_ask_all_is_declared, the_read_by_subject_asks_only_the_members_the_localizer_names, the_read_by_subject_fails_closed_when_the_localizer_does_not_answer
• app/ferrofed-server/tests/it/nl_gf.rs: a_member_the_nvi_leaves_out_is_not_localized_and_complete_holds, an_nvi_that_does_not_answer_fails_the_query_closed, the_pseudonymised_walkthrough_runs_end_to_end_and_no_node_sees_the_pseudonym
• app/ferrofed-server/tests/it/nvi_nuts.rs: a_refused_nuts_grant_fails_the_localization_closed, the_nvi_is_asked_with_the_dpop_bound_nuts_token
• app/ferrofed-server/tests/it/pixm_localizer.rs: a_pix_manager_that_does_not_answer_fails_the_query_closed, the_members_whose_domain_holds_the_patient_are_asked_over_one_iti_83_call
• app/ferrofed-server/tests/it/registry_mcsd/lrza.rs: the_custodians_come_from_the_directory_without_a_table
• app/ferrofed-server/tests/it/xcpd.rs: a_failing_gateway_fails_the_query_closed_and_asks_no_member, the_communities_xcpd_discovers_select_the_members_asked

CP-6

22 tests.

• app/ferrofed-server/tests/it/directive.rs: a_directed_aggregate_to_one_endpoint_reaches_it_unchanged, a_directed_subject_query_reports_unlisted_members_excluded_and_unknown_ones_not_resolved, a_selected_endpoint_attribute_is_added_to_the_rows_and_asked_of_no_node, an_endpoint_the_registry_does_not_know_is_refused_400_before_any_node_is_asked, no_node_receives_the_directive_and_each_receives_the_undirected_node_query, the_organisation_selector_asks_every_endpoint_the_organisation_manages
• app/ferrofed-server/tests/it/e2e/track3.rs (e2e): a_directive_selects_the_node_set_and_leaves_the_row_shape_alone, a_named_member_where_the_patient_does_not_resolve_is_reported_not_errored
• app/ferrofed-server/tests/it/fhir/native.rs: a_directive_naming_the_native_endpoint_is_refused_400, a_targeting_header_naming_the_native_endpoint_is_refused_400
• app/ferrofed-server/tests/it/localization.rs: a_directed_query_is_never_localized
• app/ferrofed-server/tests/it/localizer_surface.rs: a_targeted_read_by_subject_is_never_localized
• app/ferrofed-server/tests/it/targeting.rs: a_header_and_a_directive_that_differ_are_refused_400_naming_both_sets, a_header_and_a_directive_that_select_the_same_set_proceed, the_endpoint_header_selects_the_node_set_as_the_directive_does
• crates/openehr-federation/tests/it/aql/directive.rs: a_directed_aggregate_to_one_endpoint_is_dispatched_unchanged_and_to_two_is_refused, a_directed_patient_query_reaches_the_node_as_the_undirected_one_does, an_undefined_function_directed_to_one_endpoint_passes_and_to_two_is_refused, an_unscoped_query_selecting_only_endpoint_attributes_asks_each_node_one_ehr_column, the_directive_is_lifted_out_with_its_kind_and_identifiers_in_order, the_organisation_selector_never_reaches_a_node
• crates/openehr-federation/tests/it/aql/golden.rs: golden_case_02_keeps_the_directive_and_its_projections_out_of_the_node_query

CP-7

2 tests.

• app/ferrofed-server/tests/it/e2e/track2.rs (e2e): a_selected_subject_column_is_the_input_and_never_asked_of_a_node
• app/ferrofed-server/tests/it/facade/query.rs: a_patient_query_is_one_result_set_over_both_nodes

CP-8

55 tests.

• app/ferrofed-engine/tests/it/fanout/distinct.rs: a_cut_node_returning_one_value_twice_fails_the_query_424, a_row_two_nodes_return_takes_one_slot_of_the_limit
• app/ferrofed-engine/tests/it/fanout/order.rs: interleaved_node_answers_merge_into_the_global_top_n
• app/ferrofed-server/tests/it/distinct.rs: a_duplicate_straddling_the_page_edge_is_answered_once, without_distinct_the_duplicate_is_answered_twice
• app/ferrofed-server/tests/it/e2e/track5.rs (e2e): duplicates_pass_through_by_default_and_distinct_folds_them_at_the_tier, order_by_and_limit_return_the_global_top_rows_deterministically
• app/ferrofed-server/tests/it/endpoint_attributes.rs: under_distinct_a_shared_organisation_collapses_the_rows, under_distinct_an_endpoint_id_keeps_the_rows_of_two_endpoints_apart
• app/ferrofed-server/tests/it/order.rs: a_distinct_function_of_an_unselected_path_under_a_limit_is_refused_400, a_distinct_function_of_selected_paths_returns_the_same_rows_on_every_repeat, a_distinct_whole_object_under_a_limit_is_refused_400, the_client_gets_the_global_top_n_without_the_hidden_column
• crates/openehr-federation/tests/it/aql/comparable.rs: under_distinct_a_bounded_page_with_a_whole_rm_object_is_refused, under_distinct_a_limit_on_an_incomparable_order_by_key_is_refused, under_distinct_a_limit_with_a_collection_is_refused, under_distinct_a_limit_with_a_dv_text_is_refused, under_distinct_a_limit_with_a_path_the_rm_does_not_resolve_is_refused, under_distinct_a_limit_with_a_whole_rm_object_is_refused, under_distinct_a_limit_with_an_element_value_is_refused, under_distinct_a_limit_with_ordered_data_values_and_primitives_is_pinned, under_distinct_with_no_limit_an_incomparable_path_is_not_a_key
• crates/openehr-federation/tests/it/aql/dedup.rs: under_distinct_a_selected_uid_is_the_dedup_key, under_distinct_an_unselected_uid_is_not_added
• crates/openehr-federation/tests/it/aql/distinct.rs: a_re_injected_subject_column_is_not_compared, every_selected_column_of_an_unscoped_query_is_compared, the_column_kept_for_a_subject_only_query_is_not_compared
• crates/openehr-federation/tests/it/aql/order.rs: under_distinct_a_bounded_page_with_an_unpinned_function_is_refused, under_distinct_a_function_of_selected_paths_is_pinned_by_them, under_distinct_a_limit_with_a_function_of_an_unselected_path_is_refused, under_distinct_a_limit_with_a_value_from_outside_the_row_is_refused, under_distinct_an_unpinned_function_with_no_limit_is_answered
• crates/openehr-federation/tests/it/attributes.rs: distinct_on_attributes_alone_keeps_one_row_per_value_and_refuses_no_cut_node, under_distinct_a_shared_attribute_value_collapses_the_rows, under_distinct_rows_of_two_endpoints_are_two_values
• crates/openehr-federation/tests/it/dedup/distinct.rs: outside_dedup_distinct_compares_a_uid_as_sent, under_dedup_a_node_cut_on_two_case_variants_is_refused, under_dedup_distinct_folds_case_beside_the_endpoint_attributes, under_dedup_distinct_holds_case_variants_of_a_uid_one_value
• crates/openehr-federation/tests/it/dedup/mod.rs: dedup_runs_before_distinct_so_the_distinct_row_is_the_originating_copy
• crates/openehr-federation/tests/it/distinct.rs: a_column_the_client_does_not_see_never_makes_rows_distinct, a_cut_node_holding_two_equal_rows_is_refused, a_data_value_is_one_value_whatever_the_order_of_its_members, a_duplicate_from_two_nodes_collapses_under_distinct_and_stays_without_it, a_duplicate_straddling_a_page_edge_takes_one_slot, a_number_written_two_ways_is_one_value, an_uncut_node_holding_two_equal_rows_is_collapsed, date_times_are_one_value_only_as_one_instant_written_one_way, distinct_is_idempotent_and_leaves_no_two_rows_equal, distinct_runs_before_the_limit, distinct_with_order_by_and_a_bounded_page_is_the_page_of_the_distinct_union, distinct_without_order_by_keeps_limit_distinct_values_of_the_union, the_kept_copy_is_the_first_under_order_by_then_endpoint_id, without_order_by_a_duplicate_collapses_to_the_first_endpoint_copy
• crates/openehr-federation/tests/it/merge.rs: the_pushed_down_merge_is_the_order_and_limit_of_the_union

CP-9

46 tests.

• app/ferrofed-engine/tests/it/fanout/dedup.rs: a_failing_424_envelope_records_the_mode, a_failing_504_envelope_records_the_mode, a_version_uid_of_the_wrong_form_fails_the_query_424, by_default_the_imported_composition_comes_back_twice, under_version_identity_the_originating_copy_is_kept_and_the_copy_named
• app/ferrofed-server/src/facade/dedup.rs: a_repeated_header_is_refused, any_other_value_is_refused, each_offered_mode_is_selected_by_its_name, no_header_is_the_pass_through_default
• app/ferrofed-server/tests/it/dedup.rs: a_failing_answer_still_records_the_mode, a_recombined_aggregate_under_version_identity_is_refused, a_value_naming_no_offered_mode_is_refused_before_any_node_is_asked, none_is_accepted_explicitly, under_version_identity_one_row_comes_back_and_the_copy_is_named, without_the_header_both_copies_come_back_and_none_is_recorded
• app/ferrofed-server/tests/it/e2e/track5.rs (e2e): duplicates_pass_through_by_default_and_distinct_folds_them_at_the_tier
• crates/openehr-federation/tests/it/aql/dedup.rs: a_directed_single_node_aggregate_under_dedup_is_dispatched, a_limit_without_order_by_is_ordered_on_the_uid, a_query_that_reads_no_version_has_no_dedup_key, a_recombined_aggregate_under_dedup_is_refused, a_selected_uid_is_read_where_it_is, a_version_variable_supplies_the_uid, the_version_uid_is_asked_as_a_hidden_column, under_distinct_a_selected_uid_is_the_dedup_key, under_distinct_an_unselected_uid_is_not_added, under_order_by_the_row_key_is_the_dedup_key
• crates/openehr-federation/tests/it/dedup/distinct.rs: under_dedup_a_node_cut_on_two_case_variants_is_refused, under_dedup_distinct_folds_case_beside_the_endpoint_attributes, under_dedup_distinct_holds_case_variants_of_a_uid_one_value
• crates/openehr-federation/tests/it/dedup/mod.rs: a_row_too_short_for_its_version_column_is_refused, a_row_with_no_version_uid_is_never_suppressed, a_system_id_that_differs_from_the_creating_system_id_only_in_case_keeps_its_copy, a_version_uid_of_the_wrong_form_is_a_node_defect, by_default_both_copies_of_an_imported_composition_come_back, copies_whose_version_ids_differ_only_in_case_are_one_version_kept_as_sent, dedup_runs_before_distinct_so_the_distinct_row_is_the_originating_copy, every_row_of_the_dropped_copy_is_suppressed_and_every_row_of_the_kept_one_stays, the_record_carries_the_mode_and_under_version_identity_what_was_suppressed, two_versions_of_one_object_both_survive, under_version_identity_the_originating_copy_is_kept_and_the_copy_recorded, with_no_originating_holder_the_lowest_endpoint_id_keeps_its_copy
• crates/openehr-federation/tests/it/dedup/order.rs: a_case_variant_copy_at_a_page_edge_ranks_as_its_version_and_keeps_its_text, a_node_that_orders_uids_byte_for_byte_across_case_is_refused_at_its_cut, a_suppressed_copy_does_not_take_a_slot_of_the_limit
• crates/openehr-federation/tests/it/dedup/properties.rs: dedup_keeps_one_endpoint_per_version_and_records_exactly_what_it_dropped, dedup_with_order_by_limit_and_a_bounded_page_is_the_page_of_the_deduplicated_union

CP-10

45 tests.

• app/ferrofed-engine/tests/it/fanout/aggregate.rs: a_node_that_does_not_answer_fails_the_aggregate_504, a_recombining_plan_is_refused_best_effort_before_dispatch, a_value_the_recombination_cannot_use_fails_the_query_424, the_node_answers_recombine_into_one_row
• app/ferrofed-server/tests/it/aggregate.rs: a_failing_node_fails_the_aggregate_424_with_no_row, a_partial_request_for_a_recombined_aggregate_is_refused_400, the_client_receives_one_recombined_row_in_its_own_columns, with_nothing_declared_the_aggregate_is_refused_400
• app/ferrofed-server/tests/it/dedup.rs: a_recombined_aggregate_under_version_identity_is_refused
• app/ferrofed-server/tests/it/e2e/aggregate.rs (e2e): an_undirected_avg_is_the_mean_weighted_by_the_counts_each_node_returns
• app/ferrofed-server/tests/it/e2e/track5.rs (e2e): an_undirected_aggregate_is_recombined_or_refused_and_a_directed_one_answered
• crates/openehr-federation/tests/it/aql/aggregate.rs: a_directed_single_node_aggregate_is_dispatched_unchanged, a_distinct_count_does_not_decompose, a_function_left_out_of_the_declaration_is_refused, a_plain_column_beside_an_aggregate_is_refused, a_recombined_aggregate_is_never_answered_best_effort, an_aggregate_directed_to_two_endpoints_is_recombined, an_aggregate_naming_no_patient_is_recombined_across_every_member, an_indecomposable_aggregate_suggests_both_alternatives, avg_is_asked_of_each_node_as_its_sum_and_count, distinct_breaks_the_decomposition, every_declared_function_but_avg_is_dispatched_as_written, several_aggregates_map_to_their_node_columns, the_columns_are_the_clients_query_not_the_dispatched_one, with_nothing_declared_every_undirected_aggregate_is_refused
• crates/openehr-federation/tests/it/aql/dedup.rs: a_recombined_aggregate_under_dedup_is_refused
• crates/openehr-federation/tests/it/aql/function.rs: a_function_outside_aql_directed_to_one_endpoint_passes_through, a_function_outside_aql_directed_to_two_endpoints_is_refused, a_function_outside_aql_is_refused_before_the_aggregate_beside_it, a_function_outside_aql_is_refused_in_a_patient_query_across_nodes, a_function_outside_aql_nested_in_an_aql_function_is_refused, an_aggregate_follows_the_decomposition_rules, an_undirected_function_outside_aql_in_select_is_refused, an_undirected_function_outside_aql_in_where_is_refused, the_refusal_suggests_both_alternatives
• crates/openehr-federation/tests/it/aql/golden.rs: golden_case_06_is_refused_with_nothing_declared_and_recombined_under_the_default_set
• crates/openehr-federation/tests/it/aql/hygiene.rs: no_recombined_aggregate_query_carries_the_patient_identifier, the_avg_rewrite_reaches_the_node_without_the_patient
• crates/openehr-federation/tests/it/aql/rules.rs: an_aggregate_directed_to_one_endpoint_is_dispatched_unchanged, an_aggregate_directed_to_two_endpoints_is_refused, an_undirected_aggregate_is_refused_with_its_reason
• crates/openehr-federation/tests/it/combine.rs: a_value_of_the_wrong_kind_refuses_its_node_and_leaves_no_row, an_avg_whose_sum_and_count_disagree_refuses_its_node, every_recombined_function_is_the_aggregate_over_the_union, values_no_one_order_compares_refuse_every_node_that_holds_one

CP-11

5 tests.

• app/ferrofed-server/tests/it/e2e/track3.rs (e2e): an_undirected_query_asks_only_the_members_the_localizer_names
• app/ferrofed-server/tests/it/e2e/track4.rs (e2e): a_node_answering_an_error_fails_the_query_424_and_is_named_node_error, an_unreachable_node_fails_the_query_504_and_is_named_offline
• app/ferrofed-server/tests/it/e2e/xcpd.rs (e2e): an_undirected_query_asks_only_the_member_ferropix_names_over_iti_55
• app/ferrofed-server/tests/it/endpoint_report.rs: a_member_a_directed_query_did_not_name_is_reported_excluded_and_out_of_scope

CP-12

17 tests.

• app/ferrofed-engine/tests/it/fanout/best_effort.rs: every_node_not_resolved_is_a_200_with_no_rows_in_either_mode
• app/ferrofed-server/tests/it/completeness.rs: incompleteness_is_the_complete_flag_and_never_an_operation_outcome
• app/ferrofed-server/tests/it/e2e/track4.rs (e2e): a_node_answering_an_error_fails_the_query_424_and_is_named_node_error, a_slow_node_is_abandoned_at_the_per_node_timeout_and_named_time_out, an_unreachable_node_fails_the_query_504_and_is_named_offline, found_nowhere_and_consent_denied_are_200_and_never_424
• app/ferrofed-server/tests/it/errors.rs: a_node_error_under_all_or_nothing_is_a_424_carrying_the_envelope, a_node_not_found_inside_a_fan_out_is_a_node_error_and_a_424, a_node_timing_out_under_all_or_nothing_is_a_504_carrying_the_envelope, a_node_timing_out_under_best_effort_is_a_200_reporting_it, an_invalid_request_is_a_400_with_its_code_and_quotes_nothing, an_unreachable_node_under_all_or_nothing_is_a_504_carrying_the_envelope
• app/ferrofed-server/tests/it/fhir/unresolved.rs: a_list_for_a_patient_no_member_holds_is_empty, a_prescription_search_for_a_patient_no_member_holds_is_empty
• app/ferrofed-server/tests/it/pdqm/flow.rs: an_identifier_the_supplier_knows_no_patient_for_is_not_resolved_anywhere
• app/ferrofed-server/tests/it/resolution.rs: a_patient_known_nowhere_is_200_with_no_rows_and_every_member_not_resolved, an_empty_cross_reference_is_200_with_no_rows_and_every_member_not_resolved

CP-13

19 tests.

• app/ferrofed-registry/tests/it/creating_system/learned.rs: a_sighting_at_a_second_node_raises_the_incident_and_withdraws_the_mapping, an_imported_version_resolves_to_its_creating_node_through_a_registered_mapping, one_sighting_learns_a_route_to_the_endpoint_it_was_seen_at
• app/ferrofed-registry/tests/it/creating_system/load.rs: a_registered_mapping_loads_and_is_listed
• app/ferrofed-registry/tests/it/load.rs: a_system_id_routes_to_its_node, an_endpoint_carries_its_url_connection_type_and_managing_organisation, every_member_is_answered_by_its_id
• app/ferrofed-server/tests/it/contribution_write.rs: a_contribution_amending_a_registered_mapping_s_version_reaches_its_node
• app/ferrofed-server/tests/it/e2e/track6.rs (e2e): a_follow_up_read_of_a_row_reaches_the_cdr_that_holds_it_with_its_uid_unchanged
• app/ferrofed-server/tests/it/follow_up.rs: a_fan_out_answer_teaches_the_table_a_system_seen_at_one_node, a_learned_route_never_routes_a_write, a_read_names_the_version_its_path_identifier_classes_carry, a_routed_answer_teaches_the_table_the_version_its_etag_names, a_routed_read_teaches_the_table_the_version_it_named, a_system_seen_at_two_nodes_is_an_integrity_incident
• app/ferrofed-server/tests/it/registry_mcsd/routing.rs: a_registry_from_a_harness_directory_routes_identically_to_the_bootstrap_document, the_directory_materialises_the_snapshot_of_the_bootstrap_document
• app/ferrofed-server/tests/it/versioned_write.rs: a_learned_holder_is_never_the_controlling_cdr_of_a_write, a_registered_creating_system_mapping_makes_its_node_the_controlling_cdr

CP-14

5 tests.

• app/ferrofed-server/tests/it/follow_up.rs: a_version_read_whose_creator_the_registry_does_not_map_falls_to_the_probe, an_imported_copy_is_read_where_the_index_places_the_path_ehr_id_never_at_its_creator, with_no_target_binding_or_index_a_version_read_reaches_its_creator_by_step_4
• app/ferrofed-server/tests/it/path_ehr_id/order.rs: step_4_names_no_member_for_a_creating_system_id_the_registry_does_not_route, step_4_names_the_member_whose_system_id_is_the_creating_system_id

CP-15

33 tests.

• app/ferrofed-server/tests/it/contribution_write.rs: a_body_that_is_no_contribution_naming_object_version_ids_is_a_400_before_any_node, a_contribution_amending_a_registered_mapping_s_version_reaches_its_node, a_contribution_amending_a_version_no_member_is_known_to_control_is_409, a_contribution_in_canonical_xml_is_refused_415_before_routing, a_contribution_its_path_node_controls_reaches_it_once_byte_identical, a_contribution_of_creations_alone_routes_by_its_path_ehr_id, a_contribution_with_one_version_another_member_controls_is_409_and_reaches_no_node, a_contribution_without_a_target_is_never_probed_for, a_malformed_flat_contribution_is_a_400_before_any_node, a_simplified_contribution_its_path_node_controls_reaches_it_once_byte_identical, a_simplified_contribution_of_creations_alone_routes_by_its_path_ehr_id, a_simplified_contribution_with_one_version_another_member_controls_is_409
• app/ferrofed-server/tests/it/created_ehr_id.rs: a_binding_placing_the_ehr_id_at_a_refuses_a_create_at_b, a_create_at_b_of_an_ehr_id_the_index_holds_at_a_is_refused_and_sends_nothing, a_create_at_the_member_holding_the_ehr_id_is_forwarded_for_its_own_409, an_unknown_ehr_id_is_created_where_named_and_then_indexed_there
• app/ferrofed-server/tests/it/e2e/commit.rs (e2e): a_versioned_write_reaches_its_controlling_node_and_never_another
• app/ferrofed-server/tests/it/e2e/track6.rs (e2e): a_new_ehr_is_created_at_the_one_node_the_client_names
• app/ferrofed-server/tests/it/follow_up.rs: a_versioned_write_no_earlier_step_locates_reaches_its_creator_by_step_4, a_versioned_write_whose_path_carries_no_version_is_still_a_400_with_no_earlier_step
• app/ferrofed-server/tests/it/its_rest_areas/ehr.rs: the_ehr_declaration_states_that_a_new_ehr_goes_only_to_the_named_endpoint
• app/ferrofed-server/tests/it/versioned_write.rs: a_learned_holder_is_never_the_controlling_cdr_of_a_write, a_new_ehr_is_created_by_the_targeting_headers_alone_never_by_the_index, a_new_ehr_lands_byte_identical_at_the_one_named_node, a_new_ehr_naming_more_than_one_endpoint_is_refused_and_reaches_no_node, a_registered_creating_system_mapping_makes_its_node_the_controlling_cdr, a_versioned_write_lands_byte_identical_and_carries_no_identifier_outside_its_body, a_versioned_write_naming_no_single_preceding_version_is_a_400_before_any_node, a_versioned_write_reaches_its_controlling_cdr_and_no_other_node, a_versioned_write_the_index_routes_reaches_its_controlling_cdr_unprobed, a_write_its_path_node_does_not_control_is_refused_409_and_reaches_no_node, a_write_of_a_version_no_member_is_known_to_control_is_refused_409, no_write_without_a_target_is_ever_probed_for

CP-16

29 tests.

• app/ferrofed-engine/tests/it/conveyance.rs: a_conveyance_header_from_the_client_never_reaches_the_node, a_node_the_gateway_has_a_grant_at_knows_it_by_its_client_id, a_probe_conveys_the_caller_to_every_member, a_query_conveys_the_caller_in_a_token_the_published_key_verifies, a_relayed_caller_conveys_every_annex_attribute_marked_as_asserted, a_routed_read_and_a_routed_write_convey_the_caller, a_stored_query_definition_conveys_the_caller, each_node_is_the_audience_of_its_own_token, the_admission_checks_ehr_create_and_read_convey_the_gateway
• app/ferrofed-engine/tests/it/exchange.rs: the_node_receives_a_token_exchanged_for_the_verified_caller
• app/ferrofed-engine/tests/it/mtls.rs: token_exchange_composes_with_mutual_tls
• app/ferrofed-engine/tests/it/signing.rs: a_next_key_is_published_ahead_and_never_signs, a_rotation_across_curves_publishes_both_and_signs_with_the_new, the_conveyance_is_signed_with_the_current_keys_algorithm
• app/ferrofed-server/tests/it/auth/patient.rs: a_member_other_than_the_token_s_own_is_told_its_own_ehr_id, each_node_is_told_its_own_ehr_id_and_the_covering_patient_scope
• app/ferrofed-server/tests/it/auth/professional.rs: the_node_is_told_who_acts_and_the_level_reached
• app/ferrofed-server/tests/it/contact_point/relayed.rs: each_node_is_told_the_asserted_attributes_and_no_name
• app/ferrofed-server/tests/it/conveyance.rs: a_local_caller_conveys_the_professional_and_the_provider_to_each_node, a_p256_signing_key_conveys_the_caller_es256_beside_the_previous_es384_key, a_query_conveys_the_verified_caller_to_each_node_signed_for_it, a_query_that_reaches_dispatch_with_no_verified_caller_reaches_no_node, a_registry_from_either_source_without_a_signing_key_does_not_load, a_routed_read_a_routed_write_and_a_definition_request_convey_the_caller, an_edge_asserted_caller_is_conveyed_as_edge_asserted, the_ask_all_probe_conveys_the_caller_to_every_member
• app/ferrofed-server/tests/it/e2e/national/served.rs (e2e): the_national_connector_reads_the_summary_and_prescriptions_and_dispenses
• app/ferrofed-server/tests/it/e2e/track7.rs (e2e): each_node_is_reached_with_its_onward_token_and_told_the_caller
• app/ferrofed-server/tests/it/onward_exchange.rs: the_callers_token_reaches_no_log_span_metric_or_conveyed_claim

CP-17

161 tests.

• app/ferrofed-engine/src/dispatch/dpop.rs: a_proof_that_fails_on_the_first_send_is_a_node_error_with_nothing_sent, a_proof_that_fails_on_the_nonce_resend_is_a_node_error_of_a_node_that_was_asked
• app/ferrofed-engine/tests/it/audience.rs: the_issuer_audience_names_the_issuer, the_token_endpoint_is_the_default_audience
• app/ferrofed-engine/tests/it/conveyance.rs: a_query_conveys_the_caller_in_a_token_the_published_key_verifies
• app/ferrofed-engine/tests/it/dispatch/mod.rs: a_missing_credential_is_a_node_error_and_sends_nothing
• app/ferrofed-engine/tests/it/dpop/mod.rs: a_bearer_token_where_dpop_was_asked_fails_the_node, a_dpop_bound_token_reaches_the_node_with_a_proof_of_its_key, an_exchanged_token_is_dpop_bound, the_nodes_nonce_is_answered_once, the_token_endpoints_nonce_is_answered_no_more_than_once, the_token_endpoints_nonce_is_answered_once
• app/ferrofed-engine/tests/it/dpop/nonce.rs: a_deadline_before_the_nonce_resend_is_a_time_out_of_a_node_that_was_asked, a_nonce_resend_of_an_exchange_signs_new_assertions, a_nonce_resend_signs_a_new_client_assertion, the_token_endpoint_and_the_node_keep_their_own_nonces
• app/ferrofed-engine/tests/it/exchange.rs: a_caller_without_its_token_is_refused_with_nothing_sent, a_node_401_drops_the_exchanged_token, a_refused_exchange_names_the_token_endpoints_code, an_edge_asserted_caller_is_refused_with_nothing_sent, an_exchange_answer_without_its_issued_token_type_fails_the_node, an_exchange_naming_no_resource_is_never_sent, an_exchanged_token_is_cached_per_caller, an_operation_no_scope_covers_is_never_exchanged, every_exchange_carries_its_scope_and_resource, the_gateways_own_request_uses_client_credentials, the_node_receives_a_token_exchanged_for_the_verified_caller
• app/ferrofed-engine/tests/it/fapi2/mod.rs: a_callers_token_carrying_the_patient_is_never_sent, a_dpop_bound_token_reaches_the_node, a_refused_grant_fails_the_node_and_shows_no_credential, a_token_endpoint_past_the_timeout_fails_the_node, a_token_without_its_granted_details_fails_the_node, a_verified_callers_token_is_exchanged, refused_details_fail_the_node_naming_the_code, the_token_request_names_the_issuer_and_carries_the_details
• app/ferrofed-engine/tests/it/fapi2/mtls.rs: a_fapi2_grant_authenticates_and_binds_its_tokens_by_certificate, an_alias_on_a_host_the_grant_names_is_taken
• app/ferrofed-engine/tests/it/fapi2/rotation.rs: only_the_current_client_key_signs_while_the_previous_one_is_published
• app/ferrofed-engine/tests/it/mtls.rs: a_bound_token_travels_only_over_connections_presenting_its_certificate, a_token_bound_to_another_certificate_never_reaches_the_node, the_gateway_authenticates_by_its_certificate_and_sends_no_assertion, token_exchange_composes_with_mutual_tls
• app/ferrofed-engine/tests/it/nuts.rs: a_refused_nuts_grant_fails_the_node, the_nuts_token_reaches_the_node_dpop_bound
• app/ferrofed-engine/tests/it/onward.rs: a_401_drops_the_token_and_the_next_request_obtains_a_new_one, a_refused_token_request_is_a_node_error_and_nothing_reaches_the_node, a_rotation_publishes_both_keys_for_the_overlap_window, a_token_endpoint_description_never_reaches_the_answer, a_token_is_cached_until_thirty_seconds_before_it_expires, an_unreachable_token_endpoint_is_a_node_error_and_nothing_reaches_the_node, the_assertion_carries_the_rfc_7523_claims, the_assertion_verifies_against_the_published_jwks_and_the_token_reaches_the_node, the_token_request_carries_the_rfc_7523_parameters, the_token_request_carries_the_scope_as_written
• app/ferrofed-engine/tests/it/signing.rs: an_es256_signing_key_signs_the_client_assertion_es256
• app/ferrofed-server/tests/it/access/emergency.rs: the_emergency_purpose_is_conveyed_to_the_node
• app/ferrofed-server/tests/it/admission/onward.rs: beside_an_onward_lane_the_admission_check_uses_the_client_credentials_grant, the_admission_check_authenticates_with_the_onward_grant
• app/ferrofed-server/tests/it/auth/attributes.rs: an_issuer_without_an_attributes_table_states_no_purpose
• app/ferrofed-server/tests/it/auth/edge.rs: a_bearer_token_alone_is_401_at_the_edge, an_assertion_of_another_issuer_is_401, an_assertion_of_the_edge_admits_and_is_recorded
• app/ferrofed-server/tests/it/auth/introspection.rs: an_active_token_for_another_audience_is_401, an_active_token_for_this_gateway_is_admitted, an_answer_past_its_expiry_is_401, an_endpoint_answering_an_error_is_503, an_inactive_token_is_401, an_unreachable_endpoint_is_503
• app/ferrofed-server/tests/it/auth/kept_token.rs: an_edge_assertion_is_never_kept_as_a_token, no_token_is_kept_where_no_node_exchanges_it, the_verified_token_is_kept_for_an_exchanging_node_and_never_shown
• app/ferrofed-server/tests/it/auth/keys.rs: a_key_set_answered_with_an_error_is_503, a_key_set_file_verifies_and_a_missing_one_is_503, a_key_set_is_fetched_once_and_verifies_every_token, a_rotated_key_is_picked_up_by_one_refetch, an_es384_key_verifies_its_tokens, an_unknown_key_refetches_at_most_once_per_interval, an_unreachable_key_set_is_503
• app/ferrofed-server/tests/it/auth/other_patient.rs: a_query_for_another_patient_asks_the_bound_member_alone, a_read_by_subject_of_another_patient_asks_the_bound_member_alone, the_token_s_own_patient_is_localized_and_prefiltered
• app/ferrofed-server/tests/it/auth/patient.rs: a_class_beside_the_scoped_ehr_under_and_is_refused, a_class_beside_the_scoped_ehr_under_or_is_refused, a_containment_nested_under_the_scoped_ehr_is_admitted, a_cross_reference_contradicting_the_token_is_a_424, a_patient_grant_creates_no_ehr, a_patient_grant_never_reaches_the_demographic_api, a_patient_query_with_a_class_beside_its_ehr_is_refused, a_patient_token_without_an_ehr_id_is_refused, a_population_query_is_refused, a_query_for_another_patient_is_refused, a_read_by_subject_reaches_the_patient_s_own_ehr_alone, a_refused_read_by_subject_records_nothing_of_the_other_patient, a_second_ehr_variable_is_refused, an_ehr_id_outside_the_patient_s_pairs_is_refused_with_no_probe, an_ehr_under_not_contains_is_refused, the_patient_s_ehr_id_routes_to_its_own_member, the_token_s_ehr_id_at_another_member_is_refused, the_token_s_own_patient_is_admitted_at_every_member, without_the_opt_in_a_patient_grant_still_admits_nothing
• app/ferrofed-server/tests/it/auth/purpose.rs: a_deployment_that_declares_it_optional_admits_a_token_without_one, a_purpose_in_authorization_details_is_admitted, a_token_without_a_purpose_of_use_is_403, an_iua_coding_without_a_code_declares_none
• app/ferrofed-server/tests/it/auth/scope.rs: a_composition_read_needs_a_composition_read_over_every_template, a_named_aql_pattern_does_not_cover_an_ad_hoc_query, a_named_template_is_covered_by_its_own_pattern, a_patient_grant_admits_no_ehr_id_route, a_patient_grant_admits_no_query, a_query_without_an_aql_search_scope_is_403, a_scope_outside_the_grammar_and_no_scope_grant_nothing, a_stored_query_needs_a_pattern_over_its_name, a_system_wide_aql_grant_counts_only_for_a_listed_backend_client, an_admin_operation_is_refused_to_every_caller, an_ehr_status_update_needs_a_composition_update, the_demographic_api_admits_only_a_listed_client
• app/ferrofed-server/tests/it/auth/token.rs: a_basic_credential_is_401, a_bearer_value_outside_b64token_is_401, a_query_without_a_token_is_401_and_reaches_no_node, a_token_expired_within_the_clock_skew_is_admitted, a_token_for_another_audience_is_401, a_token_from_an_untrusted_issuer_is_401, a_token_naming_an_unpublished_key_is_401, a_token_not_typed_as_an_access_token_is_401, a_token_not_yet_valid_is_401, a_token_signed_by_another_key_under_a_trusted_name_is_401, a_token_with_a_blank_sub_is_401, a_token_without_its_client_id_is_401, an_admitted_token_reaches_no_node, an_expired_token_is_401, an_hmac_token_is_401, an_unsigned_token_is_401, options_root_is_behind_the_gate, two_authorization_fields_are_400
• app/ferrofed-server/tests/it/conveyance.rs: a_query_conveys_the_verified_caller_to_each_node_signed_for_it
• app/ferrofed-server/tests/it/e2e/onward_cdr.rs (e2e): a_persons_query_reaches_the_cdr_under_the_exchanged_token_alone
• app/ferrofed-server/tests/it/e2e/track7.rs (e2e): a_caller_that_does_not_authenticate_reaches_no_node, each_node_is_reached_with_its_onward_token_and_told_the_caller
• app/ferrofed-server/tests/it/next_key.rs: the_next_key_is_published_and_never_signs
• app/ferrofed-server/tests/it/onward.rs: a_refusal_description_reaches_the_log_and_never_the_answer, a_rotation_publishes_the_current_and_the_previous_key, a_token_endpoint_down_fails_the_node_and_sends_it_nothing, options_declares_the_jwks_uri_and_validates_against_the_schema, the_node_receives_the_token_its_endpoint_issued_against_the_published_jwks
• app/ferrofed-server/tests/it/onward_exchange.rs: a_dpop_bound_grant_proves_every_request_to_its_node, an_edge_asserted_caller_fails_an_exchanging_node_with_nothing_sent, node_a_receives_a_token_exchanged_for_the_verified_caller, the_callers_token_reaches_no_log_span_metric_or_conveyed_claim, the_exchange_asks_for_the_covering_scope_in_canonical_form
• app/ferrofed-server/tests/it/onward_fapi2.rs: a_refused_fapi2_grant_fails_node_a_and_names_no_credential, a_rotated_client_key_is_published_beside_the_previous_one_and_alone_signs, node_a_receives_the_dpop_bound_fapi2_token
• app/ferrofed-server/tests/it/onward_lane.rs: a_caller_the_issuer_does_not_carry_is_refused_before_anything_is_sent, a_person_reaches_the_node_under_the_exchanged_token, a_refused_exchange_fails_the_node_with_nothing_sent, no_inbound_request_reaches_the_node_under_the_client_credentials_token
• app/ferrofed-server/tests/it/onward_mtls.rs: a_node_is_reached_with_a_token_bound_to_the_certificate_its_section_names, a_token_bound_to_another_certificate_never_reaches_the_node
• app/ferrofed-server/tests/it/onward_nuts.rs: a_refused_nuts_grant_fails_node_a_and_names_no_credential, node_a_receives_the_dpop_bound_nuts_token, the_served_did_document_verifies_the_gateways_presentation

CP-18

4 tests.

• tools/ferrofed-testkit/tests/it/e2e/node_profile.rs (e2e): ferroehr_is_checked_for_holding_its_own_access_decision, ferroehr_is_checked_for_passing_its_errors_through
• tools/ferrofed-testkit/tests/it/e2e/node_profile/ehrbase.rs (e2e): ehrbase_is_checked_for_holding_its_own_access_decision, ehrbase_is_checked_for_passing_its_errors_through

CP-19

2 tests.

• tools/ferrofed-testkit/tests/it/e2e/node_profile.rs (e2e): ferroehr_is_checked_for_withholding_a_restricted_composition
• tools/ferrofed-testkit/tests/it/e2e/node_profile/ehrbase.rs (e2e): ehrbase_has_no_consent_refusal_arranged_in_the_harness

CP-21

10 tests.

• app/ferrofed-server/tests/it/base_url.rs: a_read_by_subject_is_served_at_the_root_and_under_a_prefix, a_routed_read_is_served_at_the_root_and_under_a_prefix, a_routed_write_is_served_at_the_root_and_under_a_prefix_with_location_untouched, no_prefix_is_reserved_at_the_root, options_describes_the_surface_at_the_root_and_under_a_prefix, the_base_path_is_the_root_by_default_and_the_deployment_chooses_any_other, the_federated_query_is_served_at_the_root_and_under_a_prefix, under_a_prefix_nothing_is_served_outside_it
• app/ferrofed-server/tests/it/e2e/track9.rs (e2e): an_unmodified_client_given_only_the_base_url_reads_and_writes_at_a_prefix
• app/ferrofed-server/tests/it/fhir/summary.rs: an_its_rest_path_under_the_base_still_answers_as_it_did

CP-22

12 tests.

• app/ferrofed-server/tests/it/e2e/track9.rs (e2e): an_unmodified_client_given_only_the_base_url_reads_and_writes_at_a_prefix
• app/ferrofed-server/tests/it/ehr_scope.rs: a_scoped_query_reaches_only_the_member_that_holds_the_ehr_id, a_targeted_scoped_query_goes_to_the_named_endpoint_and_nothing_is_probed, both_forms_send_the_owner_the_same_query_and_answer_the_same_rows, the_index_routes_a_scoped_query_and_nothing_is_probed, two_members_holding_the_ehr_id_are_a_409_and_neither_is_queried
• crates/openehr-federation/tests/it/aql/rules.rs: a_query_already_scoped_by_ehr_id_is_accepted_as_written
• crates/openehr-federation/tests/it/aql/scope.rs: a_bound_parameter_scopes_the_query_in_either_form, a_patient_query_in_the_from_form_dispatches_the_canonical_scope_and_no_identifier, an_unnamed_ehr_in_the_from_form_is_scoped_through_a_fresh_variable, both_forms_name_the_same_ehr_id_and_reach_a_node_as_the_same_query, the_patient_identifier_written_as_an_ehr_id_is_refused_in_either_form

CP-23

39 tests.

• app/ferrofed-server/tests/it/auth/token.rs: options_root_is_behind_the_gate
• app/ferrofed-server/tests/it/consent_withheld/mod.rs: by_default_the_exclusion_is_disclosed_and_declared, the_configured_setting_withholds_the_exclusion_and_is_declared
• app/ferrofed-server/tests/it/contact_point/declared.rs: a_declared_contact_point_is_described_with_how_its_requests_are_served, a_deployment_with_no_contact_point_declares_none, a_tightened_emergency_limit_is_declared_as_the_one_in_effect
• app/ferrofed-server/tests/it/e2e/track9_surface.rs (e2e): the_self_description_lists_the_members_and_demographic_answers_as_declared
• app/ferrofed-server/tests/it/fhir/native.rs: the_native_endpoint_is_absent_from_the_self_description
• app/ferrofed-server/tests/it/its_rest_areas/definition.rs: the_definition_declaration_states_that_a_request_goes_to_the_one_named_node, the_definition_declaration_states_the_distribution_only_where_offered, the_definition_declaration_states_the_template_fan_out_only_where_offered, the_definition_declaration_states_where_stored_queries_are_held
• app/ferrofed-server/tests/it/its_rest_areas/demographic.rs: the_demographic_declaration_matches_the_demographic_area_in_each_mode
• app/ferrofed-server/tests/it/its_rest_areas/ehr.rs: the_ehr_declaration_states_how_a_path_ehr_id_finds_its_owner, the_ehr_declaration_states_that_a_new_ehr_goes_only_to_the_named_endpoint, the_ehr_declaration_states_that_a_versioned_write_needs_the_controlling_node, the_ehr_declaration_states_the_read_by_subject
• app/ferrofed-server/tests/it/its_rest_areas/modes.rs: every_mode_declares_all_four_areas_and_each_follows_only_its_own_settings
• app/ferrofed-server/tests/it/its_rest_areas/query.rs: the_query_declaration_names_stored_query_execution_only_where_the_registry_is_offered, the_query_declaration_states_that_both_forms_of_an_adhoc_query_fan_out
• app/ferrofed-server/tests/it/onward.rs: options_declares_the_jwks_uri_and_validates_against_the_schema
• app/ferrofed-server/tests/it/options.rs: an_endpoint_sent_requests_reports_its_median_and_95th_percentile, no_targeting_mechanism_no_carrier_and_no_async_member_is_declared, options_on_a_path_the_gateway_does_not_serve_is_not_implemented, options_on_a_sub_path_names_the_methods_served_there, the_body_validates_against_the_vendored_schema, the_completeness_modes_follow_the_configuration, the_decomposable_aggregates_follow_the_configuration, the_dedup_policy_names_the_default_the_modes_and_the_header, the_definition_area_declares_nothing_offered, the_description_needs_no_patient_identifier_and_holds_none, the_member_endpoints_follow_the_registry, the_offset_strategy_follows_the_configuration, the_options_root_answer_names_the_methods_of_the_base, the_row_ceiling_follows_the_configuration, the_template_fan_out_upload_follows_the_configuration, the_timeout_budget_follows_the_configuration
• app/ferrofed-server/tests/it/stored/declaration.rs: options_declares_the_registry_and_the_methods_it_serves
• crates/openehr-federation/tests/it/examples.rs: the_7a_2_example_round_trips_unchanged

CP-24

23 tests.

• app/ferrofed-engine/tests/it/forward.rs: the_body_arrives_byte_for_byte_and_only_the_declared_headers_travel
• app/ferrofed-server/tests/it/contribution_write.rs: a_contribution_its_path_node_controls_reaches_it_once_byte_identical
• app/ferrofed-server/tests/it/declared.rs: a_body_sent_without_a_content_type_travels_with_the_one_its_operation_declares
• app/ferrofed-server/tests/it/e2e/commit.rs (e2e): a_composition_committed_through_the_gateway_lands_byte_identical_at_one_node, a_versioned_write_reaches_its_controlling_node_and_never_another
• app/ferrofed-server/tests/it/e2e/track9.rs (e2e): an_unmodified_client_given_only_the_base_url_reads_and_writes_at_a_prefix
• app/ferrofed-server/tests/it/ehr_by_subject.rs: a_subject_one_member_holds_is_that_members_ehr_read_by_its_ehr_id
• app/ferrofed-server/tests/it/ehr_scope.rs: a_scoped_query_reaches_only_the_member_that_holds_the_ehr_id
• app/ferrofed-server/tests/it/provenance.rs: a_directed_query_names_the_node_that_failed_it_once_the_node_was_asked, a_directed_query_that_asked_no_node_names_none, a_fan_out_lists_the_endpoints_that_contributed_rows_in_registry_order, a_query_directed_at_one_endpoint_names_it_and_its_system_id, an_all_or_nothing_failure_lists_no_endpoint, an_undirected_query_the_patient_resolves_for_at_one_member_names_it, the_provenance_headers_carry_registry_ids_and_nothing_the_request_sent, under_partial_a_failed_node_and_an_empty_one_are_not_listed
• app/ferrofed-server/tests/it/routing/pass_through.rs: a_committed_composition_lands_byte_identical_and_location_and_etag_pass_through, a_query_parameter_its_rest_defines_is_forwarded_as_received, a_redirect_is_the_nodes_answer_and_is_never_followed, every_routed_answer_names_the_acting_endpoint_and_its_system_id, the_nodes_own_404_and_500_pass_through_as_the_node_sent_them
• app/ferrofed-server/tests/it/versioned_write.rs: a_new_ehr_lands_byte_identical_at_the_one_named_node, a_versioned_write_lands_byte_identical_and_carries_no_identifier_outside_its_body

CP-25

14 tests.

• app/ferrofed-server/tests/it/demographic.rs: a_header_naming_another_endpoint_several_or_a_star_is_refused, a_header_naming_the_declared_endpoint_is_accepted, by_default_a_read_and_a_create_are_501_and_no_node_is_asked, options_declares_each_mode_and_the_behaviour_matches_it, options_on_a_party_names_its_methods_only_when_routed, the_conflict_names_both_endpoints, with_the_setting_a_create_body_is_forwarded_unchanged, with_the_setting_a_party_read_reaches_only_that_node_byte_identical, with_the_setting_a_path_naming_no_its_rest_operation_is_still_501, with_the_setting_a_request_naming_no_endpoint_goes_to_the_declared_one_alone
• app/ferrofed-server/tests/it/e2e/track9_surface.rs (e2e): the_self_description_lists_the_members_and_demographic_answers_as_declared
• app/ferrofed-server/tests/it/errors.rs: an_unexposed_its_rest_area_is_a_501_not_implemented
• app/ferrofed-server/tests/it/its_rest_areas/demographic.rs: the_demographic_declaration_matches_the_demographic_area_in_each_mode
• app/ferrofed-server/tests/it/its_rest_areas/modes.rs: every_mode_declares_all_four_areas_and_each_follows_only_its_own_settings

CP-26

165 tests.

• app/ferrofed-engine/src/declared/headers.rs: a_utf_8_charset_passes_and_is_dropped, an_accept_list_reaches_the_node_as_its_best_listed_match, an_accept_that_admits_nothing_listed_is_not_acceptable, an_unlisted_content_type_is_unsupported, any_media_type_reaches_the_node_as_the_first_listed, prefer_reaches_the_node_as_its_listed_preferences_only
• app/ferrofed-engine/src/declared/mod.rs: a_free_text_parameter_passes_unclassified, a_malformed_date_time_is_refused_by_position_never_by_value, a_well_formed_date_time_is_held
• app/ferrofed-engine/src/declared/path.rs: a_uid_based_id_parses_as_a_version_or_an_object_id, a_uuid_path_parameter_is_a_canonical_uuid, a_version_uid_parses_as_an_object_version_id, the_uid_based_id_of_a_delete_parses_as_an_object_version_id
• app/ferrofed-engine/src/hygiene/forwarded.rs: every_federation_header_is_withheld_even_where_an_operation_declares_it
• app/ferrofed-engine/src/hygiene/mod.rs: the_authority_of_the_url_is_never_read, the_identifier_in_a_conveyed_claim_names_the_conveyance_header, the_path_query_and_fragment_are_read_under_any_authority
• app/ferrofed-engine/src/outbound_id.rs: a_withheld_value_inside_the_minted_id_is_sent_with_that_id, the_same_value_in_the_aql_is_still_never_sent
• app/ferrofed-engine/tests/it/conveyance.rs: a_caller_claim_carrying_the_withheld_identifier_stops_a_query_unsent, a_caller_claim_carrying_the_withheld_identifier_stops_a_routed_request_unsent, a_caller_claim_carrying_the_withheld_identifier_stops_an_ehr_call_and_a_definition
• app/ferrofed-engine/tests/it/dispatch/sent.rs: every_header_a_node_receives_is_in_the_inventory, the_request_id_a_node_receives_is_the_minted_outbound_id_byte_for_byte
• app/ferrofed-engine/tests/it/exchange.rs: a_caller_token_carrying_the_withheld_identifier_is_never_exchanged
• app/ferrofed-engine/tests/it/fanout/all_or_nothing.rs: the_one_outbound_id_reaches_every_node
• app/ferrofed-engine/tests/it/fapi2/mod.rs: a_callers_token_carrying_the_patient_is_never_sent, no_carrier_to_the_server_or_the_node_names_the_patient
• app/ferrofed-engine/tests/it/forward.rs: a_free_text_parameter_passes_unclassified, a_header_the_operation_declares_travels_and_one_it_does_not_is_stripped, a_malformed_date_time_is_refused_and_no_node_is_asked, a_query_parameter_the_operation_does_not_declare_is_refused_unsent, a_well_formed_date_time_is_forwarded_byte_identical, a_withheld_identifier_in_the_body_of_a_commit_is_sent_unchanged, a_withheld_identifier_in_the_path_or_a_forwarded_header_is_never_sent, a_withheld_value_in_a_client_header_is_refused_though_the_registry_authority_holds_it, a_withheld_value_in_the_registry_path_is_never_forwarded, an_accept_list_reaches_the_node_as_its_best_listed_match, an_accept_that_admits_nothing_listed_is_not_acceptable_unsent, an_identifier_inside_the_composed_ehr_id_is_forwarded, any_media_type_reaches_the_node_as_the_first_listed, the_host_a_node_receives_is_the_registry_authority_never_the_client_host, the_same_identifier_in_a_part_the_client_wrote_is_still_withheld
• app/ferrofed-engine/tests/it/gate.rs: a_clean_request_is_sent_with_identifiers_withheld, a_fan_out_with_a_leaking_query_fails_closed_and_asks_nobody, a_short_identifier_inside_the_scope_ehr_id_is_sent, a_withheld_value_in_the_registry_authority_is_sent, a_withheld_value_in_the_registry_path_is_never_sent, a_withheld_value_inside_the_minted_id_is_sent_with_that_id, an_identifier_in_the_aql_text_is_never_sent, the_header_the_gateway_adds_is_its_minted_id_and_carries_no_identifier, the_same_short_identifier_elsewhere_is_never_sent
• app/ferrofed-engine/tests/it/masking.rs: a_short_identifier_in_the_base_path_is_found, a_short_identifier_inside_the_composed_ehr_id_passes, an_ehr_id_segment_the_client_wrote_is_never_masked, the_same_short_identifier_in_a_client_part_is_still_found
• app/ferrofed-engine/tests/it/native.rs: a_request_that_would_carry_a_withheld_identifier_is_never_sent, the_member_is_asked_by_its_ehr_id_alone_and_its_document_comes_back_unchanged
• app/ferrofed-engine/tests/it/native_create.rs: an_update_leaves_once_by_the_members_id_with_its_body_byte_for_byte, the_body_leaves_byte_for_byte_once_and_nothing_else_carries_the_patient
• app/ferrofed-engine/tests/it/nuts_service.rs: the_pseudonym_reaches_neither_the_authorization_server_nor_a_proof
• app/ferrofed-engine/tests/it/onward.rs: a_token_endpoint_description_never_reaches_the_answer
• app/ferrofed-identity/tests/it/mitz.rs: a_patient_named_by_a_pseudonym_is_never_sent_to_mitz
• app/ferrofed-identity/tests/it/nvi_localizer.rs: a_bsn_system_never_stands_for_the_pseudonym
• app/ferrofed-server/tests/it/collision_clear.rs: the_clear_is_recorded_with_its_operator_listed_and_names_no_patient_identifier
• app/ferrofed-server/tests/it/contact_point/relayed.rs: no_iua_person_id_reaches_a_node
• app/ferrofed-server/tests/it/contribution_write.rs: a_contribution_its_path_node_controls_reaches_it_once_byte_identical, a_simplified_contribution_its_path_node_controls_reaches_it_once_byte_identical
• app/ferrofed-server/tests/it/conveyance.rs: a_caller_claim_carrying_the_patient_stops_the_query_before_any_node, a_professional_claim_carrying_the_patient_stops_the_query_before_any_node
• app/ferrofed-server/tests/it/declared.rs: a_free_text_parameter_passes_unclassified, a_malformed_path_uid_is_refused_by_position_and_no_node_is_asked, a_malformed_version_at_time_is_refused_and_no_node_is_asked, a_well_formed_version_at_time_reaches_the_node_byte_identical, an_accept_that_admits_nothing_listed_is_a_406_that_asks_no_node, an_unlisted_content_type_is_a_415_that_asks_no_node, the_listed_values_of_a_commit_reach_the_node_and_no_client_text
• app/ferrofed-server/tests/it/definition.rs: a_definition_request_carries_only_what_its_operation_declares, a_malformed_declared_value_is_refused_before_the_missing_target
• app/ferrofed-server/tests/it/directive.rs: no_node_receives_the_directive_and_each_receives_the_undirected_node_query, the_organisation_selector_asks_every_endpoint_the_organisation_manages
• app/ferrofed-server/tests/it/e2e/national/restricted.rs (e2e): a_patient_every_member_restricts_is_looked_up_as_one_no_member_holds, a_restricting_member_leaves_no_trace_in_any_answer
• app/ferrofed-server/tests/it/e2e/national/served.rs (e2e): the_national_connector_reads_the_summary_and_prescriptions_and_dispenses
• app/ferrofed-server/tests/it/e2e/track10.rs (e2e): a_committed_dv_identifier_arrives_at_a_ferroehr_node_byte_identical, the_four_positions_reach_neither_ferroehr_node_on_any_path
• app/ferrofed-server/tests/it/ehr_by_subject.rs: a_plus_in_the_subject_is_a_literal_plus, a_short_subject_inside_the_registry_base_path_is_never_forwarded, a_short_subject_inside_the_routed_ehr_id_still_forwards, a_subject_not_given_once_or_an_undeclared_parameter_is_a_400_that_asks_nobody, a_subject_one_member_holds_is_that_members_ehr_read_by_its_ehr_id, a_subject_several_members_hold_is_a_400_listing_them_and_asks_nobody, a_subject_that_is_no_utf8_text_is_a_400_that_asks_no_resolver, the_targeting_header_names_which_of_several_holders_answers
• app/ferrofed-server/tests/it/ehr_id_collision.rs: an_ehr_id_that_is_no_uuid_is_never_named_by_an_incident, no_incident_or_log_line_names_a_patient_identifier
• app/ferrofed-server/tests/it/ehr_scope.rs: an_ehr_id_that_is_no_uuid_is_never_probed_nor_sent, neither_form_carries_the_patient_identifier_to_a_node
• app/ferrofed-server/tests/it/fhir/binary.rs: a_read_asks_the_member_by_its_ehr_id_alone
• app/ferrofed-server/tests/it/fhir/header.rs: the_header_is_the_supplier_s_and_no_header_value_reaches_a_node
• app/ferrofed-server/tests/it/fhir/list/mod.rs: a_native_member_is_asked_for_the_list_by_its_ehr_id_alone
• app/ferrofed-server/tests/it/fhir/list/own_laboratory.rs: a_members_own_report_is_listed_unchanged_but_for_its_url_and_read_unchanged
• app/ferrofed-server/tests/it/fhir/native.rs: a_native_member_is_asked_by_its_ehr_id_alone_and_left_out_of_the_mapped_document
• app/ferrofed-server/tests/it/fhir/patient_grant.rs: a_persons_own_grant_gets_their_summary_and_no_identifier_reaches_a_node_or_a_log
• app/ferrofed-server/tests/it/fhir/prescriptions/dispense.rs: a_dispensation_naming_its_prescription_by_the_faces_reference_alone_is_refused, a_dispensation_reaches_the_owner_alone_by_its_ehr_id_with_its_body_unchanged
• app/ferrofed-server/tests/it/fhir/prescriptions/dispensed.rs: the_dispensation_a_receipt_located_is_read_at_its_member_by_its_ehr_id
• app/ferrofed-server/tests/it/fhir/prescriptions/mod.rs: each_member_is_asked_by_its_ehr_id_alone
• app/ferrofed-server/tests/it/fhir/prescriptions/read.rs: the_member_is_asked_by_its_ehr_id_and_its_own_id_alone
• app/ferrofed-server/tests/it/fhir/prescriptions/vread.rs: the_location_a_receipt_answered_reads_back_the_dispensation_it_located
• app/ferrofed-server/tests/it/fhir/prescriptions/withdraw.rs: a_withdrawal_reaches_its_member_alone_with_its_body_unchanged_but_for_its_id
• app/ferrofed-server/tests/it/fhir/receive/inserted.rs: a_persons_own_document_is_marked_as_inserted_by_them_with_no_identifier_added
• app/ferrofed-server/tests/it/fhir/receive/representative.rs: a_representatives_document_names_them_as_every_entrys_provider
• app/ferrofed-server/tests/it/fhir/receive/write.rs: a_document_is_written_to_its_member_by_its_ehr_id_alone
• app/ferrofed-server/tests/it/fhir/summary.rs: the_summary_is_an_eps_document_from_both_members_and_no_identifier_reaches_a_node
• app/ferrofed-server/tests/it/follow_up.rs: a_version_read_reaches_the_node_byte_identical_and_carries_no_identifier
• app/ferrofed-server/tests/it/identity_export.rs: the_export_names_no_patient_identifier_while_bindings_exist_and_is_recorded
• app/ferrofed-server/tests/it/mitz/config.rs: the_pseudonym_listed_as_the_bsn_is_refused
• app/ferrofed-server/tests/it/mitz/decision.rs: the_bsn_reaches_mitz_only_and_no_node_log_or_error
• app/ferrofed-server/tests/it/nl_gf.rs: a_bsn_system_listed_as_the_pseudonym_is_refused_at_load, the_pseudonymised_walkthrough_runs_end_to_end_and_no_node_sees_the_pseudonym
• app/ferrofed-server/tests/it/nvi_nuts.rs: the_nuts_token_reaches_the_nvi_alone
• app/ferrofed-server/tests/it/outbound.rs: a_clinician_predicate_reaches_the_node_unchanged, a_short_identifier_inside_the_nodes_ehr_id_is_answered, an_identifier_in_the_clients_query_string_and_headers_is_never_forwarded, either_carrier_and_a_projection_reach_a_node_as_its_ehr_id_alone, the_identifier_on_another_path_is_a_400_that_asks_nobody
• app/ferrofed-server/tests/it/outbound_id.rs: a_client_request_id_never_reaches_a_node_on_the_fan_out, a_failed_query_is_logged_under_the_id_its_request_line_records, two_requests_reach_the_nodes_under_two_ids, with_no_client_id_the_response_and_every_node_share_the_minted_id
• app/ferrofed-server/tests/it/path_ehr_id/probe.rs: neither_the_probe_nor_the_routed_read_carries_an_identifier_or_the_clients_credential
• app/ferrofed-server/tests/it/pdqm/flow.rs: neither_identifier_reaches_a_log_line_a_metric_or_a_node
• app/ferrofed-server/tests/it/probed_ehr_id.rs: a_read_whose_ehr_id_is_a_uuid_is_still_resolved_by_the_probe, a_read_whose_ehr_id_is_no_uuid_and_that_nothing_routes_is_refused_and_probes_nobody, an_ehr_id_that_is_no_uuid_is_forwarded_to_the_named_node_alone_and_then_indexed
• app/ferrofed-server/tests/it/query_get.rs: a_client_ehr_id_in_the_query_string_is_dropped, a_quoted_identifier_bound_as_the_subject_resolves_as_the_posted_string, a_quoted_identifier_in_a_get_query_parameter_is_refused_before_dispatch, a_quoted_identifier_in_a_stored_get_query_parameter_is_refused_before_dispatch
• app/ferrofed-server/tests/it/routing/hygiene.rs: an_identifier_in_a_client_header_never_reaches_the_node_nor_does_its_authorization, an_identifier_in_a_query_parameter_is_refused_before_anything_is_sent
• app/ferrofed-server/tests/it/routing_log.rs: no_event_of_a_routed_request_names_the_clients_id
• app/ferrofed-server/tests/it/traces/traceparent.rs: an_identifier_hidden_in_the_clients_trace_id_reaches_no_node_and_no_span
• app/ferrofed-server/tests/it/track10/mock.rs: a_committed_dv_identifier_arrives_at_the_node_byte_identical, a_panicking_handler_holding_the_identifier_leaves_it_on_neither_stderr_nor_the_log, the_identifier_in_a_party_identified_predicate_reaches_no_node, the_identifier_in_a_projection_reaches_no_node, the_identifier_in_an_external_ref_predicate_reaches_no_node, the_identifier_in_the_ehr_id_slot_is_never_probed_at_a_node, the_identifier_in_the_query_string_or_a_header_reaches_no_node, the_identifier_on_the_single_node_route_reaches_no_node
• app/ferrofed-server/tests/it/versioned_write.rs: a_new_ehr_lands_byte_identical_at_the_one_named_node, a_versioned_write_lands_byte_identical_and_carries_no_identifier_outside_its_body
• crates/openehr-federation/tests/it/aql/directive.rs: a_directed_patient_query_reaches_the_node_as_the_undirected_one_does, the_organisation_selector_never_reaches_a_node
• crates/openehr-federation/tests/it/aql/golden.rs: golden_case_02_keeps_the_directive_and_its_projections_out_of_the_node_query
• crates/openehr-federation/tests/it/aql/guard.rs: a_clinician_or_facility_predicate_is_dispatched_unchanged, the_same_path_compared_with_the_patient_identifier_is_refused
• crates/openehr-federation/tests/it/aql/hygiene.rs: a_seated_identifier_is_either_kept_from_the_node_or_refused, no_pushed_row_key_carries_the_patient, no_recombined_aggregate_query_carries_the_patient_identifier, the_avg_rewrite_reaches_the_node_without_the_patient
• crates/openehr-federation/tests/it/aql/scope.rs: a_patient_query_in_the_from_form_dispatches_the_canonical_scope_and_no_identifier, the_patient_identifier_written_as_an_ehr_id_is_refused_in_either_form

CP-27

6 tests.

• tools/ferrofed-testkit/tests/it/e2e/node_profile.rs (e2e): ferroehr_is_checked_against_the_identifier_integrity_conditions, ferroehr_is_checked_for_an_ehr_created_without_a_subject, ferroehr_is_invocable_on_its_local_ehr_id_alone
• tools/ferrofed-testkit/tests/it/e2e/node_profile/ehrbase.rs (e2e): ehrbase_is_checked_against_the_identifier_integrity_conditions, ehrbase_is_checked_for_an_ehr_created_without_a_subject, ehrbase_is_invocable_on_its_local_ehr_id_alone

CP-28

18 tests.

• app/ferrofed-engine/src/hygiene/forwarded.rs: the_targeting_headers_are_withheld_from_every_operation
• app/ferrofed-server/src/facade/target.rs: a_conflict_names_both_sets_and_answers_its_own_code
• app/ferrofed-server/tests/it/e2e/track3.rs (e2e): the_endpoint_header_selects_what_the_directive_selects
• app/ferrofed-server/tests/it/routing/selection.rs: a_node_named_in_a_query_parameter_is_refused_and_never_routed, the_organisation_header_routes_to_the_one_endpoint_it_manages, the_routing_headers_select_one_endpoint_and_never_two_sets
• app/ferrofed-server/tests/it/stored/invocation.rs: a_stored_query_is_targeted_by_the_header_as_by_the_directive
• app/ferrofed-server/tests/it/targeting.rs: a_header_and_a_directive_that_differ_are_refused_400_naming_both_sets, a_header_and_a_directive_that_select_the_same_set_proceed, a_query_parameter_targets_nothing, an_aggregate_the_header_directs_at_one_endpoint_reaches_it_unchanged, an_identifier_a_header_names_that_the_registry_does_not_know_is_refused_400, an_unknown_header_identifier_is_refused_even_beside_a_valid_directive, no_node_receives_a_targeting_header_or_its_value, the_endpoint_header_selects_the_node_set_as_the_directive_does, the_organisation_header_asks_every_endpoint_the_organisation_manages, the_two_headers_that_differ_are_refused_400
• app/ferrofed-server/tests/it/template_fan_out.rs: a_star_beside_an_organisation_naming_fewer_members_is_a_conflict

CP-29

5 tests.

• app/ferrofed-server/tests/it/dedup.rs: under_version_identity_one_row_comes_back_and_the_copy_is_named
• app/ferrofed-server/tests/it/dedup_write.rs: a_write_against_the_surviving_row_while_its_owner_is_down_is_a_409_and_reaches_no_node, a_write_through_the_owners_ehr_id_reaches_the_owner_alone_and_claims_no_copy, every_refusal_names_the_controlling_system_and_quotes_no_other_part_of_the_request, with_the_owner_up_a_write_through_the_copys_ehr_id_is_still_a_409

CP-30

34 tests.

• app/ferrofed-engine/tests/it/fanout/all_or_nothing.rs: a_time_out_and_a_node_error_together_are_a_504, an_unreachable_node_is_offline_and_a_504, one_node_error_fails_the_query_424_with_the_nodes_error, one_node_timing_out_fails_the_query_504_with_the_envelope
• app/ferrofed-engine/tests/it/fanout/best_effort.rs: a_consent_denied_node_is_a_200_with_the_rest_in_either_mode, a_node_error_under_best_effort_is_a_200_naming_the_nodes_error, a_time_out_under_best_effort_is_a_200_with_the_answering_rows, an_offline_node_under_best_effort_is_a_200_reporting_it, every_node_not_resolved_is_a_200_with_no_rows_in_either_mode, members_out_of_scope_never_clear_complete_in_either_mode
• app/ferrofed-engine/tests/it/fanout/consent.rs: a_403_carrying_a_listed_code_is_consent_denied_and_fails_nothing
• app/ferrofed-engine/tests/it/oversized.rs: an_answer_past_the_bound_is_node_error_and_fails_the_query_424
• app/ferrofed-server/tests/it/completeness.rs: all_stated_explicitly_is_accepted_and_fails_closed, partial_where_best_effort_is_not_offered_is_refused, partial_where_offered_is_a_200_with_the_answering_nodes_rows
• app/ferrofed-server/tests/it/consent.rs: a_member_the_prefilter_leaves_in_is_asked_and_its_refusal_still_reported, a_node_the_localizer_names_still_refuses_and_the_query_succeeds, with_no_consent_service_a_node_refusal_is_reported_and_the_query_succeeds
• app/ferrofed-server/tests/it/e2e/track3.rs (e2e): an_undirected_query_asks_only_the_members_the_localizer_names
• app/ferrofed-server/tests/it/e2e/track4.rs (e2e): a_node_answering_an_error_fails_the_query_424_and_is_named_node_error, a_slow_node_is_abandoned_at_the_per_node_timeout_and_named_time_out, an_unreachable_node_fails_the_query_504_and_is_named_offline, found_nowhere_and_consent_denied_are_200_and_never_424, partial_returns_the_answering_nodes_rows_only_where_offered
• app/ferrofed-server/tests/it/e2e/track7.rs (e2e): a_member_the_consent_service_admits_still_refuses_and_the_query_succeeds, with_no_consent_service_a_node_refusal_is_reported_and_the_query_succeeds
• app/ferrofed-server/tests/it/errors.rs: a_424_and_a_504_echo_the_clients_q, a_node_error_under_all_or_nothing_is_a_424_carrying_the_envelope, a_node_not_found_inside_a_fan_out_is_a_node_error_and_a_424, a_node_timing_out_under_all_or_nothing_is_a_504_carrying_the_envelope, a_node_timing_out_under_best_effort_is_a_200_reporting_it, an_unreachable_node_under_all_or_nothing_is_a_504_carrying_the_envelope
• app/ferrofed-server/tests/it/facade/query.rs: a_node_error_carries_the_nodes_message_with_the_subject_masked
• app/ferrofed-server/tests/it/overload.rs: a_member_answer_past_the_read_bound_is_node_error_and_fails_the_query_424

CP-31

19 tests.

• app/ferrofed-engine/tests/it/fanout/all_or_nothing.rs: a_node_answering_after_the_overall_budget_contributes_nothing, one_node_timing_out_fails_the_query_504_with_the_envelope
• app/ferrofed-engine/tests/it/fanout/budget.rs: a_longer_wait_leaves_the_configured_budget_in_force, a_shortened_budget_abandons_a_node_the_configured_one_would_wait_for, a_zero_wait_asks_no_node_and_reports_every_node_time_out, abandoning_one_node_never_aborts_another_in_flight, time_spent_before_the_dispatch_comes_out_of_the_overall_budget
• app/ferrofed-engine/tests/it/fanout/decision.rs: a_client_wait_shortens_the_budget_and_never_extends_it
• app/ferrofed-server/tests/it/e2e/track4.rs (e2e): a_client_wait_shortens_the_budget_and_never_extends_it, a_slow_node_is_abandoned_at_the_per_node_timeout_and_named_time_out
• app/ferrofed-server/tests/it/endpoint_report.rs: latency_is_reported_exactly_for_the_endpoints_dispatched_to
• app/ferrofed-server/tests/it/timeouts.rs: a_longer_wait_never_extends_the_configured_budget, a_shorter_wait_shortens_the_budget_and_is_reported, a_shorter_wait_under_partial_returns_the_answering_rows, a_slow_node_under_the_default_timeouts_answers_the_504_envelope, a_zero_wait_asks_no_node_and_reports_every_node_time_out, respond_async_beside_a_shorter_wait_still_shortens_the_budget, respond_async_never_exempts_a_request_from_the_overall_budget, the_overall_budget_fires_before_the_tightest_accepted_request_timeout

CP-32

159 tests.

• app/ferrofed-engine/tests/it/fanout/aggregate.rs: a_count_past_what_a_json_number_holds_is_an_error, a_node_that_does_not_answer_fails_the_aggregate_504, a_recombining_plan_is_refused_best_effort_before_dispatch, a_value_the_recombination_cannot_use_fails_the_query_424, an_avg_over_integers_answers_an_integer, the_node_answers_recombine_into_one_row
• app/ferrofed-engine/tests/it/fanout/distinct.rs: a_row_two_nodes_return_takes_one_slot_of_the_limit
• app/ferrofed-engine/tests/it/fanout/order.rs: a_bounded_offset_page_is_sliced_from_k_plus_n_rows_per_node, a_bounded_window_out_of_the_federation_order_fails_the_query_424, a_cut_out_of_the_federation_order_fails_the_query_424, a_node_answering_past_its_limit_fails_the_query_424, interleaved_node_answers_merge_into_the_global_top_n, tied_keys_merge_identically_whichever_node_answers_first, under_best_effort_a_disagreeing_node_leaves_the_others_top_n
• app/ferrofed-server/tests/it/aggregate.rs: a_failing_node_fails_the_aggregate_424_with_no_row, a_partial_request_for_a_recombined_aggregate_is_refused_400, the_client_receives_one_recombined_row_in_its_own_columns, with_nothing_declared_the_aggregate_is_refused_400
• app/ferrofed-server/tests/it/distinct.rs: a_duplicate_straddling_the_page_edge_is_answered_once
• app/ferrofed-server/tests/it/e2e/aggregate.rs (e2e): an_undirected_avg_is_the_mean_weighted_by_the_counts_each_node_returns
• app/ferrofed-server/tests/it/e2e/track5.rs (e2e): an_undirected_aggregate_is_recombined_or_refused_and_a_directed_one_answered, order_by_and_limit_return_the_global_top_rows_deterministically
• app/ferrofed-server/tests/it/node_fetch.rs: a_bounded_page_sends_every_node_k_plus_n_as_fetch, a_fetch_member_larger_than_the_aql_limit_keeps_the_limit, a_fetch_member_smaller_than_the_aql_limit_is_the_count, a_query_with_a_limit_sends_every_node_that_limit_as_fetch, an_offset_member_past_the_aql_limit_answers_no_row, the_composed_window_is_held_to_the_configured_bound, the_offset_member_starts_past_the_aql_offset
• app/ferrofed-server/tests/it/order.rs: a_bounded_offset_page_asks_each_node_for_k_plus_n_rows, a_bounded_offset_page_is_computed_afresh_and_carries_no_cursor, a_distinct_function_of_an_unselected_path_under_a_limit_is_refused_400, a_distinct_function_of_selected_paths_returns_the_same_rows_on_every_repeat, a_distinct_whole_object_under_a_limit_is_refused_400, a_node_out_of_the_federation_order_fails_the_query_424, a_page_past_the_configured_window_is_refused_400_naming_the_bound, an_ehr_only_query_returns_the_same_rows_on_every_repeat, bounded_pages_tied_across_their_edges_repeat_and_tile, the_client_gets_the_global_top_n_without_the_hidden_column, the_reject_strategy_refuses_any_offset_past_zero_400
• app/ferrofed-server/tests/it/order_key.rs: a_limit_on_a_dv_text_key_is_refused_400_and_asks_no_node, top_on_a_dv_text_key_is_refused_400_and_asks_no_node, with_no_limit_a_dv_text_key_is_answered_in_one_order_on_every_repeat
• crates/openehr-federation/tests/it/aql/aggregate.rs: a_distinct_count_does_not_decompose, a_function_left_out_of_the_declaration_is_refused, a_plain_column_beside_an_aggregate_is_refused, a_recombined_aggregate_is_never_answered_best_effort, an_aggregate_directed_to_two_endpoints_is_recombined, an_indecomposable_aggregate_suggests_both_alternatives, avg_is_asked_of_each_node_as_its_sum_and_count, distinct_breaks_the_decomposition, every_declared_function_but_avg_is_dispatched_as_written, several_aggregates_map_to_their_node_columns, the_columns_are_the_clients_query_not_the_dispatched_one, with_nothing_declared_every_undirected_aggregate_is_refused
• crates/openehr-federation/tests/it/aql/comparable.rs: a_bounded_page_on_a_comparable_key_is_answered, a_bounded_page_on_an_incomparable_key_is_refused, a_later_incomparable_key_is_refused_and_located, a_limit_on_a_collection_is_refused, a_limit_on_a_dv_text_order_key_is_refused, a_limit_on_a_path_the_rm_does_not_resolve_is_refused, a_limit_on_a_whole_rm_object_is_refused, a_limit_on_an_element_value_is_refused, a_limit_on_primitives_and_ordered_data_values_is_answered, an_unscoped_limit_on_an_incomparable_key_is_refused, the_fetch_member_on_an_incomparable_key_is_refused, top_on_an_incomparable_key_is_refused, under_distinct_a_bounded_page_with_a_whole_rm_object_is_refused, under_distinct_a_limit_on_an_incomparable_order_by_key_is_refused, under_distinct_a_limit_with_a_collection_is_refused, under_distinct_a_limit_with_a_dv_text_is_refused, under_distinct_a_limit_with_a_path_the_rm_does_not_resolve_is_refused, under_distinct_a_limit_with_a_whole_rm_object_is_refused, under_distinct_a_limit_with_an_element_value_is_refused, under_distinct_a_limit_with_ordered_data_values_and_primitives_is_pinned, under_distinct_with_no_limit_an_incomparable_path_is_not_a_key, with_no_limit_an_incomparable_key_is_sent_as_written_and_ordered_at_the_tier
• crates/openehr-federation/tests/it/aql/dedup.rs: a_limit_without_order_by_is_ordered_on_the_uid, under_order_by_the_row_key_is_the_dedup_key
• crates/openehr-federation/tests/it/aql/function.rs: a_date_and_time_function_is_forwarded_across_a_fan_out, a_function_name_is_read_in_any_case, a_function_outside_aql_directed_to_two_endpoints_is_refused, a_function_outside_aql_is_refused_before_the_aggregate_beside_it, a_function_outside_aql_is_refused_in_a_patient_query_across_nodes, a_function_outside_aql_nested_in_an_aql_function_is_refused, a_numeric_function_is_forwarded_across_a_fan_out, a_string_function_is_forwarded_across_a_fan_out, an_aggregate_follows_the_decomposition_rules, an_undirected_function_outside_aql_in_select_is_refused, an_undirected_function_outside_aql_in_where_is_refused, the_refusal_suggests_both_alternatives, the_terminology_function_is_forwarded_across_a_fan_out
• crates/openehr-federation/tests/it/aql/golden.rs: golden_case_05_is_refused_under_reject_and_paged_under_bounded, golden_case_06_is_refused_with_nothing_declared_and_recombined_under_the_default_set
• crates/openehr-federation/tests/it/aql/hygiene.rs: no_pushed_row_key_carries_the_patient
• crates/openehr-federation/tests/it/aql/offset.rs: a_fetch_member_larger_than_the_aql_limit_keeps_the_rows_the_limit_leaves, a_fetch_member_smaller_than_the_aql_limit_is_the_count, a_member_offset_that_overflows_the_skip_is_past_the_bound, a_page_past_the_bound_is_refused_naming_the_bound, a_page_whose_window_is_the_bound_is_accepted, a_window_that_overflows_is_past_the_bound, an_ehr_only_page_asks_each_node_for_k_plus_n_rows_tie_broken_on_the_ehr_id, an_offset_member_adds_to_the_aql_offset, an_offset_member_beside_the_aql_limit_is_refused_under_the_reject_strategy, an_offset_member_past_the_aql_limit_selects_no_row, an_offset_with_no_limit_is_refused_under_the_bounded_strategy, an_offset_with_no_order_by_is_refused_under_the_bounded_strategy, an_unscoped_query_is_paged_the_same_way, the_bounded_strategy_asks_each_node_for_k_plus_n_rows_and_never_pushes_offset, the_composed_window_is_held_to_the_bound, the_offset_and_fetch_members_page_like_the_clauses_under_the_bounded_strategy, the_reject_strategy_refuses_an_offset_past_zero
• crates/openehr-federation/tests/it/aql/order.rs: a_containment_with_no_versioned_object_is_keyed_on_its_ehr, a_folder_is_never_a_key_and_a_query_with_no_key_is_dispatched_as_written, a_patient_query_scoped_to_one_ehr_pushes_no_ehr_key, a_selected_ehr_id_is_the_tie_break_where_it_is, a_version_outranks_the_ehr_and_the_ehr_outranks_its_status, an_ehr_only_query_is_tie_broken_on_the_ehr_id, an_ehr_status_with_no_ehr_class_is_keyed_on_its_uid, under_distinct_a_bounded_page_with_an_unpinned_function_is_refused, under_distinct_a_function_of_selected_paths_is_pinned_by_them, under_distinct_a_limit_with_a_function_of_an_unselected_path_is_refused, under_distinct_a_limit_with_a_value_from_outside_the_row_is_refused, under_distinct_an_ehr_only_query_gets_no_ehr_id_column, under_distinct_an_unpinned_function_with_no_limit_is_answered, without_distinct_a_function_column_is_pinned_by_the_row_key
• crates/openehr-federation/tests/it/aql/rules.rs: an_undirected_aggregate_is_refused_with_its_reason
• crates/openehr-federation/tests/it/combine.rs: a_node_that_does_not_answer_one_row_is_refused, a_value_of_the_wrong_kind_refuses_its_node_and_leaves_no_row, a_value_the_gateway_cannot_write_exactly_is_an_error_never_a_rounding, an_aggregate_over_no_value_is_null_and_a_count_is_zero, an_avg_whose_sum_and_count_disagree_refuses_its_node, avg_over_integers_is_the_nearest_integer_a_tie_to_the_even_one, avg_over_integers_rounds_once_over_the_federation_sum_and_count, avg_with_a_real_node_sum_is_the_decimal_mean, every_recombined_function_is_the_aggregate_over_the_union, min_and_max_over_date_times_compare_instants_and_keep_the_written_value, reals_add_in_decimal_arithmetic, the_recombination_does_not_depend_on_the_order_the_nodes_answered_in, the_recombined_row_is_cut_at_the_limit_and_offset, values_no_one_order_compares_refuse_every_node_that_holds_one, with_no_answer_there_is_no_row
• crates/openehr-federation/tests/it/dedup/distinct.rs: under_dedup_a_node_cut_on_two_case_variants_is_refused
• crates/openehr-federation/tests/it/dedup/order.rs: a_case_variant_copy_at_a_page_edge_ranks_as_its_version_and_keeps_its_text, a_node_that_orders_uids_byte_for_byte_across_case_is_refused_at_its_cut, a_suppressed_copy_does_not_take_a_slot_of_the_limit, without_dedup_a_uid_orders_by_code_point_as_sent
• crates/openehr-federation/tests/it/dedup/properties.rs: dedup_with_order_by_limit_and_a_bounded_page_is_the_page_of_the_deduplicated_union
• crates/openehr-federation/tests/it/distinct.rs: a_duplicate_straddling_a_page_edge_takes_one_slot, distinct_runs_before_the_limit, distinct_with_order_by_and_a_bounded_page_is_the_page_of_the_distinct_union, distinct_without_order_by_keeps_limit_distinct_values_of_the_union
• crates/openehr-federation/tests/it/merge.rs: a_cut_node_out_of_the_federation_order_is_refused, a_node_whose_k_plus_n_rows_disagree_with_the_federation_order_is_refused, an_uncut_node_may_answer_in_any_order, the_bounded_offset_page_is_the_page_of_the_full_merged_set, the_bounded_offset_page_matches_the_full_merge_for_every_split, the_merge_does_not_depend_on_the_order_the_nodes_answered_in, the_pushed_down_merge_is_the_order_and_limit_of_the_union

CP-33

53 tests.

• app/ferrofed-server/tests/it/caller_bindings.rs: a_caller_with_no_query_has_no_binding, another_caller_never_sees_the_binding, the_caller_who_queried_is_routed_by_its_binding_first
• app/ferrofed-server/tests/it/collision_clear.rs: a_cleared_collision_that_still_stands_is_probed_and_refused_409_again, a_remedied_collision_reads_from_the_claimant_left_once_cleared, a_write_after_the_clear_is_never_probed_for, the_clear_forgets_the_binding_of_every_session, the_clear_is_recorded_with_its_operator_listed_and_names_no_patient_identifier
• app/ferrofed-server/tests/it/contribution_write.rs: a_contribution_without_a_target_is_never_probed_for
• app/ferrofed-server/tests/it/created_ehr_id.rs: a_binding_placing_the_ehr_id_at_a_refuses_a_create_at_b, a_create_at_b_of_an_ehr_id_the_index_holds_at_a_is_refused_and_sends_nothing, an_unknown_ehr_id_is_created_where_named_and_then_indexed_there, two_creates_racing_for_one_ehr_id_at_two_members_raise_the_index_insert_alarm
• app/ferrofed-server/tests/it/e2e/track11.rs (e2e): a_read_and_a_query_of_the_duplicate_are_refused_and_only_the_probe_reaches_a_node, a_versioned_write_no_earlier_step_routes_is_refused_and_no_node_is_asked, once_the_index_holds_both_claimants_no_read_or_write_reaches_either_node
• app/ferrofed-server/tests/it/e2e/track6.rs (e2e): a_follow_up_read_of_a_row_reaches_the_cdr_that_holds_it_with_its_uid_unchanged, an_unseen_ehr_id_is_probed_read_only_and_a_write_to_it_is_never_probed
• app/ferrofed-server/tests/it/ehr_id_collision.rs: a_binding_collision_names_both_claimants_and_raises_one_incident, a_probe_collision_is_a_409_naming_both_with_one_incident_and_neither_is_read, a_write_in_collision_is_refused_409_and_reaches_no_node, an_ehr_id_that_is_no_uuid_is_never_named_by_an_incident, an_explicit_target_routes_an_ehr_id_in_collision_to_the_named_node, no_incident_or_log_line_names_a_patient_identifier, the_index_insert_alarm_fires_once_and_the_index_then_routes_neither, the_querying_callers_binding_finds_the_collision_first_and_routes_neither
• app/ferrofed-server/tests/it/ehr_scope.rs: two_members_holding_the_ehr_id_are_a_409_and_neither_is_queried
• app/ferrofed-server/tests/it/fhir/prescriptions/read.rs: an_ehr_id_two_members_claim_refuses_the_read_with_one_incident
• app/ferrofed-server/tests/it/follow_up.rs: a_version_read_reaches_the_node_byte_identical_and_carries_no_identifier, a_version_read_whose_creator_the_registry_does_not_map_falls_to_the_probe, a_versioned_write_no_earlier_step_locates_reaches_its_creator_by_step_4, a_versioned_write_whose_path_carries_no_version_is_still_a_400_with_no_earlier_step, an_imported_copy_is_read_at_the_endpoint_the_client_names, an_imported_copy_is_read_where_the_index_places_the_path_ehr_id_never_at_its_creator, with_no_target_binding_or_index_a_version_read_reaches_its_creator_by_step_4
• app/ferrofed-server/tests/it/path_ehr_id/order.rs: a_held_binding_wins_over_the_index, a_step_naming_two_members_names_no_owner_and_no_later_step_picks_one, step_4_names_no_member_for_a_creating_system_id_the_registry_does_not_route, step_4_names_the_member_whose_system_id_is_the_creating_system_id, the_explicit_target_wins_over_a_binding_and_the_index, the_index_answers_when_no_target_and_no_binding_does
• app/ferrofed-server/tests/it/path_ehr_id/probe.rs: a_read_no_earlier_step_routes_goes_to_the_one_member_the_probe_finds, a_read_of_the_ehr_itself_is_answered_by_the_owners_probe_answer, a_resolution_teaches_the_index_and_a_follow_up_goes_to_the_resolving_member, the_index_never_overrides_an_explicit_target, the_probe_teaches_the_index_and_a_later_write_is_routed_by_it_unprobed
• app/ferrofed-server/tests/it/path_ehr_id/refusals.rs: a_member_answering_the_probe_with_an_error_leaves_the_owner_unknown, a_member_that_does_not_answer_the_probe_in_time_leaves_the_owner_unknown, a_read_no_member_holds_is_a_404_no_destination, a_write_no_earlier_step_routes_is_a_400_and_probes_nobody, two_members_holding_the_ehr_id_are_a_409_naming_both_and_neither_is_read
• app/ferrofed-server/tests/it/versioned_write.rs: a_versioned_write_the_index_routes_reaches_its_controlling_cdr_unprobed, no_write_without_a_target_is_ever_probed_for

CP-33a

3 tests.

• tools/ferrofed-testkit/tests/it/e2e/admission.rs (e2e): a_candidate_sharing_a_members_system_id_is_reported_and_never_admitted
• tools/ferrofed-testkit/tests/it/e2e/node_profile.rs (e2e): ferroehr_is_checked_against_the_identifier_integrity_conditions
• tools/ferrofed-testkit/tests/it/e2e/node_profile/ehrbase.rs (e2e): ehrbase_is_checked_against_the_identifier_integrity_conditions

CP-34

30 tests.

• app/ferrofed-server/src/facade/route/fan_out.rs: a_failed_member_is_never_reported_as_overall_success
• app/ferrofed-server/tests/it/definition.rs: a_definition_request_carries_only_what_its_operation_declares, a_definition_request_without_a_target_is_refused_and_no_node_is_asked, a_malformed_declared_value_is_refused_before_the_missing_target, a_nodes_own_error_passes_through_as_the_node_sent_it, a_star_an_unknown_endpoint_and_several_endpoints_are_refused, a_template_list_is_the_one_named_nodes_answer_and_never_a_union, a_template_upload_with_a_target_reaches_only_that_node_byte_identical, the_registry_keeps_its_stored_queries_and_templates_still_route_to_one_node, without_the_registry_a_stored_query_definition_is_the_named_nodes, without_the_registry_a_versioned_stored_query_put_in_another_media_type_is_refused, without_the_registry_a_versioned_stored_query_put_is_the_named_nodes
• app/ferrofed-server/tests/it/e2e/track9_surface.rs (e2e): a_definition_request_routes_to_the_one_named_node
• app/ferrofed-server/tests/it/its_rest_areas/definition.rs: the_definition_declaration_states_that_a_request_goes_to_the_one_named_node, the_definition_declaration_states_the_template_fan_out_only_where_offered, the_definition_declaration_states_where_stored_queries_are_held
• app/ferrofed-server/tests/it/options.rs: the_definition_area_declares_nothing_offered, the_template_fan_out_upload_follows_the_configuration
• app/ferrofed-server/tests/it/stored/declaration.rs: without_the_registry_a_definition_is_routed_and_no_name_is_invoked
• app/ferrofed-server/tests/it/template_fan_out.rs: a_definition_request_other_than_an_upload_still_routes_to_one_node, a_member_past_its_timeout_is_reported_and_the_others_keep_the_template, a_named_subset_reaches_only_its_members_and_reports_the_rest_excluded, a_plain_upload_naming_no_endpoint_never_fans_out, a_plain_upload_naming_one_endpoint_routes_to_that_node_alone, a_rejecting_nodes_message_is_carried_and_no_other_body_is, a_star_beside_an_organisation_naming_fewer_members_is_a_conflict, every_member_accepting_answers_success_with_every_member_named, every_member_rejecting_is_a_failed_dependency_naming_each, with_one_member_rejecting_the_answer_is_partial_and_names_it, with_the_setting_off_a_star_upload_is_refused_and_nothing_is_sent

CP-35

13 tests.

• app/ferrofed-server/tests/it/e2e/attributes.rs (e2e): the_example_query_adds_each_nodes_attributes_over_two_cdr_nodes
• app/ferrofed-server/tests/it/e2e/crossref.rs (e2e): one_result_set_over_two_cdr_nodes_and_no_identifier_on_the_wire
• app/ferrofed-server/tests/it/e2e/track1.rs (e2e): an_unmodified_client_gets_one_single_cdr_shaped_result_set, the_columns_are_the_same_whichever_node_answers_first
• app/ferrofed-server/tests/it/endpoint_attributes.rs: a_query_selecting_no_attribute_keeps_the_single_cdr_row_shape, an_alias_resolves_a_collision_and_both_columns_survive, an_alias_that_leaves_the_collision_standing_is_refused_400, the_example_query_answers_the_example_columns_and_rows
• app/ferrofed-server/tests/it/facade/query.rs: a_patient_query_is_one_result_set_over_both_nodes
• crates/openehr-federation/tests/it/aql/attribute.rs: a_query_selecting_no_attribute_keeps_the_single_cdr_shape, an_alias_resolves_the_collision_and_both_columns_survive, an_alias_that_leaves_the_collision_standing_is_refused, the_example_query_names_its_attributes_and_asks_no_node_for_them

CP-36

43 tests.

• app/ferrofed-server/tests/it/consent.rs: a_directed_query_reaches_the_node_that_checks_consent_itself, a_member_the_prefilter_denies_is_reported_and_never_contacted, a_member_the_prefilter_leaves_in_is_asked_and_its_refusal_still_reported, a_node_the_localizer_names_still_refuses_and_the_query_succeeds, a_prefilter_that_cannot_answer_leaves_every_candidate_to_its_node, the_prefilter_runs_after_localization_over_its_candidates_only, with_no_consent_service_a_node_refusal_is_reported_and_the_query_succeeds
• app/ferrofed-server/tests/it/consent_everywhere.rs: the_read_by_subject_never_contacts_a_member_the_prefilter_denies, the_read_by_subject_whose_holders_are_all_denied_is_consent_denied
• app/ferrofed-server/tests/it/consent_withheld/mod.rs: a_read_by_subject_another_member_holds_is_served_with_the_exclusion_withheld, a_read_by_subject_only_a_withheld_member_holds_answers_as_one_no_member_holds, a_withheld_exclusion_is_reported_as_a_member_without_the_patient, a_withheld_exclusion_reads_as_the_others_when_the_crossref_cannot_answer, a_withheld_exclusion_reads_exactly_as_a_member_that_does_not_know_the_patient, by_default_the_exclusion_is_disclosed_and_declared, the_configured_setting_withholds_the_exclusion_and_is_declared, with_disclosure_the_exclusion_stays_consent_denied
• app/ferrofed-server/tests/it/consent_withheld/node.rs: a_node_refusal_is_reported_as_a_member_without_the_patient, a_node_refusal_reads_exactly_as_a_member_that_does_not_know_the_patient, a_read_by_subject_the_holder_refuses_answers_as_one_no_member_holds, a_routed_read_the_node_refuses_answers_subject_unavailable, an_ask_all_probe_the_holder_refuses_answers_as_one_no_member_holds, with_disclosure_a_node_refusal_stays_consent_denied
• app/ferrofed-server/tests/it/consent_withheld/not_asked.rs: a_withheld_deployment_answers_a_prefilter_that_did_not_ask_as_one_that_found_nothing
• app/ferrofed-server/tests/it/consent_withheld/routed.rs: a_read_of_an_ehr_id_the_prefilter_excluded_is_left_to_its_node, a_targeted_read_the_node_refuses_reads_exactly_as_one_the_node_cannot_find, an_ask_all_probe_a_member_refuses_reads_exactly_as_one_no_member_answers
• app/ferrofed-server/tests/it/contact_point/withheld.rs: a_restricted_patient_and_an_unknown_one_answer_alike, an_excluded_member_and_one_without_the_patient_answer_alike, the_deployments_own_caller_still_sees_the_exclusion_disclosed
• app/ferrofed-server/tests/it/e2e/pixm.rs (e2e): a_pix_resolved_query_asks_only_the_member_that_knows_the_patient
• app/ferrofed-server/tests/it/e2e/restriction.rs (e2e): a_restriction_at_one_node_is_honoured_by_the_federated_query
• app/ferrofed-server/tests/it/e2e/track7.rs (e2e): a_directed_query_is_consent_checked_at_the_node, a_member_the_consent_service_admits_still_refuses_and_the_query_succeeds, a_member_the_consent_service_denies_is_reported_and_never_dispatched_to, with_no_consent_service_a_node_refusal_is_reported_and_the_query_succeeds
• app/ferrofed-server/tests/it/mitz/decision.rs: a_denial_and_a_failure_together_deny_one_and_leave_the_other_to_its_node, a_member_mitz_denies_is_consent_denied_and_never_asked, a_member_mitz_permits_is_asked_and_its_node_still_decides
• app/ferrofed-server/tests/it/mitz/grant.rs: mitz_is_asked_with_the_token_the_grant_obtained_and_reused
• app/ferrofed-server/tests/it/pdqm/flow.rs: an_identifier_the_supplier_knows_no_patient_for_is_not_resolved_anywhere
• app/ferrofed-server/tests/it/resolution.rs: a_member_the_patient_is_not_known_at_is_not_resolved_and_never_asked, a_patient_known_nowhere_is_200_with_no_rows_and_every_member_not_resolved

CP-37

29 tests.

• app/ferrofed-server/tests/it/directive.rs: a_selected_endpoint_attribute_is_added_to_the_rows_and_asked_of_no_node
• app/ferrofed-server/tests/it/e2e/attributes.rs (e2e): the_example_query_adds_each_nodes_attributes_over_two_cdr_nodes
• app/ferrofed-server/tests/it/e2e/track3.rs (e2e): a_directive_selects_the_node_set_and_leaves_the_row_shape_alone
• app/ferrofed-server/tests/it/endpoint_attributes.rs: a_query_selecting_no_attribute_keeps_the_single_cdr_row_shape, an_attribute_key_among_node_keys_keeps_its_place, every_attribute_reads_the_registry_entry_of_its_endpoint, ordering_on_an_attribute_alone_orders_the_endpoints_at_the_tier, the_attribute_elsewhere_than_select_and_order_by_is_still_refused_400, the_example_query_answers_the_example_columns_and_rows, under_distinct_a_shared_organisation_collapses_the_rows, under_distinct_an_endpoint_id_keeps_the_rows_of_two_endpoints_apart
• crates/openehr-federation/tests/it/aql/attribute.rs: a_query_selecting_no_attribute_keeps_the_single_cdr_shape, every_attribute_the_table_lists_is_selectable, ordering_on_an_attribute_is_accepted_with_or_without_a_limit, the_example_query_names_its_attributes_and_asks_no_node_for_them, under_distinct_the_node_is_asked_only_its_own_columns
• crates/openehr-federation/tests/it/aql/endpoint_order.rs: an_attribute_key_alone_is_the_tier_key_and_the_node_keeps_the_tie_break_and_limit, an_attribute_key_keeps_its_place_among_the_node_keys, an_attribute_ordered_on_and_not_selected_follows_the_selected_ones, an_unscoped_query_ordered_on_an_attribute_sends_no_directive
• crates/openehr-federation/tests/it/attributes.rs: distinct_on_attributes_alone_keeps_one_row_per_value_and_refuses_no_cut_node, each_row_keeps_the_attributes_of_its_endpoint_in_the_tier_order, under_distinct_a_shared_attribute_value_collapses_the_rows, under_distinct_rows_of_two_endpoints_are_two_values, without_an_order_each_row_keeps_its_endpoint_attributes
• crates/openehr-federation/tests/it/endpoint_order.rs: an_attribute_key_after_a_node_key_breaks_its_ties, an_attribute_key_alone_orders_the_endpoints_and_the_uid_breaks_the_tie, an_attribute_key_before_a_node_key_orders_first_and_a_tie_falls_to_the_node_key, an_attribute_value_compares_as_a_string_cell_does

CP-40

62 tests.

• app/ferrofed-server/tests/it/definition.rs: the_registry_keeps_its_stored_queries_and_templates_still_route_to_one_node
• app/ferrofed-server/tests/it/e2e/store.rs (e2e): a_stored_query_database_of_the_earlier_release_boots_with_every_definition_and_refusal_kept
• app/ferrofed-server/tests/it/e2e/stored_postgres.rs (e2e): a_row_naming_its_patient_by_a_literal_is_never_served_or_run, a_version_one_instance_stored_is_run_by_name_at_the_other, two_gateways_racing_one_new_version_store_exactly_one, two_gateways_racing_unversioned_puts_store_two_versions_or_refuse_one
• app/ferrofed-server/tests/it/e2e/track9_surface.rs (e2e): a_definition_fan_out_reports_a_one_node_rejection_as_partial, a_stored_query_is_held_at_the_gateway_and_runs_by_name_over_both_members
• app/ferrofed-server/tests/it/its_rest_areas/definition.rs: the_definition_declaration_states_the_distribution_only_where_offered
• app/ferrofed-server/tests/it/query_get.rs: a_stored_get_reads_a_q_key_as_a_query_parameter, a_stored_query_runs_by_get_with_and_without_a_version
• app/ferrofed-server/tests/it/stored/assigned.rs: a_distribution_sends_the_version_the_registry_assigned, a_literal_patient_is_refused_before_any_version_is_assigned, a_new_name_is_stored_at_one_zero_zero_and_named_in_location, an_unversioned_put_in_the_reserved_namespace_is_refused, concurrent_unversioned_puts_each_store_a_version_of_their_own, the_next_patch_follows_the_newest_version_by_number_and_none_is_replaced
• app/ferrofed-server/tests/it/stored/declaration.rs: options_declares_the_registry_and_the_methods_it_serves
• app/ferrofed-server/tests/it/stored/files.rs: a_definition_file_is_read_listed_and_run_by_name, a_held_version_put_naming_members_at_a_read_only_registry_is_a_405, a_put_at_a_read_only_registry_is_a_405_naming_the_read_methods, the_admin_distribution_at_a_read_only_registry_is_a_405_allowing_nothing
• app/ferrofed-server/tests/it/stored/held.rs: a_held_definition_naming_its_patient_by_a_literal_refuses_the_start, a_literal_a_shared_store_gains_after_the_start_is_never_served
• app/ferrofed-server/tests/it/stored/invocation.rs: a_failing_member_fails_the_stored_query_and_the_envelope_still_names_it, a_stored_query_invoked_by_name_fans_out_and_names_the_gateways_definition, no_version_runs_the_latest_and_a_prefix_runs_the_highest_it_matches, query_parameters_bind_into_the_stored_query_as_if_submitted_inline
• app/ferrofed-server/tests/it/stored/reserved.rs: a_put_into_the_reserved_namespace_is_refused_and_the_held_text_stands, a_store_holding_a_definition_in_the_reserved_namespace_refuses_the_start, each_section_query_runs_by_name_and_no_patient_identifier_reaches_a_node, the_section_queries_are_listed_and_read_at_their_immutable_version
• app/ferrofed-server/tests/it/stored/storage.rs: a_definition_naming_the_patient_by_a_literal_is_refused_at_put, a_definition_the_rewrite_refuses_whatever_is_bound_is_refused_at_put, a_second_put_of_a_held_name_and_version_is_refused_and_the_text_stands, a_stored_definition_reads_back_as_an_its_rest_stored_query_and_lists, a_stored_version_survives_a_restart_and_stays_immutable, the_store_holds_no_identifier_after_a_definition_is_stored_and_invoked
• app/ferrofed-server/tests/it/stored_fan_out.rs: a_targeted_definition_is_refused_for_distribution_and_stays_executable, an_invocation_runs_the_registry_aql_even_where_a_nodes_copy_differs, config_check_refuses_definition_fan_out_without_the_registry, options_declares_definition_fan_out_only_where_offered_beside_the_registry, the_drift_report_names_matching_differing_and_missing_members, with_every_member_failing_the_registry_still_holds_the_definition, with_one_member_failing_the_distribution_is_partial_and_the_registry_holds_it, with_the_setting_off_a_get_naming_members_is_refused_and_reads_nothing, with_the_setting_off_a_put_naming_members_is_refused_and_stores_nothing
• app/ferrofed-server/tests/it/stored_location.rs: a_versioned_put_names_the_stored_query_relative_to_its_request, an_unversioned_put_names_the_stored_query_relative_to_its_request, with_a_public_url_both_puts_name_the_absolute_url_of_the_stored_query, with_a_public_url_the_admin_distribution_names_the_stored_query, without_a_public_url_the_admin_distribution_names_no_location
• app/ferrofed-server/tests/it/stored_redistribution.rs: a_redistribution_every_member_rejects_is_a_424_and_the_registry_is_unchanged, a_redistribution_one_member_rejects_is_partial_and_the_registry_is_unchanged, a_second_put_of_a_held_version_is_refused_in_every_form, the_admin_action_exists_only_on_the_admin_listener, the_admin_action_reaches_a_member_admitted_after_the_distribution, the_admin_action_refuses_a_held_targeted_definition, the_admin_action_refuses_what_it_cannot_distribute_and_sends_nothing, the_admin_action_sends_the_held_version_to_the_member_that_missed_it, the_admin_listener_is_refused_off_loopback_without_allow_remote, without_distribution_offered_the_admin_action_is_refused

Track 1

3 tests.

• app/ferrofed-server/tests/it/e2e/crossref.rs (e2e): one_result_set_over_two_cdr_nodes_and_no_identifier_on_the_wire
• app/ferrofed-server/tests/it/e2e/track1.rs (e2e): an_unmodified_client_gets_one_single_cdr_shaped_result_set, the_columns_are_the_same_whichever_node_answers_first

Track 2

7 tests.

• app/ferrofed-server/tests/it/e2e/crossref.rs (e2e): both_patient_carriers_resolve_to_the_same_rows_over_two_cdr_nodes, one_result_set_over_two_cdr_nodes_and_no_identifier_on_the_wire
• app/ferrofed-server/tests/it/e2e/pixm.rs (e2e): a_patient_fed_at_both_members_resolves_through_pix_at_both, a_pix_resolved_query_asks_only_the_member_that_knows_the_patient
• app/ferrofed-server/tests/it/e2e/santempi.rs (e2e): a_patient_each_member_fed_to_santempi_is_answered_by_both
• app/ferrofed-server/tests/it/e2e/track2.rs (e2e): a_selected_subject_column_is_the_input_and_never_asked_of_a_node, the_pix_manager_resolves_both_carriers_to_each_nodes_own_ehr_id

Track 3

6 tests.

• app/ferrofed-server/tests/it/e2e/attributes.rs (e2e): the_example_query_adds_each_nodes_attributes_over_two_cdr_nodes
• app/ferrofed-server/tests/it/e2e/track3.rs (e2e): a_directive_selects_the_node_set_and_leaves_the_row_shape_alone, a_named_member_where_the_patient_does_not_resolve_is_reported_not_errored, an_undirected_query_asks_only_the_members_the_localizer_names, the_endpoint_header_selects_what_the_directive_selects
• app/ferrofed-server/tests/it/e2e/xcpd.rs (e2e): an_undirected_query_asks_only_the_member_ferropix_names_over_iti_55

Track 4

7 tests.

• app/ferrofed-server/tests/it/e2e/track3.rs (e2e): an_undirected_query_asks_only_the_members_the_localizer_names
• app/ferrofed-server/tests/it/e2e/track4.rs (e2e): a_client_wait_shortens_the_budget_and_never_extends_it, a_node_answering_an_error_fails_the_query_424_and_is_named_node_error, a_slow_node_is_abandoned_at_the_per_node_timeout_and_named_time_out, an_unreachable_node_fails_the_query_504_and_is_named_offline, found_nowhere_and_consent_denied_are_200_and_never_424, partial_returns_the_answering_nodes_rows_only_where_offered

Track 5

4 tests.

• app/ferrofed-server/tests/it/e2e/aggregate.rs (e2e): an_undirected_avg_is_the_mean_weighted_by_the_counts_each_node_returns
• app/ferrofed-server/tests/it/e2e/track5.rs (e2e): an_undirected_aggregate_is_recombined_or_refused_and_a_directed_one_answered, duplicates_pass_through_by_default_and_distinct_folds_them_at_the_tier, order_by_and_limit_return_the_global_top_rows_deterministically

Track 6

4 tests.

• app/ferrofed-server/tests/it/e2e/commit.rs (e2e): a_versioned_write_reaches_its_controlling_node_and_never_another
• app/ferrofed-server/tests/it/e2e/track6.rs (e2e): a_follow_up_read_of_a_row_reaches_the_cdr_that_holds_it_with_its_uid_unchanged, a_new_ehr_is_created_at_the_one_node_the_client_names, an_unseen_ehr_id_is_probed_read_only_and_a_write_to_it_is_never_probed

Track 7

6 tests.

• app/ferrofed-server/tests/it/e2e/track7.rs (e2e): a_caller_that_does_not_authenticate_reaches_no_node, a_directed_query_is_consent_checked_at_the_node, a_member_the_consent_service_admits_still_refuses_and_the_query_succeeds, a_member_the_consent_service_denies_is_reported_and_never_dispatched_to, each_node_is_reached_with_its_onward_token_and_told_the_caller, with_no_consent_service_a_node_refusal_is_reported_and_the_query_succeeds

Track 9

7 tests.

• app/ferrofed-server/tests/it/e2e/commit.rs (e2e): a_composition_committed_through_the_gateway_lands_byte_identical_at_one_node, a_versioned_write_reaches_its_controlling_node_and_never_another
• app/ferrofed-server/tests/it/e2e/track9.rs (e2e): an_unmodified_client_given_only_the_base_url_reads_and_writes_at_a_prefix
• app/ferrofed-server/tests/it/e2e/track9_surface.rs (e2e): a_definition_fan_out_reports_a_one_node_rejection_as_partial, a_definition_request_routes_to_the_one_named_node, a_stored_query_is_held_at_the_gateway_and_runs_by_name_over_both_members, the_self_description_lists_the_members_and_demographic_answers_as_declared

Track 10

45 tests.

• app/ferrofed-engine/tests/it/fapi2/mod.rs: a_callers_token_carrying_the_patient_is_never_sent, no_carrier_to_the_server_or_the_node_names_the_patient
• app/ferrofed-engine/tests/it/native.rs: a_request_that_would_carry_a_withheld_identifier_is_never_sent, the_member_is_asked_by_its_ehr_id_alone_and_its_document_comes_back_unchanged
• app/ferrofed-engine/tests/it/native_create.rs: an_update_leaves_once_by_the_members_id_with_its_body_byte_for_byte, the_body_leaves_byte_for_byte_once_and_nothing_else_carries_the_patient
• app/ferrofed-server/tests/it/access/accessor.rs: the_professional_and_the_patient_reach_no_log_or_metric
• app/ferrofed-server/tests/it/access/emergency.rs: the_mark_carries_no_patient_identifier_to_a_log_or_a_node
• app/ferrofed-server/tests/it/access/query.rs: no_patient_template_or_caller_reaches_the_log_a_metric_or_a_node
• app/ferrofed-server/tests/it/contact_point/relayed.rs: no_iua_person_id_reaches_a_node
• app/ferrofed-server/tests/it/e2e/track10.rs (e2e): a_committed_dv_identifier_arrives_at_a_ferroehr_node_byte_identical, the_four_positions_reach_neither_ferroehr_node_on_any_path
• app/ferrofed-server/tests/it/fhir/binary.rs: a_read_asks_the_member_by_its_ehr_id_alone
• app/ferrofed-server/tests/it/fhir/binary_trc.rs: a_document_read_under_another_patients_trc_is_no_data_recorded_and_fetched_nowhere
• app/ferrofed-server/tests/it/fhir/header.rs: the_header_is_the_supplier_s_and_no_header_value_reaches_a_node
• app/ferrofed-server/tests/it/fhir/list/mod.rs: a_native_member_is_asked_for_the_list_by_its_ehr_id_alone
• app/ferrofed-server/tests/it/fhir/list/own_laboratory.rs: a_members_own_report_is_listed_unchanged_but_for_its_url_and_read_unchanged
• app/ferrofed-server/tests/it/fhir/native.rs: a_native_member_is_asked_by_its_ehr_id_alone_and_left_out_of_the_mapped_document
• app/ferrofed-server/tests/it/fhir/patient_grant.rs: a_persons_own_grant_gets_their_summary_and_no_identifier_reaches_a_node_or_a_log
• app/ferrofed-server/tests/it/fhir/prescriptions/dispense.rs: a_dispensation_naming_its_prescription_by_the_faces_reference_alone_is_refused, a_dispensation_reaches_the_owner_alone_by_its_ehr_id_with_its_body_unchanged
• app/ferrofed-server/tests/it/fhir/prescriptions/dispensed.rs: the_dispensation_a_receipt_located_is_read_at_its_member_by_its_ehr_id
• app/ferrofed-server/tests/it/fhir/prescriptions/mod.rs: each_member_is_asked_by_its_ehr_id_alone
• app/ferrofed-server/tests/it/fhir/prescriptions/read.rs: the_member_is_asked_by_its_ehr_id_and_its_own_id_alone
• app/ferrofed-server/tests/it/fhir/prescriptions/trc.rs: a_read_by_id_of_another_patients_prescription_is_no_data_recorded_and_sent_nowhere
• app/ferrofed-server/tests/it/fhir/prescriptions/vread.rs: the_location_a_receipt_answered_reads_back_the_dispensation_it_located
• app/ferrofed-server/tests/it/fhir/prescriptions/withdraw.rs: a_withdrawal_reaches_its_member_alone_with_its_body_unchanged_but_for_its_id
• app/ferrofed-server/tests/it/fhir/receive/inserted.rs: a_persons_own_document_is_marked_as_inserted_by_them_with_no_identifier_added
• app/ferrofed-server/tests/it/fhir/receive/representative.rs: a_representatives_document_names_them_as_every_entrys_provider
• app/ferrofed-server/tests/it/fhir/receive/write.rs: a_document_is_written_to_its_member_by_its_ehr_id_alone
• app/ferrofed-server/tests/it/fhir/summary.rs: the_summary_is_an_eps_document_from_both_members_and_no_identifier_reaches_a_node
• app/ferrofed-server/tests/it/pdqm/flow.rs: neither_identifier_reaches_a_log_line_a_metric_or_a_node
• app/ferrofed-server/tests/it/probed_ehr_id.rs: a_read_whose_ehr_id_is_a_uuid_is_still_resolved_by_the_probe, a_read_whose_ehr_id_is_no_uuid_and_that_nothing_routes_is_refused_and_probes_nobody, an_ehr_id_that_is_no_uuid_is_forwarded_to_the_named_node_alone_and_then_indexed
• app/ferrofed-server/tests/it/stored/reserved.rs: each_section_query_runs_by_name_and_no_patient_identifier_reaches_a_node
• app/ferrofed-server/tests/it/traces/traceparent.rs: an_identifier_hidden_in_the_clients_trace_id_reaches_no_node_and_no_span
• app/ferrofed-server/tests/it/track10/mock.rs: a_committed_dv_identifier_arrives_at_the_node_byte_identical, a_panicking_handler_holding_the_identifier_leaves_it_on_neither_stderr_nor_the_log, the_identifier_in_a_party_identified_predicate_reaches_no_node, the_identifier_in_a_projection_reaches_no_node, the_identifier_in_an_external_ref_predicate_reaches_no_node, the_identifier_in_the_ehr_id_slot_is_never_probed_at_a_node, the_identifier_in_the_query_string_or_a_header_reaches_no_node, the_identifier_on_the_single_node_route_reaches_no_node

Track 11

5 tests.

• app/ferrofed-server/tests/it/e2e/track11.rs (e2e): a_read_and_a_query_of_the_duplicate_are_refused_and_only_the_probe_reaches_a_node, a_versioned_write_no_earlier_step_routes_is_refused_and_no_node_is_asked, once_the_index_holds_both_claimants_no_read_or_write_reaches_either_node
• app/ferrofed-server/tests/it/fhir/prescriptions/read.rs: an_ehr_id_two_members_claim_refuses_the_read_with_one_incident
• tools/ferrofed-testkit/tests/it/e2e/admission.rs (e2e): a_candidate_sharing_a_members_system_id_is_reported_and_never_admitted

Conformance matrix

Every conformance point of the Federation Tier with AQL specification (section 17), the test tracks of section 16.3 and every requirement, with the status FerroFED holds for each. The actor, requirement and track columns are derived from the vendored specification; the status, issue and reason columns are kept by FerroFED. A point is covered only when a test carries its marker and CI runs it.

Gateway points: 35 of 35 covered, 0 planned, 0 deferred.

The other 6 points belong to a member node or to the federation operator, and a gateway is never marked down for them (section 17).

Conformance points

Test tracks

Requirements

46 requirements: 46 reached by a conformance point, 0 by a test track only, 0 by neither.

Obligations checklist

Every normative statement of the Federation Tier with AQL specification, on every page and in both JSON schemas, with the status FerroFED holds for it. The conformance matrix scores the section 17 points; this checklist also holds the obligations in the section prose that are no point of their own. Each row of conformance/obligations.tsv quotes the statement and names the test, the code, the issue or the report behind its status.

Statements: 445, of which 374 fall on the gateway.

Counts per status

Gaps

Every statement FerroFED does not yet meet as the text reads, and every statement where the text disagrees with itself, by status.

Missing

None.

Built, not yet tested

None.

Contradictions and silences found by the audit

Contradictions already reported

Planned

None.

Deferred

Pinned versions

Every version the repository depends on is pinned once, in docs/VERSIONS.md, and scripts/checks/versions.sh fails a change that lets a repeated pin drift from it, this page included. This page summarises the pins that shape the design. Each Item names its rows in docs/VERSIONS.md by their exact names, so the guard can hold every row here to its source.

The other identity bindings (XCPD and the Dutch Generic Functions) are listed in docs/VERSIONS.md with the version each binding uses, and each package is vendored by the issue that first reads it.

Vendored specifications

The specification, its reference implementation, the ITS-REST OpenAPI documents with the SMART on openEHR source of the same release (a DEVELOPMENT-status document in ITS-REST 1.1.0), the AQL source, the IHE FHIR packages and the IHE IUA supplement are vendored verbatim under docs/specs/, each fetched by a committed script and stamped with a PROVENANCE.md that records the source, the pin, the licence and a tree digest.

Licensing

FerroFED is source-available under the Business Source License 1.1: free for every non-production use and for non-commercial production use, with a commercial licence from Cadasto B.V., the Licensor, for any other production use. The authoritative text is LICENSE, with the notice in NOTICE.

Every FerroHEALTH product shares these terms, and the family book’s Licensing and trademarks page states them once: what is free, when you need a commercial licence, how to arrange one, the brand terms of the FerroHEALTH names and marks, and the terms under which contributions are accepted. Where that page and LICENSE differ, LICENSE wins.

What is particular to FerroFED

• The hosted service. The Additional Use Grant excludes offering FerroFED, or a work derived from it, to third parties as a hosted, managed or embedded service through which others discover, query or exchange health records across organisations. That needs a commercial licence in every case (what counts as a hosted service).
• The change date. Each version becomes available under the Apache License 2.0 four years after that version is published. The licence calls that the Change License.
• Contributions. A contribution is licensed under the same licence. You keep your copyright, and you grant the Licensor the relicensing right in CONTRIBUTING.md § Licensing of contributions, accepted by opening the pull request.
• Third-party material. Vendored specifications and third-party material keep their upstream terms, recorded in a PROVENANCE.md beside each vendored tree.
• The brand assets. The logos and icons under assets/brand/ are part of the Licensed Work.

Technical questions go to the maintainer named in MAINTAINERS.md.

Regulatory status

This page states FerroFED’s intended purpose and how it is classified under Regulation (EU) 2025/327 on the European Health Data Space (the EHDS Regulation). The classification was decided on 2026-10-04 (#519): FerroFED is built and documented as an EHR system, and its harmonised software components are to be delivered before the dates the Regulation applies to it. The page also states FerroFED’s position under the Cyber Resilience Act, decided on 2026-10-06 (#654): each release is a product that Cadasto B.V. places on the market (The Cyber Resilience Act).

Every quotation from the EHDS Regulation is from the Official Journal text (OJ L, 2025/327, 5.3.2025, http://data.europa.eu/eli/reg/2025/327/oj), vendored verbatim at docs/specs/eu-ehds/reg-eu-2025-327-en.xhtml. This page is not legal advice; the last section names what a deployment’s counsel should confirm.

Intended purpose

FerroFED is a federation gateway intended by its manufacturer to be used by healthcare providers when providing patient care. A clinician’s application sends it an ordinary AQL query about a patient. FerroFED resolves the patient to a record at each openEHR clinical data repository (CDR) of a federation, asks each CDR for its part of the answer, and returns one answer that names the CDR each row came from. It routes the follow-up reads and writes of that answer to the CDR that holds the record.

• Users. Healthcare providers and their health professionals, through the client applications they use in patient care. Every caller is authenticated at the gateway (client authentication). The operator of a deployment configures the member CDRs and the identity services. FerroFED offers patients no access service of their own, the “electronic health data access service” of Art 2(2)(h).
• Data. Personal electronic health data, “data concerning health and genetic data, processed in an electronic form” (Art 2(2)(a)), held in the member CDRs as openEHR records. FerroFED holds no clinical data of its own: it passes each CDR’s answer through, merges the answers, and forwards a write to the CDR that owns the record. What it keeps is the registry of members, routing state in memory, the stored-query definitions and the IHE audit records waiting for delivery; Data protection lists each.
• Priority categories. Art 14(1) lists six: “(a) patient summaries; (b) electronic prescriptions; (c) electronic dispensations; (d) medical imaging studies and related imaging reports; (e) medical test results, including laboratory and other diagnostic results and related reports; and (f) discharge reports”, with their main characteristics in Annex I. FerroFED does not select data by category: a query reaches whatever the member CDRs hold. Its intended purpose therefore covers every priority category a member CDR holds, all six of Art 14(1)(a) to (f).

Classification: an EHR system

Art 2(2)(k) defines an EHR system as:

any system whereby the software, or a combination of the hardware and the software of that system, allows personal electronic health data that belong to the priority categories of personal electronic health data established under this Regulation to be stored, intermediated, exported, imported, converted, edited or viewed, and intended by the manufacturer to be used by healthcare providers when providing patient care or by patients when accessing their electronic health data

FerroFED meets each part of that definition:

• It is software that allows priority-category data to be intermediated. Answering a clinician’s query from many CDRs, and routing a read or a write to the CDR that owns the record, is intermediation. The Regulation expects an EHR system that intermediates without storing: Annex II, point 2.1, begins “Where an EHR system is designed to store or intermediate personal electronic health data”.
• The data belong to the priority categories. Data of each of the six categories can be held in an openEHR CDR, and the intended purpose covers every category the member CDRs hold.
• The manufacturer intends it for healthcare providers providing patient care. That is the intended purpose above. Defining the purpose to exclude the priority categories would cut FerroFED off from its own use case, so the purpose includes them.

The general-purpose exclusion

Art 25(2) reads: “This Chapter shall not apply to general purpose software used in a healthcare environment.” Recital 38 gives the examples it has in mind: “text-processing software used for writing reports that would then become part of written electronic health records, general-purpose middleware, or database management software that is used as part of data storage solutions.”

FerroFED is middleware, so the recital’s second example needs an answer. It is built for one clinical purpose. It speaks openEHR ITS-REST and AQL to openEHR CDRs, it resolves the patient through an identity cross-reference, it rewrites the patient’s query for each CDR, and its intended purpose names healthcare providers providing patient care. The same recital contrasts general-purpose software with “EHR systems specifically intended by the manufacturer to be used for processing one or more specific categories of electronic health data”, and FerroFED is the second kind.

The obligations and their dates

Art 25(1) sets the core obligation: “EHR systems shall include a European interoperability software component for EHR systems and a European logging software component for EHR systems (the ‘harmonised software components of EHR systems’)”. The interoperability component “provides and receives personal electronic health data under a priority category for primary use … in the European electronic health record exchange format” (Art 2(2)(n)). The logging component “provides logging information related to access by health professionals or other individuals to priority categories of personal electronic health data … in the format defined in point 3.2. of Annex II” (Art 2(2)(o)).

Art 105 sets the dates. The Regulation “shall apply from 26 March 2027”, and Articles 25, 26, 27, 47, 48 and 49 apply later: “from 26 March 2029 to … EHR systems intended by the manufacturer to process” patient summaries, prescriptions or dispensations, and “from 26 March 2031” to those intended to process imaging, test results or discharge reports. FerroFED’s intended purpose covers all six categories, so both dates apply to it: 26 March 2029 for patient summaries, prescriptions and dispensations (Art 14(1)(a) to (c)), and 26 March 2031 for imaging, test results and discharge reports (Art 14(1)(d) to (f)).

Art 105 names no later date for Articles 28, 30, 35 to 41 and 44, so the general date of 26 March 2027 applies to them. Each of them attaches to an EHR system placed on the market or put into service, and Art 26(1), which makes compliance the condition for either, applies to FerroFED from 26 March 2029 for categories (a) to (c) and from 26 March 2031 for (d) to (f). That reading is one counsel should confirm.

The technical content comes from implementing acts the Commission has not yet adopted. The exchange format (Art 15(1)) and the common specifications for the essential requirements (Art 36(1)) are both due “By 26 March 2027”, and Art 105 applies them from the same 2029 and 2031 dates by category. A weekly job, scripts/checks/ehds-acts.sh, reads EUR-Lex and the Commission’s “Have your say” register and files an issue for each act adopted; the re-checks against the exchange format and the common specifications wait in FerroHEALTH/FerroBRIDGE#1327 and #799.

Two implementing acts are adopted. Both bind the national contact points and the cross-border authentication chain, and neither sets the content of the harmonised components:

Implementing Regulation 2026/2083 has the national contact points exchange data “in accordance with the requirements catalogue” and “the technical specifications” the MyHealth@EU steering group approves (its Art 4(1)). Implementing Regulation 2026/2099 has the entity a Member State lists authenticate a health professional at eIDAS assurance level “substantial”, and at level “high” from 26 March 2032 (its Art 6(3)). Both are vendored beside the Regulation, with Commission Recommendation (EU) 2019/243 on a European Electronic Health Record exchange format, which recital 26 names as the format’s foundation. A weekly check reads EUR-Lex and the Commission’s “Have your say” register for the acts still pending, and files an issue when one is adopted.

A deployment a health institution runs for itself

Art 26(2) reads: “EHR systems that are manufactured and used within health institutions established in the Union, as well as EHR systems offered as a service … to a natural or legal person established in the Union, shall be considered as having been put into service.” Putting into service is “the first use, for its intended purpose, in the Union of an EHR system covered by this Regulation” (Art 2(2)(l)). Recital 44 explains the intent: a healthcare provider “developing and using an EHR system ‘in-house’” should “comply with all requirements applicable to manufacturers”, after “an extended transitional period”. Art 105 sets that period: “Chapter III shall apply to EHR systems put into service in the Union referred to in Article 26(2) from 26 March 2031.”

For FerroFED this means:

• A health institution that builds and runs its own FerroFED may be the one that manufactured and used it within the institution. It would then carry the manufacturer’s obligations for that system, from 26 March 2031.
• A deployment that changes FerroFED can make its operator a manufacturer whatever the answer to the first point. Art 34 treats a user as a manufacturer where it modifies an EHR system “in such a way that conformity with the applicable requirements might be affected”, or “in such a way that it leads to changes in the intended purpose declared by the manufacturer”. FerroFED’s source is open to modification (licensing), so this applies to any deployment that runs changed code.
• An operator that hosts FerroFED for other organisations offers an EHR system as a service, which Art 26(2) also counts as putting into service. Such a hosted service also needs a commercial licence (licensing).

FerroFED plans its harmonised components for before the dates that apply to each category (26 March 2029 for (a) to (c)) whichever reading holds, so a deployment can use them under either. Who carries the manufacturer’s obligations for a given deployment is a question for that deployment’s counsel.

Cross-border access

Art 11(2): where the Member State of affiliation and the Member State of treatment differ, “cross-border access to the personal electronic health data of the natural person under treatment shall be provided through the cross-border infrastructure referred to in Article 23”. That infrastructure is MyHealth@EU and each Member State’s national contact point for digital health, “an organisational and technical gateway for the provision of services linked to the cross-border exchange of personal electronic health data” (Art 23(2)). The exchange between contact points “shall be based on the European electronic health record exchange format” (Art 23(3)), and “Member States shall ensure the connection of all healthcare providers to their national contact points for digital health” (Art 23(5)). Art 105 applies Art 23(2) to (6) from the same 2029 and 2031 dates.

FerroFED does not reach another Member State itself and does not build the contact point’s cross-border protocols. Its route to cross-border care is the national one: a national contact point asks its national infrastructure for a patient’s documents, and FerroFED can answer that request from federated openEHR data through its interoperability component. It does so on its FHIR face, where a national connector reads the patient summary, the document list and the prescriptions and posts a dispensation (A national contact point, #524).

The Federation Tier specification does not say whether a federation whose member CDRs sit in different Member States is in scope. FerroFED neither detects nor refuses one; whether such a deployment is lawful, and for which data, is the deployment’s to answer.

The Cyber Resilience Act

Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), “applies to products with digital elements made available on the market” whose intended purpose includes a data connection to a device or network (Art 2(1)). FerroFED is software whose purpose is that connection. The quotations in this section are from the Official Journal text (OJ L, 2024/2847, 20.11.2024), vendored with Regulation (EU) 2019/1020 at docs/specs/eu-cra/, and Art 104 of the EHDS Regulation amends three of its articles.

The manufacturer’s side of the CRA is the same for every FerroHEALTH product and is in the family book: who the manufacturer is, which duties apply from when, the vulnerability-handling policy, the Annex II information every product shares, and the conformity route of each product (The Cyber Resilience Act, the manufacturer). This section is FerroFED’s own reading: why a FerroFED release is a CRA product, what that asks of it, and its support period.

Why the CRA reaches a release

• A commercial activity. Art 3(22) defines making available on the market as “the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge”. Recital 15 names “an intention to monetise” as one mark of a commercial activity. FerroFED’s licence is free for non-production use and for non-commercial production use, and sells a licence for any other production use (Licensing). A release is therefore supplied in the course of a commercial activity, a free download included.
• Not free and open-source software. Art 3(48) asks for “a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable”. The Business Source License 1.1 withholds production use outside its Additional Use Grant, so FerroFED is not free and open-source software within the CRA, and the open-source software steward of Art 3(14) and Art 24 does not apply to it.
• The same test under the EHDS. EHDS Art 2(1)(d) takes “placing on the market”, “manufacturer” and “economic operator” from Regulation (EU) 2019/1020, whose Art 3(1) has the same words: “in the course of a commercial activity, whether in return for payment or free of charge”.

What the manufacturer does

• One product per release. Every tagged release, meaning the source tag, the binary tarballs, the gateway image and the console image of one version, is one product with digital elements. Cadasto B.V. places it on the market as its manufacturer (Art 3(13)). The main branch is development code and is not supplied for use.
• Reporting applies now. Art 14 has the manufacturer notify an actively exploited vulnerability and a severe incident, with an early warning within 24 hours. Art 71(2) applies Art 14 “from 11 September 2026”, and Art 69(3) applies it to “all products with digital elements … placed on the market before 11 December 2027”, the v0.0.x releases among them. The written reporting procedure is in SECURITY.md and on the Complaints and incidents page (#762).
• The rest from 11 December 2027. Art 71(2) applies the rest of the CRA from 11 December 2027. Each release placed on the market from that date meets the essential requirements of Annex I and has the support period below. Art 69(2) holds a product placed before that date to those requirements only once it is “subject to a substantial modification”.
• One file, one declaration, one CE marking. EHDS Art 104 inserts CRA Art 32(5a): the manufacturer of an EHR system shows conformity with CRA Annex I “using the relevant conformity assessment procedure provided for in Chapter III” of the EHDS Regulation. It also replaces CRA Art 31(3), so “a single set of technical documentation shall be drawn up” for both acts. CRA Art 28(3) and EHDS Art 39(2) each require a single EU declaration of conformity. A release placed from 11 December 2027 therefore carries one technical documentation set, one declaration and one CE marking for both acts, all planned under #525.
• The economic operators supplied. EHDS Art 35 has an economic operator identify, for 10 years, “any economic operator to which they have supplied an EHR system”. CRA Art 23(1)(b) asks the same “where available”; EHDS Art 35 has no such qualifier. The manufacturer’s answer is a register, kept for 10 years, of every economic operator it supplies under a contract: commercial licensees, resellers, integrators and hosts. The procedure is in place (The register of economic operators): the register’s format is public and checked in CI, and its rows are kept by the manufacturer outside the public repository and are not published. The public release is not gated, and it is supplied for non-production use and for non-commercial production use under the licence. If counsel holds that an anonymous production user is an economic operator, for example one that puts FerroFED into service under EHDS Art 26(2), downloads move behind a registration.

A FerroFED that someone hosts as a service, or that a health institution builds and runs for itself, is outside the CRA for that service: EHDS recital 112 says that “EHR systems offered through the SaaS licensing and delivery model do not fall within the scope of” the CRA, nor do “EHR systems that are developed and used in-house”. EHDS Art 26(2) still counts both as put into service (A deployment a health institution runs for itself). The release that was downloaded to run it stays a CRA product.

Two delegated acts are adopted under the CRA, both vendored beside it. Commission Delegated Regulation (EU) 2025/1535 excludes from the CRA the products within the scope of Regulation (EU) No 168/2013, on two- or three-wheel vehicles and quadricycles (its Art 1); FerroFED is not one of them, so the act changes nothing here. Commission Delegated Regulation (EU) 2026/881, adopted under Art 14(9), sets when the CSIRT that first receives a notification may delay passing it on (Art 16(2)). It binds that CSIRT and puts no duty on the manufacturer; the Complaints and incidents page says what it means for a notification.

The support period

Art 13(8) has the manufacturer handle a product’s vulnerabilities for its support period, and “the support period shall be at least five years”. Art 13(19) has the end date of that period, “including at least the month and the year”, specified “at the time of purchase”, and Annex II, point 7, puts “the end-date of the support period” in the information to the user. Cadasto B.V. meets this as a commitment for the whole product: for every release placed on the market from 11 December 2027 it keeps publishing security fixes, in new releases, for at least five years, with the end date published, and ships them only in the newest release, as Art 13(10) allows. Only the newest release is supported: when a new release is published, every earlier release stops receiving fixes, and upgrading is free. There are no maintenance branches, no long-term-support line and no backports. SECURITY.md lists every release with the date until which fixes are published, five years from its release date (#763). The gateway knows the end date of its own release from its build: the startup banner and OPTIONS {base}/ name it, and once it has passed the banner, the log and config check say so (#782).

The basis of the five years

Art 13(8), second subparagraph, has the manufacturer “determine the support period so that it reflects the length of time during which the product is expected to be in use, taking into account, in particular, reasonable user expectations, the nature of the product, including its intended purpose, as well as relevant Union law determining the lifetime of products with digital elements”. Its fifth subparagraph puts “the information that was taken into account” in the technical documentation, which Annex VII, point 4, repeats. Cadasto B.V. decided on 2026-10-16 to keep five years from each release date (#1088). It took these matters into account:

• The length of time in use. A gateway sits between the hospital platforms it federates: the CDRs behind it and the clients in front of it. The manufacturer expects one release to stay in use until those platforms are next upgraded, when the operator moves the gateway to a newer release as part of the same change, and expects that interval to fall within five years.
• Reasonable user expectations. The users are the health institutions and the operators that run the gateway for them (Intended purpose). They can expect every vulnerability found to be fixed in a new release they can take free of charge: a security fix ships as a patch release of the newest release, with the fix alone, or with the reason a functional change ships with it stated in the release notes (SECURITY.md).
• The nature of the product and its intended purpose. FerroFED is software with no hardware part, and it holds no clinical data of its own, so an operator replaces a release by installing a newer one (Upgrading).
• Union law determining the lifetime. Art 13(8), third subparagraph, sets the floor: “the support period shall be at least five years”. The acts adopted under the CRA that the manufacturer holds, Regulations (EU) 2025/1535, 2025/2392 and 2026/881, set no support period. EHDS Art 39(4) keeps a digital declaration of conformity online “for the expected lifetime of the EHR system and, in any event, for at least 10 years”; that rule sets how long the declaration stays available, and sets no support period.
• The release cadence. Releases come days or weeks apart: seven between 2026-10-01 and 2026-10-15, in the table of SECURITY.md. Only the newest release is supported, and each release starts its own five years, so fixes keep coming for at least five years after the newest release.

Art 13(8) also lets the manufacturer take into account “the support periods of products with digital elements offering a similar functionality placed on the market by other manufacturers, the availability of the operating environment, the support periods of integrated components that provide core functions and are sourced from third parties as well as relevant guidance provided by the dedicated administrative cooperation group (ADCO)”. Of these:

• Similar products. The manufacturer compared no other gateway’s support period, and the period does not rest on one.
• The operating environment and integrated components. A release runs as its container image or binary tarball and reaches each node over openEHR ITS-REST. A vulnerability in a component the release carries, which its SBOMs list, is fixed in a new release like one in the gateway’s own code, so no supplier’s end of support ends the commitment.
• ADCO and Commission guidance. The manufacturer holds no ADCO or Commission guidance on support periods (Art 52(16)) for this category of product, and reads the period against such guidance once it is published.

Already in place

None of these is a conformity claim; each answers a CRA requirement in part:

• Each release attaches a CycloneDX SBOM of the source dependency graph and an SPDX SBOM of the shipped binary, with signed provenance (Annex I, Part II, points 1 and 7).
• Vulnerabilities are reported privately, with an acknowledgement within about 5 business days and an initial assessment within about 10, and a fixed release follows within 7, 30 or 90 days of the confirmed assessment for a Critical, High or Medium vulnerability, and with the next release for a Low one (Annex I, Part II, points 5 and 6; Art 13(17)).
• The running system names the manufacturer, its postal address and its single point of contact (Art 13(16)).
• A published release cannot be changed or deleted, so every update stays available (Art 13(9)).
• The cybersecurity risk assessment reads the threat model and the clinical safety risk file against Annex I (Art 13(2), (3)), and CRA information to the user gives the points of Annex II (Art 13(18)).

What is built and what is planned

Neither harmonised software component is complete yet. Three built features relate to the essential requirements, and none has been assessed against them:

• Every caller is authenticated at the gateway (client authentication). Annex II, point 3.1, asks for “reliable mechanisms for the identification and authentication of health professionals”. For patient data the gateway requires a natural person behind the token, or a client acting for the professional the token names, and the assurance level the deployment sets per issuer (Professionals and assurance).
• Every access to patient data the gateway intermediates is recorded with the verified caller, the patient, each endpoint asked and the categories of the data, in the record Annex II, point 3.2, sets for the European logging component (the access log). The library that builds it is ehds-logging, published from the FerroHEALTH audit library (FerroAUDIT). The records are reviewed at the Audit Record Repository with ITI-81, the connection of external software point 3.3 admits, and each states how long it is kept by its origins and categories, never under three years (point 3.4, Art 9(2); Reading the log). A request addressed by ehr_id names the patient the identity binding holds under it, so a search by the person’s identifier finds it (Art 9(1)); a query over many patients’ data names the patient behind each ehr_id its delivered rows project, up to a bound, and otherwise records its scope, which a person’s search finds through the members that hold their EHR (A query over many patients’ data). Each record carries a security label per category and per origin, which the repository applies as access rights by origin and category (point 3.4; Labelling the access records).
• The European interoperability component is the eehrxf crate, published from FerroHEALTH/FerroBRIDGE and pinned exactly (its pages): the EHDS dataset model, read from the Xt-EHR logical models, and the mapping of an openEHR composition to a FHIR R4 Bundle through the mapping files you supply. It also reads a received document, checks it against its profiles and maps it into one openEHR composition that keeps the original document (Receiving a document). The gateway holds the stored queries that select each patient summary section’s compositions (the section queries), and serves the patient summary built from them on a FHIR R4 face of its own, the interface of Annex II, point 2.1 (The patient summary over FHIR). The same face lists the summaries that exist for a patient, the members’ own ones included (The document list). It also searches and reads a patient’s electronic prescriptions and receives a dispensation into the member that owns its prescription, passed through in the HL7 Europe MPD profiles from the members that serve them on their own FHIR endpoint, or mapped from a member’s openEHR medication data in the map mode (Prescriptions and dispensations over FHIR). It lists, reads and receives laboratory reports in the HL7 Europe Laboratory Report profiles (Laboratory reports over FHIR), lists, reads and receives discharge reports in the Hospital Discharge Report profiles (Discharge reports over FHIR), and lists and reads imaging reports in the Imaging Report profiles (Imaging reports over FHIR).

Seven of the manufacturer’s obligations have a first answer:

• The running system names its manufacturer, with the postal address and the single point of contact (Art 30(1)(g)): GET {base}/, OPTIONS {base}/, the startup banner, ferrofed --version, the operator console’s About page, which the footer of every console page links to, and the image labels.
• The complaint channels, the two registers, corrective action and the serious-incident report (Art 30(1)(i) to (o), Art 44(7)) are written procedures (Complaints and incidents).
• The economic operators supplied under a contract are identified from a register kept for 10 years outside the public repository (Art 35, CRA Art 23), with its procedure written and its public format checked in CI (The register of economic operators).
• Every public text is reviewed against Art 28 at each release, and the completeness default, the budgets and the consent pre-filter are assessed against Annex II, point 2.5 (Claims review).
• The information sheet gives every item of Art 38(2), held to the pin matrix by a guard, and the instructions for use cover installation, the configuration of a deployment in the EU, maintenance and the limitations (Art 30(1)(d), Art 32(2)(d), Annex III, point 1(j)).
• The clinical safety risk file names each hazard of the two harmonised components with its control and the test that holds it, for Annex II, point 1.1.
• The technical documentation indexes every element of Annex III, a release that changes a harmonised component is not cut without a review row (Art 30(2)), and each release’s documentation is kept for ten years (Art 30(3)).

The planned work is filed under #519. What remains before the Regulation applies on 26 March 2027:

• #799: the European logging software component is built (#521), and is re-checked against the Art 36(1) common specifications once they are adopted. None is adopted, so the issue waits upstream with no milestone.
• FerroHEALTH/FerroBRIDGE#1327: the European interoperability software component for the patient summary is built from federated openEHR data (#522), and is re-checked against the Art 15(1) implementing act once it is adopted. None is adopted.
• #1794: the rating of what a received discharge or imaging report can lose. The component moved to FerroBRIDGE (#813), where prescriptions from openEHR medication data, laboratory reports, discharge reports and imaging were built (issues FerroHEALTH/FerroBRIDGE#1321, FerroHEALTH/FerroBRIDGE#1322, FerroHEALTH/FerroBRIDGE#1324, FerroHEALTH/FerroBRIDGE#1325 and FerroHEALTH/FerroBRIDGE#1326, now closed).
• #525: the rest of the conformity work: the points the Annex II checklist leaves open, the EU declaration of conformity, which each release writes once the manufacturer issues it, the CE marking and the registration.

No EU declaration of conformity has been drawn up and no FerroFED release carries the CE marking. The release process says when, in a release, the manufacturer affixes the CE marking (Art 41) and makes or updates the EU database entry (Art 49), and that the entry waits on the list of data the Art 49(4) delegated act will set (docs/release.md, Before the tag, step 8).

The crosswalk of each category, which ties the eHealth Network dataset, the Xt-EHR logical model and the HL7 Europe profiles together, and the section queries that select the openEHR content, are on The category crosswalks.

Not legal advice

This page is the manufacturer’s reading of the EHDS Regulation and the CRA, written to plan the engineering work. It is not legal advice, and it does not decide any deployment’s obligations. The manufacturer’s own counsel is asked to confirm, now, that a release is supplied in the course of a commercial activity, that Cadasto B.V. is its manufacturer, and that CRA Art 14 applies to the v0.0.x releases; the rest of the CRA position is put to counsel before the first release placed on the market from 11 December 2027. A deployment’s counsel should confirm at least:

1. The intended-purpose statement and the classification as an EHR system under Art 2(2)(k), including the answer to recital 38’s “general-purpose middleware” example.
2. That the intended purpose covers all six priority categories, given that FerroFED passes through whatever the member CDRs hold.
3. Whether the deployment is an EHR system “manufactured and used within health institutions” (Art 26(2)), and who then carries the manufacturer’s obligations of Art 30.
4. Whether the deployment changes FerroFED in a way that makes its operator a manufacturer under Art 34.
5. Whether hosting FerroFED for others is offering it as a service under Art 26(2). The manufacturer reads each tagged release as placed on the market by Cadasto B.V. (The Cyber Resilience Act; Art 2(1)(d) takes the definition from Regulation (EU) 2019/1020). What remains for a deployment is whether it is an economic operator that Cadasto B.V. supplied, which EHDS Art 35 has the manufacturer identify: 2019/1020 Art 3(13) counts whoever puts a product into service under the applicable legislation, and EHDS Art 26(2) counts a hosted or in-house system as put into service.
6. The dates for the Chapter III articles Art 105 does not name, read together with Art 26(1).
7. The national rules that apply beside the Regulation: national requirements for EHR systems (Art 42) and the Member State’s arrangements for connecting healthcare providers to its national contact point (Art 23(5)).

The category crosswalks

For each priority category, the interoperability component keeps a crosswalk: the eHealth Network dataset, the Xt-EHR logical model and the HL7 Europe profiles element by element, held to the vendored packages by a test. The component is the eehrxf crate, published from FerroHEALTH/FerroBRIDGE and pinned exactly here, so its crosswalks are described on FerroBRIDGE’s crosswalk page: the patient summary, the prescription and dispensation, the discharge report, the laboratory report and the imaging study and report. This page keeps what the gateway does with them: its reading of the patient summary against the Xt-EHR D6.1 draft and the section queries that select the openEHR content each document is written from. Where the component stands as a whole is on Regulatory status.

Two elements of the patient summary crosswalk have no openEHR content named to feed them, so they are open in the clinical safety risk file (hazard I-03) and the gateway writes them as unavailable: the medical alert (A.2.1.2), which a producer must be able to populate, and the functional status (A.2.3.4).

Against the Xt-EHR D6.1 draft

The Commission has adopted no Art 15(1) act and published no draft of one, so the patient summary is also read against the Xt-EHR deliverable D6.1 (Patient Summary: implementation guides on the EEHRxF, published in 2026-05), the closest published text of the specifications that act will lay down. It defers its datasets to the Xt-EHR logical models, which the crosswalk above is read from, and adds these points for an EHR system:

D6.1 asks nothing the gateway does not do, and changes no decision. The summary is read again against the adopted act (FerroHEALTH/FerroBRIDGE#1327).

The patient summary’s section queries

Each section openEHR content feeds has a stored query the gateway holds itself, read-only, under the namespace eu.ferrofed.eehrxf at the one version 1.0.0 (§12.7, N44). The crate app/ferrofed-eehrxf, the federation half of the interoperability component, builds them; eehrxf links nothing of the gateway. The queries are:

• eu.ferrofed.eehrxf::patient-summary-allergies-and-intolerances
• eu.ferrofed.eehrxf::patient-summary-problems
• eu.ferrofed.eehrxf::patient-summary-medication-summary
• eu.ferrofed.eehrxf::patient-summary-medical-devices-and-implants
• eu.ferrofed.eehrxf::patient-summary-procedures
• eu.ferrofed.eehrxf::patient-summary-immunisations
• eu.ferrofed.eehrxf::patient-summary-social-history
• eu.ferrofed.eehrxf::patient-summary-pregnancy-history
• eu.ferrofed.eehrxf::patient-summary-advance-directives
• eu.ferrofed.eehrxf::patient-summary-observation-results
• eu.ferrofed.eehrxf::patient-summary-care-plans

Each one selects, from every member, the whole compositions that contain one of the archetypes the openEHR International Patient Summary template names for its section, each composition once with its uid and its template id, because a FHIRconnect mapping is chosen per template. The patient is the $patient and $namespace parameters alone, so the query passes the stored-query admission and the gateway’s rewrite asks each member by its own ehr_id. The section-to-archetype table, and the four sections no query feeds, are in the clinical safety risk file. Vital signs, which the EPS composition carries in a section of its own, feed the Xt-EHR observation results. Running a query by name and the reserved namespace are described under the gateway’s own queries. The FHIR face of Annex II 2.1 assembles the patient summary from their answers (The patient summary over FHIR, #809); the document list names it beside each member’s own summary (#810).

The laboratory report’s section query

One stored query selects the laboratory reports, eu.ferrofed.eehrxf::laboratory-report, held beside the patient summary’s and in their shape: every whole composition that contains an openEHR-EHR-OBSERVATION.laboratory_test_result.v1, the entry the openEHR international Clinical Knowledge Manager’s template “Generic lab test result example simple” names (CKM cid 1013.26.408, asset version 3). That template is a DRAFT CKM has not reviewed or published, so a reviewed template that names other entries would change the query; it is vendored by scripts/vendor/openehr-ckm.sh with its status recorded. A test holds the query to the template’s entries. The mapping of laboratory results is the laboratory mapping eehrxf ships, built in FerroBRIDGE (issue FerroHEALTH/FerroBRIDGE#1324, now closed), and the FHIR face writes a member’s report with it (Laboratory reports over FHIR).

The discharge report and the imaging report have no section query yet. Building each report from the members’ answers, and the FHIR face, are planned as the gateway half of each category (#1404, #1405, #1406), after the component work in FerroBRIDGE.

MyHealth@EU self-assessment

This page is FerroFED’s own assessment of the gateway against the MyHealth@EU Requirements Catalogue v10.0.0 (W10-Operation Ready, 2026-03-06). It is not a MyHealth@EU compliance check, and FerroFED holds no Operation Ready status: MyHealth@EU runs its own compliance checks for the national contact points in operation, and FerroFED is not a national contact point. The badge in the README counts the rows below and says self-assessed; it never says compliant, certified or operation ready.

What the catalogue binds

The catalogue’s requirements address the national contact points for digital health and MyHealth@EU. FerroFED is one of the national infrastructures a contact point calls through its national connector (A national contact point), so a requirement binds the gateway only where the contact point of the country of affiliation relies on what the national infrastructure answers: the patient lookup, the patient summary, the prescriptions and the dispensations it receives, the document categories, the quality of the data, and the record of every access.

Every row judges the gateway’s share of one requirement, and its conclusion names whose the rest is:

The badge’s count is the rows met out of every row but the not-applicable ones. A row whose status the repository’s own pages and tests cannot show is never marked met.

The source and its terms

The catalogue is privileged-access: the Xt-EHR deliverable D6.1 (section 5) says it is available only with authorisation, and Commission Decision 2011/833/EU Art 2(2)(c) excludes such documents from its reuse grant. The owner read v10.0.0 under an EU Login reading grant, and FerroFED has no grant to reuse it. This page, conformance/myhealth-eu.tsv and the badge therefore carry requirement ids, section numbers, statuses and FerroFED’s own conclusions, and none of the catalogue’s text. scripts/checks/myhealth-eu.sh holds the mapping, this page and the badge in step, and refuses a copy of the catalogue in the repository.

The implementing act on the exchange format (Regulation (EU) 2025/327 Art 15(1)) is not adopted. When it is, every row is checked again with the decisions it rests on (#1425).

The requirements

Of the 73 rows, 31 bind the gateway: 18 met, 5 partly met, 0 waiting on the Art 15(1) act, 8 not met and 0 not assessed. The other 42 do not apply to the gateway.

Information sheet

Regulation (EU) 2025/327 on the European Health Data Space (the EHDS Regulation) has every EHR system “accompanied by an information sheet that includes concise, complete, correct and clear information that is relevant, accessible and comprehensible to professional users” (Art 38(1)), free of charge for the user (Art 30(1)(d)). This page is that sheet for FerroFED. Each section answers one point of Art 38(2). The instructions for use are the other document Art 30(1)(d) asks for.

Art 38(3) lets a manufacturer enter the same information into the EU database of Art 49 in place of supplying the sheet. The data that database holds is set by a delegated act under Art 49(4) that is not adopted, so the sheet is supplied here. Every quotation is from the Official Journal text, vendored at docs/specs/eu-ehds/reg-eu-2025-327-en.xhtml.

(a) The manufacturer

Art 38(2)(a): “the identity, registered trade name or registered trademark, and contact details of the manufacturer and, where applicable, of its authorised representative”.

The running gateway names the same details in GET {base}/, OPTIONS {base}/, its startup banner and ferrofed --version (Complaints and incidents).

(b) Name, version and date of release

Art 38(2)(b): “the name and version of the EHR system and date of its release”.

The EHR system is FerroFED. This sheet describes FerroFED 0.0.20, released on 2026-11-12. It ships as these forms:

• the gateway image ghcr.io/ferrohealth/ferrofed, for Linux on x86_64 and aarch64;
• the gateway binary ferrofed, for Linux on x86_64 and aarch64, on glibc and on musl;
• the operator console image ghcr.io/ferrohealth/ferrofed-console;
• the source code, under the Business Source License 1.1 (Licensing).

Each release lists its changes in the changelog, and ferrofed --version prints the version a binary is. The book on the main branch also documents changes merged since the release above; the changelog’s [Unreleased] section lists them, and the next release carries them. From FerroFED 0.0.10 on, the sheet of a release is this page at that release’s tag.

Each release from 0.0.10 on carries its own copy of this sheet and of the instructions for use: the Markdown source of both pages at the tag, plain text a screen reader reads, attached to the release on the releases page as ferrofed-vX.Y.Z-information-sheet.md and ferrofed-vX.Y.Z-instructions-for-use.md. The gateway and console images of the release name the download address of each copy in their labels eu.ferrofed.information-sheet and eu.ferrofed.instructions-for-use, which docker image inspect prints. The links inside a copy are relative to this book.

Once the manufacturer issues it, a release also carries its EU declaration of conformity (Art 39, with the content of Annex IV) as ferrofed-vX.Y.Z-eu-declaration-of-conformity.md. No release carries one yet; the technical documentation says what it holds and what it waits on.

(c) Intended purpose

Art 38(2)(c): “the intended purpose of the EHR system”.

FerroFED is a federation gateway intended by its manufacturer to be used by healthcare providers when providing patient care. A clinician’s application sends it an ordinary AQL query about a patient. FerroFED resolves the patient to a record at each openEHR clinical data repository (CDR) of a federation, asks each CDR for its part of the answer, and returns one answer that names the CDR each row came from. It routes the follow-up reads and writes of that answer to the CDR that holds the record. It holds no clinical data of its own.

The users are healthcare providers and their health professionals, through the client applications they use in patient care, and the operator who configures a deployment. FerroFED offers patients no access service of its own. The full statement, and the classification as an EHR system under Art 2(2)(k), are on Regulatory status.

(d) The categories of data

Art 38(2)(d): “the categories of electronic health data that the EHR system has been designed to process”.

FerroFED selects no data by category: a query reaches whatever the member CDRs hold. It is designed to intermediate personal electronic health data of all six priority categories of Art 14(1):

The codes are those of HL7 Europe’s EEHRxFDocumentPriorityCategoryCS (hl7.fhir.eu.health-data-api 1.0.0-ballot), and the record writes each with that system. The categories a deployment declares under national law are recorded as well, each in the system its Member State defines (Categories).

The categories received

Annex II, points 2.2 and 2.3, ask that an EHR system “be able to receive personal electronic health data in the European electronic health record exchange format”. A client sends such a document to POST {fhir-base}/Bundle, and FerroFED writes it to the one member the deployment declares for its category (Receiving a document). This release can receive documents of three categories:

An imaging report is received over the HL7 Europe Imaging Report 1.0.0-ballot package closure, which the package set pins (#1716).

An electronic dispensation, Art 14(1)(c), is received as one resource, which the table above does not count: a client sends one MedicationDispense-eu-mpd to POST {fhir-base}/MedicationDispense, and FerroFED writes it to the member that owns the prescription it names, when the deployment declares members for electronic dispensations in [[fhir.serve]] (Receiving a dispensation). Electronic prescriptions, Art 14(1)(b), are served by search and read and are never received.

Which of these a deployment receives is its operator’s choice: each [[fhir.receive]] table of the configuration names the one member that stores a category’s documents (Configuring the face). A category with no such table has no receiving member, and a document of it is refused with a 422 OperationOutcome that names the category, with nothing sent to any member. Every receipt that reached a member writes one access record carrying the document’s category and the member.

This sheet is the same for every deployment of a release, so it cannot list one deployment’s receiving members. Each deployment states its own: GET {fhir-base}/metadata answers a CapabilityStatement whose Bundle resource, present only when the deployment receives a category, names, by the codes above, the categories the deployment receives and those it has no receiving member for, and lists the Bundle profile of each category received.

(e) Standards, formats and specifications

Art 38(2)(e): “the standards, formats and specifications supported by the EHR system and versions of those standards, formats and specifications”.

scripts/checks/versions.sh holds every row of this table to the pin matrix, docs/VERSIONS.md, so a version that moves there fails CI until this sheet moves with it. Each Item names its row in the matrix exactly.