這套東西賣的是行政流程，不是診斷。醫院省下的是查資料與填表格的時間，病人要面對的是病歷被拆開來看的方式。
Gemini for healthcare 是什麼：四個零件組成的代理層
Google Cloud 本週發布 Gemini for healthcare，執行長 Thomas Kurian 把它定位成為醫療產業特製的解決方案，延伸 10 月 Gemini at Work 發表的通用代理。這是 Google Cloud healthcare AI 走進特定產業的一次嘗試，目前是預覽版。官方部落格掛的日期是 11 月 11 日，其他報導寫 11 月 10 日，記成 11 月初就好。
它的組成分四塊：由領域專家寫好的醫療技能、連接臨床與財務系統的連接器、開放的合作夥伴生態，以及一個可以在不同模型之間調度的治理平台。
技能與連接器是兩種東西。技能是「這件事該怎麼做」的步驟，例如怎麼把一份授權申請湊齊；連接器是「資料在哪」的通道，例如電子病歷（EHR）、理賠與排程系統。少了後者，前者只能空轉。
agentic layer 管的四件事：身分、權限、邊界、稽核
Google 說每個代理都有自己的身分，繼承使用者既有的角色權限，並在使用者、子代理與工作流程之間執行需要才知道的邊界。
聽起來抽象，實際意思是代理不能因為跑得快，就看到它不該看的病歷。所有存取會留下稽核紀錄，回答也附上可查證的引用，讓審查者有東西可對。
醫院端的 prior authorization 流程怎麼被拆開
醫院端最實際的改變在事前授權。產品會在送出前，依付款方政策把授權包組好；被拒絕時，可以依臨床紀錄與保單條款起草申訴。
其他流程還包括跨越時間的病人時間軸，把進行中的問題與已解決的問題分開，並標出用藥不一致的地方；看診前的病歷準備；以及付款方那一側，把進來的申請對照醫療政策，整理給臨床審查人員。
付款方那一側還有一項常被忽略的工作：向保戶解釋給付與費用，依據是保戶自己那份保單文件。這聽起來像客服，實際上佔掉保險公司大量人力。
HIPAA 與「支援合規」之間差在哪
Google 的說法是這套平台設計用來支援 HIPAA 合規，具備企業級存取控制、端到端稽核紀錄與可驗證引用。它沒有說自己通過認證。
這個差別在採購時很具體。支援合規代表工具幫得上忙，責任仍在醫療機構身上；認證則是把責任往廠商推一步。
那醫院到底在怕什麼？怕的是查核時拿不出紀錄，而不是模型答錯一題。
平台還有一個設計值得注意：Google 說機構可以在同一套治理層之下，把自家的前沿模型與合作夥伴的模型混著用。對已經簽了其他模型合約的醫院，這比「只能用 Google」實際。
28 小時這個數字，是 Google Cloud 自己的說法
Google 說臨床人員每週花將近 28 小時手動核對分散在各系統的資訊。這是 Google 的數字，不是獨立研究。
即使打折看，這個數字指向的問題是真的：醫院的資料散在掛號、檢驗、影像、藥局與申報系統裡，而人得在中間當橋。
台灣醫院導入 Gemini for healthcare 會先問的四個問題
第一個是資料放在哪。台灣醫院對病歷資料的在地規範與個資法要求，會直接影響能不能用境外雲端。
第二個是支援哪幾套電子病歷系統。第三個是預覽版要花多少錢，Google 沒有公布。第四個最難答：代理把政策讀錯時，責任算誰的。
規模也會決定答案。區域醫院與大型醫學中心的資訊部門人數差很多，前者常常只有幾個人要同時顧掛號、影像與申報，沒有餘力再做一套整合。診所更直接，多半只能等廠商把功能包進既有的系統裡。
台灣的制度對應物是健保申報與特定檢查的事前審查，護理與行政人員的負擔同樣存在。工具能不能落地，最後還是看這四個問題有沒有答案。
對醫院來說，下一步很具體：先確認自家電子病歷的版本與資料存放地點。這兩題有答案，其餘的採購與資安討論才有得談。
