接收的HL7消息格式异常：MSH与EVN段位于同一行

针对你遇到的MSH和EVN段拼接在同一行的问题，可按以下方向排查：

• 检查出站侧段分隔符配置
  HL7标准默认使用ASCII的CR字符（\r）作为段分隔符。确认出站系统的段分隔符配置是否正确：

  • 查看出站模板中MSH段的结尾是否包含了正确的段分隔符，有没有被误删或替换；
  • 确认系统是否将段分隔符错误设置为空、LF（\n）或其他字符，导致段之间无分隔直接拼接。

• 排查消息序列化逻辑

  • 检查出站系统的消息生成代码/组件，是否在每个段（包括首个MSH段）结束后都追加了段分隔符。部分自定义序列化逻辑容易遗漏第一个段的分隔符；
  • 确认是否存在字符清洗/过滤规则，把CR/LF这类段分隔符替换成了空字符，导致段边界丢失。

• 验证传输过程中的消息完整性

  • 用抓包工具或查看接收端的原始消息文件，确认传输过来的消息本身就没有段分隔符，还是接收端解析时的问题；
  • 排查中间传输设备（网关、代理、FTP服务器等）是否修改了消息内容，比如自动转换CRLF为LF，或压缩转义时丢失了段分隔符。

• 检查HL7版本与字段合法性

  • 你使用的是HL7 2.4版本，确认出站系统的版本配置是否与消息中的MSH-12（Version ID）一致，部分系统版本不匹配会导致序列化异常；
  • 检查MSH段的字段是否符合规范，比如MSH-12的内容是2.4，确认该字段没有被截断或额外拼接内容，导致后续EVN段被错误连在一起。

• 最小化场景测试

  • 构造仅包含MSH和EVN的极简消息，用出站系统发送，验证问题是否复现：若消失，说明是原消息中其他字段的特殊字符导致序列化错误；若复现，锁定为基础配置或序列化逻辑问题；
  • 手动在MSH段结尾添加CR字符后发送，若接收端能正常解析，说明问题完全出在发送侧的生成逻辑。

内容的提问来源于stack exchange，提问作者Swarnamala Sekar