区域医疗平台设计(上)

在已有的信息化基础建设上、在医疗服务需求不断升级的背景中、在大数据、数据湖和人工智能等创新技术不断融合下，医疗信息化的范围与定义也不断扩大，从院内单机信息化不断延伸为区域间、不同机构间数据的互联互通与共享应用；从患者的病历信息，拓展到居民的全生命周期健康数据以及与健康息息相关的环境等信息，成为更加全面、更加数智化的智慧医疗平台。

前面用了20多个章节描述了区域医疗相关的平台业务内容，在熟知业务的基础上如何设计平台成为了本章后续的重点。区域医疗平台本是一个宏大的软项目工程，其建设过程不可能一蹴而就，所以先阐述平台的架构，然后是平台的设计，最后是平台的实现，层层递进。

每个人的经历不一样，看待问题的角度就会不一样，设计理念就会有些差异，求同存异是本文的宗旨，也许大家对基础的理解是趋同的，只是外在的表征有所差异，文本同而末异，殊路同归而已。我们找出医疗平台中可以通用的基础部分，上层的应用建筑再根据现场需求进行增减取舍，勾勒平台体系的轮廓，最终实现完整的平台大厦。经不住似水流年，逃不过此间少年，每一位程序员的内心都有一个世界，宁静而孤独。清欢不渡，白茶不予，芳华待灼，韶华向远；凡是过往、皆为序章，念念不忘，方得始终。

1.1. 建设思路

从近些年国家医疗规范发布的趋势来看，医疗软件体系会大概率会从2个方面发展，一个方面是业务的深而精，诸如垂直业务系统，医院管理系统；另一方面是数据的大而全，从早期的全民健康信息平台到后来的紧密型县域医共体平台，将来的有更智能的医疗平台系统来取代之前的系统。平台系统的功能会越来越全面，数据会越来越丰富，业务会越来越复杂。

站在平台系统的角度来说，抛开繁杂的业务层面，从技术角度来说平台系统可以抽象为彼此有关联的业务族系统，技术基座可以统一，数据流转可以互通，业务调用可以互联，概括提炼总结之后就能有5个层级组成：

1、 基础平台：

提供通用统一的技术基座，提供包括微服务体系，单点登录，用户管理，权限管理，系统监控和业务运维等功能的管理后端。并提供上层平台所需的基础业务模块。从发展的角度来看，从前是多个基于springboot业务模块的集合，现在是遵循微服务体系的业务设计，未来是基于低代码平台的使用。

2、 功能系统：

包括2个部分，通用业务模块和专项业务模块。通用业务是平台级应用，为上层应用提供底层业务支撑，包括EMPI，健康档案浏览器，电子病例浏览器等；专项的模块根据实际业务来增减部署，不同的业务系统可通过页面集成+服务集成+数据集成的手段，实现业务在平台内的互联互通。

3、 业务协同：

包括人-机交互的业务流程和机-机交互的逻辑流程。严格的说这2个部分其实就是早期workflow和后来bpm的概念，只是在实际应用中，很多业务系统把与人交互的业务流程，类似OA审批这样的工作定义为业务协同；把API和服务交互的定义为服务编排。

早期服务编排基于SOA/ESB来实现，现在的API范围更宽泛，不单包括WebService，消息，还包括Rest，本地SpringBean的调用，把各种业务服务进行编排，中间可以穿插人工在页面上的处理，最终形成业务流程链，业务服务能复用，业务过程能留痕，并能减少重复开发的工作量。

4、 数据仓库：

技术实现可以分为3个层次：离线数仓，实时数仓，数据湖。医疗系统涉及众多的软件服务商和医疗机构，数据处理链路较为冗长，数据口径和数据质控也是参差不齐。从实现角度来说，离线数仓能较好的兼容各种数据来源、传输途径、统计口径，涵盖事务型事实表，周期性事务表，累积型事务表。因为采用批量处理和中间计算结果的复用，能节省算力。

