微医互联网医院平台全链路拆解：医生端与患者端功能架构及落地实践

简介：这份PPT资料面向互联网医疗产品经理、医疗信息化从业者及医院管理者，系统梳理了微医互联网医院平台的整体设计思路与功能模块，可用于产品调研、方案汇报或竞品分析等场景。资源包共1个pptx文件，约25MB，以图文并茂的幻灯片形式呈现，便于直接引用或二次编辑。内容围绕平台架构、医生端与用户端三条主线展开：医生端涵盖在线复诊、远程门诊、远程会诊、双向转诊、检查检验、远程培训、视频会议与面诊处方八大模块；用户端则包括患者主页、在线复诊、预约挂号、智能导诊与个人中心。目录层级清晰，每项功能均配有独立章节说明，能帮助读者快速理解互联网医院从技术架构到业务落地的完整链路。目前已有317人学习下载，适合需要搭建或评估互联网医院产品体系的中高级从业者参考借鉴。

1. 微医互联网医院平台拆解：从医生端到患者端的全链路功能地图

如果你正在做互联网医院相关的产品选型或系统集成，大概率会遇到一个绕不开的参照物——微医互联网医院平台。这份 2018 年 6 月的产品介绍文档，虽然时间有些年头，但它把互联网医院的业务架构讲得足够完整：医生端覆盖在线复诊、远程门诊、远程会诊、双向转诊、检查检验、远程培训、视频会议、面诊处方八个模块，患者端则包含患者主页、在线复诊、预约挂号、智能导诊、个人中心五个入口。换句话说，它是一份能让你快速理解“互联网医院到底该有哪些功能块”的落地参考。

这份资料适合三类人：一是正在做互联网医院产品规划的产品经理，需要对照功能清单查漏补缺；二是负责对接医院信息系统的开发工程师，想搞清楚业务模块之间的数据流向；三是基层医疗机构的信息化负责人，评估自己需要哪些模块才能接入上级医院的远程协作体系。文档本身不是技术手册，没有 API 文档和数据库设计，但它给出的业务流程和模块划分，足够你用来做需求梳理和架构对标。

2. 平台架构与业务模块：互联网医院的技术底座怎么搭

2.1 四层架构拆解：业务模块、支撑系统、运营管理、数据层

从文档给出的架构图来看，微医互联网医院平台采用典型的四层设计。最上层是业务模块，分为互联网医院（医医协作）和互联网医院（用户端）两条线；中间层是支撑系统，包括医院端、医生端、远程门诊、双向转诊、远程会诊、检查检验、医教平台等；底层是运营管理后台，涵盖医院管理、医生管理、资源管理、对账系统、统计报表、医保结算等；最底下是数据层，涉及 CDSS/AI、处方共享、健康档案、电子病历、中医辨证论治、健康扶贫等数据能力。

这个分层逻辑的核心思路是：业务模块面向不同角色（医生、患者、医院管理者）提供功能入口，支撑系统负责具体的业务流转，运营管理后台做资源调度和财务结算，数据层则沉淀病历、处方、健康档案等核心资产。常见做法是，业务模块通过 API 网关调用支撑系统的服务，支撑系统再读写数据层的电子病历和处方库。如果你要自建类似平台，这个分层可以直接复用，但要注意数据层的中医辨证论治和健康扶贫模块属于特色功能，不是所有互联网医院都需要。

注意：文档中的架构图是 2018 年的版本，当时微医云的技术栈以云计算为基础，强调高并发和数据安全。如果你现在做选型，需要额外考虑微服务治理、容器化部署和等保合规要求，这些在原始文档中没有体现。

2.2 医医协作与用户端的模块映射关系

医生端和患者端并不是孤立的两套系统，它们通过业务单据和消息通道紧密耦合。具体来说：

这张映射表的价值在于：当你要做系统集成时，可以按业务单据来设计接口。比如在线复诊这条线，患者端提交复诊申请后，医生端会生成待接诊订单，医生接诊后书写病历和处方，处方流转到药房或配送系统，最后患者端收到取药通知。整个链路的每个节点都需要一个状态字段来驱动，常见做法是用状态机来管理订单流转，状态包括待接诊、问诊中、待开方、待审核、待配送、已完成、已取消。

