醫(yī)療軟件可能是工程領(lǐng)域最復(fù)雜的賽道之一。和普通的SaaS產(chǎn)品不同，這里的每一個字段變更都可能引發(fā)連鎖反應(yīng)——改一個患者ID格式，可能導(dǎo)致保險拒付、用藥錯誤或診療延誤。這也是為什么醫(yī)療工程的核心不是框架選型，而是對行業(yè)標準的深度理解。

普通電商系統(tǒng)里，服務(wù)A改個字段名，影響范圍僅限內(nèi)部。但在醫(yī)院場景下，同一個患者數(shù)據(jù)要在HIS、電子病歷、實驗室系統(tǒng)、影像系統(tǒng)之間無縫流轉(zhuǎn)，任何格式不一致都會出亂子。醫(yī)療工程的真相是：80%的工作是集成工程，而非從零開發(fā)。

HL7 v2至今仍是醫(yī)院集成的絕對主流。它用管道符分隔的文本消息傳遞患者入院、檢驗結(jié)果、醫(yī)囑變更等信息。一個典型的實驗室結(jié)果消息包含消息頭、患者標識、觀察值三段結(jié)構(gòu)。但麻煩在于，不同醫(yī)院對同一字段的填充方式千差萬別——有的用"M"表示男性，有的寫全"Male"。你的集成層必須能識別并歸一化這些差異。Mirth這類接口引擎的價值就在于此：監(jiān)聽端口、解析HL7、轉(zhuǎn)換格式、路由到目標系統(tǒng)。

FHIR是新一代的醫(yī)療API標準。它把RESTful設(shè)計、JSON格式、OAuth認證這些現(xiàn)代工程師熟悉的元素帶了進來。獲取患者信息不再需要調(diào)用各醫(yī)院定制的接口，而是統(tǒng)一走GET /Patient/123。資源類型也標準化了：患者、觀察值、用藥、診斷、預(yù)約、影像研究，每個都有固定的JSON結(jié)構(gòu)。前端甚至可以直接用React或Vue消費FHIR API，這在HL7時代不可想象。

但FHIR的實現(xiàn)并不統(tǒng)一。兩個醫(yī)院都聲稱支持FHIR R4，可能一個用美國核心數(shù)據(jù)集，另一個用英國配置文件，字段必填規(guī)則和術(shù)語編碼完全不同。工程師仍需編寫映射邏輯，不能指望"一次對接，處處通用"。

SMART on FHIR解決了另一個痛點：第三方應(yīng)用如何安全接入醫(yī)院系統(tǒng)。它讓醫(yī)療App能像插件一樣運行在Epic、Cerner等主流電子病歷內(nèi)部，醫(yī)生無需切換界面就能調(diào)用AI輔助診斷工具。OAuth2授權(quán)、上下文傳遞、單點登錄，這些機制保證了數(shù)據(jù)安全和用戶體驗的平衡。

CDA則是文檔交換的標準，基于XML的嵌套結(jié)構(gòu)。一份術(shù)后出院小結(jié)可能包含幾百個標簽，解析和驗證的工作量不小。openEHR走的是另一條路，用雙模型架構(gòu)分離參考模型和臨床模型，更適合需要長期結(jié)構(gòu)化存儲的慢病管理場景。DICOM專屬于醫(yī)學(xué)影像，不僅管圖像格式，還涵蓋存儲、傳輸、工作流管理——PACS系統(tǒng)的核心協(xié)議。

真實醫(yī)院的日常是這些標準的混搭：HL7 v2傳實時消息，F(xiàn)HIR做現(xiàn)代集成，CDA交換文檔，DICOM處理影像，openEHR支撐�？葡到y(tǒng)。工程師的價值不在于記住每個標準的細節(jié)，而是理解它們?yōu)楹未嬖�、何時選用、如何橋接。醫(yī)療軟件的復(fù)雜性，本質(zhì)上是對生命數(shù)據(jù)的敬畏。