某天下午医院信息科收到一摞各科室报上来的新系统申请手术室要上4K示教系统护理部想把移动护理终端全部换新设备科准备上全院物联网资产追踪门诊办要求升级排队叫号和分诊屏影像科又抱怨PACS传片太慢。每个科室都有充分理由每套系统都离不开网络但如果真按老思路各自拉线、各自组网机房很快就变成仓库。这份“智慧医院融合网络技术需求表”本质上就是在这种混乱中长出来的——它不是一张普通的网络配置清单而是一份把医院几乎所有业务系统、终端设备、传输需求汇总到一起再做统一规划的技术基线。这篇文章写给三类人看一是医院信息科的网络工程师或项目负责人需要写需求、搞招标、做验收二是医疗信息化集成商的售前和实施人员需要理解医院甲方的真实诉求三是做智慧医院顶层设计的咨询顾问需要一份能落地的网络需求参照。我会把这张需求表背后的技术逻辑、指标计算方法、以及那些不会写进标书里的坑一起讲透。1. 一张需求表是从“各科室都要网”的混乱中长出来的1.1 医院网络为什么那么难业务边界远比技术参数复杂医院网络和企业办公网最大的区别在于“断网容忍度”极低。企业网络断几分钟大家顶多喝杯咖啡等恢复医院网络断几分钟挂号缴费排长队医生开不了医嘱护士执行不了治疗手术示教可能中断严重的还会影响诊疗决策。再叠加医院建筑的特点——多栋楼、厚承重墙、电梯井、地下室、电磁环境复杂——网络建设天然就是个高难度场景。很多医院现网是“一次一个项目”长出来的最早只有办公网后来上HIS系统加了一张业务网再后来搞移动查房又建了无线网物联网设备多了再添一张物联网专网。结果就是机房里堆了好几个品牌的交换机地上走了好几套线每张网的控制器和认证系统互不相通出故障时要在几套告警里来回切换排查。我在不少医院见过这种状况门诊楼一层有行政办公的网口有业务系统的网口有新开的自助机网口还有第三方设备厂商私自拉的网线墙上面板密密麻麻弱电间里乱成一团。这背后是三个很现实的问题建设成本高每张网都要独立的交换机、控制器、安全设备重复投入。运维负担重网络故障要先判断是哪张网的问题再去找对应的管理平台。业务隔离僵化几张网完全割裂数据打通靠人工拷贝或中间设备转发既不安全也不高效。1.2 融合网络不是“物理一张网”而是“统一承载、逻辑隔离”“融合”这个词被用滥了很多厂商把它理解为把所有东西塞进同一台设备、同一根光纤里。真正在医院场景下融合网络的含义应该是在一套统一的物理基础设施光纤链路、交换机、无线AP、管理平台之上通过VLAN、VRF、策略路由、防火墙分区等技术把不同业务按需隔离。用一句话概括就是一张物理网多个逻辑平面按业务分资源按安全分级管控。举个例子医生的移动查房终端要访问HIS、LIS、EMR这些核心业务而无线的胎心监护传感器只需要把数据传到产科中央站。两者都接入同一张无线网但通过不同的SSID、VLAN、接入策略做到数据互不可见。护理PDA能访问医嘱系统患者家属Wi-Fi只能上互联网——这些都发生在同一套AP和交换机上。这么做的好处是显而易见的弱电间不再堆满设备线缆大幅减少运维只需盯一套管理平台新业务上线时不用再拉新网只需要划分新的VLAN和策略业务开通时间从几周缩短到几天。当然代价是对网络工程师的要求更高了——你不再只是“配VLAN的”而是要懂业务隔离、策略编排和故障域设计。2. 融合网络需求拆解一张网上到底要跑多少种业务写“技术需求表”最怕的就是只堆名词不拆业务。一份合格的需求表应该先把业务分类列全再针对每一类业务写技术需求。我一般把医院业务分成四类核心医疗业务、患者服务业务、运营管理业务、物联网业务。每一类对网络的需求完全不同。2.1 网络架构需求核心、汇聚、接入只是骨架关键是冗余和可扩展先说物理架构。常规三甲医院建议采用“核心-汇聚-接入”三层架构规模小的院区可以简化为“核心-接入”两层。核心层必须双机冗余这是底线不是可选配置。汇聚层按楼栋划分比如门诊楼一台或两台汇聚交换机住院楼单独部署避免单楼故障影响全院。接入层按楼层或病区部署每病区一台或两台接入交换机。冗余设计要具体到链路层核心到汇聚至少两条光纤链路跑跨设备链路聚合任何一条链路断开都不会造成业务中断。汇聚到接入同样要留冗余端口或预埋备用光缆。我在需求表里通常会明确写“关键链路故障收敛时间不超过1秒”这个指标要写进去而不是只写“支持冗余”。SDN和网络虚拟化要不要上取决于医院的信息化水平。如果信息科有专人做网络管理对策略配置比较熟可以考虑控制面集中的方案统一配置和下发策略会方便很多如果人手紧张、运维以第三方为主传统架构加网管平台反而更稳妥。需求表里可以要求“支持SDN能力但不强制启用”把选择权留给自己。2.2 无线接入需求高密、漫游、频段规划一个都不能少无线是智慧医院里感知最强的部分。医生护士拿着PDA到处跑患者连着Wi-Fi刷视频物联网设备在角落里发数据三类终端对无线网的要求各不相同。需求表里无线部分我建议至少覆盖三个方面。第一个是高密接入场景。门诊大厅、候诊区、学术报告厅、体检中心这些地方的特点是终端数量巨大、单终端流量不高、并发连接数爆炸。普通办公室放一个AP能带50个终端门诊大厅的AP可能要同时承载100到150个终端。需求表里要明确AP并发带机量比如“单AP并发终端数不低于128个”并且指定用三频或高规格AP而不是把办公室用的普通AP直接搬过去。第二个是漫游体验。移动护理PDA在病区里来回走护士从护士站走到病房再从病房走回护士站终端要在多个AP之间切换。如果漫游丢包率高PDA上的医嘱界面就会转圈护士会直接骂网烂。需求表里要写“支持802.11k/v/r快速漫游协议”和“漫游切换时延不高于50毫秒”这两个参数能明显改善移动查房体验。第三个是频段规划。2.4GHz频段在现在的医院里基本已经挤满了——无线鼠标、蓝牙设备、老旧医疗设备无线模块都在用干扰非常严重。需求表里应该把5GHz作为主力频段新建网络原则上要求AP支持Wi-Fi 6或以上标准条件允许的可以要求支持6GHz频段Wi-Fi 7但6GHz的终端普及率还不够不建议作为必选项。物联网设备单独规划接入方式不要硬挤Wi-Fi频段。2.3 物联网和医疗专网需求多种无线技术并存才是常态很多需求表在物联网部分写得很虚一句话“支持物联网扩展”就完了。实际医院里的物联网终端五花八门婴儿防盗手环用RFID资产定位标签用蓝牙AoA或BLE冷链温湿度传感器用LoRa输液泵和监护仪走Wi-Fi或私有协议。没有任何一个无线协议能统一所有物联网设备融合网络的价值在于能同时承载这些不同的接入方式。我在需求表里一般会分这么几块写医院资产和人员定位要求支持蓝牙AoA或UWB高精度定位精度不低于1米用于资产盘点、婴儿防盗、重点区域人员管理。环境监测冷链冰箱、温湿度、水浸、用电安全等传感器要求支持LoRa或类似低功耗广域协议电池供电设备续航不少于1年。医疗设备联网呼吸机、监护仪、输液泵这类设备优先走医疗设备专网或有线接入必须无线的要单独规划SSID并做设备准入控制。这里有个很容易踩的坑物联网终端数量大、单设备流量小但连接数会占用大量IP地址和AP资源。一个500张床位的院区物联网终端可能有两三千个加上电脑、手机、PDA、自助机总终端数轻松破万。需求表里一定要对IP地址规划、VLAN数量、网关容量做明确要求否则项目上线后会发现地址不够用、设备加不进去。2.4 安全与隔离需求一张网上的多个逻辑平面怎么切安全是医院网络里最敏感的话题也是需求表里最难写的部分。医院的核心业务系统涉及患者隐私等级保护要求摆在那里内外网隔离是硬指标。但一刀切成物理隔离又和“融合”矛盾——物理隔离意味着业务要跨网时只能靠人工或网闸效率低。我的建议是物理链路共用逻辑隔离做强。具体做法内网区承载HIS、LIS、PACS、EMR等核心业务系统只允许受控终端接入。外网区承载互联网访问、患者Wi-Fi、行政办公上网与内网之间通过下一代防火墙做访问控制。设备专网区承载医疗设备、物联网终端访问关系按设备厂商要求单独放通。运维管理区单独划出管理口和业务口物理分离防止管理流量混入业务网络。需求表里还要写终端准入控制。医院里私接路由器、乱插U盘、自带笔记本上网的情况非常普遍没有准入控制的网络形同虚设。建议要求“支持802.1X认证和MAC认证混用支持终端健康状态检查不通过的终端只能访问隔离恢复区”。这样即使有陌生终端接入也无法访问核心业务。3. 需求表里的数字才是灵魂带宽、时延、可靠性指标怎么定3.1 带宽估算从业务反推流量别拍脑袋写“万兆核心”写需求表时最怕遇到拍脑袋的参数。核心交换机写“支持万兆”没有意义关键是你得知道自己到底需要多少带宽。带宽估算要从业务流量反推我以一家中等规模三甲医院为例说下计算方法。事务型业务挂号、缴费、医嘱、病历调阅的特点是单次流量小、并发高。按日门诊量一万人次高峰时段同时在线约1000个操作终端每个终端平均流量0.5Mbps那这部分总需求大约是500Mbps。PACS影像业务是流量大户。一张胸部CT平扫200到500MB虽然多在非高峰时段自动拉取但医生阅片时的交互延迟直接受带宽影响。影像科和核心机房之间建议预留不低于1Gbps专用带宽并且要保证低丢包率否则阅片会卡。手术示教和远程会诊视频流一路4K手术示教视频大约需要25Mbps按同时三间手术室直播来算仅视频就占75Mbps。这部分建议单独规划组播或预留独立带宽避免和事务型业务抢资源。视频监控一个500路摄像头的院区每路按4Mbps码流计算就是2Gbps。监控网络原则上单独组网或单独VLAN不要混入业务网。表格里我习惯把估算结果直接列出来写需求时更有底业务类型估算流量说明事务型业务500Mbps挂号、缴费、医嘱、EMR交互PACS影像1000Mbps影像拉取与阅片手术示教/远程会诊75Mbps起每路25Mbps按并发路数扩展视频监控2000Mbps500路×4Mbps独立组网物联网数据50Mbps单设备流量小但连接数大预留扩展30%以上新业务、新设备接入余量这样算下来核心下行带宽至少在4Gbps以上核心交换机建议按10Gbps或更高规格设计接入交换机到汇聚之间至少千兆到桌面、万兆上行。需求表里写带宽时要附上这个计算过程而不是只写一个数字这样招标时供应商也很难糊弄你。3.2 时延与可靠性分级不是所有业务都该一个标准很多需求表把时延写成“全网时延不高于10毫秒”这其实是不合理的。医院里不同业务对时延的敏感度差异巨大统一一个极端标准只会推高成本。更合理的做法是分级定义普通办公和互联网访问时延小于100毫秒丢包率小于1%这个标准很容易达到。语音和视频业务时延小于50毫秒抖动能控制在30毫秒以内无线语音对漫游和抖动比数据敏感得多。手术示教和远程操控类业务端到端时延设计目标小于20毫秒但这类业务不建议跑在通用融合网上优先用物理专线或独立的低时延通道融合网络作为辅助链路。可靠性的分级逻辑也一样。核心设备、关键链路要求故障切换时间小于1秒普通接入链路允许5秒内恢复无线部分允许AP单点故障但同一区域的覆盖要能由相邻AP补上。把可靠性要求分级写清楚既能让供应商有明确的交付标准也避免为不必要的可靠性指标多花钱。3.3 漫游和覆盖边界写清楚室外、地下和特殊区域无线覆盖需求不能只写“全覆盖”三个字。我曾经见过一个项目病房里信号满格但护士推着治疗车走到走廊尽头时PDA掉线因为那个位置正好是两个AP的信号交界处漫游切换没调好。需求表里要把覆盖范围按区域类型写清楚病房区每病区AP数量按房间数规划保证病床位置信号强度不低于-65dBm。门诊大厅和候诊区高密覆盖信号强度不低于-60dBm重点保障并发能力。走廊和护士站确保PDA全程不掉线漫游切换时延不高于50毫秒。地下停车场和楼梯间至少保证安防和应急通信覆盖不一定要求高速上网但不能有盲区。室外花园和连廊根据实际使用场景决定是否覆盖如果患者需要在室外连Wi-Fi单独部署室外AP。特殊区域要特别注明。手术室、ICU这类区域对无线设备有电磁兼容要求普通AP不能随便装需要医疗级AP或带消毒外壳的型号。核磁共振室内部不能装任何金属设备和普通AP只能通过室外Waveguide波导或专用设备做信号穿透这个在需求阶段就要和影像科确认清楚。3.4 运维指标用户只关心“什么时候能修好”而不是“故障原因”最后说运维。医院信息科通常人手有限有的三甲医院信息科也就七八个人管全院几千个信息点没有可视化运维平台根本忙不过来。需求表里运维部分我会要求全网拓扑自动发现和可视化展示能定位故障到楼栋、楼层、病区、端口。无线网络质量监控能看到每个AP的在线终端数、信号质量、丢包率、漫游失败次数。告警要分级推送核心设备故障直接电话告警普通接入层异常只发工单就行。支持远程抓包和日志查询出问题时不用跑现场就能做初步定位。再补一个容易被忽视的点给运维留一个单独的网管VLAN或带外管理通道。很多医院网络出故障后管理口跟着业务一起断工程师只能跑到弱电间去Console登录效率极低。需求表里这个细节值得写进去。4. 从需求表到可交付网络选型、施工、验收的避坑经验4.1 写招标参数的技术高要求但不过度绑定品牌需求表最终是要走招标的参数写法直接决定你能招到什么水平的供应商。我的经验是三个避免避免写品牌独有功能避免写具体型号避免堆砌用不上的高端参数。比如“支持Wi-Fi 7”没问题但如果写“支持某某厂商独家的某某算法”等于直接圈定供应商不仅可能废标而且丧失了比价空间。更聪明的写法是写业务指标而不是写功能清单。举例不写“支持第6代无线协议”而是写“在门诊高密场景下单AP并发120个终端时每个终端仍能获得不低于5Mbps的吞吐量时延不高于50毫秒”。这个指标是业务可验证的供应商必须用真实产品去满足而不是在参数表里勾选“支持”就行。设备选型还有一个原则同一品牌原则。核心、汇聚、接入、无线、管理平台尽量用同一家的产品不是说别的品牌不行而是跨品牌联调时策略联动、告警统一、认证对接都会多出很多工作量。医院信息科本来就人手紧张别给自己找麻烦。4.2 施工环境约束医院楼宇的特殊性比技术本身更考验人网络设计再合理施工队进场后往往会发现现实比图纸复杂得多。医院弱电施工有几个特殊的坑最好在需求阶段就考虑到写进对施工方的要求里。第一是医疗设备电磁兼容。大型医疗设备CT、MRI、DSA运行时对电磁环境有严格要求AP和交换机不能随意安装在设备机房内或贴得太近。施工前要和设备科拿到大型设备的布置图明确哪些区域是无线禁区哪些区域必须用医疗级设备。第二是施工时间窗口。门诊区域白天不能停诊施工住院病区白天也不能长时间打孔砸墙。很多医院网络改造只能在夜间10点到凌晨5点之间进行工期要按这个节奏排而且夜间施工的人工成本更高预算里要提前留出来。第三是老旧桥架和管井。老楼改造时经常遇到桥架已满、管井被占用的情况新线缆无处可走。需求表里可以要求施工前做一次现场路由勘查把桥架扩容和新增管井的费用单独列项而不是笼统打包到工程费里。4.3 试点病房验证先跑真实业务再全院大规模推广验收环节我强烈建议做“试点先行”。不要等全网建完了再统一验收那时返工成本极高。选一个病区或者一栋楼做试点真实业务跑两到四周重点验证这几件事移动护理PDA在病区所有点位是否流畅漫游是否掉线。患者Wi-Fi和办公网、业务网是否真正隔离互相访问是否被阻断。物联网终端资产标签、温湿度传感器等是否全部在线连接是否稳定。夜间高峰时段的视频拉取、PACS阅片是否卡顿。网络故障演练故意断一条核心链路或拔掉一台核心交换机主控观察业务恢复时间是否达到指标。这些验证项都通过后再逐步向全院推广。试点阶段发现的问题比如AP点位偏差、频段干扰、认证策略配置错误在单病区范围内解决的成本是很低的等铺开到全院再改就费劲了。最后再分享两个实操细节。一个是无线网络的频段信道规划建议在需求表里要求施工方在交付时提交信道规划表和AP点位图医院不是写字楼楼层间信号串扰非常普遍没有一张准确的点位图后续排查干扰会非常痛苦。另一个是验收时要求做一次第三方无线评测让监理或专业测试机构拿着设备沿病区走廊走一圈测信号强度、漫游时延和丢包率用数据说话而不是只看“信号满格”的体感。这些细节我在不同项目里反复验证过踩过的坑多了之后你会发现智慧医院网络项目能不能顺利交付往往不取决于用了多贵的设备而是这些看似琐碎的需求定义得够不够清楚。
