HL7(Health Level Seven)

        

HL7(Health Level Seven)

​Health Level 7或HL7是指一组国际标准，用于在各种医疗提供者使用的软件应用程序之间传输临床和管理数据。这些标准侧重于应用层，即OSI 模型中的“第 7 层”。HL7标准由国际标准组织Health Level Seven International制定，并被美国国家标准协会、国际标准化组织等其他标准发布机构采用。

 ​

     医院和其他医疗提供者组织通常有许多不同的计算机系统，用于从计费记录到患者跟踪的所有内容。所有这些系统在收到新信息或希望检索信息时都应该相互通信（或“接口”），但并非所有系统都这样做。

    HL7 International指定了许多灵活的标准、指南和方法，各种医疗系统可以通过这些标准、指南和方法相互通信。此类指南或数据标准是一组规则，允许以统一和一致的方式共享和处理信息。这些数据标准旨在让医疗机构能够轻松共享临床信息。从理论上讲，这种交换信息的能力应该有助于最大限度地减少医疗在地理上孤立和高度可变的趋势。

    HL7 International将以下标准视为其主要标准 -- 最常用和实施的标准：

• 版本 2.x 消息传递标准——健康和医疗交易的互操作性规范。
• 第 3 版消息传递标准——健康和医疗交易的互操作性规范。
• 临床文档架构(CDA)——基于 HL7 版本 3 的临床文档交换模型。
• 连续性护理文件(CCD)——基于 CDA 的医疗摘要交换的美国规范。
• 结构化产品标签(SPL)——随药物发布的信息，基于 HL7 第 3 版。
• 临床上下文对象工作组(CCOW)——用户应用程序可视化集成的互操作性规范。

    其他 HL7 标准/方法包括：

    快速医疗互操作性资源(FHIR)——资源交换标准。

