区域医疗平台设计(中)

在平台级项目开发中，选型和设计的重要性不言而喻，设计是软件开发的先导，是对系统整体结构和功能的规划和布局，在对医疗软件业务的深刻理解之上，分析系统功能和业务流程，确定合适的技术架构和数据模型，定义接口规范，最终才能达成目标。

本文在技术选型上遵循的思路：用成熟的互联网技术逐渐升级改造医疗中的传统技术体系。互联网技术比传统技术有更有预期的发展性，更活跃的社团性，更先进的技术性。有时候选择大于努力，充分利用已有的成熟轮子，选型得当后续活干得少。

代码未动，设计先行，考虑篇幅的限制，本章节先概述选型原则和设计思路，实现内容在后续分章节说明。在建设思路中已经勾勒了技术框架的组成诉求，去掉具体的业务模块部分，区域医疗平台可以由4个通用部分组成。

平台设计示意图中的业务中台包括业务开发框架和业务协同框架，数据中台包括数仓体系和数据计算。这里的数据计算可以是常见的指标计算，标签画像的体系，成熟的机器学习体系，以及基于LLM构建的智能体系，共同支撑上层应用，以及医疗涉众的使用。

2.1 开发框架

医疗体系业务极为庞杂，分为院内系统和区域系统，院内系统按照国家卫计委2018年发布的《全国医院信息化建设标准与规范（试行）》明确了医院应用系统功能多达200多个，区域系统也不少，而且业务体系更加复杂。所以在设计医疗业务系统，需要根据业务场景和数据容量，选择合适的开发框架。以前有很多医疗体系中有不少老系统基于net设计，但目前基于信创要求，会逐渐要求转到自主可控/开源体系中。

业务系统可采用B/S架构，推荐采用Java生态体系来建设，以符合信创的要求。根据项目特点和规模采用单体结构或微服务结构，业务系统的开发框架可以自研脚手架，也可以根据成熟的开源产品进行产品化。现在基于Java的开发框架已经很成熟，也有成熟度较高的开源产品，直接选择轮子就行。

2.1.1 单体框架

如果是10年前，会推荐JeeSite，不过之后有部分代码闭源了。所以现在做单体系统，可以是采用JSite，前端用的AdminLTE3 + Beetl3。如果感觉界面不怎么顺手，可以用TopJUI前端框架来改造前端，基于高版本的jQuery EasyUI构建，适用于MES、ERP、HIS、CRM、OA等后台系统的开发，而且界面已经脱离了EasyUI早期版本的经典式样，有了明显现代化的前端呈现。讲到这里，为dorado前端框架感到惋惜，逐渐小众化了。

单体系统的开发和部署都很方便，还可以搭建Svn/Git + Jenkins + Maven + SonarQube实现日构建系统，规范化开发。如果数据量在增大，可以采用读写分离以及分库分表方式，再配置Redis进行热点数据缓存提升系统性能，实现科室级的项目快速开发。如果这是大科室，访问量有点多，可以部署个nginx进行粘性会话配置，实现系统的扩展。

在单体项目开发中，系统同样可以分为前端和后端两大部分，之所以保留这套体系是因为有很多科室级别的项目适合这种模式，而且架构简单，适合熟练业务的开发人员在前后端开发时同步搞定，避免前后端拆开之后的人力损耗，而且借鉴dubbo + zookeeper体系，也可以拆分为前后端模式，实现急速开发和快速拆分。

1. 前端：前端展现层，基于springMVC + bootstrap + css展现框架

2. 后端：控制层 + 业务逻辑层 + 数据访问层 + 数据库层

代码生成

中后台的应用有大量基于表的常规增删改查功能，可以采用代码生成方式来生成前端和后端代码，并符合预设的目录和代码规范结构，简化开发工作量，以便快速部署。

从历史的角度来看，代码生成只是平台业务开发体系的初级阶段，基于模版按照预设规则生成围绕表的增删改查的通用代码。在表单设计器/低代码平台中有了更高级方式，围绕页面表单生成相应逻辑的业务处理，设计者拥有更多的处理选项。

2.1.2 前后端分离

大江东去浪淘尽，曾经的单体架构也从小甜甜变成了牛夫人。基于现在的技术体系一般起手就是前后端分离的体系，前端从springMVC改成了Vue方式。不是说springMVC不行，而是在互联网模式中从支持微服务体系、前端处理性能上看不是最合适的选择。

采用这种开发模式下，人力成本会提升很多，医疗行业需要有多年经验的业务开发人员参与其中，这些从远古时代存留下来的业务开发人员熟悉的是单体技术栈，所以需要给他们配置一个前端开发人员。

