L a procedura per la certificazionedel software è stata messa a punto,inizialmente, a partire dall’espe-

rienza maturata con la messa in produzio-ne di un sistema informatizzato di gestio-ne della Terapia farmacologica e, successi-vamente, con la sua applicazione ad altriambiti critici (procedura di richiesta dareparto degli emocomponenti).

La prima esperienza riguarda un siste-ma informatizzato per la gestione dellaterapia farmacologica per i pazienti ricove-rati, presso gli Ospedali riuniti di Bergamoa partire da maggio 2006 (v. tabella).

Dalla prima versione, nella quale eranopresenti alcune funzioni base per l’oncolo-gia e l’ematologia, si è passati a un siste-ma correntemente utilizzato in circa 25realtà mediche differenti. L’aumento dellefunzioni e della complessità del processooperativo che il sistema gestisce, ha porta-to alla necessità di un controllo sulla suasicurezza e affidabilità, considerando chele azioni e gli elementi su cui si lavorasono collegati alla salute del paziente.

Nel 2007 si è proceduto a un test estensi-vo del sistema per individuarne eventualidifetti, anomalie e problemi che lo strumen-to, se non correttamente pensato e utilizza-to, può causare al paziente. Gli elementi sucui è stato sviluppato il lavoro sono i docu-menti di specifica redatti in azienda a segui-to delle interviste sul campo con i futuriutenti e utilizzati dopo per lo sviluppo delsoftware e i documenti operativi prodottidurante l’avviamento el’utilizzo quotidiano delsistema.

Per approssimazionie revisioni successive,utilizzando sia metodolo-gie consolidate nel cam-po del “software engine-ering”, sia approcci inno-vativi più avanti descritti, sono stati realiz-zati ed eseguiti circa 2.900 casi di prova.Poi il sistema è stato perfezionato nei pun-ti individuati dal test. Nel corso dei lavoriè apparsa sempre più evidente la necessitàdi considerare due diversi aspetti del per-corso di certificazione: considerare l’affi-dabilità del prodotto, legata a tutte le fun-zionalità messe a disposizione dal prodot-to software, ma anche condurre un’analisidi rischio legata all’utilizzo dello strumen-to. Questo secondo aspetto pone il proble-ma se un insieme di funzioni separate matra loro collegate nel processo operativopossono originare, da un problema di una,effetti critici sul percorso completo di tera-pia per il paziente.

Aspetti metodologici. Il metodo cheabbiamo seguito per condurre le attività diverifica e analisi sopra descritte tiene con-to degli aspetti di contesto in cui ci sipone: l’utente è un acquirente e utilizzato-re di software per uso clinico, tipicamenteun ente ospedaliero; il software può esserestato sviluppato ad hoc per l’ente oppurepuò essere un prodotto acquisito in licenzad’uso; il prodotto acquisito può anche esse-re estensivamente parametrizzato in modoche il suo comportamento reale, una voltainstallato, non dipenderà solamente dalprogramma, ma anche dallo stato dei para-metri di configurazione.

Conseguentemente il metodo si compo-ne di tre approcci differenziati per livello:il livello dell’interazione sistemica (Fmea;modalità di rilascio e attivazione del pro-dotto); il livello dell’analisi funzionale(eseguito in condizioni “di laboratorio”); illivello della “safety” (eseguito in condizio-ni che simulano l’operatività).

Il primo aspetto metodologico è di fon-damentale importanza. Un’applicazionesoftware per uso clinico è parte di unsistema informativo più ampio ed è sogget-

ta a evoluzione nel tempo. L’applicazionepuò essere modificata e adattata a nuoveregole organizzative ed esigenze, o inter-facciata con altre applicazioni, o modifica-ta funzionalmente, a esempio adattandonei parametri di configurazione. Questa evo-luzione può portare a delle variazioni nel-l’affidabilità e nella sicurezza d’uso e ren-dere non più significative le pur rigoroseverifiche effettuate “in laboratorio”, prima

del suo effettivo utilizzo“in produzione”. È quin-di di essenziale impor-tanza che il processo digestione dell’applicazio-ne sia accuratamentespecificato e posto sottocontrollo. Si pensi aesempio alla seguente se-

