At the time of starting the project, we evaluated multiple FA frameworks and chose DataSHIELD due to its comprehensive privacy controls, stable community support, and mature set of statistical functions. DataSHIELD’s unique strength lies in its local, decentralized authorization mechanism and built-in privacy disclosure checks, which prevent analysts from executing arbitrary code on remote servers. The “default privacy disclosure mode” enforces a baseline set of privacy checks (eg, thresholds on minimum cell counts) that align with real-world clinical data governance needs. While other tools like NVidia FLARE or custom Python/R frameworks exist, they often lack these out-of-the-box privacy safeguards, making DataSHIELD a practical choice for our use case. We maintained the default privacy settings throughout the study to ensure a fair demonstration of DataSHIELD’s capabilities without additional configuration.

DP provides a measurement of the privacy risk associated with publishing each particular result on a sensitive dataset, by measuring the maximum leakage that each result can cause about the individuals’ data. In practice, it often works through the addition of a controlled amount of statistical noise to obscure the contributions to the result from each individual in the dataset.

Several open-source libraries exist that implement DP, most of which are written in Python or expose a Python interface. Popular ones include Google’s DP library [10], PyDP [11] from the OpenMined community and OpenDP [12]. In R, the main open-source library is the diffpriv library [13] that implements some DP mechanisms but not a real suite of functions ready to use, and which is not actively supported with last contributions going back to 2017. Furthermore, none of these tools were directly compatible with the DataSHIELD framework, which requires a specific interface in R. As a result, a new open-source a DP R package (R Core Team) for DataSHIELD has been implemented: dsPrivacy. It is available in the Arkhn GitHub repository.

dsPrivacy implements common statistical operations such as mean (SD) with DP and can be directly integrated into DataSHIELD. More specifically, pure DP has been implemented, which means that the statistical noise added to the result is drawn from a Laplacian distribution. Privacy is therefore defined with a single parameter “ε” (which corresponds to the inverse of the noise variance) and it is called the privacy budget. The privacy budget ε controls the amount of noise injected in the computation and hence the privacy of the analysis, smaller the privacy budget ε, higher the noise, which means better privacy guarantees since the private information is better covered by the noise.

DP induces a trade-off between privacy and accuracy of the analysis [14] as privacy is ensured with noise, better privacy means a lower signal-to-noise ratio and less meaningful results. Conversely, when ε is high, the noise is reduced and privacy degrades. Choosing the right value for ε from a privacy standpoint is quite controversial [15] and is highly dependent on the context and the study considered.

dsPrivacy in the context of FA works by adding Laplacian noise locally at each center on the results computed on the local datasets before results are aggregated on a central node. This is referred to as local DP, as opposed to central DP, where the noise is added after the aggregation part on the central node. This paradigm is detailed in the Discussion section.

From an ethical and regulatory standpoint, this study complied with the MR-004 reference methodology and adhered to GDPR requirements since DP alone does not classify data as anonymized under current regulatory frameworks. However, the use of DP strengthens data protection, and aligns with emerging privacy regulations by minimizing data exposure risks. These regulatory environments emphasize data sovereignty, patient consent, and robust security, all of which are supported by our federated, privacy-enhancing architecture. All patients enrolled in this study were informed individually, and those who exercised their right to opt out were removed from the study. This is an observational study and the research ethics committees of all three centers in Toulouse, Reims, and Foch have confirmed that no ethical approval is required and have authorized this project on their patient data.

The schema of our federated architecture is given in Figure 1. Researchers connect through a VPN to a central node hosted on a cloud provider–certified ISO (International Organization for Standardization) 27001 standard. This central node coordinates the execution of the queries on the remote data assets hosted in the different hospitals and aggregate all the responses received. Each hospital exposes through the private network pseudonymized datasets, which originate from their local harmonized data architecture, but which are completely isolated on a dedicated infrastructure for security purposes. Each hospital receives and executes remote requests from the central node that match local permissions set in DataSHIELD regarding data assets, authorized functions, and legitimate users. This ensures that hospitals keep full sovereignty on how their data are exploited.

One key element is deploying a secure private network between all stakeholders, ensuring that each hospital only exposes pseudonymized data within a controlled environment. Although these pseudonymized datasets were not themselves protected by DP before analysis (since DP is applied at query-time), the secure network, encryption (TLS), and isolation measures minimize risks. We did not use “Let’s Encrypt” for certificates due to internal security policies favoring certificates from recognized authorities and the controlled VPN environment lacking public domain validation. Instead, a custom approach using a trusted certificate authority provided both strong authentication and encryption tailored to our network configuration.

The flowchart is presented in Figure 2. In total, 75 and 74 patients from respectively before and after the first wave were included in the analysis comparing disease progression. Of the patients in the period before, 63 had progressed, 9 were progression-free, and 3 had changed groups during the observation period and were therefore censored at the time of transfer. Of the patients in the period after, 55 had progressed, 17 were progression-free and 2 had changed groups during the observation period and were therefore censored at the time of transfer. Thus, after exclusion of patients who changed centers, 72 patients from each period were included in the analysis of the duration of the first line of treatment.

Combined univariate analyses without and those with DP are presented in Multimedia Appendix 4. Combined bivariate analyses without and with DP are presented in Tables 1 and 2, respectively. Direct comparison between DP and no-DP analyses across all periods is available in Table 3. In analysis without and with DP, the covariates selected for multivariate analyses were the treatment type (<.001) only.

