袁 靜 張 敏 馮 剛 代里嘉 李 暄

1 成都市第三人民醫(yī)院，成都，610031；2 成都醫(yī)學院人文信息管理學院，成都，610500

從近年來醫(yī)聯(lián)體運行和分級診療的實施現(xiàn)狀來看，各級醫(yī)療機構之間缺乏滿足實際使用需求的信息共享平臺，其具有各自獨立的信息系統(tǒng)，僅通過遠程手段實現(xiàn)特定業(yè)務領域的交互。醫(yī)療信息難以互聯(lián)互通的原因主要有不同層級的醫(yī)療機構信息化投入及建設水平差異大[1]、各自所擁有數(shù)據(jù)結(jié)構與標準不統(tǒng)一；另一方面，不同層級的醫(yī)療機構的服務能力不均等、醫(yī)療行為規(guī)范程度不統(tǒng)一，難以保障醫(yī)療數(shù)據(jù)質(zhì)量的一致性。因此，本研究將重點分析如何運用先進的信息化技術和一體化質(zhì)量管理方法實現(xiàn)不同層級的醫(yī)療機構的互聯(lián)互通。

1 關鍵技術研究

1.1 微服務架構研究

微服務架構是近年來提出的一種軟件架構模型，其設計思想是將應用劃分為多個細粒度的服務，每個服務提供單一的業(yè)務功能，并運行于獨立的進程中。微服務之間采用輕量級的通信機制進行交互，配合實現(xiàn)完整的應用功能。

當微服務架構在互聯(lián)網(wǎng)行業(yè)應用得如火如荼之時，絕大多數(shù)醫(yī)療信息系統(tǒng)仍采用單體架構模式，此類架構系統(tǒng)通常作為一個整體編譯、安裝和部署，并通過數(shù)據(jù)庫實現(xiàn)子模塊間的通信。隨著醫(yī)療信息業(yè)務快速增長，單體架構已很難適應需求的快速變化，這類應用會面臨開發(fā)效率低、實施周期長、運維成本高等多重挑戰(zhàn)。微服務架構則可以解決傳統(tǒng)架構模式帶來的上述問題，具備更好的靈活性、擴展性、高可用性等。

1.2 容器云技術選型

盡管微服務架構帶來了許多優(yōu)勢，但構建、部署和維護分布式的微服務系統(tǒng)并不輕松。容器提供的輕量級、應用隔離的虛擬化運行環(huán)境為微服務解決了這些難題。目前的主流技術是將微服務打包進容器進行獨立的部署與擴展，實現(xiàn)其隔離性和移動性[2]。具備高性能、部署快、易遷移等優(yōu)勢的容器云技術正在被市場廣泛采納[3]。

Docker是一種新興的虛擬化容器技術，與傳統(tǒng)的虛擬化方式相比，容器消耗更少的硬件資源[4]，啟動更快。Kubernetes是一個基于Docker虛擬化技術的集群管理系統(tǒng)。Kubernetes能夠管理容器化的應用程序，提供資源調(diào)度、服務發(fā)現(xiàn)、彈性伸縮以及部署運行等重要功能[5]。根據(jù)CNCF(云原生計算基金會)于2018年8月發(fā)布的全球市場半年度調(diào)查，截止2018年7月，在生產(chǎn)環(huán)境中運用容器技術的受訪者達到了73%，其中采用Kubernetes作為容器管理平臺的達到了83%，Kubernetes已經(jīng)成為容器云平臺的事實標準。

1.3 臨床路徑應用效果研究與分析

以成都市某醫(yī)院為例，目前該醫(yī)院已建設臨床路徑管理系統(tǒng)，實現(xiàn)醫(yī)療服務診療護理常規(guī)的標準化。從實施效果來看，在院臨床路徑患者比例為43.54%；在院臨床路徑患者病種人數(shù)前三的分別為脊柱側(cè)彎、慢性阻塞性肺疾病、不穩(wěn)定性心絞痛介入治療。臨床路徑系統(tǒng)的逐步推進，有效地避免過度治療的現(xiàn)象，有力地規(guī)范醫(yī)療行為，為患者提供更為優(yōu)質(zhì)的服務。然而，臨床路徑的實施也需要先進的信息技術作支撐，與HIS、電子病歷等信息系統(tǒng)有機融合，利于臨床路徑的全面推開使用，更好地保障醫(yī)療服務質(zhì)量安全[6]。

因此，將臨床路徑作為醫(yī)聯(lián)體信息平臺建設的診療質(zhì)量抓手，有效推進分級診療業(yè)務的高度協(xié)同、避免醫(yī)保費用浪費，促進區(qū)域整體醫(yī)療服務能力的提升。

