Indice. - Corso di Laurea in Ingegneria Informatica

Indice.
CAPITOLO 1. DECISION SUPPORT SYSTEMS. .......................................................... 2
1.1 Evoluzione dei sistemi informativi. .......................................................................... 2
1.2 Sistemi di supporto alle decisioni. ........................................................................... 4
1.3 Componenti di un DSS. ............................................................................................ 5
1.4 Business Intelligence. .............................................................................................. 5
1.5 Confronto tra un sistema esperto e un DSS. ............................................................ 7
CAPITOLO 2. DSS: UTILIZZO IN AMBITO CLINICO. ................................................ 8
2.1
Un po di storia. ................................................................................................... 9
2.2 Una struttura per caratterizzare i sistemi di supporto alle decisioni cliniche. ........ 13
2.3 Stile di comunicazione. .......................................................................................... 14
2.4 Il processo Decision-Making. ............................................................................... 14
2.5 Interazione Uomo-Computer. ................................................................................. 16
2.6 Costruzione di uno strumento per il supporto alle decisioni. ................................. 17
2.7 Modellazione della conoscenza medica. ................................................................ 18
2.8 Estrazione della conoscenza medica. ..................................................................... 18
2.9 Rappresentazione della conoscenza medica............................................................ 19
2.10 Convalida delle prestazioni del sistema. .............................................................. 20
2.11 Integrazione di uno strumento per il supporto alle decisioni. .............................. 20
CAPITOLO 3. ESEMPI ILLUSTRATIVI DI SISTEMI DI SUPPORTO ALLE
DECISIONI CLINICHE. .................................................................................................. 21
3.1 Diagnosi: Internist-1/QMR project e DXplain system........................................... 22
3.2 Gestione del paziente: architettura basata su linee guida e sistema EON. ............. 28
3.3 Sistemi per la gestione del paziente basati su linee guida. ..................................... 29
3.4 Un architettura basata su linee guida per la gestione del paziente: EON SYSTEM.
...................................................................................................................................... 30
CAPITOLO 4: Conclusioni. ............................................................................................. 37
4.1 I decision support systems nei prossimi dieci anni. ............................................... 37
1
CAPITOLO 1. DECISION SUPPORT SYSTEMS.
1.1 Evoluzione dei sistemi informativi.
I primi sistemi informativi computerizzati, introdotti a partire dagli anni ’50,
furono i Transaction Processing Systems (TPS): servivano per la gestione delle
attività aziendali ripetitive svolte ai livelli più bassi dell’organizzazione (ad
esempio, la fatturazione e la gestione degli stipendi). I TPS migliorarono
notevolmente le attività e le prestazioni degli impiegati. In particolare, si era in
grado di accumulare grosse quantità di dati in tempi ragionevoli e a costi ridotti.
Successivamente, grazie anche allo sviluppo della tecnologia informatica e alla
crescita della capacità di elaborazione dei calcolatori, furono introdotti i
Management Information Systems (MIS) che avevano lo scopo di fornire un
supporto ai livelli organizzativi più alti dell’organizzazione aziendale.
I
MIS
producevano
dei
report
predefiniti,
standardizzati
e
generati
periodicamente. Tipicamente, questi report contenevano informazioni ottenute
estraendo in maniera appropriata ed, eventualmente, aggregando secondo criteri
prestabiliti, i dati contenuti nei TPS.
I problemi principali relativi ai report predefiniti e standardizzati sono:
• Nella maggior parte dei casi le informazioni utili al manager per le attività di
pianificazione e controllo consistono in un sottoinsieme molto limitato delle
informazioni contenute nel report. Inoltre, tali informazioni sono spesso
difficilmente individuabili in tempi brevi;
• Non tutte le informazioni necessarie al decisore sono contenute nei report.
Il passo successivo nello sviluppo dei sistemi informativi fu, quindi, quello di
adottare un approccio completamente diverso: invece di impegnarsi per stabilire
quali e quanti tipi di informazioni dovessero essere presenti nei report per fornire
2
supporto ai manager, ci si concentrò sugli strumenti che potevano essere utili al
manager per usare al meglio le informazioni durante il processo decisionale. Era
importante fornire ai manager un accesso veloce e mirato al database aziendale e
dar loro la possibilità di eseguire elaborazioni analitiche sui dati secondo criteri
non fissati a priori.
Riflettendo sul significato di supporto alle decisioni, ci si rese conto che
supportare le attività manageriali significa fare uso di dati che riguardano
l’azienda nel suo complesso e che derivano spesso dall’aggregazione di dati
specifici. I dati specifici sono quelli contenuti nel database aziendale che ha lo
scopo, appunto, di memorizzare i dati provenienti dalle operazioni di transazione
e gestiti dal TPS.
In quest’ottica si capì che era utile creare un nuovo database (data warehouse) a
partire dai dati contenuti nel database aziendale, ma separato dallo stesso database
aziendale, e destinato agli usi specifici del supporto alle decisioni. Questo nuovo
database doveva contenere dati già opportunamente aggregati secondo determinati
criteri.
Ovviamente servivano anche degli strumenti software che permettessero di
elaborare in modo analitico le informazioni aggregate contenute nel nuovo
database in maniera da supportare diversi modelli e stili decisionali. Nacquero
così i Sistemi di Supporto alle Decisioni (DSS).
Successivamente, in parallelo allo sviluppo dei DSS, nacquero i Sistemi Esperti
(ES). Gli ES possono essere utilizzati come supporto al processo decisionale in
quanto forniscono al manager le conoscenze specifiche in
determinati campi applicativi, conoscenze che il manager in genere non
possiede e per le quali avrebbe dovuto ricorrere ad esperti esterni
all’azienda.
Il passo successivo è stato quello di integrare le due tecnologie dei DSS e
degli ES. I sistemi risultanti sono detti Knowledge-based DSS (KDSS). I KDSS
sono in grado di elaborare dati attraverso modelli matematici, compito tipico dei
DSS, e trasformare tali risultati in opinioni, valutazioni e consigli attraverso un
processo di ragionamento simbolico, tipico degli ES.
3
Per completare il quadro introduttivo sui sistemi informativi occorre
far riferimento ad un altro tipo di sistemi noti come Executive Information
Systems(EIS).
Tali sistemi supportano il top management nel processo decisionale fornendo
informazioni in tempo reale attraverso un’interfaccia molto amichevole e intuitiva
(User-friendly). Gli EIS sono quindi DSS destinati ai livelli più alti
dell’organizzazione aziendale. Sono più facili da usare dei DSS,
ma meno flessibili.
1.2 Sistemi di supporto alle decisioni.
I DSS forniscono supporto ai manager e a tutti coloro che devono prendere
decisioni strategico/operative di fronte a problemi poco strutturati o non strutturati
(e che quindi non possono essere risolti con i modelli offerti dalla ricerca
operativa). Devono permettere analisi ad hoc sui dati e l’uso di modelli (modelli
quantitativi finanziari, statistici e della ricerca operativa). Il principale scopo di un
DSS è quello di permettere di estrarre, in tempi brevi e in modo flessibile, da una
grossa mole di dati le informazioni che servono a supportare e migliorare in
termini di efficacia il processo decisionale. Occorre innanzi tutto separare i dati
generati dalle operazioni di gestione (contenuti nel database aziendale o
operational (database) dai dati utili ai processi decisionali dell’azienda (contenuti
nel data warehouse).
Ovviamente il data warehouse deve contenere non un sottoinsieme dei dati del
database aziendale, ma una versione di tali dati ottimizzata per analisi focalizzate
sui dati aggregati e sulle tendenze piuttosto che sulle singole operazioni di
gestione. I dati devono quindi essere memorizzati a diversi ed appropriati livelli di
aggregazione. Il decisore deve poter analizzare i dati contenuti nel data warehouse
in tempo reale, da diversi punti di vista e a diversi livelli di aggregazione.
4
1.3 Componenti di un DSS.
Data Management Subsystem: include il data warehouse che contiene i dati
rilevanti per le decisioni e il software per la gestione di quest’ultimo.
Model Management SubSystem: è un pacchetto software che contiene i modelli e
il software per gestirli. Rappresenta il cuore analitico del sistema. I modelli
permettono di descrivere la realtà complessa del problema. Oltre alla costruzione
dei modelli, devono essere messi a disposizione dell’utente strumenti per testare
un modello e per effettuare simulazioni.
Dialog Management SubSystem: è il sottosistema che gestisce la comunicazione
tra utente e sistema. Deve garantire la semplicità d’uso del sistema attraverso
menu e comandi intuitivi.
1.4 Business Intelligence.
Spesso per riferirsi ai sistemi di supporto alle decisioni si usa anche un altro
termine: BusinessIntelligence (BI). Una soluzione di business intelligence prevede
i seguenti componenti:
Data Warehouse.
Un data warehouse è un database ottimizzato per contenere i dati utili ai processi
decisionali. È separato dal database aziendale (detto operational database). Mentre
il database aziendale è aggiornato costantemente perché deve rappresentare
l’istante corrente, il data warehouse deve memorizzare solo determinati istanti
dell’attività di gestione. Conterrà quindi i dati aggregati a particolari istanti di
tempo, ad esempio dati settimanali, mensili o trimestrali.
5
Inoltre sarà necessario integrare i dati che provengono dal database aziendale con
dati relativi all’ambiente esterno in cui opera l’azienda: mercati, situazione
economica e politica, principali concorrenti, ecc.
Quindi la mole di dati memorizzati nel data warehouse è molto ampia. Di
conseguenza, è opportuno memorizzare, insieme ai dati, anche tutte quelle
informazioni utili al decisore per analizzare correttamente i dati: ad esempio, qual
è il database di origine dei dati (ad esempio, alcuni dati possono provenire dal
database interno oppure possono derivare da fonti esterne come enti pubblici,
associazioni di categoria, società di marketing o di ricerca), l’istante temporale in
cui sono stati raccolti, quando sono stati aggiornati, cosa rappresentano e in quali
tipi di analisi si possono usare.
Ad esempio, in un sistema informativo di una banca, un record nell’operational
database sarà, ad esempio, il nome e cognome di un cliente con il suo ultimo
indirizzo e il suo attuale livello di credito. Il data warehouse conterrà, invece, gli
indirizzi del cliente relativi agli ultimi tre anni, e la sua storia bancaria presso
l’istituto di credito. In ultima analisi, potremmo definire il data warehouse come
un grande contenitore che contiene i dati storici prelevati dagli operational
database.
OLAP.
Gli OLAP (On–line Analytical Processing) sono sistemi software che permettono
al decisore di analizzare i dati
I) In tempo reale;
II) Da differenti punti di vista (analisi multidimensionali);
III) A diversi livelli di aggregazione: operazioni di aggregazione (roll up) e di
disaggregazione (drill down).
Per quanto riguarda l’analisi multidimensionale non è infatti più sufficiente
condurre analisi su due sole dimensioni (ad esempio, Vendite organizzate per
Prodotto e Regione, oppure Vendite organizzate per Prodotto e Ultimi tre
trimestri), ma è necessario poter usare più dimensioni (ad esempio, Vendite
organizzate per Prodotto, Regione e Ultimi tre trimestri).
6
Per quanto riguarda l’ aggregazione invece, deve essere possibile organizzare le
dimensioni su diversi livelli gerarchici. Ad esempio, un’impresa che sia presente
sull’intero territorio nazionale, potrà organizzare la dimensione “zona geografica”
delle proprie vendite per “regioni” suddivise in “province”, a loro volta suddivise
in “stabilimenti”. Muovendosi lungo i diversi livelli della gerarchia l’utente è in
grado di passare da analisi di dettaglio ad analisi di insieme e viceversa.
EIS.
Un EIS(Executive Information System) è nato dalla necessità di fornire ai decisori
meno esperti uno strumento capace di condurre analisi “preconfezionate” sui dati
aziendali. Un EIS permette, analogamente ad un sistema OLAP, di ottenere viste
multidimensionali dei dati a diversi livelli di aggregazione. Un EIS è più facile da
usare rispetto ad un OLAP (c’è un’interfaccia grafica semplice ed intuitiva), ma è
meno flessibile in quanto le viste ed i livelli di aggregazione sono predefiniti.
Data Mining.
Data Mining è l’attività di individuazione ed estrazione di informazioni, quali
relazioni e associazioni tra i dati, precedentemente sconosciute all’utente. Le
principali tecniche usate per il data mining includono ad esempio, le reti neurali e
gli algoritmi di clustering.
1.5 Confronto tra un sistema esperto e un DSS.
Un DSS fornisce un supporto al decisore e non si sostituisce al decisore stesso. La
decisione si ottiene combinando le valutazioni umane con le informazioni
elaborate dal sistema.
Un DSS deve permettere l’uso di modelli, fornendo la possibilità di crearne di
nuovi e di modificare i precedenti. Un Sistema Esperto (SE) è in grado di
7
prendere decisioni da solo. Un SE non è usato per risolvere problemi che
richiedono tecniche di ottimizzazione matematica tipiche di un DSS. Al contrario,
un SE è utilizzato per problemi in cui l’obiettivo e gli eventuali vincoli non sono
facilmente esprimibili in termini quantitativi.
CAPITOLO 2. DSS: UTILIZZO IN AMBITO CLINICO.
Un clinical decision-support system è un qualunque programma designato
all’assistenza, in ambito sanitario, nella scelta decisionale. E’ quindi, un
programma che offre dati o una base di conoscenza medica atta a supportare il
processo decisionale dell’utente.
E’ utile considerare tre tipi di strumenti per il supporto alla decisione dal paziente
generico a quello specifico:

Strumenti per la gestione dell’informazione: sistemi di informazione
sanitaria o sistemi per il recupero delle informazioni fanno parte di questa
categoria. Workstations specializzate forniscono ambienti sofisticati per la
memorizzazione, classificazione e recupero delle basi di conoscenza
medica. Attraverso queste, gli operatori dispongono di una conoscenza più
vasta di quella ottenuta, ad esempio, dalla lettura di un libro di testo, in
quanto, la conoscenza gestita da questi sistemi è in continuo
aggiornamento. Sebbene questi sistemi forniscano i dati e le basi
conoscitive necessarie al medico, generalmente non lo aiutano
nell’applicazione di tali informazioni.

Strumenti per focalizzare l’attenzione: sistemi di laboratorio che segnalano
valori anomali o che forniscono spiegazioni a quelle anomalie come, ad
esempio, le informazioni farmaceutiche che hanno lo scopo di mettere in
guardia l’utente dai possibili effetti dei farmaci, sono strumenti che
focalizzano l’attenzione di chi li utilizza sul soggetto della diagnosi in
corso. In generale usano una logica semplice, visualizzando come risposta
standard, una lista di casi possibili per una data anomalia.
8

Strumenti per provvedere alle raccomandazioni del paziente:
tali programmi provvedono a valutazioni su misura di un insieme di dati
specifici del paziente. Possono seguire logiche semplici (Algoritmi),
possono essere basati su teorie decisionali e di analisi o, possono usare un
approccio numerico in aggiunta alla soluzione del problema simbolico.
Alcuni suggeriscono differenti diagnosi o indicano informazioni
aggiuntive che dovrebbero aiutare il medico a restringere il range di
possibilità. Altri suggeriscono una spiegazione migliore della
sintomatologia del paziente. Altri ancora forniscono consigli terapeutici
piuttosto che assistenza alla diagnosi.
Nonostante i confini tra queste tre categorie siano sottili, le distinzioni fatte sono
utili nella definizione di un insieme di funzionalità offerto dai computer,
nell’assistere il medico alla decisione.
2.1
Un po di storia.
I primi articoli sulla possibilità dell’ introduzione dei computer nel processo di
assistenza alla diagnosi apparvero alla fine degli anni 50’ e nel giro di pochi anni,
furono sviluppati i primi prototipi sperimentali.
La diffusione di questi sistemi fu ostacolata da alcuni problemi sia di origine
scientifica, come le limitazioni tecnologiche dell’epoca, sia di origine etica, come
lo scetticismo dei medici nell’utilizzo di strumenti che non avessero subito una
profonda integrazione nel suddetto ambiente di lavoro.
Tre sistemi di consulenza forniscono un utile panoramica sull’origine dei clinical
decision-support systems:

Abdominal Pain System (deDombal’s):
Alla fine degli anni 60’ deDombal, aiutato da un gruppo di suoi colleghi,
sviluppò, presso l’Università di Leeds, un computer che forniva supporto
decisionale basato sulla teoria della probabilità di Bayes. Usando diagnosi
chirurgiche e patologiche come standard, enfatizzarono l’importanza di derivare le
probabilità condizionali usate nel ragionamento di Bayes da un insieme di dati di
alta qualità, raccolti collezionando informazioni da un totale di mille pazienti. Nel
Leeds Abdominal Pain System, attraverso l’utilizzo di questi dati, segni e sintomi,
9
il campo delle malattie derivanti da un forte dolore addominale fu ristretto ad un
massimo di sette elementi. Per rendere l’algoritmo di Bayes maneggiabile, il
programma doveva fare assunzioni di indipendenza condizionata delle risultanze
per le varie diagnosi e di mutua esclusività. Nella valutazione del sistema furono
utilizzati come attributi della regola di Bayes, risultati clinici e di laboratorio,
ottenuti dai medici, relativi a 304 pazienti che si erano recati al pronto soccorso
lamentando dolori addominali. Quindi , tale formulazione assumeva che ognuno
di questi 304 pazienti avesse una delle sette malattie contenute all’interno del
sistema e selezionava la più probabile sulla base dell’osservazione registrata. Il
programma doveva essere utilizzato direttamente dal medico nella sala operatoria
ed il risultato era disponibile in un tempo pari a cinque minuti dall’ inserimento
dei dati.
Venne dimostrato che la precisione del programma era del 91.8%, in contrasto
con quella dei medici che oscillava tra il 65% e l’80%. Di particolare interesse fu
il caso dell’appendicite non facile da diagnosticare, in cui il computer si dimostrò
non sbagliare mai nell’assegnare il paziente alla categoria in questione. Fino a
quel momento più di venti pazienti che non necessitavano di intervento, furono
operati per una diagnosi non corretta. Con l’introduzione dei personal computer ci
fu un ampia diffusione di questo sistema diagnostico. Con grande sorpresa però,
lo stesso sistema non riuscì ad ottenere i soddisfacenti risultati riscontrati a Leeds.
La ragione più probabile di questa discrepanza fu addebitata alla differente
interpretazione dei dati da parte dei medici che accedevano al sistema.

MYCIN:
MYCIN è un sistema di consulenza, che utilizza un approccio completamente
differente. Si basa su una de-enfatizzazione della diagnosi per focalizzare
l’attenzione su una gestione appropriata di pazienti con malattie infettive. Gli
sviluppatori credevano che algoritmi lineari ed approcci statistici non fossero
adatti al contesto clinico, in quanto spesso, anche gli esperti erano in disaccordo
su quali decisioni prendere per la gestione di un problema specifico relativo ad un
paziente, soprattutto prima della ricezione di un insieme di risultati relativi. La
ricerca, in quegli anni, stava sviluppando nel campo dell’intelligenza artificiale,
una sottoclasse di computer basata su una manipolazione di simboli astratti
piuttosto che di calcoli.
La conoscenza di base relativa alle malattie contagiose, in MYCIN, era
rappresentata sottoforma di regole di produzione, ognuna delle quali conteneva un
“pacchetto” di conoscenza, ottenuto dal confronto tra molti medici. Una regola di
produzione è una semplice dichiarazione condizionale, che lega le osservazioni
10
alle inferenze associate che possono essere progettate. La potenza di MYCIN
derivava da tali regole in modi diversi:
-
MYCIN determinava quali regole usare e come legarle insieme per
prendere decisioni su di un caso specifico.
-
Le regole spesso fornivano una spiegazione coerente del ragionamento di
MYCIN. Quelle che venivano applicate alla decisione corrente, erano
visualizzate in risposta alla domanda dell’utente. Sebbene le regole fossero
conservate in un formato leggibile alla macchina, poteva essere
visualizzata una traduzione di esse in lingua inglese.
-
Rimuovendo, modificando o aggiungendo regole, gli sviluppatori
potevano modificare la conoscenza della struttura del programma
rapidamente, senza una riprogrammazione o ristrutturazione di altre parti
della base di conoscenza.
Gli sviluppatori valutarono le performance di MYCIN, sulla selezione della
terapia per i pazienti con infezione batterica ematica e per quelli affetti da
meningite. In quest’ultimo studio, il risultato consigliato da MYCIN fu lo
stesso di quello consigliato dagli esperti.
Nonostante i risultati ottenuti, MYCIN, non fu mai utilizzato in ambito
clinico. Il programma è meglio visto come un iniziale esplorazione di metodi,
per catturare ed applicare una conoscenza mal-strutturata, al fine di risolvere
importanti problemi clinici. Sebbene il programma non fu mai utilizzato per lo
scopo relativo alla sua progettazione, diede il via ad un grande periodo di
ricerca e sviluppo negli anni 80’, che favorì la commercializzazione di sistemi
basati su regole, in una varietà di campi differenti da quello clinico.

