前言
在綜合醫院病房中，如果走進護理站或翻開病歷夾，最醒目的圖表通常是俗稱「三折單」或「體溫單」的 TPR Sheet（Temperature, Pulse, Respiration Sheet）。

這張圖表按固定時間頻率（通常為每日 4 次：02:00、08:00、14:00、20:00，或依醫囑改為 Q4H、Q2H）繪製病患的體溫紅線、脈搏藍點、呼吸次數與出入量（I/O）。醫師查房時，往往一眼掃過 TPR 曲線，就能迅速判斷病患是否有感染高峰、心律失常或抗生素療效不彰的跡象。

在將紙本 TPR 轉化為數位化資料流時，軟體工程面臨兩大核心挑戰：
1.臨床數值防呆（Sanity & Plausibility Checks）： 護理人員在高壓環境下常有鍵盤按錯鍵的物理失誤（例如將 37.2 打成 372，或呼吸次數漏打直接送出 0）。
2.時序對齊與插值容差（Time-slot Alignment）： 臨床常規要求 08:00 記錄晨間體徵，但護理師巡視 20 間病房量測完畢時，實際時間可能是 08:35。系統如何將帶有微小偏差的物理時間歸整至標準臨床時段？

今天我們將實作生命徵象收集引擎的時序資料結構定義與多層防呆驗證管線（Validation Pipeline）。

一、臨床數值驗證的分級哲學
在醫療系統中，資料防呆不能單純採用「非黑即白」的阻斷式驗證（Hard Rejection）。臨床數值通常分為三種邊界：

如果系統將 40.2°C 的敗血症高燒直接當成錯誤阻擋，將導致護理師無法記錄真實危急病況；反之，若系統完全不攔截 370°C，將直接污染病歷庫甚至引發錯誤投藥。

二、TypeScript 驗證管線實作
我們採用兼具型別安全與防護彈性的驗證引擎。以下在 Node.js (TypeScript) 中建立檢驗規格與自訂驗證函式：

1. 介面與常數定義 (src/types/vital-signs.ts)
   
2. 多層防呆檢驗器 (src/validators/vital-signs.validator.ts)
   
   三、臨床時序歸整（Time-slot Binning）演算法
   在繪製體溫單時，若按真實秒數分散擺放，圖表橫軸會破碎不堪。因此，系統需提供演算法將量測時間映射至最接近的臨床班別區間（02, 06, 10, 14, 18, 22 或 08, 16, 24）。
   四、Express API 串接與錯誤處理規範
   在後端控制器（Controller）中，我們依據驗證結果實施兩種不同的 HTTP 回應策略：
   1.若含有 CRITICAL_ERROR： 回傳 422 Unprocessable Entity，直接終止資料庫寫入，並將所有錯誤欄位陣列回傳給前端高亮顯示。
   2.若僅有 CLINICAL_WARNING：
   -前端首次送出時，若 Header 未附帶 X-Clinical-Override: true，後端回傳 409 Conflict 與警告描述，要求護理師在介面上點擊「確認數據無誤，強制送出」。
   -前端再次帶上 X-Clinical-Override: true 時，後端將數值寫入資料庫，並在 vital_signs.is_abnormal 標記為 true。
   

小結
今天我們完成了臨床時序體徵收集的核心邏輯：
1.建立了物理極限（直接攔截）與臨床異常（二次確認）的分級防禦哲學。
2.實作了涵蓋體溫、心跳、呼吸、血壓差、血氧的 TypeScript 驗證引擎。
3.實作了將零散量測對齊至固定時段的時序槽位歸整演算法（Time-slot Binning）。
4.規範了利用 HTTP 狀態碼（422 vs 409）配合前端跳出確認框的互動模式。

確保了體徵數據的精準無誤後，明天 Day 12 我們將推進至病房最具風險的環節：醫囑流轉實務——剖析 MedicationRequest 資料結構與給藥頻率排程演算法！