医院药品管理系统前景与范围文档
1. 业务需求
1.1 应用背景
我国的人口基数大,医疗卫生资源不足,服务水平也和发达国家有不小的差距。但是卫生事业本身就是重要的行业,近年来得到了国家的重视和支持,越来越多的医院向着全科性综合医院发展。随着职工人数药品种类的不断增加,医院规模越开越大,各个机构也就更加分散了,这就加大了医院的运作难度,更增加了管理的成本。为了提高医院的管理效率,并且降低管理成本,更好的为广大人民服务。我们可以运用一些高科技设备对医院进行信息化的改造。
医院信息化系统是一项系统工程包括了很多子系统,不是在短期可以完成的。因此医院药品管理的建设,就是以药品作为切入点就行医院整体信息化的建设。医院药品管理系统可以系统的对药品进行统一的进、存、销管理,给医务人员以及药品管理员提供一个统一的操作平台,可以降低医院运作难度,降低管理成本,提高医院的服务质量,更好的为社会服务。
1.2 业务机遇
2007年,卫生部在《我国医院信息化的现状与发展策略》一文中指出了医院信息化所面临的问题以及发展的方向。就在十年前我国医院的管理和运营完全是依靠人工进行的,近些年一些配备高科技设备的科室已经进行了信息化的改造,这些科室在提高效率、信息共享上已初见成效。但是,仍有大部分科室是传统的模式,一些药品仓库,就医流程也只有半信息化,一些落后的地方甚至是全手工的。医院中的有的科室自成一体,彼此之间缺乏信息的沟通,办事效率低更需要进行信息化,便于统一的管理,提高效率,更好的服务于人民。
1.3 业务目标
医院药品管理系统主要设计目标是:
BO-1:提供易用的用户界面:界面采用Ajax技术实现的web2.0,页面简洁美观,通过系统的流浪器可以直接访问。
BO-2:提供整合医院各机构和规范药品流程的统一平台能力:药品的进出有规范的流程,各个机构都能通过本系统参与。
BO-3:提供强大的开发能力:方便进行功能的扩展和扩充,为整个信息化的建设提供支持。
BO-4:提供强的的自身管理能力:面向各个用户的操作提供不同权限的管理
提供完善的监控和统计分析能力:对仓库的药品进行随时的监控,可以监控 药品从下单到售出的整个过程,并且可以进行汇总统计。
BO-5:提供强大的扩容能力:采用标准的分布式组件技术实现7x24小时运行,确保系统可以稳定的实现在线升级。
1.4 业务风险
RI-1:一些医院原有的系统还可以维持医院的正常管理,医院不愿意为新系统投资更多的钱。
RI-2:正在开发的或者已存在的同类软件已经使用了一段时间了,不易在这些医院推广。
2 项目前景
2.1 前景概述
随着我们医疗事业的发展,医院向着大型综合化的方向发展。现代的医院不再是单一的机构,还包括了分散在城市的专科门诊,以及多个住院部和研究机构。作为医院核心的药品管理,就显得尤为重要。在一些中心药房,还有分散的门诊药房,以及住院药房很需要这样的药品管理系统。过去的人工管理不仅费时费力,效率还低,所以医院迫切需要一种统一的能够整合各种资源的药品管理系统。
2.2主要特性
FE-1:药品种类管理:对药品的种类可以进行新增、删除、修改、查询等操作。
FE-2:药品进出受理:仓库管理员可以对验收后的样品进行入库,提交入库单,修改药品的库存量,还可以响应门诊住院药房提出的上架请求,根据库存水平接受请求或者驳回
FE-3:药品上架:药房人员根据本药房的水平向药品仓库发出上架的请求。
FE-4:门诊药房售药:按照医生开出的处方,进行配药然后销售给病人,并修改药品数量和处方状态
FE-5:住院药房售药:根据医生开出的处方,先收钱,然后定期的修改药品数量和处方状态
FE-6:处方管理:医生可以查询药品情况,通过鼠标选择开出处方,也可以查询处方的状态
FE-7:操作员日志查询:查询操作员过去的操作
FE-8:用户资料变更:修改操作员本人的信息,以及密码的修改
2.3 假设与依赖
AS-1:医院有信息管理中心,并且计算机等相应的相关设备。
AS-2:医院有仓库管理人员对药品进行进、存、销的管理。
AS-3:系统的维护时间应该在一周之内,并且尽量在晚上人员操作较少的时间。
AS-4:系统管理员经过了一定的法律及技能培训,防止出现管理员对病人的信息盗用的非法操作。
DE-1:如果医院有原来的药品管理系统,那么此系统必须能够很好地替换了原来的系统。
3. 项目范围
3.1 第一版范围
第一个版本主要实现在医院的设备上能够稳定的运行,各个功能的初步实现。药品种类的管理可以进行新增、删除、修改、查询等的基本操作。药品的进出受理可以完全完成,根据医生开出的处方进行配药销售给病人,并立即修改药品数量和处方状态。各种权限的设置,不同的操作员拥有不同的权限。
3.2 后续版本范围
特性 |
版本1 |
版本2 |
版本3 |
FE-1 |
完全实现 |
|
|
FE-2 |
入库,提交入库单,修改库存量 |
完成其他所有功能 |
|
FE-3 |
完全实现 |
|
|
FE-4 |
根据医生处方配药销售给病人 |
修改药品数量,处方状态 |
|
FE-5 |
根据药房收钱 |
定期更改药品数量 |
完全实现 |
FE-6 |
医生查询药品情况 |
医生可以用鼠标开处方 |
完全实现 |
FE-7 |
完全实现 |
|
|
FE-8 |
完全实现 |
|
|
4. 项目环境
4.1 操作环境
这个系统主要提供给两类的用户使用,一类是医生,一类是药品管理人员。
- 医生使用模式中,医生可以开处方,查询处方状态,查询药品库存量。每次药品有变化就要相应的更新数据库。面向医生时,系统是普通的存储数据软件。
- 面向药品管理人员时,管理人员可以对药品进行新增、删除淘汰的药品、修改药品状态、查询药品信息。
4.2 涉众
这个系统中的主要涉众如下表:
涉众 |
特点 |
医生 |
医生可以通过这个系统用鼠标进行开处方,查询处方状态,查询药品信息,提高效率。 |
药品管理员 |
药品管理人员可以通过系统完成对药品的所有操作,可以实现与医生的沟通,减少了药品管理人员的工作量,提高了办事效率。 |
4.3 项目属性
具体项目属性如下表:
属性 |
驱动因素 |
约束因素 |
可调整因素 |
特性 |
|
各个版本的功能必须完全可操作。 |
在最终版本中进行调整。 |
质量 |
|
用户满意度必须达到85%;必须通过全部的安全机制检查,系统能够在win7,winxp等操作系统下稳定工作。 |
在后续版本中完善功能 |
成本 |
项目经理 |
必须控制开发费用在额定范围内 |
允许费用超过的最大额度不超过总经费的10% |
进度 |
项目经理 |
必须保证开发时间在规定时限范围内 |
开发时间最长不得超过规定时间2天 |
人员 |
团队规模包括一个项目经理,十名开发人员,和两名测试人员
|
人员数目按照规定严格控制 |
如果计划不够,可以适当增加人员务必保证在规定时间内完成项目。 |
词汇表:
药品种类管理 药品上架请求 开出处方 处方状态
参考资料:
需求工程—软件建模与分析
需求工程文档规范
项目前景与范围文档模板