金华市中心医院

1、金华市中心医院金华市中心医院 医院管理数据分析与决策支持系统医院管理数据分析与决策支持系统（二期）招标需求（二期）招标需求目目 录录第第 1 章章项目背景项目背景.4第第 2 章章需求分析需求分析.52.1项目总体需求描述 .52.1.1需求范围.52.1.2普遍性需求.62.1.3部门重点需求.72.1.4数据来源分析.92.2业务需求 .102.2.1总体业务架构.102.2.2实现方式.102.2.3功能性需求.112.2.4非功能性需求.15第第 3 章章项目目标及内容项目目标及内容.173.1项目目标 .173.1.1总体建设目标.173.1.2原则.193.1.3重点目标.213.

2、2项目内容 .223.2.1一期项目拓展维护.223.2.2新增指标管理.233.2.3系统管理.29第第 4 章章技术方案技术方案.314.1总体架构概览 .314.2架构要求 .314.3逻辑运营架构 .324.4物理运营架构 .374.5移动端支持 .374.6系统备份与恢复 .38第第 5 章章工期及实施计划工期及实施计划.39第第 1 章章项目背景项目背景我院在 IBM 承建的 BI 一期系统上线后，对数据分析的需求越来越多，在质量控制，临床业务分析等需求也提出了更高的要求，BI 项目对医院后期的决策支持也越来越重要，因此，我院需要在一期项目基础上，逐步将 BI 系统建设成为我院核心

3、的决策支持中心。项目一期在数据采集和分析方面已经打下了一定的基础，但还不足以支撑全院的数据分析，部分新系统的投入使用，也没有将数据整合到一期的系统中，同时，在数据分析层面，目前也比较单一，提供了报表和简单的 OLAP 分析，没有针对移动端的应用，不方便使用者随时随地地获取必要的数据。因此，我院将投入 BI 二期建设，以便将 BI 项目更进一步，使医院的决策分析能够获取实时有效的数据，从而可以进行全方位的分析，让医院的发展能够借助信息化的力量稳步前进。第第 2 章章需求分析需求分析2.1 项目总体项目总体需求描述需求描述本项目将充分利用金华中心医院现有数据源的信息和数据，建立统一的决策分析管理平

4、台；实现对医院总体运营按财务、门诊、住院、药品、耗材、设备、人力等不同主题，多维度进行分析；本着规范化与灵活性相结合的原则，设定不同的使用权限（组织和人员） ，灵活查询和分析，实现对医疗服务、研究、教学全方位的整合监控，提供决策支持。.1 需求范围需求范围BI 数据仓库系统的建设是一个系统工程，不能一蹴而就，应该循序渐进，借鉴业界数据仓库建设的实践经验，采用“大处着眼、小处入手、快速扩展”的策略，该项目的实施将循序渐进、分期实施。从所有采集的报表及数据，借鉴行业的项目经验，结合访谈需求，归纳出BI 的总体需求，根据业务需求，并结合一期已经实施的部分，本期核心的地项目范围主要有以

5、下部分：OLAP 分析增加对医院运营信息的整合和综合查询KPI 展现增加对院领导及各部门关注的关键运营指标，提供直观可视化展现固定报表增加部分业务需要的报表，能够汇总医院不同的数据 仪表盘 增加对管理层所关注的关键指标做定制展示移动应用 增加对移动端的应用支持.2 普遍性需求普遍性需求1. 需要对数据不同粒度的分析各部门已经不满足于汇总性的数据， “不仅知其然，还知其所以然” ，强烈地需要了解更详细的数据，特别是在需要了解具体的业务原因时尤为强烈。例如：医务处需要对门诊挂号量细化到小时粒度。2. 需要对数据不同维度的分析目前的报表基本上是二维报表，不能提供对一个业务问题不同角度

6、的观察，现在各部门都希望深入地了解业务，从不同的维度对业务进行交叉分析。目前在业务系统中提供维度的信息不全，如诊断。3. 报表的时效性需要提高由于许多报表的数据来源于不同部门和不同的系统，在收集来数据后还需要进行手工的整理和计算，往往过了 1-2 个月，才能到达领导手中。有的部门只能看到季报，对了解业务状况和决策产生很大影响。4. 报表的准确性需要提高许多部门的报表数据来源于各部门，统计口径不一致，手工处理较多，由于处理人员的技能不同或疏漏，很可能造成数据错误。发现错误后，再返工修改，又带来时效性问题。5. 灵活方便地分析功能分管领导、卫生部、统计局和各部门等要求提供的数据往往不一样的，而且时

7、间要求高，需要时就去提取。并且，需要分析的指标也是动态变化的，希望能提供灵活地分析手段。6. 数据共享目前有部分数据仍然分散在各个部门，数据就像在一个个孤岛中，部门间获取对方信息也很麻烦，甚至无法获取。希望数据仓库建成，可方便获取分析所需的基础数据。7. 数据质量目前数据质量还达不到要求。质量问题主要是分部门本身录入的问题如人为理解不同、误操作，受各因素影响等原因造成的。基础数据的正确性、真实性直接影响到分析结果的可信度。.3 部门重点需求部门重点需求部门部门业务要点业务要点分析重点分析重点项目阶段项目阶段院领导目前最迫切的是完善医疗服务财务运营分析门诊业务分析住院业务分析病人

