醫療門診如何導入QR收款與排隊叫號系統無縫整合

門診最常出現「服務已完成，但病人仍未能離開」的情況，往往並非因為醫生看診速度慢，而是卡在收款櫃檯：對帳需人手處理、現金需點算、病人需排隊，加上叫號系統與收款流程各自獨立，導致同一位病人需排隊兩次甚至三次。

將 QR 收款與排隊叫號系統整合，目的並非追求花俏，而是讓病人從登記、應診、檢查、取藥到付款，都能以同一個「流程狀態」串連，減少重複排隊，亦令診所管理更為清晰。

‍

先釐清：點解「叫號」同「收款」一定要打通

常見痛點分析

叫號系統本質是流程管理，收款系統本質則為資金與交易記錄。兩者未整合時，常見情況為：病人已完成看診，叫號系統顯示「完成」，但收款仍需病人自行排隊，再由職員人手核對資料、輸入金額、開立單據。

最直接的後果是高峰時段櫃檯擁擠，病人感覺「等候時間過長」，投訴多集中於付款及對帳，而非醫療質素。

以下幾個痛點，幾乎每間門診都曾遇到：

• 收款隊伍過長
• 現金點算與找續
• 單據重複輸入
• 對帳需逐筆核對
• 病人「遺漏」付款或付款後仍被叫去櫃檯

‍

病人旅程設計：從「排到櫃檯」變為「輪到即付款」

理想流程描述

整合後的理想體驗是：病人完成診症後，系統即時生成應付金額，病人可用手機掃描 QR 直接付款，付款成功後自動更新狀態，叫號系統不再將其推入「收款隊列」。需要現場協助或偏好以信用卡付款的病人，仍可前往櫃檯，兩種路徑並行。

動態 QR 的應用

關鍵不在於「單純展示 QR code」，而是要以動態 QR 或付款連結將「金額、單據編號、到期時間」綁定，讓付款結果能回寫至叫號系統或診所管理系統。

有研究顯示，門診引入流動支付後，付款等候時間可由接近 45 分鐘大幅縮短至約 1 分鐘，病人對付款體驗的滿意度亦明顯提升。即使未必每間診所都能達到同等成效，收款櫃檯壓力下降通常都能迅速見效。

‍

三種整合模式：由淺入深，按診所現況揀

模式一：櫃檯展示動態 QR

叫號系統僅負責叫號，診症完成後由職員於收款介面輸入金額，系統生成動態 QR，病人掃碼即付。此模式改動最少，適合先降低現金比例。

模式二：叫號系統觸發付款

當病人狀態由「診症完成」轉為「待付款」，系統自動建立付款單，並於螢幕、SMS 或診所 App 顯示付款 QR 或付款連結。病人可於座位完成付款，櫃檯僅處理例外個案。

模式三：全流程事件驅動

付款成功即時回寫：叫號系統收到「payment_success」訊息後，將病人狀態更新為「已付款可離開」或「已付款待取藥」，同時觸發列印收據、釋放資源、將數據入帳。此模式最為順暢，但需 API 及 webhook 整合。

‍

資料點對點：最少資料，足夠對得返資料欄位設計

醫療資料與付款資料需明確分離。整合原則為「付款系統僅需訂單識別碼」，叫號系統或診所系統保留病人個人資料，減低私隱風險，亦更易符合香港《個人資料（私隱）條例》。

常見對應方式為建立三個核心欄位：

• visit_id（就診流水號）
• invoice_id（收費單號）
• queue_token（叫號票據或隊列代碼）

整合時，建議先確定「以哪個欄位作主索引」。多數門診以 invoice_id 作付款對帳主鍵，visit_id 作臨床系統追溯，queue_token 只作前台流轉。

與供應商溝通需求建議

• 資料最小化：付款端僅傳送 invoice_id、金額、狀態、時間戳
• 狀態定義：待付款、付款中、已付款、付款失敗、已退款
• 回寫機制：webhook 事件通知，失敗需有重試及查詢補數
• 例外處理：重複付款、部分退款、改單後重新產生 QR
• 審計記錄：交易與操作日誌可追溯，但避免包含病歷內容

‍

系統架構建議：以事件通知取代「人手打電話」

技術整合流程

叫號系統與收款平台整合，技術上常見兩種方式：

