智慧醫療實況：那些沒寫在規格書裡的硬仗
我常跟同事在聊天時說，做智慧醫療產品，你得要應付兩種規格：一種是寫在專案管理軟體（如Jira）上的，另一種，是應付各種醫師「突發狀況」的規格需求，而在醫院這個極度複雜的場域，後者往往比前者更重要。
UpdatedMarch 24, 2026•1 min read
JJhihHao Wu**近期研究重點包含 AI Agent 的供應鏈攻擊、PII 偵測模型評估，以及醫療 AI 在臨床流程中的安全落地。
在這裡，我分享深度技術實測報告（如 NVIDIA NeMo, WildGuard）與職場技術成長心得，致力於在 AI 浪潮中打造具備資安韌性的解決方案。
On this page
智慧醫療實況：那些沒寫在規格書裡的硬仗實況一： 醫院評鑑與政府稽核實況二：產品主導權的「名存實亡」實況三：跨部門溝通的「語言轉換」實況四：在廠商們之間協調的「黑洞」實況五：一個功能，多個「宇宙」的設計難題實況六：API的「薛丁格的貓」
智慧醫療實況：那些沒寫在規格書裡的硬仗
我常跟同事在聊天時說，做智慧醫療產品，你得要應付兩種規格：一種是寫在專案管理軟體（如Jira）上的，另一種，是應付各種醫師「突發狀況」的規格需求，而在醫院這個極度複雜的場域，後者往往比前者更重要。
過去的經驗告訴我，再完美的產品路線圖（Roadmap），都頂不住醫院現場的瞬息萬變。
實況一： 醫院評鑑與政府稽核
「需要配合智慧醫院評級和審核，優先級最高，很容易打斷以往排期和計畫。」
這是所有醫院相關專案PM的惡夢，你的團隊可能正為了一個AI輔助診斷功能的上線，全力衝刺開發了三個月，但某個中午的院方午餐會議後，說兩個月後醫院要接受教學醫院評鑑，或是衛福部要來做稽核。
那一瞬間，原本規劃的所有專案排程都會被直接打斷，資訊室或是ＡＩ單位的頭頭會跑來告訴你：「那個AI專案先停一下，現在所有人力都要投入準備評鑑資料。」
在醫院，評鑑幾乎是「絕對命令」，它的優先級永遠是最高的（TOP Priority），這直接關係到醫院的聲譽、營運管理，身為產品管理者，你只能在一開始規劃年度計畫時，就主動去詢問醫院的評鑑時程，預先把這些「凍結期」考慮進去，並在合約中與院方明確定義，因配合評鑑所造成的專案延遲，責任該如何歸屬。
實況二：產品主導權的「名存實亡」
「溝通時產品主導權較薄弱，大多時候需要遵循醫院的需求。」
許多從資通產業或是科技製造業轉職的PM，習慣了「產品經理是產品的CEO」這樣的思維，但在醫院，多半時候這樣的想法會遭遇滿多的阻礙。
因為醫療的核心是「專業」與「安全」，最終使用並為結果負責的是院方的醫護人員。設計產品時想像的使用者體驗（UX）設計，可能在加護病房的護理長會覺得說「這個按鈕顏色太花俏，半夜精神不濟時可能會按錯」，有或者有些基於雲端的SaaS服務功能相當齊全，但基於資安考量，資訊室會堅持所有數據必須落地在院內機房（On-premise），那麼也得妥協。
在醫院，產品管理的角色更像是一個「需求翻譯官」與「解決方案顧問」，而不是「決策者」，你需要做的，是深入理解醫護人員的臨床情境與痛點，然後用專業來告訴他們「基於院方提出的需求，我建議可以用A、B、C三種技術方案來實現，它們各自的優劣是什麼」。把選擇權和最終決定權，禮貌地還給院方。
實況三：跨部門溝通的「語言轉換」
「醫院資訊室、醫師對資訊科技內容不一定理解，需要轉化為他們能懂的語言。」
當你興奮地跟影像科主任談你的AI模型用了最新的Transformer架構，AUC（Area Under Curve）高達0.95時，你可能只會看到他臉上禮貌而困惑的表情。
醫院裡的利害關係人，來自完全不同的專業領域。
資訊室關心的是：你的系統穩不穩定？安不安全？好不好維護？會不會佔用我太多伺服器資源？
管理單位關心的是：你的產品是否符合醫療法規？能否提高醫療品質、降低醫療糾紛？證據等級（Level of Evidence）夠不夠強？
第一線醫護人員關心的是：這個東西好不好用？會不會增加我的工作負擔？能不能真的幫到我？
對著資訊室，你要談API、談系統負載、談資安，對著管理權責人員，你要談臨床價值、談法規遵循，對著醫師，你要談如何融入他的工作流。
把「導入這個AI模型，可以優化營運效率」，轉譯成「主任，導入這套系統後，每位醫師平均每天可以節省半小時以上的打報告時間」。用他們能懂的語言和在乎的指標去溝通，專案才能推得動。
實況四：在廠商們之間協調的「黑洞」
「功能涉及到多家供應商時，協調極難，經常由於第三方延期。」
在醫院的日常，你可能需要整合外包系統，設備廠，或委外駐點人員來協助整合，你以為發個郵件給A、B、C三個廠商的窗口，大家開個會就能搞定。現實是，A廠商的工程師離職了，交接不清楚，B廠商的合約裡根本沒包含這個修改項目，要另外報價，C廠商的開發排程已經滿到半年後。
因此，每天的工作會變成就是打電話、發email，去追蹤各家廠商的進度。任何一家延期，你的整個專案就會跟著卡關，而且你還無能為力，給點血淚建議：
專案啟動會議（Kick-off Meeting）就要把所有廠商的「決策者」和「執行者」全部找來，當面敲定權責分工與時程，並留下白紙黑字的會議紀錄。
建立一個所有廠商都能看到的共享追蹤看板，讓進度透明化，彼此壓力才會均等。
永遠要有備案。如果A廠商的API開不出來，有沒有可能先從B廠商的資料庫用其他方式撈取？
實況五：一個功能，多個「宇宙」的設計難題
「設計一個功能時，會碰到多種不同用戶觀點的共同設計問題。」
想像一下，當你設計一個「遠距傷口照護」功能，這個功能至少就包含了三種使用者觀點：
病患端（通常是手機App）： 介面要極度簡單，引導長輩如何拍照、上傳。
醫師端（可能是Web或平板）： 需要清晰呈現傷口照片、歷史趨勢圖，並能紀錄醫囑或是相關需求。
管理端（給個管師或行政人員的Web後台）： 需要看到所有病患的列表、追蹤紀錄與數據報表。
這三個端的使用者、使用情境、核心需求完全不同，設計病患端時，你要化身為一個對科技陌生的80歲阿公，設計醫師端時，你又要變成一個忙到飛起、需要在30秒內做完判斷的醫師，這對產品設計的同理心與邏輯切換能力，是極大的考驗。
實況六：API的「薛丁格的貓」
「醫院無法提供資料的接口，開發周期就無法確認。」
這是大型醫院中最常碰到感到無力的情況，你規劃了一個完美AI模型，但核心功能需要一個HIS系統的資料接口（API）來借接推論過程所需的輸入資料，而資訊室卻跟你說：「現在沒有這個API，要請原廠開發。」
這時，你的專案時程就成了一隻「薛丁格的貓」 — 在原廠給出確切的開發時程與報價之前，它處於一種「生死未卜」的狀態，你完全無法對老闆或客戶承諾一個明確的交付日期（Deadline），可能要三個月，也可能要一年，甚至可能因為報價太高或是院方沒有編列預算而直接掰掰。
面對這種情況，要記得在專案初期進行「技術可行性評估」時，就把所有需要的接口一一列出，並與醫院資訊室「逐條確認」可用性，對於不存在的接口，必須將其列為專案的「高風險項目」，並提前規劃替代方案，哪怕那個方案很笨（例如，先手動匯出Excel檔再匯入），也比讓整個專案無限期等待來得好。
智慧醫療的產品管理，一半的時間在做產品，另一半的時間，其實是在做人、做溝通、做危機處理。
這些檯面下的硬仗，雖然充滿挫折，但也正是這個這個智慧醫療產品價值的體現。當你成功的最終讓產品順利上線時，那份成就感，將遠遠超過你畫出任何一張完美的產品藍圖。
Top comments (0)