臨床醫療數據倉庫構建方法范文

本站小編為你精心準備了臨床醫療數據倉庫構建方法參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

《中國生物醫學工程學報》2016年第二期

摘要:

醫療信息的復雜性和動態性給醫療信息系統帶來巨大的挑戰，openEHR規范的兩層建模思想提高醫療信息系統的靈活性，適應醫療信息需求的變化。但面臨查詢數據量巨大、查詢條件復雜多變的個性化操作需求時，基于openEHR兩層建模方法實現醫療信息系統查詢性能較低，這主要與底層數據存儲模型有關。數據倉庫多維數據模型具有高性能查詢的優點，通過建立滿足個性化需求的數據集市，可以加快數據查詢速度。由于基于openEHR規范兩層建模方法實現的醫療信息系統的特殊性，傳統的數據倉庫構建方法使得用戶的參與性較低并且費時費力。針對這一問題，以openEHR規范的兩層建模思想為基礎，提出模板到動態數據倉庫多維數據模型的映射方法，實現多維數據模型的用戶可配置，利用映射路徑加快ETL的實施，為醫療行業提供一種可操控、可擴展并真實反映用戶需求的數據倉庫構建方法。對該方法進行性能上的驗證，結果表明，在10861522條數據中查詢329條數據時，基于該方法構建的數據集市是基于openEHR兩層建模方法生成的數據庫的5.6倍，是基于傳統方法構建的數據集市的0.97倍。

關鍵詞:

openEHR;模板;數據倉庫;多維數據模型

醫療領域的醫學知識和醫療業務需求復雜多變，采取傳統的醫療信息系統開發方法，工程技術人員不僅要在醫療信息系統開發之時即與醫療領域專家反復討論確認，而且在系統的使用過程中還要不斷對系統進行維護和更新，這使得醫療信息系統很難及時響應醫療人員對醫療信息的需求。openEHR規范作為一套開放的EHR(electronichealthrecord)體系結構，其核心在于將醫療領域知識從具體的臨床信息中分離出來，并建立兩層模型———參考模型和原型模型［1－2］。按照openEHR規范的設計，系統底層結構的開發主要基于參考模型，而系統中所涉及的領域概念全部由原型定義，這就有效降低了系統底層結構對領域知識的依賴性，從而使系統對領域知識變化的適應能力大大增強。領域知識層由原型和模板組成，允許領域專家直接定義，從而“把臨床醫生放回了駕駛員的座位上”［3］。

目前，國際上開展了很多基于openEHR規范的醫療信息系統的研究［4－5］，對openEHR兩層建模思想進行了驗證。在基于openEHR規范構建的醫療信息系統數據持久化層方面，國內外已研究出基于openEHR兩層模型方法建立的醫療數據存儲平臺。該平臺通過讀取由領域專家定義的openEHR領域模型來滿足相應的數據存儲需求，實現醫療數據存儲結構的高度可適應性和可擴展性。其中，開源的基于openEHR體系結構的Opereffa原型系統底層使用關系數據庫存儲醫療數據［6］，瑞典林雪平大學的SergioMirandaFreire等實現了使用XML數據庫存儲基于openEHR規范的醫療數據文檔［7］，日本會津大學的AasthaMadaan等實現了由原型驅動的基于NoSQL數據庫的醫療數據存儲平臺［8］。除此之外，浙江大學的王利等為了管理復雜和不斷發展的醫療信息，利用openEHR兩層模型和原型驅動方法的高度可適應性和可擴展性，設計并實現了一個由原型驅動的基于關系型數據庫的醫療數據存儲平臺，由原型映射到關系型數據庫表來實現靈活的數據存儲。在ARM的基礎上，該研究將AQL擴展為具有完整數據操作功能的數據操作語言，并在數據存儲平臺上進行了技術實現，從而使該數據存儲平臺通過一組網絡服務對外提供靈活的數據訪問［9］。基于openEHR兩層建模實現的醫療信息系統提高了系統的靈活性，適應了醫療信息的變化和更新，但面臨數據查詢量巨大、查詢條件復雜多變的個性化操作需求(報表、集成視圖等)時，基于openEHR兩層建模實現的醫療信息系統查詢性能較低。這主要與底層數據存儲模型有關，數據倉庫多維數據模型擁有高性能查詢的優點，通過改變基于openEHR兩層建模實現的醫療信息系統底層數據存儲結構，可以解決個性化操作需求中存在的性能問題。對于此類問題，目前采用數據驅動和應用驅動相結合的數據倉庫開發方法，即根據數據源和具體的需求來設計多維數據模型，再進行相應的ETL設計實現，建立數據倉庫［10］。由于基于openEHR規范兩層建模方法實現的醫療系統的特殊性，系統持久化層會伴隨領域知識的改變而發生變化，相應的數據倉庫多維數據模型以及ETL設計都需隨之發生改變;采用傳統的數據倉庫構建方法，在數據倉庫的開發與維護過程中，技術開發人員需要不斷地與用戶進行溝通交流來明確用戶的需求，費時費力且容易出錯，用戶的參與性較低，不能很好地適應領域知識的變化。針對這一問題，為了提高數據倉庫構建時用戶的參與性，加快數據倉庫的構建速度，更好地滿足用戶的個性化需求，本研究以國際標準openEHR為基礎，采用兩層建模的方法，提高用戶的可操控性，利用數據倉庫多維數據模型高性能查詢的優點，提出模板到動態數據倉庫多維數據模型的映射方法。與傳統的數據倉庫構建方法相比，該方法實現了數據倉庫多維數據模型的用戶配置，提高了建立數據倉庫時用戶的參與性;在多維數據模型與數據源之間建立了映射關系，根據自動生成的映射路徑可以快速地訪問數據源中的數據結構、數據類型等信息，加快了ETL工作的進行，降低了構建數據倉庫的周期。

