CN1802673A - 用于将专家系统接口到临床信息系统的系统、方法以及计算机程序 - Google Patents

Abstract

用于将专家系统接口到临床信息系统的方法和计算机程序。本发明的实施例提供了允许医生使用专家系统提供的功能而无需特别地保存分立的用户数据的紧密集成的系统，它们提供了在专家系统和一个或多个临床信息系统之间的通讯方法。该通讯方法允许在专家系统和临床系统之间的信息和操作的流动，并且允许在两个系统中保存审核日志。

Description

用于将专家系统接口到临床 信息系统的系统、方法以及计算机程序

相关申请的交叉引用

本申请要求了于2003年2月7日提交的编号为60/445,889的美国临时申请的权利。

技术领域

本发明主要涉及促进临床系统和分立的专家系统之间的通讯，更具体地说，本发明涉及在临床系统和分立的专家系统之间提供接口的系统、方法和计算机程序。

背景技术

临床信息系统和电子医疗记录系统在患者护理领域已经应用了多年。这些系统包含了与系统的用户和管理员功能相关的数据库或知识库数据，同时也包含了临床效果和措施的历史(临床数据功能)。它们被用作与治疗相关的财务事项的医学记录，和用作对患者正在进行的临床治疗的工具。然而，原先，这些系统是按照在线事物处理系统(OLTP，Online Transaction Processing)设立的。结果，它们不包含大量的医学或科学知识，并且没有设计用于提供专家建议(即，执行专家功能)。

某些临床信息系统已经建立了嵌入其中的报警机制(alertingmechanisms)和基于规则(rule-based)的事件监视器，以便在输入系统的临床数据基础上提供专家建议。由于临床数据功能和专家功能被包含在一个共同的系统中，因此这些系统不需要在用于执行临床数据功能和专家功能的不同模块之间的特定的系统接口。对事务进行快速处理的需求已经限制了该模型能力，并且又限制了所能产生专家忠告的类型。另外，嵌入在已开发或购买的公共系统中的特定专家系统提供的特点限制了用户，从而失去了在这个临床系统本身中结合不同的专家系统的机会。

已经开发出了在线分析处理系统(Online Analytic ProcessingSystems)以便提供最佳解析的专家功能。然而，它们与临床系统分立，并且当它们具有来自临床系统的入站(inbound)数据连接以扩充它们的数据库时，既没有信息流返回到临床系统，也没有在两系统之间允许用户在两种类型的功能间无缝移动的互动机制。这些系统一般用于行政或病例管理的目的，而非直接用于临床治疗。所嵌入的知识和提出的建议不能够直接实现。

专家系统是作为单机系统开发的，并且已经显示出能够提供具有改善医疗潜力的有价值的信息。然而，它们分立的特性也限制了它们的实用性。需要用户输入分立应用的系统不经常被使用，而需要用户输入已经驻留在临床系统中的临床信息给用户带来了额外的负担。此外，由于重复输入的数据可能是不完整的或错误的，因此它们面临着数据保真度(或准确程度)损失的危险。因此，这些单机系统的分立特性已经限制了它们的实用性和它们在临床实践中的采纳。

单机专家系统并未集成在临床系统中的原因有很多。第一，全面的电子医疗记录(Electronic Medical Record，EMR)系统只在很少的保健系统中。拥有这样的EMR系统的那些少数站点经常只是闭门造车，并且已经开发出在其自身的EMR系统中的决策支持和专家系统。

对于大量集中的临床地区，已经开发出了各种分立的专家系统，然而没有适当的电子医疗记录系统，集成是不可能的。此外，系统集成还存在诸多技术障碍。首先，许多电子医疗记录系统是用带有专有权(proprietary)的操作系统和数据库开发出的，这些系统很难(如果不是不可能的话)与不相关的系统集成。其次，缺少数据标准和知识的表达方式，这使得传递那些能够被正确地解释和操作的数据变得很困难。即使带有定义了各系统间消息结构的接口标准，也会由于缺少了公共词汇表，而使这些消息的内容失去作用。

还没有开发出将单机专家系统与临床电子医疗记录系统集成的商用系统。电子医疗记录系统供应商们的商业模型为保健系统提供全面的解决方案，它们以在各自专家系统中功能性的长处来区分彼此。这些系统集成在它们的产品中，并且不能被开发用于与另一个供应商的电子医疗记录系统一起工作。这已经阻碍了为广泛集成而设计的那些独立专家系统的开发。小规模(niche)专家系统的供应商专注于特定的功能领域，例如病例管理、治疗恰当性的保险认证，和数据分析。直接治疗的临床医生一般不使用这些系统，因此与电子医疗系统的集成也一直没有继续。

最后，传统的学识和医疗信息学论著的教导一直不鼓励分立的专家系统。由于操作、安全、词汇表的一致性、以及开发控制等问题的原因，已经被广泛规定的信条是：只有在它们被直接建立在临床系统中的时候，这些专家系统才能有效的发挥作用。这个教导的结果鼓励了建立在临床系统中的专家系统的开发，而一直忽视了为了允许独立专家系统以集成的方式运行而开发的系统或方法

发明内容

本发明通常涉及将单机专家系统和一个或多个独立的临床系统集成的系统、方法和计算机程序。这种方法允许单机专家系统独立地开发和执行，并且通过一系列定义的接口与一个或多个临床系统相集成。至少一个接口直接指向专家系统内部，并且一个接口由专家系统向外指向临床系统。这种方法无需用户分立的分别输入就可以允许该专家系统访问临床数据，并且因此保有了数据的保真度。它也允许用户从能与该专家系统进行通讯的各个临床系统中访问该专家系统，并且在系统间提供无缝转移。从功能上讲，专家系统好像是内在地建立在临床系统中的一样运行，尽管它实际上是独立的。这补足了现有的临床工作流程，并且增加了临床医生使用专家系统的可能性。

本发明的一个实施例包括了一个系统，用于促进单机医疗专家系统和至少一个临床系统之间的通讯，这个系统包括了远离临床系统的单机医疗专家系统。没有本发明，该专家系统与临床系统或它的相关医疗模块中的一个的通讯可能不兼容。与专家系统和临床系统进行通讯的是至少一个接口模块，该接口模块促进了专家系统和临床系统之间的数据传输。该(或这些)接口模块也允许临床系统的用户从临床系统的用户接口内无缝的访问和使用医疗专家系统的功能，同时专家系统至少部分地控制临床系统的功能。通过这样的操作，临床医生、医师或者技术人员使用某个医疗模块可以访问独立的和分立的专家系统，而无需人工的切换操作、重新输入数据、或其他具有由一个或多个临床模块或临床系统提供的图形用户界面，其中所述模块例如但不限于，CDR模块，ADT模块，实验室模块，药房模块，放射学模块或者电子医疗记录模块。

