【正文】 隱私保護。 關鍵詞： 基于云計算的架構，家庭診斷服務，醫(yī)療大數(shù)據(jù) 1 介紹 背景 根據(jù)世界衛(wèi)生組織的報告，人們在亞健康狀態(tài)（ SHS），也被稱為“第三狀態(tài)”（處于健康和生病之間），在世界人口中占 75％ （ He et al., 20xx）。因此，為了滿足“ SHS”群體和人口老齡化的需求，按需自助服務應該被發(fā)展以幫助人們可以在家方便地獲得疾病預防知識。然而，大量的醫(yī)療數(shù)據(jù)，以及它的各種格式，造成大規(guī)模數(shù)據(jù)管理和高效的知識挖掘技術的挑戰(zhàn)，這也被稱為“大數(shù)據(jù)”的問題。更具體來說，本文提出的研究報告是為連云港衛(wèi)生局建立一個基于大型研究項目的醫(yī)療信大醫(yī)療數(shù)據(jù)背景下基于云架構的家庭診斷服務 2 息云平臺。通過這樣做，各種醫(yī)療服務可以被制定以符合實際的醫(yī)療保健需求。并且他知道他的癥狀包括“高燒”和“呼吸困難”。此外，有相似的歷史病歷，李某會對他的病情更詳細的了解。第一點是如何根據(jù)李某的疾病癥狀在大規(guī)模和不斷增加的醫(yī)療記錄中提供實時在線醫(yī)療記錄檢索。（ 1）在本文中我們提出了一個基于云的框架來實現(xiàn)一個名為家庭診斷的自我保健服務。首先 ,用戶提交查詢有關他 /她的疾病信息。因此，疾病的癥狀點陣，以及進行過隱私處理的醫(yī)療記錄被返回到用戶，這為用戶自己做一個初步的 診斷提供了一個詳細的診斷依據(jù)。第 4 節(jié)介紹了家庭診斷服務是如何為用戶提供了診斷援助的細節(jié)。第 7 節(jié)總結全文，并討論了今后的 工作。每個元素的內容如下： （ 1）病人數(shù)據(jù)：患者數(shù)據(jù)包括患者的基本信息，如患者的姓名，性別，出生年月日等 。圖 1 給出了XML 病歷的一個例子。 Hadoop： HDFS 和 MapReduce 框架 Hadoop (Ekanayake et al., 20xx。大文件分割成塊 (默認 64 MB)和每一個塊可以寫入多個節(jié)點 (默認值是 3)容錯。中間結果存儲在本地磁盤上運行的節(jié)點映射任務。當所有的映射任務完成 ,篩檢階段開始并把具有相同關鍵值得中間數(shù)據(jù)聚合起來。 Hatcher et al., 20xx). 它被廣泛應用于許多搜索應用，如 NetFlix, Digg, MySpace, LinkedIn 等等 (Apache Lucene, 20xx). Lucene 的核心部件是索引和搜索。 在本文中 ,我們采用 Lucene 和 Hadoop 實現(xiàn)病歷家庭診斷服務的搜索。索引階段后 ,索引文件也存儲在 Hadoop 的 HDFS 集群。這個疾病癥狀點陣在用戶查詢的過程中會揭示具有相同癥狀的疾病 的關系。我們的家庭診斷服務旨在通過相似的歷史醫(yī)療記錄為用戶提供自我護理服務。 基于云計算架構的概述 為了簡化討論，我們把一些術語羅列在下面的表 1 中。 （ 2）網上分布式搜索簇設計用于處理高并發(fā)和可擴展方式的用戶查詢。（ c）由 Q 個訪問控制節(jié)點組成的訪問控制集群被采用以過濾隱私信息。一旦完成索引構建，一個完整的索引文件就變分成 N 個片，此外，第 i個（ 1 i N）的索引片被分配給在分布式搜索群集的每一行的第 i個（ 1 i N）的搜索節(jié)點。正如 節(jié)中所討論的 ,首先，醫(yī)療記錄被翻譯成幾個 Lucene 文檔。 圖 3 家庭診斷服務的文檔存儲模型 根據(jù) Lucene 的性質 ,所有醫(yī)療記錄在索引階段之前都應該轉移到由字段值對組成的 Lucene 文檔。所有的 Lucene 文檔被存儲在 Hadoop 集群的 HDFS 中，如圖 3所示。首先 ,每個文檔塊被分為若干個分區(qū) ,映射節(jié)點為給定文檔分區(qū)建立索引。另外，為了能夠進行在線醫(yī)療數(shù)據(jù)檢索，索引文件的 N 個碎片被分布到分布式搜索集群的搜索節(jié)點中。反向索引文件記錄癥狀集和相應的醫(yī)療記錄 ID 之間的映射關系。與（ Li et al. 20xx）相似，布隆過濾器的簽名 (Bloom,1970)和布隆過濾器索引結構被用來加快基于癥狀的醫(yī)療記錄查詢。 h1(熱 )= 5,h1(咳嗽 )= 6,h1(呼吸困難 )= 7。（ 3）由于 0001110000∧ 0100100010=0101110010，在醫(yī)療記錄中這個癥狀集設置的布隆濾波器簽名是 0101110010。 BF 索引文件是由鍵值對組成的，并以序列文件存儲于 HDFS 中。因此我們也會存儲原始的癥狀集以確保匹配。這些記錄中患者的性別和年齡是與目標用戶的查詢條件所不符的。為了進行數(shù)據(jù)分析過程，診斷結果和疾病癥狀字段被用于建立疾病癥狀點陣，以顯示具有相同癥狀的 疾病之間的關系。請注意 ,根據(jù) Lucene 索引構建的可配置特性，所有字段在Lucene 可以很容易地從細節(jié)索引文件中添加或刪除。在接受用戶查詢時 ,負載平衡器根據(jù)其選擇規(guī)則將查詢轉發(fā)到一個調度程序。具體地 說，從負載平衡器收到用戶查詢之后，一個調度程序會從搜索節(jié)點集群的每一列選擇一個搜索節(jié)點執(zhí)行實時的醫(yī)療記錄檢索。因此 ,對于每一個用戶查詢 ,節(jié)點選擇算法會進行以選擇合格的節(jié)點進行用戶查詢。為了實現(xiàn)高并發(fā)的實時醫(yī)療記錄檢索， M1 個搜索節(jié)點被復制到每排的每個節(jié)點。因此，檢索到的相關的醫(yī)療記錄可能就包含多個疾病分類。關于如何計算疾病點陣的細節(jié)我們將在后續(xù)的章節(jié)討論。為了解決這一問題，我們設計了一個訪問控制策略，根據(jù)用戶的角色，用戶會被分為不同的用戶域。 在我們的設計中，每個訪問控制集群中的節(jié)點都會通過索引文件存儲用戶的權限。 節(jié)點選擇算法 對于每次用戶查詢，調度程序會從搜索節(jié)點集群中選擇某些節(jié)點。在這里， 我們提出了一個合理動態(tài)節(jié)點選擇算法，為每次用戶查詢選擇合適的節(jié)點。簡而言之，調度集群有一個包含 N 個最小堆棧的集合，而每個最小堆棧都有 M 個元素（如圖 6 所示）。 SFR ij 的值越小，搜索節(jié)點 ij 的服務質量越好。算法 2 描述了如何為一次用戶查詢選擇一組搜索節(jié)點。 圖 7 實現(xiàn)家庭診斷服務的流程圖 大醫(yī)療數(shù)據(jù)背景下基于云架構的家庭診斷服務 14 步驟 1 查詢提交 在這一步中 ,目標用戶提交一個與他 /她的疾病信息有關的查詢 ,。數(shù)據(jù)分析節(jié)點會計算與步驟 2 中的醫(yī)療記錄相關的疾病癥狀點陣。 表 2 家庭診斷服務中的關鍵術語 查詢提交 從形式上看，在我們的家庭診斷服務中，一次用戶查詢可以形式化為定義 3。疾病癥狀是指病人的癥狀名稱。 醫(yī)療記錄檢索 給定一個包含一組癥狀的用戶查詢，每個搜索節(jié)點都會運行布隆簽名過濾去檢索同時出現(xiàn)“發(fā)燒”和“咳嗽”的醫(yī)療記錄。（ 2）把 m維向量中與那些離散值 相應的位置 1。 （ 2）基本信息過濾 對于經過 BF 簽名過濾的醫(yī)療記錄，它的性別和年齡會與用戶的性別年齡相比較，以過濾掉男性、老年人以及兒童患者。數(shù)據(jù)分析通過利用一種被稱為形式概念分析（ FCA）的數(shù)學理論幫助用戶分析這些可能的疾病分類的相似和不同點。更具體地說 ,疾病名稱以及癥狀會從 節(jié)中獲得的醫(yī)療記錄中被提取。 (e, f) ∈ R (e∈ E, and f∈ F)表明疾病 e 有癥狀 f。假設與 節(jié)搜索到的醫(yī)療記錄相聯(lián)系，疾病集合 E= {胸膜炎、結核、流感、肺炎 },而癥狀集合F= {發(fā)熱、咳嗽、呼吸困難、胸痛、胸悶 ,盜汗 ,身體疼痛 }。 ,則集合 39。 ,則集合 39。 根據(jù)定義 5 和定義 6，疾病和相關的癥狀可以被歸入有意義的集合。39。)( FECF ? , 39。39。 換句話說，在 ),( 39。E ，而 39。因為 {咳嗽、發(fā)燒 }是 {胸膜炎、結核、流感、肺炎 }的共同癥狀。另外 ,({肺炎、胸膜炎 },{咳嗽、發(fā)熱、胸痛、呼吸困難 })是這種情況下的另一個概念。 示例（不等關系）在表 3 中的形式概念中， ({胸膜炎 },{咳嗽、發(fā)熱、胸痛、呼吸困難、胸悶 })? ({肺炎、胸膜炎 },{咳嗽、發(fā)熱、胸痛、呼吸困難 })。而這個在本文中被稱為疾病癥狀點陣。 圖 8 表 3 中的疾病癥狀點陣 有了疾病癥狀點陣，用戶可以通過自上而下瀏覽點陣的每一個診斷路徑獲得自我診斷。在用戶查詢的例子中 ,用戶查詢癥狀“發(fā)燒”和“咳嗽” ,有 4 個匹配這些癥狀 (如疾病、胸膜炎、結核、流感和肺炎 )。 作為總結，家庭診斷服務的數(shù)據(jù)分析可以用算法 4 來描述。 根據(jù)節(jié)點選擇算法和 節(jié)中討論的訪問控制策略 ,隱私信息過濾過程包括三個主要步驟。根據(jù)訪問控制策略，細節(jié)索引文件的與用戶相關的用戶域中的靜態(tài)域是不可訪問的。 大醫(yī)療數(shù)據(jù)背景下基于云架構的家庭診斷服務 20 5 評價 在這個部分，一個原型系統(tǒng)會被設計而且一個運行示例會演示我們的提案的可擴展性和效率。原型系統(tǒng)的配置已經列在表 4 中。醫(yī)療記錄被存儲為 XML 文檔。主節(jié)點 ,裝有 2TB 的磁盤 。此外 ,搜索節(jié)點集群由18 個人電腦組成一個 3 * 6 搜索矩陣形式。標準的 Hadoop MapReduce API 以及 Lucene API 相應地在索引構建和在線用戶查詢處理中被采用。每個醫(yī)療記錄的大小是 ，總的大小是 14GB。此外 ,新的 PFD 壓縮機 (Yan et al .,20xx。 對于在線病歷檢索 ,每個索引文件被分為 N 個碎片 (N 是搜索節(jié)點集群每一行的搜索節(jié)點的數(shù)量 )。（相應地， N 為 1,2,3,4,5）每次試驗中，我們模擬最初在客戶端有兩個并發(fā)的進程持續(xù)發(fā)送 50000 次查詢給調度程序。同樣地 ,當 N≤3, CPU 利用率會隨著 n 的增加顯著增加，而當 N 3 時趨于穩(wěn)定，原因分析如下。為了解決這個問題 ,我們可以添加更多的搜索節(jié)點到節(jié)點搜索集群 ,以提高搜索性能。 I/ O 等待時間就會變得較小 ,而 CPU不必等待 I / O 操作。 （ 2）相對于 M 值的性能 表 6 性能關于 M 的測試數(shù)據(jù) 在這個測試中， N 為定值 3。 從表 6 中，從表 6 中 ,我們可以發(fā)現(xiàn) I/O 等待時間不會隨著 M 改變。為了改善延遲 ,我們可以在搜索節(jié)點集群中添加更多行。在實際應用中 ,我們可以根據(jù)實際并發(fā)數(shù)調整副本的數(shù)量 (即 M 的值 ),來提高搜索性能。同樣 ,當并發(fā)用戶查詢數(shù)量改變時 ,我們可以調整行數(shù) (即 M 值 )。某天，李覺得自己生病了，基本癥狀是“呼吸困難”和“咳嗽”。關于基本信息 ,李選擇“男性” ,“成年人”。特別的 ,發(fā)生在女性患者、兒童以及老年人的身上的疾病會被過濾。為了保護用戶的隱私，根據(jù)李的訪問權限，如姓名、地址這樣的隱私信息會被過濾。交叉表是用來描述形式內容 ,如表 7 中所示。 形式概念計算 根據(jù)定義 7 和算法 4，在我們的例子中有 11 種概念包括在形式內容中，每種概念都被一個圈所表示，如圖 11。此外 ,它證明了李需要其他癥狀來判斷他可能感染的疾病。如果李也有{胸部疼痛、高燒 }的癥狀 ,李可能是感染了急性膿胸。從大數(shù)據(jù)中挖掘有用的知識已經在學術界和工業(yè)界引起了極大關注。同樣，在 Cheng et al. (20xx)中，一組基于云架構的硬件、軟件和設計模式被采用以實現(xiàn)低成本進行快速、大規(guī)模的數(shù)據(jù)挖掘。大醫(yī)療數(shù)據(jù)的應用也被很多工業(yè)界人士和研究人員所關注。作者提到，大量的醫(yī)療保健任務可以由 PHISP平臺來支持，提供很多智能的個性化的服務。通過家庭診斷服務，用戶在家就可以獲得便捷的診斷幫助以判斷他們感染了哪一種疾病。 (Expert system, 20xx) ES 背后的基本理念是把完成特定任務的知識從一個人轉移到一臺電腦。在 (Lee and Wang, 20xx)中，一個模糊專家系統(tǒng)被開發(fā)用于糖尿病診斷，一個 5 層的模糊實體和模糊推理規(guī)則被構建以對關于個人感染糖尿病的可能性作出判斷。類似于在專家系統(tǒng)的這些工作，我們從大數(shù)據(jù)集中提取知識以幫助用戶做出正確的判斷。圖形化的點陣對于用戶而言可以更直觀的判斷他們可能患有哪一種疾病。在 (Zhang et al., 20xxa, 20xxb)中，作者通過子樹方案解決了匿名的大規(guī)模數(shù)據(jù)集的可擴展性問題，以保護醫(yī)療數(shù)據(jù)在分享過程中的隱私。 7 結論和未來工作 在本文中，我們提出了一個基于云架構的自我護理服務稱為家庭診斷。而且，通過家庭診斷服務提供的診斷幫助，他可以為不同的用戶組 提供基本預防知識，特別是老年人和慢性病患者。為了實現(xiàn)靈活的用戶輸入，同義詞問題將出現(xiàn)在我們未來的工作中。n, M., Suel, T., 20xx. To index or not to index: timespace tradeoffs in search engines with positional ranking functions. In: Proceedings of the 35th International ACM SIGIR Conference on Research and Development in Information Retrieval, pp. 255–264. [5] Bahga, A., Madisetti, ., 20xx. Analyzing massive machine maintenance data in a puting cloud. IEEE Trans. Parallel Distributed Syst. 23 (10), 1831–1