1、醫療大數據解決策劃方案醫療大數據解決方案 與信息系統的耦合度為零的數據才是合格的大數據 全國97.8萬家醫療機構的信息系統基本上都是用關系數據庫而建立的，然而要對關系數據庫中的數據進行挖掘非常困難。大數據并不是小數據之和，關系數據庫系統不適合處理大數據。發明專利技術（發明申請號202010495041.8）醫學信息的結構化存貯方法非常適合處理醫療大數據。 目 錄 醫療大數據解決方案 1 第1章 概要 4 1.1 名詞定義 5 第2章 醫療大數據面臨的挑戰 7 2.1 醫療大數據與醫院信息系統之間的具有本質的差異 7 2.1.1 小問題放大萬倍就會大的嚇人 9 2.2 醫療大數據面臨八大難題 1

2、0 2.3 國家大數據標準工程堪比“兩彈一星” 14 2.4 醫療行業的信息系統頂層設計為何難產 15 2.5 大數據挖掘中的問題：大數據的關鍵不在于大而在于如何挖掘 16 2.5.1 我國醫療行業每年產生多少數據 16 2.5.2 挖掘關系數據庫系統所產生的醫療數據非常困難 17 2.5.3 僅患者與數據的對應關系就是一個大問題 18 2.6 關系數據庫理論的致命傷 19 2.6.1 關系數據庫中的數據在大數據環境中為何變成無意義的數據 19 2.6.2 關系數據庫系統是一種完全封閉的系統：外來數據無法入住 22 2.6.3 關系數據庫中的數據與數據系統密不可分 22 2.6.4 關系數據庫

3、中的數據與數據結構密不可分 23 2.6.5 關系數據庫中的數據與應用程序密不可分 23 2.6.6 關系數據庫中的數據一旦脫離相應的系統就成了無意義的數據 24 2.6.7 關系數據庫無法實現病歷信息的結構化存貯 24 2.6.8 關系數據庫中的數據都是“方言”，大數據需要的是“普通話” 24 2.7 關系數據庫如何處理國家醫療大數據中數萬個數據庫、數千萬張表 25 2.8 大數據之夢十年后成真 26 2.8.1 信息化社會由概念到比較成熟用了30多年時間 27 2.8.2 千年蟲問題的啟示 27 2.8.3 大數據工程遠比千年蟲問題復雜 28 2.8.4 五年之內（2020年前）醫療大數據

4、只是紙上談兵 29 2.9 必須開發新型的軟件工具才能對醫療大數據進行高效挖掘 29 第3章 發明專利：醫學信息的結構化存貯方法 30 3.1 在了解醫學信息的結構化存貯方法時的注意事項 31 3.2 醫學信息的結構化存貯方法 32 3.3 數據的完整性是大數據的根本 38 3.3.1 大數據的策略：以適當的數據冗余而使數據易識別 38 3.3.2 一個事物的數據 40 3.3.3 事物分類 40 3.3.4 關系數據庫的缺陷：關系 42 3.3.5 數據的可識別性 46 3.3.6 數據的多樣性 48 3.3.7 元數據及國際元數據標準非常重要 48 3.3.8 大數據的關鍵：讓數據自己說話

5、 49 3.3.9 大數據的策略：用數據代替程序 51 3.4 與信息系統的耦合度為零的數據才是合格的大數據 52 3.5 醫學信息的結構化存貯方法與關系數據庫的對比 55 3.6 應用醫學信息的結構化存貯方法的注意事項 55 3.7 超大表化問題：分為多張表 56 3.8 關系數據庫中的二維表是數據不具獨立性的一個根本原因 56 3.9 “萬能數據結構表”存放病歷信息的例子 56 3.10 醫學信息的結構化存貯方法實現互聯互通非常簡單 58 3.11 結構化錄入病歷信息的例子：癥狀的結構化 58 第4章 獨立數據庫在醫療大數據方面的優勢 61 4.1 大數據中最重要的就是查詢 61 4.2

6、超大表問題 61 4.2.1 自動調整表的長度 62 4.2.2 自動查詢多張表 62 4.3 用獨立數據庫實現國家醫療大數據的存貯處理 63 4.3.1 獨立數據庫如何處理國家醫療大數據中數十萬個數據庫、數千萬張表 63 4.3.2 疾病、癥狀的相關數據 65 第1章 概要 關系數據庫理論存在很多很嚴重的問題，例如，用關系數據庫系統所設計出的信息系統都是孤島型系統，難以實現系統之間的互聯互通；在大數據時代，人們發現，對全國97.8萬家醫療機構所產生的醫療數據進行挖掘非常困難，當前的大多數醫療信息系統都是用關系數據庫系統而設計的。 用關系數據庫系統所設計出的信息系統之所以難以互聯互通，孤島問題

7、嚴重，根本原因在于“異構數據”。醫學信息的結構化存貯方法中的“萬能數據結構表 ”可以存貯各種各樣的數據，也可說用醫學信息的結構化存貯方法所設計出的信息系統所產生的數據都是“同構”的，不存在“異構數據”的問題。關系數據庫理論先天不足，不可能解決“異構數據”問題。 醫院信息系統所處理的數據只是某家醫院所產生的某些特定的數據（可稱作小數據）。醫療大數據所要處理的數據是全國97.8萬家醫療機構所擁有的數十萬個醫療信息系統所產生的數據，這些數據存貯在數千萬張表中，這些系統由不同的開發商所開發，各系統的數據結構各不相同。每家醫院的信息化工作都涉及幾十個廠家，每個廠家的數據、標準、采集、存儲都不一樣。因此，

