2023年健康大數(shù)據(jù)分析應用平臺解決方案

1、健康大數(shù)據(jù)分析應用平臺解決方案 TOC o 1-5 h z 背景介紹1產(chǎn)品愿景1產(chǎn)品定位23. 1解決的問題23. 2達到的效果3產(chǎn)品理念3總體思路55.1對接數(shù)據(jù)源，獲取健康大數(shù)據(jù)分析應用平臺62對獲取的健康大數(shù)據(jù)分析應用平臺預處理機制75. 3建立健康大數(shù)據(jù)分析應用平臺的存儲機制75.4健康大數(shù)據(jù)分析應用平臺的處理和分析算法分類和形成.95. 5開發(fā)專題大數(shù)據(jù)分析，形成專題大數(shù)據(jù)應用115. 6開發(fā)機構大數(shù)據(jù)分析，建立機構大數(shù)據(jù)應用117建立平臺應用實施推廣組織機制 115.8建立平臺產(chǎn)品優(yōu)化升級服務組織機制 11健康大數(shù)據(jù)分析應用平臺建模描述和分析 121我們給出的相關數(shù)據(jù)模型 136.

2、2衛(wèi)計委給出的相關數(shù)據(jù)模型146.3相關數(shù)據(jù)特征對比分析 17健康大數(shù)據(jù)分析應用平臺支持的業(yè)務主題場景 191醫(yī)療衛(wèi)生服務機構應用21健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.07. 11.37. 11.3商業(yè)醫(yī)療保險的保障設計和精算定價60健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.07. 11.37. 11.3商業(yè)醫(yī)療保險的保障設計和精算定價60健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.07. 5.37. 5.3政府醫(yī)療規(guī)劃結構進行居民健康保健決策應用421. 1各級醫(yī)院自身應用211.2基層醫(yī)療

3、機構自身應用267.1.3區(qū)域衛(wèi)生醫(yī)療聯(lián)合體應用271.4醫(yī)療衛(wèi)生機構的合規(guī)應用327.2患者醫(yī)療治療應用347.2.1患者就醫(yī)過程提示服務347. 2.2患者服藥提示服務347. 2.3患者飲食、運動、習慣注意事項服務357.2. 4患者體征和治療效果服務357. 2.5患者交流交往服務357. 3個性化醫(yī)療服務應用353. 1基因測序分析應用363.2個性化藥物應用367. 3.3個人健康管理應用377. 4慢性病預防治療應用（疾控中心）387.4. 1慢性病檢測、發(fā)現(xiàn)、預警服務397.4.2慢性病診斷服務407.4.3慢性病防控治療服務407. 5居民健康保健應用（疾控中心） 417.5

4、.1居民自我健康保健應用417.5.2政府衛(wèi)生管理部門進行居民健康管理應用 427.6醫(yī)療衛(wèi)生管理機構應用（衛(wèi)生局）427.7醫(yī)療保險管理機構應用（醫(yī)保局） 437. 1基本醫(yī)療保險的決策支持分析 457.2基本醫(yī)療保險費用單據(jù)的智能化審核 467.3基本醫(yī)療保險的有效支付和治理應用477. 4基本醫(yī)療保險和服務監(jiān)管應用477.5降低看病率提升醫(yī)療效果應用487.8醫(yī)藥監(jiān)管機構應用（藥監(jiān)局）527.9醫(yī)藥研發(fā)生產(chǎn)經(jīng)營應用（醫(yī)藥企業(yè)） 521醫(yī)藥研發(fā)企業(yè)應用527.9.2醫(yī)藥生產(chǎn)企業(yè)應用537.9.3醫(yī)藥流通企業(yè)應用537.9.4醫(yī)藥零售企業(yè)應用567. 10醫(yī)療衛(wèi)生資源配置管理規(guī)劃應用（政府主

5、管部門）577. 10. 1醫(yī)療衛(wèi)生資源服務現(xiàn)狀分析 577.10.2醫(yī)療衛(wèi)生資源財務供給能力分析 587. 10.3醫(yī)療衛(wèi)生資源規(guī)劃指標對比587. 10. 4醫(yī)療衛(wèi)生資源政策建議597. 11商業(yè)醫(yī)療保險應用（保險公司） 597. 11. 1獲得新客戶和保留已有客戶的分析應用597. 11.2有效控制醫(yī)療費用的分析應用60健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.08. 4.98. 4.9患者特征-診斷結論分類分析81健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.08. 4.98. 4.9患者特征-診斷結論分類分析81健康大數(shù)據(jù)分