本发明的另一个实施例中，至少一个接口模块包括多个不同接口中的一个或发挥多个不同接口中的一个的功能，例如但不限于，入站数据接口(Inbound Data Interface IDI)，出站报警接口，出站指令接口(Outbound Order Interface OOI)，出站数据接口(Outbound DataInterface)，入站应用接口(Inbound Application Interface)，同步报警接口(Synchronous Alert Interface)或审核行为接口(Audit ActionInterface)。

本发明的这些和其他优点和特征通过以下的描述和附上的权利要求将变得更加显而易见，或者可以通过此后的对于本发明应用的阐明而获知。

附图说明

为进一步阐明本发明的上述和其他优点和特征，通过参考特定的附图说明的实施例更加详细的描绘了本发明。应该理解，这些附图仅仅用于说明本发明的典型的实施例而不应视为限制其范围。本发明通过使用以下附图而更加详尽的描绘和解释如下：

图1示出了本发明一个示例性的实施例的示意图，代表了在临床系统和专家系统之间接口实现方案的一个模型；

图2示出了图1中系统的一种应用的工作流程图；

图3示出了图1中系统的另一种可选应用的工作流程图；

图4示出了本发明另一个示例性的实施例的示意图，代表了在临床系统和专家系统之间接口实施方案的另一个模型；

图5示出了图4中系统的一种应用的工作流程图；

图6示出了图4中系统的另一种可选应用的工作流程图；

图7示出了图4中系统的再一种可选应用的工作流程图；

图8示出了本发明又一示例性的实施例的示意图，代表了在临床系统和专家系统之间接口实施方案的再一个模型；以及

图9示出了图8中系统的一种应用的工作流程图。

具体实施方式

现在参考图1，在一个示例性的实施例中，临床系统(ClinicalSystem CS)101包括许多临床模块，这些临床模块包括：临床数据知识库(Clinical Data Repository，CDR)102、住院/出院/转院系统(Admission，Discharge，Transfer ADT)103、实验室(LAB)系统104、药房(PHARM)系统105、放射学(RAD)系统106、电子医疗记录(EMR)系统107、和临床系统接口引擎(Clinical System InterfaceEngineer，CSIE)108。图1中显示的临床系统101的各医疗模块并不是详尽的，本发明的各实施例也并不需要所有的临床模块。当然，图1中显示的各模块、系统、数据库、接口只是对本发明的一个示例性的实施例的说明。正如本领域的技术人员可以理解的术语，各临床模块可以是各临床系统本身。因此，正如在此使用的，临床系统可以指各单独的临床模块或者临床模块的集合。

每个临床模块可以包括用户接口(UI)116，其向用户显示信息并接受用户数据的输入。显示的信息被存储，例如，存储在临床数据知识库102中，或存储在一个应用该信息的临床模块中。类似的，通过U1116输入的数据指向临床数据知识库102或应用该信息的临床模块的知识库中。U1116可以是多个图形用户接口中的一个，这些图形用户接口提供数据的直观表达并允许将额外的数据输入或键入到临床数据知识库102中。各种帧，字段，菜单，图像和文本都可能被用作UI116的一部分。

临床系统接口引擎108接收来自每个临床模块馈送(feed)的数据110，111，112，113，114，115。接着，临床系统接口引擎108将这些数据提供给专家系统119。这些数据110，111，112，113，114，115的馈送可以是周期性的、零星的或者连续的。在本发明的可选实施例中，运行临床系统接口引擎108功能的临床系统接口可以作为多个临床模块之一的一部分来实施。因此，在这种情况下，临床模块可以直接向专家系统119发送数据或从专家系统119接收数据。这样的一个例子显示于图1，其中电子医疗记录系统107的UI116直接连接到专家系统接口引擎125。

专家系统119作为一个与临床系统101分立的系统而存在。专家系统119可能包括通过多个数据馈送120，121，122相互连接的专家系统用户接口(Expert System User Interface，ESUI)123、专家系统数据库(Expert System Database，ESDB)124和专家系统接口引擎(Expert System Interface Engine，ESIE)125。专家系统119通过临床系统接口引擎108使用各种入站和出站数据接口或者馈送130，131，132，133，134，135，136连接到临床系统101。数据接口或馈送具有特定格式和数据结构，其定义了什么样的数据能穿过数据接口或馈送、以及数据是如何穿过数据接口或馈送的。例如且不限于，穿过接口的数据或沿着该数据馈送可能具有特定的报头、特定的患者信息元素、报警元素、指令(order)元素和其他类似的内容。这些数据接口或馈送将在下文中单独详细讨论。

这些各种各样的接口能够使专家系统和临床系统、和/或与该临床系统相关的各临床模块之间进行通讯。这些模块提供了结构化的方法，据此使得数据可以双向地在临床系统和相关的临床模块和专家系统之间进行通讯。以下是对一个与临床系统接口引擎和专家系统接口引擎相关的实例性接口的讨论。在一个实施例中，该接口可能利用了工业标准消息定义，伴随对这些定义的增加和修改来创建这里描述的接口定义。本发明的其他实施例允许使用专有的(proprietary)消息定义。专有的消息定义以及工业标准定义，都可以用于确保在专家系统和临床系统之间传送的结构化消息的一致性。

如图1所示，临床系统接口引擎108和专家系统接口引擎125可以通过入站数据接口133进行通讯。这个接口提供了用于传送关于各个患者的数据的管道和消息结构，在此，这些数据已经输入到了临床系统101的各临床模块中。这些临床模块可以包括，但不限于以下模块：住院/出院/转院(ADT)、实验室(LAB)系统、药房系统、指令系统、放射学系统、临床档案系统、临床知识库、和其他接口引擎。

下表包括了用于特定入站数据接口类型的示意性的数据元素。以下仅仅是示例性的，且其他数据元素也可用在本发明的实施例范围中。一些执行工业标准消息定义的实施例可能包含额外的定义，例如Z或者其他HL7定义的部分(segment)，其添加是为了其他接口事务类型。

表1

ADT部分
		MSH	消息报头
