Стандарты

CDA и C-CDA: стандарт HL7 для клинических документов между HL7 v2 и FHIR

HL7 CDA — это стандарт XML для клинических документов, который может читать человек и обрабатывать компьютер. Что содержит документ CDA (заголовок, разделы, повествование, кодированные записи), три уровня, что добавляет US Consolidated CDA, где CDA все еще требуется в 2026 году и как он связан с FHIR.

автор Опубликовано 6 мин чтения

Краткий ответ: Clinical Document Architecture (CDA) — это стандарт HL7 для клинических документов: выписных эпикризов, направлений, консультативных заключений, резюме пациента. Документ CDA представляет собой один XML-файл с заголовком (кто, когда, о ком) и телом, состоящим из разделов, каждый из которых содержит читаемую человеком нарративную часть и, опционально, машиночитаемые кодированные записи. C-CDA (Consolidated CDA) — это руководство по реализации в США, которое фиксирует шаблоны для наиболее распространенных типов документов; CCD (Continuity of Care Document) является его наиболее известным представителем. CDA Release 2 датируется 2005 годом и до сих пор требуется в нескольких национальных и трансграничных программах.

Как выглядит документ

Документ CDA — это XML-файл с корневым элементом ClinicalDocument, содержащим заголовок (тип документа в виде кода LOINC, OID шаблонов, идентификатор, время действия, код конфиденциальности, пациента, автора и хранителя) и тело разделов, каждый из которых имеет код 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>

Три момента, на которые стоит обратить внимание. Тип документа и каждый раздел идентифицируются кодом LOINC (34133-9, 48765-2). Шаблоны идентифицируются OID (2.16.840.1…), а не URL. Элемент <text> является обязательным и представляет собой то, что видит клиницист; <entry> является необязательным и представляет собой то, что читает программное обеспечение.

Три уровня

CDA определяет три уровня структуры. Уровень 1 — это допустимый заголовок с неструктурированным телом, например, встроенным PDF-файлом. Уровень 2 добавляет структурированное тело с кодированными разделами и описанием, но без кодированных записей. Уровень 3 добавляет кодированные записи в соответствии с шаблонами, чтобы программное обеспечение могло импортировать информацию об аллергиях, лекарствах и проблемах. Большинство реальных документов находятся между уровнями 2 и 3.

  • Уровень 1: действительный заголовок плюс неструктурированное тело, например, встроенный PDF. Юридически это документ CDA; компьютеры могут его сохранить, но не прочитать.
  • Уровень 2: структурированное тело с кодированными разделами и нарративной частью, без кодированных записей. Программное обеспечение знает, что есть раздел аллергий; оно не может перечислить сами аллергии.
  • Уровень 3: разделы с кодированными записями в соответствии с шаблонами. Программное обеспечение может импортировать аллергии, лекарства и проблемы в принимающую запись.

Большинство реальных документов CDA находятся между уровнями 2 и 3: некоторые разделы кодированы, другие — только нарративные.

Шесть принципов, которые до сих пор формируют его

Шесть принципов, лежащих в основе CDA: сохраняемость (документ остается неизменным годами), ответственность (хранитель несет за него ответственность), возможность аутентификации (он может быть подписан), контекст (заголовок применяется ко всему документу), целостность (раздел теряет смысл вне своего документа) и читаемость человеком (описание отображается без специального программного обеспечения). Документы FHIR используют те же шесть принципов.

CDA был разработан на основе принципов долговечности (документ остается неизменным годами), ответственности (хранитель несет за него ответственность), возможности аутентификации (его можно подписать), контекста (заголовок относится ко всему документу), целостности (раздел вне своего документа теряет смысл) и читаемости человеком (нарративная часть должна отображаться без специального программного обеспечения). Документы FHIR (Bundle типа document с Composition) следуют тем же принципам; базовая модель данных отличается, как объясняется в CDA vs FHIR.

C-CDA: консолидация в США

C-CDA (Consolidated CDA) — это руководство по реализации в США, которое с 2011 года объединило несколько пересекающихся руководств CDA в одно, с примерно дюжиной шаблонов документов, таких как Continuity of Care Document, Discharge Summary и Referral Note, а также общей библиотекой шаблонов разделов и записей. C-CDA R2.1 требуется для сертификации ONC для переходов между учреждениями и сводок для пациентов.

До 2011 года американские разработчики использовали несколько пересекающихся руководств CDA. Consolidated CDA объединил их в одно, с примерно дюжиной шаблонов документов (Continuity of Care Document, Discharge Summary, Progress Note, Referral Note, Care Plan, Operative Note, Diagnostic Imaging Report и другие) и общей библиотекой шаблонов разделов и записей. C-CDA R2.1 требуется для сертификации американских EHR (ONC) для обмена данными при переходе пациентов и резюме пациентов, и остается таковым наряду с FHIR US Core для API.