2.3 从文档到落地：搭建互联网医院功能清单的实操步骤

如果你要基于这份文档做需求梳理，可以按以下步骤操作：

第一步，提取所有功能模块，按角色分类。医生端八个模块、患者端五个模块，先列成一张大表。

第二步，为每个模块定义核心业务单据。比如在线复诊对应“复诊申请单”，远程会诊对应“会诊单”，双向转诊对应“转诊单”。单据是系统间交互的载体。

第三步，梳理单据的状态流转。以在线复诊为例，状态可以设计为：待接诊 → 问诊中 → 待开方 → 待审核 → 待配送 → 已完成。每个状态对应不同的操作权限和通知事件。

第四步，确定数据共享范围。文档提到双向转诊依赖电子病历和检查检验报告共享，这意味着你需要设计一个病历共享服务，支持按患者 ID 和就诊 ID 查询病历摘要。

第五步，标注外部系统依赖。医保结算、区域卫生平台、医院 HIS 系统都是外部依赖，需要在架构图中单独标出，并定义接口协议。

{ "module": "online_revisit", "roles": ["doctor", "patient"], "documents": ["revisit_application", "medical_record", "prescription"], "status_flow": [ "pending_accept", "in_consultation", "pending_prescription", "pending_review", "pending_delivery", "completed", "cancelled" ], "external_deps": ["pharmacy_system", "delivery_system", "payment_gateway"] }

上面这段 JSON 是一个模块定义的示例，你可以把它作为需求文档的附件。status_flow字段定义了状态流转顺序，external_deps列出了需要对接的外部系统。实际开发时，每个状态还需要定义触发事件和通知模板，比如“待接诊”状态需要给医生推送新订单提醒，“待配送”状态需要给患者发送取药通知。

3. 医生端核心模块实战：在线复诊、远程会诊与双向转诊的业务流

3.1 在线复诊：从接诊到开方的完整状态机

在线复诊是医生端使用频率最高的模块。文档描述的业务流程是：医生选择待接诊订单 → 调阅患者资料 → 进入诊室沟通 → 书写病历与处方。这个流程看似简单，但实际落地时有几个关键点。

首先是接诊环节。医生登录后看到的是待接诊列表，列表需要展示患者姓名、复诊类型、申请时间、病情摘要。点击接诊后，系统要锁定该订单，防止其他医生重复接诊。常见做法是用数据库行锁或 Redis 分布式锁来实现，锁的过期时间一般设为 5 分钟，超时未操作自动释放。

其次是调阅患者资料。文档提到“初步了解情况”，这意味着医生需要看到患者的历史就诊记录、检查检验报告、用药记录。这些数据可能来自不同的系统，需要通过患者主索引（EMPI）来聚合。如果你在做集成，建议定义一个患者资料聚合接口，入参是患者 ID，出参是结构化的病历摘要。

然后是问诊环节。文档没有明确说明问诊方式，但从“进入诊室与患者沟通”来看，支持图文和视频两种模式。图文问诊的实现相对简单，视频问诊则需要集成实时音视频 SDK。常见做法是使用 WebRTC 或第三方音视频云服务，问诊房间按订单 ID 创建，医生和患者通过房间号加入。

最后是书写病历与处方。病历需要符合电子病历规范，处方则需要包含药品名称、规格、用法用量、疗程。处方提交后进入审核流程，审核通过后才能流转到药房或配送系统。

