HL7消息进入Mirth并引发“处理”错误。在Raw格式的消息的最底部是一条与其上方的行分开的部分行。我每次都必须手动纠正这个问题。我希望使用Mirth-Javascript作为消息过滤器来解决这个问题，这样一切都可以在没有人为干预的情况下流动。
消息片段下面会触发错误。在这个例子中，它是HL7消息的最后一行。
OBX|68|FT|PT6663&IMP^PET/CT Imaging Whole Body||
||||||F|||202254836969552|||
目前我唯一的解决方法是打开HL7消息并手动转到换行符并将其提升到该段上方的一行。
HL7消息应如下所示：
OBX|68|FT|PT1103&IMP^PET/CT Imaging Whole Body||||||||F|||20190327101958|||
删除通道预处理器或附件脚本中的所有线制动器，然后根据段名称将其重新插入。最好的方法是停止消息生成系统将线制动器插入OBX.5字段。
根据您的问题，包含换行符的HL7字段是OBX(5,1)，它应该包含观察值。
观察值可能包含换行符作为数据的一部分。换行符（<CR>或ASCII 13）默认为段分隔符。如果将其作为数据的一部分接收，则在解析消息时会出现问题。这是您在问题中提到的问题的根本原因。
正如@AlonEitan在评论中所提到的：
The segment separator is not negotiable. It is always a carriage return。
理想情况下，在构建HL7消息时，应使用其转义序列替换这些换行符。关于它的更多细节已经在我之前的一个答案here中给出。
那么，您的入站消息
OBX|68|FT|PT6663&IMP^PET/CT Imaging Whole Body||
||||||F|||202254836969552|||
应该是
OBX|68|FT|PT6663&IMP^PET/CT Imaging Whole Body||\X0D\\X0D\||||||F|||202254836969552|||
关于如何使用Mirth / Javascript执行此操作的实际问题，在您的特定用例中应该不需要。在向Mirth发送消息之前，应该进行此转换。因此，向您发送此消息的人应该像这样构建它。
实际上在UI上显示观察值时，您再次需要执行相反的过程。
编辑：
如果换行符不同于<CR>（ASCII 13），则应在\X0D\中替换相应的HEX。我的链接答案中提到了详细信息;我不是在重复这些。
删除所有换行符是一种方法，但稍后可能会出现问题，您可以设置替换脚本，而不是'/ n'，搜索'| / n |'或者类似的字符串，这样，它会解决特定问题以及垂直分隔符之间的任何其他不需要的换行符，如果它在其他地方破坏它就没有帮助，所以请记住这一点。