医院住院信息管理系统(一)

医院住院信息管理系统(一)摘要医院住院病区的管理包括病人出入院管理，住院病区对病人的医嘱录入、发药和计费，中心药房对药品的管理等工作，是医院管理重要一环。计算机技术在医院管理工作中应用越来广泛，住院病区管理使用计算技术实现信息传递网络化、计费电算化对提高管理水平，提高收费透明度有很现实的意义。本文主要论述医院住院信息管理系统的构建过程。该系统基本实现了病人资料、办理出入院手续、医嘱录入和中心药房发药的计算机网络管理。关键词医院信息管理 UML 三层技术 分布式运算第一章 前 言1.1 课题的项目背景该医院为二级甲等医院，现有门诊部和住院部，住院部设有住院病区8个，设有固定病床500张，病床使用率为80%；医院同时还设有手术室、住院部中心药房、药库以及检验室、CT室、财务科和出入院收费处等功能辅助科室。为了适应中国加入WTO后医疗服务市场激烈的竞争环境和上级主管部门对医院建设的需要，必须采用先进的信息技术加强对病人住院期间的费用管理，增加收费的准确性和透明度，加快处理病人入院和出院手续的速度，尽量地满足病人的需求，提高医院在医疗市场中的竞争力。同时需要完善药品管理减少药品损耗减少药品积压。在医院的各个部门中，出入院收费处、住院病区、中心药房构成对住院病人的服务链，住院病人经出入院收费处办理入院手续后入住某住院病区接受医院的服务同时产生医疗费用，最后经出入院收费处核价收费后办理出院手续出院。住院病区是各项医疗服务的主要执行者，他与出入院收费处构成住院信息系统的两个主要部分。而在为住院病人服务的过程中，住院部中心药房根据住院部医师开出的医嘱配药，而药库则作为医院药品的采购、保管和供应部门向中心药房供应药品间接地为住院病人提供服务。因此，没有中心药房和药库子系统的加入整个住院信息管理系统是片面的，不完善的。而其他的功能辅助科室如手术室、CT室等虽然也为病人提供服务，但为减低项目的复杂程度所以暂不将这些部门纳入本项目的范围。1.2 课题的现实意义医院实现信息化是大势所趋，很多有经济条件的医院使用了C/S模式的医院信息管理系统。传统的两层结构C/S系统对中心服务器和网络的依赖性很大，需要投入大笔资金和大量人力和物力，而且随着业务量的增加需要不断地升级软硬件设备。这样的投入对于一些资金比较紧张的中小型医院来说是很难负担的，本课题的目标就是利用三层分布式计算技术使用较低档的计算机硬件设备实现功能上，性能上和稳定性都比较完善的医院信息管理系统。第二章 综 述医院信息管理系统多采用C/S模式，两层结构的C/S应用程序对网络和服务器的依赖性较大，延展性差，程序的发布也较麻烦。分布式结构出现是为了解决两层C/S结构存在的用户数量增多就导致系统效率下降和延展性差等缺点。从现在软件发展的趋势来看，采用分布式结构已经是不可避免的趋势。目前流行的分布式系统结构分为由MicroSoft制定的COM/DCOM/COM+和由SUN、IBM等众多厂商倡导的CORBA结构。前者多用于Windows平台而后者主要用于UNIX平台，由于本系统运行于Windows平台所以采用COM/DCOM/COM+结构。第三章 系统需求分析3.1 系统目标总体来说，系统的目标是提高医院住院病区的管理水平，提高医院住院费用结算的自动化水平，提高工作效率，加大住院费用的透明度。具体的目标包括：加快办理病人入院、出院的速度，实现病人的医嘱和费用资料在住院的全过程自动化管理；准确记录病人的各项医嘱和费用记录，实现病人费用每日清单和住院费用清单；可以快速地提供准确的各项统计；准确记录各种药品的购入和消耗情况，实现病区药品管理电算化和网络化；3.2 当前系统受到实际条件的制约，在目前情况下出入院收费处、各住院病区、中心药房和药库均使用人手操作。各部门之间通过传统的医嘱、治疗单来传递信息，不但速度慢而且容易造成差错。下面分别介绍各部门的情况。3.2.1 出入院收费处行政上隶属于财务科，出入院收费处担负的工作包括：为病人办理入院手续、最终核对住院费用，收取各项住院费用，为病人办理出院手续，为财务科提供财务收入数据，既是为病人提供服务的第一个环节，也是最后一环节，住院费用计算的准确性直接影响医院的经济收入和医院的声誉。出入院收费处的特点有：（1）入院病人的住院号要正确：住院号为住院病人的唯一标识，关系到后续的各项病历、医疗收费和医疗统计的正确性。出入院处需要在办理入院时安排病人的住院号，新入院的为新号，重入院的安排上一次住院的住院号。（2）病人住院费用结算的要求多样化：病人的住院费用除了在出院时一次结清外，住院时间长的病人费用一般会在住院期间作中途结算，但这些中途结算的时间范围是根据病人的要求确定的，情况往往是出入院算好了某一段时间的住院费用后病人家属只要求结算其中某一段时间的费用，余下费用留作下次结算再交。因此，出入院收费处需要记录每一位病人的费用及收费情况。（3）出入院收费处是根据病区的医嘱计算病人费用的，他并不知道医嘱的实际执行情况，在一些特殊情况下往往造成多收漏收病人费用的情况。（4）按照上级的要求，医院需要为住院病人列出住院费用明细清单。（5）在未与社保网络联网的情况下还需要计算参加社保的病人的住院费用中社保支付部分和个人自负部分的金额。（6）病人办理入院或出院往往集中在某一天的某一时刻，在高峰期往往会造成办理出入院手续的人积压在出入院收费处，使办理出入院手续的时间延长。3.2.2 住院病区住院病区的主要责任是对病人各项治疗工作的执行。由住院医师开出医嘱后由护士核对后执行具体的治疗和护理，并作相应的治疗记录。对病人的治疗主要包括：口服药物、各项点滴和注射、检查、化验、手术和其他治疗。口服药物和注射治疗所需要的药物由中心药房提供，由住院病区负责执行；检查、化验、手术及部分的治疗项目由其他功能科室执行，住院病区负责开出治疗单。以上的各种治疗除了治疗项目本身的收费外还有另外的材料或附加收费，如药物注射除了药物本身的收费外还有注射费，部分血液化验项目除了化验项目的费用外还有抽血的费用，这些费用是跟随项目费用一起收取的。医嘱的主要内容包括：执行时间、治疗项目名称、规格、单位、剂量、次数、开出医嘱的医师姓名、核对和执行医嘱的护士签名。病人的医嘱分为长期医嘱和临时医嘱两种。长期医嘱是指那些需要每天都执行的医嘱，与临时医嘱的主要区别是长期医嘱除了医嘱的开始执行时间外还有医嘱的停止时间，若没有停止时间则医嘱一直执行。长期医嘱的主要内容是各种口服或注射药物治疗，床位，诊金，护理等治疗项目。其中口服药物和注射药物需要病区护士根据长期医嘱记录到当天服药本和治疗单中，然后把服药本和治疗单送到中心药房领取药物。长期医嘱的治疗一天执行一次，早上新开出的口服药物医嘱在中午的时候送服药本到中心药房在下午就可以领到药物执行，注射或立即执行的医嘱通过治疗单可以到中心药房领药，立即执行。如果是下午新开出的长期医嘱和下午新入院病人的长期医嘱可以通过治疗单到中心药房领药，保证医嘱在下午的时候可以开始执行。临时医嘱是指那些当天有效的医嘱，只执行一次，所以没有停止时间。临时医嘱的主要内容是药物口服或注射治疗、各种检验、化验、治疗及其他收费项目。口服和注射药物需要根据临时医嘱开出治疗单到中心药房领药，立即执行治疗。在现在市场经济的情况下住院病区除了对病人的治疗工作外还要监测病人的费用情况，若发现费用超过其所交的住院押金则应通知病人补交押金。按照上级的要求，住院病区需要为每位住院病人打印住院费用每日清单，让病人清楚了解费用情况。综合上面的情况可以知道，病区管理系统必须与中心药房系统联系以知道药品的发放情况和药品的规格、单位和是否缺药，也必须与出入院系统联系以了解病人的费用情况。3.2.3 住院部中心药房中心药房隶属于药剂科管理，负责住院病区的药品供应和指导病区正确使用药物的工作。中心药房根据病区提供的长期医嘱服药本和治疗单发药，长期医嘱服药本中记录是病区中各病人一天口服的药物，项目包括名称、规格、单位、剂量和次数，一天只发一次。治疗单中的药物为临时医嘱或需要立即执行的药物，发药的次数不限。中心药房配好药后由病区护士核对无误并在治疗单或服药本上签名后既可交由病区执行。若遇到缺药的情况中心药房应当向药库领药，如果药库也缺药则通知住院病区缺药并更改医嘱。3.2.4 西药库西药库主要负责全院药物的购入、保管、发放工作。西药库按照药品公司的送货单核对药品的名称、规格、价格和数量填写药品进仓单。医院各用药部门根据需要到药库领药，药库则根据发药情况开出药品出仓单。西药库的的工作还涉及医院药品管理的其他方面，包括：药品的价格管理，根据物价部门的指示和有关规定调整药品价格，并统计药品调价所带来的差价。药品使用管理，对于新药要通知门诊和中心药房使用，淘汰的药品也需要通知停止使用，接近使用期限的药品要安排尽快使用，因过期、变质的药品要及时报废。季度盘点和月度结算报表。月度结算报表主要统计药库、中心药房、西药房中各种药品的库存、进销差价率和实现差价。季度盘点报表主要是把药品的实际库存量和帐面上的库存量作比较。西药库工作的难点在于用药部门经常需要知道某种药品在中药库是否有库存，而药库也需要及时了解用药部门的药品使用情况（存量、用量等）。3.2.5 问题总结由上面对住院部各部门的描述可知，现有的手工操作流程存在着下列缺陷：作为核算病人住院费用的出入院收费处仅能从医生开出的医嘱计算病人住院费用，但实际的执行者是病区的护士和中心药房，出入院收费处的收费员并不了解医嘱的实际执行情况。现实操作中经常存在着医嘱漏开或医嘱开出但因为某种原因但并没有执行的情况，这样就造成了计费的不准确，使病人及家属怀疑医院医疗收费的准确性和合理性。病人医嘱在病人住院期间放在住院病区，当办理病人出院或阶段结算时才交由出入院收费处核价，这个过程需要一定的时间，当病人住院时间长或医嘱比较多时尤甚。这样就造成了在办理出院的高峰期出入院收费处积压了许多病人家属等待办理出院的“壮观”场面。医嘱病历没有实现电子化，无法与其他医院、其他系统实现病人资料的交换与共享。作为住院部所有病区所使用的药品的供应部门，中心药房是被动地按照病区护士转抄医嘱的服药本和治疗单配药。病区的服药本和治疗单是否与医嘱相符，药品发到病区后的使用情况中心药房也不知道，也没有有效的机制保证没有执行治疗的药物及时退还给中心药房，造成病区药品管理的混乱局面。负责供应药品的西药库不知道中心药房的实际库存和药品使用情况，对药品有效期的管理实际也不能做到，所以无法对医院的药品进行科学有效的管理。由于人手操作的缘故，所有统计报表都由人手工计算和制作，不但效率低，容易差错，更无法作大型复杂的统计，先进的管理模式无法在医院应用，直接影响医院管理水平的提高。出入院收费处、住院病区、中心药房、西药库因为信息彼此间不能有效沟通而形成了“信息孤岛”，是造成问题主要原因，需要在四者间建立快速的有效的信息交换通道，使数据可以自动地快速地处理和传递，减少人手操作。3.3. 建议的系统图3-1 系统活动图3.3.1 概述通过对医院住院部原有系统的了解，我们可以知道医院住院部的业务主要由财务、病区、药剂三个部门组成，传统的手工信息交换和处理手段已经不能很好地满足业务增长的需要。因此系统改进的重点在于引入计算机网络技术和数据库技术，把各部门紧密地连接起来用计算机取代人手计算，通过网络进行信息传递取代手写传递，从而达到提高管理和服务水平，增强效率，减少差错的目的。通过病人住院系统的活动图可以知道，住院信息管理系统由出入院收费系统、住院病区管理系统、中心药房发药系统、药库管理系统组成。系统运行的信息主要由病人资料，医嘱信息，治疗记录，费用信息，药品资料，药品使用信息，病人交费记录等信息组成，主要活动包括：办理入院手续、录入医嘱、执行治疗、计算费用、收取费用、办理出院、药品购入、药品发出等。这些信息保存在各个子系统中，分别由各系统处理，当需要信息交换时通过网络实现信息资料的共享和交换，从而实现分布式计算。3.3.2 出入院收费处子系统3.3.2.1系统功能需求编号功能分类R1.1记录每一位曾经住院的病人的资料明显的R1.2录入新入院病人的资料明显的R1.3可以查询曾经住院的病人的资料明显的R1.5根据病人的入院时间和住院病区为病人办理入院明显的R1.6记录收取病人的每一笔住院押金，随时供查阅和收费结算使用明显的R1.7区别已结算和未结算的住院押金隐藏的R1.8显示病人现在所处的状态：未入院、等待入院、住院、阶段结算、办理出院、出院明显的R1.9记录病人每次住院的资料隐藏的R1.10可以修改病人的基本资料，但住院号和住院次数不能修改隐藏的R1.11保证每位病人有唯一的住院号隐藏的R1.12通过核对医嘱核对病人费用明显的R1.13 通过补充医嘱补充费用明显的R1.14可以冲减病人费用记录明显的R1.15不能删除或修改病区原有医嘱隐藏的R1.16标记核对完成的医嘱和费用记录作为收取病人费用的依据明显的R1.17显示病人的费用情况明显的R1.18费用的价格按产生费用当天的价格，新生成的费用按现行价格隐藏的R1.19用新补充的医嘱产生费用后如果为药品应扣减中心药房的库存明显的R1.20核对完成后为病人打印交款通知单明显的R1.21核对完成后应在系统中改变病人状态以便下一步操作隐藏的R1.22在收款结算时可以灵活选择结算的住院押金明显的R1.23根据实际的需要选择结算的费用时间阶段明显的R1.24计算结算范围内的住院费用明显的R1.26病人交款后打印收据明显的R1.27记录每次收款的资料明显的R1.28记录每次收款中现金和IC卡的金额明显的R1.29保存后的收款收据可以查阅、作废和重新打印明显的R1.30区别费用记录中已收款和未收款的部分明显的R1.31可以按收款收据或时间范围打印费用清单明显的R1.32对结算好的等待出院病人可以办理出院明显的R1.36每位收款员打印缴款日报表和阶段报表明显的R1.37每位收款员有独立的帐号和密码，收款员必须输入正确的帐号和密码才能操作出入院收费系统明显的R1.38可以查询各医疗项目的名称、规格、单位、价格等资料明显的3.3.2.2 非功能性需求用户界面和人为因素 系统的操作界面以对话框窗口为主，主要以鼠标和键盘进行操作和数据的录入。要求操作人员具有一定的windows系统的操作能力，能够阅读医嘱和基本的财务知识。文件 系统最终以EXE可执行文件发布，另外还有操作说明书和与开发活动相关的文档硬件 服务器要求为1G CPU，256M以上内存，40G以上的硬盘空间，要求兼容windows2000 操作系统和SQL SERVER2000数据库系统。客户端要求600MHz CPU，128M内存，20G硬盘空间，要求兼容windows98。网络连接设备要求与100M/10M以太网络技术兼容。性能特征 要求可以同时为不少于5台客户端连接，住院病区的客户端连接不少于20台。计算一位病人的费用不多于1分钟，一般应在10秒以内。系统要尽力保证在繁忙的时间系统的响应速度。安全 系统通过操作员帐号、密码和操作权限来保证系统不会被其他用户操作。3.3.2.3 伪需求数据服务器使用windows2000 操作系统和SQL SERVER2000数据库系统，客户端使用windows98操作系统，开发工具使用delphi5。3.3.2.4 系统模型3.3.2.4.1 用例模型 用例图3-2用例说明用例：病人办理入院参与者：住院病人，收费员，住院管理子系统目的：为需要住院的病人办理入院手续，并记录下相关的住院信息概述：需要住院的病人到出入院收费处要求办理入院手续，收费员为病人安排住院号和住院病区，病区管理系统接收住院病人。类型：主要的和基本的交叉引用：R1.1，R1.2，R1.3，R1.4，R1.5，R1.8，R1.9，R1.10，R1.11，录入病人资料用例典型的事件发生过程：参与者的动作系统响应1. 入院病人到出入院收费处要求办理入院2. 收费员根据姓名或住院号查找病人的资料3. 返回病人的资料（住院号，姓名，地址等）4收费员根据系统返回的信息选择的操作： a. 若没有此病人的信息应输入病人的资料 b. 若有此病人的信息应核对病人资料5. 收费员安排住院病区和输入住院时间6. 修改病人资料的相关属性7. 保存入院记录8. 住院病区管理系统接收病人9. 设定病人为住院状态可供选择的过程：第4点若系统没有入院病人的信息则应录入病人的资料若入院病人参加了社会医疗保险，则在办理入院后设定病人的社保相关属性用例：收取住院押金参与者：住院病人（发起者），收费员目的：记录住院病人交纳的住院押金概述：住院病人在办理入院后到出入院收费处交纳住院押金，收费员记录下病人所交纳的住院押金的情况。类型：主要的和基本的交叉引用：R1.6，R1.7，R1.8典型的事件发生过程参与者的动作系统响应1. 住院病人到出入院收费处交纳住院押金2. 收费员按住院号查找病人资料3. 返回病人的资料4. 收费员手写一份押金收据5. 收费员根据收据内容输入押金的信息并确认6. 保存押金信息可供选择的过程：收费员还可以对输入错误的押金资料作作废处理。用例：计算住院费用参与者：住院病区管理系统（发起者），收费员目的：计算病人的住院费用概述：住院病区管理系统传送病人的医嘱和费用记录要求出入院收费处计算病人的住院费用，收费员核对病人的医嘱后指示计算费用，完成后保存病人的医嘱和住院费用。类型：主要的和基本的交叉引用：R1.12，R1.13，R1.14，R1.15，R1.16，R1.17，R1.18，R1.19，R1.20，R1.21，R1.38，核对医嘱用例，冲正费用例典型的事件发生过程参与者的动作系统响应1. 住院病区管理系统传送病人的医嘱和费用记录。2. 系统更新病人的状态。3. 收费员核对病人医嘱，对多收的费用应当冲正，少收的费用应当补开医嘱4. 作相应的补发药或退药处理5. 收费员指示计算费用6. 计算和显示费用分类和合计7. 收费员完成计算操作8. 更新病人的状态，保存医嘱和费用记录，并对己计算好费用记录做标记9. 收费员打印交款通知单给病人用例：费用结算参与者：住院病人（发起者），收费员目的：结算病人的住院费用概述：住院病人到出入院收费处要求结算住院费用，收费员根据计算好的费用记录计算好住院费用金额，收款并打印收款收据类型：主要的和基本的交叉引用：R1.22，R1.23，R1.24，R1.25，R1.26，R1.27，R1.28，R1.29，R1.30，R1.31，R1.33，R1.34，R1.35典型的事件发生过程参与者的动作系统响应1. 住院病人到出入院收费处要求结算住院费用2. 收费员根据病人的住院号查询病人的住院费用3. 显示并计算病人的住院费用4. 收费员设定需要结算的住院押金5显示未结算的住院押金6. 收费员根据实际情况进行的操作：a.补充病人费用b.冲正病人费用c.按病人要求设定结算的费用时间范围7. 重新计算和显示病人的费用和病人应补交金额8. 病人交款，选择有：a. 现金交款b. 通过IC卡交款9. 显示费用结余情况10. 收费员完成结算并打印收款收据11. 保存结算信息，标识本次结算的费用记录，保存交款（现金或IC卡）和发票资料12. 收费员可以根据病人要求打印住院费用清单用例：办理出院手续参与者：住院病区管理系统（发起者），收费员，住院病人目的：为住院病人办理出院手续概述：住院病区管理系统定义病人办理出院，收费员在病人住院费用已全部结清的情况下为住院病人办理出院手续类型：主要的和基本的交叉引用：典型的事件发生过程参与者的动作系统响应1. 住院病区管理系统定义病人办理出院并传送未结算的医嘱和费用记录2. 更新病人的状态2. 收费员计算病人费用3. 保存医嘱，显示并计算病人的住院费用4. 收费员结算病人费用5 保存结算信息6. 办理病人出院7. 保存病人的出院时间和出院病区，更新病人状态用例：录入病人资料参与者：收费员（发起者）目的：新增或修改病人的基本资料概述：收费员输入新的病人资料或修改已有病人的资料类型：主要的和基本的交叉引用：典型的事件发生过程参与者的动作系统响应1. 收费员输入病人的住院号2. 系统返回病人信息3. 收费员可选择：a.新增加一位病人b.修改病人资料4. 收费员保存病人资料5. 保存病人资料，返回结果有：a. 住院号没重复，则保存b. 住院号有重复则要求重新输入另外的住院号用例：核对、录入医嘱参与者：收费员（发起者）目的：核对住院病人的医嘱，发现漏掉的医嘱应当补充概述：收费员把计算机记录的医嘱和实际医嘱对照，发现少录入的应当补充录入类型：主要的和基本的交叉引用：R2.3，R2.4 典型的事件发生过程参与者的动作系统响应1. 收费员启动核对录入操作。输入病人的住院号。2. 返回病人已有的医嘱，并显示已产生的费用情况。3. 收费员发现需要增加一条新医嘱4. 自动写入默认字段内容5. 收费员输入执行时间和治疗项目代码6. 返回项目信息，包括：名称、规格、单位、价格等7. 根据返回情况系统可选择：a. 若药品库存为缺药则要求重新输入b. 若没有此治疗项目则要求重新输入代码8. 收费员输入剂量、次数、用法9. 若用法有附加治疗项目则自动增加附加项目10. 若是长期医嘱则还应输入停止时间11. 收费员指示保存医嘱12. 保存医嘱用例：费用冲正参与者：收费员目的：冲正因医嘱错误录入等原因造成的多收病人的费用概述：收费员找出需要冲正费用的医嘱，然后输入冲正的数量和价格，产生冲正记录类型：主要的和基本的交叉引用：典型的事件发生过程参与者的动作系统响应1. 收费员按病人的住院号、住院次数查找病人未结算的医嘱2. 返回病人的医嘱3. 收费员选择要冲正的医嘱4. 计算并显示医嘱所产生的费用情况5. 收费员输入冲正的数量和价格5 重新计算并显示冲正后的费用情况6. 收费员确认冲正操作7. 保存冲正记录并作退药处理3.3.2.4.2 出入院收费子系统类图：图3-3 出入院系统类图3.3.2.4.3 动态模型图3-4核对费用顺序图图3-5结算费用顺序图图3-6收取住院押金顺序图3.3.3 病区管理子系统3.3.3.1 功能性需求编号功能分类R2.1从出入院子系统接收等待入院的病人。明显的R2.2保存本病区当前收住病人的医嘱和费用资料明显的R2.3住院病区的操作员录入病人的长期医嘱和临时医嘱，并根据这些医嘱的用法生成附加医嘱项目明显的R2.4录入的医嘱必须经过确认之后才能产生执行记录明显的R2.5产生发药记录由住院病区的操作员驱动，长期医嘱每天发药一次，临时医嘱次数不限明显的R2.6药物治疗项目的执行记录发往中心药房子系统，其他项目在系统内保存隐藏的R2.7中心药房标示为缺药的药品不能发药和录入医嘱明显的R2.8保存中心药房发回的发药记录作为治疗记录隐藏的R2.9根据治疗记录产生住院费用明显的R2.10位每位在院病人打印每日费用清单明显的R2.11显示病人的费用情况、交费和住院押金情况明显的R2.12定义病人为出院或阶段结算明显的R2.13为出入院处提供病人的医嘱及费用记录明显的R2.14为病人办理转科手续明显的R2.15区别病人每次结算的医嘱和费用隐藏的R2.16清理出院病人的医嘱和费用记录，保持系统运行速度明显的3.3.3.2 非功能性需求用户界面和人为因素 系统的操作界面以对话框窗口为主，主要以鼠标和键盘进行操作和数据的录入。要求操作人员具有一定的windows系统的操作能力，能够阅读医嘱和基本的财务知识。文件 系统最终以EXE可执行文件发布，另外还有操作说明书和与开发活动相关的文档硬件 服务器要求为1G CPU，256M以上内存，40G以上的硬盘空间，要求兼容windows2000 操作系统和SQL SERVER2000数据库系统。客户端要求600MHz CPU，128M内存，20G硬盘空间，要求兼容windows98。网络连接设备要求与100M/10M以太网络技术兼容。性能特征 要求在最系统最繁忙的时间操作基本保持流畅，住院病区的客户端连接不少于20台。打开一位病人的医嘱不多于2秒，整个病区做发药处理不多于1分钟。安全 系统通过操作员帐号、密码和操作权限来保证系统不会被其他用户操作。3.3.3.3 伪需求数据服务器使用windows2000 操作系统和SQL SERVER2000数据库系统，客户端使用windows98操作系统，开发工具使用delphi5。3.3.3.4 系统模型3.3.3.4.1 用例模型图3-7病区管理用例图用例说明：用例：接收病人入院参与者：住院病区护士（发起者），出入院收费系统目的：接收已在出入院收费系统办理好入院手续的病人概述：出入院收费系统办理病人入院后由住院病区护士在病区管理系统中接收病人的信息，住院押金信息和费用信息，并通知住院收费系统病人已经入院。类型：主要的和基本的交叉引用：R2.1，R2.2 典型的事件发生过程参与者的动作系统响应1. 住院病区的护士查询本病区等待入院的病人和空病床2. 返回本病区空病床、等待入院的病人和本科医生的列表3. 可选操作，若空病床不够可以增加病床4. 护士选择要接收的病人、床位和主管医生5. 护士确认操作6. 从出入院收费系统接收病人的信息，住院押金信息和费用信息，更改出入院收费系统中病人的状态为住院用例：医嘱录入参与者：住院病区护士（发起者）目的：把住院医生开出的医嘱录入到计算机中保存，为产生费用记录提供依据概述：住院病区护士把医生开出的医嘱录入到计算机中，核对和确认后作为产生发药记录的依据。类型：主要的和基本的交叉引用：R2.3，R2.4 典型的事件发生过程参与者的动作系统响应1. 住院病区护士启动录入操作。输入病人的住院号。2. 返回病人已有的医嘱，并显示已产生的费用情况。3. 护士增加一条新医嘱4. 自动写入默认字段内容5. 护士输入执行时间和治疗项目代码6. 返回项目信息，包括：名称、规格、单位、价格等7. 根据返回情况系统可选择：a. 若药品库存为缺药则要求重新输入b. 若没有此治疗项目则要求重新输入代码8. 护士输入剂量、次数、用法9. 若用法有附加治疗项目则自动增加附加项目10. 若是长期医嘱则还应输入停止时间11. 护士指示保存医嘱12. 保存医嘱用例：发药参与者：住院病区护士（发起者），中心药房发药系统目的：把经过病区护士核对确认后的医嘱产生可用于计算住院费用的治疗记录概述：住院病区护士指示病区管理系统扫描保存的医嘱产生要求中心药房发药的信息。类型：主要的和基本的交叉引用：R2.3，R2.4 典型的事件发生过程参与者的动作系统响应1. 住院病区护士指示发药2. 返回未发药的医嘱3. 扫描医嘱，根据医嘱的类型和内容产生请求发药信息。系统根据治疗项目的情况选择的操作有：a. 若项目不缺药和需要执行则产生发药信息b. 若缺药则提示停止医嘱c. 若不需要执行则不产生发药信息4. 向中心药房管理系统传送请求发药信息5. 为已产生发药信息的医嘱作发药标记，防止一天内多次产生发药信息。6. 中心药房系统发送消息发药成功7. 接收发药信息用例：产生费用参与者：住院病区护士（发起者）目的：利用发药信息和其他治疗记录产生费用记录概述：住院病区护士指示或病区管理系统自动扫描的发药记录产生费用记录类型：主要的和基本的交叉引用：R2.3，R2.4 典型的事件发生过程参与者的动作系统响应1. 住院病区护士或系统自动指示产生费用2. 返回当天的发药记录3. 扫描记录，产生费用记录4. 扫描发药记录，产生附加费用记录5. 保存费用记录用例：办理出院参与者：住院病区护士（发起者），出入院收费系统目的：为需要出院的病人办理出院概述：住院病区护士定义病人出院时间并向出入院传送医嘱和费用记录，等待出入院为病人办理出院手续，出入院收费处办理好出院手续后由病区护士清空床位。类型：主要的和基本的交叉引用：R2.12，R2.13，R2.15，R2.16 典型的事件发生过程参与者的动作系统响应1. 住院病区护士输入出院病人的住院号和出院时间2. 停止病人的全部长期医嘱3. 向出入院收费处传送医嘱和费用记录4. 出入院收费处为病人计算住院费用和结算5. 出入院收费处办理病人出院5. 保存费用记录6. 住院病区护士清空病床7. 修改病人和病床的信息。3.3.3.4.2 病区管理子系统类图：图3-8病区管理子系统类图3.3.3.4.3 动态模型：图3-9病区发药顺序图3.3.4 中心药房子系统3.3.4.1 功能性需求编号功能分类R3.1记录每种药品的库存量明显的R3.2根据各病区传送过来的治疗记录产生发药记录，并扣减库存明显的R3.3对每种药品设定保证库存量，对库存不足的药品应提示需要领药并生成领药申请明显的R3.4可以把发药记录按科室打印出来，方便病区核对明显的R3.5保存发药记录备查明显的R3.6提示病区缺药明显的R3.7自动接收并保存西药库的发药信息明显的R3.8手工输入西药库的出仓单明显的R3.9根据输入药品的盘点数量生成盘点报表明显的R3.10根据盘点数量校正药品库存量明显的R3.11药库的发药信息经确认后增加药品库存明显的3.3.4.2 非功能性需求用户界面和人为因素 系统的操作界面以对话框窗口为主，主要以鼠标和键盘进行操作和数据的录入。要求操作人员具有一定的windows系统的操作能力，能够阅读医嘱和基本的财务知识。文件 系统最终以EXE可执行文件发布，另外还有操作说明书和与开发活动相关的文档硬件 服务器要求为1G CPU，256M以上内存，40G以上的硬盘空间，要求兼容windows2000 操作系统和SQL SERVER2000数据库系统。客户端要求600MHz CPU，128M内存，20G硬盘空间，要求兼容windows98。网络连接设备要求与100M/10M以太网络技术兼容。每台工作站配备窄行打印机一台。性能特征 要求在最系统最繁忙的时间操作基本保持流畅，中心药房的客户端连接不少于4台。当接收到病区传送的发药信息时能够立即提示配药人员。安全 系统通过操作员帐号、密码和操作权限来保证系统不会被其他用户操作。3.3.4.3 伪需求数据服务器使用windows2000 操作系统和SQL SERVER2000数据库系统，客户端使用windows98操作系统，开发工具使用delphi5。3.3.4.4 系统模型3.3.4.4.1 用例模型图3-10 中心药房系统用例图用例说明：用例：领药参与者：中心药房主管（发起者），药库管理系统目的：到药库领取药品，增加中心药房的药品库存概述：中心药房主管提出领药请求，药库管理系统根据领药请求发药并开出药品出仓单，中心药房主管核对出仓单和药品后确认领药，中心药房增加药品的库存。类型：主要的和基本的交叉引用：R3.1，R3.3，R3.7，R3.8，R3.6典型的事件发生过程参与者的动作系统响应1. 中心药房主管查询系统记录的领药需求2. 返回领药需求记录3. 中心药房主管修改系统记录的领药需求4. 保存领药需求记录5. 中心药房主管以打印或发送数据的形式向药库管理系统发送领药请求。6. 药库管理系统接收发药请求7. 药库管理系统发药，传送发药信息或由中心药房主管输入出仓单。8. 接收并保存发药信息9. 中心药房主管确认药库发药信息10. 增加药品库存量11. 若需要提示病区缺药则向病区管理系统发送缺药信息12. 向病区系统发送缺药信息。用例：发药参与者：病区管理系统（发起者），配药员目的：根据病区管理系统发送的发药请求配药，相应减少药品库存量并把发药信息发送回病区管理系统。概述：病区管理系统向系统发送发药请求，配药员查看这些发药请求配药，确认后系统扣减药品库存，并向病区管理系统回传发药信息，系统打印配药单以方便核对。类型： 主要的和基本的交叉引用：R3.2，R3.3，R3.4，R3.5典型的事件发生过程参与者的动作系统响应1. 病区管理系统传送请求发药信息2. 保存请求发药信息3. 配药员查阅请求发药信息4. 保存请求发药信息5. 配药员确认发药6. 扣减药品库存并生成发药记录若缺药则系统查询药库管理系统药库是否有库存，有则产生领药信息，没有则提示病区管理系统缺药。7. 系统根据药品库存情况可选择a. 库存大于库存下限则不作处理b. 库存小于库存下限则生成领药信息8. 配药员打印发药单10. 病区管理系统接收发药信息3.3.4.4.2 中心药房发药子系统类图图3-11 中心药房发药子系统类图3.3.4.4.3 动态模型：图3-12药房发药顺序图3.3.5 西药库子系统3.3.5.1 功能性需求编号功能分类R4.1保存每笔药品进仓记录，并增加库存明显的R4.2保存每笔药品出仓记录，并减少库存明显的R4.3产生和保存进仓单明显的R4.4产生和保存出仓单明显的R4.5根据药品供应商的发票选择结算的进仓记录明显的R4.6保存每次结算的数据明显的R4.7药品进仓时登记药品的批号和有效期，并增加这药品的库存明显的R4.8药品出仓时由仓管员选择发出的批号，并减少药品的库存明显的R4.11根据输入药品的盘点数量生成盘点报表明显的R4.12根据盘点数量校正药品库存量明显的R4.13对每种药品设定保证库存量，对库存不足的药品应提示需要领药并生成采购计划明显的R4.14接收用药部门的领药申请明显的R4.15根据领药申请自动生成出库单，并扣减库存明显的R4.16对药品进行价格调整，并通知用药部门跟随调整价格明显的R4.17统计药品价格调整带来的差额明显的R4.18录入、保存、修改药品信息明显的3.3.5.2 非功能性需求用户界面和人为因素 系统的操作界面以对话框窗口为主，主要以鼠标和键盘进行操作和数据的录入。要求操作人员具有一定的windows系统的操作能力，能够熟悉药库的日常管理运作。文件 系统最终以EXE可执行文件发布，另外还有操作说明书和与开发活动相关的文档硬件 服务器要求为1G CPU，256M以上内存，40G以上的硬盘空间，要求兼容windows2000 操作系统和SQL SERVER2000数据库系统。客户端要求600MHz CPU，128M内存，20G硬盘空间，要求兼容windows98。网络连接设备要求与100M/10M以太网络技术兼容。每台工作站配备窄行打印机一台。性能特征 要求在最系统最繁忙的时间操作基本保持流畅，中心药房的客户端连接不少于4台。当接收到病区传送的发药信息时能够立即提示配药人员。安全 系统通过操作员帐号、密码和操作权限来保证系统不会被其他用户操作。3.3.5.3 伪需求数据服务器使用windows2000 操作系统和SQL SERVER2000数据库系统，客户端使用windows98操作系统，开发工具使用delphi5。3.3.5.4 系统模型3.3.5.4.1 用例模型图3-13药库管理系统用例图用例说明：用例：药品进仓参与者：药品供应商（发起者），仓管员目的：登记药品入库概述：药品供应商向仓管员提供入库药品的随货同行联，仓管员根据随货同行核对药品的品种、产地、规格、数量后把资料输入到计算机中并打印药品入库单。类型：主要的和基本的交叉引用：R4.1，R4.3，R4.7，R4.18 典型的事件发生过程参与者的动作系统响应1. 药品供应商提供随货同行2. 仓管员输入供应商的代码3. 显示供应商的资料4. 仓管员生成进仓单5. 生成一张进仓单，并写入进仓单的资料6. 仓管员输入一条药品进仓信息，包括：单据号，编码，数量，批号，产地，进货价7. 仓管员提示确认输入8. 保存进仓单内容并相应增加药品的库存8. 仓管员打印进仓单用例：购药货款结算参与者：药品供应商（发起者），药品会计目的：结算购药货款概述：药品供应商向药品会计提供入库药品的发票联要求结算购药款，药品会计根据药品进仓记录与发票联核对后结算货款，其余未结算的进仓记录留作以后结算。类型：主要的和基本的交叉引用：R4.5，R4.6 典型的事件发生过程参与者的动作系统响应1. 药品供应商提供发票联2. 药品会计查询供应商的供药记录3. 显示该供应商的药品进仓资料4. 药品会计核对发票和进仓记录并标记要结算的进仓记录5. 计算货款的总额6. 药品会计指示完成结算8. 保存结算的信息用例：发药参与者：中心药房管理系统（发起者），仓管员目的：为中心药房发药概述：中心药房向药库提出领药要求，仓管员根据这些要求和药品库存情况发药给中心药房，开出出仓单和发送发药信息。类型：主要的和基本的交叉引用：R4.2，R4.4，R4.13，R4.14，R4.15 典型的事机，它具有向服务器发送服务请求和显示相关数据的所有功能。客户机上的软件至少包括两类：能访问服务器数据的应用程序和网络接口软件。应用程序用于向服务器发送服务请求和显示相关数据；网络接口软件可提供各种数据传输协议。没有或很少实现企业逻辑的客户机被称为瘦客户（ThinClient）。当然，客户并非完全没有处理企业逻辑的能力，相反，也可以把部分或全部企业逻辑设计在客户机中，使其可以承担一定的数据处理能力，这样的客户就叫胖客户(flatclient)。4.1.1.3 服务器服务器(Server)是指提供服务的计算机，它能够等待客户的请求然后处理这些请求。一个服务器必须能够根据企业逻辑处理来自多个客户的多个请求。服务器上的软件至少包括两类：能处理客户机请求的应用程序和网络接口软件。在传统的两层结构的C/S系统中，企业逻辑由数据库平台的存储过程、触发器、视图以及完整性约束完成。在三层结构的C/S系统中，服务器可分为专门负责数据储存的数据服务器和运行企业逻辑的中间层应用服务器组成。4.1.2 两层和三层结构C/S系统的比较两层C/S结构就是客户端应用程序通过ODBC、SQL Link、TCP/IP直接连接数据库服务器进行通信，并完成数据的添加、修改、删除和检索等操作。从系统结构图和以往开发的经验看，两层C/S结构存在以下缺点：(1)在两层C/S结构中，客户端应用程序直接连接数据库服务器，这样数据库服务器将消耗一定的资源以处理与客户端的连接工作，并以并行方式处理客户端的处理要求。当连接的客户端达到一定数量时，数据库服务器的运行效率将会不断下降；(2)在两层C/S结构中，只有唯一一个在线的数据库服务器，这种结构将成为系统可靠性的重大隐患。如果数据库服务器因为某种原因而停止工作，那么整个系统将趋于瘫痪。(3)两层C/S结构应用程序的分发比较麻烦，需要一些*d11支持。以DELPHI为例，客户端需要安装几个BDE .dll文件，另外每个客户端还需要配置ODBC或BDE。(4)采用瘦客户模式的C/S系统由于处理都集中在服务器，系统中其他计算机很多时候处于空闲状态，他们的CPU资源和存储空间没有得到有效利用，系统升级服务器后原有数据库服务器无法再利用，造成资源和投资的浪费。如果使用胖客户模式虽然可以利用系统中客户机的资源，减少数据库库服务器的负荷，但由于企业逻辑存在于每台客户机中，若要更新程序或修改企业逻辑则要所有客户端程序都要更新，若系统中客户端计算机分布广泛或数量众多，会给维护工作带来很大的不便。正是由于两层C/S结构存在上述缺点和不足，使得自从C/S结构问世之日起，研究人员就不断致力于改进和完善它。对于上述存在的问题，解决的方法就是在客户端和数据库服务器之间加入一个企业逻辑(Business Logic)层，该层通常存放在另一台被称为应用服务器(Application Server)的机器上。三层C/S逻辑结构如图4-1所示。图4-1新加入的企业逻辑层负责对企业逻辑的执行工作和对数据服务器的连接工作，它一方面接收客户端的处理请求并转送给数据库服务器，另一方面将数据服务器的查询结果经处理后返回送给客户端。数据库服务器只需要专心响应应用服务器的数据访问请求，一方面减少了连接数量，另一方面不再负责企业逻辑的执行工作，这样就大幅度减轻了数据库服务器的工作负担，加快了其响应速度。使系统的整体工作效率也得到提高。若把企业逻辑按照功能划分为几个子模块，分别置于几个应用服务器中，从而实现企业逻辑的分布式计算，这样不但可以提高系统的响应速度，而且可以充分利用系统中配置较高的计算机的处理能力。另外，应用服务器还提供了负载平衡、容错处理Database Pooling（连接池），Object Pooling（对象池）等技术，最大限度地增加对系统资源的利用程度。（)ng t Pooooling,