如果是新建前后端分离的项目直接基于若依或者ruoyi-vue-pro作为基础开发框架。推荐ruoyi-vue-pro，基础框架的源码全公开，设计良好的dependencies，基于Maven Module技术体系的常用业务功能扩展，集成了mybaits-plus，redis，mq，job等。另外ruoyi-vue-pro有springCloud的微服务版本，这样方便业务的迁移和升级，只是要注意2个版本的module扩展不完全一样，有细微区别。

1、项目结构

RuoYi-Vue 全新 Pro 版本，优化重构所有功能。基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + UniApp 微信小程序，支持 RBAC 动态权限、数据权限、SaaS 多租户、Flowable 工作流、三方登录、支付、短信、商城等功能。

有3种前端（越靠后颜值越高）

1. yudao-ui-admin-vue2，基于 Vue2 + element-ui 实现的管理后台

2. yudao-ui-admin-vue3，基于 Vue3 + element-plus 实现的管理后台

3. yudao-ui-admin-vben，基于 Vue3 + vben(ant-design-vue) 实现的管理后台

2、基于mybatis-flex的改造

原版ruoyi-vue-pro采用的是mybatis-plus作为orm，也是大多数脚手架的选择，而且ruoyi-vue-pro在mybatis-plus的基础上做了功能的提炼，抽象了一些常用的处理扩展作为抽象类方便使用。只是本人在使用中发现mybatis-flex提供了相似功能，并且有更通用的表达。下面的代码就是对比效果，被注解的是mybatis-plus的扩展写法，外面的是基于mybatis-flex写法，纯个人喜好。

@Mapper
 public interface DeptMapper extends BaseMapper<DeptEntity> {
   /*default List<DeptEntity> selectList(DeptListReqVO reqVO) {
     return selectList(new LambdaQueryWrapperX<DeptEntity>()
         .likeIfPresent(DeptEntity::getName, reqVO.getName())
         .eqIfPresent(DeptEntity::getStatus, reqVO.getStatus()));
   }*/
   default List<DeptEntity> selectList(DeptListReqVO reqVO) {
     return selectListByQuery( QueryWrapper.*create*()
         .where(*DEPT_ENTITY*.NAME.like(reqVO.getName(), If::*notNull*))
         .and(*DEPT_ENTITY*.STATUS.eq(reqVO.getStatus(), If::*notNull*)) );
   }
   /*default DeptEntity selectByParentIdAndName(Long parentId, String name) {
     return selectOne(DeptEntity::getParentId, parentId, DeptEntity::getName, name);
   }*/
   default DeptEntity selectByParentIdAndName(Long parentId, String name) {
     return selectOneByQuery(QueryWrapper.*create*()
         .where(*DEPT_ENTITY*.PARENT_ID.eq(parentId)).and(*DEPT_ENTITY*.NAME.eq(name)));
   }
 
   /*default Long selectCountByParentId(Long parentId) {
     return selectCount(DeptEntity::getParentId, parentId);
   }*/
   default Long selectCountByParentId(Long parentId) {
     return selectCountByCondition(*DEPT_ENTITY*.PARENT_ID.eq(parentId));
   }
 }

2.1.3 微服务框架

采用前后端分离的项目，在业务使用量起来后，可以方便的迁移到微服务体系，尤其是alibaba的微服务体系。注意不是使用了微服务技术就是微服务平台，有一些平台虽然使用了微服务技术（SpringCloud 或ServiceComb），但只是实现了平台本身架构是微服务的，而基于平台二次开发的项目却是单体的，要看平台是否支持用户自行扩展新的服务，且可以做到各服务之间的数据库隔离，这样做出来的项目才能称得上微服务项目。

如果是采用ruoyi-vue-pro迁移到yudao-cloud，则更加方便，修改若干配置即可。如果在开发过程中没有完全遵循微服务的划分，有模块之间的横向api调用，则需要改成微服务模式。从功能上看和ruoyi-vue-pro基本类似，采用了alibaba的springCloud技术栈，增加了nacos，racketMQ，gateway等微服务基础组件，同时把Job和事务改成了xxl-job和seata。

表单建模器

　　之前的代码生成器的模式比较固定：要么从数据库读取已经定义好的表结构，工具生成实体部分代码，或者是与框架强相关的不同层次的服务代码；要么从配置文件，再反向生成数据库代码或者业务相关代码；还有可能先定义实体类，再生成其他部分代码。生成代码之后，再拷贝到具体的代码目录。

