臺灣為何需要50款SMART on FHIR App？李建璋：從標準走向應用生態的關鍵一步

來源：https://www.ithome.com.tw/news/175036

衛福部資訊處昨日（4/13）揭露SMART on FHIR應用程式選拔結果，在115件參賽應用中，共有50件入選優良名單，涵蓋醫療AI、醫療營運管理、臨床決策支援與資料視覺化四大類型，例如眼底鏡影像判讀、癌症用藥審查、ICD-10自動編碼及院級儀表板等應用。這些App都符合國際醫療資料交換標準FHIR與SMART on FHIR應用框架標準，也通過一系列嚴謹的評估，如程式完整性、防備性，臨床實用性以及落地程度等。

衛福部資訊處處長李建璋指出，衛福部也正建立專屬臺灣的SMART on FHIR應用程式市集，名為THAS。他們希望藉此形塑資料經濟，鼓勵醫療機構以訂閱方式使用好用的App，進而促進IT研發，形成正向循環。他也預告，今年5月開始衛福部將提供FHIR Box作業系統，來給全臺醫學中心部署，預計今年底前完成所有醫學中心的FHIR化。

115件申請、50支SMART App脫穎而出，聚焦四大場景

擔任本次評審的臺中榮總前院長陳適安指出，本次徵選共收到115件應用，來自醫療機構與產業界。他也收到衛福部資訊處的一份細緻、嚴謹評分表，重點涵蓋系統完整性、防備性，以及應用的便利性、實用性與落地能力。

不只如此，在這次選拔中，衛福部也與工研院建置雙層沙盒機制。第一層是傳統標準沙盒，由工研院嚴格檢核應用是否100%符合TW Core和SMART國際標準；第二層則是創新沙盒，就像是國家級實驗室，來模擬實際醫療場域，包括輸入大量模擬病歷資料來進行高強度壓力測試、在標準醫療資訊系統（HIS）環境下進行UI／UX驗證，並由30位跨領域專家擔任評審，來審查臨床安全和實用性。

最終入選的50款應用，主要聚焦四大類型，包括醫療AI、臨床決策支援、行政管理工具和資料視覺化。

在醫療AI方面，有眼底鏡影像判讀、胸部X光分析與心電圖（ECG）智慧分析等應用；在臨床決策支援領域，則包含癌症用藥審查、出血風險預測和醫療品質指標（CQI）自動計算等。行政管理工具則有ICD-10自動編碼與護理排班，資料視覺化則涵蓋院級儀表板和個案健康追蹤等應用。

比如，國軍高雄總醫院開發一款火線超人FHIRLineBot，整合了Line平臺和FHIR，民眾透過Line就能查閱自己的健康資料；該應用也搭配Kafka AI健康分析模組，來提供個人化健康洞察。又或是中研院統計科學研究所打造一支第二型糖尿病風險計算機，結合AI統計模型和SMART on FHIR標準，系統完成認證後，就能截取基本資料，並預測未來3、5、7年的發病風險。

還有一例是新光吳火獅紀念醫院，他們打造一款住院病人排程儀表板，來解決臨床處置排程資訊分散和高風險用藥缺乏即時檢核的痛點。重點是，該系統還內建前端CQL執行引擎，可直接把臨床決策支援整合到工作流程中。

臺灣醫院IT現況：為一杯牛奶，養一頭牛

力推臺灣SMART on FHIR應用的李建璋回顧，臺灣醫院的數位轉型現況，就像「為了一杯牛奶，要自己養一頭牛」。

首先，醫院IT系統大都封閉自建，形成數據孤島。在這樣的架構下，醫院若要建置智慧應用，就沒辦法從一個公開市場，挑選驗證過、標準化的應用，而是得找廠商或自行從頭開發、對接私有資料庫慢慢訓練AI，正式上線可能動輒半年。

「醫院花在系統串接與重複開發的時間，遠遠超過創新的時間，」他坦言。

