注:仅展示部分文档内容和系统截图,需要完整的视频、代码、文章和安装调试环境请私信up主。
-
-
该研究工作的实用价值与理论意义
-
随着科技发展的迅速,收入的增加,人们的生活也发到了很大的改善。但是支出大于收入也让越来越多的人畏惧看病就医,去医院,所以诊所就成了大部分普通人的最佳选择。大部分诊所在这个竞争日益激烈的行业中生存、发展也成为一个重要的课题。通过日常生活观察和网上考察,可以发现国内的诊所存在的一些普遍性问题。
- 信息处理比较陈旧。大部分诊所依旧采用纸质病例,不方便查找的同时,带来的是时间的流失和患者的体验度下降,严重的可能影响到诊所的效益。
- 管理诊所中使用的种类繁多的医药品、各种器械材料不够合理。医药种类繁多,数量大,这也让许多个人诊所的药物统计成了个大难题,医药品的统计和器械的使用记录,也是需要合理安排的一部分。
- 对患者不能进行合理的时间安排。诊所大部分会面临高峰期问题,上下班、上下学的时间点都成了大家看病就医的默认时间,这也让许多诊所头疼。合理安排患者就医时间,可以提高医生的工作效率,也能方便患者就医,倘若实行高峰期预约制,可以大大提高医患的时间舒适度。
- 作为诊所的管理者如何掌握诊所的盈利状况,如何按劳分配诊所的利润[1]。如果一个系统可以统计出医生、科室的上班及面诊时间,这样就可以做到利润的合理分配,对分配的合理性更有支撑力。
医疗信息具有多而杂,即时性强,分布时间长,所以引入信息管理系统是非常必要的。 一个合格的系统需要系统解决以上问题的同时,更要考虑到很多实际问题。诊所在生活中还是比较常见的,它们的规模其实并不大,所以对系统的软硬件投入都比较受限[2],那要实现哪些功能,才会给诊所带来直接的便利呢?对此,以下进行了总结:
- 方便对搜集的数据进行分析、整理,方便使用者对现实工作情况的调整和安排,比如一些科室的工作时间,从而提高诊所的效益。
- 明确工作流程,协助使用者能够及时有效的沟通,节省时间,降低成本。
- 细分和明确责任,提醒医生及时处理工作安排,提高劳动效率。
- 管理诊所的库存,使诊所的每个物品都能及时有效的被利用。
- 较好的维护与患者的关系,切实改善医患关系。
1.3 毕业论文的基本架构和各部分内容介绍
本文按照章节内容共七章进行了详细的阐述:
第1章为引言,简要地阐述了选题的研究背景和研究的重要性,并简要分析了个体门诊患者信息管理系统的发展过程,并对全文的章节和思想进行了总结。
第2章主要是介绍相关技术,以 Windows 10作为开发平台, 采用SSM框架作为后端框架,前端选用前端用 html语言编写,整体采用了MySQL数据库进行数据处理。这一章介绍了有关技术和为什么要利用这一技术来开发这款个体门诊患者信息管理系统。
第3章具体介绍了个体门诊患者信息管理系统的需求,主要介绍个体门诊患者信息管理系统的基本需求,并对个体门诊患者信息管理系统可行性做了详尽的介绍。
第4章为个体门诊患者信息管理系统的设计,具体地介绍了其主要的功能,并提供了相关的数据库。
第5章为本论文的具体实现,对各模块的设计思路、实现方法进行了阐述,提出了相关的设计思路并给出了相关的软硬件接口[4]。
第6章为系统的测试,介绍了本课题的测试目的和实现方式,然后对该系统的主要功能进行了深入的分析,并进行了一些测试。
第7章为本论文的总结与展望,简要总结了本论文的研究内容和实现,并对系统的不足之处提出了完善建议。
3.4非功能需求
(1)在对系统进行存取的过程中,如果用户通过客户机进行存取,那么开发人员就必须对该软件进行测试,以保证该软件的运行性能。由于 MySQL数据库是在开发过程中选择的,它可以通过数据库的高速缓冲来保存数据,调整数据库的参数,从而改善系统的运行效率。由于资料库有快取的特性,使用者在首次使用之后,就可以将资料储存起来,下次使用时就可以直接阅读,而不用重新下载,这种特性也会大大加快使用者的浏览效率。
(2)软件开发商所设计的软件必须具备一定的可靠性和稳定性,以便能够承受一些工作中的工作负荷。不会因一些小小的程式码差错而使您的体系运作。不过,这一次的个体门诊患者信息管理系统需要在系统发生故障后,才能正常工作。
(3)在个体门诊患者信息管理系统的设计中,必须要有多个层次的体系结构,软件开发商要在初期就将自己的职责划分清楚,这样就可以减少后期的维修工作。(4)本网站的个体门诊患者信息管理系统具有弹性的问话功能,当管理员在进行信息的查询时,可以为组态的询问,从而可以有效地提升查询的速度。
3.5功能需求分析
3.5.1用例概述
(1)医生用例图包含系统中医生身份所具有的七项功能,医生用例图如图2所示。
(2)患者用例图包含系统中患者身份所具有的六项功能,患者用例图如图3所示。
(3)管理员用例图包含系统中管理员身份所具有的九项功能,管理员用例图如图4所示。
4.2数据库设计原则
软件开发阶段有一个重要环节是数据库设计,如果软件开发者设计得好数据库的话会对开发工作有好处,在设计数据库的时候要考虑到以后表是否会有扩展性。随着企业的发展,企业的业务需求会逐渐地发生转变,从而导致系统功能需要修改。如果系统功能发生改变的话,系统对应的数据库表也需要发生转变,因此数据库在设计的时候需要考虑到后续修改的需要,数据库概念模型可以利用E-R图进行表示。E-R图又称为实体-联系模型,E-R图通常包括实体、联系和属性。通过这三个方面反映出系统各实体的关系,从概念上来讲就是反映了数据库信息的组织的情况,系统主要实体图如图11、12、13所示。
4.3数据表
数据库的物理架构主要有:数据的存贮结构的确定、数据存取方法的确定。在设计物理结构时,数据库的内部结构非常重要,架构的好坏将直接影响整个系统功能的整体效能。所以,在决定数据库的存储器和存取方式之前,必须认真地分析数据库中所支持的事务类别,才能计算出最符合的设计参数。
数据库配置表是指在数据据库中存储着系统中各种参数配置信息的表,本系统数据库的配置表参数信息如表7所示。
表7 config表
列名 | 数据类型 | 长度 | 约束 |
id | int | 11 | NOT NULL |
name | varchar | 50 | default NULL |
value | varchar | 500 | default NULL |
公告表又叫新闻表,主要用于系统发布公告,本系统数据库的公告表参数信息如表8所示。
收藏表有助于用户查看用户收藏的各项信息,本系统收藏表的各项参数信息如图9所示。
用户表的参数信息如表10所示。
表8 news表
列名 | 数据类型 | 长度 | 约束 |
id | int | 11 | NOT NULL |
title | varchar | 50 | default NULL |
introduction | varchar | 50 | default NULL |
picture | varchar | 50 | default NULL |
content | varchar | 50 | default NULL |
表9 storeup表
列名 | 数据类型 | 长度 | 约束 |
id | int | 11 | NOT NULL |
userid | varchar | 50 | default NULL |
refid | varchar | 50 | default NULL |
tablename | varchar | 50 | default NULL |
name | varchar | 50 | default NULL |
picture | varchar | 50 | default NULL |
表10 users表
列名 | 数据类型 | 长度 | 约束 |
id | int | 11 | NOT NULL |
username | varchar | 50 | default NULL |
password | varchar | 500 | default NULL |
role | varchar | 50 | default NULL |
用户个人信息表利于用户个人信息编辑,方便使用时挂号、病例的描述,有利于医生明确患者基本信息。用户个人信息表的参数信息如表11所示。
诊疗信息表主要是为了方便诊所记录和查看诊疗时间和患者信息,大大缩短了查看病例的时间。诊疗信息表的参数信息如表12所示。
表11 yonghu表
列名 | 数据类型 | 长度 | 约束 |
id | int | 11 | NOT NULL |
yonghuzhanghao | varchar | 50 | default NULL |
yonghuxingming | varchar | 50 | default NULL |
mima | varchar | 50 | default NULL |
xingbie | varchar | 50 | default NULL |
nianling | varchar | 50 | default NULL |
lianxidianhua | varchar | 50 | default NULL |
dianziyouxiang | varchar | 50 | default NULL |
shenfenzheng | varchar | 50 | default NULL |
dizhi | varchar | 50 | default NULL |
money | varchar | 50 | default NULL |
表12 zhenliaoxinxi表
列名 | 数据类型 | 长度 | 约束 |
id | int | 11 | NOT NULL |
userid | varchar | 50 | default NULL |
name | varchar | 50 | default NULL |
phone | varchar | 50 | default NULL |
Zhenliaoshijian | varchar | 50 | default NULL |
isdefault | varchar | 50 | default NULL |
管理员输入用户名和密码之后可以登录到后台管理系统的信息,系统信息的展示通过form表单的形式展示,展示的时候如果数据过多则需要通过后端逻辑接口page进行对数据的分页展示。数据信息能够在前端展示得益于后端逻辑接口通过数据库SQL语句把数据从数据库记录中取出,取出的记录通过R对象把数据从数据库记录传递到前端。管理员可以在后台管理界面中搜索诊疗信息的信息,输入的诊疗信息名称和通过数据库记录查询的信息是否相互匹配,如果匹配的话则应把信息传递到前端界面中显示信息,如果查询不出诊疗信息的信息则应给出一定的提示,新增诊疗信息时,选择诊疗分类,输入诊疗信息的必要信息完成诊疗信息的上传,如图21所示。