Researcher node has jupyterlab interface.

Support for federated Grid Optimization.

Support for federated Generative Adversarial Networks (GAN).

Support for federated Variational auto-encoders (VAE).

Support for federated Diffusion models.

Support for at least one effective federated synthetic data generator learner (GAN, VAE, or DiffMod).

Support for multi-model synthetic health data (both tabular & image).

Synthetic data generation module should allow for specifying what data (images, tabular …) should be generated.

Synthetic data generation module should allow for specifying population subsets, e.g., only with cancer.

Generation of synthetic 3D MRI images.

Data owner node has functional interface with local data owner database.

Researcher node offers all features provided by TRUMPET researcher node.

Data owner node has user interface for data owner users.

Data owner node has server interfacing with other nodes.

Support for federated Logistic Regression (LR).

Support for federated Decision Trees (DT).

Support for federated Random Forests (RF).

Support for federated Support Vector Machines (SVM).

Support for federated Deep Neural Networks (DNN).

Support for federated Convolutional Neural Networks (CNN).

Support for federated Bayesian Optimization.

SD algorithm shall offer a CSV file with the required number of instances of tabular data and each column should be in the expected format (i.e., categorical, numerical etc.).

An option for users to save hyperparameters in draft and apply them at later time.

Images input and outputs will be in DICOM format.

SD algorithm shall have the ability to save a Database (DB) with current CSV file and previous CSVs files proposed.

SD shall incorporate more than one SD algorithm to perform calculations based on customer choice.

Data imputation should be considered when historical data is not available, and there is uncertainty or bad quality in the data.

SD module will have a trained machine to generate synthetic data from new repositories shared by users.

SD algorithm shall take into account that training SD generation can suppose a long waiting time.

SD shall be implemented so that future modular extensions can be added.

SD algorithm shall offer the possibility to modify some hyper-parameters and GUI shall offer a value reset option to set hyperparameters to their default value.

Synthetic data should be evaluated using various methods and tools.

Synthetic Images should be evaluated using various methods and tools including human expert validation.

Ability to create error message when error occurs.

A range of conditions can be forced for some features when synthetic tabular data is generated.

Ability to add structured data by the user.

SD algorithm shall offer a modular structure where each parameter is a module capable of being available or disable.

SD should take into account that new users will probably need to change units or convert initial data according to specified standards.

mpMRI/bpMRI shall be performed within 1 year prior to the prostate biopsy.

Reduced sample datasets with the 7 clinical variables and associated images shall be shared to generate synthetic images and algorithms.

No sensitive information shall can be revealed from exchanged messages (aggregates, models statistics, etc.) between users.

Access to local FLUTE nodes shall be Controlled/restricted.

Platform shall allow AI developers to train their models in accordance with their legal requirements and document such training.

The training requests sent to the FLUTE nodes shall specify the minimum/maximum resources needed to be executed.

The performance of the model shall be higher than the BCN1 and BCN2 models.

AI researchers shall be able to discover and select the datasets registered at each FLUTE node and obtain descriptive statistics about the datasets.

Jupyter notebooks shall be integrated with the FLUTE functionalities to ensure discoverability of the datasets.

Platform shall allow the AI researchers to search for the relevant dataset.

Platform shall provide space to add guidance documents and instructions on how to use the Platform and the datasets.

Cohorts shall consist of men with clinical suspicion of PCa based on a PSA > 3.0 ng/ml and/or abnormal DRE.

Platform shall allow authentication of authorized individuals from Data owners and Data Users and varied level of access, based on their defined roles.

Platform shall keep record of Data Users and Data owners and logs details of their activity in the Platform.

Platform shall ensure that the training data remains on the federated node and any processing, analysis and AI training is performed there. Data User shall not see, directly access or download the data, i.e. the AI model shall only be trained in the local node.

There shall be a security check of the uploaded AI model prior to its deployment in the FLUTE data.

AI models BCN1/BCN2 trained through the platform shall be packaged into software components and deployed at the clinical sites involved in validation activities.

The platform SHALL be able to generate synthetic data for mpMRI, bpMRI and tabular data for BCN1 and BCN2 case series.

The platform SHALL be able to train BCN1 and BCN2 models from an augmented/balanced datasets thanks to synthetic data.

Lesions detected in mpMRI/bpMRI shall have to be reported using the Prostate Imaging-Report and Data System (PI-RADS) in version 2.0 or higher.

Prostate biopsies shall be systematic and targeted in cases of PI-RADS ≥3 lesions.

The platform shall define the methodology to extract/load/transform data from clinical databases and data warehouse into the FLUTE data node.

Input data shall be anonymized or pseudonymized.

Clinical data and MRI (both raw and processed) shall be linked.

MRI imaging study shall comply with specific requirements of QP-Prostate tool provided for FLUTE project.

Data shall be labelled with class csPCa 0 or 1.

Platform should provide secure methods to access the system like multi-factor authentication.

FLUTE platform should allow the user to select whether the central aggregator has clear access to the local models.

