---
# System prepended metadata

title: XDS on FHIR AAA requirements

---

# 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/