新型藥物臨床信息管理系統的設計與實現

發布時間：2023-07-18 09:39

第一章引言 1

1.1課題背景 1

1.2課題研究現狀及意義 1

1.2.1研究現狀 1

1.2.2研究意義 2

1.3課題任務 3

1.3. 1課題內容 3

1.3. 2 本人任務 3

1.4論文結構 4

1.5本章小結 5

第二章新型藥物臨床信息管理系統的相關技術 7

2.1系統整體架構設計 7

2.1. 1 B/S體系架構 7

2.1.2 MTV框架模式 8

2.2后臺框架 8

2.2. 1 Django 框架簡介 8

2.3前端框架 10

2.3.1 Vue. js 框架簡介 10

2.3.2 Element U1 簡介 10

2.4 My SQL 數據庫 10

2.5本章小結 11

第三章新型藥物臨床信息管理系統的需求分析 13

3.1系統用戶角色分析 13

3.1. 1醫生需求分析 13

3.1. 2院領導需求分析 15

3.1. 3項目辦成員需求分析 16

3.1.4審計員需求分析 18

3.2新型藥物臨床信息管理系統的功能性需求分析 19

3.2. 1患者治療情況記錄功能 19

3.2.2治療方案記錄功能 19

3.2.3合并用藥記錄功能 20

3.2.4不良反應記錄功能 20

3.2. 5趨勢分析功能 20

3.2.6提醒與警告功能 20

3.2. 7統計報表功能 20

3.2.8藥品管理功能 21

3.2.9用戶管理功能 21

3.2. 10單位管理功能 21

3.2. 11日志管理功能 21

3.3系統的非功能性需求 22

3. 3. 1系統響應時間 22

3. 3. 2系統可靠性 22

3. 3.3系統易用性 22

3.3. 4系統可擴展性 22

3.4本章小結 23

第四章新型藥物臨床信息管理系統的總體設計 25

4.1新型藥物臨床信息管理系統的設計原則 25

4.2新型藥物臨床信息管理系統的系統架構分析 25

4.2. 1新型藥物臨床信息管理系統的整體架構設計 25

4.2. 2新型藥物臨床信息管理系統的層次設計 26

4.3新型藥物臨床信息管理系統功能模塊設計 27

4.3.1登錄認證與個人信息管理模塊 28

4.3.2患者管理模塊 28

4.3. 3統計報表模塊 30

4.3.4藥品管理模塊 30

4.3.5用戶管理模塊 30

4.3.6單位管理模塊 31

4.3.7日志管理模塊 31

4.4數據模型設計 31

4.4. 1 E-R 圖 31

4.4. 2數據庫表的設計 32

4.5本章小結 38

第五章新型藥物臨床信息管理系統功能模塊的詳細設計與實現 39

5.1開發語言和框架選擇 39

5.2系統的詳細設計與實現 39

5.2. 1登錄與個人信息管理模塊的詳細設計與實現 39

5.2.2患者管理模塊的詳細設計與實現 42

5.2.3統計報表模塊的詳細設計與實現 45

5.2.4藥品管理模塊詳細設計與實現 46

5.2.5用戶管理模塊的詳細設計與實現 47

5.2. 6單位管理模塊的詳細設計與實現 48

5.2.7日志管理模塊的詳細設計與實現 49

5.3本章小結 50

第六章新型藥物臨床信息管理系統的系統測試 51

6.1新型藥物臨床信息管理系統的測試目標 51

6.2新型藥物臨床信息管理系統的測試方法 51

6.3新型藥物臨床信息管理系統的測試環境 52

6.4新型藥物臨床信息管理系統的功能測試 52

6.4. 1患者管理模塊功能性測試 52

6.4. 2統計報表模塊的功能性測試 57

6.5新型藥物臨床信息管理系統的非功能測試 59

6.5. 1性能測試 59

6.6測試結果分析 60

6.7本章小結 61

第七章結束語 63

7.1論文工作總結 63

7.2問題和展望 63

參考文獻 65

致謝 67

第一章引言

1.1課題背景

在社會經濟和科學技術飛快發展的今天，人類不斷對難以治愈的病癥進行研究和實驗；伴隨著醫療技術的不斷發展，許多曾經難以治愈的疾病不斷被克服, 醫療專家對新型藥物的不斷實驗使得各類新型藥品層出不窮。結核病是一種感染人數較多的疾病，由于結核菌的耐藥性不斷增加以及我國醫療條件較差等原因山，導致我國成為全球22個結核病高負擔國家之一，活動性肺結核病人數居世界第二位因此科研人員不斷研究治療結核病的新型藥物，而新型藥物從研發到正式生產，臨床試驗是一個必不可少的步驟⑶。

現在我國的藥物臨床試驗大多采用傳統的手工整理資料模式，該模式存在諸多弊端：醫療工作者在臨床試驗過程中由于手工記錄導致的信息缺失問題；不同醫生對結核病的研究信息和進展不能及時互通的原因導致的信息滯后問題；不同醫生對實驗過程中需要記錄的信息不能進行規范的記錄導致后續閱讀產生歧義的問題；以及手工記錄產生的藥物賬務不符的問題等等。這些弊端已不能滿足現有的臨床信息管理需求，所以研發一款新型藥物臨床信息管理系統在這種情況下的重要性溢于言表。

隨著信息技術的不斷發展，各行各業都在不斷的進行信息化，我們的思維和習慣都在不斷的變化中。與此同時，藥物臨床信息在線管理變得越來越普及，藥物臨床信息在線管理的方式具有很多傳統模式所不能具備的優點，它使得不同醫院可以及時獲取規范、準確的臨床試驗信息。在這樣迫切的需求下，設計并實現一個操作簡單、安全、穩定、并可以解決傳統手工模式所導致的信息缺失、不規范、以及信息滯后問題的藥物臨床信息管理系統變得勢在必行。

1.2課題研究現狀及意義

1.2.1研究現狀

新型藥物臨床信息管理系統是醫護人員及項目管理人員進行藥物供應與管理、用藥患者遴選、治療方案制定、患者治療管理及患者用藥監測、耐藥等方面的信息進行全程管理的系統，該系統的目標為保障患者用藥安全、提高患者治療效果。目前國外的部分醫院和科研機構所使用的藥物臨床系統的功能模塊主要包括患者住院信息管理，藥物存放情況管理，患者門診治療情況管理以及科研人員査

詢信息，患者電子處方管理，實驗器材管理等等功能模塊⑷。其中患者門診治療情況管理模塊和患者電子處方管理模塊主要實現在院的醫生記錄住院患者的病癥情況,記錄每日的試驗用藥情況，記錄患者每日的各項檢查信息等功能。使用信息化的技術將患者的各項檢測指標記錄在電子設備的方式稱為電子病歷新型藥物臨床信息管理系統就是類似電子病歷這樣的醫療信息化系統⑹,通過提取試驗過程中需要記錄的患者相關信息，并對這些信息進行整合,顯示在電腦或移動設備中，從而取代現有醫生在實驗過程中采用的傳統手工記錄方式。20世紀初，在美國成立了第一家臨床路徑委員會的醫療機構，隨后臨床路徑信息管理在澳大利亞、日本、英國等國家被推廣，并隨著臨床路徑信息管理的推廣，該種管理方式被應用至醫院的醫療服務行業中【7】。相對于國外對這項先進技術的掌握程度而言，我國的起步則顯得較為落后：目前，國內大多數醫院依舊采用人工抄寫的方式來記錄患者的監測信息，信息化建設并不完善；隨著試驗的推進，患者的各項監測指標信息和用藥信息會不斷發生變化，每當變化發生時，醫生都需要手動去修改患者的記錄，不僅浪費時間和人力還易出現信息記錄錯誤的情況；同時由于試驗參與人力的有限，會導致患者的信息更新不及時，試驗記錄不能隨時更新。傳統手工記錄方式的諸多弊端導致了臨床試驗的效率低下，并且使臨床信息管理工作的效果不盡人意。

1.2.2研究輙

新型藥物推向市場要經過新型藥物引入前的臨床試驗、新型藥物上市后的供應和使用、新型藥物使用監測和評價三個階段。其中新型藥物引入前的臨床試驗在這三個階段中尤為重要，在試驗過程中涉及到患者的全程管理，試驗數據的監控［8】，統計試驗數據并產生報表，管理藥品的費用信息，以及合作醫院的管理等等功能。而現在我國現有的純手工記錄方式會極大可能的產生試驗數據錯誤，導致難以挽回的損失；以及不同醫院試驗數據不能及時同步，試驗數據查詢費時導致的不必要工作量19】，這些都對結核新型藥物的試驗造成了阻礙。由于傳統管理模式出現的這些問題，使得臨床試驗信息化改革迫在眉睫［⑼。為了保證結核新藥規范合理的使用和項目的高質量實施，并且隨著醫院信息化建設的逐步深入，開發一款新型藥物臨床信息管理系統的任務被提上日程，這種新型藥物臨床信息管理系統主要是通過電子信息化的方式記錄患者的試驗情況，通過展示患者身體指標的變化趨勢來使得醫生能夠清晰的查看患者在治療過程中的治療狀況；綜上所述先進的新型藥物臨床信息管理系統是目前醫療服務行業信息化發展的主要趨勢。

本文以滿足北京某抗結核新藥引入和保護試點項目的新型藥物臨床信息管理系統的實際需求為起點，進行詳細完善的需求分析，從而完成新型藥物臨床信息管理系統的開發工作，形成可以實時監控，實時記錄，實時調用，實時查詢，及時回訪的統一管理調度的新型藥物臨床信息管理系統。各醫院結核病患者的醫療信息在新型藥物臨床信息管理系統中得到匯總和整理，為醫生、院領導、項目辦成員和審計員提供服務，切實解決在臨床試驗過程中涉及信息管理的問題，這是新型藥物臨床信息管理系統的開發目的，也是其最重要的任務。

1.3課題任務

1.3.1課題內容

雖然目前有很多優秀的新型藥物臨床信息管理系統，但是大多數醫院還是會選擇自己開發一款屬于自己的新型藥物臨床信息管理系統，這樣不僅可以滿足自己的特定需求，還可以自主掌控系統的升級和功能的迭代，使得藥物臨床信息管理系統更貼近醫院自身的需求，還因為大型的新型藥物臨床試驗的需求是面向各個不同藥物臨床試驗的，提供的功能也是比較完善的⑴】，這是它的優點所隹；但是目前很多醫院的需求有著很大的差異，大型的新型藥物臨床信息管理系統面向的范圍太廣，不能很好的滿足醫院的個性化要求，所以大型的新型藥物臨床信息管理系統并不實用。基于上述原因，開發一款基于醫院不同臨床試驗要求的中小型新型藥物臨床信息管理系統不僅可以更好的滿足醫院的個性化要求，也可以根據實際的情況進行系統的擴展或升級，同時降低使用成本，具有很好的可擴展性和實用性。

通過對于上述問題的分析，本文將采用Python語言以及Django框架對新型藥物臨床信息管理系統進行開發，同時采用Vue.js框架和Element UI對新型藥物臨床信息管理系統的前端界面進行設計和開發，本系統將會進行充分的用戶需求分析，然后進行詳細的設計：在系統需求分析階段，通過對用戶的需求進行分析和整理，以及系統用戶角色的劃分將系統的主要功能劃分為登錄認證與個人信息管理功能，患者管理功能、統計報表功能、用戶管理、單位管理、藥品管理和日志管理等功能，同時對于系統的非功能性需求進行分析。在系統的設計階段，將系統依據各個子功能的不同劃分為不同的子模塊，再依據每個子功能的需求進行詳細的分析和設計，在詳細設計完成之后，使用合適的計算機技術對各個需求進行代碼的實現，并對開發過程中遇到的問題進行追蹤和解決；在系統的功能全部實現后進行系統測試，測試系統是否能滿足用戶的需求。

1.3.2本人任務

通過分析目前各種新型藥物臨床信息管理系統的利弊,抽取系統需要開發的功能，并按照不同角色的不同需求進行相應的分析和設計，制定本系統的需求文檔，再依據需求文檔中的設計進行用例分析，將系統的不同模塊進行分離，對各個模塊進行總體設計和數據模型的設計；在分析階段完成后，針對系統的特征選擇合適的系統架構和計算機技術對系統進行詳細設計和實現。

在軟件系統的開發中，本人釆用Django^ Vue.js> Element UI等計算機技術進行系統的后臺的設計與開發，以及完成系統登錄認證與個人信息管理模塊、患者管理模塊、統計報表模塊、藥品管理模塊、用戶管理模塊、單位管理模塊和日志管理模塊這些系統主要功能模塊的開發任務。

1.4論文結構

本論文主要通過對新型藥物臨床信息管理系統的開發背景和開發意義進行考察，對本系統的需求分析，整體設計，各功能模塊的詳細設計和實現以及系統測試等方面進行敘述。

第一章引言：本章主要介紹了本課題的研究背景，研究現狀和意義，以及對本課題的內容和本人在項目中做的工作進行詳細介紹。

第二章新型藥物臨床信息管理系統的相關技術：本章主要闡述了在本系統中使用的計算機技術，并對這些技術進行詳細介紹。

第三章新型藥物臨床信息管理系統的需求分析：本章主要從用戶角色上對新型藥物臨床信息管理系統進行需求分析和設計，對系統的功能性和非功能性需求進行具體描述，并且通過圖表的方式直觀的展示用戶對系統的需求。

第四章新型藥物臨床信息管理系統的總體設計：本章根據上一章進行的需求分析來對系統的功能模塊進行劃分，闡述本系統的設計原則、系統架構、各模塊的總體設計，以及對本系統涉及的數據模型進行總體設計。

第五章新型藥物臨床信息管理系統的詳細設計與實現：本章根據系統的總體設計對系統的各個功能進行了代碼的實現，通過時序圖以及流程圖來對實現的過程進行了闡述。

第六章新型藥物臨床信息管理系統的系統測試：本章通過列舉部分測試用例來對本系統進行主要的功能測試，并對于系統的性能測試進行介紹。

