2026年1月25日 星期日

HIS EMR EHR FHIR 這四者之間有何差異

HIS EMR EHR FHIR 這四者之間有何差異

[耀瑄科技 新創小組]

在台灣與國際醫療資訊語境中,「HIS/EMR」與「EHR/FHIR」之間的差異,表面上看起來只是名詞不同,但實際上反映的是完全不同的歷史背景、制度設計與系統思維。若沒有把這層脈絡釐清,很容易陷入「為什麼台灣已經有 HIS,還需要 FHIR?」或「我們不是早就有 EMR 了嗎,為什麼國外還在談 EHR?」這類永遠講不清楚的討論。

在台灣,HIS 與 EMR 幾乎是伴隨著醫院資訊化一起成長的名詞。HIS(Hospital Information System)在本地的使用語境中,並不是一個單純的資訊系統名稱,而更像是一個「院內資訊世界的總稱」。它涵蓋了臨床、行政、財務、健保申報、醫囑、檢驗、影像、護理與後勤流程,甚至在某些醫院,連排班、設備管理、耗材庫存都被視為 HIS 的一部分。這樣的 HIS,設計初衷並不是資料交換,而是讓一家醫院能夠在既有制度與健保環境下穩定運作。

在這樣的架構中,EMR(Electronic Medical Record)自然成為 HIS 的核心模組之一。EMR 在台灣,通常指的是醫師與護理人員實際書寫與查閱的電子病歷內容,包括診斷、病程記錄、SOAP note、處方、檢驗與影像報告的文字結果。雖然名為「電子病歷」,但它的邊界其實非常清楚:EMR 的資料是為了支援「這一家醫院」的照護流程而存在的。資料結構、欄位定義與呈現方式,往往高度貼合院內作業習慣,並不以跨院交換或外部重用為設計前提。

也正因如此,台灣的 HIS 與 EMR 長期呈現出一種「內向型」特質。它們解決的是院內效率、流程穩定度與法規遵循問題,卻很少被要求思考資料在院外如何被使用。即便有跨院需求,過去多半也是透過文件交換、影像光碟或批次匯出來完成,而不是即時、結構化、可查詢的資料服務。

相對地,當國外談到 EHR(Electronic Health Record)時,所指涉的並不是某一套具體系統,而是一個更高層次的「健康資料體系概念」。EHR 的核心精神,是以病人為中心,而非以醫院為中心。它關心的不是某一次就醫發生了什麼,而是一個人在不同醫療機構、不同時間點、不同照護場景下所累積的健康資訊,是否能夠形成連續且可理解的整體紀錄。

這樣的 EHR 概念,從一開始就假設醫療資料必須跨系統流動。它預設了多家醫院、多種系統並存的現實,也因此必須依賴標準來確保互通性。這正是為什麼在國際脈絡中,EHR 幾乎不可能脫離 HL7 所推動的一系列標準而獨立存在。沒有共同語言,就不可能談跨院;沒有資料模型與交換規範,就無法形成真正的健康紀錄體系。

而 FHIR 的出現,正好補上了過去醫療標準在實作層面的斷層。FHIR 不只是另一套資料格式,它代表的是一種全新的資料使用方式。它將醫療資訊拆解為細小而明確的資源,讓病人、一次就醫、一筆檢驗結果或一項診斷,都能被獨立存取與組合。這種設計,使醫療資料第一次真正進入 API 與服務導向的世界,也讓臨床應用、行動 App、研究分析與 AI 推論成為可行的日常操作,而不再只是概念展示。

從這個角度回頭看,HIS/EMR 與 EHR/FHIR 並不是站在同一條水平線上的競爭者。HIS 與 EMR 解決的是「單一醫院如何把事情做好」,而 EHR 與 FHIR 回答的是「當病人跨越不同醫療場域時,資料要如何被延續與重用」。前者關心的是流程與責任,後者關心的是連續性與可攜性。這兩種思維,並不存在誰取代誰的關係,而是層級不同、關注焦點不同。

