医院门诊查询系统.docx
《医院门诊查询系统.docx》由会员分享，可在线阅读，更多相关《医院门诊查询系统.docx（30页珍藏版）》请在冰豆网上搜索。
医院门诊查询系统
摘要
医院门诊查询系统是医院的信息管理系统（MIS）的一部分,其开发主要包括后台数据库的建立和维护以及前端应用程序的开发两个方面。
对于前者要求建立起数据一致性和完整性强、数据安全性好的库。
而对于后者则要求应用程序功能完备,易使用等特点。
根据实际情况经过分析,本系统采用了MVC的设计模式，，即JavaBean（M）+JSP（V）+Servlet（C），将数据库、Servlet、JSP整合在一起，从而实现一个从信息收集、处理到查询的完整的处理方案。
服务器端采用数据库、事务逻辑、用户界面相对独立的结构，各个模块自身扩充方便，却互相之间耦合度非常底，对逻辑层稍做扩充就可以实现一个功能更完善的系统，并且逻辑层实现时使用事务保证数据的完整性。
系统使用的工具平台为IBM公司的Eclipse3.1.1，JSP服务器端的引擎使用了ApacheJakarta软件组织的Tomcat5.0.18，数据库使用符合国际标准的SQL数据语言的MySQL5.0，给系统的兼容性、可移置、安全性、稳定性打下了坚实的基础。
关键字：
数据库，设计模式，Eclipse3.1.1，查询系统。
Thehospitalout-patientservicesearchsystem
ABSTRACT
Thehospitalout-patientservicesearchsystemisapartofhospitalmanagementinformationsystem,whichmainlyincludesbuildingupdata-baseofback-endanddevelopingtheapplicationinterfaceoffront-end.Theformerrequiredconsistencyandintegralityandsecurityofdata.Thelatershouldmaketheapplicationpowerfulandeasilyused.Dependonoursituation,ThissystemadoptedMVCdesignmode,,namelyJavaBean（M）+JSP（V）+Servlet（C）,integratedatabase,Servlet,JSPtogether,carryoutthusafromtheinformationcollections,handletosearchoftheprocessingprojectoftheintegrity.Theservercarriesoppositeandindependentstructureofadoptiondatabase,businesslogic,thecustomerinterface,eachmoldpieceoneselfenlargementconvenience,butmutualofthecouplingmatchadegreeverybottom,cancarryoutasystemwithmoreperfectfunctiontothelogiclayer'sdoesinganenlargementslightly,andthelogiclayerrealizationusetheintegrityofthebusinessassurancedata.
ThetoolterraceofthesystemusageistheEclipseoftheIBMcompany,theJSPservercarryoftheengineusedtheApacheJakartasoftwaretheTomcatoftheorganization,DatabaseweselectedMySQLwhichSQLdatalanguageconformtointernationalstandard.Sothesystemhasthecharacteristicofcompatible、displace、securityandstable.
Keywords：
database,Designmode,Eclipse3.1.1,Searchsystem.
第一章概述
随着人民生活的不断提高和改善，对于医疗保健服务的要求也不断提高，这就造成了管理中的信息量迅猛增长，给医院的管理带来了相当大的难度，目前，以手工管理为主的运行方式，在信息处理过程中已远远达不到医院现行管理的要求到医院现行管理的要求，操作虽然简单，但不能采集对患者诊疗和医院管理十分重要的病人基本信息、预约信息。
因而手工操作带来的病人基本信息的缺失会给就医造成许多问题，甚至差错。
随着信息时代来临,数字化、人性化管理是医院门诊管理的主要趋势和发展方向，信息处理的利器—计算机应用于医院的日常管理为医院的现代化带来了从未有过的动力和机遇，为医疗卫生领域的飞速发展提供了无限潜力。
对门诊和住院病人实行计算机网络化管理医院，门诊查询系统是典型的联机处理系统，具有门诊量大，响应速度快，就诊人次不均匀，工作场所分散等特点，对系统的实时性、安全性和稳定性要求很高。
做到了门诊病人诊疗情况全过程信息共享与追踪，提高了医疗服务质量，并将医院管理推进到精细化管理中。
为广大医务工作人员及病人提供方便采用计算机管理信息系统已成为医院管理科学化和现代化的重要标志，给医院带来了明显的经济效益和社会效益。
为了加快医院系统的信息化步伐，提高医院的业务水平，建设和完善医院信息系已变得十分必要。
系统的建设将本着“以患者为中心”的原则，以方便患者、提高就诊效率为目的，力争为患者提供最满意的服务，同时也将提高医院的社会效益和经济效益。
因此，开发一套医院门诊查询系统是很有必要的。
本文阐述了医院门诊查询系统的系统分析、系统设计、系统实施以及开发本系统的总结。
详细介绍了每个功能模块的设计思路、具体实现和开发技巧。
第二章需求分析
需求分析是指开发人员要准确理解用户的要求，进行细致的调查分析，将用户的需求陈述转化为完整的需求定义，再由需求定义转换到相应的形式功能规约的过程。
需求分析的目标是描述系统应做什么，并使得开发人员和用户就该描述达成共识。
需求分析的任务是找出系统的所有需求并加以描述，同时建立模型。
因此，开发任何一个合格的软件系统，都必须经过需求分析，这样才能使设计出来的软件满足用户的要求，并且解决目标系统“做什么”的问题。
需求分析是软件设计的第一步，是整个软件成功实现的基础，只有真正做好了需求分析，才能真正了解客服需求，以知道下一步的工作，整个软件的实施是建立在需求所分析出的各项功能上的。
接下来就针对医院查询系统的总体需求做一个分析。
2.1系统功能的分析
根据用户的要求，通过对医院门诊查询系统进行详细地了解和分析，整个系统需要实现以下功能。
2.1.1系统整体功能
操作者的权限层次要有明确的分类，进入系统时要进行身份验证。
出于对患者个人隐私的负责，患者的病历记录只能在患者就医期间由主治医生调阅，其他任何人包括管理员无权查阅。
2.1.2患者模块
（如图2-1所示）
可联机注册成为用户，设定自己的登录名及密码。
可按医生姓名自定义查阅。
可基于查询结果进行预约，若指定医生当日预约量已满，则预约失败。
预约随即返回给患者。
可对已经进行的预约情况查看或撤销。
预约成功后可查询主治医生信息、病历信息。
图2-1患者功能需求框图
2.1.3医生模块
（如图2-2所示）
可查看预约患者的情况。
可查询患者的病历。
可创建患者的病历。
可对患者的病历进行修改。
图2-2医生功能需求框图
2.1.4管理员模块
（如图2-3所示）
可添加医生帐号。
可删除医生帐号。
图2-3管理员功能需求框图
2.2UML系统建模
UML（UnifiedModelingLanguage,统一建模语言），是一种面向对象的建模语言。
它的主要作用是帮助用户对软件系统进行面向对象的描述和建模（建模是通过将用户的业务需求映射为代码，保证代码满足这些需求，并能方便地回溯需求的过程），它可以描述软件开发过程从需求分析直到实现和测试的全过程。
使用UML进行系统建模，就是使用面向对象的方法来分析系统，然后用可视化的建模将信息用标准的图形直观地显示出来，以此建立面向地系统模型。
本例主要使用UML在分析、设计、实现过程中相应的视图来进行系统开发的分析，以帮助了解系统功能与系统流程。
2.2.1系统的用例分析
用例（UseCase）是一个叙述型的文档，用来描述参与者（Actor）使用系统完成某个事件时的事情发生顺序。
用例时系统的使用过程，更确切的说，用例不是需求或者功能的规格说明，但用例也展示和体现出了其所描述的过程中的需求情况。
分析阶段最重要的是用例视图的建立，用例视图强调用户系统得到的功能，它是成为参与者的外部用户所能观察到的系统功能的模型图。
通过用户的视图，使用者应该明确系统后续设计阶段所要完成的任务，整个系统直到实现的过程都是围绕需求阶段的用例进行的。
2.2.1.1角色的确定
对角色的确定，需要分析系统涉及的问题领域，明确系统运行的主要任务，根据本系统的需求分析，可以得到如下的任务：
患者要注册用户
患者要查询医生信息
患者要预约医生
患者要查询医生的预约信息
患者要取消预约
患者要查询主治医生的信息
医生根据患者信息提供服务
医生进行查询、修改、删除信息
管理员添加、删除医生帐号
这个UseCase的参与者主要有三个，及患者、医生和管理员。
2.2.1.2用例的创建
UseCase是参与者与系统在交互过程中所需要完成的事务。
一个完整的需求分析，要求必须找出所有的用例。
本系统分析主要的三个部分：
患者请求服务的用例；医生维护患者系统的用例；管理员维护医生的信息的用例，如图2-4所示。
登录
注销
注册
查询医生信息
预约
查询预约信息
取消预约
查询主治医生信息
查询预约患者信息
创建病历
查询患者病历
修改病历
删除病历
添加医生帐户
删除医生帐户
图2-4系统功能的用例图
2.3业务流程分析
对系统功能进行分析时，需从一个实际业务流程的角度将系统调查中有关业务流程的资料都串起来做进一步的分析，业务流程分析可以帮助我们了解该业务的具体处理过程，发现和处理系统调查工作中的错误和疏漏，修改和删除原系统的不合理部分，在新系统基础上优化业务处理流程。
前面已经将系统功能一一理出，而业务流程分析则是在系统功能的基础上将其细化，利用系统调查的资料将业务处理过程中的每一个步骤的图形串起来。
在绘制业务流程的过程中发现问题，分析不足，优化业务处理过程。
所以说绘制业务流程图是分析业务流程的重要步骤。
业务流程图（transactionflowdiagram,TFD），就是用一些规定的符号及连线来表示某个业务处理过程。
业务流程图的绘制基本上按照业务的实际处理步骤和过程绘制。
换句话说，就是一“本”用图形方式反映实际业务处理过程的“流水帐”，绘制出这本“流水帐”对于开发者理顺和优化业务流程是很有帮助的。
通过前面对本系统功能的详细分析，现可以将整个系统的业务流程表示为如图2-5所示。
图2-5业务流程图
第三章系统设计
系统设计是系统开发过程中另一个重要阶段。
在这一阶段我们将要根据前面前一阶段分析的结果，进行设计。
系统设计的主要内容包括系统总体设计、代码设计、数据库设计、输入/输出（I/O）设计。
3.1总体设计
总体设计是根据系统分析的要求和实际情况对系统的总体结构形式和可利用的资源进行大致设计，它是一种宏观、总体上的设计和规划。
本系统是使用基于Bean的MVC模式设计而成的，即JavaBean（M）+JSP（V）+Servlet（C）。
其中Servlet是用来处理请求的事务，充当了控制器（Controller即“C”）的角色，Servlet负责响应客服对业务逻辑的请求并根据用户的请求行为，决定将哪个JSP页面发送给客户。
JSP页面处于表现层，用来表现页面，也就是视图（View即“V”）的角色。
JavaBean则负责数据的处理，也就是模型（Model即“M”）的角色。
结构如图3-1所示。
系统使用MySQL作为数据库，Tomcat作为JSP容器。
请求
（模型）
响应
应用程序服务器企业服务器/数据库
图3-1MVC模型
3.1.1系统设计目标
描述一个比较完整、准确的需求是软件成功的首要因素。
目前，大部分面向对象方法都使用用例。
在实践中，事件用例被证明是捕获需求非常有效的机制。
而用UML进行系统开发正是一个用例不断迭代的过程。
系统的开发过程包括用例驱动、将需求转化为用例、反复选择最重要的用例、将用例的功能分配到类上、最后依据用例测试系统的可执行性。
从应用角度看，当采用面向对象技术设计系统时，如何用各种UML图形从不同层次、不同角度为系统的分析、设计直到实现提供一个复杂的过程，还需要视具体应用情况而定。
通过需求捕获，将系统要完成的功能分析清楚。
根据前面对本系统的组织结构和业务功能的详细分析，整个系统的设计目标是：
本系统可实现信息存储、更新、查询等多项功能，为广大医务工作人员及病人提供方便。
3.1.2系统设计思想
3.1.2.1数据库层－逻辑层－表现层结构
本系统服务器器端采用数据库层－逻辑层－表现层的体系结构，数据库层使用JDBC与底层数据库进行交互，逻辑层封装在java类中，表示层由JSP实现。
这种结构设计使数据库、事务逻辑、用户界面相对独立，各个模块自身扩充方便，且互相之间耦合度非常底，对逻辑层稍做扩充就可以实现一个功能更完善。
服务器端三层结构之间的关系如图3-2所示。
数据库层逻辑层表现层
数据库用户
图3-2服务器端体系结构
3.1.2.2角色模块设计－设计模式
整个系统中有用户：
医生、患者、管理员，它们之间没有相互的操作，因此可以封装到各自独立的类中去。
dboperation包中设计了一个抽象父类DBOperation,具体的角色类（Admin、Patient、Doctor）从它继承。
将它的子类所公用的方法划分成两类进行设计。
其中一类方法在各个子类内部的具体实现相同，这些方法被直接设计在DBOperation类中，供子类继承；另一类方法在各自子类内部的具体实现不相同，这些方法被设计成抽象方法，由子类负责实现。
3.1.2.3与数据库的连接
设计一个类只负责与数据库的连接工作，当与数据库成功连接后，该类将能返回一个可靠的数据库连接对象供其他类使用。
3.1.2.4日志记录
为了便于调试与服务器信息的记录，设计一个类负责将需要的信息记入本地硬盘上的日志文件中。
3.1.2.5辅助事务处理
设计一个类专门负责处理一些辅助性的事务，比如字符串的转码工作。
3.2数据库设计
系统的主要任务是通过大量的数据获得管理所需要的信息，这就必须存储管理大量的数据。
因此建立一个良好的数据库，使整个系统可以迅速、方便、准确地调用和管理所需的数据，是衡量一个系统开发工作好坏的主要指标之一。
3.2.1设计思路
1.确定实体间的关系
首先确定各实体相互关系，这是设计好一个数据库的基础。
本系统中实体间的E-R图如图3-5所示。
图3-5实体关系图
2.将实体和关系转化为表
将各个角色的所有信息分别放在独立的表中，其中包括该角色的全部信息。
选定一个字段作为主键，这个字段存储的信息在整个表中有两两必须相异，比如医生编号（DID）等。
如果表中没有此类信息，可认为加入唯一的ID用于标志，不如患者编号（PID）、管理员编号（AID）等。
3.主键是唯一依赖性
保证表中其他字段只与主键有关系，如果一组信息同时与一个以上的表或者一个表中一个以上的字段有关系，则必须将这组信息抽出去独立构成一张表。
比如本系统中的预约信息，既与医生信息相关，又与患者信息相关，在这里将信息独立构成一张pinqueue表。
4.指定索引
对所有会成为关键字的字段进行索引，以提高查询效率，比如本系统中的Username。
3.2.2表设计
1.医生表（doctor）
用来存储医生的个人信息，其中“Password”字段在记录插入是与“DID”字段信息相同，因此医生在第一次登录后应该及时地更改自己的密码。
如表3-1所示是医生表的详细结构。
表3-1医生表结构
字段名
类型
备注
约束条件
默认值
DID
varchar（5）
医生编号
主键
－
Name
varchar（12）
姓名
索引
－
Age
tinyint（3）unsigned
年龄
－
0
Password
varchar（20）
登录时的密码
初始：
－DID
Sex
tinyint
（1）unsigned
性别
1－男2－女
1
Level
varchar（12）
医生职称
－
－
Section
varchar（20）
所属科室
索引
－
Specialism
varchar（20）
专家门诊科目
－
－
phone
varchar（15）
联系电话
可为空
－
2.患者表（patient）
用来存储患者的个人信息，如表3-2所示是患者表的详细结构。
表3-2患者表的结构
字段名
类型
备注
约束条件
默认值
PID
mediumint（8）unsigned
auto_increment
患者编号
主键
－
Name
varchar（12）
姓名
－
－
Username
varchar（20）
用户名
唯一索引
－
Password
varchar（20）
密码
－
－
Age
tinyint（3）unsigned
年龄
－
0
Sex
tinyint
（1）unsigned
性别
1－男2－女
1
Address
Tinytext
家庭地址
可为空
－
Phone
varchar（15）
联系电话
可为空
－
注：
“PID”字段被设置为“auto_increment”，这样当插入一条记录且“PID”字段的数据为空（null）时。
新记录的“PID”值将由系统自动给出，且给出的值将比表中曾经存在的最大值大1。
这样可以保证整个表中的PID字段在数据类型允许的范围之内没有重复的值。
3.病历记录表（history）
病历表记录了患者的病历信息，以Doctor字段与doctor表建立关系，以Patient字段与patient表建立关系。
当Finished字段设为“1”时，逻辑层将不能对记录进行修改，只能查询。
如表3-3所示是病历记录表的详细结构。
表3-3病历记录表的结构
字段名
类型
备注
约束条件
默认值
HID
intunsigned（10）
auto_increment
病历记录编号
主键
－
Doctor
varchar（5）
主治医生编号
索引
－
Description
Tinytext
症状
－
－
Diagnose
Tinytext
诊断
－
－
Patient
mendiumint（8）unsigned
患者编号
索引
0
Rx
Tinytext
处方
－
－
SDate
Datetime
开始时间
－
0000-00-00
00:
00:
00
FDate
Datetime
结束时间
可为空
0000-00-00
00:
00:
00
Finished
tinyint
（1）unsigned
就诊过程是否结束
1－是0－否
0
4.预约记录表（pinqueue）
预约记录表记录了已预约但尚未创建病历的患者的信息。
在这一阶段患者可以取消预约，删除相应记录，而医生创建病历也会删除记录。
如表3-4所示是预约记录表的详细结构。
表3-4预约记录表
字段名
类型
备注
约束条件
默认值
QID
intunsigned（10）
auto_increment
记录编号
主键
－
Doctor
varchar（5）
主治医生编号
索引
－
Patient
mediumintunsigned
患者编号
索引
0
Date
Datetime
预约时间
－
0000-00-00
00:
00:
00
Day
tinyint
（1）unsigned
预约就诊时间
0－周日
1－周一
2－周二
3－周三
4－周四
5－周五
6－周六
0
tinyint
（1）unsigned
预约就诊时间
0－上午
1－下午
0
5.管理员表（administrator）
管理员表存储了与管理员有关的信息，如用户名、密码、电子邮件、真实姓名等。
其中将管理员登录用户名设为索引，目的是为了提高查询时的效率。
如表3-5所示是管理员表的详细结构。
表3-5管理员表的结构
字段名
类型
备注
约束条件
默认值
AID
tinyint
（2）unsigned
管理员编号
主键
－
Username
varchar（20）
用户名
唯一索引
－
Password
varchar（20）
密码
－
－
Email
varchar（20）
电子邮件
－
－
Name
varchar（12）
姓名
－
－
Phone
varchar（15）
联系电话
可为空
－
6.医生最大可预约数量表（appointment）
本表存储了医生每天可预约的最大数量，在逻辑层中暂时不提供对其的修改操作，只能在管理员添加医生帐户时输入。
以DID字段与doctor表建立关系。
如表3-6所示是医生最大可预约数量表的详细结构。
表3-6医生最大可预约数量表的结构
字段名
类型
备注
约束条件
默认值
DID
varchar（5）
医生编号
－
－
SunA
tinyint（3）unsigned
周日上午最大可预约数
－
0
SunP
tinyint（3）unsigned
周日下午最大可预约数
－
0
MonA
tinyint（3）unsigned
周一上午最大可预约数
－
0
MonP
tinyint（3）unsigned
周一下午最大可预约数
－
0
TueA
tinyint（3）unsigned
升级会员 