医院信息集成平台 HL7协议对接

Posted 2023-05-09 CTO老王

1.介绍
HL7 缩写于Health Level Seven，是创建于1987年，用来发展独立卫生保健行业的电子交换交换标准，经过多年的发展，HL7已经有多个版本。
简单的理解其实就像XML，JSON格式一样，HL7也是一种数据格式，可以理解为一个包含很多行字符串的消息体，这一整个就是一个HL7消息内容。
HL7官网 http://www.hl7.org/，可下载对应版本文档
Hapi官网 https://hapifhir.github.io/hapi-hl7v2/

2.传输协议规范

2.1. MLLP

MLLP是目前HL7标准采用的标准接入规范，其他还有Netty等技术手段。其定义主要包括如下几个方面：

² 传输协议

MLLP协议采用标准的TCP协议进行消息发送和接收。接入时请参考相关的TCP/IP 技术文档。

² 数据头定义

说明	定义
开始（Start Block character）	0x0B
结束（End Block character）	0x1C
回车（Carriage return）	0x0D

² 转义字符集

在通过MLLP接口传输HL7消息时，下列字符集需进行转义：

转义序列	说明
\\Cxxyy\\	单字节字符集的转义序列，由两16进制数值组成，不转换
\\E\\	Escape符的转义序列 (e.g., ‘\\’)
\\F\\	Field分隔符的转义序列 (e.g., ‘|’)
\\H\\	高亮段的起始，不转换
\\Mxxyyzz\\	多字节字符集的转义序列，由两至三个16进制数值组成 (zz可选)，不转换
\\N\\	正常文字 (结束高亮) ，不转换
\\R\\	Repetition分隔符的转义序列 (e.g., ‘~’)
\\S\\	Component分隔符的转义序列 (e.g., ‘^’)
\\T\\	Subcomponent分隔符的转义序列 (e.g., ‘&’)
\\Xdd…\\	16进制数据 (dd必须是16进制符号) 成对转换为相应字符

2.2. 规范说明

² 通用段消息中常见的段进行统一说明

² 对于域（Field）红色字体表示该域是必填的，整行绿色字体表示该域扩展用法，非HL7标准含义。

2.3. 消息格式说明

² 大括号“”表示该部分可以重复

² 中括号“[]”表示该部分可选

² 黄色背景标示的是该文档中主要用到的段（Segment）

3.HL7结构介绍
例如：下面就是一个ADT^A28类型下的A28的消息：

3.1. 患者建档（ADT^A28）

*说明*：A28是用于患者基本信息建档，区别于门诊挂号、住院入院等就诊活动消息。

3.1.1. 患者建档（ADT^A28）消息规范

Field		Data Type		Data Element	Data Source	Notes
MSH					消息头信息段
MSH-3-1				Namespace ID	HIS	发送方
MSH-5-1				Namespace ID	MediII	接受方
PID					患者基本信息段
PID-2	CX		Patient ID		患者主索引信息
PID-2-1	ST		ID		患者全院唯一标识（患者主索引ID）	若为0表示，需要EMPI系统创建并返回新的主索引号。
[NK1]					患者联系人信息段
PV1					患者就诊信息段
PV1-2		IS		Patient Class	患者分类	E:急诊 I:住院 O:门诊 T:体检
PV1-52		XCN		Other Healthcare Provider	操作人信息
PV1-52(1)-1		ST		ID Number	员工号
PV1-52(1)-3		FN		GivenName	姓名

 

² 回复(ACK)：

² 说明：ADT^A28根据医院业务，若接收方为EMPI系统（主索引系统），则建档时会返回主索引ID，否则不返回主索引。

Field	Data Type	Data Element	Data Source	Notes
MSH			消息头信息段
MSH-3-1		Namespace ID	发送方	MediII
MSH-3-2		Universal ID	发送方院区ID
MSH-5-1		Namespace ID	接受方	HIS
MSH-5-2		Universal ID	接收方院区ID
MSA			回复结果信息段
MSA-1	ID	Acknowledgment Code	AA 成功 AE 失败 AR 拒绝
MSA-2	ST	Message Control ID	响应消息的控制ID
MSA-3	ST	Text Message	消息描述		若MSA-2=AE，表示错误原因描述； 若MSA-2=AA，表示PID-2-1（主索引ID）

3.1.2. 患者建档（ADT^A28）消息示例

