Introduzione ai Sistemi Informativi Sanitariapinto/introSIS.pdf · Capitolo 1 Introduzione ai...

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 Entita 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) puo essere definito come l’insieme dei flussi di informazionegestiti 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 (cioe utilizzate peril perseguimento degli scopi dell’organizzazione).

Ogni organizzazione ha un sistema informativo, eventualmente non esplicitato nellastruttura; quasi sempre, il sistema informativo e di supporto ad altri sotto-sistemi, e vaquindi studiato nel contesto in cui e inserito; il sistema informativo, e di solito suddivisoin sotto-sistemi (in modo gerarchico o decentrato), piu o meno fortemente integrati.

Un sistema informativo puo essere automatizzato in parte o del tutto con le modernetecnologie dell’informazione. I componenti di un sistema informativo automatizzato sonoessenzialmente i processi, la base dati ed il DBMS (fig. 1.1).

1.1 Processi e dati

Un processo e un insieme di attivita (sequenze di decisioni e azioni) che l’organiz-zazione svolge per realizzare un risultato definito e misurabile (prodotto o servizio), chetrasferisce valore al fruitore del prodotto o servizio, che contribuisce al raggiungimentodella missione dellorganizzazione.

Da un punto di vista informatico, un processo e 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 entita del mondo reale(ad es. paziente, personale medico, terapie, esami di laboratorio etc. . . . ) che devonoessere gestite.

I dati possono essere classificati in:

Dati anagrafici descrivono attributi costanti delle entita (nome, cognome, codicefiscale etc. . . . )

Dati di stato descrivono le condizioni in cui si trovano le entita (diagnosi, terapiacorrente, etc. . . . )

Dati sugli eventi descrivono le operazioni compiute sulle entita (esame diagnostici,cambiamento di terapia, interventi chirurgici, etc. . . . )

Le operazioni che e 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 modalita di effettuazione di tali operazioni puo 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 e 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


Figura 1.2: Classificazione dei processi secondo la modalita di accesso ai dati.

1.2 DBMS

Il Data Base Management System e un sistema software che standardizza l’accesso deiprocessi alla base di dati offrendo delle interfacce generalizzate che permettono:

• la condivisione dei dati da parte dei processi (i dati possono essere utilizzati dapiu processi e da piu utenti);