• 診所系統呼叫付款平台 API 建立訂單，取得付款 QR 或付款連結
• 付款成功後，付款平台以 webhook 回推「成功／失敗」事件至診所或叫號系統

事件驅動的好處是即時，且可重試。即使短暫網絡波動，事件仍可排隊重送，避免出現「病人已付款，但叫號系統未更新」的情況。

資安與合規建議

所有通訊應使用 HTTPS/TLS，並加上簽名驗證或 API token。付款平台處理卡資料與錢包交易時，若能提供 PCI DSS Level 1 合規能力，診所無需自行保存或處理卡資料，風險更低。

‍

體驗細節：長者、外籍病人及特殊情境處理

備用路徑設計

門診病人狀態多元，流程必須具備容錯能力。QR 收款的成功，往往取決於「備用路徑」設計是否完善。

實用做法是將付款分為「自助」與「協助」兩種動線：自助病人掃碼即付，需協助者由職員以卡機或手機 App 代為出示 QR，或以同一平台收卡付款，交易仍歸入同一對帳口徑。

一致性與溝通

叫號畫面與付款提示需保持一致。病人見到「已完成可離開」，不應再收到「請到收款處付款」的訊息。文字一致性往往是減少投訴的關鍵。

‍

整合前後比較

‍

點揀支付平台：醫療場景要留意的規格

支付平台選擇要點

選擇收款平台時，醫療門診通常有三大要求：付款方式多元、入帳與對帳快速、可與現有系統整合。

以 Wonder 為例，定位為香港及亞太區商戶的金融科技方案，支援線上線下多達 34 種收款方式，包括 Visa、Mastercard、JCB、八達通、銀聯、雲閃付、微信支付、支付寶、PayMe、轉數快等，適合多元支付需求的門診環境。商戶亦可用 Wonder App、Wonder Terminal 及 Wonder Dashboard 將收款、交易記錄、數據分析與對帳集中管理。

API 與收費模式

若需更深度整合，開放 API 及 SDK 亦十分重要。支付平台能否提供建立訂單、生成付款連結或動態 QR、以及支付結果通知（webhook），將直接影響叫號系統能否自動回寫狀態。

收費模式亦需清楚了解。透明的按交易收費、無合約、無月費、無租機費，對中小型診所試點更易批核，亦降低試錯成本。Wonder 的收費可低至 0.7%，並強調透明，適合希望由現金轉型的門診作為比較基準。

‍

實施步驟：從試點到全面切換，三週內可見成效

分階段推進建議

許多門診初期希望「一次到位全面整合」，反而拖慢進度。較穩妥做法是先於特定時段或科別試點，先將 QR 收款流程跑順，再接入叫號系統的狀態回寫。

第一階段可先實施「櫃檯動態 QR + 自動對帳」，目標為減少現金及縮短付款時間。第二階段推動「診症完成自動開單」，讓病人在座位即可付款。第三階段再實施「事件回寫 + 例外處理閉環」，將狀態、退款、改單納入同一套規則。

Wonder 平台支援 7 分鐘快速開戶開始收款，對希望快速試點的診所更為便利；若需系統層面整合，可利用 Wonder Dashboard 進行營運監控，並以 API 由現有診所系統或叫號系統觸發付款單。

‍

常見失敗原因：流程責任未明確

流程責任分工

整合項目最常遇到的困難，往往在於「誰負責更新狀態」及「出現例外時由誰處理」。若病人付款失敗，或付款成功但單據金額後續被更改，若無明確規則，前台與後台易互相推諉。

建議一開始即明確規範：叫號系統為「流程狀態權威」，收款平台為「付款狀態權威」。兩者以事件互相通知，但不應互相覆蓋對方的核心欄位。

同時，現場亦需保留簡單人工備援：遇網絡問題時先以卡機收卡或記錄待付款，恢復後再補回寫。病人不會因系統維護而願意多排一次隊，門診流程需預設「總有人會遇到例外」。

‍

整合後嘅管理效益

數據與營運優化

當付款與叫號整合後，不僅縮短排隊時間，更能獲得有價值的營運數據：每時段完成一個就診的平均時間、付款方式分佈、退款原因、櫃檯介入比例、哪類服務最易出現改單。

這些數據無需大型 BI 項目即可產生價值。只要收款記錄能即時匯總、對帳自動化，前台減少「收工前對數」壓力，管理層亦能更有效安排人手與診期，病人自然感受到流程順暢，不再於最後一步卡關。

‍