從需求到真正被使用
醫療資訊系統、AI 與智慧醫院的整合思維
掃描 QR Code，將這份內容帶回去繼續閱讀
今天現場的介紹只是開始。 如果想在參訪之後重新整理 Workflow（工作流程）、 Platform（平台）、 FHIR（快速醫療照護互通資源）、 AI（人工智慧） 與 Vibe Coding（自然語言驅動的人工智慧輔助程式開發）等概念， 可以掃描 QR Code 開啟本頁。
建議可以先把網頁加入瀏覽器書籤， 之後再回來查看專有名詞解釋與完整內容。
醫療資訊不是單純的 Information Technology（資訊科技）問題， 而是 People（人）、 Workflow（工作流程）、 Data（資料）、 System（系統）、 Communication（溝通） 與 Governance（治理） 必須同時被考慮的整合問題。
01｜為什麼醫療資訊系統這麼難？
假設一家醫院花了很多時間與經費開發一套系統。 功能全部完成、程式也沒有明顯錯誤， 但是醫師、護理師與其他醫療工作者不願意使用。
從工程角度來看，它可能已經「完成」； 但從醫療現場來看，它可能完全沒有創造價值。
醫療資訊真正追求的並不是單純的 System Go-live（系統正式上線） ， 而是系統能否真正進入 Clinical Workflow（臨床工作流程） ， 讓工作變得更快、更安全、更一致， 或者減少不必要的負擔。
Clinical Workflow（臨床工作流程）是什麼？
這個順序很重要。 真正好的醫療資訊設計， 應該先理解問題，再選擇技術； 而不是先拿到一項新科技， 再思考「醫院哪裡可以放進去」。
↑ 回到目錄02｜醫療資訊系統真正服務的是 Workflow（工作流程）
Workflow（工作流程） 指一件工作從開始到完成， 中間涉及的人、資料、判斷與動作。
例如護理給藥並不是「按下一個按鈕」而已， 而是一連串實際工作：
因此， 一個在一般軟體裡看似無關緊要的 Click（點擊）， 如果每天必須重複幾十甚至上百次， 就可能成為很明顯的工作負擔。
醫療資訊系統不是只在管理資料； 很多時候， 它其實是在重新設計工作流程。
03｜臨床端與工程師為什麼常常互相聽不懂？
醫療資訊專案中最常出現的問題之一， 就是 Clinical–Engineering Communication（臨床與工程溝通） 。
臨床端可能會說
「這個很不好用。」
「我要自動化。」
「幫我把資料抓出來。」
「跟現在流程一樣就好。」
「這個應該很簡單吧？」
工程師真正需要知道
User（使用者）是誰？
Trigger（觸發條件）是什麼？
Input（輸入）是什麼？
Output（輸出）是什麼？
Data Source（資料來源）在哪裡？
Permission（權限）怎麼設定？
Exception（例外狀況）如何處理？
反過來， 當工程師開始談 API（Application Programming Interface，應用程式介面）、 Schema（資料綱要）、 Endpoint（服務端點）、 Frontend（前端）、 Backend（後端） 或 Permission Model（權限模型）， 臨床人員也很可能只想知道：
兩邊不一定有誰錯了。 真正的問題常常是： 大家正在不同的 Abstraction Level（抽象層級） 談同一件事情。
Translation Layer（翻譯層）：為什麼醫療資訊需要「翻譯」？
04｜Requirement（需求）不等於 Solution（解決方案）
使用者如果說：
這通常還不能稱為真正的 Requirement（需求）， 而比較像是使用者已經自行想到的一個 Solution（解決方案）。
Requirement Engineering（需求工程）是什麼？
需求訪談更應該問什麼？
先完整理解目前的 Clinical Workflow（臨床工作流程）。
找出真正的 Pain Point（痛點）。
是重複輸入、等待、找不到資料、資訊散落， 還是流程本身不合理？
區分真正必要的流程與歷史留下來的流程。
這會決定它是一個單位功能， 還是一個有機會 Platformize（平台化）的共同需求。
05｜Prototype（原型）不是答案，而是溝通工具
很多傳統資訊專案會走成：
工程師則可能回答：
如果這個循環持續發生， 最後受傷的不只是專案， 而是臨床與資訊團隊之間的信任。
Prototype（原型）與 Iteration（迭代）
Iteration（迭代） 則是透過「測試 → 回饋 → 修改 → 再測試」 反覆改善產品。
原型的價值不是一次做到完美， 而是越早讓真正使用者看到， 越早發現彼此理解是否一致。
真正危險的是花了半年把第一版做到「完整」， 才第一次讓真正的使用者看到。
06｜Low-code（低程式碼）把工具交給使用者，就解決問題了嗎？
因此出現了 Low-code（低程式碼開發）、 No-code（無程式碼開發） 與各種視覺化應用開發工具。
Low-code、No-code 與 Citizen Developer 有什麼不同？
No-code（無程式碼開發） 更強調不直接撰寫程式， 透過拖拉元件與規則設定完成應用。
Citizen Developer（公民開發者／非專職開發者） 則是本職不是工程師， 但利用這類工具建立數位應用的人。
≠
知道如何設計 Information Architecture（資訊架構）
≠
知道如何設計一個好產品
更有效的方式， 往往是先做出一個成功案例， 再把其中可重複使用的部分整理成 Template（範本） 或 Reusable Component（可重複使用元件）。
07｜從 Application（應用程式）走向 Platform（平台）
Application（應用程式） 解決一個具體問題； Platform（平台） 則讓更多應用可以建立在共同基礎上。
Platform（平台）真正的價值是什麼？
08｜從 Windows、iOS 到智慧醫院：為什麼 Platform（平台）重要？
PC（Personal Computer，個人電腦）時代， Windows（微軟視窗作業系統） 與 macOS（蘋果電腦作業系統） 建立共同的作業環境。
行動裝置時代， iOS（蘋果行動作業系統） 與 Android（安卓行動作業系統） 不只是 Operating System（作業系統）， 更形成龐大的 Application Ecosystem（應用生態系）。
Ecosystem（生態系）與 Platform（平台）有什麼不同？
Ecosystem（生態系） 則是平台、使用者、開發者、資料、服務與應用之間 逐漸形成的互相促進環境。
平台夠容易使用， 開發者就更願意開發； 應用越多， 使用者越願意加入； 使用者越多， 又產生更多新的需求。
09｜從 EHR（電子健康紀錄）到醫療應用生態系
Epic 可以作為一個大型 Electronic Health Record（電子健康紀錄，EHR） 如何逐漸形成 Platform（平台） 與 Ecosystem（生態系）的案例。
Stable Data Core（穩定資料核心）
大型醫療平台若要支援眾多應用， 底層必須先有一致、可靠的資料架構。Ambient AI（環境式人工智慧）
AI 不一定是一個額外網站， 而可以直接融入醫病對話、 病歷產生與工作流程。Clinical Data Reuse（臨床資料再利用）
臨床資料除了支援當下照護， 在適當 Governance（治理）下， 也可以支援 Research（研究）、 Quality Improvement（品質改善） 與資料分析。Application Ecosystem（應用生態系）
透過標準化介面與整合機制， 第三方或院內應用可以建立在既有 EHR 基礎上。10｜FHIR（快速醫療照護互通資源）為什麼重要？
Fast Healthcare Interoperability Resources （快速醫療照護互通資源，FHIR） 是醫療資訊交換的重要標準。
FHIR 可以怎麼理解？
它並不是另一套電子病歷， 而是降低不同系統之間 Data Exchange（資料交換） 與 Application Integration（應用整合） 障礙的一種標準。
病人基本資料
生理量測或檢驗結果
用藥相關資料
SMART on FHIR （基於 FHIR 的智慧醫療應用整合框架） 則進一步讓新的 Application（應用程式） 可以在既有醫療資訊環境中， 取得使用者身分、 病人 Context（情境資訊） 與被授權的臨床資料。
↑ 回到目錄11｜美國、歐洲與台灣：不同的醫療數位化路徑
不同醫療體系在 Standardization（標準化）、 Cost（成本）、 Autonomy（自主性）、 Speed（速度） 與 Governance（治理） 之間會做不同取捨。
| 地區 | 主要推動力量 | 可能優勢 | 主要挑戰 |
|---|---|---|---|
| 美國 | 大型 EHR 商業平台與 Application Ecosystem（應用生態系） | 整合能力成熟、應用生態較完整 | 導入成本與 Vendor Dependence（供應商依賴） |
| 歐洲 | Regulation（法規）＋ Standard（標準）＋跨境健康資料空間 | 強調 Interoperability（互通性）、資料權利與共同治理 | 跨國協調與逐步落地需要時間 |
| 台灣 | 共同標準、FHIR 與數位健康基礎設施 | 可在既有 HIS 基礎上逐步整合 | 不同醫院的 Legacy System（既有舊系統）與資料結構仍需處理 |
12｜Artificial Intelligence（人工智慧）與 Vibe Coding
Artificial Intelligence（人工智慧，AI） 正快速改變 Software Development（軟體開發）。
Artificial Intelligence（人工智慧，AI）
其中一個很容易感受到的改變， 就是 Vibe Coding（自然語言驅動的人工智慧輔助程式開發） 。
Vibe Coding（自然語言驅動的人工智慧輔助程式開發）
它可以讓 Idea-to-Prototype（從想法到原型） 的速度大幅加快， 但不代表產生的程式可以直接部署到正式醫療環境。
使用者不一定從第一行程式碼開始寫， 而可以直接描述：
AI 可以很快產生 Prototype（原型）， 讓 Idea-to-Prototype（從想法到原型） 的距離大幅縮短。
但真正要進入醫院使用， 還必須考慮：
系統會不會被不當存取？
病人資料是否被適當使用？
系統錯誤是否可能影響醫療決策？
誰核准、誰維護、誰監督？
如何接進 HIS、EMR 與既有系統？
發生問題後能不能追查？
Governance（治理）為什麼在醫療 AI 特別重要？
誰可以建立系統？
誰可以使用？
誰負責核准？
如何驗證？
誰負責維護？
發生錯誤時如何追蹤？
何時需要修改或停止使用？
醫療 AI 要真正進入臨床， 除了模型能力之外， 這些問題都必須被清楚定義。
13｜AI 會取代醫療資訊工程師嗎？
更可能發生的事情， 不是「工程師消失」， 而是工程師的工作重心改變。
過去較常被看見
Coding（程式撰寫）
頁面製作
Database Operation（資料庫操作）
Function Development（功能開發）
未來更重要
System Architecture（系統架構）
Integration（系統整合）
Cybersecurity（網路與資訊安全）
Data Engineering（資料工程）
Reliability（可靠性）
Governance（治理）
工程師的價值會逐漸從 Code Producer（程式碼生產者） 走向 System Architect（系統架構設計者） 與 System Integrator（系統整合者） 。
↑ 回到目錄14｜護理與其他臨床人員的角色也正在改變
臨床人員未來不只是 System User（系統使用者）。
Domain Expert（領域專家）
理解真正的 Clinical Problem（臨床問題）。
Workflow Designer（流程共同設計者）
把實際工作方式說清楚。
Requirement Owner（需求負責者）
定義真正需要解決的問題。
Clinical Validator（臨床驗證者）
判斷系統是否真正符合臨床需求與安全要求。
15｜Healthcare Informatics（醫療資訊學）本質上是一個 Translation Layer（翻譯層）
所謂「溝通」 並不是單純多開幾次會。
真正的溝通， 是把一個世界的語言， 有系統地轉換成另一個世界可以執行的語言。
16｜參訪醫院資訊系統時，不要只看「有什麼功能」
接下來實際看到 HIS（Hospital Information System，醫院資訊系統）、 EMR（Electronic Medical Record，電子病歷）、 AI（Artificial Intelligence，人工智慧） 或其他數位平台時， 可以用下面六個問題觀察：
當你開始用這些問題看系統， 看到的就不再只是一個畫面， 而會開始看見後面的 People（人）、 Process（流程）、 Data（資料） 與 Architecture（架構）。
↑ 回到目錄17｜醫療資訊專有名詞快速查詢
泛指支援醫院臨床、行政、財務與營運的整體資訊系統環境。
通常指單一醫療機構內的數位病歷與醫療紀錄。
更強調跨時間與跨照護場域的完整健康資訊。
一件工作從開始到完成， 中間所有角色、資料、判斷與動作的順序。
系統真正必須解決的問題或必須具備的能力。
把模糊的使用者需求轉換成可以分析、設計、開發與驗證的系統規格。
正式系統完成以前， 用來驗證概念、流程與使用者需求的初步版本。
開發、測試、回饋、修改後再次測試的循環。
透過視覺化元件與少量程式碼建立應用。
盡量透過圖形化設定、模組與模板完成應用。
本職不是軟體工程師， 但利用 Low-code、No-code 或 AI 工具建立應用的人。
提供共同能力， 讓其他應用可以建立在其上的數位基礎。
平台、開發者、使用者、資料、服務與應用彼此促進形成的環境。
讓不同系統依照約定方式交換資料或呼叫功能。
用於醫療資訊交換與互通的重要標準。
不同系統不只可以交換資料， 而且能正確理解並進一步使用資料。
已長期運作並承載大量既有資料與流程， 因此難以直接替換的系統。
規劃整體系統各元件、資料與服務如何組合與互相溝通。
定義誰負責、誰核准、如何監督、如何修改， 以及問題發生後如何處理。
保護系統與資料免受未授權存取、攻擊與資料外洩。
關注個人資訊是否被適當取得、使用、保存與分享。
確保資訊系統的設計與使用， 不會對病人的診斷、用藥或治療造成不當風險。
讓電腦執行原本需要人類智能才能完成的辨識、 分析、預測或生成工作。
可以產生文字、程式碼、圖像、聲音等新內容的人工智慧。
使用自然語言描述需求， 由生成式人工智慧大量協助產生、修改與除錯程式碼。
讓人工智慧融入背景工作流程， 例如理解醫病對話並協助產生紀錄。
最後，請帶走三個觀念
第一：
醫療資訊最難的，
不是把程式寫出來，
而是把真正的問題找出來。
第二：
好的系統不一定是功能最多，
而是讓使用者能自然、安全而有效率地完成工作。
第三：
AI 可以縮短「想法到程式」的距離，
但 Clinical–Engineering Communication（臨床與工程溝通）、
Architecture（架構）、
Security（安全）
與 Governance（治理）
反而會變得更加重要。
Technology is the tool（科技是工具）
Workflow is the reality（工作流程才是真實世界）
Communication makes it work（溝通讓系統真正運作）
參訪結束後，歡迎再回來複習
如果今天有些名詞還不熟悉， 不需要一次全部記住。 掃描 QR Code， 之後可以重新查看完整文章、 專有名詞解釋與整體醫療資訊架構。
本文作為醫療資訊與智慧醫療參訪之入門學習資料， 目的在協助資訊、護理及其他不同背景的學生， 理解臨床需求、資訊工程、系統整合與人工智慧之間的關係。