近日，國家衛生健康委統計信息中心發布了兩則通知——

2021年10月25日，國家衛生健康委統計信息中心發布《關于開展國家醫療健康信息互聯互通標準化成熟度評測工作的通知》，這意味著新一年的評測工作開始啟動。

2021年11月5日，國家衛生健康委統計信息中心發布了“關于2020年度國家醫療健康信息互聯互通標準化成熟度測評結果（第二批）公示的通知”，公布了第二批10個區域和92家醫院的測評結果。

這兩則通知，再次將“互聯互通”帶到了醫療IT人的面前。而每每談到互聯互通，就不可避免地要談到集成平臺、信息平臺和數據中臺等項目建設問題，本文將從供應商選擇、技術選型等從八個核心問題，淺談關于平臺和中臺的那些事。

如上圖所示，如果我們把平臺/中臺項目的實施方稱作解決方案提供商，那么每一家解決方案提供方背后還會有一家產品技術提供方解決方案，因為解決方案提供方往往需要借助成熟的產品來實現信息平臺和數據中臺項目，以聚焦所服務醫院客戶的具體需求，并加速實施效率，所以一個平臺/中臺供應鏈條相對比較長。也因此，醫院/醫療集團需要花費更多的精力在產品和解決方案的組合中進行選型。選型的標準也成為許多信息中心或者CIO們關注的首要問題。

首先要考慮平臺/中臺解決方案提供方本身的品牌和實力：通常而言，選擇全國性的解決方案提供方更安全一些，這類廠商的解決方案相對成熟、成功案例多，技術能力強，實施經驗豐富；但是對于一些規模略小的醫院而言，可能會顧慮這些廠商的客戶太多，對本院的支持力度不夠，或者是在該廠商在當地沒有分公司，存在技術服務跟不上等問題，也可能會更傾向于初創企業或者本地解決方案提供方來做項目的集成或者實施，這兩種選擇都沒有問題，關鍵是所選擇的合作伙伴要值得信賴。

另外要考慮廠商背后的產品技術提供方：通常產品技術提供方不直接面向最終客戶提供實施服務，而是通過本地合作伙伴向最終客戶（即醫院或者醫療集團）提供服務。但是作為解決方案的基礎，該產品或者技術本身的先進性、可靠性以及未來的可擴展性都是需要重點衡量的因素。例如醫院建設集成平臺或者互聯互通平臺通常都會本著以評促建以評促用的目的，利用信息平臺的建設契機，打通院內的信息和數據流程。此時，產品技術提供方有多少業務建模和流程整合的案例與經驗也將在很大程度上影響項目的交付質量。

同樣，醫院也可以參考該產品技術提供方的行業積累、案例詳情、服務承諾以及業界口碑等等。

總結一下，在選擇方案時，需要考慮的實際上是產品本身的技術能力和對應的解決方案提供方的服務能力。因此，我們建議大家基于成熟的產品，選擇能提供較好技術服務的解決方案提供方。如果產品并不成熟，那么即使解決方案提供方愿意常年提供駐場技術服務，也很難應對故障，也難以制訂預案保障平臺穩定運行。

在醫療行業進行業務和數據整合時，用戶常常會需要在點對點集成模式、消息路由模式以及SOA架構模式進行技術決策。

事實上，從來就未曾出現過集成模式的最終解決方案。醫院和醫療集團用某種特定的集成模式搭建自己的數字化高速公路時需要充分考慮該模式是否適合自己的場景，投入產出比是否符合自己的預期，以及是否能夠充分利用該模式的優勢。

舉例而言，當醫院考慮采用SOA架構時，需要考慮到遺留系統是否能夠提供服務接口；在當前的業務運行條件下，是否能夠承受由于接口的侵入式設計引入的風險，是否可能通過預案規避風險；以及醫院是否已經或者將在平臺投產前后具有實時數據分析的需求和技術儲備。否則就將面臨投入無法得到回報的質疑，甚至是規劃無法落地的尷尬。

再看一個例子，如果要采用點對點模式集成，那么醫院就需要考慮在平臺投產可預見的周期（如3～5年）內，是否會面臨跨部門跨系統數據利用需求快速增長的前景。如果有，那么，由于缺乏SOA架構能夠提供的業務抽象和整合的能力，爆炸性增長的接口數量和數據整合需求會成為信息科難以應對的直接威脅。

正是由于集成模式的高度個性化，我們認為作為基礎設施的集成平臺類產品必須能夠支持所有集成模式。一方面是滿足各種不同類型的醫院的需要，另一方面，醫院也需要認識到，基礎設施的建設從來都不是一蹴而就的“一錘子買賣”。您完全可以在集成需求數量較低時選用點對點模式快速投產，在需要進行流程和數據整合時應用SOA架構以獲得企業全景視圖的整合優勢。而一個能夠支持所有模式的產品才能賦能于客戶，使之具備進行策略選擇的優勢。

