简介：这是一套基于SpringBoot、Jpa与Thymeleaf构建的Java医院信息管理系统（HIS）源码，面向中小型医疗机构信息化建设者及希望深入理解主流Java Web技术栈的开发者。系统整合患者管理、医生排班、科室协作、药品库存、财务收支、预约挂号、住院管理、检查报告、权限控制与系统设置等核心模块，可作为二次开发或定制化项目的基础框架。压缩包共3973个文件，约15.37MB，以2982个svg图标、254个scss与100个css样式、129个java源码、136个js脚本及56个html页面为主，另含sql建表脚本、yml配置与maven构建文件，前端资源与后端逻辑分层清晰。目前已有2525人学习下载。通过阅读源码，可掌握实体映射、服务层实现与动态页面渲染的完整链路，理解医疗业务模块的数据库设计与权限模型，并借助现成目录结构快速搭建可运行环境，为课程设计、毕业项目或企业级开发提供可复用的参考实现。

1. 从一张挂号单说起：医院HIS源码到底在解决什么问题

一套能跑起来的医院信息管理系统源码，核心价值不在于界面多漂亮，而在于它能不能把「患者从进门诊到拿药离开」这条链路上的数据串起来。挂号、分诊、医生开方、收费、药房发药、住院登记、医嘱执行、费用结算——这些环节在纸面上是流程，在代码里就是一张张表、一个个状态机、一次次事务提交。标题里的「医院HIS源码」，说的就是这套东西的完整实现。

我见过不少团队拿到一份HIS源码后，第一反应是改界面、换皮肤，结果上线两周就翻车：挂号序号重复、收费金额对不上、退药后库存没回滚。问题不在UI，在于他们没搞懂HIS的数据模型和事务边界。这篇文章面向的是想基于Java技术栈搭建或二次开发HIS的工程师，我会把表结构设计、核心业务链路、并发控制、部署方式拆开讲，让你拿到源码后知道先看哪里、改哪里、测哪里。

2. 拿到源码先别急着跑：HIS的六张核心表与业务闭环

2.1 患者、挂号、就诊、处方、收费、药品：数据模型怎么串

HIS的数据模型本质上是一条「患者主索引驱动」的链路。患者第一次来，系统生成一条患者主记录（patient），后续所有业务表都通过patient_id关联。挂号表（registration）记录本次就诊的科室、医生、号别、费用；就诊表（visit）记录医生接诊后的诊断信息；处方表（prescription）和处方明细表（prescription_item）记录开了什么药、多少量、怎么用；收费表（charge）记录每一笔费用的来源和状态；药品库存表（drug_stock）记录入库、出库、当前库存。

这六张表的关系不是简单的父子表，而是通过业务状态字段互相约束。比如挂号表有一个status字段，取值可能是「已挂号、已就诊、已退号」；收费表有一个charge_status，取值可能是「未收费、已收费、已退费」。处方能不能发药，取决于收费状态是不是「已收费」；药品库存能不能扣减，取决于处方明细是否已经过收费确认。

常见做法是：先画一张状态流转图，把每个业务对象的生命周期标清楚，再去看源码里的枚举类和状态判断逻辑。如果你拿到源码发现状态字段用的是魔法数字（0、1、2），第一件事就是把它替换成枚举，否则后期排查问题会非常痛苦。

2.2 用SQL把「挂号→收费→发药」跑通一遍

下面这段SQL模拟了一个最小业务闭环：一个患者挂号、医生开方、收费、药房扣库存。你可以直接在MySQL里执行，用来验证源码的表结构是否完整。

