Search

LARC is managed by multimodal treatments whose intensity can be highly modulated. In this context, we need surrogate endpoints to help predict long-term outcomes and better personalize treatments. A previous study identified 2yDFS as a stronger predictor of OS than pCR in LARC patients undergoing neoadjuvant RT. The aim of this pooled analysis was to assess the role of pCR and 2yDFS as surrogate endpoints for OS in a larger cohort. The pooled and subgroup analyses were performed on large rectal cancer randomized trial cohorts who received long-course RT. Our analysis focused on the evaluation of OS in relation to the pCR and 2-year disease status. A total of 4600 patients were analyzed. Four groups were identified according to intermediate outcomes: 12% had both pCR and 2yDFS (the better); 67% achieved 2yDFS but not pCR (the good); 1% had pCR but not 2yDFS; and 20% had neither pCR nor 2yDFS (the bad). The pCR and 2yDFS were favorably associated with OS in the univariate analysis, and 2yDFS maintained a statistically significant association in the multivariate analysis independently of the pCR status. The combination of the pCR and 2yDFS results in a strong predictor of OS, whereas failure to achieve 2yDFS carries a poor prognosis regardless of the pCR status. This new stratification of LARC patients could help design predictive models where the combination of 2yDFS and pCR should be employed as the primary outcome.

Purpose SARS-COV-2 pandemic led to antibiotic overprescription and unprecedented stress on healthcare systems worldwide. Knowing the comparative incident risk of bloodstream infection due to multidrug-resistant pathogens in COVID ordinary wards and intensive care-units may give insights into the impact of COVID-19 on antimicrobial resistance. Methods Single-center observational data extracted from a computerized dataset were used to identify all patients who underwent blood cultures from January 1, 2018 to May 15, 2021. Pathogen-specific incidence rates were compared according to the time of admission, patient’s COVID status and ward type. Results Among 14,884 patients for whom at least one blood culture was obtained, a total of 2534 were diagnosed with HA-BSI. Compared to both pre-pandemic and COVID-negative wards, HA-BSI due to S. aureus and Acinetobacter spp. (respectively 0.3 [95% CI 0.21–0.32] and 0.11 [0.08–0.16] new infections per 100 patient-days) showed significantly higher incidence rates, peaking in the COVID-ICU setting. Conversely, E. coli incident risk was 48% lower in COVID-positive vs COVID-negative settings (IRR 0.53 [0.34–0.77]). Among COVID + patients, 48% (n = 38/79) of S. aureus isolates were resistant to methicillin and 40% (n = 10/25) of K. pneumoniae isolates were resistant to carbapenems. Conclusions The data presented here indicate that the spectrum of pathogens causing BSI in ordinary wards and intensive care units varied during the pandemic, with the greatest shift experienced by COVID-ICUs. Antimicrobial resistance of selected high-priority bacteria was high in COVID positive settings.

This document represents the assessment of the iHelp approaches by showing the proposed data collecting processing and modelling flow. This workflow’s final purpose is to provide to the clinicians a better insight of the Pancreatic Cancer disease. There are five pilot studies within the iHelp designed to help test and validate the personalized solution developed in this project by providing different types of data which is useful within the various aspects/scenarios of disease prevention. The five pilots involved in this project, provide the input data needed for the IHelp technical partners to analyse and compile smart models that can help with predicting this type of disease. Upon the completion of the 1st iteration of this report on D6.5 (“Data Collection and Pilot Assessments I”), adjustments and improvements will be made and will be reflected in the 2nd iteration of this deliverable, i.e., D6.6 (“Data Collection and Pilot Assessments II”). This document contains the description of data collection processes and procedures and the instruments used to evaluate these processes. It also describes the evaluation mechanisms of pilot studies. The data collection instruments section presents an overview of what the data collection strategy is for each pilot, how data will be formatted and distributed and what is the methodology for data ingestion into the iHelp platform from each pilot’s perspective. Pilots will present details about the measuring of the data quality by describing the evaluation instruments for data collection and assessment measures. Pilots will present details about the data quality and quantity and will describe how the data flow is managed. To ensure proper data flow and smooth ingestion of the data from the pilots to the iHelp platform, partners have identified potential risks that could appear, and the solutions that alleviate the impact of these potential issues.