如果特定业务需要实时计算的数据，比如疫情防控疾病追踪等需求，这部分指标可以采用实时数仓技术，作为事务型事实表的数据补充；

医疗数据包括文本，图片，影像等，数据量庞大，分布在各种专属的业务系统，但趋势是数据大集中，数据统管统用，数据湖可以承接这部分工作，形成区域内统一的大ODS模型，并为将来的湖中升仓，或者湖仓并举提供夯实的数据基础。

5、 医疗智能：

在数据仓库中可以完成传统的指标计算和机器学习，诸如用户标签，用户画像等功能，但如果更加智能的处理，则需要在大数据+大模型的算力加持下，以实现对数据赋能的加成。

以当前大模型的效果呈现，非常适合在法律，金融，医疗，教育等场景中应用。考虑到医疗数据的安全诉求，大模型需要私有化部署，并结合RAG的医疗专业知识的检索增强，在打通电子健康档案+电子病历+体检信息+智能设备传感数据的基础上，从微观层面可以实现居民个体的健康助手等相关智能应用，从宏观方面可以更加全面了解区域内居民的健康动态和发展趋势，从而全方位实现大模型对医疗智能的增益。

1.2. 平台架构

医疗行业的业务形态多种多样，无外乎数据+业务，这里以区域医疗平台为基础，从通用的角度来说平台型数据处理和业务处理，方便建立抽象模型和拉通业务逻辑，并在此基础上提供上层业务通用的业务支撑，致力于打造一个区域内的协同化、高效化的医疗服务平台。

考虑到区域医疗平台的复杂性，在描述平台架构中参考了企业架构的思路，企业架构是指为了支撑企业的战略目标、业务流程和信息技术而设计和实施的整体框架，包括了业务、应用、数据和技术的层面描述，以便能系统性思考和完整性规划。作为实施的整体框架，包含了以下几个方面：

1. 业务架构：描述平台目标、战略、流程、职能、组织和资源等方面，通过表述业务范围、流程、职责和角色，帮助平台实现业务目标，业务架构贴近商业问题，反映平台的基础业务逻辑和数据流转，同时为应用架构、数据架构和技术架构提供基础性的信息。

2. 应用架构：描述应用系统的功能、模块、关联和接口等方面，包括应用软件的设计原则、规范和标准。应用架构的设计要求从业务架构中推导出来，以确保应用系统能够支持和满足业务需求。

3. 数据架构：描述数据的来源、存储、处理、分发和使用等方面，包括数据模型、数据规范、数据质量要求等内容。数据架构的设计需要考虑到业务需求和应用系统的功能，以确保数据能够支持各种业务活动。

4. 技术架构：描述硬件、软件、分层，网络和安全等方面，技术架构的设计需要考虑到应用系统和数据架构的需求，以确保基础设施能够为业务和应用提供充分的支持。

1.2.1. 业务架构

1.2.1.1. 主要涉众角色

医疗机构，卫健委，居民个体

1.2.1.2. 关键业务服务

1. 整合数据：构建区域级医疗大数据中心，实现居民个体的电子病历+电子档案的数据的有效关联；通过对数据指标的统计分析，卫健委提供可靠的监控依据；通过对数据的挖掘，标签，画像，以及智能趋势推断，对医疗机构提供居民的身体状况信息。

2. 整合服务：构建服务编排系统，把众多系统的服务在区域内共享出来，实现跨机构跨系统的服务，根据业务流程进行整合，打通人-机交互，机-机交互的业务处理链。

3. 支撑业务：平台本身会提供一些基础服务，包括EMPI，CDA，医疗数据注册等，为上层应用提供基础服务支撑。

1.2.1.3. 主要业务流程

A、数据处理流程

关键要素

1. 遵循国家数据规范：建立区域大一统的交换标准（one-data），需要借鉴《WS 364-2011 卫生信息数据元值域代码》,《WS 370-2012 卫生信息基本数据集编制规范》,《WS 445-2014 电子病历基本数据集》,《WS/T 483-2016 健康档案共享文档规范》,《WS/T 500-2016 电子病历共享文档规范》等等标准，并做适当扩充。