HELP:
HELP è un sistema per l’integrazione di informazioni ospedaliere, sviluppato
presso LDS Hospital in Salt Lake City. Questo sistema aveva la capacità di
produrre degli “Alerts” quando venivano evidenziate anomalie nella cartella
clinica del paziente. Il suo impatto nel settore è stato immenso, tanto che la
maggior parte delle attività nel campo della biomedica utilizzano applicazioni
e metodologie derivanti da esso.
HELP aggiunge al convenzionale sistema delle cartelle cliniche, un
programma di monitoraggio e un meccanismo per la memorizzazione delle
decisioni logiche in moduli, detti “HELP sectors”. Quindi i dati del paziente,
11
sono disponibili agli utenti che desiderano conoscere informazioni specifiche
e i risultati, automaticamente stampati o comunicati tramite sistema. In
aggiunta, è presente un meccanismo di generazione “Event-driven” per la
gestione di tali “Alerts”. Inizialmente fu creato un vero e proprio linguaggio
per la gestione di HELP, il PAL. Successivamente fu adottato un formalismo
standard per codificare le regole decisionali, conosciuto come Arden syntax,
tramite il quale, era possibile scrivere regole che mettessero in relazione la
specifica situazione del paziente con le azioni che il medico doveva
intraprendere. Ogni “HELP sector” prese il nome di Medical Logic Module.
Ogni volta che erano disponibili nuovi dati relativi al paziente, il sistema
HELP esaminava se fossero soddisfatti i requisiti per invocare un MLM. Se
questo accadeva, il sistema valutava l’MLM per constatare se questo fosse
rilevante per un specifico paziente. La logica di questi MLM veniva sviluppata
da medici esperti. Un risultato generato con successo da un MLM includeva,
ad esempio, un “Alert” dovuto agli effetti indesiderati derivanti dall’azione dei
farmaci, all’interpretazione errata dei test di laboratorio oppure ad un errore di
calcolo della probabilità di malattia. Il risultato era comunicato al personale
attraverso il sistema di informazione dell’ospedale o tramite report scritti.
HELP è un ottimo esempio, di come l’integrazione del supporto decisionale
con altre funzioni di sistema, può aumentare l’efficacia e incoraggiarne
l’utilizzo. Gli “Alerts” venivano prodotti attraverso la catalogazione dei dati
del paziente, che potevano essere riutilizzati in un secondo momento.
In generale, sebbene HELP sia stata un eccezione, inizialmente la maggior
parte dei sistemi di supporto alle decisioni veniva utilizzata raramente dal
personale sanitario che vedeva quest’ ultimi con scetticismo. La successiva
evoluzione, che garantì un graduale cambiamento di pensiero nell’utilizzo dei
computer in ambito medico,è dovuta essenzialmente a quattro fattori:
1) L’emergenza di una workstation individuale, The World Wide Web e le
interfacce semplificate.
2) Il crescente riconoscimento da parte degli sviluppatori, che una parte della
tecnologia doveva fondersi in maniera trasparente con le pratiche dei
gruppi di lavoro chiamati ad adottarla.
3) Il crescente disagio tra gli operatori e gli organismi sanitari per quanto
riguarda il numero di informazioni di cui i medici necessitavano per
svolgere un lavoro esente da errori.
4) L’incremento dei costi di personale, soprattutto in caso di malattie che
richiedevano un trattamento difficile e costoso.
12
2.2 Una struttura per caratterizzare i sistemi di supporto alle
decisioni cliniche.
Per valutare in maniera adeguata uno strumento di supporto alle decisioni cliniche
o per capire l’insieme di problemi che possono influenzare le possibilità di
successo, è necessario disporre di una struttura organizzativa di tali programmi.
Un primo approccio consiste nella caratterizzazione del sistema, lungo cinque
dimensioni:
1)
2)
3)
4)
5)
Le funzioni offerte dal sistema.
Le modalità con cui viene offerto il supporto.
Lo stile di consultazione.
Il sottostante processo di scelta decisionale.
I fattori legati all’interazione uomo-computer.
I programmi di supporto alle decisioni ricadono generalmente in due categorie:
Quelli che assistono gli impiegati sanitari, determinando “cosa è vero” sul
paziente, e quelli che forniscono assistenza sul “cosa fare” per il paziente. Molti
sistemi aiutano i medici in entrambi i modi, ma la distinzione è importante, perché
il consiglio su “cosa fare” per un paziente, non può essere formulato senza
bilanciare i costi e i benefici delle azioni da intraprendere. La determinazione di
“cosa è vero” sul paziente, basata su un insieme fisso di dati già disponibili, può
teoricamente essere fatta senza la considerazione dei costi e dei rischi. Quindi un
vero programma di diagnostica, lascia all’utente il compito di decidere quali dati
raccogliere o se richiedere un insieme fisso di dati per tutti i pazienti. Comunque ,
cercare di produrre una diagnosi per i dati ottenuti e per un eventuale terapia, in
maniera del tutto indipendente dal processo di scelta tra queste due opzioni, è da
escludere.
Come per l’Abdominal Pain System e MYCIN, la maggior parte dei programmi
per il supporto decisionale ha assunto un ruolo passivo nell’aiutare i medici.
Secondo questo modello, il medico deve riconoscere quando il consiglio potrebbe
essere utile e, solo in quel caso, accedere al programma ( Il programma aspetta
l’utente). Il medico allora analizza il caso, dai dati presenti all’interno del
programma e richiede assistenza diagnostica e terapeutica.
Ci sono altre tecnologie, come HELP, che giocano un ruolo più attivo,
provvedendo al supporto decisionale come un sottoprodotto di attività di
monitoraggio o gestione dati. Tali sistemi non aspettano che i medici richiedano
formalmente assistenza, ma la forniscono senza laboriose procedure di
inserimento. Tali funzionalità sono possibili perché la logica decisionale del
sistema è integrata con un database comprensivo delle informazioni del paziente,
13
già raccolte da fonti diverse all’interno dell’ospedale. I professionisti,
generalmente, non richiedono assistenza da tali sistemi, poichè anziché ricevere
assistenza, devono evitare di produrre un numero eccessivo di “Alerts” per
problemi minori, già risolti all’interno della propria diagnosi. Tali report mendaci
possono distogliere l’attenzione del medico da problemi di maggiore importanza.
2.3 Stile di comunicazione.
I sistemi di supporto alle decisioni tendono ad operare secondo uno dei seguenti
due stili di interazione:

Consulting model: il programma si comporta come un consulente,
accettando i dati del paziente, possibilmente ponendo quesiti e generando
consigli per l’utente a proposito delle diagnosi o della gestione.

