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 回答