智慧医疗基础平台-08

数据平台-概述

按照卫健委颁发的《国家健康医疗大数据标准》，健康大数据是指居民在疾病防治、健康管理等过程中产生与健康医疗相关的数据。因为考虑到人们衣食住行中也包括平时的健康和亚健康信息，而非单纯生病治疗的数据，医疗大数据外延包括了“健康数据”。

医疗大数据的完整定义：在人们健康管理以及医疗行为过程中产生与健康医疗相关的数据。医疗大数据和传统大数据有所不同，有其自身特点包括：

1. 体量大：一张CT相片含有数据100MB，一个标准病理图有5GB左右

2. 多态性：数据来源多样，涵盖形式丰富，包括文本，医学影像等，多类型的数据对数据处理能力提出了更高的要求

3. 不完整性：医疗数据的搜集和处理过程经常相互脱节，使得医疗数据库难以对任何疾病信息全面反映。大量数据来源于人工记录，导致数据记录的偏差和残缺，去多数据的表达，记录本身也具有不确定性。

4. 冗余性：医学数据每天都会大量产生，同一人在不同医疗机构就可能产生相同的信息，整个医疗数据库会包括大量重复和无关紧要的信息。

5. 时效性：数据创建速度快，更新频率高，许多数据的采样周期从周天提升到了分秒，甚至是连续性记录。这对响应速度和处理速度提出了更高的要求；就诊、疾病进程等并非在一个时间点上发生的瞬时事件，在前中晚期会呈现不同的特点；此外疾病可能存在季节性特征。

6. 隐私性：数据隐私性是医疗大数据的重要特点。个体的患病情况，诊断结果，基因数据的泄漏都会对个人产生负面影响，且涉及侵犯公民权。

医疗大数据处理是处于相对前沿的应用，涉及到大数据，云计算，数据治理，机器学习等内容，而且在各个业务场景内有不同层级的应用。

一、区域卫健场景

2016年发布的《省统筹区人口健康信息平台应用功能指引》明确了全民健康信息平台的核心功能，明确要求建设数据采集交换、数据规范上报、大数据应用支撑和健康档案服务等内容。目前全民健康信息平台在大部分地区有了基础的建设，三大库数据完成了一轮采集、提供了初步的协同服务和综合监管和健康档案的基本应用，但也存在部分问题：

1. 数据质量不高，缺乏业务应用的数据标准，数据治理缺乏深度，数据处于谁使用谁治理的阶段。

2. 协同服务层面，虽然开通了部分共享服务接口，但是新接口的扩展还需要再次付费开发，缺少服务的整体配置和数据服务的业务化。

3. 数据准备周太长导致数据应用比较少。一方面缺少统一面向数据应用的标准，一方面缺少统一的数据平台工具，开发一款数据应用数据准备的周期很长，缺少对应的数据准备、开发的工具和数据开发、数据治理的最佳实践。

二、医疗集团场景

医疗数据在医联体医共体内流转，数据上报、集成、标准化、治理、匹配融合等加工操作，这些操作在对应的数据平台上进行。在这里数据处理有如下特点：

1. 数据来源多样：需要融合多种来源的数据，需要解决不同来源的数据标准不统一的问题。

2. 对数据实时性要求高：对数据实效性要求高，在短时间内完成多源数据的融合并对外提供高效数据查询接口。对于大数据处理的引擎和效率有更高的要求。

3. 需要更快、更准、更智能的数据洞察和分析：医疗集团对数据的需求不仅是更快的融合，更需要从数据中更快的获取到蕴含在数据中的洞察。对于大量多源数据的融合和分析，需要借助更加智能的能力，比如AI的算法模型。

三、智慧医院场景

医疗机构有电子病历评级等政策的刚需，对医疗大数据平台有强烈的需求。对于医疗机构而言，存在的问题如下：

1. 数据质量有待提高，需要加强数据标准。从医院业务系统直接产生的原生数据，一般不符合数据应用的模型标准，需要做清洗和转换，处理成符合所需的标准模型。

2. 院内系统数据壁垒未破除，院外系统数据饥渴，需加强数据共享；院内不同的子医院/科室之间系统和数据存在壁垒，院内数据共享和互通程度低，缺少统一的数据平台。

3. 线上线下医疗数据持续增长，海量数据等待挖掘与利用。传统的平台和工具不能够满足大数据体量下的数据挖掘，需要采取更加先进的技术和理念。

针对以上问题，医疗大数据平台的建设需要重点关注：医疗数据治理、实时数据协同和高效数据洞察的方面。

数据平台-功能体系

一、设计考量

1、数据应用

