基于微服務(wù)架構(gòu)的醫(yī)院統(tǒng)一接入平臺設(shè)計與應(yīng)用

廈門大學附屬東南醫(yī)院 信息科，福建 漳州 363000

引言

2017年6月1日《網(wǎng)絡(luò)安全法》[1]實施后，“互聯(lián)網(wǎng)+醫(yī)療”的信息安全越發(fā)重要。當前信息系統(tǒng)已成為醫(yī)院各部門業(yè)務(wù)開展的必備工具，是實現(xiàn)醫(yī)院現(xiàn)代化運營的重要手段，但若信息安全出現(xiàn)問題，小則影響醫(yī)院業(yè)務(wù)開展甚至停擺，大則影響社會安定，加強醫(yī)院信息安全建設(shè)勢在必行[2-3]。在信息技術(shù)迅猛發(fā)展大背景下，醫(yī)院內(nèi)部的應(yīng)用系統(tǒng)越來越多，這些系統(tǒng)互相獨立，每個系統(tǒng)都需要識別用戶的身份和授權(quán)認證，帶來用戶信息冗余、不同步等問題，長期下來，用戶需要記住的用戶名和口令越來越多，嚴重影響了工作效率，使得管理員在對人員系統(tǒng)授權(quán)的分配容易造成混亂，造成重要數(shù)據(jù)泄漏。而且醫(yī)院大部分接口基于早期的數(shù)據(jù)庫存儲過程實現(xiàn)，隨著越來越多第三方系統(tǒng)的接入，數(shù)據(jù)庫接口錯綜復雜，長期下來，重復性對接工作越來越復雜，加上人員的崗位變動，沒有形成一套完整的接口體系，且數(shù)據(jù)庫存儲過程難以調(diào)試，可移植性差，可讀性及維護性差，數(shù)據(jù)接口管理存在無法監(jiān)控、權(quán)限數(shù)據(jù)混亂等問題，在數(shù)據(jù)安全上存在很大的風險。

1 設(shè)計思路

傳統(tǒng)醫(yī)院現(xiàn)有的系統(tǒng)架構(gòu)有C/S（Client/Server）兩層架、C/S/S（Client/Server/Server）三層架構(gòu)、B/S/S（Browser/Server/Server）三層架構(gòu)，本平臺以O(shè)Auth 2.0協(xié)議建立統(tǒng)一的認證授權(quán)中心。OAuth 2.0在當前互聯(lián)網(wǎng)統(tǒng)一認證授權(quán)中應(yīng)用最為廣泛，目前各大APP、網(wǎng)站，如微信、支付寶、微博等，都用OAuth 2.0作為統(tǒng)一認證協(xié)議。OAuth 2.0有四種授權(quán)模式，本文主要采用授權(quán)碼模式（Authorization Code）和密碼模式（Resource Owner Password Credentials）及客戶端模式（Client Credentials）三種模式[4-7]，通過對醫(yī)院不同的系統(tǒng)架構(gòu)進行分析，采用不同OAuth 2.0授權(quán)模式與本平臺對接，實現(xiàn)統(tǒng)一的用戶授權(quán)認證和接口授權(quán)認證。

1.1 平臺用戶授權(quán)

1.1.1 C/S兩層架構(gòu)

醫(yī)院信息系統(tǒng)包括門診醫(yī)生站、檢查檢驗系統(tǒng)、PACS等都采用了該架構(gòu)，該架構(gòu)特點是客戶端與數(shù)據(jù)庫服務(wù)器直接相連，不需要經(jīng)過中間層服務(wù)器的處理，所以響應(yīng)速度較快，但由于客戶端與數(shù)據(jù)庫服務(wù)器的關(guān)聯(lián)性使得安全隱患無法有效避免，導致數(shù)據(jù)安全存在很大的風險。因此在與平臺對接時，對用戶數(shù)據(jù)庫登錄信息加密，把用戶登錄系統(tǒng)的信息與數(shù)據(jù)庫登錄信息完全分離。本文采用了OAuth 2.0中的密碼模式，如圖1所示，用戶通過登錄統(tǒng)一認證平臺，平臺認證后返回給客戶端該用戶加密[8]后的信息（HIS、LIS用戶名密碼及相關(guān)的資源信息），客戶端根據(jù)此信息解密后登錄到相關(guān)的數(shù)據(jù)庫服務(wù)器。