EVN	事件
		PID	患者信息
MRG	合并
		[{NK1}]	下一个亲属
PV1	患者访问
		[PV2]	额外患者访问
[{DG1}]	诊断
		[{GT1}]	保证人
[{IN1}]	保险
		[ACC]	意外事件

表2

Lab部分
		MSH	消息报头
PID	患者信息
		{[NTE]}	评论
[PV1]	患者访问
		[ORC]	公共指令
OBR	指令细节
		{[NTE]}	评论
{[OBX]}	观察/结果
		{[NTE]}	评论

表3

药房部分
		MSH	消息报头
PID	患者信息
		PV1	患者访问
ORC	公共指令信息
		RXR	配药途径
{RXE}	配药编码指令
		[AL1]	过敏信息
[{OBX}]	患者身高/体重

表4

放射学部分
		MSH	消息报头
PID	患者身份标识
		PV1	患者访问
ORC	公共指令
		OBR	观察报告编号
{[NTE]}	注意事项和评论
		{[OBX]}	观察/结果

表5

血液气体(ABG)部分
		MSH	消息报头
PID	患者信息
		ORC	公共指令信息
OBR	观察报告编号
		{[OBX]}	观察/结果

表6

文本(脚本)部分
		MSH	消息报头
PID	患者身份标识
		PV1	患者访问
OBR	观察请求
		{[OBX]}	观察/结果

图1示出了专家系统接口引擎125在出站报警接口131上将消息发送到临床系统接口引擎108。出站报警接口提供了用于传输特定患者的报警信息的管道和消息结构，所述报警信息来自专家系统产生的报警。产生于专家系统内的异步报警(信号)可以在某个消息中被传送到外部临床系统。其可以显示在外部系统的用户消息应用中。该外部系统可以提供一种机制以链接到专家系统和直接访问该报警内容。消息的内容可以包括以下的一个或多个：

1.目标用户的识别符，专家系统可以识别作为报警对象的特定的用户

2.患者识别符

3.报警会话识别符

4.日期/时间标记

5.报警识别符或名称

6.报警消息，该消息可包含报警发生的原因和使用专家系统对该报警作出反应的建议

7.一些标识符，当专家系统从外部应用进入时，外部系统可以在利用入站应用接口的链接中使用这些标识符，以直接将适当的报警呈现给用户

8.紧急指示符，其指示出向外部系统报警的紧迫性。

9.更新指示符，发送与以前的报警相关，可以在外部系统中更新报警或者能够指出报警可以被解除。

图1示出了专家系统接口引擎125在出站指令接口135上发送消息到临床系统接口引擎108。出站指令接口提供了用于将特定患者的指令(orders)从专家系统传送给临床系统的管道和消息结构。该接口可以传送药物治疗的指令到外部系统，例如给病区药房、零售配药或者给指令管理系统。它也可以传送指令，用于实验室研究或放射学研究，也可以将其他有所指向的临床指令传送给适当的系统。该指令可以被发送到外部系统的中间结果暂存器(scratchpad)，或者等同的区域，这样该指令就可从那里处理。另外的，这些指令可以直接送到药房或者其他部门的系统。

患者和用户背景可以被OOI传送。这个接口可以发送指令细节。用户评价、拒绝原因和相关信息通过审核行为接口(在下文中详细描述)发送。信息的内容可以包括以下的一个或多个：

1.用户识别符

2.患者识别符

3.报警会话识别符

4.日期/时间标记

5.报警识别符

6.指令列表和指令措施，回复可以支持一个或多个不同的指令

7.指令列表中每个指令的细节，这可以用于，例如，专有的消息定义或者工业标准消息定义，诸如HL7指令接口标准。

8.支持的措施可以包括新的指令、停止、保持或挂起、改变和在专有的消息定义或工业标准消息定义中定义的任何其他措施。

9.指令识别符，该识别符来自外部系统，其在那个系统中识别特定的指令建议(instance)。它需要在外部系统中已存在的指令上停止、改变或采取任何其他的措施。

图1示出了专家系统接口引擎125在出站数据接口134上发送消息到临床系统接口引擎108。出站数据接口提供了用于将由用户输入到专家系统的数据或在专家系统内部生成的数据传输到外部系统的管道和消息结构。这可以是离散的、结构化的元素，例如身高或生命体征(vital signs)；或者可以是文件，例如医生检查部分、完整的在线巡诊报告(completed online rounds report)或者决策支持进程注释。例如，当使用HL7规范的时候，可以使用一个带有分立HL7 OBX部分的接口用于数据元素和文档本身。患者和用户的背景可以被传送。信息的内容可以包括：

1.专有的消息或者工业标准消息，例如HL7 OBR消息，作为例如XML的文档发送。它可以利用与入站数据接口中一样的元素实施。这个消息可以包含为了发送的数据元素和这些元素数值的标识符。这些元素可以包括例如，患者、日期、时间，数据元素的性质、和来源。

2.报警标识符

3.报警会话标识符。

4.专有的消息或者工业标准消息，例如HL7过敏消息可以用于发送过敏信息。

5.专有的消息或者工业标准消息，例如HL7诊断消息可以用于发送问题或诊断的信息。

图1示出了专家系统接口引擎125在入站应用接口132上接收来自临床系统接口引擎108的消息。入站应用接口提供了管道和消息结构，用于提供从外部系统(例如临床系统)内的链接到专家系统的访问。该链接决定了专家系统中被访问的组件。该接口可能包含了专家系统需要的所有数据，例如正在讨论的药品或结果。患者和用户背景被保存。如果由于在专家系统中产生的报警而在外部系统中出现该链接，那么，接口消息可以包含一个连接到该专家系统中的那个报警内容的标识符。该消息的内容可以包括，例如：

1.用户标识符

2.患者标识符，如果有

3.报警会话标识符，如果相关

4.日期/时间标记

5.指示符，标识了打开专家系统的哪一部分

6.链接背景，如果位于药物治疗的指令中，该消息可以包括药物治疗和相关指令的细节。该消息也可以包含未期望的已存在于专家系统中的任何患者信息。

7.药物信息，包括药品、剂量、(用药)途径(route)、频率(frequency)、疗程等。

8.实验室信息，包括实验室测试，结果值，测试间隔等。

