作者jakeyyu·2022-03-14 13:48

系统架构师·三甲医院

三甲医院如何建设支持临床、运营和科研大数据平台的基础架构交流总结

字数 20301阅读 2179评论 0赞 3

应用需求决定平台架构，平台架构决定基础架构。三甲医院大数据应用场景主要分成临床、运营、科研三大类，分别对应临床数据中心（CDR），运营数据中心（ODR）和科研数据中心（RDR），临床数据以电子病历为核心，目前随着结构化电子病历的普及，纯文本的数据越来越少，NLP的技术依然适合，运营数据则大多数为结构化数据，科研数据则在临床数据的基础上有更多的多媒体数据（多数为影像数据）、实验数据和随访数据。大数据平台基础架构设计需要支撑上述需求的实现，计算能力、存储能力和安全是基础架构建设的三个重要方面。计算能力主要在数据采集、预处理、实时计算和分析阶段进行支持。存储能力则是支持分析数据所需要存储资源和存储空间的支持。三甲医院大数据平台大多数基于Hadoop等分布式平台，采用内存数据库或图数据库进行数据存储。

为帮助三甲医院用户更好地建设大数据平台基础架构，twt社区组织“三甲医院如何建设支持临床、运营和科研大数据平台的基础架构？”线上同行交流活动，特别邀请到自三甲医院的专家、戴尔科技医疗行业专家一起交流分享，本场交流活动总结如下。

# 一、临床、运营和科研大数据平台的内容和要求角度

## 1、三甲医院大数据平台如何建设，才能满足具有多模态，异构化，海量化的临床、运营以及科研数据的整合？
众所周知，三级医院经过十几年、几十年的信息化建设，已经建设成为具有临床数据支撑，科研支撑，以及运营支撑的全方位信息化应用的场景，但是随着大数据分析广泛应用，海量数据的整合挖掘及再利用也提上日程，部分医院走在了前列，但是在开展的过程中遇到了不少问题，比如，数据的模式的多样性造成了对数据使用的难点。医疗数据中包含了文本，图像，视频等，还有不同模式的数据。如何将这些数据整合利用，以便发挥数据的最大利用价值成为目前医疗大数据平台的研究方向之一。

**嘉宾：zyp8365  高级工程师，广东省中医院**
数据的多模态、异构化、海量化必然导致其支撑架构的多样性。哪些数据适合关系型数据库，哪些数据适合分布式数据库，存储的选择亦是如此，也要结合数据类型，数据的重要性、时效性要求以及业务的实际要求等因素综合考虑。数据的整合利用离不开如下几个方面的工作：
1、大数据平台需求与多元化采集数据源的梳理；
2、数据的标准化规范化治理；
3、数据的主题化的汇聚；
4、数据的知识化社会化的应用。

**嘉宾：spgoall  信息管理部部长，和祐国际医院**
可以考虑先建立数据湖，把数据整合后，再按主题做筛选和清洗。

**嘉宾：Hunter123  存储架构师，DellEMC**
医疗数据的来源和类型都非常的丰富，一般来讲至少包含了HIS、EMR、LIS、RIS、人事系统、随访系统、手麻、护理等等各个业务平台，数据类型包含结构化数据、非结构化文本、图片、甚至有的会包括一些多媒体数据，而这些数据的复制、导入都有各自的方式。所以在大数据平台的建设中，除了数据量的考量，还需要充分考虑到对多样化数据的集成问题，需要支持丰富的数据访问接口，以减少对数据集成带来的困难。同时在使用这些数据时，首先需要遵循国内、国际的相关标准，进行数据治理和标准化，然后将标准化后的数据按照不同场景进行计算整合，提供给业务使用。

## 2、信息部门该如何规划CDR、ODR、RDR的裸金层？
当前建设这个CDR、ODR、RDR个数据中心是医疗圈热门的话题，信息部门该如何规划CDR、ODR、RDR的裸金层，一次把基础架构搭建立起来，避免重复建设。

**嘉宾：zyp8365  高级工程师，广东省中医院**
目前，CDR、ODR、RDR的定位和作用医疗圈是有共识的，但是其建设方式、模式及数据交互方式尚处于百花齐放的阶段。不同的公司有各自的解决方案，不同的医院和机构也根据自己实际业务的需求和特点进行着有针对性的建设，所以我理解因为其建设的非标准化特性，希望有一种规划、或者一种模式把基础架构搭建起来，然后后续不再变动，不再调整，从而避免重复建设，这种本身是与信息化技术与发展的日新月异的特性和特点相违背的。当下，数字中国日益提上日程、物联网、5G的快速应用、区块链、数字孪生、人工智能等新技术与医疗的融合也将日益紧密，数据中台的讨论也不绝于耳。所以CDR、ODR、RDR这种适合当下的数据层架构和方法论是否适合未来3-5年的技术发展尚不可知，所以其基础架构的不确定性也更加不能形成定论。

目前就CDR、ODR、RDR的建设而言，个人觉得，应该把握几个建设原则：
（1）分类原则。不管技术如何发展，架构如何调整，数据的分类应该是不会有太大的调整。结构化、半结构化、非结构化，其适宜的存储架构是有明确的规范和要求的，数据的重要性与否，数据的响应时效要求，数据容灾要求，这些都是数据分类的具体指标，也为我们底层架构的建设提供指引，避免低需高配和高需低配的情况出现，保证需求和配置的相适宜；所以针对不同数据类型和数据要求，要有与之相适应的存储底层，故数据中心的裸金层也是存在多种架构存在的。
（2）可扩展原则。CDR、ODR和RDR，在建设初期，因为需求的不明确、中心数据的磨合、与各业务系统的交互和上层应用的梳理等原因，前期数据体量不会太大，随着业务的推进，技术、流程和方法的日趋成熟，需求也会处于井喷期，其数据增长也会指数型增长，原来的架构应该要充分考虑其可扩展性，以及扩展后保证数据性能、数据时效响应等方面不会下降。

**嘉宾：Hunter123  存储架构师，DellEMC**
没有一蹴而就的系统，也没有一招鲜吃遍天的技术；针对临床数据中心（CDR），运营数据中心（ODR）和科研数据中心（RDR）不用的特点可以用不同的技术方法来满足要求；CDR ODR更多是结构化数据，数据量相对较小，可以采用关系型数据库+SAN存储的模式；如戴尔科技PowerStore企业级全闪存存储；RDR 涉及海量数据同时对算力要求非常高，可通过医疗数据湖+HPC高性能计算集群来满足业务要求；数据湖建设要考量海量数据复制迁移（多项目使用是否要拷贝多份）、生命周期管理（性能容量要求和建设成本的矛盾）；戴尔科技PowerScale+ECS数据湖方案可以实现整合应用、消除孤岛、提高效率、降低成本，并且有丰富的三甲医院案例，可联系我们当地技术支持人员做进一步沟通交流；

