企業主患者索引（EnterpriseMaster Patient Index，簡稱EMPI）或主患者索引（MasterPatientIndex，簡稱MPI）已經成為醫院信息系統及大數據系統平臺中不可缺的基礎技術和模塊，也是醫療企業集成化（Integratingthe Healthcare Enterprise，簡稱IHE）和醫療信息交換（HealthcareInformationExchange，簡稱HIE）平臺的基礎支撐技術和模塊。

EMPI和MPI同義，因為MPI只有在整個企業或醫療機構范圍內使用時才有意義和價值。企業主病患索引是維護醫療機構中的一致準確患者信息的數據庫。準確的患者信息被各醫療信息系統參考和訪問，企業主病患索引給每個患者分配一個唯一的標識符，因此患者記錄在醫療機構的所有系統中只代表一次。患者數據可以包括姓名、性別、出生日期、身份標識號、當前地址、聯系電話等信息。

每個患者在企業主病患索引數據庫中只存儲唯一條最真實最可靠最全面的患者信息記錄，稱為單一最佳記錄（SingleBest Record,簡稱SBR），單一最佳記錄也稱金質記錄（GoldenRecord）。企業主病患索引目的是構建單一真實主患者信息源(ASingle Patient Source of Truth, 泛稱ASingle Source of Truth,簡稱SSOT)。SSOT將企業內多個系統的主患者數據聚合到一起，綜合產生單一最佳記錄（SBR），SSOT是一個企業范圍內主患者數據的整體狀態。企業主病患索引確保患者數據在醫療機構中的正確和一致。

企業主患者索引（EMPI）是通用主數據管理（MasterData Management，簡稱MDM）在主患者數據的特定場景的應用。所以，更精確地說企業主患者索引技術是主數據管理技術。通用主數據管理MDM產品通過客戶化配置可以構建企業主患者索引EMPI應用，但一些專用的企業主患者索引產品不能用于通用主數據管理，主要是因為患者主數據和通用主數據在數據結構和特性的差異。

企業主患者索引之所以重要和需求是因為在企業或醫療機構范圍內各個信息系統表述患者數據不一致，也缺乏全局唯一的標識符（GlobalPatient Identifier 或NationalPatientIdentifier），即使單一系統由于歷史原因和患者注冊過程中的錯誤導致同一患者存有多份重復記錄，患者并非總是能提供準確的個人信息如患者標識符、患者的地址等。隨著系統生成更多的數據，問題會變得更加嚴重，從而導致不同數據源、不同供應商系統、不同機構的健康信息交換和互操作性出現重大障礙。不精確的患者數據和重復的患者數據會可能會給患者帶來潛在風險，并損害護理和治療的質量。準確的患者數據對于醫療機構提供患者最佳的護理和治療至關重要。

我們以理論、產品及實踐的視角概述企業主患者索引的起源、算法、市場及創新的各方面，希望能夠給讀者關于企業主患者索引有個較全面的認識。

與企業主患者索引核心技術相關的是患者記錄匹配（PatientMatching，簡稱PM)，泛稱記錄匹配（Record/DataMatching，簡稱RM）。與記錄匹配相關的技術包括重復記錄刪除（Record/DataDeduplication，簡稱RD），記錄鏈接(RecordLinkage，簡稱RL)及實體和身份解析(Entityand Identity Resolution，簡稱IR)。重復記錄刪除（RecordDeduplication）是一種用于消除重復記錄副本的技術，用于提高數據存儲效率；記錄鏈接（RecordLinkage）是從不同數據源中查找表達同一實體的數據記錄的技術。當同一實體在不同數據源中沒有共享公共標識符或著共享公共標識符不可靠的應用環境下，記錄鏈接是必要的；實體和身份解析(Entityand IdentityResolution)是在不同的數據集和數據庫中進行搜索和分析，以找到所有匹配的即表達同一實體和身份的記錄。實體和身份解析使企業能夠基于其可用的數據記錄和屬性來分析特定實體和身份相關的數據。RD、RL和IR的應用側重不同，核心都是基于數據匹配或泛稱記錄鏈接（RecordLinkage）。

最早關于記錄鏈接（RL）的研究是哈爾伯特L.鄧恩（HalbertL.Dunn）于1946年發表在《美國公共衛生雜志》（AmericanJournal of Public Health）上題為《記錄關聯》【1】（RecordLinkage）的論文中。霍華德·波登·紐科姆（HowardBorden Newcombe）于1959年發表在《科學》（Science）上的《自動鏈接重要健康記錄》【2】(AutomaticLinkage of Vital Records)的論文奠定了現代記錄鏈接理論的概率基礎。然后，在1969年IvanFellegi和AlanSunter正式提出并證明了當屬性條件比較獨立時，概率決策規則最優。他們的開創和歷史性著作《記錄鏈接理論》【3】（ATheory for RecordLinkage）至今仍然是記錄鏈接應用的數學基礎。幾乎所有MDM和EMPI產品廠商都采用了Fellegi-Sunter（FS）概率算法模型實現概率記錄匹配如Oracle、IBM、Informatics等等，只是各廠商模型的軟件架構和實現的優化和效率程度不同，其中IBM和Oracle（SunMicrosystems）比較優化，匹配的精確度和效率比較高。如IBM和Oracle的企業主患者索引在數億條主患者記錄的場景下，匹配精確度大與95%以上，實時匹配速度在微秒級。

