Part I - End-to-end Model Development and Deployment
Part II - Active Learning
Part III - Federated Learning
# MAIA-AIDA Technical Days Workshop Simone Bendazzoli (KTH Royal Institute of Technology, Sweden and Karolinska Institutet, Sweden) **17 September 2025** --- - [Introduction to MAIA](#introduction-to-maia) - [Why MAIA?](#why-maia) - [Learn more about MAIA](#learn-more-about-maia) - [MAIA in 5 minutes](#maia-in-5-minutes) - [User Registration](#user-registration) - [MAIA Dashboard Overview](#maia-dashboard-overview) - [Connect VSCode to your running MAIA Workspace](#connect-vscode-to-your-running-maia-workspace) - [Part 1: End-to-End Model Development and Deployment Workflow](#part-1-end-to-end-model-development-and-deployment-workflow) - [Overview](#overview) - [Prerequisites](#prerequisites) - [1.1 DICOM Transfer to Orthanc](#11-dicom-transfer-to-orthanc) - [1.1.2 DICOM Manual Annotation \[Optional\]](#112-dicom-manual-annotation-optional) - [1.2 DICOM to NIFTI Conversion](#12-dicom-to-nifti-conversion) - [1.3 Data Preparation and Preprocessing for Image Segmentation with nnUNet](#13-data-preparation-and-preprocessing-for-image-segmentation-with-nnunet) - [1.4 Model Training and Validation with nnUNet (Locally)](#14-model-training-and-validation-with-nnunet-locally) - [1.5 Model Training and Validation with nnUNet \[HPC\]](#15-model-training-and-validation-with-nnunet-hpc) - [1.6 Model Packaging](#16-model-packaging) - [1.7 Model Deployment and Inference](#17-model-deployment-and-inference) - [Part 2: Active Learning with MONAI Label](#part-2-active-learning-with-monai-label) - [Active Learning Cycle](#active-learning-cycle) - [Active Learning with 3D Slicer and MONAI Label](#active-learning-with-3d-slicer-and-monai-label) - [Starting the Active Learning Loop](#starting-the-active-learning-loop) - [Training from Scratch](#training-from-scratch) - [Part 3: Federated Learning with NVFlare](#part-3-federated-learning-with-nvflare) - [Introduction to Federated Learning](#introduction-to-federated-learning) - [NVFlare Overview](#nvflare-overview) - [Brain Tumor Segmentation with Federated Learning for Enhanced Generalizability](#brain-tumor-segmentation-with-federated-learning-for-enhanced-generalizability) - [Lymphoma Segmentation with Federated Learning for Enhanced Generalizability](#lymphoma-segmentation-with-federated-learning-for-enhanced-generalizability) - [Setting Up NVFlare with MAIA](#setting-up-nvflare-with-maia) - [Start the Server](#start-the-server) - [Start the Clients](#start-the-clients) - [Access the Federation](#access-the-federation) - [Tutorial: Spleen Segmentation with Federated Learning](#tutorial-spleen-segmentation-with-federated-learning) - [Final Considerations](#final-considerations) - [What’s Next](#whats-next) --- ## Introduction to MAIA ### Why MAIA?
Artificial Intelligence in healthcare is advancing rapidly, with the potential to transform medical imaging, diagnostics, and patient care. Yet, one of the biggest challenges remains: the gap between **AI research** and its **real-world clinical application**. **MAIA** was created to **bridge this gap**. It is an open-source platform designed to bring together **AI researchers and radiologists in the same collaborative space**. By doing so, MAIA promotes direct interaction between those developing algorithms and the professionals who apply them in clinical practice. This approach enables: - **Direct integration of AI into healthcare workflows** - **Faster translation of ideas into prototypes** and then into clinical testing - **Iterative improvement of AI models**, guided by real feedback from clinicians - **Cross-disciplinary collaboration**, ensuring innovations are grounded in clinical reality In short, MAIA is more than just a technical workspace, it is a **collaborative environment** where ideas can grow from **concept to deployment**. By promoting open collaboration, MAIA empowers the medical AI community to accelerate research, validate models in clinical contexts, and bring truly impactful innovations closer to patient care. --- ### Learn more about MAIA
--- ### MAIA in 5 minutes MAIA is a collaborative platform designed to manage Medical AI research efficiently and at scale. It brings together state-of-the-art, standards-based tools to cover every stage of the AI lifecycle in the medical domain, from data management and annotation to model training, deployment, and evaluation. Multiple projects can be independently hosted within MAIA, and each user can participate in one or more projects. Built as a federation of clusters, MAIA allows physically independent computing infrastructures to be unified under one platform, abstracting away the complexity so researchers can focus on collaboration and innovation without worrying about the underlying systems.
--- #### MAIA Projects Each **MAIA Project** is provisioned with a dedicated *MAIA Namespace*, which serves as a container for all the applications required to develop, deploy, and curate medical images along with their corresponding AI models. - **Medical Images**: Managed through *Orthanc*, which acts as the project’s DICOM server and entry point for storing and accessing imaging data. - **Model Development & Scientific Computing**: Provided via the *MAIA Workspace* inside the namespace, giving users isolated or shared environments. Entrypoints to the workspace include: - Remote Desktop - Jupyter Interface - SSH Connection
--- ### User Registration To register in the MAIA Project, created for the MAIA Workshop, and getting access to the resources, please follow these steps: 1. Visit the [MAIA Project Registration Page](https://maia.app.cloud.cbh.kth.se/maia/register/). 2. Fill out the registration form with the required information. Under "Existing Project", select "**aida-workshop**". 3. Submit the form and check your email for a confirmation message. 4. Follow the instructions in the email to complete your registration. Once registered, you will have access to all workshop materials and resources.
--- ### MAIA Dashboard Overview After logging in, you will be directed to the MAIA Dashboard. Here, you can have an overview of the MAIA Cluster resources, including information about the status of each cluster and node. On the side, there is a navigation bar that allows you to access the different project pages you are assigned to. By clicking on a project name, you can switch between different projects and access their specific resources and tools. --- #### MAIA Project Page The MAIA Project page is structured in four main sections: 1. **MAIA Apps**: A collection of applications and tools available for use within the project.
2. **Remote Desktops**: This section provides a table listing each project user, along with a direct link to their Remote Desktop interface for accessing the MAIA Workspace. It also includes the corresponding SSH command for connecting to the MAIA Workspace.
3. **MONAI Label Models**: A list of available models, deployed for integration in inference pipelines (MAIA Segmentation Portal, PACS Integration through XNAT or Orthanc), and Active Learning
4. **Orthanc DICOM Web**: A list of available Orthanc instances for the project, including a reference to the DICOMWeb and the DICOM C-GET and C-STORE endpoints.
5. **NVFlare Dashboard**: An optional section that appears if the project has NVFlare enabled, providing a link to the NVFlare Dashboard for managing federated learning projects.
--- ### Connect VSCode to your running MAIA Workspace You can connect VSCode (or any other IDE through SSH), by following these steps: 1. Upload a new or an existing SSH key following the instructions on the [MAIA Welcome](https://github.com/kthcloud/MAIA/blob/master/docker/MAIA-Workspace/Welcome.ipynb) page in your MAIA Workspace (`/home/maia-user/Welcome.ipynb`), either from the Jupyter interface or the Remote Desktop 2. Retrieve the SSH command to execute either from the same [MAIA Welcome](https://github.com/kthcloud/MAIA/blob/master/docker/MAIA-Workspace/Welcome.ipynb) page or from the MAIA Dashboard, under the **Remote Desktops** table. --- ## Part 1: End-to-End Model Development and Deployment Workflow ### Overview This section outlines a complete, day-by-day workflow for developing, training, and deploying a medical imaging AI model. The process begins with DICOM data transfer and manual annotation, continues through dataset conversion, preprocessing, and model training, and concludes with packaging, deployment, and inference on both NIfTI and DICOM inputs. By the end of this sequence, you will have built and deployed a model that is fully integrated into a clinical-style pipeline. --- ### Prerequisites You will need a DICOM dataset to upload into MAIA. - To download a sample dataset, visit the [Decathlon Challenge](http://medicaldecathlon.com/) website or follow the instructions in [Kubeflow - Download Dataset from Decathlon Challenge](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/Kubeflow.ipynb#Download-Spleen-Decathlon-Dataset). - Since the dataset is provided in NIfTI format, you will need to convert it to DICOM. Follow the steps in [Kubeflow - Convert NIfTI to DICOM](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/Kubeflow.ipynb#Convert-NIFTI-to-DICOM). For convenience, an example DICOM dataset with 5 abdominal CT scans (converted from the Task09-Spleen Decathlon dataset) is available here: [MinIO - DICOM Spleen Dataset](https://aida-workshop.maia-small.cloud.cbh.kth.se/minio-console/api/v1/download-shared-object/aHR0cDovL21pbmlvLmFpZGEtd29ya3Nob3Auc3ZjLmNsdXN0ZXIubG9jYWwvc3BsZWVuL1NwbGVlbl9ESUNPTS56aXA_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD0xUjk1TklBNVlaMDJGQUQ4Nzk1TyUyRjIwMjUwOTE2JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDkxNlQxNDA5MDhaJlgtQW16LUV4cGlyZXM9NjA0Nzk5JlgtQW16LVNlY3VyaXR5LVRva2VuPWV5SmhiR2NpT2lKSVV6VXhNaUlzSW5SNWNDSTZJa3BYVkNKOS5leUpoWTJObGMzTkxaWGtpT2lJeFVqazFUa2xCTlZsYU1ESkdRVVE0TnprMVR5SXNJbUZqY2lJNklqRWlMQ0poZEY5b1lYTm9Jam9pTFU1TGRGRjVTVXhoTVZFNWEwMVpiRk55VW1kT1VTSXNJbUYxWkNJNkltMWhhV0VpTENKaGRYUm9YM1JwYldVaU9qRTNOVGd3TXpFM05ERXNJbUY2Y0NJNkltMWhhV0VpTENKbGJXRnBiQ0k2SW5OcGJXSmxia0JyZEdndWMyVWlMQ0psYldGcGJGOTJaWEpwWm1sbFpDSTZkSEoxWlN3aVpYaHdJam94TnpVNE5qTTJOVFF5TENKbVlXMXBiSGxmYm1GdFpTSTZJa0psYm1SaGVucHZiR2tpTENKbmFYWmxibDl1WVcxbElqb2lVMmx0YjI1bElpd2laM0p2ZFhCeklqb2lUVUZKUVRwaGFXUmhMWGR2Y210emFHOXdJaXdpYVdGMElqb3hOelU0TURNeE56UXlMQ0pwYzNNaU9pSm9kSFJ3Y3pvdkwybGhiUzVqYkc5MVpDNWpZbWd1YTNSb0xuTmxMM0psWVd4dGN5OWpiRzkxWkNJc0ltcDBhU0k2SWpGa056Rm1OVFF3TFRBMlpUVXRORGM0TWkxaVpUTXhMV1pqWWpka05tTXpPV05tWXlJc0ltNWhiV1VpT2lKVGFXMXZibVVnUW1WdVpHRjZlbTlzYVNJc0luQnlaV1psY25KbFpGOTFjMlZ5Ym1GdFpTSTZJbk5wYldKbGJrQnJkR2d1YzJVaUxDSnphV1FpT2lKalpHWmhNMlJtTmkwd01UbGxMVFJpWmpjdFltUTFOeTAzTTJSa1pEWmtZemcxWldZaUxDSnpkV0lpT2lJM1kyRTRNREF3T0MxaU5XVm1MVFJoWWpNdFlqSTFaaTFpWldRNFpEUm1aVFJqWm1NaUxDSjBlWEFpT2lKSlJDSjkuUVlCd2d0ZEFnNlRDTGpQMElqMTBFNGtVTXVnY3lyZTA3dWVYT3R6blg3ZjBCRmpnQkJ5YTQ1WlozZHgxeXppXzJsYVlucXpMbld6RTNKUGx1X2Z1NmcmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnZlcnNpb25JZD1udWxsJlgtQW16LVNpZ25hdHVyZT0wOWE0N2RkZWY1NTk0ZmM5MGQzN2E5NDkyMDNlZmUyODNlNWViYjgzNWQ1ZTU5NjY5YjA4NjRiYmI5NTYxYWQ1) --- ### 1.1 DICOM Transfer to Orthanc
The first step in the AI lifecycle is transferring the DICOM dataset to a MAIA project, making it accessible for subsequent processing and model training. In MAIA, *Orthanc* serves as the entry point for sharing DICOM files within a project. Orthanc supports three methods for transferring DICOM files: - **DICOMWeb** - **DICOM C-STORE** - **Orthanc Web Interface** For DICOMWeb and C-STORE, you can find the relevant links (for DICOMWeb) and commands (for C-STORE) in the MAIA Dashboard under the **Orthanc DICOM Web** table. When using C-STORE, ensure your calling AE title follows the pattern specified in the Orthanc link, e.g., `aida-workshop.maia.se/orthanc-
`. Alternatively, the AE Title can also be found in the **Modalities** section of the Orthanc Web interface. As a third option, files can be uploaded directly via drag-and-drop using the Orthanc Web UI. Once uploaded, the DICOM files can be accessed, inspected, and visualized through the Orthanc instance along with its integrated OHIF viewer. --- ### 1.1.2 DICOM Manual Annotation [Optional] For supervised tasks, both the medical images and their corresponding annotated masks are required for the model to learn the desired task. Existing segmentation masks can be uploaded as DICOM SEG files using the same procedure as for the images through Orthanc. Alternatively, masks can be manually annotated using any of the tools available in MAIA: - **OHIF Viewer Annotation Tools** - **3D Slicer in the MAIA Workspace**: Link 3D Slicer to Orthanc as a DICOM server, download the images into Slicer, and upload the annotated masks. Upload can be done using either DICOMWeb or DICOM C-STORE protocols. The main advantage of using tools like 3D Slicer in the MAIA Workspace or the OHIF interface is that both the workspace and Orthanc are within the same internal network. This allows communication with Orthanc via its internal IP, e.g., `aida-workshop-orthanc-svc-orthanc:4242`, ensuring that the data never leave the platform and remain fully secure. --- ### 1.2 DICOM to NIFTI Conversion
Most deep learning frameworks for medical image processing perform better with NIFTI images, where each case is stored as a single 3D volume along with its corresponding annotation mask, rather than using the native DICOM format. Therefore, it is necessary to export DICOM images and their associated DICOM SEG annotations into NIFTI format within the MAIA Workspace, ensuring the dataset is ready for downstream model training tasks. A Kubeflow Pipeline is available in MAIA to handle the DICOM-to-NIFTI conversion [DICOM-to-NIFTI_pipeline.yaml](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/KubeFlow/Pipelines/DICOM_to_NIFTI_pipeline.yaml). To run it, specify the DICOM WEB url and the output directory for the NIFTI files: ```yaml studies:
output_folder: /mnt/Data/NIFTI/Task09_Spleen ``` After the successful execution of the Pipeline, you will find the NIFTI converted dataset under `output_folder`. --- ### 1.3 Data Preparation and Preprocessing for Image Segmentation with nnUNet In this tutorial, we will use the **Spleen Dataset** to build a model for automatic spleen segmentation in CT images. The process will rely on the **MONet Bundle**, which provides an end-to-end workflow for model development, training, and packaging for deployment. The MONet Bundle is specifically designed to integrate the state-of-the-art **nnUNet** framework—the benchmark for medical image segmentation—within the MONet ecosystem, enabling seamless support for deployment, active learning, and federated learning. Currently, the MONet Bundle is being developed with the aim of integrating within the MONAI ecosystem, with an ongoing effort to contribute it to the MONAI Bundle repository. Starting from version 1.5.0, MONAI is integrating the MONet Bundle basic functionalities, for more details, please refer to the [MONAI 1.5.0 Docs](https://docs.monai.io/en/stable/apps.html#nnunet-bundle) Using the MONet Bundle is highly convenient, as it allows researchers to implement a complete, automated pipeline for bringing advanced segmentation models into clinical workflows. To get started, only a configuration file is required, where details about the dataset, training parameters, and task specifications are defined. ```yaml data_dir: "/mnt/Data/Task09_Spleen" # Location of the dataset directory nnunet_root_dir: "/mnt/Data/nnUNet" # Location where to create and populate the nnUNet directory dataset_name_or_id: "09" # A unique identifier for the task dataset_format: "subfolders" # The dataset directory format. Can be decathlon or subfolders modality_dict: # Dictionary for identifying modalities and segmentation files from the suffix and extension image: ".nii.gz" label: ".nii.gz" output_data_dir: "/mnt/Data/Task09_Spleen" experiment_name: "Task09_Spleen_CIFS" # Experiment name to use in MLflow concat_modalities_flag: false # Flag to configure modality concatenation in 4D volume. Only valid if the dataset has multimodal images. labels: # Segmentation labels, including the background background: 0 Spleen: 1 label_dict: Spleen: 1 bundle_config: bundle_root: "/mnt/Data/MONet_Bundle/Task09/MONetBundle" # Where to save the MONet Bundle tracking_uri: "https://mlflow.fed-lymphoma.maia-small.se" # MLflow tracking server URI mlflow_run_name: "run_fold_0" # MLflow run name continue_training: true # Flag to continue training from a checkpoint [OPTIONAL] run_validation_only: false # Flag to run only the validation step at the end of training [OPTIONAL] ``` To run the Data Preparation and Preprocessing step, we create the corresponding Configuration file for our task: ```bash mkdir -p /home/maia-user/shared/configs cat <
/home/maia-user/shared/configs/Task09_Spleen_config.yaml data_dir: /mnt/Data/NIFTI/Task09_Spleen nnunet_root_dir: /mnt/Data/nnUNet dataset_name_or_id: "09" dataset_format: "subfolders" modality_dict: image: "_image.nii.gz" label: "_label.nii.gz" output_data_dir: /mnt/Data/NIFTI/Task09_Spleen experiment_name: "Task09_Spleen" concat_modalities_flag: false labels: background: 0 Spleen: 1 label_dict: Spleen: 1 bundle_config: bundle_root: "/mnt/Data/MONet_Bundle/Task09/MONetBundle" tracking_uri: "https://aida-workshop.maia-small.cloud.cbh.kth.se/mlflow" mlflow_run_name: "nnUNet" EOF ``` And then we can run the KubeFlow pipeline for this step, [MONet-Pipeline-Plan-and-Preprocess](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/KubeFlow/Pipelines/MONet_pipeline_Plan_and_Preprocess.yaml), specifying where to locate the configuration file: ```yaml config_file_path: configs/Task09_Spleen_config.yaml ``` --- ### 1.4 Model Training and Validation with nnUNet (Locally) After completing data preparation and preprocessing, the dataset is ready for model training. The MAIA Workspace provides a complete Python environment with **Conda support**, so you can install any required packages for your experiments. You can train models using any framework, but this tutorial will focus on **nnUNet training with the MONet Bundle**. --- #### Features of the MAIA Workspace - **Full Python environment** with Conda - **SSH access** to run training scripts from your local machine (e.g., using VSCode or another IDE) - **GPU support** for faster training times --- #### Training with the MONet Bundle As with data preparation and preprocessing, we will use the **MONet Bundle** to streamline the training and validation process. The MONet Bundle includes: - Data loading and augmentation - Model architecture definition (nnUNet) - Training loops and tracking We will reuse the same configuration file created during the data preparation step, which contains all necessary parameters for training. To launch the training step, run the **KubeFlow pipeline**: [MONet-Pipeline-Train](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/KubeFlow/Pipelines/MONet_pipeline_Train.yaml) Specify the configuration file location: ```yaml config_file_path: configs/Task09_Spleen_config.yaml ``` --- #### MLFlow Integration When training with the MONet Bundle, all runs are automatically tracked in [**MLFlow**](https://aida-workshop.maia-small.cloud.cbh.kth.se/mlflow), including: - Training metrics - Hyperparameters - Model artifacts This enables: - Easy monitoring of training progress - Comparison between different runs - Visualization of training curves and logs - Identification and debugging of potential issues --- #### Validation Once training is complete, validation can be performed on the **validation split** to evaluate model performance. The MONet Bundle supports: - Generating predictions with the trained model - Logging validation metrics (e.g., **Dice Score**, **Average Surface Distance**, **Hausdorff Distance 95**) into MLFlow To run validation, use the following KubeFlow pipeline: [MONet-Pipeline-Validation](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/KubeFlow/Pipelines/MONet_pipeline_Validation.yaml) Specify the configuration file location: ```yaml config_file_path: configs/Task09_Spleen_config.yaml ``` --- #### Visualization with DTale After validation, results can be explored with [**DTale**](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/DTale.ipynb). ##### [DTale link](https://kubeflow.maia-small.se/notebook/aida-workshop/simben-40kth-2ese/proxy/40000/dtale/main/1) DTale provides: - A user-friendly interface for analyzing validation results - Interactive plots and charts - Support for generating visual reports of model performance This makes it easy to **analyze, report, and compare** model outcomes for further research and refinement. --- ### 1.5 Model Training and Validation with nnUNet [HPC]
One of the biggest features when using **MAIA** is its capability to integrate with external HPC clusters through the **MAIA-HPC interface**. This allows you to scale up the training process by leveraging multiple GPUs and larger compute resources. For example, you can move from training on a single GPU to training on **8 GPUs in parallel** (as available in the PDC cluster). Detailed setup instructions can be found in: 👉 [MAIA-HPC/README.md](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/MAIA-HPC/README.md) --- #### Running Jobs on HPC Once configured, you are ready to: 1. Launch training jobs on the HPC cluster directly from the **MAIA Workspace** 2. Retrieve the trained models back to MAIA for packaging and deployment --- #### Requirements For running this tutorial on the HPC cluster, you need: - A **Singularity container** with: - PyTorch `2.4.0` (with CUDA support) - Required packages listed in [MAIA-HPC/requirements.txt](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/MAIA-HPC/requirements.txt) --- #### Data and Bundle Transfer The first step is to transfer the **MONet Bundle** and the **Dataset** to the HPC cluster. This can be done via: - `sftp` command - Remote Desktop integration - Or the provided Python script: [SFTP transfer](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/KubeFlow/Scripts/SFTP_Pipeline.py) --- #### Executing Jobs from MAIA-HPC You can execute jobs directly from the MAIA-HPC interface. To run the interface: ```bash export BOKEH_ALLOW_WS_ORIGIN=kubeflow.maia-small.se export HPC_ID=pdc panel serve --dev HPC.ipynb --port 5006 ``` And then access it via: [MAIA-HPC](https://kubeflow.maia-small.se/notebook/aida-workshop/simben-40kth-2ese/proxy/5006/HPC) --- #### Multi-GPU Training Remember to adjust the **batch size** to match the number of GPUs: - If the original batch size is `2` on a single GPU - With **8 GPUs**, the batch size should be increased to `16` The underlying training routine calls the same **MONet Bundle** training script, but executed through **PyTorch Lightning DDP**, which handles multi-GPU distribution automatically. --- #### Training Speedup Training time differences can be significant: - On a **single GPU**, training the spleen dataset may take ~2 days - On **8 GPUs**, the same training can be reduced to ~8 hours #### Interactive Jupyter Sessions on HPC If you prefer to run an **interactive Jupyter session** on the HPC, you can replace the experiment command with: ```bash jupyter lab --ip 0.0.0.0 --port 8888 --no-browser --allow-root \ --NotebookApp.token='' --NotebookApp.password='' --notebook-dir $ROOT_DIR ``` Then, create an SSH tunnel from your local machine: ```bash ssh -L 8889:
:8888
``` Finally, open your browser inside the MAIA Workspace at: 👉 [http://localhost:8889](http://localhost:8889) --- #### Retrieving the Trained Model Once training is complete, you can retrieve the trained model back to **MAIA** for validation (as in the local training section). For transferring the model, use one of the following: - `sftp` - Remote Desktop integration - Python script: [SFTP transfer](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/KubeFlow/Scripts/SFTP_Pipeline.py) --- #### Converting the Checkpoint Before validation, convert the **PyTorch Lightning checkpoint** into a standard **PyTorch model** compatible with the MONet Bundle. We provide a KubeFlow pipeline for this step: 👉 [MONet-Pipeline-Convert-CKPT-to-PT](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/KubeFlow/Pipelines/MONet_pipeline_Convert_CKPT_to_PT.yaml) Specify the configuration file location: ```yaml config_file_path: configs/Task09_Spleen_config.yaml ``` --- #### Running Validation After conversion, you can run the validation step. To generate predictions, modify the configuration file (`/home/maia-user/shared/configs/Task09_Spleen_config.yaml`) by setting: ```yaml run_validation_only: true ``` Then: 1. Execute the **KubeFlow training pipeline** (with the above flag enabled) 2. Execute the **KubeFlow validation pipeline** (as described in the local training section) --- #### Visualization with DTale Finally, visualize the results with **DTale**, as described in the local training section. DTale provides interactive plots and metrics exploration for evaluating model performance. ##### [DTale link](https://kubeflow.maia-small.se/notebook/aida-workshop/simben-40kth-2ese/proxy/40000/dtale/main/1) --- ### 1.6 Model Packaging Once a model has been trained and validated, the next step is to make it shareable for external use—either with collaborators or within pipelines that require automatic predictions for specific tasks, such as organ or tumor segmentation. This is achieved through **model packaging**, which means bundling the model together with all the necessary metadata, configuration files, and usage instructions. The goal is to provide a standardized, standalone package that can be easily integrated into different systems with minimal effort. Proper packaging ensures that the model can be deployed in clinical workflows quickly and efficiently, allowing users to obtain results within seconds with minimal intervention. #### Packaging nnUNet with MONAI Bundle In this tutorial, we will package the trained **nnUNet** model using the **MONAI Bundle** concept. The MONAI Bundle is a framework designed to simplify the packaging and deployment of medical imaging models. It ensures compliance with industry standards while making models easier to share, reuse, and integrate into different workflows. For more details, see the [MONAI Bundle documentation](https://docs.monai.io/en/stable/bundle_intro.html). --- #### Step 1: Create a Metadata File The first step is to create a metadata file (`.json`) that describes the model, its intended use, and other relevant information. This file serves as a standardized descriptor, making the model easier to understand and deploy. Below is an example of a metadata file for a **spleen segmentation** model trained with **nnUNet**: ```json { "schema": "https://github.com/Project-MONAI/MONAI-extra-test-data/releases/download/0.8.1/meta_schema_20220324.json", "version": "0.1.0", "changelog": { "0.1.0": "Initial release" }, "monai_version": "1.4.0", "pytorch_version": "2.3.0", "numpy_version": "1.21.2", "required_packages_version": {"nnunetv2": "2.6.0"}, "task": "Decathlon spleen segmentation with nnUNet", "description": "A pre-trained nnUNet model for volumetric (3D) segmentation of the spleen from CT image", "authors": "Simone Bendazzoli", "copyright": "Copyright (c) MONAI Consortium", "data_source": "Task09_Spleen.tar from http://medicaldecathlon.com/", "data_type": "nifti", "image_classes": "single channel data, intensity scaled to [0, 1]", "label_classes": "single channel data, 1 is spleen, 0 is everything else", "pred_classes": "2 channels OneHot data, channel 1 is spleen, channel 0 is background", "eval_metrics": { "mean_dice": 0.97 }, "intended_use": "This is an example, not to be used for diagnostic purposes", "references": [ "Isensee, F., Jaeger, P. F., Kohl, S. A., Petersen, J., & Maier-Hein, K. H. (2021). nnU-Net: a self-configuring method for deep learning-based biomedical image segmentation. Nature methods, 18(2), 203-211." ], "network_data_format":{ "inputs": { "image": { "type": "image", "format": "hounsfield", "modality": "CT", "num_channels": 1, "spatial_shape": ["*", "*", "*"], "dtype": "float32", "value_range": [-1024, 1024], "is_patch_data": false, "channel_def": {"0": "image"} } }, "outputs":{ "pred": { "type": "image", "format": "segmentation", "num_channels": 1, "spatial_shape": ["*", "*", "*"], "dtype": "float32", "value_range": [0,1], "is_patch_data": false, "channel_def": {"0": "background", "1": "spleen"} } } } } ``` The important fields to edit are: - `task`: A brief description of the task the model performs. - `description`: A detailed description of the model and its capabilities. - `network_data_format`: Defines the input and output formats, including data types, shapes, and channel definitions. And its sub-fields: - `inputs`: Describes the input data format, including type, modality, number of channels, spatial shape, data type, value range, and channel definitions. - `outputs`: Describes the output data format, including type, number of channels, spatial shape, data type, value range, and channel definitions. --- Then, to package the model, we provide a KubeFlow pipeline: [MONet-Pipeline-Convert_PT_to_TS](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/KubeFlow/Pipelines/MONet_pipeline_Convert_PT_to_TS.yaml) With this pipeline, we will convert the trained **PyTorch** model along with the complete **MONAI Bundle** into a **TorchScript** format. TorchScript is optimized for deployment and allows models to run independently of Python, making them suitable for integration into different systems. One key advantage of this process is that it produces a **single, standalone file** containing the model, which can be easily shared and reused across various environments. --- ### 1.7 Model Deployment and Inference After packaging, the model is ready for deployment. At this stage, there are several ways to share the model with others or integrate it into clinical workflows. The best approach depends on the intended use case, the desired level of automation and integration, and the amount of setup effort acceptable for end users. In this section, we present three primary deployment options. ##### Option 1: Model File Sharing The most straightforward way to share the model is by distributing the standalone **TorchScript** file. This approach requires minimal setup: users only need to prepare a Python environment with the necessary dependencies and can immediately run inference on their own data. **Requirements:** - PyTorch ≥ 2.6.0 with CUDA support - MONet Bundle (`monet-bundle`) ```bash MONet_local_inference -i /home/maia-user/shared/Task09_Spleen/imagesTs/spleen_1.nii.gz -o /home/maia-user/shared/Task09_Spleen/predsTs --model /home/maia-user/shared/MONet_Bundle/Task09/MONetBundle/models/fold_0/model.ts --username NOUSER ``` --- ##### Option 2: Docker Container with MONAI Deploy This option requires more setup effort initially but makes usage much easier for the end user, since no extra installation or configuration is needed. The model and all of its dependencies are packaged within a Docker container, ensuring a consistent runtime environment on any system that supports Docker. With the [**MONAI Deploy**](https://monai.io/deploy) framework, we can build standardized containers that bundle the model and all necessary components for inference. This simplifies deployment and guarantees reproducible execution across different platforms. --- ###### Docker Image Variants Two Docker image variants can be built, depending on the input data format: - **DICOM-based container**: takes DICOM images as input and outputs DICOM SEG - **NIfTI-based container**: takes NIfTI images as input and outputs NIfTI segmentation masks To allow the container to automatically detect which DICOM series or NIfTI file to process, a **Segmentation Task file** is required. This file defines the DICOM tags or NIfTI filename patterns to locate the input images, as well as the DICOM tags to use for the output segmentation. ###### Example Segmentation Task File (Spleen Segmentation) ```yaml tasks: Spleen: Modalities: image: File_Pattern: ".nii.gz" Rules_Text: | { "selections": [ { "name": "CT Series", "conditions": { "StudyDescription": "(.*?)", "Modality": "(?i)CT", "SeriesDescription": "(.*?)" } } ] } Segments: - segment_label: "Spleen" segmented_property_category: code: "91772007" scheme: "SCT" meaning: "Organ" segmented_property_type: code: "78961009" scheme: "SCT" meaning: "Spleen" algorithm_name: "MAIA_Segmentation-Spleen" ``` --- ###### Building the Docker Image We provide a KubeFlow pipeline for building the Docker image: [Docker-Build-Pipeline](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/KubeFlow/Pipelines/Docker_Build_pipeline.yaml) Parameters to specify: ```yaml "context": "docker/Spleen-HPC" # Path where to create the Docker context "destination": "maiacloud/aida-workshop-spleen:1.0" # Docker image name and tag for the DICOM-based container "destination_nifti": "maiacloud/aida-workshop-spleen:1.0-nifti" # Docker image name and tag for the NIfTI-based container "segmentation_task_file": "Segmentation_Task.yaml" # Path to the segmentation task file "model_file": "MONet_Bundle/Task09/MONetBundle/models/fold_0/model.ts" # Path to the TorchScript model file ``` ⚠️ Note: To successfully push the Docker image to your registry, the KubeFlow pipeline requires a secret named maiacloud-dockerhub in the same namespace where the pipeline is executed. Instructions for creating the secret can be found here: [Instruction to Create a Docker Registry Secret](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/Kubeflow.ipynb). --- ###### Running the Docker Images Once built, the images can be used on any Docker-enabled system. They are available here: [Docker Hub](https://hub.docker.com/r/maiacloud/aida-workshop-spleen) ###### Run via MONet Bundle: ```bash MONet_inference_nifti --study_folder /path/to/input/folder --prediction_output_folder /path/to/output/folder --docker-image maiacloud/aida-workshop-spleen:1.0-nifti ``` or for DICOM input: ```bash MONet_inference_dicom --dicom_study_folder /path/to/input/folder --prediction_output_folder /path/to/output/folder --docker-image maiacloud/aida-workshop-spleen:1.0 ``` ###### Run Directly with Docker: ```bash docker run --gpus all --shm-size 2g --rm -v /path/to/input/folder:/var/holoscan/input -v /path/to/output/folder:/var/holoscan/output maiacloud/aida-workshop-spleen:1.0-nifti ``` or for DICOM input: ```bash docker run --gpus all --shm-size 2g --rm -v /path/to/input/folder:/var/holoscan/input -v /path/to/output/folder:/var/holoscan/output maiacloud/aida-workshop-spleen:1.0 ``` --- ###### Integration with the MAIA Platform: For direct use within the MAIA platform, we also provide a KubeFlow pipeline that executes the Docker container directly: [MONet-Inference-Pipeline](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/tree/main/KubeFlow/Pipelines/MONet_Inference_pipeline.yaml) Parameters to specify: ```yaml "input_folder_path": "Task09_Spleen/DICOM/spleen_1" "output_folder_path": "Task09_Spleen/SEG/spleen_1" "image": "maiacloud/aida-workshop-spleen:1.0" ``` or for NIfTI input: ```yaml "input_folder_path": "Task09_Spleen/NIFTI/imagesTs/spleen_1" "output_folder_path": "Task09_Spleen/NIFTI/imagesTs/spleen_1" "image": "maiacloud/aida-workshop-spleen:1.0-nifti" ``` --- ##### Option 3: MAIA Segmentation Portal
The solutions described so far require some technical expertise to set up and operate, along with access to local computing resources such as GPUs. They are primarily designed for researchers and data scientists familiar with command-line tools and Docker, and are best suited for one-off runs or batch processing. Each inference session involves preparing input data, launching the environment, loading the model and dependencies, and finally executing the inference—an overhead that must be repeated every time. Alongside these approaches, which are well suited for technical users, we also offer a third option tailored for clinicians and radiologists. This option removes the need for technical knowledge or local hardware, providing an on-demand inference service that is always active and ready to process new images. All heavy computation runs on the MAIA platform, leaving users with only the task of sending images and saving the returned results. The **MAIA Segmentation Portal** hosts a collection of pre-trained models served via **MONAI Label**. It supports both **NIfTI** and **DICOM** inputs, enabling users to upload medical images directly and receive segmentation outputs without local setup. In the following section, we describe the different ways to interact with the MAIA Segmentation Portal. The strength of the **MAIA Segmentation Portal** lies in the fact that, once a model has been packaged as a **MONAI Bundle** (as described above), it can be easily deployed to the portal. This makes the model immediately available for inference to other authorized users within the MAIA platform. --- ###### Requirements To prepare a pretrained model for deployment on the **MAIA Segmentation Portal**, the model must be packaged as a **MONet Bundle**. Since the portal’s backend runs the inference service through MONAI Label, the interaction between the platform and the model is defined by the **MONet Bundle**. In summary: - Convert or prepare your pretrained model into a valid **MONet Bundle**. - Ensure the bundle follows the MONAI Label specifications so it can be consumed by the portal. - Once packaged, the model can be deployed to the MAIA Segmentation Portal for inference. To prepare the **MONet Bundle** for the spleen segmentation model to be deployed on the portal: ```bash mkdir -p /home/maia-user/shared/MONAILabel/Spleen MONet_fetch_bundle --bundle_path Spleen rm -r /home/maia-user/shared/MONAILabel/Spleen/MONetBundle/configs/metadata.json rm -r /home/maia-user/shared/MONAILabel/Spleen/MONetBundle/configs/inference.yaml mkdir -p /home/maia-user/shared/MONAILabel/Spleen/MONetBundle/models/fold_0 cp /home/maia-user/shared/MONet_Bundle/Task09/MONetBundle/models/fold_0/model.ts /home/maia-user/shared/MONAILabel/Spleen/MONetBundle/models/fold_0 ``` --- ###### Deploying the Model to the MAIA Segmentation Portal To deploy the model to the MAIA Segmentation Portal, follow the instructions provided in the [MONAI-Label Notebook](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/blob/main/MONAI-Label.ipynb). Once deployed, the model becomes accessible for inference through both the portal’s **web interface** and **API** : [https://spleen-segmentation.aida-workshop.maia-small.cloud.cbh.kth.se/](https://spleen-segmentation.aida-workshop.maia-small.cloud.cbh.kth.se/). In the following section, we describe the different ways users can interact with the MAIA Segmentation Portal to submit inference requests and obtain segmentation results. --- ###### 3D Slicer Integration Since the MAIA Segmentation Portal is built on top of **MONAI Label**, it can be accessed directly from the **3D Slicer** application using the **MONAI Label extension**.
--- ###### MAIA Segmentation Portal The **MAIA Segmentation Portal** provides a user-friendly graphic interface for users. You can download it for [Windows](https://github.com/SimoneBendazzoli93/MONet-Bundle/releases/download/v1.3/MAIA_Segmentation_Portal.exe) or [Linux](https://github.com/SimoneBendazzoli93/MONet-Bundle/releases/download/v1.1.6/MAIA_Segmentation_Portal). More details about the portal can be found at: [MAIA Segmentation Portal Documentation](https://monet-bundle.readthedocs.io/en/latest/MAIA_Segmentation_Portal.html). The GUI allows users, upon authentication, to: - List and describe available models - Execute remote inference by uploading images and downloading segmentation results - Execute local inference by downloading the model and running it locally When executing remote inference on a **DICOM study**, the workflow is as follows: 1. The DICOM study is first uploaded to **Orthanc**. 2. The inference is performed on the **MAIA Segmentation Portal**. 3. The resulting segmentation is downloaded locally as a **DICOM SEG**. 4. A copy of the segmentation is also stored back in Orthanc as a **DICOM SEG**. This ensures that results can be directly visualized in the **OHIF Viewer**, while Orthanc maintains both the original DICOM study and its corresponding segmentation for easy access.
--- ###### Orthanc Another option is to directly upload **DICOM images** to **Orthanc**, which includes a mechanism to automatically trigger inference requests to the **MAIA Segmentation Portal** whenever a new DICOM series is received. To enable automatic inference, the DICOM images must be uploaded with a specific tag in the `Image Comments` field. - For example, to trigger the **spleen segmentation model**, use the tag: `Spleen-MSP`. Once the images are received, Orthanc sends them to the MAIA Segmentation Portal for inference. After processing, the resulting **DICOM SEG** is stored back in Orthanc, automatically linked to the original study. This workflow is particularly useful for: - Automating the inference process. - Integrating segmentation into existing **clinical workflows**, where users only need to send DICOM images to Orthanc and then retrieve the results as DICOM SEG.
An example of this workflow can be found in the [MAIA-Segmentation-Portal.ipynb](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/blob/main/MAIA-Segmentation-Portal.ipynb) notebook. --- ###### MAIA-QR Another alternative for submitting inference requests to the **MAIA Segmentation Portal** is through the **MAIA-QR** (Query-Retrieve) application. This workflow mimics the behavior of a standard **PACS** system when interacting with the MAIA platform: 1. A **C-STORE** request is sent to Orthanc, containing the DICOM images to be processed. 2. As with the previous workflow, the `Image Comments` tag must include the model identifier to trigger the inference request. 3. A **Query-Retrieve (C-FIND/C-GET)** operation is then used to: - Monitor the status of the uploaded DICOM study. - Retrieve the resulting **DICOM SEG** from Orthanc once inference is complete. This approach provides seamless integration with PACS-like workflows, allowing automated submission, monitoring, and retrieval of segmentation results. The **MAIA-QR** script is available when installing the `monet-bundle` package: ```bash pip install monet-bundle MAIA_QR --pacs-ip aida-workshop-orthanc-svc-orthanc --calling-ae-title Zocu4r8gPAimKpAR --called-ae-title ORTHANC --input-folder /home/maia-user/shared/Task09_Spleen/DICOM/spleen_1-MSP --output-folder /home/maia-user/shared/Task09_Spleen/SEG ``` --- ## Part 2: Active Learning with MONAI Label Active Learning is a machine learning strategy that improves training efficiency by selectively identifying the most informative data points for annotation. This is especially valuable in fields like medical imaging, where labeled data is costly or limited. By iteratively focusing on the most uncertain or representative samples, Active Learning enhances model performance while reducing the overall annotation effort. This approach follows a **human-in-the-loop** paradigm, where the model provides initial predictions and the user refines them, gradually improving segmentation results through repeated interaction.
--- ### Active Learning Cycle 1. **Initialize** – Start with a pretrained model (or train from scratch). 2. **Prediction** – The model generates outputs on new, unlabeled data. 3. **Annotation** – The user reviews and corrects these predictions, creating accurate annotations. 4. **Integration** – The corrected annotations are stored (e.g., as DICOM SEG in Orthanc) and added to the training dataset. 5. **Retraining** – The model is retrained with the expanded dataset, improving accuracy. 6. **Iteration** – The cycle repeats on additional unlabeled data. --- ### Active Learning with 3D Slicer and MONAI Label We use **3D Slicer** with the **MONAI Label extension** to interactively refine model predictions. By connecting 3D Slicer to the **Spleen segmentation model** deployed on the **MAIA Segmentation Portal**, we can leverage a pretrained model to generate initial predictions on new CT scans. The user then reviews and corrects these predictions directly within 3D Slicer, producing high-quality annotations that can be fed back into the training process to further improve the model. Different model versions can be deployed and served through the **MAIA Segmentation Portal**. Since both **Model Deployment** and **Active Learning** are managed within the same **MONet Bundle** mechanism, the two workflows are directly integrated. --- ### Starting the Active Learning Loop **Note:** minimum 5 pairs of images/labels are needed by nnUNet to start the training process (one per fold in the standard 5-fold cross-validation setup). In the interface, we select the **train** section (use **infer** for prediction-only mode), and configure the loop with the following parameters: ```yaml pretrained: True max_epochs: 2 val_split: -1 multi_gpu: False gpus: all tracking: None tracking_uri: https://aida-workshop.maia-small.cloud.cbh.kth.se/mlflow tracking_experiment_name: Spleen-ActiveLearning run_id: "" model_filename: model.ts skip_preprocess: False Label_0: background dataset_name_or_id: 009 fold_id: 0 iterations: 50 mlflow_run_name: ActiveLearning-Iteration-1 modality_list: CT nnunet_configuration: 3d_fullres nnunet_plans_identifier: nnUNetPlans nnunet_trainer_class_name: nnUNetTrainer num_classes: 2 region_class_order: "" Label_1: Spleen ``` Optionally disable the preprocessing step if the data is already preprocessed (only required in the first iteration): ```yaml skip_preprocess: True ``` --- ### Training from Scratch In case a pretrained model is not available, you can start the active learning loop by training the model from scratch. To do this, set the `pretrained` flag to `False` in the configuration file: ```yaml pretrained: False ``` --- ## Part 3: Federated Learning with NVFlare ### Introduction to Federated Learning Federated Learning (FL) is a decentralized machine learning approach that enables multiple clients to collaboratively train a shared model while keeping their data localized. This method enhances data privacy and security, as sensitive information remains on the clients' devices, and only model updates are exchanged with a central server. FL is particularly beneficial in scenarios where data sharing is restricted due to privacy concerns or regulatory requirements.
--- ### NVFlare Overview NVFlare is an open-source framework developed by NVIDIA for building and deploying federated learning applications. It provides a robust infrastructure for managing communication between the central server and multiple clients, handling model aggregation, and ensuring secure data transmission. NVFlare supports various machine learning frameworks, making it a versatile choice for implementing federated learning solutions. Crucially, NVFlare is integrated within the MONAI ecosystem, enabling direct use of MONAI Bundles (and by extension, MONet Bundles) for federated learning tasks. This integration streamlines the deployment of medical imaging models in federated learning environments. For example, a model can first be trained across distributed clients using FL, and the resulting model can then be packaged as a MONet Bundle for active learning or deployment, as outlined in Part 1 of this tutorial. A practical demonstration of this approach—applied to PET-CT lymphoma segmentation and multimodal MRI brain tumor segmentation in the **BraTS challenge**—will be presented at **MICCAI 2025** in the **DeCaF (Distributed, Collaborative, and Federated Learning) workshop**. It will also be featured in the **BraTS challenge GoAT subtask** on generalization across tumors, underscoring the important role of federated learning in enhancing model generalization across diverse subtasks.
--- ### Brain Tumor Segmentation with Federated Learning for Enhanced Generalizability | **Dataset - Label** | **Experiment** | **DSC** | **ASD \[mm]** | | ------------------------ | -------------------- | --------------- | -------------- | | BraTS-GLI (n=251) - ET | Cross-Site BraTS-MEN | 0.695 ± 0.292 | 3.05 ± 8.69 | | | Cross-Site BraTS-MET | 0.729 ± 0.271 | 1.62 ± 4.97 | | | *MONet-FL* | *0.788 ± 0.261* | *1.57 ± 5.56* | | | BraTSFusion | 0.774 ± 0.271 | 1.61 ± 4.07 | | | nnU-Net-Baseline | 0.796 ± 0.254 | 1.38 ± 3.72 | | BraTS-GLI (n=251) - NETC | Cross-Site BraTS-MEN | 0.709 ± 0.296 | 2.17 ± 7.84 | | | Cross-Site BraTS-MET | 0.787 ± 0.218 | 1.47 ± 2.92 | | | *MONet-FL* | *0.836 ± 0.178* | *0.88 ± 1.83* | | | BraTSFusion | 0.846 ± 0.153 | 0.84 ± 1.40 | | | nnU-Net-Baseline | 0.871 ± 0.143 | 0.81 ± 1.73 | | BraTS-GLI (n=251) - SNFH | Cross-Site BraTS-MEN | 0.823 ± 0.197 | 2.52 ± 8.67 | | | Cross-Site BraTS-MET | 0.833 ± 0.167 | 1.29 ± 3.35 | | | *MONet-FL* | *0.884 ± 0.126* | *0.79 ± 2.21* | | | BraTSFusion | 0.897 ± 0.118 | 1.92 ± 0.08 | | | nnU-Net-Baseline | 0.896 ± 0.116 | 0.48 ± 1.38 | | BraTS-MEN (n=200) - ET | Cross-Site BraTS-GLI | 0.368 ± 0.352 | 8.92 ± 7.78 | | | Cross-Site BraTS-MET | 0.366 ± 0.338 | 8.85 ± 12.57 | | | *MONet-FL* | *0.422 ± 0.354* | *7.14 ± 7.38* | | | BraTSFusion | 0.304 ± 0.308 | 8.45 ± 8.67 | | | nnU-Net-Baseline | 0.367 ± 0.337 | 9.52 ± 8.49 | | BraTS-MEN (n=200) - NETC | Cross-Site BraTS-GLI | 0.716 ± 0.305 | 6.41 ± 12.83 | | | Cross-Site BraTS-MET | 0.714 ± 0.299 | 4.58 ± 7.08 | | | *MONet-FL* | *0.774 ± 0.273* | *3.25 ± 5.95* | | | BraTSFusion | 0.728 ± 0.349 | 3.97 ± 8.76 | | | nnU-Net-Baseline | 0.774 ± 0.312 | 1.87 ± 3.28 | | BraTS-MEN (n=200) - SNFH | Cross-Site BraTS-GLI | 0.763 ± 0.363 | 2.18 ± 10.75 | | | Cross-Site BraTS-MET | 0.745 ± 0.345 | 3.47 ± 13.43 | | | *MONet-FL* | *0.911 ± 0.184* | *2.29 ± 12.21* | | | BraTSFusion | 0.925 ± 0.140 | 2.05 ± 10.11 | | | nnU-Net-Baseline | 0.924 ± 0.168 | 2.35 ± 10.16 | | BraTS-MET (n=48) - ET | Cross-Site BraTS-GLI | 0.560 ± 0.335 | 5.97 ± 12.76 | | | Cross-Site BraTS-MEN | 0.358 ± 0.362 | 11.55 ± 23.56 | | | *MONet-FL* | *0.634 ± 0.303* | *3.47 ± 8.86* | | | BraTSFusion | 0.506 ± 0.313 | 6.79 ± 18.47 | | | nnU-Net-Baseline | 0.677 ± 0.281 | 3.14 ± 8.02 | | BraTS-MET (n=48) - NETC | Cross-Site BraTS-GLI | 0.658 ± 0.314 | 3.68 ± 10.01 | | | Cross-Site BraTS-MEN | 0.547 ± 0.376 | 8.59 ± 19.90 | | | *MONet-FL* | *0.719 ± 0.262* | *1.48 ± 1.92* | | | BraTSFusion | 0.698 ± 0.256 | 1.42 ± 1.27 | | | nnU-Net-Baseline | 0.727 ± 0.251 | 2.19 ± 5.06 | | BraTS-MET (n=48) - SNFH | Cross-Site BraTS-GLI | 0.613 ± 0.299 | 0.62 ± 0.36 | | | Cross-Site BraTS-MEN | 0.541 ± 0.338 | 13.51 ± 25.83 | | | *MONet-FL* | *0.763 ± 0.156* | *0.60 ± 0.66* | | | BraTSFusion | 0.717 ± 0.194 | 2.78 ± 11.49 | | | nnU-Net-Baseline | 0.791 ± 0.147 | 0.53 ± 0.44 | --- ### Lymphoma Segmentation with Federated Learning for Enhanced Generalizability | **Dataset - Label** | **Experiment** | **DSC** | **ASD [mm]** | |---------------------------|----------------------|--------------------|----------------------| | **AutoPET (n=27) - Lesion** | Cross-Site IL1 | 0.445 ± 0.270 | 50.19 ± 95.19 | | | Cross-Site IL2 | 0.587 ± 0.251 | 40.06 ± 89.72 | | | *MONet-FL* | *0.694 ± 0.279* | *10.80 ± 24.61* | | | LymphoFusion | 0.756 ± 0.244 | 19.27 ± 39.78 | | | nnU-Net-Baseline | 0.758 ± 0.252 | 38.50 ± 133.01 | | **IL1 (n=16) - Lesion** | Cross-Site AutoPET | 0.317 ± 0.255 | 99.46 ± 147.08 | | | Cross-Site IL2 | 0.297 ± 0.230 | 111.11 ± 172.99 | | | *MONet-FL* | *0.453 ± 0.252* | *70.91 ± 127.18* | | | LymphoFusion | 0.421 ± 0.223 | 90.29 ± 143.43 | | | nnU-Net-Baseline | 0.512 ± 0.215 | 12.95 ± 11.69 | | **IL2 (n=31) - Lesion** | Cross-Site AutoPET | 0.534 ± 0.265 | 39.34 ± 71.36 | | | Cross-Site IL1 | 0.391 ± 0.247 | 40.03 ± 79.63 | | | *MONet-FL* | *0.610 ± 0.234* | *25.03 ± 64.44* | | | LymphoFusion | 0.665 ± 0.242 | 23.07 ± 70.48 | | | nnU-Net-Baseline | 0.671 ± 0.275 | 24.09 ± 72.41 | --- ### Setting Up NVFlare with MAIA Within the MAIA workspace, it is possible to pre install a [**NVFlare Dashboard**](https://nvflare.aida-workshop.maia-small.cloud.cbh.kth.se/) to be able to provision a NVFlare server and multiple clients, and start a federated learning experiment using MONet Bundles. Users can register to the NVFlare and get access to the their **Startup Kits**, which are used to get access to the NVFlare federation. Additionally, authorized users can register new clients to the federation, and get access to their **Startup Kits** to join the federation from the clients. --- ### Start the Server To start the server, you first need to download the server startup kit from the NVFlare dashboard, and then start the server on your MAIA workspace: ```bash helm install maia-server workspace/demo/prod_00/nvflare-chart ``` Remeber to unzip the startup kit with the password given in the NVFlare dashboard and upload it throguh SFTP to: ```bash ssh admin@maia-sftp cd /home/nvflare put -r
``` --- ### Start the Clients To start a client, you first need to download the client startup kit from the NVFlare dashboard, and then start the client on your MAIA workspace: ```bash helm install maia-client-1 workspace/demo/prod_00/nvflare-chart/templates/maia-client-1 ``` Remeber to unzip the startup kit with the password given in the NVFlare dashboard and upload it throguh SFTP to: ```bash ssh admin@maia-client-1-sftp cd /home/nvflare put -r
``` #### Start Clients on HPC Clusters Through the MAIA-HPC module, explained in [HPC Integration](#15-model-training-and-validation-with-nnunet-hpc), the clients can also be hosted on HPC clusters, to leverage more powerful computing resources. We provide an example of an experiment configuration file to start a NVFlare client on one of the HPC clusters available in MAIA. The only other requirement is to have the maiacloud/nvflare:1.3 image available as a Singularity container on the HPC cluster, under the project folder: ```bash cd
singularity pull docker://maiacloud/nvflare:1.3 ``` --- ### Access the Federation Once the Federation, formed by the server and multiple clients, is up and running, you can access the NVFlare dashboard to monitor the status of the federation, start new experiments, and monitor the status of the experiments: ```bash
/startup/fl_admin.sh ``` --- ### Tutorial: Spleen Segmentation with Federated Learning In this tutorial, we demonstrate how to set up and run a **federated learning experiment for spleen segmentation** using [NVFlare](https://nvflare.readthedocs.io/en/main/) and **MONet Bundles**. You can follow along using the provided notebook: 👉 [MONet-FL.ipynb](https://github.com/SimoneBendazzoli93/MAIA-AIDA-TechDays-Workshop/blob/main/MONet-FL.ipynb) --- #### Workflow Overview The tutorial covers the following steps: ##### 1. Dataset Preparation Each participating site prepares its local dataset. Data is harmonized and organized according to the **nnUNet directory structure**, including training, validation, and test splits. ##### 2. Experiment Planning (Main Site) One site is designated as the *main site*. This site runs the **nnUNet experiment planning** step, which generates preprocessing and training configurations. These plans are then shared with all other sites to ensure consistency across the federation. ##### 3. Preprocessing (All Sites) Using the shared nnUNet plans, each site preprocesses its own local data. This ensures that feature extraction, resampling, and normalization are aligned across the federation. ##### 4. Federated Training The training phase runs locally at each site using **nnUNet**. Instead of sending raw data, each site sends model updates (gradients/weights) to the FL server, which securely aggregates them into a **global model**. ##### 5. Cross-Site Evaluation Once training is complete, the global model is evaluated across all sites. Each site runs inference on its local test set, and results are collected to assess performance consistency and generalization. ##### 6. Model Packaging The trained global model is packaged as a **MONet Bundle**. This makes the model portable, reproducible, and ready for deployment in downstream workflows such as: - Active learning - External validation - Clinical inference pipelines --- ## Final Considerations The **MAIA platform** demonstrates how medical AI research can be supported through a flexible and accessible infrastructure. Key takeaways include: - **End-to-End Workflow** From data ingestion and preprocessing to model training, evaluation, and deployment, the full AI development cycle is streamlined in a single platform. - **Expert-in-the-Loop Interaction** Clinicians and researchers can iteratively refine models, ensuring that AI outputs remain clinically relevant and trustworthy. - **Federated Learning Configuration** Enables collaborative research across multiple sites while preserving patient data privacy, promoting secure and ethical data sharing. - **Accessible Infrastructure** Unlike traditional high-maintenance data centers, MAIA runs efficiently on **regular office workstations** equipped with **gaming-level GPUs**. This drastically lowers entry barriers for institutions without large-scale compute resources. --- ✨ **Best Highlight**: MAIA makes it possible to build a **democratized, open, and accessible AI infrastructure** for medical imaging research—empowering institutions of all sizes to participate in advancing medical AI. --- ## What’s Next Looking ahead, **MAIA aims to further expand within the Swedish arena**, strengthening its role as a collaborative hub for medical AI research. The platform’s development will continue to focus on: - **Continuous Improvement** of tools, workflows, and infrastructure. - **Support for Research Groups and Clinical Partners**, ensuring that MAIA provides practical solutions for a wide range of applications. - **Broader Collaboration and Involvement**, welcoming new partners to contribute to the **growth and expansion** of the platform. By building on its foundations, MAIA seeks to become a cornerstone for **collaborative, privacy-preserving, and impactful medical AI research** in Sweden and beyond.