最近，很多媒體和廠商都談到“中臺”在醫療場景的應用。同時，關于醫療“中臺”，網上也有不少質疑的聲音。

醫療信息化領域的“中臺”一般是指具備“中臺”特征的新一代電子病歷。很多文章講“中臺”，要么講的膚淺，要么故弄玄虛，讓廣大醫療信息化從業者面對“中臺”顯得無所適從。甚至對“中臺”增加了幾分神秘感。

我作為一位醫療信息化產品經理，希望結合自身工作實際，從以下四個方面談談個人對于醫療“中臺”的基本認識：1.為什么要上“中臺”；2.“中臺”上線前注意事項：業務、流程、數據標準化規范化；3.“中臺”一些基礎組件的設計介紹；4.“中臺”技術方案特點與設計介紹。

為什么要上“中臺”

1.推出“中臺”解決方案的原因

1.1 內聚與耦合

說到醫療“中臺”推出的原因就不得不提到內聚與耦合。內聚（Cohesion）是一個模塊內部各成分之間相關聯程度的度量。耦合（Coupling）是模塊之間依賴程度的度量。內聚和耦合是密切相關的，與其他模塊存在強耦合的模塊通常意味著弱內聚，而強內聚的模塊通常意味著與其它模塊之間存在弱耦合。模塊設計追求強內聚，弱耦合。軟件設計中通常用耦合度和內聚度作為衡量模塊獨立程度的標準。劃分摸塊的一個準則就是高內聚低耦合。（詳見參考資料1）

但是目前，國內廠商前期在設計信息系統的時候，由于多方面的原因導致：基礎組件耦合了太多個性化需求，以至于后續臨床對信息化建設提出新需求時，或者監管要求有所變化時，新需求或者變化仍需要調用常用基礎組件。由于之前軟件設計沒有采取結構化模塊化思路基礎組件耦合太多個性化需求。解耦的成本，遠高于重新實施一套新系統的成本。為了響應需求或是變化只有把老系統廢掉，重新組織人員實施一套全新的系統。為了大家理解這個過程，我用綜合布線的例子來給介紹：綜合布線的標準橫平豎直遵守一定的規則來部署線纜。前期軟件設計沒遵守相應的規定，在布線的時候隨意部署。當需要更換某一根線纜的時候發現所有的線纜已經打結成團了。到時候只能剪刀一剪換新線重新部署。“中臺”思路就是在布線線纜的時候按照一定的規則去部署，以便于后續更新與維護。

為了讓大家對基礎組件耦合太多個性化需求有一個直觀的了解，下面，筆者通過在工作中遇到的兩個案例介紹，以便大家有個直觀的認識。

案例一：體溫單

圖 1 體溫單（截圖來源：基礎護理學第六版（人衛版）221頁）

大多數醫院信息系統住院護士工作站里面的體溫單都如圖1所示。一張體溫單關聯了脈搏、呼吸、血壓、入量、出量、大便次數、體重、身高等多種屬性，不同數據全部關聯到一張體溫單上。

這種表單的設計還停留在紙質時代設計思路，盡量在一張表單上關聯更多的信息。信息化時代的產品經理也沒考慮其背后的成因，直接把紙質表單電子化，卻忽略了很重要的一點：電子化跟信息化是不能直接劃等號的。

此處的關注點不僅僅是體溫單，而是醫療信息系統里面涉及醫療數據錄入、存儲、查詢模塊設計。這個模塊設計如何滿足“中臺”思路：能快速響應臨床需求、同時做到結構化模塊化。在傳統設計當中無法滿足未來一些應用場景。比如，CDSS（臨床輔助決策系統）里面，涉及機器學習相關的某些對于患者處置措施的觸發值是需要從生命體征模塊抓取。

以腦卒中患者血糖管理為例：當血糖高于10.0mmol/L 時應該系統提醒醫生給予降糖治療，當血糖低于3.3mmol/L 時應該系統提醒醫生盡快給予補糖治療。當患者的血糖觸發到閾值的時候，這個時候應該把患者血糖變化的可視化圖形：血糖折線圖作為附件以通知的形式推送給醫生，讓醫生有個直觀的認識，知道患者的血糖變化需要干預。

