这篇文章通过分析医疗大数据平台的背景和市场现状，从医疗大数据不同类型的应用和场景、大数据平台产品建设实践、医疗数据中台产品的未来规划这三个方面向我们讲述了医疗大数据平台的建设理论和相关知识，希望对你有所帮助。

一、背景和市场现状

在过去的2010-2020的十年里，国内大力投资于医疗系统信息化建设，产生并积累了大量医疗数据，迫切需要通过人工智能及大数据等技术来挖掘和实现数据价值，需要整合更加先进的技术基础设施以更有效的方式进行数据集成、数据标准化以及数据分析，最终实现医疗大数据更有效的应用。2020年新冠疫情爆发进一步推动了国内医疗健康产业的数字革命，AI、大数据、数字孪生等技术与医疗健康产业不断结合，促使医疗健康产业对于数据的利用又上了一个新的台阶。

同时，来自不同方面的要素也在推动着医疗大数据产品市场的发展。医院方面，公立医院转型压力与日俱增，需要引入数字化医疗管理解决方案发挥电子病历（EMR）的潜力以提高临床研究效率、降低人工成本、提高疾病诊断和治疗质量、更好地管理病人。

医院正逐渐推出创新业务模式，注重学术研究、临床治疗、转化医学及患者管理，推升了对医疗数据集成及应用的需求；许多大型三甲医院已引入先进医疗系统以提升医院管理效率，缓解中国医疗资源的短缺和分配不均。政府投资将进一步流入医院细分市场，支持其继续升级系统，提升与多个监管机构平台的数据互连性。

区域卫健方面，经过全民信息健康平台的初步建设，积累了大量的数据，这些数据如何产生更大的应用价值，如何在区域里面互联互认，如何跨区域互联互认方面有明确的需求。医保局方面，管理每年数万亿的医保「钱袋子」，对于如何使用数据来更好地管理医保基金有强烈的需求。疾控方面，随着全球疫情的频繁爆发，如何使用数据来更加快速、精准的进行疫情风险的管控有强烈的需求。

从市场情况来看，根据相关调研报告，中国是2019年世界第二大医疗市场，国内医疗大数据解决方案整体市场规模将从2019年的105亿元增至2024年的577亿元，复合年增长率达40.5%^[1]。

二、场景和需求分析

我们可以从数据流转的方向分析医疗大数据不同类型的应用和场景。在医疗行业，绝大部分数据产生于医疗机构内，例如我们去医院的检验、检查、门诊、住院、医保结算等数据都在医院里面产生，数据最直接的流转是在医疗机构内流动。除了医院使用数据以外，数据也会通过数据上报或者采集的形式流动到对应的政府机构，包括、卫健委、医保局以及疾控中心等。

因此，医疗大数据平台面向的主要场景括医疗机构（各类公立、民营的医院和医疗集团）、卫健委、疾控中心和医保局。对于不同的场景，其数据的处理方式会存在一些差异。下面按照四个场景进行分析。

1. 医疗机构场景

在医疗健康大数据与电子病历评级等政策的强驱动下，各级医院对于医疗大数据平台的采购有比较切实的需求。信息化程度高的三级医院（尤其是三甲）出于电子病历评级、科研论文发表与临床应用的需求来使用大数据平台 。对于医院来说，在数据治理和使用方面以下三个问题^[2]。

1. 数据质量有待提高，需要加强数据标准化。从医院业务系统直接产生的原生数据，往往是不符合数据应用的模型标准。所以需要使用对应的数据平台将原始数据加工和处理成符合数据应用所需要的标准模型。
2. 院内系统数据壁垒未破除， 院外系统数据饥渴，需加强数据共享。在医院内不同的子医院或者不同的科室之间系统和数据存在壁垒，院内数据共享和互通程度低，缺少统一的数据平台。
3. 线上线下医疗数据持续增长，海量数据等待挖掘与利用。随着数据的大量增长使用传统的平台和工具已经不能够满足大数据下的数据挖掘和利用了。需要采取更加先进的技术和理念。

2. 区域卫健场景

在2016年，国家发布了《国务院办公厅关于促进和规范健康医疗大数据应用发展的指导意见》明确要实施全民健康保障信息化工程，要全面建成互通共享的国家、省、市、县四级人口健康信息平台。