也因此,當台灣近年開始大量談 FHIR,真正的意義並不在於否定既有 HIS 或 EMR,而是試圖在現實與理想之間搭起一座橋樑。透過 FHIR Gateway 或類似的轉譯層,院內的 HIS/EMR 得以在不被推翻的情況下,逐步對外提供標準化的資料介面。這些介面不僅能支援新型應用,也讓台灣的醫療資訊架構,第一次開始具備向 EHR 演進的條件。

若用更白話的方式來形容,HIS 與 EMR 像是一家醫院內部的作業系統,確保每天的醫療服務可以順利進行;EHR 則像是一個病人專屬的長期記錄本,無論走到哪裡,都能延續過去的健康脈絡;而 FHIR,則是讓這本記錄本能被不同系統讀寫的共同語言。只有當這三者各自回到適合的位置,醫療資訊才能同時兼顧現實運作與未來發展。

換成一句白話(非常好用)

HIS / EMR 解決的是「一家醫院內部怎麼運作」 EHR / FHIR 解決的是「一個病人的資料如何跨院延續」


四者的層級差異

名稱本質核心視角是否跨院
HIS(台灣)院內整體系統醫院
EMR(台灣)院內電子病歷醫院
EHR(國外)健康資料體系病人
FHIR資料與 API 標準系統互通

為什麼台灣現在開始大量談 FHIR?

因為 FHIR 剛好補上了台灣 HIS / EMR 長期缺失的那一塊: 一個不要求推翻既有系統,又能讓資料「走得出去、用得起來」的中介層。

這也是為什麼近年實務上常看到這樣的結構:

HIS / EMR(院內、既有)
   │
   │  FHIR Gateway(轉譯與抽取)
   ▼
FHIR Server
   │
   ├─ SMART on FHIR App
   ├─ AI / 臨床決策支援
   └─ 研究 / 數據中台

在這樣的架構下,HIS 與 EMR 不需要被否定,而是成為資料來源;FHIR 則成為連結應用與未來 EHR 架構的關鍵橋梁。


總結來說,台灣長期以 HIS 與 EMR 為核心,建立了高度成熟的院內資訊體系;國際上所推動的 EHR,則是一個以病人為中心的制度目標;FHIR 則是連結兩者的技術關鍵。理解這層差異,不僅能幫助醫院在導入新技術時做出務實選擇,也能避免在名詞混用之中,錯把「工具」當成「目標」,或誤以為只要換一套系統,就能自然擁有真正的 EHR。 




CDA R2 vs FHIR 比較

[耀瑄科技 新創小組]

在醫療資訊標準的發展歷程中,CDA R2 與 FHIR 往往被拿來對照討論,但若只把它們理解為「舊標準」與「新標準」,其實會忽略了兩者真正的設計初衷與歷史脈絡。

CDA R2 誕生於醫療資訊仍以「文件交換」為核心的年代。當時醫院最迫切的需求,並不是即時查詢或跨系統串接,而是如何把一份完整、可被人類閱讀、同時又能被系統解析的臨床文件,安全且一致地交付給另一家機構。因此,CDA R2 從一開始就被定位為「臨床文件架構」,它的基本單位不是資料欄位,也不是 API,而是一份具有法律與醫療意義的文件。這份文件通常包含清楚的文件標頭(病人、醫療機構、作者、時間)與文件內容,內容中既可以有結構化資料,也容許大量敘述性文字。這樣的設計,使得 CDA 在病歷交換、出院病摘、轉診文件等場景中,長期扮演不可或缺的角色。

然而,隨著醫療資訊系統逐漸走向即時化與服務化,CDA R2 的限制也開始浮現。由於它以「整份文件」為單位,只要想取得其中某一項資訊,就必須先接收並解析整個文件;而文件中大量的 narrative text,對臨床閱讀很友善,卻對系統自動化處理並不理想。更重要的是,CDA 的交換模式本質上是「傳送檔案」,並不適合支援行動裝置應用、臨床決策支援或即時 AI 分析等新型態需求。

