【從護理文書減壓開始，小醫院也能走出自己的GenAI落地方法】阮綜合揭自助式AI摘要生成和FHIR癌藥事審

「我們其實很缺護理人力！」阮綜合醫院資訊室主任陳保慶直言，這幾年全臺醫護人力吃緊，就連地方型的小醫院也難以倖免，不只影響醫療業務運作，也衝擊病人照護品質。

更大的問題在於，護理師有限的時間，還被大量文書工作占據。陳保慶指出，護理人員平均將近三分之一的工時，都花在電腦上填寫各式護理紀錄，經常因此延後下班，工作壓力越來越大。

為了替這群愈來愈稀缺的護理人員減壓，阮綜合醫院院長陳鴻曜在2024年6月拍板，啟動一項院級生成式AI（GenAI）計畫，鎖定流程重複、格式繁瑣的護理行政作業下手。這項計畫催生後來的「護理AI五部曲」，涵蓋從入院到出院最常見的5類護理紀錄，包括入院護理記錄、敘述性護理記錄、交班護理記錄、單位間交班記錄與出院護理記錄，明顯縮短護理師逐字謄打的時間。實際導入後，白班護理師平均每天可節省約30分鐘到1小時的工時。

GenAI應用瓶頸1：開發流程

身為高雄在地小醫院，阮綜合如何擁抱GenAI？

陳保慶回憶，2024年6月接下這項任務後，團隊決定先自行開發，由資訊室以C#打造護理專用的GenAI程式，並串接OpenAI的ChatGPT API，直到9月完成第一支「入院護理記錄」AI程式。

但在開發過程中，他們很快發現，生成式AI不能照傳統AI系統的開發流程來做。一般AI專案，會依序經歷需求提出、需求分析與資料準備、系統設計與模型選擇、測試驗證，最後才正式上線，而這些階段幾乎都需要資訊室全程投入。

問題是，「我們不只護理人力有限，IT人力也一樣有限。」陳保慶坦言，連IT組長都得親自下場寫程式。反覆測試、修正提示詞（Prompt），還要來回和醫護單位溝通需求，時間一久，開發負擔快速累積，成了實際的瓶頸。

為了減輕資訊室壓力，團隊改變做法，引進開源的無程式碼／低程式碼AI測試平臺，讓使用者先用假資料自行測試模型與提示詞的可行性，確認效果符合需求後，再交由IT團隊進行正式系統開發。

從此，阮綜合的GenAI開發模式也跟著定調：前段由使用者自行完成需求釐清、資料準備、模型選擇與驗證，後段再由資訊室負責系統設計、程式開發與上線。護理AI五部曲，正是在這樣的模式下逐步完成，後續也持續擴充。

GenAI應用瓶頸2：管理模式

開發流程順了之後，新的問題接著浮現——管理。

隨著AI功能愈來愈多，原本以C#元件、每支程式各自串接雲端服務的分散式架構，開始出現明顯負擔。像是Token控管、資安驗證都得重複處理，每個功能的提示詞又直接寫死在程式碼中，既不利於重用，也難以進行版本管理。

「我們需要一個像入口網站一樣的AI平臺，來集中管理所有AI功能，避免一直重複造輪子。」陳保慶說。

因此，團隊在2024年12月調整策略，找來外部廠商協助，將原本的AI 1.0分散架構，轉為集中式平臺管理。他們導入微軟的Azure OpenAI服務，並搭配digiRunner API Gateway，建立統一的AI應用入口與治理架構。

這樣一來，AI模型管理、Token控管、連線驗證等重複性高的安全機制，都交由API Gateway處理，資訊室則能把心力放在提示設計與功能開發上。

在平臺架構上，digiRunner採用Web UI與後端API分離的鬆耦合設計，提供單一入口、身分認證、權限控管與日誌紀錄等功能。相較過去的分散式元件，新架構讓不同應用能共用後端AI服務，也更容易導入提示治理與版本控管。既有的護理GenAI程式，也在此階段一併搬遷到新平臺上，並持續新增功能。

兩大GenAI亮點：醫師專用摘要和FHIR癌藥審查

在設計這套AI平臺時，團隊一開始就鎖定三個重點。

第一是流程設計，所有模組的UI操作邏輯都要一致、直覺，讓醫師或護理人員不用每用一個新功能就重新學習；對工程端來說，也能降低維護複雜度。第二是整合單一登入與資安機制，避免使用者在不同AI功能之間反覆登入，影響使用意願。

