本模組對應《衛生福利部 支付審核系統 API 規格說明書（照管平台）v2.2.1》，將長照服務提供單位（含系統商）與衛生福利部支付審核系統（以下簡稱支審系統）之間的申報與審查介接，以 HL7 FHIR R4.0.1 標準重新表達，供實作者以 FHIR 資源進行支付審查相關的資料交換。

本模組的設計原則比照臺灣健保事前審查實作指引（TWPAS）的作法，採「先建邏輯模型、再對應 FHIR 資源」的兩階段路徑：

1. 邏輯模型（Logical Model）階段：將既有 API 規格書中以 JSON 電文定義的 Schema（apply_info、case_svc_records、查詢 A／查詢 B 之回覆明細等），逐欄轉為 FHIR Logical Model，保留規格書原有的中文欄位名稱、英文欄位名稱、型態、長度與必填規則，讓熟悉原規格書的實作者可直接對照閱讀。
2. FHIR 對應（Mapping）階段：在每個邏輯模型上掛載 Mapping，指出各欄位實際落到哪一個 Profile 的哪一個 element；再以 Bundle 打包申報交易、以 ClaimResponse 與 Task 表達審查回覆與交易處理結果。

採用此路徑的理由是：支審系統的電文結構是既成事實，短期內不會為了 FHIR 而改動；邏輯模型讓「規格書欄位」與「FHIR element」之間保有一層可追溯的對照，既不必扭曲原規格書的欄位語意，也不必在 FHIR 端新增大量非標準的 Extension。實作者可先以邏輯模型確認資料齊備，再依 Mapping 頁籤將資料落入對應 Profile。

本模組於申報端（Claim、Task）的所有識別碼（服務紀錄識別碼 objid、交易序號 trans_no、支審年月 writeoff_yyyymm、核銷案號 case_no、總表版次 doc_ver、簽證編號 acc_num）一律以 identifier 的具名切片（slice）承載，並以 identifier.system 區分，不另行新增 Extension。審查回覆端（ClaimResponse）因 ClaimResponse.item、error、addItem 三個 BackboneElement 於 FHIR R4 均無 identifier 元素，其逐筆服務記錄之識別資訊須以 Extension 承載，詳見下方「設計決策說明」第五節。

規格書共定義七支 API，依業務流程可分為三個階段：申報（FeeApply、ObjDel、appCompletionNotice）、查詢（查詢 A、查詢 B） 與 異動（appCancel、CancelResultResponse）。

1. 申報服務紀錄：服務提供單位於同一支審年月內可多次執行 FeeApply，每個交易序號每次最多申報 5,000 筆個案服務紀錄。每筆服務紀錄具唯一識別碼（objid）；識別碼不存在時於支審系統新增，已存在時則更新。
2. 刪除誤申報之服務紀錄：以 ObjDel 針對 objid 刪除。
3. 申報確認通知：服務紀錄確認無誤後執行 appCompletionNotice，依案件編號通知縣市承辦人員收件審查。執行後支審系統不再受理該案件之服務紀錄申報及異動。
4. 查詢分案審核狀態（查詢 A）：取得該申報年月各分案之核銷案號、核銷狀況、總表版次、簽證編號，以及各交易單的 API 執行結果（含分案異常資料、服務紀錄刪除成功／失敗資料）。每次查詢間隔至少 20 分鐘。
5. 查詢分案審核明細（查詢 B）：須先執行查詢 A 取得核銷案號、核銷狀況與總表版次；僅在核銷案號為新案號，或核銷狀況、總表版次有異動時才執行查詢 B，取得核定金額、審核通過／錯誤服務記錄、A 碼加成資料與各式清冊下載路徑。
6. 撤回服務紀錄：以 appCancel 撤回本月該來源系統別所申報之服務紀錄；未傳入縣市代碼與核銷案號時為整月全撤，傳入時則限定該核銷案號。承辦人已收件處理者不允許撤回。
7. 取消交易單處理結果回報：以 CancelResultResponse 取消查詢 A 之 API 執行結果資料中某一交易單的處理結果回報。

七支 API 共用的傳輸封套（unitNo、requestDt、sourceSystem、apdata、checksum）與回覆封套（rtncode、responseDt、errmsg、result、checksum、rtnSeq）屬傳輸層機制，於本 IG 中不另建 FHIR 資源表達；rtncode 之取值另建 支付審查－API 回覆結果代碼，供實作者於傳輸層對照使用。

本模組以三個層級對應規格書的三種粒度：

