這篇文章，想用一個非常務實、已經完成的實例，來回答許多醫院人員與第一次接觸 FHIR 的朋友常問的問題：
「FHIR 到底能幫醫院做什麼？」 「為什麼以前這類系統很難做，現在卻可以在兩週內完成？」 「FHIR 與 SMART on FHIR 的真正價值在哪？」
以下內容，將以耀瑄科技新創小組實際開發的 「以病人為主的看診紀錄時序圖應用」 為核心案例，從臨床、資訊、管理與系統設計多個角度，帶你一步一步理解。
這是一套 以病人為核心（Patient-centric） 的醫療資料視覺化應用系統，主要功能包括：
- 以「單一病人」為主軸
- 將該病人跨年度、跨次就診的紀錄
- 依照**時間順序（Timeline）**整合呈現
- 一眼看懂「什麼時候、發生了什麼醫療事件」
病人基本資料
- 姓名、年齡、性別、身高、體重
- 病歷號、身分識別資訊
年度／月份時間軸
- 例如：1991 年 2 月、3 月有哪些就診
每一次看診的摘要
- 門診 / 急診 / 住院
- 診斷重點（如：流產、乳癌）
診斷內容時間表
- 不需要打開多個系統
- 不需要翻閱厚重病歷
👉 重點是：這一切資料都來自 FHIR Server，而不是客製化 HIS API。
這個系統的資料來源是：
HAPI FHIR 公開測試 Server（R4） https://hapi.fhir.org/baseR4
這是一個完全符合 HL7 FHIR R4 規範的免費 FHIR Server，提供標準 RESTful API。
Patient：病人基本資料Encounter：每一次就診（門診／住院／急診）Condition：診斷、問題列表Observation：身高、體重、檢驗數值（未來可擴充）
MedicationRequestProcedureDiagnosticReport
因為：
- FHIR 已經幫我們把資料結構定義好了
- 不用跟每一家醫院重新討論資料格式
- 不用寫大量 ETL 或轉檔程式
- 只要懂 FHIR Resource 與查詢方式，就能開發
👉 對工程師來說，這不是「寫醫療系統」，而是「使用一個標準 API」。
這一段，對醫院資訊人員與管理層特別重要。
傳統狀況：
- 每家 HIS 廠商資料結構不同
- 同樣是「診斷」，在不同系統欄位完全不一樣
- 想跨系統整合 → 幾乎等於重做一套系統
👉 沒有共同語言，系統就無法快速開發。
過去系統設計大多是：
- 以「表單」為中心
- 以「科別系統」為中心
- 以「申報流程」為中心
結果是：
- 一個病人的資料散落在 N 個系統
- 很難用「時間軸」方式整合呈現
👉 FHIR 天生就是以病人為核心設計。
以往常見情境：
- 想做一個新視覺化 → 再寫一次 API
- 換一家醫院 → 再重寫一次
- 系統維護成本極高
👉 FHIR 把「資料取得」變成可重複使用的基礎建設。
- 快速看到病人完整歷程
- 降低跨科、跨年度資訊落差
- 提升臨床決策效率
- 系統開發週期大幅縮短
- 新應用可以「小步快跑、快速驗證」
- 降低長期 IT 維運與整合成本
- 不必一次汰換現有 HIS
- 可以用 FHIR Gateway / 中介層 漸進導入
- 降低與多家廠商整合的複雜度
- 可以直接支援第三方 App
- 符合國際趨勢與台灣政策方向
- 為 AI、研究、數據中台鋪路
「病人時序圖」並不是終點，而是FHIR 應用的第一個高價值入口。
在這個基礎上，還可以延伸：
- 個管師專用追蹤視圖
- 慢性病照護時間線
- 腫瘤治療療程總覽
- AI 風險評估結果疊加
- SMART on FHIR App 市集應用
👉 一旦資料標準化，創意與價值才會真正爆發。
耀瑄科技新創小組，近年持續投入：
- FHIR Server 架構設計
- FHIR Gateway 與既有 HIS 整合
- 病人為主的時序視覺化應用
- SMART on FHIR App 實作
- 臨床研究、AI 與資料中台整合
這個「兩週完成的系統」不是偶然，而是：
長期累積標準理解 × 實務導向開發 × 醫療場域經驗
FHIR 不是要你立刻重建所有系統 而是讓你「終於可以開始做以前想做、卻做不到的事」
如果你是：
- 醫師
- 個管師
- 醫院資訊人員
- 管理者
- 或對醫療資訊未來有興趣的人
那麼，FHIR + SMART on FHIR，會是未來 5–10 年醫療系統演進的關鍵基礎。
沒有留言:
張貼留言