企业官网建设流程全解析

简介：这份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 字典序拼接，末尾追加 secret，MD5 后转大写 sorted_keys = sorted(params.keys()) raw = "&".join([f"{k}={params[k]}" for k in sorted_keys]) raw += f"&secret={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", json=params) return resp.json()["data"]["accessToken"] def query_schedule(token, dept_id, date): # 查询排班：dept_id 为科室编码，date 格式 yyyy-MM-dd headers = {"Authorization": f"Bearer {token}"} params = {"deptId": dept_id, "visitDate": date} resp = requests.get(f"{BASE_URL}/schedule/list", headers=headers, params=params) return resp.json()["data"] def create_consult(token, patient_id, doctor_id, schedule_id): # 创建问诊会话：返回 consultId，后续开方必须带上 headers = {"Authorization": f"Bearer {token}"} body = { "patientId": patient_id, "doctorId": doctor_id, "scheduleId": schedule_id, "consultType": "REVISIT" # 复诊类型，首诊不能开方 } resp = requests.post(f"{BASE_URL}/consult/create", headers=headers, json=body) return resp.json()["data"]["consultId"] def create_prescription(token, consult_id, drugs): # 开具处方：drugs 为药品列表，每项含 drugCode、quantity、usage headers = {"Authorization": f"Bearer {token}"} body = { "consultId": consult_id, "drugs": drugs, "prescriptionType": "WESTERN" # 西药处方 } resp = requests.post(f"{BASE_URL}/prescription/create", headers=headers, json=body) 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 证书。微医的回调通知只支持 HTTPS，HTTP 地址会被拒绝。

入驻完成后，开放平台会分配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后立即响应；后续的排班锁定、医生通知、监管预校验全部丢到队列里异步处理。处方开具同理，处方落库后返回prescriptionId，CA 签名、药师审核通知、监管上报异步执行。

队列选型上，RabbitMQ 和 Kafka 都行。RabbitMQ 延迟低，适合业务消息；Kafka 吞吐高，适合日志和监管数据批量上报。如果团队规模不大，建议先用 RabbitMQ，运维成本低。

异步化之后要解决一致性问题。我的习惯是给每个业务操作记录状态字段，比如处方状态从CREATED→SIGNED→AUDITED→REPORTED，每个状态变更都写流水表。这样即使队列消息丢失，也能通过定时任务扫描中间状态补偿。

验证异步链路是否可靠，可以做一个简单的压测：用脚本模拟 1000 个患者同时发起问诊，观察接口平均响应时间和队列积压量。如果响应时间超过 2 秒，说明同步逻辑还是太重；如果队列积压持续增长，说明消费端能力不足，需要扩容消费者。

最后说一个我踩过的坑：异步化之后，日志追踪变得困难。一个问诊请求可能跨越多个服务、多个队列，出问题时很难定位。后来我在请求入口生成一个traceId，所有异步消息都带上这个traceId，日志系统按traceId聚合，排查效率才提上来。这个习惯我一直保留到现在，希望帮到你。

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