• Bundle ＝ 一次申報交易（trans_no）：規格書明訂「每個交易序號每次申報最多 5000 筆個案服務紀錄」，交易序號即是一次申報的批次邊界，也是後續查詢 A 之 API 執行結果、撤回與取消結果回報所依據的單位。FHIR 中最貼近「一次傳輸的資料集合」語意的是 Bundle，故以 LTCBundleFeeApply 承載一次申報交易，並將 trans_no 放在 Bundle.identifier。records（服務記錄筆數）與 cases（申請個案數）為統計值，可由 Bundle 內 Claim 的筆數推得，不另設欄位以避免資料重複與不一致。
• Claim ＝ 一筆服務紀錄（objid）：規格書規定「每筆服務記錄有唯一的識別碼（objid）」，且申報之識別碼不存在時新增、已存在時更新，objid 即是可獨立新增、更新與刪除的最小業務單元。FHIR 的 Claim 正是「向給付方請求費用」的請求資源，一筆服務紀錄即一次請款主張，故以一個 LTCClaimFeeApply 對應一個 objid，並將 Claim.item 收緊為 1..1（一筆服務紀錄僅一個照顧組合代碼）。這樣的粒度使 ObjDel 的刪除、查詢 A 的分案異常回報，以及查詢 B 的逐筆審核結果都能精確指向單一資源。
• ClaimResponse ＝ 一個核銷案號（case_no）：支審系統的審查作業是以「分案」為單位進行，一個核銷案號涵蓋一個縣市對一家服務單位在一個支審年月的所有服務紀錄，並產出單一份總表、單一組核定金額與清冊。查詢 B 的回覆明細正是以核銷案號為主鍵。故以一個 LTCClaimResponseFeeAudit 對應一個核銷案號，分案層級金額放在 ClaimResponse.total，逐筆服務紀錄的審核結果放在 ClaimResponse.item 與 ClaimResponse.error。

需留意的是，Claim 與 ClaimResponse 在此並非一對一：一個核銷案號的 ClaimResponse 會回應多筆 Claim。這與 FHIR 規範相容（ClaimResponse 不強制 request 為必填），且忠實反映支審系統「以分案為審查單位」的實際運作。另因 FHIR R4 基底之 ClaimResponse.patient 為 1..1，Profile 不得放寬基數，故一個涵蓋多位個案的分案，須以代表個案填入 patient，實際個案數由 ClaimResponse.item 逐筆表達。

規格書「表1：支付碼必填欄位一覽表」定義了大量隨照顧組合代碼（gov_item_cd）而異的條件必填欄位：申報 AA00 需填服務項目、服務對象、服務內容；申報 AA03 需填服務項目與提供專業服務單位；申報 BD03、DA01 需填出發地、目的地、車號、里程數；申報 C 碼需填專業服務復能目標相關欄位。這些欄位共約 28 項，若逐一建為 Extension，將產生 28 個非標準的結構定義，且每個都只在特定支付碼下有意義。

FHIR 的 Claim.supportingInfo 正是為此設計的元素——其定義即為「支持此次請款所需的額外資訊，內容隨情境而異」，並提供 category（資訊類別）、code（代碼值）與 value[x]（值）三個欄位供結構化承載。採用 supportingInfo 具備下列優點：

• 使用 FHIR 標準元素，不擴充結構定義，跨系統互通性較佳；
• 條件必填規則可透過 category 的代碼系統（支付審查－服務紀錄補充資訊類別）集中管理，新增支付碼時只需擴充 CodeSystem 而不需改動 Profile 結構；
• 原始電文中可複選（以「|」分隔）的欄位如服務項目、服務對象、服務重點，可自然表達為同一 category 的多筆 supportingInfo 實例。

實作注意事項：FHIR R4 的 Claim.supportingInfo.value[x] 型別僅允許 boolean、string、Quantity、Attachment 與 Reference，不含 CodeableConcept。因此代碼型欄位（服務項目、服務對象、服務重點、專業服務復能目標達成情形、BD03 服務使用類型、AA10 申報狀態）一律以 supportingInfo.code 承載並綁定對應 ValueSet，該切片之 value[x] 則收緊為 0..0 以杜絕歧義。文字型欄位則以 valueString、旗標型欄位以 valueBoolean、地點型欄位以 valueReference 承載。

條件必填規則因隨支付碼而異，無法以基數表達，本 IG 改以四條 severity 為 warning 的 invariant（ltc-feeaudit-1 至 ltc-feeaudit-4）提示實作者，涵蓋 BD03／DA01、BD03、AA00 與 AA03 之必填組合。

查詢 B 回覆的「A 碼加成資料區」（a_svc_records）是審查機關於審核後，針對已通過之服務紀錄另行加計的政策鼓勵給付項目（如 AA05），其特徵是：並非由服務提供單位原申報，而是由給付方在審核階段新增的給付項目。

