3. 平台建设总体架构设计

医院资产管理平台不是一套“买来即用”的软件，而是一个需要与医院现有信息系统、财务制度、临床流程深度咬合的基础设施。总体架构设计的价值，在于把“要管什么、谁来管、数据从哪来、系统怎么搭、放在哪里跑”这五个问题一次性说清楚，避免后期反复返工。本节按业务架构、应用架构、数据架构、技术架构、部署模式选型五个视角逐层展开，并给出可落地的判断依据。

一、业务架构：先划清资产全生命周期的责任边界

业务架构回答的是“平台支撑哪些业务、这些业务由谁负责、在什么节点交接”。医院资产管理的核心对象是固定资产与医疗设备，其生命周期可归纳为：预算与论证 → 采购与验收 → 建卡与入库 → 领用与调拨 → 使用与维保 → 计量与质控 → 盘点与处置。每个环节都涉及不同科室：使用科室提出需求，设备科负责技术论证与验收，财务科负责建卡与折旧，采购中心负责招标，院感与质控部门参与计量检定。

设计业务架构时，建议用“业务域—业务活动—责任角色”三级结构梳理。例如“维保域”下含“报修受理、工单派发、维修执行、验收确认、费用结算”五项活动，分别对应临床科室、设备科调度员、工程师、科室负责人、财务。责任边界一旦明确，后续应用模块的权限设计和数据流向就有了依据。需要特别注意的是，资产“账、卡、物”一致是业务架构的底线要求：财务账、设备卡片、实物三者必须在同一数据源上对齐，否则盘点永远对不上。

二、应用架构：以“一个门户、多个能力中心”组织功能

应用架构把业务活动翻译成可建设的系统能力。推荐采用“门户层 + 业务应用层 + 能力中心层 + 集成层”的分层结构，而不是把所有功能堆在一个大系统里。门户层面向不同角色提供统一入口：临床人员看到的是“我的设备、我要报修、我要领用”，设备科看到的是“待验收、待派工、待盘点”，院领导看到的是“资产总值、利用率、维保成本”驾驶舱。

能力中心层是应用架构的关键，建议至少沉淀四个中心：资产主数据中心（统一资产编码、分类、状态）、工单中心（报修、维保、计量、巡检统一工单模型）、流程中心（审批流、消息通知、待办）、报表中心（折旧、效益分析、KPI）。集成层负责与 HIS、HRP、财务系统、招标系统、物联网平台对接。这样划分的好处是：新增“设备效益分析”时只需扩展报表中心，不必改动主数据逻辑。

三、数据架构：主数据是“账卡物一致”的根

数据架构的核心不是建多少张表，而是定义清楚“一个资产从生到死，数据在哪些系统间流转、以谁为准”。建议把数据分为三层：主数据（资产编码、分类目录、科室字典、供应商、状态机）、业务数据（采购单、验收单、工单、盘点记录、折旧明细）、指标数据（资产总值、利用率、维保成本率、报废率）。

资产编码建议采用“分类码 + 年份 + 流水号”的可读结构，例如 SB-2024-000137 表示 2024 年第 137 台设备。状态机必须显式定义，推荐状态集合为：待验收 → 在用 → 维修中 → 停用 → 待报废 → 已处置，并规定每个状态允许的操作与触发角色。数据质量上至少设置三条校验规则：资产编码全院唯一、在用资产必须有责任科室、处置资产必须有关联审批单。这三条规则能拦住绝大多数“账实不符”的源头问题。

四、技术架构：微服务不是目的，可维护才是

技术架构要服务于医院的运维现实。多数医院信息科人力有限，因此不建议一上来就追求全微服务化。更务实的做法是：核心业务（资产、工单）按微服务拆分，报表与集成采用独立服务，前端统一门户。技术栈上，后端可采用 Spring Boot + Spring Cloud，数据库优先选用国产数据库（如达梦、人大金仓）以满足信创要求，缓存用 Redis，消息用 RabbitMQ 或 RocketMQ，容器编排用 Kubernetes 或轻量级 Docker Compose。

必须提前设计的能力包括：统一认证（对接医院 AD 或 CAS 单点登录）、接口鉴权（API 网关 + Token）、操作日志留痕（谁在何时改了哪条资产数据）、数据加密（患者相关信息与设备序列号脱敏）。这些不是“以后再加”的功能，而是等保测评和审计的硬性要求。

五、部署模式选型：按数据敏感度分层落地

部署模式没有唯一答案，关键看数据敏感度、等保级别、运维能力和预算。常见三种模式对比如下：

选型判断可参考一个简单规则：涉及资产原值、折旧、供应商合同的数据，优先院内；涉及统计报表、移动端查询、灾备的数据，可考虑混合云。若医院已通过等保三级且信息科具备容器运维能力，推荐“院内私有云 + 异地灾备”的组合，RTO 控制在 4 小时内、RPO 控制在 15 分钟内，这是多数三级医院可接受的基线。

综上，五视图不是五张独立的图，而是同一平台从业务、功能、数据、技术、部署五个切面的投影。业务架构定边界，应用架构定能力，数据架构定根基，技术架构定实现，部署模式定落地方式。设计时先对齐业务与数据，再决定应用拆分与技术选型，最后根据数据敏感度选择部署模式，才能让平台既满足当前管理需求，又为后续扩展留出空间。