Standarde

CDA vs FHIR: documente vs resurse, când se potrivește fiecare și cum se convertește între ele

CDA: document XML semnat, integral. FHIR: resurse mici, adresabile, servite/actualizate de API. Cum documentele FHIR (Compoziție într-un Pachet) le unesc, când CDA e necesar și conversia.

de Publicat 6 min de citit

Pe scurt: CDA vă oferă un singur document: un fișier XML semnat despre un pacient la un moment dat, cu o narativă pe care o citește un om și intrări pe care un computer le poate citi, care trebuie să rămână întregi și neschimbate. FHIR vă oferă resurse: un Pacient, patruzeci de Observații, trei Condiții, fiecare cu propriul URL, preluate, căutate și actualizate independent printr-un API REST. FHIR poate, de asemenea, să împacheteze resurse într-un document (un Bundle de tip document condus de o Compoziție), care este echivalentul direct al CDA. Alegeți CDA acolo unde o reglementare sau un partener o cere; alegeți FHIR pentru API-uri, aplicații și orice altceva care trebuie interogat mai degrabă decât citit.

Cele două forme

CDA și FHIR au două forme diferite. CDA schimbă documente XML complete, construite pe tipuri de date HL7 v3, identificate prin OID-uri, cu text narativ obligatoriu, fără interogare, fără actualizări și cu semnătură a documentului întreg. FHIR schimbă resurse individuale JSON sau XML sau Pachete (Bundles), identificate prin URL-uri canonice, cu interogare REST încorporată, actualizări cu versiuni și profiluri publicate în ghiduri de implementare.

CDA / C-CDA FHIR
Unitate de schimb Un document întreg O resursă sau un Bundle de resurse
Format XML, tipuri de date HL7 v3 JSON sau XML, tipuri de date FHIR
Identificare OID-uri pentru șabloane și sisteme de coduri URL-uri (canonice) pentru profiluri și sisteme de coduri
Partea lizibilă de om <text> obligatoriu în fiecare secțiune Narativă text.div opțională per resursă; obligatorie în documente
Transport Nedefinit; transportat prin XDS, Direct, MLLP, email REST peste HTTPS definit de standard; de asemenea, mesagerie și documente
Interogare Nu este posibilă în interiorul unui document; registrii indexează antetul Integrat: GET /Observation?patient=…&code=…
Actualizare Niciodată; un document nou îl înlocuiește pe cel vechi Resursele sunt versionate și actualizate la fața locului
Semnare Document întreg, XML-DSig Bundle întreg posibil; resurse individuale rareori semnate
Profiluri Șabloane (templateId) per secțiune și intrare Profiluri StructureDefinition per resursă, publicate în ghiduri de implementare
Terminologie Coduri de secțiune LOINC, intrări SNOMED/ICD/RxNorm Aceleași sisteme de coduri, ca CodeableConcept

Ce înseamnă diferența în practică

În practică, diferența dintre CDA și FHIR este că CDA este potrivit pentru conținut scris o singură dată și păstrat integral, cum ar fi un rezumat de externare semnat, în timp ce FHIR este potrivit pentru date care cresc și sunt interogate, cum ar fi o serie de măsurători ale tensiunii arteriale. Un receptor CDA poate afișa, dar trebuie să reconcilieze pentru a importa; un receptor FHIR primește resurse deja structurate ca propriul său registru.

Un rezumat de externare este în mod natural un document: este scris o singură dată, semnat de un medic și trebuie să fie reproductibil ani mai târziu exact așa cum a fost citit. O serie de tensiuni arteriale este în mod natural un set de resurse: crește în fiecare zi, este graficată și filtrată, și nimeni nu o semnează. CDA gestionează bine primul caz și prost pe al doilea (ați retrimite întregul document pentru fiecare nouă citire). FHIR gestionează nativ al doilea caz și primul prin mecanismul său de documente.

Cealaltă diferență practică este ce poate face destinatarul. Un destinatar CDA poate afișa întotdeauna documentul; importarea intrărilor sale necesită reconciliere, secțiune cu secțiune. Un destinatar FHIR primește resurse care sunt deja în forma propriului său registru; întrebările dificile se mută la identitate (este același pacient?) și proveniență (cine a afirmat acest lucru și când?). Vezi Potrivirea pacienților.

Documente FHIR: punctul de întâlnire

Un document FHIR este un Bundle cu type: "document" a cărui primă intrare este o Compoziție. Compoziția joacă rolul antetului CDA și al listei de secțiuni: tip (LOINC), dată, autor, subiect, custode, stare și section[] cu un titlu, un cod, text narativ și referințe la resursele care conțin datele.

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

