简介互联网医院源码包是一套面向在线医疗服务平台建设的完整代码资源主要服务于需要快速启动远程问诊与电子处方业务的技术团队、医疗信息化开发者或创业项目初期人员。源码围绕在线问诊、在线开处方两大核心模块展开支持患者完善病情描述、上传病历图片并通过图文、语音或视频方式与医生沟通医生完成诊断后可在系统内开具电子处方并经过审核、修改、打印等流程同时对接药品数据库与第三方支付渠道。技术层面上涉及 React/Vue.js 前端、PHP 或 Node.js 后端、MySQL/MongoDB 数据存储等常见选型源码目录中的 app、api、web、framework、addons、payment、attachment 等模块分别对应业务逻辑、对外接口、前端入口、核心框架、扩展组件、支付处理和附件存储便于按模块拆解和二次开发。压缩包以 zip 格式提供整体约 83.55MB上游暂未给出具体文件清单源码对医疗数据保护与行业合规要求也有所考量适合作为互联网医院 MVP 或区域数字化医疗平台的参考基座已有 248 人学习下载。 互联网医院源码这个话题这几年问的人一直很多。我最早接触类似项目是在一个医疗信息化的外包团队里那时候大家还在纠结“先做在线问诊还是先做预约挂号”到后来才慢慢意识到真正的硬骨头其实是诊断后的那一环——在线开处方。今天这篇不写泛泛的“互联网医院能做什么”而是直接拆解一套可落地的源码方案它包含哪些核心模块、在线问诊和在线开处方在技术上到底怎么实现、每一步设计背后的理由是什么以及我实际开发中踩过的坑。如果你正准备自研或者采购评估一套互联网医院系统尤其是想搞清楚“在线开处方”这条链路怎么做到既好用又不留隐患这篇文章可以帮你省掉不少试错成本。适合技术负责人、医疗项目产品经理还有独立接医疗项目的开发团队阅读。1. 互联网医院系统整体设计先从业务模型说起我接这类项目时第一步从来不是画技术架构图而是先把业务角色和流程画清楚。互联网医院不是简单给医院做个App它本质上是把线下“挂号—候诊—问诊—开方—取药”的流程搬到线上同时还要保证医疗行为的合规性和可追溯性。这个定位一旦搞错后面技术选型、数据结构设计全都会跑偏。1.1 核心角色与业务闭环一套完整的互联网医院系统角色不是只有“患者”和“医生”两个。我按照实际项目里的权限模型整理过至少需要这几类角色患者端用户发起问诊、上传病历资料、查看处方、在线支付。医生端用户接诊、书写病历、开具处方、查看复诊记录。药师审核员对处方进行合理用药审核可以驳回或干预问题处方。运营管理员配置科室、医生排班、药品目录、问诊价格等。系统管理员维护账号权限、操作日志、字典数据。业务闭环是这样的患者发起问诊申请系统分配或由患者指定医生医生接诊后通过图文或视频方式与患者沟通同时调用电子病历模块记录病情确认诊断后在线开处方处方先经过药师审方审核通过后患者在线支付随后药品通过物流配送或到店自取完成交付。整个链条里最容易被忽视的是药师审方环节很多早期互联网医院项目没有这个角色结果上线后被监管打回重做白白浪费成本。1.2 系统模块划分与架构选择从工程落地角度我会把系统拆成五个核心服务患者端服务负责注册登录、问诊下单、支付、处方查看、评价。医生工作台服务负责接诊列表、问诊会话、病历书写、处方开具。处方中心服务负责处方单生成、药品校验、审方流转、处方归档。基础数据服务负责科室、医生、药品目录、疾病字典等主数据管理。消息与通知服务负责短信、站内信、公众号模板消息的触达。架构选型上中小型项目启动阶段我建议用前后端分离的单体应用而非一上来就搞微服务。原因很简单微服务的拆分成本、运维成本、分布式事务复杂度都高而互联网医院患者量初期不会太大单体应用把模块边界用代码规范控制好足以支撑到几万日活。等后续要接医保、对接第三方药房、做远程会诊时再按需把处方中心独立拆出去也不迟。用单体架构但用业务模块划分目录是我目前最推荐的中小团队起步方案。2. 在线问诊功能从会话到诊疗记录在线问诊是整个系统高频使用的入口看起来只是一个聊天窗口但背后关联的数据和状态流转其实非常复杂。我认为这部分的核心不是聊天本身而是怎么保证一次问诊从发起到结束的状态是可控的、可追踪的并且所有沟通内容都能自动沉淀为诊疗记录的一部分。2.1 问诊流程的状态机设计我在设计问诊状态机时第一版只设置了“进行中”和“已完成”后来发现运营要做数据分析时根本无从下手医生也经常误操作。重新设计后的状态机分了六个状态待接诊患者已提交问诊并支付等待医生接诊。问诊中医生已接诊双方可通过图文或视频沟通。待开方医生已完成诊断正在填写病历和处方。待审方处方已提交等待药师审核。已完成审方通过患者完成支付整个诊疗流程结束。已关闭问诊超时未接诊、患者取消或医生主动关闭。每个状态之间的流转动作必须绑定权限。比如“待接诊”只能由医生端操作流转到“问诊中”患者端只能执行取消操作“待审方”只能由药师端操作。把这些规则写死在服务层而不是靠前端按钮控制否则有人绕过页面直接调接口就能导致状态错乱。状态机的另一个作用是支撑超时处理。我常设两个定时任务问诊下单超过15分钟未被接诊的自动推送提醒给医生超过30分钟仍未接诊的自动退款并关闭问诊单。这个逻辑上线后发现极大地减少了客诉值得做进第一版。2.2 会话机制与消息处理图文问诊的消息系统我推荐直接用WebSocket做长连接配合消息持久化到数据库。很多团队会直接套用第三方IM SDK比如腾讯云IM或环信这些SDK确实省事但要注意两个问题一是医疗消息的合规留痕要求第三方IM服务通常不承诺永久存储你需要自行拉取消息流水存入自己的服务器二是敏感词和图片内容过滤第三方IM的通用过滤规则不一定适合医疗场景。我自己的项目里用的是WebSocket网关服务 Redis保存会话在线状态 MySQL保存全部消息记录。WebSocket网关负责实时推送每次消息发送时先写库、推MQ再通过网关下发。为什么要先写库因为医疗诊疗过程要求完整可追溯如果先推消息再写库万一写库失败消息就丢了这是不可接受的。图片和文件则先上传到对象存储如阿里云OSS或腾讯云COS消息里只保存文件URL同时生成缩略图避免聊天列表加载原图导致流量消耗过大。同时上传接口必须做类型校验和大小限制只允许jpg、png、pdf等格式单文件不超过20MB防止有人传可执行文件造成安全隐患。2.3 诊疗数据模型在线问诊并不只是聊天接诊过程中医生随时要记录病情所以问诊单必须和一整套结构化病历数据关联。我设计的核心表是consultation问诊单它关联五类数据患者基本信息快照此时不允许实时关联用户表因为在问诊期间患者资料可能变更快照能保证诊疗记录的客观性。病情描述信息包括主诉、现病史、既往史、过敏史、家族史等。医生诊断信息包括诊断结论、ICD-10编码、处理意见。辅助检查资料患者上传的检查报告图片、检验单PDF等。生命体征数据体温、血压、心率等如果对接了硬件设备。结构化病历最大的价值在于后续的处方校验和数据分析。比如患者之前在A医生那里记录过“青霉素过敏”B医生下次开处方时系统就能自动检测到过敏史和药品的禁忌冲突直接弹窗提醒。这个功能在非结构化文本里根本做不了。3. 在线开处方最核心也最需要谨慎的模块如果说在线问诊决定了系统的体验那么在线开处方就决定了系统的底线。处方涉及用药安全、合规流转、责任追溯在技术上容不得半点马虎。这个模块也是互联网医院源码评估中外行和行家拉开差距的关键部分。3.1 药品库与处方单设计药品库是整个处方模块的地基。很多团队图省事直接内置一份普通商品药品表结果开处方时才发现单位换算、医保编码、药物属性分类全是错的。我建议药品库至少包含以下字段通用名、商品名、剂型、规格、生产企业、批准文号、医保编码、计价单位、包装单位、用法编码、用量上限、儿童禁用标志、孕产禁用标志、需要皮试标志、抗菌药物分级。各单位之间的换算也尤为重要比如一片药是0.25g医生开处方时输入“每次1片”系统内部必须能自动换算成“0.25g”用于剂量校验否则就会出现“250mg超过单次极量”的误判。处方单的主体结构我设计了四层处方头处方单号、问诊单号、患者ID快照、医生ID快照、处方状态。处方明细药品ID、药品名称、单次剂量、频次、天数、总量、用法、备注。处方签名医生电子签名值、签名时间、签名证书序列号、审方药师签名、审核时间。处方附加信息诊断ICD编码、医保类型、结算方式、开方来源图文/视频。处方单号我建议直接用日期加随机数生成比如RX20250107153012345不要用数据库自增ID做对外编号避免被遍历抓取造成患者隐私泄露。3.2 合理用药校验逻辑这部分是我认为整套源码中“含金量”最高的地方。正规的互联网医院上线前都必须接入合理用药监测系统常见的第三方有美康、大通、逸曜等。但作为源码方案你自己的系统里也必须内置一套基础的校验规则引擎否则脱离第三方接口时整个开方流程就瘫痪了。我在项目中实现的校验逻辑按优先级分为五层患者基础信息校验年龄、体重、孕产状态、过敏史。儿童用药要按体重或年龄折算剂量孕产状态与处方药禁忌直接阻断。药品单品校验单次剂量是否超过极量、日剂量是否超限、用药天数是否过长。比如某些抗生素默认不超过7天。配伍禁忌校验多张处方或同一处方内药品之间是否存在重复用药、相互作用。重复用药的判断标准是通用名相同而不是商品名很多系统在这一点上做错。诊断适配校验药品适应症是否与医生填写的诊断疾病匹配。比如诊断“感冒”时不允许开“降压药”这类逻辑用药品与ICD-10诊断编码的映射表维护。处方限额校验同一患者同一药品在一定周期内的开药总剂量控制防止医生一次性开出超大剂量药。这些校验规则不能直接写死在业务代码里必须做成可配置的规则引擎用JSON或数据库配置项管理。因为临床药学会随时提出新规则业务代码频繁发版跟不上节奏。我见过一个项目把用药规则写在Service层用if-else判断结果药学部提需求后要排两周开发才能上线极其痛苦。3.3 处方审核与签名流程处方开完不代表流程结束审方环节是互联网医院和普通在线商城的最大区别。审方模式我一般配两种系统自动审方和人工药师审方。系统自动审方处理常规处方校验通过后直接流转对于存在禁忌、超量、特殊人群用药等高风险情形自动转人工审方。电子签名这块我建议采用数字证书方式而非简单图片签名。医生在开方时必须使用实名认证过的数字证书进行签名签名值包含医生身份、处方摘要、签名时间并通过加密算法生成一个不可伪造的签名串。每次签名验签都要调用CFCA或CA机构提供的接口并在本地数据库留存签名日志。这个问题一定要重视如果后续发生医疗纠纷签名记录是判定处方责任归属的关键证据。处方状态流转也要做到全链路留痕创建→提交→自动审方→或转人工审方→审核通过→患者支付→药品配送→完成。每一步都要记录操作人、操作时间、操作内容和操作前后的状态快照便于审计追溯。4. 从零搭建的技术选型与数据模型建议这块直接进实操层面。我排除掉“随便选个框架跑起来就行”的思路从真实业务约束反推技术选型数据要做权限隔离、部分数据要做加密存储、接口要支持高并发秒级响应、所有操作要留痕。4.1 后端技术栈的建议组合后端我用的是Java Spring Boot理由很直接医疗项目在后期的医院对接、医保接口、设备集成场景里Java的技术生态最成熟招人也最容易。不愿意用Java的团队用Go也行性能和并发表现同样优秀但要注意医疗行业的SDK和中间件对Go的支持相对弱一点。前端分三端患者侧用微信小程序或支付宝小程序因为医疗服务的获客还是靠流量平台医生侧用Vue或React的Web管理后台因为医生主要在电脑上办公需要大屏和键盘操作效率运营管理后台同样用Vue或React和医生端可以复用一套组件库。数据库主库用MySQL缓存用Redis消息中间件用RocketMQ或RabbitMQ。文件存储用OSS类对象存储。搜索功能初期不建议上Elasticsearch用MySQL的LIKE模糊查询就够了等数据量真正上来再迁移不要提前引入复杂度。4.2 核心表结构设计示例我这里展示三张核心表的设计思路开发时可以直接按这个基座扩展。问诊单表的关键字段CREATE TABLE consultation ( id bigint NOT NULL AUTO_INCREMENT, consult_no varchar(32) NOT NULL COMMENT 问诊单号, patient_user_id bigint NOT NULL COMMENT 患者用户ID, patient_info_snapshot json NOT NULL COMMENT 患者信息快照, doctor_user_id bigint DEFAULT NULL COMMENT 接诊医生ID, department_id bigint NOT NULL COMMENT 科室ID, status tinyint NOT NULL COMMENT 状态1待接诊 2问诊中 3待开方 4待审方 5已完成 6已关闭, consult_type tinyint NOT NULL COMMENT 问诊类型1图文 2视频 3电话, chief_complaint text COMMENT 主诉, present_illness text COMMENT 现病史, past_history text COMMENT 既往史, allergy_history text COMMENT 过敏史, diagnosis text COMMENT 诊断结论, icd_codes varchar(255) DEFAULT NULL COMMENT ICD-10诊断编码逗号分隔, start_time datetime DEFAULT NULL COMMENT 接诊时间, end_time datetime DEFAULT NULL COMMENT 结束时间, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT问诊单表;这里最需要注意的字段是patient_info_snapshot它是JSON格式的快照。为什么不用关联查询直接拿用户表的最新数据因为医疗记录必须保留“当时的客观事实”患者几个月后修改了联系电话、体重、过敏史也绝不能影响历史问诊单的存档内容。处方单表的关键字段CREATE TABLE prescription ( id bigint NOT NULL AUTO_INCREMENT, rx_no varchar(32) NOT NULL COMMENT 处方单号, consult_no varchar(32) NOT NULL COMMENT 关联问诊单号, patient_user_id bigint NOT NULL, doctor_user_id bigint NOT NULL, pharmacist_user_id bigint DEFAULT NULL COMMENT 审方药师ID, status tinyint NOT NULL COMMENT 状态1待提交 2待审方 3审核通过 4审核驳回 5已过期, total_amount decimal(10,2) NOT NULL COMMENT 处方总金额, signature_value text COMMENT 医生电子签名值, signature_time datetime DEFAULT NULL COMMENT 签名时间, review_comment varchar(500) DEFAULT NULL COMMENT 审方意见, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT处方单表;处方明细表的关键字段CREATE TABLE prescription_item ( id bigint NOT NULL AUTO_INCREMENT, prescription_id bigint NOT NULL COMMENT 处方ID, drug_id bigint NOT NULL COMMENT 药品ID, drug_name varchar(128) NOT NULL COMMENT 药品通用名, specification varchar(128) DEFAULT NULL COMMENT 规格, manufacturer varchar(128) DEFAULT NULL COMMENT 生产企业, single_dose decimal(10,3) NOT NULL COMMENT 单次剂量, dose_unit varchar(16) NOT NULL COMMENT 剂量单位, frequency varchar(32) NOT NULL COMMENT 用药频次编码, days tinyint NOT NULL COMMENT 用药天数, total_quantity decimal(10,3) NOT NULL COMMENT 总量, usage_method varchar(128) NOT NULL COMMENT 用法口服/外用等, remark varchar(500) DEFAULT NULL COMMENT 备注, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT处方明细表;4.3 高并发与安全性设计互联网医院系统的并发量虽然不像电商双十一那么夸张但问诊开方链路有一个“短时集中”的特点——比如医院上线义诊活动短时间内有大量患者涌入这时候最容易出问题的是下单和支付环节。我在项目里重点处理了几个方面幂等性设计患者点击“提交问诊”时前端先向后端获取一个requestId后端用Redis的SETNX指令对该requestId加锁相同requestId的请求不会重复创建订单。这个方案比单纯用数据库唯一索引更早拦截也避免数据库出现无意义的死锁。分布式锁处方提交、医生接诊这类并发冲突高的操作使用Redis分布式锁锁的粒度要精确到问诊单ID比如lock:consult:100123千万不要用全局锁否则所有医生接诊都会被串行化。数据加密患者的姓名、身份证号、手机号、详细地址等敏感字段在数据库中必须加密存储。AES-256对称加密是推荐方案密钥统一由密钥管理系统管理。就算是DBA登录数据库直接查也不允许看到明文。接口鉴权内部服务之间的调用统一走JWT或者内部Token每个Token绑定调用方标识便于事后审计。对外接口全部走HTTPS并限制IP白名单和调用频率。5. 踩坑实录常见问题与排查建议真实项目上线后那些文档里不会写的问题会一个接一个冒出来。我把自己在这类项目里踩过、也帮别人排查过的典型问题整理一下给同行们做个参考。5.1 WebSocket断线重连与消息补发图文问诊的WebSocket连接在移动端非常容易断App切后台、网络切换、运营商NAT超时都会导致长连接断开。最开始我们的实现是断线后直接用客户端本地记录的时间查增量消息结果经常出现消息延迟、乱序甚至重复推送。最终解决方案是引入“消息序号”机制。每个患者的问诊会话维护一个自增的消息序号客户端断线重连时上报本地最后一条消息的序号服务端把该序号之后的所有消息批量补发。再加上服务端的心跳检测间隔缩短到30秒超时即释放连接问题基本上根治了。5.2 重复处方和超量开药上线运营一个月后有运营同事发现同一个患者可以通过选择不同医生在一天内反复问诊获取同一类处方药。虽然每张处方单独看都合规但结合起来已经达到超量购药的程度。后来我们加了“限购中心化校验”所有处方提交时统一调用一个处方频次服务服务里缓存了每个患者近30天的药品购买记录按通用名合并计算累计总量一旦超过阈值直接拦截并联动审方系统转人工处理。这个功能在监管视角非常加分也是后来药监平台对接时少返工很多的关键原因。5.3 历史处方数据迁移如果是从旧系统切换过来历史处方数据迁移也是个头疼问题。旧系统里处方可能是图片格式的也可能是非结构化的PDF这些数据没法直接映射到新的处方明细表。我的做法是分两阶段迁移先导入基础档案数据患者、问诊单、处方头处方明细如果结构化就导入明细表非结构化的则统一存为附件关联到处方单上同时标记“历史数据-非结构化”状态。这样既保证新系统业务流程不受影响又保留了历史数据的完整性。任何声称能直接把历史处方“完美还原”成结构化数据的方案都要保持警惕。5.4 多端数据一致性问题最后提醒一个容易踩的坑患者端和医生端看到的数据必须是一份。很多项目为了性能给前端直接返回了冗余字段比如问诊列表里直接返回了患者姓名、诊断名称结果一次更新后前端没刷新展示的数据还是旧的用户自然要投诉。我的经验是核心状态数据一律实时从服务端获取列表页只做分页查询详情页不缓存。凡是允许前端展示的数据都必须由后端定义视图模型前端不得自行拼接。这样做虽然增加了一点接口调用量但换来的数据一致性是值得的。6. 一些来自实操的建议说到底互联网医院源码不是一个“跑起来就行”的demo而是一套承载医疗行为的严肃系统。很多团队拿到开源代码第一件事是跑通界面我反而建议先去看处方模块的校验逻辑、审方状态机和数据留痕设计——这三个点决定了系统能不能经受住真实业务和审计的考验。如果预算有限我建议优先做好三件事问诊状态机严谨、处方校验规则可配置、全链路操作留痕完整。这三件事做好系统已经达到了“能用、敢用”的底线。至于电子签名、CA对接、医保支付这类进阶能力可以等业务跑量后再逐步加上。我在实际项目的体会是技术实现并不难难的是把医疗业务里的严谨性翻译成工程代码。尤其是处方校验多花一个月的开发时间都是值的。最后一个小技巧上线前找三五个医生真正用一用让他们自由操作不要给任何教程观察他们哪里卡住、哪里不满、哪里会绕开系统。从他们的操作轨迹里发现的优化点比读十遍需求文档都管用。本文还有配套的精品资源点击获取