應用剖面技術支援病人隱私偏好的系統框架 - 政大學術集成

全文

(1)國立政治大學資訊科學系 Department of Computer Science National Chengchi University 碩士論文 Master’s Thesis. 立. 政治大. ‧. ‧ 國. 學. 應用剖面技術支援病人隱私偏好的系統框架. y. Nat. er. io. sit. An Aspect-Based Approach to Supporting. n. Patients' Privacy Preferences al v i n Ch engchi U 研究生：李浩誠指導教授：陳恭中華民國一百年一月 January 2011.

(2) 應用剖面技術支援病人隱私偏好的系統框架. 摘要. 近來，隨著電子病歷的日漸普及，大眾對病人隱私的關注也隨之增加。在. 政治大. 現行的醫療資訊系統 (Healthcare Information System, HIS) 中，透過適當的. 立. 權限控管機制以保障電子病歷隱私是相當普遍的作法。然而，此機制並沒. ‧ 國. 學. 有考慮到病人對於隱私資訊用途的偏好不同。因此，擴充現行醫療資訊系統的權限控管機制，以處理病人隱私偏好的需求相當迫切。. ‧. sit. y. Nat. 針對此議題，我們認為剖面導向程式設計 (Aspect-Oriented Programming) 技術可以成為其解決方案的重要一環。本研究試著實作一個剖面導向的管. er. io. 理框架，在無需大幅度改寫系統的前提之下，能夠和現有的醫療資訊系統 a. n. iv l C n 整合，達到讓病人自訂及管理隱私偏好。該框架和現行系統的關係是鬆散 hengchi U 耦合 (loosely coupled) 的，因此，能夠輕易地用來擴充現行的系統，以便達到支援病人自定隱私偏好的目的。. I.

(3) An Aspect-Based Approach to Supporting Patients' Privacy Preferences. Abstract. 政治大. Electronic health records are getting more and more popular these days, however,. 立. concerns for patients' privacy also increase greatly. Currently, it's not unusual for. ‧ 國. 學. Healthcare Information System (HIS) to adopt a proper access control mechanism to protect patients' electronic health records. Nonetheless, this. ‧. design did not consider the requirements of supporting patients’ preferences. y. Nat. io. sit. regarding the use of their privacy information. Hence, it is desirable to extend. er. the original access control system to handle patients' privacy preferences.. al. n. v i n C hAspect-OrientedUProgramming (AOP) can be an For this issue, we argue that engchi important part of the solutions. This thesis presents an aspect-based preference management framework that collects and manages patients' preferences. It can be integrated with the existing HIS to support patients' privacy preferences without rewriting from scratch. The proposed mechanisms are loosely coupled with the underlying system. It is therefore easier to use it to improve existing systems to support patients’ privacy preferences.. II.

(4) 誌謝. 工作多年之後，能夠有機會再回到大學時的母校繼續攻讀碩士學位，感到既興奮又緊張，興奮的是能夠有機會重回學校學習新的知識；緊張的是白天要上班，晚上要上課，不知道是否能夠兼顧。所幸，在學期間能夠接受陳恭老師的指導，老師不只是學識和經歷豐富，上課也相當. 政治大. 生動有趣。在老師的教誨之下，不但讓我學到思考和解決問題的方法，也加強在工作. 立. 上實務有餘，理論不足的部份。在老師的課堂上還學到函式導向程式語言 (Functional. ‧ 國. 學. Programming) 程式語言，讓我大開眼界，了解到除了主流的物件導向程式語言之外，還有其他思考方向以及可能性。而在論文研究和撰寫的時候，老師針對論文題目和方. ‧. 向給予相當多的建議和指導，讓我能夠順利完成學業和論文。在此要向老師致上最誠. er. io. sit. y. Nat. 摯的感謝！. al. 此外，還要感謝一起上課的同學們，日晟、珮華、欣瑜、斐瑜、瀛心和裕章，有你們. n. v i n Ch 陪伴一起學習和分享，讓我在就學的這段期間成長了許多。 engchi U. 最後，要感謝我的父母和老婆巧玉的大力支持，讓我能夠安心完成學業，謝謝你們！. 國立政治大學. 李浩誠. 資訊科學研究所在職專班中華民國一百年一月. III.

(5) 第1章緒論 ............................................................................................................................................ 1 1.1 研究背景 ..................................................................................................................... 1 1.2 研究動機 ..................................................................................................................... 2 1.3 研究目的 ..................................................................................................................... 3 1.4 論文貢獻 ..................................................................................................................... 3 1.5 章節架構 ..................................................................................................................... 3 第2章. 立. 政治大. 相關研究與技術背景 ................................................................................................................ 4. ‧ 國. 學. 2.1 相關研究 ..................................................................................................................... 4 2.1.1 XACML............................................................................................................. 4. ‧. 2.1.2 EPAL.................................................................................................................. 8. y. Nat. io. sit. 2.2 AOP/AspectJ 技術介紹.............................................................................................. 10. n. al. er. 2.3 Spring/Hibernate/Wicket 技術介紹 .......................................................................... 14. Ch. i n U. v. 2.3.1 Spring .............................................................................................................. 14. engchi. 2.3.2 Hibernate ......................................................................................................... 16 2.3.3 Wicket.............................................................................................................. 18 第3章系統設計與架構 ...................................................................................................................... 20 3.1 設計理念 ................................................................................................................... 20 3.2 病人隱私剖面 ........................................................................................................... 24 3.3 行動目的管理員 ....................................................................................................... 26. IV.

(6) 3.4 病人偏好管理員 ....................................................................................................... 28 第4章系統實作與展示 ...................................................................................................................... 31 4.1 設定病人隱私剖面 ................................................................................................... 31 4.2 管理行動目的 ........................................................................................................... 35 4.3 管理病人偏好 ........................................................................................................... 38 4.4 系統展示 ................................................................................................................... 41 第5章. 立. 政治大. 結論 .......................................................................................................................................... 46. ‧ 國. 學. 5.1 結論 ........................................................................................................................... 46 5.2 未來發展 ................................................................................................................... 47. ‧. Nat. y. 第6章. n. al. er. io. sit. 參考文獻 .................................................................................................................................. 48. Ch. engchi. V. i n U. v.

(7) 第1章緒論 1.1 研究背景近年來，歸功於電子病歷的諸多優點，例如改進傳統手寫紙本病歷因醫囑字跡潦草難以辨識的缺點、易於保存和備份、虛擬儲存比實體儲存空間要便宜等等，造成電子病歷的導入日漸普及。更重要的是，藉由整合分散於各醫療院所的病歷資料，可以減少. 政治大. 醫療資源的浪費，而且導入適當的醫療資訊科技，更可以提昇醫療服務的品質，因此. 立. 電子病歷的研究已是醫院資訊系統發展的趨勢，根據行政院衛生署 94 年 12 月完成的. ‧ 國. 學. 「醫療院所病歷電子化現況調查」，顯示國內醫院病歷電子化發展已相當普及，約有 5 成醫院的病歷資料已進行電腦化，3 成左右的醫院病歷電子化已進展至院內整合階段並. ‧. 逐漸朝向院際之分享與交換應用目標前進 [1]。. Nat. sit. y. 此外，衛生署於 2004 年 10 月開始規劃「國民健康資訊建設計畫（National Health. n. al. er. io. Informatics Project，NHIP）」，其中一項重要的目標便是促進整體醫療院所內部病歷電. i n U. v. 子化進而架構出醫療院所之間電子病歷交換環境，也希望病歷內容可讓病人持有，隨. Ch. engchi. 時掌握自己的健康狀況，這在紙本病歷時代都是難以輕易達成的。在持續的努力之下，於民國 96 年 8 月 14 日核定通過 NHIP 計劃，由政府扮演推動的角色，營造國家健康資訊發展環境，同時推動衛生醫療資訊的重要基礎建設。其中，「推動實施電子病歷」與「建立及營運醫事憑證管理中心 (Healthcare Certification Authority，HCA )」同為 NHIP 的兩大分項計劃，希望能在充份保障個人健康資訊隱私的前提之下，提昇醫療資源運用效能、服務品質及病人安全，達成全民健康資訊ｅ化流通的願景 [1]。. 1.

