醫療門診如何導入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
  • 審計記錄:交易與操作日誌可追溯,但避免包含病歷內容

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

技術整合流程

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

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

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

資安與合規建議

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

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

備用路徑設計

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

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

一致性與溝通

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

整合前後比較

環節 未整合(常見做法) 整合後(建議做法) 對營運影響
診症完成 醫生手寫或系統輸入單據 系統輸入單據後即生成應付金額 減少漏單
付款提示 病人自行前往收款處排隊 螢幕/短訊/App 顯示付款 QR 或連結 減少「最後一條隊」
收款處工作 點算現金、找續、手動輸入 以例外處理為主,自助付款為主流 人手集中處理特例
狀態更新 收款後人手更改狀態 webhook 自動回寫「已付款」 避免重複叫號
對賬 每日人手逐筆對賬 自動對賬,按 invoice_id 匹配 收工時間更可控

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

支付平台選擇要點

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

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

API 與收費模式

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

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

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

分階段推進建議

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

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

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

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

流程責任分工

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

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

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

整合後嘅管理效益

數據與營運優化

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

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

You May Also Like