学校门诊管理信息系统.doc

河南城建学院
《软件工程 项目设计》

设计题目： 学校门诊管理信息系统
院系专业： 计算机科学与技术专业
学 号： 081411105
姓 名： 李彦霞
指导老师： 王春丽

2014年 5 月 27 日

目录
目录 1
第1章 绪论 2
1.1 系统开发背景 2
1. 2系统开发目标 2
第2章 需求分析 4
2.1 需求分析过程 4
2.2 系统的功能需求 4
2.3 系统的非功能需求 6
2.4 系统软件硬件需求 6
2.5 系统用例图和动态模型图 8
第3章 概要设计 11
3.1 门诊部门的体系结构 11
3.2 门诊业务流程 11
3. 3 门诊管理系统功能 12
第4章 详细设计 14
4.1 系统划分 14
4.2 门诊管理子系统 14
4.2.1 药房管理子系统 15
4.2.2药库管理子系统 15
4.2.3综合查询子系统 15
4.2.4综合管理子系统 16
4.2.5一卡通退费管理子系统 16
4.3 数据库设计 16
5.1 系统业务流程 21
5.2 门诊管理的功能实现 22
5.3 系统测试 22
第6章 总结 24
6.1 总结 24
6.2 展望 24

第1章 绪论
1.1 系统开发背景
随着科学技术的不断发展，各行业竞争日益激烈，因此如何提高工作效率已成为当今面临的主要问题。近年来MIS(管理信息系统)陆续走入了各企事业单位，成为企业管理者的得力助手。医院是信息化程度高而且复杂的单位。其信息除具有一般的信息的特征以外，通常还有相关性、多样性、时效性以及多类媒体、数据海量、法律准则等特性。由此可见手工管理将会浪费很多的财力、物力，而HIS(医院信息系统)的引进将为医院解决这一难题。HIS的开发已从最初的“以财务管理为中心”为主要模式逐步向“以病人为中心、以医疗信息为主线”的全新管理模式转变。
我国高校校医院信息系统的研发工作，从八十年代初期算起，至今也有十多年的历史，其中经历了单机单任务的阶段，多机多任务的阶段以及微机网络一体化的阶段，应该承认这期间我们有了很大的进步。医院对信息的需求永远是高校校医院管理信息系统发展的动力。在还没有投入使用管理信息系统的校医院，传统的手工操作带来了很多的问题，譬如药库管理经常由于管理上的不当使部分药品失效报废给医院带来了一定的经济损失，门诊划价出现的人为错误造成的损失和人员工作分配不合理使得劳动效率低等问题。面对这一系列的问题，校医院管理信息系统的设计和实现是迫切的、必需的，是管理系统在医院环境的具体应用。
目前，在部分高校校医院中也存在着各种各样的管理信息系统，但由于软件水平的落后和不能完全适应具体医院的业务等原因，促使了此医院门诊管理系统的开发。本系统通过开发背景，设计、开发和实现医院门诊管理系统，提高校内医务室的工作效率。所以，针对高校校医院的门诊管理信息系统，既要整合目前已经存在的医院管理信息系统的弊端和不足进行修正，还要兼顾高校这一特点，满足高校校医院 对信息系统的需求。例如，系统功能要求可以很简单，但是数据量特别大，任何一个病人的医疗记录都是一部不断增长着的、图文并茂的书，而一所高校的校医院拥有上万份病人的病案是常见的，而且有很强的流动性。另外，病人的身份多以学生和老师为主，他们都可以现金交费，而且学生可以通过校园一卡通，老师也可以通过划账方式交费等。
1. 2系统开发目标
通过对医院门诊管理系统背景的分析，针对现在相关系统存在的问题，我们提出以下几个开发目标:用全新的软件框架设计医疗系统，从而解决医疗系统需求易变、实施成本过高、系统稳定性与可靠性差等问题:使用全新的组件式产品交付方式，使得工程部实施或第三方OEM厂商能够按照客户的需求量身订制医院门诊管理系统;采用国际、国家标准和规范，搭建稳固的医疗资源平台，为产品整合医疗体系的其他业务领域提供基石;建立

