1

Insegnamento di Informatica Sanitaria Laurea Specialistica in Bioingegneria

A.A. 2005-2006

ALCUNE NOTE SULLA CARTELLA CLINICA ELETTRONICA

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)

2

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. 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 economico-amministrative, e permette la codifica di diagnosi e risultati secondo i criteri internazionali ICPC o

3

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. 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]

4

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.

a) b)

c)

Figura 2.5. Esempi di liste cronologiche tratte da Millewin. (rispettivamente per: terapie farmacologiche, misure di pressione, diario dei problemi)

5

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).

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.

- 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. - ESR 25 mm, Emoglobina 7.8, abbondante sangue occulto nelle feci. - Radiografia al torace: atelettasìa assente, lievi segni di de- compensazione 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.

Tabella 2.1

Esempio di cartella clinica ordinata in modo cronologico [2.4]

6

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:

- 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]

7

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 de-compensazione 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ì.

O: Addome rigido, assenza di sangue all’esame rettale con il guanto, 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ì.

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

8

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.

Figura 2.7 Schermata dal programma Millewin – Zoomata della nota SOVP

Valutazioni

Oggettività

Soggettività

Piani di cura

Il problema selezionato è BPCO. Appaiono sotto le relative note.

Figura 2.6 - Problem-oriented Medical Record – Schermata da Millewin

9

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] Approccio orientato alle sorgenti delle informazioni (“Source-oriented attitude”) 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. 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.

10

- 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 source-oriented è 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] 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 de-

compensazione cardiaca.

Tabella 2.3 Source-Oriented Medical Record – Esempio [2.4]

Standard terminologici 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).

Classificazione ICD

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

11

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).

Tabella 2.5 Classificazione ICD-9-CM – Suddivisione in Capitoli [2.14]

12

Figura 2.19 Stralcio della Classificazione ICD-9-CM [2.11]

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).

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

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

13

a)

b)

Figura 2.21 Inserimento di un nuovo problema in Millewin

Definizione del Problema

Pulsante di accesso alla Tabella ICD-9

Nuovo Problema

Nuovo Problema

14

Figura 2.22 Tabella dei problemi basata sulla Classificazione ICD-9 – Capitoli.

Figura 2.23 Tabella dei problemi basata sulla Classificazione ICD-9 – Blocchi.

Tabella dei Problemi suddivisa

per capitoli

Tabella dei Problemi suddivisa

per blocchi

15

Figura 2.24 Tabella dei problemi basata sulla Classificazione ICD-9 – Categorie e problemi semplici.

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

Tabella dei Problemi:

categorie e problemi semplici

problemi semplici

categoria

16

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] 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

17

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;

18

− 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

ricezione HL7-ACK

sistema B

RETE

19

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]

Figura 3.2 Organizzazione gerarchica degli oggetti in HL7. [3.10]

segmento campo campo …

campo compone … compone

messaggio segmento

segmento

segmento

…

messaggio ADT

MSH

EVN

PID

Intestazione

tipo di evento

dati identificativi del paziente

20

Figura 3.2 Esempio della struttura di un messaggio HL7. [3.10]

ST Stringa XPN Nome del Paziente TX Testo XAD Indirizzo del Paziente FT Testo formattato XTN N° di telefono del Paziente NM Numero ID Valore codificato da tabella HL7 DT Data IS Valore codificato dall’utente TM Ora CM Composito TS Ora (“Time Stamp”) CN ID e Nome PL Allocazione CQ 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) 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]

21

Figura 3.3 Esempio di HL7 Message [3.12]

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||||||||

22

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%20ICD9CM%201997.PDF]

23

[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/fr-icd.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]