The motivation is rooted in a familiar limitation of critical care monitoring. Conventional ICU devices excel at point measurements—heart rate, blood pressure, oxygen saturation—but they attach to the patient and capture little of the spatial information written on the body’s surface. Patterns of peripheral perfusion, localized inflammation, or uneven temperature distribution can carry early signals of deterioration, yet standard multiparameter monitors are largely blind to them. Infrared thermography offers a way in: a radiometric thermal camera can map surface temperature remotely, without touching the patient, and previous studies have used thermal imaging to estimate respiratory rate and other vital signs. The catch, the authors note, is that most of that evidence comes from controlled laboratory prototypes, small cohorts, or algorithm-centered studies that never faced the realities of a hospital ward.

Those realities are formidable. Any system deployed in a modern hospital must pass through institutional information technology governance: network segmentation, cybersecurity policy, bandwidth limits, authentication requirements, and data protection law. Public cloud architectures, common in commercial Internet of Medical Things products, are often difficult or impossible to approve in European hospitals that must comply with the General Data Protection Regulation and maintain local control over patient-related data. The Madrid team therefore built their system entirely on-premise. Seven acquisition nodes—each a Raspberry Pi 4B single-board computer paired with a low-cost radiometric thermal camera of 256 by 192 pixel resolution—were installed at ICU beds, with the architecture designed to scale to all thirteen beds in the unit. Each node captured one thermal image per second, tagged it with timestamps and temperature statistics, and streamed it over the hospital’s existing Wi-Fi network to a local server for storage, indexing, and near real-time visualization. No parallel network was created, and no external cloud service touched the data.

Privacy was engineered into the hardware rather than bolted on afterward. Unlike clinical video systems, which typically require post-hoc de-identification steps such as blurring faces before footage can be released, the low-resolution radiometric thermal sensor cannot resolve the optical facial features needed to identify a person in the first place. Non-identifiability is a structural property of the acquisition modality itself, not a downstream processing step that could be omitted, misconfigured, or reversed. The database stored only bed identifiers and technical metadata, image acquisition was conditional on informed consent and activation by authorized personnel, and the study was approved by the relevant research ethics committee under approval number CEIm 23/63, conducted in accordance with the Declaration of Helsinki.

The first deployment phase delivered a humbling lesson in systems engineering. In its initial configuration, with synchronous image transmission and accumulating queues, the system buckled under sustained load. Analysis of 127,618 latency samples revealed a mean end-to-end delay—the time between image capture at the bedside and availability on the dashboard—of 26,344 milliseconds, with a median of 20,616 milliseconds and a 95th percentile reaching nearly 84 seconds. Images were piling up in transmission queues faster than they could be processed, turning a nominally real-time system into a delayed archive. The fix came not from replacing hardware but from rethinking the data flow: the team decoupled image reception from persistence, prioritized the most recent frame for visualization, improved queue management, and adjusted capture and transmission parameters, allowing older frames to be retransmitted asynchronously when bandwidth allowed.

The results of that architectural overhaul were dramatic. Across 6,917,464 subsequent latency samples, mean end-to-end latency fell to 126 milliseconds—a 99.52 percent reduction—with a median of 117 milliseconds and a 95th percentile of just 207 milliseconds. Crucially, the improvement extended to the upper tail of the distribution, confirming that prolonged queue accumulation had been eliminated rather than merely reduced. The system had been transformed, in the authors’ framing, from a delayed acquisition platform into a genuinely near real-time monitoring infrastructure, achieved purely through software and data-flow design on the same inexpensive sensing hardware.