• Arden Syntax——一种将医疗状况和建议表示为医疗逻辑模块(MLM)的语法。
• 索赔附件——标准的医疗附件，以增加另一项医疗交易。
• 的功能规范电子健康记录(EHR）/个人健康记录（PHR）系统 - 保健和医疗功能的标准化描述寻求或软件等应用程序中提供。
• GELLO——用于临床决策支持的标准表达语言

版本 2

    HL7 版本 2 标准（也称为 Pipehat）旨在支持医院工作流程。它最初创建于 1987 年 10 月。

    HL7 版本 2 定义了一系列电子消息以支持管理、后勤、财务和临床流程。自 1987 年以来，该标准定期更新，产生了 2.1、2.2、2.3、2.3.1、2.4、2.5、2.5.1、2.6、2.7、2.7.1、2.8、2.8.1 和 2.8.2 版本。v2.x 标准向后兼容（例如，基于 2.3 版的消息将被支持 2.6 版的应用程序理解）。

    HL7 v2.x 消息使用基于段（行）和单字符分隔符的非XML编码语法。段具有由复合分隔符分隔的复合（字段）。复合可以具有由子复合分隔符分隔的子复合（组件），并且子复合可以具有由子子复合分隔符分隔的子子复合（子组件）。默认分隔符是段分隔符的回车符、字段分隔符的竖线或竖线、组件分隔符的插入符号、子组件分隔符的与号和默认截断分隔符的数字符号。波浪号（|^&~）是默认的重复分隔符。每个段以 3 个字符的字符串开头，用于标识段类型。消息的每一段都包含一个特定类别的信息。每条消息都有MSH其第一段，其中包括一个标识消息类型的字段。消息类型决定了消息中预期的段类型。特定消息类型中使用的段类型由 HL7 标准中使用的段语法表示法指定。

HL7 2.x 结构介绍

MSH|^~\&|MediII|MediInfo|WXXD|YX|20200720151947||ADT^A10^ADT_A09|cc492d953bb14b7991f73391e3775ec8|P|2.4
EVN|A10|20210720151947||||20210720151947
PID||357778999^0|357778999^^^JG01~155484212^^^JG02~5484213565^^^JG03~~~326632365516^^^JG06~78554215^^^JG07~212545wwe^^^JG08~~4581584^^^JG10~|0|ZhangSan^张三||19440426000000|1|||北京市朝阳区xxxx街道^260005^260005^260005^260005^^H^^260005~^^^^-^^W^-~北京市朝阳区xxx街道^260005^260005^260005^^^R||^^01^^^^18365655555~^^02|||||330227194404267517|3325626262688888|||01^汉族|北京/朝阳/xx街道|||||156^中国||0
PV1|2|I|06^06^06481^0505055&胸外科一&0^^胸外科(1)病区|R|||10178^^梁三^^^^^^^^^^^0402&胸外一D组|||||||||||150|10107360||YKT301||||20210720|||||||||||||||||0505055^^^1||20200720151947||||||2|V|10178^^梁三~16388^^曹四
OBX|0|NM|25^年龄||77|岁|||||F|||20200720151947
DG1|1|E11.900||2型糖尿病||A

    下面就是一个ADT_A09类型下的A10的消息，查阅官方文档中，A10是Patient arriving—> 患者到达的消息，当然大部分情况下，我们都是根据厂商提供的文档来进行解析，而厂商也是参考HL7官方的文档，来确定他们的消息内容，这里的A10，代表的是入院消息。

段

    在HL7消息中，消息的每个部分都包含一类特定的信息，例如患者信息或患者就诊数据。这里提到的部分就是段，也就是每一行后都会有一个回车符 < CR >

    消息中每个段的名称由该段的第一个域(fields)指定，该域始终为三个字符。HL7消息中可使用超过120个不同的HL7段，此示例消息包含6个HL7段：MSH，EVN，PID，PV1，OBX，DG1，不同类型的HL7消息包含不同的HL7段。

段名称：

• MSH（消息头）：段包含有关消息本身的信息。该信息包括消息的发送者和接收者、消息的类型以及发送的日期和时间。每个HL7消息都将MSH指定为其第一段。
• PID（患者信息）：段包含有关患者人口统计信息，例如姓名、患者ID和地址。
• NK1（近亲信息）：细分包含患者近亲的联系信息。
• PV1（患者就诊信息）：部分包含有关患者住院时的信息，例如分配的位置和推荐医生。
• PV2（患者就诊附加信息）
• ORC（医嘱命令所做的检查项目）
• OBR：关于诊断以及观察的请求信息，用于记录医嘱信息。
• OBX：用于记录观察的结果。
• QRD：查询定义段，用来定义查询的内容，查询时间、编码格式、优先等级、ID号、请求数据的最大值、请求方的信息、所要请求的内容、数据编码的部门信息。
• QRF：进一步定义查询内容。 
• DSP：重复消息段，装载LIS返回的报告结果，需要用循环的方式把数据取出。

备注

    由于HL7消息用于将各种与医疗相关的信息传递到各种不同的系统，因此有时HL7消息需要包含自定义数据。为了适应这种情况，HL7标准使系统供应商可以创建带有自定义字段的Z段，以传输此数据。

    按照惯例，所有自定义段都以字母Z开头。例如，可以创建ZPD段以包含自定义的患者人口统计信息。Z段可以放置在HL7消息中的任何位置，但是通常位于消息中的最后一段。

域

    HL7消息的每个段都包含一个或多个域（也称为fields）。默认情况下，竖线（|）字符用于将一个域与另一个域分开。

    域可以是原始数据类型（例如字符串或数字），也可以包含多个元素(Component)。如果某个域(fields)包含多个元素，则这些元素（Component）通常以^字符分隔。如果元素还包含子元素(Subcomponent)，则这些子元素通常以＆字符分隔，子元素(Subcomponent)必须 是原始数据类型（例如字符串或数字）。

"|"分隔符中可以包含其他的分隔符：

• “^” 成分分隔符，表示该位置有多个属性，例如：|101761^熊婷| 该位置是患者信息，101761是患者编号，熊婷是患者名字
• “~” 子成分分隔符，成分的下一分级
• “&” 表示该位置是数组结构，类型相同可以循环 例如：|&张三|&李四

例：

PID || 0493575 ^^^ 2 ^ ID 1 | 454721 || DOE ^ JOHN ^^^^ | DOE ^ JOHN ^^^^ | 19480203 | M || B | 254 MYSTREET AVE ^^ MYTOWN ^ OH ^ 44123 ^ USA ||（216）123-4567 ||| M | NON | 400003403〜1129086 |

    在此段中，第五个域是患者姓名，即DOE ^ JOHN ^^^^。（此域结尾处的四个 ^ 字符表示它总共有六个元素，并且只定义了前两个元素）在此组合中，DOE代表患者的名，而JOHN是患者的姓。

    为了尽可能灵活并达成共识，HL7委员会被迫将许多细分段定义为可选段，该决定的不利之处是不能确定特定的信息会出现在给定的消息中，这也造成了同一消息可能因供应商而异。

​​​​​​​HL7常用数据类型

类型编码	类型说明
ST	字符串
TX	文本数据
FT	格式化文本
NM	数字
SI	序列id
SN	结构化数据
ID	HL7表的编码值
IS	用户定义表的编码
EI	实体标识符
DT	日期
TM	时间
CE	编码要素
CX	具有校验数位的扩展符合ID
XCN	扩展符合ID号和ID名
XAD	扩展地址
XPN	扩展姓名
XTN	扩展通讯号码

​​​​​​​举例说明

下面我们在讲解一个实例：

MSH|^~\&|ADT1|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01|MSG00001-|P|2.3
EVN|A01|198808181123
PID|||PATID1234^5^M11||JONES^WILLIAM^A^III||19610615|M-||C|1200NELM STREET^^GREENSBORO^NC^27401-1020|GL|(91-9)379-1212|(919)271-3434||S||PATID12345001^2^M10|123456789|9-87654^NC
NK1|1|JONES^BARBARA^K|WIFE||||||NK
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||-||ADM|A0-
OBX|1|NM|^Body Height||1.80|m^Meter^ISO+|||||F
OBX|2|NM|^Body Weight||79|kg^Kilogram^ISO+|||||F
AL1|1||^Penicillin||Produces hives
AL1|2||^Cat dander|Respiratory distress

上面这个HL7文件共九行七类，分别是：

• 文件头（MSH）
• 事件信息（EVN）
• 患者信息（PID）
• 直系亲属信息（NK1）
• 诊疗时间（PV1）
• 查体信息（OBX）
• 过敏信息（AL1）

从上可以看出，如统一类别的信息项目超过一个的话，可以重复使用信息段。

再分析一下第一行。这一段被分隔符划分成了12个信息段：

MSH|^~\&|ADT1|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01|MSG00001-|P|2.3

MSH 表示这一段为信息头，是每个HL7信息的开始部分。

• | 表示字段分隔符
• ^~\& 这是个字符为设定的组件分隔符、重复分隔符、escape character、子组件分隔符
• ADT1 信息发出方应用程序代码
• MCM 信息发出方机构代码
• LABADT 信息接收方应用程序代码
• MCM 信息接收方机构代码
• 198808181126 为信息发出的时间，为1988年8越18日11点26分
• SECURITY 表示这个信息为保密信息
• ADT^A01 为信息内容的分类，这个信息使用了组件分隔符（^）分成了两部分，ADT表示入院、出院、转诊（Admission，Discharge，Transfer），A01表示接诊（Admit/Visit）。也就是说这个HL7信息为患者在接诊后采集的信息。
• MSG00001- 为信息标识号码
• P 为信息处理代码，P代表正式产品信息（Production）
• 2.3 表示这段信息使用的HL7版本号

其余信息也是按照这个格式进行解析，每一信息段的具体格式在HL7制定版本的标准中有详细说明。新版本会在既往版本的基础上添加信息类别或信息段。

版本 3 介绍

    V3标准是HL7小组为解决V2标准中存在的许多挑战而进行的雄心勃勃的尝试的结果。原始的V2标准（注意：没有正式发布“V1标准”，仅是概念证明）解决了当时存在的一个主要问题，即供应商的互操作性，因为专有协议用于消息交换。这使得实施成本高昂，容易出错并且难以扩展和维护。在跨部门，医院间和多学科的医疗机构中尤其如此，其中经常部署来自不同供应商的各种各样的专用系统，并且仍然需要在它们之间进行数据通信。

    V2标准为医疗行业赢得了两项重大胜利。它建议使用一种格式来对消息进行统一编码，以适应在现场看到的各种医疗情况，例如患者入院，患者出院，命令，观察和医疗费用。该标准还为称为MLLP（最小下层协议）的传输协议制定了规范。设计用于在当时流行的TCP/IP协议之上。由于这两项改进，V2标准发布后，在世界范围内迅速采用。它兑现了减少在医院和其他临床环境中所见到的维护大量数据接口的成本和难度的承诺。但是，即使采用它，裂缝也开始出现。

对V3标准的需求

    凭借其灵活的管道分隔消息结构，有时甚至可以使用基本文件编码器和解析器来实现/处理V2接口。这使得V2标准和消息接口开发非常容易进行，即使对于新手也是如此。但是，从根本上讲，V2标准有几个缺点。它被设计为主要用于查询/检索范式（在关系数据库中可见），并且在如何建模消息以及这些消息可以支持的数据类型方面存在限制。随着采用V2标准的域的数量不断增长，对更多特定于域的复杂且可重用的消息结构的需求也越来越多，这些消息结构可以在面向动态事件的消息工作流中使用（V2无法解决））。另一个缺点是由于V2消息中允许大量的可选性。这使得对信息交换的一致（“语义”）解释变得非常困难。也越来越多地认为 SNOMED CT和 LOINC）是必要的。所有这些挑战以及医疗行业的其他医疗和技术创新（以及更多法规）推动了V2标准方法通过了最初设计的处理方式。

​​​​​​​目标与目的

    为了应对这些挑战，HL7组开始构想新的HL7标准。该新标准的一些关键目标是帮助改善健康系统接口的静态和运行时特性的设计和实现。新标准将允许应用面向对象的建模过程，从而可以轻松地创建/增强/扩展消息，但同时又将其“约束”到任何医疗领域的特殊需求。而不是像V2标准那样仅关注消息的结构，该新标准将更多地关注为什么消息首先需要发送。它还将支持使用特定领域的词汇表（内部和第三方），从而更容易解释人机之间在各种系统之间交换的任何信息。带着如此崇高的远见和一些雄心勃勃的目标，成立了工作组，并在90年代中期开始着手制定新标准。同时，业界继续在可能的范围内发展V2标准（发布了从2.1到2.8.2的版本），同时确保这些修订版本保持向后兼容。

​​​​​​​关于V3发布，接收和关键组成部分

    经过近10年的制定，V3标准终于在2005年发布，引起了混合反应。该标准对许多人来说是令人恐惧的，因为它需要一套全新的技能（例如UML，XML，面向对象的设计思想和一些专用工具）来理解和使用它。许多人也感到失望，因为V3标准与V2标准不向后兼容。事实证明，V3的早期尝试和实施过于复杂且成本高昂，而这些初始实施的反馈表明，与以前使用V2标准所需的因素相比，需要考虑更多因素，从而导致更长的实施时间。

由于V3标准的规模，复杂性和工作时间长短以及它试图解决的问题，将近十年的工作不仅导致了一个标准，而且在“V3保护伞”下产生了许多不同的标准，这些标准可单独使用或组合使用以解决医疗行业中遇到的许多挑战。

其中一些标准包括：

1. 临床文件架构（CDA）
2. 合并临床文档架构（C-CDA）
3. 护理连续性文件（CCD）
4. 结构化产品标签（SPL）
5. 临床上下文对象工作组（CCOW）

    不久之后，卫生组织认可了其中一些标准（例如CDA和CCD），它们为采用许多基于V3的方法提供了“认可印章”。一些基于V3的标准已成功采用，以满足世界各地政府和医疗信息学家的一些报告要求（例如，在美国有意义的使用以及相关的法规和促销）。

​​​​​​​参考信息模型（RIM）

    RIM是V3规范的关键组成部分，对于大多数从V2进入V3的人来说，这是最令人生畏的领域。RIM本质上是一种对象建模框架，它允许设计和实现任何V3规范的所有方面，例如消息，文档，框架和相关服务。希望通过解释此框架的对象模型中的主要参与者来总结整个领域的“读者摘要版本”。它们通常被称为“RIM主干”，并通过类和接口定义进行指定，并结合使用，它们有助于定义任何医疗工作流程的静态和运行时特性。首先，有一个Act标准定义为正在完成，已经完成，可以完成，打算要完成或要求完成的事情。然后就是所谓的Entity，它可以是物理事物，一组物理事物或能够参与行为的组织。还有一个Role，定义为实体扮演给定角色所需的技能或能力。然后是一种称为Participation的东西，它可以将任何行为和角色与扮演该行为的实体之间的关联牢固地联系起来。一个ActRelationship一个行为链接到另一个，最后，一个RoleLink表示整个消息工作流程中涉及的各个角色之间的关系。通过使用这六个核心类及其关联的接口定义，可以派生出更多的专用类，以满足特定领域的实现需求。

​

    任何使用RIM的建模活动都通过使用Storyboards来辅助，这些Storyboards有助于捕获活动期间现实世界中发生的情况，并捕获系统与所涉及用户之间的交互的摘要，Trigger Events有助于确定发生消息传输的各种原因在交互过程中，最后是Application Roles，这些角色有助于定义此交互过程中涉及的任何发送或接收系统的角色。

    通过使用RIM和其他支持框架，例如HDF（HL7开发框架），可以帮助建模与HL7 V3消息（类似于V2消息）一样多变的事物，用于特定领域的信息建模框架，甚至是新的HL7标准。RIM本身使用更低的更专业的对象模型进一步完善，以实现所需的结果。例如，要派生V3消息，将使用域消息信息模型（D-MIM），其中图（这些图类似于UML，并且有比传统UML图更紧凑的表示形式）有助于突出显示各个类之间的关系。使用HL7组指定的约定。D-MIM本身会进一步完善以创建R-MIM（精简消息信息模型）对于创建序列化所需的消息内容很有用，而此过程又借助使用C-MET（公共消息元素类型）规范的实际消息表示形式的帮助，该规范有助于指定这些消息中使用的必要构建基块和数据类型。所得的消息定义称为HMD（分层消息描述符）。这些HMD并未指定消息的实际实现特征，而最终通过使用称为ITS（实施技术规范）的规范来实现这些信息。请注意，HL7组提供了大量可使用的预定义D-MIM，R-MIM和C-MET，因此，在尝试构建自己的目录之前，请始终参考这些特定于域的目录。

​​​​​​​临床文件架构（CDA）

    HL7小组在2005年创建了一个新标准，称为临床文档架构（CDA），以促进临床数据的更轻松交换和解释。CDA本身是使用我之前介绍的HL7参考信息模型（RIM）标准并使用称为HDF（HL7开发框架）的东西派生的。CDA文档（以XML格式指定）由强制性部分（供人类使用）以及一些供机器使用的可选部分组成，既可以携带结构化数据，也可以携带非结构化数据（例如图像，视频，波形图和其他二进制数据）。CDA文档与传输无关（并且不仅限于V3）。例如，可以使用其他协议（例如V2，DICOM，HTTP，电子邮件）或使用FTP交换CDA格式的数据。尽管CDA规范的发布对于医疗行业努力实现更高水平的信息交换标准化来说迈出了重要的一步，但人们认为还需要更多，特别是因为CDA对确切的格式含糊不清，仍需许多业内人士以及其他医疗机构继续推出更多特定领域的模板来填补这一空白。

​​​​​​​合并临床文档架构（C-CDA）

    为了实现标准化的医疗信息报告和数据交换，HL7组基于CDA规范创建了另一个标准或规范，称为Consolidated CDA（C-CDA）。C-CDA比CDA标准晚了大约10年，它提供实施指南以及基于最佳实践的CDA模板库，这些模板基于信息捕获和交换现场医疗信息以及来自其他医疗组织的指南和建议的最佳实践，例如IHE（医疗健康信息集成规范）和HITSP（健康信息技术标准小组）。这些C-CDA模板用于实施目前在行业中看到的许多临床文档，包括Continuity of Care Document（CCD），它们实际上是包含两者的XML文件结构化和非结构化的患者数据，可用于支持与其他EHR（Electronic Health Record）系统的健康信息交换。

​​​​​​​护理连续性文件（CCD）

    2007年，两个标准的统一，即临床文档架构（CDA）标准（来自HL7组）和ASTM的护理连续性记录（CCR）标准产生了一个新标准，称为护理连续性（CCD）。这项新标准可以在护理提供者和其他机构之间交换有关患者的全面健康信息（当前和历史）。在该标准出现之前，在护理现场进行所需的患者医疗数据的传输非常繁琐且耗时。

    CCD标准极大地简化了医疗提供的许多个阶段所需的信息传输过程。例如，当医生将患者转诊至医院，然后需要访问患者病历的相关部分时，它可以促进信息传输。当患者最终出院时，医院信息系统中捕获的信息可以传输回医生的系统，从而为患者提供更流畅，更精简的医疗服务。

    CCD文档（在该领域中以“护理文档摘要”，“情节笔记摘要”之类的一些其他名称为人所知）以XML格式编码，并允许在电子病历（EMR）之间更轻松的交换医疗数据）和电子健康记录（EHR）软件系统。CCD文件中交换的信息可能包括人口统计，过敏，程序，药物，遭遇，问题列表，诊断信息，实验室结果，免疫数据和健康风险因素等内容。

​​​​​​​结构化产品标签（SPL）

    HL7小组开发了一个新的基于文档标记的标准，以帮助缓解医疗行业中需要管理药品标签信息管理的问题，这些信息经常过时或被错误解释，从而给患者带来严重的健康后果以及声誉受损，所涉及的护理人员会担任风险和财务责任。SPL标准的目标是通过使用在创建过程中使用XML和相关技术支持的明确定义的数据结构和术语，来提高药品生产商提供的产品信息的完整性，以供监管机构、护理提供者和患者使用，药物相关信息的传输和解释。

    在这种新的信息管理方式中，药品生产商为产品创建了XML格式的核心文档。然后，可以将此文档转换为其他文档格式，例如HTML，Word，PDF等，通过使用样式表在网络、印刷纸和其他媒体上使用。当监管机构、医疗保健从业者、患者和公众提交有关产品相关标签的新信息或修订信息以供使用时，使用这种方法可确保一致和可重复的过程，从而提高准确性。使用 XML 还允许在医院系统所需的与机器相关的工作流程中更轻松地交换和解释数据。

​​​​​​​临床上下文对象工作组（CCOW）

    CCCOW 是一种架构标准，它为医疗保健应用程序之间的更容易集成和“上下文切换”提供指导，这些应用程序可能携带与患者或任何其他人在任何给定时刻感兴趣的任何其他医疗实体有关的相关临床数据的不同方面。基本上，它试图提高部署在任何医疗机构的所有技术和流程投资的信息处理的收益实现和安全性。实施这些指南后，可以提高患者数据的可访问性，加快数据检索的时间需求（通过预测接下来可能需要的内容来预加载数据），并对可以访问关键医疗保健信息的人员和内容提供更严格的控制。

    CCOW应用/使用的实际示例包括使用集成的单点登录解决方案、精心设计的图形或基于语音的界面以及现代可访问性指南、更严格的身份验证/授权/审计控制、HIPAA 合规性、警告的使用、警报和应用程序中的其他消息，以确保用户正在检查和/或更新正确的信息，并在可能的情况下预先填写任何信息，并减少手动用户输入和错误等。

​​​​​​​HL7 V3结构示例

<POLB_IN224200 ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
  <id root="2.16.840.1.113883.19.1122.7" extension="CNTRL-3456"/>
  <creationTime value="200202150930-0400"/>
  <!-- The version of the datatypes/RIM/vocabulary used is that of May 2006 -->
  <versionCode code="2006-05"/>
  <!-- interaction id= Observation Event Complete, w/o Receiver Responsibilities -->
  <interactionId root="2.16.840.1.113883.1.6" extension="POLB_IN224200"/>
  <processingCode code="P"/>
  <processingModeCode nullFlavor="OTH"/>
  <acceptAckCode code="ER"/>
  <receiver typeCode="RCV">
    <device classCode="DEV" determinerCode="INSTANCE">
      <id extension="GHH LAB" root="2.16.840.1.113883.19.1122.1"/>
      <asLocatedEntity classCode="LOCE">
        <location classCode="PLC" determinerCode="INSTANCE">
          <id root="2.16.840.1.113883.19.1122.2" extension="ELAB-3"/>
        </location>
      </asLocatedEntity>
    </device>
  </receiver>
  <sender typeCode="SND">
    <device classCode="DEV" determinerCode="INSTANCE">
      <id root="2.16.840.1.113883.19.1122.1" extension="GHH OE"/>
      <asLocatedEntity classCode="LOCE">
        <location classCode="PLC" determinerCode="INSTANCE">
          <id root="2.16.840.1.113883.19.1122.2" extension="BLDG24"/>
        </location>
      </asLocatedEntity>
    </device>
  </sender>
  <!-- Trigger Event Control Act & Domain Content --></POLB_IN224200>