基於Bootstrap框架的臨床資料管理系統的設計與開發
基於Bootstrap框架的臨床資料管理系統的設計與開發
2018年11月10日
目 錄
第一章緒論... 6
1.1 選題背景及其意義... 6
1.2國內外研究現狀... 7
1.2.1 臨床大資料管理系統發展現狀... 7
1.2.2醫療電子表單管理髮展現狀... 8
1.3研究目標... 9
1.4 研究內容... 10
1.5論文整體結構... 10
第二章相關技術研究... 12
2.1 AngularJS技術簡述... 12
2.2 RESTful API +swager 13
2.3 Oauth2.0身份驗證... 15
2.3.1 OAuth2.0. 15
2.3.2 協議流程... 15
2.3.3 Authorization Grant 16
2.4 Bootstrap視覺化佈局... 17
2.5 Data Migration. 19
2.6本章小結... 19
第三章需求分析... 20
3.1使用者許可權分析... 20
3.2 分系統需求分析... 21
3.2.1研究資訊管理子系統... 21
3.2.2專案管理子系統... 22
3.2.3質量管理子系統... 23
3.2.4資料匯出子系統... 24
3.2.5系統配置管理子系統... 25
3.3系統安全性需求分析... 26
3.3.1 身份認證技術實現... 26
3.3.2 基於角色的訪問控制策略... 28
3.3.3 AES和RSA混合加密演算法的設計與實現... 28
3.4本章小結... 30
第四章系統設計... 31
4.1設計的原則和目的... 31
4.2 系統應用架構設計... 32
4.3 系統總體流程設計... 35
4.3.1 資料錄入流程... 35
4.3.2 資料欄位匯出流程... 35
4.3.3 資料刪除流程... 36
4.4功能結構設計... 37
4.3.1 登入管理子系統... 37
4.3.2研究資訊管理子系統... 40
4.3.3專案管理子系統... 42
4.3.4質量管理子系統... 42
4.3.5 資料匯出子系統... 43
4.3.6系統配置管理子系統... 44
4.4 系統流程設計和E-R圖設計... 46
4.5資料庫設計... 46
4.5.1系統使用者相關表... 46
4.5.2專案配置相關表... 46
4.5.3選單操作許可權相關表... 47
4.5.4表單部件配置相關表... 48
4.5.5表單規則相關表... 49
4.5.6案例資料相關表... 50
4.5.7質疑相關表... 51
4.5.8其他相關表... 51
4.3.9系統E-R圖設計... 52
4.7 本章小結... 53
第五章 系統實現與測試... 54
5.1測試環境... 54
5.2 系統各子系統實現與測試... 54
5.2.1 系統登陸和註冊子系統... 54
5.2.2 研究資訊管理子系統... 55
5.2.3 專案管理子系統... 57
5.2.4 質量管理子系統... 59
5.2.5 資料匯出子系統... 61
5.2.6 系統管理子系統... 62
5.3 胃癌核心資訊資料庫案例測試與研究... 67
5.3.1 案例實現... 67
5.3.2 結果研究... 67
第六章總結與展望... 68
6.1總結... 68
6.2展望... 68
主要參考文獻... 70
摘要
臨床資料由於存在資料結構複雜、資料量大等問題，使得臨床科研很難有足夠的資料作為支援，尤其是很多臨床科研資料存在於單個醫院，甚至是單個部門，這種資料孤島現象使得臨床科研工作的開展備受阻力，資料瓶頸問題已經成為阻礙臨床科研進步的重點難題，亟待解決。
我國科研資料管理系統雖然較以往有了很大的發展，但當前資料管理系統大多數是為單一部門的使用而設計、實現的，缺少全域性性的考慮，難以應用於複雜部門關係的領域，如果應用於醫療系統，則將會有很多工作需要人工去彌補完成，造成人力資源極大的浪費。且當前資料管理系統缺少監督機制，資料錄入進度難以掌控，同時也缺少問題反饋機制，還需要人與人之間私下溝通解決，效率低下，也缺少成熟的平臺去解決問題。所以目前的絕大多數資料管理系統難以應用於實際業務，其應用普及度、可擴充套件性、安全性等因素都需要進一步提高，且關於臨床醫療資料管理的系統更是少見。基於這些考慮，本文開發一套可以應用於實際工作的臨床科研資料管理系統用於管理臨床領域醫療資料，以提高臨床科研效率。
在應用現代軟體工程理念和技術的基礎上，通過對現代醫療領域的臨床科研工作的實際需求進行深入分析，完成了臨床科研資料管理系統的設計，構建了系統整體架構、各子系統功能模組和資料庫表結構的詳細設計，基於ASP技術實現了該系統的各項功能。最後基於Windows平臺、IIS伺服器、SQL Server 2008資料庫系統等環境對系統進行執行測試，測試結果表明該系統實現了高效資料採集、資料儲存、資料管理和資料分享醫療領域的科研資料且系統能夠穩定執行。
關鍵詞：科研資料管理系統；醫療系統；資料分享
Abstract
Because of the complex data structure and large amount of data, it is difficult for clinical research to have enough data to support it. Especially, many clinical research data exist in a single hospital or even a single department. This phenomenon of data islands makes the development of clinical research work very difficult. Data bottleneck has become a key problem that hinders the progress of clinical research. It needs to be solved urgently.
Although our country's scientific research data management system has made great progress compared with the past, most of the current data management systems are designed and implemented for the use of a single department, so lack of overall consideration, it is difficult to apply in the field of complex Department relations. If applied to medical systems, there will be a lot of work to be done manually, resulting in waste of human resources. At present, the data management system lacks supervision mechanism, data entry progress is difficult to control, and there is also a lack of problem feedback mechanism. It also needs private communication between people to solve problems. It is inefficient and lacks a mature platform to solve problems. Therefore, most of the current data management systems are difficult to be applied to actual business, and their application popularity, scalability, security and other factors need to be further improved, and the clinical medical data management system is rare. Based on these considerations, this paper develops a data management system for clinical scientific research that can be applied to practical work to manage medical data in clinical field, so as to improve the efficiency of clinical scientific research.
Based on the application of modern software engineering concepts and technologies, through in-depth analysis of the actual needs of clinical scientific research in modern medical field, the design of data management system for clinical scientific research has been completed. The overall structure of the system, the functional modules of each subsystem and the detailed design of database table structure have been constructed. The functions of the system have been realized based on ASP technology. Finally, the system is tested based on Windows platform, IIS server, SQL Server 2008 database system and other environments. The test results show that the system achieves efficient data acquisition, data storage, data management and data sharing in the field of medical research data, and the system can run stably.
Key words: scientific research data management system; medical system; data sharing
第一章緒論
1.1 選題背景及其意義
機器學習技術和大資料時代的來臨使得大規模的資料的產生、管理、應用的時機和資料的用途越來越得到廣泛關注。尤其是普遍為人所用的通訊業務、社交網路、電商網路等也加速了資料的傳播與產生[1]。大資料，這一新興的領域也日漸成為社會中一項不可或缺的基礎資源，其意義不僅體現在資料量的“大”上，更體現在資料內部所蘊含的資訊資源。但隨之而來的問題是資料的管理成為了一項令人棘手的問題，資料量級的增大帶來了管理的難度、共享的需求度、傳輸的通道壓力等等問題，臨床科研領域同樣面臨著類似的問題，亟待解決[2]。
近年來，醫療資訊化成為現代醫院的一大趨勢，這不僅體現在數字化的醫療資訊管理，也體現在現代化的高效的資料管理能力[3]。但目前絕大多數醫院的醫療資料僅僅侷限於醫院內部使用，甚至僅僅侷限於科室內部使用，資料孤島現象極為嚴重。這種醫療資料的資訊孤島現象體現出我國醫院與醫院之間、醫院與管理部門之間的各自為戰現象，也體現出我國醫療衛生現代化建設的癥結所在[4]。2010年，原衛生部推出了“十二五”醫療衛生資訊化建設規劃，簡稱為3521工程，3表示建設國家、省、城市的3級衛生資訊化平臺，以此提高我國衛生服務的質量、醫療服務水平、新農村合作的醫療水平、基本藥物制度和綜合管理等五項內容，建立電子病歷和健康檔案資料庫和網路；按照這個需求制定的實施方案將會產生及其巨大的資料量，其中一張普通的CT的大小可以達到150M，一張普通的基因序列記錄的資料大小大約為750M，一張病人的病理圖甚至可以達到5G的資料量，如果再考慮到人口基數和不同時間點進行的不同診斷，則資料量的積累將難以極速爆炸[6]。在資料採集階段，醫療臨床資料包含大量非結構化的病理資料和病人健康情況資料，如果不能採取合理的方法採集資料則會造成資料採集過程中存在錯誤資料的情況[7]；在資料分析階段，如果海量資料僅僅存在於單一的醫院、甚至是單個部門中，則會造成花費巨大力氣採集的資料難以被最大化的使用。所以臨床醫療資料採集、管理平臺的建設刻不容緩，以使得臨床醫療可以被標準化的採集、規範的管理和更廣泛的共享[8]。
臨床醫療將不是某一家醫院或醫院某一部門的專有資源，高效的實現海量、異構資料的採集、管理、儲存和分享等方面將對臨床科研的進步有很大幫助，也能促進臨床資料更廣泛的共享。海量的臨床醫療資料也是臨床科研開展的基礎，如果沒有資料支援，將無法開展科研工作，所以如何實現臨床科研資料的有效管理成為了本文的研究重點。
1.2國內外研究現狀
1.2.1 臨床大資料管理系統發展現狀
目前國內還沒有關於臨床科研資料管理的文獻，臨床科研資料管理系統的構建也更是處於國內空白，只有少數相關的內容能夠借鑑。其中蔡佳慧等人[9]發現了我國衛生資訊化建設的速度越來越快，醫療領域所接收的資料量越來越大、資料型別複雜，醫療領域已然進入了大資料時代。在分析現代醫療領域特點的基礎上總結了現代醫療領域所面臨的資訊化建設的挑戰和需求，並結合具體情況提出了可行的措施。周光華等人[10]在分析了現代醫療衛生領域特點的基礎上判斷了醫療衛生領域大資料時代的來臨，在概述大資料時代各行業的情況的基礎上綜述了我國醫療衛生資料資源的分佈情況和在醫療領域的應用情況，提出了當前大資料醫療所面臨的重點和難點，併為行政部門提出了參考意見。林青等人[11]提出了智慧社群醫療系統的總體結構、系統組成以及軟體功能。智慧社群醫療系統能夠採集、查詢、管理、統計社群醫療衛生資料並將資料進行雲管理，實現社群醫療資料的雲管理和網際網路服務。殷煥炯[12]在分析了現代醫療資訊化特點的基礎上探索了大資料在現代醫療領域方面的應用現狀。針對大資料的基本概念和醫藥研發、疾病診斷、衛生管理的特點進行分析和研究，為新時代大資料的應用方式、理論提供依據。盛芳菲等人[13]提出了一種基於Hadoop的智慧醫療資料儲存和查詢方法，能夠實現結構化資料和非結構化資料的儲存，提高了資料儲存、管理的可靠性和擴充套件性，並優化了醫療圖片資料的效率和儲存方式，採用分散式的方式實現管理系統提高了資料訪問的效率和資料分享的效果。Gary Cohen等人[14]將醫療資料管理系統部署到網際網路中實現對病人醫療資料的管理，通過網際網路遠端獲取資料的優勢實現了對慢性病的長期監測，獲取病人的病理資料，並實現對資料的分析為患者提供治療意見。M Fuminori等人[15]提出了一種病人、醫務人員和通訊網路上的研究人員可以共享醫療資料的醫療資料管理系統，該系統能夠儲存病人治療期間的醫療資料，並向患者公開醫學資訊、執行有效的遠端診斷以及向醫學研究提供醫學資料等服務。Liu，Zhao等人[16]針對人工處理資料、人工開發介面生成工具等傳統辦法所面臨的困境提出了一種基於XML文件的介面生成和資料訪問的快速開發模型，並將其應用於醫學臨床資料管理系統的開發中。該模型包括兩個部分：介面生成引擎和資料自動訪問機制，使用抽象工廠模式來構造、應用面嚮物件語言的多型技術和反射技術進行實現，從而可以在各種資料庫和應用平臺之間快速切換，不僅節省60%的設計時間，也提高了系統的開發效率和可維護性。Karin Probst[17]提出了人力資源資訊系統（HUMARIS），該系統是由國家癌症研究所研發的自動化醫療資料採集和管理系統。該系統的設計容量為每年處理、儲存和檢索多達1500例外科和屍檢病例的臨床和調查資訊，提供診斷清單、病例摘要、庫存、統計報告等內容。該系統的功能相對簡單，但能夠有效的採集和管理醫學資料。
1.2.2醫療電子表單管理髮展現狀
我國經濟的告訴發展使得國家、社會對臨床科研的成果需求也更高，與此同時的投入的越來越多，醫院的科研水平也作為核心競爭力顯得日益突出。當前情況下的科研資料管理系統仍不普及，很多科研工作者仍然使用人工的方式進行資料採集、處理、分享和管理等[18-20]，有些使用諸如excel等半自動化的方式進行資料的管理和處理，這種資料管理方式的問題主要有：（1）資料屬性複雜時，管理難度很大；（2）資料手工錄入，容易出現認為錯誤；（3）難以維護，容易發生奔潰導致資料丟失；（4）效率地下，沒有利用現代化的資訊化手段。所以，臨床科研資料管理系統的需求度越來越高，合理的利用現代化的智慧手段進行資料的採集、管理、分享、維護等操作，不僅可以大幅提高資料管理效率，而且能降低人力成本的同時減少認為錯誤的發生，使臨床科研資料的管理更加智慧化、高效化和資訊化。
目前，一些高校率先建立了科研資訊管理系統用於科研資訊的管理，網路上也有一些做好的資料管理系統，但對於臨床科研領域的資料管理顯得有些不足，主要是因為：（1）高校的科研資訊管理系統大多數處於實驗狀態，實用性偏差，難以用於實際的工程應用；（2）網際網路公開的資料管理系統功能通常較為簡單，且可擴充套件性、安全性等要素缺少系統設計，考慮因素不足，在實際使用中難以穩定執行；（3）這些管理系統大多數是為單一部門的使用而設計、實現的，所以缺少全域性性的考慮，難以應用於複雜部門關係的領域，如果應用於醫療系統，則將會有很多工作需要人工去彌補完成，造成人力資源的浪費；（4）缺少監督機制，資料錄入進度難以掌控，同時也缺少問題反饋機制，還需要人與人之間私下溝通解決，效率低下，也缺少成熟的平臺去解決問題；（5）系統中缺少對資料格式的統一定義，在資料傳輸時需要資料格式轉換或資料屬性的拋棄以適合其他系統，導致資料完整性受到破壞，也難以普及系統。
通過上述總結可以看出，在當前情況下建構高效的臨床科研資料管理系統是十分必要且十分緊急的任務，高效、準確的資料管理和完備的系統管理對於提高當前臨床科研水平將有巨大幫助。當前情況下，科研資料管理系統日益朝著大眾化、可用化、智慧化的方向發展，主要的原因是計算機硬體裝置效能的提高和硬體價格的降低，使得個人、單個團體部署個人的網路應用系統成為可能，這些客觀條件使得管理系統如雨後春筍一般大量出現，逐漸取代人工。由於近年來網路成本的降低、效能的提高，使得管理系統的開發也從傳統的C/S結構過度到了B/S架構，甚至是基於B/S的分散式架構、雲架構等結構，大幅提高了管理系統的效能和安全性。
現代的基於網際網路的B/S架構的資料管理系統的訪問結構通常是瀏覽器/伺服器的結構，主要是在瀏覽器端輸入、發出請求，在伺服器端實現系統的功能並返回處理結果到瀏覽器端，瀏覽器解析出伺服器返回的結果並輸出到螢幕上供使用者使用[21]。這種訪問方式需要在系統的伺服器端運營網路應用成功、資料庫系統等應用，而客戶端只需要普通的瀏覽器即可完成服務，與傳統的管理系統相比對客戶端效能的要求更低，其訪問者不受地域、時間、平臺的限制，能夠實現任意地點、任意時間的對伺服器的訪問以獲取所需的資源。且伺服器端的維護成本、維護難度也較C/S結構更容易，也最大限度的共享了網路資源。目前，國內大多數資料管理系統都是基於區域網而建設的，基於網際網路的資料管理系統仍然處於起步階段，亟待解決[22]。
通過上述論述可以發現，我國科研資料管理系統雖然較以往有了很大的發展，但絕大多數產品難以應用於實際業務，其應用普及度、可擴充套件性、安全性等因素都需要進一步提高。基於這些考慮，本文開發一套可以應用於實際工作的臨床科研資料管理系統用於管理臨床領域醫療資料，以提高臨床科研效率。
1.3研究目標
我國經濟總量已經躍居世界第二且發展勢頭不可阻擋，全面小康化也馬上達到，在此階段下，普通人對醫療的關心和需要也越來越高，如何提高現有醫療水平稱為一項重點研究內容，而實現這一目標的有效手段就提高臨床醫療科研水平，而海量、可用的臨床資料的保證是科研高效開展的前提，所以臨床醫療資料的採集、管理和分析成為了各醫療機構普遍關心的議題。
正是基於這樣的考慮和需求，很多醫療機構都認識到了醫療資料對於醫院未來發展的用處，也意識到了臨床資料在醫院管理、醫療水平提高、臨床科研水平提高等方面所蘊含的高價值。很多醫院都成立了資料管理平臺並建構了資料管理系統，但普遍僅僅做了最基本的工作，僅僅收集了最基礎的資料，沒有系統的收集醫療領域的資料。
本文考慮到這些需求，將構建一套能高效管理海量的、多樣化、異構的醫療資料管理系統為研究目標，以實現臨床醫療資料的高效管理、提取和分享。通過對儲存的海量醫療資料的分析，能夠分析出病人身體狀況與病症之間的關係、病症之間的關係、為病人自動推薦治療方案或緩解策略、系統性的評估個人的身體狀況等結果，通過臨床科研能夠實現這些分析結果或服務，以此提高患者的健康狀況，為全民的健康狀況所服務。因此，本論文研究的海量異構臨床科研資料管理系統在提高全民身體將康水平、提高醫療科研水平等方面具有積極地、重要作用。
1.4 研究內容
通過分析醫療領域的潛在需求、挖掘領域現存的問題，並利用現代化的軟體工程技術和資料管理技術，針對臨床科研資料管理存在的特點和難點進行著手，構架了用於管理海量、異構的臨床科研資料的管理系統。主要的工作內容為如下所述。
1、通過對國內外相關研究專案的論述和分析，闡明瞭本文的研究背景和研究意義；
2、研究並學習了ASP技術、SQL Server 2008技術、UML技術等內容，並將這些技術用於構建臨床科研資料管理系統；
3、針對醫療領域和科研領域的特點對系統各角色使用者的需求進行深入挖掘，分析出了各角色使用者最需要的功能；
4、利用現代化的軟體工程技術設計並實現了臨床科研資料管理系統，並搭建環境進行測試。
1.5論文整體結構
第一章是總體介紹本文研究的背景和意義，闡述了為什麼開展此項工作，並結合國內外的研究現狀說明了本文的研究目標和研究內容。
第二章介紹了本系統設計與實現過程中需要的技術，首先說明了ASP技術的原理、特點、資料訪問控制模型和系統應用的資料庫系統，之後介紹所用整合開發環境Visual Studio 2010和軟體工程建模工具UML，最後介紹了構建資料倉庫的理念。
第三章為系統的需求分析內容。首先介紹了系統的三種類型的角色和每種角色的實際需求，之後對系統的整體結構和各子系統的結構進行了詳細說明，最後對系統的非功能性需求進行了闡述。
第四章為系統設計部分。首先闡述了系統的設計原則、目的和系統整體架構，之後從結構圖、流程圖和時序圖等方面對系統給的各子系統的設計進行了詳細說明，後續對系統流程設計和E-R圖設計進行描述，最後對系統的資料庫各子系統的表的結構、欄位等內容進行說明。
第五章為系統實現與測試章節。首先說明了系統的測試環境，之後對各子系統的功能模組的實現結果和測試結果進行說明。
第六章為總結與展望章節，總結了本文的工作內容並指出了本文工作的不足之處，也指明瞭下一階段所需努力的方向。
第二章相關技術研究
2.1 AngularJS技術簡述
AngularJS於2009年由Misko Hevery等人建立，後為Google所收購。AngularJS是一個JavaScript框架，可以擴充套件應用程式中的HTML標籤，從而能夠在Web應用程式中通過HTML標籤來宣告動態內容。AngularJS有很多特性，最為核心的是MVVM開發模式、模組化、自動化雙向資料繫結技術、語義化標籤、依賴注入、測試驅動開發等等。通過資料與模板的雙向繫結，開發人員可以從繁重的DOM操作中抽出身來，可更加專注於業務邏輯的開發。AngularJS是以一個JavaScript檔案形式釋出的，可直接通過<script>標籤新增到網頁中。
AngularJS通過指令方式擴充套件了HTML，提供了元件化開發嘲。Angular的內建HTML指令也可以提供繫結資料的控制元件指令，提高前端資料處理能力，從而提高前端開發效率。在傳統的web應用系統開發過程中，採用HTML來進行前端頁面呈現，但是在如今對網頁和應用系統如此高要求的情況下，傳統的前端開發模式已經不能夠滿足要求，通常會採用類庫和框架來解決靜態網頁技術在構建動態網頁上的不足。類庫通常是一些函式的集合，程式開發人員可以將自己的開發工作儲存在一個類庫中進行分享，供大家去使用，從而避免了大量重複的程式碼出現，需要相應的功能和程式碼只需要呼叫類庫即可，如常用的jQuery庫等。框架是一些已經實現了的非常常用的重複性的業務邏輯，用來將程式設計師從大量重複性的工作中解放出來，如AngularJS等一。
AugularJS是基於HTML基礎上擴充套件的開發工具，目的是希望通過擴充套件HTML標籤來構建動態的web應用，因此，AngularJS主要運用和創新的技術點：一是資料雙向繫結技術，二是依賴注入[451。因為AngularJS前端開發框架對於資料的處理具有高效性，可以將資料和檢視分離開來，提供一個更高層次的抽象來將應用系統的開發進行簡化，所以對於CRUD(增加、查詢、更新、刪除)應用系統，即管理資訊系統的前端頁面更加適合，但是對於操作很頻繁，應用複雜的例如遊戲或者影象處理類的應用就不合適了。
AngularJS是一個新出現的強大客戶端技術，它利用並且擴充套件HTML，CSS和javascfipt，彌補了它們的一些非常明顯的不足[46]。因此可以使用擴充套件的HTML標籤來實現一些動態內容。AngularJS有五個最重要的功能和特性：資料雙向繫結，模板化，MVVM開發模式，服務和依賴注入機制和指令。
(1)資料雙向繫結：這是AngularJS最突出、最實用的特性，可以減少大量資料同步程式碼的編寫，從而節約開發時間，使開發人專注於應用。傳統頁面開發過程中，當Model發生變化，開發人員需要手動處理DOM元素，並將變化的Model傳送到相應的檢視中，檢視中發生變化時，也需要開發人員通過DOM操作將變化的屬性獲取出來，這兩個過程開發人員都需要頻繁的進行解析和處理，增大了工作量。資料雙向繫結機制，同步了DOM和Model，尤其當用戶互動比較多，資料操作多的時候，更加反應出其優點。
(2)模板：在AngularJS中一個HTML檔案就是一個模板。HTML模板將會被瀏覽器解析到DOM中，DOM會成為AngularJS編譯器的輸入，AngularJS將會遍歷DOM模板來生成一些dkective(指令)，所有的指令都負責針對view來設定資料繫結。
(3)MVVM開發模式：通過上文對MVVM模式的分析，MVVM以Model為中心，讓View層和Model層進一步分離解耦，各層次功能明確，各司其職，減少了前端開發工作量，提高了開發效率。
(4)依賴注入機制：AngularJS中提供了大量的服務來提供某個特定的功能。AngularJS中就是可以在控制器中請求所需要的服務作為引數，AngularJS就可以偵測到相應的服務提供給開發人員。依賴注入機制允許開發人員可以請求需要的依賴，而不是去尋找它們。
(5)指令：在AngularJS中可以建立自定義的標籤，用來裝飾元素或者操作DOM屬性。這些指令可以作為標籤、屬性、註釋和類名使用。該前端框架中提供了一些自定義制定可以供框架使用者使用。
AngularJS版本有AngularJSl、AngularJS2、AngularJS4三個大版本。前期經歷過了AngularJS 1．0—1．5版本，於2014年10月份釋出了AngularJS2．0版本，但是和Angularl．x相比，發生了很多顛覆性的變化。也可以理解為1．X與2．0完全是不同的框架。對比於1．X版本，AngularJS2．0版本不再對DOM物件進行封裝，開發者可以直接對DOM物件進行操作。但AngularJS2．0版本將專注於移動應用的開發，並且目前AngularJS2．0版本的開發者還在不斷更新，所以主要基於AngularJSl．3進行前端框架的設計與研究中研究的是AngularJSl．3版本。
2.2 RESTful API +swager
REST(Representational State Transfer，表現層狀態轉化）將網際網路上的一切實體定義為資源，每一個資源至少對應一個URI，每個URI代表一類操作，使得Web資源、服務具有可定址性。此外，客戶端與伺服器間的互動是無狀態的，而通過標準的HTTP方法（GET、PUT、POST、DELETE等）實現網路資源的處理，提供冪等性（POST 除外）的資源操作方法 。 設計REST風格的API需要遵循以下原則：
１）唯一專有名詞表示原則
在REST風格的URI設計中，資源是一個實體，統一使用名詞表示，且該名詞應保證在本 API系統中的唯一性。 此外，名詞應選擇該資源在本API應用領域的專有名詞。
２）分層獨立性原則
每一個符合REST風格的API都應該是分層獨立的，分層是指每個API都是內部封裝的，其互動範圍限制在單個層。 獨立性包含兩個方面， 首先是功能的獨立性，即一個API提供的功能儘量不依賴其他API的執行結果，如果必須依賴其他API，則依賴API應儘量作為呼叫API的一個模組，封裝於API內部。 其次是部署的獨立性，如果該API具有長期使用、需要更新和呼叫量大等特點，則該API應儘量部署到專有域名和伺服器上。
３）安全性原則
RESTful API的資料安全性原則是指呼叫者在執行對資料庫的操作指令時，系統檢測該資料庫是否提供該操作，對於風險性操作執行操作限制、備份保護、日誌記錄、
風險提示等。
４）簡單化原則
簡單化原則是指構造的API。URI應儘量簡短，去除冗餘資訊。 在構造URI時，目錄深度儘量不要超過2級，對於同一資源的多個操作，操作儘量放在引數裡。
５）無狀態原則
無狀態原則是指伺服器端不儲存客戶端請求的狀態（如session、cookie等），即客戶端每次發起的請求是嶄新的、獨立的。
６）版本相容原則
API的更新應儘量保持與原版本的相容 ，並以不同的版本標識， 版本號應放入URI，易於標識和呼叫。
７ ） 執行結果一致性原則
該原則針對API返回結果的資訊一致性進行設計，即伺服器執行API後的返回資料中包含請求引數、請求地址、返回狀態碼、返回資訊、成功資訊、失敗資訊和執行結果等資訊，便於呼叫者自檢，確定執行引數和返回結果的正確性。
８）快取原則
REST使用快取設計原則，執行頻率較高的API應快取以提升載入速度，快取分為臨時快取和長久快取兩個部分，對於某一時刻呼叫較高的API快取至記憶體中，對於長期呼叫頻率較高的API快取至硬碟。
2.3 Oauth2.0身份驗證
2.3.1 OAuth2.0
OAuth2.0 協議在實現認證授權的過程中會涉及到幾個“實體”，它們在此過程中扮演者不同的角色。在 OAuth2.0 協議中定義了以下四種角色，具體描述如下：
（1）資源擁有者(Resource Owner，簡稱“RO”) ：能夠授權保護資源的訪問許可權的實體。如果它是一個“人”，一般就是指終端使用者。
（2）客戶端( Client) ：在獲得授權後，能代表使用者請求訪問受保護資料資訊的第三方應用。可以是桌面應用、Web 應用或者其裝置中執行的程式。
（3）授權伺服器( Authorization Server，簡稱“AS”)：檢測使用者授權資訊無誤後，發放訪問令牌給客戶端的伺服器。
（4）資源伺服器( Resource Server，簡稱“RS”) ：使用者託管受保護資料資訊的伺服器。能夠接受客戶端攜帶訪問令牌發起的資源訪問申請，並且做出響應。
2.3.2 協議流程
雖然，OAuth2.0 協議具體的授權流程會因所採用的授權型別不同而有所變化，但整個授權流程從整體而言均為客戶端應用（client）與資源擁有者（RO）、授權伺服器（AS）以及資源伺服器（RS）進行的 3 步互動實現，分三個階段。各角色之間通訊抽象流程，如圖 2.8 所示，這被稱為經典的“Three-Legged OAuth。
圖 2.8 抽象的協議流程
OAuth2.0 認證授權的具體步驟大致如下：
1. 階段 1 獲取使用者授權
（A）客戶端向用戶（RO）請求授權。該請求可以通過向用戶直接發起（如圖所示），也可以通過 AS 作為中介來間接地發起；
（B）使用者收到授權請求後，決定是“同意”授權又或者是“拒絕”響應。若同意授權，會向客戶端返回一個授權許可，其代表使用者的授權憑據；
2. 階段 2 發放訪問令牌
（C）當客戶端收到使用者的授權響應後，其攜帶授權資訊向 AS 發出申請Access Token 的請求；
（D） AS 對客戶端進行認證並校驗授權許可，驗證通過後發放 Access Token；
3. 階段 3 訪問受保護資源
（E）當獲得 Access Token 以後，客戶端攜帶 Access Token 向 RS 發起受保資源的申請；
（F） 認證 Access Token 確認通過後，向客戶端開放使用者許可範圍內的資料資訊。至此，整個授權流程結束。
2.3.3 Authorization Grant
OAuth2.0 中的授權許可（Authorization Grant）代表一種中間憑證，它代表了 RO 針對客戶端應用獲取目標資源的授權。OAuth2.0 定義瞭如下 4 種Authorization Grant，體現了授權採用的方式以及 Access Token 的獲取機制。
① 授權碼授權( Authorization Code Grant) ：該模式要求：在獲取用於向 RS發起訪問受保護資料資訊申請時攜帶的 Access Token 之前，需要先向 AS 獲得一個與使用者授權資訊有關的授權碼。
② 隱式授權( Implicit Grant)：它代表一種“隱式”授權方式，即客戶端在取得RO 授權的情況下直接獲取 Access Token，而不是間接地利用獲取到的授權碼來取得 Access Token。
③ 資源所有者密碼憑證授權( Resource Owner Password Credentials Grant)：採用 RO 的憑證（如：使用者名稱和密碼）直接作為獲取 Access Token 的授權方式。該方式要求使用者對客戶端足夠信任。
④ 客戶端憑證授權( Client Credentials Grant)：客戶端應用自身的憑證直接作為它用於獲取 Access Token 的授權型別。這種型別的授權方式適用於客戶端應用獲取屬於自己的資源，應用本身即為資源擁有者。
2.4 Bootstrap視覺化佈局
Bootstrap是一個自由和開源的工具集合，用於建立網站和web應用程式。它包含基於HT地和CSS的設計模板、表格、按鈕、導航和其他的介面元件，就像可選的JavaScript誇張等。Bootstrap框架的目的是旨在簡化web開發。
Bootstrap是一種前段開發框架、用於使用者的介面，不同於在駐留到後臺伺服器的程式碼。它也是一個web應用框架，就是為了支援動態網站和web應用程式的軟體框架。
Bootstrap 是目前比較流行的前端框架，最初是由 Twitter 的兩位員工 MarkOtto 和 Jacob Thornton 一起開發設計的，自推出後就備受歡迎。Bootstrap 最大的優點也是備受推崇的原因是可以方便的實現響應式佈局，能使網站頁面在不同裝置終端上完美展現。Bootstrap 是在 HTML、CSS、JavaScript 的基礎上開發的。它為使用者提供一套通俗易懂的 Web 設計工具包，開發人員可以使用它方便快速地設計出簡潔漂亮的響應式頁面，省去了開發人員為不同裝置終端設計樣式的煩惱，也在一定程度上減少了網頁的開發與維護成本。使用 Bootstrap 設計的介面比較和諧、簡潔大方和一致，可以提高使用者體驗。
Bootstrap 具有以下特性：
（1）元件部分：Bootstrap 包含豐富多樣的元件，比如按鈕組、導航條、字型圖示、進度條、排版、下拉選單等，這些模組化的元件也便於修改。
（2）預定義樣式表：Bootstrap 中預定義樣式表對頁面字號和字型具有統一規定，可以使介面看起來更一致，這些樣式表也可按照開發人員的意願進行修改。
（3）響應式柵格系統：是在網格系統的基礎上發展起來的。網格系統在日常生活中應用廣泛，比如應用到平面設計中可以使應用的設計更簡單、美觀。柵格系統可以隨著螢幕或者視窗大小的改變，自動分為最多 12 列，而不會表現出跟網格系統—960 柵格系統分為寬度固定的列的行為一樣。這時 Bootstrap 響應式佈局的優點就被充分體現出來，它可以根據不同情況以合適的方式使網頁展示出來。
（4）jQuery 外掛：包括滾動條、彈出框、模態框、警告框等，也可以幫助開發人員設計出精緻的具有動畫和其它互動的效果，而且這些外掛也可按需修改。
(5)框架程式碼
Bootstrap官網上，提供了具體的框架程式碼，開發網站時，並不需要弄清框架具體的實現，只需直接使用Bootstrap官網上的元件、樣式，也可以對Bootstrap中的所有的CSS變數進行修改，根據自己的需求修改框架中的程式碼，實現自己網站頁面。
(6)一個框架、多種裝置
網站基於Bootstrap框架，能夠適應各種螢幕的大小和各種規格的解析度，不需要複雜的編寫便可以快速應用到不同的裝置。不僅支援主流的瀏覽器的最新版本，而且充分貫徹了移動先行的宗旨，全面支援移動平臺的開發
(7)元件豐富
Bootstrap中包含了很多直接可以使用可以直接使用的文字框、下拉選單、表單等，並可以較為簡便的開發一個響應式網站。
(8)程式碼簡潔
Bootstrap的程式碼簡潔、易於修改，非前端開發人員也可以使用。Bootstrap提供多種幫助使用者學習並利用資源的方法，每一種方法針對不同的水平的開發人員和不同型別的網站，本文主要使用包含了編譯並壓縮好後的CSS、JavaScript的Bootstrap框架，其中，下載壓縮包到本地後，然後按照自己應用的需要解壓到相應的目錄下，便可以看到以下的目錄結構：CSS檔案下包含bootstrap．CSS、bootstrap．min．CSS、bootstrap．廿1eme．CSS等檔案，jS下包含bootstrap．js、bootstrap．min．js等檔案。在具體的專案中，可以根據情況，任意使用上述檔案，即不同的排版的網站可以引入不同的檔案，實現想要達到的效果，Bootstrap官網展示了目錄的檔案結構，其中包含編譯好的CSS和JS(bootstrap．木)檔案，還有經過壓縮的CSS和JS(bootstrap．rain．*)檔案。
2.5 Data Migration
2.6本章小結
本章重點闡述了醫療領域臨床科研資料管理系統的構建技術，其中包括ASP技術原理、特點和資料訪問控制模型，SQL Server 2008資料庫系統，Visual Studio 2010軟體系統開發整合環境，UML建模語言等，分別從這些技術和思想的歷史發展、技術特點等內容進行詳細說明。
第三章需求分析
3.1使用者許可權分析
本系統的角色共分為八種：（1）訪客，能夠訪問網路系統的開放頁面；（2）普通使用者，能夠訪問許可權內的專案資料；（3）中心管理員，主要負責分配各中心的許可權；（4）專案管理員，主要負責管理專案內的使用者；（5）邏輯稽核人員，稽核資料是否符合邏輯；（6）SDV稽核人員，對資料進行SDV審查；（7）人工稽核人員，對資料進行最後的審查；（8）系統管理員，系統管理員主要負責系統的日常維護、系統升級、專案分組、專案表單設計等內容。如表3-1所示，為系統的各種角色具體的許可權。
表3-1臨床科研資料管理系統角色功能分析
| 編號 |
角色名 |
角色描述 |
| 1 |
訪客 |
訪客角色能夠訪問系統的一些開放式頁面，例如研究中的專案概況展示頁面等。 |
| 2 |
普通使用者 |
普通使用者是資料管理系統的主要使用者群體，專案管理員能夠授予普通使用者對專案的訪問、操作等許可權，普通使用者在被授予對專案的訪問、操作等許可權後能夠實現諸如資料檢視、資料錄入等操作。 |
| 3 |
中心管理員 |
中心管理員負責管理研究中心對各資訊資料庫的操作的許可權，管理研究中心能夠訪問、錄入、管理哪些專案的資料。 |
| 4 |
專案管理員 |
專案管理員隸屬於研究中心，在明確了研究中心所擁有的專案操作許可權後，專案管理員將具體專案的操作許可權分配至普通使用者，管理哪些使用者能夠對本研究中心所管理專案進行訪問等操作。 |
| 5 |
邏輯稽核人員 |
系統資料在錄入時採用三級稽核機制以確保錄入系統的資料的正確性，邏輯稽核人員是三級稽核機制的第一級稽核機制，在普通使用者錄入資料後系統會自動進行邏輯審查，如果系統判定普通使用者錄入的資料存在邏輯問題，則會停止資料流轉到下一級，並由邏輯稽核人員判定由使用者重新錄入資料還是資料不存在邏輯問題而進行下一級流轉。 |
| 6 |
SDV稽核人員 |
SDV稽核人員處於三級稽核機制的第二層，對經過邏輯稽核無問題的資料進行SDV稽核，如果無問題則流轉到下一級進行最後一步的人工稽核，否則將資料返回，使用者修改後重新提交進行稽核。 |
| 7 |
人工稽核人員 |
人工稽核人員處於三級稽核機制的最後一層，通常採用第三方進行資料的人工審查，實現對資料正確性的最後判定，如果判定無問題則會將資料最終錄入到系統中，否則返回給使用者進行修改並重新提交。 |
| 8 |
系統管理員 |
系統管理員為該系統的超級管理員，主要負責系統的日常維護和系統的各項配置，主要包括專案組的管理、資料部件資訊的管理、表單的設計及管理、資料分類管理、機構資訊的管理、使用者管理等內容。 |
3.2 分系統需求分析
臨床資料管理系統主要負責儲存、查詢、管理臨床醫療資料以供科研使用，臨床資料管理系統按照功能和實際業務可以將整體系統分為七個子系統，即：登入管理子系統、研究資訊管理子系統、專案管理子系統、質量管理子系統、資料匯出子系統、統計分析子系統和系統配置管理子系統，下面結合用例如對各子系統進行詳細描述。
3.2.1研究資訊管理子系統
研究資訊管理子系統主要實現研究資訊的展示、研究資料的查詢、資料錄入進度展示與查詢、問題反饋的展示。研究資訊管理子系統中最重要的功能模組是研究資料管理模組，其中研究資料管理模組能夠通過鍵入病人姓名查詢該病人的病例資料，也能夠通過鍵入的病人的姓名進行病人病例資料輸入或修改。不同的科研專案資料庫擁有不同的資料型別，例如胃癌核心資訊資料庫中的資料清單包括九章：（1）基本資訊；（2）基線評估；（3）腫瘤學評估；（4）手術資訊；（5）術後恢復；（6）系統治療；（7）放射治療；（8）介入治療；（9）隨訪資訊。每頁資料清單都有詳細的內容需要填寫，例如胃癌核心資訊資料庫中的基線評估清單中需要填寫腫瘤位置、腫瘤浸潤深度、淋巴結轉移、遠處轉移、胃癌所致合併症等內容。
研究資訊管理子系統包括如下幾個重要的功能：專案選擇、專案概況展示、專案概況查詢、研究資料查詢、研究資料管理、資料錄入進度管理、資料錄入進度查詢、反饋問題的管理等功能。研究資訊管理子系統的用例圖如圖3.2所示。
圖3.2 研究資訊管理子系統用例圖
3.2.2專案管理子系統
專案管理子系統主要實現了研究專案的管理與維護，例如專案管理員可以管理哪些使用者獲得了該專案的授權、能夠主動邀請使用者參與該專案的管理等內容。專案管理子系統還實現了部件資訊提示對應的功能、反饋問題的回覆功能以及規則設定的功能，使用者可以自定義規則。
專案管理子系統包括如下幾個重要的功能：新建研究中心、編輯研究中心內容、研究中心的授權使用者管理、研究中心的使用者邀請、專案概況的管理、編輯部件提示資訊、搜尋部件提示資訊、刪除部件提示資訊、問題反饋管理、規劃設定管理等功能。專案管理子系統的用例圖如圖3.3所示。
圖3.3研究資訊管理子系統用例圖
3.2.3質量管理子系統
質量管理子系統主要負責檢查錄入資料的結構正確性、資料完整性等內容，以決定是儲存資料到資料庫中還是需要對資料進行修訂後再儲存到資料庫中。質量管理子系統的用例圖如圖3.4所示。
圖3-4質量管理子系統用例圖
3.2.4資料匯出子系統
資料匯出子系統的最主要功能是能夠匯出自定義格式的資料到本地，以供後續科研實驗使用。在進入所選資料庫後進入資料匯出子系統，可以自定義所需匯出的資料欄位，例如基本資訊 Patient Demography：Name；Sex；ID_National；Nationality；Race；基線評估 Baseline：Date_FirstD；Date_ComfirmedD；Age；His_Cancer；His_Familycancer；His_FamilyGC；腫瘤學評估 Cancer Identification：Location_Tumor；Size_Tumor_Patho；Number_Tumor等資料欄位。在配置好匯出欄位後點擊“匯出”按鈕即可匯出所需要的資料。
資料匯出子系統包括如下幾個重要的功能：新建資料匯出、匯出欄位檢視、匯出欄位編輯、資料匯出、編輯匯出的資料等功能。資料匯出子系統的用例圖如圖3.5 所示。
圖3.5 資料匯出子系統用例圖
3.2.5系統配置管理子系統
系統配置管理子系統包含了兩個部分的功能：專案的配置與管理和系統使用者的管理。其中專案的配置與管理的專案資訊功能實現了編輯專案資訊；專案分組功能實現了專案的分組管理；專案資料欄位的配置實現了專案所需要填寫的資料欄位，例如臨床科研資料管理系統中的胃癌核心資訊資料庫的隨訪資訊的“患者狀態”部件，配置的部件程式碼為Condition_Followup，部件型別為單選；專案配置還實現了諸如表單配置等功能。在系統使用者的管理功能模組中包括了機構資訊的管理和使用者資訊管理，其中機構資訊管理主要包括了專案資訊編輯、可訪問使用者的授權、機構的專案授權，使用者資訊管理包括使用者資訊的編輯、重置密碼等功能。
系統配置管理子系統包括如下幾個重要的功能：專案組管理、專案組資訊管理、資料配置管理、表單配置管理、資料配置管理、資料分類管理、幫助解答管理、機構資訊管理、使用者管理等功能。資料匯出子系統的用例圖如圖3.6所示。
圖3.6 資料匯出子系統用例圖
3.3系統安全性需求分析
本系統中儲存的資料均為病人的臨床資料，對於個人而言屬於極為隱私的資料，一旦發生資料洩漏問題則後果難以估量。所以，資料管理系統的保密性和安全性要求很高，現主要從身份認證技術實現、基於角色的訪問控制策略（你的提綱是第三方通訊、驗證，但我不知道你具體實現，沒法寫，寫這個標題可以嗎？）、資料加密儲存與傳輸三個方面對系統的保密性和安全性進行論述。
3.3.1 身份認證技術實現
本文采用Web Service作為服務介面，結合XML和SOAP技術，通過SOAP訊息中封裝令牌和Access Token授權口令，構件身份和服務認證的統一身份認證系統。通過使用基於公鑰機制的SSL/TLS認證方式來保證金鑰分發過程中資料的完整性和祕密性。同時，在認證伺服器和使用者端、應用伺服器和認證伺服器端都使用SSL／TLS方式進行密碼互動。通過基於Web服務的ESB應用模型、WebLogic應用伺服器、OpenSAML庫、Apache提供的OAuth開放原始碼庫以及JavaEE開發平臺對基於OAuth 2．0的單點登入系統進行了實現，通過sAMLAu—thFiher控制頁面加入單點登入。同時將APP資訊、使用者和APP之間的授權關係、SAML令牌、AccessToken等資訊儲存在資料庫表中，應用系統資訊管理資料庫表字段如表1所示。
表 1 應用系統資訊管理資料庫表字段
| 欄位 |
說明 |
| appid |
Client_id |
| appsecret |
Client_secret |
| appname |
應用名稱 |
| appowner |
應用的所有者 |
| owneremail |
應用擁有者的email |
| appdescribe |
應用描述 |
| status |
應用是否通過稽核 |
| callbackurl |
調回的url |
| addtime |
新增時間 |
統一身份認證平臺互動流程如圖*所示，具體流程如下：①由客戶端攜帶客戶端憑證(如客戶端證書等)呼叫SAMIRequest(統一身份認證服務)生成攜帶SAML令牌的sOAP請求；②認證伺服器根據使用者請求與使用者資訊，呼叫SAMLPOSTProfile類的prepare方法生成相應的SAMLResponse，通過該SAMLResponse生成相應SAM—LAssertion並進行簽名；③客戶端轉發攜帶SAML令牌的SOAP訊息後向應用伺服器請求資源；④應用伺服器將該SOAP訊息轉發到統一身份認證平臺，呼叫Verify服務驗證令牌有效性；⑤驗證通過後，由統一身份認證平臺呼叫統一授權服務頒發給使用者一個訪問該應用資源的AccessToken，包括使用者所在組別等資訊；⑥由應用伺服器根據通過認證使用者所在的組別為使用者提供不同的資源。
圖 * 統一身份認證平臺互動流程
3.3.2 基於角色的訪問控制策略
3.3.3 AES和RSA混合加密演算法的設計與實現
在傳遞資料的時候，使用AES演算法加密傳輸資料，同時使用RSA演算法加密傳送AES金鑰，結合兩種加密演算法各自的特點，發揮優點，避免缺點，從而得到了一種新的混合資料加密技術。在相同條件下，AES加密速度比解密速度快，RSA解密比加密慢很多；而無論加密還是解密，RSA都比AES慢很多，由於RSA進行的是大數計算，無論是軟體還是硬體實現，速度一直是一個較明顯的缺陷。
AES加密演算法的優點：能夠直接用硬體去實現，加密的程度較高，速度較快，對於加密大量資料非常的適用。缺點：加、解密過程使用同一個密匙進行，對於密匙的管理和保護較難。
RSA加密演算法的優點：具有公鑰和私鑰兩個不同的金鑰，公鑰用於加密資料，私鑰用於解密資料，難於破解；並且不需要通過網路傳送保密的金鑰。缺點：加密的速度比較慢。
從金鑰管理、運算速度、簽名認證和安全效能等方面比較AES和RSA兩種加密演算法：（1）金鑰管理：RSA演算法是非對稱加密技術，利用公鑰進行加密，即使是和不同的物件之間進行通訊，關鍵還是要保管好自己的解密私鑰，所以在使用該演算法時，加密金鑰更換是很容易實現的；而AES演算法是對稱加密技術，在和不同的物件進行通訊的時候，AES需要產生和保管不同的金鑰，所以金鑰的更換較難實現。（2）運算速度：AES演算法的運算速度要比RSA演算法的運算速度快。這是因為AES演算法的金鑰長度最大也就256位，利用硬體或軟體都能夠實現；而RSA演算法，至少需要1024位才能確保安全，而在加、解密過程中會需要很多的運算，因此RSA演算法的運算速度肯定要比AES演算法要慢。（3）簽名認證：RSA屬於非對稱密碼體制，利用RSA演算法可以進行數字簽名和身份認證操作；AES不能實現數字簽名和身份認證，這是由於AES屬於對稱密碼體制。（4）安全效能：目前還沒有能夠完全破譯AES和RSA的良好方法，所以兩者的安全性都很好。從以上4個方面的比較可以知道，對於大量的資料檔案，由於RSA演算法加密速度較慢，所以並不合適；而AES演算法雖然加密速度很快，但是如何在開放的網路傳輸環境中保管好AES金鑰，成為使用AES加密首先要考慮的問題。
因此，可以在傳遞資料的時候，使用AES演算法加密傳輸資料，同時使用RSA演算法加密傳送AES金鑰，結合兩種加密演算法各自的特點，發揮優點，避免缺點，從而得到了一種新的混合資料加密技術。
AES和RSA混合加密演算法加解密過程，如圖*所示。
圖* AES和RSA混合加密演算法實現流程
接收方：（1）生成1024位的RSA密匙對。（2）向傳送方傳遞RSA公匙。傳送方：（1）接收接收方發過來的RSA公匙密碼；（2）隨機生成AES密匙；（3）用AES密匙加密資料，用RSA公匙加密AES密匙；（4）將加密後的AES密匙寫入資料檔案的頭部，加密後的資料寫入資料檔案的尾部；（5）將資料檔案傳送給接收方。
接收方：（1）接收發送方發過來的資料檔案，並利用自己的RSA私鑰解密AES密匙。（2）利用解密後的AES密匙解密資料檔案。JAVA語言的安全性非常高，通過“SunJCF”提供了對各種加密技術的支援，包括DES，3DES，AES，RSA等資料加密技術。JAVA當中的常用資料加密類有：KeyGenerator類用於獲得各類對稱加密技術的密匙；KeyPairGenerator類用於獲得非對稱加密技術的密匙；Cipher類是ASP加密的主要類，用於按一定的演算法對資料進行加密、解密、包裝和返包裝。而AES和RSA混合加密演算法利用ASP語言可以較容易實現。
3.4本章小結
本章主要說明了臨床科研資料管理系統的需求分析，首先說明了系統的三種角色並對各種角色的功能進行詳細說明；之後對系統的六個子系統進行需求需求分析，並結合用例圖對系統的子系統進行需求分析；最後對系統的五項非功能的需求分析進行詳細的闡述，在響應時長、可行性等方面對系統進行分析。
第四章系統設計
4.1設計的原則和目的
臨床科研資料管理系統主要儲存著病人的病例資料以用於科研實驗，資料的種類繁多且資料量可能會達到PB級，且對海量的資料進行處理的實時性要求很高，這些特點和要求給臨床科研資料管理系統的實現帶來了不小的挑戰。例如在系統的響應時長和服務的併發處理方面，在大規模資料量方面實現海量併發請求的處理的實時反饋，對系統的效能、響應能力和高併發的支援能力都提出了很高的要求。醫療資料的特點是資料量大、資料間的關聯性強、不同使用者對資料欄位請求的也不一樣，這些對系統的資料管理模型提出了很高的要求。而且，系統存著的海量資料的查詢、分析、提取等任務的類別很多，都為系統的效能進一步提出了要求。另外還有如下幾個設計的原則和目的。
1、採用結構化、平臺化的柔性開發方法，以保證系統後續的可持續發展
臨床科研資料管理系統採用是B/S架構進行開發，設計模式上採用MVC模式、模組化設計思想，以持續性的適應醫療系統和科研系統的變化情況，為後續的科研工作提供資料保障。
（1）架構化的資料管理平臺
臨床科研資料管理系統在設計時考慮到臨床科研資料管理的一體性問題，對系統的架構進行進行設計，包括：使用者資訊與許可權的管理、專案的縱向管理、專案的橫向管理、系統管理等內容。
（2）平臺化科研資料管理工具
為了滿足臨床科研實驗的資料需求和管理的要求，實際了臨床科研資料管理系統以完成海量資料的管理工作，系統設計了不同的模組完成整體功能，系統的使用者只需通過簡單的培訓就可以基本掌握該系統的使用。
2、針對臨床科研的特點設計並開發該系統
針對臨床科研工作的特點對本系統進行設計、規劃和實現，對科研科研資料進行全方位、立體化的管理，並提高資料獲取的效率和準確性。
3、系統的技術特點
該系統採用先進的軟體開發方法和資訊化策略，通過B/S架構實現了臨床科研資料管理系統的搭建工作，通過架構華、平臺化的方法實現了系統整體框架和各功能模組的設計與實現，既實現了現有功能需求，也為後續擴充套件留下了介面。
4.2 系統應用架構設計
臨床科研資料管理系統設計到海量醫療資料的儲存、提取與管理，需要優化海量資料的儲存結構，才能提高資料的提取、管理效率，為臨床醫療的科研工作提供資料支援，為了滿足這一需求需要考慮以下兩個問題。
（1）系統能夠滿足海量結構複雜的資料的高效管理
資料管理系統中存在著大量型別複雜、型別各異的資料，例如胃癌核心資訊資料庫中，僅基線評估清單中就儲存著腫瘤位置、腫瘤浸潤深度、淋巴結轉移、遠處轉移、胃癌所致合併症等資料欄位，除了結構化的資料外，還有一些非結構化的資料需要儲存，諸如系統中儲存的一些圖片資料。
（2）實現了海量複雜資料的管理和實