袁 靜 張 敏 馮 剛 代里嘉 李 暄

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

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

1 關(guān)鍵技術(shù)研究

1.1 微服務(wù)架構(gòu)研究

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

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

1.2 容器云技術(shù)選型

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

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

1.3 臨床路徑應(yīng)用效果研究與分析

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

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

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

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

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

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

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

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

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

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

3 容器云醫(yī)療平臺(tái)技術(shù)架構(gòu)

3.1 平臺(tái)技術(shù)方案

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

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

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

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

3.2 信息安全對策

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

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

圖2 容器云醫(yī)療平臺(tái)技術(shù)架構(gòu)

4 討論

4.1 應(yīng)用模型體系風(fēng)險(xiǎn)分析

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

4.2 解決對策

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

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