1. 医疗SaaS平台架构设计工程导论
医疗SaaS平台架构设计工程，研究的不是“把一套医院信息系统搬到云上”这么简单的问题，而是如何在多机构、多角色、强监管、高可用的约束下，构建一套可被大量医疗机构共享、又能彼此隔离、还能持续演进的软件平台。本章先建立三个基础认知：医疗SaaS是什么、它和普通SaaS的差别在哪里、以及我们用什么方法论和路线图去设计它。
一、课程目标：从“能跑”到“可运营、可合规、可扩展”
本课程的目标不是教会读者写某个具体业务模块，而是建立一套架构判断力。学完之后，你应当能够：
- 区分医疗SaaS与通用SaaS在租户模型、数据合规、可用性等级上的本质差异；
- 为一家连锁诊所、区域检验中心或互联网医院选择合适的多租户隔离策略；
- 画出包含接入层、租户路由、业务域、数据层与合规审计的端到端架构；
- 用可量化的指标（隔离度、单租户成本、故障爆炸半径、审计可追溯性）评估架构方案；
- 按工程实践路线图，把架构从概念推进到可上线、可运维的形态。
换句话说，课程交付的是“设计决策的依据”，而不是“一套固定答案”。医疗行业没有放之四海皆准的架构，只有与业务规模、监管要求和成本约束相匹配的架构。
二、医疗SaaS的定义与分类
医疗SaaS，是指由平台方统一建设、运维，以订阅或按量方式向多个医疗机构、科室或健康服务主体提供软件能力的服务形态。它与传统院内自建系统的关键区别在于：基础设施与软件生命周期由平台方承担，业务数据的所有权与合规责任仍归属医疗机构。这一“责任分离”是后续所有架构设计的出发点。
按服务对象与业务深度，医疗SaaS大致可分为四类：
| 类型 | 典型形态 | 架构关注重点 |
|---|---|---|
| 业务工具型 | 预约挂号、随访、健康管理、在线问诊 | 快速迭代、租户配置灵活、轻量隔离 |
| 临床业务型 | 云HIS、云EMR、云LIS/PACS | 强数据隔离、诊疗合规、高可用、审计留痕 |
| 数据与协同型 | 区域检验互认、影像云、处方流转 | 跨机构数据交换、标准接口、隐私计算 |
| 平台能力型 | 医保结算中台、支付、电子签名、消息通知 | 高并发、幂等、对账一致性、监管对接 |
分类的意义在于：越靠近临床与数据协同，隔离与合规要求越高，架构成本也越高。设计时必须先明确产品落在哪一类，再决定隔离粒度，而不是先写代码后补隔离。
三、多租户架构的核心挑战
多租户是医疗SaaS的技术核心，也是风险集中点。它要同时满足四个相互拉扯的目标：
- 数据隔离：A医院的病历绝不能被B医院看到，且要能通过审计证明这一点；
- 成本摊薄：共享数据库、共享计算资源，才能把单租户成本压到可接受水平；
- 配置差异：不同机构的科室结构、收费项目、流程节点、权限模型各不相同；
- 故障隔离：一个租户的慢查询或流量高峰，不应拖垮整个平台。
这四者天然冲突：隔离越强，成本越高；共享越多，爆炸半径越大。常见的隔离策略有三档——共享库共享表（加 tenant_id）、共享库独立Schema、独立库/独立实例。选择依据不是“哪个先进”，而是租户的数据敏感度、规模与付费能力。例如，小型健康管理工具可采用共享表；而承载电子病历的云EMR，通常至少要做到独立Schema，核心三甲客户甚至要求独立库。
四、整体架构设计方法论与工程实践路线图
我们采用“约束驱动、分层解耦、渐进演进”的方法论。约束驱动，指先梳理合规、可用性、成本三类硬约束；分层解耦，指把系统划分为接入与租户路由层、业务域层、数据与隔离层、合规审计层；渐进演进，指架构随租户规模分阶段升级，而非一次性过度设计。
下图给出医疗SaaS平台的端到端架构骨架，以及租户请求从进入到数据落地的关键路径。它同时表达了“分层”与“隔离决策点”两个核心概念。
基于上述架构，工程实践路线图建议分四个阶段推进，每个阶段都有明确的交付物与验收标准：
| 阶段 | 核心任务 | 关键交付物 | 验收判断 |
|---|---|---|---|
| P1 约束梳理 | 明确租户类型、数据敏感度、合规等级、SLA目标 | 约束清单与隔离策略选型表 | 每个租户类型都有对应隔离档位 |
| P2 骨架搭建 | 实现网关、租户路由、统一认证、审计日志 | 可运行的最小多租户骨架 | 两个租户数据互不可见且可审计 |
| P3 业务域填充 | 按领域接入业务模块，统一配置与权限模型 | 可配置的租户级业务能力 | 同一功能在不同租户呈现不同配置 |
| P4 演进与治理 | 故障隔离、容量治理、成本优化、合规复核 | 监控看板与治理机制 | 单租户故障不影响其他租户 |
需要强调的是，路线图不是瀑布式的。P2 阶段搭出的骨架，往往会在 P3 阶段暴露出隔离粒度不合理的问题，此时应回到 P1 重新评估，而不是在错误的分层上继续堆功能。架构设计的本质，是在约束变化时仍能低成本调整。