医院监护系统设计软件工程课程设计.docx
《医院监护系统设计软件工程课程设计.docx》由会员分享,可在线阅读,更多相关《医院监护系统设计软件工程课程设计.docx(36页珍藏版)》请在冰豆网上搜索。
医院监护系统设计软件工程课程设计
第一章可行性研究报告
1.1引言
医院做为一个与人民生命健康密切相关的重要机构,势必要在各方面实现信息化,与此同时,对医疗卫生的要求也越来越高。
以方便医护人员更好的了解病人的情况,给病人提供及时的治疗。
本系统就是针对这方面的迫切需求而设计实现的。
1.1.1编写目的
此文档作为用户对即将开发的软件的功能要求,是软件设计和开发者的主要依据。
1.1.2项目背景
项目名称:
医院计算机监护系统
软件开发单位:
宿迁学院06计本(3)班软件开发2组
1.2可行性研究的前提
1.2.1要求
A.功能:
监护系统要随时接受每个病人的生理信号(脉搏、体温、血压、心电图等),定时记录病人情况以形成患者日志,当某个病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息;此外,护士在需要时还可以要求系统打印出某个病人的病情报告。
B.性能:
1、本系统要求反应时间不得低于2s.2、定期对数据库备份
C.输出如报告、文件或数据:
本系统要求输出的数据有:
查询信息、报表、警报控制信号。
D.在安全与保密方面的要求:
挂号科的工作人员负责病人基本信息的输入,住院部的医护人员负责病人住院日志的情况,管理员负责系统的维护。
1.2.2目标
本系统要求能够监护系统要随时接受每个病人的生理信号(脉搏、体温、血压、心电图等),定时记录病人情况以形成患者日志,当某个病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息;此外,护士在需要时还可以要求系统打印出某个病人的病情报告。
本软件系统要求安全、可靠(具有出错处理能力)、准确。
1.3对现有系统的分析
1.3.1系统流程图
图1-1系统流程图
1.3.2经费、投资方面的来源和限制
各种硬件和工作人员工资需至少10万元。
1.4技术可行性分析
1.4.1硬件、软件、运行环境和开发环境方面的条件和限制
软件需求:
操作系统WINDOWS2000AdvanceServer以上;数据库服务器端软件ORACLE9I,Delphi7.0。
硬件需求:
10M以上的LAN接入网络带宽,P43.0GXeonCPU/1G内存/360G(10K)SCSI硬盘的服务器,P3以上微机(带网卡)的客户机,P43.0GXeonCPU/1G内存/36G(10K)RAID硬盘的数据库。
1.4.2技术可行性评价
本系统采用Delphi实现,依靠其强大的控件系统,Oracle数据库管理系统和用C语音编制的传感器驱动相结合,能在2个月内开发出系统。
1.5经济可行性分析
医院目前由于完全采用纯人工的方式来完成工作的,医务人员要一边关注某些病人的情况,一边还要忙着对其它的病人进行医疗诊断,工作量大,耗时比较多,所以工作效率低。
根据目前医院内部员工的日人工成本为:
x人*y元/人=z元。
我们还不能计算出因效率低下而给医院带来的无形经济损失,如果指导这一部分也看作是成本,那将远远超出目前的计算数额。
而如果开发出一个能满足业务要求的医疗计算机监护系统,在采用生命周期的前提下,从问题识别到系统实施、评价、维护,开发周期如果以两年计,共需人工成本m元,各种软硬件成本n元,日常维护费用o元,共计成本费用p元,略高/低于两年的人工费用总和。
同样,我们也无法估计算出则于系统的开发应用使医院运营效率提高而带来的无形的巨额经济效益,由于系统能在未来较长的一段时间内稳定地发挥作用,这对于医院的提高管理水平很大的帮助,才能使医院早日接入到总行的更高层次的网络体系中,可以更加广泛的吸收各方面的信息资源,可为医院业务在将来的扩张打下坚实的基础,其经济效益将更上一层楼。
1.6法律可行性分析
由于在本系统中是有合同作为双方合作的基础,所以不会存在任何侵犯、妨碍和责任问题。
即使存在了,也可以根据合同进行分析,一定有人会负责任,所以此系统完全可以进行开发。
由以上经济、技术、操作和法律四方面的分析可以看出,本系统的开发时机成熟,从多种角度考虑,都是可行的。
1.7结论
本系统值得投资。
第二章需求分析
2.1引言
人员管理的合理化和经营化是医院经营效益的关键。
拥有了先进的技术还要有更加良好的管理体制,才可以让医院的经营效益发挥到最好的状态。
充分利用现代先进的技术,可以节约大量的人力资源和财力资源。
2.2功能描述
本软件主要有以下几方面的功能:
(1)数据接收处理:
通过连接在病人身上的传感器,根据传感器的值将生理信号(脉搏、体温、血压、呼吸、心电图)输入系统,并接收医护人员输入的对应病人基本信息并根据病人的实际情况确定病人的生理信号安全范围。
(2)监护管理:
进行超标判定,对超过设定安全范围的病人及时通知医护人员以及向病人家属发送短信通知。
(3)对病人档案的查询处理:
工作人员可以对病人的基本信息(病人姓名、病人性别、住址、联系电话、患病名称、入院日期、备注)进行删除和修改。
可以对这一段时间的病人病情进行查询,也可以对查询的病人病情打印出病情报告。
2.3数据流图
2.3.1数据流分析
数据流图是组织中信息运动的抽象,是管理信息系统逻辑模型的主要形式。
它可以综合的反映出信息在系统中的流动、处理和存储情况,具有良好的抽象性和概括性。
它在调查的基础上,从系统的科学性、管理的合理性、实际运行的可行性角度出发,将信息处理功能和彼此之间的联系自顶向下、逐层分解,从逻辑上精确地描述系统应具有的数据加工、数据输入、数据输出、数据存储及数据来源和去向(外部实体)等项目。
数据流程图和系统的物理描述无关,它所描述的内容不涉及技术细节,而是面向用户的,即使完全不懂信息技术的用户也容易理解。
因此,数据流图成为系统分析员与用户进行交流的有效手段,同时也成为系统设计的主要依据之一。
2.3.2需求概述
本系统由“数据接收处理”“监护管理”“对档案查询处理”三个功能模块组成。
(1)数据接收子系统包含四个功能模块:
“病人生理信号处理中心”、“时钟采样处理”、“病人基本信息处理”、“安全范围设定”
时钟采样处理子系统包括两个功能模块:
“设定时间”、“定时取样”。
安全范围设定子系统包括2个功能模块:
“分析病人病情”、“确定安全范围”。
(2)监护管理子系统包括“超标判定”、“危机情况处理”
超标判定模块包括超标判定操作。
危机处理子系统包含2个功能模块:
“通知医护人员”、“通知病人家属”。
(3)对档案查询处理子系统包含3个功能模块:
“修改”、“查询”、“删除”。
2.3.3具体数据流图(DFD)
1.分析获得的顶层图数据流图如下
本系统有三个源点四个汇点分别向中央系统传送数据和接收数据:
图2-1顶层数据流图
2.进一步划分的二层数据流图如下
中央系统主要由数据接收处理、监护管理、对档案查询处理三个加工处理、三个文件存储组成。
图2-2二层数据流图
3.对每一个功能模块的分解图
(1)对第一个模块“数据接收”的细分图
数据接收子系统包含四个功能模块:
“病人生理信号处理中心”、“时钟采样处理”、“病人基本信息处理”、“安全范围设定”
时钟采样处理子系统包括两个功能模块:
“设定时间”、“定时取样”。
安全范围设定子系统包括2个功能模块:
“分析病人病情”、“确定安全范围”。
图2-3“数据接收”模块的一层分解图
图2-3-2“数据接收”模块分解出的底层图
(2)对“监护管理”模块的分解
监护管理子系统包括“超标判定”、“危机情况处理”
超标判定模块包括超标判定操作,用来拿定时提取的病人生理信号与安全范围相比较看是否是正常状态。
危机处理子系统包含2个功能模块:
“通知医护人员”、“通知病人家属”。
图2-4-1“监护管理”模块一层分解图
图2-4-2“监护管理”模块的底层分解图
(3)对“对档案的查询处理”模块的分解
对档案查询处理子系统包含3个功能模块:
“修改”、“查询”、“删除”。
在删除操作之前需要向主治医师询问是否可以删除。
图2-5“对档案的查询处理”模块的分解图
4.总的底层数据流图
把细分图整合起来形成总的底层DFD:
图2-6底层数据流图
2.4数据词典
数据字典是各类数据描述的集合,它是进行详细的数据收集和数据分析后所获得的主要成果。
该系统的数据字典如下:
1.数据源点和终点描述
(1)名称:
病人
简要描述:
被监护的对象
有关数据流:
生理信号
(2)名称:
时钟
简要描述:
用来为系统提供时间日期数据以便定时取样生理信号
有关数据流:
时钟信号
(3)名称:
工作人员
简要描述:
负责系统数据的录入工作
有关数据流:
病人基本信息
(4)名称:
医护人员
简要描述:
监护系统终端的值班人员
有关数据流:
警告信息
(5)名称:
显示器
简要描述:
终端设备,用来显示病人的生理信号
有关数据流:
病人日志
(6)名称:
家属
简要描述:
病人的家属
有关数据流:
病情报告,病情报告短息
(7)名称:
查询者
简要描述:
主要由医护人员和病人家属组成,有权查询病人的病情报告并打印
有关数据流:
病情报告
2.加工词条描述
(1)加工名:
生理信号接收
加工编号:
1.1.1
输入数据流:
生理信号
输出数据流:
生理信号
加工逻辑:
接收病人的生理信号
(2)加工名:
生理信号分析
加工编号:
1.1.2
输入数据流:
生理信号
输出数据流:
生理信号值
加工逻辑:
分析病人的生理信号,转化为具体的数值
(3)加工名:
设定时间
加工编号:
1.2.1
输入数据流:
时钟信号
输出数据流:
时间间隔
加工逻辑:
为定时采样病人的生理信号设定时间间隔
(4)加工名:
定时采样
加工编号:
1.2.2
输入数据流:
时间间隔,生理信号值
输出数据流:
病人日志
加工逻辑:
定时取样病人的生理信号并存入病人日志
(5)加工名:
接收基本信息
加工编号:
1.3.1
输入数据流:
病人基本信息
输出数据流:
病人基本信息
加工逻辑:
接收由工作人员输入的病人的基本信息
(6)加工名:
记入档案
加工编号:
1.3.2
输入数据流:
病人基本信息
输出数据流:
病人基本信息
加工逻辑:
接收病人的生理信号
(7)加工名:
分析病人病情
加工编号:
1.4.1
输入数据流:
病人基本信息
输出数据流:
安全范围
加工逻辑:
由主治医生对病人的病历进行分析,产生分析结果
(8)加工名:
确定安全范围
加工编号:
1.4.2
输入数据流:
分析结果
输出数据流:
安全范围
加工逻辑:
根据医生对病人病情的分析,确定出一个适合病人的安全范围
(9)加工名:
超标判定
加工编号:
2.1
输入数据流:
生理信号值,安全范围
输出数据流:
警报
加工逻辑:
接收病人的生理信号值与安全范围做比较,判断是否超标
(10)加工名:
通知医护人员
加工编号:
2.2.1
输入数据流:
警报
输出数据流:
警告信息
加工逻辑:
接收警报并向终端发送警告信息
(11)加工名:
通知家属
加工编号:
2.2.2
输入数据流:
警告信息
输出数据流:
病情报告短息
加工逻辑:
接收警告信息并自动向病人家属发出病情报告短信
(12)加工名:
修改
加工编号:
3.1
输入数据流:
病人信息
输出数据流:
修改后的病人信息
加工逻辑:
可以对病人的病历等进行更新修改
(13)加工名:
查询
加工编号:
3.2.1
输入数据流:
病人信息
输出数据流:
病情报告
加工逻辑:
医生和家属可以根据病人的姓名等查询病人的基本信息并可以
请求打印报告
(14)加工名:
打印病情报告
加工编号:
3.2.2
输入数据流:
病情报告
输出数据流:
病情报告
加工逻辑