至於資料介接，考量院內醫療資訊系統（HIS）、護理資訊系統（NIS）等在初期尚未與AI平臺完全整合，團隊採取「先讓功能跑起來」的策略，透過複製貼上的方式使用AI產出的翻譯或摘要內容，先降低開發門檻與系統整合的複雜度。

在應用層面，智能搜尋魔板是最具代表性的亮點之一。這項功能專為醫師設計，整合多達15種常見病歷資料來源，例如不同時間範圍的住院病摘、檢驗報告、病理報告與醫師交班紀錄等，讓醫師自行勾選需要的資料，再搭配自訂提示詞，或從提示庫中選擇既有提示，產出符合個人需求的摘要內容。若某組提示效果特別好，也能回存到提示庫，供其他醫師使用。

陳保慶形容，相較於護理GenAI應用多半把提示詞寫死在程式裡，醫師的GenAI應用更像是「無菜單料理」，必須提供足夠彈性，讓醫師依需求自行組合資料與提示，產出客製化的摘要結果。

阮綜合醫院開發一款智能搜尋魔板，彙整了患者住院的15種病歷單張，供醫師選擇資料和區間，再透過提示產出摘要。

另一項關鍵應用，則是FHIR癌藥事前審查格式轉換。這項作法呼應健保署近年積極推動的FHIR政策。FHIR不僅是國際通行的醫療資料交換標準，也是政府鼓勵醫院導入的重要方向，而癌藥事前審查正是其中一項具體實作場域。

陳保慶說明，過去的癌藥事審多半由醫師填寫，大約只需完成15個欄位與摘要，其餘資料則以PDF附件上傳；但改為FHIR格式後，醫院必須將資料全面結構化，填寫多達106個欄位，且需對應ICD-10（國際疾病分類代碼）、LOINC（檢驗檢查代碼）、SNOMED CT（臨床術語代碼）等國際標準代碼，對人力有限的小醫院來說負擔相當沉重。

因此，阮綜合決定導入GenAI來協助這項工作，先根據既有病歷資料，推薦最合適的標準代碼；接著，再套用臺灣FHIR核心實作指引（IG）範本，請 AI 協助產生病歷資料對應範本的轉換程式，實作完整的FHIR癌藥事審流程。

陳保慶指出，這套作法已在院內驗證可行，最大價值在於，在IT人力有限、對FHIR還不夠熟悉的情況下，能透過AI協助「理解怎麼做」，並引導資訊人員完成轉換任務。

以初期應用為例，醫師可在AI平臺的癌藥事審模組中，透過病歷號搜尋患者資料，系統再依放射治療相關資訊推薦標準代碼。使用者完成必要編修後，即可轉換為FHIR格式並上傳至健保署。 這項癌藥事審FHIR轉換功能，最初僅支援放射治療項目；但隨著功能持續擴充，到了2025年底，FHIR轉換已涵蓋更多資料範圍，已完整實作且以FHIR上傳送件了。

阮綜合醫院也運用GenAI開發FHIR癌藥事審格式轉換功能，目前針對放射報告資料，可推薦合適的國際代碼、進行FHIR格式轉換。

下一步要擴大應用範圍

陳保慶指出，至2025年下半年，AI智能搜尋魔板以住院巡房資料為基礎，因此，應用範圍只限於病人住院當下。如果要進行跨門診、住院或長期追蹤的資料摘要，就會有所限制。於是，他們正思考可拉大資料區間的醫療單張優化設計。

除此之外，阮綜合團隊還在設計院內RAG知識庫，比如針對護理新進人員設計問答知識庫，來幫助新人迅速上手、減低工作壓力。但陳保慶透露，要建置這個知識庫，需要機器易懂的檔案類型和格式，比如QA形式的PDF或Markdown檔案，且需切分恰當的文字段落，才能提高準確率，這也是他們正在努力的方向。

小醫院的FHIR政策觀點

談到FHIR政策，陳保慶坦言，對地方型小醫院來說，確實是一大挑戰。資訊室成了政策對接窗口，還得跨部門協作、兼顧原本業務，加上FHIR與各類編碼的學習門檻高，都需要時間與誘因。 不過他也直言，醫院走向FHIR國際標準是大勢所趨，若政府直接要求醫院改以FHIR格式申報健保資料，會比推動FHIR癌藥事審更強而有力，醫院也會傾盡全力配合，IT阻力也會降低許多。