很多小诊所、社区站，其实一直都处于一个挺尴尬的状态：管理全靠Excel，开药靠人工记，收费靠计算器，一到月底对账就头大。所以我看到这个 Spring Boot 小型医疗机构 HIS 项目时，第一反应是：终于有一个不把“小机构”当“缩水三甲”来设计的系统了。这个项目源码编号是 00943，本质上是一套面向小型医疗机构的医院信息系统，把患者、挂号、医生工作站、处方、收费、药房库存这些核心流程全部串起来，并且是用 Spring Boot 这个主流框架做的，前后端分离不分离都不影响它落地。
这类系统最适合谁？主要就是那些没有专职IT人员、预算有限、又必须满足医疗流程合规性的场景：私立诊所、街道社区卫生服务中心、企业医务室、专科门诊部都能直接用。开发人员拿到这套源码也能快速上手——它不像大型HIS那样动辄几十个微服务，而是用一个单体应用覆盖了最关键的医疗业务闭环，理解起来不绕弯。这篇内容我就从业务拆解、表结构、核心流程、权限设计到部署上线，完整过一遍这套系统到底该怎么看、怎么改、怎么跑起来。
1. 项目整体定位：小型机构不是大医院的缩小版
1.1 小型HIS到底要解决什么事
先想一个问题：一家二十人左右的诊所，一天接诊几十到上百个患者，医疗流程看起来简单，但真正跑起来缺一不可。患者进门先挂号，医生看诊后要开检查或开药，收费处要把项目费用算清楚，药房要按处方发药，下班后还得对账。任何一个环节断了，晚上结账就会对不上。
大型医院的HIS喜欢按“临床、医技、物资、财务、运营”五条线铺开，科室多到几十个，角色权限复杂到能写一本手册。但小型医疗机构如果照抄这个架构，只会把自己压垮。这套 Spring Boot HIS 项目最大的价值在于只保留了最核心的业务主线：基础档案、挂号、门诊医生、收费、药房、统计。它把“人”和“钱”和“药”三件事管住了，这是小机构最痛的三个点。
人指患者和医生，钱指每一笔收费都有据可查，药指药品库存和发药记录必须清晰。加上系统的权限角色控制，医护人员各管各的模块，互相又不冲突，远比共用一台电脑互相翻Excel要安全得多。
1.2 模块划分：一个患者从进门到离开的系统路径
我把这个项目的模块按实际就诊顺序拆解一下，这样理解起来最直观：
- 挂号管理：创建患者档案或调取老患者，生成挂号记录，分配医生和科室，支持退号处理。
- 医生工作站：查看候诊列表、录入诊断结果、开具处方处方，明细里包含药品用法用量。
- 收费管理：对挂号费和处方费用进行结算，生成收费记录，打印收费小票。
- 药房管理：维护药品信息、库存流水、发药记录，支持药品入库和库存预警。
- 基础档案：科室管理、医生管理、患者管理、药品字典，这些是业务跑起来之前的“地基”。
- 统计报表：按时间范围统计挂号量、收费金额、医生工作量，给经营者一个简单的运营视图。
这个模块划分不是拍脑袋定的，它是跟着“患者动线”走的。你把一个早上去看感冒的患者整个流程走一遍，每个环节对应一个模块，系统需求也就自然出来了。做同类系统的时候也建议按这个思路去梳理模块，而不是先考虑技术怎么实现，业务路径是软件结构的第一依赖。
1.3 这套技术路线对于小型机构是否合适
Spring Boot 做单体应用最大的好处就是部署简单、上手快。一个可执行的 jar 包就能跑起来，对服务器要求也不高，一台2核4G的小云主机就能承载一个小型医疗机构的日常业务量。再加上项目里通常会配合 MyBatis Plus 操作数据库、Spring Security 做权限控制，这些技术都是国内开发人员最熟悉的那一套，后续找人维护也很容易。
相比之下，如果直接上个微服务架构，虽然听着高大上，但对小机构来说维护成本极高，光注册中心、配置中心、网关就要好几个服务，出了问题普通运维人员根本处理不了。单体应用就是“一辆面包车能拉货，就别上重卡”的道理。
2. 核心技术栈与架构拆解：为什么这套组合值得复用
2.1 Spring Boot 3 + MyBatis Plus + MySQL 的组合逻辑
这个项目的技术栈应该说非常“标准答案”了。Spring Boot 负责把业务模块组织起来，MyBatis Plus 负责数据库访问，MySQL 作为主数据库存储业务数据，Redis 如果引入了就承担缓存和验证码这类临时数据，前端则是 Vue 或者服务端模板渲染，两种形态都能跑通。
我特别想多说一句 MyBatis Plus 在 HIS 这类管理项目里的优势。它不像 JPA 那样给你套一堆抽象，也不像原生 MyBatis 那样每个SQL都要手写。项目里像患者分页查询、药品列表、挂号记录查询这种简单且高频的数据库操作，直接用 BaseMapper 自带的方法就够了，既快又不容易出错。真正复杂的统计SQL保留手写方式，也不影响灵活性。
2.2 分层架构：Controller、Service、Mapper 怎么隔离
我拿到源码之后最先看的就是包结构。一个合格的Spring Boot医疗项目，包结构基本是这种布局：
com.clinic ├── common // 通用返回、异常、常量 ├── config // 安全配置、跨域配置、Redis配置 ├── controller // 接口入口 ├── service // 业务逻辑层 ├── mapper // MyBatis Plus Mapper接口 ├── entity // 数据库实体 ├── dto / vo // 入参和出参对象 └── utils // 工具类这里的核心思想就一句话：Controller 只做参数收口和结果响应，Service 只做业务流转，Mapper 只做数据访问。
很多新手写代码喜欢在 Controller 里直接写业务逻辑，比如判断库存够不够、计算收费金额，我见过不少。一旦业务复杂起来，Controller 会膨胀到没法看。像 HIS 系统这种涉及多张表联动的项目，万一事务边界没控制好，代码会非常难改。项目里的标准做法就是在 Service 层开事务，把“开处方同时校验库存”这种多步操作放在一个事务方法内完成，保证要么全部成功、要么全部回滚。
2.3 为什么说源码里的通用返回对象很关键
这套系统里一定有一个类似Result<T>的通用返回对象，字段结构大概是code、message、data三个字段。这个看似不起眼的类，实际上决定了整个前后端对接的规范程度。
我见过不少项目，一个接口返回true，另一个接口返回"success"，还有一个返回{"status":200}，前端对接的人每天都要追着后端问字段含义。使用统一返回对象后，前端只需要在拦截器里判断code是否等于约定的成功值，其他情况统一弹错误提示，开发效率能提升一大截。这个项目源码里有这个基础类，新接手的人建议先把这个类看懂，再往下看业务。
3. 数据库模型设计：一张图看懂HIS核心表关系
3.1 主数据表：患者、医生、科室、药品
医疗系统跟普通进销存最大的不同，就是它对“人”的管理非常严格。患者建档时除了姓名、性别、年龄、身份证号、手机号这些常规字段，还应该有“过敏史”“既往病史”这种临床信息，医生看诊时一眼就能看到。
医生和科室单独建表，是为了后续排班和统计医生工作量做准备。药品表就更不必说了，除了药品名称、规格、生产厂家、零售价，还要有“库存上限”“库存下限”，库存低于下限时系统提醒补货，防止断药。
下面是这套系统主数据部分的表结构关系，我按常见实现整理了一个简表：
| 表名 | 核心字段 | 作用 |
|---|---|---|
| patient | id、name、gender、birthday、phone、allergy_history | 患者基础信息 |
| doctor | id、name、department_id、title、phone | 医生信息，关联科室 |
| department | id、dept_name、dept_code、intro | 科室信息 |
| drug | id、drug_code、drug_name、specification、price、stock、stock_low_limit | 药品字典与库存 |
这些表的 ID 建议统一使用雪花ID或数据库自增ID，看项目规模而定。小项目用自增ID完全够，但如果你打算后续做数据迁移或分库分表，雪花ID会更稳妥。源码里的具体策略我没办法替你确定，但跑业务测试阶段自增ID不会拖后腿。
3.2 业务表：挂号、处方、收费、发药
业务表是整个HIS系统的核心脉络。患者挂号和医生开方、收费、发药是关联在一起的，任何一个环节的数据不完整，后续对账都麻烦。
先看挂号表，挂号记录不仅要有患者ID和医生ID，还要有挂号时间、挂号费、就诊状态。就诊状态这个字段特别重要，它至少应该包含“待就诊”“就诊中”“已完成”“已退号”四种，医生看诊和统计工作量都依赖它。
再看处方表，设计上有两种思路：一种是一张处方主表加一张处方明细表，另一种是把处方明细直接全部放进一张表里。主流做法是前者，因为一次看诊可能开出多种药，每种药有自己的数量、用法、用量、天数，还可能出现一个处方里有中药和西药混合的情况。主表存医生ID、患者ID、诊断结果、总金额，明细表存每一种药品的信息和金额，两边通过处方号关联。
收费记录表记录每一笔收款，包括收费项目类型、应收金额、实收金额、支付方式、收费员ID、收费时间。发药记录表则记录药房人员按哪个处方发了哪些药、经手人是谁、发药时间是什么。从挂号、开方到收费、发药，这四张表形成一个闭环，查询任何一个患者的历史都不费劲。
3.3 索引与约束：小系统也要考虑查询性能
很多人写医疗系统的时候容易忽略索引，觉得数据量小无所谓。但别忘了，一两年后积累的挂号记录、收费记录都是几十万条级别，如果每次查询都要全表扫描，系统速度会越来越慢。
我的建议是重点关注这几个索引：
- 挂号表上的
patient_id和doctor_id，用于查患者历史挂号和医生接诊记录。 - 处方主表上的
patient_id+create_time联合索引，用于时间范围查询。 - 收费表上的
charge_time索引，用于日结月结报表。 - 药品表上的
drug_code唯一索引，防止同一药品重复建档。
外键这块，我个人的经验是：纯数据一致性要求极高、且量小的表可以用外键，但像 HIS 这种业务规则复杂的系统，外键容易锁竞争激烈，反而拖慢性能。项目源码里更常见的做法是逻辑外键，也就是字段保留 ID 关联关系，但不真的建 FOREIGN KEY 约束，事务的一致性靠Service层保证。这种方式有利于将来的功能扩展，也方便做分库分表。
4. 核心业务链路实现：从“挂一个号”到“发一盒药”
4.1 挂号环节：锁定号源与创建就诊记录
挂号是整个系统的入口，这个环节虽然看似简单，但业务上有一个关键点：挂号时要同时做两件事，一是登记患者本次就诊的挂号信息，二是更新号源状态。如果挂号动作和号源锁定不是同一个事务，就会出现两个人同时挂同一个医生最后一个号的情况。
代码层面的典型结构大概是：
@Transactional(rollbackFor = Exception.class) public Result<Long> createRegistration(RegistrationDTO dto) { Patient patient = patientMapper.selectById(dto.getPatientId()); if (patient == null) { return Result.error("患者不存在"); } // 检查号源 Registration record = new Registration(); record.setPatientId(dto.getPatientId()); record.setDoctorId(dto.getDoctorId()); record.setDeptId(dto.getDeptId()); record.setFee(dto.getFee()); record.setStatus(RegistrationStatus.WAITING.getCode()); record.setRegisterTime(LocalDateTime.now()); registrationMapper.insert(record); return Result.success(record.getId()); }这里比较核心的就是@Transactional注解。如果没有事务，假设插入挂号记录成功了，但接下来的号源扣减失败了，数据库里就多出一条“死挂号”，患者来了没医生看，数据还对不上。
4.2 医生工作站：开立处方必须携带明细
医生端的功能核心是调出待就诊患者列表，录入诊断后开处方。这里最容易踩坑的是“主表已保存，明细表没保存”的问题。
假设一次开三种药，代码逻辑应该是先插入处方主表拿到处方ID，再循环插入处方明细表，明细里关联处方主表ID。如果循环到第二种药时失败，前面插入的明细和主表数据都会成为脏数据，所以这一步也必须加事务。
@Transactional(rollbackFor = Exception.class) public Result<Long> createPrescription(PrescriptionDTO dto) { // 1. 更新挂号状态为“就诊中”或“已完成” registrationMapper.updateStatus(dto.getRegistrationId(), RegistrationStatus.FINISHED.getCode()); // 2. 插入处方主表 Prescription prescription = new Prescription(); prescription.setPatientId(dto.getPatientId()); prescription.setDoctorId(dto.getDoctorId()); prescription.setDiagnosis(dto.getDiagnosis()); prescription.setTotalAmount(dto.calcTotalAmount()); prescription.setCreateTime(LocalDateTime.now()); prescriptionMapper.insert(prescription); // 3. 插入处方明细 for (PrescriptionItemDTO item : dto.getItems()) { PrescriptionItem detail = new PrescriptionItem(); detail.setPrescriptionId(prescription.getId()); detail.setDrugId(item.getDrugId()); detail.setQuantity(item.getQuantity()); detail.setPrice(item.getPrice()); detail.setUsageMethod(item.getUsageMethod()); prescriptionItemMapper.insert(detail); // 4. 减少药品库存：这里要小心超卖 int rows = drugMapper.reduceStock(item.getDrugId(), item.getQuantity()); if (rows == 0) { throw new RuntimeException("药品库存不足：" + item.getDrugName()); } } return Result.success(prescription.getId()); }注意我标出的reduceStock方法，它返回受影响行数，如果返回0说明库存不足。这种利用SQL原子更新的方式来减库存，比先查库存再更新更安全，能避免并发情况下超卖。
4.3 收费联动：先收费再发药还是先发药再收费
实际业务里有两种模式。一种叫“先收费后发药”，处方开完之后患者去收费窗口结算，收费成功之后药房才能拿到处方发药，这套系统里默认走这个逻辑。另一种是“先发药后收费”，一般用于急诊绿色通道，正常门诊不建议用。
收费环节要做到“一笔收费对应一个处方”，收费表里存处方ID。发药环节则要检查收费状态，没交费的处方不能发药。这套数据结构下，你可以非常容易实现“退药退费”的业务：退药时先查发药记录，更新库存，再作废收费记录。
4.4 事务和并发：小诊所也会遇到的数据竞争
小诊所虽然客流不大，但早上开诊高峰那半小时特别集中，几十个患者同时挂号、开药、交费，如果接口写得不严谨，还是会出现并发问题。挂号时重复挂号、收费时重复提交、药品库存扣成负数，这些都是我实际见过的场景。
解决思路很简单：
- 扣库存用原子更新SQL，不靠程序先查再减。
- 关键状态变更加状态字段前置校验，比如挂号和退号都校验当前状态。
- 幂等控制：收费接口拿到重复请求时，先查是否已有相同处方ID的收费记录，有则直接返回已有结果。
这个源码项目在关键业务上面用了事务和状态校验，但如果你准备把它用于生产环境，我仍然建议再检查一遍库存扣减是不是原子操作，这一步最容易出问题。
5. 权限设计与数据安全：小系统也要守住患者隐私
5.1 角色划分：管理员、医生、收费员、药房
医疗数据属于个人敏感信息，权限控制不是摆设。即使是一个小型诊所，也必须做到“医生看不到收费金额、收费员改不了诊断、药房不能乱发药”。
这个项目常见的角色模型如下：
| 角色 | 核心权限 |
|---|---|
| 管理员 | 用户管理、基础数据维护、报表查看、系统配置 |
| 医生 | 患者列表、候诊、诊断开方、查看本人历史处方 |
| 收费员 | 挂号收费、处方收费、退费、日结算单 |
| 药房人员 | 药品维护、入库、发药、库存查询 |
在代码层面，比较稳妥的做法是通过 Spring Security 配置接口级别的权限注解：
@PreAuthorize("hasRole('DOCTOR')") @PostMapping("/prescription") public Result<Long> createPrescription(@RequestBody PrescriptionDTO dto) { return prescriptionService.createPrescription(dto); }这样就算某个入口漏了前端按钮控制，后端依然会拦截，防止越权操作。
5.2 登录与Token认证：无状态会话怎么落地
小型HIS系统通常不需要复杂的单点登录，用 JWT 做无状态认证是性价比最高的选择。用户登录成功后，后端生成一个包含用户ID和角色信息的 token，前端每次请求带上这个 token，后端拦截器解析 token 并放入当前用户上下文。
有一个细节必须注意：JWT 本身是有状态的业务数据，不应该越签越长。我之前见过一个项目，把患者的全部档案塞进 JWT 里，token 越来越长，网络传输越来越慢，这属于纯粹的坏设计。token 里只需要用户ID、角色、过期时间，其他数据一律通过接口查询。
5.3 敏感数据防护与审计日志
患者手机号、身份证号这类字段，数据库里能加密就加密存储。你要是怕影响查询，可以用数据库中不可逆加密或应用层加密的方式保存。不过手机号这种字段经常要用来精确查询，做脱敏显示即可，不一定非要加密。
审计日志就一句话原则：谁在什么时间对什么数据做了什么操作，必须能回溯。至少要把关键操作记录到一张操作日志表里，包括操作人、操作类型、对象ID、操作时间和请求IP。真出了医疗纠纷，这些日志就是证据。
6. 部署上线与运维心得：给想跑起来的人一份操作清单
6.1 环境准备：JDK、MySQL、Maven 一个都不能少
这套项目是 Spring Boot 技术栈，运行前提是 JDK 17 或更高版本（如果用的 Spring Boot 3），MySQL 8.0 起步，项目构建用 Maven 或者直接引入 IDEA 运行。本地开发时先用 test 环境配置，数据库连接、Redis 地址都指向本地。
我建议你拿到源码之后第一步不是直接跑，而是先执行项目里带的sql脚本建库建表。很多项目启动报错都是因为用户表不存在，而不是代码有问题。数据库字符集统一用utf8mb4，排序规则用utf8mb4_general_ci，避免中文乱码。
6.2 配置文件的坑：时区、连接池、上传路径
Spring Boot 项目的application.yml里面经常藏着几个让人头疼的问题。最典型的是数据库连接串时区：
spring: datasource: url: jdbc:mysql://localhost:3306/clinic_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 servlet: multipart: max-file-size: 10MB max-request-size: 10MB数据库服务器和程序所在服务器不在同一个时区时，查询出来的时间会相差8小时，这就是典型的时区问题。另外，连接池初期连接数和最大连接数要根据实际并发量调，诊所系统一般initial-size: 5、max-active: 50就非常富裕了。
6.3 打包部署：jar 包跑起来其实很简单
开发环境用 IDEA 直接跑没有问题，但生产环境最省心的方式是打 jar 包，用java -jar启动。
mvn clean package -DskipTests nohup java -jar his-00943.jar --spring.profiles.active=prod > his.log 2>&1 &这里的--spring.profiles.active=prod就是激活生产配置文件的入口。port 默认 8080，如果端口被占用，可以通过启动参数改：
nohup java -jar his-00943.jar --server.port=8081 > his.log 2>&1 &我踩过的坑是：有些服务器默认安装了低版本 JDK，跑高版本 Spring Boot 会直接报UnsupportedClassVersionError。部署前先执行java -version看一眼，别等到启动报错才排查。
6.4 上线前必须检查的三件事
- 初始管理员密码：项目里有自带的超级管理员账号，上线后第一件事改成强密码。
- 备份策略：MySQL 至少每天全量备份一次，小诊所数据量不大，写个 crontab 脚本就行。
- 访问权限：管理后台不要把端口暴露到公网，能用内网访问就不要对外网开放，或者加IP白名单。
这些听起来基本，但很多项目就是倒在这些“看起来不用管”的小事上。
7. 真实场景下的落地教训与优化方向
7.1 挂号高峰并发：接口响应变慢不是加机器就能解决的
有家小诊所白天人不多，但每天早上8点半到9点半是高峰，患者都集中在那个时间段来，挂号和开药请求同时打进来。一开始程序员的思路是加大服务器配置，后来发现瓶颈其实在数据库表锁和业务代码里的慢查询。
优化方向并不复杂：热门医生查询、号源状态查询这种高频但结果集很小的接口，加 Redis 缓存，过期时间控制在30秒以内就能有效降低数据库压力。挂号写操作不用盲目上消息队列，做好事务和索引，小机构这个量级完全扛得住。
7.2 药品库存不准：一定要做库存流水
这可能是HIS系统里最让人头疼的问题。开完处方扣了库存，患者后来没交费走了，处方被作废，但库存没加回来，账上库存就少了。解决的办法是引入库存流水表，每一笔扣减和回补都记录来源单号，月底对账时直接按流水表反查，而不是盯着库存字段猜。
如果源码里还没有库存流水表，改造也不复杂：药品库存字段仍然保留，但所有库存变更必须同时写一条库存流水记录，记录变更前数量、变更后数量、变更类型、关联单号。这样既能保证查询速度，又能审计追溯。
7.3 财务报表口径：直接写SQL统计表会更简单
统计功能如果靠程序循环算数据，效率很低，而且口径容易对不上。比如“今天营业额”到底是收费成功总额还是处方开立总额？这两者差的就大了。
我建议项目里的统计页面直接落地为SQL汇总查询，用GROUP BY按日期、科室、医生分组统计，接口只负责把结果返回前端。遇到复杂报表需求，宁可多写几条SQL或建视图，也尽量不要在Java内存里做二次聚合。
7.4 下一步扩展：排班、电子病历、医保接口
这套系统再往后走有几个天然扩展点：医生排班系统可以挂在医生表上做一周排班表，电子病历可以按患者维度做历次就诊档案，医保接口则需要对接各地医保平台。好消息是当前的数据结构已经为这些扩展留了空间：患者ID贯穿所有业务表，医生表和科室表独立维护，后续加功能不需要推翻重来。
我个人在实际操作中的体会是，拿到一份HIS源码后不要急着改代码，先把业务闭环走通一遍：建档、挂号、开方、收费、发药、退号退费，动手比看代码更快理解系统。尤其是“源码00943”这个版本，整体功能不复杂，恰恰适合做二次开发练手。唯一要提醒的是，真正用于医疗机构生产环境之前，务必要找医疗信息化相关规范核对一遍数据安全要求，该做的等保、隐私协议、数据备份一项都不能省。代码可以帮你把流程跑顺，但合规这块，最终还是要靠运营者自己把关。
