Rövid válasz: az egészségügyi adatok négy szabványszinten mozognak. Az adatcsere szabványok viszik az adatokat a rendszerek között: HL7 v2 üzenetek, CDA dokumentumok, FHIR erőforrások és DICOM a képekhez. Az adatmodellezés és tárolás szabványok mondják meg, hogyan épül fel egy rekord egy rendszeren belül: openEHR a klinikai rekordokhoz, OMOP a kutatási adatbázisokhoz. A terminológiák minden fogalomhoz adnak egy kódot, amit mindkét fél megért: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. Az identitás és biztonság szabványok döntik el, ki mit olvashat: OAuth 2.0 és SMART on FHIR, valamint az IHE profilok, amelyek mindezeket tesztelt receptekbe kombinálják. Senki sem használ csak egyet; egy kórház általában mind a négy szintet egyszerre futtatja.
A térkép
Az egészségügyi interoperabilitási szabványok négy rétegből állnak. A csere szabványok (HL7 v2, CDA, FHIR, DICOM és DICOMweb) adatokat mozgatnak rendszerek között, az IHE profilok pedig tesztelt receptekbe foglalják őket. Az openEHR tárolt rekordokat strukturál, az OMOP pedig kutatási adatbázisokat. Az összesben olyan terminológiákat használnak, mint a SNOMED CT és a LOINC, valamint olyan identitásszabványokat, mint a SMART on FHIR.
| Szint | Szabvány | Mi ez? | Hol találkozol vele 2026-ban? |
|---|---|---|---|
| Adatcsere | HL7 v2 | Csődelválasztott üzenetek (ADT, ORU, ORM, SIU) MLLP-n keresztül | Kórházakon belül: bevételezés, laboreredmények, rendelések, ütemezés. Még mindig a legelterjedtebb interfész |
| Adatcsere | CDA / C-CDA | XML alapú klinikai dokumentumok ember által olvasható résszel és kódolt bejegyzésekkel | Zárójelentések, beutaló levelek, az amerikai C-CDA, határon átnyúló összefoglalók a MyHealth@EU-ban |
| Adatcsere | FHIR (R4, R4B, R5) | Webes erőforrások (Patient, Observation, Condition…) REST és JSON protokollon keresztül | Betegalkalmazások, nemzeti API-k, EHR API-k, US Core, az IPS, az EHDS csereformátum |
| Adatcsere | DICOM és DICOMweb | Képobjektumok beágyazott metaadatokkal; a DICOMweb a REST-es felülete | Minden szkenner, PACS és radiológiai megjelenítő; a webes megjelenítők DICOMweb-et használnak |
| Receptek | IHE profilok | A fentiek tesztelt kombinációi egy adott használati esetre (XDS, PIX/PDQ, XCA, SWF) | Dokumentum megosztás kórházak és régiók között, betegazonosítás, radiológiai munkafolyamat |
| Tárolás | openEHR | Archetípus-alapú klinikai adatmodell magának a rekordnak | Kórházi és nemzeti EHR platformok Európa egyes részein, Skandináviában, Brazíliában |
| Kutatás | OMOP CDM | Közös relációs modell megfigyeléses kutatásokhoz | Kutatási hálózatok, valós idejű bizonyítékok, EHDS másodlagos felhasználás |
| Terminológia | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | Kódok leletekhez, vizsgálatokhoz, diagnózisokhoz, gyógyszerekhez, egységekhez | A fenti szabványok mindegyikében |
| Identitás | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | Ki a felhasználó és mit érhet el az alkalmazás | Minden betegközpontú alkalmazás és minden EHR alkalmazás platform |
Hogyan illeszkednek egymáshoz a szintek?
Az egészségügyi interoperabilitási szabványok rétegei úgy illeszkednek egymáshoz, hogy mindegyik egy feladatot végez ugyanabban a munkafolyamatban: egy HL7 v2 üzenet továbbít egy laboratóriumi rendelést, a LOINC és az UCUM kódolja az eredményt, egy openEHR platform tárolja azt, egy FHIR API a SMART on FHIR bejelentkezés után elérhetővé teszi egy páciensalkalmazás számára, egy CDA dokumentum pedig megosztja egy másik kórházzal.
Egy vérvizsgálat egy délután alatt mind a négy szintet bemutatja. A rendelés az osztályról HL7 v2 ORM üzenetként távozik (adatcsere). Az analizátor eredménye HL7 v2 ORU üzenetként érkezik vissza, a vizsgálat LOINC kóddal, az egység pedig UCUM kóddal van jelölve (terminológia). A kórház a saját adatbázisában tárolja, talán egy openEHR platformon (tárolás). A beteg alkalmazása egy FHIR API-n keresztül olvassa le Megfigyelésként (Observation), miután a beteg bejelentkezett a SMART on FHIR segítségével (identitás). Ha a kórház megosztja a teljes jelentést egy másik kórházzal, azt CDA dokumentumként teheti meg egy IHE XDS nyilvántartón keresztül. Ha az eredmény később bekerül egy kutatási kohorszba, OMOP-ra konvertálják.
A szabványok nem versenytársak. Mindegyiket más feladatra tervezték, és az egyiknek a másikkal való helyettesítése általában már működő dolgok újjáépítését jelenti.
Melyikre van szükséged?
Melyik egészségügyi interoperabilitási szabványra van szükséged, attól függ, hogy mi a feladat: FHIR R4 SMART on FHIR-rel páciens- vagy orvosalkalmazásokhoz, HL7 v2 meglévő kórházi rendszerekhez való csatlakozáshoz, DICOM és DICOMweb képekhez, CDA vagy FHIR dokumentumok teljes dokumentumokhoz, openEHR hosszú távú rekordtároláshoz, OMOP kutatáshoz, és IHE profilok, ha két rendszernek azonos módon kell viselkednie.
- Betegeknek vagy orvosoknak szóló alkalmazást fejlesztesz: FHIR R4, a piacod profiljaival (implementációs útmutatók), SMART on FHIR a bejelentkezéshez.
- Egy kórház meglévő rendszereihez csatlakozol: számíts először HL7 v2-re; FHIR, ahol a szállító kínálja. Lásd: HL7 v2 üzenetek magyarázata.
- Képekkel foglalkozol: DICOM tárolásra és átvitelre, DICOMweb böngészőben való megjelenítésre, FHIR ImagingStudy csak a metaadatokhoz. Lásd: DICOMweb magyarázata és ImagingStudy vs DICOMweb.
- Teljes dokumentumokat (összefoglalók, levelek) cserélsz: CDA, ahol kötelező, FHIR dokumentumok (Bundle típusú
document), ahol választhatsz. Lásd: CDA és C-CDA magyarázata. - Egy rekord évtizedekig tartó tárolását tervezed: openEHR, FHIR-rel mint adatcsere réteggel. Lásd: openEHR vs FHIR.
- Sok rekord kutatását végzed: OMOP, FHIR-rel mint forrással. Lásd: Egészségügyi adatok másodlagos felhasználása.
- Két rendszernek ugyanúgy kell működnie: válaszd ki a használni kívánt IHE profilt, és teszteld azt.
Hol helyezkedik el az Anpheros?
Az Anpheros Platform a szabványtérkép csere rétegében helyezkedik el, mint egy FHIR R4 szerver OAuth 2.0 hozzáféréssel és webhookokkal a változási értesítésekhez, HL7 v2 ORU, CSV vagy JSON csatlakozón keresztül fogadva a laboreredményeket. Nem tárol DICOM képeket, és nem kínál CDS Hooks szolgáltatást; ezek a kórházi rendszerekben maradnak.
Az Anpheros Platform egy FHIR R4 szerver, amely a betegközpontú rekordhoz szükséges erőforrásokkal rendelkezik (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance és mások), OAuth 2.0-val a hozzáféréshez, és webhookokkal a változási értesítésekhez. A laboreredmények a labor csatlakozón keresztül érkeznek HL7 v2 ORU, CSV vagy JSON formátumban. Nem tárol DICOM képeket, és nem kínál CDS Hooks szolgáltatást; ezek a kórház rendszereiben maradnak, és a rekord rájuk mutat.
Olvasási sorrend
Az egészségügyi interoperabilitási szabványok jó olvasási sorrendje azzal kezdődik, hogy mi a FHIR és miben különbözik az HL7 v2-től, majd a FHIR Observation erőforrás, azután a benne használt LOINC és SNOMED CT terminológiák, majd a DICOMweb képekhez, a CDA dokumentumokhoz, és végül az openEHR összehasonlítása a FHIR-rel a rekordok tárolásának módját illetően.
Ha új vagy a területen: Mi az a FHIR → HL7 vs FHIR → FHIR Observation → LOINC és SNOMED CT → DICOMweb → CDA → openEHR vs FHIR.
Kapcsolódó oldalak
- HL7 vs FHIR
- HL7 v2 üzenetek magyarázata
- CDA és C-CDA magyarázata
- DICOMweb magyarázata
- openEHR vs FHIR
- FHIR implementációs útmutatók
- FHIR R4 vs R5
- Mi az a LOINC kód?
- Mi az a SNOMED CT?
- DICOM vs FHIR fejlesztőknek
- FHIR profilok és kiterjesztések magyarázata
- FHIR terminológiai szerverek magyarázata
- Egészségügyi adatok szabályozási térképe
- Nemzeti elektronikus egészségügyi nyilvántartások Európában és az USA-ban
- Kórházi rendszerek integrációja magyarázata
- AI az orvosi adatokon
- Egészségügyi adatok másodlagos felhasználása
- Biztonság és identitás egészségügyi alkalmazásokban
Források
- HL7 International: standards
- HL7 FHIR R4 specification
- DICOM standard, current edition
- IHE technical frameworks
- openEHR specifications
- OHDSI OMOP Common Data Model
- SMART App Launch
Gyakori kérdések
Felváltja a FHIR az összes többi szabványt?
Nem. A FHIR felváltja az egyedi API-kat és lassan néhány CDA dokumentumcserét. A HL7 v2 marad a kórházakon belüli munka ló, a DICOM marad az egyetlen szabvány a képekhez, és az openEHR és az OMOP olyan kérdésekre válaszol (tárolás, kutatás), amelyekre a FHIR-t nem tervezték.
Mi a különbség egy szabvány és egy IHE profil között?
Egy szabvány, mint a FHIR vagy a DICOM, építőelemeket határoz meg. Egy IHE profil kiválaszt bizonyos elemeket, rögzíti azok opcióit, és pontosan megmondja, hogyan kell a rendszereknek használniuk őket egy feladathoz, így két olyan gyártó, aki mindkettő átment az IHE teszteken, együtt tud dolgozni egy projekt nélkül.
Melyik szabványt használják a nemzeti egészségügyi rendszerek?
A legtöbb európai rendszer CDA dokumentumokkal és HL7 v2-vel indult, és FHIR API-kat adnak hozzá; az EHDS csereformátum FHIR-re és az IPS-re épül. Az USA a FHIR US Core-t írja elő a beteghozzáféréshez és a C-CDA-t a dokumentumcseréhez.
Hol illeszkednek a SNOMED CT és a LOINC?
Nem adatcsere szabványok; olyan szókészletek, amelyeket mindegyikben használnak. Egy LOINC kód azonosítja a vizsgálatot egy HL7 v2 OBX szegmensben, egy CDA bejegyzésben és egy FHIR Observation-ben egyaránt.
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 →