6、析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.08.1.18.1.1患者數(shù)據(jù)預處理767. 11. 4商業(yè)醫(yī)療保險的理賠運營管理應用 617. 11.5商業(yè)醫(yī)療保險的市場和銷售拓展應用647. 12公共衛(wèi)生服務應用（衛(wèi)生防疫中心） 6412. 1傳染病預警預報657. 12.2公共衛(wèi)生輿情監(jiān)測預警6612.3疾控和保健應用677. 13政府監(jiān)管應用（政府主管部門）6713. 1醫(yī)藥監(jiān)管應用677. 13.2醫(yī)療監(jiān)管應用687. 13.3醫(yī)保監(jiān)管應用697.13. 4醫(yī)療服務機構和醫(yī)生監(jiān)管應用707. 14新型醫(yī)療衛(wèi)生服務應用（政府主管部門）707. 14. 1遠程醫(yī)療717.

7、14.2移動醫(yī)療717. 14.3互聯(lián)網(wǎng)醫(yī)療737. 14.4數(shù)字醫(yī)療737. 14.5大數(shù)據(jù)醫(yī)療737. 14.6智慧醫(yī)療747. 14. 7精準醫(yī)療74健康大數(shù)據(jù)分析應用平臺支持的專題大數(shù)據(jù)應用758.1患者分析（基于電子病歷EMR） 761. 2患者個體（個性）分析771.3患者群體（統(tǒng)計）分析778.2疾病分析（基于電子病歷EMR和電子健康檔案EHR） 77& 2. 1常見疾病分析77& 2. 2慢性疾病分析77& 2. 3疾病誘因分析78& 2. 4疾病統(tǒng)計分析78& 2. 5臨床路徑分析788.3醫(yī)生及醫(yī)護人員分析（基于醫(yī)療衛(wèi)生資源數(shù)據(jù)） 78& 3.1醫(yī)生及醫(yī)護人員資歷資格分析7

8、8& 3.2醫(yī)生及醫(yī)護人員行醫(yī)記錄分析78& 3. 3醫(yī)生及醫(yī)護人員培訓進修分析784處方分析（基于電子病歷EMR） 78& 4. 1醫(yī)生用藥分析79& 4. 2患者用藥分析79& 4. 3處方用藥分析80& 4. 4醫(yī)院科室用藥分析80& 4. 5安全用藥分析80& 4. 6處方符合性分析80& 4. 7處方用藥-診斷結論關聯(lián)分析81& 4. 8診斷結論-處方總價聚類分析81健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.09.9.關鍵核心技術和算法97健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.09.9.關鍵核心技術和算法97健康大數(shù)

9、據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.08. 7.28. 7.2醫(yī)學影像圖像分析95& 4. 10患病時間-診斷結論序列分析 818.5居民人口分析（基于電子健康檔案EHR） 82& 5. 1居民個體健康分析82& 5. 2人口群體健康分析82& 5.3人口亞健康相關因素關聯(lián)分析82& 5.4人口健康相關因素關聯(lián)分析82& 5.5人口健康時間空間分布分析82& 5. 6人口健康預測分析828.6藥品分析（基于醫(yī)藥產(chǎn)業(yè)鏈數(shù)據(jù)）82& 6.1藥品種類分析83& 6.2藥品研發(fā)分析84&6.3藥品生產(chǎn)分析87& 6.4藥品銷售分析87& 6.5藥品物流分析88& 6.6藥

10、品資金流分析89& 6.7藥品信息流分析89& 6.8藥品庫存分析89&6.9藥品質(zhì)量偏差分析94&6. 10藥品不良反應&藥品群體不良事件分析 947醫(yī)療健康檢驗檢測分析（基于電子健康檔案EHR） 941生理信號檢測分析947. 3 DNA檢測和DNA序列分析958.7.4重要人體征數(shù)據(jù)分析 957.5遠程自助健康醫(yī)療檢測分析958醫(yī)療安全風險分析（基于電子病歷EMR） 951醫(yī)療安全分析958.8.2醫(yī)療風險分析958.8.3假藥、過期藥、成分異常藥的使用分析968.8.4醫(yī)療事故誘因分析968.8.5醫(yī)療安全風險統(tǒng)計分析968.9醫(yī)療衛(wèi)生資源分析（基于政府的醫(yī)療衛(wèi)生資源數(shù)據(jù)）.961醫(yī)生

