醫療軟件工程師必須掌握的六大標準

　　醫療領域的軟件開發，復雜度遠超普通SaaS。一個字段名的改動，在電商系統里只影響內部服務；在醫療場景下，錯誤的患者標識符格式可能導致治療延誤、保險拒賠，甚至法律風險。這就是為什么醫療工程的核心不是框架選型，而是標準合規。

　　醫療系統的本質是集成工程。典型的醫院環境里，電子病歷（EHR）、實驗室系統（LIS）、影像歸檔（PACS）、保險平臺四個異構系統必須實時交換同一患者的臨床數據——哪怕它們底層技術棧完全不同。一條入院流程可能同時涉及HL7消息、FHIR接口、DICOM影像、CDA文檔四種標準。

　　HL7 v2至今仍是醫院集成的主流標準，覆蓋患者入院、檢驗結果、醫囑傳遞等場景。它的消息格式看起來像這樣：MSH|^~\&|LAB|HOSPITAL|EHR|HOSPITAL，PID|1||12345||DOE^JOHN，OBX|1|NM|WBC||5.4。這段文本包含消息頭、患者身份、觀察結果三層結構。工程師的日常不是寫消息，而是做映射——一家醫院傳"M"，另一家傳"Male"，集成層必須都能識別為同一性別。Mirth這類接口引擎的價值就在于此：接收HL7、轉換格式、過濾字段、路由到目標系統。

　　FHIR是新一代的API標準。它把GET /patientInfo?id=123這類私有接口，統一成GET /Patient/123的可預測格式。返回的JSON結構清晰：{"resourceType": "Patient", "id": "123"}。Patient、Observation、MedicationRequest等資源類型覆蓋了醫療核心實體。REST設計、JSON格式、OAuth安全——這些現代工程師熟悉的元素，降低了入門門檻。前端甚至可以直接用React或Vue消費FHIR接口。但實現層面仍有坑：兩家醫院都聲稱支持FHIR，可能一個用R4版本、一個用DSTU2；一個暴露50個字段、另一個只給20個。映射邏輯依然省不掉。

　　SMART on FHIR解決了更深的問題：第三方應用如何安全嵌入Epic、Cerner這類主流EHR？它提供了一套"插件化"機制——醫生直接在熟悉的系統界面里打開AI輔助診斷工具，無需切換登錄，數據權限由醫院管控。

　　CDA處理的是文檔交換。術后出院小結、轉診報告這類場景，需要一份結構化的XML文檔跨機構流轉。簡單的患者摘要也可能膨脹為數百個嵌套標簽，解析和驗證都是硬骨頭。

　　openEHR的定位與眾不同：它關注長期健康數據的結構化存儲，而非系統間傳輸。通過"原型"（archetype）機制，把血壓、血糖等臨床概念定義為可復用的數據模型，支持幾十年的患者隨訪記錄管理。

　　最后提一句DICOM——醫療影像的通用語言。CT、MRI、X光片的存儲、傳輸、顯示都依賴它，一個檢查可能產生數百MB的多幀圖像。

　　六個標準，六個不同的 problem space。HL7 v2和FHIR管消息流動，CDA管文檔交換，DICOM管影像，openEHR管長期數據建模。醫療工程師的價值，往往體現在讓這些標準在同一個患者ID下無縫協作。