# 在线复诊状态机核心逻辑示例 REVISIT_STATUS = { "PENDING_ACCEPT": "待接诊", "IN_CONSULTATION": "问诊中", "PENDING_PRESCRIPTION": "待开方", "PENDING_REVIEW": "待审核", "PENDING_DELIVERY": "待配送", "COMPLETED": "已完成", "CANCELLED": "已取消" } # 允许的状态流转 TRANSITIONS = { "PENDING_ACCEPT": ["IN_CONSULTATION", "CANCELLED"], "IN_CONSULTATION": ["PENDING_PRESCRIPTION", "CANCELLED"], "PENDING_PRESCRIPTION": ["PENDING_REVIEW"], "PENDING_REVIEW": ["PENDING_DELIVERY", "PENDING_PRESCRIPTION"], "PENDING_DELIVERY": ["COMPLETED"], } def transition(current_status, action): """根据当前状态和操作，返回下一个状态""" allowed = TRANSITIONS.get(current_status, []) if action not in allowed: raise ValueError(f"状态 {current_status} 不允许执行 {action}") return action

这段代码定义了一个简化的状态机。TRANSITIONS字典描述了每个状态可以流转到哪些下一个状态。比如PENDING_REVIEW可以流转到PENDING_DELIVERY（审核通过）或PENDING_PRESCRIPTION（审核驳回，医生重新开方）。实际使用时，你需要把状态和操作映射到数据库字段，并在每次流转时记录操作日志，方便追溯。

3.2 远程会诊：点名会诊与平台级会诊的流程差异

远程会诊是面向疑难病例的协作手段。文档明确区分了两种模式：点名会诊和平台级会诊。点名会诊由发起方医生主动选择会诊专家，平台级会诊则由医务中心协助安排。这两种模式的流程差异直接影响系统设计。

点名会诊的流程是：选择会诊医生 → 填写会诊单 → 线上/线下支付 → 会诊沟通 → 会诊结束查看会诊单详情。关键点在于“选择会诊医生”这一步，系统需要提供专家列表，支持按科室、职称、擅长领域筛选。会诊单需要包含患者基本信息、病情摘要、初步诊断、会诊目的。支付环节需要对接支付网关，支持线上支付和线下支付两种方式。

平台级会诊的流程是：提交会诊申请 → 医务中心审核 → 安排会诊医生 → 会诊沟通 → 会诊结束。与点名会诊的区别在于，平台级会诊多了一个医务中心审核和安排的环节。这意味着系统需要为医务中心角色提供管理后台，支持会诊申请的审核、专家排期、会诊室分配。

从技术实现角度看，两种模式可以共用同一套会诊单和会诊室，区别在于会诊医生的确定方式。常见做法是，会诊单上增加一个consultation_type字段，值为designated或platform。如果是designated，发起方直接指定专家；如果是platform，则由医务中心在后台指派。

提示：远程会诊涉及多学科专家，会诊室需要支持多人视频。建议选择支持 9 人以上同时在线、具备屏幕共享和文件传输功能的音视频方案。会诊结束后，会诊报告需要回传到发起方医生的系统中，并关联到患者的电子病历。

3.3 双向转诊：号源锁定与病历共享的接口设计

双向转诊是分级诊疗的核心环节。文档描述的业务逻辑是：基层医生将危重病、疑难病患者转诊至上级医疗机构，完成诊疗后再转诊回基层康复。这个过程依赖两个关键能力：号源锁定和病历共享。

号源锁定是指基层医生在转诊时，需要直接预约上级医院的号源。系统需要对接上级医院的号源池，支持按科室、医生、时间段查询可用号源，并在转诊单提交时锁定号源。常见做法是，号源服务提供lock和unlock两个接口，转诊单创建时调用lock，转诊取消或超时未确认时调用unlock。

病历共享是指转诊过程中，患者的电子病历和检查检验报告需要随转诊单一起流转。系统需要提供病历摘要接口，支持按患者 ID 和就诊 ID 查询。转诊单上需要附带病历摘要的引用 ID，上级医院医生接诊时可以直接调阅。

# 号源锁定接口示例 POST /api/hospital/registration/lock Content-Type: application/json { "schedule_id": "SCH20240101001", "patient_id": "P123456", "referral_id": "REF20240101001", "lock_duration": 300 } # 响应 { "code": 0, "message": "锁定成功", "data": { "lock_id": "LOCK20240101001", "expire_at": "2024-01-01T10:05:00Z" } }