• l’indipendenza dei dati rispetto ai processi (se i processi vengono cambiati non enecessario 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’efficienzadipende sia dalle tecniche utilizzate per l’implementazione del DBMS che dallabonta della realizzazione della base in fase di progettazione;

efficace rendendo produttive le attivita dei suoi utilizzatori.

L’architettura di un DBMS e definita da vari schemi che rappresentano la base datia 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. uncerto utente (personale dell’accettazione) non ha bisogno di ‘vedere’ l’intera basedati ma solo una parte di essa.

schema fisico rappresentazione dello schema logico per mezzo di strutture fisiche dimemorizzazione.

1.3 Il modello Entita Relazione

Nel progetto di una base dati si procede per livelli di raffinamento successivi. In questocontesto e rilevante il modello entita-relazione (E-R) che consente di trarre una de-scrizione a livello logico della base dati. Tale descrizione puo essere poi efficacementeimplementata in un DBMS.



Figura 1.3: Simboli usati per la costruzione dei diagrammi E-R.

I componenti del modello E-R sono (fig. 1.3, 1.4):

Entita oggetti sui quali si memorizza informazione; hanno associati degli attributi (ades. ‘Nome’ e ‘Cognome’ sono attributi dell’entita ‘Persona’).

Relazioni definiscono rapporti tra le entita (ad es. ‘Impiegato’ e dipendente di ‘Azien-da’); possono avere anch’esse degli attributi.

In questo modello la struttura del Database e composta da:

• Un insieme di diagrammi ER che rappresentano i dati operativi che devono esserestrutturati 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 integrita sui dati che specificano condizioni particolariche non possono essere desunte dai diagrammi (ad es. l’eta di una persona e unnumero che non puo essere negativo).



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 alformalismo 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 elaboratinel sistema (fig. 1.5).

I DFD descrivono le operazioni effettuate sui dati e le dipendenze funzionali che sicreano in virtu dei flussi di informazione esistenti tra i diversi processi.

Utilizzano una notazione grafica che si concentra sull’elaborazione funzionale, lamemorizzazione dei dati e il passaggio di dati tra funzioni.

Nella figura 1.6 e rappresentato un esempio di processo di monitoraggio pazientemodellato con la metodologia DFD.

1.5 I DBMS relazionali

Il modello relazionale dei dati e il modello che si e affermato sin dagli anni ’70 per iDBMS.

In questo modello le entita e le relazioni (derivate dal diagramma E-R) sono rapp-resentate mediante tabelle. In ogni riga (denominata anche record) di tali tabelle sonoscritti gli attributi della entita o della relazione in esame. Ad esempio la tabella seguenterappresenta gli attributi dell’entita ‘persona’.



Figura 1.5: Simboli usati per la costruzione dei diagrammi DFD.

Figura 1.6: Modello di un processo di monitoraggio paziente mediante DFD.



Tabella ‘persona’Codice Fiscale Nome Cognome Eta

RSSMRA Mario Rossi 32MNDLCA Lucia Mondella 27

Ogni tabella e caratterizzata da uno schema, cioe da una struttura che indica il tipodi valore inserito in una data colonna della tabella ad es.:

(Codice Fiscale, Nome, Cognome, Eta)

Nello schema precedente il campo sottolineato indica una chiave cioe un tipo divalore che puo 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 e opportuno disporre di opportunilinguaggi.

Lo standard in questo senso e il linguaggio SQL (Structured Query Language, Lin-guaggio per interrogazioni strutturate). Senza entrare nel dettaglio di tale linguaggiodiamo un esempio di come sia possibile effettuare una interrogazione su una base dati:

SELECT Nome, Eta FROM Persona WHERE Cognome=’Rossi’;

Questa interrogazione preleva il Nome e l’Eta (SELECT Nome, Eta) dalla tabel-la ’Persona’ (FROM Persona) di tutte le persone che si chiamano Rossi di cognome(WHERE Cognome=’Rossi’).

Il SQL e 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 deiprocessi.

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 controllocentralizzato e della gestione del sistema, delle prestazioni, dell’affidabilita, delleautorizzazioni. Le funzioni del DBA includono quelle di progettazione, anche sein progetti complessi ci possono essere distinzioni.

Utenti finali Sono gli utenti quotidiani del sistema. Di norma essi hanno diritti diaccesso ai dati limitati; vengono identificati medianteusername e password.



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 uncomputer server il quale a sua volta inoltra la richiesta nel linguaggio idoneo per ilDBMS che gestisce la base dati. La risposta del DBMS viene interpretata e riformattataopportunamente dal server ed inviata da questi al client. Pertanto il server intermedioha il compito di interrogare la base dati e formattare adeguatamente le risposte per ilclient (architettura three-tier).

Allo stato attuale quasi tutti i DBMS disponibili in commercio utilizzano l’architet-tura client-server. Tra i piu 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 stessoedificio o in edifici diversi e situati nell’arco di pochi Km. Le WAN (Wide Area Networks)inter-connettono varie LAN.

La piu comune topologia di rete e quella a BUS (fig. 1.8). Con queste topologie disolito si utilizza un controllo casuale di trasmissione: un calcolatore invia un pacchettoin 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 loignorano.

La rete Ethernet e 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 sulmezzo di trasmissione non ne stia viaggiando gia un altro. Se si genera una collisioneviene rinviato il pacchetto.

Nelle reti di computer vengono trasmessi pacchetti di dati. Ogni singolo pacchettodi dati subisce una complessa trasformazione (incapsulamento) prima di essere inviato



Figura 1.8: Rete a BUS.

sulla rete. Il meccanismo di incapsulamento dei dati e 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 conl’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 unnumero (indirizzo IP).

Quando si vuole colloquiare con un computer che non si trova sulla stessa rete localebisogna trasferire i pacchetti alle altre reti in maniera simile a quanto succederebbe seuna persona di Napoli volesse comunicare con una persona di Milano tramite posta:la lettera spedita verrebbe intercettata dall’ufficio postale principale Napoletano che lospedirebbe a quello Milanese ed a quel punto tramite dei sottouffici e infine tramite ilpostino 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 dismistamento.

Infine poiche i numeri sono difficili da ricordare per gli esseri umani esiste un sistemadi codifica degli indirizzi IP che associa ad ogni indirizzo un nome. Esistono pertanto deicomputer (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 ) e un linguaggioper la rappresentazione dei dati in maniera testuale utilizzando dei marcatori appunto.

Chiariamo subito con un esempio. Supponiamo di avere la tabella dei dati anagraficidei pazienti:

Tabella ‘Pazienti’Codice Fiscale Nome Cognome Eta

RSSMRA Mario Rossi 32MNDLCA Lucia Mondella 27

una rappresentazione di tale tabella in un documento di testo XML e la seguente:



< TabPazienti >< Paziente >

< CF > RSSMRA < /CF >< Nome > Mario < /Nome >< Cognome > Rossi < /Cognome >< Eta > 32 < /Eta >

< /Paziente >< Paziente >

< CF > MNDLCA < /CF >< Nome > Lucia < /Nome >< Cognome > Mondella < /Cognome >< Eta > 27 < /Eta >

< /Paziente >< /TabPazienti >

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 unoslash. E importante che ogni tag aperto sia poi chiuso. Come si vede i tag possono essereinnestati l’uno dentro l’altro (ad es. < CF > e contenuto in < Paziente >). Si vedeche un record della tabella Pazienti corrisponde al contenuto di un tag < Paziente >.

Questa rappresentazione non e una semplice manipolazione della tabella perche esuscettibile di una serie di varianti che la rendono estremamente flessibile e potente.

Una delle carattersitiche piu importanti e che la sequenza dei tag puo essere dichiara-ta opzionale, cioe un campo puo essere assente (ad es. potrei non volere le Eta). Questorende il linguaggio XML in grado di mettere in comunicazione due strutture dati cheabbiano un sottoinsieme comune (ad es. in una prima struttura uso tutti i campi mentrenella seconda uso solo il CF Nome e Cognome, in questo caso per comunicare dati dallaprima verso la seconda potro indicare che il campo Eta e opzionale)

La modalita in cui i vari tag si possono innestare tra di loro, i dati opzionali, idati ripetuti (ad es. ci puo essere piu di una diagnosi) ed altre caratterstiche devonoessere 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 questomodo e possibile verificare se un documento XML e ben formato.

1.11 Cenni su HTML

HTML e un linguaggio a marcatori per la rappersentazione di documenti sul web. In ef-fetti puo essere considerato un derivato dell’XML anche se cronologicamente lo sviluppoe stato inverso (cioe prima html e poi XML).

In effetti la differenza tra XML e HTML (Hyper Text Markup Language, linguaggioper ipertesti a marcatori) consiste nel fatto che in XML i tag sono decisi dall’utenteche 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 iBrowser commercali (ad es. MS Explorer, Netscape, Opera etc.. . . ).



Facciamo un esempio di pagina HTML:

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

<meta name="GENERATOR" content="Microsoft FrontPage 3.0">

<title>Pagina di HTML</title>

</head>

<body>

<h1>Salve</h1>, <h2>sono una pagina HTML!</h2>

<a href="atrapagina.htm">Questo \’e un link</a>

</body>

</html>

Il tag < hmtl > deve essere sempre presente e racchiude l’intero documento che ecostituito da un header < head > e da un body < body >. Nell’header sono contenuteinformazioni di controllo (metadati) che servono poter interpretare corretamente il doc-umento: nell’esempio troviamo il set di caratteri ed il software che e stato usato pergenerare la pagina. Nel body invece troviamo il documento vero e proprio che verrainterpretato dal browser e visualizzato all’utente.

Ogni tag ha un significato preciso ad es. < h1 > significa che il testo va visualizzatoin grasseto con un carattere grande; < h2 > significa che il testo e un po piu piccolo:questa organizzazione serve a rendere il documento piu leggibile e renderlo visualizzabilesu qualunque dispositivo.

Un altro aspetto importante di HTML e il tag < a > (link ipertestuale) che consentedi ‘puntare’ ad un altra pagina o a un altro documento generico.


Capitolo 2

I Sistemi Informativi Sanitari

La finalita di un sistema informativo in sanita e la gestione di informazioni utili allamisura ed alla valutazione dei processi gestionali e clinici al fine di ottimizzare le risorseimpiegate nel conseguimento degli obbiettivi istituzionali e ottimizzare le modalita dicomunicazione.

Le entita coinvolte sono rappresentate nella figura 2.1 in cui sono rappresentati anchei 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 dettagliodello standard su citato, si puo comunque comprendere il concetto osservando la figura2.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 diogni accadimento, per motivi medico/legali/amministrativi.

In questo contesto il fattore centrale di tutto il sistema informativo e la cartellaclinica, sia essa cartacea o elettronica.

2.1 La cartella clinica

La finalita della cartella clinica e di facilitare la cura del paziente, avere a dispo-sizione una raccolta cronologica del processo di cura, semplificare la comunicazione frail personale, la raccolta dati a fini medico/legali, le operazioni di rimborso, le ricercheretrospettive e prospettiche.

Una storia semplificata della cartella clinica puo essere cosı riassunta:

1910 Raccolta dati orientata al paziente

1940 Ospedali Americani con accreditamento

1969 Riflessione sui modelli di cartella clinica

13

Capitolo 2. I Sistemi Informativi Sanitari

Figura 2.1: Entita coinvolte.

Figura 2.2: Flussi informativi.



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 continuita della cura

I tipi di cartella clinica proposti intorno agli anni ’70:

• Orientati temporalmente: collezione di dati sequenziali, in questo modello i dativengono raccolti ed organizzati solo in base alla sequenza temporale degli eventi.ad es.

21/02/01 Mancanza di respiro, tosse, febbre.Temp:39.3 CDiagnosi: bronchite acutaHb: 7.8 mg/dlTrattamento: 100mg Ascal/d

• Orientati alla ‘sorgente’ informativa: organizzazione temporale in una classifi-cazione per sorgente dei dati. In questo modello i dati vengono organizzati anchein base al tipo di sorgente informativa (cioe se i dati vengono da una visita, da unesame diagnostico etc. . . . ) ad es.

Visite21/02/01 Mancanza di respiro, tosse, febbre.

Temp:39.3 CDiagnosi: bronchite acutaTrattamento: 100mg Ascal/d

Esami21/02/01 Hb: 7.8 mg/dl

• Orientati al problema: organizzazione temporale in una classificazione per proble-mi. In questo modello il nucleo centrale e il problema ed i dati vengono classificatiin soggettivi ed oggettivi. ad es.

Problema Bronchite acuta21/02/01 Soggettivi: Mancanza di respiro, tosse, febbre.

Oggettivi: Temp:39.3 C, Hb: 7.8 mg/dlDiagnosi: bronchite acutaTrattamento: 100mg Ascal/d

Una interessanteclassificazione delle cartelle cliniche si fonda sull’individuazione dicategorie di pazienti rispetto ai quali esistono differenti trattamenti clinici: a causa diquesti differenti trattamenti e del tempo, nel corso del quale tali trattamenti sono effet-tuati, differenti tipologie di informazioni devono essere gestite. Si distinguono cartellecliniche per:



pazienti in terapia intensiva la cartella clinica e rivolta a pazienti in condizioni se-vere, in cui il controllo del quadro clinico e effettauto di continuo da una opportunastrumentazione. E il caso tipico della sala di rianimazione o unita coronarica. Epresente una sofisticata strumentazione in grado di monitorare di continuo alcuniparametri vitali e di generare allarmial personale in presenza di anomalie. Talestrumentazione acquisisce una grande mole di dati che puo essere memorizzataed inclusa nella cartella clinica computerizzata. Dunque il sistema informaticodi gestione dovra interfacciarsi anche con la strumentazione oltre che gestire leinformazioni 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 controllatead intervalli di tempo variabili. Qeuste cartelle si possono dividere in cartelle atermine e a tempo indefinito. Le prime sono relative a patologie che si supponevengano risolte in breve tempo, Le seconde sono relative a patologie che restanpcroniche.

In una cartella clinica orientata temporalmente vengono gestiti dati raccolti durantevisite periodiche. Un esempio di tabella orientata temporalmente e riportata di seguito:

data visita freq. card. press. max press. min

02-03-90 110 180 11004-05-90 90 145 9006-07-90 105 140 100

Il riferimento temporale cionsente di ricostruire l’andamento del quadro, la valu-tazione clinica puo essere migliorata. Tipiche categorie di pazienti sono gli ipertesi, ipazienti 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 cartaceapossono essere cosı riassunti:

• riduzione dello spazio fisico necessario per archiviare le cartelle: con i modernisistemi informatici migliaia di cartelle cliniche possono essere registrate su unHard Disks;



• possibilita di effettuare ricerche in tempi rapidissimi;• possibilita di condividere le cartelle tra i vari reparti;• possibilita di consultare i dati attraverso le reti informatiche e quindi in linea di

principio da qualunque postazione all’interno della struttura ospedaliera o dellarete sanitaria nazionale o addirittura mondiale.

Questi vantaggi si pagano pero con alcuni svantaggi:

• i dati devono essere altamente strutturati per poter essere trattati con i mezziinformatici;

• i dati devono venire digitati dall’operatore e questo puo essere un aspetto rile-vante soprattutto se vengono commessi errori; tuttavia in questo campo sono staticompiuti grossi sforzi allo scopo di semplificare la inputazione dei dati (vedi adesempio i sistemi di dettatura vocale) e nella correzione automatica di certi tipi dierrore;

• disomogeneita dei dati tra i diversi reparti. In effetti e praticamente impossibileorganizzare un sistema informativo che sia efficace ed efficiente per tutti i sotto-sistemi presenti all’interno di una struttura sanitaria: la tendenza attuale e quelladi rassegnarsi ad avere sistemi informativi diversi per ciascun reparto, ma lavo-rare nella direzione della integrazione dei vari sottosistemi mediante lo sviluppodi metodi di interfacciamento che consentano di transcodificare le informazioni daun sistema all’altro (vedi fig. 2.3 e 2.4);

• la sicurezza del dato in formato elettronico presenta forse degli aspetti piu delicatirispetto al dato cartaceo; tuttavia sono stati compiuti grossi sforzi nel campo dellasicurezza 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 identificarele generalita del paziente costituiscono la chiave per l’individuazione univoca dell’in-dividuo all’interno dell’archivio e rappresentano l’anello di collegamento con tutte lealtre informazioni che vengono progressivamente immagazzinate nel corso della degen-za e del trattamento anche in occasione di ricoveri ripetuti e contribuiscono a renderepiu rapido e sicuro lo scambio di dati tra diverse realta che vengono a contatto conlo stesso individuo. Questo, oltre a rappresentare un vantaggio per le varie strutturecoinvolte nello scambio dei dati, contribuisce a rendere piu complete le informazionirelative all’individuo consentendo un piu completo e rapido trattamento delle patologieconcomitanti.

Tra i dati anagrafici il minimo set di informazioni, indispensabili per identificareunivocamente un individuo, e rappresentato da:

COGNOMENOMEDATA DI NASCITASESSO

Mediante queste informazioni e possibile identificare univocamente la quasi totalitadelle persone ad eccezione di qualche raro caso in Italia, per il quale occorre considerare



Figura 2.3: Architettura integrata.

Figura 2.4: Architettura non integrata.



qualche altro dato. A tale riguardo una circolare del ministero della funzione pubblica,gia nel 1990, aveva individuato il codice fiscale quale sistema unitario di individuazionee di accesso dei cittadini. Per questi motivi un buon sistema di gestione della cartellaclinica dovrebbe prevedere l’utilizzo del codice fiscale come identificatore univoco dell’in-dividuo all’interno del sistema. Quando questo non e immediatamente disponibile vieneparzialmente costruito in modo automatico utilizzando il cognome, il nome, il sesso ela data di nascita (campi obbligatori) per i primi 12 caratteri, aggiungendo un numeroprogressivo di 4 cifre per distinguere eventuali individui con lo stesso codice parziale. Ilcodice cosı costruito dovra essere sostituito al piu presto con il codice fiscale completo.

E auspicabile la possibilita di collegamento con un archivio anagrafico standard messoa disposizione da altre strutture quali l’ospedale, il comune, la regione ecc.. . . , perprelevare i dati anagrafici garantendo la correttezza dei dati.

Sui dati anagrafici dovra essere possibile effettuare rapide ricerche, anche con chiaveparziale, per consentire il ritrovamento immediato di pazienti precedentemente registratied evitare inserimenti errati, come nel caso di soggetti il cui nominativo potrebbe esserescritto in modo non univoco (es. Depaoli, De Paoli, de Paoli).

A questi dati potranno essere aggiunte ulteriori informazioni ritenute di utilita nel-la gestione specifica di ogni singola realta (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 datisanitari risultano essere di importanza il ‘Tempo di transazione’ (cioe il momento in cuisi effettua l’inserimento del dato), ed il ‘Tempo di validita’ (validita del dato). Questadistinzione e cruciale per gli esami di laboratorio (che risultano significativi solo per uncerto periodo di tempo) ed anche per per giudicare l’attivita del reparto e gli esiti delprocesso clinico.

Una parola chiave nel contesto della disomogeneita delle informazioni e interoper-abilita: il modello non integrato e possibile a patto di avere uno strato software di in-termezzo (detto ‘middleware’) che deve assicurare l’interoperabilita dei sistemi informa-tivi. L’interoperabilita e la possibilita di scambiare informazioni e utilizzare proceduremediante stazioni di lavoro con caratteristiche hardware e software diverse.

In effetti allo stato attuale molti sono i software proprietari (cioe con caratteristichenon standard), ed esiste una non uniformita dei dati raccolti ed una difficolta nelloscambiare i dati con altri centri, tuttavia e pressoche impossibile pensare a sistemiinformativi completamente integrati.

Tale considerazione risulta ancora piu critica nell’area clinica della terapia intensiva,in cui la struttura organizzativa e la dinamica dei flussi informativi risultano spessofortemente dipendenti dalle realta locali, cosı da rendere difficilmente trasportabili soft-ware preconfezionati che avrebbero costretto l’utente di tali prodotti ad adeguare ilproprio modo di lavorare a degli standard non perche considerati superiori, ma soloperche imposti dal sistema. Quindi nonostante l’impegno di numerose case di softwarenella progettazione di cartelle cliniche sofisticate, in grado di contenere infinite quantitadi informazioni, la maggior parte delle esperienze si sono rivelate fallimentari.



E necessario pertanto l’adeguamento del prodotto al modo di operare della singolarealta in modo da incidere minimamente sui metodi e sulle abitudini di lavoro consideran-do assolutamente indispensabile l’adeguamento del software alla struttura piuttosto cheviceversa. Questo naturalmente comporta una notevole personalizzazione del ‘prodotto’cartella clinica rendendo difficilmente trasportabile un software, anche se ottimo, dauna realta operativa ad un’altra, con la richiesta di una elevata disponibilita di risorse ecompetenze specifiche, non solo tecniche ma anche organizzative, non sempre facilmentereperibili.

La vera possibilita di standardizzazione non sta quindi nell’adozione di cartellecliniche uguali per tutti e che gestiscono le stesse informazioni, quanto piuttosto nellostabilire un numero minimo di informazioni che ciascun sistema deve contenere lascian-do all’iniziativa del singolo l’integrazione con dati che si adeguano alle necessita impostedal sistema di lavoro e dal flusso di informazioni che la singola realta decide di trattare.

La standardizzazione e l’adeguamento al minimo set di informazioni non sara quindiun obiettivo ma una necessita qualora si richieda al sistema di colloquiare con un altro.Tuttavia poiche e auspicabile che una cartella clinica di reparto sia in grado di scambiaredati con cartelle cliniche di altri reparti, con l’intero sistema informativo ospedaliero econ reparti di altri ospedali, tale standardizzazione risulta pressoche indispensabile.Questo e in linea con quanto ribadito da una buona parte della letteratura che ritieneprioritario lo studio dei flussi informativi, indipendentemente dagli strumenti utilizzatiper la gestione delle informazioni.

2.2 Hospital Information System (HIS)

Si potrebbe definire un HIS (in italiano Sistema Informativo Ospedaliero - SIO) comeil 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-tabilita analitica, generale, fatturazione, ordini, rilevazione presenze e gestionepersonale), sia quelle piu generalmente volte a garantire l’erogazione di servizidi 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: tradizionalmentele informazioni processate sono quelle relative alla cartella clinica (generalita, datianamnestici, obiettivita, terapie, . . . ) ed al monitoraggio strumentale di parametriclinici 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).



