3. 平台总体架构设计

慢病患者管理平台不是单一系统，而是横跨院内诊疗、院外随访、体征监测和区域协同的业务中枢。它既要承载高血压、糖尿病等专病的长期随访计划，又要对接医院信息系统（HIS）、检验信息系统（LIS）、电子病历（EMR）以及区域卫生信息平台。因此总体架构设计的第一原则是：按业务能力切分边界，按数据流向组织协作，按可用性等级部署资源。本节围绕微服务与模块化、前后端分离、数据流、高可用与可扩展、外部集成五个方面展开。

一、微服务与模块化：按业务能力切分，而非按技术分层

平台的核心业务能力可以归纳为六类：患者主索引与档案、专病随访计划、体征与指标采集、预警与干预、用药与依从性管理、统计分析与质控。每一类对应一个可独立部署的微服务，服务内部再按模块化分层（接口层、应用层、领域层、基础设施层）。切分依据是业务变化频率和数据所有权：随访计划规则经常调整，独立成服务；患者主索引变更少但被广泛引用，独立成服务并对外提供唯一标识。

服务之间不共享数据库。患者服务持有 patient_master 库，随访服务持有 followup_plan 库，体征服务持有 vital_record 库。跨服务查询通过接口聚合或事件订阅完成，避免因一个库的表结构变更引发全平台连锁故障。服务注册与发现采用 Nacos 或 Consul，配置集中管理，网关统一做鉴权、限流和路由。

二、前后端分离：接口契约先行

前端分为三类终端：医护工作站（Web）、患者端（小程序/App）、管理驾驶舱（大屏）。三者共用同一套后端 API，通过角色与权限裁剪返回字段。前后端分离的关键不是“分开写”，而是接口契约先行：先定义 OpenAPI 文档，明确路径、请求参数、响应结构和错误码，前后端并行开发。

例如随访计划查询接口：GET /api/v1/followup/plans?patientId={id}&status=active，返回 { planId, diseaseType, nextVisitDate, items[] }。前端不直接拼接业务规则，规则全部在后端服务中实现。这样当随访周期从“每3个月”调整为“每2个月”时，只需修改后端配置，三端同时生效。

三、数据流设计：采集、汇聚、计算、回流

平台的数据流可以概括为四条链路：体征采集链路（设备/患者上报→消息队列→体征服务→时序库）、诊疗数据链路（HIS/LIS/EMR→集成引擎→主索引匹配→临床数据中心）、预警计算链路（体征+随访记录→规则引擎→预警事件→干预任务）、分析回流链路（数据仓库→指标计算→驾驶舱/质控报表）。

实时性要求高的走消息队列（Kafka/RabbitMQ），批量历史数据走定时抽取。所有写入操作保留操作人、时间戳和来源系统标识，便于追溯。下面用一张数据流图展示各服务与外部系统之间的主要流向。

四、高可用与可扩展性

高可用不是“所有服务都双活”，而是按业务影响程度分级。患者主索引、体征采集、预警干预属于一级服务，要求 99.95% 可用，采用多副本部署、跨可用区容灾、数据库主从切换；统计报表、驾驶舱属于二级服务，允许分钟级恢复，可单副本运行。网关层做熔断和降级：当预警服务响应超时，网关返回缓存中的最近一次预警结果，而不是直接报错。

可扩展性体现在两个维度：水平扩展和业务扩展。水平扩展方面，体征采集服务无状态，可通过增加 Pod 副本应对设备上报高峰；随访计划服务有状态，采用分片键（患者ID哈希）将不同患者路由到不同实例。业务扩展方面，新增专病（如慢阻肺）时，只需在随访服务中增加一套规则配置和表单模板，不修改其他服务代码。数据库层面，时序数据按月分区，历史数据自动归档到对象存储，控制单表规模。

五、与医院信息系统和区域卫生平台的集成策略

集成策略的核心是松耦合、可追溯、可降级。与 HIS/LIS/EMR 的集成优先采用 HL7 v2 或 FHIR 标准接口，通过集成引擎做协议转换和字段映射。患者身份匹配采用“身份证号+姓名+出生日期”三要素，匹配失败时进入人工核对队列，不自动合并。与区域卫生平台的集成采用前置机模式：平台侧部署前置服务，定时拉取居民档案和转诊信息，推送随访记录和体征数据，网络中断时本地缓存，恢复后补传。

下面给出一份集成接口的关键配置示例，用于说明实际落地时的参数约定：

# 集成引擎接口配置示例（示例参数，非实测）
interface:
  name: his-patient-sync
  protocol: HL7v2
  source: HIS
  target: patient-master-service
  schedule: "0 */30 * * * ?"   # 每30分钟增量同步
  matchRule: [idCard, name, birthDate]
  onMatchFail: manual-review-queue
  retry: 3
  timeoutMs: 5000
  degrade: use-local-cache

判断集成是否正常，可以观察三个指标：接口成功率（目标≥99.5%）、平均响应时间（目标≤800ms）、主索引匹配率（目标≥98%）。若匹配率持续低于95%，应检查医院侧患者信息完整性和字段映射规则，而不是简单增加重试次数。

六、架构落地时的取舍

微服务带来灵活性的同时也增加了运维复杂度。对于患者规模在5万以下的区域平台，不必一开始就拆分六个服务，可以先按“患者+随访”和“体征+预警”两个服务起步，待业务量增长后再细分。前后端分离要求团队具备接口设计和联调能力，若前端资源有限，可先做医护工作站，患者端复用同一套 API 但简化页面。高可用投入应与业务连续性要求匹配，避免为二级服务过度建设容灾资源。架构设计的最终标准不是“先进”，而是在当前业务规模、团队能力和合规要求下，能够稳定运行并支持后续演进。