医疗数据仓库建设方案.docx

医疗数据仓库建设方案.docx

《医疗数据仓库建设方案.docx》由会员分享，可在线阅读，更多相关《医疗数据仓库建设方案.docx（6页珍藏版）》请在冰豆网上搜索。

医疗数据仓库建设方案

综合医疗系统中的数据仓库解决方案

在医疗服务系统中建立数据仓库是一个不小的挑战，综合大型医疗系统的焦点正从糟糕的医疗配套问题转向立体交叉的医疗管理之中，在提高医疗服务质量的同时又要削减成本，这就需要在医疗程序中消除不必要的环节。

这里我们介绍一下在医疗项目业务开发过程中总结的一些宝贵经验，主要包括建立数据仓库需求，理解医疗系统中的数据仓库，明确开发数据仓库的成本，建立开发小组，以及设计各阶段的任务目标。

1、简介

2.1建立数据仓库需求

2.2确定核心业务问题

20多个主要业务经理参与了需求调查，主要是关于决策支持所需的高层信息。

在此次调查过程中确立了几个关键性的领域，它们是业务实际利益、数据获取、企业文化、领导及无效的进程。

然而，调查小组很快发现，将数据仓库认为是能解决上述所有领域的问题的灵丹妙药等于冒一个天大的风险。

数据仓库仅对数据的获取与保持数据的连续性方面有本质的突破，而再出色的数据入口对改变领导模式、企业文化或医疗基础都无济于事。

调查小组调查的问题集中如下：

1．列出3个你最需要作出的决策，是什么？

2．作出这些决策你需要哪些报表和工具？

3．目前这些报表和工具的优缺点是什么？

4．基于当前的信息，时间、质量或资金对作出一个好的/坏的决策有何影响？

5．什么样的信息/计算/聚合可能提高你制定决策的水平？

6．你运用联机系统进行信息分析的可能性有多大？

7．如果你借助于专门的数据查询，决策制定过程有何变化？

8．为了充分利用信息优势，需要改进哪些日常工作？

9．获取新系统信息的最关键的益处在哪里？

2.3数据源清单和数据源分析

与对管理人员调研同时进行的是定义数据目录，数据目录用于确定哪些参选数据适合进入数据仓库。

目录包括用于IDS之中的312个专用例程的内容及结构的详细信息。

数据清单的主要目的是进行当前数据源与预期信息需求的对比。

数据源清单和管理调研显示了如下主要问题：

●在多个应用中使用同一个主题的数据

●一些应用包括空的数据结构

●系统没有集成，无法自动进行数据的更新、转移和载入，产生数据碎片和数据不一致的现象

●多种多样的和不兼容的数据结构使相似的数据结合起来很困难，有时甚至不可能

●数据从一个系统中出出进进，与数据不一致的问题纠缠在一起

2.4定义侯选主题领域

基于如下条例，可以开发并优化一组潜在主题领域：

●期望利润——通过实施一个主题领域，在患者满意度、出诊收益和运营效率方面，健康系统取得的定量的和定性的利润

●数据裂缝——实施一个主题领域所需数据与可支配数据之间的差异

●复杂程度——为一个特定的主题创建一个有效的设计方案所需的努力

●实施风险——当组织准备充分并具备运营能力，而且所需的系统界面齐全，时间安排得当，广度和深度比例适当时，实施一个特定的主题领域会相对容易一些

2.5选择主题领域

通常，一个具有最大潜在利润，同时风险因素又最少的主题是最好的选择。

有时对业务的深思熟虑会让我们放弃一个显而易见的决策。

另外，你必须时刻牢记在心的还有，如果不存在业务对数据的强烈的需求，那么数据的价值是零。

克里斯蒂安娜健康中心的高层管理者指定了一个指导委员会，这个委员会将担负起选择第一个主题领域的任务。

为了确定最佳的选择，他们列出了潜在主题领域的主要维度的清单，按照期望利润、数据裂缝、复杂程度和实施风险四个类别进行评分，最后计算总分。

基于这个分数卡，指导委员会对各个主题领域进行分析和定级。