第七章結束語：本章總結論文的收獲，對于在開發過程中遇到的問題和系統現有的問題進行分析并提出升級措施，對系統接下來的系統迭代進行了規劃和展望。

1.5本章小結

本章主要分析新型藥物臨床信息管理系統的研究背景和研究意義，并對課題的內容進行分析歸納，明確了本人在課題中所承擔的任務，在本章的最后對論文的整體結構劃分進行了詳細介紹，提高了論文的可讀性。

北京郵電大學碩士學位論文

第二章新型藥物臨床信息管理系統的相關技術

從新型藥物臨床信息管理系統的實際需求出發，在開發過程中選用B/S體系架構作為系統的整體架構，Django框架為系統的后臺開發框架，Vue.js框架和 Element UI為前端開發框架、以及My SQL數據庫技術；本章將介紹系統開發過程中涉及到的計算機技術，并分析這些技術的優缺點。

2.1系統整體架構設計

2.1.1B/S體系榊

新型藥物臨床信息管理系統選取了 B/S (Browser/Server)體系架構作為系統的整體架構，即瀏覽器和服務器體系架構。它是通過對C/S (Client/Server)架構進行改進然后產生的不同種類的體系架構。在B/S架構下，用戶僅需下載瀏覽器即可通過網絡訪問服務器系統，這樣使得前端(Browser)的業務邏輯處理變得很簡沾，同時主要的業務邏輯和絕大部分的邏輯處理都在服務器端(Server)實現, 形成一層結構，如下圖2-1所示

圖2-1 B/S網絡架構圖

B/S架構具有以下三個重要的特點：(1)維護成本小和后續升級簡單。在 C/S架構中，當用戶的需求發生變更時，不僅需要對服務端的系統進行功能的迭代，還需要對每個操作系統的客戶端系統進行開發。但是基于B/S架構的系統在功能的迭代中只需對服務器端的系統進行修改，減少了大量的開發工作(2) 使用方便。在系統開發完成石，系統將投入使用，用戶在使用基于B/S架構的軟件系統時，只要在客戶端安裝任意一款瀏覽器，并且可以上網，這樣就無需安裝其他軟件即可訪問該系統。（3）可擴展較強。相對于C/S架構需要開發不同操作系統對應的相應版本的客戶端系統而言，基于B/S架構的系統只需完成服務端系統的開發即可，這樣在系統日后的功能迭代中，將減少大量的開發任務，從而提高系統的可擴展性［⑶。

2.1.2 MTV框架模式

MTV框架模式可能很多人都不熟悉這個名詞，所以先來簡單介紹下類似的 MVC模式：MVC模式是現在WEB服務器開發過程中受很多程序員喜愛的一種框架模式，M、V、C簡而言之就是把Web應用分為模型層（Model）、控制器層（Controller）、視圖層（View）這樣三層結構。同理而言，Django的MTV 框架模式本質上是和MVC框架模式是一樣的，同樣是為了完成系統各組件之間的松耦合關系要求，但是在各層的定義上同MVC框架模式有所不同【⑷。Django 的M、T、V分別是：M是代表模型層（Model）主要負責業務對象和數據對象之間的映射工作，T是代表模板（Template）主要負責將頁面以可以和用戶交互的形式展現給用戶，V是代表視圖（View）主要負責的是業務邏輯的處理，根據用戶的不同輸入來選擇相對應的Model層或Template層來進行調用。因為 MTV框架模式的松耦合特性，使得由Django框架驅動的Web應用的各層都具有獨立的功能，各層都可以單獨更改而不影響其他層的使用。MTV三層框架結構如下圖2-2所示：

圖2-2 MTV框架三層關系圖

2.2后臺框架

2.2.1Django框架簡介

隨著Python語言的不斷發展，現在已經是很多公司開發Web應用采用的主要語言，由此催生了 Python的Web框架，例如Django> Tornado> Flask等多種 Python的Web框架。本課題采用Django作為系統的后臺框架，主要原因是Django 同其他Web框架相比，它的優勢為：框架完整并且Django本身繼承了用來操控數據庫的ORM,不用額外接入SQL Alchemy等ORM框架，同時Django還具有模型綁定、模板引擎、緩存、Session等功能。Django原生還提供了很多的功能組件，當業務系統需要時可直接引用，減少二次開發的成本。

Django的特點是：（1）功能齊全、組件完整：Django本身自帶了很多的常用工具，例如分頁功能、權限管理等，非常適合快速開發Web應用2】。（2）完備的文檔：Django在經過數年的開發和使用，在不斷的完善過程中產生了眾多的實踐案例和齊全的在線參考文檔，當在開發過程遇到問題時，開發者可以搜索在線文檔來找到解決問題的方法。（3）完善的數據庫訪問組件：Django的Model 層本身已經集成了數據庫的ORM組件，使得開發者在不熟悉SQL語言的前提下可以對數據庫進行操作。（4）松耦合的設計理念：Django先進的APP設計理念將系統設計為可拔插的APP組件【⑹，是非常先進的設計思想，因此對于某個不需要的APP,可直接將其刪除而不影響系統的整體功能。（5）詳細的Debug 功能：在開發過程中，難免會遇到很多問題，此時詳細的Debug功能會使得查找問題和解決問題變得快速和準確。Django的處理邏輯如下圖2-3所示：

HTTP

圖2-3 Django處理邏輯圖

2.3前端框架

2.3.1Vue.js框架簡介

Vue是一套用于搭建同用戶交互界面的漸進式框架，同現在流行的其他前端框架相比較，Vue被設計為可以自底向上逐層開發的應用。對于Vue的核心庫來講，Vue的核心庫只關心前端界面的開發，這個特點導致了 Vue不僅易于上手，同時還便于同第三方庫或者現有的項目的整合應用。另一方面，如果使用Vue 與現有的其他工具鏈或者各種Vue支持的類庫結合使用時,Vue也完全可以負責給復雜的頁面應用提供頁面驅動［⑺。同時Vue還是一個單頁面的應用，這樣如果頁面的局部需要刷新時，不需要每次跳轉頁面都重新加載所有的數據和Dom, 這樣會節約很多加載時間、提升了用戶的訪問速度以及優化了用戶的交互體驗。同其他優秀的前端框架一樣，Vue還提供了完善了的第三方UI庫，可以節約較大的開發成本。

2.3.2Element UI 簡介

Element UI是一個第三方的UI庫，它不依賴于Vue存在，但是卻是現在同 Vue配合做Web項目開發的一個非常優秀的UI框架。

Element UI的特點主要有以下四點：（1）高度的一致性：Element UI的一致性主要分為兩點，一是同現實生活保持一致，Element UI與現實生活的流程、邏輯保持一致，同時遵守用戶常用的語言和邏輯；二是在界面中保持一致， Element UI所有的元素和結構設計保持一致，例如：設計樣例，圖標和文字、組成元素的位置等。（2）及時反饋：反饋是指控制反饋和頁面反饋，控制反饋是通過頁面的設計樣式和頁面的交互特效來讓用戶清楚的知道自己的操作；頁面反饋是指用戶在操作結束后，頁面可以通過改變頁面元素來向用戶清晰的展現當前的頁面狀態。（3）使用效率較高：Element UI對開發流程進行簡化，設計出簡單直觀的操作流程，且語言表達清楚，并且表達的意思非常準確，這樣可以使用戶可以快速理解頁面操作并做出選擇；Element UI的界面簡潔直觀，可以讓用戶快速進行識別而不是對剛才的操作進行回想，這樣可以減少用戶的記憶量。（4）可控性較強：界面可以依據現有的場景來對用戶進行提示和操作指南，但是不能代替用戶做出選擇；同時用戶在界面操作過程中可以自由的選擇鍵入、撤銷、回退操作和結束頁面現有的操作等。

2.4 My SQL數據庫

My SQL數據庫是一款關系型數據庫管理系統，因其訪問速度快，是現在主流Web開發所常使用的數據庫之一〔⑹。My SQL數據庫的優點有以下三點：（1） My SQL數據庫相比較于Oracle數據庫而言，My SQL數據庫體積小、開源、且反應速度快，這樣會降低開發成本，并且該數據庫使用SQL語言，使得多數程序員可以快速上手。（2） My SQL數據庫是跨系統、跨平臺的一款關系型數據庫，在不同的系統上對多種語言都有良好的支持，例如：C++、Python、Java以及PHP等語言。（3） MySQL數據庫對大型數據量也有良好的支撐，對擁有大數量記錄的數據倉庫也可以提供支持1切。

2.5本章小結

本章介紹了新型藥物臨床信息管理系統在開發過程中使用的相關技術，通過對每種技術的優缺點和系統本身的特點進行分析整理，系統的體系架構最終選擇了 B/S架構作為整體架構，并選擇Django作為后臺開發的框架，數據庫選擇 My SQL數據庫，前端釆用Vue.js框架和Element UI技術。

第三章新型藥物臨床信息管理系統的需求分析

軟件系統在開發前，首先需要進行嚴謹的、細致的需求分析，在這個過程中, 需要準確的理解用戶的需求以及軟件系統的功能、性能和可靠性等方面的具體需求;需求分析工作做的詳細完善才可以進行其他后續工作，如果在需求分析階段, 不能明確用戶的需求，將會在后續的開發過程中直接導致開發的系統軟件不滿足用戶需求的大問題，甚至直接導致軟件系統不能按時交付的嚴重后果，所以需要認真對待需求分析。按照項目具體的臨床信息管理的實際需求進行功能性需求分析和非功能性需求分析，并以此為基礎介紹了新型藥物臨床信息管理系統自身的需求分析是本章的主要內容。

3.1系統用戶角色分析

對新型藥物臨床信息管理系統進行用戶分析后，將本系統的用戶分為四種類型：醫生、院領導、項目辦成員和審計員，醫生主要使用新型藥物臨床信息管理系統進行患者的管理，記錄和查看患者的醫療記錄、治療方案和不良反應等，以及對實驗藥品的管理；院領導即醫院負責人主要使用本系統進行患者的管理，查看患者的醫療記錄、治療方案和不良反應等，實驗藥品的管理，對患者試驗用藥的查看，以及對參與試驗的工作入員的用戶管理；項目辦成員主要使用本系統進行患者的管理，查看患者的醫療記錄、治療方案和不良反應等，實驗藥品的管理，對患者試驗用藥的查看，參與試驗的工作人員的用戶管理，以及參與試驗單位的管理；審計員則可使用本系統的所有功能，擁有系統的最高權限。

3.1.1醫生需求分析

新型藥物臨床信息管理系統是一個對結核試驗用藥過程信息記錄的軟件系統，醫生是本系統的主要用戶，主要滿足醫生線上記錄試驗過程信息的需求，通過本系統醫生可以對參與試驗的患者進行管理，例如新增參與試驗的患者以及在工作臺顯示近期操作患者以及查看提醒和警告消息。同時醫生還需要在試驗過程中及時記錄對每位患者使用的試驗性藥物，并對每位患者檢測的各項身體指標進行記錄，例如記錄患者的血常規信息等；在階段試驗用藥之后，醫生可以查看在用藥期間，患者的某一指標的變化情況，并通過該指標的趨勢情況來判斷用藥是否有效。為了讓醫生清楚的了解各醫院藥品的發放與結存情況，系統還需向醫生用戶提供藥品管理功能：包括錄入藥品發放與盤點的流水記錄；同時系統還需要向醫生提供査看統計報表的功能，以供醫生査看患者的藥物使用情況統計、隨訪情況統計、治療轉歸情況統計以及不良反應統計情況。通過以上描述，下圖3-1

展示了新型藥物臨床信息管理系統的醫生類需求用例:

圖3-1醫生類需求用例圖

依據上圖，下表3-1描述了醫生用例圖中錄入患者身體指標中記錄患者血常規信息的用例：

表3-1記錄患者的血常規信息的用例描述

用例名稱記錄患者的血常規信息

用例標識號 UseCase 1

參與者醫生A

簡要說明醫生A對患者在某一階段的藥物臨床試驗過程中患者的血常規信息進行錄入。

前置條件醫生A在輸入正確的用戶名和密碼后成功登錄，并正確展示系

統界面

基本事件流 (1)醫生A點擊新型藥物臨床信息管理系統的患者管理功能

(2)系統展示管理功能界面

(3)醫生對所需錄入血常規信息的患者點擊處理

(4)系統展示該患者的操作界面

(5)醫生點擊醫療記錄按鈕

(6)系統展示醫療記錄操作界面

(7)醫生選擇就診日期，在項目中選擇需要記錄的血常規表單，并點擊右側編輯按鈕，在輸入框中填寫需要記錄的信息，點擊保存

(8)用例結束

續上表

其他事件流醫生A在填寫完該表單后，不點擊保存，點擊系統的登出按鈕，退出系統

異常事件流系統沒有將醫生A記錄的信息正確的保存在數據庫中

后置條件系統將用戶記錄的信息正確的保存在數據庫中

3.1.2院領導需求分析

院領導作為項目的管理人員，也同醫生用戶一樣，可以與參與試驗的患者進行管理，例如新增參與試驗的患者和刪除已經退出試驗的患者等。在進入系統后，向院領導展示本院患者一覽；同時院領導也可查看醫生在試驗過程中對每位患者使用的試驗性藥物的記錄，并且院領導也可査看每位患者的各項身體指標的具體值以及每個身體指標的階段趨勢和統計報表，并對某患者現有癥狀可能引發的危險對該患者對應的醫生發出提醒或警告消息。院領導同醫生用戶不同的是院領導還可以對參與試驗的工作人員即參與試驗的醫生進行管理，例如新增參與試驗的醫生，刪除退出試驗的醫生、查詢現在參與試驗的醫生以及對現有參與試驗醫生的個人信息進行修改。通過以上描述，下圖3-2展示了新型藥物臨床信息管理系

統的院領導類需求用例:

圖3-2院領導類需求用例圖

