平臺級項目開發中，選型和設計的重要性不言而喻，設計是軟件開發的先導，是對系統整體結構和功能的規劃和布局，在對醫療軟件業務的深刻理解之上，分析系統功能和業務流程，確定合適的技術架構和數據模型，定義接口規范，最終才能達成目標。

本文在技術選型上遵循的思路：用成熟的互聯網技術逐漸升級改造醫療中的傳統技術體系。互聯網技術比傳統技術有更有預期的發展性，更活躍的社團性，更先進的技術性。有時候選擇大于努力，充分利用已有的成熟輪子，選型得當后續活干得少。

代碼未動，設計先行，考慮篇幅的限制，本章節先概述選型原則和設計思路，實現內容在后續分章節說明。在建設思路中已經勾勒了技術框架的組成訴求，去掉具體的業務模塊部分，區域醫療平臺可以由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體系，也可以拆分為前后端模式，實現急速開發和快速拆分。

0. 前端：前端展現層，基于springMVC + bootstrap + css展現框架
1. 后端：控制層 + 業務邏輯層 + 數據訪問層 + 數據庫層

代碼生成

中后臺的應用有大量基于表的常規增刪改查功能，可以采用代碼生成方式來生成前端和后端代碼，并符合預設的目錄和代碼規范結構，簡化開發工作量，以便快速部署。

從歷史的角度來看，代碼生成只是平臺業務開發體系的初級階段，基于模版按照預設規則生成圍繞表的增刪改查的通用代碼。在表單設計器/低代碼平臺中有了更高級方式，圍繞頁面表單生成相應邏輯的業務處理，設計者擁有更多的處理選項。

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種前端（越靠后顏值越高）

0. yudao-ui-admin-vue2，基于 Vue2 + element-ui 實現的管理后臺
1. yudao-ui-admin-vue3，基于 Vue3 + element-plus 實現的管理后臺
2. 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審批功能。商業版多了括門戶展示套件，接口引擎，文檔套件，手機套件等擴展組件。

平臺功能架構分為：存儲層、平臺層、應用層、展現層。根據其不同層級劃分，開發和運維人員可根據不同的部署及實施方案構建出可用性強、擴展性高的應用。

0. 存儲層：用于數據庫的存儲及文件的存儲。用戶可以根據需求使用相同或獨立數據庫。
1. 平臺層：主要提供低代碼及通用服務能力，主要包括網關服務、元數據服務、RBAC服務、消 息服務、文檔服務等。
2. 應用層：主要提供業務服務的能力，用戶可基于平臺層快速創建及發布業務服務，從而以 JECIoud為底座構建出高可用的微服務應用。
3. 展現層：主要提供前端多端展示的能力，用戶可以基于元數據解析引擎的配置、微應用的平臺 插件開發及移動端的多端配置開發快速構建多端的展示應用。

Jecloud界面顏值高，做出來的效果和界面漂亮，在顏值即代表正義的當下，是一款不錯的開箱即用低代碼平臺。Jecloud是一套基于ServiceComb的微服務體系，特別適合信創平臺。Jecloud包括go和java部分，其中java部分開源，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、實現思路

0. BFF 層中的BPM 系統可以用于定義和管理API的聚合邏輯，包括不同微服務之間的調用順序、條件和數據處理流程。
1. BPM 系統可以充當一個中心化的控制器，負責協調和管理各種微服務之間的交互，從而簡化前端與后端微服務之間的通信。
2. 通過 BPM 系統，可以實現復雜的業務流程和邏輯，將這些邏輯從前端和后端微服務中解耦出來，提高系統的靈活性和可維護性。

B、具體方案

0. 在 BFF 層引入一個BPM 系統，用于定義和管理API 的聚合邏輯。
1. BPM 系統提供可視化流程配置界面，方便業務人員定義和修改流程規則。
2. BPM 系統需要與微服務架構無縫集成，可以通過WebService/Rest/SpringBean 或消息隊列等方式與后端服務進行通信。

C、BPM 系統選型

0. Camunda：開源BPM，提供強大的工作流和決策引擎，適合用于復雜的業務流程管理。
1. Flowable開源BPM，具備良好的靈活性和可擴展性，支持BPMN/DMN/CMMN標準。
2. Activiti：開源BPM，具有輕量級和易擴展的特點，適合用于中小型項目的流程管理。
3. 自研BFM：考慮到Camunda/Flowable/Activiti在執行中需要落盤處理，以及自身實現的復雜性，導致性能不高。高性能服務編排本身只是一段膠水代碼，不能給原生服務調用產生額外的負擔，可以自研輕量級服務編排系統（BFM）。
4. 也可以采用輕量級服務編排，諸如jd-easyflow和liteflow等