Figura 2.5: Hospital Information system.

Sottosistema di prenotazione rappresenta il sistema di gestione degli accessi delpaziente alla struttura ospedaliera (prenotazione esami, visite ambulatoriali, ri-coveri). Risulta, pertanto, fortemente integrato con i sottosistemi di gestione deipaziente e dei servizi.

2.3 Diagnosis Related Group (DRG)

Il DRG/ROD (Raggruppamenti Omogenei di Diagnosi) e un metodo per la classifi-cazione dei pazienti dimessi dagli ospedali 2.6. Il sistema DRG e un sistema di classi-ficazione che si basa su raggruppamenti omogenei di diagnosi, traduzione italiana delsistema statunitense noto con la sigla DRG (Diagnosis Related Groups). E un sistemadi classificazione dei pazienti dimessi dagli ospedali per acuti che attualmente viene uti-lizzato anche in Italia come base per il finanziamento delle Aziende Ospedaliere. Talesistema si basa su alcune informazioni contenute nella scheda di dimissione ospedaliera(SDO) ed individua circa 500 classi di casistiche, tendenzialmente omogenee per quantoriguarda il consumo di risorse, la durata della degenza e, in parte, il profilo clinico. Conl’applicazione di tale sistema viene introdotto nel SSN una nuova modalita di finanzia-mento delle attivita ospedaliere basato sulla remunerazione delle prestazioni mediantetariffe predeterminate.