2. 创建数据质量的控制和反馈：系统会需要采集几十套系统的数据，大大小小的厂家，参差不齐的数据质量，各怀心思的小九九，需要建立起一套自驱动的数据处理闭环机制。

3. 数据整合：建立区域EMPI（one-id），是拉通各个业务领域的关键，且要求性能高，需要在内存中计算，可以采用redis / clickhouse的内存表。

B、数据挖掘流程

医疗体系的数据挖掘一般从临床需求开始，然后根据需求集成数据或整合专病库，过滤数据，选择合适的数据挖掘方法，最终满足需求，并将模型推广和应用的过程。医疗大数据挖掘的整体流程如图所示。

处理过程

1. 需求理解：充分理解临床医生想要通过数据挖掘技术解决的临床问题。

2. 数据集成：其目的就是将各个数据源统一为准确、有效、可用的数据源，对来自不同医疗信息系统的病人数据进行数据集成，形成医疗大数据中心。数据来源包括HIS、CIS、LIS、RIS、PACS等系统，包括结构数据，文档数据，半结构化数据。

3. 专病库抽取（二次建库）：基于医疗大数据中心构造面向特殊疾病的专病库，确定符合疾病特征的病例和需要的病例字段，并建立向量数据库和知识图谱，以方便自动化的病例数据抽取和检索。

4. 数据质量（质控）评估：对专病库进行数据质量评估，包括数据完整性、数据一致性、医疗实体及其编码的一致性、数据逻辑性等。若数据达标可进行后续的数据建模工作。

5. 数据建模：建模过程中根据达成目标选择合适的模型和算力。从简单实现考虑，采用基于Greenplum的MADlib的实现；如果要达成更高要求，选择KNN算法、朴素贝叶斯算法等算法用来提升特定领域的处理；在将来还可以采用LLM的方式，辅助医疗机构处理相关信息，比如从EHR/EMR中快速提取关键信息，支持临床决策等。

6. 评估与部署：评估中需要考虑数据的分析角度；部署是将建模过程及得到的最终结果以人类可以识别的形式呈现出来。

C、业务协同流程

区域内的业务协同有不少，包括全程健康档案调阅，重复用药提醒，重复检查检验提醒，检查检验结果共享与互认，远程会诊业务协同，双向转诊业务协同等等，前文已经有详细描述，此处不在赘述。

1.2.1.4. 重要支撑业务

A、资源注册

资源注册打通平台和第三方系统的服务进行统一管理，参数设置，权限设定，从而打通全区相关业务平台的服务。

1. 医疗卫生机构注册：具有医疗卫生机构注册功能，且按属地、组织机构代码、机构分类代码标准进行注册，包括机构介绍、科室介绍、特长介绍、图片，联系人等信息。

2. 医疗卫生机构人员注册：具有医疗卫生机构人员注册功能，包括执业信息，特长信息等，最终将实现卫生人力资源管理，逐步实现对医务人员的医疗信用体系建设。

3. 医疗服务资源注册：医疗机构把可对外服务的医疗资源进行发布，医疗机构提供资源的性质、范围；科室提供以及医生的方式。

4. 居民个人身份信息注册：具有居民个人身份注册功能，且注册信息符合标准，居民健康档案建档率、完整率达到建设要求。

5. 个人身份识别验证：能够在不同的业务系统中识别验证居民个人身份。

6. 核心码表注册：平台具有标准核心码表管理功能，且注册的核心码表要与业务系统共享。

7. 医疗卫生术语和字典注册服务：建立术语和字典注册库，用来规范医疗卫生事件中所产生的信息含义的一致性问题。

B、患者主索引服务

患者主索引（EMPI）的作用就是将不同医疗机构同一个病人不同的信息标识关联起来，实现不同机构，或不同系统之间，同一患者的识别及信息互访，是实现医疗信息共享的基础，采用医疗信息系统集成（IHE）技术框架中定义的患者标识交叉索引（PIX）和患者基本信息查询（PDQ）集成规范，是实现患者主索引服务的参考标准。

