Gemini for Healthcare 美國預覽：病歷唯讀、事前授權與醫療代理如何分工？

Gemini for Healthcare 面對的工作，常從看診前的病歷整理開始。醫療團隊需要對照用藥與歷次紀錄，再把保險要求的資料補齊。資訊散在不同系統裡，即使每份資料都找得到，串成能交給下一位同事接手的內容仍需時間。

Google Cloud 最新公布 Gemini for Healthcare 美國預覽，嘗試把醫療專用技能、資料連接與代理協作放在同一個工作環境。官方 X 帳號於 11 月 10 日介紹這項預覽，本文以 11 月 11 日查核到的官方公告與可用條件為準。

這次的重點是讓代理理解醫療工作流程，協助準備材料。它建立在既有 Gemini 代理能力上，加入醫療情境與合作夥伴服務，並沒有把一個會回答醫學問題的模型直接變成醫師。

醫療機構首先要確認的，是代理能讀到什麼、可以做什麼，以及誰負責採納結果。官方明列 Epic 與 Oracle Health 的電子病歷連接為唯讀，不能把整理紀錄說成直接回寫病歷。

這個界線影響了適合委派的工作：就診前整理、建立時間軸、彙整事前授權資料，都偏向先形成可審閱材料。至於臨床判斷、正式紀錄與保險核決，仍需要相應的人員與流程負責。

因此，這項預覽較值得從醫療文書協作理解。能否減少交接時的重複查找，並保留每項說法的來源，會比一次生成多少內容更接近醫療團隊的實際需求。

先分清醫療代理與診療決策

Gemini for Healthcare 的新能力主要放在醫療工作情境與材料整理，不能因為代理能執行多步工作，就推定它取得診療權限。醫療流程裡，同樣一段病歷可能被用來準備看診、核對給付或追蹤品質，目的不同，允許的動作也不同。

例如，就診前的病歷摘要需要找出相關紀錄，讓醫療人員快速定位原文。摘要可以幫忙減少翻頁，但如果把不同日期的用藥、暫定診斷與已確認結果混在一起，就可能改變閱讀者對病人的理解。

代理因此需要保留事件時間與來源，而不只是把文字寫得通順。醫療人員也應能從重要敘述回到原始紀錄，確認資訊是目前有效、歷史狀態，還是其他單位留下的待核資料。

Google 公告中的機構與合作夥伴談到探索方向、預期用途和工作需求，這些說明有助理解產品設計，卻不能視為已完成獨立臨床驗證。本文也沒有使用真實病人資料部署或測試這項服務。

要判斷代理如何形成這些材料，接著應看它把技能、資料與治理安排在哪些位置。這些組合會決定它能做到的工作，也決定出問題時能追查到哪一段。

Gemini for Healthcare 四層架構如何接進工作

官方把產品分成可重用技能、資料連接器、合作夥伴生態及受治理的平台四個部分。技能可以理解為已整理好的任務方法，讓代理依醫療需求處理資料，而非每次從一個空白聊天視窗開始。

連接器則負責把既有系統的資訊帶進工作流程。它的價值不是讓所有人突然看見所有資料，而是在原有角色與權限下取得需要的內容。資料來源不同，功能與可用狀態仍須分別確認。

合作夥伴服務補上部分醫療與保險情境，例如臨床知識、給付政策或資格資料。這能降低團隊自行組裝每一塊服務的負擔，但公告出現合作夥伴名稱，不等於所有服務都已對每個客戶正式開放。

平台層則處理代理身分、存取控制、操作紀錄與模型使用。Google 表示，代理可有自己的身分，並依使用者角色取得必要權限。這類設計能讓動作對回責任，但實際規則仍要由機構設定與檢查。

例如，一位負責準備就診資料的人員，不應只因開啟代理就獲得原本無權查看的紀錄。導入時需要把角色、資料種類與用途對起來，讓技術上的可連接，真正符合組織中的可使用。

若資料來源更新，團隊還需要知道既有整理結果是否仍可沿用。例如先前草稿引用的政策已換版，就應重新核對適用條件。能追查形成答案時所用的資料，才有辦法解釋前後兩次結果為何不同。

四層架構能描述能力從何而來，卻還不足以判斷實際風險。對醫療機構最直接的下一個問題，是電子病歷連接究竟允許讀取，還是也能修改。

病歷唯讀能做什麼

Epic 與 Oracle Health 的電子病歷連接在這次公告中明列為唯讀、沒有回寫。這個限制不代表代理沒有用途，而是把工作停在取得資訊、整理證據與形成可供人員審閱的材料。

以就診前準備為例，代理可以協助將分散紀錄排成縱向時間軸。使用者需要看到的不只有最後一段摘要，還包括重要事件發生的日期、資訊出自哪一次紀錄，以及哪些項目仍存在矛盾。

假如不同來源對同一件事有不同描述，合理的輸出應保留差異供人確認。把它們強行整成一個看似完整的答案，反而會掩蓋原本需要醫療團隊釐清的問題。

唯讀也意味著整理後的內容不會因此自動成為正式病歷。若人員決定採用，仍要經過機構既有的審閱、編輯與紀錄程序。不能把「已產生草稿」當成「已完成病歷更新」。

