医院门诊信息管理系统
第 1 章绪论
1.1 项目背景
随着计算机应用的日益普及和深化,网上办公已经成为了一种趋势。医院信息化近年来也在各个医院迅速发展,医院信息系统公认为新兴的医学信息学的重要分支,医院信息系统是指利用计算机硬件技术、网络通讯技术等现代化手段对医疗机构及其所属各部门对人流、物流、财流进行综合管理,对在医疗活动各阶段中产生的数据进行采集、存储、处理、提取。传输、汇总、加工生成各种信息,从而为医疗机构的整体运行提供全面的、自动化的管理以及各种服务的信息系统。
其中,医院门诊部分的人流量最大,传统的挂号就诊方式不仅浪费时间,患者还要注意保存各种对应的凭证和收据,如果患者不慎丢失凭证,可能会导致时间上的浪费甚至无法就诊。同时,传统的挂号就诊方式也导致医院方面的工作效率低下,出错率也较高,数据的保存、管理和查询也非常困难,这导致门诊医生的看诊效率也随之下降。为了方便患者的就诊、简化就诊流程,也为了提高医院的工作效率、降低工作出错率、减少工作人手、方便患者数据的保存和管理、完善医院的管理体制,建立一个门诊信息管理系统就显得尤为重要。
1.2 项目意义
本系统的落成可以简化患者的就诊流程,提高就诊效率,增加患者就诊时的舒适度;对于医院,可以提高医院的工作效率,降低工作的出错率,也方便医院对于患者信息和医院工作人员信息的管理,提高门诊医生的看诊效率。
该门诊管理系统通过身份证等方式,实现病人数据准确唯一识别。加快病人诊疗流程,减少病人排队等候时间,通过病历本等方式可以展示居民个人信息,便于医生快速全面了解患者的健康记录。
本系统以“服务病人”为中心,节省病人就诊时间的同时,大大提高医疗质量和工作效率,可以减轻医生和护理人员的工作压力和时间,并将大部分时间花在医疗护理效果上面。
全电子化处方流程,提高了医生的工作效率。实践案例应用证明,即使是已退休年龄的医生,都能轻松的完成电子处方和病历,比原来手写处方节约一半以上的时间,同时带来防止因处方流失、加快门诊收费速度等好处。
门诊医生工作人员无需切换界面或者另外登录其他的模块,在同一界面即可进行填写病历、检验申请、门诊确诊、处置申请、开立处方等内容。
系统提供基于工作角色的权限管理,对操作权限进行了严格的控制,对操作过程进行完整的记录,信息更加安全可靠。
对于数据的安全性,采取多级的权限管理机制,确保了数据的安全性。
1.3 工作内容
1.3.1 项目故事板
作为一个医院门诊的信息管理系统,对于用户而言最重要的功能就是挂号和看诊过程,这也是本系统的实现重点。
挂号过程的大致原型和基本描述如下:
图 1.1 挂号过程大致原型
本页面的主要功能如下:前台首先输入患者的各项基本信息,而后根据患者的需求,选择挂号科室、号别以及门诊医生。若无余号,则告知患者并重新选择。确定填写无误后,点击“提交”,再次确认信息。
看诊过程大致原型如下:
图 1.2 看诊流程大致原型
本页面的主要功能如下:门诊医生首先确认当前就诊的患者与系统显示的患者是否一致,如果发现当前就诊患者与系统显示患者不一致,告知患者错误并通知正确的患者。在看诊过程中,门诊医生发现已诊患者仍需要诊断,可点击已诊患者下对应患者的“选择”,令其成为当前患者,同时系统读取该患者信息;如果门诊医生认为当前患者诊断完毕,可点击“诊毕”,将当前患者放入已诊患者中,同时未诊患者中序号最小的患者成为当前患者。门诊医生根据患者的病情,为患者新增医技(填写医技编码、项目名称,系统会自动生成执行科室、单价等信息)。新增若干条医技后,选择若干项进行删除或开立。同时可以进行检验/处置申请、门诊确诊、出发开立、费用查询等功能。
1.3.2 项目结构层次图
使用表格,对项目结构层次图进行描述。
1.3.3 整体业务流程图
图 1.4 整体业务流程图
第 2 章开发工具及相关技术简介
2.1HbuilderX
HBuilderX 是 DCloud(数字天堂)推出的一款支持 HTML5 的 Web 开发 IDE。它的编写用到了 Java、C、Web 和 Ruby。HBuilderX 本身主体是由 Java 编写。它基于 Eclipse,所以顺其自然地兼容了 Eclipse 的插件。
HbuilderX 的发行包仅 10 余 M,非常的轻巧,而且不管是启动速度、大文档打开速度、编码提示,极速响应 C++ 的架构性能远超 Java 或 Electron 架构。HbuilderX 对 vue 做了大量优化投入,开发体验远超其他开发工具。HbuilderX 也是唯一一个新建文件默认类型是 Markdown 的编辑器,也是对 md 支持最强的编辑器。而且,HbuilderX 是中国唯一一家拥有自主 IDE 语法分析引擎的公司,对前端语言提供准确的代码提示和转到定义。除此以外,现代 js 开发中大量 JSON 结构的写法,HbuilderX 提供了比其他工具更高效的操作。HbuilderX 还支持 Java 插件、nodejs 插件,并兼容了很多 vscode 的插件及代码块。
由于 HbuilderX 轻巧、方便、相应速度快,而且支持 Vue 框架,故我小组使用该软件进行项目前端开发。
2.2IntelliJIDEA
IntelliJIDEA 是 Java 编程语言开发的集成环境。
IntelliJ 在业界被公认为最好的 Java 开发工具,尤其在智能代码助手、代码自动提示、重构、JavaEE 支持、各类版本工具(git、SVN 等)、JUnit、CVS 整合、代码分析、创新的 GUI 设计等方面的功能可以说是超常的。
由于 IDEA 使用方便、开发容易,故我小组使用该软件进行后端开发。
2.3MySQL
MySQL 是一个关系型数据库管理系统,由瑞典 MySQLAB 公司开发,属于 Oracle 旗下产品。
MySQL 是最流行的关系型数据库管理系统之一,在 Web 应用方面,MySQL 是最好的关系数据库管理系统)应用软件之一。关系数据库将数据保存在不同的表中,而不是将所有数据放在一个大仓库内,这样就增加了速度并提高了灵活性。而且,MySQL 所使用的 SQL 语言是用于访问数据库的最常用标准化语言。由于其体积小、速度快、总体拥有成本低,尤其是开放源码这一特点,一般中小型网站的开发都选择 MySQL 作为网站数据库。
由于 MySQL 的速度和灵活性,故我小组使用该软件进行数据库开发。
2.4Navicat
Navicat 是一套快速、可靠的数据库管理工具,专为简化数据库的管理及降低系统管理成本而设。
Navicat 的功能足以符合专业开发人员的所有需求,而且对数据库服务器的新手来说又相当容易学习。有了极完备的图形用户界面(GUI),Navicat 让你可以以安全且简单的方法创建、组织、访问和共享信息。
由于 Navicat 的众多优点,故我小组使用 Navicat 进行数据库管理。
2.5 配置管理与 Git 应用
Git 是一个开源的分布式版本控制系统,可以有效、高速地处理从很小到非常大的项目版本管理。
分布式相比于集中式的最大区别在于开发者可以提交到本地,每个开发者通过克隆(gitclone),在本地机器上拷贝一个完整的 Git 仓库。优点有适合分布式开发,强调个体;公共服务器压力和数据量都不会太大;速度快、灵活;任意两个开发者之间可以很容易的解决冲突;离线工作等。
由于 Git 优异的版本控制能力,故我小组使用该软件进行版本控制。
2.6Vue 开发前端开发框架
Vue 是一套用于构建用户界面的渐进式 JavaScript 框架。
Vue 是一套构建用户界面的渐进式框架。与其他重量级框架不同的是,Vue 采用自底向上增量开发的设计。Vue 的核心库只关注视图层,并且非常容易学习,非常容易与其它库或已有项目整合。另一方面,Vue 完全有能力驱动采用单文件组件和 Vue 生态系统支持的库开发的复杂单页应用。而且,Vue 通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件。当然,Vue 自身不是一个全能框架——它只聚焦于视图层。因此它非常容易学习,非常容易与其它库或已有项目整合。另一方面,在与相关工具和支持库一起使用时,Vue.js 也能驱动复杂的单页应用。除此以外,Vue 还具有易用、灵活和高性能的特点。
由于 Vue 的这些优点,故我小组采用该框架来进行前端开发。
2.7ElementUI
ElementUI,一套为开发者、设计师和产品经理准备的基于 Vue2.0 的组件库,提供了配套设计资源,帮助网站快速成型。
ElementUI 具有一致性、优化反馈、高效率和可控的优点,故我小组使用该组件库辅助前端开发。
2.8Ajax
AJAX 是异步 JavaScript 和 XML,包括 HTML 或 XHTML,CSS,JavaScript,DOM,XML,XSLT,以及最重要的 XMLHttpRequest。使用 AJAX 技术可以在不刷新整个页面的前提下进行数据的增量更新,更快的回应用户的操作。我们主要使用 Axios 实现 AJAX 技术.
2.9Spring
Spring 框架是一个开放源代码的 J2EE 应用程序框架,是针对 bean 的生命周期进行管理的轻量级容器。
Spring 解决了开发者在 J2EE 开发中遇到的许多常见的问题,提供了功能强大 IoC、AOP 及 WebMVC 等功能。Spring 可以单独应用于构筑应用程序,也可以和 Struts、Webwork、Tapestry 等众多 Web 框架组合使用,并且可以与 Swing 等桌面应用程序 AP 组合。因此,Spring 不仅仅能应用于 J2EE 应用程序之中,也可以应用于桌面应用程序以及小应用程序之中。故我小组使用 Spring 作为后端框架。
2.10SpringMVC
SpringMVC 属于 SpringFrameWork 的后续产品,已经融合在 SpringWebFlow 里面。
SpringMVC 易于同其它 View 框架(Tiles 等)无缝集成,采用 IoC 便于测试。这是一个典型的教科书式的 mvc 构架,而不像 struts 等都是变种或者不是完全基于 mvc 系统的框架。第二它和 tapestry 一样是一个纯正的 servlet 系统,这也是它和 tapestry 相比 struts 所具有的优势。而且框架本身有代码,看起来容易理解。故我小组使用其进行后端开发。
2.11Springboot
SpringBoot 基于 Spring4.0 设计,不仅继承了 Spring 框架原有的优秀特性,而且还通过简化配置来进一步简化了 Spring 应用的整个搭建和开发过程。该框架使用了特定的方式来进行配置,从而使开发人员不再需要定义样板化的配置。故我小组使用该框架辅助后端开发。
2.12MyBatis
MyBatis 是一个基于 Java 的持久层框架。
MyBatis 是一款优秀的持久层框架,它支持定制化 SQL、存储过程以及高级映射。MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。MyBatis 可以使用简单的 XML 或注解来配置和映射原生信息,将接口和 Java 的 POJOs(PlainOrdinaryJavaObject,普通的 Java 对象)映射成数据库中的记录。故我小组使用该框架完成后端与数据库的连接与查询。
2.13Maven
Maven 项目对象模型,可以通过一小段描述信息来管理项目的构建,报告和文档的项目管理工具软件。
Maven 除了以程序构建能力为特色之外,还提供高级项目管理工具。由于 Maven 的缺省构建规则有较高的可重用性,所以常常用两三行 Maven 构建脚本就可以构建简单的项目。Maven 还提供了一种标准化的方式构建项目,一个清晰的方式定义项目的组成,一个容易的方式发布项目的信息,以及一种简单的方式在多个项目中共享 JAR。
2.14AxureRP
AxureRP 是一款专业的快速原型设计工具。
AxureRP 是最常用的快速原型设计工具之一,能够快捷而简便的制作产品原型,快速绘制线框图、流程图、网站架构图、示意图、HTML 模版以及交互设计,并可自动生成用于演示的网页文件和规格文件,以提供演示与开发。应用于产品设计包括 Web/移动端/客户端的产品,支持多人协作设计和版本控制管理。将设计、研发、产品、用研融为一体的快速工具。在互联网产品领域,Axure 已成为产品经理、产品设计师以及交互设计师的必备工具。其优势非常明显:操作复杂度介于 Keynote/PPT 和 Adobe 家族之间;拥有全套 Web 控件库,直接拖拽即可快速制作网站原型;丰富的动态面板可以用来模拟各种复杂的交互效果;导出 HTML 后可以更加准确的传达信息架构和页面跳转。便于与用户的需求验证,也帮助我们构思交互细节,使前端和开发人员更容易理解我们的产品。故我小组使用该软件进行原型设计。
2.15PowerDesigner
PowerDesigner 是 Sybase 公司的 CASE 工具集,使用它可以方便地对管理信息系统进行分析设计,他几乎包括了数据库模型设计的全过程。利用 PowerDesigner 可以制作数据流程图、概念数据模型、物理数据模型,还可以为数据仓库制作结构模型,也能对团队设计模型进行控制。他可以与许多流行的软件开发工具,例如 Delphi、VB 等相配合使开发时间缩短和使系统设计更优化。powerdesigner 是能进行数据库设计的强大的软件,是一款开发人员常用的数据库建模工具。使用它可以分别从概念数据模型和物理数据模型两个层次对数据库进行设计。在这里,概念数据模型描述的是独立于数据库管理系统的实体定义和实体关系定义;物理数据模型是在概念数据模型的基础上针对目标数据库管理系统的具体化。
基于 PowerDesigner 的以上优势,我小组使用其进行数据库的设计。
2.16ProcessOn
ProcessOn 是一个面向垂直专业领域的作图工具,支持绘制思维导图、流程图、UML、网络拓扑图、组织结构图、原型图、时间轴等等。
ProcessOn 将全球的专家顾问、咨询机构、BPM 厂商、IT 解决方案厂商和广泛的企业用户紧密的连接在一起,提供基于云服务的免费流程梳理、创作协作工具,与同事和客户协同设计,实时创建和编辑文件,并可以实现更改的及时合并与同步,这意味着跨部门的流程梳理、优化和确认可以即刻完成。而且,ProcessOn 专注于为作图人员提供价值,利用互联网和社交技术颠覆了人们梳理流程的方法习惯,继而使商业用户获得比传统模式更高的效率和回报,改善人们对流程图的创作过程。故我小组使用其作为项目各种示意图、流程图等的作图工具。
2.17 本章小结
本章主要介绍了本小组在开发项目时选择使用的开发工具及相关技术/框架的简介,简述了它们的优势和使用它们的原因,为将来的开发打下了坚实的基础。
第 3 章需求分析
3.1 引言
3.1.1 目的
本文档是根据医院的门诊部门的实际工作流程进行充分调研后整理出来的,描述用户关于医院门诊部门的业务流程和业务需求的文档,本文档的目的一方面是指导实训学员了解最终的业务需求,另一方面是作为后续开发设计的业务需求指导文档。
3.1.2 参考资料
暂无描述。
3.1.3 术语
暂无描述。
3.2 任务概述
3.2.1 目标
项目总体目标是搭建一个医院门诊的管理系统,使得医院的医生以及工作人员可以更好地完成医院门诊的工作。系统在完成门诊各种功能实现的同时,还要力求系统的易学性、简约型。做到能够让用户快速学习,快速熟练使用本系统。
3.3 需求规定
3.3.1 一般性需求
系统应实现医院门诊系统的所有主要功能,方便医院的医生以及工作人员可以方便地完成医院门诊的日常工作。
系统应采用基于浏览器的操作模式,并具有良好的系统扩充能力。
系统应操作方便、功能显示直接,能够让用户快速熟练使用本系统。
系统应具备完善的数据库,便于医院的医生以及工作人员对数据进行查看与操作。
对于用户的重要操作,系统应记录操作人和操作日期。操作人默认为当前登录人员。操作日期默认为当天。
3.3.2 功能性需求
图 3.1 医院门诊系统功能图
表 3.1 医院门诊系统功能描述表
功能名称 | 备注 | 裁剪说明 |
---|---|---|
挂号 | 主要负责医院门诊的挂号退号操作。 | 不可裁剪 |
费用查询与管理 | 主要负责患者查询费用以及缴费退费功能。 | 不可裁剪 |
病历填写 | 主要负责对患者的病历进行编辑与填写功能。 | 不可裁剪 |
检验申请 | 主要负责患者的检验申请功能。 | 可以裁剪 |
门诊确诊 | 主要负责对患者的病情进行确诊的功能。 | 不可裁剪 |
开立处方 | 主要负责对患者的处方进行开立的功能。 | 不可裁剪 |
处置申请 | 主要负责患者的处置申请功能。 | 可以裁剪 |
处方管理 | 主要负责对已有的处方进行管理的功能。 | 可以裁剪 |
患者检验 | 主要负责患者检验的功能。 | 可以裁剪 |
患者处置 | 主要负责患者处置的功能。 | 可以裁剪 |
医技管理 | 主要负责对医院医技管理的功能。 | 可以裁剪 |
药房开药 | 主要负责对患者开药的功能。 | 可以裁剪 |
药物管理 | 主要负责对药房的药物进行管理的功能。 | 可以裁剪 |
医生排班管理 | 主要进行医生排班的管理。 | 不可裁剪 |
科室管理 | 主要进行医院科室的管理。 | 不可裁剪 |
用户管理 | 主要进行对系统用户的管理。 | 不可裁剪 |
整体业务流程:
图 3.2 整体业务流程图
3.3.3 挂号
需求描述:
表 3.2 挂号功能描述表
功能需求 | |
---|---|
功能名称 | 挂号部分 |
优先级 | 高 |
业务背景 | 门诊前台部分是为患者提供挂号服务的部分,主要为医院门诊的挂号退号操作。 |
功能说明 | 1.填写患者基本信息 2.查询挂号信息并选择挂号 3.确认挂号信息 4.缴费 5.查询患者挂号信息 6.取人患者挂号状态 7.退号并退费 |
约束条件 | 1.挂号过程中,只能当天有排班信息的医生的号。2.若一个医生当天的号全部挂完,则不能挂该医生的号。3.挂号时需填写所有必要信息,否则不予挂号。4.在查询患者信息时,至少填写一个必要信息,否则不予查询。5.当患者挂号状态为已诊时,不予退费。 |
相关查询 | 1.查询患者基本信息 2.查询医生排班信息和余号信息 3.查询患者挂号信息 |
其他需求 | 无 |
裁剪说明 | 不可裁剪 |
业务流程描述:
图 3.3 挂号业务流程图
数据描述:
表 3.3 挂号数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
病历号 | 用于标识患者的代码 | 是 |
姓名 | 用于表示患者姓名 | 是 |
身份证号 | 用于标识患者的代码 | 是 |
性别 | 描述患者性别 | 是 |
年龄 | 描述患者年龄 | 是 |
出生日期 | 描述患者出生日期 | 否 |
住址 | 描述患者住址 | 否 |
挂号科室 | 下拉框,分为内科、外科、骨科等 | 是 |
号别 | 描述是专家号还是普通号 | 是 |
门诊医生 | 确定看诊医生 | 是 |
余号 | 自动生成 | 是 |
费用 | 自动生成 | 是 |
支付方式 | 确定患者支付方式 | 是 |
挂号日期 | 显示患者挂号信息 | 是 |
挂号状态 | 显示患者挂号状态 | 是 |
3.3.4 缴费/退费
需求描述:
表 3.4 缴费/退费功能描述表
功能需求 | |
---|---|
功能名称 | 缴费/退费部分 |
优先级 | 高 |
业务背景 | 缴费/退费部分是为患者提供费用相关服务的部分,主要负责患者查询费用以及缴费退费功能。 |
功能说明 | 1.患者信息查询 2.显示患者费用信息 3.确认患者缴费状态 4.进行缴费/退费操作 5.开立处方 6.费用查询 7.处方管理 |
约束条件 | 1.在查询患者信息时,至少填写一个必要信息,否则不予查询。2.当患者缴费状态为已缴费时,不予缴费。3.当患者缴费状态为未缴费时,不予退费。 |
相关查询 | 1.患者信息查询 2.患者缴费信息查询 3.患者缴费状态查询 |
其他需求 | 无 |
裁剪说明 | 不可裁剪 |
业务流程描述:
图 3.4 缴费/退费业务流程图
数据描述:
表 3.5 缴费/退费数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
病历号 | 用于标识患者的代码 | 是 |
姓名 | 用于表示患者姓名 | 是 |
身份证号 | 用于标识患者的代码 | 是 |
费用单号 | 用于表示费用单的代码 | 是 |
详细信息 | 用于描述费用的具体详细信息 | 是 |
开立时间 | 用于显示费用单的开立时间 | 是 |
费用状态 | 用于显示缴费状态 | 是 |
操作 | 共有两种操作:缴费、退费 | 是 |
3.3.5 病例填写
需求描述:
表 3.6 病例填写功能描述表
功能需求 | |
---|---|
功能名称 | 病历填写部分 |
优先级 | 高 |
业务背景 | 病历填写部分是门诊医生给患者填写病历的部分,主要为对患者病历进行编辑与填写的功能。 |
功能说明 | 1.查看目前的就诊队列与已诊队列。2.填写并编辑病历信息。3.给出初步诊断与评估。4.给出检查建议。 |
约束条件 | 1.病历中主诉、现病史为必填项。2.初步诊断至少给出一项,否则不予提交。 |
相关查询 | 1.查询未诊患者与已诊患者队列。2.对 ICD 编码进行查询。 |
其他需求 | 无 |
裁剪说明 | 不可裁剪 |
业务流程描述:
图 3.5 病例填写业务流程图
数据描述:
表 3.7 病例填写数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
当前患者 | 无 | 是 |
当前患者年龄 | 无 | 是 |
当前患者病历号 | 无 | 是 |
未诊患者序号 | 无 | 是 |
未诊患者姓名 | 无 | 是 |
未诊患者性别 | 无 | 是 |
已诊患者序号 | 无 | 是 |
已诊患者性别 | 无 | 是 |
已诊患者序号 | 无 | 是 |
主诉 | 患者对病情的描述 | 是 |
现病史 | 患者当前病情历史 | 是 |
现病史治疗情况 | 患者当前病情历史治疗情况 | 否 |
既往史 | 患者既往史 | 否 |
过敏史 | 患者过敏史 | 否 |
体格检查 | 患者体格检查 | 否 |
西医诊断 ICD 编码 | 与中医诊断 ICD 编码二者至少填写一个 | 否 |
西医诊断名称 | 与中医诊断名称二者至少填写一个 | 否 |
西医诊断时间 | 与中医诊断时间二者至少填写一个 | 否 |
西医诊断操作 | 与中医诊断操作二者至少填写一个 | 否 |
中医诊断 ICD 编码 | 与西医诊断 ICD 编码二者至少填写一个 | 否 |
中医诊断名称 | 与西医诊断名称二者至少填写一个 | 否 |
中医诊断时间 | 与西医诊断时间二者至少填写一个 | 否 |
中医诊断操作 | 与西医诊断操作二者至少填写一个 | 否 |
检查建议 | 根据病情的初步诊断给出检查建议 | 否 |
3.3.6 检验申请
需求描述:
表 3.8 检验申请功能描述表
功能需求 | |
---|---|
功能名称 | 检验申请部分 |
优先级 | 高 |
业务背景 | 检验申请部分是医生为患者开立检验申请的部分,主要为编辑检验申请和提交的功能 |
功能说明 | 1.查看目前的就诊队列与已诊队列 2.能够新增,删除检验项 3.有常用的检验项,4.开立和作废检验单 |
约束条件 | 数据库里有检验项 |
相关查询 | 待诊患者队列查询检查项 |
其他需求 | 有常用的检查项 |
裁剪说明 | 可以裁剪 |
业务流程描述:
图 3.6 检验申请业务流程图
数据描述:
表 3.9 检验申请数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
当前患者 | 无 | 是 |
当前患者年龄 | 无 | 是 |
当前患者病历号 | 无 | 是 |
未诊患者序号 | 无 | 是 |
未诊患者姓名 | 无 | 是 |
未诊患者性别 | 无 | 是 |
已诊患者序号 | 无 | 是 |
已诊患者性别 | 无 | 是 |
已诊患者序号 | 无 | 是 |
检验项分类 | 检验项的类别 | 是 |
检验项名称 | 检验项的名称 | 是 |
执行科室 | 执行检验的科室 | 是 |
检验项单价 | 检验项的价格 | 是 |
检验项状态 | 已开立,未检查,已检查等状态 | 是 |
检测结果 | 检查结果 | 否 |
3.3.7 门诊确诊
需求描述:
表 3.10 门诊确诊功能描述表
功能需求 | |
---|---|
功能名称 | 门诊确诊 |
优先级 | 高 |
业务背景 | 门诊确诊是医生为患者的病情做出诊断的部分,主要为对患者的病情进行确诊的功能。 |
功能说明 | 1.查看目前的就诊队列与已诊队列。2.填写患者基本信息。3.查看检查项结果。4.给出诊断结果和处理意见。 |
约束条件 | 1.患者病历号、姓名、年龄、性别为必填项。2.必须填写诊断结果与诊断意见,否则不予提交。 |
相关查询 | 1.查询未诊患者与已诊患者队列。2.查询患者检查信息。 |
其他需求 | 无 |
裁剪说明 | 不可裁剪 |
业务流程描述:
图 3.7 门诊确诊业务流程图
数据描述:
表 3.11 门诊确诊数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
当前患者 | 无 | 是 |
当前患者年龄 | 无 | 是 |
当前患者病历号 | 无 | 是 |
未诊患者序号 | 无 | 是 |
未诊患者姓名 | 无 | 是 |
未诊患者性别 | 无 | 是 |
已诊患者序号 | 无 | 是 |
已诊患者性别 | 无 | 是 |
已诊患者序号 | 无 | 是 |
病历号 | 用于标识患者的代码 | 是 |
姓名 | 用于标识患者姓名 | 是 |
性别 | 用于标识患者性别 | 是 |
年龄 | 用户表示患者结果 | 是 |
检查项类别 | 自动生成项 | 否 |
检查项名称 | 自动生成项 | 否 |
检查项类别 | 自动生成项 | 否 |
检查项结果 | 自动生成项 | 否 |
诊断结果 | 无 | 是 |
处理意见 | 无 | 是 |
3.3.8 处置申请
需求描述:
表 3.12 处置申请功能描述表
功能需求 | |
---|---|
功能名称 | 处置申请 |
优先级 | 高 |
业务背景 | 处置申请部分是医生为患者开立处置申请的部分,主要为对患者的处置申请进行编辑与填写的功能。 |
功能说明 | 医生为患者开立处置申请,以保证患者可以进行处置处理 |
约束条件 | 数据库中存在处置信息 |
相关查询 | 患者队列的查询,处置项目的查询 |
其他需求 | 常用处置项 |
裁剪说明 | 可以裁剪 |
业务流程描述:
图 3.8 处置申请业务流程图
数据描述:
表 3.13 处置申请描述表
名称 | 描述 | 是否必添 |
---|---|---|
处置项分类 | 处置项的分类描述 | 是 |
处置项名称 | 名称 | 是 |
执行科室 | 执行处置的科室 | 是 |
单价 | 单次的价格 | 是 |
状态 | 未开立,已完成等 | 是 |
结果 | 处置结果 | 否 |
3.3.9 开立处方
需求描述:
表 3.14 开立处方功能描述表
功能需求 | |
---|---|
功能名称 | 开立处方部分 |
优先级 | 高 |
业务背景 | 开立处方部分是医生为患者开立处方的部分,主要为对患者处方编辑与填写的功能。 |
功能说明 | 给患者开立处方(包括成药处方和草药处方) |
约束条件 | 无 |
相关查询 | 查询相关药物信息 |
其他需求 | 无 |
裁剪说明 | 不可裁剪 |
业务流程描述:
图 3.9 开立处方业务流程图
数据描述:
表 3.15 开立处方数据描述表
名称 | 描述 | 是否必添 |
---|---|---|
药品名称 | 添加的药品名称 | 是 |
规格 | 添加的药品规格 | 是 |
单价 | 药品的单价 | 是 |
用法 | 该药品的使用方法 | 是 |
用量 | 该药品的用量 | 是 |
频次 | 该药品的使用频次 | 是 |
数量 | 该药品的数量 | 是 |
总价 | 总的价格 | 是 |
3.3.10 处方管理
需求描述:
表 3.16 处方管理功能描述表
功能需求 | |
---|---|
功能名称 | 处方管理 |
优先级 | 低 |
业务背景 | 添加医生常用的处方,方便医生使用 |
功能说明 | 添加常用处方和其详细信息(包括西药和中药的处方模板) |
约束条件 | 无 |
相关查询 | 查询药品和处方 |
其他需求 | 无 |
裁剪说明 | 不可裁剪 |
业务流程描述:
图 3.10 处方管理业务流程图
数据描述:
表 3.17 处方管理数据描述表
名称 | 描述 | 是否必添 |
---|---|---|
处方名称 | 处方的名称 | 是 |
处方编号 | 处方的唯一标识 | 是 |
药品名称 | 处方中药品的名称 | 是 |
药品规格 | 处方中药品的规格 | 是 |
药品单位 | 处方中药品的单位 | 是 |
药品用法 | 处方中药品的用法 | 是 |
药品用量 | 处方中药品的用量 | 是 |
药品频次 | 处方中药品的频次 | 是 |
3.3.11 患者检验
需求描述:
表 3.18 患者检验功能描述表
功能需求 | |
---|---|
功能名称 | 患者检验 |
优先级 | 低 |
业务背景 | 患者检验部分是医生对患者的检验进行管理的部分,主要为对患者检验信息的确认和状态管理的功能。 |
功能说明 | 1.核对患者信息 2.检查患者检验信息 3.对患者需要检验的项目进行操作 |
约束条件 | 1.患者缴费后才能做检验 2.患者做完的检验项状态变为已做 3.患者只能做未做状态的检验 |
相关查询 | 1.查询已完成检验和未完成检验的患者 |
其他需求 | 无 |
裁剪说明 | 可以裁剪 |
业务流程描述:
图 3.11 患者检验业务流程图
数据描述:
表 3.19 患者检验数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
病历号 | 用于标识患者的代码 | 是 |
姓名 | 用于表示患者姓名 | 是 |
身份证号 | 用于标识患者的代码 | 是 |
性别 | 描述患者性别 | 是 |
年龄 | 描述患者年龄 | 是 |
就诊科室 | 描述患者就诊科室 | 是 |
结算类别 | 描述患者缴费方式 | 否 |
处方状态 | 用于查看检验项的状态 | 是 |
收费日期 | 描述患者缴费时间 | 否 |
开单医生 | 描述患者的开单医生 | 是 |
3.3.12 患者处置
需求描述:
表 3.20 患者处置功能描述表
功能需求 | |
---|---|
功能名称 | 患者处置 |
优先级 | 低 |
业务背景 | 患者处置部分是医生对患者的处置进行管理的部分,主要为对患者处置信息的确认和状态管理的功能。 |
功能说明 | 1.核对患者信息 2.检查患者处置信息 3.对患者需要处置的项目进行操作 |
约束条件 | 1.患者缴费后才能做处置 2.患者做完的处置项状态变为已做 3.患者只能做未做状态的处置 |
相关查询 | 1.查询已完成处置和未完成处置的患者 |
其他需求 | 无 |
裁剪说明 | 可以裁剪 |
业务流程描述:
图 3.12 患者处置业务流程图
数据描述:
表 3.21 患者处置数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
病历号 | 用于标识患者的代码 | 是 |
姓名 | 用于表示患者姓名 | 是 |
身份证号 | 用于标识患者的代码 | 是 |
性别 | 描述患者性别 | 是 |
年龄 | 描述患者年龄 | 是 |
就诊科室 | 描述患者就诊科室 | 是 |
结算类别 | 描述患者缴费方式 | 否 |
处方状态 | 用于查看检验项的状态 | 是 |
收费日期 | 描述患者缴费时间 | 否 |
开单医生 | 描述患者的开单医生 | 是 |
3.3.13 医技管理
需求描述:
表 3.22 医技管理功能描述表
功能需求 | |
---|---|
功能名称 | 医技管理 |
优先级 | 低 |
业务背景 | 医技管理部分是医生对已有的医技进行管理的部分,主要为对医技的添加、编辑和管理功能。 |
功能说明 | 1.医技添加 2.医技编辑 3.医技删除 4.医技查询 |
约束条件 | 1.只能查询到现有的医技 |
相关查询 | 1.查询医技 |
其他需求 | 无 |
裁剪说明 | 可以裁剪 |
业务流程描述:
图 3.13 医技管理业务流程图
数据描述:
表 3.23 医技管理数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
项目编码 | 用于标识医技的代码 | 是 |
项目名称 | 用于表示项目名称 | 是 |
项目助记码 | 用于项目快捷添加 | 否 |
项目单价 | 用于描述项目费用 | 是 |
3.3.14 药房开药
需求描述:
表 3.24 药房开药功能描述表
功能需求 | |
---|---|
功能名称 | 开药部分 |
优先级 | 低 |
业务背景 | 开药部分是为患者进行开药拿药的部分,主要为对患者基本信息查询、对开药信息查询以及确认开药的功能。 |
功能说明 | 1、查看未开药的患者名单 2、查看已开药的患者名单 3、在未开药的患者名单中查询患者姓名 4、查看患者的药单 5、确认给患者发药 |
约束条件 | 1、确认发药后不可以进行退药 2、只能在未开药患者名单中进行查询 3、查询患者姓名不排除有重名的现象 |
相关查询 | 1、查询患者姓名 2、查询患者的药单 |
其他需求 | 开药部分 |
裁剪说明 | 低 |
业务流程描述:
图 3.14 药房开药业务流程图
数据描述:
表 3.25 药房开药数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
患者名称 | 取药的患者姓名 | 是 |
年龄 | 取药的患者年龄 | 是 |
病历号 | 取药的患者病历号 | 是 |
药品编号 | 患者要取得的药物的编号 | 是 |
药物名称 | 患者要取得的药物的名称 | 是 |
生产厂家 | 患者要取得的药物的生产厂家 | 是 |
使用说明 | 患者要取得的药物的使用说明 | 是 |
数量 | 患者要取得的药物的数量 | 是 |
单价 | 患者要取得的药物的单价 | 是 |
开立医生 | 给患者开药的医生 | 是 |
频次 | 患者要取得的药物的频次 | 是 |
小结 | 患者要取得的药物的单价*数量 | 是 |
总金额 | 患者要取得的所有药物的总价 | 是 |
3.3.15 药房管理
需求描述:
表 3.26 药房管理功能描述表
功能需求 | |
---|---|
功能名称 | 药物管理 |
优先级 | 低 |
业务背景 | 药物管理部分是对药房的所有药物进行管理的部分,主要为对药物的编辑和管理功能。 |
功能说明 | 1、查看药库中的药物信息 2、查询药物编号 3、新增药物 4、批量删除药物 |
约束条件 | 1、不可以对药物进行修改 |
相关查询 | 1、查询药物编号 |
其他需求 | 无 |
裁剪说明 | 可以裁剪 |
业务流程描述:
图 3.15 药房管理业务流程图
数据描述:
表 3.27 药房管理数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
药物编号 | 用于标识药物 | 是 |
药品名称 | 患者要取得药物的名称 | 是 |
生产厂家 | 患者要取得药物的生产厂家 | 是 |
使用数量 | 患者要取得药物的数量 | 是 |
单价 | 患者要取得药物的单价 | 是 |
开立医生 | 给患者开药的医生 | 是 |
频次 | 患者要取得药物的频次 | 是 |
小计 | 患者要取得药物的单价*数量 | 是 |
总价 | 患者要取得所有的药物的价钱 | 是 |
3.3.16 医生排班管理
需求描述:
表 3.28 医生排班功能描述表
功能需求 | |
---|---|
功能名称 | 医生排班管理 |
优先级 | 高 |
业务背景 | 门诊后台管理系统,专门安排医生的工作时间 |
功能说明 | 1.选择科室 2.查询选择科室的排班表 3.清空选择科室的当前排班表用于新的排班 4.在排班表写入人员来进行排班管理 5.需要新的排班规则,写入规则名称和规则描述,点击新增排班规则 6.取消排班规则 |
约束条件 | 1.科室选择只能选择已有的科室 2.同科室的规则名称不能相同 3.只能对今天及之后的时间进行医生排班管理 |
相关查询 | 查询科室当前的排班信息 |
其他需求 | 无 |
裁剪说明 | 不可裁剪 |
业务流程描述:
图 3.16 医生排班业务流程图
数据描述:
表 3.29 医生排班数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
科室选择 | 用于表示需要排班的科室 | 是 |
规则名称 | 用于表示排班规则的名称 | 是 |
规则描述 | 用于描述排班规则的信息 | 否 |
3.3.17 科室管理
需求描述:
表 3.30 科室管理功能描述表
功能需求 | |
---|---|
功能名称 | 科室管理 |
优先级 | 低 |
业务背景 | 对医院的所有科室进行管理 |
功能说明 | 能新增、删除科室,并管理的科室的职能定位 |
约束条件 | 无 |
相关查询 | 查询现有的科室 |
其他需求 | 无 |
裁剪说明 | 不可裁剪 |
业务流程描述:
图 3.17 科室管理业务流程图
数据描述:
表 3.31 科室管理数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
科室编号 | 唯一标识科室 | 是 |
科室名称 | 科室的名称 | 是 |
科室类别 | 科室的类别 | 是 |
3.3.18 用户管理
需求描述:
表 3.32 用户管理功能描述表
功能需求 | |
---|---|
功能名称 | 用户管理 |
优先级 | 高 |
业务背景 | 门诊后台管理系统,用来管理用户个人信息 |
功能说明 | 1.新增用户 2.选择新增人员的科室、用户角色 3.修改用户信息 4.删除用户 |
约束条件 | 1.科室选择只能选择已有的科室 2.用户编号、创建时间不能修改 3.管理员账号不能删除 4.用户选择只能选择符合当前科室的角色 |
相关查询 | 无 |
其他需求 | 无 |
裁剪说明 | 不可裁剪 |
业务流程描述:
图 3.18 用户管理业务流程图
数据描述:
表 3.33 用户管理数据描述表
名称 | 描述 | 是否必填 |
---|---|---|
科室选择 | 用于表示需要排班的科室 | 是 |
用户角色选择 | 用于表示当前科室的用户角色 | 是 |
3.4 系统安全性的要求
3.4.1 数据存储安全
暂无描述。
3.4.2 访问控制安全
过滤器过滤未登录用户和权限不一致的用户。
3.4.3 网络传输安全
暂无描述。
3.4.4 应用系统审计
暂无描述。
3.4.5 系统约束
暂无描述。
3.5 运行环境规定
3.5.1 运行环境
软件环境:
前端 VUE、ElementUI
后端 Spring、SpringBoot、SpringMVC、MyBatis、SSM
JDK1.8、Maven3.63 以上
数据库 MySQL8 以上
操作系统:Windows764 位或 Linux6.564 位及以上
硬件环境:
CPU:4Core3.0GHz 以上 RISCCPU 或 4*IntelE7-3250v4(4Core,16MCache,2.1GHz)及以上。
内存:128GB,内置硬盘:2*600GBRAID1
3.5.2 接口
暂无描述。
3.6 遗留问题
暂无描述。
3.7 项目非技术需求
暂无描述。
3.8 本章小结
本章主要介绍了我小组对该系统进行的需求分析,明确了系统的整体目标和各个模块的优先级,为将来的概要设计及编码打下了基础。
第 4 章系统设计
4.1 界面原型及接口设计
4.1.1 挂号部分
图 4.1 挂号部分原型截图
本页面的主要功能:前台首先输入患者的各项基本信息,而后根据患者的需求,选择挂号科室、号别以及门诊医生。若无余号,则告知患者并重新选择。确定填写无误后,点击“提交”,再次确认信息。
本页面的 url 路径为:
本页面请求的数据:病历号、姓名、性别、年龄、身份证号、出生日期、住址、挂号科室、号别、门诊医生、支付方式。
本页面响应的数据:余号、费用。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.2 退号部分
图 4.2 退号部分原型截图
本页面的主要功能:前台首先输入患者的病历号、姓名、身份证号其中若干项(但至少输入一项),然后点击“查询”,系统将显示患者的挂号信息。前台根据患者挂号信息,确认挂号状态无误后,点击“退号”。
本页面的 url 路径为:
本页面请求的数据:病历号、姓名、身份证号。
本页面响应的数据:病历号、姓名、身份证号、挂号日期、看诊科室、状态。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.3 患者费用查询部分
图 4.3 患者费用查询部分原型截图
本页面的主要功能:前台首先输入患者的病历号、姓名、身份证号其中若干项(但至少输入一项),然后点击“查询”,系统将显示患者的费用信息。
本页面的 url 路径为:
本页面请求的数据:病历号、姓名、身份证号。
本页面响应的数据:病历号、姓名、身份证号、缴费项目名称、数量、单价、总价、缴费状态、项目状态、缴费时间。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.4 缴费/退费部分
图 4.4 缴费/退费部分原型截图。
本页面的主要功能:前台首先输入患者的病历号、姓名、身份证号其中若干项(但至少输入一项),然后点击“查询”,系统将显示患者的费用信息。前台可根据目前费用信息的缴费状态和退费状态来进行判断,选择若干项点击“缴费”或“退费”。
本页面的 url 路径为:
本页面请求的数据:病历号、姓名、身份证号。
本页面响应的数据:病历号、姓名、身份证号、缴费项目名称、数量、单价、总价、缴费状态、项目状态、缴费时间。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.5 病历首页部分
图 4.5 病历首页部分原型截图
本页面的主要功能:门诊医生首先确认当前就诊的患者与系统显示的患者是否一致,如果发现当前就诊患者与系统显示患者不一致,告知患者错误并通知正确的患者。
在看诊过程中,门诊医生发现已诊患者仍需要诊断,可点击已诊患者下对应患者的“选择”,令其成为当前患者,同时系统读取该患者信息;如果门诊医生认为当前患者诊断完毕,可点击“诊毕”,将当前患者放入已诊患者中,同时未诊患者中序号最小的患者成为当前患者。
门诊医生确认当前就诊的患者与系统显示的患者一致后开始看诊,根据患者的描述、医生的诊断,填写主诉、现病史、现病史治疗情况、既往史、过敏史、体格检查、初步诊断信息,给出可能的检查建议,点击“保存”。
本页面的 url 路径为:
本页面请求的数据:未诊患者序号、未诊患者姓名、已诊患者序号、已诊患者姓名、当前患者姓名、年龄、病历号。
本页面响应的数据:主诉、现病史、现病史治疗情况、既往史、过敏史、体格检查、初步诊断信息、检查建议。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.6 检验申请部分
图 4.6 检验申请部分原型截图
本页面的主要功能:门诊医生首先确认当前就诊的患者与系统显示的患者是否一致,如果发现当前就诊患者与系统显示患者不一致,告知患者错误并通知正确的患者。
在看诊过程中,门诊医生发现已诊患者仍需要诊断,可点击已诊患者下对应患者的“选择”,令其成为当前患者,同时系统读取该患者信息;如果门诊医生认为当前患者诊断完毕,可点击“诊毕”,将当前患者放入已诊患者中,同时未诊患者中序号最小的患者成为当前患者。
门诊医生根据患者的病情,为患者新增医技(填写医技编码、项目名称,系统会自动生成执行科室、单价等信息)。新增若干条医技后,选择若干项进行删除或开立。
本页面的 url 路径为:
本页面请求的数据:未诊患者序号、未诊患者姓名、已诊患者序号、已诊患者姓名、当前患者姓名、年龄、病历号。
本页面响应的数据:医技编码、项目名称、执行科室、单价、状态、检验结果、常用项目名称。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.7 处置申请部分
图 4.7 处置申请部分原型截图
本页面的主要功能:门诊医生首先确认当前就诊的患者与系统显示的患者是否一致,如果发现当前就诊患者与系统显示患者不一致,告知患者错误并通知正确的患者。
在看诊过程中,门诊医生发现已诊患者仍需要诊断,可点击已诊患者下对应患者的“选择”,令其成为当前患者,同时系统读取该患者信息;如果门诊医生认为当前患者诊断完毕,可点击“诊毕”,将当前患者放入已诊患者中,同时未诊患者中序号最小的患者成为当前患者。
门诊医生根据患者的病情,为患者新增医技(填写医技编码、项目名称,系统会自动生成执行科室、单价等信息)。新增若干条医技后,选择若干项进行删除或开立。
本页面的 url 路径为:
本页面请求的数据:未诊患者序号、未诊患者姓名、已诊患者序号、已诊患者姓名、当前患者姓名、年龄、病历号。
本页面响应的数据:医技编码、项目名称、执行科室、单价、状态、检验结果、常用项目名称。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.8 门诊确诊部分
图 4.8 门诊确诊部分原型截图
本页面的主要功能:门诊医生首先确认当前就诊的患者与系统显示的患者是否一致,如果发现当前就诊患者与系统显示患者不一致,告知患者错误并通知正确的患者。
在看诊过程中,门诊医生发现已诊患者仍需要诊断,可点击已诊患者下对应患者的“选择”,令其成为当前患者,同时系统读取已诊患者中,同时未诊患者中序号最小的患者成为当前患者。
门诊医生根据患者的病情、检查项,给出西医/中医的诊断评估(填写 ICD 编码或名称),并给出诊断结果和处理意见,点击“保存”。
本页面的 url 路径为:
本页面请求的数据:未诊患者序号、未诊患者姓名、已诊患者序号、已诊患者姓名、当前患者姓名、年龄、病历号、检查项的类别、名称、时间和结果。
本页面响应的数据:中医/西医诊断 ICD 编码、名称、时间、诊断结果、处理意见。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.9 成药处方部分
图 4.9 成药处方部分原型截图
本页面的主要功能:门诊医生首先确认当前就诊的患者与系统显示的患者是否一致,如果发现当前就诊患者与系统显示患者不一致,告知患者错误并通知正确的患者。
在看诊过程中,门诊医生发现已诊患者仍需要诊断,可点击已诊患者下对应患者的“选择”,令其成为当前患者,同时系统读取已诊患者中,同时未诊患者中序号最小的患者成为当前患者。
门诊医生根据患者的病情,开立成药处方(填写若干条药品编码、药品名称、药品规格、包装单位、生产厂家、药品剂型、药品类型、药品单价、药物数量、服法用量),填写若干条处方后,可选择若干条处方进行开立。若要修改未开立的处方,可点击其名称进行修改。
本页面的 url 路径为:
本页面请求的数据:未诊患者序号、未诊患者姓名、已诊患者序号、已诊患者姓名、当前患者姓名、年龄、病历号。
本页面响应的数据:药品编码、药品名称、药品规格、包装单位、生产厂家、药品剂型、药品类型、药品单价、药物数量、服法用量、处方名称、处方状态。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.10 草药处方部分
图 4.10 草药处方部分原型截图
本页面的主要功能:门诊医生首先确认当前就诊的患者与系统显示的患者是否一致,如果发现当前就诊患者与系统显示患者不一致,告知患者错误并通知正确的患者。
在看诊过程中,门诊医生发现已诊患者仍需要诊断,可点击已诊患者下对应患者的“选择”,令其成为当前患者,同时系统读取已诊患者中,同时未诊患者中序号最小的患者成为当前患者。
门诊医生根据患者的病情,开立草药处方(填写若干条药品编码、药品名称、药品规格、包装单位、生产厂家、药品剂型、药品类型、药品单价、药物数量),处方的药物确认完毕后,填写服法用量。填写若干条处方后,可选择若干条处方进行开立。若要修改未开立的处方,可点击其名称进行修改。
本页面的 url 路径为:
本页面请求的数据:未诊患者序号、未诊患者姓名、已诊患者序号、已诊患者姓名、当前患者姓名、年龄、病历号。
本页面响应的数据:药品编码、药品名称、药品规格、包装单位、生产厂家、药品剂型、药品类型、药品单价、药物数量、服法用量、处方名称、处方状态。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.11 门诊费用查询部分
图 4.11 门诊费用查询部分原型截图
本页面的主要功能:门诊医生首先确认当前就诊的患者与系统显示的患者是否一致,如果发现当前就诊患者与系统显示患者不一致,告知患者错误并通知正确的患者。
在看诊过程中,门诊医生发现已诊患者仍需要诊断,可点击已诊患者下对应患者的“选择”,令其成为当前患者,同时系统读取已诊患者中,同时未诊患者中序号最小的患者成为当前患者。
系统根据患者的病历号,查询并显示患者的费用名称、金额和状态。
本页面的 url 路径为:
本页面请求的数据:未诊患者序号、未诊患者姓名、已诊患者序号、已诊患者姓名、当前患者姓名、年龄、病历号。
本页面响应的数据:患者费用名称、金额、状态。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.12 患者检验部分
图 4.12 患者检验部分原型截图
本页面的主要功能:医技医生首先确认当前检验的患者与系统显示的患者是否一致,如果发现当前检验患者与系统显示患者不一致,告知患者错误并通知正确的患者。
系统根据患者的病历号,查询其检验信息,医技医生选择若干项检验,点击“确定检验”来完成检验操作。
本页面的 url 路径为:
本页面请求的数据:未检验患者序号、未检验患者姓名、已检验患者序号、已检验患者姓名、当前患者姓名、年龄、病历号、检验名称、数量、单价、总价、状态。
本页面响应的数据:检验状态。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.13 患者处置部分
图 4.13 患者处置部分原型截图
本页面的主要功能:医技医生首先确认当前处置的患者与系统显示的患者是否一致,如果发现当前处置患者与系统显示患者不一致,告知患者错误并通知正确的患者。
系统根据患者的病历号,查询其处置信息,医技医生选择若干项处置,点击“确定处置”来完成处置操作。
本页面的 url 路径为:
本页面请求的数据:未处置患者序号、未处置患者姓名、已处置患者序号、已处置患者姓名、当前患者姓名、年龄、病历号、处置名称、数量、单价、总价、状态。
本页面响应的数据:处置状态。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.14 医技管理部分
图 4.14 医技管理部分原型截图
本页面的主要功能:医技医生首先输入医技名称进行搜索,系统将显示对应的医技编码、项目名称、项目类型、执行科室、单价。医技医生可对其进行编辑或删除或新增医技。
本页面的 url 路径为:
本页面请求的数据:医技编码、项目名称、项目类型、执行科室、单价。
本页面响应的数据:医技编码、项目名称、项目类型、执行科室、单价。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.15 开药部分
图 4.15 开药部分原型截图
本页面的主要功能:药房医生根据患者的姓名和病历号进行搜索和查找,确认后点击“查看”,该患者的姓名、年龄、病历号以及该处方将会显示在右侧。药房医生确认无误后点击“确认发药”,而后可以选择打印。
本页面的 url 路径为:
本页面请求的数据:未开药患者姓名、病历号、已开药患者姓名、病历号。
本页面响应的数据:患者年龄、药品编码、药品名称、规格、包装单位、生产厂家、药品类型、药品单价、药品种类、开具数量、开药医生、小计、总计。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.16 药物管理部分
图 4.16 药物管理部分原型截图
本页面的主要功能:药房医生可根据药物名称进行查询,对药物进行编辑、新增和删除操作。
本页面的 url 路径为:
本页面请求的数据:药品编码、药品名称、规格、包装单位、生产厂家、药品类型、药品单价、药品种类。
本页面响应的数据:药品编码、药品名称、规格、包装单位、生产厂家、药品类型、药品单价、药品种类。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.17 医生排班管理部分
图 4.17 医生排班管理部分原型截图
本页面的主要功能:信息科人员选择科室,系统会显示该科室所有医生和目前的排班信息,信息科人员根据实际情况进行排班,而后点击“保存”。
本页面的 url 路径为:
本页面请求的数据:科室名称、科室医生信息、排班信息。
本页面响应的数据:排班信息
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.18 科室管理部分
图 4.18 科室管理部分原型截图
本页面的主要功能:信息科人员输入科室名、类别、编号进行查询,系统将会显示科室的编号、科室名、类别,信息科人员可以对科室进行编辑或删除,也可以新增科室。
本页面的 url 路径为:
本页面请求的数据:科室名称、科室类别、编号。
本页面响应的数据:科室编号、科室名称、科室类别。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.1.19 用户管理部分
图 4.19 用户管理部分原型截图
本页面的主要功能:信息科人员输入用户 ID、姓名、类别、职称、科室进行查询,系统将会显示用户的的 ID、姓名、类别、职称、科室,信息科人员可以对用户进行编辑或删除,也可以新增用户。
本页面的 url 路径为:
本页面请求的数据:用户 ID、姓名、类别、职称、科室。
本页面响应的数据:用户 ID、姓名、类别、职称、科室。
本页面的目的 url 路径有:
本页面涉及到的接口有:(路由、前后端链接接口)
4.2 数据库设计(ER 图,规范化,物理设计)
4.2.1 项目总 E-R 图
图 4.20 项目总 E-R 图
4.2.2 项目分 E-R 图
图 4.21 系统用户 E-R 图
图 4.22 科室信息 E-R 图
图 4.23 排班信息 E-R 图
图 4.24 患者基本信息 E-R 图
图 4.25 患者挂号信息 E-R 图
图 4.26 医技信息 E-R 图
图 4.27 检验信息 E-R 图
图 4.28 处置信息 E-R 图
图 4.29 患者处方 E-R 图
图 4.30 处方药品 E-R 图
图 4.31 中西药品 E-R 图
图 4.32 病历首页 E-R 图
图 4.33 患者诊断信息 E-R 图
图 4.34 诊断信息库 E-R 图
4.2.3 数据库规范化分析
对数据库分析可知,本数据库的表中的所有数据元素不但要能唯一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系。即数据库中所有属性均不依赖于其它非主属性,故本数据库满足第三范式。
4.2.4 数据库表设计
数据库总表:
图 4.35 数据库总表设计图
数据库分表:
图 4.36 病历首页表设计图
图 4.37 处方药品表设计图
图 4.38 处置信息表设计图
图 4.39 患者处方表设计图
图 4.40 患者处方表设计图
图 4.41 患者基本信息表设计图
图 4.42 患者诊断信息表设计图
图 4.43 检验信息表设计图
图 4.44 科室信息表设计图
图 4.45 排班信息表设计图
图 4.46 系统用户信息表设计图
图 4.47 医技信息表设计图
图 4.48 诊断信息库表设计图
图 4.49 中西药品表设计图
图 4.50 主菜单表设计图
图 4.51 子菜单表设计图
♻️ 资源
大小: 55.3MB
➡️ 资源下载:https://download.csdn.net/download/s1t16/87404179