約翰R.塔爾伯特（JohnR. Talburt）于2010發表了《實體分辨率與信息質量》【?】（EntityResolution and InformationQuality）一書，約翰R.塔爾伯特引入了記錄鏈接的抽象和集合表達，是近年來關于記錄鏈接的比較全面的理論和方法的闡述。

記錄鏈接可以在沒有計算機幫助的情況下完成，但在大量數據的場景中如數百萬、數千萬、幾億萬條記錄，人工審核（ManualReview）成為不可能。計算機記錄鏈接的自動方法減少或消除了人工審核，匹配結果更具一致性、速度和和效率更高。計算機記錄鏈接的自動方法并不能終是解決所有場景的100%的問題，只要確保匹配結果沒有假陰性（FalseNegative），少量的假陽性（FalsePositive）或不確定性，如在大量數據集合，中自動方法解決95-99%以上問題，余下的1-5%問題人工審核，就會大量地減低運營成本、提高效率。這也是企業主患者索引軟件產品的設計原則之一。

在工業界，九十年代末較早研發企業主患者索引軟件產品的是SeeBeyondTechnology和IBM。IBM的產品稱IBMInitiate后更名為InfoSphere。SeeBeyond的產品稱eIndex，SeeBeyond于2005被SunMicrosystems收購，后更名為SUNMDM，Oracle又更其名為OHMPI。在企業主患者索引創新的初期到高峰期，SunMicrosystems和IBM一直是技術和市場的領導者，SunMicrosystems也是較早開放企業主患者索引程序代碼的廠商之一，其開源的MuralMDM 主數據管理產品代碼托管在java.net上（甲骨文已經終止了java.net，而改用Apache）。

如今，有大量至少30家以上主要的企業主患者索引產品廠商，企業主患者索引已經廣泛用于醫療信息系統中，產品和技術基本成熟。用戶可以根據不同的需要和場景及項目預算，選擇合適的產品。

各個廠商企業主患者索引（EMPI）產品組成的模塊不同，但主要的企業主患者索引產品基本包括：

• 設計模塊：用于設計和生成特定的企業主患者索引應用程序，根據不同用戶和場景客戶化和配置不同的解決方案。

  
  

• 運行模塊：運行設計模塊生成的企業主患者索引應用程序，執行企業主患者索引各種功能模塊。

  
  

參考如下設計模塊和運行模塊列子：

圖一.甲骨文企業主患者索引OHMPI的設計和運行模塊（參考甲骨文企業主患者索引資料）

企業主患者索引功能模塊主要包括：數據庫模式模塊（DatabaseSchema）、數據標準化/歸一化引擎（Standardization/NormalizationEngine）或稱數據質量引擎（DataQuality Engine）、塊搜索引擎（BlockingQuery Service）、匹配引擎（MatchEngine）、配置引擎（ConfigurationService），單一最佳記錄生成策略服務（SurvivorStrategy Service）、安全服務（SecurityService）、數據驗證服務（ValidationService）、應用程序接口API、事件通知(EventNotification) , 初始批量匹配和加載(InitialBulk Match and Load)及數據管理（DataStewardship）。用戶可以根據這些功能評估和選擇適合的自己應用場景的企業主患者索引產品。

圖二.企業主患者索引功能模塊

企業主患者索引（EMPI）核心算法是記錄匹配，記錄匹配方法主要包括確定性匹配（DeterministicMatching）和概率匹配（ProbabilisticMatching）。概率匹配可以有效解決大部分應用場景，適合確定性匹配的應用場景并不多見。企業主患者索引軟件廠商一般提供這兩種方法以適應不同的應用場景。模糊匹配（FuzzyMatching）也是學術界研究的方法，但未見工業界廣泛接受。

確定性匹配（DeterministicMatching）

確定性匹配使用一系列規則，如嵌套式if語句，對數據集執行一系列邏輯測試。這就是我們如何確定數據集中的相互關系（relationships）、層次結構（hierarchies）和從屬控制（householding）。確定性匹配給出明確的是或否結果。在確定性匹配中，要么比較每條記錄的唯一標識符以確定匹配，要么精確比較每條記錄字段。唯一標識符可以是通用的患者標識符等。確定性匹配通常不完全可靠，因為在某些情況下，沒有一個字段可以在兩個記錄之間提供可靠的匹配。這就引入了概率匹配或模糊匹配。

