HL7 加速器尾随定界符预期行为

Question

考虑 HL7v2 消息中的以下 PV1 段。

PV1|1|E|MYLOC||||55555^Doctor^Doc^D^^Dr^^DOCT|||||||HO||||ER||BC|||||||||||||||||||VALUE||REG|||201406270627||||||||55555^Doctor^Secondary^H^^Dr^^DOCT2|

那里有 52 个字段。我们的 Meditech 系统始终在此接口上发送字段 52 (PV1_52_OtherHealthcareProvider)，此处表示为 55555^Doctor^Secondary^H^^Dr^^DOCT2. 。我已经这样设置了 允许尾随分隔符 已开启。正如您所看到的，该段中有一个尾随分隔符， 然而 这是段中最后一个字段之后的字段，该字段恰好包含上面显示的数据。

情况始终如此，Meditech 始终在此接口上附加尾随分隔符。

其他段的最终字段中都没有数据，因此尽管它们具有尾随分隔符，但我们尚未遇到此问题。在 PV1 段上，我们收到错误：

Error happened in body during parsing 
Error # 1
Segment Id: PV1
Sequence Number: 1
Error Number: 100
Error Description: Segment sequence error (Unexpected end of message body found)
Encoding System: HL79999

事实证明这是由于尾随分隔符造成的，因为手动删除分隔符并重新提交，不会出现错误。另外，如果我修改架构以添加 假的 (PV1_53_ExtraField) 字段，该消息是允许的。

我的问题是这样的：的预期行为是什么 允许尾随分隔符 在这种情况下？是否应该允许尾随分隔符 全部 情况，还是仅适用于最终字段没有数据的段（即：段末尾的额外字段）？

Answer 1

在接收管道上，段中最后一个字段后面不能有分隔符。看起来这是 HL7 加速器中的一个错误。仅当分隔符位于定义的字段数量内时，此属性似乎才会对发送端产生一些影响。

我建议在接收管道组件中处理这个问题，并通过 Microsoft 支持提出它

Answer 2

虽然即使 HL7 消息传递标准版本 2.6 没有用其他字段扩展 PV1 段，因此从仅支持 52 个段字段的角度来看，您的原始代码是正确的

1. 使用自定义字段和自定义段扩展 HL7 消息传递协议是完全有效的，前提是此扩展得到所有相关方的同意并记录在 HL7 一致性声明 （你可以找到一些解释链接 这里 和 这里)

2. 您的解析和消息处理代码应该与协议的旧版本和某些未来版本兼容。段的数量、它们的名称和顺序以及字段的数量和字段中的组件的数量可以被动态地确定和处理。消息语法旨在支持它。硬编码之类的东西 “无论 HL7 版本字段 MSH-12 包含什么，PV1 段中都会有 52 个字段” 这不是很好的方法，因为它无法扩展

..在这种情况下允许尾随分隔符的预期行为是什么？..

预期的行为是您的应用程序不会崩溃，不会阻止数据处理，如果数据通过您的代码传输到另一个系统，您不应该删除/删除您不理解的字段（它或多或少是在 HL7 规范中编写的）某处..）