摘要：在促进和规范健康医疗大数据应用发展的形势下，为了有效聚合、分析、管理、利用医疗大数据资源，医院有必要构建医疗大数据平台，为医院的管理、诊疗、科研和教学提供高效支持。本文分享了某全国百强大型三甲医院大数据平台的需求分析、建设方案、技术选型、应用场景等项目建设实战经验，供医院同行参考。

1 建设背景

1.1 政策背景

2015年9月，国务院发布了《国务院关于印发促进大数据发展行动纲要的通知》（以下简称“通知”）。通知指出，构建以人为本、惠及全民的民生服务新体系。围绕服务型政府建设，在健康医疗等领域全面推广大数据应用。

2016年6月国务院出台《关于促进和规范健康医疗大数据应用发展指导意见》（以下简称“意见”），意见指出，健康医疗大数据是国家重要的基础性战略资源，要以保障全体人民健康为出发点，消除“信息孤岛”，建设健康医疗大数据平台，推进健康医疗大数据的共享和应用。

随后几年相继出台的政策，例如：《“健康中国2030”规划纲要》、《关于促进“互联网+医疗健康”发展的意见》、《关于加强三级公立医院绩效考核工作的意见》、《中医药询证能力建设项目实施方案》、《公立医院高质量发展促进行动（2021-2025年）》、《“十四五”国家临床专科能力建设规划》都强调了建设医疗大数据的重要作用。

1.2 医院背景

某三甲医院（以下简称“医院”）是一所融医疗、科研、教学、预防、培训为一体的大型现代化三级甲等医院。总建筑面积43万平方米。医院现有编制床位近3000张，设有42个临床科室、8个医技科室、27个教研室和1个研究所。年门急诊量约350万，每年约为20万住院患者提供医疗服务，并入围“2020年中国医院竞争力顶级医院100强”。

医院近几年获得国家、省、市科研项目几百项，相关科研成果也获得了科技进步奖，医院先后获批设立院士工作站、博士后科研工作站、医学成果转化中心。为了支持医院高标准、严要求、不断技术创新、服务创新的远景，医院迫切希望通过大数据平台的建设，帮助医院更好的进行科研创新和成果转化。

为了促进“健康中国”建设，落实国家“互联网+医疗健康”战略，根据国家卫生健康委《关于进一步推进以电子病历为核心的医疗机构信息化建设工作的通知》要求，2021年国家卫生健康委医院管理研究所对“2020年度电子病历系统功能应用水平分级评价高级别医疗机构结果”进行了公示，我院正式通过电子病历5级乙等测评，标志着信息化水平迈上一个新的台阶。

依托医院成熟的信息化建设水平以及临床应用深度，接下来医院会在信息化建设与临床的结合上继续加强内涵建设，利用信息化手段，建设医疗大数据平台，在惠民、惠医、惠管三方面助力医院的服务能力建设。

运用大数据的分析和挖掘技术，可以在一定层度上帮助医院提高生产力，改进护理水平，增强竞争力。基于医疗大数据平台，可以实现历史医疗数据资源的再利用，并借助大数据的思维和方法进行研究，挖掘数据的价值，实现量变到质变的过程。建设一个高效、稳定运行的医疗大数据平台，可以实现各种医疗数据的共享和交换，让大数据处理更加便捷、快速、贴近用户，有效实现数据的流通和增值，为患者、医务人员、科研人员及管理人员提供服务和协助。因此，医疗大数据平台的建设已成为医院信息化工作的重要方向。

国家卫生计生委统计信息中心为加强卫生标准化的推广与应用，以测促用、以测促改、以测促建，促进各地区、各医疗机构信息化水平的提升和跨机构跨地区互联互通与信息共享，开展了国家医疗健康信息互联互通标准化成熟度测评工作。

2018年8月，国家医政医管局发布《关于进一步以电子病历为核心的医疗机构信息化建设工作通知》，明确要求到2020年，三级医院要实现院内各诊疗环节信息互联互通，达到医院信息互联互通标准化成熟度测评4级水平。根据2020年度参与测评的240家医院结果来看，有30家医院测评结果为五级乙等，175家医院测评结果为四级甲等，33家医院测评结果为四级乙等，2家医院测评结果为三级。