“以病人为中心，以服务为导向，经济上降低成本，医疗上控制质量”的模式;采取分布式网络结构，实现存储分布，计算分布，显示多样，以便减少单服务器的负荷压力，大大提高系统的稳定性和响应，同时也支持多种终端设备的显示。物理上我们将分成三层结构:数据服务器群，组件服务器群(程序服务器群)，用户操作终端;建立在线备份及数据转储机制，从而减少了在线联机事务处理系统的数据压力并且也保证了数据的安全和可靠。彻底解决联机事务处理与联机事务分析之间的矛盾。

第2章 需求分析
2.1 需求分析过程
软件需求分析工作是软件开发成功的前提和基础，需要研发人员与用户密切配合，将软件的功能和性能描述转换成精细的软件逻辑模型。首先研发人员需要进行细致地调查分析，认真了解用户的需求，并澄清用户的模糊需求，最终将用户非形式化的需求叙述转化为完整的需求分析文档，进而明确系统的开发目标。需求分析的基本任务包括
u 问题识别
(1)功能需求:明确待开发软件的实现功能。
(2)性能需求:明确待开发软件的技术性能指标。
(3)环境需求:明确软件运行对机器的软、硬件需求。
(4)用户界面需求:明确软件和用户交互的界面形式。
u 分析与综合，导出软件的逻辑模型
研发人员对数据流和数据结构进行详细分析，逐步细化系统的功能，找出系统各元素之间的联系和设计上的限制，形成系统的解决方案，建立目标系统的逻辑模型。
u 编写需求分析文档
为了对用户的需求清晰准确地描述，开发人员需要编写软件需求规格说明书。
u 需求分析评审
在需求分析工作的最后阶段，研发人员需要对系统的功能需求、性能需求以及其他需求进行评审并给出评价。
2.2 系统的功能需求
我们项目组针对医院信息管理系统的使用情况进行深入调研，发现大部分医院根据自身特点和业务流程，进行医院信息系统的设计与开发。比如，一些医院把病房的床位管理中，一些医院把门诊收费模块和信息系统分开等。我们项目组对学校医院目前使用的信息管理系统进行详细分析，并综合考虑部门的职能设置以及联网后的应用需求，结合项目开始阶段完成的需求分析文档，将目标系统划分为以下几个模块进行开发，如表3-1所示：

表2-1 学校医院信息管理系统的功能模块
编号
系统功能
功能模块
模块介绍

1

门诊管理
门诊挂号
门诊挂号支持一卡通挂号和现金挂号，并记录患者的基本信息
医师门诊
对患者进行病情诊断，选择项目和药品，并开除处方
病房门诊
对患者进行病情诊断，选择项目和药品，并开出处方
划价收费
对项目和药品进行划价收费

2

药房管理
入药提请
药品数量不足时，向药库申请药品
药房发药
针对缴费成功的患者发放药品
药房出药
记录药房中药品的所有流向，但不包括药房发药方式
药房库存
管理药品分库存信息

3

药库管理
提药批复
批复入药提请模块发出的提药申请
药库入药
对新购入的药品进行正常入库
药库出药
记录药库中药品的所有流向
药库库存
管理药品的库存信息

4

综合管理
门诊收费统计
统计门诊收费信息，便于管理和查询
药库出入记录
记录药品出入药库的信息
药房出入记录
记录药品出入药房的信息

5

系统管理
药品字典
负责药品信息的管理
项目字典
负责项目信息的管理
科室设置
负责科室信息
医师字典
负责医师信息的管理
出入库字典
负责药品出入药库的类型设置
出入房字典
负责药品出入药房的类型设置
操作员字典
负责操作员信息的管理，以及对操作员的使用权限进行设置
患者类别字典
负责喊着类别的信息管理
系统参数设置
负责系统草书的管理。包括最低库存数量、预警天数、挂号费等
6
一卡通退费管理
对刷卡缴费的患者，执行退费操作
7
修改密码
修改登陆密码

学校医院信息管理系统实现的主要功能是:患者在门诊挂号模块可使用校园一卡通缴费和现金缴费两种挂号方式，挂号成功后选择医师门诊或病房门诊就诊，医师根据患者病情书写电子病历，并选择相应的药品或项目，最后开出并打印患者处方。门诊管理员在划价收费模块对患者开出的药品和项目进行划价和收费，并打印收费发票。药房针对缴费成功的患者，根据药品单发放药品，若药品数量不足，可向药库发出提药申请，药库根据库存情况进行提药批复。如果存在患者缴费成功后，退掉某一药品或项目的情况，操作员在一卡通退费模块针对刷卡患者执行退费操作并开出退费凭据，患者到一卡通管理中心领取相应金额。