11、護理人員分析968.9.2醫(yī)院床位分析968.9.3醫(yī)療檢測檢驗能力分析968.9.4醫(yī)療衛(wèi)生資源需求分析968.9.5醫(yī)療衛(wèi)生資源匹配度分析968.9.6醫(yī)療衛(wèi)生資源對比分析 9710醫(yī)療衛(wèi)生效果分析（基于電子健康檔案HER和醫(yī)療衛(wèi)生資源數(shù)據(jù)）9710. 1醫(yī)療衛(wèi)生滿意度分析9710.2醫(yī)療衛(wèi)生問題誘因分析9710.3醫(yī)療衛(wèi)生規(guī)劃符合度分析 97健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.01大數(shù)據(jù)分析能力982大數(shù)據(jù)分析技術983大數(shù)據(jù)存儲技術和系統(tǒng)994大數(shù)據(jù)業(yè)務模型建模1005大數(shù)

12、據(jù)的實時查詢1036大數(shù)據(jù)的復雜分析104用健康大數(shù)據(jù)分析應用平臺為業(yè)務服務 1081核心理念10810.2管理閉環(huán)109健康大數(shù)據(jù)分析應用平臺解決方案V3. 健康大數(shù)據(jù)分析應用平臺解決方案V3. 0第第 頁庫系統(tǒng)不適合存儲非結構化數(shù)據(jù)。一種解決方案是采用兩套系統(tǒng)分 別存儲結構化與非結構化數(shù)據(jù)，但這為兩種數(shù)據(jù)之間進行聯(lián)接查詢 (join)帶來了困難。例如，當要尋找某科室患者的所有CT影像圖 片時，需要首先在業(yè)務數(shù)據(jù)庫中查詢到該科室所有患者的II),然后 再到非結構化數(shù)據(jù)庫中查找圖片。這種跨數(shù)據(jù)庫的聯(lián)接查詢的執(zhí)行 效率不高。因此，就醫(yī)療健康大數(shù)據(jù)而言，需要研究一種基于混合 數(shù)據(jù)模型的數(shù)據(jù)管理系統(tǒng)

13、，能夠高效管理結構化數(shù)據(jù)與非結構化數(shù)據(jù), 并支持異構數(shù)據(jù)之間的高效混合查詢。5大數(shù)據(jù)的實時查詢醫(yī)療服務對時效性的要求很高，很多查詢都要求得到實時響應。 智慧醫(yī)療中涉及實時查詢的可大致分為：與時間有關的查詢，如檢索監(jiān)護對象某一時間段內(nèi)的全部信 息；與空間有關的查詢，例如檢索監(jiān)護對象在某個區(qū)域(如某個 醫(yī)院)內(nèi)的全部信息；與特定屬性有關的查詢，例如檢索監(jiān)護對象的血壓變化歷史 和用藥記錄等；綜合查詢，例如檢索監(jiān)護對象在某段時間和某個區(qū)域內(nèi)的某 項生命體征數(shù)據(jù)。高效實時查詢的關鍵是必須預先了解查詢類型并建立所需的索 引。當數(shù)據(jù)規(guī)模非常大時，現(xiàn)有數(shù)據(jù)庫采用的索引技術基本能夠滿 足數(shù)據(jù)檢索的實時性需要，但

14、在索引的創(chuàng)建與更新的性能方面有較大 不足。例如，我們的測試結果表明，用一臺運行PostgreSQL的服務 器為200萬條數(shù)據(jù)(約1GB)在一個空間屬性上創(chuàng)建R-tree索引，用 時約為20分鐘；在此基礎上再次插入40萬條數(shù)據(jù)(約0. 2GB),用時 約為60分鐘。根據(jù)這個結果，當數(shù)據(jù)產(chǎn)生的速度大于960萬條/天 時，即使服務器的全部計算資源都用于維護索引，索引的更新速度仍 將落后于數(shù)據(jù)產(chǎn)生的速度。而如果1個醫(yī)療傳感器每15秒產(chǎn)生1條 測量數(shù)據(jù)，1萬個這樣的傳感器每天將產(chǎn)生超過5000萬條數(shù)據(jù)。這 意味著現(xiàn)有的索引更新方法無法勝任醫(yī)療健康大數(shù)據(jù)處理的需求。 此外，是一種常用的避免更新索引的方法是