这个接口示例展示了号源锁定的基本参数。schedule_id是排班 ID，patient_id是患者 ID，referral_id是转诊单 ID，lock_duration是锁定持续时间（秒）。锁定成功后返回lock_id和过期时间。如果转诊单在锁定期间未确认，号源会自动释放。实际开发时，你需要考虑并发锁定的问题，建议用 Redis 的SETNX命令来实现分布式锁。

4. 患者端功能落地：智能导诊、预约挂号与个人中心的数据流

4.1 智能导诊：症状推断与科室推荐的实现思路

智能导诊是患者端的入口功能。文档描述的逻辑是：根据患者的症状自动生成初步的疾病推断，引导患者合理就医。这个功能的实现通常分为三步：症状采集、推理引擎、科室推荐。

症状采集界面需要提供人体图或症状列表，让患者选择不适部位和症状描述。常见做法是提供一个人体正面和背面的示意图，患者点击部位后弹出该部位对应的症状选项，比如点击“头部”后显示头痛、头晕、失眠等症状。

推理引擎是核心。简单做法是基于规则引擎，维护一张症状-疾病-科室的映射表。比如“头痛 + 发热 + 颈部僵硬”映射到“脑膜炎”，推荐科室为“神经内科”或“感染科”。复杂做法是引入机器学习模型，用历史导诊数据训练分类器。对于大多数互联网医院来说，规则引擎已经够用，维护成本低且可解释性强。

科室推荐需要结合医院的科室设置和号源情况。如果推荐科室没有号源，需要推荐备选科室。常见做法是，推理引擎输出一个科室列表，按置信度排序，然后查询每个科室的号源情况，优先展示有号源的科室。

# 基于规则的智能导诊示例 SYMPTOM_RULES = [ { "symptoms": ["头痛", "发热", "颈部僵硬"], "disease": "脑膜炎", "departments": ["神经内科", "感染科"], "confidence": 0.85 }, { "symptoms": ["咳嗽", "咳痰", "胸闷"], "disease": "支气管炎", "departments": ["呼吸内科"], "confidence": 0.75 }, { "symptoms": ["腹痛", "腹泻", "恶心"], "disease": "急性胃肠炎", "departments": ["消化内科", "急诊科"], "confidence": 0.80 } ] def triage(patient_symptoms): """根据患者症状匹配规则，返回推荐科室""" results = [] for rule in SYMPTOM_RULES: match_count = len(set(patient_symptoms) & set(rule["symptoms"])) if match_count >= 2: results.append({ "disease": rule["disease"], "departments": rule["departments"], "confidence": rule["confidence"] * (match_count / len(rule["symptoms"])) }) results.sort(key=lambda x: x["confidence"], reverse=True) return results[:3]

这段代码展示了一个简化的规则匹配逻辑。SYMPTOM_RULES是规则库，每条规则包含症状组合、疾病名称、推荐科室和基础置信度。triage函数接收患者症状列表，计算匹配度并返回前三个推荐结果。实际使用时，规则库需要由医学专家维护，并定期根据导诊准确率进行优化。

4.2 预约挂号：号源池管理与排队机制

预约挂号是患者端使用最频繁的功能。文档描述的逻辑是：患者提前在线预约医生，避免线下排队。这个功能的背后是号源池管理和排队机制。

号源池管理需要解决三个问题：号源生成、号源锁定、号源释放。号源生成通常由排班系统完成，医生排班后自动生成号源，每个号源包含医生 ID、科室 ID、就诊时间段、号源序号。号源锁定在患者提交预约时触发，锁定成功后号源状态变为“已预约”。号源释放在患者取消预约或超时未支付时触发，号源状态恢复为“可预约”。

排队机制是指当号源已满时，患者可以进入候补队列。当有患者取消预约时，系统自动通知候补队列中的患者。常见做法是用消息队列来实现，候补患者按加入时间排序，号源释放时发送通知，先到先得。