圖1 平臺與C/S兩層架構(gòu)系統(tǒng)的授權(quán)認證過程

1.1.2 C/S/S三層架構(gòu)

醫(yī)院信息系統(tǒng)包括醫(yī)護一體化、護理文書等采用了該架構(gòu)，該架構(gòu)是客戶端-服務(wù)端-數(shù)據(jù)庫，與傳統(tǒng)的兩層結(jié)構(gòu)相比，加了一個中間應(yīng)用服務(wù)器。將業(yè)務(wù)邏輯在應(yīng)用服務(wù)器上處理，減少了客戶端的壓力，本文采用了OAuth 2.0中的密碼模式，如圖2所示，以平臺作為橋梁，客戶端登錄請求平臺，平臺認證返回token，客戶端帶著token與服務(wù)端實現(xiàn)交互，服務(wù)端通過token從平臺獲取用戶相關(guān)信息。實現(xiàn)客戶端與服務(wù)端用戶的認證及信息的獲取，解決了一個賬號多點登錄。

圖2 平臺與C/S三層架構(gòu)系統(tǒng)的授權(quán)認證過程

1.1.3 B/S/S三層架構(gòu)

醫(yī)院信息系統(tǒng)包括辦公化自動化系統(tǒng)、微醫(yī)療、預(yù)約平臺等Web系統(tǒng)采用了該架構(gòu)，該架構(gòu)是瀏覽器-服務(wù)端-數(shù)據(jù)庫，只需要通過瀏覽器就可以使用，解決了系統(tǒng)安裝及更新存在的復雜性問題，本文采用OAuth 2.0中的授權(quán)碼模式，如圖3所示，瀏覽器登錄請求服務(wù)端，服務(wù)端通過請求到平臺，平臺返回授權(quán)碼，服務(wù)端通過授權(quán)碼獲取token，服務(wù)端通過token從平臺獲取用戶相關(guān)信息。該架構(gòu)所有應(yīng)用系統(tǒng)接入平臺后，可配置在平臺中，即可實現(xiàn)一次登錄，訪問授權(quán)過的應(yīng)用系統(tǒng)。

圖3 平臺與B/S/S三層架構(gòu)系統(tǒng)的授權(quán)認證過程

1.2 平臺數(shù)據(jù)接口授權(quán)

針對醫(yī)院大部分接口采用存儲過程維護性差、不宜管理且易出現(xiàn)安全問題等現(xiàn)狀，對醫(yī)院的現(xiàn)有接口進行改造。以平臺的標準化開發(fā)，通過統(tǒng)一接入本平臺，實現(xiàn)統(tǒng)一的接口授權(quán)管理，第三方只需要通過平臺分配的授權(quán)機制及調(diào)用參數(shù)，即可實現(xiàn)接入調(diào)用所需要的醫(yī)院信息數(shù)據(jù)。本文采用OAuth 2.0中客戶端模式，如圖4所示，第三方系統(tǒng)通過參數(shù)請求token，根據(jù)token去調(diào)用相關(guān)的授權(quán)接口。

圖4 平臺與第三方服務(wù)數(shù)據(jù)接口的授權(quán)認證過程

2 平臺建設(shè)與功能介紹

