医保数据中台建设的实践与思考

黄 越 彭思翔 罗 源 倪剑文 朱晓娟 施鑫杰 梅 好 王雅迪

（1腾讯云计算（北京）有限责任公司 北京 100193；2腾讯科技（深圳）有限公司 深圳 518057）

1 背景

随着医保覆盖率的不断提升、医保制度的不断完善，我国对医保精细化管理的要求愈发强烈。信息化作为实现医保精细化管理的重要手段，已成为我国医保体系建设的必然趋势，而数据中台作为国家医保信息化系统中的重要组成部分，也成为实现医保精细化管理的有效途径。

从2000年-2009年建立的社保管理信息系统核心平台一版、二版、三版，到2018年国家医保局成立后开始进行的全国统一医疗保障信息平台建设，医保信息化建设已经积累了20多年的宝贵经验。在这20多年中，医保信息化得到了很大的发展。在业务层面，医保信息化从主要面向经办发展到兼顾经办、监管、公共服务和决策；在架构层面，医保信息化从最初的C/S架构发展到当前基于政务云和专有云的HSAF架构。此外，伴随着大量医保数据的积累，医保信息化系统也从面向事务发展到面向“事务+大数据分析”。当前的医保信息平台顶层设计在核心业务区中明确规划了大数据区，并在该区域内通过数据中台来支撑大数据的存储、加工和应用。

在目前的医保信息平台建设中，我国是以“中台+子系统”的方式进行的。其中，中台部分包含了业务中台和数据中台，业务中台是基于国家医保局下发的程序代码进行部署，数据中台则基于我国发布的《医疗保障信息平台数据中台建设及应用指南》（以下简称《指南》），需要各地对建设的内容和需求进行消化吸收后再具体建设实施；子系统部分共包含14个子系统，遵循强约束、基础约束和弱约束的原则在下发的代码版本上进行建设。

2 数据中台建设的具体架构

数据中台建设需要对《指南》进行深入解读，结合医保信息平台建设场景需求，对应具体的内容，进而加以建设实施。结合数据中台建设和大数据应用的经验，通过对《指南》中的6大模块、16大功能需求进行详细分析，可梳理出数据中台所对应的建设内容。

2.1 大数据计算引擎

此部分内容主要对应建设当前主流的、经过实践的大数据存储和计算引擎，包括Hadoop和Spark等离线计算引擎，以及Spark Streaming和Flink等实时和流式计算引擎，以满足大吞吐量的计算场景和高实时性的计算场景。

2.2 数据集成

此部分内容需要包含数据采集和数据集成两个模块。其中，数据采集指通过离线同步、实时同步、文件传输等方式，将新平台生产的业务数据、地方历史业务数据、平行委办局共享数据等来自各个数据源的数据传输到数据中台；数据集成则负责将这些纵向（不同时间维度）和横向（不同空间维度）的数据纳入同一个框架下进行统一使用。

2.3 数据仓库

该部分内容由大数据仓库和数据资产管理共同组成。其中，大数据仓库按照《指南》的建议分为缓冲层、操作数据层、通用数据模型层、数据应用层，并承担相应的功能；数据资产管理是大数据仓库的顶层管理系统，负责根据当前大数据仓库的存储内容，实时对其库表、主题、血缘（指表与表之间的生成关系）、权限等进行梳理，并提供相应的管理和展示界面，方便各医保局的大数据仓库管理人员对当前的数据资产进行把控。

2.4 数据治理

数据治理是当前医保数据中台建设中的核心部分，包含数据标准(模型)管理模块、数据质控管理模块及数据转换模块。其中，数据标准(模型)管理模块管理和融合不同来源、不同版本的数据元数据、数据值域等，以保证数据中台最后提供的数据在符合国家标准要求的统一框架下运转；数据质控管理模块优先承载国家下发的各个版本的质控要求，并在此基础上扩展地方业务需要的其他质控标准；数据转换模块是数据中台工作流的核心模块，提供从数据源到数据仓各层的可视化工作流配置，并将数据标准和数据质控融合其中，带动数据中台的整体运转。

2.5 数据服务

数据服务主要依照《指南》，通过API接口、数据库接口和数据文件接口，提供数据写入和更新等数据类服务、数据查询类服务、数据运算类服务。

