Introduzione

Parlare di informatica sanitaria, senza parlare di integrazioni non ha oramai alcun senso. La realtà sanitaria è infatti variegata oltre che dal punto di vista medico-sanitario-infermieristico da quello informatico. Il panorama sanitario italiano è costituito da ASL, Aziende Ospedaliere, Istituti di cura a carattere scientifico, università, cliniche private, che raggruppano tutta una serie di servizi più o meno strutturati. Se pensiamo che ogni servizio, sia interno che esterno può essere informatizzato con strumenti e tecnologie diverse, ci rendiamo ben presto conto della difficoltà con cui queste possono interagire tra loro. A livello medico-infermieristico, c’è e ci deve essere forte interazione tra settori di diverse competenze se si vuole ottenere come obiettivo la cura del paziente. Gli specialisti devono collaborare tra loro scambiandosi, opinioni, informazioni, studi, protocolli di cura se vogliono vincere le battaglie contro le malattie più o meno gravi che non possono essere inquadrate in un unico settore specialistico.

Tecnologie e Sanità

Informaticamente parlando i tempi sono maturi, e forse lo erano già da parecchio, per offrire il supporto tecnologico necessario per tutte quelle attività che normalmente vengono svolte in ambiente sanitario, dalla prenotazione degli appuntamenti alla gestione degli apparati clinico - diagnostici, dalla gestione dei ricoverati alle liste di attesa. Esistono decine di software in grado di gestire i più semplici processi, e tanti altri possono essere sviluppati all’aumentare della complessità dei servizi offerti. L’operatore non deve aver paura di utilizzare questi strumenti, deve essere consapevole che sono solamente dei mezzi e non possono sostituire la capacità di analisi di ragionamento propria dell’essere umano. Altro deterrente nell’utilizzo della tecnologia, è la paura che le aziende possano esercitare un controllo totale di quello che viene svolto nell’esercizio della propria professione. Una paura più che lecita, quando ad esercitare questi controlli sono persone prive delle competenze necessarie, senza qualifiche senza un adeguato percorso formativo, che si trovano in un determinato ruolo solo perché non si sapeva cosa fargli fare nella vita. Spesso e volentieri sono queste le persone che ricoprono i ruoli di più grande responsabilità, quella di dover prendere delle decisioni. In tutto questo processo intervengono numerose entità, quali i sindacati, la politica, la religione, l’università ma questi sono argomenti che esulano dal fine di questo documento ((condizioni al contorno)). Tornando alle problematiche tecnologiche in ambito sanitario possiamo dire che ad oggi esistono due grandi famiglie di tipologie di software quelli cosiddetti client - server e le applicazioni web. I primi sono in auge già da parecchi anni, e sono maturi per poter gestire processi complessi in cui vi è una spiccata verticalizzazione e una necessità di rendere veloci le applicazioni. Questo perché nel client - server la logica dell’applicazione (il software) viene installato direttamente sulla macchina (computer) utilizzatrice, mentre i processi/applicazioni serventi (basi di dati e altro) risiedono su macchine remote. L’interazione quindi client - server è ridotta al minimo con conseguente aumento della velocità di esecuzione dovuta alla riduzione dell’eventuale collo di bottiglia rappresentato dalle infrastrutture di rete. Di contro, questo approccio applicativo presenta problematiche di gestione ed aggiornamento, anche se si stanno facendo notevoli sforzi per gestire questa fase in maniera più automatica possibile. Le web application, nate in seguito al fenomeno internet, rappresentano la modernità in termini tecnologici ma non sono certo il toccasana che permetterà di risolvere a breve termine tutti i nostri problemi. Esse si basano su un meccanismo relativamente semplice, e quindi vincente, ed hanno il grande vantaggio di poter essere fruite dalla medesima applicazione client “Il Browser”. Per chi ha navigato in internet, e oramai non siamo più una elite di persone una applicazione web sanitaria può essere considerata alla stregua di un portale di commercio elettronico in cui l’applicazione vera e propria può cambiare, ma il contesto entro la quale viene eseguita è sempre lo stesso ed è rappresentato dal “Browser”. Chi ha seguito più o meno da vicino l’evolversi delle web application, sa bene a quali problemi si va incontro nell’adottare questa “scelta di campo”; problemi che coinvolgono tecniche di programmazione da adottare, tempi di esecuzione dell’applicazione, pesante utilizzo delle risorse di rete, tempi di formazione degli utilizzatori, ma cosa più importante decidere su quale “Browser” questa applicazione dovrà essere eseguita. Su quest’ultima problematica è necessario aprire una parentesi, non su cosa sia un browser (cito degli esempi: Internet Explorer, Mozilla) ma sulla mancanza di necessità di avere client differenti per l’esecuzione di applicazioni web di un certo livello di complessità. Il rischio è infatti di ripetere il modello client - server sommando alle difficoltà delle web application le difficoltà di quello client - server. La cosiddetta “guerra dei browser” , è bene relegarla all’ambito “internettiano”, o di piccole realtà private, e non dove deve intervenire pesantemente lo stato (mercato sanitario italiano), in cui l’approccio dovrebbe essere “cost - driven” . Affidarsi ad un unico browser vuol dire che la portabilità delle applicazioni su piattaforme differenti dipenderà dalla portabilità del browser. Attualmente con opportuni accorgimenti è possibile far funzionare la medesima applicazione su personal computer, palmari, tablet pc il che ne permette un facile utilizzo direttamente in reparto / corsia. Questo è reso possibile dall’evoluzione delle infrastrutture di rete. L’avvento delle reti wireless ha portato cambiamenti radicali in questo campo permettendo cablature spot relativamente veloci, affidabili ed a basso costo. Pensiamo ad esempio ad un applicativo di tipo cartella clinica informatizzata, su cui il medico/infermiere dovrà giornalmente aggiungere dei dati. Una operazione di questo tipo eseguita in maniera tradizionale prevede la compilazione manuale di schede da aggiungere alla cartella clinica, come il diario medico, la rilevazione di parametri vitali, i fogli di lavoro ecc.. ecc.. Difficile pensare che i medici, e gli infermieri incaricati di svolgere questi lavori eseguano il task due volte, prima in maniera tradizionale, quindi ripetendo le operazioni sul personal computer. Uno scenario di questo tipo è ipotizzabile in fase iniziale di avvio dell’applicativo e solamente per un breve intervallo temporale. L’informatizzazione come detto precedentemente deve avere lo scopo di semplificare il lavoro e non di complicarlo.