患者标识交叉索引PIX，在将患者信息注册时，将信息传递至PIX，PIX根据患者基本信息与历史患者信息进行匹配，匹配度超过一定阈值，则认为当前患者与历史患者中某人为同一人，匹配成功，返回患者唯一标识，否则为患者生成唯一标识并返回。

患者基本信息查询PDQ，是指患者基本信息使用者利用已知的患者信息如患者的唯一标识码PID（例如身份证号、医保卡号、居民健康卡号等）、姓名、出生日期、地址、联系人、电话号码、性别等作为查询条件，向患者基本信息提供者发起查询请求，患者基本信息提供者向患者基本信息使用者返回一个列表，列表中包含与查询条件相匹配的患者的基本信息，供使用者进行选择。

C、卫生活动资源

以平台为中心的卫生活动资源是基于元数据标准、信息资源分类标准、标识符编码标准和全文检索技术，充分利用目录的规划、注册、编目、发布、维护和查询功能，按照统一的标准规范，对分散在各级卫生行政管理部门和基层医疗卫生机构的平台资源进行整合和组织，形成逻辑上集中、物理上分散，可统一管理和服务的、以平台为中心的信息资源目录，为人口健康档案的调阅者提供在全省范围内跨区域、跨机构的统一的信息资源发现和定位服务，为授权调阅和共享做准备。

信息资源分类是根据信息资源自身内容的属性或特征，将其按一定的方法和原则进行区分和归类，并建立起一定的分类体系和排列顺序；其分类依据取决于分类信息的属性或特征。

平台资源目录的管理基于元数据标准、信息资源分类标准、标识符标准和全文检索技术实现。基于基础平台的实际情况，平台的资源目录包括数据元目录、基础共享信息目录、卫生活动目录、卫生管理指标目录以及服务接口目录。

通过平台资源目录管理，实现管理者对平台按照信息资源分类标准进行有效配置和统一管理，从而让使用者能够快速、方便的实现平台资源的发现与定位。

D、临床文档架构

CDA(clinical document architecture)临床文档架构是一种文档标记标准，目的是统一临床文档和数据交换格式。该标准定义了交换标准本身的文档格式和具体语义。CDA本身也可以不依赖HL7v3消息格式独立使用。当前常用的CDA版本为v2.0版本。

CDA组件是完成CDA文件的解析，转换，产出和转发四个功能的基础模块。CDA组件结合存储模型，通过服务注册接收外部平台上传的CDA文件，并解析成存储模型实体，存储到对应的物理表存储，并支持查询数据库数据或请求外部平台获取对应的存储模型数据，产生CDA文件推送到上级平台或或者响应给请求方。在处理CDA文件的过程中，将CDA文件存储在分布式文档服务器中，并实现文件的存储、读写、检索、备份。

E、健康档案服务

健康档案服务处理平台内与数据定位和管理相关的任务。该服务包括相关的索引信息，这些索引将不同存储服务所保存的数据链接到一个特定的个人、医疗卫生人员、医疗卫生机构，实现共享及协同应用的实时响应、快速调阅。健康档案服务负责分析来自外部资源的信息，根据其状态恰当地保存这些数据到存储库中，实现对健康档案的建档、归档及更档，同时可以反向地响应外部医疗卫生服务点的检索、汇聚和返回数据。

健康档案服务围绕任何数据主题汇集出真正的全程和综合的健康档案视图。同时全程健康档案服务可提供自动或手动的健康档案维护功能，包括由于居民身份唯一性识别的人工处理所带来的健康档案合并与拆分的操作。健康档案服务包括：

1. 索引服务：快速定位患者信息，及与之相关健康事件、摘要，目录

2. 摘要服务：生成患者信息基本摘要

3. 查询服务：提供数据组装和查询

1.2.2. 应用架构