quenza di eventi: è identificato un malfun-zionamento, il software è corretto ed ègenerata una nuova versione, per errore èmessa in produzione la versione preceden-te, oppure il personale non è correttamenteinformato e non utilizza la funzionalitàrilasciata. Ogni modifica deve perciò esse-re autorizzata, gestita e tracciata, il rilascioin produzione di una nuova versione deveessere controllato e per ogni modifica de-ve essere riconsiderata la valutazione disicurezza d’uso al fine di decidere se ènecessario rivederla o estenderla. Si notiche questo processo deve definire con pre-cisione tutti i componenti che vanno messisotto controllo, sia tecnologici che organiz-zativi. Un esempio significativo è la pre-senza di dati attraverso i quali è possibileconfigurare un prodotto software acquisito

in licenza da un produttore. In questo casoil sistema è composto dal software e daidati di configurazione ed entrambi devonoessere considerati in un processo unitariodi gestione. L’interazione tra persone esistema, infine, mette in evidenza elementiproblematici: dall’analisi formale (Fmea)si ricavano indicazioni su dove sia meglioinserire controlli e ausili all’operativitàumana (messaggi di avvertimento; blocchiall’esecuzione di procedure non corrette).

Preliminarmente tuttavia, l’obiettivo èraggiungere una ragionevole garanzia sul-la “qualità” del prodotto. In particolare,consideriamo due specifici aspetti: l’affida-bilità (la proprietà di comportarsi comespecificato, senza malfunzionamenti) e lasicurezza d’uso (la proprietà di non mani-festare comportamenti che possano contri-buire a causare danni ai pazienti). Ricordia-mo che le due caratteristiche sono diversee richiedono modi diversi per dare unaragionevole garanzia che il prodotto lepossieda. Un prodotto software potrebbeessere molto affidabile, manifestando unnumero molto basso di malfunzionamentidurante un lungo periodo d’esercizio, mapotrebbe causare gravi danni al pazienteper quei rari malfunzionamenti. Ricordia-mo anche che queste due caratteristichenon esauriscono l’insieme delle possibili“qualità” di un prodotto software. Nonconsideriamo a esempio l’usabilità e cioèla facilità d’uso del software.

Si può dare una ragionevole garanziasull’affidabilità del prodotto, progettandoe realizzando un adeguato insieme di casidi test. Considereremo casi di test di tipo

“funzionale” e cioè prove di funzionamen-to per le quali la singola funzione (nonl’intero programma che ha effetti sistemiciche vanno considerati per se stessi) è una“scatola nera” che riceve dati di ingresso ecomandi e produce risultati, senza che chiesegue il test conosca la struttura internadel software. Questo modo di operare èadeguato dal punto di vista di un utilizzato-re del software, e parte dal presuppostoche lo sviluppatore ab-bia già esaurito tutte lealtre modalità di provache considerano invecela struttura interna deiprogrammi.

Lo sviluppo di un pia-no di prove richiede ladefinizione di una strate-gia adeguata. Il software deve essere verifi-cato da più punti di vista diversi che devo-no essere testati separatamente. Identifi-chiamo almeno i seguenti tre punti vista:● l’insieme delle funzioni elementari,ognuna delle quali può essere eseguita daun utilizzatore. In questi sistemi ogni fun-zione è costituita da una o più maschereche permettono di interagire con una basedi dati;● l’insieme dei processi utente. Ogni pro-cesso (a esempio di prescrizione, prepara-zione e somministrazione di un ciclo diterapia protocollata in un sistema softwareche gestisce la prescrizione e somministra-zione dei farmaci) è costituito da un flussodi attivazioni di più funzioni elementari dauno o più utenti (medico, farmacista einfermiere in questo caso);

● l’insieme dei vincoli che sono impostiallo svolgersi dei processi (a esempio unaterapia “protocollata” può essere in statidiversi: prescritta, in corso, sospesa, termi-nata, e il passaggio da uno all’altro è sog-getto a regole aziendali e operative).

La verifica di aspetti diversi attraversoun piano di test è importante poiché ognigruppo di test legato a un aspetto, puòrilevare malfunzionamenti generati da di-

verse cause. A esempio,la verifica di ogni singo-la funzione può eviden-ziare problemi dovuti aun carente controllo deidati di ingresso attraver-so le maschere, mentrela verifica dei processipuò rilevare problemi di

interazione delle funzioni attraverso i datidalla base dati o problemi dovuti a carenzedi specifica.

