🏥 线上看诊平台架构规划

0️⃣ 先讲三件会决定整个规划走向的事

0.1 最大的门槛不是技术，是资质

「互联网医院」没有独立牌照。它是《医疗机构执业许可证》的两种许可形式之一，必须依托实体医疗机构，主管机关明令严禁「空中办院」。

换句话说：没有一家实体医疗机构作为依托，写再多代码都无法合法提供线上诊疗。这是 L0 层的硬闸门，排在所有技术工作之前。

0.2 Telegram 在中国大陆不可用

现有 cdrm-bot 以 Telegram 为用户界面。Telegram 在中国大陆被封锁，患者端必须整组换掉（微信小程序／App／支付宝小程序）。既有代码中可延用的是领域逻辑，不是界面层。

同理，先前评估过的 Cloudflare 在此情景下完全不适用：境内服务需 ICP 备案，且数据必须境内存储。

0.3 「不得首诊」出现松动，但别把它当成既定条件

现行规则：互联网诊疗仅限常见病／慢性病复诊、术后随访、健康管理；禁止首诊、急危重症、麻醉及一类精神药品处方、有创操作。患者就诊时应提供已有明确诊断的病历资料。

变化：经国家卫健委批复，自 2026 年 1 月起北京市率先启动为期一年的互联网诊疗首诊试点。

1️⃣ 总体分层树

线上看诊平台
├── L0 资质与合规层（法定前置，技术无法绕过）
├── L1 基础设施层（境内云、等保三级）
├── L2 数据层（分类分级、留存、不出境）
├── L3 应用层（患者端／医生端／药师端／管理端／监管接口）
├── L4 业务流程层（问诊到配药的完整链路）
├── L5 外部集成层（HIS／医保／处方流转／物流／CA）
└── L6 运营与风控层（医疗品质、投诉、追溯、报送）

依赖方向由上而下：L0 未完成，L3 以下做出来也不能上线运营。但 L1／L2 的技术准备可与 L0 的行政流程并行。

2️⃣ L0 资质与合规层

L0 资质与合规
├── 机构资质
│   ├── 实体医疗机构（硬前提）
│   │   └── 《医疗机构执业许可证》
│   ├── 互联网诊疗资质（二选一）
│   │   ├── 途径A：于既有执业许可证「服务方式」增加互联网诊疗
│   │   └── 途径B：申请互联网医院作为第二名称
│   └── 依托关系证明（自建 或 与实体机构合作协议）
├── 人员资质
│   ├── 医生
│   │   ├── 执业医生资格 + 执业满 3 年
│   │   ├── 多点执业备案（跨机构时）
│   │   └── 实名认证与电子签名凭证
│   ├── 药师（处方审核，法定必要角色）
│   └── 护理／客服（分诊、随访）
├── 网络与电信资质
│   ├── ICP 备案（境内服务必要）
│   ├── ICP 经营许可证（涉经营性业务时）
│   └── 《互联网药品信息服务资格证书》
├── 药品相关资质（若自营药品环节）
│   ├── 《药品经营许可证》
│   └── 药品网络销售备案
└── 监管接入
    ├── 省级互联网医疗服务监管平台（强制对接）
    ├── 诊疗行为全程留痕上报
    └── 医生身份与处方资料报送

规划备注：途径 A（既有机构加服务方式）比途径 B（申请第二名称）流程轻。若合作对象已是实体医疗机构，优先评估 A。

3️⃣ L1 基础设施层

L1 基础设施
├── 部署位置（硬约束：数据不出境）
│   ├── 境内公有云医疗合规专区（阿里云／腾讯云／华为云）
│   ├── ❌ 排除：Cloudflare、境外 VPS、境外 CDN
│   └── 多可用区部署（医疗业务不可长时间中断）
├── 安全合规基建
│   ├── 网络安全等级保护三级（等保三级）
│   │   ├── 定级备案 → 建设整改 → 测评 → 监督检查
│   │   └── 安全技术 + 安全管理 双构面
│   ├── 商用密码应用安全性评估（密评）
│   └── 堡垒机、日志审计、数据库审计、WAF、抗DDoS
├── 网络
│   ├── 境内 DNS + 境内 CDN（需备案）
│   ├── 全站 HTTPS，国密算法兼容性评估
│   └── 音视频专用通道（低延迟，见 L3）
├── 环境隔离
│   ├── 生产／预发／测试／开发 四环境
│   └── 生产数据禁止下行至非生产环境（去识别化后方可）
└── 灾备与持续运营
    ├── 同城双活 + 异地备份
    ├── RPO／RTO 目标依医疗业务定义
    └── 病历数据备份保存期须配合 15 年留存要求

4️⃣ L2 数据层