同年，国家卫生计生委规划与信息司和国家卫生计生委统计信息中心发布了《省统筹区人口健康信息平台应用功能指引》明确了全面健康信息平台的核心功能，其中明确要建设数据采集交换、数据规范上报、大数据应用支撑和健康档案服务等内容。2020年国家卫健委发布了医院信息互联互通标准化成熟度评测方案。

目前区域卫健的全民健康信息平台各地都有一些基础的建设，例如三大库数据完成了一轮采集、有了初步的协同服务、也有了一些例如综合监管和健康档案的数据应用。但整体来看也存在部分问题。

1. 数据使用时数据质量不高。数据采集之后没有形成业务应用的数据标准，数据治理缺乏深度，数据处于谁使用谁治理的阶段。
2. 协同服务层面，虽然开通了部分共享服务接口，但是新接口的扩展还需要再次付费开发，缺少服务的整体配置和数据服务的业务化。
3. 数据准备周太长导致数据应用比较少。一方面缺少统一面向数据应用的标准，一方面缺少统一的数据平台工具，开发一款数据应用数据准备的周期很长，缺少对应的数据准备、开发的工具和数据开发、数据治理的最佳实践。

针对以上问题，医疗大数据平台应该解决的问题主要有三点：数据治理、数据协同和更快的数据洞察。

3. 疾控中心场景

新冠疫情的爆发在疾控场景开辟了数据应用的新战场，也让医疗健康行业对数据应用走向了新的阶段。例如我们每天的健康码、核酸检测、疫苗以及在医院的就诊都会产生大量的数据，这些数据需要在疾控中心和卫健委等系统中进行上报、集成、标准化、治理、匹配融合等等数据加工操作，这些操作都是对应的大数据平台上进行。

在疾控场景下，数据的处理和应用有独特的特点。

1. 数据来源更多源。疫情防控中需要融合多种来源的数据，需要解决不同来源的数据标准不统一的问题。
2. 对数据实时性要求高。疫情的防控朝夕必争，是对数据实效性要求非常高的场景。很多来源的数据需要在分钟级别完成数据的获取，完成多源数据的融合以及对外提供快速、高效的数据查询接口。对于大数据处理的引擎和效率有更高的要求。
3. 需要更快、更准、更智能的数据洞察和分析。疫情防控中对于数据的需求不光是更快的融合，更需要从数据中更快的获取到蕴含在数据中的洞察。另外，在防疫这种需要快速决策和响应的场景，这些数据洞察要尽可能地准确。对于大量多源数据的融合和分析，需要借助更加智能的能力，例如AI算法模型，才可以让数据的洞察更加快速、准确和智能。例如，在疾控场景下基于AI算法模型的数据分析洞察和疫情检测预警。

4. 医保场景

2018年5月31日，国家医疗保障局正式挂牌。2020年7月国家医疗保障局印发了《医疗保障信息平台数据归集技术规范》等四部规范的通知，其中《医疗保障信息平台数据中台建设及应用指南》中将数据中台的建设标准规范进行了详细的定义。建设内容包括医保数据数仓建设、数据的归集建设，数据模型管理、数据质量管理、数据共享管理、数据分析等服务的建设。

相对于医疗机构、区域和疾控等医疗场景，由于国家医保局的统一规划，医保信息平台和大数据平台的建设更为靠前，在建设指南出台前期就有阿里、腾讯等互联网公司参与了建设指南的输出，从指南的名字包含”数据中台”可以看到有互联网公司大数据平台建设的印记，建设的范围和模式跟互联网公司的大数据平台更加贴紧。因此，在医保大数据平台这个赛道，对于互联网公司更为有利。

对于省级医保数据中台的建设，主要的需求有以下几点：

1. 业务应用和数据中台分开建设。《建设指南》中明确要求14个业务子系统国家统一下发，数据中台由各个省自行建设。
2. 汇集医保业务全部新老数据形成高质量数据资产。由于业务和数据中台同时建设，业务数据会有历史数据和增量数据标准不统一的情况，医保数据中台需要统一存储、管理和处理历史数据和增量数据。
3. 数据治理和上报标准化、需要紧贴国家考核要求。由于在新的建设方案下各省业务系统数据结构统一，省级通过数据中台将数据上报到国家，国家会使用统一的规则进行数据质量的评分，因此数据的治理和上报都需要标准化。省级数据中台的数据质控需要跟国家对齐，保证本省数据上报合规。
4. 面向主题的、分层的数据仓库建设，赋能数据应用。在医保数据中台建设指南中，国家医保局给出了一些业务主题的划分，也明确了医保数据仓库建模的一些规范。因此，省级医保数据中台需要支持数据仓库、数据主题的统一建设，方便上层数据应用的数据调用。

