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

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

引言

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

1 設(shè)計(jì)思路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖7 平臺(tái)功能介紹

2.1 系統(tǒng)管理

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

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

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

2.3 接口管理

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

2.4 監(jiān)控管理

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

2.5 服務(wù)治理

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

3 應(yīng)用效果

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

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

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

4 總結(jié)

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