第 24 章讓預約能成立，本章讓它能被日常營運。你會加入：
我們仍然不處理病歷或醫療判斷。這一章談的是營運可靠性與個資治理，而不是把網站升級成醫療資訊系統。
預約成功只是開始。真正消耗櫃檯時間的是改期、忘記到場、醫師臨時停診、LINE 未送達與離職員工仍可查看名單。若系統只有一張 appointments 表，所有例外都只能靠人工備註，最後沒有人知道資料是否可信。
本章把工作拆成三條互不污染的流程：
預約狀態：booked -> confirmed -> checked_in -> completed/no_show
通知狀態：queued -> sent/failed
資料生命週期：active -> retention_due -> anonymized/deleted
通知失敗不能取消預約；資料到期也不能直接刪掉仍有營運或法定保存需求的紀錄。
完成第 24 章，準備 LINE Official Account、Messaging API channel 與測試用 LINE 帳號。若尚未申請，先用 mock sender 走完整佇列。不要用 LINE Notify 舊教學。
在 Plan Mode 鎖定決策：
請規劃現有診所預約 MVP 的營運功能，不要先實作。
加入安全改期、LINE 或 Email 確認、看診前一天提醒、報到、完成、未到、通知失敗待辦，以及個資保存期限和匿名化流程。
LINE webhook 要驗證簽章，推播只放預約必要資訊。通知失敗不能改變預約狀態。
系統仍不得蒐集病歷、症狀、診斷、處方、健保卡或身分證資料。
請列出新增資料、排程、角色權限、失敗重試、稽核事件與驗收案例。
沿用 appointment_events，事件至少包含：
created、confirmed、rescheduled、cancelled。checked_in、completed、no_show。reminder_queued、reminder_sent、reminder_failed。retention_reviewed、anonymized。不要只更新 appointments.status 而丟失前一個狀態。事件記錄誰在什麼時間做了什麼，是處理客訴、錯誤與權限問題的基礎。
改期不是先取消再建立，因為兩個步驟之間可能失敗。後端 reschedule_appointment 應：
任何步驟失敗都不應留下兩個占位或完全沒有時段的預約。接近看診時間的改期限制放在後端。
請實作原子化的 reschedule_appointment 後端操作。
支援使用管理 token 的預約者與登入的櫃檯人員。
必須先驗證新時段、容量、休診與改期期限，再於同一交易占用新時段、釋放舊時段並建立事件。
兩人競爭新時段最後一格時只能一人成功。重複送出相同改期要安全回傳既有結果。
圖 25-1：改期前先檢查容量、休診與期限，再於單一交易處理新舊時段。
實際按下模擬改期後，事件表新增 booked → rescheduled，原始建立事件仍保留且不可覆寫。
圖 25-2：改期完成後以 append-only 方式保存前後狀態與操作說明。
LINE user ID 需由 LINE Login 或使用者與官方帳號互動後，透過受驗證的流程連結到系統使用者。LINE Login channel 與 Messaging API channel 的 provider 設定會影響使用者識別，實作時應依官方最新文件設定。
新增 line_links：app user、LINE user ID、連結時間、同意版本、解除時間。診所預約若允許訪客不用帳號，可在成功頁提供「連結 LINE 接收提醒」，完成授權後才綁定預約；只知道手機號碼不能直接推播。
使用者可以略過 LINE，Email 或畫面上的預約管理連結仍可使用。
新增：
notification_deliveries：預約、通道、範本、預定時間、狀態、嘗試次數、最後錯誤。reminder_jobs：預約、提醒類型、執行時間、唯一鍵。建立預約後排定確認通知與看診前一天提醒。排程以台北時間計算，但資料庫可保存 UTC。執行前重新檢查預約是否仍有效、時段是否改變、相同範本是否已成功發送。
LINE 訊息只包含診所名稱、預約日期時間、服務名稱、取消／改期連結。不要包含病情或其他敏感內容。使用者封鎖帳號、API 逾時或額度不足時，保存安全錯誤碼，按規則重試，最後進入櫃檯待辦。
如果系統接收加好友、訊息或 postback webhook，必須使用 channel secret 驗證 LINE 簽章。驗證應以原始 request body 進行；解析或重新序列化後再驗證可能失敗。
驗證失敗立即拒絕，不建立連結或事件。事件處理採冪等設計，避免 LINE 重送時重複改期或重複建立通知。
請新增 LINE webhook 與通知 worker。
webhook 必須用原始 request body 與後端 secret 驗證簽章，並以 event ID 防止重複處理。
通知 worker 在送出前重新確認預約狀態、時段與既有成功紀錄。
LINE 失敗時不得取消或回滾預約；有限次數重試後建立櫃檯待辦，並保留 Email fallback。
日誌不可輸出 channel secret、完整 token 或不必要個資。
圖 25-3：通知成功、逾時重試、錯誤簽章、封鎖後 Email fallback 與略過各自有獨立狀態；通知失敗不會取消預約。
櫃檯今日列表提供「已報到」。按下後保存時間與操作者，並讓醫師或後續工作看見等待狀態。完成看診只記錄 completed，不要在這個系統輸入診斷內容。
看診時間過後，由櫃檯人工確認 no_show，不要只靠排程自動判定，因為現場可能延誤或漏按報到。管理者可查看未到率，但報表使用聚合資料，不顯示不必要姓名。
建立可設定的保存政策，例如已完成或取消預約在一定期間後進入 retention_due。具體期限應由實際診所依目的與法遵要求決定，本書不替業者下法律結論。
到期工作先產生審查清單，再匿名化或刪除聯絡資料。統計需要可保留不含身分資訊的日期、服務與結果。每次處理保存政策版本、執行者與筆數。
員工離職或停權時，membership 立即失效；既有事件保留操作者識別快照，但該帳號不能再讀取名單。不要只從畫面選單移除人員。
圖 25-4：示範保存政策、匿名化待辦、離職停權、角色最小權限與稽核事件；圖中的期限僅為測試值，實際期限仍須由診所依目的與法遵要求決定。
至少測試：
請執行診所營運功能驗收。
測試原子化改期、最後一格競爭、重複請求、取消後提醒、改期後舊提醒、LINE 錯誤簽章、API timeout、員工停權與到期匿名化。
每項列出資料庫前後狀態、事件、通知紀錄、畫面結果與權限證據。
檢查任何通知、日誌、報表是否意外包含醫療內容或不必要個資。
建立明天與後天的測試時段。讓預約者 A 改期到容量 1 的時段，同時讓預約者 B 競爭；取消另一筆預約後確認提醒被跳過。模擬 LINE 正常、timeout、錯誤簽章與封鎖四種情況，再停權一位櫃檯帳號。
預期成果是預約、通知與權限各自保持正確；任何外部服務失敗都不會讓預約消失，也沒有醫療資訊被送進 LINE。
你可以接著問 Lovable：「請依我的提醒時間、改期限制與保存政策，生成排程、失敗待辦與故障演練清單。」下一章會進入台灣小型電商，先把商品、庫存、後端計價與訂單快照做對。
嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。
如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：
📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。
📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。
🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。
如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！
🎁 免費送 Lovable 額度給讀者！
我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。
參加方式：
確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！
iThome鐵人賽
看影片追技術