消息说明	消息内容
患者建档	MSH|^~\\&|HIS|MediInfo|MediII|MediInfo|20120123210401||ADT^A28^ADT_A05|8890fd1647d541130c8e50e322f989|P|2.4 EVN|A28|20120123210401||||20120123210401 PID||3102209|3101409^^^JG01~1004209^^^JG02~00345685^^^JG03~330107331108002^^^JG04~014211589^^^JG05~30114174~06D958112F11^^^JG06~01411589^^^JG07~A12231645^^^JG08~33213154^^^JG09~1011409^^^JG10||XiaoHua^小华||19890101000000|2|||浙江杭州建德新安江街道&新安江街道&19号^建德市^杭州市^浙江省^311600^^H^乡镇信息^330182^街道标准编码~农夫山泉新安江饮料有限公司&新安江街道&10号^建德市^杭州市^浙江省^311600^^W^农夫山泉新安江饮料有限公司^县地区编码^街道标准编码||^^01^^^^18205710973~^^02^^^^8318764|^^^^^^18258476654||O^其他||330182192232210412^^^01|330182192221012212|||01^汉族|浙江省|||Y^退休||40^中国||||0 NK1|1|TANMOUMOU^谭某某|30^女儿|浙江杭州建德新安江街道华&新安江街道华&13号^建德市^杭州市^浙江省^311600^^H^乡镇信息^330182^街道标准编码|^^^^^^1821110973~^^^^^^8318764~^^^^^^182111113||||||||农夫山泉新安江饮料有限公司<20003711> PV1||O||||||||||||||||01||||||||||||||||||||||||||||||||||1295^^孟子
回复消息[成功]	MSH|^~\\&|UEHIS|UEHIS|MediII|MediII|20150123210520||ACK^A28^ACK|83bc94f0eb82428ea8e7482f7def130e|P|2.4 MSA|AA|8890fd1647d54362b30c8e50e322f989
EMPI系统 回复消息[成功]	MSH|^~\\&|UEHIS|UEHIS|MediII|MediII|20150123210520||ACK^A28^ACK|83bc94f0eb82428ea8e7482f7def130e|P|2.4 MSA|AA|8890fd1647d54362b30c8e50e322f989|1000100
回复消息[失败]	MSH|^~\\&|UEHIS|UEHIS|MediII|MediII|20150123210520||ACK^A28^ACK|83bc94f0eb82428ea8e7482f7def130e|P|2.4 MSA|AE|8890fd1647d54362b30c8e50e322f989|失败原因

 

4.通用段消息值域说明

 

4.1. 消息头（MSH）

 

Field	Data Type	Data Element	Notes	Data Source
MSH-1	ST	Field Separator	|
MSH-2	ST	Encoding Characters	^~\\&
MSH-3	HD	Sending Application	发送程序
MSH-3-1		Namespace ID	发送程序简称	如HIS
MSH-4	HD	Sending Facility	发送设备。目前等同MSH-3
MSH-5	HD	Receiving Application	接收程序
MSH-5-1		Namespace ID	发送程序简称	如PASC
MSH-6	HD	Receiving Facility	接收设备。目前等同MSH-5
MSH-7	TS	Date/Time of Message	消息发生的时间	20141023090101
MSH-9	CM	Message Type		如：ADT^A01^ADT_A01
MSH-9-1		Message Type	消息类型	如ADT
MSH-9-2		Trigger Event	事件	如A01
MSH-9-3		Message Structure	消息结构	如ADT_A01
MSH-10	ST	Message Control ID	用于唯一标识某条消息。在ACK消息中，必须使用到该Field	全球唯一标识符32位长度
MSH-11	PT	Processing ID
MSH-11-1		Processing ID	处理ID号	生产系统使用 ’P’
MSH-12	VID	Version ID
MSH-12-1		Version ID	版本号	2.4

4.2. 消息确认(MSA)

Field	Data Type	Data Element	Data Source	Notes
MSA-1	ID	Acknowledgment Code		AA 成功 AE 失败 AR 拒绝
MSA-2	ST	Message Control ID		响应消息的控制ID
MSA-3	ST	Text Message		错误信息
MSA-6	CE	Error Condition		错误情况 参见HL7表0357

HL7 表 0357 – 信息出错情况代码