当得分最高的三个主题领域被进一步分析时，两个看起来较好的侯选主题领域没能经得起业务实例分析的考验，委员会发现，这两个主题领域存在着不可逾越的数据裂缝，而且组织对所需要进行的变革毫无准备。

于是委员会将目标锁定在排位第三的主题领域上——医师行为报表，因为医师最终对医疗质量负责，并对医疗成本有巨大的影响作用，于是医师业务行为方式自然而然地成为了一个逻辑控制点。

按照一致赞同的规则，委员会进一步论证了将医师行为报表作为第一个主题领域的合理性。

然而，这项决定并没有引起人们充满激情的或持久的支持。

可见，要想成功，对这个初始决策的支持必须来自于最高层管理者。

2.6选择业务出资人

在数据仓库项目中，业务出资人往往提议主题领域应基于一个核心的业务需求。

通常，在我们这种医疗服务情况下，有许多组织对医疗主题怀有极大的热忱。

医师队伍与患者医疗管理共同资助是可以接受的，因为这两家出资人在削减无谓的医疗行为方式以获取最大的出诊收益方面目标是一致的。

3、理解医疗系统数据仓库

在IDS单个业务单元中，基于操作型系统的决策支持应用已经存在了。

管理者会理直气壮地问为什么现存的系统不够用呢，要回答这个问题，需要阐明与数据仓库相关的风险、收益和成本。

首先，考虑我们面临的风险：

●几乎没人理解操作型系统与决策支持系统的差别

●很难将数据集成带来的收益概念化和具体化

●由于静态报表已成为标准，我们的用户很难适应交互式的数据界面

●我们的努力很难在整个项目周期中都得到普遍的支持，这也是值得担心的

接着，我们考虑潜在的收益：

●数据仓库将会提供毫无疑义的数据集成，确保在整个IDS中数据的真实性和一致性

●联机分析处理系统（OLAP）将通过一个生动并且易于使用的界面给高层管理者提供新奇的决策支持透视服务

●运用数据分析预处理包能使业务分析专家迅速发现问题并很快建立解决方案

●对人群和供应商会有更深了解，利于提高医疗管理项目的效率

●常规报表不再需要借助于IT部门的先进的技术服务

●用户能够获得元数据，即关于数据的来源及数据转换方式的信息。

●对数据质量的信心会增强

●将会建立数据标准

●新成立的医师组织能够发展基于信息的文化

这指引我们去分析最后一个因素——成本。

数据仓库项目是昂贵的，保守一点说，数据仓库项目的启动少则1百万美金，多则5百万美金。

为了帮助你更好的理解，我们引入了一个样本项目预算，后来我们发现这个预算过于乐观了。

既然清楚了在实施数据仓库项目过程中会涉及到惊人的风险和成本，就应该明白为什么有必要在一些基本方面对管理者进行培训。

3.1操作型系统与决策支持

虽然医疗服务经常与操作型系统打交道，但对于在整个企业范围内提供决策支持还是经验尚浅。

一个错误的认识是，地区的联机操作系统（OLTP）已经能够提供企业范围的决策支持。

下面几段将总结这两个概念之间的差别。

操作型系统的设计目的在于实现数据的快速存取，任务或小数据集的快速处理。

规范的关系数据库在进行数据的插入、更新和删除操作时能确保数据的完整性，并能优化在多表间进行数据存储的机制。

用于决策支持的统计分析需要平滑的数据以及满足查询的最低粒度级。

决策制定者借助于一些软件工具进行决策，这些软件工具可以划分为报表、数据挖掘/统计和数据浏览几个类别。

报表可以发展成为总结已被充分理解的业务进程和主题的工具。

数据挖掘工具和数据浏览工具使分析人员能够从海量的数据集中察觉业务趋势和发现商机。

数据挖掘工具如同一个巨大的钻取机器，它将运用成千上万的公式法则对数据进行汇总、建模和聚合。

被称为OLAP的数据浏览工具能为分析人员提供聚合的数据和高效的界面，使分析人员能够快速地操纵数据视图和聚合层次。

3.2取得行政通行证

