Wearable integrations can deliver a continuous stream of health data, but receiving the data is only the first step. Product teams still need to define what is expected for each user, evaluate incoming measurements, and build a reliable notification flow when a value falls outside an expected range.
ROOK Health Monitoring System (HMS) is a Beta add-on designed to handle that monitoring layer. It evaluates five supported signals against either a personal baseline or a configured fixed range, then sends alert documents through the client's existing ROOK Data Webhook.
HMS is a health monitoring and notification feature. It is not an emergency service, a medical diagnostic tool, or a clinical decision system.
Five supported signals, two monitoring approaches
- HMS supports resting heart rate, heart rate variability (HRV), resting breathing rate, oxygen saturation (SpO2), and sleep duration.
- Resting heart rate, HRV, and resting breathing rate use a personal baseline with percentage deviations. Oxygen saturation and sleep duration use fixed minimum and maximum ranges. Missing or invalid measurements do not create alerts.
- Signal availability varies by data source, device, user permissions, and synchronization behavior. Clients should verify coverage for their own user population before making customer-facing promises about a specific signal.
The Five Signals
The threshold: ROOK´s default, configurable
A personal baseline for each user
For baseline-based signals, HMS calculates a baseline independently for each user and signal. It can use eligible pre-existing history when available during activation. Otherwise, it needs seven valid days of data before it can evaluate that signal.
Once calculated, the Beta baseline remains static rather than rolling. Until the baseline is ready, HMS skips alert evaluation for that baseline-based signal. Fixed-range signals do not require a personal baseline.
Client-level rules and user-specific overrides
Clients manage stored rules through the Health Monitoring API:
- GET /api/v2/health_monitoring/rulesreturns the stored client-level rule or one stored user-specific rule.
- PUT /api/v2/health_monitoring/rulescreates or fully replaces one rule. It is not a partial update, and every request includes all five signal objects.
Omitting
user_id
selects the client-level scope. Providing user_id
selects that user's rule. The monitoring engine resolves rules in this order: user-specific rule
, client-level rule, then ROOK default.The GET endpoint returns the rule stored for the requested scope. It does not return the resolved effective threshold for each signal. The API does not expose a self-service
DELETE
operation.Two alert documents, one existing delivery flow
HMS creates two product-level data structures:
- alert_event: a near-immediate document created only for an eligible oxygen saturation measurement that breaches its effective fixed-range rule. Delivery depends on when the source sends the measurement to ROOK.
- alert_summary: a daily result evaluated after ROOK receives the user's sleep summary. It can contain resting heart rate, HRV, resting breathing rate, oxygen saturation, and sleep duration breaches, with at most one entry per signal for the evaluated day.
Users who do not generate a sleep summary do not generate an
alert_summary
in this release. Evaluation timing depends on when the source synchronizes the sleep summary and is not guaranteed at a fixed clock time. Both alert types use the client's existing Data Webhook; HMS does not provide an endpoint for retrieving previously generated alerts.
Link to complete JSON examples HERE
Activation
For now, The Health Monitoring System is presented as a Beta add-on. Clients can contact the ROOK support team or their account manager to request activation. Further down the road we will introduce HMS as a new product within the ROOK Signals product category - part of web 3.0 and tech-docs 3.0 launch.
The feature is enabled by default for all clients in Sandbox in order for them to test fast and at any given moment.
Initial pricing:
Health Monitoring System FAQ
1. What is Health Monitoring System?
- Health Monitoring System is a ROOK add-on that evaluates supported wearable-derived health signals against a personal baseline or configured fixed range. When a valid measurement breaches the effective rule, HMS can create an alert document for delivery through the client's existing ROOK Data Webhook.
2. What problem does HMS solve?
- Without HMS, a client receiving wearable data would need to build baseline calculations, threshold evaluation, alert-document generation, and the associated monitoring workflow. HMS centralizes that logic so product teams can focus on how their applications use the alerts.
3. Which signals does HMS monitor?
- The Beta release supports resting heart rate, HRV, resting breathing rate, oxygen saturation, and sleep duration. Resting heart rate, HRV, and resting breathing rate use personal baselines. Oxygen saturation and sleep duration use fixed ranges.
4. Does HMS monitor heart rate during exercise?
- No. This release monitors resting heart rate. Exercise heart rate is outside the current scope.
5. Does HMS monitor body temperature, blood pressure, glucose, or ECG?
- No. These signals are outside the confirmed Beta scope.
6. How is a personal baseline calculated?
- HMS calculates a baseline independently for each user and baseline-based signal. It can use eligible pre-existing data when available, but that history is not mandatory. Without it, HMS needs seven valid days of new data. Once calculated, the initial Beta baseline remains static rather than rolling.
7. What happens before a baseline is ready?
- HMS skips alert evaluation for that baseline-based signal. Oxygen saturation and sleep duration use fixed ranges and do not depend on a personal baseline.
8. Is data from different sources combined into one baseline?
- The implementation uses prioritized sources and deduplication, and it preserves the selected HRV metric family rather than mixing RMSSD and SDNN values in one baseline.
9. Can clients configure their own rules?
- Yes. The API supports a client-level rule and user-specific rules. A user-specific rule takes priority for that user, followed by the client-level rule and then the ROOK default. Thecurrent PUTcontract creates or fully replaces a rule and requires a complete configuration rather than a partial update.
10. Does one client-level percentage create a shared baseline for all users?
- No. Each user's baseline remains individual. A client-level percentage is applied separately to each user's own baseline.
11. How can a client read or change a stored rule?
- Use GET /api/v2/health_monitoring/rulesto read one stored scope andPUT /api/v2/health_monitoring/rulesto create or fully replace one scope.Both operations support Basic or Bearer authentication and require Health Monitoring to be enabled for the client.
12. Does GET return the effective rule used by HMS?
- No. It returns exactly what is stored for the requested client-level or user-specific scope. The monitoring engine applies precedence and resolves the effective rule.
13. How does a client remove a user-specific rule?
- The current API does not provide a self-service DELETEoperation. Sending the same values as the client-level rule does not remove the user-specific override and does not make it inherit future client-level changes. A stored rule can only be replaced with another completePUT.
14. Is HMS a real-time monitoring system?
- Not in the emergency-monitoring sense. Only oxygen saturation can create a near-immediate alert_event, and only after ROOK receives an eligible measurement from the source. HMS does not continuously poll wearable providers or guarantee emergency-response latency.
**15. What is the difference between
alert_event
and alert_summary
?**- alert_eventis limited to oxygen saturation in this release.alert_summaryis a daily result that can contain breaches for any of the five supported signals, with at most one entry per signal for the evaluated day.
16. When is the daily alert summary delivered?
- The evaluated day is normally the sleep_date reported by the sleep summary. If that value is missing or invalid, HMS derives the date from the summary's sleep-end timestamp and then its event timestamp. Timezone resolution prefers a valid IANA timezone, then an explicit Z or +/-HH:MM offset, and finally UTC. These fallbacks keep processing available, although UTC or a fixed offset can classify measurements near midnight differently and a fixed offset does not model daylight-saving changes.
17. What happens if a sleep summary is corrected later?
- The expected behavior is to recalculate that day's result for the same user based on the most recent document version (sleep_summary.document_version); if that event occurs, a newalert_summarywith a higherdocument_versionwill be generated
18. What happens when data is missing or invalid?
- Missing data is not interpreted as a threshold breach. HMS skips null or invalid values and signals that cannot be evaluated.
- A user without a sleep summary does not produce an alert_summaryin this release.
19. Will every connected ROOK user receive HMS alerts?
- No. A user must synchronize at least one supported signal, and baseline-based signals require enough valid history. Availability depends on the source, device, granted permissions, and synchronization frequency.
20. Which wearable and data sources are supported?
- HMS reads data already synchronized through ROOK and supports prioritized sources and fallbacks, but coverage is not uniform across signals or providers.
21. Does HMS detect sustained trends or combine multiple signals?
- No. This release evaluates each supported signal independently. Rolling baselines, sustained multi-day trend detection, automatic anomaly detection, multi-signal composition, predictions, and recommendations are outside the confirmed scope.
22. Does HMS classify alerts by severity?
- No. HMS reports that a value breached an effective threshold and identifies whether it was above or below the range. It does not assign clinical severity levels.
23. Does HMS provide a diagnosis or medical recommendation?
- No. HMS does not diagnose medical conditions, recommend treatment, predict outcomes, or replace professional medical judgment or emergency services.
24. Does HMS connect directly to a wearable?
- No. HMS evaluates data already synchronized through ROOK. Users must first connect a compatible data source and allow the relevant data to sync.
25. How are alerts delivered?
- ROOK sends alert_eventandalert_summarydocuments through the existing Data Webhook. Clients do not configure a separate HMS webhook, and HMS does not provide an endpoint for retrieving generated alerts.
26. Is configuration available in the ROOK Portal?
- No. Portal configuration is outside the confirmed Beta scope. Configuration is API-first.
27. How can a client enable HMS?
- The add-on is enabled in Sandbox by default - contact the ROOK support team or your account manager to request activation of the Beta add-on in Production.