核心功能

0. 接口調用：接口間調用關系可以抽象為：串行調用、并行調用、排他調用
1. 參數處理：包括入參/出差，靜態/動態參數，動態參數的值來自外部接口的返回值
2. 異常處理：在異常場景下，流程能執行一個預期的分支，并把異常信息能捕獲
3. 調試測試：需要輸出編排執行的輸出日志，以及異常信息的捕獲
4. 服務部署：引擎可以分為單節點部署和多節點部署，不同的節點執行不同的業務流程，同時因為不是硬編碼，所以業務邏輯的部署實現了類似定義即部署的方式。

2.2.3 服務的管理

當平臺積累了大量的后臺服務，如何有效使用是平臺設計的重要內容。服務首先要歸類，做好領域劃分，然后服務的命名和版本要規范，服務的出參和入參要考慮方便和實用。

A、平臺服務列表

0. 區域衛生平臺接口：醫共體平臺通過與區域平臺對接，實現業務協同和數據共享；
1. 區域業務應用接口：婦幼保健、遠程醫療、遠程心電、區域LIS、區域PACS等；
2. 區域協同應用接口：注冊服務、主索引服務、遠程會診、雙向轉診、檢查檢驗結果共享、協同公衛報病、協同提醒、健康檔案調閱等；
3. 公立醫院內部系統接口：醫院平臺、HIS、LIS、PACS、EMR、HRP等；
4. 基層醫療機構內部系統接口：基層醫療、公共衛生、家庭簽約、衛生綜合管理等；
5. 便民惠民應用接口：統一支付、預約掛號、報告查詢、健康信息管理等；
6. 衛生資源目錄共享接口：為第三方系統（公安/民政等）提供數據訂閱和數據推送服務；
7. 其它需要擴展的內部接口；

B、服務類型

服務編排需要集成不同的第三方服務和內部服務，對于這些應用，接口和參數各不相同，考慮到方便服務的集成和內部服務的穩定，可以采用：外部接口=>轉換服務=>內部服務。

0. 外部服務：第三方系統提供的業務主體，對外提供Rest、WebService以及RPC
1. 內部服務：平臺內部實現的服務，提供本地調用的模式或者rest等，以及通用POJO或json（通用字段和擴展字段），統一異常調度處理機制
2. 轉換接口：集成Rest和WebService客戶端，以及Json，Map，Pojo的轉換。通過轉換接口適配內外接口的差異性，維系平臺接口的穩定性。

3、服務生命周期

微服務API的開發納入生命周期管理時，遵循一套開發，上線，下線，版本控制的管理。另外構建服務度量指標，通過日志和性能數據采集，監控服務運行監控狀態，并執行相應的限流，預警等管控策略，以確保微服務的持續健康，可靠和高效運行。

2.2.4 編排的功能

功能自洽的區域平臺的BFM-engine功能包括：

0. 支持XPDL/BPM規范的流程，包括串行，并行，條件（xor/or）,定時啟動，事件啟動。
1. 支持多服務接口調用，包括Rest，web服務，springbean和javabean。
2. 流程支持各個服務的參數的傳入和傳出
3. 支持多模式部署，包括單節點和多節點，local部署模式
4. 如果流程中的活動采用springbean服務，支持事務調用
5. 支持服務管理，根據功能領域實現基于服務目錄的劃分和管理，服務的參數定義和服務的版本管理，以及服務生命周期管理
6. 支持執行記錄留痕，可追溯異常流程和正常流程運行/完成流程

2.2.5 狀態機應用

引擎的實現會涉及到flow-act-item，彼此有依賴關系，另外自身也有狀態變化，包括create-run-finish以及其他輔助狀態，所以如果自研引擎，需要構建一個3層狀態機模型。

對于3層狀態機，每層狀態機擁有自己的狀態變化，同時狀態變化可能會對其他狀態機產生影響。這里區分2種情況：

0. 對于人工活動，它不直接面向參與者，需要item與參與者交互，同時擁有自身的狀態和控制字段，并和活動作狀態交互。所以對于人工活動來說，有三層狀態：過程à活動à任務項。
1. 自動活動主要處理業務邏輯，沒有人-機界面，不需要額外的控制，因此對于自動活動來說，它就只有兩層狀態，過程-活動。

2.3 數據倉庫

醫院/平臺的互聯互通為醫療健康大數據奠定了基礎；同時個性化診斷、疾病預測與輔助決策等各類醫療人工智能應用也在不斷涌現，醫療健康大數據的存儲和分析，需要有一套體系來管理，數據倉庫由此應運而生。

