dataesr/scientific-paragraphs-categorization huggingface dataset:
Discussion The present study aimed to explore several facets of the in situ Fig. 4. Ancestral state reconstructions of traits evolution performed on the dated 50%-majority rule consensus tree. (A) Body size (snout-vent length (SVL)) evolution reconstructed with the R package phytools on the dataset including SVL measurement of P. menamainty as a proxy for the genus Pseudoacontias (Supplementary Table  S11 ). The bars on the right represent SVL values of each species. (B) Fossorial lifestyle evolution reconstructed with the R package hisse. States are coded as follows: fossorial (white), non-fossorial (black) (Supplementary Table  S13 ). diversification (diversification rate, phenotypic evolution, and biogeography) of Malagasy scincine lizards. Based on diversification trends frequently observed in evolutionary radiations and especially in insular systems (e.
Systematics and time-tree In contrast to previous published phylogenetic hypotheses  (Whiting et al. , 2004; Schmitz et al. , 2005; Crottini et al. , 2009; Miralles et al. , 2015; Erens et al. , 2017) , the monophyly of major clades and their phylogenetic relationships received full support (Fig. 2 ). This was likely the result of a more complete data matrix, both in terms of a broader range of taxa and additional molecular loci included. However, the short internodes between Clade B genera might indicate that even a larger multi-locus dataset (e. g. , obtained by a phylogenomic approach) will be needed to reconstruct evolutionary trajectories in the context of a rapid inter-generic divergence. This seems to be confirmed by the difficulty in retrieving well-supported phylogenetic hypotheses using alternative inference methods (see 3.
1 Phylogenetic hypothesis). Compared to previously published phylogenies, most differences are related to inter-generic relationships within clade B. Amongst these, the most remarkable are the recovery of the genus Grandidierina as the sister lineage to the clade containing Amphiglossus, Brachyseps, Flexiseps, Pygomeles, and Voeltzkowia (similarly to the phylogenetic hypothesis proposed in  Schmitz et al. , 2005) , and the recovery of the genus Voeltzkowia as the sister lineage to the clade containing Amphiglossus and Pygomeles. This work also included 21 candidate species, some of which were molecularly characterised for the first time (Supplementary Tables  S2-S3 ). Amongst these, Madascincus sp. CaNew from Betampona   S15 ) were coded with the R package speciesgeocodeR based on Madagascar's bioclimatic classification modified from  Yoder and Nowak (2006)  (sub-arid spiny thicket (a, blue), sub-humid forest (b, light blue), dry deciduous forest (c, green), montane thickets (d, yellow), and rainforest (e, red)).
, 2020) , limiting the use of fossil calibrations in dated phylogenies. To circumvent this limitation, either secondary calibrations from existing large and dated phylogenies (e. g. , as from  Crottini et al. 2012; Zheng and Wiens, 2016)  or fossil data from outside Madagascar to calibrate selected outgroups could be used (as in  Blair et al. , 2015; Burbrink et al. , 2019). We chose to use primary fossil calibrations on the outgroups of a reduced dataset (Supplementary Table  S5 ) and used the resulting divergence time estimates of the ingroup crown age as secondary calibration on the full dataset. This approach received high statistical support and produced low uncertainty in the estimated divergence times (Fig. 3A ), as also demonstrated by the consistency of our time estimates with estimates available from other dated phylogenies that used different calibration points (e.
, 2017). This suggests that a major change in Malagasy biota is concordant in time with the decreasing diversification rate observed for Malagasy Scincinae. Considering that most species of this group are forest dwellers  (Glaw and Vences, 2007) , the hypothesised expansion of grasslands may have had a significant impact on their diversification. A recent decline in diversification rates might also be consistent with a protracted speciation model  (Rosindell et al. , 2010)  whereby recent speciation events might not have reached a sufficient level of differentiation to be reflected in current taxonomy. However, lineages included in the phylogenetic dataset were identified based on the interspecific genetic distance thresholds proposed for Malagasy skinks  (Nagy et al. , 2012 ; see 2. 1 Samples and dataset; Supplementary Tables  S2-S3 ).
Acknowledgements We thank the  Ministère de l'Environment, de l'Ecologie et des Forests (now Ministère de l'Environnement et du Développement Durable)  for issuing research, collection and export permits that enabled the compilation of the dataset used in this study. The numerous samples analysed in this study have been assembled over many years with the help of several colleagues whom we would like to acknowledge and especially  Gonçalo M. Rosa ,  Jean Nöel ,  Jean Honoré Velo ,  Honoré Lava ,  Georges ,  D. James Harris ,  Daniele Salvi ,  Emanuele Scanarini ,  Miary Randriamialisoa ,  Stefano Faravelli ,  Vincenzo Mercurio ,  Fabio Mattioli ,  Devin Edmonds ,  Iker A. Irisarri ,  Alexandra Lima ,  Solohery Rasamison ,  Andolalao Rakotoarison ,  Emile Rajeriarison , and  Anicet Haza. We are furthermore grateful to  Jan Hackel  for support in the interpretation of biogeographic results.
Funding Portuguese National Funds through FCT ( Fundação para a Ciência e a Tecnologia ) supported this work with the projects  UIDP/50027/2020  and  PTDC/BIA-EVL/31254/2017. FCT also funded the contract grant to AC [ 2020. 00823. CEECIND/CP1601/CT0003 ], the PhD fellowship of  FB [PD/BD/128493/2017 ] and  WC [SFRH/BD/102495/2014 ], and the post-doctoral fellowship of JMP [SFRH/BPD/111015/2015]. AV is funded by the  Agencia Española de Investigación , with a  Juan de la Cierva-Formación grant  [ FCI2019-039443-I/AEI/10. 13039/ 501100011033 ]. AA acknowledges financial support from the  Swedish Research Council  [ 2019-05191 ] and the  Royal Botanic Gardens, Kew. DS received funding from the  Swiss National Science Foundation  [PCEFP3_187012] and from the  Swedish Research Council  [VR:  2019-04739 ].
Federated learning initiatives in healthcare are being developed to collaboratively train predictive models without the need to centralize sensitive personal data. GenoMed4All is one such project, with the goal of connecting European clinical and -omics data repositories on rare diseases through a federated learning platform. Currently, the consortium faces the challenge of a lack of well-established international datasets and interoperability standards for federated learning applications on rare diseases. This paper presents our practical approach to select and implement a Common Data Model (CDM) suitable for the federated training of predictive models applied to the medical domain, during the initial design phase of our federated learning platform. We describe our selection process, composed of identifying the consortium's needs, reviewing our functional and technical architecture specifications, and extracting a list of business requirements.
We review the state of the art and evaluate three widely-used approaches (FHIR, OMOP and Phenopackets) based on a checklist of requirements and specifications. We discuss the pros and cons of each approach considering the use cases specific to our consortium as well as the generic issues of implementing a European federated learning healthcare platform. A list of lessons learned from the experience in our consortium is discussed, from the importance of establishing the proper communication channels for all stakeholders to technical aspects related to -omics data. For federated learning projects focused on secondary use of health data for predictive modeling, encompassing multiple data modalities, a phase of data model convergence is sorely needed to gather different data representations developed in the context of medical research, interoperability of clinical care software, imaging, and -omics analysis into a coherent, unified data model.
Introduction The lack of availability of high-quality datasets comprising large volumes of data represents a significant limitation to the training of machine learning models in the healthcare domain. One solution to this problem, the pooling and integration of datasets from multiple centers, is often met with a strong resistance in the healthcare setting. In addition to the ethical, motivational, and economic barriers preventing data sharing, a review identified legal barriers such as privacy protection, political barriers such as lack of trust, and technical barriers such as a lack of widely adopted sharing solutions  [1]. These barriers are exacerbated in the context of rare disease research, where datasets are small and thus more easily identifiable, and integration of multiple data modalities (genomic, phenotypical, demographic, medical history, and others) is often required.
Recently the Federated Learning (FL) paradigm has gained popularity as a means to overcome such limitations by providing a scalable, privacy-preserving approach to the joint training of machine learning models across federated health data repositories  [2, 3]. The core idea behind FL is that instead of sharing data, different centers only need to share the parameters of the machine learning model being trained. FL has been a very active research topic for several years, producing major advances in the fields of platforms, security and models. Recently FL has been applied to the healthcare domain and life-science industry, leading to international initiatives that are now reaching a first maturity level allowing deployment at scale. The GenoMed4All consortium aims to achieve one of the first international implementations of a FL platform for clinical and -omics rare disease data.
However, the current challenge that the consortium faces is the systematic lack of standardized protocols for interoperable data and lack of FAIR data principles (Findable, Accessible, Interoperable, Reusable) in the biomedical data community. The multidisciplinary nature of GenoMed4All requires the strict cooperation of different communities, including clinical medicine, data science, engineering, legal, and data privacy. In order to protect and disseminate such valuable information and to mitigate the risk of building a tower of Babel, the GenoMed4All consortium, created in 2021, has put significant preliminary efforts to understand the current state of the art on data interoperability and consented reutilization of data of genetic and phenotypic origin in a FAIR way, utilizing specialized strategies to facilitate the sharing of clinical data and support the FL paradigm.
This process culminated in the definition of the requirements for a project-wide Common Data Model (CDM), an abstract representation of the structure of the data, rather than of the data itself, aimed at explicitly conveying and formalizing the organization of the data and the relationships among data elements via the specification of a machine-readable, codified format. In this article, we present the methodology and the outcomes of our data modeling effort, based on identifying a list of requirements specific to our project which allowed us to study and compare three widely used and highly standardized candidate data models: OMOP, FHIR and Phenopackets. We share the key challenges and lessons learned in the process of designing a model for multimodal healthcare data with the goal of supporting the federated learning paradigm.
Ultimately, we hope that our work may be transferable to similar efforts in the future, enabling new initiatives to build on top of our experience. This paper is structured as follows: in the Materials and Methods section, we present our journey towards the definition of a data model for the GenoMed4All platform through a process of reviewing our implementation plans, eliciting requirements, and selecting a CDM from the available international standards, thus roughly following our chronological order. We begin by establishing the motivation for a CDM in our consortium; then we present our functional and technical platform architecture focusing on the data flows, Artificial Intelligence (AI) functionalities and technical design choices related to the CDM; building on this knowledge, we elicit a list of business requirements from all stakeholders; finally, we evaluate the three candidate models based on this list of requirements.
We may distinguish standards: • for improving the connection between health research and care delivery, such as the HCSRN-VDW  [6]  and the CESR-VDW  [7]  common data model; • focused on simplifying the sharing of data, for example HL7 clinical documents Architecture (CDA)  [8] , medical records  [9] , medical imaging information  [10] , or for the pharmacovigilance use case  [11, 12] ; • for facilitating data exchange between different health systems like FHIR  [13] ; • Designed to map electronic medical records as part of medical insight and research data hubs, and/or for mapping and collaboration of datasets like OHDSI OMOP  [14] , i2b2  [15] , PCORNET  [16]  (patientreported and payor data for research) or even FHIR (considered as a data warehousing standard); • Specialized into acquisition, archive and interchange of metadata and data for clinical research studies like CDISC  [17].
• Those specialized in genomic data collection, storage, analyzing, and sharing representation and sharing like SAM/BAM, VCF, and Phenopackets endorsed by the Global Alliance for Genomics and Health (GA4GH)  [18]. In spite of the abundance of specialized data formats, reutilization of medical data for clinical research purposes is still a rare occurrence  [19] , especially in the case of predictive analytics and machine learning  [20]. Moreover, these different standards are covering distinct functional domains, which raises the problem of a mature CDM covering clinical, imaging and -omics data types. Out of those models, within the GenoMed4All project we identified three CDM candidates based on our experience and expertise, that have been demonstrated to support predictive analytics including genomic data: FHIR, OMOP-CDM and Phenopackets.
The HL7 Fast Healthcare Interoperability Resources (FHIR) is one of the most robust and complete healthcare data persistence and exchange specifications that support full semantic interoperability. FHIR has already been successfully demonstrated in a federated learning medical application  [21]. The Observational Medical Outcomes Partnership (OMOP) CDM  [14]  is one of the most widely used CDMs in the life sciences community and has been demonstrated to facilitate ML-based oncological studies  [22] , clinical predictive modeling  [23] , and other ML-based analysis  [24]. While neither standards were developed with a specific focus on genomics, both have been extended to -omics data  [26, 27, 28]. Conversely, the Global Alliance for Genomics and Health Steering Committee (GA4GH) approved Phenopackets as a format specifically designed to integrate genomic and phenotypic information  [25].
This process is executed iteratively multiple times until a satisfactory level of convergence has been reached. The main feature of this approach is that the only information being exchanged are the models' parameters. The purpose of the GenoMed4All project is to build a platform enabling data scientists to conduct FL experiments leveraging the network of medical Sources of Records (SoR) within the consortium. In what follows, we present the outcomes of our preliminary requirements gathering, identification of design principles, and technical infrastructure proposal, which are guiding the beginning of the implementation efforts currently underway. Several details, especially regarding the technical implementation, have not yet been fully fleshed out. The implementation of the GenoMed4All platform will be carried out in a multi-phase approach.
Motivation for a common data model The large heterogeneity in data representations and semantics across SoR leads to unnecessary complexity in the analysis, reuse, and interpretation of data in health research. A well-established approach to overcome this issue relies upon a Common Data Model (CDM), a collection of rules which standardizes both the structure and the semantics of disparate datasets through the use of ontologies, coding systems, and formal documentation. During the preliminary design phase of the functional and technical architecture for GenoMed4All, we realized how much even the simple issue of justifying the need for a CDM for federated learning platform requires careful analysis and a tight interdisciplinary collaboration. Using a CDM does not come for free: it requires training software developers and data analysts, significant levels of expertise and domain knowledge, and a considerable initial development effort.
Data modeling for federated training of AI models The interaction between data modeling and the training of learning algorithms is an evolving subject of exploration as it must align two communities with their own practices and tools: AI researchers and IT platform integrators. To the best of our knowledge this topic has not been extensively analyzed in the healthcare domain (for example the IHE AI interoperability in Imaging white paper  [41]  provides limited indication for data/AI model interaction). In the GenoMed4All project this topic has been addressed both during the model development and training phases.
Model development phase Data scientists in the consortium have identified a need for a preliminary model development phase in which a subset of the data is centralized an made available to them. A dataset anonymization and preliminary analysis is usually performed in this phase prior to entering the research phase. At this stage, the datasets delivered to data scientists are very often not aligned to a CDM. After the data is made available to the data scientists, there are more challenges to be solved in order to develop an ML-based model and provide an automatic application of the whole process, such as e. g. the choice of the ML algorithm, which strongly depends on the data, and therefore on the data model. We expect that higher heterogeneity of the features considered in the datasets corresponds to more complex relationships among these features, fostering the usage of ML-based solutions.
The model training data flow The diagram in Fig. 2  presents the data flow orchestrated by the FL platform at the edge. The training descriptor, described in the previous paragraph, is used by the integration pipeline to configure the data flow execution. It is also used by the FL edge model trainer to control and perform the model training. In this flow, the CDM ingests data from the different SoR after feature extraction for clinical images and genomic data, alignment on a single terminology and formatting into the CDM, and finally pseudonymization. Then the cohort extractor retrieves a dataset from the CDM and applies data normalization using a set of dictionaries to convert categorical data into the numerical data format for input into the AI model. A data quality check based on the training descriptor metrics is then applied, and if successful the model training plan can start.
Data transformations The data model MUST provide a uniform interface for accessing and querying data for the purposes of training federated AI models. The information contained in the data model after transformation MUST be at least equivalent to the information contained in the raw source data. Data transformations from the raw source to the AI training dataset SHOULD be as simple as possible. Data transformations from the data model to the training dataset COULD be disease-specific, algorithm-specific, and training plan-specific.
Data consumers and federated training The quality of the data exposed by the CDM for training predictive models MUST be at least as high as the quality of the raw input data. Given any training plan for an AI algorithm, the data model SHOULD be structured in such a way that simplifies the retrieval of all the records in the training dataset. in the sections above. Furthermore, a list of high-level data elements present at each SoR in the consortium was gathered to aid in identifying whether the shortlisted CDMs could indeed adequately represent the data (see Appendix "GenoMed4All: clinical demonstrators and available data"). The requirements were discussed in the context of group and individual interviews with the different domain experts in the consortium, including AI experts, clinical data providers, and software engineers, following a requirement engineering approach  [42].
Mapping data models to the requirements One of the main technical challenges that we encountered in the process of selection and design of the data model was to identify which available international standards best suited our needs. We present here a preliminary mapping exercise trying to identify whether the three data models under investigation are adequate in covering all data aspects that should be modeled within GenoMed4All. We expand on the "Data model design" row from the checklist in Table  2  and our prior work on gathering the requirements expressed in Table  1  to identify a set of dimensions to evaluate three commonly used standards for clinical and genomics data: FHIR, OMOP, and Phenopackets. Our first concern was to look at the expressivity of each model with the goal of making sure that all types of data may be adequately represented in the platform.
Comparison of data models Based on our coarse-grained preliminary analysis, all three data models were deemed generally capable of supporting all the clinical and genomics data requirements foreseen for the GenoMed4All project, as well as all the necessary processes for querying and transforming information required by the AI algorithms. We found more overlap in the Table  2  Data architecture checklist. We distilled the main points of discussion from our experience into a checklist of questions and recommended actions, to be used for future implementations of a data architecture based on a CDM in a federated learning platform in the healthcare domain.
Survey data providers to identify biases in patient demographics' distributions and data volumes. Conduct statistical analysis prior to the training of predictive models. capabilities offered by FHIR and OMOP, whereas Phenopackets, which has better expressivity for genomic data, has the disadvantage of not being able to adequately represent some common data types such as imaging or other -omics data. The complementarity of the three data models is particularly obvious in the specific case of representation of genomics data, where we highlighted some difficulties in mapping specific concepts to FHIR and OMOP. We report in Fig. 3  the hierarchy of genomics data needs for GenoMed4All  [46] : while FHIR and OMOP are better suited for highly processed genomics data and linking with other clinical data types, Phenopackets retains the ability to natively express raw sequencing data and linking it to specific phenotypical manifestations.
In general, all analyzed data models serve well as a layer of standardization for clinical research data within one's own research network. However, in case one wants to reuse and integrate a set of datasets in broader clinical research communities across different research networks, this requires a global data model as a reference standard to facilitate not only data model harmonization and data integration, but also easy data transfer and exchange. Towards this end, there has been an effort recently to combine several data standards in a single global common data model that will allow researchers to pull data from multiple sources and compile it in the same structure without degradation of the information. We believe that a combination of data models, as well as the implementation of Phenopackets within the FHIR or OMOP standard, will facilitate in better developing and improving the interoperability and standardization in genomics data.