在医疗信息化高速发展的今天,门诊流程的优化是提升医院服务效率与患者满意度的关键环节。传统的人工分诊模式依赖护士经验,易导致患者排队时间长、队列不透明、急诊与普通患者混杂等问题。针对这些痛点,设计并实现了一套基于SSM(Spring + Spring MVC + MyBatis)架构的智能分诊管理平台,旨在通过数字化、智能化的手段,重塑门诊就诊流程。
该平台构建了患者、分诊护士、科室医生及系统管理员四类核心用户的完整操作闭环。分诊护士通过系统快速录入患者主诉与基本信息,系统依据预设规则自动推荐就诊科室与优先级;医生在诊室终端可清晰查看待诊队列,系统支持灵活的叫号与过号处理;管理员则负责维护科室、医生等基础数据。整个流程数据实时同步,队列状态可视化,有效减少了患者无效等待时间,实现了医疗资源的精准调度。
技术架构选型与设计
平台采用经典的三层架构模式,确保系统的高内聚、低耦合与可扩展性。
- 表现层:基于Spring MVC框架构建,采用注解驱动的控制器(
@Controller)来处理所有Web请求。通过配置InternalResourceViewResolver视图解析器,实现JSP页面的渲染。对于异步交互,控制器方法使用@ResponseBody注解直接返回JSON数据,为前端提供RESTful风格的数据接口,确保了前后端分离的协作效率。 - 业务逻辑层:由Spring Framework的IoC(控制反转)容器负责管理所有Service组件的生命周期和依赖关系。利用Spring的声明式事务管理(
@Transactional),对分诊、叫号等核心业务操作进行事务边界划定,确保了在多步骤数据操作下的原子性与一致性。 - 数据持久层:选用MyBatis作为ORM框架,其半自动化的特性提供了极大的SQL编写灵活性。通过XML映射文件(Mapper XML)集中管理所有SQL语句,实现了动态SQL、结果集映射、关联查询等复杂功能,与MySQL数据库进行高效、可靠的交互。
项目采用Maven进行依赖管理,清晰地定义了各层之间的依赖关系。web.xml中配置了DispatcherServlet作为前端控制器,并设置了字符编码过滤器以解决中文乱码问题。Spring的配置文件(applicationContext.xml)整合了组件扫描、事务管理、数据源以及MyBatis的SqlSessionFactoryBean等核心配置。
核心数据库表结构设计剖析
数据库设计是系统稳定性的基石。该平台共设计了22张数据表,以下详细分析其中几个关键表的设计亮点。
1. 患者信息表(patient):实现信息的高效复用与一致性
患者信息是系统的核心数据实体。其表结构设计不仅考虑了单次就诊的需求,更着眼于患者全生命周期信息的连贯性。
CREATE TABLE `patient` (
`patient_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '患者ID',
`patient_name` varchar(50) NOT NULL COMMENT '患者姓名',
`gender` char(1) NOT NULL COMMENT '性别(0男 1女)',
`age` int(11) NOT NULL COMMENT '年龄',
`id_card` varchar(18) DEFAULT NULL COMMENT '身份证号',
`phone` varchar(11) DEFAULT NULL COMMENT '手机号码',
`address` varchar(200) DEFAULT NULL COMMENT '住址',
`create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
PRIMARY KEY (`patient_id`),
UNIQUE KEY `uk_id_card` (`id_card`),
KEY `idx_phone` (`phone`),
KEY `idx_name` (`patient_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='患者信息表';
- 设计亮点:
- 唯一身份标识:通过
id_card字段建立唯一索引(uk_id_card),确保每位患者在医院系统中只有一份主档案。当患者再次就诊时,分诊护士可通过身份证号快速调取历史信息,避免了信息重复录入,保证了数据一致性。 - 高效的查询优化:为
phone和patient_name字段建立了普通索引(idx_phone,idx_name),显著提升了通过手机号或姓名进行模糊查询的性能,尤其在快速寻人、电话回访等场景下至关重要。 - 审计追踪:
create_time和update_time字段自动记录数据的创建和最后修改时间,便于数据追踪与审计。
- 唯一身份标识:通过
2. 分诊队列表(triage_queue):核心业务的状态机管理
分诊队列表是系统业务流程的引擎,它动态地记录了患者从分诊到就诊完成的全过程状态。
CREATE TABLE `triage_queue` (
`queue_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '队列ID',
`patient_id` int(11) NOT NULL COMMENT '患者ID',
`dept_id` int(11) NOT NULL COMMENT '科室ID',
`doctor_id` int(11) DEFAULT NULL COMMENT '医生ID',
`priority_level` tinyint(4) NOT NULL COMMENT '优先级(1普通 2紧急 3危急)',
`status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态(1待诊 2诊中 3已完成 4已过号)',
`queue_number` int(11) NOT NULL COMMENT '队列序号',
`triage_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '分诊时间',
`call_time` datetime DEFAULT NULL COMMENT '叫号时间',
`complete_time` datetime DEFAULT NULL COMMENT '完成时间',
PRIMARY KEY (`queue_id`),
KEY `idx_dept_status` (`dept_id`,`status`),
KEY `idx_doctor_status` (`doctor_id`,`status`),
KEY `idx_patient` (`patient_id`),
CONSTRAINT `fk_queue_patient` FOREIGN KEY (`patient_id`) REFERENCES `patient` (`patient_id`),
CONSTRAINT `fk_queue_dept` FOREIGN KEY (`dept_id`) REFERENCES `department` (`dept_id`),
CONSTRAINT `fk_queue_doctor` FOREIGN KEY (`doctor_id`) REFERENCES `doctor` (`doctor_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='分诊队列表';
- 设计亮点:
- 复合索引优化:创建了
idx_dept_status和idx_doctor_status等复合索引。这使得查询某个科室下所有“待诊”状态的患者,或某位医生名下“诊中”的患者时,数据库可以直接利用索引定位数据,避免了全表扫描,性能极高。 - 外键约束保证数据完整性:通过外键约束(
fk_queue_patient等),确保了队列中的患者、科室、医生信息必然存在于主表中,防止了“脏数据”的产生。 - 状态与时间轴:
status字段清晰地定义了患者所处的流程节点,结合triage_time,call_time,complete_time等时间戳,可以精确统计患者等候时长、医生接诊效率等关键运营指标。
- 复合索引优化:创建了
3. 用户表(user):基于角色的权限控制基础
用户表的设计支撑了系统的多角色登录与权限管理体系。
CREATE TABLE `user` (
`user_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户ID',
`username` varchar(50) NOT NULL COMMENT '用户名',
`password` varchar(100) NOT NULL COMMENT '密码',
`real_name` varchar(50) NOT NULL COMMENT '真实姓名',
`role` tinyint(4) NOT NULL COMMENT '角色(1管理员 2护士 3医生)',
`is_active` tinyint(1) DEFAULT '1' COMMENT '是否启用(0否 1是)',
`last_login_time` datetime DEFAULT NULL COMMENT '最后登录时间',
PRIMARY KEY (`user_id`),
UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='系统用户表';
该表通过role字段区分用户角色,is_active字段允许软删除(禁用)用户账号而非物理删除,last_login_time用于安全审计。密码字段varchar(100)的长度预留了使用Spring Security等安全框架进行加密(如BCrypt)后的存储空间。
核心功能模块实现解析
1. 智能分诊与队列管理
分诊是流程的起点。护士录入患者症状后,系统根据规则(如关键词匹配、预设科室关联)智能推荐科室,护士确认后,系统自动生成一个队列号并插入triage_queue表。
Service层核心逻辑 (TriageServiceImpl.java):
@Service
@Transactional
public class TriageServiceImpl implements TriageService {
@Autowired
private TriageQueueMapper triageQueueMapper;
@Autowired
private DepartmentMapper departmentMapper;
@Override
public ApiResult addPatientToQueue(TriageQueue triageQueue) {
// 1. 参数校验
if (triageQueue.getPatientId() == null || triageQueue.getDeptId() == null) {
return ApiResult.error("患者ID和科室ID不能为空");
}
// 2. 生成队列号:查找该科室当前最大队列号,并+1
Integer currentMaxNumber = triageQueueMapper.selectMaxQueueNumberByDept(triageQueue.getDeptId());
int newQueueNumber = (currentMaxNumber == null) ? 1 : currentMaxNumber + 1;
triageQueue.setQueueNumber(newQueueNumber);
// 3. 设置初始状态为“待诊”
triageQueue.setStatus(TriageStatus.WAITING.getCode());
triageQueue.setTriageTime(new Date());
// 4. 持久化到数据库
int result = triageQueueMapper.insertSelective(triageQueue);
if (result > 0) {
return ApiResult.success("分诊成功", newQueueNumber);
} else {
return ApiResult.error("分诊失败");
}
}
}
队列管理界面为护士提供了清晰的视图。
如上图所示,界面以列表形式展示了当前各科室的排队情况,包括患者姓名、优先级、队列号、状态等。护士可以在此界面进行叫号、过号等操作,操作后数据库中的status和call_time等字段会实时更新。
2. 医生叫号接口实现
医生登录系统后,其工作台主要显示指派给自己的待诊患者列表。点击“叫号”后,系统更新队列状态并可能通过接口驱动物理叫号屏。
Controller层接口 (DoctorController.java):
@RestController
@RequestMapping("/api/doctor")
public class DoctorController {
@Autowired
private TriageService triageService;
@PostMapping("/callNext")
public ApiResult callNextPatient(@RequestParam Integer doctorId) {
// 1. 查询该医生下状态为“待诊”的第一个患者(按优先级和队列号排序)
TriageQueue nextPatient = triageService.selectNextWaitingPatient(doctorId);
if (nextPatient == null) {
return ApiResult.error("暂无待诊患者");
}
// 2. 更新该患者状态为“诊中”,并记录叫号时间
nextPatient.setStatus(TriageStatus.IN_CONSULTATION.getCode());
nextPatient.setCallTime(new Date());
int updateResult = triageService.updateQueueStatus(nextPatient);
if (updateResult > 0) {
// 3. 成功后可集成WebSocket或第三方API进行语音/屏幕叫号
// notificationService.callPatient(nextPatient);
return ApiResult.success("叫号成功", nextPatient);
} else {
return ApiResult.error("叫号失败");
}
}
}
对应的MyBatis Mapper XML查询 (TriageQueueMapper.xml):
<!-- 查询下一个待诊患者 -->
<select id="selectNextWaitingPatient" resultMap="BaseResultMap" parameterType="java.lang.Integer">
SELECT
<include refid="Base_Column_List"/>
FROM triage_queue
WHERE doctor_id = #{doctorId, jdbcType=INTEGER}
AND status = 1 <!-- 状态为待诊 -->
ORDER BY priority_level DESC, queue_number ASC
LIMIT 1
</select>
此SQL查询充分利用了idx_doctor_status索引,并通过ORDER BY子句实现了按优先级(紧急优先)和队列号(先到先得)的排序,确保了分诊的公平性与紧急性。
3. 患者信息管理
系统提供了完善的患者信息增删改查功能。下图展示了患者管理列表界面,支持按姓名、手机号等条件查询。
其对应的数据查询Mapper如下:
// Mapper接口中的方法
List<Patient> selectByCondition(@Param("patientName") String patientName, @Param("phone") String phone);
<!-- 动态SQL查询,支持条件筛选 -->
<select id="selectByCondition" resultMap="BaseResultMap">
SELECT * FROM patient
<where>
<if test="patientName != null and patientName != ''">
AND patient_name LIKE CONCAT('%', #{patientName}, '%')
</if>
<if test="phone != null and phone != ''">
AND phone = #{phone}
</if>
</where>
ORDER BY create_time DESC
</select>
MyBatis的动态SQL功能使得查询构建非常灵活,当查询条件为空时,SQL会自动退化为查询全部,简化了代码编写。
4. 系统管理与数据维护
管理员角色负责维护系统的基础数据,如科室信息、医生信息、用户账号等。
这些管理功能通常涉及简单的CRUD操作,但其实现同样注重事务性与数据完整性。例如,删除一个科室前,需要检查triage_queue等表中是否存在关联数据,必要时使用事务保证关联删除或提示无法删除。
实体模型与对象映射
系统使用JavaBean作为实体模型,与数据库表结构一一对应,并通过MyBatis的ResultMap进行精确映射。以患者实体为例:
public class Patient {
private Integer patientId;
private String patientName;
private String gender;
private Integer age;
private String idCard;
private String phone;
private String address;
private Date createTime;
private Date updateTime;
// getters and setters...
}
这种清晰的映射关系,使得业务逻辑层可以完全面向对象进行编程,数据持久层则负责对象与关系数据的转换,符合软件工程的设计原则。
未来优化方向与功能展望
- 集成实时通信技术:引入WebSocket协议,实现服务器与护士站、医生工作站、候诊区大屏之间的全双工实时通信。当队列状态发生变化(如叫号、过号)时,系统可主动推送更新到所有客户端,无需页面轮询,实现真正的实时刷新。
- 强化智能分诊引擎:当前分诊规则相对简单。未来可引入自然语言处理(NLP)技术,对患者的主诉文本进行更深度的语义分析,或构建一个基于历史诊断数据的机器学习模型,从而提供更精准的科室推荐,降低误分诊率。
- 移动端应用开发:开发面向患者的微信小程序或APP。患者可在线完成分诊前的信息填报、查看实时排队进度、接收叫号提醒等,将线下排队环节线上化,进一步改善就医体验。
- 数据可视化与决策支持:基于积累的分诊队列数据,开发院长驾驶舱功能。通过ECharts等图表库可视化展示各科室在不同时间段的接诊量、患者平均等候时长、峰值压力等关键指标,为医院管理层的资源调配和流程优化提供数据支撑。
- 与HIS/LIS/PACS系统深度集成:作为门诊流程管理系统,未来需要与医院现有的医院信息系统(HIS)、实验室信息系统(LIS)、影像归档和通信系统(PACS)等进行接口对接,实现患者信息、检查检验报告、医学影像的互联互通,构建一体化的临床信息工作流。
总结
该智能分诊管理平台成功地将SSM框架的优势应用于医疗信息化实践。通过严谨的三层架构设计、精心优化的数据库表结构以及清晰的核心业务逻辑实现,构建了一个稳定、高效、易扩展的门诊流程管理系统。它不仅解决了传统分诊模式的固有弊端,显著提升了医院运营效率,其模块化设计与清晰的代码结构也为后续的功能迭代与系统集成奠定了坚实的技术基础。该平台的实现范式对于开发同类企业管理信息系统具有良好的参考价值。