CDA a FHIR: dokumenty kontra zasoby, kiedy co stosować i jak konwertować

Krótka odpowiedź: CDA daje Ci jeden dokument: podpisany plik XML dotyczący jednego pacjenta w jednym momencie, zawierający tekst do odczytu przez człowieka i wpisy do odczytu przez komputer, który musi pozostać nienaruszony. FHIR daje Ci zasoby: Pacjenta, czterdzieści Obserwacji, trzy Stany chorobowe, każdy z własnym adresem URL, pobierany, przeszukiwany i aktualizowany niezależnie za pomocą API REST. FHIR może również pakować zasoby w dokument (Bundle typu document prowadzony przez Composition), który jest bezpośrednim odpowiednikiem CDA. Wybieraj CDA tam, gdzie wymaga tego regulacja lub partner; wybieraj FHIR dla API, aplikacji i wszystkiego, co musi być odpytywane, a nie tylko czytane.

Dwa kształty

CDA i FHIR mają dwa różne kształty. CDA wymienia całe dokumenty XML zbudowane na typach danych HL7 v3, identyfikowane przez OID, z obowiązkową narracją, bez możliwości zapytań, bez aktualizacji i z podpisem całego dokumentu. FHIR wymienia pojedyncze zasoby JSON lub XML lub pakiety (Bundles), identyfikowane przez kanoniczne adresy URL, z wbudowanymi zapytaniami REST, wersjonowanymi aktualizacjami i profilami opublikowanymi w przewodnikach implementacji.

Co oznacza różnica w praktyce

W praktyce różnica między CDA a FHIR polega na tym, że CDA nadaje się do treści pisanych raz i zachowywanych w całości, takich jak podpisane podsumowanie wypisu, podczas gdy FHIR nadaje się do danych, które rosną i są przeszukiwane, takich jak seria pomiarów ciśnienia krwi. Odbiorca CDA może wyświetlić, ale musi pogodzić, aby zaimportować; odbiorca FHIR otrzymuje zasoby już ukształtowane jak jego własny rekord.

Podsumowanie wypisu jest z natury dokumentem: jest pisane raz, podpisywane przez jednego lekarza i musi być odtwarzalne lata później dokładnie tak, jak zostało przeczytane. Seria pomiarów ciśnienia krwi jest z natury zbiorem zasobów: rośnie każdego dnia, jest wykresowana i filtrowana, i nikt jej nie podpisuje. CDA dobrze radzi sobie z pierwszym, a źle z drugim (wysyłałbyś cały dokument ponownie dla każdego nowego odczytu). FHIR natywnie obsługuje drugie, a pierwsze poprzez swój mechanizm dokumentów.

Inna praktyczna różnica to co odbiorca może zrobić. Odbiorca CDA zawsze może wyświetlić dokument; importowanie jego wpisów wymaga uzgodnienia, sekcja po sekcji. Odbiorca FHIR otrzymuje zasoby, które są już w kształcie jego własnego rekordu; trudne pytania przenoszą się na tożsamość (czy to ten sam pacjent?) i pochodzenie (kto to stwierdził i kiedy?). Zobacz Potwierdzanie tożsamości pacjenta.

Dokumenty FHIR: punkt styku

Dokument FHIR to Bundle z type: "document", którego pierwszym wpisem jest Composition. Composition odgrywa rolę nagłówka i listy sekcji CDA: typ (LOINC), data, autor, temat, powiernik, status i section[] z tytułem, kodem, tekstem narracyjnym i odniesieniami do zasobów, które zawierają dane.

{
  "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"}]}}}
  ]
}

Międzynarodowy Podsumowanie Pacjenta jest dokładnie tym: profilem dokumentu FHIR, z bliźniaczym odpowiednikiem CDA dla systemów, które go nadal potrzebują. Zobacz także FHIR Bundle wyjaśnione.

Konwersja między nimi

Konwersja między CDA i FHIR działa w obu kierunkach z ograniczeniami. Przewodnik implementacji HL7 C-CDA on FHIR mapuje typy dokumentów, sekcje i wpisy na profile Kompozycji (Composition) i zasoby; sekcje zawierające tylko narrację stają się tekstem bez danych. Konwersja z FHIR do CDA działa dla zasobów, które pasują do szablonów C-CDA. W obu kierunkach oryginał powinien być przechowywany jako DocumentReference z Provenance.

