Detailed graphical overview

The following figure provides a detailed overview of the FL-Net architecture and how it is intended to be used.

FL-Net follows a star shaped network architecture, where a central Platform coordinates multiple distributed Clients without requiring direct access to local, patient-level data. Each Client describes a Site. Both the FL-Net Platform and the FL-Net Client are protected through access and identity management by their own Keycloak instance. They also both expose APIs and services via HTTP endpoints accessed via their relative Frontend using their own NGINX for routing, TLS and additional security. FL project run communication is handled via controller services per FL-Net Client relaying messages via the Relay Server deployed on the FL-Net Platform. The FL-Net Platform uses PostgreSQL with pgvector to also store embeddings, and neo4j to store the graph structure of Schemas, ontologies and DataTypes. The FL-Net Client only requires vanilla postgreSQL data storage. Additionally, the FL-Net Platform provides the documentation as an extra service. The typical operational flow in FL-Net starts with data holders deploying their own FL-Net Client and importing data according to an existing Schema or creating a Schema describing their data. In the next step, a Data Scientist runs a DDQ to see if a sufficient amount of patient data could be used for FL. If they are satisfied with the amount, they create a FL project. This contains the information of the DDQ and which variables should be used for training, the workflow to be executed, and how the resulting model should be published. When the FL project is created, it is packed into a FL request sent to all Clients. Data holders whose client previously answered the connected DDQ can review the request. The request includes the project configuration, selected Tools, and their settings, as well as certifying audit reports provided by specific Auditors. For example, a Tool may have a up to five verified stars indicating that it has been reviewed and approved by five Auditors. Data holders can then allow the request for a subset of patients of their choosing. After at least 3 Clients approved the request, the Data Scientist may start the FL project. Any Client that didn’t yet approve the relevant request cannot join anymore now. Each participating Client is informed of the start of the project, pulling the relevant Tool and exporting the relevant data into their locally executed Tool. Finally, the aggregator of this FL project run, running on a random Client, uploads the resulting model to the FL-Net Platforms model store with appropriate access settings depending on FL project settings. In case of maximum model privacy, the final model is only distributed to the FL-Net Clients but not to the FL-Net Platform.

Refer back to the welcome page of the architecture section for the next recommended reading step.