## 3、医疗大数据方面如何解决数据孤岛和数据安全问题？
在医疗数据收集方面存在很多检查设备，例如：纤支镜 等单设备无法提取数据的问题。大数据处理过程中，如何保障数据的安全，以及隐私隐私问题

**嘉宾：zyp8365  高级工程师，广东省中医院**
目前，的确存在很多单体设备的数据提取、存储的问题，尤其是对一些专有设备如 纤支镜 、脑电图等，这些数据的采集要相应的设备厂家能开放相应的数据接口，目前很多这些设备的厂家基本都会有自己开发的系统，也有一些厂家会开发相应的系统，对市面上的比较高占有率的产品类型进行数据的提取开发。所以建议在采购该类设备的时候，一定要注意关注数据提取这块，数据接口是否开放？通过特定数据线抑或是网络传输？是否要专有信息系统抑或是市面上有可以统一汇集提取的软件？这些都要考虑并且也要写入采购合同中。大数据处理要严格执行等保2.0的相关要求，数据的处理可以通过堡垒机等安全措施进行操作，另外可以通过脱敏设备对敏感数据进行脱敏，并且形成相应的规范流程便于操作。数据安全要重视设备的投入、人员的管理、技术的提升，也要关注架构的合理、流程的规范、举措的到位。

**嘉宾：spgoall  信息管理部部长，和祐国际医院**
检查设备数据传输问题还是设备本身是否支持数据输出接口，这个需要联合设备科在购买设备的时候就要把数据传输接口需求写入招标文件。大数据处理过程中的数据安全也应该基于三级等保2.0的要求严格执行，隐私问题还要增加动态脱敏、数据库防火墙等设备

**嘉宾：Hunter123  存储架构师，DellEMC**
大数据最终为具体应用服务，数据的价值需要在具体应用场景才能最大化；数据采集作为大数据应用的第一步，是大数据平台的基础；针对没有应用场景需求的设备，可暂缓数据采集；同时在未来的设备选型中，明确数据采集接口的要求，为后续大数据应用打下基础，等保 2.0 有完善的安全体系要求，就数据安全而言，戴尔科技有完善的数据备份，数据容灾，数据中勒索病毒后快速恢复，数据避风港等解决方案。详情可以咨询戴尔当地的销售和售前同事。大数据隐私保护，可通过数据脱敏 及防泄密等安全手段进行防护；

## 4、科研大数据平台
科研大数据平台现在发展方向主要有四个方向：影像，大样本分析，多模态，真实世界研究，目前以真实世界研究居多，但是趋势是往多模态方向发展，这就要求传统的文本，结构化数据处理外，还需要结合影像图片，甚至是超声之类的视频，对于这类数据处理，底层基础架构如何支撑？

**嘉宾：zyp8365  高级工程师，广东省中医院**
存储层面可以考虑分布式存储、对象存储等方式；数据层面可以考虑分布式数据库、图数据库等方式。

**嘉宾：Hunter123  存储架构师，DellEMC**
科研数据类型越来越多样化，应用软件对底层基础架构的接口也越来越多样化，从传统的 NAS(SMB/NFS等)协议，到对象存储S3以及 HDFS(Hadoop分布式文件系统) ；这就需要底层存储架构架构满足丰富的非结构化文件接口要求，同时满足同一份数据被不同方式调用，避免数据重复存储，造成资源浪费；同时科研数据体量大，底层存储要具备高扩展性，只有真正意义上的分布式存储可满足要求；同时科研平台对算力的要求也特别高，需要一套匹配的高性能计算集群（HPC）才能真正发挥数据的价值；计算存储分离的架构，也更方便后续灵活扩展算力或者存储资源，灵活响应科研需求；

## 5、三甲医院科研大数据平台应该具备哪些主要功能？
结合现今人工智能，数据科学的流行，三甲医院对科研的发展愈加的重视，对于一个能够完美支撑三甲医院科研的数据平台是非常必要的，但是从业务和建设者角度来看，临床科研的需求和计算机专业从业者之间对于技术平台的理解还有一定的差异，那么科研平台应该具有什么样的功能，才能满足或推动临床科研的进一步发展十分重要，这也是具备信息技术的从业人员需要搞清楚的问题

**嘉宾：zyp8365  高级工程师，广东省中医院**
科研平台作为医院科研领域重要的业务平台，要结合科研业务的特点进行功能的设计。因为科研业务的复杂性和多样性，所以也就导致科研平台的功能是十分复杂、十分多样的成体系的存在。但是几个大的功能科研平台还是应该具备的：
1、数据的查询和提取功能。科研业务的重要对象就是对数据的分析，针对某一科研项目需求，能从平台中查询并提取出研究所需要的数据，这个应该是平台必备的功能；
2、科研信息图谱的查询。科研业务在开展前，需要进行回顾性分析，对前人类似的科研业务、文献、网络资源等进行综合性查询和分析，能让研究者了解该研究的整体的信息图谱，为本次科研项目研究提供有效信息支撑；
3、科研人员图谱查询。要做好科研，要有合适的对的人参与进来或者进行相关业务的合作，科研平台能全方位的展示相关人员的科研信息，为科研人员提供选择参考将有利于科研项目的推进。

**嘉宾：Dell_zhangcan  架构师，戴尔科技**
科研大数据平台的建设自然是需要以科研为核心来进行建设，对于数据平台来讲，主要的目标还是科研数据的管理和提取统计，考虑到医疗数据来源、类型多样化，所以在科研大数据平台需要具备灵活的数据处理功能，对数据的来源、格式不能有太严格的要求；同时在提取统计时需要做到快速、高效，以帮助提升科研效率。

另外，科研平台还应具有数据汇聚、数据分析、海量数据存储，数据查询、数据生命周期管理等功能。

## 6、医院科研大数据平台，对临床医生要能真正有所帮助，无论是数据还是图像？

