简而言之： CDA 提供一个文档：一个关于单个患者在特定时间点的签名 XML 文件，其中包含人类可读的叙述和计算机可读的条目，该文件必须保持完整且不变。 FHIR 提供资源：一个患者、四十个观察结果、三个病症，每个都有自己的 URL，可以通过 REST API 独立获取、搜索和更新。FHIR 还可以将资源打包成一个文档（类型为 document 的 Bundle，由 Composition 引导），这是 CDA 的直接等效项。在法规或合作伙伴要求使用 CDA 时选择 CDA；在需要 API、应用程序以及任何需要查询而非阅读的内容时选择 FHIR。
两种形式
CDA 和 FHIR 有两种不同的形式。CDA 交换基于 HL7 v3 数据类型构建的整个 XML 文档，由 OID 标识，包含强制性叙述，不支持查询、更新和整个文档签名。FHIR 交换单个 JSON 或 XML 资源或 Bundle，由规范 URL 标识，内置 REST 查询、版本化更新，并在实施指南中发布配置文件。
| CDA / C-CDA | FHIR | |
|---|---|---|
| 交换单元 | 整个文档 | 资源，或资源的 Bundle |
| 格式 | XML，HL7 v3 数据类型 | JSON 或 XML，FHIR 数据类型 |
| 标识 | 模板和代码系统的 OID | 配置文件和代码系统的 URL（规范） |
| 人类可读部分 | 每个部分都必须包含 <text> |
每个资源可选的 text.div 叙述；文档中必须包含 |
| 传输 | 未定义；通过 XDS、Direct、MLLP、电子邮件传输 | 标准定义的通过 HTTPS 的 REST；也支持消息和文档 |
| 查询 | 文档内部无法查询；注册表索引头部 | 内置功能：GET /Observation?patient=…&code=… |
| 更新 | 从不；新文档替换旧文档 | 资源是版本化的，原地更新 |
| 签名 | 整个文档，XML-DSig | 可以签名整个 Bundle；单个资源很少签名 |
| 配置文件 | 每个部分和条目的模板（templateId） | 每个资源的 StructureDefinition 配置文件，在实现指南中发布 |
| 术语 | LOINC 部分代码，SNOMED/ICD/RxNorm 条目 | 相同的代码系统，作为 CodeableConcept |
实际差异意味着什么
实际上，CDA 和 FHIR 之间的区别在于，CDA 适用于一次性编写并完整保存的内容，例如签名的出院小结；而 FHIR 适用于不断增长并需要查询的数据，例如一系列血压记录。CDA 的接收方可以显示，但必须进行协调才能导入；FHIR 的接收方则直接获取与其自身记录格式一致的资源。
出院小结自然是一个文档：它一次性编写，由一位医生签名，并且多年后必须能够准确地重现其阅读内容。血压系列自然是一组资源：它每天都在增长，会被绘制和过滤，没有人会对其进行签名。CDA 能很好地处理前者，但对后者处理不佳（每次新读数都需要重新发送整个文档）。FHIR 原生处理后者，并通过其文档机制处理前者。
另一个实际区别是接收者能做什么。CDA 接收者始终可以显示文档；导入其条目需要逐节进行协调。FHIR 接收者获得与其自身记录形状相同的资源；棘手的问题转移到身份（这是同一个人吗？）和来源（谁在何时断言了这一点？）上。请参阅 患者匹配。
FHIR 文档：交汇点
FHIR 文档是一个类型为 document 的 Bundle，其第一个条目是 Composition。Composition 扮演着 CDA 头部和节列表的角色：类型（LOINC）、日期、作者、主题、保管者、状态以及 section[]，其中包含标题、代码、叙述文本以及指向承载数据的资源的引用。
{
"resourceType": "Bundle",
"type": "document",
"identifier": {"system": "urn:ietf:rfc:3986", "value": "urn:uuid:3f2d7a3e-…"},
"timestamp": "2026-03-14T10:15:00+01:00",
"entry": [
{"fullUrl": "urn:uuid:comp-1", "resource": {
"resourceType": "Composition", "status": "final",
"type": {"coding": [{"system": "http://loinc.org", "code": "60591-5", "display": "Patient summary Document"}]},
"subject": {"reference": "urn:uuid:pat-1"},
"date": "2026-03-14T10:15:00+01:00",
"author": [{"reference": "urn:uuid:prac-1"}],
"title": "Patient summary",
"section": [{
"title": "Allergies and intolerances",
"code": {"coding": [{"system": "http://loinc.org", "code": "48765-2"}]},
"text": {"status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>Penicillin: rash</p></div>"},
"entry": [{"reference": "urn:uuid:allergy-1"}]
}]
}},
{"fullUrl": "urn:uuid:pat-1", "resource": {"resourceType": "Patient", "id": "pat-1"}},
{"fullUrl": "urn:uuid:prac-1", "resource": {"resourceType": "Practitioner", "id": "prac-1"}},
{"fullUrl": "urn:uuid:allergy-1", "resource": {"resourceType": "AllergyIntolerance", "id": "allergy-1", "patient": {"reference": "urn:uuid:pat-1"}, "code": {"coding": [{"system": "http://snomed.info/sct", "code": "764146007", "display": "Penicillin"}]}}}
]
}
国际患者摘要正是如此：一个 FHIR 文档配置文件，带有 CDA 孪生版本，供仍需要它的系统使用。另请参阅 FHIR Bundle 详解。
相互转换
CDA 和 FHIR 之间的相互转换在一定程度上是可行的。HL7 C-CDA on FHIR 实施指南将文档类型、章节和条目映射到 Composition 配置文件和资源；仅包含叙述的章节将转换为不包含数据的文本。FHIR 到 CDA 的转换适用于符合 C-CDA 模板的资源。无论哪种方向，原始文档都应作为带有 Provenance 的 DocumentReference 进行保存。
- CDA → FHIR： HL7 C-CDA on FHIR 实现指南将美国的文档类型和节映射到 Composition 配置文件；条目映射到资源（Problem Concern Act → Condition，Medication Activity → MedicationStatement，Result Observation → Observation）。对于结构良好的 Level 3 内容，映射是确定的；对于仅叙述的节，映射是有损的，它们会变成没有数据的文本。
- FHIR → CDA： 对于其资源符合 C-CDA 模板的文档，这是可能的。从未被设计为文档的自由格式 FHIR 资源（例如可穿戴设备的观察结果流）不会变成有意义的 CDA。
- 保留原始文件。 无论转换哪个方向，都应将接收到的源文件作为 DocumentReference 存储，并让 Provenance 指向转换后的资源。转换是一种视图，而不是替换。
何时 CDA 仍是正确答案
当接收方要求时（例如美国的转诊过渡、MyHealth@EU 患者摘要和电子处方，以及一些国家的文档注册中心)，当内容在法律上是必须签名并完整保存的文档时，或者当合作伙伴的基础设施是 IHE XDS（索引文档而非资源)时，CDA 仍然是正确的选择。否则，应优先考虑 FHIR。
当接收方要求时（例如，美国过渡护理、当前的 MyHealth@EU 患者摘要和电子处方，以及一些国家文档注册表）；当内容在法律上是一个必须完整签名和保存的文档时；当合作伙伴的基础设施是 IHE XDS，它索引文档而不是资源时。在所有其他情况下，从 FHIR 开始，并在需要文档的地方生成 FHIR 文档。
相关页面
来源
常见问题
FHIR 文档只是 JSON 格式的 CDA 吗？
不是。它遵循相同的原则（完整、签名、人类可读、带有头部），但其内容是普通的 FHIR 资源，因此同一个 Observation 可以存在于文档中，也可以通过 API 提供。在 CDA 中，条目仅存在于其文档内部。
我可以为 FHIR 文档签名吗？
可以。Bundle.signature 包含对 bundle 的数字签名，IPS 和国家指南对此进行了描述。实际上，许多部署依赖于传输安全和来源而不是签名。
FHIR 有 templateId 吗？
等效的是 meta.profile，它是资源声称符合的 StructureDefinitions 的规范 URL 列表。验证器以与 CDA schematrons 检查模板相同的方式检查符合性。
新的国家项目应该选择哪个？
近期的项目（例如 EHDS 交换格式、美国患者访问规则、IPS）都选择 FHIR，使用 FHIR 文档来处理摘要和信函，并且仅为遗留合作伙伴保留 CDA 路径。
在沙盒中免费试用
5 分钟完成第一次 FHIR 调用. 一个内置患者授权的 HL7 FHIR R4 API：先在沙盒中试用，然后连接您自己的应用或诊所系统。
免费 · 30 位合成患者 · 无需信用卡
Anpheros 致力于打造一个由患者掌控的医疗记录，并可在欧盟的 HL7 FHIR R4 平台上与任何诊所共享。这些指南旨在帮助您理解和整理您的健康信息，但不能替代您的医生。
关于 Anpheros →