8、病种费用分析药品库存进出量分析（含血库）科室设备使用情况分析设备报废情况分析耗材使用情况分析（含高值耗材）人力成本分析人力效率分析财务处特需住院难区分资产负债分析收入支出分析人力成本分析医疗机构基本数字及财务分析（门诊、住院、药品、设备、耗材、人力相关财务数据）科研经费分析教学经费分析财务核算分析医务处节假日无法标识门诊量分析住院工作量分析门诊住院效率分析手术情况分析病房床位分析辅助检查工作量统计控感办数据均需手工输入，跨系统无法综合性分析 院感情况分析感染费用分析手术感染情况分析耐药性情况分析器械不良事件监控药剂科所需数据系统中都有，难以应对临时性统计需求药品库存财务分析 药品价格变动分析药

9、品库存业务分析药品使用模式分析用药量变化因素分析设备处数据是动态变化，时点数据统计较为困难设备库存分析设备使用状况分析设备预算管理分析设备采购流程分析设备报废管理分析高值耗材分析设备维修情况分析设备经济效益分析供应科耗材成本分摊规则较难定位耗材财务分析耗材管理情况分析耗材使用排名分析基数调研分析供应商付款情况分析固定资产使用情况分析放射科与临床数据的关联不够设备费用分析设备使用量分析工作效率分析护理部基础数据无系统支持，靠手工记录护理人员配置分析护理人员工作量分析护理人员工作质量考核物品消耗管理薪酬奖金管理教学科研管理病人相关管理人事处所有报表均为手工制作人力成本分析人员构成分析岗位设置分析绩

10、效考核分析职称评价体系分析运营处单病种费用分析住院业务质量分析全成本核算分析改革办原始数据质量存在问题病房收入分析门诊收入分析消耗相关分析手术费用分析住院日费用趋势分析.4 数据来源分析数据来源分析根据对项目业务需求范围的建议，结合医院现有数据情况，一期系统本身已经对部分系统进行了数据抽取和清洗，但由于医院业务在不断改进，部分业务系统进行了重新建设，部分业务系统进行了改造，因此本期涉及的源系统 将涵盖一期源系统，同时也将增加部分系统，初步统计将设计如下系统：门急诊 HIS住院 HISHRP电子病历（部分）病案首页人事系统药物不良反应记录电子病历检验信息系统捷达图文报告系统手术排

11、程系统手术麻醉信息系统病理信息系统PACS/RIS内窥镜/超声/心电血库预约中心2.2 业务需求业务需求.1 总体业务架构总体业务架构系统架构组成如图所示，按照目前数据基础状况及业务需求的紧迫性要求分阶段实现。.2 实现方式实现方式根据业务需求中提出的操作、展示等要求，目标系统需要通过以下几种方式加以实现：1、多维分析2、固定报表3、KPI 展现4、仪表盘5、移动端OLAP 是 On-Line Analytical Process（在线分析处理）一种即时分析工具。利用 OLAP 分析，分析人员、管理人员能够针对同一个主题，根据已经设计好的分析维度与分析内容做任意

12、组合的交叉分析，选取需要的分析维度与分析内容产生特定的分析，从多个角度对数据进行分析，从而快速、交互地得出经营管理所需的分析结论。它的技术核心是“维”的概念，因此，OLAP 也被称为多维数据分析。OLAP 分析模块是医院 BI 系统的主要数据展现和分析手段，用户通过浏览器，快速访问各种可能的信息视图，很容易地由不同的分析指标测量值，做非常快速与互动的摘要整理分析，洞察数据深处蕴涵的规律，掌握隐于其中的规律。OLAP 多维分析包括分析维度和分析指标两个重要要素。对各项分析主题进行分析时，要针对某些分析的角度或视点去进行观察，这些分析的角度或是视点，即分析维度需要在二期实现中多方位实现，项目需要的

13、维度如下：员工维度：如年龄层、性别、职称、学历等时间维度：如年、季、月、日、时段等 组织维度：如总院、学科、部门、科室、病房.等药品维度：如药品大类、单种药品等 项目本期大部分的多维分析主题都共享这些分析维度，在系统上线稳定运转一段时间后，可以根据业务需要进行调整。.3 功能性需求功能性需求根据医院数据仓库的总体需求，结合数据仓库分析技术能力，可以将重心医院数据仓库的实现分为关键业务指标展示和多维分析两种方式。关键业务指标展示采用图表结合的方式，主要面向管理层和决策支持人员，对业务关注的关键业务指标进行综合分析，包括文字方式、占比分析、预警分析、历史趋势分析等。多维分析主要面向

14、决策和运行管理人员，采用面向业务主题的方式组织，方便业务人员根据实际业务要求灵活的组织分析指标、分析维度，能够动态生成分析图表，并可以对图表的样式进行调整。除了展示关键业务指标和多维分析以外，系统还提供全面的系统管理接口，包括，用户管理、权限管理、用户日志管理以及系统帮助等。 KPI 展示实现展示实现关键业务指标分析主要为管理层提供当前业务运行情况的总体分析和概览，对关键业务指标的当前数据进行展示，并计算累计量，与计划量进行比较、与上期量进行比较。如下图所示，可以直接选择关注的关键业务指标查看具体的数据及比较分析情况，采用图形和表格方式进行展示。 多维分析实现多维分析实现业务主题多维分析主要面