**嘉宾：Dell_zhangcan  架构师，戴尔科技**
医院科研大数据平台，大部分基于 HADOOP 技术框架，针对业界公认的未来大方向是计算与存储分离。计算节点容易理解就是运行集群管理和 MapReduce 的计算资源，存储推荐基于数据湖的 HDFS 解决方案，数据湖的核心定义就是一个存储平台，就是一种以集中式存储各种类型数据 ( 包括 PACS 图像、视频等 ) ，提供弹性的容量和吞吐能力，能够覆盖广泛的数据源（ NFS/SMB/FTP/HTTP/S3 ），支持多种计算与处理分析引擎，并可以直接对数据进行访问的统一存储平台。

存储与计算分离架构提供了独立的扩展性，可以做到数据入湖（DataLake）的同时，计算引擎按需扩容，更关键的是存算分离解耦方式带来了更好的性价比。

**嘉宾：zyp8365  高级工程师，广东省中医院**
任何技术手段、架构、方法、系统抑或是平台，包括医院科研大数据平台也是如此，其目标都是结合业务对数据、流程、模式等进行再组织，从而实现用户既定目标。系统平台的建设，表面看是信息化层面的建设，但是其实质是业务流程的再造、知识的再重组梳理、数据的再组织，结合技术的特点和优势，从而实现业务自动化乃至智能化。所以如果系统和平台要建的好，相应用户如临床医生的深度参与是密不可分，需求目标要能明确提出、功能体系要充分验证，数据质量要监控把关，只有这样，医院科研大数据平台的建设才能实现为临床医生提供真正意义上，有感的帮助。

# 二、基于医院大数据平台建设的技术架构角度

## 1、互联网医院的建设中，如何规划大数据平台的架构？

**嘉宾：zyp8365  高级工程师，广东省中医院**
按照卫健委发布的《互联网医院管理办法**（试行）**》，互联网医院包括作为实体医疗机构第二名称的互联网医院，以及依托实体医疗机构独立设置的互联网医院。互联网医院作为互联网+医疗的组织表现形式，不管是哪种形式的互联网医院，其业态是目前为止是一定的，如我们熟知的预约挂号、在线缴费、在线查询检验检查报告、在线入出院等。随着互联网+医疗的深入结合，其服务模式等也会有相应创新性的发展。规划互联网医院的大数据平台架构是，要充分考虑互联网医院现有业务模式下的数据概况，也要充分预留未来互联网+医疗业务爆炸式、井喷式发展时，基础架构的可扩展性、灵活度要能与之适配。

**嘉宾：Dell_zhangcan  架构师，戴尔科技**
互联网医院的大数据平台建设中常常遇到的典型问题是如何应对非结构化数据高速增长带来的存、管、用难题，比如：数据中转效率低，性能跟不上，硬件更新迭代如何数据迁移，归档怎么做，数据安全、合规怎么做，如何保障数据长期甚至是永久保留等等。因此规划大数据平台架构，主要需要支持以下能力：
（1）采用支持不同应用、多协议访问的数据湖解决方案，
（2）分布式架构，支持横向扩展
（3）支持上下代兼容，
（4）支持数据自动分层、归档功能，
（5）支持备份、复制、防范勒索病毒方案，
（6）支持基于网段、IP限制、多租户、配额等权限管理。

这里推荐数据湖存储解决方案，数据湖的核心定义就是一个存储平台，就是一种以集中式存储各种类型数据，提供弹性的容量和吞吐能力，能够覆盖广泛的数据源，支持多种计算与处理分析引擎，并可以直接对数据进行访问的统一存储平台。DELLEMC ISILON 数据湖存储，其核心基于分布式文件系统OneFS建立的数据存储方式，横向扩展能力强大，实现了集中统一管理，对同一份数据支持多协议访问，支持数据(HDFS)就地分析(MapReduce)，同时支持云原生应用的持久化存储，在数据安全方面支持备份、容灾、权限管理、勒索病毒防范和检测功能。

## 2、基础架构与医院信息系统的融合问题？
如果医院已经建立集成平台，但缺乏专业的临床科研数据平台，怎样将科研，管理，临床平台与现有集成平台融合。基础架构与新建信息平台的融合！

**嘉宾：Hunter123 存储架构师，DellEMC**
数据集成平台的出现解决了不同信息化系统中的接口问题，让数据流动起来 ; 但科研，管理，临床平台最终目的是实现不同领域的业务应用；临床数据中心（CDR），运营数据中心（ODR）更多是以结构化数据为主数据类型，数据总量相对较小，很多医院已经基于集成平台完成了CDR及ODR的业务应用，如患者360视图等；科研数据中心（RDR）更多是非结构化数据，数据量大，数据类型多，对基础架构的要求也更高；在平台规划期更多要关注平台扩展性，和数据处理能力；另外新应用的建设，也要考虑接口对接问题，才能更好的与现有基础架构融合；

**嘉宾：zyp8365  高级工程师，广东省中医院**
首先，应该要先理清各平台的定位和作用，以及我们需要实现的目标。集成平台是为了解决医院系统间星状交互导致的各类问题而提出来的系统交互平台，其目标在于实现系统间的互联互通，系统间的互联互通主要是通过平台的标准化接口实现。科研、管理、临床作为医院不同的业务领域，其实际业务目标是不相同的。又因为这三大业务领域中的具体业务各式各样，所以业务系统数量和种类也是多而杂。集成平台可以解决临床、科研和管理等业务领域各类系统互联、数据交互共享的问题，但是如果是临床、科研、管理等业务系统的数据的融合利用，则需要通过CDR、ODR、RDR等各类数据中心去实现，通过对逻辑数据的治理、存储、利用，充分发挥数据资源的价值。

## 3、大数据平台底层架构规划？
大数据平台架构需要数据存储和计算能力。医疗数据是多源异构的，有结构化、半结构化和非结构化，同时随着未来物联网、设备等数据的增长，对大数据平台的数据存储要求会更高；大数据平台需要满足各种AI能力，这部分体现在算力上，算力需要的软件和硬件两个层面的支撑。综上，在建设大数据平台的时候，做好应用的规划的同时，也需要充分规划好底层基础架构，底层基础架构需要满足先进行、成熟性、使用性、开放性、和扩充性。
问题：如何做好这部分规划？

**嘉宾：Hunter123 存储架构师，DellEMC**
大数据平台建设涉及数据采集、数据存储、数据清洗、数据分析和数据应用等应用流程；每一个流程都有不同的技术选型；结合在医疗实践中总结的主要挑战，需要重点关注 平台扩展性、稳定性、性能、及数据移动等问题；戴尔科技集团可提供端到端的医疗大数据平台基础架构方案，提供从云平台、医疗数据湖、HPC高性能计算集群等方案，解决大数据平台建设中的挑战；并且有丰富的案例，详细方案可联系我们当地的技术支持人员；

