applicazioni di sanità digitale - pinciroli bonacina

a cura diFrancesco PinciroliStefano Bonacina

Applicazioni di Sanità Digitale

Prima edizione: ottobre 2009

www.polipresseditore.it

Stampato da: Poliprint - Politecnico di Milano Piazza Leonardo da Vinci, 32 20133 Milano - Italia

Tutti i diritti riservati. Riproduzione anche parziale vietata. Nessuna parte di questa pubblicazione può essere riprodotta, archiviata in un sistema di recupero o trasmessa, in qualsiasi forma o con qualunque mezzo elettronico, meccanico, fotoriproduzione memorizzazione o altro, senza permesso scritto da parte dell’Editore.

ISBN 97888-7398-049-0

Indice

Ringraziamenti

Prefazione

Presentazione

Cap. 1 Lo scenario dei sistemi informatici clinici e sanitaridi Walter Bergamaschi, Marcello Crivellini e Francesco Pinciroli

1.1 Usuali elementi costituenti 1.1.1 ICT Ospedaliera

1.1.2 ICT Sanitaria (ASL)

1.2 Elementari prestazioni attese

1.3 Gli scenari dominanti 1.3.1 Il modello organizzativo del sistema sanitario italiano e il

sistema regionale

1.3.2 L’ospedale

1.3.3 Il medico di medicina generale

1.3.4 Il sistema di emergenza-urgenza

1.3.5 L’utente e il servizio sanitario

1.3.6 La sanità nazionale: verso il Nuovo Sistema Informativo Sanitario (NSIS)

Bibliografia

Cap. 2 Vincoli e opportunitàdi Stefano Bonacina e Francesco Pinciroli

2.1 La cartella clinica informatizzata 2.1.1 Introduzione

2.1.2 Sezioni

2.1.3 Gestione

2.1.4 Analisi e indicazioni ai clinici

2.2 Classificazioni orientate all’informatica

2.2.1“Locale” rispetto “a distanza”

2.2.2 “Dati” rispetto “segnali e immagini”

2.2.3 “Codici” e “linguaggi”

2.3 Dati e DBMS 2.3.1 I modelli di basi di dati

2.3.2 Ritorni all’utente

Bibliografia

Cap. 3 Applicazioni Sanitarie di arnesi informatici generalidi Stefano Bonacina, Silvia Navino, Giuseppe Pozzi

3.1 Sistemi cooperativi e sistemi di workflow 3.1.1 I Sistemi Cooperativi

3.1.2 Sistemi di Workgroup e di Workflow a confronto

3.1.3 Il sistema di Workgroup BSCW (Basic Support for Cooperative Work)

3.1.4 Workflow Management System (WfMS)

3.1.5 Workflow nell’Healthcare

3.2 Unified Modeling Language (UML) 3.2.1 Introduzione

3.2.2 Diagrammi

3.2.3 Vantaggi di UML

3.2.4 UML nell’Healthcare

3.3 Data Mining 3.3.1 Una definizione

3.3.2 Il processo Knowledge Discovery in Databases (KDD)

3.3.3 Data Mining

3.3.4 Applicazioni

3.3.5 Conclusioni

3.4 Catalogo di prodotti software open source per la medicina

575758

3.4.1 Breve storia dell’Open Source

3.4.2 Vantaggi del software libero

3.4.3 Svantaggi del software libero

3.4.4 Ricerca di software Open Source: criteri e modalità di lavoro adottati

3.4.5 Risultati conseguiti e loro valutazione

3.4.6 Conclusioni

Bibliografia

Cap. 4 Arnesi informatici peculiari della sanitàdi Stefano Bonacina, Mario Marchente, Silvia Navino, Francesco Pinciroli

4.1 Unified Medical Language System (UMLS) 4.1.1 Introduzione

4.1.2 La struttura generale di UMLS

4.1.3 Esempio di classificazione

4.1.4 MetamorphoSys

4.1.5 Applicazioni di UMLS

4.2 Systemized Nomenclature of Medicine (SNOMED) 4.2.1 Le origini della Systematized Nomenclature of Medicine

(SNOMED)

4.2.2 Concetti, termini e descrizioni nelle terminologie mediche

4.2.3 L’organizzazione SNOMED

4.2.4 SNOMED CT

4.2.5 Elementi di valutazione e conclusioni

4.3 Health Level 7 (HL7) 4.3.1 Introduzione

4.3.2 La versione 2.3.1 di HL7

4.3.3 La versione 3.0 di HL7

4.4 DICOM 4.4.1 Introduzione

4.4.2 DICOM e il paradigma object oriented

4.4.3 Struttura dello standard

127127

138139

164164

183183

4.4.4 Network

4.4.5 Associazioni DICOM

4.4.6 Esempi applicativi

4.5 Integrating the Healthcare Enterprise (IHE) 4.5.1 Introduzione

4.5.2 Attività

4.5.3 Aree professionali interagenti

4.5.4 Lo scenario operativo

4.5.5 Il caso della Radiologia

4.5.6 Strumenti “Medical Enterprise Simulators and Analyzers”

Bibliografia

Cap. 5 Casi di prodotti e servizidi Stefano Bonacina, Sara Marceglia, Silvia Navino, Francesco Pinciroli

5.1 Il Centro Unico di Prenotazione 5.1.1 Motivazioni

5.1.2 Organizzazione

5.1.3 Il CUP

5.1.4 Conclusioni

5.2 Registrazione elettronica dei nuovi farmaci (PharmaReg) 5.2.1 Ricerca e sviluppo per un nuovo farmaco

5.2.2 La registrazione di un nuovo farmaco

5.2.3 L’impatto del nuovo farmaco sul sistema informativo di una azienda farmaceutica

5.2.5 “Electronic submission” e eCTD

5.2.6 Conclusioni e valutazioni

5.3 Medical Knowledge Management e Semantic Web5.3.1 Introduzione

5.3.2 La situazione attuale

5.3.3 Applicazioni del web semantico nell’Health care

5.3.4 Google o UMLS?

5.3.5 Prospettive

5.3.6 Conclusione

200200

229229

248248

278278

5.4 Applicazione dei sistemi valutativi: il sistema di tracciabilità dei farmaci

5.4.1 Introduzione

5.4.2 Il sistema di tracciabilità dei farmaci

5.4.3 Il sistema di identificazione: il primo obiettivo

5.4.4 Le semplificazioni introdotte

5.4.5 Analisi dei dati raccolti

5.4.6 Possibili sviluppi futuri

5.4.7 Conclusioni

5.5 VistA5.5.1 Introduzione

5.5.2 Il Sistema Informativo VistA a supporto delle performances

5.5.3 WorldVistA

5.5.4 Il futuro di VistA

5.6 Sistemi di assistenza domiciliare 5.6.1 Definizione e caratteristiche dell’ assistenza domiciliare

(Homecare)

5.6.2 Scenario ICT per i sistemi di homecare

5.6.3 Aspetti tecnologici

5.6.4 Biostrumentazione

5.6.5 Il grado di diffusione

5.6.6 Conclusioni

5.7 Biometria per gli accessi 5.7.1 Introduzione

5.7.2 Rassegna dei dispositivi

5.7.3 Dispositivi a tecnica multipla

5.7.4 Criteri di scelta in ambito sanitario

5.8 La sanità digitale per la famiglia 5.8.1 Introduzione

5.8.2 Modellazione del sistema

5.8.3 Descrizione e implementazione del sistema

5.8.4 Elementi di valutazione (Discussione)

5.8.5 Conclusioni

Bibliografia

299299

310310

334334

355355

Ringraziamenti

Così come è successo per il precedente libro “Elementi di Informatica BioMedica”, anche questo libro, dedicato alle applicazioni, è il frutto di molti stimoli e di molti aiuti, spesso gli uni con gli altri a rincorrer-si, e nel tempo a volte a scambiarsi tra loro.

Grande stimolo e aiuto, scenario fondamentale, è il Dipartimento di Bioingegneria del Politecnico di Milano. Assieme ai collegati Consi-glio di Corso di Studi di Ingegneria Biomedica e Dottorato di Ricer-ca in Bioingegneria, il Dipartimento continua a incardinare - ad un livello di eccellenza accreditato internazionalmente - un fondamenta-le laboratorio di forgia e costruzione di avanzate tendenze formative e di ricerca. È qui che, assieme alle radici Elettrica, Meccanica e dei Biomateriali, la radice Informatica e delle Comunicazioni è chiamata - con particolare rigore - a dar prova della propria vocazione e della propria utilità per un migliore servizio al paziente, in generale trami-te coloro che - medici in prima fila - lo assistono da vicino. Grazie Politecnico.

Altro fondamentale stimolo e aiuto è quello che proviene dagli stu-denti. Nel corso degli anni recenti ho impegnato molti di loro ad analizzare e approfondire anche i temi che questo libro tratta. Non pochi studenti hanno prodotto contributi che, pur se rifatti per ge-nerare il libro, ne hanno costituto il terreno di incubazione e crescita. Grazie studenti.

Prefazione

Ogni area dell’ingegneria consiste di “fondamenti” e di “applicazio-ni”, i primi a sostenere le seconde, le seconde a motivare la utilità di apprendimento dei primi. La Bioingegneria non fa eccezioni. Al suo interno, l’Informatica BioMedica e la Sanità Digitale pure soddisfano tale dialettica.

“Elementi di Informatica BioMedica” è il libro di “fondamenti” che sostiene quanto oggetto di questo libro dedicato alla “Applica-zioni di Sanità Digitale”, queste ultime a loro volta motivano la ne-cessità di apprendimento di quegli “Elementi”. PoliPress - l’editrice del Politecnico di Milano che pubblica entrambi i libri - ha creduto in questa idea.

“Applicazioni di Sanità Digitale” apre (Cap. 1 e 2) con le de-scrizioni operative dello scenario dei sistemi informativi clinici e sanitari. È lo scenario col quale si devono fare i conti, ai vari livelli: geografico, della grande istituzione clinica, del piccolo ospedale. La descrizione indica che lo scenario rimane comunque complesso, e di tale ineludibile complessità va presa consapevolezza. Altrimenti non se ne risolvono i problemi. Per risolverne i problemi, in prima battuta è sensato tentare la via degli strumenti dell’informatica che, pur declinati per le applicazioni della clinica e della sanità, hanno origine sostanzialmente generalista (Cap. 3). Questo si deve fare. E si fa. Nondimeno, se si opera soltanto in questo modo, non si fa molta strada. Fortunatamente sono ormai svariati gli strumenti informatici di rilevante consistenza sviluppati ad hoc per la Sanità Digitale (Cap. 4). Strumenti dell’informatica generalista e strumen-ti informatici specifici della Sanità Digitale concorrono alla costru-zione di prodotti e al rilascio di servizi dei quali questo libro illustra una selezione (Cap. 5).

Se torna naturale aspettarsi che i “fondamenti” di una certa area dell’ingegneria non siano troppo rapidamente avvicendabili, tutte le “applicazioni” di informatica rimangono ancora lontane dal livello di stabilità che hanno i segmenti del mercato ritenuti maturi. Ciò avvie-ne pure nella Sanità Digitale, anche se il suo livello di disseminazione ha già raggiunto livelli elevati. Infatti, - in svariati Paesi Europei, così come in alcune regioni italiane - è già stato raggiunto direttamente il livello del cittadino, che ha in tasca la propria “carta sanitaria”. Quin-

di, per quando le “applicazioni” oggetto di questo libro diventeranno obsolete, fin da ora “arrivederci” alla prossima edizione.

Francesco PinciroliStefano Bonacina

Presentazione

dal versante del governo della salute

Se, da Assessore alla Sanità della Regione Lombardia, sono convinto sia giusto che io dedichi prioritarie attenzioni a ciò che ancora la Sa-nità Digitale non ha realizzato, da medico cardiochirurgo mi è facile riconoscere alla Sanità Digitale e alla Telemedicina meriti rilevanti, che forse hanno perso lo smalto degli onori della cronaca sulla grande stampa, ma che certo non perderanno ormai più l’efficacia quotidia-na di mostrarsi capaci di contribuire in modo determinante a salvare la vita di tanti pazienti. Valga l’esempio dei servizi di Sanità Digitale che sono impiegati dalle squadre di soccorso in regime di emergenza-urgenza per trasmettere da un mezzo mobile al Pronto Soccorso di destinazione, nei tempi brevi indispensabili per riuscire a salvare il paziente, l’elettrocardiogramma del traumatizzato raccolto dopo un incidente. Pur trovandomi io sensibile, - da sempre, da quando a Cape Town andai a fare l’assistente di Christian Barnard, all’epoca dei suoi primi trapianti cardiaci - alle sfide impossibili, ma da vincere, riconosco che la Sanità Digitale ha mietuto già molti successi, oggi normalmente disponibili al medico, a vantaggio del paziente.

Nell’ordinamento italiano, che tuttora vede il comparto della Sa-nità costituire gli otto decimi e oltre del bilancio di ogni Regione, la Sanità Digitale è un’area così estesamente percepibile dal cittadino da assegnarle anche una valenza non piccola nella raccolta del consenso politico a livello regionale. Nel caso specifico della Regione Lombar-dia, gli investimenti indirizzati alla Sanità Digitale continuano ad essere rilevanti, rimangono ampiamente focalizzati alla realizzazione del sistema CRS-SISS (Carta Regionale dei Sevizi – Sistema Informa-tivo Socio Sanitario), hanno incluso la costituzione di aziende – valga il caso di Lombardia Informatica – nelle quali le quote di proprietà regionale sono determinanti, consentendo il conseguimento di risul-tati che sono di assoluto livello internazionale. Rimane percepibile che la Sanità Digitale deve progredire nello sviluppo per soddisfare le aspettative del cittadino, in particolare dopo che nel corso degli ulti-mi due decenni, - merito di home-banking e di e-commerce, come pure delle tante foto e videocamere digitali – sono molto aumentate le consuetudini informatiche che all’interno delle famiglie vengono gestite con buon successo in prima persona. Le aspettative del cittadi-no si incardinano nel giusto desiderio di ogni paziente che i propri dati

medici, qualunque siano stati gli enti di ricovero e cura in cui lui li ha generati, in regime di ricovero o ambulatorialmente, siano facilmente, ordinatamente, efficacemente accessibili, specialmente quando egli - il paziente - è in condizioni di urgenza. Tali aspettative rimangono simili anche in altri Paesi che, di dimensione vicina al nostro, pure hanno fatto investimenti paragonabili ai nostri. Così è insospettabilmen-te presente anche nel Nordamerica, nonostante che qui l’erogazione dell’Assistenza Sanitaria non debba misurarsi con lo scenario di pari diritti sanitari per tutti i cittadini, scenario questo che invece molto positivamente caratterizza la situazione europea.

In una situazione così tesa al miglioramento ed all’espansione delle tecnologie digitali, un Ateneo di Cultura Politecnica delle tradizioni e della rilevanza anche internazionale del Politecnico di Milano, che è attivo sui temi di frontiera dell’Informatica BioMedica e della Sanità Digitale, ha - per il Governo della Salute - un valore molto grande e polivalente. È una spinta all’innovazione tecnologica non effimera, co-stituisce un versante capace di verifiche documentate al meglio dello stato dell’arte e delle applicazioni di frontiera, è una presenza dialogante capace di disseminare cultura tecnica, è un ateneo che forma una per-centuale significativa dei neolaureati italiani in Ingegneria BioMedica, che sono una risorsa umana di impagabile valore per il territorio e per l’intero Paese, per il modo col quale gli enti di governo indirizzano l’as-sistenza sanitaria e gli enti di ricovero e cura la erogano, per gli aspetti tecnologici che contribuiscono alla costruzione della qualità delle cure.

È cosa nota che la Sanità Digitale italiana riconosce in Francesco Pinciroli, e nel suo Laboratorio di Sanità Digitale al Politecnico di Mi-lano, una delle presenze italiane di rango internazionale più rilevanti. Vi aggiungo il mio personale apprezzamento per la scelta del profes-sor Pinciroli di dedicare una parte importante del proprio impegno di anni alla forma-principe dell’educazione avanzata, la forma del “libro di testo universitario”, in un’area tecnica così nuova e difficile da do-minare, nella quale libri di testo universitari sostanzialmente non ce ne sono, nemmeno in lingua inglese, con questa caratura tecnologica e con l’ampiezza dello scenario applicativo che i curatori Pinciroli e Bonacina, assieme ai loro co-autori, contemplano nel loro libro.

A questo libro “Applicazioni di Sanità Digitale” i migliori auguri di lasciare traccia, di essere di riferimento, contribuendo anche alla for-mazione continua di chi già opera in Sanità Digitale, qualunque ne sia il versante di attività, quello della domanda o quello dell’offerta, tra loro chiamati a dialogare, a beneficio del cittadino–paziente.

Luciano Bresciani Assessore alla Sanità della Regione Lombardia

Presentazione

dal versante delle risorse umane della Sanità Digitale

Per quanto la formazione curriculare e quella sul campo siano chiamate a dialogare e ad integrarsi tra loro, rimanendo la prima – così io credo – finalizzata alla costituzione e al consolidamento della seconda, va riconosciuto che nell’area della Sanità Digitale, e dei collegati sistemi informativi, i mattoni disponibili per la costruzione di una buona formazione rimangono sostanzialmente orientati alla sola formazione sul campo. Si tratta di mattoni dei quali sul campo c’è molto bisogno nella pratica e che contribuiscono alla costruzione delle specifiche abilità che concorrono alla formazione di ogni esperienza individuale, esperienza che ambisca ad un buon grado di globalità e a robustezza di impostazione. Globalità e robustezza ottenibili a fronte di un impegno e di una fatica di integrazione che rimane però lasciata in misura eccessiva sulle spalle del singolo individuo, il cui costo di formazione rimane troppo elevato non solo per lui, ma anche per l’istituzione in cui opera, come pure per il nostro intero sistema sanitario.

In uno scenario del genere la coppia di libri di Francesco Pinciroli – intendo che a questo “Applicazioni di Sanità Digitale”, curato con Stefano Bonacina, va aggiunto il precedente “Elementi di Informatica BioMedica”, curato con Marco Masseroli – sono un contributo formativo di valore inestimabile. Non solo affinché la formazione curriculare sia più pronta e meno sprovveduta ad affrontare la sua integrazione con la formazione sul campo. Ma anche per consentire a tutti coloro che solo sul campo formano la propria esperienza di raggiungere quella robustezza e quella globalità di visione senza le quali la professione di Responsabile dei Sistemi Informativi negli Enti di Ricovero e Cura e negli Enti Sanitari – è il ruolo che la terminologia inglese denomina “Healthcare Chief Information Officer” (HCIO) – non riesce ad esprimere quel “meglio di sé” del quale ogni moderna gestione dei Sistemi Sanitari ha grande bisogno. Ne ha bisogno vuoi al livello della singola regione, vuoi ai livelli sovra regionali: nazionale e internazionale. “La coppia di libri di Pinciroli, che non ha eguali nemmeno in lingue diverse dall’italiano, contribuisce a stimolare la crescita culturale della stessa AISIS, l’Associazione Italiana dei Sistemi Informativi in Sanità, oggi più che mai focalizzata a “completare ed irrobustire” il contesto professionale dei propri associati verso una

completa acquisizione ed un pieno riconoscimento del ruolo di HCIO.”

Andrea OlianiPresidente dell’AISIS

Associazione Italiana dei Sistemi Informativi in Sanità

1 Lo scenario dei sistemi informatici clinici e sanitari

1.1 Usuali elementi costituenti

Nel considerare le applicazioni per la sanità digitale è opportuno innanzitutto definire quali sono gli elementi costituenti lo scenario considerato. Lo facciamo analizzando due contesti, l’Azienda Ospe-daliera e l’Azienda Sanitaria, ed elencando le presenze di rilievo delle tecnologie dell’informazione e della comunicazione (ICT).

1.1.1 ICT Ospedaliera

Presenza di:

Elemento caratteristico Numerosità e/o specializzazioni

Posti lettoNumerose centinaia di posti letto, di varie caratteristiche, pochi con valenza informatica, alcune volte impegnativa

Posti di lavoro informatici

Generici, in ragione di circa il doppio dei posti lettoDi sportelloDei servizi (cucina, lavanderia, mensa, magazzini)Di Urgenze di pronto soccorsoPer bioimmagini e biofilmatiPortatiliDi amministrazione tecnica del sistema informativo sanitario

Server Dell’ordine delle decineSistemi operativi Svariati, non sempre nella sola ultima release

Retistica interna

Architetture: a stella, ad anello, misteTecnologie di linea: doppino, fibre ottiche, ponti radio, wirelessAltre linee: CDN, ISDN, ADSL, …Dispositivi: switch, hub, firewall

StampantiPersonali: in ragione di una ogni due o tre posti Di lavoroDi alta produttività: alcune decine

MonitorPersonali: uno ogni posto di lavoroPer le bioimmagini: attribuiti ai PACS Altri di alta risoluzione grafica: pochi

Scanner Personali: qualche decinaRadiologici: attribuiti ai PACS

Lettori di codici a barre Numerosità dell’ordine delle centinaia

Tabella 1.1Le caratteristiche di ICT per una Azienda Ospedaliera

PACS Presente o in fase di progettazione/implementazione

Banchi di memorizzazione juke box, SaN, …

Applicativi software di utente, e collegati bioarchivi

Automazione d’ufficio: aventi licenza d’uso a pagamento o gratuita (open source)Comunicazione (posta elettronica)Di navigazione in InternetDi protezione antivirusDi anti-spamDi biblioteca biomedica digitale (SBBL, altre)Gestione di schede anagraficheGestione di bioimmagini e biofilmatiGestione di cartelle cliniche di degenza: probabilmente un applicativo per ogni repartoGestione di cartelle cliniche ambulatoriali: possibilmente un unico applicativo di ospedaleDi teleconsulto clinico remotoAmministrativi per il personaleAmministrativi di fatturazioneControllo di gestioneGestione dei bandi di appalti per fornitureDei magazzini Della mensaDella trasparenza (per chi dall’esterno si collega per vedere l’iter di bandi, di concorsi)Della comunicazione istituzionaleGestione del CUPCongelamento dei contenuti (Adobe) Rete/Intranet/corporanet (quando la rete esce in un altro presidio)/Extranet (carta SISS che è diventata carta dei servizi)/Internet(postazioni internet dedicate solo a quello; non pc con dati ospedalieri)Sistemi di televisualizzazione e di teleconferenzadi amministrazione tecnica del sistema informativo sanitario dedicati a:

posti di lavorocomunicazione (analisi files log, ecc)gestione dei rischigestione dei back up

Packages di gestione della rete che regolano

Origine e destinazione Accreditamento di accesso (sia come macchina che come area di utilizzo)Gestione della riservatezza sul dato (si migliora complicando l’identificazione dell’utente)Gestione della sicurezza (fare il possibile affinché ci sia la miglior ubicazione “fisica”dell’hardware, tutela dei virus) Gestione “voice over IP” (gestione della voce mandata in contemporanea coi dati che si scambiano i calcolatori “telefoni e pc viaggiano sulla stessa rete”)

Basi di dati

AmministrativeAnagraficheClinichealtre

3Capitolo 1Lo scenario dei sistemi informativi clinici e sanitari

1.1.2 ICT Sanitaria (ASL)

Presenza di:Elemento caratteristico Numerosità e/o specializzazioni

Posti di lavoro informatico

Generico, in ragione di circa 0.9 per ogni addettoDi sportelloNei servizi (cucina, lavanderia, mensa, magazzini)Urgenze (non da pronto soccorso, ma territoriali, tipo epidemie)PortatiliDi amministrazione tecnica del sistema informativo sanitario

Server Alcuni

Sistemi operativi Svariati, non sempre nella sola ultima release

Retistica interna

Architetture: a stella, ad anello, misteTecnologie di linea: doppino, fibre ottiche, ponti radio, wirelessAltre linee: CDN, ISDN, ADSL, …Dispositivi: switch, hub, firewall

StampantiPersonali: in ragione di una ogni due o tre posti Di lavoroDi alta produttività: alcune decine

Monitor Personali: uno ogni posto di lavoroDi alta risoluzione grafica: qualcuno

Scanner Personali: qualche decina

Lettori di codici a barre Dell’ordine delle centinaia

Di automazione d’ufficio: aventi licenza d’uso a pagamento o gratuita (open source)Comunicazione (posta elettronica)Di navigazione in InternetDi protezione antivirusDi anti-spamDi biblioteca biomedica digitale (SBBL, altre)Gestione di cartelle dei servizi domiciliariAmministrativi per il personaleAmministrativi di rimborsoControllo di gestioneGestione dei bandi di appalti per fornitureDei magazziniDella mensaDella trasparenza (per chi dall’esterno si collega per vedere l’iter di bandi, di concorsi)Della comunicazione istituzionale

Elemento caratteristico Numerosità e/o specializzazioni

Posti letto Nessun posto letto

Elenco completo dei cittadini aventi diritto

Con indicazione:Esenzioni;Fabbisogni di movimentazione; Fabbisogno di accompagnamento;

Eventualità della cittadinanza estera

Aspetti di assistenza domiciliare

Tabella 1.2Le differenze principali di una Azienda Sanitaria Locale con un’Azienda Ospedaliera (caso della Lombardia)

Tabella 1.3Le caratteristiche di ICT per un’Azienda Sanitaria Locale

1.2 Elementari prestazioni attese

Anche non essendo specialisti in Informatica Medica e Telemedici-na, nel pensare agli strumenti per la Medicina e la Sanità ci sono ter-mini che, in modo naturale, vengono alla mente. Ha senso iniziare da questi poiché costituiscono una conoscenza implicita e di ampio raggio. Per ottenere profitto da ciò, si comincerà esaminando bre-vemente alcune di queste parole: saranno considerate come parole-chiave e verrà ricordato il loro significato. Nel fare questo saranno anche ricordate le aspettative generali che tali termini generano ai differenti profili relativi ai numerosi utenti. Qualche volta sarà facile capire il grado al quale – già da ora – le aspettative sono soddisfatte. In altri casi vorremmo percepire quanto i metodi e le tecnologie do-vrebbero ancora migliorare per risolvere i problemi dei loro utenti in Medicina e Sanità.

La prima delle parole chiave è scrivere. Compilare una cartella clinica, un referto, una prescrizione ma anche acquisire un dato da uno strumento di misurazione; correggere un elemento scritto o acquisito precedentemente ma anche importarlo da uno scanner. Le accezioni della parola scrivere sono numerose e tutte estremamente

Gestione del CUP (a volte)Congelamento dei contenuti (Adobe) Rete/Intranet/corporanet(quando la rete esce in un altro presidio)/Extranet (carta SISS che è diventata carta dei servizi)/Internet(postazioni internet dedicate solo a quello; non pc con dati ospedalieri)di amministrazione tecnica del sistema informativo sanitario dedicati a: posti di lavoro comunicazione (analisi dei files log, ecc) gestione dei rischi gestione dei back up

Packages di gestione della rete che regolano

Origine e destinazione Accreditamento di accesso (sia come macchina che come area di utilizzo)Gestione della riservatezza sul dato (si migliora complicando l’identificazione dell’utente)Gestione della sicurezza (fare il possibile affinché ci sia la miglior ubicazione “fisica”dell’hardware, tutela dei virus) Gestione “voice over IP” (gestione della voce mandata in contemporanea coi dati che si scambiano i calcolatori “telefoni e pc viaggiano sulla stessa rete”)

Basi di dati

Anagraficheepidemiologicheamministrativealtre

importanti: l’insieme di queste va infatti a costituire la documen-tazione che terrà storia del percorso del paziente all’interno della struttura di cura. Sono operazioni che richiedono grande attenzione e qualità di esecuzione per scongiurare il rischio di errori che pos-sano compromettere la corretta assistenza al paziente e la corretta memorizzazione dei suoi dati.

La seconda parola chiave è quindi memorizzare. Nel corso degli ultimi decenni, sappiamo come la capacità di memoria dei disposi-tivi digitali sia stata ampiamente aumentata di anno in anno, anche ultimamente. Probabilmente, adesso, le capacità di memorizzazione non costituiscono colli di bottiglia significativi nelle applicazioni me-diche e sanitarie. Nell’anno 2003, i sistemi offerti erano in grado di raggiungere 12 Petabyte, e un costo di 6000 $ per Terabyte era rela-tivamente comune (Tabella 1.4). In accordo con le capacità di me-morizzazione solitamente necessarie, i dispositivi disponibili hanno capacità abbastanza adeguate e prezzi relativamente bassi. Un aspetto non trascurabile è relativo al mantenere il supporto di memorizzazio-ne leggibile in futuro, a lungo, per parecchi decenni.

Dischi e nastri magnetici Costo per GigabyteDischi di alto livello (FC, SCSI, FICON, ESCON) 50–70 $/GBDischi di medio livello (SCSI, FC) 20–35 $/GBDischi a basso costo (S-ATA, JBODs) 5–15 $/GBNastri automatizzati 0.75–3.50 $/GBSupporti ottici <10 $/GB

Una terza parola chiave è archiviare. Archiviare correttamente con-sentirà poi di usare le informazioni in maniera corretta. L’operazione richiede memoria, ma necessita anche di organizzazione; organizzare vuol dire indicizzare, contestualizzare e gerarchizzare. Per compren-dere questo, assumiamo che si archivia perché abbiamo necessità di rendere più facili gli usi futuri delle informazioni di cui disponiamo. Individuare, selezionare ed elaborare sono le principali azioni d’uso dei dati che l’archiviare dovrebbe facilitare. Interrogare in maniera efficace i dati, inoltre, è possibile solo se le informazioni sono sta-te archiviate in maniera corretta. Per di più, per rendere possibile ciascuno di questi usi, i dati dovrebbero essere stati memorizzati bene e in modo sicuro. Vogliamo dire che, qualsiasi sarà il prin-cipio fisico coinvolto nei dispositivi e meccanismi di memorizza-zione, fondamentalmente l’azione di archiviazione dovrebbe fornire affidabile memorizzazione, in modo tale da permettere agli utenti delle informazioni di compiere le loro pertinenti azioni, come indi-viduare, visualizzare ed elaborare i dati. Per esempio in una biblio-teca, è necessario un sistema di classificazione per guidare gli utenti

Tabella 1.4Costo di un Gigabyte per differenti supporti di memorizzazione di massa.

[Source: Horison Information Strategies and Giga Research, 2003] [Sun Microsystems, 2005]

nell’allocazione dei libri sullo scaffale. Però non tutti i libri hanno le medesime dimensioni. Anche se libri di differenti dimensioni sono collocati su differenti scaffali, questo dovrebbe non costituire una difficoltà per gli utenti quando vogliono cercare libri aventi soggetti simili. Se noi trasferiamo il concetto dai libri ai dati medici e sanita-ri, l’archiviazione di questi non dovrebbe costituire alcuna difficoltà per i loro utenti nonostante le molte differenze esistenti tra i tipi di dati di base medici e sanitari [Pinciroli, et al., 1998]. Va ricordato quanto le parole, i biosegnali, le bioimmagini impegnino qualsiasi computer in modo molto differente le une dagli altri, a partire dalla loro digitalizzazione, fase iniziale di qualunque insieme di desidera-te prestazioni.

Utilizzare vuol dire anche visualizzare. Grazie alla tendenza “gran-de è bello”, schermi grandi e piatti trionfano ovunque: da una parte essi possono apparire solo un’attrazione, d’altra parte essi indicano miglioramenti oggettivi. Ad ogni modo, grande non è tutto. Questo significa che non è abbastanza che la visualizzazione sia realizzata “plug and play” per garantire anche i livelli di fedeltà richiesti dalle applicazioni mediche. È necessario considerare la forma dei pixel, il numero dei livelli di colore, la dinamica di risposta riguardante i filmati, le condizioni di illuminazione dell’ambiente e così via. Per tutto questo, nell’ambito medico, considerate tutte le necessarie cautele, una più grande dimensione incoraggia un nuovo inizio, per aggiornare l’analisi ereditata dal passato.

Un’altra parola chiave è integrazione. Le specifiche funzioni a cui il concetto di integrazione può essere applicato sono realmente tan-te: fra loro molte sono differenti una dall’altra. È integrazione quella dei dati che un singolo paziente genera nei sistemi informativi di parecchi differenti ospedali, dove egli è stato curato. È integrazione quella fra la descrizione testuale di una diagnosi medica e le spe-cifiche bioimmagini che la supportano [Cristiani, et al., 1996]. È integrazione quella fra dati clinici e dati amministrativi. Le aspetta-tive generali sono che i prodotti della tecnologia dell’informazione gestiranno una completa ed efficace integrazione. Ma, nel campo dei dati clinici e sanitari, dopo alcuni decenni di sforzi indirizza-ti all’implementazione di integrazioni efficaci, ancora permangono cattive notizie. Si vuole dire che, anche a livello di paziente, ancora sperimentiamo che le integrazioni sono troppo lontane dai livelli naturalmente desiderati. Per esempio due differenti ospedali, man-tenenti alcuni dei miei dati clinici, ben difficilmente li fonderanno insieme sotto una singola identificazione di paziente. Non di meno, nonostante le presenti carenze, i database rimangono il solo unico strumento utile alle necessità dell’integrazione desiderata per per-

mettere agli utenti individuare, visualizzare o elaborare i dati clinici e sanitari. In sintesi, “integrazione” è una parola chiave veramente desiderata dai clienti, e quindi è considerata dalle aziende fornitrici, ma sta ancora aspettando sistemi più performanti di quelli offerti oggi. Attualmente la scelta da fare consiste nel tenere limitate le necessità di interesse, analizzandole professionalmente e cercando soluzioni che si adattino a esse.

Un problema inevitabile riguarda la riservatezza e la sicurezza. Esso può essere trattato sottolineando tre differenti aspetti sui quali si possono basare gli strumenti e le tecniche di riservatezza e sicu-rezza: “cosa conosciamo”, “cosa possediamo”, “cosa siamo” [Miller, 1994]. Rispettivi esempi sono: una password, una carta ‒ del tipico ingombro di una carta di credito ‒ di qualunque tecnologia, un’im-pronta digitale. Anche quando ci focalizziamo sulla categoria “cosa siamo” appaiono molte difficoltà: algoritmi affidabili, in grado di rendere completamente tollerabile la rilevanza di errori di riconosci-mento ‒ siano falsi positivi o falsi negativi ‒, non sono ampiamente diffusi, almeno quando le coorti da considerare sono altamente po-polate. Ad ogni modo, ci sono tante iniziative promosse da aziende. Alcune di loro offrono servizi basati su un certo numero di grandez-ze biometriche, eventualmente applicate l’una dopo l’altra in suc-cessione [Ravera, et al., 2004].

Gestione è il termine spesso aggiunto a tutte le parole chiave fi-nora considerate. Noi possiamo avere familiarità con i termini quali gestione della memoria, gestione dell’integrazione e così via. Da pa-recchi anni, la dicitura “gestione del PACS” (Picture Archives and Communication Systems), ha acquisito una propria fisionomia e caratteristiche di globalità [Samei, et al., 2004]. Nella “gestione del PACS”, già l’edizione 2003 della conferenza Hospital Information Management System Society (HIMMS) ha confermato una speci-fica tendenza: quella dei “web-based PACS”, cioè PACS basati su tecnologie per il web. Il concetto di base è adottare metodi e tec-nologie web anche per lo svolgimento di operazioni sulla intranet ospedaliera. La tendenza è qualche volta davvero notevole, come nel caso della Fuji Medical Systems USA, che commercializzò come “The web-based PACS”, cioè il PACS basato su web, il proprio pro-dotto chiamato Synapse [Fuji Medical System, 2008].

È a partire da questi concetti che tutte le applicazioni per la Sa-nità Digitale che incontreremo si costruiscono e prendono forma. Queste sono le aspettative con le quali ci vogliamo confrontare e che le applicazioni che verranno analizzate cercano di soddisfare.

1.3 Gli scenari dominanti

1.3.1 Il modello organizzativo del sistema sanitario italiano e il sistema regionale

L’attuale assetto del sistema sanitario italiano si ispira al National Health Service (NHS) creato in Inghilterra subito dopo la seconda guerra mondiale. Principali caratteristiche di questo modello sono: • copertura sanitaria per tutta la popolazione in base alla citta-

dinanza; • sostanziale gratuità delle prestazioni erogate (a meno di ticket

su singole prestazioni); • finanziamento del sistema mediante la tassazione generale.Come conseguenza di tali caratteristiche generali si ha che:• il finanziamento da parte dei cittadini non avviene in base al

“rischio di salute” ma in base al reddito (secondo la progressio-ne delle aliquote fiscali)

• la copertura sanitaria è un diritto che deriva dal fatto di essere nati o diventati italiani; si paga anche se non si utilizza il siste-ma ovvero non è possibile rinunciare alla copertura sanitaria e non pagare la quota di tasse corrispondente;

• il ruolo dello Stato (nelle sue articolazioni nazionali, regionali, locali...) è prevalente sia a livello di decisione/programmazione che di gestione diretta dei servizi e delle strutture.

In Italia tale organizzazione viene introdotta con la legge 23 dicem-bre 1978 n. 833 (Istituzione del Servizio Sanitario Nazionale), no-vanta anni dopo la prima riforma sanitaria del 1888 a opera di Cri-spi. Poco dopo la riforma del 1978, soprattutto a causa dell’incon-trollabilità della spesa, viene approvata una nuova riforma (decreti delegati del 1992-93) che ha sostanzialmente mantenuto l’architet-tura generale del sistema ma modificato in profondità i meccanismi di gestione e responsabilità di spesa. Inoltre nei successivi anni ’90 e all’inizio di questo secolo sono state approvate ulteriori integrazioni che hanno portato il sistema all’assetto attuale.

Questo modello organizzativo è stato definito, spesso con una certa enfasi, solidaristico nel senso che l’utilizzo del sistema avviene in base ai bisogni di salute mentre la compartecipazione al finanzia-mento è in base al reddito: dunque chi è più ricco paga di più (tra-mite la tassazione) e chi è più sano finanzia più di quanto consuma, in favore di chi è più povero o più malato.

Tutto ciò è sicuramente vero e apprezzabile anche se in realtà l’osservazione sperimentale della pratica attuazione consiglierebbe meno enfasi. L’accesso al sistema è garantito a tutti indipendente-

mente dallo stato sociale, ma la pratica utilizzazione non si dimostra uguale per tutti, come liste di attesa, possibilità effettiva di scegliere strutture e operatori migliori, trattamento reale, informazione effet-tivamente disponibile, ecc. mostrano chiaramente. Inoltre la pre-sunta equità nel finanziamento dipende dal sistema fiscale sulla cui efficienza è lecito avanzare più di un dubbio.

Il Servizio Sanitario Nazionale (SSN), come è oggi configurato, può essere rappresentato dallo schema istituzionale mostrato in Fi-gura 1.1.

Schema Istituzionale del Servizio Sanitario Nazionale

Bilanciodello Stato Parlamento

Ministero Salute

ConferenzaStato Regioni

Regioni

Agenzia Serv. San. Regionali

Ist. Sup. Prev. Sic. Lavoro

Istituto Superioredi Sanità

Istituti Zooprofil.

Sperimentali

Strut. di cura privateAttività medica professionale

Strutture proprie delle ASL

AziendeOspedaliere

Medicidi base

Assicurazioni

Sanità marittima aerea e di frontieraSanità penitenziaria

Piano Sanitario Nazionale

Consul. ricerca

proposta

Ricerca e assistenza

Profilassiinternazionale

Proposta di Piano Sanitario Nazionale

Vigilanza e coordinamento

Accordo su quote e altro

Leggi sanitarie regionali

Assistenza ospedaliera

Assistenza sanitaria

Assistenza ospedaliera

e medica

Nomina Direttori Generali

Assistenza medica

Ripartizione FSR

Trasf. risorse Gestione

Rimborsi

Convenzioni

Relazione sullo stato sanitario del paese

Leggi sanitarie generali

Tassazione generale e contributi sanitari

Quote di imposte

CITTADINI

Finanziamento integrativo

Confronto

Convenzioni

Premilive

Figura 1.1Schema istituzionale del Servizio Sanitario Nazionale

Sono distinguibili tre livelli: centrale, regionale, locale. A livello centrale è posto il Parlamento e il Governo ai quali spetta il

compito di emettere leggi di carattere generale, assumere decisioni in materia di finanziamento del sistema, effettuare attività di supervisio-ne e controllo, partecipare e gestire alcuni settori specifici; in questo può essere coadiuvato da altri enti nazionali di consulenza, ricerca e proposta. A questo livello viene approvato il Piano Sanitario naziona-le, documento che fissa gli obbiettivi generali futuri del sistema per un triennio, e il Rapporto sullo Stato Sanitario del Paese, documento che descrive e quantifica prestazioni e strutture esistenti.

A livello regionale, secondo quanto previsto dalla Costituzione, compaiono le Regioni: il loro compito è programmare e gestire i servizi sanitari sul territorio, assumendo, in merito, le decisioni che più ritengono idonee ma non in contrasto con quelle nazionali. Il confronto tra Regioni e Governo nazionale sulle materie di comune competenza e interesse avviene in sede di Conferenza Stato Regioni, che approva gli accordi conseguenti. Le Regioni approvano leggi re-gionali in materia di sanità, il Piano Sanitario Regionale, nominano i Direttori Generali di ASL e AO e decidono in materia di accredi-tamento delle strutture.

A livello locale i principali attori sono le ASL (Aziende Sanitarie Locali) cui spetta il compito di organizzare i servizi sanitari sul terri-torio, le AO (Aziende Ospedaliere) costituite di solito dalle maggio-ri strutture ospedaliere, i medici di medicina generale e altre strut-ture di cura private che possono essere accreditate, cioè far parte, a tutti gli effetti, del servizio sanitario regionale.

Per quanto riguarda il finanziamento del sistema, sino al 2000 esi-steva un Fondo Sanitario Nazionale (FSN), approvato a livello cen-trale una volta l’anno con la Legge Finanziaria, che definiva il livello di spesa complessiva pubblica; esso era poi ripartito fra le regioni pre-valentemente in base al numero dei residenti e in misura minore con altri parametri concordati in sede di Conferenza Stato Regioni.

Con il Decreto Legislativo n. 56 del 2000 (Disposizioni in mate-ria di federalismo fiscale) si è deciso di attribuire alle regioni anche la responsabilità delle entrate, nel senso di finalizzare direttamente alla sanità quote di imposte e tributi (IRAP, IVA, accisa sulla benzina) che così non vengono più incamerate a livello centrale per poi esse-re suddivise a livello regionale ma trattenute direttamente a livello regionale; inoltre si è data alla regioni la facoltà di aumentare alcu-ne aliquote (addizionale IRPEF, per esempio) per finanziare servizi sanitari. Per evitare cambiamenti improvvisi è stato introdotto un transitorio sino al 2013 che prevedeva una sorta di coesistenza dei due sistemi.

Nei fatti questo processo è stato sospeso a partire dal 2004 e at-tualmente, se è vero che il FSN formalmente non c’è più, sostan-zialmente è come che ci fosse: rimangono le varie quote di imposte trattenute direttamente sul territorio, ma poi si fa in modo che con un Fondo integrativo deciso centralmente il FSN si materializzi nei fatti. Dunque i finanziamenti alla singola regione non dipendono strettamente dalla capacità contributiva dei residenti di quella re-gione (come previsto dal Decreto n. 56), ma continuano a essere influenzati da altri criteri (la serie storica, gli orientamenti del go-verno, ecc.). Anche il più volte proclamato obbligo di far fronte ai propri deficit e debiti regionali è stato manifestamente contraddet-to nel 2007 con un intervento finanziario di supporto del governo centrale nei confronti di quelle regioni (Campania, Lazio, Sicilia, Liguria, Abruzzo e Molise) che hanno creato voragini economico-finanziarie di entità pari solo alla loro incapacità gestionale.

Il ruolo delle Regioni è centrale nel sistema sanitario italiano: esse detengono la proprietà di tutte le strutture sanitarie pubbliche, ne controllano direttamente la gestione, programmano la distribuzione dei servizi nel territorio, definiscono le regole di finanziamento delle varie tipologie di assistenza e regolano (tramite l’accreditamento) l’afferenza delle strutture private al sistema pubblico. Di fatto bi-sognerebbe parlare di Servizi Sanitari Regionali (SSR) più che di SSN, anche se quest’ultimo ha ancora senso perché è mantenuta la libertà a ogni cittadino italiano di farsi curare in qualsiasi parte del territorio nazionale e perché le regioni hanno l’obbligo di fornire comunque una base di assistenza comune (Livelli Essenziali di As-sistenza, LEA).

A conferma di tutto ciò si pensi che la sanità occupa mediamente il 70% dei bilanci regionali e che anche a livello politico viene con-siderato, nel bene e nel male, uno dei settori più importanti.

I principali strumenti di governo della sanità in mano alle regioni sono:• la definizione del Piano Sanitario Regionale;• l’approvazione di leggi regionali in materia di sanità;• la nomina dei Direttori Generali di ASL e AO;• la definizione e quantificazione dei DRG (rimborsi a presta-

zione)[QBGROUP, 2007];• la approvazione delle norme relative all’Accreditamento delle

strutture sanitarie pubbliche e private e dei relativi contratti;• la definizione di standard di qualità, sicurezza, ecc.;• l’attività di controllo e verifica sul territorio.Nel rispetto delle comuni regole nazionali ogni regione ha ampi margini di autonomia organizzativa in materia sanitaria; decide il

numero e le dimensioni delle ASL, la tipologia e il numero delle AO, i criteri strutturali e organizzativi che una struttura sanitaria deve rispettare, il tariffario (DRG) sulla cui base rimborsare le pre-stazioni effettuate dai diversi erogatori di servizi, i limiti in termini di quantità e di spesa che ogni azienda sanitaria deve rispettare, l’af-ferenza o meno di strutture private e di nuovi ospedali, l’ammonta-re di eventuali ticket e compartecipazione alla spesa (farmaceutica, ospedaliera, specialistica, ecc..), il livello di alcuni tributi su scala regionale oltre a nominare i Direttori Generali di tutte le ASL e AO, affidando loro obbiettivi da conseguire.

In definitiva tutti gli attori ed erogatori di servizi sanitari hanno nella Regione il loro principale e naturale interlocutore.

1.3.2 L’ospedale

Dagli inizi del ’900 l’ospedale si è sempre più affermato come luogo principe della cura. Prima alcune scoperte (asepsi, anestesia, com-prensione dei meccanismi di trasmissione di molte malattie.) poi la messa a punto di farmaci e di tecnologie di diagnosi sempre più sofisticate ne hanno decretato successo e sviluppo organizzativo.

L’espansione è proseguita sino agli ultimi decenni dello scorso secolo quando tutti i paesi industrializzati hanno iniziato un’azione di contenimento e riduzione; in Italia ancor oggi il settore ospeda-liero assorbe circa la metà dell’intera spesa sanitaria. Contestual-mente anche il modello organizzativo e strutturale dell’ospedale sta cambiando: non più grandi spazi dedicati quasi esclusivamente alla degenza ordinaria, ma strutture orientate prevalentemente all’eroga-zione di servizi (in day-hospital, ambulatoriali, diagnostici) con de-genze brevi e finalizzate ai casi più gravi. Questa tendenza, da tutti condivisa, stenta peraltro a concretarsi perché rallentata da interessi consolidati degli operatori, corporazioni e aziende poco propensi al cambiamento e più sensibili al mantenimento degli equilibri interni preesistenti che alle reali esigenze di salute degli utenti.

In Tabella 1.5 sono riportati i valori di alcune grandezze del set-tore ospedaliero, confrontato tra il 1990 e il 2004. Tale settore è fra quelli maggiormente influenzati dalla riforma del 1992-93 e succes-sive integrazioni.

Uno dei maggiori cambiamenti è stato il nuovo meccanismo di finanziamento. Mentre precedentemente la copertura dei costi era comunque assicurata (e dunque nullo era l’incentivo al migliora-mento e alla ricerca di efficienza) ora le strutture ospedaliere vengo-no finanziate in base alle prestazioni effettivamente erogate ai citta-dini, sulla base di un tariffario (DRG).

Dunque ora costi ed efficienza organizzativa sono diventati proble-mi dei responsabili delle strutture e non più degli enti finanziatori (le Regioni): ciò ha cambiato profondamente la cultura di gestione delle strutture, le loro strategie e i comportamenti dei responsabili di gestione.

GRANDEZZE UNITÀ DI MISURA 1990 2004

Letti numero 388.273 231.915ospedalieri n./1000 ab. 6,7 3,99Degenza tutti 11,7 7,6media (in giorni) acuti 11,2 (1985) 6,7Tasso occupazione

% 69,30% 76,4%posti letto (per acuti)Ricoveri ordinari numero 8.966.192 8.708.296Ricoveri day-hospital numero 3,6 milioni (2003)(*)

Un’immediata conseguenza è che non è più possibile gestire una struttura ospedaliera senza un sistema informatico degno di questo nome: tutto deve essere conosciuto e misurato, se non altro perché altrimenti non può essere rimborsato.

Indipendentemente da come vengono effettivamente gestiti, gli ospedali sono oggi delle vere aziende: forniscono migliaia di servizi fra loro fortemente diversificati, impiegano i più diversi sistemi e tec-nologie (presenza di apparecchiature elettroniche, meccaniche, nucle-ari, di imaging), funzionano senza soluzione di continuità dalla loro inaugurazione, devono soddisfare esigenze alberghiere degli utenti e dei loro familiari, si occupano di persone e non di prodotti inerti, ecc.

Sicurezza, qualità, gestione del rischio costituiscono inoltre set-tori di grandissima e crescente importanza, anche se non ancora affrontati con il dovuto rigore.

È compito delle Regioni definire e controllare gli standard strut-turali e organizzativi, fissare i criteri di accreditamento (cioè di par-tecipazione al SSR), di gestione e di finanziamento.

A livello internazionale si stima che le dimensioni ottimali di una struttura ospedaliera siano fra i 250 e i 350 letti. La creazione di grandi ospedali di 800, mille o più letti si è spesso dimostrata un fallimento organizzativo, con problemi a tutti i livelli, persino di ordine pubblico. In sintesi:• il settore ospedaliero assorbe in Italia quasi il 50% di tutta la

spesa (in altri paesi comparabili questa percentuale è più vicina al 40%);

• esigenze di salute impongono un cambiamento organizzativo, di gestione e strutturale: meno letti di degenza, più servizi ma tale cambiamento è più lento del dovuto;

Tabella 1.5Grandezze del settore ospedaliero. Italia 1990-2004

*Relazione sullo Stato Sanitario del Paese 2003-2004

Fonte: Health Data Base WHO 2007

• gli ospedali sono strutture fortemente complesse per diversità e particolarità di servizi erogati: la loro gestione non può pre-scindere da un sistematico impiego di Information Technology;

• le Regioni sono proprietarie delle strutture ospedaliere pub-bliche e per tutte fissano le regole di finanziamento e gestione, oltre agli standard di sicurezza, qualità, struttura.

1.3.3 Il medico di medicina generale

La rete dei medici di medicina generale (MMG), chiamati anche medici di base o medici di famiglia, costituisce l’accesso che il siste-ma sanitario offre all’utente, relativamente a una prima valutazione di salute (non è l’unica possibile ma sicuramente la più naturale e immediata). I medici di medicina generale sono convenzionati con il SSN (e i SSR) e devono offrire una serie di prestazioni di base (visite, prescrizioni di farmaci, di analisi diagnostiche, di visite spe-cialistiche, di ricoveri, di procedure terapeutiche) a un numero di cittadini che non può superare una certa soglia (circa 1500) e che sono stati da loro scelti.

Vengono remunerati in base a una quota capitaria e ad altri fatto-ri variabili contrattati a livello nazionale e regionale. Il loro numero ed i criteri di accesso sono regolamentati.

Negli ultimi anni alcune regioni cercano di fissare anche vincoli miranti a una maggiore appropriatezza nelle prescrizioni farmaceu-tiche o incentivi per favorire accorpamenti in studi associati, al fine di ottenere servizi più estesi e accessibili per i cittadini.

Culturalmente il riferimento è al medico di famiglia inglese che però ha tradizionalmente poteri e responsabilità maggiori: in In-ghilterra egli costituisce infatti il vero accesso al sistema e detiene il potere di regolare e indirizzare alle cure successive, compreso il ricovero. In Italia invece per lungo tempo il MMG è stato poco più di un attore-spettatore del sistema senza alcun potere di indirizzo reale; per esempio i ricoveri ospedalieri (50% circa di tutta la spesa sanitaria) possono avvenire al di fuori del suo controllo, ma in com-penso ha avuto una grande libertà di prescrizione. Nei fatti è stato più un prescrittore che un controllore di accesso al sistema o un tutore del processo di salute. L’esperienza ha mostrato che assenza di regole e responsabilità di categoria hanno reso il MMG più sensibile agli interessi delle aziende farmaceutiche e dei laboratori di diagnosi che a quelli oggettivi di salute degli utenti: anche questi ultimi lo hanno spesso indotto a dosi massicce di prescrizioni nella illusione che a una maggiore quantità di sanità e di farmaci, corrispondesse una migliore salute.

Negli ultimi anni esigenze di contenimento della spesa hanno spin-to alcune regioni a introdurre maggiori controlli, ma la situazione è rimasta fondamentalmente la stessa: dal punto di vista dell’or-ganizzazione generale del sistema il MMG è un attore con pochi poteri e resta principalmente un prescrittore. È questa una delle debolezze dell’attuale modello organizzativo: si tende a introdurre qualche flebile controllo ma non gli si attribuiscono responsabilità vere di sistema.

Un importante impulso al cambiamento potrebbe venire dall’uso massiccio di Information Technology che consentirebbe al MMG di fare sistema con farmacie, laboratori di diagnosi e strutture ospe-daliere. I vantaggi per gli utenti potrebbero essere consistenti so-prattutto in termini di qualità del servizio e risparmio di tempo e adempimenti; renderebbe inoltre possibili misure, controlli e valu-tazioni dei processi di cura.

Secondo i dati del Ministero della Salute (Ufficio di Direzione Statistica) nel 2005 il numero dei MMG su tutto il territorio na-zionale era 47.022, a ciascuno dei quali competevano mediamente 1.080 cittadini adulti residenti; a essi vanno aggiunti 7.459 medici pediatri, con una media di 1.029 bambini residenti. Naturalmente vi sono differenziazioni per regione ma contenute, soprattutto per quanto riguarda la distribuzione dei MMG.

1.3.4 Il sistema di emergenza-urgenza

Per Emergenza-Urgenza si intende quel particolare settore del si-stema sanitario mirante a garantire una risposta immediata e tem-pestiva a situazioni di improvvisa crisi di salute. Casi tipici sono gli eventi traumatici e quegli eventi improvvisi (spesso di origine cere-brovascolare) che creano situazioni critiche di salute e che necessita-no di un intervento urgente mirato alla sopravvivenza del soggetto e alla stabilizzazione delle sue condizioni.

Il settore è regolato da norme nazionali (del 1992 e 1996) e regio-nali. Esse definiscono lo stato attuale del sistema emergenza urgenza in Italia secondo la seguente composizione:• un sistema di allarme sanitario, dotato di numero telefonico

(118) di accesso breve e universale in collegamento con le cen-trali operative;

• un sistema territoriale di soccorso;• una rete di servizi e presidi ospedalieri, funzionalmente diffe-

renziati e gerarchicamente organizzati.La Figura 1.2 mostra lo schema organizzativo del Sistema Emergen-za Urgenza.

Il sistema di allarme è costituito da un numero unico (118) e da una centrale operativa a cui fanno capo tutte le richieste telefoniche di urgenza ed emergenza convogliate attraverso il numero unico. Le funzioni sono: la ricezione delle richieste di soccorso, la valutazio-ne del grado di complessità dell’intervento da attivare, l’attivazione e il coordinamento dell’intervento stesso. Il DEA (Dipartimento di Emergenza ed Accettazione) comprende due tipologie di unità operative: il Pronto soccorso e le Unità di Rianimazione e Terapia intensiva. Il servizio di Pronto Soccorso funziona 24 ore su 24 e deve essere in grado di garantire la stabilizzazione del malato critico e l’eventuale trasporto verso una struttura più idonea. All’arrivo in Pronto Soccorso il paziente viene accolto da un infermiere profes-sionale che valuta lo stato di salute e attribuisce un codice di priori-tà, in relazione al quale il soggetto aspetterà in sala d’attesa o entrerà direttamente nelle sale d’emergenza.

La priorità articola su codici di diverso colore che rappresentano quattro livelli di gravità:• CODICE ROSSO: casi più gravi, con pericolo di vita imme-

diato da affrontare subito;• CODICE GIALLO: pazienti con lesioni gravi; i tempi di atte-

sa sono ridotti al minimo;• CODICE VERDE: paziente non in pericolo di vita, da assi-

stere dopo i casi più urgenti;• CODICE BIANCO: casi meno gravi (non da Pronto Soccor-

so); vengono comunque assistiti, ma dopo i casi più urgenti.Le Unità di Terapia Intensiva e Rianimazione garantiscono l’assi-stenza al paziente critico tramite:• una prima fase di emergenza (Rianimazione), con il paziente

in potenziale pericolo di vita, caratterizzata da sostegno e/o ripristino delle funzioni vitali compromesse;

Organizzazione del Sistema di Emergenza Urgenza

DEA (Dipartimento Emergenza Accettazione)

Struttura ospedaliera qualificata

Dimissione

Dim. protettaTelemedicina

Pronto Soccorso

RianimazioneTerapia Intensiva

(UTIC, Stroke Unit... )

Sistema di Soccorso

Unità Cliniche Blocco Operatorio

Riabilitazione

Diagnosticaper Immagini Lab. Servizi

Territorio

Figura 1.2Schema organizzativo

del Sistema di Emergenza-Urgenza

• una seconda fase (Terapia intensiva) in cui viene fornito un sostegno clinico a elevata specializzazione anche con moderne risorse strumentali.

Il DEA può essere di primo o secondo livello a seconda del suo gra-do di complessità e specializzazione; può utilizzare i servizi di altre unità diagnostiche dell’ospedale e, dopo la fase di stabilizzazione e di intervento intensivo, normalmente trasferisce i pazienti in altre unità di degenza ordinaria.

Le unità di Terapia Intensiva e Rianimazione sono in genere for-mate da un numero limitato di letti (4-12) dotati di sistemi avanzati di monitoraggio e di supporto, devono rispettare particolari standard strutturali e organizzativi, dispongono di personale altamente specia-lizzato sui tre turni e presentano costi particolarmente elevati; il loro finanziamento, diversamente dagli altri reparti e servizi, non avviene mediante rimborso a prestazione (DRG) ma normalmente a forfait.

I letti di terapia intensiva sono meno di 4.000 su tutto il territo-rio nazionale e si stima che siano meno della metà del necessario; ciò porta a un loro costante pieno utilizzo con il rischio di dimettere pazienti ancora potenzialmente a rischio, o peggio ancora, di non riuscire a ospitarne altri in condizioni critiche.

Una soluzione organizzativa idonea appare l’adozione di un ulte-riore livello di cura, le terapie subintensive o semintensive, interme-dio tra le terapie intensive e i normali reparti di degenza. Lo scopo è ridurre il forte afflusso nelle Terapie Intensive, contenere i costi, assicurare un livello di cure e di sicurezza adeguato.

1.3.5 L’utente e il servizio sanitario

L’utente è il soggetto debole nell’ambito del Servizio Sanitario Na-zionale. Non dispone di quasi alcuno strumento per affermare i pro-pri diritti e soprattutto non dispone di canali informativi idonei per assumere le decisioni più opportune.

Mentre operatori e strutture sono spesso ipertutelate da prote-zioni sindacali e corporative, i malati, già fragili per la loro condi-zione, appaiono disarmati. È una situazione che viene da lontano: la cultura medica è stata per secoli autoreferenziale, considerando il “paziente” una “cosa” o un “suddito”.

A partire dall’ultima riforma del 1992-93 sono stati peraltro in-trodotti all’interno delle aziende ospedaliere alcuni esili strumen-ti: l’Ufficio Relazione con il Pubblico (URP), la Carta dei Servi-zi, il consenso informato: l’esperienza mostra che tali strumenti, quand’anche fisicamente presenti, vengono spesso considerati for-mali e sono di difficile accesso.

Gli utenti dispongono di scarsi canali e quasi tutti dipendenti da chi produce e vende sanità a vario titolo (aziende cliniche, farmaceuti-che, operatori singoli ed associati, strutture).

Questa asimmetria informativa andrebbe corretta e integrata con regole diverse di sistema e con l’attivazione di centri e fonti di va-lutazione indipendenti di facile accesso, che pongano il cittadino in grado di conoscere e confrontare il grado di successo degli interventi terapeutici, i reali effetti e le eventuali controindicazioni connesse, il livello di preparazione e di esperienza degli operatori, il grado di eccellenza delle strutture, il livello di sicurezza, di aggiornamento ecc. di ogni struttura e servizio.

Tutto ciò per mettere i cittadini nelle condizioni migliori per decidere sulla propria salute, operando scelte in base a informazio-ni certe e indipendenti e non basandosi sulle informazioni parziali fornite da chi ha un oggettivo interesse all’estensione dei consumi sanitari, anche se inutili.

In altri paesi la situazione è diversa: in Inghilterra, per esempio, le strutture ospedaliere vengono valutate da un ente indipendente e l’esi-to delle valutazioni è pubblico e pubblicizzato. Esistono inoltre degli Health Commissioners nazionali, esterni e indipendenti dal NHS, cui i cittadini possono rivolgersi per far valere le loro ragioni, che hanno potere di intervento sulle strutture e sugli operatori del sistema.

Anche in Francia recentemente è stato introdotta una specie di valutazione pubblica (via internet) da parte degli utenti nei con-fronti dell’attività dei medici. In Italia questa notizia è stata definita una “follia” da esponenti di associazioni mediche.

Questa è la differenza culturale prima che organizzativa tra il SSN italiano e quello di altri paesi: prevalgono con tenacia gli interessi di categorie e di gruppi concentrati su quelli degli utenti.

Tecnologie informatiche e nuovi canali di diffusione di informa-zioni indipendenti possono avere un grande ruolo nell’organizzazio-ne sanitaria, restituendo diritti e capacità reale di scelta ai cittadini.

Sinora questo non è avvenuto e gli interessi della sanità hanno generalmente prevalso su quelli della salute. La prima esigenza di cambiamento nell’organizzazione sanitaria non sta dunque nell’au-mentare la quantità di sanità, ma nell’abolire l’asimmetria informa-tiva e colmare il deficit di informazione per i cittadini.

1.3.6 La sanità nazionale: verso il Nuovo Sistema Informativo Sanitario (NSIS)

Le prestazioni attese del sistema informativo di governo sono acqui-

sire, conservare, organizzare, proteggere e far usare dati complessi. I dati che vengono raccolti mentre i pazienti vengono assistiti sono strumenti molto potenti per migliorare la rete di assistenza. Perchè questo possa accadere, dobbiamo parlare la stessa lingua, quindi chiamare le stesse cose con lo stesso nome. Vedremo come l’innova-zione e le tecnologie ci possono aiutare a rendere il Servizio Sanita-rio Nazionale (SSN) un sistema che lavora in modo integrato per il cittadino-paziente. Perché questo possa accedere bisogna ripensare i luoghi dove si fa assistenza, il modo di fare assistenza, le professioni sanitarie e bisogna rendere partecipe il cittadino-paziente della sua assistenza-cura.

Definizione di un linguaggio comune: il progetto Mattoni SSNLa corretta progettazione e sviluppo di un sistema informativo di livello nazionale richiede la disponibilità di un linguaggio comune che consente l’interscambio tra il sistema informativo e i sistemi sanitari regionali. La definizione di questo linguaggio comune ha implicato la nascita del Progetto Mattoni SSN. La coniazione del termine mattone nasce pensando che ogni Regione sia autonoma nella realizzazione del proprio sistema sanitario purché i metodi di misura, raccolta, classificazione e codifica dei dati, chiamati appun-to mattoni, siano uniformi a livello nazionale.

È un obiettivo tutt’altro che banale: pensiamo solo all’esempio del tempo di attesa per una prestazione sanitaria. Possiamo definire in prima battuta il tempo di attesa come il tempo che intercorre tra la presentazione della richiesta di una prestazione sanitaria e il suo soddisfacimento. Tuttavia, ogni volta che il tempo di attesa deve essere rilevato entrano in gioco una serie di diversi fattori che rendo-no il compito di una misura uniforme molto arduo. Pensiamo per esempio a un esame mammografico, che può essere effettuato sia all’interno di un programma di screening di prevenzione, e quindi non richiesto dal paziente ma offerto dal sistema sanitario, oppure su prescrizione del medico curante di fronte a un sospetto diagno-stico. È chiaro che non ha alcun senso confrontare i dati qualora il tempo di attesa venga rilevato con la medesima modalità in entram-bi i casi. I programmi di screening vengono, infatti, programmati con largo anticipo rispetto all’esecuzione effettiva dell’esame e non ha senso parlare di tempo di attesa. Anche riuscendo in qualche modo a risolvere questo problema, ci troviamo di fronte a un altro dilemma: il tempo di attesa, infatti, viene valutato sulla base della data di soddisfacimento della richiesta, indipendentemente dalla modalità con cui la data dell’erogazione della prestazione sanitaria viene determinata. Può trattarsi infatti, della prima data disponibile

per la specifica prestazione proposta dal sistema informativo del-la struttura erogatrice oppure può essere una specifica richiesta del paziente. Supponiamo per esempio che una paziente abbia rifiuta-to la prima data disponibile proposta perchè la struttura erogatrice della prestazione non si trova sufficientemente vicino al suo luogo di residenza. È ovvio che la completa conoscenza dell’intero pro-cesso è fondamentale per un’accurata misura della performance di un sistema sanitario. Il decisore deve intervenire perché la rete di offerta non è dimensionata correttamente e non riesce a soddisfare la domanda oppure perchè la rete di offerta non è ben distribuita nel territorio? È evidente che se le informazioni non vengono raccolte correttamente nel livello assistenziale, non saranno di alcuna utilità per il decisore politico. È essenziale quindi che le regole di misura, raccolta, classificazione e codifica dei dati vengano applicate nei li-velli di erogazione dell’assistenza, in modo da garantire l’uniformità e soprattutto la comparabilità dei dati che giungono al governo.

Un altro tipico esempio di quanto lo scenario sanitario sia di-somogeneo a livello nazionale è il pronto soccorso. È chiaro che il significato dell’intervento urgente è univoco su tutto il territorio nazionale, ma non lo è il suo assetto organizzativo. Per esempio in alcune Regioni è richiesta la presenza di un medico sul mezzo di pronto intervento mentre in altre questo non viene ritenuto neces-sario. Generalmente, le strutture di pronto intervento sono dotate di sistemi informativi deputati, come detto precedentemente, anche alla gestione del triage. Le classi di emergenza (codice bianco, gial-lo e rosso) sono state uniformate a livello nazionale, cosa che non succede per le prestazioni erogate dalle strutture di pronto interven-to. La Regione Lombardia, per esempio, considera le prestazioni di pronto soccorso prestazioni ambulatoriali, a cui però, viene appli-cata una tariffa diversa rispetto alle prestazioni ordinarie di speciali-stica ambulatoriale per tenere conto del regime di urgenza. In altre Regioni, l’episodio di pronto soccorso viene considerato una specie di day-hospital, durante il quale vengono erogate prestazioni sani-tarie differenti, secondo il sospetto diagnostico, ma rappresentano, dal punto di vista della gestione dei dati, un unico evento. È chiaro che a livello di governo i dati inviati da Regioni con modelli di organizzazione del pronto soccorso così differenti non hanno alcun significato, perché non confrontabili.

Il progetto Mattoni SSN coinvolge 15 aree tematiche, articolabili in tre, che confluiscono tutte nella base dati NSIS: i Mattoni relativi a classificazioni e codifiche, quelli riferiti alle metodologie di analisi, e quelli che si interessano dei contenuti informativi.

Una volta che è stato definito è implementato il linguaggio co-

mune, bisogna preoccuparsi dei requisiti tecnologici attraverso la definizione di standard che permettono la comunicazione e l’inte-grazione di dati che provengono dai diversi livelli di assistenza (per esempio HL7, DICOM ecc.).

La sfida: spostare l’attenzione progressivamente dall’ospedale al territorio

Nonostante nella società odierna la chiusura di un ospedale è sem-pre oggetto di dibattiti e discussioni perché i cittadini-pazienti difatti avvertono la necessità di avere un ospedale nelle vicinanze del proprio luogo di residenza, la tendenza in futuro è quella di diminuire progressivamente il numero di posti letto. L’ospedaliz-zazione di pazienti-cittadini dovrebbe essere considerato un difetto della capacità di risposta di un sistema sanitario. Come sottoline-Come sottoline-ato da David Kerr, “We need to shift the balance of care and to think of hospital admission as a failure of the collective health sys-tem” [Christie, 2005]. Il ricovero, soprattutto quello specialistico, incide enormemente sulla spesa sanitaria complessiva. Un sistema che riesce a curare il paziente senza ospedalizzarlo è sicuramente un sistema migliore e più efficiente. Ovviamente, ci sono ancora pa-tologie per le quali l’ospedalizzazione del paziente è inevitabile. La cura degli altri pazienti invece, dovrebbe essere lasciata a livelli assi-stenziali meno costosi. È compito del governo riuscire a distribuire le risorse in modo da migliorare la capacità di risposta della rete di assistenza per favorire una progressiva diminuzione del numero di letti ospedalieri. È stato dimostrato che la cura delle malattie, nel momento in cui queste insorgono, ha un impatto sicuramente in-feriore dal punto di vista economico rispetto alla cura prestata nello stadio avanzato della malattia. Un sistema sanitario che permette alle persone di accedere al sistema per tutelare la propria salute, e quindi prevenire l’insorgenza di patologie o la progressione delle stesse, ha sicuramente un costo inferiore rispetto ai sistemi che ero-gano prestazioni sanitarie ai propri assistiti solo in casi strettamente necessari. Rimane comunque il problema di gestire la crescita del-la spesa sanitaria, soprattutto quella ospedaliera, che ha da sempre un’incidenza molto elevata. Possiamo citare l’esempio dei ricoveri per insufficienza cardiaca: a fronte di una crescita della popolazione di riferimento del 5% dal 2000 al 2003 si è assistito ad una crescita dei ricoveri ospedalieri del 12% e delle giornate di degenza del 19%. È evidente che per non portare la crescita della spesa sanitaria a li-velli non sostenibili, la rete di assistenza deve essere adeguatamente ristrutturata. Il problema principale però è dato dalla gestione di malattie croniche e dal costo che essa comporta. Il diabete mellito,

per esempio, comporta dei costi di ospedalizzazione non estrema-mente elevati, ma ciò che più preoccupa, è la crescita dell’incidenza nella popolazione; se questa non viene in qualche modo arginata, in breve periodo il sistema rischia di diventare incapace di rispondere in modo appropriato alla domanda di prestazioni sanitarie. L’appli-cazione di programmi di disease management è stata dimostrata esse-re fattore determinante nella prevenzione delle complicazioni e nel miglioramento della qualità della vita del paziente. Attraverso pro-grammi di formazione, prevenzione e il coinvolgimento del pazien-te nella sua cura, è possibile quindi controllare lo stato di salute dei malati di diabete mellito e prevenire l’insorgenza di complicazioni, che inevitabilmente portano all’ospedalizzazione del paziente stesso.

Gli obiettivi del NSISCome accennato precedentemente, il sistema sanitario oggi è con-cepito attorno alle strutture che erogano servizi sanitari. Ovviamen-te esistono norme che impongono l’obbligo alle strutture sanita-rie di conservare e proteggere i dati del cittadino; per esempio, per le aziende ospedaliere è in vigore l’obbligo di conservazione delle cartelle cliniche a tempo indefinito. L’obbligo di conservazione e protezione dei dati nasce però per motivi scientifici: in un sistema in cui ogni struttura sanitaria conserva i dati dei propri assistiti è il paziente che si deve muovere all’interno della rete di assistenza per integrare i propri dati. Per esempio, ogni cittadino che sia stato ri-coverato in un ospedale, può richiedere la propria cartella clinica. In un sistema sanitario centrato sul paziente invece, sono le strutture erogatrici di servizi sanitari che diventano responsabili della trasmis-sione dei dati del paziente.

Quando il livello di governo è interessato a ricevere dalla rete di assistenza solo dati aggregati di attività delle strutture, può disinte-ressarsi della modalità con cui ogni struttura produce i propri re-port. Non è fondamentale, per il livello del governo, che le strutture erogatrici abbiano sviluppato sistemi informativi al proprio interno, fin tanto che sono in grado di trasmettere al governo i dati necessa-ri. Ovviamente, la presenza di un sistema informativo favorisce la gestione dei dati, e la qualità del dato trasmesso migliora. Quando invece il livello di governo non si accontenta più di dati aggregati per struttura ma desidera raccogliere tempestivamente dati indivi-duali, integrati sul paziente, nel momento in cui questi vengono generati, la presenza di sistemi informativi nella rete di assistenza diventa fondamentale. Ovviamente, i dati inviati devono poter es-sere interpretabili univocamente da chi li riceve, cioè deve essere stato utilizzato il linguaggio comune che precedentemente è stato

definito. Il grande obiettivo di un sistema informativo cosi conce-pito è quindi quello di integrare tutte le informazioni relative alle prestazioni erogate, riconducendole al singolo cittadino, cioè istitu-ire un sistema di tracciabilità del cittadino e di individuazione delle strutture erogatrici (cosa sono, dove sono, la missione ecc.).

La creazione di un sistema di integrazione delle informazioni sa-nitarie individuali nell’ambito della progettualità del NSIS trae ori-gine dalla constatazione che qualità, appropriatezza ed economicità nella gestione del Servizio Sanitario Nazionale (SSN) si originano dall’interazione medico-paziente. Conseguentemente, un sistema informativo che si colloca ad un livello superiore rispetto a tale in-terazione non è in grado di cogliere le cause alla base dei livelli di performance complessivi del SSN.

Gli obiettivi del NSIS possono essere così posti:• Integrazione delle informazioni sanitarie individuali. Il sistema

informativo integrerà tutte le informazioni relative alle presta-zioni erogate, riconducendole al singolo cittadino.

• Monitoraggio della rete di assistenza. Il sistema informativo sarà focalizzato sulle strutture di erogazione (c.d. poli della rete di assistenza) e sulle prestazioni da queste erogate ai cittadini.

• Monitoraggio dei LEA e dell’appropriatezza. Il sistema infor-mativo monitorerà le prestazioni erogate sui diversi livelli di assistenza e supporterà l’analisi dell’appropriatezza delle pre-stazioni stesse.

• Monitoraggio dei costi. Il sistema informativo rileverà i costi relativi alle strutture di erogazione (costi dell’offerta) e costi relativi all’assistenza sanitaria erogata al singolo cittadino (co-sti della domanda).

• Monitoraggio delle liste di attesa. Il sistema informativo mo-nitorerà le liste di attesa sia dal punto di vista delle strutture erogatrici (tempi di attesa nelle singole strutture per tipologia di prestazione), sia dal punto di vista del cittadino (tempo ef-fettivamente atteso dal singolo cittadino per l’erogazione delle singole prestazioni).

• Monitoraggio e tutela della salute mentale. Il sistema informati-vo integrerà le informazioni relative alle strutture di erogazione, alle prestazioni erogate ed ai cittadini destinatari dell’assistenza.

• Monitoraggio del ciclo di vita del farmaco e dell’impiego dei me-dicinali (in fase di approfondimento). Il sistema informativo integrerà le informazioni relative alle diverse fasi che compon-gono il ciclo di vita del farmaco e monitorerà l’impiego dei medicinali, collegandosi alle informazioni sanitarie individuali.

• Osservatorio degli investimenti pubblici in sanità. Il sistema in-

formativo consentirà di programmare e valutare i progetti d’in-vestimento, nonché di monitorarne lo stato di avanzamento.

Tutti gli obiettivi si inseriscono in una cornice strategica unitaria (Figura 1.3), caratterizzata da numerose interconnessioni e com-plessivamente finalizzata al monitoraggio del bilanciamento tra co-sti e qualità del servizio sanitario.

È evidente che gli obiettivi individuati sono funzionalmente interconnessi perché, congiuntamente, soddisfano le esigenze dei diversi livelli del SSN, così come sono logicamente interconnessi perché fanno tutti riferimento:• al cittadino e alle prestazioni (sviluppo di un sistema di inte-

grazione delle informazioni sanitarie individuali);• alle strutture di erogazione dell’assistenza sanitarie ed alle pre-

stazioni (monitoraggio della rete di assistenza).Il concetto fondamentale è quello di legare la prestazione sanitaria di un cittadino al medico che l’ha prescritta e alla struttura che l’ha erogata, registrando il tempo intercorso tra la richiesta della presta-zione e il suo soddisfacimento (Figura 1.4).

Il problema della tutela della privacy del cittadinoIl problema della privacy nasce nel momento in cui si decide che i dati del paziente non rimangono più confinati all’interno della struttura sanitaria dove sono stati generati, ma vengono inviati all’organo responsabile della loro gestione: è ovvio che il problema

Monitoraggiodella rete di assistenza

Integrazioneinfo sanitarie individuali

STRUTTURE PRESTAZIONIPRESTAZIONI CITTADINO

Figura 1.4Percorso del cittadino: cittadino-prestazione-

struttura

Figura 1.3Cornice strategica del

Investimentipubblici in sanità

Monitoraggio della rete di assistenza

Monitoraggio e tutela della salute

mentale

Integrazione infosan. individuali

Monitoraggiodei costi

LEAed appropriatezza

Liste di attesa

Ciclo di vitadel farmaco

della privacy di dati inviati in rete assume dimensioni molto mag-giori del problema della salvaguardia dei dati immagazzinati in una struttura sanitaria, accessibili a un numero limitato di persone. Il Garante della Privacy si è posto il problema se fosse davvero neces-sario per chi governa la sanità avere a disposizione i dati individuali dei cittadini integrati sul loro percorso sanitario, ovvero se fosse ne-cessario conoscere l’identità del cittadino di cui si conosce il percorso sanitario. In effetti, il possesso del dato identificativo è stato ritenuto eccedente per chi si trova a livello di governo: il decisore politico, per il suo scopo di governo giusto della sanità, dovrebbe infatti disporre di dati che gli permettano di valutare accuratamente la performance del sistema sanitario in modo da poter intervenire nei suoi punti più deboli, per renderlo migliore per i cittadini. L’opinione del Garante della Privacy è che per il suo scopo istituzionale, il livello di governo dovrebbe operare solo sui dati già aggregati, in modo da poter leggere i fenomeni attraverso valutazioni statistiche. Da quanto detto prece-dentemente risulta tuttavia essere necessario integrare sul cittadino i dati relativi al percorso sanitario, è non disporre solamente di dati integrati per esempio per prestazione e per struttura. Per rispondere all’esigenza di creare un sistema centrato sul paziente ma anche tute-lare la privacy dei cittadini, una possibile soluzione è anonimizzare i dati integrati sul percorso sanitario dei cittadini.

Tuttavia, la conoscenza del dato identificativo a livello di gover-no può risultare più che utile in particolari situazioni di emergenza sanitaria. Citiamo il caso Lipobay, il farmaco della Bayer contro il colesterolo ritirato dal commercio perché sospettato di aver causato la morte di più di 50 persone in tutto il mondo. Si presuppone che la causa delle morti fosse un’interazione imprevista del farmaco con altri farmaci. Se al momento dell’insorgenza della crisi sanitaria il li-vello di governo avesse avuto a disposizione informazioni identifica-tive del percorso sanitario dei cittadini, avrebbe potuto intervenire direttamente in tutti quei casi dove avesse riscontrato l’assunzione più o meno contemporanea del Lipobay e dei farmaci con cui que-sto interagiva in modo imprevisto.

La soluzione, che sembra essere un compromesso tra il dato ano-nimo e il dato identificativo, è il dato cosiddetto pseudoanomizzato. Si tratta di dati anonimi, codificati opportunamente in modo da poter, attraverso specifici meccanismi di reversibilità, in situazioni molto particolari, come per esempio emergenze sanitarie, e in modo molto controllato, risalire all’identità del cittadino. Ovviamente si può anche optare per una anonimizzazione irreversibile, qualora si giudichi che per il livello di governo il possesso di dati identificativi non sia necessario.

Il problema della tutela dei dati del cittadino resta comunque un argomento molto dedicato. Anche se non possiamo affermare che il cittadino è proprietario dei suoi dati, ne è sicuramente l’origine. In un sistema sanitario di tipo universalistico come quello italiano, i cittadini sono assistiti dallo Stato, attraverso il SSN: pertanto lo Sta-to ha sicuramente la capacità operativa di gestione e coordinamento dei dati del cittadino, che i cittadini stessi non hanno. È questione fondamentale se lo Stato deve semplicemente aiutare il cittadino nel coordinamento dei propri dati sanitari attraverso la realizzazione di centri di assistenza sul modello, per esempio, dei centri di assistenza fiscale, oppure deve incamerare i dati sanitari dei cittadini e quindi diventare, non solo responsabile del coordinamento, ma anche pro-prietario dei dati.

È fondamentale, nella progettazione di un sistema informativo sanitario, a livello di governo, porre la massima attenzione al pro-blema della tutela della privacy del cittadino e introdurre misure che garantiscono la protezione del dato individuale. L’aspetto della privacy non deve in alcun modo essere trascurato o raggirato per volontà di semplificazioni nella realizzazione del sistema e accelera-zioni tecnologiche.

Progetto del NSISSulla base dei dati che giungono dal sistema sanitario il livello di governo deve poter prendere decisioni che riguardano l’assetto or-ganizzativo del sistema stesso. In particolare, bisogna conoscere sia il flusso di prescrizioni, che quantificano la domanda sanitaria, sia i flussi di dati che provengono dalle strutture erogatrici, riguardanti il numero delle prestazioni sanitarie effettuate, il numero del per-sonale, i costi sostenuti ecc. In questo modo diventa possibile con-frontare la dimensione della domanda con la dimensione dell’of-ferta e capire se sia necessario intervenire sulla rete di assistenza, e soprattutto, se viene giudicato che una ristrutturazione del sistema sia effettivamente necessaria, capire dove e come intervenire, cioè individuare i punti deboli del sistema. L’ equilibrio si raggiunge solo se l’offerta riesce a soddisfare una domanda che chiamiamo appro-priata, non solo dimensionando opportunamente l’offerta, e quindi la rete di assistenza, ma anche cercando di moderare la domanda in modo da renderla appropriata. È ben noto infatti un fenomeno che viene chiamato domanda indotta dall’offerta, in cui, a fronte della presenza di una rete di assistenza sovraproporzionata rispetto al reale bisogno di salute dei cittadini, i medici tendano a prescri-vere prestazioni sanitarie anche laddove esse non siano strettamente necessarie.

Il progetto del Nuovo Sistema Informativo Sanitario poggia pro-prio su questi due assi fondamentali (Figura 1.5): il primo è il fatto di poter integrare a livello individuale le informazioni sanitarie, e quindi raccogliere il bisogno espresso di sanità, e il secondo riguarda la rete di assistenza, cioè la capacità di offerta che soddisfa il bisogno di sanità. Un confronto dei due assi permette di avere uno stru-mento potente di analisi decisionale a livello di governo. Una volta effettuata l’analisi strategica, cioè una volta individuati gli obiettivi del sistema informativo a livello nazionale, si passa alla progettazio-ne della base dati vera e propria.

La Figura 1.6 mostra il macromodello entità relazioni del NSIS che definisce le informazioni necessarie al NSIS (entità) e le associa-zioni di significato che esistono tra di esse (relazioni):• l’assistenza sanitaria a ciascun cittadino è assicurata dall’Azienda

sanitaria di riferimento, la quale fa riferimento a una Regione;• ciascun cittadino può accedere all’assistenza sanitaria attraver-

so la scelta di un Medico di Medicina Generale (o Pediatra di Libera Scelta) che fa riferimento ad una Azienda Sanitaria Locale;

• l’assistenza sanitaria viene erogata attraverso una rete di assi-stenza composta da strutture che erogano prestazioni ai cittadi-ni, dando vita ai singoli eventi, che rappresentano l’interazione tra il cittadino e il SSN (ricoveri, specialistica ambulatoriale, assistenza domiciliare ecc). Ciascuno evento, a cui corrisponde una specifica prestazione, è collocabile su un livello assistenzia-le e può comportare un tempo di attesa;

• ciascuna prestazione viene richiesta da una tipologia di pre-scrittore, che può essere il Medico di Medicina Generale, il Pediatra di Libera Scelta, lo Specialista, ecc;

• per l’erogazione delle prestazioni le strutture impiegano risorse a fronte delle quali sostengono dei costi;

Rete Assistenza Integrazione infosan. individuali

LEAed appropriatezza

Liste di attesa

Tracciabilitàdel farmaco

Figura 1.5I due assi su cui poggia il NSIS

• le strutture fanno territorialmente riferimento a una Azienda sanitaria, la quale a sua volta afferisce a una Regione;

• ciascuna Regione stipula con il Ministero un accordo di pro-gramma, attraverso il quale vengono finanziati dei progetti di investimento sulle Aziende sanitarie.

Il NSIS, quindi, attraverso il progressivo sviluppo di un sistema di informazioni sanitarie individuali, dovrà poter:• disporre di informazioni omogenee rispetto ai singoli eventi

(ricoveri, specialistica ambulatoriale, assistenza domiciliare ecc);• ricondurre ciascun evento al cittadino che ha interagito con

il SSN; • disporre di ulteriori informazioni per l’individuazione dei per-

corsi diagnostico terapeutici seguiti.Tali informazioni potranno essere utilizzate sia per funzioni di go-verno del SSN, sia, in stadi evoluti del sistema, per funzioni di dia-gnosi, cura e riabilitazione sul singolo paziente.

LEGENDA DELLE CARDINALITÀ DELLE RELAZIONI

uno a molti

uno a molti (partecipazione obbligatoria)uno a uno (partecipazione opzionale)

Min. della Salute

Regione

Aziende sanitarie

Tipologia Medico Prescrittore SSN

Strutturedi erogazione Cittadino

Evento

Tempi di attesa

Accordodi programma

Progetti

Risorse

Figura 1.6Macro modello entità-

relazioni del NSIS

Figura 1.7Stadiazione della

realizzazione del NSIS

Patient File

Solo SDOPrestazioni sanitarie

Esito delle prestazioni (referto)

Diagnosi/Sospetto diagnostico e informazioni personali

Integrazione con il sociale

Stadio 1

Stadio 2

Stadio 3

Stadio 4

La meta ultima è quella di arrivare al cosiddetto patient file, che in-tegra le informazioni del cittadino nel suo percorso all’interno della rete di assistenza; la complessità di tali obiettivi ha determinato la scelta di adottare, dove opportuno, un approccio incrementale per stadi (Figura 1.7), in modo tale da poter ottenere risultati in tempi più rapidi, garantendo comunque uno sviluppo coerente con le fi-nalità complessive del sistema.

Gli stadi della realizzazione del progetto NSISCome accennato precedentemente, per non porsi davanti a un obiettivo troppo ambizioso e rischiare di non arrivare mai alla realiz-zazione, in base alla difficoltà della realizzazione stessa e la eventuale disponibilità di flussi informativi gia in atto, sono stati individuati quattro stadi principali, illustrati in Figura 1.8.

Si è partiti dalla realizzazione di un’anagrafe sanitaria a livello na-zionale (stadio 1). Diverse Regioni utilizzavano un proprio sistema di codifica sanitaria, che perde ogni significato se il paziente, nel suo percorso all’interno della rete di assistenza, si sposta tra diverse Regioni. L’anagrafe sanitaria a livello nazionale è stata realizzata in Lombardia, attraverso il progetto della Carta Regionale, e appog-giandosi al Ministero dell’Economia nelle restanti Regioni. È stato scelto infatti di affidare la gestione dell’anagrafe sanitaria alla strut-tura che già gestiva l’anagrafe fiscale, e costituire, insieme all’anagra-fe del Ministero dell’Interno, un contenitore completo dei dati del cittadino e disporre quindi con certezza della residenza, del codice fiscale e dei dati sanitari di ogni cittadino.

La realizzazione di un flusso degli esiti delle prestazioni, cioè i referti (stadio 2) rappresenta un problema logistico non irrilevan-te. Non è possibile infatti pensare che un’unica base dati a livello nazionale possa gestire una tale quantità di dati. Si pensa piuttosto alla realizzazione di un sistema informativo nazionale che funga da

di baseCITTADINO

STADIO 1

Info sanitariepersonali

STADIO 3STADIO 2 STADIO 4

Info tipologiaprescrittorePRESCRITTORI

Info accessorie Tempi di attesaPRESTAZIONI

Sospettodiagnosticoe diagnosi

Esiti delleprestazioni(REFERTI)

Prestazioni sociali

Soggetto erogatoreAZIENDA

Figura 1.8Schema dettagliato degli stadi della realizzazione del progetto NSIS

puntatore agli effettivi contenitori dei referti, locati a livello regio-nale. È ovvio che la presenza di un sistema a livello nazionale, anche con sola funzione di puntatore, è indispensabile per tenere traccia di pazienti a cui vengono erogate prestazioni in diverse Regioni. (Stadio 3)

Un ultimo passo nella realizzazione del patient file completo è l’integrazione dei dati sulle prestazioni sociali (stadio 4).

Figura 1.9Raccolta delle prestazioni di specialistica

ambulatoriale ed assistenza farmaceutica

Livello Regionale

Livello ASL

FarmadatiFarmaciaPresidio

Data EntryRicette

Dati aggregati

- I dati relativi alle Prestazioni Ambulatoriali vengono inviati al MdS in forma aggregata.- I dati di Assistenza Farmaceu-tica sono oggetto di data entry manuale e vengono inviati al MdS in forma aggregata.

Livello Nazionale

Tabella 1.6Stato attuale del

progetto NSIS

CONTENUTO INFORMATIVO

SPECIALISTICA AMBULATORIALE

OSSERVATORIO INVESTIMENTI PUBBLICI IN SANITÀ

RILEVAZIONE DEI DECESSI

MONITORAGGIO E TUTELA DELLA SALUTE MENTALE

ASSISTENZA FARMACEUTICA

MONITORAGGIO RETE DI ASSISTENZA (FASE 2)

MONITORAGGIO RETE DI ASSISTENZA (FASE 1)

DISTRIBUZIONE DIRETTA

ASSISTENZA RESIDENZIALE E SEMIRES. PER ANZIANI

Attivato

Studio di fat.in corso

Da attivare

Attivato

Studio di fat.in corso

Attivato

Studio di fat.da attivare

Da attivare

ALIMENTAZIONE

"Nucleo minimo"

Applicativotransazionale

“Nucleo minimo”

Applicativotransazionale

PERIODICITÀ

Trimestrale

Su base evento

Semestrale/Annuale

Trimestrale

Su base evento

Stato del progetto: scenario transitorio e scenario a regimeLa fase di sperimentazione ha coinvolto tredici Regioni nelle quali esisteva già un flusso di informazioni a livello regionale: è stato de-finito un nucleo minimo di informazioni relative alle prestazioni di specialistica ambulatoriale e assistenza farmaceutica da integrare con la Scheda di dimissione Ospedaliera (SDO) [Ministero della Salute, 2007], la cui trasmissione era già in atto. Lo schema della raccolta dei dati è mostrato in Figura 1.9. Nonostante fossero state coinvolte solo 13 Regioni su 20, sono stati raccolti più di 1,3 mi-liardi di record.

Allo stato attuale lo stadio 1 è in fase operativa di raccolta e ana-lisi dei dati mentre per gli stadi successivi si stanno creando le con-dizioni necessarie affinché possano essere realizzati. In particolare, si stanno realizzando i requisiti tecnologici è di uniformità nella misura, raccolta, classificazione e codifica dei dati accennati prece-dentemente (Mattoni SSN), in modo che, una volta avviata la fase di raccolta, le informazioni vengano interpretate a livello di governo con lo stesso significato inteso da chi le ha generate. La Tabella 1.6 mostra dettagliatamente lo stato attuale del progetto, indicando le iniziative già avviate, da avviare e in studio di fattibilità.

Lo scenario a regime invece prevede di sviluppare la cooperazio-ne tra i sistemi regionali e il NSIS per condividere le informazioni relative alle prestazioni, implementando un modello pronto a rece-

Figura 1.10Schema dei flussi informativi a regime

Livello Regionale

Livello ASL

- Sistema Informativo “Art.50” si colloca al livello delle Struture di Erogazione e restituisce i dati all’Azienda Sanitaria.- Tale sistema raccoglie e rende disponibili unicamente i dati raccolti per le proprie finalità.

Livello Nazionale

Presidio Farmacia

pire le nuove classificazioni/codifiche previste nel progetto Mattoni SSN. La Figura 1.10 ci mostra uno schema dei flussi informativi a regime tra i livelli di assistenza, regionali e nazionale.

Bibliografia

Paragrafo 1.2Cristiani P, Pinciroli F, Stefanelli M, a cura di. I Sistemi Informativi

Sanitari. Bologna, IT: Pàtron Editore; 1996. p. 35-49.Fuji Medical Systems USA. SYNAPSE (PACS). [Online] 2008.

Disponibile all’indirizzo: http://www.fujimed.com/products-services/network-systems/default.asp?location=1&area=5 &id=0&subid=0 Ultimo accesso: 16 Aprile 2008.

Miller B. Vital signs of identity. IEEE Spectrum. 1994;31(2):22-30.Pinciroli F, Combi C, Pozzi G. Basi di dati per l’Informatica Medi-

ca. Bologna, IT: Pàtron Editore; 1998. p. 167-184.Ravera L, Colombo I, Tedeschi M, Ravera A. Security and privacy

at the private multispecialty hospital Istituto Clinico Humanitas: strategy and reality. Int J Med Inform. 2004;73(3):321-4.

Samei E, Seibert JA, Andriole K, Badano A, Crawford J, Reiner B, Flynn MJ, Chang P. AAPM/RSNA tutorial on equipment selec-tion: PACS equipment overview: general guidelines for purchas-ing and acceptance testing of PACS equipment. Radiographics. 2004;24(1):313-34.

Sun Microsystems. Manage and Store - Enterprise Content Smart-ly. SunTM Content Infrastructure System. White Paper. [online] 2005. Disponibile all’indirizzo URL: http://www.sun.com/sto-ragetek/white-papers/intelligent_mgmt_cis.pdf Ultimo accesso: 12 Maggio 2008.

Paragrafo 1.3Christie B. Report calls for more community based on health care

in Scotland. BMJ, 2005; 330:1288Ministero della Salute. Che cos’è la SDO? [Online] 2007; dis-

ponibile all’indirizzo URL: http://www.ministerodellasalute.it/programmazione/sdo/sezApprofondimenti.jsp?label=sdo Ultimo accesso: 23 luglio 2009

QBGROUP spa. Il sito nazionale sui DRG e sul management della sanità [online] 2007; disponibile all’indirizzo URL: http://www.drg.it Ultimo accesso: 23 luglio 2009

2 Vincoli e opportunità

2.1 La cartella clinica informatizzata

2.1.1 Introduzione

La cartella clinica è un indispensabile supporto al lavoro del medi-co. Fra attesa di tecnologie più adatte e sottoimpiego di prestazioni pronte, però, oggi rimangono ancora poco diffuse le applicazioni informatiche che, indirizzate alla gestione delle cartelle cliniche, sia-no giudicate soddisfacenti dagli utenti. Tra le ragioni della modesta soddisfazione vi sono anche persistenti incapacità ‒ degli strumen-ti e dei metodi informatici e telematici ‒ di soddisfare le esigenze che i medici hanno. Si tratta di esigenze sia naturali ma sia anche molto impegnative per la tecnologia. Fortunatamente alcune tra le difficoltà in gioco sono rese prevedibili da una buona tassonomia informatica delle informazioni cliniche, della quale gli utenti clinici diventino consapevoli. Altresì una corretta tassonomia aiuta nell’in-dividuazione di un buon numero di facilitazioni operative di alto valore, che non vanno dimenticate, anche perché spesso sono indi-spensabili ad alcuni rilevanti progressi della Medicina.

La compilazione a penna di una cartella clinica cartacea, la rac-colta eseguita fisicamente a mano di documenti e lastre in un faldo-ne, la collocazione manuale del faldone in un ripiano di archivio, la ripresa del faldone dal ripiano per leggervi a vista i contenuti di dati, lastre, biosegnali e altre bioimmagini: tutte queste sono azioni che chiunque esegue con grande facilità e immediatezza operative. Invece l’introduzione delle tecnologie dell’informazione costringe ad abbandonare aspetti di gestione spesso avvertiti come molto utili e naturali. Valga, al proposito, l’esempio del dispiegamento su un tavolo del contenuto di un faldone. In tal caso l’integrazione umana fra i differenti tipi di dati è immediata e molto più naturale rispetto a quando, con difficoltà anche non trascurabili, l’integrazione viene perseguita sul video di un calcolatore. Ne segue il costante bisogno di individuare quelle funzioni che sono utili a curare meglio il pa-ziente, che sono impossibili da svolgere a mano e che sono candi-dabili a divenire funzionalità presenti in un pacchetto informatico. È probabile che un controllo di qualità che venga automaticamente

eseguito in fase di raccolta dati e l’elevato livello di complessità e flessibilità delle interrogazioni consentite sono i risultati più utili della informatizzazione delle cartelle cliniche.

Dal punto di vista generale, e quindi anche da quello informati-co, gli scopi di compilazione di una cartella clinica sono molteplici e a volte conflittuali. Da quello di “testimonianza notarile” a quello di “evocatore negli utenti di conoscenze implicite pregresse”, allo sco-po di “archiviazione”. Questa ultima funzione, storicamente intesa nella sua accezione “conservativa”, da ormai molto tempo è chiama-ta a essere, pur aiutata dagli strumenti del caso, anche “propositiva”.

2.1.2 Sezioni

Le sezioni di una cartella clinica possono essere descritte schemati-camente nel modo seguente.• Anagrafica: il primo obiettivo, obbligatoriamente presente, è

l’identificazione del paziente. Le voci attese caratterizzate da immutabilità nel tempo sono: nome, cognome, sesso, data di nascita, luogo di nascita. Ma ci aspettiamo anche voci quali le coordinate di comunicazione (indirizzo civico, telefono), indi-rizzo di posta elettronica, professione che sono invece mutabili nel tempo e che è indispensabile tenere aggiornati pena l’im-possibilità di comunicare.

• Ragioni del ricovero: questa sezione ha l’obiettivo di sintetiz-zare le patologie che hanno portato al ricovero del paziente. Queste saranno certe se la sezione viene compilata alla fine del ricovero; potrebbe dover essere corretta successivamente, se compilata all’inizio del ricovero.

• Anamnesi familiare: vengono descritte sommariamente le pa-rentele del paziente sia verticalmente (con ascendenti e discen-denti) che orizzontalmente (con coniuge, fratelli e sorelle) per evidenziare eventuali patologie ereditarie o contagiose.

• Anamnesi fisiologica: in questa sezione vengono riportati tutti i dati utili a descrivere in modo generico stato di salute a alcuni abitudini del paziente.

• Anamnesi patologica prossima: questa sezione mira a sintetizza-re e standardizzare la descrizione dei sintomi così come viene riferita dal paziente. Si distinguono: sintomi, segni, localizza-zione, entità, durata e altro da segnalare.

• Anamnesi patologica remota: l’obiettivo della sezione è di forni-re un efficace strumento di supporto per il processo deduttivo del medico includendo la storia clinica pregressa del paziente. Comprende quindi un campo “terapia” a fronte di ogni pre-

37Capitolo 2Vincoli e apportunità (oppure Richiami di Informatica BioMedica)

gressa patologia riscontrata. • Esame obiettivo particolare: comprende le valutazioni del me-

dico riguardo all’analisi dei diversi sistemi corporei, che tipi-camente sono: capo, occhio, naso, orecchio, faringe, apparato cardiovascolare, apparato polmonare, ecc.

• Esami di laboratorio: questa sezione raccoglie i risultati delle analisi di laboratorio (esami del sangue: data, sodio, potassio, calcio, ferro, trigliceridi, ecc; esami delle urine: data, colore, albumina, glucosio, ecc.).

• Decisioni: l’utilizzo del termine “decisione” al posto di “dia-gnosi” tende a sottolineare nella cartella clinica l’aspetto di supporto al percorso decisionale del medico. La vera diagnosi sarà quella alla fine del percorso decisionale: decisioni di atte-sa, richiesta di ulteriori accertamenti e assegnazione di terapia.

• Foglio di diagnosi.

2.1.3 Gestione

Le famiglie di operazioni necessarie alla gestione informatica delle cartelle cliniche sono:• la compilazione, estesa alle accezioni di aggiungere, correggere,

cancellare, aggiornare, firmare;• l’interrogazione, estesa alle accezioni chiedere, selezionare, con-

tare, riordinare;• la archiviazione, intesa sia conservativa sia propositiva, inclusa

la protezione.A ogni operazione è indispensabile affiancare l’avverbio “efficace-mente”, che sottolinea il desiderio di ottenere un sistema che l’uti-lizzatore avverta utile.

Osservando i dati clinici dal punto di vista delle basi di dati infor-matiche, i principali tipi di dato sono:• Valori numerici, associabili a intervalli di normalità, di patolo-

gia, ovvero di errore del dato medesimo. L’interrogazione è so-litamente efficace, anche se complicata da eventuali evoluzioni dei valori di definizione degli intervalli.

• Brevi stringhe di testo, molto meglio se provenienti da diziona-ri specifici del settore e standardizzati. Sono ben interrogabili con parole chiave.

• Testi estesi dove, anche quando il testo è strutturato, l’inter-rogazione con parole chiave è di modesta efficacia quando le attese di interrogazione sono di tipo concettuale.

• Immagini e filmati a varia risoluzione e a vario numero di co-lori, la cui interrogazione semantica risulta applicabile, in ge-

nerale, soltanto al referto che essere generano, e rimane quindi esposta alle discrezionalità del refertatore, per ridurre le quali un condiviso dizionario mirato è strumento indispensabile.

• Tracce audio della voce umana, la cui interrogazione richiede il preliminare riconoscimento vocale del parlato.

La conversione dell’insieme eterogeneo di dati appena descritto in formato elettronico si è rivelato tutt’altro che semplice. Tuttavia, negli ultimi quindici anni, sono stati sviluppati svariati applicati-vi mirati all’archiviazione e consultazione di cartelle cliniche, svi-luppati in collaborazione con gli stessi medici e operatori sanitari. Rimangono comunque una serie di esigenze e di problemi che ne rendono complessa la gestione, qualunque siano le tecniche – non soltanto quelle informatiche – con le quali la gestione venga realiz-zata, aspetti che possono complicarla fino al punto da compromet-tere la tanto attesa efficacia di interrogazione dei dati, nel modo in cui usualmente questa efficacia è attesa dall’utente clinico, sono:• la eventuale necessità di storicizzazione del dato;• la, a volte, modesta precisione del dato, che obbliga a una sua

contestualizzazione statistica;• differenti livelli di precisione dei dati di una stessa grandezza;• la significatività del dato rispetto alla interrogazione prospet-

tata;• la necessità di integrazione tra differenti tipi di dati e il venta-

glio di aspettative funzionali che la parola integrazione genera tra gli stessi utenti;

• i necessari livelli di protezione dei dati, sia in termini di riserva-tezza che di sicurezza.

È probabile che i risultati più utili della informatizzazione delle car-telle cliniche riguardino:• un sostenibile controllo di qualità dei dati, che venga esegui-

to al momento della loro raccolta nel modo più automatico possibile;

• la capacità di archiviare grandi quantità di dati;• la affidabilità, la laboriosità e la flessibilità delle interrogazioni

consentite, anche se esse rimangono semplici;• la elevata velocità di esecuzione delle operazioni informatiche.Quando all’utente del sistema informatico si chiede di sostenere il costo richiesto dalla immissione dei dati del paziente in un sistema, si deve aver previsto quali saranno i ritorni che – nel nostro caso – il medico otterrà, quali utilità – per il paziente, per sé medesimo, per il progresso delle conoscenze – il medico assocerà a ciascuno dei ritorni individuati.La diffusa attesa di un maggior grado di soddisfazione indica una

caratteristica di mercato in cui rimane positivamente alto l’interesse dell’utente finale a percepire, sperimentare, far proprie innovazioni che si dimostrino utili. La via necessaria da seguire passa da una conoscenza maggiormente condivisa, comunque dialetticamente interpretata da utenti e costruttori, ma in modo più coinvolto.

2.1.4 Analisi e indicazioni ai clinici

A. L’uso di discrezionalità espressive – quali la forma di testo libero, anche quando rivolta soltanto a sintetizzare un referto ritenu-to troppo lungo o dettagliato, come pure l’uso di aggettivi non pre-elencati esaustivamente, quindi senza che ai preesistenti se ne possa aggiungere qualche altro in modo incontrollato – nega la possibilità di applicare ai dati un’interrogazione informatica au-tomatizzata, efficace al punto di essere avvertita come utile nella clinica. Di conseguenza, nella compilazione della cartella clinica, non deve esserci possibilità di testo libero.

B. Soltanto quando dello specifico aspetto trattato in una certa li-mitata parte non è nota una conoscenza sufficiente strutturata, è vero che il testo libero è la forma espressiva che consente di documentare – pur soggettivamente – quanto di volta in volta venga percepito dal compilatore come notevole. In tal caso, se si vuole continuare a perseguire lo scopo di una “interrogazione informatica automatizzata”, allora si dovrà prevedere un termine temporale in cui procedere a revisione delle compilazioni in testo libero, revisione che sia rivolta alla individuazione di una qualche forma di strutturazione di quella parte.

Di conseguenza, ogni volta che l’utenza clinica chiede l’impiego del testo libero, essa deve indicare una scadenza di revisione dei contenuti e nominare la coppia di responsabili (clinico e infor-matico) della revisione.

C. Ogni dato che venga introdotto da tastiera espone a rischio di errori, tipicamente quelli di battitura. Di conseguenza, se si vuole favorire una buona qualità di esecuzione della raccolta dei dati, l’uso della tastiera va limitato al minimo. Ciò normalmente av-viene massimizzando l’uso di dizionari che, tipicamente quando sono brevi, possono anche essere definiti in loco, a patto però che siano sottoposti nel tempo a buone manutenzioni, pena la forte probabilità di cadere in errori al momento della interrogazione, errori che solitamente sono rilevanti.

D. L’aiuto alla interrogazione efficace dei dati è tra le maggiori aspetta-tive dei ritorni attesi dalla informatizzazione delle cartelle cliniche di reparto. Tuttavia, al fine di non fomentare aspettative irrealisti-che, conviene condividere la tripletta che, in ordine crescente di difficoltà informatiche, distingue tra le seguenti tre famiglie.

• Reportistica: è quella tipica dei ripetitivi resoconti periodici, solitamente quantitativi, che l’utente deve produrre. Le strut-ture delle tabelle e dei grafici, come pure le architetture dei do-cumenti in cui essi vanno inseriti, sono dettagliatamente pro-gettabili e concordabili a priori, di concerto tra utente clinico e fornitore informatico. Solitamente la reportistica apprezza la stabile ripetitività del formato dei documenti. La risposta informatica alla richiesta di reportistica è basata sia su fogli elettronici – valga l’esempio di Excel – sia sull’impiego di qual-che diffuso linguaggio di programmazione, quale per esempio il C. Mentre il foglio elettronico mantiene una certa flessibilità di definizione a posteriori delle priorità di elaborazione dei dati di ingresso, un linguaggio come il C privilegia efficienze di impiego delle risorse informatiche.

• Interrogazione: è la situazione nella quale, dopo che avrà otte-nuto la risposta alla domanda che formula – contrariamente a quanto succede alla successiva famiglia di “data mining”, qui l’utente sa ben dettagliare la domanda, – mai l’utente ripete-rà la domanda uguale a sé stessa. La risposta informatica alla richiesta di interrogazioni è usualmente basata sull’impiego di linguaggi di interrogazione di basi di dati, linguaggi tra i quali il più frequentemente citato è SQL, con la semplice ed efficace struttura che indica cosa, dove e a quali condizioni cercare.

• Data Mining: è la situazione nella quale l’utente formula la sua – certamente motivata – istanza di conoscenza soltan-to in termini che, benché a lui utili, rimangono purtroppo molto generici riguardo all’organizzazione secondo la quale i dati sono stati raccolti. La risposta informatica alla richiesta di Data Mining si basa su un aggregato di tecniche, ormai abbastanza note, rivolte - in ordine crescente di dettaglio – alla visualizzazione ottimale dei dati raccolti, alla loro investiga-zione statistica, alla costruzione di modelli di interrogazione ritenuti almeno parzialmente utili ad avvicinare una risposta alla istanza formulata dall’utente.

E. La funzione di protezione dei dati – intesa come sia conserva-zione dei medesimi, sia riservatezza dell’accesso, da mantenere

circoscritto ai soli aventi diritto – deve essere messa in pratica alla luce della pertinente parte della analisi dei rischi, originati dal versante informatico o che comunque lo tocchino.

Di conseguenza:

F. L’analisi dei rischi originati dal versante clinico deve essere guida-ta sostanzialmente dai clinici.

2.2 Classificazioni orientate all’informatica

2.2.1“Locale” rispetto “a distanza”

I database dei medici di famiglia sono l’esempio base di database locali: essi sono localmente compilati e localmente utilizzati. Non è un problema che il medico di famiglia usi un computer notebook, in modo tale da poter operare anche in casa del paziente, vogliamo solo dire che non esiste la necessità di un’infrastruttura di comuni-cazione: ogni cosa è dentro, in quella singola macchina.

I database per il trapianto di organi sono l’opposto, essi non sono per niente locali: solitamente il database è fisicamente allocato nel sito principale del servizio di gestione dei trapianti. La parte di database dei “candidati riceventi” è compilata a distanza, dai dipartimenti ap-partenenti a differenti ospedali, solitamente senza rilevanti necessità di tempo reale. La parte di database dei “candidati donatori” è com-pilata anch’essa a distanza: anche se arrivati tramite un dipartimento ospedaliero, la loro origine può essere quell’ambulanza che ancora sta prestando soccorso sul luogo di un incidente in autostrada. Le ne-cessità di tempo reale sono molto elevate. Nulla vieta che nelle infra-strutture di comunicazione coinvolte ve ne siano di non proprietarie a patto che i nostri dati possano far uso di canali prioritari.

2.2.2 “Dati” rispetto “segnali e immagini”

Sappiamo che una classica cartella clinica è un raccoglitore di do-cumenti cartacei come pure di altre informazioni residenti su dif-ferenti supporti, quali per esempio pellicole fotografiche. Tracciati di bio-segnali (come elettrocardiogrammi, elettroencefalogrammi, ecc.) e bio-immagini (come grandi radiografie del torace o le picco-le radiografie di una mano, fotografie da ecografie a un seno o dal cuore, immagini di risonanza magnetica, immagini di tomografie a emissione di positroni), sono comunemente presenti nel raccoglito-

re “cartella clinica”. Osserviamo che, se il medico possiede la cono-scenza necessaria per comprendere gli specifici e differenti contenuti informativi presenti nelle immagini, tale varietà di supporti non gli causa alcun problema. Poiché umano, egli mostra la stessa natura-lezza nel consultare bio-dati, bio-segnali e bio-immagini indifferen-temente tra loro: questo è normale per il nostro senso della vista. Ma, sfortunatamente, nulla di tal genere è ancora successo a un computer: nel dire così non ci riferiamo alla caratteristica dei dati di essere digitali. Questo è tecnologicamente naturale per qualsiasi computer. Vogliamo dire che per qualunque tipo di informazione – bio-dati, bio-segnali e bio-immagini – arriverà tranquillamente il momento di finire in bit. Ciò non costituisce problema. Le diffi-coltà provengono dalle differenze relative ai passi intermedi richie-sti per convertire ciascun tipo di informazione in cifre binarie. Per spiegare le maggiori differenze, sia osservato che i bio-dati entrano in un computer via tastiera. Questo accade per gli esempi di: un nome di malattia, il valore numero della frequenza cardiaca. Per conver-tire questi in cifre binarie, dobbiamo aver risposto alla domanda “Quanti bit sono necessari per codificare il numero di caratteri pre-senti nel nostro alfabeto?”. Ecco quanto c’è bisogno sapere. Bio-dati riguardano caratteri e numeri; ma per bio-segnali e bio-immagini – come pure per segnali e immagini – no. Bio-segnali e bio-immagini entrano in un computer via scanner. Questo accade per gli esempi di: una mammografia e un’ecografia fetale. Per convertire queste figure in digitale, dobbiamo aver risposto alle domande “Per non perdere dettagli, quanti punti per pollice (dpi – “dot per inch”) il mio scan-ner dovrebbe avere? E, per non perdere in precisione, quanti diffe-renti tonalità e livelli di colore dovrei essere in grado di codificare per ciascun di quei punti?”. I punti per pollice e il numero di colori definiscono le prestazioni base di qualsiasi scanner. Per di più, quan-do il punto non è un cerchio, la quantità punti per pollice di uno scanner dovrebbe essere indicata più di una volta. Per i bio-segnali, è vero che quando, per esempio, un elettrocardiogramma è disegnato su un foglio di carta millimetrata, può essere visto come un’immagi-ne. Tuttavia i bio-segnali entrano in un computer attraverso un dispo-sitivo di conversione analogico-digitale. Per convertire questi segnali in digitale, dobbiamo aver risposto alle domande “Per non perdere dettagli, quante volte al secondo dovrei leggere, cioè campionare, il segnale? E, per non perdere in precisione, quanti differenti livelli di valori dovrei avere disponibili per codificare le ampiezze di ciascun campione senza cadere in approssimazioni intollerabili? La frequen-za di campionamento e i livelli di quantizzazione definiscono le pre-stazioni base di qualsiasi convertitore analogico-digitale. Per di più,

quando canali di ingresso multipli possono essere impiegati, quanto contemporanei possono essere i campioni provenienti da differenti canali è pure un’importante caratteristica di qualità.

2.2.3 “Codici” e “linguaggi”

“Più codifichiamo quanto memorizziamo in un database, più fa-cile sarà interrogarlo” è una frase con la quale si è facilmente d’ac-cordo. Tuttavia maschera problemi. Vogliamo dire che una lettura superficiale della frase può tranquillamente invitare verso sistemi di codifica molto semplici. Dobbiamo tenere in mente che, se fac-ciamo così, accettiamo di andare incontro soltanto a interrogazioni di tipo semplice. Generalmente questo non è ciò che vogliono gli utenti. Sfortunatamente solitamente accade che le aspettative degli utenti di database – in Medicina e Sanità come pure in altri cam-pi – non sono soddisfatte dal formulare interrogazioni soltanto di tipo semplice. Per di più, se noi andiamo verso sistemi di codifica troppo semplici, la loro granularità può essere non sufficiente per il grado di realtà che vogliamo conservare. Ad esempio, nel dire “infiammazione dell’occhio”, usualmente vogliamo conoscere quale è l’occhio coinvolto. Una frase migliore e usualmente più accettata è questa: “Più ampiamente codifichiamo quanto vogliamo memo-rizzare in un database, più efficacemente lo interrogheremo”. Ma anche questa frase maschera problemi. Vogliamo dire che alcuni notevoli sistemi di codifica sono certamente disponibili. Unified Medical Language System (UMLS) [USNLM, 1999], Systemati-zed Nomenclature of Medicine – Clinical Term (SNOMED-CT) [IHTSDO, 2007], International Classification of Diseases (ICD-9, ICD-10) [NCHS, 2000] sono i maggiori esempi di codici ampia-mente estesi. Purtroppo essi sono così ampi al punto da non essere usati nella pratica clinica giornaliera di un reparto. Questo fatto è di certo sbagliato in assoluto. Purtroppo però ha una sua utilità. Vale a dire che, in quanto dobbiamo sempre fare i conti col desiderio di ridurre la ricchezza del nostro linguaggio a favore della maggio-re efficacia e immediatezza di comprensione dell’uditorio che im-mediatamente ci circonda e al quale ci rivolgiamo, l’ampiezza e la precisione del linguaggio usato a livello di un dipartimento clinico inevitabilmente finirà per essere più piccola di quella del linguaggio che usiamo nello scrivere un articolo da sottomettere ad una rivista scientifica internazionale.

2.3 Dati e DBMS

I database per la Medicina e la Sanità servono per permettere che le informazioni mediche e sanitarie siano archiviate efficacemente in modo tale da supportare le necessità dei parecchi differenti utenti di quelle informazioni. I database dovrebbero anche aiutare gli utenti nell’individuare, visualizzare ed elaborare ciò a cui sono interessati. Per compiere il loro lavoro adeguatamente, i database per la medi-cina e la sanità dovrebbero includere operazioni di memorizzazione, integrazione, visualizzazione e gestione di informazioni mediche, fino al più piccolo livello dei loro dati atomici. Essi dovrebbero an-che includere prestazioni per sicurezza e riservatezza [Reni, et al., 2004]. Per ultimo, ma non ultimo in importanza, essi dovrebbero essere costruiti – anche cooperativamente – e usati – principalmente individualmente – a distanza. Per di più ogni cosa dovrebbe essere fatta “on time”. Questo è essenziale nonostante “on time” non è facile da quantificare. Differenti utenti potrebbero richiedere dif-ferenti numeri. Per di più questi numeri potrebbero evolvere nel tempo.

Il ricco insieme di caratteristiche illustrato permette di individua-re le funzioni – potenti e flessibili – delle quali i database devono essere dotati, se si vuole che essi siano avvertiti dai loro utenti come pienamente utili per servire la Medicina e la Sanità. Tuttavia oggi-giorno un insieme di tal genere non può essere considerato come facile da allestire. La ragione è che, nella sua interezza, esso è ancora al di sopra delle prestazioni di base, delle tecnologie e dei meto-di disponibili per i database. Non di meno questo non significa che i database non possano fare nulla di utile in Medicina e Sanità. In accordo con il desiderio di ottenere ritorni sulla base del breve periodo, la politica di implementare un sottoinsieme di caratteri-stiche, che sono di interesse a pochi profili utente alla volta, usual-mente conduce a risultati soddisfacenti. Nel fare ciò, noi accettiamo di andare a prendere specifiche soluzioni, magari di portata limitata, ma sostenibili e utili subito. Molti esempi provano che questo è un approccio di ampio successo [Cristiani, et al., 1996].

Come cittadini, quando richiediamo al nostro programma assi-curativo nazionale sanitario che il badge possa essere mostrato ogni volta che richiediamo assistenza medica, si usa un database. Esso non consente di gestire le bioimmagini, ma funziona bene nell’am-ministrare i diritti sanitari della popolazione.

Come pazienti, quando vediamo il nostro medico di famiglia re-cuperare i nostri pregressi dati sanitari, egli usa un database. Proba-bilmente non sarà in grado di comparare dati simili di differenti pa-

zienti, ma funziona bene nel recuperare i nostri propri dati medici. Come medici lavorando in un reparto ospedaliero, quando fac-

ciamo paragoni tra i dati medici dei pazienti affetti dalla stessa ma-lattia, un database ci sta aiutando. Probabilmente non fa nulla per permetterci di comprendere qualcosa circa i costi delle cure som-ministrate ai pazienti, ma funziona bene nel servire i nostri scopi di confronti clinici.

Come amministratori ospedalieri espletando funzioni complesse di controllo del budget, sicuramente usiamo un database. Esso non farà nulla per aiutarci nell’analisi in tempo reale dei segni vitali di un paziente allettato nell’unità di terapia intensiva, ma funziona bene nell’aiutarci a mantenere in piedi il budget dell’ospedale.

Come ricercatori che lavorano nel campo della bioinformatica, usiamo dati che frequentemente provengono da parecchi differenti database [Masseroli, et al., 2004]. Parlando in generale, essi non forniscono quasi nulla di pronto per essere integrati con i dati del paziente ora raccolti nella sua cartella clinica, ma essi funzionano bene per permettere l’investigazione delle ipotesi di ricerca scelte.

2.3.1 I modelli di basi di dati

Gerarchico, reticolare, relazionale e orientato agli oggetti sono i maggiori modelli nel campo dei database. Ciascuno di essi ha ap-plicazioni elettive nell’ampio campo della Medicina e Sanità. Poi-ché i database gerarchici [Elmasri e Navathe, 1994a] sono efficaci in quelle applicazioni dove c’è un solo punto di vista dominante, essi sono adeguati per i medici di famiglia quando gestiscono eventi minori. Questi sono quelli dove i membri della famiglia soffrono di un solo problema sanitario alla volta. Qualsiasi nuovo problema è nettamente posteriore ai precedenti e del tutto indipendente da essi. Quando un problema si presenta, il membro della famiglia è visi-tato dal medico. Il problema viene identificato. Test di laboratorio sono solitamente prescritti, farmaci sono anche prescritti, qualche volta anche prima dell’arrivo dei risultati dei test di laboratorio. Per tutta la durata del problema, il paziente può essere visitato più volte e la terapia può essere modificata secondo necessità, ma il problema arriva ad una fine. Il prossimo problema sanitario, se si verifiche-rà, può essere assunto ampiamente indipendente dal precedente: per l’organizzazione del database, la sorgente gerarchica primaria è il nome del medico di famiglia (Figura 2.1). Un livello sotto c’è il nome del paziente. Più sotto, al secondo livello, c’è il nome dell’evento. Questo può essere “infiammazione dell’occhio”. Al ter-zo livello ci sono le visite effettuate per quel problema. Al quarto

livello troviamo le prescrizioni farmacologiche e le raccomandazioni di comportamento per il paziente. La gerarchia implica che qualsia-si prescrizione dovrebbe essere interpretata appartenente solamente a quella visita, a quell’evento, a quel paziente. Un secondo esempio medico di chiara gerarchia è relativo alla sezione anamnesi familiare di una cartella clinica. Probabilmente nulla è più gerarchico di un albero genealogico, ma, sfortunatamente, tutti gli altri paragrafi di una cartella clinica ospedaliera non mostrano nulla di così gerar-chico come l’anamnesi familiare. La prospettiva di usare differenti database per specifici capitoli di un documento non è attuabile nella pratica dei software applicativi di uso comune.

I database reticolari [Elmasri e Navathe, 1994b], basati sul mo-dello reticolare dei dati, sono adeguati per i casi dove ci sono parec-chi punti di vista – cioè parecchi profili utente – e nessuno di essi è tale da essere considerato ampiamente dominante (Figura 2.2).

Il seguente insieme di coppie di interrogazioni riassume cosa vo-gliamo dire. Tutti i farmaci assunti da un paziente. Tutti i pazienti che hanno assunto un farmaco specifico. Tutti i dipartimenti pre-senti in un ospedale. Tutti gli ospedali aventi uno specificato di-partimento clinico. Tutti i pazienti curati da uno specifico medi-co. Tutti i medici curanti specifici pazienti. E così via. Di fronte a esempi come questi, è facile ammettere che non c’è un punto di vista dominante, cioè non c’è gerarchia. L’idea di database reticolare è più adatta a queste condizioni. Tuttavia anche i database retico-lari hanno debolezze: queste originano dal fatto che, a qualunque stadio, essi trattano con la sola totalità di tutti i dati che devono essere investigati dalle interrogazioni. Questo è vero anche quando tutte tali interrogazioni appartengono a uno specifico sottoinsieme applicativo, dove una grande parte dei dati memorizzati non sarà

Infiammazione all’occhio

Farmaco 2 Farmaco 1 Farmaco 4 Farmaco 3

Emicrania

30-10-2000 05-05-2000 10-02-2002

Mario Rossi

20-02-2002

Giuseppe Bianchi, MMG

Adele Rossi

raccomandazioni

comportamentali

Paola Rossi

…. ….

raccomandazioni

comportamentali

Emicrania

30-10-2000 05-05-2000 10-02-2002

Mario Rossi

20-02-2002

Adele Rossi

raccomandazioni

comportamentali

Paola Rossi

…. ….

raccomandazioni

comportamentali

Emicrania

30-10-2000 05-05-2000 10-02-2002

Mario Rossi

20-02-2002

Adele Rossi

raccomandazioni

comportamentali

Paola Rossi

…. ….

raccomandazioni

comportamentali

Emicrania

30-10-2000 05-05-2000 10-02-2002

Mario Rossi

20-02-2002

Adele Rossi

raccomandazioni

comportamentali

Paola Rossi

…. ….

raccomandazioni

comportamentali

Emicrania

30-10-2000 05-05-2000 10-02-2002

Mario Rossi

20-02-2002

Adele Rossi

raccomandazioni

comportamentali

Paola Rossi

…. ….

raccomandazioni

comportamentali

05-05-2000 30-10-2000

Raccomandazioni comportamentali

Farmaco 2Farmaco 1

Emicrania

20-02-200210-02-2002

Raccomandazioni comportamentali

Farmaco 4Farmaco 3

Paola Rossi Mario Rossi Adele Rossi

... ...

Figura 2.1Esempio di albero delle

occorrenze per una base di dati progettata con

il modello gerarchico. Il tipo di record Paziente_

Cognome_Nome, che assume il valore “Mario Rossi”, è parent per gli altri record sottostanti:

il tipo di record Diagnosi, che assume

valori “Infiammazione all’occhio” e

“Emicrania”, è record child. La relazione

tra essi (Parent-Child Relatioship) è, nell’esempio, di 1:2;

infatti, un unico record padre di tipo Cognome_Nome è in relazione con due record figlio di tipo

Diagnosi

mai considerata oggetto di analisi. I dati amministrativi sono un esempio: essi non saranno mai di interesse in un’interrogazione cli-nica. Un secondo esempio è l’intero insieme dei dati identificativi, compresi quelli che potrebbero variare, come l’indirizzo civico e il numero telefonico. Principalmente questi ultimi dati sono necessari solo per inviare lettere ai domicili dei pazienti. Non sono necessari per rispondere alle interrogazioni cliniche.

La sottolineata debolezza dell’interezza è risolta dai database re-lazionali [Elmasri e Navathe, 1994c]. Essi possono essere visti pro-venire da un’ingegnosa segmentazione dei database reticolari. Le relazioni sono il risultato della segmentazione. Essenzialmente una relazione è una semplice tabella con righe e colonne: le colonne servono per gli attributi che descrivono propriamente a che cosa ser-vano le relazioni. Uno degli attributi, quello utilmente dominante, viene considerato come chiave (Figura 2.3).

In una cartella clinica, tipicamente le relazioni sono usate per i dati identificativi, per l’anamnesi familiare, per l’anamnesi patolo-gica remota, per l’anamnesi patologica recente, eccetera. Nel fare questo, in ogni relazione un attributo chiave adatto può essere il codice che l’ospedale dà al paziente per quel ricovero. Le righe delle relazioni sono riempite con valori specifici di attributi, proprio per quei casi che stiamo considerando: generalmente l’insieme dei va-

IUGERI 16303PININI 67109 MARINI 42793PAZIENTI

67109 G726 W84 B 67109 G912 W84 C 42793 E504 W84 A 42793 G726 583 C 16303 E796 W84 B 16303 G912 W84 B

PAZIENTI - RISULTATI TERAPIE

RISULTATI TERAPIE

TERAPIE

TERAPIE - RISULTATI TERAPIE

REPARTI

REPARTI - TERAPIE

CARDIOLOGIA MEDICINA

G726 FARM1 5 G912 FARM2 4 E504 FARM3 4 E796 FARM4 4

Figura 2.2Istanza di Database Reticolare che mostra i Reparti, le Terapie, i Pazienti e i Risultati delle terapie assegnate ai pazienti. I punti di vista sono i Reparti, le Terapie e i Pazienti. (FARM indica “farmaco”)

Figura 2.3Esempio di tabella nel modello relazionale. La prima riga della tabella, racchiusa in una doppia cornice, illustra lo schema della relazione, attraverso l’indicazione del nome della relazione (PAZIENTE) e dei nomi degli attributi (Codice_sanitario, Cognome, Nome, Data_visita, Terapia). Le righe sottostanti formano l’istanza della relazione

PAZIENTE Codice_sanitario Cognome Nome Data_visita Terapia000ZZ000 Bianchi Antonio 12-03-2003 Paracetamolo111AA222 Neri Adele 14-10-2004 Baclofene000EE999 Rossi Mario 23-09-2001 Acemetacina123XX456 Verdi Anna 11-05-2002 Lansoprazolo

lori presenti in una riga è chiamato tupla. Segmentare un database non dovrebbe portare verso relazioni troppo piccole, infatti più le relazioni sono piccole più alta è la loro numerosità, e più alti di-venteranno il tempo di interrogazione e la complessità. Anche se l’azione di interrogare i database relazionali trae vantaggio dall’al-gebra relazionale, adeguatamente definita e potente, il tempo di in-terrogazione può diventare significativamente importante. Anche la complessità da gestire può richiedere troppo lavoro di programma-zione. Tuttavia, ogni volta che il tempo di calcolo non è importante, i database relazionali di solito forniscono la flessibilità desiderata per l’interrogazione dei contenuti del database. Spesso ciò avviene dal largo uso dello Structured Query Language (SQL) [Elmasri e Na-vathe, 1994d]. Ciò che i database relazionali forniscono nella loro essenza va lungo due linee principali: la prima è l’incremento del livello di dettaglio, la seconda è la potenza degli strumenti di inter-rogazione che abbiamo a disposizione. Senza dubbio i database re-lazionali sono i più usati. Tuttavia, per molte applicazioni mediche e sanitarie, anche i database relazionali mostrano grosse debolezze. Per esempio essi non integrano facilmente dati e immagini. Ciò si-gnifica che diventa molto difficile considerare un’immagine soltan-to come il valore di un attributo, da essere scritto nell’appropriata cella di una tabella relazionale. In aggiunta, i database relazionali non fanno facilmente fronte alla gestione degli attributi multiva-lore – come noi necessitiamo per riempire la colonna dell’attributo “Fattori di rischio” per pazienti che sono affetti, per esempio, sia da obesità che da alcolismo. Il tecnicismo dell’aggiungere righe a una tabella relazionale – per includere uno soltanto dei fattori di rischio multipli in una cella alla volta – è una possibilità critica. Vale a dire che, dal punto vista clinico, quando i pazienti possiedono contem-poraneamente due fattori di rischio, il loro stato è intuitivamente e di solito più grave.

Le Basi di dati orientate agli oggetti [Kim, 1995] derivano da un coraggioso tentativo e dalla speranza di proporre una nuova visione per risolvere il problema di gestire i dati efficacemente. Noi inizia-mo da un alto livello di generalità. Infatti nel rispetto verso parole come gerarchico, reticolare, relazionale, la parola oggetti suona più generale. Apparentemente ciò suona anche più debole e più gene-rico rispetto al bisogno di permettere descrizioni dettagliate. Un oggetto può essere qualunque cosa. Tante cose, molto differenti tra loro, possono essere chiamate oggetti. Ma questa parola comporta il potere di dare rilevanza a identità complete, potenti, e conosciute. Ad esempio si pensi al numero di serie che identifica e distingue ciascuno degli esemplari tutti tra loro uguali di una produzione in-

LMI_A_Coronaro_image

LMI_A_Ventr_image

LMI_A_Risk_factor

LMI_A_Sten_to_img

LMI_A_Demographic

LMI_A_Report

LMI_A_Stenosis

LMI_set

LMI_A_Angio_exam

LMI_A_Ventro_exam

LMI_A_Coronaro_exam

LMI_object

LMI_A_Person

LMI_A_Patient

LMI_A_Diagnosis

LMI_A_AngiovisitLMI_A_Therapy

LMI_t_objectLMI_A_interval

LMI_t_o_set

LMI_A_clinical_history_view

LMI_view_object

LMI_view_manager

LMI_view_descriptor

LMI_view_extent_manager

is defined onMaterialization relationship

Figura 2.4Un diagramma delle classi di Booch [Booch, 1994] semplificato che illustra la struttura del database clinico. Ogni blocco deve essere pensato come una “nuvola”, denominata in gergo “amorphous blob”, che rappresenta una classe. Il nome della classe è scritto all’interno del blob. Le classi aventi un nome che inizia per “LMI” sono tipiche del modello di dati; le classi aventi il nome che inizia per “LMI_A_” appartengono all’applicazione ARCADIA [Pinciroli, et al., 1995]. I blob punteggiati rappresentano le classi del modello dei dati introdotti per supportare la definizione delle viste.

L’oggetto-vista “LMI_A_clinical_history_view” è rappresentato con un blob ombreggiato, come tutte le classi di ARCADIA interessate da questa particolare vista. Le linee terminanti con un pallino pieno (nero) indicano relazioni di HAS_A (appartenenza), ove il pallino è posto accanto alla classe soggetto della relazione; le linee terminanti con un pallino vuoto (bianco) indicano relazioni di USES (uso), ove il pallino è posto accanto alla classe soggetto della relazione. Le linee terminate da una freccia indicano una relazione IS_A (ereditarietà), ove la freccia punta alla classe dalla quale si eredita, cioè la superclasse. I

numeri vicino alle linee indicano la cardinalità delle relazioni. La classe “LMI_view_manager”, composta da un descrittore di vista (classe “LMI_view_descriptor”) e da un insieme di metodi e trigger (classe “LMI_view_extent_manager”), è connessa da una relazione vista-materializzazione con la classe “LMI_view_object”. La classe “LMI_A_patient”, sulla quale è definita la vista “LMI_A_clinical_history_view”, è collegata ad essa mediante una relazione “view-definition”. [Portoni, et al., 1998].La figura avente la notazione di Booch è disponibile online nella raccolta di iconografia di sanità digitale.

dustriale. Frequentemente le identità contengono altre identità, più piccole, e questo succede a un livello spesso implicito. Per esempio, quando in una conversazione generica diciamo: “È diabetico”, in-tendiamo dire che: “Egli è una persona malata a causa del diabete”. Noi intendiamo questo senza il bisogno di dirlo esplicitamente. Succede che l’oggetto “Diabetico” eredita le proprietà dell’oggetto “Paziente”, e questo eredita le proprietà dell’oggetto “Persona” (Fi-gura 2.4).

Rimane vero che oggetto è un termine abbastanza generico, ma noi usiamo la sua positiva flessibilità di significati, dato che abbiamo – ge-neralmente implicita – la conoscenza di ciò che un’identità assegnata significa nel nostro ambiente. Stando nella parte delle tecnicità infor-matiche, noi diciamo che un oggetto include sia l’insieme dei suoi dati adeguatamente definiti, sia i relativi metodi per la gestione dei dati stessi. I metodi di base sono quelli richiesti per l’inserimento dei dati, memorizzazione, relazioni, interrogazione, salvataggio, in-dividuazione, integrazione, eccetera. In aggiunta all’ereditarietà, al-tre proprietà frequentemente menzionate dei database orientati agli oggetti, sono l’incapsulamento (per nascondere la struttura dei dati verso l’esterno), sovradefinizione (overriding, overloading), risoluzio-ne dei legami posticipata (late binding) – cioè in fase di esecuzione vengono risolti i nomi dei metodi, e i tipi delle variabili, che devono agire – persistenza (mantenere gli oggetti nel tempo anche dopo il termine dell’esecuzione di un programma), concorrenza (differenti procedure agiscono contemporaneamente sugli stessi dati) e altre ancora.

Il ciclo di vita di un database è un processo complesso, solitamen-te composto dalle seguenti fasi principali: 1. Raccolta e analisi dei requisiti2. Progettazione concettuale del database3. Scelta di un adeguato Data Base Management System4. Progettazione logica del database5. Progettazione fisica del database6. Implementazione del database7. Uso e manutenzionePer la fase di progettazione concettuale di un database, il modello concettuale maggiormente diffuso è quello Entità-Relazione (Enti-ty-Relationship model, E-R) (Figura 2.5).

2.3.2 Ritorni all’utente

Classi di interrogazione:Per parole chiave: durante l’ultimo decennio alla maggior parte di

noi è diventato familiare compiere ricerche in Internet mediante l’uso di parole-chiave – per lo più impiegate una alla volta - e motori di ricerca. Se, in un dato ospedale, vogliamo elencare tutte le car-telle cliniche dove quelle parole-chiave sono contenute, il metodo ha successo. Esempi pratici sono elencati di seguito: tutti i pazienti che hanno ricevuto uno specifico farmaco; tutti i farmaci presi da uno specifico paziente; tutti i medici in carico ad uno specifico di-partimento; e così via. In aggiunta, se, nel compiere una ricerca nel-la letteratura medica, probabilmente usando PubMed [US NLM, 1996a], vogliamo avere elencati tutti gli articoli di rivista dove la parola-chiave è presente – potrebbe essere solamente nell’abstract,

Nome dell’istanza

Categoria dell’istanza

Nome del File Dati

Nome File Ausiliari

Valori di Default

Descrizione

Coordinate di Visualizz.

Nome/Descrizione

Numero dei Livelli Gerarchici

Condiziona

Caratteristica del File Dati

Caratteristica della Categoria

Può essere completata

Caratteristica del Dato

Caratteristica del Vocabolario

Consiste di

Può essere legato

File Dati

Istanza di Categoria

Vocabolario Dati

Contiene

Indica

Definisce

Figura 2.5Il modello E-R della struttura del database, per il software multiservizio per la medicina MS/2 Cardio [Pinciroli, et al., 1998], implementato per configurabilità. Le entità sulla destra contengono i dati raccolti dai pazienti, quelle sulla sinistra definiscono la struttura e le caratteristiche delle entità sulla destra. Le entità sono collegate verticalmente da relazioni “made-of” e le relazioni tra le entità sulla sinistra e quelle sulla destra possono essere definite come “relazioni di configurazione”.

Simbologia per il modello Entità-RelazioneUn’entità può rappresentare ciascun oggetto o aspetto del mondo reale avente un’esistenza indipendente. Ciascuna delle entità ha particolari proprietà, rappresentate dagli attributi dell’entità stessa. Fra le entità possono esistere delle relazioni e queste relazioni possono avere propri attributi. Un tipo di relazione raccoglie relazioni del medesimo tipo ed è descritta da un nome, dai loro attributi e da una cardinalità, cioè il numero di istanze di relazione a cui un’entità può partecipare. È possibile distinguere in relazioni “molti a molti”, “uno a molti” e “uno a uno”

= Attributo

= Relazione uno a uno

= Entità

= Relazione uno a molti

= Attributo

= Relazione uno a uno

= Entità

= Relazione uno a molti

potrebbe essere all’interno del testo dell’articolo – il metodo ha suc-cesso ancora. Certamente, la lista di risultati includerà anche quei pazienti (o quegli articoli di rivista) dove quella parola-chiave è pre-ceduta da “assenza di” o è seguita da “non presente”. Ma, quando interroghiamo un database ospedaliero, non vogliamo che questo succeda. Vogliamo una più elevata efficacia. Tuttavia, dobbiamo ammettere che il programma di interrogazione è molto semplice ma anche ammettere che alcuni rischi di malinteso sono indesiderati. Per intervallo: in Medicina, per la maggior parte delle quantità mi-surabili, la conoscenza acquisita nel passato ci consente di definire intervalli di normalità. Di fronte al risultato di un test di laboratorio per un dato paziente, vogliamo conoscere se il risultato è normale (fisiologico) oppure no. Per effettuare un’interrogazione di questo tipo anche l’organizzazione dei dati consentita da un foglio di cal-colo elettronico può generalmente essere sufficiente. Interrogazioni un poco più complesse sono del tipo: “Vogliamo conoscere se il paziente ha avuto febbre mentre era ricoverato in ospedale”. Una più alta complessità hanno le interrogazioni come: “Selezionare i pazienti che, dopo aver preso un certo farmaco in una certa quan-tità, hanno avuto il trattamento con quel farmaco interrotto per effetti collaterali indesiderati, e dopo minimo cinque giorni il perio-do di wash-out, il paziente è passato al trattamento con questo altro farmaco, e ciò fu fatto senza avere che il paziente mostrasse alcun effetto collaterale per un minimo di trattamento lungo tre mesi con il nuovo farmaco, a medio o più alto dosaggio”.

Per concetti: nel fare un’interrogazione, “cardiopatia” può essere giu-sto una parola-chiave. Un risultato può essere il numero di volte in cui questa parola è presente nel testo. Ma noi possiamo usare “car-diopatie” per interrogare qualcosa d’altro. Vogliamo dire che possia-mo cercare la lista di nomi specifici di tutte le patologie cardiache. L’operatività di fare ciò è lontana dal contare quante volte una paro-la appare in un dato testo. Ora l’operatività inizia con il cercare un dizionario medico: frequentemente sarà un dizionario strutturato. Un possibile esempio può essere la parte di terminologia del Uni-fied Medical Language System (UMLS). Poi il dizionario dovrebbe essere consultato. La consultazione deve essere fatta in accordo con i criteri di strutturazione del dizionario. Tutti nomi delle cardiopa-tie dovrebbero essere elencati, e i sinonimi dovrebbero essere pro-priamente trattati. I risultati dovrebbero accordarsi con anche con i livelli di granularità richiesti dall’utente. Una ricerca come quella appena descritta è spesso detta “un’interrogazione per concetti”.

Interrogazioni semantiche per database di bio-immagini: il Visible Human Dataset (VHD) [US NLM, 1996b] è una collezione di immagini da sezioni orizzontali esaustive di due corpi umani, uno maschile e uno femminile. Il corpo dell’uomo è stato sezionato una volta ogni millimetro. Questo ha portato alla serie di 1870 fotogra-fie digitali. Il corpo della donna, sezionato tre volte per ogni milli-metro, ha portato alla serie di 5.100 fotografie digitali. Fotografie in tali quantità non sono adeguate per essere gestite manualmente. Interrogazioni come: “Per le immagini provenienti da tutte le se-zioni dove il fegato è presente, dammi tutti i dati relativi al solo fegato”, dovrebbero essere considerate interrogazioni assai naturali anche dalle matricole universitarie. Ma l’architettura software per effettuare una tale interrogazione è molto peculiare. La visualiz-zazione seriale dei file grezzi contenenti le immagini del VHD, la selezione di quelle di loro dove il fegato è presente, il contorna-mento del fegato su ciascuna delle immagini selezionate, la valida-zione dell’azione di contornamento, il salvataggio dei dati originali del VHD appartenenti al contorno, la loro memorizzazione in un nuovo database, chiamato “fegato VHD”, la scelta di un corpus di conoscenza anatomica (per esempio il tesauro del Unified Medical Language System) e parecchi altri aspetti da curare: tutti questi sono tra i maggiori passi da compiere con qualsiasi sistema che esegua interrogazioni semantiche di database di bio-immagini [Cerveri e Pinciroli, 2001].

Bibliografia

Paragrafo 2.2International Health Terminology Standards Development Organi-

sation. SNOMED CT (Systematized Nomenclature of Medi-cine-Clinical Terms) [online] 2007. http://www.ihtsdo.org/our-standards/snomed-ct/ Ultimo accesso: 12 maggio 2008

National Center for Health Statistics. International Classification of Diseases, Ninth Revision, Clinical Modification (ICD-9-CM) [online] 2000. Disponibile all’indirizzo URL: http://www.cdc.gov/nchs/about/otheract/icd9/abticd9.htm Ultimo accesso: 12 maggio 2008

US National Library of Medicine. Unified Medical Language System (UMLS) [online] 1999. Disponibile all’indirizzo: URL:http://www.nlm.nih.gov/research/umls/ Ultimo accesso: 12 maggio 2008

Paragrafo 2.3Booch G. Object-oriented Design with applications. Red Wood

City, CA, USA: The Benjamin Cummings Publishing Company; 1994.

Cerveri P, Pinciroli F. Symbolic representation of anatomical knowledge: concept classification and development strategies. J Biomed Inform. 2001;34(5):321-47.

Cristiani P, Pinciroli F, Stefanelli M., editors. I Sistemi Informativi Sanitari. Bologna, IT: Pàtron Editore; 1996. p. 239-300.

Elmasri R, Navathe SB. Fundamentals of Database Systems. 2nd ed. Redwood City, CA; Benjamin/Cummings Publishing Company: 1994. pp 343-349.

Kim W, editor. Modern Database Systems. The Object Model, In-teroperability, and Beyond. Reading, MA; Addison-Wesley Pub-lishing Company: 1995.

Masseroli M, Stella A, Meani N, Alcalay M, Pinciroli F. My-WEST: my Web Extraction Software Tool for effective min-ing of annotations from web-based databanks. Bioinformatics. 2004;20(18):3326-35.

Pinciroli F, Combi C, Pozzi G. ARCADIA: a system for the integra-tion of angiocardiographic data and images by an object-oriented DBMS. Computers and Biomedical Research. 1995;28(1):5-23.

Pinciroli F, Combi C, Pozzi G. Basi di dati per l’Informatica Medi-ca. Bologna, IT: Pàtron Editore; 1998. p. 196-197.

Portoni L, Combi, C, Violante FF, Pinciroli F. Towards user-views in an OODBMS for PTCA patients. In: Murray A, Arzbaecher R, eds. Computers in Cardiology 1996. Piscataway, NJ: IEEE Comp Soc Press; 1996. p. 357-360.

Reni G, Molteni M, Arlotti S, Pinciroli F. Chief medical officer ac-tions on information security in an Italian rehabilitation centre. Int J Med Inform. 2004;73(3):271-9.

The National Library of Medicine. Entrez-PubMed. [online] 1996. Disponibile all’indirizzo: URL:http://www.ncbi.nlm.nih.gov/entrez/query.fcgi Ultimo accesso: 12 maggio 2008.

The United States National Library of Medicine. The Visible Hu-man Project. [online] 1996. Disponibile all’indirizzo: URL: http://www.nlm.nih.gov/research/visible/visible_human.html Ultimo accesso: 12 maggio 2008.

3 Applicazioni Sanitarie di arnesi informatici generali

3.1 Sistemi cooperativi e sistemi di workflow

3.1.1 I Sistemi Cooperativi

I Sistemi Cooperativi sono software che supportano l’esecuzio-ne coordinata di attività semplici (tasks) eseguite da diversi attori (agents); vengono utilizzati sia per processi di business che produt-tivi. Tra questi i Sistemi di Workgroup sono adatti a piccoli team di professionisti per processi di business mentre i Sistemi di Wor-kflow Management (WfMS) sono adatti a sistemi più complessi e che coinvolgono più attività, come all’interno delle realtà sanitarie. Questi ultimi verranno considerati in maniera più dettagliata sia dal punto di vista strutturale sia per quanto riguarda gli aspetti della modellizzazione.

I Sistemi Cooperativi, definiti anche Computer-Supported Coo-perative Group (CSCW) definiscono:• sequenze e condizioni di realizzazione di un insieme di azioni

da eseguire;• la sincronizzazione delle azioni;• i flussi informativi;• le eccezioni [Casati et al., 1999]I Sistemi Cooperativi sono classificati, seguendo criteri di ripetibilità e prevedibilità delle azioni e in termini di presenza o meno di con-trollo umano (piuttosto che automatizzato) sul processo [Casati et al., 1998], in:• Sistemi Amministrativi: utili per processi burocratici caratte-

rizzati da estrema ripetibilità e prevedibilità, le informazioni sono trasferite e approvate manualmente, i processi non sono critici per la mission aziendale e utilizzano soprattutto servizi email e database.

• Sistemi di Workgroup: utilizzati per processi all’interno di pic-coli gruppi di professionisti in cui non ci sono percorsi pre-definiti per il trasferimento delle informazioni tra gli attori. I processi, inoltre, richiedono l’intervento umano considerando che la sequenza di azioni che si deve eseguire viene decisa dina-micamente con lo svolgimento del processo stesso.

• Sistemi di Workflow: questi vengono utilizzati per processi ri-petibili e prevedibili come quelli produttivi. L’ordinamento e l’esecuzione delle azioni possono essere totalmente o parzial-mente automatizzati, senza che sia richiesto l’intervento uma-no. Processi di questo tipo sono comunque considerati critici per la realizzazione degli obiettivi del processo.

3.1.2 Sistemi di Workgroup e di Workflow a confronto

Per Sistemi di Workgroup il modello è orientato ai flussi di dati e il processo è un contenitore di informazioni che si muovono da una workstation all’altra, seguendo regole locali. La sequenza del-le workstation è definita dinamicamente a seconda delle specifiche del processo, della sua storicità, dei risultati correnti e delle regole. Sono utili per processi solo parzialmente specificati con obiettivi ben definiti.

Le esigenze sono sotto il controllo umano:• istantaneità del processo;• correttezza di esecuzione;• controllo sull’accesso ai dati;• consistenza dei dati;• definizione degli obiettivi;• rilevamento di eventi eccezionali;• scadenze.Per Sistemi di Workflow il modello di esecuzione è basato su una precisa organizzazione e le specifiche di progetto, quindi, vengono lette da un motore di esecuzione (seguendo la programmazione av-venuta in maniera manuale o automatizzata)[Casati e Pozzi, 1999]. Sono utili per processi ripetitivi e orientati all’esecuzione del proces-so stesso (piuttosto che ai dati).

La correttezza del processo alla fine dell’esecuzione dipende da:• lo stato finale raggiunto, che deve appartenere a un set di stati

possibili inizialmente individuati;• la consistenza dei dati;• il raggiungimento degli obiettivi previsti;• l’intervento del gestore delle eccezioni in caso di errori;• il WfMS che deve generare un piano di esecuzione che garan-

tisca la correttezza nell’esecuzione del processo;• il rispetto dei tempi di esecuzione (sia in termini di tempo

assoluti sia relativi).

59Capitolo 3Applicazioni Sanitarie di arnesi informatici generali

3.1.3 Il sistema di Workgroup BSCW (Basic Support for Cooperative Work)

BSCW ovvero Basic Support for Cooperative Work è uno strumen-to multimediale che può essere usato per mettere in comunicazione tra loro i membri di un gruppo di lavoro e per permettere loro di scambiarsi idee e materiali [BSCW, 2008]. I membri che formano il gruppo di lavoro possono sia rendere disponibili i propri documen-ti, sia leggere ciò che gli altri rendono disponibile. In questo senso BSCW è un sistema che permette di lavorare in rete: se oggetto e obiettivo del lavoro del gruppo è sviluppare un determinato pro-getto, questo strumento offre la possibilità di sviluppare lo stesso in modo cooperativo.

Sono possibili due modalità di utilizzo:• accesso asincrono (non simultaneo);

> condivisione di documenti;> interfaccia web;> ricezione e spedizione di messaggi attraverso l’interfaccia web;

• accesso sincrono (simultaneo):> pianificazione, organizzazione;> comunicazioni dirette tra gli utilizzatori attraverso workspace

condivisi.Quindi le strutture hardware e software necessarie per utilizzare BSCW sono:• un computer con modem; • un accesso ad Internet;• un indirizzo di posta elettronica; • un browser (Netscape, Internet Explorer).

3.1.4 Workflow Management System (WfMS)

I Workflow Management System (WfMS) sono applicazioni che gestiscono flussi di lavoro [WfMC, 1999]. Qualsiasi azienda, am-ministrazione pubblica o ente commerciale segue dei protocolli per gestire processi produttivi o amministrativi basati sul passaggio di informazioni o documenti: questi iter possono essere schematizzati come flussi di lavoro a cui si riferiscono i dipendenti e/o gli utenti. Nella gestione tipica di questi flussi di lavoro molte energie vengono spese inutilmente in due ambiti che non portano alcun risultato pratico. Da una parte si deve curare il passaggio del lavoro o dei do-cumenti, perdendo tempo e risorse nel cercare di capire che cosa si debba fare di un certo oggetto o a quale ufficio debba essere manda-to un incartamento. Dall’altra parte molte delle attività svolte sono

ripetitive e automaticamente gestibili da un’applicazione software anziché da un essere umano. I WfMS si propongono di automatiz-zare queste fasi dispendiose e non redditizie dei flussi di lavoro, con l’aiuto delle tecnologie informatiche.

Si definisce, quindi, un Workflow Management System come sistema che definisce, crea e gestisce l’esecuzione di workflow attra-verso l’uso di software, coinvolgendo uno o più motori di workflow e che è in grado di interpretare definizioni di processo, interagire con i partecipanti del workflow e, se richiesto, invocare l’uso di ap-plicazioni e strumenti dell’information technology.

La Workflow Management Coalition (WfMC), un’organizzazio-ne internazionale no-profit fondata nell’agosto del 1993 e costituita da produttori di workflow, utenti, analisti e gruppi di ricerca uni-versitari, è sorta con l’obiettivo principale di promuovere lo svilup-po dell’uso del workflow, stabilendo standard e terminologie comu-ni per consentire la compatibilità e l’interoperabilità tra prodotti eterogenei di workflow. L’interazione fra applicazioni di WfMS di natura diversa è indispensabile poiché ogni situazione richiede uno strumento diverso: lo scopo della WfMC è proprio quello di fornire standard per questa integrazione. Essa inoltre si pone come scopo anche quello di accrescere il valore degli investimenti nelle tecno-logie di workflow, ridurre i rischi legati all’uso dei prodotti di wor-kflow e l’espansione del mercato accrescendo la consapevolezza delle potenzialità del workflow.

Secondo la definizione fornita della Workflow Management Co-alition, col termine workflow si intende “L’automazione di una parte o l’intero processo aziendale dove documenti, informazioni e compiti vengono passati da un partecipante ad un altro per ricevere qualche tipo di azione, seguendo un determinato insieme di regole” [WfMC, 1999]. Dunque un workflow riassume una serie di procedure che, poste in relazione le une con le altre, definiscono un contesto di la-voro strutturato, dove più unità lavorative, siano esse risorse umane, gruppi di lavoro o sistemi computerizzati, lavorano in concomitan-za per un determinato fine. Ogni workflow è dunque composto da un certo numero di processi, cioè procedure da seguire per ottenere un certo risultato da determinate condizioni di partenza, ad es. un iter per una richiesta di acquisto dell’università, o la procedura per ottenere una licenza edilizia nell’ambito della pubblica amministra-zione. Ogni processo viene descritto dall’insieme di attività e dalla sequenza con cui vengono svolte.

I componenti principali di un WfMS sono:• Process model designer: definisce il modello generale del pro-

cesso;

• Process model repository: archivio dei modelli dei processi conservati nel WfMS;

• Engine: programma le attività da eseguire;• Resource executive: assegna agli attori i compiti da eseguire;• Worklist server: fornisce agli attori un interfaccia web;• E-mail feeder e E-mail notofication: invia agli attori messaggi

e documenti;• Audit logger: mantiene gli archivi storici delle attività eseguite.

Architettura concettualeAl di là delle particolarità, tutti i WfMS hanno una serie di ca-ratteristiche comuni che garantiscono una base per l’integrazione e l’interoperabilità (Figura 3.1). Si possono quindi individuare tre macroaree funzionali:• i servizi di supporto alla costruzione, connessi alla definizione e

alla modellazione del processo di workflow e delle attività che lo costituiscono (build-time functions);

• i servizi di controllo della messa in opera, capaci di gestire i pro-cessi di workflow in un ambiente operazionale, seguendo la fase run-time delle varie attività (run-time functions);

• le interazioni tra gli utenti umani e gli strumenti applicativi nel processare i vari passi delle attività (run-time interactions).

L’utilizzo di Sistemi di Workflow è spesso associato a processi di Business Process Reengineering (BPR) cioè valutazione, analisi, modellizzazione e implementazione di processi all’interno di un’or-ganizzazione. La macrofase successiva definisce invece il comporta-mento evolutivo dei processi, interpretandoli con soluzioni software che si occupano della creazione e del controllo delle istanze opera-zionali tramite la schedulazione delle attività e l’invocazione di ap-

Process Instanciation & Control

Interaction with Users & Application Tools

Build Time

Run Time

Business Process Analysis

Applications& IT Tools

Figura 3.1Architettura concettuale di un WfMS. Adattato da [Hollingsworth, 1995]

propriate risorse umane e tecnologiche. L’interazione con tali risorse viene infine gestita nell’ambito della terza macrofase, che si occupa delle soluzioni specifiche per gestire il trasferimento del controllo, l’evoluzione dello stato di processi e attività, il passaggio dei dati, le interfacce.

Architettura fisicaIl supporto fisico allo sviluppo di workflow (Figura 3.2) è garantito dai Workflow Enactment Services (WES), che consistono di uno o più motori capaci di creare, gestire ed eseguirne le istanze. Le applicazioni possono interfacciarsi a tali servizi tramite le Workflow Application Programming Interface (WAPI).

Il motore di workflow. È il componente run-time più importante del sistema di gestione; solitamente è implementato su un server e rice-ve istruzioni dagli altri componenti del sistema. Il suo ruolo princi-pale consiste nello stabilire le priorità dei diversi compiti, porli nel giusto ordine e assegnarli alle risorse. Per poter fare ciò deve essere in grado di interpretare le regole assegnate in fase di definizione del processo. Ciascun motore di workflow presente nel WES provvede alle funzioni di:• interpretazione della definizione del processo;• controllo delle istanze di processo;• navigazione tra le attività di processo, gestendo parallelismo;

sequenzialità, cicli, condizioni, dati e deadline;• sign-on e sign-off degli specifici partecipanti;• identificazione delle interazioni sulle interfacce utenti;• mantenimento e passaggio dei dati connessi al workflow;• chiamata di applicazioni e collegamento a dati esterni;• controllo, amministrazione e verifica degli obiettivi.Le applicazioni esterne. Le interazioni con le risorse esterne al moto-

Process

ApplicationsInvoked

Applications

Interface 1

Interface 2

Interface 4

Interface 3

Interface 5

Workflow API and Interchange Formats

Administration& Monitoring Tools

Enactment Services

Figura 3.2Architettura fisica di un

WfMS. Adattato da

[Hollingsworth, 1995]

re di workflow avvengono attraverso due tipi di interfacce:• client application: interagisce con un worklist handler che or-

ganizza il lavoro di gestione delle risorse, selezionando e facen-do progredire singoli lavori contenuti nella lista;

• invoked application: abilita il workflow engine a intraprendere una particolare attività, in genere priva di interfaccia utente. Nel caso una particolare attività usi strumenti che richiedono interazione con l’utente, essa viene in genere invocata tramite un’interfaccia worklist per garantire maggiore flessibilità nella schedulazione delle operazioni.

Altre interazioni il motore di workflow le avrà con gli strumenti di definizione e con quelli di monitoraggio dei processi. Sarà poi pos-sibile per un WES interagire con analoghe architetture impegnate su altri workflow.

Nel dettaglio, le client application di supporto all’enactment di un workflow offriranno:• Ambiente di modellazione: tool grafici per la definizione del

processo, tramite i quali vengono definiti l’inizio e la fine del processo, le attività intermedie con le relative ramificazioni, le attività che richiedono l’interfacciamento con altre applicazio-ni, le attività manuali. A seconda delle funzionalità del tool grafico, si può disporre di oggetti predefiniti che costituiran-no la rappresentazione grafica del processo (per esempio bot-toni per spostare nodi e collegamenti, nodi per trasferimenti condizionati, nodi di rendez-vous, nodi di sottoprocesso). I tool di definizione possono far parte integrante del sistema di gestione di workflow o esserne separati. In quest’ultimo caso l’interfacciamento col motore di workflow avviene attraverso le WAPI.

• Ambiente di sviluppo: tool per la rappresentazione della mappa dei ruoli e dei gruppi gerarchici o collaborativi, per la defini-zione di dati, parametri e condizioni utilizzati nelle singole attività di un processo o rilevanti per il processo globale e per costruire l’applicazione di workflow, cioè programmi per gesti-re le informazioni che viaggiano attraverso il processo.

• Ambiente per la gestione: tool per il monitoring dei processi at-tivi (controllo dell’avanzamento), per la gestione dei processi e delle attività, per la generazione di statistiche sull’utilizzo delle risorse e sul tempo medio richiesto per completare task.

• Ambiente run-time delle applicazioni client: fornisce quello che l’utente vede quando usa un’applicazione di workflow. Com-prende l’accesso trasparente al Database, alle applicazioni lega-cy, al sistema di gestione documentale (EDM), incluse le com-

ponenti per l’interfaccia della work list dell’utente coinvolto nel processo, e tutti gli oggetti che il motore del workflow ma-nipola. Gli utenti del sistema utilizzano l’applicazione client per interagire col motore di workflow.

• Le interfacce: Le API e gli standard di scambio sviluppati dalla WfMC sono denominati WAPI (Workflow API). Ciascuno dei cinque livelli di interfaccia presenti nell’architettura fisica mette a disposizione delle API tra il motore di workflow e gli altri componenti del sistema.

Il modello WIDEIl modello di workflow maggiormente diffuso è il Modello WIDE – Workflow on an Intelligent and Distributed database Environment. È composto da tre modelli tra loro collegati che garantiscono estre-ma flessibilità nella descrizione dei processi, soprattutto per quanto riguarda le eccezioni.

I tre modelli sono:• modello dell’organizzazione: descrive la struttura organizzati-

va e gli agenti che ne fanno parte;• modello delle informazioni: descrive i dati e i documenti ne-

cessari all’esecuzione di un processo;• modello dei processi: definisce le attività che fanno parte del

processo e l’ordine in cui devono essere eseguite.Un Workflow in WIDE è specificato da un insieme di attività (task) e da connettori che specificano l’ordine in cui i task devono essere eseguiti. Oltre a questi ultimi comprende:• unità di modularizzazione, distribuzione e transazionali: con-

sentono di descrivere i processi a diversi livelli di dettaglio, isolandone alcune parti che debbono essere ritenute unitarie dal punto di vista della distribuzione del lavoro o dal punto di vista transazionale;

• eccezioni: consentono di descrivere in modo compatto alcune situazioni di tipo anomalo che si possono verificare durante l’esecuzione del processo e che richiedono un particolare trat-tamento:- esecuzione di specifiche attività;- aggiornamento di alcuni dati del processo;- alterazione del normale flusso di esecuzione.

Costrutti del modelloGli elementi che vengono utilizzati per la realizzazione di un model-lo sono (Figura 3.3):• Task: sono le attività elementari che compongono un processo.

Inizio/Fine Totale Condizionale Ciclo Join parziale

Trigger

SupertaskSottoprocesso Business transaction

Trigger

Figura 3.3I costrutti del modello

Un Task è caratterizzato da un nome, una descrizione, un in-sieme di ruoli (capacità), un insieme di dati associati e un in-sieme di azioni predefinite.

• Connettori: un task può avere una sola connessione in uscita e una in ingresso.I connettori iniziano l’esecuzione parallela di task (FORK) e sincronizzano i task al termine di esecuzioni parallele (JOIN). In particolare, i FORK preceduti da un task (predecessore) e seguiti da due o più task (successori), sono classificati in:- totale: al termine del predecessore attiva tutti i successori;- condizionale: a ogni successore è associata una condizione.

Vengono attivati i successori la cui condizione è vera.I connettori JOIN, preceduti da due o più task (predecessori) e seguiti da un task (successore), sono classificati in:- totale: il successore viene attivato solo al termine di tutti i

predecessori;- parziale: al connettore join è associato un valore k, il succes-

sore viene attivato non appena k predecessori con lo stesso numero di attivazione sono terminati. La terminazione di ulteriori predecessori non ha nessun effetto. K può essere una costante o una variabile del processo. Per default K=1;

- ciclico: un’istanza del successore viene attivata tutte le volte che un predecessore termina.

• Simboli di inizio e fine processo: ogni workflow ha un simbolo di inizio e uno o più simboli di fine processo. Il simbolo di inizio ha uno o più successori (deve essere seguito da un con-nettore fork). Il simbolo di fine ha uno o più task predecessori (deve essere preceduto da un connettore join).

• Wait task: è un task che non compie azioni e che non deve essere assegnato ed eseguito da un agente, il suo compito è di attendere che una certa condizione si verifichi.

• Multitask: consente di specificare in modo compatto un in-sieme di task che compiono la stessa funzione e consente di definire il numero delle istanze che devono essere attivate, che può dipendere dal valore di una variabile del workflow.

• Sottoprocessi, supertask e business transaction: consentono di modularizzare la specifica di un workflow e di definire proprie-tà transazionali.

3.1.5 Workflow nell’Healthcare

La gestione per processi in sanitàAll’interno delle realtà sanitarie la scelta di orientare la gestione delle

attività a una visione “per processi” è stata dettata, nella sostanza, da due esigenze fondamentali [Lega, 2001]:• il recupero del paziente, e dei problemi di salute dei quali è af-

fetto, al centro dell’attenzione della programmazione, dell’or-ganizzazione e della gestione: si tratta di un orientamento la cui necessità deriva dall’esigenza di valutare l’economicità e l’efficacia delle scelte e della gestione che, solo attraverso una maggiore attenzione alla misurazione dei risultati finali (soddi-sfacimento dei bisogni), assumono significato pieno e coerente con le finalità di sistema;

• il pieno coinvolgimento dei professionisti nella gestione at-traverso l’impiego di informazioni in grado di rappresentare le modalità con le quali gli stessi lavorano e favorendo, in tal modo, il ciclo di miglioramento continuo.

Sul piano operativo, infatti, la gestione per processi, anche alla luce delle esperienze fino a oggi condotte, sembra essere l’unico approc-cio, al momento, in grado di:• supportare la progettazione di un sistema di misurazione dei ri-

sultati orientato sia alla rilevazione degli indispensabili feno-meni economici (costo di gestione), sia di quelli clinico/sani-tari (risultati finali). Potenzialità garantita dalla modificazione dell’oggetto di rilevazione del sistema di misurazione: tradi-zionalmente le informazioni sono strutturate per articolazioni organizzative fornendo, in tal modo, elementi conoscitivi di sintesi rispetto ad aggregati contabili (centri di costo) che, se da un lato assorbono le risorse in modo unitario, dall’altro ge-nerano output molteplici e fra loro eterogenei. Impostazione che, nella sostanza, non consente di comprendere le modalità di formazione dei costi rispetto alle tipologie di servizi e pre-stazioni prodotte e, in ultima analisi, rende assai complesso, se non impossibile, individuare indicatori specifici espressivi del risultato ultimo dell’organizzazione sanitaria. Il sistema or-ganizzato rispetto ai processi, al contrario, identifica gruppi e sottogruppi di pazienti caratterizzati da forti elementi di omo-geneità tra i quali il principale è senza dubbio rappresentato dal problema di salute. In tal modo, a fronte della rilevazione delle risorse impiegate, ora comparabili in termini realmente omogenei, è soprattutto possibile monitorare i risultati non economici conseguiti, utilizzando opportuni parametri clinici e assistenziali, e individuare attraverso quali modalità (proces-so) sono stati conseguiti;

• affinare le capacità predittive, a tutti i livelli di sistema, e sup-portare i processi decisionali focalizzando l’attenzione rispet-

to a specifiche problematiche di salute e rendendo possibile comprendere e stimare gli impatti economici ed organizzativi derivanti dall’esigenza di perseguire obiettivi di salute, dando pieno significato al termine, spesso abusato, di “clinical gover-nance”;

• coinvolgere definitivamente i professionisti nella gestione fornen-do loro strumenti di conoscenza, finalmente focalizzati sugli aspetti realmente gestiti, ossia le modalità di combinazione delle risorse organizzative ed economiche a disposizione per raggiungere specifici risultati di salute rispetto ai pazienti trat-tati, sgomberando il campo da possibili equivoci sul loro ruolo aziendale, rivalutando il sistema di programmazione budgeta-rio e rendendo possibile l’avvio e la realizzazione del ciclo di miglioramento continuo;

• favorire la riprogettazione della struttura organizzativa e del sistema delle responsabilità aziendali in un’ottica dinamica e sempre più coerente con le finalità aziendali (tutelare la salute dei cittadini e/o curare i pazienti), superando progressivamen-te le barriere poste dagli assetti organizzativi tradizionali, ba-sati sul modello divisionale e della specializzazione del lavoro, piuttosto che sulle modalità con le quali si sviluppano i pro-cessi reali, interni.

I Percorsi del PazienteConoscere per valutare e decidere è un assunto fondamentale per un’equili brata e incisiva gestione di qualsiasi organizzazione. È in questo quadro di sensibilità crescente ai fenomeni gestionali e di ricerca di un mix equilibrato tra spinte so lo idealmente, ma di fat-to spesso concretamente contrapposte, che si inserisce il progetto sperimentale “La gestione dei processi produttivi sanitari attraverso lo strumento dei percorsi diagnostico-terapeutici”. Quando nell’or-mai lontano 1997 il progetto fu proposto per il finanziamento al Ministero della Sanità nel l’ambito dei programmi sperimentali, nei percorsi diagnostico-terapeutici, in se guito ridenominati percorsi del paziente (PDP), l’azienda aveva intravisto il fu turo “obbligato” del-la sanità italiana, in quanto possibile risposta contempora nea alle istanze pressanti di maggiore efficienza, efficacia e qualità.

Il percorso del paziente è uno strumento gestionale basato sull’as-sunto secondo cui, per consentire ai dirigenti medici di attivare le azioni ne cessarie per governare i risultati sanitari e gestionali di cui sono responsa bili, occorre rendere loro disponibile una tipologia d’informazione, tenden zialmente di carattere non monetario, che evidenzi il percorso compiuto dai pazienti e le singole attività utiliz-

zate; solo in tal modo è possibile analiz zare e controllare i processi sanitari, allo scopo di risolvere gli specifici pro blemi di salute che ciascun paziente presenta e, quindi, di attivare le azioni ritenute più idonee per garantirne il miglioramento futuro [Lega, 1999].

Il PDP può essere definito come l’iter complessivo che il pazien-te segue per risolvere il suo problema di salute, dal momento in cui viene a contatto con la struttura ospedaliera, più specificamente “l’iter clinico e organizza tivo definito, in ottica contingency, dalla sequenza temporale e spaziale del le attività ritenute necessarie per risolvere il problema di salute sulla base delle conoscenze tecnico-scientifiche e delle risorse professionali a disposi zione dell’ospedale in un certo periodo storico” [Casati e Vichi, 2002]. Esso descrive quindi il percorso organizzativo e clinico di interventi (cioè di at-tività) ne cessari per fornire assistenza a un gruppo di pazienti con una specifica dia gnosi o un determinato insieme di sintomi, a un precisato livello di qualità.

Gli obiettivi che ci si propone di perseguire con la logica che sot-tende all’introduzione della gestione per processo, rappresentato nel caso specifico della sanità dal percorso del paziente, sono i seguenti:• fornire il miglior servizio possibile al paziente, attraverso la

comunica zione personale e ai familiari di quanto lo attende nello svolgimento del percorso stesso, sviluppando una mo-dalità di gestione del rapporto tra struttura sanitaria e utente/paziente basata sulla completezza e trasparen za delle informa-zioni relative al percorso di cura;

• migliorare i rapporti di collaborazione e di scambio interni ed esterni al l’ospedale, favorendo processi di integrazione e co-ordinamento tra unità operative che partecipano congiunta-mente, seppur con professionalità diff erenti, alla realizzazione di un percorso;

• valorizzare il ruolo professionale degli operatori, in primo luo-go quello medico;

• costruire un sistema informativo di supporto alla programma-zione azien dale e ai centri di responsabilità, che consenta una più corretta identifi cazione delle risorse necessarie alla realiz-zazione delle attività e del con tributo richiesto ad altri centri di responsabilità. Ciò significa progettare uno strumento per la misurazione dei risultati delle organizzazioni sanitarie che consenta di esplicitare chiaramente: - l’oggetto di “scambio” tra azienda e paziente;- il valore economico dell’oggetto di scambio;- la correlazione con i processi interni aziendali e, quindi, il fabbi-

sogno di coordinamento nei rapporti tra unità operative;

- definire modalità di misurazione del risultato sanitario atteso derivan te dalla gestione dei processi;

- individuare eventuali punti critici del percorso, per i quali può es-sere necessario intraprendere interventi di riprogettazione orga-nizzativa a livel lo micro e macro, che consentano di aumentare i livelli di efficacia ed effi cienza dell’azienda creando le condizioni organizzative finalizzate a da re adeguata risposta ai fabbisogni di coordinamento generati dallo svi luppo dei percorsi.

Dal punto di vista dell’azienda, quindi, la lettura dei dati del con-trollo dei percorsi, confrontati anche con quanto elaborato in lette-ratura e da altre aziende, dovrà consentire di comprendere e valutare le diverse pratiche se guite e le relazioni interne ed esterne instaurate, così da attivare un siste matico processo di apprendimento organiz-zativo a livello di singolo medi co, gruppo di lavoro, reparto, unità operativa e di ospedale.

Dal punto di vista del singolo medico, l’adozione dei percorsi di riferi mento e delle loro varianti personalizzate, oltre a rappresentare uno strumento al controllo della gestione e un momento di aggior-namento, permetterà agli operatori interessati di aprire un confron-to culturale proponendo ai diversi interlocutori interni ed esterni i propri metodi clinici sviluppati secondo una metodologia, traspa-rente, condivisa e adottata dall’azienda, in un contesto generale sti-molante e creativo in quanto oggetto di continuo miglioramento.

Strumenti IT L’effetto dell’informatica e dell’automazione sulle procedure medi-co-sanitarie si sta manifestando in maniera sempre più ampia, por-tando notevoli vantaggi per la salute e il benessere di tutti i pazienti e al tempo stesso ponendo sfide sempre più complesse alle istituzio-ni sanitarie e ai produttori di dispositivi medico-sanitari. Si pensi alle applicazioni già oggi sotto gli occhi di tutti: dalla possibilità di prenotare un esame via internet all’uso di tecniche diagnostiche sempre più sofisticate (TAC, Risonanza Magnetica, PET, ecc.), dal-la telemedicina alla possibilità di eseguire interventi minimamente invasivi con tecniche endoscopiche [Marra et al., 2005]. Eppure, al di là dei meriti del singolo prodotto o tecnologia, esiste un fatto-re strategico che dovrebbe essere sempre considerato nel momento di progettare un software o un dispositivo da utilizzare in ambito sanitario (da parte dei produttori) o nel momento di pianificare l’acquisto di sistemi medicali o diagnostici complessi (da parte delle istituzioni sanitarie): l’aspetto dell’integrazione, ovvero la capacità del sistema di inserirsi in maniera semplice, efficace e poco costo-sa in un workflow completamente integrato. Se con le tecnologie

hardware e software attualmente disponibili è infatti relativamente semplice realizzare programmi e dispositivi per automatizzare singo-larmente molte delle tradizionali funzioni ospedaliere (ammissione del paziente, richiesta esami, generazione di immagini diagnostiche, cartella clinica, refertazione, ecc.), molto più difficile e costoso (an-che in termini di risorse e competenze) risulta l’obiettivo di rendere completamente automatico, digitale ed integrato il flusso di lavoro all’interno di una struttura sanitaria.

Soarian by SiemensSiemens Medical Solutions apre, con la suite di applicativi Soarian®, una nuova era per l’Information Technology sanitaria, il cui obiet-tivo è la gestione “proattiva” dei processi clinici legati alla diagnosi e alla cura del paziente, secondo linee guida, protocolli e procedure certificate [Mintrone, 2007].

Soarian® non si limita a gestire il paziente dal punto di vista am-ministrativo, ma si pone come un vero e proprio strumento a sup-porto delle decisioni cliniche.

Dalla passività di linee guida ed interventi descritti su supporto cartaceo, si passa alla proattività di regole, suggerimenti, strumenti di raccolta informazioni con i quali gli operatori interagiscono atti-vamente e costantemente nella pratica clinica quotidiana.

In pratica si tratta di un mezzo attraverso il quale coadiuvare l’operato del personale necessario alla cura del paziente, in grado di ridurre significativamente l’insorgenza di errori clinici. Un esempio concreto del supporto che l’Information Technology può offrire a livello clinico è dato dal Chester County Hospital, struttura ameri-cana all’avanguardia. Qui l’implementazione attraverso Soarian® di un workflow per il controllo delle infezioni da MRSA (stafilococco aureo meticillina resistente – il più comune batterio antibiotico-re-sistente) o da VRE (enterococco vancomicina resistente) ha ridotto dal 25% allo 0% la casistica di pazienti ricoverati senza conoscerne tempestivamente la potenziale contagiosità infettiva. Presso questo ospedale il motore di workflow rimane in “ascolto”, per ogni pazien-te ammesso o sottoposto a esami pre-ricovero, di eventuali risultati positivi ai due agenti patogeni. Se vengono intercettati risultati po-sitivi, il sistema invia in automatico notifiche a tutti gli operatori in-teressati, medici, infermieri, ufficio infezioni, servizio pulizie, con-sentendo la massima tempestività nelle operazioni di isolamento del paziente stesso, garantendo maggiore sicurezza per gli altri pazienti ricoverati e per lo staff clinico ed al contempo l’utilizzo adeguato delle risorse dell’ospedale.Questa soluzione rappresenta un ambito di applicazione partico-

larmente importante, perché attraverso meccanismi integrati nella pratica clinica quotidiana è possibile definire e attuare interventi organizzativi in grado di prevenire l’insorgere di rischi di infezioni ospedaliere.

Uno strumento di questo tipo è quindi un elemento strategico fondamentale per supportare nuove ed emergenti esigenze:• gestione del rischio clinico;• implementazione diffusa di linee guida;• incrementi di efficienza nella gestione clinica (più qualità,

meno costi);• governo clinico.

3.2 Unified Modeling Language (UML)

3.2.1 Introduzione

La comunicazione tra informatici che operano in ambienti com-plessi, quali tipicamente sono gli ospedali, ha bisogno di forme in-termedie tra la forma testuale, avvertita come dispersiva, e quella dei linguaggi di programmazione, i cui tanti dettagli di scrittura rendono difficile dominare le tante, diversificate, spesso temporiz-zate interazioni tra i molteplici attori.

Assecondando l’osservazione che un’immagine spesso fornisce una comunicazione molto efficace, l’UML (Unified Modeling Lan-guage) è un linguaggio grafico volto a facilitare la comunicazione tra informatici. La facilitazione è conseguita attraverso l’impiego di una grammatica e di una sintassi grafiche che visualizzano gli attori in gioco, le relazioni che tra essi intercorrono, le attività possibili e le sequenze da rispettare per metterle in pratica in modo appropriato, e così via [Fowler e Scott, 1999].

UML è uno standard dell’Object Management Group (OMG) che definisce “un linguaggio per specificare, visualizzare e realizza-re i prodotti di sistemi software e anche per il business modeling. L’UML rappresenta una collezione di “best engineering practices” che si sono dimostrate utili nella progettazione di sistemi complessi e di grandi dimensioni” [UML, 1997].

È importante avere chiaro fin dall’inizio il punto di vista utiliz-zato nello sviluppo di un particolare modello del sistema in esame. Tre sono i differenti punti di vista (Figura 3.4):• concettuale: consente di costruire un modello del sistema in

esame rappresentando i concetti del dominio dell’utente;• di specificazione: è il primo passo verso il software, ma ci si oc-

Figura 3.4I punti di vista nello sviluppo di un modello

Figura 3.5Gerarchia dei diagrammi

Class Diagram

CompositeStructure Diagram

Timing Diagram

Activity Diagram

Sequence Diagram

Interaction Diagram

CommunicationDiagram

Component Diagram

Deployment Diagram

Structure Diagram

Use Case Diagram

InteractionOverview Diagram

Behavior Diagram

Object Diagram

Package Diagram

State MachineDiagram

Diagram

cupa del software solo a livello di interfacce. Ci si muove non più nel dominio utente, ma nel dominio applicativo;

• implementativo: tale punto di vista consente di descrivere l’im-plementazione del software.

3.2.2 Diagrammi

Il linguaggio UML consiste di 9 diagrammi di base, ma si tenga presente che è assolutamente possibile costruire e aggiungere dei diagrammi differenti dagli standard (che vengono definiti ibridi) rispetto a quelli definiti dal linguaggio [UML, 1997].

Possono essere suddivisi sulla base di differenti categorie a secon-da che descrivano la struttura, il comportamento oppure le intera-zioni (Figura 3.5). Vediamo nel dettaglio i diagrammi principali e la loro struttura [Naiburg e Maksimchuck, 2001].

Class Diagram

Per avere una idea immediata di cosa sia una classe possiamo usare come esempio il fatto che tutti gli oggetti o esseri viventi, spesso, sono riconducibili a determinate categorie (per esempio: computers, automobili, piante, animali, ecc.). Queste categorie costituiscono le classi: una classe è una categoria o un gruppo di oggetti (con que-

sto termine includiamo, per comodità anche gli esseri viventi) che hanno attributi simili e comportamenti analoghi. I Class Diagrams forniscono le rappresentazioni utilizzate dagli sviluppatori.

Il Class Diagram del linguaggio UML consiste di svariate classi connesse tra di loro tramite delle relazioni. Una classe viene rap-presentata da un rettangolo (Figura 3.6). Il nome della classe, per convenzione, è una parola con l’iniziale maiuscola e appare vicino alla sommità del rettangolo. Se il nome della classe definita consiste di una parola composta a sua volta da più parole allora viene utiliz-zata la notazione in cui tutte le iniziali di ogni parola sono scritte in maiuscolo. Un attributo rappresenta una proprietà di una classe: esso descrive un insieme di valori che la proprietà può avere quando vengono istanziati oggetti di quella determinata classe. Una classe può avere zero o più attributi. La lista degli attributi di una classe viene separata graficamente dal nome della classe a cui appartiene tramite una linea orizzontale.

Un’operazione è un’azione che gli oggetti di una certa classe pos-sono compiere. Analogamente al nome degli attributi, il nome di un’operazione viene scritto con caratteri minuscoli. Anche qui, se il nome dell’operazione consiste di più parole, allora tali parole vengo-no unite tra di loro e ognuna di esse, eccetto la prima, viene scritta con il primo carattere maiuscolo.

Le classi possono relazionarsi (essere associate) una con l’altra in diversi modi.• Generalizzazione: l’ereditarietà è uno dei concetti fondamen-

tali della programmazione a oggetti, in cui una classe “acquisi-sce” tutti gli attributi e le operazioni della classe da cui eredita, e può sostituire o modificare alcuni di loro, oltre ad aggiungere più attributi e operazioni di suo. In UML, un’associazione di generalizzazione tra due classi le mette in una gerarchia rap-presentante il concetto di ereditarietà di una classe derivata da una classe di base. In UML le generalizzazioni sono rappresen-tate da una linea che connette le due classi, con una freccia sul lato della classe di genitore.

• Associazioni: sono i meccanismi che permettono agli oggetti di comunicare tra loro, descrivono la connessione tra diverse classi (la connessione tra gli oggetti reali è chiamata una con-nessione tra oggetti, o collegamento). Le associazioni possono

Figura 3.6Rappresentazione di una classe

Attribute: Type = initial Value

CLASS NAME

Operation (arg list): return type

avere un ruolo che specifica lo scopo dell’associazione e può essere uni o bidirezionale (indica se i due oggetti che parteci-pano alla relazione possono mandare messaggi all’altro, o se solo uno di loro sa dell’altro). Ogni parte dell’associazione ha un valore di molteplicità, che detta quanti oggetti su questo lato dell’associazione possono relazionarsi a un oggetto sull’al-tro lato. In UML le associazioni sono rappresentate come li-nee che connettono le classi che partecipano alla relazione, e possono anche mostrare il ruolo e la molteplicità di ciascuno dei partecipanti. La molteplicità è mostrata come un intervallo [minimo..massimo] di valori non negativi, con un asterisco (*) sul lato massimo per rappresentare l’infinito.

• Aggregazione: sono un tipo speciale di associazioni nel quale le due classi partecipanti non hanno un rango uguale, ma hanno una relazione “intero-parte”. Un’aggregazione descrive come la classe che ha il ruolo dell’intero è composta di (ha) altre classi, che hanno il ruolo di parti. Per le aggregazioni, la classe che fa da intero ha sempre molteplicità di uno. In UML le aggregazioni sono rappresentate da un’associazione che mostra un rombo vuoto sul lato dell’intero.

• Composizione: le composizioni sono associazioni che rappre-sentano aggregazioni molto forti. Ciò vuol dire che anche le composizioni formano relazioni intero-parte, ma la relazione è così forte che la parte non può esistere di per sé. Esistono solo all’interno dell’intero, e se l’intero è distrutto anche le parti muoiono. In UML le composizioni sono rappresentate da un rombo solido sul lato dell’intero.

La seguente figura (Figura 3.7) illustra con un esempio quanto espresso:

Vertice Centro

Poligono Cerchio

0...* 0...*

Figura 3.7Esempio di aggregazione

e composizione tra classi

Object DiagramUn Object Diagram è simile a un Class Diagram ma è riferito agli oggetti, descrivendone la struttura runtime. Per questo può anche essere relativo a uno specifico istante.

Use Case DiagramUno Use Case (caso d’uso) è una descrizione di un comportamento particolare di un sistema dal punto di vista dell’utente. Per gli svilup-patori, gli Use Case Diagram rappresentano uno strumento notevo-le: infatti tramite tali diagrammi, essi possono agevolmente ottenere una idea chiara dei requisiti del sistema dal punto di vista utente e quindi scrivere il codice senza timore di non aver recepito bene lo scopo finale. All’interno di un singolo caso d’uso vi possono essere diversi percorsi possibili. Tali cammini prendono il nome di scenari, quindi per meglio descrivere il nostro caso d’uso possiamo realizzare diversi scenari, i quali devono interessare i casi più significativi per meglio descrivere le diverse interazioni che vi possono essere fra più casi d’uso. Nella rappresentazione grafica, viene utilizzato un simbo-lo particolare per l’actor (l’utente o un altro sistema che interagisce) che vediamo in Figura 3.8. L’actor è l’entità che interagisce con uno Use Case facendo partire la sequenza di azioni descritte dallo Use Case stesso e, eventualmente, ricevendo delle precise risposte dal si-stema. Può essere una persona o anche un altro sistema.

Le relazioni possibili all’interno di uno Use Case sono:• include: specifica che un caso d’uso avviene all’interno di un

altro caso d’uso;• extend: specifica che in certe situazioni, o a un certo punto

(chiamato punto di estensione) un caso d’uso sarà esteso da un altro;

• generalization: specifica che un caso d’uso eredita le caratteri-stiche del “sovra”caso d’uso, e può sostituirne alcune o aggiun-gerne nuove in un modo simile all’ereditarietà tra classi.

Graficamente (Figura 3.8):

Use case

<< Extend >> Generalization

<< Include >>

Extension points

(Extension points)

Figura 3.8Le relazioni possibili in uno Use Case Diagram

State DiagramA un determinato istante, durante il funzionamento del sistema, un oggetto si trova in un particolare stato. Gli State Diagrams rappresen-tano tali stati, e i loro cambiamenti nel tempo. Ogni State Diagram inizia con un simbolo che identifica lo stato iniziale (Start State) e termina con un altro simbolo che rappresenta lo stato finale (End State). Per esempio, ogni persona può essere identificato dai seguenti stati: neonato, infante, bambino, adolescente, adulto, anziano.

Sequence DiagramI Class Diagrams e gli Object Diagrams rappresentano informazio-ne statica. In un sistema funzionante, tuttavia, gli oggetti interagi-scono l’uno con l’altro, e queste interazioni avvengono in relazione al trascorrere del tempo. Il Sequence Diagram (Figura 3.9) mostra le dinamiche, basate sul tempo, delle varie interazioni tra gli oggetti.

Activity DiagramLe attività che si riscontrano all’interno di Use Case o all’interno del comportamento di un oggetto accadono, tipicamente, in una sequenza ben definita. Tale sequenza viene rappresentata con gli Ac-tivity Diagrams (Figura 3.10).

Gli elementi di un Activity Diagram sono i seguenti.• Activity: dal punto di vista concettuale, indicano un lavoro che

deve essere svolto. Dal punto di vista più strettamente imple-mentativo, un’activity può essere un metodo di una classe. Da ogni activity possono uscire uno o più transazioni, che indica-no il percorso da una activity ad un’altra.

• Start e End Point: punti di inizio e fine del diagramma. Gli End Point possono anche non essere presenti, oppure essere più di uno.

• Branch e merge: il comportamento condizionale è determinato da questi due costrutti. Il branch ha una singola transazione

Create

Message Self Delegation

Delete

Return

An Object

New Object

Figura 3.9Esempio di Sequence

Diagram

entrante e più transazioni uscenti in cui solo una di queste sarà prescelta. Il merge ha più transazioni entranti e una sola uscente e serve a terminare il blocco condizionale cominciato con un branch.

• Fork e join: il comportamento parallelo è determinato da que-sti due costrutti. Quando scatta la transazione entrante, si eseguono in parallelo tutte le transazioni che escono dal fork. Con il parallelismo non è specificata la sequenza. Per la sincro-nizzazione delle attività parallele è presente il costrutto di join che ha più transazioni entranti e una sola transazione uscente.

Un Activity Diagram è particolarmente utile per descrivere wor-kflow process, e quindi business process e parallel process.

Da un punto di vista più vicino a UML, tali diagrammi sono utili per:• descrivere metodi di classe;• descrivere use case.

[Condition]

Activity Activity

Activity

DynamicConcurrent

Actvity

[Else]

Branch

Figura 3.10Esempio di Activity Diagram

Role Name

1. Simple Message()

1.1*. Iteration Message()1.2. [Condition] Message()

Object Name: Class

: Class Object Name

Figura 3.11Esempio di Collaboration Diagram

Collaboration DiagramGli elementi di un sistema lavorano insieme per realizzarne e sod-disfarne le necessità. Un linguaggio di modellazione deve avere un modo per rappresentare tale cooperazione: il Collaboration Dia-gram (Figura 3.11) nasce proprio per questa ragione.

Component DiagramOggi, nell’ingegneria del software, viene sempre più utilizzato il modello di organizzazione secondo il quale ognuno nel team di la-voro si occupa di un componente differente: il Component Dia-gram descrive questa importante caratteristica.

Deployment DiagramIl Deployment Diagram (Figura 3.12) mostra l’architettura dal punto di vista fisico e logistico di un sistema. Tale diagramma può descrivere i computer e i vari dispositivi presenti, mostrare le varie connessioni che intercorrono tra di essi e, ancora, il software che è installato su ogni macchina.

3.2.3 Vantaggi di UML

Elenchiamo, qui di seguito, alcuni dei benefici derivanti dall’utiliz-zo del linguaggio UML.1. Un sistema software grazie al linguaggio UML viene disegna-

to professionalmente e documentato ancor prima che ne venga scritto il relativo codice, da parte degli sviluppatori. Si sarà così in grado di conoscere in anticipo il risultato finale del progetto su cui si sta lavorando.

2. Poichè, come detto, la fase di disegno del sistema precede la fase di scrittura del codice, ne consegue che la scrittura del co-dice stessa è resa più agevole ed efficiente oltre al fatto che in tal modo è più facile scrivere del codice riutilizzabile in futuro. I costi di sviluppo, dunque, si abbassano notevolmente con l’utilizzo del linguaggio UML.

3. È più facile prevedere e anticipare eventuali “buchi” nel sistema. Il software che si scrive, si comporterà esattamente come ci si aspetta senza spiacevoli sorprese finali.

4. L’utilizzo dei diagrammi UML permette di dare una chiara idea, a chiunque sia coinvolto nello sviluppo, di tutto l’in-sieme che costituisce il sistema. In questo modo, si potranno sfruttare al meglio anche le risorse hardware in termini di me-moria ed efficienza, senza sprechi inutili o, al contrario, rischi di sottostima dei requisiti di sistema.

Component 2

Component 1

Figura 3.12Esempio di Deployment

Diagram

5. Grazie alla documentazione del linguaggio UML diviene an-cora più facile effettuare eventuali modifiche future al codice. Questo, ancora, a tutto beneficio dei costi di mantenimento del sistema.

La comunicazione e l’interazione tra tutte le risorse umane che prendono parte allo sviluppo del sistema è molto più efficiente e diretta; parlare la stessa “lingua” aiuta a evitare rischi di incompren-sioni e quindi sprechi di tempo [Booch et al., 2005], [Bandinelli et al., 1995] .

3.2.4 UML nell’ Healthcare

Al fine di dare una risposta alla richiesta crescente di interventi sa-nitari, si è cercato di ridisegnare l’organizzazione del Servizio Sa-nitario, trasferendo il luogo di cura e assistenza dall’Ospedale alle strutture territoriali e da queste al domicilio del paziente.

Tutto questo è stato reso possibile grazie alla “sensibilità” mostra-ta dai diversi “attori” operanti in Sanità e dalle nuove opportunità offerte dalla ricerca scientifica in campo diagnostico (in particolare nella diagnostica per immagini e di laboratorio) e terapeutico (con la commercializzazione di molecole, innovative anche per la loro maneggevolezza).

In molti di questi casi può essere utile realizzare, con idonei strumenti e metodi, un’analisi degli specifici bisogni e dei processi assistenziali realizzati, ricercando quelli più idonei. Ciò significa de-finire dei “profili di assistenza”, ovvero programmi interdisciplinari creati per rispondere a specifici problemi clinici, tendenti a mini-mizzare la pratica clinica non appropriata e i relativi “costi super-flui” e adattati alle risorse concretamente presenti a livello locale. Sulla base dell’evidenza scientifica coniugata alla migliore pratica clinica, essi definiscono la migliore sequenza degli interventi rivol-ti a pazienti con particolari diagnosi e condizioni all’interno delle diverse tipologie di servizi ospedalieri ed extra-ospedalieri. A dif-ferenza delle linee guida, i profili assistenziali spostano l’attenzione delle diverse figure professionali preposte all’assistenza del semplice “caso clinico” al “paziente” con bisogni complessi – e non solamente sanitari – favorendo in tal modo l’approccio multidisciplinare e il lavoro di equipe (Ministero della Salute).

La stesura di un profilo di assistenza è un processo complesso che coinvolge più attori e necessita di un lavoro sistematico, articolato nel tempo e sottoposto a periodiche revisioni in funzione dei risultati otte-nuti o di possibili influenze che possono venire dall’ambiente esterno. In conseguenza è necessario effettuare alcune scelte di fondo quali:

1. avere come punto di riferimento il paziente e non più la pre-stazione fornita;

2. lavorare in pool con altri professionisti che, pur operando in strutture differenti, entrano nell’evolvere naturale di una pato-logia. Questi professionisti sono legati da un comune filo “il paziente” e conseguentemente hanno un reciproco rapporto di cliente-fornitore;

3. effettuare dei programmi formativi finalizzati alla conoscenza delle migliori evidenze scientifiche, nonché, delle migliori pra-tiche possibili in funzione del bisogno del paziente. I program-mi in questione devono essere caratterizzati dalla presenza di tutte le figure coinvolte nel processo di cura del paziente;

4. definito il profilo di cura, avviare in sede locale un percorso per il paziente monitorando i diversi aspetti che lo caratterizzano: quello clinico, quello gestionale e quello economico registran-do sistematicamente gli output e gli outcome;

5. inserire il tutto in un sistema capace di trovare il maggior livel-lo di qualità possibile, partendo dal presupposto che occorre ricercare la qualità totale.

Al fine di definire i profili di assistenza, possono essere utilizzati diversi modelli. Consideriamo quello ritenuto di maggiore efficacia operativa, sulla scia di quanto previsto dall’Organizzazione Tri-He-alth di Cincinnati, che può essere così sintetizzato: 1. Identificazione della patologia; 2. Costituzione del gruppo di lavoro; 3. Selezione della Popolazione; 4. Stesura del profilo di Assistenza; 5. Pretesting del profilo di Assistenza; 6. Applicazione del Profilo di Assistenza; 7. Valutazione del Profilo di Assistenza; 8. Implementazione del Profilo di Assistenza. L’esperienza sul campo ha evidenziato la necessità di sviluppare ul-teriormente due problematiche: • il sistema di rappresentazione del profilo per meglio provve-

dere alla stesura;• la metodologia per effettuare il pretesting.

Il sistema di rappresentazioneFinora in sanità sono state utilizzate delle tecniche di rappresenta-zione dei profili di assistenza che sul campo hanno mostrato non poche debolezze. In particolare si riportano di seguito quelle mag-giormente impiegate:• flowchart o diagramma di flusso: strumento che permette una

visione immediata e schematica del processo grazie a una nota-zione facilmente comprensibile, ma che appare inefficace nella rappresentazione di processi più complessi e articolati in quan-to produce un appesantimento della notazione tale da rendere il diagramma poco leggibile.

• IDEF0 o Scatola delle attività: strumento che coglie bene gli aspetti funzionali di un’organizzazione o di un sistema grazie alla sua schematizzazione in input, output, vincoli e risorse. Esso si presta, pertanto, a modellare solo gli aspetti statici di un sistema e risulta non idoneo nella rappresentazione di pro-cessi con numerosi momenti decisionali che portano a scelte alternative.

Con il crescere della complessità dei sistemi è opportuno utilizzare una tecnica di rappresentazione che superi i limiti legati agli stru-menti sopra esposti. Si è pertanto scelto di adottare, a tale scopo, il linguaggio UML (Unified Modeling Language). UML, infatti, inclu-de una notazione grafica che rappresenta diverse ‘viste’ del sistema:• la vista statica evidenzia informazioni che non evolvono nel

tempo fornendo un’istantanea del sistema in un dato momen-to della sua vita;

• la vista dinamica mostra l’evoluzione degli elementi del siste-ma evidenziandone le loro interazioni.

UML è allo stato attuale, utilizzato principalmente per la progetta-zione di sistemi software object oriented; tuttavia, dato che, nessuna delle sue caratteristiche è esclusivamente riferibile allo sviluppo del software, UML è un valido strumento per la rappresentazione di realtà e processi complessi. L’approccio adottato per la rappresenta-zione si articola nelle seguenti fasi.1. Costruzione del percorso di massima: rappresentazione generale

del percorso di assistenza, basata sull’utilizzo del diagramma UML dei casi d’uso. Questo diagramma fornisce una vista sta-tica del sistema utilizzata per caratterizzare il processo, gli ele-menti che lo compongono (risorse, input, output) e le attività elementari che lo rappresentano.

2. Ricostruzione analitica del percorso: partendo dal percorso di massima, attraverso un approccio gerarchico, si giunge a una rappresentazione di dettaglio delle singole attività coinvolte nel processo/percorso di assistenza e delle relazioni che inter-corrono tra di esse. In questa fase gli aspetti statici del percorso sono rappresentati mediante i diagrammi UML dei casi d’uso, mentre per la modellazione degli aspetti dinamici, si ricorre ai diagrammi delle attività. Tali diagrammi consentono, infatti, di tener conto dei momenti decisionali e dei flussi informativi

coinvolti nel processo 3. Analisi dei costi: in questa fase, sfruttando la modellazione

dell’intero processo ottenuta tramite il modello concettuale, è possibile individuare con chiarezza le attività essenziali del processo sanitario e associare a esse i costi, ai fini della valu-tazione economica dello stesso, coerentemente con i concetti di Activity Based Costing (ABC). Questa associazione è sem-plificata e supportata dai diagrammi UML, in cui è possibile definire in maniera analitica i tempi e le altre determinanti di costo legate all’esecuzione di una data attività.

Il sistema di simulazione come metodologia per effettuare il pretesting

L’utilizzo di modelli organizzativi innovativi, legati a processi con-tinui di cura, caratterizzati per la necessità di ridisporre le risorse all’interno del sistema, determina la necessità di “testare” in ambien-te protetto”, i possibili scenari operativi.

Grazie ai modelli di pianificazione e di rappresentazione indica-ti, possono essere costruiti modelli di simulazione capaci di testa-re scenari possibili, consentendo così una valutazione dei punti di forza e di debolezza insiti nel sistema, nonché l’analisi dell’impatto funzionale ed economico del processo sanitario di cura. Consente di testare svariati parametri che possono essere la base per la de-terminazione “sul campo” di indicatori di output. Consente infine di supportare scelte di convenienza economica tra ipotesi alternati-ve, supportando così, a diversi livelli aziendali, le scelte gestionali. Rappresenta infine la base di partenza per la definizione prima e la rilevazione poi di indicatori di esito sanitario.

ESEMPIO: Realizzazione di diagrammi UML per esame obiettivoConsideriamo l’esame obiettivo che viene effettuato da un medico sul paziente che si reca all’interno della struttura sanitaria [Naiburg e Maksimchuk, 2001]. Immaginiamo esista un programma compu-terizzato che unisca tutte le informazioni relative a un determinato paziente all’interno di tutto l’ospedale. Diversi professionisti effet-tuano lo stesso tipo di esame sul paziente in momenti diversi. Un semplice sistema computerizzato consente di recuperare informa-zioni relative agli esami effettuati e di aggiungerne di nuove.

Abbiamo quindi creato un unico Use Case, denominato “rive-dere e integrare esame obiettivo sul paziente” e possiamo prevedere diversi scenari:• indagare riguardo all’ultimo valore di frequenza cardiaca re-

gistrata;

• indagare sul gruppo sanguigno;• aggiornare il livello di coscienza del paziente;• aggiornare i dati sulla frequenza cardiaca: il sistema registra

la frequenza come bassa, normale o alta a seconda dei range stabiliti in precedenza.

Il primo passo è di realizzare il modello concettuale (Figura 3.13) che descriva i concetti appartenenti a questo dominio. In questa fase non dobbiamo pensare a come funzionerà il software ma a come organizzare i concetti nelle menti dei medici e degli infermieri.

Iniziamo con un modello basato sui seguenti concetti:• osservazione;• quantità;• range;• limiti.

Figura 3.13Modello Concettuale

PhenomenonType

Observation

Phenomenon

Measurement

Quantity

Patient

CategoryObservation

Range: Range

Amount: Quantity

Amount: NumberUnit: Unit

IsPresent: Boolean

Upper: MagnitudeLower: Magnitude

0... 1

Measurement Category<Dynamic>

Figura 3.14Patient Observation Domain Model.Adattato da [Fowler e Scott, 1999]

Ogni osservazione effettuata dal medico o dall’infermiere sul pa-ziente è un’istanza del concetto di Osservazione e può essere o una Misurazione o una Categoria d’osservazione (Figura 3.14). Asso-ciati alla misurazione ci sono il Tipo di Fenomeno (peso, altezza, frequenza cardiaca, ecc.) e il Nome del Paziente.

L’Osservazione che il paziente (nell’esempio Martin Flower) ha gruppo sanguigno 0 è rappresentata come una Categoria di Osser-vazione il cui Fenomeno associato è “gruppo sanguigno 0”. Questo Fenomeno è associato al Tipo di Fenomeno “gruppo sanguigno” (Figura 3.15)

Quindi, possiamo effettuare un’Osservazione che faccia sia da Misura che da Categoria d’Osservazione definendo che una Misura di “90 battiti al minuto” può anche essere definito come Categoria d’Osservazione il cui Fenomeno associato è “elevata frequenza car-diaca” (Figura 3.16).

Ora consideriamo il comportamento collegato al modello di os-servazione (e quindi di specificazione, Figura 3.17) del nostro pa-ziente.

Il primo scenario riguarda la richiesta al paziente del valore dell’ultima frequenza cardiaca misurata. La responsabilità di gestire questa richiesta è del paziente. Il paziente deve poter avere accesso a tutte le rilevazioni, determinare quali rientrano nel Fenomeno “Fre-quenza cardiaca” e trovare l’ultima rilevazione (Figura 3.18). Per fare questo dobbiamo aggiungere un campo relativo al Tempo per quanto riguarda la Misurazione e l’Osservazione.

Amount = 6 feet

Heigt:Phenomenon

Blood group:Phenomenon

a Measurement

Martin Flower:Patient

Blood group A:Phenomenon

Blood group O:Phenomenon

Figura 3.15 Patinet Observation

Object Diagram.Adattato da [Fowler e

Scott, 1999]

Figura 3.16 Patient Observation Object Diagram 2.Adattato da [Fowler e Scott, 1999]

Figura 3.17 Modello di specificazione

Figura 3.18 Patient Observation OperationsAdattato da [Fowler e Scott, 1999]

PhenomenonType

Observation

Phenomenon

Measurement

Patient

Range:Quantity Range

Latest Amount of (Phenomenon Type): QuantityPhenomenon of (Phenomenon Type): Phenomenon

Amount: Quantity Timepoint

0... 1

Normal heart rate:Phenomenon

Amount = 90 bpm

a Range a Range

Upper = 80 bpmLower = 60 bpm

Upper = InfinityLower = 80 bpm

Fast heart rate:Phenomenon

Stefano BonacinaPatient

Measurementand Category Observation

Heart rate:Phenomenon Type

3.3 Data Mining

3.3.1 Una definizione

Il Data Mining è un processo analitico studiato per esplorare i dati (di solito grandi quantità) alla ricerca di pattern consistenti e/o rela-zioni sistematiche tra variabili e quindi validare i risultati applican-do i pattern ottenuti a nuovi sottoinsiemi di dati. Il Data Mining è una materia interdisciplinare relativamente recente e poggia le sue radici su vari campi di applicazione tra i quali l’intelligenza artificia-le, la statistica, le basi di dati e il machine learning.

3.3.2 Il processo Knowledge Discovery in Databases (KDD)

Come è possibile vedere nella Figura 3.19 il Data Mining è parte di un processo più ampio che ha il nome di Knowledge Discovery in Databases: indipendentemente dal tipo di applicazione specifica, un processo di estrazione di conoscenza percorre alcune fasi che possono essere schematizzate nella figura seguente (Figura 3.19):

Il processo KDD prevede come input dati grezzi e fornisce come output informazioni utili ottenute attraverso le seguenti fasi:• Selezione: i dati grezzi vengono segmentati e selezionati secon-

do alcuni criteri al fine di pervenire a un sottoinsieme di dati, che rappresentano il nostro target data o dati obiettivo. Risulta abbastanza chiaro come un database possa contenere diverse informazioni, che per il problema sotto studio possono risul-tare inutili; per fare un esempio, se l’obiettivo è lo studio delle associazioni tra i prodotti di una catena di supermercati, non ha senso conservare i dati relativi alla professione dei clienti; è

Informationrequirement

Dataselection

EnrichmentCleaning· DomainConsistency· De-duplication· Disambiguation

Data mining· Clustering· Segmentation· Prediction

Action

External data

Operational data

Feedback

Coding Reporting

Figura 3.19Processo del Knowledge Discovery in Databases

(KDD). Adattato da [Adrians e Zantinge,

1996], pag. 38

invece assolutamente errato non considerare tale variabile, che potrebbe invece fornire utili informazioni relative al compor-tamento di determinate fasce di clienti, nel caso in cui si voglia effettuare un’analisi discriminante.

• Pre-elaborazione: spesso, pur avendo a disposizione il target data non è conveniente, né d’altra parte necessario, analizzarne l’intero contenuto; può essere più adeguato prima campionare le tabelle e in seguito esplorare tale campione effettuando così un’analisi su base campionaria. Fanno inoltre parte del seguen-te stadio del KDD la fase di pulizia dei dati (data cleaning), che prevede l’eliminazione dei possibili errori, e la decisione dei meccanismi di comportamento in caso di dati mancanti.

• Trasformazioni: effettuata la fase precedente, i dati, per essere utilizzabili, devono essere trasformati. Si possono convertire tipi di dati in altri o definire nuovi dati ottenuti attraverso l’uso di operazioni matematiche e logiche sulle variabili. Inol-tre, soprattutto quando i dati provengono da fonti diverse, è necessario effettuare una loro riconfigurazione al fine di garan-tirne la consistenza.

• Data Mining: ai dati trasformati vengono applicate una serie di tecniche in modo da poterne ricavare dell’informazione non banale o scontata, bensì interessante e utile. I tipi di dati che si hanno a disposizione e gli obiettivi che si vogliono raggiun-gere possono dare un’indicazione circa il tipo di metodo/algo-ritmo da scegliere per la ricerca di informazioni dai dati. Un fatto è certo: l’intero processo KDD è un processo interattivo tra l’utente, il software utilizzato e gli obiettivi, che devono esse-re costantemente inquadrati, e iterativo nel senso che la fase di DM può prevedere un’ulteriore trasformazione dei dati originali o un’ulteriore pulizia, ritornando di fatto alle fasi precedenti.

• Interpretazioni e Valutazioni: il DM crea dei pattern, ovve-ro dei modelli, che possono costituire un valido supporto alle decisioni. Non basta però interpretare i risultati attraverso dei grafici che visualizzano l’output del DM, ma occorre valuta-re questi modelli e cioè capire in che misura questi possono essere utili. È dunque possibile, alla luce di risultati non per-fettamente soddisfacenti, rivedere una o più fasi dell’intero processo KDD.

Il processo di Knowledge Discovery in Databases è un campo di ricerca multidisciplinare (Figura 3.20):• sistemi esperti;• machine learning;

• statistica;• visualizzazione;• database.

3.3.3 Data Mining

Gli algoritmi di Data Mining sono stati sviluppati per far fronte all’esigenza di sfruttare il patrimonio informativo contenuto nelle grandi raccolte di dati che abbiamo a disposizione (Figura 3.21).

Avere dati non è infatti più un problema (basta pensare alla ric-chezza delle sorgenti di dati accessibili su Web o attraverso Data Warehouse aziendali), il problema è cercare di utilizzarli, estrarne le informazioni. Spesso i dati, sia che si riferiscano all’attività gior-naliera dell’azienda (o dell’ente), sia che si riferiscano alla clientela (o all’utenza), sia che si riferiscano al mercato o alla concorrenza, si presentano in forma eterogenea, ridondante, non strutturata. Tutto ciò fa sì che solo una piccola parte ne venga analizzata. D’altra parte la rapida evoluzione del mercato richiede rapidità di adattamento. In questo contesto riuscire a sfruttare la potenziale ricchezza di in-formazioni che abbiamo a disposizione costituisce un enorme van-taggio [Dulli, 2006].

Per fare ciò è necessario disporre di strumenti potenti e flessibili. La grande quantità di dati e la loro natura eterogenea rende infatti inadeguati gli strumenti tradizionali. Questi si dividono in due tipi: strumenti di analisi statistica e strumenti tipici di interrogazione di banche dati (data retrieval). Per quanto riguarda i primi, le difficoltà nascono dal fatto che: • difficilmente operano su grandi quantità di dati (richiedono

operazioni di campionamento con conseguente perdita di in-formazioni);

• spesso richiedono valori di tipo quantitativo (mentre i prodot-ti venduti, le caratteristiche della clientela, ecc. sono dati di tipo qualitativo);

• non gestiscono i valori mancanti;

Expert systems Machine learning

StatisticsKDD

Database

Visualization

Figura 3.20Insieme

multidisciplinare del KDD. Adattato da

[Adrians e Zantinge, 1996], pag. 96

Figura 3.21Processo di

sfruttamento del patrimonio informativo.

Adattato da [Dulli, 2006], pag. 9

Informazione

Conoscenza

Decisione

Volume

Valore

• richiedono personale tecnico sia per il loro utilizzo che per l’interpretazione dei risultati.

Per quanto riguarda il data retrieval, le difficoltà riguardano: • i tempi di risposta (aumentano all’aumentare della quantità

di dati);• l’inadeguatezza nell’individuare “associazioni nascoste”.È difficile definire in maniera precisa un’area in continua evoluzio-ne, quale è sicuramente quella del Data Mining. In assenza di una definizione universalmente accettata, considereremo il Data Mining come: “il processo di estrazione di informazione valida, utilizzabile e precedentemente sconosciuta, da grandi databases e l’utilizzo di queste informazioni per prendere cruciali decisioni di business” [Cabena et al., 1997].

Alcune delle parole utilizzate nella definizione aiutano a chiarire in cosa il Data Mining si differenzia rispetto ad altre discipline simili:• informazione valida: un data miner, analizzando larghi insiemi

di dati, prima o poi troverà qualcosa di interessante. Contra-riamente a quanto dicano i super-ottimisti, è necessario con-trollare che i risultati ottenuti non siano errati;

• informazione utilizzabile: deve essere possibile tradurre la nuo-va informazione in un vantaggio di business;

• informazione sconosciuta: il data miner ricerca qualcosa che non è intuitivo ma, anzi, è spesso controintuitivo (più l’in-formazione si discosta dall’ovvio, infatti, più è grande il suo valore potenziale).

Non è facile vedere la differenza tra il Data Mining e le altre tecni-che di analisi dei dati. In generale, possiamo dire che quando co-nosciamo chiaramente la forma ed i contenuti approssimativi di ciò che stiamo cercando, non abbiamo a che fare con un problema di Data Mining.

Paradigmi di Data MiningPer costruire i modelli sulla base dei dati si possono differenziare due paradigmi di apprendimento che differenziano le tecniche di Data Mining:• Data Mining supervisionato, fondato su algoritmi predittivi;• Data Mining non supervisionato, che sfrutta algoritmi di tipo

descrittivo.Il Data Mining supervisionato è un approccio top down, applica-bile quando è chiaro l’obiettivo da prevedere, che genera previsioni, stime, caratterizzazioni rispetto al comportamento di alcune varia-bili target, individuate in funzione di variabili di input. Nei modelli previsionali l’obiettivo è quello di apprendere in modo che la cono-

scenza acquisita sia applicabile anche in futuro, quindi il modello migliore non è solo quello che presenta migliore efficacia (lift) ma quello meglio performante con i dati futuri.

Il Data Mining non supervisionato è un approccio bottom up in cui si lascia che i dati stessi indichino un risultato, dove non esiste una variabile target usata per la descrizione e l’individuazione di segmenti.

Tale approccio viene spesso applicato nella fase esplorativa per cogliere nelle strutture decisionali un pattern interessante.

Le tecniche utilizzabili sono varie e, di conseguenza, anche gli algoritmi che le implementano. La scelta dipende principalmente dall’obiettivo che si vuole raggiungere e dal tipo di dati da analiz-zare [Adrians e Zantinge, 1996]. Le più utilizzate sono illustrate di seguito.

• Tecniche di visualizzazioneL’esplorazione visiva dei dati mira a integrare le capacità di elabo-razione umane con gli strumenti tecnologici a disposizione (Figu-ra 3.22 e 3.23). I tipi di dati che possono essere visualizzati sono: dati monodimensionali, bidimensionali o multidimensionali, testi e ipertesti, gerarchie e grafici, algoritmi e software.

• Clustering Mediante tecniche di cluster analysis è possibile segmentare un da-taset in diversi gruppi di individui in base ai valori da loro assunti su una serie di variabili. A differenza degli alberi decisionali in cui si prevede una variabile obiettivo, nella cluster analysis non si pre-vede nulla, ma si cerca una ripartizione ottimale degli individui. Il

Figura 3.22Componenti di rosso

raccolte in istogrammi per trenta sezioni, dalla 1.001 alla 1.301 con uno

step di 10, del Visibile Human Male Dataset

Figura 3.23Lo stesso insieme di

istogrammi mostrato nell’immagine

precedente è stato ruotato e traslato.

Per evidenziare meglio i picchi e gli

avvallamenti, inoltre, gli assi sono stati

normalizzati

criterio di ottimo è quello di avere, in ogni gruppo, individui il più possibile simili tra loro. Tra gli algoritmi più utilizzati c’è il metodo delle K medie (Figura 3.24): è un algoritmo di clustering non gerar-chico in cui le variabili utilizzate sono di tipo quantitativo e come criterio di somiglianza tra le due unità si considerata la distanza calcolata su tali variabili. L’algoritmo associa un individuo al cluster fra i K disponibili a cui esso è più vicino e il numero K di cluster in output deve essere specificato preventivamente.

• Reti NeuraliCercano di riprodurre il processo di apprendimento del cervello umano. Le reti vengono costruite per prevedere il valore assunto da una variabile obiettivo e sono caratterizzate da strati di neuroni (Figura 3.25). Tutti i neuroni di uno strato sono collegati a ogni neurone dello strato successivo mediante connessioni a cui sono associati dei pesi. Lo strato di input associa i neuroni alle variabili attive dell’analisi, lo strato di output associa uno o più neuroni alla variabile target (in base alla sua natura).

Il tipo più diffuso di rete neurale ha un metodo di apprendimen-to backpropagation: riceve in input un’unità, in base ai pesi iniziali associati ai neuroni formula una previsione e confronta il valore previsto con il valore reale. In caso di errore rivede i pesi associa-ti alle varie connessioni partendo dagli ultimi strati fino a tornare allo stato di input. Le condizioni per fermarsi possono dipende-re dall’accuratezza di previsione richiesta, dal numero di iterazioni (passaggi attraverso la rete dei dati) o dal tempo trascorso dall’inizio della costruzione del modello.

• Alberi di Decisione La costruzione di modelli sulla base di alberi decisionali ha lo scopo di ripartire un dataset in una serie di passi. La ripartizione avviene

1. K=2, Arbitrarily choose K object as initial cluster center2. Assign each objects to most similar center3. Update the cluster means4. Reassign5. Update the cluster means6. Reassign

Figura 3.24Esempio di metodo delle K medie Adattato da [Wang, 2009]

in base alle relazioni che legano la variabile target che si cerca di prevedere, e una serie di variabili utilizzate come predittori. Il ri-sultato del modello può essere rappresentato da un set di regole per ottenere i valori della variabile target o da una struttura ad albero (Figura 3.26). Gli elementi strutturali sono:

• nodi, cioè la rappresentazione grafica di una valutazione sul valore delle varaibili;

• archi, cioè i collegamenti tra i nodi;• foglie, cioè la rappresentazione dei risultati della classifica-

zione.• Individuazione di Associazioni Le regole di associazione permettono lo studio di accadimenti si-multanei di eventi o di sequenze di eventi. Le regole hanno la forma:

Condizione 1 – Condizione 2 - …. Condizione n. → Conclusione

Associati a ogni regola ci sono poi una serie di indicatori come il supporto e la confidenza. Il supporto indica la frequenza assolu-ta del verificarsi della regola rispetto a tutte le transazioni presenti nel dataset, la confidenza è un rapporto che indica quante volte in percentuale si verifica la conclusione quando sono verificate le condizioni.

Non c’è un criterio standard per definire “interessante” una re-gola in quanto si possono fare valutazioni sia sul supporto che sulla confidenza e comunque occorre una buona conoscenza del feno

age < 30

30 < age < 50

age < 50

Hidden layers

Input nodes

Output nodes

car_mag

sports_mag

house_mag

music_mag

comic_mag

Figura 3.25Esempio di rete neurale.Adattato da [Adriaans e Zantinge, 1996] pag.71

Figura 3.26Esempio di albero

decisionale

High Risk

SmokerLow Risk

Low Risk

<20 >20

Yes No

Tabella 3.1Esempi di transazioni, di regole e loro attributi

Transaction ID Objects Rules100 A B C Regola A ⇒ C

Support = 50%Confidence = 66,6%200 A C

300 A D Regola C ⇒ ASupport = 50%

Confidence = 100%400 B E F

meno studiato per dividere le regole imprevedibili e interessanti da regole note che non portano alcuna informazione aggiuntiva.

3.3.4 Applicazioni

Applicazioni più comuniDi seguito sono illustrate alcune delle applicazioni più comuni.Segmentazione della clientela (Database Marketing) - applicazione di tecniche di clustering al fine di individuare gruppi omogenei in ter-mini di comportamento d’acquisto e di caratteristiche socio-demo-grafiche; l’individuazione delle diverse tipologie di clienti permette di effettuare campagne di marketing diretto e di valutarne gli effetti, nonché di ottenere indicazioni su come modificare la propria offer-ta, e rende possibile monitorare nel tempo l’evoluzione della propria clientela e l’emergere di nuove tipologie.

Analisi delle associazioni (Basket Analysis) - applicazione di tecniche di individuazione di associazioni a dati di vendita al fine di cono-scere quali prodotti sono acquistati congiuntamente; questo tipo d’informazione consente di migliorare l’offerta dei prodotti (dispo-sizione sugli scaffali) e di incrementare le vendite di alcuni prodotti tramite offerte sui prodotti ad essi associati.

Analisi testuale (Text Mining) - applicazione di tecniche di cluste-ring al fine di individuare gruppi omogenei di documenti in termini di argomento trattato; consente di accedere più velocemente all’ar-gomento di interesse e di individuarne i legami con altri argomenti.

Technology Watch (Competitive Intelligence) - applicazione di tecni-che di clustering a banche dati di tipo tecnico-scientifico al fine di individuare i gruppi tematici principali (nel caso di banche dati di brevetti, un gruppo tematico indica una particolare tecnologia), le loro relazioni, l’evoluzione temporale, le persone o le aziende coin-volte.

Applicazioni nell’HealthcareNumerose sono le applicazioni delle tecniche di Data Mining in

ambito biomedico: per fornire un quadro più dettagliato riportia-mo i risultati di un’analisi volta appunto a individuare le aree di maggiore interesse. Per fare questo sono stati analizzati 70 articoli pubblicati su importanti riviste scientifiche o riportati all’interno di atti di congressi.

La ricerca è stata effettuata tramite PubMed (http://www.ncbi.nlm.nih.gov/PubMed), utilizzando le seguenti parole chiave:• Data Mining• Data Mining Clinical Warehouse• Data Mining Drugs• Data Mining Genome• Data Mining Knowledge Discovery• Data Mining Medical Records• Data Mining Microarrays• Data Mining Proteins• Data Mining Records• Data Mining Tumor• Data Mining Warehouse• Clinical Data Mining

I 70 articoli individuati sono stati organizzati in un database (Figura 3.27) secondo il seguente schema:

Tutti gli articoli sono stati analizzati secondo lo schema di Tabella 3.2.

I campi di applicazione (Figura 3.28) più frequenti sono risultati essere:• applicazioni mediche;• applicazioni nella ricerca genomica.Oltre a:• applicazioni sanitarie;• studi proteomici.

Analysis

ObjectivesData EnviromentTechniquesResults - ObjectivesResults - Techniques

CodeArticle TitleJournal TitleJournal TypeYearKeywords

Authors

CodeAuthor

Figura 3.27 Organizzazione del

Database con gli articoli individuati nella ricerca

Using data mining to characterize DNA mutations by patient clinical features

L’applicazione ad un campione di pazieti pota alla deduzione di regole utili nella scelta preliminare di test genetici da effettuare.

Viene analizzata una serie di informazioni presentate in una matrice le cui righe rappresentano i pazienti. Vengono ricercate delle regolarità nei dati selezionando per ogni riga gli elementi maggiormente rappresentativi e creando una o più espressioni booleane che caratterizzino gli esempi positivi.

DB contenenti dati di pazienti con indi-cazioni riguardanti le malattie, l’età in cui sono comparse, eventuali fattori di rischio ecc.In particolare i dati riguardano lo storico e gli attributi relati-vi a casi di cancro.

Il metodo può essere migliorato selezionando in modo opportuno attributi clinici più significativi di altri. É un metodo che può essere efficace-mente utilizzato dai clinici per migliorare il monitoraggio e la prevenzione del cancro.

Correlare carat-teristiche cliniche specifiche derivanti dall’anammesi familiare relativa a casi di cancro con mutazioni presenti nel DNA, allo scopo di facilitare la scelta di eventuali test di labo o viceversa predire le caratteri-stiche del paziente.

Autom ated detection of hereditary syn-dromes using data mining

Il metodo rende pos-sibile la derivazione di regole da un in-sieme di dati tali da descrivere sindromi ereditarie.

Estrapolazione di regole che caratte-rizzano gli esempi positivi nell’insieme dei dati.

DB contenente la storia di una fami-glia con attibuti che la descrivono dal punto di vista delle malattie (età di occcorrenza, tipo, durata, ecc.)

Messo a confronto con le valutazioni di un esperto il metodo identifica in modo opportuno eventuali sindromi ereditarie in linea con le deduzioni dello specialista.

Descrizione e valutazione di un si-stema per la costru-zione automatica di regole che possano identificare pattern di disordini/sindromi ereditarie.

Mining the National Cancer Institute Anticancer Drug Discovery Database: cluster analysis of ellipticine analogs with p53-inverse and central nervous system-selective pattens of activity

Identificati due sot-togruppi di composti con proprietà simili.

Clustering gerarchico in base alla simile attività dei composti.Average linkage clustering (la distanza tra due cluster è la media tra le distan-ze tra i singoli punti di ciascuno.

DB di composti chimici. In particolare dati relativi alla attività antitumorale dei composti (in relazione a diverse tipologie di tumore) nonchè informazioni sulla struttura chimica.

Scelte differenti riguardanti il metoo di clustering (average, single e complete linkage) ed il tipo di distanza (euclidea, 1-r con r coeff. di correl. di Pearson) danno risultati simili.

Valutazioni delle attività di composti antitumorali.

Title Results - Objectives

TechniquesData Environment

Objectives Results - Techniques

Tabella 3.2Tabella di analisi degli articoli

In particolare, le applicazioni mediche (Figura 3.29) più frequenti sono:• diagnosi: ricerca e applicazioni di regole per la diagnosi pre-

coce;• reperimento di informazioni: velocizzare e semplificare la ri-

cerca di informazioni nei database;• sistema di supporto alle decisioni: ricerca e applicazione di re-

gole al processo decisionale;• analisi automatica di documenti testuali: ricerca di conoscenza

nei database.Le applicazioni più frequenti nella ricerca genomica (Figura 3.30) sono invece:• reperimento di informazioni;• identificazione di geni: ricerca e applicazioni di algoritmi per

identificare sequenze di geni;• classificazione: ricerca di criteri per distinguere dati in set

omogenei.Le tecniche maggiormente utilizzate (Figura 3.31) sono:

Medicine

Health Care Genome Research

Proteomic Studies

454035302520151050

Figura 3.29Applicazioni mediche

del Data Mining.Sull’asse verticale è

riportato il numero di articoli

Decision ClassificationSupport

Risk Factor Analysis

Automatic Text Analysis

1614121086420

Diagnosis Information Retrieve

Medicine Applications

Figura 3.28Campi di applicazione

del Data Mining nell’Healthcare.

Sull’asse verticale è riportato il numero di

articoli

Information Identification

ClassificationRetrieve

Gene Diagnosis/ Decision Support

9876543210

Genome Research Applications

Sequence Comparison

Decision Trees

Association Rules

Visualization

Techniques

Clustering Genetic Algorithms

Neural Networks

Rule Induction

Information Retrieval

Figura 3.30Applicazioni nella ricerca genomica.

Sull’asse verticale è riportato il numero di

articoli

Figura 3.31Tecniche di Data Mining

utilizzate.Sull’asse verticale è

riportato il numero di articoli

3.3.5 ConclusioniAbbiamo visto come le numerose tecniche di Data Mining possano essere utilizzate in diversi ambiti di applicazione e in ognuno di essi sono riscontrabili diversi vantaggi:• trattamento di dati quantitativi, qualitativi, testuali, immagini

e suoni;• non richiede ipotesi a priori da parte del ricercatore;• non richiede ipotesi sulla forma distributiva delle variabili;• possibilità di elaborare un numero elevato di osservazioni;• possibilità di elaborare un numero elevato di variabili;• algoritmi ottimizzati per minimizzare il tempo di elaborazione;• semplicità di interpretazione del risultato;• visualizzazione dei risultati.

3.4 Catalogo di prodotti software open source per la medicina

L’attività del software open source (Open Source Software, OSS) è un modello di sviluppo, di diffusione e di cooperazione nel campo-dell’ Information Tecnology (IT).

Nel caso di progetti finanziati con fondi pubblici, il suo scopo principale è quello di facilitare a tutti l’accesso gratuito ai risulta-ti, questi tipicamente costituiti da pacchetti software, programmi sorgente inclusi, possono soddisfare in misura significativa molte specifiche esigenze di svariati utenti.

Nel caso di progetti finanziati con fondi privati, pur se con mino-re frequenza, può permanere un interesse alla distribuzione gratuita, come azione di marketing, che di solito non include i programmi sorgente [Grasso, 2002].

3.4.1 Breve storia dell’Open Source

In origine il termine “software” (SW) veniva usato per identifica-re quelle parti di un sistema di calcolo che fossero “modificabili” liberamente tramite differenti configurazioni di cavi e spinotti, diversamente dall’hardware (HW) con cui si identificava la com-ponentistica elettronica. Successivamente all’introduzione di mezzi linguistici atti ad alterare il comportamento del computer, SW prese il significato di “espressione in linguaggio convenzionale che de-scrive e controlla il comportamento della macchina”. In particolare occorre notare che ogni macchina aveva un suo proprio linguaggio convenzionale, comunemente detto Assembler.

Nella relativamente breve storia dell’Information Technology, tutte le società produttrici di HW hanno cominciato a fornire, as-sieme all’Hardware della macchina, un certo numero di program-mi in grado di svolgere le funzioni di base. Inizialmente si parlava di Monitor, poi di Supervisori, infine è stato adottato il nome di “Sistema Operativo”. Tali programmi erano scritti sempre in As-sembler cioè nel linguaggio specifico della macchina, costituito da sequenze binarie di 0 e di 1.

Un’eccezione a tale regola è stata il sistema operativo UNIX, re-alizzato da un’organizzazione che non produceva HW, e precisa-mente i Laboratori Bell, e che pertanto fu progettato fin dall’inizio per risultare indipendente dalla specifica piattaforma HW su cui era stato inizialmente scritto. Non solo, i progettisti iniziali dello UNIX, proprio per renderlo indipendente dalla piattaforma har-dware, svilupparono un linguaggio, conosciuto come “linguaggio

C”, che contiene costrutti della programmazione strutturata (come i cicli FOR e DO…WHILE, le clausole IF…THEN…ELSE, ecc.) oltre a permettere la gestione precisa delle locazioni di memoria, possibili con l’Assembler.

Un’altra peculiarità è che avendo allora (anni ’70) la Bell una causa in corso per violazione della legge statunitense sui monopoli, lo UNIX veniva inizialmente distribuito corredato dei codici sor-genti. Questo permise ad altri di portare il sistema UNIX stesso su piattaforme diverse da quelle usate dai Laboratori Bell e ne causò una rapidissima diffusione fra le comunità dei ricercatori e degli svi-luppatori. Non solo: la disponibilità dei codici sorgenti permetteva a chiunque di contribuire al miglioramento ed all’espansione delle funzioni del sistema operativo.

In pratica si formò una comunità di sviluppatori volontari, in genere dell’ambiente universitario, ma non solo, che contribuì in un modo di operare che potremmo definire “collaborativo”, alla cresci-ta dello UNIX.

Nel 1984 la Bell perse la causa e la proprietà dei laboratori passò all’AT&T che iniziò a rivendicarne i diritti, cioè incominciò a chie-dere delle royalty, ma soprattutto mise un freno alla distribuzione dei codici sorgenti.

Ne seguì una battaglia per i diritti di proprietà dello UNIX che durò una decina d’anni. Un folto gruppo di costruttori di sistemi informatici costituirono la Open Software Foundation, con l’obiet-tivo di farla diventare la proprietaria del software di base comune a tutti e sul quale tutti avrebbero costruito il loro sistema UNIX.

Il risultato fu che quell’unico UNIX divenne una molteplicità di Sistemi Operativi: AIX, Digital UNIX, HP-UX, Sinix, Irix, UNIX 386, ecc.

Il progetto GNU e la Free Software Foundation La principale conseguenza della scomparsa della Bell e della trasfor-mazione di UNIX in tanti sistemi proprietari fu che la comunità di programmatori formatasi spontaneamente in quegli anni, si trovò impossibilitata a lavorare. Uno degli hacker (l’uso recente della pa-rola hacker con il significato di “pirata informatico” è una deforma-zione dovuta ai mass media; i veri hacker rifiutano questo significato e continuano a usare la parola intendendo “qualcuno a cui piace programmare e gode nell’essere bravo a farlo”) più lungimiranti, Richard M. Stallman ricercatore presso il Laboratorio di intelligen-za artificiale del Massachusset Institute of Technology (MIT), nel 1985 diede origine al progetto GNU e alla Free Software Funda-tion. L’acronimo GNU significa “GNU is Not Unix” ad indicare

che l’evoluzione che aveva seguito il sistema operativo UNIX era sbagliato [Williams, 2002].

La Free Software Fundation si occupava e si occupa tuttora di eliminare le restrizioni sulla copia, sulla ridistribuzione, sulla com-prensione e sulla modifica dei programmi per computer, concen-trandosi in particolare sullo sviluppo di nuovo software libero in-serendolo in un sistema coerente che possa eliminare il bisogno di utilizzare software proprietari.

Stallman si premurò anche di concepire un’infrastruttura legale entro cui il sistema GNU potesse prosperare. Introdusse la licenza GPL, GNU Public License o General Public License (consultabile su ww.gnu.org), che garantisce le seguenti libertà:1. libertà di eseguire il programma per qualunque scopo, senza

limitazione;2. libertà di adattare il programma alle proprie necessità (l’acces-

so ai codici sorgenti è condizione essenziale);3. libertà di copiare il programma senza limitazione;4. libertà di distribuire le copie modificate (l’accesso ai codici sor-

genti è condizione essenziale).Oltre a questi diritti, stabilisce un dovere: tutte le modifiche a sof-tware licenziato con la GPL devono essere rilasciate con la stessa licenza. La GPL è, quindi, una licenza persistente.

Tale licenza, usando intelligentemente le leggi sul diritto d’au-tore, ne rovescia il significato per mantenere il software libero e ac-cessibile a tutti, come bene universale, utilizzabile senza restrizione dall’intelletto umano, né più né meno come un teorema matemati-co o una teoria scientifica.

Il concetto di Copyleft-all rights reversed (gioco di parole con Copyright-all rights reserved) è stato stabilito nelle quattro libertà e nel dovere sanciti nella GPL e che vengono concessi (left, participio passato di leave) [De Laat, 2005].

Come detto un programma è software libero se l’utente ha i quat-tro tipi di libertà sopra elencati. In particolare, se è libero di distri-buire copie con o senza modifiche, gratis o addebitando delle spese di distribuzione a chiunque e ovunque. Essere liberi di fare queste cose significa, tra l’altro, che non bisogna chiedere o pagare nessun permesso. Bisogna anche avere la libertà di fare modifiche e usarle privatamente nel proprio lavoro o divertimento senza doverlo dire a nessuno. Se si pubblicano le proprie modifiche, non si deve essere tenuti a comunicarlo a qualcuno in particolare o in qualche modo particolare. La libertà di usare un programma significa libertà per qualsiasi tipo di persona o organizzazione di utilizzarlo su qualsiasi tipo di sistema informatico, per qualsiasi tipo di attività e senza

dover, successivamente, comunicare con lo sviluppatore o qualche altra entità specifica. La libertà di distribuire copie deve includere le forme binarie o eseguibili dei programmi e anche il codice sor-gente, sia per le versioni modificate che non modificate. Affinché la libertà di fare modifiche e di pubblicare versioni migliorate ab-bia senso, si deve avere accesso al codice sorgente del programma. Perciò, l’accessibilità al codice sorgente è una condizione necessaria per il software libero. Queste libertà per essere reali devono essere irrevocabili fin tanto che non si fa qualcosa di sbagliato: se lo svilup-patore del software ha il potere di revocare la licenza anche senza che l’utente sia causa di tale revoca, il software non è libero. Tuttavia, certi tipi di regole sul come distribuire il software libero sono accet-tabili quando non entrano in conflitto con le libertà principali. Ad esempio il copyleft, come già detto, cioè la regola per cui quando un programma è ridistribuito non è possibile aggiungere restrizioni per negare ad altre persone le libertà prinicipali, è una regola che non entra in conflitto con le stesse, anzi le protegge. È importante a questo punto chiarire alcuni aspetti delle licenze software. Come tutti i tipi di software, cioè sia di quello libero che quello non libero, la tutela dell’opera è sottoposta alla normativa sul diritto d’autore (copyright) e quindi la distribuzione viene regolata da una licen-za. Generalmente questa licenza viene usata per limitare le azioni dell’utente e garantire solamente l’autore. Le licenze del software proprietario come per esempio l’EULA (End-User License Agree-ment) di Microsoft impongono restrizioni a quello che si può fare con il programma che si acquista:• la copia non è permessa;• non è possibile modificare il codice e ridistribuire eventuali

modifiche;• non è ovviamente possibile studiare il funzionamento del pro-

gramma poiché i sorgenti sono segreti;• in alcuni casi ci sono restrizioni anche su come usare il sof-

tware.Al contrario nella comunità del software libero il copyright viene sfruttato per garantire all’utente finale le quattro libertà fondamen-tali.

Il Kernel LINUX La Free Software Foundation si occupò di riscrivere tutto il sistema UNIX per non dovere royalty a nessuno. Tutti i componenti ve-nivano però innestati su un Kernel UNIX, essendo il progetto del Kernel GNU (di nome Hurd) non ancora completato. A tutt’oggi il Kernel Hurd è ancora in fase di sviluppo.

Nel 1990 uno studente ventenne dell’Università di Helsinki, Li-nus Torvalds, non avendo i soldi sufficienti a istallare sul suo nuovo PC il tradizionale UNIX e ritenendo il vecchio DOS di Microsoft non adatto a sviluppare software di alto livello (in particolare, la programmazione di “processi” concorrenti), decise di scrivere da solo il nucleo di un nuovo sistema operativo, un clone di UNIX, per dotare il suo PC delle funzionalità di base di un elaboratore di fascia alta.

Il 25 agosto 1991 Linus Torvalds annunciò il suo progetto di ker-nel UNIX-like (“non un progetto professionale come GNU” diceva il suo messaggio) e chiedeva suggerimenti su quali funzioni erano ritenute interessanti; fornì, quindi, questi kernel in seguito ribat-tezzato LINUX, alla Free Software Fondation. Nasce così il nucleo del nuovo sistema operativo, versione 0.01. Tale nucleo gestisce i “file”, ossia i documenti, e il “file system”, ossia l’organizzazione gerarchica dei documenti in cartelline e cartellone, con la stessa lo-gica di UNIX è dotato della funzionalità di emulazione di terminale e contiene alcuni “driver” di base per pilotare le unità periferiche. Sostituendo la consonante finale del proprio cognome con la “x” di UNIX, Linus Torvalds battezza il suo prodotto “LINUX”, e fa così una prima scelta felice, ma ancora più felice e importante è la seconda scelta, quella di diffondere il nuovo sistema operativo su Internet, mettendo a disposizione di chiunque sia interessato a uti-lizzarlo, senza chiedere altra contropartita oltre alla collaborazione per migliorarlo ed espanderlo [Amadori et al., 2002]. Il suo invito è raccolto da centinaia di giovani programmatori in tutto il mondo che nell’arco di pochi anni, in un telelavoro collettivo guidato da quello splendido organizzatore che si rivela Linus Torvalds, trasfor-mano un interessante prototipo scientifico in una vera e propria linea di prodotti industriali.

Il sistema GNU/Linux (l’insieme del kernel Linux e delle com-ponenti del progetto GNU) oggi è un sistema operativo completo e funziona su un numero notevolissimo di piattaforme hardware. Senza campagne pubblicitarie sponsorizzate da organizzazioni com-merciali, ma solo per forza sua, è arrivato in pochi anni ad oltre dieci milioni di installazioni nel mondo. In particolare si stima che Linux sia il motore di oltre sei milioni di server Web in Internet.

Software Libero (Free software) ovvero “Open Source”Un altro nome per il software libero è “Open Source”. Questo ter-mine è nato il 3 febbraio 1998 in una riunione a Palo Alto, Califor-nia, a cui partecipavano Todd Anderson, Chris Peterson (del Fore-sight Institute), John “maddog” Hall e Larry Augustin (ambedue di

Linux International), Sam Ockman (del Silicon Valley Linux User’s Group) e Eric Raymond. Il concetto venne sviluppato durante una discussione sul doppio significato, in inglese, della parola “free”: se usata nella frase “free beer tonight”, significa “gratis”, ma se usato come nel primo emendamento della Costituzione Americana come il concetto di “free speech right” allora significa “diritto alla libertà di parola”.

Per evitare questa possibile confusione fu coniato, nonostante il parere contrario di molti “Guru” (tra i quali ricordiamo Richard M. Stallman) il termine “Open Source”, dato che la parola “free” aveva la particolarissima capacità di far preoccupare e tremare qual-siasi imprenditore. Oltretutto il mondo del software libero ha come principale priorità quella di salvaguardare la libertà dell’utente, sa-crificando quindi altri aspetti, primo fra tutti l’ambito economico. Per cercare di risolvere questa frattura venne convocata la riunione sopra menzionata. In nuovo termine fu scelto appositamente per evitare ogni ambiguità, con il preciso intento di portare il free sof-tware nel mondo degli affari. Con questa decisione si eliminò com-pletamente la carica ideologica che tanto era cara al movimento, ma che contemporaneamente era malvista dall’industria, concen-trandosi esclusivamente sui vantaggi pratici che può portare lo svi-luppo di un software lasciando il codice sorgente a disposizione di chiunque. Le argomentazioni a favore dell’Open Source, non sono più quindi la libertà concessa all’utente, ma la maggiore affidabilità e sicurezza, la conformità agli standard, la facilità di adattamento alle proprie esigenze e l’indipendenza dai singoli fornitori [Evers, 2000]. La voluta e ricercata neutralità del movimento Open Source nei confronti degli aspetti etici del software libero, è la caratteristica fondamentale che lo distingue dal Free Software che pone, invece, l’accento su motivazioni ideologiche. Nonostante queste differenze, che spesso sono state oggetto di accese discussioni fra le due parti in causa, nella pratica i due movimenti hanno mezzi e obiettivi co-muni. Nella realtà, infatti, le licenze software accettate dall’Open Source Initiative (OSI) sono le stesse accettate anche dalla Free Software Foundation (con rarissime e poco significative eccezioni). Entrambi i movimenti si basano quindi sulla libertà di accesso al codice sorgente, sulla possibilità di poterlo liberamente modificare e poterlo ridistribuire altrettanto liberamente. A conferma di que-sto, attualmente i termini Free Software e Open Source sono soli-tamente usati come sinonimi. Anche se ciò non è formalmente ed ideologicamente corretto, la cosa è comunque accettabile, purchè si abbiano ben chiare le differenze tra i due movimenti.

3.4.2 Vantaggi del software libero

Il Software Libero è più affidabile e più efficienteIl vantaggio principale del software libero non consiste, come invece molti vogliono credere, nel fatto che è a basso costo, perché si può copiare senza limiti e senza royalty. Il vantaggio principale sta nella sua robustezza. Questa robustezza è dovuta al modo come viene svi-luppato il software, che è diverso dal modo di sviluppo del software proprietario.

I moduli del software libero vengono sviluppati da poche perso-ne, spesso da una sola persona, ma poi, invece di essere protetti e tenuti nascosti, come accade per il software proprietario, vengono pubblicati in Internet dove sono a disposizione di tutti i program-matori che desiderano rendersi utili verificando software altrui. In pratica il software viene sottoposto a decine, centinaia di revisioni da parte di professionisti. Eventuali buchi o debolezze vengono evi-denziati molto prima che possano emergere durante il funziona-mento. Volendo banalizzare si tratta dell’applicazione del vecchio proverbio “quattro occhi vedono meglio di due”, che in questo caso diventa, in inglese, “Many eyes make all bugs shallow”.

Per lo stesso motivo il software libero può essere anche più effi-ciente. Se un hacker, inteso come professionista del software, esa-minando una porzione di codice si accorge che esiste un modo più efficiente di risolvere un problema, molto probabilmente lo comu-nicherà alla comunità degli sviluppatori, magari inviando la parte di codice già corretta.

Alla lunga questo meccanismo spontaneo porta a software robu-sti ed efficienti. Nel mondo del software libero, inoltre, il software viene rilasciato senza l’ansia di rispettare le scadenze di annuncio, tipiche del mondo del software proprietario. Non esiste un team di marketing che, avendo già annunciato delle nuove funzionalità, fa pressione sugli sviluppatori perché le date preannunciate siano rispettate. L’obbiettivo è mettere a disposizione del software che funzioni bene, non del software che sia disponibile a una data pre-fissata. Anzi, lo sviluppatore ha interesse a rilasciare del sofware che funzioni bene perché non c’è nessun guadagno a distribuire delle correzioni, a differenza di quanto invece avviene con gli aggiorna-menti di software chiuso e proprietario.

Il Software Libero è più sicuroNel software libero non possono esistere backdoor, cioè punti di ingresso conosciuti solo da chi ha sviluppato il codice. Essendo i codici sorgenti a disposizione di tutti, la presenza di un backdoor

verrebbe segnalata in tempi brevi. Ovviamente, tutte le volte che si installa del software libero già compilato non ci può essere alcuna garanzia che uno sviluppatore malintenzionato non abbia inserito del codice non conforme ai sorgenti pubblici. Alla lunga, però, di-fetti di questo genere vengono scoperti e possono essere corretti, dato che il codice sorgente originale è sempre a disposizione per essere ricompilato.

È accaduto, per esempio, che le installazioni di un noto Data Base Relazionale proprietario contenessero un problema riguar-dante la sicurezza degli accessi al Data Base, perché banalmente gli sviluppatori avevano lasciato nel codice una backdoor di cui poi si erano dimenticati. Quando il Data Base è diventato libero ed è stato messo a disposizione di tutti in formato sorgente, l’errore è stato scoperto e corretto nel giro di pochi mesi.

Il Software Libero garantisce la scelta del fornitoreAl di là delle questioni tecniche finora elencate, il vantaggio prin-cipale del software libero sta nella libertà di scelta: il cliente può davvero liberamente scegliere il fornitore di software o di servizi migliore disponibile sul mercato.

Forse paradossalmente, la massima libertà di scelta favorisce an-che i fornitori stessi. Di primo acchito sembra che con il software libero per un cliente sia più semplice abbandonare un fornitore per un altro, ma questo significa anche che il cliente non è spaventato a dover lavorare con una piccola ditta che egli teme possa sparire in cinque o dieci anni. Molti piccoli sviluppatori software temono di perdere i loro già piccoli guadagni se sviluppassero software libero. In realtà molti programmatori e case di sviluppo vivono dignitosa-mente scrivendo e vendendo software libero, in un mercato in cui le loro scelte sono veramente libere.

Il software libero abbassa la barriera all’ingressoIl software libero per sua natura abbassa le barriere di ingresso al mercato e questo può certamente essere salutato come un lieto evento da parte degli sviluppatori e degli utenti. Gli utenti avranno in tale modo la possibilità di ridurre i costi fissi legati alle loro so-luzioni salvaguardando, quindi, una maggiore liquidità all’acquisto di servizi per lo sviluppo di nuove soluzioni. Il fiorire di società che stanno migrando o sviluppando applicazioni su Linux così come l’affermarsi di palmari basati sul kernel Linu lo dimostra.

Le imprese libere sono compensate con vendite e profitti per aver legalmente e correttamente soddisfatto gli acquirenti. Il software li-bero in quanto tale viene venduto a prezzi talmente bassi che i gua-

dagni più significativi vengono fatti vendendo servizi e assistenza o soluzioni. RedHat Suse, Caldera, TurboLinux e Mandrake sono alcuni esempi di aziende che si guadagnano da vivere con il software libero.

L’alternativa al software libero è la sorveglianza, ovvero assicurarsi che il software non sia usato o copiato illegalmente. Parlando in generale, la parola “sorveglianza” non è usata, si sente invece parlare di “controllo licenze” o frasi simili.

3.4.3 Svantaggi del software libero

Una domanda che divide gli utilizzatori dei programmi informatici, e non solo quelli medici, è: conviene installare un software gratuito, open source, o uno a pagamento?

Il programma gratuito offre ciò che nessun software acquistato può offrire: la possibilità di provare liberamente la versione oppure di disinstallarla liberamente, senza rimetterci un soldo in caso di insoddisfazione.

In caso di software a pagamento, invece, oltre al costo iniziale dato dall’acquisto del programma, va attentamente valutato quello degli aggiornamenti che devono spesso essere acquistati direttamen-te dalla ditta produttrice o pagati con un canone mensile o annuale.

Paradossalmente, l’utente del software gratuito è sempre quel-lo più libero. Infatti, oltre a quanto già visto, il passaggio da un programma gratuito a uno acquistato comporta solo la necessità di trasferire gli archivi da un formato all’altro. Nel passaggio inverso (da uno a pagamento a uno gratuito), pur rimanendo identica la necessità di trasferire gli archivi, si avrebbe la perdita secca dell’inve-stimento economico effettuato.

Tuttavia, ci sono diversi motivi per preferire l’acquisto di un pro-gramma proprietario:• chi paga un prodotto ha maggiori possibilità di essere ascoltato

per eventuali richieste di chiarimenti o lamentele rispetto a chi questo prodotto lo riceve in regalo;

• il mercato dei software medici esiste già da tempo e ha selezio-nato i prodotti migliori, di lungo respiro e calzanti alla specifi-cità della medicina generale (spesso grazie al contributo, negli anni, di centinaia di utenti). Inoltre la concorrenza reciproca di tali programmi garantisce il continuo miglioramento e la competizione a vantaggio degli utenti;

• in campo medico i continui cambiamenti legislativi riguardo al prontuario e alle norme prescrittive e l’affinamento dell’uten-te, che chiede sempre di più al software man mano che lo usa,

implicano quell’aggiornamento rapido e completo che solo i programmi a pagamento possono vantare;

• un programma a pagamento, soprattutto tra quelli selezionati da anni di presenza sul mercato e da un grande numero di utenti, offre migliori garanzie di continuità e stabilità nel tem-po rispetto a strategie, legittimamente variabili, di chi produce e distribuisce software gratuiti.

Falsi miti sul software liberoÈ opportuno sfatare alcuni falsi miti che, per diversi motivi, si sono consolidati negli anni, nel pensiero comune sul software libero:• il software libero è gratuito: nonostante in molti casi il Free

Software sia liberamente scaricabile da internet senza nessun costo aggiuntivo, libertà e gratuità sono due aspetti distinti. Esistono infatti diverse aziende che hanno impostato il loro business su questo tipo di software;

• il software gratuito è libero: stesso discorso precedente. Esisto-no moltissimi software scaricabili gratuitamente da internet che non garantiscono nessuna delle quattro libertà formulate dal progetto GNU;

• il software libero è privo di copyright: anche questo è falso. Semplicemente la proprietà intellettuale su un software è usata in modo diverso da quello tradizionale [Berra e Meo, 2006]. A conferma di questo, basti pensare a quanti programmatori sono diventati famosi grazie al Free Software; la comunità rico-nosce sempre il lavoro e l’impegno di ogni singolo individuo;

• il contrario di libero è commerciale: sbagliato! Il suo vero con-trario è proprietario. La possibilità di commercializzare un programma non dipende dalla licenza utilizzata. Non è una questione di prezzo;

• il software libero non offre garanzie: questo invece è verissimo. Peccato che nemmeno il software proprietario offra nessuna garanzia: quando si acquista un programma proprietario (ma-gari anche molto costoso), la licenza non ci garantisce che quel software svolga realmente e correttamente una funzione, nem-meno quella per cui è stato venduto.

3.4.4 Ricerca di software Open Source: criteri e modalità di lavoro adottati

IntroduzioneInternet ha portato un notevole cambiamento nelle modalità di ri-cerca. L’aumento esponenziale dei suoi utenti, solo in Italia circa

10 milioni di persone, con una crescita che tende a continuare, ha prodotto una ricchezza di contenuti mai riscontrata prima.

I principali vantaggi riscontrabili nell’uso del World Wide Web allo scopo di ricercare sono:• velocità: Internet offre per esempio la possibilità di consultare

grosse banche dati (paragonabili a gigantesche biblioteche) in pochi secondi;

• comodità: la rete è consultabile pressochè da qualsiasi posto ove possa esserci la possibilità di un collegamento evitando all’utente spostamenti che potrebbero variare da poche decine di metri a migliaia di chilometri;

• completezza: su Internet si trova ormai la quasi totalità degli argomenti;

• interattività: viene permesso all’utente la possibilità non solo di accedere ai dati ma di essere lui stesso protagonista immet-tendo nell’Web informazioni che fanno parte del proprio ba-gaglio culturale.

Internet ha, però, anche lo svantaggio di essere paradossalmente troppo ricco di contenuti: a volte cercare il documento desiderato, soprattutto per un utente poco esperto, può diventare paragonabile alla ricerca dell’ago nel pagliaio. Non si può pretendere di trovare informazioni su Internet in pochi minuti: al pari del tempo che si dedica, per esempio, a una ricerca in una biblioteca, Internet, a causa della sua enormità, richiede tempo e pazienza.

I consigli per il miglior uso della Rete vengono dalla Rete stessa: quando ci si approccia ad un motore di ricerca, per esempio, è bene innanzitutto andare a leggere la pagina di aiuto in cui vengono de-scritte le modalità di ricerca proprio del motore.

È bene poi ricordarsi che anche i più “grandi” motori di ricerca non riescono ad avere nel proprio catalogo più del 20-25% del to-tale dei siti Web presenti in rete, pertanto è consigliabile, durante la ricerca di un documento, consultarne più di uno.

Esistono infine dei motori di ricerca “specializzati”, ossia che si occupano di catalogare solo siti di una particolare area tematica (come nel nostro caso la medicina).

Qui è utile fare un distinguo: sulla Rete troviamo “motori indi-cizzati per argomento” e “motori indicizzati per parole”.

La differenza tra le due tipologie di strumenti si basa sul modo di interrogare il database: mentre nel primo caso i link sono orga-nizzati su più livelli in base all’argomento (per esempio esiste l’argo-mento “oncologia” e al suo interno l’argomento “chemioterapia”), nel secondo caso il database può essere interrogato attraverso parole chiave o una loro combinazione.

Utile può risultare anche la consultazione dei “portali”. In essi tro-viamo links a siti che trattano dell’argomento a cui il portale è de-dicato con una descrizione delle risorse che ognuno di questi siti mette a disposizione.

Infine, una volta trovata l’informazione che tratta dell’argomen-to desiderato, è bene sempre valutarne il contenuto attraverso dei principi di qualità: 1. valutazione del contenuto:

autorevolezza dell’autore;autorevolezza dell’organizzazione di appartenenza;inclusione di riferimenti bibliografici;inclusioni di link alle fonti; identificazione dello scopo;identificazione del target; chiara identificazione dei finanziamenti / sponsorizzazioni;

2. valutazione dell’aggiornamento:data di pubblicazione;data di ultima modifica.

Motori di ricercaTra i più importanti strumenti di ricerca nella Rete, dove l’immensa quantità di informazione si confronta con l’assenza di una struttu-razione omogenea, sono da segnalare innanzitutto gli indici World Wide Web (WWW) che si occupano di censire e catalogare il con-tenuto complessivo della Rete.

Sono strumenti indispensabili per la navigazione, capaci di “spaz-zolare” migliaia di pagine Web ogni giorno alla ricerca di una ideale completezza ed esaustività che la Rete, per sua natura, non può cer-to concedersi.

Se riconosciamo che la documentazione reperibile in rete è spesso costituita da materiale eterogeneo, multimediale (suoni, immagini, testi, ipertesti) queste risorse sono da considerarsi assolutamente es-senziali per selezionare informazioni utili nell’immensità del patri-monio di pagine WWW di Internet.

Un patrimonio così elevato da giustificarne l’identificazione con la rete stessa.

Per la gestione ordinata delle pagine WWW, che sembra abbiano ormai superato la boa del miliardo, sono state studiate e incremen-tate numerose tipologie di indici (motori di ricerca) fondamentali per le operazioni di ricerca.

Indici Web per parolaDetti anche motori di ricerca o search engines, selezionano pagine

dalla Rete in funzione delle parole chiave digitate dall’utente nello specifico campo di ricerca (alcuni motori ricercano anche tra i mes-saggi di numerosi gruppi di news).

Utilizzano i cosiddetti programmi “spider” o “ robot” per aggior-nare periodicamente il proprio database, raccogliendo automatica-mente in grandi archivi le informazioni e individuando le occorren-ze di uno o più termini presenti nelle pagine Web.

Pertinenza dei risultati: spesso la lista di pagine Web che soddisfa la query (domanda, interrogazione) dell’utente, non ha un elevato indice di specificità, intesa come capacità di limitare l’effetto rumo-re, escludendo le citazioni non rilevanti da quelle pertinenti, infatti l’interrogazione del database in base alla keyword (parola chiave) digitata, viene condotta dai motori secondo un modello di ricerca semplice che non tiene conto del contesto in cui essa è collocata.

Proprio per questo motivo vengono utilizzati gli operatori boo-leani (AND, OR, NOT) per individuare con maggiore precisione l’area che interessa l’utente.

Nonostante l’impegno tecnologico per perfezionare questi stru-menti di interrogazione della Rete sia molto intenso, la difficoltà principale consiste nell’insegnare al programma a individuare auto-maticamente, omonimie, sinonimie e il contenuto semantico delle pagine Web, senza l’intervento di catalogatori umani.

Indici Web per argomentoDenominati anche directory o subject list sono realizzati con l’inter-vento di catalogatori umani che ordinano le pagine Web indicizzan-dole per soggetto e creando un albero di argomenti progressivamen-te sempre più circoscritti come contenuto semantico.

Sono estremamente costosi, ma presentano il vantaggio di ga-rantire una catalogazione delle risorse seconda una logica molto più vicina al nostro modo di ragionare e di ricercare.

Pertinenza dei risultati: la presenza di una valutazione “umana” capace di discernere, di individuare omonimie, sinonimie, e, soprat-tutto, riconoscere il contenuto semantico delle pagine Web, riduce fortemente il rumore nei risultati della ricerca, cioè la selezione di materiale documentativo non pertinente.

È necessario, però, considerare che le logiche di catalogazione e indicizzazione dei documenti vengono definite da uno staff di catalogatori umani che possono avere un bagaglio culturale molto diverso da quello ingegneristico, con il quale può essere difficile en-trare in sintonia.

Inoltre il database su cui si effettua la ricerca è, in genere, molto meno consistente di quello degli indici per parola che ricorrono a

sistemi di indicizzazioni delle pagine Web completamente automa-tizzate: questo aspetto aumenta ulteriormente lo scarto rispetto a una ideale esaustività della ricerca.

Gli indici Web per parola e per argomento sono molto numerosi; oltre agli indici generici esistono indici specializzati in specifici am-biti disciplinari (salute, economia, educazione, medicina) e indici internazionali, europei, nazionali secondo la specializzazione geo-grafica nella catalogazione delle risorse.

Nessun indice Web per parola o per argomento è in grado di verificare l’opzione di ricerca dell’utente su tutto il patrimonio di Internet sia per la sua inafferrabile dinamicità in termini di nume-rosità e variabilità delle risorse, sia per motivi tecnici: ogni motore indicizza una sua base dati, più o meno ampia, che viene aggiornata secondo una periodicità settimanale o mensile.

MetaindiciLa caratteristica di non omogeneità tra i diversi indici Web ha moti-vato la realizzazione di metamotori di ricerca o meta search engine o unified search engine che consentono all’utente di risparmiare tempo, utilzzando, talora anche contemporaneamente, tutti gli indici selezio-nati (l’elenco di default può essere modificato dall’utente finale).

Il risultato è una lista di indirizzi di pagine che suppliscono l’op-zione di ricerca, selezionate dalle basi di dati dei diversi motori: la lista, a volte, viene ordinata in base al motore di ricerca da cui proviene ogni specifica risorsa informativa, a volte in base alla pre-sunta rilevanza rispetto alla richiesta, altre volte ancora in base alla frequenza con cui gli indirizzi ricorrono nei motori scelti.

I metaindici in senso stretto riescono a individuare ed eliminare le ripetizioni (schiacciando le ridondanze qualora due indici sele-zionino lo stesso documento) e ordinare documenti secondo la loro rilevanza, cioè la pertinenza rispetto alla parola chiave di ricerca.

Bisogna stare attenti, però, che l’obiettivo di risparmio di tempo e di una presunta esaustività della ricerca nella rete, si paga con un appiattimento delle potenzialità di raffinamento delle interrogazio-ni in quanto questi strumenti sono incapaci di sfruttare le specifiche modalità di interrogazione dei singoli motori (definizione dell’arco temporale, della lingua, uso di operatori booleani, ecc.) rendendo di conseguenza più grezza la strategia di ricerca.

Suggerimenti per la ricerca attraverso i motori di ricercaFare ricerca attraverso la rete e, nel nostro caso, utilizzando gli indici o motori di ricerca, presenta sicuramente molti elementi di vicinan-za con la ricerca attraverso documentazione cartacea comunemente

condotta nelle biblioteche e nei centri di documentazione.I maggiori elementi di vicinanza riguardano la fase di imposta-

zione di ricerca, dalla definizione dell’argomento alle decisioni ine-renti la strategia di ricerca da mettere in atto.

Anche per la ricerca attraverso la rete è fondamentale mettere in campo tutte le risorse personali: precisione, intuito, pazienza, perse-veranza, curiosità intellettuale, competenza professionale e, soprat-tutto, il tempo.

Questo patrimonio personale può essere supportato dall’adozio-ne di un percorso metodologicamente definito di cui presentiamo le tappe principali:• scelta dell’argomento della ricerca;• delimitazione dell’argomento attraverso il disegno di una

mappa concettuale dello stesso e indicazione delle relazioni fra concetti attinenti;

• selezione dall’insieme di concetti di quelli su cui deve orien-tarsi la ricerca. Per ottenere questo si può ricorrere a indici web per argomento come Yahoo! che già classifica le pagine per categorie e sottocategorie di argomenti, progressivamente sempre più delimitati come contenuto semantico. Questo può facilitare la delimitazione concettuale della ricerca;

• identificazione di parole chiave che rappresentino significati-vamente il contenuto della ricerca. Esse devono essere precise, definite, univoche;

• collegamento al sito del motore di ricerca (meglio partire da quelli generali per poi accedere a quelli specializzati).

Osservazione: non esistono motori assolutamente migliori di altri. È meglio privilegiare quelli più visitati e scegliere in base alla velocità di accesso e all’interfaccia che appare più chiara e intuitiva. È anche molto importante, prima di impostare la ricerca, leggere le istruzioni per l’ interrogazione semplice ed avanzata che ogni motore di ricerca per parola o per argomen-to definisce. Queste sono linee guida utilissime per l’ottimiz-zazione delle operazioni di ricerca sia a livello qualificativo che quantitativo;

• digitazione nel campo “ricerca” (o search, o query o trova ) della parola o delle parole che rappresentano, nel modo più univoco possibile l’argomento di interesse.

A questo punto si otterrà un elenco di indirizzi di siti che avrà nel-le prime posizioni quelli con la maggior percentuale di “Relevance Ranking”.

Questo è un sistema di ordinamento dei risultati definito sulla base dei seguenti fattori:

- il numero di occorrenze dei termini di ricerca definiti dall’utente;

- la loro prossimità relativa nel testo;- la loro presenza in alcuni campi particolarmente significati-

vi come per esempio il titolo.

Se il risultato finale dell’interrogazione è caratterizzato da scarsezza o assenza di indirizzi spesso vuol dire che la strategia è sbagliata. Un errore comune è lo sbaglio di digitazione.

In questo caso le seguenti indicazioni sono valide per la maggior parte dei motori di ricerca:

- se si inseriscono più parole nel campo di ricerca, si tenga con-to del fatto che i motori attribuiscono valore all’ordine di in-serimento (prima le più importanti, al fondo le secondarie);

- se si vuole effettuare la ricerca su una frase si devono rac-chiudere le parole che la compongono tra virgolette. Au-tomaticamente verranno selezionati i documenti che con-tengono esattamente quella sequenza di parole o caratteri (questa funzione non è attiva per il motore Excite);

- rispetto all’uso di lettere maiuscole o minuscole è preferibile abituarsi ad utilizzare le minuscole perché consentono, a meno che sia necessario il contrario, di recuperare tutti i do-cumenti che contengono quella parola indipendentemente dai caratteri utilizzati per scriverla;

- per specificare le parole che devono sempre essere o non es-sere contenute nei documenti selezionati, sono da utilizzare i simboli + e − attaccati alle parole. Es: +cardiopatia −tratta-menti per trovare documenti che parlano della cardiopatia ma non del suo trattamento;

- per espandere la ricerca, si può usare il carattere *. Inserendo l’asterisco dopo una sequenza di lettere, almeno tre, si ottie-ne un troncamento a destra della parola. In questo modo la ricerca sarà effettuata su quella stringa di caratteri che può presentarsi in molteplici parole di senso compiuto (utile per i singolari – plurali, per le forme maschili – femminili). Il simbolo asterisco non deve essere separato dalla stringa di caratteri. Es: digitando diabet* avremo la visualizzazione di tutti i documenti che contengono le parole diabete, diabe-tologico, diabetico, diabetica, diabetici;

- gli operatori booleani devono essere scritti sempre in maiu-scolo. Se utilizzati in combinazione con più parole occorre utilizzare le parentesi per racchiuderle. Es: epilessia AND (traumi OR diagnosi);

• navigazione attraverso il documento, scelto tra quelli della lista che ci sembra più attinente al concetto ricercato;

• se il sito scelto è pertinente rispetto all’argomento di nostro interesse e nel motore di ricerca è attiva la funzione More Like This o Find Similar Pages o Mostra Pagine Simili (presente in Excite, Yahoo, Lycos, Google ) è consigliabile attivarla. Si può così localizzare pagine simili in base ad un criterio di at-tinenza/somiglianza semantica, cioè vengono ricercate pagine che contengono in alta percentuale le parole presenti nel do-cumento selezionato. Se la ricerca è stata fatta con un motore per categorie, appena si riesce a trovare almeno una risorsa informativa con un alto livello di pertinenza rispetto all’argo-mento di interesse, è consigliabile cliccare sulla categoria in cui è catalogata quella risorsa perché al suo interno se ne potranno trovare con facilità altre simili;

• chiedersi, durante la lettura dei diversi documenti, se sono davvero utili ai fini della ricerca in termini di contenuto, lin-guaggio, comprensibilità, pertinenza;

• selezione dei documenti in base al livello dell’approfondimen-to che si vuole raggiungere;

• cambiare motore di ricerca, oppure strategia di ricerca se non si riesce a selezionare dalla lista fornita in seguito all’interroga-zione, un documento utile entro i primi trenta;

• riproporre la stessa ricerca a più motori di ricerca, oppure uti-lizzare i metaindici tenendo presente, comunque, i loro limiti.

La modalità di lavoro è stata quella di utilizzare motori di ricerca per trovare le informazioni desiderate. Nel caso specifico si è scelto di usare Google ritenuto il più performante in ambito tecnico-scienti-fico. Si è, a tal proposito, verificato che in questo tipo di ricerca altri motori si riferiscono al sopra citato.

Come criterio di ricerca si è provveduto ad utilizzare come paro-le chiave: software open source, software gratis, software freeware, questo per la ricerca base, per poi specializzare la ricerca con parole come; medico, medical, dedicato alla medicina, per la sanità, oltre che con termini derivati dalla terminologia medica come, cardiolo-gia, diagnosi, oncologia e altri.

3.4.5 Risultati conseguiti e loro valutazione

Inserendo come parola chiave, nel motore di ricerca, “medical open source” sono stati ottenuti diversi risultati tra i quali segnaliamo i piu’ inerenti alla ricerca.

ComChart: electronic medical record che permette una facile ge-

stione dei dati di un paziente. Particolarmente interessante è la parte di “Lab management” dove viene sottolineata l’importanza di visualizzazione e di gestione di una grossa quantità di dati. Il prodotto è in grado di gestire anche le immagini (come per esem-pio le lastre) in modo efficiente. Non è gratuito ma è possibile scaricarne una demo da 7.5 MB [Comchart, 1999].Biomed central [Biomed Central, 1999]: questo sito presenta una lista di links in cui reperire materiale informatico inerente alla medicina. Tra questi segnaliamo LabX.com. In questo sito è pos-sibile scaricare come free download demo per 30 giorni JellyFish, interfaccia grafica che permette di gestire facilmente una sequen-za di analisi e/o importarla da database esterni [Labx, 1995].

MedsPDA [MedsPDA, 2002]. Tra i prodotti più interessanti ci sono:

• 5mCardiac (The AHA Clinical Cardiac Consult): linee gui-da per cercare e gestire malattie comuni e rare del cuore.

• 5mPeds (The 5-Minute Pediatric Consult): progettato per una veloce consultazione sui problemi infantili.

• A2zDrugs (A to Z Drug Facts): grosso database che contie-ne più di 5000 tipi di droghe con nomi, classificazioni ed effetti.

Bioinformatics.org, the open Lab offre diversi prodotti di cui si riportano le caratteristiche [Bioinformatics Organization, 1999].• A Smith Waterman algorithm on GreenTea algoritmo di

una sequenza di allineamento (sequence alignment algo-rithm) implementato per la piattaforma GreenTea P2P (decentralized distributed network computing platform). Questo Sw serve essenzialmente per creare una grossa po-tenza di calcolo.

• AcE, tool di valutazione e testaggio dei datasets: permette di fare un set di valutazioni statistiche facilmente generabili da una sequenza di tests.

• Biochemical Network Visual Designer, JDesigner è un tool che permette all’utilizzatore di disegnare reti biochimiche.

• COMBOSA3D, programma Web-based per comparare se-quenze di percorsi (memorizzati) su tre dimensioni.

• Dnacgr, programma per visualizzare percorsi nel DNA e RNA utilizzando la rappresentazione del caos.

• E-CELL Simulation Environment Version 3, pacchetto sof-tware per modellizzazione e simulazione nel settore cellula-re e biochimico.

• FragSize, Software Tool progettato per aiutare i biologi mo-lecolari nella determinazione della dimensione della banda del DNA.

• G-language Genome Analysis Environment, pacchetto sof-ware che fornisce un ambiente di sviluppo e analisi geno-mica.

• Gbioseq, lo scopo è quello di fornire un software facile da usare per editare una sequenza DNA sotto Linux.

• Genquire, software per annotazione di genomi completi o incompleti.

• Multi-Genome Navigator, pacchetto per l’esplorazione in-terattiva simultanea di genomi multipli possibilmente mi-schiata con risultati di analisi computazionale. Le informa-zioni sulla mappa possono essere caricate da varie sorgenti e le immagini risultanti possono essere esportate in differenti formati.

• PCalc - Primer Concentration Calculator, software proget-tato per aiutare biologi molecolari nelle procedure di routi-ne di calcolo di concentrazioni in PCR.

• Systems Biology Workbench, framework che permette in-tercomunicazione fra applicazioni eterogenee.

• The Sequence Manipulation Suite , collezione di program-mi web-based per analizzare e formattare le sequenze di DNA e proteine.

Open source health care resources: dove vengono presentati diversi programmi molto interessanti [Open Source Health Care Re-sources, 2000].

Ipath: open source framework per implementazioni di telemedi-cina [Ipath, 2005].

Inserendo parole chiave come: open source tumore, software open source diagnosi, software open source tumore, software open source cardiologia, software open source ipertensione, software open source trombosi, software tools oncologia, non sono stati trovati siti interessanti ai fini della ricerca.

Un caso particolare: il medico di baseConsideriamo il caso particolare del medico di base in quanto si è osservato, durante la ricerca, che per quanto riguarda il software open source rivolto ai medici, si fa particolarmente riferimento al medico di base, in particolare per la sua attività di prescrizione.

Questo fatto ci sembra giustificato dal motivo che tale figura pro-fessionale “lavora in proprio”, a differenza dei medici ospedalieri e di quelli che operano presso istituti di ricerca, dove il software viene messo a loro disposizione dall’azienda stessa per la quale lavorano.

Ci è sembrato così interessante approfondire questo argomento mettendo in evidenza il comportamento, spesso refrattario, del me-dico di base verso l’uso di tecnologie informatiche e al contempo di mostrare una classificazione del software open source recuperabile per questo ambito specifico. Già da tempo gli studi dei medici di base si sono arricchiti di un accessorio tecnologico di grande dif-fusione: il personal computer. Ma a questa constatazione ne segue immediatamente un’altra di uguale, se non maggiore, importanza: buona parte dei medici, nonostante siano dotati di personal com-puter, continuano a prescrivere manualmente. Le ragioni di questo atteggiamento possono essere diverse:1. si preferisce mantenere il contatto fisico con la penna che fa

“più umano”;2. il personal computer non ha mai fatto parte dei supporti pro-

fessionali;3. la dotazione hardware/software di cui si dispone non è in gra-

do di gestire il ricettario;4. dopo un primo avvio, a seguito di problemi non risolti, si è

tornati al manuale;5. la banca dati farmacologica non viene aggiornata con la neces-

saria tempestività;6. a seguito di variazioni normative il software non è più rispon-

dente ai bisogni professionali;7. il software utilizzato non dà nessun beneficio supplementare

rispetto alla prescrizione manuale.La prima di queste ragioni, ai nostri tempi, non regge, soprattutto se si considera la sempre più elevata abitudine tecnologica dell’uo-mo e l’eliminazione delle procedure di compilazione di dati perso-nali del paziente sul ricettario.

La seconda, più grave da parte del medico, lascia intendere che non esiste una consapevolezza nel considerare lo strumento informatico utile all’attività medica, trascurando il fatto che farmacisti, ingegneri, avvocati, notai, commercialisti e professionisti di ogni genere ne fan-no un uso quotidiano già da molti anni.

La terza e la quarta ragione stanno a significare che l’investimen-to informatico non è stato fatto con le opportune precauzioni, ciò implica che il medico deve fare sempre molta attenzione a ciò che acquista (dipende dall’esperienza informatica del medico, infatti il medico esperto tende a chiedere prestazioni superiori e a critica-

re facilmente manchevolezze del software che all’utente inesperto sfuggono completamente).

La quinta e la sesta ragione potrebbero essere effettivamente un problema del software open source in quanto, nel momento in cui a seguito dell’imprevedibile cambiamento legislativo, venga modifi-cato il modo di applicare un’esenzione, oppure alcuni farmaci non risultano essere più concedibili da un giorno all’altro o cambiano fasce di appartenenza, è difficile che il software libero si adegui con tempestività. Lo stesso problema non avviene con software acqui-stati, visto che in questo caso viene fornita garanzia di assistenza e di aggiornamento costante e tempestivo a fronte però di un canone di abbonamento.

Infine, a proposito dell’ultima ragione che può aver determinato la scelta di continuare a prescrivere manualmente, si possono por-tare esempi concreti di prodotti open source che la rendono in-fondata. Ad esempio: un programma come Perseo Plus consente la prescrizione contemporanea di farmaci, prodotti omeopatici, esami di laboratorio, diagnostica strumentale, visite specialistiche, terapie fisiche, richieste di ricovero, prescrizioni libere, altre prestazioni.

Ognuno di questi elementi è richiamabile secondo vari criteri, ad es. per i farmaci è possibile effettuare selezioni per nome com-merciale, principio attivo, classe di appartenenza; per le richieste di accertamenti è possibile selezionare la branca desiderata; al medico resta solo da specificare gli elementi da prescrivere.

Ogni elemento da prescrivere, indipendentemente dalla sua tipo-logia (farmaco, prestazioni, esame di laboratorio, visita specialistica ecc.) può essere selezionato:• tramite i vari archivi disponibili (prontuario farmaci, tariffario);• attingendo da un archivio di protocolli personalizzabili;• utilizzando l’archivio delle prestazioni ripetitive associate al

paziente.Queste varie modalità di operare durante la prescrizione possono, inoltre, essere combinate tra loro. Questi programmi effettuano l’applicazione delle esenzioni in modo automatico e, ad essi, può essere richiesto anche di verificare, sempre in automatico, l’intera-zione tra i farmaci, le controindicazioni e/o intolleranze che hanno causato in precedenza reazioni avverse del paziente oppure legate ad un determinato stato patologico temporaneo del paziente.

Nel caso dei farmaci è possibile poi stabilire la durata della terapia e, per ogni elemento prescrittivo, può essere associata una diagnosi o un commento come per esempio la modalità di assunzione di un farmaco. Infine, durante la prescrizione, con semplici comandi è sempre possibile:

Tabella 3.3Esempi di programmi autoprodotti e loro caratteristiche

• visualizzare la scheda del farmaco o della prestazione;• ricercare farmaci equivalenti a quello prescritto (es. farmaci

generici);• ripercorrere la storia prescrittiva del farmaco richiesto;• visualizzare i dati del SSN del paziente;• conoscere il numero di ricette generate dalla prescrizione, il

tiket a carico del paziente, l’eventuale quota a carico del SSN ed il costo totale della prestazione effettuata;

• esaminare le norme che regolano in quel momento la prescri-zione in ambito del SSN;

• ottenere informazioni sulla spesa sanitaria generata dal singolo paziente.

Dopo questa lunga lista di benefici, risulta difficile capire come sia possibile paragonare una prescrizione manuale con una informatiz-zata.

Passando ora alla breve classificazione del software open source recuperabile, possiamo dire che in base alle loro caratteristiche i sof-tware per medici di base possono essere suddivisi per gruppi e per categorie. La suddivisione per gruppi prevede:1. programmi autoprodotti;2. programmi per sistema operativo DOS;3. programmi per MS-Windows.

1. Programmi autoprodottinome sistema minimo disponibilità categoria

Ambulatorio Macintosh(Motorola 68030) gratuito 2-3

Doctor Ardus DOS (286) gratuito 2Irambiep DOS (286) gratuito 2

Il punto di forza di questi programmi è che sono stati costruiti dai medici per se stessi, quindi, continuamente affinati ed aggiornati per un utilizzo ottimale da parte dei loro creatori. Sono programmi leggeri e molto veloci, adatti ai computer più vecchi; sono robusti e difficilmente presentano difetti di affidabilità; sono generalmente studiati in modo da essere manovrati anche da utenti poco esperti. Il loro punto debole è generalmente una scarsa o assente possibilità di evoluzione, restando legati, soprattutto, alle mansioni di base. Sono, tuttavia, programmi utili per alcune fasce di utenti: • medici poco interessati ad approfondire il settore informatico;• medici che desiderano solo scrivere ricette;• medici che, in possesso di un vecchio computer, non vogliono

spendere per una macchina più potente.

2. Programmi che girano ancora col DOSnome Sistema minimo disponibilità categoriaPerseo DOS( 486) gratuito 3-4PFP DOS ( 486) gratuito 2-3

I programmi di questo gruppo sono molto più rifiniti e con un numero di funzioni più elevate rispetto a quelle del gruppo prece-dente. Appartengono generalmente alla terza categoria con alcune funzioni della quarta.

3. Programmi per MS-Windowsnome sistema minimo disponibilità categoriaCartella clinica Bracco

Windows 95(486 ) gratuito 3-4

Medico 2000 Windows 95( Pentium 166)

gratuito 3-4

Perseo Plus Windows 95( Pentium 166) gratuito 3-4

In questo gruppo troviamo programmi nati appositamente per Windows 95, sono tutti di alto livello, appartengono alla terza cate-goria ma hanno numerose funzioni della quarta.

L’interfaccia è, generalmente, più amichevole e rifinita rispetto agli altri gruppi, inoltre il ricorso all’uso di icone li rende molto più intuitivi.La classificazione delle categorie dei programmi prevede:

Categoria DescrizioneCategoria 1 Il programma svolge solo compiti di base

scrittura ricette e certificati ( dati anagrafici, età, indirizzo, data)scheda clinica personale per ogni paziente

Categoria 2 A quanto sopra si aggiungono le seguenti funzioni:tenuta dell’elenco dei pazientimemorizzazione delle prestazionitrasmissione dei dati via modem alle ASL secondo un protocollo standard

Categoria 3 Il programma si serve, in aggiunta, di database e funzioni accessorie di tipo espositivo o al massimo elaborativo che completino e facilitino l’opera del medicoprontuario farmaceutico aggiornatomanuali di elencazione di patologie, protocolli terapeutici, criteri diagnosticiprincipali protocolli di leggeripetizione automatica delle prescrizioni abitualiprincipale modulistica accessoria per i certificatielaborazione statistica dell’andamento prescrittivo, degli eventuali costielaborazione statistica dei principali indicatori epidemiologici ( patologie, decessi, ecc.)verifica automatica della possibilità di esenzionetrasmissibilità di dati complessi di collegamento interattivo con le ASL per prenotazioni, ricevimento circolari, ecc.

Categoria 4 Il programma contiene funzioni intelligenti che intervengono con criterio interattivo nella scelta dell’opzione medica assistenza alla diagnosi differenzialeassistenza alla scelta della terapiaassistenza all’interpretazione dei referti di laboratorioassistenza alla prescrizione degli accertamenti più opportunipresentazione, all’atto della prescrizione, di eventuali alternative

Tabella 3.4Esempi di programmi

per sistema operativo DOS e loro

caratteristiche

Tabella 3.5Esempi di programmi per sistema operativo

MS-Windows e loro caratteristiche

Tabella 3.6La classificazione delle

categorie e le loro descrizioni

3.4.6 Conclusioni

Il software Open Source, sviluppato e distribuito gratuitamente tra-mite Internet, sta raccogliendo sempre più consensi, non solo negli ambienti accademici, ma anche nelle imprese, nelle professioni e nella pubblica Amministrazione, in Italia come all’estero. Affida-bilità, prestazioni, sicurezza, assistenza e documentazione sono le qualità che rendono questo software spesso superiore al software commerciale. Questo senza dover sostenere costi di acquisto o di licenza. Un’evoluzione che tocca tutti: imprenditori, responsabili di informatica, presidi, insegnanti e studenti.

Ci sono alcune considerazione, alcune regole di base che possono tornare utili per valutare un prodotto Open Source, non essendo tutto l’Open Source di qualità. Tali regole, pur non pretendendo di valere in qualunque circostanza, nella maggior parte dei casi per-mettono di distinguere un buon progetto dal tentativo, spesso de-stinato ad arenarsi, di un gruppo di volenterosi ma poco competenti sviluppatori.

La prima domanda da porsi e insieme una delle più importanti è relativa a “chi” sta dietro al progetto stesso. Questo sia da un punto di vista quantitativo (se un software viene sviluppato da varie decine di persone probabilmente si tratta di qualcosa di quantomeno inte-ressante) sia da un punto di vista qualitativo (la presenza di grandi aziende è spesso la miglior garanzia di qualità). La seconda doman-da che vale la pena di farsi è di chiedersi il “quando” del progetto: se il software viene sviluppato da molto tempo ha probabilmente passato la selezione naturale severissima che opera nel mondo del software libero. In questo senso un approccio conservativo richiede di accantonare progetti magari promettenti, ma appena usciti, in quanto la “mortalità infantile” nel mondo dell’Open Source è mol-to alta. Un ulteriore parametro è quello del “perché” e del “cosa”. Quali sono i motivi che hanno spinto alla nascita del progetto? Si tratta di una applicazione verticale ma di estremo interesse, oppure orizzontale ma insieme molto generica e poliedrica? Come la tecno-logia usata è in grado di integrarsi con quella presente in azienda? In quale misura il software che si sta analizzando copre l’esigenza alla base della valutazione stessa? Come si può vedere i parametri di va-lutazione sono molti e spesso richiedono avanzate capacità di analisi tecnica per capire quale sia l’alternativa migliore tra Open Source e proprietario. Un dato di fatto che sembra ormai assodato è la qualità molto alta del software Open Source di successo: se il software ha alle spalle una buona comunità e risponde a esigenze reali in manie-ra tecnicamente valida, questo è un ottimo indizio di qualità. Po-

ter detrarre dall’analisi del TCO (Total Cost of Ownership) la voce relativa all’acquisto delle licenze è un ottimo primo passo, ma non basta per giustificare la scelta di una soluzione Open Source rispet-to a un’alternativa commerciale: nulla è in grado di sostituire una buona analisi tecnica che, prescindendo dalla struttura dei costi, si basi solo sulla qualità della tecnologia. La scelta dell’Open Source è spesso coraggiosa, ma le storie di successo non mancano.

Bibliografia

Paragrafo 3.1Basic Support for Cooperative Work (BSCW) [Online]; 2008. Di-

sponibile all’indirizzo URL: http://public.bscw.de. Ultimo acces-so: 5 settembre 2008.

Casati F, Ceri S, Pernici B, Pozzi G. Data and Knowledge Enginee-ring. Workflow Evolution 1998; vol. 24 (1):211-238

Casati F, Ceri S, Paraboschi S, Pozzi G. Specification and Imple-mentation of Exceptions in Workflow Management Systems. ACM Transactions on Database Systems 1999; vol. 24 (3): 405-451

Casati F, Pozzi G. Modeling Exceptional Behaviors in Commer-cial Workflow Management Systems. IEEE Computers Society. Fourth IECIS International Conference on Cooperative Infor-mation Systems; Washinton DC, USA; 1999. p.127

Casati G, Vichi M.C. Il percorso assistenziale del paziente in ospe-dale. Milano: Mc Graw Hill; 2002.

Hollingsworth D. Workflow Management Coalition (WfMC) [Online] 1995. Disponibile all’indirizzo URL: http://www.wfmc.org/standards/docs/tc003v11.pdf. Ultimo accesso: 5 set-tembre 2008.

Lega F. Il percorso diagnostico-terapeutico. L’impatto sull’organiz-zazione, sulla qualità e sui costi. Prospettive sociali e sanitarie. Milano: IRS; 1999.

Lega F. Logiche e strumenti di gestione per processi in sanità. Mila-no: Mc Graw Hill; 2001

Marra D, Romano P, Milanesi L. Web services and workflow ma-nagement for biological resources. BMC Bioinformatics 2005; 6(Suppl 4):S24

Mintrone S. IT e gestione del rischio clinico: passato, presente e fu-turo. Atti del II Convegno Nazionale AISIS; 26-28 ottobre 2007; Acireale, Italia. Disponibile all’indirizzo URL: http://www.aisis.it/index.php?option=com_docman&task=doc_view&gid=36. Ultimo accesso: 5 settembre 2008.

Workflow Management Coalition (WfMC) [Online] 1999. Disponi-bile all’indirizzo URL: http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf. Ultimo accesso: 5 settembre 2008.

Paragrafo 3.2Bandinelli S, Baresi L, Fuggetta A, Lavezza L. Experiences in the

Implemenation of a Process-Centered Software Engineering Environment using Object-Oriented Technology. Theory and Applications of Object-oriented System. John Wiley, 1995; vol. 1(2): 115-132.

Booch G, Rumbaugh J, Jacobson I. Unified Modeling Language User Guide. 2nd ed. Addison-Wesley. Boston, MA; 2005.

Fowler M, Scott K. UML distilled A Brief Guide to the Standard Object Modeling Language. 2nd ed. Addison-Wesley Pearson Education; 1999.

Naiburg E.J, Maksimchuk R.A. UML for Database Design. 1st ed. Addison-Wesley Pearson Education. Boston, MA; 2001.

Unified Modeling Language (UML) 1997. Disponibile all’indirizzo URL: www.uml.org. Ultimo accesso: 5 settembre 2008.

Paragrafo 3.3Adriaans P, Zantinge D. Data Mining. Reading, MA: Addison We-

sley Publishing Company; 1996Cabena P, Hadjinian P, Stadler R, Verhees J, Zanas A. Discovering

Data Mining - From Concept to Implementation. Upper Saddle River, NJ: Prentice Hall PTR; 1997.

Dulli S. Il Data Mining [Online, 2006]. Disponibile all’indirizzo URL: www.math.unipd.it/~dulli/corso06/DMteoria.pdf Ultimo accesso: 15 giugno 2009

Wang W. Data Mining: Concepts, Algorithms, and Applications. [Online, 2009] Disponibile all’indirizzo URL: http://www.cs.unc.edu/Courses/comp790-090-s09/LectureNotes/cluste-ring1.pdf Ultimo accesso: 15 giugno 2009

Paragrafo 3.4Amadori G, Bazzigaluppi G, Bernocchi W. Gatti M. Sistemi ope-

rativi “Open Source”: il caso Linux. Mondo Digitale 2, Marzo 2002.

Berra M, Meo A.R. Libertà di software, hardware e conoscenza in-formatica solidale 2. Bollati Boringhieri editore; 2006.

Bioinformatics Organization [Online] 1999. Disponibile. all’indi-rizzo URL: http://bioinformatics.org/softwaremap/?form_cat=2. Ultimo accesso: 6 settembre 2008.

Biomed central [Online] 1999. Disponibile all’indirizzo URL:http://www.biomedcentral.com/info/general.asp. Ultimo accesso: 6

settembre 2008.ComChart: electronic medical record [Online] 1999. Disponibile

all’indirizzo URL: http://comchart.com/cc_46features.html. Ul-timo accesso: 6 settembre 2008.

De Laat P.B. Copyright or copyleft? An analysis of property regimes for software development. Research Policy, Vol. 34 p.1511-1532; 2005.

Evers S. An Introduction To Open Source Software Development. Technische Universität Berlin, Fachbereich Informatik, Fachge-biet Formale Modelle, Logik und Programmierung (FLP) 2000.

Grasso F. Il Software Open Source (OSS): scenario e prospettive. AIPA - Autorità per l’Informatica nella Pubblica Amministrazio-ne, 2002.

Ipath – Open Source Medical Collaboration Platform [Online] 2005. Disponibile all’indirizzo URL: http://ipath.sourceforge.net/. Ultimo accesso: 6 settembre 2008.

LabX Scientific Marketplace [Online] 1995. Disponibile all’indi-rizzo URL: http://www.labx.com. Ultimo accesso: 6 settembre 2008.

MedsPDA Software [Online] 2002. Disponibile all’indirizzo URL: http://medspda.com Ultimo accesso: 6 settembre 2008.

Open Source Health Care Resources [Online] 2000. Disponibile all’indirizzo URL: www.openhealth.org. Ultimo accesso: 6 set-tembre 2008.

Williams S. Free as in freedom: Richard Stallman’s crusade for free software. O’Reilly ed 2002.

4 Arnesi informatici peculiari della sanità

4.1 Unified Medical Language System (UMLS)

4.1.1 Introduzione

Nonostante gli evidenti vantaggi dell’informatizzazione delle co-noscenze biomediche, esiste il rischio di riutilizzare i dati clinici (codici, termini, espressioni in testo libero) fuori dal loro contesto originale, senza convertirli da un ambiente ad un altro, interpre-tando quindi i dati in modo parzialmente diverso da quello per cui erano stati generati. Occorre quindi assicurarsi che le espressioni per gli operatori sanitari siano univoche, ben definite e il più possibile indipendenti dal contesto, in modo accettato da tutta la comunità medica nel suo complesso. Una precisione estrema nella rappresen-tazione del significato del dato clinico è fondamentale sia per il suo uso primario (durante la fornitura di prestazioni al paziente), sia per i successivi eventuali riutilizzi (in situazioni e contesti diversi), resi molto più agevoli dai progressi della telematica. Il calcolatore è in grado di memorizzare e restituire frasi di testo libero in genere senza elaborarle. Accanto al testo libero il calcolatore può utilizzare i linguaggi artificiali (tra cui i sistemi di codifica ed i vocabolari controllati), costruiti per rappresentare e trasferire informazioni, in maniera efficace e per scopi definiti, in ambienti ben caratterizzati.

Nel linguaggio medico interessano in particolare le cosiddette “espressioni motivate”, cioè espressioni linguistiche formate da varie parole che denotano nel loro complesso concetti “unitari” particolar-mente significativi per chi parla e ascolta [Bondi et al, 1995]. Da un punto di vista linguistico i dati che devono essere elaborati sono sin-tagmi terminologici del tipo: ulcera cronica sanguinante dello stomaco e severa gastrite atrofica, con presenza di compylobacter.

Certamente non è possibile trovare già predefinite in un qualsiasi sistema di uso generale, espressioni motivate della complessità della precedente; occorre infatti trovare un compromesso tra lunghezza delle espressioni e quantità di voci considerate. I sistemi termino-logici attualmente in uso presentano diversi gradi di flessibilità e alcuni permettono di esprimere nel dettaglio concetti medici anche molto complessi.

UMLS (Unified Medical Language System) è stato realizzato dalla National Library of Medicine (NLM) di Bethesda (USA) a partire dal 1986. Il progetto UMLS si presenta come il mezzo per facilitare il recupero e l’integrazione delle informazioni provenienti da una molteplicità di sorgenti di informazioni biomediche informatizzate [UMLS, 2004].

Il sistema medico unificato di lingua (UMLS) contiene i termi-ni biomedici ed i rapporti semantici. Fanno parte dell’UMLS, ad esempio, l’International Classification of Disease (ICD), la Syste-matic Nomenclature of Medicine (SNOMED), il Library of Con-gress Subject Headings (LCSH) e le diverse edizioni del MeSH tra-dotto nelle principali lingue europee, tra cui l’italiano. I termini vengono da circa 100 vocabolari eterogenei in circa 15 lingue.

Ci sono:• più di 1.900.000 termini provenienti da oltre 60 fonti tra clas-

sificazioni, terminologie ecc.;• circa 800.000 concetti;• 19 milioni di relazioni.Lo scopo di UMLS è, quindi, l’unificazione e l’associazione di sva-riate terminologie e classificazioni mediche, per mezzo di una gran-de rete di relazioni tra i termini che compaiono nelle terminologie, e di una rete semantica per la loro classificazione. Facendo ciò si facilita lo sviluppo dei sistemi di elaborazione, in modo che si com-portino come se “capissero” il significato della lingua della biome-dicina e della salute. A tale scopo, NLM produce e distribuisce le fonti di conoscenza di UMLS (basi di dati) e gli attrezzi collegati del software (programmi) ad uso degli sviluppatori del sistema in costruzione; vengono aumentati i sistemi d’informazione elettronici che generano e/o aggregano dati, informazioni di salute e biomedi-che [Bodenreider, 2004].

L’approccio di UMLS si basa sullo sviluppo di Sorgenti di Cono-scenza su calcolatore accessibili da una grande varietà di programmi applicativi, per compensare le differenze di espressione dei concetti presenti nelle diverse sorgenti di terminologia biomedica memoriz-zate su calcolatore. Lo scopo finale è facilitare gli operatori biome-dici nel difficile compito di collegare informazioni provenienti da sistemi di registrazione dei pazienti, da basi di dati bibliografiche, da sistemi esperti, e così via.

La quantità di sorgenti di informazione a cui si può attingere mediante UMLS è considerevole. In particolare troviamo descrizio-ni tratte dalle seguenti sorgenti: letteratura biomedica, basi di dati bibliografiche, raccolte di cartelle cliniche, sistemi esperti, sistemi di basi di conoscenza, elenchi di persone e organizzazioni. Senza

129Capitolo 4Arnesi informatici peculiari della Sanità

l’ausilio di uno strumento di ricerca di informazioni come UMLS gli ostacoli, all’effettivo recupero ed integrazione di informazioni provenienti da questo tipo di sorgenti, sono essenzialmente due:• la varietà di vocabolari e di classificazioni usate nelle diverse

sorgenti e dai diversi utenti;• il gran numero e la dispersione delle sorgenti di informazione.Questi ostacoli che si frappongono fra l’utente e le sorgenti di in-formazioni hanno l’effetto di scoraggiare gli operatori del settore biomedico dal fare utilizzo di questa gran mole di dati, altrimenti di grande interesse. In questo contesto UMLS si propone come il mezzo per coordinare logicamente la massa bruta delle informazio-ni dislocate nelle più disparate sorgenti, in modo che l’accesso dei potenziali utenti ad esse risulti essere facilitato.

Per esemplificare, supponiamo che un internista visitando un paziente riscontri una lesione sospetta. Il medico ha tutta una se-rie di possibilità per approfondire la conoscenza della patologia del paziente:• potrebbe desiderare di consultare in una base di dati le ca-

ratteristiche di manifestazione della lesione per ottenere più informazioni circa una possibile predisposizione genetica del paziente;

• proporre esami e protocolli clinici;• analizzare la recente letteratura medica su quel particolare ar-

gomento (p.e. elective lymph node dissection in MEDLINE);• seguire il decorso della malattia attraverso una registrazione

computerizzata del paziente (nel proprio o in un altro istituto).Tipicamente ognuna delle precedenti esigenze richiederebbe la co-noscenza da parte dell’utente di un diverso strumento informatico; da qui il progetto UMLS come interfaccia uniforme al mondo delle conoscenze biomediche.

4.1.2 La struttura generale di UMLS

UMLS si basa su un sistema a tre strati così classificati:• strato superiore: costituito dall’interfaccia utente, la quale può

essere implementata localmente in modo diverso a secondo delle esigenze e delle macchine a disposizione;

• strato intermedio: costituito dal Metathesaurus, dalla Rete Se-mantica, e dal lessico SPECIALIST Lexicon. Nel metathesaurus tutte le parole e le frasi che hanno lo stesso significato formano un concetto distinto, una classe di sinonimi. I concetti sono correlati tra loro e organizzati per categorie, dal generale al par-ticolare, all’interno di una complessa rete semantica (semantic

network), mentre un apposito lessico specializzato in lingua inglese (Specialist Lexicon) definisce le varianti lessicali per una parte della terminologia biomedica predisponendo le informa-zioni sintattiche, morfologiche e ortografiche necessarie allo sviluppo di sistemi di “mappatura” automatica del linguaggio naturale (Natural Language Processing System o NLP);

• strato inferiore: costituito dalla Mappa delle Sorgenti di Infor-mazione.

Nella Figura 4.1 possiamo vedere graficamente come sono intercor-relate le varie componenti di UMLS. La figura in questione non è uno schema formale della struttura di UMLS ma solo un disegno che evidenzia graficamente le sue parti componenti e come queste sono legate fra loro.

Vediamo nel dettaglio le parti di cui si compone UMLS:

Interfaccia utente

Metathesaurus

SPECIALIST LexiconRete Semantica

(Semantic Network)

Mappa delle sorgenti di informazione

Human Genome Project

Medline/ PubMed

Toxicology and

Chemical Databases

BiosignalDatabases

Image Databases

PatientRecord Systems

Decisions Support Systems

Oltre 18 milioni di riferimenti bibliografici

NCBIOMIMGeneBank

TOXNET Visible Human DatasetMedPix

Physionet

Informazioni biomediche

Figura 4.1Struttura di UMLS

• l’interfaccia;• il Metathesaurus;• la Rete Semantica;• lo SPECIALIST Lexicon;• la Mappa delle Sorgenti d’Informazione.

4.1.2.1 L’interfacciaL’interfaccia che consente di effettuare le ricerche viene definita UMLS Knowledge Source Server (UMLSKS) ed è un’applicazione che consente l’accesso tramite Internet alle informazioni memo-rizzate nelle Sorgenti di Informazione di UMLS (Figura 4.2). Lo scopo di UMLSKS è quindi di rendere facilmente accessibili i dati agli utenti. L’architettura del sistema è basata su un modello Client/Server che consente di inviare richieste di interrogazione da parte di utenti remoti al server centrale della National Library of Medicine.

A partire da questa possono essere interrogati separatamente il Metatesauro (Figura 4.3), la Rete Semantica (Figura 4.4) o lo SPE-CIALIST Lexicon (Figura 4.5). Per quanto riguarda il Metatesauro, il Knowledge Source Server (KS) consente all’utente di richiedere informazioni a proposito di un particolare concetto, compresi i suoi attributi, la definizione e i concetti correlati. È inoltre possibile cer-care un dato specifico cioè interrogare il server limitando la ricerca a un solo termine e, volendo, ai suoi sinonimi.

La parte dedicata al Semantic Network consente di ricavare in-formazioni sui Semantic Type e sulle loro relazioni. Queste possono essere richieste specificando i tipi semantici e le loro relazioni ma anche indicando solo uno dei due; il sistema completerà in questo caso il valore corrispondente per le parti non specificate nell’inter-rogazione. È possibile, inoltre, conoscere tutte le relazioni tra una coppia di tipi. Per esempio: “cura”, “prevenzione” e “complicazione” sarebbero elencate, tra le altre, come potenziali relazioni tra malattia e medicinale.

Per quanto riguarda il terzo livello di interrogazione, cioè lo Specialist Lexicon, le voci lessicali in ingresso possono essere voci singole o termini composti. Le informazioni ricevute includono la categoria sintattica e le variazioni inflessionali (singolare/plurale per i nomi, le coniugazioni dei verbi, comparativo/superlativo per gli aggettivi, ecc.).

4.1.2.2 Il metatesauroMetathesaurus contiene informazioni sintattiche e semantiche sui termini, che compaiono in vari vocabolari e classificazioni. Ad ogni concetto è associato un Semantic Type (ST) dalla Rete Semantica

Figura 4.2 Homepage di ULMS-KS

Figura 4.3Esempio di “Metathesaurus Search”

Figura 4.4Interfaccia relativa a una “Semantic Network Search”

Figura 4.5Esempio di “Specialist Lexicon Search”

[Aronson, 2001]. Il Metathesaurus è organizzato per concetti e l’or-ganizzazione si snoda su tre livelli (Figura 4.6):• il primo livello è relativo ad un insieme di concetti generali

(rappresentati ciascuno mediante un codice) – CUI;• il secondo è relativo ad un insieme di nomi del concetto (rap-

presentati anch’essi da codici) – LUI;• il terzo livello considera un insieme di stringhe (ciascuna rap-

presentata da un codice e dalla stessa stringa lessicale) – SUI.Le relazioni all’interno del Metathesaurus sono del tipo X è figlio di Y, X è padre di Y, X e Y non sono simili, X è più generale di Y. Han-no un tipo (es. narrower) e molte hanno un attributo (es. part_of ) che definisce in qualche modo la natura della relazione. La maggior parte delle relazioni deriva dalle fonti (relazioni tra concetti) ma anche relazioni tra le fonti sono aggiunte durante la costruzione del Metatesauro:• Relazioni simboliche:

> Relazioni gerarchiche aggiuntive (collegamenti tra gerar-chie diverse ed esplicitazione di relazioni tra CUI);

> Tutte le relazioni non gerarchiche associative• Relazioni statistiche.

SUI S0016668String: Atrial Fibrillation

LUI: L0004238Atrial Fibrillation SUI S0016669

String: Atrial Fibrillation

CUI: C0004238Atrial Fibrillation

SUI S0016899LUI: L0004327 String: Auricolar Fibrillation

Auricolar FibrillationSUI S0016900

String: Auricolar Fibrillation

Lo spazio semantico delle relazioni simboliche (gerarchie/relazioni associative) è definito dal loro tipo e, laddove esiste, dal loro attri-buto. Lo spazio semantico delle relazioni statistiche, invece, è inde-finito [Tringali et al., 2002].

Le relazioni presenti sono:0. Sinonimia.

Da Metatesauro:1. RB – Broader;2. RN – Narrower;3. RO – Other Related;4. RL – Like;

Figura 4.6Esempio di

organizzazione del Metatesauro

Da fonti:5. PAR – Parent;6. CHD – Child;7. SIB – Sibling (“Fratellastro”);8. AQ – Allowed Qualifier;9. QB – “Può essere” Qualified.

4.1.2.3 La rete semanticaLa Rete Semantica (Semantic Network, SN) contiene informazioni sui tipi semantici assegnati ai concetti nel Metathesaurus; ad ogni concetto viene attribuito almeno un tipo semantico. Questi tipi sono definiti esplicitamente dall’informazione testuale ed implicita-mente tramite le gerarchie rappresentate. I tipi semantici sono rap-presentati come nodi e le relazioni come dei links.

Nella rete semantica di UMLS si individuano due tipi di gerar-chie, una per le entità ed una per gli eventi (sono quindi inclusi tipi semantici per gli organismi, strutture anatomiche, concetti, idee…).

Per quanto riguarda le relazioni oltre alla relazione is_a (gerarchi-ca) (Figura 4.7), sono presenti delle relazioni associative non gerar-chiche rappresentate da 53 verbi che esprimono i possibili collega-menti tra concetti o tra relazioni (Figura 4.8). Queste sono suddivi-se in cinque categorie:• Fisica, ad esempio “part of”;• Spaziale, ad esempio “location of”;• Funzionale, ad esempio “prevents”;• Temporale, ad esempio “co-occurs with”;• Concettualel, ad esempio “diagnoses”.

Figura 4.7Relazione gerarchica Is_a - Funzioni biologiche

Biologic Function

Physiologic Function

OrganismFunction

Mental Process

GeneticFunction

Organ or Tissue

Function

CellFunction

MolecularFunction

Cell or Molecular

Dysfunction

Disease or Syndrome

Mental or BehavioralDysfunction

Neoplastic Process

Experimental Model of Disease

Pathologic Function

Se da un lato i tipi semantici sono specifici per il dominio biomedi-co, molte delle relazioni sono applicabili in domini al di fuori della medicina.

L’organizzazione del SN è meglio rappresentata dai grafi diret-ti aciclici (DAG – Direct Acyclic Graph), che consentono di rap-presentare l’ereditarietà multipla. In questi grafici esiste sempre un percorso (cioè un insieme di collegamenti tra concetti) “preferito”; le relazioni gerarchiche sono transitive e monodirezionali mentre quelle associative possono anche essere bidirezionali (riflessive).

La rete semantica quindi:• aiuta ad esplicitare le relazioni interconcettuali;• rafforza la struttura del Metatesauro;• aiuta nell’interpretazione semantica dei testi.

4.1.2.4 Specialist LexiconLo Specialist Lexicon fornisce informazioni sintattiche dettagliate sui termini biomedici (biomedical) e parole comuni della lingua inglese, con le loro informazioni morfologiche e sintattiche.

Il lessico specialistico con i programmi lessicali connessi, costitu-

Organism

co-occurs with

disrupts

adjacent to

process of

evaluation ofevaluation ofproperty of

contains,produces

location of

conceptualpart of

part of

part ofpart ofpart ofpart of

AcquiredAbnormality

CongenitalAbnormality

Body, Part, Organ or Organ Component

Tissue Cell Cell Component

Gene orGenome

Body System

Body Substance Body Space

or Junction

Body Locationor Region

Fully FormedAnatomicalStrucutre

Injury orPoisoningAnatomical

AbnormalityEmbryonicStructure

AnatomicalStructure

OrganismAttribute

Laboratoryor Test Result

Sign of Symptom

PhysiologicFunction

PathologicFunction

BiologicFunctionFinding

Figura 4.8Legami tra entità. Le relazioni associative “non Is_a” sono espresse dalle frecce tratteggiate e dall’indicazione del tipo di relazione (esempi “part of”, “evaluation of” ). Queste relazioni insieme con le relative entità formano un Grafo Diretto Aciclico (DAG). Le relazioni di ereditarietà , cioè “Is_a”, sono indicate da tratti continui. Ad esempio “Pathologic Function” Is_a “Biologic Function”

iscono delle risorse UMLS per gestire l’elevato grado di variazione linguistica, presente nel linguaggio naturale e nelle stesse termino-logie: quindi contengono e gestiscono non solo la terminologia bio-medica ma anche buona parte del vocabolario della lingua inglese. Inoltre possono essere utilizzate indipendentemente in altre appli-cazioni per il processamento del linguaggio naturale.

4.1.2.5 La mappa delle sorgenti di informazioneLa Mappa delle Sorgenti di Informazione ISM (Informations Sources Map) deve supportare un sistema in cui l’utente pone una query, re-lativamente all’ambito biomedico, ed in risposta riceve delle infor-mazioni che siano pertinenti, con accesso facilitato all’informazione.

Nella versione del 1998 erano presenti 75 sorgenti d’informa-zione. Queste sorgenti includono tra le altre cose, databases sul-la bibliografia medica, sistemi esperti, e databases sulle droghe e di genetica. Per ciascuna risorsa, ISM include una descrizione del database, il tipo di informazione che contiene, i probabili usi del database stesso.

4.1.3 Esempio di classificazione

La metodologia di classificazione presentata consente, quindi, di identificare e definire univocamente concetti presenti nelle diverse sorgenti di terminologia biomedica.

È quindi possibile definire i concetti secondo lo schema e la gra-fica presenti nella Figura 4.9.

GLIOBLASTOMA

• CUI:C0017636• SemanticType:Neoplastic-process• SemanticGroup:Disorders• Synonyms:Astrocytoma,GradeIV-Astrocytomas,GradeIV-glioblasto-

ma-Glioblastoma-GlioblastomaNOS-Glioblastoma,NOS-Glioblasto-mas -GradeIVAstrocytoma -GradeIVAstrocytomas-[M]Glioblastoma-NOS

• Definition:> Amalignant form of astrocytoma histologically characterize-

dbypleomorphism of cells,nuclear atypia,microhemorrhage,andnecrosis.They may ariseinany region ofthecentral nervoussystem,withapredilectionforthecerebralhemispheres,basalgan-glia, andcommissural pathways.Clinical presentation most fre-quentlyoccursinthefifthorsixthdecadeoflifewithfocalneurologicsignsorseizures.[MSH]

> Ageneral term that refers tomalignant astrocytoma, atype ofbraintumor.[PDQ]

Figura 4.9Snapshot della rappresentazione dei risultati di una ricerca

4.1.4 MetamorphoSys

MetamorphoSys è il software di installazione di UMLS e di per-sonalizzazione del Metatesauro incluso ad ogni rilascio di UMLS. Consente quindi di installare una o più Sorgenti di Informazione in locale e, quando il Metatesauro è selezionato, consente la persona-lizzazione [Kleinsorge et al., 2006].

Due sono gli scopi fondamentali:• escludere dei vocabolari non necessari in una determinata

ricerca o che non sono accreditati per un’applicazione locale (Figura 4.10)

• personalizzare la ricerca con particolari filtri o opzioni di uscita dei dati.

MetamorphoSys è implementato in Java ed è stato testato sui se-guenti sistemi operativi:• Sun Solaris 8 e 9;• Windows XP, NT e 2000;• Linux;• Macintosh (OS x 10.4).Il software può essere scaricato da UMLSKS oppure essere eseguito a partire da un DVD-ROM (che contiene l’applicazione e le Sor-genti di Informazione).

4.1.5 Applicazioni di UMLS

Ora che conosciamo la struttura di UMLS, riassumiamo quelle che sono le più importanti applicazioni:1. diffusione di vocabolari biomedici;2. information Retrival (IR) cioè l’insieme di tutte quelle tecni-

che che si adoperano per il recupero dei dati elettronici.In particolare:

a. espansione delle ricerche (sinonimi);Figura 4.10

Esempio di filtro di esclusione di vocabolari

b. mappatura del testo a specifiche terminologie;c. IR multi-linguale;

3. area di ricerca sulle ontologie:a. sistemi di rappresentazione delle conoscenze;b. sistemi di codifica per scopi clinici.

L’accumulo di grandi quantità di dati e di risultati di ricerche speri-mentali è stata la linea di tendenza predominante nelle scienze biome-diche durante l’ultimo decennio. Affinché tali informazioni possano produrre un approfondimento significativo delle conoscenze e delle pratiche terapeutiche occorre tuttavia disporre di valide reti informa-tive che ne garantiscano la sintesi e il recupero mirato alla luce di nuove ipotesi scientifiche [Cerveri e Pinciroli, 2001]. L’opportunità rappresentata da UMLS integra in modo decisivo il substrato biblio-grafico del database e permette a ricercatori e bibliotecari di tutto il mondo di trasformare una base dati citazionale in uno strumento potente di organizzazione e recupero dell’informazione medica al ser-vizio della pratica clinica e della ricerca primaria.

4.2 Systemized Nomenclature of Medicine (SNOMED)

L’attuale evoluzione del Sistema Qualità in Sanità ha determinato diversi problemi a causa degli elevati costi di gestione e dell’organiz-zazione dei dati clinici.

Le applicazioni informatizzate, in generale i sistemi informativi sanitari, che trattano dati clinici richiedono che tali dati [Spack-man, 2003]:• siano registrati con un adeguato livello di descrizione;• siano utilizzabili senza limitazioni spaziali o temporali;• possano essere trasmessi senza perdita o distorsione del loro

significato e senza perdita di informazione diagnostica;• possano essere utilizzabili sotto più prospettive ed anche in

contesti generali;• possano essere interpretati da calcolatore.I dati clinici, così creati, vengono utilizzati nella documentazione appartenente ad un paziente (come ad esempio la cartella clinica), nella creazione di analisi statistiche per proiezioni future, nella con-divisione di informazioni con altri operatori appartenenti anche a contesti diversi.

Gli aspetti positivi si manifestano nella riduzione di errori nella compilazione, riduzione dei costi dei test per la ridondanza della terminologia e nell’ampliamento della conoscenza di malattie e trat-tamenti, ma, d’altro canto, diventano indispensabili diverse abilità per l’interrogazione di un Data Base che le contiene e la conoscenza di criteri generali per l’effettuazione delle ricerche nello stesso.

Tutto questo ha condotto alla creazione di una terminologia di riferimento per la gestione di tali dati ovvero a una struttura com-posta da concetti e relazioni standardizzati e correlati che permette l’aggregazione e la comparazione tra dati estrapolati dal processo di “Health Care” [NHS - Connecting for Health, 2005].

In questo paragrafo si tratta il sistema terminologico Systemati-zed Nomenclature of Medicine Clinical Term (SNOMED - CT). SNOMED CT nasce dalla collaborazione tra l’organizzazione “College of American Pathologists (CAP)” statunitense e il Natio-nal Health System (NHS) della Gran Bretagna nel Gennaio 2002 come fusione di due sistemi terminologici pre-esistenti: SNOMED Reference Terminology (sviluppato dal CAP) e Clinical Terms Ver-sion 3 (sviluppato dal NHS), e può essere definito come il più am-pio vocabolario strutturato e validato dei termini specifici usati in Medicina.

Nell’aprile 2007 l’organizzazione “International Health Ter-

minology Standards Development Organisation (IHTSDO)” ha acquisito la proprietà intellettuale di SNOMED Clinical Terms (SNOMED CT) e delle terminologie sue antenate dalla organizza-zione “College of American Pathologists (CAP)” [NHS - Connec-ting for Health, 2005].

4.2.1 Le origini della Systematized Nomenclature of Medicine (SNOMED)

Il primo tentativo di classificazione in ambito medico si ebbe nel 1662 quando J. Graunt, ricco mercante londinese e collezionista d’arte, pubblicò il “Observations of the London Bills of Mortality”, una collezione di osservazioni scientifiche e politiche fatte sui Bol-lettini di Mortalità della Londra del periodo. Graunt elencò le cause di morte dei suoi concittadini ed il numero di decessi per tali cau-se, includendo anche la comparsa di malattie sconosciute all’epoca [Stephan, 2005].

In seguito molti altri esperimenti si sono susseguiti fino al 1965 quando è stato creato dall’organizzazione statunitense “College of American Pathologists (CAP)”, il Collegio dei Patologi, la termi-nologia Systematized Nomenclature of Pathology (SNOP). SNOP, con la sua struttura a quattro assi, cioè quattro tipi di categorie ge-rarchizzate, si può definire il precursore dell’attuale SNOMED an-che se utilizzabile prettamente in ambito anatomo-patologo [Som-mers, 1967].

Attraverso diverse versioni, nel Maggio 2000, SNOP si è evolu-to in SNOMED Reference Terminology (RT), ugualmente carat-terizzato da una struttura multi-assiale e con tipi di terminologia sia enumerativa che combinatoria [Spackman, 2003], [Dolin et al., 2002].

I sistemi costituiti da terminologia enumerativa:• elencano in anticipo tutti i termini possibili che potrebbero

essere usati;• risentono fortemente dello scopo per cui è costruito il sistema

di codifica;• sono soggetti a verifica continua per evitare l’effetto ridondan-

za.I sistemi costituiti da terminologia combinatoria:

• permettono di costruire termini complessi partendo da una serie di termini primari o elementari;

• necessitano di regole per la composizione anche molto com-plesse;

• utilizzano modificatori e quantificatori per la costruzione dei

termini complessi.Alcuni esempi sono mostrati in Figura 4.11.

I concetti possono anche essere classificati come [White et al., 1999]:• Pre-coordinati: un singolo identificativo di concetto rappre-

senta un concetto. Per esempio il codice “174041007” signifi-ca “appendicectomia laparoscopica d’emergenza”.

• Post-coordinati: una combinazione di identificativi rap-presenta un concetto. Ad esempio i codici “80146002: 260870009=25876001, 260507000=12938008” significano “Appendicectomia: priorità=emergenza, accesso=endoscopico” che sta per “Appendicectomia endoscopica d’emergenza”.

Dall’alleanza stipulata nel 1999, è stato presentato SNOMED CT nato nel Gennaio 2002 dalla fusione di SNOMED RT e CT Ver-sion 3 ad opera della collaborazione tra il CAP e il servizio sanitario NHS [Wang et al, 2001]. Il processo ha dovuto tener conto dei contenuti delle terminologie di partenza.

Il sistema terminologico SNOMED RT contiene:A. 121,000 concetti;B. 19,000 termini;C. 360,000 relazioni tra termini diversi.In questa classificazione, inoltre, sono state introdotte sezioni relati-ve alle sostanze chimiche “Drugs” e alle procedure infermieristiche.

Parallelamente, la terminologia “Clinical Term version 3” (CTV3) è composta da:• 200,000 concetti; • 278,000 termini.Questo multi-progetto ha impiegato più di duemila medici spe-cialisti prestando soprattutto attenzione all’individuazione delle procedure mediche ed alla classificazione della nomenclatura delle malattie.ULCERA ACUTA M38010ULCERA CICATRIZZATA M38008ULCERA CRONICA M38020ULCERA DA DECUBITO M10540ULCERA PENETRANTE M3800YULCERA PEPTICA M38090ULCERA PEPTICA PENETRANTE M3809YULCERA PEPTICA PERFORATA M38093ULCERA PEPTICA SANGUINANTE M38091ULCERA PERFORATA M38003ULCERA PIOGENICA M38400ULCERA SANGUINANTE M38001

CRONICOACUTO

MULTIPLO...

TUMOREULCERA

ULCERAZIONEURETERITE...

ULCERA + PEPTICA + PERFORATA

DESTRO SINISTROCICATRIZZATO

PERFORATAPEPTICO

SANGUINANTE...

QUANTIFICATORI

MODIFICATORI

TERMINIFigura 4.11Esempi di terminologia

enumerativa e combinatoria

4.2.2 Concetti, termini e descrizioni nelle terminologie mediche

SNOMED RT e CTV3 sono entrambe classificazioni mediche vali-date scientificamente e basate su una terminologia a concetto [Wang et al, 2001]. Un concetto è l’unità di pensiero riferito chiaramen-te ad un’unica entità ed è rappresentato da un termine ovvero una stringa di caratteri ben definita. Una descrizione è la risultante di più termini e si riferisce univocamente ad un concetto mentre un concetto, a sua volta, può possedere più definizioni.

La seguente tassonomia risulta di aiuto:• Terminologia - lista di espressioni motivate (eventualmente

affiancate da codici) con:> unicità di relazione concetto/codice,> situazioni complesse espresse tramite codici multipli;

• Vocabolario controllato - terminologia il cui uso è limitato/definito da regole;

• Nomenclatura - terminologia spesso accompagnata da un in-sieme di regole riguardanti l’uso dei termini;

• Classificazione - sistema terminologico i cui elementi sono or-ganizzati gerarchicamente secondo un qualche concetto:> unicità di relazione evento/codice, > classi mutuamente esclusive, > propensione per espressioni omnicomprensive.

Le definizioni dei termini sono di due tipi: uno chiamato “preferred name” ed un altro chiamato “Synonym”. I “preferred names” sono quelli generalmente richiesti nell’interrogazione e non sono neces-sariamente unici o pienamente specificati. Per esempio il preferred name per il termine “pain (Finding)” è “pain”. I “synonyms” sono invece inclusi nella tabelle delle Descrizioni con le abbreviazioni e gli acronimi [Wang et al, 2001]. Esempi di “preferred names” e “synonyms” sono illustrati in Tabella 4.1.

Sistemadiclassi-ficazionetermino-logica

Codiceconcetto Descrizione Tipodefinizione

SNOMEDRT D3-89550 CerebroVascularAccidentCVAStroke

PreferrednameSynonymSynonym

CTV3 X00D1 StrokeCerebroVascularAccidentCVA

PreferrednameSynonymSynonym

Tabella 4.1Esempi di “preferred names” e “synonyms”. Adattato da [Wang et al. 2001]

Per operare la fusione tra SNOMED RT e CTV3, sono state create varie mappe di corrispondenza tra le descrizioni, contenute nelle due classificazioni, ed i concetti rappresentati, mentre si sono tra-scurate le relazioni tra concetti in modo da individuare subito i si-nonimi e le potenziali ambiguità. Questo processo ha inoltre ridotto moltissimo il fenomeno della ridondanza dei concetti. Il team in-glese ha sviluppato un software in grado di distribuire ai gruppi di lavoro descrizioni appartenenti ad una specifica sezione gerarchica non più di una volta.

Questo è stato il passo fondamentale per iniziare le mappatu-re delle singole descrizioni dei concetti medici ed è stato condot-to simultaneamente sia dal gruppo di lavoro inglese sia da quello americano: i primi hanno mappato le descrizioni in SNOMED RT mentre i secondi quelle in CTV3.

I tipi di relazioni tra concetti utilizzati sono stati:• Same-as: le definizioni prese in esame sono puri sinonimi di

quella “preferita”. A loro volta le relazioni “same-as” possono essere:> lexical-semantic: la descrizione presa in esame ha lo stesso

significato e stringa descrittiva del “preferred name”;> semantic: può non avere la stessa stringa descrittiva.

• Is-a: se non si trova un concetto semanticamente equivalente nella terminologia preferita si può collegare la descrizione in esame al più vicino concetto supertipo. È un tipo di relazione che determina la gerarchia della struttura e deve essere aciclica, ovvero non devono esistere percorsi che permettano di partire ed arrivare a sé stessa.

• Unmappable: non è possibile determinare il significato della descrizione.

Si sono valutate le descrizioni, inquadrandole o come “preferred name” o come “synonym”, ma soprattutto i significati dei singoli concetti suddividendoli in supertipi, sottotipi, attributi e valori at-tributivi. Il sottotipo o sottoclasse (classe derivata) si può costrui-re usando l’ereditarietà da un altro tipo, il supertipo o superclasse (classe base). La sottoclasse è identica alla superclasse tranne che è più specializzata: una variante che contiene più informazioni. Una classe può essere sottoclasse di un’altra solo se esiste una reazione di tipo “Is-a”. L’ereditarietà non è ristretta ad un solo livello ma una cascata di livelli con relazione a senso unico.

Le gerarchie presenti in SNOMED CT sono indispensabili per navigare e per definire i concetti. Spesso sono dettate da relazioni in cui concetti figli sono spesso pre-coordinati esempi dei concetti genitori con attributi o modificatori addizionali. Per esempio “pain

in digit” e “pain in wrist” sono figli di “pain”. Le gerarchie presenti sono di due tipi:

• Definitional: sono parte della definizione dei concetti e sono caratterizzate dalle relazioni “is-a”;

• Navigational: sono indipendenti dalla definizione del concetto e possono essere modificate dall’utente e condivise.

I risultati preliminari sono mostrati nelle Tabelle 4.2 e 4.3 [Wang et al, 2001].

Sezione SNOMED RT CTV3

Anatomia 10980 9325

Malattia 27908 53794

Funzione/osservazione 6235 24753

Organismiviventi 20721 5543

Morfologia 3674 1523

Occupazione 1865 3133

Procedura 23368 27018

Sostanza/sostanzachimica 25519 31984

Tipodimappa/relazione

DaCTV3aSNO-MEDRT

DaSNOMEDRTaCTV3

Mappetotali(USeUK)

Semantica 29016 47731 76747

Is-aRelazione 99532 93142 192674

Mappetotali 128548 140873 269421

In Tabella 4.4 è mostrato un esempio di relazioni “child-parent” in SNOMED RT per l’arteriosclerosi [NCCH, 2001].

Childterm Relationship Parenttermcoronaryartery isapartof heart

heart isapartof cardiovascularsystem

cardiovascularsystem isapartof bodysystem

bodysystem isapartof physicalanatomicalentity

artherosclerosis isa vascularsclerosis

vascularsclerosis isa degenerativeabnormality

degenerativeabnormality isa morphology

coronaryartherosclerosis isa coronaryarterydisease

heartdisease isa diseaseofcardiovascularsystem

diseaseofCVsystem isa disease

È molto importante per la costruzione del sistema anche il numero delle relazioni figlio che si vuole inserire [Walker, 2004]. In Tabella 4.5 sono elencati alcuni tra i 20 concetti aventi il maggior numero di relazioni “child-of” presenti in SNOMED CT.

Tabella 4.2Concetti totali selezionati sulle aree specifiche da SNOMED RT e CTV3

Tabella 4.3Risultati della mappatura preliminare

Tabella 4.4Esempio di rappresentazioni di un concetto in SNOMED RT. Adattato da [NCCH, 2001]

Nome concetto Conteggio figli Nome concetto Conteggio

figliVeterinaryproprietarydrugAND/ORbiological(product)

2532 Intentionaldrugoverdose(disorder)

Biochemicaltest(procedure)

1002 Generaladjectivalmodi-fier(qualifiervalue)

Hydrolase(substance) 766 Accidentaldrugoverdose(disorder)

Assessmentscale(assessmentscale)

722 Non-humandisorderbybody-site(disorder)

In Tabella 4.6 è, invece, illustrato un esempio di tipi di relazioni tra concetti.

Concetti Concetto relativo Tipo di relazioneCoughfractureofrib Fractureofrib(disorder) Is-a

Bonestructureofrib(bodystructure)

Findingsite

Fracture(morphologicabnormality)

Morphologysite

Questa modalità di strutturazione è utile nelle fasi di ricerca, infatti un utente per ricercare un termine può scegliere di utilizzare:• “similar concepts” secondo una ricerca non gerarchica. Per

esempio se si cerca “chest pain” alcuni termini concetti che si trovano sono: “acute chest pain”, “left side chest pain”, “car-diac syndrome X” e si arriva ad un totale di 23 concetti;

• “keyword” utilizzando una parola chiave e relazioni non ge-rarchiche. Per esempio alcuni concetti che si possono trovare effettuando la ricerca con parola chiave “chest pain” sono: “left side chest pain”, “precordial pain” e “upper chest pain” sino ad arrivare ad un totale pari a 33 concetti;

• “keyword” disabilitando le relazioni non gerarchiche si otten-gono invece solo 15 concetti [Walker, 2004].

4.2.3 L’organizzazione SNOMED

Nel periodo dell’alleanza con il sistema NHS e prima del 2007, SNOMED International è stata una organizzazione interdiscipli-nare composta dai membri del College of American Pathologist (CAP), esperti clinici, esperti di informatica medica, rappresen-tanti della United Kingdom’s National Health Service, tradutto-ri, redattori, validatori, medici, infermieri e direttori scientifici [SNOMED International, 2005]. L’organigramma è mostrato in Figura 4.12.

Tabella 4.6Esempio di tipi di

relazioni tra concetti in SNOMED CT

Tabella 4.5 Alcuni tra i 20 concetti

aventi il maggior numero di relazioni

figlio

L’organizzazione è suddivisa in quattro aree:1 CAP: è una società che comprende circa 16,000 membri e

diversi laboratori in tutto il mondo. È composta da patolo-gi ed è, la maggiormente accreditata per l’assicurazione della qualità nei laboratori. Il 30 Settembre 2003 è stata nominata organizzazione per lo sviluppo di Standard “American Natio-nal Standards Institute (ANSI) standards developer”. Questa organizzazione si preoccupa di:• non perdere il valore della standardizzazione a causa della

frammentazione a lungo termine del nucleo della termino-logia;

• rendere SNOMED la risposta alle necessità dei Governi di computerizzare i dati medici;

• proteggere gli investimenti dei Governi tramite self-funding models per la collaborazione e la contribuzione piuttosto che su licenze di utilizzo individuali;

• mantenere ridotti i costi per quei Governi che stipulano un contratto per lungo periodo.

2 SNOMED International Authority: autorità sottostante al CAP con la responsabilità delle attività relative alla terminologia.

3 SNOMED International Editorial Board: responsabile della direzione scientifica, dei processi editoriali, della validazio-ne scientifica della terminologia [SNOMED International, 2005]. La struttura interna dell’Editorial Board è mostrata in Figura 4.13.

COLLEGE OF AMERICAN PATHOLOGISTS BOARD OF GOVERNORS

Executive Vice President

Terminology ModelersCAP/NHS/Kaiser

SNOMED Users

Other Collaborators

Working GroupsTranslators/Validators

SNOMED International Editorial BoardDomain Experts

Informatics ExpertsClinical & Standards Liaisons

SNOMED StaffOperationsEducationLicensing

SNOMED International Authority

Figura 4.12Organigramma dell’organizzazione SNOMED International

4 SNOMED Gruppi di lavoro: responsabili dello sviluppo pratico del progetto. Hanno mansioni differenziate: a partire dell’immissione di dati fino ad arrivare alla revisione di questi ultimi. Esistono due tipologie di gruppo di lavoro Clinical e Technical e sono mostrati in Tabella 4.7 con i relativi sotto-gruppi [SNOMED International, 2005].

Clinical TechnicalGenomicsMappingNursingPrimaryCarePharmaceuticalsPublicHealthSurgery/AnesthesiaSurgicalPathology

ConceptModelGuidelines

4.2.4 SNOMED CT

4.2.4.1 Il processo di costruzione di SNOMED CTSNOMED CT è il più ampio vocabolario strutturato dei termini tecnici usati in Medicina e al 12 Maggio 2005 [SNOMED Interna-tional, 2005] conteneva: > 287,000 concetti;> 2,000,000 termini:

• 715,000 (Inglese);• 620,000 (Tedesco);• 613,000 (Spagnolo);

> 1,025,000 relazioni definizionali;> 420,000 relazioni qualificative;> 70,000 relazioni addizionali;> estensioni: “Cancer Checklist” in costruzione per enumerare tut-

te le forme di cancro adulto, US Drugs, Anesthesiology.

Technical Working Group

Clinical Content Working Group

Core Design Team

SNOMED International Editor Board

Domain Specific Working Group

Figura 4.13Struttura dello Editorial Board

dell’organizzazione SNOMED International

Tabella 4.7Attività dei gruppo

si lavoro suddivisi in Clinical e Technical

SNOMED CT è stato adottato da entità governative, organizzazio-ni sanitarie e produttori di software in 30 paesi nel mondo, tra cui anche l’Italia.

L’effettivo processo di sviluppo di SNOMED CT è stato suddi-viso in sei stadi [Wang et al, 2001]:

1. Start-up e initiation: nomina dei rappresentanti inglesi ed americani appartenenti alla SNOMED International Authority, allo SNOMED International Editorial Board, allo SNOMED CT Design Team ed ai vari working group. In questo stadio è stato an-che tracciato un prototipo per mappare i concetti semanticamente equivalenti in SNOMED RT e CTV3.

2. Terminology design: in questo stadio sono stati redatti docu-menti che avrebbero definito le funzionalità e la struttura di SNO-MED CT. Questi documenti descrivono:

• il risultato rappresentato da SNOMED CT,• la Struttura portante,• i meccanismi dei sottogruppi,• l’analisi delle richieste di sviluppo,• proposte di strutture per le tabelle di cross-mapping,

Sempre in questo stadio sono stati fusi i livelli superiori delle gerar-chie di SNOMED RT e CTV3.

3. Production: in questo stadio è stato effettuato l’accorpamento delle descrizioni dei concetti in SNOMED RT e in CTV3 seguen-do le seguenti fasi:

• Description mapping: creazione di mappe tra concetti equi-valenti semanticamente. In questa fase si risolvono anche i conflitti dovuti alla presenza di sinonimi.

• Concept modeling: riempimento delle tabelle di SNOMED CT seguendo i livelli gerarchici. In questa fase sono state eliminate le descrizioni ed i termini ridondanti e si sono introdotti gli attributi.

• Terminology Refinements: sono stati assegnati nomi specifici ai concetti ed introdotti anche nuovi concetti come descrit-to precedentemente.

4. Alpha test: l’Editorial Board ha autorizzato vari test per la valutazione del funzionamento della struttura di SNOMED CT. Questi test sono stati limitati a sei domini clinici:

• orbital region procedures,• orbital region disorder, • urinary system disorder, • urinary system procedures, • respiratory system infectious disorders, • breast neoplams.

Sono test effettuati da chi ha sviluppato il sistema.5. Beta test: tutti i dati sono stati messi a disposizione di gruppi

esterni interessati per la valutazione. In questo stadio si è effettuato il raffinamento degli stessi dati. Esso consiste nell’applicazione di un valore più specifico per definire una caratteristica. Per esempio il concetto “frattura del femore” è stato definito inizialmente tramite il “sito di individuazione=struttura ossea del femore” ed in seguito, tramite raffinamento, dal “sito di individuazione=struttura del collo del femore” e quindi alla fine la sua definizione consiste in “frattura del collo del femore”.

6. Release process: si sono effettuati i controlli della qualità per l’integrità e la correttezza dei dati inseriti nello stadio 3.

SNOMED CT quindi si presenta come una terminologia medi-ca validata scientificamente in grado di rendere i dati sanitari più fa-cilmente manipolabili. Gli aggiornamenti sono, inoltre, disponibili due volte all’anno in Gennaio e Giugno.

La sua forte innovazione è nel progetto che, a differenza di altri sistemi di classificazione quali MeSH, SNOMED RT e CTV3, non è ideato da un singolo gruppo di lavoro per una realtà ben con-testualizzata, ma da una task force tramite una fusione corretta e riveduta di due sistemi terminologici (SNOMED RT e CTV3) a larga scala [Walker, 2004].

4.2.4.2 La struttura di SNOMED CTSNOMED CT è una struttura complessa per via di alcuni fattori:• l’alto numero di dati inseriti e la loro relativa precisione;• l’elevato numero di concetti pre-coordinati;• le gerarchie estese che spesso sono costituite da figli che sono

una modifica pre-coordinata dei padri. Per esempio “pain” ha

History Mechanism

Subset Mechanism

Complements

Navigations Hierarchies

Duplicate Terms

Canonical Table

Word Equivalents

Terminology Browser

Indexes

Subsets

Subsets Editor

Cross Map Targets

Cross Maps

Cross Map Sets

Cross-Mapping Mechanism

RelationshipsDescriptions

Concepts

Core TablesExtensions

SubsetMembers

Historical RelationshipsComponent

History

Subset

Figura 4.14Struttura dei dati in

SNOMED CTAdattato da

[Walker, 2004]

come figlio “pain of the ankle” così come anche altri diversi tipi di pain come “headache”. La pre-coordinazione deriva dal desiderio di importare direttamente la terminologia dall’In-ternational Classification of Desease (ICD9), altro sistema di classificazione molto utilizzato;

• le relazioni non gerarchiche estese spesso sono non clinica-mente intuitive [Walker, 2004].

Tutti i sostantivi, gli eponomi e gli altri componenti del linguag-gio medico sono compresi nella raccolta sistematica di nomi SNO-MED CT mediante un linguaggio codificato che rende possibile l’aggregazione, la raccolta e la condivisione dei dati medici attraver-so tutte le varie specializzazioni.

SNOMED CT è diviso in:1. SNOMED CT Core tables: include le tabelle dei concetti, le

descrizioni delle tabelle, le relazioni tra le stesse, la loro storia e la guida ai riferimenti tecnici. Le Figure 4.14 e 4.15 e sono tratte dalla “Technical Implementation Guide” e illustrano la struttura dei dati in SMOMED CT. Come si deduce dalla Figura 4.15 il sistema di SNOMED CT è supportato da 3 tabelle base: “Concetti”, “Descrizioni” e “Relazionioni”, tutte

History Mechanism

Subset Mechanism

Cross Map Targets

Cross Maps

Cross Map Sets

Cross-Mapping Mechanism

ConceptsCore Tables

Extensions

Subset Members

Historical Relationships

Component HistoryUses Relationships Structure

* ComponentID* Release Version

ChangeStatusReason

* SubsetID* MemberID* MemberStatus

LinkedID

* SubsetID

Subset Original IDSubset VersionSubset NameSubset TypeLanguage CodeRealm IDContext ID

* Relationship ID

Concept ID1Relationship TypeConcept ID2Characteristic TypeRefinabilityRelationship Group

* Description ID

DescriptionStatusConcept IDTermInitial Capital StatusDescription TypeLanguage Code

* ConceptID

ConceptStatusFully Specified NameCTV3IDSNOMED IDIs Primitive

* Target ID

Target Scheme IDTarget CodesTarget RuleTarget Advice

* MapSet ID* Map Concept ID* Map Option

Map PriorityMap Target IDMap RuleMap Advice

* MapSet ID

MapSet NameMapSet TypeMapSet Scheme IDMapSet Scheme NameMapSet Scheme VersionMapSet Realm IDMapSet SeparatorMapSet Rule Type

Subset

* Denotes key field

Figura 4.15Dettaglio della struttura dei dati in SNOMED CTAdattato da [Walker, 2004]

con un formato di testo “tab delimited”: tale formato usa un carattere di tabulazione (HT, Horizontal Tab, ASCII 09) come separatore di campo all’interno dei record e la coppia CR+LF (ASCII 10+13) come separatore di record; può essere impor-tato e dunque utilizzato per compiere ricerche in moltissimi programmi database e spreadsheet (fogli di calcolo) su tutte le piattaforme PC esistenti.

2. Estensioni: sezioni aggiuntive contenenti particolari termino-logie, per esempio “Drugs Extension” riguardante i farmaci.

Esiste, inoltre, un framework che dà la possibilità di integrare il Core con termini specifici usati in una particolare area geografica o ente sanitario, anche tramite l’uso di qualificatori. I qualificatori applicano un valore ad una caratteristica qualificante. Per esempio “Bronchite” ha come qualificatore “course” a cui può essere assegna-to il valore “course=acute” e quindi si ha “Bronchite acuta”.

Come già spiegato, ogni concetto elementare viene definito ter-mine ed è individuato, nel linguaggio naturale, da una o più parole (es. stomaco, orecchio destro). Sono stati fissati dei grandi raggrup-pamenti logici dei concetti elementari ed ogni termine è associato ad uno solo di questi gruppi. I raggruppamenti sono definiti moduli e costituiscono le tracce principali entro le quali tutti i termini tro-vano una collocazione logica, a partire da concetti generali molto ampi per scendere a dettagli sempre più analitici. L’organizzazione in moduli, con multipli livelli di precisione scolare, motiva l’aggetti-vo “sistematica” attribuito a “classificazione”. Per esempio abbiamo “trombosi”(=M35100) e “trombosi parietale”=(M35130). Quindi, riassumendo, i termini corrispondono a concetti medici, i codici sono distinti per ogni concetto, i gruppi sono un insieme di codici simili e le gerarchie sono processi di raggruppamento gerarchico secondo un qualche attributo o concetto.

Ad ogni termine considerato in SNOMED CT viene assegna-to un codice alfanumerico di 5-6 cifre, che è la rappresentazione simbolica sintetica del concetto elementare. Per esempio, nella ver-sione di SNOMED III, uno dei predecessori di SNOMED CT, “T-28210” è il codice usato per “segmento apicale del lobo superiore del polmone destro” dove “T” sta per Topografia, “2” per sistema respiratorio, “8” per polmone, “2” per lobo superiore e “10” per segmento.

4.2.4.2.1 Tabelle aggiuntive in SNOMED CTIn aggiunta alle tre tabelle principali in SNOMED CT ne esistono altre che includono:

• cross-mapping verso le terminologie Logical Observation Identifiers Names and Codes (LOINC®), International Clas-sification of Diseases, Ninth Revision (ICD-9) e International Classification of Diseases for Oncology (ICD-O);

• sottoinsiemi: semplici dati o dati non relativi all’uomo;• storia: annotazioni dei cambiamenti dei dati tra le varie ver-

sioni;• relazioni canoniche: di supporto alla conversione tra concetti

pre-coordinati e post-coordinati;• dati “keyword”: indici pre-generati per assistere nella ricerca

di una frase;• dati “exclusion”: per escludere parole non desiderate durante

la ricerca;• dati “equivalence”: per convertire i termini designati nella ri-

cerca in espressioni alternative;• gerarchie navigazionali: per trovare facilmente la locazione cli-

nica di gruppi di concetto rilevanti;• termini duplicati: tool per identificare i termini duplicati

[Walker, 2004].In Figura 4.16 sono mostrati i collegamenti verso queste tabelle ad-dizionali chiamate anche “developer toolkit”.

4.2.4.2.2 Moduli di SNOMED CTLa versione di SNOMED CT aggiornata al Maggio 2005 contiene 18 assi [SNOMED International, 2005]. Gli assi di SNOMED CT

ConceptsCore Tables

Navigation Hierarchies

Duplicate Terms

Uses SubSet Mechanism

* Relationship ID

Concept ID1Relationship TypeConcept ID2Characteristic TypeRefinabilityRelationship Group

* Description ID

DescriptionStatusConcept IDTermInitial Capital StatusDescription TypeLanguage Code

* ConceptID

ConceptStatusFully Specifed NameCTV£IDSNOMED IDIs Primitive

* Denotes key field

Canonical Table

* Concept ID 1* Relationship Type* Concept ID2

Relationship Group

No-Human SubSet

Uses SubSet Mechanism

Word Equivalents

* Word Block Number* Word Test

Word TypeWord Role

Conc Word Key

* Keyword* ConceptID

Conc Dual Key

* Dualkey* ConceptID

Excluded Words

* Language Code* Keyword

Desc Word Key

Indexes

* Keyword* DescriptionID

Desc Dual Key

* Dualkey* DescriptionID

Figura 4.16Collegamenti tra il Core di SNOMED CT e le tabelle “developer toolkit” Adattato da [Walker, 2004]

sono suddivisi in due gruppi:• Gerarchie principali che comprendono:

Clinical finding;Procedure;

• Gerarchie di supporto che comprendono:Observable entity; Body structure; Organism; Substance; Pharmaceutical/Biological product; Specimen; Physical object; Physical force; Event; Environments and geographical locations; Social context; Context-dependent categories; Staging and scales; Attribute; Qualifier value;Special concept.

Verranno ora brevemente illustrati i significati dei 18 assi.1 Clinical finding (= Individuazione clinica): i concetti con-

tenuti in questo modulo rappresentano i risultati di una os-servazione clinica, di una valutazione o di un giudizio. Alcuni esempi di concetti contenuti all’interno di questo modulo sono: “Appendicite”, “Dolore”. Un esempio di codice è “Difficulty walking”=”F-18003”.

2 Procedures (= Procedure): i concetti contenuti in questo modu-lo rappresentano le attività utili nel perseguimento della salute. Questo modulo comprende una grande varietà di attività come per esempio le procedure invasive chirurgiche, le procedure rela-tive alla gestione delle bioimmagini e le procedure amministra-tive. Alcuni esempi di concetti contenuti all’interno di questo modulo sono: “Registrazione del paziente”, “Controllo dell’epi-stassi tramite cauterizzazione”. Un esempio di codice è “sutura del fegato”=”P1-5B810”.

3 Observable entities (= Entità osservabili): i concetti contenuti in questo modulo possono essere pensate come la combinazione tra una domanda ed una procedura che costituisce una individua-zione. Per esempio “Pressione diastolica finale del ventricolo sini-stro” può essere interpretata come la risposta alla domanda “Qual

è la pressione diastolica finale nel ventricolo sinistro?”. Tuttavia quando si dà un valore reale alla “Pressione finale diastolica del ventricolo sinistro” questo diventa un Finding infatti il concetto “Pressione diastolica finale del ventricolo sinistro” è contenuta in Clinical Finding perché è qualificata dal termine “Incrementata”. Altri esempi di concetti contenuti in questo modulo sono: “Cir-conferenza del cranio” e “Temperatura”.

4 Body structure (= Struttura del corpo): i concetti contenuti in questo modulo contengono sia le strutture anatomiche norma-li ed anormali. In Figura 4.17 è illustrato che è fondamentale definire un organo anatomico (nell’esempio il “Fegato”) come “Intero” o “Parte di”.

5 Organismi (= Organismo): i concetti contenuti in questo modu-lo rappresentano agenti eziologici nelle malattie umane ed ani-mali. Essi sono fondamentali per il controllo della Pubblica Sa-nità soprattutto in relazione ai sistemi decisionali clinici in caso di protocolli contro le epidemie. Gli organismi comprendono: batteri, funghi, virus, parassiti, animali e piante. Un esempio di codice è “Amanita”=“L-42220”.

6 Substances (= Sostanze): i concetti contenuti in questo modulo possono essere usati per la registrazione dei costituenti chimici dei farmaci, dei cibi, degli allergeni chimici e per le informazioni riguardanti avvelenamenti e tossicità. Sono costituenti generici e sono collegati a Procedure tramite gli attributi “agente causa di”, “sostanza diretta” e “componenti”. Altri esempi di concetti contenuti in questo modulo sono: “Insulina” e “Acetaminofene”. Esempio di codice è “Insecticide”=“C-23100”.

7 Pharmaceutical / biologic products (= Prodotti farmaceutici / biologici): i concetti contenuti in questo modulo servono a distin-guere i costituenti chimici contenuti nel modulo Substances dai prodotti chimici e dai farmaci. I farmaci generici sono inseriti in SNOMED CT corredati di nome, dose e potenza del farmaco.

8 Specimens (= Esemplari): i concetti contenuti in questo mo-dulo rappresentano entità che sono ottenute dall’analisi dei dati raccolti esaminando un paziente. Essi sono definiti in rapporto alle strutture corporee normali e anormali dai quali sono ottenu-ti, alle procedure usate per raccoglierli, alla risorsa da cui sono

Liver StructureCTV3 Liver Structure

Liver PartRT Liver Part

Entire Liver CTV3 Liver

IS-A IS-A

Figura 4.17Distinzione tra concetto “Intero” e concetto “Parte di”

estrapolati ed alla sostanza contenuta nella risorsa. Un esempio di concetto contenuto in questo modulo è “Esemplari di unghie”.

9 Physical object (= Oggetto fisico): i concetti contenuti in que-sto modulo comprendono oggetti trovati in natura e oggetti fatti dall’uomo. Sono utilizzati in rapporto soprattutto ad incidenti. Alcuni esempi di concetti contenuti in questo modulo sono “Ro-bot” e “Organi artificiali”.

10 Physical forces (= Forze fisiche): i concetti contenuti in questo modulo sono: Moto, Attrito, Gravità, Elettricità, Magnetismo, Suono, Radiazioni, Forze termiche (caldo e freddo), Umidità e Pressione dell’aria. Alcuni esempi di concetti contenuti in questo modulo sono “Fuoco” e “Gravità”. Un esempio di codice è “Scu-ba diving”=“A-71830” [Wang et al, 2001].

11 Events (= Eventi): i concetti contenuti in questo modulo rap-presentano i risultati di incidenti mentre escludono le procedure e gli interventi. Alcuni esempi di concetti contenuti in questo modulo sono: “Inondazione” e “Incidenti con veicoli a motore”.

12 Environments and geographical location (= Locazione geogra-fica ed ambientale): questo modulo contiene tipi di locazioni quali nomi di paesi, stati e regioni. Alcuni esempi di concetti contenuti in questo modulo sono: “California” e “Sala operatoria”.

13 Social context (= Contesti sociali): i concetti contenuti in que-sto modulo rappresentano condizioni sociali e particolari condi-zioni di rilevanza sanitaria come lo stato di famiglia, lo stato eco-nomico, l’etnia, la religione e il lavoro. Alcuni esempi di concetti contenuti in questo modulo sono: “Stato economico (concetto sociale)” e “Africano (gruppo etnico)”.

14 Context-dependent categories (= Categorie dipendenti dal contesto): i concetti contenuti in questo modulo sono utilizzati per aumentare il significato di altri concetti medici, definendone il contesto di utilizzo. Un esempio di concetto contenuto in que-sto modulo è “Storia familiare di infarto miocardio”.

15 Staging and scales (= Organizzazione e scale): i concetti conte-nuti in questo modulo rappresentano scale di valutazione e siste-mi di organizzazione dei tumori. Alcuni esempi di concetti con-tenuti in questo modulo sono: “Glasgow coma scale (assessment

PNEUMONIA Finding-Site

Relationship Concept 2Concept 1

AttributeFigura 4.18Utilizzo degli attributi

tra due concetti

scale)” e “Dukes staging system (tumor staging)”.16 Attributes (= Attributi): i concetti contenuti in questo modulo

sono utilizzati per collegare fra loro due diversi concetti. Possono essere caratteristici del concetto od aggiungere significato. In Fi-gura 4.18 è illustrato un esempio di utilizzo di attributi.

17 Qualifier value (= valore Qualificato): questi concetti sono va-lori per gli Attributi in SNOMED CT tuttavia molti attributi derivano da altri moduli, per esempio “Individuazione della lo-cazione” può avere il valore “Lunghezza del polmone” che deriva dal modulo Body Structure. Alcuni esempi di concetti contenuti in questo modulo sono: “Bilaterale” e “Ridotto”

18 Special concepts (= Concetti speciali): Questo modulo ha tre sotto-gerarchie:

• Inactive concepts: i supertipi ancestrali di tutti i concetti inat-tivi;

• Navigation concepts: i supertipi “genitori” di tutti i concetti navigation;

• Namespace concepts: i supertipi “genitori” di tutti i concetti namespace.

In Figura 4.19 è mostrato il numero di concetti per ognuno di que-sti assi [Markwell, 2005].

La Figura 4.20 rappresenta un diagramma UML che illustra i percorsi che collegano, tramite relazione “Is-a”, i diversi assi di SNOMED e “concept”. Seguendo le frecce a ritroso si osserva che Procedure è collegato a Clinical finding dall’asse Observable finding

Figura 4.19Aereogramma rappresentante il numero dei concetti per i 18 assi di SNOMED CT (Versione di gennaio 2004) Adattato da [Markwell, 2005]

mentre Clinical finding è collegato ai restanti assi attraverso gli attri-buti. La linea sottile nera indica che alcuni attributi possono avere un collegamento a valori applicabili che definiscono maggiormente il concetto [ISO/TC 215 WG3, 2004].

4.2.4.2.3 Struttura dei dati di SNOMED CTIn Figura 4.21 è riportata la struttura dei codici di SNOMED CT. Sono contenute le seguenti parti:• Item ID: identificatore;• Namespace ID: da usare per sviluppi locali ed implementa-

zioni;• Partition ID:

00 Concetti,01 Descrizioni,02 Relazioni,03 Sottogruppi;

• Check-digit: come controllo.

Terminological model

person/people

observable finding

interprets

keyIS_A link (UML notation)Defining AttributeApplicable valueCore concept

interpretationshas_interpretation

procedure

geographical + environments

events

complex finding

associated finding

clinical finding

associatedfunction/activity

object

physical agent

organism

substance

morphologies

embryologicstructure

anatomy

abnormal locationanatomical siteStructural embryological defect

episodicity

course

morphology

severity

numberexternal cause

causativeagent

subject of information

place of occurrence

value only

concept

function + activity

Figura 4.20Diagramma UML che

rappresenta i vari collegamenti tra moduli

e “concetto” Adattato da [ISO/TC 215 WG3,

Figura 4.21Struttura notazionale

dei codici di SNOMED CT

SNOMED CT Concept identifier for Pneumonia

Item ID Namespace ID

Partition ID

Check-digit

55679 00 8

In Figura 4.22 è illustrato un esempio dell’utilizzo della sovra citata struttura della notazione di SNOMED CT.

La tabella dei “Concetti” contiene tutti gli identificatori dei concetti ed il loro nome specifico, contando più di 357,000 record. Alcuni esempi sono mostrati in Tabella 4.8 [Walker, 2004].

ConceptID Conceptstatus

Fullyspecifiedname CTV3 SNOMEDID Isprimitive

369445005 0 Chronicproctocolis(disorder) XUU7a D5-45285 1

369446006 0Chronicproctoco-lis,patchy(disorder)

XUU7b D5-45286 1

369447002 0

Malignanttumorinvolvingrectumbydirectextensionfromendometrium(disorder)

XUU7d D5-F140A 1

La tabella “Descrizioni” contiene tutti i nomi dei concetti usati in SNOMED CT. Questi includono pienamente i nomi specifici mostrati nella tabella dei Concetti, quindi i “preferred names” ed i “synonyms”, per un totale di 984,000 records circa. Alcuni esempi sono mostrati in Tabella 4.9.

DescriptionID Description

StatusConceptID Term Initialcapital

satusDescription

TypeLanguagecode

740302015 0 14679004 Occupation 0 3 En

451353015 0 158744001Administrator-top(occupation)

0 3 En

La tabella “Relazioni” specifica le relazioni tra concetti ed il tipo di ogni relazione: “characteristic”, “refinability”, “relationship-group”. Al suo interno sono inseriti circa 1,450,000 record Alcuni esempi sono mostrati in Tabella 4.10.

Figura 4.22Esempio di utilizzo della struttura rotazionale di SNOMED CT

Tabella 4.8Esempi di dati per la tabella “Concetti”

Tabella 4.9Esempi di dati per la tabella “Descrizioni”

Concept id Fully specified name

Preferred Term

Synonyma

807580015

112640014

112644017

112642018

112643011 Bronconeumonia

Lobular pneumonia

Bronchial pneumonia

Bronchopneumonia

Bronchopneumonia (disorder)

67814005

RelationshipID ConceptID1 Relationshiptype

ConceptID2 Characteristictype

Refinability Relationshipgroup

100000028 280844000 116680003 71737002 0 0 01000002029 10002003 260686004 129304002 0 0 1

Tutti questi tipi di dati sono memorizzati in un Data-Base, con-vertiti e manipolati sino ad ottenere una struttura compatibile al poly-browser nel quale vengono, alla fine, importati. Il poly-brow-ser contiene strumenti che aiutano nella creazione di relazioni che definiscono concetti [University of Adelaide, 2005].

Le relazioni sono di due tipi: “gerarchico” e “non gerarchico”. Come già detto, una relazione gerarchica è del tipo “is-a” e non in-clude, quindi, delle relazioni “cycle” o “duplicated”. Il poly-browser quando viene avviato effettua i seguenti test ed operazioni:• test per la ricerca di relazioni gerarchiche cicliche;• test per la ridondanza;• conteggio dei figli;• costruzione di parole chiave;• ricostruzione del lessico del poly-browser.Nella Tabella 4.11 è mostrato il contenuto da una videata del poly-browser, mentre nelle Tabelle 4.12a, 4.12b e 4.12c sono mostrate le gerarchie possibili per “Acute appendicitis” che è dotata di tre “ge-nitori” [Walker, 2004], si può cioè arrivare ad “Acute appendicitis” tramite tre diversi percorsi:

Concepts and their ParentsParent Children Codes Terms0 5 TOP CONCEPT 0 01 1 Top SNOMED-CT Concept 2 11 19 SNOMED CT Concept (SNOMED RT + CT V3) 2 7Children of: “SNOMED CT Concept (SNOMED RT + CT V3)”

51 Attribute (attribute) 2 23 Body structure (body structure ) 2 322 Context-dependent categories (context-dependent category) 2 241 Disease(disorder) 2 152 Environments and geographical locations (environment/location) 2 23 Events (event) 2 310 Finding (finding) 2 213 Observable entity (observable entity) 2 21 Organism (organism) 2 244 Pharmaceutical/biologic product (product) 2 522 Physical force (physical force) 2 38 Physical object (physical object) 2 610 Procedure (procedure) 2 34 Qualifier value (qualifier value) 2 210 Social context (social concept) 2 33 Special concept (special concept) 2 2… … … …

Tabella 4.10Esempi di dati per la

tabella “Relazioni”

Tabella 4.11Dalla videata del

livello superiore della gerarchia in SNOMED

CT. Adattato da [Walker, 2004]

1. disease (disorder) – desease by body site – disease of trunk – disease of abdomen – disease of intestine – disease of large in-testine – inflammation of large intestine – appendicitis – acute appendicitis;

2. disease (disorder) – desease by body site – disorder of body system – disease of digestive system – acute digestive system disorder – acute appendicitis;

3. disease (disorder) – acute disease – acute inflammatory disease – acute appendicitis.

In Figura 4.23 è mostrata una videata del Poly-browser and Au-thoring tool (PAT) con le relazioni ed i codici relativi ad “Acute appendicitis” [Walker, 2004].

Concepts and their ParentsParent Children Codes Terms0 5 TOP CONCEPT 0 01 1 Top SNOMED-CT Concept 2 11 19 SNOMED CT Concept (SNOMED RT + CT V3) 2 71 41 Disease(disorder) 2 151 78 Disease by body site (disorder) 2 21 131 Disease of trunk (disorder) 2 21 107 Disease of abdomen (disorder) 2 22 79 Disease of intestine (disorder) 2 73 50 Disease of large intestine (disorder) 2 34 12 Inflammation of large intestine (disorder) 2 22 19 Appendicitis (disorder) 2 33 10 Acute appendicitis (disorder) 2 3Children of: “Acute appendicitis (disorder)”

0 [O]Acute appendicitis NOS (disorder) 2 20 Acute appendicitis with peritoneal abscess (disorder) 2 25 Acute appendicitis with peritonitis (disorder) 2 20 Acute appendicitis without peritonitis (disorder) 2 30 Acute focal appendicitis (disorder) 2 21 Acute fulminating appendicitis (disorder) 2 21 Acute gangrenous appendicitis (disorder) 2 21 Acute obstructive appendicitis (disorder) 2 33 Acute perforated appendicitis (disorder) 2 20 Acute suppurative appendicitis (disorder) 2 2

Tabella 4.12aDalla videata contenente la prima gerarchia per “Acute appendicitis”. “Acute appendicitis” ha tre genitori. Adattato da [Walker, 2004]

Concepts and their ParentsParent Children Codes Terms0 5 TOP CONCEPT 0 01 1 Top SNOMED-CT Concept 2 11 19 SNOMED CT Concept (SNOMED RT + CT V3) 2 71 41 Disease(disorder) 2 151 78 Disease by body site (disorder) 2 21 27 Disorder of body system (disorder) 2 21 31 Disease of digestive system (disorder) 2 62 50 Acute digestive system disorder (disorder) 2 23 10 Acute appendicitis (disorder) 2 3Children of: “Acute appendicitis (disorder)”

Concepts and their ParentsParent Children Codes Terms0 5 TOP CONCEPT 0 01 1 Top SNOMED-CT Concept 2 11 19 SNOMED CT Concept (SNOMED RT + CT V3) 2 71 41 Disease(disorder) 2 151 29 Acute disease(disorder) 2 31 98 Acute inflammatory disease(disorder) 2 33 10 Acute appendicitis (disorder) 2 3Children of: “Acute appendicitis (disorder)”

Tabella 4.12bDalla videata contenente la seconda gerarchia per “Acute appendicitis”. “Acute appendicitis” ha tre genitori. Adattato da [Walker, 2004]

Tabella 4.12cDalla videata contenente la terza gerarchia per “Acute appendicitis”. “Acute appendicitis” ha tre genitori. Adattato da [Walker, 2004]

4.2.5 Elementi di valutazione e conclusioni

L’American National Standards Institute (ANSI) ha designato SNOMED CT come struttura esempio per la terminologia stan-dardizzata in grado di erogare un dato con codifica standard per la diffusione delle informazioni mediche. In questo capitolo verranno considerati gli aspetti positivi e i punti critici di SNOMED CT.

4.2.5.1 Aspetti positiviI benefici derivanti dall’uso di SNOMED CT sono:• chiunque appartenente al National Health System (NHS) uti-

lizza lo stesso linguaggio per descrivere le condizioni cliniche o i trattamenti riguardanti un paziente;

• si utilizza un unico sistema di terminologie, aggiornato e mo-nitorato da una unica organizzazione;

• è possibile uno scambio di dati clinici di notevole portata;• è semplificato il data-entry dei dati dei pazienti;• sono possibili un’analisi ed una ricerca basate su un’unica e co-

mune comprensione dei termini medici, sotto forma di codici. John Lumpkin, direttore della National Committee on Vital and Health Statistic, nel 2003, ha affermato: “Questa iniziativa [SNO-MED] porterà alla fondazione della prima generazione di dati elet-tronici in forma standardizzata, presto verrà il tempo in cui i sistemi sanitari potranno inter-operare senza problemi”.

Gli esperti di tutto il mondo sostengono che una terminologia standard di riferimento clinico sia la chiave di volta per la costruzio-ne di un sistema basato su dati sanitari elettronici (EHR). Questo perché la riduzione della variabilità di raccolta, codifica ed utilizzo

Figura 4.23Relazioni e codici per “Acute appendicitis”. Adattato da [Walker, 2004]

dei dati medici è un punto critico nella cura dei pazienti e nella ricerca scientifica [Health Data Management, 2003].

SNOMED CT è in grado, inoltre, di interagire con altre classi-ficazioni mediche quali: ICD-9-CM, ICD-10, ICD-3, OPCS-4 ed allinearsi ad altri standard per la comunicazione come HL7, Digi-tal imaging and Communications in Medicine (DICOM), XML, ANSI e ISO. SNOMED CT ha anche incorporato il “Logical Ob-servation Identifier Names and Codes” (LOINC), il Data Base più usato per la condivisione dei risultati di laboratorio. Questo sarà il primo passo verso la progettazione di smart-cards contenenti i re-cords medici di un paziente, che potranno essere aggiornate in tutto il mondo periodicamente o, all’occorrenza, tramite un processo la cui sicurezza sia stata validata. Un esempio di questo nuovo proget-to è dato dalla Smart-card che la regione Lombardia ha sviluppato in collaborazione col Sistema Informativo Socio-Sanitario.

Con l’utilizzo di SNOMED CT sarà possibile un largo uso di dati in formato digitale. Questo porterà a diverse migliorie:• consegna dati del paziente: abilità ad inviare e ricevere dati me-

dici in un formato semplice a comprensibile a tutti in modo da ridurre duplicati tra i referti e le prescrizioni;

• gestione della cura del paziente: sviluppo delle misurazioni dei risultati e delle osservazioni rilevanti verso il paziente;

• processo di supporto al paziente: la qualità della Salute è incre-mentata dall’unione di collezioni di dati e risultati;

• processi amministrativi e finanziari: libero e semplice acces-so alle informazioni utilizzate per le prestazioni finanziarie ed amministrative;

• autogestione del paziente: il paziente è libero di valutare le opzioni di trattamento anche in rapporto ai costi;

• educazione: sviluppo di protocolli e linee guida; • regolazione: si può valutare un sistema di pagamento;• ricerca: le informazioni diventano basilari per condurre tenta-

tivi clinici;• salute pubblica e sicurezza nazionale: la formulazione di sta-

tistiche per valutare la salute pubblica ed i rischi come il bio-terrorismo;

• supporto politico: la collezione di dati ed immagini aiuta a tracciare la politica sanitaria [SNOMED International, 2005].

4.2.5.2 I punti critici di SNOMED CTNonostante gli innumerevoli benefici apportati dall’utilizzo di SNOMED CT questo non è largamente utilizzato tra i sistemi me-dici informatizzati, come invece si potrebbe supporre. La licenza

per l’utilizzo di SNOMED CT è molto costosa sia rispetto alle tasse annuali sia per il processo di negoziazione dei termini. Quindi se SNOMED CT non diventerà un sistema internazionale cioè senon verrà acquistato da organizzazioni governative e internazionali, fal-lirà la sua missione.

Nella Tabella 4.13 sono elencate le maggiori debolezze di SNO-MED CT con relative conseguenze e possibili soluzioni [Walker, 2004].

Debolezza Conseguenza SoluzionepossibileProprietàascopodilucrodiprivati.

sfiduciadelleforzecommercialicheinfluenzanoilfairplay.

contrattoemezzodisicurezzaade-guatamentecostruiti.

Architetturanonfami-gliare.

Bisognodiridisegnarealcunisoftwareclinici.

Sviluppoditrainingperimparareadoperarecolsistema.

Dimensioneecomples-sità.

AlcunisistemipossonoavereproblemiasupportareSNOMEDCT.

Sipossonosvilupparesottodominipiùpiccolieadeguatiagliusispecifici.

Alcuniconcettisonoinde-sideratidaimedici.

Difficoltànell’analisi,nellaselezioneenellaletturarapidadeidati.

Creareunagerarchianavigazionalesempliceesoggettaafiltri.Utilizzaresoftwarechescelgonounapartico-laregerarchiainaccordoaltipodiparticolaclient,provideroorganismomedico.

Gerarchiaconmolterela-zionia“figlio”.

Sicreanoproblemiconquestege-rarchieancheselogichedurantelericercheopiùesteseopiùstrette.Loscambiotrapreepostcoordinaticon-cettisonodifficiliselerelazionisonopocointuitive.

Rimodellamentodeiconcetti.Peresempioinveceche“painofankle”comefigliodi“pain”metterecomedi-scendentidi“pain”:“ache”,“sharp”.

Definirerelazionichespessononsonointuitiveechenonsempredefini-sconounivocamenteunconcetto.

Lalocazionedeiconcettiattraversolelororelazionidiventadifficoltosaselequestesonoincompleteodincon-sistenti.

Rivederelerelazioniericostruirlesecondolenuoveesigenze.

Altolivellodipre-coordi-namento

Incrementodelladimensione,com-plessità,mantenimentoecostidelsistema.

Ridurrenasconderealcunipre-coordi-namenti.Costruirestrumentiingradodiagevolareloscambiotrapreepost-coordinaticoncetti.Incoraggiareilpost-coordinamento.

Costi Icostisonofondamentaliperladiffu-sionedelprodotto.

Lelicenzenazionalidevonoesserenegoziabili.

Tabella 4.13Elenco delle debolezze del sistema, delle conseguenze e delle soluzioni possibili

4.3 Health Level 7 (HL7)

4.3.1 Introduzione

L’iniziativa di standardizzazione denominata Health Level 7 (HL7) riguarda solo la forma secondo la quale sono allestite le comunica-zioni di messaggi scambiati in ambiente sanitario tra differenti siste-mi di calcolatori. Il significato, che rimane il contenuto concettuale del messaggio, è quindi di completa pertinenza dell’autore, che lo formula indipendentemente da HL7, vuoi in linguaggio naturale, vuoi seguendo altre iniziative di standardizzazione specificamente orientate ai contenuti, quali ad esempio SNOMED, UMLS, e così via. Altrettanto indipendenti da HL7 rimangono tutti gli aspetti di elaborazione e/o sistematizzazione del contenuto concettuale, quali ad esempio la sua strutturazione secondo qualche modello di basi di dati, il suo miglioramento con tecniche di filtraggio, la sua inter-rogazione con specifici linguaggi o con tecniche mirate come quelle dedicate al data mining. In sostanza HL7 ha lo scopo di normare tutti quegli aspetti che, quando non sono noti al destinatario del messaggio, pur riguardando la sola forma del messaggio medesimo, mettono generalmente il destinatario nell’impossibilità di intender-ne correttamente il significato.

Ricordare che mittente, destinatario e contenuto sono gli ele-menti necessariamente presenti in un qualunque messaggio, ci permette di esplicitare qualche utile riflessione che, se lasciata per implicita, rende meno facile apprezzare il valore di HL7. A tal pro-posito è naturale ricordare la lingua in cui il messaggio viene scritto; i differenti formati – ad esempio al variare del Paese, o in base al dif-ferente tipo di posta - che può assumere l’indirizzo sia del mittente che del destinatario del messaggio; l’applicativo software – ad esem-pio elaboratore (formattatore) di testi, foglio elettronico, e così via - usato nella costruzione del messaggio; le unità di misura adottate per esprimere i valori quantitativi delle grandezze che compaiono nel corpo del messaggio, eventualmente indicando anche le relative approssimazioni; l’ordine secondo il quale, nel corpo del messaggio, si susseguono le varie informazioni che lo costituiscono, come pure il modo in cui tali informazioni vengono separate tra loro.

È ben vero che gli aspetti qui sopra richiamati riguardano qua-lunque messaggio di comunicazione fra calcolatori. Essi quindi non sono specifici dei messaggi di tipo clinico e sanitario. Nondimeno è proprio in un ambito di dominio, quindi limitato, come appunto è quello clinico e sanitario, che l’opera di standardizzazione di aspetti del genere può diventare sostenibile e generare, entro tempi ragio-

nevolmente brevi, risultati già applicabili nella pratica ospedaliera, così come appunto accade per HL7.

HL7 tipicamente si dedica ai sistemi informativi sanitari che viaggiano sulla retistica ospedaliera di connessione tra i vari padi-glioni, tra i servizi, tra l’ambulatorio e la degenza, tra le sale operato-rie e così via. HL7 riguarda le comunicazioni tra queste realtà nelle quali è usuale che i dati dei pazienti vengano generati direttamente dalla strumentazione biomedica che, essendo molto differenziata da reparto a reparto nei suoi scopi, origina da costruttori che tra loro sono così tanto diversificati da non metterli nella condizione di avvertire nessuna seria spinta all’adozione di standard di comu-nicazione, tanto meno a far si che questi, una volta adottati formal-mente, possono essere implementati in modo tale che siano ben funzionanti tra loro. Invece tale spinta rimane per intero sulla spalle del responsabile del sistema informativo dell’ospedale, che tutti quei dati – generati da strumentazione biomedica pur tanto variegata – deve ricondurre al loro contenitore naturale: la cartella clinica del paziente. In questo ambiente non è ammissibile che vi siano errori, meno che mai quando dovessero rivelarsi dovuti a errori di comu-nicazione tra strumenti. Infatti la corrente cultura tecnologica, pur non affermando che sia banale eliminare errori di tal genere, giusta-mente ritiene che essi possano essere comunque del tutto eliminati. Di conseguenza è nato HL7.

È utile che la descrizione di HL7 venga incardinata su qualcuno dei suoi tanti documenti ufficiali, scelto assegnando valore alla sua chiarezza didattica e al fatto che sia un documento recente. Purtrop-po succede che la versione più recente di HL7, la 3.0, è ancora priva di una letteratura tecnica illustrativa adatta a chi ad HL7 si avvicina per la prima volta. Succede invece che per una versione precedente di HL7, la 2.3.1, materiale di questo genere esista, anche come frut-to del lungo lavoro accumulato negli anni scorsi. Va ricordato che le prime iniziative HL7 risalgono ad una ventina di anni or sono. Quindi questo capitolo prosegue dapprima illustrando il documen-to, [HL7 Communication Standard, 1999] e successivamente ri-chiamandone i passi più innovativi.

4.3.2 La versione 2.3.1 di HL7

Soffermiamoci sulla pagina identificata con “page 1-1” [HL7 Com-munication Standard, 1999]. Le informazioni riguardanti la versio-ne dello standard, lo stato della versione e la data di rilascio sono presenti nella nota a piè di pagina.

“Versione 2.3.1...”Il numero di versione è indicato da tre stati. Lo sforzo di costruzione di HL7 ha alle spalle una quindicina d’anni di crescita.

“HL7 Standard” Tutte le volte in cui si usa la parola “standard” è d’obbligo ritenere che ci siano degli enti che possano costruirli. Stante un individuato bisogno e un certo consenso di rispondervi, uno “standard” deve es-sere scritto dai tecnici, con attenzione al mercato, ma anche avendo individuato specifici beneficiari. La bozza di standard viene quindi sottoposta ad una procedura di approvazione appropriata alla si-tuazione. In sostanza c’è da ricordare che, quando si usa la parola “standard”, si implica la presenza di una organizzazione solitamente ben strutturata, importante, molto seria, frequentemente di livello sopranazionale, e spesso complessa, sia dal punto di vista tecnico, che da quello rivolto a tener conto del mercato. Vale a dire che, pur ricordando quanto rilevanti siano per il mercato alcuni standard proprietari – quello di Windows può essere un rilevante esempio di know-how aziendale divenuto standard di fatto – uno standard pubblico deve anche non costituire turbativa del mercato, come in-vece avverrebbe se creasse privilegi per qualche azienda.

“HL7 Standard for electronic data exchange in all healthcare environments...”

Nell’introduzione di questo capitolo abbiamo parlato di “comuni-cazioni”. Qui si dice: “electronic data exchange”, ed in particolare: “This document contains the specifications for Version 2.3.1. of the Health Level Seven (HL7) Standards for electronic data exchange in all health care environments, with special emphasisi on impatient acute care facilities (i.e., hospitals). It summarizes the work of a committee of healthcare providers (i.e., users), vendors and con-sultants established in March 1987 on the occasion of a confer-ence hosted by Dr. Sam Schultz at the Hospital of the University of Pennsylvania. Its participants, who represents users as well as ven-dors, share a common goal of simplifying the implementation of interfaces between computer applications from different, and often competing, vendors. This committee, which subsequently became known as the HL7 Working Group, endeavors to standardize the format and protocol for the exchange of certain key sets of data among healthcare computer application system. Meetings are held approximately every four months in scattered locations through-out the United States. HL7 sanctioned national groups also exist in many other countries outside of the United States including Austra-

lia, Germany, Japan, the Netherlands, New Zealand and Canada” [HL7 Communication Standard, 1999].

Si punta quindi l’indice sul fatto che devono esserci dati digitali da scambiare. Ne deriva, ad esempio, l’esclusione della usuale co-municazione originata da una conversazione vocale al telefono, al-meno quando strettamente riferita al 7° livello del modello OSI, che attiene l’intesa dei due interlocutori umani sui contenuti di quanto vocalmente si raccontano. “Electronic data exchange” è un termine più specifico che non la generale comunicazione. La seconda parte della frase recita “in all healthcare environments”. Davvero tutti? Sarebbe un grande successo. Sarà proprio cosi? Certo che ce ne sa-rebbe bisogno. Abbiamo appena ricordato che uno standard è una cosa seria, e la frase afferma “in tutti gli ambienti sanitari”, “in all healthcare environments, with special emphasis on inpatient acute care facilities (i.e., hospitals)” cioè gli ospedali.

Focalizziamo: scambio di dati, in tutti gli ambienti sanitari. Quindi anche tra i medici di famiglia, però con particolare atten-zione alle situazioni in cui ci sono dei pazienti acuti.

Immaginiamo la comunicazione tra pronto soccorso e reparto, tra sala operatoria e laboratorio di analisi. Questi ambienti sono pesantemente strumentati. Si tratta di ambienti tecnologicamente complessi. Percepiamo nettamente di affacciarci al problema della “comunicazione fra macchine” (Vale a dire che è facile e naturale pensare alla presenza di un impianto di risonanza magnetica, un sistema di ecografia, altri servizi di protezione dati, etc.), ma ca-piamo ora che la situazione si presenta decisamente interessante e complessa.

“... simplifying the implementation of interfaces...” (alla fine della riga 5 di page 1-1). Ecco specificato lo scopo. Quindi: c’è un problema di comunicazio-ne tra macchine, che non sono in grado di parlarsi l’una con l’altra. Verrebbe voglia di dire che non ne hanno bisogno. Che bisogno c’è che un impianto di risonanza parli con un sistema ecografico? Ep-pure il bisogno c’è. Capita quando essi generano dati che riguarda-no un medesimo paziente. Entrambi, comunicando con il Sistema Informativo dell’ospedale, devono mantenere correttamente inte-stati e opportunamente indirizzati i dati della specifica metodica diagnostica che è propria di ciascuno di essi. Ci si affaccia realmente al rischio che il responsabile del Sistema Informativo ospedaliero debba passare la propria vita a costruire interfacce. Si capisce che, se c’è qualche ente, qualche gruppo, qualche iniziativa buona che lo aiuti a semplificare la costruzione di interfacce, sia giusto sostenere

e facilitare al massimo il successo di simili azioni, eventualmente anche fornendo loro la propria collaborazione.HL7 serve dunque per semplificare le interfacce tra strumenti nell’ambito della comunicazione. Ci sarà l’analizzatore di liquidi organici, ci sarà l’elettrocardiografo. Ogni strumento ha il proprio compito. È vero che non è verosimile che un analizzatore di provet-te scambi dati direttamente con l’elettrocardiografo. Tuttavia ci sarà un archivio centrale col quale scambiare dati digitali. Soffermiamoci sul modo in cui le provette inviano a questo serbatoio centrale i ri-sultati che riguardano lo specifico paziente. Saranno preceduti dalla sua identificazione. Lo stesso avverrà per il modo in cui l’elettro-cardiografo invia l’elettrocardiogramma del paziente, pure questo preceduto dalla identificazione del paziente medesimo. Queste due identificazioni, prima o poi, devono essere allineate l’una con l’altra. Non c’è alternativa. Altrimenti non c’è via di uscita. Altrimenti i dati del paziente rimangono un po’ di qua e un po’ di là, e il pazien-te assume tante identità quanti sono gli esami che può aver fatto nei vari reparti di una stessa struttura ospedaliera.

“semplificare la costruzione di interfacce tra applicazioni digitali costruite da aziende differenti o anche concorrenti”.

La situazione è difficile. È quella in cui i soggetti in gioco, le azien-de, in generale non hanno alcuna voglia di condividere la conoscen-za di quello che fanno, perché ne va del loro know-how aziendale.

“to standardize...” (qualche riga più sotto nel documento). Si tratta di standardizzare il formato (cioè cosa metto prima e cosa metto dopo) e il protocollo (di solito il protocollo coinvolge an-che un aspetto temporale: cosa mando via prima e cosa mando via dopo) per lo scambio di certi insiemi fondamentali di dati (“key sets of data”). Si usa il termine “among” e non “between”, cioè gli scam-bi tra sistemi non sono solo a due alla volta. In generale si tratta di sistemi che non obbligatoriamente sono costruiti per parlare l’uno con l’altro, una coppia alla volta. Tuttavia tutti devono parlare col sistema informativo. È incluso anche un concetto di comunicazio-ne “da uno a molti”, in cui c’è un solo trasmettitore e posso esserci più destinatari che ricevono lo stesso messaggio. È inclusa inoltre la necessità di comunicazione di messaggi tra differenti sistemi di calcolatori. Ad esempio: tra l’autoanalizzatore - nel quale viaggiano svariate centinaia di provette all’ora, e il cui scopo è di analizzare quanta luce viene fermata tra la sorgente di luce e la fotocellula – e il sistema informativo.

Riflettiamo su cosa sia un “messaggio”. Nel fare lezione il docente indirizza messaggi agli studenti che lo ascoltano. In tale azione esiste un livello di standardizzazione che è implicito, del quale non ci si accorge, ma che tuttavia è molto rilevante. Ad esempio: indipen-dentemente dalla difficoltà dei contenuti, come pure dalla chiarezza didattica del docente, è implicito che docente e studenti parlino la stessa lingua. Perchè HL7 nasce negli USA? Forse anche a causa del multilinguismo, tra lingua inglese e lingua spagnola, che è ampia-mente distribuito sul territorio, e che nella sanità – come anche in altri ambiti – non deve costituire limitazione al livello di intesa fra coloro che si stanno prendendo cura del paziente. Diviene così facile riconoscere l’esistenza di un problema di lingua, a accettare che essa venga specificata. Quando io ti mando un messaggio, se io mi aspet-to che tu lo capisca, devo comunicarti la lingua in cui te lo mando.

Un’altra necessità di specificazione riguarda il contesto. Se par-lo di papà in quella famiglia mi riferisco ad una persona diversa rispetto a quando parlo di papà in quell’altra famiglia. Se a fare questa lezione fosse qui una brava e nota star del cinema e vi parlasse di HL7, voi gli credereste? Benché manifestato in modo implicito, esiste un tipo di accreditamento del docente che, a garanzia del de-stinatario del messaggio, è sinteticamente e globalmente erogato dal contesto – nel nostro caso quello universitario – in cui il docente opera. Quindi, sintetizzando, si vuole che ci sia un mittente mani-festo: voglio sapere chi mi dice le cose. Quindi simmetricamente, se c’è un mittente, c’è pure un destinatario dichiarato: certe cose le dico per il collega medico, invece che per il bambino, invece che per l’assistente sociale, invece che per l’infermiera, invece che per tutti i medici di quel reparto, invece che per tutti i prescrittori di quel farmaco, invece che per un altro destinatario ancora.

In DOS c’era un solo stile di un carattere. Adesso, se mandi un messaggio, stante tutta l’abbondanza di caratteri che abbiamo a di-sposizione, se vuoi che alla fine il messaggio venga riprodotto con lo stesso stile di carattere, allora gli stili vanno comunicati accom-pagnati al messaggio stesso. Anche nel caso semplice di quando ci arriva un messaggio di posta elettronica qualunque, una certa varie-tà dello stile dei caratteri e il loro stesso colore sono spesso perso-nalizzati dal mittente. Un documento formale, quale ad esempio è un messaggio-referto, può essere scritto tenendo conto di grassetti, sottolineature, corsivi, tabelle. Chiamiamo tutto ciò con “stile di caratteri”, “formattazione di caratteri”.

Riflettiamo su qualche altro aspetto, sempre di contesto, ma più specifico. Ad esempio, capita di ricercare se un cognome sia citato nella bibliografia di articoli scientifici, ma capita anche di ricercare

se quello stesso cognome sia citato direttamente nel testo degli ar-ticoli scientifici. È evidente che le due ricerche soddisfano motiva-zioni che non vogliono essere confuse tra loro. L’esigenza che una ricerca venga mantenuta circoscritta ai singoli paragrafi di un testo è abbastanza frequente. Possiamo chiamarla ricerca nei paragrafi. Ad esempio il nome del notaio che autentica la firma del medico responsabile. Se invece lo stesso nome è messo in un altro paragrafo, proprio per questioni di contesto, significa cose diverse.

In conclusione: non si creda che, avendo circoscritto il tema alla “comunicazione di messaggi”, si stia parlando di cose banali e di ovvia soluzione. Se abbiamo l’ambizione di far comunicare tra loro delle macchine - invece che degli esseri umani, dotati di un buon bagaglio di conoscenze implicite che usiamo con naturalezza senza accorgercene – dobbiamo diventare molto più espliciti e pedanti del solito. Ad esempio, quando usiamo una stampante un po’ vecchia, non riusciamo a farle stampare certi tipi recenti di caratteri, perché non ne possiede le primitive. Riconosciamo che, quando sono due macchine che devono parlarsi tra loro, le complicazioni sono tante.

Possiamo davvero capire le motivazioni che hanno spinto questo “HL7 group” di utenti a cercare di mettersi d’accordo, nel rispetto delle leggi del mercato, - cioè nel rispetto del fatto che le macchine le costruiscono le varie aziende seguendo i criteri loro prioritari

Quindi il responsabile dei sistemi informativi andrà nella dire-zione realistica di aggiungere all’output di una delle macchine ciò che gli serve per svolgere correttamente il suo lavoro. Cercherà di andare nella direzione di prendere le cose così come sono già date dalle macchine, aggiungendo al flusso di dati proveniente da ogni macchina il risultato di una certa sua osservazione identificativa, che verrà usata quando sarà necessario visualizzare quel flusso.

Questo è il filo conduttore, lo spirito, lo scopo da intendere per capire la forza della utilità di HL7.

In fondo alla pagina 1-6 del documento, ci sono 7 righe che descrivono in che cosa consistono le regole di codifica di HL7 (pa-ragrafo 1.6.1). Idealmente sono 7 righe da imparare a memoria! In particolare: “Message formats prescribed in the HL7 encoding rules consist of data fields that are of variable length and separated by a field separator character. Rules describe how the various data types are encoded within a field and when an individual field may be repente. The data fields are combined into logical groupings called segments. Segments are separated by segments separator characters. Each segment begins with a three-character literal value that identi-fies it within a message. Segments may be defined as required or optional and may be permitted to repeat. Individual data fields are

found in the message by their position within their associated seg-ments.” [HL7 Communication Standard, 1999]

“Message format prescribed in the HL7 encoding rules consist of DATA FIELDS...”

Può esserci utile esprimere questa frase nella seguente forma sinte-guente forma sinte-tica:

Il formato HL7 =(def.) { data fields }

Cioè il messaggio HL7 consiste, per definizione, in un insieme di “data fields”. Questi sono campi di dati, di lunghezza variabile, ne-cessariamente separati da un carattere avente la funzione di “sepa-ratore di campi”. Se considero un file a pila (un file a pila è quello in ordine sparso) e arriva un dato, prima di immagazzinarlo si deve anteporre il significato del dato. Se arriva una data, che tipicamen-te è suddivisa nei tre usuali campi di giorno-mese-anno, prima di immagazzinarla ne separo i componenti dando a ciascun campo la propria etichetta. Se invece arriva una data e, sbagliando, la leggo come peso, allora il 23/11/2005 diventa 23.112.005, numero unico che esprime il peso in una certa assegnata unità di misura. In sostan-za c’è bisogno di un “dichiaratore del significato di dato”. Tornando a pag. 1-6 “Le regole descrivono il modo in cui vari tipi di dati sono codificati entro il campo” e descrivono anche quando un campo individuale può essere ripetuto.

Parlando del formato HL7 diciamo che è un aggregato di dati (Figura 4.24). Abbiamo campi di dati separati da opportuni caratte-ri. Ebbene: riflettiamo sul fatto che i dati escono dalle macchine così come le macchine li generano. Senza che ci sia bisogno di entrare

Figura 4.24Esempio di messaggio HL7 Adattato da [Hammond et al., 2001]

MSH |^~&\DHIS|OR|TMR|SICU|199212071425|password|ADT|16603529|P|2.1<cr>

EVN|A02|199212071425||<cr>

PID|||Z99999^5^M11||ROSSI^SALEMI^LIA|RILEY|19430704|F||C|RT. 1, BOX97^ZIRCONIA^NC^27401 |HEND|(704)983-1822||S|C||245-33-9999<cr>

PV1|1|I|N22^2204|||OR^03|0940^DOCTOR^HOSPITAL^A||| SUR|||||A3<cr>

OBR|7|||93000^EKG REPORT|R|199401111000|199401111330|||RMT||||1994011111330|?|P030||||||199401120930||||||88-126666|A111|VIRANYI^ANDREW<cr>

OBX|1|ST!93000.1^VENTRICULAR RATE (EKG)||91|/MIN|60-100<cr>

OBX|2|ST|93000.2^ATRIAL RATE(EKG)||150|/MIN|60-100<cr>

OBX|8|ST|93000&IMP^EKG DIAGNOSIS|1|^ATRIAL FIBRILATION<cr>

nel livello fisico, riconosco “che questo dato che ora esce dal canale seriale è la data e lo metto qui”; “il dato successivo che esce è il peso e lo metto lì”, “il dato ancora successivo è la concentrazione e – nel mio riordino – lo metto là”; l’altro dato ancora e così via. Non basta. Voglio dire: la concentrazione, come la esprimo? In volumi/litro invece che numero di molecole per decimetro cubo? Quindi: devo includere delle unità di misura.

“... e quando un campo individuale può essere ripetuto” È utile quando, ad esempio, ho tutti pesi corporei, espressi in chi-logrammi. Varrà la pena di comunicare in modo non ridondante. Ad esempio: i prossimi 10 numeri sono tutti di peso corporeo. Evi-teremo di mandare 10 coppie (valore-”peso”), risparmiando sulla lunghezza totale del messaggio.

“I campi dei dati sono combinati in gruppi logici chiamati SEGMENTI...”

Ciò richiede una certa generalizzazione della definizione sintetica data sopra. Infatti in HL7 ci sono sia strutture atomiche, sia alcuni loro aggregati logici ai quali do il nome di segmenti. Posso così avere il segmento “indirizzo del paziente”. Posso avere il segmento delle caratteristiche somatiche. E così via. Poi aggrego i segmenti e trovo il formato HL7.

Msg di HL7 =(def.) { segmento = { campi di dati } }

Se nel formato HL7 ho sia dati che segmenti, e ho dei separatori di dati, allora ho pure separatori di segmenti, con i quali indico dove termina un raggruppamento di dati. Quindi è vero che “I segmen-ti sono separati da caratteri separatori di segmenti”. In particolare “Ogni segmento inizia con un valore letterale di 3 caratteri che lo identifica all’interno del messaggio” (Figura 4.24).

“I segmenti possono essere definiti come necessari o come opzionali...”

Allora i segmenti hanno un nome, e i 3 caratteri mi servono per dire: questo è il segmento indirizzo, questo è il segmento malattia, questo è il segmento temperatura corporea.

“... e si può consentire loro che vengano ripetuti”

“Campi di dati individuali sono trovati nel messaggio per mezzo della loro posizione all’interno dei segmenti a loro associati”.

Conta molto la posizione di collocamento ordinato dei campi di dati.

Parlando di aggregati di dati, non sempre si mette il peso come primo, l’altezza come secondo e sempre la concentrazione di cole-sterolo come terzo. Può darsi che un campo non ci sia. Si potrebbe lasciare il campo vuoto inserendo comunque il nome del campo, e durante la lettura accorgersi che quel campo è vuoto, quel dato non c’è: o non è stato raccolto, oppure la situazione non si prestava a che io lo raccogliessi.

“All data is represented as displayable characters from a selected character set” (primarigapagina1-7).

È il riferimento esplicito allo stile di caratteri (“...from a selected character set”). Se ho contemplato quello stile di caratteri, allora posso accettarlo. Altrimenti dovrò farmi carico di gestire in proprio lo stile di caratteri ulteriore. Ci sarà una parte dello standard HL7 che da qualche parte conterrà la tabella dei caratteri ammessi. Lo standard specifica queste caratteristiche nella seguente forma: “All data is represented as displayable characters form a selected charac-ter set. The ASCII displayable character set (hexadecimal values be-tween 20 and 7E, inclusive) is the default character set unless modi-fied in the MSH header segment. The field separator is required to be chosen form the ASCII displayable character set. All the other special separators and other special characters are also displayable characters, except that the segment separator is the ASCII Carriage Return character.• There is nothing intrinsic to HL7 Version 2.3.1.or ASTM

1238 that restricts the legal data set to the printable ASCII characters. The former restrinction was imposed to accommo-date the limitations of many existing communication system. Some existing system would misinterpret some eight-bit cha-racters as flow control characters instead of data. Other would strip off the eighth bit.

• The European Community (EC) has a nedd for printable cha-racters (for example, the German oe, the French accent grave) that are not within the above-defined restricted data set. The personal computer market accommodates these alphabetic characters by assigning them to codes between 128 and 256, but it does this in many different ways. ISO 8859 is a 256-cha-racter set that does include all of the needed European letters and is a candidate for the European standards group. Where the Europeans define an eight-bit character set specification, HL7 will accept this data set in environments that require it, and can use it without complications.” [HL7 Communication Standard, 1999].

“Non c’è niente di intrinseco in HL7 (qui ci riferiamo alla versione 2.3.1) che restringa l’insieme dei dati ammessi ai caratteri ASCII stampabili”.

Questa frase sostiene che HL7 non vieta la gestione di immagini, ma nemmeno offre strumenti predisposti a facilitarla.

“La storia degli accenti” (Paragrafo 2)È l’arruolamento a livello HL7 di ciò che succede con tastiera italia-na, tastiera francese, tastiera tedesca.

“Codici multicarattere” (Paragrafo 3) (Figura 7)Le indicazioni sui Codici multi carattere [HL7 Communication Standard, 1999] presenti sono: • “a. UNICODE – When communicants use UNICODE all

characters are representes by the same number of bytes, all de-limiters will be single characters of the specified bytes lenght, and the Standard applies just a sit does for single-byte lenght, except that the length of the characters may be greater the none byte.

• b. JIS X 0202 – ISO 2022 provides an escape sequence for switching among different character sets and among single-byte character representation. Japan has adopted ISO 2022 and its escape sequences as JIS X 0202 in order to mix Kanji and ASCII characters in the same message. Both the single- and multiple-byte characters use only the low order 7 bits in JIS Kanji code with JIS X 0202 in order to ensure transpa-rency over all standards communication systems. When HL7 messages are sent as JIS X, 0202, all HL7 delimiters must be sent as single-byte ASCII characters, and the escape sequence from ASCII to Kanji and back again must occur within deli-miters. In most cases the use of Kanji will be restricted to text fields”.

Ad esempio la “oe” tedesca è da considerare costituita da 1 o 2 ca-ratteri? Se voglio svolgere bene in mio compito, allora il livello di dettaglio da considerare deve essere adeguato ed è quello descritto. Ho bisogno che il messaggio arrivi al destinatario in modo a lui comprensibile. Io ho dichiarato la lingua e la “oe” la scrivo nel modo in cui la si scrive in tedesco.

“For more information on fields and encoding rules, see Section 2.6 “Fields” and 2.10, “Message construction rules” ”.

Allora, se ci si deve mettere a fare i “ragionieri dei caratteri”, ecco la parte del documento con evidenziati i rimandi alle sezioni “Fields”,

“Message construction rules” [HL7 Communication Standard, 1999]: “The encoding rules distinguish between data fields that have the null value and those that are not present. The former are represented by two adjacent quotation marks, the latter by no data at all (i.e., two consecutive separator characters). The distinction be-tween null values and those that are not present is important when a record is being updated. In the former case the filed in the database should be set to null; in the latter it should retain its prior value. The encoding rules specify that if a receiving application cannot deal with a data field not being present, it should treat the data field as present but null. The encoding rules specify that a receiving application should ignore fields that are present in the message but were not expected rather than treat such a circumstance as an error. For more information on field and encoding rules, see Section 2.6, “Fields” and 2.10, “Message Construcion Rules”.

“L’ambito di HL7” Viene definito nella sezione 1-11nella seguente forma [HL7 Com-munication Standard, 1999]: “It is useful to under stand both what HL7 is and what is not. This chapter, up to this point, represents some effort to give the reader an overall understanding of HL7 by looking at purpose, history, and some of its overall features and architecture. It is also of value to understand the “edges” or limita-tion of HL7. While HL7 can, and routinely does, provide a considerable service in everyday use today, there are certainly many areas of healthcare system integration that HL7 does not address or addresses with what may prove to be an inadequate or incomplete solution. Many of these topic areas are being worked on today by HL7 and will, hopefully, appear in latter version of this balloted Standard. Some others of these topics may never be addresses by HL7 because they are being addressed by some other standards body. Still other areas may never be addresses by HL7 due to a lack of interest, or at least available energy by its members. In any case, it is certainly useful for the analyst to understand what these boundaries are and to then either choose to solve them in some other way or to merely ignore them if they are deemed not sufficiently important. The following features listed in this section may well be best served by the participating applications them-selves. However, it is possible to conceive of an architecture that expects these features to be present in the messaging standard itself. These potential deficiencies are included to give the reader a com-plete view.”

“È utile capire che cosa è HL7 è cosa HL7 non è” (prima riga del primo capoverso).

Segue una serie tutt’altro che breve di sottoparagrafi: da 1.7.1 a 1.7.23. Si tratta di 23 paragrafi! In 23 punti mi aspetto di capire cosa HL7 è, e cosa HL7 non è. Ebbene: l’unico di questi paragrafi informato a dichiarare “Cosa è HL7” è il paragrafo 1.7.22. Tutti gli altri dicono “Cosa NON è HL7”.

Nel dichiarare che non riescono a trattare molti aspetti i redattori dello standard scrivono esplicitamente che non ne trattano per evi-tare di far credere che questi aspetti siano da sottovalutare.

1.7.1Lo scopo complessivo è quello di “plug and play” come definito all’interno dello standard [HL7 Communication Standard, 1999]: “HL7 is not, in itself, a complete system integration solution. Th e is-The is-sue directly addressess the so-called goale for “plug-and-play”. There are several barriers in today’s healthcare delivery environment that make it difficult, it not impossible, for HL7 to create a complete “plug-and-play” solution. Two of these barriers include: a) the lack or process conformity within healthcare delivery environments and b) the resulting requirement for “negotiation” between users and vendors. There is little, if any, process conformity within healthcare delivery environments. As a consequence, healthcare information solutions vendors are required to create very flexible system with a very wide range of data and process flow options. HL7 attempts to address the superset of all known process (i.e., trigger) and data (i.e., segment and field) requirements. In doing this, it has attempted to be “all things to systems and users.”. In fact, there is no user nor any system that users would elect to use that would use all that HL7 at-tempts to offer. This “excess” of features typically requires some level of “negotiation” to take place between a user and his/her vendors to come up with the set of triggers and data items necessary to affect the solution for the users. In effect, this creates a unique use of the Standard and site. The current version of HL7 has no intrinsic way to tailor a pre-determinable view of the Standard for each possible use. Future versions of HL7 will likely address this shortcoming. A true integrated healthcare information system solution addresses an integrates database, or at least what appears to be a virtual inte-grated database. In fact, however, as a practical matter, information solutions still need to be installed and operated in environments where no other, or only a subset of other, system are available. In any case, all system today are designed and implemented to process using their own local copies of data. HL7, to this date, has not at-

tempted to prescribe the architecture, functionality, data elements or data organizations oh healthcare applications. Rather, HL7 has attempted to accommodate all application requirements that have been brought to its attention by volunteers willing and able to ad-dress them. Future version of HL7 may choose to alter HL7’s his-toric approach to these issues. Recent efforts by HL7 and other ANSI Standards Developers to produce Data Meta Models have created a framework that both standards and applications develop-ers can use as a common basis for defining and using both data and data organizations. Widespread acceptance of these concepts may allow HL7 and other Standards Groups to be more prescriptive in their approach with a smaller set oh choices that must be made when interfaces are implemented. For now, however, users should be aware that HL7 provides a common framework for implement-ing interfaces between disparate vendors. In all cases, if an existing application interface is not available, HL7 reduces (but does not eliminate) the time and cost required to implement an application interface between two or more healthcare informations systems. If a user chooses to implement a set of homogeneous solutions from a single vendor, HL7 is typically not necessary not even applicable.”

Questo scopo non viene raggiunto quando viene meno l’allinea-mento alla standardizzazione, che utilmente dovrebbe essere accom-pagnato da una prova di conformità. Ricordiamo che il momento della fornitura di apparecchi all’ospedale è anche il momento nel quale vengono definite le specifiche del software di interfacciamen-to. La definizione comporta una sorta di negoziato tra utenti e ven-ditori. Non è infrequente che, in questo negoziato, si vada alla ricer-ca della soluzione che vada bene per – purtroppo soltanto - quella volta in quella istituzione. In generale l’istituzione ha un parco di apparecchi e di applicativi costituito da alcuni nuovi e altri vecchi, assieme ad una certa quantità di collegamenti, alcuni dei quali verso l’esterno. Dal punto di vista clinico, l’istituzione avrà una sua vo-cazione: geriatrica, piuttosto che neonatale, o altro ancora. È quasi inevitabile che, per far costare poco il risultato di interfacciamento desiderato per il nuovo apparecchio in fornitura, il responsabile dei Sistemi Informativi dell’ospedale proceda ad un negoziato che ri-spetti solo le necessità contingenti. Se da dove siamo in Politecnico attraversiamo la strada ed entriamo all’Istituto Neurologico Besta, dove non c’è un reparto neonatale, non c’è una lunga degenza ge-riatrica, è fatale andare incontro, nell’occasione di una nuova for-nitura, ad un differente punto di mediazione della definizione delle prestazioni dell’interfaccia. Così argomentando abbiamo descritto

quella che è la mina principale che si oppone al conseguimento della portabilità “plug and play”.

“HL7 fino a questo momento non ha tentato di prescrivere delle architetture, funzionalità, organizzazioni di dati o di elementi di dati”.

Quindi da HL7 non aspettiamoci alcuna proposta architetturale della cartella clinica. Qui ho un aggregato di campi, poi ho un ag-gregato di segmenti, poi posso avere un aggregato di paragrafi, ma l’architettura della cartella clinica non viene interessata. Ricordiamo che i suoi paragrafi fondanti sono: 1 – identificazione; 2 – anamnesi patologica familiare; 3 - anamnesi patologica prossima; 4 - esame obiettivo; 5 - diario della degenza; 6 – scheda di dimissione. Ebbe-ne, nonostante la H di HL7 stia per “health”, HL7 non si fa carico di nessuna architettura interna di documenti clinico sanitari. Si li-mita ad aggiungerne una descrizione esterna.

Tuttavia le cose non stanno rigorosamente in questi termini. Si vuol dire che quando ampliamo la nostra letteratura di riferimento su HL7 e andiamo oltre quello che è un momento didattico iniziale, quale quello che caratterizza il presente capitolo, ci si accorge che l’architettura dei documenti è trattata. Si vedano a questo proposito i due articoli sul JAMIA dedicati alla Clinical Document Architecture (CDA) [Dolin et al, 2001; Dolin et al, 2006], ma anche [Muller et al, 2005; Ferranti et al, 2006].

Orbene, ciò non conduce alla cancellazione di quanto scritto fi-nora, perché siamo al livello di una proposta. In sostanza usiamo HL7, quindi si definiscono degli aggregati - come “Anamnesi”, - impiegando il linguaggio Unified Modelling Language (UML) per la modellazione. E si continua di questo passo. Di conseguenza, an-che a fronte di una analisi della recente letteratura scientifica sull’ar-gomento, viene confermata la frase: “non è scopo di HL7 entrare nel merito della struttura dei documenti”.

1.7.2Protezione delle informazioni sanitarie. In HL7, regole per la pro-In HL7, regole per la pro-tezione dei dati non sono indicate [HL7 Communication Standard, 1999]: “HL7 Version 2.3.1. is largely silent about the issues of pri-vacy authentication and confidentiality of data that pass through HL7 messages. HL7 makes no assumption about the ultimate use of data rather assumes that both source and destination applications provide for these requirements. In addition, HL7 does not, at this time, specifically specify what, if any, encryption method should be used when transporting HL7 –based messages between two or more

system. At this time, HL7 users should familiarize themselves with legal and professional requirements for these topics.”.

“HL7 is largely silent about...”.

Non vengono negate la necessità e la validità della protezione delle informazioni cliniche e sanitarie, ma le priorità considerate sono di tipo diverso, e non sono disponibili in HL7 regole per la protezione dei dati.

1.7.7 “Accountability, audit trials and assigned responsibility” È manifesta la disattenzione anche per la parte di audit di tipo am-ministrativo [HL7 Communication Standard, 1999]: “HL7 Ver-sion 2.3.1. does not attempt to define Typical transaction process-ing features such as audit trails. A feature such as an audit trail may well be needed to successfully implement both a robust and security auditable environment. This feature could also support verifying that a given action is performed by individuals who are also respon-sible. A user may decide that these features are necessary in their integrated environment.”

Quindi HL7 trascura non solo la riservatezza, ma anche aspetti che riguardano i costi dei cammini di diagnosi e cura.

1.7.22 “Infrastructure based applications”Torniamo alla questione dei sistemi che non si parlano. L’elettrocar-diografo non parla con l’autoanalizzatore. È appropriato che non si parlino direttamente. C’è bisogno di un’infrastruttura di allinea-mento di quei dati che, generati da essi, sono originati da uno stesso paziente. Infrastruttura che aggiunga un’organizzazione capace di rendere le due uscite dei dati, tutto sommato, coordinate l’una con l’altra. Le specifiche applicazioni che l’infrastruttura contempla in-cludono, (ma non sono limitate a):• scheduling: come fare una cosa dopo l’altra, cioè la program-

mazione dell’ordine delle singole operazioni;• sostegno ai punti di servizio;• promemoria e richiesta di maggior attenzione;• sorveglianza dei dati concorrenti. Salta fuori la metrica;• sostegno a decisioni concorrenti. Si rifletta sui termini:

• concomitante: riferito soltanto il tempo;• conflittuale: che va in rotta di collisione (indipendente dalla

velocità);• concorrente: potrebbe voler dire entrambe le cose con di-

versi livelli tra conflittuale e concomitante;

• tracking delle uscite: è un’operazione più ampia del solo mo-nitoraggio;

• tracking del grado di soddisfazione e delle aspettative dei pa-zienti;

• liste di problemi.Sono i temi dei messaggi presi in considerazione da HL7. Quando in altri capitoli si parlerà di Integrating the Healthcare Enterprise (IHE), si vedrà che IHE, tenta di assorbire da HL7 (per quello che qui è descritto) e da DICOM (per le immagini). IHE tenta dunque di fare la operazione di integrazione in grande: vale a dire che lo scopo non è limitato al fatto che il messaggio del mittente venga ben ricevuto dal destinatario, lo scopo è che il messaggio che spedisco al mio destinatario, venga da tale destinatario ben ricevuto non solo per la parte di messaggio, ma anche per la parte di immagini che gli mando. In sostanza confeziono qualcosa della cartella clinica, pur senza dominare per intero la struttura della cartella stessa.

Il capitolo 2 tratta la parte di “Control/Query” e, in particolare, nell’introduzione si definiscono [HL7 Communication Standard, 1999]: “the generic rules that apply to all messages. Subsequent sec-Subsequent sec-tions define functionally specific messages to be exchanged among certain applications. The specific aspects of message definition that are addressed herein are:• the form to be used in functional chapters for describing mes-

sages. This includes their purpose, their contents, and the in-terrelationships among them. This form is called an abstract message definition because it is purely a level 7 (application) definition.

• The HL7 encoding rules for converting an abstract message into a string of characters that comprises an actual message

• The programming procedures required to exchange messages using the HL7 specifications

• The anticipated relationship with lower level protocols• Certain message segments that are components of all messages• A single message, the acknowledgment message, that may be

used unchanged in multiple applications.”Vi si trovano i paragrafi 2.6 e 2.10, che sono costituiti da lunghe liste, che occupano le pagine 2-9, 2-10, 2-11, 2-12. Vi si trova il livello di specifica, molto dettagliata, del quale c’è bisogno nell’am-bito della realizzazione di interfacce. Per gli scopi didattici del pre-sente capitolo, costituiscono un elemento di dettaglio del quale è fondamentale conoscere l’esistenza. Esse di fatto sono un sintetico manuale operativo di riferimento, da conoscere quando si procede alla realizzazione di un’interfaccia.

4.3.3 La versione 3.0 di HL7

La figura 4.25 rappresenta la struttura di HL7 versione 3.0. In basso a destra c’è il messaggio (lo scopo). Al blocco “Messaggio” si arriva da due direzioni. Dalla direzione verticale arriva tutta una serie di indicazioni di confezionamento (dati, segmenti, supersegmenti, i 3 caratteri all’inizio di ogni segmento,...). RIM sta per Reference Information Model. L’altra freccia che entra nel blocco “Messaggio” proviene da una direzione che fino a questo momento non abbiamo preso in considerazione ed è invece una direzione importante. Nella prima riga c’è scritto “Trigger Event” [HL7 Communication Stan-dard, 1999]: “The Standard is written from the assumption that an event in the real world of healthcare creates the need for data to flow among systems. The real-world event is called the trigger event. For example, the trigger event a patient is admitted may cause the need for data about that patient to be sent to a number of other systems.” Riguarda le azioni che il ricevimento del messaggio deve innescare. Si vuole così esplicitare il fatto che l’aver ben confezionato il mes-saggio non garantisce che il suo ricevimento sia senza conseguenze, a tal punto da non dovervi fare mente locale. Ad esempio: è suonata la sveglia e devi prendere la pastiglia. Ci sono questi elementi di innesco che avvengono con un po’ di regole:

INTERACTION

STORYBOARD

MESSAGE

RIMTRIGGEREVENT

APPLICATIONROLE

example

references

sender

receiver

content

triggers

instantiate

restrict

Figura 4.25Il processo di sviluppo dei messaggi in HL7, versione 3.0. Adattato da [Hinchley, 2003]

• non prendo la pastiglia tutte le volte che suona la sveglia;• se la sveglia suona alle 9.00 del mattino prendo l’anti iperten-

sivo;• se la sveglia suona alle 15.00 prendo la pastiglia del digestivo;• se la sveglia suona alle 21.00 corrisponde alla pastiglia per dor-

mire.L’evento che innesca una reazione è sempre lo stesso: “il suono della sveglia”, ma il significato devi darglielo tu. È il contesto che assegna messaggi diversi allo stesso evento di innesco a seconda di come è stato confezionato. Per avere il messaggio deve essere scattato un elemento di determinazione all’inoltro.

“Storyboard” È una sorta di storia clinica [Hinchley, 2003]. Siamo di fronte ad un messaggio che è stato confezionato, che è stato spedito sulla base di una decisione con una soglia. Il messaggio può rimanere lo stesso, ma il contesto, il significato, la portata, il valore finale del messaggio, sono diversi. È diverso parlare di sottopeso per un neo-nato o per una persona adulta. Ad esempio: diminuzione del 10% del proprio peso; i 7 chili persi da un adulto possono essere meno importanti dei 7 etti persi dal neonato. “Storyboards” sono esempi di recupero della storia clinica di quel paziente che consente di con-testualizzare il messaggio, non soltanto nell’ambito del documento, ma nell’ambito del paziente al quale esso si riferisce.

4.4 DICOM

4.4.1 Introduzione

La possibilità di trattare i dati in formato digitale ne consente un migliore trattamento e una più efficiente gestione, sia dal punto di vista clinico-scientifico che da quello più meramente economico-gestionale (in termini di costi di esercizio). A differenza delle im-magini analogiche, che possono essere esaminate solo sul supporto e nel formato in cui vengono prodotte, le immagini digitali esisto-no in forma elettronica e pertanto possono essere visualizzate in qualunque formato e su qualunque tipo di supporto: monitor del computer, pellicola o carta.

Tali vantaggi hanno determinato negli ultimi anni lo sviluppo e la diffusione di Sistemi Elettronici di Archiviazione e Gestione delle Immagini Digitali (PACS) [Giovagnoni et al., 2002].

Il tipo di gestione e’ sicuramente più semplice, sicuro e meno co-stoso: un’ immagine digitale può essere inviata a distanza sia all’in-terno che all’esterno dell’ospedale, anche a più sanitari contempo-raneamente, senza essere spostata fisicamente dall’archivio elettro-nico, cioè dalla memoria principale del computer che la contiene.

Le immagini digitali possono essere archiviate insieme con i rela-tivi referti, oppure possono essere integrate all’interno di una cartel-la clinica elettronica, ed essere richiamate in qualunque momento unitamente con le altre informazioni cliniche. È possibile control-lare rigorosamente l’accesso ai dati memorizzati, limitandolo al solo personale sanitario direttamente coinvolto nell’attività diagnostico-terapeutica di un determinato paziente, e conoscendo esattamente il numero di volte e l’identità delle persone che hanno preso visione di quei dati [Huang, 2003].

Ma la caratteristica più importante delle immagini digitali è, sen-za dubbio, la possibilità di modificarne le caratteristiche a seconda delle necessità, per mezzo di algoritmi di elaborazione.

Tali algoritmi, costruiti per esaltare alcune componenti di un’im-magine, possono migliorare notevolmente le capacità di visualizza-zione dell’occhio umano e consentire l’identificazione di particolari che altrimenti potrebbero essere persi.

Il trattamento numerico delle immagini porta dunque con sè un potenziale d’uso vastissimo, ma al contempo pone gli utenti – nello specifico gli sviluppatori dei sistemi hardware e software che devono gestirle - di fronte ad una serie di problematiche che, per certi aspet-ti, sono significativamente diverse da quelle inerenti la gestione, il trattamento e l’utilizzo di pellicole radiografiche. Si pensi ad esem-

pio a tutte le problematiche inerenti la codifica dei livelli di grigio o degli spazi colore di ciascun pixel che compone un’immagine, ma anche a tutte le questioni inerenti la corretta e univoca visualizza-zione di questa indipendentemente da quale sia il supporto di cui ci si avvale (monitor radiologico ad alta risoluzione con scheda video dedicata oppure monitor LCD/CRT), o ancora a quali algoritmi di compressione devono essere applicati alle immagini affinché queste non saturino in breve tempo la memoria disponibile per la loro ar-chiviazione, oppure alla definizione e memorizzazione di tutti quei parametri necessari per il post-processing (si pensi ad esempio alla definizione dei reperi anatomici che consentono la co-registrazione e successiva fusione tra un’immagine PET ed una CT).

Per rispondere in modo concreto a queste esigenze e per far fronte ai notevoli sviluppi che il mondo della diagnostica per immagini sta avendo, da diversi anni ormai la comunità clinica ha espresso for-temente l’esigenza di adottare uno standard che potesse rispondere concretamente alla necessità di gestire e supportare la produzione di bioimmagini, i dati a queste correlati, nonché il loro trasferimen-to sulla rete ospedaliera (interna ed esterna) [Huang, 2002]: nasce così DICOM, acronimo di Digital Imaging and Communication in Medicine.

Nel 1983 ACR (American College of Radiology) e NEMA (Na-tional Electrical Manifactures Association) iniziarono a collaborare per creare una standardizzazione che potesse superare le diversità tra i vari costruttori.

Dopo due anni fu presentato alla RSNA (Radiological Society of North America) la prima versione dello standard ACR-NEMA 300-1985 1.0, che nel 1988 venne aggiornato alla nuova versio-ne 2.0 (ACR-NEMA 300-1988). Lo standard non era esente da problemi: infatti non prevedeva specifiche sulla connessione in rete delle macchine, limite estremamente significativo per la possibilità di invio dei risultati di uno studio di imaging a una apparecchiatura diversa da quella che lo ha effettuato.

L’evoluzione di questo standard è il DICOM, che supera le diffi-coltà di interconnessione in rete, offrendo la possibilità di verificare se due apparecchi - dichiarati conformi - sono in grado di scambia-re informazioni. Il completamento delle specifiche è avvenuto nel settembre 1993 e lo standard è stato presentato ufficialmente alla RSNA nello stesso anno [RSNA, 2008].

DICOM versione 3.0 rappresenta lo standard di fatto approvato dall’ISO che consente ai vari dispositivi medici (TAC, risonanza magnetica, ecc.) l’archiviazione e lo scambio (anche tra apparec-chiature di diversi produttori) delle immagini e delle informazio-

ni associate in formato digitale. Alla base dei protocolli definiti da DICOM esiste un modello funzionale del mondo reale, cioè un modello di come le diverse attività ospedaliere (in particolare quelle radiologiche) si svolgono nell’ambiente operativo.

Sotto il profilo tecnico, DICOM realizza un esplicito e detta-gliato modello di descrizione di una serie di ‘oggetti’ (paziente, im-magine, ecc.) che formano il dato radiologico, e di come essi sono tra loro collegati. DICOM è un oggetto ‘composito’, contiene cioè molte informazioni oltre ai pixel veri e propri: dati del paziente, dati dell’esame, dati dell’apparecchio usato e altri ancora. Nel messaggio scambiato in rete, inoltre, la parte informativa vera e propria (chia-mata data set) è preceduta da una parte di comandi (detta command set) che contiene istruzioni sulle operazioni da compiere sul data set. DICOM può essere considerato un elemento fondamentale dei sistemi RIS/PACS in quanto prevede l’interconnessione sia mecca-nica che elettrica delle apparecchiature con costi e difficoltà minori e una manutenzione semplificata.

4.4.2 DICOM e il paradigma object oriented

Abbiamo già definito DICOM come uno standard di comunicazio-ne di immagini biomediche, prevalentemente radiologiche, com-plete delle relative informazioni, ma DICOM è in realtà più di un insieme di norme fissate per stabilire uno scambio di informazioni; DICOM realizza un esplicito e dettagliato modello di descrizione di una serie di “oggetti” (paziente, immagine, ecc.) che formano il dato radiologico, e di come essi sono tra loro collegati (vedi rappre-sentazione E-R del modello, Figura 4.26).

Ad ogni oggetto DICOM deve essere associato uno Unique Iden-tifier (UID), codificato secondo regole ben precise: l’intento è quello di rendere tale identificativo possibilmente unico a livello mondiale.

L’adozione degli UID consente tra l’altro un migliore e più effi-ciente scambio dei dati sulla rete in quanto è possibile, ad esempio, richiamare un’immagine a partire dal suo UID, oppure confrontare due serie d’immagini semplicemente confrontando il proprio UID per stabilire se sono diverse o meno (questo ad esempio è ciò che vie-ne fatto automaticamente prima di svuotare la memoria temporanea delle macchine d’acquisizione o per sondare se effettivamente la copia di una serie prodotta risiede su una postazione remota del PACS, ov-vero se l’invio è avvenuto correttamente). È importante sottolineare in questa sede come gli UID esistono e sono definiti per pressoché tutti gli oggetti definiti nello standard, nello specifico oggetti infor-mativi e classi di servizi (ovvero non solamente per le immagini, le

serie e gli studi). Anche se è prassi comune associare DICOM alle immagini, è importante ribadire come, ad esempio, anche un lista di prenotazioni di un paziente o la coda di stampa associata ad una stampante di pellicole sono oggetti DICOM.

Lo struttura di un UID è basata sulla forma numerica dello stan-dard OSI Object Identification (ISO 8824); ogni UID si compone di due parti, una radice (riferita alla specifica organizzazione/azienda produttrice) e un suffisso:

UID = <radice><suffisso>Il meccanismo di assegnamento del codice radice è di tipo gerar-

study contentnotification

describes

includes

includes includes

0-n 0-n 0-n 0-n 0-n 0-n 0-n

raw datawaveformpresentationstateoverlaylookup

tableRadiotherapy

objectsRegistration

MR spectroscopy

SR document

imagecurvestoredprintfiducials

spatiallydefines

ammendmentreport

series

createsequipment

frame of reference

contains

results

see notecontains

modality performedprocedure steps

studycomponents

comprised of

hasmakes

patient

0-n 0-n 0-n 0-n 0-n 0-n

0-n 0-n

1-n1-n1-n

1-n1-n

spatiallydefines

Figura 4.26DICOM Imformation Model [The DICOM

standard. 2008]

chico e solitamente, ma non sempre, è previsto un costo di regi-strazione. Le regole con cui codificare il suffisso sono ad arbitrio della specifica organizzazione, la quale però si impegna a garantirne l’unicità al suo interno (comunque anche per il suffisso si adotta la notazione a punti e ogni gruppo di cifre ha un preciso significato). Nella Tabella 4.14 mostrato un esempio

<radice>=1.2.840.xxxxx <suffisso>=3.152.235.2.12.1876364731:ISO 3:tipodiapparecchiatura2:ANSI 152:numerodiseriedell’apparecchiatura840:codiceANSIpergliU.S.A. 235:studioxxxxx:codiceANSIfornitoall’organizzazione/azienda 2:serie

12:immagine187636473:codificaperdataeoradiacqui-sizione

Come già detto, alla base dei protocolli definiti da DICOM esi-ste un modello funzionale del mondo reale. L’approccio a sviluppare strutture di dati basate su modelli e analisi di versioni astratte di en-tità reali è la cosiddetta “struttura orientata ad oggetti” la quale offre il grande vantaggio di mostrare chiaramente, sia i dati richiesti in un determinato scenario modellato, sia le modalità di interazione e cor-relazione tra di essi. Un entità del mondo reale come un paziente, un ricovero o un immagine viene modellata come un oggetto; ogni oggetto ha in sé una serie di attributi, per esempio l’oggetto paziente conterrà gli attributi dati anagrafici, data di ricovero, ecc.Definiti gli oggetti di interesse e tutte le loro caratteristiche, DI-COM definisce quali operazioni possono essere eseguite e su quali oggetti. Tali operazioni sono chiamate DIMSE service (Dicom Mes-sage Service). A partire dai comandi DIMSE vengono definite le Classi di Servizi: la combinazione di una Classe di Servizio (con i suoi comandi DIMSE associati) e di un IOD (ovvero un oggetto) prende il nome di Service Object Pair (SOP): ad ogni SOP viene

command: operation (store, print...)

SOP instance

SOP class

image data

template:

object:(IOD)

Figura 4.27SOP Class e SOP Instance

Tabella 4.14Esempio di Unique Identifier

assegnato un UID (numero identificativo) chiamato SOP Instance UID, associato ad una SOP Class (Figura 4.27).La SOP Class, il cui UID viene scambiato tra i dispositivi nella fase di negoziazione della comunicazione, costituisce l’unità funzionale di DICOM 3.0. Per ogni classe di servizi vengono definiti gli attori coinvolti (ovvero quali dispositivi), nonché le rispettive funzioni che sono chiamati a svolgere. DICOM adotta il paradigma di comunicazione client-ser-ver, ma utilizza una propria specifica sintassi: in riferimento al ruolo di client, definisce il dispositivo che invoca un particolare servizio come Service Class User (SCU); in riferimento al ruolo di server, de-finisce il dispositivo che presta un particolare servizio come Service Class Provider (SCP). A seconda del contesto in cui ci si trova, un dispositivo può agire come SCU o come SCP oppure assumere en-trambi i ruoli. Naturalmente esistono dispositivi che posso afferire ad una sola tipologia delle due, come ad esempio una macchina di acquisizione d’immagini che si preoccupa solamente di spedire le immagini prodotte al sistema centrale di archiviazione del PACS (ovvero, nella terminologia informatica, in modalità push).

4.4.3 Struttura dello standard

Lo standard è organizzato in 18 parti secondo la struttura seguente (Fi-gura 4.28). La struttura modulare di DICOM ne consente una facile espansione, in risposta alle esigenze del mercato e all’evoluzione delle tecnologie. L’evoluzione dello standard viene garantita da una com-missione centrale e - nello specifico - dal lavoro congiunto di diversi

part 10file format

part 12physicalmedia

mediaTCP/IP

part 8networksupport

part 18WADD

part 15 security profiles part 14display

part 16codes

part 5 data structures

part 1appl. profiles

part 7messaging

part 6dictionary

part 3objects

part 4services

part 1 intro/overviewFigura 4.28

Struttura dello standard

Working Group ad ognuno dei quali è affidata una specifica tematica o campo d’applicazione; ogni modifica o aggiunta viene vagliata e - nel caso - approvata dal Base Standard Working Group (WG VI). La mag-gior parte dei Working Group assieme alla DICOM Standard Com-mitee – che si occupa di mansioni meramente amministrative - hanno un segretario e due presidenti, di cui uno rappresentante del mondo aziendale/produttivo e l’altro rappresentante del mondo clinico e degli utilizzatori [The DICOM Standard, 2008].

PARTE 1 – INTRODUCTION AND OVERVIEWLa prima parte contiene una panoramica dello standard stesso, con descrizione dei principi basilari e delle norme di riferimento.

PARTE 2 – CONFORMANCEOgni produttore e venditore di un dispositivo dichiarato compati-bile con DICOM 3.0 è tenuto a redigere e a rendere pubblicamente fruibile un documento di conformità allo standard. In esso sono contenute le necessarie informazioni per capire se effettivamente il dispositivo d’interesse è in grado di integrarsi con il parco macchine DICOM-compatibili già a disposizione. Non si specifica però una procedura di testing/validation per stimare la conformità di un’ap-plicazione allo Standard.

PARTE 3 – INFORMATION AND OBJECT DEFINITIONLa terza parte definisce e descrive gli Information Objects che of-frono una definizione astratta delle entità reali (paziente, studio, immagine), applicabile alla comunicazione di immagini mediche digitali ed alle informazioni relative (forme d’onda, report strut-turati, dose di radiazione, ecc.). Ogni “Information Object Class definition” (IODs) è costituita da una descrizione del suo scopo e dagli attributi che la definiscono. Ogni IOD è una classe, non è una istanza e non specifica i valori per i suoi attributi. Si parla di istanza quando ad un attributo si sostituisce un valore specifico: natural-mente i valori degli attributi possono cambiare nel tempo, anche in base alle operazioni che si effettuano sulle entità.

PARTE 4 – SERVICES CLASS SPECIFICATIONIl contenuto della quarta parte mostra le specifiche delle classi di servizi Service Object Pair (SOP Class) che sono basate su di una serie di operazioni primitive che operano su IOD.

Passiamo ora brevemente in rassegna le più importanti - nonché le più implementate - classi di servizi definite dentro DICOM:

• VerificationTale servizio consiste in un semplice ed utile test che consente ad un dispositivo DICOM di verificare lo stato di connessione (e di fun-zionamento) di un altro dispositivo connesso alla rete; sovente ci si riferisce a questa classe di servizio utilizzando il termine “DICOM-ping”. È di fatto indispensabile per la risoluzione dei comuni pro-blemi di connessione e comunicazione tra dispositivi; inoltre questi spesso invocano tale servizio prima di stabilire un’associazione ed iniziare lo scambio effettivo dei dati, con un meccanismo totalmen-te trasparente all’utente. In ogni caso, ad ogni dispositivo DICOM-compatibile è richiesto di supportare tale servizio come SCP; sem-pre più spesso però quelli di nuova generazione implementano e supportano entrambe le modalità (SCP+SCU).• Storage È di fatto il servizio DICOM più utilizzato; permette il trasferimen-to di immagini e di altri oggetti DICOM tra dispositivi. Prevede e definisce diverse ed innumerevoli Storage SOP Class e di queste ne vengono continuamente e periodicamente aggiunte di nuove. L’UID di una Storage SOP Class viene solitamente scambiato tra dispositivi in fase di negoziazione, sovente per verificare le effettive capacità dei dispositivi che intendono stabilire un’associazione; tali UID sono sempre elencati all’interno di ogni Conformance State-ment. Una vecchia Storage SOP Class è tipicamente deficitaria di qualche funzione e/o caratteristica e può quindi limitare le funzio-nalità del dispositivo che la implementa. Il dispositivo che invece implementa una Storage SOP Class più recente, sempre implementa anche quelle più vecchie (proprio per garantire la compatibilità con i dispositivi più datati).• Query/Retrieve (Q/R)Questo servizio consente ad un qualunque dispositivo che lo im-plementa come SCU di interrogare un archivio centrale o un altro dispositivo (che agisce da SCP) alla ricerca delle immagini ivi even-tualmente contenute; contestualmente consente di effettuare un re-cupero selettivo delle corrispondenze trovate.• PrintLa standardizzazione del servizio di stampa e della configurazione delle stampanti ha consentito di superare tutte le limitazioni delle connessioni punto-a-punto, nonché di effettuare un set-up da po-stazioni remote dei parametri di configurazione delle stesse: questa classe di servizi rende pertanto le stampanti fruibili in un contesto di rete ed ogni dispositivo che implementi il servizio come SCU può dunque inviare i propri job di stampa ad una delle stampanti colle-gate (naturalmente ci si sta riferendo a stampanti dotate di scheda

di rete e che implementano il servizio come SCP). Vi sono diversi problemi per quanto riguarda la stampa su pellicola radiografica, tra cui quelli legati alla dimensione effettiva (reale) delle immagini, alla possibilità che queste vengano tagliate oppure ridimensionate, ma – soprattutto - alla loro consistenza nella visualizzazione rispetto alle versioni digitali disponibili sui monitor delle workstations (ovvero a come vengono codificati i livelli di grigio della pellicola a partire dai livelli di luminanza delle immagini digitali). • Modality Worklist (MWL)Questa classe di servizio ha una struttura in parte simile a quella della Query/Retrive; consente all’operatore del sistema di acquisi-zione di reperire dal RIS (Radiological Information System) la li-sta dei pazienti in attesa di effettuare un esame diagnostico (CT, PET, MRI, ecc.), nonché tutte le informazioni socio-demografiche a questi collegate. La Modality Worklist apporta sostanzialmente due grossi vantaggi: consente un grande risparmio di tempo (in quan-to all’operatore non vengono richieste ulteriori operazioni di data entry) e preserva l’integrità dei dati (che sono così consistenti con quelli disponibili nel repository centrale). Il dispositivo che agisce come SCU può adottare differenti schemi di richiesta (ad esempio, filtrando la lista in base all’orizzonte temporale d’interesse e/o al tipo di esame); in particolare le richieste al SCP possono avvenire in tempo reale ovvero a intervalli regolari.• Modality Performed Procedure Step (MPPS)Questa è la classe di servizio complementare alla precedente. Con-sente al sistema di acquisizione di comunicare la presa in consegna di un esame diagnostico per un paziente presente nella lista d’at-tesa, nonché lo stato attuale dell’esame (con il relativo numero di immagini prodotte e la loro locazione) ed, eventualmente, la sua conclusione. • Storage CommitmentQuesto servizio consente di garantire la corretta e persistente me-morizzazione delle immagini (e in generale di qualunque altro oggetto DICOM), a seguito del loro invio attraverso la rete, sul dispositivo ricevente. Più propriamente si può dire che consente al dispositivo SCU di riversare la responsabilità della corretta archi-viazione dei dati sul dispositivo SCP (tipicamente l’archivio cen-trale del PACS): in tal modo, ad esempio, è possibile e lecito per il sistema d’acquisizione, liberare la memoria occupata dagli oggetti per cui il servizio è andato a buon fine, avendo la certezza che i dati cancellati non vadano persi. Può accadere che il servizio di Storage venga più volte inoltrato da un dispositivo all’altro; tipicamente in-vece viene richiesto lo Storage Commitment una sola volta. Questo

servizio è dunque di fatto indispensabile, specie se si considerano le implicazioni medico-legali legate all’eventuale perdita di uno o più esami diagnostici.

PARTE 5 – DATA STRUCTURE AND ENCODINGAppena un’applicazione DICOM assembla un data set (una rac-colta d’informazioni costituite dagli Information Objects e dalle Service Classes DICOM), deve essere codificata cosicché può essere inserita in forma di messaggio per la comunicazione. La funzione principale di questo documento è la definizione del “linguaggio” che due apparecchiature useranno per “parlare” l’una con l’altra.

PARTE 6 – DATA DICTIONARYQuesta parte di DICOM include la lista completa di tutti i Data Elements insieme ai loro tag (o nomi numerici) ed al loro nome testuale, come questi sono rappresentati (testo, numero a virgola mobile, ecc.), se contengono uno o più percorsi e quali valori sono permessi.

Per ogni elemento, specifica: • I suoi unici tag, che sono costituiti da un gruppo ed un nume-

ro di elementi; • il suo nome; • la rappresentazione del suo valore (stringa di caratteri, interi, etc); • la sua moltitudine di valori (quanti valori per attributo); • se è stato ritirato.Per ogni articolo unicamente identificato, specifica: • il suo unico valore numerico con componenti multipli, sepa-

rato dai punti decimali e limitato a 64 caratteri; • il suo nome; • il suo tipo, entrambi le “Information Object Class”, definizio-

ni di codifiche per il trasferimento dei dati o certi Information Object conosciuti;

• le parti dello standard DICOM in cui esso è definito.

PARTE 7 – MESSAGE EXCHANGELa settima parte dello Standard DICOM specifica sia il servizio che il protocollo utilizzato per lo scambio d’immagini mediche da un’applicazione dedita allo scambio dei messaggi su supporti defi-niti nella Parte 8.

PARTE 8 – NETWORK COMMUNICATION SUPPORT FOR MESSAGE EXCHANGE

In ambiente DICOM il protocollo di comunicazione utilizzato è

il TCP/IP che rappresenta uno standard ormai molto diffuso che consente il trasferimento di immagini e dati a prescindere dal mezzo fisico di trasmissione, in modo efficiente e coordinato. Data l’esi-stenza di molte reti di comunicazione, realizzate secondo strategie differenti, la scelta di questo standard rappresenta una soluzione ideale al trasferimento delle immagini diagnostiche, sia a livello lo-cale, che su rete metropolitana (MAN) o geografica (WAN).

PARTE 9 – RETIREDNella nona parte sono raggruppate tutte le modalità relative ai vec-chi protocolli punto-punto ancora in uso presso vecchi sistemi.

PARTE 10 – MEDIA STORAGE AND FILE FORMAT FOR DATA INTERCHANGE

Specifica un modello generale per lo storage delle informazioni re-lative alle immagini medicali su supporti removibili. Lo scopo è fornire un framework che consenta l’interscambio di vari tipi di im-magini medicali e delle relative informazioni, su una vasta gamma di supporti fisici di memorizzazione.

PARTE 11 – MEDIA STORAGE APPLICATION PROFILESLa parte 11 dello standard specifica sottoinsiemi specifici di appli-cazioni dello standard DICOM ai quali un’implementazione può esigere la conformità. Questi sottoinsiemi specifici di applicazioni vengono raggruppati in Application Profiles.

PARTE 12 – STORAGE FUNCTIONS AND MEDIA FORMATS FOR DATA INTERCHANGE

Questa parte dello standard facilita l’interscambio di informazioni tra applicazioni in ambiente medico, specificando: • una struttura per descrivere la relazione tra il modello di me-

morizzazione e uno specifico supporto fisico e formato; • specifica le caratteristiche del supporto fisico ed i relativi for-

PARTE 13 – RETIRED (FORMERLY PRINT MANAGEMENT POINT-TO-POINT COMMUNICATION SUPPORT)

La parte 13 specificava i servizi ed i protocolli utilizzati per le co-municazioni punto-punto ed i servizi per la gestione delle stampe. È stato ritirato.

PARTE 14 – GRAYSCALE STANDARD DISPLAY FUNCTIONLa parte 14 specifica le funzioni standard per la visualizzazione di

immagini in scala di grigi. Questa funzione fornisce un metodo per calibrare un particolare sistema di visualizzazione al fine di presen-tare le immagini in modo consistente su differenti strumenti di vi-sualizzazione (e.g. monitor e stampanti).

PARTE 15 – SECURITY AND SYSTEM MANAGEMENT PROFILESLa parte 15 specifica i profili per la gestione della sicurezza del siste-ma ai quali l’implementazione dichiara di essere conforme. Questa parte non vuole indicare delle politiche di sicurezza ma vuole solo fornire dei meccanismi che possono essere utilizzati per implemen-tare le politiche di sicurezza nell’ottica dell’interscambio sicuro degli oggetti DICOM.

PARTE 16 – CONTENT MAPPING RESOURCELa parte 16 specifica: • template per strutturare i documenti come oggetti DICOM • insiemi di termini utilizzati negli oggetti DICOM • un lessico dei termini definiti e mantenuti da DICOM • specifiche traduzioni di termini del Paese specifico.

PARTE 17 – EXPLANATORY INFORMATIONLa parte 17 specifica le informative e le normative annesse che con-tengono informazioni esplicative.

PARTE 18 – WEB ACCESS TO DICOM PERSISTENT OBJECTS La parte 18 specifica come accedere agli oggetti persistenti DICOM attraverso richieste HTTP URL/URI che includono un puntatore ad uno specifico oggetto DICOM nella forma di una istanza UID.

4.4.4 Network

DICOM è in grado di gestire la comunicazione tra differenti dispo-sitivi connessi ad una rete sia locale sia geografica, nonché di sup-portare l’archiviazione dei dati su sistemi di storage off-line (come CD e DVD).

La Figura 4.29 mostra il DICOM Data and Communication Mo-del, il quale si compone di due parti: rispettivamente il network layers model (a sinistra) e il media storage interchange model (a destra). En-trambi i modelli condividono un upper-layer data structure model, che fa riferimento alle parti 3, 4, 5, 6 dello standard. La parte 7 è specifi-catamente dedicata ai processi di comunicazione propriamente detti, mentre la parte 10 è rivolta alle definizione del formato di file per lo scambio attraverso dispositivi di massa. Al di sotto degli upper layers i

due modelli sono completamente differenti [Huang, 2004].• Le applicazioni possono far riferimento ad uno dei seguenti:

l’Upper Layer Service, è indipendente dallo specifico canale di comunicazione e dal protocollo utilizzato, quale ad esempio il TCP/IP;

• il Basic DICOM File Service, fornisce l’accesso agli Storage Media, indipendentemente dallo specifico formato di memo-rizzazione e dalla struttura del file.

4.4.4.1 Modello ISO-OSI DICOM si appoggia ed utilizza lo standard di comunicazione ISO-OSI (ISO 7498). Il modello ISO/OSI definisce una pila (stack) di protocolli in 7 livelli (layer o strati). I livelli comunicano fisicamente tra di loro attraverso una interfaccia che consiste in una serie di operazioni che ogni livello offre al livello superiore. Il principale vantaggio del modello OSI è di fatto quello di svincolare le solu-

File FormatMessage Exchange

SecurityLayer

(Optional)

Media Storage InterchangeON-Line Communication

Network ExchangeON-Line Communication

Physical Mediaand Media

File Formats

TCP/IPTransport

SecurityLayer

(Optional)

DICOMUpperLayer

Dicom Basic File Service BoundaryDicom Upper Layer Service Boundary

Data Set Structure and Encoding - Data Dictionary

Information Objects Definitions

Service Class Specifications

Medical Information Application

Part11 & 12

Part 10Part

Part 3

Figura 4.29DICOM Data and Communication Model Adattato da [The DICOM standard, 2008]

zioni applicative a livello software da quelle hardware (dedicate al trasferimento fisico dei dati) [Garattini et al., 2004]. La Figura 4.30 illustra lo stack protocollare del modello.

Al livello di trasporto dello stack si situa il protocollo TCP/IP di-venuto punto di riferimento per le reti di tipo broadcast ed adottato anche dentro DICOM. All’interno dello standard non vi sono ri-ferimenti a quali connessioni fisiche adottare (ATM, T1, Megabit/Gigabit Ethernet, ISDN, etc), che sono di competenza dei livelli OSI più bassi; bensì vengono definiti e descritti solo gli ultimi livelli dello stack (ovvero quelli sopra il livello di trasporto) per i quali si specifica come utilizzare i servizi (archiviazione, reperimento, trasferimento, etc) in relazione agli oggetti di DICOM (immagine CT, MR, etc).

L’adozione del modello OSI rende quindi trasparente a DICOM la gestione del trasferimento fisico dei dati sulla rete: naturalmente affinché due dispositivi possano tra loro comunicare è necessario che entrambi supportino lo stesso protocollo fisico, ad esempio quello Ethernet. La mancanza di riferimenti ai mezzi fisici consente a DICOM di seguire in modo automatico eventuali sviluppi del-le tecnologie del settore (senza necessariamente aggiornare la do-cumentazione) e agli utilizzatori di implementare connessioni tra dispositivi DICOM adottando comuni componenti hardware, tipi-camente dal basso costo d’acquisto, anziché componenti specifica-tamente dedicati e progettati [The DICOM Standard, 2008].

4.4.5 Associazioni DICOM

Concludiamo questa breve trattazione dei servizi DICOM provan-do a illustrare meglio il meccanismo di negoziazione della comuni-cazione tra due dispositivi, cui si faceva cenno.

Quando due dispositivi tentano di scambiarsi delle informa-zioni, questi -secondo la terminologia DICOM - devono stabilire un’associazione. Un dispositivo DICOM-compatibile presenta un numero massimo di associazioni (solitamente più di una) che può

Physical Media

OSI End -System

Peer Protocol Layer

Application

Presentation

Session

Transport

Network

Data Link Physical

TCP/IP

Figura 4.30Modello ISO-OSI

gestire contemporaneamente: in questo modo è possibile garantire una comunicazione parallela verso due o più dispositivi (più pro-priamente, verso due o più Entità Applicative o processi). L ’asso-ciazione DICOM è di tipo state-less, ovvero non tiene traccia delle associazioni precedenti. Conseguentemente, il numero di associa-zioni che devono essere prima aperte e poi chiuse può impattare gravosamente sulle prestazioni della rete (si pensi al caso, anche se poco realistico, in cui si opti per spedire uno studio composto da centinaia di immagini CT stabilendo una nuova associazione per ogni singola immagine…).

L’associazione viene tipicamente richiesta dal SCU, il quale pre-para un cosiddetto Presentation Context, la cui struttura è presentata in Figura 4.31. All’interno dell’Abstract Syntax vengono specificate le SOP Class a cui si intende fare ricorso (ovvero si specifica quali in-formazioni si vuole scambiare): tale approccio consente di trasferire oggetti differenti all’interno di un’unica associazione (ad esempio, immagini CT miste ad immagini MRI).

Nel Transfer Syntax, per ogni SOP Class, risiedono informazio-ni legate alla codifica e rappresentazione dei dati: specificatamente compaiono i criteri con cui deve essere letto ed interpretato il flusso di dati in arrivo, nonché gli eventuali schemi di compressione uti-lizzati (TIFF, JPEG, JPEG2000, etc).

Il dispositivo SCP risponde al Presentation Context inviato dal SCU con la lista delle SOP Class richieste e supportate e con le re-lative Transfer Syntax: la fase successiva (quello di scambio effettivo dei messaggi) viene adattata in relazione alle corrispondenze trovate nella fase di negoziazione.

4.4.6 Esempi applicativi

4.4.6.1 Trasferimento di un’immagine CTUn’immagine CT viene trasferita dalla macchina di acquisizione alla workstation di visualizzazione. I passi che in sequenza vengono eseguiti sono (Figura 4.32):• la macchina di acquisizione codifica l’immagine CT all’inter-

no di un oggetto DICOM;

Figura 4.31Struttura di un Presentation Context

Presentation

Transfer SyntaxAbstract SyntaxPresentation context

• viene richiamato un set di comandi di primitiva di tipo DIM-SE (Dicom Message Service Element) a partire dai quali si costruiscono i messaggi DICOM;

• i messaggi vengono elaborati secondo il modello ISO-OSI, scendendo fino al livello fisico dello stack protocollare;

• il protocollo TCP/IP si preoccupa di garantire la comunicazio-ne e lo scambio dei pacchetti attraverso la rete (eventualmente rispedendo i pacchetti perduti);

• vengono ricevuti i pacchetti sulla workstation di visualizzazio-ne; si risale lo stack protocollare fino a ricomporre i messaggi DICOM;

• vengono decodificati e richiamati i comandi di primitiva di tipo DIMSE;

• viene ricomposto l’oggetto DICOM e si rende disponibile l’immagine CT alla visualizzazione. su monitor.

Diviene opportuno fare un’utile puntualizzazione. Si è soliti distin-guere tra i concetti di protocollo e di servizio: nello specifico, ci si riferisce ad un protocollo (di comunicazione) in riferimento al modo in cui i dati vengono trasferiti e codificati; diversamente un servizio è concettualmente più astratto e legato alle funzionalità che ci si aspetta di ottenere quando questo viene invocato (nel caso appena presentato il servizio consiste appunto nell’invio di un’immagine CT).

4.4.6.2 Utilizzo di un servizio: DICOM StorageViene di seguito presentato un esempio applicativo relativo alla clas-se di servizio di Storage: si consideri il caso in cui occorra inviare le diverse immagini che compongono uno studio CT dalla macchina di acquisizione all’archivio centrale del PACS. Sono di seguito pre-sentati gli step protocollari previsti in DICOM (si faccia riferimen-to allo schema di figura 4.33) [Huang, 2004]:• la macchina CT (SCU) richiede di stabilire e ottiene un’asso-

ciazione con il Server Controller del PACS (SCP);

Servizio DICOM

Oggetto DICOM

(immagine CT)

Comandi DIMSE

Connessione di rete

Comandi DIMSE

Protocollo TCP/IP

Acquisizione imm

agine CT

Visualizzazione imm

agine CT

Oggetto DICOM

(immagine CT)

Figura 4.32Un esempio di

trasferimento di un’immagine CT

• il SCU invia un comando DIMSE C_STORE al SCP per ri-chiedere il servizio di Storage;

• il SCP (PACS Controller) riceve il comando C_STORE e ri-sponde;

• la macchina CT invia il primo pacchetto del primo messaggio DICOM, relativo alla prima immagine dello studio CT;

• il PACS Controller esegue la richiesta di storage e memorizza i dati sui propri dispositivi di massa (dischi locali);

• al completamento dell’operazione viene inviato un messaggio di conferma al SCU;

• dopo aver ricevuto il messaggio di conferma, la macchina CT invia il successivo pacchetto;

• vengono ripetute le operazioni da (4) a (6) fino a che tutti i dati relativi alla prima immagine non vengono inviati;

• la macchina CT fa una seconda richiesta invocando nuova-mente il servizio di Storage per la trasmissione della seconda immagine dello studio. Vengono ripetuti i passi da (1) a (7) fino a che tutte le immagini non vengono trasmesse.

• la macchina CT fa una richiesta di chiusura dell’associazione: il PACS Controller risponde e l’associazione viene effettiva-mente chiusa.

C-STORE service grantedC-STORE response

C-STORE requestRequests forC-STORE service

Drops associationDropping association response

Dropping association requestRequests for

dropping association

Last data packet

Confirmation

First data packet

Receives image data

Sends image data

Association response

Association requestAssociation granted

Requests forestablishing association

SERVERPACS CONTROLLER

(C-STORE SCP)

CLIENTCT SCANNER

(C-STORE SCU)

(1)-(7)

(2)(2)

(3) (4)(5)(6)

(9)(9)

(0)(0)

Figura 4.33Esempio di servizio di Storage [Huang, 2004]

4.5 Integrating the Healthcare Enterprise (IHE)

4.5.1 Introduzione

4.5.1.1 MotivazioniLe tecnologie informatiche ormai da alcuni decenni supportano in maniera significativa l’ambito sanitario nella fornitura di servizi ri-volti alla cura del paziente ed agli aspetti amministrativo/contabili ad essi correlati. Originariamente molti di questi sistemi sono stati progettati come ambienti indipendenti, difficilmente interfacciabili con altre realtà e quindi non predisposti alla condivisione dei dati. In seguito, al fine di garantire una loro effettiva integrazione ed ot-timizzare i flussi delle attività, sono stati definiti dei protocolli, quali HL7 - Health Level 7 [HL7, 2004] e DICOM - Digital Imaging and Communication in Medicine [DICOM Standard, 2003], con lo scopo di poter trattare qualsiasi informazione riguardante il mon-do ospedaliero. La disponibilità di standard, però, è una condizione necessaria ma non sufficiente per integrare sistemi così differenti. L’adattabilità non è solo un fattore estremamente positivo, ma pre-senta anche degli aspetti di debolezza originati dalla residua – ma pur sempre rilevante – discrezionalità di implementazione, che rimane a disposizione dei vari produttori di sistemi che, di solito, ne fanno uso col fine ultimo di mantenere limitati i costi di produzione.

Il modello Integrating the Healthcare Enterprise (IHE) vuole proprio offrire una concezione globalmente funzionante dell’utiliz-zo e dell’implementazione degli standard nei vari mondi e dispo-sitivi per far sì che comunichino e siano in grado di trasferire in maniera efficace ed efficiente l’informazione. Se questo non accade, i processi coinvolti in ambito sanitario (ad esempio la richiesta del medico di una radiografia o la creazione e visualizzazione dei referti sulle immagini radiografiche) non sono automatizzabili e, malgra-do la presenza di sistemi informativi, il passaggio di documenti ed informazioni non segue sufficientemente precise regole procedurali. Ne consegue, purtroppo, una spinta a che i dati vengano trasferi-ti tra i sistemi coinvolti, magari ritornando al supporto cartaceo, richiedendo così l’introduzione delle stesse informazioni, nei vari ambienti, numerose volte, accrescendo di conseguenza il margine di errore sui dati stessi.

4.5.1.2 ScopoUn miglioramento quantitativo e qualitativo del servizio sanitario è direttamente legato all’evoluzione nella gestione dell’informazio-ne digitale sia all’interno che tra le istituzioni sanitarie. Al fine di

rispondere a questa esigenza nel 1997 la Radiological Society of North America (RSNA) [RSNA, 2006], la Healthcare Informa-tion and Management Systems Society (HIMSS) [HIMSS, 2007] ed alcune industrie del settore hanno promosso l’iniziativa Integra-ting the Healthcare Enterprise (IHE) [IHE, 2008] (Figura 4.34). Essa ha lo scopo di realizzare un consenso generale ed un’operati-vità condivisibile, atta a stabilire come gli standard esistenti (oggi DICOM, HL7), ma potenzialmente anche altri che siano adatti a specifici domini di applicazione, debbano essere adoperati in modo da risolvere gli aspetti comuni coinvolti nella comunicazione tra sistemi informativi in ambito radiologico. Il successo dell’iniziativa ha coinvolto negli anni successivi differenti domini clinici ed è stata accolta e promossa anche a livello nazionale e internazionale da altre associazioni in Europa e Giappone.

La proposta di IHE è rivolta a tutte le figure interessate e coinvol-te nell’integrazione di informazioni sanitarie quali le numerose as-sociazioni scientifiche riferite ai differenti settori clinici, che spesso di fatto rappresentano anche gli enti di ricovero e cura, i produttori di sistemi informativi e quelli di apparecchiature medicali, i medici ed i professionisti dell’Information Technology. IHE definisce una

Figura 4.34Il dominio di IHE in ambito radiologico.Adattato da [IHE, 2008]

IHE Workflow Events

Patientinformation

Registration

Examination orders

Ordersfilled

Break down the entered order into specific radiology procedure steps to be performed

Patient and procedure information retrieved by

the modality

Radiology report viewed by referring physician

Diagnostic image and demographic info stored for network access

Orders Placed

Acquisition completed

ProcedurescheduledPrefetch any relevant

prior studiesModality worklist

Modality

Images stored

Acquisition completed

Image manger and archive

images retrieved

Report

ReportReportrepository

Radiology report stored for network access

Position patient and acquire

imageprinted

filmfolder

filmlightbox

Diagnostic workstation

Initial capture of patient demographic information

Goal: accurate, complete report accessible whenever the referring physician desires

Referring physician orders the desidered radiology procedure

Diagnostic image and demographic info presented to radiologist

Figura 4.35L’Organizzazione

dell’iniziativa IHE [IHEa, 2008]

DevelopmentInternational, Domain Oriented

DeploymentRegional and National

Strategic Development Committee

Domain Committees/Domain Sponsors and Cooperating Orgs

National/Regional Deployment Initiatives/Sponsoring Organizations

Domain Sponsor

SponsorHMSS

SponsorACC

SponsorGMSIH, SFIL,

JASHIS

IHE/North America IHE/Asia Oceania IHE/Europe

Local/DomainReview

Committees

IHE-USA IHE-Can

IHE-J IHE-KR

IHE-UK

IHE-IT

IHE-CN?

Local/DomainCommittees

Local/DomainReview

Committees

RadiologyPalnning Cmte

InfrastructurePlanning Cmte

CardiologyPlan Cmte

LabPlan Cmte

RadiologyTechnical

InfrastructureTech Cmte

CardiologyTech Cmte

LabTech Cmte

Membership and staff of sponsoring organizationsCo-chairs of domain planning and technical committeesRepresentatives of national and regional IHE initiativesDomain experts and representatives of organizations in targeted expansion domains

struttura organizzativa (Figura 4.35) a supporto dell’iniziativa che non vuole essere coercitiva, ma flessibile per riflettere la sua natura cooperativa e volontaria e per incrementare la propria espansione ed innovazione. Le attività principali inquadrate in questa architettura organizzativa sono:• attività di Sviluppo atte a fornire documentazioni di riferimen-

to per chi vuole effettivamente adottare nei propri prodotti la proposta IHE, o desideri accertarsi che un sistema comprenda effettivamente le caratteristiche raccomandate da IHE. Queste attività e le organizzazioni che le supportano sono in generale specifiche per un dominio di applicazione e di interesse glo-bale;

• attività di Verifica e Promozione comprendenti: dimostrazioni pratiche e verifiche dei risultati raggiunti, iniziative promo-zionali ed educative. Queste attività e le organizzazioni che le supportano possono essere specifiche per un dominio di ap-plicazione o coinvolgere più domini ed identificano interessi nazionali e regionali.

4.5.2 Attività

4.5.2.1 SviluppoIHE definisce e documenta delle soluzioni basate sugli standard per risolvere specifiche necessità cliniche e di integrazione operativa. Queste soluzioni, individuate con il nome di “Integration Profiles” (IP), sono contenute in un manuale di riferimento intitolato “Tech-nical Framework” (TF), che aiuta l’implementazione degli standard disponibili in modo da raggiungere lo scopo desiderato: integrare e condividere dati medici per una cura ottimale del paziente. In ultima analisi il TF propone un modello informativo ed un vocabo-lario da adoperare nella comunicazione di informazioni sanitarie tra sistemi specializzati (ad esempio i gestori di immagini) e sistemi in-formativi e suggerisce come i vari standard debbano essere utilizzati per completare le transazioni ben definite, quelle prese in conside-razione, che coinvolgono aspetti della comunicazione. Gli elementi condivisibili (modello e vocabolario) sono la base di discussione su cui i medici ed i fornitori di sistemi possono confrontarsi per risol-vere aspetti analoghi di differenti domini sanitari.

IHE si propone inoltre di suggerire un preciso percorso di con-trollo del buon funzionamento operativo dell’integrazione, percor-so che risulta facilmente incorporabile nelle procedure di acquisto di sistemi.

Gli strumenti resi disponibili da IHE sono: • Integration Profiles per i produttori già citati• le Request for Proposal (RFP) per gli utenti. I contratti di acquisto dei prodotti identificano una visione unitaria, sia per l’acquirente che per il fornitore, sul concetto di interopera-bilità dei sistemi da comperare od espandere, rendendo le soluzioni proposte maggiormente accettabili e realizzabili.

Le commissioni “Domain Specific Planning Committee” e “Technical Committee”, composte dai rappresentanti degli enti i cui sistemi e programmi sono adoperati in un particolare ambito clinico, determinano con cadenza annuale la pubblicazione e la revisione dei “Technical Framework”. Esse sono sostenute da or-ganizzazioni di supporto (“Domain Specific Committee Sponsor”) negli specifici domini, che gestiscono gli aspetti logistici, economici (responsabilità di fondi, allocazione delle risorse), la schedulazione e preparazione degli incontri, il reclutamento ed il coordinamento dei partecipanti.

4.5.2.2 Verifica e PromozioneLa proposta IHE, per incoraggiare e promuovere l’implementazione

degli “Integration Profiles”, ha determinato un processo di verifica dell’interoperabilità tra sistemi e di istruzione e promozione del mo-dello suggerito. Queste attività (National Regional IHE Initiatives) sono promosse da iniziative nazionali e regionali (insiemi di nazioni) che devono coordinare la diffusione ed accettazione dei TF e degli IP e sostenere lo sviluppo di quelle parti che sono rilevanti per la riso-luzione delle problematiche a loro pertinenti. Anche in questo caso le associazioni professionistiche ed i produttori del settore sanitario forniscono gli specialisti per la supervisione e l’attuazione delle varie iniziative, individuando anche i fondi necessari alla loro realizzazione. Le iniziative regionali sono il contenitore delle iniziative nazionali e ne coordinano le specifiche attività. Tra queste abbiamo:• reclutare partecipanti, collaboratori e finanziatori per le inizia-

tive nazionali;• partecipare alle attività regionali, alla loro pianificazione ed al

coordinamento con le altre attività nazionali;• mantenere un continuo flusso di contatti ed informazioni con

gli altri componenti nazionali e regionali;• pianificare e sostenere il processo di verifica dell’interoperabi-

lità mediante eventi educativi, promozionali, dimostrativi o specifici incontri operativi nominati Connectathon;

• Individuare un direttore tecnico di progetto e/o un gruppo di specialisti a supporto di un coordinamento concreto delle attività;

• pubblicare e distribuire documentazione conforme alle linee guida delle iniziative regionali;

• sviluppare e proporre estensioni nazionali al TF per la risolu-zione di argomenti riferiti a politiche sanitarie locali.

4.5.2.3 Supervisione e programmazioneLa supervisione globale dell’iniziativa è demandata alla Commissio-ne Strategica per lo Sviluppo di IHE (Strategic Development Com-mittee), la quale ha la responsabilità:• di definire e pubblicizzare le mete di IHE e le linee guida delle

attività; • di supervisionare che i vari membri rispettino ed aderiscano

agli scopi ed alle indicazioni di IHE; • di favorire la comunicazione e fornire il coordinamento tra i

“domain committee” e le iniziative nazionali e regionali;• di definire ed attuare l’espansione dell’iniziativa verso nuovi

domini clinici, coinvolgendo persone, società ed organizzazio-ni in essi operanti.

La Commissione Strategica è composta da membri e gruppi di lavoro

provenienti dalle organizzazioni sostenitrici, dai professionisti che nel tempo hanno fatto parte dei “Domain Planning” e dei “Technical Committee”, dai rappresentanti invitati delle iniziative nazionali e regionali, e da esperti e rappresentanti di organizzazioni coinvolte in domini attualmente candidati ad adottare la proposta IHE.

4.5.3 Aree professionali interagenti

4.5.3.1 AreeConsideriamo l’impatto di IHE sul lavoro delle aree professionali coinvolte nelle problematiche descritte:• SanitàIl personale sanitario necessita di condividere completamente l’in-formazione distribuita in ambienti differenti per compiti e locazio-ne. I dati fondamentali dei pazienti devono essere accessibili senza limitazioni dovute all’incapacità di colloquiare tra sistemi e disposi-tivi, così da evitare anche la ridondanza e moltiplicazione delle stes-se informazioni e l’impossibilità di usufruire di un quadro definito dello stato del paziente. La struttura di IHE tende ad ottimizzare i processi clinici, riducendo gli errori possibili, migliorando l’effica-cia delle prestazioni, incrementando l’interazione tra dipartimenti e rafforzando la visione unitaria dell’organizzazione sanitaria.• Information Technology In una situazione eterogenea di sistemi, sia per ambienti che per modalità di interfacciamento, la struttura IT di un’organizzazione sanitaria è sottoposta ad un impegno continuo e gravoso per com-prendere le diverse implementazioni degli standard adottati e per tentare di accordarli tra loro. IHE definisce una modalità comune, flessibile e focalizzata nell’assicurare una soluzione delle tematiche relative all’integrazione, a cui possono riferirsi tutti gli attori coin-volti: produttori, centri IT, medici e consulenti. In particolare gli esperti dell’IT si possono dedicare a migliorare l’operatività dei si-stemi ed alla gestione dei processi di interesse e non principalmente ad elementi puramente tecnici.• AmministrazioneGli amministratori devono valutare aspetti economici, clinici e tec-nici relativi alla gestione del personale nel prendere decisioni che coinvolgono l’acquisto e l’esercizio dei prodotti disponibili sul mer-cato. Quando i sistemi non si integrano nella maniera corretta anche la qualità del servizio offerto non risulta elevato e l’organizzazione viene penalizzata da molti punti di vista che competono all’ammi-nistrazione: quello finanziario, quello dell’investimento tecnologico e quello dell’efficienza del personale.

4.5.3.2 InterazioniModalità principale di IHE è un confronto continuo, basato sulla collaborazione, la comunicazione e l’interazione delle figure fonda-mentali coinvolte nei processi operativi e gestionali delle organizza-zioni sanitarie. Oltre alle specifiche tecniche descritte nel Technical Framework, IHE fornisce una rappresentazione dettagliata dei passi da compiere e da verificare per incoraggiare un fattivo colloquio tra sistemi e stabilire il punto di incontro tra i loro distributori e gli utilizzatori, alla luce degli standard adottati.

Con scadenza annuale IHE promuove degli incontri internazio-nali di durata settimanale (Connectathon), dove sono eseguiti test definiti di interoperabilità, per verificare il lavoro di integrazione proposto dai partecipanti. Le industrie presenti all’evento, per di-mostrare la capacità di scambio dell’informazioni tra i loro sistemi ed altri di tipo complementare forniti da differenti distributori, uti-lizzano un ambiente costituito da applicazioni di test, basate sulla struttura proposta nel Technical Framework e specificatamente svi-luppate per il collaudo, raggruppate sotto il nome “Mesa test tools”.

In generale il processo di interazione e collaborazione può essere ricondotto alle quattro seguenti fasi distinte:• Identificazione del Problema: clinici ed esperti di IT rilevano

problemi di integrazione e condivisione dei dati che coinvol-gono l’accesso all’informazione, l’attività sanitaria, l’ammini-strazione ed i sistemi/dispositivi interessati.

• Specifica dei Profili di Integrazione: i responsabili coinvolti individuano gli standard più adatti a risolvere le esigenze di integrazione e si riferiscono per la loro implementazione alla documentazione relativa rilasciata nei profili di integrazione (integration profiles) descritti dal Technical Framework di IHE

Figura 4.36Il documento

Integration Statement di IHE

Adattato da [HIMSS/RSNA, 2003]

IHE Integration Statement Date 12 oct 2002Vendor Product Name VersionAny medical Systems Co IntegratedRATE V2.3This product implements all transactions required in the IHE Technical Framework to support the IHE Integration Profiles. Actors and Options listed below

Integration Profiles Implemented Actors Implemented Options implemented

Scheduled workflow

Image Manager/Image Archive NoneImage Display NoneImage Creator Performed Procedure StepOrder filler PPS Exception Management

Simpled Image and Numeric Report Report Creator NoneInternet address for vendor’s IHE information: www.anymedicalsystemsco.com/ihe

Links to standards Conformance Statements for the ImplementationHL7 www.anymedicalsystemsco.com/hl7DICOM www.anymedicalsystemsco.com/dicom/integrateRAD.pdf

Links to general information on IHEIn North america: www.ihe.net In Europe: www.the-europe.org In Japan: www.jira-net.or.jp/ihe-i

• Implementazione e Verifica: i produttori di sistemi verificano la bontà delle soluzioni delineate servendosi di strumenti softwa-re specifici e, in occasione degli incontri Connectathon, prova-no l’efficienza dei loro prodotti in termini di interoperabilità, interagendo con mondi di altri fornitori.

• Dichiarazioni di Integrazione e RFP: le industrie del settore pubblicano gli IHE Integration Statements (Figura 4.37) dove sono dichiarate le caratteristiche di integrazione supportate dai loro prodotti. Gli utilizzatori che desiderano comprare i sistemi così validati, possono farvi riferimento quando viene richiesta un’offerta economica alle dichiarazioni di integrazio-ne semplificando i vari aspetti dell’acquisto.

4.5.4 Lo scenario operativo

4.5.4.1 Attori e interazioni: il “Technical Framework” IHE non è un ente certificatore e la sua efficacia è molto più imme-diata e può essere molto maggiore di uno standard. IHE è il tenta-tivo di determinare modalità operative di riferimento per affrontare in maniera orientata alla rapida soluzione il problema dell’integra-zione tra prodotti, sistemi e modalità operative, partendo da una particolare prospettiva del mondo radiologico.

Questo punto di vista non è necessariamente l’unico od il miglio-re; ciò che più conta è che sia ampiamente accettato dai volontari partecipanti ad IHE stessa. Ad esempio, fornire un servizio di dia-gnosi per una prestazione radiologica implica l’esecuzione di molte procedure specifiche di conseguenza IHE ha definito univocamente un loro sottoinsieme appartenente alla famiglia dei processi fonda-mentali, senza per questo ritenere di aver compreso tutti i possibili e futuri flussi operativi che coinvolgono la radiologia ed altri ambiti sanitari.

Dato un ambiente sanitario distribuito, il Technical Framework di IHE [IHE, 2008b] (Figura 4.37) ne identifica le componenti funzionali, denominandole Attori (Actor) di IHE, dei quali con-sidera solamente le interazioni all’interno dell’azienda stessa. Nel TF sono descritte in maniera rigorosa, dettagliata ed esaustiva, le indicazioni proposte per realizzare le integrazioni desiderate tra i sistemi. Ciò viene ottenuto tramite la determinazione di una serie di interazioni fondamentali, o Transazioni (Transaction), da imple-mentare negli standard oggi più frequentemente considerati (HL7, DICOM, W3C), senza però precludere che ulteriori standard pos-sano essere aggiunti come unanimamente accettati.

In aggiunta, i distributori che hanno sviluppato i loro sistemi se-

condo le indicazioni del Technical Framework IHE, possono adope-rare il documento Integration Statement per dichiarare, sotto la loro completa responsabilità, le caratteristiche di integrazione supportate. Gli utilizzatori che conoscono i concetti proposti da IHE, a loro vol-ta, possono confrontare gli Integration Statement di diversi sistemi, per verificare se e fino a che punto la specifica implementazione sup-porta una non limitata comunicazione tra prodotti differenti.

A partire dal primo manuale redatto sulla base delle esigenze del settore radiologico, successive edizioni del Technical Framework sono state pubblicate nel corso degli anni, molte delle quali sono tra loro dipendenti e sono il frutto del lavoro di altri gruppi di la-voro, denominati comitati, patrocinati da IHE (IHE Committee). Ognuno di essi è focalizzato a risolvere le necessità di integrazione dei sistemi informativi in altri ambiti dell’organizzazione sanitaria, ugualmente coinvolti dalle problematiche che hanno originato l’ini-ziativa IHE.

Attualmente (al dicembre 2006) i manuali redatti dai vari comi-tati sono i seguenti:• IHE IT Infrastructure Technical Framework, per le esigenze

di integrazione dei dipartimenti di Information Technology dell’azienda sanitaria;

• IHE Radiology Technical Framework per la Radiologia;• IHE Cardiology Technical Framework per la Cardiologia;• IHE Eye Care Technical Framework per l’ Oculistica;• IHE Laboratory Technical Framework per i laboratori clinici;• IHE Patient Care Coordination (PCC) Technical Framework;

Figura 4.37Organizzazione

dell’informazione nel Technical Framework di

IHE [IHEb, 2008]

Integrationprofile

Integration profile

Actors

Actor Actor * * *

Transactions Tran

detailedmessaginginfo

referencedsrandards:DICOM & HL7

per coordinare lo scambio di informazioni mediche appropria-te tra differenti fornitori di servizi sanitari.

Il Technical Framework viene continuamente corretto, reso più comprensibile, aggiornato e curato mantenendo la compatibili-tà con le precedenti versioni dalla specifica Commissione Tecnica (IHE Technical Framework Committee) ad esso preposta. Il proces-so di revisione è annuale, sia per fornire una solida continuità alla sua struttura ed ai contenuti, sia per rimanere aderenti all’obbiettivo perseguito da IHE, che è quello di focalizzarsi sulle esigenze di inte-roperabilità dei sistemi in forza alle aziende sanitarie.

Il manuale TF può essere sottoposto a due tipi di modifiche, ca-ratterizzate da due differenti processi (Figura 4.38) da seguire:

1. Nuovi sviluppi. Hanno lo scopo di estenderne i contenuti, relativamente a nuo-vi Profili, Attori, Opzioni o flussi concettuali. Queste funzionali-tà sono pubblicate nella forma di Supplemento al Technical Fra-mework, sottoposto alla seguente successione di fasi:• Public Comment, indicato con la sigla (PC), per la raccolta

tramite servizio Web dei commenti alle proposte pubblicate;• Trial Implementation (TI) contenenti le variazioni apportate

al Supplemento considerando i commenti ed i suggerimenti raccolti nella fase precedente;

• Final Text (FT) al termine delle verifiche operative (ad esempio durante i Connectathon) sulla bontà delle soluzioni proposte.

Con la fine del ciclo annuale tutti i Final Text vengono raccolti ed inseriti nella versione di riferimento del Technical Framework.

Figura 4.38Il processo di aggiornamento/revisione/correzione annuale del Technical Framework Adattato da[IHE Technical Framework, Vol.I, 2007] pag. 13

New development

continue as required in the next

annual cycle

technical framework

(next version)

final text change

proposal

final text change

proposalchange proposal submitted &

accepted

change proposal submitted &

accepted

issues raised in previous version of

technical framework

publish comments considered & supplement

updated

existing technical

framework from previous annual

cyclefinal text

supplementsupplement

TIsupplement

PCPropose & draft new supplement

Publish for public comment

Publish for trial implementation

Publish as final text

Publish next version

2. Revisioni, aggiornamenti e modifiche dei contenuti già trattati. • Change Proposal - In certi casi, nonostante l’attento lavoro

della Commissione Tecnica, il manuale può contenere degli errori o dei passaggi non chiari e completi nel testo che devono essere sottoposti ad un processo di revisione;

• Correction – Sono elementi che provocano la non interopera-bilità tra sistemi, ma non richiedono di modificare la funzio-nalità dei Profili di Integrazione;

• Clarification – Sono parti del testo che invece non sono chiare e possono condurre ad un’errata interpretazione del contenuto;

• Procedure - Utenti, produttori o membri della Commissione stessa che richiedono la revisione evidenziano le inesattezze riscontrate e propongono anche una possibile soluzione. La richiesta a sua volta può essere accettata (Accepted) o rifiutata (Rejected); se approvata viene pubblicata nel documento de-nominato Final Text Change Proposal ed aggiunta al Techni-cal Framework, sempre con scadenza annuale.

4.5.4.2 L’Infrastruttura sanitaria Gli elementi trattati dal Technical Framework (attori e transazioni) sono una rappresentazione ideale della struttura informativa reale presente in ambito sanitario, che comprende i seguenti sistemi in-formativi principali:• HIS (Hospital Information System): gestisce le informazioni

comuni per tutte le attività dell’ospedale come accettazione/dimissione pazienti, gestione della cartella clinica, gestione della scheda di dimissione ospedaliera e gestione dei magaz-zini;

• CUP (Centro Unico di Prenotazione): è il sistema che si occu-pa della gestione delle prenotazioni delle prestazioni mediche;

• RIS (Radiology Information System): ha la funzione di prov-vedere alla raccolta, alla gestione, alla distribuzione delle infor-mazioni prodotte nel reparto di radiologia come prenotazione/accettazione/esecuzione esami, alla loro refertazione e archivia-zione.

• PACS (Picture Archiving and Communication Systems): è de-putato alla acquisizione, distribuzione, visualizzazione, archi-viazione, stampa e copiatura delle immagini digitali prodotte in radiologia.

• Sistemi per i Servizi di Patologia Clinica: in questa categoria rientrano i laboratori d’analisi di chimica clinica e di anatomia patologica

• Sistemi per la gestione dell’emergenza-urgenza: sono i sistemi sui quali si appoggia tipicamente il pronto soccorso o il Dipar-timento di Emergenza ed Accettazione (DEA).

Nonostante succeda che certe transazioni siano di fatto specifiche di alcuni dei sistemi citati, il Technical Framework evita intenzio-nalmente di riferire funzionalità o attori ai prodotti di questi am-bienti; anzi, nel manuale, ad ogni particolare attore sono associate solamente le funzionalità che influenzano l’integrazione dell’infor-mazione tra sistemi. Perciò, nella visione di IHE, un attore non identifica in maniera completa i prodotti che possono realizzarlo. Quindi, ancora una volta, il Technical Framework non si propo-ne di rappresentare esaustivamente tutto l’insieme dell’architettura informativa di un’organizzazione sanitaria. I due elementi (attori e transazioni) individuano solamente una piattaforma di riferimento per la descrizione dei tipi di interazione tra i componenti funzionali specifici dell’ambiente di applicazione. L’iniziativa di IHE non è interessata a giudicare se per ottenere le stesse finalità sia meglio un singolo sistema informativo o un sistema composto da molti componenti, ma sicuramente si propone di sostenere e dimostrare che l’adozione del suo manuale da parte delle società distributrici, consente di integrare e far cooperare i loro prodotti.

4.5.4.3 I Profili di IntegrazioneI Profili di Integrazione di IHE risolvono la necessità di conseguire un linguaggio comune tra i professionisti del settore sanitario ed i produttori di sistemi al fine di dialogare dei requisiti necessari all’in-tegrazione dei prodotti. Essi descrivono alcune delle caratteristiche dei sistemi integrati del mondo reale, sono applicabili a gruppi de-terminati di attori e, riguardo ad ognuno di quest’ultimi, indivi-duano le transazioni specifiche per realizzare a pieno le potenzialità dei sistemi stessi. Come accennato precedentemente, IHE ha pub-blicato numerosi Technical Framework per diversi settori e processi presenti nell’azienda sanitaria. In questo paragrafo, che vuole essere di primo avvicinamento a IHE, ci si limita al caso della Radiologia.

4.5.4.4 Le Classi dei Profili di Integrazione In generale i Profili di Integrazione di IHE sono riconducibili alle seguenti tre classi: • Content Profile per la gestione di un particolare tipo di ogget-

to contenente informazioni (content object). Essi descrivono la creazione, l’immagazzinamento, il trattamento, il recupero e l’utilizzo di un particolare “content object”, e tra gli altri com-prendono anche i seguenti profili: Consistent Presentation of

Images, Key Image Notes, NM Image, Evidence Documents, e Simple Image and Numeric Reports. I Content Profiles non sono coinvolti nella descrizione di alcun flusso di processo.

• Workflow Profile per il trattamento del flusso di attività (wor-kflow process) che ha come fine ultimo la produzione di un contenuto. Sono richieste di solito un elenco delle attività da svolgere (worklist) e delle fasi di controllo ed informazio-ne sullo stato di elaborazione e completamento dei vari punti (workitem). Questo profilo riporta e sovrintende all’evoluzio-ne e completamento delle attività necessarie alla creazione di uno o più content object secondo il content profile di rife-rimento. Tra i Workfl ow Profi le abbiamo: Scheduled Work-Tra i Workflow Profile abbiamo: Scheduled Work-flow (per l’acquisizione), Post-Processing Workflow e Re-porting Workflow. Il Presentation of Grouped Procedures è un’estensione dello Scheduled Workflow, mentre Charge Post-ing è un’estensione di tutti i Workflow Profiles.

• Infrastructure Profile rivolti a questioni di interesse dipartimen-tale come Basic Security and Access to Radiology Information.

A titolo di esempio la Figura 4.39 rappresenta l’insieme corrente dei Profili di Integrazione per la Radiologia organizzati secondo le tre classi citate. Normalmente i profili non sono indipendenti tra loro; può essere necessario implementarne più di uno per consegui-re le funzionalità di quello desiderato. Sempre dalla Figura 4.39 si può notare come il profilo Presentation of Grouped Procedures è

Scheduled WorkflowAdmit, order, schedule

Cross-Radiology Document Sharing for ImagingConsistent sharin of images and radiology reports across enterprise boundaries

Other Radiology Relevant Profiles:ITI ATNA - Radiology Audit Trail Option, ITI RID, ITI PIX

Portable Data for ImagingConsistent access to images and reports on CD Media

Access to Radiology InformationConsistent access to images and reports

Create, store,

manage, retrieve & use images

Manage worklists, track status, perform

& notify acquisition

related steps

Evidence Documents

Create, store, manage,

retrieve & use objects to

record study evidence

Consistent Presentation

of imagesCreate, store,

manage, retrieve & use

objects for hardcopy and

softcopy grayscale

presentation states

NM ImageCreate, store,

manage, retrieve & use NM image

objects

Mammo ImageCreate, store,

manage, retrieve & use Mammo image objects

Presentation of Grouped Procedures

Manage individual procedure image subsets from a

multi-procedure acquisition for

viewing & reporting

Import Reconciliation

WorkflowReconcile imported

data objects

Patient Information

ReconciliationReconcileworklists,

status and dataobjects for patients and demographics

changes

Post Processing Workflow

Manage worklists, track status,

perform & notify image processing

& CAD steps

Reporting Workflow

Manage worklists, track status,

perform & notify diagnostic

reporting steps

Charge PostingCollect and post timely billable

procedure details

Simple Image and Numeric

Reports Create, store,

manage, retrieve & use

simple diagnostic

reports with optional images

Key Image Notes

Create, store, manage,

retrieve & use objects to flag

significant images

Figura 4.39I profili di Integrazione

del Technical Framework di IHE per la Radiologia

Adattato da [IHE Technical Framework,

Vol.I, 2007] pag. 15

influenzato direttamente dalle caratteristiche dello Scheduled Wor-kflow e dal Consistent Presentation. In generale un profilo di tipo workflow non risulta essere di alcuna utilità se almeno uno, o più, dei profili legati ai contenuti non viene realizzato, consentendogli di maneggiare differenti tipo di input ed output durante la gestione delle attività. La Tabella 4.15 definisce le dipendenze esistenti tra i vari profili attualmente definiti. Le aziende produttrici di siste-mi informativi per il settore sanitario attestano l’aderenza dei loro prodotti ad un Profilo di Integrazione, realizzando tutte le relazioni attori-transazioni come richiesto dalle specifiche relative ai vari pro-fili; nello lo stesso prodotto inoltre possono essere presenti più attori e Profili di Integrazione. Ogni attore deve comprendere anche tutte le transazioni richieste nei profili considerati necessari (pre requisiti) a quello di interesse.

4.5.5 Il caso della Radiologia

4.5.5.1 I Profili di IntegrazioneDi seguito sono elencati i profili individuati da IHE per la risoluzio-ne delle necessità cliniche in ambito radiologico; abbiamo:• Scheduled Workflow (SWF) stabilisce la continuità e l’integrità

delle informazioni relative ad una prestazione radiologica per un determinato paziente con produzione di immagini, elencando i passi principali ed il flusso informativo necessari per la sua effet-tuazione: 1) registrazione, 2) disposizione, 3) pianificazione, 4) acquisizione, 5) distribuzione ed 6) archiviazione.

• Patient Information Reconciliation (PIR) consente di riferire in maniera efficiente immagini, diagnosi ed altri documenti pro-dotti durante il ricovero di pazienti non identificati o scambia-ti con altre persone, ad esempio come può avvenire nel caso di traumi sottoposti ad un pronto intervento.

• Consistent Presentation of Images (CIP) determina, attraverso una serie di transazioni, la consistenza della riproduzione dei toni della scala dei grigi delle immagini radiografiche su diffe-renti video e dispositivi sia per copie fisse, che volatili od en-trambi. Allega all’immagine anche ulteriori informazioni quali annotazioni del clinico, caratteristica dell’otturatore adopera-to, se l’immagine e ruotata o capovolta, i parametri di zoom.

• Presentation of Grouped Procedures (PGP) consente la gestione di quelle situazioni (linked studies problem) dove sono acqui-site in una sola volta immagini radiologiche (ad esempio la Tomografia Computerizzata del petto e dell’addome), spesso per fattori di efficienza nell’acquisizione o per diminuire i di-

sagi del paziente, atte a soddisfare differenti richieste di pre-stazione.

• Post-processing Workflow (PWF) estende le funzionalità del profilo SWF per gestire tutte le procedure legate a successive rielaborazioni e ricostruzioni delle immagini, tramite sistemi dedicati.

• Reporting Workflow (RWF) supporta la pianificazione, la distri-buzione e l’identificazione dello stato di attività informative fondamentali, come l’interpretazione dei dati, la loro trascri-zione e verifica.

• Evidence Documents (ED) definisce le modalità operative per il trattamento di informazioni non riferite ad immagini (osser-vazioni, misure, risultati prodotti da sistemi CAD) da parte di altri ambienti preposti all’ acquisizione, all’archiviazione e alla rappresentazione mediante terminale, od altri supporti, per produrre informative diagnostiche.

• Key Image Note (KIN) permette di aggiungere note testuali ed indicatori alle immagini relative, ad esempio, a consulti con altri dipartimenti o per appunti sulla qualità dell’immagine in esame.

• Simple Image and Numeric Reports (SINR) realizza una modali-tà standard per la creazione, l’utilizzo, la memorizzazione e la visualizzazione di documenti multimediali comprendenti im-magini, testi, valori numerici e registrazione di informazioni trasmesse mediante comandi vocali digitali.

• NM Image (NM) specifica come le immagini prodotte da di-spositivi PET/TAC, sia statiche che dinamiche, debbano es-sere memorizzate nelle stazioni di lavoro utilizzando oggetti sviluppati secondo lo standard DICOM, e come debbano es-sere visualizzate.

• Portable Data for Imaging (PDI) specifica le funzionalità neces-sarie alla distribuzione di informazioni riferite ad immagini radiologiche su media di trasporto. In questo modo viene rea-lizzato uno scambio affidabile di dati per successive visualizza-zione su video o su stampe.

• Charge Posting (CHG) determina in maniera precisa le infor-mazioni necessarie da inviare ai sistemi amministrativi di fat-turazione per consentire un costante e tempestivo addebito delle prestazioni tecniche e professionali, svolte dall’organiz-zazione sanitaria.

• Basic Security (SEC) stabilisce le misure di sicurezza fondamen-tali, all’interno dell’insieme di policy, e procedure da attivare in un’azienda sanitaria, per la protezione della confidenzialità

Tabella 4.15Dipendenze tra i Profili di Integrazione per il dominio di Radiologia Adattato da [IHE Technical Framework, Vol.I, 2007] pag. 16-17

IntegrationProfile Dependson DependencyType CommentsConsistentPresentationofImages

None None -

KeyImageNotes None None -

NMImage None None -

MammographyImage None None -

EvidenceDocuments None None -

SimpleImageandNumericReport

None None -

AccesstoRadiologyInforma-tion

Oneormoreof:{ScheduledWorkflow ConsistentPresentationofImages, EvidenceDocuments,KeyImageNotes,SimpleImageandNumericReports}

RequiredforContentoutput SupportingtheimagerelatedtransactionsofScheduledWorkflowcountsasaCon-tentprofile

PatientInformationRecon-ciliation

ConditionallyRequiredfortheMultiSourceoption

ScheduledWorkflow None None -

PresentationofGrouped Procedures

ScheduledWorkflow Requiredforworkflow -

ConsistentPresentationofImages

RequiredforContentoutput -

Post-ProcessingWorkflow ScheduledWorkflow Requiredforworkflowman-agement

Oneormoreof:{ScheduledWorkflow, EvidenceDocuments,NMImage}

RequiredforContentinput SupportingtheimagerelatedtransactionsofScheduledWorkflowcountsasaCon-tentprofile

Oneormoreof:{ScheduledWorkflow ConsistentPresentationofImages, EvidenceDocuments,KeyImageNotes}

Requiredifanyoutputisproduced

SupportingtheimagerelatedtransactionsofScheduledWorkflowcountsasaCon-tentprofile

ReportingWorkflow ScheduledWorkflow Requiredforworkflowman-agement

Oneormoreof: {ScheduledWorkflow, EvidenceDocuments,NMImage}

RequiredforContentinput SupportingtheimagerelatedtransactionsofScheduledWorkflowcountsasaCon-tentprofile.

SimpleImageandNumericReports

RequiredforContentinput/output

ChargePosting OneorMoreof: {ScheduledWorkflow,Post-ProcessingWorkflow,ReportingWorkflow,ImportReconciliationWorkflow}

Requiredforchargetriggerinput

PatientInformationRecon-ciliation

ScheduledWorkflow Requiredforworkflow/con-tenttomanage

PatientInformationRecon-ciliationisanextensiontothisprofilerequiringthattheworkitemsand/orcontentbeupdated.

PortableDataforImaging None None -XDSforImaging XDS(ITI) DocumentConsumer,Docu-

mentRegistry,andDocumentRepositoryactorsfromITIXDSarerequiredforXDS-I.

Documentcontenttypesandmetadataarespecialized.

ImportReconciliationWorkflow

ScheduledWorkflow RequiredforWorkflow(includingScheduledImportOption)

SupporttheworkflowrelatedtransactionsofScheduledWorkflow.

PatientDemographicsQuery[ITI]

RequiredforUnscheduledImportOption

PatientDemographicinfor-mationisobtainedusingPatientDemographicQuery.

dei dati del paziente secondo i suggerimenti contenuti dell’ Health Insurance Portability and Accountability Act (HIPAA) redatto dal congresso degli Stati Uniti nel 1996. Garantisce anche il controllo sicuro sull’attività dell’utilizzatore delle in-formazioni tra sistemi distribuiti e interconnessi. Questo pro-filo è stato sostituito dal profilo Audit Trail and Node Authen-ticaton (ATNA) pubblicato nel Technical Framework per l’IT.

• Access to Radiology Information (ARI) stabilisce un meccani-smo basato sul formato DICOM per la distribuzione di infor-mazioni radiologiche, comprendenti immagini e documenti, all’interno del dipartimento di Radiologia e/o altri interessati ad acquisirle, quali patologia, chirurgia, oncologia.

4.5.5.2 Gli AttoriGli Attori, come precedentemente enunciato, individuano sistemi informativi o parti che li costituiscono e che producono, gestiscono o rielaborano dati, informazioni ed immagini dipendenti da ope-razioni svolte nell’azienda sanitaria. Di seguito vengono descritti alcuni degli attori coinvolti nei Profili di Integrazioni delineati per la Radiologia.

In linea di massima possiamo individuare alcuni insiemi contrad-distinti da macro funzionalità a cui far riferire gli attori enunciati nel manuale come:1. i sistemi dedicati alla gestione dei dati personali del paziente, all’impostazione delle sequenze operative necessarie per eseguire esami e prestazioni (di laboratorio, di esecuzione di immagini ra-diografiche), alla definizione ed attivazione di sequenze di attività con conseguente valutazione ed addebito dei costi sostenuti, alla sicurezza delle informazioni trattate. Tra questi identifichiamo:• ADT (admission/discharge/transfer) Patient Registration – un

sistema preposto alla registrazione/modifica dei dati demogra-fici ed amministrativi di un paziente. In particolare registra un nuovo paziente con gli attori chiamati Order Placer e Depart-ment System.

• Department System Scheduler/Order Filler – un sistema in-formativo dipartimentale che supporta l’esecuzione di ordini provenienti dall’esterno o dallo stesso dipartimento. Definisce la lista delle azioni da realizzare consentendo ad un altro attore di stabilire a quale coppia azione/evento di pertinenza deve essere assegnato un costo per la successiva fatturazione.

• Order Placer – un sistema ospedaliero o aziendale che genera e distribuisce correttamente gli ordini per i vari dipartimenti della struttura.

• Secure Node – un sistema che verifica le credenziali di un utente od un nodo esterno per autorizzare o meno l’accesso o lo scambio di informazioni. Mantiene i parametri temporali, ricevuti da un sistema generatore (Time Server) della corretta data ed ora per tutta l’organizzazione. Invia al sistema Audit Record Repository tutte le informazioni relative alle richieste di accesso per la successiva registrazione.

• Charge Processor – un sistema che riceve i costi da fatturare per le varie prestazioni eseguite e che fa parte del sistema di contabilità dell’azienda.

2. i sistemi per l’archiviazione ed il recupero delle immagini, per la loro esatta rappresentazione, per l’immagazzinamento e recupero da media differenti, per la creazione di referti comprendenti immagini ed annotazioni, per la stampa corretta dell’immagini. Vediamone alcuni:• Acquisition Modality – un sistema per l’acquisizione e la cre-

azione di immagini del paziente prodotte da un dispositivo radiologico e/o nucleare. Può definire anche altri elementi di interesse relativi alle immagini per una loro corretta rappre-sentazione o per corredarle con dei valori misurati di interesse.

• Evidence Creator – un sistema che provvede elementi risul-tanti dal processo di indagine sul paziente e che producono immagini, annotazioni e/o documentazione complessiva da trasmettere all’Image Archive. Si interfaccia anche con il Post Processing Manager per partecipare alla gestione dei passi di post elaborazione delle informazioni.

• Image Archive, Image Manager, Image Display - sistemi che consentono la memorizzazione dei vari elementi e dei do-cumenti contenenti immagini, la loro gestione all’interno dell’organizzazione sanitaria e corretta rappresentazione sui media adatti a visualizzarli.

• Print Composer – un sistema che genera richieste di stampa ad un Print Server secondo lo standard DICOM, comprendenti informazioni sullo stato della presentazione riferita a tabelle di codifica dei toni colore (Presentation Lookup Table).

3. sistemi che generano e trasmettono incartamenti, talvolta anche rapporti diagnostici nella forma di DICOM Structured Reporting Object (Report Creator), che li gestiscono all’interno dell’azienda e determinano i passi dei processi ad essi riferiti (Report Manager), che li recuperano e li visualizzano (Report Reader) e che li immagaz-zinano (Report Repository).

4.5.5.3 Le TransazioniTecnologicamente la struttura di IHE è fondata sui processi che in-tercorrono all’interno di un’organizzazione sanitaria. Gli attori ap-partenenti ai Profili di Integrazione interagiscono attivamente per risolvere le esigenze di integrazione ed il flusso operativo richiesto per l’esecuzione corretta dei processi stessi. A questo scopo sono uti-lizzate delle transazioni realizzate mediante dei messaggi descritti in uno degli standard disponibili, quali HL7 e DICOM. Senza entrare nel dettaglio delle singole transazioni, per le quali si rimanda al ma-nuale, vediamo di seguito come i due standard siano stati adattati al contesto di IHE per la Radiologia e a quali famiglie di transazioni siano stati rispettivamente riferiti per modellare eventi del mondo reale.

Transazioni secondo HL7Lo standard HL7 individua l’insieme dei messaggi necessari alla tra-smissione dei dati personali del paziente, delle informazioni ammi-nistrative ad esso connesse ed alla distribuzione di ordini clinici, di osservazioni e risultati. In questa comunicazione sono coinvolti sia sistemi informativi di supporto all’azienda nel suo complesso che determinati sistemi adoperati a sostegno di servizi puntuali. HL7 subordina l’invio di messaggi a degli eventi specifici che li attivano, quali ad esempio “un nuovo paziente viene ammesso” o una “nuo-va disposizione è stata emessa”. Questa natura per cui i messaggi sono frutto di eventi (event driven) ben si adatta alla creazione di diagrammi di interazione che definiscono accuratamente i ruoli, le responsabilità ed il tipo di comunicazione esistenti in un dialogo.

Il Technical Framework di IHE stabilisce un insieme di transa-zioni da adoperare per comunicare tre ampie categorie di informa-zioni: relative al paziente, alle disposizioni ed ai risultati. Il dialogo avviene tra il sistema ADT e i sistemi preposti all’introduzione di disposizioni per quanto riguarda le richieste e tra il Department System Scheduler, e l’Image Manger, per la loro esecuzione. Consi-deriamo di seguito le tre tipologie di messaggi informativi trasmessi:1. Le informazioni riferite al paziente – ADT, produce una serie

di messaggi HL7, per la gestione dei dati relativi al paziente, in risposta ad un gran numero di eventi scatenanti (più di 60). In generale ADT, in tutti i casi in cui sono elaborate informazioni di questo tipo, comunica con i sistemi che richiedono informa-zioni sul degente, garantendo che i vari oggetti trasmessi gli sia-no correttamente assegnati. Il documento tecnico di IHE deter-mina una transazione per la registrazione del paziente (Patient Registration) in funzione degli eventi mostrati in Figura 4.40.

Inoltre viene definita anche una transazione per la modifica dei suoi dati (Patient Update) in caso di trasferimento, dimissione, variazione di dati personali, composizione di dati duplicati. IHE considera anche il caso di richiesta di prestazioni per un paziente non identificato, consentendo l’attivazione degli ordi-ni mediante un colloquio diretto con gli attori Order Placer e Order Filler e non impedendo in ultima analisi la fornitura ser-vizio. La riconciliazione delle informazioni viene eseguita una volta che l’esecuzione dell’ordine sia stata completata.

2. Le informazioni riferite alle disposizioni – HL7 prevede un messaggio specifico, denominato ORM (order management) per la gestione degli ordini ed informazioni di stato tra l’Order Placer e l’ Order Filler. Il coordinamento della trasmissione tra gli attori coinvolti invece dipende da una comunicazio-ne di risposta denominata in HL7 ORR (order responses). In particolare il Technical Framework utilizza queste informative in quattro specifiche transazioni nominate: Placer Order Ma-nagement, Filler Order Management, Procedure Scheduled e Procedure Update. In questo modo sono comunicate informa-zioni relative al paziente per cui la disposizione è stata rilascia-ta, il tempo di programmazione della procedura e le attività specifiche da soddisfare. A differenza dei messaggi ADT che sono provocati da eventi, le comunicazioni di comandi si ba-sano su un codice di controllo della prescrizione che informa sullo stato delle transizioni (nuovo ordine, disposizione termi-nata). Nel modello IHE gli ordini sono inviati da un sistema che li emette (order entry) o che li definisce (Department System Scheduler). Quest’ultimo in particolare determina i passaggi necessari alla completa caratterizzazione dell’ordine da tra-smettere all’attore coinvolto per ultimo negli aspetti operativi della Radiologia: l’Image Manager.

3. Le informazioni riferite ai risultati – nelle transazioni che coin-

*-A01, A04, A05, A11, A38

ADT Patient Registration

HL7 ADT^*

MPIDepartment SystemScheduler/Order Filler

Order Placer

Figura 4.40Transazioni in HL7 provocate dagli eventi indicati dall’asterisco Adattato da [IHE Technical Framework, Vol.II, 2007] pag. 18

volgono referti o relazioni IHE si utilizza il messaggio HL7 detto ORU (observation results unsolicited) per trasmettere do-cumenti di testo in codice ASCII tra un sistema di gestione della documentazione ed una base dati. Nonostante molti rap-porti siano strutturati nel formato DICOM, IHE fornisce una completa mappa dei campi comuni ai due standard e incorag-gia l’emissione di rapporti scritti mediante semplici caratteri testo, al fine di risolvere le differenze esistenti tra le molteplici famiglie di sistemi di archiviazione.

Transazioni secondo DICOMDICOM [DICOM Standard, 2003] sin dalla prima metà degli anni ’90 si è affermato come strumento per il trasferimento delle immagini prodotte dai dispositivi adoperati nell’indagine radiologi-ca. In poco tempo, dopo essere stato accettato come standard uni-versale per il trasporto di immagini dalla comunità dei radiologi, si è diffuso in altri settori della medicina: dalla cardiologia alla radio terapia, dalla patologia all’oculistica, includendo anche le specifiche di molte funzioni d’onda mono dimensionali studiate ed analizzate da alcune specialità cliniche. DICOM ha successivamente influen-zato altri aspetti dell’organizzazione sanitaria relativi alla gestione ed alla preparazione, esecuzione, immagazzinamento e recupero delle immagini trovando una continua corrispondenza all’interno del modello transazionale proposto da IHE. Vediamo di seguito i problemi risolti dall’adozione di questo standard:1. la connessione in rete di dispositivi per la stampa delle imma-

gini e la produzione di film (chiamate DICOM Print), che all’interno di una rete ospedaliera servono sia il dipartimento di radiologia che altre aree cliniche.

2. Lo scambio di immagini mediante media per la memorizzazio-ne dei dati (dischi ottici, CD-Rom, sistemi di storage portati-li). Tra questi grande successo ha avuto la modalità DICOM CD-R per immagazzinare dati temporali, immagini, e film che possono essere rilasciate al paziente, da utilizzare anche con differenti organizzazioni sanitarie.

3. La necessità di trattare nel trasferimento delle immagini, per la gestione di un corretto flusso operativo, anche informazio-ni differenti da inviare al sistema informativo dipartimentale, quale il sistema di radiologia (Department System Scheduler o Order Filler nella terminologia di IHE) e i PACS (IHE Image Manager o Image Archive). La classe Modality Worklist è stata la prima funzionalità ad essere specificata. Questa transazione invia al dispositivo per l’acquisizione numerose informazioni,

quali i dati demografici del paziente, la procedura richiesta, il piano di lavorazione, consentendo allo specialista di sele-zionare un paziente od un elemento da studiare all’interno di una lista, riducendo gli errori operativi. Un’altra classe succes-sivamente introdotta ed utilizzata è stata la DICOM Storage Commitment il cui scopo è quello di garantire che un’imma-gine non possa essere cancellata da un sistema di acquisizione, a meno che un altro dispositivo (un archivio per esempio) non sia in carica come gestore e responsabile delle immagini pro-dotte. Di recente DICOM ha introdotto la classe Performed Procedure Step con lo scopo di informare il Department Sy-stem Scheduler, l’Image Manger e l’Image Archive, che una delle attività previste e determinate è stata ultimata. IHE ha contribuito in maniera effettiva perché queste tre famiglie di transazioni (Modalità Worklist, Storage Commitment a Per-formed Procedure Step) fossero ampiamente supportate dalle stazioni di lavoro per l’acquisizione di immagini, dai PACS e dal sistema informativo dipartimentale di Radiologia all’inter-no del profilo di integrazione Schedule Work Flow.

4. La necessità di uniformare la funzione di rappresentazione della scala dei toni di grigio sullo schermo, in modo da rispet-tare la percezione che ha della luminanza l’occhio umano. Di conseguenza ogni dispositivo, che riceve od invia immagini, calibrato sulla DICOM Gray-Scale Display Function non in-fluenza con la sue caratteristiche di luminanza la percezione dell’immagine e quindi non introduce possibili errori di va-lutazione sulla stessa. Ulteriori elementi considerati nella cali-brazione della scala dei toni di grigio dallo standard DICOM sono le trasformazioni (inversione, rotazione, zoom) a cui e’ stata sottoposta l’immagine o altre annotazioni ad essa ineren-ti di tipo testuale o grafico. IHE ha incluso questi servizi di presentazione dell’immagine nel profilo di integrazione Con-sistent Presentation of Images.

5. L’esigenza di gestire referti, misurazioni e la loro relazione con le immagini di riferimento. DICOM ha proposto la classe Structured Reporting per codificare e strutturare questa fa-miglia di documenti. Gli oggetti appartenenti alla classe pos-sono essere estremamente complicati, proprio per rispondere alle specifiche del vasto mondo delle applicazioni rivolte alla produzione di rapporti. La classe Structured Reporting per-mette di registrare le misurazioni direttamente nella stazione di lavoro che le hanno acquisite o integrate con viste ed analisi di riferimento o all’interno di applicazioni per la diagnosi assi-

stita a computer. Gli oggetti DICOM di questa classe sono in grado di catturare anche annotazioni informali scarabocchiate su pezzi di carta o sulla copertina delle immagini. In generale sono di estrema utilità per quelle applicazioni di ricerca inten-siva sui dati disponibili (data mining). IHE si serve della classe Structured Reporting all’interno del profilo di integrazione Simple Image and Numeric Report.

4.5.5.4 Il caso del flusso amministrativo e procedurale per una richiesta di una prestazione

La sequenza di passi illustrata nelle Figure 4.41 e 4.42 descrive il tipico flusso di attività che devono essere svolte nell’organizzazione ospedaliera per eseguire una prestazione in cui è richiesta la produ-zione di immagini radiografiche. In questo caso di studio riferito al profilo di integrazione Scheduled Workflow i processi trattati, suddivisi in amministrativo e proce-durale, sono riferibili a pazienti nuovi o già conosciuti all’istitu-zione, sia degenti che ad essa esterni. In generale nel modello IHE un medico imposta una prescrizione radiologica mediante l’attore identificato come Order Placer che nella realtà può corrispondere ad un sistema informativo ospedaliero o clinico. A questo punto una richiesta di una prestazione radiografica, conseguenza dell’or-dine, giunge al Department System Scheduler, anche identificato come Order Filler. IHE non precisa mai il tipo di sistema informa-tivo a cui deve essere assegnato un ruolo specifico, il quale, nel caso dell’Order Filler, potrebbe coincidere con un RIS. Il modello IHE esige solo che all’interno dell’organizzazione esista un componen-te in cui le funzionalità dell’attore prescritto siano state sviluppate. L’Order Filler interessato assegna infine un codice univoco di iden-tificazione ad una o più prestazioni desiderate; il codice prende il nome di Accession Number. Ogni richiesta così etichettata è compo-sta da una serie di ben determinate procedure (requested procedure) che rappresentano l’unità di scala del lavoro svolto da un radiologo da poter fatturare e alla cui esecuzione corrisponde un referto. I codici (Request Procedure Identifiers) delle singole attività radiologi-che necessarie al soddisfacimento della richiesta sono forniti da una parte del sistema. Questi codici sono differenti dal singolo Acces-sion Number, il quale può comprendere un insieme di particolari procedure. Le varie procedure a loro volta sono precisate da una serie di passi predefiniti ed ordinati secondo i protocolli di imposta-zione (scheduled procedure step), che rappresentano le componenti del lavoro svolto dal tecnico di radiologia presso il dispositivo di acquisizione. Esse specificano un piano di lavoro, differente per i

vari tipi di procedure, che lo specialista deve eseguire; i termini una volta soddisfatti, assumono l’etichetta di performed procedure step. La sequenza di azioni predeterminate sono funzione delle modalità implementative caratteristiche dei dispositivi forniti dal mercato; la loro esecuzione provoca un messaggio di evento eseguito. Quando la richiesta iniziale viene soddisfatta, il radiologo scrive il referto a chiusura delle attività svolte e di conseguenza viene inviata comuni-cazione del completamento agli attori Order Filler e Order Placer.

Nel diagramma di Figura 4.42 è mostrata una particolare posizio-

Query ModalityWorklist [RAD-5]

Schedule Procedure and/orAssign Protocol

Register/Admit Patient

Create Order

Procedure Scheduled[RAD-4]

Patient Registration[RAD-1]

Place Order Mgmt New [RAD-2]

ADTAcquisition Modality

Image Manager

Department SystemScheduler/Order Filler

Order Placer

Figura 4.41Processo per l’esecuzione di una richiesta radiografica – parte amministrativa Adattato da [IHE Technical Framework, Vol.I, 2007] pag. 47

Figura 4.42Processo per l’esecuzione di una richiesta radiografica – parte proceduraleAdattato da [IHE Technical Framework, Vol.I, 2007] pag. 48

Modality PresentationState Stored [RAD-9]

Modality ProcedureStored [RAD-8]

Order Status Update [RAD-3]

Image Availability Query [RAD-11]

Storage Commitment [RAD-10]

Print Request [RAD-23*]

PerformAcquisition

Modality ProcedureStep Completed [RAD-7]

Modality ProcedureStep in Progress [RAD-6]

PrintComposer

PrintServer

Acquisition Modality

Image Manager/Image Archive

Department SystemScheduler/Order Filler

Order Placer

ne della transazione Modality Procedure Step Completed [RAD-7] poiché IHE non specifica un momento esatto per la sua esecuzione, essa può avvenire in ogni istante tra la creazione di un immagine, la sua trasformazione in formati per la stampa, la memorizzazione e l’effettivo immagazzinamento.

4.5.6 Strumenti “Medical Enterprise Simulators and Analyzers”

Per facilitare il processo di verifica dell’adesione dei prodotti svi-luppati dai vari distributori alle linee guida sull’interoperabilità proposte, le organizzazioni che sostengono l’iniziativa IHE (RSNA, HIMSS) hanno incaricato l’Electronic Radiology Laboratory dell’Istituto di Radiologia, Washington University di St.Louis, di creare un insieme di strumenti software chiamati Medical Enter-prise Simulators and Analyzers (MESA) [Electronic RadiologyLab, 2008]. Questo supporto è progettato affinché le aziende - che sono interessate a offrire nei propri prodotti le caratteristiche contempla-te da IHE - siano in grado di predisporli in modo appropriato alla valutazione durante i Connecthaton. Gli strumenti MESA sono resi disponibili ai partecipanti nel periodo dimostrativo e vengono resi di pubblico dominio al termine del ciclo annuale. Il sistema MESA è suddiviso in quattro aree di componenti a cui possono contribuire gli sviluppatori degli strumenti di verifica e a cui possono riferirsi gli utilizzatori. Abbiamo:• facilities – subroutine, classi e strutture per fornire funzionali-

tà di basso livello alle applicazioni;• simulatori – applicativi di alto livello comunicanti mediante

messaggi con altri prodotti dello stesso rango;• programmi di Utilità – per verificare funzionalità specifiche o

fornire semplici programmi di test;• documentazione – un sistema di documentazione in formati

html e pdf accessibile tramite web.

Bibliografia

Paragrafo 4.1Aronson AR. Effective mapping of biomedical text to the UMLS

Metathesaurus: the MetaMap program. Proc AMIA Symp. 2001:17-21.

Bodenreider O, Willis J, Hole W. [Online] 2004. The Unified Med-ical Language System: What is it and how to use it?. Tutorial a MEDINFO, 8 September 2004; San Francisco CA. Disponi-bile all’indirizzo: http://www.cs.uwaterloo.ca/~cdimarco/pdf/UMLS_tutorial.pdf. Ultimo accesso: 23 settembre 2008.

Bondi A, Nesti P, Rossi Mori A, SNOMED International – No-menclatura sistematica della medicina umama e veterinaria. Udi-ne 1995 Pubblicazioni Medico Scientifiche.

Cerveri P, Pinciroli F. Symbolic representation of anatomical knowledge: concept classification and development strategies. J Biomed Inform. 2001;34(5):321-47.

Kleinsorge R, Willis J, Cathcar G. Unified Medical Language Sys-tem® (UMLS®) Basics [Online] 2006. National Institutes of Health U.S. Department of Health & Human Services National Library of Medicine. Disponibile all’indirizzo URL: http://www.nlm.nih.gov/research/umls/pdf/UMLS_Basics.pdf. Ultimo ac-cesso: 24 settembre 2008.

Tringali M, Hole WT, Srinivasan S. Integration of a standard gas-trointestinal endoscopy terminology in the UMLS Metathesau-rus. Proc AMIA Symp. 2002:801-5.

Unified Medical Language System (UMLS) [Online] 2004. Di-Di-sponibile all’indirizzio URL: http://www.nlm.nih.gov/research/umls/about_umls.html. Ultimo accesso: 23 settembre 2008.

Paragrafo 4.2Dolin RH, Spackman KA, Markwell D. Selective retrieval of pre-

and post-coordinated SNOMED concepts. Proc AMIA Symp. 2002:210-4.

ISO/TC 215 WG3 N163- Accompanying annex to draft NWIP - Health informatics - Categorical structure for documentation of patient findings and problems. [Online] 2004; Disponibile all’indirizzo URL: http://www.tc215wg3.nhs.uk/pages/pdf/

wg3_163.pdf. Data di ultimo accesso: 11 dicembre 2008. Markwell D. Clinical Coding for the Future. SNOMED Clinical

Terms. [Online] 2005; Disponibile all’indirizzo URL: www.pri-mis.nhs.uk/Presentations/Presentations2005/5D-clinicalcoding-forfuture.pps. Ultimo Accesso: 12 dicembre 2008.

National Centre for Codification in Health (NCCH). Systematized Nomenclature of Medicine (SNOMED). Codification Corner. Coding Matters. 2001;8(2):4-7.

NHS - Connecting for Health. Snomed Clinical Term [Online] 2005. Disponibile all’indirizzo URL: http://www.connecting-forhealth.nhs.uk/systemsandservices/data/snomed. Data di ulti-mo accesso: 10 Dicembre 2008.

SNOMED International. [Online]. 2005 May 12; Disponibile all’indirizzo URL: http://www.snomed.org/index.html. Data di ultimo accesso: 7 Luglio 2005.

Sommers SC. Systematized nomenclature of pathology. Pathol Microbiol (Basel). 1967;30(5):826-7.

Spackman KA. Finally, a Standard Terminology for Health Care? [Online]. 2003 March 3; disponibile all’indirizzo URL: http://www.hinfgrad.umn.edu/seminar/02-03_Spring/030327_Spack-man/Spackman-Lazarow-lecture_files/frame.htm. Data di ulti-mo accesso: 10 Dicembre 2008.

Stephan E. A life of John Graunt. [Online]. 2005 July 1; disponibi-[Online]. 2005 July 1; disponibi-le all’indirizzo URL: http://www.ac.wwu.edu/~stephan/Graunt/grauntbio.html. Data di ultimo accesso: 10 Dicembre 2008.

University of Adelaide. Discipline of General Practice - Health In-formatics - Current Research Programs - Health Informatics. Introduction to drug dose-form in the Poly-browser and Au-thoring Tool [Online]. 2005 January 6; Disponibile all’indirizzo URL: http://www.adelaide.edu.au/health/gp/research/current/informatics/#pat intro.pdf. Data di ultimo accesso: 11 Dicembre 2008.

Walker D. SNOMED Clinical Terms – Report 2 [Online]. 2004; Disponibile all’indirizzo URL: http://www.adelaide.edu.au/he-alth/gp/research/current/vocab/2_02_2.pdf. Data di ultimo ac-cesso: 10 Dicembre 2008.

Wang AY, Barrett JW, Bentley T, Markwell D, Price C, Spackman KA, Stearns MQ. Mapping between SNOMED RT and Clinical terms version 3: a key component of the SNOMED CT devel-opment process. Proc AMIA Symp. 2001:741-5.

White MD, Kolar LM, Steindel SJ. Evaluation of vocabularies for electronic laboratory reporting to public health agencies. J Am Med Inform Assoc. 1999;6(3):185-94.

Why the SNOMED Deal is Important. Health Data Management. [On line] 2 Luglio 2003. Disponibile all’indirizzo URL: http://www.healthdatamanagement.com/news/8711-1.html. Data di ultimo accesso: 11 Dicembre 2008.

Paragrafo 4.3Dolin RH, Alschuler L, Beebe C, Biron PV, Boyer SL, Essin D et

al. The HL7 Clinical Document Architecture. J Am Med Inform Assoc. 2001;8(6):552-69.

Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV et al. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc. 2006;13(1):30-9.

Ferranti JM, Musser RC, Kawamoto K, Hammond WE. The clini-cal document architecture and the continuity of care record: a critical analysis. J Am Med Inform Assoc. 2006;13(3):245-52.

Hammond WE, Cimino JJ. Standards in Medical Informatics. In: Shortliffe EH, Perreault LE, Wiederhold G, Fagan LM, editors. Medical Informatics: Computer Applications in Health Care and Biomedicine. New York: Springer-Verlag; 2001. 212-256.

Health Level Seven Organization. Health Level 7 Communication Standard. Version 2.3.1. May 1999.

Hinchley A. Understanding Version 3. A Primer on the HL7 Ver-sion 3 Communication Standard1st ed. Munich, D: Alexander Moench Publishing; 2003, pag. 14-15.

Muller ML, Uckert F, Burkle T, Prokosch HU. Cross-institutional data exchange using the clinical document architecture (CDA). Int J Med Inform. 2005;74(2-4):245-56.

Paragrafo 4.4Garattini A, Randazzo L, Righi D. Guida alle reti: LAN. Milano:

Arnoldo Mondadori Editore; 2004. p. 23-33.Giovagnoni A, Golfieri R, Baffoni L, Barone D, Benea G, Borasi G

et al. PACS-ITALIA [Online]. 2002; Disponibile all’indirizzo: URL:http://rad.med.unisi.it/pacsitalia/indice.htm Ultimo acces-so: 30 Gennaio 2008.

Huang HK. Medical Image Management in Healthcare Enterpri-se. Technology & Application: Global Health Care Issue 2002; 3:84-88.

Huang HK. Enterprise PACS and image distribution. Comput.Med.Imaging Graph. 2003; 27(2-3):241-253.

Huang HK. PACS and imaging informatics: basic principles and applications. Hoboken, N.J.: Wiley-Liss; 2004.

RSNA.org [Online]. 2008; Disponibile all’indirizzo: URL:http://

www.rsna.org/ Ultimo accesso: 30 Gennaio 2008.The DICOM Standard [Online]. 2008; Disponibile all’indirizzo:

ftp://medical.nema.org/medical/dicom/2008. Ultimo accesso: 5 settembre 2008.

Paragrafo 4.5ACC/HIMSS/RSNA. IHE Technical FrameWork. Volume I - In-

tegration Profiles. [Online] Revision 8.0. 2007; Disponibile all’indirizzo: URL: http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8.pdf. Ultimo accesso: 27 marzo 2009.

ACC/HIMSS/RSNA. IHE Technical Framework. Volume II - Transactions. [Online] Revision 8.0. 2007; Disponibile all’indi-2007; Disponibile all’indi-rizzo URL: http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-2.pdf. Ultimo accesso: 27 marzo 2009.

DICOM “Digital Image and Communication in Medicine” Stan-dard. [Online]. 2003; Disponibile all’indirizzo: URL: http://me-2003; Disponibile all’indirizzo: URL: http://me-dical.nema.org/ Ultimo accesso: 27 marzo 2009.

Health Level 7. [Online]. 2004; Disponibile all’indirizzo: URL:http://www.hl7.org Ultimo accesso: 27 marzo 2009.

HealthCare Information and Management System Society (HIMSS). [Online]. 2007; Disponibile all’indirizzo: URL: http://www.himss.org/ Ultimo accesso: 27 marzo 2009.

HIMSS/RSNA. IHE Integration Statements. [Online]. 2003; Disponibile all’indirizzo URL: http://www.ihe.net/Resources/upload/ihe_integration_statement_form.pdf Ultimo accesso: 27 marzo 2009.

IHE International Integrating the Healthcare Enterprise. [Online]. 2008; Disponibile all’indirizzo: URL: http://www.ihe.net/ Ulti-mo accesso: 27 marzo 2009.

IHEa. IHE Organization Chart. [Online]. 2008; Disponibile all’in-2008; Disponibile all’in-dirizzo: URL: http://www.ihe.net/About/Organization/upload/chart.pdf Ultimo accesso: 27 marzo 2009.

IHEb. The IHE Process to Achieve Standards-based Interoperabil-ity. [Online]. 2008; Disponibile all’indirizzo: URL: http://www.ihe.net/About/process.cfm Ultimo accesso: 27 marzo 2009.

Mallinckrodt Institute of Radiology. Electronic Radiology Lab. In-tegrating the Healthcare Enterprise. Testing Tools and Integra-tion Projects. [Online], 2008. Disponibile all’indirizzo URL: http://erl.wustl.edu/research/ihe.html Ultimo accesso: 27 marzo 2009.

Radiology Society of North America (RSNA). [Online]. 2006; Di-2006; Di-sponibile all’indirizzo: URL: http://www.rsna.org/ Ultimo acces-so: 27 marzo 2009.

5 Casi di prodotti e servizi

5.1 Il Centro Unico di Prenotazione

5.1.1 Motivazioni

Il Centro Unico di Prenotazione (CUP) nasce come aiuto per i pa-zienti e per le istituzioni sanitarie, per garantire una maggiore ef-ficienza ed efficacia delle prenotazioni di accertamenti clinici, allo scopo di ottenere minori tempi di attesa per il paziente.

Senza l’ausilio di un CUP, il paziente è costretto a contattare i sin-goli centri di prenotazione delle strutture sanitarie per conoscerne i tempi di attesa e decide successivamente in quale struttura prenota-re l’esame. Il paziente dovrebbe poi disdire le eventuali prenotazioni fatte nelle altre strutture, cosa che spesso non avviene se non sono presenti penali in caso di non effettuazione della visita senza preav-viso (per esempio, se la prenotazione non è disdetta almeno con un determinato anticipo, il ticket deve essere pagato)[Donatini et al., 2001]. Senza un CUP la singola struttura sanitaria non è in grado di conoscere le prenotazioni dei pazienti in altre struttura della zona.

Al contrario, in presenza del CUP, è l’operatore del call center clinico a proporre al paziente la prima data libera per l’accertamen-to che deve sostenere, in base alla disponibilità da parte di tutte le strutture sanitarie facenti riferimento a quel determinato CUP. Starà poi al paziente accettare o richiedere di effettuare l’esame in un’altra struttura o in un’altra data rispetto a quella proposta.

Le motivazioni per creare un centro unico di prenotazione sono molteplici:• Rischio: code lunghe al punto da aggravare lo stato del pa-

ziente o da non consentirgli un monitoraggio periodico. Per esempio, una donna in stato di gravidanza deve effettuare tre ecografie con precise scadenze temporali (a 10-12 settimane, a 20-22 settimane e a 32-34 settimane), ma spesso i tempi di attesa per un’ecografia superano i di tre mesi; un paziente affetto da tumore potrebbe dovere effettuare periodicamente una TAC o una risonanza magnetica per controllare il decorso della malattia;

• Risorse: limitatezza delle risorse diagnostiche e terapeutiche;

• Distribuzione: dispersione territoriale delle risorse. Un pazien-te che necessita di effettuare più esami dovrebbe per comodità poterli effettuare nella stessa struttura;

• Molteplicità delle prescrizioni per volta per paziente: è meglio fare esami diversi allo stesso paziente nello stesso giorno;

• Necessitàdiottimizzazione: dare al paziente la possibilità di de-cidere tempo e luogo della visita, in funzione della distanza e delle sue necessità; bisogna tenere conto non solo della resi-denza, ma anche della residenza momentanea (per esempio, se il paziente è in villeggiatura, deve potere effettuare l’accer-tamento in un luogo vicino al suo indirizzo di villeggiatura piuttosto che vicino alla propria residenza);

• Importanzaperilfollowupdieseguireilnuovoesamenellostessoluogodelprecedente.a. Per una maggiore precisione per garantire una ripetibilità dei

risultati:- strumento di misura;- abilità dell’operatore;- esperienza pregressa sui pazienti;

b. Per un confronto seriale affidabile:- tra grandezze quantitative;- tra referti completi;

• Differentinomicheoperatoridiversi (medici e istituzioni) dan-no alla stessa indagine, con conseguente necessità di usare unaterminologia controllata: bisogna utilizzare gli stessi termini anche per le prescrizioni, per dare la possibilità al paziente di scegliere dove prenotare gli esami e di capire in dettaglio a quale trattamento verrà sottoposto;

• Differentiorganizzazionitemporalideisingoliesami,percuioc-correunaprogrammazionecoordinata:- periodo della giornata (il prelievo del sangue necessita di

essere effettuato alla mattina presto, solitamente entro le 8:00) [PHRC, 2008];

- durata dell’esame (un esame di risonanza magnetica neces-sita di almeno mezz’ora per essere effettuato);

- ottimizzazione dei tempi di accertamento tra i vari pazienti, per limitare i tempi morti (nell’effettuare un’urografia, oltre a dover essere eseguita la mattina perché richiede almeno otto ore di digiuno, occorre inizialmente iniettare il liqui-do di contrasto, per poi effettuare radiografie a intervalli di tempo regolari di 30 minuti) [American College od Radio-logy, 2004].

Queste motivazioni portano ad alcune conseguenze:

231Capitolo 5Casi di prodotti e servizi

• bisogno di un’interazione umana tra i pazienti e le istituzioni. Per questo si ricorre a un call center clinico, i cui addetti de-vono provenire dal settore sanitario, con conoscenze almeno infermieristiche e un background anche di tipo informatico per potere gestire il software del CUP;

• limitazione alle prestazioni non rischiose. Il CUP può accet-tare richieste di prestazioni con informazioni (codice della prescrizione, medico di base, ecc.); non trapianti, sostituzioni valvolari, ecc.

5.1.2 Organizzazione

Si può quindi definire il CUP come un software di aiuto al gestore del call center clinico per minimizzare i ritardi di esecuzione degli accertamenti diagnostici e terapeutici, mantenendo per il paziente condizioni logistiche sostenibili e buona soddisfazione.

Il beneficiario del CUP è quindi il paziente, mentre l’utente è l’operatore del call center clinico (Figura 5.1).

5.1.2.1 L’offertaIl CUP è di aiuto alle istituzioni sanitarie, in quanto permette di tenere maggiormente sotto controllo il cittadino/paziente, dimi-nuendo il rischio che questo non si presenti all’accertamento e ot-timizzando così le prestazioni degli impianti necessari a svolgere gli accertamenti. Il CUP aiuta il paziente a trovare la migliore soluzio-ne per l’effettuazione degli accertamenti clinici, sia come data, sia come luogo di effettuazione.

Ogni istituzione (ospedale, laboratorio di analisi) dispone di una certa impiantistica; è quindi in grado di effettuare solo alcuni tipi di accertamenti clinici tra tutti quelli esistenti. Gli impianti sono presenti in una certa quantità, di conseguenza può essere effettuato un numero limitato di esami al giorno. In più, ogni impianto ne-cessita di una manutenzione periodica, solitamente programmata.

paziente eprescrizioni

operatore callcenter clinico

effettuazione dei pagamenti

gestore dei diritti

enti clinici Figura 5.1All’operatore del call center clinico arrivano informazioni dal paziente sulla prescrizione (1) e dagli enti clinici (2) sulla disponibilità degli accertamenti: tramite il CUP (3) propone al paziente dove e quando effettuare l’accertamento. Enti esterni al CUP si occupano della gestione dei pagamenti (4) e dei diritti dei pazienti (5), per definire chi ha diritto all’esenzione dal ticket o ha diritti o convenzioni particolari

Nei periodi di manutenzione l’impianto non può effettuare i relativi accertamenti diagnostici.

Per ogni istituzione viene definita l’offerta di cui dispone, in ter-mini di accertamenti clinici disponibili e carico di lavoro che la stes-sa può sostenere utilizzando gli impianti di cui dispone. Per ogni accertamento vengono descritti:• codice dell’accertamento diagnostico, come identificativo uni-

co;• nome dell’accertamento diagnostico;• vincoli di prescrivibilità (per esempio un prelievo di sangue va

effettuato alla mattina entro le 10, una risonanza magnetica richiede almeno 30 minuti di tempo, nell’esecuzione di un esame urografico non è necessario finire l’accertamento su un paziente per iniziare quello sul paziente successivo);

• dati amministrativi, che si riferiscono al tipo di sistema sanita-rio (pubblico o privato) e all’eventuale pagamento di un ticket per effettuare l’esame;

• durata dell’esame;• carico di lavoro. Definisce il limite massimo di accertamenti

effettuabili al giorno/settimana/mese: è necessario definire tre differenti carichi di lavoro perché quelli settimanale e mensile non corrispondono solo a una moltiplicazione del carico di lavoro giornaliero, in quanto vanno tenuti in considerazione i periodi di manutenzione dell’impianto;

• logistica di disponibilità, che definisce la frequenza delle ma-nutenzioni effettuate sull’impianto e la durata di tali manu-tenzioni.

Per rappresentare l’offerta diagnostico-terapeutica di una singola istituzione si può utilizzare una tabella come quella definita in Ta-bella 5.1.

istituzione i

codice esame no

e carico di lavoro logistica di disponibilità

giornaliero settimanale mensile frequenza di manutenzione

tempo impiegato

Considerando tutte le offerte diagnostico-terapeutiche di tutte le istituzioni presenti nella zona di competenza del CUP, si può defini-re una seconda tabella, che ha su ogni colonna il risultato dell’unio-ne delle offerte di tutte le istituzioni e ogni riga rappresenta una diversa istituzione (vedi Tabella 5.2).

Tabella 5.1Offerta dell’istituzione

i-esima

accertamento

… i i + 1 i + 2 i + 3 i + 4 …is

… … … … … … … …

j … X X X …

j + 1 … X X X …

j + 2 … X X …

j + 3 … X X …

j + 4 … X X X X X …

j + 5 … X X …

… … … … … … … …

L’offerta a MilanoA Milano è presente il servizio Sanità Milano, che permette di pre-notare telefonicamente tramite numero verde accertamenti ed esa-mi specialistici, presso alcune strutture sanitarie (Fatebenefratelli, Gaetano Pini, Istituti Clinici di Perfezionamento, Niguarda Ca’ Granda, Ospedale Maggiore di Milano Policlinico Mangiagalli e Regina Elena, Luigi Sacco, San Carlo, San Paolo, vedi Figura 5.2) e i poliambulatori collegati a queste strutture. Il servizio è rivol-to a qualsiasi cittadino iscritto al Sistema Sanitario Nazionale, in possesso della tessera sanitaria e della ricetta del medico. I tipi di accertamenti prenotabili tramite questo servizio sono più di mil-le. È presente inoltre un portale online che permette di consultare l’elenco degli accertamenti eseguibili (Figura 5.3) e di reperire le informazioni sulle strutture sanitarie che aderiscono al servizio.

Gli accertamenti che possono essere eseguiti hanno un codice, formato da due lettere che rappresentano il reparto (“CA” per un elettrocardiogramma, “RA” per le radiografie e le TAC, ecc.) e uno o più numeri separati da un punto.

Tabella 5.2Offerta nella zona di competenza del CUP: ogni colonna corrisponde a un tipo di accertamento diagnostico, mentre ogni riga definisce una istituzione

Figura 5.2Mappa di Milano in cui sono evidenziate le strutture che aderiscono a Sanità Milano [Sanità Milano, 2008]

A partire dalle informazioni contenute in Sanità Milano è possibile costruire una tabella come la Tabella 5.2, in cui per ogni ambula-torio di ogni azienda ospedaliera che aderisce al servizio è presente l’elenco di tutti gli accertamenti che possono essere prenotati (Ta-bella 5.3). Per ogni accertamento è indicato il codice e il nome; per ogni azienda ospedaliera è indicata anche la sede di erogazione, dal momento che, a parte l’azienda ospedaliera Niguarda Ca’ Granda e l’azienda ospedaliera San Paolo, tutte possono effettuare gli accer-tamenti in più di una sede e ognuna di queste offre servizi diversi rispetto alle altre. Per esempio, per quanto riguarda l’azienda ospe-daliera Polo Universitario Luigi Sacco, il poliambulatorio T. Pansi-ni può effettuare tutti i tipi di elettrocardiogramma indicati tranne quello a riposo (CA31_B), mentre quello di via Gola può effettuare solo elettrocardiogramma (CA31) e l’elettrocardiogramma dinami-co holter (CA30).

Azienda Ospedaliera Sede di erogazione

Prestazione

Azienda Ospedaliera - Polo Universitario Luigi Sacco

Ospedale Luigi Sacco (Poliambulatorio T. Pansini)

X X X X X X X X

Poliambulatorio P.le Accursio X X X X X

Poliambulatorio Via Baroni X

Poliambulatorio Via Gola X X

Poliambulatorio Via Novara X X X X X

Poliambulatorio Via Quarenghi X X X X X

Poliambulatorio Via Stromboli X X X X X

Figura 5.3Esempio di una

ricerca su http://www.sanitamilano.it/ [Sanità Milano,

2008] la prima colonna rappresenta il codice

dell’accertamento, seguito dal nome

dell’accertamento e dalla struttura (azienda

ospedaliera e sede di erogazione) in cui è effettuato; l’ultima

colonna definisce la disponibilità

dell’accertamento nella struttura

Tabella 5.3Esempio dell’offerta da parte del servizio Sanità Milano per quanto riguarda l’elettrocardiografia [Sanità Milano, 2008]

(Segue...)

Azienda Ospedaliera Fatebenefratelli e Oftalmico

Ospedale Fatebenefratelli e Oftalmico

Ospedale Macedonio Melloni X X X

Poliambulatorio Via Fantoli X

Poliambulatorio Via Fiamma X

Poliambulatorio Via Puecher X

Azienda Ospedaliera Istituti Clinici di Perfezionamento

Ospedale Niguarda X

P.O. Buzzi V. - Ospedale dei Bambini X

P.O. C.T.O. X X X

Poliambulatorio Via Don Orione X X X X X X

Poliambulatorio Via Doria X X X X X X

Poliambulatorio Via Farini X X

Poliambulatorio Via Inganni X X

Poliambulatorio Via Ippocrate X

Poliambulatorio Via Livigno X

Poliambulatorio Via Mangiagalli X X X X X X

Poliambulatorio Via Masaniello X X

Poliambulatorio Via Novara X

Poliambulatorio Via Rugabella X X X X X X

Azienda Ospedaliera Niguarda Cà Granda

Poliambulatorio Via Farini X

Azienda Ospedaliera Istituto Ortopedico Gaetano Pini

Sede di Piazza Cardinal Ferrari X X

Azienda Ospedaliera San Carlo Borromeo

Ospedale San Carlo Borromeo X X X

Poliambulatorio Via Inganni X X X

Poliambulatorio Via Masaniello X X X

Poliambulatorio Via Novara X

Azienda Ospedaliera San Paolo Ospedale San Paolo X X

Ospedale Maggiore Milano - Policlinico

Area Ospedaliera via Sforza - Commenda X X X

P.O. Commenda e Regina Elena X

Poliambulatorio Via Lamarmora X X

(Continua...)

L’offerta in alcuni paesi stranieriNel Regno Unito è presente un sistema che combina la prenota-zione elettronica e la scelta di luogo, data e ora per l’effettuazione di accertamenti dei pazienti. Questo sistema si chiama “Chooseand Book” ed è stato introdotto nell’estate del 2004 da parte del Na-tionalHealth Service (NHS, Servizio Sanitario Nazionale). Dall’1 gennaio 2006, tutti i pazienti in possesso della ricetta da parte del medico di base che necessitano di una visita specialistica possono scegliere tra almeno quattro diversi ospedali o ambulatori speciali-stici. I pazienti hanno a disposizione il sito internet del NHS e un call center telefonico e possono anche decidere di prenotare la visita specialistica direttamente tramite il medico generico.

In questo caso, oltre ai benefici per il paziente e per gli ospedali (la copertura del ChooseandBook è nazionale), il medico generico ha un ruolo importante nel consigliare al paziente il luogo dove effettuare l’accertamento e nell’aiutare il paziente stesso a prenotare [NHS, 2008] [Hendy et al., 2007].

La Danimarca ha preferito utilizzare un altro metodo per dimi-nuire le liste di attesa e rendere più accessibili i servizi ai pazienti: già dal 1993 è stata introdotta la libertà di scelta da parte del paziente, che può scegliere di essere curato gratuitamente anche al di fuori della propria regione di residenza; nel 2004 il 12% dei pazienti ha scelto di essere curato in una regione diversa da quella di residenza. Inol-tre dal 1999 il governo centrale ha introdotto il concetto di “unità funzionali” per particolari specialità, con l’intenzione di centralizzare l’attività ospedaliera: ogni unità specialistica serve una popolazione di 200.000-250.000 persone e tutte sono state create sia chiudendo dipartimenti piccoli, sia forzando la cooperazione tra dipartimenti di ospedali diversi.

Figura 5.4Ricetta da parte del medico di base per

un accertamento ecografico dell’apparato

urinario

Dal 2002 è stata introdotta la “scelta estesa” per ridurre le liste di attesa: questa viene effettuata se il sistema pubblico danese non è in grado di fornire al paziente il trattamento entro due mesi (un mese dall’1 gennaio 2007). La “scelta estesa” permette al paziente di esse-re curato in una struttura privata o all’estero (in strutture che hanno una convenzione con le autorità sanitarie danesi, 157 tra ospedali privati e ospedali stranieri) a spese della sua regione di residenza; nel 2004 65.000 pazienti hanno usufruito della “scelta estesa” [Vallgår-da et al., 2001].

5.1.2.2 La domandaIl paziente contatta il call center clinico per prenotare un accerta-mento diagnostico, in seguito alla prescrizione della ricetta da parte del medico (Figura 5.4). Al momento della richiesta del paziente, che avviene solitamente per telefono, l’operatore controlla che l’ac-certamento sia tra le offerte disponibili nella zona di competenza del CUP e, se è presente, propone al paziente la prima data disponibile in un’istituzione che effettua l’accertamento. Il paziente può accet-tare o può proporre di effettuare l’accertamento in un’altra istitu-zione, ad esempio perché è più vicina a casa o al luogo di lavoro, ha conoscenze o gli è stata consigliata. Una volta raggiunto l’accordo riguardo a data e luogo, l’operatore richiede al paziente i dati perso-nali, i dati identificativi del medico che ha emesso la ricetta (numero di matricola o nome e codice fiscale) e il numero della ricetta stessa. Tale numero è univoco, quindi può essere utilizzato per controlla-re la validità della prescrizione. Il paziente ottiene come ricevuta il codice di prenotazione, che viene inserito nell’agenda dell’impianto dell’istituzione che effettuerà l’esame (Figura 5.5).

operatore

proposta di appuntamento

verifica disponibilitàrichiesta

istituzionipaziente

prima data e luogo disponibile

conferma blocca lo slot relativo

ricevuta della prenotazione (codice prenotazione)

verifica disponibilitànon conferma

prima data e luogo disponibile

conferma blocca lo slot relativo

ricevuta della prenotazione (codice prenotazione)

agenteimpianti

Figura 5.5UML sequence diagram per una singola prenotazione di un accertamento clinico tramite il CUP. In questo caso Il paziente, che è in possesso della ricetta prescritta dal proprio medico curante o da uno specialista, contatta il call center clinico per richiedere la prenotazione dell’accertamento o di più accertamenti nello stesso momento, nel caso che la ricetta contenga la richiesta per l’effettuazione di più accertamenti. L’operatore del call center controlla se l’accertamento fa parte di quelli eseguibili: se è compreso, allora ricerca la prima data disponibile nell’agenda degli impianti che offrono tale accertamento. Propone così una data al paziente; se questo non ha altre richieste, la ricevuta della prenotazione viene rilasciata al paziente

richiesta

istituzionei

istituzionei + 1

istituzionei + 2

paziente

confermaricevuta della prenotazione

proposta di appuntamentoconferma

ricevuta della prenotazione

non conferma

agenteimpianti

Figura 5.6UML sequence diagram per la prenotazione di

un accertamento clinico senza la presenza di un

CUP. Il paziente deve contattare le singole

strutture sanitarie e procedere alla

prenotazione. Se non è soddisfatto della data,

il paziente contatta un’altra struttura, e

così via, fino a quando non trova una soluzione

a lui adeguata

Figura 5.7Modulo di prenotazione

per ecografia dell’apparato urinario: presso questa azienda ospedaliera (i cui dati

sono nell’intestazione), la prima parte del

modulo contiene i dati del paziente e il numero

della prenotazione (1); la seconda parte

contiene le informazioni sulla data e sul luogo

di effettuazione dell’accertamento (2); la terza parte descrive l’accertamento che il

paziente deve eseguire, con tutte le indicazioni per la preparazione del paziente all’esame (3). L’ultima parte contiene eventuali note da parte

dell’operatore (4).

Invece, se il CUP non è presente, il paziente deve contattare le varie istituzioni singolarmente, fino a quando non ne trova una che gli propone una data di suo gradimento (Figura 5.6).

Sia in presenza di un CUP, sia quando si effettua la richiesta per un accertamento direttamente a un’istituzione, la ricevuta di avve-nuta prenotazione è in modulo cartaceo e contiene, oltre all’indi-cazione di data e luogo dell’appuntamento, anche tutte le infor-mazioni relative al paziente, all’accertamento che deve effettuare e all’istituzione (Figura 5.7 e Figura 5.8).

5.1.3 Il CUP

5.1.3.1 ArchitetturaLe diverse istituzioni sanitarie che aderiscono al CUP possiedono determinati impianti, diversi per ogni istituzione; per esempio un ospedale può contenere apparecchiature radiologiche, TAC e riso-nanze magnetiche, mentre gli ambulatori sono di solito specializ-zati, quindi contengono solo impianti specifici (un ambulatorio di cardiologia possiede apparecchiature per l’analisi del sangue e elet-trocardiografi, mentre un ambulatorio di ortopedia possiede appa-recchiature radiologiche e risonanza magnetica).

In generale, ogni istituzione ha un’offerta limitata di accertamen-ti in base agli impianti di cui dispone e, all’interno della zona di competenza del CUP, sarà presente un’offerta limitata di accerta-menti che i pazienti potranno prenotare rispetto a tutti gli accerta-menti utili che sono descritti nei dizionari clinici (Figura 5.9).

Figura 5.8Modulo di prenotazione per un accertamento specialistico ortopedico: presso questa istituzione la prima parte del modulo contiene i dati del paziente, della prenotazione e della data e luogo dell’accertamento; la seconda parte contiene le indicazioni sulla documentazione che il paziente dovrà presentare al momento dell’accertamento e le indicazioni per presentare disdette o richiedere informazioni aggiuntive

accertamentiutili

IMPIANTISTICACLINICA

accertamentieseguibili

Figura 5.9Per conoscere la gli accertamenti eseguibili nella zona di competenza del CUP, bisogna operare un filtraggio degli accertamenti utili definiti dai dizionari clinici con l’impiantistica disponibile. Da questo filtraggio si ottengono gli accertamenti eseguibili

5.1.3.2 Definizione degli agenti che interagiscono con il CUPIl paziente può prenotare gli accertamenti di cui necessita tramite il call center clinico (Figura 5.10); una volta che sono definiti data e luogo dell’accertamento, la prenotazione viene ufficializzata e, a questo punto, nell’agenda dell’impianto viene inserito il codice di prenotazione relativo alla ricetta, che servirà al paziente per effettua-re l’accertamento. Il codice di prenotazione dipende dalla ricetta, quindi a ogni ricetta possono corrispondere più accertamenti diver-si, ma tutti hanno lo stesso codice di prenotazione.L’agenda degli impianti è strutturata in modo da:• prevedere per alcuni accertamenti più di un paziente allo stes-

so orario;• ottimizzare i tempi in cui non è necessario agire direttamente

sul paziente, come nel caso di un accertamento urografico, in cui si può iniziare l’accertamento su un paziente mentre un altro è in attesa di effettuare la radiografia di controllo, dopo che gli è stato iniettato il liquido di contrasto;

• avere un limite temporale definito: possono essere prenotati accertamenti entro la data di scadenza della ricetta; se entro questo periodo l’impianto non è disponibile, l’accertamento va ricercato in un altro impianto e, se nessuno è disponibile, il CUP non può soddisfare la richiesta del paziente.

Ogni accertamento può essere diviso in tre fasi: preparazione, esecu-zione e refertazione. Di solito più di un attore agisce su queste tre fasi: le prime due possono essere effettuate da un medico o da un tecnico (per esempio una radiografia viene di solito effettuata da un tecnico, mentre un prelievo di sangue viene di solito effettuato da un medico). In ogni caso è un medico che compila e firma il referto.

Il paziente viene individuato tramite il codice di prenotazione e il codice sanitario, che potrebbe coincidere con il codice fiscale, supposto univoco.

accertamentirichiestipaziente

agendaimpianto

operatore callcenter clinico

operatoremedico/tecnico

definiscono

necessita

emette

effettua accertamenti eseguibili

prenotazionefinale

Figura 5.10Schema delle procedure

che un paziente deve effettuare

per prenotare un accertamento tramite

il CUP

5.1.3.3 Progettazione concettualeDal precedente schema si può definire un diagramma entità-rela-zioni che spieghi la struttura del CUP (Figura 5.11, seguita dalla descrizione di tutte le entità e relazioni, Tabella 5.4 e Tabella 5.5), in termini di informazioni che è necessario conoscere per ogni attore che interagisce con il CUP e come questi attori interagiscono.

numero serienome

proprietàlocalizzazione

codice

disponibilità agenda

occupazione

prenotazione

pazienterichiestaaccertamenti richiesti

operatorecall center

accertamentieseguibili

partecipazionemedico

partecipazionetecnico

tecnico

medico

accertamenti utili

verificadisponibilità

impiantisticaclinica

nomelocalizzazione

medico prescrittore

codice ricetta

relazione

1,N1,N

1,Ncodice

codice

i,j cardinalità

attributoentità

nomedescrizionecampo

codiceora inizioora finegiornomeseannocodiceprenotazione

codice fiscalenomecognomesessoviaCAPcittàtelefonocellulareE-mail

0,N1,N1,N

codice

Figura 5.11Diagramma ER della struttura del CUP

l filt

n l’

dell’

e l’

all’

l’os

i al C

’ent

e l’

gia…

e l’

dell’

ll’ag

l’ef

dell’

ll’im

dell’

ll’in

ll’os

i un’

ata…

ll’ef

dell’

ll’in

a l’

re l’

ell’

l’ef

dell’

Tabella 5.4Descrizione delle entità

l filt

n l’

dell’

e l’

all’

l’os

i al C

’ent

e l’

gia…

e l’

dell’

ll’ag

l’ef

dell’

ll’im

dell’

ll’in

ll’os

i un’

ata…

ll’ef

dell’

ll’in

a l’

re l’

ell’

l’ef

dell’

ilità

dell’

ll’ag

N l’

dell’

ell’

N l’

lla la

l’ac

l’es

ll’op

l’ac

l’es

ilità

n l’

l’im

Tabella 5.5Descrizione delle relazioni

5.1.3.4 Progettazione logicaUna volta definite tutte le entità e relazioni che concorrono a forma-re la struttura del sistema CUP, si può procedere alla progettazione logica, quindi a definire tutte le tabelle che dovranno essere create perché questo sistema funzioni veramente. Si procede alla progetta-zione logica per tradurre il diagramma ER in un sistema che rappre-senti i dati in modo efficiente.

La ristrutturazione del diagramma ER avviene in quattro punti:1. analisi delle ridondanze;2. eliminazione delle generalizzazioni;3. riarrangiamento di entità e relazioni;4. scelta delle chiavi primarie.Una ridondanza è un’informazione che può essere ricavata da altre: è necessario decidere se mantenere le ridondanze del diagramma ER o eliminarle. Da un lato, le ridondanze possono semplificare le interrogazioni sulla base di dati, ma, d’altro canto, sono informazio-ni superflue, quindi aumentano il carico computazionale: bisogna quindi trovare un compromesso. Nel nostro caso, viene mantenuto il ciclo tra accertamentieseguibili, agenda e prenotazione, per ottenere una lettura più chiara, dal momento che non appesantisce il carico di informazioni contenute nello schema.

Le generalizzazioni sono attributi particolari e non possono esse-re rappresentate direttamente nello schema logico e vanno quindi sostituite con entità e relazioni. Nel nostro caso non sono presenti generalizzazioni.

Il terzo passo consiste nel partizionamento e accorpamento di entità e relazioni per rendere più efficienti le operazioni di accesso e estrazione delle informazioni dalla base di dati: in questo modo si definiscono le tabelle che compongono la base di dati. In segui-to a questa operazione è possibile definire gli identificatori primari di queste tabelle. Per quanto riguarda il CUP, vengono definite le seguenti tabelle (gli attributi sono tra parentesi e gli identificatori primari sono sottolineati):

Entità: • accertamenti eseguibili (nome, localizzazione)• accertamenti richiesti (codice fiscale paziente, medico pre-

scrittore, codice ricetta)• accertamenti utili (nome, descrizione, campo)• agenda (codice, orario inizio, orario fine, giorno, mese, anno,

codice prenotazione)• impiantistica clinica (nome, numero serie, localizzazione,

proprietà)• medico (nome, codice)

• paziente (codice fiscale, nome, cognome, sesso, via, CAP, cit-tà, telefono, cellulare, e-mail)

• prenotazione (codice, codice operatore, nome accertamento eseguibile, codice ricetta)

• tecnico (nome, codice)Relazioni:• disponibilitÀ (codice agenda, orario inizio, orario fine, gior-

no, mese, anno, codice prenotazione, nome accertamento)• occupazione (orario inizio, orario fine, giorno, mese, anno,

codice prenotazione)• operatore del call center (codice)• partecipazione medico (tipo, codice medico, nome accer-

tamento)• partecipazione tecnico (tipo, codice tecnico, nome accer-

tamento)• verifica disponibilitÀ (numero serie impianto, nome accer-

tamento utile, nome accertamento eseguibile).Una volta che tutte queste tabelle sono definite, è possibile riempire la base di dati e cioè costruire il livello dei dati e delle funzioni per il servizio CUP.

5.1.3.5 Strumenti di implementazioneDefinendo queste tabelle, il software che sta alla base del CUP può aiutare l’operatore del call center clinico a semplificare le prenota-zioni di accertamenti clinici sia per il paziente, che non dovrà più contattare personalmente le diverse strutture per cercare le condi-zioni migliori per prenotare l’accertamento, sia per le istituzioni, dal momento che la probabilità che un paziente non si presenti all’ac-certamento saranno molto diminuite. In questo modo i tempi mor-ti per le istituzioni saranno quasi nulli e le liste di attesa più brevi, in quanto un accertamento verrà ricercato, tramite il CUP, in tutte le istituzioni della sua zona di competenza.

La base di dati progettata può essere implementata con diversi Database Management Systems (DBMS), come Microsoft Access, Oracle 9, MS-SQL Server 2005 o MySQL. Ogni istituzione sanita-ria possiede un proprio database, in cui sono contenuti tutti i dati necessari a gestire le prenotazioni di tutti gli accertamenti clinici eseguiti e tutte le agende degli impianti contenuti al suo interno: ogni istituzione possiede un suo CUP già affermato e funzionante; non solo, ogni istituzione può utilizzare un DBMS diverso.

La creazione di un CUP che comprende più istituzioni su un territorio definito potrebbe portare a due soluzioni differenti, per quanto riguarda la gestione dei dati:

1. la più semplice comporta la creazione di un database del CUP, che contiene tutti i dati relativi a tutti i pazienti, le istituzioni e le agende degli impianti appartenenti alla sua zona di com-petenza (Figura 5.12);

2. la seconda comporta l’integrazione, da parte del CUP, di tut-te le agende degli impianti delle singole istituzioni, in modo da fornire all’operatore l’elenco della disponibilità di ogni im-pianto di ogni istituzione nella zona di competenza del CUP in base alle richieste del paziente (Figura 5.13).

operatore del call center

istituzionei + 1

DATABASE

istituzionei

istituzionei + 2

integratore delle agende (middleware)

operatore del call center

applicazioneCUP

istituzionei + 1

SQL server2005

DATABASE

istituzionei

istituzionei + 2

oracle 9i

DATABASE

Figura 5.12Prima soluzione: un

DBMS del CUP per tutte le istituzioni

Figura 5.13Seconda soluzione: ogni

istituzione ha il suo DMBS, tutte le agende

degli impianti vengono integrate

per permettere all’operatore del CUP

di interagire con il paziente

La prima soluzione comporta un maggiore spreco di tempo e risor-se, quindi è meno conveniente, anche se è più semplice da un pun-to di vista implementativo: è necessario utilizzare un unico DBMS con cui definire i database di ogni istituzione. La seconda soluzione comporta l’implementazione di un integratore in grado di leggere i dati di tutti i DBMS delle singole istituzioni, per poi fornire all’ope-ratore le informazioni di cui necessita per interagire con il paziente.

5.1.4 Conclusioni

L’obiettivo principale per la creazione di un Centro Unico di Pre-notazione che comprenda tutte le istituzioni sanitarie all’interno di un’area geografica ben definita è di aiutare sia i pazienti, sia le isti-tuzioni sanitarie. Il paziente necessita di effettuare un accertamento clinico in tempi brevi e l’istituzione ha bisogno di ottimizzare il grado di utilizzo degli impianti che possiede. In questo modo, è fortemente raccomandato l’aiuto di un call center che permetta al paziente di scegliere il luogo e il tempo per l’effettuazione dell’ac-certamento tra tutte le possibilità. Dall’altra parte, le istituzioni sa-nitarie possono beneficiare dell’aiuto del call center, dal momento che questo permette loro di ottimizzare l’agenda degli impianti, diminuendo i tempi morti. Inoltre il paziente non deve più contat-tare personalmente tutte le istituzioni sanitarie per scegliere l’offerta migliore, ma il call center lo aiuta direttamente.

Un possibile sviluppo del Centro Unico di Prenotazione potreb-be includere la gestione dei pagamenti e delle convenzioni da parte dei pazienti; inoltre il CUP dovrebbe tenere conto anche delle di-sdette da parte dei pazienti, quindi l’operatore del call center clinico deve essere in grado anche di eliminare i dati di una prenotazione e poterli reinserire in un’altra data/istituzione.

5.2 Registrazione elettronica dei nuovi farmaci (PharmaReg)

5.2.1 Ricerca e sviluppo per un nuovo farmaco

Il concetto di qualità è ormai affermato come una delle maggiori necessità e, quindi, contemporaneamente come l’elemento irrinun-ciabile che un prodotto ed un produttore devono esibire per potersi affermare. Nell’industria farmaceutica la qualità è da sempre con-siderata fondamentale di una corretta politica di produzione per le particolari caratteristiche del prodotto stesso, soggetto ad una legi-slazione molto rigida ma soprattutto ad un utilizzo molto impor-tante per la salute e per il benessere dei cittadini.

Un farmaco è un qualsiasi prodotto che possa curare, prevenire o diagnosticare una malattia e la cui immissione in commercio sia stata autorizzata dalle Autorità Regolatorie.

Le aspettative del pubblico sono rivolte a che i farmaci offerti sul mercato siano efficaci e sicuri e che la loro qualità sia eccellente. È altrettanto importante che nuovi farmaci diventino disponibili entro un tempo il più breve possibile, pertanto l’applicazione delle cosiddette “Buone Pratiche” (Good Engineering Practices, Good Manufacturing Practices, Good Laboratory Practices, Good Clini-cal Practices, Good Distribution Practices) dispone ormai di uno storico ben consolidato.

In particolare con l’espressione Buona Prassi di Fabbricazione (GMP, dall’inglese Good Manufacturing Practice) ci si riferisce ad un sistema di norme volte ad assicurare che i farmaci siano pro-dotti in modo coerente e controllato per garantire precisi standard di qualità e minimizzarne i rischi legati alla produzione secondo protocolli dettagliati, nonché sistemi che documentino la corretta applicazione delle procedure in ogni singola fase della produzione. La buona prassi di fabbricazione comprende tutti gli aspetti della produzione, dalle materie prime alle officine di produzione, le at-trezzature utilizzate, la formazione del personale, il confezionamen-to, l’igiene del personale addetto ecc.

La Buona Pratica Clinica (GCP, dall’inglese Good Clinical Prac-tice) si riferisce invece ad uno standard scientifico ed etico inter-nazionale per la progettazione, conduzione, registrazione dei dati e pubblicazione delle sperimentazioni con esseri umani, al fine di assicurare la tutela dei diritti, la sicurezza e il benessere dei soggetti che partecipano alla sperimentazione in base ai principi già sanciti dalla Dichiarazione di Helsinki [WMA, 1964].

La Buona Prassi di Laboratorio (GLP, dall’inglese Good Labora-

tory Practice) stabilisce una serie di norme e criteri per promuovere la qualità e la validità dell’elaborazione ed analisi dei dati provenien-ti dagli studi di laboratorio (non-clinici) [Fuccella e Frascio, 1995].

Con il continuo aumentare della competizione nel mercato far-maceutico è abbastanza facile comprendere come l’aumento di effi-cienza ed efficacia non solo dei processi produttivi di fabbricazione, di prova in laboratorio e di distribuzione di un farmaco, ma anche della redazione di un dossier per la registrazione di un nuovo far-maco che sia rapida, utile, di facile condivisione a livello non solo internazionale ma mondiale, sia fondamentale.

Riassumendo si può affermare che un nuovo farmaco debba esse-re uno strumento vantaggioso in termini di:• Efficacia• Sicurezza• UtilitàL’efficacia viene intesa come il grado di raggiungimento degli obiet-tivi terapeutici prefissati da parte del farmaco, la sicurezza come la certezza di assenza di effetti dannosi che possono derivare dall’uso di un farmaco mentre l’utilità si riflette nell’adeguatezza a soddisfare una necessità terapeutica e ad avere un favorevole rapporto rischio/beneficio.

5.2.1.1 Il processo di ricerca e sviluppo Per poter produrre un medicinale si parte da migliaia di molecole, che vengono inesorabilmente decimate dai test preliminari di labo-ratorio. Le poche che superano gli esami affrontano le prove succes-sive, sempre più complesse, alla fine delle quali sopravvive una sola molecola, quella che sarà poi il principio attivo del farmaco, adatto all’impiego sull’uomo.

Figura 5.14I processi di ricerca e sviluppo del farmaco[NIAID, 2005]

Drug Development Process

drug discovery

/basic

research

combinatorial/natural product libraries

preclinical toxicology,

pharmacokinetics & metabolism

information system / computer technology

biotechnology

bioanalytical chemistry technology

enabling technologies

clinical trialspreclinicaldiscovery

clinical researchsafety & metabolism

clinical lab technology

survey technology

drug substance manufacture

post marketing

surveillance

phaseIV

phaseIII

phaseII

phaseI

pharmacology & Exploratory

toxicology

modelling, screening &

characterization

lead enhancement

La Figura 5.14 illustra le fasi dell’intero processo di ricerca e svi-luppo di un nuovo farmaco, specificando, gli scopi e le tecnologie utilizzate che ciascuna fase richiede [NIAID, 2005].

Si possono identificare le seguenti fasi principali:1. La ricerca di base2. Lo sviluppo preclinico3. Lo sviluppo clinico (diviso in I, II, III fase)4. La IV fase.

1. La ricerca di baseLa ricerca di base ha lo scopo di identificare le molecole che fun-gono da candidati migliori per diventare principio attivo del nuovo farmaco. Una molecola può “nascere” in diversi modi. In genere l’idea originatrice deriva da una necessità terapeutica, ovvero dalla mancanza di un adeguato strumento terapeutico per il trattamento di un determinato stato patologico.

Tradizionalmente il principio attivo veniva identificato ispirandosi a molecole prodotte da specie animali o vegetali dotate di proprietà terapeutiche o a farmaci esistenti poco efficaci e sicuri, oppure ancora osservando effetti collaterali di altri farmaci, o infine per evento for-tuito. Questo procedimento, oltre ad essere poco mirato e selettivo in termini di bersaglio biologico, richiede generalmente tempi molto lunghi per produrre un composto (sottoposto a brevetto) che dovrà successivamente essere ottimizzato per efficacia e sicurezza.

Per accelerare il periodo di identificazione delle molecole con po-tenziale attività terapeutica e quindi rispondere nel più breve tempo possibile alla richiesta di salute pubblica, le aziende farmaceutiche si sono dotate di strutture informatizzate che accelerano compiti che un tempo erano svolti dall’uomo. Si tratta di tecniche di automa-zione, grandi sistemi robotizzati che eseguono screeningfarmacolo-gico, ovvero saggi biologici in vitro su migliaia di campioni in poco tempo. Per esempio, grazie all’impiego di “biblioteche” di molecole automatizzate, nei laboratori alcuni robot sono in grado di verifica-re l’azione di circa 60.000 composti su specifici bersagli biologici, nell’arco di un solo giorno. Dopo aver identificato alcuni potenziali principi attivi, un altro sistema computerizzato si occupa di svilup-pare un numero elevato di varianti chimiche, per trovare quella più efficace, in pochissimo tempo.

Inoltre una buona ricerca privilegia, anziché l’approccio bruteforce, che consiste nel saggiare indiscriminatamente milioni di com-posti, una selezione razionalizzata degli stessi sulla base delle carat-teristiche del sistema biologico bersaglio.

Questa fase di ricerca di base dura anche 3-5 anni, e rappresenta

circa il 10% dell’investimento totale. Essendo obiettivo di questa fase verificare in laboratorio il maggior numero possibile di carat-teristiche positive e negative dei composti, la sua durata è andata allungandosi nel tempo, fino a raggiungere a volte anche gli 8-10 anni [Harman, 2002].

2. Lo sviluppo preclinico del farmacoDopo l’identificazione di una ridotta parte di molecole provenienti dalla Ricerca di base che hanno mostrato attività biologica di rilievo sul bersaglio considerato, vengono intraprese lunghe e complesse indagini e sperimentazioni chimico-biologiche per determinarne:• la selettivitàdiazione (quindi la riduzione di effetti collaterali),

ovvero la capacità di agire su determinati sistemi bersaglio sen-za influire sul funzionamento di sistemi simili;

• la biodisponibilità, ovvero la velocità con cui il farmaco rag-giunge la circolazione e in che quantità;

• la tossicità, ovvero la capacità di produrre effetti dannosi all’or-ganismo vivente, con la sua somministrazione;

• il comportamentometabolico, ovvero in quali modi il farmaco si trasforma in sostanze chimiche differenti per effetto dei siste-mi enzimatici presenti nell’organismo.

In pratica un principio attivo deve possedere una via di sommini-strazione accettabile, essere assorbito una volta somministrato, saper raggiungere i suoi bersagli, esplicare la sua azione e venire eliminato: il tutto, ovviamente, senza essere tossico. Gli studi sulla stabilità chimica del composto e altri studi tecnici si effettuano per mettere a punto la formulazione migliore e il dosaggio per iniziare la successi-va fase di sperimentazione sull’uomo.

In questa fase di sviluppo preclinico gli esperimenti sono condot-ti invivo sugli animali da laboratorio, riproducendo in essi la ma-lattia per cui il farmaco deve essere sintetizzato. Lo scopo primario è innanzitutto determinare se il prodotto è sufficientemente sicuro per un iniziale impiego sull’uomo.

Al terminare di queste ricerche, quando ormai pochi composti sono stati selezionati per un futuro sviluppo, l’azienda farmaceutica raccoglie i dati e le informazioni necessarie a dimostrare che il pro-dotto non esporrà l’uomo a rischi se usato in maniera limitata du-rante i successivi studi clinici. L’azienda farmaceutica inoltra all’Au-torità Regolatoria un iniziale dossier per richiedere l’autorizzazione a procedere alle successive sperimentazioni sull’uomo.

Questo dossier contiene dati e informazioni in tre principali aree:I. Studifarmacologicietossicologici condotti sugli animali: i dati

preclinici permettono di valutare se il farmaco è ragionevol-

mente sicuro per iniziare i test sull’uomo.II.Informazionisullaproduzione: sono informazioni pertinenti a

composizione, produttore, stabilità e controlli usati nella pro-duzione del principio attivo e del farmaco. Queste informa-zioni servono per assicurare che l’azienda possa adeguatamente produrre e fornire costanti quantità di prodotto.

III.Protocolliclinicieinformazionisuiricercatori: sono descritti dettagliatamente i protocolli che saranno usati per gli studi clinici proposti, ovvero i piani per la conduzione di ogni tappa di un trattamento, al fine di dimostrare che gli iniziali test non sottoporranno i soggetti a rischi. Inoltre sono fornite informa-zioni circa le qualifiche dei ricercatori clinici che visioneranno l’esecuzione degli esperimenti successivi.

In genere l’azienda farmaceutica, prima di presentare la documenta-zione necessaria, provvede subito a brevettare la molecola.

La durata degli studi preclinici è di circa 2 anni (si può esten-dere anche fino a 5 anni) e al termine di essi meno del 50% delle molecole provate passa alla sperimentazione sull’uomo avendo di-mostrato di avere un potenziale terapeutico insieme ad una tossicità accettabile. Lo sviluppo preclinico costituisce circa il 30% dell’in-vestimento totale.

3. Lo sviluppo clinico del farmacoLo sviluppo clinico è lo stadio più complesso, lungo ed oneroso (da solo costituisce il 60% dell’investimento totale) di tutto il processo sperimentale.

Con il termine sperimentazione clinica si intende ogni studio su soggetti umani inteso a verificare gli effetti clinici, farmacologici e farmacodinamici di un prodotto; a identificarne ogni reazione av-versa e a studiarne l’assorbimento, la distribuzione, il metabolismo e l’eliminazione, con l’obiettivo di valutarne sicurezza ed efficacia.

Non è sempre facile tracciare divisioni nette fra le diverse fasi della sperimentazione clinica, dato che a seconda del prodotto esa-minato, e della metodologia di studio alcune fasi si possono sovrap-porre. Tipicamente, la sperimentazione avviene in 4 fasi, al termine di ognuna di esse i risultati determineranno se il farmaco sarà adatto ad entrare nelle fasi successive o se invece la sperimentazione verrà interrotta.

FaseI-StudiopreliminaresullasicurezzaesullamodalitàdiazioneLo scopo principale di questa prima fase non è quello di valutare l’efficacia del nuovo farmaco, ma quello di dare una prima valuta-zione sulla sua sicurezza e allo stesso tempo di determinare quel-

lo che accade al farmaco nel corpo umano (studio della cinetica): come viene assorbito, metabolizzato ed escreto.

Lo studio è effettuato in generale su un piccolo numero di vo-lontari sani.

La fase I può anche servire ad evidenziare eventuali effetti indesi-derati della sostanza in funzione del dosaggio.

Per passare alle fasi successive un farmaco deve dimostrare di non essere tossico, o perlomeno di avere una tossicità accettabile rispetto all’uso previsto.

FaseII-StuditerapeuticipilotaLo scopo principale è quello di valutare l’efficacia del farmaco (ad un preciso dosaggio e con una definita posologia) in un ristretto numero di pazienti affetti dalla malattia o dalla condizione clinica per la quale il farmaco è proposto.

FaseIII-StuditerapeuticisupiùlargascalaSe la fase II fornisce risultati incoraggianti la fase III coinvolge un numero più ampio di pazienti al fine di approfondire i dati di ef-ficacia, di valutare il dosaggio più opportuno e di monitorare gli eventuali effetti collaterali su un campione statisticamente più si-gnificativo.

Per la maggior parte, gli studi di fase III sono di tipo randomiz-zato e in doppio cieco e la loro durata è variabile a seconda degli obbiettivi che la sperimentazione stessa si pone. Durante questa fase viene sempre controllata con molta attenzione la tollerabilità (insor-genza di effetti indesiderati e/o collaterali) del farmaco.

I farmaci che passano con successo la fase III della sperimentazio-ne ottengono l’autorizzazione per la commercializzazione.

4. La quarta faseFaseIV-DopolacommercializzazioneAnche quando un farmaco viene venduto ed utilizzato da migliaia di persone in uno o più paesi gli studi clinici continuano con la fase IV. Gli studi di fase IV sono volti a confermare la sicurezza e la tollerabilità a lungo termine del farmaco, su un ampio numero di pazienti. I dati che si ottengono sono statisticamente importanti, dato che coinvolgono un gran numero di utilizzatori, spesso diversi per età, razza, sesso etc.

5.2.1.2 La sperimentazione clinica dei farmaciPrima di poter essere messi in commercio tutti i nuovi farmaci de-vono superare una lunga fase di sperimentazione. In generale si par-

la di sperimentazione clinica di un farmaco quando si vuole valutare l’efficacia e/o la tollerabilità e/o la sicurezza di un trattamento far-macologico sull’uomo basandosi sul confronto dei risultati ottenuti su due gruppi di pazienti con caratteristiche e modalità di prova differenti in base al confronto che si vuole effettuare.

La sperimentazione clinica comporta un iter lungo e costoso, le cui diverse fasi sono descritte e stabilite dalla legge, in modo da garantire procedure etiche in grado di minimizzare i rischi per i pazienti.

Per indicare le sperimentazioni cliniche si usa spesso il termine inglese clinicaltrias[Pitt et al, 2000].

Le figure usualmente coinvolte nella conduzione delle attività, che la buona pratica clinica, o Good Clinical Practice (GCP), preve-de che siano svolte nell’ambito della sperimentazione clinica, sono:• Il Promotore o Sponsor• Lo Sperimentatore• Il Monitor• Il Soggetto dello studioÈ importante sottolineare che una corretta gestione dello studio clinico può essere raggiunta solo attraverso un’appropriata imposta-zione dei rapporti fra le suddette parti, in relazione a quelli che sono i ruoli e le responsabilità di competenza nell’ambito dello studio [Beckman, 1997].

Il Promotore della sperimentazione clinica o Sponsor, secondo le definizioni del Decreto Ministeriale del 15/7/97 [DM, 15 lu-glio 2007] e del Decreto legislativo n.211/2003 [DL, 2003], è una persona, società, istituzione oppure un organismo che “si assume la responsabilità di avviare, gestire e/o finanziare una sperimenta-zione clinica”. Nonostante le università e le associazioni o società scientifiche possano essere inglobate nella definizione di promotore di uno studio clinico, generalmente gli Sponsor degli studi clinici sono quasi sempre le industrie farmaceutiche interessate a sviluppa-re nuovi farmaci in vista della loro commercializzazione. Una parte minore di studi clinici è invece finanziato da organismi di ricerca pubblici. In particolare uno studio è detto multicentrico quando coinvolge più istituti o centri di ricerca.

Le responsabilità del promotore riguardano sia gli aspetti orga-nizzativi sia quelli scientifici interessando in particolare la pianifica-zione dello studio, la gestione dello studio e della documentazione, gli aspetti etici, regolatori e assicurativi, la sicurezza del prodotto in studio, la qualità e la conformità dello studio stesso.

Lo sperimentatore è definito, in accordo con il Decreto legislativo n.211/2003 [DL, 2003], come “un medico o un odontoiatra quali-

ficato ai fini delle sperimentazioni, responsabile dell’esecuzione del-la sperimentazione clinica in un dato centro. Se la sperimentazione è svolta da un gruppo di persone nello stesso centro, lo sperimenta-tore responsabile del gruppo è definito sperimentatore principale”.

Dal momento in cui lo Sperimentatore accetta di partecipare allo studio deve provvedere, con la collaborazione dello Sponsor cioè del promotore della ricerca, ad ottenere tutte le necessarie autorizzazio-ni e la documentazione richiesta. È opportuno che tutte le proce-dure amministrative siano soddisfatte prima dell’arruolamento dei soggetti in modo da non determinare l’esclusione di questi dalle valutazioni finali dello studio.

In questo lavoro lo Sponsor si avvale della figura del Monitor. Il Monitor, come definito nelle norme di Buona Pratica Clinica, è la persona designata a sorvegliare lo studio e a riferire allo Sponsor o alla Organizzazione di Ricerca a Contratto (CRO) sullo stato di avanzamento dello studio e a verificare i dati.

In base al tipo di studi, allo stadio di sviluppo del prodotto e alle caratteristiche anche logistiche del centro sperimentatore, la docu-mentazione da ottenere per poter avviare la ricerca può variare.

Le verifiche che il monitor deve effettuare presso il centro riguar-dano i seguenti principali aspetti della sperimentazione:• conduzione dello studio da parte dello sperimentatore e del

suo staff;• gestione del farmaco in studio presso il centro;• gestione del File dello sperimentatore;• modalità della segnalazione degli eventi avversi (EA) e delle

reazioni avverse al farmaco (ADR).È fuori di dubbio che nessuna ricerca clinica, di tipo terapeutico e non, per quanto ben progettata e organizzata, possa essere intra-presa senza l’adesione alla stessa di individui identificati come sog-getto dello studio: soggetti non solo per la dignità che deve essere riconosciuta a qualsiasi essere umano ma anche in quanto essi stessi protagonisti della ricerca clinica. La normativa di riferimento sulla sperimentazione clinica definisce soggettodella sperimentazione “la persona che partecipa ad una sperimentazione clinica, sia come de-stinataria del medicinale in sperimentazione sia come controllo”. Tale definizione si applica sia ai pazienti che ai volontari (sani e/o malati) [Tomino, 2004].

Secondo i principi enunciati nella Dichiarazione di Helsinki e nelle successive revisioni, che costituiscono il testo etico di riferi-mento del ricercatore biomedico, lo Sperimentatoreha l’obbligo e la responsabilità di ottenere, prima del coinvolgimento di un sog-getto in una sperimentazione clinica, il consensoinformato di questi.

Il consenso informato è “l’assenso volontario di un soggetto a partecipare ad uno studio e la relativa documentazione. Tale assenso dovrebbe essere richiesto solo dopo aver fornito informazioni sullo studio che includano i suoi obbiettivi, i potenziali benefici, rischi e inconvenienti, nonché i diritti e le responsabilità del soggetto in accordo con l’ultima revisione della dichiarazione di Helsinki”.

Come si evince da questa breve panoramica i soggetti coinvolti direttamente nella sperimentazione clinica sono vari e molteplici, con l’integrazione di figure professionali eterogenee tra loro.

Se passiamo ad analizzare le figure coinvolte nella sperimentazio-ne clinica ad un livello superiore scopriamo che essa è posta sotto il controllo delle autorità sanitarie pubbliche (Istituto Superiore di Sanità, Ministero della Sanità, Comitati Etici regionali, Comitati Etici locali) e regolamentata da leggi precise.

Per quanto riguarda i paesi dell’UE, dal 1995 esiste una struttu-ra centralizzata (EMEA – European Agency for the Evaluation of Medicinal Products [EMEA, 1995]) che ha lo scopo di coordinare e armonizzare le procedure in tutti i paesi dell’Unione Europea. Negli Stati Uniti l’autorità competente è la Food And Drug Administra-tion [U.S. FDA, 2001].

In Italia gli organismi coinvolti nel processo di autorizzazione di una sperimentazione clinica sono il Ministero della Sanità, l’Istituto Superiore di Sanità e i Comitati Etici.

I Comitati Etici sono commissioni autonome di esperti che ven-gono istituite all’interno di Ospedali e centri di ricerca, iscritte in un apposito registro del Ministero della Sanità. Ogni commissione può autorizzare la sperimentazione all’interno del proprio ospedale, istituto o centro di ricerca.

La prima autorizzazione, indispensabile per iniziare la sperimen-tazione, è il cosiddetto Giudizio di Notorietà. Il Giudizio di Noto-rietà esprime parere relativamente all’utilizzo di un principio attivo (dose, formulazione, frequenza ) in una certa patologia o condizio-ne clinica.

Il Giudizio di Notorietà è necessario per tutti gli studi clinici dalla fase I alla fase III. In particolare il Giudizio di Notorietà per gli studi di fase II e, III deve essere richiesto ai Comitati Etici au-torizzati, mentre per la fase I (prima somministrazione del farmaco nell’uomo) deve essere richiesto all’Istituto Superiore di Sanità. Una volta ottenuto il Giudizio di Notorietà, bisogna ottenere sempre l’approvazione del Protocollo di studio da parte di tutti i Comitati Etici dei centri partecipanti alla sperimentazione.

Gli enti che in Italia autorizzano la commercializzazione di un farmaco sono il Ministero della Sanità e/o la Commissione Euro-

pea. Le procedure di registrazione si diversificano secondo il tipo di prodotto e di mercato in cui si vuole immettere il nuovo farmaco.

5.2.1.3 Il disegno sperimentaleQualsiasi ricerca clinica deve considerarsi un esperimento scientifi-co: essa trae origine dalla formulazione di una ipotesi seguita dall’al-lestimento di un piano sperimentale idoneo a saggiarla. Il disegno sperimentale deve pertanto essere adeguato all’obiettivo dello stu-dio, all’ipotesi di lavoro ed ai criteri di valutazione prescelti. Studi non sostenuti da un corretto razionale o non aventi un obiettivo scientificamente definito o un disegno sperimentale in grado di rag-giungere quest’ultimo, non hanno validità scientifica.

Il disegno sperimentale tende a minimizzare gli errori sistematici che possono introdursi nell’esperimento, ovvero tutte quelle fonti di variabilità che non dipendono dal trattamento. Occorre quindi conoscere le caratteristiche della malattia (frequenza, gravità, evolu-tività), definire i limiti sulla popolazione da studiare, stabilire i pa-rametri di valutazione ed i relativi metodi di rilevamento e definire l’entità dell’effetto atteso del farmaco in studio. Non bisogna mai dimenticare infatti che il punto cardine di tutta la sperimentazione clinica è il confronto dei risultati ottenuti su due o più gruppi di pazienti.

Gli strumenti a disposizione per “controllare” i fattori di variabi-lità non legati al farmaco a disposizione di chi esegue una sperimen-tazione clinica sono:• la selezione dei pazienti e gli indici quali e quantitativi da ana-

lizzare;• il controllo;• l’assegnazione casuale dei trattamenti e il mascheramento dei

trattamenti stessi (cecità).

La selezione dei pazienti e gli indici quali e quantitativi da analizzare

Nella selezione dei pazienti l’obiettivo principale è quello di garantire che i pazienti selezionati costituiscano un campione rappresentativo della popolazione a cui potranno essere applicati i risultati della ricer-ca. Criteri di ammissione eccessivamente rigidi, oltre a creare spesso difficoltà nel reperimento dei pazienti, rischiano di rendere impos-sibile la generalizzazione dei risultati; è altresì vero che criteri di am-missione troppo generici comportano spesso una disomogeneità del campione ed una conseguente eccessiva variabilità della risposta che può rendere problematica l’interpretazione dei risultati. Nella prima fase della sperimentazione di un farmaco definita fase conoscitivae

nonterapeutica che ha come scopo quello di acquisire informazioni su come la nuova sostanza si comporta nell’organismo e di verificare la predittività dei dati pre-clinici, gli studi vengono condotti su sog-getti sani volontari in numero compreso tra 100 e 200. Tra gli indici analizzati all’interno di questo campione primeggiano:• La valutazionediunprofiloditollerabilità del farmaco sommi-

nistrato a dosi crescenti sotto stretto monitoraggio clinico sino a definire, quando possibile, la dosemassimatollerata nell’uo-mo.

• La definizione di un profilofarmacocinetico attraverso i para-metri più significativi quali: la massimaconcentrazioneplasma-tica (Cmax); il tempo necessario per raggiungere tale concen-trazione (Tmax); l’area sottesa alla curva tempo/concentrazione (AUC), che fornisce informazioni sulla quantità del farmaco biodisponibile; l’emitivitàbiologica (t1/2) ovvero l’intervallo di tempo in cui una volta avvenuta la distribuzione nell’organi-smo, i livelli plasmatici si dimezzano.

• L’analisi del volumeapparentedidistribuzione ovvero il volu-me di liquido in cui teoricamente la dose di farmaco appare disciolta in modo uniforme in base alla concentrazione pla-smatici rilevata.

• Il calcolo della percentuale farmaco legata alle proteine e laclearance, ovvero la quantità di sangue depurata del farmaco nell’unità di tempo.

• L’acquisizione di informazioni sul destinometabolico del far-maco nell’uomo e lo studio dell’attività farmacodinamica nell’uomo.

A seguito della fase conoscitiva vi è una fase in cui per la prima volta l’attività del farmaco viene saggiata in pazienti con lo scopo di verificare se esso esercita un effetto utile nelle probabili indicazioni elettive, anche in confronto con standars o placebo. Il numero di pazienti coinvolti cresce rispetto alla prima fase e assume propor-zioni dell’ordine dei 200-400 soggetti. Oltre alla verifica dell’effetto terapeutico atteso, gli obbiettivi di questa fase sono:• La definizionedelledositerapeuticheattive e la ricercadellapo-

sologiaottimaledautilizzareneisuccessivistudi.• Valutare latollerabilitàabrevetermine.Superata questa fase il farmaco viene studiato in un campione di pazienti molto più ampio (2000-4000 individui) con l’obiettivo principale di dimostrare l’efficacia terapeutica e la tollerabilità nelle indicazioni principali e di valutare il rapporto rischio-beneficio ri-spetto a farmaci al momento disponibili.

Il controlloLa valutazione degli effetti di un nuovo farmaco, eseguita utilizzan-do un solo gruppo di pazienti trattati, può portare a conclusioni erronee in quanto potrebbero venire attribuite variazioni spontanee occasionali nel decorso dell’affezione ad effetti del trattamento.

Per questo motivo è indispensabile che le ricerche cliniche, che devono valutare l’efficacia e la tollerabilità di un farmaco, siano di tipo comparativo. Il termine “studio controllato” deve essere perciò inteso sinonimo di studio comparativo e ciò significa che i risultati ottenuti in un gruppo di pazienti trattati con il nuovo farmaco in esame, devono essere confrontati con un gruppo di controllo co-stituito da pazienti, con le medesime caratteristiche trattati con un farmaco standard di efficacia nota (oppure, qualora non esistano farmaci comparativi, con un placebo).

L’assegnazione casuale dei trattamenti e il mascheramento dei trattamenti (cecità)

Per ottenere una valutazione dell’effetto di un trattamento, il più possibile corretta, è necessario che questo venga assegnato ai pazien-ti secondo un procedimento casuale o randomizzato. La procedura di assegnazione casuale mira ad evitare che lo sperimentatore sia portato ad assegnare i trattamenti in base a convinzioni personali sull’effetto che essi potrebbero avere sui diversi tipi di pazienti.

Negli studi clinici controllati, un gruppo di pazienti riceve il trattamento sperimentale, mentre un altro gruppo (il gruppo di “controllo”) riceve una terapia standard (ad esempio un farmaco già utilizzato per la stessa patologia), oppure (dove sia eticamente-clinicamente accettabile) un placebo, cioè una preparazione appa-rentemente identica a quella che si vuole testare ma che non contie-ne alcun principio attivo. L’efficacia del nuovo farmaco viene così confrontata con quella della terapia standard o del placebo.

In uno studio controllato randomizzato (dall’inglese “randomi-zed”, cioè scelti a caso) i pazienti sono assegnati a caso al gruppo sperimentale o a quello di controllo, invece di essere scelti in modo deliberato dai ricercatori, il tutto sempre seguendo un protocollo sperimentale o trial clinico di riferimento.

Anche se nel linguaggio comune il termine protocollo sperimen-tale si usa come sinonimo di trial clinico, in senso stretto il pro-tocollo è il documento che descrive l’obiettivo, la metodologia, le considerazioni statistiche e l’organizzazione di uno studio. Si può dire che il protocollo è il “libretto di istruzioni” per poter eseguire in maniera corretta una sperimentazione clinica.

Generalmente tali studi vengono “mascherati” e più generalmen-

te si parla di mascheramento degli studi intendendo studi effettuati in cieco o in doppio cieco. Uno studio randomizzato si dice in cie-co (blind) quando i pazienti non sanno a quale gruppo sono stati assegnati. Ovviamente prima di partecipare ad uno studio in cieco i pazienti devono essere messi al corrente della possibilità che non venga loro somministrato il farmaco sperimentale ma il placebo. In uno studio in doppio cieco (doubleblind), né i pazienti né i medici sanno chi sta assumendo la cura sperimentale e chi il placebo. Le etichette dei farmaci e dei placebo portano dei codici, che vengono svelati solo alla fine dell’esperimento, o in caso di necessità. L’effica-cia della terapia farmacologica viene valutata facendo il confronto tra i dati ottenuti nei pazienti trattati con il farmaco e in pazienti trattati con il placebo. Solo se c’è una differenza statisticamente si-gnificativa tra i due tipi di “trattamento” a favore del gruppo di pa-zienti che è stato trattato con il farmaco si può dire che quest’ultimo ha una efficacia terapeutica.

5.2.2 La registrazione di un nuovo farmaco

Da una decina di anni, il percorso di registrazione dei farmaci passa sempre di più per un livello europeo, in un contesto di armonizza-zione internazionale. Nonostante persistano ancora alcune attribu-zioni nazionali, la materia farmaceutica è stata disciplinata a livello comunitario ed è soggetta ad una normativa analoga in tutti i paesi dell’Unione Europea (UE). In altre parole, gli strumenti legislativi su cui ogni Paese europeo basa la valutazione di un dato medicinale sono comuni in tutti i Paesi dell’UE. Di seguito è riportato un elen-co utile a capire il funzionamento generale delle istituzioni europee in cui avviene la registrazione di un medicinale e il monitoraggio dello stesso dopo che è entrato in commercio.• Autorizzazione all’Immissione in Commercio (AIC) • AIC nazionale • AIC europea secondo procedura centralizzata• AIC europea per mutuo riconoscimento• Agenzia Europea per la Valutazione dei Medicinali• EMEA (European Medicines Evaluation Agency)L’AIC è l’atto che permette ad un’azienda farmaceutica di commer-cializzare un medicinale, di specialità o generico, prodotto in modo industriale. Attualmente esistono nell’UE tre tipi di AIC: nazionale, europea secondo procedura centralizzata, europea per mutuo rico-noscimento.

L’AIC rilasciata con decreto del Ministero della Salute, dopo esa-me ed approvazione del dossier di valutazione da parte della Com-

missione Unica del Farmaco. Il medicinale con AIC nazionale può essere commercializzato unicamente nel Paese in cui l’autorizzazio-ne è stata accordata.

La procedura centralizzata prevede un’unica AIC valida in tutta l’Unione Europea. Tale autorizzazione viene rilasciata con decisione della Commissione Europea, sulla base di una valutazione scientifi-ca da parte dei comitati creati in seno all’Agenzia europea di valuta-zione dei medicinali EuropeanAgencyfortheEvaluationofMedicinalProducts (EMEA). La procedura centralizzata è obbligatoria per i medicinali derivati dalle biotecnologie e, nel caso di altri prodotti innovativi, è disponibile su richiesta delle ditte farmaceutiche.

La procedura del mutuo riconoscimento AIC si basa sul prin-cipio del mutuo riconoscimento di un’autorizzazione nazionale da parte degli altri Stati membri. L’AIC di un medicinale è rilasciata in un Paese dell’UE da un organismo nazionale competente (in Italia, il Ministero della Salute), su richiesta di un’azienda farmaceutica in-teressata. L’azienda può altresì richiedere l’estensione di tale autoriz-zazione alle Agenzie regolatrici di uno o più Stati dell’UE, sulla base della stessa documentazione presentata nello Stato che per primo ha autorizzato il farmaco. Tale Stato è detto “di riferimento”, in inglese Reference Member State, in quanto ha predisposto il rapporto di valutazione scientifica, che sarà sottoposto ad accettazione da parte degli altri Paesi dell’Unione. Tuttavia, uno Stato membro interessa-to può sollevare obiezioni qualora ritenga che vi siano fondati mo-tivi per supporre che l’autorizzazione di un determinato medicinale possa costituire un rischio per la salute pubblica. Se alle obiezioni non è data risposta convincente da parte dell’azienda farmaceutica e persiste il disaccordo, può essere coinvolta l’EMEA a cui la mate-ria viene trasferita affinché sia attivata una procedura di arbitrato. Il risultato di tale arbitrato sarà una decisione della Commissione indirizzata agli Stati membri interessati, che dovranno attuare le ne-cessarie disposizioni. Per evitare l’arbitrato, un’azienda farmaceutica può decidere di non commercializzare il medicinale nello Stato che ha sollevato obiezioni.

Nella Tabella 5.6 sono riportate le domande di AIC relative ai medicinali per uso umano contenenti nuove sostanze attive presen-tate secondo la procedura centralizzata e di mutuo riconoscimento dal 1995 al 2000.

Le domande sono presentate direttamente all’EMEA. Al termi-ne di una valutazione scientifica compiuta all’interno dell’Agenzia nell’arco di 210 giorni, il parere del comitato scientifico è trasmesso alla Commissione europea per essere trasformato in un’unica auto-rizzazione all’immissione in commercio per tutta l’Unione europea.

La procedura decentrata (o di mutuo riconoscimento) si applica alla maggior parte dei medicinali convenzionali e si basa sul principio di mutuo riconoscimento delle autorizzazioni nazionali. Fornisce un’estensione delle autorizzazioni all’immissione in commercio concesse da uno Stato membro o da uno o più Stati membri indivi-duati dal richiedente.

AnnoDomande di autorizzazione mediante procedura centra-

lizzata (%)

Domande di autorizzazione mediante procedura di mu-

tuo riconoscimento (%)1995 8 (80%) 2 (20%)1996 15 (50%) 15 (50%)1997 25 (49%) 26 (51%)1998 26 (70%) 11 (30%)1999 19 (61%) 12 (29%)2000 20 (77%) 7 (23%)Totale 6 anni 113 (61%) 73 (39%)

L’EMEA è una agenzia che coordina le risorse scientifiche degli Stati membri al fine di valutare e controllare i medicinali per uso umano e veterinario in tutta l’UE. Essa si propone di contribuire alla tutela e alla promozione della sanità pubblica e della salute degli animali:• mobilitando le risorse scientifiche disponibili nell’UE al fine

di garantire una valutazione di alta qualità dei prodotti medi-cinali, svolgendo un’attività di consulenza sui programmi di ricerca e sviluppo e fornendo informazioni utili e complete agli utenti e agli operatori sanitari;

• definendo procedure efficaci e trasparenti che consentano agli utenti di accedere tempestivamente a medicinali innovativi tramite un’unica AIC europea;

• controllando la sicurezza dei medicinali per uso umano e ve-terinario, in particolare mediante la creazione di una rete di farmacovigilanza e la definizione di limiti di sicurezza relativi ai residui consentiti negli animali destinati alla produzione ali-mentare;

• assicurando il coordinamento delle attività d’ispezione nel campo industriale dei medicinali, in particolare di quelle rela-tive alla verifica del rispetto della buona prassi di produzione (GMP), di laboratorio (GLP) e cliniche (GCP).

L’Agenzia fornisce inoltre consulenze scientifiche a società impegna-te nella ricerca durante la fase di sviluppo di nuovi medicinali, anche sotto forma di linee guida sui requisiti d’esame in materia di qua-lità, sicurezza ed efficacia. L’EMEA non ha poteri decisionali, ma

Tabella 5.6Domande relative ai

medicinali per uso umano contenenti

nuove sostanze attive presentate in

applicazione della procedura centralizzata

e della procedura di mutuo riconoscimento

dal 1995 al 2000

deve rendere disponibili valutazioni e pareri alle istituzioni europee, in particolare alla Commissione europea che autorizza le immis-sioni in commercio dei medicinali, e agli Stati membri (ad esem-pio, in materia di farmacovigilanza). Infine, compito dell’EMEA è di mettere a disposizione degli operatori sanitari e dei cittadini dell’UE le medesime informazioni aggiornate nelle 11 lingue uffi-ciali dell’Unione. Il nome del prodotto, l’etichettatura e il foglietto illustrativo sono pertanto gli stessi per tutti i cittadini, così come le indicazioni e le informazioni sul prodotto, di particolare importan-za per gli operatori sanitari.

Due comitati scientifici sono incaricati di formulare i pareri dell’Agenzia sulle questioni riguardanti la valutazione dei medici-nali: il Comitato per le specialità medicinali (CPMP) e il Comita-to per i medicinali per uso veterinario (CVMP). L’EMEA dispone inoltre di gruppi di lavoro costituiti da esperti provenienti dai dif-ferenti Paesi dell’UE.

L’EMEA è sottoposta al controllo di un consiglio di amministra-zione, composto da 34 membri, in rappresentanza di ciascun Stato dell’UE, del Parlamento europeo e della Commissione europea. Il direttore esecutivo dell’EMEA dirige un segretariato di circa 200 persone, suddiviso in quattro unità, che fornisce sostegno tecnico e amministrativo ai comitati e ai gruppi di lavoro.

Tuttavia, l’EMEA è di dimensioni notevolmente inferiori rispet-to alla Food and Drug Administration (FDA) degli Stati Uniti, seb-bene copra una popolazione pari a circa il doppio di quella statu-nitense.

In conclusione quando un medicinale ottiene la registrazione eu-ropea centralizzata, il suo codice o numero di AIC (che si ritrova, ad esempio, sulla confezione, nell’EPAR, ecc.) è costituito dai seguenti elementi:• lettere EU, per European Union;• cifra 1 o 2, a seconda si tratti di medicinale ad uso umano (1)

o veterinario (2);• due cifre, corrispondenti all’anno della prima autorizzazione

(ad esempio, 06 per 2006);• tre cifre, corrispondenti a un numero attribuito al medicinale;• tre cifre, che caratterizzano ogni preparazione della serie auto-

rizzata, variabile per numero di unità, dosaggio, forma farma-ceutica, via di somministrazione, ecc.

Ad esempio, EU/1/00/150/001 corrisponde all’AIC europea della specialità ad uso umano ACTOS® compresse 15 mg orale, blister in alluminio da 28 compresse, registrata nel 2000.

5.2.2.1 La domanda di registrazione del farmaco in Italia e in alcuni Paesi

È al termine della fase III del processo di sviluppo, che l’azienda farmaceutica deve fare domanda di registrazione del nuovo farmaco all’Autorità Regolatoria competente. A tale domanda deve essere allegato il dossier di registrazione che descrive il farmaco e tutte le sperimentazioni che sono state effettuate, insieme al foglio illu-strativo e ad una scheda tecnica che contenga la denominazione della specialità, la composizione qualitativa e quantitativa, le forme farmaceutiche, le proprietà framacolociche e tossicologiche, nonché gli elementi di farmacocinetica, le informazioni cliniche e quelle farmaceutiche.

Tutti i documenti descritti vanno consegnati all’Autorità Re-golatoria: è il processo di submission del dossier. Negli Stati Uniti d’America, l’ente preposto all’analisi della documentazione del dos-sier è la FDA, mentre per i paesi dell’Unione Europea l’organo com-petente è l’EMEAnel caso in cui l’autorizzazione venga richiesta se-condo procedura comunitaria (detta centralizzata), oppure i singoli MinisteridelleSanità dei diversi Paesi, qualora si tratti di procedura nazionale o di mutuo riconoscimento (estensione di autorizzazioni già concesse in altri Paesi dell’unione Europea).

Il contenuto del dossier è specificato da linee guida che sono rese disponibili dalle Autorità Regolatorie dei diversi paesi. La domanda non viene accettata automaticamente, ma una commissione scienti-fica valuta attentamente i dati che l’industria farmaceutica ha messo a disposizione e raccolto nel dossier e, ove fosse necessario, ne ri-chiede di altri. I documenti vengono studiati dalle diverse divisioni dell’autorità di competenza e, se l’esito dell’analisi dei documenti forniti è positivo, sarà l’Autorità Regolatoria a prendere la decisio-ne finale se concedere l’autorizzazione all’immissione in commercio del nuovo farmaco.

Alla fine degli studi sperimentali, i dati raccolti dovranno, nel loro insieme, dimostrare che il farmaco:• ha un’azione correlata al meccanismo che causa la malattia;• dimostra effetti replicabili, ovvero che ogni volta che si som-

ministra il farmaco, si ottengono le medesime risposte di ef-ficacia;

• migliora la qualità di vita del paziente;• ha un migliore rapporto costo/beneficio rispetto ai trattamenti

in atto praticati (per esempio, ha un migliore profilo di tollera-bilità e/o assicura meglio l’adesione del paziente);

• rappresenta un significativo progresso nella conoscenza della malattia e del suo trattamento.

Se i dati raccolti durante tutte le fasi delle sperimentazioni precli-niche e cliniche sono positivi il dossier viene sottoposto al giudizio delle Autorità Regolatorie per richiedere l’approvazione alla com-mercializzazione. In caso contrario, pur essendo riusciti a sviluppare una molecola farmacologicamente attiva, ma non un buon farmaco, il processo si chiude con un insuccesso. Questo è, purtroppo, un evento il cui rischio è sempre messo in preventivo da un’azienda farmaceutica orientata alla ricerca e allo sviluppo.

5.2.2.2. Gli aggiornamenti più recenti Per quanto riguarda gli aggiornamenti più recenti possiamo suddi-videre il discorso in due parti. La prima riguarda l’effettiva imple-mentazione di una versione finale del Common Technical Docu-ment (CTD). In questo senso possiamo affermare che una versione definitiva è stata approvata nel Novembre 2000 e solo a partire dal Luglio 2001, le aziende farmaceutiche hanno avuto la possibilità di inoltrare il dossier a EMEA, FDA e MHLW (il Ministero giappone-se “Ministry of Health, Labour and Welfare”), seguendo il formato standard CTD. A partire dal Luglio 2003 il CTD è diventato obbli-gatorio: tutte le aziende che devono inoltrare domanda di registra-zione di un nuovo farmaco nella Unione Europea, in Giappone, in Canada e in Svizzera dovranno rispettare il formato standard.

Il formato dell’eCTD invece è stato approvato durante l’incontro dell’ICH tenutosi a Washington (USA) nei giorni 9-12 Settembre 2002 [ICH, 2002]. Più articolato ed innovativo è invece il discorso che riguarda la forte spinta nata in questi ultimi dieci anni a definire un iter di riconoscimento del farmaco all’interno del lotto di produ-zione di appartenenza (Vedi Paragrafo 5.4).

5.2.3 L’impatto del nuovo farmaco sul sistema informativo di una azienda farmaceutica

L’attività di compilazione del dossier registrativo è per sua natura una attività complessa, che richiede una grande quantità di risorse, sia in termini di tempo che di persone.

Le sfide introdotte dal nuovo formato standard impattano in due direzioni:• dal punto di vista dell’aumentato livello di dettaglio della do-

cumentazione richiesta dal CTD e quindi del flusso informa-tivo. Poiché spesso la documentazione proviene da terze par-ti, occorre fare maggiore attenzione alle informazioni fornite dall’esterno, verificandone la completezza e correttezza e con-formità al formato;

• dal punto di vista dei processi di preparazione del dossier. La compilazione è, infatti, un’attività che coinvolge funzioni aziendali interne ed enti esterni.

L’introduzione del un nuovo formato di registrazione del farmaco semplifica l’attività di compilazione, che rimane comunque un’atti-vità non semplice da gestire [Borghoff e Pareschi, 1997].

La Figura 5.15 mostra le funzioni aziendali coinvolte, come emettitori di documentazione o revisori, nella compilazione del dossier. Sono distinte le funzioni interne (blocchi tratteggiati) e gli enti esterni, in genere presenti in una qualsiasi azienda farmaceutica (blocchi a tratto continuo).

Ciascuna organizzazione esterna avrà una funzione referente in-terna, alla quale dovrà sottoporre i documenti e apportare modifi-che o fornire maggiori dati se richiesti. Ogni funzione interna ha poi la responsabilità di uno o più paragrafi del CTD-dossier.

Senza che la figura si sia addentrata nei dettagli di tutti i paragrafi e sottoparagrafi previsti e specificati dal CTD, è già evidente la com-plessità dei rapporti e dei processi al fine di redarre il dossier.

La stessa complessità nel processo di compilazione del dossier registrativo è evidenziata dalla Figura 5.16, che illustra le interazioni tra le funzioni interne ed esterne secondo il Semantic Object Model (SOM), un modello basato su un approccio orientato agli oggetti per l’analisi dei processi lavorativi.

Per oggetto s’intende un’entità specifica e riconosciuta come in-dipendente e portatrice di un significato (semantico). L’ambiente aziendale, che costituisce l’universo del discorso, viene così modella-to mediante oggetti interagenti tra loro, coinvolti, nel caso specifico, nella compilazione del dossier del farmaco. Facendo riferimento alla

Figura 5.15I ruoli coinvolti nella

compilazione del CTD-dossier

productionPT expertsARA

NC CRO

NC dep.

NC experts

C dep.

C experts C CRO

supplier

purchase

fine.Chem.

CTD Summaries

2.1 ToC2.2 Introduction2.3 Quality Overall Summary2.4 Non-Clinical Overview2.5 Clinical Overview2.6 Non-Clinical Summary2.7 Clinical Summary

Reg.Admin.Info

1.1 ToC1.2 Application form1.3 Product Info1.4 Experts Signature

1.5 Specific Requirements for Application

Non-Clinical (Safety)

4.1 ToC4.2 Non-Clinical Reports4.3 Literature References

Clinical (Efficacy)

5.1 ToC5.2 Tabular Listing5.3 Clinical Reports5.4 Literature References

Quality

3.1 ToC3.2S Drug Substance Q3.2P Drug Product Q3.2A Appendices 3.2R Regional Info

Figura 5.16, il sistema risulta allora modellato con oggetti interni all’azienda (i rettangoli), con oggetti esterni (gli ellissi) in contatto con quelli aziendali e con le transazioni tra oggetti (le frecce).

Le transazioni possono essere sia servizi che gli oggetti scambiano tra loro, sia informazioni che fluiscono da un oggetto all’altro.

Nello specifico del processo di compilazione del dossier, il modello illustra lo schema delle interazioni tra funzioni aziendali interne ed esterne e il flusso delle informazioni tra loro, che non sono altro che documenti che costituiranno il contenuto di paragrafi del dossier.

5.2.4 Il “Common Technical Document” (CTD) Il CTD, la cui specifica è stata approvata dall’ICH durante la con-ferenza tenutasi a San Diego nel Novembre 2000 [ICH, 2002], è stato introdotto allo scopo di ottenere:• una riduzione concreta dei tempi e delle risorse utilizzate nella

registrazione di nuovi farmaci. In particolare rispetto all’atti-vità di redazione per quanto riguarda l’azienda farmaceutica e quella di revisione per quanto riguarda le Autorità Regolatorie. Questo produce degli effetti positivi anche sulla riduzione del ritardo nella disponibilità del farmaco sul mercato;

• un miglioramento nella qualità del processo di registrazione dei farmaci;

• la standardizzazione dei formati dei dossier nelle tre aree, così da uniformare interpretazione ed applicazione dei requisiti per la registrazione dei prodotti.

L’impatto che l’introduzione del CTD ha sulle aziende del settore non è irrilevante. Con la sua comparsa, esse dovranno seguirne la rigida struttura, fornire informazioni ancora più dettagliate e sotto-porsi ad una più attenta valutazione dei requisiti richiesti.

Figura 5.16Lo schema delle interazioni e il flusso delle informazioni

NC study Reports NC overview

NC summeries

Trial reports

Application form

ProductInfo

Quality OverallSummary

DrugMaster

DrugSubstance

Information

DrugSubstance

Information

Rial Reports

C overviewC summariesC studyreports

C exportsinformation

NC CROs C CROsNC EXPERTS C EXPERTS

SUPPLIERS

PURCHASING

FINE CHEM

PT EXPERTS

CLINICAL (C)

PRODUCTIONPHARMATECH (PT)

NON CLINICAL (NC)

AFFILIATEREGULATORYAFFAIRS (ARA)

HEAD-QUARTERREGULATORY

AFFAIRS (HQ RA)

NC ExpertsInformation

PT ExpertsInformation

Il CTD è strutturato in moduli che organizzano i documenti richie-sti. Esistono delle guide, sviluppate dall’ICH, che assistono tutte le aziende farmaceutiche con informazioni precise circa la prepa-razione del CTD (Organizzazione del CTD, Qualità del farmaco, Efficacia e Sicurezza).

Le principali specifiche dettate dal CTD e che richiedono parti-colare attenzione per l’implementazione sono:• costruire ed inserire i tabs per separare le diverse sezioni del

dossier e renderne più semplice la consultazione;• spezzare il dossier cartaceo in volumi;• numerare le pagine dei volumi come da specifica;• i cross-referencing da un documento ad altri devono essere fatti

specificando il numero del volume e la sezione, seguiti dal nu-mero di pagina;

• la compilazione della TableofContents (ToC).Inoltre, in ogni parte, la visualizzazione delle informazioni deve es-sere non ambigua e facilitare la revisione dei dati più importanti, permettendo a chi revisionerà il dossier di orientarsi velocemente tra i contenuti. Per questo il testo e le tabelle devono essere redatti rispettando regole comuni (ad es. il formato carta A4 è valido per l’Unione Europea e il Giappone mentre il formato 8.5x11’’ è valido per gli Stati Uniti).

5.2.4.1 I moduli del CTD Il CTD organizza i contenuti del dossier in cinque moduli. Tutti i nomi e i titoli dei paragrafi sono stati lasciati in inglese, in quanto le specifiche del CTD per l’electronicsubmission hanno valenza inter-nazionale e la lingua di riferimento è l’inglese.• Modulo 1: Regional Administrative Information. Il modulo

contiene informazioni specifiche regionali: sono i requisiti ri-chiesti dai singoli enti regolatori regionali.

• Modulo 2: CTDSummary. Questo modulo fornisce al revi-sore una valutazione complessiva e critica del farmaco, dei processi e di eventuali conclusioni che sono state tratte dai diversi studi su di esso. Inizia con una generale introduzione al farmaco, che include la sua classe farmacologica, la sua moda-lità di azione e il suo uso clinico. In generale tale introduzione non supera una pagina. È importante notare che tale modulo non fornisce nessun nuovo dato che non sia già contenuto nei Moduli 3, 4, 5.

• Modulo 3: Quality. Il modulo fornisce informazioni sulla qua-lità del prodotto farmaceutico e sul/sui principio/i attivo/i in esso contenuto/i.

• Modulo 4: NonclinicalStudyReports. Contiene i reports dei test non-clinici.

• Modulo 5: ClinicalStudyReports. Contiene i reports dei test clinici.

La figura è disponibile on-line nella raccolta di “iconografia di sa-nità digitale”.

Modulo 1Il Modulo 1 deve contenere dati sul prodotto e informazioni am-ministratrive della specifica regione alla quale il dossier verrà inol-trato. Consideriamo, a titolo esemplificativo, le specifiche dettate dall’EMEA per l’Unione Europea.

Per una prima domanda di certificazione il prodotto, occorre presentare:• modulo di richiesta di sottomissione;• documenti informativi generici del prodotto;• informazioni sul personale esperto che ha condotto i test;• ToC (Table of Contents), ovvero una tabella dei contenuti,

dell’intero dossier;• SPC (SummaryofProductCharacteristics), che illustra le carat-

teristiche della confezione del farmaco e altri requisiti specifici dell’applicazione, insieme ad eventuali certificati di conformi-tà alle buone pratiche GMP.

Tutti questi documenti non sono più necessari in caso di domande di certificazione successive alla prima nel ciclo di vita del farmaco (ad esempio per variazioni sul prodotto stesso).

Modulo 2 Le specifiche prevedono innanzitutto che il modulo fornisca una pagina introduttiva con la descrizione del farmaco: la sua classe far-macologica, il modo di agire e l’uso clinico proposto. Il modulo è poi strutturato come segue:• la sezione QualityOverall Summary fornisce una veduta ge-

nerale di quello che sarà contenuto nel Modulo 3. Questo ri-assunto pone attenzione su alcuni parametri critici di qualità del principio attivo e del prodotto e include riferimenti che rimandano ad altri moduli, specificandone il volume e il nu-mero della pagina. Normalmente non eccede le 40 pagine di testo, escluse eventuali tabelle e figure.

• la sezione Non-ClinicalOverview fornisce un riassunto com-plessivo dei dati non-clinici, con un’interpretazione degli stes-si, con i riferimenti agli aspetti di qualità del farmaco e con le implicazioni dei risultati non-clinici sull’uso sicuro del pro-

dotto. I dati presenti in questa sezione sono ricavati in partico-lare dalla sperimentazione su cavie animali;

• la sezione ClinicalOverview fornisce un’analisi critica dei dati clinici nel CTD. Fa riferimento ai report dei singoli test cli-nici e ad altri rilevanti report e soprattutto deve presentare le conclusioni e le implicazioni di quei dati. Il Clinical Overview deve essere abbastanza breve (circa 30 pagine). La lunghezza in ogni caso dipende dalla complessità dell’applicazione. È con-sigliato l’uso di tabelle e grafici che lo rendano più facilmente e velocemente comprensibile, e di riferimenti a paragrafi più dettagliati del Modulo 5;

• la sezione Non-ClinicalWrittenandTabulatedSummary illu-stra gli studi preclinici che sono stati condotti durante la speri-mentazione del farmaco. Quando è possibile, gli studi in vitro devono precedere quelli in vivo. Le specifiche di questa sezione del CTD non indicano quali studi sono richiesti, ma sempli-cemente indicano il formato appropriato per organizzare i dati non clinici nel dossier;

• la sezione Clinical Summary fornisce un dettaglio riassun-to delle informazioni cliniche contenute nel Modulo 5 del CTD: lo scopo di questa sezione è il confronto e l’analisi dei risultati fra i vari studi condotti. Differentemente, il Cli-nical Overview fornisce un’analisi critica del programma e dell’organizzazione dei test clinici e dei risultati di tale piani-ficazione. La lunghezza del Clinical Summary varia molto a seconda delle informazioni che sono state prodotte, ma indi-cativamente può variare dalle 50 alle 300 pagine, escludendo eventuali tabelle allegate.

Modulo 3Il modulo Quality specifica come raccogliere e organizzare tutte le informazioni chimico-famaceutiche e biologiche delle sostanze atti-ve e del prodotto medicinale.• Innanzitutto include una TableofContents che aiuti il revisore

ad avere un quadro d’unione del modulo e dei documenti in esso contenuti. Tale tavola è seguita dal corpo dei dati.

• La sezione contraddistinta con “S” dà tutte le informazioni generali sul principio attivo del farmaco, una descrizione dei produttori del principio attivo, dei processi di sintesi e dei re-lativi controlli, un chiarimento sulla struttura e sulle caratteri-stiche del principio attivo, un’analisi dei controlli sul principio attivo, un elenco dei materiali di riferimento usati per i test; una descrizione della confezione, infine un riassunto degli stu-

di di stabilità fatti, dei protocolli usati e dei risultati ottenuti.• La sezione contraddistinta con “P” è una descrizione del far-

maco, della sua composizione e del suo dosaggio. Contiene informazioni sugli studi condotti per stabilire la formulazione del prodotto, il processo di produzione, la confezione e le in-dicazioni d’uso. Raccoglie le specifiche degli eccipienti e del principio attivo.

• La sezione contraddistinta con “A” raccoglie appendici con in-formazioni riferite al nucleo del dossier.

• Nella sezione contraddistinta con “R” sono raccolte informa-zioni supplementari sul prodotto farmaceutico e sul principio attivo, specifiche di ogni regione. Per l’Europa ad esempio è richiesto lo schema del processo di validazione del farmaco.

• L’ultima sezione contiene i riferimenti bibliografici.

Modulo 4 Il Modulo 4 specifica il formato per l’organizzazione dei report degli studi preclinici nel CTD: comprende i report di test farmacologici, farmacocinetici e tossicologici.

Un’iniziale TableofContents elenca tutti i report dei test precli-nici e dà l’indicazione di dove sono dislocati nel CTD. Vengono poi elencate tutte le tipologie di report richiesti e infine, al solito, eventuali riferimenti bibliografici.

Modulo 5Parallelamente al Modulo 4, l’ultimo modulo del CTD specifica l’organizzazione che deve essere data ai report degli studi clinici e ad altri dati clinici. Queste specifiche facilitano la preparazione e la revisione di una richiesta di autorizzazione all’immissione in com-mercio di un nuovo farmaco ad uso umano.

5.2.5 “Electronic submission” e eCTD

In seguito al formato CTD sviluppato dall’M4 EWG, un altro gruppo di sviluppo, l’M2EWG ha presentato all’ICH un’altra spe-cifica: l’Electronic Common Technical Document (eCTD), l’equi-valente elettronico del formato cartaceo CTD.

Le specifiche eCTD descrivono il formato per l’electronic delive-ry del dossier, la cui struttura è quella già specificata nel CTD. L’eC-TD è quindi un modo strutturato con cui organizzare, presentare e poi mantenere i dati raccolti nello sviluppo di un farmaco. La novità di questo formato elettronico è l’utilizzo di una tecnologia innova-tiva, quella del linguaggio XML (eXtensibleMarkupLanguage). Il

processo che deve essere supportato e per il quale è stato sviluppato l’eCTD è descritto come segue:

Industria Farmaceutica ‹-----› Messaggio ‹-----› Autorità Regolatoria

L’eCTD definisce i requisiti per il messaggio. Il principale obiettivo è fornire un formatoditrasporto dei dossier tra industria farmaceu-tica e Autorità Regolatorie. L’azienda dà inizio al processo creando una iniziale submission concordemente al formato CTD elettroni-co. Le specifiche dell’eCTD vogliono fornire dei criteri comune-mente accettati, imponendo minime restrizioni sia alle aziende sia alle Autorità Regolatorie nella modalità di scambio delle informa-zioni nel corso del ciclo di vita di un’applicazione farmaceutica.

La specifica eCTD dà supporto per il trasferimento elettronico di applicazioni di registrazione di farmaci dell’azienda all’Autorità di certificazione.

Viene così fornita la lista delle specifiche che rendono una electro-nicsubmission(e-Submission), iniziale o con i successivi cambiamen-ti, tecnicamente valida e standard: • nomi dei file;• generazione del XML backbone, ovvero di una struttura elet-

tronica del dossier;• hyperlink e bookmark: i documenti al loro interno devono

contenere link ad annotazioni, a sezioni correlate con essi, ad appendici, tabelle e figure che non sono nello stesso file, allo scopo di aiutare la navigazione del dossier elettronico;

• formato e contenuto dei file: l’eCTD specifica il tipo, la di-

Figura 5.17La rappresentazione

dell’eCTD

mensione e la navigazione all’interno di cartelle e file del dos-sier. I file hanno i seguenti possibili formati:1. File narrativi: formato PDF2. File con dati strutturati: formato XML3. File grafici: formato PDF (se possibile), JPEG, PNG, GIF;

• dimensione massima dei file: da tale dimensione dipende poi il supporto elettronico per la delivery del dossier;

• tutte le tabelle, figure e ToC devono essere raggiungibili tra-mite hyperlink.

L’implementazione di una e-Submission, o eCTD Submission, con-siste nella composizione di un pacchetto elettronico denominato XML backbone. È un file XML che, quando usato con un appro-priato style-sheet o visualizzatore, permette di navigare attraverso il dossier elettronico. In esso sono anche contenute informazioni ri-guardanti la submission e il contenuto dei file. Per rendere l’idea di come sia strutturato il dossier elettronico, si guardi la Figura 5.17: paragona l’intero dossier alle radici di un albero, che si diramano poi nei rami, ovvero le directory dei moduli di un dossier, e infine le foglie rappresentano i documenti finali, nei formati sopra descritti.

L’eCTD Submission è una struttura basata su directory e file, che contengono i report, i dati e quanto altro occore per la submission del dossier elettronico, ugualmente a quello cartaceo.

La struttura dell’eCTD rispecchia, in termini di organizzazione e di navigazione, la struttura modulare del CTD.

Il ruolo dell’eCTD è fornire la capacità di trasferire elettronica-mente il CTD dall’industria all’Autorità Regolatoria. L’eCTD è un catalogo XML con link agli attuali file della CTD Submission. Dal momento che l’eCTD è basato su un XML backbone, l’utilizzo di XML permette alla eCTD submission di essere visualizzata attraver-so un Web browser e di essere caricata su un Web server.

Una parte della specifica è dedicata a descrivere quei contenu-ti che non sono inclusi nel CTD e quei dettagli logistici necessari per l’iter di e-Submission, quali gli indirizzi a cui inoltrare i dossier elettronici, i supporti informatici consentiti per l’e-Submission, la lettera di presentazione del dossier, il trasporto e la sicurezza.

In poche parole se vogliamo descrivere l’Architettura di un eCTD possiamo riassumere i seguenti principi di base:• un eCTD è progettata con l’obbiettivo primario di presidiare

lo scambio di elementi informativi tra l’industria del farmaco e le Agenzie.

• l’eCTD realizza una struttura elettronica modulare: submis-sion, pienamente rispondente in termini organizzativi e di navigazione alla struttura del Common Technical Document.

• si presenta con una gerarchia di cartelle nidificate, realizzando percorsi ramificati e catalogando all’estremo della ramificazio-ne i files degli argomenti trattati.

• riproduce il percorso logico che nel CTD, attraverso la sche-matizzazione in moduli, paragrafi e sottoparagrafi, conduce alla localizzazione degli argomenti all’interno del report di re-gistrazione (Figura 5.18).

5.2.6 Conclusioni e valutazioni

Per lungo tempo, il dossier di registrazione ha assolto il compito di dimostrare la qualità, la sicurezza ed il rapporto rischio/beneficio dei farmaci, assumendo dunque il ruolo di “passaporto” che ogni nuovo farmaco deve avere per poter essere ammesso sul mercato. Tuttavia, a causa delle attuali difficili condizioni economiche e della crescente pressione per ridurre la spesa sanitaria, il dossier di re-gistrazione, inteso in maniera tradizionale, con i suoi report sugli studi chimico-farmaceutici, farmaco-tossicologici e clinici, non è più sufficiente per assicurarsi uno “spazio” sul mercato. Negli Stati Uniti, la presentazione di documentazione relativa alla farmaco-economia alle Managed Care Organization (MCOs) è ormai un fatto assodato e avviene secondo le linee dettate da Food and Drug Administration Act (FDAMA). In aggiunta, la crescente pressione economica sta introducendo una nuova sfida per l’industria farma-ceutica: dimostrare che un medicinale è effettivamente innovativo.

Module 1

Nonclinical Written and Tabulated

Summaries 2.6

Nonclinical Overview

Module 3 Quality

3 3.1 T of C

Module 4

Nonclinical Study Reports

4 4.1 T of C

Module 5

Clinical Study Reports

5 5.1 T of C

Clinical

Summary 2.7

Quality Overall

Summary 2.3

Clinical Overview

CTD Table of Contents

CTD Introduction

2.2 Module 2

Regional Administrative

Information 1

1.1 Submission T of C

Not part of the CTD

Figura 5.18Rappresentazione

schematica dell’organizzazione per lo sviluppo del

documento ICH – CTD. Adattato da [ICH, 2004]

Di conseguenza, un dossier di registrazione capace di dimostrare che un farmaco può essere prodotto secondo standard di qualità e che presenta un rischio/beneficio accettabile, non è più sufficiente per garantire al medicinale una posizione sul mercato. Il rapporto costo/beneficio e l’”innovatività” del prodotto sono oramai aspetti cruciali da considerare. Inoltre, lo stesso ruolo del regulatoryaffairmanager, come custode del dossier di registrazione sta cambiando. Allo scopo di accelerare la registrazione dei farmaci, buona parte delle aziende farmaceutiche compilano il dossier durante lo svilup-po del farmaco piuttosto che aspettare il completamento di tutti gli studi sul prodotto. Ne consegue come la compilazione del dossier sia parte integrale dello sviluppo del farmaco, che vede il coinvolgi-mento di tutte le funzioni Ricerca e Sviluppo. Tutto questo implica che il controllo sul dossier di registrazione non sia più solamente nelle mani del regulatoryaffairmanager ma condiviso con il resto del team di Ricerca e Sviluppo.

Un cambiamento di fondamentale importanza è quindi il passag-gio da dossier di registrazione con scopo nazionale a dossier capaci di soddisfare aspettative globali. Alla base di tale cambiamento c’è la Conferenza Internazionale sull’Armonizzazione (ICH) - un’inizia-tiva appoggiata da industria e agenzie regolatorie negli Stati Uniti, nell’unione Europea (EU) ed in Giappone - il cui scopo è l’armoniz-zazione dei requisiti per la registrazione dei farmaci nelle tre regioni menzionate. Sin dalla sua fondazione nel 1990, l’ICH ha prodotto numerose linee guida sullo sviluppo del farmaco. Alcune di queste iniziative hanno costituito dei passi critici verso lo sviluppo globale del farmaco, come per esempio la guida sulla accettabilità dei dati clinici esteri, che ha ridotto notevolmente il numero di studi di fase III necessari per registrare un farmaco in diversi Paesi e, recente-mente, lo sviluppo del Common Technical Document (CTD), una serie di specifiche per l’armonizzazione della struttura del dossier di registrazione. Il Common Technical Document (CTD) porta bene-fici enormi all’industria farmaceutica e rappresenta un buon punto di partenza per una armonizzazione globale. Per decenni infatti le aziende farmaceutiche hanno preparato dossier di registrazione na-zionali, mentre con l’arrivo del CTD ora si è in grado di presentare un dossier valido per diversi paesi.

In aggiunta al cambiamento da dossier nazionali/regionali a globali, vi è da considerare l’altro importante cambiamento realiz-zatosi, ovvero, il passaggio da dossier cartacei a quelli elettronici. L’FDA accetta da alcuni anni ormai dossier elettronici; al contrario, la situazione in Europa è molto più complessa dal momento che le aspettative cambiano da Paese a Paese. Alcune agenzie regolatorie

sono disponibili ad accettare un dossier elettronico in aggiunta a quello cartaceo; altre sono disponibili ad accettare dossier in parte elettronici ed in parte cartacei ma non vi è ancora una armonizza-zione a tale riguardo.

Il passaggio da dossier cartaceo ad elettronico presenta delle sfi-de rilevanti. In particolare, le aziende farmaceutiche devono gestire un quantitativo enorme di documentazione elettronica e, di conse-guenza, hanno bisogno di nuovi sistemi, di nuovi processi e metodi di lavoro. La carta è un mezzo durevole, ma l’IT è in continua evo-luzione ed alcuni dei programmi correntemente usati per creare ed archiviare documenti potrebbero presto divenire obsoleti. La grande sfida è assicurarsi che tutti i dati che vengono creati oggi siano leg-gibili in futuro.

Il cambiamento da dossier cartacei a quelli di formato elettroni-co, non significa semplicemente investire in IT: bisogna considerare l’impatto del cambiamento sulle risorse umane. Sarà necessario, in-fatti, assumere personale con diverse qualifiche.

Nelle grandi aziende farmaceutiche sembra logico avere all’in-terno del reparto di regulatoryaffair, un gruppo dedicato esclusiva-mente alla compilazione del dossier elettronico. In questo ambito i corsi ed i seminari di formazione sono uno strumento valido per il raggiungimento di tale scopo. Al contrario, nelle aziende più pic-cole che non possono permettersi di avere risorse dedicate a tale at-tività, sembra valido esplorare altre opportunità come per esempio l’outsourcing delle attività IT ad organizzazioni specializzate.

Non solo il tradizionale dossier di registrazione è praticamen-te scomparso ma lo stesso concetto di approvazione del dossier sta inoltre cambiando. Vi è la tendenza ad andare da una registrazione valida per tutta la vita del prodotto ad un continuo processo di riva-lutazione del dossier per quel che concerne la sua farmaco-tossicità, la sua efficacia ed il suo rapporto costo/beneficio.

In particolare se consideriamo la comunicazione elettronica tra azienda farmaceutica ed ente di certificazione durante il processo di electronicsubmission essa ha lo scopo principale di semplificare l’iter d’approvazione di un nuovo farmaco.

I potenziali benefici di tale paradigma elettronico per le attività regolatorie e per le aziende farmaceutiche possono riassumersi nel seguente elenco:• controllo della documentazione regolatoria: sono chiari le pro-

cedure, i ruoli e le responsabilità per la preparazione, la revisio-ne, l’approvazione e l’archiviazione della documentazione.

• Disponibilità della documentazione critica del dossier al mo-mento opportuno e per tutte le persone autorizzate.

• Riduzione del tempo e dello sforzo di compilazione del dos-sier.

• Garanzia della qualità dei documenti attraverso la loro gestio-ne elettronica e un flusso di lavoro automatizzato, che sempli-fica il processo di mantenimento del dossier nel ciclo di vita di una submission, grazie alla struttura dell’XMLbackbone.

• Aumento della collaborazione interna e della condivisione del-le informazioni, che implicano anche una riduzione dei tempi di revisione e approvazione dei documenti critici del dossier.

• Miglioramento dello scambio di informazioni con terze parti esterne all’azienda, quali fornitori, esperti e centri di ricerca (CRO), in termini di qualità e disponibilità della documen-tazione.

• Efficienza ottenuta dal facile riutilizzo di contenuti da una submission all’altra.

• Possibilità di sottomettere simultaneamente, ai tre più grandi mercati farmaceutici mondiali, le richieste di commercializza-zione di nuovi farmaci.

È evidente che l’introduzione delle applicazioni elettroniche com-porta anche dei costi per le aziende che devono adeguarsi alle nuove regolamentazioni. Nell’implementazione di una soluzione di e-Sub-mission, occorre quindi considerare:• i costi delle persone: i dipendenti vanno istruiti, occorre far

loro del training affinché siano in grado di utilizzare al meglio la nuova tecnologia che si decide di introdurre e acquistino familiarità con la nuova modalità di gestione dei documenti e di submission;

• I costi della tecnologia per migrare dagli esistenti sistemi a un nuovo sistema elettronico che sia in grado di rispondere alle nuove esigenze;

• Gli eventuali costi di integrazione con sistemi già esistenti in azienda, che non possono essere sostituiti.

Tenendo conto di questi fattori di costo, l’azienda che affronta un progetto di e-Submission, deve fare particolare attenzione a mini-mizzare l’impatto che un tale progetto può avere sull’organizza-zione. L’intero percorso che porta all’electronic submission implica notevoli cambiamenti di processi e strumenti utilizzati, all’interno dell’azienda e all’esterno: lo sforzo dell’azienda deve essere rivolto a ridurre al minimo gli effetti sui membri dell’organizzazione, in termini di modalità di lavoro e di carico di lavoro.

5.3 Medical Knowledge Management e Semantic Web

5.3.1 Introduzione

Il Web Semantico è un’estensione del World Wide Web in cui il contenuto web può essere espresso non solo nel linguaggio naturale, ma anche in una forma che può essere letta e usata da agenti softwa-re (quindi da ‘macchine’), permettendo loro di trovare, condividere e integrare informazioni in maniera più facile [Berners Lee et. al, 2001].Doveeperchènascel’esigenzadiquestostrumentoPrima di affrontare questo tema è molto importante fornire un qua-dro preciso della realtà a cui ci riferiamo e dei bisogni e delle aspet-tative che questa realtà suscita in noi. Partiamo quindi da alcune constatazioni:La conoscenza umana:• non è soltanto verbale, ma è istintivamente multimediale.

Include anche immagini, suoni, sensazioni tattili, ecc. È an-che multistrumenti (si avvale di frasi, tabelle, immagini della realtà come fotografie, immagini esplicative come i vari tipi di disegno, immagini di sintesi come istogrammi, segnali che evolvono in un certo dominio, grafi, ecc.), ciascuno dei quali richiede di essere letto con l’appropriata procedura;

• usa facilmente una grande varietà di granularità istantanea-mente orientate all’interesse del momento.

Se rileggiamo queste considerazioni e ripensiamo al mondo infor-matico, percepiamo subito la distanza esistente tra il nostro modo di conoscere e le modalità di acquisizione di informazioni che ci possono derivare dalla consultazione, ad esempio, di un motore di ricerca.

Unicode

NamespacesXML

XML SchemaXML Query

RDF Model & Syntax

Ontology

Rules/Query

Trusted SW

URI/IRI

Figura 5.19L’architettura del

Semantic Web. Adattato da [Signore, 2006]

Attualmente infatti nel mondo informatico esiste una limitazione molto forte: le interrogazioni informatiche sono al massimo SQL-like basate cioè sulla Structured Query Language o Google-like.

Cosa intendiamo con questo? Consideriamo ad esempio un turi-sta che di fronte a un quadro esclami:”Questo è un Goya!”. Questa esclamazione deriva da un’insieme di immagini precedentemente osservate dal turista con delle caratteristiche particolari tipiche di quell’autore e quindi associate allo stesso. Ma con Google potrem-mo fare lo stesso? Al momento Google verifica solo se a una data immagine è stata associata un’etichetta con scritto “Goya”. Se esiste ritorna l’immagine, in caso contrario anche se il ritratto è chiara-mente un Goya non viene dato come risultato. Non viene quindi interrogata l’immagine, ma solo l’etichetta alfanumerica associata ad essa. Sicuramente l’utilità di Google nell’annullamento delle di-stanze è fondamentale, ma rimangono molte differenze tra questo modo e il “nostro” modo di conoscere il mondo.

Il Semantic web nasce quindi dall’esigenza di colmare questo gap, e in particolare ha lo scopo di eseguire interrogazioni infor-matiche basate su concetti (conoscenza) aventi vari livelli di sinte-si (granularità). C’è bisogno quindi di strumenti informatici che rendano possibile, almeno parzialmente, l’esecuzione informatica di interrogazioni concettuali (Figura 5.19).

Portiamo qui due esempi utili alla comprensione di quanto af-fermato.

Esempio 1: estrazione dei pazienti cardiopatici. Ricordiamo che solitamente la classificazione di un paziente è a granularità più det-tagliata. In una ricerca SQL-like chiederemmo: estrai tutti i pazienti che hanno colesterolemia maggiore di TOT (con tutti i limiti di un’affermazione di questo tipo).

Esempio 2: interrogazioni semantiche di basi di bioimmagini. Al momento la ricerca Google-like di ‘fegato’ porterà a cercare nelle etichette delle immagini questa parola.

5.3.2 La situazione attuale

L’ambizione è forte e gli strumenti disponibili non sono molti. Ad oggi siamo fuori dal mercato, ancora in una fase di ricerca di solu-zioni possibili.

Secondo il SemanticWeb forHealthCare and Life Sciences In-terestGroup [W3C, 2007] il successo in questa sfida è legato alla creazione di un sistema semanticamente ricco e alla interoperabilità tra processi e informazioni. Ad esempio, per la bioinformatica, una raccolta dati con data entry obiettivamente cooperante.

Fondamentale appare da subito la collaborazione: è necessario in-fatti utilizzare parecchi strumenti, difficili da usare con un mercato non immediato: ecco il perchè della creazione nel consorzio W3Cdel SemanticWeb forHealthCare andLife Sciences InterestGroup[W3C, 2006], il cui scopo è quello di aumentare la collaborazione, la ricerca, lo sviluppo e l’adozione di tecnologie innovative nel mon-do dell’health care e della life-science industry.

La chiave del successo nel campo dell’Health Care è rappresenta-to dall’implementazione di nuovi modelli informatici che uniscano molte forme di informazioni mediche e biologiche, attraverso una codifica, una catalogazione dei significati dei dati e della loro in-terpretazione. Dietro a tutto questo c’è il significato di ontologia, inteso come modello che consente di implementare una comunica-zione tra macchine. Concentrandosi sulla semantica relativa all’in-formazione, i ricercatori potranno avere un migliore accesso alla conoscenza necessaria a trovare cure efficaci per le malattie, mentre il personale medico disporrà di strumenti più adatti per curare indi-vidualmente ciascun paziente.

5.3.3 Applicazioni del web semantico nell’Health care

L’ActiveSemanticElectronicMedicalRecord (ASEMR) [Sheth et al., 2006] utilizza le tecnologie del web semantico per ridurre gli erro-ri medici, aumentare l’efficienza tramite un’accurata compilazione delle cartelle cliniche, migliorare la sicurezza del paziente e il suo giudizio verso chi lo ha in cura. L’ASEMR è attualmente utilizzato nella gestione dei dati di tutti i pazienti nell’AthensHeart Center (Athens, Georgia) dal dicembre del 2005.

BioDASH [Neumann et. al, 2006] è un prototipo di un DrugDevelopmentDashboard (gruppi di dati che si concentrano sui prin-cipali indicatori, in questo caso farmacologici) che associa malattie, composti, stadi di sviluppo del farmaco, e la conoscenza relativa ai pathway per un gruppo di utenti. Dal momento che queste infor-mazioni di solito risiedono in diversi server in differenti gruppi di ricerca e sviluppo, la scommessa è quella di non costruire un nuovo modello di dati ma di organizzare le informazioni che già esistono in un modo semanticamente coerente.

HealthCyberMap [Boulos et. al, 2002] è un applicativo svilup-pato dal CentreforMeasurementandInformationinMedicine del-la City University di Londra allo scopo di costruire un Resource Description Framework (RDF) metadatabase relativo alle risorse riguardanti in generale la salute basato sul Qualified Dublin Core Metadata/Set [Dublin Core, Metadata Initiative, 2002].

Speghiamo meglio di cosa si tratta: l’RDF metadatabase rappresen-ta l’anticamera dell’ontologia essendo una particolare applicazione XML che standardizza la definizione di relazioni tra informazioni ispirandosi ai principi della logica dei predicati. È una raccoman-dazione W3C per i metadati, con un maggior potere dell’XML, in quanto può rappresentare le relazioni. La base dell’RDF è costituita da triplette Oggetto-Attributo-Valore o Soggetto-Predicato-Og-getto (ad esempio, Mario è paziente); è possibile inoltre esprimere relazioni come subClassOf o subPropertyOf. [Boulos et. al, 2002] I metadati sono invece informazioni, generalmente strutturate in campi prefissati, relative a ‘documenti primari’ sia testuali che fat-tuali. Per ‘documento primario’ qui intendiamo riferirci ad un og-getto organizzato e strutturato, sia che consista in un testo scritto (un libro, ma anche una legge, un’articolo, una pubblicazione, ecc.) sia che abbia forma di un archivio (elettronico o meno), contenente informazioni di qualunque natura. I metadati sono quindi le infor-mazioni che descrivono, in modo più o meno dettagliato, la forma ed il contenuto dell’oggetto cui si riferiscono. La funzione dei me-tadati è permettere (o comunque facilitare) il raggiungimento dei seguenti obiettivi:• ricerca, ovvero saper individuare l’esistenza di un documento

primario;• localizzazione, ovvero poter rintracciare una particolare versio-

ne del documento primario;• selezione, ovvero analisi, valutazione e filtro di una serie di

documenti primari senza dover accedere al loro contenuto;• interoperabilità, ovvero poter eseguire una ricerca in ambiti

disciplinari diversi, grazie a una serie di equivalenze fra termini che descrivono l’oggetto (descrittori e thesaurus);

• gestione delle risorse informative, ovvero poter gestire le rac-colte di documenti primari grazie a strumenti come banche dati o cataloghi;

• validità, ovvero ottenere informazioni sulla effettiva disponibi-lità del documento primario.

Il Dublin Core Metadata Set [Dublin Core Metadata Initiative, 2002] è un insieme di metadati costituito da 15 elementi che ha lo scopo di facilitare la ricerca di risorse elettroniche. Il progetto del Dublin Core si è sviluppato in ambito “On line Computer Li-brary Center” (OCLC), la grande rete di servizi statunitense per le biblioteche. Nel marzo 1995 si è tenuta una conferenza nella città americana di Dublin (Ohio), alla quale i partecipanti – bibliote-cari, archivisti, editori, ricercatori e sviluppatori di software, oltre ad alcuni membri dai gruppi di lavoro dell’“Internet Engineering

Task Force” (IETF) – hanno convenuto sulla necessità di creare un insieme di strumenti condivisi per l’accesso alle risorse digitali. Lo scopo era quello di stabilire un insieme base di elementi descritti-vi che potessero essere forniti dall’autore o dall’editore dell’oggetto digitale, inclusi in esso o da esso referenziati. Il consorzio di utenti che si è costituito ha incominciato così a sviluppare un’architettura per i metadata che venisse incontro alle necessità dei venditori e dei produttori di informazioni.I 15 elementi sono:1. Titolo (Title)2. Creatore (Creator)3. Soggetto (Subject)4. Descrizione (Description)5. Editore (Publisher)6. Autore di contributo subordinato (Contributor)7. Data (Date)8. Tipo (Type)9. Formato (Format)10. Identificatore (Identifier)11. Fonte (Source)12. Lingua (Language)13. Relazione (Relation)14. Copertura (Coverage)15. Gestione dei diritti (Rights)

Tra gli strumenti usati da Health cybermap per quanto riguarda i linguaggi di progettazione di ontologie riveste una cera importanza Protégé, supporto che permette agli utilizzatori di sviluppare un’on-tologia di dominio, creare secondo le proprie esigenze delle tecniche di acquisizione di conoscenza e inserire nell’ontologia la struttura del dominio e le istanze.

Tutto ciò è stato esteso con un plug-in molto utile come UMLS tab [Li e Shilane, 2006]. Quest’ultimo permette di effettuare del-le ricerche sul National Library of Medicine’s Unified Medical Language System e arricchire la propria ontologia sviluppata con Protégé con termini, sinonimi, relazioni e altre informazioni prove-nienti dalla UMLS (Figura 5.20).

Protégé è stato appunto usato come editor per costruire l’RDF. Gli utilizzatori possono aggiungere nuovi metadati per costruirsi il proprio database e, grazie al plug-in UMLS tab, possono effetture ricerche basate sui concetti che meglio descrivono una risorsa. L’uti-lizzo dell’RDF quindi fornisce un’ontologia di facile impiego che sia da supporto per lo scambio di conoscenza tra macchine. Ad oggi il

Web descritto da metadati RDF viene considerato come una base di conoscenza, quindi le tecniche di rappresentazione di conoscenza vengono applicate ai metadati RDF.

Appare comunque chiara anche in questo caso l’importanza che ha l’utilizzatore la cui esperienza risulta fondamentale nell’utilizzo ottimale di questa base di conoscenza. In quello che potremmo de-finire ancora un cantiere di costruzione, il livello di coinvolgimento richiesto all’utente è ancora importante.

Analisi delle esperienze descritteDalle applicazioni del web semantico viste possiamo dedurre alcune considerazioni. Le esigenze da cui nasce il Semantic Web portano a delle conseguenze che possono essere riassunte in due punti, corri-spondenti ad altrettanti strumenti necessari per poter effettivamente avvicinarci alla costruzione di interrogazioni concettuali; sentiamo quindi l’esigenza di possedere:1. Metodi di descrizione/etichettatura dei contenuti specifici

medici, organizzati per la conoscenza bibliografica, come per esempio accade con i 15 elementi di metadati del “Dublin Core” composti seguendo metodi e/o usando arnesi che sia-no il più monumentalmente robusti possibile (UMLS, XML), senza tuttavia trascurare l’utilità di – anche piccole – ontologie di dominio che consentano risultati quali “Automatic topic indexing tools. Nonostante gli aiuti che questi strumenti semi-automatici possono fornire non permettono di sostituire la ca-talogazione fatta dall’operatore umano [Boulos et al., 2002].

2. Scavatori dei contenuti, anche generici, che ne misurino la distanza rispetto a delle chiavi alfanumeriche che è respon-

Figura 5.20Esempio di uso del plug-in UMLS Tab per stringa di ricerca “breast cancer.” Adattato da [Li e Shilane, 2006]

sabilità dell’utente ritenere rappresentative dei contenuti dei quali è alla ricerca (e’ il metodo di Google). Questi scavatori dovranno ampliare la base di indagine estendendola ai filmati (YouTube) e ad altre grandezze (E-bay) opportunamente di-chiarate dal loro generatore (e quindi non soltanto da un loro classificatore che interviene solo successivamente alla genera-zione).

5.3.4 Google o UMLS?

Quanto detto ci porta nella realtà a riflettere su che strumento con-venga utilizzare in una specifica applicazione. In altre parole, mi conviene la ricerca per chiavi alfanumeriche operata da Google, ma-gari fatta più volte o reindicizzare UMLS ogni volta?

Se utilizzo UMLS ho un grande vantaggio, in quanto mi ap-poggio a una conoscenza fortemente strutturata. Il rischio è che l’utilizzatore non possieda fino in fondo questa conoscenza e non la utilizzi appropriatamente. Se utilizzo Google mi appoggio a una conoscenza strutturata certamente, ma in termini di mercato. Tut-tavia la scoperta di contenuti, siano anche questi generici, non è da sottovalutare nel nostro ambito. Andando oltre Google, ci sono strumenti che già ora permettono una flessibilità di ricerca maggiore ma orientata a uno specifico ambito spesso commerciale, come E-bay.

Quindi entrambi questi strumenti sono utili pur rappresentando approcci diversi alla gestione della conoscenza.

5.3.5 Prospettive

Concludiamo ricordando alcuni dei possibili sviluppi futuri del Se-mantic Web.

Possiamo distinguere tre possibili applicazioni di sicuro interesse:1. Estensione del web semantico ai filmati (con particolare atten-

zione al ‘fenomeno’ YouTube).2. Creazione e utilizzo di strumenti semipronti, che permettano

ad esempio di effettuare una interrogazione Google-like sulle cartelle cliniche di un dato ospedale.

3. Impiego in strumenti che facilitino la scelta del luogo più adatto in cui effettuare una certa visita o fare un certo prelie-vo. Ad esempio, fornire la possibilità di consultare una lista di laboratori che effettuano un certo esame in una data zona e il costo correlato.

5.3.6 Conclusione

I motori di ricerca che indicizzano le pagine HTML trovano certa-mente risposte alle ricerche lavorando su un’enorme quantità di in-formazioni, ma poi rispondono con molti risultati non appropriati. Vanno quindi sfruttati come ‘scavatori’ di contenuti, consapevoli dei limiti che questi strumenti hanno. Una ‘ricerca di conoscenza’ più vicina a quella umana (anche se comunque realizzata tra mac-chine) soprattutto nel campo dell’Health Care potrà essere svilup-pata combinando i motori di ricerca con motori che possiedono capacità di ragionamento, che da soli soffrono dell’impossibilità di rovistare in una massa di dati molto ampia e spesso intrecciata e confusa.

5.4 Applicazione dei sistemi valutativi: il sistema di tracciabilità dei farmaci

5.4.1 Introduzione

Si introducono in questo capitolo i sistemi di monitoraggio per la salute e si riporta come esempio il sistema di tracciabilità dei farma-ci recentemente attivato dal Ministero della Salute [Bergamaschi et al., 2005]. È estremamente importante capire come la definizione, la progettazione e l’utilizzo dei sistemi di monitoraggio siano condi-zionati dall’esistenza di relazioni tra i sistemi progettati per monito-rare e i sistemi da monitorare sottostanti stessi.

I sistemi sottostanti sono tutti i componenti coinvolti nella rea-lizzazione del core process attraverso l’implementazione di sistemi informativi. Esempi sono gli ospedali che generano lettere di dimis-sione: dobbiamo ricordare che i sistemi informativi sanitari possono essere classificati in più categorie. Sistemi di supporto che fornisco-no assistenza sanitaria (che qui definiremo Sistemi Informativi Sa-nitari Standard), sviluppati inizialmente per gestire le attività ammi-nistrative. Sin dalla loro introduzione, i sistemi informativi sanitari hanno migliorato l’efficienza e l’efficacia di alcuni processi chiave, hanno subito una forte evoluzione e, oggi, sono considerati la strut-tura portante del sistema sanitario. Questi sistemi hanno a che fare con le attività ospedaliere quotidiane come le analisi di laboratorio a gli esami radiologici, che esistevano già ben prima dell’introduzione dei sistemi informativi ma la cui gestione è significativamente mi-gliorata grazie all’introduzione delle tecnologie informatiche.

Diversamente, l’introduzione dei servizi legati alla telemedicina, il secondo sistema che qui definiremo Sistema Informativo Sanita-rio Innovativo, è strettamente legata allo sviluppo delle tecnologie informatiche in sanità. Quando parliamo di telemedicina ci riferia-mo per esempio ai servizi di homecare cioè applicazioni ICT per il monitoraggio dei pazienti a distanza. Come mostrato in Figura 5.21, i sistemi informativi sanitari standard a quelli innovativi sono il cuore dell’intero sistema.

Al di sopra di questi servizi centrali, come mostrato in Figura 5.21, c’è un’infrastruttura che consente non solo la loro comuni-cazione ma anche l’integrazione con il governo centrale cioè servizi volti a migliorare quello che è effettivamente necessario al sistema sanitario stesso che possiamo definire “continuità di assistenza”. Es-sendo il paziente responsabile delle richieste di interrogazione dei dati personali e del loro mantenimento, egli è l’effettivo elemento di integrazione. L’intero processo è prolungato nel tempo e oneroso:

la richiesta e l’ottenimento dei dati clinici personali non è né sem-plice né rapido. Consideriamo l’esempio di un paziente ammesso in un ospedale X: per assicurargli la corretta continuità di assistenza si suppone che egli trasporti la sua cartella clinica eventualmente ottenuta durante un ricovero in un ospedale Y. In un mondo in cui aumenta la cronicità delle patologie, la presenza di sistemi in grado non solo di gestire i processi ma anche di assicurare l’integrazione delle informazioni è sicuramente un valore aggiunto.

Quando parliamo di tecnologie informatiche in medicina, dob-biamo citare quello che viene definito “paradosso tecnologico” [Vi-neis e Dirindin, 2004]. Mentre l’introduzione delle tecnologie por-ta tradizionalmente alla riduzione dei costi di produzione e quindi permette di fornire gli stessi servizi a costi ridotti, ogni volta che una nuova tecnologia viene introdotta in sanità i costi aumentano in maniera significativa visto che questo implica l’introduzione di nuovi trattamenti. Se consideriamo questo aspetto diventa evidente come lo sviluppo di una struttura di integrazione consenta di gesti-re le informazioni provenienti da diverse sorgenti senza errori (per esempio nella prescrizione di medicinali) e di superare il paradosso tecnologico.

La parte superiore dello schema in Figura 5.21 rappresenta il Si-stema di Monitoraggio della Salute, una sorta di Data Warehouse. Questi sistemi sono stati progettati non per supportare l’attività di gestione dei dati dei lavoratori ma quella del governo centrale con l’obbiettivo di:• supportare il processo decisionale;• acquisire conoscenza sul Sistema Sanitario Nazionale;• verificare i principi su cui si basa il Sistema Sanitario Nazio-

nale.Consideriamo la Figura 5.22. Diversi paesi, come il Regno Unito, hanno adottato un sistema in cui l’utilizzo dell’IT deve essere capil-

Figura 5.21Relazione tra i sistemi di monitoraggio e i sistemi monitorati

Sistema Informativo Sanitario Standard

Nuovo Sistema Informativo Sanitario

Continuità assistenziale

Sistema Informativo Sanitario

Innovazione

Bisogni

Governo centrale

Ospedali e strutture simili

lare e completamente introdotto nel processo e, in questo modo, fornire automaticamente al sistema i dati necessari. (Figura 5.22a). Questo approccio, in cui il governo definisce quali dati il sistema deve trasmettere, può difficilmente essere fattibile. In Italia l’ap-proccio applicato (Figura 5.22b) per raccogliere i dati delle lettere di dimissioni degli ospedali (SDO) [Ministero della Salute, 2007] è stato diverso. Dal momento in cui sono state introdotte le lettere di dimissione (nel 1991), gli ospedali, dal punto di vista tecnico, non erano in grado di generare e trasmettere elettronicamente questi dati. Se il Sistema Sanitario Nazionale avesse atteso che gli ospedali fossero pronti a sottoscrivere il progetto, non avrebbe mai ottenuto i risultati sperati. Invece, il governo centrale ha definito il set minimo di dati che gli ospedali erano pronti a trasmettere. Lo scopo era di caricare i dati richiesti in un sistema centrale che collegasse gli ospe-dali con il Ministero della Salute. Questo serviva, inoltre, per acce-lerare l’introduzione dell’IT negli ospedali. Questo esempio spiega quello che in Figura 5.22b è definito “Modello Bidirezionale”: si stabilisce così un circolo virtuoso (Figura 5.23).

È comunque importante per il sistema di monitoraggio naziona-le stimare la reale capacità a la puntualità della periferia nel trasmet-tere i dati. Non si intenda il termine “periferia” però come nel lin-guaggio comune. Quando diciamo “periferia” , ci riferiamo a tutti quei componenti del sistema che generano i dati e li trasmettono al

Figura 5.22Miglioramenti del sistema a) Primo

modello semplificato, b) Modello Bidirezionale

Figura 5.23Il circolo virtuoso:

interazioni sistema di monitoraggio – sistemi

monitorati

Sistema informativo sanitario standard

Sistema di monitoraggio della

salute

Sistema informativo sanitario standard

Sistema di monitoraggio della

salute

Il sistema di monitoraggio analizza la periferia sulla base

dei dati disponibili

Il sistema di monitoraggio identifica un insieme di dati che vanno trasmessi dalla periferia al sistema centrale in accordo

con le loro possibilità

La periferia predispone strumenti di ICT per soddisfare le richieste del livello

centrale

Grazie alle innovazioni tecnologiche la periferia genera e trasmette i nuovi flussi

di dati

governo centrale. Quando ci riferiamo ai dati delle SDO, i sistemi periferici sono tutti gli ospedali che generano le lettere di dimissione e le trasmettono. Per capire esattamente cosa si intende per “perife-ria”, si osservino le Figure 5.24 e 5.25.

Introduciamo quindi il sistema di tracciabilità dei farmaci. In questo caso gli elementi della periferia sono tutti componenti della catena di produzione e distribuzione dei farmaci. Più precisamente, i produttori, gli agenti, i venditori e i farmacisti o gli ospedali dalla periferia del sistema.

5.4.2 Il sistema di tracciabilità dei farmaci

Prima di entrare nello specifico del funzionamento del sistema di tracciabilità dei farmaci, dobbiamo definire quali sono gli attori coinvolti nell’intero sistema: l’Istituto Poligrafico Zecca dello Stato

Figura 5.24Lo Stato e la Periferia

Figura 5.25Componenti della periferia

La periferia Lo Stato

Sistema informativo sanitario

Sistema Sanitario Nazionale

Sistema di monitoraggio della salute

Lo Stato

La periferia

• Decide quail flussi di dati debbano essere generati

Raccoglie Elabora i dati

Genera i dati

(IPZS), il cui ruolo verrà chiarito più avanti, e tutti i membri della catena di produzione e distribuzione dei farmaci (più precisamente identifichiamo i produttori, gli agenti, i commercianti, le farmacie o gli ospedali).

Perchéc’èbisognodiunsistemadiindividuazioneetracciabilitàdeifarmaci?

La prima risposta è quella di poter risolvere il problema delle contraffazioni, ma non solo. Quando il sistema è stato implementa-to, i vantaggi sono risultati subito numerosi.

La contraffazione dei medicinali è un problema molto diffuso, non solo in Italia, ma in molti altri paesi. Questo fenomeno è stato riscontrato inizialmente in seguito a furti di materiale e, da quanto l’IT è parte della vita quotidiana, si è diffuso con l’uso del web. Ognuno di noi riceve quotidianamente via web molte pubblicità di prodotti che, spesso, nascondo una frode.

Un altro fenomeno per cui è stato necessario stabilire un sistema di tracciabilità dei farmaci è quello dello smaltimento dei medicinali scaduti. Già nel 1983 il Parlamento Europeo e il Consiglio Direttivo, con la Normativa 2001/83/CEE [Parlamento Europeo, 2001], defi-niscono la necessità di tracciare l’intero processo dal produttore fino al consumatore finale con l’obbiettivo di garantirne sicurezza e qua-lità. È ora evidente che questo sistema è di grande interesse non solo per il Ministero della Salute ma anche per il Ministero delle Finanze.

Con l’emanazione di leggi nazionali (Legge 39 dell’1 marzo 2002 [DL, 2002] e Decreto Ministeriale del 15 luglio 2004 [DM, 2004]) è stato lanciato il progetto di “Monitoraggio delle confezioni di far-maci all’interno del sistema di distribuzione”.

5.4.3 Il sistema di identificazione: il primo obiettivo

Il sistema ha lo scopo di identificare univocamente sia la confezione del medicinale sia gli attori coinvolti nel processo (Figura 5.26). L’identificazione univoca è basata su:

Codice di Autorizzazione di Immissione in Commercio (A.I.C.) del medicinale: è il codice rilasciato dall’Agenzia Italiana del Far-maco (AIFA). Il codice A.I.C. identifica univocamente non solo il principio attivo ma anche il tipo di confezione, per esempio una confezione da 20 pillole. L’etichetta in uso prima del 2001 contene-va già il codice A.I.C.: fu introdotto l’1 gennaio 1992 [DL, 1991] per registrare i farmaci in commercio.• Nome identificativo del farmaco• Proprietario del codice A.I.C. o rappresentate legale per pro-

prietari stranieri

• Numero progressivo di identificazione della singola confezio-ne del prodotto.L’identificazione degli attori coinvolti si basa su un codice identi-

ficativo (ID), gestito da un registro centrale (Figura 5.27).È importante sottolineare che solo dopo l’introduzione dell’eti-

chetta a due codici nel 2001 si è riscontrato un netto decremento nel numero di frodi.

L’Istituto Poligrafico Zecca dello Stato (IPZS) è stato incaricato non solo di produrre le etichette a doppio codice ma anche di di-segnare l’interno progetto. L’obbiettivo era semplice e, allo stesso tempo, ambizioso: la singola confezione di un medicinale doveva essere identificabile in qualsiasi momento e in qualsiasi punto della catena di produzione e distribuzione. Questo implica:

La presenza di un database centrale accessibile dai diversi utenti in qualsiasi momento. L’obbligo per tutti gli attori del sistema, per ogni carico e scarico di merce, di trasmettere in tempo reale “alme-no” i dati necessari: il codice del carico e il codice identificativo di chi invia e di chi riceve la merce.

In questo modo, ogni singola confezione di medicinali sarebbe stata identificabile nei confini nazionali in qualsiasi momento anche durante le fasi di trasporto. Al di là degli studi di fattibilità effettuati dall’ IPZS, due problemi risultavano di difficile soluzione:

Figura 5.26Identificazione delle confezione di medicinale

Figura 5.27Catena di produzione e distribuzione dei farmaci

Codice AIC

Codice progressivo identificativo

Denominazione del farmaco

Possessore AIC

L’obbligo di leggere i codici di ogni singola confezione durante il caricamento e lo scaricamento della merce non risultava fattibile per gli attori che lavorano con grandi quantità di medicinali. Men-tre i farmacisti, che lavorano generalmente con piccole quantità di prodotti, non avrebbero avuto particolari problemi nel passaggio dall’etichetta con uno a quella con due codici, gli agenti e i com-mercianti non erano invece pronti a intraprendere un tale cambia-mento. Per rendere l’idea dei tempi richiesti a digitalizzare le eti-chette di grandi quantità di materiale, consideriamo l’esempio di un pallette (Pallette EUR-EPAL © standard, 80 cm x 120 cm x 12 cm) di pacchi di confezioni da 20 pillole di un comune medicinale. Con riferimento ai dati riportati nella tabella 5.7 è evidente perché gli agenti e i commercianti abbiano rifiutato un tale progetto: 10 pacchi di confezioni di medicinale avrebbero richiesto circa 35 ore per la scansione!

Confezione di medicinaleV = h × l × p = 260,4 × 10-6 m3

p =circa 90 gr.

EUR Pallet Support V = 80cm × 120cm × hConsiderando h = 120 cm (cioè 20 vol-te l’altezza di una singola confezione)

V = 80cm × 120cm × 112cm

Numero e peso delle confezioni con-tenute

4.160 confezioni per un peso di 374.4 kg

Tempo richiesto per scannerizzare 4.160 confezioni

t = 12480 secondi = 3 ore e 28 minuti

Tempo richiesto per scannerizzare 10 volte la stessa quantità 34 ore e 40 minuti

La necessità di sincronizzare il database centrale che doveva essere consultabile in qualsiasi istante (24 ore al giorno, 7 giorni a set-timana) da diversi utenti. Ricordiamo che ci sono più di 17.100 farmacie in Italia. Se supponiamo che ciascuna farmacia trasmetta i dati in tempo reale, l’attività commerciale quotidiana diventa di-pendente dalle performances del database centrale, un sistema che non dipende da noi. È evidente che molti degli attori coinvolti nel progetto non fossero pronti ad affrontare queste conseguenze.

5.4.4 Le semplificazioni introdotte

Appare evidente che, a causa dei contrasti tra il governo (con lo scopo di ridurre le contraffazioni di medicinali) e gli altri attori della catena (tipicamente i produttori e i commercianti, con lo scopo di portare avanti le proprie attività commerciali senza ostacoli), il pro-

Tabella 5.7Stima dei tempi

richiesti per scannerizzare grandi

quantità di confezioni di medicinali

getto fosse destinato a fallire. Ancora una volta abbiamo visto come senza coinvolgere i livelli sottostanti del sistema durante la proget-tazione delle specifiche, nessuna possibilità di successo sia garantita.

Il passo successivo è stato quello di analizzare le richieste e le ne-cessità di tutti gli attori del sistema. La bolla di consegna sembrava essere la soluzione ottimale.

Tutti gli attori del sistema, dai produttori ai farmacisti, anche i meno esperti di tecnologie informatiche, erano già in grado di rea-lizzare bolle di consegna in forma elettronica. Queste contengono informazioni su chi spedisce e riceve il materiale, il codice A.I.C. del farmaco, la quantità e la data di scadenza. Non contiene il codice progressivo identificativo del farmaco.

Una seconda decisione è stata presa per aiutare gli attori a com-pilare le richieste: l’obbligo di trasmettere i dati durante il trasporto è stato rimosso. Gli attori perciò trasmettevano i dati (la bolla di consegna) solo prima dello scaricamento, una volta al giorno. Con l’introduzione di queste due misure entrambi i problemi precedenti sembravano essere risolti: invece di leggere i codici di ogni singola confezione di medicinale gli attori dovevano solo trasmettere gior-nalmente la bolla di consegna, il caricamento dei dati da trasmette-re, quindi, non era più necessario e l’impedimento della sincronicità del database centrale fu risolta: il sistema è diventato asincrono.

Se consideriamo la struttura dell’intero sistema dell’IPZS, la ca-tena di produzione e di distribuzione e il progetto di tracciabili-tà semplificato, possiamo facilmente modellare il processo con un diagramma UML. Si è deciso di utilizzare due Activity Diagrams per modellare il percorso dei codici (Figura 5.28) e il percorso del farmaco nella catena di produzione e distribuzione (Figura 5.29).

Figura 5.28UML Activity Diagram della costruzione del codice

Una volta che furono stabilite le nuove modalità (alla fine del 2004), la trasmissione dei dati sarebbe dovuta iniziare il prima possibile, lasciando solo il tempo a tutti gli attori coinvolti di standardizzare la bolla di consegna in formato elettronico. Il decreto che defini-va ufficialmente le regole per la trasmissione dei dati fu pubblicato sulla Gazzetta Ufficiale nel Gennaio del 2005 e lasciava sei mesi di tempo per la standardizzazione. Nel giugno del 2005, furono trasmessi i primi dati. Dal primo di ottobre del 2005, il database centrale conteneva già l’80% dei due miliardi di medicinali presenti sul mercato italiano.

La struttura dei dati contenuta nel database centrale è mostrata in dettaglio nello schema in Figura 5.30.

5.4.5 Analisi dei dati raccolti

La prima trasmissione di dati fu nel giugno del 2005. Da quel momento in avanti, i numeri relativi al progetto sono (all’ottobre 2008):

• Produttori: 243• Agenti: 248• Venditori: 491• Farmacie: 17.214• Ospedali: 1.424 pubblici e 1348 privati

Figura 5.29UML Activity Diagram

del percorso del farmaco

• Negozi: circa 300Il numero di movimenti tracciati è in media di 2,7 milioni al gior-no. Quello che si ottiene è una grande mole di dati, un database molto semplice ma estremamente popolato, con numerose possibi-lità di utilizzo dei dati che si allontanano dallo scopo iniziale di anti-contraffazione. Infatti, per effettuare controlli efficienti in questo ambito, il numero progressivo della confezione di farmaco doveva essere trasmesso insieme al codice A.I.C. In questo modo, un con-fronto tra il materiale acquistato e quello venduto poteva fornire indicazioni su eventuali irregolarità.

Consideriamo l’esempio di una farmacia: i dati di vendita sono facilmente ricavabili dal database centrale che abbiamo precedente-mente descritto. Da quando il commercio dei medicinali venduti sotto prescrizione medica è monitorato, possiamo anche ottenere i dati relativi alle vendite.

È importante ricordare che i farmaci più costosi possono essere venduti solamente sotto prescrizione medica. Se ci sono significative differenze tra gli acquisti e le vendite, anche se riguardano solo il commercio dei farmaci con prescrizione, non siamo in grado di rile-vare una truffa, ma abbiamo sicuramente bisogno di conoscere più a fondo l’irregolarità. Comparando il totale di farmaci veduti con la popolazione che si rivolge a una determinata farmacia possiamo stimare la media nel consumo di quel farmaco e segnaliamo i casi in cui il consumo è maggiore. Non siamo sicuri che si tratti di una frode, o di un medico generico che effettua un numero eccessivo di

a a a b b b

Dati disponibili ai vari livelli:

C A N A L E D I U S C I T A

Dati di vendita (quantità ) 1

Sprechi produttivi Dati di vendita (quantità )

Dati di vendita (quantità )

Dati di vendita (quantità + ammontare solo per le aziende del sistema sanitario nazionale)

Numero di etichette consegnate ai roduttori per AIC (quantità)

Nota 1: quantità di AIC x ricevitore - trasmissione in 24 ore

Nota 2: quantità di AIC x regione ricevente - trasmissione mensile

1Dati della catena di distribuzione, furti, distribuzioni, rimozioni (quantità )Cittadini

Venditori

Depositi

COMPAGNIE FARMACEUTICHE

Produzione nazionale Produzione paesi stranieri

Farmacie nazionali

Aziende sanitarie

NPIProduzione etichette

Figura 5.30Struttura del modello

prescrizioni, ma sappiamo che bisogna analizzare il fenomeno più a fondo.

Come detto precedentemente, i dati raccolti offrono un vasto range di possibili applicazioni. Una ricerca dell’”Università degli Studi di Napoli Federico II” mostra diversi aspetti del mercato dei farmaci in Italia. Se ne riporta un esempio nella tabella seguente (Tabella 5.8):

Principio attivo Quantità di confezioni (x1000)

Ammontare (€x1000)

B03XXXX 2.315 106.439 L01XXXX 38 93.262 J05XXX 179 70.612

Analizziamo le variabili presenti.Possiamo vedere come, nonostante il cambiamento considerevole

nel numero di confezioni vendute (da 38 a 2.315), la variazione totale delle vendite non è così significativa. Emerge quindi l’evi-denza di tracciare i medicinali più costosi, in modo da evidenziare se questi siano o meno correttamente utilizzati. Questo significa certificare sia la sicurezza del medicinale che l’idoneità all’uso: la medicina deve essere utilizzata solo per le patologie indicate. Se que-sto non accade, oltre a costituire un pericolo per la salute, lo Stato deve far fronte a spese inutili. Sicuramente, se i medicinali devono essere tracciati per controllarne la spesa, bisogna cominciare dai più costosi.

In Figura 5.31 vediamo che altri dati sono disponibili come il prezzo a cui i medicinali vengono acquistati. Sappiamo che le far-macie possono effettuare uno sconto del 5% ma se consideriamo

Legenda

Prezzo Regionale < Prezzo Medio Italiano

Prezzo Regionale > Prezzo Medio Italiano

Numero totale di confezioni: 362.852Quantità: 5.464.000 €Prezzo Medio al SSN = 15 € Prezzo di vendita 2005 = 35,11 €

Figura 5.31Analisi dei prezzi medi

per codice A.I.C.

Tabella 5.8I farmaci più costosi

per il Sistema Sanitario Nazionale

l’esempio in figura vediamo come il Sistema Sanitario Nazionale può fornire medicinali ad un prezzo considerevolmente più basso, con il 57% di sconto (valore medio) rispetto al prezzo segnalato: il canale diretto di rifornimento, quindi, dovrebbe essere preferito rispetto alle farmacie. La figura mostra inoltre le significative diffe-renze regionali per lo stesso A.I.C.

Possiamo per esempio facilmente notare come il prezzo per lo stes-so medicinale vari del 46% tra la Toscana e la Calabria. È evidente che i miglioramenti nell’approvvigionamento dei farmaci non sono solo necessari ma fattibili. Lo Stato dovrebbe intervenire determinando il prezzo massimo di ogni A.I.C., spingendo in questo modo le regioni verso metodi di approvvigionamento più convenienti.

Abbiamo mostrato le spese nazionali per i medicinali e l’analisi dei prezzi medi per regione ma sono comunque possibili altre analisi. Possiamo analizzare il consumo di farmaci per regione, la media di consumo per migliaia di abitanti in una particolare regione, il medi-cinale più utilizzato, ecc. E per finire, ma non di minore importanza, possiamo considerare l’idoneità del consumo di medicinali, colle-gando la tracciabilità del farmaco del database centrale con il sistema di monitoraggio delle prescrizioni in modo da poter tracciare l’intero percorso del medicinale dal produttore al paziente.

5.4.6 Possibili sviluppi futuri

Alcune soluzioni tecnologiche sono state proposte per l’identifica-zione di ogni singola confezione di farmaco, prima di tutto l’Identi-ficazione a Radio Frequenze (RFID).

La tecnologia RFID usa onde radio per identificare e tracciare gli articoli: il lettore comunica con un microchip inserito in un’etichet-ta che contiene le informazioni in forma digitale.

La tecnologia RFID non richiede la scannerizzazione per ogni singola confezione ma consente di leggere numerosi oggetti con-temporaneamente senza necessità di direzionare il codice in modo da poter risparmiare una notevole quantità di tempo. Ricordiamo che la U.S. Food and Drug Administration ha supportato e inco-raggiato l’uso della tecnologia RFID come mezzo per contrastare le contraffazioni e migliorare la sicurezza dei pazienti [FDA, 2004]. I produttori di medicinali stanno tutt’oggi sviluppando sistemi di tracciabilità interni come deterrente per le truffe. Per esempio la tecnologia RFID è stata utilizzata dall’azienda Pfizer’s per associare un unico numero ad ogni singola confezione di Viagra distribuita negli Stati Uniti. Non è lo Stato che costringe all’identificazione dei medicinali ma lo fanno i produttori stessi. I produttori (e gli

altri attori del sistema) sentono i vantaggi di un tale sistema: oggi sono propensi a collaborare nello sviluppo futuro del progetto di tracciamento dei farmaci. La contraffazione dei farmaci non provo-ca solamente perdite economiche ma rappresenta una minaccia per la salute dei pazienti: i produttori sono estremamente interessanti nello sviluppare sistemi capaci di provare che i loro prodotti non causano problemi ai pazienti che li utilizzano.

5.4.7 Conclusioni

Sebbene i diversi attori del sistema non fossero pronti a sottoscrive-re il progetto prima che ne fossero dimostrati i vantaggi, essi sono attualmente interessati a sviluppare sistemi per il monitoraggio dei farmaci. Durante la progettazione molti sono stati gli ostacoli: gli attori avevano esitato di fronte alla possibilità di introdurre un si-stema che implicasse la supervisione dello Stato, maggiori costi e burocrazia. Comunque, di fronte ai numerosi vantaggi ottenuti una volta che il sistema è stato implementato, è cambiato comple-tamente il loro atteggiamento. Emerge qui la necessità chiave nella progettazione di un sistema di monitoraggio: non considerare solo quali sono i servizi necessari ma quali sono quelli fattibili. In questo modo gli attori periferici saranno pronti a iniziare immediatamente con la trasmissione dei dati e, presto, di fronte ai vantaggi che si possono ottenere, a migliorare le capacità di produrre e trasmettere i dati.

5.5 VistA

5.5.1 Introduzione

In America quella della sanità è una ferita aperta: 46 milioni di cittadini senza alcuna assistenza, un sistema basato su assicurazioni private che dovrebbe essere più efficienti dei sistemi pubblici euro-pei e che invece risulta mediamente più costoso e farraginoso (pur tenuto conto di molte aree di eccellenza assoluta). Non mancano né le tecnologie specifiche per la sanità, né le aziende che si sono spe-cializzate in questo campo ma nessuno, fin qui, è riuscito a creare un sistema di banche dati e a metterle online, in un sistema, come quel-lo Usa, frammentato tra mille assicurazioni e varie amministrazioni pubbliche. Il vero problema è economico: per medici e ospedali mettere in rete i dati di un loro paziente significa spendere per creare una banca dati che li priverà di un prezioso «monopolio» informa-tivo, esponendoli alla concorrenza. I benefici andrebbero (gratis) ai pazienti (più prevenzione, meno sovrapposizioni e ripetizioni di esami, attese più brevi, un minor rischio di errori) e al sistema (co-sti più bassi per le assicurazioni e per lo Stato). È qui che arriva il Veterans Informations System and Technology Architecture (Vista), una banca dati pubblica trattata come una cenerentola dalle assicu-razioni private e che invece, creando un «database» di alcuni milioni di pazienti, ha ottenuto risultati straordinari tanto sul piano clinico (soprattutto grazie all’attività di prevenzione sui soggetti a rischio) quanto su quello economico: al netto dell’ inflazione, ogni paziente oggi costa all’Amministrazione dei veterani il 32 per cento in meno di 10 anni fa, mentre a livello nazionale, nello stesso periodo, i costi sono saliti del 50 per cento [Gaggi M., 2007].

La VeteransHealthAdministration (VHA), una delle tre ammini-strazioni presenti all’interno del DepartmentofVeteransAffairs (VA), è il più grande sistema per la salute integrato degli Stati Uniti d’Ameri-ca. Soffrendo, più o meno giustamente, durante gli anni Ottanta e nei primi anni Novanta per un’organizzazione macchinosa caratterizzata da eccessiva burocrazia, inefficienza e mediocrità nelle cure, la VA si è reinventata ed è rinata a partire dal 1995 diventando un sistema modello basato sulla centralità del paziente e su prestazioni ad alto valore e qualità. La riorganizzazione ha previsto cambiamenti strut-turali e gestionali, una razionalizzazione e riallocazione delle risorse e la necessità di dotarsi di una infrastruttura informatica che garantisse il supporto alle necessità sia dei pazienti che dei professionisti. Tutti questi cambiamenti hanno consentito alla VA di affermarsi come lea-der riconosciuto nella cura della salute.

Il Dipartimento dei Veterani fornisce benefici ai militari americani veterani e alle loro famiglie. Il Presidente Lincoln costituì un isti-tuto per i soldati tornati feriti dalla guerra TheNationalAsylumforDisabledVolunteerSoldiers, l’antesignano di VA, nel 1866. Questo divenne The Veterans Administration nel 1930 sotto il Presidente Hoover e fu successivamente elevato a membro del Gabinetto dal Presidente Bush nel 1989 con il nome di U.S.DepartmentofVete-ransAffairs.

Nel 2001, il budget per questo dipartimento è stato di 44 mi-liardi di dollari. Di questi, la VeteransBenefitsAdministration (VBA) amministra 23 miliardi di dollari per pagamenti diretti di pensioni, assistenza educativa e risarcimento danni. La VeteransHealthAd-ministration (VHA) utilizza i 21 miliardi di dollari di budget per gestire il più grande sistema sanitario della nazione. Nel 2001, il Dipartimento dei Veterani ha fornito cure a 4.2 milioni di veterani; più di due terzi di questi erano disabili o persone poco abbienti. In VHA sono approssimativamente impegnati 180.000 professionisti in circa 170 ospedali, più di 800 cliniche, 135 case di cura, più di 200 centri di riabilitazione e altre diverse strutture (Figura 5.32). Inoltre, VHA è il maggiore fornitore nazionale di istruzione uni-versitaria medica e un forte contribuente per la ricerca medica e scientifica. I centri medici VA sono affiliati con più di 152 scuole di medici e dentisti, preparando così più di 80.000 studenti ogni anno. Più della metà dei medici che praticano attualmente la profes-sione negli U.S.A. hanno seguito corsi di formazione negli ospedali dei veterani. VA è il secondo più grande finanziatore per la ricerca biomedica. Inoltre fornisce servizi di assistenza al personale militare attivo nei periodi di guerra e a tutta la popolazione in caso di disa-stri. Per il 2009 la VA riceverà circa 93 miliardi di dollari di cui circa 47 miliardi di fondo discrezionale, gran parte del quale finanzierà il sistema sanitario della VA stessa [Mosquera, 2008].

VHA ha una lunga e affermata storia nell’uso di tecnologie in-The largest single healthcare provider in the US

Provides comprehensive health care to 25 million US military veterans

1300 Site-of-Care including- 173 hospital- 850 clinics- 135 nursing homes- 203 counselling centres, 73 home-care programs

Employs- 15,000 MD- 50,000 Nurses- 33,000 Allied Health Professionals

Figura 5.32Le dimensioni della Veterans

Administration. Fonte: Colin Smith - VicePresident World

Vista, 2006. Adattato da [Smith,

formatiche nel portare avanti i suoi obiettivi; ogni centro ha un elevato grado di informatizzazione. Nel 2003, il Wall Street Journal ha titolato in prima pagina “Nella gestione dei dati clinici, VHA è indubbiamente il leader” [Rundle, 2001]. Per esempio, la docu-mentazione clinica e la sua gestione sono automatizzate a tutti i livelli. Una sofisticata infrastruttura a livello nazionale è stata svi-luppata per l’evoluzione di ogni singolo centro sul territorio. Con lo sviluppo di reti di consulenza intersettoriali e di scambio dati, il sistema informativo di VA denominato VistA è diventato un’impor-tante soluzione a livello nazionale.

5.5.2 Il Sistema Informativo VistA a supporto delle performances

L’efficienza dei sistemi informativi è il prerequisito essenziale per lo sviluppo del progetti di valore in tutti i campi, primo fra tutti quello dell’acquisizione dei dati. Il sistema informativo della Veterans Ad-ministration è ben strutturato per supportare in maniera efficace il percorso di cura dei pazienti. VistA (Veterans Health Information Systems and Technology Architecture) è un sistema di applicazioni software integrate che supporta direttamente l’assistenza ai pazienti della Veterans Health Administration (VHA) e le procedure ammi-nistrative relative.

VistA è l’evoluzione del Decentralized Hospital Computer Pro-gram (DHCP), il primo sistema informativo elettronico delle Vete-rans Hospital Administration, adottato negli anni 80. Il DHCP è ancora il cuore del Sistema Informativo Sanitario nei centri medici. Per riconoscere l’incremento della complessità tecnologica dei siste-mi informativi presenti nei centri medici della Veterans Administra-tion, il termine VistA è stato introdotto nel 1996. Nel 1997, poi, è stata introdotta l’interfaccia grafica per la cartella clinica informatiz-zata del paziente (Computerized Patient Record System – CPRS).

5.5.2.1 La struttura di VistADurante gli anni sono state sviluppate diverse piattaforme har-dware. Inizialmente si è utilizzato Digital Equipment Corporation (DEC) PDPs mentre successivamente, sono stati applicati VAX e il sistema Alpha con il sistema operativo VMS. Alcune applicazioni hanno da subito utilizzato computers Intel in grado di girare in-differentemente su DOS o sul sistema operativo Windows. Alcuni tipi di strumenti UNIX sono stati utilizzati come hosts, ma non in numero elevato. Esiste inoltre una versione Open Source Linux utilizzabile per far girare VistA. La configurazione hardware più co-

mune nei centri medici della Veterans Administration al momento è un inisieme da 1 a 12 processori Compaq Alpha.

Le applicazioni VistA sono costruite su un’infrastruttura comu-ne. Questo approccio ha diversi scopi. Il primo è di integrare le applicazioni al livello del database; i dati comuni vengono così con-divisi e non duplicati. Il secondo è di rendere consistenti le applica-zioni sia dal punto di vista degli utilizzatori che degli sviluppatori. Il terzo è di minimizzare le spese di manutenzione. Infine fornisce un livello stabile tra le applicazioni e i sistemi operativi per aiutare a isolare le applicazioni dai cambiamenti. Le tre componenti chia-ve dell’infrastruttura sono: kernel, FileMan e MailMan [Timson, 1980] e [Johnson, 1981].

Kernel fornisce i servizi di condivisione delle applicazioni, tools per il sistema di gestione e un livello di portabilità tra il sistema operativo sottostante e il codice applicativo. I servizi di condivisione comprendono la gestione della registrazione e della sicurezza, del menu delle applicazioni e degli errori, l’installazione dei software e le funzioni di libreria. Il sistema di gestione permette di ottimizzare i parametri in modo da incontrare tutti i bisogni locali, i reports di stato, le analisi di performances e gli alerts. Esempi possono essere il numero di tentativi di accesso falliti prima dello spegnimento del dispositivo, il tempo di vita delle password, la massima grandezza di documenti, l’assegnazione di elaborazioni sequenziali e il fissaggio di priorità nelle attività.

MailMan è un altro elemento centrale del sistema VistA che af-fonda le sue radici alla fine degli anni Settanta. Il termine MailMan non descrive pienamente tutte le funzionalità di questo componen-te: è un sistema di messaggistica che trasmette mail e alerts, pro-grammi e dati. MailMan fornisce programmi con un API in modo che la messaggistica possa essere facilmente integrata nelle applica-zioni (es: notifica di eventi particolari, report delle mail in uscita).

FileMan è il Database Management System di VistA. Fu svilup-pato alla fine degli anni Settanta e da allora fornisce una piattaforma indipendente per la gestione dei dati. La sua interfaccia molto sem-plice consente un facile accesso ai dati conservati nei diversi centri clinici attraverso la possibilità di effettuare interrogazioni ad hoc. I servizi includono la creazione e la gestione dei file, l’archiviazione e il trasporto dei dati.

5.5.2.2 Le applicazioni di VistaAttualmente VistA è composto da 162 pacchetti applicativi. Di questi, 72 sono applicazioni infrastrutturali, 35 sono applicazioni amministrative e finanziarie e 55 sono applicazioni cliniche. Tutte

lavorano in comune con altri sistemi informativi quali quello del laboratorio, della farmacia, della radiologia, ecc (Figura 5.33). Altre applicazioni di VistA meno comuni negli altri sistemi informativi sono quelle riguardanti la sicurezza, le librerie e il registro dei pa-zienti scomparsi. La descrizione delle singole applicazioni è dispo-nibile all’indirizzo della Veterans Administration www.va.gov/vista [VA, 2004].

Consideriamo invece due delle più recenti applicazioni che han-no trasformato la VHA attraverso il coinvolgimento diretto di de-cine di migliaia di medici, infermieri e dello staff ausiliario: Com-puterized Patient Record System (CPRS) e Bar Code Medication Administration (BCMA).

Computerized Patient Record SystemLa Computerized Patient Record System (CPRS) [Anderson e Meldrum, 1994][Meldrum et al., 1999] rappresenta un notevole progresso nello stadio evolutivo del sistema VistA. Innanzitutto ga-rantisce un approccio al sistema informativo centrato sul paziente piuttosto che sull’organizzazione. Inoltre la sua implementazione nei centri medici garantisce il passaggio di processi basati sull’uti-lizzo di carta a processi completamente computerizzati. La CPRS fu inizialmente rilasciata nel 1996 ma l’implementazione a livello nazionale è avvenuta a partire dal 1999 e coinvolge attualmente tutti i medici della Veterans Administration.

CPRS è un programma che integra numerose applicazioni esi-stenti per uso clinico: lista di problemi organizzativi, dati farmaceu-tici, ordini, risultati di laboratorio, segni vitali, risultati radiologici, trascrizione di documenti e reports da diversi studi (Figura 5.34).

Coloro che utilizzano la CPRS posso immettere, visualizzare e

Figura 5.33La complessità del Sistema Informativo VistA. Adattato de [Turano, 2006]

firmare elettronicamente documenti e prescrizioni. Tra l’autunno del 1999 e la primavera del 2002, 3,5 milioni di note e 7,2 milioni di prescrizioni sono state immesse nelle CPRS della Veterans Admi-nistration della sola Tennessee Valley Helathcare System, un’orga-nizzazione che fornisce 468,000 visite ai pazienti e 130,000 giorni di ricovero nel solo anno 2001.

La CPRS ha avuto due interfacce. La versione “list manager” è stata disegnata per essere compatibile con i terminali hardware esi-stenti e per garantire le transazioni fino a che l’infrastruttura GUI fosse disponibile per tutti gli utenti. Ora che questa è disponibile, è stato deciso di mettere da parte quel tipo di interfaccia.

La preparazione della CPRS è avvenuta in più di 30 mesi ed è co-stata due milioni di dollari, gran parte dei quali sono stati utilizzati per lo sviluppo delle workstation e l’aggiornamento dei server. Il si-stema è cresciuto da quanto l’implementazione è diventata effettiva. (Figura 5.35)

Bar Code Medication Administration (BCMA)Bar Code Medication Administration [Johnson et al., 2002] è una ulteriore applicazione che convalida la prescrizione di medicinali o esami, installata a livello nazione tra il 1999 e il 2000. Consen-te al personale infermieristico di gestire le informazioni in forma elettronica attraverso Medication Administration Record (MAR) implementata attraverso palmari wireless. Il cinturino al polso di un paziente e la card identificativa del personale hanno un codi-ce a barre con un unico numero identificativo; i farmaci prescritti sono confezionati in contenitori di plastica anch’essi dotati di co-dice a barre da parte della farmacia. Per gestire le somministrazio-ni, il personale infermieristico scansisce il cinturino del paziente, la confezione di farmaci e utilizza la sua card identificativa. Tutti i dati vengono automaticamente trasmessi alla cartella elettronica MAR. Questo consente di verificare istantaneamente la correttezza

Figura 5.34Layout Computerized

Patient Record System. Adattato da [Brown et

al., 2003]

della corrispondenza tra il paziente e la sua prescrizione, di eviden-ziare eventuali allergie per prevenire un’errata somministrazione, di registrare automaticamente i dati in tempo reale e di segnalare au-tomaticamente eventuali mancanza di materiale. Il sistema è stato inizialmente sviluppato al Colmery O’Neil VA Medical Center in Kansas a partire dal 1994 (Figura 5.36): gli errori nella sommini-strazioni di medicinali sono diminuiti del 70% fin dai primi anni di appplicazione; non sono scesi a 0 perché questo tipo di errori derivano anche da errori nel processo amministrativo e non solo in quello somministrativo.

VistA ImagingTra gli applicativi sviluppati c’è anche VistA Imaging che è un si-stema coordinato per la comunicazione con i sistemi per immagini radiologiche PACS e per l’integrazione di altri tipi di informazioni con contenuto di immagini, come per esempio documenti scanne-rizzati, con le cartelle cliniche elettroniche all’interno del sistema

G) Facility Merger

Medium SiteLarge Site

0,0250 %

0,0200 %

0,0150 %

0,0100 %

0,0050 %

0,0000 %

1993 1994 1995 1996 1997 1998

Figura 5.35Lo sviluppo del Compu-terized Patient Record System. Adattato da [Brown et al., 2003]

Figura 5.36Andamento delle per-centuali di errore nella somminitrazione dei medicinali all’interno del Colmery O’Neil Va Medical Center in Kan-sas.Adattato da [Brown et al., 2003]

VistA. Questo tipo di integrazione di informazioni in cartelle clini-che è un punto critico per il raggiungimento dell’efficienza nell’uti-lizzo di questi strumenti. VistA Imging è un sistema accessibile an-che ad utenti esterni, per ospedali sia pubblici che privati; può essere quindi usato in modo autonomo oppure integrato nel sistema VistA (come accade ovviamente all’interno delle strutture della Veterans Administration).

Utilizzo di VistA al di fuori della Veterans Administration: evidenze di successo

VistA è un sistema estremamente diffuso e utilizzato all’interno di molti ospedali nel mondo, in quanto capace di adattarsi e di soddi-sfare i bisogni delle diverse organizzazioni.

Alcuni esempi di utilizzo del sistema sono:• VistA&AmericanSamoa–Il governo samoano ha implemen-

tato con successo il sistema VistA al LBJ Tropical Medical Center.

• VistA&DistrictofColumbiaGovernment – Il governo colom-biano utilizza il sistema VistA in alcune delle maggiori cliniche del paese ed è in programma un ulteriore espansione.

• VistA&OklahomaStateVeteransHomes – Lo stato dell’Okla-homa si sta muovendo per acquisire e implementare il sistema di cartelle cliniche informatizzate CPRS nelle sette strutture gestite dalla Veterans Health Administration. VistA è attual-mente utilizzato in quattro cliniche.

• VistAOfficeEHR&HHS/CMS – Il Dipartimento per la Sa-lute e i Servizi Sociali (The Department of Health and Hu-man Services - HHS), i centri di primo soccorso (Centers for Medicare & Medicaid Services - CMS), e la Veterans Health Administration (VHA) collaborano ad iniziative per l’utilizzo di VistA e del sistema di cartella elettronica integrato agli studi privati dei medici.

• VistA&NationalHansen’sDiseaseCenters-Il centro nazionale per la cura della malattia di Hansen (National Hansen’s Dise-ase Programs - NHDP), situato a Baton Rouge in Louisiana, è il maggiore centro per la cura dei pazienti affetti da lebbra. Ha adottato il sistema informativo della Vetarans Administra-tion dal 1989 e ha aggiornato le infrastrutture tecnologiche nel 2000 con un database che contiene dati di oltre 16 mila pazienti.

• VistA& IndianHealth Service (IHS) – la Veterans Admini-stration e il servizio sanitario indiano (Indian Health Service – IHS) hanno da molto tempo lavorato congiuntamente per

lo sviluppo di tecnologie informatiche per la salute. Il sistema sanitario indiano utilizza un’applicazione detta RPMS (Re-source and Patient Management System) che ha le sue radici in VistA.

• VistA&DepartmentofDefense(DoD)–la Veterans Admini-stration e il Dipartimento della Difesa Americano collaborano da sempre a progetti legati all’informatizzazione. Il Diparti-mento della Difesa utilizza un sistema definito CHCS (Com-posite Health Care System) che deriva da VistA.

• VistA&StateandLocalGovernments – I membri della Vete-rans Health Administration (VHA) forniscono periodicamen-te formazione sul sistema VistA e organizzano convegni dimo-strativi per le diverse istituzioni in tutto il Paese che intendono adottarlo.

• VistA&InternationalHealthcareCommunities – Diverse strut-ture in molti paesi del mondo hanno implementato e utilizza-no regolarmente il sistema VistA, tra questi: German Hearth Insitute, Helsinki University Hospital, Cancer Hospital del Cairo in Egitto, Università di Wurzburg, University Hospital di Kuopio in Finlandia.

5.5.3 WorldVistA

WorldVista è un’associazione no-profit nata in California nel 2002 con lo scopo di far conoscere e riuscire a implementare gli strumenti dell’informatica medica a livello mondiale [WorldVistA, 2005].

Un medico, un infermiere o una qualsiasi istituzione in grado di fornire cure a un paziente può avere accesso alle informazioni cliniche relative grazie al supporto di strumenti informatici dedi-cati, per garantire il massimo livello di cura possibile. WorldVista opera perché questo si realizzi attraverso la diffusione del software opensource VistA.

L’associazione lavora affinchè i medici e gli ospedali nel mondo adottino VistA come sistema informativo nell’ottica di migliorare le capacità di cura verso pazienti e, inoltre, per aggiornare continua-mente il sistema per andare incontro ai bisogni di cambiamento degli stessi pazienti e dei medici;

La medica è una scienza complessa, caratterizzata da grande va-riabilità e in continua evoluzione. Coloro che utilizzano software medici, quindi, hanno bisogno costante di seguirne gli sviluppi fino a diventare co-sviluppatori e, nello stesso tempo, gli strumenti in-formatici devono sapersi adattare alle diverse esigenze degli utenti, salvaguardando sempre tutte le esigenze di sicurezza e privacy.

L’efficienza e la modularità alla base della costruzione del sistema VistA fanno sì che la possibilità che il sistema si diffonda in tutto il mondo siano reali; l’associazione WorldVistA lavora appunto con questo scopo. La cartella clinica informatizzata (Electronic Health Record – EHR) di WorlVistA, che nasce infatti dall’applicativo software della Veterans Administration, ha le seguenti funzionalità principali:

Inserimento di dati e informazioni;Creazione e personalizzazione di templates: per velocizzare la cre-

azione di documenti per le diverse esigenze. Promemoria: questa applicazione assiste i clinici nel momento

decisionale aiutando la migliore scelta possibile per il percorso del paziente all’interno della struttura di cura;

Grafica: consente di visualizzare i risultati dei testi di laboratorio e l’andamento dei parametri vitali del soggetto; ogni rilevazione vie-ne poi registrata come un punto su un grafico in modo da poterne monitorare l’evoluzione nel tempo;

Reportistica: l’applicazione consente di creare un report per ogni paziente con tutti i dati relativi al suo percorso, dai parametri vitali alle informazioni nutrizionali;

Supporto dello standard HIPAA (Health Insurance Portability and Accountability Act) per la sicurezza delle prescrizioni attraverso firma digitale;

Codifica dei dati attraverso nomenclatori standard;Individuazione dei fattori di rischio, clinici e sociali, di un sog-

getto attraverso la capacità che l’applicazione ha di analizzare la storia del paziente relativa al consumo di alcol, tabacco, droghe o analizzando l’impiego lavorativo e lo stato sociale;

Compilazione della scheda di dimissione ospedaliera;Per il laboratorio consentendo la possibilità di prescrivere test e

analizzarne i risultati;Per la farmacia per la richiesta automatizzata di farmaci.

E oltre a queste funzionalità, ci sono due altre caratteristiche di in-terfaccia molto utili:

Interfaccia per i laboratori: consente di effettuare prenotazioni di esami da studi esterni e di vederne i risultati una volta disponibili;

Interfaccia per la gestione delle pratiche di pagamento: una piat-taforma opensource gestisce l’integrazione tra le prestazioni erogate e i pagamenti effettuati.

5.5.4 Il futuro di VistA

VistA è nel mezzo di un processo di modernizzazione, si sta evol-

vendo in un sistema informativo integrato basato su Oracle, Linux e java. L’obiettivo del rinnovamento di VistA è quello di muovere verso un sistema informativo centrato sul paziente. Uno dei mag-giori benefici di questa conversione, in particolare per le decisioni basate sull’analisi dei dati, è la possibilità di accedere in maniere più immediata agli archivi nazionali di dati clinici.

La chiave del nuovo sistema sarà l’Health Data Repository (HDR): sarà una banca dati nazionale per dati clinici standardizzati relativi a ciascun paziente. Quando sono iniziate le operazioni per la creazione della HDR nel 2005, l’obiettivo era di aggregare in un database centrale i dati prima dispersi in 128 archivi locali. Il siste-ma rinforzerà in maniera più rigorosa la standardizzazione dei dati in modo che possano essere maggiormente coerenti con i sistemi di gestione dei dati clinici stessi. Le diversità a livello locale saranno mappate in modo da poter ricondurre allo standard anche i dati sto-rici affinché possano essere adeguatamente rappresentati nell’HDR.

Non tutti gli elementi della cartella del paziente però vengono memorizzati nell’HDR ma alcuni, come quelli relativi alle infor-mazioni finanziarie, saranno immagazzinati separatamente. Le im-magini, come quelle prodotte da esami cardiologici o radiologici saranno immagazzinate a livello locale, non spediti all’HDR, anche se si sta pensando ad un archivio centrale anche per questa tipologia di dati. Tuttavia l’HDR ha enormemente incrementato il numero di dati clinici a livello nazionale disponibili per le analisi.

Gli elementi selezionati tra i dati clinici, estratti a livello nazio-nale, sono stati recentemente disponibili anche da un’altra fonte, il Financial and Clinical Data Marts (FCDM). Questi datamart sono database relazionali integrati con accesso a strumenti di analisi sta-tistiche dei dati.

È evidente l’importanza di strumenti di questo tipo ed è prevedi-bile che la loro diffusione sarà sempre maggiore a livello mondiale, anche grazie all’associazione no-profit WorldVistA.

5.6 Sistemi di assistenza domiciliare

5.6.1 Definizione e caratteristiche dell’ assistenza domiciliare (Homecare)

La diffusione dell’Information & Communication Technology (ICT), specialmente in ambito sanitario, e l’impiego di sistemi di telecomunicazione avanzati rende possibile la trasmissione a distan-za di informazioni dal paziente alla struttura sanitaria e viceversa, evitando spostamenti fisici.

Nell’ambito dei servizi sanitari si sta affermando sempre di più il controllo extraospedaliero dei pazienti che per vari motivi non possono o, per i quali non è ritenuto indispensabile, accedere diret-tamente alle cure all’interno delle strutture ospedaliere tradizionali. Per controllo extraospedaliero intendiamo la raccolta, archiviazione ed elaborazione di specifici dati medici lontano dalle strutture ospe-daliere, tramite l’utilizzo delle risorse di base della telemedicina, al fine di avere una chiara situazione dello stato di salute del paziente.

Con il termine Homecare, spesso tradotto in “assistenza domici-liare”, si definisce la “fornitura di servizi sanitari a casa del paziente invece che in ospedale”, ossia l’insieme dei servizi sanitari erogati al domicilio del paziente comprendendo sia l’apporto professionale del personale e sia l’apporto tecnologico dei sistemi di raccolta e trasmissione dei dati clinici.

L’idea di effettuare dei servizi direttamente a domicilio non è nuova: alcuni esempi risalgono addirittura al 400 d.c., quando a Costantinopoli alcune diaconesse si dedicarono all’assistenza infer-mieristica a casa. Nel XIX secolo si verificarono diverse iniziative so-prattutto a Londra, Boston e New York: e fu proprio in questa città che nel 1947 partì in primo programma di assistenza domiciliare da parte del Montefiore Hospital effettuando prestazioni terapeutiche a casa degli ammalati, usufruendo delle attrezzature ospedaliere.

È molto difficile dare una definizione di assistenza domiciliare, comunque quando lo Stato organizza un’assistenza domiciliare si-gnifica che porta al domicilio del paziente tutto quello che serve per effettuare le cure che prima potevano essere erogate solo in ospedale. La frase “portare le cure a casa del malato” rende molto bene l’idea di qual è l’obiettivo che si persegue.

Molto più complesso è poi realizzare questo obiettivo perché por-tare le cure a casa del malato può significare portare e somministrare farmaci, garantire un’adeguata assistenza infermieristica e assistenza medica, significa utilizzare dispositivi medici di tecnologia spesso complessa, raccogliere e gestire informazioni ed interagire con una

serie di figure e professionalità in modo che il livello di assistenza sia del tutto paragonabile a quello dell’ospedale, se non addirittura superiore.

Il motivo principale per cui questo settore è in forte sviluppo è la situazione demografica dei paesi occidentali: la popolazione di tutti gli Stati occidentali presenta una forte tendenza all’invecchiamento, grazie ai notevoli progressi della medicina, infatti, tende ad aumen-tare con il tempo la percentuale di pazienti anziani e soggetti a pato-logie croniche. Di fronte ad un quadro di questo genere gli ospedali non sono sempre la soluzione più indicata per seguire questo tipo di patologie, in particolare quando le stesse si sono stabilizzate. Inoltre l’enorme pressione politica ed economica, ormai comune a tutti i paesi industrializzati, verso la riduzione dei costi dello stato sociale e quindi in particolar modo della sanità, spinge verso protocolli te-rapeutici più snelli e verso la riduzione dell’ospedalizzazione, che è universalmente uno dei principali determinanti degli alti costi della spesa sanitaria [Bergamasco e Schiavon, 2000].

L’ospedale tende a diventare un centro di eccellenza dove ven-gono curati i fenomeni acuti, ma se la patologia si stabilizza po-chi preferiscono trattenersi in ospedale se possono stare a casa, ed inoltre l’assistenza a domicilio offre anche il vantaggio di essere più vantaggiosa da un punto di vista economico.

Quindi l’Homecare consiste nel fornire dei servizi che garantisca-no al paziente la continuità della sua terapia. Non vi è dubbio che in un prossimo futuro la risposta vincente alle attuali problematiche sarà costituita proprio dall’homecare, a condizione che esso risulti in grado di garantire, almeno in una certa misura, alcune delle pre-stazioni che caratterizzano la degenza ospedaliera, ossia:• presenza continua di personale medico e paramedico;• disponibilità di strumentazione diagnostica, terapeutica e di

monitoraggio;• capacità di reazione tempestiva all’emergenza.Si possono utilizzare sistemi telematici che accorciano in modo vir-tuale la distanza fisica tra il paziente “ricoverato” a casa sua ed il centro medico erogatore del servizio di assistenza. Questi sistemi rendono possibile:• il contatto audiovisivo tra medico e paziente;• il controllo e l’impostazione del funzionamento del dispositi-

vo utilizzato;• l’acquisizione in tempo reale di parametri clinici e strumentali,

quali:- pressione arteriosa;- temperatura corporea;

- elettrocardiogramma a 12 derivazioni;- saturazione d’ossigeno.

In pratica, questi nuovi dispositivi rendono possibile al medico di visitare virtualmente il paziente, il quale, da parte sua, ha la certezza di poter ottenere questo tipo di assistenza ogni volta che ne senta l’esigenza.

Obiettivi dell’homecareL’Homecare va quindi considerata come un sistema integrato di interventi domiciliari di assistenza sanitaria e sociale continuativa che, con l’ausilio dei sistemi dell’Information & Communication Technology, consente ad un’ampia categoria di pazienti di rimanere il più possibile nel proprio ambiente abituale. Questo sistema con-sente di contenere il numero e la durata dei ricoveri ospedalieri e di assicurare la migliore assistenza possibile, avvantaggiando sia il sin-golo paziente (miglioramento della qualità di vita), sia la collettività (grazie all’indubbia riduzione della spesa sanitaria per la diminuzio-ne dei cosiddetti «ricoveri impropri»).

Le cure domiciliari, quindi, si caratterizzano per:• la globalità dell’intervento terapeutico che non si limita al

controllo dei sintomi fisici, ma si estende al sostegno psicolo-gico, relazionale, sociale e spirituale;

• la molteplicità delle figure professionali che sono coinvolte nel piano di cura;

• l’intensità delle cure che devono essere in grado di dare rispo-ste pronte ed efficaci al mutare dei bisogni del malato;

• la continuità della cura fino all’ultimo istante, sostenendo la famiglia durante la malattia e il lutto (nei casi di assistenza domiciliare ai pazienti in fase terminale)

• l’impiego degli strumenti della telecomunicazione e dell’infor-matica per consentire, anche a distanza, di monitorare i para-metri vitali di specifico interesse direttamente al domicilio del paziente.

Gli obiettivi dell’homecare possono essere, quindi, così elencati:• ridurre il disagio fisico, psicologico e sociale avvertito dalle fa-

miglie nei confronti di lunghe degenze ordinarie e alleggerire il peso derivante dalle problematiche sanitarie e socio-assisten-ziali;

• ridurre i costi dell’assistenza, favorendo dimissioni precoci (“protette”);

• ridurre il numero di ricoveri impropri nei reparti di degenza e, quindi, rendere disponibili i posti letto di degenza ordinaria

per pazienti in condizioni cliniche critiche;• promuovere la cultura gestionale delle cure domiciliari e pal-

liative, facendo convergere attività e interessi delle organizza-zioni di volontariato e della medicina del territorio sui piani assistenziali istituzionali;

• migliorare l’integrazione professionale visto l’alto numero di attori coinvolto;

• sfruttare al meglio l’innovazione tecnologica orientata alla sa-nità.

La famiglia opportunamente “educata” è il punto di riferimento più sicuro per il paziente, soprattutto per quel che riguarda l’assistenza psicologica In tal senso l’educazione riveste un ruolo fondamentale prima della dimissione del paziente in quanto l’assistenza psicolo-gica, ma anche pratica, è demandata alla famiglia anche in presenza di una realtà ospedaliera molto efficiente. Una volta abbandonato l’ospedale se un paziente o un familiare sbagliano è perché proba-bilmente a monte sono stati male istruiti. Purtroppo non sempre pazienti e familiari possono essere sempre sottoposti ad un training pre-dimissione, sia per la mancanza di programmi adeguati, sia per oggettive difficoltà di interazione tra medico e familiari. Certo non si può generalizzare, spesso ci troviamo di fronte a situazioni difficili di persone totalmente prive di assistenza.

5.6.2 Scenario ICT per i sistemi di homecare

A seguito di un’analisi delle esperienze in atto si deve precisare che lo spazio delle cure intermedie fra ospedale e territorio può essere coperto da diverse forme di offerta e che quindi bisogna come prima cosa collocare i servizi offerti. In linea di principio, l’ospedalizzazio-ne a domicilio consiste nell’allocare, all’esterno del presidio ospeda-liero, attività diagnostiche, terapeutiche, riabilitative, a medio/alta intensità assistenziale, normalmente svolte, da medici e personale sanitario ospedaliero, in regime di ricovero. Questa serie di attività potremmo classificarle con il termine generale di teleassistenza; in quest’ambito è sicuramente di grande importanza l’apporto delle tecnologie informatiche e delle telecomunicazioni, che permettono di controllare lo stato del paziente tenendone monitorati i parame-tri vitali di specifico interesse.

Analogamente l’ADI (Assistenza Domiciliare Integrata) può es-sere definita come un sistema di cure domiciliari caratterizzato dalla integrazione tra attività di natura sanitaria e di natura socio-assisten-ziale, erogate nell’ambito di un Piano di Intervento Personalizzato,

definito anche in relazione al carico assistenziale di tipo sanitario. Costituisce ormai un nodo di offerta nell’ambito dei servizi sociosa-nitari anche se l’offerta è di norma poco standardizzata e vede, oltre a servizi a gestione diretta dell’ASL, anche frequentemente diverse forme di esternalizzazione del servizio.

L’avanzata integrazione tra assistenza ospedaliera e assistenza do-miciliare, infine, concorre alla realizzazione dello scenario in cui è l’ospedale che va al domicilio del paziente: il ricovero virtuale; la riduzione dei tempi di ricovero dei pazienti e del pendolarismo casa-ospedale sono i punti di forza questa applicazione. In questo contesto viene assicurata la “continuità ospedaliera” anche quando il paziente non può raggiungere l’ospedale (impossibilità fisica, la-vorativa, di accompagnamento familiare). Nei casi di cronicità il paziente può essere monitorato al proprio domicilio con le modalità del telemonitoraggio. È possibile rappresentare, quindi, un possibi-le scenario dei componenti che costituiscono l’Homecare (Figura 5.37).

5.6.2.1 TeleassistenzaLa Teleassistenza è un servizio che, per le sue caratteristiche (di tem-poraneità e di complementarietà operativa), in relazione alla tipicità del bisogno del singolo utente, può assumere forme diverse e deve avere sempre un necessario coordinamento con gli altri servizi socia-li del territorio e con quei servizi sanitari che, potendo essere erogati a domicilio, richiedono la presenza sia di operatori professional-mente capaci di fornire le prestazioni specifiche (medico generico, medico specialista, personale infermieristico, personale volontario, etc.)sia di operatori che, grazie all’impiego delle tecnologie telema-tiche, siano in grado di monitorare e trasmettere i parametri vitali dal domicilio del paziente alla struttura ospedaliera di riferimento. La premessa indispensabile per la pratica realizzazione del servizio di Homecare è la costituzione di un Centro di Teleassistenza in grado di attuare ogni opportuna e possibile iniziativa affinché il soggetto, pur esposto ai rischi per i quali il rimedio immediato sembra essere

Figura 5.37Un possibile scenario dei

sistemi di Homecare teleassistenza home care

ricovero virtuale

ADI: assistenza domiciliare integrata

rappresentato dal ricovero, possa continuare a rimanere nel proprio ambiente, in ciò agevolato dalla consapevolezza di un’assistenza adeguata. Di norma il Centro di Teleassistenza dovrebbe avere il necessario raccordo con le ASL, con le Aziende Ospedale, oppure con le Centrali Operative del Numero Unico per l’emergenza 118, affinché a livello territoriale il servizio possa creare – anche per eco-nomia di gestione – una simbiosi di operatori che, pur con diversa professionalità e ruolo istituzionale, operino in equipe coordinate, nella logica e nella disciplina degli interventi, specie nei casi in cui è coinvolta la presenza sanitaria per il controllo o per prestazioni di primo livello che, in ipotesi, possono anche richiedere apparecchia-ture trasportabili. Sulla base dello scenario appena esposto, la Tele-assistenza viene intesa, principalmente, come offerta di un insieme di servizi rivolti ad un largo targetdi utenza (non necessariamente anziana).

Nello specifico, quindi, possiamo analizzare la Teleassistenza come l’insieme di tre “sottoapplicazioni”:• Telemonitoraggio; • Telecontrollo (Telepresenza);• Telesoccorso.

Telemonitoraggio Con Telemonitoraggio si intende la possibilità di monitorare, per alcune patologie, lo stato del paziente tramite la misurazione con-tinua di alcuni parametri medici, da casa o da strutture decentra-lizzate. Questa applicazione è particolarmente orientata a pazienti cronici, terminali, deospedalizzati, portatori di handicap, convale-scenti [IMTES, 2008].

Distinguiamo:• Telemonitoraggiocardiaco: prevede la registrazione continuati-

va dell’attività cardiaca effettuata mediante un’apparecchiatura portatile (elettrocardiografo) e un successivo invio in rete dei dati registrati verso un Centro dove questi vengono elaborati; dall’analisi del tracciato, vengono derivate informazioni sulla situazione cardiaca del paziente, che può perciò essere infor-mato con tempestività.

• Telemonitoraggiodeipazientiindializzati: i dati, sia clinici ge-nerati grazie ad interfacce con il paziente che quelli statistici ottenuti con sistemi di gestione automatizzata dell’intero cen-tro dialisi (cartelle cliniche, schede di programmazione, elabo-razioni statistiche, programmazione delle visite e degli esami, ecc.), sono inoltrati ad un centro specializzato di gestione, che provvede alla loro elaborazione ed al controllo delle operazioni.

• Telemonitoraggiodeipazientidiabetici: si tratta di sistemi au-tomatici per l’infusione dell’insulina in modo continuativo, la cui velocità viene regolata in base al tasso glicemico; alcuni glucosimetri sono provvisti di interfaccia standardizzata a li-vello fisico e possono archiviare, in una memoria interna, il valore di glucosio con relativa indicazione di tempo. Questi valori possono poi essere inviati verso un centro specializzato remoto, utilizzando un PC ed il sistema di telecomunicazio-ne, congiuntamente ad eventuali commenti introdotti diret-tamente dal paziente; il monitoraggio dell’andamento giorna-liero potrebbe perciò essere seguito a distanza dal personale medico.

• Telemonitoraggiodellapressionearteriosa: nasce dall’esperienza dei centri per il controllo dell’ipertensione, di poter monitora-re il paziente (ipoteso, iperteso o cardiopatico) nelle condizio-ni e negli ambienti usuali.

• Telemonitoraggio dei pazienti affetti da problemi respiratori: consiste nel monitoraggio di pazienti, per lo più cronici, per i quali è necessario somministrare quotidianamente ossigeno (ossigenoterapia). Nello specifico, questi sistemi permettono di tenere sotto controllo i parametri specifici (ossigenazione del sangue, frequenza respiratoria, etc.) e di intervenire pron-tamente in caso di necessità.

• Telemonitoraggiodeineonati: consiste nel monitoraggio conti-nuo dei parametri vitali dei neonati affetti da patologie respira-torie e di tutti i bambini considerati a rischio, come i fratellini dei bambini morti di Sids (Sudden Infant Death Sindrome), i nati prematuri, e i bambini che hanno avuto un episodio di ALTE (Apparent Life-Threatening Event).

Telecontrollo (Telepresenza)Il Telecontrollo (oppure Telepresenza) ha l’obiettivo scientifico, clinico e al medesimo tempo tecnologico, di realizzare un’attività continuativa di controllo dello stato fisico e psichico del paziente. Il servizio è rivolto prevalentemente ai pazienti anziani (Telecon-solazione) e a coloro che sono affetti da malattie psichiche (Telep-sichiatria) che viene effettuato tramite un collegamento a distanza in videocomunicazione tra terapeuta e paziente, oppure attraverso telefonate periodiche dal centro operativo presso cui il paziente è in cura al domicilio di quest’ultimo.

TelesoccorsoNello specifico intendiamo porre l’attenzione non tanto sulla possi-

bilità di cura al domicilio (in quanto avviene in strutture ospedaliere o comunque in centri specializzati attrezzati) bensì sulla possibilità di intervenire tempestivamente al domicilio del paziente. Il Telesoc-corso è un servizio che assicura all’utente di richiedere aiuto, princi-palmente in condizioni di emergenza che fornisce una risposta alle richieste di aiuto provenienti dai propri utenti e, grazie a trasmet-titori portatili e dispositivi di ricezione fissi collegati ad una rete di comunicazione, rappresenta un efficace sostegno di carattere psi-cologico e sociale. Una centrale garantisce interventi di emergenza personalizzati grazie alle notizie contenute in una cartella informa-tiva elettronica. Il centro di assistenza deve raccogliere le richieste e le segnalazioni comunque pervenute, valutare le richieste attraverso un’indagine anche di carattere medico (solitamente tramite consul-tazione di software dedicati di gestione dei dati sanitari del pazien-te), organizzare i vari tipi di intervento stabilendo eventuali piani di assistenza, mantenere i rapporti ed i collegamenti tra le varie figure professionali interessate ed utilizzate nel servizio, mantenere uno schedario aggiornato dei casi seguiti. In generale, quindi, consente al paziente-utente, tramite un comando collegato al telefono, di in-viare una richiesta di soccorso ad un centro operativo d’emergenza attivo 24 ore al giorno. Normalmente il numero effettuato dall’ap-parecchio in dotazione al paziente è il numero unico di urgenza/emergenza sanitaria, il 118, che si adopererà per inviare tempestiva-mente l’ambulanza.

5.6.2.2 Assistenza Domiciliare Integrata (ADI) L’assistenza domiciliare integrata è un tipo di servizio erogato diret-tamente a casa dell’utente, che comprende, a seconda dei casi, pre-stazioni mediche, infermieristiche, riabilitative e socio-assistenziali. Essa è caratterizzata da vari gradi che dipendono dalle specifiche necessità della persona che la richiede. Descrivendo tali livelli è pos-sibile capire con facilità che tipo di interventi essa preveda [Scaglia-ti, 2001].

PrimolivelloAssistenza destinata a persone parzialmente non autosufficienti

o a rischio di emarginazione, che richiedono interventi di sostegno psico-sociale e di cura della persona (fornitura dei pasti, riassetto della casa, lavaggio della biancheria, igiene personale, aiuto per pa-gare le bollette). Viene definita a bassa intensità, ma è chiaro che per l’utente interessato può risultare fondamentale.

SecondolivelloConsiste nell’erogazione di interventi di natura sanitaria. È ri-

volta a persone non autosufficienti o di recente dismissione ospe-daliera, che richiedono prestazioni infermieristiche, riabilitative, mediche o specialistiche. È un’assistenza a media e alta intensità, che si ripropone di evitare ricoveri impropri e mantenere il paziente nel suo ambiente di vita.

TerzolivelloQuesto livello riguarda le situazioni più complesse, nelle quali

vengono affrontate le situazioni più difficili, quelle che richiedono l’implementazione del servizio offerto dall’ADI (Assistenza Domi-ciliare Integrata). In questo caso specifico il servizio di assistenza medica è coordinato con quello socioassistenziale, trattandosi di conseguenza di una fusione vera e propria dei primi due livelli.

L’assistenza domiciliare, a qualsiasi livello, viene fornita all’utente solo in giorni ed ad ore stabilite. Gli operatori vengono assegnati ai vari utenti, e dopo aver fatto il proprio lavoro presso il domicilio di ognuno di essi se ne vanno. Il supporto assistenziale non è continua-tivo, come avviene in ospedale. Chi ne usufruirà, di conseguenza, dovrà avere certi requisiti:• Se l’utente vive solo dovrà essere autosufficiente, cioè capace

di provvedere a se stesso (perlomeno per le cose più importan-ti). Se mancasse questo requisito verrebbe meno la possibilità stessa dell’assistenza domiciliare: dato che essa occupa solo un certo arco di tempo nel periodo della giornata, non è certo destinata a chi ha bisogno di un aiuto continuo. In questi casi si dovrà provvedere a forme di assistenza alternative, molto più radicali.

• Se l’utente vive in famiglia può essere completamente non au-tosufficiente (anziani allettati da tempo e con piaghe da decu-bito). L’assistenza familiare dovrà essere adeguata, ed il servizio domiciliare fornirà quelle prestazioni che la famiglia non può assicurare (in primis, ma a seconda dei casi, quelle sanitarie richiedenti l’intervento di uno specialista).

La definizione proposta è limitata al settore sanitario: rimane aperto il problema dell’integrazione con il socioassistenziale, oggi critico in molte realtà, ma sempre più cogente. L’incremento della popolazio-ne anziana, spesso sola, induce bisogni non solo sanitari e, senza la collaborazione del servizio socioassistenziale, difficilmente si riesce a mantenere il paziente a casa propria [Andreoni, 2000].

Gli attori coinvolti, quindi, nel campo dell’Assistenza Domicilia-

re Integrata sono:• medici di medicina generale e pediatri di libera scelta su chia-

mata sporadica dei pazienti (malattie febbrili in giovani adulti, epidemie influenzali, eventi acuti occasionali, ecc.);

• medici di medicina generale in assistenza domiciliare pro-grammata (ADP);

• specialisti ambulatoriali per visite occasionali richieste dall’ASL• fisiatri e fisioterapisti per programmi riabilitativi domiciliari;• psichiatri ed infermieri psichiatrici per programmi che preve-

dono accessi domiciliari;• infermieri, medici ed assistenti sociali dei Ser.T., in particolari

progetti terapeutici;• medici ospedalieri, per progetti mirati specifici: ad esempio i

medici appartenenti ad unità operative di dialisi, con estensio-ni domiciliari o gli anestesisti per la gestione della terapia del dolore, o taluni gastroenterologi o infermieri specializzati per la nutrizione, ecc.

5.6.2.3 Il ricovero virtuale È noto che la medicina è fondamentalmente “Hospital Oriented” e l’evoluzione del ricovero ospedaliero (in regime ordinario o di day-hospital) verso il ricovero virtuale può avere un impatto sociale rile-vante. L’ospedale dispone di risorse umane e strumentali integrate, utilizzabili anche con minimi tempi di accesso ed in rapida sequen-za, che garantiscono una qualità di prestazioni spesso non ottenibile altrimenti [Papi e Ricc, 2003]. Il ricovero ospedaliero presenta però, secondo gli attuali orientamenti, tre difetti basilari:• il costo della degenza;• il costo da mancata attività lavorativa;• i problemi psicologico-affettivi dell’ospedalizzazione.Parte dei ricoveri ospedalieri potrebbe essere realizzata “virtualmen-te”, assistendo telematicamente il paziente presso il proprio domi-cilio o presso il posto di lavoro. Infatti l’innovazione tecnologica offre l’opportunità di migliorare la qualità dell’assistenza, offrendo l’ospedale virtuale a domicilio del paziente.

Tale soluzione permetterebbe un miglioramento della qualità as-sistenziale perché ne verrebbe assicurata la continuità “ospedaliera” anche quando il paziente non possa raggiungere l’ospedale (impos-sibilità fisica, lavorativa, di accompagnamento familiare), diminui-rebbe ulteriormente il costo sociale, sia per il paziente se lavoratore, che per i familiari che spesso lo accompagnano, e riduce i disagi dovuti agli spostamenti delle persone malate e disabili [D’Innocen-zo e Trippetti, 2006]. Le aree di principale interesse per una prima

applicazione del ricovero virtuale potrebbero essere l’oncologia, la chirurgia, e le malattie croniche (ad esempio, cardiologia, diabete, ecc.).

Il possibile modello d’interazioneIl processo di cura che si basa sul ricovero virtuale enfatizza le fun-zioni dell’insieme delle strutture sanitarie che collaborano per por-tare avanti il protocollo clinico scelto per il paziente, ognuna con le proprie competenze e specializzazioni. È importante definire bene i ruoli che ciascuna di esse svolge nell’erogazione della cura ed è quindi fondamentale definire il modello d’interazione tra di esse, tenendo anche conto che il paziente è “fisicamente” distante dagli operatori sanitari presenti in tali strutture.

Il possibile modello di interazione si configura come mostrato in Figura 5.38. L’erogazione della cura eseguita durante il ricovero virtuale coinvolge i seguenti attori:• il paziente (oggetto della cura);• il responsabile della cura (un medico, un team di medici) che

segue l’intero processo di cura del paziente;• il fornitore della cura (lo stesso responsabile della cura, un

medico specialista, un infermiere, il paziente stesso o un suo familiare) che esegue le attività diagnostiche, terapeutiche e riabilitative;

• il medico specialista (o un team di medici) che offre consu-lenza sia nella valutazione dei risultati degli esami diagnostici che nella definizione del protocollo diagnostico e terapeutico.

Lo scambio d’informazione tra i diversi attori, oltre che avvenire direttamente, si realizza tramite l’accesso alle informazioni inserite nella cartella clinica del paziente. Questa deve contenere sia le infor-mazioni cliniche relative al paziente che la lista delle attività cliniche suggerite, programmate ed eseguite (protocollo clinico) ed anche

Figura 5.38Il modello di interazione

tra i diversi attori del Ricovero Virtuale.

Adattato da [Papi e Ricc, 2003]

responsabile della cura

paziente fornitore della cura

cartella clinica

medico specialista

informazioni cliniche

indicazionicliniche

consulto

lo stato di esecuzione della singola attività (procedure gestionali) e dei flussi informativi tra le strutture coinvolte nell’attività. Questo implica che nella cartella clinica sia riportato anche il protocollo clinico che si intende seguire al fine di assicurare la coerenza de-gli interventi. Lo scambio d’informazioni diretto tra gli attori può avvenire utilizzando le tecnologie del teleconsulto, in quanto tale modalità d’interazione può avvenire non solo tra responsabile della cura e medico specialista, ma anche tra il responsabile della cura ed il fornitore di essa ed addirittura coinvolgendo il paziente in un dialogo diretto. Ciò è importante perché il medico può seguire da lontano, e in modo diretto, l’evoluzione del quadro clinico dei pa-zienti che necessitano di essere seguiti con particolare attenzione. Inoltre si possono affrontare, in modo organico ed in tempo reale, tutte le emergenze di tipo qualitativo che richiedono la disponibi-lità della maggior quantità di informazioni possibile, unitamente al parere dei maggiori esperti del settore. Tali pareri, opportunamente “formalizzati” e “generalizzati” possono creare le banche di proto-colli che insieme ad altre informazioni (quali quelle presenti nei database on line) sono la premessa per lo sviluppo di una nuova serie di servizi integrati.

Riflessioni sul ricovero virtuale Di fronte a questo scenario è indubbio che le nostre aspettative sia-no decisamente alte; si tratta, ora, di andare ad analizzare quali siano i possibili vantaggi e limitazioni derivanti dall’implementazione di tale progetto. Da un lato possiamo riconoscere le possibili migliorie che il ricovero virtuale si auspica di apportare in termini di vantaggi al paziente e agli attori coinvolti nella struttura e dall’altro possiamo evidenziare eventuali criticità in merito.

Per quanto riguarda i vantaggi riconosciamo i principali:• il paziente si sente seguito, dal punto di vista clinico, in modo

continuativo e circondato da molti attori;• il paziente che dovesse versare in condizioni croniche potrebbe

essere monitorato direttamente al suo domicilio tramite l’im-piego dei classici sistemi di telemonitoraggio; se ciò dovesse succedere allora il paziente ritroverebbe tutti i vantaggi relativi al telemonitoraggio;

• auspicabile riduzione dei tempi di ricovero dei pazienti e del pendolarismo casa-ospedale;

• migliore utilizzo delle diverse competenze e delle strutture ospedaliere (soprattutto in località caratterizzate de una parti-colare morfologia, quindi, montagna o isole).

È necessario, come analizzato in precedenza, che vi sia una ben de-finita integrazione tra il lavoro svolto dai vari attori coinvolti nel-la cura del paziente; questo aspetto è tanto più critico quanto più aumenta il numero degli attori stessi. Un primo aspetto critico , quindi, è quello dovuto alla presenza di diversi professionisti del settore che devono interagire in modo sincrono tra loro; questo rap-porto collaborativo deve essere garantito, oltre che da motivazioni di carattere personale, anche dall’impiego di sistemi informativi che rappresentano le fondamenta del Ricovero Virtuale, quindi, sul pia-no personale, il paziente può sentirsi lasciato a sé stesso quando non vi è la dovuta professionalità da parte del medico curante. Un altro aspetto critico è rappresentato dalla possibile difficoltà del paziente di riconoscere e identificare l’effettivo responsabile della cura (vi-sto l’alto numero di attori diversi). Vi è, poi, la necessità di dover standardizzare le informazioni scambiate tra il medico curante e le strutture specializzate; questo aspetto può essere critico, soprattutto se vengono coinvolte numerose strutture.

5.6.3 Aspetti tecnologici

5.6.3.1 IntroduzioneAbbiamo visto nei paragrafi precedenti, che con il termine generale di Homecare si intende letteralmente portare le “cure al domicilio”, si deve quindi tenere ben presente che la possibilità di curare un paziente a casa propria non significa solo offrirgli la possibilità di restare in un ambiente a lui familiare senza badare alla qualità delle cure praticate: in generale è utile che ci sia un giusto trade off tra questi due aspetti. Nello scenario dei sistemi di trasferimento dei dati e segnali biomedici è possibile individuare molteplici tipologie trasmissive che variano a seconda del tipo di dato specifico, del li-vello che si vuole mantenere di qualità del dato, dei costi e quindi del budget a disposizione dei diversi attori coinvolti, e infine del contesto in cui la comunicazione a distanza avviene.

Ulteriori fattori di innovazione stanno spostando ancora più in avanti le frontiere dell’agire in medicina permettendoci di gestire ogni tipo di informazione senza più vincoli di tempo e di spazio. Distinguiamo:• l’allargamento della banda di trasferimento dell’informazione;• la velocità di trasferimento del pacchetto di informazioni utili;• la mobilità come primario elemento di innovazione per gestire

la crescente complessità dei sistemi sanitari.È ormai forte la consapevolezza che la mobilità sarà la vera gran-

de rivoluzione dei prossimi anni e che la Sanità italiana non dovrà

perdere le occasioni che questa ennesima sfida tecnologica porta con sé [Borghi, 2000].

5.6.3.2 Caratteristiche dei datiL’Homecare e, più in generale, la telemedicina derivano dall’ap-plicazione della telematica e dell’informatica in campo medico. È utile, quindi, prendere in considerazione alcuni aspetti tecnici per meglio comprenderne il funzionamento [Bragonzi e Orsi, 2006].

Innanzitutto si possono distinguere le applicazioni della teleme-dicina in base alle caratteristiche dei dati scambiati ed alla modalità di interazione tra gli interlocutori coinvolti nello scambio.

Per quanto riguarda la tipologia dei dati scambiati, possiamo di-stinguere:• Dati statici: dati che non variano nel tempo (immagini stati-

che, dati di testo,…)• Dati dinamici: dati che hanno variazioni nel tempo (immagi-

ni dinamiche, segnali audio,…)Ciò che contraddistingue il contenuto informativo trasmesso nella pratica informatica da quello trasmesso nella pratica medica è la particolare importanza che esso ricopre; ogni dato trasmesso può essere cruciale nel trattamento di un paziente, e pertanto va dedica-ta ogni cura possibile alla sua manipolazione, sia relativamente alla qualità che alla privatezza a sicurezza durante la trasmissione.

5.6.3.2.1 Tipi di dati I dati che possono essere trasmessi in telemedicina sono quelli che possono essere trasmessi in ogni comunicazione di tipo multimedia-le, e quindi includono: • Testo: che di solito accompagna ogni altro tipo di dato sotto

forma di storia clinica del paziente, dati anagrafici, etc. • Immagini: sia digitalizzate a partire da fonti analogiche, sia

direttamente digitali, costituiscono probabilmente la maggior parte dei dati scambiati in telemedicina, poiché riguardano moltissime discipline (teleradiologia, teledermatologia, telepa-tologia, etc).

• Audio: per esempio, suoni provenienti da stetoscopio. • Altri dati monodimensionali: ECG e altri segnali provenien-

ti da monitoraggio di attività fisiologiche. • Video: immagini da endoscopia, ecografia, videoconferenza

nel consulto su paziente (per esempio, in telepsichiatria). Di ogni dato è necessario garantire la qualità ottenuta dall’interlo-cutore remoto dopo acquisizione e trasmissione.

5.6.3.3 La compressione dei datiNella pratica medica è altresì molto importante ricevere i dati tra-smessi ed essere sicuri che quanto ricevuto corrisponda perfetta-mente all’originale; aspetto questo da non sottovalutare in quanto è usuale ricorrere a tecniche di compressione per poter trasferire quantità superiori di dati in minor tempo.

Taluni dati possono assumere dimensioni tali da non permet-terne la trasmissione in un tempo clinicamente utile, e pertanto si ricorre a diversi metodi di compressione: • Compressione reversibile o lossless: basati su metodi ma-

tematici e statistici, riducono la ridondanza presente nell’in-formazione in modo tale che dal dato compresso è possibile ricostruire integralmente il dato originale. Con questi metodi il dato compresso può occupare fino al 25-30% del dato ori-ginale. Esempi: il formato ZIP, la compressione dell’immagine nel formato GIF.

• Compressione irreversibile o lossy: tramite un modello del sistema di acquisizione e del destinatario (es. occhio per le im-magini), viene eliminata l’informazione che si ritiene di inte-resse minore in quanto meno precisamente acquisita o perce-pita. Di conseguenza c’è una perdita di informazione ed il dato originario non viene ricostruito esattamente, anche se in linea di massima le differenze non saranno percepibili. Con questi metodi il dato compresso può occupare anche meno del 2% del dato originale (di solito è possibile scegliere quanto com-primere e quindi quanto perdere). Esempi: JPEG, wavelets.

La Tabella 5.9 espone alcune dimensioni tipiche di dati in telemedi-cina, con e senza compressione [Fontana, 2004].

Sorgenti dati Descrizione Compressione Dimensione totale

Radiografia generica Risoluzione 4096x4096x12 bit < 15 1,6 Mbyte

Radiografia per Oncologia Risoluzione da 1024x1280x 8bit a 2048x2560x12 bit < 15 da 85 Kbyte a 512

Mammografia Risoluzione 4096x4096x12 bit < 15 1,6 Mbyte

TAC Risoluzione 512x512x16 bit per ogni scansione < 15 25,6 Kbyte

Risonanza Magnetica Risoluzione 256x256x16 bit per ogni scansione < 15 8,5 Kbyte

Ecografia Risoluzione 768x12x8 bit per singola schermata < 15 25,6 Kbyte

ECG 500 campioni di 16 bit al sec. per ogni testina, durata 10 sec. Nessuna 80 Kbyte

Immagini dermatologiche Risoluzione 768x512x24 bit < 25 48 Kbyte

Tabella 5.9Dimesioni di dati tipiche

della telemedicina.Dati da [Fontana, 2004]

Immagini microscopiche Risouzione 640x480x24 bit < 25 60 Kbyte

Segnali biomedici (es. temperatura, peso, pulsazioni)

Informazioni puntuali provenienti da sensori

Non necessaria < 1 Kbyte

Si ricorda comunque che, quando c’è una digitalizzazione di un dato normalmente disponibile in forma analogica, si ha sempre una perdita di informazione dovuta intrinsecamente al processo di di-scretizzazione del dato.Per quanto riguarda le modalità di interazione, distinguiamo :• Real Time: in questo caso non c’è un apprezzabile ritardo tra

l’acquisizione dell’informazione e la sua spedizione all’inter-locutore.

• Store and forward: in questo caso esiste un primo momento in cui il segnale è acquisito e memorizzato, e un secondo mo-mento in cui i dati sono spediti all’interlocutore.

5.6.4 Biostrumentazione

5.6.4.1 Requisiti delle apparecchiature biomedicheLe apparecchiature biomediche utilizzate in ambito homecare, de-vono soddisfare particolari specifiche restrittive, quali:• leggerezza e comodità nella presa;• riduzione al minimo possibile di cavi di collegamento;• integrazione di tutte le parti funzionali in un unico box;• estrema semplicità d’uso, con pochi comandi ben accessibili;• prontezza all’uso, senza necessità di configurazioni iniziali o

laboriose procedure d’accensione;• robustezza di tutte le parti, con particolare protezione per di-

splay o parti fragili;• Testata resistenza agli urti, alle cadute e al contatto con parti

appuntite;• elevata autonomia di batterie;• impermeabilizzazione nei confronti dell’acqua , ma anche di

polvere e sabbia;Lo strumento che deve essere utilizzato non va quindi progettato solo rispettando gli standard tecnologici, ma deve essere ideato in funzione di chi ne fa uso e delle condizioni ambientali in cui deve funzionare. Un altro aspetto di primaria importanza è quello riguar-dante l’interazione che esiste tra lo strumento e il paziente.

In ambito medico sia che si parli di diagnosi che di terapia, si deve fare i conti con un termine: invasività. Questo termine si ri-ferisce alla particolare condizione in cui sono costretto ad “entrare” in qualche modo nel corpo del paziente per effettuare una misura

o effettuare una terapia; in questo caso di parla di diagnosi/terapia “strumentale”. È ovvio che tanto più una misura è invasiva e tanto più è critico effettuare la cura al domicilio del paziente; nel caso, ad esempio, della teledialisi (dialisi peritoneale o emodialisi domicilia-re) vi è ,oltre al problema di monitorare in real time il paziente e, in caso di emergenza, di intervenire prontamente, la necessità di enfa-tizzare l’aspetto riguardante la sicurezza sia del paziente sottoposto al trattamento sia della strumentazione impiegata.

5.6.4.2 Scenario della strumentazione impiegataSegue una breve presentazione di apparecchiature biomediche non invasive utilizzabili in ambito homecare.

SpirometroLo spirometro è uno strumento dedicato alle persone asmatiche o affette da malattie respiratorie. Deve essere di facile utilizzo, a basso costo e tascabile, in modo tale da dover sottoporre il paziente solo ad un breve training per eseguire correttamente la spirometria. Tra i diversi spirometri in commercio alcuni utilizzano un sistema di tra-smissione di dati per accoppiamento acustico che permette di uti-lizzare sia telefoni fissi che cellulari e altri un sistema di trasmissione digitale, coperto da un brevetto internazionale, che permette di tra-smettere la spirometria ponendo lo strumento fino ad un metro di distanza dal telefono, evitando così complicati “accoppiamenti” con lo spirometro. Ovviamente la procedura per l’invio dei dati avviene in modo semplice, chiamando il centro di ascolto pneumologico ed inoltre se necessario è possibile parlare con il medico sia prima che dopo l’invio dei dati. La foto è disponibile on-line nella raccolta di iconografia di sanità digitale.

TelepulsossimetroQuesto apparecchio mobile non invasivo misura in tempo reale i valori della saturazione dell’ossigeno (SpO2) e la frequenza delle pulsazioni. L’apparecchio trasmette i valori misurati che vengono confrontati con i valori base (assoluti), archiviati in una banca dati centrale. Se i valori sono più bassi - indizio di una minaccia di ipos-sia, che può provocare gravi danni - viene allarmato uno staff di me-dici, che quindi provvede a contattare telefonicamente il paziente e gli suggerisce i provvedimenti possibili o necessari (ad es. farsi visi-tare dal proprio medico). La foto è disponibile on-line nella raccolta di iconografia di sanità digitale.

Dispositivo per il telemonitoraggio della pressioneQuesto apparecchio consente di monitorare la pressione sanguigna. Il paziente posiziona la fascia attorno al braccio, preme un tasto e attiva la misurazione automatica e la trasmissione dei valori della frequenza cardiaca e della pressione sanguigna che vengono con-frontati con i valori base archiviati in una banca dati centrale. In caso di variazione critica dei valori, viene allarmato il personale che contatta telefonicamente il paziente e gli suggerisce i provvedimenti possibili o necessari. Con questo apparecchio (che viene installato nell’abitazione del sottoscrittore e dispone di una regolazione auto-matica della pressione), premendo un tasto si misurano la frequenza cardiaca e la pressione sistolica e diastolica, che vengono visualizzate su un display a cristalli liquidi. La foto è disponibile on-line nella raccolta di iconografia di sanità digitale.

ElettrocardiografoQuesto apparecchio consente, in generale, il rilievo di 12 derivazio-ni standard, in gruppi di 6 + 3 + 3 contemporanee. I segnali vengo-no acquisiti con un’altissima risoluzione (22 bit) ed inviati al PC, tramite un accoppiamento ottico, utilizzando una porta standard per stampante; non è pertanto necessaria l’installazione nel PC di hardware aggiuntivo. Grazie a questa caratteristica l’apparecchiatura può essere agevolmente utilizzata anche in collegamento con un PC portatile. Effettuando un collegamento on-line, via Internet o diret-to via modem, con una centrale diagnostica vengono trasmessi au-tomaticamente i tracciati elettrocardiografici, utilizzando una vasta gamma di opzioni di trasmissione: internet, posta elettronica, mo-dem, fax. Per una maggiore facilità di impiego può essere utilizzato, oltre che con un cavo paziente standard, con uno speciale giubbotto che non richiede l’intervento di personale sanitario per il posiziona-mento degli elettrodi. La qualità dei contatti viene visualizzata sul PC con immagini chiare ed intuitive. La foto è disponibile on-line nella raccolta di iconografia di sanità digitale.

Unità HomecareQuesto dispositivo medio è costituito da un concentratore di dati interfacciabile a più moduli strumentali per l’acquisizione di infor-mazioni cliniche quali l’ossigenazione del sangue (SPO2), tracciato elettrocardiografico (ECG), una misura del livello di glucosio attra-verso un apposito strumento (Glucosimetro), etc. Tale unità Home Care può essere collegata ad un modulo GSM DUAL BAND o in alternativa ad un tradizionale modem e alla rete telefonica fissa al fine di trasmettere i dati“ad una Unità di Consultazione Remota“

per il monitoraggio “ON LINE” del paziente. Il medico, dall’ospe-dale può così con un computer, modem e apposito software di con-sultazione visionare in tempo reale i dati clinici fondamentali del paziente come l’elettrocardiogramma, la concentrazione di ossige-no nel sangue, e se necessario può anche verificare ed apportare modifiche ai parametri di funzionamento degli strumenti inseriti nel modulo a domicilio del paziente; il paziente può contattare il medico, o lo staff preposto al controllo dei parametri, tramite un si-stema di videoconferenza. Alcune Unità Homecare hanno anche la possibilità di assistere i pazienti affetti da gravi patologie dell’appa-rato respiratorio grazie all’ausilio di ventilatori polmonari. La foto è disponibile on-line nella raccolta di iconografia di sanità digitale.

5.6.4.3 Interferenza elettromagnetica nella strumentazione biomedica impiegata in Homecare

Uno dei principali problemi che si incontrano utilizzando disposi-tivi che sfruttano lo stesso range di frequenza è rappresentato dalle interferenze provocate [Bragonzi e Orsi, 2006]; in generale con il termine interferenza si indica il disturbo provocato dall’impiego di un dispositivo nelle vicinanze di un altro (simile nel contenuto in frequenza) tale da “sporcare” le informazioni rilevate o trasmesse [Chierici e Rampini, 2003]. In particolare in aggiunta al dato che effettivamente deve essere trasferito si trasferisce una componen-te di disturbo (in termini tecnici rumore) e ciò rende ambigua la trasmissione. Nell’impiego di apparecchiature mediche che sfrut-tano la stessa tecnologie wireless (WLAN e Bluetooth) ci possono esser problemi di questo genere; in ambito Homecare, poi, questa problematica è giustamente enfatizzata in quanto non è possibile chiedere direttamente al paziente di risolvere queste problematiche (magari l’ente responsabile si può limitare alla divulgazione di con-sigli utili). Un conto è svolgere un esame in un contesto più o meno organizzato e progettato (ospedali, centri specializzati, laboratori), in modo tale da ridurre al minimo l’effetto di eventuali interferenze, mentre ben più problematico è l’impiego di apparecchiature medi-che in ambienti volti allo svolgimento della propria vita quotidiana. In questo paragrafo non vogliamo soffermarci troppo sugli standard relativi alla progettazione dell’ambiente di lavoro in ambito medi-co, ma cerchiamo di enfatizzare l’aspetto riguardante la possibile interazione dannosa tra dispositivi medici applicati al domicilio del paziente. Molte apparecchiature mediche, per poter trasferire all’ospedale o al centro specializzato l’esito degli esami effettuati al domicilio del paziente, utilizzano bande di frequenza simili con il rischio di intaccare l’affidabilità dell’esame svolto (si pensi ad esem-

pio agli elettrocardiografi, dispositivi per il telemonitoraggio della pressione, telepulsossimetri); molte volte, e questo grazie allo svi-luppo dell’industria biomedica nel suo complesso, questi dispositivi vengono progettati e assemblati in un unico apparecchio per ren-dere meno difficoltoso il loro impiego. Quindi, almeno in fase di progettazione, è auspicabile che si adoperi per ridurre al minimo il rischio di possibili interferenze. Una variabile esogena è rappresen-tata dall’impiego in ambiente domestico di altri dispositivi (cellu-lari, forno a microonde, telefoni cordless); in questo caso, sebbene ancora una volta in fase di progettazione è possibile intervenire, si possono riscontrare problematiche sempre inerenti alla sicurezza ed esattezza del dato trasferito. Un sistema elettronico che sia in grado di funzionare compatibilmente ad altri sistemi e che non produca o non sia suscettibile alle interferenze è definito elettromagnetica-mente compatibile.

Per eliminare il fenomeno è quindi necessario :• cercare di sopprimere o limitare le emissioni direttamente alla

sorgente;• rendere il percorso di propagazione il più inefficiente possibile;• rendere il ricevente il meno suscettibile alle interferenze.Quindi, ogni dispositivo medico che ha al suo interno circuiti elettronici può essere suscettibile a tale interferenza. Tra questi, ad esempio, sono classificabili le pompe ad infusione, apnea monitor, monitor per il battito cardiaco, ossimetri pulsati, ventilatori, defi-brillatori impiantabili, pacemaker, sistemi telemetrici, sistemi per la dialisi, protesi acustiche, incubatrici, sedie a rotelle elettriche, ri-scaldatori di sangue, elettrostimolatori, elettroencefalografi ed altri. Molti di questi dispositivi sono di importanza vitale per il paziente ed è chiaro che in questo caso il fenomeno dell’interferenza ed il conseguente malfunzionamento del dispositivo può costituire un problema di elevata gravità.

Esistono varie regolamentazioni che le apparecchiature mediche de-vono rispettare affinché non vi siano problemi di interferenze tra le di-verse apparecchiature mediche; tecnicamente la FDA (Food and Drug Administration) non ha emanato uno standard di immunità, sebbene suggeriscano 7 V/m su una banda di frequenza intorno ai 900 MHz. IEC 601-1-2 suggerisce che i dispositivi operino a 3 V/m su una ban-da di frequenza tra i 26 e i 100 MHz. Lo standard attorno al quale più produttori stanno lavorando è la seconda bozza del IEC 60601-1-2 che specifica un livello di potenza per i campi di 10 V/m per frequenze comprese approssimativamente tra gli 800 MHz e i 2.3 GHz.

Dispositivi Distanza [m] dalle apparecchiature mediche2.4 GHz FHSS 0.6Telefono cellulare 1.4Walkie-Talkie UHF 4.1Monitoraggio pazienti 0.12Radiomobile 8.2Radiomobile 4.1

La tabella 5.10 mostra quanto lontana deve essere l’apparecchiatura radio dall’apparecchiatura medica per generare un campo di inten-sità pari a 3 V/m; i walkie talkies UHF, ad esempio, devono essere tenuti almeno ad una distanza di 4 metri da un’apparecchiatura me-dica per avere, a tale distanza, un’intensità di campo di 3 V/m. Tele-foni cellulari dovrebbero essere tenuti ad almeno una distanza di 1,4 metri. In sostanza il concetto è il seguente: le apparecchiature uti-lizzanti potenze maggiori creano delle intensità di campo maggiori e devono essere tenute a distanza maggiore dalle apparecchiature mediche. Un tipo di apparecchiatura particolarmente suscettibile è rappresentato dai monitor dei pazienti, che hanno tipicamente trasduttori (elettrodi per ECG, trasduttori di pressione, ecc.) che si trovano ai terminali di cavi relativamente lunghi. Questi cavi e tra-sduttori si comportano come antenne a dipolo, e sono connessi ad amplificatori differenziali molto sensibili. Le regolamentazioni per i produttori prevedono che questi cavi siano connessi durante i test, ma prevedono inoltre che i cavi siano orientati opportunamente per minimizzare gli effetti di antenna. Tutto questo per non avere l’inconveniente di misurare un parametro affetto da rumore.

5.6.5 Il grado di diffusione

Come abbiamo visto i sistemi di assistenza domiciliare sono molte-plici e variano a seconda del modello clinico-sanitario oppure socio-assistenziale che consideriamo. A seconda dello scenario cambiano, quindi, le finalità del servizio e le interfacce (tecnologica e relaziona-le) coinvolte. Cambia anche, ovviamente, l’oggetto dell’assistenza: pazienti affetti da cronicità oppure persone sole, anziani o disabili.

La tabella 5.11 riassume le caratteristiche dei principali servizi secondo queste variabili considerate.Sono diversi i progetti in questo ambito finanziati sia a livello lo-cale che nazionale che dall’Unione Europea. Riportiamo in tabella 5.12un elenco dei progetti attualmente in corso (al 2007).

Il progetto E-care, per esempio, è rivolto ad anziani e soggetti fragili su un territorio che comprende i comuni di Bologna, Ferrara, Budrio (BO), San Lazzaro di Savena (BO), San Pietro in Casale (BO), Vergato (BO) [Valerio, 2008].

Tabella 5.10Distanze da mantenere tra generatori di campi

elettromagnetici e apparecchiature

elettromedicali

Caratteristiche Modello clinico-sanitario Modello socio-assistenziale

Servizi Telemonitoraggio, telemedicina Teleallarme, telecompagnia, teleinformazione, teleascolto

Finalità del servizio Favorire la deospedalizzazione e il telecontrollo terapeutico Interventi di social support

Interfaccia tecnologica Dispositivi per il monitoraggio con interfaccia user freindly

Tecnologie di tipo domestico (telefono, videotelefono, dispositivi per l’invio del segnale di allarme)

Interfaccia relazionale Medici, operatori sanitari Operatori sociali, Call center

Ente promotore Soggetti del sistema sanitario regionale: soggetti della sanità privata

Enti locali, soggetti del terzo settore, distretti

Utenti Pazienti affetti da cronicità e in dimissione protetta

Persone sole, anziane e/o disabili o in stato di disagio

Ente finanziatore ProgettoProgetti finanziati dall’ UE

E-care (Italia, Germania, Cipro), HELLODOC (Italia, Belgio, Spagna), Medical Care Continuity (Belgio, Francia, Italia, Polonia), OLDES (Bologna, Praga)

Progetti finanziati dal Governo

DiCIT (Comune di Milano, Comune di Bergamo, Comune di Reggio Emilia), Mana-ged care (Regioni Lombardia e zone limitrofe)

Progetti finanziati a livello locale

E-Care di CUP 2000 SpA (Comune di Bologna, Comune di Ferrara, Comune di Bu-drio (BO), Comune di San Lazzaro di Savene (BO), Comune di San Pietro in Casale (BO), Comune di Vergati (BO)), Nonne-care di CUP 2000 SpA (Circoscrizione di San Giovanni a Teduccio, Napoli), Telecardiologia nella Medicina Generale (Distretto Pianura Est Azienda Usl di Bologna), NON più SOLI (Comune di Roma), Servizio di Teleassistenza dell’USL 4 di Thiene (ASL Alto Vicentina), Boario Home Care Project (Vallecamonica), Telecardiologia sul territorio nella provincia di Trento (Provincia di Trento), Firenze Telecare (Comune di Firenze), Telecardiologia – ASL 2 Castrovillari (USL 2 Castrovillari), Comune di Roma – dimissione protetta e terapia domiciliare per scompenso cardiaco (Area Metropolitana di Roma), Ospe-dalizzazione domiciliare – Servizio di Telemedicina (Brescia), Servizio di Teleme-dicina di Ancona, Telecardiologia (Provincia mantovana).

La popolazione coinvolta nel 2007 era di 4000 utenti (pari al 4,2% della popolazione) e per il 2008 si prevede il coinvolgimento di 5000 persone.

Gli obiettivi [Bragonzi e Orsi, 2006] dichiarati dal progetto sono di:• favorire una nuova domiciliarità socio-sanitataria;• ritardare il passaggio a condizioni di non autosufficienza;• fornire strumenti per migliorare l’integrazione tra sociale e sa-

nitario;• valorizzare il ruolo delle risorse sociali del territorio;• produrre informazioni condivise, in un’ottica di prevenzione.

Per questo sono stati istituiti diversi servizi:• Call Center Specializzato attivo h24, 7 giorni su 7;• Compilazione Dossier Socio Sanitario;• Piano Individuale di Assistenza;• Telesoccorso chiamando il Call Center, h24;• Prenotazioni CUP personalizzate;• Contatto con i MMG di riferimento e con la Guardia Medica

Tabella 5.11Ricognizione sullo stato dell’arte in Italia alla ricerca di possibili modelli e-care Fonte: E.Porcu [Guarino e Mignardi, 2007]

Tabella 5.12Ricognizione sullo stato dell’arte in Italia alla ricerca di possibili modelli e-care Adattato da E.Porcu [Guarino e Mignardi, 2007]

(al bisogno);• Contatto costante e personalizzato con i Servizi Sociali;• Servizi di trasporto, accompagnamento, spesa a domicilio ecc.;• Sevizi di Telesicurezza (rapporti con polizia Municipale, Vigili

del Fuoco, organi di Pubblica Sicurezza);• Attivazione di artigiani convenzionati per piccoli lavori a do-

micilio;• Consulenze fiscali e per la tutela previdenziale (a domicilio);• Attivazione volontari e opportunità.Un altro progetto realizzato invece sul territorio di Napoli è Nonne-Care [Nonne-Care, 2006]. Si tratta di una sperimentazione di Call Contact Center e-Care rivolta a circa 200 donne over 70 residenti nella periferia est della città di Napoli, nel territorio della munici-palità di San Giovanni a Teduccio. Ogni donna anziana partecipan-te al progetto ricevere forme di assistenza a domicilio attraverso le nuove tecnologie: teleassistenza, telecompagnia, telesoccorso, tele-medicina e teleinformazione.

Altro caso significativo è quello della sperimentazione di telecon-sulto cardiologico della provincia di Trento [Trentino Salute, 2000]. Il decentramento dei servizi e l’utilizzo in periferia di esperienze specialistiche nel campo medico risulta di particolare importanza in un territorio montano, quale quello della provincia di Trento, carat-terizzato da una comunità diffusa, con la conseguente frammenta-zione dei bisogni di prestazioni sanitarie e la necessità di assistenza extra-ospedaliera. Di qui bisogna partire per ricordare quali siano gli obiettivi di un servizio di Teleconsulto cardiologico e cioè: a. riduzione degli accessi agli ambulatori cardiologici e potenzia-

mento del filtro pre-ospedaliero; b. esecuzione di esami strumentali a domicilio in pazienti con

compromesse possibilità di trasferimento (come i non-deam-bulanti e gli invalidi totali), con riduzione delle spese, del cari-co organizzativo, del trasferimento in ambulanza;

c. riduzione dei tempi decisionali; d. riqualificazione professionale dei medici di medicina generale; e. assicurazione di un adeguato monitoraggio dei pazienti car-

diopatici.

5.6.6 Conclusioni

Abbiamo analizzato il contesto dell’Homecare cercando di unire gli aspetti riguardanti l’ambito organizzativo (attori coinvolti e flussi informativi) con l’impiego delle tecnologie (di base e in via di svi-luppo) di supporto. In conclusione possiamo affermare che l’Home

Care rappresenta ormai una realtà importante nel contesto dei ser-vizi sanitari offerti tramite l’impiego delle tecnologie informatiche e della telecomunicazione (soprattutto per la teleassistenza viste le numerosa applicazioni). Lo sviluppo tecnologico permette di im-plementare soluzioni innovative nell’ambito delle cure domiciliari e, più in generale, della telemedicina tanto che si può addirittura parlare di ospedalizzazione domiciliare. Nel contesto nazionale lo scenario dell’Homecare è abbastanza vasto anche se sono di gran lunga maggiori i progetti riguardanti il telemonitoraggio domicilia-re rispetto a quelli riguardanti l’ADI (in via di sviluppo, soprattutto in questi ultimi anni) mentre, per il ricovero virtuale, attualmente vi è solo un possibile modello teorico; anche nel contesto europeo e internazionale, inoltre, l’impiego degli strumenti di ICT in ambito sanitario trova applicazione in molteplici campi di interesse.

5.7 Biometria per gli accessi

5.7.1 Introduzione

La forte diffusione delle reti e delle connessioni remote, con tutto il corollario di dispositivi portatili, di palmari e di altri dispositivi wireless, ha portato le aziende pubbliche e private a trattare come prioritario il tema della sicurezza dei dati e delle informazioni.

Si fa strada sempre più un nuovo approccio alla sicurezza, che ne modifica il concetto intrinseco spostando l’attenzione dalla classica accezione di protezione dai rischi e dalle minacce del mondo ester-no (virus, attacchi di hacker…) ad una concezione focalizzata sul valore e sull’importanza che i dati e le informazioni hanno.

L’Identity and Access Management, in questo contesto, assume una rilevanza strategica nella gestione della sicurezza, in quanto si occupa del controllo e della gestione delle “identità digitali” garan-tendo l’appropriata interazione tra i soggetti utilizzatori e le infor-

Identificazione automatica

Riconoscimento biometrico(feature extraction)

Trasporto dati(data carrier)

Caratteristiche statiche

Caratteristiche dinamiche

Proprietà chimico-fisiche

Memorizzazione ottica

Memorizzazione magnetica

Caratteristiche elettronica

Voce Digitazione (pressione)

Andatura (passo)

Firma dinamica

(pressione)

Banda magnetica

Non contact

MICF Memorie magneto-ottiche

Flying null holotag

Risonanza magnetica programmabile

Codice a barre

Codice a matrice

Optical Mark

Reading(OMR)

Optical Character

Recognition(OCR)

Memorie a contatto

Trasponder RFID

Memory Card

Senza Chip Con Chip SmartCard

Inlets & tags Contactless smart card

Visione industriale

Aspetti anatomici e biometrici

Altri sistemi di perturbazione

energetica

Sensori di proprietà chimica

Sensori di proprietà

fisica

Proprietà organiche

virus anticorpi

Naso elettronico

Impronte digitali

Geometria del viso

Retina e iride

Lineari Multiriga

Codici composti

Full matrix Dot codes

Figura 5.39Classificazione tecniche

di identificazione [Cascetta e De Luccia,

mazioni disponibili attraverso la rete.In ambiente sanitario molte aree di lavoro sono caratterizzate da

elevata criticità e delicatezza, per la natura dei dati trattati (dati sani-tari come cartelle cliniche, dati privati degli utenti, dati amministra-tivi…); la loro protezione diviene quindi fondamentale ed assume un ruolo centrale in tali ambienti, sia per i risvolti legati alla privacy sia per quanto riguarda i costi di gestione.

Lo scopo degli strumenti dell’Identity and Access Management è di:• proteggere la struttura da accessi ed utilizzi non autorizzati di

risorse informatiche o informative;• gestire il ciclo di vita delle identità digitali;• centralizzare il governo delle identità digitali evitando sovrap-

posizioni che possono tradursi in minacce per la sicurezza;• correlare le utenze alle persone fisiche che operano nella strut-

tura a qualsiasi titolo.

Arruolamento

Caratteristiche biometriche Sensore Controllo

qualitàEstrazione

caratteristiche

Verifica

Caratteristiche biometriche Sensore Matcher

(1 Match)

Estrazione caratteristiche

Vero/Falso Identità richiesta

Identificazione

Caratteristiche biometriche Sensore Matcher

(N Matches)

Database template

Databasetemplate

Estrazione caratteristiche

Identità del soggetto oppurenon identificazione

Biometrico Template

BiometriciN template

Computer

Biometrico Template

Conversione

Figura 5.40I processi biometrici Adattata da [NTSC, 2006]

È importante adottare un sofisticato sistema del controllo degli ac-cessi che sia in grado di ridurre al minimo i rischi di frodi o furti di identità e di contenere i costi di gestione del processo di autentica-zione, ed al contempo sia trasparente per l’utente e coerente con il ruolo ricoperto, senza risultare troppo oneroso in termini di tempo edattenzione.

Le password ed i token utilizzati per l’identificazione sono metodi di autenticazione “innaturali” e non possono attestare con sicurezza l’identità della persona, ma semplicemente garantire che l’utente sia a conoscenza di un’informazione o possegga un determinato oggetto.In questo contesto l’interesse verso le tecnologie biometriche è rapi-damente cresciuto (crescita riscontrata del 31,6% dal 2000 al 2005 – Tabella 5.13) grazie alla possibilità di basare il riconoscimento degli individui su dati certi quali caratteristiche fisiche e compor-tamentali, ragionevolmente uniche e non riproducibili [European Biometrics Portal-Unysis, 2006].

TECHNOLOGY 2000 2001 2002 2003 2004 2005 CAGR 5 anniFinger-scan 57.2 99.4 167.0 266.6 373.9 453.3 42.1%Facial recognition 13.1 31.3 63.3 105.9 151.0 199.6 55.7%Hand geometry 18.8 21.1 28.5 31.4 35.6 40.5 15.4%Middleware 11.4 24.2 49.9 111.2 190.0 307.5 67.7%Iris-scan 9.2 12.6 18.4 29.8 49.7 97.1 48.1%Voice recognition 6.2 8.8 20.6 42.8 70.5 130.6 62.5%Signature scan 3.0 5.5 11.4 28.5 64.1 101.1 72.5%Keystroke scan 0.0 0.7 2.2 7.2 9.1 12.5 59.0%Emerging Tech. Subtotal 118.9 203.6 361.3 623.4 943.9 1342.2 49.5%Automated Fingerprint ID system for law enforcement. immigration 282.0 320.6 367.8 426.2 496.3 563.4 13.9%

Total Biometric Market 400.9 524.2 729.1 1049.6 1440.2 1905.6 31.6%

Nel settore della sanità, la certezza identificativa diviene ancora più essenziale poiché è necessario:• poter accedere facilmente alle informazioni mediche storiche;• gestire correttamente il processo di cura;• distribuire prescrizioni mediche;• esportare procedure mediche;• avere a disposizione tecniche di autenticazione estremamente

affidabili sempre nel rispetto della privacy.Questi requisiti fanno del settore sanitario uno scenario ideale per l’implementazione e l’applicazione dei dispositivi biometrici.

Per maggior chiarezza (Figure 5.39-5.40), si riportano di seguito le definizioni di alcune terminologie ricorrenti nell’ambito di analisi di sistemi biometrici:• dispositivi trasporto dati (data carrier): comprendono tec-

Tabella 5.13Stima del mercato delle tecnologie biometriche

nologie finalizzate alla “raccolta, memorizzazione e trasporto” di dati e informazioni (prevalentemente codificati), su op-portuni supporti, come metodi ottici (codici a barre) oppure basati sulla memorizzazione magnetica (banda magnetica) o elettronica (RFID-tag, smart card, chip, ecc.);

• riconoscimento biometrico (feature extraction): contiene a sua volta 3 sottogruppi a seconda che il tipo di aspetto “estrat-to” si riferisca a un’immagine di un oggetto o di una persona (sistemi di visione), oppure sia attribuibile a un’azione dinami-ca della persona (voce, firma, andatura, ecc.), oppure, infine, sia associabile a una proprietà chimico-fisica del materiale co-stituente l’oggetto. Fa riferimento sia al processo di verifica sia al processo di identificazione;

• arruolamento o registrazione: fase iniziale del processo bio-metrico in cui viene creato e salvato il template personale re-lativo alla misura biometrica definita per successive verifiche di identità;

• verifica (1:1): processo di comparazione del template estratto da un campione biometrico (template corrente) con un unico template (template di riferimento) memorizzato in un sup-porto in possesso dell’utente o in un archivio. Se il grado di somiglianza (matching score) tra il template corrente e quello di riferimento è superiore alla soglia di decisione (decision th-reshold) viene ottenuta la verifica dell’identità;

• identificazione (1:N): processo di comparazione di un cam-pione biometrico con i template contenuti in un archivio allo scopo di identificare un individuo, ovvero di trovare un tem-plate il cui grado di somiglianza (matching score) è superiore alla soglia di decisione (decision thresold);

• autenticazione: processo attraverso il quale un individuo di-mostra la propria identità a un sistema informatico. Può avve-nire attraverso verifica di identità o identificazione.

5.7.2 Rassegna dei dispositivi

Questo capitolo intende analizzare la protezione dei dati sanitari in una prospettiva di “sostenibilità immediata” valutando le differenti soluzioni tecnologiche in commercio e le possibili alternative emer-genti, con particolare attenzione ai dispositivi biometrici.

È stata presentata ciascuna tecnica individuandone i principifi-sici di funzionamento e le caratteristiche peculiari, le quali risultano utili in fase di confronto tra differenti dispositivi sia secondo i nor-mali criteri descritti anche in bibliografia sia secondo altri criteri

individuali integrati a completamento, con particolare attenzione all’organizzazione richiesta per la gestione degli accessi [European Commission Joint Research Centre, 2005].

Le foto sono disponibili on-line nella raccolta di iconografia di sanità digitale.

5.7.2.1 Impronte digitaliLa tecnica si basa sulla scansione dell’immagine dell’impronta di-gitale con sensori di tipo ottico o capacitivo ed utilizza confronti basati su:• minuzie (minutiae), ossia caratteristiche “minori” come bifor-

cazioni o interruzioni delle rughe epidermiche (da 50 a 200 in un dito umano) estratte da algoritmi proprietari come “tem-plate” (8-20 kbyte per l’immagine completa contro meno di 1kbyte per il template) ed utilizzato poi per l’analisi compa-rativa

• pattern matching, ossia lo studio della corrispondenza di aree specifiche di impronta tra altre immagine completa (raw ima-ge): confronto con archivi in cui vengono immagazzinate im-magini complete delle impronte.I costi (dalla poche decine ad alcune centinaia di euro a secon-

da del tipo di dispositivo selezionato), accessibili ed in continua riduzione grazie alla costante introduzione di nuove tecnologie, ne fanno la tecnica più largamente diffusa e ne consentono l’utilizzo anche in dispositivi a tecnica multipla.

La figura è disponibile on-line nella raccolta di iconografia di sanità digitale. La scelta è ampia tra differenti produttori che si oc-cupano di questa tecnologia.

Le principali applicazioni riguardano 3 principali campi:• large-scale Automated Finger Imaging Systems (AFIS), gene-

ralmente utilizzate per scopi “legali”;• prevenzione della frode;• controllo degli accessi fisici ed al pc.

L’immagine è disponibile on-line nella raccolta di iconografia di sanità digitale.

5.7.2.2 Geometria della manoQuesta tecnologia si basa sul confronto di immagini tridimensionali della mano esaminandone la geometria spaziale attraverso la valuta-zione di un certo numero di parametri quali:• forma;• ampiezza;• lunghezza delle dita.

La fase di preparazione consiste nel posizionamento corretto del palmo della mano dell’utente sul lettore, allineandola con alcuni pioli disegnati per imporre una posizione appropriata alle dita ed altre parti significative della mano. Sono richiesti 3 posizionamenti sul dispositivo per l’arruolamento dai quali vengono estratti i dati principali generanti il template di riferimento di dimensioni estre-mamente ridotte (10 byte).

Le immagine sono disponibili on-line nella raccolta di iconogra-fia di sanità digitale.

Le possibili applicazioni sono molteplici, per lo più di verifiche dato il basso livello di distintivitàdella mano e delle dita.

Si tratta di una tecnologia con una buona evoluzione, che ha su-biti molti test su campo. È facilmente accettata dagli utenti e richie-de costi facilmente sostenibili (poche migliaia di Euro) se utilizzato standalonein combinazione di lettori di smart card o password, al fine di garantire migliori prestazioni soprattutto in termini di velo-cità di riconoscimento.

5.7.2.3 Morfologia dell’irideLa tecnologia si basa sullo studio della morfologia dell’iride, ossia sull’analisi delle caratteristiche dell’anello colorato che circonda la pupilla, con un elevato grado di unicità.

Necessita di una fase di preparazione che consiste nella scansione dell’iride mediante una video-camera ad una distanza di circa 40 centimetri, senza alcun contatto con il sensore.

Il suo modello viene costruito dall’insieme di legamenti musco-lari, colore e contrasto che sono determinati dalla pigmentazione. Ogni template contiene circa 24 immagini dello stesso occhio, rac-colte in 2 giorni differenti.

Malgrado le dimensioni dell’iride varino in funzione dell’illu-minazione ambientale (una forte luce fa restringere la pupilla e di conseguenza aumentare il raggio della corona dell’iride), gli algo-ritmi tengono conto di queste modifiche e dell’eventuale copertura superiore ed inferiore dell’iride dovuta alle palpebre.

La dimensione del modello è approssimativamente di 500 bytes.L’immagine è disponibile on-line nella raccolta di iconografia di

sanità digitale.Si tratta di una tecnologia che utilizza una caratteristica fisica

altamente distintiva e “robusta” e che quindi può essere utilizzata sia per identificazione che per verifica, con costi che variano a seconda che vengano implementati accessi logici o fisici (da poche centinaia a un migliaio di Euro).

5.7.2.4 Morfologia del visoSi tratta dell’analisi delle caratteristiche fisiche distintive del volto, tra cui il contorno superiore dell’incavo dell’occhio, le aree circo-stanti gli zigomi, la dimensione della bocca, la localizzazione di naso ed occhi, ecc....

È necessaria una registrazione di pochi secondi per acquisire più immagini statiche del viso, inquadrando l’utente da più angolazioni per ottenere anche modelli tridimensionale del viso.

La dimensioni del template varia da 100 a 3.500 byte. Il ricono-scimento del volto avviene attraverso una serie di tecniche:• “eigenface” che utilizza immagini 2D in scala di grigio rappre-

sentanti le principali caratteristiche del volto;• algoritmi basati su reti neurali in grado di determinare la simi-

larità delle caratteristiche rilevate nell’insieme globale di tutte le immagini del volto sia acquisite al momento sia registrate in fase di arruolamento;

• processamento automatico del volto basato sulla misura di al-cune distanze tra punti di riferimento del viso.

È ad oggi in fase di implementazione una tecnica 3D in grado di migliorare sensibilmente la capacità di distinzione tra più individui. Le immagini sono disponibili on-line nella raccolta di iconografia di sanità digitale.

Le applicazioni più frequenti sono:• il controllo degli accessi logici a pc;• la rilevazione clandestini e/o persone sotto copertura, grazie

alla possibilità di riprendere un viso anche a distanza con ap-posite telecamere;

• l’idenficazione di soggetti “indesiderabili” in alcuni ambienti (criminali e/o terroristi).

I costi, principalmente imputabili al software per il riconoscimento, anche in questo caso variano sensibilmente a seconda dell’imple-mentazione (dalle centinaia di Euro, normale costo di una teleca-mera per pc per accesso logico, a migliaia di Euro per telecamere di “sorveglianza”).

5.7.2.5 Albero vascolare della retinaIl metodo si basa sull’analisi della struttura dei vasi sanguigni pre-senti sul fondo dell’occhio, che risulta essere unica in ogni essere umano.

I dispositivi di acquisizione dirigono un fascio di luce a bassa intensità nella pupilla dell’utente, che deve accostare l’occhio al dispositivo per il tempo necessario alla cattura del campione ed all’estrazione del modello (generalmente dai 6 ai 10 secondi). La

dimensione del modello estratto è di circa 100 bytes.L’acquisizione può essere considerata ragionevolmente invasiva

per l’utente, necessita di una partecipazione attiva e consensuale di quest’ultimo.

Dati gli elevati costi di implementazione (oltre il migliaio di Euro) ed il basso grado di accettazione da parte degli utenti, tale tecnica trova applicazione soprattutto per il controllo degli accessi che necessitano di elevata sicurezza.

5.7.2.6 Albero vascolare di parti della manoAlcune caratteristiche dell’albero vascolare rimangono molto stabili nel tempo e la loro registrazione non prevede alcun contatto con de-vice elettronici. Queste caratteristiche hanno permesso lo sviluppo principalmente di 2 metodologie di identificazione.

Un primo metodo consiste nell’identificazione di un pattern di vasi sanguigni estratto dall’immagine digitalizzata ottenuta dalla riflessione da parte della mano (o parti di essa quali polso, dor-so, ecc…) del fascio NIR applicato alla stessa. In questo caso viene sfruttata la differenza d’assorbanza del sangue rispetto agli altri tes-suti.Dal pattern vengono ricavate diverse caratteristiche peculiari come i punti e gli angoli di diramazione, lo spessore dei vasi, ecc… che vanno a formare il template.

In alternativa il modello è catturato con una camera infrarossi ad alta risoluzione che consente la visualizzazione dell’albero vascolare. In pratica vengono rappresentati i vasi sanguigni come linee nere sull’immagine bianca del resto della mano, grazie alle caratteristiche di assorbimento della radiazione da parte della deossiemoglobina.Un algoritmo registra quindi le caratteristiche dei pattern dei vasi sanguigni del dito, o meglio del palmo della mano, e li archivia in un database per le future autenticazioni.

Questa tecnica, che non prevede alcun contatto con il disposi-tivo di acquisizione, viene normalmente utilizzata per il controllo degli accessi fisici che non richiedono elevato grado di sicurezza sia outdoor sia indoor, nella fattispecie per verifiche degli ingressi in cantieri, in università e scuole ed in reparti ospedalieri critici.

5.7.2.7 Traliccio del dermaNella famiglia delle tecniche biometriche è l’ultima nata, vista la dif-

ficoltà sino ad oggi riscontrata nell’utilizzo dell’analisi automatica delle caratteristiche della superficie dell’epidermide, e risulta avere ampie prospettive.

In aggiunta alle ovvie differenze di pigmentazione, la pelle di ogni individuo è strutturalmente unica. Gli strati della pelle variano in spessore, punti di contatto tra i diversi strati di pelle hanno dif-ferenti ondulazioni ed altre caratteristiche, le fibre di collagene, le fibre elastiche, la densità della rete di capillari e la loro localizzazione differiscono in ogni strato di pelle. La dimensione delle cellule e la loro densità all’interno degli strati epiteliali variano da persona a persona, così come la struttura chimica degli strati stessi.

HW ed SW riconoscono queste differenze della pelle e gli effetti ottici che questi producono. I sensori illuminano una piccola (0.4 pollici di diametro) porzione di pelle con diverse lunghezze d’onda (colori) di luce visibile e vicino all’IR.

La luce, riflessa dopo essere stata diffusa nella pelle è quindi misu-rata per ogni lunghezza d’onda. I cambiamenti che la luce ha subito, nel passaggio attraverso la pelle, vengono elaborati per estrarre un pattern ottico di caratteristiche da comparare con quello di riferi-mento per l’autenticazione.

Dato che il segnale ottico è sensibile ai cambiamenti chimici e ad altre proprietà della pelle umana, è possibile verificare in modo semplice la natura del tessuto analizzato nonché il fatto che si tratti di un tessuto vivo, poichè tessuti differenti (non umani, sintetici o non vivi) hanno proprietà molto diverse e quindi segnali ottici risultanti differenti

La tecnica utilizza dispositivi in grado di catturare immagini ad alta risoluzione e si avvale di un algoritmo, chiamato “Surface Texture Analysis”, che analizza la superficie della pelle ed estrae un template caratteristico mediante l’utilizzo di peculiarità quali im-perfezioni, assorbimento della luce, etc…

Questa metodologia può essere utilizzata come tecnica singola oppure in combinazione con altre (riconoscimento facciale o im-pronte digitali), al fine di garantire buone prestazioni di identifica-zione, elevato livello di accuratezza e robustezza comparabile a quel-lo di dispositivi multipli tradizionali (ad esempio riconoscimento del volto + impronta digitale) e possibili applicazioni potrebbero riguardare il controllo degli accessi.

5.7.2.8 Riconoscimento dell’unghiaIl riconoscimento dell’unghia è una tecnica biometria che può esse-

re implementata con 2 differenti metodologie:• base dell’unghia (struttura epidermica parallela localizzata

direttamente sotto l’unghia del dito formata da linee paralle-le spaziate ad intervalli sulla quale scorre l’unghia durante la normale crescita): si utilizza l’alta rifrangenza della cheratina contenuta al suo interno nell’interfaccia con l’unghia stessa;

• RFid dell’unghia: viene utilizzato un dispositivo RFid monta-to sull’unghia stessa il quale risulta sensibile alla capacità elet-trica dell’unghia, diversa per ciascun individuo.

L’immagine è disponibile on-line nella raccolta di iconografia di sa-nità digitale.

Le applicazioni commerciali, ancora poco diffuse in quanto si tratta di una tecnica biometrica emergente tuttora in fase di studio, potrebbero interessare svariati ambiti, dal controllo di sicurezza su computer, specialmente per le reti complesse, all’autenticazione di-namica con RFid in campo militare, governativo e settori privati in cui sia necessario il controllo degli accessi senza visibili stazioni di controllo (ad esempio prigioni, sicurezza aeroportuale o laboratori).

5.7.2.9 Morfologia dell’orecchioIn questo caso viene estrapolata un’immagine a livelli di grigio (da 300 a 500 livelli) del profilo della testa del soggetto utilizzando una videocamera CCD e viene utilizzato un metodo relativamente sem-plice basato sui contorni deformabili.

Il principale svantaggio di questa tecnica, nel caso di un sistema passivo di identificazione, è l’impossibilità di utilizzare l’immagine qualora l’orecchio del soggetto risulti coperto sebbene sia possibile, con opportuni algoritmi, riconoscere i capelli, segmentarli nell’im-magine e quindi escluderli.

Le tecniche esistenti per il riconoscimento dell’orecchio possono essere raggruppate in 4 classi:• Approccio globale• Punti di interesse (marcatori)• Termogramma• Modelli 3DLe immagini sono disponibili on-line nella raccolta di iconografia di sanità digitale.

Si tratta di una tecnica tuttora in fase di ricerca e sviluppo, uti-lizzata per lo più in ambito forense. Si può immaginare un suo uti-lizzo in combinazione con tecniche di riconoscimento del viso, per rendere più efficace l’identificazione, soprattutto per la gestione del controllo degli accessi fisici.

5.7.2.10 Dinamica della firma manualeQuesta tecnica analizza il modo con cui l’utente appone la propria firma, esaminando in particolare:• la velocità;• la pressione;• l’angolo d’inclinazione della penna;• il tempo impiegato;• l’accelerazione del movimento;• il numero di volte che la penna viene sollevata dalla carta;• caratteristiche distintive come la forma stessa della firma.L’utente appone la propria firma con una penna speciale o una ta-voletta, o entrambe, incorporanti sensori per rilevare le caratteristiche dinamiche distintive. La dimensione del modello è circa 1500 byte.

Si trovano poche applicazioni che utilizzano questo sistema, a pa-ragone di altre tecniche biometriche. La tecnica è adatta soprattutto per applicazioni dove la firma è un identificativo ben accetto; gode infatti di una certa popolarità negli ambienti bancari e finanziari, in cui l’apposizione della firma è una prassi frequente e, senza richie-dere un cambio delle abitudini da parte dell’utente o un particolare addestramento, permette un considerevole incremento di sicurezza.

L’immagine è disponibile on-line nella raccolta di iconografia di sanità digitale. I costi sono accessibili, legati soprattutto al software di riconoscimento (il costo di una tavoletta grafica si aggira intorno alle poche centinaia di euro).

5.7.2.11 Dinamica dattilograficaSi tratta di un metodo automatico di riconoscimento di un indivi-duo in base alla modalità individuale di digitazione sulla tastiera, rilevando caratteristiche peculiari quali velocità, pressione, tempo totale impiegato per inserire particolari parole ed il tempo di ritardo nella battitura di alcuni tasti.

Gli algoritmi di calcolo sono tuttora in sviluppo per migliorare la robustezza del sistema e la distintività.

L’applicazione assume una particolare significatività nel controllo degli accesso ai pc, dove questa caratteristica biometrica può essere utilizzata anche in modalità dinamica (controllo ”in continuo”) sen-za richiedere particolari implementazioni hardware.

5.7.2.12 Spettro della voceÈ una tecnica che utilizza gli aspetti caratteristici della voce umana per verificare l’identità di un individuo attraverso pass-phrases. La

cattura del campione può avvenire con dispositivi tradizionali quali microfoni o ricevitori telefonici.

Nelle applicazioni “text dependent”, si richiede all’utente di ripe-tere una frase predefinita (es. una sequenza di numeri) per diverse volte, cosicché la fase di “enrollment” risulta generalmente più lun-ga rispetto agli altri sistemi biometrici.

La dimensione del modello è piuttosto consistente, nell’ordine delle migliaia di bytes.

È considerato tecnicamente un ibrido tra una biometria di tipo fisico ed una comportamentale, dal momento che l’emissione della voce è determinata sia dalla conformazione della gola e della laringe ma anche da aspetti legati al comportamento.

Si tratta di una tecnica biometrica con ampie possibilità di uti-lizzo, poiché risulta economica e largamente accettata dal pubblico, essendo naturale (es. uso del telefono); tuttavia può essere affetta da alcune problematiche quali disturbi e rumori di fondo.

Viene usata soprattutto in combinazione “voice authentication vs. speech recognition+positioning technology”.

Il costo preponderante è rappresentato, anche in questo caso, dal software di riconoscimento (dalle centinaia di Euro in su).

5.7.2.13 Analisi del movimentoQuando una persona cammina, le parti del corpo (gambe, ginoc-chia, braccia, gomiti ed altro), creano un particolare pattern ripeti-tivo nel loro movimento nello spazio.

Una videocamera è in grado di catturare questi punti di movi-mento ed analizzarli mediante procedure informatizzate. Il com-puter individua i movimenti e stabilisce una relazione matematica per ogni punto creando così una sorta di “firma” individuale su cui basare il riconoscimento personale.

Il riconoscimento automatico delle persone per mezzo del movi-mento è tuttora in fase di studio poiché si tratta di una caratteristica comportamentale a bassa unicità, permanenza e sicurezza malgrado abbia elevata accettabilità da parte degli utenti.

Risulta oggetto di molte ricerche a livello universitario trattando analisi di sequenze di immagini, con elevati tempi di calcolo e uti-lizzo di modelli complessi.

Possibili applicazioni future (al momento non esistono sistemi commerciali di verifica di identità) di questa metodologia si focaliz-

zano sul riconoscimento personale a distanza mediante l’utilizzo di videocamere a bassa risoluzione per ambiti di difesa perimetrali ed installazioni militari.

Le immagini sono disponibili on-line nella raccolta di iconogra-fia di sanità digitale.

5.7.2.14 Analisi del movimento delle labbraÈ basato sull’idea che il movimento delle labbra effettuato mentre si parla sia unico per ciascuna persona.

Dalle prime 16 immagini della sequenza video registrata durante la pronuncia di una frase, vengono estrapolate le caratteristiche mi-miche di un’area di interesse (AOI) attorno alle labbra.

Sulla posizione stimata degli occhi, in base alle conoscenze an-tropomorfiche, viene individuata la posizione dell’area di interesse. Tracciando l’intero volto, mediante un dispositivo di tracciamento del movimento, si compensano i movimenti involontari causati dal cambio di posizione della testa; le immagini vengono inoltre elabo-rate per eliminare l’influenza dell’illuminazione.

Il riconoscimento del movimento delle labbra è solitamente uti-lizzato in combinazione con altre tecniche biometriche, non poten-do garantire, se utilizzato singolarmente, un livello di accuratezza sufficientemente elevato.

Sono in corso anche studi sull’utilizzo della forma delle labbra come caratteristica biometrica, ma non esistono per ora implemen-tazioni.

5.7.2.15 DNAÈ possibile creare un profilo DNA grazie all’utilizzo di tecniche particolari in grado di estrapolare specifiche regioni del DNA “non codificate”, ossia regioni che non consentono l’identificazione ge-netica.

È una tecnica con elevata accuratezza dove le esclusioni sono as-solute e l’identificazione è espressa in termini di probabilità.

Al momento è molto utilizzato in ambito forense, malgrado non consenta identificazioni in tempo reale, ma ci si aspetta in futuro dei kit capaci di creare un pattern DNA nell’arco di pochi minuti, evoluzione che potrebbe espanderne l’utilizzo a scopo d’identifica-zione personale.

L’uso del DNA ha i suoi aspetti negativi:• gemelli identici non sono distinguibili tra loro utilizzando il

DNA;• esistono problemi etici in quanto sarebbe possibile arrivare a

conoscere informazioni mediche relativamente a malattie e/o

comportamenti personali, accrescendo quindi il rischio di di-scriminazioni o la moltiplicazione di procedure di test obbli-gatori;

• si tratta di una tecnologia molto costosa sia in termini di tem-po che economici, non essendo ad oggi un processo completa-mente automatizzato che richiede quindi l’intervento umano.Le immagini sono disponibili on-line nella raccolta di iconogra-

fia di sanità digitale.

5.7.3 Dispositivi a tecnica multipla

5.7.3.1 IntroduzioneCome già trapelato durante le l’analisi delle singole tecniche bio-metriche, la spinta all’implementazione di sistemi di identificazione basati su tecniche multiple si basa soprattutto sulla possibilità di ottenere una maggiore distinguibilità degli utenti, in caso di im-plementazioni ad elevato grado di sicurezza, e sulla capacità di ga-rantire una maggiore flessibilità in caso di integrazione di metodi alternativi. Questo permette l’ampliamento dell’universo degli uti-lizzatori ed una maggiore usabilità dei dispositivi.

Per dispositivi a tecnica multipla si intendono:• combinazioni di supporti di memorizzazione magnetica-elet-

tronica con dispositivi biometrici che consentono di ovviare ai problemi relativi alla privacy (viene privilegiata l’identificazio-ne 1:1 rispetto all’autenticazione 1:N evitando la registrazione dei template dei dati personali in database remoti) garantendo anche minori problematiche di gestione dei template (minori spazi necessari da dedicare per lo stoccaggio dei modelli) e, di conseguenza, minori costi di acquisto e gestione);

• combinazioni di molteplici tecniche biometriche, in sequenza o in parallelo.

5.7.3.2 Combinazioni più frequentiDi seguito riassumiamo le combinazioni più frequenti correlate al loro impiego:• morfologia viso + impronta digitale:

consente di combinare una maggiore velocità di elaborazione data dal riconoscimento del volto (scrematura dei template nel database) con la maggiore accuratezza assicurata dal controllo delle impronte digitali (che hanno un tempo di elaborazione maggiore ma lavorano su un database ridotto dalla prima tec-nica biometrica);

• morfologia viso + orecchio:con le medesime caratteristiche sopra indicate aggiungendo il vantaggio di un dispositivo che non necessita alcun contatto fisico;

• morfologia viso + movimento delle labbra + spettro della voce:è proposta normalmente per accessi logici perché consente una maggiore accuratezza della tecnica di riconoscimento facciale utilizzata singolarmente, mantenendo costi di implementazio-ne ridotti;

• morfologia viso + impronta digitale + geometria della mano:vengono utilizzati molteplici tratti biometrici aventi pesi diversi a seconda delle caratteristiche intrinseche del soggetto, in modo da rendere meno “influenzabile” il riconoscimento (persistente secchezza delle mani, scarsa fotogenicità, ecc…);

• iride + retina:consente, utilizzando la biometria complessiva dell’occhio, di ridurre la quantità di dati richiesti dalla tecnica di riconosci-mento dell’iride usata singolarmente poiché elaborando un pattern congiunto tra dati dell’iride e della retina viene mante-nuta un’elevata accuratezza ma con ridotti spazi dei template;

• impronta digitale + traliccio del derma:consente di migliorare la capacità del sistema di riconoscere le impronte digitali grazie all’integrazione con l’analisi spettrale della pelle e diminuire la probabilità di contraffazione (spoof )supporti di memorizzazione elettronica e/o magnetica + diffe-renti tecniche biometriche.

Esponiamo in seguito alcuni criteri di valutazione suggeriti dal CNIPA, Centro Nazionale per l’Informatica nella Pubblica Ammi-nistrazione, di cui tener conto nel caso di implementazioni di siste-mi biometrici, al fine di giungere ad una scelta consapevole [CNI-PA, 2005] [CNIPA, 2004].

Criteri di valutazione CNIPAA. Sicurezza

A.1. Accuratezza A.1.1. FAR (False Acceptance Rate) A.1.2. FRR (False Rejection Rate) A.1.3. ROC e DET A.1.4. EER (Equal Error Rate) A.1.5. ZeroFAR A.1.6. ZeroFRR

A.2. Resistenza ai tentativi di inganno con false caratteristiche biometriche

A.2.1. Vivezza A.2.2. MimicaA.3. Resistenza ai tentativi di manomissione

B. Robustezza B.1. Rispetto all’accuratezza dell’acquisizione B.2. Rispetto alla stabilità della caratteristica biometrica B.3. Rispetto ad alcuni soggetti, popolazioni, lavoratori B.4. Rispetto all’ambiente

C. Usabilità C.1 Interazione con l’utente

C.1.1. Semplicità d’uso C.1.2. Praticità d’uso C.1.3. Necessità di addestramento dell’utente o supervisio-

ne iniziale C.1.4. Criticità della fase di enrollment

C.2. Interazione con l’amministratore del sistema C.2.1. Praticità d’uso C.2.2. Strumenti di controllo e di monitoraggio C.2.3. Necessità di supervisione C.2.4. Necessità di manutenzione

C.3. Efficienza C.3.1. Tempo di enrollment C.3.2. Tempo di verifica/identificazione

D. Accettabilità D.1. Della caratteristica biometrica D.2. Delle operazioni di enrollment e di verifica/identificazione

E. Miscellanea E.1. Costo E.2. Ingombro E.3. Dimensione dell’identificativo biometrico E.4. Aderenza a standard E.5. Integrabilità con altri sistemi E.6. Adattabilità rispetto a specifiche applicazioni o ambienti

operativi

Si focalizza l’attenzione su alcuni criteri di valutazione ritenuti par-ticolarmente importanti (Tabella 5.14), di cui si riportano alcune considerazioni:

Universalità:È molto importante per determinare l’effettiva applicabilità del si-stema in un determinato ambiente tuttavia, essendo un parametro di valutazione solitamente rapportato a contesti applicativi “limita-ti” nell’ambito ospedaliero, risulta un vincolo meno stringente.

Costo:Da questo punto di vista le tecnologie a minor impatto economi-co risultano quelle applicate all’analisi spettrale ed alle impronte digitali, che consentirebbero quindi una diffusione su larga scala. Entrambe presentano, però, alcune limitazioni applicative impor-tanti, come il rumore di sottofondo per il riconoscimento vocale e la presenza di sporco o di guanti per quanto concerne l’identifica-zione personale mediante il riconoscimento delle impronte digitali. Tali limitazioni non consentono una diffusione così capillare della tecnica biometrica più economica a vantaggio di tecniche più accu-rate ed efficienti anche più onerose, a patto di limitarne l’utilizzo a particolari settori.

Accuratezza:La maggiore accuratezza si ritrova nelle metodologie legate al rico-noscimento delle caratteristiche oculari come retina ed iride, che risultano per contro le tecniche economicamente più onerose. Que-sta caratteristica ne riduce i possibili campi applicativi, favorendone l’implementazione solo in particolari settori nei quali il costo sia giustificato da necessità di elevati gradi di controllo e di sicurezza.

Tabella 5.14Comparazione relativa

ad alcuni dei parametri di valutazione esposti.

Adattato da [CNIPA, 2004]

Impronte Geometria della mano

Iride Viso Voce Firma

Accuratezza Alta Medio/alta Molto alta Media Medio/bassa

Medio/bassa

Accettabilità Medio/alta Medio/alta Alta Alta AltaUsabilità Medio/alta Alta Medio/alta Alta Alta AltaStabilità nel tempo della caratteristica fisico/comp.

Alta Media Alta Medio/bassa Media Medio/bassa

Costo del sensore Basso Medio Basso/alto Medio/alto Basso Medio

Dimensioni del template

800-1500 byte 10 byte 512 byte 1000-2000 byte

2000-10000 byte

1500 byte

Maggiori cause di errore

Aria troppo seccaScarsa

accettazione polpastrello sporco e/o rovinato

Lesioni traumatiche della mano

Condizioni di illuminazione

danneggiamento dell’occhio

Rumori di fondoScarsa

accettazione polpastrello sporco e/o rovinato

Media Media

Dimensioni del template:Requisito importante per valutare la tipologia di riconoscimento (identificazione o verifica) e, quindi, la conseguente implementazio-ne tecnica, preferendo supporti di memorizzazione al portatore per template di dimensioni ridotte con processi di verifica più rapidi, maggiore tutela della privacy e maggiore integrabilità in sistemi di controllo preesistenti.

Invasività:I dispositivi presenti sul mercato non presentano alcuna pericolosi-tà, tuttavia è necessario valutarne l’impatto sull’utente:• la necessità di contatto fisico con il sensore può causare proble-

matiche di igiene, in determinati contesti caratterizzati da un numero elevato di utenti, che possono compromettere l’uso della tecnica

• la percezione relativa a livello di invasività della tecnica, come nel caso di tecniche che coinvolgono gli occhi;

• la preoccupazione relativa alla gestione dei dati personali;• possono compromettere l’uso della tecnica biometrica e det-

tarne la scelta.

5.7.4 Criteri di scelta in ambito sanitario

La certezza identificativa, come già evidenziato nella parte intro-duttiva del capitolo, è una caratteristica essenziale nella gestione dei dati in ambito sanitario che si contrappone alla necessaria privacy dovuta alla loro natura sensibile. Tenere conto di tale dicotomia nel-la scelta dei dispositivi di accesso ed identificazione, già dalla fase di progettazione, risulta fondamentale.

La scelta della tecnologia biometrica deve assolutamente sempre dipendere dal contesto di utilizzo e dalle necessità applicative, fa-cendo una dettagliata analisi costi-benefici, anche relativamente alla diffusione dei dispositivi.

Inoltre, nel settore medico, ci sono fattori aggiuntivi da tenere in considerazione [Dolan, 2006]:• le impronte digitali non possono essere utilizzate in ambienti

in cui gli utenti utilizzano guanti in lattice;• il riconoscimento del volto non può essere implementato in

luoghi in cui si lavora con la mascherina chirurgica;• lo spettro vocale non può essere introdotto in ambienti ru-

morosi;• nel caso di accessi in rete, non è possibile pensare di accedere

a documenti in modalità remota da un pc portatile mediante

l’identificazione della morfologia dell’iride, considerati i costi e gli ingombri dei dispositivi necessari;

• è inoltre indispensabile ricordare che, in un ambiente ospe-daliero in cui la minimizzazione dei fattori di rischio assume una particolare importanza, risulterebbe più opportuno evita-re l’utilizzo di lettori che necessitano un contatto fisico (come, ad esempio, i lettori di impronta digitale).

Tenendo conto di queste ed ulteriori considerazioni, si riportano di seguito alcune possibili applicazioni e/o scenari in ambito sanitario:

Controllo degli accessi fisici ai magazzini di particolari prodotti far-maceutici (prodotti tossici, stupefacenti…) e/o laboratori con ca-ratteristiche peculiari di sicurezza/pericolosità (ad elevato rischio chimico o biologico oppure contenenti materiali costosi o “prezio-si”)Smart-cards+morfologiadell’iride:consentirebbe un riconoscimento sicuro e privo di contatto dell’identità dell’utente che accede ad ambienti con particolari ca-ratteristiche di sicurezza, con possibilità di implementare controlli ulteriori dell’appropriatezza d’uso mediante un tag RFid applicato sul materiale prelevato. Per contro tale tecnologia potrebbe compor-tare un aggravio delle tempistiche operative dovute alla maggiore procedurizzazione necessaria.

Sicurezza identificativa per i pazienti ricoveratiImprontadigitale:consentirebbe sia di ridurre o persino evitare gli errori commessi alla registazione del paziente, stimati nella misura del 30%, per quanto concerne duplicazione dei record per lo stesso paziente (con possi-bili divisioni in più parti dei dati clinici registrati) e/o sovrascrittura dei record per pazienti diversi erroneamente identificati (con possi-bili conseguenze sulle somministrazioni) sia di permettere l’identi-ficazione di pazienti che non sono in grado di dichiarare la propria identità.

Controllo corretta attribuzione madre-neonato nel reparto maternità

DNA:consentirebbe la corretta attribuzione madre-neonato. In que-sto caso le gestanti verrebbero sottoposte ad un prelievo di DNA all’ospedalizzazione che, una volta analizzato, sarebbe registrato come template da collegare, in un database in sola lettura, a quello del bimbo appena nato, creato alla nascita tramite medesimo pre-

lievo. I template sarebbero poi eliminati una volta dimessi madre e neonato.RFid:consentirebbe la corretta attribuzione madre-neonato mediante l’utilizzo di appositi braccialetti su cui viene apposto il tag RFid.

Controllo degli accessi al reparto maternitàQualsiasidispositivobiometricodicontrolloaccessofisico:aumenterebbe il livello di sicurezza del reparto mediante un pun-tuale controllo degli accessi per evitare il prelievo dei neonati da parte di estranei. Tale soluzione risulta applicabile solo su bassa scala in quanto limita il numero di utenti che possono accedere al reparto stesso (impronta digitale, iride…).

Telecare o Home healthcareImprontadigitalee/omorfologiadell’iride:consentirebbero una maggiore sicurezza, rispetto alle password, nell’accesso ai dati sensibili da postazioni in remoto con costi tutta-via non sempre accessibili.

Controllo degli accessi ai dati sensibili in remoto Qualsiasichiave/caratteristicabiometrica:consentirebbe la registrazione dei dati medici in un ambito di pri-vacy completo grazie alla mancanza di associazione diretta ai dati identificativi personali, sostituiti dalla chiave biometrica scelta. In questo scenario l’unico utente autorizzato all’accesso è il proprieta-rio stesso dei dati. Il lato negativo è dato sia dalla necessità di utiliz-zare sistemi tecnologicamente avanzati in grado di gestire autentica-zioni 1:N complesse sia dal bisogno di poter risalire ai dati nel caso in cui la chiave biometrica dovesse cambiare per qualsiasi motivo.

Controllo degli accessi per funzioni “amministrative”Dinamicadattilografica:consentirebbe di evitare problemi di dimenticanze ed aggiornamen-ti delle password in uso, anche se incontra riluttanza da parte degli utilizzatori poiché induce “controlli” dell’operatività.

Controllo degli accessi ai dati sensibili Improntadigitale:consentirebbe, mediante un lettore per ogni postazione pc, un controllo puntuale degli accessi alle informazioni sensibili (grazie all’aggiunta di supporti di gestione dei privilegi d’accesso) a costi ridotti. Rimane l’aspetto “negativo” del contatto fisico con il lettore

risolvibile con operazioni frequenti di pulizia.Spettrodella voce e/odinamicadattilografica e/o tralicciodel dermae/oRFid:consentirebbero di eliminare, pur mantenendo un elevato gradi di accuratezza, i problemi riscontrati con l’utilizzo sanitario del rico-noscimento tramite impronte digitali (lozioni sulle mani del perso-nale medico, guanti e altri dispositivi che interferiscono con il let-tore oltre a problemi di contaminazione incrociata, che implicano problemi di tempo per la pulizia del sensore).Morfologiadell’alberovascolaredipartidellamano:consentirebbe di scavalcare il problema di accettazione da parte de-gli utenti rispetto all’utilizzo di tecnologie biometriche poiché non esige un contatto fisico diretto con i dispositivi e può essere utiliz-zato da chiunque.

Controllo distribuzione farmaci e/o stupefacenti Improntadigitale:consentirebbe il controllo delle somministrazioni di farmaci e/o stupefacenti (es. metadone) al fine di accertare, a costi ridotti, che i partecipanti ad un programma di disintossicazione abbiano la cor-retta dose di droga.

5.8 La sanità digitale per la famiglia

5.8.1 Introduzione

5.8.1.1 Personalized Health InformaticsL’informatica medica Personalizzata (Personalized Health Informa-tics - PHI), ideata da Josè C. Lacal pochi anni orsono, è definita come l’insieme degli strumenti basati su Internet che posizionano l’individuo al centro di un disegno architetturale di servizi atti alla promozione e al miglioramento della salute. La PHI offre una piat-taforma di servizi basata su standard aperti, centrata sulla persona, personalizzata, focalizzata sulla famiglia e orientata alla prevenzione per mantenere o migliorare la salute dell’individuo. Questo utiliz-zando in maniera adeguata gli sviluppi delle tecnologie informati-che, gli strumenti di comunicazione e l’evoluzione delle reti, anche wireless [Lacal, 2004].

Maggiori evidenze a questo concetto arrivano da come le cose si sono evolute negli anni con lo sviluppo della “Personalized he-althcare (pHealth)”, spinta dall’importante consapevolezza che si-stemi centralizzati di gestione della sanità sono necessari ma non sono in grado, da soli, di coordinare tutti gli aspetti relativi alla valutazione dello stato di un paziente all’interno della realtà sanita-ria. Serviva qualcosa di più, bisognava spostarsi ad una visione “pa-tient-centred”, ossia collocare il paziente al centro del sistema. E per fare questo è stato necessario considerare tutti gli aspetti che sono coinvolti nel garantire a un cittadino un buono stato di salute; non solo, quindi, l’assenza di malattie ma anche lo stile di vita, l’ambito nutrizionale, la conoscenza medica, la dipendenza da farmaci, ecc. Tutto questo non può ovviamente prescindere dalla partecipazione attiva del paziente stesso.

Quindi, in generale, la PHI è l’insieme degli arnesi dell’Infor-mation & Communication Technology (ICT) – concetti, metodi e dispositivi – in grado di aiutare il graduale ma completo sviluppo della pHealth. I prodotti della PHI hanno lo scopo di rendere più facile – sempre e comunque – per il paziente, l’utilizzo dei dati ri-guardanti la propria salute, anche quando questi sono conservati in archivi istituzionali. Un altro scopo è quello di incaricare il pazien-te della gestione, seppur in maniera periferica, dei suoi documenti clinici, coinvolgendolo in questo livello di responsabilità. Per fare questo, il paziente non va incontro a nulla di completamente nuo-vo: anche prima dell’era digitale, infatti, è sempre stata buona prassi quella di conservare i documenti, lastre e referti cartacei, relativi alla propria storia clinica.

La PHI può fare tutto questo attraverso l’utilizzo delle tecnologie informatiche. Come detto, l’idea di raccogliere e conservare i docu-menti cartacei relativi alla propria salute non è nuova; la diffusione delle tecnologie dell’informazione e della comunicazione (ICT) e di internet ha reso l’idea attuabile mediante l’utilizzo di personal computer e/o smart-phone. La cartella clinica digitale (Electronic Health Record – EHR) declinata nell’ambito della PHI ha portato alla definizione di Personal Health Record (PHR): “Un’applicazio-ne elettronica attraverso cui gli individui possono accedere, gestire, condividere le informazioni relative alla propria salute, e a quella di coloro che hanno concesso l’autorizzazione, in maniera riservata, sicura e protetta” [Markle Foundation, 2003].

Questa definizione evidenzia quali sono gli aspetti che caratte-rizzano i Personal Health Record, se paragonati agli EHR. Innan-zitutto, non viene nominato “il paziente” ma l’attore principale è l’individuo, inteso come consumatore. Come secondo aspetto, i sistemi PHR hanno l’obiettivo di fornire informazioni sullo stato di salute di un individuo, mentre i sistemi EHR forniscono l’in-formazione necessaria ai professionisti della sanità. Inoltre la PHR può essere utilizzata per gestire lo stato di salute di un individuo ma anche di tutti coloro di cui l’individuo in questione si occupa [Markle Foundation, 2003]. Infine un PHR non può essere con-siderato come un mero contenitore statico di dati ma è l’insieme di “dati, conoscenza e arnesi informatici” per aiutare le persone ad assumere un ruolo attivo nei riguardi della propria salute. Un altro aspetto, poi, è connesso con l’affidabilità dei dati conservati in un PHR: la sua architettura richiede che i dati che vengano immessi da chi utilizza il sistema. Questo implica che la qualità dei dati inseriti dipende fortemente da ciò che viene memorizzato, dalle conoscenze in ambito medico sanitario di chi mantiene l’applicazione e dalla sua personale motivazione nel collezionare i documenti relativi alla salute.

5.8.1.2 Recenti approcci al Personal Health RecordNello scenario internazionale sono stati proposti diversi approcci ai PHR, ciascuno focalizzato su un particolare aspetto della gestione dei dati. In un recente studio effettuato dal punto di vista del con-sumatore, gli autori hanno individuato gli elementi ritenuti mag-giormente importanti per gli utilizzatori quando si avvicinano alle cartelle cliniche informatizzate: il controllo personale sui dati, la condivisione di informazioni e la loro integrazione, la sicurezza e la flessibilità [Civan et al, 2006 ].

Molti sistemi sono stati progettati seguendo queste indicazioni.

In [Kim et al., 2005] è stato proposto un sistema per superare quello che viene definito “digital divide”. È stato progettato e implementa-to un sistema di cartella elettronica informatizzata centrata sul pa-ziente ospitato in una residenza per anziati. Il sistema è stato testato su una popolazione anziana e non esperta di computer che, con l’aiuto di una strategia di condivisione e supporto e con l’assistenza di personale infermieristico, ha dimostrato di essere in grado di ge-stire i documenti relativi alla propria salute [Kim et al., 2005]. Que-sto studio indica come che l’allenamento e il supporto tecnologico sono gli aspetti essenziali per il successo di un sistema PHR, special-mente quando il bacino di utenti non ha sufficienti conoscenze ICT per gestire il sistema, come nel caso delle persone anziane.

La gestione a livello di famiglia verticale, multigenerazionale, delle informazioni relative alla salute è responsabilità del singolo “assegnatario”, coinvolto in prima persona nel reperimento dei dati, nella loro gestione, organizzazione e archiviazione. Sono state in-dividuate differenti strategie di raccolta e archiviazione delle infor-mazioni sanitarie e documenti clinici in ambito domestico [Moen e Brennan, 2005]: 1) “just-in-time”, questa strategia prevede che le informazioni e i documenti siano sempre con e a portata di mano del responsabile dei dati della famiglia; 2) “just-at-hand”, questa strategia prevede che le informazioni e i documenti siano sempre visibili, oppure presenti in un luogo conosciuto e immediatamente accessibile, al responsabile dei dati della famiglia; 3) “just-in-case”, questa strategia prevede che le informazioni e i documenti siano presenti in un luogo conosciuto e raggiungibile in breve tempo (pochi minuti) dal responsabile dei dati della famiglia; 4) “just-be-cause”, questa strategia prevede che le informazioni e i documenti immediatamente disponibili siano quelle relativi ad eventi clinici/sanitari recenti. Queste strategie dovrebbero essere rese disponibili negli applicativi software dedicati all’informatica medica persona-lizzata [Demiris et al., 2008].

Un elenco di applicazioni web di Personal Health Record sono descritti e presentati in [Kim e Johnson, 2002]. Questi sistemi di PHR non sono però realizzati appositamente per la famiglia, inte-sa come entità singola, e non contengono strumenti per la verifica della bontà di compilazione delle varie parti. Inoltre, volendo ap-plicare tali sistemi ad un ambito familiare, la famiglia deve essere considerata come un insieme di singoli individui, senza considerare le relazioni che la caratterizzano, perdendo così preziose informa-zioni di come l’anamnesi patologica remota delle generazioni più antiche presenti nell’albero genealogico possa influenzare quelle più giovani.

5.8.1.3 L’approccio “family PHI”L’idea di “mantenere un corretto stile di vita” risiede in ciascuno degli individui che compongono una famiglia. Sicuramente però ognuno di essi declina l’idea a seconda del proprio stato di salute e del proprio modus vivendi. Da sempre, nella famiglia verticale, multigenerazionale, la generazione di mezzo si è presa cura dei do-cumenti sanitari anche per la generazione precedente e successiva. Ora, le potenziate conoscenze digitali, entrate nelle famiglie sull’ab-brivio di spinte pur esterne alla Salute, garantiscono alla famiglia verticale un certo livello di “digital inclusion”, che richiede nuovi prodotti e servizi di Sanità Digitale.Nell’era pre-digitale, la stessa generazione di mezzo si è preoccupata di conservare i documenti in forma cartacea; e questo accade anche attualmente, considerando per ognuno le proprie conoscenze mediche e le abilità informatiche. Quindi: perché non usarle per la migliore gestione dello stato di salute della famiglia verticale? Un’altra importante considerazione è che al di là della propria storia clinica personale, il modo di vivere e l’ambiente in cui si vive sono elementi che ognuno ha generalmente in comune con i membri della propria famiglia. Per esempio, con-sideriamo l’anamnesi familiare dei figli e delle figlie di una deter-minata coppia; sarà sostanzialmente simile per i fratelli e le sorelle quindi potrà essere inserita una sola volta nel sistema di gestione della cartella clinica di famiglia. Anche l’ambiente familiare è il me-desimo, quindi potrà essere inserito una sola volta. Generalmente anche lo stile di vita in casa è lo stesso e sono anche prevedibili dei possibili eventi, legati alla salute di uno dei membri della famiglia, che influiscano su tutto il nucleo familiare. Questi sono esempi di come le informazioni inserite una sola volta con l’aiuto di arnesi informatici possano tornare utili in più circostanze.

È esperienza comune che coloro i quali necessitano della maggio-re assistenza all’interno di un nucleo familiare (bambini e anziani) siano anche i meno esperti nell’ambito degli strumenti di ICT, o comunque non lo siano abbastanza da poter gestire e organizzare le informazioni relative al proprio stato di salute in un Personal Health Record (PHR) [Lober et al., 2006].

Contrariamente, la generazione di mezzo di una famiglia vertica-le, multigenerazionale, utilizza giornalmente strumenti dell’ICT, al lavoro o per interessi personali, ed è pertanto in grado di organizzare i dati dell’intero nucleo familiare in un PHR.

Il livello di conoscenze nel campo dell’ICT dipende ovviamente dal grado di scolarità, dal tipo di lavoro e dagli interessi personali di ciascuno. È comunque lecito pensare, però, che questa generazione dopo un’adeguata fase di addestramento possa essere in grado di

gestire questo tipo di applicazione. Per questo, l’idea di sviluppare un “Family Health Record” appare senza dubbio ragionevole.

Ha senso quindi anche parlare di un “Family Health Data Mana-ger (FHDM)”, cioè di un gestore dei dati sanitari della famiglia: è tipicamente uno dei genitori, che ha le motivazioni e le capacità per gestire questo tipo di applicazione.

Se consideriamo una famiglia libera da conflitti – dove per con-flitti si intendono eventuali impedimenti di concessione dell’accesso e gestione dei dati e delle informazioni relative alla salute da parte di altri membri delle famiglia stessa – i dati sono digitati e inseriti nel sistema dal “Family Health Data Manager”, che si occuperà anche di inserire nel sistema i dati relativi allo stile di vita e alla storia cli-nica degli altri componenti nel nucleo familiare. Siccome il FHDM non è un professionista dell’ambito medico-sanitario, deve essere opportunamente assistito in modo da evitare errori nell’immissio-ne dei dati. L’inserimento di dati scorretti o incompleti, infatti, ne preclude il corretto futuro utilizzo da parte di medici e clinici. Per superare questo ostacolo, i dati immessi devono essere visionati e approvati da un professionista della sanità prima di essere effetti-vamente registrati all’interno della cartella informatizzata. A que-sta figura diamo il nome di “Matching Evaluator – (ME)”, che si occuperà di verificare l’adeguata bontà di compilazione delle parti della cartella clinica da parte del FHDM. Inoltre, per raggiungere un adeguato livello di protezione dei dati e per rendere il sistema più sicuro, la trasmissione e l’archiviazione dei dati avviene appli-cando algoritmi di crittografia. Dati immagazzinati localmente o su dispositivi portatili devono essere maggiormente protetti dalle minacce; le prime esperienze di questo tipo di dispositivi di archi-viazione hanno, infatti, mostrato bassi livelli di affidabilità [Wright e Sittig, 2007].

La disponibilità di un’interfaccia grafica user-friendly e la possi-bilità di inserire i dati una sola volta, impiegandoli poi frequente-mente (“fill once and use many times”) sono sicuramente caratteri-stiche che accrescono l’usabilità di un’applicazione di questo tipo. Un vantaggio dei PHR rivolti al gruppo di famiglia è la possibilità di effettuare interrogazioni sull’insieme delle informazioni relative al nucleo familiare per avere riscontri su patologie comuni a più membri della famiglia, sulle terapie effettuate e i momenti in cui si sono verificate.

5.8.1.4 Elementi che danno valore al sistemaNel dominio della PHI, il paziente/consumatore, il medico di base, il medico specialista e la comunità dei clinici sono i maggiori attori.

Ognuno di essi deve agire a seconda dell’ambiente nel quale sta operando: la casa, l’ospedale e l’ambulatorio sono ambienti tipici dove gli attori sopra indicati svolgono le funzioni di compilazione, archiviazione e interrogazione dei documenti clinici, con l’obiettivo primario di salvaguardare il proprio o l’altrui stato di salute. Nella PHI l’archiviazione dei documenti deve essere rispettosa di un in-sieme di procedure per quanto riguarda l’immissione dei dati, la memorizzazione e la sicurezza degli stessi. Le interrogazioni, poi, possono essere sia libere che guidate. Arnesi e strumenti di ICT sono in grado di accrescere il valore di queste funzionalità le quali devono essere considerate fondamentali nella valutazione di sistemi rivolti alla PHI.

Il primo di questi elementi è una chiave di accesso biometrica per la famiglia. Questa chiave garantirebbe un maggiore grado di sicu-rezza del sistema mantenendone la semplicità d’uso. Tra le tecniche biometriche utilizzabili ricordiamo la lettura delle impronte digitali o la scansione dell’iride.

Un secondo elemento è la possibilità di effettuare interrogazioni e ottenere i risultati con modalità analoghe al motore di ricerca Go-ogle. Potrebbe essere comodo per la ricerca di immagini in modo da consentire la visualizzazione di più risultati annotati da una stessa parola chiave. Per esempio, immagini radiografiche, TAC o risonan-ze magnetiche di diverse parti del corpo, riferite a uno stesso mem-bro del nucleo familiare potrebbero essere visualizzate contempo-raneamente utilizzando come parola chiave di ricerca il suo nome.

Un terzo elemento da considerare è la possibilità da parte dell’ap-plicativo di importazioni di immagini da diverse sorgenti, ossia da diversi dispositivi digitali, immagini in formati differenti; l’utente può in questo modo collegare il PC con uno scanner o con un te-lefono cellulare dotato di fotocamera e può addirittura scaricare le immagini precedentemente memorizzate sul web o su un altro di-spositivo. Anche i dispositivi medici che forniscono dati in formato elettronico possono essere facilmente connessi all’applicazione sof-tware; per esempio la misurazione della pressione ottenuta con uno sfigmomanometro digitale può essere direttamente trasmessa grazie a un dispositivo wi-fi o bluetooth.

Un quarto elemento è che il sistema dovrebbe essere indipenden-te rispetto alla piattaforma con la quale è stato sviluppato e quindi utilizzabile su sistemi aventi differenti sistemi operativi, e essere pre-disposto per l’uso con differenti lingue. Dovrebbe inoltre include-re sia vocabolari medici generali sia dizionari medici specifici. Ad esempio, se fosse incluso un dizionario terminologico medico ri-guardante le patologie (ICD-9-CM) e un prontuario farmaceutico,

la fase di inserimento di patologie e terapie farmacologiche asse-gnate avverrebbe semplicemente tramite scelta e selezione da liste, evitando così possibili errori di digitazione.

Il sistema deve essere implementato utilizzando interfacce sem-plici, in modo che gli utilizzatori siano facilmente guidati nell’ap-prendimento di come utilizzare il sistema stesso.

Un’altra caratteristica chiave da prendere in considerazione è “integrazione”. In particolare integrazione riferita al livello di inte-roperabilità tra il sistema personale e quello dei professionisti. Per questo, l’area di applicazione del sistema deve essere correttamente definita in termini di bisogni, obiettivi e standard di sicurezza ri-chiesti.

5.8.2 Modellazione del sistema

5.8.2.1 Requisiti applicativiUn sistema applicativo rivolto alla PHI per la famiglia deve rispon-dere necessariamente a specifici requisiti:

Inserimento e archiviazione in locale dei dati per facilitare la ge-stione della privacy, rispettando le leggi in materia di archiviazione e trattamento dei dati personali. Nonostante gran parte di sistemi PHR siano basati su web, ovvero i dati relativi allo stato di salute di un nucleo familiare sono archiviati su un server accessibile, una possibile soluzione è quella di realizzare un sistema in cui sia l’ap-plicazione software sia i dati siano conservati sul lato client, cioè sul personal computer dell’utente. L’applicazione software viene scari-cata e installata dall’utente a seguito della registrazione al servizio della cartella clinica per la famiglia verticale. In questa architettura, l’applicazione locale (lato cliente) può funzionare anche senza una connessione ad internet o ad una rete intranet, mentre l’applica-zione web garantisce la registrazione al servizio, il processo di au-tenticazione, lo scaricamento di moduli applicativi, la possibilità di valutazione della bontà di compilazione da parte di personale speci-fico. La trasmissione di dati deve essere protetta attraverso algoritmi criptati.• La verifica della bontà della compilazione delle sezioni della

cartella clinica di famiglia da parte di un medico, che potrebbe anche essere il medico di medicina generale, o da uno spe-cialista. Questo ruolo è indicato con il termine di “Matching Evaluator”. La verifica avviene sui dati inviati al server in ma-niera criptata da parte dei FHMS e lì temporaneamente me-morizzati.

• Una procedura a due fasi per l’immissione e l’aggiornamento

dei dati della cartella clinica di famiglia: 1) l’immissione dei dati da parte del FHMS; 2) la verifica della bontà di compi-lazione dei dati da parte del medico. I dati potranno essere interrogati solo dopo l’esito positivo della verifica, evitando così l’utilizzo di dati e informazioni non coerenti e/o corretti.

• Un ambiente di produzione indipendente dal dispositivo, considerando non solo i personal computer ma anche compu-ter portatili o palmari. Questo permette di evitare la necessità di impiego di package per la visualizzazione o la stampa dei dati su dispositivi hardware differenti.

• Un’interfaccia grafica (Graphical User Interface – GUI) adatta al sistema operativo considerato. Questa dovrà essere realiz-zata tenendo conto della numerosità dei campi da compilare (“previsione esaustiva”), che è possibile che non tutti siano poi compilati, ma il sistema visualizzerà poi solo i campi aventi un valore assegnato (“visualizzazione efficace”).

• Applicazioni autocontenute in grado di lavorare senza la ne-cessità di installare altri software o altre librerie per rendere il sistema indipendente dalla necessità di avere a disposizione altre applicazioni software. Così l’applicativo può essere ese-guito su dispositivi removibili.

• La presenza di una struttura dati che permetta un suo aggior-namento in maniera agevole e senza necessità di re-inserire i dati già memorizzati. Il processo di aggiornamento tramite una struttura predeterminata, “struttura a scheletro”, permet-te di evitare che i programmatori debbano editare il codice sorgente relativo all’interfaccia grafica ad ogni aggiornamento della struttura di memorizzazione. Ad esempio l’aggiungere un campo ad un form deve automaticamente portare ad una modifica dell’interfaccia grafica.

Requisiti per la struttura di una cartella clinicaLa cartella clinica gestita dal sistema deve poter contenere i dati relativi a tutti i membri del nucleo familiare. Il FHDM compila le informazioni relative alla anamnesi familiare e patologica di tutti i componenti della propria famiglia. Se il programma è in grado di recuperare automaticamente i dati comuni relativi all’anamnesi di altri componenti della famiglia, la procedura di inserimento risulta facilitata. La cartella clinica deve inoltre poter gestire diverse tipo-logie di eventi, come ricoveri in ospedale o esami diagnostici, an-che contenenti immagini digitali (statiche e/o dinamiche). Inoltre, il sistema deve gestire le terapie farmacologiche, preferibilmente, come detto, utilizzando dizionari terminologici standard. L’utente

che effettua un’interrogazione può quindi richiedere informazioni che riguardano più componenti della famiglia; questa possibilità dipende ovviamente dalla possibilità che il FHDM ha di gestire i dati relativi agli altri componenti del nucleo familiare, possibilità garantita da accordi tra i membri stessi.

Collegamento tra cartelle clinicheLe relazioni familiari possono essere utili per definire lo stato di salute di uno dei membri della famiglia. La cartella di un soggetto può essere confrontata con le altre, seguendo l’albero genealogico, per avere la possibilità di stabilire connessioni tra i dati (di eventi e/o esami), per velocizzarne l’inserimento e per migliorare le capacità di interrogazione sui dati stessi. Per esempio, l’anamnesi fisiologica e quella patologica dei componenti più anziani di una famiglia posso-no influenzare la anamnesi delle nuove generazioni.

5.8.2.2 Attori del sistemaIl processo di gestione delle informazioni cliniche contenute all’in-terno della cartella clinica di famiglia coinvolge tre attori principali che operano in maniera diversa sui dati e da differenti postazioni:• Il Family Healthcare Data Manager (FHDM)• Il Matching Evaluator (ME)• Il Technological Manager (TM) - per la manutenzione dell’har-

dware, del sistema operativo e degli applicativi software.La Figura 5.41 rappresenta il Diagramma dei Casi d’Uso dell’in-

tero sistema impiegando il linguaggio grafico Unified Modeling Language (UML) [Object Management Group, 1997].

Family Healthcare Data Manager (FHDM)Il Family Healthcare Data Manager (FHDM) è il membro della fa-miglia che raccoglie e organizzata i dati e la documentazione clinica. Nel caso di cartella clinica cartacea, il FHDM è quello che raccoglie in una cartelletta i documenti e gli esami relativi a se stesso e agli altri membri della famiglia.

Le funzioni di questo attore sono: registrazione al servizio, inse-rimento dei dati, visualizzazione e interrogazioni dei dati, richieste al Matching Evaluator (ME) di verifica della bontà di compilazione dei dati inseriti, creazione di un report (generalmente in formato pdf ) contenente i dati sanitari relativi ad ogni componente della famiglia.

Matching Evaluator (ME)Il Matching Evaluator (ME) è il professionista della sanità incari-

cato di controllare la bontà di compilazione dei dati clinici inseriti in formato digitale dal FHDM. Le funzioni di questo attore sono: richiesta di arruolamento nel servizio, visualizzazione dei dati da verificare, valutazione (accettazione o rifiuto) della compilazione.

Technological ManagerIl Technological Manager (TM) è un ruolo diversificato che com-prende l’amministratore della sicurezza, dell’hardware del sistema e del sistema di gestione della base di dati. Le funzioni di questo atto-re sono: inserire o modificare le informazioni relative a nuovi utenti (sia pazienti ma anche professionisti nel ruolo di ME).

Heading New Family Member

Document Acquisition

Data Entry & Update

Make Query & Visualization of Medical Report

Generate PDF Format Medical Reports

Heading New Family

Client

Family Health Data Manager

Matching Evaluator

Technological Manager

SW Maintenance HW Maintenance

Backup Request

Backup Server Maintenance

Backup Server

<<include>><<include>>

Request of Data Verification

Software Maintenance

Hardware Maintenance

Enrollment

Maintenance

Web server

<<include>>

Data verification and Document

Figura 5.41Diagramma dei

casi d’uso UML che rappresenta gli attori del sistema e le loro

relazioni con gli elementi costitutivi

5.8.2.3 Modellazione dell’architettura del sistemaLa costruzione del sistema prevede l’esistenza di alcuni componenti fondamentali (Figura 5.42): • un server operativo, costituito da un “Web server” più un “Ap-

plication Server”, per fornire le pagine web con i servizi di download riguardanti l’applicazione lato client;

• una workstation residente a casa dell’utente per eseguire l’ap-plicativo lato client;

• una workstation per l’applicazione web di valutazione dei dati da parte del Matching Evaluator

• una workstation per il Technical Manager• un server per il backup dei dati.

5.8.2.4 Funzionamento del sistemaDopo aver avuto accesso al sito web del servizio, l’utilizzatore può effettuare la registrazione compilando un form contenente i pro-pri dati (nome, cognome, indirizzo mail, ecc). Riceverà successi-vamente un messaggio email inviato dal server centrale. Cliccando sull’indirizzo URL contenuto nel messaggio, viene attivato il pro-prio account e si può accedere al servizio. L’attivazione consiste in un controllo sui dati dell’utilizzatore: una chiave a 32 byte spedita dal server cliccando sull’indirizzo URL è confrontata con un codice

Browser Client

Matching Evaluator

Web Server

Manager Client

Application Server

ZTP/ Python

MySQL DBMS

Internet Https ProtocolInternet Https Protocol

Internet Https Protocol

SQL-Alchemy

Rich Client

<<artifact>>Family Health Record Application

Figura 5.42Deployment Diagram indicante il layout fisico del sistema comprendente i nodie le loro connessioni

a 32 byte generato durante l’inserimento dei dati; se coincidono l’account viene attivato. La Figura 5.43 rappresenta il diagramma delle sequenze UML per l’inserimento e la memorizzazione dei dati nel sistema. I dati inseriti riguardano informazioni sui membri della famiglia, le loro anamnesi fisiologiche, familiari, patologiche (pros-sime e remote), le informazioni relative agli esami effettuati.

La Figura 5.44 rappresenta il Diagramma UML delle Classi della “struttura a scheletro” per l’aggiornamento dei dati creata per sepa-rare la fase di aggiornamento della struttura dati dal codice sorgente del software. Ci sono due tipi di “struttura a scheletro” (skeletonstructures): • ScheletrodiIntestazione(Headerskeleton): relativo ai dati per-

sonali e clinici di tutti i componenti di una famiglia;• Scheletrodiaggiornamento(Updatingskeleton): relativo agli

eventi clinici di un individuo e alle terapie prescrittegli. La Figura 5.45 mostra il Sequence Diagram UML del processo di verifica di bontà di compilazione dei dati. Quando un ME accede alla sua area riservata, trova un insieme di dati in attesa di essere va-

Figura 5.43Sequence Diagram

UML che rappresenta l’inserimento e la

memorizzazione dei dati

;Saver();SkelParser();GUI

a: Family Health Data Manager

2: Request of Skeleton()

3: Heading Skeleton

4: Creating Form for Data Entry()

5: Form Visualization()

6: Data Entry()

7: Store Data Request()

8: Data Stored

9: End Session()<<destroy>>

1: Start Session()<<create>

lidati inseriti da diversi utenti, manager dei dati sanitari di famiglia, registrati al servizio. Ogni documento è associato a un insieme di etichette comprendenti la data della visita, la data di creazione del file, la parte del corpo interessata e la patologia evidenziata (selezio-nata dal dizionario ICD-9-CM). Il ME verifica la corrispondenza tra i dati e le etichette e la buona qualità delle immagini inserite dall’utente fornendo un giudizio, positivo o negativo. Nel secondo caso il FHDM che ha inserito la richiesta può correggere i dati e procedere ad una nuova richiesta di valutazione.

La trasmissione dei dati e la loro memorizzazione sul server av-viene in modo criptato. I dati sono “impacchettati” e criptati prima della trasmissione al server e vengono decriptati utilizzando un al-goritmo simmetrico (Advanced Encryption Standard – AES) [FIPS, 2001] per abbreviare i tempi della procedura di trasmissione. La chiave simmetrica, che ha generalmente una lunghezza limitata ai 32 bytes, viene criptata utilizzando l’algoritmo asimmetrico RSA [Rivest et al., 1978] e trasmessa insieme al pacchetto di dati. Trami-te l’algoritmo MD5, un checksum viene calcolato prima e dopo la trasmissione del pacchetto di dati al server remoto; se coincidono la trasmissione è avvenuta correttamente, altrimenti la trasmissione dei dati deve essere ripetuta.

Skeleton Structure

+Type+Version

Family Medical Hystory

Heading Skeleton Updating Skeleton

Common Parts to Family Members

+Family Biographical Information+Last Modify Date

Specific Parts to Family Member

+Demographical Information+Last Modify Date

+Date+Description+Labels+Attachments+References

Therapy

+Start Date+End Date+Prescripted Drugs+Drug Change

Medical Hystory

+Pathologies

Developmental History

+Developmental Pathologies

Figura 5.44Il Diagramma UML della Classi della “struttura a scheletro” del sistema per l’aggiornamento dei dati

5.8.3 Descrizione e implementazione del sistema

5.8.3.1 Implementazione web serverIl sistema del server è stato implementato con un’architettura a due strati. Il primo strato (quello di elaborazione e dei dati) è costituito da un Data Base Management System MySQL per la gestione de-gli utenti (sia quelli finali sia gli amministratori) e dei dati ad essi relativi. È basato su un database relazionale in grado di mantenere

;Web Server;Client

: Family Health Data Manager

<<destroy>>

1: Start Session()

: Matching Evaluator

2: Data Evaluation Request()

3: Transmission of encrypted data()

4: Transmission completed 5: Start Evaluation

Session()

6: Pending Requests

7: Evaluation()

8: Evaluation completed9: Transmission of

encrypted Judgement()

10: End of Evaluation Session()

11: Judgement Advise

12: Querying Updated Data()

13: End Query Session

14: Mistake correction()

15: Mistake corrected

16: End Session()<<destroy>>

[Positive Judgement]

[Negative Judgement]

alt After Evaluation

Figura 5.45Sequence Diagram che

rappresenta il processo di validazione dei dati da parte del Matching

Evaluator

le informazioni sugli utilizzatori e i dati sanitari inseriti con tutti i riferimenti annessi (etichette di descrizione e il percorso del file). Inoltre, nel primo strato il server web gestisce le richieste prove-nienti dal lato client e permette l’esecuzione di tutte le funzioni del sistema (la registrazione al servizio, la richiesta di validazione al ME,

Figura 5.46Diagramma entità-relazioni del database relazionale che governa le informazioni degli utenti

Family HealthData Manager

MatchingEvaluator

Submitted (Healthcare) Data for Matching Evaluation

and Content Validation

(0,N) (1,1) (1,1) (0,N)

Figura 5.47Diagramma dei Componenti UML del Web Server

Web Server

ZPT pages

Socket HTTPS

User Authentication System Authentication Service

Network Connetion

<<artifact>>Drug Reference Book

<<artifact>>ICD-9-CM Dictionary

Indexing Services for Medical Dictionaries

Manager and Validator of Clinical Digital Documentation

SQL Alchemy Object Relational Mapper

Encryption & Decryption Services

<<artifact>>Encrypted Data

<<artifact>>Data Base

Access Control

User Management

requires

Medical Dictionary Decode

Encryption

Delete

Update

Select

Insert

Decryption

requires

la visualizzazione e la navigazione all’interno dei dati da validare, la validazione dei dati inseriti).

Il secondo strato, quello dell’utente, è composto da tutti i com-puter client connessi al server sul primo strato attraverso la rete internet e che caricano sul proprio browser l’interfaccia utente, a seconda del proprio ruolo (FHDM o ME). La Figura 5.46 rap-presenta il diagramma entità-relazione del database relazionale che governa le informazioni a proposito degli utenti del server (FHDM o ME) e il caricamento dei dati clinici.

C’è una relazione binaria uno a molti tra le due entità “Dati Cli-nici Inseriti” e “Family Health Data Manager”: un FHDM può in-serire molte richieste di validazione dei dati. Inoltre, c’è una relazio-ne binaria uno a molti tra “Dati Inseriti” e “Matching Evaluator”: un ME può analizzare molte richieste di validazione. Per rendere la figura leggibile, gli attributi delle entità rappresentate non sono mostrati ma sono elencati nelle Tabelle 5.15-5.16-5.17.

L’applicativo web è stato sviluppato usando la tecnologia Zope Application Server e il linguaggio di ZPT templating language, che permette lo sviluppo di pagine web dinamiche, insieme al linguag-gio HTML 4.0 (Hyper Text Markup Language).

Il linguaggio JavaScript è stato usato per aggiungere controlli lo-gici alle pagine web, per esempio per validare le strutture di pagine web usando alcune richieste ad istanze di Asynchronous Javascript and XML (AJAX).

L’applicazione Web Server, Figura 5.47, consente la registrazio-ne al servizio, il processo di autenticazione, lo scaricamento dei moduli applicativi lato client, il processo di valutazione delle com-pilazioni dei dati tramite connessione sicura (Secure Socket Layer – SSL). L’uso combinato di ZPT, del linguaggio di programmazione Python e di SQLAlchemy ha consentito di interpretare i contenuti delle pagine web contenente informazioni recuperate dalla base di dati.

SQLAlchemy è un “object relational mapper”, sviluppato utiliz-zando il linguaggio di programmazione Python, e permette di leg-gere tramite i costrutti di un linguaggio di programmazione orien-tato agli oggetti i dati memorizzati in una base di dati relazionale.

Attributi DescrizioniID Identificativo del “Family Health Data Manager”Name Nome dell’utente registratoSurname Cognome dell’utente registratoEmail Indirizzo email dell’utente registratoUsername Nome utentePassword Password accoppiata al nome utente per consentire l’autenticazione e l’accessoRegistered_on Contiene la data di attivazione dell’utente

Activation_pending Se è uguale a zero significa che l’utente ha effettuato l’attivazione al servizio, altrimenti contiene un numero che sarà parte dell’URL per l’attivazione al servizio

Public_key Contiene la chiave pubblica RSA generata durante il primo accesso da parte dell’utente

Attributi DescrizioniID Identificativo del “Matching Evaluator”Name Nome dell’utente registratoSurname Cognome dell’utente registratoEmail Indirizzo email dell’utente registratoUsername Nome utentePassword Password accoppiata al nome utente per consentire l’autenticazione e l’accessoRegistered_on Contiene la data di attivazione dell’utentePublic_key Contiene la chiave pubblica RSA generata quando l’utente si è registrato Private_key Contiene la chiave privata RSA generata quando l’utente si è registrato

Attributi DescrizioniID Identificativo del Blocco di Dati

User_ID Utente “Family Health Data Manager” che ha inviato il blocco di informazioni (chiave esterna)

Tar_path Indica il percorso di archiviazione del blocco criptato di informazioniMasterxml Indica il numero di file contenuto nel blocco di dati

Status

Identifica lo stato blocco di dati rispetto alle operazioni di verifica. È un valore intero che può assumere i seguenti valori: 1: dati da verificare; 2: dati verificati e validi; -1: dati verificati e non validi; -2: dati verificati e scaricati dall’utente (il blocco di dati criptato è eliminato)

Posted_on Data di invio del blocco di datiDone_on Data di verifica dei dati

Done_by Identificativo del “Matching Evaluator” che ha effettuato la verifica (chiave es-terna)

Notes Note inserite dal “Matching Evaluator” riguardante il blocco di dati

Encrypted_key

Contiene la versione criptata RSA della chiave AES accoppiata al blocco di dati criptato. Se i dati non sono stati ancora verificati la chiave AES è criptata con la chiave pubblica RSA del server, altrimenti la chiave AES è criptata con la chiave pubblica RSA del client, identificato dall’attributo User_ID.

Tabella 5.15Attributi della tabella “Family Health Data Manager”

Tabella 5.16Attributi della tabella “Matching Evaluator”

Tabella 5.17Attributi della tabella “Submitted Data”, contenente i blocchi di dati da sottoporre alla verifica

5.8.3.2 Implementazione del modulo ClientL’applicazione Client è stata sviluppata utilizzando il linguaggio di programmazione Python. Essa costituisce il nucleo del sistema sof-tware e viene eseguita sul calcolatore del paziente/utilizzatore. Le funzioni consentite sono l’immissione tramite form e l’archiviazio-ne delle informazioni anagrafiche e dei dati clinici riguardanti tutti i membri della famiglia; la generazione e la visualizzazione dell’al-bero genealogico della famiglia e di tutti i dati inseriti; l’invio dei dati al server per la valutazione da parte del ME; la ricezione dei report formulati dal ME. Inoltre permette l’interrogazione dei dati clinici per differenti tipi di parole chiave e la generazione di un file pdf contenente l’intera cartella clinica di un membro della famiglia. L’interfaccia grafica (Graphical User Interface - GUI) risulta como-da e permette la navigazione di tutte le sezioni dell’applicativo.

Le sezioni disponibili sono quelle che compongono tipicamente una cartella clinica sono [Marceglia e Pinciroli, 2005]: anagrafica, anche condivisa a tutta la famiglia come può accadere per l’indiriz-zo (il sistema prevede comunque che si possano inserire indirizzi diversi per ciascun membro) e l’anamnesi (fisiologica, patologica prossima, patologica remota comprendendo anche le patologie, gli interventi subiti e le terapie farmacologiche di ciascun membro).

Per memorizzare i dati di ogni membro della famiglia sono stati sviluppati quattro “scheletri software” usando il linguaggio XML (eXstensible Markup Language) [Bray et al., 2004]. Il primo è per l’inserimento dei dati anagrafici (“skelinfoanag.xml”), il secondo per l’anamnesi fisiologica (“skelanamnesifisio.xml”), il terzo per l’anam-nesi patologica (“skelanamnesipato.xml”) e l’ultimo per l’anamnesi familiare (“skelanamnesifamiliar.xml”).

La figura 5.48 rappresenta lo scheletro XML delle informazioni anagrafiche per ogni membro della famiglia. Ogni tag “field”possiede un elemento “code” che identifica il nome di un attributo (per esempio il codice “A08” è legato all’attributo “Health Identification Number”) e un elemento “type” che identifica il tipo di elemento presente nel form (ST sta per “stringa” mentre RB per “elenco a di-scesa”). I valori elencati degli elementi “code” nello scheletro (Figura 5.48) divengono nomi di tag XML (Figura 5.49).

L’interfaccia grafica GUI dell’applicazione locale comprende una finestra principale contenente quattro pannelli, ciascuno per una diversa funzione: “Famiglia”, “Cerca Eventi”, “Cerca terapie”, “Ve-rifica accreditamenti”.

Il primo pannello, etichettato “Famiglia”, contiene le caselle di testo per l’inserimento dell’indirizzo della famiglia e sotto è visualiz-zato l’albero genealogico della famiglia dove la posizione di ciascun

componente è legata al grado di parentela con gli altri membri (Fi-gura 5.50).

Il secondo pannello, etichettato “Cerca Eventi”, contiene la lista degli eventi accorsi ai membri della famiglia. Ogni elemento della lista è caratterizzato dai seguenti attributi: nome del componente, nome dell’evento occorso, numero degli allegati, numero delle eti-chette di descrizione dell’evento, lo stato della valutazione (secon-do quanto descritto a riguardo dell’attributo “Status” della tabella “Submitted Data” Tabella 5.17). È possibile interrogare per nome dell’individuo e per etichetta descrittiva evidenziando anche quanti membri della famiglia hanno avuto lo stesso disturbo.

Figura 5.48Il codice XML dello scheletro per le informazioni anagrafiche

Figura 5.49Il codice XML dello scheletro per le informazioni anagrafiche compilato per il membro di una famiglia. Alcune informazioni sensibili sono state omesse

<?xml version=’1.0’ encoding=’UTF-8’?><skel type=’Demographical notes’ version=’0.1’> <field code=’A01’ name=’First Name’ type=’ST’/> <field code=’A02’ name=’Last Name’ type=’ST’/> <field code=’A03’ name=’Gender’ type=’RB’/> <value name=’M’/> <value name=’F’/> </field> <field code=’A04’ name=’Birth day’ type=’ST’/> <field code=’A05’ name=’Birth month’ type=’ST’/> <field code=’A06’ name=’Birth year’ type=’ST’/> <field code=’A07’ name=’Birth month’ type=’ST’/> <field code=’A08’ name=’Place of born’ type=’ST’/> <field code=’A09’ name=’Health identification number’ type=’ST’/> <field code=’A10’ name=’Assurance ID’ type=’ST’/> <field code=’A11’ name=’Street name’ type=’ST’/> <field code=’A12’ name=’Street number’ type=’ST’/> <field code=’A13’ name=’Zip code’ type=’ST’/> <field code=’A14’ name=’State/Province’ type=’ST’/> <field code=’A15’ name=’Country’ type=’ST’/></skel>

<?xml version=’1.0’ encoding=’UTF-8’?> <message savedon=”2007-07-19”> <A01>Stefano</A01> <A02>Bonacina</A02> <A03 type=”int”>0</A03> <A04>1</A04> <A05>11</A05> <A06>1970</A06> <A07>[omitted]</A07> <A08>[omitted]</A08> <A09>[omitted]</A09> <A10>[omitted]</A10> <A11>[omitted]</A11> <A12>Rome</A12> <A13>00100</A13> <A14>RM</A14> <A15>Italy</A15> </message>

Il terzo pannello, etichettato “Cerca Terapia”, contiene la lista delle terapie farmacologiche prescritte ai membri della famiglia. Ogni elemento della lista è caratterizzato dai seguenti attributi: nome del soggetto, data di inizio e data di fine della terapia, elenco dei farmaci prescritti per la specifica terapia. È possibile interrogare la lista per nome del soggetto e/o per nome del medicinale prescrit-to. Questi tipi di interrogazioni consentono di individuare in quali periodi della propria vita un membro della famiglia ha assunto uno specifico farmaco e con quale posologia.

Il quarto pannello, etichettato “Verifica accreditamenti”, contie-ne la lista dei blocchi di dati contenente documenti clinici inviati o da inviare al ME dall’inizio dell’uso dell’applicazione. Ogni elemen-to della lista è caratterizzato dai seguenti attributi: nome del sogget-to, data di segnalazione dell’evento occorso, data della valutazione da parte del ME (se eseguita), nome dell’evento, lista dei file allegati con relativo link attivo per aprire ciascun file in una nuova finestra del browser, etichette di descrizione dell’evento, stato della valuta-zione. È possibile effettuare l’interrogazione attraverso il nome dei membri della famiglia. I risultati dei processi di verifica dei dati sono mostrati nel pannello “Verifica accreditamenti” della finestra principale. Questa funzionalità richiede una connessione a internet.

Dal menu “File” è inoltre possibile generare un file in formato pdf contenente tutte le informazioni personali e cliniche di ciascun membro della famiglia o di tutta la famiglia.

Ogni elemento dell’albero genealogico, formato dalla foto e dalle informazioni anagrafiche del componente, è un link attivo. Clic-

Figura 5.50In alto: l’albero

genealogico di una tipica famiglia verticale

con tre generazioni, dai nonani ai nipoti.

Tutti gli individui rappresentati hanno

dato l’autorizzazione all’uso dei propri dati

personali. Alcune delle relazioni sono

inventate per mostrare il funzionamento

dell’applicazione. In basso: il pannello

“Evento/Esame” e “Aggiungi evento” per

inserire le informazioni relative ad eventi clinici

ed esami

cando su ognuno di essi si apre una nuova finestra (Figura 5.51) che contiene cinque pannelli per inserire dati riguardanti un membro della famiglia: “Informazioni anagrafiche”, “Anamnesi Fisiologica”, “Anamnesi Patologica”, “Eventi/Esami”, e “Terapie”.

Il primo pannello, etichettato “Informazioni anagrafiche”, serve per l’inserimento delle informazioni anagrafiche di ogni componen-te della famiglia. È anche possibile inserire un indirizzo diverso per ciascun membro della famiglia.

Il secondo pannello, etichettato “Anamnesi Fisiologica”, serve per inserire i dati riguardanti l’anamnesi fisiologica di un soggetto, ide-almente partendo dal giorno della sua nascita. Il pannello visualizza-to dipende dal sesso del soggetto: per le donne sono richieste infor-mazioni aggiuntive riguardanti gli aspetti della “salute della donna”.

Il terzo pannello, etichettato “Anamnesi Patologica”, serve per inserire i dati riguardanti patologie passate e presenti (patologie car-diovascolari, cancro, diabete) per ciascun membro della famiglia. Il sistema consente di etichettare le patologie usando il dizionario medico ICD-9-CM. I termini del dizionario appaiono in un “elen-co a discesa” da cui l’utente può effettuare la selezione. La bontà dell’operazione di etichettatura verrà successivamente verificata dal ME.

Il quarto pannello, etichettato “Eventi/Esami”, serve per inserire dati riguardanti esami clinici ai quali un membro è stato sottopo-sto. Si inseriscono come allegati il formato digitale dei documenti relativi a un’investigazione clinica (ad esempio, immagini TAC, im-magini radiografiche, immagini di risonanza magnetica, filmati di ecografia), compreso il relativo referto.

La Figura 5.50, nella parte inferiore, mostra inoltre l’inserimento di nuovi eventi. Viene rappresentata la prescrizione per un’ecogra-fia dell’apparato urinario. La finestra mostra nell’angolo in basso a destra l’interfaccia per l’inserimento delle etichette descrittive del nuovo evento.

Il quinto pannello, etichettato “Terapie”, serve per inserire dati riguardanti le prescrizioni di farmaci tra i quali la data di inizio e la data di fine della terapia. È possibile inserire più di un farmaco per ogni terapia scegliendo da un “elenco a discesa” (prontuario farma-ceutico).

La Figura 5.51 rappresenta il diagramma dei componenti UML dell’implementazione del sistema Client.

5.8.3.3 Sviluppo del sistemaIl sistema è stato sviluppato presso il Laboratorio di Informatica BioMedica e Sanità Digitale del Dipartimento di Bioingegneria

del Politecnico di Milano. È installato su un computer “MaxData Favorit 200 AS” con processore AMD Athlon 64 X 2 3800+ (2 GHz), un gigabyte di memoria RAM e 80 di hard disk. Il computer ha una scheda di rete 1000Base - T ed è connesso alla rete LAN tramite backbone di 1000 MB/s (Giga bit LAN). Il sistema opera-tivo è Linux Ubuntu (versione 7.04) e i software installati sono il

Figura 5.51Diagramma UML dei

Componenti per il lato Client

Indexing Services for Medical Dictionaries

<<artifact>>Drug Reference Book

<<artifact>>ICD-9-CM Dictionary

<<artifact>>Generated PDF files

Management Services forInserted Data

XML File Parser of the Skeleton filling

Socket HTTPS

PDF File Generator

Network Connection

<<artifact>>Skeletons

Manager of XML file repository

<<artifact>>Local XML files

Receive

Generate

Skeleton_ReadFile_Read

<<User Interface>>Client

Exporting Data Services

Data transmission Services

Management Services forSkeletons and Forms

Encryption & Decryption Services

requires

Encryption

Decryption

<<artifact>>Encrypted Data

DBMS MySQL (versione 5.0.38 per il sistema operativo Ubuntu), un web server Apache – Apache/2.2.3. PHP/5.2.1., un server Zope, un compilatore ZTP, un compilatore per il linguaggio di program-mazione Python.

5.8.4 Elementi di valutazione (Discussione)

Il prototipo presentato è un sistema efficace per memorizzare infor-mazioni mediche e cliniche nell’ambiente familiare in modo sicuro e facile. Tipicamente gli ospedali non hanno una storia di condivi-sione delle informazioni relative ai pazienti che sono stati comuni. Perciò il paziente rimane solitamente l’unico portatore della conti-nuità della cura. Il prototipo presentato rappresenta un importante contributo in questo ambito.

Per salvaguardare i diritti dei singoli in ambito delle modalità del trattamento dei propri dati sanitari deve necessariamente sus-sistere un accordo tra tutti i membri della famiglia, considerando anche coloro che per minorenni possano decidere senza il consenso dei genitori. Questo accordo consente al “Family Healthcare Data Manager” di avere accesso e di poter gestire i dati relativi ai membri della sua famiglia, sia nel formato cartaceo che in quello digitale. Ovviamente ciascun membro è libero di decidere quali informa-zioni possano essere inserite nella cartella clinica di famiglia e per quanto tempo debbano essere accessibili. Qualora richiesto gli svi-luppatori di politiche di accesso ai dati è possibile fare riferimento a linee guida di compagnie assicurative [Demiris et al., 2008].

Nel nostro approccio la famiglia è considerata una singola entità, nel senso che è composta da più individui che condividono aspetti relativi all’ambiente nel quale vivono, allo stile di vita e alla propria storia clinica. L’idea centrale di mantenere uno stile di vita salutare che sta alla base dello sviluppo di sistemi di Personalized Health In-formatics, è declinata in questo prototipo a tutto il gruppo familiare multi generazionale, dove la generazione di mezzo (i genitori) ha la responsabilità di prendersi cura dei soggetti più deboli (gli anziani e i bambini). I genitori gestiscono la cartella clinica della famiglia in modo che possano monitorare lo sviluppo dello stato di salute di tutti i componenti della famiglia stessa. Il vantaggio di questo tipo di approccio è duplice: da un lato, tutti i fattori condivisi dal gruppo familiare possono essere usati per migliorare e monitorare in maniera più efficace la salute di ogni singolo componente; dall’altro lato, i componenti più deboli, che non hanno conoscenze tecnolo-giche e/o mediche e l’abilità nell’uso del calcolatore per prendersi cura dei propri dati sanitari informatizzati, sono inclusi nel monito-

raggio. Attualmente, la preparazione in ambito dell’ICT della gene-razione di mezzo è tale che, con un’appropriata fase di training sul software, questa sia in grado di utilizzare adeguatamente l’applica-zione descritta. Essa è basata su attività molto semplici, richiedendo di compilare dei form e di caricare documenti e immagini digitali anche ottenuti da dispositivi comuni, come scanner o fotocamere digitali. Il concetto di “famiglia verticale” è stato infatti sviluppato per superare la criticità del “digital divide”.

In un sistema di cartella clinica personale individuale (Personal Health Record), il singolo individuo ha la responsabilità di gesti-re i dati relativi alla propria salute e, di conseguenza, deve essere in grado di saper utilizzare l’applicativo e avere anche conoscenze mediche di base. Le persone che non hanno sufficienti capacità in-formatiche non possono utilizzare il sistema, per cui devono essere adeguatamente addestrate, si veda [Kim et al., 2005]. Al contrario, in una prospettiva di cartella clinica dedicata al gruppo di famiglia, si può assumere che almeno un membro della famiglia sia in grado di utilizzare il sistema e possa prendersi carico di gestire i docu-menti sanitari digitalizzati relativi a tutti gli altri componenti. Si-curamente, in una prospettiva di commercializzazione, è necessario prevedere per un tal sistema la presenza di un servizio di assistenza e supporto all’utente oltre che al manuale d’uso in formato digitale. È da notare che il sistema sviluppato non necessita di particolari tecnologie per poter funzionare in maniera completa e soddisfacen-te. Una delle principali caratteristiche del prototipo è, infatti, la sua indipendenza dall’hardware e dal sistema operativo installato sul generico computer client. Quindi affinché l’applicazione funzioni non risulti necessario installare alcun componente aggiuntivo.

Il prototipo trae vantaggio dalla condivisione delle informazioni relative ai diversi membri della famiglia non solo nella costruzione della storia clinica di ogni componente in maniera semiautomatica ma anche definendo ricerche trasversali a episodi comuni a tutti i membri della famiglia per evidenziare eventuali fattori di rischio.

Uno dei maggiori problemi legati allo sviluppo e all’uso della cartella clinica informatizzata personale (PHR) è l’inserimento dei dati: poiché i dati in questo tipo di approccio sono esclusivamente in possesso del paziente/consumatore, la procedura di inserimento è effettuata dal soggetto stesso, aumentando di conseguenza la pro-babilità di includere errori. Nel prototipo sviluppato, il ruolo del “Matching Evaluator” (ME) è stato introdotto per diminuire questa probabilità: ogni nuovo episodio deve essere verificato dal ME che controlla la corrispondenza tra il dato inserito e l’etichetta che lo de-scrive, come pure la bontà delle digitalizzazioni effettuate. In questo

modo, il gestore dei dati sanitari della famiglia (Family Healthcare Data Manager - FHDM) può usare/interrogare/stampare solo dati validati e corretti, mentre quelli indicati dal ME come inadegua-ti devono essere nuovamente inseriti. La protezione dei dati che vengono verificati dal ME è garantita da connessioni sicure di dati (SSL) e dalla crittazione delle informazioni relative al proprietario dei dati da verificare. Inoltre, il sistema può essere utilizzato solo da coloro i quali ne hanno le credenziali, impedendo pertanto l’accesso ai non autorizzati.

L’interfaccia intuitiva fornisce un ambiente facile per la memoriz-zazione e poi interrogare i dati relativi ad ogni singolo componente della famiglia, e la rappresentazione grafica dell’albero della famiglia illustra chiaramente le relazioni familiari. L’albero viene costruito e/o aggiornato automaticamente quando i dati relativi a un nuo-vo componente vengono inseriti nella cartella clinica di famiglia. L’idea di includere tra le funzionalità la possibilità di effettuare una ricerca per parole chiave anche nelle immagini, come ad esempio viene effettuato in Google, facilita le interrogazioni delle immagini contenute nella cartella clinica di famiglia.

La condivisione e l’integrazione delle informazioni sono model-late su diversi aspetti: innanzitutto i dati sono visualizzati su una piattaforma indipendente da quella usata per lo sviluppo, quale un personal computer, un dispositivo portatile (laptop o palmare) e anche smart-phone; in secondo luogo l’applicazione stessa è auto-sufficiente e indipendente da software di terze parti; terzo, il sistema è basato su una struttura di dati facilmente modificabile; inoltre, la disponibilità nel sistema di dizionari medici standard non solo minimizza la possibilità di errori di sintassi nella fase di inserimento dei dati, ma garantisce anche l’utilizzo di terminologia condivisa, anche per i professionisti che in tempi e luoghi diversi leggeranno la cartella clinica. Infine il sistema accetta l’inserimento di note su eventi clinici in diversi formati. Per esempio, per prevenire cefalee o emicrania, il paziente può annotare nel sistema la data, l’ora, la du-rata di ogni episodio, i sintomi e i possibili fattori scatenanti. Inol-tre l’integrazione può essere migliorata in accordo agli importanti elementi di valore più sopra discussi. Per esempio, implementando la connessione con strumentazione elettronica o permettendo l’im-portazione multi-digitale da diversi dispositivi e di diversi formati di immagine.

Attualmente, il prototipo non include la possibilità di collegare la cartella clinica della famiglia con il Sistema Sanitario Nazionale. Tuttavia la Regione Lombardia ha manifestato un particolare in-teresse verso questo tipo di approccio centrato sul paziente. Non

è da escludere che, in breve tempo, il sistema per la famiglia verti-cale possa essere un servizio aggiuntivo per i cittadini della regio-ne. Questa possibilità supera ulteriormente il problema dei costi: il “Matching Evaluator” può essere iscritto insieme ai professionisti della salute già impiegati dalla regione, consentendo una diminu-zione dei costi per l’intero sistema.

La sicurezza è stata modellata a diversi livelli. La soluzione pre-sentata considera i dati immagazzinati a livello locale nel computer Client, quello del “Family Healthcare Data Manager” e le connes-sioni internet necessarie sono limitate alla fase di aggiornamento. Connessioni criptate e sicure prevengono da attacchi durante la ses-sione di lavoro con internet. Inoltre, l’applicazione autosufficiente può facilmente essere trasferita su un dispositivo portatile, come una chiave USB, possibilmente protetta con una chiave di accesso biometrico multi-modale.

Nel campo della Pesonalized Health Informatics alcuni standard riguardanti la struttura dei dati e lo scambio di dati strutturati pos-sono essere applicati:• il Clinical Document Architecture (CDA) di Health Level 7

(HL7) specifica la struttura e la semantica di un documento clinico (come una lettera di dimissioni o una nota sul progres-so del paziente) con lo scopo di favorire l’integrazione [Dolin et al., 2006];

• lo standard American Society for Testing and Materials (ASTM International) Continuity of Care Record (CCR) è stato sviluppato in risposta al bisogno di organizzare e rendere esportabile un set di informazioni basate sullo stato di salute di un paziente che sia accessibile sia al medico che al paziente stesso [AAPF, 2006];

• la proposta di Standard IEEE (P2407) “Architecture and Fra-mework Reference Implementation for Personalized Health Informatics” ha l’obiettivo di creare un sistema basato su inter-net che considera l’individuo al centro di un insieme di servizi progettati per aiutarlo a salvaguardare e migliorare il proprio stato di salute [Lacal, 2004].

Come descritto sopra l’implementazione del prototipo è basata su documenti XML per immagazzinare i dati sanitari relativi alla fa-miglia e ai suoi membri. Abbiamo etichettato tali documenti “sche-letri software” e servono per contenere in maniera strutturata dati relativi all’anagrafica (Figure 5.48 e 5.49), alle anamnesi personali e familiare, ad eventi clinici, - come esami diagnostici e la relativa do-cumentazione - prescrizione di farmaci e terapie. Per progettare gli scheletri abbiamo considerato per il singolo membro della famiglia

uno “stato corrente”, descritto dallo “scheletro di intestazione”, e un “processo di aggiornamento”, descritto dallo “scheletro di aggior-namento”, che conduce ad un nuovo stato corrente (Figura 5.44).

Seguendo la struttura gerarchica progettata (Figura 5.44) si deriva la struttura del documento XML praticamente in modo piuttosto naturale e quindi la struttura di documenti specifici proposta dagli standard non è stata seguita. Tuttavia, la mappatura dei documenti XML generati verso quelli proposti dagli standard è possibile usan-do eXtensible Stylesheet Language Transformations (XSLT) che è un linguaggio per trasformare documenti XML in altri documen-ti XML. Un approfondito confronto tra gli standard HL7 CDA e ASTM CCR è presentato in [Ferranti et al., 2006], dove si indica come le differenze tra i due siano più numerose delle similarità. Inoltre, poiché entrambi gli standard si basano sulla sintassi XML, si è deciso di utilizzare questo linguaggio. L’azione di adozione di standard, però, non è garanzia di effettiva interoperabilità per cui le future implementazioni del prototipo utilizzando gli standard a disposizione saranno sviluppate tanto più velocemente quanto più iniziative come Integrating the Healthcare Enterprise (IHE) saran-no presenti anche nell’ambito della Personalized Health Informati-cs. Si ricorda che Integrating the Healthcare Enterprise ha lo scopo di fornire una struttura per entrambi gli standard HL7 e DICOM definendo profili di integrazione per migliorare la condivisione delle informazioni da parte dei sistemi informatici impiegati in medicina [ACC, HIMSS, RSNA, 2001]. Recentemente, un modello basato su HL7 Clinical Genomics, denominato “Family History Specifi-cation” è stato sviluppato per raggiungere l’interoperabilità tra le applicazioni informatiche di cartella clinica “Family History”, cioè quelle impiegate dai medici di medicina generale per conservare le informazioni relative ai propri pazienti, includendo elementi per la rappresentazione dei dati genomici e i risultati dei test genomici [Shabo e Hughes, 2005].

5.8.5 Conclusioni

È stato modellato un sistema e costruito un prototipo per la ge-stione dei dati clinici in ambiente familiare. Il sistema considera la famiglia come un’unica entità composta dai singoli membri mini-mizzando così gli aspetti di “digital divide”, che esclude gli individui privi di conoscenze informatiche dall’uso di sistemi per la cartella clinica informatizzata. Un componente della famiglia, denominato “Family Healthcare Data Manager”, raccoglie e organizza i docu-menti sanitari digitalizzati relativi a se stesso, ai suoi figli e ai suoi ge-

nitori, ai membri più deboli del nucleo familiare. I dati inseriti nel sistema sono controllati e verificati da un professionista della salute, denominato “Matching Evaluator, minimizzando così la possibilità di cattiva compilazione della cartella clinica di famiglia. Il sistema consente una facile compilazione della cartella e una visualizzazio-ne efficace dei dati clinici relativi a ciascun membro della famiglia, dando la funzionalità di generazione di report, in un ambiente sicu-ro e controllato. Grazie alla semplica interfaccia grafica per l’immis-sione dei dati, al processo di validazione dei dati e all’indipendenza della piattaforma il sistema può essere facilmente adottato e usato dalle famiglie, anche senza una preparazione medica e/o informatica specifica, e impiegando gli strumenti di ICT già disponibili nelle attuali famiglie sull’abbrivio di spinte esterne alla salute.

Bibliografia

Paragrafo 5.1American College of Radiology (ACR). ACR practice guideline for

the performance of excretory urography [Online]. 10 Gennaio 2004; Disponibile all’indirizzo: URL:http://www.acr.org/Secon-daryMainMenuCategories/quality_safety/guidelines/pediatric/excretory_urography.aspx. Ultimo accesso: 27 Maggio 2009.

Choose and Book (NHS – Connecting for Heath) [Online]. 2008; Disponibile all’indirizzo: URL: http://www.chooseandbook.nhs.uk/ Ultimo accesso: 27 Maggio 2009.

Donatini A, Rico A, D’Ambrosio MG, Lo Scalzo A, Orzella L, Cic-chetti A et al. European Observatory on Health Care Systems. Health Care Systems in Transition: Italy [Online]. 2001; Dispo-2001; Dispo-nibile all’indirizzo: URL: http://www.euro.who.int/document/e73096.pdf Ultimo accesso: 27 Maggio 2009.

Hendy J, Fulop N, Reeves BC, Hutchings A, Collin S. Implement-ing the NHS information technology programme: qualitative study of progress in acute trusts. BMJ 2007; 334(7608): 1360.

Partners Human Research Committee (PHRC). Blood sampling guidelines [Online]. 2008; Disponibile all’indirizzo: URL: http://healthcare.partners.org/phsirb/bldsamp.htm Ultimo ac-cesso: 27 Maggio 2009.

Sanità Milano [Online]. 2008; Disponibile all’indirizzo: URL: http://www.sanitamilano.it/ Ultimo accesso: 27 Maggio 2009.

Vallgårda S, Krasnik A, Vrangbæk K. Health Care Systems in Transition: Denmark [Online]. 2001; Disponibile all’indirizzo: URL:http://www.euro.who.int/document/e72967.pdf Ultimo accesso: 27 Maggio 2009.

Paragrafo 5.2Beckman T.A Methodology for Knowledge Management. Interna-

tional Association of Science and Technology for Development (IASTED) AI and Soft Computing Conference. Banff, Canada 1997.

Borghoff UM, Pareschi R. Information Technology for Knowl-edge Management. Journal of Universal Computer Science. 1997;3(8):835-842.

Decreto Legislativo (DL) n.211 del 2003. Attuazione della direttiva 2001/20/CE relativa all’applicazione della buona pratica clinica nell’esecuzione delle sperimentazioni cliniche di medicinali per uso clinico. [Online]. Disponibile all’indirizzo URL: http://te-sto.camera.it/parlam/leggi/deleghe/testi/03211dl.htm. Ultimo accesso: 27 Maggio 2009.

Decreto Ministeriale (DM) 15 luglio 2007. Recepimento delle linee guida dell’U.E. di Buona Pratica Clinica per la esecuzione delle sperimentazioni cliniche dei medicinali. Linea guida per la buona pratica clinica. [Online]. Disponibile all’indirizzo URL: http://oss-sper-clin.agenziafarmaco.it/normativa/DM15_07_1997.pdf Ultimo accesso: 27 Maggio 2009.

European Medicines Agency (EMEA) [Online] 1995. Disponibile all’indirizzo URL: http://www.emea.europa.eu. Ultimo accesso: 27 Maggio 2009.

Fuccella LM, Frascio M. Guida pratica alla sperimentazione clinica dei farmaci. Milano: Organizzazione Editoriale Medico Farma-ceutica; 1995.

Harman RJ. The EMEA: Drug Regulation at a supranational level. Pharmaceutical Journal. 2002;269(7225):752-756.

ICH. ICH Harmonised Tripartite Guideline. Diagrammatic Repre-sentation of the Organization of the ICH Common Technical Document (CTD). [Online], 2004. Disponibile all’indirizzo URL: http://www.ich.org/LOB/media/MEDIA554.pdf pag. 4. Ultimo accesso: 27 Maggio 2009.

International Conference on Harmonisation (ICH) of Techni-cal Requirements for Registration of Pharmaceuticals for Hu-man Use. The Common Technical Document. [Online] 2002. Disponibile all’indirizzo URL: http://www.ich.org/cache/com-po/1325-272-1.html. Ultimo accesso: 27 Maggio 2009.

National Institute of Allergy and Infectious Disease (NIAID) [On-line] 2005. Disponibile all’indirizzo URL: http://www.niaid.nih.gov/daids/PDATguide/drugdp.htm. Ultimo accesso: 27 Maggio 2009.

Pitt B, Desmond J, Pocock S. La sperimentazione clinica. Principi fondamentali. Roma: Il Pensiero Scientifico Editore; 2000.

Tomino C. Manuale tecnico-pratico sulla sperimentazione clinica del medicinale. Roma: CMP - Critical Medicine Publishing; 2004.

U.S. Food and Drug Administration (FDA) [Online] 2001. Dispo-Dispo-nibile all’indirizzo URL: http://www.fda.gov. Ultimo accesso: 27 Maggio 2009.

World Medical Association (WMA). Declaration Of Helsinki: Eth-

ical Principles for Medical Research Involving Human Subjects [Online] 1964. Disponibile all’indirizzo URL: http://www.wma.net/e/policy/b3.htm. Ultimo accesso: 27 Maggio 2009.

Paragrafo 5.3Berners-Lee T, Hendler J, Lassila O. The Semantic Web. A new form

of Web content that is meaningful to computers will unleash a revolution of new possibilities. Scientific American Magazine, 2001. [online]. Disponibile all’indirizzo URL: http://www.scien-[online]. Disponibile all’indirizzo URL: http://www.scien-tificamerican.com/article.cfm?id=the-semantic-web&page=2 Ultimo accesso: 27 maggio 2009

Boulos MN, Roudsari AV, Carson ER. Towards a semantic medical Web: HealthCyberMap’s tool for building an RDF metadata base of health information resources based on the Qualified Dublin Core Metadata Set.Med Sci Monit. 2002;8(7):MT124-36.

Dublin Core Metadata Initiative [Online]. 2002. Disponibile all’indirizzo: URL: http://dublincore.org/ Ultimo accesso: 27 Maggio 2009

Li Q, Shilane P. Protégé UMLS Tab [Online], 2006. Disponibile all’indirizzo: URL: http://protegewiki.stanford.edu/index.php/UMLS_Tab Ultimo accesso: 27 Maggio 2009

Neumann EK, Quan D. Biodash: A Semantic Web Dashboard for Drug Development. Pacific Symposium on Biocomputing 2006;11:176-187. PSB Online Proceedings. Disponibile all’in-dirizzo: http://helix-web.stanford.edu/psb06/neumann.pdf Ulti-mo accesso: 27 Maggio 2009

Sheth A, Agrawal S, Lathem J, Oldham N, Wingate H, Yadav P et al. Active Semantic Electronic Medical Record [online]. 2006; Disponibile all’indirizzo: URL: http://iswc2006.semanticweb.org/items/Oldham2006fk.pdf Ultimo accesso: 27 Maggio 2009

Signore O. Semantic Web: non solo teoria. L’architettura del Se-mantic Web. W3C - Ufficio Italiano.[Online], 2006. Dispo-nibile all’indirizzo URL: http://www.w3c.it/talks/2006/pra-to2006/#[4] Ultimo accesso: 27 Maggio 2009

W3C. W3C Semantic Web Health Care and Life Sciences Inter-est Group [Online]. 2007; Disponibile all’indirizzo: URL:http://www.w3.org/2001/sw/hcls/ Ultimo accesso: 27 Maggio 2009

W3C. Semantic Web in Health-care and Life Sciences - Applica-tions and Demonstrations [Online]. 2006; Disponibile all’indi-2006; Disponibile all’indi-rizzo: URL: http://www.w3.org/2005/04/swls/ Ultimo accesso: 27 Maggio 2009

Paragrafo 5.4Bergamaschi W, Canali D, Fantola M. (a cura di). Il Nuovo Siste-

ma Informativo Sanitario (NSIS): Modello concettuale di base, Roma 2005, Ministero della Salute.

Decreto Ministeriale (DM) 15 luglio 2004 [Online] 2004. Di-sponibile all’indirizzo URL: http://www.ministerosalute.it/imgs/C_17_normativa_575_allegato.pdf Ultimo accesso: 23 settembre 2008.

Decreto Legge (DL) n° 39 del 1 marzo 2002 [Online] 2002. Di-sponibile all’indirizzo URL: http://www.ministerosalute.it/imgs/C_17_normativa_578_allegato.pdf Ultimo accesso: 23 settembre 2008.

Decreto Legge (DL) n° 178 del 29 maggio 1991. Disponibile all’in-dirizzo URL: http://www.galenotech.org/dlgs-farmaci.htm Ulti-mo accesso: 23 settembre 2008.

Ministero della Salute. Che cos’è la SDO? [Online] 2007; Disponi-bile all’indirizzo: URL: http://www.ministerosalute.it/program-mazione/sdo/sezApprofondimenti.jsp?label=sdo Data di ultimo accesso: 22 settembre 2008

Parlamento Europeo. Normativa 2001/83/CEE [Online] 2001. Disponibile all’indirizzo URL: http://www.informatori.it/infor-matori/legislazione/Direttiva200183CE.pdf Ultimo accesso: 23 settembre 2008.

U.S. Department of Health and Human Services, Food and Drug Administration (FDA). Combating Counterfeit Drugs: A Re-port of FDA. Rockville, Maryland; 2004.

Vineis P, Dirindin N. In buona salute: dieci argomenti per difende-re la sanità pubblica. Torino: Einaudi; 2004.

Paragrafo 5.5Anderson C.L., Meldrum K.C. The VA computerized patient re-

cord. In: Proceedings of the Annual Symposium on Computer Applications in Medical Care. 1994, p. 1048.

Brown S.H, Lincoln M. J, Groen P.J, Kolodner R. M. VistA U.S. Department of Veterans Affairs national-scale HIS. International Journal of Medical Informatics 2003, 69 p.135-156

Gaggi M. L’ ingombrante successo di Vista: la rete della salute creata dai veterani Usa. Corriere della Sera, 1 giugno 2007.

Johnson C.L, Carlson R.A, Tucker C.L, Willette C. Using BCMA software to improve patient safety in Veterans Administration Medical Centers. Journal of Healthcare Information Manage-ment 2002. 16 (1) p. 46-51.

Johnson M.E. Overview of the file manager. In: Proceedings of the

Fifth Annual Symposium on Computer Applications in Medical Care.1981, pp. 56-59.

Meldrum K., Volpp B., Vertigan R.. Department of Veterans Affairs computerized patient record system. In: Proceedings of AMIA Symposium. 1999, No. 1-2, p. 1214.

Mosquera M. VA budget would boost health IT, claims processing. Government Health IT. [Online] 2008. Disponibile all’indiriz-[Online] 2008. Disponibile all’indiriz-zo URL: http://www.govhealthit.com/online/news/350209-1.html. Ultimoaccesso:29ottobre2008.

Rundle R. In the drive to mine medical data, VHA is the unlikely leader. The Wall Street Journal, New York, 2001, p. 1

Smith C. An Opensource Health Information System for the 21st century. Presentation at the OSS Watch Sustainbility Confer-ence. Business School, Oxford, aprile 2006.

Timson G.F. The file manager system. In: Proceedings of the Fourth Annual Symposium on Computer Applications in Medical Care. 1980, pp. 1645-1649.

Turano A. VistA: FileMan, Kernel, CPRS and MedicalData. Vista Software Alliance [Online] 2006. Disponibile all’indrizzo URL: http://www.vistasoftware.org/presentations/VistAIntroduc-tion_080406.pdf. Ultimoaccesso:29ottobre2008.

Veterans Administration (VA) 2004. Disponibile all’indirizzo URL: www.va.gov/vista. Ultimo accesso: 25 ottobre 2008.

WorldVistA 2005. Disponibile all’indirizzo URL: www.worldvista.org. Ultimoaccesso:25ottobre2008.

Paragrafo 5.6Andreoni B. Assistenza Domiciliare Integrata. Masson editore 2000.Bergamasco R, Schiavon L. Assistenza Domiciliare. Milano, Mc-

Graw-Hill 2000.Borghi G. Fra ospedale e territorio: politiche, modelli e supporti

tecnologici. Osservatorio Telesanità, quaderno AIM n° 44, CE-FRIEL (Regione Lombardia) 2000.

Bragonzi G, Orsi W. Progetto e-Care. [online] 2006; Disponibi-le all’indirizzo: http://urp.comune.bologna.it/WebCity/Cit-yLights.nsf/3517d58584915955c1256b4f003c8afe/abb64f1cd6f3b52ac125720a00432bbf/$FILE/Bragonzi_Orsi.pdf Ultimo accesso: 16 settembre 2008

Chierici S, Rampinini M. Cellulare e pacemaker:vanno d’accordo? [Online]. 7 Feb 2003. Disponibile all’indirizzo: URL: http://www.asl.milano.it/docpdf/ondemagnetiche.pdf Ultimo accesso: 16 settembre 2008

D’Innocenzo M, Trippetti S. Argomenti di Economia per le profes-sioni sanitarie. Milano, McGraw-Hill 2006.

Fontana C. IEIIT-CNR. Le Tecnologie per MobiDis. Analisi delle tecnologie disponibili per la telemedicina. [Online] 2004. Di-sponibile all’indirizzo: URL: http://www.irpps.cnr.it/mobidis/pdf/tecnologie%20Mobidis.pdf

Guarino F. Mignardi L. Tecnologieareteperlasaluteel`assistenza. Suppl. di: Salute e società, n. 2/2007. Milano, Franco Angeli 2007.

IMTES Istituto Mediterraneo per la Telematica in Sanità [Online]. 2008; Disponibile all’indirizzo: URL: http://www.imtes.net/pro-filo.htm Ultimo accesso: 16 settembre 2008

Nonne-Care. Tecnologie e reti di persone per il nuovo welfare. [On-line] 2006. Disponibile all’indirizzo: URL: http://www.onecare.cup2000.it/nonne-care Ultimo accesso: 28 luglio 2009.

Papi G, Ricc FL. La telemedicina [Online]. 31 Gennaio 2003; Di-sponibile all’indirizzo: URL: http://dns2.icar.cnr.it/cannataro/unicz/ISEI-MED-II/dispense/Telemedicina.pdf Ultimo accesso: 16 settembre 2008

Scagliati FF. Linee guida regionali per le cure domiciliari [Online]. 2001; Disponibile all’indirizzo: URL: www.grusol.it/informazio-ni/lineeguida.doc Ultimo accesso: 16 settembre 2008

Trentinosalute.net. Telemedicina e cardiologia [online]; Disponi-bile all’indirizzo: http://www.trentinosalute.net/context_biblio-teca.jsp?area=44&ID_LINK=99&page=12 Ultimo accesso: 16 settembre 2008

Valerio E. Un nuovo progetto per supportare gli anziani: E-Care/OLDES [Online] 2000. ; Disponibile all’indirizzo: http://www.regione.emilia-romagna.it/wcm/par/sezioni_laterali/articoli/Un_nuovo_progetto_per_supportare_gli_anziani.pdf Ultimo accesso: 16 settembre 2008

Paragrafo 5.7Cascetta F. e De Luccia M. Sistemi di identificazione personale

[Online]. Mondo Digitale, marzo 2004; 1 p. 44-55.CNIPA Centro Nazionale per l’Informatica nella Pubblica Am-

ministrazione. La biometria entra nell’e-government [Online]. Marzo 2005; Disponibile all’indirizzo: URL: http://www.cnipa.gov.it/site/_files/01_Quaderni_15.pdf / Ultimo accesso: 1 Feb-braio 2008

CNIPA Centro Nazionale per l’Informatica nella Pubblica Ammi-nistrazione. Linee guida per l’impiego delle tecnologie biometri-che nelle pubbliche amministrazioni [Online]. Novembre 2004;

Disponibile all’indirizzo: URL: http://www.cnipa.gov.it/site/_files/I%20QUADERNI9.pdf Ultimo accesso: 1 Febbraio 2008

Dolan TG, Biometric Identification — You See It in the Movies. Will You See It in the Hospital?. Radiology Today. 2006;7(25):14.

European Biometrics Portal-Unysis. Biometrics in Europe: Trend June report 2006 [Online]. 4 Luglio 2006; Disponibile all’in-[Online]. 4 Luglio 2006; Disponibile all’in-4 Luglio 2006; Disponibile all’in-dirizzo: URL: http://www.europeanbiometrics.info/images/re-sources/112_165_file.pdf Ultimo accesso: 1 Febbraio 2008

European Commission Joint Research Centre. Technical report Se-echnical report Se-rier: Biometrics at the frontiers: Assessing the impact on society [Online]. 23 Marzo 2005; Disponibile all’indirizzo: URL:http://ec.europa.eu/justice_home/doc_centre/freetravel/doc/biometri-cs_eur21585_en.pdf Ultimo accesso: 1 Febbraio 2008

National Science and Technology Council. Biometrics “Foundation Documents” [Online]. 28 Giugno 2006; Disponibile all’indiriz-zo: URL: http://www.biometrics.gov/Documents/biofounda-tiondocs.pdf Ultimo accesso: 1 Febbraio 2008

Paragrafo 5.8American Academy of Family Physicians (AAPF) Center for Health

Information Technology (CHIT). ASTM Continuity of Care Record (CCR), web site: http://www.centerforhit.org/x201.xml, 2006. Ultimo accesso: 3 dicembre 2008

American College of Cardiology, Healthcare Information and Man-agement Systems Society and the Radiological Society of North America. Integrating the Healthcare Enterprise, web site: http://www.ihe.net/About/index.cfm, 2001. Ultimo accesso: 3 dicem-Ultimo accesso: 3 dicem-bre 2008

Bray T, Paoli J, Sperberg-McQueen CM, Maler E, Yergeau F. Ex-tensible Markup Language (XML) 1.0, third ed., W3C Recom-Language (XML) 1.0, third ed., W3C Recom-mendation, W3C.org, web site: http://www.w3.org/TR, 2004. Ultimo accesso: 3 dicembre 2008

Civan A, Skeels MM, Stolyar A, Pratt W. Personal health informa-tion management: consumers’ perspectives. AMIA Annu Symp Proc. 2006:156-60.

Demiris G, Afrin LB, Speedie S, Courtney KL, Sondhi M, Vi-marlund V, Lovis C, Goossen W, Lynch C. Patient-centered Applications: Use of Information Technology to Promote Dis-ease Management and Wellness. A White Paper by the AMIA Knowledge in Motion Working Group. J Am Med Inform Assoc. 2008;15(1):8-13.

Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo Shvo A. HL7 Clinical Document Architecture, Release 2.

J Am Med Inform Assoc. 2006;13(1):30-9.Federal Information Processing Standards. Publication 197. Ad-

vanced Encryption Standard (AES), web site: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf, 2001. Ultimo acces-Ultimo acces-so: 3 dicembre 2008

Ferranti JM, Musser RC, Kawamoto K, Hammond WE. Th e clini-The clini-cal document architecture and the continuity of care record: a critical analysis. J Am Med Inform Assoc. 2006;13(3):245-52.

Kim E, Mayani A, Modi S, Kim Y, Soh C. Evaluation of patient-centered electronic health record to overcome digital divide. Conf Proc IEEE Eng Med Biol Soc. 2005;2:1091-4.

Kim MI, Johnson KB. Personal health records: evaluation of func-tionality and utility.J Am Med Inform Assoc. 2002;9(2):171-80.

Lacal JC. IEEEP2407 Standard for Personalized Health Informat-ics. web site: http://www.ieee2407.org/about.html, 2004. Ul-timo accesso: 3 dicembre 2008

Lober WB, Zierler B, Herbaugh A, Shinstrom SE, Stolyar A, Kim EH, Kim Y. Barriers to the use of a personal health record by an elderly population. AMIA Annu Symp Proc. 2006:514-8.

Marceglia S, Pinciroli F. La cartella clinica informatica, in Pinciroli F, Masseroli M (a cura di), Elementi di informatica Biomedica, Milano, IT: Polipress Editore, 2005, pp. 1-22.

Markle Foundation, Connecting for Health, The personal health working group final report, web site: http://www.markle.org/downloadable_assets/final_phwg_report1.pdf, 2003. Ultimo ac-cesso: 3 dicembre 2008

Moen A, Brennan PF. Health@Home: the work of health informa-tion management in the household (HIMH): implications for consumer health informatics (CHI) innovations. J Am Med In-form Assoc. 2005;12(6):648-56.

Object Management Group. The Unified Modeling Language ™ - UML. UML® Resource Page, web site: http://www.uml.org/, 1997. Ultimo accesso: 3 dicembre 2008

Rivest R, Shamir A, Adleman L. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM. 1978;21(2):120-126.

Shabo A, Hughes SK. Family History Information Exchange Services Using HL7 Clinical Genomics Standard Specifica-tions. Int’l Journal on Semantic Web & Information Systems, 2005;1(4):42-65.

Wright A, Sittig DF. Encryption characteristics of two USB-based personal health record devices. J Am Med Inform Assoc. 2007;14(4):397-9.

La logistica urbana. Elementi conoscitivi per la governance del processo, a cura di Flavio Bo-scacci, Elena Maggi, Polipress Milano, novembre 2004; pp. VIII-188.€ 18,00; ISBN 88 7398 010 4

Claudio Bernuzzi, Proporzionamento di struttu-re in acciaio, Polipress Milano, febbraio 2005, pp. XII-320.€ 32,00; ISBN 88 7398 011 2

Valentina Rognoli, Marinella Levi, Materiali per il design: espressività e sensorialità, Polipress Milano, giugno 2005; pp. X-180.€ 24,00; ISBN 88 7398 012 0

Cicli combinati a gas naturale. Polveri sottili ed emissioni gassose, a cura di Ennio Macchi, Poli-press Milano, luglio 2005; pp. VI-214.€ 30,00; ISBN 88 7398 013 9

Breve storia del Politecnico di Milano, con illu-strazioni di Emilio Giannelli, Polipress Milano, agosto 2005; pp. 54.€ 7,50; ISBN 88 7398 014 7

Catalytic Combustion, editors Pio Forzatti, Gianpiero Groppi, Paolo Ciambelli, Diana Sanni-no, Polipress Milano, settembre 2005; pp. VIII-520 2 voll.€ 50,00; ISBN 88 7398 015 5

Ennio Macchi, Stefano Campanari, Paolo Silva, La microcogenerazione a gas naturale, Polipress Milano, settembre 2005; pp. XII-282.€ 45,00; ISBN 88 7398 016 3

Elementi di Informatica BioMedica, a cura di Francesco Pinciroli, Marco Masseroli, Polipress Milano, ottobre 2005; pp. XVIII-382.€ 38,00; ISBN 88 7398 017 1

Maria Dina Vivarelli, The Amazing S-Code of the Conic Sections and the Kepler Problem, Polipress Milano, dicembre 2005, pp. VI-94.€ 13,00; ISBN 88 7398 018 X

Altre pubblicazioni Polipress

Fernando Sansò, Navigazione geodetica e rile-vamento cinematico, Polipress Milano, gennaio 2006; pp. XII-294. € 32,00; ISBN 88 7398 019 8

Luciano Lazzari, Pietro Pedeferri, Cathodic Protection, Polipress Milano, gennaio 2006; pp. XVIII-366.€ 49,00; ISBN 88 7398 020 1

La nascita dell’Informatica in Italia, a cura di Luigi Dadda, Polipress Milano, marzo 2006; pp. VI-132.€ 15,00; ISBN 88 7398 021 X

Michela Arnaboldi, Davide Chiaroni, I nuovi standard contabili internazionali IAS-IFRS. Principi e casi reali, Polipress Milano, febbraio 2006; pp. 106.€ 15,00; ISBN 88 7398 022 8

Marco Bramanti, Maurizio Verri, Politest. Il test di Ingegneria al Politecnico di Milano, Polipress Milano, aprile 2006; pp. XIV-144.copia omaggio; ISBN 88 7398 023 6

Andrea Galliani, Ernesto Pedrocchi, Analisi Exergetica, Polipress Milano, ottobre 2006; pp. XIV-370.€ 35,00; ISBN 88 7398 025 2

Paolo Maria Ossi, Plasmi per Superfici, Polipress Milano, novembre 2006; pp. X-206.€ 25,00; ISBN 88 7398 026 0

Progetto Bovisa, Polipress Milano, novembre 2006; pp. 264.€ 20,00; ISBN 88 7398 027 9

Luciano Lazzari, Pietro Pedeferri, Protezione catodica, Polipress Milano, dicembre 2006; pp. XXVI-470.€ 49,00; ISBN 88 7398 028 7

Giorgio Diana, Ferruccio Resta, Controllo di sistemi meccanici, Polipress Milano, gennaio 2007; pp. VI-346.€ 32,00; ISBN 88 7398 024 4

Giulia Fiorese, Giorgio Guariso, Antonio Lazza-rin, Renato Razzano, Energia e nuove colture agricole. Potenzialità delle biomasse a scala regionale, Polipress Milano, febbraio 2007; pp. XIV-258.€ 30,00; ISBN 97888 7398 029 2

Michele Monno, Massimiliano Annoni, Chiara Ravasio, Water jet, a flexible technology, Poli-press Milano, febbraio 2007; pp. XIV-250.€ 25,00; ISBN 97888 7398 030 8

Simmetria: una scoperta matematica, a cura di Renato Betti, Elena Marchetti, Luisa Rossi Costa, Polipress Milano, marzo 2007; pp. XII-80.€ 13,00; ISBN 97899 7398 031 5

Pietro Pedeferri, Corrosione e protezione dei materiali metallici, Vol. I, Polipress Milano, aprile 2007; pp. XVI-314.€ 32,00; ISBN 97899 7398 032 2

Francesca Cognetti, Bovisa in una goccia. Nuovi equilibri per un quartiere in trasformazione, Polipress Milano, giugno 2007; pp. 128.€ 8,00; ISBN 97899 7398 033 9

Elena Maggi, La logistica urbana delle merci. Aspetti economici e normativi, Polipress Milano, settembre 2007; pp. XIV-306.€ 30,00; ISBN 97899 7398 037 7

Pietro Pedeferri, Corrosione e protezione dei materiali metallici, Vol. II, Polipress Milano, ottobre 2007; pp. XVIII-390.€ 40,00; ISBN 97899 7398 043 8

Giancarlo Chiesa, Darko Pandakovic, Paesaggio e risorse energetiche. Le trasformazioni soste-nibili nel territorio montano, Polipress Milano, settembre 2007; pp. XII-138.€ 25,00; ISBN 97899 7398 040 7

Fabio Fossati, Teoria dello yacht a vela, Poli-press Milano, novembre 2007; pp. XVIII-610.€ 75,00; ISBN 97899 7398 035 5

Lucio Lamberti, Giuliano Noci, Jurong Guo, Schichang Zhu, Bing Juan, A Sino-European Comparison of the Exhibition and Convention Industry, Polipress Milano, novembre 2007; pp. XVI-144.€ 25,00; ISBN 97899 7398 042 1

Scritti in onore del Professor Francesco Turco, a cura di Armando Brandolese, Alberto Grando, Marco Perona, Polipress Milano, dicembre 2007; pp. VIII-256.€ 25,00; ISBN 97899 7398 036 0

Renzo Riboldazzi, Una città policentrica. Cesare Chiodi e l’urbanistica milanese nei primi anni del fascismo, Polipress Milano, maggio 2008; pp. XII-292.€ 29,00; ISBN 97899 7398 039 1

Marinella Levi, Emanuele Schivo, Paolo Soro, MATEOD - Raccolta differenziata di materiali avanzati, Polipress Milano, maggio 2008; pp. 300 schede tecniche.€ 75,00; ISBN 97899 7398 044 5

Campus Point, a cura di Riccardo Pietrabissa, Polipress Milano, maggio 2008; pp. 144.€ 25,00; ISBN 97899 7398 047 6

Carlo Lombardi, Ernesto Pedrocchi, Introduzio-ne all’energia nucleare, Polipress Milano, giu-gno 2008; pp. VIII-90.€ 15,00; ISBN 97899 7398 046 9

Franco Giacomazzi, Marketing Industriale, Poli-press Milano, settembre 2008; pp. XII-640.€ 27,00; ISBN 97899 7398 051 3

Emanuela Del Curto, Politest. Comprensione verbale, Polipress Milano, dicembre 2008; pp. VIII-104.copia omaggio; ISBN 88 7398 052 0

Muscogiuri Marco, Poggioli Piero, Università e Territorio, Polipress Milano, gennaio 2009; pp. 196.€ 25,00; ISBN 97899 7398 054 4

Luca Reggiani, Guido Tartara, Sistemi di radio-comunicazione, Polipress Milano, marzo 2009; pp. 162.€ 15,00; ISBN 97888 73978 050 6

Carlo Lombardi, Impianti nucleari, Polipress Milano, aprile 2009; pp. XII-710.€ 60,00; ISBN 97888 73978 055 1

Luigi Ascione, Antonella Giordano, Riabilitazio-ne strutturale con materiali compositi fibro-rinforzati, Polipress Milano, maggio 2009; pp. XIV-108.€ 30,00; ISBN 97888 73978 053 7

Pietro Natale Maggi, Il processo edilizio, II volu-mi, Polipress Milano, luglio 2009; pp. 1050.€ 50,00; vol. 1: ISBN 97888 73978 057 5vol. 2: ISBN 97888 73978 058 2

Compasso volante, a cura di Marco Imperado-ri, Matteo Brasca, Polipress Milano, settembre 2009; pp. 142.€ 25,00; ISBN 97888 73978 060 5

Finito di stamparenel mese di ottobre 2009presso Poliprint - Politecnico di Milano

applicazioni di sanità digitale - pinciroli bonacina

Documents

press release bonacina pierantonio june 2009

istituto superiore di sanità - qs - quotidiano sanità...

microsoft power point presentazione- iab 2012 - bonacina e...

fabiana bonacina definiÇÃo do processo de fabricaÇÃo de...

unified modeling language uml fernando pinciroli solus s.a....

vittorio bonacina by acquiring the brand pierantonio ... ·...

primo bonacina - cv · 2016-07-20 · primo bonacina - cv -...

pbs - primo bonacina services · pbs –primo bonacina...

non sanità elettronica, solamente sanità migliore: to do...

efrem bonacina

pbs (primo bonacina services) talent ( ... · pbs – primo...

subscriber copy architectural digest discover! ·...

scuola primaria gianni rodari massalengo. pinciroli edoardo...

sanitÀ e salute - qs - quotidiano sanità

pbs - primo bonacina services per adwords · pbs - primo...

primo bonacina services per adwords come fare pubblicità...

profs.sci.univr.itprofs.sci.univr.it/~bonacina/talks/phdthesisdefense1992-slides.pdf ·...

primo bonacina · 2016-12-20 · primo bonacina - cv -...

igiene sanità 2 2010 · 2019. 9. 25. · igiene e sanità...

aziendalizzazione sanità