Category: AI in Healthcare
Wearables can transform continuous physiological signals into predictive alerts when the data is reliable, contextualized in the electronic health record, and analyzed by clinically validated models. The goal is not to replace medical assessment, but to identify deterioration trends early enough for a care team to confirm the risk and intervene.
What continuous telemetry with wearables is
Continuous telemetry is the recurring collection of physiological signals by connected devices, followed by transmission, processing, and presentation to a healthcare team. Depending on the wearable and its intended purpose, the following may be monitored:
- heart rate and heart rate variability;
- peripheral oxygen saturation, or SpO₂;
- estimated respiratory rate;
- skin or body temperature;
- blood pressure, when supported by an appropriate device;
- single-lead or multi-lead electrocardiogram;
- physical activity, steps, posture, and periods of immobility;
- sleep and rest patterns;
- glucose, in the case of specific sensors.
“Continuous” does not necessarily mean one sample every millisecond. One sensor may produce high-frequency ECG data, while another records temperature every minute or consolidates activity into five-minute windows. The appropriate frequency depends on the clinical phenomenon, battery life, connectivity, and the expected response time.
It is also necessary to distinguish wellness devices from equipment intended for clinical use. A consumer watch may be useful for longitudinal monitoring, but its data should not automatically be treated as equivalent to data from a hospital monitor. Intended use, technical documentation, validation, and applicable regulatory requirements must be considered during selection.
How the remote monitoring architecture works
A remote patient monitoring platform, or RPM, typically has six layers.
1. Device and acquisition
The wearable measures the signal and records metadata such as time, reading quality, battery level, and conditions of use. Without reliable time synchronization and correct device identification, the time series loses clinical value.
2. Communication
Transmission may use Bluetooth to send data to a smartphone or gateway, followed by Wi-Fi or a mobile network to the cloud. In environments with unstable connectivity, the application should store data locally, prevent duplicates, and resend events when the connection is restored.
3. Ingestion and normalization
The platform receives different formats, converts units, and associates each observation with the correct patient. This layer also checks for impossible values, gaps, delays, and time zone changes.
4. Storage and interoperability
High-frequency raw data may remain in a time-series repository, while clinically relevant observations are integrated into the hospital ecosystem. In FHIR, resources such as Patient, Device, Observation, Encounter, and CarePlan help represent the context. Legacy systems may require HL7 v2 messages, such as results sent through ORU^R01.
5. Rules and predictive models
The platform runs clinical thresholds, trend analyses, and machine learning models. The result should include the risk level, relevant variables, inference time, and model version.
6. Care workflow
The alert reaches a queue with an assigned person, priority, response deadline, and escalation procedure. Without this final layer, there is only a technical dashboard, not a clinical monitoring process.
From fixed thresholds to predictive alerts
A traditional alert is triggered when a variable exceeds a threshold—for example, SpO₂ below a certain value. It is simple and auditable, but it may overlook gradual deterioration or generate many false positives for patients whose baseline patterns are different.
Predictive alerts combine history, rate of change, and multiple variables. A model may consider a persistent decrease in saturation, an increase in respiratory rate, an elevated heart rate, and reduced mobility. This combination may signal risk before a single parameter crosses a critical threshold.
There are three main approaches:
- Clinical rules: easy to explain and appropriate when clear protocols exist.
- Personalized anomaly detection: compares the patient with their own baseline pattern.
- Supervised models: estimate the probability of an outcome using labeled historical data.
In practice, hybrid architectures tend to be more controllable: rules block clearly invalid situations, the model estimates risk, and a clinical policy determines when to send a notification.
How to measure whether the alert actually works
AUROC alone is not sufficient to approve a clinical system. The evaluation must consider the population, outcome, prevalence, and actual operation.
The minimum metrics include:
- sensitivity: proportion of actual events detected;
- specificity: proportion of cases without an event that are correctly ruled out;
- positive predictive value: how many alerts actually correspond to the outcome;
- alerts per patient/day: a direct measure of operational workload;
- lead time: interval between the alert and the clinical event;
- calibration: closeness between predicted risk and observed frequency;
- missing data: percentage of time without usable telemetry;
- time to acknowledgment: how long the team takes to view and classify the alert.
An overly sensitive model can overwhelm the team. A highly specific model may fail to identify patients who are deteriorating. The threshold should be selected according to outcome severity, response capacity, and the clinical cost of false positives and false negatives.
Validation should occur in stages: retrospective, temporal, external when compatible data is available, and prospective in silent mode. In this final stage, the model generates predictions without affecting care, allowing performance and alert workload to be measured before activation.
How to reduce alert fatigue
Alert fatigue occurs when the volume or low relevance of notifications causes professionals to start ignoring them. It is a safety and operational design issue.
Practical measures include:
- requiring persistence over a time window before issuing an alert;
- grouping related events into a single episode;
- applying personalized thresholds when clinically justified;
- suppressing new notifications while a case is being handled;
- raising the priority only when risk increases;
- recording reasons for dismissal to recalibrate the system;
- routing each severity level to the appropriate professional role;
- tracking alerts by shift, unit, and patient/day.
Every alert must answer four questions: what happened, why the patient was flagged, how urgent it is, and what action should be considered. The recommendation must comply with institutional protocols and leave the decision to the qualified professional.
Data quality and common failures
Wearables are subject to motion artifacts, inadequate skin contact, low perfusion, drained batteries, and incorrect use. The platform must distinguish an absent signal from clinical normality.
Before running a model, checks such as the following should be applied:
- is the value within physically plausible limits?
- does the received unit match the expected unit?
- does the signal have an acceptable quality indicator?
- are the sensor and server timestamps synchronized?
- was there a change of patient, device, or sensor position?
- what percentage of the window contains valid data?
Imputing gaps without recording the procedure may create stability that never existed. Estimated data must be identified, and the system must prevent inferences when minimum coverage is not reached.
Security, privacy, and governance
Health data is sensitive personal data under Brazil’s General Data Protection Law, or LGPD. Deployment must define purpose, legal basis, retention, sharing, and data subject rights, with the involvement of legal and privacy officers.
Recommended technical controls include encryption in transit and at rest, multifactor authentication for teams, segregation by organization, least privilege, audit trails, and key management. Devices, applications, and APIs also require updates, inventory management, and incident response.
For AI, governance must record the model version, set of variables, threshold, validated population, and changes made. Performance and calibration must be monitored after the system enters production, including across relevant clinical groups, because changes in the patient profile or device may cause drift.
Checklist for implementing remote monitoring
Before getting started, the institution should confirm:
- [ ] defined clinical outcome and target population;
- [ ] sensor appropriate for the purpose and usage environment;
- [ ] protocol for loss of connection or battery power;
- [ ] electronic health record integration through FHIR, HL7 v2, or a documented API;
- [ ] patient identity reconciled across systems;
- [ ] signal quality and coverage metrics;
- [ ] assigned personnel and deadlines for each alert level;
- [ ] clinical and prospective validation before automation;
- [ ] recording of alert viewing, classification, and outcome;
- [ ] security, privacy, and retention controls;
- [ ] contingency plan for downtime;
- [ ] continuous monitoring of false positives, drift, and fatigue.
The decision between building and buying depends on the desired differentiation. An off-the-shelf solution reduces initial implementation time but may limit integrations and rules. Custom software provides greater control over data and care workflows, but it requires ongoing maintenance, clinical governance, and engineering.
How Predictor Solutions addresses this
Predictor Solutions develops custom healthcare systems with HL7 v2 and FHIR integration, data engineering, cloud/DevOps, security, and applied artificial intelligence. Its work includes telemetry ingestion, signal normalization, dashboards, audit trails, clinical rules, and predictive models integrated into operational workflows.
Predictor Health brings together healthcare dashboards and wearable data. Predictor AI Hospitals focuses on predicting sepsis, heart attacks, and pneumonia in ICUs; its application requires validation with each institution’s population and protocols, as well as professional oversight.
Across the projects delivered by the software house, which has served nine medium-sized and large companies, the reported overall results include average savings of R$ 1.32 million per client per year, an average productivity increase of 70%, and profit growth of 43% in six months. These figures represent the project portfolio and should not be interpreted as the clinical effectiveness of a specific wearable or model.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.