SMART on FHIR：醫療應用授權標準與架構方法論

SMART on FHIR（Substitutable Medical Applications and Reusable Technologies）是由哈佛醫學院 / Boston Children's Hospital 主導發展的開放標準，現由 HL7 維護（SMART App Launch IG v2.2.0）。

它的核心是：OAuth 2.0 + OpenID Connect + FHIR API，三者合一，解決「臨床應用程式如何以標準化、安全的方式存取 EHR 資料」的問題。

核心三層架構

graph TD
  subgraph standards[標準層]
    FHIR[FHIR R4/R5 資源 API]
    OAuth[OAuth 2.0 授權框架]
    OIDC[OpenID Connect 身份驗證]
  end

  subgraph smart[SMART on FHIR]
    Launch[Launch Context 情境傳遞]
    Scopes[Clinical Scopes 臨床範圍]
    Token[Access Token 存取令牌]
  end

  OAuth --> Token
  OIDC --> Token
  FHIR --> Launch
  Token --> Scopes
  Scopes --> FHIR

兩種 Launch 模式

1. EHR Launch（從 EHR 系統啟動）

臨床人員在 EHR 介面操作中直接開啟 SMART App，EHR 自動傳遞當前病人/就診情境。

sequenceDiagram
  actor Clinician as 臨床人員
  participant EHR as EHR 系統
  participant App as SMART App
  participant AuthServer as 授權伺服器
  participant FHIR as FHIR Server

  Clinician->>EHR: 點擊開啟 App
  EHR->>App: launch + iss 參數
  App->>AuthServer: 授權請求 + launch scope
  AuthServer->>Clinician: 確認授權(或自動)
  Clinician->>AuthServer: 同意
  AuthServer->>App: authorization_code
  App->>AuthServer: 換取 access_token + launch_context
  App->>FHIR: 攜帶 token 查詢資源
  FHIR->>App: Patient/Encounter/Observation...

2. Standalone Launch（獨立啟動）

App 不依賴 EHR 直接啟動，用戶自行登入並選擇病人。適合病人自用 App 或後端服務。

Scopes 授權範圍

SMART 定義三層 Scope，對應不同存取主體：

Scope 前綴	說明	範例
`patient/`	存取特定病人資料	`patient/Observation.read`
`user/`	存取該使用者可見的資料	`user/Patient.read`
`system/`	後端服務，無使用者介入	`system/DiagnosticReport.read`

常見 Launch Context Scopes：

Scope	取得的情境
`launch/patient`	目前開啟的病人 ID
`launch/encounter`	目前的就診 ID
`openid profile`	臨床人員身份（OIDC）

SMART on FHIR v2 新增功能

細粒度 Scopes：支援欄位層級的存取控制（e.g., patient/Observation.rs?category=vital-signs）
PKCE：強制使用 Proof Key for Code Exchange，防止授權碼被攔截
Backend Services：支援機器對機器（M2M）無使用者情境的整合
Token Introspection：資源伺服器可即時驗證 token 狀態

與 DHH Citadel 架構的對應

SMART on FHIR Gateway 是 Citadel 架構中最典型的 Outpost 範例之一。

graph TD
  subgraph citadel[Citadel 核心城堡]
    Rails[Rails 主應用]
    DB[(PostgreSQL)]
    Rails --- DB
  end

  subgraph outpost[Outpost FHIR Gateway]
    HAPI[HAPI FHIR Server Java]
    SmartAuth[SMART 授權伺服器]
    HAPI --- SmartAuth
  end

  subgraph clients[外部用戶端]
    EHR[EHR 系統]
    ClinicalApp[臨床 App]
  end

  Rails -->|HL7 訊息 / REST| HAPI
  EHR -->|SMART Launch| SmartAuth
  SmartAuth -->|access_token| ClinicalApp
  ClinicalApp -->|FHIR API + token| HAPI

為何 FHIR Gateway 是 Outpost 而非 Monolith 的一部分？

考量	說明
技術語言限制	HAPI FHIR 是 Java 生態系，Rails 難以原生整合
標準合規	需通過 ONC/CMS 認證的 SMART 端點，有嚴格的互操作測試要求
安全隔離	醫療資料需要獨立的存取控制、稽核日誌與合規邊界
版本演進	FHIR R4 → R5 升級不應影響核心應用程式

Citadel（Rails）依然是主體：負責業務邏輯、病人管理、排程等核心功能。FHIR Gateway 只在需要與外部 EHR/臨床系統交換資料時才被呼叫。

實作考量

自建 SMART on FHIR Gateway

推薦技術棧：

HAPI FHIR（Java）：最完整的開源 FHIR 伺服器，內建 SMART 支援
Keycloak：負責 OAuth 2.0 / OIDC 授權伺服器角色
Inferno：ONC 官方 SMART 合規測試工具

雲端託管方案

Azure Health Data Services：內建 SMART on FHIR 端點
Google Cloud Healthcare API：支援 SMART 授權
AWS HealthLake：FHIR R4 相容，需自行整合 SMART 層