医院管理信息系统
位及地址,电话,邮政编码,户口地址,联系人姓名,联系人地址,联系人电话,是否住院) 2.住院病人(住院号,姓名,入院科别,入院时间)
3.医生(医师编号,姓名,出生日期,出生地,民族,国籍,户口地址,婚姻状况,年龄,住址,电话,专业技术职务,备注)
4.住院医生(姓名,医师编号,所属科室,是否当值)
5.住院病案(病案号,病人姓名,住院号,入院科别,入院病室,入院时间,入院情况,转科情况,出院科别,出院科别,出院病室,出院时间,入院诊断,入院后确诊时间,出院诊断,出院情况,其他)
6.床位(床号,住院号,姓名,经管医生,护理人员号码,是否空床,治疗结果,床位租金,入院日期, 住院天数,交费方式)
7.病区(病区名,床位数,负责人,入住人数,出院人数,治愈率,好转率,未愈率,死亡率,诊断符合率,床位使用率)
8.医嘱(诊断序号,诊断类别,疾病编码,疾病名称,启用日期,处理日期,医嘱内容,领药量,主治医师,病人姓名,住院号,出院转归,病理符合)
9.住院处方(处方号,诊断序号,处方内容,主治医师,病人姓名,住院号,附注)
10.检查项目(检查序号,诊断序号,病人姓名,住院号,检查类别,检查内容,检查日期安排,检查负责人员,检查结果,附注)
11.检验项目(检验序号,诊断序号,病人姓名,住院号,检验类别,检验内容,检验日期安排,检验负责人员,检验结果,附注)
12.手术项目(手术序号,诊断序号,手术名称, 手术室号,病人姓名,住院号,主刀医师,手术日期,麻醉方式,切口情况,手术持续时间,手术结果)
13.收费项目(项目列号,项目内容,病人姓名,住院号,收费类型,收款日期,收款员,收款金额,结账情况,结账金额,是否转账)
14.入院通知单(通知单号,门诊医师号,医师姓名,病人姓名,病人号,诊断建议,收费情况,批准与否)
15.出院通知单(通知单号,住院医师号,医师姓名,病人姓名,病人号,诊断建议,收费情况,批准与否)
解释一:新加入的“医生”“病人”两个实体.它们分别是“住院医生”和“住院病人”的超类.之所以要这样,原因是由于“住院病人”与“门诊病人”有很多相同的属性,这样就造成了数据冗余.而如果让他们相同的属性由一个超类“病人”来拥有的话, “住院病人”与“门诊病人”就可以继承它的所有属性,这样也形成了与门诊子系统的接口.“住院医生”“门诊医生”和“医生”也是同样的处理.
解释二:对于各类型的预约,由于其功能比较单一,可在相应的项目中以“日期安排”的属性来完成其功能(如“检查项目”中用“检查日期安排”来代替“检查预约”).这样就使总E-R图比较的简洁了.
解释三:手术项目中涉及到的麻醉药品与器械在此总图中没有反应(画图出现分叉).由于麻醉药品从属于药品,因此在“手术项目”中以“麻醉方式”描述其小类编号、药库号和品名,这样就不用单述“麻醉药品”一个实体了 (“药品”的实体、属性在药品进出管理子系统中描述,因此总图也不涉及).对于器械这一个实体,由于此次只有门诊、住院、药品管理三个子系统,没有涉及器械的管理,因此在此图中略去.如是一个完整的医院信息管理系统则应该加入.
解释四:在图中该加入“出院通知单”这一个实体.由于图中空余不够,因此没有画出.其应与病人发生联系(与“入院通知单”相同).
27
医院管理信息系统
解释五:对于“住院医生”这个实体应有“工作安排”的这样一个实体与之联系.但考虑到其只要与“医生”发生联系即可,这样的联系将在汇总E-R图是再考虑,本部分则略去.
至此,本部分的E-R设计大体已经结束.在相应实体的属性中,必然有相应的冗余部分,此外,与其余子系统的衔接还有待在汇总时考虑.
三、药品出入库管理子系统
一、分E-R图
药 库 1 库 存
1
提
交 n
药品请领单 1
生
存 n
住院处方
二、实体及属性：
n 药 品 1 n 供 应 m 供 应 商 1 参照 交付 n 订单细则 n 组 成 1 n 订 单 n 门诊处方 供应商：{供应商号，地址，电话，信贷状况}；
订 单：{订单号，供应商号，订货项数，订货日期，交货日期，生产地点}；
药 品：{小类编号，品名，规格，单位，数量，单价，金额，生产日期，保质期}； 药 库：{药库号，负责人，类别，面积}；
订单细则：{订单号，细则号，药品编号，单价，数量，规格，总价，批号}； 药品请领单：{编号，领用单位，药品名称，规格，领药量，单价，金额}。
28
医院管理信息系统
逻辑设计
在概念设计的基础上，根据设计得到系统总的E-R图，按照概念模式与关系表转化的一般规则，结合实际的需要进行逻辑设计，E—R图中的实体、实体的属性和实体之间的联系转化为关系模式。最后生成的关系及关系表如下（同时附优化说明）： 1. 具体关系表的设计及优化说明
? 门诊子系统部分：
1．挂号单(挂号号、挂号类别、挂号日期、科室、病人号、医师号)
说明:由实体型生成的关系模式,由于门诊医师和挂号单的联系是1:1,因而将其加入门
诊医师的主码加入到挂号单所形成的关系模式中.
优化说明：由于挂号人姓名与病人号，医师号与主治医师有冗余故删除主治医师和挂号
人姓名；另外，挂号科室与后面的科室存在异名同义的矛盾，故改名为科室。
2．处理方案（处理方案号、医师号、开出时间、处理方案内容）
说明:由处理方案形成的关系模式,门诊医师与处理方案之间为１：ｎ，故将门诊医师的
主码加入到处理方案的关系模式中来。
3．门诊病历（病历号、病人号、病历内容、诊断时间、医师号、处方号）
说明:由门诊病历形成的关系模式,而门诊病历与门诊处方的联系为1:1,故将门诊处方
的主码处方号加入到门诊病历关系模式中。另门诊病人与门诊病历为１：１，故将病人号加入到门诊病人中；另主治医师好改为医师号。
优化说明：医师号与主治医师有冗余，故删除主治医师。
4．门诊处方（处方号、处理方案号、门诊收费项目号、请领单单号、处方内容、病人号、
医师号、附注）
说明：处理方案与门诊处方以及收费项目与门诊处方均为１：ｎ。故将处理方案号、门
诊收费项目号加入到其中。
优化说明：主治医师、病人姓名、病人性别、病人年龄等均是冗余数据，故均应删除，
这是因为处方号可函数推导出病人号，而病人号则可函数推导出病人的所有上述信息，故将其删除。
5．门诊收费项目（门诊收费项目号、挂号号、支付时间、项目类型、相应序号、收费金额、
收费人员、病人号）
说明:由门诊收费项目形成的关系模式，又门诊收费项目与挂号单为１：１，故将挂号
号加入到其中.
6．门诊医师（医师号、科室、当值日期）
优化说明：门诊医师中的属性：姓名,专业技术职称,性别,出生日期,年龄,婚姻状况,职
业,出生地,民族,身份证号,国籍,住址,电话,邮政编码,户口地址, 备注均可有医师号函数推出，故将它们删除。
7．门诊病人（病人号、就诊时间、交费情况）
优化说明：由于姓名、年龄、性别可由病人号函数推出，故将其删除。
8．门诊检验项目（检验序号、医师号、门诊检验时间安排、门诊检验内容、门诊检验分析
门诊检验结果、门诊收费项目号、处理方案号）
优化说明：检验收费情况可由门诊收费项目号函数推导。检验医师与医师号冗余，故删
除。
9．门诊检查项目（检查序号、医师号、门诊检查时间安排、门诊检查内容、门诊检查分析、
门诊检查结果、门诊收费项目号、处理方案号）
29
医院管理信息系统
优化说明同门诊检验项目。
10．工作时间安排（工作时间、科室、医师号）
优化说明：其中的病假情况、事假情况可由医师关系模式中主码医师号函数推出。 11．挂号收费（挂号号、门诊收费项目号、收费金额）
说明:由挂号单与门诊收费项目之间形成的一种联系,收费金额是挂号收费的属性. 12．缴纳（病人号、门诊收费项目号、缴纳金额）
说明:由门诊病人和门诊收费项目之间形成的一种联系,缴纳金额是缴纳的属性.
? 住院子系统部分：
13．住院收费项目(项目序号,项目类型,相应序号,收费类型,收费金额,收款员,结账情况,
结账金额,是否转账);
说明: “项目类型”是指处方,检查,检验,手术或住院;“项目类型” 是指处方序号, 检查
序号, 检验序号,手术序号或入住序号(床位); “收费类型” 是指公费或私费;
14．医嘱 (诊断序号,诊断类别,启用日期,处理日期,医嘱内容,医师号, 住院号,疾病编码); 说明: “诊断类别”指的是医嘱的序号;“诊断类别” 是指处方, 检查, 检验,或手术; “医
嘱内容”是指处方, 检查, 检验,或手术的相关内容
优化说明：其中的主治医师姓名与医师号，住院号与病人姓名，疾病编码与疾病名称这
些两两实体之间局存在冗余，故将主治医师姓名、病人姓名、疾病名称均删除。
15．住院处方( 住院处方号,诊断序号,处方内容,医师号, 住院号,请领单号,附注);
说明: “附注” 是指处方上的注意事项;“药品提领单号”对应由住院处方积累而成的药品
提领单.
优化说明：主治医师号与医师号是异名同义，故改名为医师号。
16．住院检查项目( 检查序号, 诊断序号,住院检查日期安排, 住院检查负责人员,住院号,
住院检查内容, 检查结果);
17．住院检验项目（检验序号, 诊断序号,住院检验日期安排,住院检验负责人员,住院号, 住
院检验内容,住院检验结果);
18．手术( 手术序号,医师号,住院号,手术名称,手术持续时间,手术结果,麻醉方式,切口情
况, 手术室号);
19．住院病人(住院号, 病人名, 入院时间, 转科情况, 入院科别,出院科别); 20．住院医师( 医师号,科室);
21．床位(床号,值班人员号,床位租金,是否空床, 所属病区)
22．病区(病区名,负责人号,床位数,入住人数,出院人数,治疗率,好转率, 未愈率, 死亡率,
诊断符合,床位使用率);
23．医师( 医师号,姓名,专业技术职称,性别,出生日期,年龄,婚姻状况,职业,出生地,民族,
身份证号,国籍,住址,电话,邮政编码,户口地址, 备注);
24．病人( 病人号,姓名,性别,出生日期,年龄,婚姻状况,职业,出生地,民族,身份证号,国籍
工作单位及地址,电话,邮政编码,户口地址,联系人姓名,联系人地址,联系人关系，是否住院, 联系人电话);
25．住院病案( 病案号,病人号,入院科室, 病室,入院日期, 入院诊断,入院情况, 转科情况,
出院科别,出院病室, 出院时间,出院诊断,入院确诊日期,出院情况)
说明: 入院情况是指危,急,一般等; 出院情况是指治愈,好转,无效,加重,死亡及其他情
况;
26．住院医生-病人(医师号,住院号,床号,开始日期,结束日期);
30
医院管理信息系统
说明:由联系“附注”做出此表,因为病人与住院医生之间是m对n的关系;而且该联系有
自己的属性如“开始日期” “结束日期”；
优化说明：病人号与住院号之间存在冗余，将病人号删除。 27．医嘱-病案(诊断单序号,病案号,合并日期 )
说明: 由联系“归档”做出此表.由于“合并日期”此属性需单独列表反映;其指的是医嘱归
入病案的日期.
28．病人-床位(入住序号,病人号,床位号,床位所属病区号,治疗结果,住院天数, 入住时间,
退床时间);
说明: 由联系“入住”做出此表,与“收费项目”便发生联系.之所以要这么做,是由于“床
位”项目与“检查项目” 和“检验项目” “手术项目”是不同的,床位可以没有病人入住,因此不发生收费;而其余几个只要有元组存在就一定是要收费的.此外治疗结果,住院天数, 入住时间,退床时间等属性放于此表反映是较好的.
29．医嘱-手术(手术序号,诊断序号,医师号,住院号)
说明: 由联系“解释4”做出此表. 之所以要这么做,是由于“手术”项目的特殊性.其主要
反映的是手术的种种特性,如主刀医师等,以供单独的查询;将手术序号,诊断序号,主治医师号,主治医师姓名,住院号, 病人姓名等加入到“手术”中则破坏了独立性,因此单独列表.
? 药品出入库子系统部分：
30．供应商（供应商号，地址，电话，信贷情况）；
31．订 单（订单号，供应商号，订货项数，订货日期，交货日期，生产地点）；
32．药 品（药品编号，药库号，品名，规格，单位，数量，单价，金额，生产日期，保质
期）；
33．药 库（药库号，负责人，类别，面积）；
34．订单细则（订单号，细则号，药品编号，单价，数量，规格，总价，批号）；
35．药品请领单（请领号，药库号，领用单位，药品名称，规格，领药量，单价，金额）。 36．供 应（产品号，供应商号，供应量）； 37．生 成（请领单，处方号，生成量）； 注： 药品关系表中包含联系“库存”；
订单关系表中包含联系“交付”； 订单细则关系表中包含联系“参照”、“组成”； 药品请领单关系表中包含联系“提交”。
2．关系表总体设计说明
? 由于本系统在进行概念模型设计的时候各个系统的负责人之间曾进行过多次交流，因此
在合成的时候没有太多的冲突。各个部分也能比较好地结合到一起。 ? 对于门诊检查项目和住院检查项目两张表不进行合并的说明：
1．门诊检查项目（检查序号、医师号、门诊检查时间安排、门诊检查内容、门诊检查分析、
门诊检查结果、门诊收费项目号、处理方案号）
2．住院检查项目( 检查序号, 诊断序号,住院检查日期安排, 住院检查负责人员,住院号,
住院检查内容, 检查结果);
这两个关系表由于其中有些字段保留了不同的必要信息，因此无法进行合并成为一个表，即是在用户模式下，同一个用户（检查部门工作人员）必须基于两个逻辑表，这里也没有必要像门诊病人与住院病人一样用一个超类病人来处理。
31