基于RBAC權(quán)限模型實(shí)現(xiàn)醫(yī)院計(jì)算機(jī)信息管理的研究

董向文

(廣西中醫(yī)藥大學(xué) 第一附屬醫(yī)院，廣西 鐘山 530023)

0 引言

隨著現(xiàn)代的計(jì)算機(jī)技術(shù)不斷升級(jí)，醫(yī)院管理信息化程度越來越高，醫(yī)院的管理信息類型繁多，需要耗費(fèi)大量的時(shí)間進(jìn)行處理，工作效率低。醫(yī)院的信息管理不僅包括醫(yī)生及患者信息、病案、醫(yī)院設(shè)施、物資、人事、財(cái)務(wù)、藥房及藥物價(jià)格，還包括其他部門的信息交互，及時(shí)地了解相關(guān)的信息變動(dòng)。目前，醫(yī)院計(jì)算機(jī)信息管理系統(tǒng)面臨最大的難題是信息安全保障[1-4]，為了解決問題，本文通過RBAC權(quán)限模型對醫(yī)院計(jì)算機(jī)信息進(jìn)行有效的管理[5-8]。

1 RBAC技術(shù)

隨著我國的發(fā)展，各行各業(yè)的數(shù)據(jù)不斷信息化，每個(gè)角色都有自己的數(shù)據(jù)庫，任何角色都無權(quán)獲取不屬于自己的數(shù)據(jù)庫相關(guān)的信息，而RBAC技術(shù)正是為了這個(gè)而提出的。RBAC技術(shù)在各行業(yè)信息管理平臺(tái)中比較廣泛的應(yīng)用，擴(kuò)展性強(qiáng)[9]，RBAC模型如圖1所示，其主要思想如下：

圖1 RBAC模型

首先創(chuàng)建角色集合，放在權(quán)限集合與用戶集合中間，角色本身擁有配套的訪問權(quán)限，具體用戶不需要被直接授予系統(tǒng)中的訪問權(quán)限，只需要被安排到合適的角色即可。在信息管理中，只需要角色授權(quán)信息，即可得到配套的訪問權(quán)限，減少系統(tǒng)開銷，簡化角色權(quán)限管理[10]。

如圖1所示，RBAC模型由角色、用戶、會(huì)話、權(quán)限構(gòu)成。一個(gè)角色可分配到多個(gè)用戶，同理，一個(gè)用戶也可被賦予多個(gè)角色，角色與權(quán)限也同樣如此。角色本身具有配套的權(quán)限，首先創(chuàng)建一個(gè)會(huì)話，在該會(huì)話中，當(dāng)角色被分配到用戶時(shí)，該用戶自動(dòng)獲得相應(yīng)的所有權(quán)限。

通過RBAC技術(shù)，使管理系統(tǒng)的工作效率提高，使用戶授予權(quán)限的過程節(jié)省了不少的時(shí)間，有助于減少系統(tǒng)開銷，提高安全性[11-12]。下面描述內(nèi)容是RBAC技術(shù)的優(yōu)勢：

1)該技術(shù)給用戶賦予了本身擁有配套權(quán)限的角色，以便降低了開銷，提高了靈活性和管理效率，大大節(jié)省了管理技術(shù)復(fù)雜的用戶角色占據(jù)的空間。

2)職責(zé)分離，比如，為了提高安全性，防止發(fā)生欺騙現(xiàn)象，在支付平臺(tái)中通過該技術(shù)將實(shí)際付款和授權(quán)付款分開進(jìn)行，減少經(jīng)濟(jì)損失。

3)最小權(quán)限原則，為了避免有些用戶利用職權(quán)進(jìn)行濫用行為，利用技術(shù)給每個(gè)用戶分配到該角色本身擁有的權(quán)利，該權(quán)利只能在自己工作范圍內(nèi)履行，不能超過角色本身權(quán)限范圍，超出范圍外的權(quán)利視為無效。

2 醫(yī)院計(jì)算機(jī)信息管理系統(tǒng)

2.1 整體平臺(tái)模塊設(shè)計(jì)

