简介这是一套面向医疗信息化领域的互联网医院源码专门服务于需要搭建在线诊疗平台的技术团队与创业者核心覆盖在线问诊和在线开处方两大业务闭环。源码在架构上采用前后端分离思路前端可基于React或Vue构建交互界面后端提供PHP/Node.js接口服务并结合MySQL/MongoDB完成数据持久化整体设计兼顾了实时通讯、电子处方流转、支付对接与附件存储等关键环节并预留了良好的扩展空间。资源包以zip格式封装整体约83.55MB内部结构涵盖composer.json、app、api、web、framework、addons、payment、attachment等典型模块便于按功能区块学习二次开发。同时源码对医疗数据安全与合规有所考量可帮助开发者快速理解电子病历保存、用户隐私保护及药品数据对接等落地要点。目前已有248人浏览学习适合具备中高级Web开发经验、希望深入医疗SaaS业务的技术人员参考与复用也可作为医疗信息化项目的教学与起步模板。 这些年医疗信息化项目确实火尤其是互联网医院这一块几乎每一家二级以上医院都在提建设需求。很多人拿到“互联网医院源码”第一反应就是这不就是做一个App加上视频问诊功能吗等真正动手做才发现在线问诊和在线开处方这两个模块牵扯到的业务流程、权限控制、合规要求远比表面上看到的要复杂。这篇文章我就从源码实现的角度把整套系统的设计思路、核心模块的落地细节、以及我在实际项目中踩过的一些坑好好拆开来讲一讲。如果你正打算接手或者建设类似系统可以拿来当作一份实战参考。1. 项目背景与整体方案设计1.1 互联网医院的业务闭环是什么先说清楚一件事互联网医院不是简单把线下门诊搬到线上它实际上是一个完整的业务闭环。病人线上挂号、医生图文/视频接诊、开具电子处方、处方流转到药房、药品配送到家这中间的每一个环节都必须有对应的系统模块支撑而且环环相扣。在源码层面除去常见的预约挂号、在线支付、报告查询等功能最核心、也最难做的两件事就是在线问诊和在线开处方。问诊解决的是医患双方高效沟通的问题处方解决的是诊疗行为合法合规落地的问题。这两个功能一旦做扎实了整套系统的基本盘就稳了。1.2 为什么选微服务架构来拆业务中心我在设计这套源码的时候没有采用传统的单体应用方案而是选择了微服务架构因为互联网医院的业务边界其实是非常清晰的。按领域划分我拆出了这几个核心服务问诊服务处理图文咨询、视频问诊、问诊会话状态流转处方服务电子处方生成、审方、签名、流转用户服务患者端、医生端、药师端、管理员端的统一身份认证支付与订单服务问诊费用、药品费用的结算消息服务IM聊天、通知推送、视频通话信令微服务拆分的核心逻辑是为了让团队可以并行开发同时也能让各个核心模块独立扩展。比如在线问诊在高峰期并发高我可以单独扩容问诊服务处方服务跟药房对接时出现接口抖动也不会拖垮问诊链路。这里有一个关键经验拆服务要适度不要为了微服务而微服务。有些团队把合理用药审核做成了一个独立服务结果团队只有五六个人联调成本直线上升。我更建议将合理用药审核嵌入到处方服务内部用独立的模块去实现而不是单独部署一个微服务实例。2. 在线问诊模块的核心设计与实现2.1 问诊流程的状态机设计在线问诊最容易出问题的就是状态管理。一个问诊订单可能会经历待接诊、问诊中、待开方、已完成、已取消、退款中、已退款这些状态之间的流转是有严格规则的。我建议在源码中用状态机模式来做这一块不要散落着各种if-else判断。关键状态转移如下当前状态触发动作下一个状态约束条件待接诊医生接诊问诊中订单未超时医生未达到接诊上限问诊中图文/视频沟通问诊中会话未关闭问诊中患者确认结束待评价医生未开方或已开方但患者已收到处方问诊中医生开具处方待支付处方审核通过患者待支付药费待支付支付完成已完成药房已接收处方待接诊超时未接诊已取消系统自动取消并退款实际编码时状态机不一定要引入重框架自己维护一张状态转移表也能做但必须保证每个转移都有前置校验。我遇到很多团队的问诊状态卡死就是因为漏掉了“医生正在视频通话中却被患者取消订单”这种边界场景。所以在问诊服务的代码中取消订单前必须要校验当前是否处于音视频通话中如果是要先释放音视频房间资源再变更订单状态。2.2 视频问诊与IM消息的技术选型在线问诊有两种主流形式图文问诊和视频问诊。图文问诊的核心是一个IM系统好消息和坏消息都会发给双方但它和普通聊天软件又不一样这里多了一个“诊疗”的严肃性。我在源码中用的是WebSocket长连接来承载IM消息配合一个消息推送服务做离线消息补偿。文本消息、图片消息、医嘱卡片都是通过消息类型字段区分的。这里提示一个关键点图片消息必须做敏感信息过滤不能只依赖前端限制图片上传接口在后端也要做二次校验因为有时患者会不小心上传包含个人身份信息的图片必须支持医生端一键撤回。视频问诊我选了WebRTC的方案配合SFU类型的流媒体服务器做多人房间管理。之所以不用Mesh架构是因为医生端和患者端的网络环境经常不对等Mesh模式下上行带宽压力太大视频会卡顿。房间的创建和销毁逻辑要跟订单状态绑定。创建房间时把订单ID传入流媒体服务器断线重连时根据订单ID重新加房而不是重新创建一个房间。这个细节如果不注意会出现“医生重进房间却看不到患者”的尴尬局面。2.3 医生排班与号源控制在线问诊的医生端和线下门诊有一个很大的不同医生不是随时都在线的。这套源码里我设计了排班模块医生需要提前设置可接诊时间段系统根据时间段生成号源。号源控制我用的是Redis分布式锁加数据库唯一索引的双重策略。以医生ID加时间段作为维度同一时间点只允许一个问诊订单占用一个号源。这里有一个教训只靠Redis锁是存在隐患的当锁意外过期后两个请求同时通过校验就会超卖。所以数据库表中必须有一个唯一索引组合doctor_id, time_slot, status当状态为“已占用”时插入新订单直接报错靠数据库兜底。同时还要控制医生的并发接诊数。一个医生同一时刻最多接诊几单这个不是技术问题是业务规则。我做过的一般是三到五个取决于医院的管理政策。这个并发数需要做成可配置项方便管理员后台调整。3. 在线开处方模块的合规化实现3.1 处方流转的完整链路在线开处方是整个系统合规要求最高的部分也是真正体现互联网医疗价值的地方。处方不是医生在界面上写几个药、填个用量那么简单它背后是一条完整的数据链路医生开方、合理用药审核、药师审方、电子签名、处方上传监管平台、处方流转到药房。我在源码中把处方服务设计成了七个核心步骤医生BEAN选择药品填写用法用量前端组装处方草稿提交到处方服务处方服务调用合理用药审核模块检查配伍禁忌、重复用药、剂量上限系统将审核通过的处方推送给药师进行人工审方非必须视医院要求医生端确认处方内容使用电子签名完成签署处方数据加密后上传到区域卫生信息平台监管处方流转至指定药房药房完成调配并发货这个流程中最容易被忽略的是第五步电子签名。签名不能只是图片贴上去必须调用合规的CA签名服务要有时间戳要能追溯整个签署过程。很多医院过等级保护评审时被卡住的就是签名这块。3.2 合理用药审核与处方签名合理用药审核模块是源码中的一个亮点也是我建议你重点研究的地方。它的逻辑本质上是规则引擎把药品字典、相互作用库、禁忌症库加载到内存中然后对处方明细进行匹配。判断逻辑常见的有这么几类同种药品重复开方单次剂量超过最大限制配伍禁忌妊娠期/哺乳期妇女禁用药品抗菌药物越级使用检查这里有一个数据上的坑这些药品规则库是需要持续更新的而且不同医院采购的药品目录不一样。所以源码中不能将这规则库写死必须支持在管理后台手工维护同时保留从第三方医药数据库导入的功能。处方签名则推荐采用异步方式。医生确认处方后签名请求先打入消息队列前端提示“签署中”签名完成通过消息推送通知医生。这里不要设计成同步等待因为CA签名的响应时间往往不稳定最慢可能超过十秒同步等待会严重影响医生操作体验。3.3 电子处方对接HIS与药房的关键点互联网医院的处方最终是要回到线下履约的所以与HIS医院信息系统和药房系统的对接是绕不开的。对接HIS时有一个必须处理好的问题患者主索引映射。同一个患者可能在互联网医院注册过一个账号在线下医院又是另外一个ID两个系统间需要靠身份证号或手机号进行匹配。如果匹配不上处方发送到线下HIS时就会出错药就没法发。对接药房时我建议优先使用处方二维码方案。药房扫码后自动关联到处方详情减少手工录入错误。同时要设计好药房库存扣减的时机是在医生开方时就锁定库存还是在患者支付后再锁定我的经验是后者更合理因为避免部分患者支付前取消导致库存锁死。但这样一来支付高峰期的库存扣减性能压力会比较大需要数据库事务和缓存配合好防止超卖。4. 核心业务流程串讲与实战4.1 从患者挂号到处方完成的完整时序为了方便你理解这套源码我模拟一段完整流程从患者端发起到最后药房接单用文字走一遍。患者打开小程序选择在线问诊找到科室和医生提交病情描述并支付问诊费用。此时问诊服务创建订单状态为待接诊。医生端收到新订单提醒点击接诊状态变为问诊中。图文会话窗口打开双方可以自由沟通。医生觉得信息足够打开开方界面选择药品、填写用法用量提交后处方服务做合理用药审核。审核通过医生做电子签名处方状态变为已签署。系统自动将处方推送至患者端患者确认无误后支付药品费用。支付完成后处方推送至药房药房拣货打包对接物流公司配送上门。这条链路表面上看起来线性实际上涉及问诊服务、处方服务、支付服务、药房系统四个模块的协同每一次状态变更都会产生事件消息。前期我建议把关键操作日志全部打出来方便测试时定位问题。4.2 关键数据表设计思路源码中问诊和处方相关的表设计是核心这里给出几张关键表的字段思路问诊订单表主要字段订单号、患者ID、医生ID、问诊类型、状态、创建时间、接诊时间、关闭时间、支付金额。注意订单号不能使用自增ID要使用雪花算法生成因为多服务之间需要全局唯一订单号。处方主表主要字段处方号、问诊订单号、患者ID、医生ID、药师ID、处方状态、合理用药审核结果、签名时间戳、签名值。处方明细表则是主表的一对多扩展记录药品编码、药品名称、规格、数量、用法、用量、频次。处方状态字段建议不要只用一个状态值可以拆成两个字段审方状态和发药状态。因为一个处方既可能审核通过但患者不支付也可能支付完成但药房缺货单一状态无法表达这种组合情况。4.3 源码落地时容易踩的坑第一个坑是时区问题。互联网医院面向的患者分布在全国各地医生和患者的服务器可能不在同一地域。处方签名时间戳必须统一使用北京时间的服务器时间不能直接取客户端本地时间否则会出现签名时间与服务器时间不一致影响后续审计。我处理的办法是在网关层统一注入请求时间所有业务服务读取网关时间作为当前时间。第二个坑是IM消息的时序问题。患者发一条消息医生回一条消息进WebSocket之后如果落到数据库的顺序跟发送顺序不一致会导致聊天记录错乱。源码中我引入了消息序号机制每条消息在客户端生成单调递增的序号服务端按序号排序后再落库。第三个坑是断网重连后的会话恢复。我遇到过多次患者视频问诊中断网等重新连上后问诊会话已经被系统自动关闭了。所以自动关闭问诊的定时任务需要增加一个前置条件当前没有活跃中的音视频通话。否则业务方会不断收到“问诊异常结束”的投诉。5. 常见问题与排查技巧5.1 问诊超时与会话丢失很多系统会设置问诊超时时间比如医生超过五分钟未接诊订单自动取消。这个机制本身没问题但定时任务的执行频率和订单量大时会出现延迟。我建议用延迟队列来实现而不是每分钟跑一次数据库扫描。订单创建时同时发送一条延迟消息五分钟后投递收到消息后再校验订单状态这样既准实时又不会给数据库带来太大压力。会话丢失的原因通常是WebSocket连接断开后没有正确处理心跳重连。前端需要实现断线检测连续几次心跳没响应就主动重连重连成功后拉取离线消息补偿。5.2 处方签名失败签名失败是开方模块常见问题原因往往不是CA服务本身挂了而是前置参数校验没通过。比如医生没有在有效执业期内、患者的电子健康卡号为空、处方明细中的药品编码在CA侧没有备案。排查时优先看网关的访问日志看请求是否到达CA服务然后再看CA服务返回的具体错误码。签名失败的现场一定要保留完整的请求报文方便CA厂商那边定位。5.3 高并发抢号场景的处理在线问诊也会有抢号场景比如某个知名专家放号五十个几千人同时抢。为了避免数据库压力过大我用了两级限流第一级用Redis做预扣减第二级用数据库悲观锁兜底。同时Nginx层会按IP做简单限流防止单一用户疯狂重试。这里补充一个实际操作心得测试高并发时不要在测试环境用真数据压测完要把所有测试产生的问诊订单清理干净不然会影响后续药房的真实对账。我一般会单独建一套压测库专门用于并发测试。5.4 常见问题速查表问题现象可能原因排查方向解决建议问诊订单一直待接诊延迟队列消息丢失查看消息中间件投递日志增加定时任务扫描做最终兜底视频画面卡顿上行带宽不足或SFU节点负载高查看流媒体服务器CPU和带宽监控按地域就近分配SFU节点上次聊天记录丢失断网重连后未做消息补偿检查IM消息拉取接口增加会话内消息游标拉取处方审核不通过但医生无感知前端未展示具体拦截原因查看合理用药规则命中记录把规则命中的详细项显示在处方页药房没收到处方处方推送接口重试机制缺失检查消息队列消费异常日志为跨系统接口增加重试和人工补发工具患者支付成功但药品未发货支付回调与处方状态更新非原子操作查看订单服务事务日志引入对账任务定时排查处方状态和支付状态不一致记录最后再说一个我个人的习惯源码交付之后不要急着开始新项目花点时间把核心流程画成业务时序图贴到团队文档里。尤其是问诊和处方这条链路每次改动需求先看时序图再动手返工率能降低很多。互联网医院这类系统业务复杂度高于技术复杂度把状态流转和合规链路吃透了源码改起来会顺手很多。本文还有配套的精品资源点击获取