A Scalable Patient Monitoring System Using Apache Storm
Bibliographic record
Abstract
The growth in wearable medical sensor-based technologies has made it possible to capture high volume physiological data of patients, both within and outside the hospital. The acquired physiological data are analyzed, usually in real-time, using a patient monitoring application for early disease detection or to detect any other changing conditions of a patient. In some cases, it is desirable to have a distributed, scalable patient monitoring system to which the physiological data of different patients can be submitted for online analysis. Such a system should be able to support the concurrent analysis of multiple data streams of different patients, allowing a clinician to remotely monitor more than one patient from a single location. This type of system also conserves resources, since in this case, there is no need to provision computational resources for every single patient being monitored. In this paper, we explore the usability of Apache Storm, an open-source real-time processing engine, in the development of such a scalable patient monitoring system. The contribution of this work, therefore, is to demonstrate that it is possible to achieve a more resource-efficient alternative to the isolated patient monitoring systems by using a distributed real-time computation platform, Apache Storm, to develop a scalable health monitoring system that can support the concurrent monitoring of multiple patients. To show how the proposed system can be developed, we describe a prototype implementation of a multi-tenant health monitoring application that monitors the arrhythmia status of multiple patients, based on a simple ECG analysis, using Apache Storm.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.004 |
| Meta-epidemiology (narrow) | 0.001 | 0.000 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.001 | 0.002 |
| Open science | 0.002 | 0.003 |
| Research integrity | 0.000 | 0.001 |
| Insufficient payload (model declined to judge) | 0.004 | 0.002 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".