這個挑戰，也進一步擴大數位落差。因為資源充足、能自行研發AI的醫學中心，往往能夠獨享數位紅利，而資源不足的中小型或偏鄉醫院，只能因數位落差而掉隊。就算醫學中心開發出來的AI應用，直接給中小型醫院使用，也會因AI模型的訓練資料不同，而產生不準確的答案、無法落地，造成創新無法規模化。

導入FHIR與SMART on FHIR，建立醫療版App生態

為解決互通痛點，衛福部推動導入FHIR與SMART on FHIR兩大國際標準，要實現「資料統一、應用統一」的目標。

進一步來說，FHIR是由Grahame Grieve於2009年創立，他借鏡RESTful API、引入資源（Resources）概念，建立FHIR標準，來促進醫療資料互通。他的設計理念是，定義80%全球通用的資料核心結構，並保留20%的在地化擴充彈性。FHIR的出現，就像是醫療資訊界的WWW，讓鎖在醫院裡的醫療資料，可以有通用的標準來交換。

SMART on FHIR標準則由美國哈佛大學醫學院教授Kenneth D. Mandl創立，這個標準使用OAuth2，解決了身份驗證和授權機制問題，將需要取得的資料範圍最小化，確保資訊安全。也因此，SMART on FHIR應用可以直接嵌入醫療資訊系統（HIS）中，不必切換頁面。

李建璋認為，有了這兩大標準，臺灣醫療資訊生態，就能發展出專屬的SMART on FHIR市集，如同App Store般，來提供各種智慧應用、供醫院選用。這個市集，也就是衛福部正在建置的THAS市集，未來還要擴大成一個生態系。

從標準統一走向工具統一，FHIR Box補上最後一哩路

李建璋話鋒一轉，光有FHIR標準還不夠，標準之後的工具與實作方式也需要整合。因為，要是各家醫院都導入FHIR，但使用的工具、版本和實作方式不同，FHIR伺服器彼此不相容，還是會導致應用仍被鎖在單一醫院體系內。換句話說，過去是資料格式分裂，現在變成工具分裂，「只是把問題往下移了一層。」

為避免這個問題，衛福部決定不只訂標準，而是直接提供整套工具，並與工研院合作推出FHIR Box，要從底層架構重新整合醫療資訊系統。

FHIR Box的核心概念，是在各家醫院既有HIS系統之上，加上一層共通平臺。醫院不需要更換原有系統，只需將資料接口接入，平臺就會自動將資料轉換為FHIR格式，並串接SMART on FHIR應用框架。

也就是說，就算不同醫院的底層系統都不一樣，也能執行相同的應用服務，形成跨院共享的應用生態。

FHIR Box：從資料到應用，一次打通的醫療互通作業系統

在實作上，FHIR Box有三大元件，包括資料轉換器（Converter）、FHIR Server與應用環境，醫院只需串接既有系統，就能完成FHIR部署。衛福部形容，這就像把原本難以利用的資料，「從Garbage變成Gold」，讓資料真正具備應用價值。

在架構設計上，FHIR Box也是一套三層的整合平臺。最底層是資料空間（Data Space），負責將醫院內各類資料轉換為FHIR，建立標準化的真實世界資料（RWD）；中層是規則空間（Rule Space），可透過Clinical Quality Language（CQL），將醫療知識轉為可執行的決策邏輯；最上層的應用空間（App Space）則支援SMART on FHIR應用，形成可跨院執行的App生態。

李建璋也透露，衛福部已於今年3月啟動補助計畫，並獲得各大醫學中心支持，預計5月開始提供FHIR Box給醫學中心部署，年底前讓全臺醫學中心完成FHIR化，進一步建立跨院互通的應用環境。

醫院IT角色將轉變，接下來要走向資料經濟

在推動策略上，衛福部也將重點從單一系統建置，轉向流程整合和推動資料經濟。

尤其，臺灣的THAS市集規模化後，可以翻轉醫院IT角色，從單純的系統「維護者」，轉型為創造應用價值的「創作者」。同時，市集的出現，也能帶動訂閱制，比如原本沒有資源自行開發的中小型醫院，可將成本省下來改以訂閱方式，訂閱好用的App。而這種訂閱機制，也能正向促使開發者投入資源研發，建立永續的資料經濟模式。

'

