UNIVERSITÀ POLITECNICA DELLE MARCHE
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Biomedica
DEFINIZIONE DI UN SISTEMA PER LA
GESTIONE DEL FASCICOLO SANITARIO
ELETTRONICO: NORMATIVE,
STANDARDS DI RIFERIMENTO E
REALIZZAZIONE PRATICA
Laureando:
Domenico PACCONE
Relatore: Chiar.mo
Prof. Aldo Franco DRAGONI
Anno Accademico 2006-2007
t| Å|x| zxÇ|àÉÜ|
2
INDICE
INDICE ............................................................................................ 3 RINGRAZIAMENTI ...................................................................... 5 INTRODUZIONE ........................................................................... 6 CAPITOLO 1: L’INFORMATIZZAZIONE DEI
DOCUMENTI CLINICI ................................................................ 9 1.1 INTRODUZIONE ...................................................................... 9 1.1.1 DEFINIZIONE DI CARTELLA CLINICA ................................... 9 1.1.2 PERCHÉ INFORMATIZZARE: DIRETTIVE MINISTERIALI 10 1.1.3 PERCHÉ INFORMATIZZARE: VANTAGGI RISPETTO AL
CARTACEO ........................................................................................... 11 1.1.4 LE FINALITÀ .............................................................................. 12 1.1.5 I REQUISITI ................................................................................. 14 1.1.6 LE PROBLEMATICHE ............................................................... 17 1.2 GIURISPRUDENZA E NORMATIVE VIGENTI ................. 19 1.2.1 DEFINIZIONE LEGALE DELLA CARTELLA CLINICA ....... 19 1.2.2 NORMATIVE RELATIVE ALLA COMPILAZIONE ............... 20 1.2.3 NORMATIVE RELATIVE ALL’INFORMATIZZAZIONE DEI
DOCUMENTI CLINICI ......................................................................... 21 1.2.4 TRATTAMENTO DEI DATI PERSONALI ............................... 22 1.3 STANDARDS E PROTOCOLLI DI CODIFICA ................... 25 1.3.1 INTRODUZIONE ......................................................................... 25 3
1.3.2 HEALT LEVEL 7 (HL7) .............................................................. 25 1.3.3 STANDARDS DI ORGANIZZAZIONE STRUTTURALE
DELLE CARTELLE CLINICHE ELETTRONICHE ............................ 32 1.3.3.1 ENV 13606-2 ......................................................................... 32 1.3.3.2 POMR .................................................................................... 34 1.3.3.3 LISTA CRONOLOGICA ...................................................... 35 1.3.4 ICD ................................................................................................ 36 1.3.5 LOINC........................................................................................... 39 1.3.6 DICOM ......................................................................................... 40 CAPITOLO 2: SVILUPPO PROGETTUALE .......................... 46 2.1 INTRODUZIONE .................................................................... 46 2.2 IL DOCUMENTO DEI REQUISITI ....................................... 47 2.2.1. ELENCO DEI REQUISITI........................................................... 47 2.2.2. VINCOLI AMBIENTALI ............................................................ 50 2.2.3 FUNZIONALITÀ PREVISTE ...................................................... 51 2.2.4 MATRICE DI TRACCIABILITÀ ................................................. 62 2.3 CDA DI LABORATORIO ........................................................ 62 2.4 SVILUPPO DELLE SEZIONI ANAGRAFICA ED
ANAMNESICA ................................................................................ 65 CAPITOLO 3: CONCLUSIONI ................................................. 74 APPENDICE A: XML DEL CDA DI LABORATORIO .............. 77 APPENDICE B: PDF CDA DI LABORATORIO OTTENUTO . 85 APPENDICE C: PAGINE ANAGRAFICHE E ANAMNESICHE
SVILUPPATE PER IL FASCICOLO SANITARIO ..................... 88 APPENDICE D: VERBOT .............................................................. 95 BIBLIOGRAFIA .......................................................................... 96 4
RINGRAZIAMENTI
L’eccellente percorso formativo realizzato durante l’attività di tirocinio e il
supporto sempre efficace nell’attività di stesura della tesi li devo essenzialmente ad
alcune persone che intendo ringraziare qui di seguito.
Innanzitutto rivolgo un enorme ringraziamento al Professor Aldo Franco
Dragoni per la possibilità concessami di svolgere lo stage di formazione presso una
struttura sanitaria, facendomi entrare, per la prima volta, a contatto con una realtà
lavorativa in un ambito di mio grande interesse, il sanitario appunto. Tengo a
ringraziarlo anche per la sua costante disponibilità e pazienza nell’ascoltare e
rispondere, durane la stesura della tesi, a dubbi, incertezze e domande di ogni tipo.
Sono, poi, immensamente grato al tutor Ing. Luigi Lella, persona eccezionale,
disponibile e comprensiva, nonché preparatissima e con grandi competenze, messe
sempre a disposizione dei tirocinanti. Il suo aiuto è stato fondamentale nel lavoro
svolto, soprattutto nei momenti più difficili e delicati, quando sono stati trattati
aspetti informatici di approccio non immediato per uno studente di Ingegneria
Biomedica. La crescita formativa avuta durante lo stage di formazione la devo in
buona parte a lui.
Infine rivolgo un pensiero anche a tutte le persone che lavorano presso il SIA
della ASUR zona territoriale n.7, sempre molto gentili e accoglienti con i nuovi
tirocinanti.
5
INTRODUZIONE
Negli ultimi anni, l’informatizzazione delle cartelle cliniche ha costituito una
delle tematiche di maggior rilevanza nell’ambito degli studi atti a fornire un
supporto completo ed affidabile all’interno dei servizi sanitari nazionali e locali.
La gestione e il controllo della salute sono basati, infatti, sull’uso, la
trasmissione e il confronto di una grande mole di dati, informazioni e conoscenze
eterogenei. Si registra, quindi, l’esigenza di scambiare una quantità di dati in
vertiginoso aumento, sia all’interno di una stessa struttura sanitaria (tra diversi
operatori
sanitari
e
tra
unità
operative
specializzate)
sia
tra
strutture
geograficamente distanti.
La necessità d’utilizzo di sistemi informativi nasce dall’esigenza di dover
garantire
una
sempre
maggiore
efficienza
(attraverso
l’ottimizzazione
dell’organizzazione locale) ed efficacia dei servizi/prestazioni erogati al cittadino
fruitore (attraverso la pianificazione e il controllo).
L’esigenza di organizzare e strutturare attraverso supporti informatici i dati
clinici deriva anche da una serie di studi ed evidenze che hanno mostrato e portato
in evidenza una situazione critica, se si tiene conto che l’oggetto di tali analisi
riguarda dati sensibili e, più in generale, la salute degli assistiti. Si è evidenziato, ad
esempio, su un considerevole campione analizzato, che la cartella clinica completa
non era disponibile per il 30% delle visite effettuate [Tufo, 1971] e che, spesso, gli
esami di laboratorio venivano molte volte ripetuti perché i risultati non erano resi
disponibili al medico in tempo tempestivo. Quando, invece, le cartelle cliniche sono
risultate subito disponibili, si è verificato che, spesso, mancavano dati essenziali (in
una ricerca americana [Dawes, 1972] è stato riscontrato che l’età del paziente
mancava nel 10% dei casi, che i farmaci non erano trascritti nel 30% e che la
6
diagnosi mancava nel 40%). Infine, quando sono risultati disponibili sia le cartelle
cliniche che i dati, si è riscontrato il dispendio di un tempo eccessivo per il
reperimento dell’informazione d’interesse [Zimmerman, 1978; Pories, 1990].
Ovviamente tale situazione si ripercuote sui pazienti, che si ritrovano a dover
ripetere innumerevoli volte i proprio dati anagrafici, l’anamnesi remota e prossima,
etc., a non saper descrivere ai medici i farmaci prescritti e assunti dopo un eventuale
ricovero, etc.
Da queste evidenze, nel 1991 è stato pubblicato negli Stati Uniti un rapporto
della National Academy of Science, commissionato dal Congresso, in cui un
comitato di esperti statunitensi è arrivato alla conclusione che un documento clinico
elettronico rappresenta una «tecnologia essenziale per la sanità». Nel 1998, poi, al
IX Congresso Internazionale di Informatica Medica (Medinfo ’98, Seoul, Agosto
1998) si è prodotto un consenso condiviso, basato su questi principi:
• la cartella clinica elettronica è un approccio, non un prodotto;
• la tecnologia è un’opportunità, non un vettore;
• l’aspetto fondamentale è il paziente, non la tecnologia;
• il sistema deve essere sicuro;
• occorre un “identificatore unico del paziente”.
Tali congressi sono stati quindi il punto di partenza per lo sviluppo di
progetti, programmi e studi di ricerca atti alla realizzazione di cartelle cliniche
elettroniche locali (Electronic Patient Record) prima e di fascicoli sanitari personali
(Electronic Health Record) poi. Infatti, il fascicolo sanitario rappresenta
l’integrazione di dati provenienti dalle cartelle cliniche locali in uno strumento
accessibile tramite web, che raccoglie la storia clinica di un paziente dalla nascita
alla morte. Oggi si denota, comunque, la diffusa tendenza a identificare con il
termine di cartelle cliniche elettroniche i suddetti fascicoli sanitari informatizzati.
Pertanto, anche nei capitoli seguenti quando si parla di cartelle cliniche ci si
riferisce, in realtà, all’accezione più generica di fascicoli sanitari.
7
Anche in Italia sono stati promossi e portati avanti, soprattutto negli ultimi
anni, innumerevoli progetti a riguardo, grazie allo sviluppo di tecnologie e supporti
hardware/software con potenzialità sempre maggiori e alla diffusione di connessioni
in rete a banda larga, che hanno facilitato la comunicabilità e la trasmissibilità di
dati online. L’attività di tirocinio svolta presso il SIA della ASUR zona territoriale
n.7 di Ancona si è quindi inserita in uno di tali progetti, denominato “Assistente
Personale”. Nello specifico, lo stage si è concentrato in un primo momento
sull’analisi delle tecnologie e dei protocolli esistenti ed utilizzabili in fase di
sviluppo, e successivamente sul progetto vero e proprio del fascicolo sanitario lato
medico e la definizione di un applicativo per la gestione dei dati clinici degli esami
di laboratorio.
8
CAPITOLO 1: L’INFORMATIZZAZIONE DEI
DOCUMENTI CLINICI
1.1 INTRODUZIONE
1.1.1 DEFINIZIONE DI CARTELLA CLINICA
Il passo preliminare per l’analisi progettuale di una cartella clinica informatizzata
consiste nell’apprendimento della definizione stessa che se ne da:
“La cartella clinica è un documento, o meglio un insieme di documenti, nei
quali viene registrato dal medico, ed anche dal personale paramedico, un
complesso eterogeneo di informazioni soprattutto sanitarie, ma anche
anagrafiche,
sociali,
ambientali,
giuridiche,
etc.,
concernenti
un
determinato, allo scopo di poterne rilevare, il più acutamente possibile, ciò
che lo riguarda in senso diagnostico-terapeutico, nel momento di
un’eventuale
ospedalizzazione,
ed
in
tempi
successivi,
anche
ambulatorialmente, al fine di predisporre gli opportuni interventi medici e
9
poterne usufruire anche per le più varie indagini di natura scientifica,
statistica, medico-legale e per l’insegnamento” [Gattai, 1990].
“La cartella clinica è da considerare un diario diagnostico-terapeutico, nel
quale vanno annotati fatti di giuridica rilevanza quali i dati anagrafici ed
anamnestici del paziente, gli esami obiettivi, di laboratorio e specialistici,
le terapie praticate, nonché l’andamento, gli esiti e gli eventuali postumi
della malattia” [Cassazione Penale, 27/02/92].
In sintesi, la cartella clinica è una registrazione dei dati anagrafici, dell’anamnesi,
dei rilievi clinici, degli indirizzi diagnostici e dei dispositivi terapeutici relativi ad
un determinato paziente.
Può, quindi, essere definita anche come una costante certificazione di ciò che il
medico rileva e delle procedure diagnostico-terapeutiche che intende approntare.
1.1.2 PERCHÉ INFORMATIZZARE: DIRETTIVE
MINISTERIALI
Già da qualche anno la Convenzione del Ministero della Sanità con i medici di
medicina generale prevede e incentiva espressamente l'informatizzazione. Invece,
dal 2005 è divenuto obbligo dotarsi di cartelle cliniche informatizzate, come
riportato nell’“Accordo collettivo nazionale per la disciplina dei rapporti con i
medici di medicina generale” (ai sensi dell’Art.8 del D.L.vo 502/92 e successive
modificazioni). Infatti, viene esplicitamente riportato che:
«Dall’entrata in vigore del presente accordo, tutti i medici di assistenza
primaria sono obbligati a garantire, dal momento dell'assunzione
dell'incarico, nel proprio studio e mediante apparecchiature e programmi
informatici, la gestione della scheda sanitaria individuale e la stampa
10
prevalente (non inferiore al 70%) delle prescrizioni farmaceutiche e delle
richieste di prestazioni specialistiche. Le apparecchiature di cui sopra
devono essere idonee ad eventuali collegamenti con il centro unico di
prenotazione e devono consentire l'elaborazione dei dati occorrenti per
ricerche epidemiologiche, il monitoraggio dell'andamento prescrittivo e la
verifica di qualità dell'assistenza» (Parte II - Capo II Art. 59 /11).
1.1.3 PERCHÉ INFORMATIZZARE: VANTAGGI RISPETTO
AL CARTACEO
La nascita e lo sviluppo di un numero sempre maggiore di progetti concernenti
cartelle cliniche informatizzate è dovuto ai numerosi vantaggi che queste hanno
dimostrato avere rispetto a quelle cartacee, in quanto:
• evitano l’archiviazione del cartaceo;
• velocizzano le operazioni di inserimento ed archiviazione dei dati;
• limitano i rischi di smarrimento dei dati sensibili archiviati;
• forniscono all’operatore sanitario un reale ausilio diagnostico-terapeuticogestionale nello svolgimento della propria attività professionale, dando la
possibilità di analizzare e confrontare, anche nel tempo, i dati clinici del/dei
pazienti, nonché consultare statistiche, effettuare ricerche di dati o formulare
ipotesi diagnostiche;
• aiutano ad evitare errori;
• danno la possibilità di consultare i dati clinici del/dei pazienti in differenti
strutture sanitarie;
• permettono al personale medico di avere sempre a disposizione qualsiasi
informazione riguardante la vita clinica del/dei pazienti;
11
• danno al paziente l’opportunità di poter visionare i propri dati clinici da casa,
via web;
• facilitano il recupero e la consultazione di dati clinici comprensivi di grafici,
tabelle, e bioimmagini.
Purtroppo va detto che si denota ancora tra i medici una certa resistenza all’utilizzo
e nel prendere confidenza con nuove applicazioni informatiche. Pertanto, la cartella
clinica informatizzata deve avere come requisito, o meglio come valore aggiunto,
un’interfaccia il più intuitiva e di facile approccio possibile, così come il suo
utilizzo deve risultare semplice e friendly per i medici di base che andranno ad
utilizzarla. Solo in questo modo, rendendo di immediata percezione i vantaggi
offerti dallo strumento elettronico rispetto al cartaceo, si potrà tentare di superare la
barriera di resistenza opposta da buona parte della classe medica verso l’utilizzo di
applicazioni informatiche di ausilio alla propria attività.
1.1.4 LE FINALITÀ
A questo punto risulta utile definire quali siano le finalità della cartella clinica
informatizzata:
• gestione clinica
Il normale lavoro clinico viene svolto in base alle informazioni disponibili e,
quando queste non sono sufficienti, necessita della ricerca di ulteriori
informazioni;
• ricerca
Spesso in ambito clinico il lavoro non si esaurisce nella diagnosi, ma ha una più
o meno grande componente di ricerca, oggi sempre più frequente specie in
12
campo farmacologico. Ne deriva che in area clinica la corretta gestione dei dati e
delle informazioni riveste un'importanza sempre maggiore;
• amministrazione
Negli ultimi anni la componente amministrativa del lavoro clinico sta crescendo
sempre più rapidamente e le incombenze di questo tipo diventano sempre più
frequenti e complicate. Per obbedire ai doveri amministrativi è necessario avere
a disposizione informazioni certe e circostanziate;
• controllo finanziario
Molte delle informazioni che vengono gestite giornalmente in area clinica hanno
un risvolto, oltre che amministrativo, anche finanziario. Dall'accuratezza delle
informazioni e dei dati dipende la misurazione del lavoro clinico e la sua
valorizzazione in ambito aziendale;
• management clinico
Il lavoro degli operatori sanitari in ambito clinico diviene sempre più complesso,
spesso ha aspetti collaborativi interdisciplinari e interprofessionali. Nel caso in
cui più persone intervengono sullo stesso assistito, l'accuratezza e la
disponibilità delle informazioni divengono di fondamentale importanza. In
queste situazioni non ci si può affidare alla buona volontà dei singoli, ma è
necessaria una funzione di management che governi le interazioni e coordini le
decisioni;
• esigenze legali
Come tutti sappiamo, le procedure mediche possono comportare errori, danni e
quindi l'avvio di azioni legali tendenti a stabilire le eventuali responsabilità e a
definire gli eventuali risarcimenti. In quest'area la qualità e la completezza delle
informazioni divengono di importanza assolutamente basilare, in quanto la
mancanza di informazioni critiche può far vedere la colpa dove non c'è.
13
1.1.5 I REQUISITI
I requisiti di base richiesti per le cartelle cliniche elettroniche possono essere
identificati ed elencati osservando sistematicamente diversi possibili aspetti, che
vengono di seguito descritti.
Contenuto
Deve essere sistematizzato e organizzato, come base per ogni successiva
elaborazione e per garantire un adeguato livello di qualità, e deve:
• utilizzare un insieme minimo di dati concordato;
• utilizzare un dizionario di dati comune predefinito;
• utilizzare i relativi sistemi di codifica condivisi e il loro formato standard;
• riportare le informazioni sull'esito delle terapie e sullo stato del paziente.
I primi tre punti richiedono accordi espliciti a livello regionale e possibilmente a
livello nazionale e internazionale, per definire i dati che occorre trattare in modo
uniforme e i sistemi di codifica collegati.
Formato
I dati devono essere adeguatamente strutturati, in modo da poter fornire funzionalità
avanzate, quali:
• predisporre una lista dei problemi come una "pagina di apertura";
• prevedere la possibilità di andare rapidamente da una sezione all'altra della
cartella;
• utilizzare formati armonizzati tra diverse discipline e diverse strutture
sanitarie, per realizzare interfacce omogenee;
• la struttura della cartella deve prevedere diversi livelli di organizzazione dei
dati con specifiche caratteristiche legali e pratiche. Ad esempio in ENV
14
13606 vengono definiti i concetti di: "folder", "composition", "section",
"cluster". Le composizioni sono le unità di documentazione che vengono
firmate da un responsabile. Un folder comprende uno o più composizioni.
Una composizione può essere organizzata in sezioni. Nella comunicazione
tra operatori sanitari l'unità minima di trasmissione dovrebbe essere la
composizione firmata.
Le prestazioni del sistema
È un aspetto più pratico ma fondamentale per l’accettazione da parte degli utenti,
per cui si ha:
• facilità di immissione dei dati.
• rapido recupero dei dati;
• disponibilità 24 ore su 24 (almeno per le cartelle cliniche ospedaliere e per le
diverse forme di fascicolo sanitario personale);
• disponibilità in luoghi facilmente accessibili e compatibili con le modalità di
lavoro;
Connessioni
Il sistema di gestione delle cartelle cliniche deve avere opportune connessioni,
logiche ed operative, con altri sistemi, quali:
• collegamenti con altri sistemi informativi, con messaggistica standard per
scambio di ordini/risultati o per prenotazioni (radiologia, laboratorio etc.);
• trasferibilità delle informazioni tra specialisti e luoghi diversi;
• facilità di consultazione con banche dati bibliografiche;
• collegamenti con basi di dati e con registri istituzionali;
• possibilità, ove opportuno, di collegamenti con cartelle cliniche di familiari
(secondo modalità di accesso che tengano conto della privacy);
• gestione elettronica dei documenti economici (es. rimborsi, ticket).
15
Funzionalità intelligenti
Devono essere basate anche su semplici regole o su basi di conoscenze commerciali
(per esempio, basi di dati sull'interazione tra farmaci e sugli effetti collaterali):
• aiuto alla gestione e all'adattamento di percorsi diagnostico-terapeutici
predefiniti, e successiva valutazione retrospettiva dell'appropriatezza degli
interventi e delle motivazioni degli scostamenti dai percorsi predefiniti;
• supporto alla decisione e guida alla risoluzione di problemi;
• richiamo selettivo di informazioni di rilevanza clinica (clinical reminders);
• allarmi per segnalare errori o problemi, adattabili dall'utente.
Generazione rapporti e documentazione
Vanno considerati sia gli aspetti legati alla gestione "interna" dei pazienti e del
carico di lavoro, che gli aspetti relativi alla comunicazione con altri operatori:
• produzione di documentazione "derivata" (per esempio, ricette o denunce di
malattia), nei formati richiesti dalle organizzazioni interessate;
• documentazione clinica ordinaria (per esempio, lettera di dimissione);
• certificati e documentazione a richiesta (sintesi in risposta a specifici quesiti);
• rapporti e grafici sugli andamenti di singoli pazienti o di sottogruppi.
Sicurezza
È un ulteriore aspetto di crescente rilevanza nelle reti telematiche, sotto diversi
punti di vista, sempre garantendo la facilità di accesso per il paziente e i suoi
delegati:
• rispetto della riservatezza dei dati contro possibilità di lettura ed uso non
autorizzati;
16
• controllo delle autorizzazioni e dei mandati per l'introduzione o la modifica
dei dati;
• protezione dei dati da perdite o modifiche accidentali (back-up).
Innovazione
Fondamentale nella pratica clinica e relativamente alla resistenza degli operatori a
cambiamenti non sempre compatibili con le proprie abitudini e la propria cultura.
La cartella clinica elettronica non deve essere imposta, ma deve risultare facilmente
compatibile con il modo di lavorare del medico. Lo sforzo per l'utilizzo del sistema
deve essere bilanciato dalla percezione di chiari benefici:
• addestramento ridotto all'essenziale per l'utilizzo delle funzioni di base,
estendibile gradualmente alle funzioni più complesse;
• implementazione e installazione il più possibile graduale e modulare;
• naturalezza e gradevolezza dell'interfaccia;
• rispetto dell'interazione medico-paziente.
1.1.6 LE PROBLEMATICHE
L’informatizzazione della cartella clinica o della scheda sanitaria non è
un’innovazione banale e priva di rischi. Infatti deve essere garantita:
• l’identificazione del compilatore;
• la possibilità di fruire dei dati sensibili esclusivamente da parte del paziente e
del personale medico autorizzato;
• la sicurezza contro le manomissioni;
• la tutela dalle intromissioni;
• la tutela dalla violazione della segretezza.
17
In caso di mancata competenza specifica sulla sicurezza, il titolare deve avvalersi di
personale competente, il quale deve rilasciare certificazione sugli interventi.
In particolare, il decreto legislativo 196/2003 (“Codice in materia di protezione dei
dati personali”) al titolo V prevede che i dati personali oggetto di trattamento siano
custoditi e controllati applicando le tecniche, relative a misure e organizzazione, più
sicure e aggiornate, atte a ridurre al minimo i rischi di accesso non autorizzato o di
trattamento non consentito e non conforme alle finalità della raccolta, nonché di
distruzione o perdita, seppur accidentale.
Dunque risulta fondamentale l'adozione di idonee e preventive misure di sicurezza,
le quali prevedono:
• un’autenticazione informatica;
• l’adozione di procedure di gestione delle credenziali di autenticazione;
• l’utilizzo di un sistema di autorizzazione;
• l’aggiornamento periodico dell'individuazione dell'ambito del trattamento
consentito ai singoli incaricati e addetti alla gestione o alla manutenzione degli
strumenti elettronici;
• la protezione degli strumenti elettronici e dei dati da trattamenti illeciti degli
stessi, da accessi non consentiti e da determinati programmi informatici;
• l’adozione di procedure per la custodia di copie di sicurezza, il ripristino
della disponibilità dei dati e dei sistemi;
• la disponibilità di un aggiornato documento programmatico di sicurezza.
18
1.2 GIURISPRUDENZA E NORMATIVE VIGENTI
1.2.1 DEFINIZIONE LEGALE DELLA CARTELLA CLINICA
Come definito dalla Cassazione (C.d.C. 27/09/99, n° 10695), la cartella clinica è,
legalmente, un atto pubblico di fede privilegiata, ossia un atto redatto dal medico
nell’esercizio di una potestà di certificazione ed attestazione conferita dalla legge ed
in conformità ai singoli regolamenti interni. Nella compilazione di una cartella
clinica il medico ricopre, pertanto, il ruolo di pubblico ufficiale se compie attività di
assistenza sanitaria (ASL ed Ospedali). Ricoprono in ugual modo questo ruolo i
medici della ASL, i medici e farmacisti ospedalieri ed i medici dipendenti privati di
una struttura sanitaria convenzionata con il Sistema Sanitario Nazionale.
Possono essere quindi delineati gli elementi giuridicamente necessari alla
definizione della cartella clinica come atto pubblico:
• l’agente: il medico che la redige;
• il destinatario: il paziente cui è riferita la cartella clinica;
• la volontà: nessun atto può considerarsi riferibile all’autore se non è stato
consapevolmente voluto;
• l’oggetto: deve essere determinato, possibile e lecito;
• il contenuto: la cartella clinica ha contenuto misto e complesso (certificativo,
attestativo, dispositivo) e si compone anche di altri documenti (ad esempio le
bioimmagini);
• le finalità: scopo amministrativo, assistenza sanitaria pubblica;
• la forma: scritta.
19
1.2.2 NORMATIVE RELATIVE ALLA COMPILAZIONE
In fase di redazione di un documento clinico, la sua funzione certificatoria deve
poter essere assicurata attraverso veridicità, completezza, correttezza formale e
chiarezza (Cfr. Cass. Penale 27 Marzo 1992).
La sottoscrizione di una cartella clinica da parte di un medico non prevede, inoltre,
l’ipotesi di responsabilità a suo carico in caso di erronea terapia medica se egli è
assente al momento dell’intervento (Corte dei Conti, sez. II, 14 Marzo ’91, n.146).
Analogamente, in caso di intervento sanitario con esito infausto il medico può
essere dichiarato esente da responsabilità solo se abbia agito attenendosi alle regole
della scienza e l'evento si sia verificato per cause a lui non imputabili, oppure se vi
sia stato un errore professionale, sempre che questo non sia a sua volta determinato
da negligenza, imprudenza o imperizia.
Per quanto concerne le eventuali correzioni da apportare, va sottolineato che la
documentazione clinica, in virtù della sua funzione pubblica, non appartiene a colui
che la redige. Pertanto è vietato alterare il significato della cartella, anche se il
documento rimane nella disponibilità materiale del medico. Nell'ipotesi di un’errata
annotazione, è quindi lecito solo ripetere successivamente l'annotazione corretta,
senza modificare le precedenti scritture (Cassazione penale, sez. V, sentenza
13989/2004).
Nei casi in cui vengano riportati, in fase di compilazione, un dato o un’annotazione
falsi, si definiscono due tipologie di falsità in atto pubblico:
• falsità materiale
Il pubblico ufficiale che, nell’esercizio delle sue funzioni, forma, in tutto o in
parte, un atto falso o altera un atto vero, è punito con la reclusione da uno a sei
anni (art. 476 del Codice Penale);
• falsità ideologica
20
Il medico, ricevendo o formando un atto nell’esercizio delle sue funzioni, è
soggetto alle pene previste all’art. 479 del Codice Penale nei casi in cui: attesta
falsamente che un fatto è stato da lui compiuto o è avvenuto alla sua presenza,
omette o altera dichiarazioni da lui ricevute oppure attesta falsamente fatti dei
quali l'atto è destinato a provare la verità.
1.2.3 NORMATIVE RELATIVE ALL’INFORMATIZZAZIONE
DEI DOCUMENTI CLINICI
Il Decreto Legislativo del 7 Marzo 2005, n.82, punto P afferma che si può definire
documento informatico la rappresentazione informatica di atti, fatti o dati
giuridicamente rilevanti. La cartella clinica, quindi, può nascere o essere trasformata
in documento informatico, nel rispetto di quanto contenuto nel predetto decreto
legislativo. Pertanto, la registrazione su supporto informatico, la trasmissione con
strumenti telematici, la sottoscrizione con firma elettronica qualificata e la
sottoscrizione con firma digitale sono validi e rilevanti a tutti gli effetti di legge se
conformi alle regole tecniche di cui all'articolo 71 del D. Lgs. del 7 Marzo 2005,
n.82, che garantiscono l'identificabilità dell'autore e l'integrità del documento.
Per quanto concerne la validazione legale, essa può essere effettuata dal pubblico
ufficiale di competenza, il medico, tramite una firma digitale. L'autenticazione di
quest’ultima consiste nell'attestazione, da parte del pubblico ufficiale, che la firma
sia stata apposta in sua presenza dal titolare della validità del certificato elettronico
utilizzato e che il documento sottoscritto non sia in contrasto con l'ordinamento
giuridico.
Inoltre, l’informatizzazione dei documenti clinici e lo sviluppo di applicativi online
dei servizi di teleassistenza e teleconsulto hanno portato il Garante della Privacy a
delineare le condizioni per cui risulti necessaria la notifica delle prestazione di
servizi sanitari online, così come riportate nella Newsletter Garante della Privacy
n.210 del 26 Aprile 2004, secondo cui:
21
• necessitano di notifica
le prestazioni riguardanti servizi relativi ad una banca dati, prestati per via
telematica o relativi alla fornitura di beni;
• non necessitano di notifica
i trattamenti di dati nell’ambito della teleassistenza (consulto per via telefonica),
organizzati in banche dati ad archiviazione cartacea od organizzati in banche
dati informatizzate ma scollegate da reti telematiche.
1.2.4 TRATTAMENTO DEI DATI PERSONALI
I dati contenuti nelle cartelle cliniche sono dati sensibili strettamente correlati alle
informazioni medico-sanitarie e anagrafiche del paziente a cui si riferiscono. È
quindi di immediata evidenza la necessità di normative atte alla tutela della Privacy
di tali dati. Il Decreto attualmente vigente in materia è il Decreto Legislativo del 30
Giugno 2003, n. 196, Titolo V. Alcuni degli articoli di maggior rilevanza sono:
• art. 76 – condizioni di rilascio del consenso
comma 1: gli esercenti le professioni sanitarie e gli organismi sanitari pubblici
trattano i dati personali idonei a rivelare lo stato di salute: a) con il consenso
dell’interessato, anche senza l’autorizzazione del Garante, se il trattamento
riguarda dati e operazioni indispensabili per perseguire una finalità di tutela
della salute dell’interessato; b) senza il consenso dell’interessato, previa
autorizzazione del Garante, se la finalità di tutela della salute riguarda la
collettività. L’autorizzazione del Garante, salvo i casi di particolare urgenza,
viene rilasciata previo consulto del Consiglio Superiore di Sanità.
• art. 78 – informativa sul trattamento dei dati
22
comma 1: il medico di medicina generale o il pediatra di libera scelta informano
l’interessato relativamente al trattamento dei dati personali, in forma chiara e
tale da rendere comprensibili gli elementi indicati nell’articolo 13, comma 1;
comma 3: l’informativa può riguardare, altresì, dati personali eventualmente
raccolti presso terzi.
• art. 13 – informativa sul trattamento dei dati
comma 1: l'interessato o la persona presso la quale sono raccolti i dati personali
viene previamente informata oralmente o per iscritto circa: a) le finalità e le
modalità del trattamento cui sono destinati i dati; b) la natura obbligatoria o
facoltativa del conferimento dei dati; c) le conseguenze di un eventuale rifiuto di
rispondere; d) i soggetti o le categorie di soggetti ai quali i dati personali
possono essere comunicati o che possono venirne a conoscenza in qualità di
responsabili o incaricati, e l'ambito di diffusione dei dati medesimi.
• art. 82 – informativa successiva alla prestazione medica
comma 1: l’informativa e il consenso al trattamento dei dati personali possono
intervenire successivamente alla prestazione, nel caso di emergenza sanitaria o
di igiene pubblica per la quale la competente autorità ha adottato un’ordinanza
contingibile ed urgente;
comma 2: l’informativa e il consenso al trattamento dei dati personali possono
intervenire successivamente alla prestazione, in caso di: b) rischio grave,
imminente ed irreparabile per la salute del’interessato.
• art. 92 – richiesta di accesso ai dati sensibili
comma 2: eventuali richieste di presa visione o di rilascio di copia della cartella
da parte di soggetti diversi dall’interessato possono essere accolte, in tutto o in
parte, solo se la richiesta è giustificata dalla documentata necessità: a) di far
valere o difendere una libertà fondamentale e inviolabile o un diritto della
personalità, di pari rango a quello dell’interessato.
L’art.92 va applicato in conformità con quanto riportato all’art.26, comma 4.
23
• art. 26 – condizioni di trattamento senza consenso
comma 4: i dati sensibili possono essere oggetto di trattamento anche senza
consenso, previa autorizzazione del Garante: a) quando il trattamento è
effettuato da associazioni, enti od organismi senza scopo di lucro, anche non
riconosciuti, per il perseguimento di scopi determinati e legittimi, relativamente
ai dati personali degli aderenti o dei soggetti che in relazione a tali finalità hanno
contatti regolari con l'associazione. Questo può avvenire solo se i dati non siano
comunicati all'esterno o diffusi e l'ente determini idonee garanzie relativamente
ai trattamenti effettuati, prevedendo espressamente le modalità di utilizzo dei
dati; b) quando il trattamento è necessario per la salvaguardia della vita o
dell'incolumità fisica di un terzo. Se la medesima finalità riguarda l'interessato e
quest'ultimo non può prestare il proprio consenso per impossibilità fisica, per
incapacità di agire o per incapacità di intendere o di volere, il consenso è
manifestato da chi esercita legalmente la potestà, ovvero da un prossimo
congiunto, da un familiare, da un convivente o, in loro assenza, dal responsabile
della struttura presso cui dimora l'interessato.
24
1.3 STANDARDS E PROTOCOLLI DI CODIFICA
1.3.1 INTRODUZIONE
Negli ultimi anni, la tendenza allo sviluppo sempre crescente di documenti clinicosanitari elettronici ha reso inevitabilmente necessaria la creazione e la definizione di
nuovi standards, protocolli e codifiche informatiche specifici per l’ambito medico.
Nei paragrafi a seguire vengono presi in esame alcuni degli standards tra i più
importanti e diffusi nell’informatica medica, utilizzati poi in fase di sviluppo
progettuale.
1.3.2 HEALT LEVEL 7 (HL7)
HL7 (www.hl7.org; www.hl7italia.it) è uno standard di comunicazione sviluppato
nell’ambito dell’Healtcare con lo scopo di permettere l’intercomunicabilità di dati
tra la gran parte delle istituzioni e le strutture del settore sanitario. Più precisamente,
l’intento è quello di creare in modo flessibile, produttivo e sistematico approcci,
standards, linee guida, metodologie e servizi relativi all’interoperabilità tra vari
sistemi informatico-sanitari.
I principali vantaggi apportati dalla diffusione dell’HL7 sono, quindi, lo sviluppo di
formati e protocolli tali da poter garantire lo scambio di dati tra i vari sistemi
informatico-sanitari,
la
standardizzazione
delle
interfacce,
l’ottimizzazione
dell’efficienza nella comunicazione tra le varie strutture sanitarie e l’utilizzo di
standard internazionali in ambito medico.
L’HL7 prevede inoltre la standardizzazione dei messaggi di intercomunicazione tra
sistemi, in particolare per quanto riguarda la struttura dei messaggi stessi, la loro
25
descrizione per le regole di encoding per la trasmissione di dati, ed i trigger events
(in sede di generazione di eventi).
Lo standard sfrutta un sistema di scambio dati che genera proprio dal verificarsi di
uno di questi trigger events, quali ad esempio il ricovero di un nuovo paziente, che
porta all’invio di messaggi dal sistema che registra l’evento ad altri sistemi ad esso
collegati, come si evince dalla seguente immagine:
Fig.1: trigger event e scambio dati
Il sistema ricevente invia, poi, di ritorno, un altro messaggio, definito HL7-ACK
(Acknowledged Exchange Of Data), ossia una conferma di avvenuta acquisizione
dei dati inviati dal sistema di partenza. In caso contrario, se vi è stata perdita
d’informazione durante la trasmissione del messaggio attraverso la rete, il sistema
ricevente invia delle Query così da indurre il sistema di partenza a re-inviare
l’informazione persa.
Fig.2: perdita d’informazioni ed invio di Query
26
Questo sistema di scambio dati rende pertanto possibile la registrazione di un nuovo
paziente nel sistema informatico-amministrativo centrale, in seguito al verificarsi di
un trigger event, ed il successivo scambio dei relativi dati con tutte le altre
postazioni informatiche dislocate nei vari dipartimenti ed unità operative complesse.
Fig.3: scambio dati tra le varie strutture del sistema informatico ospedaliero
L’HL7 prevede, oltre allo scambio di dati amministrativo-anagrafici, anche la
trasmissione di messaggi strutturati contenenti tabelle di valori previste dallo
standard, tabelle definite dall’utente, riferimenti di codifica di altri standard (ISO,
ICD, etc.) o semplici data-type (Nome paziente, ID paziente, etc.). Ogni messaggio
viene così ad essere costituito da una serie di segments, ossia una serie di elementi o
informazioni organizzati in modo logico, secondo una sequenza ordinata di campi
(fields).
Attualmente l’HL7 prevede la coesistenza di due versioni, la 2.x, molto stabile e di
facile uso, e la v3, designata per il supporto XML ma più complessa e non ancora
sufficientemente stabile né testata con documenti strutturati. Nonostante ciò,
l’ultima versione presenta degli aspetti e dei vantaggi di prim’ordine, quali la
possibilità di sviluppare varianti locali da parte delle utenze che fruiscono dello
standard e la gestione di un numero maggiore di trigger events e di formati dei
27
messaggi scambiati. L’aspetto di maggior interesse riguarda comunque la
compatibilità della v3 con una metodologia di sviluppo orientata agli oggetti e un
sistema di creazione dei messaggi che esplicita le intercorrelazioni semanticolessicali tra le informazioni contenute nei segments: il Reference Information Model
(RIM).
Il modello RIM, insieme al linguaggio XML per l’encoding dei documenti clinici, è
anche alla base della cosiddetta HL7 CDA (Clinical Document Architecture), ossia
del sistema di architettura dei documenti clinici che ne permette la fruizione, il
trattamento e lo scambio tra i vari sistemi informatico-sanitari. Le principali
caratteristiche di un documento in HL7 CDA devono pertanto essere:
• Persistenza
Un documento clinico deve essere conservato in uno stato inalterato, per un
periodo di tempo stabilito da leggi o regolamenti locali;
• Gestione
Il documento va conservato dall’organizzazione che si occupa della sua
gestione;
• Autenticazione
Un documento clinico è un insieme di dati sensibili, per cui si rende necessaria
l’autenticazione legale;
• Contesto
Il documento clinico definisce il contesto di default per i contenuti in esso
presenti;
• Interezza
L’autenticazione va riferita all’intero documento e non a sue singole porzioni;
• Leggibilità
28
Un documento clinico deve essere “human-readable”, ossia leggibile da un
umano e non solo da una macchina (nella fattispecie un computer).
Strutturalmente, un documento CDA è costituito da un Header, che identifica e
classifica il documento e fornisce informazioni sull’autenticazione, sul paziente e
sui providers coinvolti, e un Body, che contiene il report clinico, che può essere
strutturato o meno in sezioni ricorsive, tramite linguaggi di markup. Più nello
specifico, l’Header contiene tags quali:
• l’identificativo unico del documento (<id extension>);
• il codice che contraddistingue il tipo di documento (<code>). Di solito si
ricorre ai codici OID, LOINC o ICD, di cui si parlerà in seguito;
• il titolo del documento (<title>);
• la data di creazione del documento (<effectiveTime>)
oltre che tutta la serie di tags relativi ai cosiddetti Participants, ossia l’insieme degli
operatori che definiscono e gestiscono i contenuti del documento CDA:
• l’autore
(medico
ospedaliero,
medico
della
ASL)
(<assignedAuthor>):
Fig.4: tags relativi all’autore del documento
29
del
documento
• il
laboratorio
che
ha
effettuato
l’analisi
o
l’esame
(<representedOrganization>);
• l’ente responsabile della gestione e del trattamento del dato clinico acquisito
(<assignedCustodian>);
• l’assistito a cui il documento è riferito (<record Target>):
Fig.5: tags relative all’assistito a cui il documento è riferito
Attualmente, l’HL7 CDA è giunta alla Release 2, la quale prevede l’estensione
dell’implementazione dei modelli RIM anche al Body e non solo all’Header, come
avveniva nella Release 1. Questo aspetto permette la strutturazione articolata del
documento CDA in modelli grafici, gli Object Models, attraverso le sei classi,
definite “back-bone”, proprie del RIM:
• Act
Rappresenta le azioni cliniche svolte (esami, visite, etc.) che vanno documentate
per il management e la gestione dell’Healtcare e per fini legali;
• Participation
Rappresenta il “contesto” dell’act, ossia chi ha svolto l’azione, a quali fini la si è
compiuta, dove, etc.
30
• Entity
Rappresenta le persone, le strutture, le organizzazioni, etc. che prendono parte
all’Healtcare;
• Role
Definisce il ruolo ricoperto dalle entities nelle acts d’interesse;
• ActRelationship
Definisce i legami e le relazioni tra un act e un altro, ad esempio la relazione che
intercorre tra la richiesta di un esame e lo svolgimento stesso dell’esame;
• RoleLink
Definisce le relazioni tra i vari Role.
Fig.6: esempio di Object Model di un documento CDA, strutturato secondo i modelli RIM
Queste classi si dividono poi in ulteriori sotto-classi o attributi, quali moodCode,
determinerCode, typeCode, etc.
31
1.3.3 STANDARDS DI ORGANIZZAZIONE STRUTTURALE
DELLE CARTELLE CLINICHE ELETTRONICHE
Da un punto di vista strutturale, la cartella clinica elettronica può essere organizzata
almeno secondo tre principi [Rossi Mori, 2000]:
• secondo la suddivisone classica in sezioni (anagrafica, anamnesi, esami
obiettivi, prescrizioni, etc.);
• per problemi ed episodi di malattia;
• come una lista cronologica di fatti, basata sulla data di registrazione (o di
ricevimento dei messaggi da altri calcolatori) o sulla data dell’evento
sottostante.
1.3.3.1 ENV 13606-2
La documentazione clinica presenta delle sezioni tipiche quali: anamnesi, esame
obiettivo, diagnosi e prognosi di entrata, pianificazione della terapia, terapia
effettuata, dati di laboratorio, diario clinico, diagnosi di uscita, lettera di dimissione,
follow-up, terapia di mantenimento, etc.
L’ENV 13606-2 è, quindi, uno standard che prevede il raggruppamento delle
varianti locali in grosse categorie, per permettere il confronto tra le cartelle cliniche
costruite in modo indipendente. Tali categorie sono schematizzate nella seguente
tabella:
32
Fig.7: codifica ENV 13606-2 delle categorie in cui suddividere la cartella clinica
Scopo dello standard è, pertanto, quello di fornire una griglia per navigare in un
insieme di documenti non predisposti ed estrarre i documenti rilevanti per uno
scopo prefissato dall'utente. Inoltre le categorie potranno servire per sviluppare
regole che permettano ad un’applicazione di verificare e strutturare i fatti contenuti
all'interno di una data sezione. Le categorie ovviamente non sono concepite per
sostituire i nomi originali delle sezioni nelle cartelle cliniche originali.
33
1.3.3.2 POMR
La "cartella clinica orientata per problemi" (POMR, “Problem Oriented Medical
Record”, pubblicato da Lawrence Weed nel 1968-69) prevede una suddivisione
diversa delle sezioni e dei contenuti delle cartelle cliniche.
Lo scopo è quello di incoraggiare un processo logico nella raccolta e
memorizzazione dei dati, per generare testi più strutturati e cartelle più chiare,
anche per comunicare informazioni sul paziente ad altri operatori. In questo
approccio, la cartella è organizzata secondo tre modalità:
1. informazioni di base, sia permanenti (es.: data di nascita, sesso, anamnesi
familiare) che variabili (es.: stato civile, stato lavorativo, indirizzo, test di
screening);
2. lista dei problemi, che contiene i problemi attivi e inattivi, sia di tipo medico che
sociale;
3. dati clinici di dettaglio, organizzati per problema. In particolare, ogni problema
viene esaminato seguendo uno schema ben preciso, il SOAP:
• aspetti Soggettivi, osservati o raccontati dal paziente;
• aspetti Oggettivi, osservati dal medico od ottenuti come risultati di analisi;
• valutazione (Assessment), che riflette l'interpretazione del medico;
• Pianificazione, che riguarda gli obiettivi e le azioni da intraprendere.
I riassunti basati sui problemi sono risultati utili per migliorare il processo
decisionale (es.: per rapidità e qualità delle decisioni, per un migliore accesso alle
informazioni rilevanti). Questo approccio è stato facilmente trasferito su supporto
elettronico, per la progettazione, la presentazione e l'analisi di cartelle cliniche.
Nell'uso concreto, è stata tuttavia riscontrata una certa imprecisione nel gestire in
modo omogeneo e pratico le relazioni, spesso complesse, tra problemi e incontri
(encounters), episodi e sotto-problemi. Sono stati quindi proposti diversi modelli
34
più dettagliati, che sono tuttora oggetto di discussione. Tra questi, occorre citare il
modello OHEAP (Orientation, History, Exam, Assessment, Plan). E' stata poi
proposta una serie di criteri per l'implementazione su calcolatore dell'approccio
problem-oriented:
• il sistema deve essere centrato sugli aspetti clinici;
• i problemi devono essere ben codificati;
• il sistema deve poter aiutare la decisione clinica;
• il sistema deve gestire l'evoluzione dei problemi;
• il sistema deve gestire diverse viste cliniche sui dati;
• le funzioni di manutenzione devono essere integrate con le procedure di
lavoro;
• il sistema deve gestire la documentazione amministrativa;
• il sistema deve essere integrato con utili strumenti clinici.
1.3.3.3 LISTA CRONOLOGICA
Per un calcolatore è semplice ordinare e presentare i fatti clinici per data, anche se
la realizzazione pratica di questa funzione nelle cartelle cliniche reali non è
altrettanto semplice. Infatti questa funzione implica due presupposti:
1. ogni fatto che descrive un dato clinico deve essere rappresentato esplicitamente
come un singolo dato elementare. In altre parole, i fatti non possono essere
memorizzati in modo informale all'interno di arbitrari brani di testo, ma devono
essere ben suddivisi (uno per frase). Inoltre i fatti non devono essere frammentati in
un numero imprevedibile di campi non collegati, ovvero - se l'informazione è
rappresentata in più campi - esistono dei criteri espliciti che permettono
all'applicazione di raggrupparli;
35
2. ogni fatto corrisponde esplicitamente ad una data, e il "tipo di data" è esplicito.
Esistono, infatti, diversi tipi di data, che non possono essere confusi tra loro. Le date
appartengono a tre grandi categorie:
• date relative alla documentazione (es. creazione del documento, dettatura,
firma, importazione nella cartella clinica);
• date relative all'evento di interesse sanitario (es.: appuntamento, esecuzione,
insorgenza, prelievo, incidente);
• date relative alla "consapevolezza", cioè quando l'autore della cartella clinica
è venuto a conoscenza del dato (es.: riportato dal paziente, lettura del referto,
osservazione diretta, conclusione diagnostica).
Nella maggior parte dei casi dei dati clinici correnti, tuttavia, i tre tipi di date spesso
coincidono o non sono significativamente distanti, e le conseguenze pratiche di
queste distinzioni sono limitate, anche grazie all'adozione di particolari
accorgimenti.
1.3.4 ICD
La Classificazione Internazionale delle Malattie, dove ICD sta per International
Classification of Diseases (www.who.int/classifications/icd/en), è un sistema di
classificazione nel quale le malattie e i traumatismi sono ordinati, per finalità
statistiche, in gruppi tra loro correlati.
Negli Stati Uniti, a partire dal 1979, un Comitato (in cui sono rappresentati le
associazioni professionali ed accademiche dei medici, le associazioni degli ospedali
e l'ufficio regionale dell’Organizzazione mondiale della sanità) ha sviluppato e
provvede ad aggiornare annualmente una versione modificata ed ampliata del
sistema ICD, la ICD9-CM ("International Classification of Diseases, 9th revision,
Clinical Modification"), la quale è stata utilizzata a partire dal 1979. Il termine
36
"clinical" è utilizzato per sottolineare le modifiche introdotte: rispetto alla ICD-9,
fortemente caratterizzata dall'orientamento a scopo di classificazione delle cause di
mortalità, la ICD-9-CM è soprattutto orientata a classificare i dati di morbilità.
Infatti, le principali modificazioni introdotte sono finalizzate a consentire sia una
classificazione più precisa ed analitica delle formulazioni diagnostiche, attraverso
l'introduzione di un quinto carattere, sia l'introduzione della classificazione delle
procedure.
La Classificazione ICD9 nella traduzione italiana predisposta e pubblicata a cura
dell'Istat, è stata utilizzata, ai sensi del Decreto del Ministero della Sanità 26 luglio
1993, per la codifica delle informazioni.
La classificazione ICD9-CM è finalizzata a tradurre in codici alfa-numerici i termini
medici in cui sono espressi le diagnosi di malattia, gli altri problemi di salute e le
procedure diagnostiche
e
terapeutiche. I
caratteri
fondamentali
di
tale
classificazione sono i seguenti:
• l'esaustività
tutte le entità trovano una loro collocazione, più o meno specifica, entro i
raggruppamenti finali della classificazione;
• la mutua esclusività
ciascuna entità è classificabile soltanto in uno dei raggruppamenti finali della
classificazione;
• il numero limitato di raggruppamenti
circa quindicimila codici consentono la classificazione delle diagnosi, dei
problemi di salute e delle principali procedure diagnostico-terapeutiche;
• la specificità dei raggruppamenti in ragione della rilevanza delle entità
nosologiche dal punto di vista della sanità pubblica
le entità nosologiche di particolare importanza per la sanità pubblica, o che si
verificano con maggiore frequenza, sono individuate da una specifica categoria;
37
tutte le altre entità nosologiche sono raggruppate in categorie non strettamente
specifiche, che comprendono condizioni differenti, benché tra loro correlate.
La struttura della classificazione ICD è determinata, poi, da due assi principali:
• l'eziologia;
• la sede anatomica.
I capitoli in cui si articola la classificazione riflettono i due assi principali: il criterio
eziologico determina i cosiddetti capitoli "speciali" (malattie infettive, traumi); il
criterio anatomico determina i capitoli cosiddetti "locali", ovvero riferiti ad una
specifica sede anatomica. In generale il criterio eziologico prevale su quello
anatomico, per cui le condizioni morbose sono in via prioritaria classificate in uno
dei capitoli speciali.
I codici presenti nella ICD9-CM relativi alle diagnosi sono costituiti da caratteri
numerici o alfanumerici, in numero di tre, quattro o cinque. Quando sono necessari
più di tre caratteri, si ricorre all’utilizzo di un punto decimale, che viene interposto
tra il terzo ed il quarto carattere.
I codici presenti nella ICD9-CM relativi alle procedure sono costituiti da caratteri
numerici, in numero di due, tre o quattro. Quando sono necessari più di due
caratteri, un punto decimale è interposto tra il secondo e il terzo.
Il sistema ICD9-CM contiene, pertanto, due classificazioni, una per le malattie ed
una per le procedure. Esso è costituito da tre parti:
1. Indice alfabetico delle malattie;
2. Elenco sistematico delle malattie;
3. Elenco alfabetico e sistematico delle procedure.
L'elenco sistematico e l'indice alfabetico delle due classificazioni sono concepiti per
integrarsi a vicenda.
38
L'indice
alfabetico
consente
l'agevole
ricerca
di
una
singola
voce.
L'elenco sistematico contiene, invece, tutte le indicazioni accessorie per verificare la
correttezza del codice attribuito.
Nel 1992 è stata, inoltre, completata la classificazione ICD10, una sorta di versione
ottimizzata ed aggiornata della ICD9, che ha visto i primi utilizzi pratici ad inizio
millennio, specialmente negli Stati Uniti. Inizialmente, si è utilizzata l’ICD10
prettamente per codifiche riguardanti la mortalità, mentre l’ICD9 per codifiche
concernenti la morbilità, ossia lo stato d’avanzamento delle malattie. Negli ultimi
anni sono state, poi, prodotte delle release riguardanti la codifica delle diagnosi
(ICD10-CM) e quella delle procedure (ICD10-PCS), che hanno portato al sempre
crescente ricorso alla classificazione ICD10, grazie alla presenza di nuove sezioni,
alla revisione radicale di alcuni settori dell’ICD9 e all’utilizzo di un codice
alfanumerico, e non più semplicemente numerico. Attualmente, però, soprattutto in
Europa, si tende ancora all’utilizzo dell’ICD9.
1.3.5 LOINC
La codifica LOINC (www.regenstrief.org/medinformatics/loinc) è stata sviluppata a
partire dal 1994 dal Regenstrief Institute For Health Care (organizzazione no-profit
di ricerca medica associata all’Università dell’ Indiana) e dalla LOINC Committee
per permettere il movimento elettronico di dati Clinici dai laboratori analisi che li
producono agli ospedali e studi medici. Tale codifica offre, infatti, un set standard
di nomi e codici per identificare i risultati clinici degli esami di laboratorio. Il
Regenstrief Institute For Health Care ha anche sviluppato una utility di nome
RELMA (Regenstrief LOINC Mapping Assistant), per facilitare la ricerca
all’interno del database LOINC. Ogni singolo LOINC record è caratterizzato da un
codice che può essere integrato nei messaggi in HL7 ed è descritto da sei campi,
definiti assi, riportati di seguito:
39
• Component: sostanza o entità misurata (es.: Potassio, Emoglobina, etc.);
• Kind of Property: caratteristica dell’ analita che è stato misurato (es.:
concentrazione, attività enzimatica, etc.);
• Time Aspect: intervallo di tempo durante il quale è stata effettuata la
misurazione (es.: 12h, 24h, etc.);
• System: tipo di campione su cui è stata effettuata la misurazione (es.: sangue,
urine, etc.);
• The type of Scale: scala di misura (es.: quantitativa, nominale, descrittiva,
etc.);
• Type of Method: procedura utilizzata per compiere l’osservazione.
Si ottengono, in questo modo, codici del tipo riportato nella seguente tabella:
Fig. 8: esempio di codici LOINC
1.3.6 DICOM
Lo standard DICOM, Digital Imaging And Communications In Medicine
(http://medical.nema.org), è stato creato dalla National Electrical Manufacturers
Association (NEMA) per promuovere la distribuzione e la visione delle immagini di
esami clinici, come ultrasuoni, risonanze magnetiche, PET, etc. Il precursore del
40
DICOM è stato lo standard ACR-NEMA, che prevedeva una standardizzazione
terminologica, una ben precisa e definita strutturazione ed un encoding dei file. Nel
1993, però, a seguito di numerose ottimizzazioni si è arrivati alla nascita del
DICOM, le cui specifiche sono state da subito suddivise in 9 “parti”, con l’aggiunta
di due capitoli che fissano i criteri secondo cui i file possono essere scambiati
attraverso supporti di memoria removibili come dischi e nastri.
Fig. 9: specifiche DICOM
Ciascuna di queste parti definisce una ben precisa specifica, come descritto di
seguito:
• Parte 1
contiene una panoramica dello standard stesso, con descrizione dei principi
basilari.
• Parte 2
41
viene fornita la definizione di conformità verso DICOM, cioè si richiede ai
costruttori di descrivere chiaramente come i loro apparecchi siano conformi
allo standard.
• Parte 3
formula la definizione degli oggetti di informazione (IOD), alcuni dei quali
potrebbero contenere gruppi di attributi simili, raccolti insieme in una serie
di moduli comuni. Tali oggetti composti sono per esempio un’immagine TC,
RM, NM, US, etc. e contengono attributi inerenti alla stessa entità del mondo
reale ed altri non inerenti.
• Parte 4
mostra le specifiche delle classi di servizi (SOP Class), che sono basate su
una serie di operazioni base, operanti su IOD. Tali classi di servizi sono:
certificazione, memorizzazione, richiamo/consultazione di immagini ed
informazioni, contenuto dello studio, gestione del paziente, gestione
dell'esame, gestione del referto, gestione della documentazione. Quando
un'applicazione DICOM genera una serie di dati, questa deve essere
decodificata per poter essere inserita in un messaggio per la comunicazione.
• Parte 5
le specifiche della codifica dati ed i relativi processi formano la quinta parte
di DICOM. La principale funzione di questa parte può essere definita come il
"linguaggio" che due apparecchi devono usare per comunicare (es.: formato
JPEG per la compressione delle immagini).
• Parte 6
è l'elenco completo di tutti gli elementi dei dati, insieme ai loro valori
numerici o alfanumerici.
• Parte 7
42
definisce ciò che è necessario al software applicativo per interagire con i
protocolli di comunicazione DICOM. Il formato base di un messaggio è
costituito da una stringa di comando ed una stringa di dati.
• Parte 8
il supporto di rete per il trasferimento dei messaggi è descritto nell’ottava
parte. In ambiente DICOM il protocollo di comunicazione utilizzato è il
TCP/IP, che rappresenta uno standard ormai molto diffuso che consente il
trasferimento di immagini e dati a prescindere dal mezzo fisico di
trasmissione in modo efficiente e coordinato. Data l'esistenza di molte reti di
comunicazione, realizzate secondo strategie differenti, la scelta di questo
standard rappresenta una soluzione ideale al trasferimento delle immagini
diagnostiche, sia a livello locale, che su rete metropolitana (MAN) o
geografica (WAN).
• Parte 9
sono raggruppate tutte le modalità relative ai vecchi protocolli punto-punto
ancora in uso presso vecchi sistemi.
Da un punto di vista strutturale, ogni singolo file DICOM presenta un header, che
contiene le informazioni riguardanti il nome del paziente, il tipo di esame, le
dimensioni dell’immagine, etc. e un body con i dati relativi all’immagine.
L’informazione contenuta nell’header è organizzata in gruppi. Ad esempio, il
gruppo 0002hex è il gruppo del file “meta information” e contiene tre elementi: uno
definisce la lunghezza del gruppo stesso, il secondo memorizza la versione del file e
l’ultimo definisce la sintassi di trasferimento. I tag vengono poi racchiusi, per
convenzione, tra parentesi quadre (es.: [7001,0010]LO; [7001,1001]UI) e
presentano anche dei codici che definiscono lo stato dell’elemento descritto, detti
“status codes” (es.: A700 - Out of Resources: indica che non vi è più spazio
sufficiente per memorizzare o processare l’immagine). Di seguito viene, quindi,
riportato un esempio esplicativo di file DICOM:
43
Fig. 10: file DICOM
Lo standard DICOM, inoltre, non definisce l’architettura dell’intero sistema, né
specifica requisiti funzionali ma facilita l’interoperabilità tra i sistemi informaticoclinici per bioimmagini tramite la definizione di:
• un set di protocolli da seguire che richiedono la conformità allo standard, per
le comunicazioni in rete;
• una sintassi dei comandi e le informazioni associate che possono essere
scambiate tramite l’utilizzo di tali protocolli;
• un set di funzioni per la memorizzazione dei file da seguire per la conformità
allo standard.
La necessità di rendere possibile tale interoperabilità deriva dal fatto che, spesso, i
sistemi informatici per definizione ed elaborazione di bioimmagini interagiscono
con
altri
devices
clinici,
per
cui
il
44
DICOM
deve
rendere
possibile
l’intercomunicabilità di tali dati tra le diverse aree del sistema informatico-sanitario.
Infatti, lo standard può essere considerato un’evoluzione del PACS (Picture
Archiving And Communication System), in quanto prevede l'interconnessione sia
meccanica che elettronica delle apparecchiature con costi e difficoltà minori ed una
manutenzione semplificata. Come si evince nella figura sottostante, in cui è
rappresentato lo schema di un dipartimento di immagini completamente
informatizzato, DICOM offre molteplici vantaggi. Infatti, esso consente sia
l’utilizzo di un unico sistema di documentazione (laser) e di memorizzazione, sia il
collegamento diretto bidirezionale ai sistemi informativi di reparto (RIS) ed
ospedialeri (HIS), oltre che la comunicazione all'esterno con altri ospedali o con
Internet.
Fig. 11: intercomunicabilità dei file DICOM
45
CAPITOLO 2: SVILUPPO PROGETTUALE
2.1 INTRODUZIONE
Il progetto del fascicolo sanitario elettronico per medici di base è stato ideato alla
ASUR Zona Territoriale N.7 di Ancona per rispondere alla forte necessità dei
medici di base, appunto, di poter disporre di uno strumento informatico diretto,
intuitivo, di facile approccio e personalizzabile, atto al supporto e all’ausilio
dell’attività medica.
Questa esigenza è particolarmente sentita dai medici che si trovano a gestire un gran
numero di pazienti e che, quindi, sentono la necessità di poter fruire di uno
strumento capace di organizzare in modo sistematico i numerosi dati, esami,
diagnosi, terapie, anamnesi, ricette, etc. che devono gestire giornalmente.
Le attuali tecnologie dell’informazione e della comunicazione possono permettere
di creare uno strumento simile, mettendo a disposizione dei medici di base una serie
di servizi e applicazioni che possano aiutarlo a far incontrare le sue esigenze e le sue
richieste con le risorse offerte dall’interfaccia progettata.
Tutto questo ha il duplice scopo di migliorare la qualità e l’efficienza dell’attività
medica e di permettere l’archiviazione, l’organizzazione e la strutturazione dei dati
sensibili dei pazienti assistiti in modo più sistematico. Lo sviluppo di queste nuove
46
tecnologie informatiche deve inoltre poter essere di complemento all’attività svolta
dal personale medico, alleggerendone il carico di lavoro.
Sulla base di tali considerazioni è stato sviluppato un Documento dei Requisiti per
il progetto del fascicolo sanitario per medici di base, diviso in tre sezioni principali:
• Sezione I: illustra a grandi linee il comportamento esterno del sistema: definisce i
requisiti funzionali e non funzionali del software da realizzare, sulla base delle
richieste dei medici di base, e specifica anche i vincoli ambientali che devono essere
rispettati.
• Sezione II: è destinato agli sviluppatori e formalizza le specifiche funzionali del
sistema.
• Sezione III: riporta la tracciabilità del progetto, ovvero una matrice che collega i
requisiti esposti nella seconda sezione con le componenti specifiche del sistema che
sono state definite per implementarli.
2.2 IL DOCUMENTO DEI REQUISITI
2.2.1. ELENCO DEI REQUISITI
• R1. Selezione mirata ed ottimizzata dei casi clinici e dei dati significativi
La gestione dei dati di tutti gli assistiti può diventare molto problematica,
considerando l’elevato numero di pazienti di un medico di medicina generale, sino a
1500 e più, e l’elevata mole di dati relativa ai casi di malattia cronica. E’ necessario,
quindi, presentare i dati degli assistiti in una forma semplificata che permetta non
solo di selezionare quelli più rilevanti, in relazione ad un determinato caso e ad un
determinato problema, ma anche di individuare quelli più urgenti. Attraverso
l’interfaccia dovrebbero così poter essere recuperati tutti i dati più significativi dei
47
casi clinici all’ordine del giorno e di tutti quelli che, a seguito di un aggiornamento
dei dati stessi, meritano un’attenzione maggiore.
• R2. Creazione semplificata della scheda clinica relativa ad un nuovo assistito
L’inserimento di un nuovo paziente nella lista degli assistiti del medico di base deve
avvenire in una forma semplificata. Ad esempio dev’essere possibile recuperare
immediatamente, in modo automatico, tutti i dati anagrafici del paziente,
specificando o il codice fiscale oppure nome, cognome, luogo e data di nascita
dell’assistito. Deve essere anche possibile recuperare eventualmente i dati del
fascicolo clinico del paziente, qualora questi siano stati precedentemente inseriti da
altri medici nel database dei fascicoli sanitari virtuali. Tali dati sono, infatti, presenti
all’interno di un middleware server che permette la condivisione dei dati del
paziente tra tutti i medici che lo hanno in cura.
• R3. Visualizzazione strutturata della cartella clinica
La visualizzazione dei dati della cartella clinica di un dato paziente deve avvenire in
maniera personalizzata e semplificata. La cartella clinica elettronica deve cioè
fornire delle viste particolari che dipendano dal caso esaminato ed eventualmente
anche da una serie di impostazioni definite dal medico di base stesso. I dati del
paziente dovrebbero poter essere strutturati sia nella forma classica (per sezioni
quali l’anamnesi, gli esami, le diagnosi, le terapie, le prescrizioni ed il diario
clinico) che in altre forme, ad esempio orientate ai problemi o secondo opportuni
ordini cronologici.
• R4. Rispetto delle norme sulla privacy
Si devono garantire dei livelli di sicurezza adeguati per l’accesso ai dati sensibili
degli assistiti. Le politiche di accesso a tali dati devono rispettare le norme sulla
privacy, consentendo, ad esempio, all’assistito di selezionare le persone che
possono fruirne, specificando i vari livelli di accesso.
• R5. Aggiornamento automatico ed assistito della cartella clinica
48
I dati contenuti all’interno della cartella clinica dovrebbero essere automaticamente
aggiornati con tutti i nuovi dati provenienti dal sistema sanitario, relativi al caso
clinico considerato (nuovi referti di esami di laboratorio e/o strumentali, diagnosi,
terapie e prescrizioni di medici specialisti, etc.). L’inserimento di nuovi dati da parte
del medico di base deve avvenire in modo assistito. L’interfaccia deve cioè
suggerire le sezioni da modificare, segnalare dei dati inseriti in modo errato, ed
eventualmente supportare anche la specifica della diagnosi e del nuovo intervento
terapeutico.
• R6. Firma digitale da apporre ai dati sensibili
Secondo i criteri giuridici che conferiscono al medico la responsabilità legale del
contenuto del fascicolo sanitario personale, deve essere possibile specificare e
accreditare la fonte dei dati in esso contenuti attraverso strumenti quali la firma
elettronica.
• R7. Stampa di ricette e certificati pre-compilati
L’interfaccia dovrebbe poter essere in grado di generare in modo semi-automatico
documenti medici stampabili, risparmiando al medico il tempo speso nell’attività
compilativa degli stessi.
• R8. Gestione della dispensa dello studio medico
È necessario poter gestire l’inventario del materiale sanitario e l’elenco completo
dei farmaci in modo informatizzato, attraverso una sezione dedicata dell’interfaccia.
• R9. Possibilità di accesso a risorse online per il supporto decisionale
L’interfaccia dovrebbe segnalare al medico tutte le risorse online che possono
aiutarlo ad inquadrare meglio il caso clinico esaminato e a scegliere il trattamento
terapeutico più idoneo. Tale supporto può tornare utile soprattutto in presenza di
patologie dalla difficile diagnosticazione o di esami clinici dall’incerta
interpretazione.
49
• R10. Informazione ed educazione del paziente
Attraverso l’interfaccia deve poter essere possibile selezionare una serie di risorse
consultabili dall’assistito, per educarlo sui rischi in cui può incorrere e sulle misure
da adottare per migliorare il proprio stile di vita. Tali risorse possono includere non
solo informative, guide e manuali ma anche veri e propri percorsi terapeutici con
obiettivi verificabili dallo stesso assistito.
2.2.2. VINCOLI AMBIENTALI
• V1. Interazione con il chatterbot
Per semplificare l'interazione con l'interfaccia, il medico potrebbe esprimere le
proprie richieste ed informazioni in linguaggio naturale. Ad esempio si potrebbe
utilizzare un chatterbot, ovvero un’interfaccia che riesca ad interpretare le domande
dell’utente rispondendo sia oralmente che in forma scritta, e modificando anche i
contenuti informativi visualizzati.
• V2. Separazione del contenuto dalla presentazione grafica
Verranno utilizzati, nello sviluppo dell'interfaccia grafica, i fogli di stile (CSS), per
garantire la corretta e uguale visualizzazione su tutti i browser e permettere l'utilizzo
di diversi dispositivi per la visualizzazione dell'interfaccia (non solo PC ma anche
PDA e cellulari).
• V3. Standard di rappresentazione dei risultati
I dati estratti dai moduli cartacei vanno rappresentati in formato XML; le
informazioni relative al layout del modulo vanno rappresentate in formato XSL-FO.
Il documento XML contenente i dati del modulo, unitamente al foglio di stile XSLFO, consentirà di produrre una copia elettronica del modulo in formato PDF.
• V4. DBMS utilizzato
50
Verrà utilizzato un database MySQL per l’archiviazione dei dati.
• V5. Trasmissione sicura dei dati
Per la trasmissione in sicurezza dei dati verrà utilizzata la tecnologia SSL.
• V6. Requisito di portabilità
L’applicazione web che implementa il sistema di gestione dei dati si deve basare
sulle tecnologie Java e JSP.
2.2.3 FUNZIONALITÀ PREVISTE
Sulla base dei requisiti delineati, è stato così sviluppato l’elenco completo delle
funzionalità previste per il fascicolo sanitario per medici di base.
A riguardo, un primo passo importante è stata la realizzazione dello use case model
riportato di seguito e, in versione ottimizzata, nel cd-rom allegato alla tesi:
Fig. 12: use case model
51
Successivamente si è passati alla stesura vera e propria delle funzionalità:
• F1. AUTENTICAZIONE
-
Descrizione: permette l’identificazione del medico che accede ai dati sensibili
degli assistiti.
-
Input: inserimento Username e Password.
-
Sorgente: form per l’inserimento dei dati necessari all’autenticazione (Username
e Password).
-
Output: nessuno.
-
Destinazione: nessuna.
-
Requisiti: caricamento del driver di connessione al database MySQL.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
• F2. ACCESSO A CARTELLE CLINICHE
-
Descrizione: permette al medico di accedere alla sezione riguardante le cartelle
cliniche dei propri pazienti.
-
Input: comandi impartiti dall’utente.
-
Sorgente: pulsantiera interfaccia Assistente Personale.
-
Output: nessuno.
-
Destinazione: nessuna.
-
Requisiti: nessuno.
-
Pre-condizioni: autenticazione.
-
Post-condizioni: nessuna.
-
Effetti collaterali: nessuno.
• F3. REGISTRAZIONE PAZIENTE
52
-
Descrizione: nel caso in cui il medico di base riceva un nuovo paziente, può
registrarlo e crearne la relativa cartella clinica, inserendo successivamente le
voci di ogni suo campo e di ciascuna sezione prevista.
-
Input: insieme di dati di vario tipo (String, Char, …).
-
Sorgente: form per l’inserimento dei dati relativi al nuovo paziente.
-
Output: nuovo record all’interno del database centrale.
-
Destinazione: base di dati MySQL.
-
Requisiti: caricamento del driver di connessione al database MySQL.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
• F4. VISUALIZZAZIONE LISTA C.C.
-
Descrizione: permette la visualizzazione delle liste dei casi più urgenti e di
quelli programmati nel calendario delle visite.
-
Sorgente: comandi impartiti da mouse o tastiera dall’utente.
-
Output: selezione di una parte lista di assistiti.
-
Destinazione: browser.
-
Requisiti: caricamento del driver di connessione al database MySQL;
caricamento del file XML contenente la lista degli assistiti ed i criteri di
visualizzazione.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
• F5. VISUALIZZAZIONE SINGOLA C.C.
-
Descrizione: una volta selezionato dalla lista un dato assistito, il medico può
visualizzare determinate sezioni della sua cartella clinica, anche in base al
problema in esame.
53
-
Input: selezione dell’assistito.
-
Sorgente: pagina JSP relativa alla lista degli assistiti.
-
Output: apertura della cartella clinica dell’assistito selezionato.
-
Destinazione: browser.
-
Requisiti: caricamento del driver di connessione al database MySQL e del file
XML contenente le sezioni della cartella ed i criteri di visualizzazione.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
¾ F5.1. ANAGRAFICA. Tale sezione comprende diverse voci tra le quali: dati
strettamente anagrafici (Nome, Cognome, Data di nascita, Sesso, etc.), recapiti
(Indirizzo, Telefono, Mail, etc.), dati sanitari principali (Codice SSN, ASL di
appartenenza, etc.) e descrizione del nucleo familiare di appartenenza.
¾ F5.2. ANAMNESI. Consta di tre sottogruppi:
9 F5.2.1. FISIOLOGICA. Si divide in più sezioni: Generale (parametri
vitali, gruppo sanguigno, etc.), Sportiva (elenco sport praticati, livello di
agonismo, frequenza), Abitudini (abitudini alimentari, tabagismo, consumo di
alcool, stupefacenti, etc.), Handicap (se il paziente presenta qualche handicap),
Esenzioni, Occupazione lavorativa, Allergie, Vaccinazioni effettuate, sezione
Ostetrico-Ginecologica (per le donne).
9 F5.2.2. REMOTA. Comprende una descrizione di tutte le patologie
passate relative al paziente, con riferimento alla diagnosi, alle terapie attuate, agli
esami effettuati, ai farmaci somministrati e alla definizione dello stato attuale
della patologia (attiva, risolta, cronica).
54
9 F5.2.3. FAMILIARE. Contiene i parametri vitali di riferimento dei
membri del nucleo familiare del paziente e un elenco delle patologie (in atto,
passate o croniche) e delle allergie dei parenti più stretti. Questa sezione è di
particolare interesse per identificare eventuali ereditarietà in riferimento a
patologie in atto.
9 F5.2.4. PROSSIMA. Contiene una descrizione dei problemi riscontrati
durante la visita del paziente, specificando quelli di natura soggettiva, cioè i
disturbi percepiti dal paziente, e quelli di natura obiettiva, ossia i problemi
effettivamente riscontrati dal medico.
¾ F5.3. TERAPIE. In questa sezione rientra l’elenco delle cure farmacologiche a
cui il paziente è sottoposto, degli esami prescritti, e di tutte le altre terapie
previste dal medico relativamente ad una determinata patologia.
¾ F5.4. ESAMI/ANALISI. Sono ivi presenti tutti i dati e i file relativi ad analisi
di laboratorio ed esami strumentali. Ad esempio, sono contenute in questa
sezione bioimmagini (radiografie, ecografie, etc.), tracciati (ECG, EEG, etc.),
tabelle riportanti i valori delle analisi emocromocitometriche, etc. Inoltre è
prevista la presenza di referti testuali e i tracciati relativi all’andamento
temporale dei valori dei parametri vitali e fisiologici.
¾ F5.5. DIARIO CLINICO. In questa sezione vengono segnalati tutti i sintomi
presentati dal paziente, relativamente ad una certa data, e la diagnosi emessa dal
medico di base. Il diario clinico può contenere anche delle annotazioni (testo
libero).
• F6. MODIFICA DATI C.C.
-
Descrizione: il medico può modificare i dati di ciascuna sezione (Anagrafica,
Anamnesi, Diario del paziente, etc.) nei casi in cui si manifestino cambiamenti
nel quadro clinico dell’assistito.
55
-
Input: insieme di dati di vario tipo (String, Char, …).
-
Sorgente: form per l’inserimento dei dati da modificare.
-
Output: aggiornamento record con modifiche apportate.
-
Destinazione: base di dati MySQL.
-
Requisiti: caricamento del driver di connessione al database MySQL.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
• F7. MODIFICA RISORSE PAZIENTE
-
Descrizione: il medico, nell’area web dell’Assistente Personale fruibile e
accessibile ai pazienti, ha modo di apportare modifiche, aggiungere elementi o
file, inserirvi avvisi e/o memo importanti per l’assistito, …
-
Input: insieme di dati di vario tipo (String, Char, …).
-
Sorgente: form per la selezione delle risorse da visualizzare.
-
Output: aggiornamento record con modifiche apportate.
-
Destinazione: base di dati MySQL.
-
Requisiti: caricamento del driver di connessione al database MySQL.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
• F8. GENERAZIONE RAPPORTI STAMPABILI
-
Descrizione: questa sezione è di notevole interesse, in quanto permette al
personale medico di risparmiare il tempo speso nella scrittura manuale di
innumerevoli ricette e certificati vari (di sana e robusta costituzione, di malattia,
etc.). Infatti, per quanto riguarda ad esempio le ricette, il medico, che sta
visualizzando la cartella clinica del paziente in visita, accede alla sezione
“ricette e certificati” e in automatico il sistema riporta sul modello della ricetta
56
da stampare tutta l’anagrafica dell’assistito in questione e l’intestazione
riguardante i dati del medico stesso; poi, se si vuole sottoporre il paziente ad un
esame diagnostico, basta selezionarlo dall’elenco degli esami nella sezione
“esami e analisi” o “ terapie” e in automatico il sistema riporta la prescrizione
sul modello della ricetta. Analogamente avviene con la prescrizione di un
farmaco, andandolo a selezionare dalla sezione “terapie”. A questo punto si
avvia la stampa e si genera una ricetta già completa.
-
Input: insieme di dati di vario tipo (String, Char, …).
-
Sorgente: form per la creazione di documento stampabile.
-
Output: documento stampabile completo.
-
Destinazione: browser.
-
Requisiti: caricamento del driver di connessione al database MySQL.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
• F9. PERSONALIZZAZIONE INTERFACCIA
-
Descrizione: con questa funzione il medico ha modo di apportare alcune
modifiche e variazioni a livello di layout, posizionamento ed ordinamento delle
aree consultabili, … In tal modo si può creare un aspetto grafico dell’interfaccia
più intuitivo, in base alle esigenze e alle preferenze dell’operatore medico che ne
fa uso.
-
Input: selezione effettuata dall’utente.
-
Sorgente: form per la personalizzazione dell’interfaccia.
-
Output: aggiornamento XML, con i criteri di personalizzazione effettuati
dall’utente.
-
Destinazione: base di dati MySQL.
-
Requisiti: caricamento del driver di connessione al database MySQL.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
57
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
• F10. RECUPERO INFO PER SUPPORTO DECISIONALE
-
Descrizione: l’interfaccia, in base alla patologia dell’assistito analizzata dal
medico, è in grado di reperire dalle risorse web del database centrale le diagnosi
simili a quella in analisi. Tali diagnosi, per chiari motivi di tutela della privacy,
vengono riportate e richiamate in forma anonima, sia per quanto riguarda il
paziente a cui si riferiscono sia in riferimento al medico che le ha prodotte.
-
Input: rappresentazione del caso clinico esaminato.
-
Sorgente: modulo estrazione conoscenza.
-
Output: recupero diagnosi di casi simili.
-
Destinazione: browser.
-
Requisiti: caricamento del driver di connessione al database MySQL.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
• F11. ACCESSO AL DISPENSARIO
-
Descrizione: in questa sezione il medico può avere accesso ad una sorta di
inventario di tutto il materiale a sua disposizione (farmaci, campioni, materiale
sanitario). Con dei sistemi di Alert è inoltre possibile creare avvisi in caso di
esaurimento.
-
Input: criteri di ricerca impostati dall’utente.
-
Sorgente: pagina JSP.
-
Output: lista del materiale sanitario e farmacologico a disposizione.
-
Destinazione: browser.
-
Requisiti: caricamento del driver di connessione al database MySQL.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
58
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
¾ F11.1. VISUALIZZAZIONE SCORTE. Il medico ha modo di visualizzare
l’elenco del materiale sanitario a sua disposizione nello studio medico.
Attraverso la possibilità di personalizzazione dell’interfaccia, l’operatore
sanitario può anche decidere in che modo organizzare e gestire la visualizzazione
dell’inventario.
¾ F11.2. AGGIORNAMENTO SCORTE. Ogni nuovo rifornimento di scorte
può essere inserito e memorizzato nell’interfaccia, così da poter poi visualizzare,
nella sezione di cui al punto precedente (F11.1.), il materiale sanitario arrivato.
• F12. AGGIORNAMENTO LISTA FARMACI
-
Descrizione: prevede un periodico aggiornamento automatico della lista dei
farmaci prescrivibili.
-
Input: comando impartito dall’utente tramite mouse o tastiera.
-
Sorgente: database remoto.
-
Output: lista dei farmaci aggiornata.
-
Destinazione: base di dati MySQL.
-
Requisiti: caricamento del driver di connessione al database MySQL.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
• F13. ACCESSO AL MOTORE DI RICERCA
-
Descrizione: l’interfaccia prevede l’utilizzo di un motore di ricerca
personalizzato, per permettere il recupero dei risultati sulla base del profilo del
medico.
-
Input: criteri di ricerca specificati dall’utente.
59
-
Sorgente: form HTML.
-
Output: risultati della ricerca effettuata.
-
Destinazione: base di dati MySQL.
-
Requisiti: caricamento del driver di connessione al database MySQL.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
• F14. ACCESSO AL FORUM
-
Descrizione: il medico può accedere al forum di discussione, scambiando pareri
ed opinioni mediche con altri medici della ASL ed offrendo un servizio di
consulto per i propri assistiti. Inoltre, successivamente all’inserimento di un
quesito nel forum, il sistema è in grado di andare ad individuare tutte le risposte
dal contenuto simile, presenti nel database. In questo modo è possibile ricevere
una risposta in minor tempo, senza dover aspettare quella diretta dei partecipanti
al forum.
-
Sorgente: form HTML.
-
Output: visualizzazione del forum.
-
Destinazione: base di dati MySQL.
-
Requisiti: caricamento del driver di connessione al database MySQL.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
• F15. ACCESSO A PUBMED
-
Descrizione: il medico può accedere al sito di PubMed, da cui poter leggere e
scaricare articoli pubblicati, relativamente all’ambito medico o alla patologia
d’interesse.
-
Input: criteri di ricerca specificati dall’utente.
60
-
Sorgente: form HTML.
-
Output: visualizzazione testo di articoli archiviati in PubMed.
-
Destinazione: browser d’utilizzo.
-
Requisiti: importo API per ricerca archivio PubMed.
-
Pre-condizioni: apertura connessione con database remoto di PubMed.
-
Post-condizioni: chiusura connessione con database remoto di PubMed.
-
Effetti collaterali: nessuno.
• F16. FIRMA
-
Descrizione: la firma di documenti clinici è di fondamentale importanza, in
quanto il medico ricoprire un ruolo di forte responsabilità nella compilazioni e
modifica dei dati delle cartelle cliniche. Queste, infatti, sono ritenute, a livello
giuridico, atti pubblici, rispetto ai quali il personale medico ricopre il ruolo di
pubblico ufficiale.
-
Input: chiave privata, Certification Authority, digest e timestamp dei dati in
formato xml.
-
Sorgente: Smart Card.
-
Output: firma elettronica dei dati creati, gestiti o modificati.
-
Destinazione: database centrale.
-
Requisiti: caricamento dei driver di connessione a MySQL e caricamento dei
driver della Smart Card.
-
Pre-condizioni: apertura di una connessione sicura con il database centrale
MySQL.
-
Post-condizioni: chiusura della connessione sicura con il database centrale.
-
Effetti collaterali: nessuno.
61
2.2.4 MATRICE DI TRACCIABILITÀ
Il Documento dei Requisiti prevede, alla fine, anche la rappresentazione di una
matrice di tracciabilità, per verificare il soddisfacimento dei requisiti e dei vincoli
ambientali tramite le funzionalità previste in fase di progetto:
R1
R2
R3
R4
R5
R6
R7
R8
R9
R10
V1
V2
V3
V4
V5
V6
F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15 F16
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
Fig. 13: matrice di tracciabilità
2.3 CDA DI LABORATORIO
Dopo la stesura del Documento dei Requisiti, si è passati alla realizzazione del
documento clinico di laboratorio e alla sua implementazione.
La cartella clinica di un dato paziente contiene infatti, sotto la sezione esami, anche
tutti i referti degli esami di laboratorio effettuati, disposti in ordine cronologico.
Lo sviluppo di tale documento ha previsto una prima fase di analisi e studio delle
diverse tipologie di esami clinici effettuabili da qualsiasi unità analisi ospedaliera o
centri analisi della ASUR o privati.
62
Successivamente è stata predisposta una tabella costituita dall’insieme dei principali
valori misurabili ed analizzabili, presenti sui documenti di laboratorio di tutti i
centri analisi presi in considerazione e suddivisi per gruppi:
• valori emocromocitometrici;
• velocità di eritrosedimentazione;
• prove emocoagulative;
• gruppi ematici;
• tests immunologici;
• markers per epatite A, B, C;
• valori chimico-clinici;
• esame delle urine;
• esame chimico;
• esame microscopico.
Dopo la definizione di un file .doc riportante la tabella nella sua interezza, si è
generato il relativo foglio di stile XSL-FO, attraverso una trasformazione con
Microsoft Word.
A questo punto l’attenzione si è spostata sulla realizzazione di un file XML, nel
rispetto dei vincoli strutturali imposti da HL7 e tramite l’utilizzo delle codifiche
LOINC. Il file consta, pertanto, di due sezioni: un Header ed un Body. Nella prima
parte sono definiti gli aspetti generici identificativi del documento, il medico che ha
effettuato le analisi, il laboratorio in cui sono state fatte e in cui vengono conservate
ed il paziente che si è sottoposto agli esami clinici in questione. Le voci
identificative codesystem, presenti nell’Header, sono state riempite con i
corrispettivi codici OID, sottorami del relativo ramo riferito ad HL7
(www.alvestrand.no/objectid/2.16.840.1.113883.html), ossia:
2.16.840.1.113883. xxx
63
Concluso l’Header, si è passati alla stesura del Body, riportante i dati relativi agli
esami e ai valori clinici analizzati. In questa fase è risultato molto utile l’utilizzo del
programma RELMA LOINC, che ha coadiuvato l’attività di ricerca ed
identificazione dei codici LOINC, relativi ai rispettivi valori degli esami di
laboratorio effettuati. Nel Body sono pertanto presenti tutte le informazioni
riguardanti i valori clinici presi in considerazione: data ed ora della misurazione,
range di riferimento, valore effettivo, unità di misura, …
Per una più chiara visione di quanto descritto, in appendice è riportato l’intero file
XML.
Successivamente si è passati allo studio del foglio di stile relativo alla tabella finale
del CDA di laboratorio che si desidera ottenere. Il problema principale ha riguardato
l’identificazione della corretta definizione sintattica del percorso di richiamo dei
valori dell’XML, motivo per cui ci si è avvalsi del linguaggio di markup XPATH,
che ha reso possibile l’esatta individuazione dei nodi dell’XML. Una Path
Expression è, infatti, scritta come una sequenza di passi per raggiungere un nodo
XML, partendo dal nodo corrente (percorso "relativo"). In alternativa è possibile
utilizzare dei percorsi "assoluti" utilizzando come riferimento la radice del
documento. Ad esempio, riferendoci al valore relativo agli Eritrociti, presente
nell’XML:
<!-- Primo valore: ERITROCITI -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="11273-0" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="ERITROCITI"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 5.45 -->
<value xsi:type="PQ" value="5.45" unit="10*6/mm3"></value>
<interpretationCode code="N"
codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="4.50" unit="10*6/mm3"></low>
64
<high value="6.00" unit="10*6/mm3"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
lo si può richiamare attraverso la seguente Path Expression:
<xsl:value-of select="ClinicalDocument/component/StructuredBody/component/
section/entry/Act[code/@displayName='ESAME EMOCROMOCITOMETRICO']
/entryRelationship/organizer[code/@displayName='ESAME
EMOCROMOCITOMETRICO']/component/observation[code/@displayName='ERI
TROCITI']/value/@value"></xsl:value-of>
In questo modo è stato possibile richiamare nell’XSL-FO tutti i relativi valori clinici
contenuti nell’XML.
Lo scopo finale è quello della realizzazione di un referto clinico in formato PDF,
facilmente visualizzabile e stampabile. Pertanto si è ricorsi ad un’applicazione
Java, che ha permesso l’implementazione dei file XML ed XSL con Apache FOP, il
quale prende in input i suddetti file, producendo in uscita un PDF riportante la
tabella completa contenente i risultati dell’esame di laboratorio effettuato.
In appendice viene riportato il referto in PDF, così come viene prodotto attraverso
l’applicazione FOP.
Inoltre, alla tesi è allegato un cd-rom contenente i file XML, XSL-FO,
l’applicazione Java utilizzata e il PDF che si ottiene.
2.4 SVILUPPO DELLE SEZIONI ANAGRAFICA ED
ANAMNESICA
Nelle cartelle cliniche relative ad ogni singolo paziente, due delle sezioni di
65
maggior
importanza
riguardano
le
pagine
anagrafiche,
necessarie
per
l’identificazione e l’indicizzazione dei pazienti tenuti in cura dai vari medici di
base, e quelle anamnesiche, che delineano un quadro generale e d’insieme della vita
clinica degli assistiti.
Nella fase di studio e sviluppo di tali sezioni, da implementare nel fascicolo
sanitario, sono stati analizzati e comparati i seguenti software per la gestione di
documenti e fascicoli clinici:
• “Studio Medico”: software prodotto dalla SoftVision per la gestione degli
studi di medici di base;
• “Anamnesi”: programma sviluppato dalla Meeting Point Internet & Software
Solutions di Mantova;
• “Medico 2000”: software realizzato dalla Mediatec Informatica di Rovigo;
• “Cartella Clinica Bracco”: programma della DS Medigroup di Milano;
• “Pagellium”: software elaborato dal Dott. Pagelli della ASUR zona
territoriale n.7 di Ancona.
L’attività di studio e analisi di tali programmi si è basata in una prima fase di
comparazione parallela delle sezioni anagrafiche ed anamnesiche di ciascun
software, per poter individuare la totalità di voci e valori clinici in esse presenti, per
riportarle, poi, in fase di sviluppo, nelle relative pagine del fascicolo sanitario.
Pertanto, la seconda fase del lavoro ha riguardato la stesura di progetto delle pagine
anagrafiche ed anamnesiche, ponendo particolare attenzione sul layout e sui
contenuti presenti, sulla base dello studio preliminare delle relative sezioni dei
software sopra citati.
Una prima stesura cartacea è stata seguita da una realizzazione ed implementazione
informatica, con la collaborazione di un altro tirocinante.
Analizzando nel dettaglio la fase preliminare di analisi, sono riportati di seguito
alcuni esempi del lavoro comparativo tra i vari programmi informatico-clinici
studiati e del successivo sviluppo implementativo.
Per quanto riguarda la sezione anagrafica, i software contengono tutti pressappoco
66
le stesse voci: nome, cognome, indirizzo, data e luogo di nascita, recapiti, etc. . A
queste si aggiungono dati identificativi quali codice fiscale e numero di tessera
sanitaria, oltre che i campi relativi alla Asl di appartenenza. Prendendo in
considerazione, per esempio, “Studio Medico”, “Medico 2000” e “Anamnesi”, il
layout e i campi relativi all’anagrafica di un paziente sono mostrati nelle seguenti
figure:
Fig.14: pagina anagrafica di “Studio Medico”
67
Fig.15: pagina anagrafica di “Medico 2000”
Fig.16: pagina anagrafica di “Anamnesi”
Pertanto, sulla base dell’analisi di tali interfacce, si è passati alla stesura del layout e
dei campi da inserire nella pagina anagrafica da implementare nel fascicolo
68
sanitario in via di sviluppo, con la successiva implementazione che ha portato al
seguente risultato:
Fig.17: pagina anagrafica sviluppata
Analizzando la figura 17, si evince immediatamente la presenza di alcune voci che
esulano dai comuni e condivisi campi anagrafici dei software analizzati. Infatti, è
presente un campo “Nucleo Familiare”, seguito da un pulsante di ricerca, che
permette l’individuazione immediata delle cartelle cliniche di altri assistiti, correlati
al paziente in analisi da vincoli di parentela. Questo può avvenire grazie alla
69
possibilità di indicizzazione dell’elenco assistiti per nucleo familiare, aspetto di
importanza rilevante ai fini dell’analisi e dell’individuazione di possibili ereditarietà
di certe patologie. Inoltre, a fondo pagina, è presente una finestra riguardante le
esenzioni, con un menu a cascata che permette di identificare quella di interesse dal
database implementato. Tale aspetto è utile, ad esempio, ai fini della produzione
automatica di rapporti stampabili quali le ricette.
Un analogo lavoro comparativo è stato effettuato anche per tutte le pagine
riguardanti l’Anamnesi: si è studiato il layout dei vari software, i campi e le voci
riportate, per poi pensare, su tale base, alle modalità di sviluppo delle relative
pagine per il fascicolo sanitario. È da notare che si è sempre posta attenzione sulle
possibili aree ed i possibili campi addizionali da poter inserire, in modo tale da
offrire un valore aggiunto ai medici di base nella gestione dei dati clinici dei loro
assistiti.
Riferendoci sempre ad un caso d’esempio, mostriamo le pagine concernenti
l’Anamnesi Fisiologica dei software analizzati precedentemente per l’anagrafica:
Fig.18: Anamnesi Fisiologica di “Medico 2000”
70
Fig.19: Anamnesi Fisiologica di “Anamnesi”
Per quanto riguarda, invece, “Studio Medico”, la sezione relativa all’Anamnesi
Fisiologica viene suddivisa in diverse pagine (generale, sportiva, abitudini, …),
come si evince dalla seguente immagine:
Fig.20: Anamnesi Fisiologica di “Studio Medico”
Sulla base di tali analisi, si è passati, come per la parte anagrafica, allo sviluppo
delle pagine dell’Anamnesi Fisiologica per il fascicolo sanitario. Si sono ottenute,
così, le tre pagine riportate di seguito:
71
Fig.21: Anamnesi Fisiologica, pag.1
Fig.22: Anamnesi Fisiologica, pag.2
72
Fig.23: Anamnesi Fisiologica, pag.3
Anche in questo caso sono state inserite, oltre alla totalità dei campi presenti in
ciascuno dei software analizzati, alcune voci ulteriori, tali da caratterizzare e
rendere più peculiari l’interfaccia e le funzionalità offerte dal fascicolo sanitario
sviluppato. Ad esempio, sulla base del consulto con medici del 118, sono state
inserite nella prima pagina le voci: “Saturazione”, “Pulsazione”, “Pressione Max” e
“Pressione min”, in quanto sono alcuni dei cosiddetti parametri vitali, di cui è di
fondamentale importanza saperne i valori in condizioni stazionarie, ossia non
patologiche, così da rilevare in modo immediato e tempestivo qualsiasi loro
variazione, dovuta ad eventuali nuovi fattori patologici.
Ulteriore valore aggiunto apportato all’interfaccia sviluppata riguarda la presenza di
una funzionalità “Personalizza”, che permette al medico di decidere quali voci e
quali campi visualizzare o meno, in modo da rendere l’applicazione di approccio
immediato e friendly, in base alle esigenze del medico stesso che ne fruisce.
In appendice vengono, quindi, riportate tutte le pagine anagrafiche ed anamnesiche
prodotte ed implementate nel fascicolo sanitario, con un simile approccio analitico,
comprese la “Home Page”, la pagina di registrazione di un nuovo utente, quella di
login, etc.
73
CAPITOLO 3: CONCLUSIONI
L’informatica medica sta ormai assumendo un ruolo basilare all’interno delle
strutture sanitarie ed ospedaliere. Molti dei più grossi ospedali e policlinici si
affidano ormai a sistemi PACS, a reti di comunicazione interne, ad archiviazione
digitale di esami per bioimmagini, etc. Anche nelle ASL l’attenzione si sta
focalizzando sullo sviluppo di software e applicativi per la gestione telematica dei
dati clinici degli assistiti, sempre in accordo con gli obblighi previsti dalla Legge
sulla Privacy. La ASUR zona territoriale n.7 di Ancona ha deciso, quindi, di
adeguarsi a questa informatizzazione dei servizi sanitari, portando avanti un
progetto d’avanguardia, innovativo e di grande utilità: il progetto “Assistente
Personale”. In questo modo, come descritto nel Documento dei Requisiti al
precedente capitolo, si vogliono fornire e mettere a disposizione di assistiti e medici
enormi potenzialità e vantaggi. I pazienti potranno, infatti, consultare risultati
clinici, prescrizioni o consigli del proprio medico online, eliminando la necessità di
recarsi in ambulatorio anche semplicemente per ritirare un’analisi, riducendo le
visite cliniche ai casi più seri ed urgenti, abbattendo così i tempi di attesa. Una
proposta avanzata, per uno sviluppo futuro a tal riguardo, è quella di munire i
poliambulatori di “totem” recanti al loro interno dei PC connessi al portale di
Assistente Personale, tramite cui ogni paziente può ricevere un primo consulto,
grazie all’assistente virtuale (chatterbot) che è stato già sviluppato e implementato.
Il progetto portato avanti durante lo stage di formazione apporterà enormi benefici
soprattutto all’attività ambulatoriale, in quanto i medici disporranno di informazioni
74
cliniche in modo integrato, ricerche e pratiche cliniche recenti, avvisi immediati e
memo concernenti la gestione degli assistiti, accesso a risorse e letteratura medica di
vario tipo, possibilità di fornire online consulti generici ai pazienti, prima di
eventuali visite ambulatoriali, disponibilità di accesso a qualsiasi dato diagnosticoclinico relativamente a ciascun assistito. Il medico, infatti, è in grado, in ogni istante
e nel rispetto della privacy del paziente, di conoscere tutte le informazioni cliniche
di cui ha bisogno per gestire il caso, indipendentemente da dove i dati siano stati
prodotti. Se necessario, inoltre, ovviamente solo con il consenso del paziente, i dati
possono essere trasferiti per via telematica anche ad altre strutture di ricovero e cura
alle quali il paziente si trovi a dover accedere durante un determinato percorso
diagnostico-terapeutico. Questo proprio grazie all’utilizzo di standard quali XML ed
HL7, la “lingua” internazionale dei sistemi informativi sanitari, utilizzati anche
nello sviluppo applicativo del referto degli esami clinici di laboratorio, come
descritto nel precedente capitolo.
È chiaro ed evidente, quindi, che un progetto di tale portata, e con tali
benefici e potenzialità, apporta enormi migliorie anche in termini di qualità delle
prestazioni cliniche. Infatti, due parole chiave in Sanità, a riguardo, sono
l’efficienza e l’efficacia dei servizi erogati. Un’implementazione informatica
dell’attività
clinica,
pertanto,
non
può
essere
altro
che
un
incentivo
all’ottimizzazione dell’output e, di conseguenza, dell’outcome dei servizi messi a
disposizione, che si traducono poi in soddisfazione del cliente (gli assistiti).
Il prosieguo del progetto e dello sviluppo di Assistente Personale e, nello
specifico, del fascicolo sanitario elettronico si baserà, quindi, sulla definizione di
applicazioni e funzioni mirate al sempre crescente supporto all’attività medica e, più
o meno indirettamente, al raggiungimento di una piena soddisfazione del cliente.
Si possono prefigurare, pertanto, innumerevoli vie e strade di sviluppi futuri.
Una tra queste, tra l’altro già seguita da diverse strutture ospedaliere, è quella di
fornire i medici in corsia di Pocket PC, da cui poter accedere ad Assistente
Personale e consultare in tempo reale dati, esami e referti relativi ai pazienti
ricoverati. Per quanto riguarda i medici di base, si può prevedere, come già
ipotizzato in altri progetti a livello regionale o locale, la fornitura di palmari da cui
75
consultare una versione di Assistente Personale dedicata e specifica per questo tipo
di supporto tecnologico.
Le strade di sviluppo dell’informatizzazione di cartelle cliniche e fascicoli
sanitari sono, dunque, innumerevoli. Il problema, purtroppo, risiede spesso nella
mancanza di fondi stanziati, nella poca fiducia in progetti forse troppo innovativi
per essere compresi fino in fondo, nella scarsa vision e intraprendenza di alcuni
dirigenti sanitari e, soprattutto, nella ancor poca apertura del personale medico verso
supporti e tecnologie d’avanguardia di sostegno all’attività clinica.
76
APPENDICE A: XML DEL CDA DI LABORATORIO
<?xml version="1.0" encoding="UTF-8"?>
<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:hl7-org:v3 file:/C:/Documents and
Settings/Administrator/Desktop/provaXSL/CDA.ReleaseTwo.CommitteeBallot03.Aug.2004B.xsd">
<!-********************************************************
CDA Header
********************************************************
-->
<id extension="c266" root="2.16.840.1.113883.3.933"></id> <!-- QIdentificativo univoco dell'istanza del
documento. Non ci sono convenzioni da adottare -->
<code code="11488-4" codeSystem="2.16.840.1.113883.6.1" displayName="Consultation note"></code>
<title>Referto Analisi del Sangue</title>
<effectiveTime value="20070124"></effectiveTime>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"></confidentialityCode> <!-Normali regole di accesso al documento. Può essere consultato da personale autorizzato per motivi di ordine
medico o amministrativo -->
<languageCode code="ita" codeSystemName="2.16.840.1.113883.6.121"></languageCode>
<author>
<time value="20070124"></time>
<assignedAuthor>
<id extension="XXXXXXXXXXXXXXXX"></id> <!-- Codice fiscale dell'autore del documento. -->
<assignedPerson>
<name>
<given>Pinco</given>
<family>Pallino</family>
<suffix>Dr</suffix>
</name>
</assignedPerson>
<representedOrganization>
<name>Polo Ospedaliero di Loreto</name>
<telecom>071750916291</telecom>
<addr>via S.Francesco (Loreto, AN)</addr>
</representedOrganization>
</assignedAuthor>
</author>
<custodian>
<assignedCustodian>
<representedCustodianOrganization>
<id extension="XXXXXXXXXXXXXXXX"></id> <!-- Identificativo univoco dell'azienda che esegue
le analisi ed è responsabile del trattamento degli stessi. -->
<name></name> <!-- Nome dell'azienda che conserva i dati -->
<telecom></telecom>
<addr></addr>
</representedCustodianOrganization>
</assignedCustodian>
</custodian>
<recordTarget>
<patientRole>
<id extension="LLLLGU75E28C615S"></id> <!-- Codice fiscale del soggetto cui i dati presenti nel
body si riferiscono. -->
<addr>
<streetName>via Avvenati</streetName>
77
<houseNumber>8</houseNumber>
<postalCode>60129</postalCode>
<city>Ancona</city> <!-- Una possibile alternativa è data dal relativo codice ISTAT -->
<state>Ancona</state> <!-- Una possibile alternativa è data dal relativo codice ISTAT -->
<country>ITALY</country>
</addr>
<telecom value="07134835"></telecom>
<patientPatient>
<administrativeGenderCode code="M"
codeSystem="2.16.840.1.113883.12.1"></administrativeGenderCode>
<maritalStatusCode code="S" codeSystem="2.16.840.1.113883.12.2"></maritalStatusCode>
<religiousAffiliationCode code="c"></religiousAffiliationCode>
<raceCode code="c"></raceCode>
<ethnicGroupCode code="e"></ethnicGroupCode>
<birthplace classCode="CITY"></birthplace>
<languageCommunication></languageCommunication>
</patientPatient>
</patientRole>
</recordTarget>
<!-********************************************************
CDA Body
********************************************************
-->
<component>
<StructuredBody>
<component>
<section>
<entry>
<!-- Report Entry da cui deriva la section -->
<Act classCode="ACT" moodCode="EVN">
<code code="24317-0" codeSystem="2.16.840.1.113883.6.1" displayName="ESAME
EMOCROMOCITOMETRICO"></code>
<statusCode code="completed"></statusCode>
<!-- Campione di sangue totale utilizzato per le osservazioni dell'intera section -->
<specimen typeCode="SPC">
<specimenRole classCode="SPEC">
<!-- ID unico del campione assegnato dal laboratorio -->
<id root="1.3.6.4.1.4.1.2835.1" extension="0321123456"></id>
</specimenRole>
</specimen>
<!-- Esame Emocromocitometrico -->
<entryRelationship typeCode="COMP">
<organizer classCode="BATTERY" moodCode="EVN">
<id root="1.3.6.4.1.4.1.2835.1" extension="060321123456"></id>
<code code="24317-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="ESAME EMOCROMOCITOMETRICO"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data del risultato finale delle analisi: 09:00 del 30 Dicembre 2006 -->
<effectiveTime value="200612300900"></effectiveTime>
<!-- Primo valore: ERITROCITI -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="11273-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="ERITROCITI"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
78
<!-- Risultato: 5.45 -->
<value xsi:type="PQ" value="4.60" unit="10*6/mm3"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="4.50" unit="10*6/mm3"></low>
<high value="6.00" unit="10*6/mm3"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Secondo valore: EMOGLOBINA -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="20509-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="EMOGLOBINA"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 16.0 -->
<value xsi:type="PQ" value="16.0" unit="g/dL"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="11.5" unit="g/dL"></low>
<high value="14.5" unit="g/dL"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Terzo valore: LEUCOCITI -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="11156-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="LEUCOCITI"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 6900 -->
<value xsi:type="PQ" value="6900" unit="mm3"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="4000" unit="mm3"></low>
<high value="10000" unit="mm3"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Quarto valore: EMATOCRITO -->
<component>
79
<observation classCode="OBS" moodCode="EVN">
<code code="20570-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="EMATOCRITO"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 48 -->
<value xsi:type="PQ" value="48" unit="%"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="40" unit="%"></low>
<high value="54" unit="%"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Quinto valore: MCV -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="30428-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="MCV"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 88 -->
<value xsi:type="PQ" value="88" unit="fL"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="80" unit="fL"></low>
<high value="99" unit="fL"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Sesto valore: MCH -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="28539-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="MCH"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 29 -->
<value xsi:type="PQ" value="29" unit="fL"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="27" unit="fL"></low>
<high value="31" unit="fL"></high>
</value>
80
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Settimo valore: MCHC -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="28540-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="MCHC"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 33 -->
<value xsi:type="PQ" value="22" unit="fL"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="33" unit="fL"></low>
<high value="37" unit="fL"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Ottavo valore: NEUTROFILI -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="26499-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="NEUTROFILI"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 60 -->
<value xsi:type="PQ" value="60" unit="%"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="40" unit="%"></low>
<high value="75" unit="%"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Nono valore: EOSINOFILI -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="26449-9" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="EOSINOFILI"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 3 -->
<value xsi:type="PQ" value="3" unit="%"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
81
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="0" unit="%"></low>
<high value="7" unit="%"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Decimo valore: BASOFILI -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="26444-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="BASOFILI"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 0 -->
<value xsi:type="PQ" value="0" unit="%"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="0" unit="%"></low>
<high value="2" unit="%"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Undicesimo valore: LINFOCITI -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="26474-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="LINFOCITI"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 33 -->
<value xsi:type="PQ" value="33" unit="%"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="18" unit="%"></low>
<high value="50" unit="%"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Dodicesimo valore: MONOCITI -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="26484-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="MONOCITI"></code>
<statusCode code="completed"></statusCode>
82
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 4 -->
<value xsi:type="PQ" value="4" unit="%"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="2" unit="%"></low>
<high value="9" unit="%"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Tredicesimo valore: PIASTRINE -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="26515-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="PIASTRINE"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi -->
<effectiveTime value="200612300730"></effectiveTime>
<!-- Risultato: 1.4 -->
<value xsi:type="PQ" value="1.4" unit="10*5/mm3"></value>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"></interpretationCode>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="1.5" unit="10*5/mm3"></low>
<high value="4.0" unit="10*5/mm3"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<!-- Fine della batteria di valori -->
</organizer>
</entryRelationship>
</Act>
<Act classCode="ACT" moodCode="EVN">
<id root="2.16.840.1.113883.19" extension="1234"></id>
<code code="18725-2" displayName="ESAME DELLE URINE"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'inserimento dei dati -->
<effectiveTime value="200612301015"></effectiveTime>
<specimen typeCode="SPC">
<specimenRole classCode="SPEC">
</specimenRole>
</specimen>
<entryRelationship typeCode="COMP">
<organizer classCode="BATTERY" moodCode="EVN">
<code code="xxxxx" displayName="ESAME DIRETTO"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'esame -->
<effectiveTime value="200612300630"></effectiveTime>
<!-- 2 Osservazioni: colore=giallo paglierino, aspetto=limpido -->
<component>
83
<observation classCode="OBS" moodCode="EVN">
<code code="5778-6" codeSystem="2.16.840.1.113883.6.1" displayName="COLORE"></code>
<value xsi:type="ST">giallo paglierino</value>
</observation>
</component>
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="5767-9" codeSystem="2.16.840.1.113883.6.1" displayName="ASPETTO"></code>
<value xsi:type="ST">limpido</value>
</observation>
</component>
</organizer>
</entryRelationship>
<entryRelationship typeCode="COMP">
<organizer classCode="BATTERY" moodCode="EVN">
<code code="xxxxx" displayName="ESAMI AL MICROSCOPIO"></code>
<statusCode code="completed"></statusCode>
<!-- Ora & Data dell'analisi al microscopio -->
<effectiveTime value="200612300700"></effectiveTime>
<!-- 2 Osservazioni: densità, pH -->
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="19152-8" codeSystem="2.16.840.1.113883.6.1" displayName="DENSITA"></code>
<value xsi:type="PQ" value="1025" unit="kg/m3"></value>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="1015" unit="kg/m3"></low>
<high value="1025" unit="kg/m3"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
<component>
<observation classCode="OBS" moodCode="EVN">
<code code="27378-9" codeSystem="2.16.840.1.113883.6.1" displayName="pH"></code>
<value xsi:type="PQ" value="6.50" unit="unità di pH"></value>
<!-- Range di valori di riferimento -->
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<value xsi:type="IVL_PQ">
<low value="4.4" unit="unità di pH"></low>
<high value="8.0" unit="unità di pH"></high>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
</organizer>
</entryRelationship>
</Act>
</entry>
</section>
</component>
</StructuredBody>
</component>
</ClinicalDocument>
84
APPENDICE B: PDF CDA DI LABORATORIO OTTENUTO
85
86
87
APPENDICE C: PAGINE ANAGRAFICHE E
ANAMNESICHE SVILUPPATE PER IL FASCICOLO
SANITARIO
Fig.24: registrazione nuovo utente
Fig.25: login
88
Fig.26: Home Page del fascicolo sanitario
Fig.27: registrazione nuovo paziente
89
Fig.28: Anamnesi Familiare, pag.1
Fig.29: Anamnesi Familiare, pag.2
90
Fig.30: Anamnesi Fisiologica, pag.1
Fig.31: Anamnesi Fisiologica, pag.2
91
Fig.32: Anamnesi Fisiologica, pag.3
Fig.33: allergie/intolleranze
92
Fig.34: vaccinazioni
93
Fig.35: pagina di personalizzazione
94
APPENDICE D: VERBOT
Nelle screenshots delle sezioni anagrafica e anamnesica, illustrate nella precedente
appendice, si evidenzia senz’altro la presenza del chatterbot riportato qui di seguito:
Fig.36: Chatterbot
Il chatterbot consiste in una faccia 3D parlante e viene utilizzato nell’interazione
con l’utente, all’interno di un software, Verbot (Verbally Enhanced Software
Robot), che combina il linguaggio naturale, le tecniche proprie dell’Intelligenza
Artificiale e un’animazione real-time (assieme alla sintesi vocale) al fine di creare
un assistente virtuale parlante. Infatti, tramite le tecniche utilizzate all’interno del
Player del Software Verbot, viene reso possibile all’utente di porre domande in
linguaggio naturale (tramite tastiera), alle quali il chatterbot risponde sia per iscritto
che tramite sintesi vocale. Inoltre, il personaggio animato è capace di lanciare
applicazioni esterne, visualizzare siti Web, parlare differenti lingue e leggere ad alta
voce.
95
BIBLIOGRAFIA
National Electrical Manufacturers Association, “Digital Imaging
Communications in Medicine, Part 1: introduction and overview”, 2007
and
Marcheschi P., “CDA Release 2, Guida all’uso”
CEN/TC 251 Healt Informatics, “Revision of ENV-13606, parts 1-4 - Electronic
healthcare record communication”, 2001
Giacomini M., “Gli standards per l’informatica medica”, 2007
Robert H. Dolin, “HL7 Clinical Document Architecture, Release 2”
Sottile P. A., “Architettura della cartella clinica virtuale”, 2003
Perelli Ercolini M., Pascale M., “Requisiti, Normativa, Giurisprudenza delle
cartelle cliniche”
Centro Nazionale per l'Informatica nella Pubblica Amministrazione, “Regole per il
riconoscimento e la verifica del documento informatico”, 2005
Integrating the Healthcare Enterprise (IHE), “IHE Laboratory Technical
Framework Supplement, LOINC Test Codes Subset”, 2006
Integrating the Healthcare Enterprise (IHE), “IHE Laboratory Technical
Framework Supplement, Sharing Laboratory Reports”, 2006
Dcr. Lgs. 30 Giugno 2003, n.196, “Codice in materia di protezione dei dati
personali”
McDonald C., Huff S., Vreeman J. Daniel, Mercer K., “Logical Observation
Identifiers Names and Codes (LOINC®), Users' Guide”, 2006
96
Sigonore O., “Il ruolo central di XML nell’evoluzione del Web”, 2001
Regenstrief Institute, “LOINC® Database Version 2.17Released”, 2006
Heitmann K.U., Blobel B., Dudeck J., “HL7 - Communication standard in
medicine”, 1999
Spronk R., “HL7 v3, Encounters & Demographics”
Nationaal ICT Instituut in de Zorg (Nederland), “HL7 v3 Data Types en CMETs”
Servizio Sanitario Regionale Emilia Romagna, “Definizione della 10a revisione
della Classificazione Statistica internazionale delle Malattie e dei Problemi
Sanitari Correlati”, 2006
Anedda P., Brelstaff G., Moehrs S., Tuveri M., Zanetti G., “Cartella Clinica
Elettronica su Piattaforma Java InfoBus”
Dalmiani S., Marcheschi P., Mazzarisi A., “HL7 Clinical Document Architecture to
Share Structured Data in Wide Hospital Information Systems”, 2004
Patersona G.I., Shepherdb M., Wangb X., Wattersb C., Zitnera D, “Using the XMLbased Clinical Document Architecture for Exchange of Structured Discharge
Summaries”, 2002
Rossi Mori A., Maceratini R, “La cartella clinica elettronica (Electronic Patient
Record)”, 2000
Rossi Mori A., “Standards per l’informatica sanitaria”; 2000
Clunie D.A., “Dicom Structured Reporting”, 2000
Castro E., “XML for the World Wide Web”, 2001
Decreto del Presidente del Consiglio dei Ministri, 08 febbraio 1999
Garante della Privacy, Newsletter n.183 del 15 settembre 2003, “Cartelle cliniche e
privacy”
Garante della Privacy, Newsletter n.210 del 26 aprile 2004, “Notificazioni in sanità:
precisazioni del Garante”
Decreto del Presidente della Repubblica n.318 del 28 luglio 1999, “Regolamento
recante norme per l'individuazione delle misure di sicurezza minime per il
trattamento dei dati personali a norma dell'articolo 15, comma 2, della legge 31
dicembre”
97
Dottorini M. L., “La Cartella Clinica”, 2004
Baraghini G., Capelli M., “Il sistema qualità ISO 9000 in Sanità, Guida al
miglioramento della qualità nelle strutture sanitarie”, 2000
http://www.sph.sc.edu/comd/rorden/dicom.html, “The DICOM standard”
http://www.dclunie.com/dicom-status/status.html#BaseStandard2007, “The DICOM
standard development status”
https://www.hl7.org/library/data-model/RIM/C30202/rim.htm#rimUnder, “The HL7
Reference Information Model”
http://www.who.int/classifications/icd/en/,
“World
Healt
(WHO/OMS), International Classification of Diseases (ICD)”
Organization
http://www.alvestrand.no/objectid/2.16.840.1.113883.html, “Healt Level Seven Inc.
OID, 2.16.840.1.113883”
http://www.regenstrief.org/medinformatics/loinc, “Logical Observation Identifiers
Names and Codes”
http://www.hl7.org
http://www.hl7italia.it
http://medical.nema.org
http://www.dica33.it/
98
