文章目錄
Key Takeaways
- 台灣醫療數據的核心問題不是「資料太少」，而是同一位病人的資料分散在不同格式、不同系統，無法被機讀。
- FHIR R4 是 HL7 推出的第一個正式規範版本，以 RESTful API 和 JSON 為基礎，讓不同醫療系統能用同一套語言交換資料。
- 衛福部國衛院與健保署均已推動 FHIR R4 試辦，但院所端的實作仍高度分散。
- Taiwan Health MCP 的 8 個服務模塊，對應台灣現場最常見的醫療數據類型：診斷碼、藥品、檢驗、臨床指引、電子病歷、病人資料、預約，以及自然語言轉 FHIR。
- 下一步：Taiwan Health MCP 已在 GitHub 開源，歡迎醫療從業人員提出實際場景需求。
一個護理師每天都在做的事
某醫院護理站，一位護理師正在處理一位從外院轉入的 68 歲慢性心衰竭患者。上一家醫院的出院摘要是 PDF 掃描版，裡面的藥物名稱是舊版商品名，而本院 HIS 系統認不出來。她需要手動比對藥典，確認是否與目前的處方重複用藥。這個過程大概花了她 20 分鐘。
這不是特例，這是台灣很多二線以上醫院的日常。
問題不在於病歷資料不存在，而在於它以不同格式鎖在不同系統裡，每次跨院轉診都需要人工轉換。這是「數據孤島」的具體樣子，不是抽象的數位轉型口號。
台灣醫療數據的實際問題
台灣的醫療機構密度高，但系統異質性也高。同樣是「血壓記錄」，不同 HIS（醫院資訊系統）廠商的欄位名稱、資料型別、數值單位都可能不同。這帶來幾個現實困境：
跨院轉診 仍高度依賴紙本或 PDF。病人自己帶著一疊影本去下一家醫院，醫師重新問診。
重複用藥與重複檢驗 因為查不到其他院所的處方紀錄，可能讓病人做了已經做過的 CT 或血液檢查，增加輻射暴露與醫療費用。
臨床研究的資料前處理 耗時佔了研究時間的大頭。研究人員在能跑任何分析之前，往往要先花幾個月清洗來自不同系統的資料。
AI 應用的數據準備 更是直接受阻。你沒辦法用格式五花八門的資料訓練或驗證一個醫療 AI 模型。
這些問題的根源是同一個：缺乏標準。
FHIR R4：為什麼是現在？
HL7 推出 FHIR（Fast Healthcare Interoperability Resources）已有多年，但 R4（Release 4）是第一個被認定為「規範性（Normative）」的版本——意思是這個版本的核心規格不會再有破壞性改動，可以放心作為長期系統整合的基礎。
FHIR 的設計有幾個在技術上值得注意的選擇：
資源化（Resource-based）：醫療數據被拆解成標準化的「資源」單位。一位病人是 Patient，一筆診斷是 Condition，一個處方是 MedicationRequest，一份檢驗結果是 Observation。每種資源都有明確的欄位定義，不同系統傳輸同樣資料時，語義不會跑掉。
現代 API 設計：FHIR 以 RESTful API 為基礎，用 JSON 或 XML 傳遞資料。這讓它對現代開發者相當友善，不需要學習傳統 HL7 v2 那套用管線符號分隔的傳統格式。
可延伸性（Extension）：FHIR 允許在標準資源上加掛自訂欄位（Extension），各國可以在國際標準的基礎上，加入本地需求。台灣的健保 ID、院所代碼、中文藥品名稱，都可以透過 Extension 納入。
台灣的 FHIR 推行現況
衛福部國家衛生研究院（國衛院）已建立台灣版的 FHIR Implementation Guide，針對台灣醫療現場的特殊需求定義了 Terminology 與 Profile。健保署也在 API 開放政策中納入 FHIR 格式，作為電子病歷交換的標準之一。
但實作現況仍然分散。大型醫學中心走得較前面，部分已有 FHIR R4 相容的 API。中型院所與基層診所的步調落差很大。Taiwan Health MCP 的設計目標之一，正是在這段落差期間提供一個橋接層，讓不完全符合 FHIR 標準的舊有系統，也能透過標準介面被存取。
Taiwan Health MCP 的 8 個核心服務模塊
MCP（Model Context Protocol）扮演的角色是「轉譯器」：把 AI 模型（如 Claude、GPT）的意圖，轉換為對後端醫療數據服務的標準呼叫，並把結果以 AI 可理解的格式回傳。Taiwan Health MCP 在這個架構上，建立了對應台灣醫療現場的 8 個服務模塊。
1. ICD Service（診斷與手術碼）
負責 ICD-10-CM（國際疾病分類臨床修訂版）與 ICD-10-PCS（手術程序編碼）的查詢、診斷併發症推論與衝突檢查。整合衛福部 ICD-10 中文化資料，查詢結果可轉換為 FHIR Condition 資源。
實際應用： 病歷助理 AI 產出「高血壓」診斷後，可呼叫此服務確認正確的 ICD-10 碼，並檢查是否與其他已記錄的診斷存在衝突（例如同時記錄了互斥的診斷碼）。
2. Drug Service（藥品整合）
整合台灣食品藥物管理署（TFDA）五個官方藥品資料集：藥品許可證、外觀識別、成分、ATC 藥物分類、仿單說明書。查詢結果轉換為 FHIR Medication 或 MedicationKnowledge 資源。
實際應用： 轉診病人帶來外院舊處方，AI 可透過外觀識別（藥片顏色、刻字）反查藥品名稱與成分，確認是否與目前處方重複用藥。
3. Lab Service（檢驗標準）
核心是整合 LOINC（Logical Observation Identifiers Names and Codes）檢驗碼，提供台灣常用檢驗項目的 LOINC 對照表、依年齡與性別的參考值查詢，以及批次判讀功能。
實際應用： 電子病歷 AI 在讀取血液檢驗報告時，可自動對照 LOINC 碼並標記異常值，無需人工核對參考範圍。
4. Guideline Service（臨床指引）
整合台灣醫學會發布的臨床診療指引，提供指引查詢、診斷建議、用藥建議與檢查建議。
實際應用： AI 臨床決策輔助工具在給出用藥建議時，可呼叫此服務確認建議是否符合台灣醫學會的現行指引，並在建議旁顯示指引出處。
5. Patient Service（病人資料）
以 FHIR Patient 資源為基礎，提供病人基本資料的標準化存取介面，包含台灣特有的欄位（健保 ID、身分證號、戶籍地）。
實際應用： 跨院資料查詢的基礎層，確保不同系統在交換病人資料時，能正確對應同一位病人的身份。
6. Encounter & Record Service（就診紀錄）
對應 FHIR Encounter、DocumentReference、DiagnosticReport 等資源，處理就診紀錄、檢查報告與文件的存取。
實際應用： 讓 AI 在回答「這位病人上次來的主訴是什麼」時，能從 FHIR 格式的就診紀錄中取得結構化答案，而非解析純文字 PDF。
7. Appointment Service（預約排程）
對應 FHIR Appointment 與 Schedule 資源，提供預約查詢、建立與取消功能。
實際應用： AI 助理在完成診斷後，可直接呼叫此服務協助安排下次回診，無需跳轉到另一套系統。
8. FHIR Conversion Service（自然語言 → FHIR）
這是整個架構中最直接面向 AI 應用的一層：把 LLM 產出的自然語言或半結構化內容，轉換為標準 FHIR 資源格式，供下游系統使用。
實際應用： 醫師口述病歷，AI 整理後透過此服務輸出為 FHIR Composition（出院摘要）或 FHIR Bundle（完整就診記錄），可直接寫入 EMR 或供其他院所讀取。
系統架構：各層職責
使用者 / AI 模型
│
▼
MCP 層（意圖轉譯 + Tool Routing）
│
▼
Taiwan Health MCP 服務層
├── ICD Service
├── Drug Service
├── Lab Service
├── Guideline Service
├── Patient Service
├── Encounter & Record Service
├── Appointment Service
└── FHIR Conversion Service
│
▼
FHIR R4 資源層（標準化輸出）
│
▼
後端資料來源
├── 台灣 HIS / EMR 系統
├── 衛福部 / TFDA 官方資料集
└── 健保署 API
每一個服務模塊的輸出都是標準 FHIR 資源，不管後端資料來源的格式如何，輸出介面保持一致。這讓 AI 應用不需要為每一家醫院的 HIS 寫客製化的資料解析邏輯。
實際整合場景
場景一：轉診資料整合
68 歲心衰竭患者從外院轉入，護理師在 AI 助理介面中輸入「讀取轉診資料」。系統透過 Patient Service 確認身份，透過 Encounter Service 取得外院就診記錄（若已 FHIR 化），透過 Drug Service 比對用藥清單，在 30 秒內產出重複用藥警示與缺漏病史摘要。
場景二：AI 病歷助理的診斷編碼
住院醫師完成問診後，AI 助理建議診斷。系統呼叫 ICD Service 確認診斷碼，呼叫 Guideline Service 核對治療建議，最後透過 FHIR Conversion Service 產出標準格式的 FHIR Condition 與 CarePlan，寫入 EMR。
場景三：臨床研究資料準備
研究人員設定篩選條件（年齡、診斷、藥物），系統透過各服務模塊的 FHIR 輸出，直接產出標準化的研究資料集，省去格式轉換的前處理階段。
下一步
Taiwan Health MCP 目前已在 GitHub 開源。如果你是：
- 臨床醫師或護理師，有具體的「這個流程用 AI 能省多少時間」的場景想法，歡迎開 Issue 描述
- 醫療 IT 工程師，正在評估 FHIR R4 整合方案，可以直接 fork 測試
- 研究人員，需要標準化的 FHIR 資料存取介面，可以從 FHIR Conversion Service 開始
醫療數據的互通不是靠一個平台就能解決的事。Taiwan Health MCP 是一個技術起點，但真正能讓這些標準在臨床現場運作的，是來自醫療現場的具體需求與回饋。
討論區 (0 則留言)