8、即便是在一家醫院，都會出現很多孤島，整個醫療行業的信息孤島問題更嚴重。各家醫院信息系統的標準、接口都不同，這成為利用率低、共享難的原因之一。不僅如此，數據種類的多樣化也為數據標準的制定和應用帶來了挑戰。 小數據的特點是數據的類型和數據都是有限的，在處理數據前能事先確定數據的類型。而大數據的數據特點是 “多樣性 (variety)”，在處理數據時很難先事先確定數據的類型，甚至不能確定數據的類型。目前關系數據庫在數據處理中占據統治地位，而關系數據庫在處理數據時事先要確定數據的類型，因此，在處理數據類型不能事先確定的大數據時，關系數據庫就遇到了難以逾越的障礙。 醫療大數據與醫院信息系統所產生的數據具

9、有本質的差別。現有的各種信息系統所處理的數據都是小數據。目前人們只是認識到大數據重要性，大數據還只是處于概念階段。大數據夢想將在10年后夢想成真，5年之內，難有突破性進展。 國家醫療大數據所面臨的最大難題：當前的醫療信息系統不能適應醫療大數據的實際需求，需要對現有的信息系統進行徹底的改造才能適應大數據時代的潮流。然而，要徹底改造全國現的醫療信息系統，所花費的代價是非常高昂的！ 關鍵詞：數據與系統的耦合度、萬能數據結構表、獨立數據庫、醫療大數據、數據的獨立性、數據的完整性、數據的可識別性、事物分類。 聯系人：樊夢真 136 6086 7965 qq：269779216 269779216 1.1

10、 名詞定義 l 數據與系統的耦合度：數據與系統的耦合度越高，數據對系統的依賴程度就越高。當數據對系統的依賴程度比較高時，數據一旦脫離了原有的系統就變成了無意義的數據。大數據的數據來源于成千上萬家單位的系統，因此，大數居中的數據應該是與系統的耦合度為零的數據，否則就需要很多的應用程度來解讀數據，這會增加數據處理的難度、成本。 l 萬能數據結構表：由發明專利技術“醫學信息的結構化存貯方法”在模仿大腦記憶、聯想的基礎上而所提出的一種新型數據結構，可以在同一張表中存貯各種各樣的數據。 l 獨立數據庫：由發明專利技術“醫學信息的結構化存貯方法”而建立的數據庫即可稱為獨立數據庫。獨立數據庫與關系數據庫有本

11、質的差異。 l 數據的獨立性：數據的獨立性是由發明專利技術“醫學信息的結構化存貯方法”所提出的概念，是指數據不信依靠數據庫系統、不依靠數據結構、不依靠注釋、不依靠應用程序而獨立地表達出某種含義。關系數據庫中的數據不具有獨立性，需要借助于注釋、數據結構、應用程序才能解讀數據的含義。 l 數據的完整性：數據的完整生是由發明專利技術“醫學信息的結構化存貯方法”所提出的概念，是指數據不信依靠數據庫系統、不依靠數據結構、不依靠注釋、不依靠應用程序而完整地表達出某種含義。關系數據庫中的數據不具有完整性，需要借助于注釋、數據結構、應用程序才能解讀數據的含義。 l 數據的可識別性：在班、組這樣的小環境中可以用

12、每個人的姓名而區分出每一個人，然而在全國范圍內，由于人數太多，很多姓名都有重名現象，因此僅靠姓名就不能準確無誤地識別出每一個人。大數據時代以前的關系數據庫中的數據只是應用于某個機構內部，因此各個數據就容易識別，然而如果把關系數據庫中的數據放到大數據環境中，那么這些數據就成了不可識別的數據。在大數據時代，需要通過數據的獨立性、數據的完整性而確保每一個數據都是可識別的。 l 在醫療大數據中，各個醫療數據分別由各家醫療機構所產生、擁有。 l 事物分類：事物分類是由發明專利技術“醫學信息的結構化存貯方法”所提出的概念。大數據時代以前的信息系統的最終用戶是通過應用程序而看到各種數據，最終用戶并不直接與數

13、據庫中的數據打交道，數據庫中的數據需要通過應用程序解讀后最終用戶才能讀懂。在大數據時代，大數據中包含成千上萬家機構的數據，因此，大數據中的每一個數據庫是由哪家機構所產生，數據庫中各表中所存貯的數據是什么等等都是非常重要的信息，只有搞清楚這些信息，才能正常解讀各數據的真實含義。在“萬能數據結構表”中，“信息系統的名稱、數據庫的名稱、表名”是以“事物分類”的形式存貯在表中，其目的是讓數據具體獨立性、完整性，以此確保各數據在大數據中具有可識別性。 第2章 醫療大數據面臨的挑戰 本章內容提要：大數據并不是小數據之和，大數據與小數據有本質的差異。關系數據庫只適合于處理小數據而不適合處理大數據。用關系數據

14、庫來處理大數據時會遇到很多難以克服的困難。五年之內（2020年前）大數據難以取得根本性突破，大數據之夢十年之后才能夢想成真。維基百科關于大數據的定義也明確指出當前的主流軟件工具不能高效地處理大數據，要高效處理大數據必須開發新的軟件工具。目前的大多數信息系統所產生的數據都存貯在關系數據庫系統中。關系數據庫中的數據的一大特點（或者說一大問題）就是“數據嚴重依賴于數據庫系統及應用程序”，當關系數據庫系統中的數據脫離了相應的數據庫系統及應用程序后，這些數據基本上就成了難以閱讀的無用數據。 2.1 醫療大數據與醫院信息系統之間的具有本質的差異 如果把全國各家醫院所產生的數據全部集中上傳到國家醫療大數據中

