泥沼與曙光： 醫院裡「複雜的資訊系統生態」
聊到智慧醫療，大家想到的可能都是頂尖的AI模型、精準的基因檢測，但最頭痛且接地氣的問題是— 醫院內部那堆「複雜的資訊系統生態」。
UpdatedMarch 24, 2026•1 min read
JJhihHao Wu**近期研究重點包含 AI Agent 的供應鏈攻擊、PII 偵測模型評估，以及醫療 AI 在臨床流程中的安全落地。
在這裡，我分享深度技術實測報告（如 NVIDIA NeMo, WildGuard）與職場技術成長心得，致力於在 AI 浪潮中打造具備資安韌性的解決方案。
On this page
泥沼與曙光： 醫院裡「複雜的資訊系統生態」挑戰一：供應商的「聯合國會議」溝通成本挑戰二：想從HIS拿資料？抱歉，我們沒有API挑戰三與曙光：數據中台/平台與FHIR標準的興起挑戰四：數據的拼圖遊戲
泥沼與曙光： 醫院裡「複雜的資訊系統生態」
聊到智慧醫療，大家想到的可能都是頂尖的AI模型、精準的基因檢測，但最頭痛且接地氣的問題是— 醫院內部那堆「複雜的資訊系統生態」。
舉個大家可能比較能夠體驗的例子，大台北的捷運系統是由是數十個不同時代、不同規格的鐵軌拼接而成。無論捷運車廂的性能再好，運量再大，若無法彼此良好的串接，跑不起來也沒用。
因此，如果你的智慧醫療產品要能落地，首先就要學會在這片泥沼中游泳。
挑戰一：供應商的「聯合國會議」溝通成本
「一個區域醫院可能有上百個軟硬體系統供應商，意味著一個功能保底需要和兩三家供應商溝通是常態。」
這句話完全不是危言聳聽，而是血淋淋的日常，正常來說，一家中等規模的綜合科別醫院，其資訊系統可能由A廠商的HIS（醫院資訊系統）、B廠商的EMR（電子病歷）、C廠商的PACS（影像儲存與傳輸系統）、D廠商的LIS（檢驗系統），再加上數十個不同科室自行採購的專科系統和醫療設備軟體所組成。
因此，當你的AI專案或是產品開發時，需要同時用到醫囑、病歷和影像資料時，你面對的就不再只是一個窗口，而是一場供應商的「聯合國會議」。每一家廠商的系統架構、數據格式、開發排程都不同。光是釐清數據欄位的定義，就可能耗上數週。
比如過去為了開發一個手術風險預測模型，我們需要從HIS抓取病患基本資料、從EMR取得過去病史，再從PACS調閱術前影像。這些看起來很簡單的需求，中間足足開了兩個月的大小會議。A廠商的工程師說他們的系統輸出資料要排程開發；B廠商擔心資料被拿走會有責任問題，要求簽署複雜的法律文件；C廠商的系統較舊，根本沒有API可以介接…
一個稱職的PM，必須是個優秀的「外交官」，懂得如何周旋在各個供應商之間，釐清權責、建立信任，並將所有技術細節與時程整合成一份可行的作戰計畫。
挑戰二：想從HIS拿資料？抱歉，我們沒有API
「直接從HIS獲取數據，進行對接和研發，沒有API或是對接的Interface，都需要自己做。」
HIS系統通常是醫院最早導入、也最核心的系統，掌管了掛號、計價、醫囑等關鍵流程。但也因為歷史悠久，在台灣，很多醫院的HIS都是二三十幾年前開發的「骨董級」產品，其架構封閉，根本沒有現代軟體所謂的API（應用程式介面）概念。
因此，通常技術團隊只能「自己動手，豐衣足食」XD
資料庫層級撈取（Database-level extraction）：在取得院方資訊室嚴格授權後，直接連進HIS的後端資料庫，用SQL語法把資料「撈」出來。這種方式風險極高，一不小心可能影響到線上系統的運作，而且你需要花費大量時間去逆向工程，理解每個資料表和欄位的意義。
檔案交換（File exchange）：這是比較常見的折衷方案。請HIS廠商或醫院IT人員，定期（例如每天半夜）將特定資料打包成CSV或TXT檔，放到一個指定的FTP伺服器上，你的系統再去抓取。這種方式雖然相對安全，但缺點是資料有延遲，無法做到即時應用。
無論哪種方式，在開發產品時都必須認知到，從0到1建立數據通道，是專案的常態，而非例外。
挑戰三與曙光：數據中台/平台與FHIR標準的興起
為了解決上述的串接惡夢，一些有遠見的醫院或系統整合商，開始建置所謂的「數據中台」。這個平台預先跟後端五花八門的系統（HIS、EMR、PACS…）打通關，然後將這些雜亂的數據，清洗、整理成統一格式，再透過標準化的API提供給前端的AI應用程式使用。
對開發新產品來說，只需要對接這個單一的平台即可。這大大降低了開發門檻與時間成本。而讓這件事從「理想」走向「標準化現實」的關鍵推手，就是衛福部近年來大力推動的FHIR（Fast Healthcare Interoperability Resources）。
FHIR是國際上新一代的醫療資訊交換標準，它採用了現代網路通用的RESTful API架構，將每一筆醫療資料（如病患、過敏史、藥物）都定義成一個「資源（Resource）」，讓不同系統之間可以用極其高效、標準化的方式溝通。
衛福部成立了「電子病歷互通推動辦公室」，並在各大醫院推廣「臺灣核心實作指引（TW Core IG）」，目標就是希望未來所有醫院的資訊系統，都能說FHIR這種「共同語言」。
挑戰四：數據的拼圖遊戲
「需要從多家供應商內獲取數據，例如HIS、EMR、PACS、醫院醫療設備裡獲取數據。」
即便有了FHIR這樣的標準，產品設計的挑戰也還沒結束。一個完整的臨床AI應用，往往需要的是一幅完整的「數據拼圖」。
HIS 提供病患的身份和就診紀錄。
EMR 記錄了醫師的文字病程描述與主訴。
PACS 儲存了關鍵的醫療影像證據。
LIS 包含了血液、生化的檢驗數值。
甚至連手術室的生理監視器、加護病房的呼吸器，這些醫療設備本身也都在不斷產生即時數據。
最難的就是將這些來自不同源頭、不同格式的數據，在正確的時間點上，拼湊起來，形成一個有意義的「病患360度視圖」，這通常需要熟悉相關療程與極其細緻的數據治理（Data Governance）規劃，確保數據在串接過程中的一致性、準確性與及時性。
— —
在智慧醫療的賽道上，技術領先固然重要，但是能夠駕馭複雜系統、打通資料串接血脈的PM，才是決定產品生死的關鍵人物。除了加速開發，後續驗證流程有都會產生極大得價值。
在產品開發的同時，學會欣賞醫院資訊系統的「歷史共業」，把它當成一個待解的謎題，並且擁抱FHIR這樣的標準化浪潮，才能穿越這片泥沼，走入臨床，創造價值。
Top comments (0)