15、向业务人员的数据分析要求而提供的一种数据分析工具，业务人员可灵活地选择和显示数据，支持数据的下钻、上钻等操作和动态变更表、图、曲线的显示形式。其中，业务主题是指面向业务的一组业务指标的集合，比如人员构成分析就是从编制、职级、工作性质、部门等不同维度，对医院的人员构成，如在职员工数、平均年龄以及离职率进行多维分析；多维分析是指按照预先设定的分析角度，对指标进行分析，比如机构、时间、职称、学历、年龄段等。所谓数据上钻、下钻，是指可以在不同的层次上对数据进行查看分析，比如可以查看某个科室、在某个岗位上人员的学历构成是怎样的。 权限管理权限管理角色管理模块是门户系统的核心模块，通过为角色分配权限和维度

16、限制了扮演这个角色的用户所能够涉及的系统内容和用户动作的应用范围，如图. 角色权限管理示例。它有以下的几个功能：角色信息管理、角色权限管理、新增角色和删除角色。图 角色权限管理示例 角色信息管理角色信息管理角色的信息管理包括，对于角色层级的管理以及对于角色的基本信息的管理，如名称、描述、上级管理单位以及是否为管理员，如下图： 角色权限管理角色权限管理角色的权限管理涉及到 2 个主要的方面：模块权限管理、维度授权管理。模块授权管理对于用户能够访问的系统内容进行限制，既当用户登陆后能访问的模块功能。维度的限制控制了用户可以访问的内容的宽度，比如地域、机构等等。为角色分配权限的过程如下图示例：图 用

17、户维度管理 新增角色新增角色新增角色的过程包括，为角色设定基本信息，为角色分配相关权限，以及为角色分配维度，在新增一个角色时数据库会将角色的基本信息、权限以及维度记录在不同的表中，如下图示例：图 新增角色 删除角色删除角色删除角色时，如果数据库中存在使用这个角色的用户，那么系统将不允许删除操作，需要将相关用户的角色重置为其他的角色，之后，数据库才会先将这个角色的权限以及维度从相关表中删除，之后才从角色表中删除这个角色。.4 非功能性需求非功能性需求 用户界面需求用户界面需求方便操作，提供友好界面，特别是在移动端，要能够及时便利地操作。 产品质量需求产品质量需求主要质量属性主要质

18、量属性详细要求详细要求正确性正确性系统能保证业务数据处理正确，并保持与其他系统的数据一致可靠性可靠性系统保证在运行期间安全可靠。对重要数据具有备份和恢复机制。对系统异常情况处理具有容错功能。具有全套的异常情况应急处理方案和措施。性能，效率性能，效率在满足系统运行的软、硬件以及网络性能要求的前提下：KPI 展示部分：查询命令提交后结果返回平均不超过 20秒钟。统计分析部分：不超过 120 秒。易用性易用性操作界面优化，业务处理逻辑合理安全性安全性 确保本系统不被非法入侵; 确保系统内信息通过网络传输时不会被窃取和修改; 确保系统使用者的身份不被盗用，只有认证用户才能登录本系统; 由权限机制保证的

19、访问控制能保证不同级用户对不同资源的使用; 确保系统敏感数据的安全。可扩展性可扩展性数据库的设计应考虑可扩充性，以适应今后业务发展的需要。系统设计中对数据采集的设计应考虑对新增数据源的支持。兼容性兼容性基于 JAVA 平台和 J2EE 体系结构，但可以运行在各种操作系统。能适应多种机型。系统封装性系统封装性本系统自成体系。对外提供与其他系统联网的接口。尽量减少对其他业务系统的依赖。可维护性可维护性在程序的开发过程中，应遵循结构化的程序设计原则，设立运行日志，加强系统的可维护性 系统安全设计需求系统安全设计需求本期系统设计必须符合行内计算机安全管理规范。保证以下安全点：主机系统安全：确保本系统不

20、被非法入侵；网络安全：确保系统内信息通过网络传输时不会被窃取和修改；用户身份合法性：确保系统使用者的身份不被盗用，只有认证用户才能登录本系统；用户权限控制：由权限机制保证的访问控制能保证不同级用户对不同资源的使用；关键数据安全：确保系统敏感数据的安全。第第 3 章章项目目标及内容项目目标及内容3.1 项目目标项目目标在完成了大量基础业务应用系统的建设后，金华市中心医院的业务发展战略已从建设省内高水平的市级医院，发展至以项目建设带动学科发展和人才培养、以学科建设促进医院发展；提高医院管理效率和效益，增强医院竞争实力；注重规划与建设，坚持可持续发展；创新医疗模式，整合区域社区医疗，实现共同发展；最

21、终打造浙中一流医院，因此金华市中心医院的信息化建设也面临着转型和升级，才能更好地为医院战略提供支持。因此，根据我医院运营管理、绩效考核与业务流程优化的需求，提出了如下项目建设目标。.1 总体建设目标总体建设目标在医院已有应用软件基础之上，建立面向医院管理的数据分析和决策支持平台则成为金华市中心医院数字化医院建设中不可缺少、也是亟待加强的一环，其主要目的是以计划、组织、监测、控制、评价、预测和决策等各类管理活动中对信息的需求为出发点，通过对医院的门诊、住院流程以及物流、财务方面的运营数据等进行综合分析，通过商业智能的技术手段从高速增长数据中获取有价值的信息，对其进行归纳、梳理和设

