三甲醫(yī)院傳統(tǒng)院內(nèi)信息化系統(tǒng)經(jīng)歷20多年的建設(shè)發(fā)展，目前正面臨智慧醫(yī)院建設(shè)轉(zhuǎn)型中的諸多問題：例如在互聯(lián)互通和電子病歷評級過程中，原有單體應用、C/S架構(gòu)應用的ESB性能、單點故障和服務治理問題；在基于消息驅(qū)動模型的醫(yī)療大數(shù)據(jù)分析中數(shù)據(jù)標準化、全面向性和及時性等問題；在后疫情時代，傳統(tǒng)架構(gòu)無法快速滿足互聯(lián)網(wǎng)醫(yī)療發(fā)展的問題；醫(yī)院物聯(lián)網(wǎng)應用的數(shù)據(jù)分析計算協(xié)同問題等等。
基于云原生架構(gòu)的解決方案是醫(yī)院邁向數(shù)字化時代的必由之路，包括面向醫(yī)務人員的“智慧醫(yī)療”、面向患者的“智慧服務”以及面向管理者的“智慧管理”都可以利用云原生架構(gòu)實現(xiàn)。
社區(qū)近日組織2021容器云職業(yè)技能大賽醫(yī)療行業(yè)應用創(chuàng)新解決方案成果發(fā)布及探討活動，邀請到武漢市中心醫(yī)院、深圳華僑醫(yī)院、西寧市中醫(yī)院、內(nèi)蒙古醫(yī)科大學附屬醫(yī)院、中山大學附屬腫瘤醫(yī)院、南京市第二醫(yī)院、廊坊人民醫(yī)院和瀏陽市中醫(yī)醫(yī)院等8家醫(yī)院的一線技術(shù)專家和東軟集團、RedHat公司的技術(shù)顧問參與，針對如何基于云原生架構(gòu)加速三甲醫(yī)院實現(xiàn)互聯(lián)互通、建設(shè)智慧醫(yī)院，在熱烈的氛圍中對基于云原生架構(gòu)的醫(yī)院信息化解決方案進行了討論和探索。
本文梳理了與會者的分享精華，重點從五個方面20個交流主題進行總結(jié)，包括：醫(yī)院業(yè)務容器化轉(zhuǎn)型的思考，智慧醫(yī)院建設(shè)的思考，智慧醫(yī)院解決方案的實施和部署，容器云平臺的使用、安全和運維，交流共識，希望給致力于研究的醫(yī)院容器云解決方案的同行們提供一定的參考和幫助。
一、醫(yī)院業(yè)務容器化轉(zhuǎn)型的思考
目前醫(yī)院信息化發(fā)展以ESB和C/S架構(gòu)私有云部署為主，基于容器化的云云原生架構(gòu)尚未普及。特別是核心HIS/PACS/EMR等業(yè)務系統(tǒng)也沒有進行微服務化改造。那么，考慮對醫(yī)院業(yè)務系統(tǒng)進行微服務化改造并采用容器技術(shù)進行部署，哪些信息化系統(tǒng)會比較合適呢？如果將現(xiàn)有業(yè)務系統(tǒng)進行改造部署，困難和問題又有哪些？
1、三甲醫(yī)院目前適合容器化的典型應用有哪些？
jakeyyu某三甲醫(yī)院系統(tǒng)架構(gòu)師：
首先明確的就是互聯(lián)網(wǎng)業(yè)務，因為大部分互聯(lián)網(wǎng)業(yè)務可以使用單體結(jié)構(gòu)技術(shù)去實現(xiàn)，比如功能單一的業(yè)務或并不復雜的業(yè)務；第二就是在核心業(yè)務中可以拆分成為獨立服務的業(yè)務，通過接口與核心相連。
劉東東軟集團IT技術(shù)咨詢顧問：
目前三甲醫(yī)院最適合的容器化場景應該是智慧醫(yī)院應用場景。
例如說患者中心：通過服務化、移動化的手段使醫(yī)療服務和醫(yī)院流程向患者集中。醫(yī)療費用中心，通過微服務和容器化支持產(chǎn)品應用快速構(gòu)建，靈活應對醫(yī)院快速發(fā)展的信息化需求。
另外，在醫(yī)院的云數(shù)據(jù)中心建設(shè)上，容器化部署也會帶來很多好處。
基于容器化的云原生技術(shù)是大勢所趨，容器云具備快速部署和便捷運維等特性，支持DevOps的開發(fā)運維一體化，可以讓醫(yī)院信息中心業(yè)務部署更靈活，更簡單。
2、三甲醫(yī)院業(yè)務的特殊性和復雜性導致單體應用轉(zhuǎn)變?yōu)樵圃軜?gòu)具有一定的困難性，如何解決？
【問題描述】云原生架構(gòu)中具有微服務、容器化、DevOps等特點，目前國內(nèi)三甲醫(yī)院的信息化建設(shè)相對較為完善，技術(shù)成熟，為了盡快全面實現(xiàn)互聯(lián)互通，智慧化醫(yī)院建設(shè)，也期待技術(shù)上的領(lǐng)先和突破。目前，國內(nèi)大多數(shù)三甲醫(yī)院的信息系統(tǒng)體量較大，絕大多數(shù)以單體應用為主。隨著政策的指引，以及信息安全的要求，ESB總線技術(shù)業(yè)已全面應用在三甲醫(yī)院的信息化平臺架構(gòu)中。作為云原生架構(gòu)的優(yōu)點，容器化和微服務應用優(yōu)勢明顯。但是三甲醫(yī)院業(yè)務的特殊性和復雜性導致單體應用轉(zhuǎn)變?yōu)樵圃軜?gòu)具有一定的困難性，比如業(yè)務如何拆分并遷移至微服務，數(shù)據(jù)如何統(tǒng)一管理，業(yè)務流程的全面管控，在轉(zhuǎn)變過程中這些困難如何克服？
Sam_Zhu RedHat（Beijing）解決方案架構(gòu)師：
需要引入具有豐富經(jīng)驗的合作伙伴和領(lǐng)先解決方案的廠商。三甲醫(yī)院的IT建設(shè)水平處在行業(yè)領(lǐng)先階段，在智慧醫(yī)院建設(shè)方向也有很強的意愿。紅帽與近90%全球500強企業(yè)客戶合作，幫助他們進行數(shù)字化轉(zhuǎn)型，使用OpenShift業(yè)內(nèi)領(lǐng)先技術(shù)，在應用微服務和容器化、業(yè)務流程自動化等方面積累了豐富經(jīng)驗。相信紅帽的技術(shù)再配合東軟在行業(yè)解決方案方面的能力，一定能為廣大三甲醫(yī)院客戶IT建設(shè)帶來全面提升。
醫(yī)療行業(yè)技術(shù)專家：
1、業(yè)務拆分盡量遵循DDD設(shè)計原則，由醫(yī)院具體的使用者來驅(qū)動設(shè)計，而不是傳統(tǒng)的設(shè)計方法！盡量在比較完備的模型基礎(chǔ)上去做相應的架構(gòu)。而不是在原有業(yè)務基礎(chǔ)上由開發(fā)主導設(shè)計，這樣的結(jié)果就是換湯不換藥。
2、醫(yī)療業(yè)務確實很復雜，面對這樣的業(yè)務，短時間內(nèi)沒辦法拆分相對合理的領(lǐng)域模型，所以不要過分設(shè)計，把握核心業(yè)務就好。
3、還有您提到的ESB，相對于云原生，其本質(zhì)就是上面的業(yè)務拆解
4、任何技術(shù)都不是銀彈，鞋子合不合適只有腳知道。不要刻意模仿比如淘寶、京東等互聯(lián)網(wǎng)大廠的架構(gòu)方案，否則只會東施效顰。
以上是個人對云原生在醫(yī)療領(lǐng)域的淺見，歡迎討論指正。
3、醫(yī)院消息驅(qū)動的系統(tǒng)互通架構(gòu)如何轉(zhuǎn)型到云原生？
【問題描述】消息驅(qū)動的集成平臺架構(gòu)隨著系統(tǒng)越來越多，依賴平臺就越來越強，這種架構(gòu)如何往云原生轉(zhuǎn)換，微服務與這種集成平臺是怎樣關(guān)系，存在矛盾還是并不沖突？
Sam_Zhu RedHat（Beijing）解決方案架構(gòu)師：
消息是異步通訊的基礎(chǔ)，集成平臺也是實現(xiàn)SOA的重要標志。這些架構(gòu)處理的問題也都是云原生技術(shù)（微服務、容器化等）所需要面對的，它們不矛盾，反而會利用消息和原有的集成模式來以最低的代價解決問題。
因此我們看到大量基于消息中間件異步通訊的微服務方案，以及基于容器和微服務技術(shù)的分布式敏捷集成方案。集成平臺由于服務設(shè)計和功能拆分不合理或管理因素等形成的依賴性導致平臺形成了一個新的大單體業(yè)務系統(tǒng)，這和集成平臺建設(shè)初衷也是背道而馳的，我們應該在云原生技術(shù)引入時避免這些問題的出現(xiàn)。存量和新建并行是可取的做法，開發(fā)和運維會積累實際經(jīng)驗，不斷糾正和完善。
4、醫(yī)院從基于ESB的平臺遷移到云原生平臺的難點在什么地方？
【問題描述】原有的服務要變成微服務，是否有工具自動轉(zhuǎn)換，.NET封裝的服務如何跑著DOCK上？客戶端調(diào)用是否需要改變？
Sam_Zhu RedHat（Beijing）解決方案架構(gòu)師：
云原生的目的不是重構(gòu)和技術(shù)升級，是為了更靈活和高效的解決業(yè)務問題。ESB的大單體應用整體搬遷技術(shù)上問題不大，但是沒有業(yè)務上的收益，甚至效果更差。實際遇到很多客戶的經(jīng)驗是小步快跑，老ESB會和微服務應用共存很長一段時間，我們用運用一些微服務容器化的敏捷集成技術(shù)將無法改造的老系統(tǒng)和新系統(tǒng)打通。業(yè)務挑戰(zhàn)嚴峻，對靈活性和開發(fā)迭代周期短的業(yè)務領(lǐng)域應用，可以優(yōu)先考慮轉(zhuǎn)到這個方向上來。
原有的服務變成微服務更多的是業(yè)務問題，業(yè)務領(lǐng)域拆分的合理性才是重點。技術(shù)上有很多工具實現(xiàn)，包括.net服務容器化，紅帽就提供.netcore基礎(chǔ)鏡像和遷移支持?？蛻舳艘欢ㄊ亲畲笙薅鹊谋ＷC穩(wěn)定不變，這也是集成層解耦的主要目的。
jakeyyu某三甲醫(yī)院系統(tǒng)架構(gòu)師：
從這個問題來說，主要是esb的平臺遷移到云原生平臺，關(guān)注微服務架構(gòu)如何實現(xiàn)的問題。我們知道對于單體架構(gòu)業(yè)務轉(zhuǎn)變?yōu)槲⒎盏募軜?gòu)面臨著一些固有的特點，如微服務之間如何通信，微服務之間數(shù)據(jù)如何共享，遷移過程如何不影響現(xiàn)有業(yè)務等。如果原來的基于esb平臺上的業(yè)務是linux系統(tǒng)，客戶端調(diào)用應該問題不大。
5、微服務化改造過程中，數(shù)據(jù)中臺技術(shù)是如何對于醫(yī)院信息化互聯(lián)互通要求起到支撐作用的？
【問題描述】數(shù)據(jù)中臺技術(shù)是如何對于醫(yī)院信息化互聯(lián)互通要求起到支撐作用的？（從數(shù)據(jù)中臺技術(shù)的特點，發(fā)揮作用，結(jié)合醫(yī)院信息化建設(shè)的特點，以及三甲醫(yī)院業(yè)務的需求層面）
gulx東軟集團股份有限公司軟件架構(gòu)師：
數(shù)據(jù)中臺以數(shù)據(jù)湖為底座，打破數(shù)據(jù)壁壘，實現(xiàn)醫(yī)療信息數(shù)據(jù)的統(tǒng)一存儲，解決醫(yī)療大數(shù)據(jù)存儲難的問題。以大數(shù)據(jù)平臺的分布式計算能力為支撐，結(jié)合數(shù)據(jù)治理，形成數(shù)據(jù)資產(chǎn)，解決醫(yī)療數(shù)據(jù)孤島現(xiàn)象，實現(xiàn)數(shù)據(jù)連通。采用流批一體的OLAP技術(shù)解決方案，支撐大型三甲醫(yī)院的離線與實時相結(jié)合的業(yè)務需求。
二、智慧醫(yī)院建設(shè)的思考
醫(yī)院進行互聯(lián)網(wǎng)架構(gòu)轉(zhuǎn)型，建設(shè)容器化的云原生平臺，建設(shè)數(shù)據(jù)中臺、業(yè)務中臺，進行微服務化改造，這一切都是為了智慧醫(yī)院的建設(shè)，那么醫(yī)院智慧醫(yī)院究竟該如何進行建設(shè)？智慧醫(yī)院和云原生平臺的關(guān)系又是什么呢？
1、智慧醫(yī)院平臺建設(shè)一般需要分為幾個階段進行設(shè)計？
劉東東軟集團IT技術(shù)咨詢顧問：
1、智慧醫(yī)院平臺的建設(shè)按照2021年國家衛(wèi)生健康委《關(guān)于印發(fā)醫(yī)院智慧管理分級評估標準體系（試行）的通知》。智慧醫(yī)院的建設(shè)主要分為三部分內(nèi)容，包括智慧醫(yī)療、智慧服務、智慧管理三大評估標準。
2、智慧醫(yī)療面向醫(yī)務人員，智慧服務主要面向患者，智慧管理主要指后勤物資和運營管理。
3、為了實現(xiàn)以上三部分智慧醫(yī)院建設(shè)內(nèi)容，首先需要有一定的基礎(chǔ)建設(shè)和積累，主要包括以電子病歷為核心的醫(yī)院信息化和醫(yī)院數(shù)據(jù)的統(tǒng)一安全管理。
4、在醫(yī)院信息化建設(shè)和數(shù)據(jù)安全建設(shè)之前，又需要有一個具備安全、可靠和穩(wěn)定的基礎(chǔ)設(shè)施。
5、所以，實現(xiàn)智慧醫(yī)院，以上任何一部都不可或缺，特別是在基礎(chǔ)設(shè)施方面，首先需要查缺補漏。在醫(yī)院內(nèi)部利用物聯(lián)網(wǎng)、云原生、云計算和大數(shù)據(jù)等新技術(shù)完成基礎(chǔ)環(huán)境建設(shè)，統(tǒng)籌管理資源。
2、智慧醫(yī)院建設(shè)中，后勤建設(shè)、管理的難點和對策有哪些？
【問題描述】醫(yī)院后勤管理的智能化實際是上醫(yī)院管理智慧化，它是“智慧醫(yī)院”建設(shè)中的一個重要部分，但是，目前情況下，醫(yī)院后勤建設(shè)和管理，其智能化水平還比較低，和智慧醫(yī)院的中的智慧醫(yī)療、智慧服務的快速發(fā)展不相匹配。我的問題是醫(yī)院后勤管理智能化有哪些痛點和難點，有什么對策？
劉東東軟集團IT技術(shù)咨詢顧問：
首先，后勤管理的建設(shè)難點主要如何建設(shè)一個數(shù)據(jù)平臺，將智慧后期系統(tǒng)與其他系統(tǒng)連接獲取數(shù)據(jù)，然后進行精細化運營。
其次，智慧化的醫(yī)院后勤管理系統(tǒng)需要將被動服務轉(zhuǎn)化為主動服務，提高后期服務效率，同時構(gòu)建智慧化的統(tǒng)一后勤服務體系。
1、數(shù)據(jù)平臺的建設(shè)需要利用IT技術(shù)和其他系統(tǒng)（例如如電梯、中央空調(diào)、醫(yī)用氣體和消防系統(tǒng)等）連接，開展數(shù)字化智慧后勤建設(shè)。
2、對數(shù)據(jù)進行精細化管理，提高設(shè)備運行效率，降低能源與資源消耗，促進醫(yī)院的和諧、可持續(xù)性發(fā)展
3、數(shù)據(jù)平臺的運營和承載同時需要一個云平臺進行統(tǒng)一，同時也可以考慮云原生平臺來實現(xiàn)。
jakeyyu某三甲醫(yī)院系統(tǒng)架構(gòu)師：
這個問題目前的解決辦法還是比較成熟，是因為各大公司有很多具體的實施案例，一般依托于企業(yè)的智慧園區(qū)管理模式。對于醫(yī)療行業(yè)，特別是醫(yī)院，包括兩個方向，第一是建設(shè)數(shù)據(jù)中樞平臺，將院區(qū)管理，人員、車輛、物業(yè)、樓宇等相關(guān)要素信息集中管理，通過一卡通的方式，進行人員身份認證，門禁識別，車輛進出院區(qū)等。第二是關(guān)于醫(yī)療，這部分通常與醫(yī)院系統(tǒng)做集成，包括醫(yī)用物資、設(shè)備采購管理，高值耗材等。我認為這兩點不能進行混合管理，也就是通過一個平臺來進行，主要原因是二者的業(yè)務流程區(qū)別很大，雖說涉及的多個管理部門都和后勤相關(guān)，但管理內(nèi)容包括醫(yī)療部分，醫(yī)療業(yè)務必有專業(yè)的醫(yī)療部門去管理，因此在智慧醫(yī)院的建設(shè)中應該區(qū)分開來建設(shè)。
3、在智慧醫(yī)院建設(shè)，如何提高醫(yī)療設(shè)備的智能化水平？
【問題描述】隨著“智慧醫(yī)院”建設(shè)的不斷推進，不少同行發(fā)現(xiàn)了在“智慧醫(yī)院”建設(shè)中，有一個瓶頸，那就是醫(yī)院整體缺少智能化的設(shè)備，無法滿足集中管理和分散控制的需求，達不到自動化智能控制照明，鍋爐，空調(diào)，除濕機等用電設(shè)備；無法分析環(huán)境、濕度等數(shù)據(jù)，造成設(shè)備過度運行能耗浪費情景，能耗巨大，延長壽命減短，環(huán)境不夠舒適智慧化。那么我的問題是：在“智慧醫(yī)院”建設(shè)，如何提高醫(yī)療設(shè)備的智能化水平？
劉東東軟集團IT技術(shù)咨詢顧問：
在智慧醫(yī)院建設(shè)中，提高醫(yī)療設(shè)備的智能化水平，并不是簡單的通過智能設(shè)備實現(xiàn)的，主要還得需要依靠智能化的管理系統(tǒng)。例如在問題中提到的自動化智能控制照明，鍋爐，空調(diào)，除濕機等用電設(shè)備，除了智能化設(shè)備以外，還需要智慧后勤管理系統(tǒng)，可以將這些設(shè)備統(tǒng)一的聯(lián)動起來，獲取運行數(shù)據(jù)，然后進行統(tǒng)一數(shù)據(jù)分析和管控。利用獲得的數(shù)據(jù)更好的利用這些智能設(shè)備，讓醫(yī)院更具智慧化。
spgoall和祐國際醫(yī)院信息管理部部長：
對于舊設(shè)備，無法提供運行狀態(tài)接口的，可以利用一些RFID等智能標簽做到設(shè)備定位和開關(guān)機時間的收集，對于新的設(shè)備，特別是即將要采購的設(shè)備則需要在需求里明確要開放運行狀態(tài)數(shù)據(jù)接口，或自帶的運行監(jiān)測系統(tǒng)開放接口給第三方平臺調(diào)用。有了數(shù)據(jù)才能做分析、預警。
4、在智慧醫(yī)院建設(shè)中如何提高智慧服務水平？
【問題描述】我院已經(jīng)實施建設(shè)了智慧醫(yī)院建設(shè)，應用一年多來，發(fā)現(xiàn)智慧服務水平有待提高，具體情況是，在智慧醫(yī)院應用過程中，患者掛號就診途徑多元化，對于患者，存在這樣的問題，初次就診沒有問題，我什么時候掛的號，什么時候去找相應醫(yī)生看病，智慧掛號都已準確到分了。但是在整個就診過程中存在患者重復等待情況，患者不滿意。如患者就診，要去檢查，因為做不到就診后，相應的檢查等著你去做，要排隊（患者不可能先回家等），做完檢查后，找醫(yī)生看，這時醫(yī)生在跟別的患者看病，并且這時還有其他患者等著看病，不可能讓你插隊先看你的檢查結(jié)果、診斷，因此這種情況下又要等待，多次重復等待，患者不滿意。那么，我的問題是，在智慧醫(yī)院建設(shè)中，如何解決這些問題？
劉東東軟集團IT技術(shù)咨詢顧問：
1、您提到的智慧服務水平提高主要是門診服務流程問題?；颊叩结t(yī)院就診體驗如果產(chǎn)生過多的排隊情況，往往就診體驗就不高。如何進行門診流程再造，優(yōu)化就診流程，構(gòu)建科學、規(guī)范、合理的就醫(yī)流程，改善患者就醫(yī)體驗，國內(nèi)大量的醫(yī)院也在進行積極的探索。
2、優(yōu)化患者就診流程和體驗除了信息化技術(shù)手段，還需要一定的流程優(yōu)化和管理制度的優(yōu)化。例如允許在新掛號患者之間按一定比例安排檢查后復查患者插隊，可以起到一定的作用。之前我去過一個醫(yī)院就默認2名新掛號患者+1復查患者+2+1這種自動的排隊模式。大家也都可以理解和接受。
3、另外，針對目前醫(yī)院存在患者排隊、等待、輾轉(zhuǎn)多次而造成的就醫(yī)體驗差，也可以應用技術(shù)手段設(shè)立統(tǒng)一的預約通道，設(shè)定患者沖突知識庫等，避免多次預約等問題。解決患者預約、排隊、等待、輾轉(zhuǎn)等問題，有效降低沖突，降低就醫(yī)成本，提升就醫(yī)滿意度。
5、智慧服務首先實現(xiàn)哪些項目效果更明顯？
gulx東軟集團股份有限公司軟件架構(gòu)師：
對目前排隊比較明顯的服務，比如：
患者建檔，預問診，方便醫(yī)生提前前了解患者癥狀，縮短看診時間；
預約掛號和預約檢查檢驗，減少患者排隊，注意事項重點通知；
患者費用管理，對接移動支付減少排隊，欠費催繳信息及時發(fā)送；
診療過程查看，包括檢查檢驗結(jié)果，病歷等，方便患者及時了解看診進度，以便安排復診時間；
基于物聯(lián)網(wǎng)的院內(nèi)導航業(yè)務。
三、智慧醫(yī)院解決方案的實施和部署
醫(yī)院信息化系統(tǒng)的建設(shè)離不開云架構(gòu)，為了讓醫(yī)院信息化系統(tǒng)更智慧，除了云架構(gòu)更需要考慮容器云平臺建設(shè)。在容器云平臺建設(shè)、實施和部署之前，需要對現(xiàn)有醫(yī)院業(yè)務系統(tǒng)進行梳理，哪些業(yè)務適合進行改造和適配，其次進行容器平臺的技術(shù)選型和建設(shè)完成部署，最后是對容器云的維護和DevOps建設(shè)。在容器平臺選型上可以考慮采用k8s開源架構(gòu)，但是要求這類醫(yī)院有較強的技術(shù)開發(fā)和自研能力，否則建議選用基于k8s的商用容器平臺，可以加速應用容器化實施落地，穩(wěn)定性和安全性也更高。
1、互聯(lián)網(wǎng)醫(yī)院的建設(shè)是智慧醫(yī)院建設(shè)的重要一環(huán)，如何搭建適合互聯(lián)網(wǎng)醫(yī)院的云架構(gòu)？
【問題描述】互聯(lián)網(wǎng)醫(yī)院的建設(shè)是智慧醫(yī)院建設(shè)的重要一環(huán)，如何搭建適合互聯(lián)網(wǎng)醫(yī)院的云架構(gòu)？是私有云還是混合云，如何劃分安全邊界，同時又能保證數(shù)據(jù)本地化存儲？最重要的是滿足互聯(lián)網(wǎng)醫(yī)院線上的應用擴展。
Sam_Zhu RedHat（Beijing）解決方案架構(gòu)師：
從目前趨勢看，傳統(tǒng)醫(yī)院云架構(gòu)體系建設(shè)應該是私有云為基礎(chǔ)，公有云為必要補充的混合云路線。核心業(yè)務系統(tǒng)和關(guān)鍵業(yè)務數(shù)據(jù)是在本地數(shù)據(jù)中心維護，同時充分利用共有云彈性計算資源搭建渠道應用和流程。數(shù)據(jù)下發(fā)和同步應通過標準的安全協(xié)議通道傳遞，啟用公有云環(huán)境中的數(shù)據(jù)加密功能，保障落地數(shù)據(jù)的安全性。封裝業(yè)務流程服務接口，調(diào)用通過統(tǒng)一的API網(wǎng)關(guān)把控安全和鏈路追蹤。安全建設(shè)是系統(tǒng)工程，沒有絕對的安全方案，私有云和公有云安全應該通盤規(guī)劃和設(shè)計。
jakeyyu某三甲醫(yī)院系統(tǒng)架構(gòu)師：
云架構(gòu)建設(shè)具有多種方式，私有云，公有云和混合云。針對該問題，一般情況下醫(yī)療機構(gòu)會根據(jù)自身的投資情況，大多會采用混合云和小規(guī)模私有云，混合云負責同互聯(lián)網(wǎng)互通，公共業(yè)務的服務都可以部署在上面，而核心業(yè)務數(shù)據(jù)庫等在自身的私有云上，形成內(nèi)部業(yè)務閉環(huán)。一般通過在邊界上放置防火墻，網(wǎng)閘等安全設(shè)備，數(shù)據(jù)通過業(yè)務接口程序單向傳遞。這樣對于互聯(lián)網(wǎng)醫(yī)院的應用擴展形成安全的架構(gòu)，既保證了數(shù)據(jù)的本地化存儲，也方便應用擴展，不足之處是對接口服務有一定的要求，此處處理不好，多數(shù)情況下會影響業(yè)務。
spgoall和祐國際醫(yī)院信息管理部部長：
目前互聯(lián)網(wǎng)醫(yī)院有兩種模式，一種是完全第三方平臺，Saas模式，另一種是自建或合作共建，本地私有化部署，這個問題應該是適用于第二種情況，這種情況實際上是要實現(xiàn)線上線下聯(lián)動的，最優(yōu)的做法是醫(yī)生端的電腦端是和業(yè)務HIS融合對接，這樣必然涉及到內(nèi)外網(wǎng)打通的問題，所以需要的是混合云架構(gòu)，需要界定出口防火墻DMZ的前置服務器和內(nèi)網(wǎng)HIS服務器的訪問策略以及和桌面終端的訪問策略，存儲肯定是存在內(nèi)網(wǎng)。
2、后疫情時代，互聯(lián)網(wǎng)＋醫(yī)療醫(yī)院數(shù)據(jù)中心與混合云如何建設(shè)？
【問題描述】后疫情時代，大型醫(yī)院數(shù)據(jù)中心該如何建，私有云有必要與公有云形成嚴格物理邊界嗎，是建軟件定義的數(shù)據(jù)中心還是傳統(tǒng)的呢？網(wǎng)絡(luò)安全如何同步考慮？
jakeyyu某三甲醫(yī)院系統(tǒng)架構(gòu)師：
就目前從安全角度出發(fā)，無論在什么應用環(huán)境下，目前的技術(shù)私有云和公有云的嚴格物理邊界是無法去掉的；其次對于醫(yī)療系統(tǒng)的數(shù)據(jù)中心建設(shè)我認為更應該繼續(xù)堅持以患者為中心的服務系統(tǒng)的建設(shè)，同時兼顧防疫的信息采集，數(shù)據(jù)中心的功能應該包括和政府防疫信息平臺的對接，這種應用場景業(yè)務在公有云上能夠更好的服務社會。根據(jù)實際的需要，基于軟件定義的數(shù)據(jù)中心和傳統(tǒng)數(shù)據(jù)中的建設(shè)都應考慮。
3、醫(yī)院集成平臺架構(gòu)和業(yè)務連續(xù)性問題？
【問題描述】問題一：新一輪的醫(yī)院互聯(lián)互通評審開始后，醫(yī)院信息科又遇到這樣的場景問題，基于SOA的架構(gòu)，由于歷史的原因，遇到評審也過后，但是無法真正的運行起來，原因有以下幾個方面的原因：
1.溝通與協(xié)作成本高：新系統(tǒng)迫于業(yè)務需求和市場壓力，急需上線，對負責的團隊而言，與周邊系統(tǒng)的對接和調(diào)試屬于外部不可控因素，團隊總是傾向于在內(nèi)部可控的范圍內(nèi)解決問題，因此會刻意避開對外部服務的依賴，選擇自建相關(guān)功能，這樣一來，系統(tǒng)間的交互會向著衰減的方向發(fā)展，重復建設(shè)也因此隨之蔓延；
2.組織架構(gòu)制約：團隊往往缺乏為響應其他系統(tǒng)的訴求而改造和升級自身服務的意愿，因為新系統(tǒng)與他們沒有直接的利益關(guān)系，醫(yī)院也缺乏適當?shù)莫剳蜋C制促使各團隊之間的積極協(xié)作，本質(zhì)上，這是組織架構(gòu)決定的；
3.缺乏長效機制：SOA改造常常是作為一個項目實施的，項目結(jié)束之后就不再有專門的組織和團隊對SOA架構(gòu)進行持續(xù)把控了，后續(xù)新的系統(tǒng)在融入SOA系統(tǒng)時受到的支持就減弱了，而新系統(tǒng)本身提供的服務也缺乏必要的梳理和管控，有的新系統(tǒng)甚至不對外提供服務。
我們在做五級互聯(lián)互通后，發(fā)現(xiàn)產(chǎn)品的架構(gòu)無法適應新的要求，希望專家給支支招。
問題二：有一次處理一個醫(yī)院故障事件，發(fā)現(xiàn)集成平臺存在著單點故障，雖然重啟服務后，解決了問題，但是給我們帶來了一個思考？
集成平臺選型時須考慮，支持熱備高可用性部署，主備機之間配置、消息庫可實時同步，當主機發(fā)生故障時，備機可在不需人工干預的情況下秒級自動啟動，消息在備機中繼續(xù)運行，當主機修復后，消息會轉(zhuǎn)回主機中繼續(xù)處理。
請專家講講，在冗余和集群服務中，如何考慮產(chǎn)品？
劉東東軟集團IT技術(shù)咨詢顧問：
解答問題一：
1、SOA架構(gòu)，是一種粗粒度、開放式、松耦合的服務結(jié)構(gòu)，要求軟件產(chǎn)品在開發(fā)過程中，按照相關(guān)的標準或協(xié)議，進行分層開發(fā)。
2、SOA體系架構(gòu)主要是業(yè)務驅(qū)動IT，SOA通過所謂粗粒度服務接口和分級，確實提高了效率。實現(xiàn)流程化以后，也確實簡化了開發(fā)難度。但是同時也給服務劃分帶來難題，如果說這個架構(gòu)不能符合醫(yī)院用戶的實際需求，也確實不合適。如果所有廠商都進行個性化開發(fā)，那么醫(yī)院業(yè)務系統(tǒng)就更難集成。
3、所以服務松耦合設(shè)計其實是一把雙刃劍，在帶來應變敏捷性的同時，也應該考慮類似的問題。
4、為了避免類似的問題出現(xiàn)，其實現(xiàn)在許多行業(yè)已經(jīng)從SOA架構(gòu)轉(zhuǎn)向了微服務架構(gòu)。
5、微服務架構(gòu)其實和SOA架構(gòu)類似,微服務主要是在SOA上做優(yōu)化，其特點是將業(yè)務系統(tǒng)進行組件化和服務化。原有的單個業(yè)務系統(tǒng)會拆分為多個可以獨立開發(fā)、設(shè)計、運行的小應用。這些小應用之間通過服務完成交互和集成。所以只要對這些組建進行維護就可以了，新的開發(fā)商需要什么組建、服務和能力，只要他提出了，再把服務給他就可以了?？梢愿斓膶崿F(xiàn)系統(tǒng)開發(fā)、上線和部署。同時避免SOA的諸多問題。
6、最后需要說明的一點微服務架構(gòu)在部署的同時還需要對現(xiàn)有基礎(chǔ)設(shè)施進行優(yōu)化，最好采用基于容器的云原生運行環(huán)境。
解答問題二：
集成平臺選型時可以同時考慮冗余和集群服務。
冗余機制通常是對集成平臺本身來說的，例如數(shù)據(jù)的冗余備份，集成平臺承載設(shè)備的自身部件的冗余配置。
集群服務機制通常是指多個節(jié)點同時提供服務，即使有一個節(jié)點發(fā)生故障，也不會影響業(yè)務的連續(xù)性。
實現(xiàn)集群服務通常的做法分為三個層次選擇產(chǎn)品。
1、數(shù)據(jù)庫層，例如采用ORACLE數(shù)據(jù)庫RAC群集，單個節(jié)點故障，并不會對其他節(jié)點產(chǎn)生影響。
2、虛擬化層，例如VMware虛擬機群集遷移，單個VM故障，業(yè)務也不會中斷。
3、例如云平臺或云原生平臺實現(xiàn)群集化部署，通常部署在云平臺或云原生平臺上的業(yè)務，都可以利用云平臺的相關(guān)群集策略和機制實現(xiàn)，可以避免單節(jié)點故障和停機。
Sam_Zhu RedHat（Beijing）解決方案架構(gòu)師：
傳統(tǒng)集成平臺架構(gòu)即便運用了主備高可用、多集群等技術(shù)手段，仍然是擺脫不了星型架構(gòu)的單點結(jié)構(gòu)。基于容器PaaS平臺的分布式敏捷集成已經(jīng)是此類總線系統(tǒng)的成熟替代方案，一來解決了大單體巨石應用的問題，二來解決了運維問題。
當然我們?nèi)匀豢梢詫⒍嘀行?、熱備等手段用于PaaS平臺節(jié)點和組件設(shè)施，但應用層面上的高可用和彈性伸縮已經(jīng)被平臺接管，我們充分利用基于KS8的容器編排技術(shù)，讓微服務化的容器集成應用“自維護”。
jakeyyu某三甲醫(yī)院系統(tǒng)架構(gòu)師：
目前大多數(shù)集成平臺都支持雙機冗余，或者是多機集群服務。以我們醫(yī)院為例，我們采取了雙機冗余的機制。當然，我們也曾經(jīng)遇到過上述的問題，也對平臺故障轉(zhuǎn)移的機制進行了思考。其實在醫(yī)院這種生產(chǎn)業(yè)務特點下，最大的需求是面臨快速的業(yè)務恢復，那么對于產(chǎn)品的選型，更應當傾向于備機的迅速接管業(yè)務的能力以及平臺上消息隊列的轉(zhuǎn)移。
4、醫(yī)院如果采用東軟信息化軟件產(chǎn)品，又采用紅帽的容器化平臺，相比其他醫(yī)院廠商，有哪些優(yōu)勢特點？
劉東東軟集團IT技術(shù)咨詢顧問：
首先，東軟醫(yī)療信息化軟件產(chǎn)品同時支持K8S開源容器云平臺和包括紅帽在內(nèi)的多種商業(yè)化容器云平臺。
采用紅帽容器化平臺的主要優(yōu)勢包括：
1、紅帽容器化平臺構(gòu)建于開源創(chuàng)新和行業(yè)標準的基礎(chǔ)上，包括K8S和紅帽企業(yè)Linux，是一個兼容開源標準的容器云平臺，可以完全兼容基于開源K8S的醫(yī)院容器化應用。
2、紅帽的容器化平臺對安全進行了增強，結(jié)合安全增強型Linux（SELinux）環(huán)境結(jié)合使用，更適合醫(yī)院用戶的多租戶環(huán)境。
3、紅帽的容器化平臺還提供了很多實用的工具和組件，可以輕松部署Web應用。通過支持持久性卷等功能，容器云平臺可以更好的支持醫(yī)院大量的有狀態(tài)應用。
4、紅帽的容器化平臺是一個完整的容器應用程序平臺，在性能、安全和穩(wěn)定性上可以更好的滿足醫(yī)院未來容器化的需求和應用。
jakeyyu某三甲醫(yī)院系統(tǒng)架構(gòu)師：
紅帽的技術(shù)基于OpenShift容器化技術(shù)，因此，除了保持有OpenShift自身的特點和優(yōu)勢外，也會融入紅帽和東軟的一些成熟技術(shù)特點。紅帽公司是全球知名的Linux平臺的技術(shù)廠家，東軟是國內(nèi)著名的軟件公司，二者結(jié)合應該在云原生系統(tǒng)的技術(shù)上具有一定的實力。
5、較高互聯(lián)互通要求HIS與平臺異構(gòu)，是否必須上兩個云？如果不必，怎樣證明異構(gòu)？
Sam_Zhu RedHat（Beijing）解決方案架構(gòu)師：
HIS的平臺無關(guān)性需要一個抽象層來保證，通過PaaS平臺來支撐這部分能力是一個主流方向。即在平臺選型中將對多云和混合云環(huán)境的支持作為重要的考核指標。這樣就可以達成一套系統(tǒng)跨不同云廠商環(huán)境跨區(qū)域部署，來滿足業(yè)務要求。
IT實踐中，未必是上兩個云，業(yè)務將來可能是要求上任意云，這一點對國際化的組織機構(gòu)來說尤為重要。
jakeyyu某三甲醫(yī)院系統(tǒng)架構(gòu)師：
從我的經(jīng)驗角度來講，HIS與平臺異構(gòu)要求HIS系統(tǒng)的架構(gòu)與支撐平臺架構(gòu)異構(gòu)，我們說在建設(shè)云平臺的時候首先要根據(jù)HIS的選型，如果是從頭開始建設(shè)，這樣會容易一些，HIS的選型可以結(jié)合云原生架構(gòu)來建設(shè)，這樣也可以只建設(shè)一個平臺，該平臺僅僅是對系統(tǒng)的支撐。如果是對已有的HIS系統(tǒng)進行改造，可以考慮獨立HIS建設(shè)新的平臺，并把HIS的部分業(yè)務遷移至新的平臺上。至于兩個云的問題，是根據(jù)實際情況而定，可以考慮建如果資金充足的話。
劉東東軟集團IT技術(shù)咨詢顧問：
HIS與平臺異構(gòu)不需要通過上兩個云來證明，也完全沒有必要。多個云不但不方便管理，還會造成資源浪費。
HIS與平臺指的是兩套技術(shù)路線和保障機制，不一定需要2套云環(huán)境，在建設(shè)之初需要規(guī)劃好。通常醫(yī)院HIS系統(tǒng)是最先建設(shè)的，那么在平臺建設(shè)時就需要考慮異構(gòu)問題，建議有興趣的話采用基于容器云技術(shù)的云原生架構(gòu)進行新的云平臺建設(shè)和支撐。因為新的云原生架構(gòu)可以支持容器化、DevOps化和微服務化等多種先進技術(shù)，同時也可以更好支持醫(yī)院未來的互聯(lián)互通。
四、容器云平臺的使用、安全和運維
容器云平臺對于醫(yī)療行業(yè)還是一個新興事物，還處于探索、研究和學習階段，需要更深入的了解。而且容器云平臺比以往任何的基礎(chǔ)架構(gòu)平臺更加的接近業(yè)務，同時容器云也包含了更多的層級和組件，因此也帶來了更多的風險。容器云平臺的好用嗎？安全和運維情況如何，這都是醫(yī)院用戶比較關(guān)注的問題。
1、OpenShift容器云平臺使用對醫(yī)院信息化人員的門檻如何？
Sam_Zhu RedHat（Beijing）解決方案架構(gòu)師：
我們可以了解到k8s和容器技術(shù)對傳統(tǒng)的信息從業(yè)者還是有比較高的學習門檻的?；卮疬@個問題的前提是下沒下決心上基于K8S的容器平臺。如果答案是“是”，那么OpenShift就是一款企業(yè)級的K8S容器平臺產(chǎn)品。它的產(chǎn)品定位就是讓用戶不用深入了解上述技術(shù)，就能快速和高效利用它帶來的優(yōu)勢。
OpenShift PaaS平臺面向兩方面用戶群體。一是開發(fā)人員，平臺提供工具（IDE--eclips風格和命令行--git風格）讓開發(fā)人員以自己熟悉的方式同OpenShift交互。二是運維人員，SRE工程師甚至不用登到操作系統(tǒng)后臺，通過管理控制臺就可擴展集群，升級和安裝新環(huán)境。因此，OpenShift最大限度地幫助我們的用戶降低了K8S和容器技術(shù)引入帶來的技術(shù)門檻。
jakeyyu某三甲醫(yī)院系統(tǒng)架構(gòu)師：
OpenShift對于醫(yī)院信息化人員具有一定的高要求，結(jié)合近些年三甲醫(yī)院信息化人員的引進多為應屆計算機相關(guān)專業(yè)碩士研究生，以及HIS廠家成熟的實施工程師和開發(fā)工程師，學歷高，技術(shù)起點也高，同時這類人員對于新技術(shù)的學習能力也較強，完全可以勝任openshift的開發(fā)使用。
2、如何保證容器本身的安全？
【問題描述】微服務化后，多了一層容器，安全復雜度增加，有無特別針對容器安全的工具或手段？
Sam_Zhu RedHat（Beijing）解決方案架構(gòu)師：
紅帽在OpenShift基礎(chǔ)組件之上，提供了高級集群安全管理模塊（stackrox），可以幫助用戶在鏡像安全和容器運行安全，以及提供基于AI的使用安全方面主動的安全加固建議和手段，這和普通的容器靜態(tài)安全檢測手段相比處于領(lǐng)先地位。
gulx東軟集團股份有限公司軟件架構(gòu)師：
1、從網(wǎng)絡(luò)上需要做到網(wǎng)絡(luò)劃分，需要將不同租戶之間的網(wǎng)絡(luò)進行隔離或者使用SR-IOV之類的網(wǎng)絡(luò)虛擬技術(shù)。
2、存儲加密，使用K8S CSI管理存儲卷的生命周期，將用戶與存儲架構(gòu)隔離。同時加密保護各個存儲卷，防止不安全訪問。
3.對于鏡像安全，可以所以用Aqua、Sysdig等工具對正在構(gòu)建的容器鏡像進行漏洞、程序包以及依賴包的掃描。
其次，應該有嚴格的準入控制策略，只允許通過組織簽過名的鏡像。
在運行中的容器可以使用AquaSysdig等工具進行事實監(jiān)控預防威脅。
3、云原生架構(gòu)的運維？
【問題描述】不是每個廠家系統(tǒng)都原生支持云原生的，當使用基于微服務、服務網(wǎng)格、無服務計算、物聯(lián)網(wǎng)、Kubernetes等云原生技術(shù)統(tǒng)一技術(shù)架構(gòu)，利用數(shù)據(jù)中臺提供的數(shù)據(jù)服務等這一系列的技術(shù)后，整體的運維又有誰來統(tǒng)一管理負責，尤其大多數(shù)廠商仍舊使用傳統(tǒng)操作系統(tǒng)加配置環(huán)境的情況下。
Sam_Zhu RedHat（Beijing）解決方案架構(gòu)師：
隨著DevOps理念和實踐在國內(nèi)的不斷發(fā)展，有將運維工作下放到開發(fā)團隊的趨勢，因為運維將面對是密集的容器而不是數(shù)量有限的虛機，根本管不過來。同時運維也開始做開發(fā)，公有云大行其道就是將基礎(chǔ)設(shè)施代碼化的最好體現(xiàn)。趨勢不可阻擋，所以運維需要逐步做好自動化體系建設(shè)，將運維能力開放給開發(fā)甚至業(yè)務部門，讓他們“自助服務”。運維將有限的精力放在對這些基礎(chǔ)設(shè)施的管控和環(huán)境治理方面，形成良性循環(huán)的局面。
gulx東軟集團股份有限公司軟件架構(gòu)師：
基于原生的Kubernetes系統(tǒng)進行運維確實會比較麻煩，因為大多數(shù)API的使用都是基于命令行或yaml配置，需要運維人員具備很高的技術(shù)水平和知識儲備。但如果使用云原生管理平臺類產(chǎn)品可以在一定程度上減輕運維的負擔，即由平臺統(tǒng)一提供多租戶、系統(tǒng)配置、管理、監(jiān)控和運維等圖形化界面，并且可以即時處理監(jiān)控告警等重大事件。平臺也能集成一定的優(yōu)化、故障處理方面的經(jīng)驗和專家能力，對平臺以及依托于平臺運行的應用的健康狀況提供合理化的處理建議等。
jakeyyu某三甲醫(yī)院系統(tǒng)架構(gòu)師：
我認為云原生架構(gòu)運維的核心點在兩點，一是運維人員的素質(zhì)，需要同時精通技術(shù)和業(yè)務的優(yōu)秀運維管理人員，第二是充分運用devops所需的技術(shù)和協(xié)作流程。既然企業(yè)要進行云原生的架構(gòu)的建設(shè)，必然要在這兩方面提前準備，同時在產(chǎn)品選型時要把握所選產(chǎn)品的技術(shù)特點，方便后期的運維，不能對市場的產(chǎn)品技術(shù)特點過于廣泛的關(guān)注，這樣會增加運維的難度。
4、如何讓廠家配合使用容器云平臺？
【問題描述】一個大型三甲醫(yī)院往往使用多個廠家的多個系統(tǒng)，是不是每個廠家都愿意使用，或者說是不是每個廠家都愿意配合使用是個很大的問題。尤其大多數(shù)系統(tǒng)都有自己定制的內(nèi)容，這些如何在容器化的時候?qū)崿F(xiàn)，由誰來實現(xiàn)？
Sam_Zhu RedHat（Beijing）解決方案架構(gòu)師：
推進醫(yī)院IT標準體系建設(shè)，建立準入機制，通過構(gòu)建統(tǒng)一的基礎(chǔ)平臺來倒逼廠家支持和兼容。醫(yī)院的不應該也不會在開發(fā)方面投入很多資源，集成廠商和軟件廠商應該滿足微服務化和容器化方面的要求。
5、醫(yī)院打造智慧醫(yī)療，那么云平臺方案應該如何設(shè)計能更好的保證安全性？
劉東東軟集團IT技術(shù)咨詢顧問：
云平臺的安全設(shè)計不僅注重技術(shù)安全，還應該更多的關(guān)注安全管理制度。嚴格遵循國家等級保護有關(guān)規(guī)定和標準規(guī)范要求，堅持管理和技術(shù)并重的原則，將技術(shù)措施和管理措施有機結(jié)合，建立信息系統(tǒng)綜合防護體系，提高信息系統(tǒng)整體安全保護能力。
1、技術(shù)安全方面。根據(jù)國家等保護標準進行建設(shè)，建議至少按照3級及以上標準建設(shè)。同時需要確定安全策略，并實施強制性的安全保護，使數(shù)據(jù)信息免遭非授權(quán)的泄露和破壞，提供較高安全的系統(tǒng)服務。
2、安全管理方面，需要建立完整的信息系統(tǒng)安全管理體系，對安全管理過程進行規(guī)范化的定義，并對過程執(zhí)行實施監(jiān)督和檢查。根據(jù)實際安全需求，建立安全管理機構(gòu)，配備專職安全管理人員，落實各級領(lǐng)導及相關(guān)人員的責任。
五、交流達成的共識總結(jié)
通過本場醫(yī)療同行的交流活動達成了一些交流共識如下，僅供參考：
（1）在智慧醫(yī)院的業(yè)務場景驅(qū)動下，醫(yī)院正在逐漸轉(zhuǎn)變現(xiàn)有的技術(shù)架構(gòu)和業(yè)務架構(gòu)以快速適應這種變化。醫(yī)院的信息化架構(gòu)也越來越互聯(lián)網(wǎng)化。
（2）醫(yī)院有意愿基于微服務架構(gòu)對原有醫(yī)院的應用系統(tǒng)進行業(yè)務拆分和改造，部署在以業(yè)務為中心、低耦合、高度自治、高彈性和自動化的容器云平臺上，這將成為未來醫(yī)院的主流技術(shù)架構(gòu)。
（3）醫(yī)院的傳統(tǒng)核心應用系統(tǒng)、集成平臺和智慧醫(yī)院業(yè)務都依賴云平臺的建設(shè)，而醫(yī)院目前云平臺的基礎(chǔ)設(shè)施建設(shè)能力不足，難以適應新興業(yè)務的靈活性和快速響應能力、部署能力和開發(fā)能力的要求。
（4）在容器云的技術(shù)選型方面，不同于其他行業(yè)，醫(yī)院普遍自研能力不足，應該首選基于k8s的商用容器平臺，可以加速應用容器化實施落地，穩(wěn)定性和安全性也更高。
（5）容器云平臺對于醫(yī)療行業(yè)還處于起步階段，對于容器云平臺的使用、安裝、部署和運維管理還缺乏足夠的認識和信心。