已经选择了主题领域，但是否能通过还模棱两可。

业务分析小组担心的是，对项目理解不深可能会导致在项目未完全开发完毕之前，人们不再拥有激情。

这时要做的事情有两件：

在高层管理者之间宣传数据仓库以加深他们对工具的了解，还要大力强调集成数据源对支持IDS新战略方向的重要性。

3.3OLAP原型

OLAP是基于易于理解和频繁使用的交叉汇总表格的，交叉表格呈立体形式，一个变量表示列，另一个变量表示排，形成矩阵，第三个变量——度量填写在矩阵的各个单元中。

标准的数据分析包括许多专有的交叉表格，它们是理解数据关系的组成部分。

这个多维矩阵称为OLAP数据立方体。

海量数据进入数据立方体需要消耗大量的计算资源，在当前的环境难以得到优化。

当Ewen博士建立了一个包含真实的医疗主题数据的OLAP数据立方体并获得成功时，他明白了这种强大的数据处理工具意味着什么。

数据呈现的是对住房病人和紧急情况下科室的反映的统计，核心是针对未保险的突发事件引起的成本。

数据也通过疾病分类，如长期的和与医疗管理技术相关的。

哮喘、CHF、糖尿病和HIV通常发病率较高，风险成本也很高。

从提出问题到解答问题的间隔时间由数天或数月缩减到几秒钟或几分钟。

我们的用户能够获得数据仓库各个方面的一切数据，用户参与的热情会大大提高，也就会迅速发现更多的商机。

一个重要的发现是未保险和紧急就诊的比率相当高；还有人提出既然我们知道派送救护车医疗要比派送医疗人员花费少，那么更有效的医疗管理将减少医疗成本对贫穷人群的影响。

3.3其它工具

象SPSS8.0和SAS6.0这些统计软件也能提供交叉表格，但应用不是很广。

应用这类软件需要一定的统计知识，而且要求在客户端进行处理。

既然在客户端进行处理，交叉表格所需的数据就被拷贝到用户工作站，在计算资源限制下，运行处理将缓慢地进行。

MicrosoftAccess7.0包含一个容易使用的交叉查询表格，但属于客户端处理，因而象SPSS和SAS一样受计算资源的限制。

SQLServer6.5在计算资源受限方面有所突破，它能够拥有更多的计算资源，但不支持交叉表格查询。

通常，需要写复杂的SQL代码来模拟交叉表格查询，但大多数数据分析人员没有学过写这些代码。

OLAP软件可以摆脱这些限制，提供服务器端处理的针对海量数据集的快速的、交互式的交叉表格视图

3.5OLAP与医疗服务

所有业务都可以按层次分类，惟独药品不可以，因为各种各样的医疗服务相互交叉和重叠。

要驾驭这种复杂的情况，我们需要将药品按医疗主题分组，这样对于每个供应商会有多种解决途径。

临床用户可能需要查看关于整个医疗程序信息的数据。

OLAP工具建立并实施业务分层结构模型，然后将它们与交叉表格汇总相结合。

数据浏览器使用户可以对任意两个类别进行行列组合，然后选择一系列度量在矩阵中汇总。

而且，用户能够在层次之间进行上下钻取，以获得扩展或聚合的数据。

这是一个强有力的信息展示器，它能令用户在标准的、基于代码的统计和查询工具所允许的小片时间内迅速解决一系列问题。

建立OLAP交叉表格数据结构有多种途径，包括按关系数据表存储，创建专用的多维数据结构，以及建立基于需求的虚拟交叉表格。

商业软件既有在客户端处理的应用又有在服务器端处理的应用，目前许多软件还能提供网络接口。

拥有网络接口的服务器端执行软件要比多用户客户端执行的软件廉价，而且能对服务器资源起调节作用，能获得更高的执行效率

4、确数据仓库开发的成本

记住，我们选择的主题领域要求在提高医疗服务的同时又要降低医疗成本，现在，我们为这个主题领域建立一个业务案例。

既然借助于投资回报率（ROI）难以奏效，我们可以根据小组先前进程改进的经验保守地作一些情景假设，然后，我们估计超过5年的成本并将时间延伸直到ROI成为可能。

