本文重點
- 醫療行政負擔的根因不是流程懶散，而是系統設計當初沒有把資料流納入考量
- 解行政問題，是解「醫療人員可以花更多時間在病患身上」這個更根本的問題
- 問題定義清楚了，才能判斷 AI 工具切入的位置是否對準痛點
- 行政 AI 和臨床 AI 有什麼根本差異？
- 行政 AI 處理的任務有明確的完成標準，例如文件格式正確、編碼與診斷對應；臨床 AI 處理的是需要專業判斷的問題，例如症狀最可能的診斷方向。前者可以由人快速確認，後者的錯誤後果更嚴重，監管要求也高出許多。這是兩者在導入複雜度與監管路徑上差距最大的地方。
- FHIR 標準推廣多年，為什麼醫療系統之間還是難以整合？
- FHIR 定義了格式，但沒有強制各系統按照相同的深度實作。不同廠商的實作程度不同，現場資料品質也不同。更重要的是，整合需要的不只是技術對接，還有跨機構的資料授權、隱私合規與長期維護成本，這些都是標準本身無法解決的問題。
- 什麼樣的機構最適合優先導入行政 AI？
- 有以下特徵的機構通常最適合作為起點：有清楚可量化的行政痛點（例如預約等待時間長、編碼錯誤率高）；有一定的 IT 基礎設施支撐 API 整合；有願意參與流程重新設計的臨床與行政人員。如果這三個條件都不具備，應先補基礎，而不是急著選工具。
很多人在談醫療 AI 的時候，第一個反應是輔助診斷、醫學影像辨識，或是讓 AI 協助臨床決策。這個方向聽起來更有突破感，也是過去幾年討論的主軸。
但如果去看近期大廠的實際動向，會看到一個明確的轉向：先從行政流程下手。
CVS Health 與 Google Cloud 宣布合作推出 Health100 健康 AI 平台，核心是整合多來源健康資料，提供即時決策工具；AWS 在相近時間推出面向醫療行政工作的 agentic AI 平台，直接切入預約管理、病史整理、臨床文件撰寫與醫療編碼四個場景。
這不是巧合，也不只是商業策略上的保守選擇。要理解這件事，要先把問題本身定義清楚。
一、行政工作才是醫療機構的核心瓶頸
行政與文件工作佔用了醫療人員大量時間，這是整個系統最可量化、也最普遍存在的瓶頸。 根據美國醫師協會（AMA）的調查，醫師平均每週花在電子病歷填寫與行政溝通的時間，已超過直接照護病患的時間。這不是個別醫院的效率問題，而是系統性結構問題。
這裡要先問一個更前面的問題：為什麼行政工作這麼重，而且問題長期沒有解決？
表面上看起來是流程沒有優化。但往更根本的層次追，會發現一個更重要的原因：大多數醫療機構的電子病歷系統（EHR）是在紙本流程的基礎上數位化，而不是從頭重新設計流程再選工具。結果是，臨床人員在照護病患之外，還同時要扮演資料輸入員的角色——這個角色從來不是他們應該承擔的工作。
問題如果沒定義清楚，後面的方法就會解錯題。真正要解的，不是「怎麼讓醫師輸入資料更快」，而是「怎麼讓醫師不需要自己輸入那麼多資料」。這兩個問題的解法差距很大。
重點摘要
- 醫療行政負擔的根因不是流程懶散，而是系統設計當初沒有把資料流納入考量
- 解行政問題，是解「醫療人員可以花更多時間在病患身上」這個更根本的問題
- 問題定義清楚了，才能判斷 AI 工具切入的位置是否對準痛點
二、大廠同時押注行政端的三個條件
行政場景具備讓醫療 AI 商業化最快的三個條件：資料結構化程度相對較高、成效可量化、監管風險相對低。 這三點在臨床決策 AI 上都困難得多。
條件一：資料結構化程度
行政資料——預約紀錄、保險申報碼、費用結算、病歷摘要——雖然分散在不同系統之間，但格式相對統一。臨床資料（診斷推論、治療決策、醫師的思考路徑）則高度個人化，且大量存在於非結構化的自由文字中。AI 在結構化資料上能夠更快建立可信任的輸出，也更容易設計人工確認機制。
條件二：成效可量化
行政 AI 的成效可以直接計算：文件完成時間縮短多少、編碼錯誤率降低多少、預約流程減少幾個接觸點。這種可量化的 ROI，是機構內部推動導入時最容易說服決策層的條件。臨床決策 AI 的成效評估需要更長的追蹤周期，也更難排除其他變因的干擾。
條件三：監管風險相對低
在行政流程中，AI 的角色多數是「輔助生成草稿」或「自動彙整資料」，最終由人確認送出。這類設計迴避了「AI 直接做醫療決策」的監管問題。臨床決策 AI 則面對美國 FDA 的 AI/ML 醫療器材審查框架，從申請到取得許可的周期長出許多。
「數位健康工具最容易在能夠清楚定義成效指標的場景取得進展，行政效率恰好是這類場景的代表。」——麥肯錫全球研究院《數位健康的未來》報告（2024）
三、Health100 與 AWS 代表的兩種問題定義
Health100 走的是資料整合與橫向平台路線，AWS 走的是 agentic AI 垂直工作流路線。兩種架構背後，是對問題的不同定義。
Health100 的核心假設是：健康資料太分散，缺乏整合平台是瓶頸。設計目標是把來自不同來源的健康資料（保險理賠、藥局用藥、診所量測、可穿戴裝置）整合在一起，讓使用者和照護提供者能看到較完整的健康輪廓，並提供即時工具介入。
AWS 的方向是任務導向：定義明確的行政工作項目（預約管理、病史整理、臨床文件、編碼），讓 AI agent 完成特定步驟、生成草稿，減少人工介入的環節數。Agentic AI 的特點是能夠在設定的範圍內自主執行多個步驟，不需要使用者逐步下指令。
| 面向 | Health100（CVS + Google Cloud） | AWS 醫療行政 AI |
|---|---|---|
| 核心假設 | 資料整合是最大瓶頸 | 行政工作步驟太多太繁瑣 |
| 定位 | 橫向資料平台 + 工具整合 | 垂直任務 agentic AI |
| 使用者 | 病患 + 照護提供者（雙向） | 行政人員 + 臨床人員（後台） |
| 資料輸入 | 多來源整合（保險、藥局、診所、穿戴） | 院內系統（EHR、排程、編碼） |
| 成效衡量 | 健康資料完整性、使用者參與度 | 任務完成時間、錯誤率 |
| 主要挑戰 | 跨系統資料授權與品質一致性 | 工作流適配與人工確認機制設計 |
這兩種架構並不互斥。但它們背後的問題定義不同，適合的機構條件也不同。比較兩者優劣之前，應該先問的是：自己機構的核心瓶頸，是資料分散整合困難，還是工作流程環節太多效率太差？
四、行政 AI 落地的資料條件與常見卡點
導入卡點通常不在技術選型，而在資料品質、系統介接與人工確認機制這三個地方，而且這三個問題在規劃期常常被低估。
卡點一：資料品質
AI 的輸出品質取決於輸入資料的品質，而醫療機構的行政資料品質參差不齊。同樣是「病患病史」，在不同系統中可能格式不同、欄位定義不同、更新頻率不同。把品質不穩定的資料直接餵給 AI，輸出的摘要或文件就會帶著這些偏差。
這裡有一個跟標準化相關的重要背景：FHIR（Fast Healthcare Interoperability Resources，快速醫療互操作資源）是由 HL7 International 制定的醫療資訊交換標準，目標是讓不同系統之間以統一格式交換資料。FHIR 的基本單位是 Resource，每種資料類型有對應格式，例如 Patient（病患基本資料）、Observation（量測數值）、MedicationRequest（用藥指示）。
問題是，FHIR 定義了格式，但無法保證填入的資料品質。現場系統的實作深度也參差不齊，中小型醫療機構的 EHR 系統可能不支援完整的 FHIR API 介面。
卡點二：系統介接
多數醫療機構的 IT 環境由多個年代的系統疊加而來，整合成本常被低估。AI 平台要取得排程、病歷、保險系統的資料，每個介面都可能需要個別的整合工作，而且整合工作完成後還需要持續的維護。
卡點三：人工確認機制設計
行政 AI 生成的文件、編碼建議或摘要，最終需要人確認才能送出。這個確認步驟的設計，直接影響實際節省的時間量。如果確認界面設計不好，醫療人員花在確認 AI 輸出的時間，可能跟過去手動操作的時間相差不多。
「醫療 AI 的落地挑戰，往往不在於模型本身是否夠強，而在於系統整合與臨床工作流程的重新設計。」——史丹佛大學醫學院數位健康中心，《AI 在醫療導入的障礙分析》（2023）
五、評估行政 AI 導入前，應先釐清的問題
最重要的準備是把問題本身定義清楚：要解的是什麼問題、問題的根因是什麼、現有的資料和流程條件能不能支撐這個工具。 工具選型應該排在最後，而不是最前面。
可執行步驟
以下是評估行政 AI 導入時，可以依序釐清的判斷步驟：
步驟一：列出最耗時的三個行政場景
具體描述問題：是哪個流程、誰在做、每次花多少時間、現在的錯誤率大概是多少。沒有具體問題描述，就無法判斷 AI 切入哪個環節最有效。
步驟二：追問問題的根因
這個流程耗時，是因為「步驟太多」、「資料太分散」，還是「人力配置不足」？不同原因需要不同工具，搞錯方向只是換一套工具繼續卡住。
步驟三：清查資料來源與品質
這個工作流程需要哪些資料？資料在哪個系統？格式是否一致？更新頻率如何？資料本身有問題的話，AI 不會解決問題，只會放大問題。
步驟四：確認角色與責任分工
AI 輸出之後，誰負責確認？確認流程要多少時間？出錯時責任歸屬如何界定？這些問題如果沒在導入前釐清，後續治理很難建立。
步驟五：設定可量化的基準指標
導入前先記錄 before 數字（文件完成時間、編碼準確率、預約等待天數）。沒有基準線，就無法在導入後判斷改善幅度是否達到預期。
六、行政端是起點，不是終點
行政 AI 的最終價值，不只在於節省行政時間，而在於逐步建立讓臨床 AI 能夠運作的資料基礎。 這一點在多數討論中被跳過，但它才是這波大廠投入的更長遠邏輯。
臨床 AI 需要高品質、一致性強、來源可追溯的資料。但現在多數醫療機構的臨床資料，正是因為行政系統問題而殘缺、分散或格式不一。先把行政端的資料流整頓好，才能逐步建立臨床 AI 可信任的輸入環境。
這個脈絡也解釋了為什麼 CVS+Google 和 AWS 在這個時間點選擇行政端：行政 AI 本身有可量化的 ROI，同時也是未來更複雜臨床應用的基礎設施建設。這兩個目標可以同時推進。
反過來說，如果機構跳過行政端的整頓，直接嘗試導入臨床 AI，大概率會在資料品質和系統整合上遇到更大的阻力。順序很重要。
真正有效的設計，是能從源頭減少問題發生，而不是在問題發生之後才想辦法補救。從行政端開始，就是這個邏輯的體現。
重點摘要
- 行政 AI 的成效可量化，是它商業化最快的核心優勢，也是最適合的切入點
- 資料品質與系統介接是落地的主要卡點，不是技術選型本身
- 行政端的整頓，是臨床 AI 資料基礎的前置工作，兩者是順序關係
- 評估工具前先評估問題：問題、原因、方法、最好的做法，順序不能倒置
延伸參考：
行政 AI 和臨床 AI 有什麼根本差異？
行政 AI 處理的任務有明確的完成標準，例如文件格式正確、編碼與診斷對應；臨床 AI 處理的是需要專業判斷的問題，例如症狀最可能的診斷方向。前者可以由人快速確認，後者的錯誤後果更嚴重，監管要求也高出許多。這是兩者在導入複雜度與監管路徑上差距最大的地方。
FHIR 標準推廣多年，為什麼醫療系統之間還是難以整合？
FHIR 定義了格式，但沒有強制各系統按照相同的深度實作。不同廠商的實作程度不同，現場資料品質也不同。更重要的是，整合需要的不只是技術對接，還有跨機構的資料授權、隱私合規與長期維護成本，這些都是標準本身無法解決的問題。
什麼樣的機構最適合優先導入行政 AI？
有以下特徵的機構通常最適合作為起點：有清楚可量化的行政痛點（例如預約等待時間長、編碼錯誤率高）；有一定的 IT 基礎設施支撐 API 整合；有願意參與流程重新設計的臨床與行政人員。如果這三個條件都不具備，應先補基礎，而不是急著選工具。
agentic AI 和一般 AI 助理有什麼不同？
一般 AI 助理是對話導向，使用者主動輸入問題，AI 輸出回應。Agentic AI 是任務導向，AI 可以在設定的範圍內自主執行多個步驟（例如：讀取預約資料 → 查詢保險條件 → 草擬確認信件），不需要使用者逐步指示。在行政流程中，agentic AI 可以大幅減少人工操作的環節數，但也需要更嚴格的邊界設定，避免 AI 在沒有確認的情況下執行關鍵操作。
台灣的醫療機構在評估這類工具時，還需要額外注意什麼？
台灣的《個人資料保護法》對醫療資料的跨機構使用有明確規範，導入前需確認資料授權範圍。此外，健保署的申報編碼有特定的在地規格，不能直接對應國際標準版本，工具是否支援台灣健保編碼體系需要個別確認。資料存放位置是否符合本地法規（境外儲存限制），也是評估雲端平台時需要提前確認的事項。
About the Author