　　在脚手架开发的基础上，可以套用一个表单建模器，给后端开发人员提供一个快速界面开发的选项。基于表单建模器的开发：首先需要面向业务实现表单与实体模型之间的映射；其次运行时CRUD等与数据存储相关操作，以及自动生成Id、自动添加审计日志、动态生成各种Sql语句、自动方法验证等；然后可以定义与实体模型相关的动态方法执行，包括通用的增册改查、分页获取数据等、执行自定义的Sql语句，还可以执行反射或者微服务调用定义等。

表单建模器能够快速创建常规的业务模块，可以把常规的业务功能做成模板，方便快速的创建业务模块功能，选择一个模板之后，会将模板对应的表单、子表单、子视图、控件等所有自定义表单相关的定义全部自动创建出来，通过底层一套schema或DSL规范约束，生成JSON Schema；表单引擎通过加载JSON Schema渲染出表单。

不过要实现复杂的业务，单纯的表单建模器不一定合适，本身医疗体系中面向患者的业务处理就很复杂，建模器的预设组件是覆盖不了全部的医疗业务，强行匹配会适得其反。可以根据医疗业务的特点，把系统分为面向管理者的中后台业务和面向患者的前台业务，中后台业务可以采用代码生成、表单建模、或者低代码平台；而前台业务还是需要前端开发人员根据实际业务去设计，根据业务特点去适配界面。

关于MIT协议

ruoyi-vue-pro和yudao-cloud采用的MIT协议，这是一种非常宽松的开源许可证，允许软件在保留版权和许可证声明的前提下，免费使用、复制、修改、合并、出版、分发、再授权和销售等。该许可证适用于几乎所有类型的软件，包括商业软件和专有软件。

2.1.4 低代码平台

基于前后端分离或者微服务体系的脚手架，为医疗业务的实现提供了良好的基础，只是有一类中后台管理的业务，涉及大量的基于表的增删改查业务和业务审批的业务，相对业务比较规范，可以采用低代码平台实现相应的业务，最终形成中后台管理业务由低代码平台实现，复杂医疗业务由前后端/微服务脚手架实现，从而优化开发过程。

低代码基础架构可分为四个部分：由核心引擎（页面、模型、工作流程、API编排）实现前端交互和业务编排的效果；可视化设计平台对接开发者，实现平台的表单设计和业务设定；平台门户提供通用的技术组件和常规业务模板；运营管理是平台的基础组件部分，对平台的运行状态进行检测与管理。

开发者使用低代码进行应用开发时，需要主数据设定，领域建模、页面建模、服务编排、编译出码和部署运营等环节，其中页面建模与服务编排是核心开发环节。

低代码平台中，主要由建模引擎和编排引擎支撑用户的前端页面操作。其中建模引擎支撑静态模型构建，编排引擎支撑动态逻辑流转。建模引擎支撑开发者在前端开发界面对应用程序的业务逻辑、数据结构和界面布局等进行设计和构建的行为，包含数据引擎、表单引擎、页面引擎、领域建模引擎等。编排引擎支撑用户可视化编排应用的数据表单流转、自动化管理、服务调度，包含流程引擎、规则引擎、消息引擎、事件驱动引擎等。在建模引擎和编排引擎的共同作用下搭建完整的应用外壳。

现在业界也有了一些低代码平台，从开源角度看，成熟度高的是Jecloud。Jecloud分为社区版和商业版本。社区版提供了基础的低代码开发功能，以及OA审批功能。商业版多了括门户展示套件，接口引擎，文档套件，手机套件等扩展组件。

平台功能架构分为：存储层、平台层、应用层、展现层。根据其不同层级划分，开发和运维人员可根据不同的部署及实施方案构建出可用性强、扩展性高的应用。

1. 存储层：用于数据库的存储及文件的存储。用户可以根据需求使用相同或独立数据库。

2. 平台层：主要提供低代码及通用服务能力，主要包括网关服务、元数据服务、RBAC服务、消 息服务、文档服务等。

3. 应用层：主要提供业务服务的能力，用户可基于平台层快速创建及发布业务服务，从而以 JECIoud为底座构建出高可用的微服务应用。

4. 展现层：主要提供前端多端展示的能力，用户可以基于元数据解析引擎的配置、微应用的平台 插件开发及移动端的多端配置开发快速构建多端的展示应用。

Jecloud界面颜值高，做出来的效果和界面漂亮，在颜值即代表正义的当下，是一款不错的开箱即用低代码平台。Jecloud是一套基于ServiceComb的微服务体系，特别适合信创平台。Jecloud包括go和java部分，其中java部分开源，go是用来管理各个微服务的应用。