依據上圖，下表3-2主要描述了用例圖中本院醫生管理中的添加試驗醫生用例:

表3-2添加試驗醫生用例描述

用例名稱添加試驗醫生

用例標識號 UseCase2

參與者院領導B

簡要說明院領導B將新參與試驗的醫生添加至系統

前置條件院領導B在輸入正確的用戶名和密碼后成功登錄，并正確展示系統界面

基本事件流 (1)院領導B點擊新型藥物臨床信息管理系統的用戶管理功能

(2)系統跳轉用戶管理界面，界面顯示全部參與試驗的醫生的基本信息

(3)院領導B點擊右上角的添加按鈕

(4)系統彈出需要填寫信息的表單

(5)院領導B填寫相應表單，點擊確定

(6)用例結束

其他事件流院領導B填寫相應表單后點擊取消，系統不保存該次填寫的信息。

異常事件流系統沒有將院領導B記錄的信息正確的保存在數據庫中

后置條件系統將用戶記錄的信息正確的保存在數據庫中

3.1.3項目辦成員需求分析

項目辦成員作為整個項目的負責人，可以查看參與本項目的全部患者信息，以及查看在項目實施過程中，本項目參與患者的藥物使用情況、治療轉歸情況、不良反應統計等。當項目辦成員擁有以上功能時，該成員即可隨時掌握參與試驗患者的情況控制患者的參與與否，控制項目的進度，對某患者現有癥狀可能引發的危險對該患者對應的醫生發出提醒或警告。同時作為項目負責人，還需要對參與試驗的醫院單位進行管理。通過以上描述，下圖3-3展示了新型藥物臨床信息管理系統的項目辦成員類需求用例：

圖3-3項目辦成員類需求用例圖

依據上圖，表3?3主要描述了用例圖中的參與本項目的醫院單位管理中的添加試驗單位用例。

表3-3添加試驗單位用例描述

用例名稱添加試驗單位

用例標識號 UseCase3

參與者項目辦成員C

簡耍說明項目辦成員C在項目中可以隨時新增參與試驗的醫院

前置條件項目辦成員C在輸入正確的用戶名和密碼后成功登錄，并正確展示系統界面

基本事件流 (1)項目辦成員C點擊新型藥物臨床信息管理系統的單位管理功能

(2)系統跳轉單位管理功能界面，頁面展示現有參與試驗的單位的基本信息情況

(3)項目辦成員C點擊右上角添加按鈕

(4)系統界面彈出所需填寫的表單

(5)項目辦成員C填寫表單并點擊確定

(6)用例結束

其他事件流用戶填寫表單后，不點擊確認，點擊取消按鈕

異常事件流系統沒有將項目辦成員C記錄的信息正確的保存在數據庫中

后置條件系統將用戶記錄的信息正確的保存在數據庫中

3.1.4審計員需求分析

審計員是本系統最高級別的用戶，主要提供給審計人員使用，為了保證審計員可以隨時查看參與項目的患者的各項醫療情況，以及查看醫生、院領導、項目辦成員在系統的操作記錄，審計員擁有整個系統的全部權限，例如查看所有患者的基本信息和醫療情況，同時審計員還可以向醫生、院領導、項目辦成員發送提醒和警告消息；也可查看院領導和項目辦成員給醫生發送的提醒和警告消息；審計員還可以對使用系統的用戶進行管理，例如用戶的新增、用戶的刪除、用戶的查詢以及用戶的修改；因為審計員需要查看不同角色用戶在系統的操作記錄，還需要擁有日志管理的功能，可以查看并查找用戶的登錄日志，以及修改記錄的日志，用來在醫療數據發生變化時能夠及時找到進行該操作的用戶。通過以上描述, 下圖3-4展示了新型藥物臨床信息管理系統的審計員類需求用例：

圖3-4審計員類需求用例圖

依據上圖，表3-4主要描述了用例圖中的查看指定類型操作日志中的查看登錄日志記錄用例。

表3-4查看登錄日志記錄用例描述

用例名稱查看登錄日志記錄

用例標識號 UseCase4

參與者審計員D

簡要說明審計員D在日志管理界面，選擇登錄日志進行查看

前置條件審計員D在輸入正確的用戶名和密碼后成功登錄，并正確展示系統界面

續上表

基本事件流 (1)審計員D點擊日志管理功能

(2)系統頁面默認分頁展示近一個月的登錄日志記錄的信息

(3)用例結束

其他事件流審計員D選擇其他類型的日志例如刪除日志進行展示

異常事件流系統不能正確的默認展示登錄日志

后置條件系統能夠準確篩選出登錄日志記錄，并對這些登錄日志采用分頁的方式進行展示

3.2新型藥物臨床信息管理系統的功能性需求分析

及時規范的記錄患者的用藥和各項身體指標是新型藥物臨床信息管理系統的主要目的，所以系統的主要需求是要實現患者的全程管理，及時規范的記錄參與試驗的患者的每一項監測信息，同時可對某一患者某一用藥階段的某一身體指標進行報表展示。整個系統的主要功能性需求包括患者治療情況記錄、治療方案記錄、合并用藥記錄、不良反應記錄、趨勢分析、統計報表、藥品管理、單位管理及日志管理功能。

3.2.1患者治療況記錄功能

新型藥物臨床信息管理系統主要目的是對患者的臨床信息進行記錄，患者治療情況記錄功能是整個新型藥物臨床信息管理系統的核心功能，在對某一患者的治療情況進行記錄時需要完成該患者的治療階段的選擇、項目的選擇還有入選排除表、隨訪表、各種檢查單的填寫。醫生在填寫該患者的某項身體指標之前首先需要對試驗階段進行選擇，再選擇需要填寫哪個表或者哪項檢查，對系統彈出的該項表單中的具體信息進行填寫。

3.2.2治療方案辟功能

治療方案記錄功能的主要目的是供醫生查看、添加該患者的治療方案，以便了解該患者治療了幾個周期，在治療過程中使用了哪些藥物，為日后的治療提供依據。針對以上目的，該功能首先需向醫生展示患者的全部治療周期(默認為 96周，如患者增長試驗治療周期，可手動添加)，以及展示在每種藥物在患者的哪個治療周期進行使用。同時在系統界面還需展示該種藥物的藥物名稱、給藥途徑、每日總量、用藥頻率、開始日期、結束日期的信息以及提供對該條記錄的操作功能。

3.2.3合并用藥記錄功能

合并用藥記錄功能主要目的是向醫生展示該患者在使用除醫生開具的藥物之外的其他用藥的詳細信息。如果患者在試驗過程出現不良反應，則有可能是因為患者的合并用藥引起的，此時醫生需要及時的査找在這一試驗階段患者的合并用藥信息，來分析不良反應出現的原因并解決。

3.2.4不良反應記錄功能

新型藥物在試驗過程中會針對患者的發病組織進行不同的藥物使用，在用藥過程中需要對患者定時進行各項身體指標的檢測，觀察用藥的有效性，總結試驗結果，提岀有意義的有效藥物報告。在臨床試驗過程中，患者可能會出現不良反應，當該情況出現時，該患者的治療醫生應該及時在系統進行記錄。同時應該在后臺提供不良反應上報的接口，實時監控在試驗過程中出現的不良反應；系統在接收到醫生提交的不良反應信息后，將立刻自動向項目辦指定負責人提供的接收不良反應的電子郵箱發送不良反應上報郵件，郵件內容為醫生填寫的該條不良信息的全部內容。該指定負責人在收到該郵件后需要對郵件進行回復（即點擊確認鏈接），以保證郵件被正確接受。系統發送郵件五分鐘內如果未收到該指定負責人的回復，將再次發送該項不良事件，并等待接受該指定負責人的回復。如果重發五次仍得不到該指定負責人的回復，系統將給該指定負責人提供的手機號碼發送提醒短信。通過以上流程保證試驗過程中出現的不良反應一定會通知到項目辦的負責人，不會遺漏患者出現的不良反應。

3.2.5趨勢分析功能

患者在用使用某種藥物的階段中，身體各項指標在每次隨訪時都會進行檢查并記錄，參與試驗的醫生在拿到患者這個用藥階段的全部指標報告時沒有辦法直觀的觀察出這種藥物對患者的有效性，所以系統應該向用戶提供趨勢分析功能，能夠讓醫生可以選擇指定患者查看該患者在治療過程中的血常規分析、血壓分析、結核菌藥敏分析、肝功能分析、腎功能分析等形成的曲線圖或柱狀圖。

3.2.6提震與警告功能

在項目進行的過程中院領導和項目辦會對本醫院或者本項目參與的患者進行不定期的查看，包括醫生給患者制定的治療方案信息、患者出現的不良反應信息、患者的用藥情況信息等信息的查看，在查看的過程中如果發現患者的某項身體指標變化可能導致嚴重結果，需要及時的向醫生發送提醒或者警告信息。同時審計員作為系統的審計人員，會定期的查看系統中記錄的各項信息，如果發現某項信息存在問題，將需要對該用戶發送提醒消息。

3.2.7統計報表功能

該功能主要是向用戶展示患者藥物使用情況、患者隨訪情況統計、患者治療轉歸情況統計以及不良反應統計四種類型的統計報表。針對患者藥物使用情況統計應該展示各種藥物的用藥分布情況，讓醫生能直觀的查看到哪種藥物在患者身上的使用頻次最高從而分析其有效性。患者隨訪情況統計則直觀展示單位隨訪率、是否完成隨訪、未完成隨訪原因、以及隨訪類型；項目辦成員和院領導在查看項目整體的隨訪率或者本醫院的隨訪率時可以直觀的觀測到醫生的隨訪情況，便于項目的管理。患者的治療轉歸情況則根據本項目的測試目標直觀的向醫生展示患者的痰菌陰轉率及其他治療轉愈情況。不良反應情況則應該展示不良事件嚴重程度分級統計、嚴重不良事件類型統計、不良事件結局統計、不良事件名稱統計以及提供點擊該條不良反應記錄可以跳轉去該患者的患者管理頁面的功能。

3.2.8藥品管理功能

藥品管理功能應該包括向用戶展示當前用戶所在醫院（項目辦成員在此界面展示所有參與項目的醫院）的藥品盤點數據：包括藥品發放量以及藥品銷毀量等藥品的盤點數據；還應該提供給醫生錄入藥品的盤點信息的功能，并在當前登錄的醫生操作完成后在頁面展示此次的操作記錄，方便后續查看；本功能的主要目的是讓用戶清楚的了解各醫院藥品的發放與結存情況。

3.2.9用戶管理功能

本項目由不同醫院的不同醫生在臨床試驗中對患者的臨床試驗信息進行記錄，每個參與項目的醫生分屬于不同的醫院，各個醫院的院領導會對本醫院的醫生進行管理，例如新增參與試驗的醫生和刪除退出試驗的醫生，所以本系統應該提供用戶管理的功能，來讓院領導對本醫院參與試驗項目的醫生進行管理。

3.2.10單位管理功能

項目開始時項目辦會組織部分醫院參與到該項目中，在項目實施期間，不斷會有新的醫院加入項目，也會有部分醫院退出該項目，所以系統應該向項目辦成員提供單位管理功能，以便項目辦成員能夠對單位醫院進行增加、刪除、查詢、修改等操作。

3.2.11日志管理功能

日志管理功能主要是提供給審計員的功能，審計員使用該功能可以清楚的查看各個賬號對系統的操作記錄。日志應該包括登錄日志、數據提交日志、數據修改日志、以及數據刪除日志。審計員通過選擇日志類型和輸入日志關鍵字來篩選指定日志進行查看，如果出現用戶在操作過程中發生惡意刪除信息的情況，審計員也可以通過日志管理管理功能快速定位到用戶，挽救損失。

3.3系統的非功能性播求

系統的非功能性需求是指在除了完成系統的功能性需求，系統還需完成的其他指標；例如系統同用戶交互時的從用戶發出請求到系統做出相應的時間，系統能否安全、穩定的持續運行，系統在后期的可維護性，系統在后續需求增加時的可擴展性等這些指標；通過這些對這些指標的制定，來對本系統進行非功能性的需求分析。

3.3.1系統響應時間

系統響應時間為用戶在瀏覽器中點擊一個界面，到系統做出響應，將該界面所需要的數據回傳給瀏覽器，瀏覽器將頁面的元素和數據加載完成后并展示給用戶，這整個過程所需的時間為系統響應時間；為保證同用戶的友好交互，用戶在向新型藥物臨床信息管理系統發送請求時，響應時間應該不超過5秒，如果超過 5秒，用戶會感受到明顯的系統延遲，降低同用戶交互的友好性。

3.3.2系統可靠性

新型藥物的臨床試驗是一個漫長的過程，而本系統又是貫穿整個藥物臨床實驗中的，需要在整個過程中準確的記錄患者的各項監測指標，并準確的展示出醫生想要查看的報表信息；所以對新型藥物臨床信息管理系統的可靠性需要達到一個較高的標準；這就使得我們系統的設計過程中，需要將系統的可靠性作為技術選擇的一個考量標準，在系統開發完成后，也就是系統的運行時，能夠安全可靠的運行。在向項目辦咨詢項目現有參與項目的醫院數，及對應的醫生數并針對項目的實際使用情況而言，最大峰值為每小時會有60個臨床試驗的患者的信息需要記錄，即60個醫生需要同時登錄系統對患者的監測項目進行記錄；同時由于參與項目的醫生大約有80人左右，所以需要模擬100人同時登錄系統且100人同時向系統發送請求或進行查詢。在性能測試階段，需要保證系統可滿足上述性能需求。

3.3.3系統易用性

醫生、院領導以及項目辦成員作為新型藥物臨床信息管理系統的主要用戶，他們不具有計算機從業人員所擁有的計算機知識，所以系統需要具有較高的易用性。系統界面的設計需要簡單易用、簡潔大方，使用戶在初次使用本系統時能夠快速找到自己需要使用的相應功能。

3.3.4系統可擴展性

