“我构建了这个，这是它的工作原理，这是它的瓶颈所在。”这句直白的坦白，出自一位在澳大利亚寻找FHIR工程师岗位的开发者。几个月前，他在浏览职位描述时发现，几乎每个远程岗位都提到了同一项要求：具备将HL7 v2与FHIR R4集成的经验。这毫不奇怪，澳大利亚乃至全球多数医院仍在依赖HL7 v2标准，患者入院、检验结果、医嘱等数据，均以管道符分隔的消息格式在MLLP协议上流转。然而，澳大利亚数字健康局正通过Sparked FHIR加速器和AU Core框架，强势推动向FHIR R4的迁移。他决定亲手为这两个世界搭建一座桥梁。

他选择了一个具体的切入点：开发一条能够接收真实HL7 v2产科消息，并将其转换为符合同盟国AU配置规范的有效FHIR R4资源的工作管道。目标很明确，这不是玩具项目，也不是入门教程，而是一个能在面试中展示的真实集成。整个项目的源代码已托管在GitHub上。他大方地分享了设计过程，并特别强调了其中踩过的坑。

他最初的方案思路简单到有些幼稚。设想中，HL7 v2消息传入，用Python解析，手动构建FHIR JSON，然后将其发送到FHIR服务器，流程便宣告结束。他很快写出了一个脚本，并成功处理了一条ADT^A01（患者入院）消息。那种感觉很不错，直到真正的麻烦一个接一个地浮现。他后来将这种只处理最理想情况的构建方式称为“又犯了快乐路径的老毛病”。

第一个失败点是根本无法在真实环境中运行。他的脚本从文件读取消息，而现实中的医院系统根本不发送文件，它们通过MLLP协议——一种基于TCP、带有特定帧格式的协议——实时发送HL7消息。脚本完全没有能力接收实时消息，这意味着它一出生就脱离了实际应用场景。第二个问题是脆弱得不堪一击的解析逻辑。他最初的实现方式是靠分割管道符并数位置来提取字段。只要出现一个意想不到的空字段，整个映射关系就会全部错位。他举了一个具体的例子：如果消息中的PID-6字段有娘家姓，但PID-5.4（后缀）字段为空，解析脚本会毫无征兆地将错误的数据填入错误的FHIR字段里。

第三个问题出在完全没有校验机制。他是在用Python字典手工构建FHIR JSON，这意味着如果字段名出现笔误，或者遗漏了某个必填元素，脚本会高高兴兴地向FHIR服务器发送无效资源。服务器的反应不一，时而照单全收，时而又抛出令人费解的错误。这种不确定性本身就是灾难。第四个问题是缺失了多资源关联。一次产科就诊涉及患者、就诊记录、观察指标（如血压、体重、胎心）以及诊断状况（如妊娠诊断）等多个资源，这些资源本应相互引用。他的脚本却独立创建每个资源，彼此之间毫无关联，导致观察记录根本不知道自己属于哪次就诊。

第五个问题让事后追溯成为不可能，因为整个过程没有留下任何错误追踪。如果患者资源创建成功，但观察记录创建失败，他既没有任何记录说明失败原因，也无法在原消息和失败事件之间建立关联，更不可能重放那条失败的消息。至此，这条最初的架构彻底宣告了失败。