簡単な回答: Clinical Document Architecture（CDA）は、HL7が定める診療記録の標準規格です。退院サマリー、紹介状、診療記録、患者サマリーなどが含まれます。CDA文書は、ヘッダー（誰が、いつ、誰について）と、人間が読めるナラティブと、オプションで機械が読めるコード化されたエントリを持つセクションのボディからなるXMLファイルです。C-CDA（Consolidated CDA）は、最も一般的な文書タイプのためのテンプレートを固定した米国の実装ガイドです。その中でも最もよく知られているのがCCD（Continuity of Care Document）です。CDA Release 2は2005年にリリースされ、現在でもいくつかの国や国際的なプログラムで義務付けられています。
文書の外観
CDA文書は、ヘッダー（LOINCコードによる文書の種類、templateIdのOID、ID、有効期間、機密性コード、患者、作成者、管理者）とセクションのボディを含むXMLファイルです。各セクションにはLOINCコード、必須の人間の可読テキスト要素、およびソフトウェアが読み取るためのオプションのコード化されたエントリが含まれています。
<ClinicalDocument xmlns="urn:hl7-org:v3">
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<templateId root="2.16.840.1.113883.10.20.22.1.2" extension="2015-08-01"/>
<id root="2.16.840.1.113883.19.5" extension="DOC-2026-0314"/>
<code code="34133-9" codeSystem="2.16.840.1.113883.6.1" displayName="Summarization of Episode Note"/>
<effectiveTime value="20260314101500+0100"/>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<recordTarget><patientRole>…</patientRole></recordTarget>
<author>…</author>
<custodian>…</custodian>
<component><structuredBody>
<component><section>
<templateId root="2.16.840.1.113883.10.20.22.2.6.1" extension="2015-08-01"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies</title>
<text><table><tr><td>Penicillin</td><td>Rash</td></tr></table></text>
<entry>…coded Allergy Concern Act…</entry>
</section></component>
</structuredBody></component>
</ClinicalDocument>
注目すべき点は3つあります。文書のタイプと各セクションは、LOINCコード（34133-9、48765-2）で識別されます。テンプレートはURLではなくOID（2.16.840.1…）で識別されます。<text>要素は必須であり、医師が見る部分です。<entry>はオプションであり、ソフトウェアが読み取る部分です。
3つのレベル
CDAは3つのレベルの構造を定義しています。レベル1は、埋め込みPDFのような構造化されていないボディを持つ有効なヘッダーです。レベル2は、コード化されたセクションとナラティブを持つ構造化されたボディを追加しますが、コード化されたエントリはありません。レベル3は、テンプレートに従ってコード化されたエントリを追加するため、ソフトウェアはアレルギー、薬剤、問題をインポートできます。ほとんどの実際の文書はレベル2と3の間に位置します。
- レベル1: 有効なヘッダーと構造化されていないボディ（例: 埋め込みPDF）。法的にはCDA文書ですが、コンピューターは保存できますが、内容を読むことはできません。
- レベル2: コード化されたセクションとナラティブを持つ構造化ボディで、コード化されたエントリはありません。ソフトウェアは「アレルギーセクションがある」ことは知っていますが、アレルギーをリストアップすることはできません。
- レベル3: テンプレートに従ってコード化されたエントリを持つセクション。ソフトウェアは、受信記録にアレルギー、薬剤、問題をインポートできます。
実際のCDAの多くはレベル2と3の中間に位置します。一部のセクションはコード化され、その他はナラティブのみです。
今なお影響を与えている6つの原則
CDAの背後にある6つの原則は、永続性（文書は何年も変更されずに存在します）、管理責任（管理者が責任を負います）、認証の可能性（署名できます）、コンテキスト（ヘッダーは文書全体に適用されます）、全体性（セクションは文書外では意味を失います）、および人間の可読性（ナラティブは特別なソフトウェアなしでレンダリングされます）です。FHIR文書は、これら6つの原則を採用しています。
CDAは、永続性（文書は何年も変更されずに存続する）、管理責任（管理者が責任を持つ）、認証の可能性（署名できる）、文脈（ヘッダーは文書全体に適用される）、完全性（セクションが文書から切り離されると意味を失う）、人間による可読性（ナラティブは特別なソフトウェアなしでレンダリングできる）を中心に設計されました。FHIR文書（documentタイプのBundleとComposition）もこれらの原則を採用しています。基盤となるデータモデルは異なります。詳細はCDA vs FHIRで説明しています。
C-CDA: 米国の統合
C-CDA（Consolidated CDA）は、2011年から複数の重複するCDAガイドを1つに統合した米国の実装ガイドです。Continuity of Care Document、Discharge Summary、Referral Noteなど約12の文書テンプレートと、セクションおよびエントリテンプレートの共有ライブラリがあります。C-CDA R2.1は、ケアの移行と患者の概要のONC認証に必要です。
2011年以前、米国の実装者はいくつかの重複するCDAガイドを使用していました。Consolidated CDAはそれらを1つに統合し、約12の文書テンプレート（Continuity of Care Document、Discharge Summary、Progress Note、Referral Note、Care Plan、Operative Note、Diagnostic Imaging Reportなど）と、セクションおよびエントリテンプレートの共有ライブラリを作成しました。C-CDA R2.1は、米国のEHR認証（ONC）でケアの移行と患者サマリーに必要とされており、API用のFHIR US Coreと並んで引き続き必要とされています。
2026年におけるCDAの利用状況
2026年、CDAは米国のプロバイダー間交換において、Directメッセージングと健康情報交換を介したC-CDAとして、ヨーロッパのクロスボーダーMyHealth@EU患者サマリーと電子処方箋、ドイツのeArztbriefとePA、オーストリアのELGA、イタリアのFSE、オランダとスイスなどの国内プログラム、そしてスキャンまたはPDF文書を囲むヘッダーとして、どこでも利用されています。
- 米国: 医療提供者間の文書交換、Directメッセージング、医療情報交換でC-CDAが利用されています。
- ヨーロッパ、国際間: MyHealth@EUは、患者サマリーと電子処方箋をCDA文書（eHDSIテンプレート）として交換しています。EHDSの下でFHIRベースの形式が登場する予定です。EU域内の電子処方箋を参照してください。
- 国内プログラム: ドイツの電子医師レター（eArztbrief）とePAの一部、オーストリアのELGA文書、イタリアのFSE、オランダ、スイスでは、多くの場合IHE XDSレジストリを通じて、文書にCDAが使用されています。
- あらゆる場所: スキャンされたPDF文書がCDAヘッダーにラップされ、文書レジストリがインデックスを作成できるようにしています。
受信者が実際に受け取るもの
CDA文書の受信者は常に読みやすいナラティブを受け取りますが、コード化されたデータは、送信者がレベル3テンプレートを一貫して使用した場合にのみインポートできます。受信システムは通常、ナラティブを表示し、2つの異なるベンダーからのレベル3文書は同じ事実を正確にコード化することがまれであるため、エントリから問題、薬剤、アレルギーを1つずつ照合するオプションを提供します。
CDA文書は、読み取りには信頼性がありますが、インポートにはばらつきがあります。ナラティブは常に存在しますが、コード化されたエントリは送信者のレベルとテンプレートの規律に依存します。受信システムは通常、医師にナラティブを表示し、エントリからローカル記録への問題、薬剤、アレルギーを1つずつ「調整」するオプションを提供します。この調整ステップが存在するのは、異なるベンダーからの2つのレベル3文書が同じ事実を同じようにコード化することはめったにないためです。
Anpherosでは、病院からのCDA文書は、XMLが添付されたDocumentReferenceとしてそのまま保存され、コード化されたコンテンツ（存在する場合）はFHIRリソース（Condition、AllergyIntolerance、MedicationStatement）にマッピングされ、その出所は文書に戻ります。DocumentReference vs DiagnosticReport vs Binaryを参照してください。
関連ページ
- CDA vs FHIR
- HL7 vs FHIR: v2、CDA、FHIR
- FHIR Bundleの説明
- DocumentReference vs DiagnosticReport vs Binary
- 国際患者サマリー
- 医療相互運用性標準: マップ
- TEFCAとQHINの説明
情報源
- HL7 CDA Release 2 製品概要
- HL7 C-CDA R2.1 製品概要
- HL7 C-CDA オンラインナビゲーション（テンプレート）
- ONC認証: C-CDA要件
- MyHealth@EU（欧州委員会）
よくある質問
CDAはHL7 v3と同じですか？
CDAはHL7 v3参照情報モデルに基づいて構築されており、v3データ型を使用しているため、XMLの外観がそのようになっています。HL7 v3メッセージングの他の部分はほとんど採用されませんでした。CDAはv3の中で成功した部分です。
CCDとは何ですか？
Continuity of Care Documentは、患者サマリー（問題、薬剤、アレルギー、予防接種、結果、処置、バイタルサイン、ケアプラン）のためのC-CDA文書タイプです。これは国際患者サマリーの米国の同等物です。
CDAはFHIRに置き換えられますか？
新しいAPIやアプリについては、はい。機関間の文書交換については、ゆっくりとです。米国とヨーロッパの規制では、特定の文書に対して依然としてCDAが必要とされており、FHIR文書は置き換えではなく並行して導入されています。
CDA文書をFHIRに変換できますか？
はい、ただし制限があります。HL7 C-CDA on FHIR実装ガイドは、文書タイプとセクションをマッピングします。コード化されたエントリは、テンプレートが一致する場所でFHIRリソースにマッピングされます。ナラティブのみのセクションは、テキストを持つCompositionセクションになり、構造化データはありません。
サンドボックスで無料で試す
5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。
無料・合成患者30人・カード不要
Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。
Anpherosについて →