描述用于支持业务架构，并对数据架构所定义的数据进行处理的应用功能。这些应用功能是用来管理在数据架构中定义的数据，并对业务架构中定义的各项业务进行支撑的能力。

1.2.2.1. 系统层

来自各个医疗系统的数据，可以是医疗机构的传统系统，包括HIS，EMR，LIS，PACS等，也可能是来自穿戴设备的数据；数据种类也是多样化，包括关系型数据和非关系型数据。

1.2.2.2. 总线层

包括数据总线和服务总线，拉通各种医疗数据，最终汇聚到平台交换中心。交换中心的设计需要遵循国家规范，再根据本地化医疗信息程度进行取舍。数据采集手段也是多样化，包括服务方式（CDA），数据集方式（ETL/前置库），日志方式（第三方外部数据源）。

1.2.2.3. 数据层

这里是系统的数据中心，如果需要可以构建数据仓库。在未来需要构建的统一数据资源池的时候，可以采用数据湖模式。考虑使用湖仓并举或者湖上建仓的模式来进行湖仓一体的建设，从而实现数据的存储、管理和分析等全生命周期的管理。

在解决了数据存储的问题，还有数据计算和数据管理的需求。医疗体系中，离线数仓技术能兼容更多的数据来源，以及多种事实表的类型；在某些要求时效性高的事务型事实表的计算，可以采用实时数仓作为离线数仓的补充。要更好的使用数据，数据管理是必不可少的，数据管理包括数据治理，数据交换，数据共享等内容。

自此数据中心汇聚了区域内的海量医疗数据，经过处理后可以形成高价值的数据资产，数据可以4种使用的层级：1、通过EMPI关联有序的居民个体数据集合；2、经过统计分析后的区域监管指标数据；3、经过标签、画像后的居民个体特征数据；4、经过LLM分析后的居民个体推理数据和区域医疗趋势化分析等。

1.2.2.4. 支撑层

平台支撑层是平台的业务基础模块的集合，起到承上启下的衔接作用，为上层具体应用提供通用的服务支撑，包括基础服务，服务协同，数据共享等内容。

1. 基础服务包括：CDA，MPI，数据注册等

2. 服务协同的底层逻辑是BPM的实现，通过对WebService，Rest，SpringBean的API编排，形成有业务逻辑的处理链路，打通跨系统的调用，最终实现业务的协同。

3. 数据中心存储了高价值医疗数据，通过接口，或者JDBC以及前置库的方式提供数据共享，这里需要设定高强度安全措施，避免数据非法使用。

1.2.2.5. 业务层

这里就是项目体现差异的地方，根据不同的诉求来设定相应的模块。如有需要，可以开放特定API以及部分数据接口，或者CDC，从而纳入平台整体的数据流转和服务流转。

这里业务模块众多，有中后台管理类型的系统，也有业务处理的系统，规模也不尽相同，可以根据实际需要来使用具体的技术路线。可基于微服务脚手架或者低代码平台，得以快速开发和部署业务系统。

1.2.3. 数据架构

以企业愿景、使命，业务需求，业界实践，现有模型及标准和其他架构设计成果为输入，通过数据资产目录，数据标准，数据模型，数据分布等方式进行数据资产设计。

1.2.3.1. 数据标准

标准规范体系是平台建设的基础，在应用架构图中所示，规范是纵向贯穿始终的存在，通过建立并制定医疗卫生数据标准体系，并充分利用各级单位的医疗卫生资源，形成统一的资源交换规则和标准。一般来说平台建设标准化规范体系包括：数据规范、业务功能规范、应用规范、管理规范、安全规范、技术规范等部分。

1. 数据标准规范：公共数据元标准、公共代码标准、公共数据存取规范、数据交换规范、业务数据采集标准，健康档案标准，统计数据标准，共享数据标准等。

2. 技术标准规范：通过技术标准规范支持各机构信息系统和信息平台之间的数据级和应用级整合，并提高业务系统之间的应用集成、互联互通的能力。

