Node.js醫(yī)保藥品集中采購(gòu)系統(tǒng)

摘要

為“解決看病貴，吃藥貴”的問(wèn)題，找出藥品流通環(huán)節(jié)，地區(qū)供價(jià)差異，順加作價(jià)機(jī)制不合理，合同不規(guī)范執(zhí)行，藥品市場(chǎng)缺乏競(jìng)爭(zhēng)等問(wèn)題原因。完善藥品集中采購(gòu)制度。主要是為了加強(qiáng)藥品質(zhì)量區(qū)別，實(shí)現(xiàn)網(wǎng)上充分競(jìng)價(jià)。開(kāi)展采取帶量采購(gòu)方式進(jìn)一步降低藥品價(jià)格，進(jìn)一步深化藥品價(jià)格形成機(jī)制。

本文主要通過(guò)對(duì)醫(yī)保藥品集中采購(gòu)系統(tǒng)的功能性需求分析，對(duì)系統(tǒng)的安全性和可擴(kuò)展性進(jìn)行了非功能性需求分析。在詳細(xì)的需求分析的基礎(chǔ)上，根據(jù)系統(tǒng)的功能設(shè)計(jì)確定了數(shù)據(jù)庫(kù)結(jié)構(gòu)，實(shí)現(xiàn)完整的代碼編寫(xiě)。醫(yī)保藥品集中采購(gòu)系統(tǒng)完成了主要模塊的頁(yè)面設(shè)計(jì)和功能實(shí)現(xiàn)。本文展示了首頁(yè)頁(yè)面的實(shí)現(xiàn)效果圖，并通過(guò)代碼和頁(yè)面介紹了用戶注冊(cè)功能、藥品資訊、采購(gòu)招標(biāo)、企業(yè)投標(biāo)管理的實(shí)現(xiàn)過(guò)程。

關(guān)鍵詞：醫(yī)保藥品集中采購(gòu)；Node.js；數(shù)據(jù)庫(kù)

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

目 錄

一、緒論 5

(一) 研究背景與現(xiàn)狀 5

(二) 研究?jī)?nèi)容 5

二、開(kāi)發(fā)工具及相關(guān)技術(shù)介紹 6

2.1 koa框架 3

2.2 Vue.js主要功能 4

2.3 MVVM模式介紹 4

2.4 B/S體系工作原理 5

2.5 Mysql數(shù)據(jù)庫(kù) 5

2.6 koa框架優(yōu)點(diǎn) 5

2.7Node.jsScript 運(yùn)行模式 5

三、系統(tǒng)分析 7

(一) 可行性分析 7

1. 經(jīng)濟(jì)可行性 7

2. 技術(shù)可行性 7

3. 操作可行性 7

(二) 功能性需求分析 7

(三) 非功能性需求分析 11

(四) 業(yè)務(wù)流程分析 11

四、系統(tǒng)設(shè)計(jì) 12

(一) 功能模塊設(shè)計(jì) 12

(二) 數(shù)據(jù)庫(kù)設(shè)計(jì) 14

1. 概念模型設(shè)計(jì) 14

2. 數(shù)據(jù)庫(kù)表設(shè)計(jì) 15

五、系統(tǒng)實(shí)現(xiàn) 17

(一) 用戶登錄的實(shí)現(xiàn) 18

(二) 系統(tǒng)前臺(tái)主要功能實(shí)現(xiàn) 18

(三) 系統(tǒng)后臺(tái)主要功能實(shí)現(xiàn) 21

六、系統(tǒng)測(cè)試 24

(一) 系統(tǒng)可靠性測(cè)試 24

(二) 系統(tǒng)功能性測(cè)試 24

(三) 系統(tǒng)合格性測(cè)試 25

(四) 測(cè)試結(jié)果 25

七、總結(jié)與展望 26

參考文獻(xiàn) 27

致謝 27

緒論

研究背景與現(xiàn)狀

自2009年深化醫(yī)藥衛(wèi)生體制改革以來(lái)，藥品在醫(yī)療費(fèi)用中所占比重持續(xù)降低，次均門(mén)診藥品費(fèi)用和人均住院藥品費(fèi)用占醫(yī)藥費(fèi)用的比例分別自2009年的51.5%和43.6%降至2016年的45.5%和34.6%，但同時(shí)次均門(mén)診藥品費(fèi)用和人均住院藥品費(fèi)用的總數(shù)依舊是持續(xù)攀升，分別自2009年78.3元和2480.6元增加至2016年114.6元和2977.5元，且我國(guó)藥品費(fèi)用占醫(yī)藥費(fèi)用的比例仍遠(yuǎn)高于發(fā)達(dá)國(guó)家的比例（10%左右)，藥品價(jià)格虛高和虛低并存情況明顯，藥品集中采購(gòu)制度不夠完善是產(chǎn)生此現(xiàn)象的重要因素。

我國(guó)藥品集中采購(gòu)制度的全面試點(diǎn)始于2000年，原衛(wèi)生部等5部委要求各省(區(qū)、市）要抓好2～3個(gè)藥品集中招標(biāo)采購(gòu)工作試點(diǎn)。經(jīng)過(guò)十多年的試點(diǎn)完善，2015年國(guó)務(wù)院辦公廳印發(fā)《關(guān)于完善公立醫(yī)院藥品集中采購(gòu)工作的指導(dǎo)意見(jiàn)》（以下簡(jiǎn)稱《指導(dǎo)意見(jiàn)》)，標(biāo)志著該項(xiàng)制度已基本建立，《指導(dǎo)意見(jiàn)》明確以省（市、區(qū)）為單位的網(wǎng)上藥品集中采購(gòu)方向，并將藥品分為五類，分別采取不同的采購(gòu)方式:對(duì)臨床用量大、采購(gòu)金額高、多家企業(yè)生產(chǎn)的基本藥物和非專利藥品實(shí)行雙信封公開(kāi)招標(biāo)采購(gòu)，對(duì)部分專利藥品、獨(dú)家生產(chǎn)藥品，以談判方式采購(gòu)，對(duì)臨床必需、用量小、市場(chǎng)供應(yīng)短缺的藥品實(shí)行議價(jià)采購(gòu)，對(duì)婦兒專科非專利藥品、急（搶）救藥品、基礎(chǔ)輸液、臨床用量小的藥品有醫(yī)院集中掛網(wǎng)采購(gòu)，其他相關(guān)藥品按國(guó)家現(xiàn)行規(guī)定采購(gòu)。