服务名称	占用端口	用途	说明
mysql	31306	数据服务	基础服务
Redis	31379	提供二级缓存等	基础服务
openresty	80	网关代理	基础服务
comb	30100/30103	注册中心	基础服务
apollo	8070/8080/8090	配置中心	基础服务
gateway	3050	业务网关	jecloud服务
meta	3051	元数据	jecloud服务
rbac	3052	权限管理	jecloud服务
connector	3053/7010	连接器	jecloud服务
workflow	3054	工作流	jecloud服务
demo	3055	demo	jecloud服务
document	3056	文档	jecloud服务
message	3057	消息	jecloud服务
job	3060	job	jecloud服务
operator	3061	operator	jecloud管理（go）
jinit		jinit	jecloud管理（go）

前面阐述了4款开发框架的形态，也是开发平台的发展过程，总有1款适合当前的业务开发。考虑到医疗体系的复杂和多样性，推荐采用2套以上的框架，混合适配不同的场景开发，通过微服务做各个模块的服务集成。

一种可能的场景是后台管理型的业务可以采用低代码平台的模式；而面向患者的业务系统采用单体模式或者前后端模式；对于互联网的惠民应用，在后台服务的基础上生成APP应用页面或者微信小程序前端，就能涵盖医疗业务体系的方方面面。

前文阐述了基于表的业务模块开发，围绕表单进行用户的交互。还有一种是基于业务流程的开发，有2种业务流程：人-机交互的人工审批流程，机-机的自动处理流程（服务编排），Jecloud已经提供了基于Activiti7的审批型流程设计，但如果是基于微服务编排的业务逻辑，则需要服务编排引擎来支撑，两者应用场景不一样，所以设计思路也不同，需要区分对待。

2.2 服务编排

服务编排的概念是微服务架构落地伴生而来，原本一次请求即可处理完成的业务，现在可能需要多次请求才能完成，为了降低前端逻辑的复杂性并提高前后端交互效率，BFF层应运而生。BFF作为前后端的代理层，提供了一个业务接口聚合层，其核心职责是为前端（PC、小程序、H5等）适配不同的业务场景，降低客户端与业务端的耦合，前期通过硬编码的方式来实现BFF层的需求，是最简单最直接的方式。但随着BFF层承接业务需求的增多，采取硬编码方式容易产生编码效率低、编码细节难以规范、调试测试效率低等问题。

服务编排在统一规范的基础上提供了业务逻辑的柔性设计，通过可视化设计快速的API的编排、调试、测试和上线。看上去服务编排和工作流引擎在形式上趋同，但两者不一样。在脚手架/低代码平台会提供类似Flowable 、Activiti、Camunda实现的OA审批工作流系统。这种工作流基于表单模式，通过扩展表或者表单表上添加辅组字段满足业务的审批流转，最终形成留痕记录。这种模式都是人-机交互模式，而服务编排，更多的是机-机交互模式，强调的是服务（API）的有序调用。

2.2.1 BFF的作用

微服务体系架构是一种前后端架构，在前后端之间添加中间层 (BFF：Backend For Frontend)，以解决服务的汇聚和调用，把BFF加入在前后端架构之后，前端服务不再直接访问后端微服务，而是通过 BFF 层进行访问。从微服务的角度来看，由于有关 UI 逻辑的数据在 BFF 层进行了处理，减少前后端细颗粒微服务之间的相互调用。

BFF层的主要职责是组合使用后台数据，稍微额外处理C端展示逻辑。可以参看前章的“基于tuxedo的API编排架构”的内容。综上所述，采用BFF之后的开发逻辑：通过后台工具查到原始数据，然后按照业务要求，把查到的原始数据封装成API，再通过加工->组装->适配成可以展示给前端的信息，最后发送给客户端使用。这部分各个服务（API）的聚合工作主要由中间层的BFF API负责。

BFF API的处理也是有一定的业务逻辑，可以抽象为串行，并行，分支，汇聚等，包括多种服务接口的适配，可视化业务逻辑的设计，持久化保存需求，接口返回数据的裁剪、排序、格式化等操作，这些功能又可以映射为BPM的能力。所以最终支持BFF层运行的底层组件是BPM系统，提高提升微服务的复用度，降低编码及编译打包的等待时间，提高业务逻辑的快速交付能力。

2.2.2 BPM的定位

可视化服务编排系统的核心功能都是对BFF日常需求及研发流程的抽象，从接口的调用方式、出入参的处理、接口异常情况的处理、服务的调试测试、服务的上线流程等几个维度完成系统整体功能的设计。

A、实现思路

1. BFF 层中的BPM 系统可以用于定义和管理API的聚合逻辑，包括不同微服务之间的调用顺序、条件和数据处理流程。

2. BPM 系统可以充当一个中心化的控制器，负责协调和管理各种微服务之间的交互，从而简化前端与后端微服务之间的通信。