Parola d’ordine: “integrare”!

Come fronteggiare questa frammentazione informatica e organizzativa? A questa domanda non esiste un'unica risposta, ma possiamo optare per più soluzioni, facendosi guidare dalle necessità del problema che stiamo affrontando. Difficile pensare di adottare, in realtà molto complesse un approccio che prevede il rinnovo completo, immediato A questo punto verrebbe da chiedersi: “una sanità paperless è quindi possibile?” . “Se le tecnologie sono mature possono essere adottate pesantemente per risparmiare tempo, denaro, rispettare l’ambiente, migliorare la qualità del lavoro di impiegati e dirigenti?” Il mio punto di vista è che oltre ad essere possibile è auspicabile e deve essere realizzata più velocemente possibile. Per vincere le resistenze dei dirigenti in termini di sicurezza, affidabilità, privatezza dei dati ci sono gli informatici, i sistemisti, i consulenti, a tutela dei lavoratori ci sono gli organi sindacali, che remando in fase possono amplificare i benefici di una informatizzazione spinta.

Tecniche di integrazione software

Esistono varie tecniche per integrare sistemi software in generale, nel caso sanitario ne descriviamo tre in particolare 1. Integrazione lato db 2. integrazione software “secca” 3. Integrazione software attraverso middleware /software La prima è una forma di integrazione abbastanza semplice ma oserei dire obsoleta e non sempre realizzabile con i diversi database a cui si poggiano le moderne architetture. Essa prevede una integrazione in senso stretto tra due o più db presenti, normalmente fatta a colpi di trigger e stored procedure ove queste sono supportate dal db in oggetto.Come accennato in precedenza una integrazione di questo tipo se da un lato comporta una certa facilità implementativi (visti gli skill di persone che in genere operano nei ced) dall’altro porta ad una difficile gestione e distribuzione della conoscenza. Chi realizza queste integrazioni ne detiene lo scettro e poiché normalmente poco strutturate difficilmente verranno passate di mano, e sicuramente spendendo risorse di tempo e di soldi. Se ci si vuole astrarre di livello bisogna cercare di spostare la logica delle integrazioni su un livello logico di più ampio respiro che magari rende indipendente l’integrazione dalla tipologia di database presente. Spostandoci a livello software(punto 2,3) otteniamo quindi diversi benefici: astrazione dal livello data base riutilizzo del codice controllo delle integrazioni facilità di manutenzione del codice Se pensiamo ad una forma di integrazione attraverso la scrittura di codice in un qualsiasi linguaggio di programmazione, ad esempio java o visual basic è possibile gestire le integrazioni attraverso funzioni che eseguono query sul data base che spostano dati controllandone la conformità allo standard cercato. In questo modo se il problema è stato ben analizzato un programmatore è in grado di gestire queste transazioni attraverso una logica che non risiederà più nel data base, bensì potrà essere una applicazione schedulata in esecuzione sul serve. Una integrazione del genere è più versatile di quella fatta esclusivamente usando le potenzialità di software scritto sul data base. Una tecnologia più sofisticata per gestire le integrazioni è quella di utilizzare software di terze parti che faccia da arbitro e controlli l’integrazione. Esistono diversi software “middleware” che realizzano questo come ad esempio BizTalk di Microsoft. Questi hanno il compito di stare al centro delle applicazioni da integrare prelevando dati da una parte manipolari e inserirli dall’altra, gestendo eventuali ritrasmissioni, e se ben programmati tenendo traccia anche degli errori incontrati. Il costo di questi è giustificato nel caso di integrazioni di un certo livello dove si vuole avere qualche garanzia in più sul buon funzionamento. Software come BizTalk hanno embeded diversi ad adattatori che lo rendono utilizzabile su differenti basi di dati e sono programmabili anche utilizzando dei semplici wizard per la gestione e la manipolazioni di quest’ultimi.

Conclusioni La sanità e le tecnologie sono un binomio inscindibile già da tempo sugli apparati clinici, e lo diventeranno ben presto sulla parte sanitaria e sulla gestione dei processi interni per contenere i costi e valorizzare le risorse sgravandole da quintali di scartoffie in cui si perderebbe anche il più bravo bibliotecario italiano. Vincere le resistenze interne portandole a comprendere la necessità delle nuove tecnologie vuol dire aprire finalmente questo mondo ancora poco esplorato ad un nuovo modello di gestione più semplice e renumerativo.

Ing. Andrea Del Vecchio