一位患者的睡眠狀況，資料其實來自好幾個地方：睡覺時裝置量到的生理數據、白天自己填的日誌與問卷，還有醫療團隊的判讀與追蹤。這些過去分散在裝置、紙本和各自的表格裡，很難兜在一起看。我們為一家從事睡眠醫學臨床服務的機構打造的，就是一套把患者端與臨床端接在同一條資料流上的平台：患者用手機 App 連接智慧戒指、體溫貼片或 Apple Watch，睡眠一整晚的血氧、心率、睡眠階段會自動上傳、在 App 上看得到圖表，也能隨手填睡眠日誌與臨床問卷；醫師與個案管理師則在後台看到每位個案的數據、管理臨床試驗與知情同意、需要時匯出報表。從手腕上的裝置到醫師手上的報告，中間不必人工轉抄，也不會各存一份兜不攏。
睡眠資料從患者手腕上的裝置出發，先經手機 App 整合與暫存，再上傳到後台分析與管理，三段接成同一條資料流。
flowchart LR
subgraph DEV["周遭裝置"]
direction TB
R["智慧戒指"]
P["體溫貼片"]
W["Apple Watch"]
end
APP["iOS App
三源整合・數據視覺化
日誌問卷・背景上傳"]
BE["臨床管理後台
個案・臨床試驗管理
報表・批次推播"]
ENG["第三方睡眠分析引擎"]
CLIN["醫師・個案管理師"]
R -- 藍牙 --> APP
P -- 藍牙 --> APP
W -- HealthKit --> APP
APP -- HTTPS API --> BE
BE -- 送分析 --> ENG
ENG -- Webhook 回傳 --> BE
BE -- 判讀・追蹤 --> CLIN
classDef ext fill:#faf3f5,stroke:#cf7688,stroke-dasharray:4 3,color:#201d10;
classDef human fill:#cf7688,stroke:#b95f72,color:#ffffff;
class ENG ext;
class CLIN human;
三種穿戴裝置藍牙整合
App 能連接智慧戒指、體溫貼片與 Apple Watch 三種穿戴裝置：戒指下載整晚的睡眠紀錄檔、貼片回傳體溫、Apple Watch 則同步 HealthKit 裡的睡眠與心率資料。患者不必自己抄數字，睡一覺醒來，資料就進了系統。
六維睡眠數據視覺化
App 把血氧、心率、體溫、睡眠效率與階段、自律神經、記憶指數等數據畫成圖表，支援日／週／月切換，也能點進單日看細節。比起一長串數字，患者更容易看懂自己今晚睡得好不好、跟平常比起來如何。
四種日誌與十一種臨床問卷
睡眠、情緒、頭痛、疼痛四種結構化日誌，加上 PSQI、ISI、STOP-BANG、PHQ-9、GAD-7 等十一種國際標準臨床問卷，患者在 App 上就能填寫與回顧。主觀的睡眠感受和客觀的裝置數據擺在一起，醫療團隊判讀時更完整。
臨床試驗與知情同意管理
後台可建立臨床試驗、設定期間與內容，個案在參與前於 App 簽署知情同意，狀態（同意／拒絕／撤回）完整留存。臨床研究需要的同意流程與資料依據，系統從頭到尾都接住，不必再靠紙本追。
分層角色權限與操作稽核
後台依開發者、管理員、合作單位、醫師、個管師等角色給予不同權限，不同角色只看得到自己該看的個案；匯出報表這類敏感操作需經審核才能執行，所有動作都留下稽核軌跡，誰在什麼時候動了什麼，事後都查得到。
批次推播與異常數據自動警告
系統整合推播通知，可對全部個案或指定醫師、個管師的個案批次發送；當體溫、血氧、睡眠效率或心率超出安全範圍，也會自動推播提醒。重要的變化不必等人工翻資料才發現，系統會先提醒。
患者端是 Swift 開發的原生 iOS App；後端用 Laravel 8，並針對整晚生理數據的大量上傳與查詢做了效能設計（Octane／Swoole、讀寫分離、Redis 快取），數據再多也不拖慢日常操作。其中裝置整合、上傳穩定性、權限稽核這三段，花了我們不少功夫。
三種裝置、一套資料流
戒指走專用 SDK 以藍牙下載睡眠檔、體溫貼片走自訂的藍牙配網協定、Apple Watch 讀 HealthKit，三種來源的連線方式和資料格式都不一樣。我們在 App 端把它們統一成同一套生理數據模型，再送後端的第三方睡眠分析引擎、以 Webhook 收回結果。日後要換裝置或多接一種新裝置，改的只是對接那一小塊，不必整套重寫。
弱連線也不漏資料
整晚的睡眠檔動輒不小，App 以本機先落地、再交背景上傳，並顯示下載與上傳進度；後端則用佇列批次處理推播與分析結果的輪詢。網路不穩或資料量大的時候，作業不會卡住，也不會漏傳。
醫療級的權限與稽核
後台是細緻的角色權限，敏感操作走「申請 → 審核 → 執行」的三層流程、需經核准才動作，並以分散式鎖確保序號唯一；所有敏感操作都寫進活動日誌。健康資料誰能看、誰動過，都有依據可查。
有不少原本要人工盯的環節，現在都交給系統自動處理：睡眠資料上傳後自動送分析、結果回來自動歸到對應個案；體溫、血氧、睡眠效率、心率超出安全範圍時自動推播提醒；每日固定時段自動推送任務與臨床試驗提醒；連過期的推播與暫存資料，也由背景排程定時清理。對臨床團隊來說，等於把「收資料、比對、提醒」這些每天重複的雜事，交給系統自動接續，人力可以留給真正需要判讀的個案。
開發一套結合 App 與後台的健康管理平台要多少錢？
取決於範圍。這類平台通常同時包含患者端 App（含穿戴裝置藍牙整合、數據視覺化、日誌問卷）與管理後台（個案管理、臨床試驗、報表），屬於中大型專案；影響報價的主因是要串接幾種裝置、數據分析的複雜度，以及後台的角色權限與合規要求。建議先把必要功能列出來，我們可以依範圍拆成幾個階段報價，先做核心、再逐步擴充。
這種 App 加後台的整合系統，開發時間大概多久？
常見時程約 6 到 10 個月：需求釐清與資料流設計約 1–2 個月，App、後台與裝置整合並行開發約 4–6 個月，最後是資料校正、測試與上線輔導。若採分階段上線（先讓 App 能連裝置、看得到數據，再補齊問卷、臨床試驗與報表），第一個可用版本能更快進到實際試用。
要串接智慧戒指、Apple Watch 這類穿戴裝置，技術上會很複雜嗎？
會，但可以收斂。不同裝置的連線方式與資料格式都不一樣：戒指多半透過專用 SDK 走藍牙下載睡眠檔、體溫貼片走自訂藍牙配網、Apple Watch 則是讀取 iOS 的 HealthKit。我們的做法是把這些來源在 App 端統一成同一套生理數據模型，再送後端分析，讓「換一種裝置」不會牽動整套系統，日後要多支援一種裝置也相對單純。
醫療或健康資料的隱私與稽核，系統怎麼把關？
從權限與軌跡兩端把關。後台採分層角色權限，不同角色只看得到自己該看的個案範圍；匯出報表這類敏感操作走「申請、審核、執行」的流程，需經核准才能進行；所有敏感操作都會留下稽核軌跡，記錄誰在什麼時候動了什麼。臨床試驗也搭配知情同意的簽署與狀態管理，讓資料的使用有依據可查。
未來想加新的問卷、日誌或裝置，好擴充嗎？
可以，這是一開始就考量的方向。問卷與日誌以可重用的題型元件組成，新增一份量表主要是配置題目與計分，不必每次都重寫畫面；數據來源與分析也是模組化的，要接新的裝置或新的分析指標，多半是新增對應模組而非改動既有流程。系統也提供 API，能與既有的醫院或研究系統串接。
