医院信息系统数据库设计
一、门诊子系统E-R 图
实体及相应的属性
实体及相应的属性
门诊医师( 医师号, 科室、工作时间, 姓名, 专业技术职称, 性别, 出生日期, 年龄, 婚姻状况,
职业, 出生地, 民族, 身份证号, 国籍, 住址, 电话, 邮政编码, 户口地址, 备注)
挂号单(挂号号、挂号类别、挂号日期、挂号科室、主治医师、病人姓名) 处理方案（处理方案号、开出时间、处理方案内容、主治医师，病人姓名）
门诊病历（病历号、病人姓名、病历内容、诊断时间、主治医师）
处方（处方号、处方内容、主治医师、病人姓名、病人性别、病人年龄、附注） 收费项目（收费项目号、项目类型、相应序号、收费金额、收费人员、病人姓名） 门诊病人( 病人号, 姓名, 性别, 出生日期, 年龄, 婚姻状况, 职业, 出生地, 民族, 身份证号, 国
籍, 工作单位及地址, 电话, 邮政编码, 户口地址, 联系人姓名, 联系人地址, 联系人关系，是否住院, 联系人电话);
检验项目（检验序号、检验医师、检验时间安排、检验内容、检验分析、检验结果，检验收
费情况）
检查项目（检查序号、检查医师、检查时间安排、检查内容、检查分析、检查结果、检查收
费情况）
工作时间安排（工作时间、所属科室、主治医师）
联系说明及其相应属性：
支付：（支付金额、支付时间、支付项目）
生成（门诊处方－药品提领单）：这里做了简化(少了分E-R 图中的中西药房药品实体及相关联系) ，直接由门诊处方与药品提领单产生联系，原因是为了简化设计。
包括1、包括2、包括3、包括4（医生处理方案与具体处理方案的联系，不需要属性） 包括5（门诊处方－门诊病历） 发出（门诊医生－处理方案） 对应（门诊病人－门诊病历）
二、住院子系统E-R 图
相应的实体—属性关系如下:
1. 病人(身份证号, 姓名, 出生日期, 性别, 年龄, 婚姻状况, 职业, 出生地, 民族, 国籍, 工作单位及地址, 电话, 邮政编码, 户口地址, 联系人姓名, 联系人地址, 联系人电话, 是否住院) 2. 住院病人(住院号, 姓名, 入院科别, 入院时间)
3. 医生(医师编号, 姓名, 出生日期, 出生地, 民族, 国籍, 户口地址, 婚姻状况, 年龄, 住址, 电话, 专业技术职务, 备注)
4. 住院医生(姓名, 医师编号, 所属科室, 是否当值)
5. 住院病案(病案号, 病人姓名, 住院号, 入院科别, 入院病室, 入院时间, 入院情况, 转科情况, 出院科别, 出院科别, 出院病室, 出院时间, 入院诊断, 入院后确诊时间, 出院诊断, 出院情况, 其他)
6. 床位(床号, 住院号, 姓名, 经管医生, 护理人员号码, 是否空床, 治疗结果, 床位租金, 入院日期, 住院天数, 交费方式)
7. 病区(病区名, 床位数, 负责人, 入住人数, 出院人数, 治愈率, 好转率, 未愈率, 死亡率, 诊断符合率, 床位使用率)
8. 医嘱(诊断序号, 诊断类别, 疾病编码, 疾病名称, 启用日期, 处理日期, 医嘱内容, 领药量, 主治医师, 病人姓名, 住院号, 出院转归, 病理符合)
9. 住院处方(处方号, 诊断序号, 处方内容, 主治医师, 病人姓名, 住院号, 附注)
10. 检查项目(检查序号, 诊断序号, 病人姓名, 住院号, 检查类别, 检查内容, 检查日期安排, 检查负责人员, 检查结果, 附注)
11. 检验项目(检验序号, 诊断序号, 病人姓名, 住院号, 检验类别, 检验内容, 检验日期安排, 检验负责人员, 检验结果, 附注)
12. 手术项目(手术序号, 诊断序号, 手术名称, 手术室号, 病人姓名, 住院号, 主刀医师, 手术日期, 麻醉方式, 切口情况, 手术持续时间, 手术结果)
13. 收费项目(项目列号, 项目内容, 病人姓名, 住院号, 收费类型, 收款日期, 收款员, 收款金额,
结账情况, 结账金额, 是否转账)
14. 入院通知单(通知单号, 门诊医师号, 医师姓名, 病人姓名, 病人号, 诊断建议, 收费情况, 批准与否)
15. 出院通知单(通知单号, 住院医师号, 医师姓名, 病人姓名, 病人号, 诊断建议, 收费情况, 批准与否)
解释一:新加入的“医生”“病人”两个实体. 它们分别是“住院医生”和“住院病人”的超类. 之所以要这样, 原因是由于“住院病人”与“门诊病人”有很多相同的属性, 这样就造成了数据冗余. 而如果让他们相同的属性由一个超类“病人”来拥有的话, “住院病人”与“门诊病人”就可以继承它的所有属性, 这样也形成了与门诊子系统的接口. “住院医生”“门诊医生”和“医生”也是同样的处理.
解释二:对于各类型的预约, 由于其功能比较单一, 可在相应的项目中以“日期安排”的属性来完成其功能(如“检查项目”中用“检查日期安排”来代替“检查预约”). 这样就使总E-R 图比较的简洁了.
解释三:手术项目中涉及到的麻醉药品与器械在此总图中没有反应(画图出现分叉). 由于麻醉药品从属于药品, 因此在“手术项目”中以“麻醉方式”描述其小类编号、药库号和品名, 这样就不用单述“麻醉药品”一个实体了 (“药品”的实体、属性在药品进出管理子系统中描述, 因此总图也不涉及). 对于器械这一个实体, 由于此次只有门诊、住院、药品管理三个子系统, 没有涉及器械的管理, 因此在此图中略去. 如是一个完整的医院信息管理系统则应该加入.
解释四:在图中该加入“出院通知单”这一个实体. 由于图中空余不够, 因此没有画出. 其应与病人发生联系(与“入院通知单”相同).
解释五:对于“住院医生”这个实体应有“工作安排”的这样一个实体与之联系. 但考虑到其只要与“医生”发生联系即可, 这样的联系将在汇总E-R 图是再考虑, 本部分则略去.
至此, 本部分的E-R 设计大体已经结束. 在相应实体的属性中, 必然有相应的冗余部分, 此外, 与其余子系统的衔接还有待在汇总时考虑.
三、药品出入库管理子系统
二、实体及属性：
供应商：{供应商号，地址，电话，信贷状况}；
订 单：{订单号，供应商号，订货项数，订货日期，交货日期，生产地点}； 药 品：{小类编号，品名，规格，单位，数量，单价，金额，生产日期，保质期}； 药 库：{药库号，负责人，类别，面积}；
订单细则：{订单号，细则号，药品编号，单价，数量，规格，总价，批号}； 药品请领单：{编号，领用单位，药品名称，规格，领药量，单价，金额}。
数据字典
医院信息系统各实体及联系数据字典（注：重复的则后面涉及时不再在备注中列出，意思很明确的也不再备注。）：
挂号单数据字典：
处理方案数据字典：
门诊病历数据字典：
门诊处方数据字典：
收费项目数据字典：
门诊医师数据字典： 门诊病人数据字典：
检验项目数据字典：
检查项目数据字典：
工作时间安排数据字典：
供应商数据字典： 订单数据字典：
药品数据字典：
药库数据字典：
订单细则：
药品请领单：
收费项目
医嘱
住院处方
检查项目
检验项目
手术
住院病人 住院医师
床位
病区
医师情况
病人情况
病案
医院信息系统数据库设计
一、门诊子系统E-R 图
实体及相应的属性
实体及相应的属性
门诊医师( 医师号, 科室、工作时间, 姓名, 专业技术职称, 性别, 出生日期, 年龄, 婚姻状况,
职业, 出生地, 民族, 身份证号, 国籍, 住址, 电话, 邮政编码, 户口地址, 备注)
挂号单(挂号号、挂号类别、挂号日期、挂号科室、主治医师、病人姓名) 处理方案（处理方案号、开出时间、处理方案内容、主治医师，病人姓名）
门诊病历（病历号、病人姓名、病历内容、诊断时间、主治医师）
处方（处方号、处方内容、主治医师、病人姓名、病人性别、病人年龄、附注） 收费项目（收费项目号、项目类型、相应序号、收费金额、收费人员、病人姓名） 门诊病人( 病人号, 姓名, 性别, 出生日期, 年龄, 婚姻状况, 职业, 出生地, 民族, 身份证号, 国
籍, 工作单位及地址, 电话, 邮政编码, 户口地址, 联系人姓名, 联系人地址, 联系人关系，是否住院, 联系人电话);
检验项目（检验序号、检验医师、检验时间安排、检验内容、检验分析、检验结果，检验收
费情况）
检查项目（检查序号、检查医师、检查时间安排、检查内容、检查分析、检查结果、检查收
费情况）
工作时间安排（工作时间、所属科室、主治医师）
联系说明及其相应属性：
支付：（支付金额、支付时间、支付项目）
生成（门诊处方－药品提领单）：这里做了简化(少了分E-R 图中的中西药房药品实体及相关联系) ，直接由门诊处方与药品提领单产生联系，原因是为了简化设计。
包括1、包括2、包括3、包括4（医生处理方案与具体处理方案的联系，不需要属性） 包括5（门诊处方－门诊病历） 发出（门诊医生－处理方案） 对应（门诊病人－门诊病历）
二、住院子系统E-R 图
相应的实体—属性关系如下:
1. 病人(身份证号, 姓名, 出生日期, 性别, 年龄, 婚姻状况, 职业, 出生地, 民族, 国籍, 工作单位及地址, 电话, 邮政编码, 户口地址, 联系人姓名, 联系人地址, 联系人电话, 是否住院) 2. 住院病人(住院号, 姓名, 入院科别, 入院时间)
3. 医生(医师编号, 姓名, 出生日期, 出生地, 民族, 国籍, 户口地址, 婚姻状况, 年龄, 住址, 电话, 专业技术职务, 备注)
4. 住院医生(姓名, 医师编号, 所属科室, 是否当值)
5. 住院病案(病案号, 病人姓名, 住院号, 入院科别, 入院病室, 入院时间, 入院情况, 转科情况, 出院科别, 出院科别, 出院病室, 出院时间, 入院诊断, 入院后确诊时间, 出院诊断, 出院情况, 其他)
6. 床位(床号, 住院号, 姓名, 经管医生, 护理人员号码, 是否空床, 治疗结果, 床位租金, 入院日期, 住院天数, 交费方式)
7. 病区(病区名, 床位数, 负责人, 入住人数, 出院人数, 治愈率, 好转率, 未愈率, 死亡率, 诊断符合率, 床位使用率)
8. 医嘱(诊断序号, 诊断类别, 疾病编码, 疾病名称, 启用日期, 处理日期, 医嘱内容, 领药量, 主治医师, 病人姓名, 住院号, 出院转归, 病理符合)
9. 住院处方(处方号, 诊断序号, 处方内容, 主治医师, 病人姓名, 住院号, 附注)
10. 检查项目(检查序号, 诊断序号, 病人姓名, 住院号, 检查类别, 检查内容, 检查日期安排, 检查负责人员, 检查结果, 附注)
11. 检验项目(检验序号, 诊断序号, 病人姓名, 住院号, 检验类别, 检验内容, 检验日期安排, 检验负责人员, 检验结果, 附注)
12. 手术项目(手术序号, 诊断序号, 手术名称, 手术室号, 病人姓名, 住院号, 主刀医师, 手术日期, 麻醉方式, 切口情况, 手术持续时间, 手术结果)
13. 收费项目(项目列号, 项目内容, 病人姓名, 住院号, 收费类型, 收款日期, 收款员, 收款金额,
结账情况, 结账金额, 是否转账)
14. 入院通知单(通知单号, 门诊医师号, 医师姓名, 病人姓名, 病人号, 诊断建议, 收费情况, 批准与否)
15. 出院通知单(通知单号, 住院医师号, 医师姓名, 病人姓名, 病人号, 诊断建议, 收费情况, 批准与否)
解释一:新加入的“医生”“病人”两个实体. 它们分别是“住院医生”和“住院病人”的超类. 之所以要这样, 原因是由于“住院病人”与“门诊病人”有很多相同的属性, 这样就造成了数据冗余. 而如果让他们相同的属性由一个超类“病人”来拥有的话, “住院病人”与“门诊病人”就可以继承它的所有属性, 这样也形成了与门诊子系统的接口. “住院医生”“门诊医生”和“医生”也是同样的处理.
解释二:对于各类型的预约, 由于其功能比较单一, 可在相应的项目中以“日期安排”的属性来完成其功能(如“检查项目”中用“检查日期安排”来代替“检查预约”). 这样就使总E-R 图比较的简洁了.
解释三:手术项目中涉及到的麻醉药品与器械在此总图中没有反应(画图出现分叉). 由于麻醉药品从属于药品, 因此在“手术项目”中以“麻醉方式”描述其小类编号、药库号和品名, 这样就不用单述“麻醉药品”一个实体了 (“药品”的实体、属性在药品进出管理子系统中描述, 因此总图也不涉及). 对于器械这一个实体, 由于此次只有门诊、住院、药品管理三个子系统, 没有涉及器械的管理, 因此在此图中略去. 如是一个完整的医院信息管理系统则应该加入.
解释四:在图中该加入“出院通知单”这一个实体. 由于图中空余不够, 因此没有画出. 其应与病人发生联系(与“入院通知单”相同).
解释五:对于“住院医生”这个实体应有“工作安排”的这样一个实体与之联系. 但考虑到其只要与“医生”发生联系即可, 这样的联系将在汇总E-R 图是再考虑, 本部分则略去.
至此, 本部分的E-R 设计大体已经结束. 在相应实体的属性中, 必然有相应的冗余部分, 此外, 与其余子系统的衔接还有待在汇总时考虑.
三、药品出入库管理子系统
二、实体及属性：
供应商：{供应商号，地址，电话，信贷状况}；
订 单：{订单号，供应商号，订货项数，订货日期，交货日期，生产地点}； 药 品：{小类编号，品名，规格，单位，数量，单价，金额，生产日期，保质期}； 药 库：{药库号，负责人，类别，面积}；
订单细则：{订单号，细则号，药品编号，单价，数量，规格，总价，批号}； 药品请领单：{编号，领用单位，药品名称，规格，领药量，单价，金额}。
数据字典
医院信息系统各实体及联系数据字典（注：重复的则后面涉及时不再在备注中列出，意思很明确的也不再备注。）：
挂号单数据字典：
处理方案数据字典：
门诊病历数据字典：
门诊处方数据字典：
收费项目数据字典：
门诊医师数据字典： 门诊病人数据字典：
检验项目数据字典：
检查项目数据字典：
工作时间安排数据字典：
供应商数据字典： 订单数据字典：
药品数据字典：
药库数据字典：
订单细则：
药品请领单：
收费项目
医嘱
住院处方
检查项目
检验项目
手术
住院病人 住院医师
床位
病区
医师情况
病人情况
病案