3. 通过 BPM 系统，可以实现复杂的业务流程和逻辑，将这些逻辑从前端和后端微服务中解耦出来，提高系统的灵活性和可维护性。

B、具体方案

1. 在 BFF 层引入一个BPM 系统，用于定义和管理API 的聚合逻辑。

2. BPM 系统提供可视化流程配置界面，方便业务人员定义和修改流程规则。

3. BPM 系统需要与微服务架构无缝集成，可以通过WebService/Rest/SpringBean 或消息队列等方式与后端服务进行通信。

C、BPM 系统选型

1. Camunda：开源BPM，提供强大的工作流和决策引擎，适合用于复杂的业务流程管理。

2. Flowable开源BPM，具备良好的灵活性和可扩展性，支持BPMN/DMN/CMMN标准。

3. Activiti：开源BPM，具有轻量级和易扩展的特点，适合用于中小型项目的流程管理。

4. 自研BFM：考虑到Camunda/Flowable/Activiti在执行中需要落盘处理，以及自身实现的复杂性，导致性能不高。高性能服务编排本身只是一段胶水代码，不能给原生服务调用产生额外的负担，可以自研轻量级服务编排系统（BFM）。

5. 也可以采用轻量级服务编排，诸如jd-easyflow和liteflow等

核心功能

1. 接口调用：接口间调用关系可以抽象为：串行调用、并行调用、排他调用

2. 参数处理：包括入参/出差，静态/动态参数，动态参数的值来自外部接口的返回值

3. 异常处理：在异常场景下，流程能执行一个预期的分支，并把异常信息能捕获

4. 调试测试：需要输出编排执行的输出日志，以及异常信息的捕获

5. 服务部署：引擎可以分为单节点部署和多节点部署，不同的节点执行不同的业务流程，同时因为不是硬编码，所以业务逻辑的部署实现了类似定义即部署的方式。

2.2.3 服务的管理

当平台积累了大量的后台服务，如何有效使用是平台设计的重要内容。服务首先要归类，做好领域划分，然后服务的命名和版本要规范，服务的出参和入参要考虑方便和实用。

A、平台服务列表

1. 区域卫生平台接口：医共体平台通过与区域平台对接，实现业务协同和数据共享；

2. 区域业务应用接口：妇幼保健、远程医疗、远程心电、区域LIS、区域PACS等；

3. 区域协同应用接口：注册服务、主索引服务、远程会诊、双向转诊、检查检验结果共享、协同公卫报病、协同提醒、健康档案调阅等；

4. 公立医院内部系统接口：医院平台、HIS、LIS、PACS、EMR、HRP等；

5. 基层医疗机构内部系统接口：基层医疗、公共卫生、家庭签约、卫生综合管理等；

6. 便民惠民应用接口：统一支付、预约挂号、报告查询、健康信息管理等；

7. 卫生资源目录共享接口：为第三方系统（公安/民政等）提供数据订阅和数据推送服务；

8. 其它需要扩展的内部接口；

B、服务类型

服务编排需要集成不同的第三方服务和内部服务，对于这些应用，接口和参数各不相同，考虑到方便服务的集成和内部服务的稳定，可以采用：外部接口=>转换服务=>内部服务。

1. 外部服务：第三方系统提供的业务主体，对外提供Rest、WebService以及RPC

2. 内部服务：平台内部实现的服务，提供本地调用的模式或者rest等，以及通用POJO或json（通用字段和扩展字段），统一异常调度处理机制

3. 转换接口：集成Rest和WebService客户端，以及Json，Map，Pojo的转换。通过转换接口适配内外接口的差异性，维系平台接口的稳定性。

3、服务生命周期

微服务API的开发纳入生命周期管理时，遵循一套开发，上线，下线，版本控制的管理。另外构建服务度量指标，通过日志和性能数据采集，监控服务运行监控状态，并执行相应的限流，预警等管控策略，以确保微服务的持续健康，可靠和高效运行。

2.2.4 编排的功能

功能自洽的区域平台的BFM-engine功能包括：

1. 支持XPDL/BPM规范的流程，包括串行，并行，条件（xor/or）,定时启动，事件启动。

2. 支持多服务接口调用，包括Rest，web服务，springbean和javabean。

3. 流程支持各个服务的参数的传入和传出

4. 支持多模式部署，包括单节点和多节点，local部署模式

5. 如果流程中的活动采用springbean服务，支持事务调用

6. 支持服务管理，根据功能领域实现基于服务目录的划分和管理，服务的参数定义和服务的版本管理，以及服务生命周期管理

7. 支持执行记录留痕，可追溯异常流程和正常流程运行/完成流程

2.2.5 状态机应用

