This page gives a brief overview of LeoMed and describes how research groups can become LeoMed shareholders.

Table of Contents

What is LeoMed?

Leonhard Med (LeoMed) is a secure, powerful, and versatile scientific data and computing platform to transfer, store, manage and analyze confidential research data. Leonhard Med is provisioned and operated by the Scientific IT Services (SIS) of IT Services at ETH Zurich. At the national level, SIS with the Leonhard Med platform is part of the BioMedIT network, representing the BioMedIT node Zurich. Visit our website to find out more about our services for confidential research data or see this presentation.

(lightbulb)Confidential data, per LeoMed Acceptable Use Policy refers to all personal data (either identifying or pseudonymized data, in particular, health-related or medical data) unless explicitly classified differently.

secure project space for data storage, management and analysis with command line and remote desktop access

secure and collaborative compute environment for data management and data analysis (bioinformatics, ML, etc.)

secure data transfer from distributed sources (Swiss hospitals and research facilities, international repos, etc.)

flexible and customizable (e.g., hosting specialized web-based applications, DBs, clinical data warehouses, containerized applications etc.)

Important roles on LeoMed

  • The Project Leader (PL) is accountable for the legally and ethically correct handling of all Confidential Data across the whole data lifecycle of a research project. The PL is responsible and accountable for the correct data classification within the project. The PL names the Users who are entitled to access and process sensitive data within the project (see LeoMed AUP Art. 9). The PL can delegate the user management to a Permissions Manager.
  • The Permissions Manager (PM) is designated by the PL and it is responsible for requesting user access or revocation of user access to a specific project space or research group space on Leonhard Med.
  • The Data Manager (DM) is often used in the BioMedIT context and is responsible for managing confidential data on Leonhard Med. The data manager's responsibilities include, but are not limited to, requesting data from external sources, decrypting confidential data transferred to Leonhard Med, and organizing data on the system.
  • The User is a person that has been authorized by a PL to access and use LeoMed tenants/project spaces. Users are responsible for the confidentiality of personal access data and identification mechanisms, such as passwords, PINs, private keys, tokens. The Users may not disclose or make available this access data to third persons, or give them access under their account name (see LeoMed AUP Art. 8).

LeoMed use cases

With LeoMed, many different use cases to securely work with sensitive data can be accommodated. These cases cover some workflows possible after a research group becomes a LeoMed shareholder and their project space has been configured according to their requirements:

A research group wants to store sensitive data.

  • Sensitive data is transferred to LeoMed, either as a service via the BioMedIT secure data transfer process, or on the user level.
  • The Data Manager can organize the data on LeoMed.
  • The data is backed up regularly.
  • After the project ends and the tenant is closed, the data can be securely destroyed or securely archived.

A research group wants to securely manage sensitive data using a data management solution.

  • Sensitive data is transferred to LeoMed (see use case above).
  • The Data Manager organizes the data using a data management solution (e.g., openBIS)
  • The Permissions Manager can add other lab members to the LeoMed tenant so that they can work with the data.

A research group wants to securely share the data with a collaborating research group.

  • Research group A transfers data that they collected to their LeoMed tenant.
  • Research group B wants to work with the data without transferring it to their own infrastructure
  • After the groups sign legal agreements, members from research group B can be added to the LeoMed tenant by the Permissions Manager.

A research group wants to securely work with sensitive data from multiple Swiss hospitals.

  • Sensitive data is transferred to LeoMed via the BioMedIT secure data transfer process
  • To initiate the process the Data Manager sends a Data Transfer Request BioMedIT, which will validate it and forward it to the Data Providers
  • The Data Providers encrypt the data and transfer it to the BioMedIT network
  • The data automatically arrives in the project's tenant on LeoMed and the Data Manager can decrypt and work with the data.

A research group wants to securely analyze sensitive data on a high-performance compute cluster.

  • Sensitive data is transferred to LeoMed (see use cases above).
  • Post Doc A analyzes the data using centrally provided software or software maintained by the research group; potentially run in a container
  • Post Doc A analyzes the data by submitting a job to a SLURM high-performance compute cluster, utilizing resources that the cluster can provide, such as, CPUs, GPUs, large memory.
  • Additionally, Post Doc A can collaborate on data analysis with Post Doc B

A research group wants to securely host a web application that aggregates and plots sensitive data.

  • Sensitive data is transferred to LeoMed (see use cases above).
  • A dedicated virtual machine running rootless docker will be deployed.
  • Ph.D. student A develops a data analysis pipeline, which aggregates sensitive data and plots it in an interactive R-Shiny app. S/he containerizes the app and transfers the container to the VM on LeoMed. Here s/he can configure and run the container.
  • Ph.D. student B wants to use the app. S/he logs in to LeoMed and works with the app in the web browser.

