3. HL7 v2消息交互模式
HL7 v2 的接口引擎并不是“收到消息就回 ACK”这么简单。真正决定接口稳定性的，是消息双方对交互模式的约定：谁发起、谁应答、应答里带什么、失败时如何回退。若交互模式没有在接口设计阶段明确，后续排障时就会出现“消息已发出但业务未落库”“ACK 是 AA 但数据没更新”这类难以定位的问题。本节围绕查询、响应、主动更新、确认模式、增强确认模式与错误处理机制展开，重点说明每种模式在引擎中的处理路径与判断依据。
一、查询与响应：拉取式交互
查询（Query）由消费方主动发起，典型触发事件为 QRY^Q01（旧式）或 QBP^Q11（v2.5 以后），响应为 QRY^Q02 或 RSP^K11。查询消息的核心是查询条件，通常放在 QPD 段中，例如按患者标识、就诊号或时间范围检索。响应消息则用 RSP 段承载结果状态，用 QAK 段回传查询标签与命中数量，用 QPD 段回显原始条件，再用若干重复的 PID/PV1/OBX 等段返回数据行。
在接口引擎中，查询处理的关键是查询标签（Query Tag）的生成与回传。引擎收到 QBP 后，先解析 QPD-2 中的查询标签，再按 QPD-3 的查询条件调用业务查询服务，最后把同一标签写入 RSP 的 QAK-1。若命中 0 条，QAK-2 返回 NF（未找到）；若命中多条，QAK-2 返回 OK，QAK-4 给出命中总数。这样发起方才能把响应与请求一一对应，避免并发查询时结果错配。
二、主动更新：推送式交互
主动更新（Unsolicited Update）由数据产生方主动推送，典型如 ADT^A01（入院）、ADT^A08（信息更新）、ORM^O01（医嘱）、ORU^R01（检验结果）。这类消息不等待对方查询，而是“有变化就发”。引擎收到后需要完成三件事：校验消息结构、按 MSH-9 路由到对应处理器、把业务数据写入目标系统或触发下游动作。
主动更新的风险在于重复推送与顺序错乱。同一患者短时间内连续 A08，若引擎按到达顺序处理，可能先写旧值再写新值。因此引擎通常结合 MSH-10（消息控制 ID）做幂等判断，结合 EVN-2（事件发生时间）或 PV1-44（入院时间）做顺序判断。示例中，若两条 A08 的 MSH-10 不同但 EVN-2 相同，引擎应保留后到者并记录覆盖日志，而不是简单追加。
三、确认模式：ACK 的三种应答码
确认模式（Original Acknowledgment Mode）是最基础的应答机制。接收方处理完消息后返回 ACK，MSA-1 给出应答码：AA 表示接受，AE 表示错误，AR 表示拒绝。AA 仅代表消息在语法和结构上被接受，并不必然代表业务已成功落库；AE 通常表示可重试的处理错误，如数据库暂时不可用；AR 表示不可重试的拒绝，如患者标识非法、消息版本不支持。
引擎在返回 ACK 时，必须把原消息的 MSH-10 写入 MSA-2，把原 MSH-3/MSH-4 与自身 MSH-5/MSH-6 对调，形成正确的收发关系。若 MSH-15/16 未设置，默认采用“接收后确认”，即消息一进入引擎就回 ACK，业务处理异步进行。这种模式下 ACK 快，但业务失败无法通过 ACK 反馈，需要额外告警。
四、增强确认模式：接受确认与处理确认分离
增强确认模式（Enhanced Acknowledgment Mode）通过 MSH-15（接受确认类型）和 MSH-16（应用确认类型）把确认拆成两段。MSH-15 控制“是否回接受确认”，MSH-16 控制“是否回处理确认”。常见取值为 AL（总是）、NE（从不）、ER（仅错误时）、SU（成功时）。当 MSH-15=AL、MSH-16=AL 时，接收方先回一条 ACK（接受确认），业务处理完成后再回一条 ACK（处理确认），两条 ACK 的 MSA-1 分别反映接受结果与处理结果。
这种模式适合“消息量大、业务处理慢”的场景。例如检验结果推送，引擎可先回接受确认让发送方释放连接，再在结果入库后回处理确认。若处理失败，处理确认的 MSA-1 返回 AE，并在 ERR 段给出错误码与错误位置。发送方据此决定是否重发，而不是盲目重试。
五、错误处理机制：ERR 段与重试策略
错误处理的核心是 ERR 段。ERR-1 给出错误码与错误位置，ERR-2 给出错误严重程度（W 警告、E 错误、F 致命），ERR-3 给出用户可读的诊断信息。例如患者标识为空时，可返回 ERR-1 为“100^Required field missing^HL70357”，ERR-2 为 E，ERR-3 为“PID-3 患者标识不能为空”。引擎应把 ERR 段与 MSA-1=AE 或 AR 配合使用，让发送方明确知道失败原因。
重试策略需要区分错误类型。对于 AE（可重试），发送方可在退避后重发，但必须保证 MSH-10 不变以支持幂等；对于 AR（不可重试），重发无意义，应转人工处理。若采用增强确认模式，接受确认失败通常意味着消息结构问题，处理确认失败则意味着业务问题，两者的重试策略应分别配置。建议在引擎中维护一张错误码与动作映射表，例如“数据库连接失败 → 延迟 30 秒重试 3 次”“患者不存在 → 转人工队列”，避免所有错误都走同一套重试逻辑。
六、模式选择与配置要点
选择交互模式时，先判断数据流向：需要按条件检索用查询/响应，数据变化主动通知用主动更新。再判断可靠性要求：内部系统、网络稳定可用确认模式；跨机构、消息量大或业务处理耗时较长，优先增强确认模式。配置时重点检查 MSH-15/16 是否与对端一致，MSA-2 是否回填原 MSH-10，ERR 段是否包含可定位的错误位置。只有把交互模式、确认级别与错误处理三者对齐，接口引擎才能在异常时给出可判断、可追溯、可恢复的反馈。