In particolare sarà opportuno modellarei processi utente e gli insiemi di vincoli,con strumenti linguistici più rigorosi dellinguaggio naturale, perché sia possibileapplicare tecniche sistematiche, note daletteratura, per generare i casi di test.

L’elenco delle funzioni (con le associa-te specifiche), i modelli dei processi e imodelli degli insiemi di vincoli, sono labase per applicare le tecniche più adeguateallo stato dell’arte per produrre i casi diprova. L’attività di test fornirà un rapportofinale che include la descrizione della stra-tegia e delle tecniche adottate, l’elenco deicasi di prova, l’esito di ogni caso e ladocumentazione che certifica l’esito.

È noto che non è possibile per un siste-ma software complesso, dimostrare la cor-rettezza e cioè l’aderenza alle sue specifi-che. È invece possibile produrre un rappor-to di test che porti a una “ragionevolefiducia” nell’utilizzo, basato su un approc-cio robusto, ben fondato scientificamentee difendibile allo stato dell’arte davanti auna commissione di esperti. Egualmenteimportante è la valutazione di un softwareclinico per quanto riguarda la sua“sicurezza d’uso” (o, se vogliamo utilizza-re il termine anglosassone, “safety”, danon confondere con la “sicurezza” nel sen-so di privatezza, a esempio dei dati). Nellaclasse dei sistemi informativi utilizzati perapplicazioni cliniche, un ruolo importanteper la sicurezza d’uso è svolto dai dati. Èinfatti possibile che una condizione rischio-sa possa essere causata non solo da unmalfunzionamento del programma (unprogramma calcola in modo erroneo undosaggio) ma anche da una configurazio-ne errata dei dati (un programma copiacorrettamente da un’altra base dati nella

Ict: meno rischi clinici con un

I l proposito di questo articolo è aprire un dibatti-to sull’adozione di una condivisa metodologia di

analisi del rischio e di una adeguata certificazionedi qualità, per i prodotti software da utilizzarenella pratica clinica. Va premesso che la riflessionenasce da esperienze operative svolte “sul campo”,con l’impiego di strumenti software dedicati allaspecifica attività di medici e infermieri.

La tipologia di software di cui stiamo parlando èancor oggi relativamente poco diffusa nelle corsiedei nostri ospedali, e conseguentemente il dibatti-to è da considerarsi ai suoi albori.

Recentemente, tuttavia, è intervenuto un even-to che pone all’ordine del giorno questo tema, valea dire la variazione della normativa comunitariache include il “software” in quanto tale nelle cate-gorie di oggetti definiti «dispositivi medici». Chiun-que abbia un po’ di dimestichezza con le apparec-chiature sanitarie, avrà sentito parlare della“marcatura Ce”, obbligatoria appunto per gli og-getti qualificati come «dispositivi medici». In termi-ni molto semplificati, possiamo dire che un ogget-

to tecnologico è un «dispositivo medico» se il pro-duttore dichiara che tale è la sua destinazioned’uso, e opera di conseguenza per ottenere la rela-tiva certificazione, secondo le modalità previstedalle norme. Ne consegue che nessun medico ac-cetterebbe di utilizzare un ecografo o una Tacsprovvisti del “bollino Ce”, mentre lo stesso medi-co probabilmente non si è mai posto la questionedi un’analoga certificazione per gli strumenti sof-tware.

La nuova normativa, paradossalmente, apreuno scenario problematico per il sanitario, perchéla sua applicazione acritica rischia, da un lato, dirallentare l’evoluzione possibile degli strumenti sof-tware a supporto della pratica clinica e, dall’altro,di indurre un falso senso di sicurezza - quasi chebastasse l’apposizione di questo marchio in un an-golo dello schermo di un computer a garantire lasicurezza di una procedura clinica.

La tesi di questo articolo è che - in ambitoospedaliero - abbiamo a che fare con “sistemi”organizzativi e informativi di elevata complessità,

per i quali le pur rigorose previsioni di certificazio-ne “Ce” sono insufficienti, e che richiedono invecedi pensare a modalità di “certificazione” più ade-guate alle caratteristiche loro proprie.

Possiamo definire queste caratteristiche in rap-porto a quelle più comuni di un generico dispositi-vo medico. Di quest’ultimo, a esempio, si può so-stenere che: è sottoposto a certificazione e a tara-tura; è “sigillato”; è brevettato (è un sistema pro-prietario); è un prodotto di (piccola/media) serie;ha un utilizzo procedurale (protocolli - manuali diistruzione); è sostituibile, vale a dire può esseremesso “off line”, oppure duplicato, oppure surro-gato con altro strumento; infine, non prevede (dinorma) utilizzi simultanei da parte di una pluralitàdi operatori. Se ne può concludere che stiamoparlando di oggetti che sono realizzati e utilizzaticome “scatole nere”, e nei quali tutti gli sforzi diprogettazione sono rivolti a predefinire le modali-tà di interazione con l’essere umano e con altrecomponenti tecnologiche.

Al contrario un software gestionale o di proces-

Per i programmi utilizzati nell’assistenza sanitaria sono insufficienti le marcature Ce ma

I malfunzionamentigenerano gli errori

Tre aspetti su cuifare le verifiche

Esempio di tappe dell’analisi del rischio

L’esperienza condotta agli Ospedali Riuniti di Bergamo ha dimostrato la

20 15-21 aprile 2008TECNOLOGIE

propria base dati, dati anagrafici chepossono identificare erroneamente un pa-ziente).

