CDA против FHIR: документы или ресурсы, когда что использовать и как конвертировать

Краткий ответ: CDA предоставляет вам один документ: подписанный XML-файл об одном пациенте в один момент времени, содержащий текст для чтения человеком и записи для чтения компьютером, который должен оставаться целым и неизменным. FHIR предоставляет вам ресурсы: пациента, сорок наблюдений, три состояния, каждое со своим URL-адресом, которые извлекаются, ищутся и обновляются независимо через REST API. FHIR также может упаковывать ресурсы в документ (Bundle типа document во главе с Composition), который является прямым эквивалентом CDA. Выбирайте CDA, когда этого требует регулирование или партнер; выбирайте FHIR для API, приложений и всего, что должно запрашиваться, а не читаться.

Две формы

CDA и FHIR имеют две разные формы. CDA обменивается целыми XML-документами, построенными на типах данных HL7 v3, идентифицируемых OID, с обязательным повествованием, без запросов, без обновлений и с подписанием всего документа. FHIR обменивается отдельными ресурсами JSON или XML или пакетами (Bundles), идентифицируемыми каноническими URL-адресами, со встроенными REST-запросами, версионированными обновлениями и профилями, опубликованными в руководствах по внедрению.

Что означает разница на практике

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

Выписной эпикриз — это, естественно, документ: он пишется один раз, подписывается одним врачом и должен быть воспроизводим спустя годы точно так же, как он был прочитан. Серия измерений артериального давления — это, естественно, набор ресурсов: она растет каждый день, строится по графику и фильтруется, и никто ее не подписывает. CDA хорошо справляется с первым и плохо со вторым (вы бы отправляли весь документ заново для каждого нового измерения). FHIR обрабатывает второе нативно, а первое — через свой механизм документов.

Другое практическое различие — что может сделать получатель. Получатель CDA всегда может отобразить документ; импорт его записей требует согласования, раздел за разделом. Получатель FHIR получает ресурсы, которые уже имеют форму его собственной записи; сложные вопросы перемещаются к идентификации (это тот же пациент?) и происхождению (кто это утвердил и когда?). См. Сопоставление пациентов.

Документы FHIR: точка пересечения

Документ FHIR — это Bundle с type: "document", первая запись которого — 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. В любом направлении оригинал следует сохранять как DocumentReference с Provenance.

• CDA → FHIR: руководство по реализации HL7 C-CDA on FHIR сопоставляет типы документов и разделы США с профилями Composition; записи сопоставляются с ресурсами (Problem Concern Act → Condition, Medication Activity → MedicationStatement, Result Observation → Observation). Сопоставление детерминировано для хорошо шаблонизированного контента Уровня 3 и с потерями для разделов, состоящих только из нарратива, которые становятся текстом без данных.
• FHIR → CDA: возможно для документов, ресурсы которых соответствуют шаблонам C-CDA. Произвольные ресурсы FHIR, которые никогда не предназначались в качестве документа (поток наблюдений с носимых устройств), не преобразуются в осмысленный CDA.
• Сохраняйте оригинал. В каком бы направлении вы ни преобразовывали, храните источник в том виде, в котором он был получен, как DocumentReference, и позвольте Provenance указывать от преобразованных ресурсов к нему. Преобразование — это представление, а не замена.

Когда CDA по-прежнему является правильным ответом

CDA по-прежнему является правильным ответом, когда принимающая сторона этого требует (переходы пациентов в США, сводка для пациента и электронные рецепты MyHealth@EU, несколько национальных реестров документов), когда контент юридически является документом, который должен быть подписан и сохранен целиком, или когда инфраструктура партнера — IHE XDS, которая индексирует документы, а не ресурсы. В противном случае начинайте с FHIR.

Когда этого требует принимающая сторона (переходные процессы в США, резюме пациента и электронные рецепты MyHealth@EU сегодня, различные национальные реестры документов); когда контент юридически является документом, который должен быть подписан и сохранен целиком; когда инфраструктура партнера — IHE XDS, которая индексирует документы, а не ресурсы. Во всех остальных случаях начинайте с FHIR и создавайте документ FHIR, когда требуется документ.

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

• CDA и C-CDA объяснены
• FHIR Bundle объяснен
• Международный резюме пациента
• HL7 против FHIR
• DocumentReference против DiagnosticReport против Binary
• Сопоставление пациентов

Источники

• HL7 FHIR R4: Документы
• HL7 FHIR R4: Composition
• Руководство по реализации HL7 C-CDA on FHIR
• HL7 FHIR: сравнение с CDA (Приложение)
• Руководство по международному резюме пациента HL7 FHIR

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

Является ли документ FHIR просто CDA в JSON?

Нет. Он разделяет принципы (целостность, подпись, читаемость человеком, с заголовком), но его контент состоит из обычных ресурсов FHIR, поэтому одно и то же Observation может существовать в документе и обслуживаться API. В CDA запись существует только внутри своего документа.

Могу ли я подписать документ FHIR?

Да. Bundle.signature содержит цифровую подпись для всего пакета, и руководства IPS и национальные руководства описывают, как это сделать. На практике многие развертывания полагаются на безопасность транспорта и происхождение, а не на подписи.

Есть ли у FHIR templateId?

Эквивалентом является meta.profile, список канонических URL-адресов StructureDefinitions, которым ресурс заявляет о соответствии. Валидаторы проверяют соответствие так же, как схемы CDA проверяют шаблоны.

Что следует выбрать новой национальной программе?

Недавние программы (форма обмена EHDS, правила доступа пациентов в США, IPS) выбирают FHIR, используя документы FHIR для резюме и писем, и сохраняют путь CDA только для устаревших партнеров.

Anpheros Platform

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

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

Создать бесплатную песочницуЧитать руководства для разработчиков →

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

Автор

Команда Anpheros

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

О Anpheros →