新型藥物臨床信息管理系統需要貫穿整個藥物臨床試驗，要隨著醫院的試驗過程中不斷變化的需求來增加相應的系統功能。為了保證日后系統能夠高效快捷的進行系統功能的迭代，所以在系統的設計階段和技術選擇的階段，系統的可擴展性要作為一個重要的考量指標；通過完善的設計和謹慎的選擇，保證系統能夠完成日后的功能迭代需求。

3.4本章小結

本章對新型藥物臨床信息管理系統進行了用戶角色的劃分，并對系統進行了功能性的需求分析，將系統劃分為患者治療情況記錄、治療方案記錄、合并用藥記錄、不良反應記錄、趨勢分析、統計報表、藥品管理、單位管理及日志管理多個功能。除了功能性需求外，本章還通過對系統的相應時間、可靠性、易用性以及可擴展性的介紹來對系統進行了非功能性的需求分析。

第四章新型藥物臨床信息管理系統的總體設計

系統的總體設計作為軟件開發過程中的中間環節，需要準確的將需求分析過程中所產生的結果進行轉換，變成新型藥物臨床信息管理系統開發所必須的數據模型和系統結構，需要站在全局的角度把握本系統整體的軟件開發過程。

4.1新型藥物臨床信息管理系統的設計原則

新型藥物臨床信息管理系統作為醫院內部使用的中小型軟件系統，在對系統的設計過程中，首先需要考慮的是系統的可擴展性。因為本系統是在整個臨床試驗過程中一直使用的系統，隨著試驗的推進，患者需要檢測的身體指標會不斷增多，也就是醫生在系統中需要記錄的信息也會隨著增長；同時醫生可能還需要對某一指標增加統計報表圖等等需求，為了滿足需求的不斷增加，系統將不斷進行迭代，這就需要系統的可擴展性較好。其次就是系統的易用性；系統的主要使用用戶是醫生、院領導和項目辦成員，這些用戶并非是計算機從業人員，對從未使用過的軟件系統不能很快速的接受并掌握；所以系統界面的設計應該以簡潔為主，方便用戶在首次登錄系統后，能夠快速了解系統提供的功能；同時在每個功能模塊上方應具有提示性語句，這樣使用戶能對這些功能該如何使用能夠快速了解并進行使用。最后還需要考慮的是系統的穩定性，作為一個信息管理系統，在本系統上存儲著該項目的所有參與患者的試驗數據，如果系統不能穩定的運行，可能會導致醫生隨訪時需要對患者的檢測指標進行記錄時，出現系統故障不能訪問的情況，這樣會導致數據的不完整性和延遲，甚至還會出現由丁系統不能穩定的運行造成數據缺失的大問題。綜上所述，系統在設計過程中應該以良好的可擴展性，較高的易用性，以及優秀的穩定性為系統的設計原則。

4.2新型藥物臨床信息管理系統的系統架構分析

4.2.1新型藥物臨床信息管理系統的整體架構設計

新型藥物臨床信息管理系統是一個供醫生、院領導、項目辦成員和審計員使用的開放式系統，軟件系統提供的各個功能是為了能夠讓研究人員在臨床試驗過程中準確、規范、有效的記錄試驗數據從而驗證新研發的藥物的安全和有效性。由于在試驗過程中需求可能會不斷增加，遂需要設計一款高內聚低耦合的軟件系統，本系統通過選擇三層架構模式來保證系統在后續迭代過程中的功能可擴展

性。傳統的MVC三層架構模式由數據層處理層、業務處理層、視圖層三層組成, 其中視圖層只關心數據的傳遞而不做數據的處理；而Django采用的是MTV模式，即模型層、模板層、視圖層，其中的視圖層同MVC模式不同的是，MTV 模式的視圖層會對數據進行處理。MTV模式是目前在Python開發中相對較為流行的高內聚低耦合的架構模式，由于其高內聚低耦合的特征，該模式現被應用到很多Web應用中。

4.2.2鮭藥物臨床信息系統的層次設計

基于上述的系統整體架構設計，本系統的層次設計為三層結構模型，分別為模型層、視圖層、模板層，系統的三層結構模型圖如下圖4-1所示：

圖4T系統的三層結構模型

下面將對這三層結構分別進行介紹：

模型層（Model層）主要是對新型藥物臨床信息管理系統中所需要處理的數據信息進行處理，主要功能是給上層的視圖層做數據支持和數據存儲，并對實體和數據庫中的數據實現映射。在本系統中需要映射的數據有：患者個人信息、患者的醫療記錄、患者的治療方案信息、患者的合并用藥信息、患者的不良反應信息、參與試驗的醫生信息、參與試驗的單位信息、藥品的發放和結存信息等幾種主要數據。

視圖層（View層）是連接模型層和模板層的中間連接層，主要功能是對模板層傳來的表單數據進行數據處理，將依據業務處理的具體情況選擇調用不同的模型層或模板層；本系統的主要數據處理包括醫生添加新參與試驗的患者、醫生對指定患者的醫療記錄進行記錄、醫生對指定患者出現的不良反應進行存儲、醫生査詢指定患者的某項身體指標的趨勢圖、項目辦成員查看患者的納入和治療情況統計報表幾個主要部分，系統將依據前端頁面的具體請求來進行相應的業務邏輯操作，完成用戶的具體請求。

模板層(Template層)主要是將新型藥物臨床信息管理系統的功能進行圖形界面化的展示。該層主要連接了用戶行為和系統操作，完成系統同用戶的交互。通過詳細的需求分析，模板層將分為登錄認證與個人信息管理(前端界面展示為工作臺)、患者管理、統計報表、藥品管理、用戶管理、單位管理、日志管理七個模塊，根據登錄用戶的不同身份標識向用戶展示不同的模塊。

4.3新型藥物臨床信息管理系統功能模塊設計

新型藥物臨床信息管理系統按照上章需求分析得出的結果，并因為患者治療情況記錄功能、治療方案記錄功能、合并用藥記錄功能、不良反應記錄功能、趨勢分析功能和提醒與警告功能這些功能都是醫生在臨床試驗過程中對患者試驗信息的記錄功能，所以將以上功能劃分至患者管理模塊；統計報表功能作為用戶查看各種信息報表的功能單獨劃分為統計報表模塊；藥品管理功能同理單獨劃分為藥品管理模塊；因為院領導要擁有用戶管理功能，而醫生沒有該項功能，為方便權限控制，將用戶管理功能單獨劃分為用戶管理模塊；同理因項目辦成員擁有單位管理功能且審計員擁有日志管理功能遂將其分別單獨劃分為單位管理模塊和日志管理模塊；綜上所述將系統的功能模塊劃分為登錄認證與個人佝息管理模塊、患者管理模塊、統計報表模塊、藥品管理模塊、用戶管理模塊、竜位管理模塊、日志管理模塊這七個模塊；系統的功能模塊圖如下圖4-2所示：一

圖4-2系統的功能模塊圖

43.1登錄認證與個人信恵管理模塊

登錄認證與個人信息管理模塊作為新型藥物臨床信息管理系統最為基礎的功能，該模塊主要由登錄認證&修改密碼、工作臺兩個小模塊構成；并在該模塊的子模塊工作臺下實現了提醒與警告功能。

用戶登錄是針對本系統涉及到的全部角色的登錄，用戶在使用本系統前首先需要正確的登錄本系統，當用戶登錄成功后系統還應向用戶提供修改密碼的功能，登錄認證和修改密碼子模塊完成了上述功能的實現。

工作臺是用戶使用本系統的快速入口，在用戶登錄本系統后，直接展示工作臺界面。本模塊主要包括近期就診患者一覽功能和通知與警告功能兩個功能點。近期就診患者一覽會直接在界面展示以下三種狀態的患者：（1）待處理：顯示七日內將要就診或隨訪的患者列表。（2）已逾期：顯示己經超過預定就診或隨訪日期3天仍未就診或隨訪的患者列表。（3）最近已隨訪：顯示該醫生最近隨訪的患者，用于對最近隨訪患者補充完善檢測數據等。消息與提醒是在項目進行的過程中，院領導和項目辦成員會隨時查看患者的治療情況，如果發現試驗過程中某位患者存在治療不當，或者存在危險隱患，可以給該患者的主治醫生發送消息與提醒。該功能用于顯示院領導或項目辦成員發送給當前登錄醫生的消息與提醒，提醒醫生注意。

在登錄認證和修改密碼子模塊中還實現了權限控制功能，該功能主要對登錄的用戶的權限進行劃分，在不同身份用戶的系統界面上展示不同的功能模塊。審計員為系統一級權限管理者，擁有系統的全部功能模塊權限（即審計員擁有登錄認證與個人信息管理模塊、患者管理模塊、統計報表模塊、藥品管理模塊、用戶管理模塊、單位管理模塊、日志管理模塊七個模塊的權限）并且擁有向系統所有用戶發送消息和提醒的權限；項目辦成員作為系統的二級權限管理者擁有除日志管理模塊的其余全部權限（即項目辦成員擁有登錄認證與個人信息管理模塊、患者管理模塊、統計報表模塊、藥品管理模塊、用戶管理模塊、單位管理模塊六個模塊的權限）并且擁有向院領導和醫生發送消息和提醒的權限；院領導作為系統的三級權限管理者擁有除日志管理模塊、單位管理模塊之外的其余全部模塊權限（即院領導擁有登錄認證與個人信息管理模塊、患者管理模塊、統計報表模塊、藥品管理模塊、用戶管理模塊五個模塊的權限）并且擁有向醫生發送消息和提醒的權限；醫生作為系統的主要操作用戶擁有登錄認證與個人信息管理模塊、患者管理模塊、統計報表模塊、藥品管理模塊的權限，并且醫生只具有查看該消息與提醒的權限。

43.2患者管理模塊

患者管理模塊是新型藥物臨床信息管理系統最為重要的核心功能，為滿足醫生在臨床試驗過程中能夠方便快速準確的錄入患者檢測指標信息的需求，在臨床試驗過程中對患者某一身體指標的變化能夠直觀的查看的需求以及其他上述需求分析得出的結論，在本模塊需要實現患者治療情況記錄功能、治療方案記錄功能、合并用藥記錄功能、不良反應記錄功能、趨勢分析功能。為實現上述功能所以將本模塊細分為新增患者、患者查詢、趨勢分析和CRF表錄入四個子模塊。

新增患者的流程由三步組成，流程如下圖4-3所示：

醫生錄入患者的基本信息之后，需要對患者進行入組排查，填寫入組排查表之后在確認頁面選擇是否加入該患者。如果本次添加的患者通過入組排查表的篩選之后則提示用戶本次添加的患者成功并入組；如果本次添加的患者沒有通過入組排查表的篩選，則提示用戶患者添加成功但沒有入組（入組排查是因為本項目主要是針對MDR-TB. Pre-XDR-TB、XDR-TB類型的患者，并且主要測試一種新發現的對結核病的成分的有效性進行鑒定的臨床試驗,所有在新患者加入項目時需要對該患者進行入組篩選，如果患者符合上述條件且對藥物臨床試驗知情并接受且無其他重大身體疾病之后即可入組成為臨床試驗的參與患者）。

患者查詢子模塊是提供給用戶篩選需要查看的患者的功能，該子模塊的系統界面設計如下：用戶點擊患者管理模塊后，將在主頁面上分頁展示患者列表，在患者列表上方是進行查詢的篩選按鈕，用戶可以選擇篩選單位、建檔人、患者是否入組以及時間的選擇，或者用戶可以直接指定患者的姓名或者編號進行精確檢索；在用戶輸入篩選信息后點擊搜索按鈕，即可進行查詢。查詢返回的患者列表部分展示以下字段：患者編號、患者姓名、性別、診斷類型、電話、入組日期。

CRF表錄入子模塊包括患者的醫療記錄、治療方案、合并用藥等一些患者的主要指標，醫生在子模塊中可對患者的檢測信息進行錄入或者查看某個患者某項身體指標的檢測信息；系統需要按照CRF表的要求自動驗證表中各項數據指標的完整性。在患者的基本信息中醫生可以査看患者的基本信息，如：姓名、編號、性別、年齡、結核病灶位置、目前診斷情況、診斷時間等。院領導或項目辦成員在查看該患者的情況時，針對此患者的現有問題，如果需要提醒該患者的主治醫生重點關注該患者的某項指標、不良反應等，則會給該患者的主治醫生發送通知與警告。

系統將按照CRF表的要求自動驗證表單填寫的完整性，并且在每個患者的監測指標下醫生可以查看該患者的該項指標的趨勢變化。

4.3.3統計報表蹶

統計報表模塊實現了統計報表功能，在模塊應該使用折線圖、柱狀圖、餅圖或者其他統計圖滿足用戶直觀的查看各項指標的需求，依據醫生、院領導、項目辦的實際需求該模塊包括對所有患者藥物使用情況的統計，患者隨訪情況統計、患者治療轉歸情況統計和不良反應統計四個子模塊，供院領導和項目辦成員查看分析。

患者藥物使用情況統計以柱狀圖展示各種藥物的用藥分布情況；患者隨訪情況統計以柱狀圖和折線圖分別展示單位隨訪率、是否完成隨訪、未完成隨訪原因、以及隨訪類型；患者治療轉歸情況統計模塊以表格的形式展示痰菌陰轉率，以柱狀圖展示治療轉愈情況以及治療完成后復發情況。不良反應統計則以柱狀圖分別展示不良事件嚴重程度分級統計、嚴重不良事件類型統計、不良事件結局統計、不良事件名稱統計四張圖表。

4.3.4藥品WS腆

