Continuous timely monitoring of core temperature with two wearable devices in pediatric patients undergoing chemotherapy for cancer – a comparison study

Purpose Pediatric patients with cancer often develop chemotherapy-induced fever in neutropenia (FN), requiring emergency broad-spectrum antibiotics. Continuous temperature monitoring can lead to earlier FN detection and therapy with improved outcomes. We aimed to compare the feasibility of continuous core temperature monitoring with timely data availability between two wearable devices (WDs) in pediatric oncology patients undergoing chemotherapy. Methods In this prospective observational two-center study, 20 patients (median age: 8 years) undergoing chemotherapy simultaneously wore two WDs (CORE®, Everion®) for 14 days. The predefined goal was core temperature recorded in sufficient quality and available within ≤ 30 min during ≥ 18/24 h for ≥ 7/14 days in more than 15 patients. Results More patients reached the goal with CORE® (n = 13) versus Everion® (n = 3) (difference, 50% p < 0.001). After correcting for the transmission bottleneck caused by two WDs transmitting via one gateway, these numbers increased (n = 15 versus n = 14; difference, 5%; p = 0.69). CORE® measurements corresponded better to ear temperatures (n = 528; mean bias, − 0.07 °C; mean absolute difference, 0.35 °C) than Everion® measurements (n = 532; − 1.06 °C; 1.10 °C). Acceptance rates for the WDs were 95% for CORE® and 89% for Everion®. Conclusion The CORE® fulfilled the predefined feasibility criterion (15 of 20 patients) after correction for transmission bottleneck, and the Everion® nearly fulfilled it. Continuous core temperature recording of good quality and with timely data availability was feasible from preschool to adolescent patients undergoing chemotherapy for cancer. These results encourage the design of randomized controlled trials on continuously monitored core temperature in pediatric patients. Trial registration. ClinicalTrials.gov (NCT04914702) on June 7, 2021. Supplementary Information The online version contains supplementary material available at 10.1007/s00520-024-08366-w.


Online Resource Text S1 -Technical details of wearable devices
The Everion® (version, VSM-1; reference number, 910044; firmware version, 3.0.6) is CE-certified (CE 0123), medical device class IIa and FDA 510(k) exempt listed.It is light (40g), small (70x55x9 mm) and designed to be worn on the upper arm, see Figure 1.It records skin temperature once per second, and calculates core temperature once per minute, including its quality score (range, 0 to 100; sufficient quality, score ≥ 50).It additionally records heart rate, heart rate variability, respiration rate and further vital signs plus calculated measures, most of them once per second, some of them with their respective quality scores.In order to reduce energy consumption, the Everion® was set to mode «green only», which precludes from measuring oxygen saturation.We have previously shown that the quality of the oxygen saturation signal is poor in the majority of time [25].See Online Resource Table S4 for a full list of monitored signals.
The CORE® (lots GTG0013/17/18/19; firmware version, 0.3.15) is a commercially available consumer WD.It is not certified as a medical product and so no CE certificate is available.However the device meets the following EU conformity standards: 2014/53/EU Radio Equipment Directive (RED) and 2011/65/EU Restriction of Hazardous Substances (RoHS).It is lighter (12g) and smaller (50x40x 8 mm) than the Everion®.It is designed to be worn on the chest, either by an elastic strap or by skin-compatible adhesives.In this study, all but one patient wore it on the upper arm, see Figure 1.It measures skin temperature once per second, and calculates core temperature using an algorithm optimized in adults for chest positioning once per minute, including its quality score (range, 0 to 4; sufficient quality, score ≥ 2).
The data recorded and stored temporarily by the WDs were sent to a password protected cloud dashboard via a gateway.The gateway was custom built from commercially available components (Raspberry Pi 3B+ microcomputer from raspberry.org,uninterruptible power supply UPS HAT from waveshare.comequipped with 4 Li-ion batteries with a total capacity of 13000mAh, E3372h-320 GSM dongle from huawei.com)plus a Leitwert programmed BLED112 USB dongle for Bluetooth connection to the Everion®.All components were packed into a robust case, the entire gateway weighing around 500g.It run on proprietary gateway software by Leitwert (version 1.11.0, with the bgapi library, version 0.5.2, for the BLED112 dongle integrated), and connected to the WDs via Bluetooth® and to the dashboard via wireless LAN or the mobile net, without storing or processing the data.After shutdown by, e.g., inadvertent switching off, or battery exhaustion, the gateway rebooted automatically and was ready for data transmission within two minutes.
The dashboard was a GCP-ready server application hosted in Switzerland and specifically adapted to the needs of this study (Leitwert Dashboard,frontend version 3.7.12,backend version 3.7.5).To compensate for the wider range of the Bluetooth connection of the CORE®, the gateway configuration setting "default minimum synchronization interval" was increased to 120 seconds for the CORE® versus 60 seconds for the Everion®.
In the current setting, approximate charging times until full battery capacity were 3 hours for 18 hours recording in the Everion®, 3 hours for 120 hours (5 days) recording in the CORE®, and about 8 hours during function for 18 hours transmission in the gateway.The gateway was rechargeable during function thanks to the dual function capability of its power supply unit, while the Everion® and the CORE® had to be charged off body and thus off function.Correspondingly, the gateway was usually recharged some hours during every night in the sleeping room, the CORE® was usually recharged every day for about half an hour during, e.g, the time of bathing, and the two Everions® were alternatingly charged during night and during day, respectively.

