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

引言

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

1 設計思路

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

1.1 平臺用戶授權

1.1.1 C/S兩層架構

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

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

1.1.2 C/S/S三層架構

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

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

1.1.3 B/S/S三層架構

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

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

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

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

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

2 平臺建設與功能介紹

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

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

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

圖6 接口授權配置

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

圖7 平臺功能介紹

2.1 系統(tǒng)管理

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

2.2 授權接入管理

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

2.3 接口管理

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

2.4 監(jiān)控管理

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

2.5 服務治理

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

3 應用效果

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

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

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

4 總結

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