台灣醫院 HIS 的獨規困局，為什麼 SMART on FHIR 是唯一的出路
這篇講一件我在醫院資訊室每天都在面對的事：台灣各家醫院的 HIS 長期各做各的、彼此不通，我把這個現象叫「獨規」。每家醫院一套自己的資料模型、一套只有原廠看得懂的介面，跨院調不到資料、想接新功能都要回頭跟原廠談，貴又慢，AI 跟創新根本進不來。我認為這不是靠「再串一條介面」能解的，出路只有一條，就是把資料模型跟存取方式收斂到開放標準，也就是 FHIR。但光有 FHIR 還不夠，真正能打破廠商綁定的是 SMART on FHIR，它在 FHIR 的資料與 API 之上補了 OAuth2 授權跟 app 掛載機制，讓任何一支符合標準的應用可以安全地掛到任何一家醫院的系統上，一次寫、到處跑。美國用 21st Century Cures Act 直接強制 EHR 開放這套 API，Epic、Cerner 都支援，早就是事實標準；台灣有衛福部的 TW Core IG 打底，方向對了，卡的是既有投資跟廠商動機。這篇把獨規怎麼來的、代價是什麼、為什麼標準化是唯一解、為什麼是 SMART on FHIR 而不只是 FHIR，一路講清楚，也誠實講台灣落地的現實阻力。
我在醫院資訊室工作，每天都在跟一件事纏鬥：台灣每一家醫院的資訊系統（HIS）幾乎都是各做各的，彼此不通。這個現象我自己叫它「獨規」，也就是大家常說的系統孤島，只是我更想強調造成孤島的根源，是每家醫院一套只有自己跟原廠看得懂的規格。這篇想把這件事講清楚，也講為什麼我認為出路只有一條，就是 SMART on FHIR。
「獨規」是什麼，怎麼長出來的
台灣醫療資訊的底子是很厚的，早年各大醫院為了跑得動自己的流程，紛紛自建或委外做 HIS。醫學中心常常自己養一整組人開發，區域和地區醫院則買商用套件再大量客製。做到最後，每一家的資料怎麼存、欄位怎麼定義、狀態怎麼流轉，都是一套自己的規格。
系統跟系統之間要交換資料時，靠的多半是 HL7 v2 這種點對點的介面，一條一條手工串。A 醫院要跟 B 廠商的檢驗系統對接，就客製一條；換一個系統，再客製一條。久了整個院內像一張用膠帶黏起來的網，能動，但沒有人敢亂碰。至於跨院，長期以來主要靠電子病歷交換，那是以 CDA 這類文件為單位在交換，本質是「把一份病歷文件送過去」，不是讓另一端可以即時、精準地查詢某個病人的某個資料。
這不是誰笨，是歷史累積的結果。每一步在當下都合理，合起來就變成今天這個彼此不通的局面。
獨規的代價，比想像中大
獨規真正的問題，不在於它現在不能動，而在於它讓每一件想做的新事情都變得又貴又慢。
第一，跨院調不到資料。病人在 A 醫院做過的檢查，到了 B 醫院常常得重做，因為兩邊的系統講不同的語言。受害的是病人，浪費的是整個健保。
第二，任何創新都要先過原廠這一關。我想在門診流程裡加一個小功能、想接一個 AI 決策支援，第一步不是寫程式，是回頭跟當初做 HIS 的廠商談。因為資料鎖在他們的規格裡，沒有開放的介面，我碰不到。談判、報價、排程，一輪下來，一個本來很小的功能可以拖上大半年。
第三，這是一種很深的廠商綁定。系統換不掉，因為所有客製、所有介面都是為這一家長出來的，換一家等於整院重做。議價能力長期在對方手上。
第四，AI 進不來，或者進來也長不大。這兩年大家都在談醫療 AI，但 AI 要規模化，前提是資料拿得到、而且是標準化的。如果每一家醫院的資料模型都不一樣，那每接一家就要重做一次資料清洗跟對映，這件事我在 用 LLM 把結構化臨床資料自動轉 HL7 FHIR 那篇算過帳，光是把非標準資料對到標準模型就是最大的成本。獨規等於讓每一家醫院都變成一座孤島，AI 只能一座一座重新登陸。
為什麼標準化是唯一解，為什麼是 FHIR
要解獨規，方向其實很清楚：把「資料長什麼樣」跟「怎麼存取資料」這兩件事，從各家自己說了算，收斂到一套大家共用的開放標準。
這套標準，國際上已經有答案，就是 HL7 FHIR。FHIR 把臨床資料拆成一個個標準的資源，病人、就診、檢驗、用藥、診斷，每一種都有明確定義的結構；存取方式用的是大家都熟的 RESTful API，不是只有原廠看得懂的私有介面。等於是幫整個醫療資料圈訂了一套共同語言。台灣這邊，衛福部推的 TW Core IG 就是把 FHIR 在地化，定義台灣自己的核心資源與規範，這一步方向是對的。
但我要強調，光有 FHIR 還不夠。FHIR 解決的是「資料怎麼描述、怎麼被查詢」，它沒有解決一件同樣關鍵的事：一支外部應用，要怎麼被安全地授權、掛進醫院的系統裡。
為什麼是 SMART on FHIR，而不只是 FHIR
這就是 SMART on FHIR 的位置。它站在 FHIR 之上，補了三件 FHIR 本身沒管的事：一是用 OAuth2 跟 OpenID Connect 做授權，讓應用拿到的是有範圍、有期限、可撤銷的權限，而不是整包資料庫的鑰匙，這套機制我在 FHIR 用 OAuth2 + PKCE 交換資料 拆過。二是 app 掛載的情境，讓一支應用可以從 HIS 裡被叫起來、並且知道現在是哪個病人、哪個醫師。三是標準化的權限範圍，讓「這支 app 只能讀這個病人的用藥」這種控制變成標準寫法。
把這三件事加起來，SMART on FHIR 做到的是一件很關鍵的事：讓應用變成可替換、可攜帶的。一支符合 SMART 的 app，只要寫一次，理論上就能掛到任何一家支援標準的醫院系統上，一次寫、到處跑。這正好把前面獨規的死結解開，應用不再跟某一家 HIS 廠商綁死，醫院要接新功能不必每次都回頭求原廠，創新者可以直接照標準做一支 app，掛上去就能用。我自己做的火線超人，就是照這個思路，用 SMART on FHIR 把一支 LINE Bot 安全地接到病歷資料上，細節在 SMART on FHIR 遇上 LINE Bot。
flowchart TB
subgraph OLD[現況：獨規，點對點客製]
A1[A 院 HIS<br/>自有規格] ---|客製介面| X1[檢驗系統]
A1 ---|客製介面| X2[影像系統]
A1 ---|客製介面| X3[新功能 / AI]
B1[B 院 HIS<br/>另一套規格] ---|又一條客製| X4[同樣的功能重做]
end
subgraph NEW[出路：SMART on FHIR，標準 API + 授權層]
H[任一家醫院<br/>FHIR 資源 + REST API]
S[SMART 授權層<br/>OAuth2 / 範圍 / 掛載情境]
H --- S
S -->|一次寫，到處跑| APP1[病人自主 app]
S --> APP2[AI 決策支援]
S --> APP3[跨院調閱]
end
OLD -.收斂到開放標準.-> NEW
國際已經證明這條路走得通
這不是我一廂情願。美國在 21st Century Cures Act 裡，直接用法規強制通過認證的 EHR 必須開放標準化的 FHIR API 跟 SMART app 掛載，把「開放」變成法定義務，也明文禁止資訊封鎖。市場上最大的 Epic 跟 Oracle Cerner 都支援 SMART on FHIR，第三方 app 生態已經長出來了。換句話說，全世界醫療資訊最大的市場，已經賭定 SMART on FHIR 是答案，而且是用法律去推。
台灣的底子其實不差，TW Core IG 已經把資料標準這一塊打好，跨院 FHIR 互通的架構討論也在進行。缺的不是技術，是把它從示範計畫變成醫院日常的決心。
台灣落地的現實阻力，我不迴避
我不想把話講得像業配，所以得誠實講難處。
最大的阻力不是技術，是既有投資跟廠商動機。每一家醫院都在現有的獨規系統上投了很多年、很多錢，要動它就是動筋骨。而對做 HIS 的廠商來說，開放標準等於降低了綁定，短期內他們沒有太強的誘因主動做這件事。加上醫院端最在意的是不能停機、不能出錯，這種求穩的體質，天生就對「換底層」很保守。這些都是真的，我每天都在面對。
但我認為方向不會變，因為獨規的成本是隨時間往上長的：資料越積越多、想接的 AI 跟創新越來越多、跨院的需求越來越剛性，孤島的代價只會越來越貴。與其每一次新需求都在舊介面上再貼一條膠帶，不如認清這條路遲早要走。務實的做法不是明天就把整院翻掉，而是新的東西一律照 SMART on FHIR 的標準長，讓開放的那一塊慢慢長大，舊的獨規部分逐步被標準包起來、替換掉。
我做 Omakase Smart Hospital 一直在講的一件事就是這個：一個人加上開放標準，就能把很多本來要靠大廠、靠大預算才能做的事做出來。前提是資料得先站在開放標準上。SMART on FHIR 不是眾多選項裡比較潮的一個，對台灣醫療資訊的長期健康來說，它是那條我看得到的、唯一走得出去的路。