FHIR 的 ClaimResponse.item 定義為「對應原始 Claim 中某一 item 的裁決結果」，必須以 itemSequence 指回原申報項目；而 ClaimResponse.addItem 的定義正是「給付方新增、原請款單中未提出的給付項目」。A 碼加成的語意與 addItem 完全吻合，故以 addItem.productOrService 承載 A 碼（a_gov_item_cd）、addItem.adjudication 承載單價（price），所加成之審核通過服務記錄（ref_objid、ref_source_system）則以 addItem.extension[recordRef] 識別——addItem.itemSequence 於 FHIR R4 的語意是「本服務項目所欲取代之原申請單（Claim）項目序號」，且為 positiveInt，無法承載長度 20 的字串識別碼。

若改用 ClaimResponse.item 表達 A 碼加成，將造成「回應了一筆原申報中不存在的項目」的語意矛盾，且驗證器會期待對應的 Claim item 存在；使用 addItem 則可清楚區分「單位申報的」與「機關加計的」兩類給付，也讓政策鼓勵金額（a_svc_fee）與核定金額（approve_fee）在 ClaimResponse.total 中的分列有據可循。

本模組僅在 FHIR R4 確實缺乏語意相符之標準元素時才新增 Extension，且集中為兩個：

• 服務記錄識別資訊（RecordRef）：承載每一筆服務記錄的識別碼（objid／ref_objid）、來源系統別（source_system）與交易序號（trans_no），掛載於 ClaimResponse.item、ClaimResponse.error 與 ClaimResponse.addItem。
  需要它的原因是：這三個 BackboneElement 於 R4 均無 identifier 元素，唯一可用於指涉的 itemSequence 型別為 positiveInt，且其語意是「指向 ClaimResponse.request 所參照之單一 Claim 內的 item.sequence」。本模組一份 ClaimResponse 涵蓋一個核銷案號下的多筆服務紀錄，每筆各為獨立的 LTCClaimFeeApply 且其 item.sequence 固定為 1，因此 itemSequence 既無法承載長度 20 的字串識別碼，也無法在跨 Claim 的情境下唯一指向任何一筆服務紀錄；改以 processNote 自由文字記載則喪失可運算性。
• 分案審核統計與承辦資訊（AuditSummary）：承載分案層級的統計值（records、cases、approve_case_num、approve_record_count）、暫付申請狀態（temp_payment_status）、分案已處理之單號（trans_nos）與承辦人員（audit_man）。
  需要它的原因是：統計值為整數而 ClaimResponse.total 為 Money 型別；暫付申請狀態不在 ClaimResponse.outcome 的取值範圍；trans_nos 為多筆字串而 ClaimResponse.request 於 R4 為 0..1 Reference；承辦人員是審查機關的審核承辦人，與 ClaimResponse.requestor（R4 定義為「負責本次請款的服務提供方」）語意方向相反，混用會使範例被誤讀為申報單位。

其餘可由現有元素表達者（各項金額、核增／核減原因、錯誤代碼、清冊下載路徑之外的所有欄位）一律不新增 Extension。

本模組中，ObjDel（服務紀錄刪除）、appCompletionNotice（申報確認通知）、appCancel（撤回服務記錄）與 CancelResultResponse（取消交易單處理結果回報）四支 API，以及查詢 A 回覆的 API 執行結果資料（webapi_process_info），一律以 LTCTaskFeeAudit 表達。其中「申報確認通知」一詞容易讓人直覺選用 Communication，但依 FHIR 的 workflow 語意分界，正確選擇是 Task。

FHIR 將 workflow 資源分為 Event 與 Request 兩大類：

• Event（事件）：記錄「已經發生的事」。Communication 屬於 Event 類別，其定義是「資訊已在雙方之間傳遞完成」的既成事實紀錄——它描述某則訊息被送出、被接收，並不預期接收方因此採取任何行動，也沒有對應的狀態機來追蹤後續處理進度。Communication.status 的取值（preparation、in-progress、completed…）描述的是「訊息傳遞本身」的進度，而非「接收方處理該訊息的業務進度」。
• Request（請求）：表達「要求某方去做某事」。Task 是 Request 類別中專門用於表達「待執行之工作項目」的資源，具備 status（任務執行狀態）、businessStatus（業務狀態）、input（執行所需輸入參數）與 output（執行後產出結果）等元素，完整涵蓋一次「請求—執行—回報結果」的生命週期。

支審系統的這四支 API 都不是單純的訊息傳遞，而是要求對方改變系統狀態並回報結果：

