安消一体：养老机构的工单该长什么样

核心答案

养老机构的工单比工业场景简单，但四个时间戳一个都不能少：告警产生、机构确认、处置反馈、销号归档。额外要加两个字段——是否夜间、是否失能区域。这两个字段决定了复盘时能不能看出“哪类时段、哪类区域容易出事”，也是机构画像的数据来源。

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

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

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

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

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

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

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

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

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

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

03政策链条：三份文件，一条线

这类项目不是从技术需求开始的，是从文件开始的。要读的文件有三层：

层级	文件	它管什么
省级部署	云民发〔2026〕81 号《关于加强县级养老机构消防安全管理中心试点建设的通知》	为什么建、谁来建、什么时间建成、试点要形成什么
建设内容	上述文件的附件《县级养老机构消防安全管理中心建设参考方案》	中心里放什么、平台要有哪些模块、机构端接什么
技术依据	T/QDAS 146-2025《养老机构智慧消防管理数字化平台建设技术规范》	平台的功能项、数据结构、接口方式

三层里最容易出错的是中间那层。省级文件是方向性的，团标是技术性的，真正决定“这个中心长什么样”的是附件里的参考方案。方案里列的每一条建设内容，在验收时都会被问到“对应哪个模块、实现到什么程度”。

所以做方案的顺序应该是：先拿附件逐条拆成功能清单 → 再用团标补技术细节 → 最后用省级文件校准范围。反过来做（先堆产品功能，再往文件上靠）会在评审时露馅：功能很多，但和附件对不上号。

团体标准的引用要核实。T/QDAS 146-2025 是团体标准，不是国标也不是行标。引用时写全标准号与年份，不要写成“国家标准”或“行业标准”——这是评审最容易抓的一处。

04中心与机构，责任线要画在哪

建中心最容易埋的坑，是责任界面模糊。设备装上了、平台通了，真出事时“谁先动”说不清，这套系统就等于没有。

环节	机构端责任	县级中心责任
初次确认	接到告警后在约定时限内到现场核实	看平台、打电话催办、记录时间
处置	现场处置、拍照上传	判断是否需要外部救援、是否升级
升级	无力处置时立即上报	逐级上报民政与消防救援机构
归档	补充整改记录	销号、纳入机构画像

这张表要在合同里写死，尤其是“机构未按时确认，中心怎么办”这一行。合理的设计是：超时未确认自动升级到机构负责人，再超时升级到县级中心，中心有权直接联系 119——而不是中心只能看着屏幕上的红点。

一个常见误解：以为中心是“监管机构”，可以对机构下指令。实际上中心多数是民政委托的服务方，没有执法权。它的手段只有三个：催办、上报、记录。把这三个做扎实，比给它“权力”更有效。

05自查清单：12 项

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

0 / 12

06常见问题

一个县一般要接入多少家机构？

试点通常选正常运营的机构全覆盖，5 家到十几家都常见。规模直接影响架构：10 家以内一套标准部署就够，超过 30 家要考虑分片区值守和账号权限分级。先定规模，再定功能。

超时未确认怎么处理？

自动升级：先升到机构负责人，再超时升到县级中心，中心有权直接联系 119 并记录。关键是这条链路要在系统里自动跑，不能靠中心值守人员盯屏幕手动打电话。

台账为什么容易做成空表？

因为没想清楚谁填、什么时候填、填了有什么用。尤其是日常巡查：纸质表改成手机打卡，形式上完成了，内容全是“正常”。要让它有价值，巡查发现的问题必须落成隐患条目并可统计。

兼容主机品牌写“主流品牌”行不行？

不行。要报具体品牌名和协议名。养老机构存量主机品牌杂，每个县的实际构成都不同，接入前还得现场确认型号与固件版本。写“兼容主流品牌”在评审时基本等于没答。

水压采集一定要破管吗？

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

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

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

推送实时和批量要都支持吗？

要。火警必须实时，统计类可以 T+1 批量。只有一种的系统，要么浪费带宽，要么报表不及时。配套还要有推送失败重传策略和每日对账机制，否则丢包率算不出来。

项目数据归谁？

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

适用范围与本页说明

本页面向平台需求编写与验收指标设定。"告警时延、响应时长、处置率、整改率"这些指标的分子分母要在需求阶段一并定义，否则报表无法用于考核；涉及与消防救援机构、民政部门的数据对接，字段范围与推送频率需以对方接口文档为准。

平台上线前先跑通一条完整链路：告警产生→推送→确认→处置→销号，五个时间点都要能取到并导出。

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