医院药品管理系统前景与范围文档
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天 |
|
人员 |
团队规模包括一个项目经理，十名开发人员，和两名测试人员
|
人员数目按照规定严格控制 |
如果计划不够，可以适当增加人员务必保证在规定时间内完成项目。 |
词汇表：
药品种类管理 药品上架请求 开出处方 处方状态
参考资料：
需求工程—软件建模与分析
需求工程文档规范
项目前景与范围文档模板