Articolo
AgenticHealth
AI on-premise per la ricerca clinica: ricerca con le fonti, bozze di studio e di qualità, oscuramento dei dati. Non è un software medicale: non supporta diagnosi né decisioni sulla cura dei pazienti.
Scopri AgenticHealth →
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 →Il ponte tra terminologie
Le grandi terminologie cliniche — SNOMED CT, LOINC, RxNorm, ICD, ATC, MedDRA, HCPCS, NDC, CVX — hanno governance, licenze, aggiornamenti e semantiche indipendenti. Chi vuole fare analisi di dati sanitari attraversando più sorgenti — un ospedale che usa ICD-10-CM, un database di ricerca su SNOMED CT, un registro farmaceutico su ATC e un sistema clinico americano su RxNorm — si trova davanti al problema di armonizzare terminologie eterogenee in una vista comune.
La comunità OHDSI — Observational Health Data Sciences and Informatics, iniziativa collaborativa internazionale che dal 2014 mantiene l’OMOP Common Data Model nato nel 2008 sotto il Observational Medical Outcomes Partnership della FDA — ha costruito una risposta pragmatica a questo problema: le OMOP Standardized Vocabularies.
Un’unica tabella Concept
Il cuore delle Standardized Vocabularies è una singola tabella relazionale: CONCEPT, che contiene — nella release attuale — oltre cinque milioni di concetti provenienti da decine di terminologie. Ogni riga rappresenta un concetto con:
- concept_id — identificativo intero globale all’interno dell’intero universo OHDSI
- concept_name — nome preferito in inglese
- domain_id — dominio (Condition, Drug, Procedure, Measurement, Observation, Device, Visit)
- vocabulary_id — terminologia di origine (
SNOMED,LOINC,RxNorm,ICD10CM,ICD9CM,ATC,HCPCS,MedDRA,CVX, …) - concept_class_id — classe all’interno del vocabolario (p. es.
Clinical Findingper SNOMED CT) - concept_code — codice originale della terminologia di provenienza (SCTID, codice LOINC, codice ICD, …)
- standard_concept — flag che indica se il concetto è Standard (
S), Classification (C) o non-standard (NULL) - valid_start_date / valid_end_date — validità temporale del concetto
Due tabelle complementari completano il modello:
- CONCEPT_RELATIONSHIP — relazioni tra concetti all’interno della stessa terminologia o tra terminologie diverse (Maps to, Is a, Has RxNorm, Has ATC)
- CONCEPT_ANCESTOR — chiusura transitiva delle relazioni gerarchiche IS-A, per interrogazioni su sottoclassi
La chiusura transitiva precalcolata è un’ottimizzazione centrale: interrogare “tutti i diabetici” significa unire i concept_id dei discendenti di un concetto radice, con un semplice JOIN su CONCEPT_ANCESTOR.
Source e standard
Il meccanismo operativo del vocabolario OMOP ruota attorno a una distinzione fondamentale:
- Un source concept è un codice così com’è nel sistema d’origine — per esempio un codice ICD-10-CM italiano, un LOINC di laboratorio locale, un codice interno di un LIS
- Uno standard concept è il concetto canonico scelto da OHDSI per rappresentare lo stesso significato nell’ecosistema OMOP, tipicamente preso da una terminologia “target” per ciascun dominio
Le scelte di standard per dominio — visibili nei ruoli di progettazione OHDSI — seguono una logica pragmatica:
- Condition — SNOMED CT come standard, con mapping da ICD-9-CM, ICD-10-CM, ICD-10, Read, MedDRA
- Drug — RxNorm come standard, con mapping da NDC, ATC, nomi commerciali
- Measurement — LOINC come standard
- Procedure — SNOMED CT + HCPCS/CPT4 + ICD-10-PCS
- Device — SNOMED CT
Il risultato pratico: a ogni codice sorgente è associato via CONCEPT_RELATIONSHIP un Maps to verso il concetto standard corrispondente. Un laboratorio che riceve dati da sistemi eterogenei li carica sui source concept, e OMOP li proietta automaticamente sui concetti standard per l’analisi.
Athena
Il vocabolario è distribuito attraverso Athena — athena.ohdsi.org — portale aperto di OHDSI. Chi implementa un CDR OMOP scarica da Athena i CSV delle tabelle (CONCEPT, CONCEPT_RELATIONSHIP, CONCEPT_ANCESTOR, CONCEPT_SYNONYM, VOCABULARY, DOMAIN, CONCEPT_CLASS, RELATIONSHIP, DRUG_STRENGTH) e li importa nel proprio database.
Athena è anche un browser web: l’utente può cercare “hypertension”, “metformin”, “serum sodium” e vedere il concetto standard di riferimento, i mapping provenienti dalle varie terminologie, la gerarchia dei discendenti.
Le restrizioni di licenza si riflettono nel download: SNOMED CT è distribuito soltanto agli utenti autenticati appartenenti a Paesi membri di SNOMED International (o con licenza individuale valida), CPT-4 richiede licenza AMA, ICD-10-CM e RxNorm sono liberamente distribuiti. L’importazione in un CDR produttivo deve tenere conto di queste restrizioni — per l’Italia, il cui status formale in SNOMED International al 2017 non prevede l’adesione nazionale, l’accesso a SNOMED CT in OMOP deve essere valutato caso per caso.
Usagi: il mapping dei codici locali
Qualunque cartella clinica reale contiene codici locali — diagnosi digitate, codici di reparto, codici di esami interni — non presenti nelle Standardized Vocabularies. Il lavoro di mapping da codici locali a concetti OMOP è uno dei compiti ricorrenti di chi carica dati in un CDR OMOP.
Lo strumento dedicato è Usagi — applicazione Java Open Source distribuita da OHDSI — che:
- Importa un CSV di codici locali con descrizione
- Per ognuno propone candidati match nelle Standardized Vocabularies, classificati secondo una metrica di similarità testuale
- Consente al mapper (idealmente un clinico o un data manager con formazione medica) di accettare, modificare o rifiutare il match
- Produce un file di mapping importabile come source concept nel database OMOP
Un mapping ben fatto è il lavoro più tempo-intensivo dell’implementazione di un CDR OMOP, ma è anche l’asset che rende i dati analizzabili nelle query condivise della comunità OHDSI.
Rapporto con FHIR
Il modello delle Standardized Vocabularies e il modello delle FHIR terminology resource (CodeSystem, ValueSet, ConceptMap) rispondono a esigenze diverse:
- FHIR espone ogni CodeSystem nel suo formato nativo, con il suo identificativo canonico, e lascia a chi interroga il compito di combinare più CodeSystem. Una
ValueSetpuò includere codici di più CodeSystem ma la loro integrazione semantica è lasciata a chi costruisce la ValueSet - OMOP prescrive una scelta esplicita di terminologia standard per dominio e pre-calcola le relazioni tra terminologie. Il prezzo è una strutturazione rigida; il beneficio è l’immediatezza dell’analisi cross-sorgente
I due modelli non sono alternativi e in pratica convivono: FHIR è il formato di scambio, OMOP è il modello dati osservazionale. Un workflow sempre più comune è: acquisizione via FHIR API, trasformazione ETL verso OMOP CDM, analisi via OHDSI Tools.
Nel panorama italiano
L’adozione di OMOP CDM in Italia al 2017 è ancora limitata ad ambienti di ricerca e a qualche progetto strutturato su dati amministrativi. Il mapping delle terminologie nazionali italiane — ICD-9-CM italiana, ATC, AIC — verso le Standardized Vocabularies è un lavoro ancora frammentario, condotto in contesti specifici (registri di patologia, studi osservazionali di farmacovigilanza). Il vincolo maggiore resta l’accesso a SNOMED CT: senza adesione italiana a SNOMED International, la componente Condition di OMOP può essere soltanto parzialmente valorizzata.
La crescita della domanda di real-world evidence da parte di EMA, AIFA e network di ricerca clinica sta però spingendo il tema. L’avvio di programmi europei dedicati — il più rilevante, in fase di definizione, è un’iniziativa IMI (Innovative Medicines Initiative) per la costruzione di una rete europea di database clinici mappati a OMOP — è atteso per i prossimi mesi.
Riferimenti: OHDSI — OMOP Common Data Model v5.x. OMOP Standardized Vocabularies, distribuiti via Athena (athena.ohdsi.org). Usagi — OHDSI Code Mapping Tool. SNOMED International, Regenstrief Institute (LOINC), US National Library of Medicine (RxNorm).