2. 医疗系统接口生态与协议解析
医疗系统的接口生态不是单一协议栈，而是由多种协议按“临床场景—数据形态—交互时效”分工协作形成的组合体。做接口自动化测试时，如果只按 HTTP 状态码和 JSON 字段做断言，很容易漏掉医疗语义层的错误。本节先建立一张协议分工图，再逐个拆解每种协议的接口形态与测试关注点。
HL7 v2.x：管道分隔消息与 MLLP 传输
HL7 v2.x 是医院内部系统间最普遍的接口形态，典型场景是 LIS 向 HIS 回传检验结果（ORU^R01）。消息以段（Segment）为单位，段内字段用竖线 | 分隔，字段内分量用 ^ 分隔，重复字段用 ~ 分隔。传输层通常使用 MLLP（Minimal Lower Layer Protocol），即在消息前后加 0x0B 和 0x1C 0x0D 作为帧边界。
测试关注点首先是帧边界与编码：MLLP 帧头帧尾缺失会导致接收端一直等待，表现为连接不关闭但无响应。其次是 MSH 段中的 MSH-9 消息类型、MSH-10 消息控制 ID、MSH-11 处理 ID 和 MSH-12 版本号，这些字段决定接收端如何路由和去重。第三是 ACK 应答：接收端返回 MSA-1 为 AA 表示接受，AE 表示错误，AR 表示拒绝。自动化测试不能只断言“收到 ACK”，必须解析 MSA-1 并核对 MSA-2 是否回显了原消息控制 ID。
一个可复用的断言示例：发送 ORU^R01 后，在 5 秒内读取 ACK，断言 MSA-1 == "AA" 且 MSA-2 == 原 MSH-10；若为 AE，则进一步读取 ERR 段中的错误码和错误位置，定位是字段缺失还是编码不合法。
FHIR R4：资源化 REST 接口
FHIR 把医疗数据抽象为资源（Resource），如 Patient、Observation、Encounter、DiagnosticReport，通过 RESTful 风格暴露：GET /Patient/{id}、POST /Observation、GET /Patient?identifier=...。数据格式以 JSON 为主，也支持 XML。FHIR 的价值在于资源之间的引用关系，例如 Observation 通过 subject 引用 Patient，通过 encounter 引用就诊。
测试关注点与普通 REST 不同：一是资源结构校验，必填元素、基数（0..1、1..1、0..*）和数据类型必须符合 Profile；二是搜索参数，_count、_offset、_sort、_include 的行为需要逐项验证，尤其是分页时 Bundle.link 中 next 链接是否可用；三是错误响应，FHIR 要求返回 OperationOutcome 资源，其中 issue.severity 和 issue.code 是判断错误类型的关键；四是版本与并发，ETag 和 If-Match 用于乐观锁，测试时应验证版本冲突时返回 409 而非静默覆盖。
DICOM：影像与元数据一体化
DICOM 不是文本消息协议，而是二进制对象协议。一次 CT 检查包含多个 SOP Instance，每个实例由 SOP Class UID 和 SOP Instance UID 唯一标识，像素数据与患者、检查、序列等元数据封装在同一数据集中。传统 DIMSE 服务使用 C-STORE 存储、C-FIND 查询、C-MOVE 检索；现代 DICOMweb 则提供 WADO-RS、QIDO-RS、STOW-RS 等 REST 接口。
测试关注点集中在 UID 一致性和传输语法：同一 Study 下 Series 与 Instance 的层级关系必须正确，StudyInstanceUID、SeriesInstanceUID、SOPInstanceUID 不能混用；传输语法（如 Implicit VR Little Endian、Explicit VR Little Endian、JPEG Baseline）决定了解析方式，压缩影像需要验证解压后像素与原始一致。C-STORE 的响应状态码 0000 表示成功，0110 表示处理失败，A700 表示资源不足，自动化测试应逐实例断言状态码并统计失败实例数。
SOAP：契约优先的 Web Service
SOAP 在医疗领域常见于旧版 HIS、医保结算和区域平台接口。其接口形态由 WSDL 定义，请求体是 XML Envelope，包含 Header 和 Body。测试关注点首先是契约符合性：请求 XML 必须符合 WSDL 中定义的 schema，元素顺序、命名空间、必填属性都不能错。其次是 Fault 处理：SOAP Fault 的 faultcode 和 faultstring 是判断业务错误与系统错误的关键，不能只依赖 HTTP 500。第三是 WS-Security，涉及用户名令牌、时间戳和签名时，需要验证过期时间、签名有效性和重放保护。
WebSocket：实时生命体征推送
WebSocket 用于监护仪、可穿戴设备等需要持续推送的场景。客户端与服务端通过 HTTP Upgrade 握手建立长连接，之后以帧为单位双向传输。测试关注点包括：握手阶段子协议协商是否正确；消息顺序与丢失，推送数据通常带时间戳和序列号，需要验证乱序和丢包；心跳与重连，长时间无数据时是否发送 Ping/Pong，断线后是否自动重连并补发；背压处理，当客户端消费慢时服务端是否丢弃或缓冲，丢弃策略是否符合临床要求。
跨协议测试的公共关注点
无论哪种协议，医疗接口测试都有四个公共关注点。第一是患者标识一致性：同一患者在 HL7 的 PID-3、FHIR 的 Patient.identifier、DICOM 的 PatientID 中必须指向同一主索引，否则会出现“结果找不到患者”。第二是时间语义：HL7 的 YYYYMMDDHHMMSS、FHIR 的 dateTime、DICOM 的 DA/TM 格式不同，时区和精度必须统一。第三是编码系统：性别、检验项目、诊断编码可能使用 HL7 表、LOINC、SNOMED CT、ICD-10，测试要验证编码映射而非仅验证文本。第四是幂等与重传：医疗接口常因网络抖动重发，接收端必须能通过消息控制 ID 或资源版本去重，自动化测试应构造重复消息并断言不产生重复记录。
把上述关注点落到测试用例设计上，可以按“协议—场景—断言”三层组织：协议层验证连接、帧、编码；场景层验证一次完整的业务闭环，如“开医嘱—采样—出结果—回传—归档”；断言层则分别检查传输成功、结构合法、语义正确和业务状态一致。只有三层都通过，才能认为该接口在医疗场景中可用。