前言
在軟體工程中，只要 JSON 語法無誤，一般 API 就能順利序列化與反序列化。但在醫療資訊交換（Interoperability）的領域，語法合規（Syntactically Valid）僅僅是及格線，語意合規（Semantically Valid）與結構約束（Profile Conformance） 才是跨系統資料交換不破局的關鍵。

一、認識 FHIR Validation 階層
在 FHIR 規格中，資料驗證主要分為三個由淺入深的層次：

1. 結構與型別檢核 (Structural / Schema Validation)

   • JSON 語法格式無誤
   • 欄位型別吻合 (例如: birthDate 為 YYYY-MM-DD 字串)
   • 必填欄位 (如: resourceType, status) 存在

2. 語意與代碼綁定檢核 (Terminology / ValueSet Binding)

   • CodeSystem URI 正確性 (例如: LOINC, SNOMED CT)
   • 代碼是否存在於指定的 ValueSet 內 (例如: 性別代碼)

3. 實作指引約束 (Profile & Invariant Constraints)

   • FHIRPath 限制式 (例如: 收縮壓必須大於舒張壓)
   • 區域化延伸欄位要求 (例如: TW Core 要求身分證檢核碼)
     二、利用 HAPI FHIR 原生 $validate 端點
     在 Day 5 我們使用 Docker 架設的 HAPI FHIR JPA Server，原生就內建了強大的驗證操作端點——$validate。

4. HTTP 驗證請求語法
   你不需要真正將資料寫入資料庫，只需將欲檢測的 Resource 透過 POST 送至 /[ResourceType]/$validate：

5. 解析 OperationOutcome 回應
   伺服器不會回傳 201 Created，而是回傳一個標準的 OperationOutcome Resource。
   在上述範例中，因為我們刻意省略了必填的 subject（受測病患），HAPI FHIR 會明確指出違規位置：
   -severity：問題嚴重等級（fatal、error、warning、information）。
   -location：違規的 JSON 屬性路徑。
   -details.text：具體違規原因（例如：基數不足、型態錯誤、代碼未定義）。

三、在 Node.js 中實作 Validation 守門員服務
為了避免每次驗證都要額外發出 HTTP 請求打到外部 Server，我們可以在 Node.js 內部建立雙層驗證策略：
1.第一層（本機極速檢驗）： 使用輕量級的 JSON Schema 檢核核心欄位與型態。
2.第二層（深度語意檢驗）： 調用 HAPI FHIR 的 $validate 引擎進行完整 Profile 與 Terminology 驗證。

建立 src/services/fhir-validator.service.ts：
四、中介軟體整合：自動攔截非法 Resource
我們可以將驗證器實作成 Express Middleware，應用在對外發布或資料轉出的路由上：
五、自動化測試：CI/CD 階段的品質防線
在撰寫轉接器（如 FhirObservationAdapter）時，除了驗證自己定義的單元測試，更應在測試流程中將轉換後的物件直接送入 Validator 驗證。

建立 tests/integration/fhir-validation.spec.ts：
當團隊修改了 Adapter 邏輯或新增欄位時，只要執行 npm test，就能在編譯與整合測試階段即時揪出「漏帶屬性」、「無效 URI」或「不符合規範的單位」等語意錯誤，避免上線後產生資料污染。

小結
今天我們建立了確保醫療資料嚴謹性的核心防線：
1.掌握了 FHIR 三層驗證階層（結構、代碼綁定與實作指引約束）。
2.學會運用 HAPI FHIR 的標準 $validate 操作端點 與 OperationOutcome 診斷報告。
3.實作了可整合於 Express 與 CI/CD 自動化測試管線的 FhirValidatorService，在資料送出前完成 100% 規格防呆。

資料合規性經過嚴格檢驗後，明天 Day 21 我們將完成模組三的最終篇章：跨系統交換實作——匯出標準 FHIR Bundle 提供第三方與電子病歷交換中心調閱！