Le informazioni necessarie all’attribuzione dei pazienti alle singole categorie sonofacilmente ottenibili dal sistema informativo disponibile negli ospedali. Le informazioninecessarie all’attribuzione dei pazienti alle singole categorie sono facilmente ottenibili dalsistema informativo disponibile negli ospedali. Ragione principale della scelta operatadal Ministero della Sanita e stata la considerazione della ‘robustezza’ del sistema DRG



Figura 2.6: DRG.

rispetto alla qualita ed alla completezza delle informazioni attualmente ottenibili dallaScheda di Dimissione Ospedaliera (SDO) in uso presso gli ospedali dal 1991. I campirelativi ai dati contenuti nella SDO sono stati in seguito in parte modificati sia dalMinistero (dati minimi essenziali) che da alcune regioni per adeguarli a nuove normative.

La transcodifica e il procedimento mediante il quale i codici diagnostici del sistemaICD-9 dell’OMS vengono convertiti a quelli dell’ICD-9-CM. Questo e necessario percheil software Grouper, che attribuisce i DRG, e stato predisposto per utilizzare la classifi-cazione delle malattie ICD-9-CM che e quella utilizzata negli USA. La transcodifica puocausare alcune difficolta pratiche nella definizione del DRG1.

I gruppi diagnostici principali (MDC, Major Diagnostic Category) sono i gruppi didiagnosi 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 significativita ecoerenza clinica, e rispondono a criteri anatomici, eziologici e di specialita clinica similia 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 principaledi 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, eta, stato alla dimissione e diagnosi secondarie, se presenti. Nelcaso le diagnosi vengano ancora codificate secondo la 9a revisione della classificazioneinternazionale delle malattie (ICD-9), mentre il Grouper e stato costruito per utilizzare icodici della sua modificazione clinica (ICD-9-CM) utilizzata negli USA, e indispensabileuna transcodifica per riconoscere la maggioranza dei codici di diagnosi. La logica delfunzionamento del sistema di e la seguente: il software individua la diagnosi principaledalla scheda nosologica ed in base a questa sceglie la MDC appropriata. Valuta poi la

