3. 平台总体架构设计

医院患者服务一体化平台的总体架构设计，核心不是把业务架构、应用架构、数据架构、技术架构四张图分别画出来，而是让四者形成一条可追溯的协同链：业务能力决定应用边界，应用边界决定数据归属与流向，数据流向再决定技术选型与部署形态。本节以“门诊—住院—随访”一体化服务为主线，说明四层架构如何对齐，并给出关键集成关系。

一、四类架构的协同设计方法

协同设计的基本顺序是“自上而下分解、自下而上验证”。自上而下时，从患者服务旅程出发，先识别业务能力域，再落到应用模块，再确定主数据与业务数据，最后选择技术组件。自下而上时，用技术约束反向校验应用与业务是否可落地，例如统一身份认证是否覆盖全部入口、消息中间件能否支撑预约高峰、数据同步延迟是否满足临床要求。

业务架构回答“为谁提供什么服务”，典型能力域包括：预约挂号、智能导诊、门诊缴费、报告查询、住院服务、随访管理、满意度反馈。应用架构回答“由哪些系统承载”，需要明确每个能力域对应的应用模块及其对外接口。数据架构回答“数据从哪里来、存到哪里、谁可以看”，重点是患者主索引（EMPI）、就诊主索引、统一字典和主数据管理。技术架构回答“用什么技术实现”，包括微服务框架、API 网关、消息队列、缓存、容器化部署与监控体系。

四者对齐的检验标准是：任意一个业务能力，都能找到对应的应用模块、数据实体和技术组件；任意一个数据实体，都能追溯到产生它的业务动作和消费它的应用。若出现“有业务无应用”“有应用无数据”“有数据无技术承载”的断点，说明架构尚未闭环。

二、一体化平台分层架构

推荐采用“五层两翼”结构。五层自下而上为：基础设施层、数据资源层、应用支撑层、业务应用层、服务渠道层；两翼为安全与运维保障体系、标准与规范体系。基础设施层提供计算、存储、网络与容器编排；数据资源层承载主数据、业务库、临床数据中心（CDR）与数据仓库；应用支撑层提供统一认证、消息、工作流、规则引擎、日志与监控；业务应用层按能力域部署预约、缴费、住院、随访等微服务；服务渠道层统一接入微信公众号、小程序、自助机、窗口与院内工作站。

分层的意义在于隔离变化：渠道层改版不影响业务逻辑，业务逻辑调整不直接触碰数据模型，数据模型演进通过支撑层接口对外暴露。这样，当医院新增互联网医院入口或对接区域健康平台时，只需在渠道层或集成层扩展，而不必重构核心服务。

三、关键集成关系与数据流向

一体化平台的集成关系可归纳为四条主链路。第一条是渠道到网关的接入链路：所有外部请求先经 API 网关完成身份校验、限流与路由，再转发到对应微服务。第二条是业务服务之间的异步链路：预约成功后通过消息队列通知排班服务锁定号源、通知消息服务推送提醒，避免同步调用造成阻塞。第三条是业务到数据的归集链路：挂号、缴费、报告等动作产生的数据，经统一接口写入 EMPI 与 CDR，保证患者维度数据完整。第四条是支撑层到数据层的同步链路：缓存服务加速热点查询，任务调度负责定时同步主数据与指标计算。

以一次门诊预约为例：患者在微信公众号选择科室与医生，请求经网关鉴权后进入预约挂号服务；服务先查询排班资源服务的可用号源，再调用统一支付服务完成预缴，成功后向消息队列发送“预约成功”事件；消息通知服务消费该事件推送短信或模板消息，同时数据归集任务将本次预约写入就诊主索引。整个过程体现了渠道、应用、支撑、数据四层的协同。

四、架构协同的落地要点

第一，接口先行。在应用架构确定后，先定义各服务对外接口的输入输出与错误码，再进入开发，避免后期因接口不一致返工。第二，主数据唯一。患者、科室、医生、收费项目等主数据必须由主数据管理模块统一维护，各业务服务只引用不复制。第三，技术选型服务业务。例如预约高峰的并发量决定是否需要缓存与队列，随访的定时提醒决定是否需要任务调度，不应为追求新技术而引入不必要的复杂度。

综上，平台总体架构设计的关键在于四类架构的相互约束与验证：业务架构划定范围，应用架构落实承载，数据架构保证一致，技术架构提供支撑。只有四者形成闭环，一体化平台才能在渠道扩展、业务调整和数据共享时保持稳定与可演进。