图1示出了专家系统接口引擎125在同步报警接口130上向临床系统接口引擎108发送消息和从临床系统接口引擎108接收消息。同步报警接口提供了用于支持在外部系统和专家系统之间同步互动的管道和消息结构。具体来说，同步报警接口提供了消息结构或者协议，其允许外部系统请求处理指令或通过专家系统请求其他临床数据，以此利用专家系统的诸如生成报警发生器的特性。按此方法，专家系统可以用于分析放置在外部指令管理系统中的指令，该外部指令管理系统例如是计算机化的医师指令入口(Computerized Physician OrderEntry，CPOE)系统、或者药房系统。外部系统可以用含有将被分析的指令的消息调用专家系统，并且暂停对指令的进一步处理，等待专家系统的回复。专家系统的回复可以确定是否发出报警。如果发出报警，则回复可以包含足够的信息以使外部系统处理这个报警。这可能涉及自动产生变化，或者可能需要外部系统将该报警信息呈送给用户。用户可以随后决定是否接收这个建议。一旦发生，外部系统可以把结果传递回专家系统以便审核。

同步报警接口是双向接口。同步报警接口的专家系统入站接口来自外部系统的应用，例如CPOE或配药指令入口系统。这是一个通过专家系统报警引擎处理的请求，包含了患者和用户背景，也有对措施进行评判和分析的细节。由于本发明利用了在专家系统和临床系统之间的互动会话，因此具有高性能的专家系统是可以期待的。

本发明支持在专家系统和临床系统之间的同步互动或者通讯。在临床系统中采取的措施在专家系统中得到核实和分析，并且在该措施在临床系统中完成或实施之前，专家系统会给临床系统一个关于该核实和分析的答复。反之也是可能的。

同步报警接口的专家系统出站接口包括了报警处理的结果。如果生成了报警，那么带有患者和用户背景的报警内容会返回。如果没有报警生成，那么回复也会如此指出。审核信息通过审核行为接口传递到主系统。该审核信息的传递也可以是异步的。

本发明的专家系统处理可以无需用户互动而完成，并且回复指向外部系统。外部系统决定是否直接向专家系统发出申请或者向用户呈送到专家系统的链接，以此允许用户向专家系统咨询。外部系统可以在外部应用中呈送来自专家系统回复的信息，并且允许用户接受或拒绝这个信息。如果选择了这样实施，审核信息可以通过审核行为接口返回给专家系统。与同步报警接口相关的入站消息的内容可以包括下列的一个或多个：

1.用户标识符

2.患者标识符

3.报警会话标识符

4.日期/时间标记

5.带有附随指令细节的指令列表，包括指令标识符，作出指令的医师。

6.其他临床信息，与诸如实验室结果或过敏信息相关的指令。

同步报警接口出站消息的内容可以包括以下的一个或多个：

1.用户标识符

2.患者标识符

3.报警会话标识符

4.日期/时间标记

5.报警标志，指出是否已生成了报警

6.带有细节内容的额外指令的列表

7.带有变更细节的变更或删除的指令列表

8.标识符，如果用户希望与专家系统互动以便调查和根据建议行动，则外部系统使用该标识符以允许用户直接链接到专家系统中的专家系统报警

9.可以结构化消息以加载由同一会话触发的多个报警。

图1示出了专家系统接口引擎125在审核行为接口136上，向临床系统接口引擎108发送消息和从临床系统接口引擎108接收消息。具体来说，审核行为接口提供消息结构或协议，其允许外部系统和专家系统保持它们的报警审核索引(audit trails)的同步化。外部消息系统可以允许用户直接解除报警，并且专家系统需要停止在那个报警上的审核索引。可选地，外部报警审核机制可以更新以反映出用户在专家系统中所采取的措施。这也提供给外部系统一种机制，在问题再次出现的时候，可以在患者治疗过程中稍后的时点(point)呈送报警的结果。

当用户针对在外部系统中呈送的报警而采取措施时，专家系统入站审核消息包括措施和不考虑的理由。当报警从外部系统被解除时候，其允许专家系统更新它的审核日志。

当在专家系统中按照报警采取措施时，专家系统出站审核消息包括措施和不考虑的理由，且允许外部系统保留它的审核索引。

当附带的用户看到显示给他们的报警内容时，专家系统出站审核消息也允许外部系统将不考虑的理由和其他评论显示给这些附带的用户。例如，如果药剂师顺序地浏览某个报警的医生评论，那么他也可以看到该医生的措施和所阐述的基本原理。

不考虑的理由可以被编码，以在可能时允许高效率的查询和理由的标准化。然而，该消息结构也可以支持自由文本评论(free textcomments)。

该接口是双向的，但是消息的内容在两个方向都是相同的。该消息的内容可以包括：

1.用户标识符

2.患者标识符

3.报警会话标识符

4.日期/时间标记

5.报警标识符

6.报警行为

7.经过编码的不考虑的理由

8.用户评论

总的来说，本发明的专家系统包含了知识库和一种用于保有患者信息的方法或机制，例如硬件和/或软件的模块和组件。专家系统可以包括接口引擎，其接收数据到专家系统中，并发送数据回到一个或多个外部临床系统，该一个或多个外部临床系统可以使用一个或多个接口与该专家系统进行通讯。该专家系统还可能包括预处理输入数据的推理引擎(inference engines)、和一个或多个将知识库的知识应用到单个或全体患者信息的知识引擎。

专家系统可以与一个或多个临床系统或其他系统接口。例如，专家系统可以和临床数据知识库、单独的数据系统(例如实验室或药房)、接口引擎、或者其他知识库、系统或引擎接口。

总的来说，如在此使用的专家系统可能并不是指各种专家系统(例如在人工智能的应用中使用的那些专家系统)的广泛分类。当然，尽管这里所描述的专家系统可能结合了人工智能的原理，但正如在医疗领域的技术人员所明了的术语那样，在这里使用的专家系统是一种临床决策支持系统(Clinical Decision Support System，CDSS)。

在一些实施例中，专家系统119和临床系统101可以包括一个或多个专用(目的)的和一个或多个通用的计算机，所述计算机包含有各种硬件组件。本发明的一些方面也会按照包含功能性的步骤和/或非功能性的动作来描述。下面描述了可以在本发明的实践中执行的动作和步骤。通常，功能性的步骤依照所实现的结果来描述本发明，而非功能性的动作则描述了用于达到特定效果的更具体的行为。尽管功能性的步骤和非功能性的动作可以在特定的次序中描述或声明，但是本发明并不限于动作和/或步骤的任何特定的次序或组合。