在醫(yī)保藥品集中采購(gòu)中，參與主體有藥品生產(chǎn)企業(yè)、公立醫(yī)療機(jī)構(gòu)、第三方平臺(tái)機(jī)構(gòu)、藥品經(jīng)營(yíng)企業(yè)，其中藥品第三方平臺(tái)機(jī)構(gòu)不直接參與藥品集中采購(gòu)，對(duì)醫(yī)保藥品價(jià)格的形成沒(méi)有產(chǎn)生影響。以競(jìng)價(jià)品種為例，醫(yī)保藥品價(jià)格形成過(guò)程為：藥品生產(chǎn)企業(yè)自主定價(jià)，并參與省第三方藥品交易平臺(tái)招標(biāo)采購(gòu)，中標(biāo)后，中標(biāo)企業(yè)發(fā)出藥品訂單以確定具體的采購(gòu)品種和數(shù)量，按中標(biāo)價(jià)格采購(gòu)藥品。藥品生產(chǎn)企業(yè)、經(jīng)營(yíng)企業(yè)、醫(yī)療結(jié)構(gòu)簽訂藥品購(gòu)銷協(xié)議，按中標(biāo)價(jià)格買(mǎi)賣(mài)藥品，醫(yī)療機(jī)構(gòu)根據(jù)每宗交易成交價(jià)格計(jì)算出成交品種的臨時(shí)零售價(jià)格賣(mài)給消費(fèi)者。藥品取消加成后，中標(biāo)價(jià)格等于零售價(jià)格。

研究?jī)?nèi)容

基于Node.js的醫(yī)保藥品集中采購(gòu)系統(tǒng)的開(kāi)發(fā)及實(shí)現(xiàn)，所需要的工作內(nèi)容：

（1）首先是確定選題，確定好所要做的系統(tǒng)，并對(duì)系統(tǒng)的背景及現(xiàn)在面臨的一些問(wèn)題等進(jìn)行系統(tǒng)的初步確認(rèn)。

（2）系統(tǒng)確認(rèn)完成后，結(jié)合系統(tǒng)開(kāi)發(fā)的需求進(jìn)行確認(rèn)系統(tǒng)開(kāi)發(fā)所使用的技術(shù)醫(yī)保藥品集中采購(gòu)系統(tǒng)的開(kāi)發(fā)使用Koa框架，數(shù)據(jù)庫(kù)進(jìn)行系統(tǒng)的搭建開(kāi)發(fā)，確認(rèn)好使用的技術(shù)進(jìn)行技術(shù)分析，所使用的技術(shù)是否可以完成系統(tǒng)的實(shí)現(xiàn)。

（3）確定好系統(tǒng)使用的技術(shù)，進(jìn)行在線確認(rèn)系統(tǒng)所劃分的用戶角色，并且根據(jù)用戶角色劃分確定所要設(shè)計(jì)的功能模塊，對(duì)于醫(yī)保藥品集中采購(gòu)系統(tǒng)的設(shè)計(jì)主要?jiǎng)澐謩e為管理員和用戶角色，并所使用的功能模塊也相應(yīng)不同，但是系統(tǒng)的數(shù)據(jù)庫(kù)實(shí)現(xiàn)的內(nèi)容是交互的，用戶可以隨時(shí)根據(jù)自己的需求進(jìn)行信息查詢，對(duì)于系統(tǒng)工作人員可以根據(jù)自己的分管內(nèi)容進(jìn)行在線信息的處理及操作，管理員獲取到所有用戶的詳細(xì)數(shù)據(jù)信息，并根據(jù)需求進(jìn)行第一時(shí)間處理解決。

（4）系統(tǒng)的功能模塊確認(rèn)完成后進(jìn)行程序及界面的設(shè)計(jì)，設(shè)計(jì)完成后，并且通過(guò)測(cè)試來(lái)判斷程序是否完善，對(duì)于系統(tǒng)測(cè)試，需要不同的用戶進(jìn)行不同的內(nèi)容編輯及提交，及使用不同的測(cè)試方式找出程序中存在的漏洞，并對(duì)程序出現(xiàn)的漏洞問(wèn)題進(jìn)行在線解決處理，如果測(cè)試系統(tǒng)沒(méi)有任何問(wèn)題時(shí)，可以將系統(tǒng)上傳進(jìn)行正式操作使用。

開(kāi)發(fā)工具及相關(guān)技術(shù)介紹

2.1koa框架

Node.js是一個(gè)異步的世界，官方API支持的都是callback形式的異步編程模型，這會(huì)帶來(lái)許多問(wèn)題，例如:1、callback嵌套問(wèn)題；2、異步函數(shù)中可能同步調(diào)用callback返回?cái)?shù)據(jù)，帶來(lái)不一致性。為了解決以上問(wèn)題Koa出現(xiàn)了。

koa是由Express原班人馬打造的，致力于成為一個(gè)更小、更富有表現(xiàn)力、更健壯的Web框架。使用koa編寫(xiě)web應(yīng)用，可以免除重復(fù)繁瑣的回調(diào)函數(shù)嵌套，并極大地提升錯(cuò)誤處理的效率。koa不在內(nèi)核方法中綁定任何中間件，它僅僅提供了一個(gè)輕量?jī)?yōu)雅的函數(shù)庫(kù)，使得編寫(xiě)Web應(yīng)用變得得心應(yīng)手。開(kāi)發(fā)思路和express差不多，最大的特點(diǎn)就是可以避免異步嵌套。

阿里內(nèi)部就在使用Koa框架，并在Koa基礎(chǔ)上面做了一些擴(kuò)展和封裝。并且基于koa開(kāi)發(fā)了一個(gè)開(kāi)源框架egg。

2.2 Vue.js 主要功能：

Vue.js是一套構(gòu)建用戶界面的漸進(jìn)式框架。與其他重量級(jí)框架不同的是，Vue采用自底向上增量開(kāi)發(fā)的設(shè)計(jì)。Vue 的核心庫(kù)只關(guān)注視圖層，并且非常容易學(xué)習(xí)，非常容易與其它庫(kù)或已有項(xiàng)目整合。另一方面，Vue 完全有能力驅(qū)動(dòng)采用單文件組件和Vue生態(tài)系統(tǒng)支持的庫(kù)開(kāi)發(fā)的復(fù)雜單頁(yè)應(yīng)用。

Vue.js 的目標(biāo)是通過(guò)盡可能簡(jiǎn)單的 API 實(shí)現(xiàn)響應(yīng)的數(shù)據(jù)綁定和組合的視圖組件。

Vue.js 自身不是一個(gè)全能框架——它只聚焦于視圖層。因此它非常容易學(xué)習(xí)，非常容易與其它庫(kù)或已有項(xiàng)目整合。另一方面，在與相關(guān)工具和支持庫(kù)一起使用時(shí)，Vue.js 也能驅(qū)動(dòng)復(fù)雜的單頁(yè)應(yīng)用。

2.3 MVVM模式介紹：