在208家测评结果为四级的医院中，大部分没有建立大数据平台或建设的不够完善。因为在互联互通评价5级乙等及以上标准中，均要求建立“基于大数据的临床科研和决策分析”系统。临床决策支持不等同于知识库，是更偏人工智能的一种应用，比如要能处理非结构化、多维度临床数据，能够根据患者的临床数据推出疑似疾病并自动推荐个性化的诊疗方案。临床决策系统的建设离不开大数据系统的支撑，需要大数据的算法和深度学习技术，满足电子病历信息化分级评级要求，满足新的电子病历评级要求中对数据质量的要求。

在申请电子病历5级乙等测评之前，我院就建立了大数据平台，解决数据决策和质量问题，解决各个业务系统数据格式不一致而导致数据不连通的问题，进一步完善信息化建设。

为了实现互联互通标准化成熟度测评要求，除了大数据系统的建设，医院还需要围绕以下几个方面开展工作：

• （1）全院级应用系统互联互通；
• （2）与外部系统集成互联；
• （3）建立全院级电子病历；
• （4）医院信息数据资源充分利用。

2 需求分析

医疗大数据平台是医院信息化建设的重要组成部分。在促进和规范健康医疗大数据应用发展的形势下，为了有效聚合、分析、管理、利用医疗大数据资源，有必要构建医疗大数据平台，为医院的管理、诊疗、科研和教学提供高效的服务。

2.1 数据量估算

我院年门急诊量近350万人次，出院患者近20万人次，住院手术近8万例。为此全年按照300个工作日，则门急诊日均超11667人次。对于在院患者，按照编制床位数日均3000进行估算。

结构化数据的数据库使用时，需要考虑索引、日志、闪回、表空间使用率、临时表空间、表空间改变、数据库控制文件、数据库系统表空间、碎片空间、磁盘空间使用率低于70%时性能最佳等因素，数据库所需的存储空间按照原始数据量的2-3倍进行估算，本次估算，按照原始数据量的3倍进行配置。按照下表所示，HIS/EMR等结构化数据库所需的存储空间为5.47TB，临床系统结构化数据库存储空间约为3.56TB

非结构化数据和其他数据存储需要考虑文件存储、大数据存储和临床管理决策分析等数据，可以根据HIS/EMR等数据进行推算。文件存储主要为电子病历和电子票据等提供文件存储服务，大数据存储主要用于临床数据、科研数据、学科研究等数据，管理决策分析数据主要为大数据建立数据仓库，用于大数据分析平台数据仓库建设。非结构化数据和其他数据存储主要使用空间约为20.82TB

详细数据量估算详见下表：

2.2 业务需求分析

我院大数据平台的建设主要为临床科研提供服务，同时满足互联互通评价5级乙等及以上标准中对于大数据临床科研和决策分析系统的建设要求。

临床诊疗科研水平是医院发展的生命力，是提升医院整体水平和学科发展建设的基础，我院信息系统现拥有大量的病例资源，将这些病例资源的数据进行挖掘是提高我院科研水平的基本要求。基于我院现有的信息数据构建特色的大数据科研数据中心，为临床科研提供数据查询和数据挖掘的服务，参照循证医学的方法丰富医院临床知识库，将知识库融合到临床一线工作中去，提高临床信息系统的智能化水平，不断提高医院的诊疗水平。

根据公立医院高质量发展要求，科研大数据平台的建设目标着眼于医院学科能力建设和持续发展需求，通过全系统数据整合，完善临床信息系统标准化、前瞻性建设，探索科研模式创新、构建科研新生态，引领医学科研的不断创新与发展。夯实临床全流程智能化管理体系，打通区域数据，实现协同创新，推动成果转化，实现持续发展，共创国际化智慧科研生态体系。

科研数据中心作为科研平台的基础数据来源，将院内历年临床诊疗数据按照科研所需的数据结构和数据格式重新组织、以患者-病历为中心整合数据，利用大数据技术高效、高容错、高稳定等特点，为整体科研平台应用提供可靠的底层数据支持。