-- 号源表结构示例 CREATE TABLE registration_schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doctor_id BIGINT NOT NULL, department_id BIGINT NOT NULL, schedule_date DATE NOT NULL, time_slot VARCHAR(20) NOT NULL COMMENT '时间段，如 09:00-09:30', total_quota INT NOT NULL DEFAULT 0, available_quota INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1 COMMENT '1-可预约 2-已满 3-停诊', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_doctor_date (doctor_id, schedule_date), INDEX idx_department_date (department_id, schedule_date) ); -- 预约记录表 CREATE TABLE registration_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, schedule_id BIGINT NOT NULL, patient_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT '1-待支付 2-已预约 3-已取消 4-已完成', queue_number INT COMMENT '排队号', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_schedule_patient (schedule_id, patient_id), INDEX idx_patient (patient_id) );

这两张表是预约挂号的核心。registration_schedule存储号源信息，available_quota字段记录剩余号源数。registration_order存储预约记录，queue_number字段记录排队号。uk_schedule_patient唯一索引防止同一患者重复预约同一号源。实际开发时，号源扣减需要用乐观锁或悲观锁来保证并发安全，常见做法是在UPDATE语句中加available_quota > 0条件。

4.3 个人中心：病历、报告与支付数据的聚合展示

个人中心是患者管理自身健康信息的入口。文档描述的功能包括：管理个人信息、查看历史就诊记录、接收健康提醒、进行支付操作。这些功能的数据来源不同，需要在个人中心做聚合展示。

个人信息包括姓名、性别、年龄、手机号、身份证号等，通常由患者注册时填写，支持修改。历史就诊记录来自电子病历系统，需要按时间倒序展示，每条记录包含就诊时间、医生、科室、诊断。检查检验报告来自 LIS/PACS 系统，需要支持在线查看和下载。健康提醒来自随访系统，包括用药提醒、复诊提醒、检查提醒。支付操作对接支付网关，支持查询订单、退款、发票下载。

从技术实现角度看，个人中心是一个典型的 BFF（Backend for Frontend）层，需要聚合多个后端服务的数据。常见做法是，个人中心页面加载时并行调用用户服务、病历服务、报告服务、支付服务，然后将结果组装成前端需要的格式。为了提升性能，可以引入缓存，比如患者基本信息缓存 5 分钟，病历列表缓存 1 分钟。

注意：个人中心涉及大量敏感数据，需要做好权限控制。患者只能查看自己的数据，医生查看患者数据需要经过授权。建议在接口层增加患者 ID 校验，防止越权访问。

5. 避坑与排查：互联网医院平台落地时最容易翻车的五个点

5.1 状态机设计不完整导致订单卡死

现象：在线复诊订单提交后，医生接诊了但无法开方，或者开方后无法提交审核，订单一直停留在某个状态。

原因：状态机设计时遗漏了某些状态流转路径，或者状态流转的前置条件没有校验。比如医生接诊后，系统没有把订单状态从“待接诊”改为“问诊中”，导致后续操作无法进行。

解决：在开发阶段，用状态流转图把所有可能的路径画出来，确保每个状态都有明确的入口和出口。在代码中，每次状态变更都要校验当前状态是否允许该操作。建议增加状态变更日志表，记录每次变更的前后状态、操作人、时间，方便排查。

5.2 号源超卖与并发锁定失效

现象：同一个号源被多个患者预约成功，或者患者预约时显示有号，提交后提示号源已满。

原因：号源扣减没有加锁，或者锁的粒度不对。比如用SELECT查询剩余号源，然后UPDATE扣减，两个操作之间没有原子性，导致并发时超卖。

解决：用数据库的原子操作来扣减号源，比如UPDATE registration_schedule SET available_quota = available_quota - 1 WHERE id = ? AND available_quota > 0。如果影响行数为 0，说明号源已满。对于分布式场景，可以用 Redis 的DECR命令，但要注意 Redis 和数据库的数据一致性。

5.3 病历共享接口超时导致转诊失败

现象：基层医生提交转诊单时，系统提示“病历调阅失败”或“接口超时”，转诊单无法创建。

