Коротка відповідь: 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 / C-CDA | FHIR | |
|---|---|---|
| Одиниця обміну | Цілий документ | Ресурс або Bundle ресурсів |
| Формат | XML, типи даних HL7 v3 | JSON або XML, типи даних FHIR |
| Ідентифікація | OID для шаблонів та систем кодування | URL (канонічні) для профілів та систем кодування |
| Частина, зрозуміла людині | Обов'язковий <text> у кожному розділі |
Необов'язковий наратив text.div для кожного ресурсу; обов'язковий у документах |
| Транспорт | Не визначено; переноситься через XDS, Direct, MLLP, електронну пошту | REST через HTTPS, визначений стандартом; також повідомлення та документи |
| Запити | Неможливо всередині документа; реєстри індексують заголовок | Вбудовано: 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 – це 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: Міжнародний резюме пацієнта IG
Поширені запитання
Чи є документ FHIR просто CDA в JSON?
Ні. Він поділяє принципи (цілісний, підписаний, зрозумілий людині, із заголовком), але його контент – це звичайні ресурси FHIR, тому одне й те саме Observation може існувати в документі та обслуговуватися API. У CDA запис існує лише всередині свого документа.
Чи можу я підписати документ FHIR?
Так. Bundle.signature містить цифровий підпис над Bundle, а IPS та національні посібники описують, як це зробити. На практиці багато розгортань покладаються на безпеку транспорту та походження, а не на підписи.
Чи є в FHIR templateId?
Еквівалентом є meta.profile, список канонічних URL StructureDefinitions, яким ресурс претендує на відповідність. Валідатори перевіряють відповідність так само, як schematrons CDA перевіряють шаблони.
Що має обрати нова національна програма?
Нещодавні програми (формат обміну EHDS, правила доступу пацієнтів США, IPS) обирають FHIR, з документами FHIR для резюме та листів, і зберігають шлях CDA лише для застарілих партнерів.
Спробуйте безкоштовно в пісочниці
Перший запит FHIR за 5 хвилин. API стандарту HL7 FHIR R4 з вбудованою згодою пацієнта: спробуйте в пісочниці, а потім підключіть власну програму чи клінічну систему.
Безкоштовно · 30 синтетичних пацієнтів · без картки
Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.
Про Anpheros →