企业官网建设流程全解析

重症监护室的护理管理，说实话是个非常典型的“小而难”业务场景。难不在于业务逻辑有多复杂，而在于数据实时性要求高、来源零散、医疗责任界定严格。我这次做的这套基于Spring Boot框架的重症监护室急诊护理管理系统，就是针对ICU日常护理中“记录靠手写、查询靠翻纸、统计靠Excel”这一堆痛点去设计的。系统覆盖了从患者入科建档、生命体征采集、护理记录单生成、医嘱执行闭环，到护士排班、床位分配、设备巡检的全流程管理，整个后端基于Spring Boot 2.7 + MyBatis Plus + MySQL + Redis这套组合来实现，前端搭配Vue 3和Element Plus。如果你是做Java毕业设计、正在搞Spring Boot实战项目，或者所在团队准备把科室护理流程线上化，这套系统的设计思路和落地细节会很有参考价值。

1. 需求拆解与系统整体设计

1.1 ICU护理场景的核心痛点

动手写代码之前，我花了不少时间蹲在科室里看护士的工作流。不把业务场景吃透，做出来的系统就是“挂着医疗名头的通用增删改查”，没法真正用起来。

ICU的护理工作有几个非常突出的特点。第一是生命体征数据采集频率极高，体温、心率、呼吸、血压、血氧饱和度这些指标，以前是每小时手工填一次，一天下来一张记录单写得密密麻麻。第二是医嘱执行链路长，医生开完医嘱之后，护士要先核对、再执行、再签名，事后还要补录执行时间和执行人，任何一个环节断了都没法追溯。第三是交接班信息量大，白班和夜班之间要传递的不只是患者当前状况，还包括各种引流管、压疮风险、镇静评分这些维度数据，口头交接极易遗漏。

这几个痛点决定了系统不能只做成信息管理工具，它本质上是一个“实时数据采集 + 闭环任务执行 + 全链路追溯”的平台。所以我在需求梳理阶段就把系统拆成了几个核心模块：患者入科与床位管理、生命体征采集与趋势分析、电子护理记录单、医嘱执行闭环、护理排班管理、设备与物资管理，以及系统权限与日志审计。每个模块之间的数据流向必须清晰，比如医嘱执行后会产生护理任务，护理任务执行过程中产生的体征数据又会回流到护理记录单上。

1.2 技术选型思路

这套系统的主技术栈是Spring Boot，但选型过程中我其实做了不少对比，不只是“用Spring Boot就行”那么简单。

后端这块，Spring Boot 2.7.18是首选。为什么不直接上Spring Boot 3.x？原因很现实：3.x版本基于Jakarta EE规范，很多老牌第三方库的兼容版本当时还不够稳定，而且很多毕业设计或者团队已经在跑的项目都停留在2.x生态，用2.7能最大程度保证各种参考方案可以直接复用。MyBatis Plus作为持久层框架，好处是单表CRUD几乎不用写SQL，分页插件也内置好了，项目开发速度能快不少。Redis主要用来做三件事：登录Token缓存、验证码存储、热点数据缓存。医疗数据的查询频率很高，比如某位患者最近24小时的体征记录会被反复读取，这种数据放Redis里能明显降低数据库压力。

前端选型上，Vue 3 + Element Plus是当前实战项目里的主流组合。Vue 3的组合式API写业务逻辑比Vue 2的选项式API清爽很多，Element Plus的表单组件和表格组件非常成熟，做管理系统界面基本是开箱即用。前后端通过RESTful API交互，认证采用JWT方案。

这里我把核心技术栈做了个整理：

1.3 系统模块划分与核心业务流程

系统的功能模块划分直接决定了后端Controller层怎么组织。我按业务域拆分的方式设计，而不是按技术层拆分，这样更贴近实际使用场景。

整个系统划分为六个核心业务模块。患者管理模块负责入科登记、病历摘要、床位分配和转科转出，这个模块是所有业务的数据源头，患者核心信息在这里先落库，生成唯一的患者编号。护理记录模块是整个系统的重心，包括生命体征数据录入、体温单自动生成、护理评估量表（如格拉斯哥昏迷评分、压疮风险评分）管理。医嘱管理模块负责从HIS系统接入或手动录入医嘱，执行时生成执行任务，护理人员逐条确认后标记执行状态。排班管理模块按月/周生成护理排班表，支持轮班规则设置和调班申请。设备管理模块管理监护仪、呼吸机等设备的档案和使用状态。系统管理模块则是用户、角色、菜单、操作日志这些基础功能。