15、心，這些數據的數據量一定會非常龐大，這些數據能不能稱為國家醫療大數據？ 按維基百科對大數據的定義：“大數據是指所涉及的數據量規模巨大到無法通過目前主流軟件工具，在合理時間內達到獲取、處理的數據。”這些數據可以稱為國家醫療大數據。 維基百科的定義也明確地說明了把全國各家醫院全部集中起來的“數據量規模巨大到無法通過目前主流軟件工具，在合理時間內達到獲取、處理”。為什么不能處理呢？ 例如，患者就醫時，醫生非常關心患者的病史。醫生能否從國家醫療大數據中心獲得患者在全國任意一家醫院就醫時的所有病歷呢？假設全國各家醫院的所有信息系統所產生的數據都已全部集中在國家醫療大數據中心，而且醫生具有獲得這些數據的權

16、限。 截至2020年3月底，全國醫療衛生機構數達97.8萬個，其中：醫院2.5萬個，基層醫療衛生機構91.8萬個，專業公共衛生機構3.2萬個，其他機構0.3萬個。 全國按2.5萬家醫院計算，一家醫院按4個信息系統計算，全國共有10萬個醫院信息系統，這些信息系統所產生的數據存貯在數千萬張表中。 醫療大數據應該說是永久有用的，可用來研究人類疾病的歷史變化情況。因此，國家醫療大數據應是整個國家數年內、數十年內所產生的全部數據的總和，甚至需要存貯數百年、數千年。國家醫療大數據所涉及的信息量是一般的醫院信息系統的數據量的數萬倍、數十萬倍以上。 醫生要想獲得患者以往的病史數據，就必須從數據千萬張表中查詢患

17、者的病史數據。了解關系數據庫理論者都知道，如果說僅有表中的數據，沒有相應的軟件工具，那么，從數千萬張表中查詢數據，即使最優秀的程序員，在目前的技術條件下，一周的時間內肯定查不出來患者的所有病史數據。因為程序員在查詢數據前，首先要搞清楚如下問題： 1、 這些數據分別是哪家醫院所產生的？ 2、 這些數據分別是什么樣的數據庫系統產生的？ 3、 這些數據分別存貯在哪些表中？ 4、 各張表的結構是什么？ 5、 表中會含有大量的代碼，各個代碼的含義是什么？ 6、 同一數據庫中會有多張表，這些表之間的關系是什么？ 7、 各張表中所存貯的是什么數據？數據的類型是什么？ 國家醫療大數據文件中含有數千萬張表，一張

18、表詳細情況說明基本上要用一頁復印的信息量來描述，共需數千萬頁復印紙才能描述清楚全部表的基本情況。 面對全國97.8萬家醫療機構，2萬多家有一定規模的醫院，數萬個醫院信息系統，數千萬張表，程序員在一周的時間內肯定搞不清楚上述問題。 從理論上而言，只要有數據，程序員可以查詢到任何需要信息，然而由于國家醫療大數據的數據量太大，數據關系太復雜，數據結構太多、數據類型太多、不標準的數據太多，結果是太難太難。 處理小數據時并未感到關系數據庫有什么不足之處，在大數據時代人們已認識到關系數據庫系統不適合處理大數據。 2.1.1 小問題放大萬倍就會大的嚇人 國家醫療大數據并不是把全國各家醫院所產生的數據全部集中

19、在一起就可以稱作是合格的醫療大數據。如果僅是把全國各家醫院所產生的數據全部集中在一起，而沒有處理這些數據的應用程序，那么，這些數據也沒什么用處。 目前不是沒有大數據，而是有很多大數據，然而人們不能高效地對這些數據進行處理。 到目前為止，還沒有成功處理上萬家醫療機構所產生的醫療大數據的成功案例。 大數據比小數據大多少倍？目前沒有明確的定義，應該說真正的大數據要比小數據大一萬倍以上，最少也應大一百倍以上。 大數據的大表現在：一是數據量大（是小數據”萬倍以上”），二是數據類型多（是小數據“萬倍以上”），三是所涉及到的單位多（是小數據“萬倍以上”），四是所涉及到的用戶多種多樣（是小數據“萬倍以上”），

20、五是對數據的需求多種多樣而且不確定（是小數據“萬倍以上”）。 在處理大數據時，會有很多的“萬倍以上”的問題。 3歲小朋友都可以數清楚自已家里有幾口人，然而全國有多少人？由于人數十分龐大，全國人口普查就成了一項十分艱巨的大工程。自有人類以來，還無人能夠數百之百準確地數清楚全球在某段時間內的人數。大家都認為當今的計算機技術已非常先進，然而時至今日，全球、全國的人口普查都做不到百分之百準確。我國歷次人口普查都要花費大量的人力、物力。 宇宙之中有多少個星球體？誰也數不清，因為整個宇宙實在是太大了，宇宙中的星球數量實在是太多了，誰也數不清，永遠也數不清。 事物的數量大到一定程度后一項非常簡單的工作就會變

21、成一項非常艱巨的大工程。 小數據所處理的數據猶如小朋友數家里的人數，大數據所處理的數據猶如全國人口普查。 大數據的特點：小數據中的小問題一旦放大萬倍就會大的嚇人！在大數據處理中，會遇到數量眾多的小問題。 當前的絕大多數信息系統都是用關系數據庫系統而建立的。在設計數據庫系統時，設計人員習慣于用代碼來表示各種數據，例如一些設計人員人用數字“0”來代表女性、用“1”代表男性），有的用“m”來代表男性、“f”來代表女性。全國各行各業擁有數千萬個信息系統，其中的數千萬張表中擁有人的性別這種字段。在當前的情況下，人們是用數據抽取的方法來而使性別這種字段中的數據全部轉換為統一的、標準的數據，例如統一為“男”

