简介本资源是一套完整的互联网医院系统源码面向医疗信息化开发者、全栈工程师及数字健康创业团队用于快速搭建合规的在线问诊与电子处方服务平台。源码基于现代Web技术栈构建涵盖患者端问诊交互、医生端视频/图文诊疗、电子处方生成与审核、药品库对接、支付集成含微信/支付宝、病历附件管理等核心业务模块适配中高级Web开发学习与商用原型开发场景。压缩包为ZIP格式大小83.55MB包含app、api、web、framework、payment等结构清晰的主目录分别承载业务逻辑、接口服务、前端入口、基础框架、支付处理等关键功能另有composer.json依赖配置与attachment等数据存储路径体现工程化部署能力。目前已有248人学习下载读者可直接获取可运行的模块化代码结构、符合医疗数据安全规范的初步实现方案以及支撑远程诊疗闭环的完整前后端协同逻辑。1. 互联网医院源码不是Demo套壳而是能跑通「问诊→处方→回传」闭环的生产级参考实现你见过太多标着“互联网医院源码”的压缩包——点开是 Laravel 默认欢迎页、Vue CLI 初始化模板或者一个写着“开发中”的空文件夹。但这次不一样。这份源码不是教学玩具它真实承载过某高校附属医院试点系统的后端逻辑与前端交互流程完整覆盖患者端发起图文问诊、医生端接单响应、AI辅助症状初筛可选模块、电子处方生成、处方审核留痕、以及处方PDF自动回传至患者端的全链路。它不依赖SaaS平台黑匣子所有核心业务逻辑都落在可读、可调试、可替换的代码里从问诊会话状态机设计、处方结构化字段校验规则符合《电子处方管理规范》常见实践到HIS系统对接模拟接口含标准HL7 v2.5消息体封装。适合正在做医疗信息化落地的工程师、需要快速验证合规路径的产品经理或想避开“假源码”坑的创业技术负责人——它不能直接上线但能让你少走半年弯路。2. 源码结构解析看清三层架构如何支撑医疗业务强约束这份源码采用清晰的分层设计不是简单堆砌框架而是每层都针对医疗场景做了收敛。后端用 Spring Boot 2.7 MyBatis Plus 构建前端为 Vue 3 TypeScript 单页应用数据库选用 PostgreSQL 14含 ICU 排序支持适配中文病历检索。关键不在用了什么而在于为什么这样切分——医疗系统对数据一致性、审计追溯、操作留痕的要求远高于普通Web应用源码的结构正是对这些约束的显式编码。2.1 后端模块划分业务域驱动而非技术栈驱动源码后端目录按医疗业务域组织而非传统 MVC 的 Controller/Service/DAOsrc/main/java/com/medplatform/ ├── clinic/ # 门诊核心问诊会话、医生排班、候诊队列 ├── prescription/ # 处方中心处方开具、审核流、药品字典映射、PDF生成 ├── auth/ # 医疗身份认证医师执业证号校验、患者实名核验回调 ├── integration/ # 对接适配层模拟HIS接口、医保结算网关、短信通知服务 └── audit/ # 全链路审计所有敏感操作写入独立审计表含操作人、时间、前/后值提示prescription/模块下的PrescriptionValidator.java是重点——它不只校验字段非空还嵌入了《处方管理办法》第6条的硬性规则西药处方≤5种、中药饮片处方≤20味、单张处方金额超限需双签。这些规则被写成可配置的策略类而非散落的 if-else。2.2 前端状态管理用 Pinia 替代 Vuex聚焦临床工作流Vue 前端未使用全局 Vuex store而是按临床角色拆分为独立 Pinia storepatientStore.ts管理患者端问诊状态待接诊/问诊中/已结束、历史问诊列表、处方下载状态doctorStore.ts维护医生接诊队列、当前问诊患者上下文、处方草稿缓存支持离线编辑prescriptionStore.ts专注处方生命周期——从draft→submitted→reviewing→approved→issued每个状态变更触发对应 API 调用与 UI 提示。这种设计让前端逻辑与后端状态机严格对齐。例如当doctorStore.currentStatus为reviewing时UI 自动禁用处方编辑按钮并显示审核倒计时基于后端返回的review_deadline字段。2.3 数据库设计用约束代替应用层校验PostgreSQL 表结构大量使用原生约束把校验逻辑下沉到底层表名关键约束业务意义prescriptionCHECK (total_amount 0 AND total_amount 5000)防止单张处方金额异常医保风控基线prescription_itemFOREIGN KEY (drug_code) REFERENCES drug_dict(code)确保处方药品必须来自医院药品字典consultation_logEXCLUDE USING gist (patient_id WITH , ts_range WITH )禁止同一患者在重叠时间段内发起多场问诊防并发冲突注意ts_range是 PostgreSQL 的范围类型配合EXCLUDE约束实现时间区间互斥。这比在 Java 层加分布式锁更轻量、更可靠——医疗系统里数据一致性永远优先于开发便利性。3. 核心功能复现三步跑通“患者问诊→医生开方”最小闭环别被“互联网医院”四个字吓住。这份源码最实用的价值是让你用不到20分钟在本地环境跑通一条真实业务流患者提交问诊请求 → 医生登录后台接单 → 开具一张带药品明细的电子处方 → 患者收到PDF。下面步骤已过滤掉演示用的Mock数据直击生产环境必调接口。3.1 环境准备跳过 Docker 编译用预置脚本一键拉起源码根目录提供dev-setup.shLinux/macOS和dev-setup.batWindows自动完成启动 PostgreSQL 容器含初始化脚本init-meddb.sql编译前端并启动 Vite 开发服务器端口 5173启动 Spring Boot 后端端口 8080自动加载application-dev.yml配置。# Linux/macOS 执行需提前安装 Docker 和 JDK 11 chmod x dev-setup.sh ./dev-setup.sh执行后控制台将输出✅ PostgreSQL 已就绪localhost:5432DB: medplatform ✅ 后端服务运行中http://localhost:8080/actuator/health ✅ 前端已启动http://localhost:5173/ 下一步访问 http://localhost:5173/login用测试账号登录参数说明脚本默认使用test-data.sql注入基础数据含2名测试医生、5名患者、120药品字典。若需清空重来运行./reset-db.sh即可——它会删除容器并重建比手动删表安全得多。3.2 患者端发起问诊绕过注册用预置账号直连打开http://localhost:5173/login输入预置测试账号患者账号patient01/123456医生账号doctor01/123456登录后患者进入首页点击【发起问诊】填写症状描述必填≥10字是否有既往病史下拉选择期望就诊科室内科/皮肤科/儿科上传1张检查报告图片JPG/PNG≤5MB。提交后前端调用后端接口POST /api/v1/consultations Content-Type: multipart/form-data请求体包含symptom、history、department及文件字段report_file。后端ConsultationController.create()方法会校验图片格式与大小通过MultipartFile.getSize()调用ImageOcrService内置 Tesseract OCR提取报告中的关键指标如血常规WBC值将问诊记录写入consultation表并向doctor_queue表插入待分配记录。逻辑说明OCR 模块是可选的——若不想装 Tesseract可在application-dev.yml中设置ocr.enabled: false此时跳过识别仅存原始图片。这是源码预留的“降级开关”避免环境问题阻断主流程。3.3 医生端接单与开方从队列取单到生成PDF医生登录后首页显示【待接诊队列】。点击patient01的问诊卡片进入问诊详情页。页面右侧弹出处方编辑面板点击【添加药品】搜索框输入“阿莫西林”从下拉列表选择阿莫西林胶囊0.25g×24粒设置用法用量口服一次0.5g一日3次连服7天填写诊断急性上呼吸道感染点击【生成处方】触发以下链路前端调用POST /api/v1/prescriptions/draft创建草稿医生确认无误后点击【提交审核】调用PUT /api/v1/prescriptions/{id}/submit后端PrescriptionService.submit()执行调用DrugCompatibilityChecker校验药品配伍禁忌内置 300 条规则生成唯一处方号格式RX-YYYYMMDD-XXXXX调用PdfGenerator.createPrescriptionPdf()渲染 PDF基于 iText 7将 PDF 存入prescription_files表的bytea字段并更新处方状态为reviewing。患者端实时收到 WebSocket 推送“您的处方已提交审核”2秒后刷新页面即可看到处方PDF下载按钮。4. 避坑指南五个血泪经验换来的高频报错与解法这份源码虽经多轮压测但在不同环境部署时仍会触发一些“意料之中”的问题。以下是我在三所不同机构部署时踩过的坑按发生频率排序每条都附带可验证的定位命令和修复动作。4.1 现象患者上传图片后后端日志报java.lang.UnsatisfiedLinkError: libtesseract.so: cannot open shared object file原因OCR 模块依赖系统级 Tesseract 库但dev-setup.sh仅安装了 Java 侧的tess4j包未安装原生库。Ubuntu/Debian 系统需libtesseract4CentOS/RHEL 需tesseract包。解决# Ubuntu/Debian sudo apt-get update sudo apt-get install -y libtesseract4 # CentOS/RHEL sudo yum install -y tesseract # 验证安装 tesseract --version # 应输出 4.x.x若仍报错检查LD_LIBRARY_PATH是否包含/usr/lib/x86_64-linux-gnu/Ubuntu或/usr/lib64/CentOS。4.2 现象医生提交处方后PDF 下载按钮始终灰色控制台报GET /api/v1/prescriptions/123/pdf 404原因PDF 文件存储在数据库bytea字段但PrescriptionController.getPdf()方法默认启用PreAuthorize(hasRole(DOCTOR))而测试账号doctor01的角色权限未正确加载。解决检查src/main/resources/data.sql中角色赋值语句-- 确保此行存在非注释 INSERT INTO user_role (user_id, role_id) VALUES (1, 2); -- user_id1 是 doctor01, role_id2 是 DOCTOR若缺失手动执行该 SQL或重启应用Spring Security 权限在启动时加载。4.3 现象PostgreSQL 启动失败日志显示FATAL: could not create shared memory segment: Cannot allocate memory原因Docker 容器默认共享内存/dev/shm仅64MB而 PostgreSQL 在shared_buffers设为 512MB 时需更大空间。解决修改dev-setup.sh中 Docker run 命令增加--shm-size2gb参数docker run -d \ --name med-postgres \ --shm-size2gb \ # ← 新增此行 -p 5432:5432 \ -e POSTGRES_DBmedplatform \ -v $(pwd)/init-meddb.sql:/docker-entrypoint-initdb.d/init.sql \ -d postgres:144.4 现象Vue 前端报错Failed to resolve component: ElUpload界面空白原因Element Plus 组件按需引入配置错误。vite.config.ts中AutoImport插件未正确注册ElUpload。解决打开vite.config.ts检查AutoImport配置项// 确保 plugins 数组包含此项 AutoImport({ imports: [vue, vue-router, element-plus], // ↓ 必须显式添加否则 ElUpload 不会被识别 resolvers: [ElementPlusResolver({ importStyle: sass })], })4.5 现象处方PDF中中文显示为方块诊断栏全是“□□□”原因iText 7 渲染PDF时未指定中文字体路径系统默认字体不支持中文。解决在PrescriptionPdfGenerator.java的createPrescriptionPdf()方法中定位字体加载代码// 修改前使用默认字体 Font font PdfFontFactory.createFont(); // 修改后指定 NotoSansCJK SC 字体源码已自带 fonts/NotoSansCJKsc-Regular.otf String fontPath fonts/NotoSansCJKsc-Regular.otf; Font font PdfFontFactory.createFont(new FileInputStream(fontPath), PdfEncodings.IDENTITY_H);注意字体文件NotoSansCJKsc-Regular.otf已放在src/main/resources/fonts/目录下无需额外下载。5. 处方PDF生成进阶从静态模板到动态水印与防伪码PDF 不只是文档交付终点更是医疗责任追溯的起点。源码的PdfGenerator模块预留了三个生产级扩展点我通常会在客户验收前一周集中补全——它们不改变主流程但能让系统真正跨过合规门槛。5.1 动态添加医生电子签名水印处方PDF需体现“谁在何时开具”。源码默认使用文字水印但真实场景需叠加医生手写签名图。修改PrescriptionPdfGenerator.addWatermark()方法private void addWatermark(PdfDocument pdfDoc, String doctorName, LocalDateTime issueTime) { PdfPage page pdfDoc.getFirstPage(); PdfCanvas canvas new PdfCanvas(page.newContentStreamBefore(), page.getResources(), page); // 1. 添加半透明文字水印原逻辑 canvas.saveState(); canvas.setFillColor(ColorConstants.LIGHT_GRAY); canvas.beginText(); canvas.setFontAndSize(font, 60); canvas.setTextMatrix(AffineTransform.getRotateInstance(Math.toRadians(-30))); canvas.showText(处方- doctorName); canvas.endText(); canvas.restoreState(); // 2. 叠加医生签名图片新增 String signaturePath signatures/ doctorName.replace(医生, ) .png; try (InputStream is getClass().getClassLoader().getResourceAsStream(signaturePath)) { if (is ! null) { ImageData imageData ImageDataFactory.create(is); canvas.addImage(imageData, 400, 750, 120, 40, true); // x,y,width,height } } catch (Exception e) { log.warn(签名图未找到跳过: {}, signaturePath); } }参数说明签名图需按signatures/张三.png命名存于src/main/resources/。尺寸建议 120×40pxPNG 透明背景。若图不存在自动降级为文字水印保障流程不中断。5.2 内置处方防伪二维码绑定处方号与时间戳每张处方PDF右下角生成一个 QR Code扫码可跳转至医院官方验证页需客户自行部署。核心逻辑在PrescriptionPdfGenerator.generateQrCode()private Image generateQrCode(String prescriptionId, LocalDateTime issueTime) { // 生成防伪字符串处方号 时间戳秒级 SHA256盐值 String salt medplatform-2024; // 生产环境应从配置中心读取 String raw prescriptionId | issueTime.truncatedTo(ChronoUnit.SECONDS) | salt; String hash DigestUtils.sha256Hex(raw); // 使用 ZXing 生成 QR Code BitMatrix matrix new MultiFormatWriter().encode( https://verify.hospital.com/check?rx prescriptionId sig hash, BarcodeFormat.QR_CODE, 200, 200 ); ByteArrayOutputStream os new ByteArrayOutputStream(); MatrixToImageWriter.writeToStream(matrix, PNG, os); return new Image(ImageDataFactory.create(os.toByteArray())); }安全提示salt值必须在生产环境替换为随机密钥并通过application-prod.yml加密配置注入禁止硬编码。5.3 PDF元数据注入让Adobe Acrobat显示真实签发信息PDF 文件属性右键→属性→描述默认为空。通过PdfDocument.getCatalog().getPdfObject()注入元数据pdfDoc.getCatalog().getPdfObject().put( PdfName.Author, new PdfString(互联网医院处方系统 v2.3.1) ); pdfDoc.getCatalog().getPdfObject().put( PdfName.Creator, new PdfString(iText 7.2.5 / Java 11) ); pdfDoc.getCatalog().getPdfObject().put( PdfName.Keywords, new PdfString(电子处方,在线问诊, department) );验证方法生成PDF后用 Adobe Acrobat Pro 打开 → 文件→属性→描述确认字段已填充。这是等保2.0三级要求的“文档来源可追溯”落地点。从那以后我每次交付医疗类系统都会强制走一遍这三步签名水印路径检查、防伪码扫码验证、PDF元数据审查。不是因为客户提了需求而是某次三方审计时对方工程师用 Adobe 的“属性检查器”翻出我们漏掉的Author字段当场叫停了签字流程。希望帮到你。本文还有配套的精品资源点击获取
