鐵人檔案
醫療資料通過 JSON、FHIR 或 TW Core 驗證，不代表一定符合交換雙方的實際要求。本系列將以 Java、Spring Boot 與 HAPI FHIR，逐步實作一套輕量資料品質閘門，檢查跨 Resource 關聯、契約允許的 LOINC／UCUM 條件與版本差異，並透過自動化測試、Docker 與 CI 建立可重現的驗證流程。
摘要Day 10 已完成第四條交換契約規則 LAB-CODE-001，確認 Observation.code 是否包含合作方允許的 LOINC coding。...
摘要Day 11 已完成第五條交換契約規則 LAB-UNIT-001，確認 Quantity 檢驗結果是否具有可讀的 valueQuantity.unit。D...
摘要Day 12 已完成第六條核心交換契約規則 LAB-UNIT-002，六條規則都已能獨立測試。Day 13 接著把這六條規則接回 Bundle 解析流程與...
摘要Day 13 已經把六條交換契約規則接回 Bundle 解析流程與首頁結果頁，使用者可以在同一個畫面看到 JSON、FHIR R4、TW Core、交換契...
摘要Day 14 已經把契約 v1.0 / v1.1 的基本比較骨架接起來，證明同一份 Bundle 可以因為 v1.1 新增 UCUM system/cod...
摘要Day 15 已經把契約 v1.0 / v1.1 的代表案例整理成最小情境測試包，證明 Expected / Actual 結果可以穩定重跑。Day 16...
摘要Day 15 已經把代表案例整理成 Expected / Actual 測試，Day 16 已經把契約 v1.0 / v1.1 的基本比較結果接回畫面。D...
摘要Day 17 已經把契約 v1.0 / v1.1 的差異轉成可修正的證據。Day 18 把目前的資料品質閘門放進可重現的執行環境：新增 Dockerfil...
摘要Day 18 已經把驗證流程放進 Docker 與 CI quality gate。Day 19 把既有規則測試、分層驗證測試、情境測試與版本比較測試整理...
摘要Day 19 已經把 Quality Test Report、規則覆蓋矩陣與契約版本比較整理成可閱讀證據。Day 20 回頭處理一個更根本的問題：交換契約...
