<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.0 20040830//EN" "journalpublishing.dtd"><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" dtd-version="2.0" xml:lang="en" article-type="research-article"><front><journal-meta><journal-id journal-id-type="nlm-ta">JMIR Med Inform</journal-id><journal-id journal-id-type="publisher-id">medinform</journal-id><journal-id journal-id-type="index">7</journal-id><journal-title>JMIR Medical Informatics</journal-title><abbrev-journal-title>JMIR Med Inform</abbrev-journal-title><issn pub-type="epub">2291-9694</issn><publisher><publisher-name>JMIR Publications</publisher-name><publisher-loc>Toronto, Canada</publisher-loc></publisher></journal-meta><article-meta><article-id pub-id-type="publisher-id">v14i1e89685</article-id><article-id pub-id-type="doi">10.2196/89685</article-id><article-categories><subj-group subj-group-type="heading"><subject>Original Paper</subject></subj-group></article-categories><title-group><article-title>Admission Mechanisms for Scalable Federated Health Data Collaboration: Design and Proof-of-Concept Study</article-title></title-group><contrib-group><contrib contrib-type="author"><name name-style="western"><surname>Fenoglio</surname><given-names>Enzo</given-names></name><degrees>MSEE</degrees><xref ref-type="aff" rid="aff1">1</xref></contrib><contrib contrib-type="author" corresp="yes"><name name-style="western"><surname>Nieroda</surname><given-names>Marzena</given-names></name><degrees>PhD</degrees><xref ref-type="aff" rid="aff2">2</xref></contrib><contrib contrib-type="author"><name name-style="western"><surname>Carvalho</surname><given-names>Graca</given-names></name><degrees>MSc</degrees><xref ref-type="aff" rid="aff3">3</xref></contrib><contrib contrib-type="author"><name name-style="western"><surname>Smietanka</surname><given-names>Malgorzata</given-names></name><degrees>PhD</degrees><xref ref-type="aff" rid="aff4">4</xref></contrib><contrib contrib-type="author"><name name-style="western"><surname>Kalogeropoulos</surname><given-names>Dimitrios</given-names></name><degrees>PhD</degrees><xref ref-type="aff" rid="aff5">5</xref></contrib><contrib contrib-type="author"><name name-style="western"><surname>Treleaven</surname><given-names>Philip</given-names></name><degrees>PhD</degrees><xref ref-type="aff" rid="aff1">1</xref></contrib></contrib-group><aff id="aff1"><institution>UCL Computer Science, University College London</institution><addr-line>London</addr-line><addr-line>England</addr-line><country>United Kingdom</country></aff><aff id="aff2"><institution>UCL Global Business School for Health, University College London</institution><addr-line>Marshgate Building, 7 Sidings Street</addr-line><addr-line>London</addr-line><addr-line>England</addr-line><country>United Kingdom</country></aff><aff id="aff3"><institution>Departamento de Informatica, Universidade do Minho</institution><addr-line>Braga</addr-line><country>Portugal</country></aff><aff id="aff4"><institution>Actuari</institution><addr-line>London</addr-line><addr-line>England</addr-line><country>United Kingdom</country></aff><aff id="aff5"><institution>Global Health and Digital Innovation Foundation</institution><addr-line>London</addr-line><addr-line>England</addr-line><country>United Kingdom</country></aff><contrib-group><contrib contrib-type="editor"><name name-style="western"><surname>Coristine</surname><given-names>Andrew</given-names></name></contrib><contrib contrib-type="editor"><name name-style="western"><surname>Benis</surname><given-names>Arriel</given-names></name></contrib></contrib-group><contrib-group><contrib contrib-type="reviewer"><name name-style="western"><surname>Veltri</surname><given-names>Giuseppe</given-names></name></contrib><contrib contrib-type="reviewer"><name name-style="western"><surname>Goyal</surname><given-names>Nitin</given-names></name></contrib></contrib-group><author-notes><corresp>Correspondence to Marzena Nieroda, PhD, UCL Global Business School for Health, University College London, Marshgate Building, 7 Sidings Street, London, England, E20 2AE, United Kingdom, 44 07739873221; <email>m.nieroda@ucl.ac.uk</email></corresp></author-notes><pub-date pub-type="collection"><year>2026</year></pub-date><pub-date pub-type="epub"><day>30</day><month>10</month><year>2026</year></pub-date><volume>14</volume><elocation-id>e89685</elocation-id><history><date date-type="received"><day>16</day><month>12</month><year>2025</year></date><date date-type="rev-recd"><day>22</day><month>08</month><year>2026</year></date><date date-type="accepted"><day>29</day><month>09</month><year>2026</year></date></history><copyright-statement>&#x00A9; Enzo Fenoglio, Marzena Nieroda, Graca Carvalho, Malgorzata Smietanka, Dimitrios Kalogeropoulos, Philip Treleaven. Originally published in JMIR Medical Informatics (<ext-link ext-link-type="uri" xlink:href="https://medinform.jmir.org">https://medinform.jmir.org</ext-link>), 30.10.2026. </copyright-statement><copyright-year>2026</copyright-year><license license-type="open-access" xlink:href="https://creativecommons.org/licenses/by/4.0/"><p>This is an open-access article distributed under the terms of the Creative Commons Attribution License (<ext-link ext-link-type="uri" xlink:href="https://creativecommons.org/licenses/by/4.0/">https://creativecommons.org/licenses/by/4.0/</ext-link>), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR Medical Informatics, is properly cited. The complete bibliographic information, a link to the original publication on <ext-link ext-link-type="uri" xlink:href="https://medinform.jmir.org/">https://medinform.jmir.org/</ext-link>, as well as this copyright and license information must be included.</p></license><self-uri xlink:type="simple" xlink:href="https://medinform.jmir.org/2026/1/e89685"/><abstract><sec><title>Background</title><p>Many digital health and AI initiatives show promising results in pilot settings but do not progress to sustainable services. Pilots can operate within a predefined collaboration, whereas operational services must accommodate changes in participating organizations, available resources, and analytical capabilities while preserving established governance and technical arrangements.</p></sec><sec><title>Objective</title><p>This study examines the pilot-to-service transition as a problem of governed federation evolution and evaluates whether Open Health can admit new forms of participation while preserving bounded capabilities, organizational sovereignty, and auditable decision evidence.</p></sec><sec sec-type="methods"><title>Methods</title><p>Open Health applies federated computing (FC) as a governance model separated from the analytical runtime. A governed federation context is established before execution, participants receive holder-bound capabilities, and an admission gateway produces explicit ALLOW or DENY decisions before requested operations proceed. The proof of concept uses the Flower federated learning framework and the Pathology Modified National Institute of Standards and Technology (PathMNIST) dataset from the MedMNIST collection with an initial federation comprising hospitals A and B. Mode 1A introduces hospital C as a sponsored contributor permitted to submit locally computed training updates but not invoke the resulting federated model for inference. Mode 1B examines bounded AI-agent participation, where restricted results may be transformed through policy-authorized operations into derivatives whose consumption is governed independently from the source. Evaluation considers admission conformance, signed decision evidence, analytical effects of the additional contribution, and admission overhead.</p></sec><sec sec-type="results"><title>Results</title><p>The demonstrator admitted valid member operations and hospital C&#x2019;s sponsored contribution (mode 1A) while denying model consumption outside hospital C&#x2019;s capability, scope violations, holder-binding mismatch, and federation-envelope mismatch. Mode 1B extended the same bounded-governance pattern to AI-agent participation, admitting bounded inference and governed transformation but denying unauthorized source consumption and privileged governance access. Under matched training conditions, cancer-related macro recall increased from 50.2% in the A+B control to 67.4% in A+B+C (+17.2 percentage points), while noncancer macro recall changed from 85.5% to 86.3% (+0.8 percentage points). Recall increased from 19.5% to 39.9% for cancer-associated stroma and from 80.9% to 94.9% for colorectal adenocarcinoma epithelium. Median (IQR) full admission latency was 1.210 (1.141-1.333) ms for ALLOW, 1.195 (1.136-1.273) ms for capability-scope DENY, and 0.884 (0.837-0.921) ms for holder-binding DENY. Each evaluated request generated signed decision evidence recording the decision, reason, participant and request bindings, governance context, and related model run.</p></sec><sec sec-type="conclusions"><title>Conclusions</title><p>Open Health demonstrates how a federated health-data collaboration can evolve through differentiated participation while preserving membership boundaries and bounded capability relations. The principal contribution is an executable governance boundary preserving capability relations and producing independently verifiable decision evidence separately from the federated-learning runtime. The analytical experiment showed that governed admission of an additional contributor produced a measurable effect on the intended cancer-related classes while preserving noncancer performance. The proof of concept establishes governance behavior under controlled conditions; clinical effectiveness and production-scale performance require further evaluation.</p></sec></abstract><kwd-group><kwd>federated learning</kwd><kwd>federated analytics</kwd><kwd>health data collaboration</kwd><kwd>federation admission</kwd><kwd>data governance</kwd><kwd>artificial intelligence</kwd><kwd>health informatics</kwd><kwd>federated computing</kwd></kwd-group></article-meta></front><body><sec id="s1" sec-type="intro"><title>Introduction</title><sec id="s1-1"><title>Background</title><p>Digital health and clinical AI increasingly depend on access to diverse, multimodal, and representative data distributed across organizations and care settings. Models developed or validated within a single institution may not perform consistently across different populations or operational contexts, whereas broader cross-organizational collaboration can improve robustness and generalization by reducing dependence on narrowly defined local datasets [<xref ref-type="bibr" rid="ref1">1</xref>-<xref ref-type="bibr" rid="ref3">3</xref>].</p><p>Despite substantial investment in digital health and AI, many initiatives that show promising results in pilot settings do not progress to sustainable operational services [<xref ref-type="bibr" rid="ref4">4</xref>,<xref ref-type="bibr" rid="ref5">5</xref>]. Explanations commonly emphasize model performance, data quality, clinical validation, and local implementation barriers, but operationalization may also require the collaboration itself to change. Adding an organization can entail further contracting, governance review, technical integration, and assurance, and large-scale health-data programs have identified organizational and technical integration as important sources of delay [<xref ref-type="bibr" rid="ref6">6</xref>].</p><p>Pilots can usually operate within a predefined collaborative arrangement in which participating organizations, datasets, analytical objectives, and responsibilities are established before execution and remain relatively stable. Operational services must accommodate changes in participation, available data, and analytical capabilities as needs and circumstances evolve. Scaling concerns not only the execution of distributed computation but also the ability of a governed collaboration to evolve without reconstructing its governance and technical arrangements for each new activity. Recent system-level evidence from the National Health Service AI Lab similarly identifies the pilot-to-scale gap, with fragmented governance and lack of system orchestration among the mutually reinforcing mechanisms constraining the scaling of health care AI [<xref ref-type="bibr" rid="ref7">7</xref>]. In this study, scalability refers to the capacity of the governed collaboration to accommodate changes in participants, resources, and operations without altering its governance conditions. Computational throughput and deployment scale are outside this definition.</p><p>Existing health-data infrastructures address important parts of this problem at different boundaries. Centralized platforms provide common custody and access mechanisms, trusted research environments (TREs) provide controlled analytical access to governed datasets, federated learning (FL) frameworks coordinate computation across organizational boundaries, keeping raw data local, and dataspace or policy frameworks establish requirements for participation and data sovereignty. Their functions remain necessary, yet the decision that a participant may enter a particular federated activity under a defined authority, purpose, and set of capabilities can remain distributed across contracts, accreditation, identity systems, application configuration, and operational controls.</p><p>Open Health addresses the transition from fixed collaboration to evolving service through federated computing (FC), which represents collaboration as a governed structure within which autonomous organizations retain sovereignty over local data and systems for participating under shared governed rules [<xref ref-type="bibr" rid="ref8">8</xref>,<xref ref-type="bibr" rid="ref9">9</xref>]. FC complements health-data platforms, identity systems, FL frameworks, and organization-local security controls by providing the governance structure through which participation becomes legitimate within an existing federation.</p><p>Session-bound admission is one mechanism for establishing such participation [<xref ref-type="bibr" rid="ref10">10</xref>]. Admission is evaluated for a specific governed activity, purpose, and bounded set of capabilities. Different participation relations can coexist within the same federation. An organization may, for example, submit locally computed model updates to federated training, without exposing its underlying local data, under a bounded contribution relation while retaining a status distinct from existing federation members. Contribution and model consumption are governed through separate capabilities, where a capability denotes an explicitly granted permission to perform a specified federation operation. Collaboration growth can proceed through purpose-specific and asymmetric participation relations, preserving the governance conditions of the federation.</p><p>The Open Health demonstrator examines this proposition in a multisite FL setting using Pathology Modified National Institute of Standards and Technology (PathMNIST) [<xref ref-type="bibr" rid="ref11">11</xref>,<xref ref-type="bibr" rid="ref12">12</xref>]. PathMNIST provides a biomedical benchmark derived from colorectal histopathology, but the federation-level partitioning used in this study is experimentally constructed and is not intended to reproduce the full clinical, organizational, or technical heterogeneity of operational health institutions.</p><p>An initial federation comprising hospitals A and B is extended through the governed participation of hospital C as a sponsored contributor. Hospital C may contribute to federated training but may not consume the resulting model only by virtue of that contribution. The implementation enables examination of whether federation participation can expand and preserve explicit authority, capability boundaries, session binding, and auditable decision evidence. This study, therefore, addresses the following research question: Can an open federated health data collaboration support governed evolution through new forms of participation and preserve bounded capabilities and auditable decision evidence?</p><p>The paper makes 3 contributions: First, it reframes the transition from pilot to service as a problem of governed federation evolution beyond computational or data scale. Second, it presents an Open Health implementation of FC in which session-bound admission, capability separation, and auditable decision evidence are integrated with a conventional FL runtime. Third, it evaluates governed federation evolution through controlled organizational and computational participation scenarios, together with the analytical consequence and admission overhead of the implemented mechanisms.</p><p>The remainder of the paper is organized as follows: the Methods section reviews existing approaches to collaborative health-data infrastructure and their governance boundaries, introduces the FC and federation-admission principles used by Open Health, and describes the system implementation, experimental scenarios, and evaluation criteria. The Results section reports the admission, analytical, AI-agent conformance, and admission-overhead results. The Discussion section discusses the principal findings, their relationship to existing health-data infrastructure, the role of decision evidence and governed AI-agent participation, and the limitations and directions for future work.</p></sec><sec id="s1-2"><title>Existing Solutions and Related Work</title><sec id="s1-2-1"><title>Collaborative Health-Data Infrastructures</title><p>Health-data collaboration is supported by several classes of infrastructure, including centralized data platforms, TREs, proprietary federated platforms, open-source FL frameworks, and policy or data-sovereignty frameworks. They are not direct substitutes because each establishes a different boundary around data custody, computation, participation, and governance.</p><p>Centralized data platforms simplify integration by bringing data under a common technical and administrative environment, where repository-level identity, access control, and data-management mechanisms can govern users and datasets [<xref ref-type="bibr" rid="ref13">13</xref>,<xref ref-type="bibr" rid="ref14">14</xref>]. Such an arrangement is effective when common custody is organizationally and legally acceptable but is less suitable when participating organizations must retain direct sovereignty over sensitive health data. TREs adopt a different boundary by providing controlled environments in which approved researchers or projects analyze specified datasets under explicit governance and disclosure controls. OpenSAFELY (Bennett Institute for Applied Data Science) [<xref ref-type="bibr" rid="ref15">15</xref>] is a prominent example. TREs provide strong mechanisms for research approval, controlled access, and accountability, principally governing access to approved data and projects. The evolution of a federation of autonomous organizations and operational relationships constitutes a separate governance problem.</p><p>Proprietary integration and federated platforms, including Rhino Health [<xref ref-type="bibr" rid="ref16">16</xref>], Syntropy [<xref ref-type="bibr" rid="ref17">17</xref>], and the Mayo Clinic Platform [<xref ref-type="bibr" rid="ref18">18</xref>], support cross-site analytics allowing participating organizations to retain local data. Their governance, deployment, and operational mechanisms are defined within the corresponding platform environment. Open-source FL frameworks such as Flower (Flower Labs GmbH) [<xref ref-type="bibr" rid="ref19">19</xref>], NVIDIA FLARE (NVIDIA Corporation) [<xref ref-type="bibr" rid="ref20">20</xref>], Intel OpenFL [<xref ref-type="bibr" rid="ref21">21</xref>], PySyft (Andrew Trask) [<xref ref-type="bibr" rid="ref22">22</xref>], and Substra (Owkin) [<xref ref-type="bibr" rid="ref23">23</xref>] similarly provide computational mechanisms for coordinating distributed machine-learning workflows, keeping raw data local. In both cases, FC can be technically coordinated, and authority to participate remains represented through platform governance, deployment configuration, or surrounding organizational processes. Hybrid cloud architectures provide another mechanism for retaining organizational control over sensitive data for performing distributed computation. Brown and Randall [<xref ref-type="bibr" rid="ref24">24</xref>] evaluated a secure record-linkage architecture in which identifiable information remained on premises, but privacy-preserving computation was performed in cloud infrastructure. Open Health addresses a complementary boundary by governing whether and under what conditions a participant may invoke a federated activity, independently from where the computation is executed.</p><p>Cross-organizational collaboration also depends on semantic interoperability because participating institutions may represent clinically equivalent concepts through different data structures, terminologies, coding systems, or information models. Rosenau et al [<xref ref-type="bibr" rid="ref25">25</xref>] developed an intermediate query representation to bridge heterogeneous repository-specific query languages within a federated German health research infrastructure. Shared vocabularies and ontologies can make distributed data interpretable across organizational boundaries. Entitlement to contribute a resource, consume a resulting model, or perform an operation under a particular authority is established separately through federation governance. Semantic interoperability and federation governance address complementary requirements.</p><p>Policy-oriented dataspace initiatives, including Gaia-X [<xref ref-type="bibr" rid="ref26">26</xref>], the European Health Data Space (EHDS) [<xref ref-type="bibr" rid="ref27">27</xref>], and Towards the European Health Data Space [<xref ref-type="bibr" rid="ref28">28</xref>], address trustworthy exchange, organizational eligibility, interoperability, and data sovereignty at the ecosystem level. Their emphasis on organizational control is closely aligned with cross-organizational health-data collaboration. Conversely, an operational federation-level admission decision cannot replace the regulatory, contractual, ethical, or organizational conditions that established eligibility.</p><p>AI-agent frameworks introduce a further implementation layer by coordinating how computational participants invoke tools, services, workflows, memory, or other runtime resources. Tool restrictions, isolation, approval mechanisms, and monitoring can constrain execution, but such controls do not determine whether an AI-driven process is entitled to participate in a federated health-data activity, under whose authority it acts, or which federation capabilities it may exercise. Open Health treats the agent framework as an execution mechanism whose implementation may vary independently of the federation&#x2019;s governance semantics.</p></sec><sec id="s1-2-2"><title>Governance Boundaries in Cross-Organizational Collaboration</title><p>Cross-organizational infrastructures depend on established identity and access-control mechanisms. Federated identity systems can authenticate principals across organizational boundaries. Open authorization (OAuth)&#x2013;based mechanisms, cloud identity and access management (IAM), role-based access control (RBAC), and attribute-based access control (ABAC) can control access to services and resources [<xref ref-type="bibr" rid="ref29">29</xref>-<xref ref-type="bibr" rid="ref32">32</xref>]. Such technologies provide necessary deployment foundations by establishing whether an identity can be trusted, whether a service account may invoke an API, or whether an actor possessing specified attributes may access a resource. Participation in a shared activity raises a different question because the relevant decision must be established across organizational boundaries.</p><p>In operational deployments, the effective participation decision may be distributed across cloud IAM policies, platform configuration, central policy services [<xref ref-type="bibr" rid="ref33">33</xref>-<xref ref-type="bibr" rid="ref35">35</xref>], contractual arrangements, and checks embedded in orchestration code. Heterogeneous identity and infrastructure stacks can make integration increasingly bespoke as collaborations evolve, but configuration changes can alter effective participation semantics and complicate reconstruction of earlier decisions. Organization-local access control and cross-organizational admission address different governance boundaries. The former controls activity within an administrative domain, whereas the latter establishes whether a participant may enter a specified collaborative activity under the applicable federation conditions.</p><p>Cross-silo FL illustrates the separation between computational coordination and participation governance. A federated learning (FL) framework can coordinate model distribution, local training, update submission, aggregation, and evaluation, leaving the authority for participation external to the learning procedure. Prior work on auditable session admission has shown that requests can be evaluated against session-specific capabilities and holder identity before reaching the FL runtime, producing explicit ALLOW or DENY decisions and structured decision evidence [<xref ref-type="bibr" rid="ref10">10</xref>]. The underlying training and aggregation procedure remains unchanged. Open Health adopts the separation between governance boundary and analytical runtime, applying it to the broader problem of federation evolution.</p><p><xref ref-type="table" rid="table1">Table 1</xref> summarizes the principal approaches according to the boundary at which governance is exercised, and the extent to which changes in participation become explicit operational decisions. The comparison is functional: the different approaches may coexist within the same health-data infrastructure. Open Health introduces a complementary boundary at the transition from institutional eligibility or agreement to participation in a particular governed federated activity. Authentication, regulatory or dataspace eligibility, FL-platform interoperability, and valid local permissions establish the necessary preconditions. Entitlement to a particular federation activity is determined separately through federation admission for the specified purpose and bounded capability. Open Health addresses that transition by making the participation decision explicit, session-bound, and auditable, leaving data custody, local identity, operational authorization, semantic interoperability, and analytical execution to the mechanisms suited to those functions.</p><table-wrap id="t1" position="float"><label>Table 1.</label><caption><p>Functional comparison of approaches supporting cross-organizational health-data collaboration.</p></caption><table id="table1" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Approach</td><td align="left" valign="bottom">Primary governance boundary</td><td align="left" valign="bottom">Data remain under organizational control</td><td align="left" valign="bottom">Controls operational access</td><td align="left" valign="bottom">Establishes purpose-specific participation</td><td align="left" valign="bottom">Participation decision externally auditable</td><td align="left" valign="bottom">Supports governed change of participation</td></tr></thead><tbody><tr><td align="left" valign="top">Centralized data platforms: enterprise cloud data lakes [<xref ref-type="bibr" rid="ref14">14</xref>]</td><td align="left" valign="top">Repository or data controller</td><td align="left" valign="top">Usually no</td><td align="left" valign="top">Yes</td><td align="left" valign="top">Deployment dependent</td><td align="left" valign="top">Deployment dependent</td><td align="left" valign="top">Through repository governance</td></tr><tr><td align="left" valign="top">TREs<sup><xref ref-type="table-fn" rid="table1fn1">a</xref></sup> [<xref ref-type="bibr" rid="ref15">15</xref>,<xref ref-type="bibr" rid="ref36">36</xref>,<xref ref-type="bibr" rid="ref37">37</xref>]</td><td align="left" valign="top">Approved project or research environment</td><td align="left" valign="top">Often logically controlled by custodian</td><td align="left" valign="top">Yes</td><td align="left" valign="top">Yes, for approved research</td><td align="left" valign="top">Yes</td><td align="left" valign="top">Primarily through new project or governance approval</td></tr><tr><td align="left" valign="top">Proprietary federated platforms [<xref ref-type="bibr" rid="ref16">16</xref>-<xref ref-type="bibr" rid="ref18">18</xref>]</td><td align="left" valign="top">Platform federation</td><td align="left" valign="top">Yes</td><td align="left" valign="top">Yes</td><td align="left" valign="top">Platform dependent</td><td align="left" valign="top">Platform dependent</td><td align="left" valign="top">Platform dependent</td></tr><tr><td align="left" valign="top">Open-source FL<sup><xref ref-type="table-fn" rid="table1fn2">b</xref></sup> frameworks [<xref ref-type="bibr" rid="ref19">19</xref>-<xref ref-type="bibr" rid="ref23">23</xref>]</td><td align="left" valign="top">Federated computation</td><td align="left" valign="top">Yes</td><td align="left" valign="top">Runtime dependent</td><td align="left" valign="top">Usually external to FL framework</td><td align="left" valign="top">Usually external</td><td align="left" valign="top">Usually external</td></tr><tr><td align="left" valign="top">Dataspace or sovereignty frameworks [<xref ref-type="bibr" rid="ref26">26</xref>-<xref ref-type="bibr" rid="ref28">28</xref>]</td><td align="left" valign="top">Ecosystem eligibility and exchange</td><td align="left" valign="top">Yes</td><td align="left" valign="top">Implementation dependent</td><td align="left" valign="top">At policy or ecosystem level</td><td align="left" valign="top">Governance dependent</td><td align="left" valign="top">Yes, principally at ecosystem level</td></tr><tr><td align="left" valign="top">Open Health or federated computing [<xref ref-type="bibr" rid="ref9">9</xref>]</td><td align="left" valign="top">Governed federation activity</td><td align="left" valign="top">Yes</td><td align="left" valign="top">Complementary local or runtime mechanisms</td><td align="left" valign="top">Explicit and session-bound</td><td align="left" valign="top">Explicit decision evidence</td><td align="left" valign="top">Through bounded participation relations</td></tr></tbody></table><table-wrap-foot><fn id="table1fn1"><p><sup>a</sup>TRE: trusted research environment.</p></fn><fn id="table1fn2"><p><sup>b</sup>FL: federated learning.</p></fn></table-wrap-foot></table-wrap></sec></sec></sec><sec id="s2" sec-type="methods"><title>Methods</title><sec id="s2-1"><title>Dimensions of Collaboration Growth</title><p>Scaling a collaboration requires changes not only in the number or type of participants but also in the resources available to the federation, and the operations participants may perform. The 3 dimensions are related but governed through different relations. New participants establish participation relations, new datasets or models extend the federation&#x2019;s resource base, and new analytical capabilities extend the set of permitted operations. Distinguishing them avoids collapsing heterogeneous entities and activities into a single category of objects to be admitted (<xref ref-type="table" rid="table2">Table 2</xref>).</p><table-wrap id="t2" position="float"><label>Table 2.</label><caption><p>Dimensions of collaboration growth and their associated governance questions.</p></caption><table id="table2" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Dimension of evolution</td><td align="left" valign="bottom">What changes</td><td align="left" valign="bottom">Governance question</td></tr></thead><tbody><tr><td align="left" valign="top">Participation</td><td align="left" valign="top">Organizations and human or computational participants, including AI agents</td><td align="left" valign="top">Under whose authority may they participate?</td></tr><tr><td align="left" valign="top">Resources</td><td align="left" valign="top">Datasets, models, compute, and analytical services</td><td align="left" valign="top">Under what conditions may they be contributed, exposed, or used?</td></tr><tr><td align="left" valign="top">Operations</td><td align="left" valign="top">Training, inference, validation, and analysis</td><td align="left" valign="top">Which activities are permitted, and for which purpose and scope?</td></tr></tbody></table></table-wrap><p>Open Health treats scaling as governed evolution across participants, resources, and operations. Rights remain specific to the relation in which they are established, providing the conceptual basis for the asymmetric participation relations examined in the experimental implementation.</p></sec><sec id="s2-2"><title>FC and the Governed Federation Context</title><p>Open Health applies FC to the problem of evolving cross-organizational health-data collaboration and treats the federation as a governed relational structure. Participating organizations retain sovereignty over their local data, infrastructure, identities, and internal access mechanisms; the federation embodies the shared conditions agreed among the participating organizations under which cross-organizational participation becomes legitimate. The resulting boundary is complementary to organization-local IAM, RBAC, or ABAC, TREs, FL frameworks, and other operational controls because those mechanisms continue to govern activity within their respective administrative or computational domains.</p><p>The constitutive governance conditions originate in the agreements established among the participating organizations rather than in the capabilities of the technical implementation. A governed federation context is established before operational execution. The context identifies the authorities participating in the collaboration, the applicable constitutional and policy state, the purpose of the activity, and the conditions under which participation may occur. Open Health represents the bounded context through a federation envelope, allowing later capability and admission decisions to be interpreted relative to the governance state under which they were made. Authentication establishes identity, and prior organizational eligibility establishes eligibility to participate. Federation admission separately establishes entitlement to a specified activity.</p><p>A federated service is an operational function exposed within a governed federation and retained under the control of the organization that provides it. The service and its underlying resources remain within that organizational domain. The federation governs the relations under which participants may invoke it, including authority, purpose, capability, scope, and federation context. FL model inference, data transformation, and other analytical functions may be exposed as federated services and remain operational functions outside the federation&#x2019;s constitutive governance.</p><p>FC as Code (FCaC) [<xref ref-type="bibr" rid="ref9">9</xref>] provides the machine-processable representation through which these governance relations are expressed and evaluated. In Open Health, the governed federation context, participant authority, capabilities, purpose, scope, and related constraints are represented as executable artifacts that can be tested at the admission boundary. We separate governance establishment and capability expression from operational execution: FC models the relations governing participation, FCaC renders those relations machine-processable, admission evaluates them for a requested activity, and the corresponding federated service performs the admitted operation. Keeping these concerns distinct allows the participation structure to evolve independently of the analytical runtime and organization-local security mechanisms. Federation governance remains represented in its own constitutive artifacts, and operational configuration changes leave the conditions of participation unchanged.</p><p>FC provides a structure in which collaboration can evolve through changes in relations among participants, resources, and operations. A new organization does not need to acquire the rights of an existing member; a newly contributed resource need not become available to every participant, and permission to perform one operation need not imply permission to perform another. The relevant governance question is not whether an entity has been globally admitted to the federation, but whether a particular participation relation is legitimate within the governed context.</p></sec><sec id="s2-3"><title>Session-Bound Admission</title><sec id="s2-3-1"><title>Overview</title><p>Session-bound admission operationalizes the transition from an established governance context to a requested federated activity [<xref ref-type="bibr" rid="ref10">10</xref>]. In the earlier FL-specific formulation, that governed context was exposed as a session identifier, retaining the semantics of the underlying federation envelope. Open Health makes the federation-context semantics explicit and applies the same boundary-oriented principle to participation relations that may change over time. The admission decision asks whether a specific participant may perform a specified operation, for a defined purpose and scope, within the current governed context. An admission decision with the value ALLOW or DENY is produced before the requested activity reaches the corresponding analytical or operational runtime.</p><p>Capabilities used at the admission boundary are contextual, not global. A capability issued for one governed context is not a reusable entitlement to arbitrary future activities, and possession of a capability is not equivalent to federation membership. Admission evaluates the holder, requested operation, purpose, resource, and scope against the capability and the governance state associated with the federation envelope. The analytical runtime remains responsible for executing an admitted activity. Legitimacy of the preceding participation relation is established separately at the federation boundary.</p></sec><sec id="s2-3-2"><title>Admission of Participants</title><p>A participant may be a human actor or a conventional software process acting within the federation under an accountable organizational relationship. The issuer expresses the participant&#x2019;s permitted federation activity through a bounded capability associated with the current federation envelope. Holder binding connects the capability to the participant for whom it was issued, while purpose, operation, resource, and scope delimit the activity that may subsequently be requested. The gatekeeper then evaluates the presented capability against the current governed context, with issuance and admission remaining separate decisions.</p><p>Separating issuance from admission supports differentiated participation. An established member may hold capabilities for both training and model use, whereas another organization may receive only a contribution capability for a specified federated training activity. Sponsorship provides an accountable route for establishing bounded participation while preserving the sponsor&#x2019;s rights as a separate governance relation. Delegation and federation membership remain in separate governance relations.</p><p>The same separation applies across capability categories. Contribution and consumption are governed through separate capabilities. Admission authorizes only the specified operation and scope. Provenance similarly records where a participant, credential, model, or other artifact originates, whereas accountability concerns the authority under which participation occurs, and the party responsible for that relationship. Treating provenance and accountability as separate relations avoids inferring federation rights from technical origin or organizational association alone.</p><p>Admission decisions also produce explicit governance evidence. The evidence associates the participant, governed context, requested activity, capability, purpose, decision outcome, and reason for the decision. These boundary-generated artifacts provide the information needed to reconstruct successful and denied requests independently of application logs and historical system configurations. They also link governance intent to operational participation and preserve the decentralization of organization-local policy mechanisms.</p></sec><sec id="s2-3-3"><title>Admission of AI Agents</title><p>AI agents do not require a separate constitutive governance category. From the perspective of FC, an AI agent is a form of computational participant acting under an accountable organizational relationship. The model provider, planning strategy, memory architecture, tool framework, or execution runtime may affect how the agent behaves, but none of those implementation properties independently determines its federation rights. Admission remains governed through the same relations of authority, purpose, capability, holder binding, and federation context that apply to other participants.</p><p>Agent participation nevertheless introduces an additional operational distinction between runtime capability and federation capability. An agent runtime may expose file access, network communication, tools, APIs, or other execution mechanisms. Federation entitlement is established independently through admitted capabilities. Admission authorizes the specified federation operation and scope, while local runtime and external-environment permissions remain governed by their respective controls. The federation governs boundary crossing, and the agent runtime governs how admitted execution is carried out.</p><p>Admission cannot certify that an AI agent will behave correctly after execution begins. In this study, agent containment denotes complementary runtime controls such as sandboxing, network isolation, tool policies, approval mechanisms, and monitoring that restrict what the agent can do after admission. Federation participation remains defined by the admitted capability relations, and the execution framework must not expose federation operations beyond those relations. Assurance therefore depends on conformance between the agent&#x2019;s effective execution possibilities and the capabilities established by the governed admission decision. The bounded AI-agent scenario evaluates this requirement under the same federation-governance model used for human and conventional computational participants.</p></sec><sec id="s2-3-4"><title>Threat and Trust Boundary</title><p>The threat model considered in this study concerns unauthorized enlargement of federation participation or capability relations. Attacks on the FL algorithm itself are outside its scope. The evaluated boundary includes capability or scope violations, holder-binding mismatch, federation-envelope mismatch, unintended propagation of rights through sponsorship or contribution, and attempts by a computational participant to exercise authority outside its admitted execution path. Model poisoning, membership inference [<xref ref-type="bibr" rid="ref38">38</xref>], gradient leakage, model inversion [<xref ref-type="bibr" rid="ref39">39</xref>], Byzantine aggregation, and related attacks on the analytical runtime remain outside the admission-governance mechanism evaluated here and require complementary protections at the FL and organization-local security layers [<xref ref-type="bibr" rid="ref2">2</xref>].</p></sec></sec><sec id="s2-4"><title>Open Health System Implementation</title><sec id="s2-4-1"><title>System Architecture</title><p>The Open Health demonstrator implements a governed FL environment in which participation is established before execution of the corresponding distributed computation. The architecture separates the governance and admission plane from the analytical runtime so that the conditions under which an organization or computational participant acts can be evaluated independently from the technology executing the work. <xref ref-type="fig" rid="figure1">Figure 1</xref> summarizes the implementation as four interacting areas comprising the federation-authority and participant interfaces, the Open Health governance and orchestration services, the FL runtime, and the participating hospital sites. The proof of concept is implemented as a local containerized Docker deployment. The conditions the architecture must satisfy are stated independently as a conformance criterion for FCaC [<xref ref-type="bibr" rid="ref40">40</xref>]. All cross-boundary operations in the demonstrator traverse this admission boundary before reaching the corresponding federated service. No path into a participating site bypasses it.</p><fig position="float" id="figure1"><label>Figure 1.</label><caption><p>Open Health proof-of-concept architecture. The governance and admission layer establishes session-bound participation before execution by the federated learning runtime. Hospitals retain their Pathology Modified National Institute of Standards and Technology data locally. The Flower runtime exchanges model updates rather than raw data. Hospital C participates as a sponsored contributor with a capability restricted to federated training; model-consumption rights are governed separately. A bounded AI agent participates through the same governed admission path but may exercise only the capabilities granted within the active federation context. ECT: envelope capability token; LLM: large language model. C4: context, containers, components, and code; CDI: Centre for Digital Innovation;</p></caption><graphic alt-version="no" mimetype="image" position="float" xlink:type="simple" xlink:href="medinform_v14i1e89685_fig01.png"/></fig><p>Flower remains responsible for distributed model training and aggregation [<xref ref-type="bibr" rid="ref19">19</xref>]. Open Health governs participation at the federation boundary. Each hospital retains its PathMNIST partition locally and exchanges only model updates through the Flower workflow, so raw images remain within the originating site. This separation confines the Open Health contribution to participation governance and leaves the learning algorithm and analytical runtime unchanged.</p></sec><sec id="s2-4-2"><title>Governance and Admission Workflow</title><p>Before a federated activity begins, the federation authority establishes a governed context represented by an envelope. Creation, binding, and approval of the envelope associate the activity with the applicable constitutional and policy state. The Key Your Organization (KYO) procedure establishes the envelope through mutual transport layer security (mTLS)&#x2013;authenticated organizational approvals and the required federation quorum. The resulting envelope_id is the admission binding for subsequent participation decisions and remains distinct from the operational model run created after admission [<xref ref-type="bibr" rid="ref9">9</xref>].</p><p>Participants receive envelope capability tokens (ECTs) through the Open Health issuer service. Each ECT expresses the bounded resource, operation, purpose, and scope available to its holder and associates that capability with the governed federation context [<xref ref-type="bibr" rid="ref10">10</xref>]. Its signature is verified against a public trust anchor associated with an issuer authorized in that context. Capability issuance, admission, and federation membership are established independently, allowing a participant to hold a narrowly scoped capability while other federation activities remain outside its authorization. For each governed request, the holder presents a request-bound demonstrating proof-of-possession (DPoP) proof signed with the key associated with the ECT. The proof binds the credential presentation to the evaluated request and establishes control of the holder key [<xref ref-type="bibr" rid="ref41">41</xref>].</p><p>Constitutional and policy artifacts are compiled into machine-evaluable constraints for the admission boundary. The verifier and gatekeeper evaluate the ECT, holder proof, envelope_id, requested operation, purpose, resource, and scope against the current compiled governance state. Admission evaluation is stateless and fail-closed. A missing, malformed, expired, or unverifiable artifact yields DENY. No discretionary path or operator override is available at the admission boundary.</p></sec><sec id="s2-4-3"><title>Runtime, State, and Decision Evidence</title><p>The web interface is built with React 18 (Meta Platforms) and Vite 7.3.5 (VoidZero), the gateway runs Nginx (F5, Inc), and the backend services are implemented with FastAPI (Sebasti&#x00E1;n Ram&#x00ED;rez). Participant and federation-authority operations are exposed through this interface and routed through the Nginx gateway to the OpenHealth services. The fc-hub FastAPI service coordinates. The fc-hub FastAPI service coordinates the governed workflow and maintains the association between the current federation context and the operational FL run, but policy evaluation remains the responsibility of the verifier and gatekeeper. The interface and orchestration services expose governance state and invoke governed operations, while governance semantics remain defined by the federation&#x2019;s constitutive artifacts.</p><p>Constitutional and policy artifacts, active federation envelopes, and admission evidence are maintained separately from the Flower runtime. Each evaluated request produces a structured decision record containing the relevant participant, governed context, requested capability, purpose and scope, decision outcome, and reason.</p><p>The run registry maintains a traceable association between the governed federation context and the model run executed by Flower, preserving them as distinct objects. Capability credentials remain bound to the federation envelope and do not extend automatically to future model runs. A decision concerning a particular executed run may record the corresponding run association when applicable. Governance context, capability, admission decision, and model run remain distinct artifacts connected through explicit relations.</p></sec><sec id="s2-4-4"><title>Experimental Scenarios</title><p>The experimental design uses PathMNIST [<xref ref-type="bibr" rid="ref11">11</xref>,<xref ref-type="bibr" rid="ref12">12</xref>] to examine governed evolution of an initially fixed federation. Hospitals A and B establish the baseline federation. The scenarios then change the governed participation relations without changing the analytical runtime, first by admitting hospital C as a sponsored contributor and then through bounded AI-agent participation. Governance and analytical outcomes are evaluated independently. Admission correctness is established through preservation of the specified capability relations, whereas model performance is evaluated through the resulting analytical outcomes.</p></sec><sec id="s2-4-5"><title>A+B Baseline</title><p>Hospitals A and B constitute the initial federation and participate as established members under the same governed federation context. Each hospital retains its local PathMNIST partition and operates a Flower client that performs local training and submits model updates to the federated aggregation process. Raw images remain within the corresponding hospital environment, and the shared model is produced through conventional federated training after the required participation has been admitted.</p><p>PathMNIST contains nine classes comprising adipose tissue, background, debris, lymphocytes, mucus, smooth muscle, normal colon mucosa, cancer-associated stroma, and colorectal adenocarcinoma epithelium. Background was excluded from the publication experiment because it represents image background rather than a histological tissue category and is therefore outside the scope of the tissue-specific analytical comparison. The active noncancer classes were adipose tissue, debris, lymphocytes, mucus, smooth muscle, and normal colon mucosa, while cancer-associated stroma and colorectal adenocarcinoma epithelium formed the cancer-related group.</p><p>The federation partition was experimentally constructed. Hospitals A and B each received 30% of the observations allocated to every active noncancer class and 5% of those allocated to each cancer-related class. Consequently, the A+B control contained 60% of the allocated observations for every active noncancer class and 10% for each cancer-related class. The remaining observations were assigned to hospital C.</p><p>Two roles of the A+B configuration are distinguished in the evaluation. The initial A+B run establishes the governance and system baseline in which the federation consists only of its existing members. For the analytical comparison, an A+B control is trained under conditions matched to the A+B+C configuration, preserving the same model architecture and learning procedure so that the comparison isolates the effect of the additional admitted contribution rather than differences in training configuration.</p></sec><sec id="s2-4-6"><title>Mode 1A: Governed Expansion With a Sponsored Contributor</title><p>Hospital C is admitted to federated training as a sponsored contributor under a participation relation distinct from federation membership. Sponsorship establishes an accountable, bounded participation relation for hospital C. Its capability is restricted to the submit_update operation for the specified federated-training purpose and remains bound to the current governed federation context. Admission authorizes that specific activity while preserving hospital C&#x2019;s sponsored-contributor status and the separation from member capabilities.</p><p>Model consumption is represented independently from contribution and is absent from the capability granted to hospital C. The implementation permits hospital C to contribute model updates to an admitted federated-training activity, remaining unable to query or otherwise consume the resulting model. Contribution and consumption are governed as distinct relations not inferred from participation or organizational association.</p><p>Hospital C contributed 40% of the observations allocated to each active noncancer class and 90% of the observations allocated to each cancer-related class. Accordingly, the A+B+C configuration contained the full set of allocations for every active class. Mode 1A produces two independent evaluation dimensions. The governance dimension examines whether contributions are admitted, while operations outside hospital C&#x2019;s granted capability, including model consumption, remain denied. The analytical dimension compares the matched A+B control with the A+B+C model to determine whether the admitted contribution produces an observable analytical consequence.</p></sec><sec id="s2-4-7"><title>Mode 1B: Bounded AI-Agent Participation</title><p>Mode 1B introduces an AI agent as a computational participant acting within the same governed federation context as the human participants. The agent has a dedicated identity and holder-bound capabilities that permit narrowly scoped inference operations but do not confer federation membership or unrestricted access to model outputs. Its execution environment is isolated from privileged governance services so that technical reachability cannot enlarge the participation relation established through admission.</p><p>The scenario considers a requester seeking cancer-related information whose unrestricted form lies outside the requester&#x2019;s authorized consumption scope. Direct source consumption is therefore denied. The agent may invoke an explicitly governed rebind operation, transforming the restricted result into a policy-authorized derivative representation, which the demonstrator implements as a blurred image accompanied by a qualitative indication of model accuracy. The federation policy determines the transformation. The term rebind is retained throughout this paper in its broader operational sense of placing a derived representation under a new governance relation. This terminology emphasizes the governed outcome of the operation. In the stricter formalization of [<xref ref-type="bibr" rid="ref8">8</xref>], the value-changing transformation V&#x2192;W constitutes an Unbind, whereas Rebind preserves the value while tightening its governance envelope.</p><p>Source and derivative consumption are governed independently. The agent performs the transformation under its own admitted authority, and the requester&#x2019;s access to the resulting derivative is evaluated under a separate derivative-consumption capability. The transformation and subsequent consumption remain distinct governed operations within the same federation context, preserving the distinction between the capabilities of the computational participant and those of the requesting participant.</p></sec><sec id="s2-4-8"><title>AI-Agent Participation and Governance Invariants</title><p>The mode 1B design makes explicit a set of governance invariants that remain independent from the agent framework used to implement the computational participant. An agent runtime may determine how tasks are planned and tools are invoked, but the execution mechanism cannot redefine the authority under which the participant entered the federation (<xref ref-type="table" rid="table3">Table 3</xref>).</p><table-wrap id="t3" position="float"><label>Table 3.</label><caption><p>Federated computing governance invariants for AI-agent participation. These invariants are the agent-participation case of the general conformance criterion for federated computing as code [<xref ref-type="bibr" rid="ref40">40</xref>].</p></caption><table id="table3" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Governance invariant</td><td align="left" valign="bottom">Operational consequence for AI-agent participation</td></tr></thead><tbody><tr><td align="left" valign="top">Admission is governed</td><td align="left" valign="top">Technical reachability is insufficient; the computational participant must be explicitly admitted to the requested federation activity.</td></tr><tr><td align="left" valign="top">Authority is explicit and bounded</td><td align="left" valign="top">The agent acts only within the authority, purpose, operation, resource, and scope represented by the admitted capability.</td></tr><tr><td align="left" valign="top">Sponsorship is distinct from delegation</td><td align="left" valign="top">A sponsoring organization establishes an accountable participation route; its federation capabilities remain with the sponsor.</td></tr><tr><td align="left" valign="top">Provenance is distinct from accountability</td><td align="left" valign="top">The agent participates under an explicitly established authority relation, independent of the origin of its model, framework, runtime, or provider.</td></tr><tr><td align="left" valign="top">Credentials remain bound to the federation envelope</td><td align="left" valign="top">A capability issued for one governed context remains valid only within that federation envelope and its associated activity.</td></tr><tr><td align="left" valign="top">Contribution and consumption are independently governed</td><td align="left" valign="top">Contribution capabilities and model-query or model-use capabilities are established as separate relations.</td></tr><tr><td align="left" valign="top">Execution cannot redefine governance</td><td align="left" valign="top">Tools, network paths, or runtime functions that are technically available cannot enlarge the participation relation established by the admission decision.</td></tr><tr><td align="left" valign="top">Derivative consumption is distinct from source consumption</td><td align="left" valign="top">A policy-authorized rebind may create a derivative that can be consumed under a capability relation different from that governing the source representation.</td></tr></tbody></table></table-wrap><p>For an admitted computational participant, conformance requires the effective operational possibilities exposed by the execution environment to remain within the capabilities established by the governed admission decision. The criterion evaluates whether runtime behavior remains within the admitted capability boundary, including when execution is variable or fallible. It does not require the computational participant to be predictable; it makes preservation of the asserted governance boundary observable and testable even when the internal behavior of that participant varies.</p></sec></sec><sec id="s2-5"><title>Evaluation Criteria</title><p>The demonstrator is evaluated along complementary governance and analytical dimensions. Governance behavior is assessed through positive and negative admission tests covering valid session admission, capability mismatch, holder-binding mismatch, sponsorship-based contribution, denial of model consumption to a contribution-only participant, and preservation of federation-context binding. Decision evidence is examined for the ability to associate ALLOW and DENY outcomes with the participant, requested operation and purpose, governed context, reason, and relevant model run when applicable.</p><list list-type="bullet"><list-item><p>Mode 1A evaluates the analytical effect of governed federation expansion by comparing the matched A+B control with A+B+C. Cancer-related macro recall is the unweighted mean recall of classes 7 and 8. Noncancer macro recall is the unweighted mean recall of active classes 0, 2, 3, 4, 5, and 6. Class-specific recall for cancer-associated stroma and colorectal adenocarcinoma epithelium is also reported. Global macro recall and overall accuracy are reported descriptively. Analytical outcome and governance correctness are evaluated independently.</p></list-item><list-item><p>Mode 1B evaluates conformance between the capability relations specified for the computational participant and the effective execution possibilities exposed to it. General claims about agent safety, autonomy, or model reliability fall outside the evaluation.</p></list-item></list></sec><sec id="s2-6"><title>Admission Overhead</title><p>Admission overhead is evaluated through a request-level microbenchmark of the admission gateway. Three decision paths are exercised: a valid ECT and holder proof with a permitted capability (ALLOW), a valid ECT and holder proof with a capability or scope mismatch (DENY-Cap), and a valid ECT presented with a mismatched holder proof (DENY-Holder). Each iteration uses a fixed valid federation context and capability credential for generating a fresh request-bound DPoP proof [<xref ref-type="bibr" rid="ref41">41</xref>]. Per-request timings are recorded inside the admission gateway using a monotonic high-resolution clock. Measurements are retained in memory during the benchmark and written to a JavaScript Object Notation Lines (JSONL) log after the run, excluding filesystem I/O from the measured request path. The benchmark uses 1000 requests per decision path under no concurrent load, and latency is summarized as the median with the 25th and 75th percentiles.</p></sec><sec id="s2-7"><title>Ethical Considerations</title><p>This study involved no human participants or identifiable personal data. All experiments used PathMNIST, a publicly available, anonymized dataset [<xref ref-type="bibr" rid="ref11">11</xref>,<xref ref-type="bibr" rid="ref12">12</xref>], and hospitals A, B, and C were simulated participants. Under University College London guidance, research using anonymized public-domain datasets is minimal risk and does not require ethical approval [<xref ref-type="bibr" rid="ref42">42</xref>], and Health Research Authority guidance generally excludes research using previously collected, nonidentifiable information from research ethics committee review [<xref ref-type="bibr" rid="ref43">43</xref>]. Ethics review and informed consent were therefore not sought.</p></sec></sec><sec id="s3" sec-type="results"><title>Results</title><sec id="s3-1"><title>Admission Behavior and Decision Evidence</title><p>The Open Health implementation produced explicit admission decisions for permitted and rejected requests at the federation boundary. In this study, evidence denotes the signed, machine-generated decision artifact emitted by the admission mechanism for each evaluated request. It is distinct from the capability credential presented by the requester, from application logs, and from the analytical artifacts produced by the FL runtime. The approach follows earlier session-admission work in treating the decision outcome, its reason, and the bindings required to reconstruct the evaluated request as first-class experimental outputs [<xref ref-type="bibr" rid="ref10">10</xref>].</p><p>Each Open Health decision record identifies the admission event and timestamp, records the ALLOW or DENY outcome and reason, and associates the requester and holder-binding result with the relevant organizational and sponsorship information. The record also captures the requested action, purpose, and tissue scope, the governing federation envelope, the policy hash, and the related model run when applicable. Request and credential identifiers bind the decision to the specific presentation that was evaluated. An independent evidence signature protects the integrity of the resulting artifact.</p><p>The resulting evidence is independently verifiable and not merely observable. A verifier possessing the federation&#x2019;s public trust anchor can check the signature and inspect the recorded outcome, reason, request bindings, and governance state independently of mutable dashboard state and historical Flower-runtime configuration. Evidence establishes the governance decision and the conditions under which it was made. Clinical correctness of the subsequent analytical result is evaluated separately (<xref ref-type="table" rid="table4">Table 4</xref>).</p><table-wrap id="t4" position="float"><label>Table 4.</label><caption><p>Principal elements of an Open Health admission-evidence record.</p></caption><table id="table4" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Evidence element</td><td align="left" valign="bottom">Representative content</td><td align="left" valign="bottom">Audit role</td></tr></thead><tbody><tr><td align="left" valign="top">Decision</td><td align="left" valign="top">Decision identifier, timestamp, ALLOW or DENY, and reason</td><td align="left" valign="top">Identifies the outcome produced at the admission boundary and why it was reached.</td></tr><tr><td align="left" valign="top">Principal and accountability</td><td align="left" valign="top">Subject, actor type, issuing organization, sponsorship relation, and requester-binding result</td><td align="left" valign="top">Associates the decision with the participant and the authority relation under which the request was made.</td></tr><tr><td align="left" valign="top">Requested activity</td><td align="left" valign="top">Operation, purpose, resource, and requested tissue scope</td><td align="left" valign="top">Records the activity against which the presented capability was evaluated.</td></tr><tr><td align="left" valign="top">Governed context</td><td align="left" valign="top">Federation envelope, policy hash, and related model run when applicable</td><td align="left" valign="top">Binds the decision to the governance state and operational context in which it was valid.</td></tr><tr><td align="left" valign="top">Request and credential binding</td><td align="left" valign="top">Request identifier and capability-credential fingerprint</td><td align="left" valign="top">Distinguishes the evaluated presentation from other requests or credentials.</td></tr><tr><td align="left" valign="top">Integrity</td><td align="left" valign="top">Signed decision artifact and evidence-key identifier</td><td align="left" valign="top">Allows later verification that the recorded decision has not been modified.</td></tr></tbody></table></table-wrap><p>Positive and negative tests were used to determine whether the admission boundary preserved the capability relations specified by the federation. <xref ref-type="table" rid="table5">Table 5</xref> summarizes the principal cases. Ordinary member participation, hospital C&#x2019;s sponsored contribution, attempted model consumption outside hospital C&#x2019;s capability, scope violations, holder-binding failure, and federation-envelope mismatch are evaluated independently. Each case produces its own decision record. Each DENY is recorded as an explicit governance event.</p><table-wrap id="t5" position="float"><label>Table 5.</label><caption><p>Admission and capability-conformance results.</p></caption><table id="table5" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Test condition</td><td align="left" valign="bottom">Expected</td><td align="left" valign="bottom">Observed</td><td align="left" valign="bottom">Decision evidence</td></tr></thead><tbody><tr><td align="left" valign="top">Established member requests an operation within the admitted capability</td><td align="left" valign="top">ALLOW</td><td align="left" valign="top">ALLOW</td><td align="left" valign="top">Capability match</td></tr><tr><td align="left" valign="top">Hospital C submits an update for the admitted federated training purpose</td><td align="left" valign="top">ALLOW</td><td align="left" valign="top">ALLOW</td><td align="left" valign="top">Capability match under sponsored contribution</td></tr><tr><td align="left" valign="top">Hospital C requests model consumption outside its granted capability</td><td align="left" valign="top">DENY</td><td align="left" valign="top">DENY</td><td align="left" valign="top">Capability violation</td></tr><tr><td align="left" valign="top">Requested pathology scope exceeds the capability scope</td><td align="left" valign="top">DENY</td><td align="left" valign="top">DENY</td><td align="left" valign="top">Capability scope exceeded</td></tr><tr><td align="left" valign="top">Presented proof does not match the credential holder binding</td><td align="left" valign="top">DENY</td><td align="left" valign="top">DENY</td><td align="left" valign="top">Holder-binding mismatch</td></tr><tr><td align="left" valign="top">Presented capability is bound to a different federation envelope</td><td align="left" valign="top">DENY</td><td align="left" valign="top">DENY</td><td align="left" valign="top">Envelope mismatch</td></tr></tbody></table></table-wrap></sec><sec id="s3-2"><title>Governed Expansion From A+B to A+B+C</title><p>The A+B configuration established the initial federation with 2 existing members participating in federated training under the same governed context. Mode 1A then introduced hospital C through sponsorship, preserving the status and capabilities of hospitals A and B and leaving the Flower training and aggregation procedures unchanged. Hospital C was admitted for the submit_update operation associated with the federated-training purpose, and the corresponding admission evidence remained associated with the governed context and executed model run.</p><p>The complementary negative test preserved the asymmetric relation established for hospital C. A request to query or otherwise consume the resulting model was denied because model consumption was absent from the sponsored contributor&#x2019;s capability set. Successful contribution combined with unsuccessful model consumption provides the primary governance result for mode 1A. Federation growth occurred by adding a bounded participation relation instead of promoting hospital C to an equivalent member or transferring the capabilities of its sponsor.</p></sec><sec id="s3-3"><title>Analytical Effect of the Additional Contribution</title><p>PathMNIST model performance was measured to verify that hospital C&#x2019;s admitted contribution produced an observable analytical consequence and not a purely administrative change. The analytical comparison uses an A+B control trained under conditions matched to the A+B+C run. An earlier A+B baseline used during development is not treated as the comparative reference because its training duration differs from that of the governed-expansion experiment (<xref ref-type="table" rid="table6">Table 6</xref>).</p><table-wrap id="t6" position="float"><label>Table 6.</label><caption><p>Matched analytical comparison between A+B control and governed A+B+C expansion.</p></caption><table id="table6" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Metric</td><td align="left" valign="bottom">A+B control (%)</td><td align="left" valign="bottom">A+B+C expansion (%)</td><td align="left" valign="bottom">Change (pp)<sup><xref ref-type="table-fn" rid="table6fn1">a</xref></sup></td></tr></thead><tbody><tr><td align="left" valign="top">Cancer-related macro recall</td><td align="left" valign="top">50.2</td><td align="left" valign="top">67.4</td><td align="left" valign="top">+17.2</td></tr><tr><td align="left" valign="top">Noncancer macro recall</td><td align="left" valign="top">85.5</td><td align="left" valign="top">86.3</td><td align="left" valign="top">+0.8</td></tr><tr><td align="left" valign="top">Cancer-associated stroma recall</td><td align="left" valign="top">19.5</td><td align="left" valign="top">39.9</td><td align="left" valign="top">+20.4</td></tr><tr><td align="left" valign="top">Colorectal adenocarcinoma epithelium recall</td><td align="left" valign="top">80.9</td><td align="left" valign="top">94.9</td><td align="left" valign="top">+13.9</td></tr><tr><td align="left" valign="top">Global macro recall</td><td align="left" valign="top">76.7</td><td align="left" valign="top">81.6</td><td align="left" valign="top">+4.9</td></tr><tr><td align="left" valign="top">Overall accuracy</td><td align="left" valign="top">82.0</td><td align="left" valign="top">86.4</td><td align="left" valign="top">+4.5</td></tr></tbody></table><table-wrap-foot><fn id="table6fn1"><p><sup>a</sup>pp: percentage points.</p></fn></table-wrap-foot></table-wrap><p>Admission of hospital C increased cancer-related macro recall from 50.2% to 67.4% (+17.2 percentage points), while noncancer macro recall remained similar at 85.5% and 86.3%, respectively. Within the cancer-related classes, recall increased from 19.5% to 39.9% for cancer-associated stroma and from 80.9% to 94.9% for colorectal adenocarcinoma epithelium. Global macro recall increased from 76.7% to 81.6%, and overall accuracy from 82.0% to 86.4%.</p><p>These analytical results establish that hospital C&#x2019;s admitted contribution had an observable effect on the workload. Governance correctness is established separately through preservation of the admitted capability relations and their signed admission records. Model-performance improvement is therefore not treated as evidence that admission was correctly governed.</p></sec><sec id="s3-4"><title>AI-Agent Conformance and Rebind</title><p>Mode 1B introduces an AI agent as a computational participant with its own identity and holder-bound capabilities. A requesting participant may lack authority to consume an unrestricted source result. Direct consumption of the restricted source must remain denied to a requester lacking the corresponding source-consumption capability.</p><p>The requester is not authorized to consume the unrestricted cancer-related source result. The agent may nevertheless perform bounded inference and invoke the governed rebind operation, which converts the restricted result into a policy-authorized derivative consisting of a blurred tissue image and a qualitative indication of prediction accuracy. The requester may consume this derivative only under a separate derivative-consumption capability. The agent performs the transformation under its own admitted authority, and federation policy determines the permitted transformation. The Mode 1B scenario follows the conformance requirements summarized in <xref ref-type="table" rid="table7">Table 7</xref>, which define the required decisions across source consumption, bounded inference, policy-authorized rebind, derivative consumption, and access to privileged governance paths.</p><table-wrap id="t7" position="float"><label>Table 7.</label><caption><p>Mode 1B conformance requirements and observed decisions for bounded AI-agent participation.</p></caption><table id="table7" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Governed operation</td><td align="left" valign="bottom">Required decision</td><td align="left" valign="bottom">Observed decision</td><td align="left" valign="bottom">Governance requirement</td></tr></thead><tbody><tr><td align="left" valign="top">Requester asks for unrestricted cancer-related source output</td><td align="left" valign="top">DENY</td><td align="left" valign="top">DENY</td><td align="left" valign="top">Source-consumption capability remains absent</td></tr><tr><td align="left" valign="top">The agent performs inference within its bounded capability</td><td align="left" valign="top">ALLOW</td><td align="left" valign="top">ALLOW</td><td align="left" valign="top">Agent authority remains explicit and holder-bound</td></tr><tr><td align="left" valign="top">The agent invokes the policy-authorized rebind operation</td><td align="left" valign="top">ALLOW</td><td align="left" valign="top">ALLOW</td><td align="left" valign="top">Transformation is determined by federation policy</td></tr><tr><td align="left" valign="top">Requester consumes the derived representation under the corresponding capability relation</td><td align="left" valign="top">ALLOW</td><td align="left" valign="top">ALLOW</td><td align="left" valign="top">Derivative consumption is evaluated independently from source consumption</td></tr><tr><td align="left" valign="top">The agent attempts a privileged governance path outside the admitted execution route</td><td align="left" valign="top">DENY</td><td align="left" valign="top">DENY</td><td align="left" valign="top">Execution cannot enlarge federation authority</td></tr></tbody></table></table-wrap></sec><sec id="s3-5"><title>Admission Overhead</title><p>Admission adds cryptographic verification, capability matching, evidence signing, and evidence persistence to the request path. <xref ref-type="table" rid="table8">Table 8</xref> reports the completed request-level benchmark for the current Open Health implementation.</p><table-wrap id="t8" position="float"><label>Table 8.</label><caption><p>Server-side admission latency by decision path.</p></caption><table id="table8" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Operation</td><td align="left" valign="bottom">ALLOW<sup><xref ref-type="table-fn" rid="table8fn1">a</xref></sup>, median (IQR) ms<sup><xref ref-type="table-fn" rid="table8fn2">b</xref></sup></td><td align="left" valign="bottom">DENY-Cap<sup><xref ref-type="table-fn" rid="table8fn3">c</xref></sup>, median (IQR) ms</td><td align="left" valign="bottom">DENY-Holder<sup><xref ref-type="table-fn" rid="table8fn4">d</xref></sup>, median (IQR) ms</td></tr></thead><tbody><tr><td align="left" valign="top">ECT<sup><xref ref-type="table-fn" rid="table8fn5">e</xref></sup> verification</td><td align="left" valign="top">0.150 (0.143&#x2010;0.171)</td><td align="left" valign="top">0.148 (0.143&#x2010;0.160)</td><td align="left" valign="top">0.150 (0.144&#x2010;0.161)</td></tr><tr><td align="left" valign="top">DPoP<sup><xref ref-type="table-fn" rid="table8fn6">f</xref></sup> verification</td><td align="left" valign="top">0.112 (0.110&#x2010;0.120)</td><td align="left" valign="top">0.114 (0.111&#x2010;0.120)</td><td align="left" valign="top">0.144 (0.139&#x2010;0.151)</td></tr><tr><td align="left" valign="top">Capability match</td><td align="left" valign="top">0.0051 (0.0048&#x2010;0.0053)</td><td align="left" valign="top">0.0051 (0.0049&#x2010;0.0054)</td><td align="left" valign="top">NA<sup><xref ref-type="table-fn" rid="table8fn7">g</xref></sup></td></tr><tr><td align="left" valign="top">Full admission check</td><td align="left" valign="top">1.210 (1.141-1.333)</td><td align="left" valign="top">1.195 (1.136&#x2010;1.273)</td><td align="left" valign="top">0.884 (0.837&#x2010;0.921)</td></tr></tbody></table><table-wrap-foot><fn id="table8fn1"><p><sup>a</sup>ALLOW denotes a valid capability and holder proof.</p></fn><fn id="table8fn2"><p><sup>b</sup> Values are median (IQR) ms, from 1000 requests per case.</p></fn><fn id="table8fn3"><p><sup>c</sup>DENY-Cap denotes a capability or scope mismatch.</p></fn><fn id="table8fn4"><p><sup>d</sup>DENY-Holder denotes a holder-binding mismatch.</p></fn><fn id="table8fn5"><p><sup>e</sup>ECT: envelope capability token. </p></fn><fn id="table8fn6"><p><sup>f</sup>DPoP: demonstrating proof of possession. </p></fn><fn id="table8fn7"><p><sup>g</sup>NA indicates that capability matching was not reached because holder validation failed first.</p></fn></table-wrap-foot></table-wrap><p>Median full admission latency was 1.210 (IQR 1.141&#x2010;1.333) ms for successful admission, 1.195 (IQR 1.136&#x2010;1.273) ms for capability-scope denial, and 0.884 (IQR 0.837&#x2010;0.921) ms for holder-binding denial. ECT verification, DPoP verification, and capability matching individually remained submillisecond. Capability matching is reported as not applicable for the holder-binding denial because the request fails closed during DPoP verification and evaluation terminates before the capability-matching stage. The shorter full latency for this path is consistent with that early termination. For ALLOW, decision-evidence signing and persistence had median latencies of 0.065 (IQR 0.063-0.069) ms and 0.164 (IQR 0.159-0.172) ms, respectively, with comparable values for the denial paths.</p><p>The full admission measurement includes cryptographic verification, capability evaluation, decision-evidence signing and persistence, and the surrounding admission-gateway processing. The benchmark is intended as a deployability check rather than a throughput study and reports single-request latency under no concurrent load. The relevant systems question is whether explicit admission and signed decision evidence introduce material overhead relative to the federated activity they govern; throughput and tail latency under concurrent requests remain outside the current evaluation.</p></sec></sec><sec id="s4" sec-type="discussion"><title>Discussion</title><sec id="s4-1"><title>Principal Findings</title><p>The Open Health demonstrator supports the central proposition of the study by representing federation growth as a governed change in participation relations, with technical onboarding remaining subject to explicit governance conditions. Positive and negative admission decisions remain tied to the federation envelope and are retained as signed evidence. Mode 1B extends the same structure to computational participation by separating the agent&#x2019;s execution capability from the rights of the human participant requesting the result.</p><p>Model accuracy is a secondary outcome in the current evaluation. Under matched training conditions, cancer-related macro recall increased from 50.2% to 67.4% after hospital C&#x2019;s admitted contribution, while noncancer macro recall remained similar at 85.5% and 86.3%. This establishes an observable analytical consequence of the governed contribution but neither establishes nor measures governance correctness. The primary result is preservation of the capability relations asserted before execution, including contribution-specific capabilities, holder-bound admission, federation-context binding, and independent governance of source and derivative consumption.</p></sec><sec id="s4-2"><title>From Fixed Collaboration to Governed Federation Evolution</title><p>Many collaborative infrastructures are designed around an initially established set of organizations, resources, and analytical operations. Their technical mechanisms may scale effectively once those assumptions are fixed, yet movement from pilot to operational service can require the collaboration itself to change. Open Health addresses that transition by treating participation, resources, and operations as separable dimensions whose relations can evolve under an existing governance context.</p><p>The concept of a federated service follows from the same separation. An operational function can be exposed within the federation while remaining under the control of its provider, with the federation governing the authority, purpose, capability, scope, and context under which it may be invoked. Flower-based training and inference provide the concrete services used in the demonstrator. The governance structure is runtime-independent and can in principle accommodate other analytical or data-processing services as operational functions outside the federation&#x2019;s constitutive layer.</p></sec><sec id="s4-3"><title>Relationship to Existing Health-Data Infrastructure</title><p>Open Health is not intended to replace TREs, identity federation, IAM, RBAC, or ABAC, dataspace governance, or FL frameworks. Each addresses a different boundary. Organization-local controls remain responsible for identities, infrastructure, users, and resources within an administrative domain, while analytical runtimes remain responsible for executing admitted computation. The additional FC boundary establishes whether a participant may enter a particular federated activity under the current shared governance conditions.</p><p>The distinction becomes important when collaborations evolve asymmetrically. Conventional onboarding may be sufficient when every new organization is intended to receive the same role and operational privileges as existing members. Hospital C represents a different case because the desired relation is deliberately narrower. Sponsorship enables accountable, differentiated participation while preserving delegation and membership as separate governance relations.</p></sec><sec id="s4-4"><title>AI-Agent Participation and Governed Transformation</title><p>Mode 1B illustrates that an AI agent fits within the existing constitutive categories of the federation. The agent acts as a computational principal with its own identity, holder binding, and bounded capabilities. Its planning strategy or runtime determines how an admitted operation is executed. Runtime isolation constrains execution paths; federation authority is established through governed admission. Rebind extends this structure with an additional governed relation.</p><p>The agent may transform a restricted result into a policy-authorized derivative; the recipient&#x2019;s rights to that derivative are evaluated independently from rights to the source. The blurred representation used in the demonstrator is not treated as a differential-privacy mechanism or as an agent-defined judgment that an output is safe. Its significance lies in the governed transformation and the independent capability relation attached to subsequent consumption. The construction provides an operational connection to the earlier value-identity model, in which transformations of data and their governance bindings are considered jointly [<xref ref-type="bibr" rid="ref8">8</xref>].</p><p>The same layering limits the claim that can be made about agent safety. Admission establishes legitimate participation at a federation boundary, whereas sandboxing, tool restrictions, network isolation, monitoring, and approval mechanisms constrain behavior within the execution environment. Neither layer can substitute for the other. The Open Health result concerns conformance between federation admission and runtime execution; agent predictability lies outside the scope of the study.</p></sec><sec id="s4-5"><title>Limitations and Future Work</title><p>The demonstrator is a proof of concept implemented outside a production health-data infrastructure. PathMNIST provides a biomedical benchmark for reproducibly exercising governance relations and class-specific analytical effects. Clinical effectiveness and performance across heterogeneous operational health systems remain subjects for subsequent evaluation. The current proof of concept includes 3 participating hospitals and focuses on technical federation governance. Institutional processes required to establish real cross-organizational agreements remain outside its scope. The implementation will be ported to Amazon Web Services as part of the University College London Centre for Digital Innovation Impact Accelerator Program beginning in September 2026. The resulting cloud deployment will provide an environment for evaluating operational deployment and scaling and for verifying preservation of the governance invariants examined in this study.</p><p>The admission benchmark characterizes single-request latency in the current implementation and deployment environment under no concurrent load and does not establish throughput, tail-latency, or scale-out performance. Key rotation, revocation, recovery, long-duration policy evolution, and operational incident handling require further evaluation. History-dependent controls such as cumulative disclosure limits belong to a procedural layer beyond the per-request admission mechanism evaluated here.</p><p>Mode 1B is restricted to a deliberately bounded agent interaction, with arbitrary autonomous behavior, unrestricted tool use, and unsupervised clinical decision-making outside its scope. Further work should examine multiagent and multisponsor participation, where computational participants operate under distinct accountable sponsorship relations and interact through bounded federation capabilities, with authority remaining specific to each participant. Deployments across different analytical frameworks and health-data environments would also test whether the governance boundary remains portable when the underlying execution substrate changes.</p></sec><sec id="s4-6"><title>Conclusion</title><p>Open Health reframes the transition from federated pilot to operational service as a problem of governed federation evolution. The demonstrator separates the establishment of a federation context, expression of bounded capabilities, admission of specific participation, execution by a conventional analytical runtime, and production of signed decision evidence. Federation growth can occur through differentiated participation relations that preserve membership boundaries and bounded capability relations.</p><p>The hospital C scenario demonstrates contribution under a dedicated capability, with model consumption governed separately. The AI-agent scenario extends the same semantics to a computational participant producing a policy-authorized derivative under its own admitted capability, while recipient access remains independently governed. Together, the scenarios show how participants and operations can evolve while preserving explicit authority and capability boundaries.</p><p>The principal contribution is not a new FL algorithm or a claim of improved clinical model performance. It is a machine-evaluable admission boundary through which an existing collaboration can change while retaining auditable evidence of the conditions under which participation was allowed or denied. Such a boundary provides one route from fixed federated health-data demonstrations to services that can evolve while preserving organizational sovereignty.</p></sec></sec></body><back><ack><p>We would like to extend our heartfelt thanks to Professor Ibrahim Abubakar, Professor Nora Colton, and the University College London (UCL) Health Partnership team for their steadfast support and belief in our vision for Open Health development. Their leadership and encouragement have been fundamental to this work. We are also deeply grateful to Professor Geraint Rees and the UCL Innovation &#x0026; Enterprise teams for their financial support and commitment to technological innovation, which have been essential in advancing this project. We also thank the UCL Centre for Digital Innovation (UCL CDI), powered by Amazon Web Services (AWS), and the CDI Impact Accelerator team for their expertise, guidance, and support in accelerating the development of Open Health and strengthening its pathway towards real-world implementation and impact.</p></ack><notes><sec><title>Generative AI Use</title><p>Generative AI tools were used as interactive computational interlocutors during manuscript and software development, including counterfactual explanations, critical challenges, iterative language revision, exploratory programming, and analysis support. Generated suggestions were treated as provisional alternatives rather than authoritative outputs. Research decisions, technical design choices, verification, interpretation of results, and final manuscript content remained under the responsibility of the authors.</p></sec><sec><title>Funding</title><p>Open Health has received funding and institutional support from the University College London (UCL) Innovation &#x0026; Enterprise Knowledge Exchange Account, the UCL Health Partnerships team, and the UCL Centre for Digital Innovation (UCL CDI). We are deeply grateful for their investment in the development of Open Health and their continued support in advancing the initiative from concept towards implementation and impact.</p></sec><sec><title>Data Availability</title><p>Pathology Modified National Institute of Standards and Technology, the pathology dataset of MedMNIST v2 (a collection of standardized biomedical images modeled on the MNIST digit dataset), is publicly available [<xref ref-type="bibr" rid="ref11">11</xref>,<xref ref-type="bibr" rid="ref12">12</xref>]. A frozen, versioned archive of the implementation, study configurations, governance artifacts, tests, and generated evidence supporting the reported results is available at Zenodo [<xref ref-type="bibr" rid="ref44">44</xref>].</p></sec></notes><fn-group><fn fn-type="con"><p>Conceptualization: EF, MN, DK, PT</p><p>Data curation: EF</p><p>Formal analysis: EF</p><p>Funding acquisition: MN, PT</p><p>Investigation: EF, MS</p><p>Methodology: EF, GC</p><p>Project administration: MN, GC</p><p>Software: EF, MS</p><p>Supervision: PT, MN</p><p>Validation: EF, GC</p><p>Writing &#x2013; original draft: EF</p><p>Writing &#x2013; review &#x0026; editing: MN, GC, MS, DK, PT</p></fn><fn fn-type="conflict"><p>None declared.</p></fn></fn-group><glossary><title>Abbreviations</title><def-list><def-item><term id="abb1">ABAC</term><def><p>attribute-based access control</p></def></def-item><def-item><term id="abb2">DPoP</term><def><p>demonstrating proof-of possession</p></def></def-item><def-item><term id="abb3">ECT</term><def><p>envelope capability token</p></def></def-item><def-item><term id="abb4">EHDS</term><def><p>European Health Data Space</p></def></def-item><def-item><term id="abb5">FC</term><def><p>federated computing</p></def></def-item><def-item><term id="abb6">FCaC</term><def><p>federated computing as code</p></def></def-item><def-item><term id="abb7">FL</term><def><p>federated learning</p></def></def-item><def-item><term id="abb8">RBAC</term><def><p>role-based access control</p></def></def-item><def-item><term id="abb9">TRE</term><def><p>trusted research environment</p></def></def-item></def-list></glossary><ref-list><title>References</title><ref id="ref1"><label>1</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Rieke</surname><given-names>N</given-names> </name><name name-style="western"><surname>Hancox</surname><given-names>J</given-names> </name><name name-style="western"><surname>Li</surname><given-names>W</given-names> </name><etal/></person-group><article-title>The future of digital health with federated learning</article-title><source>NPJ Digit Med</source><year>2020</year><volume>3</volume><fpage>119</fpage><pub-id pub-id-type="doi">10.1038/s41746-020-00323-1</pub-id><pub-id pub-id-type="medline">33015372</pub-id></nlm-citation></ref><ref id="ref2"><label>2</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Kairouz</surname><given-names>P</given-names> </name><name name-style="western"><surname>McMahan</surname><given-names>HB</given-names> </name><name name-style="western"><surname>Avent</surname><given-names>B</given-names> </name></person-group><article-title>Advances and open problems in federated learning</article-title><source>Found Trends Mach Learn</source><year>2021</year><month>06</month><day>23</day><volume>14</volume><issue>1-2</issue><fpage>1</fpage><lpage>210</lpage><pub-id pub-id-type="doi">10.1561/2200000083</pub-id></nlm-citation></ref><ref id="ref3"><label>3</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Li</surname><given-names>T</given-names> </name><name name-style="western"><surname>Sahu</surname><given-names>AK</given-names> </name><name name-style="western"><surname>Talwalkar</surname><given-names>A</given-names> </name><name name-style="western"><surname>Smith</surname><given-names>V</given-names> </name></person-group><article-title>Federated learning: challenges, methods, and future directions</article-title><source>IEEE Signal Process Mag</source><year>2020</year><volume>37</volume><issue>3</issue><fpage>50</fpage><lpage>60</lpage><pub-id pub-id-type="doi">10.1109/MSP.2020.2975749</pub-id></nlm-citation></ref><ref id="ref4"><label>4</label><nlm-citation citation-type="book"><person-group person-group-type="author"><name name-style="western"><surname>Topol</surname><given-names>EJ</given-names> </name></person-group><source>Deep Medicine: How Artificial Intelligence Can Make Healthcare Human Again</source><year>2019</year><access-date>2026-10-13</access-date><edition>1</edition><publisher-name>Basic Books</publisher-name><comment><ext-link ext-link-type="uri" xlink:href="https://catalog.nlm.nih.gov/discovery/fulldisplay/alma9917337203406676/01NLM_INST:01NLM_INST">https://catalog.nlm.nih.gov/discovery/fulldisplay/alma9917337203406676/01NLM_INST:01NLM_INST</ext-link></comment><pub-id pub-id-type="other">9781541644632</pub-id></nlm-citation></ref><ref id="ref5"><label>5</label><nlm-citation citation-type="web"><person-group person-group-type="author"><name name-style="western"><surname>Gandhi</surname><given-names>A</given-names> </name><name name-style="western"><surname>McCarthy</surname><given-names>K</given-names> </name><name name-style="western"><surname>Adams</surname><given-names>F</given-names> </name></person-group><article-title>Unbound care: revolutionizing healthcare and life science with decentralized products and services</article-title><source>Gartner</source><year>2024</year><access-date>2026-10-13</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://www.gartner.com/en/documents/5257263">https://www.gartner.com/en/documents/5257263</ext-link></comment></nlm-citation></ref><ref id="ref6"><label>6</label><nlm-citation citation-type="report"><person-group person-group-type="author"><name name-style="western"><surname>Goldacre</surname><given-names>B</given-names> </name><name name-style="western"><surname>Morley</surname><given-names>J</given-names> </name></person-group><article-title>Better, broader, safer: using health data for research and analysis</article-title><year>2022</year><month>04</month><access-date>2026-10-13</access-date><publisher-name>Department of Health and Social Care</publisher-name><comment><ext-link ext-link-type="uri" xlink:href="https://assets.publishing.service.gov.uk/media/624ea0ade90e072a014d508a/goldacre-review-using-health-data-for-research-and-analysis.pdf">https://assets.publishing.service.gov.uk/media/624ea0ade90e072a014d508a/goldacre-review-using-health-data-for-research-and-analysis.pdf</ext-link></comment></nlm-citation></ref><ref id="ref7"><label>7</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Mozaffar</surname><given-names>H</given-names> </name><name name-style="western"><surname>Williams</surname><given-names>R</given-names> </name><name name-style="western"><surname>Anderson</surname><given-names>S</given-names> </name><name name-style="western"><surname>Cresswell</surname><given-names>K</given-names> </name></person-group><article-title>A system-level analysis of challenges and strategies for scaling artificial intelligence in healthcare: a qualitative study of the NHS AI lab</article-title><source>Digit Health</source><year>2026</year><volume>12</volume><fpage>20552076261464270</fpage><pub-id pub-id-type="doi">10.1177/20552076261464270</pub-id><pub-id pub-id-type="medline">42582599</pub-id></nlm-citation></ref><ref id="ref8"><label>8</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Fenoglio</surname><given-names>E</given-names> </name><name name-style="western"><surname>Treleaven</surname><given-names>P</given-names> </name></person-group><article-title>Federated computing: information integration under sovereignty constraints</article-title><source>R Soc Open Sci</source><year>2026</year><month>02</month><day>11</day><volume>13</volume><issue>2</issue><fpage>251318</fpage><pub-id pub-id-type="doi">10.1098/rsos.251318</pub-id></nlm-citation></ref><ref id="ref9"><label>9</label><nlm-citation citation-type="other"><person-group person-group-type="author"><name name-style="western"><surname>Fenoglio</surname><given-names>E</given-names> </name><name name-style="western"><surname>Treleaven</surname><given-names>P</given-names> </name></person-group><article-title>Federated computing as code (FCaC): sovereignty-aware systems by design</article-title><source>arXiv</source><comment>Preprint posted online on  Mar 18, 2026</comment><pub-id pub-id-type="doi">10.48550/arXiv.2603.17331</pub-id></nlm-citation></ref><ref id="ref10"><label>10</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Fenoglio</surname><given-names>E</given-names> </name><name name-style="western"><surname>Treleaven</surname><given-names>P</given-names> </name></person-group><article-title>Auditable session admission for cross-silo federated learning</article-title><source>2026 2nd International Conference on Federated Learning and Intelligent Computing Systems (FLICS)</source><year>2026</year><fpage>231</fpage><lpage>238</lpage><pub-id pub-id-type="doi">10.1109/FLICS70075.2026.11621917</pub-id></nlm-citation></ref><ref id="ref11"><label>11</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Yang</surname><given-names>J</given-names> </name><name name-style="western"><surname>Shi</surname><given-names>R</given-names> </name><name name-style="western"><surname>Wei</surname><given-names>D</given-names> </name><etal/></person-group><article-title>MedMNIST v2 - a large-scale lightweight benchmark for 2D and 3D biomedical image classification</article-title><source>Sci Data</source><year>2023</year><month>01</month><day>19</day><volume>10</volume><issue>1</issue><fpage>41</fpage><pub-id pub-id-type="doi">10.1038/s41597-022-01721-8</pub-id><pub-id pub-id-type="medline">36658144</pub-id></nlm-citation></ref><ref id="ref12"><label>12</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Kather</surname><given-names>JN</given-names> </name><name name-style="western"><surname>Krisam</surname><given-names>J</given-names> </name><name name-style="western"><surname>Charoentong</surname><given-names>P</given-names> </name><etal/></person-group><article-title>Predicting survival from colorectal cancer histology slides using deep learning: a retrospective multicenter study</article-title><source>PLoS Med</source><year>2019</year><month>01</month><volume>16</volume><issue>1</issue><fpage>e1002730</fpage><pub-id pub-id-type="doi">10.1371/journal.pmed.1002730</pub-id><pub-id pub-id-type="medline">30677016</pub-id></nlm-citation></ref><ref id="ref13"><label>13</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Hai</surname><given-names>R</given-names> </name><name name-style="western"><surname>Koutras</surname><given-names>C</given-names> </name><name name-style="western"><surname>Quix</surname><given-names>C</given-names> </name><name name-style="western"><surname>Jarke</surname><given-names>M</given-names> </name></person-group><article-title>Data lakes: a survey of functions and systems</article-title><source>IEEE Trans Knowl Data Eng</source><year>2023</year><volume>35</volume><issue>12</issue><fpage>12571</fpage><lpage>12590</lpage><pub-id pub-id-type="doi">10.1109/TKDE.2023.3270101</pub-id></nlm-citation></ref><ref id="ref14"><label>14</label><nlm-citation citation-type="report"><person-group person-group-type="author"><name name-style="western"><surname>Runyon</surname><given-names>B</given-names> </name></person-group><article-title>Establish interoperable application ecosystems early in your composable healthcare provider roadmap</article-title><year>2022</year><publisher-name>Gartner</publisher-name></nlm-citation></ref><ref id="ref15"><label>15</label><nlm-citation citation-type="web"><source>OpenSAFELY</source><access-date>2026-08-01</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://www.opensafely.org/">https://www.opensafely.org/</ext-link></comment></nlm-citation></ref><ref id="ref16"><label>16</label><nlm-citation citation-type="web"><source>Rhino Federated Computing</source><access-date>2026-08-01</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://www.rhinohealth.com/">https://www.rhinohealth.com/</ext-link></comment></nlm-citation></ref><ref id="ref17"><label>17</label><nlm-citation citation-type="web"><source>Syntropy</source><access-date>2026-08-02</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://www.syntropy.com/">https://www.syntropy.com/</ext-link></comment></nlm-citation></ref><ref id="ref18"><label>18</label><nlm-citation citation-type="web"><source>Mayo Clinic Platform</source><access-date>2026-08-02</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://www.mayoclinicplatform.org/">https://www.mayoclinicplatform.org/</ext-link></comment></nlm-citation></ref><ref id="ref19"><label>19</label><nlm-citation citation-type="other"><person-group person-group-type="author"><name name-style="western"><surname>Beutel</surname><given-names>DJ</given-names> </name><name name-style="western"><surname>Topal</surname><given-names>T</given-names> </name><name name-style="western"><surname>Mathur</surname><given-names>A</given-names> </name><etal/></person-group><article-title>Flower: a friendly federated learning research framework</article-title><source>arXiv</source><comment>Preprint posted online on  Jul 28, 2020</comment><pub-id pub-id-type="doi">10.48550/arXiv.2007.14390</pub-id></nlm-citation></ref><ref id="ref20"><label>20</label><nlm-citation citation-type="web"><article-title>NVIDIA / NVFlare</article-title><source>GitHub</source><access-date>2026-08-02</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://github.com/NVIDIA/NVFlare">https://github.com/NVIDIA/NVFlare</ext-link></comment></nlm-citation></ref><ref id="ref21"><label>21</label><nlm-citation citation-type="web"><article-title>securefederatedai / openfederatedlearning</article-title><source>GitHub</source><access-date>2026-08-02</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://github.com/securefederatedai/openfl">https://github.com/securefederatedai/openfl</ext-link></comment></nlm-citation></ref><ref id="ref22"><label>22</label><nlm-citation citation-type="web"><article-title>OpenMined / PySyft</article-title><source>GitHub</source><access-date>2026-08-02</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://github.com/OpenMined/PySyft">https://github.com/OpenMined/PySyft</ext-link></comment></nlm-citation></ref><ref id="ref23"><label>23</label><nlm-citation citation-type="other"><person-group person-group-type="author"><name name-style="western"><surname>Galtier</surname><given-names>MN</given-names> </name><name name-style="western"><surname>Marini</surname><given-names>C</given-names> </name></person-group><article-title>Substra: a framework for privacy-preserving, traceable and collaborative machine learning</article-title><source>arXiv</source><comment>Preprint posted online on  Oct 25, 2019</comment><pub-id pub-id-type="doi">10.48550/arXiv.1910.11567</pub-id></nlm-citation></ref><ref id="ref24"><label>24</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Brown</surname><given-names>AP</given-names> </name><name name-style="western"><surname>Randall</surname><given-names>SM</given-names> </name></person-group><article-title>Secure record linkage of large health data sets: evaluation of a hybrid cloud model</article-title><source>JMIR Med Inform</source><year>2020</year><month>09</month><day>23</day><volume>8</volume><issue>9</issue><fpage>e18920</fpage><pub-id pub-id-type="doi">10.2196/18920</pub-id><pub-id pub-id-type="medline">32965236</pub-id></nlm-citation></ref><ref id="ref25"><label>25</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Rosenau</surname><given-names>L</given-names> </name><name name-style="western"><surname>Gruendner</surname><given-names>J</given-names> </name><name name-style="western"><surname>Kiel</surname><given-names>A</given-names> </name><name name-style="western"><surname>K&#x00F6;hler</surname><given-names>T</given-names> </name><name name-style="western"><surname>Schaffer</surname><given-names>B</given-names> </name><name name-style="western"><surname>Majeed</surname><given-names>RW</given-names> </name></person-group><article-title>Bridging data models in health care with a novel intermediate query format for feasibility queries: mixed methods study</article-title><source>JMIR Med Inform</source><year>2024</year><month>10</month><day>14</day><volume>12</volume><fpage>e58541</fpage><pub-id pub-id-type="doi">10.2196/58541</pub-id><pub-id pub-id-type="medline">39401125</pub-id></nlm-citation></ref><ref id="ref26"><label>26</label><nlm-citation citation-type="web"><source>Gaia-X</source><access-date>2026-08-01</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://gaia-x.eu/">https://gaia-x.eu/</ext-link></comment></nlm-citation></ref><ref id="ref27"><label>27</label><nlm-citation citation-type="web"><article-title>European Health Data Space Regulation (EHDS)</article-title><source>European Commission</source><access-date>2026-08-01</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space_en">https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space_en</ext-link></comment></nlm-citation></ref><ref id="ref28"><label>28</label><nlm-citation citation-type="web"><article-title>Second joint action towards the European Health Data Space &#x2013; TEHDAS2</article-title><source>TEHDAS2</source><access-date>2026-08-02</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://tehdas.eu/">https://tehdas.eu/</ext-link></comment></nlm-citation></ref><ref id="ref29"><label>29</label><nlm-citation citation-type="book"><person-group person-group-type="author"><name name-style="western"><surname>Selvanathan</surname><given-names>N</given-names> </name><name name-style="western"><surname>Jayakody</surname><given-names>D</given-names> </name><name name-style="western"><surname>Damjanovic-Behrendt</surname><given-names>V</given-names> </name></person-group><article-title>Federated Identity Management and Interoperability for Heterogeneous Cloud Platform Ecosystems</article-title><source>ARES &#x2019;19: Proceedings of the 14th International Conference on Availability, Reliability and Security</source><year>2019</year><access-date>2026-10-14</access-date><publisher-name>Association for Computing Machinery</publisher-name><fpage>1</fpage><lpage>7</lpage><comment><ext-link ext-link-type="uri" xlink:href="https://dl.acm.org/doi/proceedings/10.1145/3339252">https://dl.acm.org/doi/proceedings/10.1145/3339252</ext-link></comment><pub-id pub-id-type="doi">10.1145/3339252.3341492</pub-id><pub-id pub-id-type="other">978-1-4503-7164-3</pub-id></nlm-citation></ref><ref id="ref30"><label>30</label><nlm-citation citation-type="report"><person-group person-group-type="author"><name name-style="western"><surname>Hardt</surname><given-names>D</given-names> </name></person-group><article-title>RFC 6749: The OAuth 2.0 authorization framework</article-title><year>2012</year><month>10</month><publisher-name>RFC Editor</publisher-name><pub-id pub-id-type="doi">10.17487/RFC6749</pub-id></nlm-citation></ref><ref id="ref31"><label>31</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Sandhu</surname><given-names>RS</given-names> </name><name name-style="western"><surname>Coyne</surname><given-names>EJ</given-names> </name><name name-style="western"><surname>Feinstein</surname><given-names>HL</given-names> </name><name name-style="western"><surname>Youman</surname><given-names>CE</given-names> </name></person-group><article-title>Role-based access control models</article-title><source>Computer (Long Beach Calif)</source><year>1996</year><volume>29</volume><issue>2</issue><fpage>38</fpage><lpage>47</lpage><pub-id pub-id-type="doi">10.1109/2.485845</pub-id></nlm-citation></ref><ref id="ref32"><label>32</label><nlm-citation citation-type="report"><person-group person-group-type="author"><name name-style="western"><surname>Hu</surname><given-names>V</given-names> </name><name name-style="western"><surname>Ferraiolo</surname><given-names>D</given-names> </name><name name-style="western"><surname>Kuhn</surname><given-names>R</given-names> </name><etal/></person-group><article-title>Guide to attribute based access control (ABAC) definition and considerations. NIST Special Publication 800-162</article-title><year>2014</year><month>01</month><publisher-name>National Institute of Standards and Technology</publisher-name><pub-id pub-id-type="doi">10.6028/NIST.SP.800-162</pub-id></nlm-citation></ref><ref id="ref33"><label>33</label><nlm-citation citation-type="web"><article-title>Open policy agent (OPA)</article-title><source>Open Policy Agent v1212</source><access-date>2026-08-06</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://openpolicyagent.org/docs">https://openpolicyagent.org/docs</ext-link></comment></nlm-citation></ref><ref id="ref34"><label>34</label><nlm-citation citation-type="other"><person-group person-group-type="author"><name name-style="western"><surname>Cutler</surname><given-names>JW</given-names> </name><name name-style="western"><surname>Disselkoen</surname><given-names>C</given-names> </name><name name-style="western"><surname>Eline</surname><given-names>A</given-names> </name><etal/></person-group><article-title>Cedar: a new language for expressive, fast, safe, and analyzable authorization (extended version)</article-title><source>arXiv</source><comment>Preprint posted online on  Mar 7, 2024</comment><pub-id pub-id-type="doi">10.1145/3649835</pub-id></nlm-citation></ref><ref id="ref35"><label>35</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Chuprikov</surname><given-names>P</given-names> </name><name name-style="western"><surname>Eugster</surname><given-names>P</given-names> </name><name name-style="western"><surname>Mangipudi</surname><given-names>S</given-names> </name></person-group><article-title>Security policy as code</article-title><source>IEEE Secur Priv</source><year>2025</year><volume>23</volume><issue>2</issue><fpage>23</fpage><lpage>31</lpage><pub-id pub-id-type="doi">10.1109/MSEC.2025.3535803</pub-id></nlm-citation></ref><ref id="ref36"><label>36</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Williamson</surname><given-names>EJ</given-names> </name><name name-style="western"><surname>Walker</surname><given-names>AJ</given-names> </name><name name-style="western"><surname>Bhaskaran</surname><given-names>K</given-names> </name><etal/></person-group><article-title>Factors associated with COVID-19-related death using OpenSAFELY</article-title><source>Nature</source><year>2020</year><month>08</month><volume>584</volume><issue>7821</issue><fpage>430</fpage><lpage>436</lpage><pub-id pub-id-type="doi">10.1038/s41586-020-2521-4</pub-id><pub-id pub-id-type="medline">32640463</pub-id></nlm-citation></ref><ref id="ref37"><label>37</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Kavianpour</surname><given-names>S</given-names> </name><name name-style="western"><surname>Sutherland</surname><given-names>J</given-names> </name><name name-style="western"><surname>Mansouri-Benssassi</surname><given-names>E</given-names> </name><name name-style="western"><surname>Coull</surname><given-names>N</given-names> </name><name name-style="western"><surname>Jefferson</surname><given-names>E</given-names> </name></person-group><article-title>Next-generation capabilities in trusted research environments: interview study</article-title><source>J Med Internet Res</source><year>2022</year><month>09</month><day>20</day><volume>24</volume><issue>9</issue><fpage>e33720</fpage><pub-id pub-id-type="doi">10.2196/33720</pub-id><pub-id pub-id-type="medline">36125859</pub-id></nlm-citation></ref><ref id="ref38"><label>38</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Shokri</surname><given-names>R</given-names> </name><name name-style="western"><surname>Stronati</surname><given-names>M</given-names> </name><name name-style="western"><surname>Song</surname><given-names>C</given-names> </name><name name-style="western"><surname>Shmatikov</surname><given-names>V</given-names> </name></person-group><article-title>Membership inference attacks against machine learning models</article-title><source>2017 IEEE Symposium on Security and Privacy (SP)</source><year>2017</year><month>05</month><day>22</day><fpage>3</fpage><lpage>18</lpage><pub-id pub-id-type="doi">10.1109/SP.2017.41</pub-id></nlm-citation></ref><ref id="ref39"><label>39</label><nlm-citation citation-type="book"><person-group person-group-type="author"><name name-style="western"><surname>Fredrikson</surname><given-names>M</given-names> </name><name name-style="western"><surname>Jha</surname><given-names>S</given-names> </name><name name-style="western"><surname>Ristenpart</surname><given-names>T</given-names> </name></person-group><article-title>Model inversion attacks that exploit confidence information and basic countermeasures</article-title><source>CCS &#x2019;15: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security</source><year>2015</year><access-date>2026-10-14</access-date><publisher-name>Association for Computing Machinery</publisher-name><fpage>1322</fpage><lpage>1333</lpage><comment><ext-link ext-link-type="uri" xlink:href="https://dl.acm.org/doi/proceedings/10.1145/2810103">https://dl.acm.org/doi/proceedings/10.1145/2810103</ext-link></comment><pub-id pub-id-type="doi">10.1145/2810103.2813677</pub-id><pub-id pub-id-type="other">978-1-4503-3832-5</pub-id></nlm-citation></ref><ref id="ref40"><label>40</label><nlm-citation citation-type="web"><person-group person-group-type="author"><name name-style="western"><surname>Fenoglio</surname><given-names>E</given-names> </name></person-group><article-title>What counts as an FCaC instantiation: an invariant conformance criterion for Federated Computing as Code. version 0.2</article-title><source>Zenodo</source><year>2026</year><access-date>2026-10-14</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://zenodo.org/records/21924568">https://zenodo.org/records/21924568</ext-link></comment></nlm-citation></ref><ref id="ref41"><label>41</label><nlm-citation citation-type="report"><person-group person-group-type="author"><name name-style="western"><surname>Fett</surname><given-names>D</given-names> </name><name name-style="western"><surname>Campbell</surname><given-names>B</given-names> </name><name name-style="western"><surname>Bradley</surname><given-names>J</given-names> </name><name name-style="western"><surname>Lodderstedt</surname><given-names>T</given-names> </name><name name-style="western"><surname>Jones</surname><given-names>MB</given-names> </name><name name-style="western"><surname>Waite</surname><given-names>D</given-names> </name></person-group><article-title>OAuth 2.0 Demonstrating Proof of Possession (DPoP). RFC 9449. Internet Engineering Task Force</article-title><year>2023</year><month>09</month><publisher-name>RFC 9449: OAuth 20 Demonstrating Proof of Possession (DPoP)</publisher-name><pub-id pub-id-type="doi">10.17487/RFC9449</pub-id></nlm-citation></ref><ref id="ref42"><label>42</label><nlm-citation citation-type="web"><article-title>Research and innovation</article-title><source>University College London</source><access-date>2026-09-24</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://www.ucl.ac.uk/research-innovation-services/compliance-and-assurance/research-ethics-service/do-i-need-ethical-approval/">https://www.ucl.ac.uk/research-innovation-services/compliance-and-assurance/research-ethics-service/do-i-need-ethical-approval/</ext-link></comment></nlm-citation></ref><ref id="ref43"><label>43</label><nlm-citation citation-type="report"><person-group person-group-type="author"><collab>NHS Research Scotland</collab></person-group><article-title>Does my project require review by a research ethics committee? Version 2.0</article-title><year>2020</year><access-date>2026-10-14</access-date><publisher-name>Health Research Authority</publisher-name><comment><ext-link ext-link-type="uri" xlink:href="https://www.hra-decisiontools.org.uk/ethics/docs/Algorithm%20-%20Does%20my%20project%20require%20REC%20review%20v2.0%2020200304.pdf">https://www.hra-decisiontools.org.uk/ethics/docs/Algorithm%20-%20Does%20my%20project%20require%20REC%20review%20v2.0%2020200304.pdf</ext-link></comment></nlm-citation></ref><ref id="ref44"><label>44</label><nlm-citation citation-type="web"><article-title>OpenHealth CDI: governed federated health data collaboration</article-title><source>Zenodo</source><year>2026</year><access-date>2026-10-28</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://zenodo.org/records/22209771">https://zenodo.org/records/22209771</ext-link></comment></nlm-citation></ref></ref-list></back></article>