1多維數據模型映射方法

openEHR原型通常是對臨床知識完整定義，而在實際的醫療環境中，往往不需要記錄如此完整詳盡的信息。openEHR模板是根據實際臨床需求，對若干原型合理組合并做進一步的語義約束，不會對原型施加任何新的語義。模板與原型的不同之處主要在于:原型通常需要在國家甚至國際層面上進行統一制定，以保證得到的原型具有通用性，可以被廣泛共享。而模板的制作通常是相對局部化、本地化的事情，每個軟件系統都可以根據自己的本地化需求，定義出一系列特定的模板。研究模板到動態數據倉庫數據存儲模型映射方法，更能切實地滿足醫療工作者的個性化需求［11－12］。基于openEHR原型關系映射方法構建醫療信息系統，在顯著提高數據持久化性能的同時，使醫療信息系統能夠適應醫療信息需求快速發展變化的形勢，促進醫療信息系統的應用［9］。目前，該構建方法被廣泛采用，本研究選取基于openEHR原型關系映射方法生成的關系型數據庫，作為構建數據倉庫的數據源。數據倉庫技術采用多維數據模型，多維數據模型把數據看作是多維空間中的點集，把集合的屬性分為維和度量兩類:維屬性用來描述度量屬性，是多維空間的維度;度量屬性的值用來進行分析處理，是多維空間中的點。根據事實表和維表的關系，又可將常見的模型分為星型模型和雪花模型。兩者在數據冗余度和查詢性能上有所區別:雪花模型冗余度低，查詢性能較低;星型模型雖然冗余度高，但查詢性能好。因此，在冗余可以接受的前提下，實際中運用星型模型更多，也更有效率［13－14］。采用基于openEHR的臨床醫療數據倉庫構建方法，其主要技術路線如圖1所示。模板真實反映了基于openEHR規范兩層建模方法實現的醫療信息系統底層數據存儲結構。該技術路線從模板出發，通過映射模塊在模板與多維數據模型之間建立關聯，在此基礎上進行基于模板的元數據處理和ETL過程，實現數據集市建立。映射模塊實現模板到動態數據倉庫多維數據模型的映射，具體實現方法為:映射模塊對傳入的模板進行解析，生成反應模板內部數據結構信息的樹形結構，根據原型關系映射規則對樹形結構中的可選項進行篩選。用戶通過對樹形結構中節點的挑選，組合成滿足需求的多維數據模型，并自動收集模板到多維數據模型的映射關系以及必要的元數據。ASP．NET是建立、部署以及執行Web應用程序的平臺，它為構建新一代動態網站和基于網絡的分布式應用提供了有力的支持。ASP．NET下MVC設計模式將程序分成相對獨立而又能協同工作的3個部分———模型、視圖、控制器，可以清楚地分離用戶界面與業務邏輯，能夠為系統開發提供基本的分析方法和清晰的設計框架［15］。本研究基于ASP．NET下MVC設計模式開發來實現。

