不知不覺，這個系列終於來到第30天。
一開始決定以 FHIR 作為鐵人賽主題時，我其實只知道它與醫療資料交換有關，對 Resource、Reference、Profile 及 Implementation Guide 等名詞都不熟悉。
經過30天的整理，我逐漸發現，FHIR 並不是單純的資料格式，也不只是把病歷轉換成 JSON。它真正想解決的，是不同醫療系統之間如何用共同的方式表達、理解與交換資料。
今天不再介紹新的 FHIR Resource，而是回顧這30天走過的內容，重新回答最初的問題：
30天後，我真的看懂 FHIR 了嗎？
在還沒有深入認識 FHIR 以前，我以為醫院之間只要把資料傳送出去，就能完成醫療資訊交換。
後來才發現，事情沒有這麼簡單。
不同醫院的系統可能使用不同的：
例如，同樣是血糖檢驗，有些系統可能記錄成「血糖」，有些寫成英文名稱，也有些只儲存院內自訂代碼。人類可能看得懂它們的意思，但電腦不一定知道這些資料代表同一個概念。
因此，醫療資料交換不只是「把資料送出去」，還必須讓接收端正確理解資料。
這正是 FHIR 想處理的核心問題。
系列前幾天先從醫療資訊的基本問題開始，包含：
這一階段讓我明白，醫院並不是只使用一套系統。
掛號、批價、門診、住院、檢驗、影像、藥局及電子病歷等服務，可能由不同系統負責。這些系統必須持續交換病人、就醫、醫囑與檢查結果。
如果每套系統都使用自己的資料格式，就需要建立大量客製化的轉換方式。當其中一個系統更新時，原本的介接也可能需要調整。
FHIR 的價值，就是提供一套大家可以共同理解的資料模型與交換方式，降低系統之間各說各話的情況。
接著，我開始認識 FHIR 最重要的概念：Resource。
FHIR 將醫療資訊拆分成一個個具有明確用途的 Resource，例如：
| Resource | 代表的資料 |
|---|---|
| Patient | 病人基本資料 |
| Encounter | 一次門診、急診或住院 |
| Condition | 疾病、診斷或健康問題 |
| Observation | 檢驗結果、生命徵象或觀察資料 |
| DiagnosticReport | 檢驗或檢查報告 |
| MedicationRequest | 藥物請求或用藥醫囑 |
| Practitioner | 醫療專業人員 |
| Organization | 醫院、診所或其他機構 |
這種設計讓不同種類的資料各自具有清楚的責任。
Patient 不需要包含病人的所有就醫紀錄；Observation 也不需要重複保存完整的病人資料。各個 Resource 可以獨立存在，再透過 Reference 建立關係。
這是我在整個系列中認為最重要的觀念之一。
FHIR 資料經常使用 JSON 表示，因此初次看到 FHIR 時，很容易將注意力全部放在大括號、欄位名稱與資料層級上。
但經過這次整理，我了解到 JSON 只是 FHIR 資料的一種呈現格式。
真正重要的是欄位背後的意義，例如：
resourceType 表示這是哪一種 Resourceidentifier 表示業務上的識別碼status 表示資料目前的狀態code 表示標準化的醫療概念subject 表示資料描述的對象encounter 表示資料所屬的就醫情境reference 表示與其他 Resource 的關聯就算 JSON 的格式完全正確，如果欄位選擇錯誤、代碼使用不一致，或資料連到錯誤的病人，仍然不能算是正確的醫療資料。
因此，看懂 FHIR 不只是看懂 JSON，更需要理解它的醫療語意與資料關係。
第11天介紹的 Reference，在後面的文章中不斷出現。
一筆病歷不會只由單一 Resource 組成。它可能包含：
Reference 就像連接這些資料的線。
例如，Observation 可以指向 Patient 與 Encounter，表示某筆檢驗結果屬於哪位病人，以及它在哪次就醫中產生。
DiagnosticReport 也能透過 result 連結多筆 Observation，將個別檢驗項目組成一份完整報告。
到了第29天，當這些 Resource 被放回同一次門診情境時，我才更清楚地看見 FHIR 的整體設計。
FHIR 並不是把所有資料塞進一個巨大檔案，而是讓許多具有明確意義的 Resource 組成一張醫療資料網絡。
認識多筆 Resource 之後，也需要分清楚 Bundle 與 Reference。
Bundle 可以將多筆 Resource 集合在一起，方便進行搜尋結果回傳、文件組成或其他形式的資料交換。
但 Bundle 本身不會自動說明這些 Resource 的臨床關係。
例如，Patient、Encounter 與 Observation 即使同時出現在同一個 Bundle 中，也不能只因為它們放在一起，就認定彼此屬於同一次就醫。
真正建立關係的仍然是 Resource 中的 Reference。
所以：
這兩個觀念看起來相似，實際用途卻不同。
如果醫療資料只使用自然語言，不同系統可能用不同名稱描述同一件事。
因此，FHIR 經常搭配標準醫療術語與代碼系統，例如：
FHIR 中的 Coding 通常不只記錄顯示文字，也會記錄代碼與所屬系統。
這讓接收端不必只依靠文字猜測資料意義，而能根據代碼進行較一致的辨識。
我也因此了解到，醫療資料互通至少包含兩個層次：
FHIR 提供資料架構，標準術語與代碼則協助建立共同語意，兩者缺一不可。
在系列中，我也整理了 REST API 以及 GET、POST、PUT、DELETE 等基本概念。
它們可以概念性地理解為：
| 方法 | 常見用途 |
|---|---|
| GET | 讀取或搜尋資料 |
| POST | 建立新的資料 |
| PUT | 更新指定資料 |
| DELETE | 刪除資料 |
不過，這些方法只描述系統與資料互動的基本方式。
一個真正的 FHIR 服務還需要透過 CapabilityStatement 說明：
因此，知道 FHIR 的基本操作方式，不代表每一台 FHIR Server 都具有完全相同的功能。使用前仍需了解各系統公開的能力與規範。
FHIR 必須提供全球使用，因此原始規格保留許多彈性。
但彈性太大也會產生問題。兩間醫院都使用 Patient Resource，仍可能分別選擇不同欄位、不同識別方式及不同代碼。
Profile 可以針對特定情境限制 Resource，例如：
如果原始 Resource 沒有適合的欄位，則可以透過 Extension 補充特殊需求。
這讓我明白，採用 FHIR 並不是只選擇 Patient 或 Observation，而是還需要確認使用哪個版本、遵循哪一份 Implementation Guide，以及資料符合哪個 Profile。
FHIR 是國際標準，但台灣具有自己的醫療制度、身分識別方式、中文姓名、地址格式及醫療代碼。
因此，台灣需要自己的核心實作規範，也就是 TW Core IG。
TW Core IG 在 FHIR 的基礎上，進一步定義適合台灣使用的：
例如，TW Core Patient 仍然是一種 Patient Profile，但會更進一步考慮台灣常見的病人識別與資料表示需求。
TWCDI 則著重定義台灣醫療資訊互通所需的核心資料項目。兩者互相配合，一邊說明應該交換哪些資料，一邊說明這些資料如何使用 FHIR 表達。
這讓國際標準能真正配合台灣的醫療環境，而不是停留在通用規格層面。
在認識 FHIR 的最後階段，我也重新思考了醫療資料安全。
FHIR 讓資料更容易交換，但病歷並不會因此變成任何人都能讀取的公開資料。
一個實際使用的 FHIR 系統仍然需要：
FHIR 也提供 Consent、AuditEvent、Provenance 與 Security Label 等設計，協助系統表達同意、稽核事件、資料來源及敏感程度。
但這些內容不會自動完成所有安全防護。真正的醫療資料安全，仍然需要技術、制度、流程與人員共同維護。
對醫療資訊來說，「資料能不能交換」與「資料該不該提供」是兩個不同的問題。
如果「看懂 FHIR」是指熟悉所有 Resource、Profile、代碼系統與實作細節，那麼30天顯然還不夠。
FHIR 的規格範圍非常大，不同醫療情境也可能使用完全不同的 Resource。即使是實際從事醫療資訊工作的人，也不一定需要一次熟悉全部內容。
但如果「看懂 FHIR」是指掌握它的基本邏輯，我認為這30天已經建立了一個起點。
現在看到一筆 FHIR 資料時，我至少知道可以先思考：
能夠提出這些問題，就代表我不再只把 FHIR 看成陌生的英文欄位，而是開始理解它如何組織醫療資訊。
這個系列帶給我的最大收穫，不是記住每個 Resource 的所有欄位，而是建立了一張理解醫療資料交換的地圖。
現在我知道：
這些概念可能還不足以直接處理所有真實專案，卻提供了繼續學習 FHIR 所需要的共同基礎。
醫療資訊位在醫療與資訊技術的交界。
只懂程式，可能不容易理解醫療資料的臨床意義；只懂醫療流程，也可能無法判斷系統如何儲存及交換資訊。
FHIR 剛好位於這兩個領域之間。
學習 FHIR 的過程會接觸到：
因此，即使未來不成為專門開發 FHIR 系統的工程師，理解這套標準仍然有助於與醫療人員、資訊人員及系統廠商溝通。
對醫資學生來說，這也是認識「醫療需求如何轉換成資訊規格」的一個具體入口。
鐵人賽的第30天是這個系列的終點，但不會是 FHIR 學習的終點。
如果未來想繼續了解 FHIR，可以從不同方向深入：
不需要一次學會全部內容。先掌握整體架構，再根據實際需求逐步深入，會比單純背誦大量欄位更容易理解。
回頭看這30天，我發現原本看起來非常複雜的 FHIR，其實可以從幾個問題慢慢拆解。
先理解醫療資料為什麼需要交換，再認識 Resource 如何分類資料，接著了解 JSON、Reference、代碼、API、Profile 與資安，每一個概念都在補上醫療資訊互通的一部分。
FHIR 不是一套能消除所有醫療資訊問題的工具。
不同機構仍然需要協調資料需求、統一代碼、維護資料品質、確認病人身分、管理存取權限，並遵守相關法規。FHIR 提供的是一個共同基礎，讓這些工作有機會在更一致的架構上進行。
這30天讓我從「知道 FHIR 這個名詞」，走到可以理解一組醫療資料為什麼需要不同 Resource、它們如何互相連結，以及台灣為什麼需要 TW Core IG。
我還不能說自己已經完全學會 FHIR，但至少不再覺得它是一套完全陌生、無法理解的規格。
而這正是這次30天學習最重要的成果。
30天前，我從「FHIR 是什麼」開始；30天後，我已經能從醫療資料交換的角度，理解 Resource、Reference、Bundle、API、Profile、Implementation Guide、TW Core IG 與資訊安全之間的關係。
學習 FHIR 並不是把所有規格背起來，而是先建立正確的理解方式：
完成鐵人賽不代表已經成為 FHIR 專家，但代表我已經踏出理解醫療資料互通的第一步。
這30天的系列到這裡正式告一段落。未來再次看到 Patient、Observation 或 Encounter 時，它們不再只是陌生的英文名稱，而是組成醫療資訊交換的重要角色。
謝謝閱讀這個系列，也謝謝30天來沒有放棄的自己。
iThome鐵人賽
看影片追技術