Introduzione ai Sistemi Informativi Sanitari - A cura del Ing. Mario Sansone
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Introduzione ai Sistemi Informativi Sanitari A cura del Ing. Mario Sansone
Indice
1 Introduzione ai Sistemi Informativi 2
1.1 Processi e dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Il modello Entitá Relazione . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 I Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 I DBMS relazionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Linguaggi per la manipolazione dei dati . . . . . . . . . . . . . . . . . . . 8
1.7 Gli utenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.8 Architettura client-server . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.9 Cenni sull’organizzazione delle reti di computer . . . . . . . . . . . . . . 9
1.10 Cenni su XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.11 Cenni su HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 I Sistemi Informativi Sanitari 13
2.1 La cartella clinica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Hospital Information System (HIS) . . . . . . . . . . . . . . . . . . . . . 20
2.3 Diagnosis Related Group (DRG) . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1 Indici di efficienza . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Scheda di Dimissione Ospedaliera (SDO) . . . . . . . . . . . . . . . . . . 24
2.5 Centro Unificato di Prenotazione (CUP) . . . . . . . . . . . . . . . . . . 25
2.6 Radiology Information System (RIS) . . . . . . . . . . . . . . . . . . . . 25
2.6.1 DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7 HL7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1
Capitolo 1
Introduzione ai Sistemi Informativi
Un sistema informativo (SI) puó essere definito come l’insieme dei flussi di informazione
gestiti all’interno di una organizzazione.
Pertanto si tratta di un componente (sotto-sistema) di una organizzazione che gestisce
(acquisisce, elabora, conserva, produce) le informazioni di interesse (cioé utilizzate per
il perseguimento degli scopi dell’organizzazione).
Ogni organizzazione ha un sistema informativo, eventualmente non esplicitato nella
struttura; quasi sempre, il sistema informativo é di supporto ad altri sotto-sistemi, e va
quindi studiato nel contesto in cui é inserito; il sistema informativo, é di solito suddiviso
in sotto-sistemi (in modo gerarchico o decentrato), piú o meno fortemente integrati.
Un sistema informativo puó essere automatizzato in parte o del tutto con le moderne
tecnologie dell’informazione. I componenti di un sistema informativo automatizzato sono
essenzialmente i processi, la base dati ed il DBMS (fig. 1.1).
1.1 Processi e dati
Un processo é un insieme di attivitá (sequenze di decisioni e azioni) che l’organiz-
zazione svolge per realizzare un risultato definito e misurabile (prodotto o servizio), che
trasferisce valore al fruitore del prodotto o servizio, che contribuisce al raggiungimento
della missione dellorganizzazione.
Da un punto di vista informatico, un processo é un programma, scritto in un op-
portuno linguaggio, che accede alla base di dati per consultarla e aggiornarla (vedi fig.
1.1).
I processi possono essere classificati in:
Processi direzionali concorrono alla definizione degli obiettivi strategici.
Processi gestionali traducono gli obiettivi strategici in obiettivi economici e ne con-
trollano il raggiungimento.
Processi operativi concorrono alla attuazione degli obiettivi.
2
Capitolo 1. Introduzione ai Sistemi Informativi
Figura 1.1: I componenti di un Sistema Informativo.
La base di dati rappresenta una raccolta di informazioni sulle entitá del mondo reale
(ad es. paziente, personale medico, terapie, esami di laboratorio etc. . . . ) che devono
essere gestite.
I dati possono essere classificati in:
Dati anagrafici descrivono attributi costanti delle entitá (nome, cognome, codice
fiscale etc. . . . )
Dati di stato descrivono le condizioni in cui si trovano le entitá (diagnosi, terapia
corrente, etc. . . . )
Dati sugli eventi descrivono le operazioni compiute sulle entitá (esame diagnostici,
cambiamento di terapia, interventi chirurgici, etc. . . . )
Le operazioni che é possibile eseguire sui dati sono le seguenti:
• Creazione di un nuovo dato (Create)
• Lettura di un dato esistente (Read)
• Modifica di un dato esistente (Update)
• Cancellazione di un dato (Delete)
Le modalitá di effettuazione di tali operazioni puó essere:
Interattiva prevede il dialogo diretto tra utente e sistema (ad es. accettazione, dimis-
sione)
In tempo reale (Real-time) l’elaborazione conseguente ad una operazione deve com-
pletarsi prima dell’operazione successiva (ad es. prenotazione esami)
Batch (A lotti) l’elaborazione é tipicamente asincrona rispetto alla richiesta (ad es.
rendiconto annuale)
La fig. 1.2 riassume le caratteristiche di accesso ai dati.
A cura di: Ing. Mario Sansone 3
Capitolo 1. Introduzione ai Sistemi Informativi
Figura 1.2: Classificazione dei processi secondo la modalitá di accesso ai dati.
1.2 DBMS
Il Data Base Management System é un sistema software che standardizza l’accesso dei
processi alla base di dati offrendo delle interfacce generalizzate che permettono:
• la condivisione dei dati da parte dei processi (i dati possono essere utilizzati da
piú processi e da piú utenti);
• l’indipendenza dei dati rispetto ai processi (se i processi vengono cambiati non é
necessario modificare anche la struttura dei dati e viceversa).
Come ogni prodotto informatico, un DBMS deve essere:
efficiente utilizzando al meglio le risorse di spazio e tempo del sistema; l’efficienza
dipende sia dalle tecniche utilizzate per l’implementazione del DBMS che dalla
bontá della realizzazione della base in fase di progettazione;
efficace rendendo produttive le attivitá dei suoi utilizzatori.
L’architettura di un DBMS é definita da vari schemi che rappresentano la base dati
a differenti livelli di astrazione:
schema logico descrizione dell’intera base di dati.
schema esterno descrizione di una parte della base di dati (‘viste’ parziali), ad es. un
certo utente (personale dell’accettazione) non ha bisogno di ‘vedere’ l’intera base
dati ma solo una parte di essa.
schema fisico rappresentazione dello schema logico per mezzo di strutture fisiche di
memorizzazione.
1.3 Il modello Entitá Relazione
Nel progetto di una base dati si procede per livelli di raffinamento successivi. In questo
contesto é rilevante il modello entitá-relazione (E-R) che consente di trarre una de-
scrizione a livello logico della base dati. Tale descrizione puó essere poi efficacemente
implementata in un DBMS.
A cura di: Ing. Mario Sansone 4
Capitolo 1. Introduzione ai Sistemi Informativi
Figura 1.3: Simboli usati per la costruzione dei diagrammi E-R.
I componenti del modello E-R sono (fig. 1.3, 1.4):
Entitá oggetti sui quali si memorizza informazione; hanno associati degli attributi (ad
es. ‘Nome’ e ‘Cognome’ sono attributi dell’entitá ‘Persona’).
Relazioni definiscono rapporti tra le entitá (ad es. ‘Impiegato’ é dipendente di ‘Azien-
da’); possono avere anch’esse degli attributi.
In questo modello la struttura del Database é composta da:
• Un insieme di diagrammi ER che rappresentano i dati operativi che devono essere
strutturati nel SI;
• Un insieme di dizionari dei dati associati ai diagrammi E-R che descrivono verbal-
mente i diagrammi per mezzo di tabelle riassuntive;
• Un insieme di vincoli di integritá sui dati che specificano condizioni particolari
che non possono essere desunte dai diagrammi (ad es. l’etá di una persona é un
numero che non puó essere negativo).
A cura di: Ing. Mario Sansone 5
Capitolo 1. Introduzione ai Sistemi Informativi
Figura 1.4: Esempio di diagramma E-R.
1.4 I Data Flow Diagram
I Data Flow Diagrams (Diagrammi di Flusso dei Dati, DFD) sono complementari al
formalismo E-R: infatti non si concentrano sulla struttura e sul significato dei dati, bensı́
sulle operazioni, o funzioni, applicate ad essi: mostrano come i dati vengono elaborati
nel sistema (fig. 1.5).
I DFD descrivono le operazioni effettuate sui dati e le dipendenze funzionali che si
creano in virtú dei flussi di informazione esistenti tra i diversi processi.
Utilizzano una notazione grafica che si concentra sull’elaborazione funzionale, la
memorizzazione dei dati e il passaggio di dati tra funzioni.
Nella figura 1.6 é rappresentato un esempio di processo di monitoraggio paziente
modellato con la metodologia DFD.
1.5 I DBMS relazionali
Il modello relazionale dei dati é il modello che si é affermato sin dagli anni ’70 per i
DBMS.
In questo modello le entitá e le relazioni (derivate dal diagramma E-R) sono rapp-
resentate mediante tabelle. In ogni riga (denominata anche record) di tali tabelle sono
scritti gli attributi della entitá o della relazione in esame. Ad esempio la tabella seguente
rappresenta gli attributi dell’entitá ‘persona’.
A cura di: Ing. Mario Sansone 6Capitolo 1. Introduzione ai Sistemi Informativi
Figura 1.5: Simboli usati per la costruzione dei diagrammi DFD.
Figura 1.6: Modello di un processo di monitoraggio paziente mediante DFD.
A cura di: Ing. Mario Sansone 7Capitolo 1. Introduzione ai Sistemi Informativi
Tabella ‘persona’
Codice Fiscale Nome Cognome Etá
RSSMRA Mario Rossi 32
MNDLCA Lucia Mondella 27
Ogni tabella é caratterizzata da uno schema, cioé da una struttura che indica il tipo
di valore inserito in una data colonna della tabella ad es.:
(Codice Fiscale, Nome, Cognome, Etá)
Nello schema precedente il campo sottolineato indica una chiave cioé un tipo di
valore che puó essere utilizzato per identificare univocamente la riga della tabella.
1.6 Linguaggi per la manipolazione dei dati
Per effettuare delle interrogazioni su una base di dati é opportuno disporre di opportuni
linguaggi.
Lo standard in questo senso é il linguaggio SQL (Structured Query Language, Lin-
guaggio per interrogazioni strutturate). Senza entrare nel dettaglio di tale linguaggio
diamo un esempio di come sia possibile effettuare una interrogazione su una base dati:
SELECT Nome, Etá FROM Persona WHERE Cognome=’Rossi’;
Questa interrogazione preleva il Nome e l’Etá (SELECT Nome, Etá) dalla tabel-
la ’Persona’ (FROM Persona) di tutte le persone che si chiamano Rossi di cognome
(WHERE Cognome=’Rossi’).
Il SQL é composto di due sottoinsiemi di linguaggi:
DATA DESCRIPTION LANGUAGE (DDL) serve per descrivere lo schema del-
la base di dati. Consente di separare il progetto della base di dati dal progetto dei
processi.
DATA MANIPULATION LANGUAGE (DML) Linguaggio che fornisce una sin-
tassi standard per accedere alla base di dati.
1.7 Gli utenti
Gli utenti di una base dati possono essere distinti in:
Database Administrator Persona o gruppo di persone responsabile del controllo
centralizzato e della gestione del sistema, delle prestazioni, dell’affidabilitá, delle
autorizzazioni. Le funzioni del DBA includono quelle di progettazione, anche se
in progetti complessi ci possono essere distinzioni.
Utenti finali Sono gli utenti quotidiani del sistema. Di norma essi hanno diritti di
accesso ai dati limitati; vengono identificati medianteusername e password.
A cura di: Ing. Mario Sansone 8Capitolo 1. Introduzione ai Sistemi Informativi
Figura 1.7: Modello Client-Server.
1.8 Architettura client-server
In questa architettura (fig. 1.7) un computer client invia una richiesta di dati ad un
computer server il quale a sua volta inoltra la richiesta nel linguaggio idoneo per il
DBMS che gestisce la base dati. La risposta del DBMS viene interpretata e riformattata
opportunamente dal server ed inviata da questi al client. Pertanto il server intermedio
ha il compito di interrogare la base dati e formattare adeguatamente le risposte per il
client (architettura three-tier).
Allo stato attuale quasi tutti i DBMS disponibili in commercio utilizzano l’architet-
tura client-server. Tra i piú noti citiamo:
• Oracle (Oracle)
• SQLServer (Microsoft)
• MySQL (free)
• PostgreSQL (free)
1.9 Cenni sull’organizzazione delle reti di computer
Le reti locali (Local Area Networks, LAN) connettono calcolatori situati nello stesso
edificio o in edifici diversi e situati nell’arco di pochi Km. Le WAN (Wide Area Networks)
inter-connettono varie LAN.
La piú comune topologia di rete é quella a BUS (fig. 1.8). Con queste topologie di
solito si utilizza un controllo casuale di trasmissione: un calcolatore invia un pacchetto
in rete che viene ricevuto da tutti gli altri; gli altri elaboratori elaborano il contenu-
to ricevuto solo nel caso in cui questo contenga il proprio indirizzo; diversamente lo
ignorano.
La rete Ethernet é un particolare tipo di rete a BUS con metodo di accesso CS-
MA/CD (Accesso multiplo con rilevamento di portante e con rilevazione della collisione).
In questo tipo di rete una stazione che deve trasmettere un pacchetto si accerta che sul
mezzo di trasmissione non ne stia viaggiando giá un altro. Se si genera una collisione
viene rinviato il pacchetto.
Nelle reti di computer vengono trasmessi pacchetti di dati. Ogni singolo pacchetto
di dati subisce una complessa trasformazione (incapsulamento) prima di essere inviato
A cura di: Ing. Mario Sansone 9Capitolo 1. Introduzione ai Sistemi Informativi
Figura 1.8: Rete a BUS.
sulla rete. Il meccanismo di incapsulamento dei dati é simile al modo in cui potrem-
mo trasmettere un libro usando il sistema postale: il libro viene scomposto in pagine,
ciascuna pagina (i dati) viene numerata (protocollo TCP) ed inserita in una busta con
l’indirizzo del mittente e destinatario (indirizzo IP) infine viene imbucata (bus Ethernet).
All’interno di una stessa rete locale i singoli computer vengono individuati da un
numero (indirizzo IP).
Quando si vuole colloquiare con un computer che non si trova sulla stessa rete locale
bisogna trasferire i pacchetti alle altre reti in maniera simile a quanto succederebbe se
una persona di Napoli volesse comunicare con una persona di Milano tramite posta:
la lettera spedita verrebbe intercettata dall’ufficio postale principale Napoletano che lo
spedirebbe a quello Milanese ed a quel punto tramite dei sottouffici e infine tramite il
postino la lettera giuge a destinazione.
In internet questo meccanismo viene chiamato routing (instradamento) dei pacchetti.
Esistono dei computer (denominati router) che hanno il ruolo degli uffici postali di
smistamento.
Infine poiché i numeri sono difficili da ricordare per gli esseri umani esiste un sistema
di codifica degli indirizzi IP che associa ad ogni indirizzo un nome. Esistono pertanto dei
computer (denominati DNS) che possiedono l’elenco degli indirizzi con i nomi associati
(ad es. www.miodominio.it → 192.10.10.5).
1.10 Cenni su XML
XML (eXtended Markup Language, Linguaggio a Marcatori Esteso ) é un linguaggio
per la rappresentazione dei dati in maniera testuale utilizzando dei marcatori appunto.
Chiariamo subito con un esempio. Supponiamo di avere la tabella dei dati anagrafici
dei pazienti:
Tabella ‘Pazienti’
Codice Fiscale Nome Cognome Etá
RSSMRA Mario Rossi 32
MNDLCA Lucia Mondella 27
una rappresentazione di tale tabella in un documento di testo XML é la seguente:
A cura di: Ing. Mario Sansone 10Capitolo 1. Introduzione ai Sistemi Informativi
< T abP azienti >
< P aziente >
< CF > RSSM RA < /CF >
< N ome > M ario < /N ome >
< Cognome > Rossi < /Cognome >
< Eta > 32 < /Eta >
< /P aziente >
< P aziente >
< CF > M N DLCA < /CF >
< N ome > Lucia < /N ome >
< Cognome > M ondella < /Cognome >
< Eta > 27 < /Eta >
< /P aziente >
< /T abP azienti >
Le informazioni sono racchiuse da un tag o marcatore di apertura (ad es. < CF >)
ed uno di chiusura (ad es. < /CF >) i quali differiscono solo per la presenza di uno
slash. É importante che ogni tag aperto sia poi chiuso. Come si vede i tag possono essere
innestati l’uno dentro l’altro (ad es. < CF > é contenuto in < P aziente >). Si vede
che un record della tabella Pazienti corrisponde al contenuto di un tag < P aziente >.
Questa rappresentazione non é una semplice manipolazione della tabella perché é
suscettibile di una serie di varianti che la rendono estremamente flessibile e potente.
Una delle carattersitiche piú importanti é che la sequenza dei tag puó essere dichiara-
ta opzionale, cioé un campo puó essere assente (ad es. potrei non volere le Etá). Questo
rende il linguaggio XML in grado di mettere in comunicazione due strutture dati che
abbiano un sottoinsieme comune (ad es. in una prima struttura uso tutti i campi mentre
nella seconda uso solo il CF Nome e Cognome, in questo caso per comunicare dati dalla
prima verso la seconda potró indicare che il campo Etá é opzionale)
La modalitá in cui i vari tag si possono innestare tra di loro, i dati opzionali, i
dati ripetuti (ad es. ci puó essere piú di una diagnosi) ed altre caratterstiche devono
essere dichiarate all’interno di un documento chimato DTD (Documet Type Definition,
Definizione dei tipi di dati, oppure XML-Schema nelle ultime versioni di XML), in questo
modo é possibile verificare se un documento XML é ben formato.
1.11 Cenni su HTML
HTML é un linguaggio a marcatori per la rappersentazione di documenti sul web. In ef-
fetti puó essere considerato un derivato dell’XML anche se cronologicamente lo sviluppo
é stato inverso (cioé prima html e poi XML).
In effetti la differenza tra XML e HTML (Hyper Text Markup Language, linguaggio
per ipertesti a marcatori) consiste nel fatto che in XML i tag sono decisi dall’utente
che prepara il testo e possono essere qualsiasi a patto che vengano specificati nel DTD
(o XML-Schema); nell’HTML invece i tag sono predefiniti e sono riconosciuti da tutti i
Browser commercali (ad es. MS Explorer, Netscape, Opera etc.. . . ).
A cura di: Ing. Mario Sansone 11Capitolo 1. Introduzione ai Sistemi Informativi
Facciamo un esempio di pagina HTML:
Pagina di HTML
Salve, sono una pagina HTML!
Questo \’e un link
Il tag < hmtl > deve essere sempre presente e racchiude l’intero documento che é
costituito da un header < head > e da un body < body >. Nell’header sono contenute
informazioni di controllo (metadati) che servono poter interpretare corretamente il doc-
umento: nell’esempio troviamo il set di caratteri ed il software che é stato usato per
generare la pagina. Nel body invece troviamo il documento vero e proprio che verrá
interpretato dal browser e visualizzato all’utente.
Ogni tag ha un significato preciso ad es. < h1 > significa che il testo va visualizzato
in grasseto con un carattere grande; < h2 > significa che il testo é un pó piú piccolo:
questa organizzazione serve a rendere il documento piú leggibile e renderlo visualizzabile
su qualunque dispositivo.
Un altro aspetto importante di HTML é il tag < a > (link ipertestuale) che consente
di ‘puntare’ ad un altra pagina o a un altro documento generico.
A cura di: Ing. Mario Sansone 12Capitolo 2
I Sistemi Informativi Sanitari
La finalitá di un sistema informativo in sanitá é la gestione di informazioni utili alla
misura ed alla valutazione dei processi gestionali e clinici al fine di ottimizzare le risorse
impiegate nel conseguimento degli obbiettivi istituzionali e ottimizzare le modalitá di
comunicazione.
Le entitá coinvolte sono rappresentate nella figura 2.1 in cui sono rappresentati anche
i flussi informativi e le richieste di servizi.
L’architettura proposta dallo standard Europeo CEN/TC 251 per i sistemi informa-
tivi sanitari, prevede al centro del sistema il soggetto di cura. Senza entrare nel dettaglio
dello standard su citato, si puó comunque comprendere il concetto osservando la figura
2.2.
In effetti dal momento dell’accettazione, in cui il paziente accede alla struttura san-
itaria, fino al momento della dimissione, il sistema informativo deve tenere traccia di
ogni accadimento, per motivi medico/legali/amministrativi.
In questo contesto il fattore centrale di tutto il sistema informativo é la cartella
clinica, sia essa cartacea o elettronica.
2.1 La cartella clinica
La finalitá della cartella clinica é di facilitare la cura del paziente, avere a dispo-
sizione una raccolta cronologica del processo di cura, semplificare la comunicazione fra
il personale, la raccolta dati a fini medico/legali, le operazioni di rimborso, le ricerche
retrospettive e prospettiche.
Una storia semplificata della cartella clinica puó essere cosı́ riassunta:
1910 Raccolta dati orientata al paziente
1940 Ospedali Americani con accreditamento
1969 Riflessione sui modelli di cartella clinica
13Capitolo 2. I Sistemi Informativi Sanitari
Figura 2.1: Entitá coinvolte.
Figura 2.2: Flussi informativi.
A cura di: Ing. Mario Sansone 14Capitolo 2. I Sistemi Informativi Sanitari
1960-70 Sistemi informativi ospedalieri ‘elettronici’ per accettazione, dimissione, ren-
diconto economico
1980 Prime cartelle cliniche ‘di reparto’
1990 Esempi di cartelle cliniche condivise
2000 Possibile trasformazione del concetto per favorire la continuitá della cura
I tipi di cartella clinica proposti intorno agli anni ’70:
• Orientati temporalmente: collezione di dati sequenziali, in questo modello i dati
vengono raccolti ed organizzati solo in base alla sequenza temporale degli eventi.
ad es.
21/02/01 Mancanza di respiro, tosse, febbre.
Temp:39.3 C
Diagnosi: bronchite acuta
Hb: 7.8 mg/dl
Trattamento: 100mg Ascal/d
• Orientati alla ‘sorgente’ informativa: organizzazione temporale in una classifi-
cazione per sorgente dei dati. In questo modello i dati vengono organizzati anche
in base al tipo di sorgente informativa (cioé se i dati vengono da una visita, da un
esame diagnostico etc. . . . ) ad es.
Visite
21/02/01 Mancanza di respiro, tosse, febbre.
Temp:39.3 C
Diagnosi: bronchite acuta
Trattamento: 100mg Ascal/d
Esami
21/02/01 Hb: 7.8 mg/dl
• Orientati al problema: organizzazione temporale in una classificazione per proble-
mi. In questo modello il nucleo centrale é il problema ed i dati vengono classificati
in soggettivi ed oggettivi. ad es.
Problema Bronchite acuta
21/02/01 Soggettivi: Mancanza di respiro, tosse, febbre.
Oggettivi: Temp:39.3 C, Hb: 7.8 mg/dl
Diagnosi: bronchite acuta
Trattamento: 100mg Ascal/d
Una interessanteclassificazione delle cartelle cliniche si fonda sull’individuazione di
categorie di pazienti rispetto ai quali esistono differenti trattamenti clinici: a causa di
questi differenti trattamenti e del tempo, nel corso del quale tali trattamenti sono effet-
tuati, differenti tipologie di informazioni devono essere gestite. Si distinguono cartelle
cliniche per:
A cura di: Ing. Mario Sansone 15Capitolo 2. I Sistemi Informativi Sanitari
pazienti in terapia intensiva la cartella clinica é rivolta a pazienti in condizioni se-
vere, in cui il controllo del quadro clinico é effettauto di continuo da una opportuna
strumentazione. É il caso tipico della sala di rianimazione o unitá coronarica. É
presente una sofisticata strumentazione in grado di monitorare di continuo alcuni
parametri vitali e di generare allarmial personale in presenza di anomalie. Tale
strumentazione acquisisce una grande mole di dati che puó essere memorizzata
ed inclusa nella cartella clinica computerizzata. Dunque il sistema informatico
di gestione dovrá interfacciarsi anche con la strumentazione oltre che gestire le
informazioni inputate da tastiera.
pazienti ospedalizzati in questo caso la cartella clinica raccoglie oltre alle infor-
mazioni identificative, anche dati significativi acquisist durante la degenza (terapie,
esami effettuati).
pazienti ambulatoriali in follow-up in questo caso le informazioni sono controllate
ad intervalli di tempo variabili. Qeuste cartelle si possono dividere in cartelle a
termine e a tempo indefinito. Le prime sono relative a patologie che si suppone
vengano risolte in breve tempo, Le seconde sono relative a patologie che restanp
croniche.
In una cartella clinica orientata temporalmente vengono gestiti dati raccolti durante
visite periodiche. Un esempio di tabella orientata temporalmente é riportata di seguito:
data visita freq. card. press. max press. min
02-03-90 110 180 110
04-05-90 90 145 90
06-07-90 105 140 100
Il riferimento temporale cionsente di ricostruire l’andamento del quadro, la valu-
tazione clinica puó essere migliorata. Tipiche categorie di pazienti sono gli ipertesi, i
pazienti affetti da scompenso cariaco, oncologici, post-infartuati, etc.. . . .
I dati presenti in una cartella clinica possono esser di vario tipo:
• Numerici: misure di parametri vitali del paziente;
• Alfanumerici: parametri che non possono essere quantificati ad es. l’ombra car-
diaca ‘aumentata’ su una lradiografia;
• Date: istante di accadimento di un evento;
• Testo libero: refertazioni etc.. . . ;
• Segnali: ECG, EMG, etc.. . . ;
• Immagini: CT, MRI, ecografia, etc.. . . ;
• Suoni fonocardiografia etc.. . . ;
I vantaggi della cartella clinica elettronica rispetto ad una cartella clinica cartacea
possono essere cosı́ riassunti:
• riduzione dello spazio fisico necessario per archiviare le cartelle: con i moderni
sistemi informatici migliaia di cartelle cliniche possono essere registrate su un
Hard Disks;
A cura di: Ing. Mario Sansone 16Capitolo 2. I Sistemi Informativi Sanitari
• possibilitá di effettuare ricerche in tempi rapidissimi;
• possibilitá di condividere le cartelle tra i vari reparti;
• possibilitá di consultare i dati attraverso le reti informatiche e quindi in linea di
principio da qualunque postazione all’interno della struttura ospedaliera o della
rete sanitaria nazionale o addirittura mondiale.
Questi vantaggi si pagano peró con alcuni svantaggi:
• i dati devono essere altamente strutturati per poter essere trattati con i mezzi
informatici;
• i dati devono venire digitati dall’operatore e questo puó essere un aspetto rile-
vante soprattutto se vengono commessi errori; tuttavia in questo campo sono stati
compiuti grossi sforzi allo scopo di semplificare la inputazione dei dati (vedi ad
esempio i sistemi di dettatura vocale) e nella correzione automatica di certi tipi di
errore;
• disomogeneitá dei dati tra i diversi reparti. In effetti é praticamente impossibile
organizzare un sistema informativo che sia efficace ed efficiente per tutti i sotto-
sistemi presenti all’interno di una struttura sanitaria: la tendenza attuale é quella
di rassegnarsi ad avere sistemi informativi diversi per ciascun reparto, ma lavo-
rare nella direzione della integrazione dei vari sottosistemi mediante lo sviluppo
di metodi di interfacciamento che consentano di transcodificare le informazioni da
un sistema all’altro (vedi fig. 2.3 e 2.4);
• la sicurezza del dato in formato elettronico presenta forse degli aspetti piú delicati
rispetto al dato cartaceo; tuttavia sono stati compiuti grossi sforzi nel campo della
sicurezza elettronica (firma digitale, crittografia dei dati, etc.. . . ).
Le informazioni contenute nella cartella clinica comprendono sicuramente i dati ana-
grafici del paziente. Tra i dati anagrafici ve ne sono alcuni che oltre ad identificare
le generalitá del paziente costituiscono la chiave per l’individuazione univoca dell’in-
dividuo all’interno dell’archivio e rappresentano l’anello di collegamento con tutte le
altre informazioni che vengono progressivamente immagazzinate nel corso della degen-
za e del trattamento anche in occasione di ricoveri ripetuti e contribuiscono a rendere
piú rapido e sicuro lo scambio di dati tra diverse realtá che vengono a contatto con
lo stesso individuo. Questo, oltre a rappresentare un vantaggio per le varie strutture
coinvolte nello scambio dei dati, contribuisce a rendere piú complete le informazioni
relative all’individuo consentendo un piú completo e rapido trattamento delle patologie
concomitanti.
Tra i dati anagrafici il minimo set di informazioni, indispensabili per identificare
univocamente un individuo, é rappresentato da:
COGNOME
NOME
DATA DI NASCITA
SESSO
Mediante queste informazioni é possibile identificare univocamente la quasi totalitá
delle persone ad eccezione di qualche raro caso in Italia, per il quale occorre considerare
A cura di: Ing. Mario Sansone 17Capitolo 2. I Sistemi Informativi Sanitari
Figura 2.3: Architettura integrata.
Figura 2.4: Architettura non integrata.
A cura di: Ing. Mario Sansone 18Capitolo 2. I Sistemi Informativi Sanitari
qualche altro dato. A tale riguardo una circolare del ministero della funzione pubblica,
giá nel 1990, aveva individuato il codice fiscale quale sistema unitario di individuazione
e di accesso dei cittadini. Per questi motivi un buon sistema di gestione della cartella
clinica dovrebbe prevedere l’utilizzo del codice fiscale come identificatore univoco dell’in-
dividuo all’interno del sistema. Quando questo non é immediatamente disponibile viene
parzialmente costruito in modo automatico utilizzando il cognome, il nome, il sesso e
la data di nascita (campi obbligatori) per i primi 12 caratteri, aggiungendo un numero
progressivo di 4 cifre per distinguere eventuali individui con lo stesso codice parziale. Il
codice cosı́ costruito dovrá essere sostituito al piú presto con il codice fiscale completo.
É auspicabile la possibilitá di collegamento con un archivio anagrafico standard messo
a disposizione da altre strutture quali l’ospedale, il comune, la regione ecc.. . . , per
prelevare i dati anagrafici garantendo la correttezza dei dati.
Sui dati anagrafici dovrá essere possibile effettuare rapide ricerche, anche con chiave
parziale, per consentire il ritrovamento immediato di pazienti precedentemente registrati
ed evitare inserimenti errati, come nel caso di soggetti il cui nominativo potrebbe essere
scritto in modo non univoco (es. Depaoli, De Paoli, de Paoli).
A questi dati potranno essere aggiunte ulteriori informazioni ritenute di utilitá nel-
la gestione specifica di ogni singola realtá (indirizzo, recapito telefonico, stato civile,
cittadinanza, titolo di studio) che potranno anche essere aggiornate con procedure auto-
matiche basate sui dati trasmessi dalle anagrafi dell’ospedale o comunali (nascite, morti,
cambi d’indirizzo).
Un dato deve sempre essere legato ad una data. Quale data? Nel caso dei dati
sanitari risultano essere di importanza il ‘Tempo di transazione’ (cioé il momento in cui
si effettua l’inserimento del dato), ed il ‘Tempo di validitá’ (validitá del dato). Questa
distinzione é cruciale per gli esami di laboratorio (che risultano significativi solo per un
certo periodo di tempo) ed anche per per giudicare l’attivitá del reparto e gli esiti del
processo clinico.
Una parola chiave nel contesto della disomogeneitá delle informazioni é interoper-
abilitá: il modello non integrato é possibile a patto di avere uno strato software di in-
termezzo (detto ‘middleware’) che deve assicurare l’interoperabilitá dei sistemi informa-
tivi. L’interoperabilitá é la possibilitá di scambiare informazioni e utilizzare procedure
mediante stazioni di lavoro con caratteristiche hardware e software diverse.
In effetti allo stato attuale molti sono i software proprietari (cioé con caratteristiche
non standard), ed esiste una non uniformitá dei dati raccolti ed una difficoltá nello
scambiare i dati con altri centri, tuttavia é pressoché impossibile pensare a sistemi
informativi completamente integrati.
Tale considerazione risulta ancora piú critica nell’area clinica della terapia intensiva,
in cui la struttura organizzativa e la dinamica dei flussi informativi risultano spesso
fortemente dipendenti dalle realtá locali, cosı́ da rendere difficilmente trasportabili soft-
ware preconfezionati che avrebbero costretto l’utente di tali prodotti ad adeguare il
proprio modo di lavorare a degli standard non perché considerati superiori, ma solo
perché imposti dal sistema. Quindi nonostante l’impegno di numerose case di software
nella progettazione di cartelle cliniche sofisticate, in grado di contenere infinite quantitá
di informazioni, la maggior parte delle esperienze si sono rivelate fallimentari.
A cura di: Ing. Mario Sansone 19Capitolo 2. I Sistemi Informativi Sanitari
É necessario pertanto l’adeguamento del prodotto al modo di operare della singola
realtá in modo da incidere minimamente sui metodi e sulle abitudini di lavoro consideran-
do assolutamente indispensabile l’adeguamento del software alla struttura piuttosto che
viceversa. Questo naturalmente comporta una notevole personalizzazione del ‘prodotto’
cartella clinica rendendo difficilmente trasportabile un software, anche se ottimo, da
una realtá operativa ad un’altra, con la richiesta di una elevata disponibilitá di risorse e
competenze specifiche, non solo tecniche ma anche organizzative, non sempre facilmente
reperibili.
La vera possibilitá di standardizzazione non sta quindi nell’adozione di cartelle
cliniche uguali per tutti e che gestiscono le stesse informazioni, quanto piuttosto nello
stabilire un numero minimo di informazioni che ciascun sistema deve contenere lascian-
do all’iniziativa del singolo l’integrazione con dati che si adeguano alle necessitá imposte
dal sistema di lavoro e dal flusso di informazioni che la singola realtá decide di trattare.
La standardizzazione e l’adeguamento al minimo set di informazioni non sará quindi
un obiettivo ma una necessitá qualora si richieda al sistema di colloquiare con un altro.
Tuttavia poiché é auspicabile che una cartella clinica di reparto sia in grado di scambiare
dati con cartelle cliniche di altri reparti, con l’intero sistema informativo ospedaliero e
con reparti di altri ospedali, tale standardizzazione risulta pressoché indispensabile.
Questo é in linea con quanto ribadito da una buona parte della letteratura che ritiene
prioritario lo studio dei flussi informativi, indipendentemente dagli strumenti utilizzati
per la gestione delle informazioni.
2.2 Hospital Information System (HIS)
Si potrebbe definire un HIS (in italiano Sistema Informativo Ospedaliero - SIO) come
il risultato dell’integrazione ed interazione di alcuni sottosistemi informativi principali
(vedi fig. 2.5).
Sottosistema amministrativo-finanziario vengono in esso identificate sia le fun-
zioni tradizionalmente pertinenti alla gestione economico-finanziaria dell’Ente (con-
tabilitá analitica, generale, fatturazione, ordini, rilevazione presenze e gestione
personale), sia quelle piú generalmente volte a garantire l’erogazione di servizi
di rilevante importanza logistica (gestione mensa, turni, personale infermieristico,
. . . ).
Sottosistema di gestione del paziente racchiude l’insieme di protocolli e modulis-
tiche relative alla gestione del paziente degente ed ambulatoriale: tradizionalmente
le informazioni processate sono quelle relative alla cartella clinica (generalitá, dati
anamnestici, obiettivitá, terapie, . . . ) ed al monitoraggio strumentale di parametri
clinici rilevanti.
Sottosistema servizi e laboratori in tale ambito vengono incluse sia le esigenze in-
formative che caratterizzano la gestione interna dei servizi ospedalieri (radiologia,
laboratori chimico-clinici e microbiologici, centro emotrasfusionale, . . . ), sia i flus-
si informativi inerenti all’interazione con il sottosistema di gestione del paziente
(prenotazione ed invio referti).
A cura di: Ing. Mario Sansone 20Capitolo 2. I Sistemi Informativi Sanitari
Figura 2.5: Hospital Information system.
Sottosistema di prenotazione rappresenta il sistema di gestione degli accessi del
paziente alla struttura ospedaliera (prenotazione esami, visite ambulatoriali, ri-
coveri). Risulta, pertanto, fortemente integrato con i sottosistemi di gestione dei
paziente e dei servizi.
2.3 Diagnosis Related Group (DRG)
Il DRG/ROD (Raggruppamenti Omogenei di Diagnosi) é un metodo per la classifi-
cazione dei pazienti dimessi dagli ospedali 2.6. Il sistema DRG é un sistema di classi-
ficazione che si basa su raggruppamenti omogenei di diagnosi, traduzione italiana del
sistema statunitense noto con la sigla DRG (Diagnosis Related Groups). É un sistema
di classificazione dei pazienti dimessi dagli ospedali per acuti che attualmente viene uti-
lizzato anche in Italia come base per il finanziamento delle Aziende Ospedaliere. Tale
sistema si basa su alcune informazioni contenute nella scheda di dimissione ospedaliera
(SDO) ed individua circa 500 classi di casistiche, tendenzialmente omogenee per quanto
riguarda il consumo di risorse, la durata della degenza e, in parte, il profilo clinico. Con
l’applicazione di tale sistema viene introdotto nel SSN una nuova modalitá di finanzia-
mento delle attivitá ospedaliere basato sulla remunerazione delle prestazioni mediante
tariffe predeterminate.
Le informazioni necessarie all’attribuzione dei pazienti alle singole categorie sono
facilmente ottenibili dal sistema informativo disponibile negli ospedali. Le informazioni
necessarie all’attribuzione dei pazienti alle singole categorie sono facilmente ottenibili dal
sistema informativo disponibile negli ospedali. Ragione principale della scelta operata
dal Ministero della Sanitá é stata la considerazione della ‘robustezza’ del sistema DRG
A cura di: Ing. Mario Sansone 21Capitolo 2. I Sistemi Informativi Sanitari
Figura 2.6: DRG.
rispetto alla qualitá ed alla completezza delle informazioni attualmente ottenibili dalla
Scheda di Dimissione Ospedaliera (SDO) in uso presso gli ospedali dal 1991. I campi
relativi ai dati contenuti nella SDO sono stati in seguito in parte modificati sia dal
Ministero (dati minimi essenziali) che da alcune regioni per adeguarli a nuove normative.
La transcodifica é il procedimento mediante il quale i codici diagnostici del sistema
ICD-9 dell’OMS vengono convertiti a quelli dell’ICD-9-CM. Questo é necessario perché
il software Grouper, che attribuisce i DRG, é stato predisposto per utilizzare la classifi-
cazione delle malattie ICD-9-CM che é quella utilizzata negli USA. La transcodifica puó
causare alcune difficoltá pratiche nella definizione del DRG1 .
I gruppi diagnostici principali (MDC, Major Diagnostic Category) sono i gruppi di
diagnosi che formano la struttura del sistema di classificazione DRG. Sono 25 (vedi tab.
2.1)
Le MDC sono costruite per fornire ai DRG una struttura che dia significativitá e
coerenza clinica, e rispondono a criteri anatomici, eziologici e di specialitá clinica simili
a quelli che caratterizzano i settori diagnostici della classificazione internazionale ICD-9.
L’assegnazione di un caso ad una specifica MDC avviene in base alla diagnosi principale
di dimissione e rappresenta la prima fase del processo di attribuzione del DRG.
Ciascun caso dimesso viene attribuito ad uno specifico DRG da un software (Grouper)
che, fra le informazioni contenute nella scheda di dimissione, utilizza sempre quelle rela-
tive alla diagnosi principale e agli eventuali interventi chirurgici o procedure, e le infor-
mazioni relative a sesso, etá, stato alla dimissione e diagnosi secondarie, se presenti. Nel
caso le diagnosi vengano ancora codificate secondo la 9a revisione della classificazione
internazionale delle malattie (ICD-9), mentre il Grouper é stato costruito per utilizzare i
codici della sua modificazione clinica (ICD-9-CM) utilizzata negli USA, é indispensabile
una transcodifica per riconoscere la maggioranza dei codici di diagnosi. La logica del
funzionamento del sistema di é la seguente: il software individua la diagnosi principale
dalla scheda nosologica ed in base a questa sceglie la MDC appropriata. Valuta poi la
1
Dal Gennaio 2000 alcune Regioni hanno adottato ufficialmente la classificazione ICD9-CM per la
compilazione della SDO, come da indicazione ministeriale. A tutt’oggi alcune Regioni non si sono
ancora adeguate. É necessario inoltre far notare come l’OMS abbia nel frattempo aggiornato piú volte
la classificazione ICD e lo stesso avviene, con frequenza annuale, per l’ICD9-CM, aggiornata con la
costante collaborazione delle societá medico scientifiche USA.
A cura di: Ing. Mario Sansone 22Capitolo 2. I Sistemi Informativi Sanitari
1 Malattie e disturbi del sistema nervoso
2 Malattie e disturbi dell’occhio
3 Malattie e disturbi dell’orecchio, del naso e della gola
4 Malattie e disturbi dell’apparato respiratorio
5 Malattie e disturbi dell’apparato cardiocircolatorio
6 Malattie e disturbi dell’apparato digerente
7 Malattie e disturbi epatobiliari e del pancreas
8 Malattie e disturbi dell’apparato muscoloscheletrico e connettivo
9 Malattie e disturbi della pelle, del sottocutaneo e della mammella
10 Malattie e disturbi endocrini, metabolici e nutrizionali
11 Malattie e disturbi del rene e delle vie urinarie
12 Malattie e disturbi dell’apparato riproduttivo maschile
13 Malattie e disturbi dell’apparato riproduttivo femminile
14 Gravidanza, parto e puerperio
15 Malattie e disturbi del periodo neonatale
16 Malattie e disturbi del sangue e degli organi ematopoietici e del sistema
immunitari
17 Malattie e disturbi mieloproliferativi e tumori poco differenziati
18 Malattie infettive e parassitarie (sistematiche)
19 Malattie e disturbi mentali
20 Uso di alcool o farmaci e disturbi mentali organici indotti da alcool o farmaci
21 Traumatismi, avvelenamenti ed effetti tossici dei farmaci
22 Ustioni
23 Fattori influenzanti lo stato di salute ed il ricorso ai servizi sanitari
24 Traumi multipli significativi
25 Infezioni da HIV.
Tabella 2.1: Major Diagnostic Category
A cura di: Ing. Mario Sansone 23Capitolo 2. I Sistemi Informativi Sanitari
presenza o meno di interventi chirurgici e, successivamente, dopo aver preso in consid-
erazione le altre informazioni presenti attribuisce il DRG. Infine, l’attribuzione al DRG
dipende anche da:
• etá del paziente (in particolare, alcuni DRG sono relativi a pazienti: > 17 anni,
< 18 anni, > 35 anni, < 36 anni);
• presenza o meno di patologie secondarie ossia di complicanze (la complicanza viene
individuata in relazione alla diagnosi principale)
• stato alla dimissione: vivo, deceduto, dimesso contro il parere dei sanitari, trasfer-
ito ad altro reparto
• peso alla nascita
Il processo di cura viene quindi esaminato mediante alcune delle variabili presenti
all’interno della scheda di dimissione.
2.3.1 Indici di efficienza
Detti:
Dj la degenza media del DRGj nello standard,
Pj la proporzione dei ricoveri per il DRGj nello standard
P
Dst la degenza media nello standard, data da j Dj · Pj
dij la degenza media del DRGj nel reparto i-esimo
pij la proporzione dei ricoveri per il DRGj nel reparto i-esimo
L’indice di Case-Mix (ICM), o grado di complessitá dei casi trattati, del reparto
P
i-esimo é definito come: ICM = j DDj ·pstij
Se ICM > 1 la casistica del reparto i-esimo é piú complessa dello standard, se
ICM < 1 la casistica é meno complessa dello standard.
L’indice comparativo di performance (ICP), che valuta l’efficienza della struttura
P
rispetto alla media, del reparto i-esimo é definito come: ICP = j PDj ·dstij
Un ICP < 1 indica buona efficienza del reparto i-esimo, mentre un ICP > 1 indica
una cattiva efficienza.
2.4 Scheda di Dimissione Ospedaliera (SDO)
É uno strumento informativo per la raccolta dei dati relativi ai singoli dimessi dagli
istituti di ricovero ospedaliero; costituisce la sintesi delle informazioni contenute nella
cartella clinica. La identificazione delle informazioni da rilevare attraverso la scheda di
dimissione e le relative modalitá di compilazione e codifica sono disciplinate dal D.M.
28.12.91 e dal D.M. 26.07.93. A far data dal 1 gennaio 2001, la nuova disciplina della
SDO é stabilita dal decreto ministeriale 27 ottobre 2000, n. 380.
A cura di: Ing. Mario Sansone 24Capitolo 2. I Sistemi Informativi Sanitari
La tabella seguente riporta i codici presenti nella SDO per identificare il tipo di
stato alla dimissione, nella tabella successiva sono riportati i dati presenti nella SDO (la
lunghezza di un campo é espressa in caratteri ).
Codici stato alla dimissione
01 dimesso a domicilio
02 trasferito ad altro ospedale per acuti
03-06 trasferito ad altro ospedale per acuti
07 dimesso contro il parere dei sanitari
20 deceduto
Nome del campo Lunghezza Descrizione
INPUT
Et 3 0-124
Sex 1 1:Maschio,2:Femmina
DSP 2 Stato alla dimissione
DX1 5 Diagn. principale(ICD-9-CM)
DX2 5 Diagn. Secondaria(ICD-9-CM)
DX3 5 Diagn. Secondaria(ICD-9-CM)
DX4 5 Diagn. Secondaria(ICD-9-CM)
Proc1 4 Procedura/Interv. (ICD-9-CM)
Proc2 4 Procedura/Interv. (ICD-9-CM)
Proc3 4 Procedura/Interv. (ICD-9-CM)
Proc4 4 Procedura/Interv. (ICD-9-CM)
2.5 Centro Unificato di Prenotazione (CUP)
Il CUP consente di ottimizzare le risorse, riducendo contemporanemente le liste di attesa
all’interno di una singola struttura ospedaliera.
A livello regionale un sistema CUP puó gestire l’accessibilitá alle prestazioni erogate
da tutto il SSR (Servizio Sanitario Regionale), in maniera semplice per il cittadino che
ha a disposizione una varietá di opzioni di accesso (sportelli CUP, farmacie, telefono,
web), con la possibilitá di ottimizzazione una serie di parametri: ad es. scegliendo la
prestazione piú conveniente in termini geografici, temporali, tecnologici, professionali.
2.6 Radiology Information System (RIS)
Il RIS (Sistema Informativo di Radiologia) fornisce supporto alla attivitá di preno-
tazione esami, refertazione, archiviazione e interrogazione della base dati delle immagini
radiologiche.
Nei sistemi RIS un componente importante é il sistema PACS 2 (Picture Archiving
2
Per la sua vocazione prevalente alla gestione delle immagini puó essere considerato un sistema
indipendente.
A cura di: Ing. Mario Sansone 25Capitolo 2. I Sistemi Informativi Sanitari
and Communicatiosn System) cioé il sistema di gestione delle immagini (trasferimento
dalle apparecchiature radiologiche ai sistemi di archiviazione, stampa etc. . . . ).
Il Sistema Informativo Radiologico costituisce in pratica un piccolo Sistema Infor-
mativo Sanitario a sé stante. La forza di un sistema del genere é basato sulla possibilitá
di scambiare immagini diagnostiche, corredate di numerosi dati, quali ovviamente quelli
anagrafici (ma volendo, anche clinici), grazie all’utilizzo di un protocollo comune (ad
esempio, DICOM).
La possibilitá di disporre le immagini diagnostiche é un notevole punto di forza in un
sistema ospedaliero. Il vantaggio indiscusso é quello di spostare le informazioni senza
spostare in pratica gli operatori: si aprono scenari di lavoro cooperativo, refertazioni
guidate a distanza, ma anche semplice invio di dati al fine di stampa o consultazione.
Ma i vantaggi non sono finiti qui: il radiologo ha la possibilitá infatti di intervenire
sull’immagine variandone le caratteristiche (ad esempio di contrasto e luminositá) anche
molto tempo dopo l’esame, mettendo in evidenza i particolari che piú gli interessano.
Si intuisce come l’integrazione del RIS all’interno di un piú ampio Sistema Informa-
tivo Ospedaliero costituisca una scelta obbligata da un lato ed un vantaggio indiscusso
dall’altro.
2.6.1 DICOM
La possibilitá di scambiare immagini mediche corredate da varie informazioni attraverso
reti telematiche, fa sorgere l’esigenza di uno standard di comunicazione globale. Ció
offrirebbe al radiologo la possibilitá di consultare tutti gli esami dello stesso paziente
contemporaneamente ed in un solo posto, ed al medico di reparto di accedere immedi-
atamente alle immagini, attraverso un collegamento in rete locale.
Uno standard, infatti, consiste in un insieme di norme fissate allo scopo di ottenere
l’unificazione delle caratteristiche di una determinata prestazione o processo tecnologico,
da chiunque o comunque prodotto.
DICOM (Digital Imaging and Communication in Medicine) rappresenta un mod-
ello di tale standardizzazione, la cui nascita é stata peró inizialmente ostacolata dalla
pluralitá di produttori di hardware in campo medico, i quali, proponendo standard pro-
prietari avevano creato una situazione di completa incomunicabilitá tra apparecchi di
case costruttrici differenti. Tale fatto, non favorendo il decollo commerciale, ha portato
l’organismo che rappresenta i costruttori Americani, la NEMA, ad affrontare il problema
della standardizzazione. DICOM rappresenta il risultato di tale impegno.
DICOM puó essere considerato una evoluzione del PACS, in quanto prevede l’in-
terconnessione sia meccanica che elettrica delle apparecchiature con costi e difficoltá
minori ed una manutenzione semplificata. Come possiamo vedere nella figura 2.7, in
cui é rappresentato uno schema di un dipartimento di immagini completamente infor-
matizzato, DICOM offre molteplici vantaggi. Infatti consente sia l’utilizzo di un unico
sistema di documentazione (stampante laser) e di memorizzazione, sia il collegamento
diretto bidirezionale ai sistemi informativi di reparto (RIS) ed ospedaleri (HIS), oltre
che la comunicazione all’esterno con altri ospedali o con Internet.
A cura di: Ing. Mario Sansone 26Capitolo 2. I Sistemi Informativi Sanitari
Figura 2.7: Architettura di rete DICOM.
L’introduzione di DICOM si é resa necessaria per superare i problemi nel campo delle
immagini radiologiche, adesso anche altre branche mediche specialistiche tipo Odontoia-
tria e Dermatologia producono immagini, risulta quindi opportuno andare a verificare
se anche in questi campi DICOM puó produrre dei vantaggi. A tal proposito sono nati
dei gruppi di lavoro in collaborazione con la ACR-NEMA.
In Europa DICOM é in sperimentazione presso l’Universitá di Ginevra nell’ambito
del progetto PAPYRUS. La stessa Comunitá Europea nell’ambito di CEN/TC 251
(http://miginfo.rug.ac.ac.be:8001/index.htm) sta studiando le funzionalitá dello stan-
dard DICOM a confronto con lo standard SPI (Standard Product interconnect) proposto
da Philips (http://www.philips.com/ms/) e Siemens (http://www.siemens.de/med).
2.7 HL7
L’esigenza di condividere i dati clinici dei pazienti all’interno della struttura ospedaliera
e in modo piú ampio fra centri di cura remoti e sul territorio (medici di base, unitá
sanitarie, farmacie, abitazione dei pazienti) é sentita da sempre.
Le motivazioni che spingono in questa direzione sono principalmente la possibilitá di
pervenire a:
• miglioramento dell’assistenza al paziente attraverso un’analisi completa della sua
storia clinica;
A cura di: Ing. Mario Sansone 27Capitolo 2. I Sistemi Informativi Sanitari
• miglioramento dell’organizzazione dell’assistenza sanitaria attraverso la riduzione
delle consulenze esterne e dei tempi di attesa;
• efficace e tempestiva assistenza diagnostica e terapeutica per i centri periferici, con
disponibilitá immediata di consulenze specialistiche;
• riduzione dei disagi per il paziente, che puó evitare spostamenti, e di costi per la
struttura e per la comunitá;
• miglioramento delle possibilitá di analisi e ricerca a partire da database clinici
omogenei e completi.
Fino ad oggi la difficoltá di pervenire ad una condivisione di informazione clinica
attraverso basi di dati eterogenee é stata grande, a causa della diversitá di piattaforme
software, di struttura dei database e di connessione fra i vari luoghi di deposito dei dati.
Gli approcci a questo problema sono sostanzialmente due: il primo, portato avanti
fin dagli esordi dell’informatica clinica, tende a perseguire la codifica e la traduzione dei
documenti clinici in un vocabolario controllato. Ma la difficoltá di ottenere una codifica
realmente universale é enorme, ed il sistema di codifica decurta il documento clinico della
ricchezza informativa del linguaggio naturale. Inoltre sono sempre necessarie soluzioni
locali di condivisione fra piattaforme e software differenti
L’altro approccio é quello cosiddetto document-centered, che renda il documento
indipendente da software e da piattaforma e consenta uno scambio di informazione
completo, semplice ed immediato.
Lo sforzo di standardizzazione dello scambio di documenti ha portato alla creazione
di insiemi di specifiche, fino all’approvazione dello HL7 (Health Level 7) come standard
ANSI nel 1997.
HL7 (Health Level 7) é una specifica per lo scambio di dati elettronici fra istituzioni
di cura e fra differenti sistemi informativi.
La HL7 PRA (Patient Record Architecture - Architettura del Record Paziente, o
anche la CDA Clinical Document Architecture) definisce la semantica ed i vincoli strut-
turali necessari per lo scambio di documenti clinici, cioé definisce la struttura minima
della cartella clinica.
L’architettura é indipendente dalla piattaforma e da software proprietario ed é
specificata in XML.
Ogni documento PRA consiste di uno header e di un body. Lo header fornisce
dei metadati che identificano e classificano il documento, mentre il body supporta la
visualizzazione dei dati.
Le finalitá di un PRA HL7 sono:
• utilizzo di uno standard open;
• supporto allo scambio di documenti fra utenti remoti;
• supporto alla loro elaborazione successiva;
• preparazione veloce dei progetti di documenti clinici.
L’architettura si propone di essere compatibile XML e minimizzare le barriere tec-
niche, con minimi vincoli o richieste sulla struttura dei documenti.
A cura di: Ing. Mario Sansone 28Capitolo 2. I Sistemi Informativi Sanitari
La PRA é un’architettura multilivello. Il concetto di livello si riferisce a diversi gradi
di granularitá dei markup richiesti, di pari passo con la profonditá dell’informazione
clinica.
LIVELLO 1 (Coded Header) É la specificazione della struttura del documento.
Non e’ richiesta semantica.
LIVELLO 2 (Coded Structure) É possibile condividere anche la semantica dei doc-
umenti, identificando sezioni e sottosezioni con titolo codificato (ad esempio: una
sezione Anamnesi con sottosezione Storia della patologia attuale). Il Livello 2
specifica dei markup per queste sottostrutture. Grazie al Livello 2 e’ possibile l’
estrazione e compilazione dalla scheda di dimissione, creata anche per dettatura,
o di liste di consigli di terapia. Il Livello 2 dovra’ avere un DTD di specifica che
determini la tipologia del documento clinico e un catalogo di possibili sezioni e
sottosezioni.
LIVELLO 3 (Coded Content) Il Livello 3 richiede un’articolazione semantica com-
pleta. Un documento di Livello 3 puó essere elaborato dai riceventi con algoritmi
di analisi di qualsivoglia complessitá che riconoscano i suoi markup.
Oltre alla struttura della cartella clinica, HL7 definisce anche i cosiddetti eventi
Trigger cioé eventi che scatenano un flusso di informazioni all’interno della struttura
sanitaria (ad es. la accettazione di un paziente implica l’aggiornamento della anagrafica
pazienti ma anche del sistema di gestione dei posti letto). A tali eventi corrispondono
pertanto dei messaggi che i vari sottosistemi informativi si scambiano per tenersi aggior-
nati l’uno con l’altro (ad es. il sistema di prenotazione esami e quello amministrativo
devono essere sempre sincronizzati tra loro per consentire di calcolare efficientemente il
DRG all’atto della dimissione).
Lo sviluppo dello standard HL7 e la sua economicitá e semplicitá fanno prevedere
una rapida diffusione di questa tecnologia.
Molte case di software sanitario negli Stati Uniti stanno incorporando PRA nei loro
sistemi di sviluppo, perché si tratta di una soluzione realmente percorribile al problema
di codifica, scambio e conservazione dei documenti clinici
2.8 Sicurezza
I requisiti per un sistema sicuro di scambio di documenti elettronici sono:
Consenso il mittente deve esprimere consenso sul contenuto.
Paternitá la paternit di un documento digitale deve essere garantita.
Integritá il messaggio non deve essere contraffatto dagli altri utenti incluso il desti-
natario.
Autenticitá il destinatario possa verificare l’identitá del mittente.
A cura di: Ing. Mario Sansone 29Puoi anche leggere