出错情况代码	出错情况文本	描述/说明
成功	AA
0	信息被接受	成功。可选，即AA传输成功，用于必返回一状态代码的系统中
出错	AE
100	信息系列号出错	信息中的信息段的顺序不正确，或者必须的信息段丢失。
101	必须的字段丢失	某一信息段的必须字段丢失
102	数据类型出错	字段包含有错误的数据类型。比如：一数值（NM）字段包含“FOO”
103	未发现相应的表格中的取值	将一数据类型为ID或IS的字段于相应的取值表格进行比较，未发现性匹配的取值。
拒绝	AR
200	不支持的信息类型	此信息类型不被支持
201	不支持的事件代码	此事件代码不被支持
202	不被支持的处理ID号	此处理ID号不被支持
203	不被支持的版本ID号	此版本ID号不被支持
204	不认识的关键标识符	未发现患者预定等的ID号。用于对患者的处理时而不是添加患者，比如：试图传输一个不存在的患者的数据。
205	关键标识符出现重复	患者预定等的ID号已经存在。用于添加患者的操作中（如：入院，新预定等）
206	应用程序纪录锁定	在程序进行存储工作时，处理不能被执行。如：数据库被锁定。
207	应用程序内部错误	以上错误代码不能覆盖的其他内部错误

4.3. 患者基本信息信息PID

Field	Data Type	Data Element	Data Source	Notes
PID-1	SI	Set ID	顺序号	默认值1
PID-2	CX	Patient ID	患者主索引信息	如： 患者主索引ID^先诊疗后付费标志^^^绿色通道患者标志^^^
PID-2-1	ST	ID	患者全院唯一标识（患者主索引ID）
PID-2-2	ST	Check Digit	VIP-先诊疗后付费标志（0/1）
PID-2-5	ID	Identifier Type Code	绿色通道患者标志
PID-3	CX	Patient identifier List		如：患者相关ID^^^授权机构
PID-3(n)-1	ST	ID	患者相关ID	患者相关ID授权机构代码
PID-3(n)-4	HD	Assigning Authority	分配患者ID机构
PID-4	CX	Alternate Patient ID PID		门诊不填，住院必填
PID-4-1	ST	ID	婴儿标志	非婴儿0婴儿1
PID-4-5	ID	Identifier Type Code	患者信息保密级别	0/空-不需要保密； 1-保密
PID-5	XPN	Patient Name		如：ZHANGSAN^张三
PID-5-1	FN	Family Name	拼音	如:ZHANGSAN
PID-5-2	ST	Given Name	患者姓名	如：张三
PID-7	TS	Date/Time of Birth	出生日期	如：20141023090101
PID-8	IS	Administrative sex	性别	F: Female M:Male O:Others 以医院标准值域为参考
PID-11	XAD	Patient Address	地址信息	如：浙江杭州市滨江区浦沿街道110号&沿街道&110号^滨江区^杭州市^浙江省^310000^H^^^
PID-11(n)-1	SAD	Street Address	详细地址描述
PID-11(n)-1-1	ST	Street or mailing address	详细地址信息	如：浙江杭州市滨江区浦沿街道110号
PID-11(n)-1-2	ST	Street name	街道信息（村/街道）	如：滨江区浦沿街道
PID-11(n)-1-3	ST	Dwelling number	门牌号码	如：110号
PID-11(n)-2	ST	Other Designation	县地区（县）	如：滨江区 或 富春县
PID-11(n)-3	ST	City	城市（市）	如：杭州市
PID-11(n)-4	ST	State Or Province	省，自治区，直辖市	如：浙江省
PID-11(n)-5	ST	Zip Or PostalCode	邮编	如：310000
PID-11(n)-7	ID	Address type	地址类型	详见字典代码说明 如：H
PID-11(n)-8	ST	Other geographic designation	乡镇信息	依需录入 地址类型是工作单位时，填“工作单位名称信息”
PID-11(n)-9	IS	County/parish code	县地区编码	县地区标准编码
PID-11(n)-10	IS	Census tract	街道标准编码（保留）	街道标准编码
PID-13	XTN	Phone Number Home
PID-13(n)-3	ID	Telecommunication Equipment Type	电话类型代码	详见字典说明
PID-13(n)-7	NM	PhoneNumber	电话号码	手机号码，如类电话型代码为01时，表示联系电话号码。
PID-14	XTN	Phone Number Business
PID-14-7	NM	PhoneNumber	工作电话	手机号码
PID-16	CE	Marital Status	婚姻状况	如： M^已婚或S^未婚或O^其他
PID-16-1	ST	Identifier	婚姻状况代码
PID-16-2	ST	Text	婚姻状况名称
PID-18	CX	Patient Account Number	证件信息
PID-18-1	ST	ID	证件号码
PID-18-4	HD	Assigning Authority	证件类型	详见字典说明
PID-19	ST	SSN Number	身份证号
PID-21	CX	Mother\'s Identifier		门诊不填，住院必填
PID-21-1	ST	ID	母亲住院ID
PID-22	CE	Ethnic Group	民族	如：12^汉族
PID-22-1	ST	Identifier	民族ID
PID-22-2	ST	Text	民族名称
PID-23	ST	Birth Place	出生地	如：浙江省
PID-26	CE	Citizenship	职业	如：0-71^医生
PID-26-1	ST	Identifier	职业代码
PID-26-2	ST	Text	职业名称
PID-28	CE	Nationality	国籍	如：1010^中国
PID-28-1	ST	Identifier	国籍ID
PID-28-2	ST	Text	国籍名称
PID-30	ID	Patient Death Indicator	死胎标志	默认是0/空，1-死胎
PID-32	IS	Identity Reliability Code	黑名单病人	默认是0/空