2.3 系统的非功能需求
非功能性需求，是指软件产品为满足用户需求必须具有且除功能需求以外的特性。本系统采用先进、成熟的软硬件技术，以便适应医疗机构的业务发展和信息化建设的需求，比如在系统开发方面，使用Microsoft公司推出的功能强大的.NET开发平台，此平台包含世界上先进的程序设计理念。
本系统可扩展性和可维护性良好，在结构设计方面采用C/S三层结构模式，将系统整体划分为表示层、业务逻辑层、数据访问层等三个部分，实现了各层在逻辑上的独立性，降低了各个层次之间的依赖，便于开发人员对系统进行维护和后期开发。由于采用模块化的结构设计，本系统能够灵活配置以适应不同环境，为系统的可扩展性奠定了良好的基础。在数据库设计上也综合考虑将来设计需求，采用SQL Serve:技术，把现实世界中的实体关系模式映射为关系数据库中对应表格，此技术具有高性能、可靠性和可扩充性等优点，方便系统的功能扩展和数据库的后期维护。
我们项目组严格遵循软件开发的工程思想，从系统的需求分析到设计再到实现。在开发方面严格遵守软件开发流程，书写规范代码，在系统和数据库设计上严格按照国家医疗卫生行业的有关标准，保证系统的质量。项目完成阶段书写完整、详细的开发文档，为本系统的后期维护、功能扩展提供良好参考。
2.4 系统软件硬件需求
我们项目组通过对需求分析文档进行详细分析和讨论，确定了系统的架构模型，包括用户交互界面、Windows窗体、软件底层环境和底层数据库等四个部分，如图2-1所示:

图2-1 学校医院信息管理系统架构图
由上图可以看出，系统架构的每一部分采用不同的软件工具进行开发，为了方便对系统的软硬件需求进行说明，本节主要从系统的开发环境和运行环境两个方面进行介绍。
开发环境的软硬件配置如下所示:
(1)软件配置
操作系统:Windows 7/XP
开发和运行环境:Microsoft .NET Framework 3.5
开发工具:Microsoft Visual Studio.NET 2008
数据库开发工具:Microsoft SQL Server 200_5
(2)硬件配置
P4 1.4G或以上CPU
2G DDR 400 Memory
80G Hard Disk
声卡、显卡主板集成
(3)网络配置
Inte110/100M网卡
10/100M自适应交换机
本系统对运行环境的软硬件配置要求如下:
(1)软件要求
Microsoft .NET Framework 3.5
Microsoft SQL Server 200_5
Windows 2003 Server(服务器端操作系统)
Windows 7/XP(客户端操作系统)
(2)硬件要求
服务器端:
P4 2.0G CPU
2G DDR 533 Memory
1606 Hard Disk
Intel 10/100M网卡
客户端:
P4 1.4G或以上CPU
1 G DDR 400 Memory
80G Hard Disk
声卡、显卡主板集成

