简介《医院管理系统——软件工程课程设计》是一份以医院管理系统为实战案例的软件工程课程设计文档适合软件工程专业学生及正在完成课程设计的开发者参考。资源仅包含1个doc文档压缩包整体约279KB但内容覆盖从项目背景、可行性分析到功能模块与业务流程设计的完整链路。文档以第二章需求分析为主体对经济和技术可行性、用例图、字典维护、门诊挂号、划价收费、门诊/住院医生工作站、住院病人及费用管理、药房管理等模块逐一展开第三章还给出系统关系图与数据表设计并配有门诊、住院、药房等关键业务流程图能帮助读者理解从需求收集到数据库设计的软件工程全过程。目前已有103人学习该文档。对需要完成类似课程设计、掌握需求分析方法或参考系统设计文档结构的读者来说这份资料提供了一份结构规范的范例能辅助理清文档撰写思路与业务建模要点。1. 医院管理系统课程设计为什么它是软件工程实践的标准题信息科学与技术学院《软件工程》课程设计选医院管理系统HIS作为题目这不算新鲜却非常耐做。HIS 天然覆盖了需求分析、用例建模、数据库设计、业务流程梳理、模块划分、实现与测试的完整生命周期而且业务边界清晰、角色明确比图书管理系统更容易讲深又不像电商系统那样涉及大量非功能性技术。这份文档采用的是 Delphi SQL Server 2000 的组合整体设计思路是典型的 C/S 架构客户端负责界面交互和业务逻辑数据库负责数据存储与一致性保障。文中列出的九大功能模块、五个核心业务流程图和十余张数据表构成了一套可以照着复现的 HIS 基础模型。对于正在做软件工程课程设计、软件工程大作业或者准备软件工程毕业设计选题的人来说这份文档的价值在于它展示了需求到实现的完整映射过程而不是某一段具体的代码。2. 功能模块拆解与用例建模从九大模块到角色权限边界2.1 系统整体架构与模块划分逻辑文档把医院管理系统划分为系统字典维护、门诊挂号系统、门诊划价收费系统、门诊医生工作站、住院病人管理系统、病案病历管理系统、住院费用管理系统、住院医生工作站、药房管理系统、其他统计财务模块十个部分。这个划分有一个非常值得注意的地方它是按「业务域」而不是按「用户角色」来拆的。门诊医生工作站和住院医生工作站虽然面向的都是医生但拆成了两个独立模块原因在于门诊和住院的业务流程完全不同。门诊是当天完成「挂号—就诊—缴费—取药」的短闭环住院则是跨天的长流程涉及床位管理、押金、每日费用记账、医嘱执行等多个环节。做课程设计时如果按角色拆模块很容易把业务逻辑纠缠在一起按业务域拆每个模块的边界就清楚了。表 2-1 整理了文档中提到的模块与对应核心职责这份表可以直接用于需求文档的功能概述部分。模块名称核心职责关键数据对象系统字典维护维护药品、科室、员工、疾病分类等基础数据药品字典、科室字典、员工字典门诊挂号系统建立病人主索引、分配ID、挂号和预约号病人信息库、门诊挂号门诊划价收费系统药品划价、收费、收据处理、退退款门诊划价、门诊划价明细门诊医生工作站病历填写、医嘱开立、辅助诊断查询病历记录、医嘱住院病人管理系统入院登记、床位调配、转科转床、退院病人住院首页、床位信息住院费用管理系统预缴金、固定费用、结算、日清月结费用账单、预缴金账户住院医生工作站住院病历、医嘱开立与执行住院病历、医嘱药房管理系统采购、入库、出库、盘点、报损、效期预警药品库存、出入库单病案病历管理系统病案首页生成、历史病案检索病案首页统计财务模块工作量统计、收入核算、财务报表挂号量统计、收费汇总2.2 门诊三条主线的协作关系门诊业务是 HIS 中最核心也最复杂的流程。文档在 2.2.3 到 2.2.5 中分别描述了门诊挂号、门诊划价收费和门诊医生工作站但三者的协作关系需要单拎出来看。病人在挂号窗口办理就诊卡系统分配临时 ID打印带条码的门诊挂号单这是整个门诊流程的起点。持卡病人到诊室后医生通过门诊医生工作站调取病人的挂号信息和既往病史在计算机上直接录入电子医嘱。划价收费处不再需要手工录入处方直接通过挂号单条码或病人 ID 调出医生的电子医嘱进行计价、收费和收据打印。最后药房管理系统根据已收费的医嘱预先打印发药明细把药品备好病人到窗口直接取药。门诊挂号分配ID→ 医生工作站电子医嘱→ 划价收费调医嘱计价→ 药房发药预发货这种流程设计的核心是把「医嘱」作为贯穿门诊业务的主线数据。挂号产生病人身份标识医生工作站产生医嘱划价收费系统读取医嘱并生成费用记录药房根据收费状态执行发药。文档在 2.2.5 里特别强调「划价时可以直接调出电子医嘱」这说明在作者的设计中电子医嘱是门诊划价系统的数据源而不是划价员重新录入药品项目。2.3 用例建模与角色权限文档的图 2-2 给出了病人用例图涉及角色包括病人、门诊办事员、医生、药房办事员。结合各功能模块的职责可以补全完整的角色权责表角色可执行用例禁止操作病人挂号、看病、划价付费、取药无任何写权限挂号员建卡、挂号、预约号处理不能修改医嘱和费用医生开医嘱、写病历、查询检查结果不能直接操作收费和发药划价收费员计价、收费、退费、收据打印不能修改药品价格字典药房管理员发药、盘点、报损、采购入库不能执行退费操作用例图的边界说明了一个问题HIS 的权限控制不只是「谁能登录」而是「谁能改哪张表」。比如医生工作站只能写入医嘱表和病历表没有权限修改划价金额和药品库存药房管理员只能看到已收费的处方不能看到未缴费的划价单。做软件工程课程设计答辩时能够解释清楚这个权限映射关系比背出十个模块的名称更有说服力。2.4 医生工作站的分层建设思路文档在 2.2.5 中写道「门诊医生工作站是医院管理系统的比较高层次的应用功能一般医院的管理都达不到应用的要求」。这句话其实在描述 HIS 行业的分期建设模式医院信息化通常先上线收费、挂号、药房等基础业务系统解决钱和药的流转问题医生工作站属于临床信息系统CIS需要医生具备计算机操作习惯、病历模板库、医嘱知识库等配套条件才能发挥价值。做课程设计时不要把医生工作站做成简单的增删改查页面。至少要体现两个设计点一是医嘱的输入方式文档中提到医嘱直接输入到计算机而不是写在药方上这意味着要设计医嘱录入界面和医嘱模板二是医嘱的状态流转从开立到执行到停止需要字段来标记状态比如advice_status。这两点在答辩时属于加分项。3. 数据库建模实践从表格记录到可复现的建表 SQL3.1 核心数据表主数据类表的 SQL 设计文档 3.2 节给出了医生资料、病人信息库、科室资料、药品分类、药品库存、药品资料、门诊划价、门诊划价明细、门诊挂号九张表的结构字段类型和长度都标得很细。这份建表记录可以直接转成 SQL 脚本。下面是主数据类表的建表语句CREATE TABLE doctor_info ( doctor_id VARCHAR(20) PRIMARY KEY, -- 医生编号主键 doctor_name VARCHAR(30) NOT NULL, -- 医生姓名 dept_name VARCHAR(30), -- 科室名称 dept_id VARCHAR(20), -- 科室编号 position VARCHAR(20), -- 职务主任、主治、住院医师 phone VARCHAR(15) -- 联系电话 ); CREATE TABLE patient_info ( patient_id VARCHAR(20) PRIMARY KEY, -- 病人编号主键 patient_name VARCHAR(30) NOT NULL, -- 病人姓名 gender VARCHAR(2), -- 性别男/女 age INT, -- 年龄 ethnicity VARCHAR(20), -- 民族 cost_type VARCHAR(20), -- 费用类型自费/医保/公费 phone VARCHAR(15), -- 联系电话 pinyin_code VARCHAR(5) -- 拼音码用于快速检索 ); CREATE TABLE dept_info ( dept_id VARCHAR(20) PRIMARY KEY, -- 科室编号 dept_name VARCHAR(30) NOT NULL -- 科室名称 ); CREATE TABLE drug_category ( id VARCHAR(20), -- 分类编号 name VARCHAR(150), -- 分类名称 type VARCHAR(50) -- 类别 ); CREATE TABLE drug_stock ( id VARCHAR(20) PRIMARY KEY, -- 库存记录编号 name VARCHAR(150), -- 药品名称 warehouse VARCHAR(100), -- 库房名称 drug_id VARCHAR(20) NOT NULL, -- 关联药品资料表的编号 quantity INT NOT NULL, -- 当前库存数量 remark VARCHAR(100) -- 备注 );pinyin_code是这套表设计里的一个亮点。HIS 系统每天录入大量病人信息中文姓名直接检索效率不高拼音码可以支持输入首字母快速定位病人。比如有人叫「张三」拼音码存zs挂号员录入zs就能检索到历史患者避免重复建卡。这个字段在文档的字段清单里只有varchar(5)的长度但对于教学型项目来说能想到这个设计说明需求分析做得比较细。3.2 药品资料为什么要拆成三张表药品相关的表在文档中拆成了药品分类、药品资料、药品库存三张这个拆分逻辑值得展开说明。药品分类表保存的是分类层级比如「抗生素类」「心血管类」用id和type两个字段来标识。药品资料表存的是药品的静态属性包括规格、单位、价格、效期、上下限其中integra_unit整量单位和fractional_unit散量单位以及integra_ratio整散比非常关键医院里有的药按盒发、有的按片发比如一盒 24 片整散比就是 24发药时如果库存只剩半盒系统要知道如何折算数量。validity_period效期和stock_limit_up/down库存上下限则用于近效期预警和库存下限报警。药品库存表存的是动态数量通过drug_id关联药品资料。把静态资料和动态库存分开的原因在于药品价格调整、规格变更时只需要改药品资料表不影响现有的库存记录而每次出入库操作只改动库存表的quantity字段。如果药品资料和库存放在一张表里一次调价就要批量更新所有库存记录逻辑上会乱。药房管理系统中提到的「效期提示」和「底限报警」功能对应到数据表就是两条 SQL-- 效期提示查找 90 天内过期的药品 SELECT d.name, d.validity_period, s.quantity FROM drug_info d JOIN drug_stock s ON d.drug_id s.drug_id WHERE DATEDIFF(day, GETDATE(), d.validity_period) 90; -- 底限报警查找库存低于下限的药品 SELECT d.name, d.stock_limit_down, s.quantity FROM drug_info d JOIN drug_stock s ON d.drug_id s.drug_id WHERE s.quantity d.stock_limit_down;这两条查询在答辩演示时非常实用能直观展示课程设计不是停留在界面层而是深到了业务逻辑层。注意DATEDIFF(day, ...)是 SQL Server 的语法如果迁移到 MySQL 需要改成DATEDIFF(d.validity_period, NOW())。3.3 门诊划价的头表明细结构与状态字段门诊划价模块是整套系统中最能体现表结构设计功底的部分。文档把门诊划价拆成了主表clinic_pricing和从表clinic_pricing_detail这属于典型的「头表明细」模式CREATE TABLE clinic_pricing ( pricing_id VARCHAR(20) PRIMARY KEY, -- 划价编号主键 dept_name VARCHAR(30), -- 就诊科室名称 reg_id VARCHAR(15), -- 关联门诊挂号表 doctor_name VARCHAR(30), -- 医生姓名 pricing_time DATETIME NOT NULL, -- 划价时间 pricer VARCHAR(10), -- 划价员 is_charged VARCHAR(2) DEFAULT 否, -- 是否已收费 cashier VARCHAR(10), -- 收费员 charge_time DATETIME, -- 收费时间 total_amount MONEY, -- 划价总金额 is_dispensed VARCHAR(2) DEFAULT 否, -- 是否已发药 dispense_time DATETIME, -- 发药时间 dispenser VARCHAR(10) -- 发药员 ); CREATE TABLE clinic_pricing_detail ( detail_id VARCHAR(20) NOT NULL, -- 明细编号 pricing_id VARCHAR(20) NOT NULL, -- 划价编号关联主表 drug_id VARCHAR(20) NOT NULL, -- 药品编号 unit_price DECIMAL(9,2), -- 单价 quantity DECIMAL(9,2), -- 数量 amount DECIMAL(9,2), -- 金额 PRIMARY KEY (detail_id, pricing_id) );主表clinic_pricing的核心设计是is_charged和is_dispensed两个状态字段。用CHAR(1)的0/1比VARCHAR(2)的否/是更节省存储但文档选择了可读性更好的文本值。这两个字段直接串起了整个门诊流程划价员创建划价单时is_charged 否收费完成后置为是并记录收费员和收费时间药房只能看到is_charged 是的划价单来备药发药发药完成后再把is_dispensed置为是。明细表用pricing_id关联主表药品项目都记录在明细中。总金额total_amount是冗余字段可以快速展示划价总额不用每次 SUM 明细表。查询任一环节卡住的数据只需要一条关联语句-- 查询已划价、未收费的单据 SELECT p.pricing_id, p.dept_name, p.doctor_name, p.total_amount FROM clinic_pricing p WHERE p.is_charged 否; -- 查询已收费、未发药的明细 SELECT d.pricing_id, d.drug_id, d.quantity FROM clinic_pricing p JOIN clinic_pricing_detail d ON p.pricing_id d.pricing_id WHERE p.is_charged 是 AND p.is_dispensed 否;这套头表明细设计在数据库课程设计和真实 HIS 项目中都是标准做法答辩时可以拿它来回答「如何在保证数据完整性的同时提高查询效率」这类问题。3.4 从 SQL Server 2000 迁移到现代数据库的注意事项文档中的数据类型基于 SQL Server 2000做软件工程课程设计时如果改用 MySQL 或 PostgreSQL有几个字段需要处理。money类型在 SQL Server 2000 里占有 8 字节但它在 MySQL 中没有对应类型建议直接用DECIMAL(10,2)DATETIME在 PostgreSQL 中建议改为TIMESTAMP主键VARCHAR(20)对于课程设计完全够用但真实生产环境中一般会用自增INT或 UUID避免病人量大的时候出现主键冲突。4. 业务流程梳理与状态设计门诊、住院、出院结算的流转逻辑4.1 门诊业务的完整状态流转文档的图 2-11 描述了门诊业务流程制作病人身份卡 → 挂号 → 首次确诊/复诊 → 确认身份卡 → 开检查处方 → 交款 → 检查检验 → 取药。把这个流程放到数据库层面等价于状态窗口的逐步推进步骤操作角色数据表写入状态变化建卡挂号员patient_info创建病人主索引挂号挂号员clinic_registration生成挂号编号分配就诊科室开医嘱医生医嘱表、病历表生成电子医嘱划价划价员clinic_pricingclinic_pricing_detailis_charged 否收费收费员clinic_pricingis_charged 是记录收费时间发药药房管理员clinic_pricing、drug_stockis_dispensed 是扣减库存值得关注的是「退费」环节文档在门诊划价收费系统的功能模块中列出了「收退款」和「退退款」。退费的常见做法是先校验is_dispensed字段如果药品已经发出需要药房先做退药操作只有is_dispensed 否或者退药完成后才能执行退费。这个逻辑在课程设计文档里可能只需一行「退退款」的描述但实现时对应的是多条 SQL 的事务控制。4.2 住院业务流程押金、床位与医嘱执行住院业务比门诊复杂的地方在于引入了「押金」和「床位」两个概念。文档图 2-13 的住院流程是入院登记 → 收取押金 → 安排床位 → 下医嘱 → 执行医嘱 → 提药 → 费用记账。每个环节都需要相应的数据支撑入院登记时系统需要判断病人是否为首次住院。文档 2.2.6 写得明确首次住院分配新住院号非首次住院则通过病案管理系统检索已有住院号在原有编号下新建病案首页。这个逻辑避免同一个病人产生多个主索引是 HIS 数据质量的关键。实现时可以加一个visit_count字段判断首次或者查hosp_admission表中是否已有该病人编号的记录。押金处理对应住院费用管理系统中的「预缴金处理」和「病人资金账户管理」。费用记账发生在护士执行医嘱之后后台数据库批量写入费用记录日清、月结报表汇总当日费用。这里有一个隐藏的需求住院费用是每晚结算一次还是实时累计文档 2.2.7 列出的「固定费用处理」指的是床位费和护理费这类按日计费的项目它们可以在每天固定的时间点批量生成费用记录而不是每次操作都写账单。4.3 出院结算的三种模式与数据一致性出院结账流程在文档图 2-14 中展示了挂账结算、中途结算、清帐结算三种模式。三种模式对应不同的业务场景结算模式适用场景数据操作挂账结算医保病人或公费病人生成应收账单标记挂账后续与医保中心结算中途结算病人住院期间先结算一部分费用按时间段计算费用补交或退差额清帐结算病人正常出院打印全额发票结清所有费用完成退院处理三种结算模式的共性在于结算前必须锁定病人的资金账户防止结算过程中仍有新的费用写入。常见做法是在费用表里加一个settle_status字段结算开始时置为「结算中」结算完成后再置为「已结算」期间新产生的医嘱费用进入待结算队列而不是直接写入已结算账单。这种做法虽然课程设计里不一定要求实现但理解了这层逻辑面试和答辩时能把「数据一致性」讲明白。4.4 业务流程图的文档化技巧文档 2.3 节的五张流程图都是手绘风格的业务框图。做软件工程课程设计时流程图的绘制建议用标准 UML 活动图或泳道图纵向泳道按角色划分病人、挂号员、医生、收费处、药房、住院部。每个活动标注对应的数据表写入操作这样流程图既表达了业务流程又映射到了数据库设计。文档中「凭证制作」「月末在院结算」「押金日结」这些描述的实质是定时任务在流程图上可以用「定时触发」标注避免和业务操作混淆。5. 把这份课程设计做成答辩亮点从文档到可演示系统的三个技巧5.1 用「状态机」思路重新审视图表设计这份文档的表结构已经覆盖了主要业务但答辩时如果想体现软件工程思维可以用状态机模型把所有核心业务对象的状态流转画出来。比如门诊划价单有未收费 → 已收费 → 已发药三态退费则是已发药 → 退药中 → 已退费。把这些状态变化列成一张表比贴十张界面截图更能体现系统分析能力。文档中clinic_pricing表只设计了收费和发药两个状态字段实际上退费还需要一个refund_status字段做扩展时建议加上。5.2 把统计模块用存储过程实现文档在功能模块中提到了「统计查询」「日清、月结报表」这类功能在课程设计里最常见的做法是直接写 SELECT 语句统计。但真实项目中这些统计会涉及多表连接、环比查询和复杂计算放在应用层会让 Delphi 客户端代码非常臃肿。常见改进方案是写成 SQL Server 存储过程把统计逻辑放到数据库层。举个例子科室挂号量统计可以这样实现CREATE PROCEDURE sp_visit_stats start_date DATETIME, -- 起始日期 end_date DATETIME -- 结束日期 AS BEGIN SELECT r.reg_dept AS 科室, COUNT(*) AS 挂号量, SUM(CASE WHEN r.reg_type 专家号 THEN 1 ELSE 0 END) AS 专家号数量 FROM clinic_registration r WHERE r.reg_time BETWEEN start_date AND end_date GROUP BY r.reg_dept ORDER BY 挂号量 DESC; END5.3 准备三个「防御型」技术问题答辩老师最喜欢在「你没写到的部分」提问。围绕这份文档最可能被追问的是并发挂号时如何保证病人编号不重复、药房发药时库存数量并发扣减会不会出现负数、退费时如何处理已经发出去的药。这三个问题的实质都是数据一致性与并发控制。基于这份文档的表结构可以回答主索引靠数据库主键约束保证唯一发药扣库存使用事务加条件判断UPDATE drug_stock SET quantity quantity - 1 WHERE drug_id ? AND quantity 0受影响行数为 0 则说明库存不足退药退费包裹在同一个事务中保证两件事同时成功或同时回滚。这几个回答不需要写出完整代码能口头说清楚就是加分项。本文还有配套的精品资源点击获取