三、产品建设实践

1. 产品洞察分析

基于以上四大目标场景的分析，我们可以得出以下洞察和的对应的产品和服务方案。

（1）四大场景基础的数据治理场景类似，上层的数据应用存在场景化差异

在以上四个不同的场景里面整体的需求有相似、相通之处，可以总结为底层的大数据引擎、医疗数据治理层，数据应用支撑和上层的数据应用部分。

数据治理及以下部分的功能类似，针对不同的场景内容和配置的方式可能有差异。例如，数据仓库建模的工具是可以复用的，数据质控平台的工具是可以复用的，数据加工的工作流工具也是可以复用的，但是针对不同的场景数据建模的方法、数据质控的内容、数据加工的流转逻辑是有差异的。

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

因此，整个医疗大数据产品的产品矩阵分为四个部分：大数据引擎、医疗数据治理套件、数据应用支撑、数据应用。

（2）大部分医疗机构缺乏数据相关的人力储备，需要提供产品+内置规则+服务的模式

在以上的四个场景中，绝大部分医疗机构都没有数据部门。部分医院逐渐的开始在信息科中有一些做数据开发和分析的角色，而其他运用主体都没有对应角色的人来操作大数据的平台。在这种情况下，运用主体需要的产品不光是平台和工具，而是基于平台和工具的场景化数据服务。有一个形象的比喻叫做『交钥匙工程』。提供数据质控工具只是服务的一部分，提供数据治理服务和提升数据治理效果才更契合实际需求。

因此，提供平台以外的基于不同场景下的内容以及对于数据的长期运营和服务。例如医保场景下我们要提供医保数据接入、质控、上报的工作流模板，这些模板需要生态合作伙伴商协调完成配置，并持续的运营。随着信息化、云化的深入渗透，部分医院开始组建对应的数据运营团队，部分医美和私立医院逐步采用了公有云模式。政府也在成立相关的数据运营公司来运营医疗数据，未来医疗数据运营也会逐步的标准化，服务化，需要提供基于业务的数据加工功能和模板的沉淀，让运营团队可以低成本的运营。

（3）抽象医疗数据处理流程，使之产品化

既然要提供大数据平台+规则+服务的模式，通用的大数据平台提供的主要是代码和流程的编辑工具，对于医疗数据规则的积累无法很好的产品化。将医疗数据处理的的过程抽象成可配置化的、面向场景的医疗数据处理步骤是一个不错的方案。从更直观的角度来看，可以把这种配置叫做医疗数据加工的算子，每一个算子不单单是通用的数据过滤、数据关联等操作，而是一个有业务含义的数据处理过程。

例如，把数据质控抽象成一个算子，在工作流中配置一个算子就可以完成整个表的质控；将患者主索引抽象成一个算子，配置患者主索引算子就可以完成主索引数据合并的配置；将医保数据转码抽象成一个算子，在工作流中用一个算子就可以完成医保数据从地方码转换为国家标准编码。这种经过抽象过的可视化配置算子一方面在产品层面沉淀了医疗数据处理的方法，一方面降低了产品的实施和维护成本。

（4）一体化的大数据平台

由于医疗数据的处理基于上游的数据采集标准和面向数据应用的数据应用标准。标准的变动会影响到数据处理流程全链路的变动，例如标准变更以后对应的数据模型表、数据工作流、数据指标、展示层的BI报表都需要做一些变更。

在这种情况下，割裂的数据平台和工具会带来很高的数据治理和运维成本，为医疗数据的使用套上不必要的枷锁。因此，提供一体化的大数据平台可以更有效地降低数据治理和运维成本。例如数据标准的变更可以借助于数据资产计算的血缘关系，自动通知到下游的数据工作流、数据指标和报表的变更，进一步降低数据治理的成本，提高数据的可用性。

2. 核心模块功能特性

基于以上的分析和在具体项目中的实践，医疗数据中台提供了四层产品，分别是以下模块。

