I sistemi di gestione delle Clinical Guideline esistenti - IRPPS

Consiglio Nazionale delle Ricerche
Stefano Anzi
Daniela Luzi
Fabrizio L. Ricci
ISTITUTO DI RICERCHE
SULLA POPOLAZIONE
E LE POLITICHE SOCIALI
I sistemi di gestione
delle Clinical
Guideline esistenti in
letteratura:
analisi e confronti
Working Paper
W.P.3/2004
Settembre 2004
I sistemi di gestione delle Clinical Guideline esistenti in letteratura: analisi e confronti
Stefano Anzi*, Daniela Luzi**, Fabrizio L. Ricci**
Sommario:
Il rapporto presenta una rassegna dei sistemi di gestione delle linee guida cliniche presenti in
letteratura. I vari sistemi sono descritti e confrontati tra loro evidenziandone sia i vantaggi che
svantaggi nel loro uso.
parole chiave. Linee guida
Abstract:
The paper reviews the literature concerning clinical guidelines management systems. The different
systems are described and compared in order to highlight advantages and disadvantages of their
application.
key-word: guidelines
* DIS – Facoltà di Ingegneria, Università di Roma “La Sapienza”, Via Eudossiana, 18, 00100 Roma, Italy
E-mail: [email protected]
**IRPPS-CNR - V. Nizza, 128, 00198 Roma, Italy
Tel.: +39 - 06 4993.2746/2814 - Fax: +39 - 06 85834506
E-mail: [email protected], [email protected]
2
INDICE
1. INTRODUZIONE
5
2. SCOPI DELLE CLINICAL GUIDELINE
6
3. CRONOLOGIA DEI SISTEMI DI GESTIONE DELLE GUIDELINE
7
4. L’ARDEN SYNTAX
8
4.1 Problemi per la condivisione di basi di conoscenza medica
9
4.2 Uso di una rappresentazione procedurale
9
4.3 Organizzazione di un MLM
10
4.4 Caratteristiche d’implementazione dell’Arden Syntax
11
5. IMPLEMENTAZIONE DI MLM
12
6. IL SISTEMA GEODE-CM
13
7. IL SISTEMA MBTA
13
8. IL SISTEMA EON
14
9. IL PROGETTO GLIF: GLIF – GLIF2 – GLIF3
15
9.1 Spiegazione del progetto GLIF
17
9.2 GLIF 2
17
9.3 Il modello GLIF2
18
9.4 Analisi delle lacune di GLIF2
20
9.5 GLIF3
21
9.5.1 Cambiamenti nel modello dell’oggetto
9.5.2 Cambiamenti nella sintassi
21
22
10. IL SISTEMA GEM
22
11. LE TABELLE DI DECISIONE E LE TABELLE DI DECISIONE AUMENTATE
26
11.1 La tabella di decisione: descrizione
26
3
11.2 La tabella di decisione aumentata
30
11.3 Vantaggi delle tabelle di decisione aumentate
31
12. ALTRI SISTEMI DI GESTIONE DELLE GUIDELINE
31
12.1 Il sistema PROforma
32
12.2 Il sistema ONCOCIN
32
12.3 Il sistema Prodigy - Prodigy3
33
12.4 Il sistema Asbru
35
12.5 Il sistema DILEMMA
35
13. CONFRONTO TRA LE CARATTERISTICHE DEI SISTEMI
36
13.1 Primo confronto
36
13.2 Secondo confronto
38
14. LA FILOSOFIA DI RAPPRESENTAZIONE TRAMITE WORKFLOW
39
15. CONCLUSIONI
39
BIBLIOGRAFIA
41
4
1. Introduzione
La Clinical Guideline (CG) e il Clinical Trial (CT) a livello concettuale sono molto
diversi e le principali differenze, che si possono indicare, riguardano i seguenti aspetti:
• Scopi
• Obiettivi
• Sviluppo di sistemi di gestione ad hoc
Il Clinical Trial.
Un CT è “una qualsiasi indagine o studio su soggetti umani, volto a scoprire o verificare
gli effetti clinici, farmacologici e/o farmacodinamici di un prodotto […] con l’obiettivo di
accertarne la sua efficacia e/o la sua sicurezza” [1,2].
La Clinical Guideline.
Le CG sono state definite dall’U.S. Institute of Medicine come “asserzioni sviluppate
sistematicamente per assistere i professionisti e i pazienti nelle decisioni di cura appropriata
nello specifico” [3].
Il Clinical Trial rappresenta sempre un processo di sperimentazione di un farmaco,
oppure il processo di sperimentazione di un trattamento terapeutico per la cura di una
determinata patologia. In quanto sperimentazione, le attività e le azioni di cui è costituito un
protocollo (così è anche detto un Trial) devono essere eseguite pedissequamente e la loro
successione temporale è rigorosamente stabilita dal protocollo stesso. Il CT deve essere
definito, quindi, in maniera molto dettagliata in modo tale da lasciare all’utente medico
pochissima libertà di scelta.
La Clinical Guideline, invece, è utilizzata nella prassi medica giornaliera ed, in quanto
linea-guida, indica qual è il miglior modo di cura per una determinata patologia. Le CG,
allora, non devono essere descritte in maniera dettagliata come i CT e, al contempo,
lasciano all’utente medico più libertà rispetto ai CT.
E’ evidente che, dal punto di vista della prassi medica giornaliera, le Guideline hanno un
importanza rilevante, mentre i Clinical Trial rivestono una notevole importanza dal punto di
vista della sperimentazione di nuovi sistemi di cura o di nuovi farmaci.
Questo rapporto analizza le caratteristiche dei sistemi di gestione (quasi tutti riguardanti
CG) esistenti in letteratura.
Nella prima parte vengono descritti, in ordine cronologico, i primi sistemi di gestione
delle CG e successivamente vengono evidenziati gli studi sui quali si è basato lo sviluppo di
nuovi e più sofisticati sistemi per la gestione delle CG.
L’analisi prende in considerazione, inizialmente, l’Arden Syntax, il concetto di MLM
(Medical Logic Module) e la loro implementazione. Successivamente vengono analizzati i
tre sistemi GEODE-CM, MBTA ed EON sui quali si basa lo studio del progetto GLIF.
Viene analizzato il progetto GLIF con le sue evoluzioni in GLIF2 e GLIF3. In seguito viene
analizzato il progetto GEM e, successivamente, viene presentata la teoria di
rappresentazione di una CG proposta dalle Tabelle di decisione e dalle Tabelle di decisione
aumentate. Nell’ultima parte dell’analisi si descrivono altri sistemi di gestione delle CG
5
quali PROforma, ONCOCYN, Prodigy, Asbru e DILEMMA. In questa parte si evidenziano
anche gli eventuali legami che possono esistere tra i diversi progetti di studio dei sistemi, in
quanto alcuni progetti sono stati sviluppati nello stesso filone di studio e all’interno dello
stesso gruppo di ricerca.
Nella parte finale dello scritto vengono confrontati i diversi sistemi sulla base delle
modalità di rappresentazione usate dai sistemi e delle primitive di rappresentazione
utilizzate dai sistemi.
2. Scopi delle Clinical Guideline
In [3] vengono definiti i 5 task che devono essere realizzati da una Guideline.
I cinque task sono:
1. Making of decision
2. Sequencing of actions
3. Setting of goals
4. Interpretation of Data
5. Refinement of actions
1.
2.
3.
4.
5.
Making of Decision. Questo task indica il “prendere una decisione” e con esso
viene messo in evidenza uno dei principali scopi delle Clinical Guidelines, vale a
dire il supporto che esse devono fornire ai medici nel prendere una decisione,
quando ci si trova a curare un paziente secondo una determinata Guideline.
Sequencing of actions and decisions. Questo secondo task indica la possibilità
delle Guideline di supportare la strutturazione di azioni e decisioni e, quindi,
suggerire l’ordine temporale delle azioni o l’eventuale sequenza.
Setting of goals. Questo terzo task indica la possibilità da parte del medico di
individuare, attraverso la Guideline, gli scopi da perseguire nell’applicare uno
specifico trattamento di cura ad un caso clinico.
Interpretation of data. Questo task indica la possibilità di derivare concetti astratti
da dati concreti. Questa caratteristica è molto importante poiché l’applicazione di
una guideline ad un individuo richiede sempre una personalizzazione di concetti
astratti e generali descritti da una CG.
Refinement of actions. Con questo task s’indica letteralmente “raffinamento delle
azioni” e riguarda la capacità di riconoscere specializzazioni d’interventi astratti,
e, se necessario, trasformare l’intervento astratto in un’attività reale, in modo che
possa essere eseguito.
Questi 5 tasks non sono fra di loro completamente separati ma interdipendenti. Il legame
che c’è tra i 5 tasks è mostrato in fig. 1 [3].
Nel descrivere ruoli e scopi delle CG, la fig. 1 evidenzia 3 tipi di frecce: le frecce a riga
continua indicano la successione delle azioni e delle decisioni, le frecce a riga tratteggiata
indicano la scelta (Choice) tra differenti alternative (Alternative1, 2, 3) e, quindi, percorsi
alternativi di azioni, mentre le frecce arrotondate indicano il flusso dei dati.
6
Se i primi studi sulle CG ne hanno evidenziato gli scopi, negli anni successivi gli
studiosi hanno dato rilievo a diversi aspetti delle guideline ed hanno cercato di gestirle con
filosofie e metodi, a volte, molto diversi.
Interpretation of data
Setting of goals
Refinement of actions
Abstraction
Sequencing of actions
Making of decisions
Action
Alt1
Choice
Abstract
action
Action
Alt2
Action
Data
Specific
actions
Alt3
Fig.1: Spiegazione dei ruoli e degli scopi che le Clinical Guideline possono perseguire per
l’organizzazione e le performances del lavoro medico.
3. Cronologia dei sistemi di gestione delle Guideline
Fig. 2. Storia dei metodi di modellamento delle Guideline.
7
Dallo studio [8], gli autori hanno evidenziato l’evoluzione temporale e i collegamenti
concettuali tra i diversi sistemi ed hanno ricavato il grafico rappresentato in fig.2.
La fig. 2 mostra due aspetti interessanti: il primo è che da essa è possibile evidenziare
diversi filoni di studio ed il secondo è che si possono facilmente notare le evoluzioni che ci
sono state tra i diversi progetti. Si possono, ad esempio, evidenziare i seguenti importanti
collegamenti progettuali:
- Il progetto di studio GEM è uno studio che non è assolutamente in collegamento con
nessuno degli altri, e che deriva esclusivamente dalla base concettuale delle Decision
Tables (le Tabelle di decisione).
- Il progetto Prodigy si è evoluto sviluppando Prodigy3 ed, oltre EON2, non ha legami
con nessun altro sistema.
- Si può notare che, invece, ONCOCIN ha ispirato lo sviluppo di EON e DILEMMA.
- GLIF, sviluppatosi recentemente in GLIF3, è nato dall’influenza di diversi progetti
separati: EON, MBTA, e GEODE-CM.
- GLIF3 è stato influenzato dall’applicazione dell’Arden Syntax.
- DILEMMA ha influenzato PROforma e PRESTIGE.
I sistemi presentati nel seguito sono i seguenti:
1) Arden Syntax,
2) Implementazione di MLM (non presente in fig. 2)
3) GEODE-CM,
4) MBTA,
5) EON
6) Il progetto GLIF (GLIF – GLIF2 – GLIF3),
7) Il progetto GEM,
8) Le tabelle di decisione aumentate,
9) PROforma, ONCOCIN, Prodigy, Asbru, DILEMMA:
Un MLM (Medical Logic Module) è un modulo software scritto nel linguaggio dell’Arden
Syntax.
4. L’Arden Syntax
L’Arden Syntax [14] è un linguaggio studiato per la scrittura e lo sharing di conoscenza
riguardante task specifici per Medical Logic Modules. La sintassi riguarda i task critici della
condivisione di basi di conoscenza medica tra diverse istituzioni. A causa della mancanza di
un accordo sull’uso di vocabolari standardizzati e di dati standards e di numerosi altri
impedimenti, gli sviluppatori dell’Arden Syntax hanno avuto un approccio pragmatico e
8
diretto che ha portato i suoi frutti in un breve periodo di tempo. La sintassi fornisce un
veicolo alle strutture di cura per iniziare lo sharing, cosicché si possono individuare quali
sono i centri che lavorano e si possono anche evidenziare quali sono gli ostacoli critici per
arrivare alla definizione di un linguaggio che permetta lo sharing totale, senza nessun tipo di
problema.
Il lavoro e lo studio sull’Arden Syntax inizia nel 1989, all’Arden Homestead conference
center in Harriman, New York. I ricercatori di diversi gruppi di informatica medica hanno
discusso la possibilità di condividere (sharing) basi di conoscenza medica in formato
elettronico. Un concreto risultato è quello di sviluppare una sintassi per condividere basi di
conoscenza medica costituite da moduli indipendenti (anche conosciuti come “frames” o
“protocols”).
4.1 Problemi per la condivisione di basi di conoscenza medica
L’Arden Syntax intende creare un linguaggio standard che permetta la condivisione di
basi di conoscenza medica tra diverse istituzioni mediche; tuttavia questo scopo non è
facilmente realizzabile poiché ci sono numerosi problemi che ostacolano la condivisione. Il
primo problema è costituito dalle diverse rappresentazioni che erano usate in medicina; ad
esempio si usavano dei moduli indipendenti in HELP, frames basati su KL-ONE, regole in
sistemi esperti come MYCIN, network causali come CASNET… etc. [15]. Tutte queste
diverse rappresentazioni dovevano essere tenute in considerazione dall’Arden Syntax che
doveva fare in modo che queste diverse rappresentazioni venissero interpretate
correttamente dai diversi utenti.
Il secondo notevole problema è l’accesso ai dati. Per avere un impatto totale dei sistemi
basati sulla conoscenza, in medicina, le istituzioni devono prima avere disponibili tutti i dati
che sono valutati dalle basi di conoscenza. Una volta che si hanno tutti i dati a disposizione
si presenta l’ostacolo di una loro corretta interpretazione, poiché le istituzioni raramente
utilizzano un vocabolario di termini medici comune o codifiche standard, cosicché ci
devono essere delle traduzioni quando la base di conoscenza è condivisa. Oltre alle
differenze nei vocabolari di termini utilizzati, bisogna considerare le differenze tra modelli
di schemi dei database.
Inoltre, una volta che la base di conoscenza è condivisa, la fase successiva, il
mantenimento, risulta essere ancora più difficile. Gli autori della base di conoscenza, infatti,
devono diffondere i cambiamenti a tutti i riceventi, e i cambiamenti devono essere
coordinati con le modifiche locali. Quando i riceventi scoprono degli errori nella base di
conoscenza, le modifiche devono essere comunicate agli autori che devono trasmettere il
cambiamento a tutti i riceventi.
La valutazione di sistemi di basi di conoscenza è molto costosa e difficile e quando una
base di conoscenza è condivisa, il problema della valutazione è ancora più complicato. La
base di conoscenza deve essere valutata dagli autori originali ed il sistema di basi di
conoscenza deve essere verificato da ogni istituzione ricevente per assicurare che il sistema
possa interpretare correttamente la base di conoscenza esterna [14].
4.2 Uso di una rappresentazione procedurale
Il sistema HELP [16], che, come si può vedere in fig. 2, è precedente all’Arden Syntax,
usa una rappresentazione procedurale. I suoi moduli non forniscono una lista di fatti, ma
9
contengono le procedure necessarie per recuperare, filtrare ed analizzare i dati, prendere una
decisione oppure realizzare una specifica azione. I moduli procedurali, quindi, non indicano
cosa fare ma come farlo.
Il paradigma procedurale è stato adottato nell’Arden Syntax, offrendo diversi vantaggi.
Esso segue l’esempio di sistemi già testati ed è facile da implementare usando gli strumenti
standard di programmazione ed, inoltre, è facile da integrare con i sistemi d’informazione
clinica esistenti.
Un ulteriore vantaggio dell’uso di una rappresentazione procedurale, è rappresentato dal
fatto che la filosofia di utilizzo non è così diversa dalla miriade di macro-linguaggi esistenti
(come, per esempio, word processor) o dai classici linguaggi di programmazione
disponibili; questa caratteristica aumenta la possibilità che utenti, con una non profonda
conoscenza dei computer, siano comunque capaci di leggerlo.
4.3 Organizzazione di un MLM
Nell’Arden Syntax, la base di conoscenza è costituita da un insieme di MLM ed ognuno
di essi è creato per prendere una singola decisione medica [14]. Un MLM è un modulo
software che, una volta implementato su un sistema d’informazione clinica, lavora su un
database di dati-paziente e fornisce avvertimenti ed avvisi per i medici. Lo scopo di un
MLM è quello di fornire la conoscenza richiesta per far partire un’azione su dati reperibili in
un database-paziente. Alcuni MLM, invece, generano messaggi che possono essere spediti
ad altri centri di cura.
Un MLM è un file ASCII con degli slots raggruppati in tre categorie: Maintenance,
Library e Knowledge.
Lo slot Maintenance definisce il nome, l’autore, l’origine, la versione e l’informazione
di validazione. Lo slot Library definisce i collegamenti con altre fonti di conoscenza,
commenti e parole-chiave per la ricerca. Lo slot Knowledge, che è la sostanza del MLM,
contiene l’attuale conoscenza medica.
Gli MLM sono forniti in semplici files ASCII, così da facilitare il trasporto tra diverse
architetture; l’insieme di caratteri è limitato ai caratteri stampabili ed a pochi caratteri
particolari per ridurre i conflitti tra i sistemi.
Un MLM consiste di un campo nome, il simbolo di punteggiatura due punti (:), una
parte di testo e due simboli di punteggiatura punto e virgola (;;) per indicare che è terminato.
Poiché gli MLM sono indipendenti e possono essere condivisi uno alla volta, gli slot
Maintenance e Library forniscono la documentazione necessaria per ogni MLM.
La categoria Knowledge contiene 4 slot importanti: Evoke, Logic, Action e Data. Lo slot
Evoke definisce il contesto nel quale lo slot è pertinente, lo slot Logic manipola ed analizza i
dati del paziente e decide se sono autorizzate ulteriori azioni, lo slot Action definisce quale
azione è appropriata, e, in ultimo, lo slot Data mappa le entità di un database clinico locale
nei termini usati nel MLM. Gli slot Evoke, Logic, Action e Data condividono una sintassi
simile, sebbene ognuno di loro abbia dei suoi costrutti speciali. In fig. 3 si mostra un
esempio di un MLM [14].
10
maintenance:
title: Alert on low hematocrit;;
filename: low_hematocrit;;
version: 1.00;;
institution: CFMC;;
author: George Hripsak, M.D.;;
specialist: ;;
date: 1993-10-31;;
validation: testing;;
library:
purpose: Warn provider of new or worsening anemia.;;
explanation: Whenever a blood count result is
obtained, the
Hematocrit is checked to see whether it is below 30 or at
least 5 points below the previous value.;;
keywords: anemia; hematocrit;;
knowledge:
type: data-driven;;
data: blood-count_storage := event {‘complete blood count’};
hematocrit := read last {‘hematocrit’};
previous_hct := read last ({‘hematocrit’};
where it occurred before the time of hematocrit);;
evoke: blood_count_storage;;
logic:
/*check that the hematocrit is a valid number */
if hematocrit is not number then
conclude false;
endif;
if hematocrit <= previous_hct-5 or hematocrit <30 then
conclude true;
endif;;
action: write “The patient’s hematocrit (“|| hematocrit ||”)
is low or falling rapidly.”;;
end:
Fig. 3: Esempio di MLM.
In fig. 3 si può notare che le parole chiave dell’Arden Syntax sono scritte in grassetto
per evidenziarle maggiormente.
4.4 Caratteristiche d’implementazione dell’Arden Syntax
Una volta che i progettisti hanno deciso di adottare una sintassi procedurale, essi si sono
posti il problema di quanto potente dovesse essere il linguaggio di programmazione da
utilizzare. HELP utilizzava un linguaggio molto simile al Pascal. Il problema derivante
dall’utilizzo di un linguaggio come il Pascal è fondamentalmente dovuto alla sua flessibilità.
Lo scopo dei progettisti dell’Arden Syntax, invece, era quello di rendere gli MLM facili da
scrivere, da condividere e da capire. L’Arden Syntax utilizza una struttura fatta a blocchi,
dove ogni blocco, come in Pascal, inizia con begin e finisce con end e “;”. Non ci sono loop
e quindi la struttura da utilizzarsi è la classica if-then-else. Gli operatori matematici sono
infissi come in Pascal, quindi una generica somma verrà scritta nel normale modo di
scrittura (es. 4 + 6). I tipi di dati sono quelli fondamentali di linguaggi di programmazione
11
come Pascal o C, e, quindi, possono essere interi, reali, caratteri, puntatori e stringhe. Altri
tipi più particolarizzati possono essere definiti utilizzando opportunamente gli array e le
liste. E’ importante notare che nell’Arden Syntax non si possono utilizzare liste annidate
[14].
Un autore di un MLM non dichiara il tipo di dati delle variabili nel MLM, ma i tipi sono
assegnati run-time ed il tipo di dati può essere riassegnato all’interno del MLM. L’uso di
questa tipizzazione di dati dinamica, sviluppata senza dichiarazioni di variabili, segue
l’esempio di linguaggi come LISP, Smalltalk, Prolog etc.
Nell’Arden Syntax i tempi sono rappresentati come istanti discreti e tutti i tempi
contengono sia una data che un time-of-day [14].
Una fondamentale assunzione, nel campo dell’utilizzo dei dati, è che i dati provengano
da un database elettronico clinico esistente, senza input interattivo. Questo significa che i
dati che l’utente deve introdurre devono essere implementati come una parte del sistema
d’informazione clinica, e non all’interno del MLM.
Un’importante possibilità che fornisce l’Arden Syntax è l’annidamento degli MLM. Il
paradigma base dell’Arden Syntax è di avere un insieme di moduli indipendenti. I moduli
interagiscono attraverso il database. Usando il database come se fosse una lavagna, gli
MLM possono comunicare risultati di calcoli, diagnosi, stati, avvisi e informazioni di
scheduling, memorizzando valori nel database che altri MLM possono leggere. Un MLM
può far partire un altro MLM in modo sincrono o asincrono attraverso lo statement CALL.
Sono stati adottati diversi metodi di implementazione ed alcuni di questi hanno utilizzati
linguaggi come il C++ e Smalltalk.
I successivi sviluppi dell’Arden Syntax, iniziati nel 1993 al ASTM meeting of the Arden
Syntax, riguardano essenzialmente una revisione degli errori fissi conosciuti e prevedono
ulteriori miglioramenti.
5. Implementazione di MLM
L’Implementazione di Medical Logic Modules (MLM) è un progetto portato avanti dalla
Columbia University [11], ed è costituito da moduli software scritti nel linguaggio Arden
Syntax [14] che, una volta implementato su un sistema d’informazione clinica, lavora su un
database di dati-paziente e fornisce avvertimenti ed avvisi per i medici. Lo scopo di un
MLM è quello di fornire la conoscenza richiesta per far partire un’azione su dati reperibili in
un database-paziente. Alcuni MLM generano messaggi che possono essere spediti ad altri
centri di cura. Altri messaggi, invece, forniscono interpretazioni di dati sui pazienti oppure
possono fornire una lista di pazienti che rispondono a determinati criteri, come i criteri
d’eleggibilità per i Clinical Trials.
Un MLM contiene un data slot che specifica il mapping tra i termini usati nel MLM e
quelli usati nel database-paziente locale. Esiste, inoltre, un evoke slot che specifica quali
sono gli elementi che indurranno il logic slot ad agire. Il logic slot specifica, invece, quali
occorrenze devono essere verificate affinché un’azione possa essere iniziata. Il risultato
dell’asserzione logica può essere true o false; se esso è true allora l’azione nell’action slot
viene eseguita, altrimenti nessuna azione viene fatta.
Gli inputs al sistema sono normalmente dei dati-paziente reperibili da un database,
mentre gli outputs sono dei messaggi ai providers. Gli MLM erano originariamente
progettati per avere un singolo insieme di dati di input, una singola applicazione di criteri
12
logici e un singolo set di azioni risultanti. In Guidelines complesse, tuttavia, ci possono
essere sequenze di azioni, ognuna richiedente un suo insieme di dati, e le scelte di azioni
possono dipendere dai risultati di precedenti azioni e decisioni. E’ importante far notare,
tuttavia, che questo tipo d’implementazione tramite Arden Syntax non riesce a supportare le
Guidelines molto complesse [11]. Un esempio di un’implementazione di questo tipo è
mostrato in fig. 3.
6. Il sistema GEODE-CM
Il GEODE-CM [11] è un sistema studiato al Brigham and Women’s Hospital. Esso
combina le Guidelines con l’introduzione di dati strutturati ed il recupero da un database
clinico. Lo scopo del sistema è di proporre la raccolta di dati specifici da memorizzare,
suggerisce decisioni da prendere ed azioni da svolgere in un determinato stato di
management clinico.
L’interfaccia grafica di GEODE-CM, inizialmente, mostra per un particolare stato di
management clinico un sommario clinico delle informazioni riguardanti il paziente, mentre
la schermata successiva è organizzata come una nota SOAP (Subjective, Objective,
Assessment e Plan). La sezione Plan è composta di actions e transitions: le actions
includono tests diagnostici e terapie che devono essere gestite, le transitions (transizioni di
stato), invece, specificano gli stati di management clinico ai quali il paziente può giungere e
i criteri che determinano se il paziente può raggiungere o meno quegli stati.
I blocchi costruttivi di base per fornire la conoscenza in GEODE-CM sono dei nodi che
rappresentano stati di management clinico. Un nodo è specificato da un unico identificatore,
un nome, dei dati pertinenti, actions, avvisi, transitions e didattica. Una spiegazione
particolare va fatta per gli avvisi: essi sono molto importanti in un sistema di gestione di una
Guideline, perché forniscono importanti informazioni che i medici utenti devono
considerare in uno specifico stato e gli ricordano a quali aspetti rivolgere particolare
attenzione. La didattica è rappresentata da materiale aggiuntivo che fornisce materiale di
testo o links a testi e grafici.
GEODE-CM differisce dagli MLM nell’incorporazione di metodi per guidare
l’introduzione di dati da parte dei medici. Gli outputs consistono in raccomandazioni
riguardanti quali dati raccogliere, le azioni da eseguire e gli stati di management clinico da
raggiungere. In GEODE-CM risultano essere importanti le sequenze di azioni e decisioni.
C’è, inoltre una parte specifica dedicata agli elegibility criteria per iniziare la Guideline, un
nodo di start e dei nodi aggiunti collegati alle transitions [11].
7. Il sistema MBTA
Il sistema MBTA [11], progetto studiato al Massachusetts General Hospital è
un’architettura in grado di costruire sistemi medici basati sulla conoscenza; esso è
indirizzato essenzialmente a fornire avvisi clinici. Un “avviso clinico” è un’indicazione
medica fornita dal sistema (in questo caso MBTA) che può avere diversi scopi. Il primo
scopo è quello di aiutare il medico nella scelta di una cura appropriata per una particolare
situazione patologica del paziente, mentre il secondo scopo è quello di ricordare al medico
13
delle scadenze temporali, delle controindicazione terapeutiche ed altri suggerimenti che il
medico deve tenere a mente durante la cura di un paziente.
I componenti-base del sistema MBTA sono moduli, oggetti ed explainers. Un modulo
MBTA è una porzione procedurale molto simile ad una classica procedura nei tradizionali
linguaggi di programmazione. La differenza principale con le normali procedure sta nel
fatto che invece del passaggio di parametri, MBTA permette ai moduli di usare, per l’input
e l’output, degli oggetti. Un oggetto MBTA è come un oggetto C++ con la differenza, però,
che esso fornisce anche una rappresentazione temporale e la possibilità di supportare il
mapping di vocabolari automatizzati. Un oggetto viene definito come una struttura avente
un unico nome e un set di campi di dati.
Un explainer MBTA è uno speciale tipo di modulo capace di usare gruppi di oggetti
precedentemente creati per fornire una spiegazione in formato di testo su quegli stessi
oggetti.
Gli inputs al sistema MBTA vengono dal database-paziente e i dati-paziente raggruppati
a formare oggetti MBTA. Il sistema produce outputs sotto forma di spiegazioni.
MBTA supporta anche le sequenze di azioni e di decisioni, le quali sono rappresentate
tramite il codice procedurale dei moduli. Il sistema, inoltre, permette di descrivere gli
elegibility criteria (criteri d’eleggibilità) e i transition criteria (criteri di transizione di
stato). E’ da notare che in MBTA non ci sono strutture chiamate esplicitamente “elegibility
criteria” e “transition criteria”, ma ci sono criteri che realizzano le loro stesse funzioni, e
sono incorporati nel codice procedurale dei moduli [11].
8. Il sistema EON
Il sistema EON è un progetto studiato alla Stanford University [11]. E’ un’architettura,
basata sui componenti, progettata per costruire sistemi che forniscano un supporto alla
decisione in processi di cura basati sulle Guidelines. I componenti di EON, che sono stati
implementati, identificano delle guidelines appropriate per un dato paziente, tracciano un
percorso del paziente stesso attraverso la guideline, raccomandano appropriati tests e terapie
per un dato paziente in un determinato tempo e, in ultimo, confrontano un progetto di
management di medici con il progetto raccomandato dalla guideline stessa.
Le strutture di conoscenza base che interessano una rappresentazione di EON sono:
protocol steps, intervention states, elegibility criteria, conditions e revision rules.
I protocol steps (“passi del protocollo”) rappresentano le fasi che specificano un
intervento, fasi di valutazione che specificano i dati necessari da rilevare per valutare o
diagnosticare un paziente.
Gli intervention states (“stati dell’intervento”) possono avere diversi valori di stato:
attivo, completato, abortito o sospeso ed indicano a che punto si trova l’intervento.
Le revision rules (“regole di revisione”) possono modificare lo stato corrente di un
intervento o modificare delle proprietà quali, ad esempio, la dose di un determinato
farmaco.
Gli elegibility criteria sono rappresentati, come in GEODE-CM, in una parte a loro
dedicata esplicitamente e così chiamata.
Le conditions (“condizioni”) contengono le condizioni logiche per passare da uno step
di protocollo ad un altro e per apportare modifiche agli interventi.
14
EON, inoltre, ha ulteriori componenti che possono risultare importanti nella gestione
delle guidelines e questi sono: un dizionario controllato, un gestore di database temporale e
la possibilità di scomporre gli steps in altri sotto-steps [11].
9. Il progetto GLIF: GLIF – GLIF2 – GLIF3
Nell’aprile del 1996, il Decision System Group al Brigham and Women’s Hospital ha
sponsorizzato una ricerca volta alla rappresentazione di una Guideline per determinare i
requisiti di una possibile rappresentazione condivisibile (shareable) e per definire una
preliminare GuideLine Interchange Format. A tal fine i ricercatori hanno analizzato
l’Implementazione di MLM, il sistema GEODE-CM, il sistema MBTA e il sistema EON allo
scopo di ricercare quali fossero le eventuali caratteristiche comuni e di analizzare quelle che
maggiormente corrispondono a criteri di ottimizzazione. I ricercatori hanno confrontato i
quattro sistemi ed hanno, quindi, scelto specifiche caratteristiche.
Il fine di questo lavoro era di creare, per quanto possibile, un sistema di
rappresentazione di una guideline, GLIF (GuideLine Interchange Format) [7, 10, 11], che
fosse il più possibile esaustivo, rappresentativo e condivisibile.
Le caratteristiche comuni ai quattro sistemi, che sono state rilevate dai progettisti di
GLIF, sono le seguenti [11]:
1. Rappresentazione di Guidelines complesse tramite diramazione logica.
Per ciò che riguarda questa caratteristica è stato osservato che GEODE-CM ed EON si
concentrano sull’implementazione di steps multipli collegati insieme con possibilità di
diramazioni (branching).
Gli MLM, invece, implementati in Arden Syntax, vengono usati per rappresentare
guidelines semplici; tuttavia se gli MLM fossero collegati insieme, potrebbero realizzare
potenzialmente delle guidelines complesse.
Il sistema MBTA, invece, pur potendo rappresentare bene delle guidelines complesse,
ha lo svantaggio di presentare delle scelte e delle azioni poco esplicite.
I progettisti hanno scelto, per GLIF, di rappresentare esplicitamente gli steps che
specificano le scelte e le azioni nella guideline.
2. Rappresentazione d’elementi di dati-paziente.
Il sistema di supporto alla decisione, basato sugli MLM, è “triggerato” dai dati nel
database-paziente usati per la cura del paziente attuale.
Gli altri 3 sistemi, invece, non interagiscono direttamente con i dati reali del paziente,
ma sono progettati per essere “triggerati” da dati-paziente immagazzinati o da dati richiesti
come input dall’utente.
Gli MLM hanno in un data slot i dati che il programma deve recuperare dal database e
nel logic slot quegli elementi che corrispondono a specifici parametri clinici.
GEODE-CM ha una sezione per dati pertinenti che specifica se riferirsi a dati da
collezionare o a dati già immagazzinati, mentre MBTA ha degli oggetti che contengono
pacchetti di dati (data packaged) reperiti da un database.
EON, invece, ha elementi di dati che si adattano al vocabolario controllato collegato al
sistema.
15
Per ciò che riguarda GLIF, i progettisti hanno scelto la possibilità di avere delle strutture
di dati che legano la guideline agli elementi di dati nel database o agli elementi di dati
introdotti dall’utente, tralasciando, per il momento, il problema del vocabolario controllato,
affrontato da EON.
3. Rappresentazione dei criteri d’eleggibilità.
GEODE-CM ed EON hanno dei costrutti specifici per realizzare i criteri d’eleggibilità,
mentre gli MLM hanno solo un’asserzione logica che serve come criterio per la
realizzazione di una determinata azione. Quest’ultimo tipo d’interpretazione del criterio
d’eleggibilità è diverso da quello che normalmente s’intende con questi termini, cioè il
criterio, le condizioni che devono essere verificate per l’introduzione di un determinato
paziente all’interno di una guideline o di un clinical protocol.
In GLIF s’implementerà solo questo secondo tipo d’interpretazione del criterio
d’eleggibilità.
4. Rappresentazione del punto di partenza.
Dall’osservazione dei 4 sistemi si è visto che per gli MLM non è importante il punto di
partenza, poiché ogni MLM costituisce un elenco sequenziale che si attiva
indipendentemente da qualsiasi altro. In EON e GEODE-CM si hanno, invece, espliciti
punti di partenza. Il sistema MBTA, inoltre, specifica determinati punti di partenza anche se
non vengono etichettati esplicitamente come tali.
Per GLIF si è stabilito che avere un punto di partenza è necessario, se si vuole realizzare una
rappresentazione condivisibile, che rappresenta lo scopo principale del progetto.
5. Rappresentazione delle azioni.
Ogni sistema implementa il concetto d’azione (action/s) in modi differenti. GEODE-CM
ha delle actions, EON ha degli interventions, gli MLM hanno degli action slots e MBTA
permette la rappresentazione delle azioni all’interno del codice procedurale dei moduli
MBTA.
Per il progetto GLIF si è scelto di rappresentare le azioni come un’entità che contenga
una singola azione.
6. Rappresentazione delle opzioni che seguono una determinata azione.
In GEODE-CM, un nodo può condurre a transizioni di stato multiple, mentre in EON
uno step di protocollo può condurre ad una scelta di diverse possibilità.
Nel progetto GLIF si è scelta la rappresentazione utilizzata in EON, dove i progettisti
hanno creato i costrutti one-of, some-of e all-of per rappresentare le opzioni seguenti
un’azione. Inoltre, se le multiple azioni devono essere realizzate parallelamente, ci dovrà
essere un punto in cui le attività convergono. La soluzione a questo problema, in GLIF, è
stata trovata prendendo spunto da EON, il quale utilizza, allo scopo, un syncronization step
(uno step di sincronizzazione).
7. Rappresentazione di criteri per procedere.
Con questa caratteristica ci si riferisce al fatto che ogni azione, per essere realizzata in
una guideline, deve essere preceduta dai “criteria for proceeding” (criteri per procedere).
Questo concetto viene realizzato in diversi modi nei 4 sistemi.
16
In GEODE-CM ci sono dei criteri di transizione, in EON ci sono dei predicati, negli
MLM ci sono dei logic slots e in MBTA c’è un codice specifico. Questi sistemi permettono
la valutazione dei suddetti criteri (true o false).
In GLIF, almeno nella prima versione, i progettisti, pur riconoscendo l’importanza di
questi criteri, li hanno lasciati sotto forma testuale.
8. Decomposizione delle azioni.
Se si ipotizza di dover trattare delle Guidelines complesse, è utile poter decomporre le
azioni in azioni più piccole. L’unico dei 4 sistemi a supportare esplicitamente questa
funzionalità è il sistema EON che è progettato per clinical trial protocols complessi.
9. Links alle risorse della Guideline.
I 4 sistemi realizzano i collegamenti alle risorse in modo diverso. Gli MLM hanno dei
citations slots e dei links slots che hanno la funzione di riportare delle citazioni importanti
presenti nella letteratura e operare legami ad altra informazione di supporto.
GEODE-CM ha la possibilità di trovare materiale di referenza supplementare,
collegandolo con ogni nodo, azione, transizione o dato pertinente.
MBTA, invece, si concentra sull’importanza di spiegare agli utenti le ragioni delle
raccomandazioni proposte nella guideline. All’interno della spiegazione, si possono trovare
riferimenti a pubblicazioni.
In GLIF si è pensato di fornire, per questo scopo, dei links testuali, citazioni e risorse su
World Wide Web in modo tale da rendere la rappresentazione più ampiamente condivisibile
(shareable).
9.1 Spiegazione del progetto GLIF
GLIF nasce con i seguenti scopi: permettere l’utilizzo delle guideline scritte in GLIF da
parte di diversi strumenti software, permettere l’adattamento delle guideline a diversi usi
locali.
L’obiettivo della specificazione GLIF è quello di fornire una rappresentazione delle
guideline che sia: precisa e non-ambigua, interpretabile dall’uomo, interpretabile da un
computer e adattabile a diversi standards di informazione clinica in modo tale da facilitare la
condivisione delle guideline.
9.2 GLIF 2
La versione 2 di GLIF (GLIF2) [11] è stata pubblicata nel 1998 ed è costituita da 2 parti
principali: un modello ad oggetti GLIF e una sintassi GLIF.
Il modello GLIF permette le specifiche di una guideline come un flowchart di fasi
ordinate temporalmente. Le fasi rappresentano azioni o decisioni cliniche e,
contemporaneamente, vengono usate ramificazioni e step di sincronizzazione. Il modello
GLIF2 consiste di un insieme di classi per entità guidelines, degli attributi per le classi e dei
tipi di dato corrispondenti ai diversi valori che possono assumere gli attributi. Il concetto
importante è che una particolare guideline codificata in GLIF non è altro che un’istanza del
modello di guideline generale.
17
La sintassi GLIF specifica il format dei files di testo che contengono la codifica. Sia il
Modello GLIF che la sua sintassi sono descritti in dettaglio nei successivi due
sottoparagrafi. In fig. 4 [11] viene mostrata la struttura delle classi di GLIF.
9.3 Il modello GLIF2
L’oggetto della guideline GLIF2 ha un nome, una lista di autori, una spiegazione delle
intenzioni della guideline da rappresentare, specifiche dei criteri di eleggibilità del paziente,
una lista non-ordinata di tutti gli step della guideline e una lista di materiale didattico di
supporto.
Gli scopi della guideline sono correntemente rappresentati come testo libero. I criteri
d’eleggibilità non sono altro che condizioni da verificare come true, prima di poter applicare
la guideline al paziente in questione.
Guideline
Model
Guideline
Action
Step
Guideline
Step
Conditional
Step
Action
Specification
Branch
Step
Patient
Data
Criterion
Synchronization
Step
Boolean
Criterion
K_of_n
criterion
Supplemental
material
Local
material
WWW
material
Fig. 4: Schema della struttura di GLIF.
Le specifiche di una guideline sono costituite da una collezione di step collegati insieme
a formare un grafo direzionale.
Ci sono 4 tipi si step di una guideline: step d’azione, step condizionali, step di branch e
step di sincronizzazione.
A. Step d’azione: questi step specificano le azioni che devono essere realizzate nel
processo di cura del paziente; uno step d’azione può chiamare una sotto-guideline. Ogni
step d’azione contiene esattamente una specifica per l’azione in questione e un puntatore al
successivo step nella guideline.
Una specifica di un’azione è caratterizzata da un nome, una lista di dati-paziente, una
descrizione dell’azione in formato testo libero ed una lista opzionale di materiale didattico
di supporto.
A sua volta, un elemento di dato del paziente è caratterizzato da un nome, un tipo di
dato, una lista opzionale di valori accettabili, dei limiti temporali e una lista di materiale
didattico di supporto.
18
B. Step condizionali: questi step dirigono il flusso da uno step all’altro, all’interno della
guideline. Uno step condizionale è caratterizzato da una condizione o criterio, che è
un’assunzione logica, da verificare come true o false; se la condizione è true allora il
controllo va allo step specificato dall’attributo destination (destinazione) mentre se la
condizione è false allora il controllo va verso lo step indicato dall’attributo otherwise
(diverso). Una non-transizione è contemplata solo nel caso non sia possibile verificare la
condizione in questione.
C. Step di branch: questi step dirigono il flusso a step multipli di guideline. Gli step
multipli rappresentano la strutturazione di più step. L’autore specifica se tutti, alcuni, o uno
solo di questi step devono intervenire e se gli step devono succedersi in un ordine specifico
o in parallelo.
D. Step di sincronizzazione: questi step vengono usati insieme agli step di branch;
quando uno step di branch è seguito da uno step multiplo, il flusso di controllo deve
convergere ad un singolo step. Lo step cui convergono tutti i percorsi degli step di branch si
chiama step di sincronizzazione. L’attributo continuation specifica se solo uno o tutti gli
step precedenti devono essere completati prima di spostare il controllo allo step successivo.
In fig. 5 [11] si mostra un esempio di rappresentazione di Guideline in GLIF2, dove
sono mostrate tutte le caratteristiche appena descritte.
Guideline Example
{
name =”Guideline for Vaccine X”;
authors = SEQUENCE1 {“Mary Doe, MD”;};
elegibility criteria = NULL;
intention = “Decide whether to reccomend the Generic Vaccine and at what dosage”;
steps =
SEQUENCE 8
{ (Branch_step 1);
(Action_step 1);
(Action_step 2);
(Syncronisation_step 1);
(Conditional_step 1); (Conditional_step 2);
(Action_step 3);
(Action_step 4);
};
first_step = (Branch_step 1);
didactics =
SEQUENCE 1
{
Supplemental_material 1
{
label = “critique”;
MIME_TYPE = “text/plain”;
material = “Published guideline does not contain explicit elegibility criteria”;
};
};
}
//________________________________________________________________________
Branch_step 1
{
name = “collect data”;
.
.
.
19
}
//________________________________________________________________________
Action_step 1
{
name = “Get occupation”;
action = …
}
//________________________________________________________________________
Action_step 2
{
.
.
}
//________________________________________________________________________
Syncronisation_step
{
}
name = “wait until data collected”;
next_step = (Conditional_step 1);
.
.
.
//________________________________________________________________________
Action_step 3
{
name = “Pediatric dosage”;
action =
Action_spec 3
{
name = “Administer pediatric dosage”;
.
.
};
subguideline = NULL;
next_step = NULL;
didactics = SEQUENCE 0 {};
}
Fig. 5: Esempio di Guideline codificata in GLIF2.
9.4 Analisi delle lacune di GLIF2
Lo studio di GLIF2 ha mostrato diverse lacune che limitano il suo utilizzo e per ovviare
a queste sono state fatte, in anni più recenti, delle modifiche a GLIF2 dalle quali è poi nato
GLIF3 [10, 11].
Le lacune che i progettisti di GLIF hanno evidenziato sono le seguenti:
a) GLIF2 non specifica come strutturare importanti attributi degli step delle guideline
come nomi di dati e di azioni ed espressioni di condizioni logiche. I valori di alcuni attributi
sono specificati come stringhe di testo. Questo non permette alle guideline di essere usate
per ottenere inferenze.
20
b) Risulta difficile l’integrazione delle guideline in GLIF2 con eterogenei sistemi
medici.
c) Lo step di branch può essere usato sia per rappresentare l’esecuzione concorrente di
azioni multiple sia per fare una selezione tra un insieme di scelte. Ciò rende la sua
semantica ambigua.
d) Il modello di decisione di GLIF2 è limitato. Le decisioni possono essere specificate o
tramite uno step condizionale oppure tramite uno step di branch per il quale non c’è
preferenza tra le scelte che possono essere espresse. Lo step condizionale permette di poter
scegliere quale “ramo” prendere, mentre lo step di branch mi manda indifferentemente in
tutti i “rami” che partono dallo step in cui mi trovo.
e) GLIF2 fornisce solamente un insieme limitato di costrutti a basso livello.
f) GLIF2 usa delle sotto-guideline per gestire la complessità dei flowchart di una
guideline e per espandere gli step delle azioni. In ogni modo, anche utilizzando le sottoguideline, le mancanze di cui al punto e fanno sì che il sistema sia molto pesante.
9.5 GLIF3
GLIF3 [10] permette di descrivere una guideline a 3 livelli di astrazione: concettuale
tramite flowchart, computabile e analizzabile e, in ultimo, implementabile. Rispetto a
GLIF2, introduce notevoli modifiche nel modello ad oggetti e nella sintassi.
1. Livello concettuale: a questo livello la guideline è rappresentata come un flowchart.
2. Livello computabile: a questo livello può essere controllata la completezza e la
consistenza logica della guideline. Vengono definite la sintassi delle espressioni, le azioni
mediche e il flusso dell’algoritmo.
3. Livello implementabile: a questo livello le guideline sono pronte per essere
incorporate all’interno di ambienti di sistemi d’informazione istituzionali.
9.5.1 Cambiamenti nel modello dell’oggetto
Il modello d’oggetto in GLIF3 definisce nuovi costrutti e modifica la struttura dei
costrutti di GLIF2. Il modello di GLIF3 è descritto usando la rappresentazione di UML
(Unified Modeling Language) [10].
GLIF3, rispetto a GLIF2, aiuta a gestire la complessità delle guideline definendo un
meccanismo per specificare gli steps delle guideline iterativamente, attraverso
l’annidamento di subguideline in steps di azioni e di decisioni. Questo meccanismo di
annidamento permette la definizione di veri e propri moduli indipendenti dalla parte restante
della guideline e questo fa sì che il modulo possa essere utilizzato in altre guideline.
Una nuova proprietà, presente nella versione 3 e non nella 2, è il macro step: esso è una
classe speciale con attributi che definiscono l’informazione necessaria per istanziare un
insieme di step di GLIF. I macro step giovano all’authoring, vale a dire alla scrittura della
Guideline, ad una comprensione visuale e all’esecuzione della guideline. Essi permettono,
inoltre, una specifica dichiarativa di un percorso procedurale che è realizzato da un insieme
di azioni, diramazioni e steps di decisione. GLIF3 ha la capacità, inoltre, di fornire diversi
21
livelli visivi all’interno di una guideline e questo è, chiaramente, un beneficio quando, in
un’ampia e complessa guideline, sono interessati diversi utenti in differenti parti della stessa
guideline [7, 10, 11].
GLIF3 possiede una grammatica strutturata per specificare le espressioni e i criteri. La
grammatica è in grado di specificare criteri logici, espressioni numeriche e temporali e
operazioni su stringhe di testo: essa non è altro che un superset della grammatica logica
dell’Arden Syntax.
Il sistema, inoltre, facilita l’utilizzo di vocabolari medici standard e l’integrazione di
guideline condivise all’interno di ambienti di sistemi d’informazione clinici, attraverso un
approccio stratificato.
I possibili strati esistenti nel modello d’oggetto GLIF3 sono i seguenti:
a. Lo strato core GLIF fornisce un’interfaccia standard per tutti i dati e concetti
clinici che possono essere referenziati da GLIF.
b. Lo strato RIM (Reference Information Model) fornisce una gerarchia semantica
per concetti medici e permette la specificazione di attributi per ogni classe di dati
medici.
c. Lo strato Medical Knowledge contiene un dizionario di termini e può fornire
l’accesso alle basi di conoscenza medica.
All’interno dei cambiamenti del modello ad oggetti di GLIF3 si trovano altri nuovi
concetti rispetto a GLIF2.
Il modello di specificazione dell’azione è stato esteso per includere 2 nuovi tipi
d’azione: azioni riguardanti il flusso della guideline come, ad esempio, la chiamata di una
sotto-guideline e azioni pertinenti clinicamente come il suggerimento di raccomandazioni.
In aggiunta, in GLIF3 vi sono rappresentazioni per diversi nuovi concetti quali:
• Descrizione di iterazioni e condizioni che controllano il flusso delle iterazioni.
• Descrizione di eventi e triggering di step di guideline da eventi.
• Descrizione di eccezioni e meccanismi associati alla manipolazione delle
eccezioni.
• Rappresentazione di stati-paziente come un altro tipo di step di guideline. Questo
step ha un attributo di precondizione che lo caratterizza.
9.5.2 Cambiamenti nella sintassi
La sintassi, sviluppata localmente, basata su ODIF [17] è stata sostituita in GLIF3 con
una basata su XML [18] ed il suo schema è tutt’oggi in fase di sviluppo [11, 14].
10. Il sistema GEM
GEM (Guideline Elements Model) è inteso come un modello di documento guideline
astratto, capace di mascherare alcuni dettagli per metterne in risalto altri. GEM propone una
traduzione di documenti, scritti in linguaggio naturale, in un formato processabile tramite
computer [6, 9, 13]. Da questo punto di vista, XML è un potente strumento capace di
rappresentare documenti in formato elettronico e in grado di permettere ad un computer, o
ad un essere umano, di estrarre l’informazione per riusarla o modificarla.
22
Un documento guideline in XML è concepito come una gerarchia d’elementi. Ogni tag
di un elemento demarca testo e fornisce etichette per caratterizzare il contenuto semantico
dell’elemento. Un DTD (document type definition) di un XML modellizza i nomi di
elementi ammissibili e di attributi nel documento, il contenuto di ogni elemento e la
struttura del documento stesso.
Diversi studiosi del settore stanno lavorando per sviluppare, implementare e memorizzare la
conoscenza contenuta in una guideline per tutto il suo ciclo di vita. I modelli che sono stati
realizzati variano secondo l’orientamento degli studiosi.
Gli autori si sono basati su 3 tipi diversi di risorse primarie per creare un insieme che sia
nucleo degli elementi di una guideline.
1.
La prima risorsa riguarda concetti relativi allo sviluppo e alla valutazione di una
guideline ed è l’Institute of Medicine’s Provisional Instrument for Assessing
Clinical Guidelines che fornisce un vasto insieme di criteri di valutazione per le
guidelines di pratica clinica. Lo scopo di questo strumento era quello di definire
gli attributi di una Guideline ideale, in modo tale da incoraggiare lo sviluppo
sistematico delle guidelines e fornire un approccio standardizzato e una struttura
per l’accertamento dei documenti della guideline.
2.
La seconda risorsa riguarda la pubblicizzazione delle guidelines on-line. Esso
fornisce uno schema per la classificazione dei componenti dei documenti della
guideline. Questo modello include un insieme di attributi-chiave che servono per
riassumere ogni guideline, così da facilitare la ricerca ed il recupero di
informazioni dal sito Web del NCG e da facilitare, anche, il confronto tra le
guidelines.
3.
La terza risorsa riguarda concetti d’implementazione per realizzare le
raccomandazioni presenti in una guideline e fa uso di un insieme di costrutti,
derivati, originariamente, dal modello di tabella di decisione aumentata trattato in
11.2.
La fig. 6 [13] mostra la gerarchia GEM.
Guideline
Document
Identity
Developer
Purpose
Intended
Audience
Method of
Development
Target
Population
Knowledge
Components
Testing
Revision
Plan
Fig. 6: Struttura gerarchica del modello GEM.
Ognuno di questi elementi contiene uno o più livelli addizionali di costrutti di guideline.
Gli elementi, a loro volta, possono contenerne altri contenenti testo libero, oppure essere
vuoti.
23
I componenti di GEM sono definiti come elementi XML ed hanno nomi distinti e sono
delimitati da un tag d’inizio e uno di fine.
Andiamo, ora, ad analizzare il primo livello gerarchico sotto la radice rappresentata da
Guideline Document.
Identity: quest’elemento include il titolo completo della guideline, una citazione che
referenzia la sua pubblicazione, la data di pubblicazione, la disponibilità di formato
elettronico o di formato di stampa e informazioni su una persona od organizzazione
contattabile per ulteriori informazioni. Al suo interno, inoltre, c’è un elemento, status, che
indica se la guideline è stata aggiornata o rivista e l’elemento adaptation che indica se la
guideline è stata adattata a partire da un’altra guideline.
Developer: quest’elemento conserva informazioni riguardanti l’organizzazione che si
occupa dello sviluppo della guideline e, quindi, anche una descrizione strutturata dello
sponsor della guideline stessa. In esso è rappresentato il nome del comitato all’interno
dell’organizzazione di sviluppo e i nomi dei membri del comitato o degli esperti che
partecipano al progetto.
Purpose: quest’elemento descrive le principali pratiche di cura, servizi o tecnologie
utilizzate dalla guideline e motivi per lo sviluppo della guideline stessa. L’elemento al suo
interno, chiamato category, classifica i maggiori interessi della guideline stessa, come ad
esempio diagnosi, trattamento o prevenzione. Nel purpose ci sono altri sottoelementi che
possono essere descritti: il rationale e l’objective. I due elementi sono sottilmente differenti
ma il modello permette di descriverne uno dei due oppure entrambi. Ci sono, inoltre, altri
sottoelementi interessanti quali exception (eccezione) che riguarda le eccezioni allo
sviluppo di una determinata guidelines.
Intended Audience: quest’elemento si riferisce ai providers di cura il cui
comportamento vuole essere modificato dall’utilizzo della guideline stessa. Al suo interno,
questo elemento include dei costrutti interessanti indicanti dove possono essere applicabili
le raccomandazioni di una guideline, per esempio un unità di cura intensiva.
Method of Development: quest’elemento riguarda la validità delle raccomandazioni
della guideline ed esse sono direttamente collegate alle prove scientifiche che le supportano.
I suoi sottoelementi descrivono, da vari punti di vista, le informazioni riguardanti le prove
scientifiche di una raccomandazione della guideline. Un suo sottoelemento specification
descrive qualitativamente i benefici anticipati, i potenziali rischi o le conseguenze avverse
associate all’esecuzione delle raccomandazioni di una guideline; il sottoelemento
quantification, invece, fornisce modelli matematici e stime numeriche utili, ad esempio, per
calcoli statistici.
Target Population: quest’elemento si riferisce all’insieme di persone che è il soggetto
delle raccomandazioni della guideline. Esso contiene il sottoelemento elegibility il quale
include i criteri d’inclusione e d’esclusione per scegliere quella parte di popolazione per cui
le raccomandazioni della guideline sono applicabili.
Testing: quest’elemento fornisce informazioni riguardo eventuali persone od
organizzazioni, esterne al team di sponsorizzazione, che hanno riesaminato le
raccomandazioni della guideline. Il suo sottoelemento pilot fornisce dei testi che riportano
eventuali tests delle raccomandazioni in ambienti clinici.
Revision Plan: in quest’elemento si forniscono le date di scadenza che aiutano a
verificare la validità delle raccomandazioni alla luce di nuove sperimentazioni.
24
Knowledge Components: in quest’elemento si categorizza e si fornisce la conoscenza
esperta della guideline. Gli autori hanno classificato le componenti di conoscenza in 3 classi
ad alto livello: recommendation, definition e algorithm. La fig. 7 mostra il modello più
dettagliato della gerarchia dei Knowledge Components che può essere analizzato
evidenziando le seguenti componenti.
Recommendation: Le raccomandazioni sono le uniche caratteristiche che distinguono
le Guidelines da altre pubblicazioni cliniche ed esse hanno lo scopo modificare il
comportamento dei medici. Le raccomandazioni si possono distinguere in condizionali e
imperative.
Guideline
Document
Knowledge
Components
Recommendation
Definition
Algorithm
Term
meaning
Conditional
Imperative
Term
Action
step
Conditional
step
Branch
step
Syncro
step
Fig. 7: Struttura gerarchica dell’elemento Knowledge Components.
Una raccomandazione condizionale può assumere l’espressione:
If CONDITION then Action(s)
{because REASON(s)}
Se la condizione (condition) è verificata allora si esegue/ono l’azione/i (action/s) e ne
vengono spiegate le ragioni (reasons). Una condizione è specificata da uno o più
combinazioni di variabili di decisione, i quali valori sono collegati da operatori di confronto.
L’esecuzione di una condizione da lo start ad almeno un’azione specificata dalla
guideline.
25
Le raccomandazioni imperative, spesso, includono locuzioni come “require”, “must” e
“should” ma non contengono parole riguardanti testi condizionali (quali “if”, “When”,
“Whenever”) che potrebbero limitare l’applicabilità delle circostanze specificate.
Definition: questo elemento fornisce la terminologia di una guideline e il significato dei
termini.
Algorithm: alcune guideline includono un algoritmo che è graficamente rappresentato
da un flowchart. Questo flowchart descrive la sequenza temporale delle attività e la
ramificazione della logica di decisione che implementa le raccomandazioni della guideline.
In GEM un flowchart può essere incluso in blocco come un elemento “algorithm” oppure
esso può essere suddiviso nelle sue parti componenti
I progettisti di GEM stanno ancora sviluppando il sistema; il campo di sviluppo
principale riguarda lo studio di strumenti per l’analisi e l’editing da fornire a GEM.
11. Le tabelle di decisione e le tabelle di decisione aumentate
Le tabelle di decisione possono fornire una semplice rappresentazione tabulare di una
complessa logica di decisione. Esse sono state usate, per oltre trent’anni, per verificare
l’ambiguità di un insieme di regole. I primi utilizzi nel campo medico vennero descritti nel
1975 dove si parlava del loro uso come alternativa ai flowcharts per facilitare la cura medica
[6].
Le tabelle di decisione consistono nel rappresentare la logica di una guideline sotto
forma di regole, all’interno della tabella di decisione stessa.
La conoscenza chiave contenuta in una guideline di pratica clinica è un insieme di
raccomandazioni per trattamenti di cura. Lo scopo di una guideline, come si è già spiegato,
non è quello di dare solamente informazioni, ma di influenzare la pratica clinica.
Un modello basato sulle regole sembra essere il modo più naturale per esprimere la
conoscenza di una guideline. Le regole sono delle condizioni logiche che legano una
combinazione logica di condizioni antecedenti ad un insieme di conseguenze.
Le suddette regole possono esprimere i 4 tipi generali di espressioni di una guideline:
1. Situazione/azione: Dato un insieme di condizioni cliniche sono raccomandate le
seguenti azioni.
2. Premessa/conclusione: data una lista di circostanze è valida la conclusione.
3. Sufficienza: Le circostanze elencate sono sufficienti a giustificare la proposizione
conseguente sebbene altre circostanze possano risultare nella stessa conclusione.
4. Definizione: Le condizioni antecedenti definiscono il significato della frase
conseguente.
11.1 La tabella di decisione: descrizione
Una tabella di decisione [5] è una matrice che associa un insieme di variabili di
decisione con un insieme di azioni. Nel campo medico le variabili di decisione sono i
sintomi, i risultati di una visita medica e i risultati di tests di laboratorio. Le azioni
26
includono l’inizio di un trattamento, l’intraprendere una valutazione diagnostica costosa o
rischiosa o la conclusione di un’attività.
Ogni valore di decisione di una tabella è un valore categorico (presente o assente),
oppure un valore compreso in un intervallo di valori. Il numero di valori che può assumere
una variabile è definito modulo della variabile stessa.
Il display convenzionale di una tabella di decisione elenca le variabili di decisione nel
quadrante superiore sinistro chiamato condition stub, mentre le azioni sono elencate nel
quadrante inferiore sinistro chiamato action stub. Il quadrante superiore destro, chiamato
condition entry, indica i possibili valori o stati della variabile di decisione mentre il
quadrante destro inferiore, chiamato action entry, indica le azioni appropriate corrispondenti
alla combinazione dei valori di decisione. Ogni colonna nell’area di entry è una regola, i cui
antecedenti sono derivati dalle condition entries e le cui conseguenze sono indicate dalle
action entries. In fig. 8 si mostra un esempio di una tabella di decisione [5].
Un insieme di regole si dice completo quando sono state considerate tutte le possibili
combinazioni dei valori di decisione. Si può verificare se un insieme di regole è completo,
verificando che il numero di regole mostrate sia uguale al prodotto dei moduli di tutte le
variabili di decisione. Si indica con modulo di una variabile di decisione il numero di valori
ammissibili per la stessa variabile. Se il numero di regole è inferiore al prodotto dei moduli
significa che l’insieme delle regole non è comprensivo; se, invece, il numero delle regole è
maggiore del prodotto dei moduli allora significa che c’è ambiguità nell’insieme di regole.
Ogni colonna dell’area delle condition entries rappresenta una regola ed, in particolar modo,
una colonna che contiene almeno un valore non definito (una lineetta) è chiamata regola
complessa. Il valore non definito nelle condition entries è da considerarsi come un grado di
libertà che permette dunque alla regola complessa in questione (corrispondente alla colonna
5 della fig. 8 A) di assumere diverse configurazioni secondo il valore di condizione
ammissibile che viene inserito al posto della lineetta. In questo modo, quindi, la regola
complessa rappresenta un insieme di più regole distinte.
Fig. 8: Esempio di Tabella di Decisione.
27
Con la voce column count di una regola complessa, s’indica il numero delle regole
rappresentate ed esso è calcolato facendo il prodotto dei moduli di tutte le entrate (con
lineetta) nella colonna. Nella fig.8 B la quinta column count ha valore 2 poiché, nella tabella
sopra, in corrispondenza della colonna 5, si hanno due valori distinti delle entrate (absent e
present) ed il valore della terza entrata rappresentato da una lineetta, il quale può assumere
due valori delle entrate. Il conto del column count è correttamente 2 in quanto prodotto
1*1*2.
Per determinare la completezza di una tabella si deve verificare che ci sia uguaglianza
tra il prodotto dei moduli e la somma dei column counts di tutte le regole e che tutte le
combinazioni delle variabili di decisione siano uniche.
Una tabella si dice completa se ∏ Moduli i = ∑ Column Count . Nell’esempio sopra si
j
i
3
ha
∏
i =1
Moduli i =
j
7
∑ Column Count j e dalla fig. 8 B si può verificare che per la formula in
j =1
questione si ha 8 = 8 e, quindi, la tabella considerata è completa.
Se due o più colonne contengono gli stessi valori di decisione allora l’insieme delle
regole rappresentato dalla tabella di decisione è ambiguo. L’ambiguità di una tabella
comprende tre possibili situazioni. La prima è che una regola è detta ridondante se 2 o più
colonne sono identiche. La seconda è che se due o più insiemi di valori di decisione sono gli
stessi ma le azioni richieste risultano essere differenti, allora l’insieme delle regole è detto
contraddittorio. La terza, infine, è quella che stabilisce che due insiemi di regole si dicono in
conflitto se hanno insiemi di condizioni differenti ma le azioni richieste combaciano.
Lo studio delle tabelle di decisione e delle sue proprietà ha dato origine all’elaborazione
di manipolazioni che semplificano la tabella di decisione. La manipolazione che viene
trattata è quella che permette di ridurre il numero delle regole andando ad eliminare tutte
quelle regole che coinvolgono test di variabili che risultano essere irrilevanti. Le prime
regole candidate all’eliminazione (considerate, quindi, irrilevanti) sono quelle che
richiedono una stessa azione, ma variano per solo una variabile di decisione. Se il modulo
della condizione differente è 2, allora significa che le 2 regole sono identiche tranne che per
il fatto che una contiene dei valori irrilevanti e l’altra la sua negazione. Una delle 2 regole
può essere eliminata e l’altra dovrà contenere nella casella delle entries, corrispondente alla
condizione che cambia, un valore non definito, vale a dire una lineetta, in modo tale da
tenere in considerazione entrambe i valori di decisione. La regola in questione, quindi, così
modificata diventa una regola complessa. Nell’esempio di fig. 8, la colonna 1 e la colonna 3
variano per un solo valore corrispondente al Phisical Finding ed il modulo corrispondente è
2. In base alla manipolazione appena esposta queste due regole possono essere ridotte ad
una sola, andando ad inserire, nella casella corrispondente al Phisical Finding, un valore non
definito. La tabella modificata viene mostrata nella fig. 9.
Esistono, inoltre, diverse tecniche che servono a manipolare le tabelle di decisione
quando l’insieme di regole è molto grande per ridurle ad una forma più facilmente
comprensibile.
Uno di questi meccanismi è quello di dividere un insieme di regole completo in sottotabelle
disgiunte basate su comuni fattori di decisione. Questi sottoinsiemi separati di regole
28
possono essere chiamati e gestiti da una tabella di decisione (principale) “master” e
possono restituire i valori definiti dalla logica delle sottotabelle alla tabella master che,
quindi, può manipolarli direttamente.
Condition Stub
Condition Entries
M
Symptom
Physical Finding
Lab Result
Treatment 1
Treatment 2
od
2
2
2
1
2
3
Present Present
Present
4
Absent
--Present Absent Present
Positive Negative Negative
--X
X
X
X
5
6
Absent
Absent
Absent
Positive
Absent
Negative
X
X
Action Entries
Action Stub
Fig. 9: Tabella di Decisione modificata.
Il vantaggio di questa prima tecnica di semplificazione di una tabella di decisione è
evidentemente quello di una modularizzazzione in più tabelle di decisione facilmente
comprensibili. Questi diversi moduli tabellari sono gestiti dalla tabella master.
Un altro meccanismo per semplificare insiemi di regole complesse fa uso della
cosiddetta “subsunzione semantica”. La subsunzione può essere utilizzata per semplificare
un insieme di regole qualora il significato di una regola è già espresso da un’altra che
richiede la stessa conclusione da condizioni meno restrittive. La subsunzione semantica,
dunque, stabilisce la seguente regola: le regole che inducono alla stessa conclusione, ma
hanno minori antecedenti, possono subsumere quelle con un maggior numero d’antecedenti.
Le regole con maggiori antecedenti vengono eliminate. Un esempio della subsunzione
semantica è il seguente: livelli crescenti di colesterolo sono associati con crescenti rischi di
eventi cardiovascolari avversi. Consideriamo un insieme di regole che definisca
esaustivamente delle circostanze cliniche per appropriate prescrizioni mediche per
l’abbassamento dei lipidi e riconosca diversi livelli di colesterolo: basso, moderato ed alto.
Una regola specifica: SE il paziente ha fattori di rischio A, B e C ed un moderato livello di
colesterolo, ALLORA trattalo con medicazioni di abbassamento di lipidi. Si dovrebbe
predire che un’altra regola in un insieme comprensivo dovrebbe specificare: SE il paziente
ha fattori di rischio A, B e C ed un alto livello di colesterolo, ALLORA trattalo con
medicazioni di abbassamento di lipidi. Questa predizione è possibile in quanto se un
paziente avente moderato rischio di colesterolo viene trattato con medicazioni di
abbassamento lipidi, a maggior ragione, tali medicazioni devono essere applicate a pazienti
aventi un elevato rischio di colesterolo. Ciò significa che la regola, che si applica ai pazienti
con moderato colesterolo, semanticamente subsume la regola applicabile ai pazienti con alti
livelli di colesterolo e rende possibile riassumere le due regole in una singola regola
ampliata.
29
11.2 La tabella di decisione aumentata
La tabella di decisione si dice “aumentata” per la sua struttura multistrato in cui
l’informazione collaterale è immagazzinata in slots a vari livelli sotto la vista della logica
della tabella di decisione convenzionale [5].
L’aumento di una tabella può riguardare diverse caratteristiche della tabella di decisione.
Il primo “aumento” riguarda l’aumento delle condition stubs e delle action stubs: uno
strato può essere utilizzato per migliorare la spiegazione e la descrizione delle azioni
raccomandate e delle variabili di decisione.
Il secondo riguarda l’aumento dell’informazione delle righe: ogni variabile di decisione è
associata con delle probabilità condizionali quali sensibilità, specificità e valori affermativi,
i quali possono convenientemente occupare una riga; così come potrebbero essere
immagazzinate in altri strati le informazioni riguardanti la decomposizione e la riduzione di
una tabella ed anche l’informazione riguardante la gerarchia di subsunzione, vale a dire che
viene riportata la gerarchia (in ordine di num. di antecedenti)di quelle regole che portano
alla stessa conclusione ma hanno tra loro un diverso numero di condizioni antecedenti.
In fig. 10 [5] si mostra la struttura multistrato della Tabella di Decisione Aumentata.
Logic Layer
Sens, spec, PV
Relevance
Subsumption
Description
Source
Cost, risk
Vocab listing
Queries
Total cost, risk
Frequency
Evidence
Literature citations
Explanation
Enforcement
Fig. 10: Struttura multistrato della Tabella di Decisione Aumentata
Il terzo riguarda l’aumento delle colonne di una tabella: ogni colonna può essere
associata con valori derivati quali possono essere probabilità disgiunte, etc.
30
11.3 Vantaggi delle tabelle di decisione aumentate
Elenchiamo, ora, le qualità, desiderabili in una guideline, che attestano l’efficacia della
rappresentazione della conoscenza tramite tabelle di decisione aumentate:
- La verificabilità di un insieme di regole di una tabella di decisione può aiutare a garantire
l’integrità logica delle raccomandazioni di una guideline.
- Le tabelle di decisione possono essere utili durante la prima fase di creazione di una
guideline quando la logica non è ancora stata ben definita.
- La modularità della rappresentazione della tabella di decisione può aiutare nel processo di
aggiornamento di una guideline.
- Le tabelle di decisione possono essere funzionalmente equivalenti ad un linguaggio di
programmazione e possono codificare sequenze, iterazioni e branching. Le tabelle di
decisione aumentate, tuttavia, potrebbero essere eseguite direttamente da programmi di
processamento specializzati.
In conclusione, è da notare che la rappresentazione di conoscenza tramite tabella di
decisione aumentata non è ancora stata convalidata da osservazioni empiriche riguardanti
l’efficacia nello sviluppo delle guidelines o come supporto alla decisione. Ciò significa che,
ad oggi, nessun sistema utilizza la teoria delle tabelle di decisione aumentate per
rappresentare la conoscenza contenuta in una guideline, tuttavia questa filosofia è stata
descritta perché risulta essere molto diversa dagli altri tipi di approcci utilizzati dagli altri
sistemi.
Per realizzare tutte le potenzialità di questo modello di conoscenza, gli studiosi, in
particolare Richard Shiffman [5], che ha dato origine allo studio di questa nuova filosofia di
rappresentazione, pensano che sarà necessario richiedere ai gruppi di sviluppo di una
guideline una certa familiarità con un approccio basato sulle regole, che rappresentano la
conoscenza di una guideline. Questa richiesta è importante in quanto si è verificato che
molti informatici e professionisti dei sistemi d’informazione non sono abituati all’approccio
richiesto dalle tabelle di decisione e questo potrebbe causare problemi nell’implementazione
delle tabelle. Se essi devono usare le tabelle di decisione nello sviluppo e
nell’implementazione di una Guideline, dovranno anche conoscere bene questi costrutti.
Inoltre, devono essere creati degli strumenti che permettano ai non professionisti di creare,
visualizzare e manipolare un insieme di regole di una tabella di decisione aumentata. Questo
approccio dovrà poi essere valutato adeguatamente per assicurarne la sua efficacia.
12. Altri sistemi di gestione delle Guideline
Oltre quelli già presentati esistono altri sistemi di gestione delle Guideline:
•
•
•
•
•
PROforma
ONCOCIN
Prodigy-Prodigy3
Asbru
DILEMMA
31
12.1 Il sistema PROforma
Il sistema PROforma [3], ideato da Fox nel 1998, per rappresentare Guideline, utilizza
un approccio basato sulla logica. Le Guideline sono rappresentate in una forma di
conoscenza dichiarativa dove la scelta della Guideline e dei componenti della Guideline, che
devono essere applicati ad un paziente in un preciso istante di tempo, è governata da criteri
logici. In PROforma, le Guideline sono modellate in termini di un’ontologia di task
(compito, azione), consistenti in decisions, actions, enquiries e plans, le quali, a loro volta,
possono essere decomposte in ulteriori task più dettagliati. Tutti i task del sistema
PROforma hanno i seguenti attributi: trigger, goal, precondition e postcondition. I task sono
descritti dalle loro scheduling constraints (elenco di limitazioni), preconditions e
postconditions. Un gestore di task che esegue un task può scrivere nuovi fatti da un database
globale e quindi effettuare l’attivazione di altri task, attraverso la valutazione delle loro
precondizioni. Qualsiasi numero di task può essere attivato simultaneamente [3].
In PROforma, ogni task può avere un fine che consiste di un criterio logico che
dovrebbe essere raggiunto. Le decisioni sono prese attraverso una struttura di
argomentazione che valuta ogni scelta alternativa in termini di argomenti a favore o contro
tale scelta; la preferenza per un’alternativa è determinata da una funzione di aggregazione
che pesa gli aspetti a favore o contro di una specifica alternativa.
12.2 Il sistema ONCOCIN
Il sistema ONCOCIN [3], come mostrato in fig. 11, è stato uno dei primi sistemi ad aver
tentato di modellizzare le specifiche di decisioni e di successione di azioni da compiere.
Esso ha fatto da pioniere ad un approccio basato sul network per modellizzare i Clinical
Trial protocols riguardanti patologie oncologiche. ONCOCIN ha sviluppato un linguaggio
di flowchart che ha permesso la specifica della sequenza, iterazione ed esecuzione
simultanea di azioni.
Le semantiche del linguaggio del flowchart di ONCOCIN sono essenzialmente
composte da augmented transition network (ATN). Un ATN è un diagramma di transizioni
finite di stati (FSTD) aumentato con alcuni attributi [3]. Un FSTD è costituito da un numero
di stati (nodi) con archi che conducono da uno stato all’altro; gli archi hanno delle etichette
che devono essere collegate con l’input per poter passare all’attività (stato) successiva. A
causa dell’impossibilità di rappresentare criteri ed azioni complessi, gli FSTD puri non sono
adatti a rappresentare le Guideline di pratica clinica. Così molti formalismi di Guideline,
basati sul network, usano un ATN come base per rappresentare gli aspetti procedurali delle
Guideline e dei protocolli.
Un ATN è un FSTD che può essere esteso in 4 modi:
Gli archi dell’ATN possono essere ampliati da sotto-network
1. Un numero di registri può essere usato per immagazzinare l’informazione
2. Gli archi, senza le etichette, possono essere associati a dei test che devono essere
soddisfatti prima che si esegua l’attività segnalata dall’arco
3. Alcune azioni possono essere connesse ad un arco ed eseguite ogniqualvolta
l’arco viene preso
32
Nel linguaggio di flowchart di ONCOCIN ogni nodo è associato ad un’attività o ad
un’azione logicamente istantanea. Le transizioni possono avvenire quando il tempo è
terminato oppure quando un esplicito criterio di transizione è valutato true. ONCOCIN è,
inoltre fornito di un database temporale del paziente che si comporta come un registro in cui
può essere memorizzata l’informazione e dal quale possono essere reperiti modelli
temporali di terapie compiute e stati del paziente. In fig. 11 [3] si mostra uno schema di
trattamento con il sistema ONCOCIN.
12.3 Il sistema Prodigy - Prodigy3
Il Prodigy [3, 9] (Prescribing RatiOnally with Decision-support In General-practice
studY) è un progetto fondato dal National Health Service of the United Kingdom ed iniziato
nel 1995. Lo scopo di questo progetto è di sviluppare un sistema di supporto alla decisione
basato sulle Guideline che assista i medici.
Nel modello Prodigy, una raccomandazione di una Guideline è considerata appropriata, per
diverse combinazioni di stati del paziente, chiamati scenarios (scenari), data una particolare
diagnosi. Ogni scenario può avere differenti strategie per il trattamento; ognuna di queste
strategie può essere ulteriormente suddivisa in istruzioni più dettagliate. Esso usa diverse
tecniche per gestire la complessità dei modelli delle Guideline.
Vam
A1
A2
Pocc
Pci
Repeat until complete response
Start
Vam
A
B
Pocc
Repeat until 1 year
Stop
No
Yes
Cavp
Complete response?
B1
B2
Pci
No
Yes
Cavp
Progression?
Ccom
Repeat until 1 year
Repeat until 1 year
Fig. 11: Esempio di schema di trattamento con ONCOCIN
Una di queste è la funzione che ha la possibilità di suddividere un algoritmo clinico in
management algorithms in modo tale da rappresentare delle alternative di decisione,
33
un’altra è la consultation templates che definisce un insieme di dati sensibili al contesto che
si riferiscono alla buona pratica clinica. In ultimo, c’è la possibilità di costruire delle sottoguideline con la funzione subguidelines che permette di descrivere più minuziosamente gli
scenari e le alternative di decisione [3]. Il modello Prodigy divide gli interventi clinici in
azioni, che sono considerate istantanee, e in attività che vengono iniziate e durano finché
esse non vengono modificate oppure terminate.
Il progetto Prodigy in seguito si è evoluto dando origine alla terza fase del progetto
iniziale, chiamato Prodigy3.
Questo progetto, come ONCOCIN, usa un ATN per modellizzare la sequenza delle
decisioni di una Guideline.
Prodigy3 modellizza una guideline attraverso un network di scenari-paziente e di
decisioni, le cui conseguenze conducono ad altri scenari. Uno scenario è uno stato-paziente
caratterizzato dalle condizioni del paziente e dalle modalità di trattamento. Associato con
ogni scenario vi è un template di consultazione che specifica il best-practice workup
(l’attivazione della decisione più appropriata) per il paziente e una scelta tra percorsi di
azioni alternativi che conduce ad una transizione verso altri scenari. Per ogni scelta,
Prodigy3 usa un modello di decisione dove i criteri di rule-in (precondizioni) e rule-out
(postcondizioni), associati con ogni alternativa, determinano la preferenza raccomandata per
l’alternativa.
Prodigy3, in pratica, modellizza una guideline in un numero di decisioni che il
professionista può dover prendere in differenti incontri. Come ONCOCIN, Prodigy3 utilizza
un database del paziente come un registro nel quale l’informazione può essere scritta o dal
quale può essere letta. Diversamente da ONCOCIN le transizioni tra scenari avvengono
quando vengono fatte delle scelte esplicite tra alternative di trattamento. In fig. 12 [3] si
mostra un esempio di una decisione di una Guideline gestita col sistema Prodigy3 [3].
Rule-in:
Scenario
Action step
BP
adequaltely
controlled
Taking no antihypertensive
medication
Continue lifestyle change
Action step
Rule-in: BP not
adequaltely
controlled for
> 6 months
Scenario
Taking antihypertensive
medication
Initiate drug
therapy
Fig. 12: Esempio di decisone di una Guideline con Prodigy3
34
12.4 Il sistema Asbru
Asbru è un linguaggio basato sulle intenzioni (intention-based) che è stato sviluppato
alla Stanford University per la rappresentazione delle CG [4, 8]. Il sistema permette la
rappresentazione esplicita delle intenzioni di una CG (ad es. gli scopi), degli stati-paziente e
di azioni prestabilite, ognuna delle quali ha una rappresentazione temporale. Le basi
concettuali di questo sistema sono costituite da azioni, ovvero compiti specifici che devono
essere realizzati, piani, specifiche delle Guideline e dei loro componenti individuali, e da
intenzioni ovvero scopi che devono essere raggiunti, mantenuti o evitati ai diversi livelli
della Guideline.
Un piano è composto da un insieme di sotto-piani; un sotto-piano è riferito ad un’azione
solamente quando esso non può essere ulteriormente decomposto. I piani sono descritti da
alcuni stati interni che possono assumere le seguenti configurazioni: iniziato, completato,
sospeso, ricominciato, abortito. Le transizioni tra gli stati sono specificati da criteri di
transizione tra stati. I piani possono essere sequenziali, paralleli o ciclici.
In Asbru possono anche essere definiti dei vincoli temporali, come sequence (sequenza)
o concurrence (parallelismo), i quali possono essere definiti attraverso due “dimensioni”,
ovvero due aspetti di definizione. La prima è quella che prende in considerazione
l’ordinamento dei vincoli e può assumere i valori any order o total order. La seconda
prende in considerazione le condizioni di proseguimento e può assumere i valori all
completed (tutti completati) o some completed (alcuni completati). Le combinazioni di
queste due dimensioni danno origine a cinque vincoli temporali delle primitive di
rappresentazione: do-all-together (esegui tutti insieme), do-some-together (esegui alcuni
insieme), do-all-any-order (esegui tutti senza ordine), do-some-any-order (esegui alcuni
senza ordine) e do-all-sequentially (esegui tutti sequenzialmente). Inoltre, Asbru fornisce
una terza categoria di vincoli temporali ed è il ciclo. Ognuno di questi vincoli è stato
rappresentato all’interno di suoi plan-body [4, 8].
12.5 Il sistema DILEMMA
Il progetto DILEMMA [9] è iniziato all’interno del 1991-94 AIM program of the
European Commission con lo scopo di sviluppare un supporto di decisione computerizzato,
in particolare per la prescrizione di farmaci. Il progetto DILEMMA deriva direttamente dal
progetto LEMMA, il quale aveva l’obiettivo principale di applicare un approccio di tipo
“logic engineering” alle terapie sul cancro [19]. Il DILEMMA ha un modello d’oggetto che
contiene una gerarchia di attività con delle transizioni di stato specificate per ognuna di
queste attività. DILEMMA rappresenta le Guideline come un insieme di protocols
(protocolli), all’interno dei quali sono codificate le azioni che devono essere eseguite allo
scopo di realizzare determinati task clinici. Un protocollo può essere anche l’elemento
componente di un altro protocollo. Quando un protocollo viene implementato, viene
generata una procedura, la quale è definita come un tipo di azione. Questa procedura può
assumere uno di seguenti stati di azione: pertinente, stabilito, richiesto, accettato e
cancellato. Una transizione di stato è controllata dai criteri di transizione di stato, i quali
sono responsabili nel controllo delle sequenze nelle quali i protocolli sono implementati. I
criteri sono valutati per selezionare i protocolli che sono rilevanti in un momento specifico.
35
13. Confronto tra le caratteristiche dei sistemi
In questo capitolo vengono fatti due confronti distinti tra i sistemi descritti in
precedenza. Tali confronti riguardano, rispettivamente, il primo le caratteristiche di
rappresentazione temporale e delle primitive di rappresentazione dei sistemi, mentre il
secondo le ulteriori proprietà ed opzioni di cui sono dotati i sistemi.
13.1 Primo confronto
Il primo confronto (vedi tabella 1) si basa su due aspetti particolari: la rappresentazione
delle primitive e la struttura delle primitive [4]. In tabella 1 [4] vengono confrontati i
seguenti sistemi: Arden Syntax, EON, PROforma, GLIF, Asbru e Prodigy.
Rappresentazione delle primitive
Si indica con questa definizione il modo di rappresentare le primitive. I modi di
rappresentare le primitive possono essere molto diversi, nonostante possano rappresentare lo
stesso tipo di primitive. Nella tabella 1 si mostrano 4 modi di rappresentazione delle
primitive: attraverso decisioni (decisions), attraverso azioni (actions), attraverso statipaziente (patient state) e attraverso stati di esecuzione (execution state). Tutti i sistemi
presi in considerazione utilizzano almeno uno di questi modi per rappresentare le primitive.
Un’azione è un task clinico che deve essere realizzato o raccomandato nel processo
d’applicazione della guideline.
Tabella 1: Modelli di rappresentazione delle guideline e loro caratteristiche
Rappresentazione delle primitive
Guideline
Model
Arden Syntax
DILEMMA
Decision
Action
Strutture per le primitive
Patient state
Execution
state
No
Procedure
state
No
Temporal
Constraints
Module invocation
Prot. Composition st.
trans. Diagram
Flowchart
Task state
Logic slot
State transition
Action slot
Protocol
No
N/a
EON
Decision step
Action, Activity
PROforma
Decision
Action, enquiry
Scenario, activity
state
N/a
GLIF
Decision step
Action step
Patient state step
No
Constraints
satisfaction graph
Flowchart
Asbru
Condition
preference
Decision
Plan
Temporal
patterns
Scenario
Plan state
Plan-body
N/a
State transition
diagram
PRODIGY
N/a:
Action, activity
Nesting
Subguideline
Patient Data
Modeling
No
Patient record
model
EPR ontology
Plan
N/a
Subguideline
Plan
Three-layer
domain ontology
N/a
Subguideline
EPR ontology
No
Protocol
informazione non disponibile dalle pubblicazioni
Una decisione è una scelta, tra un insieme di alternative, basata su alcuni criteri
predefiniti nella guideline stessa. Uno stato-paziente è la descrizione di un paziente trattato
che si basa sulle azioni realizzate e le decisioni prese per un paziente specifico nel contesto
36
di una guideline. Uno stato d’esecuzione è la descrizione del sistema d’implementazione di
una guideline, basato sui passi del processo riguardo alle decisioni ed azioni definite in una
guideline.
L’Arden Syntax ha uno slot logico utilizzato per codificare un MLM (Medical Logic
Module) e uno slot d’azione usato per codificare i compiti clinici che dovrebbero essere
realizzati.
GLIF, invece, ha uno step d’azione, uno step di decisione e uno step di stato-paziente
che corrispondono rispettivamente ad un’azione, una decisione e uno stato-paziente.
Rispetto a GLIF, l’Arden Syntax non ha la possibilità di rappresentare stati-paziente o stati
d’esecuzione e ciò, chiaramente, limita molto la sua capacità di rappresentare direttamente
guidelines complesse, anche se una possibilità è data dall’inserimento di stati intermedi tra
MLMs collegati.
DILEMMA rappresenta le guidelines come un insieme di protocolli all’interno dei quali
sono codificate le azioni.
Con DILEMMA gli stati di esecuzione si rappresentano con degli stati di procedure e le
decisioni con delle transizioni di stati. Un approccio simile è utilizzato in Asbru dove le
conditions (condizioni) e le preferences corrispondono a decisions e plans e plan states
corrispondono ad azioni e a stati d’esecuzione.
EON distingue un’activity (attività),che è un processo continuo, da un’action (azione),
che è un processo istantaneo. Di conseguenza esso propone sia un patient scenario che è
usato per descrivere gli stati-paziente con riguardo alle decisioni prese e alle azioni
completate, sia un activity state che è usato per descrivere gli stati-paziente con riguardo
allo stato delle attività applicate al paziente. Un approccio simile è stato realizzato anche in
PRODIGY.
PROforma, rispetto ai sistemi fin qui visti, ha uno speciale tipo d’azione, chiamata
enquiry, che è usata per collezionare l’informazione piuttosto che gli interventi. Questo tipo
d’informazione non influisce sugli stati-paziente, ma serve solamente a dare una
comprensione più chiara di essi. La funzione appena vista ha lo stesso compito della
temporal query presente in EON e della get_data_collection presente in GLIF.
Struttura delle primitive: Temporal constraints e Nesting
Si indica con questa definizione il modo di collegare, tra di loro, le primitive di
rappresentazione. Nella tabella 1 di confronto [4] si prendono in considerazione due
possibili strutturazioni delle primitive: la prima prende in considerazione i vincoli
temporali (temporal constraints) che sussistono tra le primitive, mentre la seconda tiene in
considerazione il possibile annidamento (nesting) delle primitive. I vincoli temporali, in
questo contesto, specificano l’ordine temporale con cui devono essere eseguite le primitive.
L’annidamento delle Guideline, invece, ha il compito di rappresentare la composizione di
una Guideline complessa, attraverso l’utilizzo di sotto-guideline “annidate” [4].
In Asbru le temporal constraints come sequence o concurrence possono essere
rappresentate in 2 dimensioni. La combinazione di queste dimensioni danno luogo a 5 tipi di
rappresentazione per le primitive e sono: do-all-together, do-some-together, do-all-anyorder, do-some-any-order e do-all-sequentially. Oltre a queste 5 tipi, Asbru fornisce anche
un altro tipo di temporal constraint che è il ciclo. Queste temporal constraints sono
rappresentate all’interno di un plan-body. Lo stesso approccio è usato in EON e anche in
GLIF. Quest’ultimo usa dei branch step e syncronisation step per realizzare sequenze in
ordine qualsiasi e concurrence, mentre si usa il next step per realizzare sequenze semplici. Il
37
branch step definisce un punto in un flowchart che è seguito, ad esempio, da percorsi in
parallelo. Il syncronisation step definisce un punto in cui i percorsi divergenti convergono
tutti.
Diversamente da Asbru per ciò che riguarda i cicli, GLIF definisce un ciclo singolo
all’interno di una singola primitiva ed un ciclo complesso in una subguideline.
DILEMMA, in modo simile, supporta la rappresentazione di sequenza, parallelo e
possibilità esclusive nella composizione del suo protocollo.
EON, GLIF e GUIDE rappresentano i vincoli temporali come un flowchart, PROforma
le rappresenta come un constraints satisfaction graph, mentre DILEMMA rappresenta i
vincoli temporali sui protocolli nel suo protocol composition e i vincoli temporali sugli stati
di procedure col suo state transition diagram.
PRODIGY, invece, modellizza una guideline come un diagramma di transizioni di stati
tra scenari-paziente; questo tipo di approccio può essere molto interessante nelle guideline
di malattie croniche, dove intervengono molto spesso multipli scenari-paziente.
Il Nesting (annidamento) è un’altra importante caratteristica della rappresentazione in
quanto esso permette multipli livelli d’astrazione, nella rappresentazione di una Guideline.
L’Arden Syntax non supporta il nesting, ma tutti gli altri sistemi lo utilizzano.
DILEMMA realizza il nesting attraverso la decomposizione ricorsiva del protocollo, EON,
GLIF e PRODIGY con l’introduzione di sotto-guideline.
13.2 Secondo confronto
Il secondo tipo di confronto che viene proposto (vedi tab. 2 [8]), riguarda altri tipi di
caratteristiche dei modelli di Guideline quali: caratteristiche algoritmiche del modello
(Algorithmic), possibilità di supportare sotto-guideline (Subguideline support), possibilità di
supportare criteri di decisione (Support decision criteria), supporto alla scelta di intenzioni e
scopi (Intentions and goals support) ed il Ranking of options supported. I sistemi che
vengono confrontati [8], sulla base delle 5 caratteristiche enunciate sono i seguenti: GLIF,
EON, Asbru, PROforma, Prodigy e GEM.
Tabella 2: Confronto tra i diversi modelli di guideline
Modelli
Algorithmic
GLIF
Si
EON
Si
Asbru
Si
Subguideline
Support
Si
Si
Si
Support
Decision
Criteria
Si
Si
Intentions and
Goals Support
Possibile
con Sottoguideline
Si
Ranking of
Options
Supported
PROforma
Non
principalmente
Si
Prodigy
Si
Si
GEM
Non
principalmente
No
Si
(temporale)
Si
Si
Si
Si
Si
Si
No
No
Si
No
Si
Si
Si
38
14. La filosofia di rappresentazione tramite Workflow
Un aspetto completamente diverso, invece, assume la rappresentazione di Clinical
Guideline attraverso Workflow. Un Workflow è “l’automazione di un processo di business,
in tutto o in parte, durante il quale i documenti, l’informazione o i task sono passati da un
partecipante all’altro, secondo un insieme di regole procedurali”[21]. L’uso di un WF
implica una rappresentazione formale del processo, nel caso specifico di un Clinical Trial,
in termini di task, attori, documenti, etc. Per gestire l’esecuzione di un WF si utilizza un
WFMS (WorkFlow Management System) che è “un sistema che definisce, crea e gestisce
l’esecuzione di un WF attraverso l’uso di software, che girano su uno o più motori di WF, il
quale è capace di interpretare la definizione del processo, interagire con i partecipanti del
WF e, quando richiesto, invoca l’uso di strumenti ed applicazioni IT” [21].
L’uso di un WFMS rende possibile definire e quindi gestire i processi; per questa
ragione la tecnologia WF applicata sui Trial Clinici apporta alla gestione di questi ultimi i
seguenti miglioramenti:
- standardizzazione del processo
- management del processo
- efficiente distribuzione agli esecutori del WF dei task basati sulle
informazioni
- esplicita focalizzazione dell’attenzione sul disegno del processo
Il valore aggiunto fornito dall’automazione di un WF è rappresentato essenzialmente
dalla formale descrizione del Clinical Trial basata su un modello concettuale di WF e
dall’esecuzione e valutazione di istanze WF basate sull’uso di WFMS. Questo approccio
interpreta una clinical guideline come un flusso di lavoro che consiste nell’esecuzione delle
attività della guideline secondo un ordinamento temporale stabilito da primitive di
rappresentazione e condizioni che ne ordinano il flusso.
Un sistema che permette la rappresentazione di Clinical Guideline sotto forma di un
sistema workflow è il modello Atreus [20], il quale permette di rappresentare graficamente
una Guideline, in modo tale da modellizzare le attività che la costituiscono, di rappresentare
testualmente la guideline, tenendo in considerazione le condizioni che controllano
l’esecuzione delle attività e tutte le informazione inerenti ogni singola attività, ed in ultimo
un diagramma di stato che permette il controllo dell’esecuzione delle attività.
I futuri sviluppi nel campo dei WF sono lo sviluppo di un sistema che supporti la fase di
definizione di un Clinical Trial ed, in particolare, la fase di scrittura collaborativa di un
Clinica Trial basata sull’utilizzo del modello di Workflow Atreus (in avanzata fase di
scrittura [2]).
15. Conclusioni
Si è visto che, dai primi anni ’70 ad oggi, lo studio della rappresentazione e della
gestione delle Clinical Guideline ha subito notevoli sviluppi. Dai primi sistemi come HELP
e ONCOCIN si è passati allo studio di uno “standard” di rappresentazione qual è stato per
anni l’Arden Syntax che ha rappresentato una base di partenza per successivi studi.
Successivamente, importanti studi sono stati fatti dai progettisti di GLIF, di GEM e delle
39
tabelle di decisione, i quali sono tutti collegati, in qualche modo, con gli altri sistemi
esistenti sull’argomento, quali DILEMMA, PROforma e PRODIGY. Coloro che, invece,
hanno deciso di prendere una strada completamente diversa rispetto a quelle battute
precedentemente, sono gli studiosi che hanno volto i loro interessi nel cercare di
rappresentare le Clinical Guideline attraverso i Workflow. Gli studi in questo campo non
sono molto avanzati ma si percepisce che questa metodologia abbia grandi potenzialità di
sviluppo, di rappresentazione e d’esecuzione per le Clinical Guideline ed i Clinical Trial. Ci
si aspetta, dunque, nel prossimo futuro di assistere ad uno sviluppo considerevole della
tecnologia WF applicata alle Clinical Guideline e, conseguentemente, ai Clinical Trial.
40
Bibliografia
1. Guideline for good medical practice. Disponibile al sito
http://www.eortc.be/documents
2 P. Fazi, D. Luzi, F.L. Ricci, M. Vignetti: The conceptual basis of WITH, a Collaborative Writer System of
Clinical Trials. 2002
3. Samson W. Tu, Mark A. Musen: Representation Formalism and Computational Methods for Modeling
Guideline-Based Patient Care. First European Workshop on Computer-Based Support for Clinical
Guidelines and Protocols 2000;:125-42.
4. D. Wang, M. Peleg, Samson W. Tu, Edward H. Shortliffe, R. A. Greenes: Representation of Clinical
Practice Guidelines For Computer-Based Implementations. Medinfo, London UK 2001.
5. Richard N. Shiffman: Representation of Clinical Practice Guidelines in Conventional and Augmented
Decision Tables. JAMIA 1997; 4(5):382-393.
6. P. Gershkovich, Richard N. Shiffman: An implementation Framework for GEM Encoded Guidelines.
AMIA 2001.
7. L. Ohno-Machado, R. A. Greenes, Edward H. Shortliffe: Sharable Representation of Clinical Guidelines
in GLIF: Relationship with the Arden Syntax. Journal of the Biomedical Informatics 2001.
8. A. Boxwala, R. A. Greenes, E.H. Shortliffe et al.: Toward Standardisation of Electronic Guideline
Representation. MD Computing 17(6): 39-44; 2000.
9. Richard N. Shiffman et al.: A Preliminary Evaluation of Guideline Content Mark-up Using GEM—An
XML Guideline Elements Model. Proc. AMIA Annual Symposium; 2000.
10. M. Peleg, A. Boxwala, Edward H. Shortliffe et al.: GLIF3: The Evolution of a Guideline Representation
Format. Proc. AMIA Symposium 2000;: 645-9.
11. L. Ohno-Machado, E. H. Shortliffe et al.: The GuideLine Interchange Format: A Model for Representing
Guidelines. JAMIA 1998;5(4): 357-372.
12. P. Fazi, D. Luzi, F.L. Ricci, M. Vignetti: Methodology for the Design of Clinical Trial Collaborative
Writing System. Rapporto tecnico in fase di stampa.
13. R. N. Shiffman et al.: GEM: A Proposal for a more Comprehensive Guideline Documento Model Using
XML. JAMIA 2000;: 7:488-498.
14. G. Hripsack, P. Ludemann et al.: Rationale for the Arden Syntax. Comput Biomed Res 1994; 27(4): 291324.
15 A, Barr, F,A. Feigenbaum: Handbook of artificial intelligence (vol. 1, 2). William Kaufman Inc: los
Altos, 1982.
16. A. Boxwala, R.A. Greenes et al.: Architecture for a multipurpose guideline execution engine. Proc 1999
AMIA Annual Fall Symposium, Washington DC, 1999. Philadelphia: Hanley & Belfus. JAMIA 1999; 6
(suppl): 701-705.
17. E. Pattison-Gordon: ODIF: Object Data Interchange Format. Boston, MA: Decision Systems Group,
Brigham and Women’s Hospital; 1996. Report No.: DSG-96-04.
18. W3C. Extensible Markup Language (XML). In http://www.w3.org/XML/; 2000.
19. J. Fox, R. Thomson: Decision support and disease management: a logic engineering approach. IEEE
transactions on Information Tech in Biomed 1998; 2(4): 1-12.
20. P. Grifoni, D. Luzi, P. Merialdo, F.L. Ricci: A Conceptual Representation of Clinical and Managerial
Guidelines: The ATREUS Workflow Model. MEDINFO 1998 B. Cesnik et al. (Eds), Amsterdam: IOS Press
1998 IMIA.
21. P. Fazi, P. Grifoni, D. Luzi, F.L. Ricci, M. Vignetti: Is Workflow technology suitable to represent and
manage clinical trials? MIE 2000.
41