CDAとFHIR：ドキュメントとリソースの違い、使い分け、相互変換の方法

簡単な回答: CDAは、1人の患者に関する、人間が読める記述とコンピューターが読めるエントリーを含む、署名済みのXMLファイル1つを、ある一時点での情報として提供します。このファイルは、全体として変更されずに保持される必要があります。一方、FHIRは、それぞれ独自のURLを持つリソース（患者、40件の検査結果、3件の病状など）を提供し、REST APIを通じて個別に取得、検索、更新できます。FHIRは、リソースをドキュメント（Compositionによって主導されるdocumentタイプのBundle）としてパッケージ化することもでき、これはCDAに直接相当します。規制やパートナーがCDAを要求する場合はCDAを選択し、API、アプリ、または検索が必要なものにはFHIRを選択してください。

二つの形式

CDAとFHIRは、形状が異なります。CDAは、OIDで識別され、必須のナラティブ（本文）を持ち、クエリや更新ができず、文書全体に署名するHL7 v3データ型を基にしたXMLドキュメント全体を交換します。FHIRは、RESTによるクエリ機能が組み込まれ、バージョン管理された更新が可能で、実装ガイドで公開されたプロファイルを持つ、個々のJSONまたはXMLリソースまたはバンドルを交換します。

実際における違いの意味

実際には、CDAとFHIRの違いは、CDAは一度作成され、署名付き退院サマリーのように全体として保存されるコンテンツに適しているのに対し、FHIRは血圧の記録のように成長し、クエリされるデータに適しているということです。CDAの受信者は表示できますが、インポートするには調整が必要です。FHIRの受信者は、自身のレコードと同じ形式に整形されたリソースを受け取ります。

退院サマリーは、自然にドキュメントとなります。一度作成され、医師によって署名され、数年後に読まれたときと全く同じように再現される必要があります。血圧の記録は、自然にリソースのセットとなります。毎日増え続け、グラフ化され、フィルタリングされ、誰も署名しません。CDAは前者には適していますが、後者には不向きです（新しい測定値ごとにドキュメント全体を再送信することになります）。FHIRは後者をネイティブに扱い、前者についてはドキュメントメカニズムを通じて扱います。

もう一つの実用的な違いは、受信者が何ができるかです。CDAの受信者は常にドキュメントを表示できます。そのエントリーをインポートするには、セクションごとに照合が必要です。FHIRの受信者は、自身の記録の形式になっているリソースを取得します。難しい問題は、ID（これは同じ患者か？）と来歴（誰がいつこれを主張したか？）に移ります。患者マッチングを参照してください。

FHIRドキュメント：合流点

FHIRドキュメントは、type: "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"}]}}}
  ]
}

International Patient Summaryはまさにこれです。CDAツインを持つFHIRドキュメントプロファイルで、まだCDAを必要とするシステム向けです。FHIR Bundleの説明も参照してください。

変換方法

CDAとFHIR間の変換は、制限付きで双方向に機能します。HL7 C-CDA on FHIR実装ガイドは、ドキュメントタイプ、セクション、エントリをコンポジションプロファイルとリソースにマッピングします。ナラティブのみのセクションは、データなしのテキストになります。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が依然として適切な選択肢となる場合

受信側がCDAを要求する場合（米国のケア移行、MyHealth@EUの患者サマリーと電子処方箋、いくつかの国のドキュメントレジストリ）、コンテンツが法的に署名および全体として保存されなければならない文書である場合、またはパートナーのインフラストラクチャがリソースではなくドキュメントをインデックス化するIHE XDSである場合、CDAは依然として適切な選択肢です。それ以外の場合は、FHIRから始めてください。

受信側がそれを要求する場合（米国のケアの移行、MyHealth@EUの患者要約と電子処方箋、現在、いくつかの国のドキュメントレジストリ）、コンテンツが法的に署名され、全体として保存されるべきドキュメントである場合、パートナーのインフラストラクチャがIHE XDSであり、リソースではなくドキュメントをインデックス化する場合。それ以外の場合は、FHIRから始めて、ドキュメントが必要な場合はFHIRドキュメントを作成してください。

関連ページ

• CDAとC-CDAの説明
• FHIR Bundleの説明
• International Patient Summary
• HL7 vs FHIR
• DocumentReference vs DiagnosticReport vs Binary
• 患者マッチング

ソース

• HL7 FHIR R4: Documents
• HL7 FHIR R4: Composition
• HL7 C-CDA on FHIR implementation guide
• HL7 FHIR: comparison with CDA (Appendix)
• HL7 International Patient Summary IG

よくある質問

FHIRドキュメントはJSON形式のCDAですか？

いいえ。原則（全体、署名済み、人間が読める、ヘッダー付き）は共有していますが、コンテンツは通常のFHIRリソースであるため、同じObservationがドキュメント内に存在し、APIによって提供される可能性があります。CDAでは、エントリーはそのドキュメント内にのみ存在します。

FHIRドキュメントに署名できますか？

はい。Bundle.signatureはバンドルに対するデジタル署名を保持し、IPSおよび各国のガイドでその方法が説明されています。実際には、多くのデプロイメントでは、署名ではなくトランスポートセキュリティと来歴に依存しています。

FHIRにはtemplateIdがありますか？

同等のものはmeta.profileです。これは、リソースが準拠を主張するStructureDefinitionの正規URLのリストです。バリデーターは、CDAスキーマントロンがテンプレートをチェックするのと同じ方法で準拠をチェックします。

新しい国家プログラムはどちらを選ぶべきですか？

最近のプログラム（EHDS交換フォーマット、米国患者アクセスルール、IPS）はFHIRを選択しており、要約や手紙にはFHIRドキュメントを使用し、レガシーパートナーのためにのみCDAパスを維持しています。

Anpheros Platform

サンドボックスで無料で試す

5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。

無料のサンドボックスを作成開発者ガイドを読む →

無料・合成患者30人・カード不要

作成者

Anpherosチーム

Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。

Anpherosについて →