简介这份PPT资料系统梳理了微医互联网医院平台的产品设计面向互联网医疗产品经理、医疗信息化从业者及医院管理者帮助理解在线复诊、远程会诊等业务的完整功能架构。资源为1个pptx文件压缩包约25MB以图文并茂的幻灯片形式呈现平台整体方案。内容分为三大部分平台架构设计、医生端与用户端功能模块。医生端涵盖在线复诊、远程门诊、远程会诊、双向转诊、检查检验、远程培训、视频会议及面诊处方八大场景用户端则包括患者主页、在线复诊、预约挂号、智能导诊与个人中心。每项功能均配有页面截图与流程说明便于读者快速掌握产品交互逻辑与业务闭环。目前已有317人学习下载适合用于竞品分析、产品方案参考或医疗信息化项目立项调研也可作为互联网医院功能设计的对照模板。1. 微医互联网医院平台从挂号到复诊一套系统怎么串起来很多同行第一次接触微医互联网医院平台都是被一个具体需求推着走的手里有实体医院资源想把复诊、慢病续方搬到线上但不知道这套系统到底包含哪些模块、接口怎么对接、监管要求怎么落地。微医互联网医院平台不是单一 App它是一套覆盖患者端、医生端、药师端、监管端的完整技术体系核心解决的是「线上问诊—电子处方—药品配送—医保结算—监管上报」这条链路的闭环问题。适合谁看医院信息科工程师、互联网医院产品经理、想接入微医生态的第三方服务商以及需要自建类似平台的架构师。这篇文章不讲虚的按「平台由什么组成 → 怎么对接 → 参数怎么配 → 坑在哪」的顺序拆开讲读完你能判断自己的业务该接哪些模块、对接成本大概多少、哪些环节最容易翻车。2. 微医互联网医院平台的模块拆解与接口选型2.1 患者端、医生端、监管端各自负责什么微医互联网医院平台在架构上通常分四层接入层、业务层、数据层、监管层。患者端负责实名认证、在线问诊、处方查看、药品下单、医保支付医生端负责排班、接诊、开方、随访药师端负责处方审核监管层负责对接省级互联网医疗服务监管平台上报问诊记录、处方数据、医师信息。实际落地时最容易被低估的是监管层。很多团队以为把问诊流程跑通就完事了结果上线前发现监管上报接口对字段格式、上报时效、数据加密都有硬性要求。常见做法是先把监管上报的字段清单拉出来反向约束业务层的数据库设计而不是等业务跑通了再补。从选型角度看如果你只是想在现有 HIS 系统上加一个互联网医院入口建议优先复用微医提供的标准化 API而不是自建全套。自建的成本主要在电子处方合规、CA 签名、监管对接这三块每一块都有资质门槛。2.2 核心接口清单与调用顺序对接微医互联网医院平台核心接口大致分五组用户认证、排班查询、问诊会话、处方开具、订单支付。调用顺序不能乱因为处方接口依赖问诊会话 ID支付接口依赖处方 ID。下面是一个典型的接口调用链路示例用 Python 演示如何按顺序完成一次线上复诊import requests import hashlib import time # 配置参数app_id 和 secret 由微医开放平台分配 APP_ID your_app_id APP_SECRET your_app_secret BASE_URL https://api.example.com/ihospital # 以实际分配域名为准 def gen_sign(params): # 签名规则按 key 字典序拼接末尾追加 secretMD5 后转大写 sorted_keys sorted(params.keys()) raw .join([f{k}{params[k]} for k in sorted_keys]) raw fsecret{APP_SECRET} return hashlib.md5(raw.encode()).hexdigest().upper() def get_token(): # 获取 access_token有效期通常 7200 秒需缓存 params { appId: APP_ID, timestamp: int(time.time()), nonce: abc123 } params[sign] gen_sign(params) resp requests.post(f{BASE_URL}/auth/token, jsonparams) return resp.json()[data][accessToken] def query_schedule(token, dept_id, date): # 查询排班dept_id 为科室编码date 格式 yyyy-MM-dd headers {Authorization: fBearer {token}} params {deptId: dept_id, visitDate: date} resp requests.get(f{BASE_URL}/schedule/list, headersheaders, paramsparams) return resp.json()[data] def create_consult(token, patient_id, doctor_id, schedule_id): # 创建问诊会话返回 consultId后续开方必须带上 headers {Authorization: fBearer {token}} body { patientId: patient_id, doctorId: doctor_id, scheduleId: schedule_id, consultType: REVISIT # 复诊类型首诊不能开方 } resp requests.post(f{BASE_URL}/consult/create, headersheaders, jsonbody) return resp.json()[data][consultId] def create_prescription(token, consult_id, drugs): # 开具处方drugs 为药品列表每项含 drugCode、quantity、usage headers {Authorization: fBearer {token}} body { consultId: consult_id, drugs: drugs, prescriptionType: WESTERN # 西药处方 } resp requests.post(f{BASE_URL}/prescription/create, headersheaders, jsonbody) return resp.json()[data][prescriptionId]这段代码的关键点有三个。第一签名规则必须严格按字典序拼接任何一个参数顺序错了都会返回签名错误。第二access_token要缓存不要每次调用都重新获取否则会触发频率限制。第三consultType必须传REVISIT首诊类型在互联网医院场景下不允许开处方这是监管硬性要求。参数说明appId和secret由微医开放平台分配不要硬编码在客户端nonce是随机字符串每次请求不同timestamp是秒级时间戳与服务器时间偏差不能超过 5 分钟否则签名失效。2.3 电子处方与 CA 签名的对接要点电子处方是互联网医院平台最核心也最容易出问题的模块。微医互联网医院平台的处方流程通常是医生开方 → 药师审核 → CA 签名 → 处方生效 → 推送至药房或配送方。CA 签名环节需要接入第三方 CA 机构医生需要在 CA 机构完成实名认证并领取数字证书。常见做法是医生首次开方前完成证书申领后续每次开方调用 CA 接口对处方内容做签名。签名失败的原因通常是证书过期或医生信息与 CA 备案不一致。处方审核环节要注意药师审核不通过时处方状态会变为REJECTED此时不能直接修改原处方必须作废后重新开具。很多团队在这里踩坑试图用更新接口修改已驳回的处方结果监管上报数据出现两条记录导致对账异常。3. 从零对接微医互联网医院平台的实操步骤3.1 环境准备与开放平台入驻对接前需要准备的东西企业营业执照、医疗机构执业许可证、互联网医院牌照或依托实体医院的牌照、CA 机构合作证明。这些资质在微医开放平台入驻时都要上传审核审核周期通常 5 到 10 个工作日。技术侧需要准备一台能访问外网的服务器用于接收回调、一个已备案的域名用于配置回调地址、HTTPS 证书。微医的回调通知只支持 HTTPSHTTP 地址会被拒绝。入驻完成后开放平台会分配appId、secret、沙箱环境地址、生产环境地址。建议先在沙箱环境把全流程跑通沙箱环境的医生和患者数据都是模拟的处方不具备法律效力但接口行为和生产一致。3.2 问诊会话的创建与状态流转问诊会话的状态机是WAITING待接诊→IN_PROGRESS问诊中→FINISHED已结束→CLOSED已关闭。医生接诊后状态变为IN_PROGRESS此时才能开方。如果患者 24 小时未回复系统会自动将状态置为CLOSED。创建问诊会话时要注意同一个患者对同一个医生在 24 小时内不能重复创建会话。如果患者需要再次问诊必须等上一个会话关闭。这个限制是为了防止刷单和监管数据重复。回调通知的处理逻辑from flask import Flask, request, jsonify app Flask(__name__) app.route(/callback/consult, methods[POST]) def consult_callback(): # 微医回调通知包含事件类型和业务数据 data request.json event_type data.get(eventType) consult_id data.get(consultId) if event_type CONSULT_FINISHED: # 问诊结束触发随访任务 create_followup_task(consult_id) elif event_type PRESCRIPTION_AUDITED: # 处方审核完成通知患者支付 notify_patient_to_pay(data.get(prescriptionId)) # 必须返回 success否则微医会重试推送 return jsonify({result: success}) def create_followup_task(consult_id): # 随访任务创建逻辑写入本地任务队列 pass def notify_patient_to_pay(prescription_id): # 通知患者支付调用消息推送服务 pass回调接口有两个硬性要求一是必须在 5 秒内返回success否则微医会按 1 分钟、5 分钟、30 分钟的间隔重试推送二是回调接口必须做幂等处理同一条通知可能推送多次重复处理会导致业务数据异常。3.3 药品目录与配送对接微医互联网医院平台的药品目录通常分两部分平台标准目录和医院自定义目录。标准目录由微医维护包含常用药和慢病用药自定义目录由医院上传需要提供药品批准文号、生产企业、规格等信息。配送对接有两种模式一是对接微医合作的配送方医院只需把处方推送到微医指定的配送接口二是医院自有药房配送需要自行对接物流系统并回传物流单号。第一种模式对接成本低但配送范围受微医合作方覆盖限制第二种模式灵活但工作量大。药品目录同步接口的调用频率建议控制在每天一次全量同步增量变更实时推送。全量同步数据量大建议分页拉取每页 500 条避免超时。4. 微医互联网医院平台对接的避坑与排查4.1 签名报错但参数看起来没问题现象接口返回SIGN_ERROR但对照文档检查参数名和值都没错。原因签名计算时包含了空值参数或者参数值做了 URL 编码后再参与签名。微医的签名规则要求空值参数不参与签名且参数值必须用原始值参与签名不能先编码。解决在签名函数里过滤掉值为None或空字符串的参数签名完成后再对请求参数做 URL 编码。另外注意时间戳单位是秒不是毫秒偏差超过 5 分钟也会报签名错误。4.2 处方开具成功但监管上报失败现象处方接口返回成功但监管平台查不到数据或者监管接口返回字段校验失败。原因监管上报是异步的处方开具成功不代表上报成功。常见原因是医师执业证书编号格式不对、患者证件类型代码不符合监管标准、药品缺少医保编码。解决在处方开具前先调用监管预校验接口把医师信息、患者信息、药品信息提前校验一遍。预校验通过后再开方能大幅降低上报失败率。如果已经失败根据监管返回的错误码逐字段修正不要盲目重试。4.3 回调通知重复处理导致订单重复现象患者支付后生成了两笔订单或者随访任务重复创建。原因微医回调通知在未收到success响应时会重试如果本地处理逻辑耗时超过 5 秒微医会认为超时并重试导致同一条通知被处理多次。解决回调接口收到通知后先落库用consultId eventType做唯一索引落库成功立即返回success业务逻辑异步处理。这样即使重复推送唯一索引也会拦截重复数据。4.4 沙箱环境正常生产环境报权限错误现象沙箱环境所有接口都能调通切到生产环境后返回PERMISSION_DENIED。原因生产环境的接口权限需要单独申请沙箱环境的权限是默认全开的。另外生产环境的appId和沙箱不同切换时容易漏改配置。解决上线前对照开放平台的权限清单逐项确认生产环境已开通。常见需要单独申请的有处方开具权限、医保结算权限、药品配送权限。配置切换时用环境变量区分不要硬编码。4.5 问诊会话超时后无法重新创建现象患者问诊结束后想再次问诊接口返回CONSULT_EXISTS。原因上一个会话虽然状态是FINISHED但没有触发关闭逻辑系统认为还有活跃会话。解决问诊结束后主动调用关闭接口或者等待系统自动关闭通常 24 小时。如果业务上需要立即重新问诊先查询当前活跃会话如果有则复用没有则创建。不要试图绕过限制重复创建监管数据会出现异常。5. 微医互联网医院平台的进阶用法用异步队列扛住问诊高峰问诊高峰期的并发压力主要来自三个方面患者集中发起问诊、医生集中开方、监管集中上报。同步处理这三个环节接口超时是迟早的事。我一般会引入消息队列做削峰填谷把非实时逻辑全部异步化。具体做法问诊创建接口只做参数校验和落库返回consultId后立即响应后续的排班锁定、医生通知、监管预校验全部丢到队列里异步处理。处方开具同理处方落库后返回prescriptionIdCA 签名、药师审核通知、监管上报异步执行。队列选型上RabbitMQ 和 Kafka 都行。RabbitMQ 延迟低适合业务消息Kafka 吞吐高适合日志和监管数据批量上报。如果团队规模不大建议先用 RabbitMQ运维成本低。异步化之后要解决一致性问题。我的习惯是给每个业务操作记录状态字段比如处方状态从CREATED→SIGNED→AUDITED→REPORTED每个状态变更都写流水表。这样即使队列消息丢失也能通过定时任务扫描中间状态补偿。验证异步链路是否可靠可以做一个简单的压测用脚本模拟 1000 个患者同时发起问诊观察接口平均响应时间和队列积压量。如果响应时间超过 2 秒说明同步逻辑还是太重如果队列积压持续增长说明消费端能力不足需要扩容消费者。最后说一个我踩过的坑异步化之后日志追踪变得困难。一个问诊请求可能跨越多个服务、多个队列出问题时很难定位。后来我在请求入口生成一个traceId所有异步消息都带上这个traceId日志系统按traceId聚合排查效率才提上来。这个习惯我一直保留到现在希望帮到你。本文还有配套的精品资源点击获取