CDA i C-CDA wyjaśnione: dokumenty kliniczne HL7

Krótka odpowiedź: Clinical Document Architecture (CDA) to standard HL7 dla dokumentów medycznych: wypisów ze szpitala, listów skierowań, notatek z konsultacji, podsumowań pacjenta. Dokument CDA to jeden plik XML z nagłówkiem (kto, kiedy, o kim) i treścią składającą się z sekcji, z których każda zawiera czytelną dla człowieka narrację i, opcjonalnie, kodowane wpisy czytelne dla maszyn. C-CDA (Consolidated CDA) to amerykański przewodnik implementacyjny, który ustala szablony dla najczęściej używanych typów dokumentów; CCD (Continuity of Care Document) jest jego najbardziej znanym członkiem. CDA Release 2 pochodzi z 2005 roku i jest nadal wymagane w kilku krajowych i transgranicznych programach.

Jak wygląda dokument

Dokument CDA to plik XML z głównym elementem ClinicalDocument, który zawiera nagłówek (typ dokumentu jako kod LOINC, identyfikatory OID szablonów, identyfikator, czas obowiązywania, kod poufności, pacjenta, autora i powiernika) oraz treść składającą się z sekcji. Każda sekcja ma kod LOINC, obowiązkowy element tekstowy czytelny dla człowieka oraz opcjonalne wpisy zakodowane, które oprogramowanie może odczytać.

<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>

Trzy rzeczy, na które warto zwrócić uwagę. Typ dokumentu i każda sekcja są identyfikowane przez kod LOINC (34133-9, 48765-2). Szablony są identyfikowane przez OID (2.16.840.1…), a nie adresy URL. Element <text> jest obowiązkowy i jest tym, co widzi lekarz; <entry> jest opcjonalny i jest tym, co odczytuje oprogramowanie.

Trzy poziomy

CDA definiuje trzy poziomy struktury. Poziom 1 to prawidłowy nagłówek z nieustrukturyzowaną treścią, na przykład osadzonym plikiem PDF. Poziom 2 dodaje ustrukturyzowaną treść z zakodowanymi sekcjami i opisem narracyjnym, ale bez zakodowanych wpisów. Poziom 3 dodaje zakodowane wpisy zgodne z szablonami, dzięki czemu oprogramowanie może importować informacje o alergiach, lekach i problemach zdrowotnych. Większość rzeczywistych dokumentów znajduje się między poziomem 2 a 3.

Poziom 1: prawidłowy nagłówek plus nieustrukturyzowana treść, na przykład osadzony plik PDF. Prawnie jest to dokument CDA; komputery mogą go przechowywać, ale nie odczytać.
Poziom 2: ustrukturyzowana treść z kodowanymi sekcjami i narracją, bez kodowanych wpisów. Oprogramowanie wie, że istnieje sekcja alergii; nie potrafi wymienić alergii.
Poziom 3: sekcje z kodowanymi wpisami zgodnymi z szablonami. Oprogramowanie może zaimportować alergie, leki i problemy do odbierającego rekordu.

Większość rzeczywistych dokumentów CDA znajduje się między poziomem 2 a 3: niektóre sekcje są kodowane, inne tylko narracyjne.

Sześć zasad, które nadal je kształtują

Sześć zasad leżących u podstaw CDA to: trwałość (dokument pozostaje niezmieniony przez lata), nadzór (powiernik jest za niego odpowiedzialny), możliwość uwierzytelnienia (może być podpisany), kontekst (nagłówek dotyczy całego dokumentu), kompletność (sekcja traci znaczenie poza swoim dokumentem) i czytelność dla człowieka (opis narracyjny renderuje się bez specjalnego oprogramowania). Dokumenty FHIR przyjmują te same sześć zasad.

CDA zostało zaprojektowane z myślą o trwałości (dokument pozostaje niezmieniony przez lata), nadzorze (powiernik jest za niego odpowiedzialny), potencjale uwierzytelniania (może być podpisany), kontekście (nagłówek dotyczy całego dokumentu), całości (sekcja poza swoim dokumentem traci znaczenie) i czytelności dla człowieka (narracja musi być renderowana bez specjalnego oprogramowania). Dokumenty FHIR (Bundle typu document z Composition) przyjmują te same zasady; model danych leżący u ich podstaw jest inny, co wyjaśnia CDA vs FHIR.

C-CDA: amerykańska konsolidacja

C-CDA (Consolidated CDA) to przewodnik implementacyjny w USA, który od 2011 roku połączył kilka nakładających się przewodników CDA w jeden. Zawiera on kilkanaście szablonów dokumentów, takich jak Continuity of Care Document, Discharge Summary i Referral Note, oraz wspólną bibliotekę szablonów sekcji i wpisów. C-CDA R2.1 jest wymagany przez certyfikację ONC do przekazywania opieki i podsumowań pacjenta.

