Insegnamento di Informatica Sanitaria
Laurea Specialistica in Bioingegneria
A.A. 2005-2006
ALCUNE NOTE SULLA
CARTELLA CLINICA ELETTRONICA
1. LA CARTELLA CLINICA ELETTRONICA
Il progresso delle scienze mediche ha portato anche ad una loro consistente frammentazione. Un
paziente può dover ricorrere al parere di specialisti che operano in campi diversi, ed ognuno di essi
aprirà una nuova cartella clinica cartacea. Dal momento che questa può essere fisicamente presente
in un solo luogo per volta, diventa molto difficile ricostruire completamente la storia clinica
dell’assistito. Spesso, inoltre, la calligrafia può risultare difficile da leggere, possono mancare dei
dati importanti, o non essere rintracciabili perché annotati in luoghi diversi. Ogni medico ha il suo
modus operandi, e non sempre risultano semplici dialogo e confronto con altri. Un altro
fondamentale limite della cartella clinica cartacea è che essa interagisce solo passivamente nelle
decisioni del medico, senza per esempio attirare l'attenzione verso allergie o intolleranze al
momento della prescrizione di cure e farmaci. Notevoli impedimenti si hanno anche per quanto
riguarda la ricerca, la redazione di statistiche, e la programmazione sanitaria, a causa della difficile
gestione delle spedizioni per il formato cartaceo, lo scarso controllo della privacy, ecc…
Lo scopo principale della cartella clinica elettronica è:
“Fornire un documento attendibile che contenga informazioni cliniche che siano di supporto alle
cure sanitarie presenti e future, per opera dello stesso o di diversi medici”.
Il supporto elettronico fornisce la possibilità di trasformare i dati in formati diversi per destinarli a
diversi tipi di utenti:
- i fornitori dell'assistenza medica: medici di medicina generale e specialisti, ma anche
dentisti, farmacisti, infermieri, ecc...;
- i fruitori dell'assistenza: pazienti e loro familiari;
- i gestori dell'assistenza: direttori sanitari a livello di singolo ospedale, ma anche di ASL,
Regione, Stato.
Il supporto elettronico fornisce la possibilità di trasformare i dati in formati diversi per destinarli a
diversi tipi di utenti:
- i fornitori dell'assistenza medica: medici di medicina generale e specialisti, ma anche dentisti,
farmacisti, infermieri, ecc...;
- i fruitori dell'assistenza: pazienti e loro familiari;
- i gestori dell'assistenza: direttori sanitari a livello di singolo ospedale, ma anche di ASL, regione,
nazione.
Una cartella clinica elettronica non è comunque la semplice trasposizione elettronica di quella
tradizionale, ma un sistema che la rende più efficiente, efficace, e potente. [1.8]
Utilizzatori della cartella clinica elettronica
I diversi usi clinici fanno sì che le funzioni contenute, i modelli concettuali e le soluzioni
informatiche siano diversi di ambito in ambito. Gli attuali ambiti di utilizzo sono la medicina di
base, l’assistenza ospedaliera in genere, e la medicina specialistica.
Materiale estratto dal lavoro:
A. Rebeschini, “La cartella clinica elettronica: problematiche di strutturazione e di interoperabilità”,
Tesina per il conseguimento della Laurea Triennale in Ingegneria Biomedica, Dipartimento di
Ingegneria dell’Informazione, Università di Padova, A.A. 2004-05 (versione completa disponibile
presso la Biblioteca)
1
Uso in medicina di base
In medicina di base la cartella clinica elettronica assomiglia più ad una versione digitalizzata di
quella cartacea, ma con opzioni problem-oriented per i dati e alcune funzioni interattive. Il sistema è
in grado di stampare impegnative e prescrizioni, gestendo anche tutte le questioni economicoamministrative, e permette la codifica di diagnosi e risultati secondo i criteri internazionali ICPC o
2
ICD-9 (e seguenti). Poiché i medici di base si riuniscono spesso in gruppi di lavoro e possono aver
bisogno di confrontarsi, la maggior parte dei software in commercio possiede una solida base per lo
scambio di dati. I cittadini ricorrono allo stesso medico per un intervallo di tempo molto esteso,
riportando a lui tutte le informazioni generate dalle strutture sanitarie con cui entrano in contatto. È
per questo motivo che il medico si imbatte in uno spettro molto ampio di problemi clinici. Ed è
sempre per questo che le descrizioni da lui prodotte sono brevi e poco dettagliate, quindi
l’operazione di inserimento dati non richiede mai più di 2-3 minuti. Il successo in questo settore
della cartella clinica elettronica è dovuto principalmente ai seguenti fattori:
1. Le associazioni dei medici di base hanno interpretato un ruolo attivo nella implementazione
del software, fornendo alle case produttrici delle linee guida da seguire. Si sono riservate poi
di valutare le offerte di mercato consigliando agli associati di acquistare solo quelle coerenti
ai canoni forniti. Questa linea d’azione ha dato vita a dei veri e propri standard de facto e ha
permesso di raggiungere dei buoni livelli di efficienza.
2. L’educazione universitaria da qualche tempo a questa parte fornisce una adeguata
preparazione nell’utilizzo di sistemi informativi. Ciò dà ai futuri medici una buona
motivazione per utilizzare i sistemi di cartella clinica elettronica, perché si rendono conto
del possibile miglioramento della qualità del lavoro. Essi sono anche consapevoli che i primi
tempi comporteranno dei maggiori sforzi: in media servono 2 anni per inserire i dati dei
circa 2000 pazienti assegnati al medico, ma ciò rappresenta un investimento che porterà
frutti per tutti gli anni seguenti.
Uso in medicina ospedaliera
In una struttura ospedaliera le possibili sorgenti di informazioni per uno stesso paziente sono
numerosissime, e dovrebbero integrarsi per formare una unica cartella clinica: un insieme di dati
dispersi sulla rete risulterebbe di scarsa utilità. Per consentire tale integrazione occorre strutturare
una “piattaforma” di cartella clinica elettronica che permetta di far comunicare tra di loro i
sottosistemi informativi dei diversi reparti, consentendo a questi di gestire i propri applicativi in
modo indipendente. In pratica, i dati vengono conservati in modo distribuito nei luoghi fisici in cui
sono più utili (dove servono l’ accesso rapido e la possibilità di modifica ai contenuti), ma sono
accessibili da altri poli.
2. STRUTTURAZIONE DEI DATI NELLA CARTELLA CLINICA
ELETTRONICA
Approccio puramente cronologico (“Time-oriented attitude”)
È considerato il più semplice metodo di organizzazione delle informazioni, in cui ogni dato inserito
viene riferito ad almeno un istante temporale esplicito. L’aspetto esteriore che si ottiene nella
maggior parte dei casi è quello una semplice lista cronologica, in cui a fianco di un dato temporale
viene inserito del testo libero o scelto da opzioni predisposte. Ogni evento clinico rilevante viene
illustrato da una sola frase di testo; questa unità elementare rappresenta un campo. Può capitare però
che non si riesca a fornire informazioni esaurienti con singola sola frase; se questo avviene, è
possibile creare un raggruppamento dei campi che riguardano lo stesso evento. Talvolta le note
cronologiche vengono illustrate attraverso grafici, nei quali viene posto su di un asse il tempo, e
sull’asse complementare il dato.
Figura 2.5 illustra alcune forme di organizzazione cronologica delle informazioni disponibili in
Millewin. Assieme al riferimento temporale, nel primo caso sono compresenti testo strutturato e
testo libero, nel secondo informazioni numeriche e testo libero, nel terzo esclusivamente testo
libero. In Figura a) si nota una lista di prescrizioni di terapie farmacologiche: è presente la data, il
nome del farmaco, il numero di confezioni prescritte, la posologia ed altro (l’esenzione ed il tipo a
cui viene associato il prodotto). Vale la pena evidenziare la differente colorazione assegnata ai
farmaci assunti in modo continuativo (verde) e a quelli occasionali (nero). Questa soluzione dà la
possibilità al medico di valutare velocemente la correttezza della terapia. In Figura b) viene
riportato un grafico di valori di pressione arteriosa: in ascissa è stato posto il tempo (data
dell’esame), in ordinata il valore di pressione fornito dallo sfigmomanometro (l’unità di misura è
mmHg). Mediante la barra blu vengono mostrati contemporaneamente massimo e minimo di ogni
misurazione, e si può valutare già ad occhio l’entità del loro scostamento (la differenza di pressione
tra max-min consente di risalire allo stato di salute del cuore). È possibile eventualmente inserire
anche la frequenza cardiaca ed altre note, ad esempio i farmaci assunti. In Figura c) infine viene
proposto il “Diario” che contiene le note sui singoli problemi del paziente. L’adozione del testo
libero permette al medico di inserire qualsiasi tipo di informazione e di entrare più o meno nei
dettagli a seconda del caso in esame.
Uso in medicina specialistica
Nel caso in cui un medico di base non si consideri qualificato per pronunciare diagnosi o prestare la
cura, invita il paziente a recarsi da uno specialista. Quest’ultimo tratta con soggetti diversi di volta
in volta, e nel prendere decisioni entra in relazione con il personale della struttura sanitaria in cui
opera. L’uso di una cartella clinica elettronica risulta una perdita di tempo per il medico specialista,
perché i dati da registrare sono numerosi, eterogenei, e spesso troppo specifici e non previsti dal
software. Talvolta capita che si debba ricorrere alla creazione di testo libero, allungando ancora di
più i tempi di lavoro e complicando il futuro recupero delle informazioni. È molto difficile
realizzare un solo modello di cartella clinica su cui convenga la maggior parte dei medici specialisti.
La soluzione ideale sembra la messa a punto di un modello generico e di base di cartella clinica, e
contemporaneamente di un insieme di cartelle cliniche elettroniche progettate su misura per i
diversi specialisti. Al bisogno, queste ultime dovrebbero poter essere integrate nella cartella di base
(mediante semplici links o trasportando fisicamente i dati), formando un unico elemento. [1.3]
a)
b)
c)
Figura 2.5. Esempi di liste cronologiche tratte da Millewin.
(rispettivamente per: terapie farmacologiche, misure di pressione, diario dei problemi)
3
4
La situazione in cui questo tipo di cartella clinica funziona meglio è quella in cui nel paziente è
presente un solo problema per volta; l’estrazione di informazioni da casi più articolati (presenza di
più problemi contemporanei) non è facilmente realizzabile. Non esistono infatti in questo modello
dei raggruppamenti semantici che aiutino nella interpretazione e comprensione delle relazioni tra i
contenuti.
Una questione spinosa è la scelta delle date da rappresentare. Nel pre-standard europeo ENV
13606-parte 2 si cerca di risolvere questo problema identificando tre diverse categorie di date:
- date relative alla documentazione (creazione documento tramite dettatura o battitura,
importazione del documento nella cartella clinica, firmatura);
- date relative all’evento sanitario (incidente, insorgenza, prelievo, appuntamento,
prestazione cure);
- date relative alla “conoscenza” o “consapevolezza”, cioè quando l’autore della cartella
clinica ha appreso i dati (dal paziente, da lettura referti medici, da osservazione diretta, da
diagnosi fatta in prima persona).
Anche in tutti gli altri approcci organizzativi si conserva l’esplicitazione dei dati in funzione del
tempo, quindi, partendo da qualsiasi metodo illustrato successivamente in questa sede, sarà sempre
possibile risalire ad una lista di tipo cronologico.
Approccio orientato ai problemi (“Problem-oriented attitude”)
La cartella clinica “orientata per problemi” in formato cartaceo venne proposta dal medico
Lawrence Weed nel 1968, mentre era docente all’ University of Vermont. Il suo scopo di partenza
era stimolare i colleghi ad effettuare un processo logico nella raccolta e catalogazione dei dati, per
generare un testo più strutturato e meno narrativo, e delle cartelle più solide e facilmente leggibili.
Questo avrebbe consentito di fare meno sforzi interpretativi e risparmiare del tempo in sede di
consultazione successiva, aspetti essenziali nelle emergenze. Un altro obbiettivo di Weed era il
raggiungimento di una rapidità di compilazione per i primi prototipi di cartella clinica elettronica
che fosse paragonabile a quella della versione cartacea; infatti il maggior tempo richiesto in fase di
inserimento dati era un fattore che a quei tempi ne frenava notevolmente la diffusione.
Egli strutturò la sua cartella in tre settori principali:
Esiste un’altra distinzione tra istanti temporali importanti, ed è legata più da vicino al metodo di
lavoro del medico. È quella tra:
- il momento in cui vengono inseriti i dati;
- il momento in cui il medico ha avuto l’intuizione e ha identificato il problema reale;
- il momento in cui la cura diventa applicabile.
Per la ricostruzione esatta di un evento sanitario e questioni di responsabilità legale tutti questi dati
dovrebbero essere sempre esplicitati nella cartella clinica. Ciò sembra portare a notevoli
complicazioni, e questo effettivamente succede. Una utile semplificazione nasce però dal fatto che
spesso gli istanti temporali sopraccitati o coincidono, o sono così vicini nel tempo da rendere
possibile il loro accorpamento. [2.1, 2.4 e 2.6]
In Tabella 2.1 viene proposto uno stralcio di cartella clinica cronologica per problemi
contemporanei di bronchite acuta, fiato corto, scurezza di feci. Si noti come ad ogni riferimento
temporale vengano associate informazioni riguardanti più problemi.
Time-Oriented Medical Record
21 Feb 1996
- Fiato corto, tosse, febbre. Feci molto scure.
o
- Esame: pressione 150/90, pulsazioni 95/min, Temperatura: 39.3 C.
- Rumori bronchiali, addome rigido.
- Terapia già in atto: 64 mg Aspirina al dì. Probabile bronchite acuta,
possibili complicazioni con de-compensazione cardiaca.
- Emorragia intestinale probabilmente dovuta ad Aspirina.
- ESR 25 mm, Emoglobina 7.8, abbondante sangue occulto nelle feci.
- Radiografia al torace: atelettasìa assente, lievi segni di decompensazione cardiaca.
- Terapia: Amoxicillina in capsule 500 mg due volte al dì, riduzione
Aspirina a 32 mg al dì.
4 Mar 1996
- Tosse assente, fiato leggermente corto, feci normali.
- Esame: lievi rumori bronchiali, pressione 160/95, pulsazioni 82/min.
- Continuazione terapia: Aspirina 32 mg al dì.
- Emoglobina 8.2, sangue occulto nelle feci.
-
-
Informazioni di base (“Background informations”): dati permanenti (data di nascita, sesso,
storia sanitaria familiare, vaccinazioni, ecc…) e dati variabili (stato civile, impiego,
indirizzo, risultato test diagnostico);
Lista dei Problemi (“Problem List”): lista dei problemi medici e sociali sia attivi che
inattivi;
Dati clinici di dettaglio organizzati per problema e nota “SOAP” (“Progress Notes –
SOAP”): in questo settore viene analizzato ogni singolo problema seguendo lo schema
SOAP (SOVP in Italiano):
o aspetti soggettivi (Subjective), cioè osservati dal paziente;
o aspetti oggettivi (Objective), cioè osservazioni del medico e/o risultati di analisi;
o valutazione (Analysis), cioè l’interpretazione del problema da parte del medico;
o pianificazione (Plan), cioè gli obbiettivi e le azioni da intraprendere.
Ad ogni paziente venivano assegnati i problemi medici di competenza (che fossero uno o più di
uno, ciò dipendeva dai casi in esame), e gli appunti venivano presi secondo la struttura SOAP
appena illustrata. Si consentiva così al medico di apprendere in modo semplice un metodo
universalmente applicabile, ed il suo lavoro, oltre a guadagnare in efficienza, diventava utile anche
per gli altri. Negli anni Settanta questo approccio si diffuse ampiamente negli ospedali di tutti gli
Stati Uniti, e l’esperienza diretta ha dimostrato la buona gestibilità delle informazioni, anche se
spesso l’utilizzo nei casi semplici risultava troppo complesso e frustrante. [2.1, 2.4, 2.6, 2.7 e 2.8]
Tabella 2.1
Esempio di cartella clinica ordinata in modo cronologico [2.4]
5
6
In Tabella 2.2 riportiamo un esempio di POMR. Vengono analizzati 3 problemi contemporanei in 2
sedute diverse; le note sono prese secondo la nota SOAP.
Problem-oriented medical Record
Problema 1: Bronchite acuta
21 Feb 1996
S: Fiato corto, tosse, febbre.
O: Pulsazioni 95/min, Temperatura: 39.3 oC.
Rumori bronchiali. ESR 25 mm.
Radiografia al torace: atelettasia assente, lievi segni di
decompensazione cardiaca.
A: Bronchite acuta
P: Amoxicillina capsule. 500 mg due volte al dì.
4 Mar 1996
S: Tosse assente, fiato leggermente corto.
O: Pulsazioni 82/min. Lievi rumori bronchiali.
A: Minimi segni di bronchite
Problema 2: Fiato corto
21 Feb 1996
S: Fiato corto
O: Rumori bronchiali, Pressione 150/90.
Radiografia al torace: atelettasìa assente, lievi segni di decompensazione cardiaca
A: Minori segni di de-compensazione cardiaca.
4 mar 1996
S: Fiato leggermente corto.
O: Pressione 160/95, Pulsazioni 82/min.
A: Decompensazione assente.
Problema 3: Scurezza delle feci
21 Feb 1996
S: Feci scure.
Terapia già in atto: Aspirina 64 mg al dì.
Addome rigido, assenza di sangue all’esame rettale con il guanto,
O:
Emoglobina 7.8.
A: Emorragia intestinale probabilmente dovuta ad Aspirina.
P: Riduzione Aspirina a 32 mg al dì.
4 Mar 1996
S: Feci normali.
O: Sangue occulto nelle feci.
A: Segni di emorragia intestinale assenti.
P: Mantenuta Aspirina a 32 mg al dì.
lembo “SOVP” appaiono in ordine cronologico tutte le note relative al problema, e le lettere
maiuscole accanto richiamano le quattro categorie appena viste.
In figura 2.7 e 2.8 sono illustrate poi due visualizzazioni alternative dalla nota SOVP. La Figura 2.7
è un semplice ingrandimento del riquadro in basso di Figura 2.6: il programma consente di zoomare
ogni finestra attiva, per poter consultare più agevolmente le informazioni contenute. La Figura 2.8
riporta invece il “quadro generale del problema”, che contiene alcune date importanti, consente di
attivare/disattivare i tre tipi di evidenziazione visti in precedenza (problema rilevante/attivo/a lungo
termine), e propone la nota SOVP separata per categorie.
Il problema
selezionato è BPCO.
Appaiono sotto le
relative note.
Valutazioni
Oggettività
Piani di cura
Soggettività
Figura 2.6 - Problem-oriented Medical Record – Schermata da Millewin
Tabella 2.2
Esempio di cartella clinica organizzata per problemi. [2.4]
In Figura 2.6 viene proposta un’altra immagine dell’interfaccia grafica del programma Millewin. In
alto si nota che è stata attivata la visualizzazione della “Lista Problemi”. Essa contiene i problemi
attivi e non, e riporta il corrispondente anno di manifestazione. Il programma mette a disposizione
tre diversi strumenti per evidenziare alcuni aspetti di un problema: la “campanella” accanto ai primi
due problemi indica che il problema è grave, la freccia verso l’alto assieme alla colorazione in
rosso indica che il problema è attivo, ed infine la clessidra che il problema ha uno sviluppo a lungo
termine. Dopo aver selezionato la voce “BPCO” (bronchite cronica ostruttiva), appaiono in basso le
annotazioni relative, suddivise per categoria (“Sogg.”, “Ogg.”, “Valut.”, “Piano”). Attivando il
7
Figura 2.7
Schermata dal programma Millewin – Zoomata della nota SOVP
8
-
Livello 2: fornisce collegamenti tra componenti del primo livello ed esplicita come essi
intervengano nella presa delle decisioni e nel dialogo tra clinici.
Un’altra differenza tra i due modi di strutturare i contenuti è che il metodo problem-oriented varia
da paziente a paziente, in quanto ognuno ha i propri problemi clinici, mentre il metodo sourceoriented è più generale, e propone la stessa struttura per tutti. [2.4]
Come già fatto in precedenza riportiamo nella pagina seguente una tabella di esempio per il modello
appena illustrato (Tabella 2.3). [2.4]
Figura 2.8
Schermata dal programma Millewin – Quadro generale del problema
L’approccio orientato per problemi si può dire sia quello che ha ricevuto il più largo consenso
dall’universo sanitario, ed è stato di volta in volta adeguato ad esigenze particolari. È nata però una
grande quantità di standard diversi e ciò ha incrementalmente peggiorato la comunicabilità. Se da
un lato, quindi, ha aiutato a migliorare l’assistenza fornita al paziente, dall’altro, l’assenza di un
ente normatore di supervisione, ha complicato la “scambiabilità” delle informazioni. [2.1]
Source-oriented medical Record
Visita
21 Feb 1996
Fiato corto, tosse, febbre. Feci molto scure.
Esame: pressione 150/90, pulsazioni 95/min, Temperatura: 39.3 oC.
Rumori bronchiali, addome rigido.
Terapia già in atto: 64 mg Aspirina al dì. Probabile bronchite acuta,
possibili complicazioni con de-compensazione cardiaca.
Emorragia intestinale probabilmente dovuta ad Aspirina.
Terapia: Amoxicillina in capsule 500 mg due volte al dì, riduzione Aspirina
a 32 mg al dì.
4 Mar 1996
Tosse assente, fiato leggermente corto, feci normali.
Esame: lievi rumori bronchiali, pressione 160/95, pulsazioni 82/min.
Continuazione terapia: Aspirina 32 mg al dì.
Test di Laboratorio
21 Feb 1996
ESR 25 mm, Emoglobina 7.8, abbondante sangue occulto nelle feci.
4 Mar 1996
Emoglobina 8.2, sangue occulto nelle feci.
Radiografia
21 Feb 1996
Radiografia al torace: atelettasìa assente, lievi segni di decompensazione cardiaca.
Tabella 2.3
Source-Oriented Medical Record – Esempio [2.4]
Approccio orientato alle sorgenti delle informazioni (“Source-oriented attitude”)
Standard terminologici
Molti sistemi cartella clinica elettronica di oggi utilizzano il metodo source-oriented, che
letteralmente significa “orientato alle sorgenti”. Queste ultime sono le vere e proprie sorgenti delle
informazioni cioè la visita medica, gli esami radiografici, test di laboratorio, ecc… I contenuti
vengono catalogati in base al metodo di acquisizione ed al formato delle informazioni prodotte
(immagini, valori numerici, concentrazioni, segnali ECG, EMG, EEG, ecc…). Nella maggior parte
dei casi misure successive sono accostate, in modo che l’utente possa velocemente ricostruire la
loro evoluzione nel tempo e osservare decorso di una eventuale malattia. Questo modello integra in
sé anche la nota SOAP (SOVP) del modello problem-oriented, che viene utilizzata per organizzare
gli appunti presi durante o a posteriori i contatti medico-paziente.
L’utilizzo del testo narrativo libero per registrare informazioni cliniche allunga i tempi di lavoro e
complica le ricerche successive. Questo non è l’unico problema che ha questa forma di inserimento
dati: mentre il medico scrive usa anche dei sinonimi, e ciò crea ancora più confusione. Servono dei
criteri oggettivi per spingere all’utilizzo di un insieme finito di termini da utilizzare. Attualmente
esistono più di 150 Classificazioni Internazionali (anche dette “Codifiche”, perché forniscono dei
codici), e la più utilizzata è l’ International Classification of Diseases (ICD).
La visione source-oriented appena esaminata è in palese contrasto con la visione problem-oriented
vista in precedenza, e si può dire che siano addirittura “perpendicolari” tra loro. Il medico però deve
sempre considerarle entrambe tenendo conto di un fatto: la visione orientata alle sorgenti è
fortemente indipendente dai contenuti, mentre quella orientata ai problemi non lo è; quest’ultima si
basa solo sulla relazione tra i contenuti semantici dei dati.
Queste considerazioni prendono vita dall’individuazione nei contenuti di due livelli:
- Livello 1: comprende estratti delle osservazioni, pensieri e azioni del medico.
La prima edizione dell’ International Classification of Diseases è nata nel 1900 ad opera della
Organizzazione Mondiale della Sanità (WHO), che ha curato anche tutte le successive revisioni
avvenute ad intervalli di circa 10 anni. ICD consiste in una classificazione a tre cifre di base, che
costituisce l’insieme minimo di codici richiesto per comunicare la statistiche alla WHO. La
classificazione ICD di base contiene solo codici per le diagnosi, ma dalla versione 9 in poi è stato
introdotto un set di espansioni che comprende anche altre famiglie di termini medici, come ad
esempio la lettera “V” che indica i motivi per cui avviene l’incontro medico-paziente, e la lettera
“E” che codifica le cause di morte esterne. Anche se esistono due versioni molto recenti (ICD-10 e
9
10
Classificazione ICD
ICD-10-CM), la maggior parte dei sistemi informativi sanitari usa ancora ICD-9 e ICD-9-CM. Esse
sono una l’evoluzione dell’altra: la sigla “CM” significa infatti “Clinical Modifications”, e il
termine "clinical" è utilizzato per sottolineare la natura delle migliorie introdotte. Rispetto a ICD-9,
che è fortemente orientata alla classificazione delle cause di mortalità, ICD-9-CM punta sui dati di
morbosità. Le modifiche apportate hanno consentito una classificazione più precisa ed analitica
delle formulazioni diagnostiche, attraverso l'introduzione di un quinto carattere, e l'introduzione
della classificazione per le procedure mediche.
La struttura della classificazione ICD è determinata da due assi principali: l'eziologia (cause della
malattia) e la sede anatomica. Il criterio eziologico è quello che dà l’impronta più profonda e
determina i capitoli "speciali" (malattie infettive; malattie costituzionali e generali; malattie dello
sviluppo; traumi); il criterio anatomico determina invece i capitoli cosiddetti "locali", anche detti
paragrafi, ovvero riferiti ad una specifica sede anatomica. [2.14]
Il sistema ICD-9-CM contiene due diverse classificazioni, una per le malattie ed una per gli
interventi chirurgici e le procedure.
Elenco sistematico delle malattie: riporta, in ordine progressivo, i codici delle malattie, dei
traumatismi, dei sintomi e di altre cause di ricorso alle prestazioni sanitarie, ed è inclusa una loro
descrizione. È suddiviso in 17 capitoli: 10 sono dedicati ad organi o apparati anatomici, 7
descrivono condizioni che interessano l'intero organismo. Questa classificazione contiene
unicamente codici numerici, compresi fra 001 e 999.9. Nella Tabella 2.5 a pagina seguente è
riportato l'elenco dei capitoli (che risulta uguale sia per l'ICD-9 che per l'ICD-9-CM). Ciascuno dei
17 capitoli è suddiviso in varie sezioni:
− Blocco: insieme di condizioni tra loro correlate (es.: malattie infettive intestinali, 001-009.
Vedi Figura 2.19 e 2.20);
− Categoria: codici a tre caratteri, alcuni dei quali specifici e non ulteriormente suddivisibili,
mentre altri sono ulteriormente suddivisi, con l'aggiunta di un quarto carattere dopo il punto
decimale (es.: Colera, 001; Febbre tifoide e paratifoide, 002. Vedi Figura 2.19 e 2.20);
– Sotto-categoria: codici a quattro caratteri; il quarto carattere fornisce ulteriore specificità
(es.: Setticemia da Salmonella, 003.1);
− Sotto-classificazioni: codici a cinque caratteri (es.: Meningite da Salmonella, 003.21. Vedi
Figura 2.19 e 2.20).
001 – 139 Æ Malattie infettive e parassitarie
001 – 009 Æ Malattie infettive intestinali
001
Colera
001.0 Colera da Vibrio cholerae
001.1 Colera da Vibrio cholerae el tor
001.9 Colera non specificato
002
Febbre tifoide e paratifoide
002.0 Febbre tifoide
Tifoide (febbre)(infezione) [qualsiasi sede]
002.1 Paratifo A
002.2 Paratifo B
002.3 Paratifo C
002.9 Paratifo non specificato
Figura 2.19
Stralcio della Classificazione ICD-9-CM [2.11]
003
Altre infezioni da Salmonella
003.0 Gastroenterite da Salmonella
Salmonellosi
003.1 Setticemia da Salmonella
003.2 Infezioni localizzate da Salmonella
003.20
Infezioni localizzate da Salmonella, non specificate
003.21
Meningite da Salmonella
003.22
Polmonite da Salmonella
003.23
Artrite da Salmonella
003.24
Osteomielite da Salmonella
003.29
Altre infezioni localizzate da Salmonella
003.8 Altre infezioni specifiche da Salmonella
003.9 Infezioni da Salmonella non specificate
Figura 2.20
Stralcio della Classificazione ICD-9-CM [2.11]
.Elenco sistematico degli interventi e procedure: consente l'agevole ricerca di una singola voce, e si
integra a tutti gli effetti con l’indice alfabetico delle malattie. [2.14]
In Figura 2.21 e seguenti viene riportato l’esempio dell’ inserimento di un problema fatto in modo
strutturato con il programma Millewin, utilizzando la codifica ICD-9. Un paziente si reca dal
medico, che nota la presenza di un nuovo problema. Dopo aver cliccato sulla “manina” rossa sulla
barra dei pulsanti (Figura 2.21 a)), appare la finestra “Nuovo Problema” (Figura 2.21 b)) che guida
nella scelta della terminologia specifica per il problema. Il medico, dopo aver cliccato sui tre puntini
di sospensione nella casella “Definizione”, accede all’elenco sistematico ordinato per codici (Figura
2.22), suddiviso al suo interno nei vari livelli: Capitoli, Blocchi, Categorie, Sotto-Categorie,
ecc…Si passa da un livello all’altro cliccando sulle voci corrispondenti (Figure 2.23, 2.24).
Supponendo per esempio che il problema del paziente sia “Enterite Batterica”, il medico lo
seleziona e conferma. Sulla “Lista Problemi” ecco comparso il nuovo problema (Figura 2.25).
Tabella 2.5 Classificazione ICD-9-CM – Suddivisione in Capitoli [2.14]
11
12
Nuovo Problema
a)
Tabella dei
Problemi suddivisa
per capitoli
Nuovo Problema
Definizione del
Problema
Pulsante di
accesso alla
Tabella ICD-9
Figura 2.22
Tabella dei problemi basata sulla Classificazione ICD-9 – Capitoli.
b)
Figura 2.21
Inserimento di un nuovo problema in Millewin
Tabella dei
Problemi suddivisa
per blocchi
Figura 2.23
Tabella dei problemi basata sulla Classificazione ICD-9 – Blocchi.
13
14
Tabella dei
Problemi:
categorie e
problemi semplici
categoria
problemi semplici
Figura 2.24
Tabella dei problemi basata sulla Classificazione ICD-9 – Categorie e problemi semplici.
attraverso l’infrastruttura di rete. Le aziende sanitarie sono infatti poste al centro di una rete
complessa creata da sistemi informativi eterogenei che dovrebbero essere grado di dialogare in una
lingua comune; tale lingua può essere vista come un set di standard condivisi, che permettano a
programmi differenti di scambiarsi informazioni.
L’utilizzo contemporaneo degli standard e della rete crea un ambiente propizio per l’attuarsi della
interoperabilità. Due applicazioni sono definite interoperabili quando possono scambiarsi dati e
servizi in modo efficace e consistente, permettendo la comunicazione tra piattaforme hardware e
software eterogenee. I vantaggi che ne derivano sono numerosi, e comprendono la possibilità di
salvaguardare gli investimenti fatti, adeguandosi all’evoluzione degli ambienti operativi, e quella di
allargare il numero di applicazioni con cui interagire.
Nel contesto sanitario che stiamo indagando, l’interoperabilità deve permettere di:
− garantire continuità assistenziale e risalire alle responsabilità delle azioni per la raggiunta
maggiore consapevolezza delle attività svolte e osservazioni prodotte da diversi operatori;
− ristabilire centralità del cittadino consentendogli di avere accesso diretto ai propri dati e a quelli
sulle strutture;
− porre il processo di cura al centro dei sistemi informativi, nell’ottica di una concreta applicazione
dei principi della Medicina Basata sulle Evidenze (“Evidence Based Medicine”) e attraverso
l’adozione di linee guida precise, rigorose e documentate;
− controllare le spese e aumentare la qualità dell’assistenza tarando adeguatamente il rapporto
costi/benefici, permettendo un migliore uso delle risorse e risparmi diretti; ciò è reso possibile dalla
tempestività degli scambi informativi e dal supporto decisionale che riduce insicurezze e errori.
Standard per la cartella clinica elettronica
La comunicazione tra i calcolatori delle strutture sanitarie serve a realizzare due tipi di
cooperazione:
1) clinica: accesso, nel momento del bisogno, alle informazioni cliniche e diagnostiche,
memorizzate in applicazioni anche remote e/o gestite da altri operatori sanitari;
2) gestionale: due applicazioni diverse interagiscono per lo scambio di richieste e risultati
(prescrizioni di farmaci e di analisi, lettera di dimissione, prenotazione di prestazioni tramite centri
unificati di prenotazione, calcolo ticket, etc.). [3.3]
Figura 2.25
La procedura è terminata: è stato inserito un nuovo problema.
3. INTEROPERABILITÀ E STANDARD
Per offrire un livello di cura migliore le organizzazioni sanitarie devono puntare ad una
cooperazione efficiente accelerando i flussi delle informazioni ed ottimizzando la comunicazione
reciproca. Devono insomma contribuire a costruire un ambiente privo di vincoli e confini
assicurando ai pazienti, agli operatori, e agli enti, la possibilità di consultare e trasmettere dati,
sempre nel rispetto della privacy. Questa integrazione dovrebbe essere realizzata preferibilmente
15
In Europa, l’introduzione dei sistemi informativi nei Sistemi Sanitari Nazionali ha sofferto della
mancanza di un approccio comune. Si veda ad esempio la messa in opera in Italia dei CUP (Centri
unificati di prenotazione) a livello locale, avvenuta senza un coordinamento e una standardizzazione
a livello nazionale basata su requisiti e funzionalità comuni. L’attenzione è stata sempre posta sulle
funzioni amministrative, mentre le funzioni cliniche legate più direttamente alla cura del paziente
sono rimaste in secondo piano. Un sistema sanitario pubblico come quello italiano ha inoltre
l’esigenza di ottimizzare l’investimento che sta compiendo nell’informatizzazione delle proprie
strutture. Occorrerebbe quindi ottenere l’indipendenza da singoli fornitori creando gruppi di lavoro
interni alla Sanità, far crescere e aggiornare gradualmente e continuamente l’hardware ed il
software e permettere la trasportabilità del software in contesti diversi (non solo dal punto di vista
hardware).
Negli ultimi anni, a livello internazionale, vengono impiegate molte risorse per mettere a punto una
adeguata normazione nell’informatica sanitaria, e vengono coinvolte le grandi organizzazioni
pubbliche e private, le industrie produttrici, le aziende di software e gli utenti finali. Gli anni
16
Novanta hanno visto la diffusione di gruppi di standardizzazione nell’ambito della sanità anche a
livello europeo: il CEN (Comité Européen de Normalisation) ha istituito una commissione tecnica
per l’informatica sanitaria (denominata CEN/TC 251 [3.5]) composta da 18 paesi comunitari e da un
crescente numero di stati dell’Europa dell’Est. L’ obbiettivo del Comitato CEN/TC 251 consiste nel
coordinamento, sviluppo e testing di standard specifici, attività che richiedono la collaborazione
continuativa di personale medico e tecnico. Per quanto riguarda le cartelle cliniche elettroniche
l’esigenza emersa è quella di poter ospitare informazioni multimediali (testo, grafici, immagini,
voce, sequenze video), e consentire il loro scambio tra diversi operatori sanitari (medici di base,
ospedali, specialisti, laboratori, servizi sanitari pubblici). Tale operazione deve avvenire in modo
strutturato e standardizzato (come visto nel Capitolo 2 di questo lavoro), garantendo agli utenti
finali un buon livello di sicurezza e confidenzialità. Per quanto riguarda l’operazione di
standardizzazione, in sanità possono essere applicati standard già utilizzati in altre discipline o
basati su piattaforme di comunicazione pre-esistenti. Solitamente essi vengono semplicemente
“adattati”, uniformando al linguaggio clinico i protocolli di comunicazione, i formati e le codifiche
dei messaggi. Gli standard di comunicazione più utilizzati in Informatica Sanitaria al giorno d’oggi
sono DICOM, CORBA e HL7 [3.1, 3.2 e 3.3]
Lo standard HL7 (Health Level Seven)
Istituzione di HL7
Health Level 7 (HL7) è una organizzazione internazionale di crescente successo nata nel 1987 negli
USA con lo scopo di realizzare standard nel settore dell’informatica sanitaria. Dal 1994 è una
organizzazione per lo sviluppo di standard accreditata presso l'ANSI (ANSI Accredited Standards
Developing Organisation), partecipa all'HISB (ANSIS's Health Information Standards Board), e
copre il 90% dei maggiori fornitori di sistemi informativi per la sanità. Negli ultimi anni sono state
attivate circa 30 sezioni nazionali in molti paesi del mondo. Particolarmente attive sono le sezioni in
Australia, Canada, Regno Unito, Germania, Olanda. Informazioni su attività, struttura organizzativa
e materiali prodotti sono disponibili in www.hl7.org. [3.8]. Il 20 marzo 2003 è stata costituita la
sezione italiana di HL7, che intende adattare lo standard alle necessità nazionali, seguendo le regole
generali già esistenti e godendo della collaborazione dell’UNI (Ente Italiano di Unificazione).
La dizione “Level 7” fa riferimento al livello più alto del modello OSI (Open System
Interconnection). Questo significa che HL7 concorre alla definizione concettuale di una interfaccia
di tipo paritario (applicazione-applicazione) posta al settimo livello del modello OSI. In altre parole
questo modello fa riferimento ai dati scambiati, alla tempistica degli scambi, e alla comunicazione
di errori fra le applicazioni, ma non fa riferimento ad aspetti implementativi che apparterebbero a
diversi livelli del modello. La comunicazione tra applicazioni sanitarie diverse viene permessa da
una particolare codifica delle informazioni.
Allo stato attuale lo standard HL7 riguarda le interfacce necessarie allo scambio di dati fra sistemi
eterogenei rispetto ai seguenti temi:
−
−
−
−
−
−
−
ammissione/dimissione/trasferimento dei pazienti;
interrogazioni della banca dati sanitaria;
pianificazione delle attività sanitarie e dell'impiego delle risorse;
effettuazione di ordini;
comunicazione di dati sanitari;
gestione economica del ricovero;
aggiornamento dei master file;
17
− gestione dei referti;
− assistenza al paziente e richiesta di consulenze. [3.1, 3.2, 3.10 e 3.11]
Basi di HL7
Lo standard HL7 presuppone che il sistema di comunicazione disponga delle seguenti
caratteristiche:
− capacità di trasmettere senza errori;
− che operi la conversione di caratteri nel caso i due sistemi connessi usino un differente set di
caratteri;
− che non esistano limiti alla lunghezza dei messaggi trasmessi.
Non esistono altre assunzioni fatte sul sistema di comunicazione. Lo standard prende le mosse, dal
punto di vista concettuale, dalla assunzione che esistano eventi nel mondo reale che determinano la
necessità di una gestione di dati all'interno del sistema informativo (allo scopo di mantenere
allineato il contenuto informativo del sistema con la realtà modellata). Tali eventi del mondo reale
vengono definiti eventi scatenanti (“trigger event”). Lo standard HL7 detta quali messaggi
(“message”) debbono essere scambiati in seguito al verificarsi delle condizioni necessarie, e
prevede sostanzialmente due grandi tipi di interazioni fra entità in comunicazione: il semplice
aggiornamento dei dati non sollecitato (il sistema inviante invia un aggiornamento di dati al
sistema ricevente), e l'interrogazione (query), grazie alla quale un sistema può interrogare una
controparte che fornisce la risposta o una condizione di errore. Ad ogni messaggio spedito
corrisponde una risposta, detta “ACK” (da “acknowledgment”), tramite la quale il destinatario
notifica al mittente l’avvenuta ricezione. Messaggi e notifiche ACK utilizzano la codifica ASCII
(American Standard Code for Information Interchange), lo standard usato per codificare i caratteri
della tastiera.
Un esempio di evento scatenante nell’ambito sanitario può essere la prima ammissione ospedaliera
di un paziente: ne consegue registrazione dei dati anagrafici e avvio delle pratiche di cura. Tutte le
informazioni prodotte a seguito dell’evento scatenante vanno comunicate al Sistema Informativo
centrale. In Figura 3.1 viene illustrato il funzionamento di base della comunicazione tra due sistemi
A e B collegati da una rete che utilizza lo standard HL7. L’evento scatenante determina che il
sistema A debba spedire al sistema B un messaggio per comunicare delle informazioni. Il sistema B
poi risponde ritornando un messaggio “ACK” che conferma l’avvenuta ricezione. Successivamente
può accadere che il sistema B debba spedire anch’esso dei messaggi che saranno seguiti da risposte
di tipo “ACK” emesse questa volta dal sistema A. [3.10 e 3.11]
Trigger
event
spedizione
messaggio
HL7
ricezione
HL7-ACK
sistema A
spedizione
messaggio
HL7
RETE
18
ricezione
HL7-ACK
sistema B
Figura 3.1
Principio di funzionamento di rete con standard HL7[3.10]
I messaggi (“message”) rappresentano le unità elementari di dati scambiate tra sistemi interconnessi
secondo lo standard. Ad ogni messaggio è associato un tipo (“type”) che ne definisce le finalità (il
tipo è una sequenza di 3 caratteri). Tipo di appartenenza ed evento scatenante concorrono alla
identificazione del messaggio: un messaggio che trasmette informazioni sull’ammissione
ospedaliera viene associato ad esempio al tipo “ADT” (Admission, Transfer, Discharge), e gli viene
assegnato come codice dell’evento scatenante la sequenza alfanumerica “A01”.
Un messaggio è costituito da un gruppo di segmenti (“segments”) ordinati secondo un criterio
preciso. Un “segment” a sua volta è il raggruppamento di più campi di dati (“data fields”). (vedi
Figura 3.2 e 3.3). Per i segmenti e per i campi il riempimento non è obbligatorio, e la loro
separazione avviene mediante caratteri speciali. Ad ogni segmento è associato un nome
identificativo, rappresentato da un codice univoco di 3 caratteri chiamato "segment ID”. Esso
specifica la natura delle informazioni contenute: un messaggio di tipo ADT potrebbe contenere per
esempio i seguenti segmenti: Message Header (MSH, detto anche “testata”), Event Type (EVN),
Patient Identification (PID), ecc… Sono i campi che contengono l’informazione vera e propria,
detta anche “contenuto semantico”, e ognuno essi ha un tipo di dato associato, come indicato in
Tabella 3.1. Al bisogno, i campi vengono suddivisi in più componenti (vedi Figura 3.2); per
esempio nel caso del campo “Nome e Cognome” vengono separati “Nome” e “Cognome”. Questi
ultimi sono di lunghezza variabile, non impongono obbligo di riempimento, possono venire ripetuti
più volte, e sono distinti tra di loro da appositi separatori.[3.10 e 3.11]
La Figura 3.2 riassume il rapporto gerarchico tra messaggi, segmenti, campi e componenti, mentre
Figura 3.3 riporta un esempio di messaggio ADT (Admission, Transfer, Discharge) nel quale
vengono specificati alcuni nomi identificativi dei segmenti (segment ID). [3.10]
segmento
campo
campo
…
segmento
segmento
campo
compone
compone
…
Figura 3.2 Organizzazione gerarchica degli oggetti in HL7. [3.10]
messaggio ADT
Intestazione
MSH
tipo di evento
EVN
PID
19
dati identificativi
del paziente
ST
TX
FT
NM
DT
TM
TS
PL
Stringa
Testo
Testo formattato
Numero
Data
Ora
Ora (“Time Stamp”)
Allocazione
…
XPN
XAD
XTN
ID
IS
CM
CN
CQ
Nome del Paziente
Indirizzo del Paziente
N° di telefono del Paziente
Valore codificato da tabella HL7
Valore codificato dall’utente
Composito
ID e Nome
Quantità ed Unità
Tabella 3.1
Tipi di dato contenuti nei campi. [3.10]
Come abbiamo detto, la separazione tra segmenti, campi e componenti avviene grazie a dei caratteri
speciali, riportati nella seguente Tabella. L’utilizzo dei separatori è stato proposto dalla versione 2
in poi, ma è compatibile ed incluso in tutte le successive pubblicazioni.
Return (INVIO)
|
^
~
\
&
messaggio
segmento
Figura 3.2
Esempio della struttura di un messaggio HL7. [3.10]
Separazione tra Segmenti
Separazione tra Campi
Separazione tra Componenti
Separazione tra Ripetizioni
Termine
Separazione tra Subcomponenti
Tabella 3.2
Caratteri speciali per la separazione. [3.10]
Riportiamo infine alcune doverose osservazioni sull’esempio di messaggio HL7 proposto in Figura
3.3.
In grassetto, sulla sinistra, sono specificati i “Segment ID”: MSH, EVN, PID, PV1.
Il carattere “|” separa i campi (ci sono parecchi campi vuoti evidenziati dalla presenza di separatori
consecutivi), mentre il carattere “^” viene utilizzato per separare i componenti (in figura vedi
cognome e nome: WHITE^CHARLES).
L’evento scatenante per questo messaggio è espresso dal codice “ADT^A04”, che corrisponde a
“Patient Registration”, cioè la registrazione dei dati di un nuovo paziente all’interno del Sistema
Informativo.
Tra gli altri dati si può infine notare la data di nascita (19980704), il sesso del paziente (M), il
domicilio (7616 STANFORD AVE^^ST. LOUIS^MO^63130), ed il medico di riferimento
(NELL^FREDERICK). [3.12]
20
MSH|^~\&|MY_ADT|XYZ_ADMITTING|MY_IS|XYZ_HOSPITAL|||ADT^A04|101102|
P|2.3.1||||||||
EVN||200004211000||||200004210950
PID|||583020^^^ADT1||WHITE^CHARLES||19980704|M||AI|7616 STANFORD
AVE^^ST. LOUIS^MO^63130|||||||20981701||||||||||||
PV1||E||||||5101^NELL^FREDERICK^P^^DR|||||||||||V1002^^^ADT1||||||
|||||||||||||||||||200004210950||||||||
Figura 3.3
Esempio di HL7 Message [3.12]
RIFERIMENTI CAPITOLO 1
[1.1] “La cartella clinica” – Marco Perelli Ercolini, estratto della relazione tenuta presso l’Azienda Ospedaliera Fatebenefratelli
Oftalmico di Milano il giorno 7 novembre 2001 al Convegno “La cartella clinica:una illustre sconosciuta”.
[www.snamiospedalieri.org]
[1.2] “La cartella clinica elettronica (Electronic Patient Record)” – Angelo Rossi Mori e Riccardo Maceratini.
[www.softwaremedico.it/documenti/CartellaClinicaElettronica.pdf]
[1.3] “Handbook of Medical Informatics” – J.H. van Bemmel (Erasmus University, Rotterdam), M.A. Musen (Stanford University,
Stanford).
[www.mieur.nl/mihandbook/r_3_3/handbook/home.htm]
[1.4] “Minimum Basic Data Set (MBDS), Unintentional Injuries” – Johan Lund, Yvette Holder, Richard J. Smith, M.S.
[www.cdc.gov/nchs/data/ice/ice95v1/c34.pdf]
[1.5] “Dalla cartella clinica elettronica al fascicolo sanitario personale” – Angelo Rossi Mori e Fabrizio Consorti – PROREC Italia.
[www.sanita.forumpa.it/documenti/0/0/0/8/cartella%20clinica%20elettronica13a.doc]
[1.6] “Sharing clinical Information. Principles and task-oriented solutions” – Angelo Rossi Mori, Fabrizio Consorti e Fabrizio L.
Ricci.
[www.prorec.it/documenti/EPR_EHR/EuroRec01-30z.doc]
[1.7] “Health Informatics – Requirements for an Electronic Health Record Architecture” – Documento ISO/TS 18308, Segretariato
ANSI.
[www.centc251.org]
[1.8] “Advantages of computer-based medical records” –1999, Dean F. Sittig –
[www.informatics-review.com/thoughts/advantages.html]
RIFERIMENTI CAPITOLO 2
[2.1] “Dalla cartella clinica elettronica al fascicolo sanitario personale” – Angelo Rossi Mori e Fabrizio Consorti – PROREC Italia.
[www.sanita.forumpa.it/documenti/0/0/0/8/cartella%20clinica%20elettronica13a.doc]
[2.2] “Health Informatics – Requirements for an Electronic Health Record Architecture” – Documento ISO/TS 18308, Segretariato
ANSI.
[www.centc251.org]
[2.3] “Public standards and patients' control: how to keep electronic medical records accessible but private” – Kenneth D Mandl,
Peter Szolovits, Isaac S Kohane
[bmj.bmjjournals.com/cgi/content/full/322/7281/283?view=full&pmid=11157533]
[2.4] “Handbook of Medical Informatics” – J.H. van Bemmel (Erasmus University, Rotterdam), M.A. Musen (Stanford University,
Stanford).
[www.mieur.nl/mihandbook/r_3_3/handbook/home.htm]
[2.5] “Interoperabilità dei Sistemi Sanitari-Clinici Complessi: un caso reale” – Tesi di Specializzazione in Telematica e Integrazione
dei Servizi nella Sanità – Giovanni Borile – Università degli Studi di Trieste.
[www.tbs.ts.it/SSIC/tesi/tesi_Borile.pdf]
[2.6] “Sharing clinical Information. Principles and task-oriented solutions” – Angelo Rossi Mori, Fabrizio Consorti e Fabrizio L.
Ricci.
[www.prorec.it/documenti/EPR_EHR/EuroRec01-30z.doc]
[2.7] “Briefing Paper – Problem Oriented Medical Record (POMR) and SOAP” – NHS Information Authority.
[www.prorec.it/documenti/EPR_EHR/NHS-Update-POMR-SOAP.doc]
[2.8] “Problem Focused Knowledge Navigation: Implementing the Problem Focused Medical Record and the O-HEAP Note” – Kim
C. Meyers, Harry J. Miller, Frank Naeymi-Rad – Department of Medical Informatics, Evanston Hospital, Evanston, Illinois
Intelligent Medical Objects, Inc., Northbrook, Illinois.
[www.amia.org/pubs/symposia/D004997.PDF]
[2.9] “Features of the Computer-based Patient Record” – Pan American Health Organization
[www.virtual.epm.br/material/healthcare/B0104.pdf]
[2.10] “Interoperabilità dei Sistemi Sanitari-Clinici Complessi: un modello di riferimento” – Tesi di Specializzazione in Telematica e
Integrazione dei Servizi nella Sanità – Bruno Antony Sandini – Università degli Studi di Trieste.
[www.tbs.ts.it/SSIC/tesi/tesi_Sandini.pdf]
[2.11] Classificazione ICD9-CM
[www.softwaremedico.it/documenti/ICD%209%20CM%201997.zip]
[2.12] Glossario sulla Scheda di Dimissione Ospedaliera reso disponibile dal Ministero della Salute – Sezione Programmazione
Sanitaria e Qualità.
[www.ministerosalute.it/programmazione/sdo/sezApprofondimenti.jsp?label=glo]
[2.13] “Ricerca Semantica” – Alessandro Mirri
[www.freeonline.org/art/a-286/ricerca-semantica.htm]
[2.14] “La nuova classificazione ICD9CM” [http://www.arsan.campania.it/sitonew/arsanweb.NSF/0/c3570dfce096649ac1256c86005255aa/$FILE/PRESENTAZIONE%20ICD9
CM%201997.PDF]
21
22
[2.15] “History of the development of the ICD” – WHO
[www.who.int/entity/classifications/ icd/en/HistoryOfICD.pdf]
È disponibile una versione on-line della classificazione ICD-10 (versione 2003) sul sito [http://www3.who.int/icd/vol1htm2003/fricd.htm]
[2.16] “International Classification of Diseases, Ninth Revision (ICD-9)”
[www.cdc.gov/nchs/Default.htm]
[2.17] “ICPC-2 PLUS : Origins and Current uses” – Family Medicine Research Centre (FMRC)
[www.fmrc.org.au/icpc2plus/origins.htm]
[2.18] “ICPC Structure” – Wonca International Classification Committe – WICC
[www.globalfamilydoctor.com/wicc/edu.html]
RIFERIMENTI CAPITOLO 3
[3.1] “Interoperabilità dei Sistemi Sanitari-Clinici Complessi: un caso reale” – Tesi di Specializzazione in Telematica e Integrazione
dei Servizi nella Sanità – Giovanni Borile – Università degli Studi di Trieste.
[www.tbs.ts.it/SSIC/tesi/tesi_Borile.pdf]
[3.2] “Interoperabilità dei Sistemi Sanitari-Clinici Complessi: un modello di riferimento” – Tesi di Specializzazione in Telematica e
Integrazione dei Servizi nella Sanità – Bruno Antony Sandini – Università degli Studi di Trieste.
[www.tbs.ts.it/SSIC/tesi/tesi_Sandini.pdf]
[3.3] “Standards per l'informatica sanitaria” - Angelo Rossi Mori
[www.softwaremedico.it/documenti/StandardsInformaticaSanitaria.pdf]
[3.4] ISO
[www.iso.org]
[3.5] CEN – Comité Européen de Normalisation
[www.centc251.org]
[3.6] DICOM Homepage
[medical.nema.org]
[3.7] “Introduzione a CORBA” – Stefano Russo, Carlo Savy, Domenico Cotroneo, Antonio Sergio – McGraw-Hill
[3.8] Health Level Seven – ANSI-HL7
[www.hl7.org]
[3.9] HL7 Italia
[www.forumpa.it/forumpa2003/sanita/cdrom/cnr/HL7-Italia.htm]
[3.10] NHS IT Standards Handbook - Part 2 - Version 0.3, CHAPTER 225 – “HL7”
[www.forumpa.it/forumpa2003/sanita/cdrom/cnr/documenti/225chap.pdf]
[3.11] Tech Zone – Forum di Informatica Sanitaria – USL di Modena
[www.ausl.mo.it/tech_zone/forum/index.html]
[3.12] “Handbook of Medical Informatics” – J.H. van Bemmel (Erasmus University, Rotterdam), M.A. Musen (Stanford University,
Stanford).
[www.mieur.nl/mihandbook/r_3_3/handbook/home.htm]
23
