在討論該一體化還是集成化建設之前，我們需要明確定義的是，什么是一體化，什么是集成化，以及一體化和集成化之間的區別。

首先，一體化建設我們要擯棄「一家廠(chǎng)商、一套系統」的認知。醫療業(yè)務(wù)復雜而又具有一定的專(zhuān)業(yè)壁壘，很難由一家廠(chǎng)商、一套系統就可以滿(mǎn)足所有的需求；同時(shí)，一家廠(chǎng)商一套系統也會(huì )制約醫院信息化發(fā)展、扼制創(chuàng )新，醫院作為買(mǎi)單方更應該有主動(dòng)權。此外，一個(gè)廠(chǎng)商、一套系統也不一定就是一體化，我國不少一體化廠(chǎng)商，內部實(shí)際上也是多套系統，多套數據，無(wú)非是預先做好了業(yè)務(wù)接口，像是煙囪間接了飛線(xiàn)。

那該怎么定義一體化呢？從架構層面看，我們認為，真正的一體化應該要從一套核心數據、一致標準、統一底層的設計出發(fā)，具體應用系統則應該百舸爭流。正因為底層是統一的，所以數據自然可以互聯(lián)互通。而集成化的思路，則是每個(gè)應用完全自治，自己維護自己的數據結構，通過(guò)接口或者集成引擎來(lái)進(jìn)行業(yè)務(wù)的互聯(lián)互通。從本質(zhì)上看，一體化是通過(guò)共享數據進(jìn)行通信，而集成化則是通過(guò)通信來(lái)共享數據，這是一體化和集成化的顯著(zhù)區別。

圖片來(lái)源于網(wǎng)絡(luò )

圖片來(lái)源于網(wǎng)絡(luò )

２０１８年６月７日在首都醫科大學(xué)附屬北京友誼醫院正式啟動(dòng)了《基于ＦＨＩＲ的互聯(lián)互通標準研究》項目，在此之前，醫院的集成平臺和數據中心項目已基本完成符合互聯(lián)互通四甲等級的改造建設，文章詳細分析了ＦＨＩＲ技術(shù)方案與醫院環(huán)境的匹配度以及該標準的成熟度，為后續醫療機構使用ＦＨＩＲ實(shí)現互聯(lián)互通提供了參考依據。

我國醫院信息互聯(lián)互通標準化成熟度測評是通過(guò)互聯(lián)互通分級制度，明確醫院自身的發(fā)展目標和改進(jìn)方向，逐步實(shí)現信息化建設的標準化和規范化。而ＦＨＩＲ標準更側重于醫療信息交換的標準，它提供了一套框架和工具，以便于不同的醫療信息系統之間能夠進(jìn)行數據交換和集成。ＦＨＩＲ標準本身并不定義具體的等級，而是提供了一套豐富的資源和ＡＰＩ，來(lái)支持醫療信息的互操作性。

一體化建設為何會(huì )成為趨勢？醫療系統的本質(zhì)是什么？

醫療業(yè)務(wù)的流程與場(chǎng)景繁多，構成了一個(gè)典型的分布式系統，而分布式系統本身離不開(kāi)ＵＣ?。拢澹颍耄澹欤澹牟剪敔柦淌谠冢玻埃埃澳晏岢龅闹?zhù)名的ＣＡＰ定理，ＣＡＰ定理對分布式系統設計具有重要的指導意義，它幫助開(kāi)發(fā)者理解在面對網(wǎng)絡(luò )問(wèn)題時(shí)需要做出的權衡，并根據具體的應用場(chǎng)景和業(yè)務(wù)需求選擇合適的系統設計。

ＣＡＰ分別代表一致性（Ｃｏｎｓｉｓｔｅｎｃｙ）、可用性（Ａｖａｉｌａｂｉｌｉｔｙ）和分區容錯性（Ｐａｒｔｉｔｉｏｎ?。裕铮欤澹颍幔睿悖澹?，該定理表示，在一個(gè)分布式系統中，ＣＡＰ這三個(gè)特性不能同時(shí)得到保證，它是一個(gè)不可能三角。

其中，分區容錯性是必選項，因為故障在客觀(guān)上是一定會(huì )發(fā)生的，事實(shí)上我們在做分布式系統架構設計時(shí)，只有ＡＰ和ＣＰ兩種選項。而醫療、金融等嚴肅領(lǐng)域更傾向于使用ＣＰ系統。因為它以犧牲極少量的可用性，來(lái)保障系統信息能做到絕對一致。ＣＰ類(lèi)系統的底層采用一套數據架構來(lái)實(shí)現信息共享，而非ＡＰ類(lèi)系統的分系統自治存儲，ＡＰ類(lèi)系統事實(shí)上在互聯(lián)網(wǎng)系統設計中更為常見(jiàn)，這是我們強調的一體化，即底層數據架構一體化，它帶來(lái)的好處是能夠從根本上保障數據一致。