大数据平台应采用业界先进的设计理念和成熟的技术路线。架构设计遵循自主可控、安全、高效、开放、稳定的原则，确保整个产品平台的安全性、高效性、易用性、可扩充性和可维护性。

2.3 功能需求分析

大数据平台的功能建设主要需求围绕以下几点：

2.3.1 稳定的大数据平台

基于大数据相关技术和框架，提供稳定、高效的数据采集、数据融合、数据计算、数据挖掘、数据分析和数据治理医疗大数据平台。

2.3.2 多样的大数据采集

支持实时的数据交互，以及非实时的增量数据抽取、全表采集、文件采集等各种数据采集方式；支持日志管理和异常监控。

2.3.3 有效的大数据治理

支持结构化和非结构化数据、集中式和分布式数据的统一建模；支持大数据清洗、脱敏的数据治理；以统一的数据标准对多源异构数据进行归一化处理。建成医院统一的数据资产，形成数据管理质量分析报告，方便医院高效管理医院的数据资产。

2.3.4 丰富的大数据应用

利用大数据中心的大数据资源，对医疗服务、科研管理、医院治理等提供辅助决策支持。

2.3.5 灵活的大数据可视化

提供大数据模型可视化配置，提供大数据分析结构的可视化展示。支持数据管理人员自由配置大数据的相关指标，提供多维度的分析功能。

2.3.6 坚实的大数据安全保障

支持大数据存储、传输、访问等服务的安全保障，对数据进行安全评估，对数据使用进行安全授权，提供数据使用溯源，提供数据隐私保护机制。保证系统处理数据的一致性，保证病人隐私信息和临床数据不被非法入侵和修改伪造，保证数据不因意外情况丢失和损坏。

3 大数据平台建设

3.1 总体架构

医院的大数据平台总体架构包括：数据源层、数据传输层、资源与任务调度层、数据存储层、数据计算层、应用服务层、数据治理层、数据安全与审计层。

图1 大数据平台架构图

3.1.1 数据源层

数据源层主要指医院的大数据平台所覆盖的数据范围。根据医院大数据建设需求，本层的数据范围主要是临床诊疗、与患者相关以及医院管理类有关业务系统的数据。涵盖的业务系统包括：医院信息系统（HIS）、电子病历系统（EMR）、检验系统（LIS）、放射系统（PACS）、病理系统、超声系统、心电系统、手术麻醉系统、移动护理系统、门急诊系统、药品耗材管理系统、病案系统、血透系统、康复系统、医保管理系统、消毒供应管理系统、人事管理系统、财务一体化管理系统（HRP）、医联体转诊系统、互联网医院相关系统等。

医院的大数据平台数据除了来自各个业务系统记录的结果数据（存储在各个业务系统数据库中的），在门诊业务场景下，针对过程性的数据，通过网络流量包解析并进行存储。

3.1.2 数据传输层

数据传输层的功能主要是将业务系统的源数据采集并传输到大数据平台。目前医疗行业普遍使用的数据采集方式有：数据库备份恢复、集成平台、物化视图、数据同步工具（如ogg、canal等）、ETL（数据抽取工具）等，按照数据传输的时效性可以分为T+0（实时）、T+1和T+N等多种模式。

医院的大数据平台采用的是集成平台、数据同步工具和ETL工具混合使用的方式，主要是根据业务系统的数据库类型、业务的重要性等方面进行评估使用，例如静脉用药管理系统的数据库是SQL server，但是表名和字段名均是以中文命名，导致无法使用OGG进行数据同步，但是结合业务的特点（静脉用药配置的业务操作时间相对固定），最终采用ETL工具根据时间戳进行数据抽取。在数据传输的时效性方面、医院大数据平台采用以T+0为主、T+1为辅的方式，结合实时数据的价值体现以及大作业量的可视化报表进行协调优化。

3.1.3 资源与任务调度层