3. 管理标准规范：标准管理、安全管理、数据管理、项目管理，用于指导信息平台日常运行管理、数据维护管理。

4. 业务标准规范：业务标准由业务部门制定，针对不同机构的不同业务，制定统一的应用服务接口标准体系，该标准体系是区域卫生数据交换和共享的前提保证。

医疗数据标准是保证各个业务系统的数据一致地、准确地交换和共享的一系列规范性约束。在平台建设中，需要参考如下规范：

1、 区域卫生信息平台标准规范

基于健康档案的区域卫生信息平台，是县域医共体信息化的核心和枢纽。区域卫生信息平台的建设必须遵循国家颁布的相关标准规范，主要包括：《WS/T 448-2014 基于健康档案的区域卫生信息平台技术规范》、《WS 365-2011 城乡居民健康档案基本数据集》，与电子健康卡的融合，遵循《电子健康卡建设与管理指南》等标准规范。

2、 各级医疗机构业务应用标准规范

在医院信息平台的设计过程中，遵循《WS/T 447-2014 基于电子病历的医院信息平台技术规范》；对于医院信息平台的标准化建设，遵循《WST 501-2016 电子病历与医院信息平台标准符合性测试规范》；在基层医疗卫生机构管理信息系统设计过程中，遵循《全国基层医疗卫生信息化建设标准与规范》；在电子病历的设计过程中，遵循《WS 445-2014 电子病历基本数据集》等标准规范。

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

业务协同及基层综合管理应用标准规范主要包括共享文档编制规范和健康档案共享文档规范的内容《WS/T 482-2016 卫生信息共享文档编制规范》和《WS/T 483-2016 健康档案共享文档规范》等标准规范。

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

其它部门系统接入标准规范主要指县域医共体信息化中接入民政系统、社保系统、公安系统、食药监系统等其他政府部门信息系统时，应该遵循的医疗卫生信息相关标准规范，主要包括：《WS 365-2011 城乡居民健康档案基本数据集》、《WS/T 482-2016 卫生信息共享文档编制规范》、《WS/T 483-2016 健康档案共享文档规范》等标准规范。

1.2.3.2. 数据分布

支撑数据架构会采用多种数据存储技术，包括关系型数据库，文件存档库，内存数据库，以及非关系型数据库。不同的技术面向不同的使用应用场景。如果是云上部署，从性能考量需要使用SSD硬盘。

区域平台最抽象的数据分布，涵盖平台数据，业务数据，资源数据等内容，并标注了关键的业务数据，如摘要库和索引库，根据业务不同，分为3个数据域：

1、 业务域：

包括通用业务和专项业务的表结构，根据不同业务进行增减设计，通用的包括MPI，CDA，服务编排等；专项业务根据现场需求而增减。采用关系型数据库来存储。之前基于Oracle，现在需要采用信创和开源的数据库，采用开源数据库的好处是方便做分库分表。

2、 平台域：

平台运行所需的表，还可以细分为系统管理，基础数据，配置信息，业务协同等内容，用以支撑平台运行的基础数据。根据业务场景不同可使用关系型数据库和内存数据库。对于需要高速IO的系统，采用Redis/ClickHouse内存表的方式。

3、 数仓域：

包括数据管理的相关表和数仓ODS，DWD表，数仓建设需要遵循国家规范，并需要适当扩充来承载各个业务系统的数据。ODS表结构要尽可能能覆盖业务含义，保留最多的原始业务字段，DWD表要满足各个业务使用需求，包括统计，分析，挖掘，推理的要求

数仓作为平台的数据资源池，存储的信息多，包括结构化数据和半结构、非结构的数据。数仓根据需求可以采用MPP数据库+OLAP库+关系型数据库+文件存储库。这么多类型的数据要汇聚，将来可以采用数据湖方案来统一部署，实现区域统一的交换中心。

1.2.3.3. 数据模型

