每月十萬份醫療傳真點入電子病歷:UTHealth 用 AI 清舊系統手尾
Tech News

每月十萬份醫療傳真點入電子病歷:UTHealth 用 AI 清舊系統手尾

圖片:via iThome — https://www.ithome.com.tw/news/177732
TechLab 編輯部(譯)·

由小型試驗擴至逾百間診所,公開資料仍欠例外處理細節

傳真冇消失,只係行政成本藏得深

醫療系統電子化咗咁多年,傳真仍然未退場。醫院、診所同化驗所用緊唔同系統,資料格式亦未必對得上,一張睇到、簽到、又可以即刻傳走嘅文件,反而成為最方便、最少阻滯嘅交換方法。麻煩去到接收嗰邊先出現:職員要逐份睇、拆文件、辨認病人同醫生,再揀啱位置放入電子病歷。UTHealth Houston 個 iDFax,針對嘅正正係呢堆重複又容易入錯嘅工夫。

UTHealth Houston 公布,iDFax 由 2023 年每月處理約 2,800 份傳真嘅試點,擴至逾 100 間 UT Physicians 診所;到 2026 年 2 月,每月處理量已超過 10 萬份,服務逾 1,200 名職員。呢條時間線幾有參考價值:團隊先喺少量據點量度速度同辨識表現,2024 年逐步加科別,2025 年先全面擴展,冇一開波就叫成間機構押注生成式 AI。

iDFax 由接收傳真、排隊、AI 分類到接駁電子病歷嘅系統架構圖

圖片:UTHealth Houston

OCR 只係第一關,後面仲有幾層配對

電子傳真先經專線送入獨立 AWS 帳戶嘅 S3,SQS 負責排隊,EC2 上嘅容器逐份處理,DynamoDB 記低每份文件行到邊一步。影像校正同 OCR 將印刷字、手寫內容抽出,系統再拆開夾埋一齊嘅文件、刪走重複頁,Amazon Bedrock 上嘅基礎模型就處理文件分類同內容分析。抽到病人及醫生資料後,iDFax 會配對身份同病歷,再送去 Epic 或其他院內系統。

呢個設計有個幾實際嘅重點:收件同處理分開咗。就算短時間湧入大量傳真,SQS 都可以先排住,後端再加運算資源慢慢消化,唔使每部接收系統同步頂住峰值。生成式 AI 喺當中只負責指定環節,前後仍有儲存、排隊、狀態追蹤、身份查找同系統整合。企業真係想用 AI 慳工夫,預算大頭好多時會花喺呢啲接駁位,模型 API 反而只係其中一項。

iDFax 由試點逐步增加每月傳真處理量嘅圖表

圖片:UTHealth Houston

95% OCR 準確,唔等於 95% 文件入啱病歷

院方話 OCR 準確率維持喺 95% 以上,每份傳真處理時間由 82 至 150 秒降至 28 至 68 秒。不過 OCR 數字只代表文字辨認表現,冇證明文件分類、病人配對、醫囑欄位同最終路由都有同一準確度。一個姓名認錯字可能影響有限,但病人身份、藥物劑量或者轉介科別配錯,後果完全唔同,評估時理應逐個欄位同文件類型分開計。

公開資料亦冇清楚交代 iDFax 點處理低信心結果,包括幾低先交俾人覆核、覆核比例、職員改正率、搵唔到病人時會排去邊條隊列,同錯誤入咗 Epic 後點追查。院方提到有監察儀表板,但未公開呢批關鍵指標。醫療文件自動化最值得追嘅數,係有幾多例外要人執,同埋幾多錯誤漏過咗檢查;單睇 OCR 百分比唔夠。

私隱隔離要睇實際設定,HIPAA 亦唔等同香港法例

UTHealth 指系統採用可處理 HIPAA 受保障醫療資料嘅 AWS 服務,放喺設有保安規則同集中監察嘅獨立環境。AWS 文件亦寫明 Bedrock 會隔離客戶內容、加密傳輸及靜態資料,亦唔會用輸入輸出去訓練基礎模型。不過服務具備呢啲能力,唔代表每個部署自然安全;S3 保存期、誰人有權讀取、模型調用紀錄有冇留低敏感內容、備份點刪,同出事後點追蹤,全部要由機構設定同持續審核。

香港仍有真實傳真場景,例如醫管局專科門診轉介表格保留傳真欄位,香港兒童醫院亦接受經傳真遞交新症文件,所以呢類技術唔算離地。不過未有資料顯示本港醫院採用 iDFax 或同類系統,HIPAA 亦唔可以直接套落香港《私隱條例》。私隱專員公署嘅 AI 模範框架要求按風險安排人為監督、保存可追溯紀錄同持續測試;真係引入醫療環境之前,低信心文件點覆核、資料保留幾耐,同錯誤點升級,都要寫得清清楚楚。

至於成效,iThome 報道引述項目資料,按每年 100 萬份傳真同平均慳 68 秒推算,可省約 1.9 萬小時行政工時;連同營運、錯誤及合規風險等估算,院方同 AWS 稱每年節省逾 200 萬美元。不過後半部分冇詳細算法,亦冇獨立審計,暫時適合當項目方商業估算。下一步值得睇嘅,係覆核率、錯誤率同實際營運成本會唔會公開。


參考來源

本文根據原文及公開資料整理;資料有出入時,以原文及官方資料為準。

分享:WhatsAppThreadsTelegramFacebook