用 LLM 把結構化臨床資料自動轉 HL7 FHIR：論文精讀與我的 H100 / LiteLLM /

這頁分兩半。上半是把 arXiv 2507.03067 精讀下來，下半是用我手上的資源（H100、LiteLLM、vLLM、Gemma、GPT）評估這條 pipeline 在我院內能不能落地、怎麼落地。

一、論文精讀

論文：Large Language Models for Automating Structured Clinical Data Standardization: HL7 FHIR Use Case
作者：Álvaro Riquelme Tornel、Pedro Costa del Amo、Catalina Martínez Costa（Universidad de Murcia，西班牙），發表於 JAMIA
程式碼與資料：GitHub alvumu/dataInteroperabilityLLM，示範資料集 physionet.org/content/mimic-iv-demo/2.2

它要解的問題

醫療語意互通性一直很貴。把結構化臨床資料對映到 FHIR，傳統做法是人工定義欄位對應再寫 ETL，既要懂來源資料模型、又要懂 FHIR 規格，耗時耗人。這篇提出一條半自動 pipeline，用 LLM 加上 RAG（把 FHIR 領域知識檢索進 prompt）來做這件事，並認真評估準確度、可靠度、安全性。

三步 pipeline

flowchart TD
  A[來源臨床表格<br/>MIMIC-IV] --> B[Step 1 資料預處理<br/>篩選欄位，轉成 JSON]
  B --> C[Step 2 情境建構 Context Building]
  subgraph RAG[混合語意檢索]
    C --> D[對每張表 / 每個屬性群做 embedding]
    E[45 個 HL7 FHIR 資源<br/>官方文件描述] --> F[FHIR 資源 embedding 語料庫]
    D --> G[TFIDF + BM25 + USE + Word2Vec<br/>各自排名，用 RRF 融合]
    F --> G
    G --> H[挑出最相近的 FHIR 資源候選]
  end
  H --> I[Step 3 LLM 互動]
  I --> J[prompt = 檢索到的 FHIR 情境 + 來源表資訊<br/>指示 LLM 把每個欄位對映到 FHIR 屬性]
  J --> K[strict JSON schema + function calling<br/>temperature=0, top_p=0 自我校驗]
  K --> L[輸出：欄位到 FHIR 屬性的對映 JSON]

三步是：Step 1 資料預處理（把表轉成好懂的 JSON）、Step 2 情境建構（用 embedding 加混合檢索，從 45 個 FHIR 資源裡挑出最相近的當上下文）、Step 3 LLM 互動（讓模型依嚴格 JSON schema 把每個欄位對映到 FHIR 屬性）。

幾個技術重點：

檢索不是單一 embedding，而是混合：TFIDF、BM25、Universal Sentence Encoder、Word2Vec 各自排名，再用 Reciprocal Rank Fusion（RRF）融合。純詞頻 embedding 效果不好，混合才行。
LLM 端靠 OpenAI 的 structuredoutput（強制 JSON 格式）加 functions 參數（把 FHIR 資源當成 JSON schema 餵進去）、`functioncall="auto"`，並設 temperature=0、top_p=0 壓掉隨機性。這個「嚴格機器可讀的 schema」是可靠度的關鍵。
試了四種 prompt 策略：Self-Reflexive、Mixture of Prompts（MoP）、5 Serial Schema、5 Serial NoSchema。GPT-4o 在 Reflexive Prompt 最好，Llama 在 MoP 最好。

兩個情境與數字

情境一 baseline（資料有良好封裝與上下文）：17 張表、183 個屬性篩到 119 個可對映屬性。

資源層辨識（table 對到正確 FHIR 資源）：100%
屬性層對映準確度：GPT-4o 的 95% 信賴區間約 67.02 到 73.88%（Reflexive Prompt），明顯贏 Llama 3.2 405b 的 43.79 到 52.98%（MoP）

情境二 real world（模擬真實資料商：單一張 68 欄的表、欄位順序打亂、沒有表層 metadata、只有欄位描述與代表值）：

因為沒有表層上下文，改用非監督 clustering 把相關欄位分群（試了 KMeans、Agglomerative、DBSCAN、BIRCH、OPTICS、Spectral，用 Silhouette / Calinski-Harabasz / Davies-Bouldin 挑最佳）
一般 embedding 資源辨識 87.9%；換上醫療專用 embedding（pubmedbert-base-embeddings、MedEmbed-large-v0.1、ClinicalBERT、biobert-v1.1）後拉到 94%
溫度測試：GPT-4o 在 t=0.5 最高約 68.8%，且跨溫度都穩（信賴區間窄）；Llama 在 t=0 最高約 56.1%，溫度一升就掉。GPT-4o 明顯比較穩、可重現性高

一句話：清楚的機器可讀上下文（JSON schema）加語意 clustering 大幅收窄信賴區間、降低對映歧義；GPT-4o 全面且穩定地贏過 Llama 3.2 405b。

錯誤類型與安全

錯誤來源：來源欄位描述不完整會導致對映不一致；偶發 hallucination（給出看似合理但錯的對映）；granularity 不匹配（顆粒度對不上）。
安全與倫理：他們用的是透過 Azure 的 OpenAI API，並明確設定不讓對話被拿去訓練，符合 PhysioNet 對 MIMIC 的責任使用規範。MIMIC 本身要通過訓練認證才拿得到。
未來工作：在 FHIR 語料上 fine-tune、延伸到 OMOP / OpenEHR / HL7 CDA、處理非結構化敘述、做互動式驗證 UI，以及 benchmark 開源 LLM 以提升在真實臨床環境的可及性與可客製化。最後這點正是我要切入的縫。

