简介这份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是排班 IDpatient_id是患者 IDreferral_id是转诊单 IDlock_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(keylambda x: x[confidence], reverseTrue) 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 系统需要支持在线查看和下载。健康提醒来自随访系统包括用药提醒、复诊提醒、检查提醒。支付操作对接支付网关支持查询订单、退款、发票下载。从技术实现角度看个人中心是一个典型的 BFFBackend 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 年的产品介绍文档最大的价值不是告诉你微医用了什么技术而是给你一张完整的互联网医院功能地图。你可以用它来反推技术选型医生端八个模块、患者端五个模块每个模块都需要对应的后端服务和数据存储。比如在线复诊需要状态机引擎和处方服务远程会诊需要音视频服务和会诊单服务双向转诊需要号源服务和病历共享服务。我一般会这样做先把文档中的功能模块全部列出来然后为每个模块标注三个属性——数据实体、外部依赖、并发量级。数据实体决定数据库设计外部依赖决定接口对接工作量并发量级决定是否需要缓存和消息队列。以在线复诊为例数据实体是复诊申请单、病历、处方外部依赖是支付网关和药品配送系统并发量级取决于医院的门诊量通常需要支持每秒几十到几百的并发。验证方法也很直接用文档中的业务流程做端到端测试。比如在线复诊从患者提交申请开始到医生接诊、开方、审核、配送最后患者确认收货走完整个流程。每个环节都要检查状态是否正确流转、数据是否正确传递、通知是否及时发送。如果某个环节卡住就回到状态机设计去排查。还有一个技巧用文档中的模块清单做竞品分析。把微医的功能清单和其他互联网医院产品对比看看哪些模块是标配哪些是特色。比如智能导诊和双向转诊是很多互联网医院的标配但中医辨证论治和健康扶贫就是微医的特色。这个对比结果可以直接用于产品规划。从那以后我每次拿到类似的产品介绍文档都会先做一件事把功能模块拆成数据实体和业务流程然后用状态机把流程串起来。这样做的好处是需求评审时能快速发现遗漏开发时能直接映射到代码结构。希望帮到你。本文还有配套的精品资源点击获取
简介这份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是排班 IDpatient_id是患者 IDreferral_id是转诊单 IDlock_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(keylambda x: x[confidence], reverseTrue) 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 系统需要支持在线查看和下载。健康提醒来自随访系统包括用药提醒、复诊提醒、检查提醒。支付操作对接支付网关支持查询订单、退款、发票下载。从技术实现角度看个人中心是一个典型的 BFFBackend 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 年的产品介绍文档最大的价值不是告诉你微医用了什么技术而是给你一张完整的互联网医院功能地图。你可以用它来反推技术选型医生端八个模块、患者端五个模块每个模块都需要对应的后端服务和数据存储。比如在线复诊需要状态机引擎和处方服务远程会诊需要音视频服务和会诊单服务双向转诊需要号源服务和病历共享服务。我一般会这样做先把文档中的功能模块全部列出来然后为每个模块标注三个属性——数据实体、外部依赖、并发量级。数据实体决定数据库设计外部依赖决定接口对接工作量并发量级决定是否需要缓存和消息队列。以在线复诊为例数据实体是复诊申请单、病历、处方外部依赖是支付网关和药品配送系统并发量级取决于医院的门诊量通常需要支持每秒几十到几百的并发。验证方法也很直接用文档中的业务流程做端到端测试。比如在线复诊从患者提交申请开始到医生接诊、开方、审核、配送最后患者确认收货走完整个流程。每个环节都要检查状态是否正确流转、数据是否正确传递、通知是否及时发送。如果某个环节卡住就回到状态机设计去排查。还有一个技巧用文档中的模块清单做竞品分析。把微医的功能清单和其他互联网医院产品对比看看哪些模块是标配哪些是特色。比如智能导诊和双向转诊是很多互联网医院的标配但中医辨证论治和健康扶贫就是微医的特色。这个对比结果可以直接用于产品规划。从那以后我每次拿到类似的产品介绍文档都会先做一件事把功能模块拆成数据实体和业务流程然后用状态机把流程串起来。这样做的好处是需求评审时能快速发现遗漏开发时能直接映射到代码结构。希望帮到你。本文还有配套的精品资源点击获取
