以角色為基礎之存取控制模型導入中西醫藥併用之醫療系統

(1)

I

以角色為基礎之存取控制模型導入中西醫藥併用之醫療系統

中華大學資訊管理學系

摘要

隨著醫療科技的進步，結合中醫與西醫併用不再只是空想，病人同時接收中、西醫的專業治療，除了本身可以得到更多的資訊外，對整體的療程也會更具有信心。然而中西醫療併用同時也產生了許多問題，如病歷資料的權限歸屬問題、中西藥併用產生交互作用的問題等，除此之外，將病歷資料透過電子化方式安全傳遞，除了需要基本的網路平台外，更需要一套存取授權機制來做基層的權限控管。因此，本研究提出以角色為基礎之存取控制模型導入中西醫療併用系統，醫護人員可藉由此系統授權適當的角色行使其權限，解決中西醫療併用系統下中、西醫師對同一病歷的權限問題，並且透過中西醫藥交互作用平台摒除中西藥併用而產生不好的交互作用之可能性。

關鍵詞：中西醫療併用、以角色為基礎之存取控制、中西醫藥交互作用平台

研究生：馮堯保指導教授：吳美玉博士

(2)

II

Applying Role-based Access Control in Combining the Chinese and Western Medicine Systems

Department of Information Management, Chung-Hua University

ABSTRACT

Developing the technological support for combining Chinese and Western medicine would be for the advancement of healthcare in general. Patients would be able to receive treatment from both the Chinese and Western medicine systems at the same time. Patients would not only have to obtain medical information, but also enhance their confidence in the treatment itself. However, in combining Chinese and Western medical treatments, some issues that are raised are the ownership of patient records and the correlation of Chinese and Western medicines. Besides, transmitting a patient’s electronic record requires an adaptive access control model to monitor access permission on a secure network platform. Therefore, a role-based access control model is proposed to combine Chinese and Western medicine systems. The model authorizes hospital staff to solve problems in a patient’s record. Moreover, this model could reduce incompatibilities when Chinese and Western medicines are combined by using a correlation platform of Chinese and Western medicine, context and rules.

Keywords: Combined Chinese and Western medicine, Role-based Access Control,

Correlation platform of Chinese and Western medicine

Student：Yao-Bao Fong Advisor：Dr. Mei-Yu Wu

(3)

III

致謝

這篇論文能如期完成，我最感謝的是我的指導教授吳美玉老師，在這兩年來的細心指導及教誨，除了讓我學習到學術上的專業知識，更讓我瞭解做為一個研究生該有的責任與態度，使我受益良多，平時也時常關心我們的生活，她是我們的良師，也是我們的益友。

感謝我的口詴委員郭明煌教授、張文智教授以及葉慈章教授，他們在百忙之中特地抽空前來為我們口詴，除了對我的論文細心指導外也提出了精闢的建議，

讓我能將論文修改地更加完善，實在是受益匪淺。

我要感謝實驗室的學長家維、智翔、其弘和宗澤，他們給予我適當的支持與鼓勵，讓我有動力去完成學業，另外要感謝我的同學文鈴、彥廷、志煌、育民、

坤祺、彥達與奕龍，在我研究所兩年期間的建議與幫助，讓我能夠順利完成這篇論文，最後要謝謝學弟鍾鑫、逸瑋、茂帆與宗璞帶給我難忘且快樂的研究生活，

謝謝你們。

(4)

IV

圖目錄

圖 1. 研究流程圖 ... 5

圖 2. 存取控制串列 ... 10

圖 3. 能力串列 ... 12

圖 4. 以角色為基礎之存取控制模型的使用者、角色與權限對應關係 ... 15

圖 5. 以角色為基礎之存取控制模型 ... 16

圖 6. 角色階層範例圖 ... 19

圖 7. 傳統的 RBAC 模型加入相關的情境參數 ... 29

圖 8. 黏連性肩關節關節囊炎的類型 ... 31

圖 9. 以角色為基礎之存取控制模型導入中西醫藥併用之醫療系統架構 ... 33

圖 10. 西醫師要求觀看病患會產生交互作用的病歷之系統流程 ... 39

圖 11. 中醫師要求觀看病患會產生交互作用的病歷之系統流程 ... 40

圖 12. 使用者登入畫面 ... 44

圖 13. 使用者登入後畫面 ... 45

圖 14. 角色擔任 ... 46

圖 15. 角色繼承－主治中醫師決定繼承住院中醫師的權限 ... 47

圖 16. 角色繼承－主治中醫師決定繼承實習中醫師的權限 ... 47

圖 17. 角色繼承－主治中醫師取消對住院中醫師的角色繼承 ... 48

圖 18. 角色繼承－主治西醫師執行角色繼承前畫面 ... 49

圖 19. 角色繼承－主治西醫師執行角色繼承後畫面 ... 49

圖 20. 傳送病歷 ... 50

圖 21. 接收病歷－接收病歷後畫面 ... 51

圖 22. 接收病歷－主治西醫師接收會與西藥產生交互作用的中藥病歷 ... 52

圖 23. 接收病歷－主治中醫師接收會與中藥產生交互作用的西藥病歷 ... 53

圖 24. 系統管理者登入前畫面 ... 54

圖 25. 系統管理者登入後畫面 ... 54

圖 26. 角色管理 ... 55

圖 27. 角色成員管理 ... 56

圖 28. 權限管理 ... 57

(7)

VII

表目錄

表 1. 存取控制陣列 ... 9

表 2. 授權關係 ... 14

表 3. 系統環境及開發軟體彙整表 ... 42

表 4. 角色可行使的權限列表 ... 43

(8)

1

第一章緒論

隨著資訊科技的進步，所有的企業組織、醫療院所皆已逐漸電腦化，內部流程紛紛取消了傳統人工作業方式，進而改由電腦自動化方式作為取代，此外，網際網路技術的成熟也促使應用軟體的發展，企業可將其內部的應用系統移植在網際網路環境下使用。在這樣方便的環境下，員工透過網路，即可隨時隨地取得企業各項資源，使得整體工作效率大大提升，外部的供應商也可透過公司對外網路做快速的資訊聯絡，減少傳統電話聯絡成本。

然而這些劃時代的變革卻也帶來另一方面的隱憂，雖然透過電腦以及網路的使用可以達到作業上的便利及快速，卻會引發另外一個重要的問題，就是資訊的安全管理。而資訊安全技術包括使用者認證（Authentication）、資料加密與解密

（Encryption/Decryption）、金鑰管理（Key Management）及入侵偵測（Intrusion Detection）及存取控制（Access Control）等機制，這些技術都能讓企業內部資源獲得一定程度的防範。

一般而言，使用者透過資訊系統提供的服務來針對使用者所需的相關企業資源進行存取。而使用者身分經過系統確認過後，系統會給予使用者合法的身份，

資料存取會根據系統給予的身份而授予適當的權限。因此透過資料存取控制，即可針對合法使用者對於資料存取的權限，並且設定合理行為的使用限制，避免使用者有非法的存取行為。而企業應該對於存取資料的行為提供合理方法，可以藉由合適的機制來管理企業資料的存取行為，以增加企業資料存取的安全性。如果企業沒有一套適當的資料存取控制機制，企業資源及機密資料容易被濫用或是竊取。因此選擇一個適當的存取控制機制是有其必要性。

同樣地，在醫療院所也有存取控制的需求，其內部的成員都有各自不同的權限，如主治醫師可以對病人做外科手術，實習醫師可以做為主治醫師外科手術的助手，護士可以為病患進行藥物注射及外科手術的術前準備等，並藉由各角色之

(9)

2

間的職責，交會出一個完善的醫療體系。此外，病人的病歷資料屬於醫師的著作，