隨著科學(xué)技術(shù)發(fā)展，醫(yī)院信息管理系統(tǒng)的權(quán)限體制越來越精細(xì)，增強(qiáng)了權(quán)限管理靈活性。醫(yī)院信息管理系統(tǒng)設(shè)計(jì)思想是“誰擁有權(quán)利，職責(zé)是什么、應(yīng)該做什么”，權(quán)限系統(tǒng)主要實(shí)現(xiàn)整體控制，業(yè)務(wù)邏輯主要實(shí)現(xiàn)局部控制。例如，在某個(gè)業(yè)務(wù)里，A醫(yī)生擁有刪除本身創(chuàng)建的病歷信息的權(quán)限，同時(shí)，擁有A醫(yī)生角色權(quán)限的B醫(yī)生只能修改A醫(yī)生創(chuàng)建的病歷信息，其他醫(yī)生只能查看病歷信息的權(quán)限，這就需要通過業(yè)務(wù)邏輯來實(shí)現(xiàn)這一要求。權(quán)限系統(tǒng)的主要問題是給醫(yī)生賦予什么樣的角色，同樣角色本身自帶配套的權(quán)限，同時(shí)利用業(yè)務(wù)邏輯根據(jù)獨(dú)特權(quán)限要求通過編碼實(shí)現(xiàn)其他的權(quán)限，建立健全的權(quán)限體系。

基于上述主要思想，現(xiàn)在設(shè)計(jì)出如圖2所示的功能模塊圖，在該功能模塊圖中，將醫(yī)院計(jì)算機(jī)信息管理平臺(tái)劃分為若干平臺(tái)，比如，該模塊分為界面客戶端平臺(tái)、網(wǎng)站查詢平臺(tái)、后臺(tái)管理平臺(tái)、手機(jī)客戶端平臺(tái)等[13-15]。為了論述的需要，將上述模塊作為主要的平臺(tái)進(jìn)行論述。界面客戶端平臺(tái)主要通過主機(jī)進(jìn)行訪問不同應(yīng)用功能，比如用戶注冊及登錄。網(wǎng)站查詢平臺(tái)主要通過網(wǎng)站對應(yīng)用功能進(jìn)行訪問。手機(jī)客戶端平臺(tái)通過手機(jī)進(jìn)行訪問醫(yī)院信息。后臺(tái)管理平臺(tái)主要管理和維護(hù)醫(yī)院計(jì)算機(jī)信息系統(tǒng)運(yùn)行，以保障系統(tǒng)安全性。

圖2 功能模塊設(shè)計(jì)

通過上述模塊設(shè)計(jì)，能夠在醫(yī)院計(jì)算機(jī)信息管理平臺(tái)上實(shí)現(xiàn)界面登錄、預(yù)約掛號(hào)、就診呼叫、病例查詢等功能。用戶還可以在后臺(tái)管理平臺(tái)實(shí)現(xiàn)各項(xiàng)功能的應(yīng)用[16-17]，比如平臺(tái)安全管理、系統(tǒng)數(shù)據(jù)管理、系統(tǒng)角色管理和系統(tǒng)日志管理等。在引入RBAC技術(shù)后，需要對數(shù)據(jù)庫進(jìn)行設(shè)計(jì)，下文將詳細(xì)介紹。

2.2 數(shù)據(jù)庫設(shè)計(jì)

下面對數(shù)據(jù)庫進(jìn)行重點(diǎn)說明，為了防止醫(yī)院隱私信息泄露、外界非法入侵，在醫(yī)院管理系統(tǒng)中引入了RBAC技術(shù)。首先設(shè)計(jì)數(shù)據(jù)庫，對數(shù)據(jù)表進(jìn)行定義[18-19]。在數(shù)據(jù)庫中：

1)hx_user：表示用戶表，其負(fù)責(zé)保存用戶基本資料，包括username，name，sex，department，id，position 和 userpass 等字段。

2)hx_department：表示部門表，負(fù)責(zé)保存部門基本資料，包括id和 department字段。

3)hx_postion：表示職位表，負(fù)責(zé)保存職位數(shù)據(jù)，包含id和 postion字段。

4)hx_node：表示權(quán)限表，負(fù)責(zé)保存權(quán)限基本資料，包含id，name，moname，mname，aname和 status等字段。

5)hx_role：表示角色表，保存角色基本資料，包含id，name，status和 remark等字段。

6)hx_tem_role：表示角色更新表，負(fù)責(zé)保存角色權(quán)限資料更新的列表，包含 id，name，status、remark 和 node 等字段。

7)hx_role_node：表示角色權(quán)限表，負(fù)責(zé)保存權(quán)限和角色的地址位置表，包含rid和nid字段。

8)hx_user_role：表示用戶角色表：負(fù)責(zé)保存用戶和角色的地址位置表，包含rid和uid字段。

9)hx_check：表示申報(bào)表，負(fù)責(zé)保存用戶申報(bào)數(shù)據(jù)，包含id，username，name，title和 fankui等字段。

