医疗软件可能是工程领域最复杂的赛道之一。和普通的SaaS产品不同，这里的每一个字段变更都可能引发连锁反应——改一个患者ID格式，可能导致保险拒付、用药错误或诊疗延误。这也是为什么医疗工程的核心不是框架选型，而是对行业标准的深度理解。

普通电商系统里，服务A改个字段名，影响范围仅限内部。但在医院场景下，同一个患者数据要在HIS、电子病历、实验室系统、影像系统之间无缝流转，任何格式不一致都会出乱子。医疗工程的真相是：80%的工作是集成工程，而非从零开发。

打开网易新闻 查看精彩图片

HL7 v2至今仍是医院集成的绝对主流。它用管道符分隔的文本消息传递患者入院、检验结果、医嘱变更等信息。一个典型的实验室结果消息包含消息头、患者标识、观察值三段结构。但麻烦在于，不同医院对同一字段的填充方式千差万别——有的用"M"表示男性，有的写全"Male"。你的集成层必须能识别并归一化这些差异。Mirth这类接口引擎的价值就在于此：监听端口、解析HL7、转换格式、路由到目标系统。

FHIR是新一代的医疗API标准。它把RESTful设计、JSON格式、OAuth认证这些现代工程师熟悉的元素带了进来。获取患者信息不再需要调用各医院定制的接口，而是统一走GET /Patient/123。资源类型也标准化了：患者、观察值、用药、诊断、预约、影像研究，每个都有固定的JSON结构。前端甚至可以直接用React或Vue消费FHIR API，这在HL7时代不可想象。

但FHIR的实现并不统一。两个医院都声称支持FHIR R4，可能一个用美国核心数据集，另一个用英国配置文件，字段必填规则和术语编码完全不同。工程师仍需编写映射逻辑，不能指望"一次对接，处处通用"。

SMART on FHIR解决了另一个痛点：第三方应用如何安全接入医院系统。它让医疗App能像插件一样运行在Epic、Cerner等主流电子病历内部，医生无需切换界面就能调用AI辅助诊断工具。OAuth2授权、上下文传递、单点登录，这些机制保证了数据安全和用户体验的平衡。

CDA则是文档交换的标准，基于XML的嵌套结构。一份术后出院小结可能包含几百个标签，解析和验证的工作量不小。openEHR走的是另一条路，用双模型架构分离参考模型和临床模型，更适合需要长期结构化存储的慢病管理场景。DICOM专属于医学影像，不仅管图像格式，还涵盖存储、传输、工作流管理——PACS系统的核心协议。

真实医院的日常是这些标准的混搭：HL7 v2传实时消息，FHIR做现代集成，CDA交换文档，DICOM处理影像，openEHR支撑专科系统。工程师的价值不在于记住每个标准的细节，而是理解它们为何存在、何时选用、如何桥接。医疗软件的复杂性，本质上是对生命数据的敬畏。