建设区域医疗数据中心，打破系统内部信息壁垒, 将区域内的患者信息、诊疗、医生、号源、设备、财务等数据全量汇集到数据中心，实行统一标准、统一运维，全面强化对疾病预防、医药保健、药械采购、药品购销等卫健各领域的监管治理。

A、建设参考：

1. 业务应用和数仓系统分开建设。

2. 区域业务涉及到多个多家软件提供商，按照国家和省级标准，依据本地业务特点，出具统一的数据交换标准。数仓系统负责存储、管理和处理历史数据和增量数据。

3. 数仓建设面向主题的、分层的数据仓库建设，划分业务主题，采用事实表+维度表建模理论，数据主题的统一建设，方便数据的应用和数据的调用。

4. 对数仓系统实施数据治理，基于统一的数据标准建设，采取EMPI实现患者数据的业务关联性，最终通过数据目录和数据服务实现数据的共享。

B、模型参考：

主要包括但不限于临床数据库、基础数据库、运营数据库和医疗资源库，电子病例，健康档案，全员人口等数据库。

1. 临床数据库：以患者为中心，集成门急诊/住院、院前/院中/院后各环节医疗数据等

2. 基础数据库：汇聚各单位机构、科室、人员和术语字典等各类基础数据。

3. 运营数据库：围绕有效运营目标，集成各个系统的医疗健康运营数据。

4. 医疗资源库：包括医生号源，床位资源，药品信息等

5. 电子病例库：包括病历概要，门急症处方，门急症病历等

6. 健康档案库：个人信息摘要，公共卫生服务等

7. 全员人口库：人口基本信息等；

1.2.4. 技术架构

技术架构需要把应用和数据架构中定义的组件影射为相应的技术组件。这里包括业务基础框架和数据实施开发。

1.2.4.1. 微服务体系

微服务架构是一种软件架构风格，通过将大型应用程序拆分为一组小型、独立的服务来构建系统。每个服务都围绕特定的业务功能进行设计、开发、部署和扩展。这些服务通过轻量级的通信机制进行交互，形成一个松耦合的分布式系统。

A、核心特点

1. 服务拆分：应用程序被拆分为多个小型服务，每个服务负责一个明确的业务功能。

2. 独立部署：每个服务都可以独立进行部署和升级，不会影响其他服务的正常运行。

3. 分布式通信：服务之间通过轻量级的通信机制进行交互，如RESTful API、消息队列等。

4. 自治性：每个服务都是自治的，可以使用不同的技术栈和数据库，独立进行开发和维护。

5. 垂直扩展：可以根据需要独立地扩展特定的服务，而不必扩展整个应用程序。

B、核心组件

1. 服务开发：服务开发框架包括Spring Boot、Node.js等。，提供快速构建服务的能力。

2. 服务注册与发现：通过注册中心提供服务发现和注册，以及负载均衡的功能。

3. 负载均衡与网关：用于在多个服务实例之间分配请求负载和提供访问入口的工具，实现请求的负载均衡和反向代理，提高系统的性能和可靠性。

4. 分布式消息传递：提供服务之间的可靠的消息传递和发布-订阅模式的支持。

C、持久层

mybatis有几个嬲塞的替代品，mybatis-plus是首选之一，不过现在可以选择mybatis-flex，提供了一些额外的高级特性，更方便的SQL逻辑的编写，以及更好的性能。

D、外部存储

作为复杂业务系统，需要不同的外部存储系统的搭配使用来获取最优的效果。典型的需要用Redis来加速业务的计算；使用MQ来获取外部的数据；使用Minio进行文件/XML/CDA的存储，使用ClickHouse来存储巨大的日志表以及部分DWS的大宽表

E、系统监控

采用Prometheus+Grafana作为系统监控。Prometheus记录和查询系统和应用程序的指标数据，监控主机和后台服务。Grafana是可视化监控工具，将Prometheus的metrics数据展示为图表、仪表盘等形式。

F、Track监控