1Dal Gennaio 2000 alcune Regioni hanno adottato ufficialmente la classificazione ICD9-CM per lacompilazione della SDO, come da indicazione ministeriale. A tutt’oggi alcune Regioni non si sonoancora adeguate. E necessario inoltre far notare come l’OMS abbia nel frattempo aggiornato piu voltela classificazione ICD e lo stesso avviene, con frequenza annuale, per l’ICD9-CM, aggiornata con lacostante collaborazione delle societa medico scientifiche USA.



1 Malattie e disturbi del sistema nervoso2 Malattie e disturbi dell’occhio3 Malattie e disturbi dell’orecchio, del naso e della gola4 Malattie e disturbi dell’apparato respiratorio5 Malattie e disturbi dell’apparato cardiocircolatorio6 Malattie e disturbi dell’apparato digerente7 Malattie e disturbi epatobiliari e del pancreas8 Malattie e disturbi dell’apparato muscoloscheletrico e connettivo9 Malattie e disturbi della pelle, del sottocutaneo e della mammella10 Malattie e disturbi endocrini, metabolici e nutrizionali11 Malattie e disturbi del rene e delle vie urinarie12 Malattie e disturbi dell’apparato riproduttivo maschile13 Malattie e disturbi dell’apparato riproduttivo femminile14 Gravidanza, parto e puerperio15 Malattie e disturbi del periodo neonatale16 Malattie e disturbi del sangue e degli organi ematopoietici e del sistema

