临床医疗大数据治理框架

笔者从事医疗信息化多年，而今医疗大模型正当风头无两，而实际落地的应用门可罗雀。无论如何，大模型将是未来的行业的重要方向，而沉淀在各大医疗机构的临床数据极有可能在未来发挥更大的价值，在此梳理医疗大数据治理体系，仅作学习记录，欢迎同行专业人士阅后探讨与指点。

笔者认为医疗大数据治理分为以下4个方面：数据集成，数据存储，数据清洗，数据应用，以下分别从这几个方面分别进行简要介绍。

1 数据集成

1.1 通用数据模型设计

由于国内医疗信息化行业的厂商较多，医院内分散着众多来自不同厂商的信息系统，因此医院的数据平台建设首先要做的便是将不同系统中的数据进行集成，包括HIS CIS RIS EMR LIS 等。数据集成过程是一个脏活、累活，原因是不同信息系统之间对于同一个字段的数据存储格式可能不同，且业务系统的数据标准化程度不高，其设计本身只是为了满足临床的业务需求，可能根本不会关注数据质量，因此数据模型设计的通用程度就显得非常重要。OMOP针对临床科研出了一份通用数据模型(CDM)，但对于国内的可适配性较差，因此需要结合国内的实际情况，进行通用数据模型的设计。
CDM的设计需要首先要考虑的问题是要集成哪些数据，临床业务数据库中所有的表数据是否都要无脑接入，当然不是！像业务系统的配置表信息、操作日志、操作过程记录等一般不会关注，通用数据模型关注的是特定的时刻医务人员出于对患者进行健康关怀而进行一系列操作的结果，例如翼医生为患者开具处方，在通用数据模型中的体现是一张处方的结果，而对于审方的流程所涉及到过程不会关注。

1.2 数据集成方式

数据集成一般分为以下几种方式：开库，接口，视图
开库：即对方厂商提供生产库或备份库的只读账号，直接对接数据库，通过ETL工具进行数据抽取。
接口或视图：厂商本身有一套提供数据的接口、视图 或 处于收费目的而开发的
对接效率上，一般开库的效率最高，视图或接口调试周期相对较长

2 数据存储

2.1 业务数据库

临床业务数据库通常采用传统的关系型数据库来存储，如SQLSERVER，MySQL、ORACLE，这三种关系型数据库语法区别不大，入门难度低，方便运维，有较好的稳定性。也有部分HIS厂商如某华用的是国外的一款数据库，在国内比较小众，这个对DBA不太友好，跳槽难度较大…
总而言之，临床业务数据库一般采用传统的关系型数据库，稳定性较好，基于关系模式进行数据库设计。为了提高查询效率，对于一些大表会进行分库分表的操作，例如只存储今年的数据，往年的数据分开存储。

2.2 数据仓库

很多人可能联想到医院的历年来的数据量非常大，集成到一个地方传统的关系型数据库肯定hold不住。在笔者看来，基于单体医院数据中心的数据库选择，传统的关系型数据库完全可以cover。除却影像文件之外，普通三甲医院近10年的数据量，过滤掉一些配置数据、日志记录、审计数据，数据量在1-3T之间，部分大表完全可以采用分表的方式来解决，个人推荐PG。

3 数据清洗

数据清洗依然是一个比较耗费精力的体力活，原因是数据清洗的标准往往是企业内部制定的，尚未形成行业标准。而制定企业内部的数据标准本身就是一件复杂且涉及到多方角色的事情，需要让研发、产品、数据治理团队之间的达成共识，在共识的标准基础上进行产品设计、产品研发和数据清洗才会让各个角色工作开展的更加顺畅。但现实往往为了赶进度，产品研发或者数据清洗工作在没有形成标准的时候已经开始，当产品正式上线时，产研团队和数据治理团队就开始上演“谁是大厨”的戏码。
笔者认为，数据清洗主要包含以下几个部分：数据维度清洗（患者维度，就诊维度）、数据类型统一（数据类型转换、脏数据过滤）、小字典映射（例如 性别，婚姻状态等）、大字典映射（如诊断、检验等字典）。
数据清洗不是一次性工作，清洗到何种程度没有标准，会随着产品需求或认知的变化而迭代，前期需要把数据维度统一、类型统一、基本的编码名称映射做完。

4 数据应用

当下医疗数据的主要应用于临床科研、医疗质控、统计报表。
讲真，由于数据质量问题，临床数据应用于科研还有很长的路要走，需要医生、信息化厂商共同重视数据质量，才能发挥医疗数据的价值。