上海：数据要能对上长护险那本账

核心答案

上海的养老服务数字化程度高，机构日常已经在长护险、养老服务平台等多套系统里报数。新建消防中心如果要独立成账，基层会重复填报。合理的做法是复用机构主数据（机构编码、床位、住养人数），只新增消防维度的字段，并预留向民政口径导出的能力。数据口径不统一，系统建好也没人填。

01接口：三张网，三种口径

县级中心的数据要往外送，方向有三个，口径完全不同。

对接对象	常用方式	难点
消防救援机构监管平台	RESTful API、GB/T 26875.3 或地方消防物联网标准	字段范围与推送频率由对方定，要先拿到接口文档
民政部门的统计口径	报表导出或接口	民政看的是“机构、床位、住养人数、隐患整改率”，不是设备在线率
全国养老服务信息系统	预留接口	接口未开放时要说明预留方式与工作量

三张网里，第一张是硬要求，第二张是软要求，第三张是预留。很多方案把三张写成一样，评审时一问“民政的报表按什么口径统计”就答不上来。

推送模式上，实时推送和 T+1 批量各有用途：火警必须实时，统计类可以批量。要做的是两种都支持，并按数据类型自动选择。只有一种的系统，要么浪费带宽，要么报表不及时。

还有两个容易被忽略的条款：推送失败后的重传策略与每日对账机制。没有对账，丢了数据双方都不知道；有了对账，才能算出真实的丢包率。

数据权属要写在合同里：告警记录、机构台账、视频影像归甲方所有；供应商退出时按约定格式完整导出，并给出迁移周期。含糊其辞的，验收时会被卡。

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

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

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

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

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

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

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

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

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

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

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

04验收与“可复制经验”：试点项目的下半场

试点项目的验收，从来不只是“设备装好了”。它有两个交付物：一套能用的系统，和一份能推广的经验。第二件经常被忽略，却往往是验收会上被问得最多的。

系统侧看什么

接入机构数是否等于计划数，每家机构的设备清单与点位图是否齐全；
抽三条工单，看四个时间戳是否完整、凭证是否有照片；
现场制造一次告警，看端到端时长与推送对象是否正确；
断一次网，看离线告警是否产生、复网后数据是否补齐；
导出一次报表，看字段是否满足民政口径。

经验材料写什么

有效的经验材料不是成果汇编，是可被别处照抄的操作说明：县域规模怎么测算、老主机怎么接、值守班怎么排、误报怎么压、钱怎么花。写“建成县级中心 1 个、接入机构 5 家”是成绩；写“5 家机构里 3 家主机无标准接口，用开关量 + 独立烟感双路采集，单家改造 0.5 天”才是经验。

一条实用建议：从项目第一天就按“经验材料”的口径留资料——改造前照片、接线方式、遇到的问题与解法、每家的实际工时。等到验收前再回忆，细节全丢了，写出来只能是套话。

05自查清单：12 项

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

0 / 12

06常见问题

火灾告警端到端时延一般要求多少？

行业没有统一的强制值，问询清单通常要求分别填最短、平均、最长三个实测值，并注明测试方法（网络条件、接入设备数量、并发告警数）。评审看的是三个数是否自洽、最长值是否有合理解释，而不是单个数字多小。

时延的三段分别是什么？

主机火警到传输装置采集、传输装置到平台入库、平台入库到责任人手机。第一段取决于主机接口和轮询周期，第二段取决于网络与平台并发，第三段取决于推送通道。只报一个总数，说明不了问题在哪。

断网本身要不要报警？

要，而且必须推送到人。很多人把设备离线当状态、不当事件，结果设备停了三天没人发现。离线应该产生一条独立告警，走和火警类似的通知链路，只是级别可以低一些。

算法放摄像机里还是放平台？

摄像机内置省带宽、响应快，但升级要逐台刷；平台侧解析能利旧摄像机，但占服务器算力、传视频费流量；边缘盒子介于两者之间。机构少时前两种都行，机构多了要算总带宽和总存储账。

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

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

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

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

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

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

等保三级是必须的吗？

政务与公共服务类平台通常要求过等保三级（GB/T 22239）。应答时要说明是否已测评、测评机构与时间；未测评的要说明具备测评条件及配合甲方测评的工作内容，包括数据加密、身份鉴别、访问控制、日志留存期限。

适用范围与本页说明

本页面向属地项目做规模测算与建设内容对照。文中引用的文件号与标准号（云民发〔2026〕81 号及附件《县级养老机构消防安全管理中心建设参考方案》、T/QDAS 146-2025、GB 26875 系列）均按公开文本表述，具体条款以正式文本为准；各地试点范围、时间节点与补贴口径以属地民政与消防救援部门口径为准。

落地前先与属地民政、消防救援部门确认试点范围、接入机构名单与时间节点，再按机构数定平台规模。

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