Risposta breve: i dati sanitari si muovono attraverso quattro livelli di standard. Gli standard di scambio trasportano i dati tra i sistemi: messaggi HL7 v2, documenti CDA, risorse FHIR e DICOM per le immagini. Gli standard di modellazione e archiviazione definiscono come un record è strutturato all'interno di un sistema: openEHR per i record clinici, OMOP per i database di ricerca. Le terminologie assegnano a ogni concetto un codice che entrambe le parti comprendono: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. Gli standard di identità e sicurezza decidono chi può leggere cosa: OAuth 2.0 e SMART on FHIR, più i profili IHE che combinano tutto quanto sopra in ricette testate. Nessuno usa un solo standard; un ospedale tipicamente utilizza tutti e quattro i livelli contemporaneamente.
La mappa
Gli standard di interoperabilità sanitaria sono organizzati in quattro livelli. Gli standard di scambio (HL7 v2, CDA, FHIR, DICOM e DICOMweb) spostano i dati tra i sistemi, mentre i profili IHE li combinano in soluzioni testate. openEHR struttura il dato archiviato e OMOP struttura i database di ricerca. Terminologie come SNOMED CT e LOINC, e standard di identità come SMART on FHIR, sono utilizzate all'interno di tutti questi.
| Livello | Standard | Cos'è | Dove lo si incontra nel 2026 |
|---|---|---|---|
| Scambio | HL7 v2 | Messaggi delimitati da pipe (ADT, ORU, ORM, SIU) su MLLP | All'interno degli ospedali: ricoveri, risultati di laboratorio, ordini, programmazione. Ancora l'interfaccia più comune |
| Scambio | CDA / C-CDA | Documenti clinici XML con una parte leggibile dall'uomo e voci codificate | Riassunti di dimissione, lettere di riferimento, il C-CDA statunitense, riassunti transfrontalieri in MyHealth@EU |
| Scambio | FHIR (R4, R4B, R5) | Risorse web (Patient, Observation, Condition…) su REST e JSON | App per pazienti, API nazionali, API EHR, US Core, l'IPS, il formato di scambio EHDS |
| Scambio | DICOM e DICOMweb | Oggetti immagine con metadati incorporati; DICOMweb è la sua interfaccia REST | Ogni scanner, PACS e visualizzatore di radiologia; i visualizzatori web utilizzano DICOMweb |
| Ricette | Profili IHE | Combinazioni testate degli standard sopra menzionati per un caso d'uso specifico (XDS, PIX/PDQ, XCA, SWF) | Condivisione di documenti tra ospedali e regioni, identità del paziente, flusso di lavoro radiologico |
| Archiviazione | openEHR | Modello di dati clinici basato su archetipi per il record stesso | Piattaforme EHR ospedaliere e nazionali in parti d'Europa, Scandinavia, Brasile |
| Ricerca | OMOP CDM | Un modello relazionale comune per la ricerca osservazionale | Reti di ricerca, real-world evidence, uso secondario EHDS |
| Terminologia | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | Codici per riscontri, test, diagnosi, farmaci, unità di misura | All'interno di ciascuno degli standard sopra menzionati |
| Identità | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | Chi è l'utente e a cosa l'app può accedere | Ogni app rivolta ai pazienti e ogni piattaforma di app EHR |
Come si integrano i livelli
I livelli degli standard di interoperabilità sanitaria si integrano svolgendo ciascuno un compito nello stesso flusso di lavoro: un messaggio HL7 v2 trasporta un ordine di laboratorio, LOINC e UCUM codificano il risultato, una piattaforma openEHR lo archivia, un'API FHIR lo rende disponibile a un'app per pazienti dopo un accesso SMART on FHIR, e un documento CDA lo condivide con un altro ospedale.
Un esame del sangue mostra tutti e quattro i livelli in un pomeriggio. L'ordine lascia il reparto come messaggio HL7 v2 ORM (scambio). Il risultato dell'analizzatore torna come HL7 v2 ORU, con il test codificato in LOINC e l'unità in UCUM (terminologia). L'ospedale lo archivia nel proprio database, forse una piattaforma openEHR (archiviazione). L'app del paziente la legge tramite un'API FHIR come Observation, dopo che il paziente si è autenticato con SMART on FHIR (identità). Se l'ospedale condivide il referto completo con un altro ospedale, può farlo come documento CDA tramite un registro IHE XDS. Se il risultato viene successivamente aggiunto a una coorte di ricerca, viene convertito in OMOP.
Gli standard non sono in competizione. Ognuno è stato creato per un lavoro diverso e sostituirne uno con un altro di solito significa ricostruire qualcosa che già funziona.
Quale ti serve?
Lo standard di interoperabilità sanitaria di cui hai bisogno dipende dal compito: FHIR R4 con SMART on FHIR per app per pazienti o medici, HL7 v2 per connettersi ai sistemi ospedalieri esistenti, DICOM e DICOMweb per le immagini, documenti CDA o FHIR per documenti completi, openEHR per l'archiviazione a lungo termine dei dati, OMOP per la ricerca, e profili IHE quando due sistemi devono comportarsi in modo identico.
- Stai creando un'app per pazienti o medici: FHIR R4, con i profili del tuo mercato (guide all'implementazione), SMART on FHIR per l'accesso.
- Ti stai connettendo ai sistemi esistenti di un ospedale: aspettati prima HL7 v2; FHIR dove il fornitore lo offre. Vedi Messaggi HL7 v2 spiegati.
- Gestisci immagini: DICOM per l'archiviazione e il trasferimento, DICOMweb per qualsiasi cosa in un browser, FHIR ImagingStudy solo per i metadati. Vedi DICOMweb spiegato e ImagingStudy vs DICOMweb.
- Scambi documenti completi (riassunti, lettere): CDA dove è obbligatorio, documenti FHIR (un Bundle di tipo
document) dove puoi scegliere. Vedi CDA e C-CDA spiegati. - Progetti come un record viene archiviato per decenni: openEHR, con FHIR come livello di scambio. Vedi openEHR vs FHIR.
- Gestisci ricerche su molti record: OMOP, con FHIR come sorgente. Vedi Uso secondario dei dati sanitari.
- Hai bisogno che due sistemi si comportino allo stesso modo: scegli il profilo IHE per il tuo caso d'uso e testa contro di esso.
Dove si posiziona Anpheros
Anpheros Platform si posiziona nel livello di scambio della mappa degli standard come server FHIR R4 con accesso OAuth 2.0 e webhook per le notifiche di modifica, ricevendo risultati di laboratorio tramite un connettore da HL7 v2 ORU, CSV o JSON. Non archivia immagini DICOM e non offre un servizio CDS Hooks; questi rimangono nei sistemi ospedalieri.
Anpheros Platform è un server FHIR R4 con le risorse necessarie per un record incentrato sul paziente (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance e altri), OAuth 2.0 per l'accesso e webhook per le notifiche di modifica. I risultati di laboratorio arrivano tramite il connettore di laboratorio da HL7 v2 ORU, CSV o JSON. Non archivia immagini DICOM e non offre un servizio CDS Hooks; questi rimangono nei sistemi dell'ospedale e il record vi fa riferimento.
Ordine di lettura
Un buon ordine di lettura per gli standard di interoperabilità sanitaria inizia con cos'è FHIR e in cosa differisce da HL7 v2, poi la risorsa FHIR Observation, poi le terminologie LOINC e SNOMED CT utilizzate al suo interno, poi DICOMweb per le immagini, CDA per i documenti e infine openEHR confrontato con FHIR per come vengono archiviati i dati.
Se sei nuovo nel settore: Cos'è FHIR → HL7 vs FHIR → FHIR Observation → LOINC e SNOMED CT → DICOMweb → CDA → openEHR vs FHIR.
Pagine correlate
- HL7 vs FHIR
- Messaggi HL7 v2 spiegati
- CDA e C-CDA spiegati
- DICOMweb spiegato
- openEHR vs FHIR
- Guide all'implementazione FHIR
- FHIR R4 vs R5
- Cos'è un codice LOINC?
- Cos'è SNOMED CT?
- DICOM vs FHIR per sviluppatori
- Profili ed estensioni FHIR spiegati
- Server di terminologia FHIR spiegati
- Mappa della regolamentazione dei dati sanitari
- Cartelle cliniche elettroniche nazionali in Europa e negli Stati Uniti
- Integrazione dei sistemi ospedalieri spiegata
- AI sui dati medici
- Uso secondario dei dati sanitari
- Sicurezza e identità nelle app sanitarie
Fonti
- HL7 International: standard
- Specifiche HL7 FHIR R4
- Standard DICOM, edizione corrente
- Framework tecnici IHE
- Specifiche openEHR
- OHDSI OMOP Common Data Model
- SMART App Launch
Domande frequenti
FHIR sta sostituendo tutti gli altri standard?
No. FHIR sta sostituendo le API personalizzate e, lentamente, alcuni scambi di documenti CDA. HL7 v2 rimane il cavallo di battaglia all'interno degli ospedali, DICOM rimane l'unico standard per le immagini, e openEHR e OMOP rispondono a domande (archiviazione, ricerca) per le quali FHIR non è stato progettato.
Qual è la differenza tra uno standard e un profilo IHE?
Uno standard come FHIR o DICOM definisce i blocchi costitutivi. Un profilo IHE seleziona blocchi specifici, ne fissa le opzioni e dice esattamente come i sistemi devono utilizzarli per un determinato compito, in modo che due fornitori che superano entrambi i test IHE possano lavorare insieme senza un progetto.
Quali standard utilizzano i sistemi sanitari nazionali?
La maggior parte dei sistemi europei ha iniziato con documenti CDA e HL7 v2, e sta aggiungendo API FHIR; il formato di scambio EHDS è basato su FHIR e sull'IPS. Gli Stati Uniti impongono FHIR US Core per l'accesso dei pazienti e C-CDA per lo scambio di documenti.
Dove si inseriscono SNOMED CT e LOINC?
Non sono standard di scambio; sono vocabolari utilizzati all'interno di tutti loro. Un codice LOINC identifica il test in un segmento HL7 v2 OBX, una voce CDA e un FHIR Observation allo stesso modo.
Provalo gratis nella sandbox
La tua prima chiamata FHIR in 5 minuti. Un'API HL7 FHIR R4 con il consenso del paziente integrato: provala nella sandbox, poi collega la tua app o il sistema della tua clinica.
Gratis · 30 pazienti sintetici · senza carta
Anpheros sviluppa una cartella clinica che il paziente controlla e può condividere con qualsiasi studio medico, su una piattaforma HL7 FHIR R4, con sede in UE. Queste guide ti aiutano a comprendere e organizzare la tua salute; non sostituiscono il tuo medico.
Chi siamo →