因為工作關係，忙到沒空寫文，拖稿拖了好久......

FHIR 是什麼，能吃嗎？

為什麼會有 FHIR？

基本上 FHIR 主要就是要解決跨系統／跨裝置的資料交換問題。

以臺灣來說，現行各家醫院／醫療照護機構的系統通常是由不同廠商提供，由於是不同廠商開發的軟體，底層資料結構、格式可能不一樣。這就導致了當這些系統間有資料交換的需求時，會因為這像限制導致各系統間無法有效進行介接，而必須另外寫程式進行轉換才能完成資料交換這件事情。當中資料的結構、介接時使用的介面（Interface）、欄位的規則與限制都是需要在轉換過程中反覆被提出來討論的東西，也因此會花上很多人力與時間成本。事實上，現在一家系統／產品要進到醫院內與院內其他系統整合，平均需要花大約兩個月的時間。

上述的問題可說是現行醫療行業的困境，且並不僅限於台灣。為了解決這樣的問題，醫療行業勢必需要一套醫療資料交換標準來支撐互聯互通的需求。這樣的需求從早期僅支援醫院工作流程，發展到現在已經不僅針對醫院，而是需要擴大至所有健康照護領域，並且要具備處理臨床與非臨床資料的能力。FHIR 就是在這個時空背景下的產物。

換句話說，FHIR 就是醫療界的 USB，讓我們可以用一個通用的醫資標準 + 通用的互操作性存取機制來交換所有跟醫療有關的資料。

FHIR 相較於現行電子病歷標準的優勢

• 通用性：FHIR 標準目前在國外被廣泛應用，而目前健保是參考 CDA R2 魔改成 108 個單張（實際上醫院真正會交換到的東西不到 20 張），拿出去國際基本上沒人會鳥你。
• 精簡性：FHIR 採用的欄位格式更精簡、可讀性更高。（Schema 規劃更簡單易用）
• 可靠性：FHIR 使用現代主流的資料交換技術（HTTPS + REST API），並使用主流的 Oauth 2.0 作為建議的標準化授權認證機制，安全性更有保障。
• 可擴展性：FHIR 擁有相當高度的可擴展性，沒有被 FHIR 規範在內的資料可以透過 Extenstion 欄位自行擴充。
• 一致性：你可以在 FHIR 裡面，為特定應用情境／場域撰寫 Profile 及 Integration Guide（IG，實作指引），來讓所有使用這個情境的系統都能有最高度的標準化及一致性。
• 跨裝置：FHIR 能廣泛應用在各類裝置上，就連蘋果也早在 iOS 10 就開始支援 FHIR（低頭看看你 iPhone 上的健康 APP 吧！） （可惜我沒有 iPhone）

基本概念

FHIR 架構與資料結構

• FHIR 把你在進行醫療工作流程中，所有會接觸到的資料都標準化為單一個資料結構（Data Structure）。
• FHIR 依照不同資料的性質進行歸檔，並把相關的資料整理成一個 Resource。
  • 例如病人的姓名、生日、地址等資料都歸類在 Patient Resource 裡面）
• 依照各 Resource 的分類，FHIR 將幾個 Resource 組成一支 Module 方便檢視。
  • 例如 Patient、Organization、Encounter 這幾個 Resource 是其他更高層 Resource 會需要依賴的底層 Resource，因此一起歸類為 Administration Module。
• 各 Module 依照抽象化程度，組成 Level 1 ~ Level 5 等層級，層級越高抽象化程度越高，也越貼近應用面。
  

以工程的角度重新認識 FHIR

• 我們認知的 FHIR，基本上就是一串 Data Model。
• 每個 FHIR Resource (Data Model) 都有固定的 Data Structure（schema）。
• 這些 Data Structure 可以被支援以不同的 Data Format 呈現。
• FHIR 使用主流的 REST API 作為 Interface 與其他系統介接。
  • 實際上不只有 REST API，不過在應用初期這會是最常碰到的交換方式
    

80-20 原則

• FHIR Resource 幫你規劃好 80% 絕大多數系統會常用到的欄位（例如病人的姓名、生日、地址這類常用欄位），剩下 20% 客製化／本地化的資料提供一個 Extension 欄位讓你自己定義跟擴充。
• 換言之，你可以用 20% 的時間去完成那些通用欄位的交換需求，拿剩下 80% 的時間專注在你自己的業務邏輯上。
• 好處就是可讀性高，並且省下非常多規劃 Schema 跟 Interface 的時間跟人力。
  

下一篇文章將會講導讀，帶各位看懂 FHIR 官方的文件。