LeoMed in action

User accounts

Once a tenant is set up, users requiring access to LeoMed can be added. Users must be authorized by the tenant's Project Leader (PL) and the user account must be requested by the Permissions Manager (PM).


Once the LeoMed user account has been set up and the user has configured the two-factor authentication (2FA), users are ready to access Leonhard Med either via remote desktop (via a web browser) or ssh (via the command line). Users enter the LeoMed platform on a login node. It serves as a jumping-off point for all services available on LeoMed, such as storage, the compute cluster, or locally hosted web services.

Data transfer and storage

Confidential as well as non-confidential data can be transferred to LeoMed. Non-confidential data can be transferred on the user level. Confidential data must be encrypted before transfer and can be transferred via the BioMedIT process, or in a user-driven way.

Users can store smaller, non-confidential data (such as analysis scripts) in their home directory and large amounts of confidential research data in a project directory.

Software and compute

From the login node, users can submit jobs to a SLURM compute cluster.

LeoMed centrally provides the Compute Canada software stack and users also can, under certain restrictions, install software themselves. Users can use data analysis tools, such as RStudio or Jupyter notebooks on LeoMed. Furthermore, software can be executed via containers.


Users can run containers to execute containerized data analysis workflows on the cluster or deploy containerized web-based services on LeoMed in dedicated virtual machines.

LeoMed layout

LeoMed is organized into tenants (distinct spaces). There are two types of tenant layouts on LeoMed: secure shared, and secure isolated tenants.

 Secure shared tenantSecure isolated tenant
Security levelelevated (as compared to standard high-performance computing systems)high
  • Multiple customers are allowed per tenant
  • The tenant is isolated by a logical network separation
  • Within the secure shared tenant, the access to the data may be restricted (i.e., per research project) using UNIX file permission rules
  • Data sharing between tenants is exclusively allowed based on explicit authorization (e.g. of the responsible Project Leader)
  • Only one customer per tenant is allowed
  • A customer may have several tenants
  • The tenant is isolated by a logical network separation
  • Within the isolated tenant, only the resources purchased for it may be used (e.g. compute nodes, virtual machines)
BenefitsSharing of compute resources between projects is possible.High security level for data protection

UNIX file permission rules offer elevated data security, however unauthorized data access within a secure shared tenant may be technically possible, for example when unauthorized actor obtains root permissions within a virtual machine.

No sharing of compute resources between projects is possible.
RecommendationConsider this option when elevated security for data protection is sufficient and benefit from sharing a pool of compute resources available in the tenant.Consider this option when high security level for data protection is required (e.g. research project with specific ethical approval) and when there is no need to use a pool of shared compute resources.

The multi-tenancy features in Leonhard Med: a secure shared tenant and secure isolated tenant are shown. Tenant resources are isolated from the rest of the cluster by logical network separation (red box). Within a secure shared tenant, UNIX file permission can further separate the data of customers (blue box), whereas a common pool of compute resources is shared. Users may have access to more than one tenant, however, data sharing between tenants is only allowed upon explicit authorization by the Project Leader responsible for the dataset to be shared.

Becoming a LeoMed shareholder

  • Research groups interested in becoming a LeoMed shareholder and in getting access to a LeoMed tenant should get in touch with SIS at
  • SIS will explain the process and the responsibilities
  • SIS and the potential shareholder - who will assume the Project Leader (PL) role - will discuss the requirements
  • The PL will identify initial users (Permissions Manager and Data Manager; can also be a single person).
    • PL, PM, DM must sing the Leonhard Med Acceptable Use Policy
    • initial users (PM, DM) need to provide relevant keys and information for user account creation (see Getting user access to LeoMed)
    • ETHZ-members will access LeoMed from the ETHZ network (e.g., VPN). In order for ETHZ-externals to reach LeoMed from outside the ETH network, the LeoMed support team needs to whitelist (allow) your institutional IP address or the IP address range (see Whitelisting external sources for ETH-externals to get access to LeoMed).
  • Once all the requirements have been clarified, SIS will provide a quote for the initial purchase of a Leonhard Med tenant
  • PL will approve the quote and send a binding requests to SIS at

LeoMed Price Model 2022


CodeSpecificationsPrice typeone time
4 years
1 year
one time
4 years
1 year
ST-SNTSetup of a new tenant (one time fee)fixed1'000



Tenant operation (up to 10 users)

(valid for both secure isolated tenants and individual allocations inside a shared tenant)


Tenant operation per additional user (11-50)


Tenant operation per additional user (from 51 on)


