[这个贴子最后由jacky在 2002/09/10 09:36am 编辑]
这是我们在一年多以前翻的一部分,基于v2.31,是第二章的开头,参照斑竹的意见修改了一些术语,但大体没有改动,有什么错误和遗漏在所难免，先献出来给大家看看,见笑啦。
有什么意见和批评或者要求，都可提出来，呵呵…………
2 •""""
控制/查询
2．1 序言
本标准的控制/查询章节定义了应用于所有消息（message）的一般规则。随后的章节部分则定义了在某一应用中用于交换的具体功能的消息。在这章引入的消息定义的具体方面是：
a） 用于功能章节中来描述消息的格式。这包括它们的目的、内容，以及它们之 间的相互关系。这种格式被称为抽象消息定义（abstract message definition），因为它是一个纯粹的第七层（level 7）（应用层）定义。
b） HL7编码规则，用于把一个抽象消息转换为一个包含了实际消息的字符串。
c） 需要使用HL7规范来交换消息的程序设计方法。
d） 与低层协议的预期关系。
e） 为所有消息的组成部分的某一消息片段。
f） 专一的消息，确认消息，这些在多个应用中使用但不会变化的消息。
2．2 概念探讨
2．2．1 触发事件
本标准的制订根据以下假定，一个真实世界中的医疗看护事件建立了对数据的需要，而在系统之间流动。这种真实世界的事件被称为触发事件（Trigger events）。例如，一个触发事件，一个病人入院，可能引起需要——将关于这个病人的数据传给许多需要这些数据的其它系统。再如，一个触发事件，一个病人对库存物资中的项目使用，可能会导致需要——关于病人和使用的项目的信息将被发给从病人看护系统到病人结账系统以及物资管理系统。当信息的传送是由正在处理触发事件的应用程序系统初始化，这种处理则被定义为主动更新（unsolicited update）。
注意:在创建主动更新的时候，没有任何假定制定关于应用程序系统的设计或者结构。HL7的领域仅限于在应用程序系统和触发它们的事件之间的消息规范说明。
HL7允许触发事件使用时，在数据间隔和相互关系上存在几个不同的水平。例如，大多数的ADT触发事件仅与单个对象有关（如一个入院事件，它创建了一个消息，仅包含了单个病人和/或账号）。其它的ADT触发事件则包含了不止一个对象之间的关系（例如，合并事件，指定病人或账号合并）。还有某些ADT触发事件，属于一个目标集合——它们之间可能没有明显的关系（例如，一个面向记录的基于位置的查询，它的回复包含了仅临时与局部位置相关的病人集合）。
2．2．2 确认：原始模式（Acknowledgements: original mode）
当主动更新从一个系统发送到另一个系统，确认模式规定它必须在应用层水平上收到确认。这是因为系统不能确切的知道其下的通信系统能否保证信息的传递。它同样也需要了解接收的应用程序在逻辑应用层上的数据处理是否成功。
确认将包含初始化交换的系统所感兴趣的数据。例如，当一个病人看护系统处理一个触发事件——为病人安排了实验室检查，它将送一个主动更新给实验室应用程序来标识病人，安排检验，以及关于安排的多种其它信息。而当这个从属程序执行成功后，它将确认这个安排。对于某些病人看护系统和它相应的从属部门系统来说，确认同时将包括从属部门系统分配的从属识别号。（HL7并不要求医嘱录入（Order Entry）和结果报告（Results Reporting）应用程序使用这种方法，但支持它们这么做。）
HL7标准对数据的所有权不作任何设定。它同样对于数据的接收者的随后动作没有任何要求，而对于接收应用系统的设计或结构也没作任何设定。HL7的领域仅限于在应用程序系统和触发它们的事件中的消息的规范说明。HL7不明确支持，但能在支持存储转发和数据广播工具的系统中使用。（见HL7执行手册）
对于一个系统在确认之前递交一个消息中的数据到它的数据库中，HL7标准没有作任何功能监控的要求。所需要的仅是，接收系统接受数据的责任权，并提供它提供给来自任何来源的数据的同样的整合性。用先前的例子，从属系统将在安置这个安排到一个队列，并在未来的某个时刻完整执行这个安排，同时放入它的数据库后，确认这个安排。在此唯一的设定就是要象数据库一样，在同样的整合性水平上维护这个队列。
2．2．3 确认：增强模式（Acknowledgements: enhanced mode）
HL7确认范例已经扩展到能区别接收确认（accept acknowledgment）和应用程序确认（application acknowledgment），同样也能区分它们所要求的条件。用一个肯定的接收确认，接收系统表明它已将消息可靠的存储，通过这种方法可以免除发送系统重新发送这个消息。在接收系统完成对消息的处理后，它将发送一个应用程序确认，以返回结果状态给发送系统。
2．2．4 查询
当一个系统向另一个系统请求查询时，不同的数据交换将会发生。例如，在一个心导管检查应用程序，如果一个病人并没有在心导管检查应用程序的数据库中注册，那么将引发一个触发事件——检查预定。这个应用程序将发送一个包含病人ID号的请求消息给ADT系统，并会收到一个回复，其中包含许可这个安排的处理的必要数据。这样的请求事务便是一个查询，并与前面讨论的主动更新区分开来。在系统间流动的信息也包含在回复中。而回复本身不再需要再次的确认。
在所有的案例中，HL7标准都包括在两个应用程序间的消息的简单交换：主动更新和它的确认或者查询与它的回复。而其下的运作模式是一种客户/服务器模式。与另一个应用程序相连接的应用程序使用事件代码来识别事务。而另一个应用程序回复的消息包含数据或者一个错误指示。初始的应用程序将从另一个应用程序或低层软件收到一个拒绝信号以表明它的消息没有正确的收到。
HL7的查询可通过以下几种方法中的一种来阐述：
1、 HL7查询过滤程序。它通过QRD和QRF片段来定义。它也被以前版本的HL7所支持，并被认为是原始模式的查询。
2、 内嵌查询语言（Embedded Query Language）选择指令。它允许查询系统，通过使用选定的查询语言（如：SQL），将请求格式化为一种自由格式的查询指令。
3、 虚拟表请求。这种方法在功能上类似于内嵌查询语言消息，但用分割符更加严格的定义格式。
4、 存储过程请求。它调用回复系统中用于满足特定查询（如：预先定义查询，SQL存储过程）的程序代码单元。
被HL7支持的预先查询仅限于数目和精确定义，它们都有相应的存储过程名和与之相关的参数列表。对于支持的查询列表参见后面的功能章节。
5、事件重放查询。它是为事件消息所格式化的数据的请求。
HL7内嵌了SQL选择指令，作为编码查询选择标准的一种替代方法。这种选择性的提供方便了程序执行人员，但决不意味着服务器系统必须支持标准的SQL或基于关系数据库技术。
这些查询都将在本规范的适当章节定义。
2．3 通信环境
HL7标准定义消息由于它们在应用程序实体间进行交换而程序已惯于交换它们。象这样，它概念性运行在开放系统互连（OSI）的ISO七层模型上。它主要涉及数据内容和消息的相互关系以及传达某一个应用水平的错误状态。
既然OSI协议没有广泛的实现，HL7工作组对于已提供的标准感兴趣，认为将在过渡时期有用。它同样认识到不但在现在，而在未来也将持续地关注那些运行在通信环境中并能提供高级功能的系统之间的交换医疗数据，但它们使用了ISO OSI以外的协议。HL7将包括这些通信环境体系，但并不会仅限如此：
a） 一些特定的环境，它们不提供甚至基本的传输可靠性。这些环境包括点对点的RS-232连接，MODEM，甚至LAN，如果它们连接到主机是通过RS-232通信链接。除非OSI高层协议开始真正的普遍，否则很多的医疗看护接口将建立在这样的链接上。在这样的环境中，HL7低层协议（HL7 Lower Level Protocols）（LLP）将在系统间使用，以增强通信环境的能力。HL7低层协议在HL7执行手册中定义，但它不是标准的正式部分。
b） 一些支持稳定传输，但不能满足高级要求的环境。这包括TCP/IP，DECNET，和SNA。
c） ISO和专有网络，它们可以支持描述和其它高级服务。IBM的SNA LU6.2和SUN Microsystems的NFS就是这类完全的专有网络。
d） 两个或更多的应用程序运行在没有紧密整合的同样的物理和/或逻辑机器上。在这种环境中，通信联系能力可通过内处理通信服务（如：UNIX系统中的Pipes）提供。
HL7标准假定通信环境将提供以下的能力：
a） 无错传输。应用程序假定它们能正确的收到所有传输的字节，并按它们发送时的正确次序排列。这意味着错误检查将在低层进行。但在没有收到一个确认消息的时候，发送应用程序将不会假定消息已经收到。
b） 字符转化。如果两台机器在使用不同的字符集的时候交换数据，那么通信环境将会把数据从一套字符集转化为另一套字符集。
c） 消息长度。HL7对于HL7消息的最大尺寸没有设置任何限制。标准假定通信环境在需要的时候能够传输任何长度的消息。实际上，站点可能会设定某个消息尺寸的上限。对于超过上限的消息，将使用消息延续协议，这将在本章的后面阐述。
注意: 正如HL7在发送和接收HL7消息的应用程序系统的设计或结构没有任何设定，它在除了以上列举的外在通信环境方面没有任何假定。特别，除了以上的假定外，通信环境，包括它的结构，设计和执行都在HL7的领域之外。
2．4 HL7消息
这一部分定义了消息的组成部分，并提供了用于随后章节的方法学，用来定义抽象消息。
2．4．1 消息定义
消息（message）是在系统间数据传送的基本单位。它包含一组按定义的序列排列的片段。每个消息都有一个消息类型来说明它的目的。例如ADT消息类型用于从一个系统向另一个系统传输部分病人的ADT数据。包含在每个消息内的一个三字符的代码标识它的类型。这些代码都列在附录A的消息类型列表中。
启动了消息的交换的现实世界的事件被称为触发事件。（触发事件的更具体描述见段2.2.1。）附录A收录了所有定义了的触发事件的代码。这些代码表示了事件的意义，如病人入院或安排事件发生。在消息类型和触发事件代码之间是一种一对多的关系。一个触发事件代码不能对应多于一个消息类型，而一个消息类型可以对应多个触发事件。
所有以字母“Z”开头的消息类型和触发事件都被保留作为本地定义消息。没有这样的代码在HL7标准中定义。
2．4．2 片段
一个片段（segment）是数据域的逻辑组。消息的片段可以是必须或是可选。它们既可以在一个消息中只出现一次，也可以被允许重复。每个片段都被赋予了一个名称。例如，ADT消息可能包含以下的片段：消息头（MSH），事件类型（EVN），病人ID（PID），和病人就诊（PV1）。
所有以字母“Z”开头的片段ID代码都被保留作为本地定义消息。没有这样的代码在HL7标准中定义。
2．4．3 字段
一个字段（field）就是一个字符串。HL7并不管应用程序所在的系统如何存储数据。字段在传输的时候，是作为字符串发送的。除了有记录的外，HL7的字段将被认为是空值。发送空值，这可以通过发送两个双引号（“”），是不同于忽略一个可选的字段的。这个区别将出现在一个消息的内容将被用于更新一个数据库的记录而不是创建一个新的时候。如果没有值被发送（比如，它被忽略了），那么原先的值将被不变的保留下来。但如果发送一个空值，则原先的值将被空值代替。（更多的细节，见消息构建规则，段2.4.7-2d）
HL7标准多个章节都包含有片段定义表。这些表列出并描述了片段中的数据域以及它们的用法特征。附录A提供了一个所有HL7字段的综合数据字典。对于定义一个片段，以下的信息将用于说明每个字段。
2．4．3．1 位置
字段在片段中的序数位置。这个数目用来查阅在片段定义表后的文本注解中的数据字段。
2．4．3．2 名称
字段的通用唯一描述性名称。
2．4．3．2 ID号
在标准中，用一个小整数来唯一标识一个字段。这个ID号在HL7消息编码规则中并没有什么意义，但被包括在内，作为一种对那些应用HL7标准但使用其它消息编码规则的系统的便利。
2．4．3．4 最大长度
一个字段可占据的字符的最大数目。最大长度在抽象消息或HL7编码规则中都不是一个重要概念。虽然字段的长度一般是标准的。然而在实际操作中，常需要在具体位置上进行协商。它将被计算包括部件以及从属部件分隔符，这些都将在后面定义。因为最大长度仅仅是单个事件的长度，所以重复分割符在计算最大长度时将不包括在内。（见2.4.3.6）
2．4．3．5 可选性
表明字段在片段中是必须的，还是可选的，或是有条件的。这里的符号表示为：
R → 必须
O → 可选
C → 有条件的，在触发事件或某些其它域
注意: 在V2.3版和更高版本，域的可选性应该明确的记录在片段的域定义部分，接在每个片段定义表后；如果片段中域的可选性变化依赖于触发事件，那么可选性也应该被明确的记录。
注意: 对于在HL7数据类型中定义的包含多个部件或从属部件的域，给定的部件或从属部件的可选性必须在正式的片段定义表后说明详细的域定义。（见2.4.4，2.4.5，和2.4.7。）
2．4．3．6 重复
表明字段是否重复。这里的符号表示为：
N → 不重复
Y → 字段将重复不确定的次数或位置决定的次数。
（整数） → 字段将重复指定的次数
每个事件可以包含字段最大长度所规定的字符数目。（见2.4.3.4）
2．4．3．7 表
HL7定义了一张字段的值表。每个表的数目列条目都表示表名等同于元素名。
HL7在定义表的有效值时的方法是多种多样的。某些字段，如病人位置，将会有各种不同的值。这样的表就是用户指定或者位置定义。即使这些表没有在标准中定义，它们也将被赋予一个HL7表的号码以便于执行。ID数据类型就常用于这些表的编码。注意某些这种表（如位置）也许要参见公用主文件。
另外，象事件类型（HL7表0003），也是HL7标准的一部分，因为它们影响着包含它们的消息的解释。它们的值仅限于HL7标准建立的那些。ID这种数据类型常用来编码HL7表的值。在HL7表中它被强烈推荐使用。这些值都列在了附录A中。这些HL7表也以文本形式出现在标准框格式中（如，HL7表0003 –事件类型，见段3.3.1.1）。附加的表将在位置专一的基础上被包括。
然而还有一些表的值的编码是参见了其它的标准文档。例如，实验室操作的编码就是按ASTM 1238-88标准来定义。CE这种数据类型就是用来编码这些表的值。
最后，有某些用户自定义的表，包含一些值，它们在机构间已标准化但没有任何可应用的正式标准存在。对于这些，一套推荐值将列在附录A中。这些推荐值也以文本形式出现在标准的无框格式中（如，HL7表0062-事件原因代码，见段3.3.1.4）。这些值将期望被使用以应用在一些机构和服务以作为一种必要的基础扩展。HL7相应的功能委员会从应用标准的机构征求对于这些附加值的建议。
多个HL7数据类型（CE, CF, CK, CM, CN, CP, CQ, CX, ED, ID, RP, XAD, XCN, XON, XPN,和XTN）将用于传达表的值，或用一个部件来包含这些表的值。
2．4．3．8 数据类型
字段内容的限定。HL7定义了很多的数据类型。这些将在2.4.5-数据类型中解释。
2．4．4 消息分割符
在构建消息时，某些特殊的字符将被使用。它们是片段终止符，字段分割符，组分分割符，子组分分割符，重复分割符，和换码符。片段终止符通常是一个回车（在ASCII中，十六进制的0D）。其它的分割符则在MSH片段中定义，字段分割符在第四个字符位置，剩下的分割符在片段ID之后的第一个域，被称为编码字符的字段中定义。在MSH中定义的分割符的值将作为分割符值在整个消息中使用。在没有其它考虑的时候，HL7推荐使用建议值，可在图表2-1分割符值中找到。
在任何给定的位置，可能的分割符子集都将通过应用程序之间的协商来限制。这意味着接收应用程序使用一致的分割符来解析消息，当它们在消息头片段（MSH）出现的时候。
图表 2-1. 分割符值
分割符 建议值 编码字符位置 用法
片段终止符回车 <cr>十六进制 0D - 结束一个片段记录，这个值不能为执行者所改变。
字段分割符 | - 在片段中分割两个毗连的字段。它也可以把每个片段中的片段ID和第一个字段分割开。
组分分割符 ^ 1 分割字段中允许的相连组分。
子组分分割符 & 4 分割字段中允许的相连的子组分。如果没有从 属部件，则这个字符将被忽略。
重复分割符 ~ 2 分割允许的多个字段的重复。
换码符 \\ 3 换码符用于TX和FT字段。如果在一个消息中没有使用换码符，则这个字符将被忽略。然而如果有子组分在消息中使用，则它必须出现。
|
发表于 2002-9-10 09:30:44
发表于 2002-9-12 11:45:43