健保規則不是需求單：HIS QA 如何拆出生效日、欄位與退補件測試

1. 先判斷文件身分，再決定 QA 要做什麼

政策文件的第一個測試條件不是欄位，而是法律與作業狀態。預告草案代表規則可能改動；正式發布確認內容；生效日才回答系統何時必須切換。把三者混在同一張需求單，QA 會過早鎖定未定案規格，或在正式上線時仍拿舊版本驗收。

建立政策追蹤單時，至少記錄文件類型、發文字號、發布日、生效日、適用院所、就醫類別、費用年月與附件版本。來源頁面後來更新時，也要保留當次測試所依據的檔案或雜湊，否則退件後很難重建當時判斷。

QA 不負責解釋法規效力，但必須把未確認事項寫成阻擋條件。生效基準、適用範圍或附件版本未定，就不能假裝已有穩定的 expected result。

2. 政策句子必須落到六類可觀測變化

真正可測的不是「配合新制」，而是某個角色在特定日期輸入資料後，哪些欄位、代碼、狀態、金額、申報內容與報表會改變。影響矩陣應把一條政策拆成前台操作、服務邏輯、資料模型、外部交換、批價申報與稽核報表六層。

例如支付項目新增適應症，可能同時牽動醫令搜尋、適用條件提示、費用計算、申報代碼、病歷佐證與退件訊息。只測畫面能選到新代碼，不能證明申報會被正確接受。

矩陣的每一格都要能指向 owner、程式或設定位置、輸入資料與驗收證據。找不到 owner 或觀測點，本身就是上線風險。

• 角色：醫師、護理、批價、申報、病歷、財務與管理者誰會看到差異。
• 資料：新增或改動哪些欄位、代碼、值域、預設值與必填條件。
• 流程：建立、儲存、取消、重開、轉科、出院、補申報與重送如何走。
• 輸出：畫面、API、交換檔、申報檔、錯誤碼、清單與統計報表是否一致。

3. 部署日不是規則日，版本切換要看業務日期

最危險的實作是把新規則綁在程式發布時間。政策通常指定一個業務生效基準，系統必須在同一套程式中同時處理新舊案件；晚到的舊案、回溯修正與補申報，不會因為版本已部署就自動變成新制。

需求評審應明確回答：選版欄位是哪一個、時區如何處理、跨午夜怎麼判斷、批次重跑採原始日期或處理日期，以及歷史資料重算時能否重現舊規則。這些問題若留到測試階段才發現，通常已經不是補一個案例可以解決。

資料庫與 API 最好回傳實際採用的規則版本或判定依據，讓 QA 能直接比對。若系統只吐出最終金額，錯誤發生時很難分辨是條件判斷、版本選擇還是計價公式出問題。

4. 一個可重跑的雙版本測試包，應長成什麼樣子

以下是示意案例，不對應任何真實健保代碼或支付點數。它的用途是示範如何把生效條件、規則版本與非直線流程寫進同一組測試資料，而不是提供申報依據。

5. 沒有來源版本、雙軌結果與回滾路徑，就不該放行

政策上線不是測試案例全部變綠就結束。發布包應同時保存官方來源、院內判讀、影響矩陣、規則版本、測試資料、申報差異與核准人；監控則要能看見退件、異常點數、版本命中與人工修正。缺少其中任一項，事故發生時就只能靠人回想。

停止條件要在上線前寫好，例如生效基準仍有爭議、申報輸出無法對應來源規則、舊案重送套錯版本、關鍵錯誤沒有回滾或人工處理路徑。這些不是可延後補文件的行政問題，而是系統是否能安全承接政策的判斷。

最後的決策規則很簡單：QA 能否拿一筆案例，從官方文件一路追到系統選版、畫面結果、申報輸出與核准紀錄；只要其中一段斷掉，就繼續修，不用靠「應該沒問題」放行。

• 來源包：公告網址、附件版本、發文字號、生效日與存檔雜湊。
• 規格包：影響矩陣、欄位對照、規則版本、例外與未決事項。
• 測試包：新舊版本、邊界、取消重開、補申報、退件重送與歷史重算。
• 營運包：監控指標、人工處理方式、回滾條件與責任窗口。