4. 智慧医院业务平台总体架构设计

智慧医院业务平台的总体架构，不是把HIS、EMR、LIS、PACS等系统简单堆叠，而是通过分层解耦与中台能力沉淀，形成“前台敏捷、中台共享、后台稳定”的整体结构。理解总体分层架构以及业务中台、数据中台、技术中台、统一门户与集成平台之间的关系与边界，是后续架构落地、系统选型与集成设计的基础。

一、总体分层架构：五层两域

从工程视角看，智慧医院业务平台可划分为五个层次，并贯穿安全与运维两个支撑域：

• 接入层：面向患者、医护、管理者提供统一入口，包括统一门户、移动端、自助终端、大屏等，负责身份认证、单点登录与界面聚合。
• 业务中台层：沉淀可复用的业务能力，如患者主索引服务、预约挂号能力、医嘱能力、收费能力、消息通知能力等，供多个前台应用调用。
• 数据中台层：负责数据采集、治理、存储与服务化，形成主数据、临床数据中心（CDR）、运营数据中心（ODR）及指标服务。
• 技术中台层：提供微服务框架、API网关、消息队列、缓存、容器编排、日志监控等通用技术能力。
• 基础设施层：包括服务器、存储、网络、云资源及安全设备，为上层提供计算与网络支撑。

两个支撑域分别是安全域（等保、数据加密、访问控制、审计）和运维域（监控、告警、发布、容量管理），它们不单独成层，而是横向贯穿所有层次。

二、中台三兄弟：业务中台、数据中台、技术中台

三个中台常被混淆，边界可以用“能力类型”来区分：

举例说明边界：当医生在门诊工作站点击“开立医嘱”时，业务中台负责校验患者身份、生成医嘱记录、触发收费与药房消息；数据中台负责把这条医嘱同步到CDR，供后续质控与科研使用；技术中台则提供网关路由、消息投递和日志采集。三者各司其职，不越界。

三、统一门户与集成平台的关系

统一门户解决“人找应用”的问题，集成平台解决“系统找系统”的问题，二者定位不同但必须协同。

统一门户面向用户，提供单点登录、待办聚合、消息提醒、个性化工作台。它不承载业务逻辑，只做界面集成与身份透传。例如护士登录门户后，可直接看到待处理医嘱、待审核检验、待回访患者，点击即跳转到对应业务系统。

集成平台面向系统，提供消息路由、协议转换、服务编排、接口监控。它不直接面向最终用户，而是让HIS、EMR、LIS、PACS、医保等系统通过统一通道交换数据。例如LIS完成检验后，通过集成平台将结果以HL7消息推送给EMR和CDR，而不是各系统两两直连。

四、关系与数据流：一次门诊挂号的完整链路

以患者通过微信公众号挂号为例，说明各层协作：

1. 患者从统一门户（微信端）发起挂号请求，门户完成身份认证并透传患者ID。
2. 请求经技术中台的API网关路由到业务中台的预约挂号服务。
3. 预约服务调用患者主索引校验身份，调用排班服务锁定号源，生成挂号记录。
4. 业务中台通过集成平台向HIS发送挂号确认消息，向支付系统发起缴费。
5. 挂号成功后，数据中台采集该事件，更新门诊量指标与患者就诊档案。
6. 门户将挂号结果与就诊提醒推送给患者。

这条链路中，门户负责交互，网关负责路由，业务中台负责业务规则，集成平台负责跨系统消息，数据中台负责沉淀数据，技术中台负责底层支撑。任何一层缺失或越界，都会导致耦合加重或复用困难。

五、边界设计中的常见误区

在实际工程中，边界模糊往往带来三类问题：

• 门户越界：把业务逻辑写进门户，导致门户变成“胖前端”，后续换门户时业务无法复用。正确做法是门户只做展示与跳转，业务规则留在业务中台。
• 集成平台越界：把数据治理、指标计算放进集成平台，导致平台既做通道又做计算，性能与职责双失。集成平台应专注消息路由与协议转换，数据加工交给数据中台。
• 中台重复建设：业务中台和数据中台各自维护一套患者信息，导致主数据不一致。应明确患者主索引由业务中台统一提供，数据中台通过集成平台订阅变更。

六、落地建议

总体架构设计完成后，建议用一张“能力-层次映射表”逐项确认每个能力归属，避免建设过程中职责漂移。同时，在集成平台与数据中台之间约定清晰的数据订阅接口，在门户与业务中台之间约定统一的身份与权限模型。架构不是一次画完的图，而是需要在每个项目迭代中持续校准的边界共识。