生成式AI現身3年的普及率為53%，超越PC及網路

來源：https://www.ithome.com.tw/news/175035

史丹佛大學人本AI研究所（Stanford HAI）近日發表年度AI趨勢報告《2026 AI Index Report》，指出AI模型在許多能力上已接近甚至超越人類，只現身3年的普及率便達53%，超越個人電腦（PC）及網路，此外，儘管AI基礎設施高度集中於美國，但美國與中國的模型差距幾乎消失了。

研究顯示，2024年全球企業對AI的投資為2,530億美元，但2025年直接成長超過1倍達到5,817億美元，其中，針對生成式AI的投資成長超過200%。在生成式AI領域，美國在2025年的投資金額達到2,859億美元，遠超過中國與歐洲的總和（334億美元）。

此外，生成式AI在現身3年內的普及率達到53%，快過電腦及網際網路。其中，電腦問世後大概經過15年的普及率才接近50%，網路則花了7年才接近50%。對生成式AI接受度前五名的國家依序是阿拉伯聯合大公國（United Arab Emirates，阿聯），普及率為64%，新加坡的60.9%，挪威的46.4%，愛爾蘭的44.6%，以及法國的44%。

Stanford HAI《2026 AI Index Report》

美國雖然投資最多，但生成式AI的普及率只有28.3%，排名24，而臺灣的生成式AI普及率則達到28.4%，排名23。

從企業的角度來看，有88%的企業至少在一個業務功能上使用AI，有79%使用生成式AI。值得注意的是，2023年只有33%的企業導入生成式AI，但2025年就快速成長到79%，這是因為ChatGPT等工具讓AI直接進入工作流程，而且企業使用AI的方式也更為廣泛。

Stanford HAI《2026 AI Index Report》

在AI整體實力方面，美國擁有5,427個資料中心，是其它國家的10倍以上；中國在論文發表、引用及專利授權上引領全球，在2025年出版了30個重要模型，至於美國則擁有更高影響力的專利，同年出版的模型達到50個。中國在2024年取得了全球74%的AI專利，相較之下美國僅取得了12%。

值得注意的是，美國與中國的頂級模型表現已不相上下，在由人類盲測的Arena排行榜上，2026年3月是由Anthropic、xAI、Google、OpenAI、阿里巴巴及DeepSeek共列前段班，彼此差距極小，幾乎處於同一競爭層級，顯示模型的性能優勢已明顯收斂，且競爭壓力開始由模型的性能，轉向成本、可靠性，以及特定場景能力。

Stanford HAI《2026 AI Index Report》

報告指出，自2025年初以來，美國與中國的模型在性能排名上多次互換位置，DeepSeek-R1在2025年2月曾短暫與美國頂級模型並駕其驅，2026年3月，美國頂級模型則以2.7%的優勢領先，過去這一年來，就算此一差距有所波動，但始終保持在個位數，顯示中美之間的AI模型效能差距實際上已消失。

'

蠕蟲程式GlassWorm透過程式語言Zig打造的載入工具，滲透多款IDE

來源：https://www.ithome.com.tw/news/175034

去年10月揭露的蠕蟲程式GlassWorm，駭客最初於Open VSX與Visual Studio Code（VS Code）延伸套件市集從事活動，後續將範圍延伸到GitHub、NPM，甚至是Chrome延伸套件市集，如今傳出駭客轉移目標，針對受害開發環境的各種整合開發環境（IDE）工具。

資安公司Aikido在Open VSX看到惡意套件code-wakatime-activity-tracker，駭客模仿熱門的時間追蹤工具WakaTime，並在套件挾帶以程式語言Zig編譯而成的二進位檔案。與之前攻擊行動相同的是，此二進位檔案並非GlassWorm的實際有效酬載，而是駭客用來傳遞該蠕蟲的工具，這次GlassWorm感染的目標，是受害電腦安裝的所有IDE工具。