L2 数据
├── 数据分类分级
│   ├── 个人健康医疗资料 →《个人信息保护法》敏感个人信息
│   ├── 需单独同意 + 告知处理目的
│   └── 数据出境：原则禁止（本规划直接排除出境情景）
├── 核心数据域
│   ├── 患者主索引（EMPI）
│   ├── 电子病历（EMR）
│   │   ├── 图文对话、音视频记录、诊断、医嘱
│   │   └── 留存 ≥ 15 年（法定）
│   ├── 电子处方
│   │   ├── 医生电子签名 + 药师审核记录
│   │   └── 流转状态全链路留痕
│   ├── 订单与支付（医保 + 自费）
│   └── 监管报送数据集
├── 安全措施
│   ├── 传输加密、存储加密、字段级加密（身份证号等）
│   ├── 最小权限 + 医生仅可见其接诊患者
│   ├── 全量操作审计（谁在何时看了哪位患者）
│   └── 去识别化管线（统计、AI 训练用）
└── 生命周期
    ├── 采集 → 使用 → 共享（受限）→ 归档 → 销毁
    └── 患者权利：查阅、复制、更正、删除（受法定留存期限制）

设计原则：留存期与删除权冲突时以法定留存优先，需在隐私政策中明确写出。

5️⃣ L3 应用层

L3 应用
├── 患者端（Telegram 不可用，全部重建）
│   ├── 微信小程序（主力入口）
│   ├── 支付宝小程序（次要入口）
│   ├── App（iOS／Android，深度功能与推播）
│   └── H5（分享与外部引流）
│       └── 功能模块
│           ├── 实名认证（身份证 + 人脸核验）
│           ├── 建档与家庭成员管理
│           ├── 病历资料上传（复诊资格判定的依据）
│           ├── 自述病情采集 ★ 可延用既有规格
│           ├── 科室／医生选择与预约排班
│           ├── 候诊队列与叫号 ★ 可延用既有逻辑
│           ├── 图文／音视频问诊
│           ├── 处方查看与购药
│           ├── 医保结算与自费支付
│           ├── 药品物流追踪
│           └── 随访与健康管理
├── 医生端
│   ├── Web 工作台（主要）+ App（移动接诊）
│   └── 功能模块
│       ├── 医生实名登入 + 执业资质绑定
│       ├── 排班与接诊设定
│       ├── 候诊队列与叫号 ★ 可延用既有逻辑
│       ├── 患者资料检视（既往病历、自述、上传资料）
│       ├── 复诊资格判定（法定必要步骤）
│       ├── 音视频问诊 + 图文问诊
│       ├── 电子病历书写（结构化模板）
│       ├── 开立电子处方 + 电子签名
│       └── 转诊与线下就医建议（不符复诊条件时）
├── 药师端
│   ├── 处方审核队列
│   ├── 通过／退回／建议修改
│   └── 审核记录留痕（法定）
├── 管理端
│   ├── 机构、科室、人员与资质管理
│   ├── 排班与号源管理
│   ├── 品质管理（病历品质、处方点评）
│   ├── 投诉与纠纷处理
│   └── 运营报表
└── 监管接口
    ├── 省级监管平台数据上报
    ├── 诊疗行为留痕
    └── 异常行为预警（如处方超量、非本人接诊）

★ 标记＝既有 cdrm-bot 已实作、可延用的领域逻辑。

6️⃣ L4 业务流程树

L4 业务流程（复诊主链路）
患者发起
├── 1. 实名认证
│   └── 未通过 → 中止
├── 2. 上传既往病历资料
│   └── 资料不足 → 引导线下就诊
├── 3. 选择科室／医生 → 取号进队列 ★
├── 4. 自述病情采集 ★
│   └── 紧急症状关键字 → 中断流程，引导急诊（安全闸）
├── 5. 医生接诊
│   ├── 5a. 复诊资格判定（法定）
│   │   └── 不符 → 转线下，不得开方
│   └── 5b. 图文／音视频问诊（全程留痕）
├── 6. 电子病历书写
├── 7. 开立电子处方（医生电子签名）
│   └── 禁忌类别拦截（麻醉药品、一类精神药品等）
├── 8. 药师审核
│   └── 退回 → 回到步骤 7
├── 9. 处方流转
│   ├── 院内药房
│   └── 电子处方流转平台 → 社会药房
├── 10. 结算
│   ├── 医保预结算 → 返回报销金额
│   ├── 患者支付自费部分
│   └── 医保扣费确认
├── 11. 药品配送（合规冷链／特殊药品规则）
└── 12. 随访与复购提醒

横切关注（每一步都要）
├── 全流程留痕与时间戳
├── 监管平台同步上报
└── 异常中断可回溯

第 4 步的紧急症状安全闸，是既有「病人自述病情标准规格」中紧急警语的延伸与强化——在此情景下不只是提示，而应能中断流程。

7️⃣ L5 外部集成树