22、计，开发建立一个能满足医院各级管理者和决策者对医院经营、运作的监控和决策分析需求的综合商业智能（Business Intelligence, BI）解决方案，为医院运营管理、绩效考核与业务流程优化提供数据分析和决策支持，并最终提升医院自身的管理，提升医院对政府与相关机构监管的合规性，加强医院以病人为中心的服务理念，促进医院各类病人的满意度和管理信息的再利用。项目应用范围：根据医院运营管理、绩效考核与业务流程优化的需求，本项目将逐步扩大其数据收集和决策支持所设计业务及职能部门的范围，包括：门诊、住院、医技、检查、检验、药品、护理、质控、教学、科研、统计、物资、财务、后勤、病患等部门，并为其提供各

23、类动态运营监控、财务分析、绩效考核、医院信息报表、决策趋势分析等决策支持情报。总体功能要求：该项目应用先进的数据仓库、商业智能、数据分析与挖掘等信息技术，并应用成熟的项目设计及实施的方法论，将现有HIS、LIS、PACS、资产管理系统等多种业务和管理系统的数据进行数据的清洗转换加载 (Extract，Transform，Load，ETL)、建立医院综合数据仓库 (Data Warehouse，DW)、并应用联机业务处理 (On-Line Transaction Processing，OLAP)技术提供多维数据立方体（Multi-Dimensional Cube）分析，以及采用大规模数据分析、数

24、理统计及数据挖掘等技术，以生动友好的界面形式展现数据分布特征，发现数据中的显性或隐性的规律和知识，实现医院对业务和管理状态的监督、追踪、评价、预测，为数字化医院的科学管理和科学决策提供有价值的信息资源；软件产品要求基于 Web 方式，不需要第三方授权，并支持 HL7/HL7 CDA、ICD-10 等相关医学信息标准规范，能够提供数据查询、统计、汇总及分析等功能，并建立各种分析和决策数学模型，开展跟踪预测，为医院管理和决策提供可信度高的数据依据和数据分析结果。此外，作为该项目的解决方案提供商，我们将提供包括项目管理、风险控制、设计、开发、实施、维护等服务，以及相适应的基础平台软件于一体化的综合解

25、决方案，并能够适应医院现有环境和技术框架，提供二次定制化开发接口及知识技能转移等服务，最终帮助医院打造能够提高医院运营效率，改善治疗效果和病人的满意度的医院管理商业智能综合解决方案。通过前期需求调研和项目规划，本项目将包含以下四大建设内容：(一)建立涵盖医院主要应用系统的数据抽取清洗整合方案，定义数据抽取及整合规则，通过定义完整、统一的数据标准，建立和完善标准的统计指标和统计口径，促进医院标准数据集建设，通过数据建模、数据治理、数据清洗等手段持续提高数据质量为综合数据仓库提供保障。(二)建立医院综合数据仓库：通过数据抽取清洗整层，收集包括医院运营管理和病人信息等方面的基础数据，并根据运营监控、

26、绩效考核、流程优化的决策支持分析需求，建立相应的企业级数据仓库。(三)建立个性化可视化的商业智能展现层：根据各类决策支持分析需求，建立包含固定报表、多维分析、管理仪表盘和专题分析的多种商业智能展现。(四)建立面向运营监控、绩效考核、流程优化的综合商业智能分析目标体系：其中，运营监控将包含质量、效率、成本、收入等八大主题的数据分析中心：帮助医院提高效率、质量，优化运营，精细化管理、降低成本，对医院运营进行监测，帮助医院最大限度地降低风险。包括数据与指标集标准化定义、流程改进、变革管理，最终改进商业智能的质量与效果。此外，本项目还将通过对项目整体架构扩展性的把控，做到不仅仅是让用户看到信息，事后分

27、析，还可以集成其它的统计软件，如 SPSS，为未来实现基于预测分析和仿真的医院运营优化决策提供数据基础。预期效果：本项目希望通过以上四大目标的建设，实现以下金华市中心医院管理模式的三大转变：(一)实现医院管理从洞察力到执行力的转变，即通过商业发现一个问题，系统自动通知到某个负责人，有人进行修正，最终解决问题，实现完整的闭环管理，(二)实现医院管理的持续加强和微观管理，即通过对应用系统中的数据积累进行商业智能化，实现以下管理模式的转变：1） 从经验管理到数据支持下的流程管理；2） 从记录交易数据到形成控制、分析、管理的决策支持3） 从业务数据分散不一致到集中和治理4） 从粗放手工化的管理手段到精

28、细化、微观化、自动化的管理手段(三)帮助医院信息部门初步实现从信息系统提供者到决策支持辅助者的转变，称为医院经营决策产生的出发点和效果反馈点。.2 原则原则为满足金华市中心医院对数据分析和经营决策的需求，并构建一个一个可靠、标准、开放、可扩展的商业智能系统平台，即满足近期医院强化管理和业务规模，也着眼于未来医院战略发展，同时为医院打造性价比最优的面向医院管理的数据分析和决策支持平台，本项目将遵循以下的项目建设原则：(一)整体规划：任何一个信息系统的建设都不可能是一蹴而就，商业智能系统不同于以往面向业务流程的应用系统，这样一个面向分析的的系统，涉及到医院从上至下方方面面的用户，涉