可采用SigNoz接入链路追踪系统的微服务，监控并排查已部署应用的问题，展示每个服务延迟、错误率、每秒请求数等。相关竞品也有Skywalking、Zipkin等。关于Metrics方面的跟踪，还是建议Prometheus+Grafana，在指标展示/告警降噪/值班OnCall要成熟得多。

1.2.4.2. 数仓开发

1、数仓建设思路

A、分层规划

数据仓库分层是一种组织数据仓库结构的方法，将数据仓库划分为多个层次，每个层次负责不同的数据处理任务和数据访问需求。结合数仓体系和区域平台的特点，分层如下：

1. ODS层，交换中心，按照国家标准建立区域统一交换标准。目前以结构化信息为主。CDA信息需要解析后入库，并在Minio存档并关联。在未来构建数据湖时，就可以存储自然/原始格式的医疗数据。

2. DWD层，资源中心，清洗转换质控以后的数据，并在此基于EMPI做数据的聚合，用主索引和交叉索引关联各业务信息，实现不同机构/不同系统之间，同一患者的识别及信息互访。在此基础上根据业务要求可进行：1、基于统计分析的监管指标计算；2、基于标签体系的患者画像；3、基于机器学习的个体和群体的分析和预测；4、基于大模型+RAG的个体健康管理和区域状况的推理。

3. DWS层，汇聚层，根据业务规则创建对应的大宽表，或者按照年月日累计的中间过程数据，方便最终结果的展示和调用。

4. ADS层，结果层，为图表报表提供呈现数据的载体。

B、数仓建模

在数仓体系中采用通过事实和维度来建模。事实通常对应业务过程（不可拆分的行为事件），而维度通常对应业务过程发生时所处的说明值。事实表包括3种类型：

1. 事务事实表：用来记录各业务过程，保存的是各业务过程的原子操作事件，可用于分析与各业务过程相关的各项统计指标，保存了最细粒度的记录，可以提供最大的灵活性。

2. 周期快照事实表：以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型或者状态型指标。

3. 累计快照事实表：是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表。

C、事实表的设计：选择业务过程à声明粒度à确认维度à确认事实。

1. 业务过程：挑选所需的业务过程，业务过程是不可拆分的行为事件。

2. 声明粒度：精确定义每行数据表示的是什么，尽量选择最小粒度。

3. 确认维度：选择与各业务过程相关的维度。

4. 确认事实：选择各业务过程的度量值。

D、维度表的设计

1. 在设计维度表时，如果对其进行规范化，得到的维度模型称为雪花模型，如果对其进行反规范化，得到的模型称为星型模型。

2. 反规范化是指将多张表的数据冗余到一张表，其目的是减少join操作，提高查询性能。

3. 维度退化：如果维度表的维度属性很少，可以不创建该维度表，而把该表的维度属性直接增加到与之相关的事实表中。

E、计算指标的形态

1. 原子指标：基于某一业务过程的度量值，在业务定义中不可再拆解。

2. 派生指标：基于原子指标，派生指标通常会对应实际的统计需求

3. 衍生指标：基于一个或多个派生指标之上，通过逻辑运算而成，例如比率/比值等。

2、数仓开发过程

围绕数仓从数据开发、数据治理、数据共享与应用三个方面进行功能设计。

A、数据开发：

对数据仓库进行整体的分层规划设计，从数据的采集到数仓的分层处理，再到数据最终的可视化，实现数据可见可得。包括如下4个方面

1. 数据建模：基于数仓建设体系，基于事务表+维度表建设

2. 数据集成：基于ETL/JDBC/CDC/日志等模式，把各业务系统数据统一汇聚；。

3. 数据清洗：根据清洗规则对于不满足规则的数据进行预设规则的处理

4. 数据质控：基于规则引擎对数据的质量进行检查，对数据质量追踪提供闭环管理。

B、数据治理：

数据入仓后提供数据治理，包括数据标准，主数据，数据地图，元数据管理等处理。

C、数据共享：

由网关对所有的数据服务进行调度、管控、编排、适配，应适应平台内部的数据共享和平台外部的数据开放等需求。