1. 20 TECNOLOGIE 15-21 aprile 2008
Per i programmi utilizzati nell’assistenza sanitaria sono insufficienti le marcature Ce ma
Ict: meno rischi clinici con un
L’esperienza condotta agli Ospedali Riuniti di Bergamo ha dimostrato la
L
a procedura per la certificazione
del software è stata messa a punto,
inizialmente, a partire dall’espe-
rienza maturata con la messa in produzio-
I l proposito di questo articolo è aprire un dibatti-
to sull’adozione di una condivisa metodologia di
analisi del rischio e di una adeguata certificazione
to tecnologico è un «dispositivo medico» se il pro-
duttore dichiara che tale è la sua destinazione
d’uso, e opera di conseguenza per ottenere la rela-
per i quali le pur rigorose previsioni di certificazio-
ne “Ce” sono insufficienti, e che richiedono invece
di pensare a modalità di “certificazione” più ade-
ne di un sistema informatizzato di gestio- di qualità, per i prodotti software da utilizzare tiva certificazione, secondo le modalità previste guate alle caratteristiche loro proprie.
ne della Terapia farmacologica e, successi- nella pratica clinica. Va premesso che la riflessione dalle norme. Ne consegue che nessun medico ac- Possiamo definire queste caratteristiche in rap-
vamente, con la sua applicazione ad altri nasce da esperienze operative svolte “sul campo”, cetterebbe di utilizzare un ecografo o una Tac porto a quelle più comuni di un generico dispositi-
ambiti critici (procedura di richiesta da con l’impiego di strumenti software dedicati alla sprovvisti del “bollino Ce”, mentre lo stesso medi- vo medico. Di quest’ultimo, a esempio, si può so-
reparto degli emocomponenti). specifica attività di medici e infermieri. co probabilmente non si è mai posto la questione stenere che: è sottoposto a certificazione e a tara-
La prima esperienza riguarda un siste- La tipologia di software di cui stiamo parlando è di un’analoga certificazione per gli strumenti sof- tura; è “sigillato”; è brevettato (è un sistema pro-
ma informatizzato per la gestione della ancor oggi relativamente poco diffusa nelle corsie tware. prietario); è un prodotto di (piccola/media) serie;
terapia farmacologica per i pazienti ricove- dei nostri ospedali, e conseguentemente il dibatti- La nuova normativa, paradossalmente, apre ha un utilizzo procedurale (protocolli - manuali di
rati, presso gli Ospedali riuniti di Bergamo to è da considerarsi ai suoi albori. uno scenario problematico per il sanitario, perché istruzione); è sostituibile, vale a dire può essere
a partire da maggio 2006 (v. tabella). Recentemente, tuttavia, è intervenuto un even- la sua applicazione acritica rischia, da un lato, di messo “off line”, oppure duplicato, oppure surro-
Dalla prima versione, nella quale erano to che pone all’ordine del giorno questo tema, vale rallentare l’evoluzione possibile degli strumenti sof- gato con altro strumento; infine, non prevede (di
presenti alcune funzioni base per l’oncolo- a dire la variazione della normativa comunitaria tware a supporto della pratica clinica e, dall’altro, norma) utilizzi simultanei da parte di una pluralità
gia e l’ematologia, si è passati a un siste- che include il “software” in quanto tale nelle cate- di indurre un falso senso di sicurezza - quasi che di operatori. Se ne può concludere che stiamo
ma correntemente utilizzato in circa 25 gorie di oggetti definiti «dispositivi medici». Chiun- bastasse l’apposizione di questo marchio in un an- parlando di oggetti che sono realizzati e utilizzati
realtà mediche differenti. L’aumento delle que abbia un po’ di dimestichezza con le apparec- golo dello schermo di un computer a garantire la come “scatole nere”, e nei quali tutti gli sforzi di
funzioni e della complessità del processo chiature sanitarie, avrà sentito parlare della sicurezza di una procedura clinica. progettazione sono rivolti a predefinire le modali-
operativo che il sistema gestisce, ha porta- “marcatura Ce”, obbligatoria appunto per gli og- La tesi di questo articolo è che - in ambito tà di interazione con l’essere umano e con altre
to alla necessità di un controllo sulla sua getti qualificati come «dispositivi medici». In termi- ospedaliero - abbiamo a che fare con “sistemi” componenti tecnologiche.
sicurezza e affidabilità, considerando che ni molto semplificati, possiamo dire che un ogget- organizzativi e informativi di elevata complessità, Al contrario un software gestionale o di proces-
le azioni e gli elementi su cui si lavora
sono collegati alla salute del paziente.
Nel 2007 si è proceduto a un test estensi- ta a evoluzione nel tempo. L’applicazione in licenza da un produttore. In questo caso “funzionale” e cioè prove di funzionamen- ● l’insieme dei vincoli che sono imposti
vo del sistema per individuarne eventuali può essere modificata e adattata a nuove il sistema è composto dal software e dai to per le quali la singola funzione (non allo svolgersi dei processi (a esempio una
difetti, anomalie e problemi che lo strumen- regole organizzative ed esigenze, o inter- dati di configurazione ed entrambi devono l’intero programma che ha effetti sistemici terapia “protocollata” può essere in stati
to, se non correttamente pensato e utilizza- facciata con altre applicazioni, o modifica- essere considerati in un processo unitario che vanno considerati per se stessi) è una diversi: prescritta, in corso, sospesa, termi-
to, può causare al paziente. Gli elementi su ta funzionalmente, a esempio adattandone di gestione. L’interazione tra persone e “scatola nera” che riceve dati di ingresso e nata, e il passaggio da uno all’altro è sog-
cui è stato sviluppato il lavoro sono i docu- i parametri di configurazione. Questa evo- sistema, infine, mette in evidenza elementi comandi e produce risultati, senza che chi getto a regole aziendali e operative).
menti di specifica redatti in azienda a segui- luzione può portare a delle variazioni nel- problematici: dall’analisi formale (Fmea) esegue il test conosca la struttura interna La verifica di aspetti diversi attraverso
to delle interviste sul campo con i futuri l’affidabilità e nella sicurezza d’uso e ren- si ricavano indicazioni su dove sia meglio del software. Questo modo di operare è un piano di test è importante poiché ogni
utenti e utilizzati dopo per lo sviluppo del dere non più significative le pur rigorose inserire controlli e ausili all’operatività adeguato dal punto di vista di un utilizzato- gruppo di test legato a un aspetto, può
software e i documenti operativi prodotti verifiche effettuate “in laboratorio”, prima umana (messaggi di avvertimento; blocchi re del software, e parte dal presupposto rilevare malfunzionamenti generati da di-
durante l’avviamento e del suo effettivo utilizzo all’esecuzione di procedure non corrette). che lo sviluppatore ab- verse cause. A esempio,
l’utilizzo quotidiano del “in produzione”. È quin- Preliminarmente tuttavia, l’obiettivo è bia già esaurito tutte le la verifica di ogni singo-
sistema. di di essenziale impor- raggiungere una ragionevole garanzia sul- altre modalità di prova la funzione può eviden-
Per approssimazioni
e revisioni successive,
I malfunzionamenti tanza che il processo di
gestione dell’applicazio-
la “qualità” del prodotto. In particolare,
consideriamo due specifici aspetti: l’affida-
che considerano invece
la struttura interna dei
Tre aspetti su cui ziare problemi dovuti a
un carente controllo dei
utilizzando sia metodolo- generano gli errori ne sia accuratamente bilità (la proprietà di comportarsi come programmi. fare le verifiche dati di ingresso attraver-
gie consolidate nel cam- specificato e posto sotto specificato, senza malfunzionamenti) e la Lo sviluppo di un pia- so le maschere, mentre
po del “software engine- controllo. Si pensi a sicurezza d’uso (la proprietà di non mani- no di prove richiede la la verifica dei processi
ering”, sia approcci inno- esempio alla seguente se- festare comportamenti che possano contri- definizione di una strate- può rilevare problemi di
vativi più avanti descritti, sono stati realiz- quenza di eventi: è identificato un malfun- buire a causare danni ai pazienti). Ricordia- gia adeguata. Il software deve essere verifi- interazione delle funzioni attraverso i dati
zati ed eseguiti circa 2.900 casi di prova. zionamento, il software è corretto ed è mo che le due caratteristiche sono diverse cato da più punti di vista diversi che devo- dalla base dati o problemi dovuti a carenze
Poi il sistema è stato perfezionato nei pun- generata una nuova versione, per errore è e richiedono modi diversi per dare una no essere testati separatamente. Identifi- di specifica.
ti individuati dal test. Nel corso dei lavori messa in produzione la versione preceden- ragionevole garanzia che il prodotto le chiamo almeno i seguenti tre punti vista: In particolare sarà opportuno modellare
è apparsa sempre più evidente la necessità te, oppure il personale non è correttamente possieda. Un prodotto software potrebbe ● l’insieme delle funzioni elementari, i processi utente e gli insiemi di vincoli,
di considerare due diversi aspetti del per- informato e non utilizza la funzionalità essere molto affidabile, manifestando un ognuna delle quali può essere eseguita da con strumenti linguistici più rigorosi del
corso di certificazione: considerare l’affi- rilasciata. Ogni modifica deve perciò esse- numero molto basso di malfunzionamenti un utilizzatore. In questi sistemi ogni fun- linguaggio naturale, perché sia possibile
dabilità del prodotto, legata a tutte le fun- re autorizzata, gestita e tracciata, il rilascio durante un lungo periodo d’esercizio, ma zione è costituita da una o più maschere applicare tecniche sistematiche, note da
zionalità messe a disposizione dal prodot- in produzione di una nuova versione deve potrebbe causare gravi danni al paziente che permettono di interagire con una base letteratura, per generare i casi di test.
to software, ma anche condurre un’analisi essere controllato e per ogni modifica de- per quei rari malfunzionamenti. Ricordia- di dati; L’elenco delle funzioni (con le associa-
di rischio legata all’utilizzo dello strumen- ve essere riconsiderata la valutazione di mo anche che queste due caratteristiche ● l’insieme dei processi utente. Ogni pro- te specifiche), i modelli dei processi e i
to. Questo secondo aspetto pone il proble- sicurezza d’uso al fine di decidere se è non esauriscono l’insieme delle possibili cesso (a esempio di prescrizione, prepara- modelli degli insiemi di vincoli, sono la
ma se un insieme di funzioni separate ma necessario rivederla o estenderla. Si noti “qualità” di un prodotto software. Non zione e somministrazione di un ciclo di base per applicare le tecniche più adeguate
tra loro collegate nel processo operativo che questo processo deve definire con pre- consideriamo a esempio l’usabilità e cioè terapia protocollata in un sistema software allo stato dell’arte per produrre i casi di
possono originare, da un problema di una, cisione tutti i componenti che vanno messi la facilità d’uso del software. che gestisce la prescrizione e somministra- prova. L’attività di test fornirà un rapporto
effetti critici sul percorso completo di tera- sotto controllo, sia tecnologici che organiz- Si può dare una ragionevole garanzia zione dei farmaci) è costituito da un flusso finale che include la descrizione della stra-
pia per il paziente. zativi. Un esempio significativo è la pre- sull’affidabilità del prodotto, progettando di attivazioni di più funzioni elementari da tegia e delle tecniche adottate, l’elenco dei
Aspetti metodologici. Il metodo che senza di dati attraverso i quali è possibile e realizzando un adeguato insieme di casi uno o più utenti (medico, farmacista e casi di prova, l’esito di ogni caso e la
abbiamo seguito per condurre le attività di configurare un prodotto software acquisito di test. Considereremo casi di test di tipo infermiere in questo caso); documentazione che certifica l’esito.
verifica e analisi sopra descritte tiene con- È noto che non è possibile per un siste-
to degli aspetti di contesto in cui ci si Esempio di tappe dell’analisi del rischio ma software complesso, dimostrare la cor-
pone: l’utente è un acquirente e utilizzato- rettezza e cioè l’aderenza alle sue specifi-
re di software per uso clinico, tipicamente che. È invece possibile produrre un rappor-
un ente ospedaliero; il software può essere to di test che porti a una “ragionevole
stato sviluppato ad hoc per l’ente oppure fiducia” nell’utilizzo, basato su un approc-
può essere un prodotto acquisito in licenza cio robusto, ben fondato scientificamente
d’uso; il prodotto acquisito può anche esse- e difendibile allo stato dell’arte davanti a
re estensivamente parametrizzato in modo una commissione di esperti. Egualmente
che il suo comportamento reale, una volta importante è la valutazione di un software
installato, non dipenderà solamente dal clinico per quanto riguarda la sua
programma, ma anche dallo stato dei para- “sicurezza d’uso” (o, se vogliamo utilizza-
metri di configurazione. re il termine anglosassone, “safety”, da
Conseguentemente il metodo si compo- non confondere con la “sicurezza” nel sen-
ne di tre approcci differenziati per livello: so di privatezza, a esempio dei dati). Nella
il livello dell’interazione sistemica (Fmea; classe dei sistemi informativi utilizzati per
modalità di rilascio e attivazione del pro- applicazioni cliniche, un ruolo importante
dotto); il livello dell’analisi funzionale per la sicurezza d’uso è svolto dai dati. È
(eseguito in condizioni “di laboratorio”); il infatti possibile che una condizione rischio-
livello della “safety” (eseguito in condizio- sa possa essere causata non solo da un
ni che simulano l’operatività). malfunzionamento del programma (un
Il primo aspetto metodologico è di fon- programma calcola in modo erroneo un
damentale importanza. Un’applicazione dosaggio) ma anche da una configurazio-
software per uso clinico è parte di un ne errata dei dati (un programma copia
sistema informativo più ampio ed è sogget- correttamente da un’altra base dati nella

2. 15-21 aprile 2008 TECNOLOGIE 21
servono certificazioni adatte alle caratteristiche Ospedali Riuniti di Bergamo: situazione a gennaio 2008
● Dipartimento onco-ematologico: ● Pneumologia: 15 medici, 18 infer. ● Anestesia II: 15 anestesisti (So car-
24 medici, 70 infermieri (oncologia diochirurgia, ostetricia/ginecologia,
● Neurologia (degenza e Dh): 13 me- ortopedia)
medica, ematologia, Dh onco-ema-
software sicuro
dici, 37 infermieri
tologico) ● Farmacia: 5 farmacisti, 3 borsisti,
Ortopedia e Traumatologia: 20 me- ● Pediatria: 14 medici, 41 infermieri
● 10 infermieri (laboratorio Umaca,
dici, 50 infermieri ● Cardiochirurgia: 13 medici, 37 infer- laboratorio galenica, farmacoeco-
● Dipartimento Chirurgico: 50 chirur- mieri nomia e logistica)
ghi/anestesisti, 72 infermieri (chirur- ● Ginecologia: 13 medici, 38 infermie- ● Sistemi informativi: 2 ingegneri, 1
gia I e III, maxillo-facciale, plastica, ri responsabile formaz./avviamenti
possibilità di ridurre gli eventi critici ●
senologica, toracica, anestesia I)
Dermatologia: 6 medici, 5 inferm.ri
● Ostetricia e sala parto: 29 medici,
86 infermieri e ostetriche
● Pazienti distinti seguiti in FarmaSa-
fe@: più di 8.000 da maggio 2006
strare la possibilità che dei malfunziona-
so è, per sua natura, uno strumento collaborativo scrizione e somministrazione di farmaci e di emo- rare “dispositivo medico” e porre di conseguenza menti identificati nel prodotto software o
che si propone di ricordare, ordinare, sistematiz- componenti); di gestione di protocolli di cura. Dal ferrei limiti al suo utilizzo e alla sua evoluzione, un anche dei funzionamenti corretti ma peri-
zare, semplificare, tenere traccia di tutte le azioni punto di vista tecnologico possono valere le se- prodotto che ha nella necessità di adattamento colosi (a esempio l’input poco controllato
generate dalla cooperazione tra esseri umani, fina- guenti caratteristiche: l’architettura software è co- costante uno dei suoi principali requisiti funziona- di dati critici) contribuiscano a generare
lizzata a un obiettivo complesso, come può essere stituita da una base di dati centrale e da una li? Non parliamo infatti di sistemi chiusi ma di l’evento critico.
assicurare la cura ai degenti di un reparto ospeda- collezione di funzioni che operano sulla stessa; le sistemi “aperti”, cioè modificabili in qualsiasi mo- I risultati dell’analisi permettono di for-
liero. Bisogna pertanto prendere atto che questa funzioni non sono soltanto utilizzate per memoriz- mento, e perciò soggetti a possibili condizioni di nire suggerimenti per la modifica del sof-
tipologia di “oggetti” basa la propria efficacia non zare dati ed eseguire interrogazioni, ma anche utilizzo non definibili e completamente prevedibili tware e la riduzione del rischio. Si ribadi-
già sulla “chiusura”, ma sull’apertura e adattabili- per processi aziendali; i processi sono vincolati da a priori. Bisogna pertanto passare a considerare sce infine che la sicurezza d’uso è una
tà al mutevole agire dell’essere umano all’interno regole aziendali che tipicamente riguardano possi- l’ipotesi di una diversa, più adeguata, modalità di proprietà di sistema.
di una organizzazione. bili evoluzioni dello “stato” di entità descritte nel- “certificazione” applicabile a questo genere di si- L’evento critico dipenderà da un insie-
Per proseguire nell’analisi, è necessario a que- la base dati; specifici dati scorretti o specifici mal- stemi. Il modello metodologico che proponiamo me di fattori che, in generale coinvolgono
sto punto definire con una certa precisione, dal funzionamenti del software possono causare pro- è elaborato a partire da esperienze concrete ma- il software ma anche macchinari, persone
punto di vista funzionale e dal punto di vista tecno- blemi di “sicurezza d’uso” (causare danni alla salu- turate presso gli Ospedali riuniti di Bergamo. e organizzazione.
logico, la categoria di oggetti dei quali stiamo trat- te dei pazienti). Anche l’analisi di sicurezza d’uso rila-
tando, e solo successivamente portare il dibattito Per condivisa ammissione, tale categoria di pro- pagine a cura di scia un rapporto finale che descrive meto-
sulle modalità di “certificazione”. dotti software non è “certificabile” attraverso pro- PierMauro Sala di e risultati e fornisce ragionevole e difen-
Possono rientrare con vari livelli di appropria- cedure di collaudo. Cosa è necessario fare pertan- Ospedali Riuniti di Bergamo - Direttivo Aisis dibile evidenza a supporto dell’utilizzo si-
tezza nella categoria dei software di rilievo clinico, to, per garantirne l’affidabilità e, al contempo, la Antonio Fumagalli curo del prodotto.
i sistemi di automazione di processi diagnostici sicurezza d’uso? In primo luogo, va affrontato, con Ospedali Riuniti di Bergamo Conclusione. Il processo di “cer-
(laboratorio-radiologia); di refertazione assistita; i estrema cautela, il problema della “destinazione Paolo Salvaneschi tificazione”, o di reale contenimento del
software di gestione di processi terapeutici (pre- d’uso”. Che utilità pratica può avere, infatti, dichia- Salvaneschi&Partners e Università di Bergamo rischio clinico, per questi prodotti, deve
essere continuo e coinvolgere tecnologia,
comportamenti personali e organizzazio-
propria base dati, dati anagrafici che zione di “eventi critici” pericolosi per la tificati gli insiemi di dati (definiti “dati ● in generale esiste un numero limitato di ne.
possono identificare erroneamente un pa- salute del paziente. Un esempio di evento critici” come i dati anagrafici del paziente) funzioni software coinvolte. Per ognuna di Stiamo infatti parlando della necessità
ziente). critico può essere: «Viene associata al pa- nella base dati dell’applicazione che posso- esse sono considerati i test realizzati per di indagare una proprietà concreta ed
La sicurezza va verificata anche duran- ziente una somministrazione relativa a un no costituire, se alimentati erroneamente, verificare l’affidabilità ed eventuali altri emergente dei sistemi, che definiamo
te il processo di sviluppo del software, ma altro paziente». condizioni che contribuiscono a un evento test specifici al fine di produrre evidenza “safety”, che si realizza solo con l’apporto
secondo il punto di vista dell’utente finale Il metodo applica un’analisi di rischio critico; che sia possibile attivare gli eventi model- efficace e integrato di tutti gli attori: in
e quindi le verifiche che si concentrano al caso di un prodotto software che ha ● per ogni condizione così identificata è lati. primo luogo le persone. Poi hardware,
sulle possibili interazioni tra le funzionali- come componente una base di dati ed è modellato il grafo dei possibili eventi cau- Le prove effettuate non arrivano a di- software, dati, conoscenza, procedure or-
tà disponibili. I criteri per la valutazione di composto dai seguenti passi: sati da funzioni software che possono ge- mostrare l’impossibilità di raggiungere ganizzative e - in certi casi - anche
sicurezza d’uso sono basati sull’identifica- ● sono classificati gli eventi critici e iden- nerare la condizione; l’evento critico, ma sono in grado di dimo- “dispositivi medici”.