為了誘惑你來閱讀我的文章，今天做回標題黨，很高興你能點進來。前段時間我聽HIT專家網組織大佬們的網課，其中提到，設計一個20年不做顛覆性改變的系統，這個問題讓我思考了良久。對啊，一個系統設計如何能扛過20年的風風雨雨，這是一個有意思的問題？ 

你可能心底和我一樣有一堆疑問，20年為你服務軟件公司是否倒閉？20年你是否還在原來這家單位？20年又會涌現多少新技術？20年發布多少醫療行業改革政策？20年之間充滿了無數的變數，設計一個系統如何扛過20年的時間，想到這里是不是感覺有點天方夜譚？接下來談談我的想法。

先看世界上頂級大佬，貝索斯在一次演講中曾說過“我經常被問到一個問題：未來10年，會有什么樣的變化？我覺得這個問題很有意思，也很普通。但我很少被問到：未來10年，什么是不變的？”，“我認為第二個問題比第一個問題更重要，因為你需要將你的戰略建立在不變的事物上”。

按照貝索斯這個思路，同樣可以用在我們這個醫療行業上。未來20年醫療行業什么不變？為患者服務的本質不變。這個原則不管20年、30年都始終不變，我們的信息系統業務設計可以圍繞這個原則開始展開。

順著這個思路下來，經過這么多年發展應用，醫院信息系統復雜程度已經非常高，我們也希望不要動不動就要推倒重來建設系統（俗稱不要重復造輪子），換系統的代價實在太大，希望保持一種長久的基本性穩定，一般HIS系統會干了一件很重要的事情，就是對系統進行分層設計（俗稱架構設計），將系統解耦，獲得一個穩定的底層結構（20年不會顛覆改變），上層允許各種HIT應用可以做到“熱插拔”。

醫院信息系統架構這個單純從技術的角度來看，未來20年什么不變的？要回答這個問題，首先回顧我們現有的軟件架構，為了把問題簡化，不考慮單機版的情況，我把現有所有的信息系統架構統一抽象成二層架構(C/S、B/S)、三層架構(SOA、微服務、中臺)，如下所示：

二層架構

三層架構

不管是二層還是三層結構，在相當長一段時間內“數據庫”這個底層是不會變化的。所以要做到20年不做根本性改變，我個人認為如何設計“數據庫”是關鍵。

回到現實當中，是否存在可以運行20年的系統，我只能說靠運氣，有人說我們不是有HL7標準、國家標準，按照標準做不就可以了，HL7太復雜、落地困難，國家標準醫院完全遵循也很困難，還有標準過多的問題，一個icd全國就有好幾個版本，何況每個廠家都有一套自己架構，互不相通，這套架構能跑20年是個大問題，還有廠商能活20年也是個問題，既然有這樣問題、那樣問題，你自然想到了一點解決方法，廠商將自己架構開放出來不就行了。

薛萬國主任，在他文章提到“封閉是當前醫院信息系統發展的最大技術障礙，很多醫院抱怨“被廠商綁架”的根源在于系統的封閉性，醫院基礎信息系統具有開放的責任與義務，有建立和遵循業務集成規范的義務，開放的內容包括：開放數據、開放事件、開放服務功能”。坦白說單憑廠商自覺性，比登天還難，畢竟商場如戰場，換位思考，這種決策相當于“自我革命”，非常困難做的，要有非凡的勇氣。

在這個章節開始之前，我先來談一下去年工信部推出的一個政策，“攜號轉網”，也稱作號碼攜帶、移機不改號，也就是說一家電信運營商的用戶，無需改變自己的手機號碼，就能轉而成為另一家電信運營商的用戶，并享受其提供的各種服務（百度百科）。