资源与任务调度层通常需要处理的问题包含：资源分配的策略、资源分配的粒度、资源分配的方式和不同任务的调度。进行资源调度管理的目的是为了提高全系统的资源利用率，并使其支持动态调正切分资源，增强系统扩展性。目前常见的资源调度框架有Mesos、YRAN、Coraca、Torca等。

医院大数据平台的资源与任务调度层主要包含:ODS层、DWD层、DWS层和ADS层的ETL作业调度，各种作业消息的调度和计算资源的调度。提供可视化界面进行配置并配合院内消息接口推送给运维工程师。

3.1.4 数据存储层

大数据存储是要解决大数据在物理层面的存储问题，在物理层面上需要构建可靠的分布式文件系统，例如HDFS，提供高可用、高容错的、弹性可配置的、高效低成本的大数据存储技术。

医院的大数据存储层采用的分布式存储系统HDFS和传统的关系型数据库Oracle相结合的方式，两者在应用场景上进行区分。HDFS用于存储未经过清洗加工的海量数据，Oracle数据库用于数据应用层ADS的存储，这种更符合业务习惯，方便可视化展示和业务联动。

3.1.5 数据计算层

大数据平台的数据计算层一般包含：大数据离线计算、大数据实时计算和图形计算。大数据离线计算主要有：大数据分布式计算框架、批处理计算框架和大数据计算资源框架；大数据实时计算主要有：大数据实时计算框架、大数据准实时计算框架和大数据混合计算框架。结合医院现有的实际情况，医院采用的是基于Hadoop架构的分布式混合计算框架。

3.1.6 应用服务层

应用服务层以医院的大数据平台数据中心的数据为基础，建设各种医院大数据平台的基础应用服务临床、患者和管理部门，这些应用包括但不限于：临床数据检索、患者360全息视图、临床科研应用、专病库、科室运营、临床药物试验受试者筛查等。

医院目前基于大数据平台建设的应用包括三大核心数据中心：CDR（临床数据中心）、RDR（科研数据中心）和ODR（运营管理数据中心），其中CDR覆盖了医院95%以上的核心系统，RDR目前围绕临床药物试验展开，ODR以医院药品、耗材、成本等方向进行统筹建设。

本期建设主要以CDR和RDR建设为主。

3.1.7 数据治理层

大数据平台的数据治理层对采集和汇聚的数据进行清洗加工处理，并做标准化整理，主要包括制定数据清洗流程、清洗流程控制、清洗质量控制（质控）、清洗过程管理等。通过规范流程和规则库，基于流程引擎构建统一的、可配置的数据转换、清洗、比对、关联、融合等加工处理过程，对异构、多源、海量的离散数据资源进行加工和生产，生成易于分析利用的、可信度高的、统一标准的、可共享的数据。

3.1.8 数据安全与审计层

医院的大数据平台建设在满足安全需求的前提下，结合《网络安全法》、《数据安全法》、《个人信息保护法》，基于现代信息安全理论，遵循国家和行业标准，采用目前国内外较为先进的信息安全技术，采取有效的安全策略和技术手段，建立覆盖硬件网络、操作系统、数据库、应用软件和管理等各个方面的统一、安全、稳定、高效的信息安全保障体系，确保平台承载业务信息的安全可靠及业务服务的连续且稳定运行。医院的大数据平台采用的是本地化部署方式。

3.2 技术选型

医院大数据平台采用基于Hadoop的平台架构，核心组件包含：

• （1）ZooKeeper：ZooKeeper是Hadoop的分布式协调服务。Hadoop的许多组件都依赖于ZooKeeper，它分布式地运行在多台计算机组成的集群上，为集群提供协调服务。
• （2）Hbase：Hbase是一个列族数据库，适用于海量数据的分析场景。
• （3）Hive：Hive是基于MapReduce的一个数据仓库工具，它使 得用户可以使用简单的类SQL语法实现数据统计处理。
• （4）Sqoop：Sqoop是一个用于解决传统关系型数据库、数据仓库与Hadoop集群之间进行数据导入导出工作的工具。
• （5）Flume：Flume是一个日志收集系统，它支持自定义各类日志数据的采集，并具有对数据进行简单处理的能力。
• （6）Pig：Pig是一种数据分析脚本，用于数据流处理。
• （7）Mahout：数据挖掘算法库Mahout包含在回归、聚类、分类等问题上被广泛使用的数据挖掘算法，可以帮助开发人员便捷地创建智能应用程序。