-- 1. 插入患者主记录 INSERT INTO patient (patient_id, name, gender, id_card, phone, create_time) VALUES (1001, '测试患者', 'M', '110101199001010011', '13800000000', NOW()); -- 2. 挂号：状态0=已挂号 INSERT INTO registration (reg_id, patient_id, dept_id, doctor_id, reg_type, reg_fee, status, reg_time) VALUES (2001, 1001, 10, 100, '普通号', 10.00, 0, NOW()); -- 3. 医生接诊后开处方 INSERT INTO prescription (presc_id, reg_id, patient_id, doctor_id, diagnosis, status, create_time) VALUES (3001, 2001, 1001, 100, '上呼吸道感染', 0, NOW()); -- 4. 处方明细：开2盒阿莫西林 INSERT INTO prescription_item (item_id, presc_id, drug_id, drug_name, quantity, unit_price, status) VALUES (4001, 3001, 5001, '阿莫西林胶囊', 2, 15.50, 0); -- 5. 收费：状态0=未收费，1=已收费 INSERT INTO charge (charge_id, presc_id, patient_id, total_amount, charge_status, charge_time) VALUES (5001, 3001, 1001, 31.00, 1, NOW()); -- 6. 扣减库存：确保库存足够再扣 UPDATE drug_stock SET stock_quantity = stock_quantity - 2, update_time = NOW() WHERE drug_id = 5001 AND stock_quantity >= 2; -- 7. 回写处方状态为已发药 UPDATE prescription SET status = 2 WHERE presc_id = 3001;

这段SQL的逻辑说明：第2步挂号时status=0表示已挂号但未就诊；第5步收费时charge_status=1表示已收费；第6步扣库存用了stock_quantity >= 2作为条件，这是防止超卖的关键；第7步把处方状态改为2表示已发药。参数说明：reg_type可以根据业务扩展为「专家号、急诊号」；drug_stock的stock_quantity字段必须是unsigned或者加check约束，否则并发下会出现负库存。

注意：真实HIS里这些操作必须放在同一个事务里，并且收费和扣库存之间要有幂等控制。上面拆成多条SQL只是为了让你看清每一步。

2.3 源码目录怎么读：从Controller到Mapper的追踪路径

Java技术栈的HIS源码，常见结构是Spring Boot + MyBatis + MySQL，前端可能是Vue或Thymeleaf。拿到源码后，不要从首页开始点，按这个顺序读：

第一步，找pom.xml或build.gradle，确认依赖版本。重点看MyBatis、Druid、Spring Security的版本，这些直接影响你后续改代码的兼容性。

第二步，找application.yml或application.properties，看数据库连接、端口、日志级别。如果源码里数据库密码是明文，先改成环境变量注入。

第三步，从controller包入手，找RegistrationController、ChargeController、PharmacyController这三个类。它们对应挂号、收费、药房三个核心模块，方法名通常能直接反映业务动作。

第四步，顺着Controller调用的Service，找到对应的Mapper接口和XML文件。XML里的SQL就是业务逻辑的最终落点，重点看insert、update语句的条件和事务注解。

第五步，找entity包和dto包，对比数据库表字段和Java对象的映射关系。如果发现字段名不一致，检查MyBatis的resultMap配置。

我一般会先画一张调用链路图：Controller → Service → Mapper → Table，然后把每个环节的类名和文件路径标上去。这样改任何一处，都能快速定位影响范围。

3. 把HIS跑起来：环境配置、数据库初始化与接口验证

3.1 本地环境的最小依赖清单

跑一套Java HIS源码，本地至少需要：JDK 8或11（看源码的maven.compiler.source配置）、MySQL 5.7或8.0、Maven 3.6以上、Redis（如果源码用了缓存）、Node.js（如果前端是独立项目）。内存建议8GB以上，因为MySQL和Java应用同时跑会吃不少资源。

数据库初始化通常源码里会带一个sql目录，里面有schema.sql和data.sql。先执行schema.sql建表，再执行data.sql插入基础数据（科室、医生、药品字典）。如果源码没带初始化脚本，你需要根据entity类反推表结构，这时候用JPA的ddl-auto=create可以临时生成，但生产环境绝对不能用。

