dataesr/scientific-paragraphs-categorization huggingface dataset:
In HAI surveillance, denominator data are crucial for comparing infection rates in the local healthcare facility with other hospitals within or outside of the surveillance network. Together, the individual-level HAI state data and the denominator form the HAI surveillance result (Box 1). Although HAI surveillance can be implemented as part of a research project, this document is concentrated on implementation with the purpose of improving quality of care for patients in the clinical setting. Relevant terminology and abbreviations are defined in the Glossary. For organizational, governance and legal aspects of HAI surveillance and data sharing, we refer to the discussion of governance aspects of large-scale implementation of AS of HAI  [12] , also supplementary to the roadmap.
Healthcare data and standardization AS relies on reusing routine-care data from EHR. A highly divergent landscape of healthcare software is running in hospitals worldwide, leading to differences in routine-care data. Even if the software is produced by the same company, local adjustments usually result in differences in data structure. In some hospitals, there is no comprehensive EHR, or clinical data are unstructured or distributed across different subsystems. Moreover, these subsystems may apply different coding languages, further limiting their interoperability (section Standardization and interoperability). Implementation of AS requires substantial resources to collect and harmonize data between these sources, in particular if surveillance is intended to be implemented centrally. This is not a one-time investment but a continuous effort, as local data systems are continuously changing.
Structured and unstructured data Structured data are characterized by an identifiable format where the content is highly organized in a small and searchable data unit. Common examples of structured data in healthcare are admission/discharge data, ward type, diagnosis codes, procedure codes, some laboratory data like C-reactive protein measurements and vital parameters such as body temperature, all of which are assigned to a unique data type, each with a distinct meaning. This allows the data to be collected, interpreted and validated by algorithms easily and unambiguously. Unstructured data are recognized as not having a predefined format or organization and are commonly found as free text in EHR, for example doctors' or nurses' notes for patient symptoms. Analysis of unstructured data in AS usually requires transforming it into a structured format, a process that can be complex and resource intensive.
Minimal and health core data set The required source data for AS comprise a long list of variables and depend on targets of AS and the required algorithms. To facilitate the implementation of AS, a minimal data set (MDS) can be specified  [11]. These variables reside in different sources and information systems distributed over the hospital IT infrastructure. In general, for all fields of application where EHR data are used, the definition of a core data set (CDS) is an important first step for the requirement analysis. The CDS is an agreement by experts defining a set of variables required to apply health algorithms, including algorithms for AS. The CDS is designed as an expandable basic module collection with obligatory specifications, like structure and data type for all included variables.
It also reports useful international standards to represent the data (section Standardization and interoperability). Table  1  provides an overview of a health CDS, covering all dimensions of surveillance, not just those pertaining to AS. More detailed information is published by the Medical Informatics Initiative  [17]. When building an automated HAI surveillance system, the HAI source data can be organized within a HAI MDS, which is a subset of the CDS including only parameters required for detecting the HAI and the relevant denominator data. For all data in the MDS, the quality of data elements should be assessed. For this purpose, data can be classified into different categories with expanding criteria for accessibility/applicability in algorithms (Table  2 ). Category 5 applies to data without any digital representation, i.
Standardization and interoperability A core requirement for implementing AS is the homogenization of HAI source data format. Transformations of source data to standard format is usually performed by taking small steps at a time, and the choice of standards should be evaluated thoroughly. It is recommended to formulate and communicate a clear transformation strategy, managed by a higher-level organization, like the coordinating centre. These could include e-health initiatives, but a key factor to speed up the overdue process of standardization in digital health is to encourage political legislators to implement mandatory rules that every software company has to fulfil. Valuable information to guide this process can be obtained by looking at similar solutions used by other countries  [18]  or used at the European level  [19].
Syntactic and semantic standardization are the key concepts to practical interoperability. Syntactic interoperability defines the transmission techniques for data, and semantic interoperability is important for unambiguous machine-based understanding and the interpretation of data. Standardization should be achieved at the earliest possible point of data creation. This defines the responsibilities of the companies/departments developing systems in which data are registered to reduce errors and the misinterpretation of data. Ideally, all data which are exchanged between different systems in a hospital setting (involving internal and external computer systems) should be standardized to avoid misinterpretation. Some existing AS systems use their own defined standards for specific data sets, such as the MiBa (the Danish microbiology database) and the German surveillance network Antibiotika-Resistenz-Surveillance (ARS).
The MiBa collects all microbiology findings from all clinical microbiology departments in Denmark, coordinated by the responsible national governmental agency, Statens Serum Institute, and defined by a standard transfer protocol, called MedCom XRPT07  [20]. Because the local data providers use different identifications for pathogens and other data elements, they established a mapping mechanism to convert from local codes to shared codes. Ideally the source data and/or HAI surveillance result transferred from hospitals to the coordinating centre should be in an international accepted standard format. Data can be transferred using tools like openEHR or ART DECOR as CDA (clinical document architecture) templates or using fast healthcare interoperability resources (FHIR). To standardize the definition of HAI source data and HAI surveillance results, they have to be specified in iteration with stakeholders and domain experts.
Simple algorithms have the advantage of being easy to understand, thereby increasing acceptance among users; most of the time, a simple rule-based classifier provides satisfactory results. When applied in production, algorithms are usually run in regular time intervals, such as once every 24 hours, once a week or in larger batches. In most circumstances, it is not required that data are being updated in real time. Simpler rule-based classifiers can be written in any language supported in production (e. g. Java, PL/SQL, Cþþ, C#, SAS, R or Python). Specific medical-focused programming languages like Arden syntax could strengthen the exchange of programming code and the common understanding of the algorithms.
Box 2 Barriers in introducing e-health standards. In general, the laboratory information system uses some structure in their databases, but these are not converted to standards like SNOMED CT or LOINC. If possible, proprietary standards developed by commercial companies should be avoided because licensing can be an issue. For most standards, there are open source solutions available. However, SNOMED CT, which comes with a licence cost, is mostly chosen because of its complexity and integrity. Because codes are not static but always changing, updates require attention. As an example, the ICD codes are updated annually, and all data sources must also receive these updates, which can be a time-consuming process. Similar problems arise if the hospital decides to update from HL7 v2. x to FHIR and all communicating systems have to be adapted.
window (e. g. symptom data are considered only when linked to a drawn culture or after a surgical procedure)  [25]. Some variables could have zero to many measurements during the time window, and it needs to be determined what value to use (e. g. most serious value, latest value, mean value, all values). In EHR, missing data are common, and attempts to address this should take into account the underlying reasons for missing data to avoid biased results  [26]. Determining data quality is crucial and needs to involve domain healthcare experts. Even though the EHR may contain features e such as tick boxes for device presence or functionalities to register movements between different wards e healthcare personnel may still not use them in the intended way, despite clear guidelines. Not addressing these issues may severely bias algorithm output.
Hospital subsystems Many hospitals are overwhelmed by multiple IT systems. Depending on a specific hospital's IT architecture, the source data required are usually distributed among different subsystems. There are several available solutions; the IT architecture can be more or less integrated or connected via communication servers. In this wealth of systems, it is important to realize that similar data may be stored in several systems. In addition, data content is sometimes 'vendor locked' and not accessible, or some data may still be stored on paper. The design of IT systems is influenced by local preferences, possibilities offered by vendors and, if applicable, regulations that enforce specific data standards or protect data privacy. The main component is usually the hospital information system or EHR, which is often the main system accessed by healthcare professionals.
Clinical data repository in hospitals Routine-care data, consisting of clinical and administration data, are transferred from hospital subsystems into a clinical data repository (CDR), a storage domain including multiple databases and concepts. The CDR includes operational data stores (ODS) for fast writing of real-time data out of clinical data sources and clinical data warehouses (CDW). The CDW are optimized databases for performance of specific fast queries  [28]. Different architectures of CDW can be implemented, with the classical CDW including the EHR data and all administrative data, as compared to a research CDW, which has additional functions like patient deidentification for external receivers  [29]. Generally, the ODS are source data for the CDW. In addition, data such as microbiologic findings may be transferred from the LIS to the hospital information system and additionally to the CDR.
The transmission is controlled by a communication server. Extract transform load is a method to transfer data. 'Extract' is the process of reading data from different types of sources. 'Transform' is the process of preparing the data for writing and converting the data into the needed structure. 'Load' writes the data into the target database. In the process of transferring the data from the ODS to the CDW via extract transform load, data can be validated and transformed in syntactic and semantic standards if not done before. Data analysis algorithms access the CDW directly, and analysis results can be retransferred to the clinical data documentation in the EHR, if allowed by the vendor. CDR enhance the transforming process to standardized and interoperable data; this is useful for many data applications, not just for AS.
Centrally implemented AS The coordinating centre provides standard definitions of HAI source data, HAI surveillance results, messaging standards and algorithms to identify HAI. Algorithm results (HAI surveillance data) and analysis results of pooled data (HAI rates) are stored in the surveillance network data repository. There are four suggested scenarios to organize centrally implemented AS. Scenario 1. The HAI source data are transferred from the participating healthcare facilities to the SDC located within the coordinating centre. After the data transfer, the fully automated HAI detection algorithms are applied. Depending on the possibilities regarding data protection, the patient data are anonymized or pseudonymized at the participating healthcare facility level. Analysis reports go back to every hospital; if pseudonyms are created at hospital level, then the link to the patient's name can be reconstructed at the hospital level.
Scenario 2. The HAI source data are not transferred from the participating healthcare facilities to the coordinating centre. Instead, the HAI detection algorithms are running in the SDC, accessing each participating centres' HAI source data in a standardized format via secured application programming interfaces (API). Feedback is organized as in scenario 1. Scenario 3. Fully automated surveillance algorithms, designed and maintained by the coordinating centre, are running locally on the participating healthcare facilities' CDR. The algorithm outputs (HAI surveillance results) are transferred to the SDC. Feedback is organized as in scenario 1. Scenario 4. A hybrid method combines semiautomated surveillance with the centralized approach and is divided into different steps, as follows. Firstly, HAI source data are transferred to or accessed by the SDC as in scenario 1 or scenario 2.
Locally implemented AS In a locally implemented AS, a greater IT responsibility lies within the participating healthcare facility. There are two suggested scenarios to organize locally implemented AS. Scenario 1. Semiautomated surveillance algorithms are implemented in each participating healthcare facility, creating 'suspected HAI events'. The IPC professionals rate these events, and the HAI surveillance results are transferred to the SDC at the coordinating centre. Scenario 2. Locally implemented fully automated algorithms classify HAI and save the HAI surveillance results into local databases. Hospital-specific indicators can optionally be included in the surveillance and local analysis process. HAI surveillance results are transferred to the SDC. The concept of the algorithms and the definition of the core HAI surveillance result data are adapted from the coordinating centre.
Secured data transfer Secure transfer of surveillance data is a priority in a surveillance network. Whenever possible, data should be pseudonymized or anonymized, and only the required data for the purpose of surveillance should be shared. Data transfers need to take place using secure channels, especially when data are transferred from participating healthcare facilities to the coordinating centre via public internet. Within the healthcare facilities, the data flow needs to be secured with the established local security standards. This requires that all connections be recorded, and unauthorized access trials needs be communicated from the system to the responsible administrators.
Data transfer from coordinating centre to participation centre The coordinating centre should provide feedback to the participating centre on the infection rates and other information, like validation and analysis results. Web portals with HTTP and authentication mechanisms are required so that every participating centre can access its data individually. When the aggregated data become public, no authentication mechanism is required, and (aggregated and pooled) infection rates are available on the internet via a public page or a report in PDF form. Practical example: a minimal viable product approach to set up locally implemented AS The minimal viable product approach means development of AS with just enough features to satisfy the basic needs of HAI surveillance and to facilitate feedback from users before proceeding further in development.
In addition, algorithms have to be evaluated regularly and adapted when necessary. The source data used for the algorithms are dynamic both in data registration and in their implementation. As an example, a department of clinical microbiology may change their codes for blood cultures in the microbiology database. As a result, the algorithm for BSI no longer picks up these blood culture results, resulting in an apparent drop in the incidence of BSI in that participating facility. This issue may be minimized, but not eliminated, by using standards such as SNOMED CT or LOINC. A more.
Software developed by several people, ideally collaboratively, ensures its continued existence and maintenance. Applications created by a single person are usually not durable in the long run and should be avoided. The basic principle for in-house development is to transfer the knowledge to as many people as possible in order to minimize the risk of losing all knowledge. But even if you choose open source software, you are not safe from later commercialization or termination of the product; for example, the collaboration tool DekiWiki (later called MindTouch Core), which was released by a company as open source software, discontinued development in 2013  [32].
Box 4 Dimensions of system elaboration. Expand the MDS to collect more source data to improve algorithms or collect more risk-factor data. Target additional HAI, e. g. surgical site infections, perhaps needing more source data (e. g. procedures, antibiotic use). Target specific patient populations (e. g. ward level, devices). Use more complex algorithms (e. g. with more complex methods). Build in a possibility for semiautomated surveillance. Ensure the participation of multiple participating healthcare facilities. Automate the reporting to and from the coordinating centre to the participating centre. rigorous example of a change in registration would be a complete revision of the data model of the data source, requiring new data importers and a revision and test of all algorithms. Changes in implemented surveillance systems or electronic healthcare registration systems may involve moving a database to another server, requiring new setup, new user access, updating scripts and updating agreements.
In addition, AS needs to develop in parallel with data legislations. Implementing a general framework, which allows AS within the existing General Data Protection Regulation, is crucial to allow for surveillance networks to collect and share desired HAI surveillance data regionally, nationally and on the European level. Finally, the initiative and leadership of automated HAI surveillance should be maintained by the IPC community and medical informatics experts. This can be ensured by establishing a commercially independent organization with the objective of compiling information on worldwide AS activities, implementing guidelines and pushing the development of AS further. Fig. 2. A minimal viable product approach to set up locally implemented automated surveillance. The AISS reads patient ADT from the HIS and receives microbiology findings from the hospital's LIS.
Acknowledgements We would like to thank  E. Abbevik  for her help in designing the graphical work. We are thankful for the valuable input of our external reviewers: K. Woeltje (USA), A. Harris (USA) ,  A. Hajdu  (Hungary),  B. Babarczy  (Hungary),  T. Karki  ( Sweden ) and  C. Schweizer  (Germany). Members of the PRAISE network are:  Olov Aspevall, Unit for Surveillance and Coordination, Public Health Agency of Sweden, Solna, Sweden; Pascal Astagneau, Centre for Prevention of Healthcare-Associated Infections, Assistance Publique e Hôpitaux de Paris & Faculty of Medicine, Sorbonne University, Paris, France ;  Marc J. M. Bonten ,  Department of Medical Microbiology, Julius Center for Health Sciences and Primary Care, University Medical Center Utrecht, Utrecht, The Netherlands ;  Elena Carrara ,  Infectious Diseases Section, Department of Diagnostics and Public Health, University of Verona, Verona, Italy ;  Aina Gomila-Grange ,  Infectious Diseases Unit, Bellvitge Biomedical Research Institute (IDIBELL), Bellvitge University Hospital and Infectious Diseases Unit, Consorci Corporaci o Sanit aria Parc Taulí, Barcelona, Spain; Sabine C.
funded by  ZonMw  (grant number  549007001 )), the  COMBACTE MAGNET EPI-Net  project (funded by the  Innovative Medicines Initiative Joint Undertaking  under grant agreement n  115523 | 115620 | 115737 | 777362  resources of which are composed of financial contribution from the  European Union Seventh Framework Programme  ( FP7/2007-2013 ) and EFPIA companies in kind contribution) and  Charit e University Hospital.
Conclusion An efficient approach to determine the optical constants and thickness of deposited thin films based on ABC algorithm and Cauchy dispersion model were presented. In this approach, the transmittance spectrum of the elaborated samples was measured first. Then, the data that corresponds to the interference fringes zone was introduced into the ABC algorithm in order to determine the thin layer thickness () and Cauchy model parameters ( 1 ,  1 ,  2   2 ). This approach consists of dividing the spectrum into two main parts. The first part corresponds to zone with interference fringe. The thin film thickness and refractive index values are determined by using this part of the spectrum. The second part corresponds to the remaining zone of transmittance. Absorption and extinction coefficients values are determined based on the transmittance spectrum of this region.
Serotype-specific surveillance for invasive pneumococcal disease (IPD) is essential for assessing the impact of 10-and 13-valent pneumococcal conjugate vaccines (PCV10/13). The Pneumococcal Serotype Replacement and Distribution Estimation (PSERENADE) project aimed to evaluate the global evidence to estimate the impact of PCV10/13 by age, product, schedule, and syndrome. Here we systematically characterize and summarize the global landscape of routine serotype-specific IPD surveillance in PCV10/13-using countries and describe the subset that are included in PSERENADE. Of 138 countries using PCV10/13 as of 2018, we identified 109 with IPD surveillance systems, 76 of which met PSERENADE data collection eligibility criteria. PSERENADE received data from most (n = 63, 82. 9%), yielding 240,639 post-PCV10/13 introduction IPD cases.
Identification of Surveillance Sites We aimed to systematically identify sites conducting serotype-specific IPD surveillance in countries where PCV10 or PCV13 was universally recommended for all infants by 1 January 2017 to ensure at least one full year of post-PCV10/13 surveillance data. Countries using PCV10/13 and their year of introduction were identified using View-Hub, a publicly available database with current information on PCV use worldwide  [5]. IPD surveillance sites were identified using multiple approaches. First, we contacted the following surveillance networks: WHO-coordinated Global Invasive Bacterial Vaccine Preventable Disease (IB-VPD) Surveillance Network, the Pan American Health Organization (PAHO) Sistema de Redes de Vigilancia de los Agentes responsables de Neumonias y Meningitis (SIREVA) Network, the European Centre for Disease Prevention and Control Streptococcus pneumoniae Invasive Disease Network (SpIDnet), The European Surveillance System (ECDC), and the U.