医院的大数据平台的数据采集和汇聚采用的是服务总线技术、ETL技术、数据同步技术，制定数据采集标准和处理流程。

集成平台选用的是Ensemble，ETL工具主要采用kettle、DATAX和Sqoop，数据同步技术采用的是OGG。

核心业务的数据库部署OGG，OGG是一种基于日志的结构化数据复制软件，能够实现大量交易数据的实时捕捉、变换和投递，实现源数据库与目标数据库的数据同步，保持亚秒级的数据延迟。对于无法通过OGG进行数据库同步的业务系统功能数据库，利用kettle工具基于时间戳的方式定时抽取数据，同时kettle也可以实现数据库初始化的同步，但是随着后期数据量的增大，kettle的同步效率不足。利用DATAX可以很好的解决这个问题，但是DATAX无法做复杂逻辑的ETL，两者配合可以达到不错的效果。

在大数据应用方面，还包括临床科研大数据模型训练。以患者为中心的临床信息系统，在做大数据模型训练时，通常以疾病为中心组织数据结构，识别出医院业务中的关键要素，（例如人、病、干预方法），梳理患者参与过的医疗活动（包括时间、地点、人物、事件和经过结果等），最后按疾病的症状特点和诊疗特点，围绕单个疾病诊断和诊疗的特点，把所有符合条件的病人的医疗事件的过程和结果，匹配到此疾病的诊断和诊疗特点上，构建专科专病分析专题等数据模型。

3.3 硬件配置

3.3.1 硬件配置概述

基于Hadoop的大数据平台运行在通用英特尔X86硬件平台之上，使用英特尔 X86自身存储空间来实现Scale Out。可以显著降低硬件部署成本，只要满足发行版所要求的操作系统和JDK需求即可。

在我院的实际部署过程中，根据Hadoop的具体使用环境进行了合理的硬件配置，充分发挥了每个节点服务器的运行效率。例如在执行MapReduce，特别是在压缩文件上执行，其对CPU的消耗较高，CPU将会成为瓶颈；而在运行HBASE的时候，更多的内存会缓存更多的数据，提高查询吞吐率并缩短响应时间。所以根据应用场景的不同，需要考虑不同的硬件配置。

本期大数据平台，我院主要的设备部署图如下：

主要包括 HP DL580 G10 四路服务器4台，华为RH5885H V5 四路服务器2台，DELL R740两路虚拟化服务器2台。

其中DL580 G10和RH5885H V5物理服务器主要用于组建Hadoop大数据平台的HDFS集群。HDFS是Hadoop的分布式文件系统，用于存储分析和查询所需的数据，可以是结构化数据也可以是非结构化数据。文件按照块进行划分存储在多台机器上，并通过多副本的方式保证高可用。由于Hadoop在软件层面已实现了数据的冗余备份，不必要在硬件层面通过RAID再做冗余。在效率提升方面，Hadoop自身的“优化策略”推荐HDFS数据直接存储到多块物理盘，而不采用RAID，直接使用物理机自身的存储空间。6台物理服务器可以提供192TB的裸容量空间，按照3副本计算，约可以提供64TB的可用存储空间，完全满足现有大数据业务系统数据存储使用并保留了足够的余量。

DELL R740服务器主要用于虚拟化，为部分业务系统提供计算和存储空间，例如NTP服务器、数据备份服务器和临床科研应用服务器等。

HP DL580 G10四路物理服务器主要配置如下：

• 4*Intel Xeon Gold 6230 20C/40T 125W 2.1GHz
• 8*DDR4 32GB RDIMM,2933MHz，256GB
• 4*128GB 英特尔®傲腾™持久内存
• 4*960G 3.5英寸 SATA SSD
• 4*8TB 7.2K 3.5英寸 SAS HDD
• 210GE光口 + 212GE电口

DELL R740两路虚拟化服务器主要配置如下：