藥品管理模塊實現了藥品管理功能，滿足藥房醫生錄入藥品數據的需求以及醫生、院領導、項目辦成員查看本院或本項目藥物現有藥品的統計信息和操作信息的需求；為滿足用戶的需求該模塊主要包括藥品統計和藥品清單兩部分功能：藥品統計功能為展示當前用戶所在醫院（項目辦成員在此界面展示所有參與項目的醫院）的藥品盤點數據：包括藥品發放量以及藥品銷毀量；藥品清單功能提供給醫生錄入藥品的盤點信息，當前登錄的醫生操作完成后需在頁面展示此次的操作記錄，方便后續查看。醫生和審計員在本模塊擁有藥品統計和藥品清單兩個子模塊的權限，院領導及項目辦成員在本模塊只擁有藥品統計子模塊的權限；本模塊的主要目的是讓用戶清楚的了解各醫院藥品的發放與結存情況。

4.3.5用戶管理模塊

用戶管理模塊實現了用戶管理功能，滿足院領導、項目辦成員以及審計員對本項目參與的所有醫生的數據進行管理的需求，即該模塊是系統提供給院領導、項目辦成員和審計員的可以對參與項目的本醫院醫生進行增加、刪除、查詢、修改管理操作的功能模塊。院領導可以對本醫院的所有參與項目的醫生進行增刪改査的操作；項目辦成員可對參與項目的所有醫院的所有醫生進行增刪改查的操作；審計員可對系統的所有用戶進行增刪改查的操作。

4.3.6單位WS戦

單位管理模塊實現了單位管理功能，滿足項目辦成員對參與項目的醫院進行單位管理的需求；即該模塊是系統提供給項目辦成員和審計員可以對參與項目的醫院單位進行增加、刪除、查詢、修改操作的功能。

4.3.7日志倔臧

日志管理模塊實現了日志管理功能，滿足審計員在審計工作中需要查看系統的操作記錄的需求，即該模塊是系統提供給審計員的可以查看系統的日志情況的功能。日志包括登錄日志、編輯日志、提交日志、刪除日志四種日志類型。通過選擇不同的日志類型展示不同的日志：登錄日志需要包括登錄賬號、姓名、登錄類型、登錄IP和登錄時間五個字段；編輯、提交和刪除日志需要包括賬號、姓名、數據類型、操作對象和操作時間五個字段。

4.4數據橫型設計

4.4.1 E-R 圖

E-R圖的全稱是Entity Relationship Diagram也就是實體-聯系圖。本系統依據實際使用場景將系統表設計為多個數拯庫表：用戶信息表、患者信息表、醫療信息表、治療方案表、合并用藥表、不良反應表、藥品信息表、單位信息表、日志信息表、權限控制表、消息提醒表等等。由于部分表是對系統的具體功能提供支持，下而將對患者信息表、醫療信息表、治療方案表、合并用藥表y不良反應表、藥品信息表、單位信息表這些同系統主要業務相關的表進行分析：患者、醫療信息、治療方案、合并用藥、不良反應、單位和藥品之間的E-R圖如下圖4-4

所示:

圖4-4數據庫主要表結構E-R圖

E-R圖各實體主要屬性的詳細描述如下：

（1）用戶：用戶id、密碼、上次登錄時間、是否審計員、用戶賬號、用戶郵箱、是否在線、是否醫生、是否項目辦成員、是否院領導、醫院id、何時加入項目

（2）患者：患者id、患者編碼、檔案編碼、姓名、性別、電話、備用電話、出生日期、地址、體重、身高、診斷類型、診斷日期、加入項目日期、曾治療否、最后治療時間、下次治療時間、警告類型、是否入組、入組原因、創建記錄時間、更新記錄時間、是否隨訪、醫生id、醫院id

（3）不良反應：不良反應id、不良反應名稱、出現時間、反應程度、是否嚴重、反應類型、使用藥品、化療聯系、是否處理、處理細節、處理結果、上次出現時間、死亡日期、死亡原因、消失時間、是否上報、上報時間、上報級別、記錄創建日期、上次更新時間、醫生id、患者id、醫院id

（4）合并用藥：合并用藥id、合并用藥名稱、合并用藥編碼、開始合并用藥時間、結束合并用藥時間、創建記錄時間、更新記錄時間、患者id

（5）醫療記錄：醫療記錄id、醫療信息治療方案、創建記錄時間、更新記錄時間、患者id、血常規id、尿常規id、生化id、心電圖id、涂片id、藥敏檢測id

（6）治療方案：治療方案id、藥品名稱、用藥方法、用藥劑量、用藥開始時間、用藥結束時間、用藥原因、其他用藥原因、創建記錄時間、更新記錄時間、陜牛id、患者id、醫院id

（7）藥品：藥品id、藥品名稱、藥品劑量、藥品類型、藥品入庫時間、創建記錄時間、更新記錄時間、批次id、醫院id、備注信息

（8）醫院：醫院id、醫院名稱、醫院編碼、醫院聯系方式、醫院聯系郵箱、醫院項目進行階段、創建記錄時間、更新記錄時間

4.4.2數據庫表的設計

為滿足系統的各個功能需求，系統的各個數據庫表設計如下（下表中未標出非主要業務邏輯需要字段）：

新型藥物臨床信息管理系統的用戶表結構如下表4-1所示，用戶表主要存儲用戶的賬號、密碼來供登錄認證功能模塊使用；用戶表還需要設計字段區分用戶的角色來給權限劃分功能做支撐；同時該表還需要設立其他字段來存儲用戶的基本彳曰息。

表4T用戶表

序號屬性名稱數據類型是否可以為空長度備注

1 id INT 否 11 用戶id

2 password VARCHAR 否 32 密碼

3 last login DATETIME 是上次登錄時間

4 is superuser TINYINT 否 1 是否審計員

5 username VARCHAR 否 32 用戶賬號

6 email VARCHAR 否 64 用戶郵箱

7 is active TINYINT 否 1 是否在線

8 is staff TINYINT 否 1 是否醫生

9 is hosLeader TINYINT 否 1 是否院領導

10 hospital id INT 否 11 醫院id

11 is proLeader TINYINT 否 1 是否項目辦成員

12 date joined DATATIME 否何時加入項目

新型藥物臨床信息管理系統的患者表的表結構如下表4-2所示，該表主要存儲患者的基本信息，以及患者屬于哪個醫院，是由哪個醫生負責，患者在系統中信息的存取靠患者表做支撐。

表4-2患者表

序號屬性名稱數據類型是否可以為空長度備注

1 id INT 否 11 患者id

2 code VARCHAR 是 64 患者編碼

3 archive code VARCHAR 是 64 檔案編碼

4 name VARCHAR 是 30 姓名

5 sex VARCHAR 是 2 性別

6 phone VARCHAR 是 11 電話

7 phone2 VARCHAR 是 11 備用電話

8 birthday DATE 是出生日期

9 address VARCHAR 是 64 地址

10 weight DOUBLE 是體重

11 height INT

UNSIGNED 是 10 身高

12 diagnose type VARCHAR 是 128 診斷類型

續上表

廳號屬性名稱數據類型是否可以為空長度備注

13 diagnose date DATE 是診斷時間

14 enter date DATE 是加入項目日期

15 has treatment TINYINT 否 1 曽治療否

16 last treatment DATE 是最后治療時間

17 next treatmen DATE 是下次治療時間

18 warning_num INT

UNSIGNED 是 10 警告類型

19 is eligible TINYINT 否 1 是否入組

20 eligible result VARCHAR 是 128 入組原因

21 creation date DATETIME 否創建記錄時間

22 last_update_dat

e DATETIME 否更新記錄時間

23 doctor id INT 否 11 醫牛id（即用戶）

24 is visit TINYINT 是 1 是否隨訪

25 hospitial id INT 是 11 醫院id

新型藥物臨床信息管理系統的不良反應表的表結構如下表4-3所示，該表需要存儲的信息是患者在治療過程中出現的不良反應的詳細佶息，同時該表還需:要存儲該種不良反應是出現在哪個患若身上、以及整個不良反應是由哪個I矢仝負責的，以及該不良反應出現在在哪個侯院，方便在不良反應出現時能夠快讀上位患者、醫化和醫院；患者管理模塊中的不良反應子模塊山不良反應表做支撐。

表4-3不良反應表

廳號屬^性名稱數據類型是否可以為空長度備注

1 id INT 否 11 不良反應id

2 name VARCHAR 是 128 不良反應名稱

3 occur time DATETIME 是出現時間

4 degree VARCHAR 是 255 反應程度

5 is serious TINYINT 是 1 是否嚴重

6 type VARCHAR 是 255 反應類型

7 medicine VARCHAR 是 255 使用藥品

續上表

序號屬性名稱數據類型是否可以為空長度備注

8 relate hualiao VARCHAR 是 255 化療聯系

9 is handle TINYINT 是 1 是否處理

10 does VARCHAR 是 255 處理細節

11 result VARCHAR 是 255 處理結果

12 remission dat

e DATE 是上次出現時間

13 death date DATE 是死亡日期

14 death reason VARCHAR 是 255 死亡原因

15 exit date DATE 是消失時間

16 is upload TINYINT 否 1 是否上報

17 upload time DATETIME 是上報時間

18 version INT 否 11 上報級別

19 creation date DATETIME 否記錄創建時間

20 last_update_d

ate DATETIME 否上次更新時間

21 doctor id INT 否 11 醫生id（即用戶）

22 patient id INT 否 11 患者id

23 hospitial id INT 是 11 醫院id

新型藥物臨床信息管理系統的合并用藥表的表結構如下表4-4所示，該表主要存儲的是患者的合并用藥詳細信息，以及該合并用藥情況是在哪個患者身上使用，患者管理模塊中的合并用藥子模塊由合并用藥表做支撐。

表4-4合并用藥表

序號屬性名稱數據類型是否可以為空長度備注

1 id INT 否 11 合并用藥id

2 name VARCHAR 是 64 合并用藥名稱

3 code VARCHAR 是 64 合并用藥編碼

4 begindate DATE 是開始合并用藥時

間

續上表

序號屬性名稱數據類型是否可以為空長度備注

5 stop_date DATE 是結束合并用藥時

間

6 creation date DATETIME 否創建記錄時間

7 last_update_d

ate DATETIME 否更新記錄時間

8 patient id INT 否 11 患者id

新型藥物臨床信息管理系統的治療方案表的表結構如下表4-5所示，該表主要存儲醫生給患者制定的治療方案的詳細信息，以及該治療方案屬于哪個患者，由哪個醫院的哪個醫生進行制定；患者管理模塊中的治療方案子模塊由治療方案表做支撐。

表4-5治療方案表

序號屬性名稱數據類型是否可以為空長度備注

1 id INT 否 11 治療方案id

2 med name VARCHAR 是 64 藥品名稱

3 med method VARCHAR 是 255 用藥方法

4 med_quantnt

y VARCHAR 是 255 用藥劑量

5 med date s DATE 是用藥開始時間

6 med date e DATE 是用藥結束時間

7 med reason VARCHAR 是 255 用藥原因

8 med_reason_ else VARCHAR 是 255 其他用藥原因

9 creation date DATETIME 否記錄創建時間

10 last_update_d

ate DATETIME 否上次更新時間

11 doctor id INT 否 11 醫生id（即用戶）

12 patient id INT 否 11 患者id

13 hospitial id INT 是 11 醫院id

新型藥物臨床信息管理系統的藥品表的表結構如下表4-6所示，該表主要是給藥品管理模塊中的藥品統計和藥品清單子模塊都由藥品表來做支撐，所以該表的字段為藥品的詳細信息。

表4-6藥品表

序號屬性名稱數據類型是否可以為空長度備注

1 id INT 否 11 藥品id

2 name VARCHAR 是 64 藥品名稱

3 quantity INT 是 11 藥品劑量

4 type VARCHAR 是 64 藥品類型

5 date DATE 是藥品入庫時間

6 batch id INT 否 11 批次id

7 creation_dat

e DATETIME 否記錄創建時間

8 lastupdate date DATETIME 否上次更新時間

9 hospitial id INT 是 11 醫院id

10 comment LONGTEXT 是備注信息

新型藥物臨床信息管理系統的醫療記錄表的表結構如下表4-7所親，該表主要存儲患者的醫療記錄，包括該條醫療記錄的創建時間、更新時間以及屬于哪個患者；患者管理模塊中的醫療記錄子模塊由醫療記錄表做支撐。

表4-7醫療記錄表

序號屬性名稱數據類型是否可以為空長度備注

1 id INT 否 11 醫療記錄id

2 RB id INT 是 11 血常規id

3 RU id INT 是 11 尿常規id

4 BI id INT 是 11 生化id

5 ECG id INT 是 11 心電圖id

6 SMEAR id INT 是 11 圖片id

7 DS id INT 是 11 藥敏檢測id

8 creation date DATETIME 否創建記錄時間

9 patient id INT 否 11 患者id

新型藥物臨床信息管理系統的醫院單位表的表結構如下表4-8所示，單位表主要存儲參與本項目的所有醫院單位的詳細信息；單位管理模塊由醫院單位表做支撐。

表4-8醫院單位表

序號屬性名稱數據類型是否可以為空長度備注

1 id INT 否 11 醫院id

2 name VARCHAR 否 64 醫院名稱

3 code VARCHAR 是 64 醫院編碼

4 phone VARCHAR 是 11 醫院聯系方式

5 email VARCHAR 是 64 醫院聯系郵箱

6 phase INT 否 11 醫院項目進行階段

7 creation_dat

e DATETIME 否創建記錄時間

8 last_update date DATETIME 否更新記錄時間

4.5本章小結

本章主要對新型藥物臨床信息管理系統的設計原則、系統的整體架構設計以及層次設計進行了詳細的闡述，并按照需求分析產生的結果對系統的各個功能模塊進行的總體設計，并對各個系統模塊的功能進行了重點介紹，同時還依據系統的實際需求對數據庫模型進行抽象產出了 E-R圖，并對E-R圖轉換的數據表進行了詳細的描述。

第五章新型藥物臨床信息管理系統功能模塊的詳細設計與

實現

本章重點是按照新型藥物臨床信息管理系統的總體設計對系統進行詳細的設計與實現；本章還描述了系統在開發過程中使用的開發語言和框架的選擇。

5.1開發語言和框架選擇

