# XDS on FHIR AAA requirements ## 目的 - FHIR 應用廣泛，XDS on FHIR 基於 IHE XDS 電子病歷互通整合架構及 FHIR 規範，明列 FHIR document(病歷文件) 之互通架構，及此架構之資安管控(AAA requirement 規範)。以此: -- 規範 FHIR **電子病歷**互通整合架構 ` -- 明訂**病歷調閱**之認證 Authentication(認證)、Authorization(授權)、Accounting(紀錄及稽核)，standard AAA solution for EHR sharing -- **避免開發單位自訂 AAA solution 導致無法整合應用** ## 說明 - 目前醫資標準 FHIR 及 DICOM 並不訂立資安標準規格，而是引用現行 IT 應用領域之資安規範，如 IETF, W3C, IHE 等組織所提規格 - 好處: 可與其他網路應用有一致的規範，使用相同的技術，並建構類似的資安防護機制 -- 如使用 openID 做認證， oAuth 授權 - 問題: 1. 引用的資安規格 並無針對醫資領域的情境及範例說明，系統開發人員需要很熟悉所引用的資安規範(但通常是粉不熟)，配合其應用情境，導入使用，並不容易。 2. 目前引用的資安規範，在健康醫療領域並無明確的規格及範例，相同應用情境，不同開發團隊發展的資安防護機制，細部做法可能不同，造成系統不相容，無法整合應用 3. 許多專業開發團隊，會各自提出醫資標準資安防護架構及規範 -- 不同團隊提出的架構及規範會有差異(不相容) -- 許有專業團隊皆希望提出通用的資安防護規範。但 DICOMweb 及 FHIR 應用範圍非常廣，不同應用情境，所需認證、授權、稽核要求不太相同。通用的 AAA 導入各式健康醫療應用，將造成其規格非常複雜。實作、導入、逐步擴充困難，例如: --- FHIR 訂立了許多通用的 resources，實際應用時應限縮其選用欄位，並確立選用欄位的編碼，並建構對應的權限管控機制，以保護病患隱私及保障病患安全(Patient safety)。如僅經**嚴謹認證授權的血壓計與 APP，方可上傳血壓及脈搏資料**。其他儀器及系統無權上傳血壓資料，避免透過其他系統，假造並上傳血壓資料，造成醫護人員誤判。又如 FHIR patient 可記錄病人及其連絡人之聯絡資訊，我們須明訂醫院那些人員及系統可增修、查詢病人個資。 --- 健康醫療作業常包含許多流程關卡，如藥物處方開立、配藥、給藥流程，使用到處方開立、藥局配藥、病房給藥等多個系統，要建立系統標準化及管控機制，工程較為複雜。若僅討論醫院釋出的 FHIR 病歷文件(可含藥物處方)，探討目標照護機構、人員、病人使用之系統調閱病歷文件之資料互通架構及權限管控，則情境較為單純且通用 --- 有些應用若系統有誤，對病人安全的影響較大(如上述用藥)，篩檢、減重、復健? ## 規範主要內容 - Authentication(認證)、Authorization(授權)、Accounting(紀錄及稽核) -- 以此安全管控標準化之健康醫療紀錄與 APIs -- AAA 也需標準規範，以利跨系統整合應用 -- IoMT 需再加入 Alert management(病人端異常警告)、Realibility(可靠性) ## FHIR AAA 標準化規格分析 - 規範須可用於單一 FHIR server RESTful API 及標準化跨系統整合架構 XDS on FHIR、[Patient portal](https://hackmd.io/F0KKJei8So2sGLkoH9QcZA?view) 要求 - [Authentication]( https://hackmd.io/vWNog-7VSEuogbZ5rlkAYA?both) -- 認證網頁、APP、物聯網裝置連結 FHIR 伺服器 -- 參考 oAuth， 但 token 需有標準規格 - [Authorization](https://hackmd.io/HogE6vz0SJSLi_4KBN6-og) -- [基於 IHE IUA](https://wiki.ihe.net/index.php/Internet_User_Authorization) --- 參考 oAuth， 但 token 需有標準規格 --- 授權伺服器核發 token，FHIR 儲存庫依據 token 決定可否存取資料 - Accounting(紀錄,付費,及稽核) 各式情境所需 Auditing, Billing, and Accounting. ## Realibility - 除了 client server 系統本身可靠性，亦須考慮: 1. 網路主幹有問題之替代方案 2. 大量使用者時分散上傳機制 ## 搭配 XDS on FHIR - [Patient portal](https://hackmd.io/3-YA4NIlSduzirHccnIq6A?view) -- 人員、組織、裝置的註冊及管理 - 人員、組織、裝置憑證管理 --- 用於雙向 SSL、文件簽章、簽認 JWT token... -- 授權管理 ## AAA Patient portal 標準化需求分析 - Authentication(認證) 無互通需求，可基於現行認證機制，如現行企業系統或雲端(如 gmail )之驗證機制 -- 但 id token 需有一致規格 - Granting or Authorization(授權) 無互通需求Accounting(紀錄及稽核) 藥物病歷 用藥紀錄 # 參考 - https://en.wikipedia.org/wiki/AAA_(computer_security) - XDS on FHIR -- https://www.devdays.com/wp-content/uploads/2019/03/DD18-EU-Gregorio-Canal-XDS-on-FHIR-DevDays-2018-11-14.pdf - IHE Alert management -- https://wiki.ihe.net/index.php/Mobile_Alert_Communication_Management(mACM) - IBM FHIR Server vs. HAPI-JPA https://www.ibm.com/blogs/watson-health/ibm-fhir-server-vs-hapi-jpa/