平台规模（结构与接口口径）
以上数字取自 2026-09-28 运行实例实测与源码统计：页面清单来自前端路由表， 设备 / 事件 / 指标数来自注册表接口实测，接口路径数来自后端源码。 均为结构与接口计数，不含演示库业务数据。平台未公开版本接口，本页不写版本号。
为什么是养老监护
我们最强的资产是 IoT 硬件、边缘算力与传感器整合能力。把这套能力放到养老场景， 要解决的不是「再做一个医院信息系统」，而是一个更朴素的问题：老人在家里或房间里出了状况，有没有人第一时间知道。
因此鲸护不做诊断、不做治疗建议，只做三件事：把设备接进来、把异常判出来、把消息送到该送的人手上， 并且确认有人接。这三件事做完了，剩下的交给家属和医护。
测量类设备（血压计、血糖仪、血氧仪）采用已持证的 OEM 产品接入， 让持证的硬件厂商赚测量的钱，我们赚连接、边缘智能和服务的钱——这是鲸护明确划定的业务边界。
一条监护链路
从设备接入到家属复盘，六个环节串成闭环；告警不是发出去就算完，要有人确认才算处置。
8 个业务页面
与平台前端路由逐条对应，每一条都是真实存在的页面。
告警分级与升级
规则未指定通道时按严重级走默认路由；无论怎么配，P1 都强制包含电话与短信，这是安全下限。
分级路由与 P1 升级呼叫链路已通过端到端验证；webhook 通道已实发验证。 短信、语音外呼与微信服务号三条通道的发送代码与签名单元测试已完成，尚未对接真实服务商凭据做实发验证，上线前需配置凭据并实发测试。未配置凭据的通道会记录 pending 审计，告警不会被静默丢弃。
四条不可让步的红线
养老场景牵涉隐私与安全。鲸护把这些约束写进产品和数据库，而不是只写在宣传页上。
真实界面，不是渲染图
以下 3 屏截自 2026-09-28 运行中的实例（登录后台后实抓）， 界面上的数据为演示库种子数据，仅用于说明系统功能。
开放公网试用
- 试用账号
- 平台内置 5 个角色账号（系统管理员、医生、护士、前台、药师），密码在登录页同页面公示， 有效期为建档日起 3 个月，到期后登录接口会返回明确的到期提示。
- 演示数据说明
- 演示库当前为 2 位老人、3 台设备的种子数据，仅用于说明系统功能，不代表实际业务规模。
相关
鲸护 · 养老监护平台
接入 → 判定 → 告警 → 触达 → 处置 → 复盘 —— 只做安全监护，不做医疗诊断