22、、“女”。要把全國數千萬張表中的性別數據全部轉換為統一的數據，就是一項非常艱巨的系統工程。 要真正建立起國家醫療大數據，要解決很多個數量十分龐大的小問題。 大數據一般比小數據大數萬倍、數十萬倍，小數據中的小問題一旦放大數萬倍、數十萬倍就會大的嚇人！ 在小數據時代，人們所設計的信息系統只是用來處理某個機構、某個部門內部的某個局部問題進行統計、分析，一個信息系統中只有幾張表、幾十張表。 在大數據時代，人們更關注全國，甚至全球范圍內的對所有事物進行統計、分析，涉及到數百萬、數千萬個信息系統、數億張表。 小數據是為機構內部的人員所使用，是從機構的角度看問題，而大數據而是從全國，甚至全球來考慮問題。 對

23、醫療行業而言，全國擁有近97.8萬家醫療機構，數百萬從業人員，為全國13億人服務。 目前商業智能所處理的還只是一家企業內部的數據，人們已感到對企業內部的數十個信息系統中的數據進行處理已非常困難，而大數據所要處理的是整個行業的數據，比商業智能復雜數萬倍。 l 大數據=價值大=困難大=問題大=代價大 2.2 醫療大數據面臨八大難題 當前國內的各家醫院的各種信息系統都是為了滿足自己的需求而開發的，可以比較好地滿足各家醫院自己的各種需求，并發揮出了重要的作用。然而，當人們從國家醫療大數據的角度來考慮問題時，就會發現要從全國的所有醫療機構的所有信息系統中挖掘出有價值的信息實在是大難了！主要有下述八大難題

24、。 1、 各自為政：各家醫療機構各自為政，都想要別人的的數據，都不希望自己的數據共享給他人。到目前為止，醫療數據都存貯在各家醫療機構內部，從各家醫療機構獲得數據非常難。 2、 數據不標準：醫療行業還未建立全國統一的、標準化、規范的數據，各家醫院的醫療數據各不相同。數據不標準問題是影響大數據處理的一個重大問題，在大數據時代，各行各業的數據標準化工作是大數據的一項非常重要的基礎工作，這項基礎工作搞不好，大數據挖掘工作不可能搞好。醫療行業的數據標準化工作也是一項工程量巨大的系統工程，需要大量的醫務人員共同參與才能完成。國內還未做好這項基礎工作。數據不標準、不規范，會嚴重影響數據挖掘的結果。【數據不一

25、致可以有多種情況，如數據類型不一致，隨意縮寫造成的不一致，計量單位不一致等。當從多個不同的數據源整合數據時，由于定義的不同，更容易產生數據不一致問題。在不同的數據源中，相同類型的信息可能表現為不同的格式。例如，電話號碼通常定義為字符型數據，但在有些數據源中可能將定義數值型數據，因此應將其標準化。典型的例子是字段“性別”，一些人用數字“0”、“1”、“2”來表示“不清”、“男”、“女”。而在其它數據庫中，可能直接用“不清”、“男”、“女”來描述。另一種情況是字段值在不同的數據源中不一致，如“出生地”可能分別使用“上海”、“滬”、“上海市”、“滬市”、“shanghai”、“sh”等表示上海市出生

26、的人。解決這一問題首先應該進行標準化，然后根據標準逐步消除數據不一致的問題。】 3、 業務及業務流程不標準：要對全國的某個行業的大數據進行分析統一，行業內的業務及業務流程的標準化工作也是一項非常重要的工作，否則，各個機構的數據也就會百花齊放、各不相同，不利于分析統計。 4、 數據多樣性(variety)【數據結構不標準、不統一】：全國有97.8萬家醫療機構，這些機構的全部信息系統有數十萬個，這些系統由不同的開發商所開發，各系統的數據結構不盡相同。【每家醫院的信息化工作都涉及幾十個廠家，每個廠家的數據、標準、采集、存儲都不一樣。因此，即便是在一家醫院，都會出現很多孤島，更別說整個醫療行業了。各家

27、醫院信息系統的標準、接口都不同，這成為利用率低、共享難的原因之一。】 5、 數據與數據庫系統、應用系統密切不可分：關系數據庫系統中的每一個數據都要先定義數據結構才能入住數據庫。信息系統的最終用戶所看到的數據都需要應用程序的解讀，最終用戶看不懂關系數據庫中的數據。 6、 不能實現醫學信息的結構化存貯：醫學信息非常復雜，醫務人員習慣于用自然語言編寫各種醫學檔案，例如醫生都是用自然語言編寫病歷。然而，計算機很笨，不能理解自然語言，因此只有把醫學信息結構化之后進行存貯，才能用計算機進行處理。而當前的眾多醫學信息都未能很好地進行結構化存貯。 7、 信息孤島：各家醫院的各個信息系統不能實現全國互聯互通。

28、8、 老系統升級改造難題：當前的信息系統都是小數據系統，不適應大數據時代的需求，然而要對現有的信息系統進行全面改造也是非常困難的，其代價也是非常高昂的。【為什么要升級改造？因為當前的各家醫院的信息系統所產生的數據各不相同，數據不標準、不規范。要對大數據進行處理，必須確保全國各家醫療機構的信息系統所產生的數據是統一的、標準的、規范的醫學標準數據。只有這樣，才能高效處理大數據。】 從理論上而言，醫療大數據挖掘很簡單，只要懂關系數據庫，基本上就能對醫療大數據進行挖掘。然而，要想對全國近百萬個醫療機構、數十萬個信息系統的全部數據進行高效地挖掘，所面臨的挑戰是非常嚴重的。 如何解決八大難題? 1、 各自

