Risposta breve: il OMOP Common Data Model (Observational Medical Outcomes Partnership CDM), mantenuto dalla community OHDSI, è uno schema relazionale in cui i dati sanitari da qualsiasi fonte (cartelle cliniche elettroniche, richieste di rimborso, registri) vengono convertiti, insieme a un set di vocabolari standardizzati che mappano ogni codice locale a un concept id standard. Una volta che un database è in formato OMOP, lo stesso codice di analisi (una definizione di coorte, una stima di incidenza, uno studio di efficacia comparativa) viene eseguito invariato su centinaia di database in tutto il mondo, e vengono condivisi solo i risultati aggregati. OMOP è il modello per la ricerca; FHIR è il modello per lo scambio e la cura; una mappatura pubblicata li collega, e la maggior parte delle piattaforme di ricerca accetta ora FHIR come fonte per il loro ETL OMOP.
Il modello in un'immagine
Il modello OMOP Common Data Model rappresenta tutto come un evento relativo a una persona durante un periodo di osservazione, con il dominio clinico che decide la tabella: condition_occurrence per le diagnosi, drug_exposure per i farmaci, measurement per i risultati di laboratorio e i parametri vitali, procedure_occurrence, visit_occurrence, observation per altri fatti, più le tabelle person, death, note, specimen, provider e cost. La versione 5.4 è la più diffusa.
Tutto è un evento su una persona durante un periodo di osservazione, con il dominio clinico che decide la tabella:
| Tabella | Contiene | Vocabolario standard (tipico) | Fonte FHIR |
|---|---|---|---|
| person | Una riga per persona: sesso, data di nascita, razza, etnia, luogo | Concetti di sesso, razza, etnia | Patient |
| observation_period | Periodi durante i quali ci si aspetta dati sulla persona | — | Derivato dalle date di copertura e degli incontri |
| visit_occurrence (e visit_detail) | Incontri: ricovero, ambulatoriale, pronto soccorso, con date | Concetti di visita | Encounter |
| condition_occurrence | Diagnosi e problemi con inizio e fine | SNOMED CT | Condition (codici ICD mappati a SNOMED) |
| drug_exposure | Prescrizioni, dispensazioni, somministrazioni con quantità e giorni di fornitura | RxNorm (e RxNorm Extension per farmaci non statunitensi) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Procedure eseguite | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Risultati di laboratorio e segni vitali con valore, unità, intervallo | LOINC, con unità UCUM | Observation (laboratorio, segni vitali) |
| observation | Altri fatti clinici: storia, sociale, punteggi | SNOMED CT, LOINC | Observation (altro), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Dispositivi utilizzati | SNOMED CT | DeviceUseStatement, Procedure |
| death | Data e causa | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Note cliniche e termini estratti da NLP | — | DocumentReference, DiagnosticReport |
| specimen | Campioni | SNOMED CT | Specimen |
| provider, care_site, location | Medici, strutture, luoghi | Concetti di specializzazione | Practitioner, Organization, Location |
| cost, payer_plan_period | Costi e copertura | — | Coverage, Claim (ove disponibile) |
La versione 5.4 è quella utilizzata dalla maggior parte dei siti; la versione 6 esiste ma non è stata ampiamente adottata, e lo sviluppo continua sulla linea 5.x.
I vocabolari
I vocabolari standardizzati OMOP, distribuiti da OHDSI tramite Athena, caricano più di cento sistemi di codifica (SNOMED CT, LOINC, RxNorm, ICD-10, ATC e altri) nelle tabelle concept, concept_relationship e concept_ancestor. Ogni codice diventa un concept_id, standard o mappato a uno standard, quindi le analisi vengono scritte una sola volta mentre il codice sorgente originale viene preservato.
La seconda metà di OMOP è Athena, la distribuzione dei vocabolari di OHDSI: più di cento sistemi di codifica (SNOMED CT, LOINC, RxNorm, ICD-10 e varianti nazionali, ATC, CPT, Read e molti altri) caricati nelle tabelle concept, concept_relationship, concept_ancestor. Ogni codice diventa un concept_id; ogni concetto è standard (quello utilizzato nelle analisi), non standard (un codice sorgente che mappa a uno standard) o una classificazione. L'ETL memorizza sia il concetto sorgente (ciò che diceva il record: ICD-10 E11.9) sia il concetto standard (SNOMED 44054006), in modo che le analisi siano scritte una volta contro i concetti standard mentre l'originale viene preservato. La tabella concept_ancestor consente a una coorte di richiedere "qualsiasi tipo di diabete" con un solo join. Vedere SNOMED CT vs ICD-10 per capire perché lo standard per le condizioni è SNOMED CT.
L'ETL
L'ETL OMOP è il lavoro di conversione di un database sorgente nel modello dati comune, supportato dagli strumenti OHDSI: WhiteRabbit profila la sorgente, Rabbit-in-a-Hat documenta la mappatura delle tabelle, Usagi mappa i codici locali ai concetti standard, il Data Quality Dashboard controlla il risultato rispetto a migliaia di regole e ACHILLES caratterizza il database completato.
Convertire una sorgente in OMOP è il lavoro principale. Gli strumenti di OHDSI aiutano: WhiteRabbit scansiona la sorgente e la profila; Rabbit-in-a-Hat documenta la mappatura dalle tabelle sorgente alle tabelle CDM; Usagi aiuta a mappare i codici locali ai concetti standard; il Data Quality Dashboard controlla il risultato rispetto a migliaia di regole; ACHILLES caratterizza il database. Decisioni tipiche: come vengono definite le visite, come i record dei farmaci diventano esposizioni con giorni di fornitura, come vengono normalizzate le unità, cosa fare con i codici che non hanno una mappatura standard e come gestire gli aggiornamenti (ricarica completa vs incrementale).
Analisi attraverso la rete
L'analisi attraverso la rete OHDSI funziona scrivendo uno studio una volta e eseguendolo ovunque: i ricercatori definiscono coorti in ATLAS, eseguono stime e previsioni con i pacchetti R HADES, e impacchettano l'analisi come codice che ogni sito esegue localmente sul proprio database OMOP, condividendo solo risultati aggregati. DARWIN EU e EHDEN seguono questo modello.
ATLAS è lo strumento web dove i ricercatori costruiscono definizioni di coorte (persone con condizione X, esposte al farmaco Y, entro finestre temporali), le caratterizzano ed eseguono studi di stima e previsione con i pacchetti R HADES (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries). Uno studio di rete impacchetta l'analisi come codice; ogni sito lo esegue localmente sul proprio database OMOP e condivide i risultati aggregati; nessuno aggrega dati a livello di record. È così che la community OHDSI ha prodotto rapidamente grandi studi multinazionali durante la pandemia, ed è il modello alla base della rete DARWIN EU dell'EMA e del progetto EHDEN, che ha convertito più di cento database europei in OMOP.
Da FHIR a OMOP
FHIR viene mappato a OMOP a due livelli: risorse a tabelle ed elementi a colonne, con i codici FHIR tradotti attraverso i vocabolari OMOP in concetti standard. La guida all'implementazione da FHIR a OMOP di HL7 e il gruppo di lavoro FHIR di OHDSI pubblicano le mappature; diverse piattaforme eseguono l'ETL direttamente da un server FHIR o da un'esportazione di dati in blocco.
FHIR e OMOP rispondono a esigenze diverse: FHIR scambia il record di un singolo paziente tra sistemi con dettagli completi; OMOP appiattisce i record di molti pazienti per analisi statistiche. La mappatura è naturale a livello di risorsa (tabella sopra) e dettagliata a livello di elemento: i codici FHIR vengono mappati attraverso i vocabolari OMOP a concetti standard; Observation.valueQuantity diventa measurement value_as_number con unit_concept_id; Encounter.class diventa visit_concept_id. La guida all'implementazione FHIR to OMOP di HL7 (attraverso l'acceleratore Vulcan) e il gruppo di lavoro FHIR di OHDSI pubblicano le mappature e le implementazioni di riferimento; diverse piattaforme eseguono l'ETL direttamente da un server FHIR o da un'esportazione Bulk Data. Rimangono ambiguità dove FHIR è più ricco (codifiche multiple, stati, provenienza) o dove OMOP necessita di ciò che FHIR non ha (giorni di fornitura, periodi di osservazione).
Cosa non è OMOP
OMOP non è un formato per la cura e non è anonimo di per sé: elimina le narrazioni, appiattisce gli stati e non contiene consensi, provenienza o flusso di lavoro, quindi FHIR rimane il formato di scambio, e un database OMOP contiene ancora dati a livello di record che devono essere gestiti come qualsiasi database sanitario, solitamente con ID persona pseudonimizzati all'interno di un ambiente sicuro.
Non è un formato per la cura: elimina la narrativa, appiattisce gli stati e non trasporta consenso, provenienza o flusso di lavoro. Non è anonimo di per sé: un database OMOP contiene dati a livello di record e viene governato come qualsiasi database sanitario, solitamente con identificatori pseudonimizzati e in ambienti sicuri. Vedere Uso secondario dei dati sanitari e De-identificazione dei dati sanitari.
In Anpheros
I record Anpheros sono FHIR R4 con codici standard (LOINC, SNOMED CT, ATC, ICD-10), che è l'input desiderato da un ETL OMOP; con il consenso del paziente per uno scopo di ricerca, estratti FHIR pseudonimizzati possono alimentare l'ETL di una piattaforma di ricerca. Anpheros stesso calcola solo segnali aggregati della popolazione su gruppi di 20 o più e non gestisce un database OMOP su dati identificati.
Pagine correlate
- Uso secondario dei dati sanitari: la mappa
- SNOMED CT vs ICD-10
- De-identificazione dei dati sanitari
- Esportazione FHIR Bulk Data spiegata
- Server di terminologia spiegati
- RxNorm vs ATC
Fonti
- OHDSI: OMOP Common Data Model
- OHDSI: The Book of OHDSI
- OHDSI Athena: vocabolari standardizzati
- OHDSI: ATLAS
- HL7 Vulcan: guida all'implementazione FHIR to OMOP
- Progetto EHDEN
- EMA: DARWIN EU
Domande frequenti
OMOP è un sostituto di FHIR?
No. FHIR scambia il record dettagliato di un singolo paziente tra sistemi; OMOP struttura molti record per analisi statistiche. Le piattaforme di ricerca accettano FHIR (o altre sorgenti) in ingresso e producono OMOP.
Quale versione di OMOP dovrei usare?
5.4 è la versione ampiamente distribuita con supporto completo degli strumenti; la maggior parte delle nuove conversioni la prende di mira. La versione 6 ha introdotto modifiche che la community non ha adottato ampiamente.
Perché OMOP mappa i codici ICD a SNOMED CT?
In modo che le analisi possano essere scritte una volta contro un singolo vocabolario standard gerarchico per le condizioni, indipendentemente dal fatto che la sorgente abbia utilizzato codici ICD-10, ICD-10-CM, ICD-9-CM o Read. Il codice sorgente viene conservato a fianco.
Un database OMOP è anonimo?
Non di per sé. Contiene dati a livello di record, solitamente con identificatori pseudonimizzati e senza identificatori diretti, e deve essere protetto e governato come qualsiasi database sanitario, tipicamente all'interno di un ambiente sicuro.
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 →