Elder Alert Routing: Who Receives the Alert and in What Order
What “Elder Alert Routing” Means in Practice
Elder alert routing refers to the deterministic order in which notifications are sent when a wearable or companion device detects a predefined event — such as prolonged immobility or a fall-like motion. It is not a networked service but a local client-side behaviour governed by the companion app’s logic. The Health & Wellness line supports this through firmware-level triggers that initiate voice calls only. No model transmits biometric data to a server for analysis; all motion and posture inference runs on-device. This design choice simplifies CE RED compliance and avoids GDPR data transfer complications, but it also means routing is static once configured and tied to the user’s Android or iOS environment.
How Contact Lists Are Managed and Secured
Contact lists are created and edited exclusively within the companion app on the primary caregiver’s smartphone. There is no web portal, no admin dashboard and no remote push capability. Each contact entry stores only name, number and sequence position — no email, no address, no secondary identifiers. The list is encrypted at rest using platform-native keychain APIs (iOS Keychain, Android Keystore), and never leaves the device. For distributors evaluating white-label options, note that OEM/ODM services can rebrand the app interface but do not alter this local storage architecture. Firmware or app white-label requires a minimum order of 2,000 units, as detailed in our MOQ, sampling and lead times policy.
Escalation Rules and Their Limits
Escalation is strictly linear and time-bound: after three unanswered calls to Contact 1, the app dials Contact 2. If Contact 2 does not answer within the same window, Contact 3 is called. There is no parallel dialling, no SMS confirmation loop and no fallback to email or push notification. Critically, the system does not detect whether a call was answered — only whether the call was declined, ended early or timed out. This means a call answered but not engaged with still triggers escalation. Because of this limitation, the health smartwatch and health ring are explicitly positioned as wellness companions, not emergency-response hardware. Distributors must ensure packaging and marketing materials reflect this boundary.
False Alarm Handling and User Confirmation
Every alert requires explicit user confirmation before escalation begins. On the smartwatch, this is a two-second press-and-hold on the side button. On the ring, it is a triple tap detected by the onboard IMU. Without confirmation, no call is placed — even if motion algorithms suggest a fall. This design reduces false alarms but introduces dependency on user responsiveness. It also means the system cannot act autonomously during unconsciousness or cognitive impairment. As outlined in our factory policy, all health metrics are wellness guidance only; none support diagnosis, monitoring or clinical intervention. The companion robot follows the same principle: it may prompt verbally but will not initiate external contact unless manually confirmed.
Compliance Boundaries You Must Enforce
This is the section where importers should say no. No WingPhoenix device carries EN 50628, EN 50134 or IEC 62304 certification. None are registered as medical devices under MDR or UK MDR. CE marking covers only radio (RED), EMC and safety (EN 62368-1), as verified per hardware revision in our CE RED document checklist. Any supplier claim suggesting otherwise — including “emergency-ready”, “PSAP-connected”, or “certified for fall response” — contradicts published factory policy and invalidates your importer liability coverage. Do not accept firmware updates or cloud features that introduce untested alert pathways. All revisions undergo IQC / IPQC / FQC / OQC gates at AQL 2.5 major, and documentation is issued per build — see how we build and test.
| Requirement | Covered? | Test Scope | Documentation Supplied |
|---|---|---|---|
| CE RED (radio) | Yes | EN 300 328, EN 301 489 | Per hardware revision |
| EN 50628 (personal safety) | No | Not booked, not claimed | Not supplied |
| FCC Part 15 B/C | Yes | Per model | With production batch |
| UKCA (on request) | Yes | Same as CE RED | Upon request, per revision |
| RoHS 3 / REACH SVHC | Yes | Material screening | Per build |
| EN 1811 (nickel release) | Yes (rings only) | Skin-contact surfaces | With ring shipments |
| EN 50134 (alarm systems) | No | Not applicable | Not supplied |
| IEC 62304 (medical SW) | No | Not implemented | Not supplied |
- All alert routing logic resides in the companion app — no cloud dependency
- Contact list edits require physical access to the paired smartphone
- Maximum three contacts; no group calling or broadcast options
- No integration with emergency services, telecare platforms or PSAPs
- UN38.3 and SDS accompany every battery shipment, with watt-hour rating printed on each unit
- Toy-grade models follow EN 71-1/-2/-3 and EN 62115, determined solely by age grading on packaging
- Service robots carry EMC and low-voltage testing, plus LiDAR laser classification and risk assessment
Where to Begin Your Procurement Review
Elder alert routing is a functional specification, not a compliance category — and its implementation affects firmware scope, test planning and importer obligations. Before quoting, confirm whether your brand intends to market these as wellness tools only or claims emergency functionality (which WingPhoenix does not support). Review the product catalogue for compatible models, then send us the specification
Questions buyers ask
How is the alert routing sequence defined and updated?
The sequence is set in the companion app during device setup and stored locally on the paired smartphone. It cannot be modified remotely or via cloud command; changes require physical access to the device’s paired phone.
Does this meet EU or UK regulatory expectations for personal emergency response?
No. These devices fall outside the scope of EN 50134 (alarm systems) and EN 50628 (personal safety devices). They are wellness tools only, with no certified emergency-response functionality.
What happens if the first contact does not answer?
The app attempts up to three calls to the next contact in the list at 90-second intervals. No SMS fallback, no voicemail drop, no automatic escalation to a third-party service.
What is the one thing suppliers routinely misrepresent here?
That the system “automatically notifies emergency services”. WingPhoenix does not integrate with PSAPs, nor does any model carry an EN 50628 certificate. This capability is not implemented, tested or claimed.
Related: more on ai health monitoring · buyer guides · customisation tiers