Online Resource Text S2 -Simulating delay times corrected for data transmission bottleneck.
Retrospectively, the data transmission setting used here was suboptimal in two dimensions.First, per-second data were chosen for transmission, while only per-minute data were analysed; and second, the two WDs were transmitted by a single gateway, transmitting the entire data volume of one WD continuously before transmitting data of the other WD.This setting was good when both WDs were constantly within the Bluetooth range of the gateway, the transmitting WDs then changing every minute, with data transmission always being up-to-date.After long data transmission breaks, e.g., when the gateway had not been taken to the school, this setting led to a bottleneck in transmission capacity, with relevant additional transmission delays for one of the WDs, while the large volume of data of the other WD were transmitted.Frequently, the large data volume to be transmitted with a relatively slow speed led to additional delays of transmission for the WDs after transmission breaks.As an instructive example in patient 8, Online Resource Figure S5 shows such delays for both WDs: After a transmission break of around 300 min (study min 6530 to 6830), the CORE® has exclusive data transmission for around 10 minutes, leading to an additional delay of around 10 minutes for Everion® data measured on study min 6530 to 6850.Non-typically, transmission then switches to the Everion® for more than 20 min even before complete transmission of the CORE® data.This leads to additionally delayed transmission of CORE® data for min 6530 to 6580, i.e., at the beginning of transmission break, and min 6830 to 6880, when transmission has been re-established for nearly an hour.This Figure displays as well the different transmission modes of the two WDs: The CORE® transmits last-in-first-out (LIFO), i.e. the data measured most recently are transmitted first, before older data.This is the reason of the longer delays of data measured at the beginning of the transmission break compared to more recent data.The Everion®, however, transmits first-in-first-out (FIFO), i.e. the data measured first, thus the oldest data, are transmitted before more recent data.These additional delays were corrected by simulating, in silico, a one gateway per WD setting.
Specifically, the per-second data resulted in large data volumes to be transmitted.The CORE® generated a data volume of 10.2 MB per day, corresponding to 425 kB per hour and 7 kB per minute measuring time, as assessed on study day 9 of patient 37, with 100% coverage (Online Resource Figure S6).The Everion® generated a data volume of 25.9 MB per day, corresponding to 1079 kB per hour and 18 kB per minute measuring time.The median data transmission speed was measured in 10 time periods with exclusive and continuous transmission per WD (Online Resource Figures S7 and S8).The median transmission speed of the CORE® was 30 min of data transmitted per minute, corresponding to 212 kB transmitted per min.The median transmission speed of the Everion® was 12 min of data transmitted per min, corresponding to 90 kB transmitted per min.
Simulating in silico a one gateway per WD setting, avoiding this transmission bottleneck, was based on LIFO transmission at a speed of 30 min data per 1 min transmission time for the CORE®, and on FIFO transmission at a speed of 12 min data per 1 min transmission time for the Everion®.When, in reality, one WD was transmitting, transmission was simulated additionally for the other WD.The effects of this simulation are displayed in Online Resource Figure S9 for the patient 8 example discussed above: For the CORE®, the additional delay for data measured at the beginning of the transmission break is eliminated.Of course, these data remain strongly delayed because of the long transmission break as such.From min 6580 to 6830, the simulated delays coincide with real delays because of the exclusive CORE® transmission time.The delays of CORE® data measured from min 6830 to 6870, due to the subsequent exclusive Everion® transmission time, however, are eliminated.For the Everion®, simulated delays of data measured in the entire transmission break time plus around 30 additional minutes are around 10 minutes lower than delays in reality.The different effects of LIFO versus FIFO transmission are as well visible in these simulation data.Displayed are transmission delay time (on the Y-axis, in minutes) versus study time (on the X-axis, in minutes) of the CORE® (green circles, forming a thick green line here, partially hidden by the Everion® circles/line) and of the Everion® (blue circles, forming a thick blue line here) in patient 37 on nearly the entire study day 9.The horizontal red line indicates 30 minutes delay, the limit between timely and delayed transmission.The black lines below 0, forming a black band here, indicate that both the CORE® and the Everion® transmitted in the same minute.Displayed are transmission delay time (on the Y-axis, in minutes) versus study time (on the X-axis, in minutes) of the CORE® (green circles, forming a thick green line here) in patient 1 on nearly the entire study day 3.The delay has originated in this section of study time because the Everion® was transmitting exclusively (blue lines below 0, forming a blue band here).Transmission of the CORE® is beyond the right margin of the figure, and thus not visible here.The horizontal red line indicates 30 minutes delay, the limit between timely and delayed transmission.