這次駭客上傳的惡意套件，看起來與正牌的WakaTime幾乎相同，具備相同的註冊指令、API金鑰的提示、狀態列圖示，但不同的地方在於其功能函式。惡意套件在執行WakaTime的邏輯之前，會根據受害電腦的作業系統載入對應的二進位檔案，在Windows電腦執行的是PE32+的DLL檔；而在macOS環境裡，則為可在x86或Arm晶片執行的通用Mach-O檔案。無論是DLL還是Mach-O檔，都是Node.js原生的附加元件（Add-on），駭客使用Zig編寫，並透過特定的共享程式庫編譯而成，並直接在Node.js的執行環境（Runtime）載入，更可怕的是，這種應用程式不僅能突破JavaScript沙箱限制而執行，還具備完整的作業系統層級存取權限。

一旦二進位檔案於受害電腦成功載入，就會試圖找出開發人員使用的IDE工具，這些工具的共通點，在於都能安裝VS Code延伸套件。這些IDE包含VS Code、VS Code Insiders、Cursor、Windsurf、VSCodium，以及Positron。接著，二進位檔案才會從GitHub擷取惡意的VSIX檔案。

'

Booking.com外洩用戶訂房資料、個資

來源：https://www.ithome.com.tw/news/175032

訂房網站Booking.com上週以電子郵件通知用戶資料外洩，包括姓名、電子郵件以及訂房資訊。

多名用戶在Reddit反映接到Booking.com的通知。Booking.com告知，一個未授權人士存取了一定用戶的訂房資訊，根據調查，外洩的資訊包括用戶姓名、電子郵件、住址、電話和任何「用戶分享給住宿機構的資訊」。為確保用戶資訊安全，該網站已經更新了預約的PIN碼。

有用戶表示接到不明人士電話聯繫。另外TechCrunch報導，有用戶經由WhatsApp接到釣魚訊息，這表示攻擊者已經開始濫用竊得的用戶個資。

Booking.com發言人向媒體證實公司發現系統可疑活動，導致使用戶訂房資訊被不明行為者存取。但該公司向The Guardian表示，用戶財務資訊未遭到存取。

不確定是Booking.com哪個系統遭存取，也尚未有駭客組織出面承認。

Booking.com官網資訊指出，自2010年以來，該平臺已累計促成約68億人次的住宿預訂，其中包括約18億筆公寓、住宅及其他類型住宿。

這不是Booking.com第一次發生資料外洩事故。2023年底，駭客藉由假扮用戶向Booking.com合作旅館下手，在旅館人員電腦散布竊資軟體取得相關帳密資料，進而利用旅館的Booking.com帳號發送釣魚訊息給旅客。

'

曝露在網際網路的AI影像生成管理平臺ComfyUI遭到鎖定，駭客試圖用於挖礦、部署殭屍網路

來源：https://www.ithome.com.tw/news/175031

威脅情報公司Censys指出，近期駭客鎖定曝露於網際網路的AI影像生成管理平臺ComfyUI，透過專屬的Python掃描工具於公有雲尋找下手目標，一旦成功入侵，他們就會將受害主機組成殭屍網路，用於挖礦或是架設非法代理伺服器，藉此獲取不法利益。值得留意的是，過程裡駭客使用的惡意程式ghost.sh，採取無檔案執行，並偽裝成核心層級的處理程序，以及導入LD_PRELOAD的Rootkit功能，藉此迴避偵測，此外，他們還加入3種備援機制，即使IT人員嘗試將ComfyUI重開機，或是移除惡意軟體相關元件，仍有可能透過備援機制恢復運作。

ComfyUI是以節點（Node）為基礎的應用程式，能讓使用者下達一系列的文字提示產生圖片。此系統廣泛受到AI社群採用，通常會搭配Stable Diffusion或其他免費的擴散模型（Diffusion Model），以及配備高階圖像運算資源的硬體，使得這類應用系統成為駭客眼中的肥羊，因為用於圖片生成的GPU，在閒置時能被用來挖礦。再加上許多ComfyUI建置於雲端基礎設施，曝露在網際網路上且未設置身分驗證機制，使得攻擊者能直接入侵及濫用。

Censys在過濾掉研究人員架設的蜜罐陷阱之後，找到超過1,000個曝露於網際網路的ComfyUI平臺，儘管數量並非極為龐大，不過該公司認為，已經足以讓攻擊者從事大規模利用。