• 2*Intel Xeon Gold 6230 20C/40T 125W 2.1GHz
• 8*DDR4 32GB RDIMM,2933MHz，256GB
• 4*960G 3.5英寸 SATA SSD
• 4*8TB 7.2K 3.5英寸 SAS HDD
• 210GE光口 + 212GE电口

3.3.2 组网方式建议

一个完整的Hadoop集群中的节点，分为三个角色：Client、Master 和Slave，如下：

其中

• Client：部署在用于跟Hadoop进行交互的应用节点中。
• Master节点用于集群管理，主要与Client进行通讯，为Client分配可用的Slave节点，同时Master会维护Slaves节点上报的每个运行参数。角色包括HDFS中的NameNode、SecondaryNameNode、zookeeper、MapRedcue的JobTracker等服务。
• Slave节点是Hadoop中的执行者，主要模块包括：DataNode用于存储，主要部署数据节点DataNode。Slave节点也是主要的数据处理节点，数据查询（HBase）的数据节点，与数据处理的数据节点共用。
• 其他服务器节点可以部署NTP server等节点，实现时间同步。

综合来说，在Hadoop集群中有大量文件读写或者MapReduce计算任务提交时候，都会出现大量的网络交互，尤其是MapReduce。所以一般建议给Hadoop提供专用的私有网络，用于内部数据的交互，网络带宽为万兆网，万兆网不仅仅10倍于千兆网的带宽，在峰值流量下，其时延也大大低于千兆网。

根据最佳实践，对于更大的集群使用千兆网可能造成性能的下降。对于同一个机架的节点，每台服务器通过配置的双端口英特尔X710万兆网卡SFP光口组建冗余IP网络并和其他大数据节点进行通信。

3.3.1 硬件配置建议

各个服务器具体配置方案如下表所示：

• 内存的选择：通常情况下，Hadoop处理任务每个CPU逻辑核（指超线程下，一般一个核对应两个逻辑核）对应4~8G内存即可。对于HBase或模型训练等大数据应用，大内存可以显著缩短运算时间。
• CPU的选择：实测表明：Hadoop处理性能与CPU性能密切相关，任务运行时间与SPEC值基本成反比关系，因此应该选择性能较高的CPU。
• 服务器类型：一般的Hadoop项目选择2U或4U的机架式服务器，对于高密（2U四节点），也应用得比较好。

3.3.1.1 存储能力估算建议

服务器在进行存储能力配置估算时需要考虑数据副本数、冗余量的考虑将影响存储能力评估，需要预先确定。可以参考此公式进行估算：

（业务估算数据量 压缩比副本数）/ 冗余量

当HDFS剩余空间较小时会影响性能。建议冗余量设置为30%。

进行HBase存储估算时，需要考虑数据膨胀率，一般来讲可以为2。

副本数设置建议按照Hadoop默认的3副本，这可以有效防止硬盘受损、机器或机架故障导致数据丢失或损坏

操作系统盘可以采用SAS或SATA盘，建议采用两块硬盘盘做RAID1后作为系统盘，磁盘支持热插拔，方便运维。

对于数据节点存放数据的磁盘：可以采用SATA降低成本，提高存储量。

对于HDFS块大小，默认是64M（某些发布版是128M，比如CDH）。但考虑到目前机器CPU的计算能力普遍很高，对于MapReduce在做Map的时候可以处理比较大的单个文件，目前一般建议Blocksize设置稍微大一点，比如256M或者512M。但跟实际应用场景相关，需要根据不同的硬件环境以及应用场景进行相关测试，然后得出最佳设置。

3.3.1.2 计算能力估算建议

应依据小规模基准测试针对所需的业务类型进行模拟测试，依据近似线性扩展原理，根据业务需求可计算出计算能力节点个数。考虑到扩容及其他因素影响，建议预留30%的计算能力冗余。

对于HBASE和模型训练等应用服务器配置的时候，更多的内存会缓存更多的数据，提高查询吞吐率并缩短响应时间。方案计划采用英特尔®傲腾™持久内存解决方案，采用AD模式为应用提供内存服务，显著缩短了HBASE和模型训练时间。