• appCompletionNotice 執行後，支審系統必須改變案件狀態，不再受理該案件的服務紀錄申報及異動，並觸發縣市承辦人員進行收件審查；
• ObjDel 要求支審系統實際刪除指定 objid 的服務紀錄，並回報刪除成功清單（delete_records）與刪除失敗清單（delete_exception_records）；
• appCancel 要求支審系統撤回已申報之服務紀錄，且有明確的前置條件（承辦人已收件處理者不允許撤回）；
• CancelResultResponse 要求支審系統取消某一交易單的處理結果回報。

更關鍵的是，規格書本身即為這些操作定義了完整的狀態機——查詢 A 回覆的 API 執行狀態（status：0 待處理、1 處理中、3 錯誤、4 處理完成）與批次處理結果（處理筆數、成功筆數、失敗筆數、異常明細），正是典型的任務執行狀態追蹤，而非訊息傳遞紀錄。這些狀態可直接對應 Task.status 的 requested、in-progress、failed、completed，處理結果則落在 Task.output。

因此，凡「要求系統改變狀態並回報結果」者一律使用 Task；Communication 在本模組中不使用。相對地，各操作所需的輸入參數（縣市代碼、核銷案號、服務紀錄識別碼、所要取消之交易序號）以 Task.input 的具名切片承載，執行結果則以 Task.output 承載，交易序號（trans_no）放在 Task.groupIdentifier，使同一次申報交易的各項處理共用同一識別。

實作限制：Task.input 與 Task.output 於 FHIR R4 為「type（CodeableConcept）+ value[x]」的扁平結構，不支援巢狀 part。因此規格書 appCompletionNotice 之 city_info（縣市代碼底下含多筆案件編號）的巢狀關係，本 IG 改以「一個縣市一筆 Task」表達：input[cityCd] 收緊為 0..1，同一 Task 內的 input[caseNo] 即明確隸屬於該縣市；一次作業涉及多個縣市時，依縣市拆分為多筆 Task 並共用同一 Task.groupIdentifier。另需注意 input／output 的切片 discriminator 為 #pattern + type.text（規格書之中文欄位名稱，如「縣市代碼」、「批次處理結果」），撰寫 FHIRPath 查詢時須以 type.text 定位，本 Profile 未定義 type.coding。

本模組定義三個邏輯模型，逐欄保留規格書之中文欄位名稱、英文欄位名稱、型態、長度與資料描述，並於各模型的「Mappings」頁籤提供至對應 Profile 的欄位對照。

各 Profile 之範例可於該 Profile 頁面的「Examples」頁籤查閱，亦可於本 IG 的 範例 頁面總覽。

• 支審年月（writeoff_yyyymm）為西元年月格式 yyyyMM（例如 201901），非民國年，與本 IG 長照 SDK 模組所使用的民國年月（YYYMM）不同，實作時請特別留意。
• 查詢 B 須先執行查詢 A 取得核銷案號、核銷狀況與總表版次；僅在為新核銷案號，或核銷狀況、總表版次有異動時才可執行查詢 B。查詢 A 每次查詢間隔至少 20 分鐘。
• 案件一旦執行申報確認通知（appCompletionNotice），支審系統即不再受理該案件之服務紀錄申報（FeeApply）與刪除（ObjDel）。
• 本模組之縣市代碼（支付審查－縣市代碼）為支付審查系統之行政區代碼，與 TW Core 之郵遞區號代碼系統用途不同，兩者不可互相替代。
• 下列三組術語為參照用術語，未繫結（bind）於任何 Profile 元素，供實作者於傳輸層或系統整合時對照使用：API 回覆結果代碼（rtncode，屬回覆封套欄位）、API 執行狀況（status，於 FHIR 中已對應至 Task.status 之標準取值，故不另行繫結）、縣市代碼（city_cd，於 FHIR 中係以 Organization.identifier（system 為 http://ltc-ig.fhir.tw/identifier/feeaudit/city-cd）或 Task.input[cityCd] 之字串值表達，非 coded 元素）。
• 各項金額類別代碼中，申請核銷金額（submitted）、自付額（copayment）與單價（price）語意與 HL7 標準代碼系統 http://terminology.hl7.org/CodeSystem/adjudication 之 submitted、copay、eligible 相近；本 IG 為維持同一組金額類別之一致性而收錄於本土代碼系統，相關繫結強度為 extensible，跨國情境交換時得改用標準代碼。
• 傳輸封套之校驗碼（checksum）計算邏輯、Base64 編碼方式與 IP 白名單等傳輸層規範，請逕行參照規格書原文，本 IG 不予規範。