摘 要
基於平臺的數據中心建設模式與傳統意義上的方法建設數據中心在數據中心數據抽取、加載、清洗、整合方面應該是不一樣的建設方法。平臺方式下服務總線進行數據的交換時完成了很多數據分類的傳遞，這些數據分類需要自動化進行數據中心的數據整合，同時通地平臺提供的適配器完成其它數據分類的整合。
本文不對數據中心的利用及進行討論，聚焦在業務數據中心的數據整合層面。
關鍵詞： 數據元 數據集 集成平臺 信息模型
正文
引 言
目前醫療行業中在平臺建設模式下，採用ESB進行信息交換，而數據中心採用另一套ETL的方式進行數據的整合，這種方式沒有充分利用平臺內部整合價值，在成本、時間方面都是一種浪費。
醫療行業經過多年發展，從專業化出發，引入了大量的專業化的軟件，所以出現大量的交互集成問題，交換集成問題在早期是採用點對點或數據共享方式實現，由於接口數量的劇增，後面引入ESB來解決一源多用與系統耦合度高的問題。另一方面，專業化程序高化，各種醫療數據都分散到各在各自的業務系統中，數據利用變得十分困難，針對這個問題，大家就採用ETL的方式來進行集中數據中心的建設。
採用ESB與ETL來實現兩個不同的業務目標，存在不少的問題：
1、交換信息的分類數據中與ETL構建數據中心的數據分類中有大量重疊部分；
2、ETL的時效性方面不是很好，一般都是在晚上進行，所以有很大滯後；
3、ETL採用的數據抽取方法一般對原有系統的性能有一定影響；
4、交換的信息與數據中心採用的標準很難進行統一。
以數據集作為數據交換與數據整合的基礎
數據集是一類數據所有數據元的集合，具有結構與邏輯關係，他可以與協議標準融合形成交換標準；向下構建數據中心物理模式。
數據元設計時採用衛生部頒佈《衛生信息數據元目錄 第1部分》規範作為參考基礎，數據元編碼規範：
數據集根據業務特點進行建模，讓其具有結構與邏輯關係，數據集其實可以理解一個信息模型，設計時要形成以下關鍵要素信息：
1、 主集與子集：從概念模型的角度出發進行設計，主集是一個數據分類的基本信息；子集是一個數據分類的明細信息；如檢驗報告數據集主集為檢驗報告基本信息，如檢驗項目、檢驗時間、病人基本信息等；檢驗子集是指檢驗明細信息；數據集中主集僅有一個，子集可以有多個；
2、 業務主鍵：用數據集承載數據時，能唯一標識確定一筆業務的數據元稱為業務主鍵。針對主集而言，可以理解為申請單號或報告單號及病人ID；針對子集而言，業務主鍵可以理解為唯一確定子集中一行數據的數據元；
3、 業務外鍵：子集中才有外鍵的概念，通過外鍵子集可以關聯到主集，與數據庫的外鍵的用途上是一致；
4、 索引：主集與子集都可以建索引，與數據庫索引用途一致；
5、 非空：指數據元不能為空，不能為空的字段，在交換與數整合中可以作為校驗方法；
6、 其它數據元的屬性，如長度、精度、類型由數據元中進行定義；
數據集定義從數據中心這個維度看，其它是一個概念模型的生成過程，通過概念模型的生成，就可進一步映射成物理模型。
數據集是通過一個管理工具來實現，也意味著根據業務特點需要調整數據集規範時，我們同時可以調整數據中心的物理模型規範。這樣就可實現一種動態管理的要求，可以根據業務與管理要求，分階段來實現數據中心的數據分類規劃，如數據中心前期我們實現以病人為中心的臨床數據中心；後面可慢慢來實現運營管理數據中心。而不要像傳統的方法採用窮舉的方式，在數據中心建設前期需要對數據分類進行全面規劃，實際上全面規劃也做不到，一來有可能某些方面考慮不周期；另一個有些業務是一將來才可能出現。
以交換與適配器兩種方式進行數據整合
通過平臺進行系統集成與業務協同實現，交換的數據分類越來越多，數據中心大部分數據分類都可以通過信息交換來進行自動化的數據整合。
以目前的業務特點來看，以病人為主線的臨床數據中心（CDR）是基本上可以通過信息交換過來的數據來完成數據整合；物流如藥品、物資、耗材等也可以通過交換來實現數據中心的整合。
其它不能通過數據交換來完成數據整合的數據分類，通過平臺提供的適配器來快速完成
數據整合。
適配器的特點：
1、直接利用數據集的制定的數據規範，通過數據集規範中的數據標準與原有系統標準進行對應與轉換，快速完成數據的接入，同時完成數據清洗與轉換；
2、對生產系統影響很小，適配器的特點不會在原有系統建觸發器、視圖；沒有特殊數據轉換時不會讀源表；不會與原表比對；
3、中心端數據集標準有變化，在適配器中直接下載變化的標準後，對變化內容進行匹配與轉換，可以快遞應對標準變化；
總結
基於平臺的數據中心建設模式是一種以業務與管理為導向的建設思路，能極大滿足未來各種複雜的業務局面。一來降低技術的複雜度與人員要求；同時大家的重點關心問題從技術層面轉移到業務與管理上。
閱讀更多 platform 的文章
