OMOP Common Data Model: OHDSI, EHDEN e la real-world evidence europea

AIHealth

Piattaforma clinica on-premise con LLM locali, RAG su dati FHIR/DICOM, supporto alla diagnosi, follow-up remoto. Architettura progettata per il percorso MDR.

Scopri AIHealth →

Digital Health

Sviluppo di software medicale conforme agli standard normativi CE e MDR. Sistemi di supporto alle decisioni cliniche, integrazione AI nei flussi di lavoro clinici.

Scopri →

Un modello dati per la ricerca osservazionale

Gli standard di scambio — HL7 v2, CDA R2, FHIR — trasportano dati clinici tra sistemi in tempo reale o quasi. Per l’analisi osservazionale su popolazioni — studi epidemiologici, valutazioni di sicurezza ed efficacia dei farmaci nel mondo reale, ricerche su esiti di cura — serve un’altra cosa: un modello dati strutturato, orientato all’analisi, in cui database clinici eterogenei per origine e formato siano armonizzati secondo regole condivise.

Questo è il ruolo del OMOP Common Data Model — Observational Medical Outcomes Partnership. Nato nel 2008 all’interno della Foundation for the National Institutes of Health (FNIH) come partnership tra FDA, industria farmaceutica e accademia, il CDM è passato nel 2014 alla comunità internazionale OHDSI — Observational Health Data Sciences and Informatics — che da allora lo mantiene e lo evolve. Al 2019 la versione di riferimento è OMOP CDM v5.3, con oltre cento database nel mondo dichiarati conformi — studi ospedalieri, registri di patologia, claims assicurativi, database di medicina generale.

La struttura del CDM

OMOP CDM è un insieme di tabelle relazionali con regole di popolamento ben definite. Le tabelle principali di tipo event:

• PERSON — l’individuo con attributi demografici (anno/mese/giorno di nascita, sesso, razza, etnia) e identificativo pseudonimizzato
• OBSERVATION_PERIOD — intervalli durante i quali una persona era osservabile nel sistema (equivalente a enrollment in un’assicurazione, o alla presenza nel catchment di un HIS)
• VISIT_OCCURRENCE — ricoveri, visite ambulatoriali, accessi in PS
• CONDITION_OCCURRENCE — diagnosi e problemi, codificati con concept_id standard (tipicamente SNOMED CT)
• DRUG_EXPOSURE — esposizione a farmaci (prescrizioni, somministrazioni), standard RxNorm
• PROCEDURE_OCCURRENCE — procedure eseguite, standard SNOMED CT + HCPCS/CPT4
• MEASUREMENT — valori numerici di laboratorio, vital signs, antropometrie, standard LOINC
• OBSERVATION — altre osservazioni cliniche non numeriche (storia familiare, abitudini, risultati qualitativi)
• DEATH — data e causa del decesso
• DEVICE_EXPOSURE, NOTE, SPECIMEN, FACT_RELATIONSHIP

Tabelle di tipo demografico e amministrativo: LOCATION, CARE_SITE, PROVIDER, PAYER_PLAN_PERIOD, COST.

A queste si affiancano le Standardized Vocabularies (CONCEPT, CONCEPT_RELATIONSHIP, CONCEPT_ANCESTOR) distribuite da Athena, che armonizzano SNOMED CT, LOINC, RxNorm, ICD, ATC e decine di altri vocabolari in un unico spazio di concept_id.

ETL: dal dato locale al CDM

Portare un database clinico in OMOP richiede un processo di ETL strutturato:

• Specificazione dell’ETL — documento che descrive sorgenti, trasformazioni, assunzioni. Tipicamente prodotto in stretta collaborazione tra data manager del centro e clinici
• Mapping delle terminologie — da codici locali (diagnosi testuali, codici di reparto, codici interni di laboratorio) a concept_id standard; è la parte più tempo-intensiva, supportata da Usagi
• Conversione dei dati — script SQL/Python che popolano le tabelle OMOP a partire dalle sorgenti. Gli script ETL OHDSI sono tipicamente open-sourcecati dai centri che li producono
• Controlli di qualità — verifica dell’integrità referenziale, distribuzioni statistiche coerenti, concept_id validi
• Report di qualità — eseguiti con Achilles, che produce centinaia di indicatori pronti per l’ispezione

Un ETL per un database di medie dimensioni è un lavoro di alcuni mesi-persona. La documentazione dello specifico ETL è essa stessa un output di valore: permette a chi interroga il dataset di capire cosa c’è e cosa manca.

L’ecosistema di strumenti

OHDSI distribuisce una pila open source completa per l’analisi su OMOP:

• ATLAS — web application per la definizione di coorti, la caratterizzazione di popolazioni, l’esecuzione di analisi standard. Interfaccia grafica che genera SQL eseguibile contro il CDM, utilizzabile senza programmazione
• WebAPI — il backend REST di ATLAS, che espone servizi su un CDR OMOP
• HADES — Health Analytics Data-to-Evidence Suite, un insieme di pacchetti R per analisi sofisticate: CohortMethod per comparazioni tra trattamenti con matching su propensione, PatientLevelPrediction per modelli predittivi, SelfControlledCaseSeries, SelfControlledCohort, IncidenceRate, Eunomia (dataset didattico)
• Achilles — pacchetto R per la valutazione della qualità dei dati in un CDM, produce un report esplorabile con centinaia di metriche
• Broadsea — stack Docker che bundle ATLAS, WebAPI, HADES, PostgreSQL e strumenti correlati in un setup pronto all’uso per sviluppo e didattica

