前言
在護理站巡房時，護理師很少「一次只為一位病人上傳一筆體溫」。臨床常見的動線是：推著護理量測推車走入一間雙人或四人病室，連續量測多位病人的生命徵象（體溫、脈搏、血壓、血氧），並在平板端一次勾選或逐床完成批次送出。

如果前端每量測一個項目就呼叫一次 API，在高併發時段會對後端連線池造成極大壓力；若中途斷線，更可能造成資料狀態破碎。

今天我們將實作 即時生命徵象上傳 API。這支 API 具備兩大核心機制：

內部資料庫交易（ACID Transaction）： 一次接收多位病患或多項體徵，在 PostgreSQL 內部確保全數成功或全數回滾（Rollback）。

FHIR Observation 轉接適配器（Adapter）： 將關聯式資料列自動拆解並封裝為符合 LOINC 國際編碼的標準 FHIR Observation Resource 與批次 Transaction Bundle。

一、批次上傳資料流架構
二、型別定義與批次 Payload
建立 src/types/vital-batch.types.ts，支援單一請求帶入多位病人、多筆量測：
三、實作 Observation Adapter（LOINC 轉換核心）
回顧 Day 4 與 Day 10 的策略：一筆包含體溫、心跳與血壓的臨床紀錄，在 FHIR 標準中應拆解為帶有精確 LOINC 代碼的獨立 Observation。

建立 src/adapters/fhir-observation.adapter.ts：

四、資料庫批次交易寫入與 Controller 實作
在 PostgreSQL 中，我們使用 pg 連線池的 Client 開啟 BEGIN ... COMMIT 交易區塊，確保即使第 5 筆量測因外鍵問題出錯，前 4 筆也不會殘留在資料庫中。

建立 src/modules/vitals/vitals.controller.ts：

五、實機測試與驗證
使用 cURL 模擬護理平板發送批次量測請求：
預期回應（201 Created）：

第 1 位病患產生 3 筆 Observation（體溫、心跳、複合血壓），第 2 位病患亦產生 3 筆，合計精準封裝 6 筆標準資源。

小結
今天我們攻克了高頻量測資料流的整合關鍵：
1.實作了基於 PostgreSQL Transaction 的原子性批次寫入，確保臨床資料零遺漏、零碎片。
2.透過 FhirObservationAdapter 將扁平的單筆體徵記錄，依據 LOINC 與 UCUM 規範拆解成符合醫療交換標準的 Observation。
3.打包成 FHIR Transaction Bundle，為後續與外部 HAPI FHIR Server 進行非同步同步備妥載體。

現在我們有了即時且批次寫入的體徵數據，明天 Day 17 我們將為系統裝上智慧大腦：實作臨床警告引擎——NEWS（早期預警評分）演算法與即時異常通報！