確定性匹配實列：

如果兩條記錄患者姓相同賦權值8，反之賦權值-8；如果兩條記錄患者名相同賦權值10，反之賦權值-10。這樣，如果兩條記錄患者姓和名相同賦權值18，姓名相同；反之賦權值小于18，姓名不相同.這是確定性匹配實現方式之一，各廠商提供不同的確定性匹配規則語言。

概率匹配（ProbabilisticMatching）

概率匹配計算兩個記錄相同的統計可能性。通過對兩個記錄的“匹配度”進行評級，概率方法能夠發現數據之間不明顯的相關性。概率匹配評估“可能”的可信度。在概率匹配中，比較兩個記錄之間的多個字段值，計算兩個記錄之間的兩個字段值的匹配程度的權重。各個字段的權重之和是匹配值（MatchScore），表示兩條記錄之間匹配的可能性。概率匹配設置重復閾值（DuplicateThreshold，也稱低閾值LowThreshold）和匹配閾值（MatchThreshold，也稱高閾值HighThreshold）。重復閾值是兩條記錄可能代表同一實體的權重。匹配閾值是兩條記錄被認為代表同一實體的權重，低于重復閾值的任何記錄都被視為代表完全獨立和不同的實體。在圖三.FS概率匹配模型中，如兩條記錄的匹配值大于匹配閾值，兩條記錄為同一患者記錄；如兩條記錄的匹配值小于重復閾值，兩條記錄為不同患者記錄；如兩條記錄的匹配值介于重復閾值和匹配閾值之間，不確定，需要人工審核。同過調正參數，減小重復閾值和匹配閾值之間的區間以減低人工審核。

圖三.FS概率匹配模型（參考甲骨文企業主患者索引資料）

Fellegi和Sunter【3】建立了用于記錄匹配的正式數學框架，是一種最廣泛接受的概率匹配方法，如今已稱為標準FS模型。FS模型對涉及匹配的每個字段計算它們的條件概率，然后，匯總所有各個字段在統計上相互獨立條件下的概率近似值。

一些研究顯示在實踐中經常違反FS算法的條件獨立性的假設，已公開的基于條件概率的顯式建模的努力并未導致匹配精度的提高。如果有足夠的帶標識的訓練數據可用，則有助于提高算法的精度。

設置重復閾值和匹配閾值

概率匹配的最大痛點是權重、重復閾值和匹配閾值的確定。有不同的技術可以確定匹配和重復閾值的初始設置。常用的實踐方法有：權重分配方法（WeightDistribution Method）和百分比方法（PercentageMethod）。權重分配方法基于通過分析所有記錄比較的加權對（WeightedRecord Pairs）的分布頻譜來計算錯誤匹配（FalseMatches）和錯誤不匹配（FalseNon-Matches）的錯誤率。權重分配方法更有效，但需要分析大量數據才能在統計上可靠。在學習記錄有限的情況下，此方法不太適用。百分比方法依賴于測量所有匹配字段的總的最大權重和最小權重，然后將這些值的一定百分比指定為初始閾值。百分比法簡單，但缺少統計學的基礎。

設置正確的閾值是一個反復的迭代過程。首先，使用前面描述方法設置初始閾值，然后分析所得的所有記錄匹配的結果，調整閾值提高精度。重復加載和分析數據以及調整閾值，直到對結果滿意為止。比較將有力的企業主患者索引廠商如Oracle和IBM都提供設置閾值的工具以幫助用戶根據自己的數據有效確定閾值。比如BMInitiate提供MatchedPairs Reviewer 工具，OracleOHMPI 有IBML工具。

EM算法【?】是比較有參考價值的統計學方法通過學習數據自動給出權重和閾值，但大部分廠商都不提供這工具。

比較函數（ComparisonFunctions）

用于匹配字段的比較函數（或比較器Comparator）比較兩條記錄中字段的值，以確定字段是否匹配或匹配的程度。然后，根據比較函數的結果為字段分配匹配權重（MatchWeight）。根據字段的特性，可先擇不同類型的比較函數，進一步調整比較函數的參數。

基本的比較函數包括:

• Bigram Comparators

• Jaro String Comparators

• Unicode String Comparators

• Numeric Comparators

• Date Comparators

• Prorated Comparators

• ……

  
  

我們還引入了中文字符的比較函數：

• Chinese String Comparator

• Chinese String Prefix Comparator

• Chinese Integer Comparator

• ……

  
  

很多企業主患者索引軟件廠商還容許創建自定義比較函數，嵌入到系統中。這些企業主患者索引產品遵循可插入式的開放體系架構(PluggableOpen Architecture).