本发明将按照在网络环境中由计算机执行的计算机可执行指令(例如程序模块)的常规环境来描述。总的来说，程序模块包括子程序(routines)、程序、对象、组件、数据结构等，它们执行特定的任务或实现特定的抽象数据类型。计算机可执行指令(与数据结构相关)和程序模块代表了用于执行在此公开的方法步骤的程序编码方案(program code means)的例子。这些可执行指令的特定序列或相关的数据结构代表了与用于执行在这些步骤中所描述的功能相应的动作的例子。

除了上述内容，本发明的实施例还可以包括计算机可读介质，用于承载或具有存储在其上的计算机可执行指令或数据结构，数据结构的这些指令可以是计算机软件代码。这些计算机可读介质可以是任何能被通用或专用计算机访问的介质。举例来说，但不限于，这些计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM、或者其他光盘存储设备、磁盘存储设备或者其他磁存储设备、或者其他的任何介质，这些介质可以用来以计算机可执行指令或数据结构的形式承载或存储所想要的程序编码方案，并且这些介质可以由通用计算机或专用(目的)计算机访问。当通过网络或其他通讯连接(既可以是有线的[hardwired]、也可以是无线的，或者是有线和无线的结合)传送或提供信息给某台计算机时，该计算机将该连接全然视为一个计算机可读介质。因此，任何这样的连接都完全可以称为计算机可读介质。上述的各种组合也应该被包括在计算机可读介质的范围内。计算机可执行指令包括，例如，指令和数据，它们引起通用目的的计算机、专用目的的计算机或者专用目的的处理设备实现某个功能或功能组。

本领域的技术人员能够明白，本发明可以在具有多种类型的计算机系统配置的网络处理环境中实施，其中计算机系统配置包括个人电脑、手持设备、多处理器系统、基于微处理器的或可编程的用户电子设备、网络PC、微型计算机、大型计算机和其他类似的设备。本发明还可以在分布式处理环境中实施，在该分布式处理环境中，任务由本地的处理设备和通过通讯网络(既可以是有线的、也可以是无线的，或者是有线和无线的结合)链接的远程处理设备共同完成。在分布式处理环境中，程序模块可以位于本地和远程两者的存储设备中。这些计算机系统可以包括各种接口，这些接口包括键盘、鼠标、计算机监视器、网络连接等和其他类似的设备。

如上所述，临床系统101的各部分可以作为在一个或多个计算机系统上的计算机软件代码来实现。临床系统101的软件代码是相对于专家系统119的软件代码分立的应用程序。然而，本领域技术人员应该明白，尽管是分立的应用程序，但是专家系统119和临床系统101可以在共同的计算机系统上或计算机系统网络上运行。更进一步，当专家系统119和临床系统101是分立的系统时，本发明的各实施例包括了多个接口，例如，专家系统接口引擎125，用于在专家系统119和临床系统101之间促进标准化通讯。当专家系统接口引擎125示作专家系统119的一个独立模块时，应当明白，专家系统接口可以在任何适当的位置实现，例如，专家系统接口可以是作为专家系统数据库124的一部分或者位于任何其他合适的位置。该专家系统接口还包括在这里所描述的专家系统接口引擎125的功能。相似地，专家系统119和临床系统101的其他模块也可以在除了示例性的附图中所示出的系统以外的那些系统中各自对应的其他位置上实现，而这些实施方式仍在本发明实施例的范围中。

图2示出了一个与图1的系统相关的示例性的工作流程。继续参考图1和图2，临床系统101生成了临床数据，“方框201”。临床数据可以由医生将数据输入到临床系统101中生成，或者可以经UI116通过模块130-136中的一个来生成。该数据也可以通过以下方式获得：实验结果、经医院住院部输入的住院和出院的数据、指令或提供的药物、以及其他类似的方式。临床数据可以由临床系统接口引擎108通过入站数据接口133(“方框202”)发送。专家系统接口引擎125从入站数据接口133接收数据(“方框203”)并处理该数据。该处理过程包括在消息中的各数据元素上附加一个标准数据的标识符，之后由专家系统119中的专家系统接口引擎125进行处理。经处理的信息随即存储在专家系统数据库124中用于进一步处理，“方框204”。该进一步处理可以由例如临床决策模块126完成。在本例中，临床决策模块是作为专家系统数据库124的一部分的软件代码而示出的。然而，临床决策模块126也可以在专家系统119中的其他位置实现。临床决策模块126包括了使用专家数据的推理引擎，以便根据从临床系统101接收的数据决定对特定患者的治疗措施，所述专家数据，即指与存储在专家系统数据库124中的医疗状况的诊断和治疗相关的该医疗领域典型知识的数据)。

有时，专家系统119也可以生成报警，“方框205”。该报警可以对应于特定患者，且与临床治疗的一些方面相关，这样，在UI116的任何一个或所有的用户都会被告知，例如采取某项行动，或用与患者相关的信息或数据被告知。专家系统119经专家系统接口引擎125可以将这个报警通过出站报警接口131发送到临床系统101，“方框206”。这个消息可以从专家系统119推送至临床系统101，或者可以由临床系统101请求或查询。临床系统101接收报警，“方框207”，并且通过一个或多个的与临床系统101相关的多种显示机制(例如UI116中的一个)显示该报警，“方框208”。这可以包括对在收件箱或在电子医疗记录(系统)107中的其他消息系统中的报警消息进行显示。这些报警也可以发送给患者主治医师的或一些其他个人的寻呼机、电子邮件收件箱、语音消息服务、以及其他类似的设备或地方。作为说明性地，该报警可以与该患者相关的某个记录一起显示，这个记录可以是在临床系统101中的任何记录，例如举例来说，该记录可以是，患者的实验室记录、放射记录、药房记录、CDR记录、ADT记录等。用户可以查看这个报警，并且决定是否采取任何措施。

继续关注图2，如果用户决定不对报警采取任何措施，那么他们可能会解除报警，“方框209”。这样做需要用户提供一个解除的理由，这将被记入临床系统101中，“方框210”。临床系统101适当地更新它的审核日志，“方框211”。当解除报警时，临床系统101也通过审核行为接口136将审核信息消息发送到专家系统119，“方框212”。专家系统接口引擎125接收该审核信息消息，“方框213”。该审核信息消息同样包含了允许专家系统119更新其审核日志的信息，“方框214”。