瀏覽器端（前端）的主要語言包括HTML, CSS, JavaScript等，主流的Web 開發語言有Java、PHP、ASP.NET、Python等。本系統前端語言采用Vue.js同 Element-UI結合的方式進行開發，引入前端框架使得前端的開發量下降；服務器端（后臺）開發語言通過比較上述幾種語言的開發工作量、運行速度、成本后選擇Python + Django的方式進彳亍開發，Python語言提供大量的第三方庫使得開發變得簡潔，同時Django是當前Python語言在Web開發上較為完整和方便的框架，所以選擇該種方式來進行服務端開發。

5.2系統的詳細設計與實現

5.2.1登錄與個人信息管理模塊的詳細設計與實現

新型藥物臨床信息管理系統的使用必須建立在后臺服務器已啟動，用戶能夠正確的登錄系統的前提下，所以登錄與個人信息管理模塊是本系統的慕礎功能模塊，該模塊主要由登錄認證&修改密碼、工作臺兩個小模塊構成，在該模塊中還實現了系統的權限控制：

（1）新型藥物臨床信息管理系統的登錄是針對全部用戶角色的登錄，登錄的具體邏輯設計為：用戶在使用本系統前需要先輸入用戶名、密碼以及驗證碼進行登錄，前端將對表單的填寫做判空處理，如果不為空則繼續；如果用戶輸入的驗證碼錯誤，則提示驗證碼錯誤；如果驗證碼正確，則繼續進行下述邏輯；如果用戶輸入的用戶名和密碼在數據庫中，并且同數據庫中存儲的數據匹配，那么用戶登錄成功；如果用戶輸入的用戶名在數據庫中找不到相應的數據項，則提示該用戶不存在；如果用戶輸入的用戶名存在，但是密碼同數據庫中該用戶名記錄的密碼并不相同時，系統提示用戶密碼輸入錯誤，如果用戶連續5次輸入密碼錯誤，該賬號鎖定1小時。下圖5-1展示了系統的登錄流程：

圖5-1登錄流程圖

登錄功能的前端界面主要通過Login.Vue文件實現，在Login.Vue中，登錄表單使用Element UI提供的el-fbrm-item表單組件完成前端表單的實現，用戶在前端頁面填寫必填項后，使用CSS-selector選擇每個項目的輸入值并與該項的prop值對應，在Login.Vue中定義getTableData()函數，該函數通過axios.post()方法將用戶填寫的數據傳遞給后端的LoginAPIView類，在該類中將數據包裝為User對象傳遞給 LoginSerializer類，該類通過使用Django中的ORM框架將User對象同數據庫的數據進行比對，驗證邏輯同上文所述；在驗證碼校驗步驟，驗證碼使用canvas繪制，并將繪制驗證碼的數字或英文保存在一個Var變量中，在rule()函數中比對用戶輸入和保存的驗證碼變量值是否相同；驗證碼驗證在前端完成，減少后端服務的交互壓力。

(2)修改密碼操作是指用戶可以將當前使用的密碼用新密碼進行替換的功能：當用戶成功登錄本系統后，點擊頁面相應的修改密碼按鈕，在前端頁面彈出的表單上填寫必填項并點擊修改按鈕，前端將會校驗對新密碼和確認密碼是不是相同，如果新密碼和確認密碼不是相同的，則提示錯誤，如果相同則提示修改密碼成功，并提示用戶用新密碼重新登錄系統，用戶密碼格式設定為不少于8位的字母數字或特殊字符組合。

在前端邏輯的實現過程中，將新密碼的prop值定義為newPassWord,確認密碼的prop值定義為confirmPassWord并將其validator值分別設置為 validate_password和validateComfirmpwd,并在該前端文件中相對應的rule()函數, 判斷newPassWord的值和confirmPassword值是否相同，如果不同則提示錯誤。

(3)工作臺是展現給登錄用戶的首界面，在這個界面上將會展示近期患者一覽和自己收到的消息和提醒。在近期患者一覽中，展示待處理患者、已逾期患者、最近已隨訪患者三種類型；用戶在訪問工作臺界面時，前端會向后端傳遞當前登錄用戶的參數，后臺服務在接收到參數后，首先會根據當前用戶的角色進行劃分，如果是院領導則查找的患者范圍為該用戶所在醫院的全部患者；醫生則查找的患者范圍為該用戶操作的全部患者；項目辦成員則査找的患者范圍為全部患者；確定患者范圍后，再按照患者的下次治療時間進行劃分，劃分為不同的患者類型返回給前端頁面進行展示。

(4)權限控制主要體現在不同的用戶擁有不同的權限模塊，各角色擁有的詳細權限在4.3」節中有詳細介紹；同時院領導和項目辦成員以及審計員還提供發送消息和提醒的功能，醫生只有查看的權限沒有發送的權限。權限控制的實現主要依據數據庫中User表中的is_staflt； is hosLeader, is_proLeader, is superuser四個字段來進行控制：當用戶為醫生則is_staff的值為1,剩余三個字段值為0；當用戶為院領導則is_hosLeader值為1,剩余三個字段值為0；當用戶為項目辦成員則 is_proLeader的值為1,剩余三個字段值為0；當用戶為審計員則is_s叩eruser值為1, 剩余三個字段值為0；前端的功能模塊權限控制由后臺向前端傳遞-個menu字典進行控制，例如醫生的menu字典設計為：

menul={

，workBench'='工作臺'，

•patientManagement,=,患者管理二

•reportForm'i 統計報表'，

• drugManagement'='藥品管理’

}

則前端頁面展示工作臺、患者管理、統計報表、藥品管理四個模塊。每當用戶登錄后，后臺會按照順序依次判斷is_superuser字段是否為1,如果是則返回相應審計員對應的字典字段，若為0則依次判斷is_proLeader, is hosLeader, is_staff字段是否為1,如果以上三個值其中有一個為1則返回該角色對應的menu字典。前端界面在收到該字典后，按照字典的key值選擇展示的模塊。

5.2.2患者管理模塊的詳細設計與實現

患者的管理模塊作為新型藥物臨床信息管理系統的重要模塊，需要完成對試驗過程中醫生的治療和患者的各種指標進行記錄的功能，主要包括新增用戶、患者查詢、趨勢分析和CRF表錄入四個主要功能。

(1)新增患者功能主要分為三個步驟：第一步為錄入患者基本信息，將對患者的基本信息進行錄入，在表單填寫過程中對基本信息中的身高、體重、電話號碼、身份證號進行驗證，比如電話號碼需為11位數字的基礎限制；第二步為填寫入組排査表，在這一步中將設立8個選項，如果這8個選項全部符合預設，則該新增患者可入組，若該新增患者不滿足其中任意一項，則不予入組；第三步為確定頁面，系統提示用戶“下一步將進行患者入選標準判定，提交后合格性判定信息將無法修改，請確認是否提交”字段，如果用戶選擇確定，則存儲該患者的信息，并顯示該用戶的入組情況。只有入組排查表填寫符合要求的患者才能進入到患者隊列中，不符合要求的患者信息只記錄入組排查表填寫內容和之前填寫的患者姓名等基本信息。新增患者的處理流程如下圖5-2所示：

圖5-2新增患者流程圖

新增患者的前端界面通過addPatient.Vue文件實現，在addPatient.Vue中，患者信息表單使用Element UI提供的el-fbrm-item表單組件完成前端表單的實現，當

醫生填寫完畢后點擊下一步，觸發rules。函數對前端表單中的各項信息進行校驗，例如手機號為11位數字的校驗通過.number修飾符實現并將其長度設置為11, 對該所填項進行校驗；驗證正確后跳轉入組排查表頁，醫生填寫后同樣觸發前端的rules()函數對表單進行驗證，點擊下一步前端通過axios.post()方法將表單傳遞給后端PatientAddView類，該類將表單數據包裝為Patient類，并傳遞類 PatientSerializer類,該類通過使用Django中的ORM框架將Patient對象同數據表中的字段對應并將數據入庫。

(2)患者査詢子模塊則是提供給用戶按照指定條件篩選特定條件的用戶的功能，用戶將通過查詢患者頁面鍵入自己的篩選信息，用戶可以選擇建檔人是誰，患者是否入組，或者直接指定患者的名稱或者編號對患者進行檢索。然后后臺將

會調用PatientViewSet類，并使用該類的PatientSearch()方法進行邏輯處理；再調用PatientFilter類的filter。方法，該方法調用Model類的patientMap()方法在數據庫中進行篩選；圖5-3展示了查詢患者子模塊的查詢患者的流程：

I I 7.匹何金詢結果伉總0

: r D

I •將結粟返冋給前端()I I

r □ I

I I I

圖5-3查詢患者的時序圖

(3)CRF表錄入主要分為醫療記錄、治療方案、合并用藥和不良反應四個功能。在患者的列表中，每位患者的最右邊一欄有“處理”按鍵，點擊該按鈕后界面展示該患者的基本信息，然后選擇要填的某一CRF表單進行填寫。

醫療記錄功能完成該患者的治療階段的選擇，患者的治療階段由系統默認生成，默認14天為一個周期，用戶需要先選擇階段，再選擇患者對應的檢査項目，項目的選擇有入選排除表、隨訪表、血常規、生化、心電圖、涂片、分子生物學診斷、培養、藥敏檢測、影像學等項目，用戶在選擇項目之后對每項必填項進行填寫，點擊保存則該條數據保存在數據庫。

治療方案功能是提供給醫生查看、添加該患者的治療方案的功能，用戶可點擊右側的“新增”按鈕添加該患者的治療方案，填寫表單后，點擊保存，該條治療方案正確保存到數據庫中，保存成功后，該條記錄展示在系統界面上。該功能的主要目的是方便醫生了解該患者治療到哪個階段，為以后的治療提供依據。

合并用藥功能供醫生查看該患者在使用試驗用藥的過程中是否還服用其他種類的藥物。用戶在該界面也可査看和新增患者的合并用藥情況，并對已有的合并用藥情況進行編輯，系統在表格上方提示用戶“影響心臟的藥物必須填報”字樣。

不良反應功能是提供給醫生查看不良反應，添加不良反應的功能并且該模塊還提供不良反應上報接口；其中不良反應上報模塊流程如圖5-4所示。系統在接收到醫生提交的不良反應信息后，將立刻自動向項目辦指定負責人提供的接收不良反應的電子郵箱發送不良反應上報郵件；郵件內容為醫生填寫的該條不良信息的全部內容及確認鏈接，該負責人在收到該郵件后需要點擊郵件的確認鏈接，以保證郵件被正確接收。系統在發送郵件后五分鐘內如果未收到該負責人的回復，將再次發送該項不良事件，并等待接收該負責人的回復，如果重發五次仍得不到該項目辦負責人的回復，則向該負責人的手機發送提醒短信。

圖5-4不良反應上報處理流程圖

該接口的處理邏輯是通過后臺的PastAdverseViewSet類進行實現，在該類中, 使用Django 的restframwork進行自動監控，如果"api/vl/hospital/adverse"這個 url被調用，即在BadCaseViewSet會將不良反應的上報數據傳遞給 PastAdverseViewSet類，在該類中選擇表單數據的患者id,醫生id和不良信息并組裝成JSON串，之后的處理邏輯如上述流程圖所示。

(4)趨勢分析功能使得醫生可以選擇查看患者在治療過程中的體重變化、血壓變化，血常規中血小板變化、血常規中白細胞變化等形成的曲線圖或柱狀圖。用戶選擇不同的身體狀況，前端將對應的參數傳遞給后臺進行處理，后臺接收到參數后，通過model層同數據庫進行交互，查詢到對應的數據后返回給前端進行展示。該功能的后臺實現主要使用Django中的ORM對數據庫的數據進行篩選，并在前端通過Echarts進行繪制，例如醫生點擊某一患者的血小板變化選項，使用該患者的患者id在數據庫中査找該患者的血小板信息，并將時間和血小板值組裝成list返回給前端，前端頁面將折線圖的drawLine的字段(即該折現圖的橫縱坐標項)分別設置為日期和血小板數量，并依據收到的list值進行繪制。

消息提醒默認點擊后分頁展示當前用戶所收到的全部消息和提醒，并提供用戶可以按照指定條件查詢相應的消息和提醒的功能；新建消息功能只提供給院領導、項目辦成員和審計員，當用戶為院領導和項目辦成員時，該用戶可對某一患者的對應醫生發送警告和提醒；審計員可以給系統的任意用戶發送消息；醫生只提供查看消息或提醒的功能。

5.2.3統計報表橫塊的詳細設計與實現

統計報表模塊主要是根據數據庫中患者的治療結果信息進行指定規則查詢，然后整合數據庫中查詢的結果傳遞給前端，由前端負責繪圖。當用戶點擊不同的報表時，前端向后臺傳遞不同報表對應的不同參數；根據不同的參數后臺進行不同的數據查詢，然后將查詢結果返回給前端進行展示；如果用戶不指定醫院，則默認展示當前用戶所在醫院的患者查詢信息，項目辦成員展示數據庫中全部患者信息。用戶查看統計報表的時序圖如下圖5-5所示：

圖5-5查看統計報表的時序圖

系統統計報表子模塊患者的藥物使用情況以柱狀圖展示各種藥物的用藥分布情況，以左氧氟沙星、莫西沙星、加替沙星、阿米卡星、卷曲美素、卡那美素、鏈霉素、乙硫異煙胺、丙硫異煙胺、環絲氨酸、特立齊酮、氯法齊明等藥物名稱為橫坐標，患者數為縱坐標進行用藥分布的展示。系統統計報表子模塊的患者隨訪情況統計以柱狀圖和折線圖分別展示單位隨訪率、是否完成隨訪、未完成隨訪原因、以及隨訪類型。系統統計報表子模塊的患者治療轉歸情況統計以表格形式展示痰菌陰轉率，以柱狀圖展示治療轉歸結果以及治療完成后復發情況；系統統計報表子模塊的不良反應情況統計以柱狀圖展示不良事件嚴重程度分級統計、嚴重不良事件類型統計、不良事件結局統計、不良事件名稱統計四張圖表。