采用開源組件迅速獲得能力，結合DevOps快速迭代開發是應對快速變化的市場環境和需求，進行產品化開發時的優先選擇。在進行應用開發時，這樣的策略通常有效。

然而優勢與代價總是如影隨形。借助開源組件的優勢是能夠快速獲得能力，但開源組件的穩定性、可靠性和安全性則是每一個技術決策者都需要考察的關鍵風險，甚至開源組件許可證的更新都有可能為企業引入巨大的知識產權風險。

例如久負盛名的ElasticSearch，作為一款企業級搜索和分析引擎，它對于文本檢索的能力和效率都有保障，被許多產品集成用于檢索。但ElasticSearch及其依賴的其他組件已被檢測出大量的安全性漏洞，例如可以引入中間人攻擊的CVE-2021-22138，可以允許用戶查看未授權敏感信息的CVE-2021-22147，以及可以允許用戶通過ElasticSearch在服務器上運行任何OS指令的CVE-2014-3120等，風險列表每年都在更新（參見：https://www.elastic.co/community/security）。同樣是ElasticSearch，在將開源授權更新為SSPL之后，如果業務用到了ElasticSearch并打包為可盈利產品，則ElasticSearch公司有權要求用戶開放源碼并收取費用。

因此，在使用大規模集成開源組件構建的產品時，醫院需要評估產品技術提供方是否能夠及時更新開源組件以獲得安全性更新，并評估產品技術提供方是否能夠及時跟蹤和處理因授權變化會引入的法律風險。

集成平臺、數據中臺甚至是數據庫這樣的基礎設施如果構建在大量的開源組件上，頻繁的版本變動通常意味著組件集成風險的大幅升高，而跟蹤和處理版本變更的技術和法務影響也將成為需要持續投入的持有成本。因此，一體化、完整知識產權的集成平臺或數據中臺產品在簡化技術堆棧的同時也將大幅降低長期持有成本。對于醫院用戶來說，需要平衡評估一體化商業產品和開源集成產品的購買和持有成本，更需要考察產品技術提供方對開源組件的跟蹤、更新和維護能力。

核心業務系統、集成平臺和數據中臺這一類的關鍵系統，事關醫院業務是否能持續運行，其運行穩定性與可靠性的重要意義不言而喻。基于主備、多活等冗余技術的平臺高可用和災備方案仍是為平臺運行保駕護航的關鍵手段。

在市場上可見到的諸多產品中，有采用原生高可用方案的產品，也有集成第三方或開源技術高可用方案的產品。在這里，各位信息中心負責人或者技術決策者不得不考慮一個問題，即高可用方案的責任歸屬問題。

因此，即使一些非核心部件采用第三方技術，高可用方案也應采用產品原生技術。即使退一步來說，在沒有原生高可用方案的情況下，您的解決方案提供方也應當承擔起解決平臺可用性和可靠性問題的技術服務角色。試想，當高可用方案失效或處于故障狀態時，解決方案提供方采用了非原生高可用方案，屆時難道能依賴開源社區的隨機問答解決問題？

醫療數字化進程與人工智能等目前的熱點技術有很大不同，即必須基于當前業務。但由于醫療業務本身面臨與新技術的融合，因此數字化進程也必須具備足夠的靈活性，能夠迅速應對業務過程的演化。而醫療業務流程或數據流程的演化，是需要業務專家、開發工程師、運維保障團隊協作共同完成的，每一種角色都需要在平臺上工作。因此，純粹面向開發工程師的技術平臺將無法有效應對業務流程本身的快速迭代。我們認為，一個成熟的集成平臺/數據中臺，需要為團隊中不同角色的成員提供適合他們的開發/維護/測試工具，使各成員能以較低的成本各施所長。這些工具至少包括：

我們理解一些工程師非常關心產品是否支持負載均衡。需要注意的是，對于現代的集成平臺和數據中臺而言，它們本身應當是由一系列的集群共同構成的分布式系統。

比如院內集成平臺擁有基于Web的操作管理頁面，運行API實現或數據流程的容器，有消息引擎，有數據庫，因此，可以構成一個典型的由Web程序，API/應用服務器，消息引擎和數據庫分層構建的分布式系統，而其中的每一層，都可以根據高可用與負載需求以不同目的的集群形態搭建出來。

以集成平臺產品為例，通常，集成平臺的Web管理程序由于并發操作的人很少，不需要單獨進行集群化；而API/應用服務器層默認會采用高可用集群，對于業務量極大的用戶，則可以采用負載均衡+高可用集群；數據庫層同樣如此，必要時還可以考慮部署讀寫分離+負載均衡+高可用集群；消息引擎則比較特別，如果不需要保障消息的先進先出特性，可以部署高可用和負載均衡集群，而對于需要保障消息處理時序的場景，則通常不能依賴負載均衡集群，或即使部署了負載均衡集群，也需要控制消息分規則，由單一實例處理這樣的消息。