**嘉宾：zyp8365  高级工程师，广东省中医院**
个人觉得对于大数据平台的底层基础架构，也应该根据其上层的应用类型、数据类型、时效要求、容灾要求等综合考虑选取合适的，与之相适应的底层架构。笼统的把整个大数据平台放在某一种架构中，不考虑其实际情况，将容易导致资源利用与实际需求的不相符。大数据平台的数据类型及业务场景都是多种多样的，与之相适应的，底层基础架构也应该进行分类讨论。就存储底层而言，存储IO要求高的，结构化的数据则应该用ssd全闪乃至NVMe全闪，要求不高，数据量较大，非结构化的数据，则应该考虑其他类型的存储、分布式存储乃至对象存储架构。

**嘉宾：陈建 系统运维工程师 武汉市中心医院**
大数据平台的底层架构主要是3个方面：数据的存储、算力和算法，在这之上来支撑数据的应用，反哺业务。

## 4、三甲医院大数据平台基础架构？
应用需求决定平台架构，平台架构决定基础架构，说明医院尤其是大型三甲医院大数据平台基础架构是很重要的，我的问题是针对医院不同类型的数据类型，要充分考虑医院数据的存储方式和存储能力，同时还要考虑系统的计算能力，这是建设基础架架的前提，希望有这方面建设的实例针对性的分析，谢谢。

**嘉宾：zyp8365  高级工程师，广东省中医院**
目前很多医院在建设基础架构时，正在逐步云化过渡，有些在建自己的私有云，有一些会将一些业务放在公有云，都在做相应的积极探索，当然有利有弊。在医院基础架构云化的大背景下，我们在建设时应该要以池的概念去综合考虑计算、存储以及业务的问题。现在很多医院都是区分内外网，并且系统都做了不同程度的容灾，还有很多系统正在上线开发，需要大量的测试环境，还有很多对外交互的业务需要在DMZ区，如医保、支付宝、银联支付等。所以从业务层面来划分，可以分为内网云、外网云、对外交互云、测试云、容灾云。而针对不同云的特点要求，可以选取不同级别、不同性能、不同容量的设备和技术体系进行支撑，重要的、稳定性要求高的、时延要求小的用高性能高可靠的架构体系，非结构化、数据量大，访问频率底的，可以考虑分布式存储或对象存储，以此类推。另外计算和存储能力，在云化下，针对性的进行池化分析，计算池是否满足计算要求，是否有GPU计算需求等，都要结合业务去具体分析，容量池亦是如此，在此不再赘述

**嘉宾：Hunter123 存储架构师，DellEMC**
非常同意应用需求和特点决定基础架构这个观点。就戴尔科技落地的案例而言，有医院将 PACS业务和Hadoop大数据分析业务都放到同一套8节点的分布式集群存储Isilon上运行，也有大型三甲医院将基因测序、影像AI、数字病理等多个生命科学大数据应用放到同一个数据湖中运行。这两个案例的共同点是计算和存储分类，服务器提供算力，专业的存储设备保存数据和保护数据。这样做的好处有：
（1）架构扩展性好，可以根据算力和存储的不同需求，按需扩展对应的资源；
（2）数据安全性好，专业的存储设备可以提供数据分层、备份、容灾、归档等多种数据保护功能；
（3）消除数据孤岛，实现多模态数据高效利用。医院有多个大数据应用时，如果每个应用都单独建设一套基础架构平台，不仅会形成新的数据孤岛，造成资源浪费，还会因为数据在各个平台间进行迁移 / 流动造成数据利用率降低。

## 5、医疗大数据平台不同的建设路线底层基础架构设计时有什么要求？
目前医疗大数据平台大多采用HADOOP+MapReduce、内存数据库(以SAP HANA为代表的)以及图数据库（GP为代表），这几种模式在底层基础架构构设计时有何区别？

**嘉宾：Dell_zhangcan  架构师，戴尔科技**
在大数据平台建设中，无论是hadoop，mapreduce只是大数据平台中的技术细节，只要是能满足业务需求的采用那种技术路线都是可以的。如果是规划底层的基础构架，灵活性是首先要考虑的问题。目前大数据相关技术发展很快，开源的hadoop,spark等，公有云 AWS，alibaba 等也有相关的云服务，IBM, 医度云等专业务的ISV也可以提供各细分行业的大数据软件和服务。在规划大数据平台时要充分考虑技术的发展，我们自己的平台要能适应这些发展，比如涉及敏感数据的需要自建平台或用私有云平台来承载，一些公开数据可以直接采用云服务，我们的平台从整体上看可以充分利用私有云和公有云的优势，在满足数据安全的前提下从平台层面打通公有云和私有云，整合两种云的优势，更好的满足业务需求。

**嘉宾：zyp8365  高级工程师，广东省中医院**
底层基础架构设计不仅要考虑技术因素（性能、一致性要求、SQL兼容性要求），也要考虑包括架构产品的生态成熟度、应用架构适配度、团队适应度等非技术因素。Hadoop+MapReduce是典型的分布式文件系统+分布式计算的技术框架，其组件HDFS就是典型的分布式存储架构，分布式存储架构更为适合其技术体系。内存数据库其主要的设计目标是为了解决高并发低时延的数据管理需求，依靠内存来存储数据。从存储速度来说，CPU寄存器>CPU缓存>DDR DRAM>持久型内存>NAND SSD>磁盘驱动器（HDD）>磁带，内存数据应该使用DDR DRAM或持久型存储，区别在于DRAM目前为易失性存储，使用时速度较高，但是应该要充分考虑业务类型和备份容灾方案，保证在极端情况下业务业务连续性，持久型内存相对来说速度较慢，但是非易失，容量和价格也占优势。图数据库根据其图存储和处理方式分为不同类型，其底层的存储架构也要视图数据库采用的技术类型而选择与之适应的存储类别。另外，值得提出的是，不管是何种存储架构，要注意存储的物理块要与文件系统或数据库中的逻辑块大小上要适配，减少同一数据操作频次。而且在基础架构设计时，也要关注业务类型、成本和投入的影响。

## 6、医疗大数据平台在做存储容量的规划时应考虑哪些因素？