我們生活都有過這樣的困惑，比如我是中國移動的客戶，我現在對移動很不滿意，我想換成中國電信，你會換嗎？拿我個人舉例，不會換，因為我的移動手機號碼如果換了，我的微信要重新更換手機號碼綁定，我的銀行賬號也是綁定這個手機號碼，我的親人、同事、朋友保存這個號碼，難道挨個發短信通知，代價實在太大！移動服務再不好，也只能忍著。現在不一樣了，有了“攜號轉網”，我這個移動手機號碼可以不變，只是換一下運營商就行了。國家給我了“用腳投票”的權利，我上個周末去移動營業廳辦理寬帶續費，我發現費用比去年便宜了一半，我那時候就想是不是受了這個“攜號轉網”政策的影響，心里就是一個“爽”字。

作為醫院一方，我們特別害怕被廠商“綁架”，一旦采用某個廠商的產品以后，一般不輕易換系統，因為代價實在太大，這個代價好比換手機號碼，尤其你的系統已經運行十年以上，除非是“忍無可忍”。為什么你那么害怕換系統，最重要原因不在于你覺得舊系統不好用，而是怕后臺數據庫發生了“斷層”，A廠商的數據與B廠商的數據互不相通的，B廠商的系統調用不到A系統的歷史數據，你可能說做接口啊，話是沒錯，假如你又成B廠商換成C廠商，又做一次接口嗎，工作量巨大。

如果允許醫療數據“攜號轉網”，也就是說某權威機構制定一套開源數據庫表結構標準，如果被多個廠商在遵循這套標準開發軟件，可以無縫切換不同廠商的軟件，用戶真正擁有了“用腳投票”的權利，也保證了做到20年不做顛覆性改變成為大概率事件。

在這里或許你了解我要表達的意思了，只有HIT開放新生態才能做到設計20年不做顛覆性改變的信息系統，當然這只是我個人看法。

其實醫院大部分的業務場景都是相近的，為避免重復造輪子，假設CHIMA成立有一個“數據庫設計標準化委員會”，比如，設計“患者主索引表結構”，主鍵id、姓名、性別、出生日期、戶籍地址、現地址……。設計“掛號業務表結構”，主鍵id、患者id、姓名、掛號醫生id、掛號醫生姓名、掛號時段……相關流程圖、時序圖等等。假設有A廠商、B廠商軟件都是基于CHIMA的“數據庫設計標準化委員會”來開發的，醫院就可以實現“攜號轉網”，實現真正HIT應用“熱插拔”。

為什么你要考慮表結構、流程圖、時序圖這么具體，第一個原因降低大家開發門檻，容易普及，容易到一個還未畢業大學生就可以在學校把這些東西了解清楚了，還可以開發相應的軟件，如果要別人實現 HL7協議標準，坦白說，學習成本過高，開發難度大。第二個原因，每個人設計數據庫的能力水平千差萬別，表、字段的命名，范式設計都是有學問的。其實我們現在各種上報的數據接口，就是一堆設計好表結構給到你，為什么不給你HL7標準，讓你自己看著辦，原因就是以上2條。

某上報數據接口

我斗膽再從商業的角度來分析這個問題。如果某個廠商基于CHIMA的“數據庫設計標準化委員會”來開發的，相當于給用戶一把刀子，隨時擁有“捅你”的機會，用戶離開你的時候都不會和你說聲“再見”，因為他們是“用腳投票”的，同時倒逼廠商必須重視售后服務、軟件易用性、穩定性。

還有人會說，你這個開源東西不安全，我覺得這完全是悖論，整個互聯網的大廈都是建立在開源“TCP/IP”協議，移動手機操作系統80%份額來自于開源安卓系統。為什么這些開源的東西，你敢用。安全問題本質非法訪問未授權的資源，應對安全的問題現在有非常多的解決方案。比如數據庫設定不同的角色；手機APP重要概念隱私權限，比如APP打開攝頭，征詢用戶同意才能操作；防火墻的攔截非法請求。本質是檢測別人是否非法訪問資源。

以上來自一個普通醫信工程師的思考，認知水平十分有限，不足之處，請大家指正批評！

（作者：馮火 廣東省羅定市人民醫院信息科）

    https://live.chima.org.cn/watch/975050

    https://live.chima.org.cn/watch/997828

歡迎您分享醫院信息化建設中的技術實踐和工作經驗。

投稿郵箱：sec@chima.org.cn

微信：13716062058