“Health Monitoring” is a ROOK Signals product that watches the wearable data already flowing through your integration and tells you when something falls outside the expected range. It evaluates five signals — resting heart rate, HRV, resting breathing rate, oxygen saturation and sleep duration — against either a deviation from each user's own personal baseline or a fixed range you configure, and delivers an alert document through your existing Data Webhook when a valid measurement breaches its rule. This article covers what HMS monitors, how personal baselines are built, what you need in place before it will produce anything, and — just as importantly — the things HMS deliberately does not do. Read the scope limits before you design any user-facing experience on top of it.
Topics
What Health Monitoring does
What Health Monitoring is not (scope limits)
Prerequisites
Supported signals
How personal baselines work
Handling of missing or invalid data
Activation in Sandbox and Production
Configuration model
Next steps
Key terms
Health Monitoring (HM) · personal baseline · seven valid days · baseline deviation vs. fixed range · Data Webhook · Sandbox vs. Production activation · signal coverage · not a diagnostic tool
What the “Health Monitoring” does
Health Monitoring evaluates wearable-derived health signals that are already synchronizing through your ROOK integration. When a valid measurement falls outside its effective rule — either a deviation from the user's personal baseline or a configured fixed range — HMS creates an alert document and delivers it through your existing ROOK Data Webhook.
Without HMS, your team would need to build baseline calculation, threshold evaluation, alert generation, and the surrounding notification workflow yourselves. HMS centralizes that logic so you can focus on what your application does with the alert.
What Health Monitoring is not
Please read this section before you design any user-facing experience on top of HMS.
Not an emergency service. HMS does not guarantee emergency-response latency and does not continuously poll wearable providers.
Not a diagnostic or clinical decision tool. HMS does not diagnose conditions, recommend treatment, predict outcomes, or replace professional medical judgment.
Not a severity classifier. An alert tells you a value breached its effective threshold and whether it was above or below the range. It carries no clinical severity level.
Not a trend or anomaly engine. Each signal is evaluated independently. Rolling baselines, multi-day trend detection, multi-signal composition, predictions, and recommendations are not part of the current version.
Prerequisites
An active ROOK integration with a configured Data Webhook. HMS reuses it — there is no separate HMS webhook.
Health Monitoring enabled on your client account (see Activation below).
For each end user: a connected, compatible data source with the relevant permissions granted, and data actually synchronizing to ROOK.
HMS does not connect to wearables directly. It only evaluates data that has already reached ROOK.
Supported signals
Signal | Evaluation method | Needs a personal baseline? |
Resting heart rate | Percentage deviation from personal baseline | Yes |
Heart rate variability (HRV) | Percentage deviation from personal baseline | Yes |
Resting breathing rate | Percentage deviation from personal baseline | Yes |
Oxygen saturation (SpO2) | Fixed minimum / maximum range | No |
Sleep duration | Fixed minimum / maximum range | No |
Signal coverage varies
Availability depends on the data source, the specific device, the permissions the user granted, and how often that source synchronizes. Coverage is not uniform across signals or providers.
Recommendation: verify coverage against your own user population before making customer-facing promises about a specific signal.
How personal baselines work
For the three baseline-based signals, HMS calculates a baseline independently for each user and each signal.
If eligible pre-existing history is available when HMS is activated for that user, HMS can use it.
Otherwise, HMS needs seven valid days of data for that signal before it can evaluate anything.
Until the baseline is ready, HMS skips alert evaluation for that signal. This is expected behavior, not a failure.
In the current version of HMS, the baseline is static after startup — it does not roll forward as new data arrives.
Where multiple sources are available, the implementation uses prioritized sources and deduplication. For HRV it preserves the selected metric family rather than mixing RMSSD and SDNN values into one baseline.
A client-level percentage does not create a shared baseline. Each user keeps their own baseline; your percentage is applied separately to each one.
Baseline-based signals also apply a minimum absolute delta (a floor), so a small percentage of a low baseline does not produce noisy alerts. See Configuring Your Health Monitoring Rules for the exact values.
Oxygen saturation and sleep duration use fixed ranges and are evaluated as soon as valid measurements arrive — no waiting period.
Handling of missing or invalid data
Missing data is never treated as a breach. HMS skips null values, invalid values, and any signal it cannot evaluate. No alert is generated in those cases.
Activation
Sandbox: enabled by default for all clients, so you can test immediately.
Production: contact ROOK support or your account manager to request activation of HMS.
Configuration model
Configuration is API-first. Rules are managed through the Health Monitoring API. Configuration through the ROOK Portal is not part of the current version.
Next steps
Configuring your Health Monitoring rules — scopes, precedence, defaults, and the full-replacement contract.
Understanding and troubleshooting Health Monitoring alerts — alert_event vs. alert_summary, delivery, and a no-alerts checklist.
For pricing and packaging, contact your account manager.