医院门诊挂号收费系统设计毕业论文.doc

一种医院门诊管理信息系统的设计与应用医院门诊挂号收费系统设计毕业论文目 录摘 要IAbstractII1 绪论11.1 医院信息系统的定义11.2 开发医院信息系统的意义11.3 国内外情况21.4 医疗发展趋势与前景32 门诊系统分析62.1 可行性分析62.1.1 技术可行性62.1.2 经济可行性62.1.3 操作可行性72.2 系统需求分析72.2.1 业务及用户需求分析72.2.2 系统功能需求分析93 门诊系统概要设计123.1 系统功能设计123.1.1 系统功能结构123.1.2 系统状态流程123.2 系统数据流程设计133.2.1 挂号模块数据流程133.2.2 收费模块数据流程143.2.3 药房模块数据流程163.3 系统概念结构设计183.3.1 基本信息维护模块概念结构设计183.3.2 挂号模块概念结构设计193.3.3 收费模块概念结构设计203.3.4 药房模块概念结构设计214 门诊系统详细设计234.1 项目架构设计234.1.1 三层架构说明234.1.2 系统三层架构244.2 界面设计254.3 数据库设计264.3.1 基本信息维护表设计264.3.2 门诊挂号表设计284.3.3 门诊收费表设计304.3.4 门诊药房表设计335 实现355.1 登陆界面355.2 基本信息维护界面365.3 门诊挂号界面375.3.1 挂号375.3.2 退号375.3.3 日结385.3.4 查询385.4 门诊收费界面395.4.1 收费395.4.2 退费415.4.3 结账415.5 门诊药房界面425.5.1 药房药品管理425.5.2 药房划价425.5.3 药房配发药435.5.4 药房查询446 测试456.1 软件测试定义456.2 软件测试目的与原则456.2.1 软件测试目的456.2.2 软件测试原则456.3 测试方法456.4 测试阶段466.4.1 单元测试466.4.2 集成测试466.4.3 功能测试46结 论47参 考 文 献48附录A 挂号日结算法49附录B 门诊收费算法55致 谢59- III -一种医院门诊管理信息系统的设计与应用1 绪论1.1 医院信息系统的定义医院信息系统(Hospital Information System, HIS)在国际学术界已公认为新兴的医学信息学(Medical Informatics)的重要分支。美国该领域的著名教授Morris.Collen于1988年曾著文为医院信息系统下了如下定义：利用电子计算机和通讯设备，为医院所属各部门提供病人诊疗信息和行政管理信息的收集、存储、处理、提取和数据交换的能力，并满足所有授权用户的功能需求。1.2 开发医院信息系统的意义改善医院管理，支持医教研。我国医院的信息处理基本上还停留在手工方式，劳动强度大且工作效率低，医师护士和管理人员的大量时间都消耗在事务性工作上，致使人不能尽其才；病人排队等候时间长，辗转过程多，影响医院的秩序；病案、临床检验、病理检查等许多宝贵的数据资料的检索十分费事甚至难以实现；对这些资料深入的统计分析手工方式无法进行，不能充分为医学科研利用；在经济管理上也因而存在漏、跑、错费现象；医院物资管理由于信息不准确，家底不明，积压浪费，以致“物不能尽其用”。开发HIS是解决上述问题的有效途径。HIS系统的有效运行，将提高医院各项工作的效率和质量，促进医学科研、教学；减轻各类事务性工作的劳动强度，使他们腾出更多的精力和时间来服务于病人；改善经营管理，堵塞漏洞，保证病人和医院的经济利益；为医院创造经济效益。完整的HIS系统实现了信息的全过程追踪和动态管理，从而做到简化患者的诊疗过程，优化就诊环境，改变目前排队多、等候时间长、秩序混乱的局面。如目前多数医院就诊必须经过挂号、等候病历、划价、收费、取药或治疗一系列过程，一个患者少则排3次队，多则5、6次，用于过程性的时间最少在1个小时以上，若实施HIS以后，每个病人用于诊疗的中间过程性时间会大幅度减少；假定一家医院门诊人次为2000人次/天，年门诊250天，每人少花费半小时，则日节约1000小时，一年节约36万小时，其产生的社会效益和间接经济效益是明显的。同时HIS的实施也强化了医院内部管理，降低了医护人员的工作强度和时间，伪、冒、漏现象可以解决，也加速了资金周转和减少药品、器械等物资积压。据估计如果全国有2000家医院应用HIS，每年每所医院增收节支、加速资金回笼和周转、堵漏、减少物资积压的回收资金方面的效益按20万元估计的话(实际比这高)，则年效益估计为40亿元，十分可观。但这往往不被人所认识。当然建立HIS更主要的还在于它对医院管理、医疗质量和医学研究的长期效应带来的综合效益。因此HIS的投资一般需做基础性投资，诚如任何机构的统计部门那样，它是花钱的部门，但其重要性是公认的，投资也是必须的。HIS的效益远远超出医院本身，因为完整的病人医学记录是医学研究的重要信息资源，这类资源在手工作业环境下，大部分被抛弃了。1.3 国内外情况电子计算机在医院的应用已有三十多年的历史，60年代初，美国便开始了HIS的研究。著名的麻省总医院开发的COSTAR系统是60年代初开始并发展到今天成为大规模的临床病人信息系统。随着计算机技术的发展，70年代，HIS进入大发展时期，美日欧各国的医院，特别是大学医院及医学中心纷纷开发HIS，成为医药信息学的形成和发展的基础。7080年代，美国的HIS产业已有很大发展。1985年美国全国医院数据处理工作调查表明，100张床位以上的医院，80%实现了计算机财务收费管理，70%的医院可支持病人挂号登记和行政事务管理。25%的医院有了较完整的HIS，即实现了病房医护人员直接用计算机处理医嘱和查询实验室的检验结果。10%的医院(2530)有全面计算机管理的HIS。日本的HIS开发和应用从70年代初开始。多数日本医院是80年代以后开始进行HIS工作的，但发展十分迅猛，规模相当大，是以大型机为中心的医院计算机系统。如北里大学医院的IBM/3090双机系统。当前日本的HIS总的趋势是系统化、网络化、综合性，开始走自上而下的开发路线，一般都有大型机作为中心、支撑整个系统工作，并尽量采用微机和网络技术，投资规模大，正在实现“ordering”工作方式，即数据从发生源直接输入计算机。到1991年统计有近10家实现或基本实现此种方式。支持诊疗的功能在不断加强，系统24小时运行。不少软件是医院和计算机公司联合开发的，一些大公司也开发了一些通用的医院信息管理软件包，也有些医院自己开发。如北里大学，开发了综合的HIS，开发费用(机器设备除外)为3亿4千万日元(约合人民币1300万元)。日常运行费用支出为一年5亿1千万日元(约合人民币2000多万元)。欧洲的HIS发展比美国稍晚，大多数是70年代中期和80年代开始。欧洲HIS的特点是实现了一些区域信息系统。如丹麦的RedSystem，管理76所医院和诊所。法国第八医疗保健中心实现了能管理三所大医院和三所医药学院的一体化信息系统Grenoble Integrated HIS。随着初级卫生保健工作的发展，欧洲各国区域性医院计算机网络将实现。目前欧共体的SHINE工程已经开始，英法意德许多公司都参与了此项工程。在分布式数据库系统和开放网工程方面已做了大量工作。计算机70年代末期就进入了我国医疗行业，当时以IBM的M340小型机为主，只有少数几家大型的部属综合医院和教学医院拥有，如北京协和医院、北京肿瘤医院、301医院等，主要应用于科研和教学，还没有应用于HIS的管理。80年代初期，随着苹果PC机的出现和BASIC语言的普及，一些医院开始开发一些小型的管理软件，如工资软件等；80年代中期，随着XT286的出现和国产化，以及DBASEIII和UNIX网络操作系统的出现，一些医院开始建立小型的局域网络，并开发出基于部门管理的小型网络管理系统，如住院管理，药房管理等。进入90年代，NOVELL网和FOXBASE、FOXFRO数据库日益盛行，完整的医院网络管理系统的实现已经成为可能，于是一些有计算机技术力量的医院开始开发适合自己医院的医院管理系统。一些计算机公司也不适时机的开发HIS，如HP公司（与301医院合作）、IBM公司、微软公司、浪潮公司。但这些系统都存在如下一些问题：A软件水平较低，一般只能做些初级的事务处理，也有的软件开发之后用了一段时间就停下了，坚持不下去，其原因是：(1)各医院计算机专业人才缺乏，技术力量薄弱，特别是缺少高层次系统分析人员和跨专业复合型人才。(2)项目多，力量分散。(3)医院经费有限，很难建立起理想的软、硬件支撑环境。B重复开发多。据一个省调查，几年来，总共开发262个项目中，工资系统就有41个，医疗统计21个，人事21个，重复率达70%多，究其原因：(1) 单位管理方式有一定差异，软件不能通用。(2) 软件没有一个统一的标准，难以推广。(3) 全国没有一个较高水平、可广泛推广的医院管理软件包。1.4 医疗发展趋势与前景在1984年，邓小平同志就曾高瞻远瞩地提出：“开发信息资源，服务四化建设。”的战略思想。可见，信息化是社会发展的趋势。特别在当今世界，信息作为最积极、最有生命力的新兴社会生产力的代表，正日益成为社会与经济发展的强大动力。作为国民经济与社会发展信息化的一个重要组成部分医疗系统信息化，是指人们利用现代信息技术，收集、开发、利用医疗信息资源，实现医疗资源的高度共享，对传统的医疗管理模式、工作流程进行信息化改造的过程1。其发展顺应了国家信息化的潮流以及我国医疗事业改革与发展的需要，同时对提高医疗预防保健工作效率与服务水平、规范卫生监督管理行为具有积极和深远的意义。科学技术发展日新月异，高精尖仪器特别是电子智能仪器在医院临床和医技科室的广泛应用，使各种数据或病人信息的收集、处理具备了良好的基础。医院管理的许多信息已可以直接从检查治疗仪器上生成，或从信息发生地获取，而无需手工汇总录入；各种信息的存储空间呈现海量使得数据和信息的存储、加工处理等可以在其发生的各个阶段或各个层次同时进行。这些功能的实现，一方面归功于自动化“硬件”技术的不断更新和发展，另方面表现在“软件”技术的不断完善或更新上。管理模式的转变、操作方法的改进，以及“硬件”技术的发展，都要求所用“软件”亦随之完善或更新。这些技术和功能的更新换代时间已大大短于其设备的使用年限，有的甚至已以月计。因此，伴随着医院管理信息系统技术的进步和更新，也使资金和技术人力投入的不断增加。在这几年中，医院信息系统将进入一个新的发展阶段。由单机系统向网络化发展，由医院内部局域网向广域网拓展；由单一形式的静态向多媒体动态改变；由封闭的专有技术环境向开放的统一标准化转变。随着信息系统自动化的实现，医院管理者能够在更高层次、更大范围。更短时间里获得各种数据和信息，拥有更多、更科学的决策依据，从而使医院管理从被动转变为主动，从而扩大了医院生存与发展的空间，获得较好的社会效益和经济效益。全国近半数的医院进行了网络建设，信息系统的应用水平不断提高，逐步从以财务为重点的管理信息系统，转向临床加管理的信息系统，一些医院正在探索建立医生工作站、护士工作站、临床检验信息系统、医学影像系统、电子病历和远程医疗为特点的数字化医院。许多医疗卫生机构建立了互联网站、开展网上挂号、预约就诊、信息咨询、健康教育和远程服务等。但是，医院因其工作的复杂性和各医院管理模式的不尽相同，使医院管理计算机软件的开发具有很大的挑战性和潜力。特别是在目前尚未形成一套成熟、有效的应用软件的情况下，各公司竞相开发，有的只做成结构框架就急于推向市场，由用户再行二次开发；有的医院聘用公司人员开发软件，应用后因软件的更新维护工作跟不上而影响其正常运行；有的医院甚至投资数十万元仍一无所获。医院各自为战的重复开发和被动应用，加上公司的商业竞争，使医院信息系统的建设处于一种热情支持、积极投资，但却与效用成反比的局面。随着知识经济时代的到来，标准化是信息化的基础，信息化必然伴随着标准化。但是由于我国标准化工作严重滞后，标准化问题目前已成为信息化进程的一个主要障碍。目前，全国医院信息管理软件的研制开发缺乏统一的标准、无统一的HIS数据接口标准，不利于整个地区医院的资源共享。统一标准，是医疗信息化建设的基础，也是进行信息交换与共享的基本前提。然而目前我国医疗行业中各种业务规范与标准，尚处于逐步建立、完善和提高的过程，尤其是医疗信息标准化工作还比较薄弱。这对医疗信息化的进一步的发展毫无疑问形成了较大的阻碍。由于缺乏统一的业务规范与标准，使不同的医疗信息系统之间无法兼容，数据无法共享，数据统计分析工作更是无法进行，造成了医疗信息资源的极大浪费。我国正处于医疗信息化建设与应用过程中，由于人们观念、习惯的转变，人员素质的提高等方面都需要比较长的时间，毫无疑问会产生上述之类的一些问题，但若通过一系列的措施，例如加强医疗信息化标准化体系的规划和建设、进行教育和培养人才的规划，以及加大医疗信息系统软件上的投入和开发力度等等，相信会对我国医疗信息化建设起到推动的作用。诚然在我国真正实现医疗信息化管理，还有很长一段路要走。但是在21世纪，不断加快信息化的今天，医疗信息化已是大势所趋，因而医疗信息化之路必定要坚持肯定地走下去，并为全社会的医疗服务质量做出贡献。 2 门诊系统分析 本节通过进行可行性分析，判断本医院门诊管理信息系统是否可行，是否能为实际应用创造价值，为医院信息管理或患者就医查询提供方便。然后再针对现今医院的实际需求进行分析，理清本系统的总体设计，需要实现的功能。2.1 可行性分析可行性分析是系统分析阶段的重要活动，是对系统进行全面、概要的分析。它的任务是确定项目开发是否必要和可行。它的主要目标是：进一步明确系统的目标、规模和功能，对系统开发背景、必要性和意义进行调查分析，并根据需要和可能提出拟开发系统的初步方案和计划，明确问题，对所提供系统大致规模和目标的几个有关约束条件进行论证，并且提出系统的逻辑模型和各种可能的方案，从而为系统开发项目的决策提供科学依据。本节从技术的可行性，经济的可行性以及操作的可行性三个方面来论证本信息管理系统的可行性。2.1.1 技术可行性技术可行性即是对现有技术进行评价，以明确能否利用现有技术进行系统开发及系统实施。硬件：计算机的存储量大，运算速度快，外部设备的功能好，效率高，可靠性高，通信设备的能力、质量都满足要求。操作系统：windows xp/2000接口能力强，数据库管理系统的功能足够。编译器：Visual Studio 2005，利用C#.net编写实际管理系统更简便易行。数据库：Oracle 10g，数据管理更加安全可靠。本人已经十分熟悉C#的编程，Oracle数据库，因此技术上是可行的。2.1.2 经济可行性对组织的经济状况和投资能力进行分析，对系统建设、运行和维护费用进行评估，对系统建成后可能取得的社会及经济效益进行估计。目前国内应用HIS的医院管理在信息化上的软硬件投资只占其年收入的1%-3%,而应用HIS后，阻塞了管理漏洞，杜绝了药品的丢失，节省了人力，提高了医院的财、物管理水平，改善了患者的就医环境，方便了患者就医和查询，提高了医院的服务效率和服务质量。因此带来的经济回报将远远超过信息化过程中的投入。2.1.3 操作可行性本系统大概需要两个月的时间完成。前两个星期主要是以看书以及收集有关系统方面的资料为主；接下来就是对系统的分析、系统架构、数据库设计、界面设计、编写代码，测试等等。而这些东西对于本系统来说是可行的。2.2 系统需求分析2.2.1 业务及用户需求分析管理信息系统是一门新兴的、集成管理科学、信息科学、系统科学及计算机科学为一体的综合性学科，研究的是信息管理活动的全过程，以便有效的管理信息，提供各类管理决策信息，辅助企业进行现代化管理。管理信息系统它具备数据处理、计划、控制、预测和辅助决策功能，具体作用如下5点内容： 用统一标准处理和提供信息，排除使用前后矛盾的不完整的数据； 完整、及时提供在管理及决策中需要的数据； 利用指定的数据关系分析数据，客观预测未来； 向各级管理机构提供不同详细程度的报告，缩短分析和解释的时间； 用最低的费用最短的时间提供尽可能精确、可靠的信息，以便使决策者选择最佳 的实施方案，以提高企业的经济效益。图2.1是系统的总体业务流程，一个患者进入医院先到挂号处进行现场挂号，领取病例卡号，如果患者在当天内不想就医，可进行退号，即退相关费用，如挂号费、病历本费用等，由于门诊医生站属于临床诊断领域，实现较为困难，因此本系统把药房划价代替门诊医生站，为患者划价，即开处方药品，然后患者到门诊收费处进行缴费，如果此时患者不想开药或者不想要药品中的某几种，可进行门诊退费。这样做是为了迎合实际需求，让医院管理更加符合现实。接着药房进行配、发药，患者领取药品之后就行了，如果领取药品之后，发现某些药品不想要，则同样可进行退费，不过先应该到药房进行退药，再到门诊收费处进行退费，这样做的目的是为了防止漏洞，试想一下，如果患者先到门诊收费处退费了，药品还在自己的手中，患者可以选择不退药品，此时就会给医院带来损失。本系统是从一个患者到医院挂号，然后进行划价，收费，药房取药的全过程。从图中可以简要看出，数据能实现全面跟踪，以便医院进行管理和决策。图2.1 系统总体业务流程图医院的医疗水平和服务质量一直是社会关注的焦点，仅靠增加基础设施投入和脱离信息化的管理方法的改进，是不能从根本上提高医院的工作效率、服务质量和管理水平的。医院信息管理系统的目的就是减轻业务劳动强度，减少了差错，科学管理药品，节省人力，提高医院的财、物管理水平，增加经济效益，改善患者的就医环境，方便患者就医和查询，提高医院的服务效率和服务质量，提高医院的医疗质量和管理水平。所以，一个现代化的适应社会发展需要的医院，除了具备一流的医疗队伍、一流的服务设施之外，还应具备一流的管理信息系统。目前很多医院信息管理仍然是人工手动计算,整理,查询，管理病房等各项工作,执行效率非常低,不方便,给医务人员带来了不少麻烦;现在已是21世纪,为了跟上时代的发展,实现信息管理自动化刻不容缓。医院信息管理系统不仅方便医院的管理，而且方便病人信息的综合管理，信息查询，床位查询，医嘱管理等等。21世纪，管理才能出效率，将先进的电脑技术和现代医院的管理完美的结合起来，完成以前需要大量人工才能完成的任务。实现了医疗、服务一体的全新概念的服务和管理方式是我们的当务之急。2.2.2 系统功能需求分析本系统根据医院的需求以及病人的实际情况，通过本人的详细分析，实现了医院门诊部分的主要功能需求，包括门诊挂号，门诊收费，门诊药房，基本信息维护四个主要功能模块。如图2.2所示，基本信息维护模块一般只有管理员或者高级操作人员才有权限进入，它是对一些基本信息的管理，如人员、科室，医院的一些常数进行管理。下面详细分析每个模块包含的功能。图2.2 系统总结构图基本信息维护模块包含的功能有常数维护、科室人员管理、人员组管理、权限维护，常数维护可对合同单位、挂号级别等基本常数进行维护；科室人员管理可对用户和科室进行增加或者修改；人员组管理可对用户可登陆的模块进行维护；权限维护可对用户登陆的模块的权限大小进行维护，如只有该模块查询权限，则无法进行该模块内删除、修改、增加数据的操作。图2.3 基本信息维护模块结构图挂号管理包含的功能有现场挂号、退号、患者基本信息维护、日结以及门诊挂号相关的查询，如科室收入汇总查询、挂号员工作量查询、挂号情况查询等等。挂号实现了患者的基本信息录入，门诊挂号等待看诊；患者挂号了但是想离开时可进行退号；患者基本信息维护能够对患者的基本信息进行修改；日结则是对挂号员上次日结到本次日结时间内发生的挂号进行结账，缴款。图2.4 门诊挂号模块结构图门诊收费包含的功能有门诊收费、门诊退费、门诊结账(日结)以及门诊收费相关的查询。门诊收费是对药房划价对患者产生的处方进行收费；门诊退费是当患者已经到药房进行退药后进行退费操作；门诊结账则是对收款员上次结账日期到本次结账日期期间发生的收费进行结账，缴款。图2.5 门诊收费模块结构图门诊药房包含的功能有药品管理、门诊划价(收费)、门诊退费、门诊配药、门诊发药、门诊退药以及药房内的相关查询。药品管理可对药品信息进行增加或者修改；门诊划价相当于医生为患者开处方；门诊配药是配药员预先给已经收费患者进行配药，方便患者取药；门诊发药是发药员把药品发到患者手中；门诊退药则是患者已经拿到药品后，在有效条件下进行退药的操作。图2.6 门诊药房模块结构图 3 门诊系统概要设计这部分主要描述了系统功能设计，首先讲述了本系统的整体结构，系统包括基本信息维护、门诊挂号、门诊收费、门诊药房四个主要模块，然后仔细描述了各模块的数据流程，跟踪各模块的业务处理流程，最后描绘了各模块内主要的实体类之间的联系。3.1 系统功能设计3.1.1 系统功能结构图3.1是本系统的功能结构图，描述了系统登陆到各个子模块可进行操作的功能。用户首先进入系统登录界面，输入用户名、密码进行身份验证，再进入模块选择，根据该用户的模块权限选择登录的模块，再进行操作，如果该用户没有任何一个模块的登录权限，则无法进入功能操作界面。图3.1 系统功能结构图3.1.2 系统状态流程如下图是本系统的状态流程图，简要描绘了系统及模块间的操作流程。用户可以登陆不同的子模块，更改登陆可登陆进入其它模块。用户先输入用户名，密码，进入登陆模块界面，选择要登陆的模块，然后再进行该模块进行相关操作。系统提供注册功能，可以在用户登录进入系统的情况下，把该用户注销，同时用其它的用户名、密码登录。图3.2 系统状态流程图3.2 系统数据流程设计3.2.1 挂号模块数据流程患者首先到患者基本信息登记处索取“患者基本信息登记表”，填写完整后交给基本信息录入员录入电脑，患者带着基本信息登记表到挂号处进行挂号，挂号员收取挂号各种费用，同时打印挂号收据，发放“初诊病历”，如果患者想退号，患者提交挂号收据，挂号员判断是否可以退号（只能退当天的号、已经医生看诊的不允许退号、预约挂号不允许退号），如果可以退号，则进行退号操作，并把挂号费退给患者。图3.3 挂号数据流程图3.2.2 收费模块数据流程 医院门诊收费处的主要业务是门诊收费和门诊退费，下面介绍了这两个主要业务流程的执行过程。1. 门诊收费流程门诊收费处可以进行划价操作，需要进行划价的，那么进行划价操作，否则进行收费操作。门诊收费处可以根据划价信息进行收费，也可以直接进行收费，门诊收费处收费时，确定支付方式（信用卡、支票等），确定分发票要求，最后打印统一门诊收费发票。图3.4 门诊收费流程图2. 门诊退费流程如果患者收费项目没有执行，那么可以直接退费，否则需要填写退费申请单，并且经过领导审核,如果患者的发票是隔日的，那么一定需要执行科室填写退费申请单，退费前需要财务领导进行审核，收费员根据收费申请单和发票进行退费,如果是交叉退费，也需要财务领导进行审核，才可以退费。如果收费时间很久的发票退费，软件不予以处理，直接到财务科手工退费。当患者收费项目已经执行了再进行退费时，应该先在药房退还药品，再到门诊收费处退药品费用。本系统的内部处理是把原来划价的处方单作废，再生成一条新的处方，这样做有利于医院统计、管理，也可减少不必要的医疗纠纷，避免医生开错药、乱开药和患者乱退药的情况。图3.5 门诊退费流程图3.2.3 药房模块数据流程1. 门诊药房发药流程门诊收费接受患者电子处方或手工处方进行收费；扣除库存药品虚库存。门诊药房系统接受收费信息，自动刷新待取药患者列表，显示患者处方信息；患者送方到药房取药。配药人员在配药台模块内，根据设置进行配药标签或配药清单补打(如已自动打印则不需补打，提前捡药)。配药人员对处方做配药确认，记录配药人员工作量信息。已配药患者信息发送发药台，同时大屏幕刷新已配好药的患者列表。患者根据当前大屏幕的待取药患者信息，排队取药。发药人员在发药模块内，对患者处方进行确认，扣除库房实库存，还虚拟库存。记录发药人员工作量信息。对于当日未取药患者，在虚拟库存管理模块内，对该处方单独进行虚拟库存还库操作。图3.6 门诊药房发药流程图2. 门诊药房退药流程判断是否已超过允许退费时间，如果已超过则不允许退费，患者需要得到医生开据药品退费说明，避免患者无故退药的情况，然后经过门诊药房负责人签字确认，此时软件生成一条退费信息，门诊收费根据病历号得到该退费信息，然后患者再进行退费。图3.7 门诊药房退药流程图3.3 系统概念结构设计该部分描绘了各个模块的E-R图，各实体的一些主要属性及联系。E-R方法是“实体-联系方法”（Entity-Relationship Approach）的简称。它是描述现实世界概念结构模型的有效方法。它一般包括实体型、属性、联系三个组成部分。实体型(Entity)：具有相同属性的实体具有相同的特征和性质，用实体名及其属性名集合来抽象和刻画同类实体。属性(Attribute)：实体所具有的某一特性，一个实体可由若干个属性来刻画。联系(Relationship)：联系也称关系，信息世界中反映实体内部或实体之间的联系。实体内部的联系通常是指组成实体的各属性之间的联系；实体之间的联系通常是指不同实体集之间的联系。3.3.1 基本信息维护模块概念结构设计首先，系统有个超级管理员，可进行信息的维护，人员添加，人员功能模块维护，科室维护等等。从图3.8中可以看出，用户以及管理员必须是医院的员工，但是员工未必有登陆此系统的权限。系统有权限维护模块，可维护用户功能模块里的每个菜单或者工具栏的操作权限，如该用于只有一个界面查询权限，则不能在该界面下进行增加、删除或者修改操作，增加系统的灵活性和安全性。本系统中设计的员工可对应多个科室，也就是说用户能用不同的所在科室登陆系统，进行只有在该科室下才能进行某些操作。图3.8 基本信息维护E-R图3.3.2 挂号模块概念结构设计挂号子模块中有一些基本数据的维护，如挂号级别维护，合同单位维护。挂号级别是患者想挂号的级别，如专家号+病例、专科号、普通号，不同的挂号级别对应的挂号费也不相同；合同单位是对患者采取的收费标准，如现金、医保、市保、退休等等。图3.9挂号E-R图中的挂号实体是挂号模块中的核心结构，记录了患者的信息、挂号信息等等、是否日结等等。挂号实体的合同号、挂号级别分别与挂号级别实体的挂号级别编号跟合同单位实体的合同编号相关联。3.3.3 收费模块概念结构设计 如图3.10所示，收费子模块中发票实体是整个模块的核心，它关联着发票明细、项目明细、支付方式、费用明细、日结等等许多信息，甚至处方实体中的发票号也是与发票实体关联着。发票实体中维护着发票号、患者病历号、金额、是否有效、是否日结等等非常重要的信息，它门诊财务管理、核对的主要管理对象。发票明细是一张发票对应的一些收费信息，费用明细则是门诊流程中对收费项目进行动态跟踪与管理的实体。本系统支持多支付方式，可用银行卡、医保卡等等进行刷卡收费。3.3.4 药房模块概念结构设计图3.11中的处方实体是在药房划价或者门诊划价时产生，它是医生给患者开的一张处方，其中包括处方号、病历号、处方状态、处方金额、配发药人等等属性。处方明细是一张处方中医生为患者开的药品明细或者项目明细，像开的哪个药品、药品数量、用法、频次、每次剂量、处方号、是否退药、摆药人等等信息。处方与处方明细实体是通过处方号相关联的，即一个处方包括多个处方明细，通俗的说，一个患者到医院就医，医生开了一张处方单，这就相当于一个处方实体，而处方单上的多个项目明细及处方明细。图3.9 挂号E-R图图3.10 收费E-R图图3.11 药房E-R图4 门诊系统详细设计 本节是对医院门诊管理信息系统的详细设计，本系统采用三层架构，因此先讲述了三层架构的特点，采用三层架构对设计本系统的好处，然后再对系统进行了数据和界面上的设计。4.1 项目架构设计4.1.1 三层架构说明本系统采用三层架构：数据访问层(DAL)，逻辑业务层(BLL)，表示层(UI)。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或成为领域层）、表示层。三层结构原理：3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。表示层位于最外层（最上层），离用户最近。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。例如Martin Fowler在Patterns of Enterprise Application Architecture一书中，将整个架构分为三个主要的层：表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans，对业务逻辑层作了更细致地划分，细分为应用层与领域层，通过分层进一步将领域逻辑与领域逻辑的解决方案分离。业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。采用三层架构的优点如下： 1、开发人员可以只关注整个结构中的其中某一层； 2、可以很容易的用新的实现来替换原有层次的实现； 3、可以降低层与层之间的依赖； 4、有利于标准化； 5、利于各层逻辑的复用。4.1.2 系统三层架构图3.1为系统三层架构简图，简要说明了系统的层次结构。图4.1 系统三层架构简图其中数据库处理类包括DAL.Database，DAL.Oracle.Database，DAL.SqlDatabase，DAL.DataAccess四个类。Database类是连接数据库的接口，可根据不同的数据库进行连接，DataAccess类提供对数据库进行读取和保存数据的操作。对于系统中的每个实体，都维护了一个实体类，便于读取和管理，每个子模块都有一个自己的业务处理类，处理与它相关的一些业务。界面层则是面向用户，提供用户操作的界面。4.2 界面设计界面设计初期，就定义了界面UI规范，无论是控件使用，提示信息措辞，还是颜色、窗口布局风格，遵循统一的标准，做到真正的一致。使用户使用起来能够建立起精确的心里模型，使用熟练了一个界面后，切换到另外一个界面能够很轻松的推测出各种功能，语句也不需要费神理解。降低对操作人员培训的成本，培训人员不需费力逐个指导。能给用户统一的感觉，不觉得混乱，心情愉快，支持度增加 。本系统定义了许多自定义用户控件和用户窗体，易于重用与维护。例如，系统子模块的功能窗体风格一致，统一继承了BaseForm窗体，查询类窗体又统一继承了BaseQueryForm窗体，如此重用性很高，也便于系统后期维护。图4.2 BaseQueryForm界面4.3 数据库设计此系统的数据库设计是根据实际需求，结合本人以往经验进行设计，虽然有些设计不是十分理想，但是能实现基本功能需求。数据表分为四个模块：基本信息维护、挂号管理、门诊收费、门诊药房。基本信息维护中的表是对一些基本信息的维护，如员工、系统用户、登陆科室、权限、系统功能模块等等的维护；挂号管理包含挂号、退号、日结、患者等信息；门诊收费主要是进行财务上的收费、核算等，其中需用的表有发票信息、费用明细、收费方式、日结等表结构；门诊药房主要是跟药品的发放关联，相关的表有处方主表、处方明细、药品信息等等。4.3.1 基本信息维护表设计用户表里主要包括用户编号、用户名称、用户密码三个字段，其中用户编号是主键，该表中的用户能登陆系统，进行系统操作，表结构如表4.1所示。表4.1 用户表NameTypeNullableDefaultCommentsUSER_CODEVARCHAR2(6)N用户编号USER_NAMEVARCHAR2(20)N用户名称USER_PASSWORDVARCHAR2(20)N用户密码员工表维护着医院的一些基本员工，如医生，护士，收款员和管理员等等，其中编号是主键，本系统的设计特点是员工表里维护的人员才能成为系统的用户，登陆系统进行操作。这样设计可进行严密的人员控制，防止安全泄密或者黑客攻击。表结构如表4.2所示。表4.2 员工表NameTypeNullableDefaultCommentsCODEVARCHAR2(6)N编号NAMEVARCHAR2(10)N名称DEPT_CODEVARCHAR2(4)科室编号TYPENUMBER(20)Y员工类别SEXVARCHAR2(2)Y男性别IDVARCHAR2(20)Y身份证号EDUCVARCHAR2(10)Y学历科室表维护了医院的一些科室，描述了这些科室是否是挂号科室，是否停用，是否是执行科室，挂号费等信息。如表4.3所示，其中科室编号是主键。表4.3 科室表NameTypeNullableDefaultCommentsDEPT_CODEVARCHAR2(4)N科室编号DEPT_NAMEVARCHAR2(50)N科室名称DEPT_TCODEVARCHAR2(4)Y科室类别编号REG_FEENUMBER(6,2)Y0挂号费IS_STOPVARCHAR2(1)Y0是否停用,1是/0否IS_REGVARCHAR2(1)Y1是否是挂号科室,1是/0否IS_EXECVARCHAR2(1)Y0是否是执行科室,1是/0否权限表维护了系统用户的功能权限，每个用户在每个功能菜单下的权限都不尽相同，如用户可以有一个功能的查询权限，但是没有修改权限，则该用户只能读取这些数据，不能进行修改，这样设计的目的是严格控制用户权限，防止用户错误修改数据，导致不必要的损失。如表4.4所示，其中用户编号、功能模块编号是主键。表4.4 权限表NameTypeNullableDefaultCommentsUSER_CODEVARCHAR2(6)N用户编号FUNCTION_IDVARCHAR2(10)N功能模块编号FUNCTION_NAMEVARCHAR2(4)功能模块名称DELETE_RIGHTNUMBER(20)Y1删除权限EDIT_RIGHTVARCHAR2(2)Y1修改权限ADD_RIGHTVARCHAR2(20)Y1增加权限READ_RIGHTVARCHAR2(10)Y1查询权限4.3.2 门诊挂号表设计 门诊挂号主表是一个非常庞大的数据表，它既包括了患者的一些信息，还包括了患者挂号、是否收费、是否有效、是否日结的一些信息，如表4.5所示，表中只列出了一部分属性，其中发票号是主键。表4.5 挂号主表NameTypeNullableDefaultCommentsCARD_NOVARCHAR2(10)N病例号/就诊卡号REG_DATEDATEN挂号日期NAMEVARCHAR2(40)Y姓名SEX_CODEVARCHAR2(1)Y性别PACT_CODEVARCHAR2(10)Y合同号REGLEVL_CODEVARCHAR2(3)Y挂号级别DEPT_CODEVARCHAR2(4)Y科室号DOCT_CODEVARCHAR2(6)Y医师代号YNREGCHRGVARCHAR2(1)Y挂号收费标志 1是/0否INVOICE_NOVARCHAR2(12)Y发票号REG_FEENUMBER(6,2)Y0挂号费PAY_COSTNUMBER(6,2)Y自付金额VALID_FLAGVARCHAR2(1)Y0退费,1有效,2作废OPER_CODEVARCHAR2(6)Y操作员代码OPER_DATEDATEY操作时间CANCEL_OPCDVARCHAR2(6)Y作废人CANCEL_DATEDATEY作废时间BALANCE_FLAGVARCHAR2(1)Y01已日结/0未日结BALANCE_OPCDVARCHAR2(6)Y日结人BALANCE_DATEDATEY日结时间YNSEEVARCHAR2(1)Y是否看诊 1是/0否SEE_DATEDATEY看诊日期 挂号员日结档是医院门诊进行日结的统计，它是对每个挂号员当天的挂号情况进行统计，本系统设计方式是只有挂号员本人才能对自己的当天工作进行日结，如果其中有中断，则对上次日结结束时间到本次日结时间这段时间内进行日结，每次日结产生一个日结号。如表4.6所示，其中日结序号是主键。表4.6 挂号员日结档NameTypeNullableDefaultCommentsBALANCE_NOVARCHAR2(12)N日结序号BEGIN_DATEDATEY开始时间END_DATEDATEY结束时间TOT_QTYNUMBER(6)Y处方数量TOT_REGNUMBER(8,2)Y0挂号费总额TOT_CHKNUMBER(8,2)Y0检查费总额TOT_DIGNUMBER(8,2)Y0诊察费总额TOT_OTHNUMBER(8,2)Y0附加费总额TOT_OWNNUMBER(8,2)Y0现金总额TOT_PAYNUMBER(8,2)Y0自付总额TOT_PUBNUMBER(8,2)Y0记帐总额OPER_CODEVARCHAR2(6)Y操作员OPER_DATEDAT