消息编码
要使 HL7 有用,定义消息语义是不够的。 确定消息内容后,标准必须说明如何在实际接口中表示该内容。 也就是说,必须有指定的“消息编码”。 HL7 版本 2 支持两种形式的消息编码:基于自定义分隔符的编码和 XML 编码。
HL7 选择原始的基于分隔符的编码来尽可能减小消息的大小。 例如,如果将分隔符分隔元素的数据结构与将每个元素置于固定位置集的结构进行比较,则如果) 消息不包含某些元素,并且 b) 某些元素未填充允许的所有空间,则基于分隔符的结构会更加经济。 基于分隔符的结构中唯一的开销是分隔符本身。
原始 HL7 编码定义了五个分隔符,每个消息在 MSH 段中声明这些分隔符。 这些指示:
段数
字段
组件
子组件
字段、组件或子组件) 的重复 (
请注意,由于分隔符是编码的基本方面,必须首先定义它们。 其一个结果是不能有子分隔符。 有时,此限制会对新数据类型的设计产生不幸的影响。
2003 年 6 月,HL7 发布了 HL7 版本 2,XML 编码语法版本 1。 此标准为 HL7 版本 2.3.1 和 2.4 消息定义备用编码规则,并提供一种机制,用于确定后续 HL7 2.X 版本的备用编码规则。 实质上,此新标准为版本 2.3.1 和 V2.4 抽象消息、段、字段和数据类型定义 XML 元素标记,并创建规则,用于定义为版本 2 标准的后续版本创建的任何新结构所需的标记。 定义此标准的过程导致了版本 2.4 和 2.5 中的一系列改进。 之所以出现这种情况,是因为创建 XML 标记导致需要解决基础标准中一些长期存在的歧义问题。 因此,创建了) 定义完善的消息结构代码,以指示与触发器事件关联的抽象消息中的变体,b) 具有抽象消息的重复段组被正式标识和命名,c) 本地定义的数据类型,CM 被替换为更具体的类型。
例如,下面是使用传统管道分隔格式的简单确认消息:
MSH|^~\&|LAB|767543|ADT|767543|199003141304-0500||ACK^^ACK|XX3657|P|2.4
MSA|AR|ZZ9380
ERR|PID^1^16^103&Table value not found&HL70357
相比之下,以下消息表示为 XML 文档:
<ACK
xmlns="urn:hl7-org:v2xml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:hl7-org:v2xml ACK.xsd">
<MSH>
<MSH.1>|</MSH.1>
<MSH.2>^~\&</MSH.2>
<MSH.3>
<HD.1>LAB</HD.1>
</MSH.3>
<MSH.4>
<HD.1>767543</HD.1>
</MSH.4>
<MSH.5>
<HD.1>ADT</HD.1>
</MSH.5>
<MSH.6>
<HD.1>767543</HD.1>
</MSH.6>
<MSH.7>
<TS.1>199003141304-0500</TS.1>
</MSH.7>
<MSH.9>
<MSG.1>ACK</MSG.1>
<MSG.3>ACK</MSG.3>
</MSH.9>
<MSH.10>XX3657</MSH.10>
<MSH.11>
<PT.1>P</PT.1>
</MSH.11>
<MSH.12>
<VID.1>2.4</VID.1>
</MSH.12>
</MSH>
<MSA>
<MSA.1>AR</MSA.1>
<MSA.2>ZZ9380</MSA.2>
</MSA>
<ERR>
<ERR.1>
<ELD.1>PID</ELD.1>
<ELD.2>1</ELD.2>
<ELD.3>16</ELD.3>
<ELD.4>
<CE.1>103</CE.1>
<CE.2>Table value not found</CE.2>
<CE.3>HL70357</CE.3>
</ELD.4>
</ERR.1>
</ERR>
</ACK>
Microsoft BizTalk Accelerator for HL7 (BTAHL7) 的以下功能支持这些要求:
支持管道分隔和 XML 编码。
支持在 XML 和管道分隔编码之间进行转换。
另请参阅
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