29、為政：這個問題必須國家衛生和計劃生育委員會以行政命令的方式來解決，強制要求各醫療單位實時地把各種醫療信息上傳到國家醫療大數據中心。若沒有強制的行政命令，不可能建立起合格的國家醫療大數據。 2、 數據不標準難題：此難題涉及到的數據量太大、工程量太大。國家衛計委及很多人士雖說早就注意到此問題的存在，然而直到目前還未從根本上解決醫療行業的數據標準化問題。此問題不從根本上解決，那么醫療大數據的挖掘就等于說大話。醫療行業數據標準化工作是大數據挖掘的基礎工作。此問題應該由國家衛計委組織業內外力量來解決，解決此問題需要3至5年的時間。有了國家醫療大數據標準之后，還需要用標準的醫療數據去代替現有的不標準的醫療

30、數據，而此項工作的工作量也是非常巨大的。標準化工作是不賺錢的基礎性工作，商業機構沒有從事這項工作的動力，應該由國家衛計委來解決。 3、 業務、業務流程不標準：目前全國各醫療機構的業務及業務流程并不標準，因此，各醫療機構所產生的數據也各不一樣。要建立國家醫療大數據，就必須道先對全國醫療機構的業務流程進行標準化處理，這也是一項工程量巨大的基礎性系統工程。這項工作也應該由國家衛計委來解決。此項工作最快需要三至五年的時間才能完成。 l 只有解決了上述三項基礎性問題，才能夠建立起國家醫療大數據這個大廈的堅實地基，否則醫療大數據只能是空中樓閣。由于上述三個因素牽涉到全國各個醫療機構的方方面面，非常復雜，十

31、年之內很難看到真正的國家醫療大數據的曙光。 下述4個問題屬于技術問題，關系數據庫理論解決不了這4個問題，可由發明專利技術“醫學信息的結構化存貯方法”從技術上加以徹底解決： 4、 數據多樣性(variety)【數據結構不標準、不統一】：目前關系數據庫占據統治地位，絕大多數信息系統都是用關系數據庫而建立的。醫院的各種信息系統中，多數也是用關系數據庫系統而建立。例如，目前國內醫療行業的his系統是由多個開發商所開發，各家開發商所用的數據庫系統不一樣，所用的數據結構結構及數據類型也不一樣。因此，如果要對全國各家醫療機構的his系統中的數據進行分析，那么首先就要把各種數據全部轉換為同一的數據結構，然后才

32、能對數據進行分析統計。然而要對全國近百萬個醫療機構的數十萬個、數百萬個信息系統中的數據進行轉換，也是一項工程量巨大的系統工程。另一外很重要的問題是，所有這些信息系統中的數據要轉換為哪一種統一的、標準的數據結構，也是需要國家衛計委制定相應的標準、規范。 5、 數據與數據庫系統、應用系統密不可分。 6、 不能實現醫學信息的結構化存貯：醫學信息非常復雜，用關系數據庫不能實現病歷信息的結構化存貯。有人用xml實現病歷信息的結構化存貯，然而xml只適合處于少量數據，不適合對全國的病歷信息的處理。 7、 信息孤島。 8、 信息系統改造：現有的醫療信息系統就猶如廣州的城中村，廣州的城中村雖有一定的作用，然而

33、城中村與廣州這樣的國際化大都市非常不協調。改造廣州城中村的最佳方案就是推倒重建，局部的修補是沒用的。然而要全部推倒重建，所花費的資金是非常巨大的。 2.3 國家大數據標準工程堪比“兩彈一星” 大數據工程，標準先行。 國家大數據標準的工程的工程量要比“兩彈一星”的工程量大。 國家大數據標準涉及到每一個行業，也涉及到各種各樣的業務。大數據標準涉及數據的標準化、數據結構的標準化、業務的標準化、業務流程的標準化。 大數據標準化工作完成之后還要對現有的信息系統進行改造，這種改造的工程量及代價也是非常高昂的。目前的信息系統所產生的數據不適應大數據的需求。 歷史對秦始皇統一文字、統一度量衡、統一貨幣的評價非

34、常高：功惠千秋。大數據所面臨的問題也猶如秦始皇時代所面臨的“文字不統一、度量衡不統一、貨幣不統一”問題。因此，要解決大數據所面臨的問題，也需要由秦國、秦始皇那樣強大的機構、領袖人物以行政命令的形式強制推行，才能從根本上解決問題。 大數據八大難題中的五大難題（各自為政、數據不標準、業務流程不標準、數據多樣性(variety)【數據結構不標準、不統一】、信息孤島）與秦始皇曾經遇到的問題有些類似。 為解決千年蟲問題，全球花費了超千億美元的資金。徹底砸爛小數據而建立大數據新環境的代價遠遠超過千年蟲問題。千年蟲只是解決一個時間數據的問題，而徹底砸爛小數據建立大數據新環境則涉及到幾乎所有信息系統的所有數據

35、！ 小數據：只要能滿足自己需求，能解決自己的問題即可。 大數據：不只是滿足自己的需求、解決自己的問題，還要考慮他人的需求。重點是如何讓他人能夠找到所需要的數據。 要讓他人、大家找到所需要的數據，最重要的是大家都要遵循相同的標準，大家都講普通話，而不是方言，這猶如泰始皇統一六國后的“書同文”的標準化改革。 當前在處理大數據時的首要工作就是數據抽取（etl： “extract”、“ transform” 、“load”，“抽取”、“轉換”、“裝載”），其實數據抽取工作也類似“秦始皇的書同文”，只是數據抽取并未能真正象秦始那樣從根本上解決書同文問題。要使大數據真正做到“書同文”，需要象秦始皇那樣從根