5.HL7 消息结构
HL7 标准包含256个事件、116个消息类型、139个段、55种数据类型、408个数据字典，涉及79种编码系统。
在 HL7 中，有四个最基本的术语概念：

• 触发事件（trigger events）：当现实世界中发生的事件产生了系统间数据流动的需求，则称其为触发事件。也可以理解为一个数据请求
• 消息（message）：它是系统间传输数据的最小单位，由一组有规定次序的段组成。每个消息都是用一个消息类型来表示其用途。
• 段（segment）：它是数据字段的一个逻辑组合。每个段都用一个唯一的三字符代码所标志，这个代码称作段标志。
• 字段（field）：它是一个字符串，是段的最小组成单位。

在 HL7 中，消息（Message）是数据在系统之间交换的基本单元，每条消息都有各自的消息类型，消息类型用于定义消息目的，包含了触发事件。一个消息由多个段（Segment）组成，每一个段都有相应的名称，用于界定其内容或者功能。
一个段又由多个字段（Field）组成。一个消息中的第一个段总是消息头段（Message head segment），它指明了发送和接收的程序名、消息类型、以及一个唯 一的消息ID号码等，接下去段的构成由消息的类型决定。
一个字段又有可能由多个组件（Component）组成。有些消息可进一步由事件码（event code）细分。

• 每个消息会包含多个段，如上述代码，表示一个消息，每个段之间通过分割回车
• 每个段又会包含多个字段，消息头段定义了段的类型，比如 MSH 表示这个段是消息头，段中又会包含多个字段
• 每个字段使用 | 分隔，如果对应的字段没有数据也不能省略 | ，这是因为每个字段在段中都有一个序号（SEQ），每个段有多少个字段、各个字段的序号和含义等都是在 HL7 协议中规定好的！
• 每个字段会包含多个组件，字段中不同的组件使用 ^ 分隔，比如 2302^BloodType
• 每个组件又可以包含多个子组件，子组件之间用 & 分隔，比如 ICU&Bed5&3232241659&0&0 （包含5个子组件）

6.HL7数据类型

7.HL7 message type消息类型

1. ADT admit disCharge transfer 入院、出院、转院
2. ACK acknowledgement message 应答消息
3. BAR biling account record 账单账户记录
4. DFT detailed financial transactions 详细的金融交易
5. MDM Medical document management 医疗文件管理
6. ORM order entry 订单录入
7. ORU Observation result (unsolicited) 观察结果 非请求观察
8. RDS pharmacy/treatment dispense 药房/治疗 配药
9. RDE pharmacy/treatment encoded order 药房/治疗 编码顺序
10. SIU schedlued information unsolicited 调度信息 非请求观察

 

 

 

技术微信群：
加微信：wonter 发送：技术Q
医疗微信群：
加微信：wonter 发送：医疗Q
更多文章关注公众号：

HL7的基本信息

参考技术A