• CDA → FHIR: przewodnik implementacji HL7 C-CDA on FHIR mapuje amerykańskie typy dokumentów i sekcje na profile Composition; wpisy mapują się na zasoby (Problem Concern Act → Condition, Medication Activity → MedicationStatement, Result Observation → Observation). Mapowanie jest deterministyczne dla dobrze szablonowych treści poziomu 3 i stratne dla sekcji zawierających tylko narrację, które stają się tekstem bez danych.
• FHIR → CDA: możliwe dla dokumentów, których zasoby pasują do szablonów C-CDA. Swobodne zasoby FHIR, które nigdy nie były przeznaczone jako dokument (strumień obserwacji z urządzeń noszonych), nie stają się sensownym CDA.
• Zachowaj oryginał. W którąkolwiek stronę konwertujesz, przechowuj źródło tak, jak zostało otrzymane, jako DocumentReference, i pozwól Provenance wskazywać z przekonwertowanych zasobów na nie. Konwersja jest widokiem, a nie zamiennikiem.

Kiedy CDA jest nadal właściwą odpowiedzią

CDA jest nadal właściwą odpowiedzią, gdy strona odbierająca tego wymaga (przejścia opieki w USA, podsumowanie pacjenta i e-recepta MyHealth@EU, kilka krajowych rejestrów dokumentów), gdy treść jest prawnie dokumentem, który musi być podpisany i zachowany w całości, lub gdy infrastruktura partnera to IHE XDS, która indeksuje dokumenty zamiast zasobów. W przeciwnym razie zacznij od FHIR.

Gdy wymaga tego strona odbierająca (amerykańskie przejścia opieki, podsumowanie pacjenta i e-recepta MyHealth@EU dzisiaj, kilka krajowych rejestrów dokumentów); gdy treść jest prawnie dokumentem, który musi być podpisany i zachowany w całości; gdy infrastruktura partnera to IHE XDS, która indeksuje dokumenty, a nie zasoby. We wszystkich innych przypadkach zacznij od FHIR i wygeneruj dokument FHIR tam, gdzie potrzebny jest dokument.

Powiązane strony

• CDA i C-CDA wyjaśnione
• FHIR Bundle wyjaśnione
• Międzynarodowy Podsumowanie Pacjenta
• HL7 vs FHIR
• DocumentReference vs DiagnosticReport vs Binary
• Potwierdzanie tożsamości pacjenta

Źródła

• HL7 FHIR R4: Dokumenty
• HL7 FHIR R4: Composition
• Przewodnik implementacji HL7 C-CDA on FHIR
• HL7 FHIR: porównanie z CDA (Dodatek)
• HL7 FHIR: Międzynarodowy Podsumowanie Pacjenta IG

Najczęstsze pytania

Czy dokument FHIR to po prostu CDA w JSON?

Nie. Dzieli zasady (całość, podpisany, czytelny dla człowieka, z nagłówkiem), ale jego treść to zwykłe zasoby FHIR, więc ta sama Obserwacja może istnieć w dokumencie i być udostępniana przez API. W CDA wpis istnieje tylko wewnątrz swojego dokumentu.

Czy mogę podpisać dokument FHIR?

Tak. Bundle.signature zawiera podpis cyfrowy na całym bundle, a krajowe przewodniki i IPS opisują, jak to zrobić. W praktyce wiele wdrożeń opiera się na bezpieczeństwie transportu i pochodzeniu, a nie na podpisach.

Czy FHIR ma templateId?

Odpowiednikiem jest meta.profile, lista kanonicznych adresów URL StructureDefinitions, do których zasób deklaruje zgodność. Walidatory sprawdzają zgodność w taki sam sposób, w jaki schematrony CDA sprawdzają szablony.

Który powinien wybrać nowy program krajowy?

Nowe programy (format wymiany EHDS, zasady dostępu pacjentów w USA, IPS) wybierają FHIR, z dokumentami FHIR dla podsumowań i listów, i zachowują ścieżkę CDA tylko dla starszych partnerów.

Anpheros Platform

Wypróbuj za darmo w sandboksie

Pierwsze wywołanie FHIR w 5 minut. API HL7 FHIR R4 z wbudowaną zgodą pacjenta: wypróbuj w piaskownicy, a następnie połącz własną aplikację lub system kliniczny.

Utwórz darmowy sandboxPrzeczytaj przewodniki dla programistów →

Za darmo · 30 syntetycznych pacjentów · bez karty

Napisane przez

Zespół Anpheros

Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.

O Anpheros →