數據倉庫主要基于業務庫（OLTP）的數據以及第三方外部數據，通過采集清洗轉換后存儲在事實表中（事實+維度），實現系統的分析整理，支持各種分析方法，如聯機分析處理(OLAP)、數據挖掘等進行，進而支持決策支持系統、從而獲取有價值的信息。

數倉的建設需要根據數據采集量，指標計算的要求，周邊系統的匹配度，開發人員和運維人員的熟練程度來綜合考慮：

0. 采用離線數倉模式，能更好的契合醫療體系各種數據接口和來源，并做好分層設計，確保數據和指標以及中間過程數據能盡可能復用；
1. 有實時要求的情況下采取離線 + 實時的混合模式，且在設計指標的時候需要規劃，確保2者指標不重合，避免2種指標統計的差異性；
2. 數倉技術底座采取混合搭建模式，ODS和DWD采用GP6/7體系，相比Hdfs+hive體系，GP更適合醫療業務場景。DWD庫有EMPI做數據聚合的需求（OLTP性能），這里需要測算增刪改查以及數據落盤性能，如果必要，搭建一套平行DWD計算庫，并保持2者的數據批量同步；DWS部分大寬表采用ClickHouse，用以提升聯機查詢速度，本身ClickHouse可以作為Flink的DWS，從政務云/信創云的資源和數據規模考慮，可以不用Drois，從而節省資源
3. 在實施機器學習的計算需求，可以采用MADlib，作為廉價機器學習的技術底座。
4. 在實時LLM人工智慧的計算需求，可以采用chatGLM4-9B/Qwen-72B，作為本地部署的基礎模型，同時實施RAG來提升LLM的垂直業務能力。

對于數據倉庫而言，無論怎么升級和變化，其設計目標是一致的，要求如下：

0. 適配業務場景和性能要求，選擇合適的技術組件搭建數倉體系；
1. 層級結構清晰，設計合理、避免交換中心直接產出報表；
2. 數據一致性保證，避免信息孤島產生；剔除過度冗余數據。
3. 高數據質量：數據全、數據質量高、數據好用、可擴展、安全性、及時性。
4. 應對業務、需求的變更，具備一定的穩健性。

2.3.1 數據存儲

醫療體系平臺采用離線批處理方式能兼容最大多數的數據源，方便最大范圍的采集數據。在當前考慮關系型數據的情況下，數倉可以采用MPP 數據庫；在將來構建區域一統的多模態數據資源池的時候，可以考慮采用數據湖體系。

數據湖和數據倉庫作為大數據系統的兩條不同演進路線，各有適用范圍。數據倉庫適合處理結構化的數據可以實現良好的分析與處理，但對于非結構化數據、半結構化數據以及種類繁多、存儲量大的數據就需要數據湖來處理。

數據湖并不比數據倉庫在處理流程上多出了什么內容，更多的在于結構性的變化，2種處理方式，代表著兩種數據處理和服務模式，是數據技術領域的一次輪回。

0. 數據湖可以使不同格式的原始數據匯聚，無需預定義模型即可為大數據分析、機器學習、預測分析等提供支持。數據湖雖然適合存儲海量數據，但有些缺陷無法避免：數據湖無法面向事務進行處理，無法提高數據質量，因缺乏數據一致性，使得輸出結果幾乎不可能被混合讀取和分析，以及無法實現流批處理。
1. 數據倉庫的處理會經歷清洗和轉換，對于原始數據而言可能發生了變化，而數據湖則可以利用數據湖提供的工具流接觸到原始數據，涵蓋了從數據采集、抽取、存儲、加工的各個階段，提升了數據對業務的理解，發揮出原始數據的最大價值，也最終有利于將來LLM在真實原始的數據上進行分析和推理。

2.3.2 數據來源