1.1模板解析模板遵循TOM(templateobjectmodel)定義，原型由ADL(archetypedefinitionlanguage)定義。openEHR模板是根據實際需求對若干原型的合理組合，在模板解析中需要訪問模板引用的原型。openEHR參考模型和原型定義了大量的類和屬性，以及類之間的關系，尤其是參考模型，它不僅定義了openEHR的上層組織結構，而且對openEHR中各類信息的組織結構以及數據類型、數據結構等都進行了詳細定義。因此，直接訪問完整的參考模型和原型的實施將會是一項非常龐大的工程。目前，國際上已經出現了多個openEHR規范實施項目，其中比較有代表性的是瑞典Linkping大學RongChen等人組織開展的openEHRJAVA開源參考實施項目。該項目已經對RM和AM進行了比較完整的實現，因此，本研究RM和AM的實現直接基于此JAVA參考實施項目。根據實際需要，采用了openEHRJAVA的模塊adl-parser和模塊xml-serializer。模塊adl-parser實現了ADL文件到AOM、AP對象的解析，模塊xml-serializer實現了AOM、AP對象到XML文件的序列化。通過以上兩個模塊，可以將ADL文件轉化為既方便計算機處理又具有一定可讀性的XML數據文件。JAVA類文件并不能直接在ASP．NET下運行，IKVM．NET是開源的基于．NETCLR的JAVA虛擬機，該項目雖然在安全性上有待改進，但實現了JAVA程序在．NET下的運行。本研究通過引用以上兩個模塊和IKVM．NET，將ADL文件轉化為方便計算機處理并且具有一定可讀性的XML數據文件。JSON作為一種輕量級的數據傳輸格式，可以在多種語言之間進行數據交換。JSON易于閱讀和編碼，并且是JavaScript規范的子集，能夠被支持JavaScript的瀏覽器所解析;相比XML，它減少了解析時帶來的性能和兼容性問題，使其成為了理想的數據交換語言［16］。因此，本研究將JSON作為數據交換語言。在實現中，主要是XML文件到JSON對象的轉換，這一過程借助XML2JSON插件完成。

模板解析技術的實現路線如圖2所示。將模板轉化為JSON對象后，傳入后臺解析模塊，后臺解析模塊依次調用需要的原型，原型經過一系列的轉化后轉變為JSON對象，返回后臺解析模塊，后臺解析模塊解析模板，并生成一個真實反映模板內部結構的JSON對象，傳入前臺解析模塊，前臺解析模塊遍歷該JSON對象，生成模板對應的樹形結構。在本研究中，將基于openEHR原型關系映射方法生成的關系型數據庫作為構建數據倉庫的數據源。為了真實地反映數據源中的數據結構信息，根據原型關系映射規則，對樹形結構中的可選項進行了篩選，原型關系映射規則［9］如下:1)每個原型映射為一個關系數據庫表，數據庫表名為原型名。2)每個基本類型的原型屬性映射為一個關系數據庫表字段，字段名為屬性名，字段類型為屬性數據類型，字段長度為屬性數據長度。3)每個集合類型的原型屬性映射為一個單獨的數據庫表，數據庫表名為“原型名_集合類型屬性名”，包括主鍵字段，字段名為“原型名_集合類型屬性名”;關聯到原型對應的數據庫表的外鍵字段，字段名為原型名，字段類型與原型對應的數據庫表的主鍵字段類型相同;集合類型屬性對應的字段，字段名為集合類型屬性名，字段類型為集合類型屬性數據類型，字段長度為集合類型屬性數據長度。4)每一個archetypeslot類型的原型屬性映射為一個單獨的數據庫表，數據庫表名為“原型名_archetypeslot屬性名”，包括主鍵字段，字段名為“原型名_集合類型屬性名”;關聯到原型對應的數據庫表的外鍵字段，字段名為原型名，字段類型與原型對應的數據庫表主鍵字段類型相同;archetypeslot類型屬性對應的字段，字段名為“archetypeslot類型屬性名”，并關聯到目標原型對應的數據庫表。根據以上規則，樹形結構中能夠映射到關系型數據庫表字段名的節點為可選項，其他節點為不可選項。樹形結構各節點name按照是否可選進行了不同的命名方式。不可選項name為對應模板層次結構中節點的屬性名，可選項name由對應模板層次結構中節點的屬性名、屬性數據類型、該屬性節點在模板中的完整路徑三者拼接而成，以方便信息的傳遞。