15、在插入新數(shù)據(jù)之前刪除索 引并在之后重新創(chuàng)建索引，但這種方法不能從根本上解決問題，因為 隨著數(shù)據(jù)不斷累積，重新創(chuàng)建索引所用的時間越來越長，最終會比更 新索引的速度更慢。為滿足大數(shù)據(jù)實時查詢的需要，必須對現(xiàn)有的索引技術必須加以 改進，將索引的創(chuàng)建與更新速度提高至少一個數(shù)量級。索引更新速 度慢的一個重要原因是數(shù)據(jù)逐條添加時引發(fā)了多次隨機小量寫操作， 因此首先需要重新設計索引結構，使其能夠批量添加數(shù)據(jù) (bulk-insertion)，盡量用順序?qū)懭氪髩K數(shù)據(jù)取代隨機寫入小塊數(shù)據(jù)。 另外，需要設計索引的并行創(chuàng)建與更新算法，使索引的創(chuàng)建與更新能 夠在無共享架構中水平擴展。6大數(shù)據(jù)的復雜分析在智慧醫(yī)療中，有

16、很多復雜的數(shù)據(jù)分析查詢，以下僅舉幾例：(1)醫(yī)療數(shù)據(jù)統(tǒng)計，如統(tǒng)計歷年慢性病比例變化和各地區(qū)心腦血管疾病分布等；相似聯(lián)接查詢(similarity join),如根據(jù)CT成像圖片， 尋找相似的病例與診斷，尋找骨髓移植匹配等；醫(yī)療數(shù)據(jù)挖掘與預測，如尋找亞健康狀況與職業(yè)、性別、年 齡等因素的聯(lián)系和預測下一個月各類藥品的需求等。這些復雜分析 查詢的主要特點有：需要讀取大量數(shù)據(jù)，所需計算時間長；查詢靈活多變，難以預測；涉及多學科交叉，需要醫(yī)療、統(tǒng)計、計算機等各領域的專業(yè) 人士協(xié)作完成。傳統(tǒng)關系數(shù)據(jù)庫與NoSQL數(shù)據(jù)庫難以勝任復雜的數(shù)據(jù)分析，其原 因主要有兩個。首先，它們在維護數(shù)據(jù)庫的原子性、一致性、分離

17、 性和持久性方面花費了巨大的開銷，而在進行復雜的數(shù)據(jù)分析時，數(shù) 據(jù)往往是靜態(tài)的，因此這些開銷是不必要的。第二，它們的存儲與 索引結構是為數(shù)據(jù)的隨機讀寫與頻繁更新而設計，沒有為大量數(shù)據(jù)的 讀取進行專門優(yōu)化。目前，對大數(shù)據(jù)進行復雜分析的工具主要有兩大類。一類是并 行分析型數(shù)據(jù)庫，另一類是基于MapReduce的數(shù)據(jù)分析工具。分析型數(shù)據(jù)庫基于關系數(shù)據(jù)模型，與傳統(tǒng)關系數(shù)據(jù)庫相比，其存 儲結構與查詢算法為數(shù)據(jù)讀取進行了專門優(yōu)化，如用列式存儲 (column-store)替代行式存儲(row-store)。目前主流的并行分析型 數(shù)據(jù)庫的有Vertica和Greenplum等。這些數(shù)據(jù)庫提供的用戶接口 是與

18、傳統(tǒng)關系數(shù)據(jù)庫相同的結構化查詢語言（SQL） o這種實現(xiàn)方式降 低了用戶的學習成本，但也帶來了兩個問題。首先，雖然關系數(shù)據(jù) 模型能夠進行擴展以表示非結構化數(shù)據(jù)，但由于數(shù)據(jù)種類繁多，目前 缺少足夠有效的理論與工具將非結構化數(shù)據(jù)轉(zhuǎn)化為結構化數(shù)據(jù)；第 二，一些復雜的數(shù)據(jù)分析難以直接用SQL描述，即使能夠用SQL描 述，其執(zhí)行效率也比專門編寫的過程化分析程序要低得多。MapReduce是Google于2003年提出的一種新的基于無共享架構 的并行計算范式。與傳統(tǒng)并行計算范式（如MPI）相比，MapReduce 簡化了并行數(shù)據(jù)處理算法的設計與實現(xiàn)，使用者僅需根據(jù)查詢需要定 義map和reduce兩個函數(shù)