36、本上解決問題。而真正實現大數據“書同文”時，就不再需要數據抽取。 與當前人們所提到的大數據相比，關系數據庫所處理的數據則是小數據。大數據中的數據是數萬家、數十萬家以上的各中機構中各種數據的總和。而關系數據庫所處理的小數據則是一家機構或幾家機構中的部分數據。 當我們面對數十萬個、數百萬個以上的信息系統中的數據（大數據）時，就會發現，我們面臨很多挑戰：“（維基百科對大數據的定義）無法在可承受的時間范圍內用常規軟件工具進行捕捉、管理和處理”。也就說明用關系數據庫系統已“無法在可承受的時間范圍內用常規軟件工具進行捕捉、管理和處理”大數據。 在小數據時代，信息系統的用戶是通過應用程序而查到自己所需要的數

37、據，而信息系統對關系數據庫中的數據進行處理后而以用戶能夠理解的形式展現給用戶。然而，在大數據時代，這種方法行不通了。因為在小數據時代，我們所要處理的數據是有限的、可確定的，而在大數據時代，我們所要處理的數據是無限的，不確定的數據。 秦始皇之所以能使“書同文”成為現實，是因為他擁有至高無上的權威；“兩彈一星”之所以能成功，關鍵在于“兩彈一星”關系到國家的生死存亡，國家大力支持。大數據的成敗與國家的支持是分不開的。 2.4 醫療行業的信息系統頂層設計為何難產 國家衛生和計劃生育委員會幾年前就注意到了醫療行業信息系統頂層設計的重要性，并希望從根本上解決此問題，但至今未能從根本上實現醫療行業信息系統的

38、頂層設計。 為什么要進行頂層設計？因為當前的各種醫院信息系統存在嚴重的問題，信息孤島問題嚴重，不能互聯互通。 頂層設計建立在醫療數據標準化、醫療業務流程標準化的基礎之上。而如今醫療數據標準化、醫療業務流程標準化這兩個基礎工作還未做好，因此頂層設計就不可能有結果。 技術上的原因：關系數據庫理論的先天不足。 客觀原因：問題非常復雜、牽涉面太廣、所需資金非常巨大。 頂層設計非常難，比頂層設計更難的是有了頂層設計之后再對全國的醫療信息系統進行全面更新換代。 2.5 大數據挖掘中的問題：大數據的關鍵不在于大而在于如何挖掘 如果把全國97.8萬個醫療衛生機構所產生的數據全部存貯到國家醫療大數據中心，這些數

39、據可以稱作是“國家醫療大數據”，然而這樣的數據并不能稱作是真正合格的“國家醫療大數據”，因為，對這樣的數據的挖掘非常困難，從這些數據中挖掘出有用數據的代價非常高，猶如沙里淘金，大海撈針。 大數據不是小數據之和。大數據的關鍵不在于大，而在于挖掘。只有可以讓大家高效挖掘、任意挖掘的大數據才是真正合格的大數據。 2.5.1 我國醫療行業每年產生多少數據 國家醫療大數據的概況：截至2020年3月底，全國醫療衛生機構數達97.8萬個，其中：醫院2.5萬個，基層醫療衛生機構91.8萬個，專業公共衛生機構3.2萬個，其他機構0.3萬個。 僅按全國擁有2.5萬家醫院、每家醫院4個信息系統計算，全國約有10萬個

40、以上的醫院信息系統，每個信息系統按20張表估算，全國共擁有200百萬張表。 除了存貯在關系數據庫系統中的數據外，還有其它類型的數據：xml、音像、文本等。 國家醫療大數據的數據量估算：南京軍區南京總醫院目前擁有5臺存儲設備，2臺專用于pacs，其中his、lis、emr等數據3t，病案縮微數據12t，pacs數據120t左右，每個月的數據增長為2t左右，每年產生的數據量：24t/年。國家醫療大數據的數據量估算=2.5萬家（未計小醫療機構的數據）*24t/年=60萬t/年。 國家醫療大數據的數據量估算：6萬t/年至100萬t/年。 2.5.2 挖掘關系數據庫系統所產生的醫療數據非常困難 如果全國

41、97.8萬家醫療機構以鏡像的方式把所有數據都上傳到國家醫療大數據中心，那么該如何對這些數據進行挖掘？ 全國共有97.8萬家醫療機構，這些醫療機構所擁有的信息系統有10萬個以上，這些醫療機構所擁有的數據庫有10萬個以上，這些數據庫中的表有200萬張以上。這些醫療機構的數據存貯在數十萬個以上的文件夾中（存貯xml、音像、文本等數據）。患者病史可能是患者自出生以來的所有情況，病史數據可能存貯在幾十年的數據中，并不僅是一年的數據中。 當前的大多數醫療數據都是存貯在關系數據庫中，關系數據庫中的數據與數據庫系統密切相關、與數據結構密切相關、與應用程序密切相關、數據不標準。如果只是以鏡像的方式把全國97.8

42、萬家醫療機構的數據全部上傳到國家醫療大數據中心，要從這些數據中挖掘數據，也是非常困難的。要從國家醫療大數據中查詢患者病歷數據，必要首先搞清楚如下情況： l 10萬個以上的數據庫各用什么數據庫系統？ l 10萬個以上的數據庫的數據存貯在哪里？ip？如何訪問數據庫（帳號）？ l 100萬張以上的表中的每張表的數據結構 l 100萬張以上的表中各表之間的關系 l 100萬張以上的表中的各個數據代碼的含義 l 10萬個以上的文件夾中存貯什么樣的數據 基礎醫療數據大多存在于his、lis、pacs、emr、手術麻醉、體檢、心電等多個子系統中。各系統來源于不同的生產廠商，數據存放在不同的數據庫，數據多而散

