analisi comparata di due ontologie in ambito biomedico
Transcript
analisi comparata di due ontologie in ambito biomedico
UNIVERSITÀ POLITECNICA DELLE MARCHE FACOLTÀ DI INGEGNERIA Corso di Laurea Specialistica in Ingegneria Informatica ANALISI COMPARATA DI DUE ONTOLOGIE IN AMBITO BIOMEDICO: SNOMED CT E ROME Tesi di laurea di: Relatore: Chiar.mo Marta Gentile Prof. Aldo Franco Dragoni Correlatori: Ing. Mauro Mazzieri Ing. Germano Vallesi Anno Accademico 2009/2010 I computer sono incredibilmente veloci, accurati e stupidi. Gli uomini sono incredibilmente lenti, inaccurati e intelligenti. Insieme sono una potenza che supera l'immaginazione Albert Einstein Abstract Il settore sanitario attualmente presenta dei problemi d'interoperabilità, che possono essere risolti dalle ontologie. In questa tesi vengonno illustrati i risultati di un'analisi comparata tra due ontologie in ambito biomedico: SNOMED CT (la realtà attualmente più diusa a livello internazionale) e ROME (alternativa italiana sviluppata dal CNR). Gli aspetti chiave del confronto spaziano dalla diusione e accettazione a livello internazionale, alla correttezza dell'ontologia, per giungere all'individuazione dell'espressività e valutazione della complessità computazionale delle due. L'obiettivo nale è ottenere un chiaro quadro della situazione attuale, delle alternative esistenti più signicative per l'Italia, per capire verso quale direzione sia meglio dirigersi nei prossimi anni. Contents 1 Introduzione 1.1 1.2 1.3 Ontologie 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1 Denizioni . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.2 Classicazioni . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.3 Vantaggi e applicazioni . . . . . . . . . . . . . . . . . . 6 OWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.1 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2.2 Sottolinguaggi . . . . . . . . . . . . . . . . . . . . . . . 10 1.2.3 OWL2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 . . . . . . . . . . . . . . . . . . . . . . . . 12 1.3.1 Logiche descrittive Denizione del formalismo di base . . . . . . . . . . . . 13 1.3.2 Description languages . . . . . . . . . . . . . . . . . . . 13 1.3.3 La famiglia dei linguaggi . . . . . . . . . . . . . . 14 1.3.4 Terminologia-TBox . . . . . . . . . . . . . . . . . . . . 15 1.3.5 Descrizione del mondo-ABox . . . . . . . . . . . . . . . 16 1.3.6 Inferenza . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3.7 Estensioni del linguaggio . . . . . . . . . . . . . . . . . 18 AL 2 SNOMED CT 19 2.1 Panoramica 2.2 Storia 2.3 Componenti base 2.4 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Utilizzi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4.1 Concetti . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4.2 Descrizioni . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.3 Relationships . . . . . . . . . . . . . . . . . . . . . . . 33 Nazionalizzazione . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.5.1 Introduzione ai principi terminologici . . . . . . . . . . 43 2.5.2 Tradurre SNOMED CT . . . . . . . . . . . . . . . . . 45 2.5.3 Sorgenti di informazione . . . . . . . . . . . . . . . . . 52 2.5.4 Processo di traduzione e problemi del post-traduzione . 53 1 2.5.5 2.6 Esperienze di alcuni release centre translating . . . . Considerazioni sulla struttura e tecnologia di SNOMED CT 57 2.6.1 Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.6.2 History Mechanism . . . . . . . . . . . . . . . . . . . . 59 2.6.3 Subset Mechanism 60 2.6.4 Cross Mapping Mechanism . . . . . . . . . . . . . . . . 60 2.6.5 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.6.6 Applicazioni e servizi SNOMED CT . . . . . . . . . . . 61 . . . . . . . . . . . . . . . . . . . . 3 ROME 3.1 3.2 3.3 63 Panoramica . . . . . . . . . . . . . . . . . . . . . . . . . . . . Componenti base . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 4.3 63 65 3.2.1 Entità principali . . . . . . . . . . . . . . . . . . . . . 68 3.2.2 Entità materiali e immateriali . . . . . . . . . . . . . . 75 3.2.3 Object properties . . . . . . . . . . . . . . . . . . . . . 77 Utilizzi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4 Analisi 4.1 55 . 79 Correttezza dell'ontologia . . . . . . . . . . . . . . . . . . . . 79 4.1.1 ROME . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.1.2 SNOMED CT . . . . . . . . . . . . . . . . . . . . . . . Espressività 84 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.2.1 ROME . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.2.2 SNOMED CT . . . . . . . . . . . . . . . . . . . . . . . 103 4.2.3 Confronto . . . . . . . . . . . . . . . . . . . . . . . . . 104 Complessità computazionale . . . . . . . . . . . . . . . . . . . 106 4.3.1 Cenni sulle classi di complessità . . . . . . . . . . . . . 106 4.3.2 ROME . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 4.3.3 SNOMED CT . . . . . . . . . . . . . . . . . . . . . . . 109 4.3.4 Confronto . . . . . . . . . . . . . . . . . . . . . . . . . 110 5 Conclusioni 111 2 Chapter 1 Introduzione Il problema della condivisione della conoscenza è sempre stato, nella storia dell'uomo, di fondamentale importanza per lo sviluppo della società. Tale problema al giorno d'oggi è ancora più visibile nel settore sanitario, il quale è aitto da un problema di comunicazione: clinici e organizzazioni utilizzano spesso diversi termini clinici che signicano la stessa cosa (ad esempio infarto del miocardio e infarto miocardico). Perciò ogni qualvolta si presenti la necessità di inserire i dati medici in diversi database, sorgono inevitabili problemi di integrazione che andrebbero risolti caso per caso. Una prima soluzione a tale problema potrebbe essere l'adozione di un sistema di codici accettato e vericato a livello internazionale, una sorta di grande vocabolario a cui tutti possano fare riferimento e che permetta lo scambio di informazioni indipendentemente dalla lingua in cui le informazioni stesse sono originariamente espresse. Un codice standardizzato della medicina è stato paragonato alla necessità di unità di misura omogenee per le scienze siche. In realtà questo risolve solo in parte il problema: vi è la necessità di rappresentare tali informazioni in modo che siano comprensibili e processabili anche dalle macchine, passando dunque dalla descrizione dei dati a quella della conoscenza. Servono quindi le ontologie. In questo capitolo verranno introdotte le nozioni fondamentali di argomenti quali le ontologie, OWL e le logiche descrittive, utili per la comprensione dei prossimi capitoli. 3 1.1 Ontologie 1.1 4 Ontologie 1.1.1 Denizioni Il termine ontologia è preso in prestito dalla losoa: l'ontologia come branca della losoa è la scienza di ciò che vi è, dei tipi e strutture di oggetti, proprietà, eventi, processi e relazioni in ogni settore della realtà(Barry Smith). In informatica, un'ontologia è una disciplina descrittiva o realista che non cerca una spiegazione, bensì una descrizione della realtà classicando tutti i tipi di entità, comprese le relazioni con cui esse sono collegate tra di loro. Fornisce dunque una rappresentazione formale, condivisa ed esplicita di una concettualizzazione di un dominio di interesse. Il termine ontologia è entrato in uso nel campo dell'intelligenza articiale e della rappresentazione della conoscenza, per descrivere il modo in cui diversi schemi vengono combinati in una struttura dati contenente tutte le entità rilevanti e le loro relazioni in un dominio. In tal caso un'ontologia è una: • Specicazione di una concettualizzazione (Gruber), nel contesto della conoscenza e della condivisione di dati; • Un insieme di assiomi logici progettati per descrivere il signicato inteso di un vocabolario(Guarino); • Il soggetto dell'ontologia è lo studio delle categorie delle cose che esistono o possono esistere in qualche dominio. Il prodotto di tale studio, chiamato una ontologia, è un catalogo dei tipi di cose, che si assume esistano in un dominio di interesse D, dalla prospettiva di una persona che usa un linguaggio L allo scopo di parlare di D( Sowa). Per essere utilizzabili, le ontologie devono essere espresse in una notazione concreta. Un linguaggio per ontologie è un linguaggio formale con cui viene costruita un'ontologia. Esistono diversi linguaggi, proprietari o basati su standard, per la denizione di ontologie: OWL rappresenta l'attuale standard per ontologie in ambienti web. Nel dominio sanitario si parla di ontologie biomediche: esse sono con- centrate sulla denizione delle classi biologiche principali e delle relazioni tra loro. Le ontologie in medicina diventano l'infrastrutture di base per garantire l' interoperabilità semantica. I sistemi di informazione medica devono essere capaci di comunicare complessi e dettagliati concetti medici (possibilmente espressi in dierenti linguaggi) in modo non ambiguo. 1.1.2 Classicazioni 1.1.2 5 Classicazioni Una delle possibili classicazioni delle ontologie è svolta in base al dominio che rappresentano o al livello di dettaglio che forniscono. Vi sono dunque le: • Top-level ontologies (o general o foundational ontologies): considerano gli aspetti più generici e astratti ravvisabili nella realtà intesa nella sua completezza. Considerano i concetti generali come oggetto, processo, tempo, comuni a diversi domini; • Domain ontologies: incentrate su uno specico contesto. Si occupano dell'analisi categoriale e relazionale che si specica in una peculiare porzione di realtà; • Application ontologies: ontologie progettate per uno specico task; • Reference ontologies: strato intermedio tra le ontologie top-level e le ontologie di dominio. Sono sviluppate indipendentemente da un particolare scopo e servono come moduli condivisibili tra domini. Tecnicamente sono ontologie di dominio, in quanto si riferiscono ad un contesto ben denito, come il diritto, l'agricoltura o la medicina. Nonostante tutto possono essere viste come top level per quanto riguarda il dominio a cui si rivolgono. Una seconda classicazione invece distingue tra: • Ontologie leggere: sono semplici strutture tassonomiche di termini primitivi o compositi con le relative denizioni. Lo scopo è denire i concetti impiegati in un determinato dominio o in una certa comunità d'uso. Il ruolo di queste ontologie è più quello di sostenere i servizi terminologici • 1 piuttosto che spiegare o denire il loro signicato inteso. Ontologie assiomatiche: forniscono una assiomatizzazione logica rigorosa. Considerano non solo le relazioni tra i termini, ma soprattutto la formale struttura del dominio che deve essere rappresentato. Si presentano in forme diverse e possono avere diversi livelli di generalità, ma una particolare rilevanza è goduta delle cosiddette ontologie fondazionali: esse utilizzano un linguaggio formale molto espressivo, sono utilizzate come ponte tra le concettualizzazioni alternative e come traduttori del signicato inteso nei diversi ambienti, grazie alla possibilità che danno di denire una struttura terminologica trasversale alle comunità d'uso. 1 Inferenze sulla base di relazioni fra i termini 1.1.3 Vantaggi e applicazioni 6 Le ontologie leggere svologno un ruolo complementare a quello delle ontologie assiomatiche: le prime possono essere costruite semi-automaticamente, ad esempio sfruttando tecniche di machine learning; le seconde invece richiedono un più faticoso lavoro umano, che può trarre beneci immensi dai risultati e discipline come la losoa, la linguistica e le scienze cognitive. 1.1.3 Vantaggi e applicazioni I vantaggi delle ontologie in ambito informatico possono essere riassunti in due punti principali: • Possibilità di eettuare elaborazioni software avanzate: ragionamento automatico, classicazione e svariate tecniche per la risoluzione di problemi; • Facilitare lo scambio di informazioni fra diversi sistemi Questi vantaggi sono ancora più evidenti nel caso delle ontologie biomediche: esse consentono infatti di costruire sistemi d'informazione sanitaria più potenti e interoperabili; di supportare la necessità di trasmissione dei processi sanitari, il riuso e la condivisione dei dati dei pazienti; di fornire criteri basati sulla semantica per supportare dierenti aggregazioni statistiche per diversi scopi e di supportare l'integrazione della conoscenza e dei dati. In sintesi i vantaggi si traducono in supporto all'intera pratica sanitaria per medici, infermieri, ausiliari e anche per i pazienti stessi, quindi in migliori cure e assistenza sanitaria. D'altro canto molti sono scettici sull'impatto che le ontologie possono avere sulla progettazione e il mantenimento dei sistemi di informazione sanitari del mondo reale. Tra i principali esempi di applicazioni delle ontologie in ambito sanitario si possono citare: • Le cartelle cliniche elettroniche: sono una versione elettronica delle cartelle cliniche cartacee; • I sistemi di supporto decisionale: rappresentano un supporto per l'assunzione di decisioni di tipo gestionale per i clinici. 1.2 OWL 1.2 7 OWL OWL (Ontology Web Language) è un linguaggio per descrivere le classi e le relazioni che le collegano inerenti ai documenti e alle applicazioni web. OWL è parte del Semantic Web Stack della W3C, come ragurato in Figura1.1: Figure 1.1: Semantic Web Stack della W3C • Alla base dello stack vi sono gli URI (Uniform Resource Identier), ossia stringhe che identicano univocamente risorse generiche (indirizzi web, documenti, immagini, les, servizi, indirizzi di posta elettronica). Gli URL (Uniform Resource Locator) sono un sottoinsieme degli URI: mediante URL si identicano risorse speciche della rete. L'Unicode è invece un sistema di codica che assegna un numero (o meglio, una combinazione di bit) a ogni carattere in maniera indipendente dal programma, dalla piattaforma o dalla lingua; • L' XML (eXtensible Markup Language) permette di esplicitare la struttura di un documento in modo formale mediante marcatori (mark-up), garantendo l' interoperabiltà sintattica; • L'RDF (Resource Description Framework) invece serve per descrivere relazioni semantiche tra risorse. In questo contesto, OWL è un linguaggio per l'aggiunta di un servizio inferenziale a RDF. 1.2.1 Struttura 1.2.1 8 Struttura Elementi base Una ontologia OWL inizia con due componenti iniziali standard: • Lo spazio dei nomi XML: è una collezione di nomi di entità usate in uno o più le sorgenti. Fornisce un mezzo per interpretare in maniera non ambigua gli identicatori e rendere il resto della presentazione dell'ontologia molto più leggibile. • L' intestazione dell'ontologia: è una collezione di aermazioni riguardanti l'ontologia. Segue le denizione delle classi. Un elenco riassuntivo degli elementi base di OWL è riportato di seguito: • Classi semplici e individui: molti usi di una ontologia dipendono dalla possibilità che orono di ragionare sugli individui. Per fare ciò in modo utile ed eciente serve un meccanismo per descrivere le classi a cui gli individui appartengono e le proprietà che essi ereditano in virtù dell'appartenenza alle classi stesse: l'insieme degli individui che sono membri di una classe vengono chiamati estensione di quella classe. Classi semplici con nome: le classi di uno specico dominio possono essere denite semplicemente dichiarandone il nome. Il costrutto OWL fondamentale per denire la tassonomia delle classi è rdfs:subClassOf. Esso mette in relazione una classe specica con una più generica. Individui: sono introdotti principalmente dichiarando la loro appartenenza ad una classe. • Proprietà semplici: le proprietà permettono di asserire fatti generali riguardo i membri delle classi e di asserire fatti specici riguardo gli individui. Vengono distinte in base a se mettono in relazione individui con individui (object properties) o individui con tipi di dati (datatype properties). È possibile specicare le caratteristiche di una proprietà allo scopo di fornire un meccanismo molto potente per agevolare ragionamenti sulle proprietà stesse. Tali caratteristiche permettono di distinguere tra: Proprietà transitive: se una proprietà P è specicata come transitiva, allora per ogni x, y e z si ha logicamente che: P(x,y) e P(y,z) implicano P(x,z); 1.2.1 Struttura 9 Proprietà simmetriche: se una proprietà P viene denita simmetrica, allora per ogni x e y si ha che: P(x,y) se e solo se P(y,x); Proprietà funzionali: se una proprietà P viene denita come funzionale, allora per tutte le x, y e z si ha che: P(x,y) e P(x,z) implicano y = z; Proprietà inverse: se una proprietà P1 viene denita come la proprietà inversa di P2, allora per tutte le x e y si ha che: P1(x,y) se e solo se P2(y,x); Proprietà funzionali inverse : se una proprietà P viene denita come una proprietà funzionale inversa, allora per tutte le x, y e z si ha che: P(y,x) e P(z,x) implicano y = z. È possibile limitare ulteriormente l'intervallo dei valori che una proprietà può assumere in specici contesti, mediante i seguenti meccanismi: • allValuesFrom e someValuesFrom: sono meccanismi locali, ovvero si applicano solo alla classe in cui sono deniti. La restrizione owl:allValuesFrom richiede che per ogni istanza della classe che ha delle istanze della specica proprietà, i valori della proprietà devono essere tutti membri appartenenti alla classe indicata nella clausola della owl:allValuesFrom. La proprietà owl:someValuesFrom è simile: la differenza tra queste due formulazioni è la dierenza che sussite tra i due quanticatori universale ed esistenziale. • owl:cardinality : permette di specicare esattamente il numero di elementi in una relazione. • owl:has value: permette di specicare delle classi sulla base dell'esistenza di particolari valori della proprietà. Class expressions OWL fornisce altri costrutti addizionali per creare le cosiddette class expressions (o classi complesse). Le class expressions possono essere annidate tra di loro senza che ci sia bisogno di creare un nome per ogni classe intermedia. OWL supporta a tale scopo i seguenti costrutti: • Operatori di insieme (intersectionOf, unionOf, complementOf ); • Classi enumerate (oneOf ): per specicare una classe mediante l'enumerazione diretta dei suoi membri; 1.2.2 Sottolinguaggi • 10 Classi disgiunte (disjointWith): garantisce che un individuo che è membro di una classe non può essere contemporaneamente una istanza di un'altra specica classe. 1.2.2 Sottolinguaggi OWL fornisce tre sottolinguaggi di espressività crescente, progettati per essere utilizzati da determinate comunità di sviluppatori e utenti: • OWL Lite: aiuta quegli utenti che hanno soprattutto bisogno di una gerarchia di classicazione con semplici restrizioni; • OWL DL: supporta quegli utenti che vogliono il massimo dell' espressività senza perdere la completezza computazionale 2 e la decidibilità 3 dei sistemi di ragionamento. OWL DL comprende tutti i costrutti del linguaggio OWL con delle restrizioni. OWL DL si chiama così a causa della sua corrispondenza con la logica descrittiva • SHOIN 4 ; OWL Full è destinato agli utenti che vogliono la massima espressività e libertà sintattica di RDF, senza garanzie computazionali; 1.2.3 OWL2 OWL 2 è un ampliamento e revisione di OWL. Nella Figura 2 l'ellisse al centro rappresenta la nozione astratta di una ontologia, che può essere pensata sia come una struttura astratta che come un grafo RDF. Nella parte superiore della gura vi sono varie sintassi concrete che possono essere utilizzate per serializzare e scambiare ontologie: la sintassi primaria per lo scambio di OWL 2 è RDF/XML. In basso vi sono le due speciche semantiche che deniscono il signicato di ontologie OWL 2: la semantica diretta e la semantica basata su RDF, mentre un teorema di corrispondenza fornisce un collegamento tra le due. Queste due semantiche sono utilizzate da ragionatori e altri strumenti, ad esempio per rispondere a problemi di consistenza di classi, sussunzione e query di recupero delle istanze. La semantica diretta assegna signicato direttamente alla struttura dell' ontologia, ottenendo una semantica compatibile col modello teorico semantico della logica descrittiva: le ontologie che soddisfano queste condizioni sintattiche sono chiamate ontologie OWL 2 DL. OWL 2 aggiunge nuove funzionalità rispetto alla versione OWL 1.1, tra 2 Tutte le conclusioni hanno la garanzia di essere calcolabili 3 Tutte le computazioni niscono in un tempo denito 4 Vedere paragrafo 1.3.3 1.2.3 OWL2 11 Figure 1.2: OWL2 cui l'introduzione di syntactic sugar e di nuovi costrutti più espressivi. I proli OWL 2 sono sotto-linguaggi (sottoinsiemi sintattici) di OWL 2 che orono vantaggi importanti in scenari di applicazione particolari: • OWL 2 EL: indicato per applicazioni in cui sono necessarie ontologie molto grandi, e in cui il potere espressivo può essere sacricato per ottenere garanzie nelle prestazioni (sono poste restrizioni sintattiche su costrutti e assiomi). Il prolo EL++ è concepito come il massimo sottoinsieme di OWL 2 DL; • OWL 2 QL: indicato per applicazioni in cui vengono utilizzate ontologie relativamente leggere per organizzare un gran numero di individui, e dove è utile o necessario accedere ai dati direttamente tramite query relazionali; • OWL 2 RL: indicato per applicazioni in cui vengono utilizzate ontologie relativamente leggere per organizzare un gran numero di individui, e 1.3 Logiche descrittive 12 dove è utile o necessario operare direttamente sui dati in forma di triple RDF. Ogni prolo è denito come una restrizione sintattica delle speciche strutturali di OWL 2: ciascuno dei proli raggiunge un trade-o rinunciando a parte della potenza espressiva di OWL in cambio di diversi beneci computazionali e/o implementativi. 1.3 Logiche descrittive Le Logiche Descrittive 5 (Description Logics, DLs) sono una famiglia di 6 formalismi di rappresentazione della conoscenza : esse rappresentano la conoscenza di un dominio di applicazione (detto mondo) denendo per prima i concetti rilevanti del dominio (la terminologia) e poi utilizzando questi concetti per specicare proprietà di oggetti e individui che occorrono nel dominio (la descrizione del mondo). Le DL sono dotate di una semantica formale basata su logica. L'enfasi è data al ragionamento: esso permette di inferire conoscenza rappresentata implicitamente dalla conoscenza che è esplicitamente contenuta nella 7 base di conoscenza . Problemi di decidibilità e complessità dei problemi di inferenza dipendono dal potere espressivo delle DL: da un lato DL molto espressive possono avere problemi inferenziali dovuti ad una elevata complessità, o possono essere anche indecicibili; d'altro canto DL molto snelle (con procedure di ragionamento ecienti) potrebbero non essere sucientemente espressive da rappresentare i concetti importanti di una data applicazione. La ricerca del trade-o tra l'espressività delle DL e la complessità dei loro problemi di reasoning è uno dei principali problemi nella ricerca. Tuttavia, 8 l' intrattabilità di ragionamento non impedisce a una DL di essere usata in pratica, grazie alle sosticate tecniche di ottimizzazione che sono usate nell'implementazione di sistemi basati su DL. 5 D'ora in poi saranno indicate anche con DL 6 Branca dell'intelligenza articiale che studia il modo in cui avviene il ragionamento umano e si preoccupa di denire dei simbolismi o dei linguaggi che permettano di formalizzare la conoscenza, al ne di renderla comprensibile alle macchine per potervi fare dei ragionamenti automatici ed estrarre così nuova conoscenza 7 Detta anche Knowledge base (KB): è un tipo speciale di database per la gestione della conoscenza 8 L' essere non-polinomiale nel peggiore dei casi. Vedere paragrafo 4.3.1 1.3.1 Denizione del formalismo di base 1.3.1 13 Denizione del formalismo di base Un sistema di rappresentazione della conoscenza basato su logica descrittiva fornisce dei mezzi per impostare una base di conoscenza, per ragionare sul suo contenuto e per manipolarlo. La gura 1.3 mostra l'architettura di un sistema tale. Una base di conoscenza comprende due componenti: un TBox e un ABox. Il TBox introduce la terminologia, ossia il vocabolario di un dominio di applicazione, mentre l'ABox contiene le asserzioni circa individui del vocabolario. Il vocabolario è costituito da concetti (concept), che denotano insiemi di individui, e regole (role names), che denotano relazioni binarie tra individui. In aggiunta, tutti i sistemi DL permettono ai loro utenti di costruire descrizioni complesse di concetti e ruoli: il TBOX può essere usato per assegnare nomi a descrizioni complesse. Un sistema DL non memorizza solo terminologie e asserzioni, ma ore anche servizi di reasoning su esso. Figure 1.3: Architettura di un sistema di rappresentazione della conoscenza basato su Logica Descrittiva 1.3.2 Description languages Le logiche descrittive vengono espresse in modo formale tramite i linguaggi descrittivi. I concetti atomici e i ruoli atomici sono descrizioni elementari: partendo da essi è possibile costruire descrizioni complesse per induzione utilizzando i costruttori di concetto. In notazione astratta si usano le lettere A e B per i concetti atomici, la lettera R per i ruoli atomici e le 1.3.3 La famiglia dei linguaggi AL 14 lettere C e D per le descrizioni di concetti. I linguaggi descrittivi sono distinti in base ai costruttori che forniscono. Il linguaggio AL (Attributive Language) è stato introdotto come un linguag- gio minimale di interesse pratico. Gli altri linguaggi di questa famiglia sono estensioni di AL. Le descrizioni di concetti in AL sono realizzate seguendo le seguenti re- gole sintattiche: C,D →A: concetto atomico; >: concetto universale; ⊥: concetto bottom; ¬A: negazione atomica; CuD: intersezione; ∀R.C: quanticatore universale; ∃R.>: quanticatore esistenziale limitato. AL, Al ne di denire una semantica formale associata ai concetti considera l'interpretazione I, che consiste in un insieme non vuoto I ∆ si (il do- minio dell'intrepretazione) e in una funzione di intrepretazione che assegna I I ad ogni concetto atomico A un insieme A ⊆ ∆ e ad ogni ruolo atomico R I I I una relazione binaria R ⊆ ∆ ×∆ . 1.3.3 La famiglia dei linguaggi Aggiungendo altri costrutti ad AL AL si ottengono linguaggi molto più espres- sivi: • U: comprende il costrutto per l'unione di concetti: CtD; • E: comprende il quanticatore esistenziale completo: ∃R.C. Esso dif- ferisce dal quanticatore esistenziale limitato (∃R.>) perché nell'ambito del quanticatore possono comparire anche concetti arbitrari e non solo il concetto universale; • N: • C: comprende le restrizioni numeriche: ≤(almeno) comprende la negazione di concetti arbitrari: Estendendo e ≥(al massimo); ¬C. AL con alcuni dei costrutti sopra indicati si ottengono particolari AL[U ][E ][N ][C ], dove ad ogni linguggi, denominati da una stringa nella forma lettera corrisponde la presenza dei corrispondenti costrutti. Da un punto di vista semantico questi linguaggi non sono tutti distinti: vi sono infatti le seguenti equivalenze CtD ≡ ¬(¬Cu¬D) e ∃R.C ≡ ¬∀R.¬C. 1.3.4 Terminologia-TBox 15 È evidente che l'unione e il quanticatore esistenziale possono essere espressi usando la negazione: di conseguenza si assume che essi siano disponibili in tutte le lingue che contengono la negazione e viceversa. Perciò spesso si usa la lettera C al posto delle lettere UE . 9 La notazione letterale standard include anche : • S: estende la DL ALE con l'ulteriore possibilità di denire la chiusura transitiva di un ruolo; • H: fornisce la possibilità di denire gerarchie tra ruoli; • O: asserisce la presenza dell'operatore di enumerazione; • I: permette di riferirsi al ruolo inverso; • F, N , Q: caratterizzano le possibilità di denire cardinalità rispetti- vamente funzionale, semplice e qualicata (in ordine di espressività crescente); • (D): descrive la possibilità di riferirsi a domini concreti. La semantica dei concetti identica i linguaggi descrittivi come frammenti della logica dei predicati del primo ordine. 1.3.4 Terminologia TBox Una terminologia è costituita da un insieme di denizioni con cui si possono introdurre concetti atomici come abbreviazioni per indicare concetti più complessi. Nel dettaglio, un TBoX contiene assiomi terminologici, cioè aermazioni su come i concetti o i ruoli sono collegati gli uni agli altri. Essi hanno la forma di: • Denizioni C≡D (R≡S): sono assiomi specici, uguaglianze sul cui lato sinistro vi è un concetto atomico. Le denizioni sono utilizzate per introdurre nomi simbolici al posto di descrizioni complesse. Un insieme nito di denizioni T è chiamato una terminologia o TBox se non vi sono nomi simbolici deniti più di una volta. • Assiomi di inclusione CvD (RvS): si usa l'inclusione per concetti che non si è in grado di denire completamente. Un insieme di assiomi T 9 Per approfondimenti consultare il The description logic handbook: theory, implementation, and applications(Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F.) 1.3.5 Descrizione del mondo-ABox 16 è un terminologia generalizzata se sul lato sinistro di ogni assioma vi è un concetto atomico e per ogni concetto atomico vi è al più un assioma in cui esso compare sul lato sinistro. 1.3.5 Descrizione del mondo-ABox Il secondo componente di una base di conoscenza, in aggiunta al Tbox, è la descrizione del mondo (Abox). Nell' ABox si descrive un particolare stato di un dominio tramite asserzioni su individui. Si possono fare aermazioni dei due tipi seguenti: • Asserzione di concetto C(a): asserisce che l'individuo a appartiene al concetto C; • Asserzione di ruolo R(b,c): aerma che l'individuo c è un role-ller R (argomento del ruolo R) per l'individuo b. A volte singoli nomi (chiamati anche nominals) sono presenti non solo nell' ABox, ma anche nel TBox. Tra i costruttori di concetto che impiegano individui vi sono il costruttore set { a1, ... ,an } e il costruttore lls R:a . 1.3.6 Inferenza Un sistema di rappresentazione della conoscenza basato su DL è in grado di svolgere determinati tipi di ragionamento deniti come inferenze logiche. Nel dettaglio, i reasoning tasks per un Tbox sono: • Soddisfacibilità: un concetto ha senso se c'è qualche interpretazione che soddisfa gli assiomi di T (cioè un modello di T) tale che il concetto indica un insieme non vuoto secondo questa interpretazione. Un concetto con questa proprietà si dice essere soddisfacibile rispetto a T e insoddisfacibile altrimenti. La verica della soddisfacibilità dei concetti è un problema di inferenza chiave; • Sussunzione: verica se un concetto è più generale di un altro. Un concetto C è sussunto da un concetto D se in ogni modello di T l'insieme denotato da C è un sottoinsieme dell'insieme contrassegnato da D; • Equivalenza: dati due concetti C e D, verica se è vero che in ogni modello della base di conoscenza si ha che le interpretazioni dei due concetti coincidono; 1.3.6 Inferenza • 17 Disgiunzione: dati due concetti C e D, verica se è vero che in ogni modello della base di conoscenza si ha che le interpretazioni dei due concetti sono insiemi disgiunti. Al ne di ottenere procedure di decisione per ognuna delle quattro inferenze discusse in realtà è suciente sviluppare algoritmi che decidono la sola soddisfacibilità dei concetti, a condizione che il linguaggio supporti la congiunzione così come la negazione di concetti arbitrari, e contenga il concetto insoddisfacibile 10 . Inoltre, per lo sviluppo di procedure di ragionamento è concettualmente più semplice astrarre dal TBOX o, il che è lo stesso, ritenere che esso sia vuoto. Se T è un TBox aciclico, si possono sempre ridurre i problemi di ragionamento riguardanti T a problemi riguardanti il TBox vuoto. I Reasoning tasks per un ABox invece sono: • Consistenza: un ABox A è consistente rispetto ad una TBox T se vi è una interpretazione che è un modello di A e T. Si può dire semplicemente che A è consistente se è consistente rispetto al TBox vuoto; • Instance check: data una base di conoscenza KB, ovvero una TBox T ed un ABox A, e dati un termine C ed un nominale, stabilisce se C(a) è conseguenza logica di KB; • Retrieval: dato un ABox A e un concetto C, trova tutti gli individui tali che C(a) è conseguenza logica di A; • Realization: dato un individuo e un insieme di concetti, trova il concetto più specico C dell'insieme per cui C(a) è conseguenza logica di A. Il ragionamento su concetti (TBox) può essere a sua volta ricondotto alla verica di consistenza: la soddisfacibilità dei concetti può essere ridotta a consistenza dell' ABox perché C è soddisfacibile se C(a) è consistente. 10 Per approfondimenti, consultare il The description logic handbook: theory, implementation, and applications, Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F., Cambridge University Press 1.3.7 Estensioni del linguaggio 1.3.7 18 Estensioni del linguaggio È possibile inoltre esprimere relazioni tra insiemi di role-ller di dierenti 11 (complessi) ruoli, tramite restrizioni numeriche e costrutti più espressivi • : Costruttori di ruoli: dato che i ruoli sono interpretati come relazioni binarie, si possono impiegare i soliti operatori (ad esempio gli operatori booleani) sulle relazioni binarie per formare nuovi ruoli; • Restrizioni numeriche espressive: si possono prendere in considera- zione le cosiddette restrizioni numero qualicate, dove le restrizioni numeriche riguardano role-llers appartenenti ad un certo concetto; • Role-values-maps: sono una famiglia di costrutti molto espressivi. In dettaglio, una role chain è una composizione del tipo R1◦R2. . .◦Rn di nomi di ruolo. Se R e S sono role chain, allora R⊆S e R=S sono role-value-maps. 11 Per approfondimenti, consultare il The description logic handbook: theory, implementation, and applications, Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F., Cambridge University Press Chapter 2 SNOMED CT 2.1 Panoramica SNOMED CT (Systematized Nomenclature of Medicin-Clinical Terms) è la terminologia clinica sanitaria più completa e multilingue al mondo (utilizzata in circa 50 paesi, tra cui non compare l'Italia). Il suo obiettivo è rappresentare precisamente le informazioni cliniche in tutti i campi di applicazione dell' assistenza sanitaria: fornisce infatti contenuti clinici per la documentazione clinica e collabora con altri standard internazionali. È una risorsa essenziale per le cartelle cliniche elettroniche, con un contenuto completo e validato scienticamente. Attualmente è ancora viva la questione se si tratti o no di una ontolo- 1 gia: secondo i documenti uciali rilasciati dalla HITSDO , SNOMED CT è denito come una terminologia clinica sempre più guidata da principi ontologici, in quanto soggetto a continue revisioni; in letteratura invece lo si denisce un'ontologia. Uno dei primi risultati dello studio riportato in questa tesi è che eettivamente presenta tutte le caratteristiche di un'ontologia, sebbene non di alta qualità secondo quelli che sono i canoni dell'ingegneria 2 ontologica . SNOMED CT presenta le seguenti caratteristiche peculiari, che contribuiscono ad una sua diusa adozione: • Completezza: dispone di un' ampia copertura di argomenti relativi alla salute e di una profondità senza precedenti, che consente ai medici di registrare i dati al livello adeguato di granularità; • Scalabilità: il numero di concetti in SNOMED CT continua a crescere, 1 Ente che ne detiene i diritti, vedere paragrafo 2.2 2 Vedere paragrafo 4.1 19 2.1 Panoramica 20 come ragura il trend degli ultimi anni in gura 2.1; • Flessibilità: applicazioni speciche tendono a concentrarsi su un sottoinsieme ristretto del contenuto di SNOMED CT. Inoltre, quando singole giurisdizioni hanno esigenze che vanno al di là di quelle che possono riettersi in una terminologia a livello mondiale, possono sviluppare estensioni locali o nazionali. Figure 2.1: Numero di concetti attivi di SNOMED CT dal 2002 al 2008. (Fonte: www.hitsdo.org) • Supporto di dierenti lingue: sebbene la International Release includa concetti e relazioni indipendenti dal linguaggio, essa incorpora dei framework per gestire diverse lingue e dialetti; • Cross maps: fornisce collegamenti espliciti con classicazioni e schemi di codica connessi alla salute in uso in tutto il mondo (ad esempio 3 classicazioni di diagnostica, come ICD-9-CM, ICD-O3, e ICD-10 , così come la classicazione OPCS-4 degli interventi). Le distribuzioni di SNOMED CT sono composte da una serie di prodotti: • SNOMED CT terminology les, composti da Concetti, Descrizioni, Relationships; 3 La classicazione ICD (dall'inglese International Classication of Diseases) è la classicazione internazionale delle malattie e dei problemi correlati, stilata dall'Organizzazione mondiale della sanità (OMS-WHO) 2.1 Panoramica 21 • Strumenti tecnici per sostenere lo sviluppo e la richiesta di elaborazioni; • Un insieme di standard alleati SNOMED CT, che consentono a SNOMED CT di interoperare in modo ecace con e/o mapparsi con altri standard internazionali; • Norme di attuazione per l'uso di SNOMED, tra cui Traduzioni e Re- ference Implementetion Instructions; • Servizi per mantenere un database in linea con i concetti necessari; • Opere derivate che contribuiscono alla diusione e l'uso di SNOMED: regole di implementazione, guide di riferimento. 2.2 Storia 2.2 22 Storia SNOMED CT è il risultato di uno sviluppo congiunto dell'NHS (National 4 Health Service ) in Inghilterra e il CAP (College of American Pathologists). È stato costituito nel 1999 dalla convergenza di SNOMED RT (SNOMED Reference Terminology, sistema di classicazione multiassiale) e CTV3 (Cli- 5 nical Terms Version3 ). SNOMED CT è stato in reltà avviato nel 1965 come SNOP (Systematized Nomenclature of Pathology), e successivamente esteso in altri campi della medicina. Nel 2007 i diritti di proprietà intellettuale di SNOMED CT sono stati trasferiti dalla CAP alla SNOMED SDO nella creazione formale della IHTSDO (International Health Terminology Standards Development Organisation): organizzazione internazionale no-prot con sede in Danimarca. La IHTSDO possiede e gestisce i diritti di SNOMED CT, compreso il diritto di rilasciare 6 le licenze SNOMED CT necesssarie per poterlo utilizzare . La HITSDO ha una serie di membri, divisi in due categorie: i membri fondatori (ossia i paesi che hanno lanciato l'organizzazione stessa nel 2007, come gli Stati Uniti, Canada, Australia, Regno Unito, Danimarca, Svezia, Lituania, Paesi Bassi, Nuova Zelanda) e i soci ordinari (quei paesi che hanno aderito/aderiscono successivamente). I membri hanno una serie di diritti e responsabilità, tra cui coordinare le richieste di integrazioni o modiche a SNOMED CT da ciascun paese. L' IHTSDO's online Request Submission System consente infatti ai National Release Centers 7 dei paesi membri e ad altri utenti autorizzati di richiedere modiche o aggiunte al contenuto della International Release di SNOMED CT. L'organizzazione fattura ogni membro di tasse annuali, calcolate in base al reddito nazionale lordo dalla banca mondiale. Nella gura 2.2 è riportata una porzione della tabella dove sono indicate le quote che ogni nazione dovrebbe 8 pagare se decidesse di diventare membro, espresse in dollari statunitensi . Secondo l' ultimo aggiornamento risalente al 2007 e pubblicato sul sito uciale della organizzazione, l'Italia dovrebbe pagare una tassa annua di circa 680.000 dollari statunitensi. 4 Il Servizio Sanitario Britannico 5 Classicazione computer-based conosciuta come Read Codes Version 3 6 SNOMED CT è un Crown copyright, copyright per tutte le pubblicazioni governative 7 I centri di rilascio nazionale 8 ATLAS è un fattore di conversione usato nel calcolo del reddito nazionale lordo (GDI). USD sta per dollari statunitensi 2.2 Storia 23 Figure 2.2: Porzione della tabella che riporta le tasse annuali per i potenziali membri della HITSDO. (Fonte: www.HITSDO.org) La HITSDO lavora con altre organizzazioni che stabiliscono standard per promuovere l'uso coerente della terminologia, tra cui: • HL7 - Health Level 7 : SNOMED è uno standard registrato nel HL7 Vocabulary Technical Committee per l'uso in messaggi HL7; • DICOM - Digital Imaging and Communications in Medicine; • ISO - International Organization for Standardization; • X12 - Accredited Standards Committee; • American Academy of Ophthalmology; 2.2 Storia 24 • ANSI - American National Standards Institute (Stati Uniti); • Il progetto Australian General Practice Vocabulary; • CHI-consolidated Health Informatics Initiative (Stati Uniti); • IOM - Institute of Medicine (Stati Uniti); • National Committee on Vital and Health Statistics (United States); • NCVHS Subcommittee on Standards and Security. Inoltre la World Health Organization (WHO) e l'IHTSDO discutono attivamente le possibilità di armonizzazione tra le due organizzazioni. Ciò ha incluso la costituzione di un Interim Harmonization Panel avvenuta tra il luglio 2008 e marzo 2009. 2.3 Utilizzi 2.3 25 Utilizzi SNOMED CT è utilizzato principalmente come: • Standard per le informazioni cliniche: le applicazioni software possono utilizzare i concetti, le gerarchie e le relazioni SNOMED CT come un punto di riferimento comune per l'analisi dei dati; • Base per applicazioni di analisi: le organizzazioni di assistenza sanitaria possono sviluppare applicazioni di analisi ecaci per condurre i risultati della ricerca, valutare la qualità e il costo delle cure e progettare linee guida di un trattamento ecace. I vantaggi del suo impiego in questi contesti sono: • Informazioni più facilmente accessibili e complete: i fornitori di servizi sanitari sono supportati nel processo di assistenza sanitaria (anamnesi, malattie, cure, risultati di laboratorio ecc.) con risultati migliori per i pazienti; • Trattamento facilitato: una terminologia clinica può consentire a un fornitore di cure sanitarie di identicare i pazienti sulla base di alcune informazioni codicate nelle loro cartelle. Per utilizzare SNOMED CT serve una licenza di aliazione, che può essere richiesta da individui e organizzazioni appartenenti o no a paesi membri: • Se la richiesta di utilizzo proviene da individui e organizzazioni presenti nel territorio di un paese membro, basta contattare il centro di rilascio nazionale, che fornirà SNOMED CT gratuito per gli utenti o potrà addebitare una piccola tassa per il recupero dei costi; • Per i paesi a basso reddito, a partire dal 2009 le licenze di aliazione per l'uso di SNOMED CT sono rilasciate a titolo gratuito; • Se la richiesta di utilizzo proviene da un paese non membro e non a basso reddito, è necessario richiedere la licenza di aliazione on-line, utilizzando un servizio apposito. Ottenuta la licenza si è contattati ogni 6 mesi dalla HITSDO per un resoconto dell'utilizzo che si è fatto di SNOMED CT, e vine conseguentemente fatturata la tasse di licenza applicabile. Sono esenti dal pagamento i progetti di ricerca qualicati, di benecenza e i progetti per scopi umanitari. 2.4 Componenti base 2.4 26 Componenti base 2.4.1 Concetti Un concetto rappresenta un preciso signicato clinico ed è identicato da un identicativo numerico (conceptID). Ad esempio il conceptID 55679008 indica il concetto Peribronchial pneumonia (disease). I concetti attivi sono più di 311.000, numero che è in continua crescita grazie alla collaborazione internazionale (gura 2.1). Ogni concetto è rappresentato da: • Un Fully Specied Name (FSN): fornisce una rappresentazione humanreadable; • Relazioni con altri concetti: gli danno una denizione formale; • Una serie di termini: spiegano il concetto in un modo human-readable. La rappresentazione dei concetti è molto granulare: i concetti possono essere generali o possono rappresentare sempre più specici livelli di dettaglio (granularità maggiore), consentendo ai clinici di scegliere il livello di dettaglio che preferiscono (Figura 2.3). 2.4.1 Concetti 27 Figure 2.3: Granularità dei concetti SNOMED CT I contenuti sono divisi in gerarchie: il Root concept è il supertipo dei concetti top-level e di tutti i concetti al di sotto di essi (gura 2.4). L'elenco completo delle gerarchie è il seguente: • Clinical nding : rappresenta i risultati di una osservazione, valutazione o giudizio clinico. Include le condizioni cliniche sia normali che anormali (ad es. Poor posture). Contiene la sotto-gerarchia Disease (ad esempio Tuberculosis); • Procedure : descrive le attività svolte nella fornitura di assistenza sanitaria (ad esempio Appendectomy ), come procedure invasive, somministrazione di farmaci, procedure di imaging, procedure amministrative; • Observable entity : descrive questioni o procedure che possono produrre una risposta o un risultato (ad esempio colore dell'unghia); 2.4.1 Concetti 28 Figure 2.4: Gerarchia dei concetti SNOMED CT • Body structure: descrive le strutture anatomiche normali e anormali. Normali strutture anatomiche possono essere utilizzate per specicare il sito del corpo interessato da una malattia o una procedura (ad es. Structure of the mitral valve). Contiene la sotto-gerarchia Body structure, altered from its oríginal anatomical structure (morphologic abnormality); • Organism: rappresenta organismi di rilevanza in medicina umana e animale (ad esempio Streptococcus pyogenes). È utilizzata anche nella modellazione delle cause delle malattie; • Substance: descrive le sostanze generali e i componenti chimici di Pharmaceutical/biologic product (ad esempio Insulin). Sotto-gerarchie di Substance comprendono anche, ma non sono limitate a: stance Body sub- (concetti per rappresentare sostanze del corpo), Dietary sub- stance, Diagnostic substance; • Specimen: concetti che rappresentano entità che si ottengono da un esame o analisi, di solito da un paziente (ad esempio samples obtained by prostate biopsy ); • Special concept: contiene la sotto-gerarchia Inactive concept, che è il supertipo per tutti i concetti che sono stati ritirati e che contengono un riferimento a un corrispondente concetto attivo nella terminologia; 2.4.1 Concetti • 29 Pharmaceutical/biologic product: gerarchia di livello superiore che consente di distinguere chiaramente i prodotti faramaceutici (products) dai loro costituenti chimici (substances). I livelli di prodotti farmaceutici rappresentati nella International Release comprendono: Virtual Medicinal Product (VMP): è il livello più granulare. Nel Fully Specied Name è compreso il nome del prodotto, il dosaggio e come si presenta la dose (ad es. Diazepam 5mg tablet); Virtual Therapeutic Moiety (VTM): il Fully Specied Name include solo il nome del prodotto (ad es. Diazepam). Tutti i VMP hanno un collegamento diretto col VTM attraverso una relationship IS_A 9 ; Product category : tipicamente descrivono comuni categorie di farmaci usati nella prescrizione (ad es. sex hormone product). Inoltre, sono state sviluppate delle estensioni per gli Stati Uniti e il Regno Unito per rappresentare gli Actual Medicinal Products (AMPs): i concetti AMP contengono marca e informazioni speciche del paese, e non sono rappresentati all'interno della International Release di SNOMED CT. Una estensione Actual Medicinal Products ha un link diretto al suo equivalente virtuale nella International Release attraverso la relationship IS_A. La gura 2.5 ragura una porzione della gerarchia dei Pharmaceutical/biologic product. 9 Vedere capitolo 2.4.3 2.4.1 Concetti 30 Figure 2.5: Gerarchia Pharmaceutical/ biologic product • Physical object: descrive gli oggetti naturali e fatti dall'uomo (ad es. Articial kidney ); • Physical force: descrive le forze siche che possono svolgere un ruolo nel provocare lesioni (ad es. Spontaneous combustion); • Event: rappresenta eventi, escluse le procedure e gli interventi (ad es. ood); 2.4.1 Concetti • 31 Environment or geographical location: descrive i tipi di ambienti e i nomi di località, quali i paesi, gli stati e le regioni (ad es. Canary islands, o Intensive care unit); • Social context: descrive le condizioni sociali e le circostanze rilevanti per l'assistenza sanitaria, come lo stato di famiglia, la situazione economica, il patrimonio etnico e religioso (ad es. Ethnic group: Afro-Caribbean), lo stile di vita, e le occupazioni; • Staging and scales: contiene le sotto-gerarchie: Assessment scales: nomi di scale di valutazione (ad es. Glasgow coma scale); Tumor stagin: nomi di sistemi di stadiazione del tumore (ad es. International Federation of Gynecology and Obstetrics -FIGO- staging ); • Linkage concept: rappresenta i concetti utilizzati per il collegamento dei concetti tra loro. Contiene le sotto-gerarchie: Link assertion : consente l'utilizzo di concetti SNOMED CT nell'ambito di relazioni tra asserzioni previste da HL7; Attribute: utilizzati per indicare la relazione o il tipo di relazione tra 2 oggetti SNOMED CT: ∗ Dening attributes: · IS_A attribute: per la denizione delle gerarchie tra i concetti; · Concept model attribute: ad esempio Laterality, Procedure site, Finding site, Associated morphology. ∗ Non-dening attributes: · Concept history attribute: utilizzati per tracciare le relazioni temporali tra i concetti, come replaced by, same as; · Unapproved attribute: utilizzati per tracciare relazioni non previste dai modelli pre-coordinati in SNOMED CT, come Relieved by. • Qualier value: contiene alcuni dei concetti utilizzati come valori per attributi SNOMED CT (ad es. left); 2.4.2 Descrizioni • 32 Record artifact: descrive una entità che è stata creata da una o più persone allo scopo di fornire ad altre persone informazioni su eventi o stati di cose. Un record è virtuale (indipendente dalla sua particolare istanziazione sica), e si compone dei suoi elementi di informazione, di solito le parole e le frasi, ma anche i numeri, graci, e altri elementi informativi; • Situation with explicit context: SNOMED CT ha sviluppato un context model per consentire agli utenti e/o implementatori di specicare il contesto usando la terminologia, senza dipendere da una particolare struttura record (ad es. Family history: Myocardial infarction, No family history of stroke, Nasal discharge present, Suspected epilepsy ). 2.4.2 Descrizioni Il secondo componente base di SNOMED CT è costituito dalle descrizioni: si tratta di termini o nomi assegnati ad un concetto per spiegarne meglio il signicato. Le descrizioni presenti sono quasi 800.000. Vi sono tre tipi di descrizioni: • Fully Specied Names (FSN): forniscono un modo univoco per nominare un concetto. Terminano con un semantic tag in parentesi alla ne del concetto che indica la categoria semantica a cui appartengono (ad es. Disorder, Organism, Person, ecc.). Un esempio di FSN è Hematoma (morphologic abnormality); • Preferred Term: catturano la parola comune o frase usata dai medici per nominare un concetto. Non sono necessariamente univoci per ogni concetto. Ad es. il concetto Repair of common bile duct (procedure) 54987000 ha il Preferred Term Choledochoplasty ; • Synonyms: lo scopo è quello di rappresentare qualsiasi ulteriore termine che rappresenta lo stesso concetto del FSN. Anche i sinonimi non sono necessariamente univoci per ogni concetto. Le descrizioni possono essere multiple, nel senso che più descrizioni potrebbero essere associate ad uno stesso concetto. Ad esempio, alcune delle descrizioni associate al ConceptID 22298006 sono: • Fully Specied Name: Myocardial infarction (disorder) - DescriptionID 751689013 ; • Preferred term: Myocardial infarction - DescriptionID 37436014 ; 2.4.3 Relationships 33 • Synonym: Cardiac infarction - DescriptionID 37442013 ; • Synonym: Heart attack - DescriptionID 37443015 ; • Synonym: Infarction of heart - DescriptionID 37441018. 2.4.3 Relationships Terzo e ultimo elemento chiave di SNOMED CT è costituito dalle relationship: esse collegano i concetti tra di loro. Di conseguenza ogni concetto risulta essere logicamente denito attraverso le sue relazioni con altri concetti. Le relationships attualmente presenti sono circa 1.360.000. Ogni concetto attivo SNOMED CT (ad eccezione del concetto root SNOMED CT Concept) ha almeno una relationship IS_A con un concetto supertipo. Una relationship viene assegnata solo quando tale relazione è sempre vera. Le principali tipologie di relationships sono: • Dening relationships: usate per modellare i concetti e creare le loro denizioni logiche. Ulteriore distinzione è fatta tra le: IS-A relationship: servono a creare gerarchie tra concetti, quindi a creare relazione del tipo padre-glio. L'esempio in gura 2.6 mostra come un concetto possa avere più di una relationship IS_A con altri concetti; Figure 2.6: Esempio di gerarchia multipla in SNOMED CT Dening attribute: gli attributi di collegano due concetti appartenenti a diverse gerarchie e stabiliscono il tipo di relazione tra loro. Ogni attributo ha un dominio, che indica la gerarchia a cui uno specico attributo può essere applicato, e un range, che indica 2.4.3 Relationships 34 l'insieme dei valori ammessi per ciascun attributo: del range possono far parte anche più gerarchie. L'esempio in gura 2.7 mostra i due concetti polmonite e struttura dei polmoni, collegati attraverso l'attributo nding site: ciò signica che la polmonite viene riscontrata nella parte del corpo chiamata struttura polmonare. Vi sono oltre 50 diversi tipi di attributi di questo tipo in SNOMED Figure 2.7: Esempio di dening attribute in SNOMED CT CT. Gli attributi hanno relazioni gerarchie tra loro, come avviene per i concetti: un attributo generale è genitore di uno o più sot- 10 totipi specici di tale attributo • . Qualifying relationships: opzionali e non-dening, possono essere ap- 11 plicati da un utente o implementatore in post-coordination • Historical: collegano concetti inattivi a concetti attivi; • Additional: rappresentano altre caratteristiche. ; Dening attributes Le gerarchie a cui sono assegnati i Dening attributes sono chiamate gerarchie principali (ad esempio Procedure, Clinical nding, Pharmaceuti- 10 Il paragrafo successivo approfondisce ulteriormente l'agomento 11 Per creare una singola espressione costituita da diversi concetti collegati da attributi 2.4.3 Relationships 35 cal/Biologic product, Situation with explicit context, Event, Specimen, e Physical object). Le gerarchie che non utilizzano gli attributi sono chiamate invece gerarchie di sostegno (Social context, Substance, Organism, e Observable entity ): esse possono essere usate come valori degli attributi nella denizione dei concetti delle gerarchie principali. Gli attributi hanno relazioni gerarchice tra loro, formando delle role hierarchies: un attributo generale è genitore di uno o più sottotipi specici di tale attributo. Di seguito è riportato un elenco dei principali attributi utilizzabili nelle gerarchie principali: • ATTRIBUTI PER DEFINIRE CONCETTI CLINICAL FINDING: FINDING SITE: specica la parte del corpo colpita da una condizione. Ad esempio: kidney disease (disorder) FINDING SITE kidney structure (body structure) ; ASSOCIATED MORPHOLOGY : specica i cambiamenti morfologici visti a livello dei tessuti o a livello cellulare che sono l'elemento caratterizzante di una malattia. Ad esempio: pancreati- tis (disorder) ASSOCIATED MORPHOLOGY inammation (morphologic abnormality) ; ASSOCIATED WITH : rappresenta un'associazione clinicamente rilevante tra i concetti, senza né aermare né escludere un nesso di causalità o sequenzialità tra i due. Sussume i seguenti, più specici, attributi nella role hierarchy: ∗ AFTER: modella concetti in cui un clinical nding si verica dopo un altro clinical nding o procedure. Ad esempio: post viral disorder (disorder) AFTER viral disease (disorder); ∗ DUE TO : collega un clinical nding direttamente alla sua causa. Ad esempio: cheilitis due to atopic dermatitis(disorder) IS_A cheilitis (disorder) DUE TO atopic dermatitis (disorder); ∗ CAUSATIVE AGENT : identica l'agente eziologico diretto di una malattia. Ad esempio: bacterial endocarditis (disorder) CAUSATIVE AGENT superkingdom bacteria (organism). SEVERITY : rappresenta il livello di gravità per un concetto clinical nding. L'uso dell'attributo severity è spesso relativo. Questo attributo non viene utilizzato nella distribuzione della International Release; 2.4.3 Relationships 36 CLINICAL COURSE: rappresenta sia il decorso che l'insorgenza di una malattia. Ad esempio: acute amebic dysentery (disorder) CLINICAL COURSE sudden onset and/or short duration (qualier value); EPISODICITY : specica il primo episodio di una malattia di un paziente. Non viene utilizzato nella distribuzione della Interna- tional Release; INTERPRETS: entità in corso di valutazione o di interpretazione, usato insieme a has interpretation; HAS INTERPRETATION : designa l'aspetto della sentenza in corso di valutazione o di interpretazione di un concetto (ad es. la presenza, l'assenza, il grado, la normalità, l'anormalità, ecc.). Ad esempio: decreased muscle tone (nding) INTERPRETS muscle tone (observable entity) HAS INTERPRETATION decreased (qualier value); PATHOLOGICAL PROCESS: fornisce informazioni sul processo patologico di base per una malattia che non è strutturale e che non è rappresentata dall' attributo associated morphology. Ad esempio: disease caused by parasite (disorder) PATHOLOGICAL PROCESS parasitic process (qualier value); HAS DEFINITIONAL MANIFESTATION : collega i disorders ai clinical ndings che sono sempre presenti, per denizione; OCCURRENCE: si riferisce al periodo specico della vita durante il quale una condizione si presenta per la prima volta. Ad esempio: childhood phobic anxiety disorder (disorder) OCCURRENCE childhood (qualier value); FINDING METHOD: specica il mezzo attraverso il quale un clinical nding (accertamento clinico) è stato determinato. Ad esempio: nding by palpation (nding) FINDING METHOD palpation (procedure); FINDING INFORMER: specica la persona o altro soggetto da cui l'informazione clinical nding è stato ottenuta. Ad esempio: complaining of a headache (nding) FINDING INFORMER subject of record or other provider of history (person); • ATTRIBUTI PER DEFINIRE CONCETTI PROCEDURE: METHOD : rappresenta l'azione che viene eseguita nella procedura. Ad esempio: incision of ureter (procedure) METHOD incision action (qualier value); 2.4.3 Relationships 37 PROCEDURE SITE: parte del corpo su cui si agisce o che è colpita da una procedura. Ad esempio: procedure on colon (proce- dure) PROCEDURE SITE colon structure (body structure). Sussume nella role hierarchies gli attributi più specici: ∗ PROCEDURE SITE - DIRECT : utilizzato quando l'azione del procedimento è direttamente rivolta ad una struttura corporea o ad un sito piuttosto che a qualcos' altro (ad esempio un dispositivo) che si trova lì. Ad esempio: biopsy of femur (procedure) METHOD biopsy action (qualier value) PROCEDURE SITE - DIRECT bone structure of femur (body structure); ∗ PROCEDURE SITE - INDIRECT : descrive la parte del corpo che è interessata, ma non è l'oggetto diretto della procedura. Ad esempio: removal of calculus of urinary bladder (procedure) METHOD removal action (qualier value) PROCEDURE SITE - INDIRECT urinary bladder structure (body structure). PROCEDURE MORPHOLOGY : specica la morfologia o struttura anormale del corpo coinvolta nella procedura. Sussume nella role hierarchy gli attributi più specici: ∗ DIRECT MORPHOLOGY : descrive la morfologia a cui la procedura è diretta. Ad esempio: excision of benign neoplasm (procedure) METHOD excision action (qualier value) DIRECT MORPHOLOGY neoplasm, benign (morphologic abnormality); ∗ INDIRECT MORPHOLOGY : rappresenta una morfologia che è interessata, ma non è il bersaglio diretto dell' azione in corso di esecuzione. Ad esempio: removal of mesh from wound (procedure) INDIRECT MORPHOLOGY wound (morphologic abnormality). PROCEDURE DEVICE: descrive i dispositivi associati ad una procedura. Ad esempio: catheter procedure (procedure) DEVICE catheter, device (physical object). Questo attributo generale sussume nella role hierarchy gli attributi più specici: ∗ DIRECT DEVICE: dispositivo su cui il metodo agisce direttamente. Ad esempio:removal of arterial stent (procedure) DIRECT DEVICE arterial stent (physical object); ∗ INDIRECT DEVICE: modella un'azione fatta su qualcosa che si trova in o su un dispositivo, ma non è fatta direttamente sul 2.4.3 Relationships 38 dispositivo stesso. Ad esempio: excision of vegetations from implanted mitral valve (procedure) METHOD excision action (qualier value) INDIRECT DEVICE mitral valve prosthesis, device (physical object); ∗ USING DEVICE: strumento o apparecchiatura utilizzata per eseguire un'azione. Ad esempio: core needle biopsy of larynx (procedure) METHOD biopsy action (qualier value) USING DEVICE core biopsy needle, device (physical object); ∗ USING ACCESS DEVICE: strumento o attrezzatura utilizzata per accedere al sito di una procedura. Ad esempio: arthroscopic synovial biopsy (procedure) METHOD biopsy action (qualier value) USING ACCESS DEVICE arthroscope, device (physical object); ACCESS: descrive il percorso utilizzato per accedere al sito di una procedura. È utilizzato per distinguere tra procedure aperte, chiuse e percutanee. Modiche all' attributo ACCESS sono state approvate ma non ancora pienamente attuate nell'ultima release. DIRECT SUBSTANCE: descrive la sostanza sulla quale il metodo della procedura agisce direttamente. Ad esempio: injection of prostaglandin (procedure) DIRECT SUBSTANCE prostaglandin (substance); PRIORITY : priorità assegnata ad una procedura. Ad esempio: emergency cesarean section (procedure) PRIORITY emergency (qualier value); HAS FOCUS: specica il clinical nding o la procedure che è il focus di una procedura. Ad esempio: cardiac rehabilitation assessment (regime/therapy) HAS FOCUS cardiac rehabilitation (regime/therapy); HAS INTENT : specica l'intento di una procedura. Ad esempio: diagnostic bronchoscopy (procedure) HAS INTENT diagnostic intent (qualier value); RECIPIENT CATEGORY : specica il tipo di individuo o gruppo su cui l'azione della procedura viene eseguita. Per esempio può essere utilizzato nelle procedure delle banche di sangue per differenziare se la procedura è stata eseguita sul donatore o sul destinatario del sangue; REVISION STATUS: specica se la procedura è primaria o no. Ad esempio: primary repair of inguinal hernia (procedure) REVISION STATUS primary operation (qualier value); 2.4.3 Relationships 39 ROUTE OF ADMINISTRATION : specica il percorso attraverso il quale una sostanza viene somministrata. Ad esempio: inhaled drug administration (procedure) ROUTE OF ADMINISTRATION by inhalation (route) (qualier value); SURGICAL APPROACH : specica l'accesso al sito di una procedura chirurgica. Ad esempio: abdominal hysterectomy (pro- cedure) SURGICAL APPROACH abdominal approach (qualier value); USING SUBSTANCE: descrive la sostanza utilizzata per eseguire l'azione di una procedura, ma non è la sostanza sulla quale il metodo della procedura agisce direttamente. Ad esempio: con- trast radiography of esophagus (procedure) USING SUBSTANCE contrast media (substance); USING ENERGY : descrive l'energia utilizzata per eseguire un'azione. Ad esempio: gamma ray therapy (procedure) USING ENERGY gamma radiation (physical force). • ATTRIBUTI PER DEFINIRE CONCETTI SPECIMEN : SPECIMEN PROCEDURE: identica la procedura con cui un campione è ottenuto. Ad esempio: Specimen from stomach ob- tained by total gastrectomy (specimen) SPECIMEN PROCEDURE Total gastrectomy (procedure); SPECIMEN SOURCE TOPOGRAPHY : specica la parte del corpo da cui si ottiene un campione. Ad esempio: Cervix cytologic material (specimen) SPECIMEN SOURCE TOPOGRAPHY Cervix uteri structure (body structure); SPECIMEN SOURCE MORPHOLOGY : indica l'anomalia morfologica da cui si ottiene un campione. Ad esempio: Specimen from cyst (specimen) SPECIMEN SOURCE MORPHOLOGY Cyst (morphologic abnormality); SPECIMEN SUBSTANCE: tipo di sostanza di cui un campione è costituito. Ad esempio: Pancreatic uid specimen (specimen) SPECIMEN SUBSTANCE Pancreatic uid (substance); SPECIMEN SOURCE IDENTITY : tipo di individuo, gruppo o ubicazione sica da cui i campioni sono stati raccolti. Ad esempio: Blood specimen from blood donor (specimen) SPECIMEN SOURCE IDENTITY Blood donor (person). • ATTRIBUTI PER DEFINIRE CONCETTI BODY STRUCTURE: 2.4.3 Relationships 40 LATERALITY : posizione di una struttura del corpo (a sinistra, a destra o bilaterale). Ad esempio: Left kidney structure (body structure) LATERALITY Left (qualier value). • ATTRIBUTI PER DEFINIRE CONCETTI PHARMACEUTICAL/ BIOLOGIC PRODUCT : HAS ACTIVE INGREDIENT : indica il principio attivo di un farmaco. Ad esempio: Naproxen 500mg tablet (product) HAS ACTIVE INGREDIENT Naproxen (substance); HAS DOSE FORM : specica la forma in cui si presenta la dose di un prodotto. Ad esempio: Digoxin 0.1mg capsule (product) HAS DOSE FORM Oral capsule (qualier value). • ATTRIBUTI PER DEFINIRE CONCETTI SITUATION WITH EXPLICIT CONTEXT 12 . Default context: un concetto SNOMED CT senza alcun contesto dichiarato esplicitamente ha un contesto soft-default: vuol dire che la constatazione è eettivamente vericata, si sta vericando per il soggetto del documento (il paziente) e si sta vericando attualmente (o in un determinato momento in passato); Axis modiers: i seguenti sei attributi sono utilizzati per la modellazione dei concetti dipendenti dal contesto in SNOMED CT: essi sono detti attributi modicatori di contesto e permettono la rappresentazione di diversi contesti. Infatti modicano il signicato di un Clinical nding o di una Procedure in un modo che cambia l'asse o la gerarchia del concetto. Ad esempio in Urine protein test not done (situation) PROCEDURE CONTEXT Not done (qualier value), il concetto che ne risulta non è un sottotipo di Urine protein test (procedure): ∗ ASSOCIATED FINDING: specica il concetto Clinical nding il cui contesto è stato modicato. Ad esempio: Family history of stroke (situation) ASSOCIATED FINDING Cerebrovascular accident (disorder); ∗ FINDING CONTEXT : indica se il Clinical nding associato è noto o sconosciuto, se è presente o assente. Ad esempio: No 12 Il signicato trasportato da un concetto SNOMED CT in un documento sanitario è aetto dal contesto in cui è memorizzato. Per esempio cancro della mammella può essere: storia familiare di cancro alla mammella, storia passata di cancro alla mammella o diagnosi corrente di cancro alla mammella 2.4.3 Relationships 41 cough (situation) ASSOCIATED FINDING Cough (nding) FINDING CONTEXT Known absent (qualier value); ∗ ASSOCIATED PROCEDURE: collega i concetti della gerarchia Situation with explicit context con i concetti della gerarchia Procedure per le quali vi è un ulteriore contesto specicato. Ad esempio: Operative procedure planned (situa- tion) ASSOCIATED PROCEDURE Surgical procedure (procedure); ∗ PROCEDURE CONTEXT : indica il grado di completamento di una procedura. Ad esempio: Operative procedure planned (situation) ASSOCIATED PROCEDURE Surgical procedure (procedure) PROCEDURE CONTEXT Planned (qualier value); ∗ TEMPORAL CONTEXT : indica il tempo di insorgenza di un Clinical nding o Procedure, esprimendo se era presente quando il concetto è stato inserito nel documento. Ad esempio: History of hematuria (situation) ASSOCIATED FIN- DING Blood in urine (nding) TEMPORAL CONTEXT In the past (qualier value); ∗ SUBJECT RELATIONSHIP CONTEXT : specica la relazione tra il soggetto del record e il soggetto del Clinical nding o della Procedure in corso di registrazione. Ad esempio: Father smokes (situation) ASSOCIATED FINDING Smoker (nding) SUBJECT RELATIONSHIP CONTEXT Father (person). • ATTRIBUTI PER DEFINIRE CONCETTI EVENT : nel gennaio 2006 un numero limitato di concetti sono stati spostati dalla gerarchia Clinical nding alla gerarchia Event (ASSOCIATED WITH, CAUSITIVE 13 AGENT, DUE TO, AFTER, OCCURRENCE) • ATTRIBUTI PER DEFINIRE CONCETTI PHYSICAL OBJECT : HAS ACTIVE INGREDIENT : è applicato anche ai concetti della gerarchie Pharmaceutical/biologic product • . 14 . ROLE GROUPS: un Role group combina una coppia attributo-valore con un'altra o più coppie attributo-valore (gura 2.8). Serve per aggiungere chiarezza alle denizioni dei concetti: 13 Non sono ancora state stabilite politiche editoriali denitive per l'uso di attributi nella gerarchia Event 14 Non sono ancora state stabilite politiche editoriali denitive per l'uso dell'attributo nella gerarchia Physical object 2.4.3 Relationships 42 CLINICAL FINDING che richiedono più attributi ASSOCIATED MORPHOLOGY e più attributi FINDING SITE; PROCEDURES che richiedono più attributi METHOD e più attributi PROCEDURE SITE 15 . Figure 2.8: Esempio di Role Group in SNOMED CT 15 Tuttavia i Role groups non sono limitati ai concetti Clinical nding e Procedure 2.5 Nazionalizzazione 2.5 43 Nazionalizzazione Per nazionalizzazione si intende il processo di traduzione di SNOMED CT nella lingua target della nazione che decide di utilizzarlo. In Italia ovviamente il processo di nazionalizzazione non è in atto, dato che SNOMED CT non è in uso: tuttavia in questo capitolo verrà descritto a grandi linee come andrebbe svolto, quali sono i punti salienti e le principali problematiche, facendo anche riferimento a concrete esperienze di altre nazioni. Innanzitutto è necessario chiarire che per nazionalizzazione non si intende una semplice traduzione letterale dei concetti, termine a termine, spesso scorretta e fuorviante, ma un processo più complesso. Esso coinvolge di- rettamente diverse tipologie di soggetti, tra cui traduttori, revisori, esperti in materia, validatori, dirigenti e membri di un editorial board (comitato editoriale) o di un gruppo equivalente di esperti che stabilisce le linee guida linguistiche e terminologiche per la traduzione nella lingua target specica. I presupposti per coloro che sono coinvolti nella traduzione, verica e convalida dei contenuti di SNOMED CT sono: l'avere una certa familiarità con i principi terminologici su cui SNOMED CT si basa; il conformarsi alle IHTSDO Style Guides 16 ; la consapevolezza di questioni delicate come la scelta delle varianti lessicali, delle tecniche di traduzione e l'importanza di assicurare la coerenza linguistica. 2.5.1 Introduzione ai principi terminologici L' idea di base nella scienza della terminologia è la distinzione tra un approccio onomasiologico e un approccio semasiologico (applicato in lessicograa). In un approccio onomasiologico il punto di partenza è il concetto, mentre in un approccio semiasologico il punto di partenza è l'espressione linguistica, vale a dire la parola/termine. L' approccio da preferire in un processo di traduzione è quello onomasiologico. In riferimento al Triangolo di Ogden-Richard (gura 2.9), si può distinguere tra: • Concetto: unità di conoscenza creata da un' unica combinazione di caratteristiche; • Designazione: rappresentazione di un concetto da un simbolo che lo denota; • Termine: denominazione verbale di un concetto generale in un campo specico. 16 Linee guida stilate dalla HITSO 2.5.1 Introduzione ai principi terminologici 44 Il termine indica un concetto, e un concetto si rifesce ad un oggetto particolare. Figure 2.9: Triangolo di Ogden-Richard 2.5.2 Tradurre SNOMED CT 45 I sistemi concettuali permettono di inserire un concetto sconosciuto in un contesto semantico. I sistemi più comuni si basano su: • Generic relationships : IS_A - relationship (gura 2.10); • Partitive relationships: PARTE OF - relationship (gura 2.11). Figure 2.10: IS-A - relationship Figure 2.11: PARTE OF - relationship In SNOMED le gerarchie sono rappresentate con una scala verticale in cui ogni livello è illustrato per mezzo di un nuovo paragrafo tabulato (gura 2.4). Le denizioni invece sono le rappresentazioni dei concetti per mezzo di dichiarazioni descrittive, che servono per dierenziare tra loro i concetti connessi. Esse possono essere espresse in logica descrittiva: è quanto accade in SNOMED CT, dove i concetti sono deniti dalle loro relationships gerarchiche (IS-A relationship) e dai dening attribute. 2.5.2 Tradurre SNOMED CT L' obiettivo della traduzione è fornire descrizioni accurate e prive di ambiguità dei concetti SNOMED CT nella lingua di destinazione (lingua target): è 2.5.2 Tradurre SNOMED CT 46 bene in questo contesto utilizzare un principio di traduzione concept-based 17 , ed è fondamentale denire linee guida linguistiche, incluse regole sintattiche, morfologiche e ortograche. Bisogna tenere inoltre presente che il nucleo della terminologia SNOMED CT non è perfetto: l'architettura CT è in fase di grandi cambiamenti e miglioramenti e i membri del team di traduzione devono rivedere e analizzare le relazioni di ogni concetto al ne di chiarire il signicato di un termine. L' approccio di base alla traduzione prevede una collaborazione interdisciplinare tra specialisti nell'ambito sanitario, informatico, linguistico e terminologico, e si trova ad arontare il problema di garantire il giusto equilibrio nel fornire termini coerenti, utilizzabili e clinicamente accettabili. Per la traduzione di termini complessi è necessario avere un relativamente elevato livello di conoscenza della terminologia di dominio, così da comprendere il signicato del termine del linguaggio sorgente; ma per una traduzione corretta è necessario anche esaminare la posizione gerarchica del concetto e le relazioni del concetto con gli altri concetti. Il usso di lavoro di traduzione, illustrato in gura 2.12, è a grandi linee il seguente: preso un concetto, si deve innanzitutto cercare il suo vero signicato individuando qual è la sua posizione all'interno dell'ontologia. Nel caso di dubbi sul signicato, si devono cercare esempi concreti del suo utilizzo in specici contesti. Chiarito dunque il signicato, si può passare alla ricerca del termine equivalente nella lingua target. 17 Approccio onomasiologico, vedere paragrafo 2.5.1 2.5.2 Tradurre SNOMED CT 47 Figure 2.12: Flusso di lavoro di traduzione di SNOMED CT I principi linguistici generali da seguire sono: • Prendere in considerazione i requisiti linguistici locali; • Stabilire i principi preliminari generali per la scelta di varianti lessicali (ad esempio in lingua danese e tedesca è comune utilizzare il puro latino o il greco all'interno del dominio di anatomia, termini ibridi per termini diagnostici o termini che descrivono le procedure, termini nazionali in altri casi); • È bene evitare espressioni colloquiali (slang), che invece possono essere aggiunte in seguito come sinonimi; • È bene anche seguire raccomandazioni stabilite da un consiglio o autorità nazionale linguistica; • È utile prendere in considerazione le pratiche speciche relative a termini medici pubblicati in riviste mediche nazionali. 2.5.2 Tradurre SNOMED CT 48 Tra le principali problematiche linguistiche e terminologiche vi sono: • La selezione del termine migliore per il concetto, tale da soddisfare le esigenze di: Univocità; Correttezza linguistica: rispettando le regole sintattiche e ortograche nazionali; Trasparenza: un termine dovrebbe essere auto-esplicativo; Riconoscibilità internazionale: meglio preferire termini basati su latino e greco; Accettazione psicologica: considerando le preferenze dei medici e la pratica comune; Sistematicità e coerenza: usando soluzioni morfologiche e sintattiche simili per i termini che coprono concetti semanticamente simili. I suddetti requisiti spesso entrano in conitto: pertanto il gruppo incaricato di stabilire le regole per la traduzione di SNOMED CT in un linguaggio specico target spesso deve svolgere un compito dicile. • Il problema dell' equivalenza dei termini: Variazioni nazionali o culturali: parte della terminologia della lingua di partenza, basata su strutture amministrative o pratiche cliniche britanniche o americane, non è necessariamente accettata globalmente. Può essere necessario elaborare nuove sottogerarchie all'interno di una edizione nazionale; False Friends : concetti apparentemente equivalenti nella lingue di partenza e di destinazione, ma che in realtà non lo sono. • La scelta della tecnica di traduzione: esistono diverse tecniche di traduzione applicabili. La gura 2.13 ne riporta degli esempi. • Il vericarsi di questioni sintattiche: L'uso del gerundio: in alcune lingue non è comune quanto lo è in inglese. Pertanto è necessario sostituire il termine con un'altra frase; La scelta del tipo di costruzione: le regole della lingua non possono essere tutte ssate. Si devono dunque seguire le abitudini cliniche e/o si deve seguire la costruzione della lingua di origine; 2.5.2 Tradurre SNOMED CT 49 Figure 2.13: Elenco di alcune tecniche di traduzione I verbi coniugati: andrebbero usati con cautela ed evitati nella gerarchia Procedure, poiché il passato richiama un contesto temporale (ad esempio salivary gland abscess drained dovrebbe essere drainage of salivary gland). I verbi coniugati anderebbero invece usati in gerarchie come Clinical nding o Situation per esprimere una occorrenza (ad esempio Patient has gone abroad); L' ordine delle parole: va fatto riferimento alle regole ortograche ordinarie e prevalenti nella lingua di destinazione. Nei suddetti casi bisogna vericare se è possibile stabilire una serie di norme riguardanti la costruzione morfo-sintattica di espressioni nella lingua target. • La scelta delle varianti lessicali: a seconda della lingua un termine medico potrebbe essere puramente greco-latino (ad esempio diabetes mellitus), ibrido, puramente nazionale (ad esempio stomach ache). In tali casi è necessario accertarsi se ci sono delle regole generali (per la scelta della variante lessicale) o aree semantiche dove la pratica impone l'uso di una certa variante lessicale. 2.5.2 Tradurre SNOMED CT 50 Scendendo più nel dettaglio, tra i principi linguistici specici vanno considerati i seguenti aspetti: • Nomi di organismi (batteri, virus, piante, animali, ecc.): a meno che non entri chiaramente in conitto con la politica linguistica nazionale, i nomi degli organismi devono essere considerati come termini scientici universali (internazionali). La gerarchia Organism fa uso dei nomi in- 18 ternazionali tassonomici • ; Denominazioni chimiche e biochimiche, ingredienti di farmaci, enzimi e nomi di ormoni: un termine che si riferisce ad una sostanza chi- mica contenuta in un farmaco può essere un nome di un determinato ingrediente (appartenente alla gerarchia PRODUCT ) o una denominazione generica per la sostanza stessa chimica (appartenente alla gerarchia SUBSTANCE). È comune nella lingua di destinazione applicare diversi principi ortograci per i PRODUCT rispettivamente alle SUBSTANCE. È bene inoltre vericare se ci sono delle regole o abitudini che dovrebbero essere prese in considerazione nella lingua target per quanto riguarda l'ortograa delle sostanze chimiche e di agenti biochimici, ingredienti, enzimi o ormoni; • Parole straniere e abbreviazioni: le linee guida nazionali di traduzione devono indicare la misura in cui le parole straniere sono accettabili nella lingua di destinazione: le parole straniere che vengono accettate devono essere conformi alle norme ortograche del linguaggio originale (ad esempio gli accenti nelle parole francesi). Per quanto riguarda invece acronimi e sigle, esse danno luogo in genere 19 a una serie di dubbi : pertanto il numero delle sigle ammesse nella terminologia dovrebbe essere mantenuto allo stretto minimo necessario; • Eponimi 20 : il problema nel LSP (Language for Specic Purposes) medico è che alcuni termini possono essere utilizzati solo in aree geograche ristrette: tuttavia a volte essi possono essere accettati al ne di rendere la terminologia psicologicamente accettabile dal punto di vista clinico. I traduttori dovrebbero essere consapevoli della necessità di vericare se un determinato eponimo nella lingua di partenza è usato anche nella lingua di destinazione e se riette adeguatamente lo stesso concetto; 18 In riferimento ai Taxonomy resources della home page del NCBI 19 Ad esempio l'acronimo AIDS ha un corrispettivo acronimo francese e spagnolo diverso: SIDA 20 Un eponimo è un personaggio che dà il suo nome, nel caso della medicina, a sindromi, malattie, segni clinici, metodiche diagnostiche e terapie 2.5.2 Tradurre SNOMED CT • 51 21 Forma determinata versus forma nuda : nella maggior parte dei ter- mini e delle espressioni in SNOMED CT i sostantivi sono presenti nella loro forma nuda. Comunque sia a volte l'articolo determinativo è utilizzato in connessione con i concetti di cui vi è uno solo per tipo (ad esempio in alcuni concetti Body structure, come the stomach). È necessario dunque vericare se ci sono delle regole generali riguardo l'uso di forme determinate/nude che dovrebbero essere prese in considerazione nella terminologia della lingua target, o particolari convenzioni che dovrebbe prevalere nei termini tradotti • 22 ; Plurale versus singolare: in generale né i Fully Specied Names né i Preferred Terms dovrebbero essere rappresentati al plurale, a meno che i termini non rappresentino concetti raggruppati (ad esempio procedures 23 relating to eating and drinking ) . Bisogna dunque capire se l'uso del plurale è assolutamente necessario al ne di trasmettere il signicato del concetto; • Lettere minuscole versus maiuscole: in generale tutti i termini dovrebbero usare le lettere minuscole 24 . Bisogna ad ogni modo seguire anche le regole della lingua target per quanto riguarda l'uso delle lettere minuscole rispetto alle maiuscole, e indagare se ci sono ragioni speciche per cui un concetto particolare dovrebbe iniziare con/comprendere le lettere maiuscole o minuscole; • Punteggiatura, segni tipograci, simboli e cifre: Virgole e trattini: sono utilizzati in SNOMED CT per aggiun- gere informazioni supplementari a un termine (ad esempio well child visit, newborn). Le virgole sono utilizzate anche in lingua inglese per accorciare termini SNOMED e/o per costruire termini nei quali la caratteristica più importante è presentata alla testa della frase (ad esempio: fracture, closed, comminuted, with displacement); Barre: vengono utilizzati per indicare la o (congiunzione con valore disgiuntivo). Ad esempio: T2b (IIB): Fallopian tube/ovarian tumor with extension to other pelvic structures; 21 Rispettivamente si riferiscono ad un sostantivo con o senza articolo determinativo 22 Questo tema è attualmente in discussione presso i modellisti di SNOMED CT: in futuro la forma determinata sarà abbandonata, ove possibile 23 Anche questi concetti sono in procinto di essere cambiati 24 Secondo la terminologia ISO Standard 704, la lettera minuscola nella prima parola del termine è raccomandata, a meno che non si tratti di un eponimo, un termine scientico universale, o un nome proprio: ad es. Behçets syndrome, ECG nding, blood group A 2.5.3 Sorgenti di informazione Parentesi e due punti: 52 sono spesso utilizzati in SNOMED CT per aggiungere informazioni semantiche ai concetti o accorciare termini. Ad esempio: FH: cardiac disorder (dove FH sta per family history ); • Abbreviazioni e unità di misura: per quanto riguarda le abbreviazioni, è probabile che nella lingua di destinazione ci siano acronimi locali accettabili. In generale bisogna essere molto cauti e ammettere solo quelli ampiamente utilizzati. Per le unità di misura invece è bene rispettare le linee guida dell' International System of Units; • Trattini: può essere utile nella lingua di destinazione inserire un trattino in: Forme ibride e combinate; Composti contenenti un eponimo o una parola straniera, o in particolare composti lunghi: ad esempio pathological - anatomical analysis; In connessione con le parole che contengono abbreviazioni, lettere o segni: ad esempio DNA(-)molecule; In connessione con alcuni pressi: ad esempio non(-)infectious. Bisogna in ogni modo vericare se ci sono norme riguardanti l'uso dei trattini nella lingua target sucientemente chiare e/o devono essere stabilite linee guida speciche. 2.5.3 Sorgenti di informazione Fonti di riferimento valide e approvate dovrebbero essere a disposizione dei traduttori, per consentire la ricerca di informazioni su concetti specici attraverso esempi testuali, denizioni e spiegazioni. Tali riferimenti possono essere di vario tipo: • Riferimenti disponibili in formato elettronico: consentono l'accesso a: Termini già approvati e tradotti: che contengono costruzioni e/o combinazioni di parole simili; Documenti interni: come le linee guida nazionali per la traduzione, la panoramica delle decisioni dell' Editorial Board e gli elenchi di esempi di termini tradotti e/o termini corretti che rappresentano specici problemi semantici o morfo-sintattici; 2.5.4 Processo di traduzione e problemi del post-traduzione Libri di testo: 53 che riguardano i domini e le aree della pratica clinica; File o libri di riferimento: che rappresentano versioni nazionali di 25 dizionari medici ; Articoli medici: reperibili in versioni elettroniche di riviste mediche di fama nazionale. • Riferimenti ad internet: tra cui link alle varie tassonomie autorevoli o nomenclature 2.5.4 26 . Processo di traduzione e problemi del post-traduzione Il processo di traduzione richiede diverse fasi: 1. Translation: ci devono essere sempre almeno due persone coinvolte nella traduzione iniziale: un traduttore e un proof-reader 27 per la verica. È fondamentale che essi abbiano competenze di elevato livello linguistico ed una buona conoscenza nel settore dell'assistenza sanitaria. I loro ruoli sono: • Tradurre i termini della lingua di origine in termini della lingua target; • Correggere le bozze dei termini tradotti prima di passarli a ulteriori riesami; • Sollevare eventualmente questioni dubbie in modo che le principali decisioni siano prese dall' Editorial Board. 2. Review : a prescindere dalla correzione di bozze, una seria revisione deve essere eettuata dai professionisti di servizi sanitari e sociali. Essi devono confermare che i termini tradotti riettano i concetti di base e che siano conformi agli orientamenti linguistici e alle regole generali della lingua target. Possono inoltre mandare indietro i termini inac- cettabili ai traduttori per la correzione e consultare l' Editorial Board su questioni dubbie. 25 Ad esempio la versione nazionale della Nomenclatura Chimica, o della Nomencatura Anatomica, ecc. 26 Ad esempio www.genenames.org per l'elenco di geni umani, www.iupac.org per i nomi delle sostanze di laboratorio e delle procedure, ecc. 27 Correttore di bozze 2.5.4 Processo di traduzione e problemi del post-traduzione 54 3. Editing : l' Editorial Board dovrebbe essere composto da un team interdisciplinare di professionisti - all'interno di settori quali la medicina e infermieristica, la linguistica e la terminologia, la scienza o le tecnologie dell'informazione, le specialità paramediche ecc - che hanno una buona conoscenza e comprensione della lingua inglese di base. Essi devono: • Denire e mantenere le linee guida a cui tutti coloro che sono coinvolti nel processo di traduzione devono aderire; • Determinare la validità dei libri di testo e riferimenti messi a disposizione di traduttori e revisori; • Garantire che tutti i partecipanti siano costantemente informati delle decisioni prese; • Agire come un organo consultivo per i traduttori e i revisori; • Creare ed evolvere le decisioni di massima, che saranno inevitabilmente richieste nel corso della traduzione; • Trattare con traduzioni particolarmente complesse e questioni sollevate dai traduttori e revisori; • Approvare i termini che soddisfano i requisiti; • Raccogliere e registrare gli errori e i quesiti correlati riguardanti il contenuto del core di SNOMED CT, da sottoporre alla IHTSDO. 4. Monitoraggio dei progressi: un responsabile di progetto e/o coordinatore deve eettuare una valutazione continua del progresso di traduzione, deve amministrare il progetto generale e vigilare su di esso. Tra i principali problemi del post-traduzione, vi sono: • Il rischio che i traduttori e i revisori possano avere frainteso il termine della lingua originale; • Il rischio che un determinato termine, comunque corretto, non sia accettabile per i medici che magari hanno l'abitudine di usare altri termini per esprimere lo stesso concetto. In questo contesto, la validazione clinica dei termini tradotti svolge un ruolo importante: la convalida deve essere eettuata da medici su sottoinsiemi di concetti relativi alla propria specializzazione. È necessaria inoltre una politica in materia di mantenimento della terminologia nella lingua target e di feedback con la IHTSDO: può darsi che alcuni dei termini nazionali e concetti che vengono aggiunti nell' estensione della lingua target siano tradotti in inglese, al ne di essere inclusi nel SNOMED CT Core. 2.5.5 Esperienze di alcuni release centre translating 2.5.5 55 Esperienze di alcuni release centre translating Lo studio sulle esperienze danesi e svedesi 28 in merito alla traduzione di SNOMED CT nella propria lingua ha portato ai seguenti risultati, utili per chi sia in procinto di avviare la nazionalizzazione di SNOMED CT: • La Danimarca: Ha impiegato un certo numero di risorse umane così spartite: 1012 traduttori professionisti, 10-12 revisori, 12 in redazione, 4-6 nella gestione del progetto; La traduzione e revisione ha coinvolto circa 10.000 concetti al mese; Il tempo necessario per la traduzione è stato di circa 2 minuti per concetto, per la revisione lo stesso; In redazione invece sono servite 12.800 ore all' anno a cura dell' Editorial Board e 1.400 ore all' anno per terminologi. La principale lezione che hanno appreso da tale esperienza è che sarebbe stato meglio iniziare la traduzione dalle dening relationships. • la Svezia: Ha impiegato 37 risorse umane nel usso di lavoro: 15 traduttori 29 (società di traduzione), 15 controllori della qualità , 7 membri del comitato di redazione (traduttori, terminologi, medici); Sono serviti due anni (dal 2007 al 2009) per approvare solo 130.000 preferred terms 30 . Tra le principali lezioni apprese vi sono: La necessità di una maggiore formazione per tutti i partecipanti su SNOMED CT, sulla traduzione concept-base, sulle linee guida linguistiche e su applicazioni software; La necessità di includere diverse competenze (medici e terminologi) nell' Editorial Board, organizzarli in piccoli gruppi e dividere i compiti e le responsabilità. 28 Relative al 2009 29 Medici alle dipendenze del National Board of Health and Welfare 30 Contavano di concludere per il 2010 2.5.5 Esperienze di alcuni release centre translating 56 In denitiva si può concludere che le risorse umane necessarie per un processo di traduzione di SNOMED CT sono circa 30-40 persone, per completare la nazionalizzazione in 2/3 anni. 2.6 Considerazioni sulla struttura e tecnologia di SNOMED CT 2.6 57 Considerazioni sulla struttura e tecnologia di SNOMED CT La struttura e la tecnologia che stanno dietro SNOMED CT consente alle organizzazioni di implementarlo e integrarlo nei loro processi e applicazioni clinici e aziendali. SNOMED CT ore inoltre funzionalità aggiuntive per facilitare la personalizzazione di una applicazione per soddisfare le particolari esigenze di un'organizzazione. La struttura dati sommaria è rappresentata in gura 2.14, e spiegata nel dettaglio nei prossimi paragra. SNOMED CT è distribuito come un insieme di le di testo delimitati da Figure 2.14: SNOMED CT Data Structure Summary tag, rappresentati secondo la specica della codica Unicode UTF-8. Alcuni 31 di questi les sono obbligatori per tutti i terminology servers SNOMED (le Core Structure e i Subset Mechanisms); altri sono necessari per supportare il mapping alle classicazioni e agli altri schemi di codica (le Cross Mapping Tables); altri ancora sono necessari per sostenere i servizi di controllo della versione (le History Tables); inne vi sono dei le di valore aggiunto (le Word 31 Software che forniscono una vasta gamma di servizi collegati alla terminologia 2.6.1 Tabelle 58 and Phrase Search Tables, le Canonical Table). Uno dei primi passi nella rappresentazione delle risorse SNOMED CT è quello di decidere in che modo tali risorse saranno memorizzate e accessibili: le opzioni includono l'uso di un database relazionale, un database ad oggetti o di una struttura le proprietaria. È possibile importare i le distribuiti direttamente in uno schema di database e utilizzarlo come risorsa SNOMED CT al centro di un terminology server, il quale dovrebbe essere in grado di importare i le di distribuzione SNOMED CT nella forma interna utilizzata per memorizare la risorsa. Il processo di importazione dovrebbe importarei i le di base (Concepts, Descriptions, and Relationships) e un selezionato insieme di Subsets . 2.6.1 Tabelle Le tre tabelle Concepts table, Descriptions table, e Relationships table sono comunemente denominate Core tables (gura 2.15). L'associazione di una serie di Descriptions e un insieme di Relationships con ogni Concept viene implementato utilizzando il ConceptID, che è la chiave primaria o esterna nelle tre tabelle. Nel dettaglio: Figure 2.15: Core tables di SNOMED CT • Concepts Table: contiene tutti i concetti SNOMED CT. Ogni concetto è rappresentato da una riga della tabella, e ogni riga della Concepts Table contiene i seguenti campi: ConceptIDs: è la chiave primaria della Concepts Table; SNOMEDID e CTV3ID: gli originali identicativi rispettivamente in SNOMED RT e CTV3 32 Vedere paragrafo 2.2 32 per ogni concetto che ha avuto origine 2.6.2 History Mechanism 59 in tali terminologie; FullySpeciedName 33 : viene visualizzato sia nella Concepts Table che nella Descriptions Table; ConceptStatus: indica se un concetto è in uso (attivo) o è stato ritirato: in tal modo, i dati codicati con questi concetti sono adeguatamente accessibili e possono essere recuperati anche molto tempo dopo che sono stati codicati; IsPrimitive: indica se o no un concetto è stato contrassegnato come primitivo (atomico) durante il processo di modellazione. Questa opzione può essere utile in applicazioni avanzate che sfruttano le caratteristiche di logica descrittiva di SNOMED CT • 34 . Descriptions Table: contiene i termini utilizzati per descrivere un concetto SNOMED CT. Comprende i seguenti campi: DescriptionID: chiave primaria di questa tabella; DescriptionType: indica se la descrizione è un Fully Specied 35 Name (FSN), un Preferred Term o un Synonym ; LanguageCode: associa ogni descrizione ad una determinata lingua o dialetto; • Relationships Table: contiene le relazioni tra i concetti SNOMED CT. Una relazione in tabella è memorizzata come una combinazione di tre concetti nell'ordine: ConceptID1 - RelationshipType - ConceptID2, sfruttando i seguenti campi: RelationshipID: identica in modo univoco ogni set di tre concetti in una relationship, e serve come chiave primaria della tabella; ConceptID1 : il primo concetto nella relationship; RelationshipType: il tipo di relationship che esiste tra i due concetti; 2.6.2 ConceptID2 : il concetto target nella relationship. History Mechanism Il contenuto di SNOMED CT evolve con ogni release. L' History Mechanism tiene conto di questo e coinvolge le seguenti tabelle: 33 Vedere paragrafo 2.4.2 34 Vedere paragrafo 1.3 35 Vedere paragrafo 2.4.2 2.6.3 Subset Mechanism • Component History Table: 60 include le eventuali modiche ai compo- nenti SNOMED CT (Concepts, Descriptions, Subsets, Cross Maps); • Component History References Table: fornisce un riferimento da un componente inattivo SNOMED CT a un componente attivo nella release in corso. 2.6.3 Subset Mechanism Un Subset si riferisce ad un insieme di Concepts, Descriptions o Relationships che sono appropriati per una particolare lingua, dialetto, paese, organizzazione, utente o contesto. Il Subset Mechanism può essere utilizzato per ricavare le tabelle che contengono solo una parte di SNOMED CT: è costituito da un elenco di identicatori SNOMED (SCTIDs), dove ogni SCTID si riferisce a un componente di SNOMED CT che è un membro del Subset (chiamato Subset Member ). Per analogia, si può pensare a SNOMED CT come un libro: un Subset è come una voce di indice che punta ad una serie di pagine relative a un particolare argomento. I Subsets vengono rilasciati con due tabelle: • Subsets Table: ogni riga della tabella descrive una release di un Subset; • Subset Members Table: ogni riga della tabella rappresenta un membro di un Subset (un Concept o una Description). 2.6.4 Cross Mapping Mechanism Il meccanismo del Cross mapping consente a SNOMED CT di riferirsi eettivamente ad altre terminologie e classicazioni. Ogni cross map collega un concetto SNOMED CT con un altro schema di codica, chiamato schema target. La struttura SNOMED CT a sostegno del Cross mapping contiene tre tabelle: • Cross Map Sets Table: ogni riga della tabella rappresenta uno schema target per la quale sono disponibili Cross maps; • Cross Maps Table: ogni riga della tabella rappresenta una opzione per la mappatura di un SNOMED CT concept a un codice target o a una serie di codici nello schema target; • Cross Map Targets Table: ogni riga della tabella rappresenta un codice o una serie di codici del sistema target, che fornisce una mappatura per uno o più SNOMED CT concepts. 2.6.5 Extensions 2.6.5 61 Extensions Il meccanismo di Extensions consente alle aziende autorizzate di aggiungere Concepts, Descriptions, Relationships e Subsets al core (contenuto centrale) della SNOMED CT International Release, ad esempio per aggiungere la terminologia specializzata necessaria ad un' organizzazione. 2.6.6 Applicazioni e servizi SNOMED CT SNOMED Clinical Terms può ricoprire molti ruoli nelle applicazioni software per l'assistenza sanitaria. La IHTSDO fornisce contenuti che possono essere caricati in queste applicazioni, ma non fornisce alcun software. I requisiti dettagliati per l'integrazione di SNOMED CT in una particolare applicazione dipendono dagli usi che se ne vuole fare, dalla percezioni degli utenti e dagli ambienti tecnici in cui l'applicazione è implementata. Tra le possibili applicazioni vi sono: • Sistemi di cartelle cliniche abilitate SNOMED CT : che incorporano immissione di dati clinici, supporto alle decisioni, collegamenti a basi di conoscenza, analisi sosticate, interfacce per messaggi di segnalazione, supporto per record di comunicazione o di condivisione, ecc.; • Data warehouses: che memorizzano e analizzano record espressi con concetti codicati SNOMED CT; • Sistemi dipartimentali diagnostici: che inviano reports che includono concetti codicati SNOMED CT ad altri sistemi; • Dispositivi di raccolta dei dati: gestiti manualmente e utilizzati per l'ingresso di una gamma limitata di concetti codicati, usati frequentemente; • Sistemi di supporto decisionale: che usano concetti SNOMED CT per rappresentare linee guida e protocolli per la distribuzione ad altri sistemi; • Sistemi per creazione di query : per l'analisi di dati detenuti da altri sistemi, alcuni dei quali contengono dati codicati SNOMED CT; • Sistemi di codica: che mappano i concetti codicati SNOMED CT (inseriti manualmente o letti da un record elettronico), con classicazioni 36 come ICD10 ; 36 Classicazione internazionale delle malattie e dei problemi correlati 2.6.6 Applicazioni e servizi SNOMED CT • 62 Sistemi per supportare la progettazione/realizzazione di messaggi: che veicolano informazioni speciche, utilizzando un set specicato di identicatori di concetti SNOMED CT. Chapter 3 ROME 3.1 Panoramica 1 ROME è una ontologia italiana, sviluppata negli ultimi anni dal CNR . L'acronimo signica Reference Ontology in Medicine: una reference ontology 2 è uno strato intermedio tra le ontologie top-level e le ontologie di dominio . È stata progettata per fare da ponte tra più sistemi specici, per garantire la coerenza semantica per i sistemi di informazioni eterogenei che possono essere applicati al settore sanitario. È composta da circa 200 entità generali, e si basa sulla ontologia fon- 3 dazionale DOLCE da cui eredita la distinzione fondamentale tra entità en- duranti e perduranti: • Enduranti: entità che, nel momento in cui sono presenti, sono interamente presenti, nel senso che tutte le loro parti proprie sono presenti (ad esempio un dispositivo medico); • Perduranti: entità che si prolungano nel tempo accumulando diverse parti temporali: perciò in qualsiasi momento sono presenti, alcune delle loro parti temporali (come le loro fasi precedenti o future) possono essere non presenti (ad esempio una visita specialistica). 4 ROME è scritta in OWL e può essere sfogliata da strumenti come Protégé . Le fonti principali per la sua costruzione sono state: 1 L' ultima pubblicazione disponibile di ROME è relativa al 2007 2 Vedere paragrafo 1.1.2 3 Descriptive Ontology for Linguistic and Cognitive Engineering 4 Ambiente di sviluppo per ontologie. Vedere paragrafo 3.2 63 3.1 Panoramica • 64 La UMLS Semantic Network: è un componente dell' Unied Medical 5 Language System (UMLS) e consiste in una serie di categorie e re- lazioni che vengono utilizzate per classicare le voci della banca dati centrale di UMLS; • I termini topmost del Foundational Model of Anatomy (FMA): si tratta di una ontologia di dominio che rappresenta un insieme coerente di conoscenze riguardanti l' anatomia umana. 5 Compendio di molti vocabolari delle scienze biomediche 3.2 Componenti base 3.2 65 Componenti base I componenti base di ROME sono stati esplorati utilizzando Protégé: un ambiente di sviluppo per ontologie. Aprendo il le OWL di ROME con Protégé, viene visualizzato il workspace principale, che mostra un overview dell'ontologia, incluse le metriche sui suoi contenuti e le annotazioni circa l'intera ontologia (gura 3.1). Figure 3.1: Protégé: workspace principale di ROME 3.2 Componenti base 66 Il tab Entities è l'ambiente principale dell'editor: da questa locazione è possibile esplorare tutte le classi, proprietà e individui dell'ontologia. Questo modello di selezione è globale: quando una classe, proprietà o individuo è selezionato nell'albero sul lato sinistro, il pannello destro cambia per mostrare i dettagli della selezione. Così, espandendo la gerarchia sulla sinistra e selezionando una classe o proprietà, sulla destra è visualizzata l'appropriata descrizione: eventuali annotazioni e la descrizione dell'entità (gura 3.2). Figure 3.2: Protégé: tab Entities di ROME 3.2 Componenti base 67 Il tab OWLViz mostra una rappresentazione graca della gerarchia delle classi (gura 3.3) Figure 3.3: Protégé:tab OWLviz di ROME Dall'analisi dell'ontologia sono emersi i seguenti risultati relativi ad alcune 6 metriche generali : • METRIC ONTOLOGY: 282 classes, 19 Object Property, 0 Data Property, 0 individuals; • CLASS AXIOMS: 301 assiomi SubclassOf, 0 assiomi EquivalentClasses e Disjoint Classes. Tutte le classi e le ObjectProperties sono sottoclassi di Thing ; • OBJECT PROPERTY AXIOMS: 0; • DATA PROPERTY AXIOMS: 0; • INDIVIDUAL AXIOMS: 0; 6 Vedere paragrafo 1.2. Per chiarimenti consultare http://www.w3.org/ 3.2.1 Entità principali • 68 7 ANNOTATION AXIOMS: annotationAssertion axioms:19 , annotationPropertyDomain axioms:0, annotationPropertyRahngeOf axioms: 0; Si tratta dunque di un'ontologia molto semplice. 3.2.1 Entità principali Nell'ambito di questa tesi è stato eettuato lo studio delle entità principali di ROME no a 3 livelli di profondità. Di seguito ne è riportata una 8 decrizione, documentata con le immagini tratte da Protégé . Al primo livello vi sono le entità Endurant, Perdurant e Quality (gura 3.4): Figure 3.4: Entità principali in ROME 7 Solo </rdfs:comment> 8 A titolo esemplicativo vengono mostrati solo per Perdurant tre versioni equivalenti della stessa denizione: la descrizione visualizzata da Protégé nel tab Entities, la visualizzazione di Protégé nel tab OWLviz e il codice OWL. Per le altre entità verrà invece riportato solo il graco Protégé del tab OWLviz, per evitare la ridondanza 3.2.1 Entità principali 69 Perdurant La descrizione dell'entità Perdurant è visibile in modo molto intuitivo nella nestra Protégé riportata in gura 3.5. Dalla denizione emerge che la classe Perdurant ha due superclassi: la classe Figure 3.5: Descrizione di Perdurant in Protégé Spatio-temporal-particular, e una classe anonima che rappresenta le entità che possono realizzare solo delle Functions. Tale denizione coincide col seguente codice OWL: <owl:Class rdf:about=http://www.loa-cnr.it/Files/DLPOnts/DOLCE-Lite_397.owl#PERDURANT>9 <rdfs:comment rdf:datatype=http://www.w3.org/2001/XMLSchema#string>Questo è DOL</rdfs:comment> <rdfs:subClassOf> <owl:Restriction> <owl:allValuesFrom rdf:resource=le:/C:/RACER/ROME/R4.owl#FUNCTION/> <owl:onProperty> <owl:ObjectProperty rdf:ID=ACCOMPLISH/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Class rdf:about=`http://www.loa-cnr.it/Files/DLPOnts/DOLCE-Lite_397.owl#SPATIO-TEMPORALPARTICULAR/> </rdfs:subClassOf> </owl:Class> La restrizione owl:allValuesFrom presente nel codice richiede che per ogni istanza della classe che ha delle istanze della specica proprietà, i valori della proprietà devono essere tutti membri appartenenti alla classe indicata nella 9 Riferimento a DOLCE-LITE_397. Vedere paragrafo 4.2.1 3.2.1 Entità principali 70 clausola della owl:allValuesFrom. Questo vuol dire, come già accennato, che per tutti i Perdurants, se realizzano qualcosa, quel qualcosa sono delle Functions. Perdurant ha come glio diretto Process (gura 3.6). Process è suddiviso in processo biologico (ad esempio processo patologico) Figure 3.6: Process in ROME e processo non-biologico (ad esempio, indagine diagnostica). La gura 3.7 mostra questo livello più apporofondito di dettaglio: Figure 3.7: Biologic Process e Non Biologic Process in ROME 3.2.1 Entità principali 71 Endurant I gli principali di Endurant nella gerarchia sono (gura 3.8): Figure 3.8: Endurant in ROME • Function: funzioni biologiche e non biologiche (gura 3.9); Figure 3.9: Function in ROME • Physical endurant: gli enduranti sici possono essere biologici (ad esempio entità anatomiche) o non-biologici (ad esempio i dispositivi)(gura 3.10); • Non-physical endurant: enduranti non sici (gura 3.11). 3.2.1 Entità principali Figure 3.10: Physical endurant in ROME Figure 3.11: Non physical endurant in ROME 72 3.2.1 Entità principali 73 Quality L'entità Quality si riferisce alla qualità astratta di un Endurant. Ad esempio Anomalia di struttura anatomica congenita non rappresenta l'entità anatomiche in sé, ma è la qualità astratta collegata ad essa (gura 3.12). In dettaglio: Figure 3.12: Quality in ROME • Physical quality : (gura 3.13); Figure 3.13: Physical Quality in ROME • Biomedical quality : (gura 3.14); 3.2.1 Entità principali Figure 3.14: Biomedical Quality in ROME 74 3.2.2 Entità materiali e immateriali 3.2.2 75 Entità materiali e immateriali Aspetto peculiare in ROME è il fatto che considera anche le entità immateriali e non tangibili, cioè che non hanno una controparte materiale. Ad esempio i diversi signicati di diagnosi sono rappresentati in ROME nei seguenti modi: 1. Atto di identicare una malattia dai suoi sintomi: classicato come diagnostic investigation → 10 non-biologic process → perdurant; 2. Decisione presa da una diagnosi: classicato come diagnosis mation entity → → infor- non-physical endurant; 3. Breve descrizione tecnica rappresentata in alcune classicazioni: classicato come disease → nosological entity → non-physical endurant; La distinzione basilare tra le entità materiali e non materiali (gura 3.15) è stata adottata dal livello superiore del Foundational Model of Anatomy, secondo cui le Entità materiali possono essere suddivise in: • Strutture anatomiche: ad esempio parti corporee, organi, ecc.; • Sostanze del corpo; • Body topographic entities. Mentre le Entità non materiali che hanno rilevanza anatomica, ma non una controparte materiale, possono essere suddivise in: • Giunzioni 11 , a loro volta suddivise in: Giunzioni bona-de: i conni interni che comportano una discontinuità spaziale (buchi, fessure, feritoie) o eterogeneità qualitativa (di materiale di costituzione). Esse sono classicate in: conuenze, giunzioni tra cavità, raccordi tra le strutture anatomiche e frontiere; • Giunzioni at: sono superci anatomiche convenzionali o linee. Spazi del corpo: suddivisi in lumina, cavità e orizi. Questa caratteristica di ROME è una estensione e ranamento del tipo semantico Body Space o Junction di UMLS-SN 12 . 10 Il simbolo in questo contesto indica la relazione 'IS_A' 11 Conni tra le diverse strutture anatomiche 12 In UMLS-SN questa distinzione collassa in una singola categoria di un gruppo di entità eterogenee, sia materiali (ad esempio, le articolazioni) che non-materiali (ad esempio cavità) 3.2.2 Entità materiali e immateriali Figure 3.15: Non-Material e Material Anatomical Entity in ROME 76 3.2.3 Object properties 3.2.3 77 Object properties Per quanto riguarda invece le Object properties, l'analisi con Protégé ha evidenziato che ve ne sono solo di tipi semplici (non vi sono proprietà 13 funzionali, inverse, transitive ecc. ), e sono tutte glie di TopObjectProperty (senza altre gerarchie intermedie). L'elenco è visualizzato in gura 3.16. Figure 3.16: Object properties in ROME 13 Vedere paragrafo 1.2.1 3.3 Utilizzi 3.3 78 Utilizzi Gli impieghi concreti principali di ROME sono: • La progettazione di ontologie di dominio speciche associate alla Reference Ontology: possono essere considerate come dei plug-in che coprono diversi domini. Ne è un esempio l'ontologia del Mechanical Circulatory Support Systems (MCSS) 14 . L'ontologia è collegata a uno strumento che è in grado di eseguire delle query sia per trovare un modello di macchina dato un insieme di caratteristiche, che per recuperare l'eettiva macchina installata in un determinato reparto o dipartimento. L'ontologia può essere utilizzata per dare consigli a un chirurgo cardiaco che sta cercando il dispositivo ottimale da impiantare in un paziente; • Il supporto alla continuità delle cure: un esempio di questo tipo di impiego si è avuto nell'ambito del progetto e-Heart Failure 15 , per sup- portare la continuità delle cure per pazienti con insucienza cardiaca. Tale progetto ha previsto la progettazione e sviluppo di un ambiente di lavoro cooperativo basato su un Electronic Patient Record (EPR), le cui informazioni cliniche sono classicate ROME. 14 Sistemi di supporto circolatorio meccanici: un particolare tipo di dispositivo mappato in ROME come Endurante sico non biologico 15 Avviato nel 2002 dalla provincia di Trento Chapter 4 Analisi 4.1 Correttezza dell'ontologia Il primo aspetto considerato nell'analisi oggetto della tesi è l'accuratezza delle ontologie. In linea generale, una ontologia high-quality dovrebbe essere modularizzata, con netta separazione tra una ontologia formale toplevel (ad esempio DOLCE), una reference ontology di conoscenza medica condivisa (anatomia, siologia, patologia, procedure mediche, ecc.) e un in- 1 sieme di (sotto)ontologie di dominio delle dierenti specialità mediche . La metodologia d'analisi seguita è stata dierente per le due ontologie in 2 quanto ROME ce l'avevamo a disposizione ; SNOMED no, in quanto l'Italia non ne possiede la licenza. 4.1.1 ROME Da un punto di vista teorico ROME è una reference ontology: si basa sulla ontologia formale DOLCE ed è ben distinta dalle ontologie di dominio. Perciò è una ontologia che soddisfa i canoni di una buona ingegnerizzazione. Tuttavia è stata svolta un'analisi più accurata e dettagliata utilizzando Protégé: lo si è utilizzato per navigare e studiare l'ontologia, ma anche per vericare la soddisfacibilità delle classi ROME sfruttando il suo reasoner (HermiT). Analizzando tutte le entità ROME, sono state individuate le seguenti imprecisioni: • Incompletezza: ROME spesso fornisce solo una parziale istanziazione di certi livelli di dettaglio. Ad esempio, tra i segni clinici generali vi 1 Vedere paragrafo 1.1.2 2 Il le OWL di ROME ci è stato fornito dal CNR 79 4.1.1 ROME 80 sono solo febbre e perdita di peso(gura 4.1). Figure 4.1: ROME: Clinical-sign Lo stesso accade tra i sintomi: ci sono solo angoscia, dolore, e mancanza d'appetito(gura 4.2). Sarebbe preferibile fermarsi ad un livello di dettaglio superiore e la- Figure 4.2: ROME:Symptom sciare la descrizione accurata dell'entità da espandere ad altre ontologie di dominio; oppure, nel momento in cui si scegliesse di scendere ad un certo livello di dettaglio, esplicitarne tutte le entità che lo caratterizzano; 4.1.1 ROME • 81 Poca chiarezza: vi sono relazioni poco chiare. In particolare vi sono 11 diversi tipi di relazioni part of , la cui dierenza non è né intuibile né espicitata (gura 4.3). Tra gli esempi di utilizzi vi è la descrizione di Body Structure: si Figure 4.3: Relazioni part of evince che è una struttura anatomica, è almeno part of_4 di Body System, ed è almeno part of_1 di Organism (gura 4.4), ma la distinzione tra queste due ultime proprietà non è intuibile. Se la distinzione tra tali proprietà è signicativa, sarebbe meglio esplicitarla nei commenti associati; se invece non lo è, sarebbe consigliabile unicare i nomi sotto un'unica proprietà part of . Per classicare l'ontologia invece bisogna aprire il menù Reasoner di Protégé e selezionare uno dei reasoner disponibili. Avviato il reasoner (nel nostro caso HermiT), la gerarchia delle classi nel tab Entities cambia, mostrando 3 la gerarchia delle classi inferita. Le eventuali classi insoddisfacibili 3 Vedere paragrafo 1.3.6 appaiono 4.1.1 ROME 82 Figure 4.4: Esempio di utilizzo delle relazioni part of in rosso sotto la classe Nothing, mentre tutto il resto appare nella gerarchia sotto le loro superclassi inferite. Avviando il reasoner di Protégé, la classicazione di ROME viene fatta senza errori, quindi l'ontologia non presenta classi insoddisfacibili (gura 4.5). 4.1.1 ROME 83 Figure 4.5: Classicazione di ROME svolta col reasoner HermiT di Protégé 4.1.2 SNOMED CT 4.1.2 84 SNOMED CT Per l'analisi della correttezza di SNOMED CT è stata seguita una metodologia dierente rispetto a ROME: partendo dagli errori più comuni e importanti riportati in letteratura, ne è stata eettuata una verica puntuale sfruttando dei browser consultabili gratuitamente su internet gare l'ontologia. 4 che permettono di navi- In questo modo si è trovato riscontro di esempi concreti di problemi ontologici di SNOMED in riferimento a DOLCE come ontologia formale top-level, e si è anche constatato che molti errori sono stati corretti 5 nelle ultime release . Nel dettaglio, l'analisi della struttura di SNOMED CT ha rivelato una serie di errori ontologici e di ingegneria della conoscenza. I più importanti sono descritti di seguito e documentati con le immagini tratte dai suddetti 6 browser : • Uso comune di ereditarietà multipla, con errori frequenti di sussunzione: ad esempio bevanda alcolica, tramite il suo genitore alcool ingestibile (gura 4.6), è sussunto da alcool etilico e da sostanza di abuso (gura 4.7). Da un punto di vista losoco nessuna di queste sussunzioni è vera: le bevande alcoliche contengono alcol etilico che svolge un ruolo di sostanza di abuso (per quanto riguarda gli esseri umani); 4 http://snomed.dataline.co.uk, http://terminology.vetmed.vt.edu/default.htm 5 SNOMED CT è continuamente soggetto a cambiamenti, modiche e integrazioni grazie alla collaborazione internazionale dei stati membri della HITSDO 6 I concetti oggetto dello studio sono visualizzati in neretto al centro, invece i loro genitori sono indicati in rosso 4.1.2 SNOMED CT Figure 4.6: Bevanda alcolica in SNOMED CT 85 4.1.2 SNOMED CT Figure 4.7: Alcool ingestibile in SNOMED CT 86 4.1.2 SNOMED CT • 87 7 Mancanza di mereologia esatta per l'anatomia : è dicile immaginare che un oggetto possa essere una parte corretta di due regioni che sono mereologicamente scollegate. Ad esempio struttura del nervo tibiale è direttamente sussunto sia da parte della coscia (parte superiore dell'arto inferiore) che da struttura della gamba (parte inferiore dell'arto inferiore)(gura 4.8); Figure 4.8: Struttura del nervo tibiale in SNOMED CT • Errori nella gerarchia: la gerarchia a volte viola le regole delle basi dell' ingegneria ontologica, mostrando una classicazione incoerente con DOLCE. Ad esempio fumatore è sussunto dal comportamento del fumare il tabacco(gura 4.9). DOLCE invece distingue chiaramente tra un ruolo e l'agente che svolge il ruolo; 7 Per mereologia si intende lo studio delle relazioni tra le parti e il tutto 4.1.2 SNOMED CT 88 Figure 4.9: Fumatore in SNOMED CT • Omissione di relazioni apparentemente ovvie: ad esempio labbra screpolate è glio di constatazione dell'aspetto del labbro (gura 4.10); anche labbro leporino, in quanto malattia che deforma il labbro, dovrebbe essere collegato a constatazione dell'aspetto del labbro: invece non lo è (gura 4.11). Di certo non ci si può aspettare che una terminologia di grandi dimensioni sia completa. Tuttavia, tali omissioni hanno la conseguenza che molte inferenze non possono essere fatte correttamente; 4.1.2 SNOMED CT Figure 4.10: Labbra screpolate in SNOMED CT Figure 4.11: Labbro leporino in SNOMED CT 89 4.1.2 SNOMED CT • 90 La gerarchia viola a volte il pensiero medico e le conoscenze in campo biomedico. Ad esempio disease (condizione anormale di un organismo), è sussunto da clinical nding (risultato di osservazioni cliniche): questo non è propriamente corretto dal punto di vista medico, in quanto si tratta di concetti medici mutuamente disgiunti (gura 4.12). Figure 4.12: Disease in SNOMED CT Gli errori ontologici sono probabilmente causati dal fatto che SNOMED CT è stato sviluppato dando la massima priorità alle esigenze dei clinici, vale a dire trovare facilmente i concetti oggetto della loro ricerca. Le occorrenze frequenti di questi errori possono creare problemi alla razionalità del ragionamento automatico. Tuttavia SNOMED è in continua evoluzione, e si può condare in una continua correzione di questi errori grazie alla collaborazione internazionale di cui gode. 4.2 Espressività 4.2 91 Espressività Il secondo aspetto dell'analisi riguarda una valutazione dell'espressività delle due ontologie. Esse sono espresse utilizzando diversi proli della famiglia dei linguaggi OWL. Come descritto approfonditamente nel paragrafo 1.2, OWL è il linguaggio ontologico per il web, raccomandato dalla W3C, attualmente alla versione 2: ha le sue radici nelle logiche decsrittive (DL). Come si è approfondito nel paragrafo 1.3, le DL sono delle famiglie di formalismi per la rappresentazione strutturata della conoscenza: ne esistono diversi tipi, ognuno caratterizzato dalla presenza di diversi costrutti, quindi da dierenti livelli di espressività e di complessità. Ciò che si vorrebbe idealmente in un linguaggio è una elevata espressività e una bassa complessità computazionale: in realtà questo non è possibile perché all'aumentare dell'espressività del linguaggio in genere aumenta anche la complessità computazionale, perciò ci si accontenta di raggiungere un buon trade-o tra le due. L'obbiettivo delle prossime sezioni sezione è determinare quale delle due ontologie raggiunge il miglior trade-o. 4.2.1 ROME Dalla dichiarazione dei namespace in ROME si evince che esso utilizza al suo interno elementi di OWL (relativi all'ultima versione, quindi OWL2) ed elementi di DOLCE-Lite 397: xmlns:owl=http://www.w3.org/2002/07/owl# xmlns:dol=http://www.loa-cnr.it/Files/DLPOnts/DOLCE-Lite_397.owl# A sua volte DOLCE-Lite 397 include nell dichiarazione dei namespace un riferimento alla ontologia DOLCE-Lite: xmlns:dol=http://www.loa-cnr.it/ontologies/DOLCE-Lite# Pertanto su ROME è stata svolta un'analisi esaustiva (utilizzando Protégé) dei costrutti OWL eettivamente impiegati nella denizione delle sue entità. Per le entità usate in ROME ma denite in DOLCE-Lite 397 e DOLCELite si è andati ad analizzarne la denizione originaria. Trovati quindi tutti i costrutti OWL eettivamente impiegati in ROME, ne è stata individuata la corrispondenza con gli operatori delle DL, e in denitiva si è giunti alla individuazione della specica DL in cui ROME è espressa. Di seguito è riportato in dettaglio il risultato di tale analisi. 4.2.1 ROME 92 DL secondoProtégé La DL di ROME, indicata sul workspace principale di Protégé, è (gura 4.13). In dettaglio la DL ALE 8 è composta dalle seguenti DL : Figure 4.13: DL di ROME secondo Protégé • AL: • E: corrisponde agli operatori: Negazione atomica; Intersezione di concetti; Restrizione universale; Quanticatore esistenziale limitato. corrisponde all'operatore quanticatore esistenziale completo. Invece la DL di DOLCE-Lite 397 è SHIF (gura 4.14). In dettaglio essa è composta dalle seguenti DL: Figure 4.14: DL di DOLCE-Lite 397 secondo Protégé • S: corrisponde alla DL • H: gerarchie tra ruoli; • I: ALC 9 , con l'aggiunta di ruoli transitivi; proprietà inversa; 8 Per ulteriori dettagli vedere il paragrafo 1.3.2 9 La DL C introduce la negazione di concetti complessi ALE 4.2.1 ROME • F: 93 proprietà funzionale. Inne, la DL di DOLCE-Lite è SHI (gura 4.15). Si può notare che gli operatori della DL ALE sono già presenti nella Figure 4.15: DL di DOLCE-Lite secondo Protégé SHI , SHIF . DL che a sua volta può essere considerata un sottoinsieme della DL Il fulcro dell'analisi pertanto è stato individuare quali operatori della DL SHIF sono realmente utilizzati in ROME. Analisi di DOLCE-Lite 397 Le entità ROME le cui denizioni fanno riferimento alla ontologia di più alto livello DOLCE-Lite 397 sono: Endurant; Non-Physical-Endurant; Physical-Endurant; Physical Quality; Quality; Perdurant; Spatio-TemporalParticular. Iniziando l'analisi da Endurant, ricordiamo che essa è una delle classi di livello superiore in ROME (gura 4.16). La sua denizione OWL è la seguente: Figure 4.16: Endurant in ROME 4.2.1 ROME 94 <owl:Class rdf:about=&dol;ENDURANT> <rdfs:subClassOf rdf:resource=&dol;SPATIO-TEMPORAL-PARTICULAR/> <rdfs:comment rdf:datatype=&xsd;string>Questo è DOL</rdfs:comment> </owl:Class> Considerando che &dol è il simbolo utilizzato al posto di http://www.loacnr.it/Files/DLPOnts/DOLCE-Lite_397.owl 10 , segue che la denizione ori- ginale di Endurant va cercata in DOLCE-Lite 397. Pertanto, la descrizione di Endurant in DOLCE-Lite 397, secondo la visualizzazione di Protégé, è riportata in gura 4.17. Tale descrizione coincide con la denizione OWL: Figure 4.17: Endurant in DOLCE-Lite 397 10 Denizione inserita nel namespace, il cui codice è riportato all'inizio del paragrafo 4.2.1 4.2.1 ROME 95 <owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#endurant> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#participant-in/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#perdurant/> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#quality/> </owl:disjointWith> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#specic-constant-constituent/> </owl:onProperty> <owl:allValuesFrom rdf:resource=http://www.loa-cnr.it/ontologies/DOLCE-Lite#endurant/> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource=http://www.loa-cnr.it/ontologies/DOLCE-Lite#abstract/> <rdfs:subClassOf> <owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#spatio-temporal-particular/> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:allValuesFrom rdf:resource=http://www.loa-cnr.it/ontologies/DOLCE-Lite#endurant/> <owl:onProperty> <owl:ObjectProperty rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#part/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <rdfs:comment rdf:datatype=http://www.w3.org/2001/XMLSchema#string >The main characteristic of endurants is that all of them are independent essential wholes. This does not mean that the corresponding property (being an endurant) carries proper unity, since there is no common unity criterion for endurants. Endurants can 'genuinely' change in time, in the sense that the very same endurant as a whole can have incompatible properties at dierent times. To see this, suppose that an endurant - say 'this paper' - has a property at a time t 'it's white', and a dierent, incompatible property at time t' 'it's 4.2.1 ROME 96 yellow': in both cases we refer to the whole object, without picking up any particular part of it. Within endurants, we distinguish between physical and non-physical endurants, according to whether they have direct spatial qualities. Within physical endurants, we distinguish between amounts of matter, objects, and features.</rdfs:comment> <owl:disjointWith> <owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#perdurant/> </owl:disjointWith> </owl:Class> Analizzando tutti i costrutti presenti in tale denizione, sono stati individuati i corrispondenti operatori delle DL. Nel dettaglio: • Il costrutto OWL <owl:someValuesFrom>, visualizzato in Protégé come SOME (gura 4.17), corrisponde in DL al quanticatore esistenziale completo • ∃R.C, quindi alla DL E; Il costrutto OWL <owl:allValuesFrom>, visualizzato in Protégé come ONLY (gura 4.17), corrisponde in DL al quanticatore universale ∀R.C, • quindi alla DL AL; Il costrutto OWL <owl:disjointWith>, visualizzato in Protégé come DISJOINT CLASSE (gura 4.17), è esprimibile in DL con la combinazione del costrutto di inclusione terminologici 11 ) e di negazione ¬, v (utilizzato per formare assiomi quindi alla DL C; Prodeguendo con l'analisi, si è andati a cercare la denizione OWL della superclasse anonima di Endurant: Particular and (endurant or perdurant or quality), classe equivalente a Spatio-temporal-particular. La sua denizione è la seguente: <owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#spatio-temporal-particular> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType=Collection> <owl:Class> <owl:unionOf rdf:parseType=Collection> <owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#endurant/> <owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#perdurant/> <owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#quality/> </owl:unionOf> 11 Vedere paragrafo 1.3.4 4.2.1 ROME 97 </owl:Class> <owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#particular/> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> <rdfs:comment rdf:datatype=http://www.w3.org/2001/XMLSchema#string >Dummy class for optimizing some property universes. It includes all entities that are not reications of universals ('abstracts'), i.e. those entities that are in space-time.</rdfs:comment> </owl:Class> Dal codice appena riportato risulta che i nuovi costrutti OWL utilizzati sono: • Il costrutto OWL <owl:intersectionOf>, visualizzato in Protégé come AND (gura 4.17), corrisponde all'operatore intersezione di concetti quindi alla DL • u, AL; Il costrutto OWL <owl:unionOf>, visualizzato in Protégé come OR(gura 4.17), corrisponde all'operatore di disgiunzione t, quindi alla DL U. Dato che nella denizione di Endurant (ma anche nella denizione di altre entità o proprietà come Participant-In, Perdurant, Quality, Specic-ConstantConstituent, Abstract, Spatio-Temporal-Particular, Part) sono presenti dei 12 riferimenti a DOLCE-Lite , è stato necessario andare ad analizzare anche la denizione di queste entità in DOLCE-Lite. Analisi di DOLCE-Lite Iniziando dalla denizione di Endurant in DOLCE-Lite, si è potuto notare che essa coincide con quella in DOLCE-Lite 397. Si è andati dunque avanti guardando alla denizione di Participant-In. La sua denizione OWL è la seguente: <! Object property: http://www.loa-cnr.it/ontologies/DOLCE-Lite.owl#participant-in > <owl:ObjectProperty rdf:about=#participant-in> <rdfs:subPropertyOf> <owl:ObjectProperty rdf:about=#immediate-relation-i"/> </rdfs:subPropertyOf> <owl:inverseOf> <owl:ObjectProperty rdf:about=#participant/> 12 Come si evince dal codice OWL cnr.it/ontologies/DOLCE-Lite#endurant>, <owl:Class rdf:about= http://www.loa- <owl:ObjectProperty http://www.loa-cnr.it/ontologies/DOLCE-Lite#participant-in/>, ecc. rdf:about= 4.2.1 ROME 98 </owl:inverseOf> <rdfs:domain> <owl:Class rdf:about=#endurant/> </rdfs:domain> <rdfs:range> <owl:Class rdf:about=#perdurant/> </rdfs:range> </owl:ObjectProperty> Analizzando tutti i costrutti presenti in tale denizione, sono stati individuati i corrispondenti operatori delle DL: • Il costrutto <rdfs:subPropertyOf>, che corrisponde all'operatore di inclusione • v utilizzato per creare gerarchie tra ruoli, quindi alla DL H; Il costrutto <owl:inverseOf>, che corrisponde alla proprietà inversa − R , quindi alla DL I . Facendo il punto della situazione, dall'analisi della sola enità Endurant di ROME, risulta che i costrutti utilizzati nella sua denizione sono: • Il quanticatore esistenaziele completo; • Il quanticatore universale; • L' operatore di intersezione; • L' operatore di unione; • Il disjoint with. Nel complesso essi corrispondono alla DL ALC . ALC esprimibili con con l'operatore sintetizza anche le DL di negazione (DL C) E ed U ,perché Ricordiamo che la DL e gli operatori di congiunzione e quanticatore univer- sale presenti nella DL AL13 . Quindi sono stati già trovato costrutti corrispondenti ad un sottoinsieme della DL SHIF : l'utilizzo della DL in particolare, della DL H, I , 13 Vedere il paragrafo 1.3.3 e parte della S SHIF è stato individuato nora (solo la DL ALC ). 4.2.1 ROME 99 Prosieguo dell'analisi Si è deciso di sospendere l'analisi esaustiva perché inutile: l'analisi si è concentrata sulla ricerca solo di esempi di ruoli transitivi (per ottenere una piena DL • S) e proprietà funzionali (corrispondenti alla DL F ): Ruoli transitivi: in DOLCE-Lite 397 vi sono 6 proprietà transitive(gura 4.18). Tra esse vi è la proprietà Part (gura 4.19). Figure 4.18: Ruoli transitivi in DOLCE-Lite 397 Figure 4.19: Proprietà transitiva Part in DOLCE-Lite 397 4.2.1 ROME 100 Tale proprietà è usata nelle denizioni delle classi Endurant e NonPhysical Endyrant in DOLCE-Lite 397 (gura 4.20), quindi risulta essere coinvolta in ROME. Facendo nuovamente il punto della situazione, grazie all'individuazione Figure 4.20: Utilizzi della proprietà Part di almeno un utilizzo di ruoli transitivi in DOLCE-Lite 397 nella denizione di entità coinvolte indirettamente in ROME, si può aermare che nora della DL SHIF corrispondenti alle DL vengono utilizzati in ROME solo gli operatori H, I ed S (stavolta completa). 4.2.1 ROME • 101 Proprietà funzionali: l'unica proprietà funzionale in DOLCE-Lite 397 è life (gure 4.21 e 4.22). Figure 4.21: Proprietà funzionali in DOLCE-Lite 397 4.2.1 ROME 102 Figure 4.22: Proprietà funzionale Life in DOLCE-Lite 397 Andando ad indagare tra i suoi utilizzi, risulta che non compare in nessuna delle denizioni delle entità di DOLCE usate in ROME (gura 4.23). Si può dedurre che ROME non utilizza proprietà funzionali. 4.2.2 SNOMED CT 103 Figure 4.23: Utilizzi della proprietà Life L'analisi sull' espressività di ROME perciò può ritenersi conclusa: essa corrisponde alla DL 4.2.2 SHI . SNOMED CT Per SNOMED CT ci si è dati delle pubblicazioni in merito: il limite di non avere tale ontologia a disposizione anche in questo caso non ha costituito un grosso problema. SNOMED CT è espresso in OWL 2 EL++: è un prolo di OWL2, con pochissimi costrutti a disposizione (è dunque poco espressivo). Tale linguaggio si basa sulla DL EL++, la cui sintassi e semantica è descritta in gura 4.24. In particolare, GCI sta per General Concept Inclusion (denizione di assiomi terminologici), mentre RI sta per Role Inclusions (costruzione di ruoli complessi) 14 . 14 Per un approfondimento ulteriore sugli operatori vedere i paragra 1.3.4 e 1.3.7 4.2.3 Confronto 104 Figure 4.24: Sintassi e semantica della DL 4.2.3 EL++ Confronto Da un confronto tra le DL EL++(di SNOMED CT ) e SHI (di ROME), risulta che esse presentano un sottoinsieme di operatori coincidenti, più degli operatori eccedenti ambo i lati. In dettaglio, • EL++ ha i seguenti operatori in più rispetto a SHI : Nominal: utilizzo di nomi di individui non solo nell'ABOX ma anche nella costruzione dei concetti 15 , usati per l'enumerazione (infatti né ROME né DOLCE-Lite hanno individui, e nessuna delle due usa il costrutto oneOf per l'enumerazione); • Inclusione di ruoli con a sinistra role chains 16 : SNOMED CT usa una forma ristretta di questo costrutto, che altrimenti sarebbe molto espressivo e sorgente di indecidibilità; • Domini concreti Invece la DL SHI 17 . ha in più rispetto alla DL EL++ i seguenti operatori 15 Per un approfondimento ulteriore vedere il paragrafo 1.3.5 16 Per un approfondimento ulteriore vedere il paragrafo 1.3.7 17 Per un approfondimento ulteriore vedere il paragrafo 1.3.3 18 Per un approfondimento ulteriore vedere i paragra 1.3.2 e 1.3.3 18 : 4.2.3 Confronto • Disgiunzione; • Negazione; • Quanticatore universale; • Ruolo inverso. 105 Si è cercato in seguito riscontro di tali risultati a livello del linguaggio OWL: in particolare dando un'occhiata ai costrutti del corrispondente prolo OWL2 EL++, risulta che tra le feature supportate vi sono: • Enumerazioni che coinvolgono un singolo elemento (ObjectOneOf ) o una singola costante (DataOneOf ); • Object property inclusion (SubObjectPropertyOf ), che coinvolgono possibilmente anche Property chains, e Data property inclusion (SubDataPropertyOf ); • Inclusioni complesse tra Object properties (dove per coplesse ci si riferisce al fatto che la property chains possono trovarsi sul lato sinistro). Invece le feature mancanti di OWL2 EL++ (rispetto ad OWL2) sono: • Quanticazione universale di una classe (ObjectAllValuesFrom) o Data range (DataAllaValuesFrom); • Disgiunzione (ObjectUnionOf, DisjointUnion); • Negazione (ObjectComplementOf ); • Inverse object properties (InverseObjectProperties). Tutto questo conferma l'analisi fatta. In conclusione non si può aermare quale delle due logiche descrittive sia più espressiva. 4.3 Complessità computazionale 4.3 106 Complessità computazionale Terminata l'analisi sull'espressività lo studio è proseguito verso l'individuazione del potere computazionale, legato all'espressività, delle due ontologie. 4.3.1 Cenni sulle classi di complessità Con complessità di un algoritmo o ecienza di un algoritmo ci si riferisce alle risorse di calcolo da esso richieste. Partendo dunque dalla misurazione delle risorse computazionali, si possono denire le seguenti classi di complessità: • La classe TIME(f(n)) è l'insieme dei problemi che ammettono una macchina di Turing che li risolve e che opera in tempo f(n) • 19 ; La classe NTIME(f(n)) è l'insieme dei problemi che ammettono una macchina di Turing non deterministica che li risolve e che opera in tempo f(n); • La classe SPACE(f(n)) è l'insieme dei problemi che ammettono una macchina di Turing che li risolve e che opera in spazio f(n) • 20 ; La classe NSPACE(f(n)) è l'insieme dei problemi che ammettono una macchina di Turing non deterministica che li risolve e che opera in spazio f(n). Si possono così denire le seguenti classi di complessità: • L=SPACE(log(n)); • NL=NSPACE(log(n)); • k P=∪k>0 TIME(n ). Per risolvere i problemi appartenenti alle classi n qui elencate sono noti algoritmi che terminano in tempo polinomiale rispetto alla dimensione dei dati; • k NP=∪k>0 NTIME(n ): per questi problemi sono noti algoritmi che terminano in un numero di passi polinomiale rispetto alla dimensione dei dati nel caso si possa utilizzare un numero indeterminato di macchine 19 Dato un input x di lunghezza n, la macchina M produce il risultato in f(n) passi 20 Dato un input x di lunghezza n, la macchina M utilizza f(n) celle temporanee per eettuare la computazione 4.3.2 ROME 107 in parallelo, o nel caso si utilizzi una macchina di Turing non deterministica. La sigla NP sta per non-deterministic polinomial (polinomiale nondeterministico): tutti gli algoritmi realizzabili su calcolatori sici risolvono questi problemi in tempo esponenziale rispetto a n; • k PSPACE=∪k>0 SPACE(n ); • k NSPACE=∪k>0 NSPACE(n ); • nk EXPTIME=∪k>0 TIME(2 ): per questi problemi sono noti solamente algoritmi che terminano in un numero di passi esponenziale rispetto alla dimensione dei dati, indipendentemente dal modello di calcolo. Tra queste classi sono note le seguenti relazioni di equivalenza: • L ⊆ NL • L ⊆ PSPACE; • P ⊆ EXPTIME. 4.3.2 ⊆ P ⊆ NP ⊆ PSPACE = NSPACE ⊆ EXP; ROME Per lo studio della complessità computazionale di ROME è stato suciente individuare la complessità (nota in letteratura) di una logica descrittiva che utilizza un sottoinsieme dei costrutti presenti nella logiche descrittiva con cui è espressa ROME: tale risultato è stato poi vericato utilizzando un' applicazione disponibile sul web (un complexity navigator). Nel dettaglio, un risultato noto in letteratura 21 è che per la DL ALE i problemi di sussuzione (a cui sono conducibili gli altri problemi di reasoning se sono presenti gli operatori di intersezione e il concetto insoddisfacibile) e soddisfacibilità (a cui sono conducibili gli altri problemi di reasoning se presente la negazione) 22 23 sono NP-COMPLETI : considerando che tutti gli 24 operatri presenti nella DL ALE sono anche presenti nella DL SHI si può dedurre che la complessità della DL SHI è almeno NP. Questi risultati sono riferiti a problemi con semplici espressioni di concetti. Se si iniziano a considerare gli assiomi (quindi il TBox) in genere la complessità aumenta. Indagando ulteriormente, è stata individuata la complessità esatta del ragionamento per la DL SHI di ROME, servendosi di un complexity navigator 21 Per approfondimenti consultare il The description logic handbook: theory, implementation, and applications, Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F. 22 Vedere paragrafo 1.3.6 23 I problemi NP-completi sono i più dicili problemi nella classe NP 24 Vedere paragrafo 4.2.1 4.3.2 ROME 108 25 disponibile per la consultazione gratuitamente su internet (gura 4.25): la classe di complessità risulta essere EXP-TIME COMPLETE sia per quanti riguarda la soddisfacibilità dei concetti che per quanto riguarda la consistenza dell'ABox. In letteratura il comportamento esponenziale nel tempo di calcolo delle Figure 4.25: Complessità delle DL SHI secondo il complexity navigator logiche descrittive è giusticato facendo riferimento all' esplorazione di alberi 26 AND e OR . Intuitivamente, esso è legato alle seguenti due origini indipen- denti di complessità: • L'AND BRANCHING: corrisponde al controllo indipendente di tutti i successori di un individuo. È responsabile della dimensione esponenziale di un singolo modello candidato. Il suo comportamento esponenziale è dovuto all'interazione del quanticatore esistenziale col quanticatore universale (come accade per la DL • ALE ); L'OR BRANCHING: corrisponde alla dierente scelta di applicazione di una regola non deterministica. È responsabile del numero esponenziale di dierenti modelli candidati. Il suo comportamento esponen- ziale è dovuto alla presenza del costruttore di disgiunzione che rende 25 http://www.cs.man.ac.uk/ ~ezolin/dl/#note8 26 Per approfondimenti consultare il The description logic handbook: theory, implementation, and applications, Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F. 4.3.3 SNOMED CT 109 un concetto soddisfacibile da più di un modello (come accade per la DL ALU ). L'intrattabilità di ragionamento (cioè l'essere non polinomiale nel caso peggiore) non impedisce tuttavia di usare la DL in pratica, se l' implementazione di sistemi basati su qualche DL usano sosticate tecniche di ottimizzazione e se le basi di conoscenza sono di dimensioni realistiche, come accade per ROME. 4.3.3 SNOMED CT Per l'analisi della complessità computazionale di SNOMED CT ci si è ancora dati dei risultati pubblicati in letteratura 27 , secondo i quali esso pre- senta buone proprietà computazionali per ontologie su larga scala: fornisce infatti ragionamento in tempo polinomiale. In dettaglio, uno dei risultati noti è che la DL DL EL++) è trattabile: 28 TBox ciclici che aciclici dono EL++, EL (sottoinsieme della è infatti decidibile in tempo polinomiale sia per . Aggiungendo alla DL EL i costrutti che la ren- il problema di sussunzione (quindi anche gli altri problemi di reasoning grazie ai costrutti presenti) resta decidibile. Tale DL è sucientemente espressiva da permetterne il suo eettivo impiego per la descrizione del dominio di interesse, ed è trattabile anche considerando l'inclusione generalizzata di ruoli. Le cause delle sue buone proprietà sono le seguenti: • Assenza del quanticatore universale, che causerebbe un ragionamento EXP-time completo; • Utilizzo solo di una forma ristretta di role-value-maps, che altrimenti sarebbe causa di indecidibilità. Gli stessi risultati sono stati riscontrati sulle pubblicazioni della W3C, secondo le quali le ontologie espresse utilizzando il linguaggio OWL 2 EL++ (tra cui appunto SNOMED CT) hanno tutte problemi di ragionamento controllabili in tempo polinomiale. 27 Per approfondimenti consultare gli articoli Pushing the EL Envelope e Pushing the EL Envelope Further (Institute for Theoretical Computer Science TU Dresden) Baader,F.,Brandt,S.,Lutz, C. 28 SNOMED CT usa un TBOX aciclico 4.3.4 Confronto 4.3.4 110 Confronto Sintetizzando i risultati sopra riportati, si può aermare che SNOMED CT presenta buone proprietà computazionali per ontologie su larga scala: fornisce infatti ragionamento in tempo polinomiale. ROME invece presenta un comportamento esponenziale nel tempo di calcolo: una ontologia con tale complessità è utilizzabile solo per basi di conoscenza di piccole dimensioni, grazie anche alle sosticate tecniche di ottimizzazione presenti oggigiorno, ma al crescere delle dimensioni della base di conoscenza il ragionamento diventerebbe in trattabile. In denitiva appare evidente che SNOMED CT presenta proprietà computazionali migliori rispetto a ROME. Chapter 5 Conclusioni Nell'ambito del lavoro presentato in questa tesi sono stati introdotti innanzitutto i vantaggi dell'utilizzo delle ontologie in ambito biomedico, traducibili in migliore interoperabilità e maggiori capacità elaborative, e in sintesi migliore assistenza sanitaria. Quindi è stato svolto uno studio su due ontologie particolarmente signicative in ambito biomedico: SNOMED CT nell'ambito internazionale, ROME nell'ambito nazionale italiano. Ne è conseguita un'analisi comparata tra le due ontologie sotto diversi aspetti: di carattere generale - come la diusione e accettazione - e di carattere più prettamente ingegneristico, quali la correttezza delle ontologie in riferimento alle regole di una buona ingegnerizzazione, la determinazione delle eettive logiche descrittive con cui sono espresse (dunque dei livelli di espressività posseduti) e della conseguente complessità computazionale. Si è giunti così all'obiettivo nale: tirar fuori delle valutazioni conclusive sul confronto risultante tra le due ontologie sotto tutti questi proli. Innanzitutto la grossa distizione tra le due ontologie oggetto dell'analisi riguarda la diusione: SNOMED CT è diusa e accettata a livello inter- nazionale; ROME è utilizzata solo in Italia, e in sporadiche applicazioni. Sotto il prolo invece della correttezza ontologica, l'analisi svolta su SNOMED CT ha rivelato la presenza di errori che spesso violano i principi dell'ingegneria ontologica; l'analisi svolta su ROME invece ha mostrato la correttezza dell' ontologia secondo i suddetti principi, sebbene siano comunque presenti delle imprecisioni. Per quanto riguarda l'espressività, l'analisi ha portato all'individuazione delle logiche descrittive sulle quali le due ontologie si basano (analizzandone i singoli costrutti del linguaggio OWL eettivamente impiegati), e dal confronto è conseguito che non si può aermare quale delle due ontologie sia più espressiva. 111 112 Per quanto riguarda inne la complessità computazionale legata all'espressività precedentemente determinata, si è individuato che per ROME risulta essere esponenziale (quindi intrattabile al cresecere della mole di dati), mentre per SNOMED CT è polinomiale, quindi trattabile anche per grandi quantità di dati. Al ne di valutare quale alternativa sarebbe migliore per l'Italia, non bisogna dimenticare che lo scopo primario delle ontologie è garantire l' interoperabilità: quindi la scelta sarebbe tra un'interoperabilità solo nazionale, quindi ROME, e una internazionale, cioè SNOMED CT. Nel primo caso tuttavia ROME andrebbe estesa con l'aggiunta di altre ontologie di dominio al ne di raggiungere una maggiore copertura di argomenti in ambito sanitario, ma a causa della sua complessità il ragionamento diverrebbe intrattabile, quindi di fatti l'ontologia sarebbe inutilizzabile. Nel secondo caso, sarebbe necessario diventare membri della HITSDO (con il relativo pagamento della tassa annuale) per poter collaborare al lavoro internazionale di correzione dei contenuti dell'ontologia, e occorrerebbe un lavoro iniziale di nazionalizzazione, ma sicuramente sarebbero garantitate una completa interoperabilità e ottime proprietà computazionali. Ringraziamenti Sarei negligente se non ringraziassi tutte le persone che mi hanno aiutata a sopravvivere all'esperienza di altri tre anni d'università: mi hanno sostenuto nei momenti di dicoltà, incoraggiato nei momenti di sconforto, si sono rallegrate con me nei piccoli/grandi successi ... e mi sono semplicemente state accanto in tutti gli altri momenti, contribuendo in modo concreto al raggiungimento di questo mio importante traguardo: questa tesi è dedicata a voi miei cari. Inizio dalla persona che, sebbene nella storica e perenne concorrenza tra ingegneri informatici ed elettronici mi abbia assegnato il titolo di pigia tasti, ha dato un tocco di brio alla mia vita in questi ultimi anni, ha riempito le mie giornate (a volta anche troppo!), ma senza la quale il mio mondo perderebbe i colori: grazie Eros, hai reso più completa la mia vita facendomi scoprire quanto sia più bella se vissuta in due. Grazie ai miei stupendi genitori che hanno sempre saputo sostenermi e consigliarmi, facendomi avvertire il loro calore anche a 500km di distanza: è dicile immaginare un mondo senza l'appoggio del mio papà e i buoni consigli della mia mamma. La mia adorata sorellina e il mio caro cognato sono stati decisivi: grazie per l'aiuto sempre pronto e concreto, la presenza costante ... e gli innu- merevoli passaggi al pronto soccorso! Prometto di essere meno sbadata... Grazie ai mei quasi suoceri e cognati: sono felice di essere entrata a far parte della vostra allegra compagnia. E poi ci sono tutti i miei amici di questi anni universitari: i compagni di corso: compagni di avventura e sventura; il gruppo della Pastorale Universitaria, che ha arricchito il mio periodo di studi attribuendogli un valore più alto; il gruppo Giovani delle Grazie per le belle e ricche chiacchierate fatte insieme. Grazie anche al gruppo di nuoto del CUS per i momenti di svago; grazie alla mia cara mamma mensa ERSU per avermi nutrita in questi anni ... e un grazie speciale va alle mie innumerevoli coinquiline: tra momenti di condivisione e di tirate per capelli, tra momenti di condenze e di litigi, tra periodi più o meno pacici ... tutte quante mi avete arricchito e fatto crescere. Grazie alle persone che erano con me all'inizio dei miei studi ma che nel corso di questi ultimi anni mi hanno lasciato per raggiungere un posto migliore: grazie Don Enzo e zio Vittorio. Grazie al Professor Dragoni e al suo gruppo di ricerca, che con la loro semplicità e dedizione rendono migliore questa università. E inne un grazie lo devo anche a tutto la sta dell'Ospedale Careggi di Firenze e a tutti i sioterapisti che mi hanno seguito in questi ultimi anni: grazie per aver rimesso in sesto la mia povera spalla con tanta competenza, permettendomi di portare a termine i miei studi. Spero di non aver dimenticato nessuno: in ogni caso vi porto tutti nel mio cuore. Bibliography Ontologie Ontologie BS [1] OpenClinical, http://www.openclinical.org/ [2] Barry Smith: textitchapter "Ontology" of Blackwell Guide to the Philosophy of Computing and Information, Oxford: Blackwell, (2003). HITSDO ROME [3] HITSDO, http://www.hitsdo.org [4] Pisanelli, D.M., Battaglia, M., De Lazzari, C.: ROME: a Re- ference Ontology in Medicine, New Trends in Software Methodologies, Tools and Techniques-Proceedings of the sixth SoMeT 07, (2007). SNOMED CT Ontological [5] Héja,G.,Surján,G.,Varga,P.: CT, First European Conference on analysis SNOMED CT, of SNOMED Copenhagen- Denmark(2006). Browsers [6] Snoflake browser, http://snomed.dataline.co.uk, Snomed Ct Core Browser, http://terminology.vetmed.vt.edu/default.htm W3C DL [7] W3C, http://www.w3.org/ [8] Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F. The description logic handbook: : theory, implementation, and applica- tions, Cambridge University Press, (2003). EL [9] Baader,F.,Brandt,S.,Lutz, C.: Pushing the EL Envelope, Institute for Theoretical Computer Science TU Dresden, Germany EL2 [10] Baader,F.,Brandt,S.,Lutz, C.: Pushing the EL Envelope Further, Institute for Theoretical Computer Science TU Dresden, Germany Complexity [11] Complexity of reasoning in http://www.cs.man.ac.uk/ ~ezolin/dl/#note8 115 Description Logics,