29、及到流程的梳理、数据的治理、整合、平台的搭建、软硬件的规划等等，更需要做一个整体的规划， ，才能为后续的建设指明道路和打下基础。(二)分步实施：面向管理的决策支持系统的建设是一个长期的过程，是随着医院信息化广度、深度的发展以及需求的扩展，逐步建设的，需要分成多个阶段来完成。因此我们要在总体规划的指导下，将整个过程科学地划分成多个实施阶段，设立每个阶段不同的里程碑，逐步完成医院商业智能的全面建设。(三)前瞻性：医院商业智能建设计划将是一个分阶段分重点持续完善的过程，因此在进行软硬件规划以及系统建设时应具有一定的前瞻性，要考虑到三四年后技术的发展水平和成熟程度。(四)先进性和超前性：紧跟国内、外先

30、进的相关软件技术、信息技术，并结合医院的实际情况，制定科学适用的技术方案，确保系统在较长时期内能够满足医院数据分析、挖掘的需要，最大限度地保证医院的投资回报率，避免造成不必要的浪费。(五)实用性：BI 系统的建设应以计划、组织、监测、控制、评价、预测和决策等各类管理活动中对信息的需求为出发点，依托医院在各项业务活动中产生的数据，对其进行梳理、归纳和整合，开发建立一个能真正满足医院决策者和各级管理者对医院运营全面监控和分析的数据分析和决策支持系统。(六)可扩展性和开放性：BI 建设将一步步扩展数据分析的范围和深度，包括面向、整合更多来源的数据，包括和其它第三方系统集成，比如企业门户，包括跨平台的

31、应用等等，且扩展将不影响原先的建设。系统在数据通信协议、数据标准、数据仓库系统、数据挖掘模型导入、界面开发、接口设计等方面应采用开放性设计。(七)标准化和规范化：BI 系统的数据模型符合行业信息模型，并根据医院的实际情况和国内外产品的优点进行必要的扩充，满足医院的需要，同时提供标准化的对外接口。(八)安全性和保密性：BI 系统的建设面对医院各种数据，医院信息系统数据的安全性和保密性必须严格遵循相关信息安全标准，切实保证在系统建设的各个环节均能最大限度保障信息安全。系统的设计也将重视信息的安全性和用户的权限控制。.3 重点重点目标目标面向医院管理的数据分析和决策支持平台项目，其在

32、规划、设计、实施过程中既面临像其它行业建立商业智能系统一样的项目重点与难点，也具有通过 BI 强化医院管理时所面临的独特挑战，具体包括：(一)医院管理性需求的收集与归纳：在面向管理的商业智能解决方案建设过程中，很多时候业务部门不知道自己需要什么数据，提不出自己的分析目标，大都还停留在传统的医院管理模式中，关注门诊量、住院量、手术量等表面数据，使得项目实施后与其理想化的预期存在较大差距，需要引导业务部门对需求进行思考，提出准确的数据及 BI 需求。(二)数据质量问题：医院的基础应用系统（如 HIS/LIS/PACS 等）是为了满足医院日常业务运转的需要而设计的，因此，往往会忽略从运营管理的角度对

33、业务数据的真实与完整性提出一定的要求，也会忽略了很多面向管理决策支持时必需的原始数据；特别是针对金华市中心医院目前已有的基础应用较多的现状，这些基础应用未必能够提供足够细化力度、满足各类维度模型的原始数据，因此如何通过数据治理（Data Governance）将医院运维管控的管理模型和绩效指标体系（KPIs） 与数据模型和数据质量问题的交叉分析，确立基础应用数据的抽取规则与质量控制指标，建立涵盖主要应用系统的数据抽取及整合规则，通过定义完整、统一的数据标准，建立和完善标准的统计指标和统计口径，为未来丰富和完善医院运行基础应用提供需求和规划就成为本项目的重点和难点。(三)如何通过项目规划和业务场

34、景选择，确立分阶段分重点的系统建设目标：通过建立医院商业智能解决方案可以实现从基础应用中抽取和整合面向医院经营决策分析的数据，并通过数据仓库和多维分析等手段实现对这些数据的二次利用，为改善医院的管理提供帮助，但面对医院各级领导，如何从数据中获得洞察力，把数据变成执行力，特别是确立那些商业智能的应用场景则称为整体方案建设内容的关键点，例如针对门诊的管理，如何通过对病人门诊诊疗时间和步骤的分析，使入院登记/门急诊挂号/收费的时候变得更加便捷? 又如面向科研与教学，如何利用临床数据支持科研和教学，又如何把科研成果应用到临床和教学，如何识别和总结最佳临床实践？ 如何提供预防和循症治疗? 能够从病人的治

35、疗过程学习到什么? 针对这些场景的选择，本建设方案将在需求调研的过程中，通过场景假设和效果模拟方式与医院各级领导细化和确立各类分析目标的明细及优先级别，最终建立确立分阶段分重点的系统建设目标。(四)建立企业数据仓库的逻辑模型和物理模型：金华市中心医院的 BI 系统，是随着医院运营发展不断完善和加强的，所以建立有扩展性的企业数据仓库是必须的，所以，如何建立企业数据仓库的逻辑模型和物理模型，使本次项目的重点和难点。(五)建立移动应用：金华市中心医院的 BI 系统一期，已经完成了基础的系统建设，但是随着医院运营发展不断完善和加强，需要扩展应用得体系，在移动应用建设上要求能够将展示与分析部分拓展到各类