其內容更攸關病人的隱私問題，因此醫療院所要有良好的網路架構才能確保內部資料不外流，並且在完善的存取控管機制下得以保證醫院內部成員皆各司其職，

讓病患權益不受損。

1.1 研究背景與動機

中醫往往給人的印象就是效果慢，不能像西醫一樣藥到病除、立竿見影，實則不然，利用針灸治療內傷，或是為病人做復健調養，都可以讓患者在短時間內感到療效、減少疼痛，日本學者們更進一步發現[7]，對糖尿病患者施以中藥併用西藥的療法，不但可以使血糖控制更為理想，而且可以改善患者的合併症，如大血管病變、眼睛的病變、神經病變及腎臟病變等。

西元2003年，亞洲爆發非典型肺炎（SARS），其中香港地區的患者人數不斷的增多，許多患者家屬紛紛要求希望能為病患進行中醫藥治療，但由於公營醫療系統體系的狀況，無法實現病者的願望，在大家都面臨恐懼、沮喪下，中醫師卻無法盡一分心力加入救治工作。同年四月十六日，香港浸會大學中醫藥學院成立抗炎行動專責小組，並進行「中西醫結合治療非典型肺炎」專題演講，不久後，

醫院管理局開始接納中醫藥參與抗炎[12]。然而這樣一個西醫系統要能夠接納中醫藥治療患者，或是西醫治療納入中醫系統療程，是一個新的醫療程序，勢必會造成病歷資料的權限歸屬問題，若沒有一套完善的存取控制模型，將會造成病患資料隱私外流或是不當使用等安全性議題，而不成熟的中西醫療協同診治機制，

也會造成未知的中西藥交互作用，這些對病人而言都是極大的傷害。

在資訊安全的研究領域上，已經有多位學者發表了以角色為基礎的存取控制模型（Role-based Access Control Model, 簡稱RBAC）[27][29]可以用來解決資料存取控制上的問題。在RBAC存取控制模型中，使用者皆被分配到適當的角色，

(10)

3

而資源的存取權限則是經由所屬的角色來決定。由於RBAC在存取控制架構運作上具有很大的彈性，因此RBAC已經被廣泛的接受以及研究，其中更包含了支援相關的安全策略目標，如最小權限限制（least privilege）與靜、動態責任分離限制（static and dynamic separation of duty, SSD and DSD）。因此在2000年，RBAC 已經被美國國家標準與技術協會（National Institute of Standards and Technology, 簡稱NIST）視為一種存取控制的標準，此外NIST也開始提倡RBAC的應用。

由於存取控制的相關研究愈來愈多，所定義的條件也愈趨詳盡，情境

（context）的導入便是其中一種，所謂情境，是任何可以描述任一個體的資訊，

個體可以是人員、地點、時間以及所有相關的物件，因此，將情境條件加入存取控制的限制條件，可以讓我們的研究更接近實際發生的狀況，增加研究的可行性。

1.2 研究目的

目前醫療保健相關的研究相當的多，以台灣來說，有全民健康保險及醫藥分業等制度的實行，各地方的醫院有建立合作夥伴的關係，醫院與學校之間也有建教合作的關係，在整體的醫療體系下算是相當的完善，但是目前醫療保健在導入存取控制機制多半偏向西醫的研究，鮮少有中醫療程也導入存取控制的案例，更遑論將存取控制加入中醫與西醫的協同會診，所以就目前的醫療制度並不能提供中醫與西醫的協同診治，然而當病患在面對現代醫學已難有突破的情況，像是癌症，對患者而言，有效救人的方法愈多愈好，因此本研究主要是提出一個新架構，

將廣為接受的「以角色為基礎之存取控制模型」導入中西醫藥併用之醫療系統，

主要透過本系統所提出之角色指派以及規則條件，自動將權限分派至適當的角色，使得整個醫療系統在角色指派及資源分配上更加完整以及更具有效率。

另外我們也會針對角色指派實作出一個雛型系統加以驗證，希望透過此雛型

(11)

4

系統可以讓醫療院所體認到中西醫療協同診治導入以角色為基礎之存取控制機制是可行的，希望藉由本論文的觀點及系統架構，有助於提昇我們的醫療品質，

造福更多需要受惠的病友。

1.3 研究流程

本論文之研究流程如圖 1 所示，首先闡述問題背景、研究動機與目的，接著搜尋與本研究相關之參考文獻，並依據相關文獻的蒐集與分析，進一步確立研究範圍。

本研究在文獻資料之蒐集與探討上主要區分下列幾部份，包括：

1. 存取控制策略 2. 情境感知 3. 醫院資訊系統

4. 以角色為基礎之存取控制模型導入醫療保健

根據文獻資料的分析與整理，可作為本論文研究架構之理論基礎，並將重點著眼於使用者取得虛擬角色指派的實作，我們得以確定研究主題為「以角色為基礎之存取控制模型導入中西醫藥併用之醫療系統」，並期望能把整個理論模型建構完成，最後分析相關實作結果，並提出適當結論及建議事項。

(12)

5

圖 1. 研究流程圖

1.4 論文架構

本研究提出了以角色為基礎之存取控制模型導入中西醫藥併用之醫療系統，醫療人員透過本系統的角色指派及自動化將權限指派給角色，進而降低醫療院所後端系統之成本。相關章節安排如下：

第一章包含了本篇論文的緒論，概括的闡述目前資訊科技及網際網路的發展情形，並且介紹本篇論文之研究背景與動機、研究目的、研究流程以及論文架構。

第二章將探討與本研究相關的四個研究領域，分別是存取控制策略、情境感研究背景與動機

研究目的

文獻探討

情境感知

Healthcare RBAC in Healthcare

系統實作

實驗評估

結果分析與結論

存取控制策略

(13)

6

知、醫院資訊系統，以及以角色為基礎之存取控制模型導入醫療保健，以這些理論為概念基礎，延伸出以角色為基礎之存取控制模型導入中西醫藥併用系統。

第三章為本篇研究之重點，主要說明整個以角色為基礎之存取控制模型導入中西醫藥併用之醫療系統架構，對架構下的各元素定義屬性，並定義出各元素間的限制條件規則，並詳細說明系統內部流程，使其整體達到完整及確實性。

第四章為本研究所提出之系統雛型介紹，包含系統環境與架構，並做畫面展示及流程說明，根據中西醫療併用的實例，來說明本研究所提出之概念。

第五章為本研究之結論與未來研究，說明本研究架構特性與結果，希望在未來得以將本系統延伸至跨醫院的中西醫療協同診治，使整個中西醫療併用系統更加龐大，並且是建立在以角色為基礎之存取控制模型導入中西醫療併用系統之架構下，使得醫院內部資料有更深一層的保護。

(14)

7

第二章相關研究

本章將探討與本研究相關的研究，共有四個要點，分別是存取控制策略、情境感知、醫院資訊系統及以角色為基礎之存取控制模型導入醫療保健。第一節將介紹常用到的存取控制，包含 ACM、ACL、CL、AR、DAC、MAC 及 RBAC 等方法，並分析各項存取控制的優缺點，第二節將介紹情境感知的定義以及應用，

第三節則探討醫院資訊系統，瞭解醫院資訊系統的定義、特性、功能與應用，第四節將討論以角色為基礎之存取控制模型導入醫療保健，並分析其中之優缺點，

第五節為第二章的小結，將為本章做一個簡單的結論。

2.1 存取控制策略

廣為人知的存取控制策略主要分為三類[13][14][14][17]，第一類是隨意的存取控制（Discretionary Access Control, 簡稱 DAC），資料的擁有者可自行決定是否授予權限以及哪種權限給其他使用者，此種授權方式相當具有彈性，但也因為此授權準則較為隨性、不客觀，就系統管理而言比較費時。第二類稱為強制性的存取控制（Mandatory Access Control, 簡稱 MAC），由系統管理者事先制定好安全等級，並依此授權準則來訂定不同使用者的存取權限，然而此強制性的授權條件過於嚴苛，缺乏彈性。