2.5 系统用例图和动态模型图
统一建模语言(Unified Modeling Language ,UML)是一种面向对象的建模语言，使用标准化、统一的定义和标记对软件系统进行描述和建模[}3s} o UML的主要内容可由下面五类图定义:第一类是用例图，主要描述用户所理解的系统功能;第二类是静态图，包括类图、对象图和包图;第三类是行为图，包括状态图、活动图、顺序图和协作图，主要描述系统在时间和顺序上与组成对象的关系;第四类是交互图，主要描述系统对象之间的关系;第五类是实现图。
UML建模语言提供的用例图描述了系统开发者和用户基于系统功能所达成的共识，是进行需求分析的强有力工具。用例图是由参与者、用例以及用例之间的关系构成的，用来描述系统的功能需求，但不涉及系统功能的具体实现[[36]。参与者是指系统使用者在与系统交互时所扮演的角色，比如管理员、操作员等，并不特指人或事物本身。用例是指参与者对系统的操作，表示一系列动作。用例之间的关系主要包括扩展和使用，扩展关系是指一个用例通过向前一个用例添加一些动作构成的，因而继承了前一个用例的行为。使用关系是指一个用例通过对其他用例的使用构成的，这两种关系描述了几个用例的相同行为。
通过以上介绍，我们可以得到系统的用例图。

图2-2 门诊管理用例图1

图2-3 门诊管理用例图2

图2-4 药品管理用例图

图 2-5 综合查询用例图

第3章 概要设计
3.1 门诊部门的体系结构
高校校医院是专门为高校的学生和教职工提供相关服务的机构，其服务的范围是人们在医院看病活动的整个过程，因此校医院包括了医院门诊部门的所有科室:门诊挂号、医务处、门诊收费、门诊药房，医护人员护理等。医院门诊部门的体系结构图如图3-1所示。

图3-1 门诊部门体系结构图
3.2 门诊业务流程
医院是以病人为中心、以病人医疗信息为核心的一个机构，所以病人的信息贯穿了整个业务流程中。以病人就医为起点，门诊部门业务流程如图3-2所示。

图3-2 门诊部门业务流程图
就诊病人来到医院，根据情况来确定是否先挂号，如果情况比较紧急，直接送入急诊室进行检查，根据病人情况判断是否使用急救车送入附近较大医院。否则病人首先在挂号门诊进行挂号，购买病历本，生成挂号凭证，在这里类似于就医排队的道理。然后凭借挂号凭证到相关诊室就诊，在就诊过程医生通过查看和询问病人情况决定是否开立处方或申请单。病人凭借医生开立的处方或申请单到收费门诊进行划价交费，门诊收费部门是整个医院的财务重点，所以把收费工作进行了划分，分成划价和收费两个部分，提高医院账务的准确性。待病人交费之后，即可凭借交费单据到门诊药房进行拿药或者到检查治疗部门执行医嘱，最后就诊结束。另外，在就诊过程中，还存在着退药、退费、药品数量查询等业务，具体功能的需求将在后面的功能需求中重点描述。
3. 3 门诊管理系统功能
门诊管理系统功能流程图，在这个流程图中，包含病人就诊和退费退药流程，实现了医院门诊的所有基本工能，如图3-3所示。

图3-3 门诊管理系统功能流程图

第4章 详细设计
4.1 系统划分
组根据学校医院的部门设置和业务流程，将本系统划分为六个子功能系统进行设计与开发，包括门诊管理子系统、药房管理子系统、药库管理子系统、综合查询子系统、系统管理子系统、一卡通退费管理子系统和修改密码子系统。每个功能子系统根据部门职能和用户需求，又划分为相应的功能模块进行设计与开发。其中门诊管理子系统包括:门诊挂号、医师门诊、病房门诊、划价收费等四个功能模块，药房管理子系统包括:入药提请、药房发药、药房出药、药房库存等四个功能模块，药库管理子系统包括:提药批复、药库入药、药库出药、药库库存等四个功能模块，综合查询子系统包括:门诊收费统计、药库出入记录、药房出入记录等三个功能模块，系统管理子系统包括:药品字典、项目字典、科室设置、医师字典、出入库字典、出入房字典、操作员字典、患者类别字典、系统参数设置等九个功能模块。如图4-1所示:
图4-1 系统划分图
4.2 门诊管理子系统
门诊管理子系统包括门诊挂号、医师门诊、病房门诊和划价收费等功能模块。遵循“一切以病人为服务中心”的管理原则，针对患者就诊环节，使患者挂号、就诊、项目检查、药品和项目缴费这一系列活动在门诊管理子系统中形成一个整体。患者通过门诊挂号模块挂号成功后，根据自身的病情需要选择医师门诊或病房门诊模块进行就诊，医师对患者的病情诊断后，选择药品或项目，书写诊断结果并开出处方，患者持处方到划价收费模块进行药品和项目缴费。

4.2.1 药房管理子系统
根据药品出入药房的流程，药房管理子系统划分为入药提请、药房发药、药房出药和药房库等四个功能模块，药房管理员通过药房管理子系统可以实现药房管理。药房中如果存在药品数量不足的情况，药房管理员通过入药提请模块向药库发出提药申请，药库管理子系统中开发提药批复模块对应此功能，药库同意药房提药请求后，由药库出药模块发放药品，药房中药品的数量得到相应增加。
药房发药模块是针对患者拿药设计的，此模块可记录患者的基本信息和领取的药品信息。药房出药模块记录了药品流出药房的信息，包括药品基本信息、药品去向和出药类型，如个人提药、药房返回药库等。药房库存模块管理药房中药品的库存信息，比如盘点药品数量，针对数量不足的药品及时向药库申请提药，隐藏药品功能可在医师门诊和病房门诊模块，不显示此类药品的信息。
4.2.2药库管理子系统
药房中的药品是由药库发放的，因此药库管理子系统的设计应对应药房管理子系统的功能模块，包括提药批复、药库入药、药库出药和药库库存等四个功能模块，药库管理员通过药库管理子系统来管理药库中的药品。提药批复模块对应药房管理中的入药提请模块，对药房发过来的提药申请进行批复，如果同意药房提药，药库出药模块会发放相应的药品给药房。此功能模块可以显示提药的信息，既可以单条批复药品申请也可以一次性批复全部药品申请。
药库管理员通过药库入药模块记录药品进入药库的信息，包括药品的基本信息、药品来源以及入库类型，比如系统初始、采购入库和药房返回等。药库出药模块和药房管理中的药房出药模块功能相似，出库类型略有不同，包括公益活动和返回药房等。药库库存模块和药房管理中的药房库存模块功能相似，此模块可查看即将过期和数量不足的药品，以便对药品管理和及时补充，库存药品列表中的药品信息可生成EXCEL表格，方便药库管理员对药品的库存信息进行记录并存档。
4.2.3综合查询子系统
综合查询子系统包括门诊收费统计、药库出入记录和药房出入记录等三个功能模块，通过综合查询子系统，系统管理员可以查看患者缴费的信息、药房中药品出入信息和药库中药品出入信息。在门诊收费统计模块，通过输入患者姓名、医师姓名或收费口期，既可以查询某一患者缴费的详细信息，也可以查看全部患者缴费的详细信息。在药房出入记录模块，通过输入药品出入药房的方式、出入类型或出入口期，既可以查看流入或流出药房的某一种药品信息，也可以查看全部药品出入药房的信息。药库出入记录模块和药房出入记录模块功能相似，可以查看药品流入或流出药库的详细信息。

4.2.4综合管理子系统
综合管理子系统包括药品字典、项目字典、科室设置、医师字典、出入房字典、出入库字典、操作员字典、患者类别字典和系统参数设置等九个功能模块，系统管理员通过综合管理子系统对医院的基本信息进行管理。药品字典模块管理药品的基本信息，可以对药品信息进行增加、修改和删除等操作。药品字典模块优化了其他功能模块在选择药品时的使用，比如医师门诊和病房门诊，在选择药品时不需要输入药品的信息，只需要在药品代码编辑框中输入或选择某一药品代码，下面的编辑框会自动显示此药品的信息。项目字典模块和药品字典模块功能相似，可增加、修改和删除项目信息，优化了其他功能模块在选
择项目时的使用。
科室设置模块的功能和药品字典、项目字典模块的功能相似，系统管理员通过此模块可以增加、修改和删除医院的科室信息。医师字典模块管理医师的基本信息，可通过此模块进行增加、修改和删除操作。出入库字典模块可以对药品出入药库的类型进行增加、修改和删除操作，并在列表中显示药品出入类型的信息。出入房字典和出入库字典模块功能相似，记录和管理药品出入药房和药库的信息。操作员字典模块实现操作员基本信息的管理，如操作员姓名、登录的用户名和密码以及隶属科室等，可以对其进行增加、修改和删除操作，此外，通过此模块可以对操作员的操作权限进行设置。患者类型字典模块管理患者的基本信息，通过此模块可以对其进行增加、修改和删除等操作。系统参数设置界面可以对系统的基本参数，如药品最低库存、预警天数、医师库存差额和挂号费等进行设置。
4.2.5一卡通退费管理子系统
一卡通退费管理子系统是针对持校园一卡通进行刷卡缴费的患者设计的。如果存在患者缴费成功后，退掉某一药品或项目的情形，系统管理员在一卡通退费管理子系统执行退费操作并开出退费凭据，患者持退费凭据到一卡通管理中心领取相应金额。

4.3 数据库设计
数据库设计包含需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行与维护等六个阶段。概念结构设计是依据需求分析阶段完成的说明文档，将系统涉及的数据和信息抽象为独立的数据模型，即概念模型。常用的概念模型为E-R图，即实体一联系图，用来描述现实世界的数据模型。E-R图的基本元素包括:实体、属性和联系，实体是对系统软件中具有一系列不同属性事物的抽象，在E-R图中用矩形表示;属性定义了实体的性质，用椭圆或圆角矩形表示;联系是指实体之间的关系，包含一对一联系、一对多联系、多对多联系等三种类型，用菱形框表示。由于篇幅限制，本系统E-R图中只显示了部分实体的属性，使用Microsoft Visio 2010画图工具进行绘制， 如图所示。

图4-2 系统E-R图

下面为本系统中涉及到的几个重要数据表在字段结构和数据类型的方面进行说明。

表4-1 处方信息表

表4-2 药品字典表

表4-3 项目字典表

表4-4 药房库存表

表 4-5 药库库存表

第5章 系统的实现和测试
5.1 系统业务流程
我们项目组研发的学校医院信息管理系统是一套自成体系能够独立运行的信息化管理系统，本系统不但能够满足医院各部门的需求，同时也适用于医院具体数据的管理工作。系统需要实现的主要目标是:整体化的设计、共享化的数据、相对独立的业务处理、简便灵活的操作和友好的交互界面。校医院各个部门可以通过本系统及时掌握各环节的工作情况，方便自身工作高效展开。学校医院信息管理系统主要由下图所示业务流程组成，操作员输入用户名和密码，登录成功后根据权限加载子系统，即可进入其权限下的功能模块。

图 5-1 系统业务流程图

5.2 门诊管理的功能实现
我们项目组根据门诊部门的机构设置和应用需求，将门诊管理子系统划分为门诊挂号、医师门诊、病房门诊和划价收费等四个模块进行开发。患者通过门诊挂号模块挂号成功后，根据病情需要选择医师门诊或病房门诊模块就诊，医师对患者的病情诊断后，选择药品和项目，书写诊断结果并开出处方，患者持处方到划价收费模块进行药品和项目缴费，缴费成功后持收费发票领取药品或项目检查。门诊挂号模块支持患者使用校园一卡通挂号和现金挂号两种挂号方式。
校园一卡通功能在本系统中的应用主要体现在门诊管理子系统中的门诊挂号和划价收费模块，门诊挂号模块通过读卡器读取患者的基本信息以及收取挂号费，划价收费模块是患者通过刷卡方式对所购药品和检查项目进行缴费。另一个重要应用是通过刷卡方式进行缴费的患者，可以退回所购药品和项目，系统管理员在一卡通退费管理模块核查患者信息，然后退还相应金额。
本系统和校园一卡通第三方服务器建立连接，在测试和运行方面需要进行的必要设置:
(1)运行第三方代理sios ，sios是脱机流水状态代理服务器监测工具。
(2)增加系统代码syscode，这个系统代码在TA_ init3)中需要用到。步骤:右击sios-子系统维护一增加子系统代码一退出。
(3)设置商户和终端编号对应关系，即商户和TerminalNo的对应关系，这个终端编
号在TA_ init3)需要用到。步骤:右击sios一商户设置一设置商户一存盘一退出。
(4)退出sios，重新启动sios 。
然后连接动态数据库，实现数据信息的存储，从而实现学校门诊管理信息系统。
5.3 系统测试
系统测试是管理信息系统开发周期中一个十分重要而漫长的阶段。其重要性体现在它是保证系统质量与可靠性的最后关口，是对整个系统开发过程包括系统分析、系统设计和系统实现的最终审查。系统测试的对象是软件，其目的是找出软件中的错误 在进行系统测试时应遵循以下基本原则：
1．测试工作应避免由原开发软件的个人或小组来承担;
2．设计测试方案时，不仅要包括确定的输入数据，而且应包括从系统功能出发预期的测试结果;