36、移动载体。(六)对一期项目维护与加强：需要完全理解金华市中心医院的 BI 系统一期的建设成果，同时能够对一期项目进行深入维护，保障在项目正常运营的基础上合理扩充和完善。3.2 项目内容项目内容.1 一期项目拓展维护一期项目拓展维护 医院运营监控中心医院运营监控中心 需要针对一期系统已经完成的业务收入、业务成本、行政运营收支等业务进行合理调整，并确保其正常运行；耗材财务与业务分析耗材财务与业务分析需要针对一期系统已经完成的耗材管理、耗材财务、耗材使用等业务进行合理调整，并确保其正常运行；药品财务与

37、业务分析药品财务与业务分析需要针对一期系统已经完成的药品管理、药品财务、药品使用等业务进行合理调整，并确保其正常运行；领导决策支持领导决策支持需要针对一期系统已经完成的财务运营、全院收支、医院管理损益、医院资产负债、医院现金流量等业务进行合理调整，并确保其正常运行；临床运营指标分析临床运营指标分析需要针对一期系统已经完成的临床运营相关业务进行合理调整并扩充临床分析，并确保其正常运行；人力资源分析人力资源分析 需要针对一期系统已经完成的人员构成、人力成本、人员配置、与医院运营相关的人力资源资质等业务进行合理调整，

38、并确保其正常运行；科室统计分析科室统计分析需要针对一期系统已经完成的科室管理、费用、业务效率指标等业务进行合理调整，并确保其正常运行；绩效管理支持绩效管理支持需要针对一期系统已经完成的绩效指标分析等业务进行合理调整，并确保其正常运行；.2 新增指标管理新增指标管理在本期项目中将对以下不同维度的指标进行整合并融入到系统中。客户维度 门急诊病人分布（来源、身份、科室、年龄） 在院病人构成（地区、身份、科室、病种、年龄） 出院病人构成（地区、身份、科室、病种、年龄） 外地病人就诊科室、病种 病人入院途径分析门诊总人次门诊城镇职工

39、基本医疗保险人次门诊城镇居民基本医疗保险人次门诊新型农村合作医疗人次门诊全自费人次年健康体检人次急诊总人次年急诊人次年留观人次初诊、复诊、出院复诊专家号、普通号即日号、预约号各预约模式预约量医保卡病人门诊量退号量、退号率科室病种分析门急诊处方量效率维度门急诊服务人次医生出诊单元医生出诊单元平均门诊量出院患者总人数出院患者城镇职工基本医疗保险人数出院患者城镇居民基本医疗保险人数出院患者新型农村合作医疗人数出院患者全自费人数年住院患者入院例数年住院患者出院例数住院服务人次出院患者平均住院日门诊手术例数年门诊手术例数总手术人次三类手术例数四类手术例数年住院手术例数各类手术平均时间住院手术手术每台日平

40、均例数床位周转次数平均每张床位工作日病床使用率（%）住院实际开放总床日数住院实际占用总床日数出院患者占用总床日数ICU 实际开放总床日数ICU 实际占用总床日数床位急诊留观实际开放床位数质量维度门急诊不合格处方占全部处方比例（%）抗菌药物在门诊处方的比例（%）门急诊使用抗菌药物人次门急诊静脉用药人次抗菌药物处方数/每百张门诊处方（%）注射剂处方数/每百张门诊处方（%）急诊科危重抢救例数急诊科死亡例数电子和非电子方占比分析入出院诊断符合率（%）危重病人抢救成功率（%）出院病人治愈率（%）住院患者总死亡人数住院患者自动出院例数住院手术死亡例数住院危重抢救例数住院危重抢救死亡例数新生儿患者住院死亡率

41、出院患者使用抗菌药物总例数出院患者使用抗菌药物总品种数住院患者抗菌药物使用强度（DDD）I 类切口手术抗菌药物预防使用率（%）发生压疮的出院患者人次医院内跌倒/坠床发生次数出院 31 日内再住院患者人次出院患者医院感染发生例数住院非计划再次手术例数手术相关医院感染总例数恶性肿瘤手术前诊断与术后病理诊断符合例数手术冰冻与石蜡诊断符合例数术中自体输血比例（%）ICU 中与中心静脉置管相关血液感染例数ICU 中使用中心静脉导管病人日数ICU 中与呼吸机相关肺部感染例数ICU 中使用呼吸机病人日数ICU 中与留置导尿管相关泌尿系统感染例数ICUICU 中使用留置导尿管病人日数中药饮片帖均费用（膏方除外

42、）药费收入占医疗总收入比重（%）抗菌药物占西药出库总金额比重（%）常用抗菌药物种类可与提供药敏试验种类比例（%）门诊病种用药分析门诊毒麻药品分析住院病种用药分析住院毒麻药品分析 单病种平均住院天数住院重点疾病总例数住院重点疾病死亡例数住院重点疾病、手术住院重点疾病 2 周与 1 月内再住院例数住院重点疾病平均住院日住院重点疾病平均住院费用住院重点手术总例数住院重点手术死亡例数住院重点手术术后非预期再手术例数住院重点手术平均住院日国内论文数 ISSN论文被引用次数（以中国科技核心期刊发布信息为准）SCI 收录论文数/每百张开放床位承担与完成国家科研课题数/每百张开放床位承担与完成省级科研课题数/

43、每百张开放床位获得国家科研基金额度/每百张开放床位学习科研科研成果（评审前五年）获得省级科研基金额度/每百张开放床位医院病房（区）总数优质护理开展优质护理病房（区）数全院员工总数卫生技术人员数医师数护理人员数医技人数其他维度资源配置医院医用建筑面积.3 系统管理系统管理重新构建分级的系统管理体系，要能够细化到对数据的管控。权限管理权限管理1) 用户种类a) 系统管理员b) 用户组：总院用户组，各分院的用户组，各科室组的用户组c) 个人用户：隶属于某个用户组2) 用户权限a) 系统管理员：该用户具有所有权限，负责为每个分公司调度和运行报表等。b) 部门

