资源描述
药事管理系统的设计与实现
系统需求
在医院,药事管理一般分为药房管理、药库管理和采购管理等。其业务描述一般为:首先由药库制定采购计划,药品采购回来后,在药库进行有效期、库存量和价格等的管理。药房或其它科室向药库发送药品请领申请,药库接收后,会根据库存量按照一定的出库原则办理药品出库。药房领药后办理药房入库。药房接收从门诊传来的处方后,进行药品调配、核对,并引导病人在指定位置领取药品,完成药品根据处方发药的过程。
药房药库每月需要进行盘点,对药品与账面数进行校对,产生盘点单,保持实物账与账面账的一致。由于整个医院信息系统比较复杂,全盘分析药品在信息系统中的流转也不太现实,这里仅仅抽取药品采购、药房管理和药库管理等环节进行分析和处理,并有删减。
1. 企业主要组织机构
采购部门:负责与供应商谈判并采购药品;
库存部门:负责进货管理、退货管理等;
药房:负责药品的配送。
2. 系统业务情况
1〕采购药品
主要负责药品采购。先根据药房和药库递交的采购申请进行汇总,生成采购计划,确定需要采购的药品的种类和数量;并查询供货商的信息,确定采购对象,与供货商议定药品价格后签订购药合同。货到时,通知库存部门验收药品。
2〕库存管理
库存管理的基本流程是:首先对采购的药品进行验收、确认、入库登记。对不合格和不符合采购计划的药品进行退药处理。对药房和相关临床科室的领药申请进行处理。
3〕药房管理
药品进入药房库存后,每天可能接受到从各个科室和病人传来的取药申请,药房要根据这些申请查询存药进行配药处理,然后发往各个科室或病人手中。如果存库药品不够,则需要申请采购。
当药房有药品出现滞销、包装、质量、过期等问题时,药房可能向药库发送退药申请,假设申请理由符合规定,则由药库根据发药票据进行确认,然后进行退药处理。
3. 用户要求
1〕采购部门:
〔1〕信息要求:
供应商信息:包括供应商的单位信息、联系人信息等;
采购合同信息:包括每一次采购的采供货商、采购时间、采购药品、采购的价格、批号、
数量等;
药品信息:药品类别信息、药品的价格信息等。
〔2〕处理要求:
对供应商信息进行管理;
能根据不同药品对相关供应商进行查询、评价和分析;能按合同号、供应商、采购时间等对合同进行查询;建立药品参考价格表,由采购员通过市场调查进行维护;建立采购合同记录,为每个合同在进药合同表中记录一行。
2〕库存部门:
〔1〕信息要求:
规格、批号、生产日期、失效日期、药品类别等;
科室名称等;
库房名称等。
药品信息:记录药品名称、科室信息:记录科室编号、库房信息:记录库房编码、
〔2〕处理要求:录入或维护药品信息;能自动生成采购计划及采购单功能;
能随时查验任一药品的库存变化,入、出、存等明细信息;接收药房、科室领药单功能;
提供药品的核算功能,可统计分析各药房的消耗、库存;
提供药品的有效期管理、可自动预警和统计过期药品的品种数目及金额,并有库存量提示功能。
3〕药房部门:
〔1〕信息要求:
药房信息:需要记录药房编号、药房名称;
处方发货信息:需要记录某张处方在哪个药房发货,详细的发货内容;进药申请:记录申请药物的信息,数量等。
〔2〕处理要求:
可自动获取药品名称、规格、批号、生产厂家、药品来源、药品剂型、药品类别、领药人、开方医生和病人等基本信息;
提供对药品明细执行发药核对确认,消减库存的功能,并统计日处方量和各类别的处方量;
可自动生成药品进药计划申请单,并发往药库;
提供对药库发到本药房的药品的出库单进行入库确认;提供本药房药品的退药功能;
可随时查询某日和任意时间段的入库药品消耗,以及任意某一药品的入、出、存明细帐;支持对多个药房的管理。
4. 安全性与完整性要求
系统应满足实体完整性、参照完整性和用户自定义的完整性规则。对不同的用户赋予不同的权限,每个用户只能对有限的数据进行有限的操作。例如,供应商只能对他们自己供应的药品价格进行查询等,这里不再赘述。
5. 确定系统边界
基础数据的录入和更新由操作员联机完成,比如录入药品名称,药房名称、供应商名称等信息。对于实体的编码维护,比如商品编码、药房编号等,可以由系统产生,也可由操作员手工管理;一些统计数据,比如采购单总价格等,由系统产生;还有一些查询工作,比如对药品价格的查询,也可以由系统完成;各种报表的生成均由系统产生,如药库缺货登记表等。
6. 分析用户需求
在调查完用户需求后,就要开始分析用户需求。可以把上述医院药事管理大致划分为3个子系统:采购药品、药库管理和药房管理。并为每个子系统组成了开发小组。图1描述了该系统的第一层数据流图。
图1药事管理系统第一层数据流图
采购药品管理子系统开发小组的成员在经过调查研究、分析和数据收集后,明确了该子系统的主要处理功能是:对药房或临床科室提供的需求信息、供应商信息和市场药品信息进行分析,确定药品供应商和供应商签订购药合同,生成购药合同记录和订单;供应商根据订单安排发货,生成发货清单;收到药品时按照发货清单和进货合同对收到的药品进行核对,核对无误生成入库单,准备入库。图2是描述的采购药品管理子系统的数据流图。
图2采购药品管理子系统数据流图
生成入库单后由质检员对其进行验收,合格的药品生成进货入库单,存入药库;不合格的药品生成退货单。根据退货单去查找进药合同记录,确定需退掉的药品是由哪个供应商供货的,与其签订退货合同,生成退货合同和退货清单。药库管理子系统的数据流图如图3所示。
科室和药房向药库办理领药出库,药库出库实际上是从药库移药到各个科室和药房的过程。药房还可以对它们管理的药房中的闲置药、过期药、报废药等向药库提出退药申请;每次从药房中出库都需要核对药库药品实物数量和账面数量,形成相应的出库单,根据出库单的内容修改库存药品;此外,还有可能发生在两个药房之间的药品转库业务,全院药品存货核算盘点等功能都可以考虑在需求中一并实现。
药房管理子系统的功能如图4所示。主要描述药房向科室和病人发药的过程。药房也可以对一些药品作退药处理。
图4药房管理子系统数据流图
将所有用户需求分析完成后,就要开始构造数据字典了。以采购药品管理子系统的数据
宇典为例,
如下各表所示。其它数据子典小冉赘述。
表1
数据结构定义
数据结构编号
数据结构名
含义说明
组成
1
供货商信息
记录供应商信息
供应商代码
、名称、地址、 、 、Email、联系人
2
药品信息
记录药品信息
药品代码、
药品名称、拼音简码、剂型、规格、单位、批号、
生产日期、
失效日期、药品类别
3
药房
记录药房信息
药房代码、
药房名称
4
药库
记录药库信息
药库代码、
药库地址
确定了数据结构后,就可以对每个数据结构的数据项进行具体定义。上述数据结构的数据项分别在下表进行定义。
数据项编号
数据项名称
含义说明
别名
数据类型
长度
1
药房代码
药房的唯一标识
Storecode
字符型
2
表2药房的数据项定义
取值范围
-99
2
药房名称
药房的名称
Storename
字符型
10
汉字
表3药库的数据项定义
数据项编号
数据项名称
含义说明
别名
数据类型
长度
取值范围
1
药库代码
药库的唯一标识
Warehousecode
字符型
2
-99
2
药库地址
药库的名称
Warehousename
字符型
10
汉字
表4供应商信息的数据项定义
数据项编号
数据项名称
含义说明
别名
数据类型
长度
取值范围
1
供应商代码
供应商单位的唯一标志
ProviderCode
字符型
4
01-9999
2
供应商全称
记录供应商的全称
ProviderName
字符型
60
汉字符号
3
地址
供应商单位地址
Address
字符型
50
汉字符号
4
联系
联系人的联系
Tel
字符型
15
数字符号
5
供应商邮政编码
Zip
字符型
6
数字符号
6
Email
供应商的Email
Email
字符型
30
字母数字组合
7
联系人
供应商联系人
Relation
字符型
7
汉字符号
表5药品信息的数据项定义
数据项编号
数据项名称
含义说明
别名
数据类型
长度
取值范围
1
药品代码
药品的唯一标志
MedicineCode
字符型
5
数字符号
2
药品名称
记录药品的全称
MedicineName
可变字符型
50
汉字符号
3
拼音简码
记录药品的单价
PyCode
字符型
10
字母组合
4
剂型
记录药品的剂型
DosageForm
字符型
6
5
规格
记录药品的规格
Standard
字符型
15
6
单位
记录药品的单位
Unit
字符型
10
7
批号
记录药品的批号
BatchNumber
字符型
20
8
生产日期
记录药品的生产日期
ProductionDate
日期型
9
失效日期
记录药品的失效日期
ExpirationDate
日期型
10
药品类别
记录药品的药品类别
category
字符型
10
中成药、西药等
系统概念模型设计
系统概念设计阶段的要求是通过对用户需求进行综合、归纳和抽象,形成一个独立于数据库逻辑结构、独立于DBMS的概念模型。
这里以E-R图来描绘概念设计模型。采购药品管理子系统所涉及的数据结构基本上已经收入数据字典了,接下来需要从数据字典中抽取相关数据、参考数据流图,设计局部应用中需要的实体、属性和实体之间的联系以及联系的属性。为提取需存入数据库中的数据来构成概念模型。参照图2可以在Powerdesigner中如图5所示设计采购药品管理子系统的E-R图。
图中有四个实体:药库、药品、药房和供应商。
有三个多对多联系:药库与药品之间的药库采购联系、药房与药品之间的药房采购联系
和药品与供应商之间的购药合同联系。
图6药库管理子系统E-R图
成检
Imps 匚七工匚 I. N.J 《盼
Ins pec torUaim Chara.-: ters〔8)
Ins pec torCodje 〈pi〉
Ware ho n= e c de
0_. n
0.. n
ffarehon= cc:-de Chirac ters (2) 〈黔
ffar e ho ns e imnK C hnr ac ters 1.10)
图6是根据药库管理子系统的数据流图而设计的子E-R图,图中有六个实体:药库、药品、供应商、质检员、药房、科室。有五个多对多联系:质检员与药品之间检验联系、供应商与药品之间的退药联系、药品与药库之间的存库联系。科室领药联系涉及的实体有药品、科室、药库,因而需要加入Association 〔关联〕工具,药房领药联系也一样。图7所示的是药房管理子系统的E-R图。
图7 药房管理子系统E-R图
各个子系统的分E-R图完成后,接下来的工作是将其合成一个全局的E-R图。遵循概念设计的原则,医院药事管理的总体概念E-R图如图8所示。在图中,为了较为清晰现实整个结构,忽略了各个属性的显示。
图8总体E-R图
系统逻辑设计
逻辑结构分两部进行:一是按照E-R图向数据模型的转换原则,将概念结构转换成DBMS所支持的数据模型;二是对数据模型进行优化,优化的原则是所有模式都需要符合第三范式。这里,可以使用Powerdesigner的工具直接转换成逻辑模型,转换结果如图9所示。同样,为了清晰起见,忽略了属性的显示。
数据库物理设计
以图9为基础,可以在逻辑模式中加入或者修改合适的属性内容,比如,对联系所生成的“实体,,中编辑联系的属性。然后保存,利用Powerdesigner工具生成物理结构,如图10所示。接下来可以进行数据库的实施和维护。
二hrr I.S〕 ::pk,
char ⑵ fljD
dat«tinK
Waruhmwndu 二har I.NJ
Bsdl二 L 二 11HT~ I.S..I 《pk, fit].::,
Ti^mini int
蜥合同
料宣轲笏
char I.dj Gk. flj"
匚bar I.5J <pL- £h2r:'
char l.d.〕
datetintt
int
CorrTpic tCode
ClteLte
Cnum
D±rnr tmtntCod亡
WaTEh&nsouodjs
BEfflimni
FatientlFame
Sex
ER1
Ba-lrecc
供应商
char I.dj
charIbO)
char 1.50)
char 115)
char lb)
char 1.30)
rlinr (T'l
Frni.ridwCo 云
PruTridcrliaiDt
A<l<ire==
Tel
2ip
Email
R* 1K + 1CF
科室中轲
De pax tmtntEls 匚 bar ⑵ <pL fLl:>
lESmini
瓦 L二 imGn L
IJjaH
QH3.1 1 fy
药座来购
Wiar 己 h・。,ns <± 匚 sit
压 J.1匚in 此 od
ffEzn-nni
lYBiite
Ms J. L 二 in An L 匚扁「I.S] fpk
Frmridr&L 匚hv l.<1〕 <pk,成匚,
Itate dntetinn
num int
匚Ear 1.2〕 〈:pkj fkD
uh nr I.SJ Ipk.’
int
da.tetinn
Stor已code
瓦 diu inelode
SKinnni
SHtate
瓦di匚inuCodu
War ehoTu o,二 o j巳
Etorocodje
E^Snuni
到品存成
Storecodje 匚hv I.W〕《.pL flcZ)
正3.1匚血<±命1± cliar ⑸ 〈uik, flrl》
Snum int
料窒
IL par tmtntlLn,』巳 ulinr l:ZJ
Itimr tmtntliame char (10)
胃五已h。匹己匚日己 匚hur⑵
胃ar;L? u= oname clinr 1.10)
质密后.
1匹±匚七匚匚日已匚h;ir⑵
Inspectc-rNaim chai 1.3)
匚bar I.W.]
S tort name clar 1.10)
Bs匚 inut 土
Ht-iic mtffanw
PyCode
处方机笏
Ktdicin±Cod±
匚hnr⑸
:-.pk- fl£l>
Storwodje
匚]lar
Pat lent Co-it
uIikt- |:4)
•g皿)
note
i.narchar (50)
dose
clnr 1.10)
病人
Fat lentC :it
cliwr (4 ]
FatientlFame
char 160)
Sex
char 1.2)
FT-1
char 1.15)
Ba-lrecc
i.narchar (60)
图10药事管理系统物理结构
该文档没有完成的部分如下表。
请大家对物理设计中的如下部分进行说明!
当然,视图、触发器、存储过程的设计不是偶然,需要在需求分析的时候有某些需求,比如上面文档红色部分,可以考虑使用如上技术。可以根据需求分析部分的用户设计设计不同用户。
每个表需要列出表上的函数依赖,一般需要每个表满足3NF
序号
模型对象
含义
要求
1
Table
表
>=8
2
Column
列
3
Primary key
主键
有
4
Alternate key
候选键
有
5
Foreign key
外键
有
6
Index
索引
>=5
7
Default
缺省值
>=3
8
Domain
域
有
10
View
视图
>=5
11
Trigger
触发器
>=5
12
Stored Procedure
存储过程
>=5
13
Database
数据库
1
14
User
用户
>=3
15
Role
角色
>=3
16
group
组
>=1
展开阅读全文