1. FHIR资源映射工程导论

FHIR（Fast Healthcare Interoperability Resources）并不是又一个“把医院数据打包成XML”的标准，它试图解决的是医疗信息系统中长期存在的结构性难题：同一份临床事实，在不同厂商、不同科室、不同年代的系统中，被拆成互不兼容的字段、编码和消息。FHIR的核心设计理念可以概括为三句话：以资源为最小可交换单元、以RESTful接口为交互方式、以可扩展数据类型为语义基础。理解这三点，是理解后续所有映射与转换工作的前提。

资源与数据类型的层次结构

FHIR把可交换的医疗信息抽象为“资源”（Resource）。资源是自包含的、有唯一标识的、可独立寻址的JSON或XML对象。例如一个Patient资源代表一位患者的基本身份信息，一个Observation资源代表一次检验或体征测量结果。资源之间通过引用（Reference）建立关系，而不是嵌套复制，这使得数据可以按需组装、按需拉取。

在资源之下，FHIR定义了一套分层的数据类型体系。最底层是原始类型（Primitive Types），如string、boolean、integer、dateTime、code；其上是通用复合类型（General-Purpose Complex Types），如HumanName、Address、ContactPoint、Identifier、CodeableConcept、Quantity、Period；再往上是元数据类型（Metadata Types），如Meta、Narrative、Extension。资源则是由这些类型按特定基数（0..1、0..*、1..1）组合而成的结构。

这种层次结构对映射工程有直接指导意义：映射的粒度首先落在数据类型上，而不是资源上。例如把HL7 V2的PID-5患者姓名映射到FHIR的Patient.name时，真正需要处理的是XPN到HumanName的字段对应、编码系统转换和空值语义；而把OBX-5检验值映射到Observation.value[x]时，核心是判断值类型并选择valueQuantity、valueString还是valueCodeableConcept。

映射与转换在互操作性工程中的定位

互操作性工程通常被拆成三层：语法层解决“能不能解析”，语义层解决“字段含义是否一致”，业务层解决“临床流程是否对得上”。FHIR映射与转换主要工作在语义层，同时向上承接业务规则、向下依赖语法解析。一个常见的误解是把映射等同于“字段改名”：把PID-8改成Patient.gender就结束了。实际上，真正的映射工程要处理四类问题：

• 结构映射：源消息的段、字段、组件如何对应到FHIR资源的路径与基数。例如V2的PID-3可以重复，映射到Patient.identifier时是0..*，但需要决定哪一条作为use=official。
• 编码映射：本地代码、医保代码、LOINC、SNOMED CT之间的转换。例如检验项目“白细胞计数”在本地是WBC，映射到Observation.code时需要给出http://loinc.org|6690-2。
• 值域映射：枚举值、单位、日期格式的规范化。例如性别M/F到male/female，体温℃到Cel。
• 语义补偿：源系统缺失或歧义时，用扩展（Extension）、dataAbsentReason或unknown编码显式表达，而不是留空。

因此，映射与转换不是一次性脚本，而是一套可版本化、可测试、可回归的工程资产。它通常以映射规则表、转换脚本、测试用例集和差异报告的形式存在。

典型项目生命周期与角色分工

一个FHIR映射项目通常经历六个阶段：范围界定 → 源系统剖析 → 目标轮廓选择 → 映射规则设计 → 转换实现与测试 → 上线与回归。每个阶段都有明确的输入和输出，而不是“先写代码再说”。

以“把某医院LIS的检验报告接入区域FHIR平台”为例。范围界定阶段要明确只做DiagnosticReport+Observation，还是连带Specimen和Patient；源系统剖析阶段要拿到LIS的接口文档、实际报文样本和代码字典；目标轮廓选择阶段要确定使用FHIR R4的Observation还是R5，以及是否采用US Core或IPS轮廓；映射规则设计阶段要产出字段级对照表；转换实现阶段要写解析器、映射器和校验器；上线后还要持续监控OperationOutcome中的校验错误。

角色分工上，通常需要临床信息专家确认语义正确性，接口工程师负责解析与传输，映射工程师负责规则设计与转换实现，测试工程师负责构造边界用例和回归验证，平台运维负责FHIR服务器的可用性与审计。小团队中一人可兼多角，但职责边界必须在映射规则文档中写清楚，否则出现“字段对错了但没人负责”的情况。

从“能转换”到“可验证”

判断一个映射是否合格，不能只看转换后JSON能否通过FHIR校验器。更实用的判断依据是：用同一份源数据重复转换，结果是否稳定；用边界数据（空值、超长、特殊字符、多编码）转换，是否产生可解释的OperationOutcome；用目标轮廓校验，是否满足必须字段和术语绑定。例如Observation.status是必须字段，如果源系统没有对应状态，映射规则必须显式给出默认值或标记为unknown，而不是让转换器抛异常。