MVVM是Model-View-ViewModel的簡(jiǎn)寫(xiě)。它本質(zhì)上就是MVC 的改進(jìn)版。MVVM 就是將其中的View 的狀態(tài)和行為抽象化，讓我們將視圖 UI 和業(yè)務(wù)邏輯分開(kāi)。當(dāng)然這些事 ViewModel 已經(jīng)幫我們做了，它可以取出 Model 的數(shù)據(jù)同時(shí)幫忙處理 View 中由于需要展示內(nèi)容而涉及的業(yè)務(wù)邏輯。微軟的WPF帶來(lái)了新的技術(shù)體驗(yàn)，如Silverlight、音頻、視頻、3D、動(dòng)畫(huà)……，這導(dǎo)致了軟件UI層更加細(xì)節(jié)化、可定制化。同時(shí)，在技術(shù)層面，WPF也帶來(lái)了 諸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM（Model-View-ViewModel）框架的由來(lái)便是MVP（Model-View-Presenter）模式與WPF結(jié)合的應(yīng)用方式時(shí)發(fā)展演變過(guò)來(lái)的一種新型架構(gòu)框架。它立足于原有MVP框架并且把WPF的新特性糅合進(jìn)去，以應(yīng)對(duì)客戶日益復(fù)雜的需求變化。

2.4 B/S體系工作原理：

B/S架構(gòu)采取瀏覽器請(qǐng)求，服務(wù)器響應(yīng)的工作模式。

用戶可以通過(guò)瀏覽器去訪問(wèn)Internet上由Web服務(wù)器產(chǎn)生的文本、數(shù)據(jù)、圖片、動(dòng)畫(huà)、視頻點(diǎn)播和聲音等信息；

而每一個(gè)Web服務(wù)器又可以通過(guò)各種方式與數(shù)據(jù)庫(kù)服務(wù)器連接，大量的數(shù)據(jù)實(shí)際存放在數(shù)據(jù)庫(kù)服務(wù)器中；

從Web服務(wù)器上下載程序到本地來(lái)執(zhí)行，在下載過(guò)程中若遇到與數(shù)據(jù)庫(kù)有關(guān)的指令，由Web服務(wù)器交給數(shù)據(jù)庫(kù)服務(wù)器來(lái)解釋執(zhí)行，并返回給Web服務(wù)器，Web服務(wù)器又返回給用戶。在這種結(jié)構(gòu)中，將許許多多的網(wǎng)連接到一塊，形成一個(gè)巨大的網(wǎng)，即全球網(wǎng)。而各個(gè)企業(yè)可以在此結(jié)構(gòu)的基礎(chǔ)上建立自己的Internet。

在 B/S 模式中，用戶是通過(guò)瀏覽器針對(duì)許多分布于網(wǎng)絡(luò)上的服務(wù)器進(jìn)行請(qǐng)求訪問(wèn)的，瀏覽器的請(qǐng)求通過(guò)服務(wù)器進(jìn)行處理，并將處理結(jié)果以及相應(yīng)的信息返回給瀏覽器，其他的數(shù)據(jù)加工、請(qǐng)求全部都是由Web Server完成的。通過(guò)該框架結(jié)構(gòu)以及植入于操作系統(tǒng)內(nèi)部的瀏覽器，該結(jié)構(gòu)已經(jīng)成為了當(dāng)今軟件應(yīng)用的主流結(jié)構(gòu)模式。

2.5 MySQL數(shù)據(jù)庫(kù)

Mysql的語(yǔ)言是非結(jié)構(gòu)化的，用戶可以在數(shù)據(jù)上進(jìn)行工作。MySQL因?yàn)槠渌俣取⒖煽啃院瓦m應(yīng)性而備受關(guān)注。大多數(shù)人都認(rèn)為在不需要事務(wù)化處理的情況下，MySQL是管理內(nèi)容最好的選擇。并且因?yàn)镸ysql的語(yǔ)言和結(jié)構(gòu)比較簡(jiǎn)單，但是功能和存儲(chǔ)信息量很強(qiáng)大，所以得到了普遍的應(yīng)用。

Mysql數(shù)據(jù)庫(kù)在編程過(guò)程中的作用是很廣泛的，為用戶進(jìn)行數(shù)據(jù)查詢帶來(lái)了方便。Mysql數(shù)據(jù)庫(kù)的應(yīng)用因其靈活性強(qiáng)，功能強(qiáng)大，所以在實(shí)現(xiàn)某功能時(shí)只需要一小段代碼，而不像其他程序需要編寫(xiě)大段代碼。總體來(lái)說(shuō)，Mysql數(shù)據(jù)庫(kù)的語(yǔ)言相對(duì)要簡(jiǎn)潔很多。

數(shù)據(jù)流程分析主要就是數(shù)據(jù)存儲(chǔ)的儲(chǔ)藏室，它是在計(jì)算機(jī)上進(jìn)行的，而不是現(xiàn)實(shí)中的儲(chǔ)藏室。數(shù)據(jù)的存放是按固定格式，而不是無(wú)序的，其定義就是：長(zhǎng)期有固定格式，可以共享的存儲(chǔ)在計(jì)算機(jī)存儲(chǔ)器上。數(shù)據(jù)庫(kù)管理主要是數(shù)據(jù)存儲(chǔ)、修改和增加以及數(shù)據(jù)表的建立。為了保證系統(tǒng)數(shù)據(jù)的正常運(yùn)行，一些有能力的處理者可以進(jìn)行管理而不需要專業(yè)的人來(lái)處理。數(shù)據(jù)表的建立，可以對(duì)數(shù)據(jù)表中的數(shù)據(jù)進(jìn)行調(diào)整，數(shù)據(jù)的重新組合及重新構(gòu)造，保證數(shù)據(jù)的安全性。介于數(shù)據(jù)庫(kù)的功能強(qiáng)大等特點(diǎn)，本系統(tǒng)的開(kāi)發(fā)主要應(yīng)用了Mysql進(jìn)行對(duì)數(shù)據(jù)的管理。

2.6 koa框架優(yōu)點(diǎn)

首先，借助promise和generator的能力，丟掉了callback，完美解決異步組合問(wèn)題和異步異常捕獲問(wèn)題。

其次，koa 把express中內(nèi)置的router、view 等功能都移除了，使得框架本身更輕量化。該設(shè)計(jì)有如下好處：1、把express各種中間件移植到koa是很簡(jiǎn)單的一件事；2、express 中內(nèi)置的功能件未必好，比如view，想添加自己的view engine進(jìn)入得做較深層次的hack，又比如router，它的效率不是最好的。koa沒(méi)有內(nèi)置這些，給了開(kāi)發(fā)者很大的自由度，開(kāi)發(fā)者都能自由發(fā)揮制作出更精細(xì)更專業(yè)的中間件。