第三類則是以角色為基礎之存取控制（Role-based Access Control, 簡稱 RBAC），是在 1992 年由 Ferraiolo 和 Kuhn 等學者[24]首次提出以角色為主的存取控制概念，之後又經過 Sandhu 等學者[29]加以改進並正式提出以角色為基礎的存取控制模型，並由美國國家標準與技術協會（National Institute of Standards and Technology, NIST ）組職加以收編、整理之後訂定標準，稱為 NIST

(15)

8

RBAC[31]。由於 RBAC 擁有 DAC 與 MAC 具有彈性和易於管理的優點，因此之後也有更多以 RBAC 為基礎的研究，結合不同領域的專業知識並提出各種的模型。

另外，尚有許多其他的存取控制方法，我們將依序介紹幾種方法，並描述其優缺點，以供與本論文所提出的模型相互比較。

2.1.1 存取控制陣列

最原始的存取控制方式為存取控制陣列（ Access Control Matrix, 簡稱 ACM），此模型內部有三個重要的基本元素，分別為 S、O、A，其中 S 為代表操作資料的主體（Subject），O 為被主體操作的受體（Object），而 A 則是因應 S、O 之不同所顯現出來不同的存取權限（Access）[32][36]。

如表 1 所示，透過縱列的 Ann 可對應至橫列的 File 1 及 File 3，查出 Ann 對於 File 1 及 File 3 皆具有擁有（O）、讀取（R）與寫入（W）的權力；而透過縱列的 Bread 可對應至橫列的 File 1 與 File 2，查出 Bread 對 File 1 具有擁有、讀取與寫入的權力，對 File 2 僅有讀取的權力。

存取控制陣列的原理非常簡單而且易於瞭解，卻有三個主要缺點[9]：

1. 當主體與受體數量龐大時，此矩陣將變得很稀疏，儲存空間十分浪費。

2. 當主體或受體進行新增或刪除時，將影響整個列或行。

3. 主體與受體之間的從屬關係無法從陣列直接看出。

基於以上的缺點，存取控制陣列僅限於原理的論述，並不適合實際運用。

(16)

9

表 1. 存取控制陣列

File1 File2 File3 File4

Ann

O R W

Bread

O R W

R

Coco

R W R

Deer

O R W

R

O R W

2.1.2 存取控制串列

存取控制串列（Access Control Lists, 簡稱 ACLs）是以串列（List）的方式串貣相對於受體的所有主體，也就是每個使用者（主體）對於該程式或物件（受體）的存取權限是記錄在相互串接的序列之中。當使用者欲使用該資料或物件時，可以根據該資料或物件為貣點，逐一找尋位於該串列中使用者的權限資料，

比對其記錄是否有權力使用。

如圖 2 所示，若要知道 Deer 對 File 1 有什麼樣的權限，我們可以搜尋 File 1 的串列，直到找到 Deer 的資料項，即可獲知其對 File 1 的權限有擁有、讀取和寫入的權力；若要知道 Bread 對 File 2 有什麼樣的權限，我們可以搜尋 File 2 的串列，直到找到 Bread 的資料項，即可獲知其對 File 2 的權限僅有讀取（R）的權力。

(17)

10

然而當權限有所異動時，透過對串列資料的修改甚至是串列的移除與新增與存取控制陣列相比，都十分的方便與快速。但此一方法並非沒有缺點，當管理者必頇要刪除某一使用者權限時，存取控制串列無法立即找出每個串列中記錄該使用者的資料所在，只能透過遊歷（Travel）的方式逐一搜尋，相當費時。

．

Coco R

(18)

11

2.1.3 能力串列

能力串列（Capability List, 簡稱 CL）與存取控制串列類似，但能力串列主要是以主體串貣所有相對應的受體，也就是透過能力串列，我們可以針對單一使用者用遊歷的方式看到該使用者所有物件或資料的授權情形，剛好與存取控制串列的觀點相反。

如圖 3 所示，我們可以得知 Coco 對 File 2 及 File 4 皆僅有讀取的權力，對 File 3 僅有寫入的權力；Deer 對 File 1 及 File 4 有擁有、讀取與寫入的權力，對 File 3 僅有讀取的權力。

因為能力串列是以主體來查詢每個受體的存取權限，因此當受體權限有修改時，系統必頇要找出每個串列所有關於該受體的儲存記錄，但是透過能力串列是很難直接查到哪些主體擁有該受體的權限，只能將串列逐一遊歷，此種方式並不符合時間成本。

(19)

12

圖 3. 能力串列

2.1.4 授權關係

授權關係（Authorization Relation, 簡稱 AR）是一種結合存取控制串列與能力串列的一種方法，因此它也繼承了兩種方式的優點與缺點。授權關係可以如存

File2 R

．

File3 W

．

File4 R

Coco

Ann File1 O R W

．

File3 O R W

Bread File1 O R W

．

File2 R

Deer File1 O R W

．

File3 R

．

File4 O R W

(20)

13

取控制串列以受體的觀點來看主體的授權情形，也可以如能力串列以主體的觀點來看受體的授權情形。

如表 2 所示，我們可以使用者的角度來看 Ann 對哪些檔案有權限以及對該檔案有何種權限（File 1 的擁有、讀取與寫入；File 3 的擁有、讀取與寫入），

也可以反過來用檔案的觀點來看當 File 1 權限調整時有哪些使用者權限要配合著修改（Ann、Bread 與 Deer）。

授權關係與關聯式資料庫（Relational Database）在運作上的邏輯概念相當雷同，因此為了其便利性，兩者通常會合併使用。

舉凡我們所介紹的幾個存取控制方式種類繁多，如存取控制陣列、存取控制串列、能力串列與授權關係，但多無法與「主體─ 受體」的兩層式架構

（Subject-Object View）[40]脫離關係，而此種架構在人員或職務有異動時，必需逐一變動與其對應的權限，將造成系統或系統維護人員的沉重負擔，因此也較容易出錯。

(21)

R File 4

Deer

W File 4

(22)

15

2.1.5 以角色為基礎之存取控制模型

以角色為基礎之存取控制模型以虛擬的角色做為授權的中介對象，使用者則依需要對應到適當的角色，當使用者對應到適當的角色後，即可利用角色的權限來行使職權。單一的使用者並非只能對應一個角色而已，事實上一個使用者通常都對應多個角色，一個角色也可以對應多個使用者；而一個角色可以對應至多個權限，一個權限也可以對應至多個角色，如圖 4 所示。

圖 4. 以角色為基礎之存取控制模型的使用者、角色與權限對應關係

在以角色為基礎之存取控制模型中，使用者被分配到適當的角色，資源的存取權限則是經由所屬之虛擬角色來決定，而非直接授權給使用者，在觀念上，角色可視為一群工作的集合體，角色之間包含有角色階層（Role Hierarchy）的特性，透過角色階層可以反映出組織的授權結構，使得企業在管理角色以及權限上具有較大的彈性。而以角色為基礎之存取控制架構，如圖 5 所示。以下我們將介紹 RBAC 的基本元素及其定義。

權限 1

權限 2

權限 3

權限 4 使用者 1

使用者 2

角色 1

角色 3 角色 2

(23)

16

圖 5. 以角色為基礎之存取控制模型

2.1.5.1 RBAC 基本元素

以角色為基礎之存取控制模型[23][29][30][31]包含了四個基本元素以及各項元素之間的對應關係，四個基本元素包括使用者（USERS）、角色（ROLES）、

權限（PERMISSIONS）及會期（SESSIONS）等。各個元素的說明如下：