Где CDA используется в 2026 году

В 2026 году CDA используется в обмене данными между поставщиками медицинских услуг в США в виде C-CDA через Direct messaging и информационные медицинские биржи, в европейском трансграничном обмене данными MyHealth@EU Patient Summary и ePrescription, в национальных программах, таких как немецкие eArztbrief и ePA, австрийская ELGA, итальянская FSE, Нидерланды и Швейцария, а также повсеместно в качестве заголовка, оборачивающего отсканированные документы или PDF-файлы.

  • Соединенные Штаты: C-CDA для обмена документами между поставщиками медицинских услуг, в Direct messaging и системах обмена медицинской информацией.
  • Европа, трансграничный обмен: MyHealth@EU обменивается резюме пациента и электронными рецептами в виде документов CDA (шаблоны eHDSI), при этом форматы на основе FHIR появятся в рамках EHDS. См. Электронные рецепты в пределах ЕС.
  • Национальные программы: Немецкое электронное письмо врача (eArztbrief) и части ePA, австрийская ELGA, итальянская FSE, Нидерланды и Швейцария используют CDA для документов, часто через реестры IHE XDS.
  • Везде: отсканированные документы и PDF-файлы, обернутые в заголовок CDA, чтобы реестр документов мог их индексировать.

Что фактически получает получатель

Получатель документа CDA всегда получает читаемое описание, но кодированные данные он может импортировать только в том случае, если отправитель последовательно использовал шаблоны Уровня 3. Принимающие системы обычно отображают описание и предлагают сопоставить проблемы, лекарства и аллергии из записей по одной, поскольку два документа Уровня 3 от разных поставщиков редко кодируют один и тот же факт идентично.

Документ CDA надежен для чтения и неоднозначен для импорта. Нарративная часть всегда присутствует; кодированные записи зависят от уровня отправителя и соблюдения шаблонов. Принимающие системы обычно отображают нарративную часть клиницисту и предлагают "согласовать" проблемы, лекарства и аллергии из записей с локальной записью, по одной. Этот шаг согласования существует потому, что два документа Уровня 3 от разных поставщиков редко кодируют один и тот же факт одинаково.

В Anpheros документ CDA из больницы хранится как есть, как DocumentReference с прикрепленным XML, а его кодированное содержимое, где оно присутствует, отображается в ресурсы FHIR (Condition, AllergyIntolerance, MedicationStatement) с указанием происхождения, ведущего обратно к документу. См. DocumentReference vs DiagnosticReport vs Binary.

Связанные страницы

Источники

Частые вопросы

Является ли CDA тем же самым, что и HL7 v3?

CDA построен на основе HL7 v3 Reference Information Model и использует типы данных v3, поэтому его XML выглядит именно так. Остальная часть обмена сообщениями HL7 v3 получила малое распространение; CDA — это та часть v3, которая оказалась успешной.

Что такое CCD?

Continuity of Care Document — это тип документа C-CDA для резюме пациента: проблемы, лекарства, аллергии, иммунизации, результаты, процедуры, жизненно важные показатели, план лечения. Это американский эквивалент Международного резюме пациента.

Заменяется ли CDA на FHIR?

Для новых API и приложений — да; для обмена документами между учреждениями — медленно. Нормативные акты в США и Европе по-прежнему требуют CDA для определенных документов, и документы FHIR вводятся параллельно, а не вместо них.

Может ли документ CDA быть преобразован в FHIR?

Да, с ограничениями. Руководство по реализации HL7 C-CDA на FHIR отображает типы документов и разделы; кодированные записи отображаются в ресурсы FHIR, где шаблоны совпадают. Разделы, содержащие только нарративную часть, становятся разделами Composition с текстом и без структурированных данных.

Anpheros Platform

Попробуйте бесплатно в песочнице

Первый запрос FHIR за 5 минут. API HL7 FHIR R4 с встроенным согласием пациента: попробуйте в песочнице, затем подключите свое приложение или систему клиники.

Бесплатно · 30 синтетических пациентов · без карты

Это руководство носит информационный характер и не заменяет консультацию врача. Решения о своём здоровье принимайте вместе с врачом. В экстренной ситуации звоните по местному номеру экстренной помощи (112 в Европе).
Автор
Команда Anpheros

Anpheros создает медицинскую карту, которую пациент контролирует и может делиться с любой клиникой, на платформе HL7 FHIR R4, базирующейся в ЕС. Эти руководства помогут вам понять и организовать свое здоровье; они не заменяют вашего врача.

О Anpheros →