L5 外部集成
├── 医疗机构内部系统
│   ├── HIS（挂号、收费、医嘱）
│   ├── EMR（电子病历）
│   ├── LIS／PACS（检验、影像，复诊常需调阅）
│   └── 药品库存
├── 医保
│   ├── 国家医保信息平台
│   ├── 医保电子凭证（身份核验）
│   └── 线上结算接口（预结算 → 支付 → 扣费确认）
├── 处方
│   ├── 电子处方流转平台
│   │   ├── 就诊登记
│   │   ├── 电子处方上传预核验
│   │   ├── 处方医保电子签名
│   │   └── 电子处方审核
│   └── 处方追溯
├── 身份与签名
│   ├── 实名认证（权威源核验）
│   ├── 人脸识别活体检测
│   └── 第三方 CA（医生电子签名、时间戳）
├── 支付
│   ├── 微信支付／支付宝
│   └── 对账与退款
├── 音视频
│   └── 境内音视频云（含录制与合规留存）
├── 药品供应链
│   ├── 药品目录与适应症库
│   ├── 药师知识库（相互作用、禁忌）
│   └── 物流（普通／冷链）
└── 通知
    ├── 短信（境内服务商）
    └── 小程序订阅消息／App 推播

8️⃣ L6 运营与风控树

L6 运营与风控
├── 医疗品质
│   ├── 病历品质检查
│   ├── 处方点评
│   └── 医生接诊品质评分
├── 风险控制
│   ├── 非本人接诊侦测（医生实名 + 人脸抽检）
│   ├── AI 代替医生接诊侦测（法规明令禁止）
│   ├── 处方异常（超量、超适应症）
│   └── 患者身份冒用
├── 投诉与纠纷
│   ├── 投诉受理与时限
│   ├── 病历封存流程
│   └── 医疗责任保险
├── 监管报送
│   └── 依省级监管平台要求的频率与字段
└── 运营指标
    ├── 接诊量、应答时长、完诊率
    ├── 处方合格率、药师退回率
    └── 患者满意度

9️⃣ 从现况到目标的演进路线

演进路线
├── Phase 0 — 现况（已完成）
│   ├── cdrm-bot：Telegram 挂号、自述病情规格 v2、繁简双语、只读后台
│   ├── 部署：境外 VPS
│   └── 定位：内部工具，非医疗服务
│
├── Phase 1 — 领域逻辑抽取与境内原型（纯技术，无需资质）
│   ├── 把可延用逻辑抽成独立套件
│   │   ├── 队列与叫号（queue.js 的状态机）
│   │   ├── 自述病情解析（parseDescription，已支持简体）
│   │   └── i18n 简体语系表（已完成，直接可用）
│   ├── 患者端换成微信小程序（Telegram 全部丢弃）
│   ├── 境内云部署 + ICP 备案
│   └── 业务范围限缩：**仅预约挂号与候诊，不含任何诊疗行为**
│       └── 此阶段不触及诊疗，可先行验证产品与流程
│
├── Phase 2 — 合规基建（与 Phase 1 并行，时程最长）
│   ├── 寻找／确立依托的实体医疗机构 ←── 关键路径起点
│   ├── 互联网诊疗资质申请（途径 A 或 B）
│   ├── 等保三级定级、整改、测评
│   ├── 省级监管平台对接
│   └── 医生、药师团队与资质备案
│
├── Phase 3 — 互联网诊疗上线（资质到位后）
│   ├── 复诊资格判定
│   ├── 图文／音视频问诊 + 电子病历
│   ├── 电子处方 + 药师审核 + 处方流转
│   ├── 医保结算
│   └── 药品配送
│
└── Phase 4 — 扩展（视政策与规模）
    ├── 首诊试点（所在地取得资格才开启，架构预留开关）
    ├── AI 预问诊（仅辅助采集，不得替代医生接诊）
    ├── 慢病管理与家庭医生
    └── 多机构接入

🔟 既有资产可延用性盘点

1️⃣1️⃣ 尚未确认、需要决策或查证的事项

以下项目会实质影响架构，但目前信息不足以定案：

1. 是否已有可依托的实体医疗机构？ 这决定整个规划是「有路径」还是「仅为纸上规划」。
2. 目标省市 — 监管平台对接规格、医保接口、首诊试点资格都因地而异。
3. 自营或合作模式 — 自建互联网医院 vs. 接入既有平台，架构复杂度差距极大。
4. 是否涉及药品销售 — 涉及则需额外资质与供应链建设，是另一整条路线。
5. 各省监管平台的具体接入技术规格（需取得目标省份的正式文件）。
6. 北京首诊试点的实施细则与后续是否推广。
7. 医疗责任与保险安排。

📚 参考资源

• 关于印发互联网诊疗监管细则（试行）的通知 — 国家卫生健康委
• 解读《互联网诊疗监管细则（试行）》— 汉坤律师事务所
• 不得对首诊患者开展互联网诊疗 — 北京市人民政府
• 突破首诊限制，让互联网诊疗更实用 — 光明网（2026-02）
• 互联网医院获批的五大关键：资质、平台、人员、制度与监管 — 健康界
• 互联网医院开发系统如何对接医保支付与电子处方平台 — 阿里云开发者社区