WP2 - Task 1: Pilot report - The Netherlands | UNITED4Surveillance

UNITED4Surveillance Grant Agreement Number 101102070 WP2 Outbreak detection – Task 1: Improving Laboratory Based-Reporting Milestone 34: Pilot report the Netherlands Open-source reference data pilot in the Netherlands Disclaimer Copyright message This document was produced under the terms and conditions of Grant Agreement No. 101102070 for the European Commission. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or HaDEA. Neither the European Union nor the granting authority can be held responsible for them. © UNITED4Surveillance Consortium, 2025 This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both. Reproduction is authorized provided the source is acknowledged. UNITED4Surveillance Grant Agreement Number 101102070 Introduction The Netherlands has initiated the development of LabSentiNL (pronounced: labsentinel), a national platform for laboratory-based surveillance of infectious diseases. This pilot aligns with the broader goals of UNITED4Surveillance by addressing the fragmented and delayed data exchange between medical microbiology laboratories, municipal public health authorities, and the National Institute for Public Health and the Environment (RIVM). 1.1 Background & objectives LabSentiNL is designed to support the early detection of infectious disease signals by integrating genotypic, phenotypic, and any available epidemiological and clinical data in one platform. The system fosters collaboration, data standardisation, and timely signal interpretation, contributing to a more performant (laboratory-based) surveillance infrastructure. It is being developed as open-source software under the European Union Public Licence (EUPL) to promote transparency, sustainability, and international reusability. The objective of this pilot was to prepare and deliver the beta release of LabSentiNL as a functional, modular, platform, with the code being publicly available on GitHub, as defined in milestone (MS) 34. 1.2 Outcome/delivered product The main deliverable of this pilot is the LabSentiNL beta version, and specifically within that the “seqdb” component for storing sequence data. The remainder of the components are developed using other funding, among which grant 101113520 - NLWGSHERA2 - EU4H-2022-DGA-MS-IBA-1, Work Package 7. All components are made available as open source under the EUPL-1.2 licence on GitHub in the “gen-epix” repositories. The name gen-epix refers to genomic epidemiology, which is the type of analysis it supports, and disease/pathogen X, which refers to pandemic preparedness. The gen-epix and gen-epix-web packages include: - Case-based data storage, with the possibility of combining genomic, phenotypic, epidemiological and clinical information. The seqdb component manages the genomic data part, including the generation of phylogenetic trees. The physical data model of this component (Figure 1) was derived from the logical data model developed as part of MS22 (see Annex 1 of D2.1) 1 . - Initial disease/pathogen support for Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) and E. coli, with scalable architecture for additional case types. The platform is built to be pathogen-agnostic and as such usable for any species, including any new pathogen X. - Fine-grained object-level access control, critical for compliance with the General Data Protection Regulation (GDPR) 2 in terms of being able to control the risk of identification of an individual, and for building trust because of the voluntary nature of the data sharing between the organisations in question. - Web interfaces for interactive phylogenetic (tree) analysis, geographic distribution (maps), epi curves, and line lists of cases of infectious disease. In addition, events can be defined as sets of cases. - Authentication mechanism based on OIDC OAuth2 flow, allowing multiple identity providers and federation of identity providers so that participating organisations can log in with their own account. - Internationalisation support, with English currently implemented and Dutch underway. 1 D2.1 Review of existing i) laboratory surveillance systems and ii) outbreak detection systems or methods of participating countries 2 Regulation - 2016/679 - EN - gdpr - EUR-Lex UNITED4Surveillance Grant Agreement Number 101102070 - A TypeScript/React frontend set up as a Single Page Application. The React open source framework, originally developed by Facebook, is currently the most used framework for web application development. - A Python/FastAPI backend which functions as an Application Programming Interface (API) for both the frontend and potential third-party applications. The FastAPI open source framework is currently one of the three most used frameworks for developing APIs in Python, and produces an API compliant with the OpenAPI standard. - Support for privacy friendly web analytics. Based on the open source Matomo framework. The pre-beta platform was presented in a series of user group meetings for validation, feedback, and iterative refinement. Figure 1. Physical data model for the sequence database, beta version. 1.3 Impact The beta release of LabSentiNL represents a significant step forward in modernising infectious disease surveillance in the Netherlands. Key expected impacts of the platform, once live, include: UNITED4Surveillance Grant Agreement Number 101102070 • Cross-institutional collaboration. Data sharing between laboratories, municipal health services, and the national public health institute is streamlined, with the medical microbiology laboratories receiving much more back from RIVM than before about the data they contributed. This in turn stimulates them to provide more data. • Improved signal detection. Municipal health authorities can themselves see if there are likely epidemiologically linked cases in other, typically neighbouring municipal health regions. The same for the laboratories that can detect signals themselves, and which are usually more experienced than municipal health authorities in correctly interpreting the genomic information such as the phylogenetic tree. Faster upload of data, to the extent that this issue could be resolved by the platform, also enables faster signal detection. • Improved follow-up. Events such as signals or outbreaks can be defined, described and maintained by the relevant organisation(s) in one place, while quick access is made possible through e.g. a permanent link to the event that can be pasted in electronic communication or used during weekly epidemiological signal follow-up meetings. At the same time, it is currently not possible in the Netherlands to combine detailed epidemiological data, collected by municipal health authorities, with the information from the laboratory-based surveillance stream due to the lack of a common identifier. Achieving this falls beyond the scope of the platform. • Open-source innovation. The gen-epix source code is explicitly designed to not contain a single line of code that is Netherlands-specific. Instead, country-specific aspects such as the organisations that would have access, and what data access rights they would have, are added as metadata after deployment. The EUPL-1.2 licence under which the source code is released promotes reuse by other organisations, such as national and international public health institutions. • Flexibility. The platform is rapidly extensible to new diseases/pathogens, including in the event of a potential pandemic. The cases types, i.e. the diseases or pathogens, the variables and the allowed values that can be uploaded and viewed, are all metadata that are added after deployment, analogous to the metadata about organisations and their access rights. There is no disease-specific code that would potentially reduce usability e.g. due to differences in methodology adopted by different organisations. • Scalability. The platform is developed for and deployed on cloud infrastructure, where scalability in terms of compute and storage capacity is much easier to achieve than in an on-premise setup. At the same time, there is no dependency on specific cloud infrastructure and on-premise installation is possible as well. Feedback from users on the pre-beta release confirmed that LabSentiNL supports both national coordination and regional decision-making through a shared, interactive data infrastructure. 1.4 Evaluation Evaluation of the product Evaluation of the pilot product, i.e. the LabSentiNL beta release, was performed through regular structured feedback loops with ~30 stakeholders in a user group, in accordance with the principles of agile software development. Every 3-5 months a demonstration for the user group was held. The project team also held a discussion with structured questions based on the U4S evaluation template in April 2025. The final evaluation of the beta release was conducted in April 2025 through two user group meetings involving medical microbiological laboratories and municipal public health authorities. In total, 19 stakeholders participated: 12 from laboratories, 6 from municipal health services, and 1 participant from an unknown domain (anonymous result). Feedback was collected through live demonstrations, discussion UNITED4Surveillance Grant Agreement Number 101102070 sessions, and Mentimeter polls. For the ratings a Likert scale was used: 1 = strongly disagree, 3 neutral, and 5 = strongly agree. Usefulness LabSentiNL was highly valued for its potential in early signal detection and public health threat response. Users gave an average score of 4.36 for its contribution to signal detection, and 3.91 for its value in the follow-up of outbreaks, indicating strong perceived relevance of the platform to surveillance goals. Simplicity (usability and user experience) The general usability of the platform received a score of 4.0, with some concerns expressed about the complexity of sharing cases, which scored slightly lower at 3.86. While users found the rights and access model logical (score: 4.18), several indicated that the operational workflow—particularly setting data-sharing permissions—could be perceived as technically demanding, especially without sufficient support or automation. Participants emphasized the need for clearer documentation, standardised procedures, and targeted training - especially for users involved in setting data access levels and managing collections. The desire for an opt-out rather than opt-in model for data sharing between laboratories in addition to RIVM was expressed to reduce operational burden and promote broader participation. Flexibility Users appreciated the platform's design allowing differentiated data access rights across local, regional, and national levels. The fine-grained access control and ability to retrospectively add data (e.g. sequences) were seen as strengths. However, some technical challenges were noted, such as limited automation with existing Laboratory Information Management System (LIMS) systems and the lack of standardised identifiers across datasets, which could affect data linkage and consistency. Timeliness Since the product is at the beta release stage, i.e. under development, the impact on timeliness of laboratory-based surveillance could not be measured. Data quality Participants recognized LabSentiNL’s potential to improve data quality through standardised data entry and shared visual analytics. However, concerns were raised around metadata consistency, interpretation differences, and identifiability of persons, especially in the context of sensitive or rare pathogens. Quality control of uploaded sequence data remains an issue. The platform does not, by design, implement any bioinformatics pipelines, since different organisations use different ones. The raw sequence data is not necessarily shared with RIVM either. A well-defined and adhered-to set of quality criteria applied before uploading is therefore needed. Acceptability While users found the platform generally acceptable, the perceived administrative workload was noted as a limiting factor for some. Municipal health services, in particular, expressed uncertainty about their roles and responsibilities in data contribution and usage, highlighting the need for improved role clarity and governance alignment. Evaluation of the process UNITED4Surveillance Grant Agreement Number 101102070 This part was not applicable to this pilot, since there was no production implementation involved, only a beta release with demo data. Evaluation of sustainability The evaluation of barriers to adoption was done together with the evaluation of the product, i.e. through the (external) user group. The remainder of the aspects was evaluated by RIVM. Barriers to adoption Common challenges identified in both sessions included: • Differences in interpretation of the GDPR 3 together with national legislation related to public health by legal departments of participating organisations. This mainly relates to the legal basis for sharing the special category of medical data, even if pseudonymised, in the public interest, and, the potential for identifying a person based on a combination of data elements, in particular for rare diseases and/or diseases associated with sexual preference. • “Free-loading” participants. It is possible, in the platform, for participants to not (broadly) share while still seeing the data of other participants that did share. Strategies to mitigate this risk can include peer pressure by showing the amount of data shared by different participants, and sharing by default through an opt out mechanism. These remain to be worked out. • Ease of upload. Ideally participants are able to upload their data to RIVM and the platform using a largely automated process using machine-to-machine communication. This work has been ongoing for a long time, independent from LabSentiNL, but faces substantial technical and financial challenges. Scalability As described in section 1.3 Impact, the platform is developed for and deployed on cloud infrastructure, where scalability in terms of compute and storage capacity is relatively easy to achieve. The performance of the platform code, i.e. independent of the infrastructure it runs on, will need to be further tuned between the beta release and the go-live. This is by design, since premature optimisation is a well-known anti-pattern in professional software development. At the same time, the beta release is already now able to show a large dataset of 2000 cases, including a phylogenetic tree that is computationally expensive to calculate and render, with acceptable performance. Long term funding The LabSentiNL platform will replace several existing platforms that are technically end-of-life. Barring fundamental restrictions in budget, it is the expectation that laboratory-based surveillance, for which LabSentiNL is a critical technical component, will remain funded long term. Conclusions from the evaluation Overall, the LabSentiNL beta release, including the seqdb component, was positively received, with a strong appreciation for its analytical capabilities and early warning potential. Usability and privacy concerns remain important areas for improvement. The feedback from the user sessions is actively being incorporated into the next development iterations and the drafting of the user agreement, to ensure broader adoption and long-term sustainability. 3 Regulation - 2016/679 - EN - gdpr - EUR-Lex UNITED4Surveillance Grant Agreement Number 101102070 1.5 Recommendations Based on the evaluation, we recommend: 1. Policy development a. Expand the platform to One Health partners providing data from samples of non-human origin, including sequence data. The platform can already support this technically, but the legal agreements with the relevant stakeholders have not yet been made for this. 2. Technical improvements a. Investigate simplifying data-sharing workflows with support for default sharing settings (share by default) b. Develop Machine-2-Machine (M2M) integrations to reduce manual workflows for participants. 3. Training and onboarding a. Provide targeted role-based training. b. Offer interactive demos, video tutorials, and sandbox environments. 4. Open-source adoption support a. To lower the barrier for reuse and encourage broader adoption of LabSentiNL as an opensource platform, we recommend including a sample dataset in the public GitHub repository. This would allow new users and developers to explore the platform’s functionality without needing access to real case data. b. Optionally provide a demo configuration (e.g. Docker Compose or test database dump) to help adopters quickly set up a sandbox environment. 5. Platform development a. Expand to additional pathogens based on national priorities. b. Maintain focus on open-source development with clear contribution guidelines. 1.6 Core messages LabSentiNL is seen as a valuable tool for early detection and outbreak management according to the future end users. It supports pandemic preparedness by rapidly being able to add disease/pathogen X, use of the same platform for both the cold and warm phase, and deployability on cloud infrastructure where scaling is relatively easy to implement. User feedback confirmed strong support for the platform’s goals, but called for improvements in usability, automation, and training. Legal and governance clarity is key to adoption, and this is taken into account to the extent possible by the user agreement for the platform that is being drafted. Sustainable development is very likely ensured as the platform will be a critical component of laboratorybased surveillance of infectious diseases in the Netherlands. The source code is explicitly designed for use in different contexts than the Netherlands, and its release under the European Union Public License 1.2 guarantees that other organisations can not only do that but also contribute to a shared code base. The generic platform is called Genomic Epidemiology for Disease X (Gen-EpiX). The source code can be downloaded here: https://github.com/RIVM-bioinformatics/gen-epix.