基于SSH的医院门诊管理系统的设计与实现.doc
中文题目:基于SSH的医院门诊管理系统的设计与实现 I摘 要人类社会进入二十一世纪,医院作为一个特殊的服务行业,其发展应适应于市场经济的发展。目前,我国的医疗体制正处于发展阶段,需要医疗市场的进一步规范信息化,这就要求医院加强自身的管理,利用现代化的管理工具对医院的工作进行必要的管理。本文设计并且实现了一个基于Web技术的医院门诊管理系统,目的是为了提高医院门诊的工作效率和信息的准确程度,根除现行的人工管理模式存在的效率低下和人员浪费等弊端,进而达到减支增效的目的,并且更好的服务于社会。系统主要以Java EE作为开发基础,主要使用了SSH框架,用MyEclipse作为开发工具,以MySQL作为数据库,以Macromedia公司的Dreamweaver作为界面美化工具,使用Java语言开发,页面采取JSP动态页面开发技术。该系统界面简单,操作方便,容易维护。关键词:医疗体制;医院门诊管理系统;人工管理模式;SSH ABSTRACTWhen the human entered in the society of twenty-first Century, the hospital is as a special service industries, its development should adapt the development in market economy.At present, China's hospital system is at a stage of development, to further standardize the need of medical market, the hospital should strengthen their own management, making the necessary management for hospital work by using modern management tools. The graduation project has designed and implemented a outpatient hospital management system based on Web technology, which is to make the degree of the work efficiency and information improved, to eradicate the shortcomings about the inefficient and the waste of staff of the existing mode of artificial management, then the quality of the medical and service would be improved, and the society will be better served. This system mainly uses JavaEE as the basis of development, its mainly use the SSH framework, its also using MyEclipse as a development tool, using MySQL as the database, using Macromedia's Dreamweaver as the interface landscaping tools, using JAVA language to development, and adopting the technology of JSP dynamic web page to development. The system has a simple interface, good operation and easy maintenance.Key Words: Medical system; Hospital outpatient management system; Artificial management model; SSH 目 录1 项目概述11.1 现系统概述11.2 医院组织机构11.3 系统业务流程21.4 系统功能模块32 系统需求分析52.1 需求陈述52.2 Use Case建模72.2.1 定义活动者72.2.2 USE CASE图82.2.3 用例说明93 系统架构设计273.1 架构设计目标273.2系统架构设计273.3 系统架构类图314 系统详细设计334.1 系统交互图334.1.1系统架构类交互图334.1.2活动者与模块间的交互344.1.3系统协作图374.1.4系统状态图394.1.5系统活动图404.2 业务逻辑对象类设计424.2.1发现业务逻辑类424.2.2业务逻辑对象类图424.3 数据库设计434.3.1 E-R图434.3.2 物理表结构图444.4 开发环境的选择474.4.1 系统开发工具474.4.2 数据库的选择474.4.3 系统网络架构配置475 编码495.1 概述开发工具及编程脚本495.2 脚本习惯说明505.3 脚本516 测试526.1 测试原则及测试方法概述526.2 测试项目测试用例526.3 软件测试结论596.3.1 软件能力596.3.2 缺陷和限制596.3.3 建议596.3.4 测试结论59总 结60致 谢61参考文献62附录A 中文译文63附录B 英文原文66附录C 程序清单691 项目概述1.1 现系统概述医院信息系统(Hospital Information System,HIS)在国际学术界已公认为是新兴的医学信息学(Medical Informatics)的重要分支。美国该领域的著名教授Morris.Collen于1988年曾著文为医院信息系统下了如下定义:利用电子计算机和通讯设备,为医院所属各部门提供患者诊疗信息和行政管理信息的收集、存储、处理、提取和数据交换的能力,并满足所有授权用户的功能需求。而医院门诊管理系统便是医院信息系统的一个小的分支,是组成医院信息系统中不可缺少的一个部分。由于我国是一个人口大国,拥有众多的患者。大多数患者渴望能够及时了解自身病情并希望得到更好的医疗资源,这就使得患者首先要对所就医的医院师资力量、医疗资源有所了解,因此对医院方方面面的咨询成为解决的唯一途径。但是无论是直接向医生咨询病情还是询问医院的其他信息,都不能实时的了解想要得到的信息,并且还会造成医生耗费宝贵的工作时间,因此就需要有一种间接的手段来满足大多数患者对就医信息的咨询,从而缓解医生的压力并且给其他患者就医留下更多宝贵的时间。医院门诊部管理系统是医院管理系统中重要的子系统,对医院的门诊收费有很大的帮助,科技进步已经将人类带入了全新的信息化时代,计算机和网络已经成为人们经营和管理各种企业不可缺少的工具,随着各种新疾病的发现,各种新药物的研发,医生的日常工作就随之显得更加复杂,医院门诊管理系统解决了医院人员、药品、处方信息的同步管理,也使之变的更准确、透明,既提高了工作效率,同时也带来了经济效益,能够杜绝欠费,减少漏费现象,从根不上防止价格的误划,减少重复劳动节约人力成本,提高工作效率,增强各项收费透明度,提高医院的管理水平和社会现象。医院实现信息化是大势所趋,很多有经济条件的医院使用了信息管理系统。传统的系统对中心服务器和网络的依赖性很大,需要投入大笔资金和大量人力和物力,而且随着业务量的增加需要不断地升级软硬件设备。这样的投入对于一些资金比较紧张的中小型医院来说是很难负担的,本课题的目标就是利用较低档的计算机硬件设备实现功能上,性能上和稳定性都比较完善的医院门诊管理系统。1.2 医院组织机构 医院组织机构如图1-1所示。 医院的组织机构,由急诊部门、门诊部门、住院部门组成,各个部门和科室在互相协作下共同完成医院的相关业务。医院组织机构急诊部门门诊部门住院部门科室管理科检查化验科医务管理科药品管理科图1-1 医院组织机构图Fig 1-1 Diagram of the Hospital Organizational Structure1.3 系统业务流程业务流程图符号说明如表1-1所示。表1-1 业务流程图符号说明Table 1-1 Service flow chart symbol explanation符号含义符号说明实体表示单位或个人,圈内写明单位或个人职务的名称。输入输出报表表示输入或输出的报表、计划、单据、报告等,框内写明其名称 。处理表示业务处理,框内写明处理的名称。 账册表示各种帐目、规范、定额手册、报表积累等大量存档信息, 符号内部写明其名称。业务流流向线,表示信息或处理的流向。 根据调研分析及业务分析,系统共需要经过如下几个个环节来办理一项业务, 得到整个系统的业务流程图如图1-2所示。开挂号单挂号收费员患者患者患者申请挂号受理诊断递交挂号单受理确认缴费开病情诊断书开医嘱申请检查化验申请病情诊断受理开处方药药品管理员申请拿药交费确认缴费受理查询病历单医生开检查化验单患者申请检查化验缴费受理检查化验员开检查化验结果单患者医生患者挂号收费员挂号收费员患者受理患者申请取药受理取药图1-2 系统流程图Fig 1-2 The workflow of system1.4 系统功能模块本系统分系统管理员、挂号收费处、药房处、检查化验处、医生和患者6个用户权限。总功能图如图1-3所示。用户管理科室管理医生信息管理患者账户管理检查化验收费标准管理药品信息管理普通门诊挂号专家门诊挂号挂号单查询检查化验单收费管理处方药收费管理处方药管理处方管理化验单管理检查化验单报告管理病历单查询诊断管理处方单查询检查化验单查询医嘱开处方病情诊断开检查单系统管理员药房处挂号收费处检查化验处系统患者医生图1-3 系统功能模块Fig 1-3 Function models of system2 系统需求分析2.1 需求陈述根据调研需求分析得知,该系统共需要19项业务,即:系统管理员负责的6项业务有用户管理、科室管理、医生信息管理、患者账户管理、检查化验收费标准管理和药品信息管理;挂号收费处负责的5项业务的有普通门诊挂号、专家门诊挂号、挂号单查询、检查化验单收费管理和处方药收费管理;药房处负责的1项业务是处方药管理;检查化验处负责的1项业务是检查化验报告管理;医生的负责的3项业务有诊断管理(包括开检查单、病情诊断、开处方和医嘱)、检查化验单管理和处方管理;患者的3项需求业务有病历单查询、检查化验单查询和处方单查询。每项业务具体描述如下:1)用户管理需要系统管理者有权限地对门诊部其他人员进行添加,并且对这些用户进行查看、删除和修改这些操作, 2)科室管理需要系统管理员对医院科室进行唯一的管理,根据需求,管理的内容有科室的添加,以及对添加科室的查询和删除。3)医生信息管理 根据业务的需求,需要管理员对医生信息进行有效的管理,需要管理的内容有所有医生的基本信息情况的记录和对这些信息的完善。4)患者账户管理根据业务的需求,需要系统管理员对所有患者的账户信息进行管理,需要管理的内容有患者账户的基本信息的查看以及对患者账户的删除。5)检查化验收费标准管理根据业务的需求,需要系统管理员对检查化验处的项目进行唯一的有权限的管理,其中需要管理的业务内容有对检查化验标准的添加,并对这些添加的项目进行查询修改和删除。6) 药品信息管理根据业务的需求,需要系统管理员对药品信息进行严格的管理,其中需要管理的业务内容有对药品的添加,并对这些添加的项目进行查询修改和删除。7) 普通门诊挂号调研需求分析后,需要挂号收费处对普通挂号的管理,也就是群众需要在门诊部的挂号处进行普通医生的挂号需求。8)专家门诊挂号调研需求分析后,需要挂号收费处对专家挂号的管理,也就是群众需要在门诊部的挂号处进行专家医生的挂号需求。9)挂号单查询根据业务的需要,需要挂号处对挂号患者的挂号信息进行查询,并且需要把生成的挂号信息交给患者,以便患者自己查询自己的相关业务信息。10)检查化验单收费管理根据业务的需要,需要挂号收费处对患者的检查化验项目进行收费的管理 。11)处方药收费管理根据业务的需要,需要挂号收费处对患者所需要的药品进行收费的管理 。12)检查化验报告管理调研需求分析后,根据业务的需求,需要检查化验处查看患者的检查化验情况,进而对患者展开检查化验服务,并开出检查化验报告单。13)处方药管理调研需求分析后,根据业务的需求,需要处方药管理处查询患者的用药情况,进而对患者展开药品派发服务。14)诊断管理调研需求分析后,根据业务的需求,需要医生对患者的病情进行诊断管理,需要管理的业务内容有对患者病情的查看,为患者提出检查化验项目,进而确定病情,然后开处方药,最后再对患者进行嘱咐,完成需要医生服务的业务。15)检查化验单管理调研需求分析后,根据业务的需求,需要医生查询患者的检查化验情况,以便确定患者的病情,进而对患者进行科学合理的治疗和帮助。16)处方管理调研需求分析后,根据业务的需求,需要医生查询患者的用药情况,以便更合理的为患者开医嘱,进而对患者进行科学合理的治疗和帮助。17)病历单查询根据业务的需求,患者需要对自己的病历进行查看,对自己的病情进行全面的了解,所以需要设置患者的病历单查询业务。18)检查化验单查询根据业务的需求,患者需要对就医时的检查化验报告单进行查看,对自己的病情进行全面的了解,所以需要设置患者的检查化验单查询业务。19)处方单查询根据业务的需求,患者需要对自己就医时开出的处方药品单进行查看,以便了解药品的使用情况,所以需要设置患者的处方单查询业务。2.2 Use Case建模2.2.1 定义活动者参与者(actor)是指系统以外的、需要使用系统或与系统交互的东西,包括人、设备和外部系统等。由于UML是最近几年才在国内流行起来的,所以很多译名并没有统一,如actor就有很多不同的译名,包括参与者、活动者、执行者和行动者等1。根据系统的需求可以确定6个活动者,即系统管理员、挂号收费员、医生、患者、检查化验管理员和处方药管理员。系统管理员通过受理权限登陆系统,需要进行用户管理, 对门诊部其他人员进行添加,并且对这些用户进行查看、删除和修改操作,对科室进行管理, 管理的内容有科室的添加,以及对添加科室的查询和删除,对医生信息进行有效的管理,需要管理的内容有所有医生的基本信息情况的记录和对这些信息的完善, 对所有患者的账户信息进行管理,需要管理的内容有患者账户的基本信息的查看以及对患者账户的删除, 对检查化验处的项目进行唯一的有权限的管理,其中需要管理的业务内容有对检查化验标准的添加,并对这些添加的项目进行查询修改和删除,对药品信息进行严格的管理,其中需要管理的业务内容有对药品的添加,并对这些添加的项目进行查询修改和删除。挂号收费员需要给患者进行挂号收费业务的管理,需要挂号收费处对普通挂号进行管理,也就是群众需要在门诊部的挂号处进行普通医生的挂号需求,相对普通挂号,还有专家挂号,即需要挂号收费处对专家挂号的管理,也就是群众需要在门诊部的挂号处进行专家医生的挂号需求,根据业务的需要,需要挂号处对挂号患者的挂号信息进行查询,并且需要把生成的挂号信息交给患者,以便患者自己查询自己的相关业务信息,挂号收费处还需要对患者的检查化验项目和处方药项目进行收费的管理 。医生人员需要对患者办理相关的业务,首先需要对患者的病情进行诊断管理,需要管理的业务内容有对患者病情的查看,为患者提出检查化验项目,进而确定病情,然后开处方药,最后再对患者进行嘱咐,完成需要医生服务的业务,根据业务的需求,需要医生查询患者的检查化验情况和用药情况,以便确定患者的病情,进而对患者进行科学合理的治疗和帮助。患者需要办理的业务主要有一些查询项目,患者需要对自己的病历进行查看,对自己的病情进行全面的了解,对就医时的检查化验报告单进行查看, 根据业务的需求,患者还需要对自己就医时开出的处方药品单进行查看。检查化验管理员需要查看患者的检查化验情况,进而对患者展开检查化验服务,并开出检查化验报告单。 处方药管理处需要进行患者的药品管理业务,查询患者的用药情况,进而对患者展开药品派发服务。2.2.2 Use Case图在计算机软件系统的分析和设计中,首先需要准确地描述用户需求中的功能需求,以便进一步确定系统中应该建立那些对象。Use Case图是一种描述用例的可视化工具,它用简单的图形元素表示出系统的活动者,Use Case,以及他们之间的关系,准确地表达了活动者与系统地交互情况和系统所能提供地服务2根据系统需求分析,结合上节系统活动者的定义分析,得到医院门诊管理系统业务的19个用例如下:1)用户管理2)科室管理3)医院信息管理4)患者账户管理5)检查化验收费标准管理6)药品信息管理7)普通门诊挂号8)专家门诊挂号9)挂号单查询10)检查化验收费管理11)处方药收费管理12)诊断管理13)检查化验报告单管理14) 处方管理15) 病历单查询16)检查化验单查询17)处方单查询18)检查化验报告管理19) 处方药管理结合活动者和用例得到系统的用例图如图2-1所示。图2-1 系统Use Case 图Fig2-1 Use Case for system 2.2.3 用例说明用户管理环节需要完成系统管理者有权限地对门诊部其他人员进行添加,并且对这些用户进行查看、删除和修改操作,经分析得到用户管理阶段用例图如图2-2所示。图2-2用户管理Use Case 图Fig2-2 Use Case for user management根据如上用户管理用例图得到用户管理用例说明如表2-1所示。表2-1用户管理用例说明Table2-1 Use Case descriptions for user management 用例名称用户管理用例描述 当一个新用户被添加或被查询并进行用户信息查看和修改删除的时候是这个用例的开始。它处理一个新用户的账户建立和基本信息的登记,以及对所有已注册用户基本信息的查看、删除、修改等问题,但是当系统管理员完成了一个新用户的创建或对一个已注册用户的查看、修改或删除的时候,它就结束了参与者系统管理员优先级1状态通过审查前置条件系统管理员以权限登陆进入系统后置条件添加一个用户;删除或更新一个已注册用户基本操作流程1) 系统管理员收到一个新用户注册请求2) 系统显示添加用户界面3) 系统管理员填写新用户的注册信息4) 填写完整后提交信息5) 正确提交后自动退出注册添加页面6) 新用户添加成功可选操作流程在添加注册途中放弃注册,退出注册页面在按照用户名查询出需要的用户后,对该用户进行基本信息查询,然后点击返回在按照用户名查询出需要的用户后,对该用户进行基本信息修改,提交后自动返回用户管理界面在按照用户名查询出需要的用户后,对该用户进行删除操作,用户列表进行更新,该用户从列表中消失,页面自动返回用户管理界面被泛化的用例无被包含的用例无被扩展的用例无科室管理环节需要系统管理员对医院科室进行唯一的管理,根据需求,管理的内容有科室的添加,以及对添加科室的查询和删除,经分析得到科室管理阶段用例图如图2-3所示。图2-3科室管理Use Case 图Fig2-3 Use Case for department management根据如上科室管理用例图得到科室管理用例说明如表2-3所示。表2-2科室管理用例说明Table2-2 Use Case descriptions for department management 用例名称科室管理用例描述当一个科室被添加或是被查询并进行查看和删除的时候是这个用例的开始。它处理一个新科室的基本信息的登记,以及对所有已注册的科室的基本信息的查看和删除的问题,但是当系统管理员完成了一个新科室的创建或对一个已注册科室的查看或删除的时候,它就结束了参与者系统管理员优先级1状态通过审查前置条件系统管理员以权限登陆进入系统后置条件添加一个科室;删除一个已登记科室基本操作流程1) 系统管理员收到一个新科室登记请求2) 系统显示添加科室界面3) 系统管理员填写新科室的注册信息4) 填写完整后提交信息5) 正确提交后自动退出注册添加页面6) 新用户添加成功可选操作流程在添加途中放弃登记,退出登记页面在按照科室名查询出需要的科室后,对该科室进行基本信息查询,然后点击返回在按照科室名查询出需要的用户后,对该科室进行删除操作,用户列表进行更新,该用户从列表中消失,页面自动返回用户管理界面被泛化的用例无被包含的用例无被扩展的用例无医生信息管理环节需要管理员对医生信息进行有效的管理,需要管理的内容有所有医生的基本信息情况的记录和对这些信息的完善操作,经分析得到医生信息管理阶段用例图如图2-4所示。图2-4医生信息管理Use Case 图Fig2-4 Use Case for doctor of information management根据如上医生信息管理用例图得到医生信息管理用例说明如表2-3所示。表2-3医生信息管理用例说明Table2-3 Doctor of information management use case descriptions用例名称医生信息管理用例描述当对医生信息管理的时候是这个用例的开始。它处理医生信息按条件查询并进行医生信息查看和医生信息查询的问题,但是当系统管理员完成了一个医生信息的查看或完善的时候,它就结束了参与者系统管理员优先级1状态通过审查前置条件系统管理员以权限登陆进入系统后置条件更新一个已注册医生的信息;基本操作流程系统管理员收到一个需要完善医生信息的请求系统显示医生信息管理界面系统管理员查询需要完善信息的医生找到以后填写完善该医生信息正确提交后自动退出完善操作界面医生信息完善填写成功可选操作流程在添加完善信息途中放弃添加,返回添加前的页面在按照用户名或科室名或医生级别查询出需要的用户后,对该用户进行基本信息查询,然后点击返回,返回到医生信息管理界面被泛化的用例无被包含的用例无被扩展的用例无患者账户管理环节需要系统管理员对所有患者的账户信息进行管理,需要管理的内容有患者账户的基本信息的查看以及对患者账户的删除,经分析得到患者账户管理阶段用例图如图2-5所示。图2-5患者账户管理Use Case 图Fig2-5 Use Case for the patient account management根据如上患者账户管理用例图得到患者账户管理用例说明如表2-3所示。表2-4患者账户管理用例说明Table 2-4 The patient account management use case descriptions用例名称患者账户管理用例描述当一个患者信息被查询的时候是这个用例的开始。它处理一个患者账户信息的查看和删除的问题,但是当系统管理员完成了一个患者账户的查看或删除的时候,它就结束了参与者系统管理员优先级1状态通过审查前置条件系统管理员以权限登陆进入系统后置条件可能要删除一个患者账户基本操作流程1) 系统管理员收到一个患者账户信息查询请求2) 系统显示患者账户管理界面3) 系统管理员按用户名查询患者4) 找到该患者以后,对账户信息进行查看5) 查询完成后返回患者账户管理界面可选操作流程在按照用户名查询出需要的患者账户后,对该患者账户进行账户删 除,然后点击返回被泛化的用例无被包含的用例无被扩展的用例无检查化验收费标准管理环节需要系统管理员对检查化验处的项目进行唯一的有权限的管理,其中需要管理的业务内容有对检查化验标准的添加,并对这些添加的项目进行查询修改和删除,经分析得到检查化验收费标准管理阶段用例图如图2-6所示。图2-6检查化验收费标准管理Use Case 图Fig2-6 Use Case for check test charge standard management根据如上检查化验收费标准管理用例图得到检查化验收费标准管理用例说明如表2-5所示。表2-5检查化验收费标准管理用例说明Table 2-5 Check test charge standard management use case descriptions用例名称检查化验收费标准管理用例描述当一个新检查化验收费标准被添加或是已注册检查化验收费标准被查询并进行查看、修改和删除的时候是这个用例的开始。它处理一个新检查化验收费标准的基本信息的登记,以及对所有已注册的检查化验收费标准的基本信息的查看、修改和删除的问题,但是当系统管理员完成了一个新检查化验收费标准的创建或完成对一个已注册检查化验收费标准的查看、修改或删除的时候,它就结束了参与者系统管理员优先级1状态通过审查前置条件系统管理员以权限登陆进入系统后置条件添加一个用户;删除或更新一个已注册用户;基本操作流程1) 系统管理员收到一个新检查化验收费标准的登记请求2) 系统显示添加检查化验收费标准界面3) 系统管理员填写新检查化验收费标准的注册信息4) 填写完整后提交信息5) 正确提交后自动退出注册添加页面6) 新检查化验收费标准添加成功可选操作流程在添加注册途中放弃注册,退出注册页面在按照用检查化验收费标准名称查询出需要的检查化验收费标准后,对该检查化验收费标准进行基本信息查询,然后点击返回在按照检查化验收费标准名查询出需要的检查化验收费标准后,对该检查化验收费标准进行基本信息修改,提交后自动返回检查化验收费标准管理界面在按照检查化验收费标准名查询出需要的检查化验收费标准后,对该检查化验收费标准进行删除操作,检查化验收费标准列表进行更新,该检查化验收费标准从列表中消失,页面自动返回检查化验收费标准管理界面被泛化的用例无被包含的用例无被扩展的用例无药品信息管理环节需要系统管理员对药品信息进行严格的管理,其中需要管理的业务内容有对药品的添加,并对这些添加的项目进行查询修改和删除,经分析得到检查化验收费标准管理阶段用例图如图2-7所示。图2-7药品信息管理Use Case 图Fig2-7 Use Case for drug information management根据如上药品信息管理用例图得到药品信息管理用例说明如表2-6所示。表2-6药品信息管理用例说明Table 2-6 Drug information management use case descriptions用例名称药品信息管理用例描述当一个新药品被添加或是已注册药品被查询并进行查看、修改和删除的时候是这个用例的开始。它处理一个药品的基本信息的登记,以及对所有已注册的药品的基本信息的查看、修改和删除的问题,但是当系统管理员完成了一个新药品的创建或完成对一个已注册药品的查看、修改或删除的时候,它就结束了参与者系统管理员优先级1状态通过审查前置条件系统管理员以权限登陆进入系统后置条件添加一个用户;删除或更新一个已注册用户;基本操作流程1) 系统管理员收到一个新药品的登记请求2) 系统显示添加药品界面3) 系统管理员填写新药品的注册信息4) 填写完整后提交信息5) 正确提交后自动退出注册添加页面6) 新药品添加成功可选操作流程在添加注册途中放弃注册,退出注册页面在按照用药品名称查询出需要的药品后,对该药品进行基本信息查询,然后点击返回在按照药品名查询出需要的药品后,对该药品进行基本信息修改,提交后自动返回药品信息管理界面在按照药品名查询出需要的药品后,对该药品进行删除操作,药品列表进行更新,该药品从列表中消失,页面自动返回药品信息管理界面被泛化的用例无被包含的用例无被扩展的用例无普通门诊挂号环节需要挂号收费处对普通挂号的管理,也就是群众需要在门诊部的挂号处进行普通医生的挂号需求。经分析得到普通门诊挂号阶段用例图如图2-8所示。图2-8普通门诊挂号Use Case 图Fig2-8 Use Case for general outpatient service registration根据如上普通门诊挂号用例图得到普通门诊挂号用例说明如表2-7所示。表2-7普通门诊挂号用例说明Table 2-7 General outpatient service registration use case descriptions用例名称普通门诊挂号用例描述当一个新患者进行普通门诊挂号的时候是这个用例的开始。它处理一个新患者的账户建立和患者基本信息的登记挂号的问题,但是当 挂号管理员完成一个新患者的挂号登记的时候,它就结束了参与者挂号收费员优先级1状态通过审查前置条件挂号收费员以权限登陆进入系统后置条件添加一个新患者用户;挂号单增加一条患者挂号记录基本操作流程1) 挂号收费员收到一个新患者普通门诊挂号注册请求2) 系统显示普通门诊挂号界面3) 挂号收费员填写新患者的挂号注册信息4) 填写完整后提交信息5) 正确提交后自动退出挂号注册页面6) 新患者挂号单注册成功可选操作流程在挂号注册途中放弃注册,返回挂号注册前的页面被泛化的用例无被包含的用例无被扩展的用例无专家门诊挂号环节需要挂号收费处对专家挂号的管理,也就是群众需要在门诊部的挂号处进行专家医生的挂号需求,经分析得到专家门诊挂号阶段用例图如图2-9所示。图2-9专家门诊挂号Use Case 图Fig2-9 Use Case for expert outpatient service registration根据如上专家门诊挂号用例图得到专家门诊挂号用例说明如表2-8所示。表2-8专家门诊挂号用例说明Table 2-8 Expert outpatient service registration use case descriptions用例名称专家门诊挂号用例描述当一个新患者进行专家门诊挂号的时候是这个用例的开始。它处理一个新患者的账户建立和患者基本信息的登记挂号的问题,但是当挂号管理员完成一个新患者的挂号登记的时候,它就结束了参与者系统管理员优先级1状态通过审查前置条件挂号收费员以权限登陆进入系统后置条件添加一个新患者用户;挂号单增加一条患者挂号记录基本操作流程1) 挂号收费员收到一个新患者专家门诊挂号注册请求2) 系统显示专家门诊挂号界面3) 挂号收费员填写新患者的挂号注册信息4) 填写完整后提交信息5) 正确提交后自动退出挂号注册页面6) 新患者挂号单注册成功可选操作流程在挂号注册途中放弃注册,返回挂号注册前的页面被泛化的用例无被包含的用例无被扩展的用例无挂号单查询环节需要挂号处对挂号患者的挂号信息进行查询,并且需要把生成的挂号信息交给患者,以便患者自己查询自己的相关业务信息,经分析得到挂号单查询阶段用例图如图2-10所示。图2-10挂号单查询Use Case 图Fig2-10 Use Case for query of registration list根据如上挂号单查询用例图得到挂号单查询用例说明如表2-9所示。表2-9挂号单查询用例说明Table 2-9 Query of registration list use case descriptions挂号单查询挂号单查询用例描述当一个挂号单被查询的时候是这个用例的开始。它处理一个患者挂号信息的查询的问题,但是当挂号收费员查看完需要查看的患者的挂号信息的时候,它就结束了参与者挂号收费员优先级1状态通过审查前置条件挂号收费员以权限登陆进入系统后置条件无基本操作流程1) 挂号收费员收到一个挂号信息查询请求2) 系统显示挂号信息查询界面3) 挂号收费员按门诊编号查找该患者的挂号记录4) 找到该条记录以后,进行查看5) 查看完成,返回到挂号信息查询界面可选操作流程无被泛化的用例无被包含的用例无被扩展的用例无检查化验单收费管理环节需要挂号收费处对患者的检查化验项目进行收费的管理,经分析得到检查化验单收费管理阶段用例图如图2-11所示。图2-11检查化验单收费管理Use Case 图Fig2-11 Use Case for charge of check test list management根据如上检查化验单收费管理用例图得到检查化验单收费管理用例说明如表2-10所示。表2-10检查化验单收费管理用例说明Table 2-10 Charge of check test list management use case descriptions用例名称检查化验单收费管理用例描述当一个检查化验单收费单被查询的时候是这个用例的开始。它处理一个检查化验单收费单的查询和缴费确认的问题,但是当挂号收费员确认该检查化验收费完成的时候,它就结束了参与者挂号收费员优先级1状态通过审查前置条件挂号收费员以权限登陆进入系统后置条件一条检查化验收费项