重症监护病房智能监测系统中的知识库与数据库集成

### 重症监护病房智能监测系统中的知识库与数据库集成 #### 1. 系统任务规划与专家系统应用 在系统运行时，需要考虑网络拥堵、采集设备状态、处理器容量等因素，对这些情况进行上下文分析，进而确定任务的执行计划，优先处理部分任务，放缓或取消其他任务。在信息系统里，报告的生成和呈现是关键环节。虽然并非必须使用专家系统技术，但它能以易于理解的方式呈现信息，生成临床医生能快速吸收的文档，助力开发辅助医生决策的系统，例如 HELP 系统便是这方面的先驱。 获取信息后，可借助专门为特定病症开发的专家系统进行分析。现阶段多数系统都处于此阶段，但很多时候会忽略时间问题，专注于知识工程任务，像 MYCIN、DXplain、Internist - 1 等系统。 不同的知识模块并非孤立存在，它们基于相同数据朝着同一目标工作，因此模块间需要进行通信。为此，研究人员开发了如 Guardian 中使用的“黑板”策略，或 SIMON 提出的分布式架构。同一任务根据其特定目的，可能同时存在软时间和硬时间要求。例如，选择治疗方案时，若为病症康复，过程会较慢；若要纠正警报，则需快速完成。SEDUCI 系统通过开发分布式专家系统来处理这些标准，它在靠近患者的硬件元素中融入智能机制（可称为“反射性”推理，响应时间更短），同时在中央系统中进行诊断和治疗方案选择。 #### 2. 知识库与数据库集成的优势 在智能监测领域，将数据库作为整体监测系统的一部分进行集成是当前的热门领域。以基于规则的重症监护病房患者智能监测专家系统为例，将数据库添加到专家系统具有以下优势： - **便于专家系统规则使用存档数据**：可通过高效的数据库机制检索存档数据，而非使用专家系统编程语言中缓慢、繁琐且受限的方法。 - **为专家系统提供更大的工作内存**：系统需处理大量生理参数（20 - 30 个）以及数字信号分析结果，工作内存至关重要。 - **便于永久存档病例数据**：利用这些信息可事后分析患者进展，如研究警报原因、不稳定性以及调试知识库等。 - **实现数据的自动智能筛选**：在永久存档前，使用专家系统规则筛选数据，确保存档数据的一致性，这在数据库理论中也具有重要意义。 #### 3. 数据库与专家系统的集成类型 数据库与专家系统的集成方式可根据耦合程度和控制分配分为以下三类： | 集成类型 | 描述 | | --- | --- | | 增强型专家系统 | 将扩展的数据管理功能融入专家系统。 | | 智能/演绎数据库 | 在数据库管理中嵌入演绎组件。 | | 具有通信功能的专家/数据库系统 | 数据库管理和专家系统相互独立，通过某种通信机制连接，通信又可分为数据定义、数据库维护和管理以及数据操作三类。 | 在实际工作环境中，由于医院已植入信息系统（HIS），并包含关系型数据库管理器和大量历史数据及特定应用，因此与现有管理器进行通信是更实际和现实的集成解决方案。同时，商业数据库管理器已具备较高的灵活性、健壮性、安全性和速度，大多数专家系统开发者难以通过大量投入设计和实现来进一步提升。 #### 4. 智能/演绎数据库 此类系统将演绎组件融入数据库管理系统，可提高数据库的功能和效率，维护完整性限制并优化查询。在系统中融入演绎组件时，可在同一环境中实现与存储数据交互的知识规则，使典型数据库应用（如数据录入、报告生成等）和智能处理能协同完成任务。 数据库可定义为一个三元组，包含以下元素： - **理论**：由一组有限的公理和元规则组成，描述如何使用特定理论。 - **完整性约束**：数据库必须满足这些约束，以保证与理论一致。 - **常量集**：理论所定义的有限集合。 这种定义方式可使用类似自然语言的语法进行维护，即数据库的完整性限制可用知识规则表达。此类数据库系统还致力于改进信息操作机制，通过集成专家系统，以接近自然语言的方式进行交互，避免使用复杂语义结构，为专家系统提供以下能力： - 设计前端，甚至以自然语言与数据库进行更简单的交互。 - 通过简单语法触发定期或事件驱动的维护任务。 - 便于表达复杂查询，如传递性和递归查询。 目前市场上的多数关系型管理器都包含不同复杂程度的规则系统来触发任务。 #### 5. 具有通信功能的专家/数据库系统 这是专家系统领域最常用的集成类型。专家系统和数据库管理系统相互独立，通过通信机制连接。虽然开发时未专门设计通信结构，交互复杂度较高，但只需开发通信接口即可。 通信可分为以下三类： - **数据定义通信**：专家系统可确定或修改数据库结构。 - **数据库管理通信**：专家系统可执行数据库管理任务，如备份、恢复或存储分析。 - **数据操作通信**：专家系统向数据库管理系统发送数据操作命令，进行数据更新、插入、删除和检索，并基于检索信息进行分析。仅通过这种通信方式，在适当实现的情况下，可实现与智能/演绎数据库等效的系统。 知识规则可分为“如果”部分（条件）和“那么”部分（动作）。在数据操作通信中，可分为以下两种数据检索类型： - **简单数据检索**：直接从数据库中检索事实，但在专家系统运行前需进行信息加载操作，无法通过规则的“如果”部分直接从数据库检索数据。 - **全数据检索**：通过数据库管理系统支持的查询语言，在规则的“如果”部分检索数据库信息，无需在专家系统运行前加载数据库中的信息。 也可将这种集成方法用于专家系统和智能/演绎数据库之间，使两个系统的“智能”不直接关联，各自执行不同任务，不影响系统整体运行。 若要将专家系统的知识库扩展到数据库，首要目标是在两个系统之间建立自然、透明的通信机制。理想情况下，通信机制应使知识工程师能透明访问两个存储系统。为此，需在专家系统知识库和数据库中以相似方式构建知识。但在使用关系型数据库时，会面临问题，因为多数专家系统开发语言和工具（如 OPS/83/R2、Nexpert Object、G2 等）使用对象或伪对象方案存储信息，与数据库的存储方案不同。Gio Wiederhold 在 PENGUIN 项目中提出了一种解决方案，他研究了通过关系型数据库存储结构管理对象，列举了信息组织系统的以下优势： - **关系技术**：为大量信息的可靠共享提供基础。 - **对象方法**：提供信息的概念局部性，吸引用户注意力。 决策支持系统（如重症监护病房）需要结合使用数据库和智能应用。他提出的方案可从共享关系型数据库派生面向对象的数据结构，基于对象和视图（基于查询生成的虚拟图表）概念的相似性，为用户提供更高层次的抽象。对象可根据工作站应用需求进行调整，同时与底层共享数据库模型（关系模型）保持严格一致。在这种情况下，需研究虚拟图表对数据库访问速度的影响，这主要取决于数据库管理器对视图的管理。 #### 6. 时态数据库 数据库管理系统（DBMS）以明确的格式存储信息，关系型数据库以关系表形式存储，表中的元组由属性组成；面向对象的 DBMS 则通过对象存储实体信息。时态数据库与非时态数据库的区别在于，时态数据库中的数据附带时间信息，表明数据存储时间和有效性。传统数据库认为存储的数据在当前时刻有效，不记录过去或未来的数据库状态。通过为数据附加时间周期，可存储不同的数据库状态。 获取时态数据库的第一步是对数据进行时间戳标记，以区分数据库中的不同状态。在关系型数据库中，通常对元组进行时间戳标记。确定时间戳中的时间周期时，需考虑时态数据库的两个时间概念： - **有效时间**：表示事实在现实世界中为真的时间段。 - **事务时间**：表示事实存储在数据库中的时间段。 这两个时间周期对于单个事实可能不同。例如，数据库中存储的前一年住院患者信息，其有效时间在 1 月 1 日至 12 月 31 日之间，而事务时间从插入数据库时开始。 以重症监护病房患者信息存储为例，数据库表可记录患者历史信息，如患者 Anton Serrapio 因颅脑外伤于 1998 年 7 月 1 日至 8 月 2 日住院，后于 1999 年 1 月 19 日再次入住 ICU，若“退出”列值为“void”，表示患者仍在治疗中，数据为最新信息。 时态 DBMS 应支持以下功能： - 时态数据定义语言 - 时态数据操作语言 - 时态查询语言 - 时态约束 在关系型数据库中，可采用 SQL3 规范，该规范提议在 SQL/temporal 中添加支持有效时间的表，并说明如何从传统关系型系统平滑迁移到时态系统。它描述了为 SQL3 添加有效时间支持所需的语言扩展，并通过提供指称语义映射到明确定义的代数表达式，正式定义了查询语言的语义。 时态数据库在医疗信息管理系统等领域有广泛应用，但目前商业数据库管理系统（如 Oracle、Informix 等）大多是非时态的，不支持时态数据管理。在医院和重症监护病房中，需使用非时态 DBMS 提供的日期类型，并在应