（1）大数据处理引擎层

大数据处理引擎：腾讯集团已经有比较成熟的大数据能力和平台产品套件，包括云Spark、Flink、Hive、数据湖基础能力。

（2）医疗数据治理套件

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

另外，针对数据工作流提供了更加全面和细致的监控功能。例如每个算子每次实例的数据条数，每个算子的任务运行状态等。内容沉淀方面，针对具体场景沉淀数据工作流的模板，方便后期在具体项目实施中一键配置。

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

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

同时，由于医疗场景下的很多数据都不是直接去读业务的备库，是有专门的厂商整理好数据到前置机，然后再从前置机同步数据，势必会造成数据的不一致，所以数据的一致性对账尤为重要。因此，数据质量平台提供了从数据接入对账、到数据接入趋势监控到医疗机构质量评分三个阶段的数据质量保障。

根据标准自动生成的质控规则配置

在数据质控的展现层面提供面向不同场景的质控Dashboard，做到一份质控数据根据场景的需要按照不同方式展示。内容沉淀方面，沉淀和内置面向场景的质控规则。例如，国家医保的数据质控规则。

医疗机构场景下源表-接入表对账监控

疾控场景下源表-接入表对账监控

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

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

（3）数据应用支撑层

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

数据可视化平台：数据可视化平台包括数据分析平台和3D可视化数字孪生平台。数据可视化平台结合医疗数据中台的能力，提供了政府监管、医疗运营分析可视化等模板。3D可视化数字孪生平台基于领先的3D可视化能力，结合医疗数据中台的数据和智能的AI算法，提供了医疗场景下3D的可视化产品能力。

（4）数据应用层

数据应用面向不同的场景，结合数据应用支撑层开发面向行业的数据应用。例如360患者浏览器、医保基金收支洞察等。

四、未来规划

当前医疗数据中台产品已经在大型医有一些项目在逐步落地，随着项目的落地产品的能力也在逐渐的补全。未来的产品规划大概会从以下几个方面发力：

1. 提升产品标准化能力。由于在医疗大数据赛道积累时间不算很长，有些产品功能存在项目的定制，对于类似的产品能力需要把能沉淀成功能的沉淀成面向场景的功能，根据不同的场景配置会提供不同的功能，进一步把能力做成可配置化、标准化，提升产品的标准化能力。
2. 交付和实施标准化。在产品标准化的同时，根据项目中实践的积累，沉淀出交付标准化的能力，上架对应的标准交付包。除了安装、部署的标准化之外，不同场景下的数据采集规范、医疗健康数据仓库建模规范、医疗数据指标配置都可以沉淀成标准产品的能力和标准的交付实施工作。将这些交付工作标准化，进一步减少自研能力的投入，培养更多的医疗数据交付和运营人才。
3. 引入更符合场景和更先进的技术能力，增加产品的适用性。医疗行业的在大数据方面使用的技术跟互联网行业还有比较大的差距，在某些场景下数据量也在暴增，数据更新和查询的需求非常的突出，但是计算资源又投入不多。所以在这种场景下一方面要引入互联网行业里面成熟的、靠前的技术，另外一方面也需要根据医疗行业特有的情况做评估。例如，目前在医保的场景下尝试数据湖来解决数据更新的问题，在疾控的场景下引入ClickHouse来满足更快的查询服务。
4. 完善产品的生态体系。医疗大数据平台的建设牵扯的流程比较长，参与的角色也比较多，在产品的交付、实施中引入生态合作伙伴可以降低产品规模化交付的成本。另外，医疗大数据最终服务的还是面向业务的数据应用，业务的应用是偏向于定制化、多元化的。因此，需要引入面向业务应用的合作伙伴，让大数据平台更加的开放，让合作伙伴也可以一起加入数据应用的开发才能更长久、健康地保障产品的成长。
5. 加强产品在医疗数据安全方面的建设。医疗数据关系到患者的众多敏感信息，对于数据敏感性、安全性要求更高。因此，平台遵循国家卫健印发的《国家健康医疗大数据标准、安全和服务管理办法（试行）》进行产品的建设，内置符合医疗数据的分类分级产品功能模块，根据不同的数据分级做针对性的脱敏处理和权限审批处理，保障医疗数据的安全使用。