2.7 Node.jsScript 運(yùn)行模式

Node.jsScript是一種屬于網(wǎng)絡(luò)的高級(jí)腳本語(yǔ)言,已經(jīng)被廣泛用于Web應(yīng)用開(kāi)發(fā),常用來(lái)為網(wǎng)頁(yè)添加各式各樣的動(dòng)態(tài)功能,為用戶提供更流暢美觀的瀏覽效果。通常Node.jsScript腳本是通過(guò)嵌入在HTML中來(lái)實(shí)現(xiàn)自身的功能的。

1.1是一種解釋性腳本語(yǔ)言（代碼不進(jìn)行預(yù)編譯）。

1.2主要用來(lái)向HTML（標(biāo)準(zhǔn)通用標(biāo)記語(yǔ)言下的一個(gè)應(yīng)用）頁(yè)面添加交互行為。

1.3可以直接嵌入HTML頁(yè)面，但寫(xiě)成單獨(dú)的js文件有利于結(jié)構(gòu)和行為的分離。

1.4跨平臺(tái)特性，在絕大多數(shù)瀏覽器的支持下，可以在多種平臺(tái)下運(yùn)行（如Windows、Linux、Mac、Android、iOS等）。

1.5 Node.jsScript腳本語(yǔ)言同其他語(yǔ)言一樣，有它自身的基本數(shù)據(jù)類型，表達(dá)式和算術(shù)運(yùn)算符及程序的基本程序框架。Node.jsScript提供了四種基本的數(shù)據(jù)類型和兩種特殊數(shù)據(jù)類型用來(lái)處理數(shù)據(jù)和文字。而變量提供存放信息的地方，表達(dá)式則可以完成較復(fù)雜的信息處理。

系統(tǒng)分析

可行性分析

本系統(tǒng)將在經(jīng)濟(jì)、技術(shù)、操作這三個(gè)角度上進(jìn)行可行性分析。

經(jīng)濟(jì)可行性

整個(gè)系統(tǒng)從設(shè)計(jì)到開(kāi)發(fā)以及測(cè)試過(guò)程嚴(yán)謹(jǐn)步驟齊全，所有工作任務(wù)全部由本人完成，并未獲取外部技術(shù)支持，節(jié)約了一切服務(wù)成本開(kāi)銷以及人工成本，在硬件方面，為節(jié)約成本使用一臺(tái)二手移動(dòng)工作站作為項(xiàng)目部署服務(wù)器以及數(shù)據(jù)庫(kù)服務(wù)器，成本在一萬(wàn)元一下，真?zhèn)€網(wǎng)絡(luò)部署也是由本人獨(dú)立完成不涉及到其他人工費(fèi)用，整個(gè)開(kāi)發(fā)過(guò)程本著低成本，低消耗的原則。

技術(shù)可行性

技術(shù)可行性分析的目的是確認(rèn)該系統(tǒng)能否利用現(xiàn)有技術(shù)實(shí)現(xiàn)，并評(píng)估開(kāi)發(fā)效率和完成情況。技術(shù)的可行性是指在當(dāng)前的技術(shù)條件下，計(jì)算機(jī)軟件和硬件的開(kāi)發(fā)是否能夠滿足發(fā)展的要求。因?yàn)樵撓到y(tǒng)的開(kāi)發(fā)基于Node.js語(yǔ)言，所以開(kāi)發(fā)該系統(tǒng)所需的軟件和硬件條件可以在普通計(jì)算機(jī)上滿足。因?yàn)樗加玫膬?nèi)存相對(duì)較少，所以用Mysql數(shù)據(jù)庫(kù)開(kāi)發(fā)和設(shè)計(jì)軟件理論上沒(méi)有問(wèn)題，因?yàn)樗加玫膬?nèi)存太少。上述技術(shù)可以有效地保證系統(tǒng)的成功和高效開(kāi)發(fā)。

操作可行性

醫(yī)保藥品集中采購(gòu)系統(tǒng)的使用界面簡(jiǎn)單易于操作，采用常見(jiàn)的界面窗口來(lái)登錄界面，通過(guò)電腦進(jìn)行訪問(wèn)操作，用戶只要平時(shí)使用過(guò)電腦都能進(jìn)行訪問(wèn)操作。此系統(tǒng)的開(kāi)發(fā)采用Node.js技術(shù)開(kāi)發(fā)，人性化和完善化是B/S結(jié)構(gòu)開(kāi)發(fā)比較顯要的特點(diǎn)使得用戶操作相比較其他更加簡(jiǎn)潔方便。易操作、易管理、交互性好在本系統(tǒng)操作上體現(xiàn)得淋漓盡致。

功能性需求分析

前臺(tái)需求：

（1）用戶模塊：主要包括用戶的注冊(cè)和登陸、用戶個(gè)人信息管理等功能。

（2）藥品資訊模塊：主要包括藥品資訊信息瀏覽功能。

（3）采購(gòu)招標(biāo)模塊：主要存儲(chǔ)采購(gòu)招標(biāo)信息。

（4）企業(yè)投標(biāo)模塊：主要存儲(chǔ)企業(yè)投標(biāo)信息。

后臺(tái)需求：

（1）用戶管理：主要包括用戶列表、用戶等級(jí)管理等功能。

（2）資訊管理：對(duì)藥品資訊信息進(jìn)行發(fā)布管理等。

（3）采購(gòu)招標(biāo)管理：對(duì)采購(gòu)招標(biāo)信息審核處理。

（4）企業(yè)投標(biāo)管理：管理企業(yè)投標(biāo)信息。

藥品企業(yè)用例圖如下所示。

圖1 藥品企業(yè)用例圖

管理員用例圖如下所示。

圖2 管理員用例圖

醫(yī)療機(jī)構(gòu)用例圖如下所示。

圖3 醫(yī)療機(jī)構(gòu)用例圖

藥品資訊添加用例描述如下表所示。

表1藥品資訊添加用例描述

用例名稱	添加新藥品資訊
參與者	管理員
用例概述	本用例用于管理員進(jìn)行添加新藥品資訊操作
前置條件	管理員添加新藥品資訊前必須登錄系統(tǒng)
后置條件	系統(tǒng)中添加一個(gè)新藥品資訊
基本事件流	參與者動(dòng)作	系統(tǒng)響應(yīng)
	管理員在后臺(tái)主界面選擇“新藥品資訊”。 4、管理員填寫(xiě)新藥品資訊信息，點(diǎn)擊“添加”按鈕。	2、系統(tǒng)打開(kāi)添加新藥品資訊界面。 3、系統(tǒng)檢查管理員輸入的藥品資訊信息是正確有效的。 5、系統(tǒng)將藥品資訊添加到數(shù)據(jù)庫(kù)中。 6、系統(tǒng)提示“操作成功”。 7、系統(tǒng)跳轉(zhuǎn)到藥品資訊管理界面。
