D3.3 - Development of an architecture blueprint, including a specification of the central and local infrastructure components

1 A new, interdisciplinary, multi-stakeholder European network to improve healthcare services, research and outcomes for Adolescents and Young Adults with cancer. STRONG-AYA – No. 101057482 – D3.3 2 Deliverable Report WP3 – Infrastructure and interoperability Deliverable D3.3 Development of an architecture blueprint, including a specification of the central and local infrastructure components Due date of deliverable: 30/09/2023 Actual submission date: 29/09/2023 Project: STRONG-AYA Lead Contributor Leonard Wee, UNIMAAS Email [email protected] Other Contributors Andre Dekker, UNIMAAS Gijs Geleijnse, IKNL Bart van Beusekom, IKNL Joshi Hogenboom, UNIMAAS Ananya Choudhury, UNIMAAS Emails [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Due date 30 09 2023 Delivery date 29 09 2023 Deliverable type R Dissemination level SEN Description of Work Version Date STRONG-AYA – No. 101057482 – D3.3 3 V2.0 was reviewed by external committee and some minor additions by way of explanation was requested. This is now added and resubmitted. V2.1 30/09/2024 V 0.2 Amended rough draft 13-03-2023; incorporated some comments received, adjusted document lay out. Major revision to simplify for general (non-specialist) reader. Marked certain sections for alignment with other documents and then eventually removed from this document V2.0 13/03/2023 V1.0 10/12/2022 Description: Architecture blueprint will guide the development of local, regional, national and European infrastructure components developed iteratively throughout the project Summary (max ½ page) The architectural blueprint of the STRONG AYA infrastructure outlines the technical infrastructure requirements to build the fundamental foundation of the STRONG AYA federated learning ecosystem. It should be read in conjunction with the data management plan (D3.1), the business architecture (D2.1), the Code of Conduct (D2.2), and the operational ecosystem plans at the national and pan-European levels (D4.4, D4.6, D4.7) STRONG-AYA – No. 101057482 – D3.3 4 1 Table of Contents SUMMARY (MAX ½ PAGE) .......................................................................................................................................... 3 1 TABLE OF CONTENTS .......................................................................................................................................... 4 2 DEFINITIONS....................................................................................................................................................... 5 3 ABBREVIATIONS ................................................................................................................................................. 6 4 PROJECT INTRODUCTION ................................................................................................................................... 7 PROJECT BACKGROUND ........................................................................................................................................................ 7 5 DELIVERABLE INTRODUCTION ............................................................................................................................ 9 5.1.1 Disclaimer ................................................................................................................................................... 10 5.1.2 Complementary documentation ................................................................................................................. 10 6 FEDERATED DATA ECOSYSTEMS – LOCAL/CENTRE LEVEL...................................................................................11 TECHNICAL REQUIREMENT 1: DATA MANAGEMENT INSIDE PARTNER INSTITUTION .......................................................................... 11 TECHNICAL REQUIREMENT 2: TRUSTED COMPUTING ENVIRONMENT FOR RESEARCH ....................................................................... 13 TECHNICAL REQUIREMENT 3: MOVING EXTRACTED DATA INTO RESEARCH ENVIRONMENT ................................................................ 14 TECHNICAL REQUIREMENT 4: UPDATING OF DATA OVER TIME .................................................................................................... 14 TECHNICAL REQUIREMENT 5: PATIENT REPORTED OUTCOMES DATA COLLECTION ........................................................................... 14 7 FAIR DATA PRINCIPLES ......................................................................................................................................15 TECHNICAL REQUIREMENT 6: EXECUTING DOCKER CONTAINERIZED SOFTWARE .............................................................................. 16 TECHNICAL REQUIREMENT 7: DEFINING METADATA FOR MAPPING TO THE COS ............................................................................ 16 TECHNICAL REQUIREMENT 8: ADDING HARMONIZED COS SCHEMA AS METADATA ......................................................................... 17 8 FEDERATED ANALYTICS AND FEDERATED LEARNING .........................................................................................17 TECHNICAL REQUIREMENT 9: DATA VISUALIZATION DASHBOARDS ............................................................................................... 18 TECHNICAL REQUIREMENT 10: FEDERATED LEARNING OF STATISTICAL MODELS.............................................................................. 18 TECHNICAL REQUIREMENT 11: PROTECTIONS AGAINST RUNNING UNAUTHORIZED CONTAINERS ........................................................ 18 9 SECURE WEB INFRASTRUCTURE – THE PAN-EUROPEAN ECOSYSTEM ................................................................19 TECHNICAL REQUIREMENT 12: SOFTWARE INFRASTRUCTURE VANTAGE6 ..................................................................................... 19 TECHNICAL REQUIREMENT 13: USE OF THIRD PARTY SECURE AGGREGATION TO ENHANCE SAFETY ..................................................... 19 TECHNICAL REQUIREMENT 14: SERVICES SUPPORTED BY SUBCONTRACTOR ................................................................................... 19 APPENDIX: FAIR DATA ...............................................................................................................................................21 STRONG-AYA – No. 101057482 – D3.3 5 2 Definitions STRONG AYA consortium members are referred to as following within this text: 1. NKI-AVL – Stichting het Nederlands Kanker Instituut – Antoni van Leeuwenhoek Ziekenhuis (NL) 2. YCE – Youth Cancer Europe (RO) 3. INT – Fondazione IRCCS Instituto Nazionale dei Tumori (IT) 4. FFUND – FFUND BV (NL) 5. CLB – Centre de Lutte Contre le Cancer Leon Berard (FR) 6. ECO – European Cancer Organisation (BE) 7. UNIMAAS – Universiteit Maastricht (NL) 8. IKNL – Stichting Integraal Kankercentrum Nederland (NL) 9. EORTC – European Organisation for Research and Treatment of Cancer AISBL (BE) 10. IGR – Institut Gustave Roussy (FR) 11. MSCNRIO – Narodowy Instytut Onkologii im. Marii Sklodowskiej-Curie – Panstwowy Instytut Badawczy (Marie Sklodowska-Curie National Research Institute of Oncology) (PL) 12. UOM – University of Manchester (UK) 13. UOL – University of Leeds (UK) 14. LTHT – Leeds Teaching Hospitals National Health Service Trust (UL) 15. SOUTHAMPTON – University of Southampton (UK)  Grant Agreement (including its annexes and amendments): the agreement signed between the beneficiaries of the HORIZON Research and Innovations Actions (hereafter referred to as Horizon) and the European Health and Digital Executive Agency (hereafter referred to as HADEA) for the undertaking of the STRONG AYA project (Grant Agreement no. 101057482).  Beneficiary: Signatories of the Grant Agreement  Associated Partner: Entities which participate in the action but without the right to charge costs or claim contributions.  Project: the sum of all activities carried out in the framework of the Grant Agreement.  Consortium: the STRONG AYA consortium, including all the aforementioned partners.  Consortium Agreement: The agreement made between STRONG AYA members for the implementation and execution of the action outlined in the Grant Agreement. The agreement shall not affect the parties’ obligations to HADEA on behalf of the European Union, and/or to one another arising from the Grant Agreement. STRONG-AYA – No. 101057482 – D3.3 6 3 Abbreviations Acronym/Abbreviation Meaning HCP Health Care Provider PRO Patient Reported Outcome PROM Patient Reported Outcome Measure COS Core Outcome Set WP Work Package WPL Work Package Lead(s) WP1 Work Package 1 (Development Core Outcome Set AYA with cancer & data collection) WP2 Work Package 2 (Governance, Data Security and Ethics) WP3 Work Package 3 (Infrastructure and Interoperability) WP4 Work Package 4 (Operation of STRONG AYA ecosystems, stakeholder and patient involvement, dissemination, exploitation, communication) WP5 Work Package 5 (Scientific coordination and project management) KPI Key Performance Indicator OA Open Access PAB Patient Advisory Board EC European Commission HADEA European Health and Digital Executive Agency SC Steering Committee MT Management Team DMP Data Management Plan STRONG-AYA – No. 101057482 – D3.3 7 4 Project Introduction Project background Cancer at adolescent and young adult (AYA) age is rare, although 4-6 times more frequent than paediatric cancer (i.e. prepubescent period). However, this rarity does not reflect the significant personal and societal costs of cancer in this population, as reflected in the potential years of life lost or saved, the decreased productivity and quality-of-life due to the impact of the disease during formative years, and the long-term complications or disabilities 1 . AYAs with cancer form a unique group; they face age-specific issues (e.g. Infertility, unemployment, financial problems) and decreased quality of life due to cancer and its treatment. Unlike dedicated healthcare and trials for paediatric cancer patients, AYA-specific healthcare services are scarce and vary across Europe. AYAs who are at the core of society and economy need access to ageappropriate and high-quality healthcare. Defining AYAs with cancer as 15 to 39 years at initial cancer diagnosis 2 , their annual cancer incidence is 42.2/100.000, with 156.431 cases in Europe and 1.231.007 cases worldwide reported in 2018 (together 6.8% of all cancers) 3 . Population-based data from 27 European countries supports that AYAs have lower survival than children but higher than adults affected by cancer. Advances in cancer treatment have led to increased survival rates for AYAs with cancer, improving by 82% for all cancers between 1990 and 2007 4 . However, survival improvement in AYA is more challenging than for children and older cancer survivors, which might be due to the fact that AYA have the highest absolute excess risk of second primary malignant neoplasms 5 . AYA face some distinct challenges given that they do not belong to neither paediatric nor adult oncology groups. Characteristic features of this population group include unique spectrum of cancer types, different tumour biology, unique complex psychological needs, distinct late sequelae, including impaired fertility, and palliative care. These traits imply that clinical management, treatment, diagnosis, psychological support will need to be designed and developed for AYA’s specific needs. For example, AYAs diagnosed with breast and prostate carcinomas have worse survival than older patients because of the biological differences between them, highlighting the need to target screening methodologies, treatment and policies to their needs 6 . AYAs with cancer also face significant psychological challenges, including substance abuse, mental health issues, suicidal ideations and increased emotional burden from cancer and cancer-related morbidity. Finally, tailoring cancer care to AYA’s needs is difficult and due to many different complex factors including the low rate of participation by AYAs in clinical trials and cancer research 7 . Despite the increasing awareness and a growing body of the scientific literature, these unique issues remain to be fully recognised and addressed by the European health systems and AYAs with cancer are frequently underserved. In part, this may have resulted from the traditional dichotomy between the integrated paediatric (“patient/family-centred”) care services versus dispersed (“diseasecentered”) adult oncology 1 Stoneham SJ. AYA survivorship: The next challenge. Cancer 2020; 126: 2116-2119. 2 Adolescent and Young Adult Oncology Review Group. Closing the gap: Research and Care Imperatives for Adolescents and Young Adults with Cancer. National Institute of Health, National Cancer Institute, and Livestrong Young Ault Alliance: Bethesda, MD, USA, 2006. 3 Trama A, Botta L, Steliarova-Foucher E. Cancer Burden in Adolescents and Young Adults: A Review of Epidemiological Evidence. Cancer J 2018; 24: 256-266 4 Trama A, Botta L, Foschi R et al. Survival of European adolescents and young adults diagnosed with cancer in 2000-07: population-based data from EUROCARE5. Lancet Oncol 2016; 17: 896-906. 5 Keegan THM, Bleyer A, Rosenberg AS et al. Second Primary Malignant Neoplasms and Survival in Adolescent and Young Adult Cancer Survivors. JAMA Oncol 2017; 3: 1554-1557. 6 Stark D, Bielack S, Brugieres L et al. Teenagers and young adults with cancer in Europe: from national programmes to a European integrated coordinated project. European Journal of Cancer Care, 25(3), 419–427. 7 Hayashi RJ. Adolescent and young adult cancer survivorship: The new frontier for investigation. Cancer 2019; 125: 1976-1978. STRONG-AYA – No. 101057482 – D3.3 8 services 8 , 9 , 10 . Up to half of AYAs with cancer report unmet informational and service needs, impacting their direct (survival rates) and indirect (long term effects and mental health) recovery to participate in society 11 . Furthermore, aligned with this barrier is the low rate of health care utilisation by AYAs, especially primary care, given their challenges to sustain health insurance coverage 12 . According to a survey conducted through the networks of the AYA Working Group of the European Society for Medical Oncology (ESMO) and the European Society for Paediatric Oncology (SIOP Europe), 67% of practitioners do not have access to specialised centres for AYA with cancer, 67% had no access to a specialist cancer service for late effects management and 38% had no access to fertility specialists. Under-provision and inequality of AYA cancer care is common across Europe and especially in the Eastern and Southern-East. Furthermore, the Working Group also reported an absence of outcome measures for monitoring and evaluating AYA cancer care programs and control 13 . Among the recommended future steps, it has been identified that one of the most important contributions to AYA research would be to pool data (e.g. patient-reported outcomes, clinical and treatment data) across institutions and countries and create large cohorts for researchers to Address the burden of cancer in AYA 14 . There is a lack of data standardization, data interoperability and (prospective) collection of outcomes of relevance for AYAs with cancer. The STRONG-AYA project aims to tackle the underrepresentation of AYA’s experiences and outcomes when navigating the healthcare system and in clinical care by developing national infrastructures for outcome data management and clinical decision-making within a pan-European ecosystem and establishing communication feedback for AYAs with cancer and the healthcare systems. This will be key to improving healthcare services, research, outcomes and policies for AYAs and to ultimately better cancer care for this patient group. To this aim, STRONG-AYA brings together an international multi-disciplinary consortium across seven European countries, led by the Netherlands Cancer Institute (NKI) and composed of academic research organisations (European Organisation for Research and Treatment of Cancer (EORTC), University of Southampton, University of Leeds, University of Manchester, Maastricht University, Netherlands Comprehensive Cancer Organisation (IKNL)), clinical partners (Italian National Tumour Institute, Léon Bérard Centre, Gustave Roussy Institute, Maria Sklodowska-Curie National Research Institute of Oncology, the Leeds Teaching Hospitals National Health Service Trust), stakeholder and patient organisations (Youth Cancer Europe, European Cancer Organisation) and a consulting company (FFUND). Building on previous initiatives, a STRONG-AYA data ecosystem will be set up for value-based care, research and policy for AYA with cancer by: 1. Developing a Core Outcome Set (COS) specifically for AYAs with cancer, via a participative consensus process defining most important aspects for those directly affected by AYA cancer, including patients and healthcare professionals. 8 Ferrari A, Stark D, Peccatori FA et al. Adolescents and young adults (AYA) with cancer: a position paper from the AYA Working Group of the European Society for Medical Oncology (ESMO) and the European Society for Paediatric Oncology (SIOPE). ESMO Open 2021; 6: 100096. 9 Osborn M, Johnson R, Thompson K et al. Models of care for adolescent and young adult cancer programs. Pediatr Blood Cancer 2019; 66: e27991. 10 Fardell JE, Patterson P, Wakefield CE et al. A Narrative Review of Models of Care for Adolescents and Young Adults with Cancer: Barriers and Recommendations. J Adolesc Young Adult Oncol 2018; 7: 148-152. 11 Keegan TH, Lichtensztajn DY, Kato I et al. Unmet adolescent and young adult cancer survivors information and service needs: a population-based cancer registry study. J Cancer Surviv 2012; 6: 239-250. 12 Hayashi RJ. Adolescent and young adult cancer survivorship: The new frontier for investigation. Cancer 2019; 125: 1976-1978. 13 Saloustros E, Stark D, Michailidou K et al. Report on ESMO/SIOPE European Landscape project key results: Mapping the status and needs in AYA cancer care. Late-breaking and deferred publication abstracts public health 2017; 28, 5: V643. 14 Smith AW, Seibel NL, Lewis DR et al. Next steps for adolescent and young adult oncology workshop: An update on progress and recommendations for the future. Cancer 2016; 122: 988-999. STRONG-AYA – No. 101057482 – D3.3 9 2. Implementing the COS across several national European healthcare systems. Data will be collected at local level and will then be included in a data integration platform. An overall ecosystem framework for data analytics and output will be created supporting federated analyses and the creation of reports across clinical and patient-reported data and making national repositories of (patient-reported) health data, available to individual patients, patient organisations, regulatory authorities, as well as the patients’ health care providers to inform clinical decision-making. The five resulting national ecosystems will be connected to each other into the pan-European ecosystem using a federated approach also utilizing the overall ecosystem framework. 3. Disseminating the COS to a wide range of local as well as pan-European stakeholders, in particular by developing analytical tools to process and present patient outcome data and establish feedback loops that inform patients and clinicians. Implementing these project objectives are five work packages within the STRONG-AYA project:  WP1: Development Core Outcome Set AYA with cancer and Data Collection (Lead: SOUTHAMPTON)  WP2: Governance, Data Security and Ethics (Lead: EORTC)  WP3: Infrastructure and Interoperability (Lead: UNIMAAS)  WP4: Operation of STRONG-AYA ecosystems, Stakeholder and Patient involvement, Dissemination, Exploitation, Communication (Lead: E.C.O.)  WP5: Scientific Coordination and Project Management (Lead: NKI) STRONG-AYA will enable AYA care and research to benefit from collection and pooling of patient-centered data and collaboration among all stakeholders: patients, healthcare professionals, scientists, and policymakers. More widely, the project will leverage the network of interested organisations and networks established under STRONG-AYA for long-term strengthened promotion of the necessary implementation of specialist AYA cancer services across Europe. This will ultimately bring novel insights into AYA cancer care, research and policy, contributing to the long-term improvement of outcomes for people with AYA cancer. 5 Deliverable introduction The STRONG-AYA consortium believes that innovative and paradigm-breaking ways of accessing data and sharing knowledge across institutional siloes is urgently needed to improve healthcare for this unique group of people. The key pillars of the project are : (1) consensus (Delphi) development of a Core Outcomes Set i.e. COS; (2) infrastructure for collecting, managing and enhancing AYA data among participating countries; (3) disseminate outcomes and data analysis tools at the pan-European level to improve patterns of care for AYAs. A federated design for data management and data analysis was chosen as a promising approach to address fragmentation of data, to address adoption barriers associated with centralized patient data repositories, and to be more easily able to support scale-up with numerous future partners. Data management that complies with FAIR (Findable-Accessible-Interoperable-Reusable) data principles is a cornerstone of our technical infrastructure. The FAIR principles will accordingly be applied at partner, national and pan-European levels for data, and subsequently digital artefacts generated (e.g., software, publications, reports) from the project work. STRONG-AYA – No. 101057482 – D3.3 16 Semantic interoperability means that the precise meaning of the data is preserved and understood throughout all transactions between cooperating partners. In STRONG-AYA, we will be supporting the open world paradigm that allows us to work with structured data extraction from each partner in any format and any terminology. We will add a FAIR-based implementation of semantic interoperability on top of the AYA data, in order to make our datasets mutually understandable to each other. An illustration of how we place a semantically interoperable annotations “layer” on top of the data can be viewed here (approximately 20 minutes video playtime). STRONG-AYA partners are recommended to view the online video, to get an idea of what the general idea looks like. Technical Requirement 6: Executing Docker containerized software STRONG-AYA partners should use a Docker application from UNIMAAS containing a basic set of tools that assists with making structured data more FAIR. This Docker application will be started in the trusted STRONGAYA virtual machine where the extracted COS data is already being stored. This application includes a Graphical User Interface (GUI). A) Via the GUI, the local PI of the data can select which database(s) to process into a non-tabular format known as Resource Descriptor Framework (RDF). This RDF contains the patient-level contents of the PI’s database. B) The GUI them prompts the local PI to match which fields in the own data (presumably in the PI’s native language and in their own coding system) corresponds to which expected COS items. C) There is extra space for additional descriptions in free text (in English please) where the local PI can describe their fields more fully, or define additional data fields that they think is important but might not be immediately matching with the current version of COS. D) The local PIs database schema layout and its codebook (but not the data contents) will be saved as a W3C Web Ontology Language (OWL) file. The matched labels and the PI’s own additional text notes will also be saved in the OWL file. E) The RDF file (data contents) and the OWL (local schema and codebook) will be archived in their own trusted virtual machine as a “graph database”. F) The local PI, with the assistance of their institutional team, is free to inspect the OWL files to confirm that it contains schema, codebook and matched COS items, but it does not contain any individual patient data. Technical Requirement 7: Defining metadata for mapping to the COS Only an OWL file from the procedure in Tech Requirement 6 will be privately and securely shared (e.g. by secured file transfer tools) by the partner PI to the technology partner UNIMAAS. Note that the OWL file shall contain protected information about the database organization and ad hoc schema, but it does not contain any individually-identifiable patient information. UNIMAAS data scientists will work closely with each partner PI and with the leader of Work Package 1, to create the customized annotations for that institution, so that their data is FAIR and suited to the needs of the STRONG-AYA project. STRONG-AYA – No. 101057482 – D3.3 17 Technical Requirement 8: Adding harmonized COS schema as metadata Technical partner UNIMAAS will provide a customized annotation file to each partner, so that the local database schema will be automatically mapped with the over-arching COS and thus becomes interoperable with the rest of the consortium data. Each local PI shall keep this custom annotation file in their own institution STRONG AYA device. 8 Federated analytics and federated learning Mathematical methods adjusted for multiple geographically-dispersed datasets will used to analyze data and create statistical models. We have tested the validity of these methods, and can show that the results of computation are the same as if we had analyzed all that data in one single location. Federated analytics is concerned with generating cohort summaries and descriptive statistics on-demand from dispersed datasets (on-demand here means the ability to interactively and dynamically generate them in near-real time, such that the summary statistics do not need to be pre-calculated beforehand to be archived alongside the underlying data). Federated learning is similarly concerned with fitting statistical models on demand from dispersed data (e.g., regression models, decision trees and machine learning models – including deep learning neural networks). The STRONG-AYA project supports validated and certified tools for users to perform their own federated analytics and federated learning. Federated analytics is somewhat analogous to performing a pooled statistical meta-analysis of individual research studies. Each study is self-contained and independent, but it communicates (through its published manuscript) its own aggregated statistical results to the reviewer, but there is no individual patient data exchanged. The reviewer has to collect the aggregated results of each study, and then come up with the pooled global statistics as their meta-analysis. Federated learning is somewhat analogous to how a political union functions. For example, the European Union is a consortium consisting of autonomous nations, but it is able to implement policies on important global matters such as trade policy, through a certain process of iteration until everyone converges on a consensus policy. In STRONG-AYA, a central aggregator device serves an analogous function as the author of the pooled meta-analysis or as the European Parliament. It has the role of communicating with nodes and finding a consensus among nodes (more about the central aggregator device in the section on Secure Web Infrastructure). Note : These annotations sit on top of the extracted COS data as persistent “metadata”. This metadata will be needed when doing federated analysis and federated learning. Our design allows multiple annotations to simultaneously co-exist on top of the same data (for example, due to different utilization cases or changes in terminology over time). The metadata layers keep the semantic interoperability of data across the STRONG-AYA consortium, without having to edit any of the underlying COS data generated by the institution. STRONG-AYA – No. 101057482 – D3.3 18 Technical Requirement 9: Data visualization dashboards Federated data analytics will be supported in the form of interactive data exploration “dashboards” which displays summary statistical data, not any individual data. The desired layout and summaries displayed will be customized for the user and/or some pre-defined dashboard layouts will be available for the user to choose from. After the user logs in and authenticates, the dashboard will be accessible to that user (assuming they have the correct levels of permission) as a web interface on their own computer devices. Important : The infrastructure (see section on Secure Web Infrastructure) shall have built-in protection against retrieving statistical summaries from any partner institution if their local summary statistic contains less than 10 subjects. Technical Requirement 10: Federated learning of statistical models Federated learning of statistical models will be supported, so that approved users can fit widely known statistical models, for example logistic regression, without displaying individual patients data. The desired models and the covariates to be fitted will be customized for the user and/or some pre-defined modelling modules will be provided for the user to choose from. After the user logs in and authenticates, the available models will be accessible to that user (assuming they have the correct levels of permission) as a web interface on their own computer devices. Important : The infrastructure (see section on Secure Web Infrastructure) shall have built-in protection against making statistical models from any partner institution if their local model contains less than 10 subjects. Technical Requirement 11: Protections against running unauthorized containers The statistical summaries and statistical models will be packaged as self-contained “micro”-software applications called Docker containers. These docker containers execute exclusively inside the partner’s trusted STRONG-AYA computing device. A) All programming language code of the federated analysis and the federated learning Docker applications shall be made open source and open access on a publicly readable software repository (i.e. GitHub). This is to make any statistical methods used on COS data to be fully transparent and fully auditable by anyone. B) Only Docker applications that are digitally signed, independently tested and approved as free from malicious contents are allowed to be distributed through the STRONG-AYA network and executed on the partners’ devices. C) Technology partners IKNL and UNIMAAS will provide Standard Operating Procedures for developing, certifying, testing and approving Docker applications to the STRONG-AYA consortium for approval and enforcement. Note : The purpose of enforcing a minimum threshold of 10 is to make it greatly more difficult to re-identity any particular human subject from the summary statistics or the modelling results alone. If any partner’s dataset contains less than 10 subjects for any federated statistic or federated model, this partner’s entire data shall be reported as if “missing in its entirety” for the purpose of that summary statistics or that particular model. This threshold can be raised or lowered, but only at the infrastructure-wide level and only with the agreement of the whole consortium. STRONG-AYA – No. 101057482 – D3.3 19 D) Approved Docker applications for federated analysis/learning within the STRONG-AYA consortium shall be placed in a private protected Docker applications repository (a.k.a. “STRONGAYA Algorithm Store”). 9 Secure web infrastructure – The pan-European ecosystem To carry out the tasks required in the STRONG-AYA project along the requirements set out in this document, the consortium needs a software technology that is trusted, well-maintained and proven to have been successfully used to date among clinical institutions for the purpose of clinically-related or epidemiologicallyrelated research. Technical Requirement 12: Software infrastructure Vantage6 STRONG-AYA shall use the open-source Vantage6 (priVAcy preserviNg federaTed leArninG infrastructurE for Secure Insight eXchange). Technology partner IKNL oversees the software management for the STRONG-AYA version(s) of the Vantage6 code. Standard Operating Procedures shall be provided to the STRONG-AYA consortium for installing and updating the required software. Technology partner IKNL publishes and updates a Software Management Plan at regular intervals, as stated by the Netherlands eScience Centre guidelines on sustainable software, on behalf of the STRONG-AYA consortium. This Software Management Plan shall be open access and accessible via a publicly readable web page managed by the consortium. Technical Requirement 13: Use of third party secure aggregation to enhance safety STRONG-AYA shall implement a “trusted third-party secure aggregator” methodology for federated analytics and federated learning based on Vantage6 software infrastructure. Technology partners IKNL and UNIMAAS shall take software design steps to ensure that : a) There shall be no direct partner-to-partner web network connections permitted by the Vantage6 infrastructure. b) Only signed, tested, certified and approved Docker applications taken from one designated “STRONG-AYA Algorithm Store” will be permitted to be sent out and executed by the devices of the partners. c) The Vantage6 software shall have active in-built protections that prevent transmission of any summary statistic or modelling result from an institution device that has less than 10 subjects (subject to change by ruling of the consortium) for a particular summary statistic or particular model fitting. d) Even though no individual patient data will be transmitted, nonetheless partners IKNL and UNIMAAS shall have industry-grade web message encryption turned on during federated analysis and federated learning processes running on the network. Technical Requirement 14: Services supported by subcontractor As stated in the original project plan submitted to the funding body, technology partner Medical Data Works has been sub-contracted by UNIMAAS to host a “trusted third-party secure aggregator” machine on their protected cloud services for use by the STRONG-AYA consortium. Medical Data Works will oversee the registration of institutions, users and researchers to access the this secure web infrastructure. STRONG-AYA – No. 101057482 – D3.3 20 Medical Data Works further ensures that network connectivity, user authentication, web applications and other processes that pass via the secure central aggregator conforms to the Secured Hypertext Transfer Protocol (HTTPS) web industry standards. Figure 2: Diagram explaining the general steps involved in federated learning (federated analytics works in a very similar way, but it might not require the steps 2 and 3 to be repeated multiple times). Image source : The Open Data Institute “Federated Learning” (Creative Commons Attribution Share-Alike 4.0 International License) To participate in a federated task, devices controlled by each STRONG-AYA partner institution device needs to be actively connected to a central coordination device that acts as a statistical aggregator. The aggregator tells the connected devices which computation to execute, e.g. calculate a summary statistic or fit a regression model. Computations that are verified and approved by the STRONG-AYA consortium will be packaged as digitally-certified Docker applications. The nodes execute the requested computation as a Docker application, only on the local dataset inside its own virtual machine. The aggregated result of the computation (not the data) is communicated to the central aggregator. The central aggregator collects the local results from each node, and by itself computes the global result. When needed, e.g. fitting a regression model, the above process has to iterate and update many times, until a single convergent global model emerges. STRONG-AYA – No. 101057482 – D3.3 21 Appendix: FAIR data In STRONG-AYA, we expect that schema, definitions and terminologies are quite likely to change over time. With rigid database designs, the databases generally need to be taken down and re-built to accommodate structural changes. This will not be an optimal idea for STRONG-AYA, since we are fully expecting our datasets to grow and extend, as we learn more and more with each other. Also, we anticipate that a small number of present and future STRONG-AYA members might not have a fully developed internal data workflow, combining clinical case report forms, electronic health records, treatment verifications systems, etc. It would seem at present to be highly resource intensive to impose a fixed schema on a partner, unless they just happen to be already collecting data in that format. Furthermore, present and future members of STRONG-AYA participate in many simultaneous projects, thus it becomes unwieldy to maintain a snapshot of their data in many different schemas due to their many different projects. Figure 3: Different data collection paradigms: warehouses, lakes and lakehouses (left to right) Similarities and differences among data collection paradigms are illustrating in the above diagram : (Left) traditional data warehouse, (middle) unstructured data lake, and (right) data lakehouse. The unique possibilities in a data lakehouse are : (1) over time, we can build data collection in such a way as to use different types of data, (2) by adding metadata annotation and governance processing on top of the data it would be possible to make the underlying data FAIR, and support automated retrieval from the data, and (3) a range of applications such as business reports, data analytics and epidemiological modelling can be built above the FAIR data. The institutional data workflows inside a given STRONG-AYA partner will (naturally) be unique and distinct from workflows elsewhere. However, we can expect that there will be some high-level kind of generalizations of the workflow. The figure below is only an example of a possible generalization, acknowledging that there will be many different variations of the theme. STRONG-AYA – No. 101057482 – D3.3 22 The principal data sources in STRONG-AYA consist of a wide range of mission-critical computer systems that collect data and store data (grey box). These systems control operations within hospitals, registries or interface with patients through some kind of electronic survey forms. STRONG-AYA does not expect to try to use all of this data, only the data that is part of the CORE OUTCOMES SET (COS). The task of the institution is to get the necessary permissions and approvals to extract COS-related data from these primary data systems, and bring the data into a protected research environment for the STRONG-AYA project (orange box). Along the way, there will be tasks requiring the help of Data Protection officers, IT experts, database experts and internal ethics review committees to get the data. Inside the protected research environment for the STRONG-AYA project (orange box) we will as a consortium install a set of software tools and safeguards to (a) make the data FAIR and mutually inter-operable within the consortium (b) store the metadata annotations that makes the data FAIR, and (c) to add a connectivity gateway so that summary statistics and epidemiological models that are computed locally can be communicated to a central aggregation server, which will put the many local results together into a single global result. Note that data stays inside the protected research environment (orange box) and no individual patient-level information is sent outside of this environment. Figure 4 Dataflow in STRONG AYA