📚 课程目录第1章 FHIR交换工程全景

1. FHIR交换工程全景

要理解FHIR在医疗数据交换工程中的位置，最有效的方式不是孤立地看FHIR规范，而是把它放回医疗互操作的演进链条中：HL7 v2解决了“系统之间能传消息”，CDA解决了“文档能被人和系统共同理解”，而FHIR要解决的是“在互联网级架构下，临床数据能以资源为单位被查询、组合、订阅和治理”。这三者不是简单的替代关系，而是不同历史阶段对互操作粒度和工程可控性的不同回答。

三代标准的工程定位差异

HL7 v2诞生于医院内部系统集成的年代，核心形态是事件驱动的消息，例如患者入院触发ADT^A01，检验结果发布触发ORU^R01。它的优势是部署广泛、实现成本低、消息语义在科室集成中被大量验证；但它的字段位置依赖段（Segment）和序号，版本间兼容性靠Z段和本地约定维持，缺乏统一的资源标识和查询模型。CDA则把交换单位从“消息”提升为“临床文档”，通过

、和模板ID（templateId）表达文档结构与语义约束，适合病历摘要、出院小结等需要完整性和法律效力的场景。但CDA本质是文档交换，难以支持“只取某个患者最近三次糖化血红蛋白”这类细粒度查询。

FHIR的设计选择正是针对这些痛点：把临床内容抽象为可独立寻址的资源（Resource），如Patient、Observation、Encounter、MedicationRequest；用RESTful API暴露资源；用统一的数据类型、编码系统和扩展机制保证语义可计算。换句话说，HL7 v2交换的是“消息”，CDA交换的是“文档”，FHIR交换的是“资源及其关系”。

FHIR的四个工程支柱

FHIR之所以能成为当前互操作工程的主流选择，依赖四个相互支撑的设计支柱。第一是资源模型：每个资源有明确的边界和必选/可选元素，例如Observation必须包含code和status，subject指向Patient，effectiveDateTime或effectivePeriod表达时间。第二是RESTful API：以HTTP动词和URL路径表达操作，GET /Patient/123读取患者，GET /Observation?patient=123&code=4548-4查询该患者的糖化血红蛋白，POST /Patient创建资源。第三是互操作层：通过CapabilityStatement声明服务器支持哪些资源、哪些交互、哪些搜索参数，通过ImplementationGuide约束本地化用法。第四是工程化落地边界：FHIR规范本身不规定部署拓扑、不规定身份认证方式、不规定性能指标，这些必须由工程团队在具体项目中补齐。

一个常见的误解是“用了FHIR就自动互操作”。实际上，FHIR只提供了语法和交互框架，语义一致性仍要靠术语绑定（如LOINC、SNOMED CT）、Profile约束和业务规则来保证。例如，同样是Observation，不同厂商可能把血压拆成两个组件，也可能放在一个组件里，如果没有ImplementationGuide约束，接收方仍然无法可靠解析。

从交换到工程：一个最小可运行示例

假设我们要让一个检验系统向FHIR服务器发布一份血常规结果。检验系统内部已有患者ID、检验项目代码、结果值和单位。工程上需要完成三步映射：患者标识映射到Patient.identifier，检验项目映射到Observation.code（推荐LOINC），结果值映射到Observation.valueQuantity。发布时使用POST请求：

POST /Observation
Content-Type: application/fhir+json

{
  "resourceType": "Observation",
  "status": "final",
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "718-7",
      "display": "Hemoglobin [Mass/volume] in Blood"
    }]
  },
  "subject": { "reference": "Patient/123" },
  "valueQuantity": {
    "value": 135,
    "unit": "g/L",
    "system": "http://unitsofmeasure.org",
    "code": "g/L"
  },
  "effectiveDateTime": "2025-03-18T09:20:00+08:00"
}

服务器返回201 Created，并在Location头中给出新资源的完整URL。此时查询GET /Observation?patient=123&code=718-7即可取回该结果。这个最小闭环说明：FHIR交换工程的关键不在“发一个JSON”，而在于标识、术语、时间、单位和状态这些字段是否与接收方约定一致。

判断一个FHIR接口是否真正可互操作，可以检查三件事：CapabilityStatement是否声明了目标资源和搜索参数；资源中的编码是否绑定到公开术语系统；时间、单位、状态是否使用FHIR规定的数据类型而非自定义字符串。

工程化落地的边界与取舍

FHIR不是银弹。在院内集成中，HL7 v2仍然承担大量实时消息场景，CDA仍然用于文档归档和法定病历交换，FHIR更适合面向互联网的患者访问、跨机构查询、移动应用和科研数据抽取。工程团队需要根据场景选择交换方式，而不是一刀切替换。同时，FHIR落地必须补齐安全（SMART on FHIR、OAuth 2.0）、性能（分页、_include、_revinclude）、版本管理（资源版本与历史）和治理（Profile、术语服务器、审计日志）等工程能力。只有把这些边界想清楚，FHIR才能从规范变成可运行、可运维、可扩展的医疗数据交换基础设施。