引擎的实现会涉及到flow-act-item，彼此有依赖关系，另外自身也有状态变化，包括create-run-finish以及其他辅助状态，所以如果自研引擎，需要构建一个3层状态机模型。

对于3层状态机，每层状态机拥有自己的状态变化，同时状态变化可能会对其他状态机产生影响。这里区分2种情况：

1. 对于人工活动，它不直接面向参与者，需要item与参与者交互，同时拥有自身的状态和控制字段，并和活动作状态交互。所以对于人工活动来说，有三层状态：过程à活动à任务项。

2. 自动活动主要处理业务逻辑，没有人-机界面，不需要额外的控制，因此对于自动活动来说，它就只有两层状态，过程-活动。

2.3 数据仓库

医院/平台的互联互通为医疗健康大数据奠定了基础；同时个性化诊断、疾病预测与辅助决策等各类医疗人工智能应用也在不断涌现，医疗健康大数据的存储和分析，需要有一套体系来管理，数据仓库由此应运而生。

数据仓库主要基于业务库（OLTP）的数据以及第三方外部数据，通过采集清洗转换后存储在事实表中（事实+维度），实现系统的分析整理，支持各种分析方法，如联机分析处理(OLAP)、数据挖掘等进行，进而支持决策支持系统、从而获取有价值的信息。

数仓的建设需要根据数据采集量，指标计算的要求，周边系统的匹配度，开发人员和运维人员的熟练程度来综合考虑：

1. 采用离线数仓模式，能更好的契合医疗体系各种数据接口和来源，并做好分层设计，确保数据和指标以及中间过程数据能尽可能复用；

2. 有实时要求的情况下采取离线 + 实时的混合模式，且在设计指标的时候需要规划，确保2者指标不重合，避免2种指标统计的差异性；

3. 数仓技术底座采取混合搭建模式，ODS和DWD采用GP6/7体系，相比Hdfs+hive体系，GP更适合医疗业务场景。DWD库有EMPI做数据聚合的需求（OLTP性能），这里需要测算增删改查以及数据落盘性能，如果必要，搭建一套平行DWD计算库，并保持2者的数据批量同步；DWS部分大宽表采用ClickHouse，用以提升联机查询速度，本身ClickHouse可以作为Flink的DWS，从政务云/信创云的资源和数据规模考虑，可以不用Drois，从而节省资源

4. 在实施机器学习的计算需求，可以采用MADlib，作为廉价机器学习的技术底座。

5. 在实时LLM人工智慧的计算需求，可以采用chatGLM4-9B/Qwen-72B，作为本地部署的基础模型，同时实施RAG来提升LLM的垂直业务能力。

对于数据仓库而言，无论怎么升级和变化，其设计目标是一致的，要求如下：

1. 适配业务场景和性能要求，选择合适的技术组件搭建数仓体系；

2. 层级结构清晰，设计合理、避免交换中心直接产出报表；

3. 数据一致性保证，避免信息孤岛产生；剔除过度冗余数据。

4. 高数据质量：数据全、数据质量高、数据好用、可扩展、安全性、及时性。

5. 应对业务、需求的变更，具备一定的稳健性。

2.3.1 数据存储

医疗体系平台采用离线批处理方式能兼容最大多数的数据源，方便最大范围的采集数据。在当前考虑关系型数据的情况下，数仓可以采用MPP 数据库；在将来构建区域一统的多模态数据资源池的时候，可以考虑采用数据湖体系。

数据湖和数据仓库作为大数据系统的两条不同演进路线，各有适用范围。数据仓库适合处理结构化的数据可以实现良好的分析与处理，但对于非结构化数据、半结构化数据以及种类繁多、存储量大的数据就需要数据湖来处理。

数据湖并不比数据仓库在处理流程上多出了什么内容，更多的在于结构性的变化，2种处理方式，代表着两种数据处理和服务模式，是数据技术领域的一次轮回。

1. 数据湖可以使不同格式的原始数据汇聚，无需预定义模型即可为大数据分析、机器学习、预测分析等提供支持。数据湖虽然适合存储海量数据，但有些缺陷无法避免：数据湖无法面向事务进行处理，无法提高数据质量，因缺乏数据一致性，使得输出结果几乎不可能被混合读取和分析，以及无法实现流批处理。

2. 数据仓库的处理会经历清洗和转换，对于原始数据而言可能发生了变化，而数据湖则可以利用数据湖提供的工具流接触到原始数据，涵盖了从数据采集、抽取、存储、加工的各个阶段，提升了数据对业务的理解，发挥出原始数据的最大价值，也最终有利于将来LLM在真实原始的数据上进行分析和推理。

2.3.2 数据来源

