前言
在護理站的電子白板或護理師手持的行動載具上，最常看見的第一個畫面永遠是「病房動態床位看板」。

例如護理師一上工，必須清楚知道：
-8 樓西側病房目前有哪些病患住院？
-801 床是哪一位病人？是新入院、預計今日出院，還是剛從加護病房（ICU）轉入？
-802-A 床目前是空床、保留中，還是消毒清潔中？

在一般資訊系統中，初學者常習慣在 Patient 資料表上直接加上 bed_id 或 room_number 欄位。但在臨床實務上，這種做法會產生嚴重架構缺陷——病人是活動的實體，而床位是實體空間資源。同一個病人在單次住院期間可能歷經多次轉床（例如：急診留觀床 ➔ ICU 重症床 ➔ 一般急性病房床），若直接把床位寫死在病人身上，歷史軌跡將完全錯亂。

今天我們將深入探討 HL7 FHIR 中專門負責「臨床就醫互動歷程」與「空間拓撲架構」的兩大關鍵 Resource：Encounter 與 Location，並建立標準的關聯動態模型。

一、空間拓撲模型：Location Resource 剖析
Location 用於記錄提供醫療照護服務的實體空間或虛擬位置。

在醫院物理空間管理中，空間具有嚴格的階層式拓撲結構（Hierarchical Topology）：

1. 空間資源的核心欄位
   status：空間可用狀態（active 使用中、suspended 暫停使用/保養維護、inactive 停用）。

operationalStatus：床位營運狀態（採用 HL7 v2 Table 0116 代碼，如 C 佔床 Occupied、U 未佔床 Unoccupied、K 污染待清潔 Contaminated、I 隔離 Isolation）。

physicalType：實體屬性（建築 bu、病房 wa、病室 ro、床位 bd）。

partOf：指向上一層空間階層的 Location Reference。

2. 床位定義 JSON 實例
   以下展示一張實體病床的標準定義，明確指出它隸屬於 801 病室：

二、臨床歷程核心：Encounter Resource 深度剖析
如果說 Patient 是「主角」、Location 是「舞台」，那麼 Encounter（就醫歷程 / 臨床接觸） 就是記錄「主角在什麼時間、出現在哪個舞台、進行了什麼臨床事件」的劇本。

無論是門診（Outpatient, AMB）、急診（Emergency, EMER）、還是住院（Inpatient, IMP），每一次臨床接觸都有其獨立的 Encounter 實體。

1. 核心狀態機（Status Lifecycle）
   住院期間的 Encounter.status 遵循嚴格的狀態流轉：
   

2. 床位歷程追蹤：location 陣列
   這是護理系統設計中最精妙的區塊。Encounter.location 是一個陣列，用來記錄病患住院期間在不同床位與病房的移動時間軸：

-location：指向特定的 Location（病床或病房）。
-status：在該床位的狀態（active 當前停留、completed 已移出）
-period：進出該床位的確切時間區間（start 與 end）。

3. 住院中病患的 Encounter JSON 實例
   以下展示病患「蔡曉華」在 801-1 床住院中的完整結構，並記錄了他曾由急診留觀床轉入的歷程：
   
   三、NIS 病房動態看板的查詢與資料聚合邏輯
   在護理站前端載入「8 樓西側病房即時動態看板」時，後端或 Gateway 需要如何調度 API 呢？

查詢步驟演練：
1.取得病房下屬所有床位：
向 Server 發出請求，搜尋父節點為 8 樓西側護理站的所有病床資源：
2.取得當前所有住院中的 Encounter：
查詢狀態為 in-progress 且當前位置屬於該病房的活動紀錄：

技巧（FHIR Reverse / Forward Include）：
使用 _include=Encounter:subject 可以在單次查詢中，同時將對應的 Patient Resource 一併打包回傳，避免前端發生 N+1 查詢問題！

3.前端看板狀態配對：

-若某床位 ID 存在於某個 Encounter.location 且狀態為 active ➔ 標示為 「佔床（Occupied）」，渲染病患姓名、年齡、主治醫師與主診斷。
-若該床位無對應活動中的 Encounter 且 Location.operationalStatus 為 U ➔ 標示為 「空床」，開放辦理新入院。
-若 Location.operationalStatus 為 K ➔ 標示為 「待清潔」，以橘色高對比提示工友清潔。

四、架構設計的防呆警示
在落實床位異動時，後端服務必須實施以下原子性（ACID）保護措施：

1.防重複排床（Double Booking Protection）：
在辦理病患轉床或入院時，必須在資料庫 Transaction 內驗證目標 Location 目前是否存在任何未結案（status: active）的關聯。嚴禁兩位活動病患同時佔據同一張實體床位。

2.轉床的時間閉合（Period Closure）：
當病患從 A 床搬至 B 床時，必須在同一個 Transaction 中：

-將前一筆 location[A].period.end 寫入當前時間，狀態改為 completed。
-新增 location[B]，start 設為當前時間，狀態設為 active。
-將 A 床的 Location.operationalStatus 設為 K（待清消），B 床設為 C（佔床）。

小結
今天我們徹底釐清了醫療空間與就醫歷程的標準模型：

1.Location 透過 partOf 建立了院區 ➔ 病房 ➔ 病室 ➔ 病床的樹狀拓撲，並以 operationalStatus 標明即時營運狀況。
2.Encounter 作為臨床核心樞紐，串接了病人、主治醫師，並利用 location[] 陣列精確追蹤病患轉床歷程。
3.掌握了利用 _include 參數一次性拉取病患與床位資料的高效查詢模式。

掌握了病人、醫護、體徵、床位與就醫歷程後，明天 Day 10 我們將正式動手設計關聯式資料庫：護理記錄資料庫設計——PostgreSQL Schema、正規化資料表與 FHIR 映射策略！