綜上所述，本研究可以基于新型的微服務架構[7]，結(jié)合Docker虛擬化技術和Kubernetes容器編排引擎[8-9]，以臨床路徑為診療質(zhì)量抓手，進行醫(yī)聯(lián)體云平臺的創(chuàng)新研究與設計。

2 醫(yī)聯(lián)體應用模式與體系構建

實現(xiàn)互聯(lián)互通，最理想的模式是各級醫(yī)療機構在遵循統(tǒng)一的數(shù)據(jù)格式標準與通信協(xié)議規(guī)范的基礎上建立信息集成平臺。首先將院內(nèi)的各個信息系統(tǒng)通過企業(yè)服務總線方式進行連接，打破院內(nèi)信息系統(tǒng)的孤島現(xiàn)象；隨后，醫(yī)聯(lián)體的醫(yī)療機構之間再通過信息集成平臺達到互聯(lián)互通。但是構建信息集成平臺的成本較高，實施周期較長，目前國內(nèi)只有少數(shù)的醫(yī)療機構完成了信息化集成平臺建設。因此，需要創(chuàng)建可為醫(yī)聯(lián)體、醫(yī)療機構、從業(yè)人員、普通居民提供基礎普適性服務的容器云醫(yī)療平臺(以下簡稱為“平臺”)。平臺本身具備直接為上述各級用戶提供應用、數(shù)據(jù)等服務的能力，同時還具備功能可擴展、數(shù)據(jù)可共享、信息可交互的特質(zhì)?；卺t(yī)聯(lián)體的應用以微服務的方式進行實現(xiàn)，都會被容器化并且部署在基于Kubernetes構建的云化集群上，應用的部署和資源調(diào)度由容器云醫(yī)療平臺進行控制和管理。其中，微服務實現(xiàn)各自具體的業(yè)務，分別選取適合的技術方案并獨立進行部署，為大型單體架構所遇到的問題提供了新的解決方案[10]。

醫(yī)聯(lián)體管理體系以容器云醫(yī)療平臺為核心，形成管理中心、公共服務、運行機制等服務為一體的管理體系，其架構構建如圖1所示。

醫(yī)聯(lián)體管理體系針對區(qū)域內(nèi)疾病譜和重點疾病診療需求，以大數(shù)據(jù)、臨床路徑等手段促進優(yōu)勢?？乒步?、醫(yī)療質(zhì)控管理、臨床路徑運用、科研協(xié)作等醫(yī)療活動，促進優(yōu)質(zhì)醫(yī)療資源共享，實現(xiàn)區(qū)域醫(yī)療信息互聯(lián)互通。

在實現(xiàn)方式上，對于醫(yī)聯(lián)體中的牽頭醫(yī)院與樞紐醫(yī)院可先建設醫(yī)院的信息集成平臺，將院內(nèi)已有的各信息系統(tǒng)互聯(lián)互通后再與醫(yī)聯(lián)體管理體系連接；對于醫(yī)聯(lián)體中信息化建設滯后的醫(yī)院，可直接從容器云平臺中獲取到其所需的醫(yī)聯(lián)體應用服務，然后通過院內(nèi)輕量級的ESB集成平臺與醫(yī)聯(lián)體管理體系聯(lián)通。通過容器云的醫(yī)聯(lián)體平臺各醫(yī)聯(lián)體單位無需進行重復建設就可享受大規(guī)模、高擴展性、同質(zhì)化、便捷低成本的信息化和數(shù)據(jù)存儲服務，可以像“買水”、“買電”一樣購買IT資源。

圖1 醫(yī)聯(lián)體管理體系構建圖

以臨床路徑系統(tǒng)為例，如果各醫(yī)聯(lián)體成員單位自擁有獨立的臨床路徑系統(tǒng)，會造成建設周期較長、建設質(zhì)量不一致、管理困難等問題。若將牽頭醫(yī)院建設成熟且應用效果較好的臨床路徑系統(tǒng)進行微服務化，醫(yī)聯(lián)體單位可以從容器云平臺獲取其所需的服務，并通過醫(yī)聯(lián)體路床路徑管理中心進行路徑表單管理、通信管理與質(zhì)量監(jiān)控。

3 容器云醫(yī)療平臺技術架構

3.1 平臺技術方案

在容器云醫(yī)療平臺上實現(xiàn)對各級醫(yī)療服務細節(jié)深度的定制，平臺使用者可以根據(jù)自身業(yè)務要求，深度定制業(yè)務模塊，打破現(xiàn)有軟件的壁壘，重組自身功能需求，以促進各級醫(yī)院、各?？频目焖侔l(fā)展。