也正是在這樣的背景下,FHIR 出現了。FHIR 並不是對 CDA 的否定,而是一種世代轉換的回應。它重新思考了一個問題:**如果醫療資料能像網路資源一樣被即時存取與組合,臨床系統可以做到什麼程度?**因此,FHIR 採用了以資源(Resource)為核心的資料模型,每一個病人、一次就醫、一筆檢驗結果,都被拆解為獨立而明確的資源,並且可以透過 RESTful API 即時查詢與組合。這種設計,讓醫療資料第一次真正融入現代軟體工程的開發模式,也為 SMART on FHIR、臨床 App 與 AI 應用打開了大門。

從設計哲學來看,CDA R2 與 FHIR 的差異,其實反映了兩個時代對「醫療資料」的不同想像。CDA 關心的是「這份文件是否完整、是否可被醫師理解、是否可作為正式紀錄保存」,而 FHIR 關心的則是「這筆資料能否被即時查詢、是否能被重複利用、是否能與其他資料快速組合」。前者重視穩定與一致,後者追求彈性與即時。

但這並不代表兩者只能二選一。實務上,許多醫院正同時使用 CDA 與 FHIR,各自扮演不同角色。CDA 繼續作為法規、評鑑與跨院交換的核心文件格式,被妥善保存;FHIR 則作為應用層與資料服務層的基礎,支援臨床決策、病人時序圖、研究分析與創新應用。甚至在技術上,FHIR 也提供了 Composition 與 Bundle 等機制,讓一組 FHIR 資源能夠被重新組裝成「文件型態」,在概念上與 CDA 對齊。

因此,與其把 CDA R2 與 FHIR 看成競爭關係,不如把它們理解為同一條演進軸線上的不同階段。CDA 保存了醫療文件的嚴謹性與法律可信度,FHIR 則賦予醫療資料前所未有的流動性與即時性。在今日的醫療資訊架構中,真正成熟的做法,往往不是淘汰其中之一,而是讓 CDA 成為可信的歷史與交換基礎,讓 FHIR 成為驅動未來應用與決策的引擎。這樣的分工,也正是許多醫院在數據中台與 FHIR Gateway 架構下,逐步實現的現實路徑。 





SMART on FHIR 應用 : 最智慧的非侵入肌肉品質定量系統

SMART on FHIR 應用 : 最智慧的非侵入肌肉品質定量系統

Image

Image

Image


從一個「身體組成 AI 推論系統」談起

為什麼 SMART on FHIR,會成為下一世代醫療應用的關鍵基礎

這篇文章,想用一個已經實際落地、通過衛福部沙盒測試的 SMART on FHIR 應用實例,來完整說明:

  • SMART on FHIR 是什麼?
  • 為什麼現在才「做得到」?
  • 過去為什麼這類醫療 AI 應用極度困難?
  • 對醫院、資訊單位、臨床與管理層的真正價值是什麼?
  • 耀瑄科技新創小組,已經做到哪些事?

本文將以**「最智慧的非侵入肌肉品質定量系統(身體組成 AI 推論)」**為核心案例,專為:

  • 醫院人員
  • 資訊室 / HIS 團隊
  • 臨床醫師、研究人員
  • 第一次接觸 SMART on FHIR 的初心者

而寫。


一、這是一個什麼樣的 SMART on FHIR 應用?

這是一套 結合醫學影像(DICOM)與 AI 推論 的臨床應用系統,主要目標是:

用既有的 CT 影像,非侵入式地量化病人的肌肉品質與身體組成狀態

系統能做什麼?

  • 從醫院系統取得病人基本資料(透過 FHIR)

  • 上傳或串接腹部 CT DICOM 影像

  • 由 AI 模型自動辨識:

    • 骨骼肌
    • 脂肪分布
    • 肌肉密度
  • 產生結構化、可追蹤、可比較的量化指標

例如:

  • SMI(骨骼肌指數)
  • SMD(骨骼肌密度,HU)
  • IMAT(肌間脂肪)
  • LAMA / NAMA
  • Myosteatosis(肌肉脂肪變性)

👉 這不是單純影像展示,而是「臨床可用的數據化 AI 結果」。


二、為什麼要用 SMART on FHIR 來做這件事?

關鍵一句話先給你:

SMART on FHIR 解決的,不是 AI 做不到,而是「AI 無法順利進入臨床系統」的問題。


三、過去為什麼這類應用「幾乎做不到」?

1️⃣ 病人身分與影像系統完全分離

傳統狀況:

  • 病人資料在 HIS / EMR
  • 影像在 PACS
  • AI 系統通常是「外掛工具」

結果是:

  • 病人對不起來
  • 研究能做,臨床難用
  • 無法成為正式醫療流程的一環

2️⃣ AI 結果「回不去」臨床系統

即使 AI 分析完成:

  • 結果多半只是一張圖
  • 或一份 PDF
  • 或存在某個獨立資料庫

👉 無法被 EMR / HIS / 臨床系統真正使用


3️⃣ 每家醫院、每套系統都要重做一次

沒有標準:

  • 病人 ID 不同
  • 欄位定義不同
  • API 規格不同

👉 導致 AI 只能停留在 POC 或研究階段


四、SMART on FHIR 做對了哪三件關鍵的事?


✅ 第一件事:用「標準方式」進入醫院系統

SMART on FHIR 提供:

  • 標準 OAuth 2.0 認證流程
  • EHR Launch / Standalone Launch
  • 明確的使用者與病人上下文(Context)

也就是:

AI App 不再是「外掛」,而是正式的醫療應用程式


✅ 第二件事:所有資料都有「FHIR 語言」

在這個系統中:

  • 病人基本資料 → Patient
  • 就診脈絡 → Encounter
  • AI 推論結果 → Observation
  • 影像關聯 → ImagingStudy

👉 AI 結果第一次成為「FHIR 資源」,而不是附件


✅ 第三件事:一次開發,多院可用

只要醫院:

  • 有 FHIR Server
  • 或有 FHIR Gateway

這個 SMART on FHIR App 就可以:

  • 不改程式
  • 不重寫邏輯
  • 直接部署

👉 這是醫療 App 生態系的起點


五、對醫院來說,SMART on FHIR 的價值在哪?

🏥 對臨床人員

  • 不需要學新系統
  • AI 結果就在熟悉的臨床流程中
  • 可以追蹤病人變化,而非單次判讀

🧑‍💼 對管理層

  • AI 不再是展示用

  • 而是可以納入正式醫療服務

  • 可用於:

    • 高齡醫療
    • 癌症治療評估
    • 術前風險評估
    • 長期照護指標

💻 對資訊單位

  • 不必一次汰換 HIS
  • 不必被單一廠商綁死
  • 可以逐步引入創新應用

六、這個系統,為什麼特別有代表性?

因為它同時具備:

  • ✅ AI 實際臨床價值
  • ✅ SMART on FHIR 正規整合
  • ✅ 通過衛福部沙盒測試
  • ✅ 可擴充、可商品化

這代表:

SMART on FHIR 已經不是未來式,而是現在進行式


七、耀瑄科技新創小組的 FHIR & SMART on FHIR 研發成果

耀瑄科技新創小組,並不是只做一個 App,而是持續投入在:

🔹 FHIR 基礎建設

  • FHIR Server 規劃
  • FHIR Gateway 與既有 HIS 串接
  • 病人為主的資料模型設計

🔹 SMART on FHIR 應用

  • 病人時序圖應用
  • AI 身體組成分析
  • 臨床研究支援工具

🔹 AI × 醫療整合

  • DICOM → AI → FHIR
  • 結果結構化、可回寫、可追蹤
  • 真正進入臨床流程

八、給第一次接觸 SMART on FHIR 的你,一個簡單結論

FHIR 解決的是「資料怎麼來」 SMART on FHIR 解決的是「應用怎麼進來」

當這兩件事都被解決:

  • AI 才能真正落地
  • 創新才能規模化
  • 醫療系統才能真正進化

九、結語:SMART on FHIR,不只是技術,而是一種「新秩序」

SMART on FHIR 帶來的不是:

  • 一個新標準
  • 一個新 API

而是:

讓醫療應用可以像 App Store 一樣被建立、被選擇、被淘汰、被進化

而耀瑄科技新創小組,正站在這個轉折點上。