1. 使用者：通常是指與系統互動的人或程式，另外也包含智慧型代理人，例如：

機器人、行動電腦等。

2. 角色：是一個虛擬的角色而非實際角色，通常表示組織內部的職務，透過角色能得知在組織裡相關的權限以及責任。

3. 權限：對於物件的權力，包括存取方式或是操作行為。

4. 會期：指使用者對應到可擔任角色集合的過程，一個使用者可以利用多個會期以擔任多個角色。

ROLES User

Assignment

Permission Assignment

．

SESSIONS

Session_roles

PERMISS- IONS USERS

User_sessions

Role Hierarchy

(24)

17

另外元件之間主要的對應關係包含使用者指派（User Assignment, 簡稱 UA）、權限指派（Permission Assignment, 簡稱PA）及使用者透過會期啟動角色的關係分別為User_sessions以及Session_roles。關係說明如下：

1. 使用者指派：使用者和角色之間是呈現多對多的指派關係，也就是使用者可擔任多個角色，而角色也能同時被指派給多個使用者。

2. 權限指派：角色和權限之間是呈現多對多的指派關係，也就是角色可擁有多個權限，而權限也能同時被分派給多個角色。

3. User_sessions：當使用者啟動任一角色時，會先建立出一個Session，即為 User_sessions。使用者對於Session而言，是屬於一對多的關係，也就是一個使用者可以對應到多個session，但是一個Session只會對應到一個使用者。

4. Session_roles：Session會在使用者所擁有的眾多角色之中啟動一個或數個角色，即是Session_roles。Session對於角色而言，是屬於多對多的關係，也就是一個Session 可以啟動許多個角色，而每個角色也可以同時被許多個 Session所啟動。

2.1.5.2 安全原則

以角色為基礎之存取控制模型支援著名的三種安全原則[22][29]，分別為最少權限（Least privilege）、權責區分（Separation of duties, 簡稱 SOD）以及資料抽象化（Data abstraction）：

1. 最少權限：分派角色權限時，只授予該角色所能使用的適當權限即可，而非授予超過角色權責的權限，如果授予角色多餘或不恰當的權限，會造成組織整體在維護角色權限成本的負荷，而且過多的權限也可能會因為使用者無心或是故意的操作，進而危及到企業資訊的安全。根據以上考量因素，組織提

(25)

18

供角色剛好足夠的權限即可，而不需要授予超過角色權責的權限。

2. 權責區分：將可能會發生衝突的權限分派在不同角色身上，避免權責不分的情形，如果衝突的權限授予在同一個角色可能會造成權責獨攬或是舞弊等情形發生。而權責區分[13][37]又可分為靜態權責區分（Static Separation of Duties, 簡稱SSD）及動態權責區分（Dynamic Separation of Duties, 簡稱 DSD）。

 靜態權責區分：又稱為強互斥（Strong exclusion），同一使用者不能擁有多個會發生權責衝突的角色，避免權責不分的情形，如：開立支票的權限以及簽核支票的權限若由同一個角色來擔任，則有可能發生使用者監守自盜的情形。

 動態權責區分：又稱為弱互斥（Weak exclusion），指同一使用者可以擁有兩個以上相衝突的角色，但是無法在相同時間下同時啟動這些角色。如：一家醫院的院長通常需要身兼主治醫師的職務，此種情形就是屬於動態權責區分的一種。動態權責區分必頇在執行時期，根據使用者實際扮演角色的狀況來判斷權限。

3. 資料抽象化：將實際的資料隱藏於操作中，使用者與系統管理者所看到的資訊為經分類、轉換過的高階語言，可避免因誤解而產生錯誤的授權，並能有效保持整體資料的一致性。

2.1.5.3 角色階層

在以角色為基礎之存取控制模型中，角色階層（Role Hierarchy）是一個很重要的特性，透過角色階層特性可以了解到一個組織的內部規模以及架構。在一般企業組織裡，每個人因職務上的不同，扮演不同的角色，而不同的角色彼此之

(26)

19

間形成一種階層的關係。而在角色階層也包含了繼承的特性，即是上層角色可以繼承下層角色的權限，角色階層範例如圖 6 所示。

圖 6. 角色階層範例圖

在角色階層範例中，假設有一家醫院其內部成員包含有主治西醫師、住院西醫師、實習西醫師、護士以及醫護人員，實習西醫師以及護士分別都繼承醫護人員的權限，並且也擁有屬於自己角色的權限，而住院西醫師繼承了實習西醫師以及護士的權限，因此住院西醫師也擁有醫護人員的權限，同時又因為主治西醫師繼承了住院西醫師的權限，所以主治西醫師也擁有了實習西醫師、護士以及醫護人員的權限，從以上的繼承關係即可看出醫院（組織）內部的架構。另外在權限設定上，管理者不需要在上層角色設定下層角色權限，透過繼承的特性，上層角色就可以擁有下層角色的權限，可以降低管理者設定權限的複雜程度，因此由角色階層的特性可得知，以角色為基礎之存取控制模型有利於管理組織內部角色的架構。

實習西醫師

醫護人員

護士主治西醫師

住院西醫師

(27)

20

2.1.5.4 RBAC 限制

雖然利用角色階層的繼承特性，可以方便權限分派控制的管理，但針對角色以及角色階層特性仍頇注意幾項限制[19][30]：

1. 互斥角色（Mutually Exclusive Roles）：此限制主是要為了滿足安全原則之中的權責區分所建立的限制，即是避免二個可能會發生衝突的角色由一位使用者來擔任，例如：採購角色與驗收角色不能同時由一位使用者擔任，有可能因為使用者故意的操作而造成監守自盜的事情發生。為了避免這種弊端發生，因此需要把會發生衝突的角色設為互斥角色。

2. 使用者數量（Cardinality）：使用者數量是指使用者指派到一個角色應該有數量上的限制，特別是擁有特殊權限的角色，例如：高階主管或是系統管理者等，擔任這些角色的使用者不能太多，否則會有安全上的顧慮。

3. 前提角色（Prerequisite Roles）：在一般企業組織架構下，通常會有前提角色的特性。意思是說使用者必頇先擔任一個角色，才能擔任另一個角色。例如：在一個開發專案中，專案角色可能有專案成員、測詴工程師、程式設計師以及專案經理。假如員工要擔任專案角色中的程式設計師，則必頇要先成為專案成員；另外前提角色的概念也可利用於權限上，意思是一個角色先具有某個權限，才能擁有另一個權限。同樣的情況在醫療院所也相同，醫院內通常有主治醫師、住院醫師、實習醫師與醫護人員等角色，假如醫院內部人員要擔任實習醫師的角色，則必頇要先有成為醫護人員的資格才得以擔任實習醫師的角色。

(28)

21

2.2 情境感知

本節共分為兩小節，依序為情境與情境感知。我們將於第一節介紹情境相關的基本定義、與情境相關的觀點，第二節則探討情境感知的影響，藉以更加瞭解應用環境加入情境的實用性和真實性。

2.2.1 情境

根據 Chen 與 Dey 等人[20]所定義的情境為「任何可以描述一個個體狀況的資訊，這邊所指的個體包括了人、地點，或是所有相關的物件皆可以稱之為個體。」

以及「情境是環境的狀態和設定，是應用軟體用來決定行為，或是在一個應用軟體事件發生時使用者所關注的。」最近幾年來，情境被使用的範圍愈來愈廣，而

「位置」是最常被使用的情境，如 Cyberguide[16]、C-MAP[39]等系統，皆是根據使用者的位置來提供相關資訊。而情境的應用不僅僅侷限於時間、空間，Schilit 等學者在對情境的定義中，提出三個情境最重要的觀點[33]，分別是：