其他事件流	系統(tǒng)驗(yàn)證管理員輸入的藥品資訊名為空，則提示“*請(qǐng)?zhí)顚?xiě)藥品資訊標(biāo)題！”。

用戶編輯用例描述如下表所示。

表2用戶編輯用例描述

用例名稱	修改用戶
參與者	管理員
用例概述	本用例用于管理員進(jìn)行修改用戶信息操作
前置條件	管理員已經(jīng)登錄系統(tǒng)
后置條件	系統(tǒng)中更新一條用戶記錄
基本事件流	參與者動(dòng)作	系統(tǒng)響應(yīng)
	1、管理員在后臺(tái)主界面選擇“用戶管理”。 4、管理員在用戶列表中選擇一個(gè)用戶，點(diǎn)擊“編輯”按鈕。 6、管理員填寫(xiě)用戶信息，點(diǎn)擊“保存修改”按鈕。	2、系統(tǒng)從數(shù)據(jù)庫(kù)中獲取用戶信息。 3、系統(tǒng)打開(kāi)用戶列表界面。 5、系統(tǒng)打開(kāi)修改用戶信息界面。 7、系統(tǒng)將更改后的添加到數(shù)據(jù)庫(kù)中。 8、系統(tǒng)提示“操作成功”。 9、系統(tǒng)跳轉(zhuǎn)到用戶管理界面。
其他事件流	無(wú)

采購(gòu)招標(biāo)用例描述如下表所示。

表3采購(gòu)招標(biāo)用例描述

用例名稱	采購(gòu)招標(biāo)
參與者	用戶
用例概述	本用例用于用戶進(jìn)行對(duì)采購(gòu)招標(biāo)操作
前置條件	用戶已經(jīng)登錄系統(tǒng)
后置條件	系統(tǒng)中增加一條招標(biāo)信息
基本事件流	參與者動(dòng)作	系統(tǒng)響應(yīng)
	1、用戶在前臺(tái)首頁(yè)選擇任意一個(gè)采購(gòu)分類。 4、采購(gòu)招標(biāo)，點(diǎn)擊“查詢”按鈕。	2、系統(tǒng)從數(shù)據(jù)庫(kù)中獲取采購(gòu)列表信息。 3、系統(tǒng)打開(kāi)采購(gòu)列表界面。 5、系統(tǒng)從數(shù)據(jù)庫(kù)中獲取采購(gòu)信息。 6、系統(tǒng)打開(kāi)采購(gòu)信息界面。 7、系統(tǒng)檢查用戶輸入的信息是正確有效的。
其他事件流	1、系統(tǒng)驗(yàn)證用戶輸入的字段為空，則提示“*采購(gòu)信息不能為空！”。

非功能性需求分析

隨著用戶量的增加，系統(tǒng)可能會(huì)需要同時(shí)服務(wù)上千、上萬(wàn)個(gè)頁(yè)面，服務(wù)器需要同時(shí)響應(yīng)大量用戶的操作，這就要求系統(tǒng)需要有良好的可擴(kuò)展性，否則系統(tǒng)會(huì)出現(xiàn)延遲，卡頓甚至服務(wù)器崩潰的問(wèn)題。高擴(kuò)展性可以使軟件保持旺盛的生命力，同時(shí)也能夠使系統(tǒng)更好的適應(yīng)用戶增加、提高性能需求、增加應(yīng)用功能等改變。

系統(tǒng)中保存了大量用戶和管理員的個(gè)人信息，因此，保證系統(tǒng)服務(wù)器和數(shù)據(jù)安全是在開(kāi)發(fā)過(guò)程中需要考慮的重要問(wèn)題。安全性包括服務(wù)器安全、操作系統(tǒng)安全、數(shù)據(jù)庫(kù)安全、程序代碼安全以及用戶個(gè)人信息和支付安全等，系統(tǒng)可以通過(guò)采用防火墻技術(shù)、加密技術(shù)、認(rèn)證技術(shù)等來(lái)增強(qiáng)其安全性，只有一個(gè)健壯安全的系統(tǒng)才能具有長(zhǎng)久的生命力。

業(yè)務(wù)流程分析

醫(yī)保藥品集中采購(gòu)系統(tǒng)的前臺(tái)中，用戶模塊主要實(shí)現(xiàn)：藥品資訊、采購(gòu)招標(biāo)、企業(yè)投標(biāo)的功能。醫(yī)保藥品集中采購(gòu)系統(tǒng)的后臺(tái)中，管理員對(duì)用戶在前臺(tái)提交產(chǎn)生的數(shù)據(jù)進(jìn)行處理，以滿足用戶的需求。前臺(tái)系統(tǒng)和后臺(tái)系統(tǒng)有數(shù)據(jù)交互，整個(gè)系統(tǒng)各個(gè)部分相互獨(dú)立又密不可分。后臺(tái)的功能主要包括藥品企業(yè)管理、醫(yī)療機(jī)構(gòu)管理、招標(biāo)分類管理、采購(gòu)招標(biāo)管理、企業(yè)投標(biāo)管理等。

系統(tǒng)設(shè)計(jì)

功能模塊設(shè)計(jì)

通過(guò)軟件的需求分析已經(jīng)獲得了系統(tǒng)的基本功能需求。根據(jù)各大功能模塊的不同，將系統(tǒng)分為各種功能大塊。系統(tǒng)功能結(jié)構(gòu)如下圖所示。

圖4系統(tǒng)功能結(jié)構(gòu)圖

數(shù)據(jù)庫(kù)設(shè)計(jì)

概念模型設(shè)計(jì)

概念設(shè)計(jì)包括實(shí)體和聯(lián)系兩部分，如該系統(tǒng)中，用戶是一個(gè)實(shí)體，其屬性包括用戶 ID 標(biāo)識(shí)、用戶名、密碼、電話、地址等屬性。聯(lián)系是指實(shí)體之間有意義的關(guān)聯(lián)，包括一對(duì)一、一對(duì)多、多對(duì)多三種類型。

數(shù)據(jù)庫(kù)表設(shè)計(jì)

數(shù)據(jù)庫(kù)表是設(shè)計(jì)和實(shí)現(xiàn)系統(tǒng)的一個(gè)重要基礎(chǔ)。以下列出了醫(yī)保藥品集中采購(gòu)系統(tǒng)幾個(gè)重要的數(shù)據(jù)庫(kù)表。