当用户决定希望对报警采取进一步措施的时候，可以接着如图3所示的工作流程。图3包括了方框210至208，它们与图2中标明的那些执行和示出的操作和功能相同。结合图3，与图2示出的简单解除报警相反，下面描述了当用户决定对报警采取进一步行动的时候所执行的措施和功能。参考图1和图3，允许用户通过选择链接或在临床系统101的用户接口UI116中的相类似机制访问专家系统119，“方框309”。例如，临床系统101可以提供一个用户接口116，该用户接口可以包括例如超级链接、按键、单选按键、下拉菜单、列表或其他的链接方式。这些链接中的一个可以连接到专家系统119。选择链接的步骤使得用户可以访问专家系统119中的报警。即，临床系统接口引擎108从专家系统119请求访问(“方框310”)。该请求通过入站应用接口132发送，且被专家系统接口引擎125接收，“方框311”。该请求包含了允许专家系统119显示与恰当的报警相关的数据的信息，“方框312”，同时保存由临床系统101提供的患者和用户的背景。例如，用户接口116的相同结构可以包含存储在临床系统101中的数据和从专家系统119接收的数据。可选地，选择该链接可以在含有与该报警相关数据的临床系统101处打开的应用程序中激活一个“弹出”窗口。

在任一情况下，现在，用户可以在专家系统119中工作，通过在临床系统101中UI116中的一个管理报警，“方框313”。对报警的管理可以包括用户对临床数据进行更新，“方框314”。用户可能希望输入那些需要用来完成对报警进行处理或管理的附加的患者信息。作为对报警进行处理或管理的结果，专家系统119本身也可以生成患者信息或者与患者相关的推断。如果该信息是可以存储在临床系统中的临床信息，例如身高、体重、诊断或其他临床数据，则专家系统接口引擎125可以发送这些临床数据，“方框315”，如此临床系统接口引擎108就可以通过出站数据接口134接收这些数据，“方框316”。临床系统101可以随后根据它的设计处理并存储新的临床数据，“方框317”。

作为报警和对该报警进行处理和管理的结果，用户可能希望设置要适用于患者的指令，“方框318”。这些指令可以包括诊断研究或者测试，或者添加、修改或停止用药或其他指令。利用出站指令接口135，用专家系统接口引擎125可以将任何新的指令发送(“方框319”)给外部临床系统101，“方框320”。临床系统101随后通过由临床系统接口引擎108将这些新的指令转达给接收这些指令的临床模块，来处理这些新的指令，“方框321”。

当完成对报警的操作和管理后，报警的结果以及临床系统101所采取的任何措施可以在专家系统119和它的审核日志中被更新，“方框322”。更新之后，审核信息消息通过审核行为接口136发送到临床系统101，“方框323”。该审核信息消息可以包含所采取的措施以及临床系统101的用户为这些措施输入的任何原因的日志。当临床系统接口引擎108接收到该审核信息消息时(“方框324”)，临床系统101可以适当地更新它自己的审核日志，“方框325”。用户可以从专家系统119返回到临床系统101。

本发明的另一示例性的实施例示于示意图4。图4中的实施例示出了专家系统419连接到临床系统401和包括临床数据知识库402和药房系统417在内的其他各临床模块。可选地，药房系统417可以是一些其他适当的部门系统。特别地，如在此应用的，临床系统可以指各临床模块的集合。临床系统也可以指小型临床系统的集合、或小型临床系统与各临床模块的任意组合。本领域的技术人员应当理解，这里示出的各临床模块通常被称为各临床系统。术语临床模块通常用于说明在临床系统集合中的小型临床系统的独立特性，或者用于说明与其他临床系统相独立的小型临床系统的特性。因此，临床系统实际上可能由其他的临床系统组成。与图1中示出的数据馈送130，132，133，134，135，136相类似，专家系统419通过数据馈送430，432，433，434，435a，435b，436连接到临床系统401、临床数据知识库402以及药房系统417。

在该实施例中的三个实例性的工作流程示于图5、6和7中。现在请关注图4和5。在图5中，医生可以使用临床系统401创建或修改对患者的指令，“方框501”。临床系统401可以生成一个由专家系统419处理的请求(“方框502”)。如在前面对接口的描述中所述，这些新的指令可以通过同步报警接口430发送给专家系统419。在同步报警接口430上发送的消息可以包含用户和患者的标识符、以及新的指令和其他指令的细节，例如剂量、用药途径(route)、频率和疗程。该消息也可以包含其他细节，以协助在专家系统419中对该指令进行评估。新的指令消息被同步发送，这意味着在临床系统401中暂停对该指令的进一步处理，直到从专家系统419收到一个回复。在收到这个消息后，专家系统419可以立即处理该消息的内容，“方框503”，并通过同步报警接口430向临床系统401发回它的回复，“方框501”。这个回复的消息可以包含一个是否已生成了报警的指示。如果还没有生成报警(“方框505”)，则临床系统401就可以通过发送该指令的请求到适当的临床模块，继续其处理，“方框506”。

现在直接关注图4、6和7，医生又一次使用临床系统401为患者创建和修改指令，“方框601、701”。临床系统401请求专家系统419处理这些指令，“方框602、702”。专家系统419按如上所述对提议的指令进行处理，“方框603，703”。在这些例子中，生成了报警。与本发明的专家系统419产生的其他报警类似，来自专家系统419的回复，“方框604，704”，可以包含关于报警特性的信息。它可以包含特定的患者和用户的信息、以及详细的建议，例如但不限于，中止一个指令或为特殊的药物治疗设置指令的建议。该回复可以包含任何或所有的细节，以便在临床系统401中生成指令。回复也可能包含链接信息，这样的一个链接地址可以显示给临床医生、医师或其他通过临床系统401上的用户接口(如图1的UI116)或由他们访问。该链接通过经由入站应用接口432激活一个调用，能够使用户直接从临床系统401访问专家系统419。临床系统401向用户显示该报警，“方框605，705”(例如通过在临床系统401上的用户接口UI116中显示消息)以允许用户照此行动。

继续该示意性的处理，在图6中，用户可能判定该报警是不恰当的，或者决定解除该报警，“方框606”。临床系统提供了为解除报警和捕获任何为解除报警而由用户给出的理由的资源。例如，临床系统401可以呈送包含了链接或按键以及文本框的用户接口，通过该链接或按键用户可以解除报警，而通过文本框可以提供解除报警的理由。与解除该报警相关的信息可以用于更新临床系统401的审核日志，“方框607”。另外，临床系统401可以通过审核行为接口436将含有审核信息的消息发送给专家系统419，“方框608”。这允许专家系统419接收该审核信息，“方框609”，并适当地更新它的审核日志，“方框610”。