(8) 1.2 研究動機相較於其他資訊，醫療資訊是重要而且相當敏感的。電子病歷可以使醫院提供的醫療服務更加安全有效率，但是如果沒有適當的保護措施，也有可能會危及到個人隱私。電子醫療資訊的交換雖然能對個人隱私權帶來許多好處，但同時也可能構成更大的威脅 [2]。一般普遍認為，方便的資訊科技例如 Google, Facebook 的流行，是讓現在人失去隱私的主要原因之一，不過水能載舟亦能覆舟，資訊科技也可以促成更健全的隱私權控管機制。事實上，關於醫療機構應該如何利用可辨識身份的個人隱私資訊的重. 政治大. 要原則是，每個人都要能夠決定個人隱私資訊可以在什麼場合、因為什麼目的而被使. 立. 用 [3]。如果是用紙本來實行這個原則的話，不但費時費力，而且很明顯地會產生龐大. 學. ‧ 國. 的管理成本。相反的，適當利用資訊科技的話，就能在可接受的成本條件下，在現行醫療資訊系統中實現。. ‧. 此外，即使現今社會大眾對隱私權的關注日益升高，但是大多數病人到醫院看病的時. y. Nat. sit. 候，通常都不清楚自己的隱私資料將會被用在什麼地方或是作為什麼用途，更別提要. n. al. er. io. 如何表達自己對隱私權的偏好了。因此可以預見的是，在很多細節達成共識之前，不. i n U. v. 論是相關法令條文、社會共識或是醫療資訊系統 (HIS) 都會經歷一個不斷修正的漫長. Ch. engchi. 過渡時期。然而，醫療資訊系統的可靠度是最重要的要求，稍有不慎的系統錯誤造成的影響難以估計，例如 2007 年台大醫院的醫療資訊系統僅僅當機 4- 5 個小時，受到影響的民眾人數就超過 8000 人 [4]，因此不斷修改或重新設計/改寫整個系統幾乎是不可行的。由此可知，要將隱私權偏好納入醫療資訊系統的權限控管機制中，主要的困難點在於，如何不影響醫療機構需要的系統穩定度，又能夠和不斷演進的法令條文和社會共識一起前進，以便順利的度過過渡期。. 1.3 研究目的. 2.

(9) 本研究的主要目標如下: 1. 將病人隱私偏好納入醫療資訊系統的存取控管機制 2. 利用剖面導向程式設計 (AOP)，達到無需大幅度改寫現行醫療資訊系統即能擴充存取控管機制的目的 3. 實作一個完整的系統框架，驗證此構想的可行性. 1.4 論文貢獻. 政治大行選擇隱私權用途的功能列入考慮。達到此目的的重點在於必須將隱私權控管的機制立. 本研究利用剖面導向程式設計 (AOP)，建立病人隱私控管和稽核機制，同時將病人自. ‧ 國. 學. 和現行的醫療資訊系統的設計分開，以免牽一髮而動全身，但是兩者又必須能在系統中共同運作，而剖面導向程式設計讓這點變得可行。在現行的醫療資訊系統中，傳統. ‧. 的存取控制機制無法將病人本身對隱私權的偏好納入考慮，剖面導向程式設計將是加. sit. y. Nat. 強隱私方面存取控管一個很好的方式。本研究試著實作一個剖面導向的管理框架，在. io. er. 無需大幅度改寫系統的前提之下，能夠和現有的醫療資訊系統整合，達到讓病人自訂. al. v i n Ch 的，因此，能夠輕易地用來擴充現行的系統，以便達到支援讓病人自定隱私偏好的目 engchi U n. 及管理隱私偏好。該框架和現行醫療資訊系統的關係是鬆散耦合 (loosely coupled). 的。. 1.5 章節架構本研究的其他章節摘要如下：第 2 章介紹 AOP 和 AspectJ，這是用來實現系統框架的程式語言。還會介紹 Wicket/Hibernate/Spring 等 Java 界常用的技術框架。第 3 章是該系統框架的架構與設計。第 4 章是解釋如何實作此系統框架，重點在實作的細節以及設計的考量。第 5 章結論將會討論提出的系統框架和未來可能的發展。第 6 章是參考文獻列表。 3.

(10) 第2章相關研究與技術背景 2.1 相關研究本論文有關權限控管架構將採用業界標準 XACML [5] ，在 2.1.1 小節將會介紹 XACML 標準的主要內容以及架構。此外，在指定隱私權規則的部份，則是採用 EPAL 標準 [6]，這會在 2.1.2 小節簡介。. 政治大. 在 “Modelling Access Control for a Complex Healthcare Organization” [25] 中，作者改進. 立. 了常用的 RBAC (Role-Based Access Control) 機制，但是並未將目的列入存取控管考慮. ‧ 國. 學. 的因素之中；此外，該研究從系統建立初期就進行存取控管機制設計，而本論文希望能在無需大幅度改寫的前提下改進現行系統的方向，相比之下會更加有彈性。而在. ‧. “Authorisation and access control for electronic health record systems” [24]，該研究著重於. y. Nat. n. al. 2.1.1 XACML. Ch. engchi. er. io. 論文較為偏重系統實作的方向也不盡相同。. sit. 如何將 System Modeling 的方法論 (methodologies) 應用到權限存取控管機制裡，和本. i n U. v. XACML 是 eXtensible Access Control Markup Language 的縮寫，是以 Security Assertion Markup Language (SAML, 安全宣示標示語言) 為基礎延伸發展，以 XML 實作的宣告式權限控管政策的語言 (declarative access control policy language)。最新的 XACML 2.0 在 2005 年 2 月成為 oasis (Organization for the Advancement of Structured Information Standards) [7] 標準。使用 XACML 有下列幾項好處 [8]： . 是業界標準，不需要再自己重新打造類似的解決方案，省時省力，而且提供跨 4.