**嘉宾：zyp8365  高级工程师，广东省中医院**
主要要考虑如下因素：
（1）业务的需求及增长预期：要考虑现存数据的体量以及未来3-5年业务数据的增长量；
（2）数据的保存周期：数据保存期限多久，基础数据，过程数据、结果数据等类型数据的比例如何？保存周期的要求如何？
（3）架构及容灾要求：是集中式架构？还是分布式架构？选择的存储产品的存储内部组织方式如何？集中式架构是否包括RAID抑或是全局打散？RAID的划分要求、热备盘的要求如何？分布式架构高可用要求如何？副本如何配置？容灾要求如何，备份方式如何选择？全备、差异，备份的方式、频率及备份的保存周期如何？

**嘉宾：ghost_liu  解决方案，hc**
（一）推算业务系统的容量需求
（1）业务的数据量预估，比如每周、每月、每年数据增量。
（2）数据需要保存多久。
（3）数据分析需要多少个副本，全量的还是差异量的副本。
（4）是否有备份、容灾的需求，备份频率、保存周期等。

（二）推算存储设备该买多少盘
（1）硬盘的进制一般是1000进制，操作系统是1024，需要折算一下单盘容量。
（2）存储设备的数据冗余方式，多副本还是EC/RAID？根据校验盘的比例来算裸盘数量。
（3）还要查看所选中的存储系统自己存储元数据会消耗多少硬盘空间，把这部分扣除才是系统可用容量。
（4）算了RAID/EC以后存储可提供的容量以后，一般还要考虑加一个经验系数，比如10%或者20%的余量，作为风险余量。主要是小文件一般都有写放大。

**嘉宾：Hunter123 存储架构师，DellEMC**
满足当下需求，照顾未来需求。满足当下需求就是当下采购或规划容量一定要满足现有业务的要求，但大数据项目存储容量往往有很大的不确定性，在选择平台里一定要有灵活性，可以很方便的扩展容量和性能，满足未来不确定的需求

## 7、数据湖的整设计架构带来的疑问？
针对结构化与非结构化或半结构化的统一存储到数据湖，因医疗行业信息化发展多年，业务流程、数据标准已有相应的国家级规范，但是我的理解数据入湖带来的最大灵活性，数据不需要通常预先定义 schema，那么应用层带来的存储系统访问、权限管理、业务模型的标准化层面，需要单独来处理，因为我的理解，数据湖架构太过灵活而缺少对数据监管、控制和必要的治理手段，导致运维成本不断增加、数据治理效率降低，企业落入了『数据沼泽』的境地，即数据湖中汇聚了太多的数据，反而很难高效率的提炼真正有价值的那部分，最后只能再次迁移到数据仓库设定数据平台，才能解决运维、成本、数据治理等问题，我想了解Dell的大数据平台，在提供强大的计算/存储引擎的同时，针对影像、语音等灵活的非结构化数据与标准诊疗业务流程的结构化数据之间怎么有效的融合与一体化管理/治理，而不是说让医院搞一个Hadoop数据湖之后，需要再上一套数据仓库的解决方案，这样增加医院的维护成本，或者说再PASS平台层的解决与推荐方案？

**嘉宾：Dell_zhangcan  架构师，戴尔科技**
影像、语音等灵活的非结构化数据与标准诊疗业务流程的结构化数据之间有效的融合与一体化管理/治理这一需求涉及到业务融合的范畴，这一问题应有大数据应用提供厂家解决。戴尔科技的数据湖解决方案侧重于解决数据存储、数据高性能分析支持、数据安全保护、数据生命周期管理、数据容灾和归档、平台无缝扩展等问题。这些问题需要硬件平台和应用提供厂家共同配合，才能给出最完善的解决方案。

# 三、基于大数据平台建设标准和目标角度

## 1、医疗大数据团队建设？
对于医院建立医疗大数据，如何组建团队，需要哪些方面的人，如何建立标准操作规范，如何确定目标方向？如何考核和推进工作

**嘉宾：zyp8365  高级工程师，广东省中医院**
团队的建设要包含如下类型的人才：
（1）管理人才：有较高的管理素养，熟悉医疗大数据的业务方向和发展趋势，能团结团队人员朝着目标努力和推进工作；
（2）技术人才：包括懂标准规范方面、大数据技术能力（架构的设计、搭建、开发、应用等）等多方面大数据所需人才。
（3）数据治理人才：包括了解业务，有较强的数据治理能力、数据处理能力和分析挖掘能力等的人才；

标准操作规范的确立要结合业务流，形成本团队操作SOP，结合行业的研究热点、技术趋势以及本单位医疗数据、人员等优势，确立目标方向，目标的确定可以分为近期目标和远期目标，通过目标的逐步实现慢慢积累经验，逐步深入，进而确定远期及战略性目标。考核工作应该以人为主体维度，推进工作应以事或项目为主体维度，形成行之有效的绩效考核目标、成立项目推进工作组等相关临时组织，制定任务明晰、目标明确的责任任务清单，将任务具体分解，落实到人，进而形成合理共同推进相关工作。

## 2、临床数据中心必须符合医院的数据管理规范？

**嘉宾：zyp8365  高级工程师，广东省中医院**
无规不成方圆，标准化、规范化将极大促进数据交互共享及后期的分析挖掘利用。所以临床数据中心的建设必须要符合数据管理规范，不仅要符合医院层面的数据管理规范，还要参考遵循国家、行业等层面的相关标准规范。
但是值得提出的是，目前很多医院重系统建设，轻标准建设。信息系统的建设和运维已经让医院的信息部门不堪重负，极少会开展相应数据标准的研究，也极少有医院会成立相应的数据管理部门，专责于开展数据标准、数据治理及数据利用。

**嘉宾：spgoall 信息管理部部长，和祐国际医院**
答案是肯定的，临床数据中心的数据也在医院管理范畴内，必须遵从管理规范。

## 3、临床大数据中心，怎样将临床医生和护士的结构化电子病历数据直观显示在临床科室？
临床数据中心的数据应该是医院最核心的数据，怎样从结构化电子病历中提取医生和管理部门所需要的数据，保障从数据到转化，应该是关键问题。

**嘉宾：zyp8365  高级工程师，广东省中医院**
目前，临床数据中心的利用有很多方式，包括360患者全息视图、临床决策支持系统等，都可以基于数据中心中汇集的各业务系统（包括HIS、LIS、PACS等）的数据，提供利用转化。临床数据中心的利用，取决于医院医生和管理部门数据需求的明晰化，这个是利用的目标，前提则是业务系统中有相关的数据源，而重点在于数据源提供的数据有较高的数据质量。不然数据的转化利用效果则会大打折扣。围绕上面几点，临床数据中心要扎实持续做好数据需求的分析，保障数据源的稳定，形成规范的数据治理体系，为后续数据的利用提供基础。