配置文件里重点改三个地方：数据库URL、数据库账号密码、文件上传路径。文件上传路径如果写的是Windows绝对路径，在Linux上会直接报错。常见做法是改成/data/his/upload/，并确保目录存在且有写权限。

3.2 用Docker Compose起MySQL和Redis

为了避免本地环境污染，我习惯用Docker Compose起依赖服务。下面是一个最小配置：

version: '3.8' services: mysql: image: mysql:8.0 container_name: his-mysql environment: MYSQL_ROOT_PASSWORD: his_root_2024 MYSQL_DATABASE: his_db MYSQL_USER: his_user MYSQL_PASSWORD: his_pass_2024 ports: - "3306:3306" volumes: - ./mysql-data:/var/lib/mysql - ./sql:/docker-entrypoint-initdb.d command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci redis: image: redis:6.2 container_name: his-redis ports: - "6379:6379" volumes: - ./redis-data:/data

逻辑说明：docker-entrypoint-initdb.d目录下的SQL文件会在MySQL容器首次启动时自动执行，所以把schema.sql和data.sql放进去就能自动初始化。参数说明：utf8mb4字符集必须设置，否则患者姓名里的生僻字会乱码；MYSQL_ROOT_PASSWORD不要用弱密码，即使是本地环境。

启动命令：docker-compose up -d。启动后用docker logs his-mysql看初始化日志，确认SQL执行没有报错。如果报错，大概率是SQL文件里有外键依赖顺序问题，需要调整执行顺序。

3.3 启动应用并验证挂号接口

应用启动命令通常是mvn spring-boot:run或者java -jar his-application.jar。启动后看日志里有没有Started Application in X seconds，有就说明Spring上下文加载成功。

验证挂号接口，用curl发一个POST请求：

curl -X POST http://localhost:8080/api/registration \ -H "Content-Type: application/json" \ -d '{ "patientId": 1001, "deptId": 10, "doctorId": 100, "regType": "普通号", "regFee": 10.00 }'

如果返回{"code":200,"data":{"regId":2001}}，说明挂号链路通了。如果返回500，先看应用日志里的异常堆栈，常见原因是数据库连接失败或者字段映射错误。如果返回400，检查请求体字段名是否和DTO一致。

接着验证收费接口和发药接口，确保整条链路能走通。每验证一个接口，就在数据库里查一下对应表的数据，确认状态字段被正确更新。这一步不能省，很多问题在接口层面看不出来，只有查库才能发现。

4. 避坑指南：HIS源码二次开发中最容易翻车的五个地方

4.1 挂号序号重复：并发下的号源分配问题

现象：两个患者同时挂号，系统分配了同一个序号。原因：源码里用SELECT MAX(seq) + 1生成序号，没有加锁。解决：改用数据库序列或者Redis原子递增，或者在挂号表上加唯一索引，让数据库来保证唯一性。如果源码用的是MAX+1，必须改成INSERT ... SELECT配合行锁，或者直接用AUTO_INCREMENT。

4.2 收费金额对不上：浮点数精度丢失

现象：处方明细里单价15.50，数量2，收费表里总额显示30.99。原因：Java里用double或float做金额计算，二进制浮点数无法精确表示小数。解决：所有金额字段用BigDecimal，数据库用DECIMAL(10,2)。如果源码里已经用了double，全局搜索替换成BigDecimal，并且注意BigDecimal的equals和compareTo区别。

4.3 退药后库存没回滚：事务边界不完整

现象：患者退药成功，但药品库存没有增加。原因：退药逻辑里只更新了处方状态，没有调用库存回滚方法，或者库存回滚和状态更新不在同一个事务里。解决：在Service层方法上加@Transactional，确保退药状态更新和库存回滚要么都成功，要么都失败。同时检查退药接口是否有幂等控制，防止重复退药导致库存虚增。

4.4 医生排班冲突：时间区间重叠判断错误