(11) . 支援分散式的政策，當你在建立一個政策的時候，可以引用另一個放置在其他、方的政策. . 功能強大，語言本身就內建了各式各樣的型別、函數以及規格，讓你可以自由組合，建立新的政策。此外，還有讓 XACML 和 SAMP 或是 LDAP 並存的擴充套件，都讓 XACML 應用的領域更加擴大. . 定義了一種通用的政策語言，不再只適用某些特殊的環境或是資源. . 政策管理點(Policy administration point, PAP)：建立單一政策(policy)或政策集合. 政治大在 XACML 中定義了下列幾個術語 [9]: 立. ‧ 國. 學. (policy set) 的系統實體. ‧. . 政策執行點(Policy enforcement point, PEP)：依照既定的授權決策來執行存取控. y. Nat. er. io. PDP 的決策行動). sit. 制的系統實體 (即接收對授權的請求。PEP 向 PDP 發送 XACML 請求，然後根據. al. n. v i n C hpoint, PDP)：PDPU使用從 PAP 獲得的策略以及從 PIP 政策決策點(Policy decision engchi. . 獲得的訊息來進行決策的系統實體. . 政策資訊點(Policy information point, PIP)：PIP 可提供被存取資源的屬性，以及試圖存取該資源的實體 (身份證明). 5.

(12) XACML 的 Data Flow 如圖 2-1 所示：. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 2-1: Data Flow of XACML [5]. Data Flow 說明如下： 1. PAP 建立授權單一政策(policy)或政策集合(policy set) 讓 PDP 可以使用，這些授權政策代表了對特定目標(target) 的管理方式 2. 存取請求者 (例如應用程式) 送出存取請求到 PEP 3. PEP 將收到的存取請求，依原有請求格式送出給 context handler，包含 subjects, 6.

(13) 4. 從 PIP 要求 subjects, resource 和 environment 的屬性值 5. PIP 取得所要求的屬性值 6. PIP 將取得的屬性值回傳到 context handler 7. Context handler 可以選擇是否將 resource 包含在 context 中. 政治大. 8. Context handler 送出包含目標的決策請求 (decision request) 到 PDP，PDP 依據. 立. 申請的政策從 context handler 取得需要的屬性值，然後評估是否要授權. ‧ 國. 學. 9. PDP 回傳授權評估結果到 Context handler. sit. y. Nat. PEP. ‧. 10. Context handler 將收到的 XACML 格式的回覆轉換成原先請求的格式之後再傳到. n. al. er. io. 11. PEP 依收到的內容執行「責任 (obligations)」 (即允許請求者存取資源與否). i n U. v. 12. (未出現在流程圖中) 如果該訊息的授權評估結果為允許，則允許請求者做資源. Ch. 存取，否則中斷存取動作. engchi. 舉例來說，當有使用者試圖存取檔案系統上的一份文件時，就會發出一個請求到保護該文件的裝置 (可能是一台伺服器)，也就是政策執行點 (Policy Enforcement Point, PEP)。政策執行點會根據請求者的身份、請求的文件類型、動作以及附加訊息來建立一個請求 (request)，然後政策執行點會將該請求發送到政策決策點 (Policy Decision Point, PDP ) 去。PDP 會評估該請求以及一些相關的存取控管政策，並回覆該要求是否合法。這個回覆會送回到政策執行點，通知使用者是否允許存取該份文件。. 7.

(14) 2.1.2 EPAL EPAL (Enterprise Privacy Authorization Language) 是 IBM 開發的「企業隱私授權語言」，是用來撰寫企業內隱私權政策的正式語言，讓資訊部門可以根據細緻的正反面授權規定來管理企業內部的資料存取。 EPAL 表達式的需求 [10]: 1. 使用者可以設定預設的存取規則是「允許」或「拒絕」，也可以不設定預設值. 政治大 (set of purpose) 中的某個目的，對類別集合 (set of category) 中的某個類別，執立. 2. 每個規則都可以允許一個使用者類別集合 (set of user categories)，為了目的集合. ‧ 國. 學. 行行動集合 (set of action) 中的某個行動. 3. 每個規則可以包含先決條件 (conditions)，如此一來只有在該先決條件成立的情. ‧. 況下，這個規則才會生效. y. Nat. n. al. er. io. 被執行. sit. 4. 每個規則可以指定責任 (obligations)，表示如果該行動執行的話，該責任也必須. Ch. 5. 可以藉由指定規則優先順序 (precedence) 況. engchi. iv n 的方式來解決可能發生的規則衝突情 U. 6. 撰寫 EPAL 的人必須能夠加入註解、參數和現在無法預測的額外資訊下列是個簡單的 EPAL 範例：. 在病人同意的前提之下，允許醫生或是護士因為提供醫療服務的目的列印病歷資料。必須刪除 3 年前的資料。. 8.

(15) 此範例中的 EPAL 規則解釋：. 欄位. 屬性值. 規則. 允許. 使用者類別. 醫護人員. 行動. 列印. 資料類別. 病歷資料. 目的. 提供醫療服務. 先決條件. 病人同意該使用目的. 責任. 必須刪除 3 年前的資料. 立. 政治大. ‧ 國. 學. 有了 EPAL 規則之後，當有存取資料的請求 (request) 進來的時候，就可以根據此規. ‧. 則來判斷是否允許該請求。請求的範例如下：. y. sit. n. al. er. 屬性值. io. 欄位. Nat. 醫生因為提供醫療服務而需要列印病人的病歷資料. 使用者類別. 醫生. 行動. 列印. 資料類別. 病歷資料. 目的. 提供醫療服務. Ch. engchi. i n U. v. 將該請求與 EPAL 規則比對之後，系統會知道可以允許請求，然後該業務人員就可以讀取到客戶的 email 資料。. 9.

(16) 2.2 AOP/AspectJ技術介紹在企業應用程式 (Enterprise Application) 中，除了必須的業務面功能需求之外，通常還會有權限控管 (access control )、交易控制 (transaction) 與記錄檔 (log) 等非功能性的需求。這類需求有一個共通的特點，就是在應用程式內的各個模組之中都會用到，改一個程式碼就要到各模組修改，不容易集中維護。在軟體開發的文獻中，通常稱這類需求為應用程式的橫跨性關注 (Crosscutting concerns) [11]。現今應用廣泛的物件導向程式設計 (Object-oriented programming) 對這類問題無法提供有效的封裝與模組化支. 政治大. 援，使得實現此類需求的程式碼必須重複出現於各個功能模組中，與其他程式碼糾結. 立. 在一起；雖然物件導向程式設計可以將相同的程式碼放到同個類別 (class) 中開發維. ‧ 國. 學. 護，但是使用的時候還是要手動呼叫該類別中的函數才行。舉例來說，下面的程式碼摘錄自 Java SE 6 標準函式庫的 java.io.File (http://download.java.net/openjdk/jdk6/)，呼. ‧. 叫 Java 安全服務 (System.getSecurityManager()) 的相同程式碼(圖 2-2 紅色框線部份)總. n. al. er. io. sit. y. Nat. 共有 24 次：. Ch. engchi. i n U. 圖 2-2 java.io.File. 10. v.

(17) 如果想要修改 java.io.File 類別中的 Java 安全服務相關程式碼，就必須 24 個地方都要去改，而且還要小心所做的修改不能影響到其他部份，增加了維護程式的困難度。最理想的情況是將這段程式碼拉出來變成一個獨立的模組，再設定讓該模組的程式碼自動套用到那 24 個需要呼叫的位置。這樣一來不但比較容易維護和修改，也符合模組化程式設計的精神。上述正是剖面導向程式設計 (Aspect Oriented Programming, AOP) [12] 試圖要解決的的問題。剖面導向程式設計的目的是將橫跨性關注予以模組化，例如權限控管 (access. 政治大需求較不相關的功能。在剖面導向程式設計 (AOP) 中，一個程式包含了許多功能模組立 control )、交易控制 (transaction) 與記錄檔 (log) 這些遍佈應用系統，但是和系統核心. ‧ 國. 學. (基本程式) 和一些封裝橫跨性關注 (crosscutting concerns)的剖面 (Aspects)。一個剖面 (Aspect) 模組提供了三種規格，以便實現基本程式中的橫跨性關注。第一個是切入點. ‧. (pointcut)，切入點會選擇一套在程式執行中明確定義的連接點 (join points)，指定在哪. sit. y. Nat. 個位置橫切到其他模組。第二個是意見 (advice)，是當切入點遇到任何連接點時會執行. al. er. io. 的一段程式碼。第三個是類型之間的宣告 (inter-type declarations)，定義在基本程式中. v. n. 的靜態類別階層上操作的橫跨性關注。圖 2-3 顯示 AOP 如何在應用程式中整合不同模組：. Ch. engchi. 11. i n U.

(18) 立. 政治大. ‧ 國. 學. 圖 2-3 以剖面導向程式設計整合企業應用程式中的不同模組 [13]. ‧. y. Nat. 基本上，剖面導向程式設計中所謂的織入 (weaving) 就是根據剖面 (Aspects) 中定義. er. io. sit. 的規格，組合功能模組和剖面來產生完整的程式。這樣一來，當剖面 (Aspects) 中的規格有修改的時候，織入 (weaving) 會讓功能模組也做出相對應的修改。. al. n. v i n Ch AspectJ [14] 是和 Java 程式語言整合良好的一個剖面導向擴充。AspctJ 利用功能強大 engchi U 的連接點 (jointpoint) 模型提供了一個切入點 (pointcut) 語言。在 AspectJ 中常用的連接點是方法 (method)、建構子 (constructor) 的執行以及存取欄位 (field) 等等。切入點 (pointcut) 前後的資訊稱為 thisJointPoint，我們可以透過切入點 (pointcut) 將這些資訊傳遞到意見 (advice) 中。意見 (advice) 是 AspectJ 中的一個匿名方法 (anonymous method)，和切入點連結在一起，並標記下列三個關鍵字其中之一：before, after 或 around。顧名思義，before 表示在連接點(join points) 之前、after 是在連接點 (join points) 之後執行，around 比較特別，在 around advice 內，我們可以藉著呼叫內建的. 12.

(19) proceed() 繼續執行該方法，或是乾脆不執行。在 AspectJ 中，織入 (weaving) 的工具和 AspectJ 的編譯器 ajc 整合在一起，所以把剖面 (Aspects) 編譯成 bytecode 的時候就一併執行織入 (weaving) [15]。此外，AspectJ 的類型之間的宣告 (inter-type declarations) 允許程式設計師新增需要的方法 (method) 和欄位 (field)，並且把這些新增的方法和欄位跟現有程式連結起來，因此不需要修改現有程式就可以擴充該程式的功能。AspectJ 也允許提供一個有抽象切入點 (Abstract pointcuts) 和抽象方法的抽象剖面 (Abstract aspects) 讓子剖面 (sub-aspect). 政治大 (generic aspect) 的功能對應用框架來說很重要。立. 繼承，然後在子剖面中撰寫實作的切入點 (pointcut) 和方法。這種可以建立泛用剖面. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 13. i n U. v.

(20) 2.3 Spring/Hibernate/Wicket 技術介紹本論文在實作網頁應用程式的時候，廣泛應用了 Spring (http://www.springsource.org/), Hibernate (http://www.hibernate.org/) 和 Wicket (http://wicket.apache.org/) 等幾個 Java 界常見的開放原始碼 (open source) 框架 (framework)，在這一章節將會針對各框架進行概略的介紹。. 2.3.1 Spring Spring. 政治大 http://java.sun.com/j2ee/overview.html) 立. 是由 Rod Johnson 開發，一個分層式 (layered) 的 Java/J2EE (Java 2 Platform,. Enterprise Edition,. 應用程式平台 (application. ‧ 國. 學. platform)，Rod Johnson 會想建立 Spring 的原因是當時要開發 EJB 2.x (Enterprise JavaBeans, http://www.oracle.com/technetwork/java/index-jsp-140203.html) 應用程式不但. ‧. 繁瑣，而且需要搭配笨重(通常也不便宜)的應用伺服器 (Application Server)，像是. sit. y. Nat. Websphere, Weblogic 等，因此 Spring 就是希望能減輕軟體工程師開發企業應用程式. io. al. n. . er. 的負擔。Spring 包含了下列功能:. i n U. v. 輕量級的容器 (lightweight container): 針對應用程式中的物件提供了集中而且自. Ch. engchi. 動化管理的機制。該容器並不具有擴散性 (non-invasive)，能把一群鬆散藕合的 Plain Old Java Object (POJO) [16] 以一致且透明的機制組合，進而構成複雜的企業應用系統。 . 交易管理 (transaction management): 允許可以置換交易管理員 (transaction managers)，而且 Spring 的好處是並不會限制必須使用特定 J2EE 環境才能支援交易管理機制。. . JDBC. (Java. Database. Connectivity,. http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136101.html) 抽象層: 14.

(21) . 與 ORM (Object-relational mapping) [17] 整合: Spring 可以和大多數常用的解. ORM. 決. 方. 案. 整. 合. ，. 例. 如. Toplink. (http://www.oracle.com/technetwork/middleware/toplink/overview/index.html), Hibernate, JDO (http://www.oracle.com/technetwork/java/index-jsp-135919.html) 和 MyBatis (http://www.mybatis.org/)，不需要擔心用了 Spring 之後不能採用習慣的. 政治大. ORM 框架。. 立. 支援 AOP (Aspect Oriented Programming) 功能: Spring 對 AOP 有完整的支，. 的. Spring. AOP. 會. 實. 學. 援. ‧ 國. . 作. AOP. Alliance. (http://www.sourceforge.net/projects/aopalliance ) 所規範的介面，AOP Alliance 是. ‧. 由許多團體所組成的聯合計畫 (Joint project)，對於 AOP 的實作會要求必須遵. Nat. sit. y. 守所制訂的介面規範，目的是希望讓 Java 的 AOP 實作介面標準化，以達到. n. al. er. io. AOP 實作在不同的 Java 應用程式之間的可移植性 (portability)。 . Ch. i n U. v. 彈性的 MVC (Model–View–Controller) [18] 網頁應用程式框架 (web application. engchi. framework): Spring 本身提供了一套完整、容易客制化的 (configurable) MVC 網頁應用程式框架，但是 Spring 也支援其他常見的網頁應用程式框架，像是 Struts (http://struts.apache.org/ ), Tapestry (http://tapestry.apache.org/), Wicket 或是 GWT (http://code.google.com/webtoolkit/ )。. 15.

(22) 2.3.2 Hibernate Hibernate 是「物件/關聯對應」 (Object-relational mapping, ORM) 的解決方案，簡單的說就是將 Java 中的物件與物件關係，對應到關聯式資料庫 (Relational Database, RDBMS) [19] 中的資料表 (Table) 與資料表之間的關係，而 Hibernate 提供了自動轉換的功能。為什麼需要「物件/關聯對應」 (ORM) 的解決方案呢？在企業應用程式中，不可避免的需要儲存和讀取資料，例如客戶資料或是訂單資料等等，因此在程式結束之後，資料. 治政仍然能夠繼續存在就是相當重要的一個要求，也就是所謂的「永續儲存」(Persistence)。大立問題出在目前廣泛使用的物件導向程式語言，像是 Java, C++ 或是 .Net 中，軟體工程 ‧ 國. 學. 師是以物件為基礎來建構程式，這和關聯式資料庫中的資料表是相當不一樣的結構，. ‧. 也就是所謂「物件/關聯式本質不相配」 (Object-Relational Impedance Mismatch) [20] 問題，造成軟體工程師花許多時間處理物件和資料表之間不同格式的資料轉換。ORM 正. y. Nat. n. 將程式設計與底層的關聯式資料庫分開，提供了將來因應需求改變可以抽換資料庫軟體的彈性。. . al. er. io. . sit. 是為了解決此問題發展出來的，採用 ORM 的好處有下列幾項：. Ch. engchi. i n U. v. 採用對軟體工程師較為直覺的方式來存取資料，不再需要手動處理繁瑣的物件和資料表轉換，程式設計相對簡化。. . 通常 ORM 框架會包含 Connection Pool [21]. 機制，因此程式的延伸性. (scalability) 較佳目前 Java 界常見的 ORM 框架有 Toplink, Hibernate, JDO 和 MyBATIS 等，那選擇 Hibernate 有哪些好處呢？. 16.

(23) . 自然的語言模式: 首先，Hibernate 支援 Java 語言中的繼承 (inheritance)、多型 (polymorphism)、組合 (composition) 和 Java Collection Framework，因此軟體工程師在 Java 中所有物件之間的關係都可以完整跟關聯式資料庫中的資料表相對應。. . 透明的永續儲存: Hibernate 並不要求 Java 物件繼承 Base Class 或是實作某些介面 (Interface) 才能夠被對應到資料表，這樣對只支援單一繼承 (Single Inheritance) 的 Java 來說是比較有彈性的作法。. . 政治大. 更好的效能: Hibernate 預設會使用延遲初始 (lazy initialization) 機制，也就是物. 立. 件只有在使用到的時候才會載入到記憶體中，這樣可以增進效能以及減少記憶. ‧ 國. 學. 體的使用。. 可靠性和延伸性 : Hibernate 的設計就是能在伺服器叢集 (application server. ‧. . cluster) 中使用，因此具備了高度的延伸性。. sit. y. Nat. . 完整的查詢語言: Hibernate 總共支援 Hibernate Query Language (HQL), Java. n. al. er. 可擴充性: Hibernate 很容易就能客制化和擴充功能。. io. . Ch. engchi. i n U. v. Persistence Query Language (JPAQL), Criteria queries, 和原生的 (native) "SQL" 等各種查詢語言。. 17.

(24) 2.3.3 Wicket Java 界的網頁應用程式框架有數十個之多，主要分成兩大類，一種是 Request based，共同的地方是 API 主要以剖析 HTTP Request 和產生 HTTP Response 為主，Struts 和 Spring MVC 是主要的代表；另外一種是 Component based [22]，比較普遍的有 JSF. (Java. Server. Faces,. http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html), Tapestry 和這邊要介紹的 Wicket。 Wicket 是 Apache 基金會. 立. 治政 (http://www.apache.org/) 大下的一個專案，是個輕量級的. 網頁應用程式框架，特色是把開發網頁應用程式抽象化，轉變成類. 學. ‧ 國. Component based. 似撰寫 Java Swing (http://download.oracle.com/javase/tutorial/uiswing/) 應用程式，透過. 徹底的物件導向: 在 Wicket 裡面，所有東西都是物件，頁面 (Page) 是物件，. sit. y. Nat. . ‧. 建立元件 (Components) 來構成網頁，Wicket 有下列優點:. io. er. 頁面上的每個元件像是按鈕 (Button)、下拉式選單 (Drop-down choice) 等也都. al. 是物件，好處是程式共用會很方便，只要把重複的程式碼寫在一個元件裡面，. n. v i n Ch 然後根據需求放到不同的頁面上就可以了；此外因為是 Java 程式，所以元件之 engchi U 間也可以繼承或是實作介面，增加應用程式的彈性。 . 將表達層 (presentation layer) 分開處理: Wicket 中每一個 HTML 檔案都一定會有相對應的 Java 類別，而 HTML 裡面只需要寫 <p wicket:id=“componentId”> contents... </p> 這樣的 tag 來跟 Java 類別中的元件對應，除此之外不會摻雜 Java 程式，因此不會像傳統的 JSP 中同時包含 HTML 語法和 Java 程式，不但增加修改的困難度，也讓軟體工程師和介面設計者 (UI Designer) 的合作變得較為困難。 18.

(25) . 含有狀態 (stateful): 傳統的 HTTP 是不含狀態的 (stateless) [23]，但是 Wicket 將 component 包裝成含有狀態 (stateful) 的，寫企業應用程式的時候非常方便，我們可以把使用者的帳號和訂單資料都紀錄在 Session 裡，要用的時候直接拿出來，不需要再去資料庫存取，省了很多工夫。. 下面是個用. Wicket 寫的簡單網頁範例，可以看出只要在. wicket:id=“message” ，再到. Java 類別裡加上. HTML 裡寫. id=“message” 的. (http://wicket.apache.org/apidocs/1.4/org/apache/wicket/markup/html/basic/Label.html). 政治大. 件，Wicket 就會把兩者關連起來，在頁面上顯示出 “Hello World” 訊息：. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. i n C h圖 2-3 HelloWorld.html engchi U. 圖 2-4 HelloWorld.java. 19. v. Label 元.

(26) 第3章系統設計與架構本章節會說明應用剖面技術的系統框架中的設計與架構，解釋如何在現有的醫療資訊系統中，加入尊重病人隱私權的設計。3.1 小節會說明設計理念以及提議的隱私權框架，3.2 小節會介紹行動目的管理員 (Action Purpose Manager) 設計。3.3 小節則是病人偏好管理員 (Patient Preferences Manager)，最後 3.4 小節是有關病人隱私剖面 (Aspect) 的設計。. 立. 3.1 設計理念. 政治大. ‧ 國. 學. 目前在一般的企業應用程式中，採用適當的存取控管 (Access Control) 機制以保障使. ‧. 用者資料是必須的作法；同樣的，在大多數醫療資訊系統 (Healthcare Information. sit. y. Nat. System) 中，使用相同機制保護病人的電子病歷也是普遍接受的準則 [24][25]。然而，. io. er. 現有的存取控管機制很少把病人對自身隱私資料的不同需求或是偏好納入考量。事實. al. n. 上，現有的存取控制機制通常只處理了「什麼角色的人員是否能存取資料」這類的簡單. i n C 規則而已，圖 3-1 是傳統存取控制機制運作的圖示。 hengchi U. 圖 3-1 傳統的存取控制機制. 20. v.

(27) 然而如果要尊重病人隱私權偏好，就必須將「什麼角色的人員能夠存取哪些病人的隱私資料」，以及「那些資料是因為什麼樣的目的允許被使用」，這些複雜的問題都納入系統的設計之中，因此隱私權保護遠超出傳統存取控制機制所能處理的範疇，圖 3-2 是我們希望建立的權限控管機制圖示。最近的存取控管機制的趨勢是，是否允許存取或是使用任何隱私資料的判斷應該依照使用資料的目的來決定 [26]。舉例來說，醫生在看診或是提供醫療服務的情況下，就可以存取病人資料，但是為了研究目的或是推廣健康食品的話，該存取請求就會被拒絕。此外，系統應該要考慮到病人的隱私偏好，. 政治大被那些人存取使用會有不同的看法。換句話說，決定是否允許存取病人的個人識別資立. 因為每個人對其個人識別資訊 (Personally identifiable information) [27] 能在什麼情況下. 訊應該要將上述的因素都列入判斷：也就是說，不只是看個人隱私資料的內容和使用. ‧ 國. 學. 目的，更要根據不同病人的偏好來決定。. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 3-2 理想的存取控制機制. 把病人隱私偏好加進系統之後，還必須考慮在遇到特殊情況的時候，能夠在病人的生命安全和尊重隱私之間取得適當的平衡。尤其在緊急情況下，主治醫師需要能夠選擇略過系統中所有的存取控管機制，以便給予病人適當且及時的治療，避免因為行政作業或系統限制而延誤，通常稱這種作法是「打破玻璃政策」 (break glass policy) [28]。 21.

(28) 然而，一旦有醫師或是護理人員利用特殊請求進入系統存取資料的時候，存取控管機制必須鉅細靡遺的紀錄所有日後稽核所需的資訊，以便緊急事件結束之後進行事後的檢討和行政稽查。但是常見的情況是，醫療資訊系統中的每個應用程式都採用符合自身需求的格式來紀錄日誌檔，因此該資訊可能沒有足夠詳細的資訊作為隱私稽核之用，這樣一來，編寫稽核報告不僅費時，而且不夠準確。理想的情況是有一個集中紀錄稽核的機制，可以對所有針對個人識別資訊的存取和請求建立所需的日誌檔。另外一個困難點在於要如何描述隱私規則，目前在醫療領域並沒有一個普遍接受的標. 政治大 HL7 [29] 的 RBAC 安全和隱私權詞彙計劃 [30] 正是其中之一。該計劃的重點在於希立準。然而，有許多計劃正嘗試制定隱私規則的格式，讓這些規則可以互相交換使用，. ‧ 國. 學. 望能開發一種標準化的隱私和同意目錄，根據使用目的來描述病人的偏好。至於醫療領域之外，也有不少關於隱私規則的新興標準，比較常見的有 P3P [31], EPAL 和. ‧. XACML 2.0，共同的特色是把使用的目的列入考量，達到強化隱私權的存取控制規. sit. y. Nat. 則。本研究遵循 EPAL 規則，使用這樣的隱私規則架構：「在特定情況下，根據使用者. io. al. er. 所同意的目的，允許或是拒絕存取某些資料的行動。」這樣的隱私規則格式不僅夠細. n. 緻，而且有把使用目的納入考慮。請參考下列的範例：. i n U. Ch. v. engchi 在病人同意的前提之下，允許醫生或是護士因為提供醫療服務的目的列印病歷資料。必須刪除 3 年前的資料。本研究實作的系統框架會利用剛剛介紹的隱私規則，根據病人對於個人識別資訊用途的偏好，改進對病人醫療記錄的存取控制機制。目前大多數的醫療機構通常是在醫療資訊系統完成之後，才考慮到要新增隱私權相關政策，並且設法取得病人針對自身可識別資訊所同意的用途。醫療資訊系統設計的時候都沒有將這些列入產品需求，因此即使事後收集病人關於存取電子病歷記錄的偏好是可行的，但要在不影響現有醫療資訊系統架構的前提下，來加強存取控制機制是相當困難的。 22.

(29) 為了解決上述提到的問題，本研究利用剖面導向的技術來開發支援病人隱私偏好的系統框架。實作的系統框架包括三個主要部份，即行動目的管理員 (Action Purpose Manager) 、病人隱私剖面 (Aspect) ，以及病人偏好管理員 (Patient Preferences Manager)。圖 3-3 顯示該系統框架的架構，並強調系統框架和底層存取控制系統的互動。本論文實作了一個簡單的 Java 網頁應用程式 (Web Application) 來展示該系統框架，因此只要是使用 Java 開發的網頁應用程式都可以適用。接下來的小節會介紹行動目的管理員、病人隱私剖面，以及病人偏好管理員是如何協同合作，以提供加入隱私權考量的存取控制機制。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 3-3 應用剖面技術支援病人隱私偏好的系統框架. 23.

(30) 3.2 病人隱私剖面為了讓這個架構能夠順利運作，本研究遵循業界標準 XACML，假設在醫療資訊系統的存取控管機制 (Access Control System) 中有政策執行點 (Policy enforcement point, PEP) 與政策決策點 (Policy decision point, PDP)，而所有針對病人隱私資料存取的請求都將被政策執行點攔截，並且傳送到政策決策點進行檢查，因此利用政策決策點當作是意見 (advice) 織入 (weaving) 的連接點 (join point)，病人隱私剖面 (Aspect) 會透過政策決策點和存取控管機制溝通，詳見圖 3-4。如果在現行系統中沒有統一的存取. 治政大 (pointcut)，例如找出共同控管模組，還是可以根據實際系統架構來找出適用的連接點立實作的介面 (interface) 等。該剖面主要是用來監控政策決策點的決定，並接著執行有 ‧ 國. 學. 關病人偏好的檢查和稽核，如果政策決策點同意存取請求的話，病人隱私剖面會跟行. ‧. 動目的管理取得該存取請求的目的，再跟病人偏好管理員查詢病人同意的存取目的有哪些，這樣可以負責確保該請求的使用目的和病人同意的存取目的相符合。遇到不符. y. Nat. io. sit. 合的時候，病人隱私剖面可以強制覆蓋政策決策點的決定，讓政策執行點拒絕此存取. n. al. er. 請求，以便保障病人的隱私偏好得到尊重。此外，無論是否允許該請求存取資料，病. Ch. i n U. v. 人隱私剖面會將存取過程的所有相關記錄保存起來，例如該人員的帳號、病人病歷號碼等等。. engchi. 從圖 3-4 可以看出，為了要實現此系統框架，在現有的醫療資訊系統中，只需要加入病人隱私剖面 (Aspect) 直接和底層的存取控管機制溝通即可，而要達成這個目標並不需要大幅修改現行系統，只要透過剖面織入程式 (aspect weaver) [32] 讓病人隱私剖面和底層的政策決策點整合在一起。換句話說，這樣可以達到改變原有存取控管機制的行為，而且除了新增病人隱私剖面、行動目的管理員和病人隱私偏好管理員這些元件相關的程式碼，幾乎不需要去改變任何既存的程式碼。這種鬆散耦合 (Loose Coupling). 24.

(31) 的設計是此系統框架最顯著的特點。. 立. 政治大. ‧. ‧ 國. 學. 圖 3-4 政策執行點、政策決策點跟病人隱私剖面溝通. sit. y. Nat. io. er. 加入的病人隱私剖面還提供了另外一個好處，就是讓系統在顯示病人可識別資訊的時候達到更細緻的控管機制。在目前大多數醫療資訊系統的存取控制機制中，如果要針. al. n. v i n Ch 對使用者是否有權限存取該筆資料進行判斷，一般都只能回傳允許或是拒絕存取而 engchi U 已。然而，在病人隱私剖面中可以更進一步的先過濾資料之後再回傳；舉例來說，有些使用者或許因業務需要必須存取病人的病歷紀錄，但是他們又不應該看到隱私資訊的欄位，這時候系統就可以在病人隱私剖面中把那些欄位的隱私資訊改掉，再把過濾後的病歷紀錄回傳給使用者。. 25.

(32) 3.3 行動目的管理員為了讓圖 3-3 的系統框架能有效地運作，病人隱私剖面 (Aspect) 必須取得存取病人隱私資料請求的使用目的，以及病人同意能夠存取資料的目的。由於這些都是新增到醫療資訊系統中，因此需要增加兩個新的元件來處理，第一個就是 3.3 小節要介紹的行動目的管理員 (Action Purpose Manager)，請參考圖 3-5；處理病人隱私偏好的模組將在 3.4 小節提到。當系統中有任何使用者對病人病歷紀錄進行存取的時候，病人隱私剖面就會向行動目的管理員要求該存取動作的目的為何，例如這個存取請求是為了提. 治政大供醫療服務或是學術研究目的。行動目的管理員是全域性的物件，會在資料庫中紀錄立所有行動和目的對應，當接到查詢請求的時候就會到資料庫中找出符合該存取請求的 ‧ 國. 學. 目的，然後回傳給病人隱私剖面，以便判斷是否可以允取該請求。. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 3- 5 行動目的管理員跟病人隱私剖面. 26.

(33) 在建立醫療資訊系統的初期，很少有系統會將每個存取請求的目的紀錄下來，通常都是事後因應新的需求才開始進行。另外一個困難點是，系統框架本身無從得知系統的每個行動所對應的目的到底是什麼，必須有人負責去瞭解系統需求，才能知道該行動的目的。因此，醫療機構需要指派專職負責安全和隱私的系統管理人員，為他們在系統中建立具有管理員權限的帳號，本研究實作的系統框架提供了把醫療資訊系統中所有已經存在的行動找出來的功能，並有管理介面讓系統管理人員使用。在實作行動目的管理員的時候，本研究假設可以從系統中類別 (Class) 和方法 (Method). 政治大制，因為有時系統中的方法不見得能夠完全和系統使用者的行動目的相對應，因此在立的組合找出該行動的目的為何，但在實際運用的時候會根據不同的系統架構而有所限. ‧ 國. 學. 實作系統框架的時候我們也提供了一個行動對應到多個目的的功能，希望能夠儘量符合實際需求，把不適用的情況減到最低。. ‧. 最後，系統管理人員必須把系統中查詢到的所有行動整理好，然後跟每個功能的負責. Nat. sit. y. 單位討論，給予每個行動適當的目的 (一個或是多個)，再將這些目的輸入到系統中。. n. al. er. io. 設定完成之後，當病人隱私剖面 (Aspect) 要求行動目的管理員提供該存取請求的使用. i n U. v. 目的時，行動目的管理員就可以很快的把相對應的目的找出來，回傳給病人隱私剖面使用。. Ch. engchi. 27.

(34) 3.4 病人偏好管理員病人偏好管理員也是新增的模組之一，主要是負責收集和管理病人針對自身可識別資訊的隱私偏好。和傳統存取控管機制不同的地方是，當事人可以指定在什麼樣的用途、存取病人病歷紀錄中的哪一項個人資訊是被允許的。當醫療資訊系統中有使用者提出要存取病人隱私資訊的請求時，病人隱私剖面 (Aspect) 會向病人偏好管理員取得有哪些用途被允許存取該類別的隱私資訊，並且和個人識別資訊連結起來，圖 3-6 顯示了病人偏好管理員和病人隱私剖面的互動。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 3- 6 病人偏好管理員跟病人隱私剖面. 在設計病人隱私偏好遇到的困難點是要到多細緻的程度，例如行動的類別、資料類別、用戶類別和使用的用途等等。在還沒有公認的相關標準出現之前，從實務面考量的話，本研究採取先嘗試從比較粗略的項目開始進行，等到累積更多經驗之後，再逐 28.

(35) 漸朝向更細緻的項目發展。如果用針對網路用戶的 P3P 隱私標準作為參考，在 P3P 中，隱私規則的格式如下：「如果同意，在特定情況下，允許用戶在某些用途上使用個人識別資訊。」但是把 P3P 應用到醫療領域會有幾個問題，第一，規則裡面沒有明確說明用戶屬於什麼群組類別。第二，唯一的動作就是「使用」，過於簡化。第三，個人識別資訊 (PII) 的類別和目的是事先定義好的，不見得能夠運用在醫療資訊領域上。本研究實作的系統框架希望在描述病人偏好上能夠做到比 P3P 更細緻的程度，有兩部份是在實作中加以擴充的。第一項是把存取病人資訊的使用者加以分類，但是，這裡. 政治大人指定隱私偏好的時候，其實不需要像是醫生、護士或是麻醉師這麼細緻的類別，可立不是採用一般基於角色的存取控制 (RBAC) [33] 系統中使用的類別，畢竟在讓一般病. ‧ 國. 學. 能用醫療人員來指定就足夠了，所以我們在系統中採用的是涵蓋比較廣泛使用者的類別，例如醫療團隊，醫院職員，政府機構和保險公司等等，這樣對病人來說會更容易. ‧. 理解。第二個要改進的項目是行動的類型，我們認為光用「使用」在某些情況下可能不. io. n. al. er. 抽象的行動類型，像是讀取、修改、建立和附加等等。. sit. y. Nat. 夠精確，而過於詳細的行動類型也會讓病人感到困惑，因此，在系統實作時採用較為. i n U. v. 至於資料的使用目的，應該要簡單到讓病人可以理解，並且讓系統能夠容易實作，因. Ch. engchi. 此實作的系統框架中包含了一些常見的目的，包括提供建議、醫療服務、學術研究、監督和產品促銷等等。最後要考慮的是資料的類別，以出院病歷為例，全部的欄位加起來將近三十個，最理想的作法是每一個欄位都要讓病人填寫允取存取的目的為何，但是很少人有耐心把全部欄位都填完，更何況這只是一份出院病歷而已，如果把欄位數量乘上醫院裡面所有的病歷紀錄，可能會有多達幾百個欄位要填寫！因此，在實際運作的時候，本研究採取折衷的方案，就是先讓系統管理員把每種病歷中牽涉到病人隱私資料的欄位挑選出來，然後把相似的欄位放在同一個群組中，病人只要針對每一個隱私資料群組來決定 29.

(36) 允許存取的目的，這樣一份病歷只要針對幾個資料類別進行設定就夠了，不但達到讓病人自己設定隱私偏好的需求，同時又兼顧了系統實際運作上的可行性。而這些隱私群組欄位的設定是紀錄在資料庫中的，如果需要增加或是修改只需要修改資料庫的資料即可，不需要重新修改程式或是重新啟動伺服器。圖 3-7 是取得病人偏好的矩陣架構:. 立. 政治大. ‧. ‧ 國. 學 er. io. sit. y. Nat. 圖 3- 7 取得病人隱私偏好的矩陣架構. al. n. v i n Ch 當系統管理人員在收集病人隱私偏好的時候，理想的狀況是可以讓病人完全掌控，在 engchi U 醫療資訊系統上針對自身的每一項隱私資料來勾選同意使用的用途，不過這樣的作法在實務上會有困難，因為這些隱私規則非常複雜，如果沒有提供協助的話，病人很難做出決定，再來每個使用者對使用電腦的熟悉程度也不一樣，要讓所有人都完全了解每個項目，並且在系統上直接填寫要花費很大的工夫。實務上比較可行的作法是將每一種病歷紀錄都整理好，提供一份相對應的紙本問卷讓病人填寫，之後再統一由系統管理人員根據該問卷填寫的內容輸入到系統之中。針對這項需求，本研究實作的系統也提供了圖形化的介面，讓管理人員可以很方便的把病人的隱私偏好輸入到系統中。. 30.

(37) 第4章系統實作本章將由使用者的角度來介紹本研究實作的系統，程式開發的平台是 Java SE 6，加上第 2 章介紹過的 Spring/Hibernate/Wicket 等框架，使用的 IDE 是 Eclipse 3.5 Galileo (http://www.eclipse.org/galileo/)。在 4.1 小節會介紹在系統中如何設定病人隱私剖面 ( Privacy Aspect)；4.2 小節會展示如何在系統中管理所有行動的目的；4.3 小節則是介. 政治大. 紹使用網頁管理介面來管理病人的隱私偏好。. 立. 4.1 設定病人隱私剖面. ‧ 國. 學. 本研究利用 Spring AOP (Aspect Oriented Programming) 將病人隱私剖面 (Privacy. ‧. Aspect) 織入到意見 (Advice) 中，在 Spring 中要加上 AspectJ 的支援很簡單，只要. n. al. er. io. sit. y. Nat. 在設定檔 applicationContext-aop.xml 加入圖 4-1 第 15 行的設定即可:. Ch. engchi. i n U. v. 圖 4-1 在 Spring 中啟用 AspectJ 支援. 接著要建立病人隱私剖面，以便設定在系統的哪些位置織入意見 (Advice)，圖 4-2 是利用 Spring 註解 (Annotation) 建立的病人隱私剖面:. 31.

(38) 圖 4-2 病人隱私剖面. 在圖 4-2 可以看到只要在 PrivacyCheckAspect 類別加上 @Aspect 的註解，這樣 Spring 就知道這是一個剖面 (Aspect)。在本研究實作的系統之中，所有存取控管相關. 行. 學. 19. ‧ 國. 治政的請求都會在 AccessControlServiceImpl 類別集中管理，這也就是前面提到的政策執大立行點 (Policy Enforcement Point, PEP)，因此在剖面中要設定在這裡織入意見，也就是第的. @PointCut("execution(public. *. AccessControlServiceImpl 類別中的所有方法時織入意見。. Nat. sit. y. ‧. tw.idv.haocheng.Hippo2.ac.impl.AccessControlServiceImpl.*(..))") ，表示要在呼叫到. io. er. 病人隱私剖面 (Privacy Aspect) 設定好之後，接下來要建立織入的意見 (Advice)，程式. al. 碼摘要請參考圖 4-3。可以看到在第 68-69 行，呼叫行動目的管理員 (Action Purpose. n. v i n Ch Manager) 取得該存取行動及目的；在第則是向病人隱私偏好管理員要求該病人 e n g72-73 chi U. 的所有隱私偏好。然後根據原本存取控管機制判斷是否可以存取的決定，如果允取的話，則將病人隱私資訊中不願開放讀取的欄位取代掉，再回傳給提出存取請求的使用者，並且紀錄該存取請求。如果原本使用者權限就不能存取此資料的話，就回傳如圖 4-4 的錯誤訊息給使用者，同時也會將該請求相關資訊紀錄下來以便日後稽核之用。. 32.

(39) 立. 政治大. ‧. ‧ 國. 學圖 4-3 隱私意見. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4-4 拒絕存取請求的錯誤訊息. 33.

(40) 當病人隱私剖面和隱私意見都建立好之後，最後只需要在設定檔 applicationContext-aop.xml 中加入圖 4-5 的設定:. 19-20 行，設定了連接點. (Pointcut) 的位置，就是. 學. ‧ 國. 在設定檔中的第. 立. 政治大. 圖 4-5 設定病人隱私剖面. PrivacyCheckAspect 類別 (圖 4-2) 中的 accessControlOperation() 對應到的方法。第. ‧. 21 行設定了病人隱私剖面 (Privacy Aspect) 是哪一個物件 (就是第 26-28 行定義的. y. sit. accessControlOperation() 連接點。換句話說，就是任何呼叫. io. er. 剛定義好的. Nat. privacyCheckAdvice Java Bean)，第 22 行是設定切入類型是 around，連接點就指到剛. AccessControlServiceImpl ( 系統中的政策執行點 ) 類別的方法，都會執行. al. n. v i n Ch 中定義的指令，然後檢查存取請求的行動目的是否符合病人允許 engchi U. privacyCheckAdvice 的隱私偏好。. 34.

(41) 4.2 管理行動目的完成病人隱私剖面 (Privacy Aspect) 和隱私意見 (Privacy Advice) 之後，接著需要管理醫療資訊系統中所有行動的目的，如此一來當病人隱私剖面向行動目的管理員查詢存取請求目的時，才有辦法提供相對應的資料。這個功能會分成兩部份來處理，首先因為行動目的通常是在醫療資訊系統建立完成之後才新增的概念，我們必須先找出系統中已經存在的所有行動，並且給予每個行動適當的目的，這項工作同樣必須依靠系統管理人員的協助，有些功能如果是很久以前開發完成的，或許還得翻閱系統相關的文件資料才行。本研. 立. 治政大框究實作的系統. 架會利用. reflections. (http://code.google.com/p/reflections/) 函式庫來掃描醫療資訊系統根目錄下的所有類別. ‧ 國. 學. 中，找出符合條件的行動，然後讓系統管理人員可以在網頁上直接指定適當的目的。. ‧. 圖 4-6 是相關的程式碼，第 77-78 行指定要掃描的目標是 tw.idv.haocheng.Hippo2 package 下的所有 Java 類別，第 83-84 行則是找出所有 @Service 註解的 Java 類. y. Nat. io. sit. 別，因為本系統實作假設所有業務面相關的需求都放在有 @Service 註解的 Java 類別. n. al. er. 中，當然實際使用的時候可以根據系統狀況來調整過濾的條件。. Ch. engchi. i n U. v. 圖 4-6 掃描系統目錄下所有類別的程式碼. 35.

(42) 找出所有的行動之後，系統框架有提供一個網頁的管理介面 (如圖 4-7) 讓系統管理人員可以輸入每個行動的目的。針對每一個行動，管理人員可以輸入多個目的，例如 PatientServiceImpl 類別的 queryRecordId() 方法是為了「提供建議」和「醫療服務」等兩項目的，而且 queryRecordId() 方法並不會修改資料，所以行動的類別設定為「讀取」。當全部都設定完成之後，只要按下左下角的「儲存」按鈕就可以了。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖 4-7 輸入行動目的管理介面. 36. v.

(43) 儲存完畢之後，系統管理人員只要進入管理行動目的的頁面 (如圖 4-8)，就可以看到剛剛輸入的那些行動和目的相對應的資料都出現了。如果需要修改某些設定完成的行動目的，只要按「修改行動目的」的連結 (如圖 4-8)，就可以連到跟圖 4-7 一樣的管理介面修改。. 立. 政治大. ‧. ‧ 國. 學. n. al. er. io. sit. y. Nat. 圖 4-8 管理行動目的頁面. Ch. engchi. 37. i n U. v.

(44) 4.3 管理病人偏好系統取得行動目的相關資訊之後，還需要設法取得病人的隱私偏好，3.3 小節有提過在實務上讓病人自己手動輸入隱私偏好是不可行的，因此本研究實作的系統框架提供了網頁的管理介面，讓系統管理人員可以根據病人填寫好的紙本問卷來輸入病人的隱私偏好。圖 4-9 就是管理的介面，系統管理人員只要輸入病歷編號以及病歷種類，系統就會顯示該份病歷可以設定的隱私偏好選項，查詢結果如圖 4-10。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4-9 利用病歷號碼和病歷類別來查詢. 在 3.4 小節有提過，我們採用的隱私權規則如下:. 如果病人同意醫護人員基於提供醫療服務和醫學研究目的的前提之下，就允許讀取病人的出院病歷資料. 38.

(45) 在圖 4-10 中可以看到，當系統管理人員在設定病人隱私偏好的時候，就是遵循這樣的規則，讓病人可以針對每一個族群的使用者 (例如: 醫療團隊、醫院一般員工)，每個使用目的 (例如: 提供建議、醫療服務)，以及每組隱私資料欄位 (圖 4-10 中的「診斷」以及「特殊檢查」)，分別設定「允許」或是「拒絕」存取。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖 4-10 設定病人的隱私偏好. 39. v.

(46) 系統管理人員把所有隱私偏好都輸入之後，只要按下「儲存」，就可以看到如圖 4-11 的病人隱私偏好結果。在尊重病人隱私權以及方便系統管理人員選取的考量之下，系統框架預設採取 opt-in 而不是 opt-out [34]，也就是所有隱私偏好的預設選項都是「拒絕」，除非病人在紙本問卷上有勾選「允許」才會修改。從圖 4-11 中可以看出，除了紅色框線部份，針對醫療團隊提供建議和醫療服務等目的有改為「允許」之外，其他選項都會維持預設值，也就是「拒絕」。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖 4-11 病人隱私偏好. 40. v.

(47) 4.4 系統展示當病人隱私剖面、行動目的管理員和病人隱私偏好管理員都設定好，而且有關行動目的和病人隱私偏好的資訊也都收集完成之後，系統框架就可以根據這些設定來過濾病人的可識別資訊 (PII)。在傳統的存取控管機制中，只能單純的根據使用者群組來區分，例如: 只有醫護人員才可以觀看病人的病歷但是當在醫療資訊系統中加入本研究實作的「支援病人隱私偏好的系統框架」之後，就可以針對隱私權做到更細緻的控管。舉例來說，假定醫療資訊系統內有兩個帳號，. 治政大 “doctor1” 帳號屬於醫療團隊，“staff1” 帳號是醫院職員。有兩個病人，John (A000001) 立 Weaving 和 Mary (F000001)，他們各自對自己的隱私偏好做了如下圖 4-12 和圖 4-13 ‧ 國. 學. 所示的設定 (沒有顯示的都是拒絕存取)。. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖 4-12 John 的隱私偏好. 41. v.

(48) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖 4-13 Mary 的隱私偏好. 42. v.

(49) 在本研究實作的醫療資訊系統中有一個功能是查詢出院病歷資料，而系統管理人員把這個功能的行動目的設定為「醫療服務」和「研究目的」。當我們把上述的這些資訊都輸入到系統中，可以得到如圖 4-14 的結果:. Account\Patient. John (A000001). doctor1 (Primary Care Allowed to see data Team) staff1 (Hospital Staff). 立. Mary (F000001) Allowed to see data. with PII. with PII. without PII. with PII. 政治大 Allowed to see data Allowed to see data. ‧ 國. 學圖 4-14 不同群組帳號瀏覽病歷資料的差異. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. 43. i n U. v.

(50) 使用 “doctor1” 帳號登入的時候，因為 John 和 Mary 都允許醫療團隊的成員在提供「醫療服務」目的的情況下可以看到病人的隱私資訊，所以 “doctor1” 看到的出院病歷資料會如圖 4-15:. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4-15 醫療團隊群組帳號看到的出院病歷資料. 44.

(51) 如果改用 “staff1” 帳號登入的話，因為 John 拒絕醫院職員群組看到出院病歷中的隱私資訊，所以看到的病歷資料會如圖 4-16，可以發現所有隱私資訊的欄位都改用 “xxxx” 代替。然而，Mary 允許醫院職員因為「監督」和「研究目的」等目的而存取其出院病歷中的隱私資訊，所以當 “staff1” 帳號查詢 Mary 出院病歷的時候，隱私資訊的欄位就會顯示出來。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4-16 醫院職員群組帳號看到的出院病歷資料. 45.

(52) 第5章 5.1 結論在開發醫療資訊系統的時候，如何保護病人的隱私一直是個重要的議題，隨著社會大眾對自身隱私日益重視，挑戰性也隨之增加，根本的原因在於傳統存取控管機制的設計很難達到尊重病人隱私偏好的需求。為了解決隱私權的問題，本研究嘗試實作了一個「應用剖面技術支援病人隱私偏好的系. 政治大. 統框架」，系統框架主要分為三部份: 病人偏好管理員、行動目的管理員以及病人隱私. 立. 剖面。系統管理人員透過病人偏好管理員模組可以收集和管理病人的隱私偏好；行動. ‧ 國. 學. 目的管理員模組則是負責管理醫療資訊系統內所有行動的目的；最後，利用剖面導向程式設計完成的病人隱私剖面，能夠在無需大幅度改寫現行系統的前提之下，將此系. ‧. 統框架和底層的醫療資訊系統進行整合，以便達到將病人隱私偏好納入考慮的設計。. Nat. sit. y. 這樣的運作機制和底層系統是鬆散耦合 (loosely coupled) 的，因此，雖然需要實作. n. al. er. io. 這三個新增的模組，但是花費的時間和成本跟大幅度改寫比起來是可以接受的。. Ch. i n U. v. 此外，本研究實作的系統框架還有兩個可以擴充的地方。首先，如果需要處理跨醫療. engchi. 機構之間個人醫療資訊交換所需的 Sticky policy [35] 的話，可以在病人偏好管理員內進行，因為病人偏好管理員是個獨立運作的模組，只要把外部的病人隱私偏好轉換成病人偏好管理員接受的格式，不管隱私偏好是來自於病人的同意書，或是其他醫療機構轉過來的醫療紀錄中所帶的隱私權政策都可以。第二，病人隱私剖面 (Privacy Aspect) 可以加強現行的存取控制機制，就如同在第四章系統實作所看到的，傳統的存取控管只有全部看到和全部看不到的規則，但是加入病人隱私剖面之後，就可以在這裡做過濾隱私資料的工作，因此不但能夠控管誰有權限存取病人的病歷資料，還可以更進一步的在回傳的病歷資料中隱藏病人的隱私資訊。 46.

(53) 5.2 未來發展我們認為下列幾點是在未來的研究中可以繼續加強的地方: 1. 在設定病歷中的哪些欄位是隱私資料的時候，目前還沒有很友善的介面可以使用，理想的情況應該是要提供網頁管理介面，就像設定行動目的和病人隱私偏好的功能，讓系統管理人員能夠直接在系統中選取哪些欄位是隱私資料，系統就會自動把這些欄位標記起來，在設定病人偏好的時候就可以使用。. 政治大統框架中並未支援，未來希望能加入管理隱私責任的機制，例如建立定期排程立. 2. 前面第二章有提到 EPAL 規則中可以包含責任 (Obligation) 的部份，這在本系. ‧ 國. 學. 檢查的功能，當系統發現符合條件的隱私責任，就會自動執行。 3. 在目前實作的系統框架中，如果要改變隱私剖面中的存取控制規則，就必須修. ‧. 改相關的程式碼然後重新編譯，再重開伺服器，修改才會生效；但是在某些很. Nat. sit. y. 重要或是流量很大的系統，可能沒辦法容忍重開伺服器造成一段時間停止服務. n. al. er. io. 的情況，這時就必須要有動態載入修改的機制。關於這方面的改進或許可以參. i n U. v. 考 JRebel (http://www.zeroturnaround.com/jrebel/ ) 提供的功能。. Ch. engchi. 47.

(54) 第6章參考文獻 [1] 行政院衛生署電子病歷推動專區, Retrieved January 15, 2011, from http://emr.doh.gov.tw/introduction.aspx [2] U.S. Department of Health and Human Services (2008), Nationwide Privacy and Security Framework For Electronic Exchange of Individually Identifiable Health Information,. 政治大 Department of Health and Human Services, Available from 立. (Internet), Office of the National Coordinator for Health Information Technology, U.S.. ‧ 國. 學. http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848088_0_0_18/Nationwi dePS_Framework-5.pdf (Accessed 28 June, 2009). ‧. [3] APEC (2005), APEC Privacy Framework, (Internet), Asia-Pacific Economic Corporation,. al. er. io. sit. y. Nat. Available from. n. http://www.apec.org/apec/news___media/fact_sheets/apec_privacy_framework.html (Accessed 28 June, 2009). Ch. engchi. i n U. v. [4] 台大醫院當機 8000 病患受累 (22 May, 2007), Retrieved January 15, 2011, from http://www.libertytimes.com.tw/2007/new/may/22/today-life3.htm [5] eXtensible Access Control Markup Language (XACML) Version 1.1, Retrieved January 15, 2011, from http://www.oasis-open.org/committees/xacml/repository/cs-xacml-specification-1.1.pdf. 48.

(55) [6] Enterprise Privacy Authorization Language (EPAL), Retrieved January 15, 2011, from http://www.zurich.ibm.com/security/enterprise-privacy/epal/Specification/index.html [7] XACML on OASIS, Retrieved January 15, 2011, from http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml [8] A Brief Introduction to XACML, Retrieved January 15, 2011, from http://www.oasis-open.org/committees/download.php/2713/%20Brief_Introduction_to_XAC ML.html. 立. 政治大. [9] XACML Terminology, Retrieved January 15, 2011, from. [10] EPAL W3C submission, Retrieved January 15, 2011, from http://www.w3.org/Submission/2003/SUBM-EPAL-20031110/. Nat. sit. y. ‧. ‧ 國. 學. http://en.wikipedia.org/wiki/XACML#Terminology. io. al. n. NU-CCS-95-03, 1995.. er. [11] Walter Hürsch and Cristina Videira Lopes, Separation of Concerns, Technical Report, no.. Ch. engchi. i n U. v. [12] Kiczales, G. et al., (1997), Aspect-Oriented Programming, European Conference on Object-Oriented Programming, Jyväskylä, Finland, June 1997, Lecture Notes in Computer Science 1241; 220-242. [13] 陳恭, 剖面導向程式設計(AOP/AOSD)簡介, 2007 [14] Kiczales, G. et al., (2001), Getting Started with AspectJ, Communications of ACM, 44(10), 2001, 59-65.. 49.

(56) [15] Hilsdale, E. and Hugunin, J. (2004), Advice Weaving in AspectJ, Proc. of the 3rd International Conference on Aspect-Oriented Software Development, Lancaster UK, 2004: 26-35. [16] Plain Old Java Object (POJO), Retrieved January 15, 2011, from http://en.wikipedia.org/wiki/Plain_Old_Java_Object [17] Object-relational mapping, Retrieved January 15, 2011, from http://en.wikipedia.org/wiki/Object-relational_mapping. 治政 [18] Model–View–Controller, Retrieved January 15, 2011, 大from 立 ‧ 國. 學. http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller [19] Relational Database, Retrieved January 15, 2011, from. ‧. http://en.wikipedia.org/wiki/Relational_database. y. Nat. er. io. sit. [20] Object-relational impedance mismatch, Retrieved January 15, 2011, from http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch. n. al. Ch. engchi. i n U. v. [21] Connection Pool, Retrieved January 15, 2011, from http://en.wikipedia.org/wiki/Connection_pool. [22] Shan, Tony (2006). "Taxonomy of Java Web Application Frameworks". Proceedings of 2006 IEEE International Conference on e-Business Engineering (ICEBE 2006), http://portal.acm.org/citation.cfm?id=1190953 (Accessed 10 Oct, 2010) [23] Stateless, Retrieved January 15, 2011, from http://en.wikipedia.org/wiki/Stateless_protocol. 50.

(57) [24] Blobel B. (2004), Authorisation and access control for electronic health record systems. Int. J. of Medical Informatics, 73(3), March 2004, 251-7. [25] Ferreira A, et al. (2005), Modelling access control for a complex healthcare organization. In: iSHIMR 2005: Proceedings of the Tenth International Symposium on Health Information Management Research, Thessaloniki, Greece, Sep. 2005. [26] Massacci, F. and Zannone, N. (2006), Privacy is Linking Permission to Purpose, Lecture Notes in Computer Science Vol. 3957, Springer Berlin / Heidelberg.. 治政 [27] Personally identifiable information, Retrieved January 大15, 2011, from 立 ‧ 國. 學. http://en.wikipedia.org/wiki/Personally_identifiable_information. [28] Hafner, M. et al. (2008), Modeling and Enforcing Advanced Access Control Policies in. ‧. Healthcare Systems with Sectet, IN: H. Giese (Ed.):MoDELS 2007 Workshops, LNCS 5002,. Nat. io. sit. y. pp. 132-144, 2008, Springer Berlin / Heidelberg.. n. al. er. [29] Health Level Seven, The Clinical Document Architecture Release 2.0, Retrieved January. Ch. i n U. v. 15, 2011, from http://www.hl7.org/library/standards_non1.htm. engchi. [30] HL7 Security WG: The RBAC Security and Privacy Vocabulary Project (2008), Available from http://hl7projects.hl7.nscee.edu/docman/view.php/57/361/SecurityandPrivacyuthzFramework. pdf, (Accessed June 28, 2009) [31] Platform for Privacy Preferences (P3P) Project, Retrieved January 15, 2011, from http://www.w3.org/P3P/. 51.

(58) [32] Aspect Weaver, Retrieved January 15, 2011, from http://en.wikipedia.org/wiki/Aspect_weaver [33] Sandhu R, et al. (1996), Role-based access control models, IEEE Computer, 29(2), 1996, pp. 38-47. [34] Opt out, Retrieved January 15, 2011, from http://en.wikipedia.org/wiki/Opt-out [35] Karjoth, G., Schunter, M., Waidner, M. (2004), Privacy-enabled Management of Customer Data. IEEE Data Eng. Bull. 27(1): 3-9 (2004).. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 52. i n U. v.

(59)