dataesr/scientific-paragraphs-categorization huggingface dataset:
Step 2: raw data extraction Software databases include dozens of tables to store clinical data, but also software configuration elements, terminologies and logs. This step aims to discover the structures of the AIMS and PMSI databases, and to identify the relevant tables and columns that were extracted from operational databases and provided to the staging area for further transformations. For this step, we relied on experts in the field to understand how the records were documented, and what they reflected about patient care. Anesthetists and nurse anesthetists opened files individually to control records, and verify the concordance between the records in the database and the actual situation of the care.
Step 3: transform The transformation stage was the most challenging one as it aimed at transforming raw and heterogeneous data into a common and homogeneous data model. For this purpose, this step involved several operations: the record linkage between sources (i. e. linking the anesthesia record from the AIMS to the patient file from the PMSI), the mapping of local vocabulary to standardized concepts, the transcoding of modalities, the filtering of erroneous records, and the homogenization of the data structure. During this step, several data inconsistencies were addressed. First, missing or erroneous patient and stay identifiers were corrected. Secondly, the measurement and drug units were conversed to standard units (e. g. gram to milligram when both units are used for the same drug). Last, measurements and drugs administrations were flagged with a quality indicator documenting whether the value is expressed with a correct unit and whether the value is in the range of expected values.
Step 4: load A first part of the loading process is executed automatically every week. Master data are integrated in the dimension tables of the data warehouse in a first step of the loading process. An initial load was initiated at the start of the project, and these tables can be completed when new concepts appear in the applications (e. g. new parameters monitored in the operating room). Transactional data are loaded in the data warehouse following the master data, through two flows that are executed automatically every week. A first flow is related to low volume data that may have been updated in the AIMS (mainly patient history). The flow covers one year of background information and takes 6 h (flow 1). A second flow involves larger data that cannot be updated (i. e. automatically recorded measurements).
Step 6: pivoting and data mart constitution At the end of ETL process and feature extraction, the data warehouse is constituted of tables organized in rows, with one row per record. These records are data collected by the source software (e. g. drug administrations, procedures) or secondarily computed features. This organization is adapted for the loading of the data warehouse (with transactional or batch queries) but is not suitable for cohort creation because of the multidimensionality of the tables. Therefore, a pivot operation transforms row-oriented records into wide tables with one row per statistical unit and one feature per column (flow 4). As a result, the constitution of a data table to perform statistical analysis or data visualization will only consist in the application of filter and variable selection criteria.
Data quality and monitoring of the ETL process Data quality and ETL process were controlled and monitored by several methods. First, we implemented data quality checks to assess completeness, correctness, concordance and plausibility of records  [21]. These checks were implemented with SQL queries and were related to the presence of values, the detection of abnormal values (e. g. heart rate measurements outside the acceptable range), or the assessment of concordance between records (e. g. operating room date included during the hospital stay dates). They were first applied to the source databases, and then to the data warehouse after loading. Whenever necessary, a feedback to the anesthetists allowed to verify a record, and its concordance with the care. Secondly, based on inconsistencies and missing data found earlier, we defined a set of rules to improve the completeness of key events such as surgery and anesthesia steps  [22].
Summary after 10 years It required the involvement of one full-time person (the data scientist), along with help from the anesthesiologists to understand the clinical domain, and how AIMS was used. Two experienced computer scientists also provided expertise in ETL development and data warehouse modeling. All anesthesia procedures occuring after the 2010-01-01 were loaded into the data warehouse. Between 2010 and 2020, 636 784 anesthesia records have been implemented, for 353 152 patients. The Table  2  described the number of records per table. The data warehouse was deployed at the same time in all departments of the University Hospital. New features appeared over time depending on the studies that were conducted, and when a feature was developed specifically for a study, it was then made available to the whole perimeter of the data warehouse.
We presented the progress of the project throughout the last ten years at care unit and department meetings, and during thematic days (e. g. Regional Congress of Anesthesiology). The auditors were anesthesiologists, residents, and nurse anesthetists. The presentations included some technical points on the implementation of the data warehouse, but especially illustrations on its potential uses. We also emphasized the importance of properly documenting the procedure in the AIMS to have usable data. We conducted about 15 studies per year, in the perspective of medical theses. Several of these works have also been published. In addition to the standard time need for submission, review and editing of the manuscript, retrospective studies requires several weeks of work when the variables are simple and already available, to several months when it is necessary to develop new features.
Of the 387 included patients, 240 (62. 0%) had MINS14 and 166 (42. 9%) had MINS20. Both conditions were significantly associated with poor 2-year survival. Age, revised cardiac risk index, duration of surgery, pre-operative estimated glomerular filtration rate, and haemoglobin level were identified as independent predictors of MINS. In a third study, we formed two groups: (i) an anaphylaxis group of 49 patients with tryptase/histamine assay data and allergy workup, (ii) a control (hypotension) group of 555 patients with severe hypotension (i. e. mean arterial pressure less than 50 mmHg) with a cause other than anaphylaxis after anesthesia induction  [27]. The minimum ETco2 value was significantly lower in the anaphylaxis group than in the hypotension group. In multivariable analysis, minimum ETco2 was associated with anaphylaxis after adjusting for confounders and competing predictors, including arterial pressure, heart rate, and peak airway pressure.
Ethical and legislative barriers The access to and use of health data is regulated and subject to strict practices (E1). Legislation on the reuse of health data has evolved over the past few years. At the beginning of the project, the database had to be declared to the Data Protection Officer of the Hospital and to the CNIL, and each study had to be validated by an ethical committee. At the European level, legislation has evolved with the adoption of the General Data Protection Regulation in 2016. This regulation aims to strengthen both the protection of persons concerned by the processing of their personal data and the responsibility of those involved in such processing. Main requirements imply (i) the explicit and positive consent of the patient to the re-use of their data, (ii) the right to erasure, and (iii) the Privacy Impact Assessment.
Technical barriers The first technical barrier (T1) relates to the access to the source databases and the implementation of the data warehouse architecture, and in particular, the creation of a workspace to transform raw data. The second technical barrier (T2) concerns data quality and the data transformation stage of the ETL process. AIMS and PMSI suffer from a wide range of data quality problems that come from manual inputs, software settings that evolve over time, different data entry practices by person and department, monitors not connected to the software, etc. Moreover, crucial data may be missing and complicate the linking of multiple data sources. Last, data cleansing operations that have been put in place, and loading in its entirety, are complicated to evaluate and track because they involve millions of rows that cannot be checked manually.
Tips to address barriers and challenges We propose 8 tips to manage the barriers previously listed. They are decribed below and resumed in Fig. 4. Collaboration with the IT department to benefit from their strong knowledge of the hospital information system and to ensure that the architecture of the data warehouse was compliant with their requirements. We also had connections with software editors to understand the structure of the databases linked to their software. (Tip 1). Documentation and illustration of the data warehouse to educate on this new tool. Inform regularly on the progress of the project (e. g. what data is available), as well as the needs and difficulties encountered. Disseminate the use that is made of the data warehouse and the studies that have been completed. (Tip 2). Quickly arrive at a proof of concept and answer simple questions first with only a few variables, from demographic data (e.
Implementation of a common data model As it stood, the architecture of our data warehouse was suitable for local use only, because of a data format and vocabulary that were based on our software or the configuration that we had set up in Lille. The methods and tools we had developed could hardly be shared with other centers and therefore, recently, we have transformed our data to implement them into the Observational Medical Outcomes Partnership (OMOP) common data model (CDM)  [28]. The OMOP-CDM provides standardized table and column names, as well as a unified vocabulary  [29]. A set of tools and methods are provided and shared with the model, and we were also able to share some of our work  [30]. OMOP CDM continues the Inmon architecture, with a warehouse as a the unified data source. It continues the Inmon architecture, the data marts are only constituted in a second step, to build the data tables for each cohort.
To align with the OMOP model, the passage in the operating room was considered as a VISIT_DETAIL record, in the same way as a stay in the intensive care unit or a passage to the emergency room. All other events and data resulting from the OR, i. e. drug administrations, anesthesia and surgery steps, measurements, have been placed in the appropriate tables, i. e. DRUG_EXPO-SURE, PROCEDURE_OCCURRENCE, OBSERVATION and MEASUREMENT. The link between these records and the passage in the operating room was maintained through the foreign key column VISIT_DETAIL_ID in each of these tables. Local vocabularies were mapped to the standard vocabularies recommended by the OMOP community, i. e. SNOMED (Systemized Nomenclature for Medicine), UCUM (Unified Code for Units of Measure), LOINC (Logical Observation Identifiers Names and Codes), RxNorm, ICD10.
Federated learning In order to gather sufficiently large data sets, it is often necessary to set up multicenter studies; yet, centralization of records can be difficult, either for practical, legal or ethical reasons. As an alternative, federated learning enables leveraging multiple centers' data without actually collating them  [32]. The data warehouse is an excellent tool to promote federated learning, especially if the data warehouse model is the same in the different centers. In this case, the cohort creation queries can also be shared, upstream of the statistical analysis scripts. We performed a proof of concept with a dataset of caesarean sections under spinal anaesthesia clinical we split among 4 hypothetical centers and tested an algorithm for logistic regression, including confidence intervals computation  [33].
Discussion In this article, we reported the development, implementation and use of an anesthesia data warehouse in a French university hospital. We highlighted the difficulties encountered during the conduct of this project, and we tried to provide advice to handle them. The development of our data warehouse started 10 years ago and lasted 4 years. It is loaded on a weekly basis and currently includes data related to more than 600 000 anesthesia procedures. It covers all events occurring in the operating room, as well as the hospital stay and the related diagnoses and medical procedures. We also integrated biology results, transfusions, a mortality database, and manually collected data. In addition to the raw data, it was necessary to extract features in an automated way, generally by applying rules defined by domain experts.
The data warehouse has permitted us to perform one hundred and twenty retrospective studies for resident works, and for some publications  [25] [26] [27]. The difficulties often put forward with this kind of project are mainly technical, and are linked to the volume of data and poor data quality, which generally result from manual entries or lack of documentation. However, the fact remains that the human and organizational aspects are often the most difficult to overcome. The implementation of such a project requires the articulation of several disciplines and skills. At the start of the project, we implemented our own data model. Now, we have moved to the OMOP CDM to be able to collaborate more easily with other centers, and share our tools and methods. The next step of the project is to share our experience and tools to help other centers for developing their own data warehouse and implementing the OMOP CDM.
We are currently collaborating in this sense with several French university hospitals. Another area for improvement in the project is the implementation of federated learning in routine, in order to conduct multicenter studies. We are also currently working on providing open access to our data warehouse, on the same way as the MIMIC project and the open-access databases of Physionet  [35]. This is a real challenge in regard to local and European laws. Last, the data warehouse must also provide physicians with feedback on their activity, and assess the compliance with clinical guidelines resulting from clinical research.
Introduction Epidemiologic disease surveillance, defined by the World Health Organisation (WHO) as "the systematic collection and use of epidemiologic information for the planning, implementation, and assessment of disease control"  [1, 2] , consists of data collection over a specific period of time and providing prompt feedback to healthcare administrators in order to adjust health policies accordingly. In many public health systems, the major pillars of epidemiologic surveillance are mandatory disease reporting and sentinel surveillance networks  [3]. Supplemental data are also collected from more modern tools that are Open Access BMC Primary Care *Correspondence: andrew. meci@iplesp. upmc. fr 1 INSERM, Institut Pierre Louis d'Epidémiologie et de Santé Publique, IPLESP, UMRS 1136, Sorbonne Université, F75012 Paris, France Full list of author information is available at the end of the article used in tandem.
These tools include administrative databases  [3] , drug sales data  [4] , and participatory syndromic surveillance  [5]. Sentinel epidemiologic surveillance relies on dedicated healthcare investigators, often in general practice, who report real-time data on specific health indicators. The objective of this type of surveillance is the early detection of unusual patterns of disease activity, estimation of the burden of disease in the population, and comparison of disease trends with historical data using data that is consistently collected by dedicated reporters using set case definitions  [1, 3, 6]. Differences between sentinel networks include the health indicators monitored, representation of populations covered, types of reporters, methodologies for data collection and analysis, case definitions, and frequencies of reporting.
Additionally, epidemiologic surveillance based on primary health care providers acting as sentinel investigators has significantly evolved over the past decades, particularly due to the advent of electronic medical records (EMR) and the advancements in automatic data collection based upon electronic record frameworks. Inter-network cooperation has long been described as essential at the European level  [14] , especially for comprehensive flu surveillance  [20]. An updated inventory on a global scale would expand upon past works and take a step toward this necessity. For this purpose, the Sentiworld project was launched in 2016 with the objective of creating an inventory of sentinel surveillance networks in general practice at a global scale and providing a public online platform that shares collected network data.
Online questionnaire Identified potential GP sentinel networks were invited to fill an electronic survey in English. The questionnaire was generated on the LimeSurvey platform and distributed by email. This survey gathered descriptive information from each network in categories such as: organization (date of creation, name, support structure, main contact information), investigators (medical specialty, number, tasks carried out for the network, compensation, representation), epidemiological surveillance (monitored indicators, frequency and collection method, frequency and method for transmission data), data availability, and data accessibility for use in collaboration with other organizations nationally or internationally. In cases of data gaps, we reached out directly to networks for additional information or clarification.
Data collection for sentinel surveillance purposes has evolved over time. Networks have trended from paper forms to electronic resources like dedicated websites and software. In recent years, with the wider use of EMR, sentinel epidemiology has trended towards the use of direct, automatic data extraction from these records to be used in tandem or in place of traditional sentinel collection mediums  [30, 31]. In theory, EMR systems make many improvements over traditional reporting methods, as they provide data on more patients in a longitudinal sense and on more indicators  [30]. Access to EMR data is also more rapid and has been shown to reduce the risk errors in disease surveillance  [32]. We have found from our own data that EMR data collection does in fact have a strong positive correlation with the number of indicators surveyed, the surveillance of non-infectious indicators, and non-infectious indicator surveillance.
This is likely because of the larger scope of data contained within EMR. EMR surveillance data is also better standardized than traditional sentinel data and thus could be a solution to homologizing sentinel surveillance, given the diversity of networks included in the Sentiworld study. However, EMR data collection cannot be a fix-all solution to all gaps in sentinel surveillance nor in international collaboration, as EMR data collection is also complicated in places where many private companies control medical data with data systems, coding or diagnoses are unstandardized, or data that is unsuited for epidemiological modelling. Our results show that sentinel networks, despite all existing in general practice, appear to be heterogeneous. It is thus crucial to understand the differences between nations in healthcare management, in the laws and practice of general medicine, and in population health habits  [33]  when engaging in global health collaborations.
This idea held true certainly at the start of the Sentiworld project in 2016 and does so even more in 2021, amidst the worst public health crisis in a century, COVID-19. In this time, we have seen unprecedented collaboration among healthcare professionals, researchers, and surveillance systems across borders and continents  [34]. With sentinel systems necessary to supplement research and mandatory surveillance data in the context of infection management, policy decisions, and vaccine monitoring, we are again confronted with the barrier of heterogeneity between systems. Our cartography allows networks to learn more about each other, which bridges many gaps in information that previously existed and allows for potentially greater inter-network cooperation. One of the major strengths of this study is that it is the first of its kind in many respects.
Further, Sentiworld data and its website can be used as a tool for communication among sentinel networks. Understanding differences between sentinel networks could allow for easier sharing of data in future studies and when dealing with public health crises. In fact, correspondence that took place for the Sentiworld study later led to the formation of a small working group of eight sentinel surveillance networks in seven European countries in 2020. The group was later able to collaborate on early COVID-19 research on initial risk perception and sentiments of preparedness among primary care physicians regarding the COVID-19 pandemic  [35].
Participants A total of 125 community-dwelling older adults were first recruited and assessed for eligibility. Thirty participants did not meet inclusion criteria at the time of enrollment, resulting in 95 participants being randomized to each of the three training arms. A total of 17 participants abandoned the intervention voluntarily before its completion (6 from EF: study too demanding = 1, sickness/health issues = 2, no longer interested = 2, too many absences = 1; 6 from AE: study too demanding = 1, sickness/health issues = 2, no longer interested = 3; 5 from GMA: study too demanding = 1, sickness/health issues = 2, no longer interested = 1, involved in another parallel study = 1). Due to data-registration issues concerning the dual-task data for the first six cohorts, we have opted to report only the data for the subsequent cohorts after the problem was addressed.
This resulted in a subset of 33 participants (EF = 10, AE = 10, GMA = 13) that were included in the present analyses (see Figure  1  for CONSORT diagram). There were no significant differences between groups in terms of attendance and drop-out rates, suggesting similar adherence across groups. There were also no significant differences in the participant characteristics between participants who had complete data and were analyzed for this study compared to participants who had missing data (see Table  1 ). Finally, results from Little's MCAR test showed that the data were missing completely at random, χ 2 (21) = 23. 40, p = 0. 323. These findings suggest that the subset of participants is representative of the full dataset and that the data are not biased. A statistical power analysis was performed for sample size estimation, based on published data  (Fraser et al.
Each walking trial was initiated by the audio signal, "GO," heard through wireless headphones, and ended with the audio signal, "STOP. " Each trial lasted 30 s. The distance walked was manually recorded and divided by 30 s to attain a measure of gait speed (m/s). Dual-Task. Participants completed the 2-back cognitive task while concurrently walking at a self-selected pace. They were instructed to perform both the cognitive and walking task equally well. Values indicate means and standard deviations in brackets. There were no significant differences across training groups, suggesting that randomization was appropriate. There were no significant differences between participants included in the main statistical analyses and those who were not due to missing data, suggesting that the participant characteristics of the smaller dataset are representative of the full dataset.