HL7 卫生信息交换标准（Health Level 7）
标准化的卫生信息传输协议，是医疗领域不同应用之间电子传输的协议。HL7汇集了不同厂商用来设计应用软件之间接口的标准格式，它将允许各个医疗机构在异构系统之间，进行数据交互。
HL7的主要应用领域是HIS/RIS，主要是规范HIS/RIS系统及其设备之间的通信，它涉及到病房和病人信息管理、化验系统、药房系统、放射系统、收费系统等各个方面。HL7的宗旨是开发和研制医院数据信息传输协议和标准，规范临床医学和管理信息格式，降低医院信息系统互连的成本，提高医院信息系统之间数据信息共享的程度。
Health Level 7中的“Level 7”是指OSI的七层模型中的最高一层，第七层。但这并不是说它遵循OSI第七层的定义数据元素，它只是用来构成它自己的抽象数据类型和编码规则。它也没有规定规范说明如何支持OSI第一到第六层的数据。
HL7并没有提供一个完全的“即插即用”解决方案，因为在医疗机构的传输环境中有两个重要的影响因素：
⑴医疗机构的传输环境中缺乏处理的一致性；
⑵产生的结果需要在用户和厂商间进行协商。
因此，它提供的是一个可在较大范围内选择数据和处理流程的灵活系统，并尽可能的包括所有已知的程序（触发器Trigger）和数据（段Segment和域Field）要求。
在HL7通信协议中，消息（Message）是数据交换的基本单位。HL7的消息是自动生成的，它将HL7标准文档自动转化为一个HL7规则数据库和部分程序数据结构代码。实现一个通信标准的具体工作是生成数据结构，以及实现一个构造器(Builder）和一个解析器（Parser）。数据结构表现了标准中各个数据对象的相互关系。构造器将数据结构中的数据转化成能在电子数据交换媒介中传输的数据串。而解析器能够将数据串解析回原来的数据结构。HL7标准是一个文本结构的文档。首先，利用一些文字处理工具将文档中的各个数据定义抽取成数据结构，再将结构的形式存入预先定义的HL7规则数据库。然后，开发一种代码生成器，它根据规则数据库的内容，自动生成某一种计算机语言代码。最后，可将这些代码加入实际应用的程序框架。
图1说明的是用HL7标准实现各种医疗设备互连，其中的ADT指的是入院、出院和转移，通常简称为ADT(Ad-mission、Discharge、Transfer）。ADT主要是关于病人个人信息的生成和更新，以及病人来访等信息数据的交换。由于任何加入医疗系统网络的设备都需要病人的个人信息，ADT是HL7标准中应用最广泛的一个方面。通常，进入一个ADT系统的数据总是要传递给医院的各种系统，2013年甚至要传递给保险公司。 HL7（Health Level 7）作为一个机构，成立于1987年，从1994年起是美国国家标准局（ANSI）授权的标准开发组织（SDO）之一，是从事医疗服务信息传输协议及标准研究和开发的非盈利组织。
HL7现有会员2200多，其中团体会员超过1500个，代表世界上主要国家和包括医疗方面90%的信息系统供应商。参与HL7技术合作与推广的国家和地区除美国外，还有澳大利亚、加拿大、中国、芬兰、德国、日本、荷兰、新西兰、英国、印度、阿根廷、南非、瑞典、韩国、台湾等。
HL7委员会的目的是开发和研制医院数据信息传输协议及标准，优化临床及其管理数据信息程序。
HL7委员会（截至2002年12月为止）设立了21个技术委员会
技术指导、构建回溯体系、 临床上下文对象工作组（CCOW）， 临床诊断支持，控制、查询，教育，财务管理， 国际会员接纳， 营销，病历记录、信息管理，建模和方法学，医嘱、观察资料，病人管理，病人护理， 人员管理，处理步骤改善， 出版， 临床研究信息管理，工作安排和后勤，结构化文档，术语。
15个特殊兴趣委员会（Special Interest Groups，SIGs）：
阿登语法，附件，临床指导方针， 临床基因， 社会基本健康服务，兼容性，电子病历（EMR)，政府计划，图像集成，Java,实验室自动化和测试，药物治疗，安全和责任，模板，XML。
HL7的委员会并不是固定不变的，特别是SIGs是可以由会员自由申请成立的。 HL7作为标准它是开放系统互联（OSI）七层协议第七层（应用层）的协议。
是作为规范各医疗机构之间，医疗机构与病人、医疗事业行政单位、保险单位以及其它单位之间各种不同信息系统之间进行医疗数据传递的标准。
作为信息交换标准，HL7自1987年发布V1.0版后相继发布了v2.0 v2.1 v2.2 v2.3 v2.3.1 ，2000年发布了v2.4版，现已用XML开发了v3.0版，但HL7 v2.4版本仍是ANSI正式发布的版本。
HL7目标
⑴ HL7标准应该支持各种技术环境下的数据交换，同时也应支持各种编程语言和操作系统，以及支持各种通讯环境。
⑵ 同时支持单数据流和多数据流两种通讯方式。
⑶ 最大限度的兼容性，预留了供不同使用者 使用的特殊的表、编码定义、和消息段（如：HL7的Z-segments）。
⑷ 标准必须具有可扩展性，以支持新的要求，这包括协议本身的扩展及与现有系统和新 系统的兼容。
⑸ 标准应该是在充分参考现有的产品通讯协议基础上，被广泛接受的工业标准。
⑹ HL7的长期目标就是制定一种用于医疗机构电子数据交换的标准或协议。 第七层是国际标准组织（ISO）的开放式系统互联（OSI）模型的最高层。这不是说HL7与ISO定义的OSI的第七层原理完全一致。而且，HL7也没有指定一套ISO批准的规范，以便占领HL7抽象消息规范作用的1-6层。但是HL7符合位于OSI模型的第7层内的这种从应用端到应用端接口的概念定义。
在OSI概念模型中，通讯软件和硬件的功能被分在第7层。HL7标准主要关注在第7层发生的或是应用层发生的问题。这些就是在应用程序之间被交换的数据、交换时间以及应用程序间通讯的特殊应用程序错误的定义。然而，与OSI模型协议低层有关的协议有时也被提到帮助系统理解标准的上下文，这是必须的。他们有时也被提到以帮助实现者建立基于HL7工作的系统。
HL7工作组是由志愿者组成的，他们是在个人时间或雇主倡导的时间内做的。HL7工作组的成员已经，并且愿意继续为那些有志于建设、发展、精炼医疗系统网络技术的第7层接口标准的人开放。
这个标准可以在不同的系统中进行接口的编址，这些系统可以发送或接收一些信息，包括：就诊者入院/登记，出院或转院（ADT）数 据，查询，就诊者的资源和计划安排表，医嘱，诊断结果临床观察，费用，主文件的更新信息，医学记录，安排，就诊者的治疗安排以及就诊者的护理。这不是试图 假设一个在应用程序中与数据的布置有关的特殊体系结构，而是被设计用来支持一个中心就诊者护理系统，以及支持数据在部门系统中的分布式环境。
如果我们认为多数的医护信息系统应用程序和传送医疗的各种环境一样，那么很明显这会有很多接口可以受益于这种标准化的定义。参与了编写标准过程的成员对接口的选择有很高的优先权。HL7的目的就是为这些接口准备一个完整的标准，其建立在可以有力的支持很多其它接口的一般构架的基础上。这个标准已经投入使用而且做为扩展现存接口定义的基础，并增加了一些其它定义。
这篇文档是按以下方式编排的。本章的余下部分包括：发展标准的基本理由，标准的发展目标，工作组从属的范围和操作入门的方法。希望可以帮助读者理解决定发展此标准的依据。以后的章节分别说明：
a）所有接口（包括通用查询接口）的全部结构
b）就诊者入院，出院，转院和登记
c）医嘱输入
d）就诊者记帐（帐目）系统
e) 临床观察数据，如化验结果，做为能识别的数据元素被发送（而不是显示定向文本）
f）为同步的公共参考文件（主文件）设立的通用接口
g）医学信息管理
h）就诊者和资源的安排计划
i）有关两个机构间的转诊病人的转诊消息
j) 支持面向问题通讯的就诊者护理消息，在计算机信息系统中为临床途径的实施提供功能 完整性－对基本的医嘱，财务，检验信息都有了规范的描述，而且做得非常详细，如病人的饮食忌讳，宗教信仰等按照相应的ISO标准描述。
可实现性－选择OSI第七层做标准，保证其可实现性。
兼容和扩展性－包括对中药计量单位的支持。
安全性－由于HL7的开发和兼容性导致安全性很难保障，尽管支持数字签名，但主要还是要靠网络底层协议保证。 一、采用点对点通讯方法以实现不同系统的对接；
二、采用HL7服务器的方法实现，HL7 Server实际上是应用服务器，形成居于HL7接口的中心数据库，这样可以减少接口数量，提高系统可靠性。