前言
在醫療資訊系統的所有業務模組中，給藥核對（Medication Administration Checking） 是安全防線的最前線，也是系統設計容錯率最低的環節。

在傳統紙本或無條碼輔助的病房中，給藥錯誤（Medication Errors）往往名列不良事件前茅——給錯病人、拿錯藥物劑量、打錯給藥時間或看錯途徑。即使護理常規明訂必須落實「三讀五對」，但當護理師面對連續值班疲勞、環境噪音干擾，或是病房突發急救時，純靠肉眼核對極易產生認知盲區。

為此，現代行動護理資訊系統（NIS）導入了 BCMA（Barcode Medication Administration，條碼給藥核對系統）。今天我們將以工程視角，將護理專業的「三讀五對」轉化為嚴謹的狀態機（Finite State Machine, FSM）與防錯資料流，並使用 TypeScript 實作核對引擎。

一、BCMA 臨床操作時序與狀態機設計
給藥不是單純打一支 API 將資料存入資料庫，而是一連串具備先後依賴關係的狀態轉換序列。

如果在未確認病人身分前就直接掃描藥包，或者在藥物未完全核對通過前就按下「確認給藥」，系統必須在邏輯層直接拒絕狀態轉移。

狀態流轉規則：
1.嚴格單向依賴： 必須先鎖定 Patient，才能進入該病患的未執行醫囑比對；
2.多重驗證原子性： 藥物、劑量、途徑、時間四項條件只要有一項檢核失敗，不得進入下一個階段；
3.核對失敗軌跡留存（Exception Audit）： 任何掃描條碼不符的情境（例如拿了隔壁床病人的藥物），系統必須以非同步方式記錄事件 log，供護理部進行品質監控與根因分析（RCA）。

二、三讀五對驗證引擎實作
我們在後端建立專門的檢核引擎 BcmaVerificationEngine，負責驗證請求是否完全滿足臨床五對原則。

1. 介面定義 (src/types/bcma.ts)
2. 核心檢核邏輯 (src/services/bcma-engine.service.ts)

三、執行完成：產生 MedicationAdministration Resource
當五對核對通過且護理師確認給藥後，後端除了在內部資料表標記完成，還必須產生 HL7 FHIR 的給藥紀錄 Resource——MedicationAdministration。

它記錄了「哪一位護理師（Performer），在什麼時間（EffectiveTime），將哪種藥劑（Medication）真正施打入病患體內（Subject）」，並回溯引用原始處方（request）：

四、臨床特殊情境防呆與例外覆蓋（Override）
在真實給藥情境中，往往存在非系統所能預測的臨床例外：
-病患拒絕服藥（Refusal）： 病患因噁心嘔吐或個人意願拒服。
-病患暫時禁食（NPO）： 準備接受內視鏡檢查或手術。
-緊急時間偏移： 急診或急救時醫師口頭指示提早給予。
面對這些情況，系統絕不能因為核對失敗就卡死。必須提供「例外紀錄與理由註記（Reason Code）」機制：
1.允許護理師點選「未給藥（Not Done）」，並在下拉選單強制選取原因（如：NPO、Patient Refused、Condition Changed）。
2.在 FHIR MedicationAdministration 中，狀態將轉為 status: "not-done"，並填寫 statusReason 欄位，確保法律紀錄完整無缺。

小結
今天我們完成了臨床護理中最嚴密的安全架構：
1.設計了 BCMA 條碼給藥的有限狀態機（FSM），規範了嚴格的依序解鎖流程。
2.以 TypeScript 實作了「五對原則」驗證引擎，精確防堵人、藥、量、途徑、時間的偏差。
3.掌握了給藥完成時產生的標準 MedicationAdministration Resource 結構。

至此，模組二：護理資訊系統（NIS）業務與資料塑模 已全數完工！我們已經掌握了床位管理、時序體徵驗證、醫囑排程與條碼給藥防錯的完整領域模型。
明天 Day 14，我們將正式進入 模組三：後端 API 開發與 FHIR 整合實戰，開始用 Node.js / Express / TypeScript 搭建 API 骨架、配置 JWT 醫護認證與 Role-Based 權限機制！