2. Scope & Non-Goals

2.1 In scope

  1. The façade contract: accepting a conformant openEHR AQL query that MAY identify the patient by ehr_status/subject, and behaving as a technically transparent intermediary (§7, §6/N1–N2).

  2. The REST surface: the openEHR ITS-REST API as a whole, read and write - which parts fan out, which are routed to a single node, and which are explicitly not supported (notably DEMOGRAPHIC, and template management, which stays single-node-routed) - plus base-URL/prefix neutrality and gateway self-description via OPTIONS (§7a, §6/N28–N32).

  3. An optional gateway-held stored-query registry: a gateway MAY be authoritative for a federated stored query, version it immutably, expand it into a fan-out when invoked by name, and optionally distribute the definition to nodes (§12.7, N44). The registry is the only part of Definition management the specification federates; the template lifecycle is not (§18).

  4. Identifier hygiene at dispatch: a node receives the ehr_id and no directly identifying patient identifier, in any carrier (§5.4, §6/N33).

  5. The two/three-step execution model: resolve subject → {node, ehr_id}, fan out standard AQL keyed on ehr_id, then combine/annotate (§4, §6, §7).

  6. The optional AQL extension (FROM ENDPOINT … / ORGANISATION …) for pinning a query to named systems and surfacing provenance - decoupled from patient resolution (§8).

  7. The result-set shape and origin metadata (§9), de-duplication policy (§10) and partial-results / unresponsive-endpoint handling (§11).

  8. Follow-up read and write routing to the owning CDR, provenance-honest, via creating_system_id - including ehr_id-path routing and ehr_id collision handling (§12), on the routing-key rules of §12a.

  9. Completeness semantics: all-or-nothing as the default with opt-in best-effort, an explicit timeout structure, and correct cross-node ORDER BY/LIMIT/aggregate handling (§11.4–§11.6).

  10. The identifier-integrity conditions for admitting a node to a federation - membership-level prevention of the routing failures §12 can only detect (§12b). Broader admission criteria and the membership lifecycle are not settled here (§12b.3, §18).

  11. Authentication/authorization handoff from client → gateway → node (§13).

  12. The bindings that make the above concrete: IHE PIXm/PDQm/XCPD/PMIR/mCSD as the proposed binding (§5, §14, §15, Annex A), and the Dutch Generic Functions as a regional alternative (Annex B).

  13. A Connectathon-style test approach and a consolidated, testable conformance-point list (§16, §17).

2.2 Referenced out (consciously out of scope)

The Federation Tier consumes these services through the named profiles, and their internals belong to those profiles and not to this document:

  • Identity-resolution mechanics - how an MPI/PIX Manager cross-references identifiers, and how a demographic match is computed. This spec requires that resolution happens via an identifier cross-reference service and that it happens outside AQL. It does not define the matching algorithm (§5, §14).

  • Localization / record-locator internals - how a locator decides which communities hold data. The spec requires the Tier to consume a node list. It does not build the locator.

  • Transport security and the trust framework - TLS, mTLS, certificate/PKI and network trust are assumed and bound via the security profiles (§13, Annex B). This document specifies the identity conveyance on top of them, not the transport itself.

  • The demographic service / MPI data model - owned by the identity/demographic profiles (Annex A), not here.

  • Audit - left out on purpose. This specification does two audit-relevant things: it requires the gateway to convey the authenticated client identity on every routed follow-up so that a node can write its own audit records (N24, §13.1), and it fixes which identifier a governance event is about (§12a). It does not specify an audit event model, what must be recorded, retention, or a federation-wide audit trail, and it binds neither ATNA nor any other audit profile. Audit stays each participant’s own obligation under its own governance. A federation that wants a common audit model must define one alongside this specification (§18).

2.3 Non-goals (in v1)

  • A federation cannot itself be a node of another federation (federation-of-federations is deferred; §18).

  • New-object creation spanning multiple nodes is disallowed in v1; a new object MUST target one explicitly chosen node (§12/N23). The single exception is optional template broadcast, which is idempotent and carries no patient data (§12.6/N43).

  • Cross-node OFFSET pagination is not guaranteed. Where it is not supported the gateway rejects (not approximates) (§11.6.2); ORDER BY + LIMIT is made correct at the Tier (N39), and a general stable-pagination solution is deferred (§18).

  • Federated demographics. The openEHR DEMOGRAPHIC API is not federated; identity lives in an MPI/demographic service reached through the identity binding (§7a.1, N32).

  • Convergence of imported copies. A write reaches the owning CDR only; propagating it to nodes holding imported copies is not specified (§10.3, §18).

2.4 Specification vs. realisation (a document convention)

This document keeps the specification separate from a regional realisation of it:

  • The normative body (§1–§18) defines the federation model in terms of abstract roles (localization / record locator, addressing / directory, identifier cross-reference, authentication, authorization, consent) and their proposed IHE binding (PIXm, PDQm, XCPD, PMIR, mCSD - see Annex A). It names a profile as the proposed binding and, at most, gives a one-line illustrative example of a role. It does not describe any specific product, national service, or deployment in detail.

  • Concrete, region-specific detail lives in Annex B (informative): the Dutch Generic Functions (Mitz/OTV, NVI, LRZa, did:web/VC/DPoP, Rego/mitz_consent, pseudonymised-BSN localization) and worked product examples such as the ACP/Vitaly flow on a pseudonymised id.

So when the body says "a localization service returns candidate nodes (proposed binding: IHE XCPD)," the how for a given region, say a record-locator lookup, is in Annex B and does not appear inline. A different region can supply a different Annex B without touching §1–§18.

The same reasoning keeps localization and consent apart (§14, §13.2) even though some regions bundle them. The Dutch realisation couples localization with the Mitz consent check, and Annex B describes it that way because that is what Mitz does. The normative body cannot assume it, because a region whose localizer is a plain record-locator has to be conformant too. The body therefore places consent enforcement at the node (N27) and treats Step-1 pre-filtering as an optional regional capability (N27a).