Rövid válasz: A CDA egyetlen dokumentumot ad: egy aláírt XML fájlt egy páciensről egy adott időpontban, ember által olvasható narratívával és számítógép által olvasható bejegyzésekkel, amelynek teljes egészében és változatlanul kell maradnia. A FHIR erőforrásokat ad: egy Pácienst, negyven Megfigyelést, három Állapotot, mindegyik saját URL-lel, amelyeket REST API-n keresztül függetlenül lehet lekérdezni, keresni és frissíteni. A FHIR az erőforrásokat egy dokumentumba is csomagolhatja (egy document típusú Bundle, amelyet egy Composition vezet), amely a CDA közvetlen megfelelője. Válassza a CDA-t, ha egy szabályozás vagy egy partner ezt megköveteli; válassza a FHIR-t API-khoz, alkalmazásokhoz és mindenhez, amit lekérdezni kell, nem pedig olvasni.
A két forma
A CDA és a FHIR két különböző formátummal rendelkezik. A CDA az HL7 v3 adattípusokra épülő, OID-azonosítókkal ellátott, teljes XML-dokumentumokat cserél le, amelyek kötelező narratívát tartalmaznak, nem támogatják a lekérdezést és a frissítést, és teljes dokumentum aláírást igényelnek. A FHIR egyedi JSON vagy XML erőforrásokat vagy Bundle-okat cserél le, kanonikus URL-ekkel azonosítva, beépített REST lekérdezéssel, verziókövetett frissítésekkel és implementációs útmutatókban közzétett profilokkal.
| CDA / C-CDA | FHIR | |
|---|---|---|
| Csere egysége | Egy teljes dokumentum | Erőforrás, vagy erőforrások Bundle-ja |
| Formátum | XML, HL7 v3 adat típusok | JSON vagy XML, FHIR adat típusok |
| Azonosítás | OID-k sablonokhoz és kódrendszerekhez | URL-ek (kanonikus) profilokhoz és kódrendszerekhez |
| Ember által olvasható rész | Minden szekcióban kötelező <text> |
Erőforrásonként opcionális text.div narratíva; dokumentumokban kötelező |
| Szállítás | Nincs definiálva; XDS, Direct, MLLP, email által szállítva | REST HTTPS-en keresztül, a szabvány által definiálva; üzenetküldés és dokumentumok is |
| Lekérdezés | Dokumentumon belül nem lehetséges; a regiszterek a fejlécet indexelik | Beépített: GET /Observation?patient=…&code=… |
| Frissítés | Soha; egy új dokumentum helyettesíti a régit | Az erőforrások verziószámozottak és helyben frissíthetők |
| Aláírás | Teljes dokumentum, XML-DSig | Teljes Bundle lehetséges; egyedi erőforrások ritkán aláírtak |
| Profilok | Sablonok (templateId) szekciónként és bejegyzésenként | StructureDefinition profilok erőforrásonként, implementációs útmutatókban közzétéve |
| Terminológia | LOINC szekciókódok, SNOMED/ICD/RxNorm bejegyzések | Ugyanazok a kódrendszerek, mint CodeableConcept |
Mit jelent a különbség a gyakorlatban
A gyakorlatban a CDA és a FHIR közötti különbség az, hogy a CDA alkalmas egyszer megírt és teljes egészében megőrzött tartalomra, például egy aláírt zárójelentésre, míg a FHIR az olyan adatokra alkalmas, amelyek növekednek és lekérdezhetők, mint például egy vérnyomás-sorozat. A CDA fogadója képes megjeleníteni, de az importáláshoz egyeztetnie kell; a FHIR fogadója olyan erőforrásokat kap, amelyek már a saját rekordjához hasonlóan vannak formázva.
Egy zárójelentés természetesen dokumentum: egyszer íródik, egy orvos írja alá, és évekkel később pontosan úgy kell reprodukálhatónak lennie, ahogy elolvasták. Egy vérnyomás-sorozat természetesen erőforrások halmaza: minden nap növekszik, ábrázolják és szűrik, és senki sem írja alá. A CDA jól kezeli az előbbit, és rosszul az utóbbit (minden új méréshez újra elküldené a teljes dokumentumot). A FHIR natívan kezeli az utóbbit, és az előbbit a dokumentum mechanizmusán keresztül.
A másik gyakorlati különbség az, hogy mit tehet a fogadó fél. Egy CDA fogadó mindig megjelenítheti a dokumentumot; a bejegyzések importálása egyeztetést igényel, szekciónként. Egy FHIR fogadó olyan erőforrásokat kap, amelyek már a saját rekordjának formájában vannak; a nehéz kérdések az identitásra (ez ugyanaz a páciens?) és a származásra (ki állította ezt és mikor?) tevődnek át. Lásd: Páciens illesztés.
FHIR dokumentumok: a találkozási pont
Egy FHIR dokumentum egy Bundle type: "document" értékkel, amelynek első bejegyzése egy Composition. A Composition játssza a CDA fejléc és a szekciólista szerepét: típus (LOINC), dátum, szerző, alany, gondozó, státusz, és section[] címmel, kóddal, narratív szöveggel és a hivatkozásokkal az erőforrásokra, amelyek az adatokat tartalmazzák.
{
"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"}]}}}
]
}
Az International Patient Summary pontosan ez: egy FHIR dokumentum profil, amelynek van egy CDA ikertestvére azoknak a rendszereknek, amelyeknek még szükségük van rá. Lásd még: FHIR Bundle magyarázata.
Átalakítás közöttük
A CDA és a FHIR közötti átalakítás mindkét irányban működik, korlátokkal. A HL7 C-CDA on FHIR implementációs útmutató a dokumentumtípusokat, szakaszokat és bejegyzéseket Composition profilokhoz és erőforrásokhoz rendeli; a csak narratívát tartalmazó szakaszok adatok nélküli szöveggé válnak. A FHIR-ből CDA-ba történő átalakítás olyan erőforrások esetében működik, amelyek illeszkednek a C-CDA sablonokhoz. Mindkét irányban az eredetit DocumentReference-ként kell megőrizni a Provenance-szel együtt.
- CDA → FHIR: az HL7 C-CDA on FHIR implementációs útmutató az amerikai dokumentumtípusokat és szekciókat Composition profilokhoz rendeli; a bejegyzések erőforrásokhoz (Problem Concern Act → Condition, Medication Activity → MedicationStatement, Result Observation → Observation). A megfeleltetés determinisztikus a jól sablonozott 3. szintű tartalom esetén, és veszteséges a csak narratív szekciók esetén, amelyek adatok nélküli szöveggé válnak.
- FHIR → CDA: lehetséges azoknál a dokumentumoknál, amelyek erőforrásai illeszkednek a C-CDA sablonokhoz. A szabad formátumú FHIR erőforrások, amelyeket soha nem dokumentumként szántak (viselhető megfigyelések folyamata), nem lesznek értelmes CDA-k.
- Tartsa meg az eredetit. Bármelyik irányba is alakít át, tárolja a forrást úgy, ahogy kapta, egy DocumentReference-ként, és hagyja, hogy a Provenance az átalakított erőforrásokról rá mutasson. Az átalakítás egy nézet, nem egy helyettesítés.
Mikor a CDA még mindig a helyes válasz
A CDA továbbra is a helyes válasz, ha a fogadó fél azt megköveteli (amerikai átmeneti ellátás, MyHealth@EU betegösszefoglaló és eRecept, számos nemzeti dokumentumregiszter), ha a tartalom jogilag olyan dokumentum, amelyet alá kell írni és teljes egészében meg kell őrizni, vagy ha a partner infrastruktúrája IHE XDS, amely dokumentumokat indexel az erőforrások helyett. Ellenkező esetben kezdje a FHIR-rel.
Amikor a fogadó fél ezt megköveteli (amerikai átmeneti ellátások, MyHealth@EU páciens összefoglaló és eRecept ma, több nemzeti dokumentumregiszter); amikor a tartalom jogilag dokumentum, amelyet alá kell írni és egészében meg kell őrizni; amikor a partner infrastruktúrája IHE XDS, amely dokumentumokat indexel, nem pedig erőforrásokat. Minden más esetben kezdje a FHIR-rel, és hozzon létre FHIR dokumentumot, ahol dokumentumra van szükség.
Kapcsolódó oldalak
- CDA és C-CDA magyarázata
- FHIR Bundle magyarázata
- Az International Patient Summary
- HL7 vs FHIR
- DocumentReference vs DiagnosticReport vs Binary
- Páciens illesztés
Források
- HL7 FHIR R4: Documents
- HL7 FHIR R4: Composition
- HL7 C-CDA on FHIR implementation guide
- HL7 FHIR: comparison with CDA (Appendix)
- HL7 FHIR: International Patient Summary IG
Gyakori kérdések
A FHIR dokumentum csak CDA JSON-ban?
Nem. Megosztja az elveket (egész, aláírt, ember által olvasható, fejlécet tartalmazó), de a tartalma hétköznapi FHIR erőforrások, így ugyanaz az Observation élhet egy dokumentumban és szolgálható ki az API-n keresztül. A CDA-ban egy bejegyzés csak a dokumentumán belül létezik.
Aláírhatok egy FHIR dokumentumot?
Igen. A Bundle.signature tartalmaz egy digitális aláírást a bundle felett, és az IPS és a nemzeti útmutatók leírják, hogyan. A gyakorlatban sok telepítés támaszkodik a szállítási biztonságra és a származásra az aláírások helyett.
Van a FHIR-nek templateId-je?
Az egyenérték a meta.profile, a StructureDefinition-ök kanonikus URL-jeinek listája, amelyekhez az erőforrás illeszkedik. A validátorok az illeszkedést úgy ellenőrzik, ahogyan a CDA sémák sablonokat ellenőriznek.
Mit válasszon egy új nemzeti program?
A legújabb programok (az EHDS csereformátum, az amerikai páciens hozzáférési szabályok, az IPS) FHIR-t választanak, FHIR dokumentumokkal az összefoglalókhoz és levelekhez, és csak a régi partnerek számára tartanak fenn CDA utat.
Próbálja ki ingyen a sandboxban
Az első FHIR-hívás 5 perc alatt. Egy HL7 FHIR R4 API, amely tartalmazza a beteg beleegyezését: próbáld ki a sandboxban, majd csatlakoztasd saját alkalmazásodat vagy klinikai rendszeredet.
Ingyenes · 30 szintetikus beteg · kártya nélkül
Az Anpheros egy olyan egészségügyi nyilvántartást épít, amelyet a beteg irányít, és megoszthat bármelyik klinikával, egy EU-ban működő HL7 FHIR R4 platformon. Ezek az útmutatók segítenek megérteni és rendszerezni az egészségügyi adataidat; nem helyettesítik az orvosodat.
Tudj meg többet az Anpherosról →