With the optimized architecture in place, the team ran a structured ten-day evaluation with all seven nodes active. The system generated 5,763,312 thermal images, roughly 1.47 terabytes of data at an average of 275 kilobytes per image and about 147 gigabytes per day. The aggregate acquisition rate of 6.67 images per second came remarkably close to the nominal target of seven, indicating that the system held nearly full capture capacity under real operating conditions. Latency remained stable throughout the evaluation, showing no progressive deterioration as the stored dataset grew into the millions of images—a sign that the hybrid persistence strategy, with raw images in a hierarchical file system and metadata indexed in a PostgreSQL database, could sustain continuous long-term operation. Server resource use stayed almost trivially low, with mean CPU utilization of just 0.66 percent and mean RAM usage of 6.93 percent, leaving ample headroom for the planned expansion to thirteen beds.

The system was not flawless, and the failure modes it exhibited are themselves informative. Effective availability during the evaluation was 95.29 percent, with the shortfall traced almost entirely to transient wireless connectivity interruptions and local node issues rather than any failure of the central server or storage infrastructure. Telemetry recorded 44 Wi-Fi interface drop or reconnection events, cumulatively lasting 106,218 seconds, with individual incidents ranging from the ten-second minimum observable interval to a maximum of 40,807 seconds. Some nodes, labeled BOX7 and BOX8, showed larger temporal discontinuities, while BOX9 and BOX11 behaved most consistently. The team also contended with clock synchronization drift between nodes and server, addressed through network time synchronization and a dual timestamp strategy, and with power supply instability in some devices, mitigated by stabilizing the supply. The pattern is a familiar one in hospital deployments: the bottleneck is rarely computation or storage, but the shared, policy-constrained wireless environment that research systems must coexist with.

The authors are careful to frame this as foundational infrastructure rather than a clinical tool. The dashboard at this stage provides no alarms, no diagnostic interpretation, and no automated decision support, and the reported temperature metrics were computed over the entire thermal frame rather than a patient-isolated region, so they cannot be read as validated measurements of body temperature—bedding and nearby equipment could fall within the field of view. This deployment is explicitly the first of two phases in the approved research protocol, establishing technical feasibility, reliability, and governance compliance before a planned second phase evaluates clinical utility, including automated detection of patient falls, self-extubation, pressure ulcer development, and cardiac arrest, a role in differentiating septic, cardiogenic, and hypovolemic shock, and monitoring of postoperative recovery of normothermia. The team also acknowledges honest limitations: transport between nodes and server used HTTP without TLS encryption, a risk mitigated by network-layer isolation but flagged as a security-hardening priority; no formal penetration testing was performed; the study was single-center with one hardware configuration; and scalability to the full thirteen-bed configuration was projected from operational trends rather than directly tested. The system remains a pre-product research infrastructure, not a certified medical device.

Even with those caveats, the study offers a rare and valuable data point: a complete, quantified account of what it actually takes to run a distributed medical sensing network inside a live ICU. The practical lessons the authors distill—deploy progressively rather than all at once, coordinate closely with hospital IT teams from day one, build local buffering and asynchronous transmission into the architecture for resilience, and evaluate operational metrics like latency, availability, and storage growth rather than sensor accuracy alone—read as a reference model for anyone attempting similar deployments. As hospitals edge toward AI-assisted, contactless monitoring, the hardest problems may not be in the algorithms at all, but in the unglamorous plumbing of queues, clocks, tokens, and Wi-Fi. In Madrid, at least, that plumbing now works, one thermal frame at a time.

Subject of Research: On-premise thermal Internet of Medical Things monitoring in an intensive care unit

Article Title: Real-World Deployment and Operational Evaluation of an On-Premise Thermal IoMT System in an Intensive Care Unit

Article References: Avilés, E., Lafuente, J.-L., González, S., & Beunza, J.-J. (2026). Real-World Deployment and Operational Evaluation of an On-Premise Thermal IoMT System in an Intensive Care Unit. Journal of Medical Systems, 50(1), Article 144. https://doi.org/10.1007/s10916-026-02455-5

Image Credits: AI Generated

DOI: 10.1007/s10916-026-02455-5

Keywords: Internet of Medical Things, thermal imaging, intensive care unit, patient monitoring, on-premise architecture, hospital IT governance, Raspberry Pi, infrared thermography, latency optimization, data privacy, edge computing, critical care