[耀瑄科技 新創小組]
在這場由 工研院受衛生福利部委託舉辦的 SMART on FHIR 工作坊 一開始，講者並沒有立刻進入技術細節，而是先花了相當多時間，帶大家重新思考一個問題：
在醫院資訊環境裡，「應用系統」到底是怎麼被建構出來的？
這個問題，看似簡單，卻正好點出了傳統醫療 IT 發展長期以來的痛點。
在台灣醫院的實務環境中，不論是 HIS、EMR、檢驗系統或影像系統，大多數都是：
- 不同廠商
- 不同年代
- 不同資料格式
- 不同存取方式
這意味著，只要想多做一個新功能或新應用，就得重新整合一次資料。
講師在工作坊中用非常直白的方式描述這件事： 如果今天要做一個新的病人相關應用，開發者往往必須：
- 自行理解各院資料結構
- 自行撰寫客製 API
- 自行處理帳號、權限與資安
結果就是—— 👉 每一個系統，都是孤島。
SMART on FHIR 的出現，並不是要推翻既有的醫院系統，而是試圖解決一個更根本的問題：
能不能用「共同標準的資料介面」，來支撐「各式各樣的醫療應用」？
講師在介紹中強調，SMART on FHIR 的概念其實很像我們熟悉的 App 生態系：
- 作業系統負責安全與資料
- App 專注在功能與價值
- 開發者不用為每一台設備重寫一次
FHIR，扮演的就是這個「標準化資料介面」的角色。 SMART，則是在 FHIR 之上，補上 啟動、授權、身份驗證 的完整機制。
講師特別花了一段時間說明 API 的價值，但這裡的重點並不只是技術。
如果每一家醫院都能：
- 將病人、檢驗、用藥、檢查等資料
- 以標準化 FHIR API 的方式提供
那麼對應用開發者來說：
- 不需要知道醫院內部資料庫長什麼樣
- 不需要重寫每一家醫院的整合程式
- 只要遵循標準 API，就能存取資料
這正是 SMART on FHIR 想要建立的世界： 👉 資料用標準說話，應用就能被重用。
當然，醫療資料不是一般資料。
因此講師也特別強調，SMART on FHIR 並不是「全面開放資料」，而是：
- 在合法、合規的前提下
- 有限制地開放
- 並且能被完整追蹤
這也是為什麼 SMART on FHIR 一定會搭配：
- OAuth 2.0
- OpenID Connect
- 使用者身份與授權範圍（Scope）
這些機制的目的只有一個：
確保每一個 App，只能在被允許的範圍內，存取被允許的資料。
在第一段介紹中，講師也快速帶過 SMART App 的三種主要使用情境，為後續實作鋪路。
- App 直接嵌入醫院系統
- 醫護人員在既有工作流程中啟動
- 不需重新登入
👉 最貼近臨床使用情境
- 通常由病人或使用者自行啟動
- 透過身份驗證後連接 FHIR Server
- 常見於病人端應用
👉 適合病人服務與跨院應用
- Server 對 Server 的存取
- 無需使用者互動
- 常見於 AI、自動分析、批次處理
👉 醫療 AI 與自動化流程的關鍵模式
在介紹後段，講師提到國際上已有大量 SMART App 範例，並集中在官方的 SMART App Gallery 中。
這些 App 涵蓋：
- 臨床決策輔助
- 病人資料視覺化
- 用藥與檢驗管理
- AI 與影像分析應用
重點不在於功能多炫，而在於：
它們都遵循同一套啟動與資料存取規則。
這正是 SMART on FHIR 能夠形成生態系的關鍵。
在前半段介紹中，我們談到 SMART on FHIR 的核心價值： 它不是單純的 API 規格，而是一套**「讓醫療應用被安全啟動、被正確授權」的機制**。
而這套機制，實際上會依照「誰在用、什麼時候用、用來做什麼」，分成三種啟動模式：
- EHR Launch
- Standalone Launch
- Backend Service
這三種模式，看起來只是技術選項，但實際上，它們對應的是完全不同的醫療使用場景。
想像一個最典型的臨床畫面：
- 醫師已經登入醫院的 HIS / EMR
- 正在看某一位病人的病歷
- 在不離開畫面的情況下，點開一個額外的輔助工具
這個時候，用的就是 EHR Launch。
整個流程，其實是由「醫院系統」主動發起的：
醫師登入 EHR（已完成身份驗證）
醫師在病人畫面中點擊某個 SMART App
EHR 以 Launch URL 啟動 App
- 同時帶入病人 ID
- 帶入使用者身份
- 指定可用的 FHIR Server
App 依據這些資訊，進行 OAuth 驗證
成功後，App 就能在「被授權的範圍內」讀取資料
整個過程中，醫師不需要再登入一次。
因為它有三個非常重要的優點：
- ✅ 不破壞醫師原本的工作流程
- ✅ 病人已經被「上下文鎖定」，不會選錯人
- ✅ 權限由醫院系統統一控管
這也是為什麼在實務上：
只要是「院內臨床人員使用的 App」，EHR Launch 幾乎都是第一選擇。
再換一個畫面。
這一次，不是在醫院裡，而是：
- 病人在家裡
- 或研究人員在院外
- 或跨院平台想要存取某家醫院的資料
這時候，App 不是從 EHR 被點開的，而是「自己啟動」。
這就是 Standalone Launch。
因為沒有 EHR 幫你「帶上下文」，流程會稍微多一點：
使用者先打開 App（Web / Mobile）
App 必須先知道：
- 要連哪一個 FHIR Server
App 將使用者導向醫院的認證頁面
使用者完成登入（醫院帳號 / 病人帳號）
醫院顯示「授權畫面」，讓使用者同意：
- 這個 App 可以存取哪些資料
授權完成後，App 取得 Access Token
App 才能呼叫 FHIR API
在台灣情境下，Standalone 常見於：
- 病人端 App（檢查報告查詢、追蹤工具）
- 跨院平台
- 研究用資料存取（在合規前提下）
但也因為流程比較長、資安要求高，導入時通常需要：
- 資訊室
- 資安
- 法遵單位
一起評估。
最後一種模式，其實是這幾年才真正開始受到重視的。
它對應的不是「人」，而是「系統」。
例如：
- AI 自動分析影像
- 夜間批次運算
- 自動品質監控
- 系統間資料同步
這些情境下，沒有使用者登入畫面。
Backend Service 的流程，完全不同：
- 系統（Server）事先完成註冊
- 使用憑證（Public / Private Key）進行身份驗證
- 取得系統層級的 Access Token
- 直接呼叫 FHIR API
- 將結果寫回 FHIR（通常是 Observation）
整個過程中：
- ❌ 沒有使用者介入
- ❌ 沒有畫面
- ✅ 完全自動化
因為它解決了一個關鍵問題：
AI 不應該打斷醫師流程，但又必須進得了醫療系統。
透過 Backend Service：
- 醫師照常看影像
- AI 在背景自動分析
- 結果直接回寫系統
- 醫師看到的，是「已整理好的資訊」
這正是目前許多醫療 AI 導入時，最理想的架構。
如果把這三種模式放在一起看，你會發現一個很清楚的演進方向：
- EHR Launch：先進臨床流程
- Standalone：再擴到病人與跨院
- Backend Service：最後做到自動化與規模化
這也正是為什麼在這場工作坊的「第一段介紹」中，講師會先把這三種模式全部講清楚。
因為它們不是選項，而是未來醫療應用一定會走過的三個階段。
SMART on FHIR 真正厲害的地方，不在於它定義了 API， 而在於它清楚定義了： 「在什麼情境下，用什麼方式，安全地使用醫療資料。」
回頭看這場工作坊的第一段介紹，可以發現講師並不是在「教技術」，而是在做三件事：
- 說明醫療系統現有的結構性問題
- 解釋 SMART on FHIR 想解決的是什麼
- 為後續實作建立共同語言與理解基礎
也因此，這一段內容更像是在告訴大家：
SMART on FHIR，不只是規範，而是一條讓醫療應用「走得出去、走得久」的路。
沒有留言:
張貼留言