2. 医疗设备通信需求分析
医疗设备通信不是把网线插上、把数据发出去那么简单。同一家医院里，监护仪每 1 秒要推送一次生命体征，输液泵要在报警后 200 ms 内把事件送达护士站，而一台 CT 的影像传输可以容忍几秒延迟却绝不能容忍一个字节出错。因此，通信架构设计的第一步不是选协议，而是把临床场景翻译成可量化、可验证的需求指标。本节围绕临床场景、实时性、可靠性、安全性、可用性、可维护性和法规约束七个维度展开，并给出可落地的需求分析方法。
一、临床场景决定需求优先级
需求分析必须从“谁在用、用来干什么、出错会怎样”出发。可以按临床风险把场景分为三类：
- 生命支持与实时监护类：监护仪、呼吸机、麻醉机、输液泵。特点是数据周期短、报警必须及时，通信中断可能直接危及患者。
- 诊断与影像类：CT、MR、超声、PACS。特点是单次数据量大、对完整性要求极高，对时延相对宽容。
- 管理与辅助类：移动护理终端、药品柜、资产定位。特点是并发设备多、单点数据小，但可用性和身份认证要求高。
场景分类的意义在于：它决定了后续实时性、可靠性、安全性指标的取值方向，而不是所有设备都套用同一套“高可靠、低时延”的模糊要求。
二、实时性：把“快”变成可测量的数字
实时性需求应拆成三个可测量指标：采样周期（设备产生数据的间隔）、端到端时延（从采集到接收方可用）、时延抖动（时延的波动范围）。例如某监护场景要求：心率数据采样周期 1 s，端到端时延 ≤ 500 ms，抖动 ≤ 100 ms；而输液泵阻塞报警要求端到端时延 ≤ 200 ms，且不允许抖动超过 50 ms，因为报警延迟直接影响处置时机。
工程上要区分“软实时”和“硬实时”。影像归档属于软实时，允许排队和重传；报警与闭环控制属于硬实时，超时即视为失败。需求文档中应明确写出超时判定阈值和超时后的行为（重发、本地报警、切换链路），而不是只写“低延迟”。
三、可靠性：不是“不出错”，而是“出错可恢复”
可靠性需求通常用可用性、误码率、丢包率和故障恢复时间描述。医疗通信中更关键的是数据完整性与故障可恢复性：一条用药医嘱被截断或错序，比丢失一条普通日志严重得多。因此需要明确：
- 是否允许丢包，允许的比例是多少（如监护波形可容忍 1% 丢包，但报警事件必须 0 丢失）；
- 是否要求确认与重传，重传超时和最大重试次数是多少；
- 链路或节点故障后，多久必须恢复（如 ≤ 3 s 切换备用链路）；
- 是否需要本地缓存，断网期间数据保留多久、恢复后如何补传。
这些指标直接决定后面选用 TCP 还是 UDP、是否需要双链路、是否部署边缘缓存。
四、安全性：保护数据，也保护患者
医疗通信安全包含三个层面：机密性（患者数据不被窃听）、完整性（数据不被篡改）、可用性（不被攻击导致服务中断）。需求分析时要落到具体机制：设备身份认证方式（证书或预共享密钥）、传输加密（TLS 版本与套件）、访问控制（谁能读、谁能写）、审计日志（谁在何时访问了哪台设备）。
特别要注意：安全措施不能以牺牲实时性为代价。例如报警通道若强制走完整 TLS 握手，可能引入数百毫秒延迟，此时可采用会话复用或轻量加密方案，并在需求中写明“安全机制引入的额外时延上限”。
五、可用性、可维护性与法规约束
可用性关注系统在需要时能否正常工作，常用“年停机时间”衡量，如关键监护网络年不可用时间 ≤ 5 分钟。可维护性关注故障能否被快速发现、定位和修复，需求应包括：设备与链路状态可监控、故障可告警、配置可远程下发、固件可安全升级、日志可追溯。可维护性差的系统，即使初始指标达标，长期运行也会因排障困难而降低实际可用性。
法规约束是医疗通信区别于普通工业通信的核心。需求分析必须考虑：医疗器械注册与网络安全审查要求、患者数据隐私保护法规、电磁兼容与电气安全标准、以及医院信息系统互联互通规范。法规要求往往转化为“必须留存审计记录”“必须支持数据导出格式”“必须通过指定安全测试”等硬性条目，应在需求阶段就纳入，而不是等到验收才补。
六、需求分析的可视化方法
把上述维度落到具体设备上，最有效的方式是建立“场景—指标—约束”的映射关系。下图以监护仪、输液泵、CT 三类典型设备为例，展示从临床场景到通信需求指标、再到法规与工程约束的推导路径，帮助在架构设计前看清每个指标的来源和优先级。
七、需求条目的写法与检查
需求分析最终要输出可验证的条目，而不是形容词。推荐每条需求包含：对象、指标、阈值、验证方法。例如：“输液泵报警事件从产生到护士站显示，端到端时延 ≤ 200 ms，采用时间戳比对法在 1000 次报警中验证，超时率 0%。”这样的条目可以直接进入测试用例。
检查需求是否完整，可以问四个问题：临床最坏情况下指标是否仍成立？安全机制是否引入不可接受的时延？故障后是否有明确的降级和恢复路径？法规要求的记录和导出是否已纳入？四个问题都能回答，需求分析才算闭环，后续的协议选型、网络拓扑和冗余设计才有可靠依据。