名稱	類型	長(zhǎng)度	不是null	主鍵	注釋
ordinary_users_id	int	11	是	是	普通用戶ID
full_name	varchar	64	否	否	姓名
gender	varchar	64	否	否	性別
examine_state	varchar	16	是	否	審核狀態(tài)
recommend	int	11	是	否	智能推薦
user_id	int	11	是	否	用戶ID
create_time	datetime	0	是	否	創(chuàng)建時(shí)間
update_time	timestamp	0	是	否	更新時(shí)間

名稱	類型	長(zhǎng)度	不是null	主鍵	注釋
bidding_classification_id	int	11	是	是	招標(biāo)分類ID
bidding_category	varchar	64	否	否	招標(biāo)類別
recommend	int	11	是	否	智能推薦
create_time	datetime	0	是	否	創(chuàng)建時(shí)間
update_time	timestamp	0	是	否	更新時(shí)間

名稱	類型	長(zhǎng)度	不是null	主鍵	注釋
enterprise_bidding_id	int	11	是	是	企業(yè)投標(biāo)ID
organization_number	int	11	否	否	機(jī)構(gòu)編號(hào)
organization_name	varchar	64	否	否	機(jī)構(gòu)名稱
title	varchar	64	否	否	標(biāo)題
bidding_category	varchar	64	否	否	招標(biāo)類別
enterprise_number	int	11	否	否	企業(yè)編號(hào)
enterprise_name	varchar	64	否	否	企業(yè)名稱
offer	int	11	否	否	報(bào)價(jià)
bidding_data	varchar	255	否	否	投標(biāo)資料
contact_number	varchar	64	否	否	聯(lián)系電話
examine_state	varchar	16	是	否	審核狀態(tài)
examine_reply	varchar	16	否	否	審核回復(fù)
recommend	int	11	是	否	智能推薦
create_time	datetime	0	是	否	創(chuàng)建時(shí)間
update_time	timestamp	0	是	否	更新時(shí)間

名稱	類型	長(zhǎng)度	不是null	主鍵	注釋
medical_institution_id	int	11	是	是	醫(yī)療機(jī)構(gòu)ID
organization_number	varchar	64	是	否	機(jī)構(gòu)編號(hào)
organization_name	varchar	64	否	否	機(jī)構(gòu)名稱
person_in_charge	varchar	64	否	否	負(fù)責(zé)人
address	varchar	64	否	否	地址
examine_state	varchar	16	是	否	審核狀態(tài)
recommend	int	11	是	否	智能推薦
user_id	int	11	是	否	用戶ID
create_time	datetime	0	是	否	創(chuàng)建時(shí)間
update_time	timestamp	0	是	否	更新時(shí)間

名稱	類型	長(zhǎng)度	不是null	主鍵	注釋
auth_id	int	11	是	是	授權(quán)ID：
user_group	varchar	64	否	否	用戶組：
mod_name	varchar	64	否	否	模塊名：
table_name	varchar	64	否	否	表名：
page_title	varchar	255	否	否	頁(yè)面標(biāo)題：
path	varchar	255	否	否	路由路徑：
position	varchar	32	否	否	位置：
mode	varchar	32	是	否	跳轉(zhuǎn)方式：
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	否	否	跨表導(dǎo)航名稱：
table_nav	varchar	255	否	否	跨表導(dǎo)航：
option	text	0	否	否	配置：
create_time	timestamp	0	是	否	創(chuàng)建時(shí)間：
update_time	timestamp	0	是	否	更新時(shí)間：

名稱	類型	長(zhǎng)度	不是null	主鍵	注釋
pharmaceutical_enterprises_id	int	11	是	是	藥品企業(yè)ID
enterprise_number	varchar	64	是	否	企業(yè)編號(hào)
enterprise_name	varchar	64	否	否	企業(yè)名稱
person_in_charge	varchar	64	否	否	負(fù)責(zé)人
examine_state	varchar	16	是	否	審核狀態(tài)
recommend	int	11	是	否	智能推薦
user_id	int	11	是	否	用戶ID
create_time	datetime	0	是	否	創(chuàng)建時(shí)間
update_time	timestamp	0	是	否	更新時(shí)間

名稱	類型	長(zhǎng)度	不是null	主鍵	注釋
comment_id	int	11	是	是	評(píng)論ID：
user_id	int	11	是	否	評(píng)論人ID：
reply_to_id	int	11	是	否	回復(fù)評(píng)論ID
content	longtext	0	否	否	內(nèi)容：
nickname	varchar	255	否	否	昵稱：
avatar	varchar	255	否	否	頭像地址
create_time	timestamp	0	是	否	創(chuàng)建時(shí)間：
update_time	timestamp	0	是	否	更新時(shí)間：
source_table	varchar	255	否	否	來(lái)源表：
source_field	varchar	255	否	否	來(lái)源字段：
source_id	int	10	是	否	來(lái)源ID：

系統(tǒng)實(shí)現(xiàn)

用戶登錄的實(shí)現(xiàn)

本系統(tǒng)主要的用戶有系統(tǒng)管理員、用戶，一個(gè)系統(tǒng)最基本的功能就是登錄功能，本系統(tǒng)可以進(jìn)行系統(tǒng)登錄的角色有用戶、管理員，用戶對(duì)應(yīng)前臺(tái)登錄界面，管理員對(duì)應(yīng)后臺(tái)登錄界面，首先進(jìn)入登錄頁(yè)，輸入用戶名和密碼，然后提交至服務(wù)端進(jìn)行數(shù)據(jù)庫(kù)數(shù)據(jù)驗(yàn)證，通過(guò)Node.jsEE邏輯代碼判斷數(shù)據(jù)庫(kù)是否存在用戶輸入的這一個(gè)記錄，如果存在，則判斷用戶身份，如果是用戶，則進(jìn)入用戶前臺(tái)，如果是管理員用戶，則進(jìn)入系統(tǒng)主頁(yè)，并把用戶對(duì)象存放在session中，如果不存在這樣一條記錄，則返回登錄界面。

登錄界面如下所示。

圖5-1登錄界面

系統(tǒng)前臺(tái)主要功能實(shí)現(xiàn)

首頁(yè)的實(shí)現(xiàn)

用戶界面要盡量簡(jiǎn)潔大方，使用戶能夠方便找到需要的功能入口，瀏覽藥品資訊、進(jìn)行采購(gòu)招標(biāo)信息查詢以及公告信息瀏覽等，且要易于修改和維護(hù)，同時(shí)還要保證用戶合法和系統(tǒng)安全。

首頁(yè)界面如下圖所示。

圖5-2首頁(yè)界面

用戶注冊(cè)的實(shí)現(xiàn)

