253_辽南某省会城市医共体信息平台信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

论辽南某省会城市医共体信息平台信息系统项目的范围管理

一、项目概要叙述

医共体建设是分级诊疗、均衡医疗资源的关键抓手，过去各级医院信息系统彼此孤立，居民健康档案分散、转诊靠人工流转、远程会诊缺乏统一入口。我所在的该地区卫生健康主管部门，长期受困于辖区内多家医院数据不通、基层诊疗能力薄弱。为破局，该部门于 2021 年 2 月正式启动 " 辽南某省会城市医共体信息平台 " 建设项目，我受委派担任项目经理，统筹需求规划、方案设计、开发实施、集成测试与验收移交全流程。

项目总投资约 850.00 万元，建设周期 7 个月，组建 19 人项目团队，内部含业务分析师 2 人、架构师 1 人、开发工程师 11 人、测试工程师 2 人、质保专员 1 人、配置管理员 1 人，外部含多家医院 HIS 厂商、集成实施与卫健委联调人员。业务侧以低代码平台拼装表单与审批流，服务间经由微服务网关统一鉴权，持久层选用 OceanBase 分布式库，消息通道由 RocketMQ 承担，整体支撑高并发事务与异步解耦。建设内容涵盖居民健康档案、双向转诊、远程会诊、决策看板四大模块：居民健康档案归集门诊与住院信息并打标画像，双向转诊把基层上转与医院下转做成可追踪的闭环，远程会诊打通专家在线阅片与协同诊断，决策看板向卫健委呈现服务量与协同效能。最终交付管理系统、移动端、指挥看板及全套运维文档。项目难点在于：业务连续性要求高，医院门诊不能停、割接窗口极为有限；第三方 HIS 厂商交付质量参差，集成测试反复返工；居民健康数据涉密且敏感，须按等保三级要求同步建设。上线后，预警事件平均处置时长缩短 55%，并发承载能力由 800 提升至 5000 用户在线，运维人工巡检投入下降 60%。

二、结合项目阐述范围说明书与范围基准的创建

所谓范围说明书，指的是明确项目与产品的详细描述、把交付边界钉死成文字的文件。本项目编制《项目范围说明书》时，我依据章程与干系人访谈，把交付物写明为居民健康档案、双向转诊、远程会诊、决策看板四个子系统，逐一列出功能边界与非功能约束；同时将 " 互联网医院在线问诊 "" 医保实时结算 " 等明显超出现有预算与接口能力的越界诉求列为除外责任，避免上线前被各方诉求带着跑。这份说明书不是写完就锁进抽屉，而是后续每一次变更比对的准星，任何新增能力都要先回到它面前问一句 " 这在本来画的圈里吗 "。

所谓创建范围基准，指的是把经批准的范围说明书、WBS 与 WBS 词典固化为后续管控依据的过程。我在定义范围后带领团队按四大模块自上而下分解，最低层级为可独立验收的工作包并分配唯一编码，形成范围基准。分解时我坚持工作包须可独立验收，把 " 远程会诊 " 拆成阅片协同与诊断报告两个工作包，便于分别验收；把 " 健康档案归集 " 拆成数据采集与质控校验两个工作包，前者先交付、后者随数据治理迭代。例如双向转诊模块我进一步拆成上转申请、下转回执、转诊追踪三个工作包，每个都对应明确的验收准则与责任人；WBS 词典则补齐了技术描述、交付形式、验收标准与工期预算，使范围基准不只是层级图，而是可翻阅、可追责的活文档。标杆对照还让我及时发现同级平台已普遍支持 " 检查检验结果互认 "，遂将其补入健康档案范围，避免上线即落后。为让基准不脱离实际，我用标杆对照对标同批次已建成的三家医共体平台，梳理出 " 双向转诊闭环 "" 远程会诊留痕 " 两项是公认的必建能力，遂将其作为范围基准的刚性条目，又把 " 决策看板实时性 " 对照标杆定为秒级刷新而非批量更新，避免自降标准。基准一旦建立，项目就由 " 大家口头说要什么 " 切换到 " 按签字的文档交付什么 "，范围责任第一次变得可核验。