44、用户：通过即时运行报表的方式查看本部门相关报表。c) 科室用户：通过即时运行报表的方式查看本科室相关报表。3) 历史报表用户应该能够查看过去生成的报表。例如对月报表，用户应该不仅能够查看本月的报表，也能查看过去的月生成的报表。4) 用户的其他权限成功登录的用户都可以对他所查看或生成的报表进行数据（报表）下载、数据（报表）打印。系统监控系统监控监控系统运行状况，如：CPU 使用率、内存使用状况、IO 吞吐量、硬盘空间状况。该项工作是每日定点检查，当遇到性能问题时，需要重点监测这些数据。系统备份与恢复系统备份与恢复建立完备的数据备份策略。根据

45、所需要的灾难恢复的级别，制定数据备份的时间、数据备份的版本数、数据备份的存放、数据备份的时效性等。制定周密的数据恢复方案也非常关键。确保在发生灾难后，按照事先制定好的方案，快速、准确地恢复数据。日志管理日志管理建立完善的日志管理策略，能够方便灵活的查询日志，并根据日志对系统进行诊断。第第 4 章章技术方案技术方案4.1 总体架构概览总体架构概览 做为医院数据整合服务平台，BI 系统整合了多个应用系统的数据源，提供了一个对医院操作性数据的整合的视图。目前 BI 的数据实时性要求 T+1，即当天（工作日）在 BI 系统看到的数据是前一工作日在业务系统的数据。BI 系统的

46、总体架构如下图所示：BI 总体架构图BI 抽取各个业务系统的数据、然后转换、装载进入 BI 核心数据库的基础层各表，再经过数据整合处理，形成了 BI 的基础数据平台。在此之上，BI 对数据汇总，汇总之后生成多维数据集（PowerCube） 。BI 提供了各种应用，包括报表生成、综合查询分析、仪表盘，这些应用分成阳光用药分析、医保费用分析、日常运营监控及科室目标管理等主题。4.2 架构要求架构要求BI 系统架构需求描述如下：我院面向医院管理的商业智能整体架构包含四大层次结构，以及跨越四大层次结构的三大共享域，其中四大层次包括：数据源层数据源层：在本项目中数据源系统主要包括门诊、住院HIS，LIS

47、，PACS，EMR 系统等；数据抽取转换层数据抽取转换层：通过 Infosphere Data Stage 软件与CognosTransfomer 软件负责从数据源系统抽取数据和转换数据，并将清洗整合好的数据导入到数据存储层，在本系统中数据整合将包括近实时性（Near Real-Time）的数据采集需求和批量数据采集需求；数据存储层数据存储层：包括 DB2 数据仓库、数据集市与 Cognos 多维立方体数据集市。商业智能展现层：商业智能展现层：包括 Cognos 多维分析（Analysis Studio）、即席查询（Query Studio 或 DB2 Client）与报表（Report St

48、udio）、平衡计分卡等集成性应用通过统一整合的分析应用环境提供对外访问服务以及元数据应用和数据挖掘类应用。此外，整个架构中跨越三大层次的共享域（管理型模块）将包括：元数据管理元数据管理；针对整个系统各个环节中的元数据集中存储，统一管理，提供给最终用户/开发者等方便查询；安全管理：安全管理：包括系统安全，网络安全，应用安全，用户认证与权限管理等；系统管理系统管理：包括系统监控，数据清理、备份与恢复，日志管理，数据库管理等；4.3 逻辑运营架构逻辑运营架构我院的系统运营架构主要用于描述系统操作和运行层面的架构，该设计面向于实现非功能性需求，包括：逻辑层次的系统节点和节点之间的连接。节点将可能是未

49、来的硬件系统配置的基本单位，当然，多个节点可以合并到一个硬件系统中，一个节点也可以分布到多一个硬件系统。同时描述每个节点和作用和配置。运营架构的作用包括：审核系统设计，确认 IT 架构设计中已经包括了业务的需求； 划分功能节点，使得每个节点可以独立的配置，不同节点协同完成复杂的功能； 作为性能、可用性和扩展性等非功能性需求的分析基础，确认系统的整体实施可行性和可发展性；确定系统所需的技术、中间件模块和集成架构；支持应用设计人员在前期从实施和管理的角度考虑应用设计；支持初步进行系统基础平台的投资分析；作为设备选择、采购、安装、配置和维护的基础蓝图。整体运营逻辑架构请参见下图。 逻辑运营架构逻辑节

50、点描述如下表所述：节点名称节点名称层次层次节点描述节点描述Web 浏览器节点(Web-Client)接入中心医院用户可通过 Web 浏览器访问业务应用的工作站平台，基于 Web 浏览器，客户可浏览所有的报表并完成全部操作的客户端支持。移动设备端接入支持用户以手机， iPone，iPad 方式接入 ,实现移动 BI。Web 应用访问服务节点应用基于报表、门户、应用等各方面的要求，选用标准的web 应用服务器，便于提高应用的开放性和可扩展性。Web 应用服务节点节点名称节点名称层次层次节点描述节点描述(WEB-APP) 是实现 Web 应用的基础，不但支持用户访问静态Web 页面，同时，还通过 W