FigureFollow
Not meeting inclusion criteria (n= 7)  chemotherapy too short or no chemotherapy (n=4)  age <1month or ≥ than 18 years old (n=3)  Not asked for informed consent (sample size was reached) (n= 28) Patients in study and analysed (n= 20, 280 study days) Declined informed consent (n= 10) Displayed are the results of core temperature recording after correction for data transmission bottleneck, by the CORE® in A) the Everion® B).Legend: green, at least sufficient data quality of core temperature, arriving on dashboard within ≤30min; blue, at least sufficient quality of core temperature, arriving on dashboard after >30min; red: poor data quality; white: no data recorded; Days ok: number of days with ≥ 18h at least sufficient data quality arriving on dashboard within ≤30min per patient; ID: patient ID Online Resource Figure S3 -Impact of improved study setting on Everion® data S6 -Data volume measurement in a section with non-delayed data transmission for CORE® and Everion® S7-Transmission speed measurement in a section with continuous transmission of delayed CORE® data

Transmission delays of CORE® and Everion® data
Displayed are the results of heart rate recording, irrespective of transmission delays, by the Everion® in A) the predecessor study, NCT NCT04134429 (from ref. 10); and B, in this study.Displayed are the results of all participants during the 14 days study period: Core temperature measurements by the CORE® in A) and by the Everion® in B), hear rate in C) and heart rate variability in D) measured by the Everion® in good quality (score ≥50).Red lines: Event with fever or infection.Displayed are transmission delay time (on the Y-axis, in minutes) versus study time (on the X-axis, in minutes) of the CORE® (green circles) and the Everion® (blue circles) in patient 8 during part of study day 5.The delays have originated in this section of study time because neither WD transmitted during 5 hours (white section below 0. Green lines below 0 indicate CORE® transmission, blue lines indicate Everion® transmission, black lines indicate CORE® and Everion® transmission in the same minute).