數據倉庫的數據來源包括健康醫療大數據和其他行業數據來源。健康醫療大數據主要包括匯聚個體和各類醫療衛生業務機構數據所形成的全員人口、電子健康檔案、電子病歷、各垂直系統的業務管理數據等。其他行業數據來源包括教育、公安、民政、人力資源、社會保障、農業、安全監管、檢驗檢疫(氣象、保險監管、殘聯等相關部門及行業。

這些數據源來自各個醫療機構的業務庫，匯聚到交換中心的時候需要根據國家規范進行轉換清洗，形成區域一統的數據標準。也可以采用CDA作為數據來源進行采集，但一般來說，CDA的數據質量不如交換庫的采集模式。

2.3.3 標準規范

數據標準是一套由管理制度、管控流程、技術工具共同組成的體系，通過這套體系來推廣和應用統一的數據定義、數據分類、紀律格式和轉換、編碼等來對數據的標準化，保障數據定義和使用的一致性、準確性和完整性的規范性約束。不限于如下標準：

0. 區域業務基于健康檔案的區域衛生標準規范
1. 醫療機構基于電子病歷的業務應用標準規范
2. 業務協同及基層綜合管理應用標準規范
3. 第三方系統接入標準規范

在數據類規范中，通常著重對數據集、數據元、代碼以及數據交換接口的內容進行標準規范，從業務數據的角度，針對信息化建設的需要進行業務標準的編制。

2.3.4 數據模型

在醫療體系中，數據模型貫穿整個業務領域和數據ETL的過程（ods-dwd-dws）。在業務領域中，醫學元數據結合領域信息模型可以被用來構建醫療數據的語義表達，從而更全面地表達和描述電子病歷。醫學元數據通常包括醫學數據的模式、定義和屬性，而領域信息模型則提供了關于特定醫學領域的知識和規則。

模型與數據庫

2.3.5 數據治理

在基于醫院數據或區域平臺數據進行臨床科研和數據應用開發的過程中，即使在病人數量足夠的情況下，數據的可用性依然存在問題。目前影響醫療數據質量的原因如下：

0. 原始數據在錄入過程中有數據錯漏、數據不完整等問題。
1. 系統間/區域內缺乏統一的元數據標準，數據融合困難。
2. 系統間/區域內缺乏統一的主數據管理，病人、醫生等醫療應用中的核心數據實體難以被唯一標識并實時更新。
3. 數據清洗缺乏統一的策略，導致數據被多次清洗，使用代價高。
4. 由于缺乏元數據和主數據標準，即使數據被勉強放在一起，數據可達性也很差，無法知曉每個字段的確切含義和具體取值范圍，難以基于簡單的查詢找到需要的數據。
5. 大量醫療數據以文本、影像、圖像等非結構化的方式存儲，增加了管理和整合的難度。
6. 在規劃層面還是在操作層面，數據隱私管理、數據使用的權限與流程都缺乏指導性的技術標準和規范，導致雖然采集存儲了很多數據，但不知道誰可以用、如何使用的問題。

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）將存儲于不同系統的病人關聯在一起。這里有兩個問題：

0. EMPI構建與識別。識別不同系統中同一個病人不同ID之間的映射關系十分困難，特別是在區域平臺上每個系統都有獨立的ID，導致該問題更復雜。
1. 病人的基礎信息在各個系統間存在差異和沖突，比如在HIS、LIS、PACS中因為側重點不同，各個系統數據填寫質量不一致或數據未及時更新等問題。

為此，需要在定義系統主數據的情況下，構建主數據管理中央庫，解決主數據碎片問題。可以從各業務系統抽取數據，并進行數據融合，形成完備的主數據信息，然后再將主數據信息分發給各業務系統，保證各業務系統中這些信息的準確性和完整性。這樣就形成了公共的重要屬性由主數據管理系統管理、各業務系統的特定屬性由各系統獨立管理的模式。

在構建主數據管理庫時，首先從多個異構的業務子系統中以ETL的方式抽取關鍵數據，然后利用元數據庫對其中的編碼、描述進行標準化。接著通過匹配算法完成對數據的錯誤消除和信息融合各個業務系統的差異性數據。對于匹配不到的孤立信息，監控跟蹤，以及人工處理。同時進匹配算法，最后將歸整好的主數據信息并入主數據庫。

3、數據質量管控子系統

從數據產生過程來看，醫療數據質量問題主要來源于3個方面。

• 原始信息采集有誤差。在醫療系統內數據采集主要通過手工方式錄入，在醫生或護士輸入信息的過程中，可能會有意或無意地將數據錯誤引入系統。
• 數據融合過程發生問題。在對不同來源的數據進行融合時，數據格式和語義可能會有誤差或不一致，導致融合結果有錯 。
• 與數據的應用場景不匹配。例如，如果要進行病例統計，現有臨床電子病歷數據就能滿足統計場景的需求。但如果要做大腸癌療效分析，現有臨床電子病歷數據就難以滿足分析場景的要求，還需補充病理數據。

在醫療數據治理過程中，需要了解最終的使用場景，也需要從業務系統的數據源頭控制質量，并保證每個融合和加工過程的正確性。另外出現數據錯誤時，進行數據修正。

因此質量管控平臺包括了數據質量監控、數據質量評估以及數據修正。數據質量監控主要針對從業務系統抽取的或是從外部傳送的接口數據，從及時性、有效性和完整性等幾個指標監測接口內容本身的數據質量問題，對采集程序進行監控；數據質量評估是指對融合后的數據進行質量評估。