開源揭幕(一)｜Taiwan Health MCP 的誕生：一個被醫療數據逼出來的決定

Key Takeaways

• Taiwan Health MCP 是一套開源的台灣醫療數據整合工具集，共 32 個 MCP 工具，涵蓋 8 個功能領域
• 核心整合範圍：ICD-10 診斷碼（含衛福部中文化資料）、台灣 FDA 藥品資料庫（5 個官方 API）、LOINC 檢驗標準碼（內建 30+ 項，可擴展至 87,000+ 項）、臨床指引、FHIR R4 轉換
• 開源的關鍵原因不是理念，而是工程現實：重複造輪子的成本太高，單一團隊無法維護所有醫療場景的數據準確性
• MCP（Model Context Protocol）讓 Claude、ChatGPT、Gemini 等 AI 不需要自訂 API 包裝層，就能直接存取醫療數據
• 三分鐘快速開始：git clone https://github.com/healthymind-tech/Taiwan-Health-MCP.git && cd Taiwan-Health-MCP && docker-compose up -d

困境先說清楚

開發 DietMate 的第一年，有一段時間我們幾乎每兩週就要重新整理一次醫療數據的接入邏輯。

不是因為產品功能複雜。是因為光是要讓 AI 「知道一個診斷代碼對應什麼意思、對應什麼藥物、對應什麼飲食建議」，就需要同時打通四件事：ICD-10 診斷碼的衛福部中文版本、台灣 FDA 藥品許可證資料庫、LOINC 檢驗標準、以及各醫學會的臨床指引。這四個資料源格式不同、更新頻率不同、API 設計也各自為政。

舉個具體例子：一位有第二型糖尿病（ICD-10 碼 E11.9）的患者來查飲食建議，AI 需要同時參考她的診斷碼、最近的 HbA1c 檢驗值（LOINC 碼 4548-4）、以及她正在服用的降血糖藥物（FDA 許可證查詢）——才能給出安全、個人化的建議。這三個查詢對應三個完全不同的系統，每次都要重寫整合邏輯。

我們的工程師把這個問題記錄下來，當時的原話是：「這不像是在開發 AI 功能，比較像在維護一個分散式資料清洗系統。」

這個困境讓我們意識到兩件事：第一，這不是只有我們遇到的問題。第二，如果每個做醫療 AI 的團隊都自己來一遍，整個業界都在浪費同一批時間。

MCP 協議出現的時機點

2024 年底，Anthropic 發布 Model Context Protocol（MCP）。

MCP 的設計概念本身不複雜：讓 AI 模型透過標準化介面存取外部系統，而不是每次都要為不同的 AI 寫不同的整合程式碼。它的重要性在於開放性——不綁定 Anthropic 自己的 Claude，ChatGPT 和 Gemini 也能使用同一套 MCP Server。

對我們來說，MCP 解決的恰好是那個讓工程師抓狂的問題：如果能把台灣四大醫療數據源全部包裝成 MCP 工具，那麼任何 AI——不管是 Claude、GPT-4 還是自建的 LLM——都能用同一套介面查詢，不需要再寫客製化的 API 包裝層。

把台灣醫療數據做成 MCP 工具集，這個想法從這裡開始成形。

為什麼決定開源，而不是自用

說清楚一點：開源的決定不是因為「社群力量」的信念，是因為一個工程上的判斷。

醫療數據的準確性和即時性，單一團隊維護不了。台灣 FDA 藥品資料庫每個月都有更新。ICD-10 有地區版本差異。LOINC 的中文對照目前市面上沒有完整版本。臨床指引各醫學會更新時程不同。

如果把這套工具鎖在公司內部，我們就必須包下所有維護責任。但如果開源，醫療專業人士可以直接貢獻驗證過的數據，開發者可以回報 Bug，架構問題會有更多眼睛盯著看。

這是一個降低長期維護風險的決策，不只是理念表態。