In the analysis without DP, the hazard ratio of the cox model for the period before compared with the period after the first wave was 0.98 (95% CI 0.65-1.46). As the 95% CI includes 1, the two periods were not considered significantly different in terms of disease progression at 24 months after adjustment for a significant covariate (treatment type).

In the analysis without DP, the coefficient of linear regression for the first period compared with the second one was –13.84 (95% CI –103.82 to 76.14). As the CI includes 1, the two periods were not considered significantly different in terms of first line duration after adjustment for significant covariate (treatment type).

In this study, a federated analysis with and without DP was performed on a real-world study in oncology. The real-world study showed consistent results in both settings. In particular, identical conclusions were drawn regarding the lack of difference in first-line treatment duration and disease progression at 24 months in non–small cell lung cancer patients treated before or after the first wave of COVID-19 pandemic.

Real-world deployment in 3 centers has shed light on some key aspects in terms of security. Regarding tools, DataSHIELD offers a lot of flexibility as it allows the use of custom libraries such as dsPrivacy implemented as part of this study. The downside is that community libraries are not always well maintained and bugs can be encountered (eg, dsStats had to be fixed manually). DataSHIELD builds upon Opal [19], a convenient data management application which comes with straightforward but very satisfactory user management and makes it easy to configure access to specific data to specific users. Opal is also secured by design and enforces many good security practices like CSRF (Cross-Site Request Forgery) and HTTPS usage. However, available docker images to deploy it have several major known security vulnerabilities and do not seem regularly updated. Regarding network configuration, setting up strong security standards across all sites has proved challenging. An IpSec bridge was set up to enable secure communication between the central node and the hospitals. Communication among all stakeholders was a key factor for this step and formal processes (network schema, requirements formalization, debugging methods, and so on) proved decisive in order to facilitate discussions. Regarding certificates to secure communications inside the private network, the primary intention was to use certificates signed by hospitals internal certificate authority because it would not match our security requirements so certificates signed by public certificate authority have been claimed. Some hospitals provided a Sertigo certificate but it was not natively recognized by the central node server. Another hospital used instead a public certificate generated by the central node manager (Arkhn). This last solution has proven to be the best solution in terms of efficiency and security, even if the domain names covered by these certificates are not representing the actual ownership of hosts.

Regarding data standards, we chose FHIR, since it appeared to be the most mature health standard in oncology at the beginning of this project [16,17]. However, Observational Medical Outcomes Partnership (OMOP) is developing extensions for oncology and is rapidly closing the gap [20,21]. As the FHIR standard corresponds to json files that are not very suitable for analytical purposes, we anticipate that moving to OMOP will be more convenient for future analyses.

Overall, our experience suggests that the most time and work intensive parts are building harmonized data models locally and setting up the network infrastructure. As both these steps are agnostic of the study considered, we anticipate that they can be easily leveraged to scale the number of studies carried out on this infrastructure.

On the DP side, it has been decided not to perform linear regression and Cox models with DP because implementing it with a moderate privacy budget was deemed too complex. Privacy budgets used in this study (especially for computing the P values) are quite high compared with the literature [15,22], in order to achieve reasonable accuracy on differentially private results but we have shown that we are able to derive similar results compared with plain FA. As underlined above, the appropriate level of privacy is highly dependent on the context considered. Here, given that this study was already compliant to the French MR-004 methodology without DP, DP was used by prioritizing usefulness over privacy. In other contexts, especially if DP becomes recognized as a legitimate and safe technology to process personal data, and hence benefits from a dedicated regulatory status, lower privacy budgets will probably be required (alongside privacy-focused pen tests). We have identified 3 directions to achieve this. The first direction is to increase the number of patients per center. This is the most straightforward option to improve the privacy vs accuracy trade-off, since the amount of noise to add to reach a certain privacy budget ε directly depends on the number of individuals. We have included close to 50 patients per center, which is quite low especially for some budget intensive operations for which we estimate that a thousand patients would be adapted. Second, by using central DP. If the noise is added on the central node, it is computed considering the sum of the patients across all the centers and enables lower noise for the same privacy budget. This is especially powerful if many centers are participating in the federated analysis. However, this means that by default the central node can see the contribution of each center without any noise which is a privacy breach if it cannot be trusted. A common solution is to implement secure aggregation [23], meaning that all contributions are hidden and are only disclosed after the aggregation operation, using cryptographic mechanisms such as secure multiparty computation [24], homomorphic encryption [25], or functional encryption [26]. Secure aggregation is not yet implemented in dsPrivacy and is left as future work. Finally, it can be achieved by improving the DP mechanism. We have used pure or ε-DP, which is a simple mechanism and which makes composition very simple, since the privacy budget of a sequence of operations is the sum of the budget of each operation. More complex mechanisms such as (ε, δ)-DP [6] or Rényi DP [27] provide more optimized composition properties [28] that allow for a tighter privacy budget management.

The DARAH project illustrates FA are a practical method to conduct scientific projects while improving data privacy, by keeping patient data stored in the hospitals and leveraging their already existing data architecture. It highlights some key challenges to be anticipated and possible answers to ensure the success of this type of projects. It also shows that DP can be used in addition to FA to improve privacy guarantees, but more experimentation is needed to develop guidelines and best practices, especially around the trade-off between accuracy and privacy. Finally, in an emerging ecosystem where tools for FA and DP are not yet well integrated, the dsPrivacy library will prove useful for researchers who want to explore privacy-friendly analysis methods.