[经管营销]高校医务信息管理系统.doc

软件需求分析报告高校医务信息管理系统 学生姓名 _ 学 号 专业班级 院 （系） 计算机与通信工程学院指导教师 完成时间 成 绩 前 言组员分工： 随着社会信息化进程的不断深入，计算机应用的普及和智能化，我们进入了信息发展的快速时代，各种传统方面的管理系统都受到了不同程度的冲击，高效方便的管理越来越受到大众的欢迎，各种各样的管理软件应运而生。传统的医务管理系统也受到信息化的影响而向着高效的管理迈进，高校作为为祖国未来培养栋梁的地方，信息化的发展更显得明显。为了改进传统医务管理的不方便之处，我们需要开发出具有很高应用型的软件，代替那些传统管理方面的零碎之处。高校医务管理信息系统的建立涉及到医院的方方面面，从计算机的硬件到软件，从管理的模式到人员的素质，从医院领导的关心和重视到各部门相互配合，都对医院管理系统的建立产生了很大的影响。随着科学技术水平的不断发展和现代化管理水平的不断提高，高校对校医院的医药管理也提出了更高的要求。目前高校医院的药库、药品管理、病案管理、计费管理等在那些繁琐、复杂、低效的日常工作中浪费了大量的时间，并且还时不时的带来这样那样的事故。例如：药库管理经常由于管理上的不当使部分药品失效报废，给医院带来经济损失，因此，医务管理的科技信息化是时代的必须，刻不容缓。为能够更好地了解药库及药房的药品情况、建立病人电子档案、规范门诊划价和费用收取核算等日常工作，对医务进行信息管理是非常必要的。目录一 项目前景文档11 业务需求11.1业务背景11.2业务机会11.3业务目标和成功条件11.4客户和市场需要21.5业务风险22解决方案的前景22.1前景陈述22.2主要系统特性：32.3假设和依赖条件：33项目范围和限制33.1发布的范围33.2限制和排除条件44业务环境44.1涉众档案44.2项目的优先级44.3运行环境5二 软件需求规格说明书61引言61.1概述61.2背景61.3定义71.4参考资料72任务概述72.1目标72.2运行环境（Operating Environment，OE）72.3假定（Assumption）和约束（Constraint）83需求规定83.1对功能的规定83.1.1用户需求（描述业务用例模型）组织机构和角色业务概览业务场景183.1.2系统需求（描述系统用例模型）概览系统需求规定数据分析523.2非功能性需求603.2.1性能需求（Performance）603.2.2安全性需求（Security）603.2.3软件质量属性613.3外部接口需求613.3.1用户界面（User Interfaces，UI）613.1.2硬件接口（Hardware Interfaces，HI）623.1.3通信接口（Communications Interfaces，CI）62高校医务信息管理系统一 项目前景文档1 业务需求1.1 业务背景校医院为了适应工作发展的需要，委托项目组为其开发一套新的高校医院医务信息管理系统。过去，高校医院在药库管理、药品管理、病案管理、计费管理等方面存在效率不高、业务流程随意、部分管理存在缺漏等问题。例如：药库管理经常由于管理上的不当使部分药品失效报废，给医院带来经济损失等。因此，设计一套符合用户需求的医务管理信息系统，将医务管理有关的信息纳入计算机系统统一管理，以便及时获取有关信息，已成为提高医疗效果和管理效率上急需解决的问题。本系统就是针对这方面的迫切需求而设计的。1.2 业务机会高校医院中的药库、药房管理、门诊划价历来是医院管理中的一些繁琐、复杂、费时、费力的日常工作。药库管理经常由于管理上的不当使部分药品失效报废，给医院带来一定的经济损失，因此，传统的手工统计操作已远远不能满足医务工作的实际需要。本系统能够提高工作效率，同时也能够随时了解药库及药房的药品情况，方便实施信息的管理，现在市场上存在的该类系统不是很多，而且没有一个能像本系统一样能够满足用户的需求，市场前景很好。本系统安装简便，移植性好。适用于多种操作系统。对硬件的要求不高，普通的个人电脑即可安装使用。与市场上已经存在的类似产品相比，本系统更加安全，可靠，即时。同时操作简便易学。系统运行速度较高，全面的业务逻辑处理能力，会给用户带来更多的便捷。安全快速全面的逻辑处理能力是本系统所独居的最大亮点。同时独立的错误处理能力也是其它系统所无法比拟的。1.3 业务目标和成功条件 高校医院主要是为全校教职工、学生、家属提供包括门诊、住院等医疗服务项目。本系统要求能够对高校医院进行药库管理、药品管理、病案管理、计费管理等。本系统要求安全，可靠（具有出错处理能力），准确。1.4 客户和市场需要随着科学技术水平的不断发展和现代化管理水平的不断提高，高校对校医院的医药管理也提出了更高的要求。高校医务管理信息系统的建立涉及到医院的方方面面，从计算机的硬件到软件，从管理的模式到人员的素质，从医院领导的关心和重视到各部门相互配合，都对医院管理系统的建立产生了很大的影响。同时，通过医务管理信息系统的建立，将医务管理计算机化、规范化，提高了工作效率、规范了业务管理流程、节省了大量的人力、物力、财力和时间，摆脱了过去手工方式时的数据统计、资料查询费时费力的落后局面，将在经济效益和社会效益方面创造良好的研究和利用价值。本系统为医务人员规范了日常工作，简化了业务管理流程，提高了效率，增加了效益。同时为患者建立个人信息档案，方便管理查询。本系统能够迅速占领市场，满足市场的需求。1.5 业务风险本系统推出时间较晚，价格昂贵，短期内很难占领市场的主要份额（可能性 0.5 影响 7）医院服务系统更新较慢，新系统很难进入应用领域（可能性 0.3 影响 4）本系统没有提供网上业务，影响系统的推广使用。（可能性 0.5 影响 3）2 解决方案的前景2.1 前景陈述产品名称：高校医务信息管理系统产品类别：软件产品目标客户：各大高校校医务室需求或机会的声明：本系统逻辑架构合理全面，满足了所有的用户需求新产品的主要竞争优势：安全快速全面的逻辑处理能力是本系统所独居的最大亮点。同时独立的错误处理能力也是其它系统所无法比拟的。2.2 主要系统特性： FE-1 日常的学生看病、挂号，住院、计费和医生计价、门诊。 FE-2 药品入库管理，对药品进行分类。FE-3 病房分配，入院病人的用药，收费。FE-4 注册门诊付费方式。FE-5 在院医生、医务人员档案建立和管理。FE-6 创建、浏览、修改和删除病人病历。FE-7 日常义务统计、整理、分析。FE_8通过高校内部网络可以访问系统，或者授权的医院工作人员可以通过外部Internet访问系统2.3 假设和依赖条件：如果本系统需要互联网的应用，开发人员可以完成网络应用的添加；为了能够保证系统的正常运行，学校医院已经建立好通畅的局域网环境。学校财务系统预留接口，可接受高校医院管理信息系统的数据作为财务系统数据输入的组成部分。 3 项目范围和限制3.1 发布的范围特性当前版本后续版本FE-1完全实现（管理日常事务）完全实现（依靠管理系统）FE-2完全实现完全实现FE-3完全实现完全实现FE-4完全实现完全实现FE-5完全实现完全实现FE-6完全实现完全实现FE-7完全实现（系统自动处理分析）完全实现FE-8不支持完全实现3.2 限制和排除条件本系统仅供医院内部使用（本系统需要的外部硬件配置昂贵），所以无法为外部人员提供服务。 本系统目前版本不支持网络服务，所以外界无法通过网络访问。4 业务环境4.1 涉众档案 用户其他涉众患者系统开发及其维护医务管理人员 4.2 项目的优先级因素约束自由度特性第一版本实现前九个特性至少实现前七个特性进度合约期内完成最晚延迟至12月14日质量必须满足95%的用户需求人员某某软件小组根据实际需要可添加成本少于计划投入资金最多超值原计划10%4.3 运行环境医院的操作将通过如下的Web浏览器来完成：IE8.0或IE6.0，360版本6和版本7。医院监护系统将运行在一个服务器中，该服务器运行当前医院批准的Red Hat Linux版本和Aachen HTTP Server。医院监护系统采用ORACLE数据库处理录入的数据。5高校医务信息管理系统二 软件需求规格说明书1引言1.1概述本文档详细介绍了高校医院管理信息系统的需求说明，为用户和领导描述出一个具体的产品模型，为软件设计、开发及测试人员提供下步工作的依据。本文档面向的读者主要是项目委托单位的管理人员。希望能使本软件开发工作更具体。本文档的目的在于给出“高校医务信息管理系统”(以下简称本系统)的功能说明。1） 向用户描述“高校医务信息管理系统”的功能；2） 为编制后续各阶段的文档提供基本依据；3） 提供给用户确认或本地化修改的基本文件；4） 作为日后软件确认测试和系统验收之参考依据；5） 作为日后系统维护工作基准文件。 本文档的内容涵盖了本系统的总体结构设计、软件运行环境设计、处理流程设计和软件功能设计等。 本文档的使用者包括本系统用户、需求分析人员、项目管理人员、软件设计人员、软件质量控制人员以及软件维护人员。1.2背景校医院为了适应工作发展的需要，委托项目组为其开发一套新的高校医务信息管理系统。高校医院主要为全校教职工、学生、家属提供医疗服务，包括门诊、住院、等服务项目。高校医务信息管理系统应将这些项目有关的信息纳入电脑系统统一管理，以便及时获取有关信息，提高医疗效果和管理效率。高校医务信息管理系统项目组成员与校医院有关人员经过一个月的工作，就校医院现有正单独使用的门诊、住院、药品管理等电脑应用系统进行了详细的分析，并考虑到校医院各部门联网后的应用需求。确定分以下子系统进行新系统的开发：住院部管理子系统；门诊部管理子系统；中西药房管理子系统；病案管理子系统；业务管理子系统；人事管理子系统；系统管理子系统。1.3定义术语所指对象或含义门诊科目校医院所设的门诊类别，由校医院设置并进行编码处方由校医院根据病情提供的治疗方法病种代码表示疾病的种类，由校医院统一规范人员类别教职工、学生、家属人员等年度指自然年度费用明细各项药品和诊疗项目费用1.4参考资料黄国兴 周勇 软件需求工程清华大学出版社 2008张海潘 软件工程北京清华大学出版版社 2003Wendy Boggs UML与Rational Rose 2002从入门到精通 邱仲潘 等 译 北京-电子工业出版社 2002 刁成嘉，UML系统建模与分析设计，北京：机械工业出版社，2007 2任务概述2.1目标 决策支持:根据实际要求及时提供所需报表及文件 提高效率:利用软件进行管理,避免人工管理的失误以及 延迟性,从而实现高效率的管理.2.2运行环境（Operating Environment，OE）(1)硬件方面：Pentium级处理芯片；1兆显存的兼容显卡；256色,1024*960的兼容显示器；标准兼容打印机。（2）软件方面: 操作系统WIN XP ；支持环境VISUAL BASIC 6.0；数据库 Microsoft SQL Server 2008。（3）网络类型：局域网（以太网）。（4） 存贮器容量：数据库服务器：100G以上；客户端：20G以上。2.3假定（Assumption）和约束（Constraint）为了能够保证系统的正常运行，学校医院已经建立好通畅的局域网环境。学校财务系统预留接口，可接受高校医院管理信息系统的数据作为财务系统数据输入的组成部分。3需求规定 3.1对功能的规定3.1.1用户需求组织机构和角色角色视图：角色说明：角色名称说明ba_患者学生、教职工、家属等具有缴纳资金、挂号预约等功能。ba_门诊管理人员医院工作人员，医生，具有诊病、开方子、收费等工作。ba_药房管理人员药房工作者，具有拿药，药品入库，药品划价等功能。ba_住院管理人员住院部管理人员，具有入院管理、出院管理、病房管理、住院计费等管理功能。（1）患者参与业务：说明：患者可以再申请账号，查看病案，挂号预约看病，如果药品有问题可以进行退还。交纳资金的多少可根据自己的意愿去决定，但若在看病住院资金不够时可当场由医务人员帮助交纳足够的资金。 （2）门诊管理员参与业务 说明：门诊管理员通过挂号预约为患者诊治，为患者建立档案，生成处方，确定患者是否需要住院，收取费用。若患者未注册自己的帐号，可由门诊管理员直接现场帮助患者注册。（3）住院管理人员参与业务： 说明：住院管理人员为病人分配房间、登记，病人住院后的安排值班人员，并调整住院费用标准，及处理出院手续、收费、查看病人记录以及查看值班记录等。（4）药房管理人员参与业务 说明：药房管理人员为药品划价，进行药品入库，药品药价变更调整，查询库存药品信息，为病人发药，接受退回药品。业务概览（1）普通就诊业务视图：普通就诊业务说明：患者在自己的帐号交纳资金后挂号预约自己想要的门诊医生，通过门诊医生的诊断，开出处方，并扣除相应的费用。普通就诊中的患者是不需要住院的，如需住院将会进行下一个业务住院业务。（2） 入院业务视图： （3）出院业务视图：说明：门诊人员诊治确定患者需要住院，确定住院信息；住院管理人员进行交接，安排患者住院及住院的管理、计费。说明：住院管理人员确定患者信息，办理出院手续，患者出院。（4）药品入库业务视图：说明：药品人员根据药房情况去厂家进药，药品入库登记，把药品放入药房；接受患者退换的药品，根据药品情况，可进行退还厂家处理。（5）药品出库业务视图：说明：门诊管理人员为病人诊治，生成药方，患者拿着药房去药方拿药；药房管理人员根据药方所列清单进行发药，同时药房管理人员还管理整个药品出库的信息。 （6）申请帐号业务视图： 说明：患者提出申请账号请求，填写申请资料，门诊管理人员查看患者信息，给患者颁发账号。（7）注销帐号业务视图：说明：患者通过查看病案信息，确定注销账号，并向门诊管理人员提出注销；门诊管理人员通过查看患者信息，确定患者注销申请，收回账号。 业务场景说明：此图描述的是业务流程，应使用预定义的business actor和business usecase作为泳道和活动。这样有助检查和发现business actor和business usecase。（1）第一次就诊业务场景：说明：此视图描述的是第一次就诊业务流程，患者首先要获得自己的帐号，然后才能进行挂号预约，在门诊部门就诊得到处方，最后在药房拿药。（2）普通就诊业务场景：说明：此视图描述的是普通就诊业务流程，因只是普通就诊，所以不需住院。 （3）入院业务场景：说明：此视图描述的是入院业务流程，患者挂号预约后在门诊部门的确诊下需要住院，然后去住院部门办理住院手续。（4）出院业务场景：说明：此视图描述的是出院业务流程，患者在得到出院许可后由住院管理人员办理出院手续，即可出院。（5）取药业务场景：说明：此视图描述的是取药业务流程，门诊人员给挂号预约的患者开出处方，由患者去药房拿药，药房管理人员处理发放药品的信息。（6）退药业务场景：说明：此视图描述的是退药业务流程，患者需要退还药品，可先提交退药申请，成功后即可去药房退药，然后由药房来处理退回来的药品信息。（7）申请帐号业务场景：说明：此视图描述的是申请帐号业务流程，由患者填写信息申请在医院的帐号，经门诊管理人员审核后颁发帐号。（8）注销帐号业务场景：说明：此视图描述的是注销帐号业务流程，患者想注销自己的帐号，提交申请，门诊部门进行审核，查看患者病案信息，最后同意并收回帐号。（9）药房管理业务场景：说明：此视图描述的是药房管理业务流程，主要由药房管理人员操作，从药品发出到患者退药再到收回药品，同时也有药品的购买和销售。3.1.2系统需求概览说明：该系统实现挂号预约、生成处方、入院管理、出院管理、发药处理、退药处理、申请帐号、注销帐号、颁发帐号、收回帐号用例。而就诊、药房管理、审核患者信息及病案信息分析等不能实现。系统需求规定(1) 挂号预约 业务说明用例名称bu_挂号预约实现名称bur_Registration appointment用例描述患者通过此用例向系统查询并提交挂号预约请求参与者患者前置条件1. 患者的帐号合法有效2. 患者帐号的资金足够后置条件1. 创建预约凭证2. 更新患者费用记录主事件流1用户用个人帐号登录系统，计算机显示我的医院信息档案2.用户选择查询预约挂号，计算机显示查询界面3.用户按门诊、日期查询，计算机显示查询结果4.用户可一个门诊或多个，并确认。计算机显示确认挂号预约清单。5.用户选择确认预约，计算机显示预约凭证及费用6用户选择提交预约凭证，计算机显示提交结果和凭证编号7.计算机执行后置条件。用例结束备选事件流4.a用户选择继续预约1.计算机执行2；4.b用户选择放弃1.计算机执行44.c用户找不到结果 1.计算机执行35.a用户余额不足1.计算机显示余额和所需金额2.用户选择续费，直接链接网上银行支付3.用户选择放弃，计算机执行16.a用户选择保存凭证单1.计算机保存并执行1；6.b用户选择放弃1.计算机执行1；业务规则至少预约一个涉及的业务实体Be_费用记录，Be_预约凭证，Be_患者帐号非功能性需求支持多种语言显示(2) 生成处方 业务说明用例名称bu_生成处方实现名称bur_Generate prescriptions用例描述门诊管理人员通过此用例向系统查询、填写患者信息并提交诊断处方参与者门诊管理人员前置条件1.患者的帐号合法有效2.患者的预约凭证有效2.患者帐号的资金足够后置条件1.创建处方单2.注销预约凭证3.更新患者费用记录主事件流1用户用个人帐号登录系统，计算机显示医务人员管理界面2.用户选择查询患者信息，计算机显示查询界面3.用户按患者帐号或姓名查询，计算机显示查询结果4.用户查询患者预约凭证，计算机显示查询结果5.用户选择注销预约凭证，计算机显示注销成功6.用户填写患者诊断信息并保存7.用户填写诊断的处方并提交，计算机显示相应费用8.用户确定提交，计算机显示提交结果和处方单9.计算机执行后置条件。用例结束备选事件流3.a用户查不到患者帐号1.用户选择颁发帐号，启动bu_颁发帐号用例2.用户选择结束，计算机执行24.a用户查不到患者的预约凭证1.计算机执行37.a患者余额不足1.计算机显示余额和所需金额2.用户选择续费，患者直接交纳3.用户选择放弃，计算机执行38.a用户选择保存处方单1.计算机保存并执行28.b用户选择放弃，1.计算机执行2业务规则至少有一个预约凭证，至少有一张处方单涉及的业务实体Be_费用记录，Be_处方单，Be_患者帐号,Be_预约凭证非功能性需求支持多种语言显示(3) 入院管理 业务说明用例名称bu_入院管理实现名称bur_Hospital management用例描述住院管理人员通过此用例向系统查询并处理患者住院手续参与者住院管理人员前置条件1.患者的帐号合法有效2患者被批准住院3.患者帐号的资金足够后置条件1.创建住院批准单、病房号2.更新患者费用记录主事件流1用户用个人帐号登录系统，计算机显示医务人员管理界面2.用户选择查询患者信息，计算机显示查询界面3.用户按患者帐号或姓名查询，计算机显示查询结果4.用户查询住院信息，计算机显示结果5.用户进行入院登记，计算机显示结果并显示空房信息6.用户选择分配病房，计算机显示病房号和应付费用7.用户提交病房单，计算机显示病房单号和住院批准单号8.计算机执行后置条件。用例结束备选事件流4.a用户查不到患者住院信息1.计算机执行35.a用户查不到空房信息 1.计算机执行36.a患者余额不足1.计算机显示余额和所需金额2.用户选择续费，患者直接交纳3.用户选择放弃，计算机执行27.a用户选择保存病房单1.计算机保存并执行27.b用户选择放弃，1.计算机执行2业务规则一次只有一张住院批准单，只有一张病房单涉及的业务实体Be_费用记录，Be_患者帐号，Be_住院批准单,Be_病房单非功能性需求支持多种语言显示(4) 出院管理 业务说明用例名称bu_出院管理实现名称bur_hospital management用例描述住院管理人员通过此用例向系统查询并处理患者出院手续参与者住院管理人员前置条件1.患者的帐号合法有效2.患者被批准出院后置条件1.创建出院批准单主事件流1用户用个人帐号登录系统，计算机显示医务人员管理界面2.用户选择查询患者信息，计算机显示查询界面3.用户按患者帐号或姓名查询，计算机显示查询结果4.用户查询住院信息，计算机显示结果5.用户进行出院登记，计算显示结果6用户选择提交出院批准单，计算机显示提交结果和批准单号7.计算机执行后置条件。用例结束备选事件流4.a用户查不到患者出院信息 1.计算机执行36.a用户选择保存出院批准单1.计算机保存并执行26.b用户选择放弃，1.计算机执行2业务规则一个患者帐号一次只有一张出院批准单涉及的业务实体Be_患者帐号，Be_出院批准单非功能性需求支持多种语言显示(5) 发药处理 业务说明用例名称bu_发药处理实现名称bur_Dispensing process用例描述药房管理人员通过此用例向系统查询并提交发药处理参与者药房管理人员前置条件1.患者的帐号合法有效2.患者有处方单且处方单有效后置条件1.创建药品开出单主事件流1用户用个人帐号登录系统，计算机显示医务人员管理界面2.用户选择查询患者信息，计算机显示查询界面3.用户按患者帐号或姓名查询，计算机显示查询结果4.用户查询取药信息，计算机显示结果5.用户选择取出药品，计算显示结果6用户选择提交药品开出单，计算机显示提交结果和药品开出单号7.计算机执行后置条件。用例结束备选事件流4.a用户查不到患者的处方单1.计算机执行34.b患者的处方单无效过期 2.计算机执行36.a用户选择保存药品开出单1.计算机保存并执行26.b用户选择放弃，1.计算机执行2业务规则一个患者帐号至少有一张处方单，但一次只有一张药品开出单涉及的业务实体Be_患者帐号，Be_处方单，Be_药品开出单非功能性需求支持多种语言显示(6) 退药处理 业务说明用例名称bu_退药处理实现名称bur_Drug withdrawal treatment用例描述药房管理人员通过此用例向系统查询并提交退药处理参与者药品管理人员前置条件1.患者的帐号合法有效2.患者已申请退还药品后置条件1. 创建退还药品单2. 更新患者费用记录主事件流1用户用个人帐号登录系统，计算机显示医务人员管理界面2.用户选择查询患者信息，计算机显示查询界面3.用户按患者帐号或姓名查询，计算机显示查询结果4.用户查询退药信息，计算机显示结果5.用户选择收回药品，计算显示结果6用户选择提交退还药品单，计算机显示提交结果和退还药品单号7.计算机执行后置条件。用例结束备选事件流4.a用户查不到患者的退还药品凭证1.计算机执行34.b患者的退还药品凭证无效过期 2.计算机执行36.a用户选择保存退还药品单1.计算机保存并执行26.b用户选择放弃，1.计算机执行2业务规则一个患者帐号至少有一个退还药品凭证，一次只有一张退还药品单涉及的业务实体Be_患者帐号，Be_退还药品凭证，Be_退还药品单非功能性需求支持多种语言显示(7) 申请帐号 业务说明用例名称bu_申请帐号实现名称bur_Apply for an account用例描述患者通过此用例向系统提交帐号申请参与者患者前置条件1.患者填写的信息正确合法后置条件1.创建帐号信息记录主事件流1用户登录系统申请帐号界面2.用户填写相应信息，计算机提示3.用户提交申请，计算机显示结果4.计算机执行后置条件。用例结束备选事件流3.a用户申请不成功 1.计算机执行23.a用户选择退出1.计算机执行1业务规则一个患者只有一个帐号，至少有一个帐号信息记录涉及的业务实体Be_患者帐号，Be_帐号信息记录非功能性需求支持多种语言显示(8) 注销帐号 业务说明用例名称bu_注销帐号实现名称bur_Cancellation account用例描述患者通过此用例向系统查询并提交注销帐号参与者患者前置条件1.患者帐号合法有效后置条件1. 更新帐号信息记录2. 注销病案信息主事件流1用户用个人帐号登录系统，计算机显示我的医院信息界面2.用户选择查询病案信息，计算机显示查询界面3.用户选择注销帐号，计算机显示结果4.用户提交申请，计算机显示结果。5.计算机执行后置条件。用例结束备选事件流3.a用户注销失败 1.计算机执行33.b用户选择放弃1.计算机执行34.a用户选择退出 1.计算机执行1业务规则一个患者帐号至少有一条病案信息，至少有一个帐号信息记录涉及的业务实体Be_患者帐号，Be_病案信息，Be_帐号信息记录非功能性需求支持多种语言显示(9) 颁发帐号 业务说明用例名称bu_颁发帐号实现名称bur_Account issued用例描述门诊管理人员通过此用例向系统查询并提交颁发帐号参与者门诊管理人员前置条件1.患者填写的信息合法正确后置条件1.更新帐号信息记录主事件流1用户用个人帐号登录系统，计算机显示医务人员管理界面2.用户查询帐号管理，计算机显示帐号管理界面3.用户选择查看帐号申请，计算机显示结果4.用户选择颁发帐号，计算机显示结果5.用户选择提交确定，计算机显示结果6.计算机执行后置条件。用例结束备选事件流4.a用户选择放弃 1.计算机执行35.a用户选择退出1.计算机保存并执行25.b用户选择放弃1.计算机执行2业务规则一个患者帐号至少有一个帐号信息记录涉及的业务实体Be_患者帐号，Be_帐号信息记录非功能性需求支持多种语言显示(10) 收回帐号 业务说明用例名称bu_收回帐号实现名称bur_Recover account用例描述门诊管理人员通过此用例向系统查询并提交收回帐号参与者门诊管理人员前置条件1.患者的帐号合法有效2.患者提交过注销帐号后置条件1.更新帐号信息记录2.注销病案信息主事件流1用户用个人帐号登录系统，计算机显示医务人员管理界面2.用户查询帐号管理，计算机显示帐号管理界面3.用户选择查看帐号申请，计算机显示结果4.用户选择收回帐号，计算机显示结果5.用户选择提交确定，计算机显示结果6.用户选择退还资金，计算显示结果7用户选择提交确定，计算机显示结果和注销病案信息8.计算机执行后置条件。用例结束备选事件流6.a用户退还不成功 1.计算机执行48.a用户选择退出1.计算机保存并执行2业务规则一个患者帐号至少有一条病案信息，至少有一个帐号信息记录涉及的业务实体Be_患者帐号，Be_病案信息，Be_帐号信息记录非功能性需求支持多种语言显示 业务场景分析（1） 挂号预约用例场景：说明：患者登录自己的帐号后选择挂号预约，系统处理信息，提示患者是成功，如不成功则预约失败：若成功，患者可选择是否继续，可以选择放弃预约，也可继续，然后确定。（2） 生成处方用例场景：说明：门诊人员在查询患者帐号信息后确定患者有过预约，注销预约凭证后为患者诊断并填写病案信息，开出处方，扣除相应费用。（3） 入院管路用例场景：说明：住院管理人员查询患者帐号信息，在确定患者需要住院后为患者进行登记住院并分配病房，扣除费用成功后即结束。（4） 出院管理用例场景：说明：住院管理人员查询患者帐号信息，在确定患者可以出院后，为患者办理出院手续。（5） 发药处理用例场景：说明：药房管理人员查询患者帐号信息，在确定患者的处方单有效后，为患者发放相应药品，并处理药房的药品信息。（6） 退药处理用例场景：说明：药房管理人员查询患者帐号信息，在确定患者申请退药有效后，收回患者退还的药品并退还给患者费用，然后处理药房的药品信息。（7） 申请帐号用例场景：说明：患者登录申请帐号界面，填写正确信息，提交申请，等待相应人员处理。（8） 注销帐号用例场景：说明：患者登录个人帐号后，可以申请注销自己的帐号，提交成功后等待相应人员处理。（9） 颁发帐号用例场景：说明：门诊管理人员在查看患者申请注册的信息后，选择颁发帐号（10） 收回帐号用例场景：说明：门诊管理人员查询患者帐号信息，在确定患者提交注销帐号后，提交注销，并退还患者帐号剩余资金。 业务实体分析（1） 挂号预约业务实体视图：说明：患者通过自己的帐号获得预约凭证，并更新费用记录。（2） 生成处方业务实体视图：说明：门诊管理人员通过患者帐号内的预约凭证，为患者诊治并开出处方单，更新费用记录。（3） 入院管理业务实体视图：说明：住院管理人员通过患者帐号的信息，开出住院批准单和病房号，更新费用记录。（4） 出院管理业务实体视图：说明：住院管理人员通过患者帐号信息为患者开出出院批准单（5） 发药处理业务实体视图：说明：药房管理人员通过患者帐号中的处方单，为患者取出药品并开出药品开出单（6） 退药处理业务实体视图：说明：药房管理人员通过患者帐号的退还药品凭证，为患者进行退药处理，并开出退还药品单（7） 申请帐号业务实体图：说明：患者通过登录系统申请自己的帐号，系统更新帐号信息记录（8） 注销帐号业务实体图：说明：患者通过自己的帐号，可以查看病案信息，并注销帐号，系统更新帐号信息记录（9） 颁发帐号业务实体图：说明：门诊管理人员通过患者的申请，为患者颁发帐号，系统更新帐号信息记录（10） 收回帐号业务实体图：说明：门诊管理人员通过患者帐号的注销申请，查看病案信息，退还余额，更新费用记录，并收回帐号，系统清除帐号信息记录数据分析(1) 概览说明：一个患者帐号获得预约凭证，门诊人员给患者帐号开出处方单，并给出费用记录。患者凭借处方单，药房管理人员为患者帐号开出药品开出单。患者通过自己的帐号获得退还药品凭证，药房管理人员为患者帐号开出退还药品单。患者需要住院，住院管理人员为患者开出住院批准单和病房号，并更新患者帐号的费用记录。患者需要出院，住院管理人员为患者帐号开出住院批准单。在患者就诊、住院过程中，相关人员为患者帐号更新患者的病案信息。在患者申请、注销帐号过程中，系统为患者帐号更新帐号信息记录。 患者帐号实体名称Be_患者帐号实体描述每个患者帐号都经由申请、颁发、登录、注销、收回几个状态，详细请参看图书状态图属性名称类型精度说明(属性的业务含义及业务规则)帐号字符18帐号为自己的身份证号帐号分类字符3帐号的分类密码字符6-12帐号的密码由数字和字母组成状态字符2帐号登录的状态 帐号信息记录实体名称Be_帐号信息记录实体描述帐号信息记录在帐号的申请、颁发、登录、注销中更新，在收回帐号后清除属性名称类型精度说明(属性的业务含义及业务规则)帐号字符18帐号为患者自己的身份证号帐号分类字符3帐号的分类日期日期帐号申请、颁发、登录、注销的时间状态字符2帐号登录的状态 处方单实体名称Be_处方单实体描述每个处方单需要注明患者帐号、姓名，以及主治医生的工号、姓名属性名称类型精度说明(属性的业务含义及业务规则)处方单号字符处方单流水号分类字符3处方单的分类患者帐号字符18患者的作者患者姓名字符20患者的姓名药品名称字符100所需药品的名称医嘱字符1000注明主治医生对患者的医嘱主治医生字符20主治医生的姓名工号字符10主治医生的工号日期日期处方单开出的日期 预约凭证实体名称Be_预约凭证实体描述患者需要看病挂号，先申请预约，有了预约凭证方可在指定时间地点看病属性名称类型精度说明(属性的业务含义及业务规则)编号字符预约凭证流水号分类字符3门诊的分类帐号字符18患者的帐号姓名字符20患者的姓名主治医生字符20主治医生的姓名工号字符10主治医生的工号地点字符100预约的地点日期日期预约的日期 费用记录实体名称Be_费用记录实体描述每本图书都经有上架，预定，借出，返回待查和下架几个状态，详细请参看图书状态图属性名称类型精度说明(属性的业务含义及业务规则)帐号字符18患者帐号姓名字符20患者姓名分类字符3支付的类型金额字符10此次所需交纳的费用收费人字符20收取费用的人员工号字符10收费人的工号欠费状态字符3当时欠费的状态 药品开出单实体名称Be_药品开出单实体描述药品开出单依赖于患者的处方单，并证明药品已发出属性名称类型精度说明(属性的业务含义及业务规则)编号字符药品开出单的流水号分类字符3门诊的分类帐号字符18患者的帐号姓名字符20患者姓名状态字符3药品发放状态，是否已发放发放人字符20药品发放人员工号字符10药品发放人员的工号日期日期药品发放的日期 退还药品凭证实体名称Be_退还药品凭证实体描述退还药品凭证依赖于药品开出单，证明患者提出退药并被同意属性名称类型精度说明(属性的业务含义及业务规则)编号字符退还药品凭证的流水号分类字符3门诊的分类帐号字符18患者的帐号姓名字符20患者的姓名药品名称字符100需要退还药品的名称退还理由字符1000退还某类药品的理由状态字符3此次退还是否有效 退还药品单实体名称Be_退还药品单实体描述退还药品单依赖于退还药品凭证，并证明已完成退药处理属性名称类型精度说明(属性的业务含义及业务规则)编号字符退还药品单的流水号分类字符3门诊的分类帐号字符18患者的帐号姓名字符20患者的姓名药品名称字符100退还药品的名称状态字符3是否已完成退还处理接收人字符20接收退还药品的人员工号字符10接收人的工号日期日期此次退还成功的日期 住院批准单实体名称Be_住院批准单实体描述住院批准单依赖于主治医生的诊断，确定患者住院信息属性名称类型精度说明(属性的业务含义及业务规则)编号字符住院批准单的流水号分类字符3门诊的分类帐号字符18患者帐号姓名字符20书籍的作者住院原因字符1000患者住院的原因住院医嘱字符1000患者住院所需的药品以