用戶進(jìn)入系統(tǒng)首頁(yè)后，點(diǎn)擊“注冊(cè)”鏈接進(jìn)入到注冊(cè)頁(yè)面，按照頁(yè)面提示輸入用戶名密碼和手機(jī)號(hào)，頁(yè)面進(jìn)行表單驗(yàn)證，驗(yàn)證輸入的用戶名和賬號(hào)是否合法，表單驗(yàn)證通過(guò)后，點(diǎn)擊“立即注冊(cè)”按鈕，利用 Ajax 技術(shù)，對(duì)用戶名和賬號(hào)實(shí)現(xiàn)頁(yè)面無(wú)刷新驗(yàn)證，檢測(cè)數(shù)據(jù)庫(kù)中是否已經(jīng)存在該用戶名，若數(shù)據(jù)庫(kù)中不存在，則注冊(cè)成功，注冊(cè)成功后，自動(dòng)跳轉(zhuǎn)到登錄頁(yè)面。

用戶注冊(cè)界面如下圖所示。

圖5-3注冊(cè)界面

藥品資訊的實(shí)現(xiàn)

藥品資訊頁(yè)面，用戶可以對(duì)系統(tǒng)發(fā)布的藥品資訊進(jìn)行瀏覽交。如下圖所示。

圖5-4藥品資訊頁(yè)面

采購(gòu)招標(biāo)的實(shí)現(xiàn)

系統(tǒng)首頁(yè)提供了采購(gòu)招標(biāo)信息列表、用戶可以進(jìn)行采購(gòu)招標(biāo)信息的查看，具體包括機(jī)構(gòu)名稱、招標(biāo)類別等。

采購(gòu)招標(biāo)界面如下圖所示。

圖5-5采購(gòu)招標(biāo)界面

公告消息的實(shí)現(xiàn)

公告消息界面如下圖所示。

圖5-6公告消息界面

系統(tǒng)后臺(tái)主要功能實(shí)現(xiàn)

用戶管理的實(shí)現(xiàn)

管理員對(duì)系統(tǒng)用戶的管理，在管理員管理實(shí)現(xiàn)管理員用戶的管理，包括錄入、刪除、修改，修改密碼通過(guò)SESSION獲取用戶名，然后輸入新密碼，使用sql命令更新密碼。

用戶管理界面如下圖所示。

圖5-7用戶管理界面

采購(gòu)招標(biāo)管理的實(shí)現(xiàn)

管理員可以獲取系統(tǒng)中所有采購(gòu)招標(biāo)列表，并可以對(duì)其信息進(jìn)行編輯。管理員在添加采購(gòu)招標(biāo)時(shí)，需要輸入機(jī)構(gòu)編號(hào)、機(jī)構(gòu)名稱、招標(biāo)類別、供應(yīng)日期、采購(gòu)物質(zhì)信息等，并對(duì)其進(jìn)行維護(hù)管理等。

采購(gòu)招標(biāo)管理界面如下圖所示。

圖5-8采購(gòu)招標(biāo)管理界面

企業(yè)投標(biāo)管理的實(shí)現(xiàn)

企業(yè)投標(biāo)管理界面如下圖所示。

圖5-9企業(yè)投標(biāo)管理界面

系統(tǒng)測(cè)試

系統(tǒng)可靠性測(cè)試

以進(jìn)入系統(tǒng)首頁(yè)的訪問(wèn)速度為例展示系統(tǒng)的性能測(cè)試；系統(tǒng)的主要用戶群體是藥品企業(yè)和醫(yī)療機(jī)構(gòu)，系統(tǒng)要在3秒鐘內(nèi)響應(yīng)；需要完成頁(yè)面的菜單欄、首頁(yè)輪播圖片、采購(gòu)招標(biāo)列表、企業(yè)投標(biāo)以及各功能模塊入口等元素的顯示。

系統(tǒng)功能性測(cè)試

功能性測(cè)試是指執(zhí)行指定的工作流程，通過(guò)對(duì)一個(gè)系統(tǒng)的所有特性和功能都進(jìn)行測(cè)試確保符合需求和規(guī)范。

系統(tǒng)功能性測(cè)試表如下表所示。

表11系統(tǒng)功能性測(cè)試表

編號(hào)	測(cè)試功能	測(cè)試內(nèi)容	測(cè)試結(jié)果
1	用戶登錄	1．驗(yàn)證用戶名與密碼的正確性。 2．驗(yàn)證密碼是否可見(jiàn)。	通過(guò)
2	首頁(yè)展示	1．首頁(yè)數(shù)據(jù)是否成功加載。 2．驗(yàn)證搜索功能的準(zhǔn)確性。 3．驗(yàn)證是否可以異步加載。 4．驗(yàn)證導(dǎo)航欄按鈕。	通過(guò)
3	個(gè)人信息修改	1．驗(yàn)證登錄名是否可以正常更改。 2．驗(yàn)證聯(lián)系方式是否可以更改。 3．驗(yàn)證密碼是否可以修改。	通過(guò)
4	公告消息管理	1．消息清單是否可以生成。 2．驗(yàn)證信息是否準(zhǔn)確。	通過(guò)
7	藥品資訊管理	1．驗(yàn)證資訊新增是否可以成功。 2．驗(yàn)證資訊刪除是否可以成功。	通過(guò)
8	采購(gòu)招標(biāo)管理	1．采購(gòu)招標(biāo)信息是否與上傳一致。 2．是否能完成展示。	通過(guò)
9	企業(yè)投標(biāo)管理	1．能否正常上傳投標(biāo)信息。 2．驗(yàn)證數(shù)據(jù)準(zhǔn)確性。	通過(guò)
10	用戶管理	1．驗(yàn)證用戶錄入功能。 2．驗(yàn)證用戶違規(guī)清理功能。	通過(guò)

系統(tǒng)合格性測(cè)試

集成測(cè)試后，所有的模塊已經(jīng)全部連接完畢，形成了一個(gè)完整的系統(tǒng)。合格性測(cè)試是在集成測(cè)試完畢后，進(jìn)一步對(duì)系統(tǒng)進(jìn)行綜合性的檢測(cè)。經(jīng)過(guò)合格性測(cè)試，可以檢查出系統(tǒng)是否符合系統(tǒng)的設(shè)計(jì)，能夠完成需求的所有功能。本系統(tǒng)經(jīng)過(guò)最后的測(cè)試，所有模塊功能都能按預(yù)定要求工作。

測(cè)試結(jié)果