43、，數據庫的設計缺乏標準化，不同數據庫中的數據靠患者主索引等進行關聯，關聯關系相當復雜。各自廠家研發人員除了對自家系統的數據結構非常了解之外，缺乏對其他系統數據結構的了解，整體數據分析能力較差。 專業做數據分析及整合的公司，缺乏對醫院實際操作流程的深入了解，導致對數據流向及關聯關系的分析不夠準確，且很難準確的拿到各子系統的基礎數據，最終未必能做到數據全面、準確。 2.5.3 僅患者與數據的對應關系就是一個大問題 如果說要從國家醫療大數據中查詢患者影像數據，那么，該如何實現？ 在當前的醫療信息系統中，關于患者的編碼并不是唯一的，也不是全國統一的。 要查詢某個患者的醫療數據，最理想的查詢方式就是以患

44、者的身份證號作為查詢條件而查詢相關數據。由于目前國內的各種醫療信息系統中的各個表中并不一定擁有患者身份證這一字段，從而使查詢變得非常繁瑣。 例如：下面的表中的數據是一個pacs系統中的數據。此表中并沒有包含可以直接識別患者身份的數據。因為由下表中的“姓名”及“門診及住院號”并不能準確地識別出是哪一個患者。國內同名的人非常多，僅由姓名查義患者的數據是不行的。“門診及住院號”只是各家醫院自己的編號，也不能把“門診及住院號”作為查詢條件。 在上面的pacs系統表中未包含患者身份證數據。因此，需要從his系統中根據患者身份證號而查出患者的“門診或住院號”，再根據“門診或住院號”而從pacs系統表中查出

45、pacs影像數據。 “患者與數據的對應關系”這樣的問題其實是大數據中的一個非常突出的問題。為了查詢的方便，一定要把數據的最主要的特征在數據中表現出來。但關系數據庫理論未考慮此問題。在大數據挖掘中，僅是確定患者的身份就是一項艱巨的工程。對小數據而言，程序員知道相關的數據存貯在哪個表中，但在大數據環境中，程序員不知道想要查詢的數據存貯在哪里。 2.6 關系數據庫理論的致命傷 關系數據庫系統只適合于處理小數據，而不適合處理大數據，其根本原因在于關系數據庫理論的先天不足。 2.6.1 關系數據庫中的數據在大數據環境中為何變成無意義的數據 如果在國家醫療大數據中心查詢到下表的數據，誰能看懂？ 該表中的數

46、據是某家醫院的信息系統中的關系數據庫中的數據，普通人看不懂，醫生也只能靠猜測才能猜出部分內容。 下面的兩張表中的數據也是關系數據庫中的數據，這兩張表中的數據也是普通人難以看懂的： id xm xb nl tz sg 1 張三 男 56 72 180 id xm xb zyf xyf qtfy 2146 張三 男 56 72 180 上面兩表中的數據的實際含義如下： id 姓名 性別 所齡 體重 身高 1 張三 男 56 72 180 id 姓名 性別 中藥費 西藥費 其它費用 2146 張三 男 56 72 180 下表是用發明專利技術“醫學信息的結構化存貯方法”而設計的表，該表中的數據無論是

47、誰，只要懂漢語，就可以看懂表中內容： id 事物代號 事物特征 事物特征值 超長特征值 單位 附件 時間 100 280 事物分類 體育管理系統 2020.3.2 101 280 事物分類 教練信息 2020.3.2 102 280 事物分類 教練基本情況 2020.3.2 103 280 身份證號 xxxxxxxxxx       2020.3.2 105 280 姓名 張三 2020.3.2 106 280 性別 男 2020.3.2 107 280 年齡 56 2020.3.2 108 280 體重 72   kg   2020.3.2

48、109 280 身高 180 cm 2020.3.2 1100 1280 事物分類 病歷 2020.5.3 1101 1280 事物分類 住院病歷 2020.5.3 1102 1280 事物分類 醫療費用 2020.5.3 1103 1280 身份證號 xxxxxxxxxx       2020.5.3 1104 1280 住院號 xxxxxxxxxx       2020.5.3 1105 1280 姓名 張三 2020.5.3 1106 1280 性別 男 2020.5.3 1107 1280 中藥費 56 元 2020.5.3

49、1108 1280 西藥費 72   元   2020.5.3 1109 1280 其它費用 180 元 2020.5.3 相對大數據而言，關系數據庫理論是小數據時代的產物，只適合處理小數據，而不適合處理大數據。 關系數據庫中的數據基本上都是不合格的失真數據，因為關系數據庫系統所面對的用戶只是熟悉關系數據庫理論的設計人員，而不是最終的用戶。關系數據庫的最終用戶所看到的數據是設計人員利用應用程序對關系數據庫中的數據進行解讀之后的數據，最終用戶并不是直接閱讀關系數據庫中的數據。最終用戶也看不懂關系數據庫中的數據。 關系數據庫理論非常注重數據的冗余，用關系數據庫所建立的信息系統所

50、產生的數據所占用的存貯空間比較小，但關系數據庫在減少數據冗余的同時也導致關系數據庫中的數據只有通過應用程序的解讀才能讓最終用戶讀懂數據的含義。 關系數據理論的一個致命傷就是由設計人員隨意定義數據結構（表結構），關系數據庫理論中沒有定義數據結構的國際標準。由此而帶來的嚴重問題就是不同的設計者所設計出的數據結構各不相同，每一個信息系統只認識自己所定義的數據，而不認識其它信息系統所定義的數據。系統與系統之間不能互聯互通，用關系數據庫理論所設計出的信息系統都是孤島型信息系統。 在小數據環境中，可由應用程序來解讀數據的真實含義。然而在大數據環境中，面對數百萬張以上的表，就是災難。 數據猶如語言，數據互聯