英特尔®傲腾™持久内存支持内存模式及APP Direct（AD模式）。在AD模式下，内存可直接插到标准 DIMM 插槽中，提供更具经济性的大容量内存支持。同时，能帮助系统在停电、宕机等情况下，将数据保存在持久内存中而无需重新加载，能够大幅缩短服务恢复时间，在一些典型场景中，整体恢复时间可从小时级缩短至分钟级。

3.3.1.3 虚拟机配置建议

除了Master节点和Slave节点外，还应对NTP时间服务器、备份服务器、接口服务器、监控运维服务器和调度预留机器。可采用虚拟化方式进行部署。

4 大数据平台应用场景

围绕大数据平台，分享医院的几个应用场景：

4.1 临床大数据搜索

通常临床医生需要检索符合医生需求的诊疗信息，需要通过院内的OA系统向信息科发起申请，由于专业性的问题，信息科的工程师还需要跟临床持续的沟通数据需求，然后在业务数据库中写SQL查询信息，再导出Excel发给临床医生。这样做效率低，查找的准确性不高，还存在数据安全的风险。

临床大数据搜索，可以用于全文搜索、结构化搜索、分词搜索、模糊搜索和复合搜索等多种模式，基于大数据平台治理好的数据元，医生可以结合专业知识进行有效的组合关联，检索目标的诊疗信息。

4.2 患者360全息视图

在实际诊疗过程中，医生往往会关注患者既往的诊疗记录（医嘱、病历、检验、检查、病理等）。在传统模式下，医生往往需要登录多个系统查看，并且很难查到历史的数据。

基于大数据平台建设的患者360全息视图，整合了不同系统间的数据通道，可以“患者全息视图”的方式展示患者的全治疗周期，记录患者在每个时间节点的诊断、用药、体征、检验、检查、治疗、手术、病理等信息。

4.3 多学科诊疗（MDT）

在临床实际工作中，医院经常会基于某些疑难杂症、典型案例发起会诊讨论或回顾性分析讨论。但是在实际讨论过程中调阅资料，整理患者资料等存在局限性，会影响实际的工作效率。基于大数据平台搭建的MDT，可以将特殊疾病、需要讨论病例的患者入组，在统一的界面展示，为临床医生提供患者统一的诊疗数据（包括历史就诊数据）：医嘱、病历、检验、检查、病理等。实现数据可真正追溯的MDT平台，同时MDT质管部门也可以进行统计分析。

医院大数据的应用场景除了以上的介绍外，还有很多好的应用场景，这里不在赘述。

5 经验分享

以下分享几点医院建设大数据平台的经验：

5.1 建立共识

建立大数据平台，要充分结合医院的发展战略。基于这个平台想要实现哪些方面的质变，甚至是量变。医疗发展方向和政策是一个指引方向，但是也要充分结合医院各个部门的需求，建立共识，才能更好的让大数据平台落地。

5.2 数据资产

建立大数据平台，还需要对医院的数据资产进行全面的梳理，只有掌握了医院的数据资产情况，才能有效的评估医院数据的存量和增量，为下一步的数据存储进行合理分配，为数据治理提供有效的支撑。

5.3 产品选型

大数据的产品选型一定要建立在满足自身需求的基础上，同时兼顾平台架构的横向扩展能力，是否能满足医院未来10年乃至15年发展的需求，包括数据增量、业务需求和计算能力。

5.4 数据服务

大数据平台需要更多的反哺业务，驱动业务，所以数据服务能力是一个很重要的体现。在建立大数据平台的同时，要充分考虑未来数据对外的服务能力，例如：数据可信、数据及时、数据算力等等。

5.5 人才梯队

大数据平台跟传统的业务系统是不一样的，大数据平台需要持续的运维和运营。随着医疗业务横向和纵向的延申，数据的范围也在不断扩大，对于大数据平台说，如何挖掘不断增长的数据和存量数据的价值，就需要持续的运维和运营。运维主要针对平台基础的维护，运营体现在数据的持续服务能力，所以培养相关方面的人才队伍是有必要的。