18. Considerations for future releases

  • Federation-of-federations. A federation cannot yet be a node of another federation.

  • End-user-scoped identity conveyance. §13.1 specifies gateway-to-node authentication (OAuth 2.0 + RFC 7523), which authenticates the gateway as a service. Conveying the end-user behind a query, needed where a node’s release decision depends on who is asking and not only on which system, is not yet specified. RFC 8693 Token Exchange and a separately-conveyed OIDC id_token are the candidates. Deployments needing it today use their regional stack (Annex B).

  • Sender-constrained tokens in the base profile. DPoP (RFC 9449) is required by the Dutch GF realisation (§B.4) but not by §13.1. Whether bearer tokens are acceptable across organizational trust boundaries, or sender-constraining should be hoisted into the base profile, is left for a future release.

  • A full OpenAPI document for the whole façade. The two structures a client must agree on byte-for-byte now have machine-readable contracts: federated-result-set.schema.json and options-root.schema.json, validated in CI (Changes). The layer above them, an OpenAPI description of the façade as a whole, is still missing: paths, methods, request headers (openEHR-federation-endpoint, openEHR-federation-completeness, openEHR-federation-dedup), response headers (§9.6) and status-code mappings (§11.2). Against that, a harness could exercise a gateway end to end; today it can only check two response bodies in isolation. The natural form is a document that imports the ITS-REST OpenAPI and overlays the federation’s additions, keeping the inheritance of §9.1 visible in the machine-readable artifact as it now is in the prose.

  • A defined membership-status vocabulary. §7a.2's endpoint status is an open string in this release, on purpose: it is a membership-lifecycle concept, and this specification does not yet define that lifecycle (§12b.2). A future release defining membership and revocation should fix the vocabulary at the same time and narrow the schema with it, since the two questions have the same answer.

  • A federation-wide audit model. Audit is out of scope in this release (§2.2). The specification conveys client identity so a node can write its own records (N24) and fixes which identifier an event is about (§12a), but defines no event model, no retention rule and no federation-wide trail, and binds no audit profile. Whether a federation needs a common audit model, and whether ATNA or an equivalent is the right binding for one, is left for a future release.

  • Comprehensive error catalogue. A full list of mandatory error messages, validation (checksums) and debug information is out of scope for now.

  • Imported-composition dedup. §10.2 defines the mechanism; broader reconciliation of independently authored equal data remains open.

  • Cross-node pagination. ORDER BY + LIMIT is made correct at the Tier (N39), but OFFSET-based paging is either rejected or served from an optional materialised cursor (§11.6); a federation-wide stable, resumable pagination model - continuation tokens with defined semantics under node churn - is not yet specified.

  • Cross-node aggregation. Decomposable aggregates (COUNT, SUM, MIN, MAX) MAY be supported today (§11.6.3); a general model covering AVG, DISTINCT-qualified aggregates and GROUP BY interacting with de-duplication is deferred.

  • Convergence of imported copies. A write reaches the owning CDR; nodes holding imported copies are not updated and this specification does not define propagation or re-import signalling (§10.3).

  • ehr_id collision remediation. Detection and refusal are specified (N42); what a federation does about a confirmed collision - re-issue, quarantine, mapping layer - is a governance question left open.

  • A fuller Federation-Node conformance profile. The node profile is thin in this release on purpose: a node is constrained at its interface and nowhere else (§16.2), the right default while the federation must be able to admit CDRs it did not design. It does leave the conformance table asymmetric, with 34 points scored against the gateway and five against a node or an operator. A future release MAY give the node profile its own numbered points, and the actor column already distinguishes them.

  • A consolidated node-admission profile. §12b.2/N42a fix the identifier-integrity conditions for admitting a node, because those prevent a specific routing failure. The other conditions a federation will want (trust and authentication, §13; registry/addressing entries, §15; consent handling, N27; conformance evidence, §16) are specified in their own sections but are not gathered into a single admission profile, and membership revocation is not addressed. A future release SHOULD define that profile and the membership lifecycle around it.

  • SEC-style plugin integration. Alignment with the openEHR AI-plugin work (https://github.com/openEHR/ai-plugins) and document-editing plugins has been raised and is not yet assessed against this specification; it is recorded here as an open item.

  • Write / transaction semantics. §12.4 covers single-CDR versioned writes and single-node new-object creation; multi-node transactions and creation spanning nodes are deferred (disallowed in v1).

  • connectionType alignment. A real openEHR Query-API connectionType code (e.g. openehr-rest-query) should be registered (with openEHR/HL7 terminology) so §15.2/N19 can bind a stable system value in place of the current placeholder.

  • PMIR merge/split (ITI-93/94). Hooks and a test track (track 8) are reserved; full propagation of identity merges/splits across the federation MAY be deferred to a later release.

  • Deployment topology. The spec is deployment-neutral; a future release MAY profile the distributed-gateway variant (per-node gateways with a trust-over-IP framework distributing addressing information) in more detail.