這起事故的發現，源自Censys於3月12日，在一家防彈主機代管供應商察覺到公開的資料夾，其內容被該公司的威脅情報平臺標示為可疑，數日後他們看到資料夾的檔案數量快速增加，代表駭客正積極開發攻擊工具。Censys進一步分析，確認駭客尋找曝露在網路上的ComfyUI，利用特定的錯誤組態設定，使得程式碼能透過特定的節點執行。得逞後，駭客透過基於Flask框架而成的網頁儀表板列管，並使用挖礦工具XMRig與lolMiner，挖取門羅幣與Conflux代幣，同時將受害系統加入代理伺服器殭屍網路Hysteria v2。

值得留意的是，若是目標ComfyUI不存在上述節點，駭客的掃描工具就會進一步部署存在弱點的節點套件ComfyUI-Manager，然後再度嘗試進行控制。

'

OpenAI受Axios供應鏈攻擊影響，已更新憑證，呼籲MacOS用戶更新到最新版

來源：https://www.ithome.com.tw/news/175030

OpenAI昨日表示自己也受到NPM套件Axios供應鏈攻擊影響，不過沒有客戶或自家系統、智財外洩。該公司也更新了macOS憑證，要求Mac用戶在5月8日前儘速升級App。

3月31日受歡迎的第三方套件Axios遭駭客利用維護者憑證發布有問題的1.14.1與0.30.4版，開發人員一旦下載安裝，電腦可能被植入RAT木馬等惡意程式。那時OpenAI用於簽發macOS應用程式的GitHub Actions工作流程就下載了1.14.1版Axios。這個工作流程具有存取簽發macOS版OpenAI程式必要的憑證和公證資料。這些憑證目的在讓使用者確認App是真實來自OpenAI的App。涉及的OpenAI App包括macOS版ChatGPT Desktop、Codex、Codex-cli和Atlas。

OpenAI說已經偕同外部數位鑑識及資安事件回應業者合作啟動調查，並且輪換macOS App簽章憑證、並且以新憑證更新App，再上架到蘋果App Store。OpenAI分析，從惡意程式執行、憑證注入驗證過程、以及驗證序列及其他因素時間點來看，簽發憑證應該沒有外洩也沒有被濫用情形。但是為保險起見，OpenAI已開始註銷和輪換憑證。

自2026年5月8日起，舊版OpenAI macOS桌面版應用程式將不再提供更新與支援，且可能無法正常運作。OpenAI表示，使用者需升級至以下版本或更新版本，這些版本為採用新憑證簽署的最早版本，包括ChatGPT Desktop 1.2026.051、Codex App 26.406.40811、Codex CLI 0.119.0，以及Atlas 1.2026.84.2。

用戶可以從macOS App的程式內更新或官網下載到最新版本App。OpenAI呼籲用戶不可從任何電子郵件、訊息、廣告或第三方網站下載，以免安裝假的App。

此外OpenAI也檢視所有以舊憑證簽發的所有軟體版本確保沒有遭到惡意修改。目前該公司沒有發現現有軟體可能或已經遭到惡意修改。OpenAI並重申，這次事件只影響OpenAI macOS App，Web版並不受影響。

'

紅帽支援RHEL執行SQL Server 2025整合Azure管理延伸模組，強化授權彈性與可視性

來源：https://www.ithome.com.tw/news/175028

紅帽（Red Hat）與微軟宣布，企業可在Azure虛擬機器上，於Red Hat Enterprise Linux（RHEL）環境執行SQL Server 2025，並整合SQL IaaS Agent延伸模組，以強化授權管理與監控資訊的可視性。

在此架構下，企業於RHEL環境部署SQL Server後，可透過SQL IaaS Agent延伸模組進行註冊，並在Azure中建立對應的SQL虛擬機器資源。該資源與原本的虛擬機器分開管理，可協助呈現授權使用的類型，提供訂閱層級的追蹤能力，以及相關監控資訊。