但是否采用及采用何種集群架構，則完全應當基于業務的實際需要和產品能力。舉例而言，InterSystems產品可以支持負載均衡+高可用集群，還可以部署為讀寫分離+負載均衡+高可用集群，但通常我們并不會作為默認配置推薦給集成平臺用戶。原因在于，我們的產品在單臺服務器上經性能測試可以達到20億消息/天的處理效率。而根據我們對國內數百家三甲醫院的實際調查，即使在國內頂尖的三甲醫院中，也未發現超過2千萬消息/天的性能需求。因此，對于單體醫院，高可用集群已足夠使用。基于奧卡姆剃刀原理和成本控制的基本需求，負載均衡集群并無必要，反而會由于加大了架構的復雜性使持有、維護成本都大幅提升。而對于醫療集團客戶，由于需要集成數十家三甲與二級醫院，同時還需要控制單個服務器的成本，因此我們的一部分醫療集團客戶部署了負載均衡+高可用集群并可進行彈性橫向擴展。

當然，不同的產品有不同的性能指標，如果產品的本身性能表現無法支撐醫院業務量，那么部署為負載均衡集群支撐醫院的實際需求還是非常必要的。

相比開源產品，基于商業產品搭建平臺/中臺解決方案最顯著的附加價值主要來源于技術服務。無論是最終用戶還是解決方案提供方，都能受益于產品提供方的技術服務。技術服務也是項目能否成功上線、持續穩定運行或者二次開發的重要保障，對于技術服務，需要考慮產品技術提供方是否能夠提供下面的三種或者以上的方式：

對于醫院或是醫療集團客戶來說，如果需要掌握信息平臺或數據中臺，能夠達到自主維護、持續演進的目標，那么，無論是通過解決方案提供方還是通過產品技術提供方，都需要獲得上述的多種技術服務支持。

對于采用商業產品這一策略本身，需要經過大量的選型工作。產品技術提供方和解決方案提供商都會積極宣傳自己的產品，而醫院則需要對產品的特性、服務體系、性能表現、案例的代表性、綜合實施效果等做出評估，方可得出對自己有利的評估結果。在這個過程中，客戶往往還是需要綜合運用多種手段，包括自行評估、走訪典型案例和開展驗證測試等手段，避免常見的一些問題，例如：

例如對于僅支持消息引擎的集成平臺，往往需要按照一種特定的消息類型進行通信，使系統間交互具備統一協議，并且系統都需要改造以接入消息引擎。這樣的規劃不能說不好，但醫院的遺留系統能不能都配合平臺進行改造或醫院有沒有足夠的預算支撐改造項目落地，以及業務系統現場改造的風險，都會影響實施效果。因此需要切實評估和核實。

例如對于具有ETL能力的產品，需要評估其對于大容量數據（例如初始化數據加載過程）進行批量采集、轉換和落盤的處理效率，以便與借助簡單的SQL JDBC連接逐條抽數和轉換的SQL適配器相區別。由于兩種模式在處理速度上通常有數量級的差別，如果使用SQL適配器模式，在大批量對數據進行ETL操作時將不可避免地遭遇瓶頸。

在現在的技術條件下，即使對同一類型的接口，也往往有多種技術選擇。如產品不能提供對這些技術的覆蓋，則用戶需要投入額外的成本和風險完成接入。例如對常見的負載均衡方案而言，通常對于推模式接口（由外部調用觸發的接口），例如SOAP WebService或者REST API，往往都能提供負載均衡；而對于拉模式接口（由產品自身自動觸發），例如SQL掃描或一些CDC功能接口，則無法直接受益于負載均衡技術。假如實際業務中有大量需要通過SQL獲取數據的接口，則負載均衡集群并沒有多少意義。

再如SQL接口可以基于JDBC或ODBC連接，如果產品只能支持其中一種連接，那么對于遺留系統的接入能力將大打折扣。

對于架構和技術的落地，通常需要驗證過程，用戶才可能獲得預期的效果。例如市場上存在對架構模式進行過度簡化與概念偷換的現象。例如將SOA架構等價于ESB、將ESB的概念偷換為接口引擎、或將集成平臺概念偷換為消息引擎，而在實施時更進一步地簡化為接口的注冊和連接，實際上變成了點對點模式。由于集成架構將影響未來3～5年的醫院數字化轉型過程中的難度和成本，點對點模式的后續實施成本將隨接口的數量增加指數上升，導致后期的實施成本居高不下。

當然，充分了解到以上關于供應商選擇與技術選型的8個問題，才是真正的互聯互通建設的起點，更重要的是，醫院信息負責人還需要真正讀懂評測要求，并了解本院建設互聯互通的整體目標以及醫院管理層、臨床業務部門等相關部門的不同訴求，把這些目標與訴求一一映射到平臺/中臺解決方案中，才是成功通關的秘籍。