前言
在 Day 7 中，我們深入剖析了病房第一線的臨床痛點：床邊即時量測、條碼給藥三讀五對，以及病房網路死角下的離線容錯需求。

面對這些嚴苛的臨床場景，許多初接觸醫療資訊標準的開發者常會走入一個極端架構誤區：「既然 FHIR 這麼好用，乾脆讓行動端平板直接將每次量測、每次掃條碼，全都直接呼叫 HAPI FHIR Server 的 REST API。」

實務上，這種「全盤直連 FHIR」的設計在真實醫院場域中往往會迅速崩潰：

1.負載與效能瓶頸： HAPI FHIR 為確保國際標準合規，每次寫入都牽涉繁重的 JSON Schema 驗證、版本號遞增與多表索引更新。在交接班與晨間量測尖峰期，數百台平板並行寫入會導致嚴重的資料庫鎖定與延遲。
2.臨床專用業務邏輯無處安放： 「三讀五對邏輯」、「NEWS 早期預警評分即時計算」、「病房動態交班排程」屬於專門的臨床業務流程（Business Domain），不屬於標準 FHIR Server 的通用職責。

今天我們將動手規劃現代化行動護理資訊系統（NIS）的整體架構，確立前端介面、NIS 核心後端服務，以及 FHIR Gateway 的職責界線與資料流。

一、系統整體架構圖：三層解耦模型
為了兼顧「臨床操作的高併發與極低延遲」以及「跨系統與主管機關要求的標準化交換」，我們採用三層架構：

二、三大核心模組的職責切分（Separation of Concerns）

1. 前端層：極簡互動、離線防呆與即時反饋
   (1.)載具型態： 建議採用 Progressive Web App (PWA) 或 Hybrid 行動 App。
   (2.)職責範疇：
   -串接硬體周邊：整合平板鏡頭條碼掃描、外接藍牙條碼槍、生理量測儀器數據自動接收。
   -臨床防呆輸入校驗：前端即時阻擋不合理的數值（例如呼吸次數輸入 120 次/分）。
   -離線工作佇列：利用 IndexedDB 儲存當班病患基本快照。斷網時體徵量測先寫入本地隊列，網路恢復時依時間戳記依序向後端同步。

2. NIS 核心後端服務：臨床業務的中樞神經
   (1.)技術棧： Node.js + Express (TypeScript)。
   (2.)職責範疇：
   -身分與存取控制（Auth）： 驗證護理人員身分證字號或員編，派發具時效的 JWT Token，實作 Role-Based 權限控制。
   -臨床防錯邏輯執行： 處理給藥「三讀五對」條碼核對演算法，驗證病患 ID 與藥品條碼是否完全符合當前醫囑。
   -高效能時序資料處理： 接收高頻體徵數據，直接寫入內部高效率的 PostgreSQL 關聯表，保證 API 響應時間低於 100ms。
   -臨床規則引擎（Rules Engine）： 寫入體徵的同時，即時計算 NEWS（National Early Warning Score）數值，若達危急門檻，立刻透過 WebSocket 向護理站發出紅色告警廣播。

3. FHIR Gateway：標準化資料的轉譯橋樑
   (1.)核心模式： 轉接器模式（Adapter Pattern）與外觀模式（Facade Pattern）。
   (2.)職責範疇：
   -資料模型映射（Data Mapping）： 將內部關聯式資料庫的扁平欄位（如 vital_signs 資料表），組裝成標準的 FHIR Observation 與 Bundle 格式。
   -編碼系統轉換（Terminology Mapping）： 將內部自定義的檢驗代碼對齊國際標準 LOINC 與 UCUM 單位系統。
   -非同步同步機制（Async Syncing）： 透過排程工作或內部隊列，將穩定的臨床記錄批次上傳至 HAPI FHIR Server，避免前線操作受標準伺服器負載波動影響。

三、關鍵資料流向：以「床邊體徵量測」為例
為了看清楚三者如何協同運作，我們追蹤一次體溫量測的完整生命週期：

1.極速響應： 護理師在送出數據後，只需要等待第 2 到第 6 步（內部資料庫單表寫入），耗時通常在 50ms 以內，床邊操作毫無卡頓感。
2.安全轉譯： 第 8 到第 10 步在後台非同步進行，Gateway 負責將資料轉化為 LOINC 編碼的 Observation，即使此時外部 FHIR Server 正在重啟或忙碌，也不會中斷床邊護理師的量測工作。

四、架構設計原則總結
在設計智慧醫療後端時，請隨時牢記三項設計準則：
1.讀寫分離，內外解耦： 內部業務與內部資料庫求「快、穩、符合前端界面動線」；對外介面與標準交換求「嚴謹、合規、語意精確」。
2.任何跨系統交換必須經過 Gateway 驗證： 嚴格禁止前端直接繞過後端寫入 FHIR 伺服器，避免未經校驗或去識別化的敏感臨床資料直接外洩。
3.時鐘源一致性（NTP 同步）： 在多容器與分散式環境中，所有服務必須校準至相同時鐘源，臨床數據的 effectiveDateTime 必須精確記錄到毫秒與時區（如 +08:00），避免因時差造成用藥核對的判定混淆。

小結
今天我們完成了整個系統的頂層骨架設計：
1.建立了前端、NIS 後端與 FHIR Gateway 三層解耦架構。
2.明確劃分了各層的職責邊界，解決了「直接打標準 Server 效能低落」的架構難題。
3.追蹤了臨床高頻量測的循序圖，釐清了即時業務處置與非同步標準交換的協同流程。

骨架已定，明天 Day 9 我們將進入臨床空間與病患動線管理：病患清單與動態床位管理——剖析 Encounter 與 Location Resource 的關聯設計！