Critiquing model: Il medico ha un idea preconcetta di cosa sta succedendo
ad un paziente o quale piano di gestione sarebbe più appropriato. Il
computer agisce come un banco di prova per l’idea dell’utente,
esprimendo approvazione o suggerendo una motivata alternativa. Un
esempio di critiquing system fu ATTENDING, un programma autonomo
che criticava uno specifico piano anestetico per la selezione, induzione e
amministrazione dopo che tale piano era stato proposto dall’anestesista
che doveva gestire il caso.
Nello stile critico il programma si concentra maggiormente sul piano a cui
il medico è interessato. Questo modello può essere applicato anche
secondo impostazioni di monitoraggio attivo. Per esempio, HELP
monitorava le decisioni del medico sulla terapia farmacologica e suggeriva
soluzioni alternative.
2.4 Il processo Decision-Making.
Un ampia gamma di tecniche è stata utilizzata nella progettazione e
implementazione dei sistemi di supporto alle decisioni. Le logiche più
semplici hanno coinvolto l’uso di diagrammi di flusso specifici per il
problema, progettati dai medici e successivamente codificati per l’uso al
computer. Sebbene tali algoritmi siano stati utili per lo smistamento dei
14
risultati, essi sono stati largamente respinti dai medici perchè troppo “poveri”
per uso di routine. I metodi predominanti sono rappresentati dal modello
Bayesiano, dall’analisi decisionale, dalla rete neurale artificiale e
dall’intelligenza artificiale (AI). Solo nel 1960 fu riconosciuto che i computer
potevano essere usati per il calcolo delle probabilità basato sull’osservazione
del paziente, fino ad allora erano visti come semplici macchine di calcolo
numerico. Un gran numero di programmi diagnostici, basati sul ragionamento
di Bayes, furono sviluppati negli anni successivi. Poiché prendere la maggior
parte delle decisioni in medicina richiede la pesatura dei costi e dei benefici
delle azioni che potrebbero essere prese durante la diagnosi o nella gestione
della malattia, i ricercatori hanno sviluppato strumenti progettati sui metodi di
analisi decisionale. L’analisi decisionale aggiunge al ragionamento di Bayes
l’idea di decisione esplicita e di utilità associata con esito diverso che potrebbe
servire in risposta a quelle decisioni. Una prima classe di programmi è
progettata per l’uso delle stesse analisi, mentre una seconda classe utilizza
concetti di analisi decisionale all’interno di sistemi più grandi, progettati per
consigliare i medici non esperti in queste tecniche. In tali programmi, i
modelli decisionali sottostanti sono stati, generalmente, specificati prima, sia
sottoforma di alberi decisionali all’interno dei quali, sono numerate tutte le
possibili decisioni e le possibili ramificazioni di queste decisioni, sia
sottoforma di diagrammi di influenza.
Le reti neurali (ANNs) sono programmi che eseguono classificazioni,
prendendo in ingresso un insieme di risultati che descrivono un dato caso e
generando come uscita un insieme di numeri. Ogni uscita corrisponde alla
probabilità di una particolare classificazione di dati, di spiegare i risultati
ottenuti. Il programma esegue questa funzione propagando attentamente i
valori calcolati attraverso una rete di regole e nodi. La struttura della rete è
uniforme per ogni tipo di problema decisionale. I valori associati con ogni
nodo sono regolati cosi che la rete tende a generare la classificazione corretta
per ogni insieme di input. Le ANNs traducono un insieme di risultati in un
insieme di classificazioni consistenti con quei risultati. Sfortunatamente, non
c’è modo che un osservatore possa direttamente capire perché un ANN può
raggiungere una particolare conclusione. ANN ha vantaggi significativi,
quando la corretta diagnosi può dipendere da interazioni tra i risultati che sono
difficili da predire.
L’intelligenza artificiale, invece, è stata strettamente legala alla modellazione
dei processi logici da parte del computer. Studi psicologici di come i
professionisti si comportino durante la risoluzione di un problema, hanno
influenzato molte ricerche nell’AI medica. Di particolare interesse per lo
sviluppo dei sistemi per il supporto decisionale è il sottocampo dell’ AI che
concerne i sistemi basati sulla conoscenza. Un sistema basato sulla
15
conoscenza è un programma che codifica concetti derivati dagli esperti in un
campo e che usa quella conoscenza per fornire al tipo di problema l’analisi e
la consulenza dell’esperto. Il processo decisionale medico spesso richiede un
ragionamento in condizioni incerte. I sistemi basati sulla conoscenza, in
medicina, hanno conseguentemente incorporato gli schemi Bayesiani per
trattare situazioni di incertezza per quanto riguarda gli effetti delle invenzioni
proposte. La cosa più caratteristica dei sistemi basati sulla conoscenza è che
quest’ultima è codificata attraverso un modello qualitativo non numerico, di
come le inferenze si leghino per cercare conclusioni astratte sul caso. Quindi,
anziché modellare le relazioni tra i risultati del paziente e le possibili diagnosi
puramente in termini di associazioni statistiche o equazioni matematiche, i
sistemi basati sulla conoscenza possono rappresentare tali relazioni in termini
di strutture simboliche. Le regole di produzione, come in MYCIN, spesso
sono state usate per costruire i sistemi basati sulla conoscenza. La conoscenza
in un sistema di questo tipo, può includere relazioni probabilistiche tra i
sintomi e la malattia. Tipicamente tali relazioni sono argomentate da
altrettante relazioni qualitative quali causalità e tempo.
2.5 Interazione Uomo-Computer.
Non ci sono dubbi, che dal punto di vista storico conti più l’impraticabilità di
molti strumenti che il fallimento degli sviluppatori di trattare adeguatamente
aspetti logistici, meccanici e fisiologici dell’uso del sistema. Spesso, i costruttori
si sono concentrati primariamente sul creare programmi che potessero fornire
decisioni ottimali, ma questa è solo una parte per il successo del sistema.
Fortunatamente, c’è una crescente presa di coscienza sul fatto che un tale
strumento dovrebbe presentare un interfaccia semplice ed intuitiva, con cui
l’utente possa confrontarsi. Nella migliore delle situazioni, gli elementi di
supporto alle decisioni dovrebbero essere incorporati all’interno di un sistema più
grande che fa già parte della routine lavorativa dell’utente. Le difficoltà d’uso di
tali programmi hanno smorzato l’entusiasmo iniziale di un gran numero di utenti.
La soluzione a tale problema richiede una notevole sensibilità durante il processo
di progettazione, e di solito la risoluzione delle inadeguatezze a livello
istituzionale. L’avvento delle reti wireless ha consentito agli utenti l’accesso al
computer indipendentemente dalla posizione, attraverso strumenti quali i tablet,
ad esempio. Il rapporto uomo-computer offre nuove soluzioni attraverso una
realtà virtuale per la gestione delle operazioni sanitarie.
16
2.6 Costruzione di uno strumento per il supporto alle decisioni.
Nonostante i progressi evidenziati dalla ricerca nell’impiego dei computer in
ambito medico, parecchie barriere continuano ad impedire l’effettiva
implementazione di tali strumenti. Questi ostacoli includono quesiti irrisolti di
scienza e logistica. L’ acquisizione e la convalidazione dei dati del paziente
sicuramente è uno di questi. Tutti i compiti necessari all’acquisizione e
all’inserimento dei dati relativi ai pazienti svolte all’insegna della completezza,
sono limitazioni per gli operatori sanitari. Essi affermano che il loro uso del
sistema sarà limitato, a meno di non essere liberati dall’onere relativo
all’inserimento dati per concentrare la propria attenzione su problemi di maggiore
rilievo. Tuttavia, anche se i computer accettassero un libero input vocale, ci
sarebbero seri problemi per strutturarlo e codificarlo, derivanti ad esempio, dalla
semantica stessa. Molti operatori credono che una combinazione di parlato e
grafici, accoppiato con un ambiente di gestione integrato, impedendo il bisogno di
un inserimento dati ridondante su più computer all’interno dello stesso ospedale,
sarà il progresso chiave che attrarrà il personale sanitario all’utilizzo degli
strumenti computerizzati. Il problema dell’acquisizione dati va oltre l’inserimento
stesso. Un ostacolo primario è rappresentato dalla mancanza di modi
standardizzati di esprimere la maggior parte delle situazioni cliniche in una forma
che i computer possano interpretare. C’è una terminologia medica controllata che
gli operatori sanitari usano per specificare precise valutazioni diagnostiche,
procedure cliniche e altro ancora. Inoltre, c’è una terminologia non controllata
che cattura le sfumature della storia di un paziente o di una data malattia, che
riguarda sia risultati che esami clinici. Non ci sono sistemi di codifica che possono
riflettere tutti i dettagli dei progressi dei medici o delle infermiere. Dato che molte
delle informazioni all’interno della cartella clinica che sarebbero utili per supporto
alla decisione più approfondito, non sono disponibili in una struttura
comprensibile alla macchina, si hanno chiare limitazioni sui dati. Tuttavia, anche
cartelle cliniche completamente elettroniche possono non includere tutti i dati
rilevanti di un paziente, quindi anche questa è da ritenere una fonte di
informazioni incompleta.
17
2.7 Modellazione della conoscenza medica.
Gli operatori preposti all’acquisizione delle informazioni per un sistema di
supporto alle decisioni possono attestare la complessità della traduzione dal testo
ad una struttura appropriata per l’applicazione logica della conoscenza al
computer. La creazione di un sistema di supporto alle decisioni computerizzato
quindi, richiede un attività di modellazione sostanziale: Decidere quali distinzioni
cliniche e dati sono rilevanti, identificare i concetti e le relazioni tra essi da
esercitare ed accertare la strategia per la soluzione di un problema che può usare
la conoscenza medica per ricercare conclusioni appropriate. Non si può
raccogliere alcuna informazione dalla semplice lettura di un libro di testo. I medici
esperti stessi non possono verbalizzare la conoscenza necessaria a risolvere anche
casi comuni. Conseguentemente la costruzione di alcuni sistemi,
indipendentemente dalla metodologia decisionale sottostante, comporta lo
sviluppo di un modello sia per il comportamento che porta alla risoluzione del
problema, sia per la conoscenza clinica che fornirà le informazioni per la
risoluzione dello stesso. Il considerevole lavoro nell’informatica biomedica è
correntemente concentrato sulla progettazione di strutture che consentono ai
costruttori di sistemi di modellare la conoscenza che sarà acquisita prossimamente
dagli strumenti di supporto alle decisioni. Le metodologie astratte di modellazione
come Common KADS, sono state ampiamente adottate dagli sviluppatori per i
sistemi di supporto alle decisioni commerciali, particolarmente in Europa. Lo
sviluppo di strumenti computerizzati che possono assistere nella modellazione
della conoscenza clinica resta un attiva area di ricerca.
2.8 Estrazione della conoscenza medica.
I ricercatori stanno mettendo a punto metodi che faciliteranno lo sviluppo e la
manutenzione delle basi di conoscenza mediche. La rapida evoluzione della
conoscenza medica fa della gestione di questa un problema di particolare
importanza. I ricercatori hanno scoperto una varietà di programmi che
18
acquisiscono le basi di conoscenza per un programma di supporto alle decisioni,
dall’interazione diretta con l’esperto, con l’obiettivo di evitare il bisogno per un
programmatore di servirsi di un intermediario. Gli analisti devono prima lavorare
con i medici esperti, al modello per l’area di applicazione. Per esempio, all’inizio i
ricercatori usavano uno strumento per usi speciali, conosciuto come OPAL per
inserire e gestire la base di conoscenza di ONCOCIN, consulente per la
chemioterapia. Gli sviluppatori di OPAL, costruito all’interno dello strumento un
modello comprensivo per l’amministrazione della chemioterapia, permettevano ad
OPAL di trasformare il processo di estrazione della conoscenza per ONCONCIN
in questione e successivamente creare diagrammi di flusso sullo schermo del
computer. Durante la creazione di uno strumento come OPAL, per l’estrazione
della conoscenza da un dominio specifico, gli sviluppatori progettano il loro
modello per lo specifico sistema di supporto alle decisioni nell’area applicativa
prevista e poi creano o un programma che inserisca il modello a mano all’interno
dello strumento o che, inserisca il modello in un meta-strumento che genera
automaticamente come risultato speciale un secondo strumento per l’estrazione
della conoscenza basato su quel modello. Protégé, ad esempio, è un metastrumento che molti sviluppatori hanno usato per creare automaticamente uno
strumento di estrazione della conoscenza per un dominio specifico come OPAL,
che prende come input i modelli degli analisti delle aree di applicazione rilevanti.
2.9 Rappresentazione della conoscenza medica.
Tra gli obiettivi di ricerca in corso vi è il bisogno di perfezionare le tecniche di
computazione per codificare un ampia gamma di conoscenza usata nel
problem-solving dai medici esperti. Tuttavia le consolidate tecniche come
l’utilizzo dei frames o regole esistenti per la memorizzazione o ancora, la
conoscenza inferenziale, restano campi aperti per la ricerca. Per esempio, i medici
usano modelli mentali tridimensionali che mettono in relazione le parti del corpo e
gli organi, per interpretare meglio i dati e raggiungere una pianificazione
terapeutica adeguata. Una rappresentazione di tali modelli di conoscenza al
computer sono risultati essere particolarmente stimolanti. Analogamente di stesso
interesse, sono quei modelli che permettono un osservazione duratura nel tempo
dello stato della malattia di un dato paziente. I ricercatori continuano a sviluppare
metodi computerizzati per modellare tali compiti. Un altro importante fattore
rappresenta l’abilità umana nel sapere come usare la conoscenza. In medicina,
spesso questa abilità viene chiamata “Buon giudizio medico”, e la distinguiamo
propriamente dalla memorizzazione della conoscenza reale o dalla letteratura dei
dati. E’ altrettanto chiaro, che fornire ai computer tanta conoscenza non rende essi
19
“abili” nel relativo campo. In ambito medico in particolare, una migliore
conoscenza della psicologia umana relativa al problem-solving sta aiutando i
ricercatori a scoprire strumenti per il supporto decisionale che simulano il
processo che i medici esperti partoriscono dalle osservazioni sulle diagnosi o dai
piani di gestione.
2.10 Convalida delle prestazioni del sistema.
Molti osservatori sono spaventati dallo sforzo necessario per restare al passo con
la continua evoluzione della conoscenza in ambito medico. Il campo di
conoscenza, in questo settore, si sta ampliando a ritmo rapido e un sistema di
consulenza non aggiornato può fallire nel cercare di fornire assistenza, che può
risultare, quindi, obsoleta. Sebbene i ricercatori si preoccupano di tali
aggiornamenti in maniera costante, è anche vero che, altri organi professionali o
corpi nazionali hanno il compito di convalidare i dati raccolti e garantirne
l’integrità. Quando una base di conoscenza è valutata in maniera corretta, gli
sviluppatori studiano come valutare gli strumenti a proposito degli aggiornamenti
ricevuti. Se esiste uno standard di prestazione, studi formali possono confrontare
il consiglio fornito dal sistema di supporto con quello accettato dallo standard.
Questa tecnica è pertinente, maggiormente, per gli strumenti di diagnosi come
biopsia, chirurgia o autopsia, di cui i dati possono essere usati come standard. In
alcuni casi tale standard è più difficile da definire. Gli esperti possono dissentire a
riguardo per il proprio modo personale di trattare lo specifico paziente. Per questa
ragione gli operatori hanno sperimentato tecniche che mettono a confronto le
raccomandazioni del programma con quelle degli esperti. Nonostante questo, il
problema della valutazione rimane un settore in fase di sviluppo.
2.11 Integrazione di uno strumento per il supporto alle decisioni.
Il successo degli strumenti di supporto alle decisioni è legato all’integrazione di
quegli strumenti che vengono utilizzati comunemente. C’è il bisogno tangibile di
innovazioni in questo campo di ricerca per garantire un legame più profondo tra
gli strumenti computerizzati basati sulla conoscenza e i programmi progettati per
memorizzare, manipolare e fornire informazioni sullo specifico paziente. Ospedali
e cliniche usano un numero sempre maggiore di piccoli macchinari ottimizzati per
20
compiti differenti, la cui integrazione è legata a problemi di networking e
interfaccia. Il processamento dei dati del paziente sarà realizzato nel
collegamento di più macchine elettroniche con funzioni sovrapposte.
CAPITOLO 3. ESEMPI ILLUSTRATIVI DI SISTEMI DI
SUPPORTO ALLE DECISIONI CLINICHE.
Per illustrare i modi in cui le nuove tecnologie hanno influenzato l’evoluzione
degli strumenti di supporto alle decisioni, dobbiamo dividere l’intera gamma di
strumenti in due categorie di appartenenza, focalizzando l’attenzione, in
particolare su specifici applicativi:


Diagnosis management.
Patient management.
Quick Medical Reference supporta la risoluzione del problema diagnostico in
medicina generale interna, mentre DXplain, è un sistema diagnostico web in
continua evoluzione. EON, è un esempio rappresentativo di uno dei recenti
sistemi di supporto alle decisioni basato su linee guida, capace di fornire consigli
terapeutici per il trattamento della malattia, in accordo con i protocolli predefiniti.
Questi sistemi mostrano differenti architetture:
Quick Medical Reference è usato, primariamente, come un sistema indipendente
mentre, DXplain, è un sistema autosufficiente ma attualmente accessibile per lo
più attraverso World Wide Web. EON, infine, comprende un insieme di
componenti software progettati per essere integrati con un sistema di
informazione clinica più grande.
21
3.1 Diagnosi: Internist-1/QMR project e DXplain system.
Dimostreremo che il task di supporto alla diagnosi clinica usa due differenti
sistemi: Internist-1, che evolve successivamente in QMR, e DXplain, un
importante risorsa web.
Internist-1/QMR project.
Internist-1 era un grande programma diagnostico sviluppato all’università di
Pittsburgh nel 1970. Nei successivi anni diventò un sistema di supporto alle
decisioni conosciuto con il nome di Quick Medical Reference. Quest’ultimo fu
commercializzato per parecchi anni ed usato da un gran numero di professionisti e
studenti. Sebbene ad oggi il sistema non sia supportato attivamente, è stato
soggetto di importanti studi della comunità informatica in ambito medico.
L’obiettivo della versione originale, Internist-1, era quello di un modello di
diagnosi nel campo della medicina generale interna. Quest’ultimo conteneva circa
600 malattie e 4500 risultati correlati (sintomi e caratteristiche del paziente). In
media, ogni malattia era associata con un numero compreso tra 75 e 100 risultati.
Più risultati, comunque, come la febbre erano associati ad un numero maggiore di
patologie, spesso con vari livelli di probabilità. I medici sostenevano che questo
stesso sistema, non fosse abbastanza flessibile per costruire una semplice cartella
clinica, con conseguenti complicazioni diagnostiche. Da un'altra parte, era
impraticabile stimare le probabilità condizionali per tutte le malattie e i risultati
all’interno della conoscenza di base di Internist-1, poiché molte delle 600 malattie
presentavano sintomi rari e, di conseguenza, mal descritti dalla letteratura medica.
Per queste ragioni, gli sviluppatori crearono uno schema di punteggio che
codificasse le relazioni tra i risultati specifici e le malattie. La base di conoscenza
su cui poggiava Internist-1, era frutto della cooperazione tra medici esperti, medici
ordinari e studenti. Attraverso un attenta revisione della letteratura medica e dei
vari casi di discussione, essi determinarono una lista di risultati pertinenti per ogni
malattia. Ad ognuno di questi risultati fu assegnato un Frequency Weight e un
Evoking Strenght, valori che riflettevano rispettivamente, la forza di relazione tra
la malattia e i risultati. Il FW era un valore numerico compreso tra 1 e 5, dove 1
22
significava che il risultato appariva raramente nella malattia e 5 indicava che era
sempre presente. ES rifletteva la probabilità che un paziente che presentasse il
risultato, avesse la malattia in questione e che la malattia fosse la causa del
risultato. Se ES era pari a 0 significava che la malattia non sarebbe mai stata
diagnosticata sulla base del singolo risultato, mentre per ES uguale a 5 il risultato
era sicuramente, sintomatico della malattia. In aggiunta, ogni risultato nella base
di conoscenza era associato con un terzo valore detto Import Number, compreso
tra 1 e 5. Questo valore sottolineava l’importanza di anomalie che potevano
presentarsi durante il processo di diagnosi. Internist-1 quindi, utilizzava IN per
gestire le “false piste”, i problemi di bassa rilevanza, che a seconda del valore di
IN dovevano essere necessariamente gestite o possibilmente ignorate.
Figura 1. Un tipico profilo di malattia in Internist-1. I numeri accanto ai risultati rappresentano
rispettivamente l’Evoking Strenght (ES) e il Frequency Weight (FW). La suddetta immagine mostra un
estratto dal profilo malattia per cisti Echinococco.
Figura 2. Interpretazione del Frequency Weight.
Fonte: Miller, R.A., People, H.E., Myers J.D. Internist-1: an experimental computer-based diagnostic
consultant for general internal medicine. New England Journal of Medicine, 307:468.
23
Figura 3. Interpretazione dell’ Evoking Strenght.
Fonte: Miller, R.A., People, H.E., Myers J.D. Internist-1: an experimental computer-based diagnostic
consultant for general internal medicine. New England Journal of Medicine, 307:468.
Figura 4. Interpretazione Import Number.
Fonte: Miller, R.A., People, H.E., Myers J.D. Internist-1: an experimental computer-based diagnostic
consultant for general internal medicine. New England Journal of Medicine, 307:468.
Basato su queste semplici misure, Internist-1 usava uno schema di punteggio
simile ad un approccio ipotetico-deduttivo. I medici avrebbero inizialmente, avuto
accesso ad un insieme di risultati dai quali il programma avrebbe estrapolato una
diagnosi iniziale. Successivamente, lo stesso programma avrebbe selezionato
appropriati quesiti da porre, scegliendo in un insieme di strategie basate su come
le malattie venissero considerate e come fossero allineate con i dati disponibili del
paziente attuale. Il programma, considerato il costo ed i rischi dei test, cosi come i
benefici, chiedeva i dati relativi allo storico del paziente e agli esami fisici, prima
di raccomandare test o procedure invasive di diagnosi. Un importante
caratteristica, non implementata nei programmi diagnostici precedenti, era
l’abilità di Internist-1, di accantonare alcuni risultati non ben spiegati dalla
diagnosi corrente e riesaminarli dopo aver emesso una diagnosi iniziale di base.
Quindi, Internist-1, avrebbe potuto diagnosticare più malattie coesistenti
all’interno dello stesso paziente. Usando queste semplici strutture conoscitive e
schemi di punteggio, Internist-1 dimostrava ottime performance diagnostiche. In
uno studio, gli sviluppatori testarono il programma su 19 casi di difficile diagnosi
24
presi da un famoso giornale medico. Per i 19 pazienti era stato fatto un totale di 43
diagnosi diverse, delle quali Internist-1, ne identificò 25 in maniera corretta. A
confronto, i medici che avevano curato tali pazienti, avevano fatto appena 28
diagnosi corrette, e gli esperti che avevano partecipato alla stesura dell’articolo ne
avevano identificate un massimo di 35. Il programma fu creato per funzionare
solo su grandi mainframe computer e quindi non adatto per un uso diffuso. Nel
1980, lo stesso programma fu adattato per funzionare sui personal computer, con
il nome di QMR.
A differenza di Internist-1, che era progettato per provvedere solo alla diagnosi
del paziente, QMR poteva servire gli operatori sanitari in tre modi:



In modo base, come sistema di consultazione esperto.
Poteva essere usato come un libro di testo elettronico, catalogando le
caratteristiche dei pazienti al verificarsi di una data malattia o al contrario,
riportando quali delle 600 malattie potevano essere associate con le
caratteristiche date.
Come una scheda medica elettronica, poteva essere combinato con poche
caratteristiche o malattie e determinare le implicazioni. Ad esempio,
l’operatore poteva specificare due problemi medici, apparentemente
incorrelati ed ottenere informazioni su come le malattie avrebbero potuto
coesistere, sotto le giuste circostanze , dando luogo ad entrambi i
problemi.
Gli sviluppatori di QMR hanno sostenuto che l’uso del sistema come
riferimento elettronico è di gran lunga più importante dell’utilizzo del
programma stesso come consulente. Infatti, molte delle caratteristiche di
consulenza presenti in Internist-1, furono rimosse. Ad esempio, QMR non
poneva domande direttamente all’operatore al fine di perseguire una diagnosi
e non tentava di valutare se fosse presente più di una malattia al tempo stesso.
25
Figura 5. Una tipica lista di associazioni di QMR, un sistema che permette ai medici di richiedere un
esplorazione della base di conoscenza per le associazioni che potrebbero essere clinicamente rilevanti.
Per esempio, come qui mostrato, il medico ha richiesto le malattie polmonari che potrebbero essere
associate con la diarrea cronica. La lista risultante, generata da QMR dinamicamente, è utile al medico
stesso, che potrebbe altrimenti trascurare le relazioni suggerite.
26
DXplain.
È un sistema di supporto alle decisioni sviluppato presso il Laboratory Of
Computer Science nel Massachussetts General Hospital.
Fu inizialmente descritto dagli sviluppatori come “Il fratello povero di Internist1”. Nonostante questa rappresentazione, le capacità del programma sono
abbastanza sofisticate. Dato un insieme di risultati clinici, DXplain produce una
lista classificata di diagnosi che può spiegare i sintomi presentati dal paziente.
DXplain fornisce una giustificazione del perché ognuna di queste malattie
potrebbe essere considerata, suggerendo quali ulteriori informazioni cliniche
potrebbe essere utile raccogliere in proposito e catalogando quali manifestazioni
cliniche, se ce ne sono, potrebbero essere atipiche per la data malattia. Il
programma non offre consulenza medica, come QMR, ma trae vantaggio da un
dababase costruito sulla probabilità di oltre 4500 manifestazioni cliniche associate
a circa 2000 differenti malattie, una base di conoscenza relativamente più ampia
di quella di QMR. Il sistema adotta una forma modificata del ragionamento di
Bayes per fornire diagnosi attraverso un algoritmo. DXplain è stato implementato
sia nella versione autosufficiente che in quella accessibile attraverso web. La base
di conoscenza e l’interfaccia utente sono state migliorate ed adattate secondo un
insieme di commenti utente. DXplain è in uso in molti ospedali e scuole, per lo
più per scopi educativi, ma anche per consulenza clinica. E’ chiaramente lo
strumento più utilizzato nel supporto alla decisione medica. Il programma ha sia
la funzione di libro di testo elettronico sia un sistema di referenza medica. Nel
primo caso, può fornire descrizioni della malattia, enfatizzando i sintomi che
incorrono in essa, l’eziologia, la patologia e la prognosi. Il programma fornisce,
inoltre, circa 10 recenti riferimenti bibliografici, ritenuti appropriati per le
specifiche malattie. In aggiunta, può fornire una lista di malattie che dovrebbe
essere considerata al manifestarsi di ognuno dei possibili 5000 sintomi.
27
Figura 6. Un immagine di una sessione di DXplain. L’utente ha inserito sei risultati, aiutato da un
vocabolario medico standard che verifica le stringhe inserite da tastiera. DXplain presenta una lista delle
malattie comuni probabili e di alcune malattie più rare corrispondenti ai risultati inseriti. Le note
mostrano alcuni sintomi pertinenti ai risultati trovati, che potrebbero o non essere presenti al fine di
migliorare la qualità del report.
3.2 Gestione del paziente: architettura basata su linee guida e
sistema EON.
Le linee guida in medicina sono il metodo più potente per la standardizzazione e il
miglioramento della qualità nella cura al paziente. In accordo con la definizione
dell’ istituto della medicina, esse sono “Dichiarazioni sistematicamente sviluppate
per assistere i professionisti e le decisioni mediche per un appropriata assistenza
sanitaria in circostanze cliniche specifiche”. Le linee guida tipicamente presentano
approvazione medica riguardo al monitoraggio, la diagnosi o la gestione, per un
periodo esteso di tempo, di pazienti con un particolare problema clinico, bisogno
o condizione. Queste, dunque, sono particolarmente utili per i pazienti che
richiedono lunghi periodi di gestazione, in particolare, in caso di malattie
croniche. La loro applicazione, consiste nel collezionare e interpretare un numero
considerevole di dati nel periodo di tempo in cui il paziente è in cura, applicando
piani terapeutici o diagnostici standard in maniera episodica, rivisitandoli quando
e se necessario.
28
3.3 Sistemi per la gestione del paziente basati su linee guida.
E’ ora risaputo, che le linee guida sono il miglior modo per incrementare la
qualità dell’assistenza sanitaria in maniera del tutto conforme con un appropriata
pratica medica, riducendo, inoltre, i costi crescenti relativi alla cura stessa.
L’utilità di questo approccio è osservabile, ad esempio, nella registrazione degli
ordini farmaceutici. In tale contesto, anche semplici promemoria hanno effetti
potenti. I ricercatori infatti, hanno dimostrato un significante incremento di
adesioni nell’utilizzo di linee guida per la prevenzione, come ad esempio, nel caso
dei vaccini influenzali o nell’integrazione all’interno del sistema, di “Warnings”
per la gestione degli ordini ospedalieri. La maggior parte delle linee guida sono
rappresentate sottoforma di testo, non facilmente accessibili, quindi, dagli
operatori sanitari. Inoltre, anche quando le stesse appaiono in formato elettronico
e nonostante questo possa essere disponibile online, i medici raramente hanno il
tempo ed i mezzi per decidere quale delle tante linee sia più appropriata per il
proprio paziente e cosa comporterebbe l’applicazione di essa sullo stesso. Per
sostenere il bisogno degli operatori sanitari e la qualità della cura, sono necessari
strumenti di elaborazione delle informazioni più complessi. A causa delle
limitazioni tecnologiche correnti, l’analisi non è flessibile. C’è un urgente bisogno
di facilitare la diffusione del metodo basato su linee guida e la loro applicazione
usando macchinari capaci di leggere rappresentazioni e metodi computazionali.
Questi compiti includono specificità nella gestione, recupero delle linee guida
appropriate per il dato paziente, applicazioni run-time e una valutazione a
posteriori sulla qualità dell’applicazione delle linee guida stesse. L’assistenza
sanitaria basata su linee guida implica la creazione di un dialogo tra il medico e il
sistema di supporto, ciascuno dei quali ha caratteristici punti di forza. Ad
esempio, i medici hanno un accesso migliore ad alcuni tipi di informazione
specifici, alla conoscenza generale e al senso comune. I sistemi automatizzati
hanno un accesso più veloce e più accurato a linee guida dettagliate e possono
sfogliare, facilmente, lo storico di un paziente. C’è quindi una grande sinergia tra
l’essere umano e la macchina con l’uso del sistema delle linee guida. Gli
sviluppatori che codificano la conoscenza, spesso hanno bisogno di provvedere
alla semplicità del sistema di supporto alle decisioni nella gestione del paziente,
ad esempio, attraverso avvertimenti e promemoria. Il processo cerca all’interno
del database una situazione relativa al paziente, tale da attivare una specifica
regola per la gestione della condizione evidenziata all’interno della situazione
stessa. Sebbene tale approccio basato su regole sia stato utilizzato con successo
29
sin dai tempi di MYCIN, lo sviluppo e la gestione di un gran numero di regole
può essere difficile. Le interazioni tra le regole possono avere una gamma di
effetti inaspettata, che porta ad un comportamento imprevisto del sistema quando
le stesse regole sono aggiunte o cancellate da una base di conoscenza
precedentemente corretta. In generale, gli approcci basati su regole per la
rappresentazione di linee guida mediche, come Arden Syntax, non includono una
rappresentazione intuitiva della logica delle linee guida, ne della semantica per i
differenti tipi di conoscenza rappresentata e ne dell’abilità nel rappresentare e
riusare le linee guida stesse e i loro componenti. Inoltre alcuni di essi, non
supportano l’applicazione di linee guida per un periodo esteso di tempo,
necessaria per i pazienti che presentano malattie croniche. Tuttavia, le regole,
sono un eccellente quanto semplice opzione. Quando si costruiscono sistemi di
supporto alle decisioni comprensivi di linee guida, spesso è di aiuto vedere tali
linee come uno scheletro riutilizzabile, cioè come un insieme di piani a vari livelli
di astrazione che, quando applicati ad un particolare paziente, hanno bisogno di
essere raffinati da un medico per il periodo di tempo necessario, lasciando un
ampio margine di flessibilità nel raggiungimento di particolari risultati. Un altro
punto di vista è quello in cui le linee guida rappresentano un insieme di vincoli
riguardanti il processo di applicazione e il risultato desiderato, cioè possono essere
viste come l’intenzione degli autori delle stesse di garantire una corretta
amministrazione della terapia. I vincoli spesso seguono una linea temporale o
richiedono azioni che devono essere applicate per lunghi periodi. Sono state
sviluppate parecchie architetture per l’applicazione automatizzata delle linee
guida, ognuna della quali assume un modello esplicito per la rappresentazione
della conoscenza.
3.4 Un architettura basata su linee guida per la gestione del
paziente: EON SYSTEM.
Molti degli attuali approcci per rappresentare la conoscenza basata su linee guida
in medicina attraverso l’utilizzo di un computer, sono costruiti su idee esplorate
per un particolare sistema di supporto alle decisioni conosciuto come EON.
Sviluppato negli ultimi 20 anni, EON è un sistema di seconda generazione basato
sulla conoscenza, che aiuta i medici nella cura del paziente, i quali sono trattati in
maniera conforme ai protocolli delle linee guida. A differenza dei sistemi come
MYCIN o QMR, EON non è un sistema autosufficiente. Esso costituisce un
insieme di componenti software che devono essere incorporati all’interno di un
30
sistema di informazione clinica che gli stessi operatori sanitari usano per accedere
ai dati relativi ai pazienti.
Figura 7. Architettura EON. Consiste in un numero di componenti il problem-solving che condivide una
stessa base di conoscenza protocollo. Il protocol Domain Model, creato con il sistema Protégé, definisce il
formato della base di conoscenza protocollo. Lo stesso modello definisce anche lo schema per il Database
Mediator, un sistema che canalizza il flusso dati del paziente tra i componenti e un database relazionale.
L’intera architettura è integrata all’interno di un sistema di informazione.
L’architettura di EON si basa su componenti software che condividono la stessa
base di conoscenza.




