161_闽北某地市级院前急救调度系统信息系统项目质量管理

ONEPSOFT | 软考学习知识库

---

闽北地区某地级市的院前急救调度长期依赖人工接警与电话调度，急救派车、车辆定位、救治记录等环节分散在各急救站与指挥中心手中，现场施工与在线业务需并行、不能中断日常办理，跨部门业务口径不一致、数据无法直接对齐，多家外部单位联调、进度同步与责任界面复杂，调度效率低、救治衔接不畅。为把院前急救调度业务数字化，该地区卫健主管部门于 2023 年 10 月发起了地市级院前急救调度系统信息系统项目，经公开招标由我司承建，合同额 920.08 万元，建设周期 11 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合急救调度全流程数据，实现接警在线化、派车自动化、救治可视化。建设内容包括接警受理、车辆调度、定位跟踪、救治记录、统计分析与报表五个模块，并与各急救站及指挥中心对接。技术方案中，急救业务表单与流程依托低代码平台快速配置，调度计算与定位跟踪由自研服务实现，前端页面基于 Vue3 组件体系渲染，后端逻辑以 Java 17 与 Spring Boot 编写，服务间经网关鉴权限流，业务数据存放于 OceanBase 数据库，消息通过 RocketMQ 异步推送，系统部署在市政务云信创环境，安全建设按等保三级实施。项目团队按矩阵型组织搭建，全队 12 人，需求、研发、测试、实施运维与数据治理各岗配齐，编制按模块规模与接口数量核定，联调高峰期另调集厂商力量集中攻坚。项目于 2024 年 9 月通过终验，上线后识别准确率达到 94.6%、误报率控制在 3% 以内，用户满意度测评由 78 分提升至 94 分。

质量是项目的生命线，质量管理回答的是 " 交付的东西合不合格、怎么保证合格 " 的问题。这个项目涉及急救调度、并行施工、外部单位多，质量稍有闪失，派车出错、定位失真，直接关系生命安全。从实际体验看，急救类系统的质量管理有两个特点：一是时效压倒一切，派车指令晚一秒都可能影响救援，质量要求必须从严；二是数据不能出错，急救记录涉及医疗责任，任何偏差都可能引发纠纷。11 个月的实践让我体会到，质量管理本质上是在回答三个问题：做到什么程度算合格，过程中怎么保证不跑偏，交付时怎么证明合格。下面我围绕这三个问题，结合项目实践说明质量管理是如何落地的。

一、做到什么程度算合格：把质量要求写成可核验的标准

质量管理的第一问是标准，回答 " 合格的定义是什么 "。我组织项目骨干，结合急救调度的时效要求，牵头编制了《质量管理计划》，把质量要求写成三条可核验的标准：功能上，接警受理、车辆调度各环节完整可用，接警受理成功率 100%、派车指令无丢失；数据上，急救数据准确率不低于 99%、救治记录完整率 100%；性能上，派车指令响应时间不超过 3 秒。三条标准共同构成质量基线，任何交付都要对照基线核验。基线不是挂在纸上的，我们把它拆成了十几个可测指标，每两周采集一次数据与基线对比，指标偏离超过容忍范围的，责任人在质量例会上当场说明原因并给出纠偏时限，基线因此始终有约束力，而不是一句口号。

标准要可执行，责任必须到人。我们按角色做了质量职责分工：需求人员守住需求质量，开发人员守住实现质量，测试人员守住验收质量，实施人员守住上线质量，分工写进岗位说明书并纳入考核。衡量口径也一并明确：质量指标每周统计、每月复盘，口径不一致的当场纠正。针对并行施工与在线业务并行的约束，我们把质量要求与施工计划同步排期，明确每个施工区的质量验收点，从源头避免 " 施工赶进度、质量让路 "。

二、过程中怎么保证不跑偏：把质量要求嵌进执行与联调

质量管理的第二问是过程，回答 " 怎么保证做出来的过程是合格的 "。我们建立了质量例检与节点把关机制：每周质量例检看质量数据，里程碑节点做质量把关，问题在过程中暴露、在过程中解决。针对跨部门口径不一致的问题，我们用流程图梳理了急救调度的全链路：从接警、派车、出车到救治记录，逐环节标注数据来源与口径要求，据此统一了各环节的数据规范，各急救站照单执行，数据对齐率明显提升。以接警环节为例，过去各站对 " 接警时间 " 的记录口径不一，有的记来电时间、有的记派车时间，统一规范后，接警时效的统计从此真实可比。

针对多家外部单位联调、责任界面复杂的问题，我们用五问法追根因：先问为什么联调反复返工，再问为什么接口文档频繁对不上，追到根子是需求变更后接口契约没有同步更新，据此建立了接口契约管理机制，任何变更先更新文档再动代码，联调返工率明显下降。以车辆定位接口为例，其联调曾因需求调整反复返工，建立契约机制后，变更先更新文档再动代码，返工明显减少。过程管理还靠日常制度托底：代码评审制度化，关键模块双人复核；质量问题台账化，发现一条、登记一条、销号一条；测试用例覆盖不足的场景当场补齐，团队逐渐养成了 " 先想质量、再做事情 " 的习惯。质量门禁贯穿每个里程碑，门禁不通过不进入下一阶段，从流程上卡住质量风险，11 个月里没有出现为赶进度而降标准的妥协。

三、交付时怎么证明合格：把成果核验到位、把记录留全

质量管理的第三问是验证，回答 " 交付的东西凭什么说合格 "。我们设置了验收关卡：开发人员先自查，测试人员再复核，独立评审最后确认，一关不过不进入下一关。针对急救数据准确性问题，我们用分层抽样按急救类型与急救站类别分层抽取样本，逐条核对数据的完整性、准确性，抽到的差异当场定位原因、限期修正；针对救治记录完整性问题，我们用检查表按记录要素、填写时限、流转完整性三个维度逐项核对，记录完整率始终保持在 100%。以派车记录为例，我们曾发现个别站点的派车时间与接警时间存在偏差，抽样核对后定位到是时钟同步问题，统一校准后数据完全一致，这类细节不核验到位，急救时效统计就会失真。

收尾阶段，我们组织了一次终验确认，由测试负责人与实施负责人共同对已完成工作包做最终确认，确认发现的问题全部限期整改、销号存档，确认结论作为验收附件一并归档。除了功能与数据核验，我们还做了时延抽测：在真实调度链路上随机抽取派车指令，记录从接警到派车的完整时延并与基线对比，确保 " 响应不超过 3 秒 " 不是纸面数字，而是可重复验证的事实。这类过程性核验让交付结论更有底气，也让验收专家对我们的数据链心服口服。核验不只发生在收尾，每个里程碑的核验记录都归档在案，最终验收时拿出的是一整条完整的数据链，各方因此对交付质量心服口服。验证环节我们还注意把握质量与等级的关系：急救系统追求高质量而不是高等级，不过度设计、不堆砌功能，而是把派车、定位、记录这些核心环节做扎实，让质量与成本、进度保持平衡。项目最终一次通过验收，识别准确率达到 94.6%，用户满意度由 78 分提升到 94 分，各急救站与指挥中心对系统的认可度明显提升，卫健主管部门认为这套质量管理做法值得在系统内推广。

回顾整个过程，质量管理给我的体会是：标准问清楚、过程管得住、结果验得实，三个问题环环相扣，缺了任何一问，质量都会失守。这正是本项目留给我最深的启示。这套把标准、过程、验证串成闭环的做法，后来也被固化进公司在卫生健康类项目的质量管理模板，为后续项目提供了参照。