統計報表的實現邏輯主要是后端查詢數拯，并將查詢的數據返回給前端，前端進行繪制：用戶通過TreatmentStats.Vue選擇自己要查詢的指定醫院的患者質量、隨訪、治療轉歸或不良反應的情況，前端將醫院參數和用戶的參數傳遞給后端的TreatmentViewSet類，在該類中通過接受前端傳遞的參數判斷是哪張表單，例如用戶點擊單位隨訪率表，則該類調用TreatmentSerializer的filter。方法，在該方法中調用Model類，在Model類中調用相應的方法在數據庫中的患者表中查找對應的hospital_id和數據條數，并將查找的數據包裝成list對象返回給前端，前端使用該list使用Echarts進行繪制。

5.2.4藥品管理模塊詳細設計與實現

藥品管理模塊主要包括藥品統計和藥品清單兩部分功能，其中默認進入藥品管理模塊后展示當前用戶所在醫院的現有藥品統計信息，表頭為單位名稱、累計發放量、盤點、藥品總消耗，并支持按每個表頭項進行排序的功能；點擊上方清

單按鈕跳轉藥品清單功能，該功能進入后默認展示當前用戶所在單位的全部藥品操作信息，表頭為：操作日期、操作類型、單位名稱、數量和操作，并支持按每個表頭項進行排序的功能，如果用戶為院領導或項目辦成員，藥品管理模塊只提供統計子模塊權限，不提供清單子模塊權限；如果用戶為醫生，則提供錄入功能, 即提供清單子模塊權限：醫生在清單子模塊點擊錄入盤點數量按鈕，彈出盤點表用戶填寫后點擊保存；點擊錄入發放量按鈕，彈出發放量的表單，用戶填寫后點擊保存。具體的邏輯實現是：用戶通過MedicineStats.Vue查看用戶所在醫院的藥品發放和存儲情況，前端將醫院參數和用戶的參數傳遞給后端的

MedicineViewSet類，該類調用其stat()方法進行邏輯處理；再通過

MedicineSerializer的filter()方法調用Model類中的MedicineMap ()方法同數據庫連

接并在Medicine表中進行查詢。藥品查詢的時序圖如下圖5-6所示:

□

圖5-6藥品查詢的時序圖

5.2.5用戶管理模塊的詳細設計與實現

用戶管理模塊是提供給院領導和項目辦成員進行人員管理的功能，當用戶登錄后，鑒定角色為院領導、項目辦成員或審計員時，左側的功能欄展示用戶管理模塊；默認進入該模塊后展示當前用戶所在醫院的所有醫生信息，項目辦成員展示數據庫中所有醫生的信息，每條用戶記錄后提供編輯和刪除按鈕；點擊刪除按鈕，彈出提示詢問用戶是否確定刪除；點擊編輯按鈕彈出該用戶的詳細信息表單, 用戶編輯修改后點擊保存。在界面上方提供查詢功能，用戶選擇指定醫院(默認為當前用戶所在醫院，項目辦成員默認為全部醫院)、填寫醫生姓名，點擊査詢按鈕進行查詢。右側提供添加醫生按鈕，點擊按鈕彈出新增用戶表單，用戶填寫表單后點擊確定進行保存。用戶展示的時序圖如下圖5-7所示：

用戶 1：用戶點擊

I 用戶管理頁面0

圖5-7用戶展示的時序圖

展示當前用戶所在醫院的所有參與項目的用戶的具體后端實現是:用戶在登錄后，前端頁面將保存登錄時用戶的角色信息，例如當院領導登錄時， is hosLeader值為1,并記錄該用戶的hospital id,當用戶點擊單位管理模塊時，前端通過UserStats.Vue向UserViewSet類后端傳遞單位id和角色信息，UserViewSet 類調用UserSerializer的filter。方法，在該方法中調用Model類的UserMap()方法在數據庫中篩選指定醫院的醫生信息并組裝成User類返回給UserViewSet類，再序列化為JSON串返回給前端進行表格的繪制。

5.2.6單位管理模塊的詳細設計與實現

單位管理模塊是提供給院領導和項目辦成員進行單位管理的功能。當用戶登錄后，鑒定角色為項目辦成員時，左側的功能欄展示單位管理模塊；默認進入該模塊后展示所有單位信息，每條單位記錄后提供編輯和刪除按鈕;點擊刪除按鈕, 彈出提示詢問用戶是否確定刪除；點擊編輯按鈕彈出該單位的詳細信息表單，用戶編輯修改后點擊保存；系統同時提供查詢功能，用戶鍵入單位姓名后進行檢索; 右側提供添加單位按鈕，點擊按鈕彈出新增單位表單，用戶填寫表單后點擊確定進行保存。單位展示的時序圖如下圖5-8所示：

圖5-8單位展示的時序圖

展示參與項目的所有醫院的具體實現如下：用戶通過OriganzatiortStats.Vue 查看參與項目的每個醫院的情況，前端通過調用axios.get()調用指定的url, Django 將url定位到0rganizationViewSet類，該類調用0rganizationSerializer的filter。方法, 在該方法中調用Model類的HospitalMap()方法在數據庫中篩選醫院信息并將查找至IJ的信息組裝成Hospital^象返回給OrganizationViewSet類，該類將Hospital對象序列化為JSON串并返回給前端，前端依據返回的信息進行表單的繪制。

5.2.7日志管理橫塊的詳細設計與實現

日志管理模塊是實現展示操作日志的模塊，當用戶登錄后，鑒定角色為審計，員時，左側的功能欄展示日志模塊；默認進入該模塊后展示登錄登出日志信息。在界面上方提供篩選功能，用戶選擇日志類型(下拉框默認為登錄日志，修改日志、提交日志、刪除日志四種類型)，點擊搜索按鈕進行篩選。篩選日志的時序圖如下圖5-9所示：

圖5-9篩選日志的時序圖

篩選系統日志的具體實現是：當用戶的is_superuser值為1時，在用戶的系統界面有日志管理模塊，當用戶點擊日志登錄模塊時，并選擇需要查看的日志類型后,CrudAuditStats.Vue將調用axios.post()方法訪問對應的url并傳遞日志類型參數，Django將該url映射到CrudAuditViewSet類，該類通過CrudAuditSerializer的 filter。方法，在該方法中調用Model類的LogMap()方法在數據庫中的日志表中進行查詢，查詢后將查詢的數據組裝為Log對象返回給CrudAuditViewSet類，該類將Log對象序列化JSON串并返回給前端，由前端進行展示日志表格。

5.3本章小結

本章的主要內容為介紹本系統選擇的開發語言和框架，通過流程圖和時序圖的形式描述了新型藥物臨床信息管理系統的登錄認證與個人信息管理模塊、統計報表模塊、藥品管理模塊、用戶管理模塊、單位管理模塊、日志管理模塊七個功能模塊的詳細設計和實現細節。

第六章新型藥物臨床信息管理系統的系統測試

軟件測試（SoftwareTesting）是軟件系統在開發完成后，對系統的一個驗證過程。通過對程序采用不同的軟件測試方法進行不同的測試，來驗證系統的功能是否滿足用戶的全部需求，評估軟件的質量。在進行軟件測試的過程中，將會發現系統在功能性的問題和性能的問題，然后對這些問題進行分析定位并解決。

6.1新型藥物臨床信息管理系統的測試目標

本系統屬于小型的軟件系統，對軟件系統的要求是運行穩定、響應速度快、各功能滿足用戶需求;所以新型藥物臨床信息管理系統的測試目的為測試系統是否滿足用戶的全部需求，并能正確、穩定的運行。由于本系統的主要角色為醫生以及系統主要用于新型藥物臨床試驗的信息管理中，所以系統測試的重點為患者管理模塊及其子功能、統計報表模塊及其子功能模塊能否滿足在需求分析中得出的功能性需求并測試系統能否在高并發量下快速響應用戶請求且穩定運行。

6.2新型藥物臨床信息管理系統的測試方法

因為本系統主要是提供給北京某抗結核新藥引入和保護試點項目進行新型藥物臨床信息管理的系統，主要測試目的為系統能否滿足項目的全部需求，所以在功能性測試中采用的測試方法為黑盒測試；黑盒測試是將測試對象看做一個黑盒子。利用黑盒測試法進行動態檢測時，需要檢測軟件系統的功能，不需要測試軟件產品的內部結構和處理邏輯。黑盒測試主要側重于軟件的需求功能測試，主要目的是通過較少的測試用例，覆蓋系統的功能需求，盡可能去發現更多的問題。黑盒測試在軟件測試過程中的應用范圍十分廣泛，主要優點有下面幾點：（1）直接從用戶的功能需求出發，可以更容易的知道用戶在使用過程中會使用什么樣的功能，遇到什么樣的問題；（2）測試人員不需要像開發人員一樣了解項目代碼的具體邏輯和開發過程中使用的編程語言；（3）測試效率較高。無論哪種測試方法都不能全面的覆蓋系統的全部測試點，只能設計較為詳盡的測試用例來來發現更多的問題。同時由于本系統需要滿足多地多人同時使用系統時，系統能夠正常穩定的運作，所以對系統的非功能性測試主要進行性能方面的測試，即使用 Apache Jmeter測試工具模擬高并發情況，通過系統的請求響應時間分析系統的性能。

6.3新型藥物臨床信息管理系統的測試環境

為了對新型藥物臨床信息管理系統的功能以及系統的穩定性進行測試，以及為了搭建系統的測試環境，將系統的后臺服務運行在一臺服務器上，測試客戶端為一臺電腦，主要進行系統的功能性和非功能性測試；系統的軟件測試環境采用的操作系統為Mac OS； Web服務器采用Nginx-1.13.4數據庫使用MySQL數據庫，系統測試使用的調試軟件為Pycharm,瀏覽器選擇IE瀏覽器，火狐瀏覽器，谷歌瀏覽器三種不同的瀏覽器系統，通過在不同種類的瀏覽器上運行，查看系統的功能能夠兼容不同的瀏覽器；以及性能測試工具采用的Apache開源的Jmeter 測試工具。

6.4新型藥物臨床信息管理系統的功能測試

下面將對新型藥物臨床信息管理系統的系統測試環境以及患者管理模塊及其子功能和統計報表模塊及其子功能的測試用例設計進行介紹。

6.4.1患者管理模塊功能性測試

本系統作為新型藥物臨床試驗過程中使用的信息管理系統，核心功能需要滿足臨床試驗過程中產生的需求，系統的主要角色醫生在該模塊主要需要對患者進行新增患者和CRF表的錄入兩種操作，所以針對這兩個功能進行測試。

新增患者的主要功能是填寫新增患者的詳細信息，進行入組判定，正確存儲患者信息，新增患者功能測試的測試用例如表6-1所示；入組成功后提示該患者添加成功，系統界面截圖如圖6-1所示；

表6T新增患者功能測試測試用例

測試編號 Test Casel

名稱新增患者功能測試

測試目的驗證系統的新增功能是否能夠滿足用戶的需求并正確的運行。

預置條件新型藥物臨床信息管理系統已經運行在系統服務器中，用戶A在數據庫的用戶表中，且用戶具有患者管理模塊的權限。

續上表

測試步驟：

1.用戶A鍵入正確的用戶名、密碼、驗證碼并成功登錄系統2.點擊患者管理模塊右側上方的添加新患者按鍵

3.填寫彈出表單的全部必填項，點擊下一步

4.跳轉入組排査頁面，填寫入組排査彈出的表單，點擊確定

5.彈出提示框，確定患苕入組，點擊確定

預期結果：

如杲患者滿足全部入組判定，患者入組、患者信息展示在患者管理模塊首條并且在用

戶A的工作臺的待處理tab下展示該患者信息。

測試結果：

患# n:.確入組，患者信息正常展示在患者管理模塊首條,在用戶a的】:作臺的待處理tab F展示該患者的信息。

o r>ues nWnfGFd—1—ir!

合入

vfGtrw

■ Betrw <

圖6-1添加患者成功系統界面截圖

CRF表錄入主要針對醫療記錄錄入、治療方案查看和不良反應上報接口進行測試：

醫療記錄錄入子模塊主要是提供給醫生錄入患者在試驗過程中患者的各項身體情況以及醫生的治療方案的功能，醫生將依據實際需求完成該患者的治療階段的選擇、項目的選擇以及填寫具體的檢查項目的檢查數據；下表6-2展示了醫療記錄錄入功能測試的測試用例；醫療記錄保存成功后，系統界面上方彈出保存成功的提示，系統界面如圖6-2所示。

表6-2醫療記錄錄入功能測試測試用例

刪影翳床謐信患

圖6-2醫療記錄保存成功系統界面截圖

治療方案子模塊的主要功能是提供給用戶添加、查看和編輯患者的用藥情況，比如說患者服用的藥物名稱、給藥途徑、總量、開始時間、結束時間等。通過表格和圖表的形式直觀的向用戶展示患者的用藥情況。用戶在點擊指定患者的治療方案子模塊時，界面上方展示患者的基本信息、治療、當前用藥三個tab；下方展示當前用藥的圖表，每種用藥以不用顏色的方格展示；下方展示患者用藥情況的列表；下表6-3展示了治療方案子模塊界面展示測試的測試用例；治療方案正確展示的系統界面如圖6-3所示。

表6-3治療方案子模塊界面展示測試測試用例

測試編號 Test Case3

名稱治療方案子模塊界面展示測試

測試目的驗證新型藥物臨床信息管理系統的治療方案界面是否正確展示

預置條件新型藥物臨床信息管理系統已經運行在系統服務器中，用戶A在數據庫的用戶表中，且用戶具有患者管理模塊的權限。

測試步驟：

1.用戶A鍵入正確的用戶名、密碼、驗證碼并成功登錄系統，在工作臺點擊對應患者的tat

2•彈出患者信息頁面并選擇當前頁面的治療方案模塊

3.彈出治療方案系統界面

預期結果：