10)hx_duty：表示員工值班表，負(fù)責(zé)保存員工值班基本數(shù)據(jù)，包含 id，username，name，department 和 time 等字段。

11)hx_book：表示公告表，負(fù)責(zé)保存公告基本資料，包含id，title和 replytime等字段。

RBAC(role-based access control,對角色的訪問控制)，在數(shù)據(jù)庫中，能夠?qū)⒔巧c權(quán)限關(guān)聯(lián)起來。簡而言之，能夠使一種用戶擁有多個(gè)角色，各個(gè)角色擁有不同的權(quán)限。充分利用“用戶-角色-權(quán)限”這種關(guān)聯(lián)形式構(gòu)建的授權(quán)模型[20-21]，進(jìn)行進(jìn)一步的計(jì)算其間的關(guān)聯(lián)性，通過利用這種數(shù)據(jù)模型，使管理者在用戶和角色之間、角色和權(quán)限之間根據(jù)設(shè)計(jì)目標(biāo)和需求設(shè)計(jì)，進(jìn)行操作計(jì)算機(jī)系統(tǒng)的各個(gè)需求功能。最后，結(jié)合醫(yī)院需求和文化，對平臺(tái)界面風(fēng)格、配色、結(jié)構(gòu)進(jìn)行設(shè)計(jì)，創(chuàng)建出相關(guān)的網(wǎng)頁。

圖3 數(shù)據(jù)庫功能模塊示意圖

在具體應(yīng)用中，可以對各種數(shù)據(jù)模塊進(jìn)行分類，其分類的模式如圖4所示。

圖4 數(shù)據(jù)庫分類結(jié)構(gòu)示意圖

在上述數(shù)據(jù)庫中，充分利用了各種權(quán)限的作用，其中將“MENU”能夠表示為對菜單的訪問權(quán)限設(shè)置，將“OPERATION”表示為數(shù)據(jù)庫中的功能模塊的操作權(quán)限，而將“FILE”表示為文件的修改權(quán)限，將“ELEMENT”表示為頁面元素中的可見性控制等[22-23]。

2.3 權(quán)限控制的業(yè)務(wù)邏輯

在對權(quán)限的功能模塊進(jìn)行了設(shè)計(jì)之后，控制的業(yè)務(wù)邏輯也是尤其重要。能否操作系統(tǒng)功能的模塊決定了用戶擁有的權(quán)限。只要用戶擁有權(quán)限，不論訪問的客體是否有資源，都可以進(jìn)入系統(tǒng)操作對應(yīng)的功能模塊。利用非浸入式編程(aspect oriented programming，AOP)方法來隔離控制邏輯與業(yè)務(wù)，并在Apache Shiro 安全框架中實(shí)現(xiàn)訪問模型。通過HashSet對用戶與角色本身擁有配套的權(quán)限進(jìn)行授權(quán)，并在Shiro帶來的Realm的doGetAuthorizationInfo[24-25]中實(shí)現(xiàn)訪問權(quán)限。

為了對通用權(quán)限管理進(jìn)行實(shí)現(xiàn)，本研究利用AOP編程方法對業(yè)務(wù)邏輯與權(quán)限判斷進(jìn)行分離。當(dāng)用戶訪問時(shí)對用戶的權(quán)限進(jìn)行判斷，必然會(huì)接觸到訪問的數(shù)據(jù)。我們可以在編程過程中添加約束條件集合語句，增加一些邏輯判斷，以便在獲取數(shù)據(jù)時(shí)，控制無權(quán)訪問的數(shù)據(jù)。為了避免遭到外界入侵，在管理模塊中只顯示操作失敗和空的結(jié)果，而不會(huì)出現(xiàn)操作越界的提示信息，具體實(shí)現(xiàn)方式如下：

1)為了查詢數(shù)據(jù)庫，對檢索接口定義，設(shè)置額外檢索參數(shù)，對用戶、用戶集對應(yīng)的屬性讀寫方式進(jìn)行實(shí)現(xiàn)。

2)對權(quán)限和權(quán)限集對應(yīng)的屬性進(jìn)行注解和標(biāo)注。

3)利用2)注解方法定義切面類。

4)為了增加一些約束條件，根據(jù)用戶擁有的權(quán)限對用戶、用戶集對應(yīng)的屬性進(jìn)行設(shè)置，以便在切面類中實(shí)現(xiàn)環(huán)繞通知。

下面的代碼是業(yè)務(wù)邏輯與權(quán)限的分離過程：