现象：同一个医生在同一时间段被安排了两次排班。原因：源码里判断时间冲突用的是start_time > existing_end AND end_time < existing_start，这个条件在边界情况下会漏判。解决：改成start_time < existing_end AND end_time > existing_start，并且把时间字段统一成DATETIME类型，避免时区问题。如果源码用的是字符串存时间，先改成标准时间类型。

4.5 患者主索引重复：没有唯一约束

现象：同一个患者多次挂号，系统生成了多个patient_id。原因：患者表没有对身份证号加唯一索引，或者挂号时没有先查患者是否已存在。解决：在patient表的id_card字段上加唯一索引，挂号接口里先根据身份证号查询，存在就复用，不存在才新建。如果历史数据已经有重复，需要先清洗数据再加索引。

5. 从能跑到好用：HIS源码的进阶改造与验证习惯

5.1 用接口幂等和状态机把业务锁死

一套HIS源码能不能上生产，关键看它有没有幂等控制和状态机约束。幂等控制的意思是：同一个请求发两次，结果应该一样。比如收费接口，如果患者重复点击收费按钮，不能扣两次钱。常见做法是在charge表上加唯一索引（presc_id + charge_status），或者用Redis记录请求token。

状态机约束的意思是：业务对象的状态流转必须是合法的。比如处方状态从「已开方」只能到「已收费」，不能从「已开方」直接跳到「已发药」。源码里如果只有if-else判断状态，建议引入Spring StateMachine或者自己写一个状态流转表，把合法流转路径配置化。

下面是一个简单的状态流转配置示例：

// 处方状态流转规则 public enum PrescriptionStatus { CREATED(0, "已开方"), CHARGED(1, "已收费"), DISPENSED(2, "已发药"), RETURNED(3, "已退药"); // 合法流转路径 private static final Map<PrescriptionStatus, Set<PrescriptionStatus>> TRANSITIONS = Map.of( CREATED, Set.of(CHARGED), CHARGED, Set.of(DISPENSED, RETURNED), DISPENSED, Set.of(RETURNED), RETURNED, Set.of() ); public static boolean canTransition(PrescriptionStatus from, PrescriptionStatus to) { return TRANSITIONS.getOrDefault(from, Set.of()).contains(to); } }

逻辑说明：TRANSITIONS定义了每个状态能跳到哪些状态。参数说明：CREATED只能到CHARGED；CHARGED可以到DISPENSED或RETURNED；DISPENSED只能到RETURNED；RETURNED是终态。在Service层每次更新状态前，先调用canTransition判断，不合法就抛异常。这样能防止大部分状态错乱问题。

5.2 用日志和审计表追踪每一次数据变更

HIS系统里，谁改了挂号信息、谁退了费、谁调整了库存，都必须能查。源码里如果只有System.out.println，那基本没法用。我一般会做两件事：第一，用AOP切面拦截所有Service层的写操作，记录操作人、操作时间、操作前后的数据快照；第二，建一张audit_log表，把关键字段的变更写进去。

审计表结构可以很简单：id, table_name, record_id, field_name, old_value, new_value, operator, operate_time。每次更新前查一次旧值，更新后查一次新值，对比差异写入审计表。这样出问题时，直接查审计表就能还原现场。

5.3 上线前必须跑的五个验证场景

源码改完后，不要只点几下页面就上线。我习惯跑五个场景：第一，并发挂号100次，看序号有没有重复；第二，收费后立即退费，看库存和金额有没有回滚；第三，医生开方后患者不缴费直接离开，看处方状态是否停留在「已开方」；第四，药房发药时库存不足，看系统是否阻止发药并提示；第五，患者退药后再次退药，看是否幂等。

这五个场景跑通，基本能覆盖80%的线上问题。剩下的20%靠日志和监控兜底。我自己的习惯是：每次改完HIS源码，先在本地用Postman跑一遍这五个场景，再部署到测试环境让业务同事点一遍。血泪经验告诉我，跳过这一步，上线后半夜被叫起来查数据是迟早的事。

希望帮到你。

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