系統界面上方展示患者的基本信息、治療、當前用藥三個tab；下方展示當前用藥的圖表，每種用藥以不用顏色的方格展示；下方展示患者用藥情況的列表。

測試結果：

系統和預期結果相同，正確展示系統界面。

肖IR用西

局 12 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 26 26 27 28 29 30 31 32 33 M 3S 36 37 38 39

圖6-3治療方案正確展示系統界面截圖

不良反應上報接口子模塊的主要功能是系統在接收到醫生提交的不良反應信息后，將立刻自動向項目辦某一指定負責人提供的接收不良反應的電子郵箱發送不良反應上報郵件。該負責人在收到該郵件后需要對郵件進行回復，以保證郵件被正確接收。本系統發送郵件后五分鐘內如果未收到該項目辦負責人的回復，將再次發送該項不良事件，并等待接收該項目辦負責人的回復。如果重發五次仍得不到該項目辦負責人的回復，該項目辦負責人的手機發送提醒短信。下表6-4 展示了不良反應上報接口功能測試的測試用例：

表6-4不良反應上報接口功能測試測試用例

測試編號 Test Case4

名稱不良反應上報接口功能測試

測試目的驗證系統的不良反應上報接口是否能夠滿足用戶的需求并正確的運行。

預置條件新型藥物臨床信息管理系統已經運行在系統服務器中，用戶A在數據庫的用戶表中，且用戶具有患者管理模塊的權限。項目辦指定負責人的賬號是yarving,郵箱為

yarving* * * @gmaiLcom,電話號碼為

1881010****

續上表

測試步驟：

1.用戶A鍵入正確的用戶名、密碼、驗證碼并成功登錄系統，在工作臺點擊對應患者的tat

2.彈出患者信息頁面并選擇當前頁面的不良反應模塊

3.彈岀不良反應界面，點擊添加按鈕，添加該患者岀現的不良反應

4.對彈出的不良反應表單的必填項進行填寫，填寫完成后點擊保存

5.項目辦指定負責人收到郵件不進行回復（不點擊郵件的確認鏈接）預期結果：

系統正確保存該條不良信息的數據，并向y arving* * * @gamil.com發送郵件，郵件內容為該條不良信息的詳細情況，五分鐘后再次收到內容為該條不良信息的郵件，十分鐘后再次收到，十五分鐘后再次收到，二十分鐘后再次收到，二十五分鐘后電話號碼為 1881013****的手機收到內容為該條不良反應信息的短信。

測試結果：

系統正確保存該條不良信息的數據，20分鐘內yarving***@gamiI.com郵箱收到五條內容為該條不良反應的郵件，保存信息后的第25分鐘收到提示不良信息的短信。

6.4.2統計報魏（塊的功能性測試

統計報表模塊的主要功能是讓用戶能夠直觀的查看患者的藥物使用情況、隨訪情況、治療轉歸情況和不良反應統計情況；下表6-5展示了統計報表功能測試的測試用例；用例描述：對統計報表模塊的患者的藥物使用情況、隨訪情況、治療轉歸情況和不良反應統計情況三個功能進行測試，查看能否正確的展示患者對應的表格或圖標；點擊統計報表系統，系統的界面截圖如圖6-4所示。

表6-5統計報表模塊功能測試測試用例

測試編號 Test Case5

名稱統計報表模塊功能測試

測試目的驗證點擊某一功能能否正確展示該功能對應的

表單

預置條件新型藥物臨床信息管理系統已經運行在系統服務器中，用戶A在數據庫的用戶表中，且用戶具有統計報表模塊的權限；系統的數據庫已經具有-定的測試數據（患者信息）

續上表

測試步驟：

1.用戶A在進行系統登錄后，在工作臺點擊對應統計報表右方的折疊按鈕

2.彈出統計報表的下拉菜單，點擊患者藥物使用情況統計

3 .點擊患者隨訪情況統計

4.點擊患者治療轉歸情況統計

5.點擊不良反應統計

預期結果：

點擊折疊按鈕后，彈出“患者藥物使用情況”、“患者隨訪情況”、“患者治療轉歸情況”、“不良反應”四個下拉菜單；點擊患者藥物使用情況，界面展示用藥分布柱狀圖；點擊患者隨訪情況，界面展示患者隨訪情況的柱狀圖和折線圖；點擊患者治療轉歸情況，界而展示一張折線圖和兩張柱狀圖；點擊不良反應按鈕，界面展示不良事件嚴重程度分級統計、嚴重不良事件類型統計、不良事件結局統計、不良事件名稱統計四張表格

測試結果：

同預期結果相同，界面展示出相應的報表。

艇融臨床雌信息

• Si的工作白

用藥分布

a 'nn«s

當前用藥分布

6.5新型藥物臨床信息管理系統的非功能測試

由于新型藥物臨床信息管理系統是面向多用戶的軟件系統，所以系統的非功能測試設計為主要針對系統的性能進行測試測試，即測試系統的實際用戶負荷能力，保證在多用戶并發請求系統時系統能夠正確、穩定的運行。

6.5.1性能測試

對于新型藥物臨床信息管理系統的性能測試而言，主要是為了滿足本系統在多地多人同時對系統進行操作時，系統能夠穩定的運行并且能夠快速的對用戶的交互進行響應。針對本系統需要同時滿足100人（該數量大于項目辦提供的預計參與項目的醫生數）在線同時操作系統的特征；選擇使用Apache Jmeter測試工具來模擬高并發訪問系統，并通過系統的請求響應時間分析系統的性能。根據項目辦提供的需求上看，本項目目前共9家醫院參與；最大峰值為每小時會有 60個臨床試驗的患者的信息需要記錄，即60個醫生需要同時登錄系統對患者的監測項目進行記錄；同時由于參與項目的醫生大約有80人左右，所以需要模擬 100人同時色錄系統」L100人同時向系統發送詰求或進行查詢,并對請求和查詢操作循環100次來模擬系統在使用過程中出現的最高峰值，依據上述項原因，系統制定了以下的系統性能測試的測試川例，如下表6-6所示：

表6-6系統性能測試用例表

測試用例并發用戶量循環次數測試內容

登錄測試 100 10 系統響應時間

訪問請求測試 100 100 系統響應時間

査詢功能測試 100 100 系統響應時間

在Jmeter中依據測試用例，通過在工具中對測試接「I urk模擬的用戶量值、模擬循環次數值等變量值的設置來分別進行上述測試用例表中的測試用例：登錄測試的測試結果如下圖6-5所示：

K 塚啊聽馭、 SU "3* $ 解棚

”w • - •'» . ■；' ”； 1-；

躺 »» U E IK* 冷祝 {£413 m

圖6-5登錄測試Jmeter測試結果

訪問請求測試的測試結果如下圖6-6所示：

at 軟3 g tte s«* 約

圖6-6訪問請求測試Jmeter測試結果

查詢功能測試的測試結果如下圖6-7所示:

Jii nt 坯a 飲填曲 E像 st、 SA 挾毆鬚念》奨君

'^=j^ ~~ ~ i? $ ui" 海亍

Si *燃 S： : 闕 2K15 轉瑪 StSK SSrS MS iXiti

圖6-7查詢功能測試Jmete r測試結果

根據Jmeter的測試結果可以看到，相對于登錄和訪問功能來講，查詢功能所耗的時長更長，同時在100個以內的用戶并發訪問系統時，系統的響應時間小于 2秒，使得系統和用戶的交互能夠十分流暢。同時測試結果也展示了最大的響應時間為9秒，這個結果表明在100人同時和系統交互時，個別用戶的系統響應時間將會相對較慢。綜合考慮系統的實際使用情況，很少出現同時100個醫生同一時刻同系統進行交互，現有系統的設計已經可以滿足實際情況的使用，如后續增加系統用戶，可考慮增加服務器來處理更高量的并發請求。

6.6測試結果分析

在本章的系統測試中，系統現有功能已可以滿足用戶目前的需求，新增患者, 查詢患者，單位管理，權限管理以及統計報表的功能基本完善，可以滿足醫生、項目辦成員、院領導的需求，系統的性能也可滿足當前的用戶需求；主要功能與非功能測試結果如表6-7所示。但是系統的醫療記錄的功能還需完善，醫療記錄中項目的種類較少，醫生在對患者進行某項身體指標進行檢測時，部分檢測項目不能直接從系統中選擇，需要再次提需求，進行功能迭代，所以需要依據項目的進行在醫療記錄的項目選擇中添加更多的身體指標項目，并且提供醫生可手動增加醫療記錄項目的功能；且系統的性能雖然能夠滿足現有的用戶需求，但當用戶量增加時，系統的最大響應時間較長，可在后續的系統迭代中對系統的性能進行提升。

表6-7功能測試結果分析

編號功能點子功能測試日期是否

通過

TestCase_

1 新增患者功能填寫患者信息，完成入組篩選，將該患者的信息展示在工作臺的待處理tab 2019.01.30 是

TestCase_

2 醫療記錄錄入流

程選擇治療階段、身體檢測項目，對患者信息進行疋確填寫 2019.01.30 是

TestCase_

3 治療方案子模塊

界面展示展示各治療周期中患者的用藥情況、展示用藥詳情 2019.01.30 是

續上表

TestCase_

4 不良反應上報接

口流程對不良反應的詳細信息上報在指定人的郵箱，如果沒有收到回復根據系統重發機制進行處理 2019.01.30 是

TestCase_

5 統計報表功能患者藥物使用情況統計、患者隨訪情況統計、患者治療轉歸情況統計、不良反應統計 2019.01.30 是

TestCase_

6 藥品管理功能藥品清單、藥品統計 2019.01.30 是

TestCase_

7 用戶管理功能用戶新增、用戶編輯、用戶刪除、用戶查詢 2019.01.30 是

TestCase_

8 單位管理功能單位新增、單位編輯、單位刪除、單位查詢 2019.01.30 是

TestCase_

9 日志管理功能日志分頁展示、H志查詢 2019.01.30 是

TestCase_

10 性能測試登錄功能性能、查詢功能性能、訪問請求性能 2019.01.30 是

6.7本章小結

在系統測試環節，依據系統本身的特點，選擇合適的測試方法對新型藥物臨床信息管理系統的各個模塊實施功能測試，并進行了性能測試，在多個用戶同時進行并發操作時，系統的相應時間會產生一定的延遲，但還在可接受的范圍內，同時在測試過程中，發現系統已滿足用戶現有的需求，但是部分功能還需在日后的迭代中不斷完善。

第七章結束語

7.1論文工作總結

新型藥物臨床信息管理系統是抗結核新藥引入和保護試點項目現在正在使用的一個藥物臨床信息管理系統，現在已在線上運行，并且還在不斷功能迭代中。主要實現的模塊包括：登錄認證與個人信息模塊、患者管理模塊、統計報表模塊、藥品管理模塊、用戶管理模塊、單位管理模塊和日志管理模塊。目的是對醫護人員及項目管理人員進行藥物供應與管理、用藥患者遴選、用藥方案制定、患者治療管理及用藥監測、耐藥等方面的信息進行全程管理，以期保障患者用藥安全、記錄規范標準、提高患者治療效果。

本系統整體開發采用的是服務器/瀏覽器架構模式，后臺采用Django進行三層結構分離，數據庫采用My SQL數據庫。三層架構模式使得系統各個模塊之間低耦合，模塊內部高內聚，使得系統在不斷的迭代開發過程中能夠更便捷的完成開發任務。目前系統的開發在CRF表錄入中項目的選擇還不夠完善，其他功能模塊功能均基本完善。

本文主要對系統的研究意義和背景、技術的選擇、需求分析、總體設計和詳細設計、系統測試這六部分進行描述，將在開發過程中對系統的設計與思考進行詳細的闡述，使得本人對系統的開發過程有了非常深入的理解。通過本次項冃的實際開發，遇到了很多在實際開發中才會遇到的問題，學習了很多開發的知識；在系統的不斷迭代中，明白了軟件系統開發是一個不斷學習的過程，在解決問題的過程中成長。

7.2問題和展望

目前新型藥物臨床信息管理系統的登錄認證與個人信息模塊、患者管理模塊、統計報表模塊、藥品管理模塊、用戶管理模塊、單位管理模塊和日志管理模塊已經基本完善，但是醫生在填寫CRF表的項目選擇中還需要繼續迭代，添加更多的項目選擇，并能支持醫生自己添加所需的檢測項目，更好的完善用戶的需求，同時系統在安全性上的工作還需要增加。

因項目已經上線運行，現在的系統已滿足用戶第一階段的需求，在接下來的時間里，將會繼續對新型藥物臨床信息管理系統的開發進行研究和迭代，主要研究和迭代內容如下所示：

1.增加用戶在CRF表填寫過程中可以新增檢測項目的功能。

2•在統計報表中可以引入一些預測算法，使用算法對患者在治療過程出現身體指標變化進行預測。

3.目前的新型藥物臨床信息管理系統已經基本滿足抗結核新藥引入和保護試點項目辦的要求，但是在后續的迭代中可以深入的了解用戶在使用現有系統時出現的問題，并加以完善。

4•在項目的后臺開發中，代碼的可重用性需要提高，減少現有代碼的冗余度。

5.項目現在對權限控制的實現依賴于三個字段，在后續系統迭代中可以將三個字段變為一個字段，通過這個字段取不同的值來區分不同的角色。

5.增加數據庫備份，保證系統的數據安全性。

文獻

[1]唐神結，肖和平新世紀我國結核病的新特點及防治策略[J],中國實用內科雜志.2011(06)

[2]吳靜，徐建，張映銘，王彩英丫-干擾素釋放試驗對活動性肺結核的診斷價值[J],中華實用診斷與治療雜志，2011(25)

[3]張丹娟，周少丹，劉麗藥物臨床試驗信息管理系統的設計及應用[J],中國數字醫學， 2017(04)

[4]賓哲桂，羅永有醫院信息管理系統數據庫設計模式研究與實踐[J],大眾科技，2016(03)