3．测试用例不仅要包括合理、有效的输入数据，还要包括无效的或不合理的输入数据;
4．不仅要检验程序是否做了该做的事，还要检查程序是否同时做了不该做的操作;
5．软件中仍存在的错误的概率和己经发现错误的个数是成正比的;
6．保留测试用例，作为软件文档的组成部分。
系统测试采用的方法是普遍引用的“黑盒”测试和“白盒”测试法。白盒测试也称结构测试，即将软件看作一个透明的白盒子，按照程序的内部结构和处理逻辑来选定测试用例，对软件的逻辑路径及过程进行测试，检查它与设计是否相符。白盒测试是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。而“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误 在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。以下是对在使用黑盒测试方法时对系统进行测试的用例的简单举例介绍。
用例一:测试输入用户密码客户端的反应
输入内容:口令长度为3-6位。
操作步骤:12345回车。
预期结果:弹出错误提示窗口:密码输入错误，三次输入错误将锁定用户。请正确输入!
用例二:测试首次挂号不输入项为空的反应
输入内容:病人首次挂号界面中不输入姓名，直接挂号。
操作步骤:空出病人姓名文本框，直接挂号。
预期结果:弹出提示窗口:姓名不能为空，请重新输入。
经过多种方法的系统测试，发现了各种类型的错误，其中黑盒测试中发现的错误类型有:功能错误或遗漏、界面错误、数据结构或外部数据库访问错误等。