## 4、医院各部门数据归口不一致，如何解决？

**嘉宾：zyp8365  高级工程师，广东省中医院**
医院部门间的数据归口不一致是业务使然，是正常状态，如医务部门的数据统计口径和统计部门的数据统计口径往往是不一样的，如就诊人次数的统计，他们各自取的有可能是不同业务表的数据，医务部门可能统计挂号人次数作为就诊人次数，而统计部门统计的是医生看诊人次数作为就诊人次数。面对这样的问题，个人理解应该从如下方面解决：
（1）统一数据口径。要梳理医院现有各部门数据需求，充分分析研究各部门的数据需求所对应的业务目标，充分沟通协商，形成有效的、统一规范的统计数据集；
（2）统一数据来源。业务数据统一汇聚在数据中心中，所有数据需求应从数据中心中获取，从而避免从不同业务系统获取数据导致的不一致情况。

**嘉宾： 陈健  系统运维工程师，武汉市中心医院**
这个问题现在是绝大部分医院面临的问题，我个人建议是划分业务域，建立指标库。
举个例子：
业务域：就诊、计费，业务活动：门诊就诊、门诊结算，原子指标：门诊就诊人次、门诊计算金额，派生指标：月度门诊就诊人次、月度门诊药品结算金额，复合指标：月度门诊药品均次费用。针对这个例子结合业务域将原子指标归口科室：门办和财务科，那么通过原子指标衍生的派生指标和复合指标口径就可以保持一致。需要注意的是：建立指标库的前提是要建立医院的数据资产，关键就是元数据、数据质量、数据血缘等。

**嘉宾： 潘延晟  系统工程师，第十区。散人**
现在很多行业做大数据都会面临这种问题。各部门分数不同的领域。所以在构建大数据之前，首先我觉得要明确的就是项目的架构，信息化逐渐的已经不再是企业的辅助系统。而是逐渐成为决策系统，要做大数据，那么首先要做的就是吧信息化做到一定的高度。底层的数据如病例，患者信息。医院信息还有综合的财务等信息要打通，这部分需要多个部门来配合，并且由独立的信息化部门来牵头完成的，梳理出数据的共性和特点。然偶建立公共的数据仓库。在根据业务的特点梳理出那些信息是需要进行挖掘的。很多时候。大数据平台的逻辑构建要比物理建设更重要，要综合现有的数据资源。共同分析才能形成更好的思路

## 5、CDR、ODR、RDR三者的边界怎么划分？面向临床医疗医生的数据呈现方式是什么？
临床数据中心（CDR），运营数据中心（ODR）和科研数据中心（RDR），三者存在交集，那么他们的边界怎么划分？面向临床医疗医生的数据呈现方式是什么？

**嘉宾： spgoall  信息管理部部长，和祐国际医院**
三大数据中心实际上就是三个业务主题，边界取决于业务数据属于哪个主题类别，但由于业务数据也存在多个类别，所以存在交集，特别是临床和科研，数据交集比较多。
面向医疗临床医生的数据呈现方式主要还是患者360视图，也就是基于一个患者的全生命周期的诊疗数据，如果数据能打通院外，那就可以以电子健康档案的方式呈现。

**嘉宾：zyp8365  高级工程师，广东省中医院**
CDR、ODR和RDR都是基于业务领域进行的逻辑层面的数据划分和再组织，而实际业务数据的产生也就是数据源是相同的，都是基于实际的业务系统，如HIS、LIS、PACS、HRP等。这三类数据中心的目标都是为了其相应领域的上层业务应用的需求，在对实际业务数据多元化采集加工基础上，进行的主题化汇聚，进而知识化应用。三大数据中心基于的业务领域分别为临床、管理和科研，虽然使用的数据源和维度可能有时相同，但是其基于此服务的应用目标是不一样的。举个例子，急诊就诊人员信息表，在CDR和ODR都可能有这部分数据，但是CDR中可能服务的上层应用是为某个急诊医生查询本人看诊人员数量或者查询剩余就诊人数，ODR中该部分数据主要是为医务管理人员查询某天、某月乃至某年急诊人次数抑或是通过可视化的方式展现急诊就诊人数的趋势图，或者结合时间、职业等进行关联分析得出相关的趋势分析。所以我个人认为三者的边界时模糊的，要基于业务领域和场景具体情况具体分析。

面向临床医疗医生的数据展现方式有十分多的类型和方式，可视化、多维度，相关的技术和工具以及相关的人员及业务都是相对较为成熟和成体系的。重点不在于有哪些类型和方式，重点在于展现的需求是否明确，展现的数据是否有来源，展现的数据质量是否足够高，这三个时对临床医疗医生的数据呈现问题需要解决的三大问题。

**嘉宾：Hunter123  存储架构师，DellEMC**
数据中心建立的最终目的是为上层应用服务，每个医院的建设的大数据应用侧重点不同，边界划分方法也不同；总的来说 CDR 及 ODR数据多是来自当前 HIS 、EMR等系统的结构化数据，应用也倾向于CDSS临床辅助决策、病种质控及医院管理等应用；RDR数据多是组学、病理、影像等非结构化数据，多用于临床科研、AI应用等场景；

# 四、基于大数据的存储规划角度

## 1、如何处理数据的存储问题，尤其是影像数据？
建设科研大数据平台，一般都是将各个业务系统的数据重新收集整理，结构化的数据也还好，并不占用空间，而非结构化的数据例如影像数据，一个大型三甲医院的增量是非常大的，如果这些数据都抽取到科研大数据平台医院相当于又要重新建设存储，如何平衡这些非结构化的数据的存储

**嘉宾：zyp8365  高级工程师，广东省中医院**
对于这类数据，应该要做好统筹规划，医院的数据都是会做容灾备份的，所以一般医院存放同类数据基本都是2份或2份以上，在业务系统、科研大数据平台或者别的其他应用系统对某个非结构化数据有读取或使用需求的时候，应该充分利用容灾备份环境中的同类数据。另外，在软件设计和数据库存放是，该类增量较大的非结构化数据以地址指针的方式存放，如需要调用时再通过地址调转到实际的数据存放路径。这样将极大的缓解该部分数据的读写压力。