在授權模式方面，該延伸模組支援三種選項，包括隨用隨付（Pay-as-you-go），將SQL Server授權費用納入Azure虛擬機器計費；Azure Hybrid Benefit（Azure混合權益），允許企業沿用既有SQL Server授權；以及災難復原（Disaster Recovery）授權，用於Azure中的高可用性與災難復原備援節點，企業可依需求選擇適用的授權模式。

在操作上，使用者需透過Azure CLI或Azure PowerShell，將Azure訂閱註冊至Microsoft.SqlVirtualMachine資源提供者，以完成SQL IaaS Agent延伸模組的初始設定。後續管理作業包括授權調整，則可透過Azure入口網站進行。

紅帽表示，隨著SQL Server 2025支援部署於RHEL 10，企業可在Linux平臺上執行關鍵資料庫工作負載。RHEL提供容器原生架構、強化安全機制與自動化管理能力，並支援混合雲、邊緣運算與AI導向環境。

'

Red Hat發布OpenShift 4.21，整合AI、容器與虛擬化於單一平臺並強化GPU資源調度

來源：https://www.ithome.com.tw/news/175027

開源解決方案供應商紅帽（Red Hat）近日宣布推出企業級Kubernetes平臺Red Hat OpenShift 4.21。此版本以Kubernetes 1.34與容器執行環境CRI-O 1.34為基礎，將AI、容器與虛擬化工作負載整合於同一基礎架構，並透過動態資源配置機制強化GPU資源調度能力，以提升混合雲環境下的整體資源使用效率。

圖片來源／紅帽

隨著企業逐步將AI應用導入正式營運環境，AI訓練與推論工作負載對於資源調度與系統整合的需求持續提高。Red Hat指出，過去AI、容器、虛擬機器多半分散於不同平臺運作，不僅增加系統管理複雜度，也降低資源配置效率。OpenShift 4.21強調在統一營運模型下整合不同類型工作負載，並可依實際需求自動調整資源配置。

在AI工作負載支援方面，OpenShift 4.21導入Red Hat組建的Kueue（Red Hat build of Kueue）1.2版，以及用於OpenShift Container Platform的JobSet Operator。Kueue是Kubernetes上的工作負載排程與佇列管理機制，適用於AI訓練等批次任務，並提供任務佇列可視化能力，讓使用者可掌握執行順序與預估啟動時間；JobSet Operator則用於協調多個相互依賴的分散式任務，支援容錯與重試機制，使企業可在既有GitOps與權限控管架構下，執行大規模分散式運算。

針對AI運算核心的GPU資源管理，Red Hat在此版本中強化Dynamic Resource Allocation（DRA）機制。DRA為Kubernetes的動態資源配置功能，允許工作負載依硬體條件（如GPU記憶體容量）提出資源需求，由系統自動匹配符合條件的設備，並支援資源優先順序與替代策略，以提升資源配置彈性。此外，該機制也提供管理員例外存取能力，以利進行監控與除錯。

在核心平臺能力方面，OpenShift 4.21針對Hosted Control Plane導入Vertical Pod Autoscaler（VPA）。Hosted Control Plane是將Kubernetes控制層元件集中託管，並與工作節點分離的架構設計，而VPA可依據實際資源使用情況，自動調整Pod（容器執行單元）的CPU與記憶體配置，降低人工設定負擔並提升資源使用效率，以降低基礎架構成本。

在既有企業環境整合方面，OpenShift 4.21支援VMware Cloud Foundation 9，並可部署於Oracle的Oracle Database Appliance，提供整合硬體與軟體的資料庫環境，以強化混合雲部署彈性。

在安全機制上，此版本支援Microsoft Azure環境執行的Confidential Containers，透過硬體層級保護機制，確保資料在記憶體中處理時仍維持隔離狀態，以降低雲端平臺或底層系統存取敏感資料的風險。

虛擬化方面，OpenShift Virtualization支援在同一平臺上同時執行虛擬機與容器工作負載，並提供跨叢集零停機遷移功能，可在不中斷服務的情況下進行維護或資源調整。此外，該版本亦支援IPv6專用的控制層與次要網路，並可在Google Cloud裸機環境執行虛擬化工作負載，以滿足低延遲與高效能需求。

'