二、用我的資源做可行性評估

先講最重要的判斷：這條 pipeline 對我來說可行性高，但決定成敗的不是省錢，是合規。論文用雲端 GPT-4o 跑去識別化的 MIMIC 沒問題，但我院內要動的是真實 PHI，那不能送 OpenAI。所以本地推論不是「比較便宜的選項」，是「唯一合法的選項」。我的 H100 加 vLLM 加 Gemma 這組，剛好就是為這件事準備的。下面逐一對到我的資源。

逐項對映

H100（本地算力）：這條 pipeline 的重擔其實不在 LLM，而在 embedding 與檢索。醫療專用 embedding（pubmedbert、biobert、ClinicalBERT、MedEmbed）都是 BERT 等級的小模型，H100 跑起來輕鬆，而且這一整段全本地、PHI 不出院區。這是準確度最大的槓桿（87.9% 到 94% 就是靠它），又剛好是最容易本地化的部分。clustering 用 sklearn 在 CPU 上跑就好，成本可忽略。
vLLM + Gemma（本地 LLM 推論）：Step 3 的 LLM 互動改用 vLLM 服務 Gemma（例如 Gemma 2 27B 或 Gemma 3 27B），讓所有病人資料留在本地。單張 H100 80GB 服務一顆 27B 模型（fp16 或量化）加上 embedding 模型，容量是夠的。要注意的是別去追 405b 等級的本地模型，單張 H100 放不下，也不需要——策略是靠強檢索加嚴格 schema 把 LLM 的工作縮小到「從前五個候選裡挑對的」，這是比開放生成簡單很多的任務。
LiteLLM（統一閘道）：這是把整套接起來的關鍵。LiteLLM 給我一個 OpenAI 相容的統一端點，前面掛 GPT（API）、後面掛 vLLM 的 Gemma，pipeline 程式碼不用改就能切換模型。實務路線是：先用 GPT-4o 對 mimic-iv-demo 這種去識別化 / 示範資料把 pipeline 跑通、當準確度天花板的參考；真實 PHI 上線時把後端切到本地 Gemma，程式碼一行不動。
GPT（雲端）：只用在去識別化或示範資料的原型與 benchmark 對照組，當「準確度上限」的標尺。真實院內資料一律不走這條。

兩個綠燈與一個要先量的風險

綠燈一，檢索那半段可以直接搬、而且全本地。混合檢索（TFIDF / BM25 加語意 embedding，RRF 融合）加醫療專用 embedding，不依賴任何 GPT，H100 就能跑，還是準確度的主要來源。

綠燈二，structured output 這條命脈可以在本地復刻。論文的可靠度很大一部分來自強制 JSON schema 加 function calling。vLLM 支援 guided decoding（xgrammar / outlines），可以對 Gemma 的輸出強制套 JSON schema，不必依賴模型原生的 function calling。所以「嚴格機器可讀輸出」這件事本地做得到。

要先量的風險，Gemma 對 GPT-4o 的準確度差距。論文顯示 GPT-4o 明顯贏 Llama 3.2 405b，而 Gemma 27B 又比 405b 小很多，所以本地開源模型很可能落在更低的準確度。這不是致命傷，但一定要先量化。降風險的手段：一是靠強 embedding 加緊緻 clustering，把 LLM 的任務壓成「在前五候選裡選」；二是 vLLM guided decoding 鎖 JSON；三是 Reflexive prompting；四是這任務本來就受限（只對映到 45 個 FHIR 資源），不是自由生成。

落地建議步驟

先 clone alvumu/dataInteroperabilityLLM，拿 mimic-iv-demo 2.2 把論文的 baseline 在本機重現一次，確認我理解每一步。
在 H100 上把醫療專用 embedding（pubmedbert / biobert / ClinicalBERT / MedEmbed）與混合檢索（RRF）跑起來，先復現「資源辨識」那段，這段跟 LLM 無關、風險最低。
用 LiteLLM 把 GPT-4o 接上跑屬性層對映，得到我的準確度上限基準。
用 vLLM 服務 Gemma 27B、開 guided decoding 鎖 JSON schema，同一批 demo 資料跑一次，直接量 Gemma 對 GPT-4o 的差距。這一步就回答了整個可行性最大的未知。
若差距可接受，把後端經 LiteLLM 切成本地 Gemma，才拿院內去識別化資料做小規模試點；全程 PHI 不出院區。
缺口若在準確度，再考慮論文提的 fine-tune on FHIR corpora，或先做論文未來工作提到的「互動式專家驗證 UI」把人放回迴圈，讓半自動先安全上線。

我的備註

這篇的價值不只是它做了什麼，而是它的未來工作欄直接點名「benchmark 開源 LLM 以提升真實臨床環境的可及性」——那正好是我有 H100 加 vLLM 加 Gemma、又有真實醫院場域可以做的事。論文用雲端 GPT 證明了可行性，但沒解「PHI 不能出院」這題；我這邊的貢獻縫就在把同一條 pipeline 做成完全本地、可合規落地的版本。這跟我一貫的 human-in-the-loop 立場也一致：對映先半自動、專家驗證留在迴圈，別讓模型直接寫進正式資料。