Wearables make it possible to monitor physiological signals between appointments, but they only deliver clinical value when telemetry is reliable, contextualized, and linked to a response protocol. Predictive alerts should combine time series, patient history, and clinical rules, with prospective validation and human oversight before guiding any intervention.
What continuous telemetry with wearables is
Continuous telemetry is the recurring collection of physiological or behavioral data by connected devices, followed by transmission, processing, and presentation to a care team. In practice, “continuous” does not always mean one sample per second: watches, sensors, oximeters, and patches may record data at different frequencies or periodically send batches.
The most commonly used data include:
- heart rate and heart rate variability;
- peripheral oxygen saturation;
- estimated respiratory rate;
- skin or body temperature;
- blood pressure, when supported by appropriate equipment;
- one-lead or multi-lead electrocardiogram;
- sleep, physical activity, steps, and estimated energy expenditure;
- falls, posture, gait, and periods of immobility;
- interstitial glucose from specific devices.
The difference between a metrics dashboard and a clinical system lies in the decision workflow. A care system must identify which patient generated the event, assess quality and context, define priority, route the alert, and record what was done.
How a remote monitoring architecture works
A robust architecture usually has six layers.
1. Device and data collection
The wearable measures a raw signal or an estimate calculated by the manufacturer. It is necessary to understand the sampling frequency, units, margin of error, positioning, battery life, and conditions that impair the reading.
Movement, sweat, reduced peripheral perfusion, skin tone, improper fit, and use outside the recommended position may introduce artifacts. Therefore, an isolated value should not automatically be treated as evidence of deterioration.
2. Application or gateway
The data may pass through a smartphone, home hub, or hospital gateway using Bluetooth, Wi-Fi, or a mobile network. This layer must handle pairing, authentication, temporary storage, and retransmission after a connection loss.
The minimum operational indicators include:
- percentage of time with an available signal;
- delay between measurement and ingestion;
- number of disconnections per day;
- average duration of gaps;
- firmware version and battery status.
3. Ingestion and normalization
The platform receives events, converts units, removes duplicates, and associates each reading with the correct patient and device. It is important to preserve the original data, processed data, measurement time, and arrival time.
FHIR can represent information through resources such as Patient, Device, Observation, Encounter, and CarePlan. In legacy environments, HL7 v2 messages, such as ORU, can carry results, requiring an integration and semantic mapping layer.
4. Time-series processing
Quality filters, moving windows, and aggregations help distinguish trends from noise. Examples include a five-minute median, variation relative to the individual baseline, and persistence of a change across multiple windows.
Missing data should not be filled in silently. The system must indicate whether the absence represents a disconnection, device removal, or processing failure.
5. Risk and alert engine
The engine may use fixed thresholds, compound rules, statistical models, or machine learning. A useful output is not merely a score: it should present the risk level, relevant variables, trend, signal quality, and action recommended by the institutional protocol.
6. Care workflow and auditing
The alert must reach the right person, through the right channel, and within the defined time frame. The platform must record delivery, reading, acknowledgment, escalation, decision, and outcome, creating an auditable trail.
From fixed thresholds to predictive alerts
A fixed threshold, such as oxygen saturation below a specific value, is simple to explain but ignores the patient’s baseline and the combination of signals. This can generate excessive alarms or detect deterioration too late.
Predictive alerts seek to estimate the probability of an event within a future time window. Models may consider:
- the trend and rate of change of signals;
- variability and correlation among variables;
- age, comorbidities, and available clinical history;
- recent medications and interventions;
- activity, sleep, or mobility patterns;
- hospitalization, postoperative, or home care context;
- quality and quantity of available data.
AI does not eliminate clinical rules. A hybrid approach is usually more controllable: safety rules address known critical situations, while the model detects multivariate patterns or deviations from the baseline.
How to reduce alarm fatigue
Alarm fatigue occurs when too many irrelevant alerts reduce staff attention. High sensitivity alone does not solve the problem: if the positive predictive value is low, professionals will need to review many cases without actual deterioration.
Practical measures include:
- Require persistence: avoid issuing an alert based on a single abnormal sample.
- Combine variables: confirm a signal with a trend, symptom, or another measurement.
- Personalize the baseline: compare the patient with their own baseline when clinically appropriate.
- Apply controlled silence periods: prevent repeated notifications without concealing worsening conditions.
- Separate notification priorities: informational events should not use the same channel as emergencies.
- Consider signal quality: low confidence should trigger a request for a new measurement, not an automatic diagnosis.
- Collect feedback: record whether the alert was useful, false, late, or impossible to assess.
Evaluation metrics should include sensitivity, specificity, positive predictive value, alerts per patient-day, lead time, acknowledgment rate, and time to action. AUROC alone does not indicate how many alarms the operation will need to absorb.
Clinical and technical validation
Historical performance does not guarantee safety in production. The population, event prevalence, equipment, care protocol, and data quality may change.
A responsible process involves four stages:
Retrospective validation
The model is tested on data separate from the data used during development. The split must prevent leakage between records from the same patient and respect chronological order when applicable.
Silent operation
The model runs on real-world data, but its alerts do not change care. This stage measures latency, availability, risk distribution, and expected alarms without exposing patients to decisions that have not yet been validated.
Supervised pilot
A limited team receives the alerts by following a previously approved protocol. Inclusion criteria, responsibilities, escalation, and documentation must be defined.
Post-deployment monitoring
Data drift and changes in the population may degrade performance. The institution should monitor calibration, false negatives, alarm burden, integration failures, and relevant differences among groups.
Security, privacy, and accountability
Health data is sensitive personal data under the LGPD. The project must apply necessity, purpose limitation, access control, traceability, and protection during transmission and storage.
The technical checklist includes:
- encryption in transit and at rest;
- strong authentication and role-based access;
- device inventory and credential revocation;
- logs protected against improper modification;
- retention and disposal policy;
- incident response plan;
- segregation between development and production environments;
- assessment of vendors, SDKs, and external APIs;
- operational continuity during internet outages.
Regulatory classification depends on the intended purpose and the use of the software or device. A wellness solution, a decision-support dashboard, and a system that influences clinical management may have different requirements; this analysis should involve clinical, legal, security, and regulatory teams.
Criteria for determining whether the project is ready
Before deploying remote telemetry, the organization should objectively answer:
- Which clinical or operational event will be detected?
- What minimum lead time allows for useful action?
- Who receives the alert, and how quickly must they respond?
- What happens during a connection loss?
- How many alerts per patient-day can the team review?
- Is there integration with the electronic health record, admission data, and patient identification?
- Does the wearable measure the variable directly or merely estimate it?
- Has performance been evaluated in the target population?
- Is there a protocol for false positives and false negatives?
- Is it possible to reconstruct each decision from the logs?
If these answers have not been defined, adding AI tends to automate an ambiguous operation rather than resolve it.
How Predictor Solutions solves this
Predictor Solutions develops healthcare systems with HL7 v2 and FHIR integrations, data engineering, cloud infrastructure, security, and applied artificial intelligence. Its work combines telemetry ingestion, clinical normalization, time-series processing, dashboards, alert engines, and audit trails, without replacing the institution’s necessary clinical and regulatory validation.
Predictor Health is a healthcare dashboard integrated with wearables. Predictor AI Hospitals, in turn, focuses on predicting sepsis, heart attacks, and pneumonia in the ICU—scenarios in which temporal data quality, operational explainability, and alarm fatigue control are core requirements.
The company is based in Lavras, Minas Gerais, and has served nine medium-sized and large organizations. Across its project portfolio, it reports 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 are overall results and should not be interpreted as evidence of the specific clinical effectiveness of a wearable or predictive model.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.