因为都是针对了具体的业务场景，都有自己的不同之处。比如，区域卫健场景有健康档案，医院有患者360视图等。这些应用基于数据的应用，那使用的数据还是底层治理的数据，因此对于上层应用部分可以结合下层的数据和一些应用搭建工具来组装，当然部分应用还需要定制化的开发。通过数据服务模块和可视化的报表搭建工具可以完成一些数据应用的快速开发和配置。

2、数据处理流程

考虑到区域卫建和医疗机构并没有配置数据专业人员，平台产品需要开箱可用，提供基于平台的场景化数据服务。将来医疗数据运营也会逐步的标准化，服务化，需要提供基于业务的数据加工功能和模板的沉淀，让运营团队可以低成本的运营。

抽象医疗数据处理流程，使之产品化。可采用数据平台+规则+服务的模式。一种可信的方式是将医疗数据处理的的过程抽象成可配置化的、面向场景的医疗数据处理步骤。把医疗数据加工的配置理解为步骤（ETL）/服务（ESB/服务编排）/算子（spark/flink），串联起来就是一个有业务含义的数据处理过程。

3、数据治理

不同场景的内容和配置的方式可能有差异，可复用的有数仓建模，数据质控，数据加工，但是有区别性的数据建模方法、数据质控内容、数据加工流转。

医疗数据的处理是基于上游的数据采集标准和面向数据应用的数据应用标准。标准的变动会影响到数据处理流程全链路的变动，统一的数据平台能降低数据治理和运维成本。例如在某种理想的状态下，数据标准的变更可以借助于数据资产计算的血缘关系，自动通知到下游的数据工作流、数据指标和报表的变更，降低数据治理的成本，提高数据的可用性。

二、功能划分

与前述若干业务场景类似，在数据处理过程中，上层数据应用也存在着场景化差异。数据处理平台整体可分为四层：数据引擎、数据治理，应用支撑和数据应用。

 

一、数据引擎

数据处理引擎：包括MPP数据库、Spark、Flink、Hive、数据湖基础能力。

二、数据治理

1、数据工作流：

将医疗数据处理抽象成具体的可视化配置处理节点或者算子（例如数据质控算子、患者主索引算子、医保转码算子等），通过表和算子的向导配置完成数据工作流的组装，同时通过调度和任务运行的能力，生成对应的kettle，Spark、Flink、ESB、Hive-SQL任务下发执行。

2、标准管理平台：

提供了医疗数据标准的管理和维护能力。跟下游的数据工作流、数据质控打通。定义好的数据标准可以直接用于质控规则的生成，避免多次配置，保证规则的一致性。内容沉淀方面，沉淀具体场景下的数据标准，积累各类医学数据标准。

3、数据质量平台：

跟数据标准和数据工作流打通。建表后自动创建默认的质量规则，同时提供多种规则模板。配置的质控规则可以在数据工作流中用算子的方式调用，让数据质控可以在工作流的任何节点以任何频率发起。

同时，由于医疗场景下的很多数据都不能读业务的备库，而是由专门的通道把数据整理发送到前置机，然后再从前置机同步数据，势必会造成数据的不一致，所以数据的一致性尤为重要。因此，需要数据质量平台提供从数据接入、到数据传输处理，到医疗机构质量评分三个阶段的数据质量保障。

4、数据资产平台：

通过从数据工作流、指标管理平台、数据服务平台中获取元数据，通过元数据的计算来生成全链路的血缘关系。为数据变更影响分析提供有利的依据。同时，数据资产基于不同的场景提供资产的分类，沉淀场景化的数据资产目录。

5、数据分析：

提供原子指标、维度、衍生指标的定义。同时指标的运行会跟数据工作流互通。指标管理平台的核心在于沉淀各个场景下的常用指标。例如，结合医保数据仓库，沉淀医保运行检测等数据应用的指标。

三、数据应用支撑层

1、数据服务平台：

提供数据查询服务，XML/CDA数据写入服务，支持共享文档等内容可以通过数据服务的方式进行配置。同时，数据资产也可以采集到数据服务的内容，可以分析潜在的数据变更对数据服务的影响。另外，数据服务平台作为数据应用的开发方式之一，沉淀了健康档案等数据应用常用的数据查询服务。

2、数据可视化平台：

数据可视化平台包括数据分析平台和大屏展示，提供业务监管、医疗运营分析可视化等模板。可以结合某些AI算法，提供了医疗场景下分析和预测能力。

四、数据应用层

数据应用面向不同的场景，结合数据应用支撑层开发面向行业的数据应用。例如患者360浏览器、健康档案浏览器，医保监测等功能。