数据仓库的数据来源包括健康医疗大数据和其他行业数据来源。健康医疗大数据主要包括汇聚个体和各类医疗卫生业务机构数据所形成的全员人口、电子健康档案、电子病历、各垂直系统的业务管理数据等。其他行业数据来源包括教育、公安、民政、人力资源、社会保障、农业、安全监管、检验检疫(气象、保险监管、残联等相关部门及行业。

这些数据源来自各个医疗机构的业务库，汇聚到交换中心的时候需要根据国家规范进行转换清洗，形成区域一统的数据标准。也可以采用CDA作为数据来源进行采集，但一般来说，CDA的数据质量不如交换库的采集模式。

2.3.3 标准规范

数据标准是一套由管理制度、管控流程、技术工具共同组成的体系，通过这套体系来推广和应用统一的数据定义、数据分类、纪律格式和转换、编码等来对数据的标准化，保障数据定义和使用的一致性、准确性和完整性的规范性约束。不限于如下标准：

1. 区域业务基于健康档案的区域卫生标准规范

2. 医疗机构基于电子病历的业务应用标准规范

3. 业务协同及基层综合管理应用标准规范

4. 第三方系统接入标准规范

在数据类规范中，通常着重对数据集、数据元、代码以及数据交换接口的内容进行标准规范，从业务数据的角度，针对信息化建设的需要进行业务标准的编制。

2.3.4 数据模型

在医疗体系中，数据模型贯穿整个业务领域和数据ETL的过程（ods-dwd-dws）。在业务领域中，医学元数据结合领域信息模型可以被用来构建医疗数据的语义表达，从而更全面地表达和描述电子病历。医学元数据通常包括医学数据的模式、定义和属性，而领域信息模型则提供了关于特定医学领域的知识和规则。

模型与数据库

2.3.5 数据治理

在基于医院数据或区域平台数据进行临床科研和数据应用开发的过程中，即使在病人数量足够的情况下，数据的可用性依然存在问题。目前影响医疗数据质量的原因如下：

1. 原始数据在录入过程中有数据错漏、数据不完整等问题。

2. 系统间/区域内缺乏统一的元数据标准，数据融合困难。

3. 系统间/区域内缺乏统一的主数据管理，病人、医生等医疗应用中的核心数据实体难以被唯一标识并实时更新。

4. 数据清洗缺乏统一的策略，导致数据被多次清洗，使用代价高。

5. 由于缺乏元数据和主数据标准，即使数据被勉强放在一起，数据可达性也很差，无法知晓每个字段的确切含义和具体取值范围，难以基于简单的查询找到需要的数据。

6. 大量医疗数据以文本、影像、图像等非结构化的方式存储，增加了管理和整合的难度。

7. 在规划层面还是在操作层面，数据隐私管理、数据使用的权限与流程都缺乏指导性的技术标准和规范，导致虽然采集存储了很多数据，但不知道谁可以用、如何使用的问题。

A、数据治理的层级

在医疗体系中，将医疗数据治理按管理机构分为4类，本文更关注第2类。

1、医院数据治理

医院成立数据管理部门，完成流程和规范制订、数据质量保证和质量控制、流程审批等工作，并对数据使用方和IT设施建设方进行管理，对其数据资产的管理和控制，支撑并保障数据被安全、高效地交换与使用。

2、区域数据治理

与医院数据管理内容相似，但实施起来难度更复杂：

l 主数据管理和元数据管理的复杂度高：病人基础数据是临床医疗信息的主数据。区域数据来源于多家医院，每家医院病人用的身份标识不一样，病人基础信息也会有差异。需要通过统一标识来统一病人的主数据，并关联病人在不同医院的就诊记录。

l 数据安全性管理更严格：区域数据量比较大，病人的就诊数据在时序上更完整，因此数据泄露带来的严重性更大，区域对数据安全管理的要求更严格。

3、专科联盟/专科医联体/专病中心的数据治理

专科联盟一般由权威医疗机构牵头，但是其牵头单位并没有行政权力，联盟单位之间的协作共享完全是一种自愿的行为。因此，专科联盟形式的医联体除了要解决区域医联体中碰到的技术问题外，还要解决数据共享后的利益分享问题，确保医联体每个成员能在数据共享活动中受益。

4、医疗标注数据与知识型数据治理

数据治理主要面向的对象是病人数据，但在医院协作共享过程中，知识型数据也必不可少。在面向分析推理等智能应用，需要大量的标注数据，这些数据的管理和利用也属于数据治理的范畴。

标注数据主要是针对电子病历文本、影像等非结构化数据进行实体、属性、关系等标注得到的数据，标注数据的质量对训练深度学习或神经网络模型起着决定性作用。为了实现对标注数据的治理，应该针对不同粒度的实体建立一套完整的标注规范，对标注过程的各要素进行规范化管理，并对标注结果进行交叉验证等。

B、数据治理的内容

医疗数据治理工具平台应包含数据存储子系统、元数据管理子系统、主数据管理子系统、数据质量管控子系统以及患者数据脱敏工具等。

1、元数据管理

目前医院信息系统中存在数据模式描述文档不全、系统之间数据关联不清晰、系统值域标准不统一等问题，这为数据集成造成了困难。在区域层面，这些问题更严重。因此，需要通过元数据管理获取业务系统中数据的含义，辅助数据理解，增加分析的敏捷性。元数据管理可以提高数据的可访问性、一致性及可用性，为多种来源数据的整合搭建了桥梁。

与其他领域相比，医疗领域的元数据规范相对比较成熟，参看《国家卫生计生委办公厅关于印发住院病案首页数据填写质量规范（暂行）和住院病案首页数据质量管理与控制指标（2016版）的通知》（国卫办医发〔2016〕24号）、《病历书写规范》（卫医政发〔2010〕11号）、《电子病历基本规范》（卫医政发〔2010〕24号）、《卫生信息基本数据集编制规范》（WS 370-2012）、《卫生管理基本数据集》（WS374-2012）与《电子病历基本架构与数据标准》（卫办发〔2009〕130号）等。在数据值编码标准方面，国际上有疾病分类编码ICD-10、手术操作编码ICD-9、SNOMED术语库；国内有《卫生机构（组织）分类与代码表》（WS2182002）、《社会保险药品分类与代码》（LD/T90-2012）和《中医病证分类与代码》（GB/T15657-1995）。

虽然国家已经规范了各种医疗元数据，然而在实际落地过程中，这些标准会根据应用进行不同程度的删减和扩充，甚至出现错误的使用。因此，需要基于标准建立和实现元数据管理系统，实现对元数据的统一管理，与各个应用关联，从而实现元数据的统一。

2、主数据管理

医疗数据的主数据主要有病人信息和医生信息两类。目前，在医院层面，各业务系统对病人的信息分别进行存储，但大型医院都建立了临床数据中心（CDR），为了唯一标识一个病人，需要通过构建病人主索引号（EMPI）将存储于不同系统的病人关联在一起。这里有两个问题：

1. EMPI构建与识别。识别不同系统中同一个病人不同ID之间的映射关系十分困难，特别是在区域平台上每个系统都有独立的ID，导致该问题更复杂。

2. 病人的基础信息在各个系统间存在差异和冲突，比如在HIS、LIS、PACS中因为侧重点不同，各个系统数据填写质量不一致或数据未及时更新等问题。

为此，需要在定义系统主数据的情况下，构建主数据管理中央库，解决主数据碎片问题。可以从各业务系统抽取数据，并进行数据融合，形成完备的主数据信息，然后再将主数据信息分发给各业务系统，保证各业务系统中这些信息的准确性和完整性。这样就形成了公共的重要属性由主数据管理系统管理、各业务系统的特定属性由各系统独立管理的模式。

在构建主数据管理库时，首先从多个异构的业务子系统中以ETL的方式抽取关键数据，然后利用元数据库对其中的编码、描述进行标准化。接着通过匹配算法完成对数据的错误消除和信息融合各个业务系统的差异性数据。对于匹配不到的孤立信息，监控跟踪，以及人工处理。同时进匹配算法，最后将归整好的主数据信息并入主数据库。

3、数据质量管控子系统

从数据产生过程来看，医疗数据质量问题主要来源于3个方面。

• 原始信息采集有误差。在医疗系统内数据采集主要通过手工方式录入，在医生或护士输入信息的过程中，可能会有意或无意地将数据错误引入系统。

• 数据融合过程发生问题。在对不同来源的数据进行融合时，数据格式和语义可能会有误差或不一致，导致融合结果有错 。

• 与数据的应用场景不匹配。例如，如果要进行病例统计，现有临床电子病历数据就能满足统计场景的需求。但如果要做大肠癌疗效分析，现有临床电子病历数据就难以满足分析场景的要求，还需补充病理数据。

在医疗数据治理过程中，需要了解最终的使用场景，也需要从业务系统的数据源头控制质量，并保证每个融合和加工过程的正确性。另外出现数据错误时，进行数据修正。

因此质量管控平台包括了数据质量监控、数据质量评估以及数据修正。数据质量监控主要针对从业务系统抽取的或是从外部传送的接口数据，从及时性、有效性和完整性等几个指标监测接口内容本身的数据质量问题，对采集程序进行监控；数据质量评估是指对融合后的数据进行质量评估。