Secure storage per TB

(including Geo-redundant tape backup, encrypted)

ST-ARCSecure archival operation (one time, per package)fixed1'000


ST-ARC10Secure archival of data for 10 years, per TB
free of charge8


General Purpose Node

CA-VM-VF12 cores, 4 GiB RAMfixed
CA-VM-VF24 cores, 8 GiB RAM fixed
CA-VM-VF38 cores, 16 GiB RAM fixed
CA-VM-VF416 cores, 32 GiB RAM fixed
Compute Node

CN-HM-VF114 cores, 224 GiB RAMindicative
CN-HM-VF228 cores, 450 GiB RAMindicative
CN-HM-VF356 cores, 900 GiB RAMindicative
CN-HM-VF4124 cores, 2040 GiB RAMindicative
Standard GPU Node (RTX2080Ti or equivalent)

GP-TR-VF14 cores, 46 GiB RAM, 1 GPUsindicative
GP-TR-VF28 cores, 92 GiB RAM, 2 GPUsindicative
GP-TR-VF316 cores, 186 GiB RAM, 4 GPUsindicative
GP-TR-VF434 cores, 372 GiB RAM, 8 GPUsindicative

High-end GPU Node (Titan RTX or equivalent)


14 cores, 56 GiB RAM, 1 GPUs


28 cores, 112 GiB RAM, 2 GPUs


56 cores, 224 GiB RAM, 4 GPUs


124 cores, 450 GiB RAM, 8 GPUs

Additional standard services

RDM-openBISRDM openBIS, on request1fixed2'000N/A1'0004'000N/A2'000
TR-GSHalf-day "Getting started" course, on request2fixedincluded6
BIT-BSBase package BioMedIT, on request3fixed

included6 - if BioMedIT eligible

BIT-SDTStandard secure data transfer BioMedIT, on request4fixed
BIT-FUMFederated user identity management BioMedIT, on request5fixed









Subscription expert services (1 FTE for 1 year), on request7
IT Solution Engineer, Research Data Manager, IT Security Engineer. Subject to specific rules set forth by the service provider.


140'000 (1 FTE) 
150'000 (< 0.8 FTE) 

200'000 (1 FTE)

DR-ESDaily rates expert services, on request.
IT Solution Engineer, Research Data Manager, IT Security Engineer. Subject to specific rules set forth by the service provider.




  • These specifications and prices are valid from 01/02/2022 until further notice.
  • Specifications and prices are indicative and may vary depending on supplier, product life cycle, technological changes, etc.
  • Prices include costs (e.g. VAT) that are not covered by funding agencies like the ERC.
  • ETH-internal prices are subsidized by ETH and are therefore valid only for members of the ETH domain. ETH-external prices are valid for customers that are not members of the ETH domain.
  • Storage is offered only to customers who have purchased compute resources in Leonhard Med.
  • Memory is expressed in binary units (1 GiB = 2^30 bytes), whereas storage is expressed in decimal units (1 TB = 10^12 bytes).               
  • 1 RDM openBIS price covers: instance setup for openBIS in a specified Leonhard Med tenant, openBIS technical maintenance, minimal openBIS data model, user training and support. The cost does not include infrastructure cost. Default openBIS instance allocation is: CA-VM-VF1
  • 2 courses are included free of charge in the service. Additional course sessions may incur a fee.
  • 3 BioMedIT base package (e.g., secure tenants, BioMedIT federated user identity management, standard secure data transfer process) are provisioned to eligible BioMedIT customers (i.e., all SPHN and PHRT projects funded in phase I and II) at no cost for the projects. GPU compute nodes are not covered by the BioMedIT base package.                                                            
  • 4,5 These service configurations are included per default the BioMedIT base package and may be requested by customers independent of BioMedIT, i.e., as non-standard service configurations.
  • 6 These service configurations are included free of charge in the service and are offered on request.
  • 7 Subscription expert services (e.g. customer-level SLA) are offered on request, for an initial period of 2 years with possibility of extension. A subscription must amount to a minimum of 20 % FTE per year.
  • 8 No steering tax will be charged for the LTS service from January 1st, 2020 for all ETH members.
  • The following items are included per default and free of charge in the service: user support, access to centrally installed software and applications library (including workload manager and container technologies), option for secure data transfer at user level, option for data restoration from backup.
  • Standard GPU nodes are sold out. Due to a worldwide semiconductor shortage, it is not possible to say when we will be able to order new ones, what type of GPUs they will contain, and how much they will cost.
  • For any questions regarding the Leonhard Med service configuration options and prices or different types of available expert services models (e.g. subscription or daily rates), please contact the Leonhard Med service desk (