学校门诊管理信息系统.docx
《学校门诊管理信息系统.docx》由会员分享，可在线阅读，更多相关《学校门诊管理信息系统.docx（28页珍藏版）》请在冰豆网上搜索。
学校门诊管理信息系统
河南城建学院
《软件工程项目设计》
设计题目：
学校门诊管理信息系统
院系专业：
计算机科学与技术专业
学号：
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需求分析过程
软件需求分析工作是软件开发成功的前提和基础，需要研发人员与用户密切配合，将软件的功能和性能描述转换成精细的软件逻辑模型。
首先研发人员需要进行细致地调查分析，认真了解用户的需求，并澄清用户的模糊需求，最终将用户非形式化的需求叙述转化为完整的需求分析文档，进而明确系统的开发目标。
需求分析的基本任务包括
◆问题识别
（1）功能需求:
明确待开发软件的实现功能。
（2）性能需求:
明确待开发软件的技术性能指标。
（3）环境需求:
明确软件运行对机器的软、硬件需求。
（4）用户界面需求:
明确软件和用户交互的界面形式。
◆分析与综合，导出软件的逻辑模型
研发人员对数据流和数据结构进行详细分析，逐步细化系统的功能，找出系统各元素之间的联系和设计上的限制，形成系统的解决方案，建立目标系统的逻辑模型。
◆编写需求分析文档
为了对用户的需求清晰准确地描述，开发人员需要编写软件需求规格说明书。
◆需求分析评审
在需求分析工作的最后阶段，研发人员需要对系统的功能需求、性能需求以及其他需求进行评审并给出评价。
2.2系统的功能需求
我们项目组针对医院信息管理系统的使用情况进行深入调研，发现大部分医院根据自身特点和业务流程，进行医院信息系统的设计与开发。
比如，一些医院把病房的床位管理中，一些医院把门诊收费模块和信息系统分开等。
我们项目组对学校医院目前使用的信息管理系统进行详细分析，并综合考虑部门的职能设置以及联网后的应用需求，结合项目开始阶段完成的需求分析文档，将目标系统划分为以下几个模块进行开发，如表3-1所示：
表2-1学校医院信息管理系统的功能模块
编号
系统功能
功能模块
模块介绍
1
门诊管理
门诊挂号
门诊挂号支持一卡通挂号和现金挂号，并记录患者的基本信息
医师门诊
对患者进行病情诊断，选择项目和药品，并开除处方
病房门诊
对患者进行病情诊断，选择项目和药品，并开出处方
划价收费
对项目和药品进行划价收费
2
药房管理
入药提请
药品数量不足时，向药库申请药品
药房发药
针对缴费成功的患者发放药品
药房出药
记录药房中药品的所有流向，但不包括药房发药方式
药房库存
管理药品分库存信息
3
药库管理
提药批复
批复入药提请模块发出的提药申请
药库入药
对新购入的药品进行正常入库
药库出药
记录药库中药品的所有流向
药库库存
管理药品的库存信息
4
综合管理
门诊收费统计
统计门诊收费信息，便于管理和查询
药库出入记录
记录药品出入药库的信息
药房出入记录
记录药品出入药房的信息
5
系统管理
药品字典
负责药品信息的管理
项目字典
负责项目信息的管理
科室设置
负责科室信息
医师字典
负责医师信息的管理
出入库字典
负责药品出入药库的类型设置
出入房字典
负责药品出入药房的类型设置
操作员字典
负责操作员信息的管理，以及对操作员的使用权限进行设置
患者类别字典
负责喊着类别的信息管理
系统参数设置
负责系统草书的管理。
包括最低库存数量、预警天数、挂号费等
6
一卡通退费管理
对刷卡缴费的患者，执行退费操作
7
修改密码
修改登陆密码
学校医院信息管理系统实现的主要功能是:
患者在门诊挂号模块可使用校园一卡通缴费和现金缴费两种挂号方式，挂号成功后选择医师门诊或病房门诊就诊，医师根据患者病情书写电子病历，并选择相应的药品或项目，最后开出并打印患者处方。
门诊管理员在划价收费模块对患者开出的药品和项目进行划价和收费，并打印收费发票。
药房针对缴费成功的患者，根据药品单发放药品，若药品数量不足，可向药库发出提药申请，药库根据库存情况进行提药批复。
如果存在患者缴费成功后，退掉某一药品或项目的情况，操作员在一卡通退费模块针对刷卡患者执行退费操作并开出退费凭据，患者到一卡通管理中心领取相应金额。
2.3系统的非功能需求
非功能性需求，是指软件产品为满足用户需求必须具有且除功能需求以外的特性。
本系统采用先进、成熟的软硬件技术，以便适应医疗机构的业务发展和信息化建设的需求，比如在系统开发方面，使用Microsoft公司推出的功能强大的.NET开发平台，此平台包含世界上先进的程序设计理念。
本系统可扩展性和可维护性良好，在结构设计方面采用C/S三层结构模式，将系统整体划分为表示层、业务逻辑层、数据访问层等三个部分，实现了各层在逻辑上的独立性，降低了各个层次之间的依赖，便于开发人员对系统进行维护和后期开发。
由于采用模块化的结构设计，本系统能够灵活配置以适应不同环境，为系统的可扩展性奠定了良好的基础。
在数据库设计上也综合考虑将来设计需求，采用SQLServe:
技术，把现实世界中的实体关系模式映射为关系数据库中对应表格，此技术具有高性能、可靠性和可扩充性等优点，方便系统的功能扩展和数据库的后期维护。
我们项目组严格遵循软件开发的工程思想，从系统的需求分析到设计再到实现。
在开发方面严格遵守软件开发流程，书写规范代码，在系统和数据库设计上严格按照国家医疗卫生行业的有关标准，保证系统的质量。
项目完成阶段书写完整、详细的开发文档，为本系统的后期维护、功能扩展提供良好参考。
2.4系统软件硬件需求
我们项目组通过对需求分析文档进行详细分析和讨论，确定了系统的架构模型，包括用户交互界面、Windows窗体、软件底层环境和底层数据库等四个部分，如图2-1所示:
图2-1学校医院信息管理系统架构图
由上图可以看出，系统架构的每一部分采用不同的软件工具进行开发，为了方便对系统的软硬件需求进行说明，本节主要从系统的开发环境和运行环境两个方面进行介绍。
开发环境的软硬件配置如下所示:
（1）软件配置
操作系统:
Windows7/XP
开发和运行环境:
Microsoft.NETFramework3.5
开发工具:
MicrosoftVisualStudio.NET2008
数据库开发工具:
MicrosoftSQLServer200_5
（2）硬件配置
P41.4G或以上CPU
2GDDR400Memory
80GHardDisk
声卡、显卡主板集成
（3）网络配置
Inte110/100M网卡
10/100M自适应交换机
本系统对运行环境的软硬件配置要求如下:
（1）软件要求
Microsoft.NETFramework3.5
MicrosoftSQLServer200_5
Windows2003Server（服务器端操作系统）
Windows7/XP（客户端操作系统）
（2）硬件要求
服务器端:
P42.0GCPU
2GDDR533Memory
1606HardDisk
Intel10/100M网卡
客户端:
P41.4G或以上CPU
1GDDR400Memory
80GHardDisk
声卡、显卡主板集成
2.5系统用例图和动态模型图
统一建模语言（UnifiedModelingLanguage,UML）是一种面向对象的建模语言，使用标准化、统一的定义和标记对软件系统进行描述和建模[}3s}oUML的主要内容可由下面五类图定义:
第一类是用例图，主要描述用户所理解的系统功能;第二类是静态图，包括类图、对象图和包图;第三类是行为图，包括状态图、活动图、顺序图和协作图，主要描述系统在时间和顺序上与组成对象的关系;第四类是交互图，主要描述系统对象之间的关系;第五类是实现图。
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图中只显示了部分实体的属性，使用MicrosoftVisio2010画图工具进行绘制，如图所示。
图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）设置商户和终端编号对应关系
升级会员 