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表示。我已将其设置为允许尾随分隔符为ON。如您所见，此段中有一个尾随分隔符，但是这是在段中的最后一个字段之后，恰好包含上面显示的数据。

总是如此，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 Messaging Standard Version 2.6没有将PV1段扩展到其他字段，因此从支持仅52个段字段开始，您的原始代码是正确的

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

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

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

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

Answer 2

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

我建议在接收管道组件中处理此问题并使用Microsoft支持提升它

HL7加速器尾随分隔符预期行为

2 个答案:

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