在實(shí)際測(cè)試中，經(jīng)過(guò)一系列系統(tǒng)性的測(cè)試，使我們能夠及時(shí)發(fā)現(xiàn)一些系統(tǒng)在設(shè)計(jì)中出現(xiàn)的疏忽和漏洞。經(jīng)過(guò)嚴(yán)密的測(cè)試，不僅發(fā)現(xiàn)了模塊內(nèi)部的錯(cuò)誤，也查找到模塊連接后產(chǎn)生的錯(cuò)誤。經(jīng)過(guò)測(cè)試，對(duì)系統(tǒng)產(chǎn)生錯(cuò)誤的地方進(jìn)行優(yōu)化、修改和完善，使得系統(tǒng)能夠?qū)崿F(xiàn)最初設(shè)計(jì)的基本功能。

總結(jié)與展望

本文針對(duì)醫(yī)保藥品集中采購(gòu)系統(tǒng)的特點(diǎn)和用戶需求，利用Node.js相關(guān)技術(shù)、Koa框架和等技術(shù)，通過(guò)詳細(xì)的需求分析、頁(yè)面設(shè)計(jì)和功能設(shè)計(jì)，實(shí)現(xiàn)了包括用戶模塊、藥品資訊模塊、采購(gòu)招標(biāo)模塊。公告模塊的前臺(tái)系統(tǒng)以及包括用戶管理模塊、采購(gòu)招標(biāo)管理模塊、企業(yè)投標(biāo)管理模塊的后臺(tái)系統(tǒng)。并添加了用戶的訪問(wèn)控制，建立了一個(gè)完整、健壯、安全穩(wěn)定的醫(yī)保藥品集中采購(gòu)系統(tǒng)。

由于時(shí)間限制和本人能力條件有限，還存在一些不足，今后也會(huì)出現(xiàn)許多新的開(kāi)發(fā)技術(shù)，未來(lái)還可以對(duì)程序做出如下改進(jìn)：

（1）優(yōu)化程序頁(yè)面，使頁(yè)面更加美觀且方便操作；

（2）優(yōu)化信息搜索功能，提供多條件選擇查詢搜索；

（3）優(yōu)化分類功能，提高分類的精準(zhǔn)度；

（4）進(jìn)一步提高使用程序的安全性，使其更加健壯；

（5）優(yōu)化數(shù)據(jù)和代碼，提升軟件效率，方便維護(hù)和擴(kuò)展。

參考文獻(xiàn)

[1]杜雯雯,徐偉.基于藥品采購(gòu)數(shù)據(jù)庫(kù)的醫(yī)療機(jī)構(gòu)藥品配備使用現(xiàn)狀研究：以江蘇省為例[J].中國(guó)現(xiàn)代應(yīng)用藥學(xué),2022,39(06):810-814.DOI:10.13748/j.cnki.issn1007-7693.2022.06.017.

[2].浙江省醫(yī)療保障局關(guān)于印發(fā)浙江省提升藥品集中采購(gòu)平臺(tái)功能推進(jìn)醫(yī)保藥品支付標(biāo)準(zhǔn)全覆蓋改革方案的通知[J].浙江省人民政府公報(bào),2020(14):32-35.

[3]張燕. 公共管理視角下內(nèi)蒙古醫(yī)保藥品帶量采購(gòu)政策執(zhí)行研究[D].內(nèi)蒙古大學(xué),2020.DOI:10.27224/d.cnki.gnmdu.2020.000286.

[4]孫明.軍隊(duì)醫(yī)院藥品采購(gòu)模式比較與現(xiàn)狀分析[J].藥學(xué)實(shí)踐雜志,2020,38(01):22-26.

[5]姜亦晨. 上海市醫(yī)保藥品“帶量采購(gòu)”政策執(zhí)行問(wèn)題研究[D].華東師范大學(xué),2019.DOI:10.27149/d.cnki.ghdsu.2019.000086.

[6]陳勇雋. 醫(yī)保藥品支付價(jià)格形成機(jī)制研究[D].上海交通大學(xué),2018.DOI:10.27307/d.cnki.gsjtu.2018.004305.

[7]金雨婷,楊帆,邵蓉.醫(yī)保藥品支付標(biāo)準(zhǔn)與采購(gòu)價(jià)的差額產(chǎn)生機(jī)制及其歸屬問(wèn)題研究[J].中國(guó)衛(wèi)生政策研究,2018,11(03):51-55.

[8]蔡雪妮.中國(guó)藥品集中采購(gòu)的演變以及與醫(yī)保支付的邏輯關(guān)系[J].中國(guó)衛(wèi)生政策研究,2018,10(06):6-12.

[9]劉桂圓. 藥品價(jià)格改革形勢(shì)下醫(yī)保藥品支付標(biāo)準(zhǔn)的研究[D].東南大學(xué),2018.

[10]武奇蓉. 上海藥品帶量采購(gòu)模式研究[D].上海交通大學(xué),2018.DOI:10.27307/d.cnki.gsjtu.2018.005867.

[11]王旭. 論我國(guó)藥品價(jià)格的法律規(guī)制[D].吉林大學(xué),2018.

[12]王雅楠,官海靜,劉國(guó)恩,孫利華.臺(tái)灣地區(qū)醫(yī)保藥品的采購(gòu)模式和支付價(jià)格[J].中國(guó)衛(wèi)生政策研究,2018,8(12):18-22.

[13].改革藥品價(jià)格形成機(jī)制[J].中國(guó)醫(yī)療保險(xiǎn),2018(07):8.

[14]通訊員 江玄勺. 非醫(yī)保藥品中標(biāo)價(jià)下降38.01%[N]. 博爾塔拉報(bào),2018-02-14(002).DOI:10.28011/n.cnki.nbetl.2008.000210.

致謝

時(shí)光飛逝，轉(zhuǎn)眼間我在學(xué)校的這些年生活即將結(jié)束，回顧這幾年的學(xué)習(xí)生活，收獲良多，既有幸福也有難過(guò)，學(xué)校生活的結(jié)束對(duì)于我來(lái)說(shuō)也是一個(gè)新的開(kāi)始。論文即將完成，在此，我心中有許多想要感謝的人。首先感謝我的導(dǎo)師，不僅在學(xué)習(xí)研究方面加以指導(dǎo)，也在生活和為人處世上給予幫助。還要感謝授課老師，你們嚴(yán)謹(jǐn)?shù)膶W(xué)術(shù)精神和積極向上的工作態(tài)度都在激勵(lì)我的成長(zhǎng)和進(jìn)步。感謝多年來(lái)一直生活在一起的室友，謝謝你們多年來(lái)的陪伴和照顧。最后，要感謝各位論文評(píng)審老師，感謝您們?cè)诎倜χ谐榭赵u(píng)閱本論文并給出寶貴的意見(jiàn)和建議。

免費(fèi)領(lǐng)取項(xiàng)目源碼，請(qǐng)關(guān)注點(diǎn)贊+私聊

總結(jié)

以上是生活随笔為你收集整理的（附源码）node医保药品集中采购平台-采购系统的设计与实现 毕业设计271542的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。