Rezumatul Internațional al Pacientului este exact acest lucru: un profil de document FHIR, cu o pereche CDA pentru sistemele care încă îl necesită. Vezi și FHIR Bundle explicat.

Conversia între ele

Conversia între CDA și FHIR funcționează în ambele direcții, cu limitări. Ghidul de implementare HL7 C-CDA pe FHIR mapează tipuri de documente, secțiuni și intrări la profiluri Composition și resurse; secțiunile narative devin text fără date. Conversia de la FHIR la CDA funcționează pentru resursele care se potrivesc șabloanelor C-CDA. În oricare direcție, originalul ar trebui păstrat ca un DocumentReference cu Provenance.

  • CDA → FHIR: ghidul de implementare C-CDA on FHIR al HL7 mapează tipurile de documente și secțiunile din SUA la profiluri de Compoziție; intrările se mapează la resurse (Problem Concern Act → Condition, Medication Activity → MedicationStatement, Result Observation → Observation). Maparea este deterministă pentru conținutul de Nivel 3 bine șablonat și pierdere pentru secțiunile narative, care devin text fără date.
  • FHIR → CDA: posibil pentru documente ale căror resurse se potrivesc șabloanelor C-CDA. Resursele FHIR libere, care nu au fost niciodată destinate ca document (un flux de Observații de la dispozitive purtabile), nu devin un CDA sensibil.
  • Păstrați originalul. Indiferent de direcția în care convertiți, stocați sursa așa cum a fost primită, ca un DocumentReference, și lăsați Provenance să indice de la resursele convertite către acesta. Conversia este o vizualizare, nu o înlocuire.

Când CDA este încă răspunsul corect

CDA este în continuare răspunsul corect atunci când partea receptoare îl solicită (tranziții de îngrijire în SUA, rezumatul pacientului și prescripția electronică MyHealth@EU, mai multe registre naționale de documente), atunci când conținutul este legal un document care trebuie semnat și păstrat integral, sau când infrastructura partenerului este IHE XDS, care indexează documente, nu resurse. În caz contrar, începeți cu FHIR.

Când partea receptoare o cere (tranzacții de îngrijire în SUA, rezumatul pacientului și prescripția electronică MyHealth@EU astăzi, mai multe registre naționale de documente); când conținutul este legal un document care trebuie semnat și păstrat întreg; când infrastructura partenerului este IHE XDS, care indexează documente și nu resurse. În toate celelalte cazuri, începeți cu FHIR și produceți un document FHIR acolo unde este necesar un document.

Pagini conexe

Surse

Întrebări frecvente

Este un document FHIR doar CDA în JSON?

Nu. Împărtășește principiile (întreg, semnat, lizibil de om, cu un antet), dar conținutul său sunt resurse FHIR obișnuite, astfel încât aceeași Observație poate exista într-un document și poate fi servită de API. În CDA, o intrare există doar în interiorul documentului său.

Pot semna un document FHIR?

Da. Bundle.signature deține o semnătură digitală peste bundle, iar ghidurile IPS și naționale descriu cum. În practică, multe implementări se bazează pe securitatea transportului și pe proveniență, mai degrabă decât pe semnături.

Are FHIR templateId?

Echivalentul este meta.profile, o listă de URL-uri canonice ale StructureDefinitions la care resursa pretinde că se conformează. Validatoarele verifică conformitatea așa cum schematronii CDA verifică șabloanele.

Ce ar trebui să aleagă un nou program național?

Programele recente (formatul de schimb EHDS, regulile de acces al pacienților din SUA, IPS) aleg FHIR, cu documente FHIR pentru rezumate și scrisori, și păstrează o cale CDA doar pentru partenerii legacy.

Anpheros Platform

Încearcă gratuit în sandbox

Primul apel FHIR în 5 minute. Un API HL7 FHIR R4 cu consimțământul pacientului integrat: încearcă-l în sandbox, apoi conectează-ți propria aplicație sau sistemul clinicii.

Gratuit · 30 de pacienți sintetici · fără card

Acest ghid este informativ și nu înlocuiește consultul medical. Pentru decizii despre sănătatea ta, vorbește cu medicul tău. În caz de urgență, sună la numărul de urgență local (112 în Europa).
Scris de
Echipa Anpheros

Anpheros construiește un dosar medical pe care pacientul îl controlează și îl poate da oricărei clinici, pe o platformă HL7 FHIR R4, cu sediul în UE. Ghidurile te ajută să-ți înțelegi și să-ți organizezi sănătatea; nu înlocuiesc medicul.

Despre Anpheros →