The objective of this deliverable is to report on the developments regarding the delivery mechanisms for personalised healthcare and real-time feedback in the first phase of the iHelp project. This is the first version of a series of deliverables of this task, which seeks to deliver the user-centric smart application to support the delivery of personalized healthcare through the use of mobile, IoT and wearable technologies. To this end, this deliverable provides information on the user centric application through which the personalised healthcare solutions are delivered. It also describes the design and implementation of the software interfaces and personalised engagement strategies that will be used to deliver the personalised recommendations and gather feedback. Ultimately, this report accompanies the software that has been developed as part of the T5.3 (“Delivery Mechanisms for Personalised Healthcare and Real-time Feedback”) until M16 of the iHelp project. An updated and final version of this document will be released on M32.

“Cloud-native” is the umbrella adjective describing the standard approach for developing applications that exploit cloud infrastructures’ scalability and elasticity at their best. As the application complexity and user-bases grow, designing for performance becomes a first-class engineering concern. As an answer to these needs, heterogeneous computing platforms gained widespread attention as powerful tools to continue meeting SLAs for compute-intensive cloud-native workloads. We propose BlastFunction, an FPGA-as-a-Service full-stack framework to ease FPGAs’ adoption for cloud-native workloads, integrating with the vast spectrum of fundamental cloud models. At the IaaS level, BlastFunction time-shares FPGA-based accelerators to provide multi-tenant access to accelerated resources without any code rewriting. At the PaaS level, BlastFunction accelerates functionalities leveraging the serverless model and scales functions proactively, depending on the workload’s performance. Further lowering the FPGAs’ adoption barrier, an accelerators’ registry hosts accelerated functions ready to be used within cloud-native applications, bringing the simplicity of a SaaS-like approach to the developers. After an extensive experimental campaign against state-of-the-art cloud scenarios, we show how BlastFunction leads to higher performance metrics (utilization and throughput) against native execution, with minimal latency and overhead differences. Moreover, the scaling scheme we propose outperforms the main serverless autoscaling algorithms in workload performance and scaling operation amount.

Deliverable D8.5 is the first iteration of the exploration plans of the iHelp project and includes the strategy, the joint exploitation approach, as well as the update of the partners’ individual plans, describing their intentions for exploitation of iHelp outcomes, detail their plans to achieve the targeted exploitation goals and report progress on planned actions. The second and third iterations of the exploitation plans will be made available on M24 and M36 respectively, with the document D8.6 and D8.7.

This document summarizes the actions performed under T4.1 “Personalized Health Modelling and Predictions” in the context of WP4 “Knowledge Management and Modelling in the iHelp Platform”. More specifically, D4.1 “Personalised health modelling and predictions I” provides an extended description of the mechanisms and Artificial Intelligence (AI) models that will be implemented for the realisation of personalised health and risk prediction models. The implementation of the ΑΙ algorithms that will be realized during the project’s lifecycle highly depends on the provided datasets on which they are trained. At this phase of the project, the description of the datasets that are going to be used, drive the actions under this Task towards a concrete description and specification of the AI algorithms and models that will be utilized. In addition, this document -the first one out of three versions- encapsulates the necessary and relevant information that was researched from recent bibliography to facilitate the manipulation of the available datasets, once they become available, setting the basis for the design and implementation of the models. More specifically, after an initial analysis of the datasets description, this document focuses on the advances of Machine Learning (ML) in the domain of healthcare, with special focus on the importance of Federated Learning (FL) for models trained from user interaction with tracking devices, as also is realised under the scopes of the iHelp project. Moreover, an initial analysis of pre-processing of data is being described, with focus on initial feature selection and imputation. Finally, in this deliverable are analysed the main concepts behind the models, also in compliance with an analysis of the importance of known and unknown risk factors based on the description of the clinical/primary data.