作为图6中所描述的处理过程的另一种选择，如图7所示，用户可能判断报警是适当的，并且决定采用一个或多个建议的措施。这些措施可能是在临床系统401内生成的。在图7所示的例子中，用户可以添加或改变指令，“方框706”。使用专家系统419、临床系统401、或者相关的临床模块可以进行这些添加或改变。当完成所采取的措施后，临床系统401更新它的审核日志，“方框707”。另外，临床系统通过审核行为接口436将含有详细说明所采取措施的审核信息的消息发送给专家系统419，“方框708”。这允许专家系统419接收该审核信息“方框709”，并适当地更新它的审核日志，“方框710”。

另一示例性的实施例示于图8。图8示出了专家系统819，类似于图1中的数据馈送120，121和122，该专家系统包括通过各种不同的数据馈送820，821，822互相连接的专家系统用户接口823、专家系统数据库824和专家系统接口引擎825。

专家系统819通过专家系统接口引擎825和多个数据馈送833，834，835(类似于图1中的数据馈送133，134，135)连接到临床系统801。专家系统819可能与其他在这里所描述的专家系统相类似，例如图1中的专家系统119。对于本实施例可能的工作流程示于图9。现在关注图8和9，在这个例子中，用户通过专家系统用户接口823直接访问专家系统819，“方框901”。因为入站数据接口833提供了患者身份识别信息和患者数据的数据馈送，因此用户可以在专家系统819中选择特定的患者，“方框902”。可选的是，通过专家系统819的处理，它可以生成呈现在专家系统用户接口823中的报警。用户可以通过选择这些报警访问被选患者的特定数据。可选的是，用户可以通过他的用户接口823查询符合特定标准的患者，并且可以随即通过该查询的结果访问特定患者的身份识别信息和数据。该查询返回符合该特定标准的患者的列表。用户可以随即从这个返回的列表中选择患者以访问患者信息。可以通过使用例如菜单、下拉菜单、数据字段、文本框和其他类似的方式在用户接口823中制订该查询。在另一可选的实施例中，专家系统可以向用户呈送从其中能识别特定患者的列表或名册，以便通过其用户接口823可以访问信息。该名册或列表可以是按照患者的位置、临床服务、主治或咨询的医师的列表、或者其他保存在临床系统中的患者列表。将这些列表显示在专家系统819中，例如显示在用户接口823上。用户可以从该名册或列表中选择患者。还是在另一可选的实施例中，专家系统819可以在其用户接口823中将一个临床信息的患者特定视图，例如简要的报告或巡诊报告，呈送给定的医师、临床医生、诊所或部门等。

一旦用户已经访问了与特定患者相关的数据，则用户可以随即使用保存在专家系统819的知识库中的专家知识生成为治疗或进一步评估的患者特定的建议，“方框903”。用户可以选择特定指令，这些指令随后经出站指令接口835通过ESIE 825发送到临床系统801“方框905”。出站指令接口835可以通过临床系统接口引擎与临床系统801进行通讯，或者直接与在临床系统801中的指令应用程序进行通讯。在稍后的例子中，专家系统接口引擎825穿过出站指令接口直接发送指令到临床系统801中的指令应用程序或一些其他的临床模块，“方框905”。指令应用程序随即接收指令“方框912”，随后完成任何必要的对指令的处理，“方框913”。临床系统801接收(“方框906”)并处理这些指令，“方框907”。如果是由用户输入了需要存储在临床系统801中的患者的临床数据，或者是从专家系统819的处理过程中生成了这样的数据，则可以通过出站数据接口将这些数据发送给临床系统。

示例性的专家系统的可选的特性是一种能在专家系统和临床系统之间对数据和术语词汇进行标准化的机制。在一种配置中，词汇服务器(Vocabulary Server)是专家系统的一部分。该词汇服务器包括将术语词汇分配给数据元素的模块或软件。在本发明的一个实施例中，位于临床系统中的数据元素的识别符被初始地映射到标准命名。基于这个映射，所有从临床系统接收到的数据元素都与附带的标准命名标识符一起存储在专家系统数据库中。对于那些并未作初始映射的数据元素，在词汇服务器中可以有这样的功能，以便允许系统识别出最匹配的标准命名。这允许系统给一个或多个数据元素中的每一个附加一个标准命名标识符，其中这些数据元素基于它们是产生于原始的系统中的而可能具有不同的标识符，但事实上它们代表相同的实体(含义)。在示例性的实施例中，这个词汇服务器是专家系统接口引擎的一个组成部分。当从临床系统接收每个入站数据元素时，该词汇服务器给所接收的数据附加上一个标准标识符。当将每个出站数据元素写入一个由专家系统接口引擎发送出去的消息中时，该词汇服务器基于利用上述专家系统命名标识符的映射所附加的标准标识符，将适当的外部标识符分配给临床系统数据元素。

在另一配置中，词汇服务器是临床系统接口引擎的组成部分。当将每个数据元素发送给专家系统接口引擎时，标准标识符被使用。由于所收到的标准标识符映射到了本地标识符，因此可以在将数据发送给临床系统接口引擎时，执行相反的操作。

在另一配置中，数据标准化是在专家系统内部动态的处理。当数据通过接口传入的时候被保存。当专家系统访问数据元素时，词汇服务器映射每个元素到在专家系统处理中使用的标准标识符。

又在另一配置中，临床系统中的全部数据元素都与各标准标识符一起存储，并且这些标识符通过接口发送。接口不进行任何附加的映射，而专家系统本身也不进行任何附加的映射。在本例中，由于在整个临床系统和专家系统中使用了数据和词汇标准，因此取消了对词汇服务器的需求。

词汇服务器可通过用户的设计来实现。然而，在本发明的实施例中，词汇服务器也可以通过使用市场上能够买到的词汇服务器来实现。这样的服务器可以很容易地从科罗拉多州、奥罗拉市(Aurora，Colorado)的Health Language公司和康涅狄格州、里奇菲尔德市(Ridgefield，Connecticut)的Apelon公司获得。

在不脱离本发明的精神和必要特征的情况下，本发明可以以其他特定的方式实施。无论从哪方面看，在此描述的各种实施例仅仅是说明性的而非限制性的。因此本发明的保护范围是由所附的权利要求书代表的，而不是由前面的具体描述所限制的。所有在权利要求书中的含义和等同范围内的变化都应当包含在本发明的保护范围之内。