19、，無需關心并行執(zhí)行過程中的任務調(diào)度、 資源管理以及出錯處理等問題。MapReduce最初是為處理Google的 海量文本數(shù)據(jù)的簡單分析算法而設計。隨著Apache Hadoop項目提 供的MapReduce開源實現(xiàn)在學術界與工業(yè)界廣泛使用，MapReduce編 程模型被證明十分靈活。我們不僅可以在其上構建分析型數(shù)據(jù)庫（如 Hadoop Hive）,而且能夠?qū)崿F(xiàn)常用的數(shù)據(jù)挖掘與機器學習算法程序庫 （如 Apache Mahout）。從大數(shù)據(jù)分析性能的角度看，數(shù)據(jù)庫專家們對并行分析型數(shù)據(jù)庫 與MapReduce的優(yōu)劣曾經(jīng)有過長達數(shù)年的爭論。隨著對兩者研究的 深入，目前已取得的主要共識有：對于簡單的

20、結構化查詢，當計算節(jié)點較少時（100臺或以下），并 行分析型數(shù)據(jù)庫由于采取了更優(yōu)化的存儲結構與查詢算法，性能明顯 優(yōu)于 MapReduce；當計算節(jié)點較多時，此時計算節(jié)點出錯的概率很高，并行分析型 數(shù)據(jù)庫在出錯時往往需要重新執(zhí)行整個查詢，性能會受到較大影響, 而MapReduce的設計從一開始就將常態(tài)化的出錯問題納入考慮，因此 能夠輕松擴展到數(shù)千臺節(jié)點；并行分析型數(shù)據(jù)庫必須預先加載數(shù)據(jù)，而數(shù)據(jù)加載的時間通常十 分漫長，因此對于日志分析等僅需讀取一次數(shù)據(jù)的任務并不合適； MapReduce比并行分析型數(shù)據(jù)庫的應用更廣泛，如能夠處理非結 構化查詢，實現(xiàn)復雜的數(shù)據(jù)挖掘算法；盡管編程模型簡單，但Map

21、Reduce仍需要專業(yè)人員進行編程工作， 并行分析型數(shù)據(jù)庫的使用成本比MapReduce低。從嚴格意義上看，并行分析型數(shù)據(jù)庫與MapReduce并不具備直接 可比性。前者是包含查詢語言、邏輯數(shù)據(jù)模型、并行執(zhí)行引擎、物 理存儲結構等一整套機制的實現(xiàn)，而后者僅與前者中的并行執(zhí)行引擎 的角色類似。整合二者的優(yōu)點，可以構建出更為強大的數(shù)據(jù)分析工 具，這也是數(shù)據(jù)庫領域一個活躍的研究方向。例如，為了保證髙容 錯性，MapReduce將計算的中間結果保存在磁盤上，這樣做帶來了巨 大的開銷，影響了查詢的執(zhí)行效率。并行分析型數(shù)據(jù)庫為了保證高 效，采用pipeline機制，即上一步的結果在內(nèi)存中產(chǎn)生后直接通過 網(wǎng)

22、絡推送到下一步的計算單元。由此可以得出一個構建高效可擴展 的分析型數(shù)據(jù)庫的思路，即在pipeline機制的基礎上，同時將中間 結果寫入磁盤。事實上，二者的融合已經(jīng)在目前最新的數(shù)據(jù)分析工 具（如Google Tenzing）中得到體現(xiàn)。無論是并行數(shù)據(jù)庫還是MapReduce,都致力于解決機器的執(zhí)行效 率問題。在對醫(yī)療健康大數(shù)據(jù)進行復雜分析時，醫(yī)療專家的知識與 智能在整個分析過程中起著至關重要的作用。但是，要求醫(yī)療專家 同時精通分析型數(shù)據(jù)庫的使用甚至編寫MapReduce程序，是不現(xiàn)實 的。因此，如何在這些復雜的數(shù)據(jù)分析系統(tǒng)之上，提供一個具備良 好可視化與互動功能的交互界面，是幫助醫(yī)療專家發(fā)掘醫(yī)療

