HL7 FHIR把140種數據模型塞進REST接口

全球醫療數據互通率長期卡在個位數。HL7 FHIR用140+標準化資源類型（Resource Types）和RESTful API架構，把醫院、保險、穿戴設備的數據格式統一成JSON/XML交換協議——這相當于給醫療IT系統發了一張通用語翻譯卡。

HL7 FHIR（Fast Healthcare Interoperability Resources，快速醫療互操作資源）由Health Level Seven International組織開發。它不像傳統HL7 v2/v3那樣用管道符分隔的文本消息，而是直接基于HTTP協議、OAuth 2.0認證和SMART on FHIR應用框架，讓第三方App能像登錄微信一樣接入醫院系統。

140種資源類型：從患者基本信息到基因測序

FHIR的資源類型覆蓋醫療全流程。Patient（患者）、Observation（觀測值）、Medication（藥物）是三大高頻類型，但完整清單延伸到Encounter（就診記錄）、DiagnosticReport（診斷報告）、Immunization（疫苗接種）、Specimen（標本）甚至MolecularSequence（分子序列）。

每種資源都有固定JSON結構。以Observation為例，必須包含status（狀態）、code（LOINC編碼）、subject（關聯患者）三個核心字段，valueQuantity或valueString承載實際數值。這種強制Schema讓不同廠商的系統能互相解析，而不是像過去那樣猜字段含義。

資源類型的粒度設計很產品經理思維：既足夠原子化以便組合，又避免拆得太碎導致查詢爆炸。

版本迭代上，R4（4.0.1）是當前生產環境標準，美國CMS（醫療保險和醫療補助服務中心）強制要求認證EHR系統支持。R5還在草案階段，R4B是給早期嘗鮮者的過渡版，DSTU2已進墳墓只供遺留系統考古。

RESTful API：用HTTP動詞操作醫療數據

FHIR的URL設計遵循「https://fhir-server.com/fhir/{resourceType}/{id}」模式。GET /Patient/123取患者檔案，POST /Observation上傳血壓讀數，PATCH做局部更新，DELETE走合規刪除流程——全是標準HTTP語義，前端工程師零學習成本。

搜索參數是隱藏大招。GET /Observation?patient=123&code=8867-4能精確撈出某患者的體溫記錄，_sort、_count、_include控制排序分頁和關聯資源預加載。相比HL7 v2的查詢黑箱，這相當于從電報機升級到搜索引擎。

CapabilityStatement（能力聲明）是服務發現機制。調/metadata端點，服務器返回支持的資源類型、搜索參數、認證方式——客戶端能動態適配，不用硬編碼接口文檔。

云廠商押注：Azure和AWS的FHIR即服務

微軟Azure API for FHIR把部署簡化為四步：Portal創建服務、配置Azure AD OAuth、記下端點URL、注冊Client App。AWS HealthLake走IAM角色授權路線，數據湖架構適合批量分析場景。

兩家都處理了最臟的活：HIPAA合規審計日志、加密存儲、自動擴縮容。醫院IT團隊不用再養一個專門維護FHIR服務器的工程師小組——這成本結構變化，會加速中小醫療機構的接入意愿。

SMART on FHIR（Substitutable Medical Applications, Reusable Technologies）是生態催化劑。它定義了App啟動上下文（當前患者、當前就診）、權限范圍（讀/寫哪些資源類型）、單點登錄流程。Epic、Cerner等主流EHR已支持，意味著一個糖尿病管理App可以一次開發，跑遍全美醫院。

國內醫療信息化廠商的跟進速度值得關注。東軟、衛寧健康、創業慧龍的產品線中，FHIR支持多停留在「兼容」而非「原生」層面——接口轉換層增加了延遲和故障點。140種資源類型的完整實現，需要重構底層數據模型，這不是貼個適配器能解決的。

HL7 FHIR技術委員會2024年的工作重點是R5定稿和訂閱機制（Subscription）增強。后者讓客戶端能實時接收特定資源變更推送，從輪詢polling模式轉向事件驅動——這對ICU監護、急診分診等實時場景很關鍵。

醫療數據互通的瓶頸從來不是技術可行性，而是利益博弈。FHIR用開放標準降低協作門檻，但醫院愿不愿意開放接口、保險公司接不接收外部數據、患者隱私授權怎么設計，仍是人的問題。140種資源類型擺在那里，用多少、怎么用，各機構的選擇會暴露真實意圖。

最后一個細節：FHIR的JSON格式允許擴展（Extension），用于承載各地特有的數據字段。中國版可能加入中醫證型、醫保支付編碼——標準框架的本土化填充，會是下一階段各廠商的角力場。你的電子健康檔案，準備好被140種格式拆解了嗎？