摘 要： 针对医院信息管理系统(HIS)对辅助决策支持不足，提出以HIS为基础建设面向主题的数据仓库，建立基于联机分析处理(OLAP) 的医院决策支持系统。该系统采用数据仓库总线架构，通过共享一致维度集成各个相对独立的数据集市。在客户端针对不同的用户环境分别使用数据透视表服务和基于ADO MD的Web系统,极大地提高了系统的灵活性。

　　关键词： OLAP; 数据仓库; HIS; 数据总线

　　医院信息系统HIS(Hospital Information System)在医疗系统的广泛应用，促进了医疗信息的电子化，使医院数据库的信息量不断地膨胀。而这些宝贵的医学信息资源对医院的管理和医疗诊断都具有极高的价值。然而，许多医院当初设计开发HIS时的主要目的仅在于满足日常的业务处理，并没有考虑到对数据的分析与数据的挖掘。HIS运行几年以后，积累了大量的数据，数据项繁杂，收集的海量数据往往被沉淀，变成了难以利用的数据档案[1]。

　　基于数据仓库的联机分析处理OLAP(Online Analytical Processing)是使分析和管理人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解并能真实反映企业数据特性的信息进行快速、一致、交互地存取，从而获得对数据更深入了解的一类软件技术[1]。通过建立面向主题的数据仓库，使用联机分析处理，可对医疗数据进行多方面的综合分析，从而提高数据库的利用水平，满足医院管理的需要。

　　1 数据仓库与OLAP建模分析

　　1.1 医院多维数据分析的体系结构

　　多维数据分析的体系结构分成四个部分：数据源、数据中心、Web服务器(应用服务器) 和终端客户应用。数据源是指医院的各种业务系统的数据,如门诊、住院、医嘱等费用(HIS) ,医院影像信息(PACS) ,检验检查信息(LIS、RIS) 等数据集。数据中心是根据医院的需求确定的分析主题的集合，由各种数据集市集成的数据仓库。Web服务器为多维数据分析提供两种集成和发布方式,即B/S 结构的Web 集成方式和三层结构的应用集成方式。终端客户应用是指多维数据分析的数据展现分析工具。整个体系结构如图1所示。

　　1.2 医院数据仓库的结构

　　医院数据仓库建设中存在一个关键的争论就是如何规划数据仓库的结构。一种观点认为应该采用“自顶向下”的整体方法，一次性地创建整个数据仓库。这种方法不适应中国的医疗界现状。大多数医院并没有配置完整的IT系统，一般建设只有HIS，部分医院可能会有PACS和LIS，这种现状无法一次性完成整体创建。此外，这种方式也无法适应未来的业务调整。另一种是“自底向上”的观点，认为可将各种无关的、迥异的数据集市装配成企业级数据仓库。这种方法比较适合医院目前的现状，这也是本文所采用的方法。但为避免最终数据的不兼容，使各个独立数据集中的数据能集成为企业级的数据仓库，需要共享一致性的维度。因此，本文采用了数据仓库总线结构的形式。

　　在数据仓库的建设当中，要避免对构建角色和作用的混淆。在开发数据仓库环境时，有四个相互分离的独特构件需要考虑：操作型源系统、数据聚集环节、数据展示环节与数据存取工具[1]。数据仓库的组成结构[2]如图2所示。操作型源系统即HIS、PACS等系统;数据聚集环节主要是清理建立一致维度，如病人维度、医生维度、时间维度等;数据展示环节主要是确定面向主题的数据集市，如挂号业务和处方业务等，通过一致的维度集成各个数据集市;数据存取工具主要是各种分析报表和数据挖掘，如数据透视服务、Web查询等。

　　1.3 维度建模技术的选择策略

　　维度建模是指用于数据建模的特殊规范，与之对应的是实体-关系(E-R)模型，它是经常应用于数据仓库的一种逻辑设计技术。该技术试图采用某种直观的标准框架结构来表现数据，并且允许进行高性能存取。而实体-关系模型的目标在于去除各种冗余，努力达到第三范式的要求，避免各种操作异常。也正是因为这个原因，实体-关系模型不便于分析，它只适合于各种操作数据的跟踪。维度模型的主要部件是事实表和维度表。在医院进行多维数据分析发现，医院的各类人员正是从医生、病人、药品维度等理解业务的，这种模型充分反映了用户眼里所认可的业务。