immunitari17 Malattie e disturbi mieloproliferativi e tumori poco differenziati18 Malattie infettive e parassitarie (sistematiche)19 Malattie e disturbi mentali20 Uso di alcool o farmaci e disturbi mentali organici indotti da alcool o farmaci21 Traumatismi, avvelenamenti ed effetti tossici dei farmaci22 Ustioni23 Fattori influenzanti lo stato di salute ed il ricorso ai servizi sanitari24 Traumi multipli significativi25 Infezioni da HIV.

Tabella 2.1: Major Diagnostic Category



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 DRGdipende anche da:

• eta 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 vieneindividuata 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 presentiall’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

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 complessita dei casi trattati, del repartoi-esimo e definito come: ICM =

∑j

Dj ·pij

Dst

Se ICM > 1 la casistica del reparto i-esimo e piu complessa dello standard, seICM < 1 la casistica e meno complessa dello standard.

L’indice comparativo di performance (ICP), che valuta l’efficienza della struttura

rispetto alla media, del reparto i-esimo e definito come: ICP =∑

jPj ·dij

Dst

Un ICP < 1 indica buona efficienza del reparto i-esimo, mentre un ICP > 1 indicauna cattiva efficienza.

2.4 Scheda di Dimissione Ospedaliera (SDO)

E uno strumento informativo per la raccolta dei dati relativi ai singoli dimessi dagliistituti di ricovero ospedaliero; costituisce la sintesi delle informazioni contenute nellacartella clinica. La identificazione delle informazioni da rilevare attraverso la scheda didimissione e le relative modalita 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 dellaSDO e stabilita dal decreto ministeriale 27 ottobre 2000, n. 380.



La tabella seguente riporta i codici presenti nella SDO per identificare il tipo distato alla dimissione, nella tabella successiva sono riportati i dati presenti nella SDO (lalunghezza di un campo e espressa in caratteri ).

Codici stato alla dimissione01 dimesso a domicilio02 trasferito ad altro ospedale per acuti03-06 trasferito ad altro ospedale per acuti07 dimesso contro il parere dei sanitari20 deceduto

Nome del campo Lunghezza DescrizioneINPUTEt 3 0-124Sex 1 1:Maschio,2:FemminaDSP 2 Stato alla dimissioneDX1 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 attesaall’interno di una singola struttura ospedaliera.

A livello regionale un sistema CUP puo gestire l’accessibilita alle prestazioni erogateda tutto il SSR (Servizio Sanitario Regionale), in maniera semplice per il cittadino cheha a disposizione una varieta di opzioni di accesso (sportelli CUP, farmacie, telefono,web), con la possibilita di ottimizzazione una serie di parametri: ad es. scegliendo laprestazione piu conveniente in termini geografici, temporali, tecnologici, professionali.

2.6 Radiology Information System (RIS)

Il RIS (Sistema Informativo di Radiologia) fornisce supporto alla attivita di preno-tazione esami, refertazione, archiviazione e interrogazione della base dati delle immaginiradiologiche.

Nei sistemi RIS un componente importante e il sistema PACS 2 (Picture Archiving

2Per la sua vocazione prevalente alla gestione delle immagini puo essere considerato un sistemaindipendente.



and Communicatiosn System) cioe il sistema di gestione delle immagini (trasferimentodalle apparecchiature radiologiche ai sistemi di archiviazione, stampa etc. . . . ).