51、互通、信息共享的基礎就是大家都講“普通話”。而用關系數據庫理論所設計的每一個信息系統都有自己獨特的“方言”，任何兩個信息系統之間誰也聽不懂對方的“方言”。關系數據庫理論中根本就沒有“普通話”的概念。 在小數據時代，一個信息系統只應用于一個單位，甚至只應用于某個部門，例如醫院的his系統、pacs系統、lis系統。 在互聯網時代、大數據時代，人們逐步發現信息系統之間的互聯互通、信息共享，以及處理數百萬家單位的全部數據具有更大的價值。此時人們才發現原來用關系數據庫理論所設計的信息系統不能互聯互通，用關系數據庫理論不能處理數百萬家單位所產生的大數據。 關系數據庫理論是單機時代時代的產物。在創立關系數

52、據理論之初根本就沒有考慮系統之間的互聯互通、信息共享、大數據問題。關系數據庫理論只適用于一個單位內部，不適合于處理單位之間數據互聯互通。 關系數據庫理論于1970年的6月由ibm公司的研究員埃德加.考特 （edgar frank codd）創立【 論文名稱為大型共享數據庫數據的關系模型（a relational model of data for large shared data banks）】。oracle誕生于1979年。 關系數據庫是信息化社會的功臣，也是當今嚴重的信息孤島的罪魁禍首！ 關系數據庫理論是單機時代、局域網時代的產物，是一種以自我為“中心”的孤島型理論，沒有與外界進行數據交

53、換及數據共享的概念，也沒有數據接口及互聯互通的概念。而當今的互聯網是一種沒有中心的網絡，系統之間的互聯互通是重中之重。用關系數據庫理論所建立的信息系統都是孤島型的，不能互聯互通。 關系數據庫的特點是：雞犬之聲相聞，老死不相往來。我只處理我的系統中的數據，我不處理你的系統中的數據，你也不能處理我的系統中的數據。我不管你的數據，你也別想管我的數據。我的就是我的，你的就是你的，你我之間沒關系。你的數據來到我的系統中是無意義的數據，我的數據到了你的系統中也是意義的數據。我的數據只能在我的系統中生存，你的數據只能在你的系統中生存。正因如此，用關系數據庫理論所設計出的信息系統全都是孤島型信息系統。 2.6

54、.2 關系數據庫系統是一種完全封閉的系統：外來數據無法入住 關系數據庫系統猶如私人住宅，只有家庭成員才能入住，外人莫入。 大數據所需要的是旅館。旅館向所有人開放，誰來了都可以入住，只要有房間。 關系數據庫系統中并沒有現成的位置供數據入住到數據庫中，數據要入住關系數據庫系統中，首先必須先為其定義數據結構，或者說只有已定義數據結構的數據入能入住到數據庫中，而絕大多數外來數據都未經過定義，因此，外來數據都不能入住到數據庫系統中。 2.6.3 關系數據庫中的數據與數據系統密不可分 關系數據庫有多種（oracle、sqlserver、db2、access等等），每一種數據庫都有自己的特點，各種數據庫系統

55、只能處理自己的數據，不能處理其它系統的數據，例如由oracle所產生的數據只能由oracle系統處理，sqlserver處理不了oracle所產生的數據。 關系數據庫中的數據在相應的數據庫系統中才是有意義的，一旦脫離了相應的數據庫系統就成了無意義的數據。 2.6.4 關系數據庫中的數據與數據結構密不可分 關系數據庫中的每一個數據都是有數據結構的，一旦失去相應的數據結構，就成了無意義的數據。 對小數據而言，一個信息系統只有幾張表、幾十張表，多的也只有幾百張表。而對大數據而言，例如國家醫療大數據，就會涉及到數十萬個信息系統中的數百萬張表。而現有的信息系統都只是小數據信息系統，只能認識自己的系統中的

56、數據，都不認識其它系統的數據，都不能處理其它系統的數據。 對關系數據庫而言，它只能處理特定的數據，所謂特定的數據就是只有事先在關系數據庫定義了結構的數據關系數據庫才能處理，不能處理事先未定義結構的數據。而大數據所面臨的數據以不確定，或不好確定為特點，面對不確定的數據、不確定的數據結構，關系數據庫無能為力。大數據的特點：大數據所面臨的是無窮的數據、無窮的數據結構，這是關系數據庫所不能解決的。因此，要處理大數據，必須從根本上解決大數據所涉及到的“無窮的數據、無窮的數據結構”問題。例如，真正合格的大數據處理軟件工具，不但能夠處理國家醫療大數據，也應該能夠其它各行各業的數據。 2.6.5 關系數據庫中

57、的數據與應用程序密不可分 目前的信息系統都是通過應用程序來解讀關系數據庫中的數據，而每個應用程序只能解讀自己的系統中的數據而無法解讀其它系統中的數據。 關系數據庫中的數據不具獨立性、完整性，數據一旦脫離相應的數據庫系統及相應的應用程序就變成了無意義的數據。例如，程序員在設計信息系統時習慣用代碼來表達數據，例如有的用“1”代表男性，用“0”代表女生，而另一些人則用“m”代表男性，用“w”代表女性。在醫院信息系統中，各個信息系統可由應用程序來解讀各個代碼，然而，在醫療大數據挖掘中，這種不規范、不標準、不統一的代碼帶給數據挖掘人員的將是災難！因為醫療大數據挖掘人員所面臨的是全國數萬家醫院的數十萬個信息系統。若要對數十萬個信息系統的數據中的代碼進行分析、轉換，將是一項工程量非常巨在的工程。因此，對大數據而言，盡量不要在數據庫中采用代