Abstract
L'uso efficace delle tecnologie dell'informazione
e della comunicazione in ambito medico richiede che
tutti gli attori coinvolti nel processo di cura di
un paziente conoscano quali siano gli aspetti informatici
che caratterizzano i dati clinici e come questi sono
organizzati. Dall'impiegato dell'accettazione, al
responsabile del centro unico di prenotazione, al
direttore amministrativo; dall'infermiere di reparto,
al medico primario, al direttore sanitario: affinché
possano cooperare a beneficio del paziente, tutti
questi attori devono conseguire un livello minimo
di conoscenza diretta e condivisa di vantaggi e vincoli
specifici delle clinica e della sanità.
Dapprima viene presentata la terminologia informatica
necessaria nel trattamento di dati in ambito biomedico;
sono descritti gli elementi per comprendere a cosa
servono globalmente i database per la Medicina e la
Sanità. Il rilevante insieme di caratteristiche
contemplato permette di individuare le funzioni -
potenti e flessibili - delle quali i database devono
essere dotati, se si vuole che essi siano avvertiti
dai loro utenti come pienamente utili. Vengono poi
considerati i criteri di classificazione a radice
informatica - "Locale" rispetto "a
distanza", "Dati" rispetto "segnali
e immagini", "Codici" rispetto a "linguaggi"
- e descritti gli elementi fondamentali dei modelli
di basi di dati: gerarchico, reticolare, relazionale,
orientato agli oggetti, presentando esempi di ambito
sanitario nei quali sono utilizzati con successo.
Quindi, prestando attenzione ai ritorni per l'utente,
sono introdotte le differenti classi di interrogazione
delle basi di dati: per parole chiave, per intervallo,
per concetti, incluso il caso di interrogazioni semantiche
per le banche di bio-immagini. In fine sono indicati
esempi e riferimenti di banche di bio-segnali, di
bio-immagini, di dati genomici.
1 - Elementi costituenti lo Scenario
Anche non essendo specialisti in Informatica Medica
e Telemedicina, nel pensare ai database per la Medicina
e la Sanità ci sono termini che, in modo naturale,
vengono alla mente. Ha senso iniziare da questi, poiché
costituiscono una conoscenza implicita e di ampio
raggio. Per ottenere profitto da ciò, si comincerà
esaminando brevemente alcune di queste parole: saranno
considerate come parole-chiave e verrà ricordato
il loro significato. Nel fare questo saranno anche
ricordate le aspettative generali che tali termini
generano ai differenti profili relativi ai parecchi
utenti dei database per la Medicina e la Sanità.
Qualche volta sarà facile capire il grado al
quale - già da ora - le aspettative sono soddisfatte.
In altri casi vorremmo percepire quanto i metodi e
le tecnologie per i database dovrebbero ancora migliorare
per risolvere i problemi dei loro utenti in Medicina
e Sanità. Una delle parole chiave è
memorizzare. Nel corso degli ultimi decenni, sappiamo
come la capacità di memoria dei dispositivi
digitali è stata ampiamente aumentata di anno
in anno, anche negli ultimi anni. Probabilmente, adesso,
le capacità di memorizzazione non costituiscono
colli di bottiglia significativi nelle applicazioni
mediche e sanitarie. Nell'anno 2003, i sistemi offerti
erano in grado di raggiungere 12 Peta Byte, ed un
costo di 6000$ per Tera Byte era relativamente comune
(Tab. 1). In accordo con le capacità
di memorizzazione solitamente necessarie, i dispositivi
di memorizzazione hanno capacità abbastanza
adeguate e prezzi relativamente bassi. Un aspetto
non trascurabile è relativo al mantenere il
supporto di memorizzazione leggibile in futuro, a
lungo, per parecchi decenni.
Una seconda parola chiave è archiviare. Archiviare
richiede memoria, ma necessita anche di organizzazione.
Per comprendere questo, assumiamo che si archivia
perché abbiamo necessità di rendere
più facili gli usi futuri delle informazioni
di cui disponiamo. Individuare, visualizzare ed elaborare
sono le principali azioni d'uso dei dati che l'archiviare
dovrebbe facilitare. Per di più, per lasciare
possibile ciascuno di questi usi, i dati dovrebbero
essere stati memorizzati bene e in modo sicuro. Vogliamo
dire che, qualsiasi sarà il principio fisico
coinvolto nei dispositivi e meccanismi di memorizzazione,
fondamentalmente l'azione di archiviazione dovrebbe
fornire affidabile memorizzazione, in modo tale da
permettere agli utenti delle informazioni di compiere
le loro pertinenti azioni, come individuare, visualizzare
ed elaborare i dati. Ad esempio in una biblioteca,
un sistema di classificazione è necessario
per aiutare gli utenti. Esso guida anche l'allocazione
dei libri sullo scaffale. Però non tutti i
libri hanno le medesime dimensioni. Anche se libri
di differenti dimensioni sono collocati su differenti
scaffali, questo dovrebbe non costituire una difficoltà
per gli utenti quando vogliono cercare libri aventi
soggetti simili. Se noi trasferiamo il concetto dai
libri ai dati medici e sanitari, l'archiviazione di
questi dovrebbe non costituire alcuna difficoltà
per i loro utenti nonostante le molte differenze esistenti
tra i tipi di dati di base medici e sanitari [2].
Va ricordato quanto le parole, i biosegnali, le bioimmagini
impegnino qualsiasi computer in modo molto differente
le une dagli altri, a partire dalla loro digitalizzazione,
che è iniziale fase di qualunque insieme di
desiderate prestazioni. Una terza parola chiave è
integrazione. Le specifiche funzioni a cui il concetto
di integrazione può essere applicato sono realmente
tante. Fra loro molte sono differenti una dall'altra.
E' integrazione quella dei dati che un singolo paziente
genera nei sistemi informativi di parecchi differenti
ospedali, dove egli è stato curato. E' integrazione
quella fra la descrizione testuale di una diagnosi
medica e le specifiche bioimmagini che la supportano
[3]. E' integrazione quella fra dati clinici e dati
amministrativi. Altri esempi di integrazione possono
essere citati. Le aspettative generali sono che i
prodotti della tecnologia dell'informazione gestiranno
una completa ed efficace integrazione. Ma, nel campo
dei dati clinici e sanitari, dopo alcuni decenni di
sforzi indirizzati alla implementazione di integrazioni
efficaci, ancora permangono cattive notizie. Si vuole
dire che, anche a livello di paziente, ancora sperimentiamo
che le integrazioni sono troppo lontane dai livelli
naturalmente desiderati. Ad esempio due differenti
ospedali, mantenenti alcuni dei mie dati clinici,
ben difficilmente li fonderanno insieme sotto una
singola identificazione di paziente. Non di meno,
nonostante le presenti carenze, i database rimangono
il solo unico strumento utile alle necessità
dell'integrazione desiderata per permettere agli utenti
individuare, visualizzare o elaborare i dati clinici
e sanitari. In sintesi, "integrazione" è
una parola chiave veramente desiderata dai clienti,
e quindi è considerata dalle aziende fornitrici,
ma sta ancora aspettando sistemi più performanti
di quelli offerti oggi. Attualmente la scelta da fare
consiste nel tenere limitate le necessità di
interesse, analizzandole professionalmente e cercando
soluzioni che si adattino ad esse. Una quarta parola
chiave è visualizzazione. Grazie alla tendenza
"grande è bello", schermi grandi
e piatti trionfano ovunque. Da una parte essi possono
apparire giusto un'attrazione, d'altra parte essi
indicano miglioramenti oggettivi. Ad ogni modo, grande
non è tutto. Questo significa che non è
abbastanza che la visualizzazione sia realizzata "plug
and play" per garantire anche i livelli di fedeltà
richiesti dalle applicazioni mediche. E' necessario
considerare la forma dei pixel, il numero dei livelli
di colore, la dinamica di risposta riguardante i filmati,
le condizioni di illuminazione dell'ambiente e così
via. Per tutto questo, nell'ambito medico, considerate
tutte le necessarie cautele, una più grande
dimensione incoraggia un nuovo inizio, per aggiornare
l'analisi ereditata dal passato. Nel trattare i database
medici e sanitari, un problema chiave inevitabile
riguarda la riservatezza. Esso può essere trattato
sottolineando tre differenti aspetti sui quali si
possono basare gli strumenti e le tecniche di riservatezza
e sicurezza. I tre aspetti sono: "cosa conosciamo",
"cosa possediamo", "cosa siamo"
[4]. Rispettivi esempi sono: una password, una carta
- del tipico ingombro di una carta di credito - di
qualunque tecnologia, un'impronta digitale. Anche
quando ci focalizziamo sulla categoria "cosa
siamo" appaiono molte difficoltà. Algoritmi
affidabili, in grado di rendere completamente tollerabile
la rilevanza di errori di riconoscimento - siano falsi
positivi o falsi negativi -, non sono ampiamente diffusi,
almeno quando le corti da considerare sono altamente
popolate. Ad ogni modo, ci sono tante iniziative promosse
da aziende. Alcune di loro offrono servizi basati
su un certo numero di grandezze biometriche, eventualmente
applicate l'una dopo l'altra in successione [5]. Gestione
è il termine spesso aggiunto a tutte le parole
chiave finora considerate. Noi possiamo avere familiarità
con i termini quali gestione della memoria, gestione
dell'integrazione e così via. Gestione suscita
problemi chiave. Da parecchi anni, la dicitura "gestione
del PACS", dove PACS è l'acronimo di "Picture
Archives and Communication Systems", ha acquisito
una propria fisionomia e caratteristiche di globalità.
Nella "gestione del PACS", già l'edizione
2003 della conferenza Hospital Information Management
System Society (HIMMS) ha confermato una specifica
tendenza: quella dei "web-based PACS", cioè
PACS basati su tecnologie per il web. Il concetto
di base è adottare metodi e tecnologie web
anche per lo svolgimento di operazioni sulla intranet
ospedaliera. La tendenza è qualche volta davvero
notevole, come nel caso della Fuji Medical Systems
USA, che commercializzò come "The web-based
PACS", cioè il PACS basato su web, il
proprio prodotto chiamato Synapse [7]. Ora abbiamo
a disposizione gli elementi per comprendere a cosa
servono globalmente i database per la Medicina e la
Sanità. Essi servono per permettere che le
informazioni mediche e sanitarie siano archiviate
efficacemente in modo tale da supportare le necessità
dei parecchi differenti utenti di quelle informazioni.
I database dovrebbero anche aiutare gli utenti nel
individuare, visualizzare ed elaborare ciò
a cui sono interessati. Per compiere il loro lavoro
adeguatamente, i database per la medicina e la sanità
dovrebbero includere operazioni di memorizzazione,
integrazione, visualizzazione e gestione di informazioni
mediche, fino al più piccolo livello dei loro
dati atomici. Essi dovrebbero anche includere prestazioni
per sicurezza e riservatezza [8]. Per ultimo ma non
ultimo in importanza, essi dovrebbero essere costruiti
- anche cooperativamente , e usati - principalmente
individualmente - a distanza. Per di più ogni
cosa dovrebbe essere fatta "on time". Questo
è essenziale nonostante "on time"
non è facile da quantificare. Differenti utenti
potrebbero richiedere differenti numeri. Per di più
questi numeri potrebbero evolvere nel tempo. Il ricco
insieme di caratteristiche illustrato permette di
individuare le funzioni - potenti e flessibili - delle
quali i database devono essere dotati, se si vuole
che essi siano avvertiti dai loro utenti come pienamente
utili per servire la Medicina e la Sanità.
Tuttavia oggigiorno un insieme di tal genere non può
essere considerato come facile da allestire. La ragione
è che, nella sua interezza, esso è ancora
al di sopra delle prestazioni di base, delle tecnologie
e dei metodi disponibili per i database. Non di meno
questo non significa che i database non possano fare
nulla di utile in Medicina e Sanità. In accordo
con il desiderio di ottenere ritorni sulla base del
breve periodo, la politica di implementare un sottoinsieme
di caratteristiche, che sono di interesse a pochi
profili utente alla volta, usualmente conduce a risultati
soddisfacenti. Nel fare ciò, noi accettiamo
di andare a prendere specifiche soluzioni, magari
di portata limitata, ma sostenibili e utili subito.
Molti esempi provano che questo è un approccio
di ampio successo [9]. Come cittadini, quando richiediamo
al nostro programma assicurativo nazionale sanitario
che il badge possa essere mostrato ogni volta che
richiediamo assistenza medica, si usa un database.
Esso non consente di gestire le bioimmagini, ma funziona
bene nell'amministrare i diritti sanitari della popolazione.
Come pazienti, quando vediamo il nostro medico di
famiglia recuperare i nostri pregressi dati sanitari,
egli usa un database. Probabilmente non sarà
in grado di comparare dati simili di differenti pazienti,
ma funziona bene nel recuperare i nostri propri dati
medici. Come medici lavorando in un reparto ospedaliero,
quando facciamo paragoni tra i dati medici dei pazienti
affetti dalla stessa malattia, un database ci sta
aiutando. Probabilmente non fa nulla per permetterci
di comprendere qualcosa circa i costi delle cure somministrate
ai pazienti, ma funziona bene nel servire i nostri
scopi di confronti clinici. Come amministratori ospedalieri
espletando funzioni complesse di controllo del budget,
sicuramente usiamo un database. Esso non farà
nulla per aiutarci nell'analisi in tempo reale dei
segni vitali di un paziente allettato nell'unità
di terapia intensiva, ma funziona bene nell'aiutarci
a mantenere in piedi il budget dell'ospedale. Come
ricercatori che lavorano nel campo della bioinformatica,
usiamo dati che frequentemente provengono da parecchi
differenti database [10]. Parlando in generale, essi
non forniscono quasi nulla di pronto per essere integrati
con i dati del paziente ora raccolti nella sua cartella
clinica, ma essi funzionano bene per permettere l'investigazione
delle ipotesi di ricerca scelte.
2 - Criteri di classificazione orientati
all'informatica "Locale" rispetto "a
distanza".
I database dei medici di famiglia sono l'esempio base
di database locali. Essi sono localmente compilati
e localmente utilizzati. Non è un problema
che il medico di famiglia usi un computer notebook,
in modo tale da poter operare anche in casa del paziente.
Vogliamo solo dire che non esiste la necessità
di una infrastruttura di comunicazione. Ogni cosa
è dentro, in quella singola macchina. I database
per il trapianto di organi sono l'opposto. Essi non
sono per niente locali. Solitamente il database è
fisicamente allocato nel sito principale del servizio
di gestione dei trapianti. La parte di database dei
"candidati riceventi" è compilata
a distanza, dai dipartimenti appartenenti a differenti
ospedali, solitamente senza rilevanti necessità
di tempo reale. La parte di database dei "candidati
donatori" è compilata anch'essa a distanza.
Anche se arrivati tramite un dipartimento ospedaliero,
la loro origine può essere quella ambulanza
che ancora sta prestando soccorso sul luogo di un
incidente in autostrada. Le necessità di tempo
reale sono molto elevate. Nulla vieta che nelle infrastrutture
di comunicazione coinvolte ve ne siano di non proprietarie
a patto che i nostri dati possano far uso di canali
prioritari.
"Dati" rispetto "segnali e
immagini".
Sappiamo che una classica cartella clinica è
un raccoglitore di documenti cartacei come pure di
altre informazioni residenti su differenti supporti,
quali ad esempio pellicole fotografiche. Tracciati
di bio-segnali (come elettrocardiogrammi, elettroencefalogrammi,
ed altri ancora) e bio-immagini (come grandi radiografie
del torace o le piccole radiografie di una mano, fotografie
da ecografie ad un seno o dal cuore, immagini di risonanza
magnetica, immagini di tomografie ad emissione di
positroni) sono comunemente presenti nel raccoglitore
"cartella clinica". Osserviamo che, se il
medico possiede la conoscenza necessaria per comprendere
gli specifici e differenti contenuti informativi presenti
nelle immagini, tale varietà di supporti non
gli causa alcun problema. Poiché umano, egli
mostra la stessa naturalezza nel consultare bio-dati,
bio-segnali e bio-immagini indifferentemente tra loro.
Questo è normale per il nostro senso della
vista. Ma, sfortunatamente, nulla di tal genere è
ancora successo ad un computer. Nel dire così
non ci riferiamo alla caratteristica dei dati di essere
digitali. Questo è tecnologicamente naturale
per qualsiasi computer. Vogliamo dire che per qualunque
tipo di informazione - bio-dati, bio-segnali e bio-immagini
- arriverà tranquillamente il momento di finire
in bit. Ciò non costituisce problema. Le difficoltà
provengono dalle differenze relative ai passi intermedi
richiesti per convertire ciascun tipo di informazione
in cifre binarie. Per spiegare le maggiori differenze,
sia osservato che i bio-dati entrano in un computer
via tastiera. Questo accade per gli esempi di: un
nome di malattia, il valore numero della frequenza
cardiaca. Per convertire questi in cifre binarie,
dobbiamo aver risposto alla domanda "Quanti bit
sono necessari per codificare il numero di caratteri
presenti nel nostro alfabeto?" Ecco quanto c'è
bisogno sapere. Bio-dati riguardano caratteri e numeri.
Ma per bio-segnali e bio-immagini - come pure per
segnali ed immagini - no. Bio-segnali e bio-immagini
entrano in un computer via scanner. Questo accade
per gli esempi di: una mammografia e un' ecografia
fetale. Per convertire queste figure in digitale,
dobbiamo aver risposto alle domande "Per non
perdere dettagli, quanti punti per pollice (dpi -
"dot per inch") il mio scanner dovrebbe
avere? E, per non perdere in precisione, quanti differenti
tonalità e livelli di colore dovrei essere
in grado di codificare per ciascun di quei punti?"
I punti per pollice e il numero di colori definiscono
le prestazioni base di qualsiasi scanner. Per di più,
quando il punto non è un cerchio, la quantità
punti per pollice di uno scanner dovrebbe essere indicata
più di una volta. Per i bio-segnali, è
vero che quando, per esempio, un elettrocardiogramma
è disegnato su un foglio di carta millimetrata,
può essere visto come un'immagine. Tuttavia
i bio-segnali entrano in un computer attraverso un
dispositivo di conversione analogico-digitale. Per
convertire questi segnali in digitale, dobbiamo aver
risposto alle domande "Per non perdere dettagli,
quante volte al secondo dovrei leggere, cioè
campionare, il segnale? E, per non perdere in precisione,
quanti differenti livelli di valori dovrei avere disponibili
per codificare le ampiezze di ciascun campione senza
cadere in approssimazioni intollerabili? La frequenza
di campionamento e i livelli di quantizzazione definiscono
le prestazioni base di qualsiasi convertitore analogico-digitale.
Per di più, quando canali di ingresso multipli
possono essere impiegati, quanto contemporanei possono
essere i campioni provenienti da differenti canali
è pure un'importante caratteristica di qualità.
"Codici" e "linguaggi".
"Più codifichiamo quanto memorizziamo
in un database, più facile sarà interrogarlo"
è una frase con la quale si è facilmente
d'accordo. Tuttavia maschera problemi. Vogliamo dire
che una lettura superficiale della frase può
tranquillamente invitare verso sistemi di codifica
molto semplici. Dobbiamo tenere in mente che, se facciamo
così, accettiamo di andare incontro soltanto
ad interrogazioni di tipo semplice. Generalmente questo
non è ciò che vogliono gli utenti. Sfortunatamente
solitamente accade che le aspettative degli utenti
di database - in Medicina e Sanità come pure
in altri campi - non sono soddisfatte dal formulare
interrogazioni soltanto di tipo semplice. Per di più,
se noi andiamo verso sistemi di codifica troppo semplici,
la loro granularità può essere non sufficiente
per il grado di realtà che vogliamo conservare.
Ad esempio, nel dire "infiammazione dell'occhio",
usualmente vogliamo conoscere quale è l'occhio
coinvolto. Una frase migliore e usualmente più
accettata è questa: "Più ampiamente
codifichiamo quanto vogliamo memorizzare in un database,
più efficacemente lo interrogheremo".
Ma anche questa frase maschera problemi. Vogliamo
dire che alcuni notevoli sistemi di codifica sono
certamente disponibili. Unified Medical Language System
(UMLS) [11], Systematized Nomenclature of Medicine
- Clinical Term (SNOMED-CT) [12], International Classification
of Diseases (ICD-9, ICD-10) [13] sono i maggiori esempi
di codici ampiamente estesi. Purtroppo essi sono così
ampi al punto da non essere usati nella pratica clinica
giornaliera di un reparto. Questo fatto è di
certo sbagliato in assoluto. Purtroppo però
ha una sua utilità. Vale a dire che, in quanto
dobbiamo sempre fare i conti col desiderio di ridurre
la ricchezza del nostro linguaggio a favore della
maggiore efficacia e immediatezza di comprensione
dell'uditorio che immediatamente ci circonda e al
quale ci rivolgiamo, la ampiezza e la precisione del
linguaggio usato a livello di un dipartimento clinico
inevitabilmente finirà per essere più
piccola di quella del linguaggio che usiamo nello
scrivere un articolo da sottomettere ad una rivista
scientifica internazionale.
Modelli di dati per Database.
Gerarchico, reticolare, relazionale e orientato agli
oggetti sono i maggiori modelli nel campo dei database.
Ciascuno di essi ha applicazioni elettive nell'ampio
campo della Medicina e Sanità. Poiché
i database gerarchici [14] sono efficaci in quelle
applicazioni dove c'è un solo punto di vista
dominante, essi sono adeguati per i medici di famiglia
quando gestiscono eventi minori. Questi sono quelli
dove i membri della famiglia soffrono di un solo problema
sanitario alla volta. Qualsiasi nuovo problema è
nettamente posteriore ai precedenti e del tutto indipendente
da essi. Quando un problema si presenta, il membro
della famiglia è visitato dal medico. Il problema
viene identificato. Test di laboratorio sono solitamente
prescritti, farmaci sono anche prescritti, qualche
volta anche prima dell'arrivo dei risultati dei test
di laboratorio. Per tutta la durata del problema,
il paziente può essere visitato più
volte e la terapia può essere modificata secondo
necessità. Ma il problema arriva ad una fine.
Il prossimo problema sanitario, se si verificherà,
può essere assunto ampiamente indipendente
dal precedente. Per l'organizzazione del database,
la sorgente gerarchica primaria è il nome del
medico di famiglia (Fig.1). Un livello
sotto c'è il nome del paziente. Più
sotto, al secondo livello, c'è il nome dell'evento.
Questo può essere "infiammazione dell'occhio".
Al terzo livello ci sono le visite effettuate per
quel problema. Al quarto livello troviamo le prescrizioni
farmacologiche e le raccomandazioni di comportamento
per il paziente. La gerarchia implica che qualsiasi
prescrizione dovrebbe essere interpretata appartenente
solamente a quella visita, a quell'evento, a quel
paziente. Un secondo esempio medico di chiara gerarchia
è relativa alla sezione anamnesi familiare
di una cartella clinica. Probabilmente nulla è
più gerarchico di un albero genealogico, ma,
sfortunatamente, tutti gli altri paragrafi di una
cartella clinica ospedaliera non mostrano nulla di
così gerarchico come la anamnesi familiare.
E la prospettiva di usare differenti database per
specifici capitoli di un documento non è attuabile
nella pratica dei software applicativi di uso comune.
I database reticolari [15], basati sul modello reticolare
dei dati, sono adeguati per i casi dove ci sono parecchi
punti di vista - cioè parecchi profili utente
- e nessuno di essi è tale da essere considerato
ampiamente dominante (Fig.2).
Il seguente insieme di coppie di interrogazioni riassume
cosa vogliamo dire. Tutti i farmaci assunti da un
paziente. Tutti i pazienti che hanno assunto un farmaco
specifico. Tutti i dipartimenti presenti in un ospedale.
Tutti gli ospedali aventi uno specificato dipartimento
clinico. Tutti i pazienti curati da uno specifico
medico. Tutti i medici curanti specifici pazienti.
E così via. Di fronte ad esempi come questi,
è facile ammettere che non c'è un punto
di vista dominante, cioè non c'è gerarchia.
L'idea di database reticolare è più
adatta a queste condizioni. Tuttavia anche i database
reticolari hanno debolezze. Queste originano dal fatto
che, a qualunque stadio, essi trattano con la sola
totalità di tutti i dati che devono essere
investigati dalle interrogazioni. Questo è
vero anche quando tutte tali interrogazioni appartengono
a uno specifico sottoinsieme applicativo, dove una
grande parte dei dati memorizzati non sarà
mai considerata oggetto di analisi. I dati amministrativi
sono un esempio: essi non saranno mai di interesse
in un'interrogazione clinica. Un secondo esempio è
l'intero insieme dei dati identificativi, compresi
quelli che potrebbero variare, come l'indirizzo civico
e il numero telefonico. Principalmente questi ultimi
dati sono necessari solo per inviare lettere ai domicili
dei pazienti. Non sono necessari per rispondere alle
interrogazioni cliniche.
La sottolineata debolezza dell'interezza è
risolta dai database relazionali [16]. Essi possono
essere visti provenire da un'ingegnosa segmentazione
dei database reticolari. Le relazioni sono il risultato
della segmentazione. Essenzialmente una relazione
è una semplice tabella con righe e colonne.
Le colonne servono per gli attributi che descrivono
propriamente a che cosa servano le relazioni. Uno
degli attributi è l'attributo utilmente dominante
che viene considerato come chiave (Fig. 3).
In una cartella clinica, tipicamente le relazioni
sono usate per i dati identificativi, per l'anamnesi
familiare, per l'anamnesi patologica remota, per l'anamnesi
patologica recente, eccetera. Nel fare questo, in
ogni relazione un attributo chiave adatto può
essere il codice che l'ospedale dà al paziente
per quel ricovero.
Le righe delle relazioni sono riempite con valori
specifici di attributi, proprio per quei casi che
stiamo considerando. Generalmente l'insieme dei valori
presenti in una riga è chiamato tupla. Segmentare
un database non dovrebbe portare verso relazioni troppo
piccole. Infatti più le relazioni sono piccole
più alta è la loro numerosità,
e più alti diventeranno il tempo di interrogazione
e la complessità. Anche se l'azione di interrogare
i database relazionali trae vantaggio dall'algebra
relazionale, adeguatamente definita e potente, il
tempo di interrogazione può diventare significativamente
importante. Anche la complessità da gestire
può richiedere di fare troppo lavoro di programmazione.
Tuttavia, ogni volta che il tempo di calcolo non è
importante, i database relazionali di solito forniscono
la flessibilità desiderata per l'interrogazione
dei contenuti del database. Spesso ciò avviene
dal largo uso dello Structured Query Language (SQL)
[17]. Ciò che i database relazionali forniscono
nella loro essenza va lungo due linee principali.
La prima è l'incremento del livello di dettaglio,
la seconda è la potenza degli strumenti di
interrogazione che abbiamo a disposizione. Senza dubbio
i database relazionali sono i più usati. Tuttavia,
per molte applicazioni mediche e sanitarie, anche
i database relazionali mostrano grosse debolezze.
Per esempio essi non integrano facilmente dati ed
immagini. Ciò significa che diventa molto difficile
considerare un'immagine soltanto come il valore di
un attributo, da essere scritto nella appropriata
cella di una tabella relazionale. In aggiunta, i database
relazionali non fanno facilmente fronte alla gestione
degli attributi multivalore - come noi necessitiamo
per riempire la colonna dell'attributo "Fattori
di rischio" per pazienti che sono affetti, per
esempio, sia da obesità che da alcolismo. Il
tecnicismo dell'aggiungere righe ad una tabella relazionale
- per includere uno soltanto dei fattori di rischio
multipli in una cella alla volta, - è una possibilità
critica. Vale a dire che, dal punto vista clinico,
quando i pazienti possiedono contemporaneamente due
fattori di rischio, il loro stato è intuitivamente
e di solito più grave. Le Basi di dati orientate
agli oggetti [18] derivano da un coraggioso tentativo
e dalla speranza di proporre una nuova visione per
risolvere il problema di gestire i dati efficacemente.
Noi iniziamo da un alto livello di generalità.
Infatti nel rispetto verso parole come gerarchico,
reticolare, relazionale la parola oggetti suona più
generale. Apparentemente ciò suona anche più
debole e più generico rispetto al bisogno di
permettere descrizioni dettagliate. Un oggetto può
essere qualunque cosa. Tante cose, molto differenti
tra loro, possono essere chiamate oggetti. Ma questa
parola comporta il potere di dare rilevanza a identità
complete, potenti, e conosciute. Ad esempio si pensi
al numero di serie che identifica e distingue ciascuno
degli esemplari tutti tra loro uguali di una produzione
industriale. Frequentemente le identità contengono
altre identità, più piccole, e questo
succede ad un livello spesso implicito. Per esempio,
quando in una conversazione generica diciamo: "E'
diabetico", intendiamo dire che: "Egli è
una persona malata a causa del diabete". Noi
intendiamo questo senza il bisogno di dirlo esplicitamente.
Succede che l'oggetto "Diabetico" eredita
le proprietà dell'oggetto "Paziente",
e questo eredita le proprietà dell'oggetto
"Persona" (Fig.4).
Rimane vero che oggetto è un termine abbastanza
generico, ma noi usiamo la sua positiva flessibilità
di significati, dato che abbiamo - generalmente implicita
- la conoscenza di ciò che un'identità
assegnata significa nel nostro ambiente. Stando nella
parte delle tecnicità informatiche, noi diciamo
che un oggetto include sia l' insieme dei suoi dati
adeguatamente definiti, e i relativi metodi per la
gestione dei dati stessi. I metodi di base sono quelli
richiesti per l'inserimento dei dati, memorizzazione,
relazioni, interrogazione, salvataggio, individuazione,
integrazione, eccetera. In aggiunta all'ereditarietà,
altre proprietà frequentemente menzionate dei
data base orientati agli oggetti sono l'incapsulamento
(per nascondere la struttura dei dati verso l'esterno),
sovradefinizione (overriding, overloading), risoluzione
dei legami posticipata (late binding) - cioè
in fase di esecuzione vengono risolti i nomi dei metodi,
e i tipi delle variabili, che devono agire -, persistenza
(mantenere gli oggetti nel tempo anche dopo il termine
dell'esecuzione di un programma), concorrenza (differenti
procedure agiscono contemporaneamente sugli stessi
dati), e altre ancora.
Il ciclo di vita di un database è un processo
complesso, solitamente composto dalle seguenti fasi
principali:
1) Raccolta e analisi dei requisiti,
2) Progettazione concettuale del database,
3) Scelta di un adeguato Data Base Management System,
4) Progettazione logica del database,
5) Progettazione fisica del database,
6) Implementazione del database,
7) Uso e manutenzione.
Per la fase di progettazione concettuale di un database,
il modello concettuale maggiormente diffuso è
quello Entità-Relazione (Entity-Relationship
model, E-R) (Fig.5).
3 - Ritorni all'utente
Classi di interrogazione - Per parole chiave
Durante l'ultimo decennio alla maggior parte
di noi è diventato familiare compiere ricerche
in Internet mediante l'uso di parole-chiave - per
lo più impiegate una alla volta, - e motori
di ricerca. Se, in un dato ospedale, vogliamo elencare
tutte le cartelle cliniche dove quelle parole-chiave
sono contenute, il metodo ha successo. Esempi pratici
sono elencati di seguito: tutti i pazienti che hanno
ricevuto uno specifico farmaco; tutti i farmaci presi
da uno specifico paziente; tutti i medici in carico
ad uno specifico dipartimento; e così via.
In aggiunta, se, nel compiere una ricerca nella letteratura
medica, probabilmente usando PubMed [23], vogliamo
avere elencati tutti gli articoli di rivista dove
la parola-chiave è presente, - potrebbe essere
solamente nell'abstract, potrebbe essere all'interno
del testo dell'articolo- il metodo ha successo ancora.
Certamente, la lista di risultati includerà
anche quei pazienti (o quegli articoli di rivista)
dove quella parola-chiave è preceduta da "assenza
di", o è seguita da "non presente".
Ma, quando interroghiamo un database ospedaliero,
non vogliamo che questo succeda. Vogliamo una più
elevata efficacia. Tuttavia, dobbiamo ammettere che
il programma di interrogazione è molto semplice.
Dobbiamo anche ammettere che alcuni rischi di malinteso
sono indesiderati.
Per intervallo
In Medicina, per la maggior parte delle quantità
misurabili, la conoscenza acquisita nel passato ci
consente di definire intervalli di normalità.
Di fronte al risultato di un test di laboratorio per
un dato paziente, vogliamo conoscere se il risultato
è normale (fisiologico) oppure no. Per effettuare
una interrogazione di questo tipo anche l'organizzazione
dei dati consentita da un foglio di calcolo elettronico
può generalmente essere sufficiente. Interrogazioni
un poco più complesse sono del tipo: "Vogliamo
conoscere se il paziente ha avuto febbre mentre era
ricoverato in ospedale".
Una più alta complessità hanno le interrogazioni
come: "Selezionare i pazienti che, dopo aver
preso un certo farmaco in una certa quantità,
hanno avuto il trattamento con quel farmaco interrotto
per effetti collaterali indesiderati, e dopo minimo
cinque giorni il periodo di wash-out, il paziente
è passato al trattamento con questo altro farmaco,
e ciò fu fatto senza avere che il paziente
mostrasse alcun effetto collaterale per un minimo
di trattamento lungo tre mesi con il nuovo farmaco,
a medio o più alto dosaggio".
Per concetti
Nel fare un'interrogazione, "cardiopatia"
può essere giusto una parola-chiave. Un risultato
può essere il numero di volte in cui questa
parola è presente nel testo. Ma noi possiamo
usare "cardiopatie" per interrogare qualcosa
d'altro. Vogliamo dire che possiamo cercare la lista
di nomi specifici di tutte le patologie cardiache.
La operatività di fare ciò è
lontana dal contare quante volte una parola appare
in un dato testo. Ora la operatività inizia
con il cercare un dizionario medico. Frequentemente
sarà un dizionario strutturato. Un possibile
esempio può essere la parte di terminologia
del Unified Medical Language System (UMLS). Poi il
dizionario dovrebbe essere consultato. La consultazione
deve essere fatta in accordo con i criteri di strutturazione
del dizionario. Tutti nomi delle cardiopatie dovrebbero
essere elencati, e i sinonimi dovrebbero essere propriamente
trattati. I risultati dovrebbero accordarsi con anche
con i livelli di granularità richiesti dall'utente.
Una ricerca come quella appena descritta è
spesso detta "un'interrogazione per concetti".
Interrogazioni semantiche per database di bio-immagini.
Il Visible Human Dataset (VHD) [24] è una collezione
di immagini da sezioni orizzontali esaustive di due
corpi umani, uno maschile e uno femminile. Il corpo
dell'uomo è stato sezionato una volta ogni
millimetro. Questo ha portato alla serie di 1870 fotografie
digitali. Il corpo della donna, sezionato tre volte
per ogni millimetro, ha portato alla serie di 5100
fotografie digitali. Fotografie in tali quantità
non sono adeguate per essere gestite manualmente.
Interrogazioni come: "Per le immagini provenienti
da tutte le sezioni dove il fegato è presente,
dammi tutti i dati relativi al solo fegato",
dovrebbero essere considerate interrogazioni assai
naturali anche dalle matricole universitarie. Ma l'architettura
software per effettuare una tale interrogazione è
molto peculiare. La visualizzazione seriale dei file
grezzi contenenti le immagini del VHD, la selezione
di quelle di loro dove il fegato è presente,
il contornamento del fegato su ciascuna delle immagini
selezionate, la validazione dell'azione di contornamento,
il salvataggio dei dati originali del VHD appartenenti
al contorno, la loro memorizzazione in un nuovo database,
chiamato "fegato VHD", la scelta di un corpus
di conoscenza anatomica (e.g. il tesauro del Unified
Medical Language System), e parecchi altri aspetti
da curare: tutti questi sono tra i maggiori passi
da compiere con qualsiasi sistema che esegua interrogazioni
semantiche di database di bio-immagini [25].
4 - Alcuni maggiori database
Per avere una visione generale di cosa sta accadendo
nel campo dei "Database per la Medicina e la
Sanità", ogni cittadino può effettuare
qualche ricerca in Internet, sommaria o affinata che
possa essere. Sappiamo che i risultati saranno parzialmente
dipendenti dal motore di ricerca utilizzato. Anche
chi è medico compirebbe sostanzialmente le
medesime azioni di ricerca, ma ha il vantaggio di
possedere già la conoscenza professionale per
dare o non dare ascolto a parecchi dei risultati apparsi
fra l'enorme numero di quelli elencati dal motore
di ricerca. I criteri generali di fiducia dei professionisti
possono essere relativi al segmento di attività
a cui i risultati possono essere associati. Esempi
di segmenti di attività possono essere produzione
ed uso per la parte di mercato, istruzione per la
parte di conoscenza, governo per la parte di legislazione,
progressi per la parte di ricerca (Fig. 6).
Criteri specifici di fiducia dei professionisti sono
relativi a obiettivi più focalizzati. Esempi
sono il nome di un sistema di gestione di basi di
dati - database management system (DBMS) -, il nome
di una malattia, il nome di un dizionario medico,
il nome di un farmaco, nomi di sintomi, segni, valori
normali di una data misurazione, il costo dei trattamenti
medici, tabelle di sopravvivenza, errori medici, complicazioni
post-chirurgiche, diritti del paziente, sicurezza
dei dati, elettrocardiogrammi, immagini di risonanza
magnetica, riservatezza della cartella clinica, DNA
micro-array, e così via. Vogliamo dire che,
per il momento, ricercando "database medici e
sanitari" il numero di ritrovamenti (risultati)
è vicino a cento migliaia per "database
medici" e dell'ordine di parecchie migliaia per
"database sanitari". Una visione dettagliata
e abbastanza approfondita della attuale situazione
nel campo dei "Database per la Medicina e la
Sanità" emerge dal libro "Elementi
di Informatica BioMedica" [26], che dedica molte
pagine all'argomento.
In particolare vi sono capitoli dedicati alle banche
di terminologie mediche, alle banche di bibliografie
mediche, alle banche di biosegnali, alle banche di
bioimmagini, alle banche genomiche.
Ciascuno tema è affrontato per rispondere alle
esigenze dell'utente fruitore di tali risorse, rendendolo
consapevole di quegli aspetti di costruzione e di
gestione che maggiormente determinano le prestazioni
di utente, a volte rendendole più a portata
di mano, altre volte - purtroppo - rimanendo lontane
dal consentire un buon successo al proposito. Per
ciascuna delle banche dati indicate sono presentati
gli aspetti caratteristici, le differenti tipologie
esistenti (ad esempio banche genomiche primarie, banche
genomiche derivate), i problemi da affrontare per
una efficace realizzazione e un loro allestimento
che si riveli utile per l'uso nell'ambiente ospedaliero.
Dove possibile il libro include alcune confronti.
Ne e' esempio quello tra le banche di bioimmagini
digitali. Alcune caratteristiche dello storico Visible
Human Dataset - realizzato oltre dieci anni fa e ampiamente
conosciuto - risultano molto migliorate nelle più
recenti banche di bioimmagini del Visible Korean Human
e del Chinese Visible Human, che hanno tratto vantaggio
dalla evoluzione tecnologica dei sistemi di acquisizione
manifestatasi negli ultimi anni.
Prof. Francesco Pinciroli
Professor of Medical Informatics and Health Information
System at the Politecnico of Milano - Italy
Prof. Stefano Bonacina
Department of Bioingegneria, Politecnico
di Milano -Italy
