数据库设计实训案例医院管理信息系统.docx
《数据库设计实训案例医院管理信息系统.docx》由会员分享，可在线阅读，更多相关《数据库设计实训案例医院管理信息系统.docx（30页珍藏版）》请在冰点文库上搜索。
数据库设计实训案例医院管理信息系统
医院信息化是医院应用信息技术及其产品的过程，是信息技术由局部到全局、由战术层次到战略层次向医院的全面渗透，运用于流程管理、支持医院经营管理的过程。
信息化的实施从自上而下的角度说，必须与医院的制度创新、组织创新和管理创新结合；从自上而下的角度说，必须以作为医院主体的业务人员直接受益及其使用水平的逐步提高为基础。
医院信息系统属于世界上现存的企业及信息系统中最为复杂的一类，这是医院本身的目标、任务和性质决定的；它应用于医院的医疗管理、经济管理等各个方面，牵涉的信息种类十分庞杂；它融合了医院的管理思想和各部门的业务经验，是医院当前运作方式和业务流程的具体体现，同时又在一定程度上反作用于医院当前的运作方式和业务流程：
他实施的技术手段与当前快速发展的信息技术密切相关，实施的广度和深度（如电子日历、电子支付等）又受到社会大环境信息化程度的影响，受到国家和有关部委制定的法律法规的影响。
因此，医院信息化建设工作具有长期性、复杂性和内容的多变性；医院信息系统不是一个简单的、封闭的、静止的软件，而是一个复杂的、开放的、在应用的深度和广度上逐步变化和发展的软件系统。
需求分析分为三个部分：
需求的文字表述、数据流图、数据字典。
一、需求分析
第一部分调查用户需求
本系统的最终用户为医院，我们根据从医院方面取得的图表资料、文字资料以及其他细节方面的信息，根据我们日常生活中的经验，根据我们所做的其他询问和调查，得出用户的下列实际要求：
1、医院的组织机构情况
一所医院的主要构成分为两个部分，一是门诊部门，二是住院部门，医院的所有日常工作都是围绕着这两大部门进行的。
各部门的关系图（即医院的机构组织结构）如下：
2、各部门的业务活动情况
门诊部门：
首先，门诊病人需要到门诊挂号处挂号（如果病人有需要，可以对所要就诊的相应医科进行查询，可查询该医科的当班医生及其基本情况，然后再去挂号），如果是初诊病人要在门诊挂号处登记其基本信息，如姓名、年龄、住址、联系方式等，由挂号处根据病人所提供的信息制成IC卡发放给病人；然后，初诊病人可与复诊病人一样进行挂号和就诊排号，由挂号处处理病人的病历管理；
其次，病人需到门诊收费处缴纳挂号费，并持挂号和收费证明到相应医科就医，经医生诊疗后，由医生开出诊断结果或者处方，检查或检验申请单，如为处方，则病人需持处方单到门诊收费处划价交费，然后持收费证明到门诊药房取药；如为检查或检验申请单，则病人需持申请单到门诊收费处划价交费，然后持收费证明到检查科室或检验科室进行检查或检验；
当门诊药房接到取药处方后，要进行配药和发药，当药房库存的药品减少到一定量的时候，药房人员应到药库办理药品申领，领取所需的药品，而药房需对药品的出库、入库和库存进行管理；
当检查科室或检验科室接到病人的申请后，对病人进行检查或检验，并将检查或检验结果填入结果报告单，交给病人，各科室所做的检查或检验需记录在案。
病人可持检查或检验的结果再到原医科进行复诊，直至医生开出处方或提出医疗建议，最终病人痊愈离院。
3、用户对系统的要求
信息要求：
由于系统的使用主体是医院的管理人员，因此对系统的信息要求可分为以下几个方面：
a、病人信息
首先是病人的基本信息，主要包括病人的姓名，性别，出生年月，年龄，家庭住址，联系方式等；
对于门诊病人，还需要就诊时间，就诊医科，就诊结果，处方记录，检查时间，检查项目，检查结果，检验时间，检验项目，检验结果等；
对于住院病人，还需要入院时间，所在病区，所在医科，床位号，主治医师，用药记录，检查时间，检查项目，检查结果，检验时间，检验项目，检验结果，手术时间，手术相关记录，病人病情变化记录，相关体检记录，出院时间等。
b、医生信息
首先是医生的基本信息，主要包括医生的姓名，性别，出生年月，家庭住址，联系方式，医生的编码，所在医科，工龄，职称等；
对于门诊医生，还需要挂号费用，当天工作量，出诊时间等；
对于住院医生，还需要所在病区，负责病人，诊断记录等。
c、各种单据，证明的信息
各种单据，证明，如医生诊断书，处方单，检验申请单，检查申请单，检验结果报告单，检查结果报告单，收款单，病人医疗记录，手术申请单，手术通知单，病人入院登记单，转科申请单，病人情况登记单，药品提领单，药品发放记录，药品出库单，药品入库单，设备使用记录，器械领用单，器械使用记录等。
d、各种库存信息
各种库存，如药品、制剂、设备、器械以及后勤劳保用品等的信息，包括入库记录，出库记录，库存量，单价等；
处理要求：
系统应当完成以下的信息处理：
a、存储病人信息，医生信息，各种单据、证明的信息，供相应的人员查询；
b、对病人信息进行及时的更新和统计；
c、对医生信息进行及时的更新和统计，并根据统计数字得出相关的其他数据，如根据医生的出诊情况、工龄、工作量、职称等，得出医生工资中相应的应得金额，完成对医生工资的计算和统计，供发放；
d、各种单据、证明以及记录，根据实际需要，进行更新，统计，自动处理，等等，如对病人病情的记录的及时更新，对药品提领情况的及时统计，通过系统，自动生成一些单证，如系统将手术申请单进行相应的处理，根据所存储的信息得出相关信息，如手术可进行时间，手术室地点安排等，进而生成手术通知单；
e、对各种库存信息的及时更新和统计以及相关的自动处理，系统应根据库存量，入库量，出库量，自动得出新的即时的库存量，完成更新，当库存少到一定程度，系统应提出警告，提示管理人员库存不足，使管理人员做出相应的处理；
f、所有原始数据和统计数据进行相关分析，如门诊收入，住院收入，药品收支，物资情况，
医疗信息，病区床位利用率，床位周转率等；
g、对医院所需的各种报表，图形显示，分析报告，各种单据进行打印，以供相关的使用
安全性与完整性要求：
安全性要求：
a、系统应设置访问用户的标识以鉴别是否是合法用户，并要求合法用户设置其密码，保证
用户身份不被盗用；
b、系统应对不同的数据设置不同的访问级别，限制访问用户可查询和处理数据的类别和内容；
c、系统应对不同用户设置不同的权限，区分不同的用户，如区分病人（只能查询医生的出诊情况，医科设置，医生简介和本人的信息），医生（只能查询本医科诊治的病人资料，本人的信息，医院的公共信息等），管理人员（可查询医院相关的运作情况，并可根据其工作内容，录入相关的信息，修改相关的记录），系统管理员（可对系统进行日常维护，包括数据更新，权限设置等），院长（可查询医院所有运作情况（包括医院的医疗管理、经济管理、行政管理等）的数据，医生的信息，以及各种统计和分析结果等）。
完整性要求：
a、各种信息记录的完整性，信息记录内容不能为空；
b、各种数据间相互的联系的正确性；
c、相同的数据在不同记录中的一致性。
4、确定系统的边界
经对前面的需求调查和初步的分析，确定由计算机完成的工作时对数据进行各种管理和处理，具体的工作内容见第二部分，由手工完成的工作主要有对原始数据的录入；不能由计算机生成的，各种数据的更新，包括数据变化后的修改，数据的增加，失效数据或无用数据的删除等；以及系统的日常维护。
第二部分系统功能的设计和划分
根据如上得到的用户需求，我们将本系统按照所完成的功能分成以下几个子系统：
门诊管理子系统
药品管理子系统
住院管理子系统
行政管理子系统
各子系统完成的功能如下：
1、门诊管理子系统
门诊挂号部分：
1．处理门诊病人挂号事务；
2．支持多种挂号类别以及自费、公费、记账等多种挂号病人，支持退号操作；
3．向首次来院就诊的病人发放就医IC卡，登记病人基本信息；
4．建立、维护门诊病历的基本信息。
门诊收费部分：
1．输入门诊病人的处方和各种诊疗项目，由电脑自动划价，同时对指定的项目支持手工划价；
2．收费后，处方信息自动发送到门诊药房；检查、检验项目发送到相应医技科室；
3．具有处方的作废、退费功能；
4．办理持就医IC卡病人的交款、退款和结账手续；
5．查询病人费用明细；
6．查询统计：
收款员缴款报表、收入分类报表；全院收入报表、收入分类报表；临床科室收入、工作量报表；医生收入、工作量报表；医技科室收入、工作量报表。
经上述分析，我们已经得到了对于该系统的基本要求和系统模块的划分，在这些模块中，我们选择门诊管理子系统，住院管理子系统，药品管理子系统（其中，对前两个系统进行了重点设计）进行具体的数据库设计，在需求分析中形成的数据流图如下：
二、数据流图
第一部分：
门诊管理子系统（见图1）
第二部分：
病房管理子系统（见图2）
第三部分：
药品管理子系统（见图3）
三、数据字典
医院信息系统各实体及联系数据字典（注：
重复的则后面涉及时不再在备注中列出，意思很明确的也不再备注。
）：
挂号单数据字典：
属性名
存储代码
类型
长度
备注
挂号号
Gh_no
String
8
挂号单的序列号
挂号类别
Ghlb
String
20
病人所看医科
主治医师
zzys
String
20
主治医师姓名
挂号人姓名
ghrxm
String
20
病人姓名
挂号科室
ghks
String
20
内外科等
挂号日期
Gh_date
String
20
病人挂号日期
处理方案数据字典：
属性名
存储代码
类型
长度
备注
处理方案号
Clfa_no
Int
8
医师号
Ys_no
String
8
医生号码
开出时间
Kc_date
String
20
处理方案内容
Clfa_con
String
100
门诊病历数据字典：
属性名
存储代码
类型
长度
备注
病历号
Bl_no
String
8
病人病号序列
病人姓名
Br_name
String
20
主治医师
Zzys_name
String
20
主治医师姓名
诊断时间
Zd_date
String
20
病人看病时间
病历内容
Bl_con
String
100
病人病历情况
门诊处方数据字典：
属性名
存储代码
类型
长度
备注
处方号
Cf_no
Int
8
处方序列号
主治医师
zzys
String
20
主治医师姓名
病人姓名
Br_name
String
20
病人性别
Br_sex
Char
2
病人年龄
Br_age
Int
8
处方内容
Cf_con
String
100
病人处方内容
收费项目数据字典：
属性名
存储代码
类型
长度
备注
收费项目号
Sfxm_no
Int
8
收费项目序列号
挂号费
Gh_fee
Real
10
挂号花费费用
药品费
Yp_fee
Real
10
药品花费费用
检查费
Jc_fee
Real
10
检查花费费用
检验费
Jy_fee
Real
10
检验花费费用
门诊医师数据字典：
属性名
存储代码
类型
长度
备注
医师号
Ys_no
String
8
门诊医师序列号
科室
Ks
String
10
医师所属科室名
当值日期
Dz_date
String
20
医师值班日期
门诊病人数据字典：
属性名
存储代码
类型
长度
备注
姓名
Name
String
20
门诊病人姓名
年龄
Age
Int
8
性别
Sex
Char
1
就诊时间
Jz_date
String
20
交费情况
jfqk
String
10
病人就诊花费
检验项目数据字典：
属性名
存储代码
类型
长度
备注
检验序号
Jy_no
Int
8
病人检验序列号
检验医师
Jyys
String
20
检验医师序列号
检验时间安排
Jy_date
String
20
检验内容
Jy_con
String
100
检验分析
Jyfx
String
100
病人检验结果分析
检验结果
Jyjg
String
100
检验收费情况
Jy_fee
Real
10
检查项目数据字典：
属性名
存储代码
类型
长度
备注
检查序号
Jc_no
Int
8
病人检查序列号
检查医师
Jcys
String
20
检查医师姓名
检查时间安排
Jc_date
String
20
检查内容
Jc_con
String
100
检查分析
Jcfx
String
100
病人检查结果分析
检查结果
Jcjg
String
100
检查收费情况
Jc_fee
Real
10
工作时间安排数据字典：
属性名
存储代码
类型
长度
备注
工作时间
Gz_date
String
20
门诊部门上班时间
科室
ks
String
10
门诊所属科室名
事假情况
Sjqk
String
50
工作人员事假情况
病假情况
Bjqk
String
50
工作人员病假情况
一、门诊子系统
根据需求分析中画出的门诊子系统的第一层数据流图，可以看出在医院门诊中一切活动都是以病人为核心，而各种处理也是由病人主动去完成，如挂号、检查、检验、交费、取药、看病、做检查检验等。
在整个数据流图中病人处于核心地位，而医院门诊的各个职能部门则完成相应的数据处理操作，如在门急诊挂号处完成。
在需求分析中我们从分析门诊部门的行政结构入手，我们得出门诊子系统存在着5个方面的需求，可以划分为5个次级子系统，从而可以设计出5个概念模式，为下一步的概念结构设计打好基础，这五个概念模式为：
病人自助查询，门急诊挂号，门诊收费，中西药房和医生诊桌子系统。
门诊子系统概念结构
以门诊子系统的第一层数据流图为基础，接下来对于各个稍微复杂的处理过程进行细化，画出其具体数据流图，从而抽象出E-R图，为进一步的逻辑设计打下基础。
而在本子系统的第一层数据流图中，检查项目处理和检验项目处理的数据比较简单，可以很简单的找出其关系表，不再进行细化分析。
另外5个处理过程的具体数据流图如下；
●分数据流图分析
（1）自助查询：
本子系统是用于不熟悉的病人进行查询之用，可进行科室查询、医生查询和挂号科室查询等。
查询中需要的信息有很多，但是并非所有的都需要用数据库查询来完成，对于医院概况、建筑物布局和名称等数据并不需要用数据库来完成，而对于医生资料信息以及当天的当值情况等数据则需要由数据库来完成。
类似这里有两个常用的查询：
（a）某医科有哪些当值医生;（b）查询某医生是否当值以及其简要资料。
（2）挂号处理
病人在已获知挂号信息（挂什么科室，什么医生等）的情况下进行挂号（病人拥有IC卡，则在数据意义上表示医院存在该病人的基础信息）
（3）门诊中西药房发药
（4）门诊收费处收费
（5）医生诊断
●对应于各个分数据流图的E—R图设计为：
（1）自助查询
（2）
挂号处理
（3）门诊中西药房发药
（4）门诊收费处收费
（5）医生诊断
（6）根据上面的分E-R图和门诊子系统的第一层数据流图画出总的E-R图
由于篇幅的问题，不再画出各个实体与其属性的E-R分图，各个实体及其属性可以参看下面列出的说明。
●门诊子系统总E-R图
●实体及相应的属性
实体及相应的属性
门诊医师（医师号,科室、工作时间,姓名,专业技术职称,性别,出生日期,年龄,婚姻状况,职业,出生地,民族,身份证号,国籍,住址,电话,邮政编码,户口地址,备注）
挂号单（挂号号、挂号类别、挂号日期、挂号科室、主治医师、病人姓名）
处理方案（处理方案号、开出时间、处理方案内容、主治医师，病人姓名）
门诊病历（病历号、病人姓名、病历内容、诊断时间、主治医师）
处方（处方号、处方内容、主治医师、病人姓名、病人性别、病人年龄、附注）
收费项目（收费项目号、项目类型、相应序号、收费金额、收费人员、病人姓名）
门诊病人（病人号,姓名,性别,出生日期,年龄,婚姻状况,职业,出生地,民族,身份证号,国籍,工作单位及地址,电话,邮政编码,户口地址,联系人姓名,联系人地址,联系人关系，是否住院,联系人电话）;
检验项目（检验序号、检验医师、检验时间安排、检验内容、检验分析、检验结果，检验收费情况）
检查项目（检查序号、检查医师、检查时间安排、检查内容、检查分析、检查结果、检查收费情况）
工作时间安排（工作时间、所属科室、主治医师）
●联系说明及其相应属性：
支付：
（支付金额、支付时间、支付项目）
生成（门诊处方－药品提领单）：
这里做了简化（少了分E-R图中的中西药房药品实体及相关联系），直接由门诊处方与药品提领单产生联系，原因是为了简化设计。
包括1、包括2、包括3、包括4（医生处理方案与具体处理方案的联系，不需要属性）
包括5（门诊处方－门诊病历）
发出（门诊医生－处理方案）
对应（门诊病人－门诊病历）
在概念设计的基础上，根据设计得到系统总的E-R图，按照概念模式与关系表转化的一般规则，结合实际的需要进行逻辑设计，E—R图中的实体、实体的属性和实体之间的联系转化为关系模式。
最后生成的关系及关系表如下（同时附优化说明）：
1.具体关系表的设计及优化说明
●门诊子系统部分：
1．挂号单（挂号号、挂号类别、挂号日期、科室、病人号、医师号）
说明:
由实体型生成的关系模式,由于门诊医师和挂号单的联系是1:
1,因而将其加入门诊医师的主码加入到挂号单所形成的关系模式中.
优化说明：
由于挂号人姓名与病人号，医师号与主治医师有冗余故删除主治医师和挂号人姓名；另外，挂号科室与后面的科室存在异名同义的矛盾，故改名为科室。
2．处理方案（处理方案号、医师号、开出时间、处理方案内容）
说明:
由处理方案形成的关系模式,门诊医师与处理方案之间为１：
ｎ，故将门诊医师的主码加入到处理方案的关系模式中来。
3．门诊病历（病历号、病人号、病历内容、诊断时间、医师号、处方号）
说明:
由门诊病历形成的关系模式,而门诊病历与门诊处方的联系为1:
1,故将门诊处方的主码处方号加入到门诊病历关系模式中。
另门诊病人与门诊病历为１：
１，故将病人号加入到门诊病人中；另主治医师好改为医师号。
优化说明：
医师号与主治医师有冗余，故删除主治医师。
4．门诊处方（处方号、处理方案号、门诊收费项目号、请领单单号、处方内容、病人号、医师号、附注）
说明：
处理方案与门诊处方以及收费项目与门诊处方均为１：
ｎ。
故将处理方案号、门诊收费项目号加入到其中。
优化说明：
主治医师、病人姓名、病人性别、病人年龄等均是冗余数据，故均应删除，这是因为处方号可函数推导出病人号，而病人号则可函数推导出病人的所有上述信息，故将其删除。
5．门诊收费项目（门诊收费项目号、挂号号、支付时间、项目类型、相应序号、收费金额、收费人员、病人号）
说明:
由门诊收费项目形成的关系模式，又门诊收费项目与挂号单为１：
１，故将挂号号加入到其中.
6．门诊医师（医师号、科室、当值日期）
优化说明：
门诊医师中的属性：
姓名,专业技术职称,性别,出生日期,年龄,婚姻状况,职业,出生地,民族,身份证号,国籍,住址,电话,邮政编码,户口地址,备注均可有医师号函数推出，故将它们删除。
7．门诊病人（病人号、就诊时间、交费情况）
优化说明：
由于姓名、年龄、性别可由病人号函数推出，故将其删除。
8．门诊检验项目（检验序号、医师号、门诊检验时间安排、门诊检验内容、门诊检验分析门诊检验结果、门诊收费项目号、处理方案号）
优化说明：
检验收费情况可由门诊收费项目号函数推导。
检验医师与医师号冗余，故删除。
9．门诊检查项目（检查序号、医师号、门诊检查时间安排、门诊检查内容、门诊检查分析、门诊检查结果、门诊收费项目号、处理方案号）
优化说明同门诊检验项目。
10．工作时间安排（工作时间、科室、医师号）
优化说明：
其中的病假情况、事假情况可由医师关系模式中主码医师号函数推出。
11．挂号收费（挂号号、门诊收费项目号、收费金额）
说明:
由挂号单与门诊收费项目之间形成的一种联系,收费金额是挂号收费的属性.
12．缴纳（病人号、门诊收费项目号、缴纳金额）
说明:
由门诊病人和门诊收费项目之间形成的一种联系,缴纳金额是缴纳的属性.
2．关系表总体设计说明
●由于本系统在进行概念模型设计的时候各个系统的负责人之间曾进行过多次交流，因此在合成的时候没有太多的冲突。
各个部分也能比较好地结合到一起。
●对于门诊检查项目和住院检查项目两张表不进行合并的说明：
1．门诊检查项目（检查序号、医师号、门诊检查时间安排、门诊检查内容、门诊检查分析、门诊检查结果、门诊收费项目号、处理方案号）
2．住院检查项目（检查序号,诊断序号,住院检查日期安排,住院检查负责人员,住院号,住院检查内容,检查结果）;
这两个关系表由于其中有些字段保留了不同的必要信息，因此无法进行合并成为一个表，即是在用户模式下，同一个用户（检查部门工作人员）必须基于两个逻辑表，这里也没有必要像门诊病人与住院病人一样用一个超类病人来处理。
同样，门诊检验项目和住院检验项目也处理为两个没有直接联系得关系
住院收费项目和门诊收费项目之间分成两个关系表处理的原因与上边说明的类似。
3．设计用户子模式
在将概念模型转化为全局逻辑模型后,根据医院系统的局部应用需求,以下设计用户子模式:
●考虑需求
考虑以下的几个需求:
⑴探望人员查阅病人信息
⑵病人查阅其账户信息
⑶医生查阅病人病案信息
⑷院领导综合查询
●定义用户级别
对行政管理人员（院领导）,医师,病人,院外探视人员的级别定义如下:
.
⑴行政管理人员:
对所有表的所有内容都有查看的权限
⑵医师:
对自己所负责病人的所有有关住院病案、门诊病历有修改和查阅的权限,对自己本人的在医师表中的有关项目有查阅的权限
⑶病人:
对自己在收费项目、检查项目、检验项目、手术项目、处方项目中所占的元组有查看的权限.
⑷院外探视人员:
对病人-床位的相应项目有查阅权限
●制作查询子系统:
根据分析需求,我们设计了以下几个查询系统:
医生辅诊子系统、医院领导综合查询子系统、患者导医子系统、探视查询子系统。
⑴医院领导综合查询子系统
提供对医院的医疗管理、经济管理、行政管理方面的信息的各种查询和统计,如:
门诊收入、住院收入、药品收支、物资情况、医疗信息、病区床位使用率等信息.提供报表打印和图形显示,供院领导作辅助决策之用.
在这里创建几个视图:
1收入类（门诊类收入,住院类收入,月份,总费用,利润,与去年同期相比增长额）
注:
门诊类收入由门诊收费项目表的所有收费金额总计计算,一月一次;住院类收入由住院收费项目表的所有收费金额总计计算,同样一月一次.总费用由费用表总计提供（本系统未列入）,前两者两
升级会员 