2.6 数据应用

数据应用主要由应用支撑和应用集市构成。其中，应用支撑包含BI（智能报表分析工具）、可视化大屏、机器学习平台等组件，在数据的基础上进一步提供数据分析和深度加工的支持；应用集市负责托管、分类标记和组织各类医保应用。

2.7 数据安全体系

数据安全体系包含角色权限配置管理、数据库表权限审批管理、数据服务脱敏、数据查询行级限制等功能，其从数据采集、数据存储到数据服务和应用，贯穿于整个数据生命周期，因此并未在表格中直接体现（见表1）。

表1 数据中台对应的建设内容

3 数据中台建设的实践与经验

从明确具体的建设框架和功能模块到实际完成建设还有很长一段路要走。在数据中台建设的实际打磨中，一整套实施方法和路径逐渐形成，为当前医保数据中台标准化的成型及下一步实践提供了方向。

3.1 实施方法和路径

实施方法和路径是实施效果和质量的保证，尤其是对于医保数据中台这类功能多、对接方多、角色复杂的系统。根据数据中台建设经验，可总结出主要的实施步骤。

3.1.1 环境调研

部署环境是一切系统部署实施的基础，当前数据中台的主要建设目标是采集业务数据、完成省级数据上报和支持应用子系统建设，因此至少需要调研4个环境情况：一是数据中台本身的部署环境。这部分主要包括数据中台部署所需的硬件情况、网络情况等，硬件和网络配置会直接影响数据中台大数据引擎的计算速度、存储能力和服务调用效率。二是业务数据源环境。业务生产数据库是数据中台的主要数据来源，为了防止业务生产数据库压力过大，通常将与生产库主备实时同步的生产备库作为业务数据源。业务数据源环境要将数据库的网络环境、吞吐能力、是否支持实时同步机制（如：binlog获取）等情况调研清楚，以明确制定数据采集策略，并提前申请测试库进行测试。三是省级交换库环境。数据上报是省级数据中台建设的使命之一，一方面要确保省级交换库的版本满足国家要求，另一方面要确保省级交换库与国家交换库及数据中台的网络已打通，同时需要详细了解交换库的读写机制（如：XA机制）是否与数据中台的大数据环境相匹配。四是应用数据库环境。为了提升应用子系统对运算结果数据的统计和查询速度，在省级平台建设架构中，往往会在数据中台和应用子系统之间设计大规模并行分析数据库（MPP库），因此，需要提前调研了解MPP库所使用的产品特性，并提前申请测试库进行测试。

3.1.2 数据归集

数据归集是数据中台部署完成后的主要任务，主要包含数据模型收集、数据归集两部分。其中，数据模型收集包含了数据建表所需的元数据等信息，需要在数据实际归集前进行创建。在实际工作中，会有大量的数据库表归集到数据中台（目前数量级上千），在数据中台会有4个大的数仓层，因此，在数据中台中会涉及大量的数据模型创建工作。为减轻该部分工作所带来的人力消耗，同时降低人工出错率，数据模型创建主要采用批量收集建立的方式进行。数据归集则可以大致划分为历史数据归集和增量数据归集，其中，历史数据归集采用一次性采集的方式进行，增量数据归集则采用定时任务配置或实时任务配置的方式进行周期性采集。

3.1.3 数据治理

数据治理作为当前数据中台建设的核心使命，主要包括6方面内容：一是数据质控链路规划。其是指在数仓各层的工作流中规划数据质控节点的位置。当前上报国家的库表为数据中台归集库表的一部分，因各地在数据应用中存在个性化差异，需要根据各地的建设需求，优先合理化规划各条链路中的数据质控规则及质控方式。二是国家质控规则注入。其是指将国家最新版本的交换库质控规则注入中台质控规则库，并通过版本管理的方式对国家交换库质控规则的更新进行跟进。三是质控规则扩充，针对地方应用需求，对质控规则库进行扩充及管理。四是质控规则启用及质控报告，按质控链路规划的质控方式启用相应的质控规则集，并对质控报告结果进行跟进。五是质控结果反馈及治理，质控问题通常可以分为两大类——业务生产数据问题和地方国家标准不一致问题。针对第一类问题，采用反馈至业务厂商并推动业务侧改进的方式进行提升，而第二类问题通常是由于地方业务编码颗粒度与国家下发标准不一致而引起的，因此可以通过数据转换先行治理，并经由合理的方式向国家反馈。六是数据上报国家，将国家上报链路中治理后的数据上传至省级交换库，并持续跟踪国家侧对上传数据的检查反馈结果。