而現實當中，圖1體溫單包含了不同屬性醫療數據，作為附件展示給醫生，醫生關注點是血糖本身？還是其他醫療數據呢？

當然，還有一種聲音，通過集成平臺去抓取一個數值彈框提醒醫生。這種解決方案無法直觀向醫生展示血糖的動態變化趨勢。醫生還需要去查看血糖變化趨勢。這樣增加醫生的工作量，時間長了醫生就會棄用。

在患者轉運交接（ISBAR）其中的A（Assessment）評估涉及的生命體征，按照互聯互通的思路應該是：自動從生命體征模塊里面抓取數據填充。然而，現實是系統無法自動獲取數據填充，護士還需要手動再次錄入生命體征數據。在某些場景手術恢復室內，麻醉醫生和護士在同一時刻錄入的患者生命體征數據都存在不一致的問題。

案例二：壓瘡不良事件上報

圖 2 某家醫院系統內壓瘡不良事件上報表單

圖2是某家醫院信息系統內不良事件上報表單截圖。一張表單里面包含壓瘡評估以及對應處置措施，還有不良事件上報以及不良事件原因分析，而且數據和流程沒有分開。這是典型的基礎組件耦合太多個性化需求的例子。如果按照高內聚和低耦合的思路，這張表單其實涉及壓瘡評估、壓瘡護理、不良事件上報、不良事件原因分析這四部分的內容其實應該分開。每部分作為附件數據單獨提交，流程和數據分開來實現相應的功能。傳統的設計一旦需求有所變更那么表單甚至流程就需要重新設計，這樣維護成本就增加了。 

到此，大家不必太多糾結這兩個案例。我舉例只是為了讓大家對基礎組件耦合太多個性化需求這個問題有一個全新認知。在后面第三篇文章—《“中臺”一些基礎組件設計》中，我會為大家詳細介紹以“中臺”思路如何解決這些問題。至此得出一個結論：推出“中臺”解決方案的原因，是為了解決基礎組件耦合太多個性化需求導致的系統無法升級和滿足一些新的應用場景，而推出“中臺”解決方案。

2.“中臺”的定義與理解

2.1 “中臺”定義

網絡上對“中臺”的定義：“中臺”是真正為前臺而生的平臺（可以是技術平臺，業務能力甚至是組織機構），它存在的唯一目的就是更好地服務前臺規模化創新，進而更好得響應服務引領用戶，使企業真正做到自身能力與用戶需求的持續對接。（詳見參考資料2）

2.2 個人對”中臺”（醫療）的理解

通過對醫療業務數據標準化規范化之后，按照一定規程設計常用基礎組件，以便快速響應臨床提出的新需求，以及監管部門對信息化要求，最終實現多業務數據之間的互聯互通，降低開發與維護的成本。避免出現由于系統無法升級只能廢掉的窘境。

當然，醫療“中臺”不是個大染缸，什么都能往里面裝。很多廠商設計的中臺系統一個比一個復雜，總想著蛇吞象，什么都做，這樣很容易消化不良。但真正考驗一家公司或是產品經理能力的，是怎么在滿足監管要求的前提下，把系統設計的簡單，讓一線醫護人員能快速上手。系統簡單，能快速上手，最終節省下來的時間對于醫院來說也是一筆不小的成本。

2.3 “中臺”與集成平臺的關系

說到這里，可能會有信息科的朋友問：醫院系統通過集成平臺實現了互聯互通，為何還需要“中臺”？

這是因為，現有集成平臺實現的互聯互通，本質上是多系統中心點式的信息共享。它是一種中轉式的互聯互通。而醫院最終想要實現的互聯互通是一種跨多系統業務流程和數據自動化互聯互通。集成平臺是滿足不了這個需求的。所以還是需要靠中臺來實現。通過重新設計這些可以復用的基礎組件來支持相關數據業務流程自動化，從而降低成本增加效率。

參考資料：

1.百度百科：高內聚低耦合（https://baike.baidu.com/item/%E9%AB%98%E5%86%85%E8%81%9A%E4%BD%8E%E8%80%A6%E5%90%88/5227009?fr=aladdin）

2.簡書：白話中臺戰略-1開篇：中臺是個什么鬼？

（https://www.jianshu.com/p/86dc7ad52ad6）

（未完待續）