Claims (32)

1.在一个分立的专家系统与带有一个或多个临床模块的临床系统进行通讯的系统中，一种将所述分立的专家系统与所述临床系统进行接口的方法，该方法包括：

在入站数据接口和同步报警接口中的至少一个上，从所述临床系统接收临床数据；

在所述专家系统的专家系统数据库中存储所述临床数据；

在所述专家系统中处理所述临床数据；

基于所述处理临床数据的结果生成报警；以及

在同步报警接口和出站报警接口中的至少一个上，将所述报警发送给所述临床系统。

2.如权利要求1的方法，进一步包括：

当在所述临床系统中已经解除了所述报警时，在审核行为接口上从所述临床系统接收审核信息；以及

在所述专家系统中更新审核日志。

3.如权利要求1的方法，进一步包括：

在同步报警接口和入站应用接口中的至少一个上，从所述临床系统接收请求，用于访问所述专家系统；

在所述临床系统处显示来自所述专家系统的所述报警；

在所述专家系统处，在同步报警接口、入站应用接口、和入站数据接口中的至少一个上，从所述临床系统的用户接收临床数据的更新；以及

使用所述同步报警接口和所述出站数据接口中的至少一个将所述临床数据的更新发送给所述临床系统。

4.如权利要求3的方法，进一步包括：在所述专家系统处更新审核日志。

5.如权利要求3的方法，进一步包括：

在专家系统处，接收指令；以及

将所述指令发送给临床模块。

6.如权利要求5的方法，进一步包括：在所述专家系统处更新审核日志。

7.如权利要求1的方法，其中将所述报警发送给临床系统的步骤包括：从所述专家系统推送所述报警。

8.如权利要求1的方法，其中将所述报警发送给所述临床系统的步骤包括：

从所述临床系统接收请求或查询；以及

响应于所述请求或查询，将所述报警发送给所述临床系统。

9.如权利要求1的方法，其中所述报警包括各数据元素，该方法进一步包括：将各标准识别符附加到所述各数据元素的至少一部分上。

10.如权利要求1的方法，进一步包括：根据各专有消息定义，对包含所述报警的消息进行结构化处理。

11.如权利要求1的方法，进一步包括：根据工业标准消息定义，对包含所述报警的消息进行结构化处理。

12.如权利要求11的方法，进一步包括：根据HL7协议，对包含所述报警的消息进行结构化处理。

13.如权利要求1的方法，其中从所述临床系统接收临床数据的步骤包括：从设置在所述临床系统内的临床模块上的接口引擎接收临床数据。

14.一种计算机可读介质，具有用于执行如权利要求1的步骤的计算机可执行指令。

15.在与临床系统分立的专家系统处，一种提供临床决策支持的方法，包括：

在同步报警接口和入站数据接口中的至少一个上，从所述临床系统接收指令；

对所述指令进行处理，以生成对于所述指令的答复；以及

在同步报警接口、出站数据接口和出站指令接口中的至少一个上，将所述答复发送给所述临床系统。

16.如权利要求15的方法，其中所述答复是报警，该方法进一步包括：

当所述报警已经在所述临床系统处被解除时，在入站审核接口、入站数据接口和审核行为报警接口中的至少一个上，从所述临床系统接收审核信息；以及

在所述专家系统中更新审核日志。

17.如权利要求15的方法，其中所述答复是报警，该方法进一步包括：

当所述报警导致在临床系统处对指令作出添加或改变时，在入站审核接口、入站数据接口和审核行为报警接口中的至少一个上，从所述临床系统接收审核信息；以及

在所述专家系统中更新审核日志。

18.如权利要求15的方法，其中所述指令包括各数据元素，该方法进一步包括：给所述各数据元素的至少一部分分配标准识别符。

19.如权利要求15的方法，进一步包括：根据专有的消息定义，对包含所述答复的消息进行结构化处理。

20.如权利要求15的方法，进一步包括：根据工业标准消息定义，对包含所述答复的消息进行结构化处理。

21.如权利要求20的方法，进一步包括：根据HL7协议，对包含所述答复的消息进行结构化处理。

22.一种计算机可读介质，具有用于执行如权利要求15的步骤的计算机可执行指令。

23.在与临床系统分立的专家系统处，一种提供临床决策支持的方法，包括：

允许访问专家系统用户接口；

在所述专家系统用户接口中提供元素，用于从临床系统中的患者中选择至少一个患者的；

生成患者特定的建议；

从用户访问的专家系统用户接口接收各指令；以及

在同步报警接口、出站数据接口和出站指令接口中的至少一个上将所述各指令发送给临床系统。

24.如权利要求23的方法，进一步包括：

从访问专家系统用户接口的用户接收对临床数据的更新；以及

在出站数据接口上，将所述更新发送给所述临床系统。

25.如权利要求24的方法，其中将所述更新发送给所述临床系统的步骤包括：直接将所述更新发送给所述临床系统中的临床模块。

26.如权利要求24的方法，其中发送所述更新的步骤包括：将所述更新发送给临床系统接口引擎，以递送到所述临床系统中的临床模块。

27.如权利要求23的方法，其中提供步骤包括：在所述专家系统用户接口中提供元素，用于从患者列表、报警或查询的至少一个中选择至少一个患者。

28.如权利要求23的方法，进一步包括：根据专有的消息定义，对包含所述各指令的消息进行结构化处理。

29.如权利要求23的方法，进一步包括：根据工业标准消息定义，对包含所述各指令的消息进行结构化处理。

30.如权利要求29的方法，进一步包括：根据HL7协议，对包含所述各指令的消息进行结构化处理。

31.一种专家系统，包括：

适于存储临床数据的专家系统数据库；

临床决策模块，其连接到所述专家系统数据库且适于从所述专家系统数据库中的临床数据生成各报警；

专家系统接口引擎，其连接到专家系统数据库，所述专家系统接口引擎适于利用同步报警接口、出站报警接口、入站报警接口、入站数据接口、出站数据接口、出站指令接口和审核行为接口中的至少一个，将包含所述各报警的临床数据发送给与所述专家系统分立的临床系统，和从所述临床系统接收包含所述各报警的临床数据。

32.如权利要求31的专家系统，进一步包括连接到所述专家系统数据库和所述专家系统接口引擎的专家系统接口，所述专家系统用户接口在临床系统用户接口处是可显示的。

Images