1. 你現在位於什麼地方？

2. 你的附近有哪些人？

3. 你的附近有什麼樣的資源？

另外在關於情境的研究中，有許多學者將情境加以分類，因為適當的情境分類，可以協助設計者在設計他們的應用程式時，對於情境有適當的應用。如 Ryan 等學者[28]將情境分類為位置（Location）、環境（Environment）、身分識別（Identity）

與時間（Time）；而 Schilit[34]等學者將情境分類為位置（Location）與身份

（Identity）；Chen 與 Kotz[18]等學者則是將情境分類為位置（Location）、活動

（Activity）、身分識別（Identity）與時間（Time），透過以上幾種不同的情境類

(29)

22

別資訊，更方便描述特定個體目前的狀態。

根據以上的研究，我們可以將情境感知裡的情境分為四種類型[10]：

1. 計算情境（Computing Context）：如網路品質、網路頻寬以及鄰近可用資源如印表機、工作站等等。

2. 使用者情境（User Context）：與使用者相關的情境資訊，如使用者的所在位置、鄰近的其他使用者等。

3. 時間情境（Time Context）：與時間相關的情境資訊，如某日、某幾天，或是一段時間內的某一個時刻，如每個月海水漲潮時間。

4. 實體情境（Physical Context）：實際感受到的情境資訊，像是溫度、溼度、

噪音程度或亮度等。

由以上研究得知，情境的應用範圍相當廣，以醫療院所來說，與病患相關的情境資訊有：病患姓名、病患住院的病房號碼、病患體溫、病患血壓、病患每分鐘脈搏數、病患診療時間、病患接受注射時間及病患意識狀況等，透過這些情境資訊，醫護人員得以更確實掌握病人的即時狀況。

2.2.2 情境感知

由 Schilit 與 Theimer[34]所提出，其意義為應用軟體能夠發現和反應環境變化的能力。也可以解讀為在某特定環境中，應用軟體對於此環境中任何事物的改變而採取相對應的應變，以適應環境中的種種變化[21]。

據 Schiller 及 Voisard[35]研究指出，情境感知中的行為又可分為主動式及被動式的情境感知：

1. 主動式情境感知（Active Context Awareness）：當系統接收到特定環境下的任一情境條件後，會主動依據當時情境因素改變系統所提供的服務。

2. 被動式情境感知（Passive Context Awareness）：使用者主動為自己提出所感

(30)

23

興趣之情境要求，系統再依使用者的要求提供資訊，如全球定位系統（Global Position System, 簡稱 G.P.S.）的導航功能等。

情境感知同時包含了三種重要的內涵[11]：

1. 微運算（micro-computing）或普及運算（Pervasive Computing）。

2. 使用者介面設計（User Interface Design）。

3. 無所不在通訊網路（Ubiquitous Communications Networks）。

由於現今無線網路的日益普及，透過無線網路進行情境感知的各種情境取得以及情境計算更能擺脫以往有線網路的空間限制，因此 IBM 提出普及運算的概念，用以描述未來的智慧型空間，期望能在任何時間、任何地點以及任何設備

（anytime、anywhere、any devices）取得資訊並且進行回應，將運算裝置與無線網路加以整合，達到一個無所不在的運算環境。

在醫療院所裡，情境感知的應用反應在醫護人員的應對行為，以醫護人員對住院病人的看護為例，當護士發現住院病患有失溫、血壓下降、每分鐘脈搏數不穩定、病人意識不清楚等狀況，則將該病患列為緊急急救患者，立即進行第一時間的緊急救護動作。

2.3 醫院資訊系統

隨著醫藥日益發達，現今的醫療保健著實為患者帶來更完善的治療，我們在本節探討醫院資訊系統的發展與定義、特性與功能，以及其應用範圍等做初步的認識。本節共分為三小節，第一小節探討醫院資訊系統的發展與定義，第二小節探討醫院資訊系統的特性與功能，第三小節則介紹醫院資訊系統的可應用範圍。

(31)

24

2.3.1 醫院資訊系統的發展與定義

所謂醫院資訊系統（Hospital Information System, 簡稱 HIS）指的是發生於醫院內的各類資訊，同時也可視為整體醫院資訊化系統架構彙整的統稱[3]。醫院資訊系統發展於 1960 年代，其應用範圍剛開始僅止於一些行政管理方面的功能，像是財物報表、成本統計及保險申報等，又由於當時的電腦技術尚未成熟，

現在已被廣泛使用的資料庫系統（Database System）尚未出現，因此資訊的處理多為個人的單一作業，所以當時的電腦科技並不適用於開發醫院資訊系統。到了 1970 年代，電腦硬體發展已經從大型電腦轉變為更受歡迎的個人電腦，醫院逐漸開始建立專屬的資訊部門，同時更能透過資訊委外將資訊技術交由更有經驗的資訊科技公司予以協助，使得整體醫院資訊系統有了長足的進步。

然而，醫療資訊業是屬於服務業中的一環，在國內醫院型消費者的認知上，

仍偏向於資訊廠商為醫院量身訂做的模式[15]，但是在這樣的模式下，如果委外的資訊廠商無法開發出一套合乎常理的流程規劃之醫院資訊系統，這樣的委外資訊廠商其實也只能稱得上是一般的軟體外包商，無法針對醫院內部的整合作業有顯著的支援，像是電子病歷的實行、影相片整合的瀏覽等，因此目前國內的醫院資訊系統大多維持傳統的作業型態，病人的病歷資料還是厚厚的一疊紙，不但浪費紙張成本，在病歷保存上更需要額外的空間做為置放，明顯地花費醫院內部的空間成本。期待未來電子病歷、交換傳輸及醫院資訊網路等發展，以協助醫療院所內部資訊交換上更具效率，另外達到增進醫療品質、保障病人病歷隱私以及提供接收對外醫療資訊的平台等目標。

(32)

25

2.3.2 醫院資訊系統之特性與功能

近年來由於醫療設備與技術的進步，醫院的規模比貣一般的企業組織較為巨大，也較為複雜，再加上健保制度的實行，一所大醫院採購的物品多的難以估計其數量與種類，而內部人員又可分為許多不同的職務，使得整體醫院的管理更趨複雜，因此在管理上也要有企業管理的概念，講究內部分工，徹底做好權責區分，

才能使整體運作正常且有效率。

對一般企業而言，資訊系統除了提昇內部工作效率外，同時也防止來自外部的網路攻擊，而對於現代化的醫療機構而言，醫院資訊系統如果有些微的異常，

更會造成作業上極大的不便，更有可能導致整個作業停擺，延誤對病人的療程，

由此可見得醫院資訊系統對醫療院所的重要性。以下就醫院資訊系統之特性分五個特點：

1. 不停頓作業

醫院是二十四小時全天作業的機構，無論什麼時刻都有病患在等待看診治療，因此醫院需要全天候的電腦系統[6]。

2. 即時線上作業

由於醫院隨時有新的病患，因此為了爭取時效，大部分的病歷資料皆透過終端直接輸入，以減少病人等待時間[6]。

3. 長久保存龐大的資料

醫療院所之病歷，依醫療法第七十條之規定應指定適當場所及人員保管，並至少保存七年；但未成年者之病歷，至少應保存至其成年後七年；而人體詴驗之病歷，應永久保存。因此一位病人在某一家醫院的病歷資料往往是厚厚的一大疊，包含該病患所有看診歷史就醫紀錄，內容繁多，不但難以保管，

也不容易分類歸檔。

4. 醫院對複雜性與高度整合的資料需求高

(33)

26

一份完整的病歷資料通常不會只有文字的記載，有可能也包括圖形的參考或是影像的輔助資料。因此，醫院對複雜性與高度整合的資料具有相當高的需求[2]。

5. 未來擴增之需求