Przed 2011 rokiem amerykańscy implementatorzy korzystali z kilku nakładających się przewodników CDA. Consolidated CDA połączyło je w jeden, zawierający około tuzina szablonów dokumentów (Continuity of Care Document, Discharge Summary, Progress Note, Referral Note, Care Plan, Operative Note, Diagnostic Imaging Report i inne) oraz wspólną bibliotekę szablonów sekcji i wpisów. C-CDA R2.1 jest wymagane przez amerykańską certyfikację EHR (ONC) do wymiany opieki i podsumowań pacjentów, i pozostaje tak obok FHIR US Core dla API.

Gdzie CDA znajduje się w 2026 roku

W 2026 roku CDA funkcjonuje w wymianie między dostawcami usług medycznych w USA jako C-CDA za pośrednictwem wiadomości Direct i wymiany informacji o stanie zdrowia, w europejskim transgranicznym podsumowaniu pacjenta MyHealth@EU i e-receptach, w programach krajowych, takich jak niemiecki eArztbrief i ePA, austriacki ELGA, włoski FSE, w Holandii i Szwajcarii, a wszędzie jako nagłówek otaczający zeskanowane dokumenty lub pliki PDF.

Stany Zjednoczone: C-CDA do wymiany dokumentów między dostawcami usług, w wiadomościach Direct i systemach wymiany informacji o stanie zdrowia.
Europa, transgranicznie: MyHealth@EU wymienia Podsumowanie Pacjenta i eReceptę jako dokumenty CDA (szablony eHDSI), z formatami opartymi na FHIR pojawiającymi się w ramach EHDS. Zobacz eRecepta w całej Europie.
Programy krajowe: Niemiecki list elektroniczny (eArztbrief) i części ePA, austriackie dokumenty ELGA, włoskie FSE, Holandia i Szwajcaria używają CDA do dokumentów, często za pośrednictwem rejestrów IHE XDS.
Wszędzie: zeskanowane dokumenty i pliki PDF opakowane w nagłówek CDA, dzięki czemu rejestr dokumentów może je indeksować.

Co faktycznie otrzymuje odbiorca

Odbiorca dokumentu CDA zawsze otrzymuje czytelny opis narracyjny, ale zakodowane dane może zaimportować tylko wtedy, gdy nadawca konsekwentnie stosował szablony poziomu 3. Systemy odbierające zazwyczaj wyświetlają opis narracyjny i oferują uzgodnienie problemów zdrowotnych, leków i alergii z poszczególnych wpisów, ponieważ dwa dokumenty poziomu 3 od różnych dostawców rzadko kodują ten sam fakt identycznie.

Dokument CDA jest niezawodny do odczytu i nierówny do importu. Narracja jest zawsze obecna; kodowane wpisy zależą od poziomu i dyscypliny szablonu nadawcy. Systemy odbierające zazwyczaj wyświetlają narrację lekarzowi i oferują "pogodzenie" problemów, leków i alergii z wpisów do lokalnego rekordu, jeden po drugim. Ten krok pogłębiania istnieje, ponieważ dwa dokumenty Poziomu 3 od różnych dostawców rzadko kodują ten sam fakt w ten sam sposób.

W Anpheros dokument CDA ze szpitala jest przechowywany w oryginalnej postaci, jako DocumentReference z załączonym XML-em, a jego kodowana zawartość, tam gdzie jest obecna, jest mapowana na zasoby FHIR (Condition, AllergyIntolerance, MedicationStatement) z proweniencją wskazującą z powrotem na dokument. Zobacz DocumentReference vs DiagnosticReport vs Binary.

Powiązane strony

Źródła

Najczęstsze pytania

Czy CDA to to samo co HL7 v3?

CDA jest zbudowane na modelu referencyjnym HL7 v3 i wykorzystuje typy danych v3, dlatego jego XML wygląda tak, jak wygląda. Reszta wiadomości HL7 v3 miała niewielkie zastosowanie; CDA jest częścią v3, która odniosła sukces.

Co to jest CCD?

Continuity of Care Document to typ dokumentu C-CDA dla podsumowania pacjenta: problemy, leki, alergie, szczepienia, wyniki, procedury, parametry życiowe, plan opieki. Jest to amerykański odpowiednik International Patient Summary.

Czy CDA jest zastępowane przez FHIR?

Dla nowych API i aplikacji tak; dla wymiany dokumentów między instytucjami powoli. Przepisy w USA i Europie nadal wymagają CDA dla określonych dokumentów, a dokumenty FHIR są wprowadzane równolegle, a nie zamiast.

Czy dokument CDA można przekonwertować do FHIR?

Tak, z ograniczeniami. Przewodnik implementacyjny HL7 C-CDA on FHIR mapuje typy dokumentów i sekcje; kodowane wpisy mapują się na zasoby FHIR, gdzie szablony pasują. Sekcje zawierające tylko narrację stają się sekcjami Composition z tekstem i bez danych strukturalnych.

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 sandbox Przeczytaj przewodniki dla programistów →

Za darmo · 30 syntetycznych pacjentów · bez karty

Ten poradnik ma charakter informacyjny i nie zastępuje konsultacji lekarskiej. Decyzje dotyczące zdrowia podejmuj z lekarzem. W nagłym wypadku zadzwoń pod lokalny numer alarmowy (112 w Europie).

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 →