原因：病历共享接口依赖多个后端系统，比如电子病历系统、LIS、PACS，任何一个系统响应慢都会导致接口超时。另外，病历数据量大时，序列化和传输耗时也会增加。

解决：对病历共享接口做超时控制和降级处理。设置合理的超时时间，比如 3 秒，超时后返回病历摘要的缓存版本或提示“病历调阅中，请稍后重试”。对于大数据量的病历，可以分页返回，或者只返回关键字段。建议增加熔断机制，当某个后端系统故障时，自动降级，不影响转诊单创建。

5.4 视频问诊音视频质量差引发投诉

现象：患者和医生进行视频问诊时，画面卡顿、声音断续，甚至掉线，导致问诊无法正常进行。

原因：音视频方案选型不当，或者网络带宽不足。比如使用了免费的 STUN 服务器，没有 TURN 中继，导致部分网络环境下无法建立连接。另外，视频分辨率设置过高，带宽不够时就会卡顿。

解决：选择成熟的音视频云服务，确保有全球节点和 TURN 中继。视频分辨率根据网络状况动态调整，比如从 720p 自动降到 480p。在问诊前增加网络检测，提示患者切换到 Wi-Fi 或 4G/5G。建议在问诊房间中增加文字聊天作为备用通道，音视频中断时可以通过文字继续沟通。

5.5 医保结算对接失败导致患者无法支付

现象：患者在线复诊后，选择医保支付，但系统提示“医保结算失败”或“医保接口异常”，无法完成支付。

原因：医保接口对接复杂，各地医保政策不同，接口协议也有差异。常见问题包括：医保目录匹配失败、处方药品不在医保范围内、医保接口证书过期、网络策略限制。

解决：在开发阶段，先确认目标地区的医保接口规范，获取测试环境和测试账号。处方开立时，实时校验药品是否在医保目录内，不在目录内的药品提示患者自费。医保接口调用增加重试机制，失败时记录详细日志，包括请求参数、响应报文、错误码。建议在支付页面增加“自费支付”备选方案，避免医保故障导致患者无法完成支付。

6. 从文档到系统：用功能清单反推技术选型与验证方法

这份 2018 年的产品介绍文档，最大的价值不是告诉你微医用了什么技术，而是给你一张完整的互联网医院功能地图。你可以用它来反推技术选型：医生端八个模块、患者端五个模块，每个模块都需要对应的后端服务和数据存储。比如在线复诊需要状态机引擎和处方服务，远程会诊需要音视频服务和会诊单服务，双向转诊需要号源服务和病历共享服务。

我一般会这样做：先把文档中的功能模块全部列出来，然后为每个模块标注三个属性——数据实体、外部依赖、并发量级。数据实体决定数据库设计，外部依赖决定接口对接工作量，并发量级决定是否需要缓存和消息队列。以在线复诊为例，数据实体是复诊申请单、病历、处方，外部依赖是支付网关和药品配送系统，并发量级取决于医院的门诊量，通常需要支持每秒几十到几百的并发。

验证方法也很直接：用文档中的业务流程做端到端测试。比如在线复诊，从患者提交申请开始，到医生接诊、开方、审核、配送，最后患者确认收货，走完整个流程。每个环节都要检查状态是否正确流转、数据是否正确传递、通知是否及时发送。如果某个环节卡住，就回到状态机设计去排查。

还有一个技巧：用文档中的模块清单做竞品分析。把微医的功能清单和其他互联网医院产品对比，看看哪些模块是标配，哪些是特色。比如智能导诊和双向转诊是很多互联网医院的标配，但中医辨证论治和健康扶贫就是微医的特色。这个对比结果可以直接用于产品规划。

从那以后我每次拿到类似的产品介绍文档，都会先做一件事：把功能模块拆成数据实体和业务流程，然后用状态机把流程串起来。这样做的好处是，需求评审时能快速发现遗漏，开发时能直接映射到代码结构。希望帮到你。

本文还有配套的精品资源，点击获取