This deliverable summarizes the work that has been done in the score of Task 2.1 (“State of the art and requirement analysis”) until M12. This is the second version of a series of deliverables of this task, whose main objective is to specify the pilot scenarios, their involved datasets, and their corresponding user requirements, as well as the system and technical requirements that are being imposed by the platform. As mentioned in the previous version of this deliverable (i.e. D2.1 – State of the art & Requirement Analysis I), the purpose of these series is to track those requirements throughout the project and update them during the progress of the project. As a result, this second version depicts the enhanced (primary & secondary) data requirements that have been identified after the delivery of the first versions of the scientific reports and provides an updated version of some of the technical requirements of the iHelp platform. As mentioned in the first version of this deliverable the approach that has been followed is twofold: A top-down approach that is followed with respect to the user requirements that were collected by the use case providers themselves, after specifying the business goals and objectives of the use case, along with a concrete definition of the scenario. Moreover, a bottom-up approach is additionally complemented that aims to identify and analyse the technical requirements with respect to the technical work packages that are focusing on the platform technological needs. The result of this analysis is an updated list of measurable an unambiguous requirement that will drive the design of the overall architecture of the iHelp platform, focusing on serving all different needs of the various use cases of the project. As the project is still progressing, a final version of this deliverable will help the architecture designers of the platform and its software developers to adjust the overall architecture and its implementation accordingly, with respect to the principles of the agile methodology. Moreover, as our scope is to continuously keep track with the latest technological advances and how we can take advantage of them while developing our -a state-of-the-art analysis has been performed regarding the major technologies that are envisioned to be exploited. This deliverable is being released on M12 of the project and its main aim is to specify the scenarios of the use cases, which drove the user requirements based on their perspective, the updated version of the secondary data requirements and the technical requirements as foreseen by the technical partners that are being involved in the design of the overall architecture of the platform. A final version of this document will be released on M18.

Background : The COVID-19 pandemic affected healthcare systems worldwide. Predictive models developed by Artificial Intelligence (AI) and based on timely, centralized and standardized real world patient data could improve management of COVID-19 to achieve better clinical outcomes. The objectives of this manuscript are to describe the structure and technologies used to construct a COVID-19 Data Mart architecture and to present how a large hospital has tackled the challenge of supporting daily management of COVID-19 pandemic emergency, by creating a strong retrospective knowledge base, a real time environment and integrated information dashboard for daily practice and early identification of critical condition at patient level. This framework is also used as an informative, continuously enriched data lake, which is a base for several on-going predictive studies. Methods : The information technology framework for clinical practice and research was described. It was developed using SAS Institute software analytics tool and SAS® Vyia® environment and Open-Source environment R ® and Python ® for fast prototyping and modelling. The included variables and the source extraction procedures were presented. Results : The Data Mart covers a retrospective cohort of 2634 patients with SARS-CoV-2 infection. People who died were older, had more comorbidities, reported more frequently dyspnea at onset, had higher d-dimer, C-reactive protein and urea nitrogen. The dashboard was developed to support the management of COVID-19 patients at three levels: hospital, single ward and individual care level. Interpretation : The COVID-19 Data Mart based on integration of a large collection of clinical data and an AI-based integrated framework has been developed, based on a set of automated procedures for data mining and retrieval, transformation and integration, and has been embedded in the clinical practice to help managing daily care. Benefits from the availability of a Data Mart include the opportunity to build predictive models with a machine learning approach to identify undescribed clinical phenotypes and to foster hospital networks. A real-time updated dashboard built from the Data Mart may represent a valid tool for a better knowledge of epidemiological and clinical features of COVID-19, especially when multiple waves are observed, as well as for epidemic and pandemic events of the same nature (e. g. with critical clinical conditions leading to severe pulmonary inflammation). Therefore, we believe the approach presented in this paper may find several applications in comparable situations even at region or state levels. Finally, models predicting the course of future waves or new pandemics could largely benefit from network of DataMarts.