數據不一致會(huì )帶來(lái)什么問(wèn)題呢？舉個(gè)例子，醫生在醫囑系統下了一個(gè)ＣＴ預約，但是預約系統掛了，沒(méi)收到這條信息，患者以為成功預約了，結果白跑一趟。再舉個(gè)例子，如果遇到醫囑下達的高峰期，集成引擎高負載，性能受到嚴重挑戰，系統卡慢、信息延遲甚至丟失，如果涉及到收費、處方等敏感的業(yè)務(wù)，導致的后果會(huì )更加嚴重。

除了數據不一致問(wèn)題，集成化建設當前所面臨還有各系統接口標準不一致、集成引擎負載過(guò)大、信息交換效率低等系統性挑戰。系統集成的核心要務(wù)是數據交換和業(yè)務(wù)協(xié)調所遵從的標準成熟度，這個(gè)標準是否可用，持續高效的迭代顯得尤為關(guān)鍵。矛盾的是，醫療信息集成有著(zhù)項目高度復雜、場(chǎng)景不斷創(chuàng )新、技術(shù)不斷迭代的特征，而目前，行業(yè)缺乏標準的常態(tài)化組織進(jìn)行有效管控，更多的是依靠行業(yè)協(xié)會(huì )和兼職成員按照項目的方式在運作，必然會(huì )導致標準跟不上業(yè)務(wù)需求，最后往往演變成各家自定義標準，進(jìn)一步放大了集成化的問(wèn)題。

當然，集成化建設可以選擇多種方案改善數據不一致問(wèn)題，比如：規范接口、數據標準、選擇同步提交（２ＰＣ，２?。校瑁幔螅濉。茫铮恚恚椋簦┑确绞?。但必須要認清的事實(shí)是：高效的分布式事務(wù)本來(lái)就是業(yè)界難題，且無(wú)論如何提升，都無(wú)法達到信息的完全一致。究其根本還是因為集成化方案本身是一個(gè)類(lèi)ＡＰ的系統，這是系統架構設計的取舍決定的，即：優(yōu)先保障可用性，允許一定程度的數據不一致。

在一體化架構方案設計中，技術(shù)上可以支持應用層無(wú)狀態(tài)高可用，數據庫可以使用主從切換等容災技術(shù)和良好部署的基礎設施，能夠實(shí)現數據丟失（ＲＰＯ）為０，業(yè)務(wù)恢復時(shí)間（ＲＴＯ）小于數十秒，在數據庫方面，現在主流的關(guān)系型數據庫（如ＰＧ）則完全可以支撐數十萬(wàn)事務(wù)每秒的處理。實(shí)現在不影響診療業(yè)務(wù)的同時(shí)保障數據一致。說(shuō)到這里我們不難發(fā)現，其實(shí)相比系統可用性問(wèn)題，信息不一致的問(wèn)題更難以解決。

當我們在做醫院大數據應用時(shí)，一體化架構的優(yōu)勢也是顯而易見(jiàn)的。尤其在當下火熱的數據應用場(chǎng)景中，不同業(yè)務(wù)系統中的相關(guān)和相似數據，經(jīng)常對不上或者自相矛盾，需要進(jìn)行深度的、大規模的數據治理。然而數據治理成本高、難度大，非?？简瀼S(chǎng)家綜合實(shí)力，且最終數據質(zhì)量相比一套底層數據的一體化架構相去甚遠。

一體化架構好處如此之多，醫院能立刻實(shí)現嗎？

話(huà)還是要說(shuō)回來(lái)，關(guān)于醫院信息化應該一體化還是集成化建設的命題前如果加一個(gè)時(shí)間條件，如現在、當下，那么，縱使一體化有種種好處，對于目前國內的絕大部分醫院來(lái)說(shuō)，也不是立刻就能夠實(shí)現的，畢竟現實(shí)情況相對于理想總有滯后性。

一方面是歷史遺留問(wèn)題多，醫院的信息化建設非一朝一夕才走到今天，很多醫院也是以“打補丁”的方式“縫縫補補又三年”，很難在不影響醫院運營(yíng)的同時(shí)快速推翻重建；另一方面是信息化的發(fā)展比如ＨＬ７?。疲龋桑业膮f(xié)議也剛成熟不久，本身難度也比較高，廠(chǎng)商之間目前也很難達成共識，需要更強有力的監管機構在互聯(lián)互通的標準中進(jìn)行提升。

對于現階段的醫院來(lái)說(shuō)，集成化還是更加實(shí)際的選擇，當然，新建醫院可以考慮從０－１開(kāi)始一體化架構設計。

小　結