老人按下的那个键，接进哪张网

核心答案

居家和机构里的紧急按键，通常先接护理站或家属手机。但在县级中心的架构下，它还有一条更重要的路径：高风险独居老人的按键，应该同时进中心的告警队列，与消防告警共用一套值守。否则夜间护理站没人时，那个键按下去就是空的。

01养老机构为什么值得单独建一套

养老机构在消防上是个特殊场景，特殊在三点，而且这三点都不靠“加强管理”能解决。

一、人搬不动

医院有平车、有电梯、有护工轮班；养老机构里大量是失能半失能老人，卧床的占相当比例。同样一场初期火灾，医院能在三分钟内把一层人转走，养老机构可能连把人扶起来都需要两个人。这决定了报警必须更早，处置必须更快——不是“重视程度”问题，是物理条件决定的。

二、夜里没人

多数中小型养老机构夜间只有 1–2 人值班，有的甚至只有门卫。夜间恰恰是火灾亡人高发时段：人处于睡眠状态，发现晚、反应慢。所以夜间值守不能只靠机构自己，县级中心的 7×24 小时值守正是补这一段的。

三、火源在家里

养老机构的火灾，电气原因与卧床吸烟是两条主线。电热毯、电暖器、私拉插排、老人自己带的充电器，这些在家里是小事，在集中住宿环境里是隐患叠加。传统火灾报警只报“着了”，报不出“哪儿在过载”——所以电气火灾监测和独立烟感要一起上，不能只装一种。

这三条对应的技术选择：更早 → 独立烟感 + 视频复核；更快 → 告警直推责任人手机，不等值班室转达；火源 → 电气火灾监测 + 可燃气体探测。选型时如果只买了火灾报警主机联网，前面三条一条都没解决。

02县级中心，是一个县一个，不是一院一个

县级养老机构消防安全管理中心的形态，容易被想成“每家大一点的养老院装一套”。不是。它是县级建一个中心，把全县正常运营的养老机构连进来——中心在县里，机构端只放感知设备和传输设备。

层级	放什么	谁值守
县级中心	平台、大屏、值守席位、值班电话	民政部门委托的值守方（自建或购买服务）
机构端	传输装置、独立烟感、水压水位、AI 摄像机、门磁	机构自己的值班人员
监管端	数据接口，不落地设备	消防救援机构、民政上级部门

这个结构决定了三件事：平台只需要一套（不是每家机构一套）；告警要跨过两层人（机构值班室 → 县级中心 → 责任人）；网络是薄弱环节（机构多在乡镇，宽带质量参差）。后面所有技术选择，都是被这三件事推出来的。

先定规模再定功能。一个县 5 家机构和 40 家机构，平台架构完全不同：前者一套标准 SaaS 就够，后者必须考虑分片区、分批值守、账号权限树。规模没定就比功能清单，比出来的结论没有意义。

03断网之后：缓存、补传、和对不上的账

乡镇养老机构的宽带和 4G 都不稳，断网是常态不是异常。所以“断网了怎么办”不是加分项，是必答题。

完整的答案要包含四件事：

断网时本地存多少条——写具体条数，不是“可缓存大量数据”。条数要和实际告警量匹配：一家机构一天最多几十条事件，缓存 1000 条能撑很久；但如果把状态心跳也算进去，1000 条可能只够几小时。
复网后怎么补——按时间戳顺序补传，还是按优先级（火警优先、故障其次）？前者简单，后者更符合实际需要。
平台怎么校验完整性——靠设备端的序号连续性判断，还是靠平台侧对账？只有设备端带序号，平台才能发现“中间缺了几条”。
什么情况下会真丢——缓存写满、断电、设备被拆。这三种要如实写，写“绝不丢失”反而不可信。

最危险的不是断网，是断网期间着了火而没人知道。所以断网本身必须产生一条告警（“设备离线”），并且这条告警要推到人，不能只在平台上变灰。很多方案把离线当状态、不当事件，结果设备停了三天没人发现。

04工单闭环：四个节点，一个都不能省

“中心预警—机构确认—处置反馈—销号归档”，这四步听起来像流程描述，实际上是四个时间戳。系统里没有这四个时间戳，这条流程就是纸上的。

节点	系统要记什么	为什么必须记
预警产生	告警时间、来源设备、原始值	后面所有时长的起点
机构确认	确认人、确认时间、是否属实	算“响应时长”；区分误报与真实
处置反馈	处置人、措施、现场照片	验收时要看凭证，不能只有文字
销号归档	销号人、销号时间、归档编号	形成可追溯的闭环

四个节点之外，还有一条最容易漏：升级规则要可配置。不同类型、不同时段、不同机构的超时阈值不该一样——白天 15 分钟、夜间 5 分钟是常见设置；失能老人多的机构阈值应该更短。写死一个统一值的系统，用半年就会被要求改。

处置凭证只收文字等于没收。现场照片要带时间和定位，整改记录要能关联到具体隐患条目。验收时抽查十条工单，如果三条以上只有一句“已处理”，这套闭环就是不合格的。

05自查清单：12 项

逐条打勾。勾选状态保存在本机浏览器，下次打开接着用；本页不上传任何数据。

0 / 12

06常见问题

工单闭环必须有哪几个节点？

预警产生、机构确认、处置反馈、销号归档，四个节点对应四个时间戳。缺任何一个，“响应时长”“处置率”这类指标都算不出来。另外升级规则要可配置，白天夜间、不同机构不该用同一个阈值。

评级结果怎么用才有意义？

至少要和检查频次挂钩：A 级季度抽查、C 级月度上门。只评级不挂钩，机构很快就不在意了。另一条用法是排值守资源——高风险机构夜间重点盯。

水压采集一定要破管吗？

不一定。优先找已有的压力表接口或预留三通，实在没有再破管。破管要停水、报备、恢复试压，一家机构可能多花半天，方案里应该写明改造方式而不是默认破管。

摄像机能利旧吗？

能，但要先摸底。把每家机构的摄像机品牌、型号、固件版本、IP 段、是否 POE 全部抄一遍，再决定要不要买接入网关、买几台、要不要换线。跳过这一步直接报价，后期一定超支。

县级中心要对接哪几个平台？

三个方向：消防救援机构监管平台（通常 RESTful API、GB/T 26875.3 或地方标准）、民政部门的统计口径（报表或接口）、全国养老服务信息系统（预留）。三者的字段口径完全不同，不能一套字段打天下。

项目数据归谁？

归甲方。告警记录、机构台账、视频影像都属于甲方数据；供应商退出或合同终止时要按约定格式完整导出并给迁移周期，不能有“数据回流原厂”或“用于其他项目”的条款。这条要写进合同。

本地服务能力怎么证明？

四样东西：本地服务主体的营业执照与社保人数、原厂授权书、常驻省内工程师名单与所在地、近三年省内同类项目的合同关键页与验收证明。没有证明的业绩一般不计入评审。

到场时限怎么写才可信？

分两级：县城与乡镇分别承诺最长时限，最远的那个机构单独列出来承诺。笼统写“全县 4 小时”很容易被追问，分开写反而显得做过功课。

适用范围与本页说明

本页面向养老与居家场景做方法参考。机构消防管理适用另一套规范，与居家设备不能混用；文中关于分级响应、台账与验收的写法属方法层面，落地时请结合本地服务能力与住养人群特点调整。

机构与居家场景的响应能力不同，方案不要互相套用；机构重"夜间有人盯"，居家重"到人"。

本页内容随政策与标准更新可能调整，具体条款请以正式文本为准；涉及具体项目的建设内容、接入范围与验收要求，请以属地主管部门口径与合同约定为准。