醫(yī)療領(lǐng)域的軟件開發(fā)，復(fù)雜度遠(yuǎn)超普通SaaS。一個(gè)字段名的改動(dòng)，在電商系統(tǒng)里只影響內(nèi)部服務(wù)；在醫(yī)療場(chǎng)景下，錯(cuò)誤的患者標(biāo)識(shí)符格式可能導(dǎo)致治療延誤、保險(xiǎn)拒賠，甚至法律風(fēng)險(xiǎn)。這就是為什么醫(yī)療工程的核心不是框架選型，而是標(biāo)準(zhǔn)合規(guī)。

　　醫(yī)療系統(tǒng)的本質(zhì)是集成工程。典型的醫(yī)院環(huán)境里，電子病歷（EHR）、實(shí)驗(yàn)室系統(tǒng)（LIS）、影像歸檔（PACS）、保險(xiǎn)平臺(tái)四個(gè)異構(gòu)系統(tǒng)必須實(shí)時(shí)交換同一患者的臨床數(shù)據(jù)——哪怕它們底層技術(shù)棧完全不同。一條入院流程可能同時(shí)涉及HL7消息、FHIR接口、DICOM影像、CDA文檔四種標(biāo)準(zhǔn)。

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

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

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

　　CDA處理的是文檔交換。術(shù)后出院小結(jié)、轉(zhuǎn)診報(bào)告這類場(chǎng)景，需要一份結(jié)構(gòu)化的XML文檔跨機(jī)構(gòu)流轉(zhuǎn)。簡(jiǎn)單的患者摘要也可能膨脹為數(shù)百個(gè)嵌套標(biāo)簽，解析和驗(yàn)證都是硬骨頭。

　　openEHR的定位與眾不同：它關(guān)注長(zhǎng)期健康數(shù)據(jù)的結(jié)構(gòu)化存儲(chǔ)，而非系統(tǒng)間傳輸。通過"原型"（archetype）機(jī)制，把血壓、血糖等臨床概念定義為可復(fù)用的數(shù)據(jù)模型，支持幾十年的患者隨訪記錄管理。

　　最后提一句DICOM——醫(yī)療影像的通用語言。CT、MRI、X光片的存儲(chǔ)、傳輸、顯示都依賴它，一個(gè)檢查可能產(chǎn)生數(shù)百M(fèi)B的多幀圖像。

　　六個(gè)標(biāo)準(zhǔn)，六個(gè)不同的 problem space。HL7 v2和FHIR管消息流動(dòng)，CDA管文檔交換，DICOM管影像，openEHR管長(zhǎng)期數(shù)據(jù)建模。醫(yī)療工程師的價(jià)值，往往體現(xiàn)在讓這些標(biāo)準(zhǔn)在同一個(gè)患者ID下無縫協(xié)作。