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

目 錄

一、緒論 5

(一) 研究背景與現狀 5

(二) 研究內容 5

二、開發工具及相關技術介紹 6

2.1 koa框架 3

2.2 Vue.js主要功能 4

2.3 MVVM模式介紹 4

2.4 B/S體系工作原理 5

2.5 Mysql數據庫 5

2.6 koa框架優點 5

2.7Node.jsScript 運行模式 5

三、系統分析 7

(一) 可行性分析 7

1. 經濟可行性 7

2. 技術可行性 7

3. 操作可行性 7

(二) 功能性需求分析 7

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

(四) 業務流程分析 11

四、系統設計 12

(一) 功能模塊設計 12

(二) 數據庫設計 14

1. 概念模型設計 14

2. 數據庫表設計 15

五、系統實現 17

(一) 用戶登錄的實現 18

(二) 系統前臺主要功能實現 18

(三) 系統后臺主要功能實現 21

六、系統測試 24

(一) 系統可靠性測試 24

(二) 系統功能性測試 24

(三) 系統合格性測試 25

(四) 測試結果 25

七、總結與展望 26

參考文獻 27

致謝 27

緒論

研究背景與現狀

自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。

2.2 Vue.js 主要功能：

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.

致謝

時光飛逝，轉眼間我在學校的這些年生活即將結束，回顧這幾年的學習生活，收獲良多，既有幸福也有難過，學校生活的結束對于我來說也是一個新的開始。論文即將完成，在此，我心中有許多想要感謝的人。首先感謝我的導師，不僅在學習研究方面加以指導，也在生活和為人處世上給予幫助。還要感謝授課老師，你們嚴謹的學術精神和積極向上的工作態度都在激勵我的成長和進步。感謝多年來一直生活在一起的室友，謝謝你們多年來的陪伴和照顧。最后，要感謝各位論文評審老師，感謝您們在百忙之中抽空評閱本論文并給出寶貴的意見和建議。

免費領取項目源碼，請關注點贊+私聊

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。