演講側記：SMART on FHIR 遇上 LINE Bot —— 打造隱私優先的醫療 AI 架構

這場演講

場合：2026 AI Enterprise Summit / Cloud Summit（iThome 主辦）
時間 / 地點：2026-07-02 上午 11:15–11:45，701F 會議室
講題：SMART on FHIR 遇上 LINE Bot —— 打造隱私優先的醫療 AI 架構
講者：國軍高雄總醫院資訊室主任鄭重男 Nickle

這是一場把「開放醫療資料標準」與「台灣人日常都在用的 LINE」接在一起的實作分享：
如何讓病人在 LINE 裡安全地查自己的病歷，同時把隱私優先（privacy-first） 放在架構的第一順位。

為什麼是 LINE Bot × SMART on FHIR

「讓病人在 LINE 裡查自己的檢驗報告、用藥紀錄」是台灣醫院最常見的病人加值服務之一。
從使用者體驗看，它只是「登入 → 看資料」；但從資安與醫療事故的角度看，
這條流程其實是三個彼此獨立的問題串成的一條身分鏈，任何一段答錯都是資安或醫療事故
（完整拆解見 line-liff-fhir-patient-record-access）。

LINE Bot / LIFF 提供了病人「零安裝、開 LINE 就能用」的入口，但 LIFF 是跑在 WebView 裡的 public client，無法保存任何 client secret —— 這個事實直接決定了後面授權必須用 Authorization Code + PKCE。
SMART on FHIR 提供了標準化、可跨系統的臨床資料授權與存取模型，讓「哪個 App 能讀哪個病人的哪些資料」有明確、可稽核的規範。

核心：辨識 → 確認 → 授權的三段身分鏈

核心觀念：「哪個 LINE 帳號」≠「哪個病人」≠「可讀哪些病歷」。
三者是三個獨立事實，必須分別建立，不能用其中一個推論另一個。

段落	問的問題	機制	失效後果
辨識	這是哪個 LINE 使用者？	LINE Login（OAuth2）→ `line_user_id`	不知道對象是誰
確認	這個使用者對應哪個病人？	院內臨櫃 KYC 綁定 `line_user_id ⟷ patient_id`	冒用他人病歷（最嚴重）
授權	這個病人可讀哪些資料？	FHIR OAuth2 Auth Code + PKCE + scope	越權讀取、過度揭露

sequenceDiagram
    autonumber
    participant U as 病人(LINE)
    participant L as LIFF / LINE Bot
    participant LL as LINE Login
    participant B as 院內綁定服務
    participant AS as FHIR Auth Server
    participant API as FHIR API

    U->>L: 開啟 LIFF / LINE Bot
    L->>LL: LINE Login (OAuth2)
    LL-->>L: line_user_id
    Note over U,B: 首次綁定：本人臨櫃 KYC<br/>(證件查驗 + 簽同意書 + 門號 OTP 測試)
    U->>B: 臨櫃核對證件、簽同意書、驗證手機門號
    B->>B: 建立 line_user_id ⟷ patient_id(高保證)
    B-->>L: 綁定完成(已知是哪個病人)
    L->>AS: Authorization Code + PKCE(病人同意 scope)
    AS-->>L: Access Token(帶 scope)
    L->>API: 用 Token 讀 Patient/Observation/MedicationRequest
    API-->>L: 依 scope 回傳病歷資料

隱私優先的四個設計準則

最弱環節是綁定，不是加密。OAuth2 / PKCE / TLS 都是成熟標準，真正容易被攻破的是
「院內綁定」這一步。病歷是高敏感 PHI，綁定的身分保證等級不應低於金融開戶：
首次採臨櫃 KYC（證件查驗 + 簽署同意書 + 門號 OTP），異動（換號 / 重綁 / 換裝置 /
解綁再綁）一律同級，不得用「已綁定」降階放行。
public client 決定用 PKCE。LIFF 在 WebView，不能藏 secret，
Authorization Code + PKCE 是正解。PKCE 保護的是「授權碼」不被攔截冒用，
資料在網路上的加密靠 TLS —— 這兩件事別混為一談（詳見 fhir-oauth2-pkce-data-exchange）。
scope 最小化。Access Token 只授予完成該功能所需的最小資料範圍；
查用藥的功能就不該能順便讀到全部檢驗影像。
同意可撤回、綁定可解除。病人撤回同意或解綁時，對應的 token 與綁定關係要能即時失效，
並留下完整、可舉證的稽核軌跡（對齊 fhir-box-phi-security-guide）。

一句話總結

用 LINE Bot 當入口、SMART on FHIR 當授權骨幹，能讓病人「開 LINE 就查病歷」；
但要做到隱私優先，關鍵不在加密演算法，而在中間那段「院內綁定」驗證得夠不夠嚴 ——
因為它守的是 PHI，就該用金融級臨櫃 KYC，而非便利優先的線上自助。

這場演講

為什麼是 LINE Bot × SMART on FHIR

核心：辨識 → 確認 → 授權 的三段身分鏈

隱私優先的四個設計準則

一句話總結

延伸閱讀

核心：辨識 → 確認 → 授權的三段身分鏈