Il Sistema Informativo Radiologico costituisce in pratica un piccolo Sistema Infor-mativo Sanitario a se stante. La forza di un sistema del genere e basato sulla possibilitadi scambiare immagini diagnostiche, corredate di numerosi dati, quali ovviamente quellianagrafici (ma volendo, anche clinici), grazie all’utilizzo di un protocollo comune (adesempio, DICOM).

La possibilita di disporre le immagini diagnostiche e un notevole punto di forza in unsistema ospedaliero. Il vantaggio indiscusso e quello di spostare le informazioni senzaspostare in pratica gli operatori: si aprono scenari di lavoro cooperativo, refertazioniguidate 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 possibilita infatti di interveniresull’immagine variandone le caratteristiche (ad esempio di contrasto e luminosita) anchemolto tempo dopo l’esame, mettendo in evidenza i particolari che piu gli interessano.

Si intuisce come l’integrazione del RIS all’interno di un piu ampio Sistema Informa-tivo Ospedaliero costituisca una scelta obbligata da un lato ed un vantaggio indiscussodall’altro.

2.6.1 DICOM

La possibilita di scambiare immagini mediche corredate da varie informazioni attraversoreti telematiche, fa sorgere l’esigenza di uno standard di comunicazione globale. Ciooffrirebbe al radiologo la possibilita di consultare tutti gli esami dello stesso pazientecontemporaneamente 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 ottenerel’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 e stata pero inizialmente ostacolata dallapluralita di produttori di hardware in campo medico, i quali, proponendo standard pro-prietari avevano creato una situazione di completa incomunicabilita tra apparecchi dicase costruttrici differenti. Tale fatto, non favorendo il decollo commerciale, ha portatol’organismo che rappresenta i costruttori Americani, la NEMA, ad affrontare il problemadella standardizzazione. DICOM rappresenta il risultato di tale impegno.

DICOM puo essere considerato una evoluzione del PACS, in quanto prevede l’in-terconnessione sia meccanica che elettrica delle apparecchiature con costi e difficoltaminori ed una manutenzione semplificata. Come possiamo vedere nella figura 2.7, incui e rappresentato uno schema di un dipartimento di immagini completamente infor-matizzato, DICOM offre molteplici vantaggi. Infatti consente sia l’utilizzo di un unicosistema di documentazione (stampante laser) e di memorizzazione, sia il collegamentodiretto bidirezionale ai sistemi informativi di reparto (RIS) ed ospedaleri (HIS), oltreche la comunicazione all’esterno con altri ospedali o con Internet.



Figura 2.7: Architettura di rete DICOM.

L’introduzione di DICOM si e resa necessaria per superare i problemi nel campo delleimmagini radiologiche, adesso anche altre branche mediche specialistiche tipo Odontoia-tria e Dermatologia producono immagini, risulta quindi opportuno andare a verificarese anche in questi campi DICOM puo produrre dei vantaggi. A tal proposito sono natidei gruppi di lavoro in collaborazione con la ACR-NEMA.

In Europa DICOM e in sperimentazione presso l’Universita di Ginevra nell’ambitodel progetto PAPYRUS. La stessa Comunita Europea nell’ambito di CEN/TC 251(http://miginfo.rug.ac.ac.be:8001/index.htm) sta studiando le funzionalita dello stan-dard DICOM a confronto con lo standard SPI (Standard Product interconnect) propostoda 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 ospedalierae in modo piu ampio fra centri di cura remoti e sul territorio (medici di base, unitasanitarie, farmacie, abitazione dei pazienti) e sentita da sempre.

Le motivazioni che spingono in questa direzione sono principalmente la possibilita dipervenire a:

• miglioramento dell’assistenza al paziente attraverso un’analisi completa della suastoria clinica;



• miglioramento dell’organizzazione dell’assistenza sanitaria attraverso la riduzionedelle consulenze esterne e dei tempi di attesa;

• efficace e tempestiva assistenza diagnostica e terapeutica per i centri periferici, condisponibilita immediata di consulenze specialistiche;

• riduzione dei disagi per il paziente, che puo evitare spostamenti, e di costi per lastruttura e per la comunita;

• miglioramento delle possibilita di analisi e ricerca a partire da database cliniciomogenei e completi.

Fino ad oggi la difficolta di pervenire ad una condivisione di informazione clinicaattraverso basi di dati eterogenee e stata grande, a causa della diversita di piattaformesoftware, 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 avantifin dagli esordi dell’informatica clinica, tende a perseguire la codifica e la traduzione deidocumenti clinici in un vocabolario controllato. Ma la difficolta di ottenere una codificarealmente universale e enorme, ed il sistema di codifica decurta il documento clinico dellaricchezza informativa del linguaggio naturale. Inoltre sono sempre necessarie soluzionilocali di condivisione fra piattaforme e software differenti

L’altro approccio e quello cosiddetto document-centered, che renda il documentoindipendente da software e da piattaforma e consenta uno scambio di informazionecompleto, semplice ed immediato.

Lo sforzo di standardizzazione dello scambio di documenti ha portato alla creazionedi insiemi di specifiche, fino all’approvazione dello HL7 (Health Level 7) come standardANSI nel 1997.

HL7 (Health Level 7) e una specifica per lo scambio di dati elettronici fra istituzionidi cura e fra differenti sistemi informativi.

La HL7 PRA (Patient Record Architecture - Architettura del Record Paziente, oanche la CDA Clinical Document Architecture) definisce la semantica ed i vincoli strut-turali necessari per lo scambio di documenti clinici, cioe definisce la struttura minimadella cartella clinica.

L’architettura e indipendente dalla piattaforma e da software proprietario ed especificata in XML.

Ogni documento PRA consiste di uno header e di un body. Lo header forniscedei metadati che identificano e classificano il documento, mentre il body supporta lavisualizzazione dei dati.

Le finalita 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.



La PRA e un’architettura multilivello. Il concetto di livello si riferisce a diversi gradidi granularita dei markup richiesti, di pari passo con la profondita dell’informazioneclinica.

LIVELLO 1 (Coded Header) E la specificazione della struttura del documento.Non e’ richiesta semantica.

LIVELLO 2 (Coded Structure) E possibile condividere anche la semantica dei doc-umenti, identificando sezioni e sottosezioni con titolo codificato (ad esempio: unasezione Anamnesi con sottosezione Storia della patologia attuale). Il Livello 2specifica 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 chedetermini la tipologia del documento clinico e un catalogo di possibili sezioni esottosezioni.

LIVELLO 3 (Coded Content) Il Livello 3 richiede un’articolazione semantica com-pleta. Un documento di Livello 3 puo essere elaborato dai riceventi con algoritmidi analisi di qualsivoglia complessita che riconoscano i suoi markup.

Oltre alla struttura della cartella clinica, HL7 definisce anche i cosiddetti eventiTrigger cioe eventi che scatenano un flusso di informazioni all’interno della strutturasanitaria (ad es. la accettazione di un paziente implica l’aggiornamento della anagraficapazienti ma anche del sistema di gestione dei posti letto). A tali eventi corrispondonopertanto 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 amministrativodevono essere sempre sincronizzati tra loro per consentire di calcolare efficientemente ilDRG all’atto della dimissione).