三、范围管理过程中遇到的问题及解决，并总结心得体会

问题一：第三方 HIS 厂商交付质量参差，集成测试反复返工。多家医院 HIS 厂商接口规范不一，初版对接常有字段缺失、报文错位，集成测试阶段缺陷率居高不下。我用控制图持续监控各厂商接口缺陷率的过程稳定性，以每周为单位画出缺陷数上下控制限，凡连续两点越过控制上限即触发约谈并暂停该厂商后续联调；用因果图分析返工根因，定位到 " 需求理解偏差 "" 接口规范缺失 "" 联调环境不一致 " 三类主因，其中接口规范缺失占比最高。针对根因，我推动编制《院端接口对接规范》作为范围基准的附件，把字段、报文、异常码全部固化，厂商按规范交付方可计入验收，返工率随之显著回落。规范发布后，我对三家主要 HIS 厂商做了两轮符合性预检，首轮仅一家达标，我要求其暂停新功能联调、先补齐规范缺口，第二轮全部通过后边际缺陷数较规范前下降约六成，集成测试的返工从 " 天天救火 " 变成 " 按表验收 "，控制图上的缺陷点也重新落回了控制限之内。

问题二：业务连续性要求高，割接窗口极为有限。医院门诊不能停，平台上线必须在极短窗口内完成数据迁移与系统切换，否则影响看病就医。我在范围上把 " 双活并行运行期 " 单列为一个工作包，明确割接前必须完成历史数据一致性校验方可切换，把 " 不停诊 " 作为范围说明书里的不可让步约束；同时用标杆对照确认同城同级平台的割接做法，把并行比对时长、回滚条件写进基准，防止为赶窗口牺牲数据安全。割接当晚，我们严格按基准执行双活并行运行，先跑通历史数据一致性校验、确认门诊业务零中断后才切流量，整个窗口仅用三小时即完成，院方事后评价 " 看病没感觉到系统在换 "。这次割接也成了后续同类项目范围基准里 " 业务零中断 " 条款的直接证据，让范围说明书里那句 " 不停诊 " 从口号变成了可复用的硬标准。

问题三：居民健康数据涉密且敏感，须按等保三级建设。我在范围说明书里把脱敏、加密、访问审计三项列为子系统的硬交付，用标杆对照同级平台的安全范围，把 " 敏感字段加密存储 "" 操作全程留痕 " 作为验收必查项，不达标不得上线，从范围边界上兜住了合规底线。为把这条硬约束真正钉死，我把 " 健康档案脱敏规则 "" 访问审计日志留存周期 " 也写进范围说明书的验收附录，并在里程碑节点用抽样核对脱敏是否到位，确保等保三级不是写在纸上的承诺而是落到库里的现实。

项目于 2021 年 9 月顺利验收。做医共体平台的范围，最怕的就是 " 该连的通没连通、不该加的镀了金 "——边界一旦失守，影响的是老百姓看病就医的真实体验。本项目以控制图盯住厂商交付质量、以因果图挖透返工根因、以标杆对照锚定必建能力，形成了可复用的范围管理资产。当然，项目在创建 WBS 初期对活动与工作包层级把握偏晚，导致中期一度返工。回头看，范围管理最忌 " 重功能、轻边界 "——把说明书写实、基准钉死、变更立住，远比堆功能管用。我越来越确信：范围这东西，是规划出来的，不是接出来的，接得越多边界越糊，这句话在我经手的项目里一次次被验证。往后我会把范围基线再磨细，推动范围管理从被动兜底转向主动设防，为分级诊疗托住每一道线。我还格外关注范围数据的真实性，曾出现某周档案归集完整率统计异常走高，核对是部分院端为达标重复上报，我当即要求采集带时间戳、抽样复核，把水分挤干再入基准。范围数字若自己都会掺水，再漂亮的基准也只是摆设，这是我始终坚守的底线。医共体连着千家万户的健康，任何范围疏漏都可能变成就医路上的梗阻，因此我比以往任何项目都更较真每一条边界。把边界划清，比把功能做满更有价值，这是这个项目给我上的最贵的一课。