這裡的唯讀描述只適用官方明列的電子病歷整合，不能任意擴大成所有合作夥伴連接器都具有相同權限。機構必須逐項確認每個連接器的動作範圍與使用條件。

先整理、再核對、最後由負責人員採納的分工，也適用保險事前授權。這個流程的難處不只是把文件填完，而是讓每個主張都有合適的證據支持。

事前授權的草稿不等於核准

代理可協助彙整事前授權資料與申覆草稿，臨床審閱者仍須作出判斷。這類工作通常要把醫療紀錄與給付政策對照，確認申請材料是否回應了實際要求。

對提供醫療服務的一方，代理的用途可能是找出支持申請的紀錄，標示缺件，再整理成便於審查的文件。它不應把沒有找到的證據寫成已存在，也不能以語氣肯定取代資料完整。

對保險端，政策與資格資料可以幫助人員理解特定方案的保障條件。然而同一種服務在不同方案、地區或時間可能有不同要求，不能把一條概括答案套到所有被保險人。

若代理提出一段理由，審閱者應能看見它引用的政策版本與病歷證據，並確認兩者是否真的支持該主張。來源連結能縮短回查路徑，並不自動保證引用內容適用當前案件。

這也改變了衡量效率的方法。比較生成速度的同時，還需要記錄人員補件、修訂與重新核對的工作量。一份很快寫完但需要大量返工的草稿，未必讓整體流程更有效率。

當工作開始涉及醫療資料與保障條件，治理就必須跟著進場。身分、紀錄與可用範圍若不清楚，單靠更流暢的文件無法建立可信任的交接。

美國預覽與連接器限制

Gemini for Healthcare 目前是美國預覽，不能寫成台灣醫療院所已普遍可用。產品公告中的整合清單也具有不同成熟度，例如部分 Optum 連接能力仍標示為限制釋出或測試。

機構評估時應先確認自己需要的資料來源是否在支援範圍、現有合約與環境能否使用，再安排試辦。如果關鍵來源尚未開放，其他功能再完整，也可能無法形成可執行的工作流程。

Google 表示，服務的設計支援 HIPAA 合規需求，並提供稽核與治理能力。HIPAA 是美國醫療資訊保護相關規範。這描述的是可供機構使用的支援條件，不能簡化成所有導入方式都自動合規，或任何輸出都已符合臨床要求。

官方也說明，在組織受治理環境中的資料、提示與輸出，不會用來訓練或微調 Google 的基礎模型。實際採用仍應核對所用服務、連接器與合約的資料處理條件，保留組織自己的審查紀錄。

治理問題因此不只是能不能登入。代理以哪個角色取資料、哪些動作有紀錄、遇到不完整內容如何停止或交回人員，都會影響醫療團隊是否能放心把材料接下去。

當可用來源、角色與交接方式清楚後，第一次試辦就能縮小成一條具體流程。這會比直接要求代理承擔整段醫療業務，更容易確認它實際改變了什麼。

如何訂出第一次試辦的驗收

第一次試辦應檢查資料來源與人工修訂量，並把結果放回原有流程比較。較適合的起點，是目的明確、能由授權人員核對的資料整理工作，例如特定就診情境的準備材料。

團隊可以先定義一份合格材料必須包含哪些資訊，再檢查代理是否漏掉重要事件、混淆日期，或引用不相關紀錄。每個缺失要能對回來源，才能判斷問題在取資料、整理還是呈現。

還應安排會出現缺件與矛盾的案例，確認代理會保留問題交回人員，而不是自行補出不存在的內容。這類測試比只選資訊完整的示範，更能看見日常工作中的接手成本。

試辦期間也可記錄哪些任務必須中途交回人員，例如查不到應有紀錄、不同來源互相衝突，或引用政策不涵蓋該次服務。這些交接點若一開始就能辨識，團隊更容易安排誰接手，而不是等到文件最後一關才發現問題。

除了材料品質，還需觀察人員實際如何使用。若摘要看似完整，閱讀者卻找不到原文或不知道下一步交給誰，流程仍會回到人工重新查找。來源與責任應和文字一起交付。

當一條流程能穩定產生可追溯材料，且錯誤與缺件有明確處理方式，機構才有基礎評估擴大範圍。這次預覽值得追蹤的進展，也正在於代理能否進入這種可核對的協作，而非替代所有醫療判斷。

常見問題

Gemini for Healthcare 在台灣現在可以直接使用嗎？

官方公告的範圍是美國預覽，沒有據此確認台灣普遍開放。機構仍須向服務提供方核對地區、環境、連接器與合約條件，不能只因Google其他產品在台灣可用，就推定此服務同樣開放。

代理會把整理結果寫回電子病歷嗎？

這次明列的 Epic 與 Oracle Health 病歷連接為唯讀，沒有回寫。人員若要把整理內容納入正式紀錄，仍須依既有流程審閱處理。其他整合則需各自確認權限。

延伸閱讀：ChatGPT 正式串接 Epic 電子病歷：醫療 AI 不只會回答問題，開始進入醫院工作流程

延伸閱讀：Google 醫療 AI 證書新課程：四課學什麼、US$49 與五點 CME 怎麼看

原始資料來源

• Google Cloud：Gemini for Healthcare
• Google 官方產品介紹
• Google Cloud 官方 X 貼文與影片