La sicurezza va verificata anche duran-te il processo di sviluppo del software, masecondo il punto di vista dell’utente finalee quindi le verifiche che si concentranosulle possibili interazioni tra le funzionali-tà disponibili. I criteri per la valutazione disicurezza d’uso sono basati sull’identifica-

zione di “eventi critici” pericolosi per lasalute del paziente. Un esempio di eventocritico può essere: «Viene associata al pa-ziente una somministrazione relativa a unaltro paziente».

Il metodo applica un’analisi di rischioal caso di un prodotto software che hacome componente una base di dati ed ècomposto dai seguenti passi:● sono classificati gli eventi critici e iden-

tificati gli insiemi di dati (definiti “daticritici” come i dati anagrafici del paziente)nella base dati dell’applicazione che posso-no costituire, se alimentati erroneamente,condizioni che contribuiscono a un eventocritico;● per ogni condizione così identificata èmodellato il grafo dei possibili eventi cau-sati da funzioni software che possono ge-nerare la condizione;

● in generale esiste un numero limitato difunzioni software coinvolte. Per ognuna diesse sono considerati i test realizzati perverificare l’affidabilità ed eventuali altritest specifici al fine di produrre evidenzache sia possibile attivare gli eventi model-lati.

Le prove effettuate non arrivano a di-mostrare l’impossibilità di raggiungerel’evento critico, ma sono in grado di dimo-

strare la possibilità che dei malfunziona-menti identificati nel prodotto software oanche dei funzionamenti corretti ma peri-colosi (a esempio l’input poco controllatodi dati critici) contribuiscano a generarel’evento critico.

I risultati dell’analisi permettono di for-nire suggerimenti per la modifica del sof-tware e la riduzione del rischio. Si ribadi-sce infine che la sicurezza d’uso è unaproprietà di sistema.

L’evento critico dipenderà da un insie-me di fattori che, in generale coinvolgonoil software ma anche macchinari, personee organizzazione.

Anche l’analisi di sicurezza d’uso rila-scia un rapporto finale che descrive meto-di e risultati e fornisce ragionevole e difen-dibile evidenza a supporto dell’utilizzo si-curo del prodotto.

Conclusione. Il processo di “cer-tificazione”, o di reale contenimento delrischio clinico, per questi prodotti, deveessere continuo e coinvolgere tecnologia,comportamenti personali e organizzazio-ne.

Stiamo infatti parlando della necessitàdi indagare una proprietà concreta edemergente dei sistemi, che definiamo“safety”, che si realizza solo con l’apportoefficace e integrato di tutti gli attori: inprimo luogo le persone. Poi hardware,software, dati, conoscenza, procedure or-ganizzative e - in certi casi - anche“dispositivi medici”.

software sicuroso è, per sua natura, uno strumento collaborativoche si propone di ricordare, ordinare, sistematiz-zare, semplificare, tenere traccia di tutte le azionigenerate dalla cooperazione tra esseri umani, fina-lizzata a un obiettivo complesso, come può essereassicurare la cura ai degenti di un reparto ospeda-liero. Bisogna pertanto prendere atto che questatipologia di “oggetti” basa la propria efficacia nongià sulla “chiusura”, ma sull’apertura e adattabili-tà al mutevole agire dell’essere umano all’internodi una organizzazione.

