医院管理系统设计说明书.docx
《医院管理系统设计说明书.docx》由会员分享，可在线阅读，更多相关《医院管理系统设计说明书.docx（43页珍藏版）》请在冰豆网上搜索。
医院管理系统设计说明书
1系统简介
医院管理管理的门面大，信息量大，手续较繁琐，在手工方式下，医护人员要做大量不必要的重复工作、效率低、准确性差，不方便管理、影响工作效率，造成了很多就诊病人得不到合理有效的快捷就诊服务，甚至影响医疗质量。
为此，越来越多的医院加快了信息化建设的步伐。
医院管理系统能有效地优化服务和工作环境、使病人和医生情绪得以放松，提高了服务效率和质量、树立了医院的良好形象，使医院工作可以高效有序的运转，提高了医院的经济效益，促进医院的发展，是医院的管理可以更加有序的进行。
2需求分析
2.1需求调查
医院管理系统是一门融医学、管理、计算机等多种学科为一体的交叉科学，在发达国家已经得到了广泛的应用，并创造了良好的社会效益和经济效益。
医院信息管理系统是现代化医院运营的必要技术支撑和基础设施，实现医院信息管理系统的目的就是为了以更现代化、科学化、规范化的手段来加强医院的管理，提高医院的工作效率，改进医疗质量，从而树立现代医院的新形象，这也是未来医院发展的必然方向。
目前，在我国尤其是西部的许多小型医院，还没有使用计算机管理系统，信息处理基本上还处于手工状态，致使医护和管理人员劳动强度大且工作效率低，大量时间都消耗在事务性工作上，致使"人不能尽其才"；病人排队等候时间长，辗转过程多，影响医院的秩序；在经济管理上也存在漏、跑、错费等现象；医院物资管理由于信息不准确，家底不明，积压浪费，以致"物不能尽其用"。
中国当前经济发展的重点在西部，作为西部大开发的前沿，医院管理计算机化已成为一种趋势。
使用真正先进的计算机管理模式，与市场接轨是许多中小型医院面临的主要问题。
因而开发医院管理信息系统是解决上述问题的有效途径。
医院管理信息系统的有效运行，将提高医院各项工作的效率和质量，减轻各类事务性工作的劳动强度，使医护和管理人员能腾出更多的精力和时间来服务于病人；改善经营管理，堵塞漏洞，保证病人和医院的经济利益；为医院创造很好的经济效益。
2.2数据流图
图2.1总体数据流图
图2.2详细设计数据流图
2.3数据字典
1数据项
数据项名：
用户名
数据项含义说明：
用于登录本系统
别名：
a_User
数据类型：
Longtext
长度：
0
取值范围：
0~0
是否主键：
否
数据项之间的联系：
登录系统的时候除了用户名还需要密码
数据项名：
密码
数据项含义说明：
用于登录本系统
别名：
a_Password
数据类型：
Longtext
长度：
0
取值范围：
0~0
是否主键：
否
数据项之间的联系：
登录系统的时候和用户名一起出现
数据项名：
真实姓名
数据项含义说明：
用于确认用户的身份
别名：
a_Name
数据类型：
Longtext
长度：
0
取值范围：
0~0
是否主键：
否
数据项之间的联系：
同一个姓名只能注册一个账号
数据项名：
邮箱
数据项含义说明：
用户的地址
别名：
a_E_mail
数据类型：
Longtext
长度：
0
取值范围：
0~0
是否主键：
否
数据项之间的联系：
邮箱对应电话
数据项名：
电话
数据项含义说明：
用户的联系方式
别名：
a_Phone
数据类型：
Longtext
长度：
0
取值范围：
0~0
是否主键：
否
数据项之间的联系：
对应邮箱
数据项名：
医生编号
数据项含义说明：
医生的身份认证
别名：
I_Id
数据类型：
int
长度：
11
取值范围：
0~11
是否主键：
是
数据项之间的联系：
与医生姓名一一对应
数据项名：
医生姓名
数据项含义说明：
医生的名字
别名：
d_Name
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
与医生编号一一对应
数据项名：
职称
数据项含义说明：
医生医术的评价
别名：
d_Profession
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
反映医生的医术
数据项名：
出诊时间
数据项含义说明：
医生给患者看病时间
别名：
d_Time
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
每个医生出诊时间不同
数据项名：
所学专业
数据项含义说明：
医生所学的专业
别名：
d_Major
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
不同的科室需要的医生专业不同
数据项名：
负责科室
数据项含义说明：
医生负责的科室
别名：
d_Department
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
同一科室的医生专业应该一样
数据项名：
是否专家
数据项含义说明：
是不是专家
别名：
p_Expert
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
无
数据项名：
病历号
数据项含义说明：
患者的病例
别名：
p_Id
数据类型：
int
长度：
11
取值范围：
0~11
是否主键：
是
数据项之间的联系：
医生写给患者的关于患者病情的诊治情况
数据项名：
病由
数据项含义说明：
生了什么病
别名：
Reason
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
病由决定处方
数据项名：
处方
数据项含义说明：
治疗疾病的药方
别名：
Prescription
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
由病由决定
数据项名：
电话
数据项含义说明：
医生的联系方式
别名：
Phone
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
一个医生对应一个电话
数据项名：
姓名
数据项含义说明：
患者的姓名
别名：
P_Name
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
一个患者对应一个病历号
数据项名：
初诊时间
数据项含义说明：
患者第一次诊断的时间
别名：
p_Time
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
每个病例只有一个初诊时间
数据项名：
联系方式
数据项含义说明：
患者的电话号码
别名：
p_Phone
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
每个患者的联系方式都不同
数据项名：
备注
数据项含义说明：
治疗情况
别名：
p_Note
数据类型：
varchar
长度：
255
取值范围：
0~255
是否主键：
否
数据项之间的联系：
根据治疗情况写处方
数据项名：
药物收费
数据项含义说明：
购买药物所花费的金钱
数据类型：
int
长度：
11
取值范围：
0~11
是否主键：
否
数据项之间的联系：
和处方有联系
数据项名：
挂号费
数据项含义说明：
挂号所花费的金钱
数据类型：
int
长度：
11
取值范围：
0~11
是否主键：
否
数据项之间的联系：
和是否是专家有关系
数据项名：
处置费
数据项含义说明：
劳务所花费的金钱
数据类型：
int
长度：
11
取值范围：
0~11
是否主键：
否
数据项之间的联系：
无
数据项名：
化验费
数据项含义说明：
化验所花费的金钱
数据类型：
int
长度：
11
取值范围：
0~11
是否主键：
否
数据项之间的联系：
和处方也有所联系
2数据结构
数据结构名：
用户登录
含义说明：
用户登录界面所需要的数据
组成：
用户名，密码，真实姓名，邮箱，电话
数据结构名：
医生信息
含义说明：
对于医生的描述
组成：
医生编号，医生姓名，职称，出诊时间，所学专业，负责科室，是否专家
数据结构名：
病人信息
含义说明：
对病人的描述
组成：
病例号，姓名，初诊时间，医生编号，处方，电话，联系方式，备注
数据结构名：
缴费信息
含义说明：
病人的缴费明细
组成：
病历号，药物收费，挂号费，处置费，化验费
3数据流
数据流名：
用户信息录入
说明：
录入用户信息
数据流来源：
用户注册输入
数据流去向：
用户登录
组成：
用户登录
数据流名：
医生信息录入
说明：
录入医生信息
数据流来源：
文件
数据流去向：
医生信息
组成：
医生信息
数据流名：
病人信息录入
说明：
录入病人信息
数据流来源：
文件
数据流去向：
病人信息
组成：
病人信息
数据流名：
病人缴费
说明：
病人根据处方去缴费
数据流来源：
病人信息
数据流去向：
缴费去向
组成：
病人信息，缴费信息
4数据存储
数据存储名：
用户存储
说明：
用户信息的输入
编号：
01
输入的数据流：
用户信息录入
输出的数据流：
用户信息录入
组成：
用户登录
存取频度：
无限制，随时都可以存取
存取方式：
联机处理，添加
数据存储名：
医生存储
说明：
医生信息的输入，修改，删除
编号：
02
输入的数据流：
医生信息录入
输出的数据流：
医生信息录入
组成：
医生信息
存取频度：
每周一次
存取方式：
批处理，添加，修改，删除
数据存储名：
病人存储
说明：
病人信息的输入，修改，删除
编号：
03
输入的数据流：
病人信息录入
输出的数据流：
病人信息录入
组成：
病人信息
存取频度：
无限制，随时都可以存取
存取方式：
批处理，添加，修改，删除
数据存储名：
收费存储
说明：
病人缴费的录入
编号：
04
输入的数据流：
病人缴费
输出的数据流：
病人缴费
组成：
病人信息，缴费信息
存取频度：
无限制，随时都可以存取
存取方式：
批处理，添加
5处理过程
处理过程名：
用户信息处理
说明：
用户信息的输入
输入的数据流：
用户信息录入
输出的数据流：
用户信息录入
处理：
用户信息的输入，只要有人注册就可以输入
数据存储名：
医生信息处理
说明：
医生信息的输入，修改，删除
输入的数据流：
医生信息录入
输出的数据流：
医生信息录入
处理：
医生信息的添加，修改，删除。
每周一次
数据存储名：
病人信息处理
说明：
病人信息的输入，修改，删除
输入的数据流：
病人信息录入
输出的数据流：
病人信息录入
处理：
病人信息的添加，修改，删除，只要有病人随时都可以存取
数据存储名：
收费信息处理
说明：
病人缴费的录入
输入的数据流：
病人缴费
输出的数据流：
病人缴费
处理：
病人所缴纳费用的添加，只要有交易随时都可以存取
存取方式：
批处理，添加
3概念结构设计
根据对功能设计的分析，可以规划整个医院管理系统所涉及的数据实体主要有“医生”、“病人”和“费用”。
“医生”实体与“病人”实体之间是一对多的关系,“病人”实体与“费用”实体之间是多对多的关系。
“医生”实体与“病人”实体之间的联系描述了病人与医生所对应的关系，“病人”实体与“实际费用”实体之间的描述了病人的消费情况。
依次可以使用实体关系模型图（E-R图）来描述这些实体以及它们之间的联系，各个实体的属性等内容。
图3.1总E-R图
4逻辑结构设计
概念结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。
在概念结构设计中，得到医院管理系统的E-R图如图3.1，将此E-R图转换为关系模型。
关系的码用下横线标出。
医生（医生编号、医生姓名、职称、出诊时间、所学专业、负责科室、是否专家）
此为医生实体对应的关系模式。
病人（病例号、姓名、初诊时间、联系方式、备注）
此为病人实体对应的关系模式。
费用（病例号、药物收费、挂号费、处置费、化验费）
此为费用实体对应的关系模式。
5物
升级会员 