Node.js医保药品集中采购系统
摘 要
为“解决看病贵,吃药贵”的问题,找出药品流通环节,地区供价差异,顺加作价机制不合理,合同不规范执行,药品市场缺乏竞争等问题原因。完善药品集中采购制度。主要是为了加强药品质量区别,实现网上充分竞价。开展采取带量采购方式进一步降低药品价格,进一步深化药品价格形成机制。
本文主要通过对医保药品集中采购系统的功能性需求分析,对系统的安全性和可扩展性进行了非功能性需求分析。在详细的需求分析的基础上,根据系统的功能设计确定了数据库结构,实现完整的代码编写。医保药品集中采购系统完成了主要模块的页面设计和功能实现。本文展示了首页页面的实现效果图,并通过代码和页面介绍了用户注册功能、药品资讯、采购招标、企业投标管理的实现过程。
关键词:医保药品集中采购;Node.js;数据库
Node. JS medical insurance drug centralized purchase system
Abstract
In order to "solve the problem of" expensive medical treatment and expensive medicine ", find out the causes of drug circulation links, regional supply price differences, unreasonable price adjustment mechanism, non-standard implementation of contracts, lack of competition in the drug market and so on. Improve the centralized drug procurement system. It is mainly to strengthen the differentiation of drug quality and realize full online bidding. We will carry out procurement by volume, further reduce drug prices and further deepen the drug price formation mechanism.
This paper mainly analyzes the functional requirements of the centralized medical insurance drug procurement system, and analyzes the non functional requirements of the security and scalability of the system. Based on the detailed demand analysis, the database structure is determined according to the functional design of the system to realize the complete coding. The centralized medical insurance drug purchase system has completed the page design and function realization of the main modules. This paper shows the implementation effect of the home page, and introduces the implementation process of user registration function, drug information, procurement bidding and enterprise bidding management through code and page.
Key words: Centralized purchase of Medicare drugs; Node. js;database
目 录
自2009年深化医药卫生体制改革以来,药品在医疗费用中所占比重持续降低,次均门诊药品费用和人均住院药品费用占医药费用的比例分别自2009年的51.5%和43.6%降至2016年的45.5%和34.6%,但同时次均门诊药品费用和人均住院药品费用的总数依旧是持续攀升,分别自2009年78.3元和2480.6元增加至2016年114.6元和2977.5元,且我国药品费用占医药费用的比例仍远高于发达国家的比例(10%左右),药品价格虚高和虚低并存情况明显,药品集中采购制度不够完善是产生此现象的重要因素。
我国药品集中采购制度的全面试点始于2000年,原卫生部等5部委要求各省(区、市)要抓好2~3个药品集中招标采购工作试点。经过十多年的试点完善,2015年国务院办公厅印发《关于完善公立医院药品集中采购工作的指导意见》(以下简称《指导意见》),标志着该项制度已基本建立,《指导意见》明确以省(市、区)为单位的网上药品集中采购方向,并将药品分为五类,分别采取不同的采购方式:对临床用量大、采购金额高、多家企业生产的基本药物和非专利药品实行双信封公开招标采购,对部分专利药品、独家生产药品,以谈判方式采购,对临床必需、用量小、市场供应短缺的药品实行议价采购,对妇儿专科非专利药品、急(抢)救药品、基础输液、临床用量小的药品有医院集中挂网采购,其他相关药品按国家现行规定采购。
在医保药品集中采购中,参与主体有药品生产企业、公立医疗机构、第三方平台机构、药品经营企业,其中药品第三方平台机构不直接参与药品集中采购,对医保药品价格的形成没有产生影响。以竞价品种为例,医保药品价格形成过程为:药品生产企业自主定价,并参与省第三方药品交易平台招标采购,中标后,中标企业发出药品订单以确定具体的采购品种和数量,按中标价格采购药品。药品生产企业、经营企业、医疗结构签订药品购销协议,按中标价格买卖药品,医疗机构根据每宗交易成交价格计算出成交品种的临时零售价格卖给消费者。药品取消加成后,中标价格等于零售价格。
- 研究内容
基于Node.js的医保药品集中采购系统的开发及实现,所需要的工作内容:
(1)首先是确定选题,确定好所要做的系统,并对系统的背景及现在面临的一些问题等进行系统的初步确认。
(2)系统确认完成后,结合系统开发的需求进行确认系统开发所使用的技术医保药品集中采购系统的开发使用Koa框架,数据库进行系统的搭建开发,确认好使用的技术进行技术分析,所使用的技术是否可以完成系统的实现。
(3)确定好系统使用的技术,进行在线确认系统所划分的用户角色,并且根据用户角色划分确定所要设计的功能模块,对于医保药品集中采购系统的设计主要划分别为管理员和用户角色,并所使用的功能模块也相应不同,但是系统的数据库实现的内容是交互的,用户可以随时根据自己的需求进行信息查询,对于系统工作人员可以根据自己的分管内容进行在线信息的处理及操作,管理员获取到所有用户的详细数据信息,并根据需求进行第一时间处理解决。
(4)系统的功能模块确认完成后进行程序及界面的设计,设计完成后,并且通过测试来判断程序是否完善,对于系统测试,需要不同的用户进行不同的内容编辑及提交,及使用不同的测试方式找出程序中存在的漏洞,并对程序出现的漏洞问题进行在线解决处理,如果测试系统没有任何问题时,可以将系统上传进行正式操作使用。
2.1koa框架
Node.js是一个异步的世界,官方API支持的都是callback形式的异步编程模型,这会带来许多问题,例如:1、callback嵌套问题;2、异步函数中可能同步调用callback返回数据,带来不一致性。为了解决以上问题Koa出现了。
koa是由Express原班人马打造的,致力于成为一个更小、更富有表现力、更健壮的Web框架。使用koa编写web应用,可以免除重复繁琐的回调函数嵌套,并极大地提升错误处理的效率。koa不在内核方法中绑定任何中间件,它仅仅提供了一个轻量优雅的函数库,使得编写Web应用变得得心应手。开发思路和express差不多,最大的特点就是可以避免异步嵌套。
阿里内部就在使用Koa框架,并在Koa基础上面做了一些扩展和封装。并且基于koa开发了一个开源框架egg。
Vue.js是一套构建用户界面的渐进式框架。与其他重量级框架不同的是,Vue采用自底向上增量开发的设计。Vue 的核心库只关注视图层,并且非常容易学习,非常容易与其它库或已有项目整合。另一方面,Vue 完全有能力驱动采用单文件组件和Vue生态系统支持的库开发的复杂单页应用。
Vue.js 的目标是通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件。
Vue.js 自身不是一个全能框架——它只聚焦于视图层。因此它非常容易学习,非常容易与其它库或已有项目整合。另一方面,在与相关工具和支持库一起使用时,Vue.js 也能驱动复杂的单页应用。
2.3 MVVM模式介绍:
MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化,让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了,它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑。微软的WPF带来了新的技术体验,如Silverlight、音频、视频、3D、动画……,这导致了软件UI层更加细节化、可定制化。同时,在技术层面,WPF也带来了 诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM(Model-View-ViewModel)框架的由来便是MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性糅合进去,以应对客户日益复杂的需求变化。
2.4 B/S体系工作原理:
B/S架构采取浏览器请求,服务器响应的工作模式。
用户可以通过浏览器去访问Internet上由Web服务器产生的文本、数据、图片、动画、视频点播和声音等信息;
而每一个Web服务器又可以通过各种方式与数据库服务器连接,大量的数据实际存放在数据库服务器中;
从Web服务器上下载程序到本地来执行,在下载过程中若遇到与数据库有关的指令,由Web服务器交给数据库服务器来解释执行,并返回给Web服务器,Web服务器又返回给用户。在这种结构中,将许许多多的网连接到一块,形成一个巨大的网,即全球网。而各个企业可以在此结构的基础上建立自己的Internet。
在 B/S 模式中,用户是通过浏览器针对许多分布于网络上的服务器进行请求访问的,浏览器的请求通过服务器进行处理,并将处理结果以及相应的信息返回给浏览器,其他的数据加工、请求全部都是由Web Server完成的。通过该框架结构以及植入于操作系统内部的浏览器,该结构已经成为了当今软件应用的主流结构模式。
2.5 MySQL数据库
Mysql的语言是非结构化的,用户可以在数据上进行工作。MySQL因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下,MySQL是管理内容最好的选择。并且因为Mysql的语言和结构比较简单,但是功能和存储信息量很强大,所以得到了普遍的应用。
Mysql数据库在编程过程中的作用是很广泛的,为用户进行数据查询带来了方便。Mysql数据库的应用因其灵活性强,功能强大,所以在实现某功能时只需要一小段代码,而不像其他程序需要编写大段代码。总体来说,Mysql数据库的语言相对要简洁很多。
数据流程分析主要就是数据存储的储藏室,它是在计算机上进行的,而不是现实中的储藏室。数据的存放是按固定格式,而不是无序的,其定义就是:长期有固定格式,可以共享的存储在计算机存储器上。数据库管理主要是数据存储、修改和增加以及数据表的建立。为了保证系统数据的正常运行,一些有能力的处理者可以进行管理而不需要专业的人来处理。数据表的建立,可以对数据表中的数据进行调整,数据的重新组合及重新构造,保证数据的安全性。介于数据库的功能强大等特点,本系统的开发主要应用了Mysql进行对数据的管理。
2.6 koa框架优点
首先,借助promise和generator的能力,丢掉了callback,完美解决异步组合问题和异步异常捕获问题。
其次,koa 把express中内置的router、view 等功能都移除了,使得框架本身更轻量化。该设计有如下好处:1、把express各种中间件移植到koa是很简单的一件事;2、express 中内置的功能件未必好,比如view,想添加自己的view engine进入得做较深层次的hack,又比如router,它的效率不是最好的。koa没有内置这些,给了开发者很大的自由度,开发者都能自由发挥制作出更精细更专业的中间件。
2.7 Node.jsScript 运行模式
Node.jsScript是一种属于网络的高级脚本语言,已经被广泛用于Web应用开发,常用来为网页添加各式各样的动态功能,为用户提供更流畅美观的浏览效果。通常Node.jsScript脚本是通过嵌入在HTML中来实现自身的功能的。
1.1是一种解释性脚本语言(代码不进行预编译)。
1.2主要用来向HTML(标准通用标记语言下的一个应用)页面添加交互行为。
1.3可以直接嵌入HTML页面,但写成单独的js文件有利于结构和行为的分离。
1.4跨平台特性,在绝大多数浏览器的支持下,可以在多种平台下运行(如Windows、Linux、Mac、Android、iOS等)。
1.5 Node.jsScript脚本语言同其他语言一样,有它自身的基本数据类型,表达式和算术运算符及程序的基本程序框架。Node.jsScript提供了四种基本的数据类型和两种特殊数据类型用来处理数据和文字。而变量提供存放信息的地方,表达式则可以完成较复杂的信息处理。
本系统将在经济、技术、操作这三个角度上进行可行性分析。
整个系统从设计到开发以及测试过程严谨步骤齐全,所有工作任务全部由本人完成,并未获取外部技术支持,节约了一切服务成本开销以及人工成本,在硬件方面,为节约成本使用一台二手移动工作站作为项目部署服务器以及数据库服务器,成本在一万元一下,真个网络部署也是由本人独立完成不涉及到其他人工费用,整个开发过程本着低成本,低消耗的原则。
技术可行性分析的目的是确认该系统能否利用现有技术实现,并评估开发效率和完成情况。技术的可行性是指在当前的技术条件下,计算机软件和硬件的开发是否能够满足发展的要求。因为该系统的开发基于Node.js语言,所以开发该系统所需的软件和硬件条件可以在普通计算机上满足。因为它占用的内存相对较少,所以用Mysql数据库开发和设计软件理论上没有问题,因为它占用的内存太少。上述技术可以有效地保证系统的成功和高效开发。
医保药品集中采购系统的使用界面简单易于操作,采用常见的界面窗口来登录界面,通过电脑进行访问操作,用户只要平时使用过电脑都能进行访问操作。此系统的开发采用Node.js技术开发,人性化和完善化是B/S结构开发比较显要的特点使得用户操作相比较其他更加简洁方便。易操作、易管理、交互性好在本系统操作上体现得淋漓尽致。
前台需求:
(1)用户模块:主要包括用户的注册和登陆、用户个人信息管理等功能。
(2)药品资讯模块:主要包括药品资讯信息浏览功能。
(3)采购招标模块:主要存储采购招标信息。
(4)企业投标模块:主要存储企业投标信息。
后台需求:
(1)用户管理:主要包括用户列表、用户等级管理等功能。
(2)资讯管理:对药品资讯信息进行发布管理等。
(3)采购招标管理:对采购招标信息审核处理。
(4)企业投标管理:管理企业投标信息。
药品企业用例图如下所示。
图1 药品企业用例图
管理员用例图如下所示。
图2 管理员用例图
医疗机构用例图如下所示。
图3 医疗机构用例图
药品资讯添加用例描述如下表所示。
表1药品资讯添加用例描述
用例名称 | 添加新药品资讯 | |
参与者 | 管理员 | |
用例概述 | 本用例用于管理员进行添加新药品资讯操作 | |
前置条件 | 管理员添加新药品资讯前必须登录系统 | |
后置条件 | 系统中添加一个新药品资讯 | |
基本事件流 | 参与者动作 | 系统响应 |
4、管理员填写新药品资讯信息,点击“添加”按钮。 | 2、系统打开添加新药品资讯界面。 3、系统检查管理员输入的药品资讯信息是正确有效的。 5、系统将药品资讯添加到数据库中。 6、系统提示“操作成功”。 7、系统跳转到药品资讯管理界面。 | |
其他事件流 | 系统验证管理员输入的药品资讯名为空,则提示“*请填写药品资讯标题!”。 |
用户编辑用例描述如下表所示。
表2用户编辑用例描述
用例名称 | 修改用户 | |
参与者 | 管理员 | |
用例概述 | 本用例用于管理员进行修改用户信息操作 | |
前置条件 | 管理员已经登录系统 | |
后置条件 | 系统中更新一条用户记录 | |
基本事件流 | 参与者动作 | 系统响应 |
1、管理员在后台主界面选择“用户管理”。 4、管理员在用户列表中选择一个用户,点击“编辑”按钮。 6、管理员填写用户信息,点击“保存修改”按钮。 | 2、系统从数据库中获取用户信息。 3、系统打开用户列表界面。 5、系统打开修改用户信息界面。 7、系统将更改后的添加到数据库中。 8、系统提示“操作成功”。 9、系统跳转到用户管理界面。 | |
其他事件流 | 无 |
采购招标用例描述如下表所示。
表3采购招标用例描述
用例名称 | 采购招标 | |
参与者 | 用户 | |
用例概述 | 本用例用于用户进行对采购招标操作 | |
前置条件 | 用户已经登录系统 | |
后置条件 | 系统中增加一条招标信息 | |
基本事件流 | 参与者动作 | 系统响应 |
1、用户在前台首页选择任意一个采购分类。 4、采购招标,点击“查询”按钮。 | 2、系统从数据库中获取采购列表信息。 3、系统打开采购列表界面。 5、系统从数据库中获取采购信息。 6、系统打开采购信息界面。 7、系统检查用户输入的信息是正确有效的。 | |
其他事件流 | 1、系统验证用户输入的字段为空,则提示“*采购信息不能为空!”。 |
随着用户量的增加,系统可能会需要同时服务上千、上万个页面,服务器需要同时响应大量用户的操作,这就要求系统需要有良好的可扩展性,否则系统会出现延迟,卡顿甚至服务器崩溃的问题。高扩展性可以使软件保持旺盛的生命力,同时也能够使系统更好的适应用户增加、提高性能需求、增加应用功能等改变。
系统中保存了大量用户和管理员的个人信息,因此,保证系统服务器和数据安全是在开发过程中需要考虑的重要问题。安全性包括服务器安全、操作系统安全、数据库安全、程序代码安全以及用户个人信息和支付安全等,系统可以通过采用防火墙技术、加密技术、认证技术等来增强其安全性,只有一个健壮安全的系统才能具有长久的生命力。
医保药品集中采购系统的前台中,用户模块主要实现:药品资讯、采购招标、企业投标的功能。医保药品集中采购系统的后台中,管理员对用户在前台提交产生的数据进行处理,以满足用户的需求。前台系统和后台系统有数据交互,整个系统各个部分相互独立又密不可分。后台的功能主要包括药品企业管理、医疗机构管理、招标分类管理、采购招标管理、企业投标管理等。
通过软件的需求分析已经获得了系统的基本功能需求。根据各大功能模块的不同,将系统分为各种功能大块。系统功能结构如下图所示。
图4系统功能结构图
概念设计包括实体和联系两部分,如该系统中,用户是一个实体,其属性包括用户 ID 标识、用户名、密码、电话、地址等属性。联系是指实体之间有意义的关联,包括一对一、一对多、多对多三种类型。
数据库表是设计和实现系统的一个重要基础。以下列出了医保药品集中采购系统几个重要的数据库表。
名称 | 类型 | 长度 | 不是null | 主键 | 注释 |
ordinary_users_id | int | 11 | 是 | 是 | 普通用户ID |
full_name | varchar | 64 | 否 | 否 | 姓名 |
gender | varchar | 64 | 否 | 否 | 性别 |
examine_state | varchar | 16 | 是 | 否 | 审核状态 |
recommend | int | 11 | 是 | 否 | 智能推荐 |
user_id | int | 11 | 是 | 否 | 用户ID |
create_time | datetime | 0 | 是 | 否 | 创建时间 |
update_time | timestamp | 0 | 是 | 否 | 更新时间 |
名称 | 类型 | 长度 | 不是null | 主键 | 注释 |
bidding_classification_id | int | 11 | 是 | 是 | 招标分类ID |
bidding_category | varchar | 64 | 否 | 否 | 招标类别 |
recommend | int | 11 | 是 | 否 | 智能推荐 |
create_time | datetime | 0 | 是 | 否 | 创建时间 |
update_time | timestamp | 0 | 是 | 否 | 更新时间 |
名称 | 类型 | 长度 | 不是null | 主键 | 注释 |
enterprise_bidding_id | int | 11 | 是 | 是 | 企业投标ID |
organization_number | int | 11 | 否 | 否 | 机构编号 |
organization_name | varchar | 64 | 否 | 否 | 机构名称 |
title | varchar | 64 | 否 | 否 | 标题 |
bidding_category | varchar | 64 | 否 | 否 | 招标类别 |
enterprise_number | int | 11 | 否 | 否 | 企业编号 |
enterprise_name | varchar | 64 | 否 | 否 | 企业名称 |
offer | int | 11 | 否 | 否 | 报价 |
bidding_data | varchar | 255 | 否 | 否 | 投标资料 |
contact_number | varchar | 64 | 否 | 否 | 联系电话 |
examine_state | varchar | 16 | 是 | 否 | 审核状态 |
examine_reply | varchar | 16 | 否 | 否 | 审核回复 |
recommend | int | 11 | 是 | 否 | 智能推荐 |
create_time | datetime | 0 | 是 | 否 | 创建时间 |
update_time | timestamp | 0 | 是 | 否 | 更新时间 |
名称 | 类型 | 长度 | 不是null | 主键 | 注释 |
medical_institution_id | int | 11 | 是 | 是 | 医疗机构ID |
organization_number | varchar | 64 | 是 | 否 | 机构编号 |
organization_name | varchar | 64 | 否 | 否 | 机构名称 |
person_in_charge | varchar | 64 | 否 | 否 | 负责人 |
address | varchar | 64 | 否 | 否 | 地址 |
examine_state | varchar | 16 | 是 | 否 | 审核状态 |
recommend | int | 11 | 是 | 否 | 智能推荐 |
user_id | int | 11 | 是 | 否 | 用户ID |
create_time | datetime | 0 | 是 | 否 | 创建时间 |
update_time | timestamp | 0 | 是 | 否 | 更新时间 |
名称 | 类型 | 长度 | 不是null | 主键 | 注释 |
auth_id | int | 11 | 是 | 是 | 授权ID: |
user_group | varchar | 64 | 否 | 否 | 用户组: |
mod_name | varchar | 64 | 否 | 否 | 模块名: |
table_name | varchar | 64 | 否 | 否 | 表名: |
page_title | varchar | 255 | 否 | 否 | 页面标题: |
path | varchar | 255 | 否 | 否 | 路由路径: |
position | varchar | 32 | 否 | 否 | 位置: |
mode | varchar | 32 | 是 | 否 | 跳转方式: |
add | tinyint | 1 | 是 | 否 | 是否可增加: |
del | tinyint | 1 | 是 | 否 | 是否可删除: |
set | tinyint | 1 | 是 | 否 | 是否可修改: |
get | tinyint | 1 | 是 | 否 | 是否可查看: |
field_add | varchar | 500 | 否 | 否 | 添加字段: |
field_set | varchar | 500 | 否 | 否 | 修改字段: |
field_get | varchar | 500 | 否 | 否 | 查询字段: |
table_nav_name | varchar | 255 | 否 | 否 | 跨表导航名称: |
table_nav | varchar | 255 | 否 | 否 | 跨表导航: |
option | text | 0 | 否 | 否 | 配置: |
create_time | timestamp | 0 | 是 | 否 | 创建时间: |
update_time | timestamp | 0 | 是 | 否 | 更新时间: |
类型 | 长度 | 不是null | 主键 | 注释 | |
pharmaceutical_enterprises_id | int | 11 | 是 | 是 | 药品企业ID |
enterprise_number | varchar | 64 | 是 | 否 | 企业编号 |
enterprise_name | varchar | 64 | 否 | 否 | 企业名称 |
person_in_charge | varchar | 64 | 否 | 否 | 负责人 |
examine_state | varchar | 16 | 是 | 否 | 审核状态 |
recommend | int | 11 | 是 | 否 | 智能推荐 |
user_id | int | 11 | 是 | 否 | 用户ID |
create_time | datetime | 0 | 是 | 否 | 创建时间 |
update_time | timestamp | 0 | 是 | 否 | 更新时间 |
名称 | 类型 | 长度 | 不是null | 主键 | 注释 |
comment_id | int | 11 | 是 | 是 | 评论ID: |
user_id | int | 11 | 是 | 否 | 评论人ID: |
reply_to_id | int | 11 | 是 | 否 | 回复评论ID |
content | longtext | 0 | 否 | 否 | 内容: |
nickname | varchar | 255 | 否 | 否 | 昵称: |
avatar | varchar | 255 | 否 | 否 | 头像地址 |
create_time | timestamp | 0 | 是 | 否 | 创建时间: |
update_time | timestamp | 0 | 是 | 否 | 更新时间: |
source_table | varchar | 255 | 否 | 否 | 来源表: |
source_field | varchar | 255 | 否 | 否 | 来源字段: |
source_id | int | 10 | 是 | 否 | 来源ID: |
- 系统实现
本系统主要的用户有系统管理员、用户,一个系统最基本的功能就是登录功能,本系统可以进行系统登录的角色有用户、管理员,用户对应前台登录界面,管理员对应后台登录界面,首先进入登录页,输入用户名和密码,然后提交至服务端进行数据库数据验证,通过Node.jsEE逻辑代码判断数据库是否存在用户输入的这一个记录,如果存在,则判断用户身份,如果是用户,则进入用户前台,如果是管理员用户,则进入系统主页,并把用户对象存放在session中,如果不存在这样一条记录,则返回登录界面。
登录界面如下所示。
图5-1登录界面
用户界面要尽量简洁大方,使用户能够方便找到需要的功能入口,浏览药品资讯、进行采购招标信息查询以及公告信息浏览等,且要易于修改和维护,同时还要保证用户合法和系统安全。
首页界面如下图所示。
图5-2首页界面
用户进入系统首页后,点击“注册”链接进入到注册页面,按照页面提示输入用户名密码和手机号,页面进行表单验证,验证输入的用户名和账号是否合法,表单验证通过后,点击“立即注册”按钮,利用 Ajax 技术,对用户名和账号实现页面无刷新验证,检测数据库中是否已经存在该用户名,若数据库中不存在,则注册成功,注册成功后,自动跳转到登录页面。
用户注册界面如下图所示。
图5-3注册界面
药品资讯页面,用户可以对系统发布的药品资讯进行浏览交。如下图所示。
图5-4药品资讯页面
系统首页提供了采购招标信息列表、用户可以进行采购招标信息的查看,具体包括机构名称、招标类别等。
采购招标界面如下图所示。
图5-5采购招标界面
公告消息界面如下图所示。
图5-6公告消息界面
管理员对系统用户的管理,在管理员管理实现管理员用户的管理,包括录入、删除、修改,修改密码通过SESSION获取用户名,然后输入新密码,使用sql命令更新密码。
用户管理界面如下图所示。
图5-7用户管理界面
管理员可以获取系统中所有采购招标列表,并可以对其信息进行编辑。管理员在添加采购招标时,需要输入机构编号、机构名称、招标类别、供应日期、采购物质信息等,并对其进行维护管理等。
采购招标管理界面如下图所示。
图5-8采购招标管理界面
企业投标管理界面如下图所示。
图5-9企业投标管理界面
以进入系统首页的访问速度为例展示系统的性能测试;系统的主要用户群体是药品企业和医疗机构,系统要在3秒钟内响应;需要完成页面的菜单栏、首页轮播图片、采购招标列表、企业投标以及各功能模块入口等元素的显示。
功能性测试是指执行指定的工作流程,通过对一个系统的所有特性和功能都进行测试确保符合需求和规范。
系统功能性测试表如下表所示。
表11系统功能性测试表
编号 | 测试功能 | 测试内容 | 测试结果 |
1 | 用户登录 | 1.验证用户名与密码的正确性。 2.验证密码是否可见。 | 通过 |
2 | 首页展示 | 1.首页数据是否成功加载。 2.验证搜索功能的准确性。 3.验证是否可以异步加载。 4.验证导航栏按钮。 | 通过 |
3 | 个人信息修改 | 1.验证登录名是否可以正常更改。 2.验证联系方式是否可以更改。 3.验证密码是否可以修改。 | 通过 |
4 | 公告消息管理 | 1.消息清单是否可以生成。 2.验证信息是否准确。 | 通过 |
7 | 药品资讯管理 | 1.验证资讯新增是否可以成功。 2.验证资讯删除是否可以成功。 | 通过 |
8 | 采购招标管理 | 1.采购招标信息是否与上传一致。 2.是否能完成展示。 | 通过 |
9 | 企业投标管理 | 1.能否正常上传投标信息。 2.验证数据准确性。 | 通过 |
10 | 用户管理 | 1.验证用户录入功能。 2.验证用户违规清理功能。 | 通过 |
集成测试后,所有的模块已经全部连接完毕,形成了一个完整的系统。合格性测试是在集成测试完毕后,进一步对系统进行综合性的检测。经过合格性测试,可以检查出系统是否符合系统的设计,能够完成需求的所有功能。本系统经过最后的测试,所有模块功能都能按预定要求工作。
在实际测试中,经过一系列系统性的测试,使我们能够及时发现一些系统在设计中出现的疏忽和漏洞。经过严密的测试,不仅发现了模块内部的错误,也查找到模块连接后产生的错误。经过测试,对系统产生错误的地方进行优化、修改和完善,使得系统能够实现最初设计的基本功能。
本文针对医保药品集中采购系统的特点和用户需求,利用 Node.js相关技术、Koa框架和等技术,通过详细的需求分析、页面设计和功能设计,实现了包括用户模块、药品资讯模块、采购招标模块。公告模块的前台系统以及包括用户管理模块、采购招标管理模块、企业投标管理模块的后台系统。并添加了用户的访问控制,建立了一个完整、健壮、安全稳定的医保药品集中采购系统。
由于时间限制和本人能力条件有限,还存在一些不足,今后也会出现许多新的开发技术,未来还可以对程序做出如下改进:
(1)优化程序页面,使页面更加美观且方便操作;
(2)优化信息搜索功能,提供多条件选择查询搜索;
(3)优化分类功能,提高分类的精准度;
(4)进一步提高使用程序的安全性,使其更加健壮;
(5)优化数据和代码,提升软件效率,方便维护和扩展。
参考文献
[1]杜雯雯,徐伟.基于药品采购数据库的医疗机构药品配备使用现状研究:以江苏省为例[J].中国现代应用药学,2022,39(06):810-814.DOI:10.13748/j.cnki.issn1007-7693.2022.06.017.
[2].浙江省医疗保障局关于印发浙江省提升药品集中采购平台功能推进医保药品支付标准全覆盖改革方案的通知[J].浙江省人民政府公报,2020(14):32-35.
[3]张燕. 公共管理视角下内蒙古医保药品带量采购政策执行研究[D].内蒙古大学,2020.DOI:10.27224/d.cnki.gnmdu.2020.000286.
[4]孙明.军队医院药品采购模式比较与现状分析[J].药学实践杂志,2020,38(01):22-26.
[5]姜亦晨. 上海市医保药品“带量采购”政策执行问题研究[D].华东师范大学,2019.DOI:10.27149/d.cnki.ghdsu.2019.000086.
[6]陈勇隽. 医保药品支付价格形成机制研究[D].上海交通大学,2018.DOI:10.27307/d.cnki.gsjtu.2018.004305.
[7]金雨婷,杨帆,邵蓉.医保药品支付标准与采购价的差额产生机制及其归属问题研究[J].中国卫生政策研究,2018,11(03):51-55.
[8]蔡雪妮.中国药品集中采购的演变以及与医保支付的逻辑关系[J].中国卫生政策研究,2018,10(06):6-12.
[9]刘桂圆. 药品价格改革形势下医保药品支付标准的研究[D].东南大学,2018.
[10]武奇蓉. 上海药品带量采购模式研究[D].上海交通大学,2018.DOI:10.27307/d.cnki.gsjtu.2018.005867.
[11]王旭. 论我国药品价格的法律规制[D].吉林大学,2018.
[12]王雅楠,官海静,刘国恩,孙利华.台湾地区医保药品的采购模式和支付价格[J].中国卫生政策研究,2018,8(12):18-22.
[13].改革药品价格形成机制[J].中国医疗保险,2018(07):8.
[14]通讯员 江玄勺. 非医保药品中标价下降38.01%[N]. 博尔塔拉报,2018-02-14(002).DOI:10.28011/n.cnki.nbetl.2008.000210.
致谢
时光飞逝,转眼间我在学校的这些年生活即将结束,回顾这几年的学习生活,收获良多,既有幸福也有难过,学校生活的结束对于我来说也是一个新的开始。论文即将完成,在此,我心中有许多想要感谢的人。首先感谢我的导师,不仅在学习研究方面加以指导,也在生活和为人处世上给予帮助。还要感谢授课老师,你们严谨的学术精神和积极向上的工作态度都在激励我的成长和进步。感谢多年来一直生活在一起的室友,谢谢你们多年来的陪伴和照顾。最后,要感谢各位论文评审老师,感谢您们在百忙之中抽空评阅本论文并给出宝贵的意见和建议。
点赞+收藏+关注 → 私信领取本源代码、数据库