1

考虑 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) 字段，则允许该消息。

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

4

2 回答 2

2

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

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

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

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

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

于 2014-08-01T12:12:31.260 回答
1

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

我建议在接收管道组件中处理此问题并在 Microsoft 支持下提出

于 2014-08-01T03:48:24.030 回答