医院管理系统.docx
《医院管理系统.docx》由会员分享，可在线阅读，更多相关《医院管理系统.docx（32页珍藏版）》请在冰点文库上搜索。
医院管理系统
课程设计报告
学生姓名:
学号:
学院:
经济管理学院
班级:
题目:
医院管理信息系统
住院管理子系统分析与设计
指导教师：
职称:
2010年7月16日
目录
第1章前言1
1.1简介1
1.2系统组织结构调查2
第2章住院管理系统需求分析3
2.1住院管理系统的需求陈述3
2.2需求分析4
2.2.1功能需求4
2.2.2性能需求4
2.3系统需求建模6
2.3.1确定参与者6
2.3.2确定用例7
2.3.3系统用例建模7
2.3.4用例描述7
第3章系统分析11
3.1系统用例建模11
3.1.1住院处管理子系统11
3.1.2详细用例描述13
3.2静态结构模型14
3.2.1类的识别14
3.2.2类的关联分析15
3.2.3类的属性描述16
3.3系统动态模型17
3.3.1系统执行顺序分析17
3.3.2系统的协作分析17
3.3.3系统状态分析19
3.3.4活动分析19
第4章系统设计与实现21
4.1UML体系结构设计21
4.1.1硬件体系结构设计21
4.1.2软件体系结构设计22
4.2对象模型设计22
4.3系统实现24
4.3.1组件图24
4.3.2配置图25
4.3.3部署图25
参考文献27
第1章前言
1.1简介
我国医院管理信息系统的发展过程从70年代末期起，至今也有20多年的历史，大体上可分为四个阶段:
第一阶段:
20世纪70年代末80代初，是相对独立的、单机单任务的信息管理阶段。
第二阶段:
20世纪80年代中后期，是多个项目的综合信息管理，部门级局域网，计算机网络文件服务器，部门级信息系统阶段。
第三阶段:
20世纪90年代，是医院各部门共享的信息系统阶段。
九十年代初开始，一些大医院相继在100M快速以太网上建立了较为完整的医院管理信息系统，以上3个阶段主要着眼于医院管理信息及其管理。
第四阶段:
90年代末至今，是客户机服务器完整的大规模一体化医院管理信息系统阶段，既面向管理，又面向医疗。
早在1995年5月19日在北京由国家卫生部宣布启动实施了金卫1号工程计划，加快了我国医疗卫生信息化的发展，随着互联网络的兴起，在一些大医院开始了对远程医疗的研究和实施，通过Internet传输射线、M班、CT等影像。
总体说来，自90年代起，随着NOVELL网和FOXBASE、FOXFRO数据库日益盛行，完整的医院网络管理系统实现已经成为可能。
因此现在一些有计算机技术力量的医院开始开发适合自己医院的医院管理系统，发达地区、省会城市医院无论在信息系统设计、开发、应用，还是信息系统维护及系统升级能力等方面都具有较高水平,为我们提供许多值得借鉴的经验。
虽然HIS系统在国内已经发展起来，但是就在这个发展过程中，产品的既定模式与用户的定制需求始终是一对难以解决的矛盾，产品的标准化和个性化在开发商和用户之间，犹如跷跷板的两端，很难保持应有的平衡，主要体现在以下几个方面:
1.单位管理方式有一定差异，软件不能通用。
2.软件没有一个统一的标准，难以推广。
3.全国没有一个较高水平、可广泛推广的医院管理软件包。
本课题以UML建模技术为基础，为住院管理分系统中心，体现出充分利用先进计算机技术、集成化设计医院信息管理系统以病人为中心的设计思想。
既要适用于当前医院的医疗管理模式，又可以用于医疗制度改革后的运作方式。
为医院的现代化、国际化和全面的计算机管理提供最有力的支持和保证。
1.2系统组织结构调查
对现行医院管理信息系统进行调查之后，医院管理信息系统主要由住院部管理子系统；门诊部管理子系统；中西药房管理子系统；人事管理子系统；财务管理子系统及后勤管理子系统组成，其组织机构图如图1.1所示。
图1.1医院管理信息系统组织机构图
第2章住院管理系统需求分析
2.1住院管理系统的需求陈述
作为HIS的一个子系统,住院管理子系统由住院登记结算、医嘱及护理、住院药房组成，完成病人入、出、转院的各种基本信息和医疗信息的输入、查询，以及费用的核算，使住院处、病房医嘱、住院药房之间进行数据共享和相互制约，防止漏欠款。
覆盖病人在院期间的全部过程，实现患者住院期间的治疗、护理、用药、费用等住院信息的高度共享。
图2.1住院管理子系统
对住院管理子系统的需求为：
首先到门诊进行挂号，然后门诊对病人进行科室分配，病人到相应的科室进行诊断，医生根据诊断结果开出住院单，当病人接到医生开立的入院通知单后，到住院处办理入院手续，登记基本信息，交纳一定数额的预交金，并分配入院科室。
住院手续办理妥当之后，病房接收病人，给病人安排床位，病房还应按照医生开出的医嘱执行，医嘱的主要内容包括病人的用药单，病房向相应的药房发送药品请领单，从药房领药，然后将药品发给住院病人。
病人经医生诊断康复后，医生开具出院通知单，病人出院时，其所在病房办理出院，然后在住院处办理出院手续，即可出院。
2.2需求分析
2.2.1功能需求
住院信息管理系统是将传统的以人、财、物管理为主的模式，逐步转向面向管理、面向医疗、面向病人三位一体的管理模式，形成“以病人为中心”，以病人就诊信息为主线，以电子病历为目标、以临床信息为中心，深化经济成本核算，并与医院人、财、物管理相结合的管理型信息系统，为医院提供更好、适用的系统解决方案，使医疗过程更加高效、有序、规范，使医院有序、健康性地发展，给患者带来全新的就诊环境和更完善的医疗服务，从而提高医院各职能部门的工作效率和医院现代化管理水平。
住院管理系统是医院信息系统的中的一部分。
本系统完成了以下功能：
（1）入院登记管理。
为病人办理入院登记手续，分配科室、输入系统中。
办理入院病人登记，建立住院号字典库，对于新住院病人，分配新的永久性住院号，再住院病人，则只需输入住院号，即可将病人信息调出，支持住院号、床位查询。
（2）预交款管理。
为病人建立初始帐户，办理预交款记入到病人帐户中。
对在院病员进行预交金警戒线、交费、催款实施的处理。
（3）医嘱录入：
由医生录入，输入住院号，调出病人一般信息。
医嘱录入时，首先录入起始日期和起始时间，录入医嘱项目、用量、用法和频率等。
（4）结算操作管理。
为病人办理出院结算手续，包括中途结算和出院结算，并为病人打印结算发票。
（5）结帐管理。
生成操作员个人日报表，上交钱款。
（6）查询管理。
查询病人住院期间所花的费用信息。
2.2.2性能需求
根据调研，总结其它医院开发实施HIS的经验和教训，我们认为，由于目前还没有一个HIS系统的行业标准，而实施HIS系统，又是发展趋势，因此，各医院只能根据自己的情况选择适合自己的HIS模式，就目前来说没有哪一家医院的HIS系统是适合其它所有医院的，也就是说我们必须结合本单位的情况设计适合自己的HIS系统。
在系统的设计和开发中，以下问题是应该注意的：
新系统应该尽可能地解决现有系统存在的问题。
例如：
减少手工操作和重复劳动，提高计算机管理程度，尽可能的杜绝漏费现象，方便查询、统计，方便数据的管理和备份等等。
由于医院工作的特殊要求，从硬件及软件上都要考虑到有良好的数据量处理能力。
系统应具备较好的可维护性，较长的生存期，避免较短的时间内被推倒重来的情况发生。
针对现行住院管理系统运行状况的调查分析结果，建设本住院管理系统的性能需求主要有如下几个方面：
（l）连续不间断
为了能随时随地为病人提供优质服务，HIS必须是一个24小时不间断连续运行的高度可靠的系统。
（2）时间响应要求
①响应时间（查询方式）
近程终端<=5seconds
远程终端<=15seconds
②更新处理时间<=5seconds
③数据转换和传送时间
数据转换<=60seconds
数据传送<=30seconds
（3）数据量大
任何一个病人的医疗记录都是一部不断增长着的、图文并茂的书，尤其像病案、统计、影像资料等历史信息的保存价值相当高。
因此，整个系统的信息量增长非常快。
HIS应采取相应的技术，解决海量存储，同时要兼顾信息的方便利用。
（4）信息类型多样
伴随病人的医疗信息不仅有文字与数据类型的表达，而且经常需要表格图形、影像等十分复杂的多种类型的表达，而其表达和描述又是比较困难的。
HIS必须能适应这些信息类型的表达。
（5）标准规范的符号语言
受医学学科本身特点的限制，医学信息的符号语言表达相当复杂，而学界对此历来又极少有规范的研究和标准的设计。
在HIS开发过程中应尽量采用己经成熟的公认标准，并始终强调数据格式、特号表示技术信息的规范，严格意义上的电子病历的实现也有待于这一问题的解决。
（6）高质量的信息保密和安全
HIS对信息质量（安全、可靠、完整、真实）及保密性的要求高，病人的医疗记录被作为具法律效力的文件，某些病人的医疗信息被列为国家机密，外籍病人的医疗信息往往以隐私权被要求保护。
（7）良好的人机交互
在开发中应重视良好人机交互性能的设计，包括更好的引导性界面，更方便的在线帮助提示，更简单的操作方法，更易学、快捷的汉字信息录入等，尽力减少用户文字信息的键盘输入。
2.3系统需求建模
在进行用例建模之前，我们首先了解到用例模型描述的是外部执行者（Actor）所理解的系统功能。
它主要用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。
它的重要作用对于我们住院管理系统的分析和设计主要体现在以下几个方面：
首先，它描述了待开发系统（住院管理系统）的功能需求；
其次，它将系统看作黑盒，从外部执行者的角度来理解系统；
再次，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML的各个模型。
从本质上讲，一个用例是用户与计算机之间的一次典型交互作用。
在UML中，用例被定义成系统执行的一系列动作，动作执行的结果能被指定执行者察觉到。
几乎在任何情况下都会使用用例。
用例用来获取需求，规划和控制项目。
用例的获取是需求分析阶段的主要任务之一，而且是首先要做的工作。
大部分用例将在项目的需求分析阶段产生，并且随着工作的深入会发现更多的用例，这些都应及时增添到已有的用例集中。
2.3.1确定参与者
在分析过程开始的时候，我们考虑到获取用例首先要找出系统的执行者。
，有鉴于此，我们通过用户回答一些问题的答案来识别执行者。
1.谁使用系统的主要功能（主要使用者）。
2.谁需要系统支持他们的日常工作。
3.谁来维护、管理使系统正常工作（辅助使用者）。
4.系统需要操纵哪些硬件。
5.系统需要与哪些其它系统交互，包含其它计算机系统和其它应用程序。
6.对系统产生的结果感兴趣的人或事物。
通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：
医生，护士，病人，财务人员。
2.3.2确定用例
在对现行住院管理系统的分析过程中，在我们获取了执行者之后，我们就对每个执行者提出以下问题以获取用例。
1.执行者要求系统提供哪些功能（执行者需要做什么）。
2.执行者需要读、产生、删除、修改或存储的信息有哪些类型。
3.必须提醒执行者的系统事件有哪些，或者执行者必须提醒系统的事件有哪些，怎样把这些事件表示成用例中的功能。
4.为了完整地描述用例，还需要知道执行者的某些典型功能能否被系统自动实现。
除了以上考虑到的问题之外，我们还考虑了一些不针对具体执行者问题（即针对整个系统的问题），以使自己的分析结果更加准确。
1.系统需要何种输入输出，输入从何处来，输出到何处。
2.当前运行系统（也许是一些手工操作而不是计算机系统）的主要问题。
因为系统比较大，因此不可能给出全部的分析过程，因此列举出在住院分系统中一部分比较有代表性的过程。
通过分析可以初步识别出系统的用例为：
挂号、诊断、交费、取药、住院、出院、费用结算、财务核算。
2.3.3系统用例建模
针对HIS系统的流程的分析，我们采用的是面向对象的分析方法（OOA）。
使用用例图来描述参与者与外部用户所能观察到的系统功能的模型图，在此模型中列出了系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。
住院管理系统的用例图如图2.2所示。
2.3.4用例描述
1.入院通知单
概述：
该用例说明用户如何建立病人的入院通知书、病人住院号和病区信息。
前置条件：
门诊医生己经开具病人的“入院通知书”。
后置条件：
建立病人的病区信息，形成可供信息交互的电子版“入院通知书”。
实现过程：
（1）.获得病人的入院通知书（手工开具的入院通知书）。
（2）.输入病人入院信息:
病人姓名、年龄、性别、职业、病区、入院诊断、入院时间等，
新增“病人”。
（3）.如果病人不是第一次住院，则系统需要调出病人信息。
（4）.系统新增“入院通知书”。
（5）.系统将自动生成病人的住院流水号（住院流水号）。
在上面的第二步，如果病人信息己经建立，在入院只需要调出该病人信息。
在上面的第三步，如果病人电子版入院通知书己经建立，则在接诊处只需要调出病人的入院通知书。
2.办理入院
概述：
该用例说明在住院处为病人办理入院，包括分配住院号（自动生成住院流水号）、入院科别、收取押金、发放患者卡，形成病案首页，其触发者是住院处操作人员。
前置条件：
门诊医生己经为病人开具入院通知书，病人不在院。
后置条件：
医院收取病人的预交金，并且办理病人的信息档案。
实现过程（事件流）：
（1）.住院处操作人员获得病人的入院通知书（手工开具）。
（2）.输入病人入院信息:
病人姓名、年龄、性别、职业、入院科别、入院诊断、
入院时间等。
（3）.收取一定数额的预交金。
3.填写信息
概述：
该用例说明如何办理病人信息登记，建立“病人病案”。
前置条件：
病人入院通知书已经存在。
后置条件：
建立病人病案，完备病人住院信息。
实现过程（事件流）：
（1）.查看病人的入院通知书
（2）.分配病人床位信息
（3）.分配医生负责小组
（4）.分配护士责任小组
（5）.系统可根据入院通知书建立初始病案（病案首页中病人基本信息要求与入院通知书大致相同），但允许更改，输入其他信息内容，建立病人病案。
4.医嘱
概述：
医嘱系统的复杂之处在于医嘱的下达，医嘱包括长期医嘱和临时医嘱。
医嘱下达支持常规医嘱和成组医嘱的录入，支持不同类型的药到不同药房领取（如出院带药可在住院药房领，也可在门诊药房领），支持手术医嘱的录入，可以录入不收费的医嘱，如自备，嘱托医嘱。
前置条件：
病区护士办理了入院接收，分配床位。
后置条件：
护士执行医生下达的各种医嘱。
实现过程：
（1）.医生选择需要下达医嘱的病人。
（2）.录入并保存医嘱。
（3）.审核医嘱。
5.费用记账
概述：
由财务人员处理病人各项不由医嘱产生的费用，如一次性消耗品等，产生消
耗品费用清单，并发送财务系统。
前置条件：
病人信息已经建立。
实现过程：
财务人员查看病人信息，同时生成相关的费用信息，确认后对产生的记录费用清单记账。
6.办理出院
概述：
办理在院病人出院。
前置条件：
病人在院，停止所有有效医嘱，费用结清。
后置条件：
病人状态改为不在院，释放其所占有的床位。
实现过程：
（1）.收到病房出院申请。
（2）.出院结算，打印结算清单和发票。
图2.2住院管理系统用例图
第3章系统分析
3.1系统用例建模
3.1.1住院处管理子系统
住院处是病人入院的起始点和病人出院的终止点。
病人的入院，预交金，结算，冲账，费用管理，出院手续都在此办理，此外病人信息的相关维护也在这里进行。
入院登记：
根据门诊医生开具的入院通知单，接受病人入院，完成入院病人病案首页的有关信息录入、修改、删除、打印病案首页。
根据病人属性打印收据。
如果是再入院病人可以刷卡自动调出上一次的入院记录。
病人费用管理：
病人预交金的收取，费用查询，记账。
支持多种结算方式：
现金结算、支票结算、医保结算、公费医疗结算等。
结算有出院结算和中途结算两种。
其中办理出院结算时进行病人费用查询，打印病人出院收据，出院费用包括退款出院、补交出院、欠费出院和出院未结四种方式，查询打印任意出院日期范围、欠款金限额的欠费病人名单及欠费通知单，统计欠款出院费用。
中途结算是给病人在住院期间结清已发生款，进行补交中结、退款中结和欠费中结等在院结算处理。
下面分别针对办理入院、医嘱下达以及办理出院进行用例分析以及详细的用例描述。
图3.1办理入院用例图
图3.2医嘱下达用例图
图3.3办理出院用例图
3.1.2详细用例描述
住院系统复杂而庞大，为了验证该模型的正确性、可靠性和互操作性，因此只能在子系统中抽取比较有代表性的用例进行详细描述。
1.住院处管理一办理入院
概述：
该用例说明在住院处为病人办理入院，包括分配住院号（自动生成住院流水号）、入院科别、收取押金、发放患者卡，形成病案首页，其触发者是住院处操作人员。
前置条件：
门诊医生己经为病人开具入院通知书，病人不在院。
后置条件：
医院收取病人的预交金，并且办理病人的信息档案。
实现过程（事件流）：
（1）.住院处操作人员获得病人的入院通知书（手工开具）。
（2）.输入病人入院信息:
病人姓名、年龄、性别、职业、入院科别、入院诊断、
入院时间等。
（3）.收取一定数额的预交金。
2.医生工作站一医嘱下达
概述：
医嘱系统的复杂之处在于医嘱的下达，医嘱包括长期医嘱和临时医嘱。
医嘱下达支持常规医嘱和成组医嘱的录入，支持不同类型的药到不同药房领取（如出院带药可在住院药房领，也可在门诊药房领），支持手术医嘱的录入，可以录入不收费的医嘱，如自备，嘱托医嘱。
前置条件：
病区护士办理了入院接收，分配床位。
后置条件：
护士执行医生下达的各种医嘱。
实现过程：
（1）.医生选择需要下达医嘱的病人。
（2）.录入并保存医嘱。
（3）.审核医嘱。
3.住院处管理一办理出院
概述：
办理在院病人出院。
前置条件：
病人在院，停止所有有效医嘱，费用结清。
后置条件：
病人状态改为不在院，释放其所占有的床位。
实现过程：
（1）.收到病房出院申请。
（2）.出院结算，打印结算清单和发票。
3.2静态结构模型
3.2.1类的识别
首先，经过调查得到用户对住院管理子系统的需求为：
病人首先到门诊进行挂号，然后门诊对病人进行科室分配，病人到相应的科室进行诊断，医生根据诊断结果开出住院单，当病人接到医生开立的入院通知单后，到住院处办理入院手续，登记基本信息，交纳一定数额的预交金，并分配入院科室。
住院手续办理妥当之后，病房接收病人，给病人安排床位，病房还应按照医生开出的医嘱执行，医嘱的主要内容包括病人的用药单，病房向相应的药房发送药品请领单，从药房领药，然后将药品发给住院病人；病人经医生诊断康复后，医生开具出院通知单，病人出院时，其所在病房办理出院，然后在住院处办理出院手续，即可出院。
我们对以上需求进行初步处理之后，经过非正式分析得出住院管理子模块的初始类为：
门诊、病人、科室、医生、诊断结果、住院单、入院通知单、住院处、入院手续、基本信息、预交金、入院科室、病房、床位、医嘱、用药单、药房、药品请领单、药品、出院通知单、出院手续。
对候选类进行严格的考察筛选，去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象。
删除不正确的或不必要的类与对象，根据冗余标准，入院手续、入院单与入院通知单，出院单与出院手续、用药单与药品请领单分别描述了相同的几类信息，应保留在此问题域中最富于描述力的名称，因此，应该去掉入院手续、出院手续、药品请领单等冗余的类，仅保留入院通知单和出院通知单、用药单这三个类。
现实世界存在许多对象，不能都纳入到系统中，仅需要把与问题密切相关的类与对象放到目标系统中，门诊、科室、入院科室、床位与本系统要实现功能关系不大。
因此，应该去掉候选类门诊、科室、入院科室和床位。
综上所述，在住院管理系统中，经过初步筛选，剩下下列类与对象：
病人、医生、诊断结果、入院通知单、住院处、基本信息、预交金、病房、医嘱、用药单、药房、药品、出院通知单。
3.2.2类的关联分析
在上文中我们将待开发的住院管理系统的对象和类识别了出来，随后，我们通过提取动词词组初步得出它们之间的关联，通过分析前文中的需求陈述，我们找出了陈述中隐含的关联，经过分析之后，初步确定出下列关联：
·到门诊进行挂号
·门诊对病人进行科室分配
·病人到相应的科室进行诊断
·医生根据诊断结果开出住院单
·当病人到住院处办理入院手续，登记基本信息，交纳一定数额的预交金，并分配入院科室。
·病房接收病人，给病人安排床位，
·按照医生开出的医嘱向相应的药房发送药品请领单，从药房领药，然后将药品发给住院病人
·医生开具出院通知单
·病人在住院处办理出院手续
由于以上关联只是初步分析得出，并不合理，需要进一步的筛选初步得出的关联，去掉不正确的或不必要的关联，进一步完善，才能得到正确而合理的关联。
经过筛选之后，得到的关联如下：
·病人到相应的科室进行诊断
·医生根据诊断结果开出住院单
·病人到住院处办理入院手续
·病人在住院处登记基本信息
·病人在住院处交纳一定数额的预交金
·住院处给病人分配入院科室、病房
·按照医生开出的医嘱向相应的药房发送药品请领单
·医生开出医嘱
·病人从药房领药
·医生开具出院通知单
·病人在住院处办理出院手续
经上述分析过程之后得出的住院管理子系统的类图如图3.4所示。
图3.4住院管理系统类图
3.2.3类的属性描述
属性是对象的性质，通过对象类和结构有更深入，更具体的认识。
一般来说确定属性的过程包括分析和选择两个步骤。
属性的确定既与问题有关，也和目标系统的任务有关。
应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。
在分析过程中应该首先找出最重要的属性，以后在逐渐把其余属性添加进去。
此次分析过程中，我们在分析阶段没有考虑那些纯粹用于实现的属性。
只是在最后认真考察了经初步分析而确定下来的那些属性，从中删掉了那些不正确的或不必要的属性。
部分对象类的属性描述如下：
医生——编号、姓名、性别、年龄、所在科室、职位、工龄、籍贯
病人——病人姓名、性别、年龄、住院原因
药品——药品条码进货批号、药品规格、药品单价、药品数量
医院部门（病房、药房）——部门名称、部门编号
3.3系统动态模型
3.3.1系统执行顺序分析
为了实现一个合适的系统，第一步应对医院目前情况进行调研分析，掌握现有的工作模式和工作流程。
经过对现行医院的调查和分析，医院当前的业务主要涉及两大块，一块是门诊业务，另一块是住院业务（把药库归入住院系统），两块业务相对独立。
本文研究的是医院管理系统中的住院管理系统，根据调查得出住院病人的就诊过程如图3.5所示。
图3.5住院病人的就诊过程
在顺序图中，一条竖线代表一个对象，每个时间用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受对象，时间从上向下递增，箭头线在垂直方向上的相对位置表示事件发生的先后。
根据如图3.5的调查结果，可以绘制出如图3.6所示的医院住院管理系统入院管理子模块的顺序图。
3.3.2系统的协作分析
合作图也称为协作图，用于描述相互合作的对象间的交互关系和链接关系。
与顺序图一样，合作图也展示了对象间的动态协作关
升级会员 