Gli studi OHDSI sono tipicamente reproducibili e federati: un ricercatore scrive un protocollo e gli script R; ciascun centro partner li esegue sul proprio CDM; le statistiche aggregate — mai i dati individuali — vengono raccolte e combinate. Il dato del paziente non esce mai dal centro di origine.

Gli studi federati

L’aspetto federato è il valore di OHDSI: permette di rispondere a domande osservazionali su centinaia di milioni di record senza concentrare i dati. Studi multi-centrici pubblicati negli anni recenti hanno coinvolto decine di database con complessivi oltre 500 milioni di pazienti, producendo evidenza che singoli dataset non potrebbero sostenere:

• Valutazioni di sicurezza di farmaci post-commercializzazione
• Analisi di pattern di prescrizione in popolazioni molto eterogenee
• Studi comparativi di efficacia tra strategie terapeutiche alternative
• Pattern clinici di malattie rare su popolazioni aggregate

Il modello federato è esplicitamente compatibile con i requisiti GDPR di minimizzazione e con la normativa sanitaria europea, perché i dati individuali restano localmente e solo aggregati possono uscire.

EHDEN: l’Europa su OMOP

Nel novembre 2018, l’Innovative Medicines Initiative — partnership pubblico-privata tra Commissione Europea ed EFPIA (Federazione europea dell’industria farmaceutica) — ha lanciato il progetto EHDEN (European Health Data & Evidence Network): un programma quinquennale con budget di circa 34 milioni di euro, con l’obiettivo dichiarato di portare 100+ database sanitari europei su OMOP CDM, costruendo una rete federata per la generazione di real-world evidence.

Il coordinamento tecnico è affidato a Erasmus MC (Rotterdam) con Peter Rijnbeek; il coordinamento industriale a Janssen Pharmaceutica. I partner di progetto includono università, centri di ricerca e ospedali di diversi Paesi europei.

Le componenti del programma:

• EHDEN Academy — piattaforma di formazione online gratuita su OMOP CDM, ETL, Standardized Vocabularies, strumenti OHDSI
• Certificazione SME — qualifica di società di servizi capaci di supportare i centri sanitari nel processo di ETL verso OMOP, con un processo di esame basato sull’Academy
• Calls for Data Partners — bandi competitivi che finanziano i centri sanitari per la conversione del proprio database in OMOP CDM, con accompagnamento da parte di SME certificate
• Portale dati — catalogo federato dei database partner, con descrittori standardizzati

A un anno dall’avvio, EHDEN ha completato le prime wave di call for data partners, con una quarantina di centri europei già in onboarding. La traiettoria — 100+ database entro il 2024 — è credibile e si innesta su una domanda crescente di real-world evidence da parte di EMA e delle agenzie nazionali.

OMOP vs altri Common Data Model

OMOP non è l’unico CDM in uso nel panorama internazionale:

• Sentinel CDM — modello della FDA utilizzato nel Sentinel System per la sorveglianza di sicurezza dei farmaci post-commercializzazione. Concettualmente simile a OMOP, strutturalmente distinto
• PCORnet CDM — modello del Patient-Centered Outcomes Research Network negli USA, orientato alla ricerca comparativa
• i2b2 — Informatics for Integrating Biology and the Bedside, Harvard Partners HealthCare; schema star con observation_fact centrale, molto flessibile. Ampiamente adottato in contesti accademici europei
• OpenEHR — non è un CDM in senso stretto ma un modello di persistenza nativo; alcuni progetti mappano openEHR a OMOP per l’analitica

L’interoperabilità tra CDM diversi è un tema di ricerca attivo. La comunità OMOP offre mapper documentati verso/da Sentinel e PCORnet; l’ecosistema i2b2 include estensioni che emettono OMOP a partire da osservazioni i2b2.

OMOP vs FHIR

La distinzione tra OMOP e FHIR è spesso fraintesa, perché entrambi trattano dati sanitari strutturati. Ma rispondono a esigenze ortogonali:

• FHIR è uno standard di scambio — come trasportare un’Observation dal sistema A al sistema B via REST in modo interoperabile. È orientato a transazioni, a consultazioni, a integrazioni applicative
• OMOP è un modello dati analitico — come strutturare in tabelle relazionali milioni di record osservazionali eterogenei per analisi statistiche longitudinali

In pratica, FHIR e OMOP si integrano: un CDR OMOP può esporre le sue risorse via API FHIR per consultazione; un flusso FHIR può essere trasformato via ETL verso OMOP per analisi. Strumenti come FHIR-to-OMOP e OMOP-on-FHIR (Georgia Tech) implementano questa traduzione.

In Italia

Al 2019 l’adozione di OMOP CDM in Italia è limitata a casi specifici: centri di ricerca oncologica, studi di farmacoutilizzazione, progetti AIFA su banche dati di prescrizioni. Nessun ospedale o sistema FSE italiano ha ancora un CDM OMOP produttivo. Le call di EHDEN stanno attirando interesse e alcuni centri italiani sono in fase di valutazione per onboarding.

La traiettoria — spinta da EMA, dalle novità regolatorie sul secondary use che arriveranno nei prossimi anni in Europa, dall’espansione di EHDEN — suggerisce che OMOP occuperà uno spazio sempre più importante nel lavoro di trasformazione dei dati sanitari italiani in evidenza clinica e regolatoria.

Riferimenti: OHDSI — OMOP Common Data Model v5.3 (ohdsi.org). OHDSI Tools: ATLAS, WebAPI, HADES, Achilles, Broadsea. OMOP Standardized Vocabularies (Athena). IMI EHDEN — European Health Data & Evidence Network (ehden.eu), avviato novembre 2018. Erasmus MC (coordinatore). EHDEN Academy.