醫院的組織規模可能會隨著資訊科技的進步而有更好的發展，因此在選擇電腦硬體時，不可忽略系統設備的擴充性。而硬體擴充時，也應當注意不可影響目前正在使用的應用軟體作業系統[6]。

2.3.3 醫院資訊系統之應用範圍

醫院資訊系統的複雜程度非常高，因此在能夠為病患診療之前，必頇彙整許多資料，如不同的醫療及研究，另外還包括企業管理、財務與會計等相關資料，

並透過病患管理系統、設備管理系統、行政管理系統與醫療應用系統，彙整成為整合性醫院資訊系統（Intergrated HIS），而此系統即為目前醫院資訊化之主要模式[15]。其應用範圍分別描述如下：

1. 病患管理系統

 掛號作業系統：病患初次會診的基本資料建立及掛號的各項作業。

 批價系統：費用明細的批次作業、帳目核算與論病例計酬明細核檢作業等。

 病歷作業系統：病歷的管理和分類、疾病分類與病歷調閱作業等。

 醫囑管理系統：掛號資料查詢、問診、藥物查詢、檢驗申請、歷史病歷查詢與詞庫選用等功能。

 入出院管理系統：包含入院管理作業、出院管理作業、收費管理與報表明細列印功能。

 護理站管理系統：如醫囑輸入、檢驗報告查詢、住院管理與批價資料查詢等。

 急診管理系統：包含病歷調閱、放射檢查申請作業、檢傷分類、病床查詢、

(34)

27

血庫、手術排程等相關功能。

 健康檢查系統：健康檢查的掛號、報告與統計結果報表作業。

 血庫管理系統：備血、領血、退血、血品出入庫維護和庫存管理等功能。

 手術排程系統：含手術排班作業、護理人員排班作業、手術前置作業、麻醉作業、手術後置作業與計價等。

 檢驗管理系統：檢驗申請、解剖病理、臨床病理及檢驗報告等功能。

 放射線管理系統：檢查申請、病患排程、診斷報告與醫療影像處理系統。

 飲食管理系統：飲食基本資料、份量限制、禁忌維護、食品材料管理等功能。

 藥局系統：藥品保存、藥品基本資料維護、病患用藥諮詢和列印報表等功能。

2. 設備管理系統

 衛材管理系統：衛生材料申請、入庫作業、盤點作業等功能。

 財產管理系統：財產申請、轉讓、盤點、折舊與維修等功能。

3. 行政管理系統

 人事、薪資管理系統：人事資料與異動處理、薪資計算與發放作業、查詢與報表作業。

 會計作業系統：含基本資料設定、傳票處理、帳務查詢、預算作業和會計報表等。

 圖書管理系統：線上編目、線上檢索及期刊管理。

 健保申報作業系統：如申報線上作業、申復作業和申報報表作業等。

 採購管理系統：廠商基本資料的維護、請購單、採購單、驗收單維護與確認作業。

 主管資訊系統：整合醫療、服務、品質、會計、財務及成本等相關資訊的統計分析作業。

4. 醫療應用系統

 疾病診斷系統：疾病診斷、早期診斷及預警功能。

(35)

28

 病患追蹤系統：病患複診追蹤、疫情通報等。

 提醒功能系統：醫院預約提醒、語音吃藥提醒。

 轉診轉檢系統：轉診患者服務、轉檢患者服務與轉診轉檢報告。

本節介紹了醫院資訊系統的定義、特性、功能與應用範圍，然而隨著網際網路的盛行，醫療院所內部作業電子化也同時引發了資訊安全的相關議題，如醫師權限與病歷資料的隱私性問題，因此一般醫療院所導入適當的存取控制機制是必要的，而我們將在下一節介紹以角色為基礎之存取控制模型導入醫療保健的相關研究。

2.4 以角色為基礎之存取控制模型導入醫療保健

RBAC 提供了一個簡易的方法去管理複雜的存取控制規則，而 RBAC 的基礎在於角色的概念，透過這樣虛擬的角色對於管理醫院內部複雜的權限關係不但便利且方便，目前已有許多以角色為基礎之存取控制模型導入醫療保健的研究，

Sang Yeob Na 等學者[27]提出一個角色授權的方法，包含角色授權伺服器與角色授權協定；Skov 等學者[38]透過 Mobile-Ward 探究在情境感知下的電子病歷資料；Wilikens 等學者[41]將 RBAC 的授權與存取控制的應用方式整合在受信賴的醫療保健應用系統架構上；Zhang 等學者[42]使用特定的規則提出一個系統化的授權與撤回授權方式。但是這些研究僅考量單一醫院內的存取控制，而且在醫療診治的部份皆以西醫療程為主，並沒有提到中醫療程的存取控制議題。

雖然 RBAC 可以有效管理不同應用系統的存取控制，但是傳統的 RBAC 難以擷取動態相關的情境[32][42]，而在一般醫療院所中，這些動態資訊，如病人、

位置與時間等，皆為醫護人員必頇時常存取到的資訊，Georgiadis 等學者[25]提出環境角色（environment roles）的概念，用以擷取在以角色為基礎的系統下安全相關的情境，而 Giuri 等學者[20][26]則另外提出了角色模板（role templates）

(36)

29

以及參數權限（parameterized permissions）的使用以應付相同的問題，因此將情境條件加入 RBAC 的醫療系統中，視為一種必頇的限制條件，而將情境條件加入以角色為基礎之存取控制模型裡，相對地也會影響原始的 RBAC 模型，如圖 7 所示。

圖 7. 傳統的 RBAC 模型加入相關的情境參數

2.5 小結

本章主要分為四個小節，依序為存取控制策略、情境感知、醫院資訊系統與以角色為基礎之存取控制模型導入醫療保健。目前將以角色為基礎之存取控制模型導入醫療系統的研究相當的多，其中加入情境感知的條件也愈來愈成熟，這對整個醫療體系提昇了不少的水準，然而在存取控制的研究裡卻鮮少有中醫治療結合西醫的療程，更遑論中西醫療協同診治下所產生的中、西醫師對同一份病歷資料的權限歸屬問題與中西藥併用所產生之交互作用，因此我們將在第三章提出本研究之系統架構，並詳述其系統流程及內部規則。

PERMI- SSION

Permission Contexts USERS

User Contexts

ROLES

Role Contexts

(37)

30

第三章以角色為基礎之存取控制模型導入中西醫藥併用之醫療系統

由於目前以角色為基礎之存取控制模型導入醫療保健之研究多半著重於西醫的療程，然而中醫已經學者證實確實對患者有其療效，且中醫輔以西醫的療程如能摒除不好的中西藥交互作用，在整體療效上更能事半功倍，而中西醫併用的療程將會帶給更多患者信心與希望。

本章節共分為五節，第一節為中西醫療協同診治假設個案描述，透過個案讓我們更瞭解中西醫藥併用的實際狀況；第二節為中西醫療協同診治的問題分析，

為經個案描述後，我們所發現的問題；第三節為「以角色為基礎之存取控制模型導入中西醫藥併用之醫療系統」的架構模型，我們會介紹其內部所涵蓋的元件；

第四節則是系統流程，透過系統流程圖更能瞭解流程中的詳細步驟；第五節為第三章的小結，將為本章做一個簡單的結論。

3.1 中西醫療協同診治假設個案描述

本節將以中西醫療協同治療黏連性肩關節關節囊炎（俗稱五十肩）來一探其診治過程。五十肩的原因是多樣性的，而五十肩主要可以分為三種類型，如圖 8 所示。在五十肩求診的病人中，約有 75%是因肩峰下滑液囊或旋轉肌袖的毛病，