　　多维模型有两种基本架构:星型模式和雪花模式。在星型模式中，事实表整个模式的中心。事实表的字段通常由一群主键与一些分析汇总数值字段所组成。而这一群主键的值往往又依靠其四周相关的维表的主键值构成星型模型。从主键与外表键的依存关系来看，星型模式适用于关系型数据库的环境中。在雪花模式中，多数经过雪花处理的表使数据展示变得复杂，而且雪花模型所提倡的维护容易性事实上也没有什么实际意义，因为数据加载到展示环节的维度方案发生之前尚有一段很长的转储环节[2]。此外，因使用雪花维度而节省下来的少量磁盘空间也是无关紧要的，用2字节的编码取代不到12 000行药品维度表320字节的产品名称，能够节省不到0.3兆字节(12 000×18字节)的磁盘空间。但事实表却有几百兆字节之大的磁盘空间，而且随着事实表容量的增大，节省的磁盘空间实际上可以忽略不计。星型模式示意图如图3所示。

　　2 多维OLAP系统的设计与实现

　　根据前面介绍的数据仓库理论以及多维建模技术，本文具体规划和设计了基于HIS的医院多维联机分析系统，以门诊为例概述实现过程(多维OLAP系统的实现目前没有标准的过程方法)，本文只是探讨了各个实现的标准步骤。

　　2.1 确定业务过程

　　业务处理过程是在机构中进行的，一般都由源数据收集系统提供支持的自然业务活动,如HIS中的挂号、处方、医嘱等。确定业务过程的关键在于分解和梳理。在医院业务流程中，比如门诊，应该将挂号和处方分离为两个相关联的业务过程，而不是作为一个整体。这种划分一方面使业务的流程清晰，事实表的粒度更小，从而能够应付未来各种层次上的分析;另一方面可以减少数据的冗余量。但分离也对维度的一致性提出了严格要求。为了以后能进行跨业务过程的分析，如分析医生某个月所开单据的平均费用，共享维度必须满足一致性条件才能进行集成。处方业务细化方案如图4所示。

　　2.2 确立多维模型

　　针对业务过程，要创建多维模型来反映这种业务。可依次分为三个步骤：定义业务过程的粒度、选定多维模型的维度和确定多维模型的事实表。粒度定义意味着对各事实表行实际代表的内容给出明确的说明，这是建模的基准，它反映了事实表的实际意义。开发多维模型是一个迭代过程，可能要在业务用户需求和选定的源文件细节之间反复切磋。要从用户角度分析如何看待业务，应该用一组在每个度量上下文中取单一值而代表了所有可能情况的丰富描述，将事实表装扮起来，用于形成每个事实表行的数字型事实。事实的确定可以通过回答“要对什么内容进行评测”这个问题来进行，明显属于不同粒度的事实必须放在单独的事实表中。本系统选择星型模式作为多维模型的架构。

　　2.3 多维模型的物理实现

　　维度建模的最终方案成为物理设计和实现的起点。首先要确定各个维度和事实表的数据源。为保证数据集市的质量，数据进入数据集市前应进行细致而具体的数据转换工作，数据的验证和清理都在这个环节完成。建设数据仓库的一大挑战就是在构建数据仓库之后的数据装入工作。它一般占整个系统60%～80%的建设时间。在数据进入数据仓库之前需要经过提取、校验、清理、转换和迁移这五个阶段。完成数据装入工作后，需针对数据仓库的增长和演变做准备，确定数据仓库维护和增长的方案。

　　2.4 多维模型的客户端实现

　　数据展示环节是进行数据组织、存储并向用户、报表撰写和其他分析型应用提供查询操作的场所。后台数据聚集环节是用户接触不到的，这样一来，展示环节就成为业务群体眼中的数据仓库，它是业务群体通过数据存取工具所看到和接触的一切[1]。

　　在客户端分析工具的选取上，系统依据不同使用环境而有不同的选择。针对内部局域网环境下，安全性要求较低，而分析能力要求更强的情况，系统选用数据透视表服务和Excel工具，它具有丰富的图形化表示;在Internet环境下，安全和保密性要求较高，系统则采用基于ADO MD的Web 应用程序作为分析工具。实践表明，这种选择带来了安全性和灵活性。图5是分析结果示意图。

　　本文针对医院HIS系统的现状，尝试一种利用数据仓库与OLAP技术对海量数据进行分析的新方案，以解决医院管理的辅助决策问题。系统采用数据仓库总线架构形式，保证了系统的可行性与可扩展性;在客户端工具选择上则根据应用环境的划分策略，这是一种有益尝试。为了更好地支持辅助决策，系统应该引进数据挖掘手段，这也是本系统下一步的目标之一。

　　参考文献

　　[1] 张文君,胡淑涛,张磊,等.OLAP技术在医院决策支持系统中的应用. 医院数字化, 2005，(12).

　　[2] KIMBALL R, ROSS M著.数据仓库工具箱.谭明金译.北京：电子工业出版社，2003.

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。