本平臺是面向醫(yī)院信息化標準的統(tǒng)一入口，肩負起支撐整個醫(yī)院核心數(shù)據(jù)的調(diào)度，對于平臺的建設(shè)，本文采用基于微服務(wù)架構(gòu)的實現(xiàn)方式[9-10]。如圖5所示，當?shù)谌较到y(tǒng)請求平臺時，通過Spring Cloud Gateway將請求動態(tài)轉(zhuǎn)發(fā)到內(nèi)部服務(wù)，網(wǎng)關(guān)接收到請求后，從注冊中心Consul[11]獲取可用服務(wù)，由Ribbon進行均衡負載后，分發(fā)到各個服務(wù)，首先進入了OAuth 2.0授權(quán)服務(wù)，認證第三方是否有獲取數(shù)據(jù)的權(quán)限[12]，認證通過后使用Feign調(diào)用相應(yīng)的醫(yī)療服務(wù)接口。服務(wù)集群通過Spring Cloud Config、Spring Cloud Bus、RabbitMQ實現(xiàn)通訊及配置更新。隨著服務(wù)的越來越多，對服務(wù)間調(diào)用的分析會越來越復雜，本平臺使用Spring Cloud Sleuth和Zipkin對這些信息進行監(jiān)控采集，為服務(wù)之間調(diào)用提供鏈路追蹤，方便對系統(tǒng)問題的實時監(jiān)控。同時加入了Hystrix進行容錯保護，防止基礎(chǔ)服務(wù)的故障可能導致的級聯(lián)故障[13]。在部署上，使用docker部署微服務(wù)[14-15]，為后期系統(tǒng)運營維護部署節(jié)約了巨大的成本，開發(fā)人員只需要關(guān)注業(yè)務(wù)模塊，根據(jù)系統(tǒng)提供的開發(fā)布署文檔，即可輕松開發(fā)自己熟悉的業(yè)務(wù)。

圖5 醫(yī)院統(tǒng)一接入平臺微服務(wù)架構(gòu)

根據(jù)上述的設(shè)計思路，OAuth 2.0授權(quán)服務(wù)主要提供用戶及接口授權(quán)認證。該服務(wù)將不同架構(gòu)的醫(yī)院信息化系統(tǒng)中的用戶登錄模塊通過OAuth 2.0協(xié)議整合到平臺中， 用戶不需要記住原來各個系統(tǒng)中的用戶名密碼，通過平臺分配的用戶名密碼登錄到平臺，即可訪問平臺授權(quán)的接入系統(tǒng)。接入系統(tǒng)從平臺獲取相應(yīng)的如用戶id、姓名、科室、職位等用戶信息關(guān)聯(lián)到相應(yīng)的接入系統(tǒng)表里，解決了接入系統(tǒng)內(nèi)部的菜單權(quán)限；醫(yī)療服務(wù)接口主要提供醫(yī)院數(shù)據(jù)接口服務(wù)，通過對醫(yī)院各個系統(tǒng)原有存儲過程的分類整理，改造成符合平臺的接口模式，劃分到各個不同的業(yè)務(wù)模塊，部署到平臺集群服務(wù)中。如圖6所示，如門診集群服務(wù)，服務(wù)中包括各種相關(guān)業(yè)務(wù)的接口，如獲取患者信息接口、獲取門診預(yù)交金余額等接口。管理員通過平臺對第三方系統(tǒng)授權(quán)相關(guān)接口配置，第三方系統(tǒng)即可調(diào)用相關(guān)的醫(yī)療數(shù)據(jù)。

圖6 接口授權(quán)配置

根據(jù)以上對平臺設(shè)計思路的分析和架構(gòu)設(shè)計，設(shè)計出平臺的主要功能，如圖7所示。

圖7 平臺功能介紹

2.1 系統(tǒng)管理

為實現(xiàn)系統(tǒng)基本管理信息的維護，系統(tǒng)用戶可關(guān)聯(lián)HIS用戶，在用戶授權(quán)調(diào)用時提供數(shù)據(jù)庫登錄信息。

2.2 授權(quán)接入管理

主要提供對第三方的OAuth 2.0授權(quán)配置，對用戶授權(quán)和接口授權(quán)，第三方只需要根據(jù)系統(tǒng)分配的參數(shù)及調(diào)用文檔，即可調(diào)用用戶認證和授權(quán)接口，該功能可提供給第三方開發(fā)人調(diào)試，且僅提供測試數(shù)據(jù)。

2.3 接口管理

在設(shè)計上主要針對醫(yī)院各個業(yè)務(wù)的模塊拆分[16]，醫(yī)院信息系統(tǒng)主要涉及門診、住院、收費、檢查、檢驗等，根據(jù)這些系統(tǒng)拆分成若干個服務(wù)，如醫(yī)護患者信息、門診收費信息、醫(yī)護排班、預(yù)約掛號、就診取藥、住院收費信息、住院信息、檢查信息、檢驗信息、問卷調(diào)查等服務(wù)，服務(wù)中又包括若干個接口，開發(fā)人員只需要根據(jù)系統(tǒng)的標準開發(fā)服務(wù)，服務(wù)會自動集成到相應(yīng)的業(yè)務(wù)集群中，同時在該功能配置相應(yīng)的接口信息，供接口授權(quán)調(diào)用。

