居家养老监护服务平台开发功能详解
居家养老是当前养老服务的主流模式，和集中养老院不同，老人分散居住在各自家中，护工、子女、养老机构很难实时掌握老人健康状态、居家安全情况。传统电话回访、上门巡检方式存在信息滞后、异常发现不及时、工单流转混乱等问题。居家养老监护服务平台，就是打通智能传感设备、健康数据、服务工单、家属端、机构管理端的一体化系统。本文从业务痛点、核心模块拆解、设备接入逻辑、代码示例、开发落地要点等方面，详解整套平台的设计思路。
一、项目开发痛点梳理
在平台开发过程中，居家养老场景有很多区别于普通SaaS系统的难点：
- 设备类型繁杂：人体红外、紧急呼叫按钮、燃气烟雾报警器、智能水表电表、血压血氧仪等，协议各不相同，统一接入难度高。
- 告警分级处理混乱：燃气泄漏属于高危告警，久坐提醒属于普通提示，如果不做分级，管理人员容易被海量消息淹没。
- 多方角色协同：老人、家属、护工、机构管理员、网格员，权限和查看的数据范围需要严格隔离。
- 工单闭环难：告警触发后派单、上门处置、回访归档缺少流程约束，容易出现告警只提醒、无人跟进。
- 健康数据零散：线下体检、居家自测设备数据分散，无法形成连续健康档案，不利于风险预判。
- 老人信息安全敏感：老人身份、健康、住址属于隐私信息，接口、数据导出都需要权限管控。
- 离线与弱网问题：部分老旧住宅网络差，IoT设备经常离线，需要离线缓存、上线补传机制。
二、平台整体角色划分
平台分为四个终端角色，权限相互隔离：
老人端：简易小程序，一键呼叫、查看服务计划、简单健康上报，界面做简化，字体放大。
家属端：查看老人实时告警、健康记录、护工服务记录、设备在线状态，接收消息推送。
护工端：接收上门工单、签到打卡、上传服务照片、填写服务记录、上报现场情况。
机构管理后台：老人档案管理、设备接入、告警配置、工单调度、统计报表、人员管理。
三、核心功能模块详解
老人档案与基础信息管理
档案是所有服务的基础，除基础身份信息外，还要记录既往病史、过敏史、常用药品、紧急联系人、居住地址、护理等级。
档案支持多标签标记，比如失能、半失能、独居、高龄，方便后续定向派单和风险筛查。同时绑定对应的智能设备，一个老人可以绑定多个传感终端。
IoT智能监护设备接入模块
这是居家养老监护平台的核心，负责接收各类传感设备上报数据。
设备类型分为安全类和健康类：紧急呼叫按钮、烟感燃气报警器、人体存在传感器、门窗磁属于安全监护；血压计、血氧仪、体重秤、睡眠监测设备属于健康监测。
平台采用设备适配器模式，屏蔽MQTT、HTTP、蓝牙网关等不同协议差异，统一标准化事件。设备上报的数据分为定时上报、告警事件两种类型。
告警支持自定义分级：一级高危告警（燃气泄漏、紧急呼救）、二级重要告警（长时间未检测到人体、门窗异常开启）、三级普通提醒（久坐、夜间频繁活动）。不同级别告警推送渠道不同，高危告警同时推送管理员、家属、值班护工。
告警调度与工单闭环模块
告警不是简单推送消息，必须形成完整闭环。
告警触发之后，系统先做降噪过滤，短时间重复上报的相同告警合并；再根据老人所在区域、护工排班自动派单；护工接单、上门签到、现场处置、填写处置结果、上传凭证，最后家属和管理员可以查看处置记录。
如果高危告警一定时间内无人接单，系统自动升级告警，推送至备用值班人员。
居家健康档案管理
健康数据自动汇总入库，支持设备自动上传和护工手动录入两种方式。
系统自动生成健康趋势曲线，监测血压、心率等指标持续异常，自动生成健康预警。健康档案和服务工单联动，护工上门护理时可以直接查看历史健康记录，辅助服务。
上门护理服务工单模块
支持计划工单和临时工单。计划工单是定期上门，比如每周助浴、助餐、保洁；临时工单来自告警、家属申请、网格员上报。
工单包含服务项目、服务时长、服务要求、签到位置校验、服务拍照留痕，完成后支持家属评价。
消息推送与通知中心
支持微信模板消息、短信、APP推送，区分告警消息、服务通知、健康提醒。高危告警优先短信通知，避免微信消息被忽略。
数据统计看板
机构后台可视化大盘，统计独居老人数量、告警总数、工单完成率、健康异常人数、设备在线率，辅助养老机构运营。
四、Java代码示例：设备告警接收与分级分发
@Service
@Slf4j
public class ElderAlarmService {
@Autowired
private ElderInfoMapper elderInfoMapper;
@Autowired
private AlarmRecordMapper alarmRecordMapper;
@Autowired
private AlarmDispatchService alarmDispatchService;
@Autowired
private MessagePushService messagePushService;
@Transactional(rollbackFor = Exception.class)
public void receiveDeviceAlarm(DeviceEventDTO eventDTO) {
// 查询老人信息
ElderInfo elder = elderInfoMapper.selectByDeviceSn(eventDTO.getDeviceSn());
if (elder == null) {
log.warn("告警设备未绑定老人，sn:{}", eventDTO.getDeviceSn());
return;
}
// 告警降噪，短时间相同告警合并
boolean repeatAlarm = alarmRecordMapper.checkRepeatAlarm(elder.getId(),
eventDTO.getAlarmType(), Duration.ofMinutes(2));
if (repeatAlarm) {
log.info("重复告警，跳过派发");
return;
}
// 构建告警记录
AlarmRecord alarm = new AlarmRecord();
alarm.setElderId(elder.getId());
alarm.setDeviceSn(eventDTO.getDeviceSn());
alarm.setAlarmType(eventDTO.getAlarmType());
alarm.setAlarmLevel(getAlarmLevel(eventDTO.getAlarmType()));
alarm.setAlarmContent(eventDTO.getAlarmContent());
alarm.setAlarmTime(LocalDateTime.now());
alarm.setStatus(AlarmStatus.UN_HANDLE.getCode());
alarmRecordMapper.insert(alarm);
// 按告警级别分发推送
if (AlarmLevel.LEVEL1.getCode().equals(alarm.getAlarmLevel())) {
// 一级高危告警，推送管理员+家属+护工
messagePushService.sendHighLevelAlarm(elder, alarm);
} else if (AlarmLevel.LEVEL2.getCode().equals(alarm.getAlarmLevel())) {
messagePushService.sendNormalAlarm(elder, alarm);
}
// 自动生成工单
alarmDispatchService.createWorkOrder(alarm);
}
/**
* 告警级别映射
*/
private Integer getAlarmLevel(String alarmType) {
return switch (alarmType) {
case "EMERGENCY_CALL", "GAS_LEAK", "SMOKE" -> AlarmLevel.LEVEL1.getCode();
case "NO_HUMAN_LONG", "DOOR_ABNORMAL" -> AlarmLevel.LEVEL2.getCode();
default -> AlarmLevel.LEVEL3.getCode();
};
}
}
五、开发阶段重点注意事项
- 设备适配器优先设计：不要为每一类设备单独写一套业务逻辑，新增传感设备只新增适配器，上层告警、工单逻辑复用。
- 告警降噪是刚需：传感器容易抖动误报，增加时间窗口合并、阈值过滤，避免无效告警打扰工作人员和家属。
- 隐私数据保护：老人住址、病历、联系方式脱敏展示，接口增加数据权限拦截，护工只能查看分配给自己负责的老人。
- 工单超时机制：高危告警必须设置超时升级策略，防止值班人员遗漏。
- 离线设备监控：定时巡检设备在线状态，设备长期离线，生成设备异常工单安排检修。
- 地理位置校验：护工上门签到基于地理位置，防止虚假打卡。
- 多机构隔离：支持多养老机构入驻，机构之间老人数据、工单隔离，适合区域性养老平台。
- 兼容性适配：老人端小程序简化交互，减少复杂表单，优先一键呼叫、大字体展示。
六、落地总结
居家养老监护平台，核心不是简单的设备数据采集，而是IoT设备事件、告警分级、工单闭环、多方协同的一体化体系。
平台把分散在老人家中的传感设备数据统一汇聚，将安全风险、健康异常及时转化为可跟踪的服务工单，打通老人、家属、护工、养老机构之间的信息壁垒。开发时优先做好设备抽象、告警降噪、权限隔离，同时兼顾老人使用的易用性和隐私安全，才能满足居家养老场景的业务要求。
