dataesr/scientific-paragraphs-categorization huggingface dataset:
The aging of the world's population, the willingness of elderly to remain independent, and the recent COVID-19 pandemic have demonstrated the urgent need for home-based diagnostic and patient monitoring systems to reduce the financial and organizational burdens that impact healthcare organizations and professionals. The Internet of Medical Things (IoMT), i. e. , all medical devices and applications that connect to health information systems through online computer networks. The IoMT is one of the domains of IoT where real-time processing of data and reliability are crucial. In this paper, we propose RAMi, which is a Real-Time Architecture for the Monitoring of elderly patients thanks to the Internet of Medical Things. This new architecture includes a Things layer where data are retrieved from sensors or smartphone, a Fog layer built on a smart gateway, Mobile Edge Computing (MEC), a cloud component, blockchain, and Artificial Intelligence (AI) to address the specific problems of IoMT.
The level 4 is device control and alerts where processed data from level 3 can be used for customized services. The Smart City Architecture components could be smart health, smart environment, smart energy, smart security, smart office and residential buildings, smart administration, smart industries, and smart transport  [7]. Loria et al. [8]  presented an in-house IoT architecture for a product named SeeYourBox. This architecture is built on two parts: processing and storing. To achieve that goal, the architecture is composed by three components: the gateway which received raw data from devices, the engine which analyzed the data and the databases to store the data. This architecture was designed to be very efficient regarding the SeeYourBox business and the expertise of their team regarding the technologies in IoT compared to the existing solutions such as Amazon AWS IoT or Microsoft Azure IoT  [8].
Data transmitted to Apache Kafka are temporarily stored in it before being ingested by the Druid Indexing Service. Apache Druid stores the data in the form of segments, in other terms, in sets of a few millions of rows of data stored on Hadoop File System (HDFS). Apache Ambari retrieved the Druid metric emitted to monitor it. Apache Kylin is used on Druid  [13]. Nevertheless, with recent the versions of Apache Druid, it is more efficient to use Druid without Kylin or in alternative Kylin 4. 0 with Parquet. Sun et al. [3]  reviewed the architecture of IoMT, the cloud-enabled IoMT, and the architecture of edge cloud IoMT and showed the potential of edge-cloud computing in the medical field. They argued that Edge Cloud computing is well adapted to 5G but brings a lot of security problems, threats, and privacy issues.
[21]  proposed an architecture for real-time health status prediction and analytics system using big data technologies. This architecture applies distributed machine learning model on streaming health data events ingested to Spark, streaming through Kafka topics. According to the author, their architecture can predict health status, send an alert message to care providers, and store the details in a distributed database, to perform health data analytics and stream reporting  [21]. Yacchirema et al. [22]  implemented an architecture which has two goals: detect and support of treatment of Obtrusive Sleep Apnea (OSA) of elderly people. Indeed, the OSA is an important sleep disorder which directly impacts the quality of life. In order to detect the OSA, they used a FOG Computing method implemented in a smart device located at the edge of the network.
The Hub-IoT (NoSQL DB, cloud broker) is used to store and to process data. As a result, they obtained for spO2, a range between 95% and 97%, for the heart rate, a range between 86-100 bpm, and for the body temperature, a range of 35. 5 °C to 37. 0 °C  [25]. Neyja et al. [26]  presented an IoT based e-health monitoring system which uses the ECG signal. This architecture is formed by heterogeneous devices (sensors, user equipment, etc. ), gateway (smartphone), and the hospital database. They have also developed a hospital alert system which is supposed to generate an alert in case of detection of an abnormal heart rate activity. To test their architecture, they used the Physio Bank ATM toolbox to generate the ECG  [26]. Ruman et al. [27]  proposed an emergency health monitoring system based on IoT.
This architecture is composed by sensors (body temperature sensor, heartbeat sensor, etc), the data processing software (Arduino, ESP8266) and the cloud to store data. To visualize data, they used Thingspeak online software. As a result, they obtained a body temperature range between 35. 6 °C and 37. 8 °C. For the ECG, they obtained a range between 65-73 bpm  [27]. The Table  3  gives a pros and cons analysis of elderly monitoring systems selected.
Federated learning is a solution to overcome this limited data availability while respecting data privacy. The Federated Learning generates a machine learning model trained with datasets distributed on multiple devices. The data and the model stay locally without any transmission of data, only the owner can obtain the trained model  [36]. According to authors of  [36] , the computational formula of Federated Learning is Arg Min L(a, b, c) = ΣP k L k (a, b, c) (1) where k = total number of clients; P k = weight of the k th client; a = input; b = output; c = parameter to be learned. In our architecture, in order to ensure data confidentiality and privacy, medical data will therefore not be shared and will not leave their original location. Our deep learning algorithms will rely on federated learning instead of traditional learning.
The main advantage for the members of the Coalition thus formed (partners) is that they do not exchange their local data. In exchange, the partners have to train a similar model on their local data. In particular, in federated learning, a consortium of actors shares their locally trained model weights and a central unit aggregates these. Although it allows partners to share only the gradients and weights of their model, the architecture also raises several challenges to ensure privacy and confidentiality. Firstly, the pseudonymization of the training dataset and, secondly, the confidentiality of the models and gradients must be guaranteed in order to avoid any reverse engineering of the training dataset. Finally, the protection of the model against degradation by training on inadequate data.
RAMi Architecture Our architecture proposition called RAMi is a Real-Time Architecture for the Monitoring of elderly patients thanks to the Internet of Medical Things. It contains an early warning system using the real-time data analysis using Machine Learning (ML) algorithms applied to real-time data and an annotation system to specifically tag individual patient's alert on historical data to avoid false positive alerts. Our architecture is based on open-source software to ensure its sustainability and the Independence of other platforms by a design which allows the replacement of a software brick which would disappear, or another software brick would be more efficient. Moreover, the fact of using software components with permissive open-source licenses makes it possible to value the developments made on the platform and even to close the code afterwards in view of a commercialization.
In addition, changing software bricks allows the architecture to be adapted to the specific needs of particular use cases. The use of a datalake formed by an object storage, a service of indexing and discovery of the data allows to store large amounts of data and to exploit them on demand for energy saving purposes compared to a systematic treatment of the whole dataset before storage. The architecture associates a cloud and a fog level of treatment to prevent and be independent of possible connection problems such as link congestion, temporary interruption of network connections that could be fatal for patients. In addition, false positives usually require human intervention, which is costly for health care facilities. The elimination of a part of them will allow to relieve the care structures by limiting the costs related to false alarms.
We have chosen an architecture deployed in the form of containers to allow easier deployment, scaling, and management. Figure  1  presents an overview of the main software bricks of the cloud part of RAMi architecture as well as the way data flow within the architecture. The data are transmitted to MQTT topic and then converted in message stored in the message queue. The real-time processing consumes and transforms the data train and predicts anomalies in data. Patterns detected are stored in the relational database in order to be annotated. The nursing staff can annotate each patient's patterns into true and false positives using the eponymous service. All the data processed by the real-time processing are stored in the time series database. All data are stored in a deep storage Amazon S3 compatible.
However, data from the relational database must be converted into objects beforehand. The conversion into an object makes it easier to search the data and display them in the dashboard. Finally, an in-memory cache system speeds up the most common queries on both the time series database and the dashboard system. The cloud part of the architecture is built around ten software components (Mosquitto, Kafka, Spark, Camel, MinIO, ElasticSearch, Surperset, PostgreSQL, Druid, Redis, Zookeeper) which constitute the core of the architecture, a log system (Log4j), a monitoring system (AirFlow) and deployment, and an administration model (Kubernetes). Eclipse Mosquitto (mosquitto. org, accessed on 22 June 2022) is a MQTT server that collects data from sensors of origins and stores them in individual topics in binary, plain text or json form, Apache Kafka (kafka.
apache. org, accessed on 24 June 2022), a message queue widely used to temporary store data before or after their processing. Apache Spark Streaming (spark. apache. org, accessed on 28 June 2022) is implemented to process streams of data while the MLlib library achieves Machine Learning analysis. At the end, the data are stored in function of the type of data in a polystore composed of multiple databases (Apache Druid & PostgreSQL). Apache Camel (camel. apache. org, accessed on 22 June 2022) is an integration framework that empowers integration of various systems consuming or producing data. MinIO   ) is an open source system for automating the deployment, scaling, and management of components in a containerized architecture. Apache Log4j (logging. apache. org/log4j/2. x, accessed on 25 June 2022) is a Java-based logging utility.
Zookeeper coordinates Druid, Spark, and Kafka clusters. While Log4j allows to log all events at key components of the architecture to quickly detect anomalies and investigate failures. Redis plays the role of caching system for Apache Druid at broker level and for the Apache Superset. Finally, Kubernetes deploys easily all components of the architecture and news pods to scale of the architecture. The proposed architecture is sufficiently flexible to easily replace most components with alternatives. In order to enlighten the readers on the possibilities of substitution, we propose some alternative software bricks that could be used to replace the components of the architecture. An alternative to Apache Druid, Apache Pinot (pinot. apache. org, accessed on 30 June 2022), a promising Real-time distributed OLAP datastore, designed to answer OLAP queries with low latency can be implemented.
Experimentation The aim of our experimentation is to evaluate our architecture, on one the hand, on the basis of the ECG real-time abnormal detection and, on the other hand, on the quality of the patient environment thanks to the evaluation of Heat Index (HI). The two experiments are implemented on the same microcontroller equipped of four sensors. We used a Wemos D1 R32 board that has the same factor form as an Arduino UNO and is also programmable with Arduino IDE. On this board, the ATMega328 16 MHz is replaced by an ESP32 WROOM at 240 MHz with Wi-Fi, Bluetooth, and 4MB of flash memory. Both experiments use a common real time clock DS3231 connected to the microcontroller by the I 2 C protocol to retrieve a common base time which is the Linux time, i. e. , the number of seconds elapsed since 1 January 1970.
Environmental data (air temperature and relative humidity) were transmitted at a frequency of 1 Hz. The HI is calculated on the basis of temperature expressed in °C and relative humidity expressed in %. An extract of the analysis achieved with Apache Superset is shown in Figure  11  to Figure  13  for temperature, Figure  14  to Figure  16  for humidity, and Figure  17  to Figure  19  for heat index, respectively. Beat rate per minute and spO2 rate acquired by MAX10302 and transmitted at each change of value at a variable frequency between 1 Hz to 3 Hz. One overview of these data is presented in Figure  20  to Figure  22  and Figure  23  to Figure  25. These first results allow to demonstrate the correct functioning of our architecture. Nevertheless, the architecture must also be tested with commercial sensors to demonstrate its ability to work with a wide variety of sensors producing data at different frequencies and in various formats.
Discussion In our experimentation, we have evaluated the ability of the architecture to ingest and process three ways of sending data. We used for our experiments a Wemos D1 R32 board equipped with 4 sensors (DHT22, DS3231, MAX30102, AD8232) which measures air temperature/relative humidity, date/time, heartbeat/spO2, and ECG, respectively. The authors of  [23]  demonstrated that local processing of data from various sensors is necessary before sending them to the cloud. Humidity and beat rate values measured in our experiment is like those obtained in  [24]. They also showed the ability of the ESP32 to process data. The authors of  [25]  measured spO2 and heart rate and their values are comparable to those measured in our experiments. The authors of  [26]  used a smartphone as gateway and sensors to detect heart anomalies but they tested their system with generated ECG data.
While the authors of  [27]  showed the ability to achieve the processing of ECG data with Arduino and ESP8266. In the first experiment, we evaluated our Machine Learning algorithm on several ECGs to evaluate its ability to detect anomalies. Our experiment was performed with 2 normal ECGs and 2 abnormal ECGs. Moreover, the transmission of an ECG signal has demonstrated the ability of the architecture to collect, process, and store data in real-time. In the second experiment, we evaluated the ability of the architecture to manage data arriving at regular intervals of time or in burst mode. In the end, our architecture has been tested with our own sensors to alleviate problems of compatibility and interoperability problems. Indeed, experimentation in a medical context requires a series of administrative steps and prior agreements with equipment manufacturers to have access to raw or pre-processed data from their sensors.
Conclusions and Future Direction In this paper, we presented RAMi, a new platform Fog/Cloud to process medical data to monitor elderly, bedridden, and convalescent patients. Our architecture is designed to detect patterns of anomalies in the data in real-time but also to eliminate false positives by integrating the particularities of the patients. Moreover, we have proposed alternatives to most of the software bricks that compose the architecture so that it can be adapted to the needs or particularities of other use cases. The fact of being relatively independent of the software bricks allows us to protect ourselves from the disappearance or abandonment of some of them over time and thus make the architecture hopefully more sustainable. In the end, the architecture is limited to real-time processing of time series data, which allows for the collection of most of the data produced by the sensors of convalescent or elderly patients.
Currently, the architecture is not designed to process and import old patient data. Our experiments have proven the proper functioning of our architecture and the ability of the node to correctly process the data streams from the ECG sensor and other sensors. The values measured by the sensors are in similar ranges to those in the literature. In future work, we will extend our architecture to all kind of medical data. With this aim, we will implement Fast Healthcare Interoperability Resources (FIRH) v3 proposed by Health Level Seven International (HL7) to describe data and improve their interoperability. The interoperability between data will allow to develop new applications. The development of a connector will also allow to interconnect INAH  [12]  and RAMi in the future. In addition, special attention will be given to the security of the platform to ensure resilience in case of attack.
The time-series data are stored in Apache Druid in the form of groups of 4 to 7 millions of lines called segments stored onto MinIO which also plays the role of deep storage. While PostgreSQL is used to store, on the one hand, a relation between collected data and Metadata of segments is produced by Apache Druid. Apache Superset allows to analyze, on the one hand, raw data to obtain an overview of the evolution of the parameters and, on the other hand, query the Druid database-processed data refining trends and achieving more complex analyses. Apache Airflow is used in our architecture to monitor workflows in Apache Druid, PostgreSQL, Redis, and ElasticSearch. Zookeeper coordinates Druid, Spark, and Kafka clusters. While Log4j allows to log all events at key components of the architecture to quickly detect anomalies and investigate failures.
Redis plays the role of caching system for Apache Druid at broker level and for the Apache Superset. Finally, Kubernetes deploys easily all components of the architecture and news pods to scale of the architecture. The proposed architecture is sufficiently flexible to easily replace most components with alternatives. In order to enlighten the readers on the possibilities of substitution, we propose some alternative software bricks that could be used to replace the components of the architecture. An alternative to Apache Druid, Apache Pinot (pinot. apache. org, accessed on 30 June 2022), a promising Real-time distributed OLAP datastore, designed to answer OLAP queries with low latency can be implemented. While Elasticserach can be replaced by Apache Solr (solr. apache. org, accessed on 30 June 2022), a popular, blazing-fast, opensource enterprise search platform also built on Apache Lucene (lucene.
(min. io, accessed on 22 June 2022) is high-performance, S3 compatible object storage. ElasticSearch (elastic. co, accessed on 24 June 2022) is a software using Apache Lucene (lucene. apache. org, accessed on 24 June 2022) for indexing and searching data. Apache Airflow (airflow. apache. org, accessed on 24 June 2022) is a platform to programmatically author, schedule, and monitor workflows. Apache Superset (superset. apache. org, accessed on 25 June 2022) is a data exploration and visualization platform. PostgreSQL (www. postgresql. org, accessed on 28 June 2022) is a powerful, open-source object-relational database system. Apache Druid (druid. apache. org, accessed on 27 June 2022) is a real-time database to power modern analytic applications. Redis (redis. io, accessed on 25 June 2022) is an open source, in-memory data store.
Apache Spark Streaming consumes data present in the Apache Kafka, annotates and enriches data while Apache Spark MLlib is used to clean and validate data before storing them. The time-series data are stored in Apache Druid in the form of groups of 4 to 7 millions of lines called segments stored onto MinIO which also plays the role of deep storage. While PostgreSQL is used to store, on the one hand, a relation between collected data and Metadata of segments is produced by Apache Druid. Apache Superset allows to analyze, on the one hand, raw data to obtain an overview of the evolution of the parameters and, on the other hand, query the Druid database-processed data refining trends and achieving more complex analyses. Apache Airflow is used in our architecture to monitor workflows in Apache Druid, PostgreSQL, Redis, and ElasticSearch.
Volunteers attended three drug administration visits (V1, V3, and V5), each of which was followed by a 24 h post-drug administration visit (V2, V4, and V6). Sample size and optimised sampling times for each administration route were determined using the PFIM 3. 2. 1 software (http://www. pfim. biostat. fr/)  10 to accurately estimate the pharmacokinetic parameters (relative standard errors <30%) based on data available in the same population. 7 herefore, for the pharmacokinetic analyses, we took blood samples (0. 5 ml venous blood in a dry tube without anticoagulant) immediately before TXA administration (T0), T0þ5 min (i. v. route only), T0þ30 min, T0þ1 h, T0þ2 h, T0þ3 h, T0þ4 h, T0þ5 h, T0þ6 h, T0þ8 h (i. m. and p. o. routes only), and T0þ24 h. After each administration, we took one additional blood sample (0.
Pharmacokinetic analysis We analysed the data using the non-linear mixed-effect modelling program Monolix 2020R1 for compartmental population pharmacokinetics. We computed maximum likelihood estimators of the parameters without any approximation of the model (no linearisation) using a stochastic approximation expectationemaximisation algorithm combined with a Markov chain Monte Carlo procedure. 12 The number of iterations was fixed at 1000. The parameters of the two-compartment model were the first-order absorption constant for the i. m. (k aIM ) and oral (k aPO ) routes, i. m. (F IM ) and oral (F PO ) bioavailability, lag time before oral absorption (T lag ), elimination clearance (CL), intercompartmental clearance (Q), volume of central compartment (Vc), and volume of peripheral compartment (Vp).
75 for volumes and clearances, respectively, consistent with allometric scaling theory. 13 We evaluated the goodness of fit of each model by visual inspection of individual concentrationetime courses, observedepredicted (population and individual) concentration plots, and predictionecorrected visual predictive checks. The Rsmlx R package (R Speaks Monolix; http://rsmlx. webpopix. org) was used to compute confidence intervals for the population parameters with non-parametric bootstrapping (n¼400 bootstrap replicates) and log-likelihood profiling, and secondary pharmacokinetic parameters were calculated with Simulx 2020R1 (Lixoft). P i ¼P STD Â (COV i / COV STD ).
Results The 11 female and four male study participants had a median age of 25 yr and a median BW of 64. 2 kg. Their characteristics are shown in Table  1. All participants had the three doses by each administration route, and there were no serious adverse events. We collected 450 serum samples for TXA concentration measurement and 42 matched whole blood samples. The concentration vs time curves are shown in Figure  1. Two serum samples from the i. v. route, which had TXA concentrations greater than 430 mg L À1 at T0þ5 min, were considered outliers and removed from the analysis. The model building steps are shown in Supplementary Table  1. A twocompartment open model with first-order absorption and elimination described the data better than a onecompartment model. A third compartment was not identifiable in our examination of three-compartment models.
Acknowledgements The funder had no role in the collection, management, analysis, data interpretation, writing of the report, or the decision to submit the report for publication. The authors gratefully acknowledge the contribution of the trial participants and the staff from the  Centre d'Investigation Clinique P1419  and  Unit e de Recherche Clinique, INSERM, Hôpital Cochin-Necker, Paris, France  involved in this study.