23、健康大數(shù) 據(jù)價值的關鍵。用健康大數(shù)據(jù)分析應用平臺為業(yè)務服務通過一系列技術處理，大數(shù)據(jù)可以幫助企業(yè)制定明智且切實可行 的戰(zhàn)略，獲取前所未有的客戶洞察，支持客戶購買行為，并構建新的 業(yè)務模式，進而贏得競爭優(yōu)勢。然而，實踐往往會比理論來得更困難， 現(xiàn)實中許多企業(yè)管理者盲目收集數(shù)據(jù)并進行分析，期待能夠得到快速 的回報。很遺憾，他們未能如愿。無論整體規(guī)劃、技術平臺還是業(yè)務 流程，大多數(shù)企業(yè)并未針對大數(shù)據(jù)分析做出特別的調(diào)整與變化。企業(yè) 要處理好大數(shù)據(jù)生命周期的每一個環(huán)節(jié)，就必須采用創(chuàng)新且經(jīng)濟高效 的處理方法，并跳出傳統(tǒng)的數(shù)據(jù)管理思維。10.1核心理念首先，管理者需要問清自己這樣一個問題：“大數(shù)據(jù)如何幫助我

24、 的企業(yè)實現(xiàn)發(fā)展？ ”。如果不能指導行動，那么收集再多的數(shù)據(jù)也是 毫無意義的。事實上，獲得洞察力是一方面，可實踐性也是分析的標 志之一。即企業(yè)能否從大量歷史數(shù)據(jù)的“噪音”中獲得可實踐的預測 以及具有前瞻性的決策？其次，需要針對大數(shù)據(jù)分析來改變傳統(tǒng)的業(yè)務流程與決策流程。 按照傳統(tǒng)企業(yè)經(jīng)營方式，髙層的主觀意見會對決策造成決定性影響， 這種現(xiàn)象到現(xiàn)在也還是非常普遍。讓真實的數(shù)據(jù)來說話，這是許多企 業(yè)管理者需要進行的觀念轉(zhuǎn)變。當然，收集更多的數(shù)據(jù)并不意味著就 能夠?qū)?shù)據(jù)轉(zhuǎn)化為洞察，如果沒有一個更適應大數(shù)據(jù)時代的技術架構, 它也會讓企業(yè)的轉(zhuǎn)型變得難上加難。第三，技術平臺不是萬能的，但沒有技術平臺是萬萬不

25、能的。在 很多情況下，我們會看到各種觀點在弱化技術所起到的作用。事實上， 這樣的觀點是比較片面的。要真正掌握駕馭大數(shù)據(jù)，我們?nèi)匀恍枰?個過硬的技術平臺來作為支撐。你很難想象用現(xiàn)有的SQL數(shù)據(jù)庫來分 析海量醫(yī)療衛(wèi)生半結構化或非結構化信息，大數(shù)據(jù)需要我們有一個更 全面、更高效的平臺來進行組織、處理和分析數(shù)據(jù)。同時需要考慮如 何將大數(shù)據(jù)平臺，與原有的數(shù)據(jù)架構進行最佳集成。10.2管理閉環(huán)這里采用一套方法論，幫助思考以下幾個問題，并加大數(shù)據(jù)轉(zhuǎn)化 為實在的收益：1我們是否擁有目前所需的大數(shù)據(jù)？我們能否獲取這些大數(shù)據(jù)？獲取大數(shù)據(jù)后，我們?nèi)绾瓮诰蜻@些大數(shù)據(jù)的價值？4業(yè)務環(huán)境發(fā)生變化時，我們?nèi)绾翁幚磉@些大數(shù)據(jù)？企業(yè)在進行數(shù)據(jù)管理方式轉(zhuǎn)型的時候，需要從四個方面來把握并 健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.0第口第口0頁健康大數(shù)據(jù)分析應用平臺解決方案V3.0健康大數(shù)據(jù)分析應用平臺解決方案V3.0第第in頁覆蓋數(shù)據(jù)的全生命周期，即設想、創(chuàng)建、部署和擴展，并以此形成一 個有機的閉環(huán)。根據(jù)這一方法論，推出了有針對性的大數(shù)據(jù)服務，幫 助企業(yè)從數(shù)據(jù)中獲取全新洞察，進一步擴展業(yè)務功能，獲得更多業(yè)務 機會。在