3.1.4 数据服务及应用

数据服务及应用作为当前数据中台建设的另一核心使命，需要完成以下工作：一是数据库表访问权限。根据各个应用子系统建设厂商的使用需求，完成相应数据表权限的开放，并控制权限的读写设置，避免子系统间产生不必要的影响。二是应用子系统建设支撑。对各应用子系统厂商进行数据中台的使用培训，并及时解答厂商使用中的各种问题，以确保各应用子系统厂商可以正确地使用数据中台，完成子系统的上线。三是数据资产管理发布。通过数据中台中的“数据资产模块”完成地方数据中台数据资产的梳理，并对管理方进行培训，以保证数据资产管理方可以通过数据资产模块，快速、完整、动态地管理地方数据。

3.1.5 上线运维

完成以上任务后，即可进行数据中台正式环境的整体上线运转，但由于数据中台功能多样，大数据环境运维本身也较为复杂，为保障数据中台的正常运转，还需长期持续运维。

3.2 功能优化

医保数据中台涉及大量的库表，需要对接多个系统，使用需求较为丰富，因此在实际落地实施的过程中，需针对各功能的使用做出相应的优化和改进。

3.2.1 自动批量建表

医保场景下涉及数千个库表模型的建设，若单纯靠人工录入或以写脚本的方式建设，在消耗人力、拉长周期的同时，也容易出现人为错误。因此，可以通过自动批量导入建表的方式，快速、高质量地完成数据库表模型的建立。

3.2.2 自动关联大部分质控规则

目前，国家下发的交换库质控规则已有数千条，如此大量的质控规则很难靠人力逐条录入并维护。在分析国家质控规则库后，可对规则进行详细分类，并将其中绝大部分规则融入到建表环节一同关联建立，从而减少质控规则录入和管理的成本。

3.2.3 多样化的质控方式

在实际建设过程中，各地不同应用及上传国家的链路对质控的要求各有不同，因此，在数据中台中，可以通过强质控（过滤脏数据）、弱质控（仅生成质控报告）和阻断质控（阻断脏数据链路）等方式对不同需求场景进行支持。

3.2.4 链路数据转码

地方编码和国家编码间的差异往往是大部分脏数据形成的原因，这其中既有业务因素，也有历史因素。为同时保证上传国家的数据质量（脏数据少）和数量（总体数据多），可以在链路中支持数据转码，把既往的“脏数据”转化为国家要求的编码数据。

3.2.5 常用功能算子化

一般的数据中台仅支持数据同步、数据脚本等通用型算子，利用这些算子可以实现当前医保数据中台的需求，但这需要编写大量脚本，工作量较大。为减少工作量，可将数据质控、数据转码等医保场景下常用的操作进行算子化，方便可视化工作流的配置及后期的维护。

4 数据中台建设的痛点及优化思路

目前，各地的医保数据中台建设已能够基本满足当前阶段的使用需求，但在各地实际使用的过程中仍存在痛点，亟须优化。

4.1 数据治理体系

当前的医保数据中台已经在多个环节上引入国家下发和地方拓展的质控规则，并通过数据转换、强弱质控等操作满足了目前建设阶段的基本需求。然而在各地的实际使用过程中，仍存在“零散化”的质控方式，无法完全满足整体把控数据治理情况、各质控环节效果展现不够清晰、部分环节仍存在缺失等问题。因此，作为数据中台核心任务的数据治理需要向更体系化的方向进行优化。结合既往的经验，数据治理体系应当至少实现数据标准、数据转码、数据对账、数据质量、数据资产在业务上的联动。

4.1.1 数据标准