Access to different platform features should be role-based.

User sessions should time out after a period of inactivity.

FLUTE platform should allow to select which protection techniques are using in a training.

Local training algorithms should be run in the data owner infrastructure.

Local trained models should be sent to aggregator using TLS.

Data owners should be able to select which fields of their data sets can be used for model training.

FLUTE platform should log every use of the data.

FLUTE platform should initiate a local training when the data owner provides consent to use the data to that study.

The FLUTE project SHOULD use the HL7 FHIR standard whenever possible.

The FLUTE project SHOULD explore the possibility to model AI models using the HL7 standards FHIR and/or CQL.

The FLUTE project SHOULD use SNOMED CT, LOINC and UCUM terminologies whenever possible.

The FLUTE project SHOULD use DICOMweb (DICOM) for imaging evidences.

A conceptual/logical model of the data that has to be exchanged SHALL be specified.

Privacy Policies SHOULD be modelled and exchanged using the HL7 FHIR standard.

Permission to access healthcare Data SHOULD be modelled and exchanged using the HL7 FHIR Permission resource.

The prediction of whether a biopsy is need SHOULD be modelled and exchanged using the HL7 FHIR standard.

The FHIR exchange capabilities of each system SHALL be modelled and exchanged using the HL7 FHIR CapabilityStatement resource.

Each Hospital SHALL expose its non-imaging data using the HL7 FHIR standard.

All output preserves privacy.

All algorithm implementations should follow the platform guidelines (adopted & revised from TRUMPET), e.g., on privacy/security parameters.

SD algorithm shall take into account that training SD generation can suppose a long waiting time.

SD shall be implemented so that future modular extensions can be added.

Synthetic data maintains data privacy and cannot correlate to patient data.

Synthetic data used in combination with real data (data augmentation) improves the prediction performance of the algorithms trained using only real data.

SD GUI shall be able to run several queries simultaneously to reduce total time.

A user manual and helping description must be provided.

SD GUI shall incorporate an internal counter which will be in charge of recording the amount of use the customer is making to allow a possible pay per use subscription method.

Units shall be harmonized.

Platform shall monitor the use of the data in the Platform, to detect potential misuse. It shall implement measures for detection of data breaches and potential privacy threats/leaks.

Platform shall ensure that the pseudonymized data can be amended or withdrawn after its sharing, if the data subject (patient) requests the modification.

A common (FHIR) data model shall be defined to represent the clinical data used in the study.

The platform shall provide validators that check whether the clinical data pushed to the local node complies with the common data model.

The data shall be standardized to a common (FHIR) data model before ingestion into the FLUTE local node.

Cryptographic methods like homomorphic encryption and differential privacy shall be used to aggregate statistics about the cohort without disclosing (leaking) sensitive data outside the local node.

Platform shall keep and display FLUTE data catalogue with defined basic metadata that characterizes the datasets available through the FLUTE Platform.

Platform shall display terms and conditions of use (T&C) and Privacy policy.

Platform shall display the conditions of the use of each of the datasets, as specified by its owner or the data hub.

Datasets which are not defined as open to all users of the platform, shall only be available to uses which request access to the dataset and are permitted to use it by the data owner or data hub.

Platform should have password policies.

FLUTE Platform should implement several PETs to protect data privacy.

Administrators of FLUTE platform should keep the systems up-to-date and patched.

There should be security policies to avoid the use of potentially vulnerable software.

FLUTE Platform should guarantee data is not tampered with in training processes.

The definition of the different actors of the platform SHOULD be modelled and exchanged using the HL7 FHIR ActorDefinition resource.

The definition of the different requirements of the platform SHOULD be modelled and exchanged using the HL7 FHIR Requirement resource.

The example scenarios of the platform usage SHOULD be modelled and exchanged using the HL7 FHIR ExampleScenario resource.

The testing of the different requirements of the platform SHOULD be modelled and exchanged using the HL7 FHIR TestScript, TestPlan and TestReport resource.

Data should never leave data owner infrastructure.

All the federated learning processes should be logged to be able to conduct an audit in case of a security incident.

The system should provide consent management mechanisms.

The exchange of data between data owner nodes and central aggregator should follow the principle of data minimization. Only sharing the necessary data to be able to train models effectively.

FLUTE platform should be compliant with regulations.

FLUTE platform should provide privacy in a semi-honest threat model (honest but curious parties).

FLUTE platform should provide privacy in a threat model with malicious parties.

Central aggregation of models should not leak any information of the data used to train local models.

Access to the platform should be protected by a secure login with multi-factor authentication.

Communication between system nodes should be encrypted.

Personal and sensitive data should not be used in the model training. In case it is required it should be properly protected, for example, with anonymization.

Users whose data is part in the training of a model should be protected to data reconstruction attacks.

Users whose data is part in the training of a model should be protected to membership inference attacks.

Users whose data is part if the training of a model should be protected to property inference attacks.

Devices used in the Federated Learning process must be secure, regularly patched and protected against malware and other vulnerabilities.