Per proseguire nell’analisi, è necessario a que-sto punto definire con una certa precisione, dalpunto di vista funzionale e dal punto di vista tecno-logico, la categoria di oggetti dei quali stiamo trat-tando, e solo successivamente portare il dibattitosulle modalità di “certificazione”.

Possono rientrare con vari livelli di appropria-tezza nella categoria dei software di rilievo clinico,i sistemi di automazione di processi diagnostici(laboratorio-radiologia); di refertazione assistita; isoftware di gestione di processi terapeutici (pre-

scrizione e somministrazione di farmaci e di emo-componenti); di gestione di protocolli di cura. Dalpunto di vista tecnologico possono valere le se-guenti caratteristiche: l’architettura software è co-stituita da una base di dati centrale e da unacollezione di funzioni che operano sulla stessa; lefunzioni non sono soltanto utilizzate per memoriz-zare dati ed eseguire interrogazioni, ma ancheper processi aziendali; i processi sono vincolati daregole aziendali che tipicamente riguardano possi-bili evoluzioni dello “stato” di entità descritte nel-la base dati; specifici dati scorretti o specifici mal-funzionamenti del software possono causare pro-blemi di “sicurezza d’uso” (causare danni alla salu-te dei pazienti).

Per condivisa ammissione, tale categoria di pro-dotti software non è “certificabile” attraverso pro-cedure di collaudo. Cosa è necessario fare pertan-to, per garantirne l’affidabilità e, al contempo, lasicurezza d’uso? In primo luogo, va affrontato, conestrema cautela, il problema della “destinazioned’uso”. Che utilità pratica può avere, infatti, dichia-

rare “dispositivo medico” e porre di conseguenzaferrei limiti al suo utilizzo e alla sua evoluzione, unprodotto che ha nella necessità di adattamentocostante uno dei suoi principali requisiti funziona-li? Non parliamo infatti di sistemi chiusi ma disistemi “aperti”, cioè modificabili in qualsiasi mo-mento, e perciò soggetti a possibili condizioni diutilizzo non definibili e completamente prevedibilia priori. Bisogna pertanto passare a considerarel’ipotesi di una diversa, più adeguata, modalità di“certificazione” applicabile a questo genere di si-stemi. Il modello metodologico che proponiamoè elaborato a partire da esperienze concrete ma-turate presso gli Ospedali riuniti di Bergamo.

pagine a cura diPierMauro Sala

Ospedali Riuniti di Bergamo - Direttivo AisisAntonio Fumagalli

Ospedali Riuniti di BergamoPaolo Salvaneschi

Salvaneschi&Partners e Università di Bergamo

servono certificazioni adatte alle caratteristiche● Dipartimento onco-ematologico:

24 medici, 70 infermieri (oncologiamedica, ematologia, Dh onco-ema-tologico)

● Ortopedia e Traumatologia: 20 me-dici, 50 infermieri

● Dipartimento Chirurgico: 50 chirur-ghi/anestesisti, 72 infermieri (chirur-gia I e III, maxillo-facciale, plastica,senologica, toracica, anestesia I)

● Dermatologia: 6 medici, 5 inferm.ri

● Pneumologia: 15 medici, 18 infer.● Neurologia (degenza e Dh): 13 me-

dici, 37 infermieri

● Pediatria: 14 medici, 41 infermieri

● Cardiochirurgia: 13 medici, 37 infer-mieri

● Ginecologia: 13 medici, 38 infermie-ri

● Ostetricia e sala parto: 29 medici,86 infermieri e ostetriche

● Anestesia II: 15 anestesisti (So car-diochirurgia, ostetricia/ginecologia,ortopedia)

● Farmacia: 5 farmacisti, 3 borsisti,10 infermieri (laboratorio Umaca,laboratorio galenica, farmacoeco-nomia e logistica)

● Sistemi informativi: 2 ingegneri, 1responsabile formaz./avviamenti

● Pazienti distinti seguiti in FarmaSa-fe@: più di 8.000 da maggio 2006

possibilità di ridurre gli eventi critici

Ospedali Riuniti di Bergamo: situazione a gennaio 2008

15-21 aprile 2008 21TECNOLOGIE