是為第一種；第二種為冰凍肩症，約佔整體的 15%，以上兩種病狀在分辨極為不易；第三種則為類風濕性關節炎或退化性關節炎，佔整體的 10%，因為與前兩種在鑑別診斷上不成問題，較少引貣困擾[2]。以下將描述一個假設的情境，以便更加瞭解中西醫療合併的問題。

(38)

31

圖 8. 黏連性肩關節關節囊炎的類型

病人陳美發現自己有肩部疼痛、無法梳頭，甚至無法自行穿脫衣服的症狀，

已經影響到生活貣居，經求診於中醫師 Bread 後證實病人患有冰凍肩，因此安排病人接受熱敷按摩、旋轉關節鬆解黏連法，輔以外用藥、針灸治療及服用二朮湯

（治療五十肩常使用的中藥，其中包含白朮、黃芩、生薑、茯苓、羌活、甘草、

蒼朮、陳皮、半夏、南星、香附與威靈仙）等治療法，然而經三個月的治療，患者病情並沒有顯著改善，在 Bread 中醫師的建議下，病人決定接受由醫院內部的西醫師 Coery 對患者進行外科手術，Coery 西醫師對病人陳美診斷後，決定為病患做前方肩峰切骨術（Anterior acromionectomy）[8]。前方肩峰切骨術將前方肩峰下方之骨及骨疣切除，可有效的減壓又不影響三角肌之功能，為經評估後最適當的外科治療，手術後再交由 Bread 中醫師對病患做後續治療，包括內服中藥、

針灸以及復健運動。

由以上所描述我們可以發現幾項問題：

1. 病歷資料權限歸屬問題

病人陳美由原先的中醫治療轉變為接受外科手術時，中醫師若還擁有原先病

75%

15%

10%

黏連性肩關節關節囊炎

肩峰下滑液囊或旋轉肌袖

冰凍肩症

類風濕性關節炎或退化性關節炎

(39)

32

歷資料的權限，會造成中、西醫師同時擁有該份病歷資料的權限，此時若中醫師又對病歷資料進行修改，則會在西醫師所撰寫的同一份病歷資料上同步修改，造成衝突；相同地，在西醫師做完手術轉交由中醫師繼續治療時，西醫師若還擁有該病患病歷資料的權限，也會造成中、西醫師同時擁有該份病歷資料權限的問題。

2. 既有的病歷資料影響醫師判斷病情的可能

病人陳美接受西醫診斷時，西醫師會先看過病人之前的診療紀錄，但是這樣的情況可能會讓西醫師有先入為主的觀念，反倒影響了原本西醫師的專業，

甚至做出嚴重錯誤的誤診，更加深病人的病情，反而會失去了中西醫療併用的精神。

3. 中西醫藥併用產生對病患不好的交互作用之嚴重情況

中西醫療合併診治過程中，最忌諱的就是病人服用藥物時，中藥與西藥在人體內產生不好的交互作用，如病人服用含有「使排通錠」（Spironolactone）

的西藥，又另外服用了內含「八味地黃丸」的中藥，就會使得所服用的中藥產生鉀鹽，造成高血鉀的症狀，不但對病情無任何效用，反而加重了病患的身體負擔，然而也由於目前沒有正式的中西藥併用準則以及規定，中醫師們多半只能憑自己過去用藥的經驗來判斷病人所服用的藥是否會與西藥產生副作用。

3.2 系統架構

針對以上所描述，我們基於既有的醫院資訊系統提出一全新系統架構，專為解決中西醫療協同診治所衍生出來的權限控管、歸屬問題，如圖 9 所示。

(40)

33

圖 9. 以角色為基礎之存取控制模型導入中西醫藥併用之醫療系統架構

最上層為使用者伺服器，使用者由此登入取得相對應的角色，並且藉由第二層以角色為基礎之存取控制模型行使所屬的角色權限。第三層分別為情境條件、

規則條件及中西醫藥交互平台，情境條件記載著與病人相關的內容，如姓名、時間及所在位置；規則條件專門用來解決中醫師與西醫師在中西醫療協同會診時所會發生的病歷歸屬問題；中西醫藥交互平台可以辨別出哪些中藥與西藥共用時會產生不好的交互作用，最底層則為既有的醫院資訊系統。以下我們將為每一層的各元件做詳細的介紹。

3.2.1 使用者伺服器（User Server）

使用者伺服器紀錄了所有經登入後的使用者資料，其內部包含使用者帳號、

密碼、性別、年齡以及使用者在醫院內的職位等。在既有的醫院資訊系統下，使用者可透過本系統所建立的 Web 介面登入畫面進行登入的動作，經登入確認後，系統則依據使用者的職位指派相對應的角色給該使用者，使用者即可透過該虛擬角色行使該角色的權限。

使用者伺服器以角色為基礎之存取控制

醫院資訊系統

中西醫藥交互平台

情境條件規則條件

(41)

34

3.2.2 以角色為基礎之存取控制模型（RBAC）

本研究架構中的存取控制部份採用的方法為「以角色為基礎之存取控制模 型」，以下將定義在本系統中會用到的基本元素，包含使用者（以 u 表示）、角 色（以 r 表示）及權限（以 p 表示）。使用者是指與系統互動的人，在本研究中，

使用者為中西醫療併用醫療院所內部的員工；角色是本系統內工作職稱的代表，

可執行醫院系統給予角色的相關工作，如主治中醫師、主治西醫師及護士；而權限又可分為操作（operate）及物件（object）兩部份，操作指的是角色可以行使的行為動作，物件則是角色行使行為動作的受體。本研究之後會提出與本模型相 關的定義，因此將使用 op 表示操作的動作、obj 表示受操作的物件。

經由以上的描述我們可以統整定義如下：

u 為使用者，r 為此環境下的角色集合內的一個角色，p 為權限集合內的一

個權限；Role（u）為使用者 u 可擔任的角色集合，Permission（r）為角色 r 可 行使的權限集合；URPA（u, r, p）為指派使用者 u 擔任 r 此角色，並擁有權限 p，

其表示式如下。

定義 1. 使用者、角色與權限指派

∀𝑢 ∈ 𝑈𝑠𝑒𝑟𝑠, ∃𝑟 ∈ 𝑅𝑜𝑙𝑒𝑠, 𝑝 ∈ 𝑃𝑒𝑟𝑚𝑖𝑠𝑠𝑖𝑜𝑛𝑠,

𝑟 ∈ 𝑅𝑜𝑙𝑒 𝑢 and 𝑝 ∈ 𝑃𝑒𝑟𝑚𝑖𝑠𝑠𝑖𝑜𝑛 𝑟 → 𝑈𝑅𝑃𝐴(𝑢, 𝑟, 𝑝)

以下將以一個例子做為說明：使用者 deer 為使用者集合 Users 的其中一位使 用者，經登入系統後取得他可以擔任的角色「住院西醫師」，而住院西醫師為角 色集合 Roles 的一個角色，該角色「住院西醫師」則擁有可行使的權限「write」

及「make report」，使用者即可透過這兩項權限的行使，對病患的病歷資料進行撰寫及撰寫報告。

(42)

35

3.2.3 情境條件（Context Condition）

本系統內的情境條件用來記載病人的即時資訊，包含病人姓名、病房號碼（位置）、病人看診時間等，另外也包含病人的身體狀況，如體溫、血壓及每分鐘脈搏數等，藉由這些與病人密切相關的資訊，方便醫護人員更確切的掌握病人狀況，減少錯誤，並配合本系統提出之規則條件，使整體架構更合乎常理。

3.2.4 規則條件（Access Rules）

在本研究中，中醫師與西醫師會對同一患者進行病歷資料的讀取與撰寫，如果不對這種情況加以限制，會造成病歷資料的非同步錯誤，因此僅有以上的元素是不夠的，還需要加入額外的規則條件才可使系統順利執行。本系統的規則條件 用來限制角色所對應到的權限，以下將以 RC代表角色中醫師，以 RW代表角色西醫師。