La base di conoscenza protocollo fornisce le fasi rappresentative di un
intervento, fasi di valutazione che specificano i dati necessari da rilevare
per valutare o diagnosticare un paziente.
Il componente di pianificazione terapia può avere diversi valori di stato:
attivo, completato, abortito o sospeso ed indicano a che punto si trova
l’intervento.
Il componente di determinazione dell’eleggibilità fornisce i criteri di
eleggibilità per il paziente.
Le regole di revisione possono modificare lo stato corrente di un
intervento o modificare delle proprietà quali, ad esempio, la dose di un
determinato farmaco.
31


Le “Conditions” contengono le condizioni logiche per passare da uno step
di protocollo ad un altro per apportare modifiche all’intervento.
Il database Mediator incanala il flusso di dati del paziente tra i vari
componenti.
La base di conoscenza, quindi, codifica le informazioni protocollo in modo che
tutti i componenti possano esaminarne una condivisione. Il componente per la
pianificazione della terapia accede al protocollo della base di conoscenza per
identificare i potenziali piani di intervento appropriati per il paziente in questione.
Successivamente il componente di determinazione eleggibilità consulta la stessa
base di conoscenza per identificare i fattori che stabiliscano l’adeguatezza del
protocollo e in tal caso, accede ai dati del paziente per accertarsi che il protocollo
possa avere esito positivo. Il Database Mediator serve da condotto tra i
componenti e il database che memorizza tutti i dati del paziente. Il Mediator isola
i componenti di EON, risolve molti dei problemi logistici di interrogazione a
proposito dei dati e fornisce un significato in termini di relazioni temporali tra
essi. Inoltre, comprende esso stesso all’interno, un “Problem-Solver” per
l’indirizzamento dello specifico compito di astrazione dei dati in concetti di
livello più alto
( Resume System ). Quindi domande come “Il paziente è
affetto da più di due settimane da tale sintomo?” possono ricevere una risposta
direttamente dal Mediator stesso. I componenti in EON sono progettati in modo
che essi possano essere mescolati e abbinati per creare differenti funzionalità di
supporto alla decisione. Per esempio, i componenti per la pianificazione
terapeutica e quelli per la determinazione dell’eleggibilità, insieme con le basi di
conoscenza per il protocollo di cura dell’AIDS e HIV, hanno formato elementi per
il supporto alle decisioni di un sistema chiamato THERAPY-HELPER. Questo
sistema conteneva una cartella clinica elettronica con la quale i medici potevano
accedere alle informazioni del paziente, al momento di ogni visita presso un
ambulatorio specializzato nella cura dei pazienti affetti da AIDS. T-HELPER
avrebbe invocato i componenti di EON per generare specifiche raccomandazioni
riguardo alla terapia del paziente. Se il paziente non era in quel momento idoneo
per i protocolli applicabili, T-HELPER avrebbe indicato quei protocolli per il
quale il paziente fosse stato potenzialmente eleggibile. Per quei protocolli ai quali
il paziente era già iscritto, il sistema avrebbe indicato quale terapia sarebbe dovuta
essere somministrata, dato i requisiti del suddetto protocollo, il corrente stato di
terapia del paziente e la sua situazione clinica. In altri esperimenti, lo stesso
componente relativo al piano terapeutico e alla determinazione di eleggibilità era
usato in congiunzione con una base di conoscenza protocollo del cancro al seno.
L’architettura di EON rese possibile collegare semplicemente questi moduli
sviluppati precedentemente e usarli in congiunzione con le nuove basi di
conoscenza sul cancro al seno. Quindi, i componenti di EON non funzionavano
come sistemi indipendenti ma erano incorporati all’interno di sistemi
32
computerizzati che potevano invocare gli stessi componenti quando appropriato.
L’architettura di EON è stata scelta per portare il supporto decisionale basato su
linee guida in parecchi centri medici per i veterani di guerra negli Stati Uniti.
L’EON Middleware, un insieme di programmi che fungono da intermediari tra
diverse applicazioni e componenti software, forma la base del sistema ATHENA
per la gestione dell’ipertensione, in accordo con le linee guida nazionali.
L’interfaccia utente di ATHENA è integrata con quella di VISTA, il sistema di
informazione clinica dei Veteran Affairs, per fornire una panoramica intuitiva dei
dati clinici rilevanti del paziente per il trattamento dell’alta pressione sanguigna.
L’interfaccia mostrava anche suggerimenti specifici per i medici riguardo gli
interventi clinici che essi potevano intraprendere per garantire che la cura fosse
consistente con le linee guida dell’ipertensione memorizzate nella base di
conoscenza del programma. La base di conoscenza di ATHENA memorizza linee
guida per i criteri di ammissibilità, stratificazione del rischio, valore di pressione
arteriosa, uso di farmaci e criteri per la selezione e modifica del trattamento. La
modularità dell’architettura dei EON lo rende relativamente lineare per l’aggiunta
di nuovi componenti, con l’ampliarsi della conoscenza.
Figura 8. Un esempio dell’interfaccia del sistema ATHENA. ATHENA fornisce supporto decisionale per la
gestione dell’ipertensione usando l’architettura EON. Nell’immagine, l’utente ha inserito il valore di
pressione sanguigna del paziente più recente ed il sistema ha offerto aiuto basato su linee guida mediche.
33
Sebbene può essere facile applicare i componenti di EON a nuovi tipi di
conoscenza, creare tali basi di conoscenza può essere difficile. Fortunatamente,
l’acquisizione della conoscenza per il sistema EON è facilitata da un ambiente di
sviluppo conoscitivo, chiamato Protégé. Questo fornisce un insieme di strumenti e
una metodologia per costruire sistemi basati sulla conoscenza, di cui EON è un
esempio.
L’uso di Protégé inizia quando gli sviluppatori creano un modello astratto per
l’area applicativa interessata. Come mostrato nella precedente immagine, c’è un
modello comune per tutte le basi di conoscenza protocollo processate da EON.
Questo modello, specifica i concetti necessari per definire protocolli clinici in un
dato campo della medicina. Ad esempio, la costruzione del sistema di supporto
del cancro al seno richiedeva la creazione di un modello che definisse i concetti
comuni tra i protocolli per il cancro al seno. I modelli servono come punto di
inizio per la generazione di strumenti computerizzati speciali che supportano gli
sviluppatori nella costruzione e nella gestione delle basi di conoscenza protocollo.
Nell’approccio usato da Protégé, gli sviluppatori prima creano un modello
generale di concetti e relazioni che caratterizzano un particolare area applicativa.
Un modulo in Protégé, prende come input tale modello e genera come output uno
strumento su misura basato su quello stesso modello, al quale gli sviluppatori
possono accedere per rivedere lo stesso modello protocollo. Questo strumento può
essere utilizzato dai medici stessi, in quanto lo strumento è prodotto direttamente
dal modello protocollo e allo stesso tempo gli sviluppatori possono aggiornare ed
accrescere tale modello con un nuovo strumento per l’acquisizione della
conoscenza derivante dai cambiamenti corrispondenti. EON mostra come i sistemi
di supporto alle decisioni possano essere incorporati in sistemi di informazione
clinica più grandi. L’architettura semplifica anche l’uso degli standard emergenti
per la comunicazione via rete tra i moduli software, una tendenza nell’ingegneria
del software che diventerà di maggiore importanza nei prossimi anni.
L’accoppiamento tra l’architettura di EON e il framework di acquisizione per la
conoscenza di Protégé semplifica l’uso di strumenti speciali per accedere e gestire
le basi di conoscenza protocollo.
34
Figura 9. Una piccola porzione di un modello generico basato su linee guida mediche inserito all’interno
del sistema Protégé. La gerarchia delle voci sulla sinistra include concetti che costituiscono un kit di
partenza per costruire le descrizioni delle linee guida. Il pannello sulla destra, mostra gli attributi di ogni
concetto evidenziato sul pannello di sinistra. Il Domain model inserito in Protégé, riflette i concetti
comuni a tutte le linee guida, ma non include informazioni specifiche per la singola linea. Il domain model
completo è usato per generare automaticamente uno strumento per l’acquisizione della conoscenza come
mostrato in Figura 3.
35
Figura 10. Immagine di uno strumento generato da Protégé per l’acquisizione dei protocolli del cancro al
seno. Questo strumento è stato generato automaticamente da uno specifico Domain Model. Il protocollo
raffigurato specifica le conoscenze necessarie per un processo clinico al fine di confrontare gli effetti della
chemioterapia adiuvante convenzionale con quelli della chemioterapia al seguito del trapianto di midollo
osseo.
Con i progressi derivanti dalla ricerca nello sviluppo dei sistemi di supporto alle
decisioni , ci sarà un espansione delle aspettative sul fatto che gli stessi decisionmakers saranno capaci di rivedere e modificare le basi di conoscenza elettronica
che codificano le politiche di decision-making istituzionali. Come dimostrato da
EON, quel tipo di coinvolgimento diretto del personale clinico nella gestione della
conoscenza sarà richiesto incrementando l’uso dei sistemi come Protégé, che
possono semplificare la creazione e la modificazione degli strumenti per costruire
la conoscenza necessaria.
36
CAPITOLO 4: Conclusioni.
4.1 I decision support systems nei prossimi dieci anni.
Dopo più di 40 anni di ricerca sui sistemi di supporto alle decisioni, i ricercatori
hanno imparato che una gran quantità di difficoltà divide il programmatore
dall’implementare con successo nuovi programmi. Negli anni 70’ e 80’ c’è stato
un maggiore progresso tecnologico e etico nel campo del supporto decisionale
computerizzato. L avanzamento tecnologico per la rappresentazione,
l’acquisizione della conoscenza ed il ragionamento automatizzato hanno spianato
la strada per approfondimenti relativi alla modellazione, codifica e diffusione dell’
esperienza umana in una forma comprensibile alla macchina. Sebbene
inizialmente, gli stessi programmatori sollevassero preoccupazioni sulla riluttanza
del rapporto uomo-computer in campo medico, la situazione è stata oggetto di un
cambiamento radicale verso la fine del secolo scorso. Il modello basato su linee
guida è attualmente onnipresente in campo medico. Gli stessi medici sono spesso,
altamente motivati nell’utilizzarlo, per fornire al paziente la migliore soluzione
possibile, derivante da un ampia base di conoscenza per lo più costruita sull’
esperienza degli esperti nel campo. Sebbene le linee guida risultino efficienti in
questo senso, meriti e demeriti restano all’abilità del medico nell’interpretare e
seguire queste stesse in maniera opportuna. In un era in cui il progresso
tecnologico comporta crescenti miglioramenti nella qualità dei nuovi strumenti, i
sistemi di supporto alle decisioni, come ad esempio quelli basati sull’architettura
EON, stanno assumendo un ruolo centrale nel fornire assistenza. L’avvento del
World Wide Web ha reso i computer indispensabili nella routine dei praticanti.
Questo ne ha demistificato l’utilizzo fornendo un sistema di connessione tra
processori distribuiti e successivamente una base di conoscenza per client
“leggeri” di basso costo attraverso i quali è possibile accedere, usando un browser
comune, a diverse collezioni di informazioni in maniera uniforme. Ad un tratto, è
risultato quasi scontato l’utilizzo di programmi direttamente presso il punto di
cura, con la conseguente semplificazione delle procedure di accesso ad una vasta
gamma di sorgenti informative e sistemi di supporto alle decisioni. E’ stato
riconosciuto il potenziale educativo di tali sistemi, tanto da impiegare grosse
risorse per ampliare il campo di ricerca relativo. Il bisogno costante di migliorare
le tecniche adottate per la cura del paziente insieme con l’ormai onnipresente
tecnologia di informazione, hanno incoraggiato l’utilizzo dei sistemi di supporto
37
alle decisioni nelle università e nelle scuole di medicina di tutto il mondo. Nella
prossima generazione, per gli operatori sanitari, l’uso della tecnologia di
informazione, in molti aspetti della cura del paziente, costituirà la garanzia per
una corretta pratica medica. Internet continuerà ad aumentare l’influenza del
computer in tutti gli aspetti della società, collegando le tecnologie di informazione
delle grandi organizzazioni,attraverso Internet stesso o intranet vari, con le
comunità di pazienti. Internet porterà quindi, i sistemi di supporto alle decisioni
progettati per la cura del paziente direttamente nelle loro case e fornirà una
migliore comunicazione tra gli operatori sanitari all’interno degli ospedali. I
laboratori di ricerca continueranno ad esplorare nuove tecniche per migliorare
l’assistenza decisionale in ambito medico fornita attraverso Internet, facilitando
l’accesso alle informazioni sia per il paziente che per gli operatori sanitari stessi.
Già adesso, attraverso Internet è possibile per il paziente ricercare la più recente
informazione disponibile a proposito della malattia riscontrata e convertirla
elettronicamente per il personale sanitario o per altri pazienti stessi. L’emergente
onnipresenza di Internet nella cultura moderna sarà condizionata dalla tecnologia
sottostante con la quale i sistemi di supporto alle decisioni sono stati sviluppati. Ci
sono già ricerche in corso di come i software di supporto decisionale possano
essere assemblati da componenti precedentemente creati e testati. In futuro, i
depositari di tali componenti saranno memorizzati in librerie accessibili attraverso
Internet stesso. Le librerie Internet conterranno standards, terminologie
controllate, cosi come concetti utilizzati comunemente. La costruzione della
decisione clinica aiuterà a coinvolgere la ricerca nell’utilizzare queste librerie per
la costruzione e la configurazione di appropriati componenti riutilizzabili. Ci sarà
bisogno di una nuova tecnologia per il recupero delle informazioni, una che possa
aiutare i costruttori del sistema a localizzare e configurare software appropriati per
il supporto decisionale derivanti dalle diverse librerie rilasciate dai laboratori di
ricerca e organizzazioni sanitarie. Le considerazioni di come i componenti
specifici riusciranno ad usare i modelli di riconoscimento o i metodi di
ragionamento Bayesiano o AI saranno meno importanti rispetto alla creazione di
nuovi approcci per combinare questi stessi metodi al fine di incontrare i requisiti
di questi complessi sistemi di decision-making. Una maggiore comprensione del
comportamento organizzativo e del flusso di lavoro stimoleranno la creazione di
una nuova generazione di sistemi informatici in ambito clinico, che sarà integrata
facilmente nel ciclo di lavoro quotidiano dei medici stessi. Più importante, questi
nuovi sistemi di informazione diventeranno i veicoli per la scoperta della
tecnologia per il supporto decisionale dei prossimi decenni. Il vero concetto di
sistema di supporto decisionale sarà esso stesso sfumato, come assistente
intelligente capace di accrescere il giudizio degli operatori sanitari all’interno
della struttura ospedaliera. Il supporto alla decisione automatizzata prenderà il
posto di ogni azione di routine del medico stesso nell’accedere ai dati in maniera
discreta, trasparente e su misura della specifica situazione del paziente. Il futuro
38
dei sistemi di supporto alle decisioni dipende, quindi, dai progressi compiuti nello
sviluppare programmi utili e nel ridurre le barriere logistiche
dell’implementazione. Sebbene la decisione computerizzata aiuti i medici sotto
molti punti di vista, molti aspetti della pratica medica sono attualmente
fantascientifici. Non si sa ancora quali effetti, queste innovazioni, avranno
sull’educazione medica e sulla pratica stessa, ma i successi crescenti forniscono
un ottimistica visione di cosa la tecnologia farà per assistere i medici con
l’utilizzo di dati complessi e conoscenza. Le sfide di ricerca sono state identificate
più che chiaramente, e le implicazioni per l’educazione della medicina sono state
meglio capite. L’alfabetizzazione computerizzata degli studenti di medicina può
essere generalmente assunta, ma gli educatori sanitari ora, devono insegnare delle
basi concettuali di informatica biomedica, affinchè i loro laureati siano preparati
per un mondo tecnologicamente sofisticato. Ugualmente, abbiamo imparato molto
a proposito di cosa non è probabile che accada. La maggioranza dei ricercatori
capisce la natura mutevole e complessa della conoscenza medica, diventa più
chiaro che medici esperti saranno sempre richiesti come elementi di un rapporto
cooperativo tra i medici ordinari e lo strumento di supporto. Non ci sono prove
che le capacità della macchina saranno sempre uguali alle abilita di pensiero
umane nel trattare situazioni sotto condizioni inaspettate, nell’ integrare dati visivi
e audio che rivelano sottigliezze sui problemi del paziente, o nell’affrontare
problemi etici e sociali che sono spesso la chiave determinante delle decisioni
mediche. Le considerazioni come queste saranno sempre importanti alla pratica
della medicina poiché i medici avranno a che fare sempre con informazioni
incomprensibili alla macchina, senza l’esperienza dei medici stessi.
39
Bibliografia.
Abbasi M. M., Kashiyarndi S., “Clinical Decision Support Systems: A discussion
on different methodologies used in Health Care.”, Master level thesis, Mid
Sweden University, 2010.
Miller, R.A., People, H.E., Myers J.D., “Internist-1: An Experimental ComputerBased Diagnostic Consultant For General Internal Medicine.”, in New England
Journal of Medicine, 1982, 307:468.
Musen Mark A., Shahar Yuval, Shortliffe Edward H., “Clinical Decision-Support
Systems”, in Shortliffe Edward H., Cimino James J., Biomedical Informatics:
Computer Applications in Health Care and Biomedicine, New York, Springer,
2006, pp 698:736.
Power Daniel J., Decision Support Systems: Concepts and Resources for
Managers, Westport, QUORUM BOOKS, 2002.
40