平臺由前端和服務器端兩部分組成，其中前端支持在計算機、手機等系統(tǒng)上運行，是直接面向用戶的組成部分，其采用RESTful開發(fā)風格，使用jQuery、Ajax等開發(fā)技術強化效果，提高用戶體驗；前端與服務器端使用JSON數(shù)據(jù)格式進行交互。平臺技術架構如圖2所示。

平臺采用Spring Cloud作為微服務框架，為開發(fā)人員提供了穩(wěn)定易用的分布式系統(tǒng)開發(fā)框架。平臺包括注冊中心、服務發(fā)現(xiàn)、負載均衡、動態(tài)路由、服務監(jiān)控、統(tǒng)一配置等完整的服務質(zhì)量治理生態(tài)組件。平臺使用Docker虛擬化技術將物理層資源整合為資源池，采用容器編排工具Kubernetes搭建集群，管理為醫(yī)聯(lián)體微服務應用運行所需的彈性集群。

基于醫(yī)聯(lián)體應用的微服務主要包括醫(yī)聯(lián)體就診服務、遠程服務(遠程視頻、遠程影像、遠程心電等)、雙向轉(zhuǎn)診服務、檢查服務、檢驗服務、協(xié)同會診服務、慢病診療服務、醫(yī)聯(lián)體質(zhì)量監(jiān)管服務。其中，醫(yī)聯(lián)體質(zhì)量監(jiān)管服務以臨床路徑為核心，選取幾種常見病、多發(fā)病為試點病種，實現(xiàn)對診療流程、病人管理、醫(yī)囑內(nèi)容的同質(zhì)化服務[11]。

3.2 信息安全對策

醫(yī)聯(lián)體容器云平臺的安全性設計需滿足以下原則：(1)所有數(shù)字化的醫(yī)療信息應根據(jù)所有者的角色和權限進行不同強度的加密，保證其訪問、傳輸與存儲的安全性；(2)對電子病歷、健康檔案等涉及患者隱私的信息保護；(3)保障云平臺自身的安全性，使其具備防攻擊、抗毀和數(shù)據(jù)防丟失等能力。

為此，平臺提供了隱私保護、安全防護、集群監(jiān)控、數(shù)據(jù)加密、身份認證、鏈路跟蹤、監(jiān)測預警等基礎組件。主要采用國產(chǎn)密碼算法(SM2、SM3、SM4等)、對密鑰的生成、協(xié)商、更新、銷毀進行全生命周期管理等機制，實現(xiàn)關鍵數(shù)據(jù)和敏感數(shù)據(jù)的加密傳輸和存儲。利用模式識別算法實現(xiàn)患者數(shù)據(jù)去標識化，保障病人的隱私數(shù)據(jù)在信息共享中不被泄露。

圖2 容器云醫(yī)療平臺技術架構

4 討論

4.1 應用模型體系風險分析

容器云式的微服務模式能提高各單項業(yè)務服務本身的運行效率和擴展性，同時也帶來了諸多挑戰(zhàn)。隨著各項服務之間通信接口的增多,這些通信接口的穩(wěn)定性將會成為影響整體業(yè)務運行穩(wěn)定性的關鍵因素。微服務之間通過同步通信接口或異步消息進行通信，并且具備分布式系統(tǒng)特征，因此需要考慮網(wǎng)絡傳輸?shù)牟豢煽啃?、消息序列化、異步、容錯、兼容性等問題，應在系統(tǒng)設計層面有一個完整的機制保障微服務長期穩(wěn)定的運行。

4.2 解決對策

首先，設計者必須深入理解和分析醫(yī)聯(lián)體業(yè)務的實際需求，對服務的業(yè)務邊界進行明確的劃分。由于一個劃分不成熟的微服務系統(tǒng)可能會在應用中為了保證數(shù)據(jù)一致性而導致分布式鎖的出現(xiàn)，進而導致系統(tǒng)復雜度急劇上升。建議可采取領域驅(qū)動設計方法(Domain-driven Design)，以業(yè)務模型為切入，并通過合理運用聚合、工廠、實體等設計要素，使業(yè)務系統(tǒng)的復雜度降低，擴展性增強[12]。拆分后的服務應包含單一的界限上下文，對于特定的模塊或功能,對外提供的接口滿足唯一性原則。

其次，微服務間的通信機制必須完備可靠，服務之間的通信選擇應盡量單一，業(yè)務之間的通信要按需選用。對于高吞吐量的業(yè)務應用選擇異步通信的消息中間件，如Apache Kafka；而對于消息可靠性要求高的業(yè)務應用選擇同步通信模式，如RESTful。在設計微服務間的通信協(xié)議時，需要重點對每個服務的接口標識，接口升級的兼容性以及通信異常狀態(tài)處理進行周全的考慮與設計。