臺灣近兩年來資訊處推動 FHIR、SMART on FHIR 與 CQL 等核心技術的整體發展方向。目前,這些技術已經在各個領域逐漸萌芽,也開始形成完整的生態系。
整個發展歷程可以分成幾個階段。
首先,由衛生福利部資訊處提出技術方向與標準規範;接著,由工業技術研究院(工研院)完成技術雛形;再由各醫療院所進行實際落地與驗證,相關經驗在用於優化完成最後系統。如今,我們已經來到最後一棒,也就是產業界的角色,希望透過各位廠商,將這些已經完成驗證的技術商品化、產業化,進一步推廣到市場,形成一個永續發展的智慧醫療產業,也希望孵化下一個臺灣的神山產業。
在這個過程中,衛生福利部資訊處最重要的角色,就是建立標準、驗測與認證制度。唯有建立一致的技術標準,才能讓所有廠商站在共同的基礎上發展產品,彼此相容、共同合作,最終讓臺灣成為國際智慧醫療的典範。
在開始推動這件事情之前,我希望大家先建立一個最大的共識。
如果站在單一公司的角度,每一家廠商都希望建立自己的規格,讓別人的產品無法相容,如此便能形成自己的市場優勢與競爭門檻。此外,遵循國際標準本身並不容易,不但要求繁瑣,也需要投入跨領域的人才與大量資源。因此,許多公司傾向發展自己的軟體、硬體或應用規格,以建立產品的護城河。
然而,我希望大家能夠跳脫這樣的思維。
回顧人類科技產業成功的案例,都建立在共同的平台之上。
PC 產業之所以成功,是因為形成了兩大作業系統──Windows 與 macOS。由於有共同的平台,硬體產業得以蓬勃發展,各式各樣的應用程式也因此快速成長,使電腦成為現代人最重要的工作工具。
進入智慧型手機時代,同樣複製了這套成功模式。Android 與 iOS 作為兩大作業系統,在共同平台上孕育出龐大的應用生態系,同時帶動硬體產業百花齊放,形成今日全球最成功的行動生態系。
同樣的邏輯,也適用於醫療產業。
醫療一定需要一套統一的醫院作業系統 (Healthcare Operating System),並且建立三條完整的產業賽道。
第一,是醫院作業系統本身。
第二,是支援醫院營運的硬體賽道。醫療資訊系統不是一般個人電腦,而是伺服器等級的基礎設施,因此需要高效能、高可靠度的硬體設備。
第三,是建立在作業系統上的應用生態系。在臺灣,主要就是以 CQL 為核心的臨床決策支援 (Clinical Decision Support) 生態系,以及以 SMART
on FHIR 為核心的應用程式生態系。
這並不是一個未來的想像,而是國際上已經存在的模式。
目前最成熟的案例,就是 Epic。Epic 已經成為美國與歐洲許多頂尖醫學中心的標準配備,它就如同當年的 Apple,以完整且封閉式的解決方案、高效率及完整生態系,占據了大型醫療機構市場。
然而,在 Epic 之外,目前仍缺乏一個真正開放、如同 Android 一般的醫療作業系統。美國其他 HIS 廠商仍在整合階段,歐洲也尚未形成完整的平台,多半仍透過歐盟推動資料交換架構。
因此,這正是臺灣最大的機會。
我們所推動的 FHIR Box,並不是單純的資料轉換器 (Converter) 或 FHIR Server,而是一套真正可以運作的醫療作業系統。
之所以稱它為作業系統,是因為它已經具備完整的作業系統功能,包括:
因此,從底層資料管理、操作介面、應用程式生態,到資訊安全防護,FHIR Box 已經涵蓋了一個作業系統應有的完整架構。
而且,FHIR Box 並不是固定不變的產品,而是一套持續演進的平台。就如同 Windows 從 3.1 發展到今日的版本,每一代都持續增加新的功能。FHIR Box 目前只是 1.0,我們未來也將持續讓這套醫療作業系統不斷成長、持續演化。
過去,許多廠商可能負責 FHIR Server、資料轉換、大數據資料庫、臨床應用等不同領域。未來,這些能力都可以回到 FHIR Box 的共同架構下共同發展。
更重要的是,這並不會衝突各家廠商的商業模式,反而會創造出一個全新的市場。因為衛生福利部與工研院並不會直接服務醫院,而是提供國家級平台與標準;真正服務醫院與診所的,仍然是整體解決方案廠商。
因此,如果過去各位是提供 FHIR Server、資訊整合或 HIS 建置服務,未來則可以轉型為國家醫療作業系統的授權服務商,協助醫院完成部署、導入與維運。
整個生態系可以分成三條明確的產業賽道。
第一,是整體解決方案賽道。
這就如同 Windows 生態中的系統整合商 (System Integrator),負責協助醫院部署 FHIR Box,建立 TWHealth Data Space、TW Health Rule
Space、TW Health App Space 等完整架構。
第二,是硬體賽道。
FHIR Box 是軟硬整合的新型裝置 (Device)。作業系統由衛生福利部資訊處制定標準,由工研院負責實作與測試,而硬體廠商則可在此基礎上持續提升設備效能,包括
CPU、記憶體、儲存設備、資料存取速度、反應時間,以及韌體最佳化等能力,打造更高效能的醫療伺服器產品。
第三,是應用程式生態系。
過去開發醫療應用程式,需花費大量時間處理資料介接與資訊安全問題。未來,只要遵循 SMART on FHIR 或 CQL 標準,就能直接建立於共同平台之上。
AI 應用可透過 SMART on FHIR 部署;臨床決策支援則可透過 CQL 與 CDS Hooks 建立完整服務。廠商除了自行開發產品外,也可透過取得相關認證,提供醫院完整的導入與維運服務。
因此,整個產業的定位將十分清楚:
做應用程式的,就如同 Windows 上的應用軟體開發商;做硬體的,就是符合標準的醫療設備供應商;做整體解決方案的,則是協助醫院完成整體部署與維運的系統整合商。
這也是我們希望建立的國家智慧醫療生態系。
透過 FHIR Box 作為共同的醫療作業系統,串聯 TW Health Data Space、TW Health Rule Space、TW Health App Space,以及完整的 AI 生態系,讓臺灣建立一套具有國際競爭力、可持續發展的智慧醫療平台。
首先是軟體認證。
我們推動的是以 FHIR Box 作為國家授權的醫療作業系統,建立全臺一致的智慧醫療平台。因此,認證的重點並不是 FHIR Box 本身,而是所有需要與 FHIR Box 介接的軟體。換句話說,我們不會認證 FHIR Converter 或 FHIR Server,而是認證所有與 FHIR Box 整合的應用程式。
目前主要包括兩大類:
以 CQL 為例,認證內容包含兩個層面。
第一,是技術驗證 (Technical Validation)。
主要確認 CQL 所使用的資料是否符合臺灣核心資料集 (Taiwan Core Data),是否遵循相關標準與規範,確保其具有互通性與相容性。
第二,是臨床驗證 (Clinical Validation)。
我們將委託長庚大學相關研究團隊,利用實際電子病歷系統、FHIR Box 平台,以及虛擬病歷環境進行測試,確認 CQL 模組在真實臨床情境下能否順利執行,並符合醫療流程需求。只有同時通過技術驗證與臨床驗證,才能取得國家認證標章。
SMART on FHIR 應用程式亦採相同概念。
由於未來所有應用程式都必須上架至國家應用程式市集 (App Marketplace),因此除了必須符合 SMART on FHIR 規範之外,也需要符合包括:
除此之外,同樣必須完成臨床驗證。
因為即使完成所有技術測試,也無法保證應用程式在真實醫療資訊系統及虛擬病歷環境中可以順利運作。因此,我們的認證制度將比美國現行制度更進一步,除了技術相容性之外,也將驗證系統在臨床環境中的實際運作效能,確保應用程式真正可以部署於醫院並穩定運行。
因此,軟體認證的原則非常簡單:
凡是需要與 FHIR Box 介接的軟體,都必須經過國家認證。
目前主要涵蓋 CQL 與 SMART on FHIR 兩大類應用。
第二個認證項目是硬體認證。
FHIR Box 是一套軟硬整合的平台,因此硬體設備的效能也必須符合一定標準。
認證方式是將完整的 FHIR Box 作業系統安裝於硬體設備上,再透過國家標準測試流程,進行各項效能驗證。
例如,我們將建立不同規模的標準測試資料集,包括 10 萬筆、25 萬筆及 50 萬筆等不同等級的病例資料,測試硬體在各種情境下的資料轉換效率與處理速度。
此外,也會模擬不同醫療院所的使用情境,例如大量使用者同時存取 FHIR Box,測試整體 Data Flow 的處理能力,包括:
所有測試結果都將由國家醫療資訊認證實驗室公開,作為第三方客觀、公正的效能評估。
需要強調的是,效能最高的設備不一定就是最適合所有醫院的設備。
大型醫學中心可能需要追求最高效能,而區域醫院或基層醫療院所則可依照自身需求,選擇最符合成本效益的設備。因此,公開透明的測試結果,將有助於不同層級醫療院所做出最適當的選擇。
第三項,也是最重要的一項,就是整體解決方案廠商認證。
未來真正協助醫院部署 FHIR Box、進行系統安裝、維運、教育訓練,以及建立完整智慧醫療環境的,都是整體解決方案廠商。
因此,國家認證實驗室也將建立整體解決方案廠商的能力認證制度。
認證內容將依據多項指標進行評估,包括:
依據不同能力等級,整體解決方案廠商將取得不同層級的服務資格,對應不同層級的醫療機構。
例如:
因此,不同層級的整體解決方案廠商,也將具備不同的服務能力與專業定位。
建立於 FHIR Box 之應用
(CDS, CQL, SMART on FHIR)
檢核項目:
國家資料標準、臺灣核心資料群、跨院互通能力
委託長庚醫院團隊、三軍總醫院團隊等單位。
檢核:真實 HIS 環境呼叫、AI 運算流程、FHIR 回傳準確度
獲頒國家認證標章,準備上架
| 比較項目 | 傳統醫院自建 FHIR Server | 國家級 FHIR Box |
|---|---|---|
| 資料交換量 | 小批量、有限範圍 | 全國規模、高通量 |
| 處理時效 | 非同步處理 | 即時性標準化轉換 |
| 硬體架構 | 一般 PC Server(效能不足) | 客製化高效能運算架構(最佳化 CPU/記憶體配置) |
| 核心標準 | 各院自訂格式 | 完全符合臺灣核心資料群 |
建構國家級醫療作業系統生態,落實標準化專業人才培訓與三階技術授權體系
圍繞 FHIR Box 醫療作業系統核心,建立包含硬體安裝、OS 維運、TWDS 資料標準化、SNOMED CT、LOINC、RxNorm、CQL & CDS Hooks、SMART on FHIR 以及 AI 治理與 LLM 病歷編碼等完整技術授權生態樹。點擊下方藍色標籤可直接平滑導覽至該課程介紹。
圍繞衛福部 FHIR Box 國家醫療作業系統生態,規劃基礎設施維運、醫療資料標準化、臨床決策與應用、智慧醫療 AI 治理四大能力領域,提供 10 門核心學程與 100 小時系統化實戰培訓。點擊各學程卡片即可查看完整 10 堂詳細單元課綱。
系統架構與硬體認識、邊緣運算規格分析、機房環境與電力保護、BIOS/UEFI 安全性、RAID/NVMe 配置、燒機壓力測試與 RMA 維修流程。
最小化核心部署、OS Hardening 資安硬化、系統核心參數調優、網路防火牆規劃、K8s/RKE2 容器叢集、核心服務部署、HA/DR 與自動化升級。
TWDS 發展脈絡、TWCDI 欄位 Mapping、StructureDefinition、Validation 與專案實作。
邏輯模型、後組合與 ECL、台灣 National Release Refset、ICD-10 對映及 Snowstorm 建置。
六大軸向剖析、檢驗與生命徵象實務、健保碼 Mapping、5050 資料庫查詢與 FHIR 整合。
實體模型解析、健保藥品對映、RxNav API 實作、處方成分歸一化與藥品交互作用 (DDI)。
CQL 語法與 FHIR 綁定、CDS Hooks 觸發點與 Cards 設計、FHIR BOX 內建 CDS 引擎部署。
OAuth 2.0 / OIDC 醫療資安、SMART App Launch、細粒度授權、EHR 介面整合與 App Store 管理。
三大 AI 中心任務、TFDA/FDA 上市前驗證、MLOps、去識別化、可解釋性 AI、聯邦學習與風險管理。
自由文本病歷解析、Prompt Engineering、RAG 術語庫檢索、地端專用微調與端側輕量化部署。
主要服務對象:醫學中心、國家級研究醫院、大型醫療體系
授權承接範圍:全院核心 FHIR Box 建置、核心 HIS/PACS 整合、智慧醫院與聯邦學習、主權雲與高可用叢集。
主要服務對象:區域 / 地區醫院、中型專科醫院
授權承接範圍:中小型 HIS/EMR 串接、FHIR Server & TWCore、SMART on FHIR 應用導入、基礎臨床 AI。
主要服務對象:診所、衛生所、長照與健檢中心
授權承接範圍:標準化快速安裝、MyData 醫療資料交換、個人健康管理平台、基本 SMART App 對接。
8-16 小時自定進度,涵蓋 FHIR Box 系統架構、國際標準 (R4/R5) 與實務避坑指南。
嚴格線上監考(得分需 ≥ 80%),包含臨床情境推理與系統案例分析。
於工研院 (ITRI) 國家級沙盒進行,每位學員配置獨立虛擬實驗環境實戰演練。
限時任務導向審查(得分需 ≥ 85%),全面考驗安裝、效能調校、資安與除錯能力。
認證人員每年須完成 16 小時 CE 課程與 1 張新 License/Delta 測驗;若遇 TWCore IG 重大改版須於 180 天內完成對接升級,確保獲得衛福部官方白名單市集 (Marketplace) 推薦並維持市場最高信任。
為避免各醫事機構與廠商自行解讀標準,導致資料欄位、身分驗證、授權範圍、批次讀寫與效能標準不一致,本辦法建立國家級電子病歷認證實驗室,作為廠商生態系介接應用軟體產品、硬體與 TSP 廠商之 FHIR BOX 佈署之標準測試、證書核發、年度維護與公開資訊揭露之制度平台。
遵循標準化、可追溯與持續監管之核心方針,確保全國智慧醫療生態系具備最高安全性與互通性。
針對 SMART on FHIR 與 CQL 臨床決策模組進行技術相容性與臨床互通雙重嚴謹檢測。
正式測試前,廠商應先完成自測並提交自我評估清單;正式測試以認證實驗室測試環境與工具版本為準。
所有測試皆保存原始 log、測試工具版本、測試資料集版本、執行時間、測試人員與測試環境設定。
針對無法通過認證之案例,實驗室提供驗證錯誤訊息與具體建議補正方向。
用於驗證硬體系統支援大規模資料交換與高負載穩定服務能力。測試項目包含批次匯入、併發使用者數、API 成功率、Latency、Token refresh 成功率與 Bulk job 完成率。
| 驗測指標 | 國家驗測基準 (Standard) | 規範說明 (Specification Details) |
|---|---|---|
| 指標 01 API 成功率 | 2xx / total;建議 > 99% | 一般 FHIR API 與 SMART 流程呼叫之成功比例。 |
| 指標 02 平均 Latency | < 500 ms | 常用查詢與單筆資源讀取之平均反應時間。 |
| 指標 03 Token refresh 成功率 | > 99% | 大量使用者情境下 refresh token 流程成功比例。 |
| 指標 04 Concurrency 併發數量 | 20、80、150、200 (依等級) | 同時連線或同時任務承載能力評估。 |
| 指標 05 SMART login 成功率 | > 99% | 大量使用者登入與 Launch 場景之成功率。 |
| 指標 06 Bundle R/W 吞吐量 | 2,500 – 3,000 bundle resources/s | CQL/CDS Hooks、SMART App 或資料交換場景下之 bundle 讀寫能力。 |
| 指標 07 單筆 Request R/W | 約 500 req/s | 單筆 API 讀寫請求之吞吐能力參考。 |
於國家級沙盒環境進行實機上機檢定,全面考核標準佈署、CDS/CQL 規則、術語映射、AI 語意檢索及故障排除能力。
受測 TSP 應能排除至少五類現場隨機抽題之維運問題:
redirect_uri mismatch 驗證異常排除