1.2可操控配置個性化需求復雜多變，而模板包含了滿足實際應用的信息，用戶通過對解析模板生成的樹形結構中有價值節點的選擇，組合成滿足個性化需求的事實表和維表，構建數據集市的多維數據模型。具體實現方法如下:根據數據倉庫多維數據模型的相關定義，允許用戶在建立數據集市時創建一張事實表和多張維表。在創建表的過程中，表名由用戶手動輸入，并進行唯一性檢驗，避免表名重復。用戶通過對樹形結構中有價值節點的選擇，將該選中項的name信息傳送到對應表，生成對應表的行信息，用戶可以指定已創建表中的某一行為主鍵或某些行組合成復合主鍵，并可以對已創建的事實表和維表進行主/外鍵關聯操作，組合成多維數據模型。數據集市是聚焦的、面向特定主題的，它通常致力于單一的某個領域，且為特定用戶服務。為了方便對數據集市的使用與管理，在用戶建立多維數據模型時，需用戶輸入數據集市的唯一性命名以及面向對象等元數據信息。

1.3數據庫生成該模塊的主要功能是根據用戶已經建立好的多維數據模型，生成數據庫，并收集部分元數據信息。用戶輸入命名的事實表名和維表名通常不符合實際數據庫表名的命名規則，需經過解析轉化符合命名標準的表名。解析用戶配置生成的事實表和維表的各個行信息，得到該行的屬性名、屬性數據類型、屬性節點的完整路徑。解析后的屬性名和屬性數據類型主要為生成數據庫表字段服務，而屬性節點的完整路徑提供AQL查詢，可以查詢到生成表字段的對應節點在原型中的信息，并可與通過原型關系映射生成的關系數據庫中的表字段關聯起來，方便數據的集成處理。解析后的屬性名并不能直接作為生成數據庫表的字段名，需經過解析和唯一性處理生成對應表的字段名，字段類型為對應屬性數據類型。然后，收集主/外鍵關聯信息，生成對應的創建關系型數據庫表的SQL語句，在數據庫中創建事實表和維表，并記錄下生成的數據集市名、數據集市面向對象、表名、表字段、表字段對應的屬性節點的完整路徑等元數據信息，便于對數據集市的管理。

2結果

為了驗證該方法是否可行，筆者針對查詢檢驗信息的相關報表中存在的性能問題，根據模板到動態數據倉庫多維數據模型映射方法，構建了滿足需求的多維數據模型，通過專業的ETL工具SSIS，對數據進行了集成處理，建立數據集市，希望通過改變底層數據存儲結構，提升查詢性能，實現數據倉庫的快速構建。選取了與檢驗信息相關的模板中有價值的節點，配置基于openEHR模板的多維數據模型，生成的數據庫表結構如圖3所示。該模型為包含一張事實表和三張維表的星型模型，涵蓋了滿足個性化需求的所需數據。其中，事實表FactLaboratoryTest存放了檢驗結果的相關數據，復合主鍵為TestReport_ID、ItemOrder。維表DimPatient存放了病人基本信息的相關數據，主鍵為PatientIdentifier_Identifier;維表DimAdmin_PatientAdmission存放了病人就診的相關數據，主鍵為EncounterIdentifier;維表DimInst_LaboratoryTestRequest存放了檢驗申請的相關數據，主鍵為RequestorIdentifier。3個維表通過主鍵與事實表FactLaboratoryTest建立關聯。在ETL過程中，基于openEHR原型關系映射生成的關系型數據庫為數據源，利用構建多維數據模型時收集的表字段的完整路徑與基于openEHR原型關系映射生成的關系型數據庫中的表字段進行關聯，快速地查找到其在數據源中對應數據的數據結構、數據類型等相關信息，在此基礎上進行數據的集成處理。數據抽取頻率設定為每天一次，抽取策略采用全量抽取，在ETL引擎中完成數據轉換，然后對數據進行裝載。

