Răspuns scurt: datele despre sănătate circulă prin patru niveluri de standarde. Standardele de schimb transportă datele între sisteme: mesaje HL7 v2, documente CDA, resurse FHIR și DICOM pentru imagini. Standardele de modelare și stocare spun cum este structurat un dosar în interiorul unui sistem: openEHR pentru dosare clinice, OMOP pentru baze de date de cercetare. Terminologiile oferă fiecărui concept un cod pe care ambele părți îl înțeleg: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. Standardele de identitate și securitate decid cine poate citi ce: OAuth 2.0 și SMART on FHIR, plus profiluri IHE care combină toate cele de mai sus în rețete testate. Nimeni nu folosește doar unul; un spital rulează de obicei toate cele patru niveluri simultan.
Harta
Standardele de interoperabilitate în domeniul sănătății formează patru niveluri. Standardele de schimb (HL7 v2, CDA, FHIR, DICOM și DICOMweb) transferă date între sisteme, iar profilurile IHE le combină în rețete testate. openEHR structurează înregistrarea stocată, iar OMOP structurează bazele de date de cercetare. Terminologii precum SNOMED CT și LOINC, și standarde de identitate precum SMART on FHIR, sunt utilizate în toate acestea.
| Nivel | Standard | Ce este | Unde îl întâlnești în 2026 |
|---|---|---|---|
| Schimb | HL7 v2 | Mesaje delimitate prin caracterul „pipe” (ADT, ORU, ORM, SIU) peste MLLP | În spitale: internări, rezultate de laborator, comenzi, programări. Încă cea mai comună interfață |
| Schimb | CDA / C-CDA | Documente clinice XML cu o parte lizibilă pentru om și intrări codificate | Scrisori de externare, scrisori de trimitere, C-CDA din SUA, rezumate transfrontaliere în MyHealth@EU |
| Schimb | FHIR (R4, R4B, R5) | Resurse web (Patient, Observation, Condition…) peste REST și JSON | Aplicații pentru pacienți, API-uri naționale, API-uri EHR, US Core, IPS, formatul de schimb EHDS |
| Schimb | DICOM și DICOMweb | Obiecte de imagine cu metadate încorporate; DICOMweb este fața sa REST | Fiecare scaner, PACS și vizualizator de radiologie; vizualizatoarele web folosesc DICOMweb |
| Rețete | Profiluri IHE | Combinații testate ale celor de mai sus pentru un caz de utilizare (XDS, PIX/PDQ, XCA, SWF) | Partajarea documentelor între spitale și regiuni, identitatea pacientului, flux de lucru radiologic |
| Stocare | openEHR | Model de date clinice bazat pe arhetipuri pentru dosarul în sine | Platforme EHR spitalicești și naționale în părți din Europa, Scandinavia, Brazilia |
| Cercetare | OMOP CDM | Un model relațional comun pentru cercetarea observațională | Rețele de cercetare, dovezi din lumea reală, utilizare secundară EHDS |
| Terminologie | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | Coduri pentru constatări, teste, diagnostice, medicamente, unități | În interiorul fiecărui standard de mai sus |
| Identitate | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | Cine este utilizatorul și la ce are acces aplicația | Fiecare aplicație orientată către pacient și fiecare platformă de aplicații EHR |
Cum se potrivesc nivelurile
Nivelurile standardelor de interoperabilitate în domeniul sănătății se potrivesc prin faptul că fiecare își îndeplinește o sarcină în același flux de lucru: un mesaj HL7 v2 transportă o cerere de analize de laborator, codurile LOINC și UCUM codifică rezultatul, o platformă openEHR îl stochează, o API FHIR îl servește unei aplicații pentru pacienți după o autentificare SMART on FHIR, iar un document CDA îl partajează cu un alt spital.
Un test de sânge arată toate cele patru niveluri într-o după-amiază. Comanda părăsește secția ca un mesaj HL7 v2 ORM (schimb). Rezultatul analizorului revine ca un HL7 v2 ORU, cu testul codificat în LOINC și unitatea în UCUM (terminologie). Spitalul îl stochează în propria bază de date, poate o platformă openEHR (stocare). Aplicația pacientului o citește printr-un API FHIR ca o Observație, după ce pacientul s-a autentificat cu SMART on FHIR (identitate). Dacă spitalul partajează raportul complet cu un alt spital, o poate face ca un document CDA printr-un registru IHE XDS. Dacă rezultatul se alătură ulterior unei cohorte de cercetare, este convertit în OMOP.
Standardele nu sunt concurenți. Fiecare a fost construit pentru o sarcină diferită, iar înlocuirea unuia cu altul implică de obicei reconstruirea a ceva ce funcționează deja.
De care ai nevoie?
Standardul de interoperabilitate în domeniul sănătății de care ai nevoie depinde de sarcină: FHIR R4 cu SMART on FHIR pentru aplicații pentru pacienți sau clinicieni, HL7 v2 pentru conectarea la sistemele spitalicești existente, DICOM și DICOMweb pentru imagini, documente CDA sau FHIR pentru documente complete, openEHR pentru stocarea pe termen lung a înregistrărilor, OMOP pentru cercetare și profiluri IHE atunci când două sisteme trebuie să funcționeze identic.
- Construiești o aplicație pentru pacienți sau clinicieni: FHIR R4, cu profilurile pieței tale (ghiduri de implementare), SMART on FHIR pentru autentificare.
- Te conectezi la sistemele existente ale unui spital: așteaptă-te mai întâi la HL7 v2; FHIR acolo unde furnizorul îl oferă. Vezi Mesaje HL7 v2 explicate.
- Gestionezi imagini: DICOM pentru stocare și transfer, DICOMweb pentru orice în browser, FHIR ImagingStudy doar pentru metadate. Vezi DICOMweb explicat și ImagingStudy vs DICOMweb.
- Schimbi documente întregi (rezumate, scrisori): CDA acolo unde este mandatat, documente FHIR (un Bundle de tip
document) unde poți alege. Vezi CDA și C-CDA explicate. - Proiectezi cum este stocat un dosar pe decenii: openEHR, cu FHIR ca strat de schimb. Vezi openEHR vs FHIR.
- Derulezi cercetare pe mai multe dosare: OMOP, cu FHIR ca sursă. Vezi Utilizarea secundară a datelor despre sănătate.
- Ai nevoie ca două sisteme să se comporte la fel: alege profilul IHE pentru cazul tău de utilizare și testează-l.
Unde se încadrează Anpheros
Platforma Anpheros se află în stratul de schimb al hărții standardelor ca server FHIR R4 cu acces OAuth 2.0 și webhooks pentru notificări de modificare, primind rezultate de laborator printr-un conector din HL7 v2 ORU, CSV sau JSON. Nu stochează imagini DICOM și nu oferă un serviciu CDS Hooks; acestea rămân în sistemele spitalicești.
Anpheros Platform este un server FHIR R4 cu resursele necesare unui dosar centrat pe pacient (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance și altele), OAuth 2.0 pentru acces și webhooks pentru notificări de modificare. Rezultatele de laborator sosesc prin conectorul de laborator din HL7 v2 ORU, CSV sau JSON. Nu stochează imagini DICOM și nu oferă un serviciu CDS Hooks; acestea rămân în sistemele spitalului, iar dosarul face referire la ele.
Ordinea de citire
O ordine bună de citire pentru standardele de interoperabilitate în domeniul sănătății începe cu ce este FHIR și cum diferă de HL7 v2, apoi resursa FHIR Observation, apoi terminologiile LOINC și SNOMED CT utilizate în cadrul acesteia, apoi DICOMweb pentru imagini, CDA pentru documente și, în final, openEHR comparat cu FHIR pentru modul în care sunt stocate înregistrările.
Dacă ești nou în domeniu: Ce este FHIR → HL7 vs FHIR → FHIR Observation → LOINC și SNOMED CT → DICOMweb → CDA → openEHR vs FHIR.
Pagini înrudite
- HL7 vs FHIR
- Mesaje HL7 v2 explicate
- CDA și C-CDA explicate
- DICOMweb explicat
- openEHR vs FHIR
- Ghiduri de implementare FHIR
- FHIR R4 vs R5
- Ce este un cod LOINC?
- Ce este SNOMED CT?
- DICOM vs FHIR pentru dezvoltatori
- Profiluri și extensii FHIR explicate
- Servere de terminologie FHIR explicate
- Hartă reglementări date despre sănătate
- Dosare electronice naționale de sănătate în Europa și SUA
- Integrarea sistemelor spitalicești explicată
- AI pe date medicale
- Utilizarea secundară a datelor despre sănătate
- Securitate și identitate în aplicațiile de sănătate
Surse
- HL7 International: standarde
- Specificația HL7 FHIR R4
- Standardul DICOM, ediția curentă
- Framework-uri tehnice IHE
- Specificații openEHR
- OHDSI OMOP Common Data Model
- SMART App Launch
Întrebări frecvente
Înlocuiește FHIR toate celelalte standarde?
Nu. FHIR înlocuiește API-urile personalizate și, încet, unele schimburi de documente CDA. HL7 v2 rămâne motorul principal în spitale, DICOM rămâne singurul standard pentru imagini, iar openEHR și OMOP răspund întrebărilor (stocare, cercetare) la care FHIR nu a fost conceput să răspundă.
Care este diferența dintre un standard și un profil IHE?
Un standard precum FHIR sau DICOM definește blocuri de construcție. Un profil IHE selectează blocuri specifice, le fixează opțiunile și spune exact cum trebuie să le folosească sistemele pentru o anumită sarcină, astfel încât doi furnizori care trec amândoi testele IHE să poată lucra împreună fără un proiect.
Ce standard folosesc sistemele naționale de sănătate?
Majoritatea sistemelor europene au început cu documente CDA și HL7 v2 și adaugă API-uri FHIR; formatul de schimb EHDS este construit pe FHIR și IPS. SUA impune FHIR US Core pentru accesul pacienților și C-CDA pentru schimbul de documente.
Unde se încadrează SNOMED CT și LOINC?
Nu sunt standarde de schimb; sunt vocabularuri utilizate în toate acestea. Un cod LOINC identifică testul într-un segment HL7 v2 OBX, o intrare CDA și o Observație FHIR în mod egal.
Î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
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 →