重點摘要
換一家醫院常常要重做檢查、重填一次病史 —— 很大原因是各家系統的病歷資料格式不一樣、互通不了。HL7 FHIR 就是為了解這個問題而生的現代標準。這篇白話講互通到底難在哪、FHIR 怎麼解,以及我做的 POC(clinconvert)在試什麼。先講清楚:我做的是研究型概念驗證,不是診所即用的工具。
互通難在哪
想像兩家醫院都存「病人的血壓」,但:
- A 院存成
BP: 120/80,B 院存成兩個欄位systolic=120, diastolic=80 - A 院的「腎功能」欄位叫
eGFR,B 院叫GFR_est - 日期一個是
2026/07/01,一個是01-JUL-2026 - 檢驗項目的代碼,兩家用不同的內部編號
單一數值都對得上,但只要欄位名稱、結構、代碼、格式各自為政,程式就沒辦法自動把 A 院的資料讀進 B 院。得靠人工對照、或每兩家系統之間寫一套客製轉換。醫院一多,轉換組合就爆炸。
這不是技術做不到,是缺一套「大家都同意的共同語言」。
FHIR 怎麼解:標準化的「資源」+ 網路 API
FHIR 的想法是把醫療資料拆成一組標準化的積木,叫「資源(Resource)」。常見的例如:
Patient(病人基本資料)Observation(一筆觀測值,例如血壓、eGFR)Condition(診斷)MedicationRequest(處方)
每種資源長什麼樣、有哪些欄位、欄位叫什麼名字,都由標準統一規定。這樣一來:
- A 院和 B 院的血壓都用
Observation這個標準結構表達 → 程式讀得懂彼此。 - 檢驗項目用共通的代碼系統(例如 LOINC)標示 → 不再各用各的內部編號。
- 交換方式用標準的網路 API(就是現代網頁在用的那種),不必為每家系統另接。
多筆資源可以打包成一個 Bundle 一起傳。R4 是目前最廣泛採用的 FHIR 版本。
我做的 POC:clinconvert 在試什麼
現實是:很多基層診所的資料還躺在 Excel 裡。要它們一步跳到 FHIR 太遠。所以我做了 clinconvert,試一個具體問題:
能不能把 Excel 病歷資料,自動結構化成 HL7 FHIR R4 的 Bundle?
它做的事:
- 讀進 Excel / CSV,把每一列對應到 FHIR 資源(
Patient、Observation…)。 - 用可插拔的模組化設計(不同欄位對應規則可替換),而不是寫死一套。
- 全程在瀏覽器本地處理,檔案不上傳;搭配 Web Crypto 零知識加密。
- 產出可以丟給標準 FHIR 伺服器(HAPI FHIR)驗證的 Bundle。
誠實說:它的定位與限制
這一段我要講得很清楚,因為醫療領域最忌諱誇大:
- clinconvert 是研究型 POC,不是診所即用的產品。它驗證的是「Excel → FHIR 這條路可行、以及模組化設計怎麼做」,不是一套通過臨床驗證、可以直接上線的工具。
- 真實病歷的髒亂遠超過乾淨的示範檔 —— 缺漏值、自由文字、不一致的單位,都是真實導入才會碰到的硬骨頭。
- 互通的最後一哩是「語意」不只是「格式」:把欄位對齊只是第一步,確保「A 院的這個代碼和 B 院的那個代碼真的指同一件事」才是難的部分。
我把它定位成工程展示 + 研究探索的延伸,而不是宣稱解決了醫療互通。這個議題本身,正是我想在研究所繼續深入的方向之一。
延伸閱讀
- 被問到「你的系統架構長怎樣」,我會怎麼講 ── 醫療系統的分層設計
- clinconvert ── 這個 FHIR 轉換 POC 本身(瀏覽器本地處理)