第6章 总结
6.1 总结
于计算机技术与网络技术等现代化技术的开发与应用，信息化建设逐步渗入到社会各个领域，成为当今世界发展的大趋势。医院信息化建设加强了部门之间的信息交流和数据共享，实现了办公自动化、就医流程最优化，进而在管理模式和医疗服务上发生了重大变革，全面提升了医院的社会地位和形象。
本论文以“学校医院信息管理系统的设计和开发”为背景，结合所学知识和开发经验，遵循软件开发的工程思想，从系统的需求分析到设计再到实现，最终开发出基于cis三层架构模式的学校医院信息管理系统，同时对本系统的开发过程和应用技术进行了深入研究。
首先，本文通过研究医院信息管理系统的开发背景和意义，对该课题的主要工作和创新点进行了详细说明。从医院信息系统的角度，阐述了它的构成和国内外研究现状，分析了我国医疗信息系统中存在的问题，同时阐明了该课题研究的实用价值。
其次，为方便系统设计与开发工作顺利展开，我们项目组成员严格按照需求分析的思想和方法，完成了需求分析任务，确定了系统的功能需求、非功能需求以及开发环境和运行环境的软硬件需求，并采用UML技术，定义了系统的用例图和协作图，进而确定了系统的功能模型。此外，详细介绍了本系统在需求分析、设计和开发阶段使用的关键技术，如系统的底层环境、Microsoft Visio绘图工具、客户端开发工具和数据库技术等。
最后，综合考虑校医院的系统需求，分析医院信息系统的信息构成和类别，对系统进行了详细设计，包括系统整体的架构设计、数据库设计、界面设计以及各功能模块的设计，之后在本文实现部分具体论述了系统中具有代表性的功能模块以及校园一卡通系统与本系统的集成实现。
6.2 展望
计算机网络与通信技术的迅速发展与普及，促使整个信息管理的面貌发生了根本性改变，驱使以单个计算机为中心过渡到以网络为中心，为单位部门之间的信息交流和资源共享提供了极大方便。为适应社会发展趋势和医院现代化管理要求，医院迫切需要建立具有自己特色的内部专用网络，加强各部门之间以及与社会医疗机构之间的信息通讯与共享。信息技术不仅能为医院带来巨大的经济效益，还能提高医院的社会影响，树立新的医院形象，为院领导的科学决策、口常办公和信息服务提供科学、高效、安全的现代化手段。医院信息系统包括临床信息系统、管理信息系统和办公自动化系统，我们项目组研发的学校医院信息管理系统实现了医院管理信息化。后期的研究内容主要面向临床管理信息化和医疗信息服务办公自动化，使临床业务和管理工作流覆盖全院各个业务环节，建设全面集成化的数字型医院，这也是当今世界医院信息化建设的任务和目标。

（注：专业文档是经验性极强的领域，无法思考和涵盖全面，素材和资料部分来自网络，供参考。可复制、编制，期待你的好评与关注）