32 個工具的全貌

Taiwan Health MCP 目前共 32 個工具，分佈在 8 個功能領域：

這 32 個工具的設計原則是：查詢結果可追蹤、來源明確。每個回傳值都附帶數據來源（哪個官方資料庫、哪個版本），而不是讓 AI 自行推論出一個無法驗證的答案。

FHIR R4 轉換模組是為了與醫院資訊系統對接設計的。衛福部已將 FHIR R4 列為電子病歷交換的國家標準，Taiwan Health MCP 的轉換模組讓 AI 查詢到的資料可以直接以 FHIR 格式輸出，銜接現有的醫院系統，不需要再做格式轉換。

實際查詢長什麼樣子

以 ChatGPT 或 Claude 接上 Taiwan Health MCP 後，一個典型的醫療查詢場景：

醫師問 AI：「這位患者診斷是 E11.9，HbA1c 是 8.2%，目前用 Metformin，有沒有飲食上需要特別注意的？」

AI 在背後自動做了三件事：

1. 用 ICD-10 工具查 E11.9 的臨床意義與常見併發症
2. 用 LOINC 工具確認 HbA1c 數值（LOINC 4548-4）對應的參考範圍，判斷控制狀態
3. 用 FDA 藥品工具查 Metformin 的飲食交互注意事項

這三個查詢過去需要工程師各自整合三個不同的 API，現在 AI 直接透過 MCP 協議在一次對話裡完成。不需要複雜的後端邏輯，也不需要人工跳轉查詢。

三分鐘快速開始

git clone https://github.com/healthymind-tech/Taiwan-Health-MCP.git
cd Taiwan-Health-MCP
docker-compose up -d

服務啟動後跑在 localhost:8000。以下是一個最基本的 Python 查詢範例：

from src.icd_service import ICDService

icd = ICDService('data/icd.xlsx', 'data')
result = icd.search_codes("糖尿病", type="diagnosis")
print(result)
# 輸出：[{'code': 'E11.9', 'name': '第二型糖尿病，不伴有併發症', 'source': '衛福部ICD-10-CM 2024版'}]

要把 Taiwan Health MCP 接上 Claude Desktop 或 Cursor，在設定檔加入：

{
  "mcpServers": {
    "taiwan-health-mcp": {
      "command": "node",
      "args": ["path/to/Taiwan-Health-MCP/index.js"],
      "env": {}
    }
  }
}

完整文件、架構說明與更多範例：GitHub Repository | 快速開始指南

需要哪些類型的貢獻

目前最缺的不是功能開發，而是數據驗證。

醫療數據的錯誤成本很高。ICD-10 中文對照如果有誤，AI 給出的診斷解釋就會跑掉。LOINC 參考值範圍如果沒有台灣本地化，判讀就可能失準。這些都需要有臨床背景的人來審。

具體的貢獻方向：

• 醫療專業人士：驗證診斷碼、藥品資訊、臨床指引的醫療準確性，補充 LOINC 中文對照
• 開發者：新增功能、撰寫測試、優化效能、回報 Bug
• 醫療資訊工程：整合更多官方資料源、優化資料管道、擴充 FHIR 轉換模組

Pull Request 開放中。Issue 也歡迎提——不管是 Bug、功能請求還是數據錯誤，都算有價值的貢獻。

如果對這個專案有疑問或合作想法，可以透過 GitHub Issues 或官方網站聯繫我們。DietMate 的應用場景可以參考產品頁面。

Taiwan Health MCP 使用 MIT 授權，可自由商用、修改與再發布。MCP 協議本身是開放標準，與 AI 廠商無關——不管你用 Claude、ChatGPT、Gemini 還是自建模型，都能使用。

相關文章：Taiwan Health MCP 完整入門指南 · Taiwan Health MCP 線上版使用指南 · 開源揭幕(二)｜FHIR R4 在台灣醫療的實際落地