端對端驗證報告
於 Raspberry Pi 5 上自動化測試 · 2026-03-02
6 測試套件 · 13 病患情境 · CIRS v3.26
13 個病患情境，從掛號到輸血到站點撤離
模擬 72 小時斷網——離線佇列、LoRa、DR 備份還原
寄售品從廠商到手術消耗到雲端帳目一致
重新連線後自動校正所有資料——無需人工逐筆核對
主機損毀，備援即插即用，數分鐘內恢復全部戰力
危機撤站合併時，成千上萬筆紀錄零遺失
本報告涵蓋六大測試套件共 595 步自動化測試，驗證 xGrid 在站點撤離、72 小時斷網、供應鏈對帳、同步韌性、災難復原、站點合併等情境下，維持完整的資料連續性——病患身分、輸血追溯、手術交班、庫存與帳務準確性——全部在一台離線 Raspberry Pi 上完成。
為什麼重要
在災害或衝突中——地震、颱風、戰場——最先崩潰的不是物資，而是資訊連續性。當站點撤離、合併或斷線時，病患紀錄、輸血追溯、藥品配送鏈全面斷裂。
風險所在：
- 輸錯血給病患——監管鏈中斷
- 手術交班未記錄——關鍵資訊在團隊間遺失
- 站點合併後庫存不符——物資去向不明
- 撤離時檢傷紀錄遺失——病患變成未知身分
xGrid 讓人員持續工作、資料完整保留——即使站點撤離、病患轉移、手術必須在別處恢復。全部運行在一台信用卡大小的 Raspberry Pi 上，完全離線。護理師用手機即可操作。
以下每一項宣稱都有自動化測試步驟為證。428 個步驟、3 大測試套件、公開的測試方法論。
當一切出錯，醫療不中斷
8 個醫療站中 3 個在作業中被迫撤離。正在輸血、手術進行中、關鍵藥品運送途中。問題不是要不要繼續——而是系統能不能讓你繼續。
就在那個當下：
- 3 位病患正在輸血——血袋必須安全轉移並在新站點重新驗證
- 一台手術正在進行——必須中斷、經 EMT 轉送病患、在新站點恢復手術
- 所有藥品和設備必須即時調撥至剩餘站點
真正的問題：
- 病患的身分和病歷是否跟著他們？
- 每一袋血是否都有完整追蹤——從來源到輸血？
- 外科醫師能否從中斷點精確恢復手術？
- 每一次轉移、每一個決定、每一次交班是否都被自動記錄？
答案：全部做到
- 病患身分在站點轉移中完整保留
- 輸血監管鏈維持不中斷——重新交叉配對並驗證
- 手術在新站點恢復，ISBAR 交班完整
- 所有整併站點庫存完成對帳
- 34 個步驟，34 個通過，零資料遺失
13 病患情境
內科門診
從掛號到繳費的完整門診流程
標準門診流程能否完全在離線環境運作？
骨科手術
含麻醉、輸血和計費的手術全週期
緊急手術中輸血能否安全追蹤，不遺失監管鏈？
多站點物流
跨 3 個站點的庫存調撥與藥局配藥
物資在站點間調撥時，庫存是否保持準確？
梯隊後送
ISBAR 交班從現場到醫院，含檢傷與轉送
病患後送時，交班紀錄能否完整保留？
麻醉深入測試
完整麻醉生命週期：誘導至 PACU 出院
麻醉紀錄從誘導到出院是否完整無缺？
大量傷患 (MCI)
20 名傷患在 3 秒內完成檢傷與登記
20 名傷患同時到達時，系統能否跟上檢傷速度？
血庫壓力測試
10 組併發交叉配對與輸血作業
10 組交叉配對與輸血能否同時進行不衝突？
全日作業
日班到夜班交接，處理 50+ 名病患
系統在一整天的班次交接中能否維持完整性？
並行壓力測試
4 組平行高寫入工作流在最大站點負載下執行
多站點同時大量寫入資料庫時，資料一致性能否維持？
站點緊急整併
3 個站點作業中撤離，病患與物資轉移
3 個站點作業中被迫關閉，人員能否繼續工作、資料能否完整保留？
LSCO 戰場醫療
完整 LSCO 生命週期：PFC 照護計畫、TCCC 傷票、MEDEVAC 後送、DCS 手術、步行血庫、權限模式切換
戰場醫療工作流程——從野戰照護到後送——能否完全在一台離線 Raspberry Pi 上運行？
醫療站管理
醫療站註冊、站間調撥、故障切換與緊急整併操作
多站作業——調撥、故障切換、整併——能否可靠地被編排執行？
戰傷鏈串連
單一傷患依序通過 TCCC 傷票、PFC 照護、MEDEVAC 後送、DCS 手術，驗證跨模組資料串連
戰場傷患經歷完整 LSCO 流程時，各模組間的資料串連是否正確？
xGrid 72H 生存測試
模擬 72 小時完全斷網——6 個階段、353 步驟
Phase 1：平靜 → 風暴
正常運作到網路中斷。SSE 重連、PWA 離線佇列啟動、LoRa 橋接模擬、Dock Sync 同步狀態。
網路突然斷線時，所有 PWA 工作站能否無縫切換到離線模式？
Phase 2：風暴
長時間隔離。Safety-II 緊急授權、SYNC 衝突偵測、MIRS DR 備份還原。
完全隔離超過 24 小時後，系統能否維持作業並處理授權例外？
Phase 3：浩劫
雙 RPi 生存驗證。設備故障切換、極端異常路徑。
主要 RPi 故障時，備援 RPi 能否接管並維持完整資料？
Phase 4：合併風暴
Alpha/Beta 合站整合與衝突解決。
T+36h → T+48h — Alpha 撤站、病患合併至 Beta，完整衝突偵測與解決
Phase 5：降級作戰
單站資源耗竭下的生存運作。
T+48h → T+60h — Beta 獨立運作，物資耗盡、設備故障、啟動緊急協定
Phase 6：耐久驗證
最終問責與 72 小時驗證。
T+60h → T+72h — PFC 警示、設備循環、補給鏈崩潰/復原、全面對帳稽核
供應鏈對帳
寄售品全鏈驗證——從廠商到手術消耗到雲端帳目
完整寄售品生命週期：廠商出貨 → RPi 本機收貨入庫 → 手術消耗扣庫 → 離線佇列同步至雲端 → 帳目對帳 ¥91,600。28 步驟全數通過。
情境風險對照
每個測試情境如何對應真實營運風險
| 關切項目 | 風險 | 驗證依據 |
|---|---|---|
| 輸血追溯 | 輸錯血或監管鏈中斷 | 病患 B、I：轉移 + 重新交叉配對 |
| 手術中斷 | 中斷未記錄或交班失敗 | 病患 I：ISBAR → EMT → 恢復手術 |
| 多站點庫存 | 合併站點庫存不符 | 病患 C、H + 370/s 效能基準 |
| 大量傷患湧入 | 檢傷被湧入傷患癱瘓 | MCI：200 人 21 秒（RPi 5） |
| 離線連續性 | 斷網/斷電導致作業停擺 | 全部 428 步於 RPi 執行，無需網路 |
| 供應鏈帳務 | 寄售品消耗未追蹤、帳目不符 | 供應鏈對帳：28 步、¥91,600 驗證 |
硬體效能
於單一 Raspberry Pi 5 測試（8GB，約 $80 美元）
一台 Raspberry Pi 5 處理每筆操作的速度比人類發起操作還快。
寫入效能
| 操作 | 吞吐量 | 延遲 |
|---|---|---|
| 病患掛號 | 58.5/s | 17ms |
| 庫存入庫 | 244/s | 4ms |
| 站間調撥 | 370/s | 3ms |
| 完整麻醉週期 | 37.5/s | 27ms |
| 跨系統來回 | 14.8/s | 68ms |
即使 20 個工作站同時運作，系統仍在 1 秒內回應，零錯誤。
併發站點負載
| 站點數 | 吞吐量 | P95 延遲 | 錯誤 |
|---|---|---|---|
| 5 | 59/s | 92ms | 0 |
| 10 | 56/s | 318ms | 0 |
| 15 | 56/s | 578ms | 0 |
| 20 | 55/s | 641ms | 0 |
即使 20 個工作站同時運作，吞吐量僅降 7%，零錯誤
大量傷患文書處理能力超越實際到院速率數個數量級。
大量傷患處理能力
200 名傷患約 21 秒內完成登記
實際 MCI 傷患到達速率：30-60 分鐘
系統僅使用約 1% 容量
效能測試方法論
所有測試於 Raspberry Pi 5（8GB RAM，Debian Bookworm）執行。SQLite WAL 模式，單行程 Python ASGI。循序測試：100 次操作，取 3 回平均。併發測試：依站點數建立 asyncio 任務，每站 50 次操作。無網路開銷 — 僅 localhost。使用 Python time.perf_counter() 量測。
一台 Raspberry Pi 即可服務 15-20 個工作站，處理每日 500+ 名病患，零錯誤。在災害或野戰現場，電腦永遠不會是瓶頸——人力才是。
快速迭代
48 小時內從 10 個缺口到零缺口
LSCO 就緒度
8 大戰場醫療模組——全部在 Raspberry Pi 上驗證完成
已驗證
範圍與限制
- •本驗證為特定模擬環境中的工程驗證，非臨床結果研究。
- •結果受限於測試時的特定硬體、軟體版本及部署配置。
- •De Novo xGrid 非醫療器材，未經任何監管機構核准。
- •詳細技術附錄可依申請提供。
名詞定義
- PASS
- — 步驟執行完成且斷言驗證成功
- FAIL
- — 步驟執行完成但斷言失敗
- GAP
- — 步驟尚未實作（API 存在但測試缺漏）
- SKIP
- — 步驟刻意排除（如 FHIR 匯出 — 不在範圍內）