核心业务闭环可以这样概括：患者入科时系统自动分配床位并生成护理档案，医生下达医嘱后系统按医嘱类型生成护理任务，护士在PDA或电脑端接收任务并执行，执行过程中填写的生命体征数据自动写入记录单，交班时系统按模板汇总所有未闭环事项供接班护士确认。这个链路走通之后，“信息需要护士手工二次整理”的场景就基本消失了。

2. 数据库设计与核心表结构

2.1 表设计总览

数据库设计是医疗系统里最不能糊弄的部分。医疗数据有两个特点，一是数据量大，比如心电监护仪十分钟就能产生几千条波形数据；二是追溯要求高，一条护理记录一旦签名确认就不能删除，只能通过更正记录来调整。所以建表的时候我遵循了几个原则：所有业务表都带主键、创建时间、更新时间、逻辑删除标记，但医疗核心表不用物理外键，而是通过索引和业务层保证数据一致性，这样既能提高写入性能，也方便后续分库分表。

系统核心表我大致分成这么几张：用户表、角色表、患者信息表、住院记录表、床位表、护理记录单主表、护理记录明细表、生命体征采集表、医嘱表、医嘱执行记录表、排班表、设备信息表、操作日志表。加上中间关联表，一共十六张表。

这里挑几张关键表说一下设计思路，完整的建表SQL能在实际开发中节省很多排查时间。

2.2 核心业务表字段设计

患者信息表是基础中的基础，字段包括患者编号、姓名、性别、出生日期、身份证号（加密存储）、入院时间、入科时间、主治医生ID、责任护士ID、诊断描述、过敏史、当前状态（在科、转出、出院）。这里特别注意，身份证号这种敏感信息在数据库里不能明文存，我用AES加密后入库，查询的时候在Service层解密，接口返回时做脱敏处理，只显示前6位和后4位。

生命体征采集表是最核心的一个表，字段设计要考虑“一次采集，多处使用”。我在设计时把采集ID、住院记录ID、患者ID、采集时间、体温、心率、呼吸、收缩压、舒张压、血氧饱和度、意识状态、采集护士ID全部放在一张表里。这里有个细节：血压同时有收缩压和舒张压两个值，有些人喜欢合并成一个字段存“120/80”，但我坚持拆成两个独立字段，因为后面做趋势统计的时候，用SQL直接算收缩压均值非常方便，不用先做字符串拆分。

护理记录单主表存储的是每次记录单的元信息，比如记录单编号、住院记录ID、记录日期、班次（白班/夜班）、记录护士、审核护士、记录状态（草稿、已提交、已审核）、签名时间。明细表则存储具体的记录条目，每条包含记录项目名称、记录值、单位、记录时间。主明细分离的好处是，以后如果护理文书模板要扩展字段，不需要频繁改表结构。

医嘱表的设计也有讲究。医嘱类型包括长期医嘱和临时医嘱，长期医嘱有开始时间和结束时间，临时医嘱只需要执行一次。表里我设计了医嘱状态字段，从“已开具”到“已审核”到“执行中”“已执行”“已停止”，整个生命周期都要可追踪。医嘱执行记录表独立于医嘱表，每条执行记录关联医嘱ID、执行护士ID、执行时间、执行结果，这样即使医嘱被修改，历史执行记录也完整保留。

2.3 MyBatis Plus配合下的表操作细节

用了MyBatis Plus之后，绝大多数单表操作不需要手写SQL，但有几个细节我要单独提示一下。

第一是逻辑删除配置。MyBatis Plus全局配置里开启逻辑删除后，所有删除操作自动变成UPDATE，查询自动追加deleted=0条件。这个功能对医疗系统特别有用，尤其是患者信息和护理记录这种不能物理删除的数据。我在配置文件里加了全局逻辑删除配置，同时在实体类对应的逻辑删除字段上加了@TableLogic注解。

第二是自动填充。创建时间和更新时间这两个字段在每个表里都有，手动逐个set实在太蠢。我用MyBatis Plus的MetaObjectHandler接口实现了字段自动填充，插入时自动填充createdTime和updatedTime，更新时自动填充updatedTime，这样业务代码里完全不用关心时间字段。

第三是分页插件配置。ICU的体征数据量增长很快，全表查询基本是灾难。我配置了MyBatis Plus的分页插件，同时设置了最大单页限制，防止有人传pageSize=10000把数据库打爆。分页插件底层做了SQL拦截和优化，limit条件能自动拼到SQL后面，不需要手写。

3. 后端核心功能模块实现

3.1 基于JWT的登录鉴权与角色权限设计

医疗系统的权限控制比普通管理系统严格得多。在我这个系统里，用户角色分为系统管理员、护士、护士长、医生（只读权限为主）。不同角色能访问的接口完全不同，比如护士可以新增和修改护理记录，但医生不能修改，只能查看；护士长可以查看全科所有患者的护理记录，普通护士只能查看自己负责的患者。