List of masses Define MenusByCode

{

Back to ZhuMenu． Define MenusByCode;

}

Void AssignMenus of masses To Deptment Define string deptcode

{

AssignMenusToDept and ZhuMenu Define menuCodes，deptcode;

}

將groupSet、groupId、userId定義為類屬性的實(shí)現(xiàn)代碼，這些代碼具備讀寫功能，檢索數(shù)據(jù)接口的代碼為 ResourceSearchMessage，實(shí)現(xiàn)業(yè)務(wù)層服務(wù)的注解為@ResourcePermission。如何判斷檢索到的參數(shù)(如groupSet、groupId、userId)，可通過實(shí)現(xiàn)環(huán)繞的切面方法，ResourcePermissionAspect定義為切面類。定義pGroupSet為權(quán)限的組合集，由于醫(yī)院部門類型繁多，各部門之間即聯(lián)系又獨(dú)立，可用4位編碼來表示groupSet、groupId、userId。如表1所示，O代表存在，-代表不存在，組合集是否包含groupId，可通過Yes或No來表示，比如groupSet非空且 groupID非空時(shí)，根據(jù)userId情況顯示的是Yes或者No。為了防止沒必要的連接或條件占據(jù)空間，在Mybatis動(dòng)態(tài)SQL內(nèi)可建立一個(gè)空的檢索屬性。

表1 編碼定義對應(yīng)表

2.4 系統(tǒng)安全訪問流程

用戶在利用RBAC技術(shù)時(shí)，不僅僅能夠防止醫(yī)院的機(jī)密資料向外泄露，保護(hù)個(gè)人隱私，還能夠大大節(jié)約用戶的工作效率。其中RBAC權(quán)限訪問模型工作原理如下：當(dāng)對系統(tǒng)用戶進(jìn)行角色分配時(shí)，能夠自動(dòng)獲得該角色相應(yīng)的權(quán)限。用戶一般指的是護(hù)士、護(hù)士長、醫(yī)生、部門主任、院長等角色，每個(gè)角色都有自己配套的權(quán)限。如圖5所示，RBAC權(quán)限訪問模型工作流程如下：

圖5 訪問流程設(shè)計(jì)

1)用戶注冊時(shí)，對用戶名進(jìn)行定義，輸入登錄密碼，完善個(gè)人資料，即完成注冊。當(dāng)用戶在系統(tǒng)登錄時(shí)，需要輸入用戶名及密碼，將會(huì)通過驗(yàn)證方式進(jìn)行驗(yàn)證，若通過驗(yàn)證，即將進(jìn)入系統(tǒng)里面，反之將回到登錄界面上。

2)完成登錄后，用戶在系統(tǒng)中被會(huì)話管理模塊檢索出角色信息，用戶即將被安排到適合的角色。

3)用戶被分配到角色后，為該用戶新建會(huì)話窗口。

4)創(chuàng)建新會(huì)話窗口后，用戶將得到該角色擁有配套的權(quán)限，即可操作相應(yīng)功能模塊。

5)管理人員需要等會(huì)話結(jié)束后，才能進(jìn)行修改用戶擁有的權(quán)限。

數(shù)據(jù)訪問層設(shè)計(jì)代碼如下：

//角色權(quán)限的獲取過程//

List of masses Define MenusByCode

{

new List() = Listmenus;

"@code =select * Department code is defined as department menu" = string sql ;

SqlDataProvider = DataSet ds Define ResultBySql(CreateSqlParameter,SqlDataP-rovider,sql (code,VarChar,SqlDbType," @ code"));

Array (Rows.Tables[0].Data Row dr in ds)

{ Add(ToString.Func).menus

}

return menus;

}

/ /角色被分配到權(quán)限名稱//

Void AssignMenus of masses To Deptment Define string deptcode

{

"@ deptcode =Remove deptcode from the b?" =Dept?Menu;

" Insert bs dept menu(menu-code，deptcode) values(@ menucode ，@ deptcode) " = string sql_ins；

ExecuteBySql.SqlDataProvider(CreateSqlParameter.SqlDataProvider． sql _ del (" dept-code,VarChar,SqlDbType,@ deptcode"))

Array (string mc in menuCodes)

{

ExecuteBySql.SqlDataProvider (CreateSqlParameter,SqlDataProvider,sql _ ins(dept-code,VarChar,SqlDbType,@ deptcode),CreateSqlParameter,SqlDataProvider(mc,VarChar，SqlDb-Type,"@ menucode")) ;

}

}

3 實(shí)驗(yàn)與效果分析