為了檢驗查詢性能是否得到了提升，在基于模板到動態數據倉庫多維數據模型映射方法建立的數據集市和基于傳統方法建立的數據集市、基于原型關系映射生成的關系型數據庫間進行查詢性能對比，挑選了三者中的部分數據作為測試數據集，數據包括57465位病人基本信息、1210798條檢驗申請記錄、840746條檢驗報告記錄、10861522條檢驗結果記錄。分別在三者中對某病人的相關信息、26條檢驗申請記錄、24條檢驗報告記錄、329條檢驗結果記錄進行了查詢。測試電腦配置CPU為Intel(R)Core(TM)2DuoCPU，內存為4GB，操作系統為Windows7.1Enterprise32位，數據庫為SQLServer2012Enterprise32位。在三者中，分別進行了3次查詢，所花費的時間以及各自平均查詢時間的結果如表1所示。查詢結果表明，在基于模板到動態數據倉庫多維數據模型映射方法建立的數據集市中，對某病人的檢驗相關信息進行3次查詢所花費的時間均值為274ms。在基于傳統方法建立的數據集市中，花費的時間均值為265ms;在基于openEHR原型關系映射生成的關系型數據庫中，花費的時間均值為1520ms。在查詢性能上，基于模板到動態數據倉庫多維數據模型映射方法是基于傳統方法建立的數據集市的0.97倍，基本持平。與基于openEHR原型關系映射生成的關系型數據庫相比，基于模板到動態數據倉庫多維數據模型映射方法構建的數據集市在性能上提升了約5.6倍。總體表明，根據模板到動態數據倉庫多維數據模型映射方法，可以配置滿足個性化需求的多維數據模型，利用多維數據模型與數據源中數據建立的映射關系，方便了ETL過程的進行，實現了數據集市的快速建立。查詢時間對比表明，該方法切實可行，大幅提升了個性化需求的查詢性能。

3討論

在本研究中，基于openEHR規范，提出了模板到動態數據倉庫多維數據模型的映射方法。與傳統的數據倉庫構建方法相比，該方法充分利用了openEHR兩層建模思想的模板領域知識驅動、易擴展、反映本地化需求等優點，使用戶在無需了解數據源底層數據存儲結構的基礎上，實現了數據倉庫多維數據模型的用戶可配置，提高了在數據倉庫構建過程中用戶的參與性，避免了數據倉庫開發前期的需求分析工作，滿足了用戶的個性化需求。在數據倉庫多維數據模型的構建過程中，自動收集了數據源與多維數據模型間的映射關系，利用映射路徑，方便ETL過程的處理，提高了數據倉庫的構建效率。用戶參與數據倉庫中多維數據模型的設計有利也有弊。用戶臨床醫療知識和計算機操作水平的差異，會影響到多維數據模型的質量，并直接關系到數據集市的服務水平。在這一點上，本研究提出的模板到動態數據倉庫多維數據模型的映射方法做了妥協。用戶需要在技術人員的指導下進行模型的設計，借助專業的ETL工具實現數據集成。提高用戶在臨床醫療數據倉庫系統開發過程中的參與性，讓用戶成為數據倉庫構建的主角，是縮短系統開發周期、滿足用戶個性化需求的重要手段。但是，讓用戶獨立配置數據倉庫還是具有一定的風險，所以領域專家的指導和培訓非常重要。通過培訓，讓用戶了解臨床醫療數據倉庫的相關知識，以及將醫療數據倉庫的領域概念與醫療領域知識相結合，對于數據倉庫配置過程中以用戶為主體具有一定的可操作性。

4結論

在本研究中，針對基于openEHR兩層建模思想實現的醫療信息系統在個性化操作需求時存在的性能問題，提出了模板到動態數據倉庫多維數據模型的映射方法。對該方法進行了驗證，表明通過該方法能夠建立滿足需求的多維數據模型，實現多維數據模型的用戶可配置。通過對數據的集成，在查詢性能上進行了驗證，表明基于該方法建立的數據集市與基于原型關系映射方法生成的數據庫相比，能夠大幅地提升查詢性能，與基于傳統方法構建的數據集市在查詢性能上基本持平。該方法充分利用了openEHR規范領域知識驅動的優點，為醫療行業提供一種可操控、可擴展、能真實反映用戶需求的數據倉庫構建方法。

作者：王冬冬 葉楓 呂旭東 閔令通 王利 單位：浙江工業大學經貿管理學院 浙江大學生物醫學工程與儀器科學學院