**嘉宾：Dell_zhangcan  架构师，戴尔科技**
建议前期可以将医院的 PACS 类非结构化数据都直接放入数据湖中，后期基于数据湖建设影像大数据平台，这样能实现数据的就地存储和就地分析，避免了海量数据在多个平台间迁来迁去。戴尔科技的数据湖还支持重复数据消除功能，这样即使在数据湖中复制几百 TB 的影像数据用于科研，也不增加过多的存储容量，而且数据复制的速度极快。

## 2、医院大数据平台、科研平台等推荐存储架构？
医院大数据平台、科研平台等平台，推荐存储架构是？除了分布式架构的分布式存储，能否做个分析，用哪种类型的存储适合非特大型三甲医院呢？

**嘉宾：zyp8365  高级工程师，广东省中医院**
医院大数据平台、科研平台等平台，鉴于其数据的多模态、异构化、海量化，建议存储架构也是混合多样的，要针对数据类型、业务需求、性能要求等综合考虑，结合分析。即使是非特大型三甲医院，其基本业务也是和三家医院相差无几的，只是同样的系统，体量不同而已。如果体量不大、增量不高，为了方便维护，可以考虑超融合的架构体系也可以考虑一体化存储的方式，存储中涵盖了闪存等高速盘，也有SAS、SATA等低速盘，支持NFS、ISCSI等协议方式，但是值得提出的是这类存储虽然支持容量的扩展，但是存储机头的缓存、性能等可能会成为后续扩容、扩展的瓶颈，所以要对这方面特别关注。避免后续成为性能瓶颈。

**嘉宾：Hunter123  存储架构师，DellEMC**
大数据平台的存储架构选择与平台的应用特点密切相关。如果是采用传统数据库+Hadoop 架构，而且运行在虚拟机上的大数据应用，可以采用全闪分布式存储，也可以采用全闪SAN存储。如果是要采用HPC架构，基于物理服务器做基因测序等生命科学类应用，则需要根据是否运行Lustre、BeeGFS等并行文件系统选择存储架构。如果不使用并行文件系统，那么分布式存储是很好的选择。就非特大型医院而言，戴尔科技的PowerScale（Isilon）是非常适合的大数据存储。在生产实践中，有医院将PACS业务和CDR（基于Hadoop）放在同一套Isilon存储上运行，不仅节省了硬件投资和机房空间，平台的扩展性和数据安全性也得到了大大的提高。

**嘉宾：匿名用户**
医院核心业务系统需要同时满足医院业务连续性和法律合规要求，以规避法律对于医院IT运营者主体带来的可能的经济损失和政治风险，并降低因医院核心业务系统故障可能带来收入损失。 因此，医院IT系统在建设的时候，还需要全面考虑系统和数据的备份、容灾问题。 根据卫健委2018年4月发布的《全国医院信息化建设标准与规范（试行版）》中的要求，三甲医院本地数据备份需要具有存储磁盘阵列、存储备份软件两种组件，数据快照、同步异步复制两种技术，以及10分钟的RPO和15分钟的RTO。应用容灾的RPO和RTO要求也是10分钟和15分钟。国家卫生计生委办公厅、国家中医药管理局办公室颁布的《电子病历应用管理规范（试行）》（2017年4月1日起实施），明确了医院信息系统数据保存年限：门（急）电子诊病历由医疗机构保管的，保存时间自患者最后一次就诊之日起不少于15年；住院病历保存时间自患者最后一次住院出院之日起不少于30年。这意味着医院需要为患者的医疗数据，提供长达数十年甚至100年的数据保存时间，日积月累下来的文件数量、整体存储系统的可靠性、存储系统硬件升级换代的风险与成本，还有医疗科研的需求，都是需要妥善考虑的。现代医院核心业务系统，其存储系统选型，已经从性能、容量的简单存储需求，过渡到全生命周期统一数据管理的综合性业务需求。

## 3、关系型数据库，非关系型数据库还是分布式数据库，医疗大数据平台基础架构如何考虑？
大型的数据整合平台如何将异构化数据统一整合，是使用传统数据库技术还是采用其他方案

**嘉宾：zyp8365  高级工程师，广东省中医院**
要考虑数据类型、业务场景、时效要求、性能要求等因素。因为数据的多样性必然导致基础架构的复杂性、差异性和多样性。多种类型的数据库、存储架构并存应该是医疗大数据平台的常态，鉴于底层架构对数据及应用上层的透明性特点，结构化关系型数据虽然也能存放在分布式或对象存储中，但是其性能必然大打折扣，不同的数据库设计是，其适宜存储和处理的数据对象是一定的，所以我们在考虑医疗大数据平台基础架构是，要结合业务场景、数据类型、以及各类数据库、存储架构的技术特点综合去考虑。

**嘉宾：Dell_zhangcan  架构师，戴尔科技**
目前各种类型的数据库在数据平台上都有一定的实践，数据平台的选择一般从数据量和负载两个层面来考虑：
从医疗大数据的实际情况看，医疗领域除影像系统外其实很难说有真正意义上的“大”数据，一般来讲都在几十TB到数百TB之间，有些规模比较小的医院可能只有几TB；这些虽然都被称作数据平台或大数据平台，但在实际运行中有很大的不同。而不同医院间数据平台业务负载的区别就更大。
一般来讲在数据量较小的情况下，各种数据库功能性上都没有问题，但NoSQL数据库或分布式数据库在运维管理上会相对复杂一些；一般的关系型数据库（类似oracle）是以行方式进行数据操作，这种方式在几十TB的数据量上会有比较一定的效率问题，在这时候就可以开始考虑使用以列为方式操作的NoSQL数据库，以提升数据检索、计算的效率；在业务负载较重的情况下，如果考虑到单机性能无法满足业务需求，则可以考虑使用分布式的部署方式，利用多台机器并发以达到提升运行效率的目的。

## 4、如果解决存储扩容时不同厂商技术之间差异化问题？

**嘉宾：zyp8365  高级工程师，广东省中医院**
可以通过云存储的方式去解决。其中有两种比较常见的方式：
（1）网关的方式。如IBM的SVC，EMC的Vplex，通过存储网关将不同厂家的存储汇集起来再对外开放；
（2）外接存储的方式。通过某一高性能的存储其自带的虚拟化套件，然后将其他存储外接到其上面，相当于外置硬盘一样，统一由该高端存储汇集后对外开放。