数据标准作为数据治理的起点，除了目前已经涵盖的元数据等数据模型信息外，还需包含各个库表、字段、值域等相关联的数据质控规则，即数据质控规则应当在数据模型建立之初就进入到整个体系内，而不是在后续工作流中进行补充，这样一方面可以在整体标准层面维护和掌握所有的质控规则，保证各层数仓的一致性和透明度，另一方面还可以统一质控规则的分类、标签等，便于对大量的质控规则进行统一管理和分析。

4.1.2 数据转码

数据转码是医保数据中台中最常见、数量最大的数据转化操作之一。为避免不同链路手动转码出现的各类错误，需要增加统一的数据转码管理子模块对数据转码进行管理。数据转码是建立在数据标准之上，对不同数据标准之间关联性的进一步约束。通过该子模块的增加，整个数据中台中的数据将得到进一步规范。

4.1.3 数据对账

医保数据中台涉及多层数仓，其间的工作流由各个不同厂商共同参与使用和修改。因此，各层数仓的表间出现各类不一致性的可能性较大，从而导致最后的出口数据受到此前链路上各节点数据的影响而出错。为最大限度避免此问题，需要在数据治理体系中引入数据对账环节。这里的对账既包括数据层面的对账，如数据量、去重后主键数量等，也包括业务层面的对账，如参保人数、就诊人数、基金支出等，以满足实际工作中对数据准确性把控的复杂需求。

数据对账中比较特殊的一类需求是业务源数据库与数据中台的数据对账。由于该类对账及后续数据问题的处理均涉及两个独立系统之间的联动，因此，需要针对两个系统的设计特性进行特殊的修正处理。医保业务子系统的设计需求使得医保业务库可进行物理删除或更新等操作，但是由于业务库事务特性和大数据仓库分析特性的区别，该类操作会引发两侧数据的不一致。因此，该类对账问题的修正还需要通过引入实时同步等方式对业务库物理操作进行捕获并同步至数据中台。

4.1.4 数据质量

数据质量指的是整体数据质量的把控，而不是某个节点的质控报告结果。整体质量把控是建立在数据标准和数据转码基础之上，对整个数据中台各个环节中数据对账、数据转码、数据质控的综合把控。医保数据中台中各层数仓之间有较为复杂的工作流关联，若需要每日掌握各级工作流的工作状态和生成结果，需要到各层的表中进行查看和统计。为把控整个中台的数据质量，需要添加统一的工作流看板，自动统计各层的工作情况并进行展示，同时支持对工作节点进行下钻以掌握具体的工作执行细节，从而使管理者能够快速掌握并定位可能存在的问题。

4.1.5 数据资产

数据质量把控着工作流间数据库表变化导致的数据质量变化，即工作流上的数据质量。除工作流上的数据质量，我们还需要把控从采集到存储、应用、共享各类节点上的数据质量，这就需要一个完整的数据资产模块来完成。当前的医保数据中台已支持数据资产管理模块，但是数据资产管理模块主要针对中台内的数据资产进行梳理，未形成完整的体系。完整的数据资产应实现从数据收集到数据处理、应用、共享全生命周期的全面覆盖，需要覆盖数据资产采集（哪里来）、数据资源目录（怎么看）、数据资产管理（怎么管）、数据共享使用（怎么用）和数据安全管理（怎么保证安全）。

4.2 大数据仓库体系

当前的医保数据中台已经在分布式文件存储系统上初步形成了分层的大数据仓库，但是医保大数据仓库从设计、使用上暂时仍未完全发挥大数据引擎的能力，仍存在各项目数仓建设规范不同、数据操作在各层数仓之间划分不清晰等问题，一方面使得大数据引擎的能力受限，另一方面也导致了资源利用不合理。一个完整的大数据仓库体系一般包含大数据仓库规范、数据指标、分析引擎等，结合既往经验，建议从数据仓库、数仓应用、新型联机分析处理（OLAP）引擎引入方面进行优化。

4.2.1 数据仓库优化

数据仓库是一切计算和分析的基础，但因其多分层的结构也使其使用和维护的难度加大，因此需要在开始便明确数据仓库的建设规范，并通过权限管理、规范约束等保证后续使用符合此规范，从而避免数仓使用的混乱。依据《指南》的规定及以往的实践经验，数据仓库优化可实行以下细化方案：（见图1）。

