时间戳

首页 > 解决方案 > 将 OML_O33 消息上的多个 ORC OBR 重复处理为 OML_O33_ORDER 实例

java - 将 OML_O33 消息上的多个 ORC OBR 重复处理为 OML_O33_ORDER 实例

问题描述

我正在使用 Java HAPI v2.3 生成 OML_O33（用于 IHE LAB-63 配置文件）HL7 v25 消息。消息应支持多个 ORDER 组（即消息配置文件），但由于 ORDER 和 ORDER_PRIOR 组中 ORC/OBR 序列的定义不明确，当解析扁平 HL7 字符串时，解析器无法识别 ORDER 组的多个实例，无法识别它们作为 ORDER_PRIOR 组。

我使用 OML_O33 类正确建模，对于单个 OML_O33_SPECIMEN 组，已添加多个 OML_O33_ORDER 组。

OML_O33 omlO33;

...

omlO33.getSPECIMENAll().size()  // displays 1
omlO33.getSPECIMEN(0).getORDERAll().size()  // displays 2

消息按预期正确序列化为 HL7 字符串，例如：

MSH|^~\&|System Test|System Test|LIS Test|LIS Test|20190911105010.527+0200||OML^O33^OML_O33|2787136c-8885-4f7c-a0bb-8190b5c73ff1|D|2.5
PID|||patientIdFoo123^^^N/A||surnameFoo123^nameFoo123||20190911|M||||||||||accountNumberFoo123^^^N/A
SPM|1|barcodeFoo0||specimenFoo123|||||||||||||20190911105010.555+0200||||||||||0^REF1230
ORC|SC|bbc4bdaa-25bc-426f-830c-0737af9ecdb8||pgnFoo123||||||||doctorIdFoo^doctorSurnameFoo^doctorNameFoo
OBR||bbc4bdaa-25bc-426f-830c-0737af9ecdb8||orderIdFoo0^orderDescriptionFoo0||||||phlebotomistFoo123||||||doctorIdFoo^doctorSurnameFoo^doctorNameFoo|||||||||S
ORC|SC|8fa86d07-4f8d-4cda-ac64-3f58a5ab6acf||pgnFoo123||||||||doctorIdFoo^doctorSurnameFoo^doctorNameFoo
OBR||8fa86d07-4f8d-4cda-ac64-3f58a5ab6acf||orderIdFoo1^orderDescriptionFoo1||||||phlebotomistFoo123||||||doctorIdFoo^doctorSurnameFoo^doctorNameFoo|||||||||S

消息通过Gazelle IHE 验证器，但当转换为字符串并“返回”解析（使用标准 PipeParser 和库提供的 DefaultHapiContext）时，它会被重新解释为单个 ORDER 组和 ORDER_PRIOR 组。

OML_O33 omlO33;

...

omlO33.getSPECIMENAll().size()  // displays 1
omlO33.getSPECIMEN(0).getORDERAll().size()  // displays 1
omlO33.getSPECIMEN(0).getORDER(0).getOBSERVATION_REQUEST().getPRIOR_RESULTAll().size() . // displays 1

我希望看到 2 个 ORDER 组，根本没有 ORDER_PRIOR 组。

如果我添加一个 FT1 空段来“打破”歧义，则会正确解析消息（2 个 ORDER 组而不是 1 个），但此解决方案在我的系统中是不可接受的。

我宁愿避免使用 Terser 访问 ORC/OBR 段实例，而是依赖模型表示。

标签： javaparsingencodehapihl7-v2

解决方案

推荐阅读