51、eb 应用支撑架构，支持其他各种标准的Web 服务,如 J2EE、.Net 等，基于该平台复杂的业务应用，同时，报表和查询软件也需要 Web 应用服务的支撑，实现其 BS 用户访问和管理界面。多维分析及报表应用节点 应用该节点是实现系统前端查询、报表及多维分析功能的核心；该节点支持用户通过 Web 浏览器进行报表查询及多维分析，该节点提供方便易用的界面，以支持非技术用户基于业务需求和业务元数据，构造出查询语句，进行查询；提供对查询的计划功能，并支持分析查询语句；报表发送服务通过该节点，配置需要后台自动生成的报表，调度报表生成作业；数据仓库(DW)存储数据仓库是配置中央数据仓库结构化数据仓储的节

52、点数据库存储的系统节点，是数据仓库系统中最核心的部分。保障数据仓库应用的性能、可用性、可靠性和可扩展性很大程度上要依赖于该节点的合理配置。数据仓库存储将建立在关系型数据库之上。其配置需要考虑以下要求：大数据量批量数据加载与和大数据量的访问需求；数据加载过程中数据表持续可访问的要求；决策支持数据集市存储决策支持数据集市是为了满足 医院领导和各科室主任决策分析的需求，从数据仓库中抽取数据重新组织和计算而产生的数据子集。该节点的配置需要考虑查询性能、可用性、呈现能力、建立和刷新所需时间。运营分析数据集市存储运营分析数据集市是为了满足 医院领导，科室主任，医护人员和信息人员 的需求，从数据仓库中抽取数

53、据重新组织和计算而产生的数据子集。基于第一医院各科室的需求分类，也可以考虑进行细分，例如门诊、住院、手术、医技、物流和财务数据集市。该节点的配置需要考虑查询性能、可用性、呈现能力、建立和刷新节点名称节点名称层次层次节点描述节点描述所需时间。临床分析数据集市存储临床分析数据集市是为了满足医生和科研人员的需求，从数据仓库中抽取数据重新组织和计算而产生的数据子集。该节点的配置需要考虑查询性能、可用性、呈现能力、建立和刷新所需时间。数据集市 -准实时数据集市(NRDM)存储准实时数据集市提供了准实时的数据统计和汇总。因此除了满足集市正常的查询和数据刷新以外，准实时的数据集市需要能够将准实时抽取过来的数

54、据加载进入集市和刷新相应的汇总数据。ETL-DW 节点整合ETL-DW 是将数据从源系统传送到数据仓库（ DW）和在 DW 的各个数据层次之间进行数据处理的过程；对ETL 技术上很关键的要求是保证 ETL 性能能够达到在有限时间窗口限制内完成数据加载和汇总统计，并且对源系统、网络和数据仓库环境的影响最小。数据模型、数据量、当前状态、历史数据需求都会影响ETL 的开发和实现模式；ETL-DM 节点整合ETL-DM 是将数据从源系统或数据仓库（ DW）传送到数据集市（DM）进行数据处理的过程。和ETL-DW 不同的是， ETL-DM 的过程不涉及到 DW 数据进行复杂的转换和整合，而更多的是进行统

55、计，汇总，和聚合的计算过程。此外需要考虑的是如果DM 和DW 是位于一个数据库实例的情况，对于ETL-DM 的过程更多的应当是在数据库内部进行，避免将数据从数据库抽出到ETL 服务器，再导入到数据库的过程。元数据存储和管理节点元数据该节点的目标是实现技术元数据的集中管理和同步，以及支持技术用户对元数据应用；该节点应该能够支持与ETL、数据建模、数据库与报表软件的元数据获取，将各个系统中定义的元数据收节点名称节点名称层次层次节点描述节点描述集到元数据存储中；该节点负责整个元数据的获取和管理过程，同时支持元数据的相关应用；数据备份恢复节点 系统管理数据备份和恢复节点支持对DW，DM 以及原数据存储

56、库中的数据安装备份策略进行数据备份，以保存重要的分析数据，对数据的归档也通过备份功能实现。在需要时，可以将数据恢复至DW 以保障系统可用性或修复数据错误。LDAP 目录服务节点 应用该节点集中存储了系统中用户、系统、功能和业务逻辑等信息，使得应用或用户可以以确定的方式从一个目录系统获取资源信息；该节点使得集中的资源管理成为可能。本项目中对目录服务的使用包括：集中管理系统用户、用户口令；该部分的功能目前是由BI 工具自带的功能组件来提供各源数据相关系统节点源系统中心医院运营分析及决策支持（ BI）系统建设涉及的各种源系统范围根据业务目标确定；源系统数据抽取的原则是不影响或尽可能少影响源系统生产；当多个源系统中存在逻辑定义相同数据时，以原始生成该数据的数据主系统为准。4.4 物理运营架构物理运营架构 物理运营架构物理运营架构说明如下：四台服务器，包括一个 ETL 服务器，一个数据仓库服务器，一个数据集市服务器和一个 HA 服务器；HA 服务器上使用不同的分区用于 ETL 服务器，数据仓库服务器，数据集市服务器的 HA；平时各自使用服务，一旦服务器出现故障则可以托管；两台 PC Server 用于 BI 工具服务器，采用双机备份，所以当一个节点失败时，另外一个可以进行接管；若干台移动终端，在安全架构方案下可以实施获取