图1 数据仓库细化方案

其中，各层功能的约定包括以下几个方面：一是缓冲层（STG层）。缓冲层存储数据源采集到的原始数据，一方面可以作为后期数据溯源或问题数据恢复的最初源头，也可以实现与数据源的数据对账，保证采集到的数据与数据来源一致。二是操作数据层（ODS层）。操作数据层主要实现元数据统一，通过对不同来源数据进行结构转化，保证来自不同数据源的同一业务数据的表结构一致，以实现数据结构的统一，这其中包括医保新老系统的元数据统一、横向委办局的元数据统一等。三是明细数据层（DWD层）。明细数据层在操作数据层之后实现明细数据的进一步标准化，这其中包含了数据去重、内涵治理等，在此层后提供的数据均为标准化数据。四是汇总数据层（DWS层）。汇总数据层在明细数据层之后面向主题进行主题数仓建设，主题数仓建设一方面是为提升主题内的查询效率，一方面也希望针对后续主题使用场景，对某些维度和事实进行预汇总，以便于后续使用。五是数据应用层（ADS层）。数据应用层在数仓的最后面向应用进行进一步的使用优化，目前在医保数据中台中主要有两个使用场景，即面向报表应用、面向子系统应用。六是维度数据层（DIM层）。维度数据层贯穿后几层的使用，主要提供一致的维度数据。维度数据主要由主数据等组成的高基数维度表和数据字典等组成的低基数维度表构成。七是临时数据层（TMP层）。临时数据层主要服务于查询的中间结果或临时结果，不做长期存储。

各层间数据转化约定主要包括以下几个方面：一是STG到ODS层。由于ODS层主要实现元数据统一化，因此，在STG到ODS层的过程中，主要需要完成数据转换，包括表结构、表名、字段类型、字段名的转换等。二是ODS到DWD层。DWD层可实现数据的全标准化，因此，在ODS到DWD层的过程中涉及大量的数据质控和数据清洗工作。这里的数据质控包括国家下发规则的质控以及地方面向业务需求的拓展。质控的主要目的是通过质控规则发现数据问题，包含清洗前质控和清洗后质控，而清洗的主要目的是对发现的数据问题进行修正或提出修正建议。在这个过程中的数据清洗包括通过智能化手段进行数据贯标、数据值域的转换，实现数据的去重、去除数据表间的不一致性、全局或准全局数据信息抽取和补全等。三是DWD到DWS层。该步骤中针对规划的主题进行数据表合并、字段行转列等工作，其实施方式需要兼顾业务需求及OLAP引擎特性进行具体设计。四是DWS到ADS层。该过程中主要面向具体的使用场景，进行进一步的数据转换和聚合，以便于最后的使用，并提升场景中的查询速率。

4.2.2 数仓应用优化

当前医保数据中台对应用的支撑方式主要是各个应用独立从数据中台中取数进行分析统计，存在统一指标重复计算多、各应用统计口径不一致的情况。此外，数仓应用层的组织方式和表设计暂未针对大数据OLAP引擎进行优化，难以发挥引擎的最大优势。为优化当前存在的问题，可对各个应用的统计需求重新进行主题化组织，面向主题和引擎特性进行表设计，统一进行指标输出，这在优化问题的同时，也可以在一定程度上避免未来子系统扩展而导致计算需求快速扩张的问题（因为有些指标不再需要重新计算）。

4.2.3 新型联机分析处理（OLAP）引擎引入

目前，大数据社区中不断有新的高性能OLAP引擎推出（如Presto、ClickHouse等），可以将这些引擎引入医保数据中台，以进一步提升医保数据中台的OLAP性能。

5 总结与展望

医保数据中台是医保进一步迈向大数据的标志。当前，各地医保数据中台的建设为未来医保数据中台的发展打下了坚实的基础。虽然目前医保数据中台的建设离其他行业完整的数据中台建设仍有一定的距离，但可以预见的是，随着各地医保数据中台使用的深入和数据中台使用需求的增多，医保数据中台将会逐渐在各地经验的积累下从“指南”走向“标准”，不断随着医保大数据的应用共同成长，最终实现医保大数据应用的智能化，并不断向着智慧化方向发展。