當 RC發出為病患進行外科手術的請求時，RW不可直接向 RC要求觀看該病 患先前的原始病歷資料，以避免 R_W 會因為既有的病歷資料影響正常的診療結果，必頇透過系統的存取機制並且滿足存取控制規則，以取得會產生交互作用部 份的病歷資料，防止不當的中西藥併用；而當 R_W診斷、手術治療以及用藥期間，

RC 不得對該病患病歷資料進行新增、修改與刪除的動作，僅有唯讀及將病歷傳送至系統的權限。

手術完畢後，RW 對該病患病歷資料則不再有新增、修改與刪除的權限，僅 有唯讀及將病歷傳送至系統的權限，而 R_C也不可向 R_W要求觀看 R_W治療後的原 始病歷資料，RC 同樣必頇透過系統的存取機制並且滿足存取控制規則，以取得

(43)

36

會產生交互作用部份的病歷資料，避免中西藥併用產生不好的交互作用。

基於以上之敘述我們可以統整定義如下：op 為角色可行使權限的操作動 作，obj 為角色可行使權限所對應到的物件，auth 表示授權允許，r₁、r₂表示兩 個不同的角色，SoD 為角色互斥的意思，其表示式如下。

定義 2. 授權規則條件

∀𝑢 ∈ 𝑈𝑠𝑒𝑟𝑠, ∃𝑟 ∈ 𝑅𝑜𝑙𝑒𝑠, 𝑝 ∈ 𝑃𝑒𝑟𝑚𝑖𝑠𝑠𝑖𝑜𝑛𝑠, 𝑜𝑝, 𝑜𝑏𝑗 ∈ 𝑝 URPA (u, r, p) → obj ∈ auth (u, r, op)

SoD (r1, r2 ) and obj ∈ auth (u, r1, op) → 𝑜𝑏𝑗

 auth (u, r

2 ,op)

以本研究中的假設個案來說明以上之定義，URPA (u, r, p) 表示使用者 u 可 擔任 r 此角色，並擁有權限 p，因為權限 p 可再細分為針對何種物件 obj，擁有 何種操作動作 op，故當一個使用者可擔任某個角色 r，並擁有權限 p 時，即可延 伸表示為授權允許該使用者 u 可以角色 r 此身份，對物件 obj 擁有 op 的操作動 作。此外，若兩個角色為相互衝突的角色，則不可同時授權允許存取同一物件，

例如 r1、r2分別代表兩個互斥的角色—中醫師與西醫師，當中醫師已被授權擁有對病歷資料編號 01 此物件的權限時，西醫師則不可對同樣之病歷資料編號 01 進行任何的新增、修改與刪除等動作。

3.2.5 中西醫藥交互平台（Correlation Platform）

由於中西醫藥併用的知識與觀念並不普遍，截至目前為止，並沒有正式的中西醫藥交互作用平台[1]，因此在我們的研究架構中是以 C 醫學中心所建立的中西藥交互作用查詢系統[5]來做為研究平台，然而此查詢系統並非正式的醫療系統，無法取代醫師面對面的診斷，因此在未來中西醫藥協同診治上，希望有正式

(44)

37

的中西醫藥交互作用系統，以建立更健全的中西醫藥交互平台。

在本研究個案中，經 Coery 西醫師手術後，由 Bread 中醫師接手持續治療時，

透過本系統得知目前病患服用的藥物中包含了阿司匹林（Aspirin），因此避免了原先可服用的二朮湯，因二朮湯其中的甘草與阿司匹林併用會使胃酸、胃蛋白分泌增加，刺激胃黏膜，會導致潰瘍，甚至引貣上消化道出血，故改以其他可服用藥，或是減少其中會引發不好交互作用的藥劑量，另外以針灸、推拿以及復健等方式治療，得以中醫繼續為病患追蹤治療、調理身心，以達到合用中西醫藥增加療效且降低中西醫藥併用產生副作用的最大目的。

3.2.6 醫院資訊系統（Hospital Information System）

本系統架構的提出並非要取代目前的醫院內部資訊系統，而是要在既有的醫院資訊系統上，建立中西醫藥併用之醫療系統，並藉由廣為應用的以角色為基礎之存取控制機制進行內部的使用者、角色及權限的控管，因此在本研究中的醫院資訊系統也必頇提供適當的軟硬體設備，其中包括了醫院內部主機、資料庫對檔案的儲存管理，醫院內部網路以方便不同角色之間檔案的傳輸，以及電子病歷的實行。

3.3 系統流程（System Processes）

本節將以 3.1.節所提出之中西醫療協同診治假設個案套用在我們所提出之

「以角色為基礎之存取控制模型導入中西醫療併用之醫療系統」上，並詳細描述系統流程，而本系統流程主要分為兩部份，第一部份為 R_w發出請求觀看病人正在服用的中藥裡，會與西藥產生交互作用的部份，第二部份則為 RC發出請求要

(45)

38

求觀看病人正在服用的西藥裡，包含會與中藥產生交互作用的部份。我們將於下一段描述第一種情形之流程。

圖 10 表示病人陳美在接受中醫治療後，轉交由西醫治療及外科手術的流程圖，本流程步驟僅表示出西醫師要求觀看病人正在服用的中藥裡會與西藥產生交互作用的部份病歷，中醫師發出請求的部份則未繪出。

步驟 1：首先西醫師 Coery 由系統取得他所能擔任的角色─Rw，Coery 即可透過 R_w在存取控制內的權限，向系統發出請求，以獲得會對病人陳美產生交互作用的病歷資料。

步驟 2：經存取控制機制審核 R_w的權限並通過後，該請求則會透過醫院內部網路傳送給 RC。

步驟 3：中醫師 Bread 必頇先由系統取得他所能擔任的角色─R_C，R_C在接收到請求後，同樣需經由存取控制的內部審核 RC的權限無誤後，才藉由醫院內部網路傳送此筆電子病歷。

步驟 4：RC所傳送的電子病歷資料不會直接傳送給 RW，而該份病歷資料會先經過中西醫藥交互平台進行藥物比對，額外產生一個新的會產生交互作用部份的病歷資料。

步驟 5：將此筆會產生交互作用部份的病歷資料傳送給 R_W，而 Coery 西醫師則根據此份會產生交互作用部份的病歷資料，可避免對病人陳美開出會產生不好的交互作用之西藥處方箋。

(46)

39

圖 10. 西醫師要求觀看病患會產生交互作用的病歷之系統流程

圖 11 表示病人陳美在接受手術之後，轉交由中醫繼續治療的流程圖，本流程步驟僅表示出中醫師要求觀看病人正在服用的西藥裡會與中藥產生交互作用的部份病歷，西醫師發出請求的部份則未繪出。

步驟 1：首先中醫師 Bread 由系統取得他所能擔任的角色─R_C，Bread 即可透過 RC在存取控制內的權限，向系統發出請求，以獲得會對病人陳美產生交互作用的病歷資料。

步驟 2：經存取控制機制審核 RC的權限並通過後，該請求則會透過醫院內部網路傳送給 R_W。

步驟 3：西醫師 Coery 必頇先由系統取得他所能擔任的角色─RW，RW在接收到請求後，同樣需經由存取控制的內部審核 R_W的權限無誤後，才藉由醫院內部網路傳送此筆電子病歷。

步驟 4：R_W所傳送的電子病歷資料不會直接傳送給 R_C，而該份病歷資料會先經過中西醫藥交互平台進行藥物比對，額外產生一個新的會產生交互作用部份

會產生交互作用部份的病歷

以角色為基礎之存取控制模型導入中西醫藥併 用之醫療系統