**嘉宾：张文正  系统工程师 , dcits**
这是个问题，不同厂商存储扩容需要的硬盘类型、扩展柜型号等等以及相应lic，这种情况下采用虚拟存储网关是比较合适的，ibm的svc，emc的vplex。或者像华为的oceanstor等，增加smart virtual lic即可完成。后端扩容，对于前台主机识别是什么存储，看采用的是什么存储网关了。国产的华为的，爱数的。国外ibm、emc、hds等。

## 5、对于医院各种类型的数据，分别用什么方式、什么设备存储最适合？

**嘉宾：Hunter123  存储架构师，DellEMC**
从理论上说上层应用架构决定下层基础设施架构，医院通常有三大类应用：
1）HIS、EMR等运行在物理环境的传统核心应用；
2）运行在虚拟机中的非核心应用；
3）需要运行Hadoop，HPC等的大数据类应用；
表明上看，存储架构选型需要根据应用特点和存储特点来确定，但这容易导致医疗行业的存储架构选项走入重视集中式还是分布式，重视 IOPS、时延、节点扩展规模的误区。从医疗行业的应用特点和应用规模来看，无论是传统应用（HIS），还是新兴应用（集成平台、CDR），在集中式存储和分布式存储上都运行得非常好。这是因为医院的数据库应用几乎没有跑到10万IOPS以上，也很少10TB 以上的数据库。即使是数十TB的数据库，和互联网、金融、运营商等行业的应用比较起来，也是非常小的。简单来说，医疗行业的应用不管是传统应用（HIS，PACS），还是新兴应用（CDR、数据中台）的规模都太小，十万以下的IOPS、5毫秒以下的时延要求、20-30个左右的节点规模，无论是集中存储还是分布式存储都能很好支撑上层应用。

存储除了支撑业务运行外，其上保存的是数据，是医院最重要的资产之一。因此“医疗行业”存储选型考虑的指标有以下几点：
1）存储的稳定性和可靠性；
2）存储配套的数据保护解决方案，如由同一个厂家提供的同存储紧密结合双活 + 连续数据保护 + 备份解决方案；
3）运维的响应时间、专业程度和便捷性。
如果存储是A厂家，连续数据保护是B厂家，备份是C厂家。这肯定会大大影响故障排查效率，增加运维负担。同时售后服务是原厂还是合作伙伴提供，也对运维带来明显的影响。
从医院实践看。很多医院选择的是集中存储+分布式存储的架构，有时也成为双模IT架构或者稳态+敏态架构。这样既能确保传统应用获得高可靠、高性能，又能确保高弹性，高灵活性。
再补充一点，医疗行业的数据库类应用无论是集中存储还是分布式存储都能很好满足需求。反而是影像类应用（PACS ，影像AI等），才需要认真考虑是选择集中存储还是分布式存储，或者集中+分布存储；

**嘉宾：zyp8365  高级工程师，广东省中医院**
不仅要根据数据类型如结构化、半结构化、非结构化来区分存储的选择，而且还要根据数据的重要性、时效性、数据量大小、成本投入等来区分存储的选择。一般来说重要的、时效性要求高的结构化数据，一般采用高端的全闪存储或同类级别的存储，并且配以双活等高可用手段；重要性一般的非结构化数据可以采用分布式存储或者对象存储；重要性一般，共享需求较高的，则可以采用NFS类型的存储。当然上述存储选择的建议也非绝对的，还是要根据具体的业务情况具体分析。

## 6、针对医院科研大数据平台，戴尔科技有哪些已经落地的案例？和其他软硬件产品技术集成生态情况如何？

**嘉宾：Dell_zhangcan  架构师，戴尔科技**
戴尔在多家省级大三甲医院落地了基因测序平台，数字化病理平台，影像AI平台等科研大数据平台，涉及到科研方向有罕见病研究、遗传病研究、肿瘤相关疾病研究等。戴尔提供的是以算力和存储为主的基础架构平台，平台上可以运行多种开源或商业软件，包括基于Docker的基因测序应用。关于案例详情和具体的软件支持情况，建议联系戴尔当地的销售或售前同事了解。

## 7、医院大数据平台数据是如何备份的？
医院大数据平台数据是如何备份的？环境是非hadoop环境，是基于数据库环境做的大数据平台，怎么备份呢？推荐规划备份频率是？？

**嘉宾：zyp8365  高级工程师，广东省中医院**
备份方式建议分类备份。针对大数据平台的应用部分，一般体量较小，建议是根据更新频率进行，每次更新后进行全量备份。针对大数据平台的数据部分，因为是数据库，建议可以采用数据库专有技术做实时容灾，如oracle的dataguard，sqlserver的mirror等。除了实时容灾外，在数据库建立后做一次全量备份，并且可以根据数据增长情况及数据恢复时限要求做每周、每2周或每月一次的全量备份，中间时间辅以差异备份。

**嘉宾：Hunter123  存储架构师，DellEMC**
基于数据库的大数据平台架构和医院的HIS、EMR等数据库应用的架构类似，所以可以采用具有重复数据消除功能的备份解决方案对数据库进行备份，这样不仅备份的速度快，备份空间利用率高，而且每次备份操作都是一次完整的数据备份（全备）。备份频率可以根据平台的重要性决定，如果这个大数据平台比较重要，例如CDR。按照电子病历四级评审的要求，重要的业务系统应该每日进行一次完整数据备份，所以备份频率应该是每天一次全备。非重要系统，备份频率也不要超过一周。

# 五、交流达成的共识总结

通过本场医院同行的交流活动达成了一些交流共识如下，仅供参考：
（1）从大数据平台建设内容方面来说，医院大数据平台围绕临床、运营以及科研等三个主要层面进行，新技术，新手段也都需要围绕这三个方面，因此，CDR，ODR，RDR的建设应该说是囊括了医院信息化大数据平台的主要内容；
（2）从技术架构角度来说，基于分布式存储的架构平台似乎成为主流，但是目前正在逐步从分布式过渡到云，主要以医院的私有云+公有云的混合模式出现；
（3）从建设标准和目标角度，大数据平台应具有异构数据的标准化，数据处理流程，分析过程标准化的功能，同时，数据可视化也应是目标之一。
（4）从数据存存储选型角度，混合ssd和传统SATA的存储器搭建san网络也是一种传统路线，分布式存储的效果主要体现在不少医院早些年建成的基于Hadoop架构，目前云存储从成本到维护层面都是一个比较划算的选择。

医疗大数据平台

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

三甲医院如何建设支持临床、运营和科研大数据平台的基础架构交流总结

添加新评论0 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料