2.4 監(jiān)控管理

主要針對系統(tǒng)的服務(wù)、熔斷、鏈路、數(shù)據(jù)庫連接池進行實時監(jiān)控。

2.5 服務(wù)治理

內(nèi)嵌Consul自帶的Web管理界面，可以看到各節(jié)點服務(wù)的信息，便于運維人員對服務(wù)節(jié)點的管理。

3 應(yīng)用效果

統(tǒng)一接入平臺通過建立統(tǒng)一的授權(quán)認證及接口管理規(guī)范平臺，為醫(yī)院提供統(tǒng)一數(shù)據(jù)接口接入，簡化應(yīng)用系統(tǒng)操作過程，提高了內(nèi)部數(shù)據(jù)的安全性。

在該平臺使用之前，醫(yī)院每個系統(tǒng)獨立運行，用戶每天需要重復的登錄工作，時間久了，用戶名密碼容易混淆，管理員對新用戶賬號分配或離職人員賬號回收，需要在多個系統(tǒng)上進行配置，不僅工作量大，而且容易發(fā)生錯誤。同時對于各個系統(tǒng)對應(yīng)的存儲過程接口很多，重復且不規(guī)范，新系統(tǒng)接入時還需要重復性的編寫存儲過程，長期下來導致數(shù)據(jù)接口管理不規(guī)范且容易造成重要的數(shù)據(jù)泄漏。使用統(tǒng)一接入平臺后，已有運維管理系統(tǒng)、辦公自動化系統(tǒng)、微醫(yī)療、門診預(yù)約系統(tǒng)、決策輔助支持系統(tǒng)等接入平臺并通過平臺獲取醫(yī)療數(shù)據(jù)。

對比系統(tǒng)使用前后，用戶每天在登錄系統(tǒng)上的時間比原來縮短70%，大大提高了工作效率，管理員在對系統(tǒng)人員授權(quán)操作時間平均縮短90%，大大降低人員賬號管理成本；對于系統(tǒng)開發(fā)人員，只需要通過平臺文檔及相關(guān)配置，即可從平臺獲取相應(yīng)的數(shù)據(jù)，簡化了開發(fā)流程。后續(xù)隨著更多的系統(tǒng)接入及接口完善，管理員對醫(yī)療數(shù)據(jù)接口的治理將更加方便，第三方系統(tǒng)將不再與數(shù)據(jù)庫直接關(guān)聯(lián)。每個系統(tǒng)的接入調(diào)用，都有實時的日志記錄，通過對日志記錄的分析，可監(jiān)控是否有可疑的系統(tǒng)接入，從源頭上保障了醫(yī)療數(shù)據(jù)泄漏的安全。

4 總結(jié)

隨著醫(yī)療信息化的不斷深入，保障信息安全已成為當今最重要的話題，由于醫(yī)院信息系統(tǒng)多套系統(tǒng)并存、開發(fā)維護復雜、業(yè)務(wù)邏輯和數(shù)據(jù)應(yīng)用不合理、安全性得不到保證，使得在數(shù)字化醫(yī)院集成改造過程中，困難重重。要克服和避免這些問題，需要更加合理的系統(tǒng)架構(gòu)。基于全局的設(shè)計和先進的理念，醫(yī)院統(tǒng)一接入平臺，在原有基礎(chǔ)上改造的同時，對相關(guān)的業(yè)務(wù)進行整合，解決了一個賬號登錄多個系統(tǒng)，統(tǒng)一了接口的管理及接入，不僅為醫(yī)院信息化安全提供保障，而且為后續(xù)醫(yī)院信息化建設(shè)打下了堅實的基礎(chǔ)。目前系統(tǒng)也在不斷完善中，最主要的是與院內(nèi)系統(tǒng)的改造及數(shù)據(jù)接口遷移還不全面，各個系統(tǒng)的接入需要隨著時間對接測試，形成醫(yī)院內(nèi)部統(tǒng)一的標準和規(guī)范。