塊查詢(BlockingQuery or Bucketing)

從大量的企業主患者索引數據庫中迅速檢索到可能匹配的記錄子集的過程塊查詢技術,匹配引擎進一步計算可能匹配的記錄子集。如果企業范圍內各系統內每個患者都強制使用了全局性的唯一標識符，檢索簡單而快速；但如果企業范圍內各系統內每個患者沒有全局性的唯一標識符或者唯一標識符不可靠，查詢技術將對匹配速度起到決定性的作用。

各廠商迅速檢索的方法不同，但基本有以Oracle為主的塊查詢（BlockingQuery）技術和IBM為主的桶裝技術（Bucketing）。

語音編碼（PhoneticCoding）

語音編碼或稱音素化技術（Phonetization）是將同一種語言中拼寫不同但具有相同的發音字或詞組編成統一碼。語音編碼的重要應用是模糊數據檢索,用于從大量數據集合中快速檢索出具有相似字段值的記錄以進行精確匹配。基本的語音編碼包括:

• Soundex

• Refined Soundex

• Metaphone

• Double Metaphone

• NYSIIS

• ……

  
  

我們引入了中文語音編碼包括:

• HanYuPinYin

• HanYuPinYinNoTone

• ……

單一最佳記錄（SBR）規則（SurvivorStrategy）

單一最佳記錄（SBR）規則用于生成并更新單一最佳記錄SBR。企業患者的單一最佳記錄（SBR）是根據每個源系統記錄中包含患者的最可靠信息創建的。每個源系統用于填充SBR的信息由單一最佳記錄（SBR）規則確定,有各種不同的規則，單一最佳記錄（SBR）規則高度可配置。單一最佳記錄（SBR）可以動態產生，如IBMInitiate的主數據庫中并不存儲單一最佳記錄，在用戶查詢時根據規則自動產生；而OracleOHMPI 主數據庫中存儲單一最佳記錄。兩種方法各有利弊。動態產生單一最佳記錄適合更多的應用場景，但損失檢索效率。

記錄鏈接的方法（RecordLinkage Method）

記錄匹配的目的是通過計算兩條或更多記錄的像似性以確定是否表達同一實體（Entity）。在企業主患者索引場景中，實體就是患者。這些像似性的記錄鏈接在一起，理論上有四種記錄鏈接方法，并不是所有的產品很好地實現了這些方法。四種記錄鏈接方法是：直接匹配（DirectMatching）、傳遞連接（TransitiveLinking）、關聯鏈接（Linkingby Association）和認知基礎鏈接（Knowledge-Based/AssertedLinking）。關于詳細的記錄鏈接方法可閱讀參考文獻【?】。

其它算法

其它算法包括數據清洗、數據標準化、和數據歸一化，這些算法和規則是企業主患者索引不可缺的，以確保患者記錄匹配的準確性和高效率。

企業主患者索引（EMPI）根據應用場景，可以歸納分為如下主要三類實施方式（ImplementationStyles）。

• 注冊方式（Registry Style）

注冊方式對來自各種源系統的數據運行清洗和匹配運算、尋找表達同一的患者數據記錄，為匹配的患者數據記錄分配唯一的全局標識符（也稱EnterpriseUnique Identifier,簡稱EUID），以構建單一真實主患者信息源（SSOT）。單一最佳記錄（SBR）可以靜態或動態產生。靜態產生的單一最佳記錄存儲在企業主患者索引數據庫中。源數據不存儲在企業主患者索引數據庫中，主數據的改變不發送回源系統，源系統負責管理和源數據。注冊方式更接近檢索方式（Indexing），只有用于匹配和產生全局標識符的患者數據保存在數據庫中，數據的安全性和脫敏易于實現和管理。

當應用場景有大量數據源，注冊方式提供了低成本和快速的數據集成。當源數據改變時，企業主患者索引系統面對維護一致性的困難。

• 交易方式（Transaction Style）
  

交易方式也稱中心化方式（CentralizedStyle）存儲和維護主數據，通過各數據源的數據清洗、匹配和豐富算法構建單一最佳記錄（SBR）。源系統的數據可以存儲和維護在企業主患者索引數據中，源系統可以訂閱由企業主患者索引主系統發布的更新消息，以確保源系統與主系統數據的一致性。交易方式需要侵入源系統以進行雙向交互。

交易方式主數據始終確保數據的準確且完整，交易方式是主數據中心（MasterData Hub），構建成本高于注冊方式。

業界也有定義合并方式（ConsolidatedStyle），合并方式和交易方式從實踐上可歸為一類。

• 共存方式（Coexistence Style）
  

共存方式在解決方案中同時運用注冊方式和交易方式。共存方式對架構和實施及維護有更高的要求。

企業主患者索引產品支持其中的一種實施方式或這些三種實施方式。

未完待續