Lo sviluppo dello standard HL7 e la sua economicita e semplicita fanno prevedereuna rapida diffusione di questa tecnologia.

Molte case di software sanitario negli Stati Uniti stanno incorporando PRA nei lorosistemi di sviluppo, perche si tratta di una soluzione realmente percorribile al problemadi 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.

Paternita la paternit di un documento digitale deve essere garantita.

Integrita il messaggio non deve essere contraffatto dagli altri utenti incluso il desti-natario.

Autenticita il destinatario possa verificare l’identita del mittente.



Segretezza gli interlocutori siano in grado di scambiare documenti senza che nessunoall’infuori di loro due sia in grado di leggerli.

Questi requisiti possono essere ottenuti con sistemi di crittografia.

Gli algoritmi di crittografia possono essere di due tipi: a chiave simmetrica e chiaveasimmetrica.

Negli algoritmi a chiave simmetrica il messaggio scambiato tra i due interlocutoriviene codificato mediante un codice (chiave) che e noto ad entrambi e solo ad essi.

Negli algoritmi a chiave asimmetrica vengono usate due chiavi: una chiave pubblicaed una privata. La chiave pubblica e nota a tutti mentre la chiave privata e nota solo alsuo possessore. Un messaggio codificato con la chiave pubblica puo esere decodificatosolo con la chiave privata. Pertanto per scrivere un messaggio ad Alice si usera la chiavepubblica di Alice: in questo modo saremo sicuri che solo Alice con la sua chiave privatapotra decodificare il messaggio (Segretezza).

Analogamente se ci arriva un messaggio codificato con la chiave privata di Alice,saremo in grado di decodificarlo solo con la chiave pubblica di Alice. In questo modosapremo che solo Alice puo aver inviato un certo messaggio (Paternita e autenticita)

Grazie al meccanismo della chiave pubblica e privata e possibile realizzare anche lafirma digitale dei documenti.

Dato un documento elettronico e possibile calcolare mediante una funzione hash (cioeuna funzione che associa ad un documento un valore numerico unico) una improntadigitale del documento. Il creatore del documento puo codificare l’impronta digitale conla sua chiave privata (l’impronta codificata viene detta firma digitale).

Quindi invia il documento non codificato assieme alla firma digitale.

Colui che riceve il documento puo ricalcolare l’impronta digitale e verificare se cor-risponde alla impronta che ottiene decodificando la firma digitale con la chiave pubblicadi colui che ha inviato il documento.

Una qualunque alterazione del documento o della firma digitale da parte di un terzointerlocutore farebbe sı che impronta digitale decodificata e impronta digitale ricalco-lata non coincidano. Con questo meccanismo e possibile essere sicuri dell’integrita deldocumento e dell’identita di colui che lo ha inviato 2.8.

Per le transazioni sicure su World Wide Web si utilizza attualmente il protocolloHTTPS che e una variante del protocollo HTTP cui si aggiunge il Secure Socket Layer(SSL, Strato per la sicurezza).

Questo protocollo utilizza i certificati ed entrambi i tipi di crittografia.

Si basa sull’identificazione del server (colui che fornisce un servizio su Internet).

Il protocolllo si svolge nelle fasi seguenti. il client fa una richiesta al server webHTTPS ricevendo una risposta con un certificato che attesta l’identita del server. Quindiclient e server insieme stabiliscono (con un sofisticato algoritmo) una chiave simmetricada usare negli scambi per quella sessione di comunicazione.



Figura 2.8: Firma digitale.


Introduzione ai Sistemi Informativi Sanitariapinto/introSIS.pdf · Capitolo 1 Introduzione ai...

Documents

Transcript of Introduzione ai Sistemi Informativi Sanitariapinto/introSIS.pdf · Capitolo 1 Introduzione ai...