為了判斷系統(tǒng)的有效性，本文對系統(tǒng)進(jìn)行測試，下面利用讀取方式對獲取訪問數(shù)據(jù)進(jìn)行分析。在試驗(yàn)時(shí)，選擇的操作系統(tǒng)為Microsoft Windows 2010，64 位。主要開發(fā)工具為Visual Studio 2015，OpenCV 3.0。運(yùn)行環(huán)境硬件參數(shù)為CPU：inter(R)Core(TM)i7；主頻為2.59GHz；內(nèi)存8G。在試驗(yàn)時(shí)，首先登錄軟件界面，其界面如圖6所示，用戶完成注冊后，可在醫(yī)院信息系統(tǒng)中輸入用戶名和密碼后，完成登錄。

圖6 用戶登錄界面圖

在完成登錄之后，如圖7所示，當(dāng)用戶需要預(yù)約掛號(hào)，選擇預(yù)約功能模塊，直接進(jìn)入預(yù)約管理系統(tǒng)，選擇醫(yī)院、掛號(hào)、時(shí)間和醫(yī)生，完成預(yù)約掛號(hào)。

圖7 預(yù)約掛號(hào)管理系統(tǒng)圖

然后調(diào)取數(shù)據(jù)庫集中的數(shù)據(jù)，對數(shù)據(jù)進(jìn)行計(jì)算。假設(shè)將U代表測試數(shù)據(jù)的集合，該數(shù)據(jù)集合包括數(shù)據(jù)源和數(shù)據(jù)訪問記錄。數(shù)據(jù)源有A、B、C、D、E五個(gè)子源，數(shù)據(jù)可由a、b、c、d四個(gè)表示，它們的分布關(guān)系如圖8所示。A子源包含a和c兩個(gè)數(shù)據(jù)，B子源包含b和c兩個(gè)數(shù)據(jù)，C子源僅包含c個(gè)數(shù)據(jù)，D子源僅包含d個(gè)數(shù)據(jù)，E為空集。

圖8 數(shù)據(jù)源分布關(guān)系

根據(jù)分布關(guān)系對用戶的角色權(quán)限進(jìn)行劃分，有A，B，C，D，E五個(gè)讀取權(quán)限。角色權(quán)限的分配結(jié)果如表2所示，○ 代表該存在擁有配套權(quán)限的用戶，╳代表該存在不擁有權(quán)限的用戶，-(空白)代表不存在該用戶。ID表示不同類型的用戶，根據(jù)全部數(shù)據(jù)、A子源數(shù)據(jù)，B子源數(shù)據(jù)。

表2 測試結(jié)果

根據(jù)上述測試，為了試驗(yàn)本系統(tǒng)的管理能力，與傳統(tǒng)醫(yī)院計(jì)算機(jī)管理系統(tǒng)比較，對系統(tǒng)管理能力的實(shí)驗(yàn)效果進(jìn)行分析，如圖9所示。

圖9 仿真結(jié)果對比圖

實(shí)驗(yàn)結(jié)果可知，在相同環(huán)境中處理相同的數(shù)據(jù)情況下，與傳統(tǒng)系統(tǒng)相比，基于RBAC權(quán)限模型的醫(yī)院計(jì)算機(jī)信息管理系統(tǒng)的管理能力較高，大大減少系統(tǒng)開銷。

4 結(jié)束語

在醫(yī)院中的各種設(shè)施、人資、物資、財(cái)務(wù)、藥房及藥物價(jià)格等信息中，融合了各種信息。本文RBAC模型利用角色建立用戶與權(quán)限之間的關(guān)系，使得用戶能夠在用戶數(shù)據(jù)和訪問權(quán)限數(shù)據(jù)之間實(shí)現(xiàn)數(shù)據(jù)分離，不僅能夠減少數(shù)據(jù)授權(quán)管理的復(fù)雜性，還能夠降低醫(yī)院日常運(yùn)營的成本開銷。通過角色權(quán)限訪問技術(shù)，根據(jù)職位和級(jí)別，將用戶分配到適合的角色，使得用戶獲得該角色本身擁有配套的權(quán)限，對相應(yīng)的功能模塊進(jìn)行操作，實(shí)現(xiàn)預(yù)約掛號(hào)、病歷查詢等功能，提高了安全性?；赗BAC模型的權(quán)限管理觀念在醫(yī)院信息系統(tǒng)中能夠得到很好的應(yīng)用，為后期在醫(yī)院管理和患者信息安全方面提供重要的價(jià)值參考。