药品系统规格需求说明书.docx
《药品系统规格需求说明书.docx》由会员分享，可在线阅读，更多相关《药品系统规格需求说明书.docx（15页珍藏版）》请在冰点文库上搜索。
药品系统规格需求说明书
案卷号
日期
天健药品系统
软件需求说明书
作者：
杜永华
完成日期：
签收人：
签收日期：
修改情况记录：
版本号
修改批准人
修改人
安装日期
签收人
2项目概述2
1引言
1.1编写目的
管好药品才能更好的为患者服务、清晰准确的进行效益结算打下最基本的数据基础。
1
1.1
1.2范围
软件名称
药品管理系统；
能干什么
改进、完善药品管理关系，提高天健系统在市场的竞争力；
描述
药品是医疗机构与患者共同关心的事情，希望通过一个良好的数据管理系统让患者能清楚的了解到目标医疗机构的药品供应情况；让医疗机构准确的掌握药品物资供应链供应、药品储备、采购计划、内部流转、患者交付等关系，以期进行准确的核算、结算工作。
1.3定义
DMS：
药品管理系统（Drugmanagementsystem）。
1.4参考资料
参考天健医院信息系统之药品管理程序
2项目概述
2
2.1产品描述
它是一项综合的IT技术，也是一种新的运作模式，它源于“以客户为中心”的新型商业模式，是一种旨在改善企业与客户关系的新型管理机制。
是一项企业经营战略，企业据此赢得客户，并且留住客户，让客户满意。
通过技术手段增强客户关系，并进而创造价值，最终提高利润增长的上限和底线，是客户关系管理的焦点问题。
当然CRM系统是否能够真正发挥其应用的功效，还取决于企业是否真正理解了"以客户为中心"的CRM理念，这一理念是否贯彻到了企业的业务流程中，是否真正提高了用户满意度等等。
2.2产品功能
一个相对独立但是可与其它姊妹系统联动的进销存，可以清晰准确的描述药品的流转关系及当前状态，提供药品数据及相关历史数据的增、删、改、查的基本操作功能。
2.3用户特点
有一定相关工作基础者稍加培训即可胜任；维护/培训人员需要具体软件相关行业知识；
2.4一般约束
本条对设计系统时限制开发者选择的其他一些项作一般性描述。
而这些项将限定开发者在设计系统时的任选项：
1.
2.
2.1.
2.2.
2.3.
2.4.
2.4.1.管理方针
1.业务选型以普遍业务为基础，可以通行于行业内至少三家医院相关业务；
2.为便于日后系统扩容所有关键字引用分为表示层和应用层，数据内部引用为应用层，该层数据应该尽量以INT类型为准，只表示数据的存在不涉及数据意义解释；
3.数据精度应该维持在5位小数点，系统中禁止使用double、decimal类型，相关数据类型应该统一转换为float；
3.1.
3.2.
3.3.
3.4.
3.4.1.
2.4.2.硬件的限制
硬件
数据库服务器
应用服务器
CPU
>=至强E5-2600双核*2
>=至强E5-2600双核*2
MEMORY
>=16G
>=8G
H·D
>=125G*3
>=125G
D·H·R
Y
N
D·A·C
Y
三甲及三甲特大型医院必须采用至少rd0，其它级别医院视情况定
2.4.3.与其他应用间的接口
JSON
2.4.4.所需的高级语言
C#
2.4.5.通信协议
HTTP
2.4.6.安全和保密方面的考虑
1.存储及传输过程中用户帐号和密码不得应用明文，需以des及md5分别对帐号和口令加密存储/传输；
2.系统访问权限受部门及职务限制；
1
2
2.1
2.2
2.3
2.4
2.5假设和依据
1.从技术层面本系统应该可以适应市场较长时间，以现有软、硬件及网络条件预测良好情况主要指后端技术方向不需要做调整，但是前端业务表现应该需要根据实际技术发展做出与俱进的改进，以增强产品的市场竞争力；
2.从架构层面当系统完全完成，并且是严格遵守设计规范所进行的，小型需求从实现（包含测试）到完成应用的计时单位应该可以控制1周以内；
3.从实施准备到上线过程开发人员基本可以保持与市场销售及实施人员同步进行，不拖或少拖后腿；
3具体需求
3.1功能需求
1.
2.
3.
3.1.
3.1.1.系统自动值守模块
负责完成药库的采购计划自动生成、库存警戒预警、仓储温度/湿度预警、停药自动处理等无人值守事情。
3.1.2.中心药库
1.
2.
3.
3.1.
3.1.1.
3.1.2.
3.1.2.1.系统设置
1.医院机构代码设置
为自产药品的生产入库使用
2.允许根据库存自动生成采购计划；
只有两个选项：
是、否。
如果本项设置为是，则系统将会根据库存自动生成采购计划并且该计划自动进入审核等后续流程，采购计划的发起者为本项设置的最后修改者；
3.温度、湿度控制参数设置
数据CRUD；
3.1.2.2.药品供应管理
1、国家字典
数据CRUD，被行政区划字典引用时不可以删除；
2、行政区划字典
数据CRUD，被生产厂商字典引用时不可以删除；
3、生产厂商字典
数据CRUD，被药品字典基本信息引用时不可以删除
4、供货商字典
数据CRUD，被采购申请单或入库单引用时不可以删除；如果医院自行生产药品，则应该将该医院也列出本字典。
5、停止供药管理
针对部分因某种原因不再继续出现在医院药品供应序列中的药品信息管理。
停药时如果药品尚有库存
6、采购申请
1.根据库存下限自动生成采购计划；
2.根据药品规格信息生成采购计划；
3.手工根据需要生成采购计划；
7、采购申请审批
1.根据采购计划，对数据进行逐项核对，允许修改采购计划中的药品生产、供应商、规格、数量（数量为零的表示不采购，审批不可删除采购明细数据）、价格；
2.审批过程中允许使采购单进入采购（即，执行采购过程）；
3.使采购明细全部进入招标；
4.使采购明细部分进入招标；
8、采购申请执行
对应实际采购行为，修改未招聘已经审核的数据使之成为有效的可入库数据并且依据该数据通知仓库管理员入库。
9、药品招标管理
1.公布招标单；
根据招标计划列出所有已经计划招标尚未公布的数据清单，供操作者有选择性的公开招标计划，被公开的招标计划可以根据用户方的信息约束要求呈现在招标网站或以文本形式被打印，未完成的招标信息可以被多次查询、打印；
2.录入中标明细
即，招标完成，完成后的标书不可以被打印但是可以被查询；
3.作废招标计划；
即，招标完成，完成后的标书不可以被打印但是可以被查询；
3.1.2.3.仓储管理
1.仓库字典
数据CRUD，被货位等其它数据引用后不可以删除；
2.货位字典
数据CRUD，被货位药品规格关系引用后不可以删除；
3.货位药品规格关系管理
数据CRUD，无特殊约束；
4.仓库警戒上下限管理
数据CRUD，以药品规格为基本数据的数据管理要素
5.仓储温度、湿度警戒线管理
数据CRUD，需要相关硬件设备支持
3.1.2.4.药品管理
1.药品基本信息
数据CRUD，被药品规格引用后不可删除，该数据必须通过药品规格信息在系统使用；
2.药品毒理分类
数据CRUD，被药品基本信息引用后不可删除；
3.药品剂型
数据CRUD，被药品基本信息引用后不可删除；
4.药品分类
数据CRUD,被药品基本信息引用后不可删除；
5.药品包装单位
数据CRUD，被药品规格引用后不可删除；
6.药品使用方式管理
数据CRUD，被药品规格引用后不可删除
7.药品规格信息
数据CRUD，被系统启用后不可删除；
8.药品可拆分性管理
依附药品规格存在
3.1.2.5.出库管理
1.调拨出库
数据CRUD，
调拨出库有两种:
主动调拨；被动调拨
主动调拨：
为流程性的，在业务进行过程中有基础药品入库后，由仓库主动向各药房配送；移库也是通过本模块完成；
被动调拨：
由药房或其它药库发起的配货行为；
2.盘亏出库
盘点亏损
3.报损出库
一般指因保管不善导致药品失效、毁损的出库行为；
3.1.2.6.入库管理
1.采购入库
依据采购计划生成的入库行为；
2.调拨入库
依据调拨申请单生成的入库行为,依赖于调拨出库单，如有调拨出库行为软件界面应有相关数据的实时提示；
3.生产入库
医院自产药品入库；药品的生产、供应商必须为医院本身；
4.盘盈入库
将盘点盈余的数据入库
3.1.2.7.退库管理
1.药品退药入库
医院内部仓储间的药品退回入库；
2.药品退回经销商
为了集中统一管理，只有中心药库可以将药品退回经销商，所有需要退回经销商的药品必须由各分仓储中心先逐级将药品退回，最后由中心仓库集中处理；
3.1.2.8.价格管理
1.药品价格类别
价格形成的原因描述
2.药品价格管理
药品价格的初次启用录入及后续调价管理模块，该模块直接经过审核流程后将非首次录入价格直接形成日志。
价格管理的日志由三部分数据构成：
1.正在使用的数据；2.将来使用的数据；3历史曾经使用但是当前已经停止使用的数据。
3.药品价格审核
药品价格变动后的事后监督模块。
本模块允许修改数据；
4.药品价格执行
按药品价格管理中预定义的已经过审核的数据做启用/停用操作。
同一种规格的药品可以同时存在多种价格，但是同一进货时间的同一种规格药品只允许使用一种价格
3.1.2.9.统计查询
1.采购申请单统计查询；
2.招标单统计查询
3.调拨入库单统计查询；
4.调拨出库单统计查询；
5.生产入库单统计查询；
6.盘点统计查询；
7.报损统计查询
8.药品出库统计查询；
9.药品退库统计查询；
10.药品退回经销商统计查询；
11.调价日志统计查询；
3.1.3.药房
3.1.3.1.仓储管理
1.仓库字典
参见中心药库
2.货位字典
参见中心药库
3.货位药品规格关系管理
参见中心药库
4.仓库警戒上下限管理
参见中心药库
5.仓储温度、湿度警戒线管理
参见中心药库
3.1.3.2.出库管理
1.调拨出库
药房间只有被动调拨，且药房无移库的概念；
2.盘亏出库
参见中心药库
3.报损出库
参见中心药库
4.发药出库
结合结算系统将药品销售给患者的过程
3.1.3.3.入库管理
1.调拨申请
向目标仓储发起调货请求，同一医院内除科室之外，可以平级或下级向上级仓储机构发起调货请求；科室间不能发起调货请求，科室只能向药房发起调货请求；
2.调拨入库
参见中心药库
3.盘赢入库
参见中心药库
3.1.3.4.退库管理
1.退回药库
将药品退回调拨来的药库，若该药库因为某种原因停止使用，则首选将药品退回历史来源药库的接替仓库，允许人工干预接受退药的目标仓库的选择；
2.科室退药入库
3.患者退药入库
3.1.3.5.统计查询
1.调拨入库单统计查询；
2.调拨出库单统计查询；
3.盘点统计查询；
4.报损统计查询
5.药品退库统计查询；
6.调价日志统计查询；
3.1.4.科室
3.1.4.1.出库管理
1.盘亏出库
参见中心药库
2.报损出库
参见中心药库
3.发药出库
结合结算中心将药品销售给患者
3.1.4.2.入库管理
1.调拨申请
参见药房
2.调拨入库
参见药房
3.盘赢入库
参见药房
3.1.4.3.退库管理
1.退回药房
3.1.4.4.统计查询
1.调拨入库单统计查询；
2.调拨出库单统计查询；
3.盘点统计查询；
4.报损统计查询
5.药品退回药房统计查询；
6.调价日志统计查询；
3.1.5.配药中心
1.收药；
依据药嘱接受患者临时寄存以便后续治疗的药品管理模块
2.发药；
1的对应模块
3.2外部接口需求
3.2.1用户接口
1．UI为自适应，屏幕分辨率不小于1024*768；
2．报表支持XLS格式输出；
3．系统操作响应最大时间应该限制在2秒以内；
4．操作应该符合键鼠脱离原则，即，可以键盘完成的就不硬性要求使用鼠标，但是允许使用鼠标；可以用鼠标完成就应该避免键盘的使用；
3.2.2硬件接口
系统支持无线或符合标准工业接口的温度、湿度仪及相关的条码、射频设备；
3.2.3软件接口
系统仅支持JSON格式：
[ver:
XXX;…………]
3.2.4通信接口
支持http/udp/tcp三种协议
3.3性能需求
1．从服务性能看，每服务器应支持至少700用户并发；
2．局域网中每用户的服务响应时间应该在2秒范围内；
3．局域网带宽应该>=1000M；
3.4设计约束
受国家相关医疗行业政策及物流政策限制
3.4.1其他标准的约束
1.报表系统格式仅支持水晶报表；
2.报表输出格式参见水晶报表相关文档；
3.系统命名遵从匈牙利命名法；
升级会员 