实现方案是JWT + Spring拦截器 + 自定义注解。用户登录成功后，后端生成一个JWT Token，Token里封装了用户ID、用户名、角色编码和过期时间，然后用HMAC-SHA256算法签名，防止被篡改。前端每次请求在Header里携带Token，后端通过拦截器统一校验。

核心的拦截器代码逻辑是这样的：

@Component public class JwtAuthenticationInterceptor implements HandlerInterceptor { @Resource private StringRedisTemplate stringRedisTemplate; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 if (handler instanceof HandlerMethod) { HandlerMethod handlerMethod = (HandlerMethod) handler; if (handlerMethod.hasMethodAnnotation(PassToken.class)) { return true; } // 校验Token String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token) || !token.startsWith("Bearer ")) { throw new BusinessException(401, "未登录或登录已过期"); } token = token.substring(7); Claims claims = JwtUtil.parseToken(token); if (claims == null) { throw new BusinessException(401, "Token无效"); } // 检查Redis中是否存在，实现单点登录效果 String redisKey = "login:token:" + claims.get("userId"); String cacheToken = stringRedisTemplate.opsForValue().get(redisKey); if (!token.equals(cacheToken)) { throw new BusinessException(401, "账号已在其他设备登录"); } // 将用户信息放入ThreadLocal，供后续业务代码获取当前用户 UserContext.set(UserContext.parseUser(token)); return true; } return true; } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }

角色鉴权我采用自定义注解结合AOP实现。在Controller方法上标注@RequireRole("NURSE")，AOP切面判断当前用户的角色是否匹配，不匹配直接抛出403异常，由全局异常处理器统一返回JSON。这样权限控制的粒度可以精确到每个接口，配置起来也很直观。

这里有个我需要特别强调的坑：JWT的基础特性是无状态的，但实际业务往往需要“踢人下线”或“强制Token失效”的能力，所以我把Token同步了一份到Redis，设置了和JWT过期时间一致的TTL。每次请求校验时先看Redis里有没有这个Token，没有就直接拒绝。这个方案牺牲了一点“纯无状态”的优雅，但管理性和安全性好了很多。

3.2 生命体征采集接口与趋势分析实现

生命体征采集是护士使用频率最高的功能，高频操作要求接口响应要快。我设计的主接口是POST /api/vital-signs，请求体里携带患者ID、住院记录ID、采集时间以及各项生命体征指标。护士在科室通过平板或PDA录入，每次提交都会校验患者是否处于“在科”状态，防止给已转出患者录数据。

对于体温单这种需要图形化展示的场景，前端调用趋势分析接口获取最近7天或最近24小时的数据。后端实现时我用了一个比较直接的方案，按小时维度分组聚合：

public List<Map<String, Object>> analyzeVitalSigns(String hospitalizationId, String startTime, String endTime) { List<VitalSignsRecord> records = vitalSignsMapper.selectList( new LambdaQueryWrapper<VitalSignsRecord>() .eq(VitalSignsRecord::getHospitalizationId, hospitalizationId) .between(VitalSignsRecord::getCollectedAt, startTime, endTime) .orderByAsc(VitalSignsRecord::getCollectedAt) ); // 按小时分组，每组取均值，跨天时记录日期边界 Map<String, List<VitalSignsRecord>> grouped = records.stream() .collect(Collectors.groupingBy(r -> DateUtil.format(r.getCollectedAt(), "yyyy-MM-dd HH:00:00"))); List<Map<String, Object>> result = new ArrayList<>(); for (Map.Entry<String, List<VitalSignsRecord>> entry : grouped.entrySet()) { Map<String, Object> point = new HashMap<>(); point.put("time", entry.getKey()); point.put("avgHeartRate", entry.getValue().stream().mapToInt(VitalSignsRecord::getHeartRate).average().orElse(0)); point.put("avgBloodPressure", entry.getValue().stream().mapToDouble(VitalSignsRecord::getSystolicPressure).average().orElse(0)); // 其他指标同理 result.add(point); } return result; }

前端用ECharts绘制折线图，纵轴是心率或血压值，横轴是时间点。多个指标可以在同一图表上叠加展示，方便医生快速发现异常趋势。对于异常体征的预警，我在接口层加了一个简单规则引擎：心率低于50或高于140、血氧饱和度低于90%等条件触发时，接口直接返回warningLevel字段，前端弹窗提示护士及时处理。

这里我建议大家不要在业务代码里散落一堆if判断来做预警，而是把预警规则集中维护。我在项目里把规则放进了数据库字典表，后续调整阈值不用改代码重新部署。对于ICU这种场景，监护仪本来自带报警，系统的预警更多是作为二次确认和记录，所以规则不需要太复杂。

3.3 护理记录单的生成与修改逻辑

电子护理记录单是整个系统的“门面”，因为护长和医生每天查看次数最多的就是这份文档。我设计了生成规则：每晚20点系统自动为每位在科患者生成第二天的空白护理记录单，初始状态为“草稿”。护士在值班过程中随时录入护理措施和观察结果，录入后记录单状态变为“填写中”，交班或者下班前点击“提交”，提交后护士长进行审核，审核通过后记录单不可再修改。

技术层面需要重点处理的是“提交后修改”场景。按照医疗合规要求，审核后的记录单不能直接改原记录，只能新增一条“更正记录”。我实现的做法是记录单主表里加一个revision字段，每更正一次revision加1，原数据保存在历史表中。查询的时候默认显示最新版本，需要追溯时可以查看历史版本对比。

这个逻辑在实现时要额外注意并发问题。比如两个护士同时提交同一个患者同一天的记录单，主表的revision就可能产生冲突。我的解决方案是在更新语句中加乐观锁条件：UPDATE nursing_record SET revision = revision + 1 WHERE id = ? AND revision = ?，如果影响行数为0，说明被其他事务提前更新了，当前请求重新拉取最新数据再合并提交。MyBatis Plus自带的@Version注解可以直接支持这个功能，不需要手写SQL。

3.4 医嘱执行闭环与排班管理实现

医嘱闭环是ICU系统里最能体现“管理价值”的功能。医生开立医嘱后，医嘱状态是“未审核”，护士长审核通过后变成“待执行”，责任护士在系统中领取任务并执行，执行时填写实际执行时间、执行情况和用药/操作备注，执行完成后状态变为“已执行”。如果医嘱需要停止，比如患者转出ICU或者病情变化，医生操作停止后，系统会校验是否有未完成的执行任务，有的话会弹出提示，防止有操作被遗漏。

排班管理模块我采用的是模板加规则的方式。每个月的排班不能纯靠护士长手动拖拽，太浪费时间。系统内置了几种常见排班模式：白班、小夜班、大夜班、休息，护士长可以按周模板复制到整月，然后针对个别日期手动调整。排班结果保存后，每个护士登录系统首页就能看到自己本周的班次。

排班模块还有一个隐藏需求是工时统计。ICU工作强度大，护士长需要定期统计每个人的夜班数量和总工时，用于绩效核算。这个功能我在排班表里增加了一个班次类型编码字段，统计时按编码分组聚合，一个SQL就能出结果。如果不提前设计这个字段，后面想加统计功能就要改表、改接口、改前端，工作量完全不一样。

3.5 消息提醒与WebSocket推送

ICU系统对实时性的要求还体现在消息推送。新的医嘱开立、患者体征异常、排班调整、审核结果返回，这些事件都需要第一时间通知到相关护士。我在这套系统里接入了WebSocket，后端事件触发时向特定用户或特定角色推送消息。

WebSocket在Spring Boot里的实现方式不算复杂，核心是配置一个TextWebSocketHandler，前端通过/ws?token=xxx建立连接。用户身份从连接参数中的Token解析，后端维护一个userId到WebSocketSession的映射。事件触发点统一放在Service层，比如医嘱状态变更后调用MessagePushUtil.pushToUser(userId, message)，由工具类遍历该用户所有活跃的WebSocketSession并发送消息。

还要提醒一下WebSocketSession的并发安全问题。一个用户可能开多个浏览器标签页，也就是一个userId对应多个Session，而且Session的发送操作不是线程安全的。我用了ConcurrentHashMap来维护Session集合，发送时对每个Session加锁，避免并发写入导致的异常。不处理这个问题，上线后会出现偶发性的消息丢失或者连接中断。

4. 系统安全、性能优化与部署上线

4.1 安全加固：参数校验、XSS防护与数据权限

医疗系统的数据安全级别要求比其他业务系统高出一截，这块我在设计和编码阶段下了不少功夫。

参数校验方面，后端所有接收前端参数的实体类都加上了Jakarta Validation注解，比如 @NotBlank、@Pattern、@Size，Controller入口由@Validated触发校验，校验失败会自动抛出MethodArgumentNotValidException，由全局异常处理器统一转换为友好提示。前端的表单校验只是提升用户体验，真正的防线必须放在后端，这句话在医疗系统里尤其重要。

XSS防护方面，我写了一个全局过滤器，对请求体中的字符串参数进行HTML标签清洗，把