医疗领域的软件开发，复杂度远超普通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下无缝协作。