我们建立了许多情景假设，并从中绘制出项目的盈亏平衡点。

据调查，通过医师业务模式的转变，如利用救护车医疗，能够实现成本躲避。

根据1997财政年度的服务统计，与设施成本相比目标比例成倍增长。

节约的设施成本等于整个数据仓库项目的开发费用。

5、组建开发小组

给数据仓库项目配备人员最重要的一个方面是为项目建立一个坚实的业务核心。

有调查显示，数据仓库由IT部门运作比那些由委托的和商务引导的部门运作失败的几率要大的多。

IT人员是必须的，但决不是项目的主要驱动力。

我们清楚小组的真正灵魂在于那些既掌握数据仓库技术又透析医疗服务进程的人。

我们小组人员组成简述如下：

项目经理是一个业务医师，他通晓信息系统；与他同等重要的是一位项目协作经理，这是一位护理/系统分析师，在医疗服务行业有多年的数据分析经验；小组的第三个成员也是一位护理/系统分析师，他对数据库和网络开发轻车熟路；另外加盟的还有两位咨询师，他们在医疗系统开发方面经验丰富，是数据仓库构建、数据建模、SQL开发和数据转换方面的专家；小组还需要一位系统管理员和一位额外的系统分析员来支持这个项目。

主题领域出资人将资金投入业务进程小组，并从我们的IT部门寻求工程基础框架的支持。

我们意识到我们拥有的人手比数据仓库项目推荐所需的人手要少，幸亏我们的组员能身兼多任，并能通过协调在风险无时不在的开发周期中灵活地适应各种需要。

注意，雇佣那些技能灵活、有多方面才能的人。

6、建立力所能及的目标

我们的目标是建立一种机制来扩大项目支持者的队伍，同时投资又不能大幅度增加。

我们已经将前期努力凝聚在一个选定的主题领域上，并期望它能成为在后续的生命周期中前进的稳固的基石。

即使进行了谨慎的规划，采用了并行的时间表，而且可以参考已有的文档和方法，我们仍意识到我们给自己赋予了一项极具挑战性的任务。

我们非常清楚“建立数据仓库用90天或更少”和“数据仓库是封装的成品”是多么的不切合实际。

请遏止想要跳上乐队花车的冲动，建成数据仓库并能用于决策支持，至少需要9—12个月的时间。

请心平气和地阅读如下的规划指南：

●清晰地描述所有假设，并尽可能地提出问题，以确保指导委员会作出的决策细致周全

●为是否继续实施项目提供明确的决策判断

●每周会面商谈风险及至关重要的发展方向

●尽早处理最艰难的问题以减少影响

●建立前端，然后精选一些评价方法来确定数据仓库的效用

●如果这些度量不能维持一个主题领域，那么就放弃这个主题领域

7、总结：

评价成功

如果你的数据仓库不是由一个重大而且合理的需求驱动的，那么就不值得去投资。

“建立它，他们就会来”的途径是一种缺乏解决方案的技术，它对70%的数据仓库项目失败负有直接的责任。

数据仓库是一种业务工具，它的真正价值只能由业务来决定。

我们为医师行为报表主题领域建立了如下的评价方法：

●项目减少了业务运作的环节了吗？

●是否如经济影响陈述中所料，资源利用减少了？

●用于设计的信息给管理程序带来弊病了吗？

●那个有根有据的案例实施了吗？

●节约成本的方案明确并实现了吗？

过去人们曾进行过许多将决策支持技术转向用户的尝试，然而成功的情况很少，因为那些努力是基于传送的数据能够应用这个假设之上的。

虽然这个意图是无可挑剔的，但它假定一个给定的业务领域能从一个系统的角度充分地理解了自身的目标、需求和进程，进而定义出有用的规则方法；它还假定这个主题领域能象组织一样接受信息、分析信息、交流信息和对信息采取行动。

可以看出，数据仓库要想成功，组织必须放开眼光，从一个文化的角度去斟酌机遇，去发展有创造性的解决方案，并随时准备采取行动以推动所需的变革。