1. 互联网医院平台业务全景与架构总览

互联网医院并不是“把医院搬到网页上”，而是以实体医疗机构为依托，通过互联网技术向患者提供部分诊疗服务的合法医疗形态。理解它的第一步，是分清“能做什么”和“不能做什么”。按照现行监管框架，互联网医院可以开展在线复诊、健康咨询、慢病管理、处方流转等业务，但首诊不得线上进行，麻醉药品、精神药品等特殊管理药品不得在线开具，急危重症必须引导线下就医。这些边界不是限制，而是平台设计的硬约束——它们直接决定了业务域划分、角色权限和数据结构。

从业务全景看，互联网医院平台围绕四类核心业务域运转。在线复诊是主干：患者基于线下明确诊断，在线上完成病情描述、资料上传、医生问诊、开具处方。处方流转承接复诊结果，处方经药师审核后，可流转至院内药房或院外合作药店，形成“开方—审方—调剂—配送”的闭环。健康咨询不产生处方，属于轻量级服务，用于分诊引导和健康宣教。慢病管理则是长周期业务，通过随访计划、用药提醒、指标采集，把单次问诊延伸为持续照护。四者共享患者、医生、药品、订单等基础数据，但业务规则和合规要求各不相同。

参与角色决定了权限模型和协作关系。患者发起咨询或复诊、上传资料、支付、签收药品；医生负责问诊、判断是否符合复诊条件、开具处方；药师独立审核处方，对用药合理性、配伍禁忌、剂量进行把关；医院作为责任主体，提供资质、排班、药房和病历管理；监管部门通过数据接口对处方、诊疗行为、资质进行监督。这五类角色不是简单的“用户”，而是带有不同法律责任和操作边界的参与者，平台必须在每个环节明确“谁可以做、谁必须做、谁不能做”。

平台整体架构通常分为四层。接入层面向患者端、医生端、药师端和监管端，处理身份认证、协议适配、限流和网关路由；业务层承载复诊、处方、咨询、慢病等核心服务，并编排订单、支付、消息、随访等能力；数据层管理患者主索引、电子病历、处方数据、药品目录和日志审计，强调隐私保护与可追溯；基础设施层提供计算、存储、网络、容器编排和安全防护。分层的目的不是画得好看，而是让合规要求能落到具体层：例如处方必须留痕，就落在数据层的审计表；药师审核必须独立，就落在业务层的权限隔离。

把四层架构和业务域放在一起看，会发现一个关键设计原则：合规约束必须逐层落地。例如“复诊才能开方”这条规则，在接入层表现为患者身份与就诊记录校验，在业务层表现为复诊资格判断服务，在数据层表现为历史诊断与处方关联，在基础设施层则通过日志和备份保证可追溯。如果只在某一层做限制，其他层就可能被绕过。

以一个典型场景为例：一位高血压患者在线复诊。患者端提交复诊申请并上传近期血压记录；接入层完成实名认证和请求路由；业务层的复诊服务调取数据层中的历史诊断，确认符合复诊条件后分配医生；医生问诊后开具处方，处方服务调用药师审核接口；药师端完成审核，处方状态变为“已审核”；订单服务生成购药订单并触发支付；支付成功后，处方流转至药房，进入调剂和配送环节。整个过程中，监管端可通过审计日志查看处方开具、审核、流转的时间戳和操作人。这个例子说明，业务全景不是四个孤立的模块，而是一条由角色、数据、规则共同驱动的协作链。

从工程视角看，平台建设初期最容易犯的错误是“先做页面，后补规则”。正确的顺序应当是：先明确业务域边界和角色权限，再设计数据模型和状态机，最后实现接入层和界面。因为互联网医院的每一个业务动作几乎都对应着监管要求和法律责任，架构分层不只是技术选择，更是合规能力的组织方式。理解这一点，就抓住了互联网医院平台架构的总纲。