AIIC
associazione
italiana
ingegneri clinici
I Quaderni dell’AIIC
IL SOFTWARE E LE RETI
IT-MEDICALI
NEL CONTESTO SANITARIO
Appunti del Corso N. 2 del XIV Congresso Nazionale AIIC
VENEZIA - anno 2014 - Vol 2
SOMMARIO
Prefazione ......................................................................4
CAPITOLO 1
Premessa...................................................5
CAPITOLO 2
Dispositivi medici e DM software....... 6
CAPITOLO 3 Le reti IT Medicali: panoramica dei principi della
norma IEC 80001-1..................................................................8
CAPITOLO 4 Le reti IT Medicali: un caso reale di riprogettazione
alla luce dei principi della norma IEC 80001-1.........10
CAPITOLO 5 Le reti IT-Medicali: aspetti tecnici legati alla
riprogettazione del networking di alla luce dei principi della
norma IEC 80001-1................................................................13
RACCOLTA SLIDES DEL CORSO......................................23
Bibliografia essenziale............................................72
I DOCENTI DEL CORSO......................................................73
GLI AUTORI
....................................................................73
Il Software e le Reti IT-Medicali
nel contesto Sanitario
AIIC
associazione
italiana
ingegneri clinici
PREFAZIONE
CAPITOLO 1
Premessa
E’ con estrema soddisfazione che mi accingo a presentarvi questo lavoro, risultato
tangibile della fortunata esperienza dei corsi di approfondimento che l’AIIC organizza in
occasione del suo Convegno Nazionale.
Questo “libretto” (così mi piace chiamarlo) è da intendersi come una vera e propria
dispensa che raccoglie, nella maniera più fedele possibile, i contenuti divulgati durante il
corso specifico cui è dedicato.
Non è e non può essere un’opera esaustiva ma piuttosto uno strumento rivolto a tutti
coloro, soci e non, che, interessati agli argomenti trattati, vogliano arricchire le proprie
conoscenze e, soprattutto, trovare spunti di approfondimento.
L’auspicio è che sia uno strumento semplicemente utile, gelosamente custodito nella
propria libreria. L’AIIC intende realizzare un libretto per ciascuno dei corsi realizzati,
dando vita ad una vera e propria Collana.
Il corso nasce dell’esigenza di porre l’attenzione sull’importanza sempre crescente
che i software utilizzati in ambiente sanitario stanno assumendo nel processo di cura
e dalla consapevolezza che, l’interconnessione delle apparecchiature elettromedicali
in reti IT medicali è da un lato una straordinaria opportunità per la salute pubblica, ma
dall’altro necessità di un controllo specifico. Una norma specifica sulla sicurezza delle
reti medicali redatta dal CEI sta per entrare in fase di revisione pubblica. Il riferimento
normativo internazionale più recente è rappresentato dalla norma IEC 80001-1 del
2010. Essa accresce fortemente la responsabilità̀ delle strutture utilizzatrici e la
responsabilizzazione delle strutture sanitarie nella gestione delle reti IT. In particolare
si introduce la figura dell’Organizzazione Responsabile (ente responsabile dell’uso e
della manutenzione della rete IT medicale) e si sollecita l’individuazione di specifico
personale qualificato per la gestione, l’esecuzione delle attività̀ operative e delle
attività̀ di valutazione delle tecnologie in questo ambito. Ne deriva che il ruolo
dell’ingegnere clinico necessariamente sarà quello di occuparsi di dispositivi medici
software e dell’IT in generale in collaborazione con responsabili informatici e direzioni
sanitarie al fine di garantire una corretta gestione delle tecnologie medicali e delle reti
telematiche sanitarie nell’analisi e valutazione del rischio associato.
Un forte e sentito ringraziamento a tutti coloro che mossi unicamente dalla comune
passione per la professione, hanno lavorato duramente e gratuitamente, alla realizzazione
del presente volume (libretto).
Il PRESIDENTE NAZIONALE AIIC
Ing. Lorenzo Leogrande
AIIC
associazione
italiana
ingegneri clinici
Il Software e le Reti IT-Medicali
nel contesto Sanitario
Il Software e le Reti IT-Medicali
nel contesto Sanitario
AIIC
associazione
italiana
ingegneri clinici
CAPITOLO 2
Dispositivi medici e DM software
Il primo riferimento legislativo cui far riferimento è rappresentato dalla direttiva
comunitaria 93/42/CE che stabilisce, oltre al concetto della libera commercializzazione
dei dispositivi medici (DM) tra gli stati membri, i criteri generali per la produzione e
la commercializzazione degli stessi nel mercato comunitario. Tali concetti generali
sono enunciati con l’obiettivo di garantire il fatto che i DM rispondano a dei requisiti
di base, che ne dovrebbero garantire un uso sicuro e almeno in parte l’efficacia.
Ai fabbricanti è richiesto di rispettare procedure stabilite nelle leggi stesse, mentre
norme tecniche specifiche stabiliscono il concetto della presunzione di conformità ad
alcuni dei requisiti essenziali. Il rispetto della norma tecnica garantisce il rispetto del
corrispondente requisito essenziale e tutela il produttore dal punto di vista legale. La
direttiva suddivide i DM in classi dalla I alla III anche sulla base del rischio corso dal
paziente in caso di errato funzionamento. Per ciascuna classe sono stabiliti criteri di
valutazione per determinare la conformità alle disposizione comunitarie quindi alla
possibilità di commercializzare il prodotto. Per la classe IIa un organismo notificato
deve certificare la fase di fabbricazione, le classi IIb e III richiedono l’intervento di un
ente certificatore anche per la fase progettuale.
La direttiva 2007/47/CE estende senza possibilità di dubbio e comunque su
dichiarazione del fabbricante il concetto di DM al software in sé, anche se stand-alone
(DM attivo). Per i dispositivi che incorporano un software è necessario prevedere la
sua convalida secondo lo stato dell’arte. Il concetto di convalida implica quello di
ciclo di vita dalla progettazione all’immissione in commercio, passando quindi dallo
sviluppo, la gestione dei rischi, la validazione e la verifica. Ciò assume particolare
rilevanza considerando il fatto che la fase progettuale è quasi totalmente assente per
i software. Il che determina mancata analisi dei rischi e gestione delle problematiche
che possono nascere dal cattivo funzionamento. Il seguente concetto è rilevante ai
fini della classificazione del software DM: “il software destinato a far funzionare un
dispositivo o ad influenzarne l’uso rientra automaticamente nella stessa classe del
dispositivo”.
AIIC
associazione
italiana
ingegneri clinici
Il Software e le Reti IT-Medicali
nel contesto Sanitario
La direttiva 2007/47 risulta spesso disattesa benché ovviamente recepita con D.Lgs
n.37 del 25 gennaio 2010. La situazione è comune a molti stati dell’Unione e pertanto
le autorità competenti nel 2012 hanno redatto delle apposite linee guida che intendono
facilitare la classificazione dei software utilizzati in ambiente sanitario, soprattutto se
stand alone. Volendo semplificare al massimo l’alterazione della rappresentazione
del dato clinico è il concetto base che stabilisce la possibilità che un software sia
o meno un DM. Quindi se il software si limita a archiviare il dato in un database
esso non è un DM. Inoltre l’alterazione del dato clinico deve essere direttamente a
beneficio di almeno un paziente, in caso contrario il software è utilizzato ad esempio
per analisi statistiche e in ogni caso non rappresenta un DM. In definitiva un software
è un DM se ha la possibilità di modificare dati clinici per fini medici come ad esempio
la diagnosi, il monitoraggio e la terapia. Qualora il software sia un accessorio di un
DM, cioè destinato dal fabbricante ad essere utilizzato per garantire la destinazione
d’uso del DM, non è esso stesso un DM, ma in ogni caso è applicabile ad esso
il concetto legale di messa in servizio secondo la direttiva 93/42. Pertanto deve
essere garantito il ciclo di progettazione necessario alla messa in commercio sul
mercato comunitario. Volendo fare un esempio un sistema di archiviazione delle
immagini radiografiche come i più comuni PACS non è un DM. Il sistema PACS-RIS
comunemente commercializzato rappresenta sicuramente un DM.
Particolare menzione infine merita la categoria dei cosiddetti software fatti in casa,
ovvero di quei software per i quali il produttore non ha previsto la messa in commercio
e la vendita a terzi. Questi prodotti non sono regolamentati dalle leggi derivanti dalle
direttive europee, ma ciascuno stato è chiamato in autonomia a regolamentare il
loro ambito di utilizzo definendo le responsabilità di ciascuno. In Italia manca una
legislazione specifica. Certamente prevedere gli stessi adempimenti relativi alla
messa in servizio per un DM o un accessorio tutela il produttore dal punto di vista
legale. In questo caso il produttore che potrebbe essere un’azienda ospedaliera che
decide di realizzare in autonomia la propria cartella clinica.
Il Software e le Reti IT-Medicali
nel contesto Sanitario
AIIC
associazione
italiana
ingegneri clinici
CAPITOLO 3
Le reti IT Medicali: panoramica dei principi della norma IEC 80001-1
La massiccia diffusione di apparecchiature elettromedicali dotate di interfaccia
di rete e la visione dei software come DM determinano la necessità di gestire
l’interazione tra le diverse realtà che costituiscono il patrimonio tecnologico di
un’azienda ospedaliera (AO). Inoltre l’interoperabilità deve essere garantita ed
efficace anche a livello delle diverse strutture tecniche che comunemente gestiscono
la rete informatica e le apparecchiature elettromedicali: il centro elaborazione dati
e l’ingegneria clinica. Con tale ottica nasce nel 2010 la norma IEC 80001 che, pur
non essendo strettamente tecnica, applica dei concetti di base, già propri del risk
management, alle reti informatiche medicali e prova a fare luce sulle zone d’ombra
rappresentate dalla sovrapposizione di competenze tra area informatica e di gestione
delle apparecchiature biomedicali.
Le peculiarità che contraddistinguono le reti dati di una AO sono almeno le seguenti:
− in rete si hanno DM che hanno caratteristiche e normative di riferimento non
confrontabili con altri dispositivi
− i dati personali e sensibili in ambito sanitario sono gestiti con leggi specifiche
questo determina il fatto che il controllo del rischio non è semplicemente garantire un
uso sicuro ed efficace, ma anche privacy e data and system security cioè sicurezza
informatica. La norma IEC 80001 definisce quindi i ruoli, le responsabilità e le
azioni necessari a garantire la gestione del rischio per le reti IT Medicali (reti IT
che incorporano almeno un DM) così da garantire SAFETY, EFFECTIVENESS e
DATA AND SYSTEM SECURITY (Figura 1). Il concetto di safety è quello classico
di sicurezza per il paziente, per le persone e l’ambiente. L’effectiveness va intesa
come l’efficienza che deve perseguire un’organizzazione responsabile per il bene
del paziente e della struttura sanitaria. Infine il data and system security lo stato
operativo di una rete medicale in cui le attività di informazione (dati e sistemi) sono
ragionevolmente protetti dalla perdita di riservatezza, integrità e disponibilità.
AIIC
associazione
italiana
ingegneri clinici
Il Software e le Reti IT-Medicali
nel contesto Sanitario
Figura 1: La norma IEC 80001 - responsabilità e azioni necessari a garantire la gestione del
rischio per le reti IT Medicali
Passiamo ora ad esaminare i principali concetti espressi dalla norma IEC 80001. La
valutazione del rischio deve essere effettuata prima che un DM venga introdotto nella
rete IT medicale e per ogni cambiamento introdotto nel network così da approntare
le misure necessarie ad evitare rischi inaccettabili per il paziente. Il risk manager è
la figura espressamente dedicata a garantire il controllo del rischio per la rete ITMedicale. La sua azione si concretizza soprattutto attraverso la pianificazione degli
interventi di inserimento di nuovi DM nel network riconsiderando di volta in volta la
matrice del rischio. E’ inoltre raccomandato il fatto di revisionare periodicamente le
autorizzazioni di accesso ai DM attribuite ai diversi utenti del network e la stessa
possibilità di cambiamenti nella matrice di gestione del rischio creando di fatto un
processo iterativo di miglioramento. La norma esplicita anche il fatto che dovrebbe
essere prodotta una apposita documentazione contenente tutte le istruzioni
riguardanti:
− le procedure di inserimento di DM nella rete IT-medicale
− le modalità di trasferimento dati dei DM attraverso la rete
− le caratteristiche di base dei DM che l’utente abilitato dovrebbe conoscere
per utilizzare al meglio e responsabilmente il dispositivo
Il Software e le Reti IT-Medicali
nel contesto Sanitario
AIIC
associazione
italiana
ingegneri clinici
La documentazione dovrebbe anche informare gli utilizzatori dei rischi derivanti da
condizioni di guasto del network e dell’uso improprio della connessione alla rete o
delle informazioni trasmesse su di essa.
Secondo la 80001 le direzioni delle diverse strutture sanitarie devono individuare
e nominare, sulla base di specifiche conoscenze, qualifiche e competenze, un risk
manager per la rete IT-Medicale. Le stesse direzioni hanno anche la responsabilità
di fornire le politiche di gestione della rete e adeguate risorse economiche e tecniche
per un’adeguata gestione. Oltre a queste indicazioni generali definite sin dal 2010, a
partire dal 2012 sono stati rilasciati, e altri sono verranno pubblicati, dei report tecnici
di applicazione pratica del risk management alle reti medicali.
CAPITOLO 4
Le reti IT Medicali: un caso reale di riprogettazione alla luce dei
principi della norma IEC 80001-1
Passiamo ora ad analizzare un caso di applicazione concreta dei concetti espressi dalla
IEC 80001-1. Si tratta della riprogettazione della rete IT-medicale dell’AOU di Trieste
“Ospedali Riuniti”. L’AOU è costituita da tre diverse AO distribuiti in almeno 10 diversi
edifici, 760 posti letto e più di 3000 dipendenti. Dal punto di vista informatico si hanno
3000 host da collegare in rete e 3500 utenti. I tre diversi presidi condividono la stessa
rete dati, pertanto i titolari del trattamento dati sono tre, ma è necessario garantire
una netta separazione del traffico di rete afferente a differenti titolari di trattamento.
In definitiva la situazione è particolarmente complessa poiché a tre differenti policy
e infrastrutture logiche distinti corrisponde un’unica infrastruttura di rete fisica. La
riprogettazione dell’architettura di networking alla luce dei principi espressi dalla IEC
80001 ha quindi impattato su una situazione di base caratterizzata da un elevato
grado di complessità. Ovviamente concetti cardine della riorganizzazione sono stati
quelli di SAFETY, EFFECTIVENESS e DATA AND SYSTEM SECURITY descritti in
precedenza.
AIIC
associazione
italiana
ingegneri clinici
Il Software e le Reti IT-Medicali
nel contesto Sanitario
La sicurezza è ovviamente quella del paziente, degli operatori e del patrimonio. Da
riconsiderare prima di tutto la sicurezza elettrica partendo dal quadro normativo
di riferimento, ma raggiungendo un livello di specificità superiore. La domanda
chiave è la seguente: il fabbricante ha previsto esplicitamente (quindi anche nella
documentazione che accompagna il device) la possibilità di connessione di rete?
Anche durante l’uso sul paziente? Se la connessione non è prevista in questo caso
si applicano le limitazioni indicate dal fabbricante (eventualmente si richiedono
specifiche ulteriori). Nel caso non sia in alcun caso prevista l’Organizzazione
Responsabile ha l’onere di effettuare l’analisi del rischio relativa ad eventuale
assemblaggio/modifica del sistema elettromedicale prendendo in considerazione
aspetti quali: la connessione dati implica una modifica del sistema EM dal punto
di vista elettrico? Tale modifica è temporanea o permanente? E’ possibile utilizzare
dispositivi di separazione galvanica? Per rischi legati a guasti e errate configurazione
degli interfacciamenti alla rete o per i rischi derivanti da interazioni non controllate
tra i DM inseriti in una rete IT-Medicale e internet vanno presi in considerazione i
concetti di effectiveness, ad esempio su qualità e tipologia degli interfacciamenti su
cui effettuare valutazione del rischio, e data and system security, per la valutazione
del rischio corso da interazioni con malaware.
Per effectiveness si deve intendere soprattutto la capacità di raggiungere il
risultato atteso per il paziente e l’Organizzazione Responsabile. Vengono quindi
presi in considerazione aspetti di integrazione, interfacciamento e interoperabilità
con l’infrastruttura IT per realizzare, in maniera sicura ed efficace, il flusso dati
informatizzato a partire dal DM/ software DM in rete. Queste considerazioni rendono
possibile anche l’ottenimento della business continuity e della sicurezza del dato. Per
l’ottenimento della qualità del sistema di trasmissione dell’informazione, che è bene
ricordare essere rappresentata da un dato clinico, è raccomandato far riferimento
agli standard di comunicazione e descrizione dei dati, i ben noti DICOM e HL7 per
esempio, e l’adozione di quelle che sono note come “best practice” internazionali,
come l’iniziativa IHE. Ulteriori strumenti che, se correttamente utilizzati, garantiscono
la qualità dell’informazione al fine della valutazione clinica sono fondamentalmente
strumenti informatici e strumenti normativi. Nella prima categoria rientrano la firma
digitale e un sistema di conservazione sostitutiva dei documenti.
Il Software e le Reti IT-Medicali
nel contesto Sanitario
AIIC
associazione
italiana
ingegneri clinici
Strumenti che usati in combinazione garantiscono il clinico che il dato, opportunamente
siglato e conservato, è consultabile in maniera appropriata. Lo strumento normativo
indispensabile, come per ogni DM, è indubbiamente la marcatura CE. Essa da sola
garantisce il clinico del fatto che il dato fornito dal software DM è sicuro.
Tutto quanto è stato preso in considerazione relativamente al concetto di data and
system security può essere così riassunto: è indispensabile garantire agli operatori
sanitari non solo le risorse informatiche necessarie al trasferimento dell’informazione,
ma anche che l’informazione sia fornita al momento giusto al terminale giusto e a chi
ha la competenza, quindi l’abilitazione giusta a poterla ricevere. In definitiva devono
essere contemporaneamente garantiti: riservatezza, integrità e disponibilità delle
risorse IT e delle informazioni. La riservatezza va intesa come l’insieme di regole che
limitano l’accesso delle risorse informatiche e delle informazioni, alle sole persone
autorizzate. L’integrità delle risorse e dell’informazione coincide con l’esattezza e la
completezza delle stesse, l’utilizzatore deve avere la garanzia del fatto che il dato non
sia stato modificato da un utente non autorizzato, ma anche del fatto che le modifiche
apportate siano riconducibili univocamente al suo autore (evidentemente autorizzato
ad apportarle). La firma elettronica quindi lega la modifica al suo autore, il file di
log traccia le azioni condotte sul dato. L’azione combinata di questi due strumenti
informatici determina la paternità delle azioni sul dato clinico. La disponibilità è quella
della risorsa informatica o dell’informazione stessa teoricamente anche h24 e sempre
nella modalità corretta ( strumenti adeguati e luogo giusto); la business continuity e il
disaster recovery rientrano in quest’ambito.
AIIC
associazione
italiana
ingegneri clinici
Il Software e le Reti IT-Medicali
nel contesto Sanitario
CAPITOLO 5
Le reti IT-Medicali: aspetti tecnici legati alla riprogettazione del
networking di alla luce dei principi della norma IEC 80001-1
Abbiamo quindi definito che gli obiettivi generali di progettazione di una rete ITMedicale sono quelli di controllare la rete nel senso di limitare la visibilità solo a ciò che
è necessario, ovvero isolare gli oggetti insicuri ed impedire la visibilità indiscriminata
delle risorse e al tempo stesso limitare le comunicazioni solo alle destinazioni
necessarie, ovvero disciplinare il traffico ed impedire l’accesso indiscriminato
alle risorse. E’ indispensabile poi garantire la disponibilità di dati e servizi anche
attraverso la ridondanza fisica e funzionale degli apparati e dei sistemi. Infine è da
considerare la condizione quasi esclusiva: i maggiori pericoli per una rete dati di una
AO provengono dal suo interno. Proviamo dunque a presentare una descrizione degli
strumenti tecnici che ha a disposizione il network engineer per ottenere tali obiettivi.
Cominciamo definendo il fatto che gli elementi di una rete dati appartengono a due
macro categorie: passivi e attivi. Il cablaggio strutturato i cavedi, le canalizzazioni
gli armadi di raccolta server sono evidentemente elementi passivi. Gli stessi locali e
vani tecnici, come ad esempio quelli che ospitano gli armadi, sono elementi passivi.
Per essi è necessario prevedere alcune caratteristiche impiantistiche di base:
antintrusione, antincendio, condizionamento, alimentazione elettrica continuativa e
aspetti di efficientamento energetico e logistico. Sono attivi gli elementi quali hub,
switch, router, gli access point alla rete wi-fi. Sono attivi i server, sia che eroghino o
usufruiscano di servizi (client), e alcuni elementi di protezione quali i firewall e i proxy. Il
compito del network engineer è quello di combinare questi elementi in un’architettura
di rete, che per essere realmente efficace, deve risultare modulare e strettamente
gerarchica. L’architettura di riferimento per una rete interna da una AO è ovviamente
quella LAN (Local Area Network) in cui sono da mettere in comunicazione edifici,
piani/aree/zone tutti distribuiti all’interno di un campus più o meno vasto. In una LAN
è possibile distinguere due diverse architetture:
-
Core---Distribution---Access
-
Core---Access
Il Software e le Reti IT-Medicali
nel contesto Sanitario
AIIC
associazione
italiana
ingegneri clinici
Di solito è sempre verificata la corrispondenza tra separazione fisica determinata
dalla realtà costruttiva e tra la separazione della rete in parti dette sub-net. Si
verificano dunque due condizioni: semplice condizione di switching all’interno degli
edifici (Layer2) oppure routing tra gli edifici (Layer3). Il sussistere di una o dell’altra
condizione è dipendente dalla grandezza del network. Per le reti più grandi si avrà
routing anche all’interno degli edifici, per le reti piccole sarà sufficiente lo switching
tra i diversi edifici. È bene considerare il fatto che uno switch può andare oltre la
semplice funzione di memorizzazione dei nodi cui inviare informazioni (attraverso
una tabella di trasmissione basata su indirizzi MAC) e di successivo smistamento
forzato alla porta presso la quale il nodo è localizzato. Esso infatti può anche
realizzare una trasmissione diretta e “consapevole” di pacchetti di informazione in
alcune condizioni particolari. Ciò accade quando l’indirizzo di destinazione non è
trovato nella tabella di trasmissione, in questo caso si genera un traffico di tipo uno a
tutti che può coinvolgere però solo un numero limitato di host. Certamente lo switch
non controlla gli indirizzi IP, cosa fatta dal router. Pertanto lo switch sovraintende al
controllo delle collisioni ai singoli host, il router controllo indirizzamento tra sotto reti.
Una LAN “moderna” è una RETE Layer2 - Layer3: tutti gli host hanno un MAC ed un
indirizzoIP. Il confine tra traffico L2 (switching) e traffico L3 (routing) viene posto, in
fase di progettazione. Se ad una rete layer2 viene tolto il router, le comunicazioni non
sono possibili al di fuori di quella rete. Si arriva quindi alla condizione di disciplina/
isolamento. Approfondiamo questo concetto.
Una LAN di una realtà “complessa” quale quella di un’azienda sanitaria dà connettività
a host classificabili come HOST SICURI, ovvero gestisti, di cui l’organizzazione
responsabile è più (o meno) direttamente competente (amministratore di fatto e di
sostanza). Questi host sono sottoposti a politiche di sicurezza centralizzate, dotati
di software non end-of-life e aggiornati in continuo. Dotati di software antivirus
costantemente aggiornato. Gli HOST INSICURI, sono quelli di cui non è possibile
garantire nulla o parte di quanto appena descritto per gli host sicuri. Uno dei
principi della sicurezza informatica è la riduzione della superficie di attacco. Gli
host insicuri sono contemporaneamente fonte e oggetto di infezione e di attacco
e su di essi non è possibile agire. Quindi nell’ottica di riduzione della superfice di
attacco è necessario isolarli quindi impedire che possano fare traffico con host non
appartenenti al loro gruppo e disciplinarli cioè fare in modo che possano comunicare
solo il minimo indispensabile con host sicuri e solo per la tipologia di traffico ritenuta lecita.
AIIC
associazione
italiana
ingegneri clinici
Il Software e le Reti IT-Medicali
nel contesto Sanitario
Il principale strumento di isolamento è la creazione di VLAN (Virtual Lan) e il relativo
confinamento in esse degli host insicuri. Si tratta quindi di fare subnetting della propria
rete non solo sulla base della dimensione della rete stessa, bensì anche sulla base di
“criteri di compartimentazione verticale”:
− per ente/azienda
− per servizio
− per tipologia di traffico
− per dominio di competenza
− per specifici problemi di sicurezza
E’ possibile regolamentare il traffico per mezzo di ACL (Access Control List) e firewall
(FW) tenendo sempre in considerazione i principi di facilità di gestione ed efficienza.
Ogni azienda ha un suo indirizzamento IP (privato) che può gestire per organizzare la
propria LAN, o le proprie LAN se l’azienda consta di diversi presidi. E’ possibile quindi
dividere ogni rete in diverse subnet ognuna delle quali è messa in comunicazione
con le altre da un router. La ripartizioni in subnet non determina un aumento degli
host collegabili anzi l’operazione di subnetting rende necessario la perdita di indirizzi
che potrebbero essere dedicati agli host. Lo strumento di controllo della ripartizione
della rete in subnet è il protocollo DHCP (Dinamic Host Configuration Protocol). Esso
è il protocollo nato nel 1993 che consente di assegnare in modo dinamico, quindi
su precisa richiesta di accesso alla rete IP la configurazione necessaria per stabilire
una connessione e operare su una rete più ampia. L’adozione del DHCP scarica
il gestore di rete dall’oneroso compito di assegnare IP statici e consente una più
razionale, dinamica e controllabile gestione delle risorse informatiche a disposizione.
Oltre all’indirizzo IP il protocollo fornisce in automatico anche subnet mask, nome di
dominio DNS, indirizzi dei server DNS e altri parametri necessari all’indirizzamento
in rete. DHCP è pensato per assegnare IP: non entra nel merito di chi gli chiede l’IP,
quindi a monte vanno implementati meccanismi di autenticazione/autorizzazione di
accesso alla rete.
Il Software e le Reti IT-Medicali
nel contesto Sanitario
AIIC
associazione
italiana
ingegneri clinici
Ulteriore elemento di flessibilità è dato dalla creazione delle VLAN (Virtual LAN). Essa
è costituita da host che possono appartenere a differenti LAN fisiche e comunque
comunicare tra loro. La flessibilità deriva principalmente dal fatto che una VLAN è
configurabile esclusivamente via software senza cioè ricorrere a ulteriori connessioni
con cavi e dispositivi attivi. L’appartenenza di un host ad una VLAN può essere
definita secondo diversi criteri. Il metodo più diffuso e più semplice da implementare
prevede l’identificazione di una porta di uno switch che è configurata per appartenere
ad una sola VLAN. Tutti i pacchetti provenienti da quella porta saranno “taggati” con
l’identificativo univoco (VID) della sua VLAN, e su questa porta verranno inviati solo
pacchetti provenienti dalla sua VLAN. In questo modo lo switch deve guardare solo
da quale porta viene un pacchetto per attribuirgli un VID. Una porta di uno switch su
cui viaggiano pacchetti con il VLAN TAG è detta tagged o trunk port. Viceversa,
una su cui viaggiano pacchetti senza VLAN TAG è detta access port. Alcuni switch
accettano anche un traffico misto di pacchetti tagged e non tagged, e una porta
configurata in questo modo è detta hybrid port. La combinazione delle VLAN e
del protocollo DHCP consente la possibilità di avere sottoreti IP interne alle VLAN
create definendo di fatti una gestione centralizzata sicuramente meno onerosa di una
puntuale (Figura 2).
La centralizzazione deriva dal fatto che i punti di uscita delle VLAN sono i router
elementi sicuramente di facile controllo. Tornando quindi alla specificità dell’AOUTS
“Ospedali riuniti di Trieste” un piano di subnetting (indirizzamento privato IP) ha
determinato la creazione di tabella della subnet e tabella delle VLAN. Di seguito si
riportano i criteri di raggruppamento adottati.
– Host di diversi enti/aziende (disciplinati-isolati)
o UNITS
o ASS1
– Host AOUTS sicuri/in dominio (disciplinati)
o per servizio (server fisici, server virtuali, management, ILOM, ecc)
o per tipologia di traffico (PC aziendali, stampanti aziendali, telefoni VOIP)
– Host AOUTS insicuri/non in dominio (disciplinati-isolati)
o per tipologia di traffico
o per dominio di competenza (produttore e/o manutentore)
o per specifici problemi di sicurezza (raro)
o per servizio (raro)
Figura 2: VLAN
Creare una VLAN permette di isolare il traffico tra gli host ad essa appartenenti dal
resto della rete evitando di fatto visibilità ed accessibilità indesiderate tra la VLAN e
il resto della rete.
AIIC
associazione
italiana
ingegneri clinici
Il Software e le Reti IT-Medicali
nel contesto Sanitario
Le VLAN dunque sono isolate, gli host comunicano solo all’interno delle VLAN e
serve qualcosa che possa discriminare cosa può o meno uscire dalla VLAN.
L’esistenza della VLAN stessa garantisce che basta controllare cosa transita dal
gateway per avere il controllo di tutta la sottorete. Rimane da risolvere il problema
della comunicazione di host inseriti in VLAN con destinazioni esterne indispensabili
(datacenter aziendale e regionale, internet). Per ottenere questo obiettivo è bene
centralizzare i servizi in modo che il traffico vada sempre dalla periferia al centro e
non da periferia a periferia e far fluire solo il traffico necessario, nel nostro caso solo
il traffico necessario da e per una VLAN. Nello scenario di AOUTS, tutte le VLAN
citate terminano e vengono ruotate dal centro stella di campus (2 presidi ospedalieri
+ 5 altre sedi).
Il Software e le Reti IT-Medicali
nel contesto Sanitario
AIIC
associazione
italiana
ingegneri clinici
Esso, gateway di tutte le sottoreti, può definire come far comunicare l’una con l’altra.
In principio, con le ACL (Access Control List) logica “permetto solo il traffico lecito
e nego tutto il resto”; filtro per indirizzo IP sorgente e destinazione e per protocollo.
Successivamente, all’aumentare della complessità, per mezzo di firewall. Le ACL
sono liste di condizioni utilizzate per testare il traffico dati che prova ad oltrepassare
un’interfaccia router. In sostanza il router riceve delle ACL specifiche regole sulle
quali consentire o negare il passaggio di pacchetti di informazioni attraverso di esso.
In questo modo è consentito il controllo del traffico e l’accesso sicuro da e per la rete
(figura 3).
Il firewall è un’architettura fisica che posizionata tra la “realtà esterna” e la rete da
proteggere determina un punto di isolamento di facile controllo che evita il propagarsi
di problemi a sezioni di rete particolarmente “sensibili”.
Per la gestione dinamica delle VLAN e l’autenticazione degli host in rete è utilizzato
lo standard IEEE 802.1x che descrive un’infrastruttura per autenticare i dispositivi
collegati alle porte della rete (switch e access point) stabilendo un collegamento
punto a punto e prevenendo collegamenti non autorizzati alla rete locale. Gli elementi
che prendono parte alla fase di autenticazione sono così schematizzati:
− Supplicant: il client che richiede di essere autenticato
− Authenticator: il dispositivo che esegue l’inoltro della richiesta di accesso
− Authentication Server: il dispositivo che effettua il controllo sulle credenziali
di accesso del supplicant ed autorizza l’accesso
Lo standard descrive Il formato dei messaggi di trasporto e ha il compito di dare
all’access point la capacità di inoltrare le credenziali del client al server autenticazione
(RADIUS) e la relativa risposta verso il client stesso. L’autenticazione è basata su
username, password e, opzionalmente, una risposta a una richiesta di riconoscimento
(una sorta di “parola d’ordine”). Se l’autenticazione ha successo, il server RADIUS
invia le informazioni di configurazione al client, inclusi i valori necessari a soddisfare
il servizio richiesto come:
− un indirizzo IP e una maschera di sottorete per PPP
Figura 3: regole che consentono il passaggio di pacchetti attraverso un router
I limiti delle ACL sono i seguenti:
− un numero di porta TCP per telnet
− una ID di VLAN
− Gestire N righe di ACL per ogni VLAN è complesso e oneroso
− Non tutte leACLsono “connection aware” e dunque non funzionano sul servizio ma
solo sulla porta d’ascolto, e spesso i servizi usano porte non prevedibili/censibili.
Questo è il limite intrinseco di questa tecnologia che determina il fatto che
spesso è possibile filtrare solo per IP.
AIIC
associazione
italiana
ingegneri clinici
Il Software e le Reti IT-Medicali
nel contesto Sanitario
Il Software e le Reti IT-Medicali
nel contesto Sanitario
AIIC
associazione
italiana
ingegneri clinici
Il supplicant è un programma o servizio che implementa le transazioni 802.1x di
richiesta di accesso alla rete, integrato in windows, che può essere configurato in
diverse maniere, ma in generale richiede all’authenticator accesso alla rete mediante
alcune credenziali configurate. L’authenticator è lo switch. Se le porte dello switch
sono configurate per essere aperte a seguito di autenticazione allora:
− Prima che l’autenticazione avvenga ammettono solo il traffico di autenticazione
(pacchetti broadcast o pacchetti di autenticazione EAP)
− Dopo che l’autenticazione va a buon fine, la porta va in stato di normale
attività e l’host ha accesso alle risorse per la VLAN configurata
Il server di autenticazione, anche per il protocollo 802.1x, è un server in grado di
interpretare il protocollo RADIUS. Una delle implementazioni, quella usata in
AOUTS, è quella Microsoft, che si chiama servizio NPS all’interno di Windows Server.
Sappiamo che l’authenticator inoltra la richiesta del supplicant a questo server, in
maniera che possa processare le credenziali fornite dall’host stesso.
Abbiamo visto che è possibile gestire quanto visto finora (assegnazione VLAN) in
maniera dinamica ma nella realtà come vengono applicati questi meccanismi ai DM?
Chi gestisce le configurazioni centralizzate in un ambiente multi-ente come quello
dell’AOUTS?
Nel caso di host in dominio, autenticazione effettuata mediante verifica dell’account
macchina (trasparente all’utente), la configurazione viene fatta con una regola
sul gruppo di appartenenza della macchina. Nel caso di host non in dominio ma
con client 802.1x (es. telefoni VOIP) autenticazione con NU e PW memodizzati
sul dispositivo (trasparente all’utente), regola su gruppo Nel caso di host fuori
dominio, l’autenticazione non può che essere effettuata per MAC authentication.
La MAC Address Authentication fornisce un metodo per autenticare le macchine
in base alla porta dello switch a cui sono collegate e al loro MAC Address, senza
richiedere nessun software client installato sugli host. Una volta che è stato rilevato
il MAC Address dell’host, inizia il processo di autenticazione. Nessun inserimento
di password è richiesto, e nessuna installazione di certificati è richiesta. La MAC
Address Authentication può essere implementata:
Per una migliore centralizzazione della tecnica, si è scelto di utilizzare la seconda
opzione. In questo caso, gli switch funzionano come RADIUS client, e completano
la MAC Address Authentication in cooperazione con i RADIUS Server. La tecnica
consiste nell’utilizzare i MAC Address degli apparati come “utenze e password” da
utilizzare nell’autenticazione. In altre parole, non appena un apparato medicale si
connette a una porta dello switch, lo switch stesso spedisce al RADIUS Server una
richiesta di autenticazione contenente:
− Come User-Name : il MAC Address dell’apparato
− Come password: il MAC Address dell’apparato
Affinché l’autenticazione avvenga, è necessario configurare tante utenze in Active
Directory quanti sono gli apparati medicali. Ogni utenza dovrà avere uno User Log
on Name e una Password uguali al MAC Address dell’apparato.
Pertanto il RADIUS proxy verifica da che dominio arriva la richiesta (esempio per
l’account 1m0710.aouts.it o da un host che ha il certificato di AOUTS a bordo) e
inoltra le richieste RADIUS secondo le regole configurate al RADIUS server opportuno
(AOUTS, ASS1, UNITS). Il proxy RADIUS è gestito dall’amministratore della rete
fisica, in accordo con gli altri enti ospitati. In questa maniera è possibile permettere
agli enti di gestire in maniera INDIPENDENTE e DINAMICA le configurazioni di rete
dei client, potendo mantenere la comodità della configurazione omogenea delle porte
degli switch.
− localmente sugli switch
− appoggiata ai RADIUS Servers.
AIIC
associazione
italiana
ingegneri clinici
Il Software e le Reti IT-Medicali
nel contesto Sanitario
Il Software e le Reti IT-Medicali
nel contesto Sanitario
AIIC
associazione
italiana
ingegneri clinici
RACCOLTA SLIDE DEL CORSO
Il Software e le Reti IT-Medicali
nel contesto Sanitario
AIIC
associazione
italiana
ingegneri clinici
Scopo del Corso
CORSO POST XIV CONVEGNO NAZIONALE AIIC
“IL SOFTWARE E LE RETI IT-MEDICALI NEL
CONTESTO SANITARIO”
LE RETI IT MEDICALI – UN CASO REALE:
LA (RI)PROGETTAZIONE DELL’ARCHITETTURA DI
NETWORKING DI UN’AZIENDA OSPEDALIERA ALLA LUCE
DEI PRINCIPI DELLA NORMA IEC 80001
• richiamare elementi di sicurezza informatica
ed elementi di gestione informatica dei DM
(norma IEC 80001);
• descrivere il progetto di configurazione della
rete dati di un’Azienda Ospedaliera (AOUTS),
come esempio di tentativo di dare concreta
realizzazione alle indicazioni della norma
suddetta.
Ing. Valeria Laudicina
ing. Davide Salute
Programma
• Le caratteristiche di contesto (peculiari) di
un’Azienda Ospedaliero-Universitaria
• Principi di sicurezza informatica nella cornice della
norma IEC 80001
• Obiettivi della progettazione di una rete IT
medicale
• Elementi di progettazione e utilizzo degli
strumenti dell’IT
Considerazioni
• La “rete dati” (e più in generale l’infrastruttura IT) di
un’Azienda Ospedaliera ha almeno due PECULIARITÀ
significative:
– la presenza in rete di Dispositivi Medici (DM), che possono essere
anche apparecchi elettromedicali o software DM, con tutte le
specificità che queste classi di dispositivi comportano
• la massiccia diffusione di DM dotati di interfaccia di rete (o comunque
capaci di interagire con l’infrastruttura informatica, p.e. SW DM) ha
profondamente cambiato lo scenario riguardante non solamente le
funzionalità dei dispositivi stessi, ma ancora di più la loro gestione e
l’interazione e interoperabilità con altre parti costituenti il patrimonio
tecnologico e informativo all’interno delle aziende ospedaliere
(“organizzazioni responsabili”).
– e, per mission, il trattamento di dati personali e sensibili nonché
protetti da alcune leggi specifiche del settore sanitario.
Considerazioni
• che implicano CRITICITÀ nella gestione dei DM
in rete e dell’infrastruttura IT
– per i DM, la gestione del rischio non è solo “safety”
ma anche “data and system security” e “privacy”,
– per l’infrastruttura IT, la sicurezza informatica (“data
and system security”) non può prescindere da
considerazioni in materia di “privacy” ed in materia di
“safety”.
IEC 80001-1:2010
Forewords
International Standard IEC80001-1 has been prepared by a joint working group of
subcommittee 62A: Common aspects of electrical equipment used in medical
practice, of IEC technical committee 62: Electrical equipment in medical practice
and ISO technical committee 215: Health informatics.
Scope
 (…) this international standard defines the roles, responsibilities and
activities that are necessary for RISK MANAGEMENT of IT-NETWORKS
incorporating MEDICAL DEVICES to address SAFETY, EFFECTIVENESS and
DATA AND SYSTEM SECURITY (the KEY PROPERTIES). This international
standard does not specify acceptable RISK levels.
 This standard applies after a MEDICAL DEVICE has been acquired by a
RESPONSIBLE ORGANIZATION and is a candidate for incorporation into an ITNETWORK.
Terms and definitions
 MEDICAL IT-NETWORK: an IT-NETWORK that incorporates at least one
MEDICAL DEVICE
Formalizzazione considerazioni
Queste considerazioni sono state formalizzate
per la prima volta a livello internazionale
nella norma IEC 80001-1:2010 “Application
of risk management for IT-networks
incorporating medical devices - Part 1:
Roles, responsibilities and activities”
IEC 80001-1:2010
This standard adopts the following principles (…)
 RISK MANAGEMENT should be used before the incorporation
of a MEDICAL DEVICE into an IT-NETWORK takes place, and for
any changes during the entire life cycle of the resulting
MEDICAL IT-NETWORK, to avoid unacceptable RISKS, including
possible RISK to patients, resulting from the incorporation of
the MEDICAL DEVICE into the IT-NETWORK.
 This standard is addressed
- to RESPONSIBLE ORGANIZATIONS,
- to manufacturers of MEDICAL DEVICES, and
- to providers of other information technology.
IEC 80001-1:2010
IEC 80001-1:2010
 Such ACCOMPANYING DOCUMENTS should convey instructions about
 RISK MANAGEMENT should be applied to address the
following KEY PROPERTIES appropriate for the IT-NETWORK
incorporating a MEDICAL DEVICE:
- SAFETY (freedom from unacceptable RISK of physical injury
or damage to the health of people or damage to property
or the environment);
- EFFECTIVENESS (ability to produce the intended result for
the patient and the RESPONSIBLE ORGANIZATION); and
- DATA AND SYSTEM SECURITY (an operational state of a
MEDICAL IT-NETWORK in which information assets (data
and systems) are reasonably protected from degradation of
confidentiality, integrity, and availability).
IEC 80001-1:2010
 The MEDICAL IT-NETWORK RISK MANAGER is responsible for
ensuring that RISK MANAGEMENT is included during the
PROCESSES of:
- planning and design of new incorporations of MEDICAL
DEVICES or changes to such incorporations;
- putting the MEDICAL IT-NETWORK into use and the
consequent use of the MEDICAL IT- NETWORK; and
- CHANGE-RELEASE MANAGEMENT and change management
of the IT-NETWORK during the IT-NETWORK’S entire life
cycle.
- how to incorporate the MEDICAL DEVICE into the IT-NETWORK,
- how the MEDICAL DEVICE transfers information over the IT-NETWORK,
- and the minimum IT-NETWORK characteristics necessary to enable the
INTENDED USE of the MEDICAL DEVICE when it is incorporated into the ITNETWORK.
The ACCOMPANYING DOCUMENTS should warn of possible hazardous situations
associated with
- failure or disruptions (GUASTO) of the IT-NETWORK,
- and the misuse (USO IMPROPRIO) of the IT-NETWORK connection or of the
information that is transferred over the IT-NETWORK.
 RESPONSIBILITY AGREEMENTS can establish roles and responsibilities among those
engaged in the incorporation of a MEDICAL DEVICE into an IT-NETWORK, all aspects
of the life cycle of the resulting MEDICAL IT-NETWORK and all activities that form
part of that life cycle.
IEC 80001-1:2010
Roles and responsibilities
 TOP MANAGEMENT shall
appoint a MEDICAL IT-NETWORK
RISK MANAGER, who has the
necessary
- qualifications,
- knowledge and
- competence
for RISK MANAGEMENT applied
to MEDICAL IT- NETWORKS
IEC 80001-1:2010
Roles, responsibilities and
activities
 The RESPONSIBLE
ORGANIZATION shall
establish and maintain a
MEDICAL IT-NETWORK
RISK MANAGEMENT
FILE
Techincal Report IEC/TR 80001-2-x
• IEC/DTR 80001-2-5 (non ancora rilasciata) Application of risk management for
IT-networks incorporating medical devices – Part 2-5: Application guidance Guidance for distributed alarm systems.
• ISO/TR 80001-2-6 (non ancora rilasciata) Application of risk management for
IT-networks incorporating medical devices – Part 2-6: Application guidance Guidance for responsibility agreements.
• IEC/DTR 80001-2-7 (non ancora rilasciata) Application of risk management for
IT-networks incorporating medical devices – Part 2-7: Application guidance Guidance for Healthcare Delivery Organizations (HDOs) on how to self-assess
their conformance with IEC 80001-1
Techincal Report IEC/TR 80001-2-x
• IEC/TR 80001-2-1:2012 Application of risk management for IT-networks
incorporating medical devices – Part 2-1: Step-by-step risk management of
medical IT-network – Practical applications and examples.
• IEC/WD 80001-2 (non ancora rilasciata) Application of risk management for IT-
networks incorporating medical devices – Part 2: Guidance on distributed
alarm systems.
• IEC/TR 80001-2-2:2012 Application of risk management for IT-networks
incorporating medical devices – Part 2-2: Guidance for the disclosure and
communication of medical device security needs, risks and controls.
• IEC/TR 80001-2-3:2012 Application of risk management for IT-networks
incorporating medical devices – Part 2-3: Guidance for wireless networks.
• IEC/TR 80001-2-4:2012 Application of risk management for IT-networks
incorporating medical devices – Part 2-4: General implementation guidance
for healthcare delivery organizations.
FOCUS: caratteristiche di
contesto (peculiari) di un’Azienda
Ospedaliero-Universitaria ai fini
della (ri)progettazione
dell’architettura di networking
Azienda Ospedaliero-Universitaria
“Ospedali Riuniti” di Trieste (AOUTS)
Il 5 marzo 2004 è stata costituita l’Azienda OspedalieroUniversitaria “Ospedali Riuniti” di Trieste, la cui
organizzazione, in attuazione del D.Lgs. 517/1999, deve
svilupparsi sulla base di logiche dipartimentali che
consentano l’integrazione tra attività assistenziali,
didattiche e di ricerca presupposto della costituzione
dell’Azienda Mista Ospedaliero-Universitaria
Azienda Ospedaliero-Universitaria
“Ospedali Riuniti” di Trieste (AOUTS)
Organizzata in:
• 13 Dipartimenti di Attività Integrata (DAI) ospedaliero-universitari e
• 2 Dipartimenti Tecnico-Amministrativi, che in totale raggruppano
• 49 Strutture Complesse
Qualificata come “ospedale di rilievo nazionale e di alta specializzazione”:
• 760 posti letto (84 di day hospital)
• più di 3000 dipendenti (circa 450 medici e 1250 infermieri)
• 23 sale operatorie (19 Ospedale di Cattinara + 4 Ospedale Maggiore)
Distribuita su:
• 2 presidi ospedalieri: Ospedale Maggiore e Ospedali di Cattinara
(accreditato JCI) che contano da soli 10 diversi edifici
• più ulteriori 5 sedi periferiche
Azienda Ospedaliero-Universitaria
“Ospedali Riuniti” di Trieste (AOUTS)
Presso gli stabili AOUTS sono ospitati anche servizi afferenti:
• all’Azienda per i Servizi Sanitari n.1 - Triestina (ASS1) e
• all’Università degli studi di Trieste,
per un totale di circa 3.000 host collegati in rete e 3.500 utenti
Azienda Ospedaliero-Universitaria
“Ospedali Riuniti” di Trieste (AOUTS)
Le 3 aziende convivono sui diversi presidi AOUTS  le 3 aziende
condividono la stessa rete dati  aumenta il livello della
criticità delle considerazioni di cui sopra, p.e.:
• in termini di privacy, significa avere 3 titolari dei
trattamenti
necessità di poter adottare policy differenti
necessità di una netta separazione del traffico di rete
afferente a differenti titolari dei trattamenti
Azienda Ospedaliero-Universitaria
“Ospedali Riuniti” di Trieste (AOUTS)
• in termini di gestione rete dati, significa avere
3 infrastrutture sistemistiche e applicative (logiche)
distinte gestite da 3 enti che insistono su un’unica
infrastruttura di rete (fisica).
almeno per AOUTS e ASS1 necessità di integrare host
intrinsecamente e irrisolvibilmente insicuri tra di loro
(p.e. DM) e con altri host sicuri di competenza di diversi
titolari
CRITICITÀ a N dimensioni
SAFETY
Sicurezza del paziente a seguito della connessione fisica e logica in rete
di DM
Danni fisici al paziente (ma anche agli operatori, a terzi ed al
patrimonio) possono essere provocati da:
• rischi legati alla sicurezza elettrica
- vanno fatte alcune considerazioni partendo dal quadro normativo e
andando oltre … (approccio “tradizionale” alla gestione dei DM): la
“documentazione annessa” (labeling) fornita dal fabbricante
contempla la connessione di rete?
 SI, è prevista la connessione durante l’uso sul paziente  OK
 SI, ma non è prevista la connessione durante l’uso sul paziente  si
applicano le limitazioni del fabbricante o si segue il caso “NO”
 NO: l’Organizzazione Responsabile deve fare la valutazione del rischio
(ASSEMBLAGGIO/MODIFICA di SISTEMA EM)
o collegamenti o connessioni funzionali “dati” sono tipicamente TEMPORANEI e
non PERMANENTI
o si rientra nel caso della “modifica” del sistema ogni volta che si connette e
disconnette il DM alla rete dati
o uso di dispositivi di separazione galvanica (separation device).
SAFETY
FOCUS: principi di sicurezza
informatica nella cornice della
norma IEC 80001 ai fini della
(ri)progettazione dell’architettura
di networking
• rischi legati a malfunzionamenti dei DM derivanti
- da “guasti” o “errate configurazioni” degli interfacciamenti o
- da interazioni non desiderate tra il DM e il “mondo
informatico esterno”
ci vengono in soccorso:
“effectiveness” (p.e. qualità e tipologia degli interfacciamenti,
su cui effettuare la valutazione del rischio) e
“data and system security” (p.e. interazione con
l’infrastruttura informatica e con malware, su cui effettuare la
valutazione del rischio)
EFFECTIVENESS
Capacità di produrre il risultato atteso per il paziente e
l’Organizzazione Responsabile (efficacia).
• Aspetti di integrazione, interfacciamento e interoperabilità con
l’infrastruttura IT per realizzare, in maniera sicura ed efficace, il
flusso dati informatizzato a partire dal DM/SW DM in rete.
Ciò contribuisce anche:
alla businness continuity (data and system security)
alla sicurezza del dato (data and system security)
L’obiettivo “sistema di qualità dell’informazione/dato clinica/o” è
perseguibile
- principalmente tramite l’impiego di standard di
comunicazione e descrizione dei dati (p.e. DICOM, HL7) e
l’adozione di best practice internazionali (p.e. iniziativa IHE).
EFFECTIVENESS
- Inoltre, ulteriori strumenti a garanzia della qualità
dell’informazione/dato al fine della valutazione clinica sono:
o strumento “informatico”
firma digitale e sistema di conservazione sostitutiva dei
documenti a norma, a garanzia di integrità e non
modificabilità degli stessi,
– un documento firmato e correttamente conservato
può essere ritenuto “sicuro” dal clinico;
o strumento “normativo”
la marcatura CE DM per il software DM,
– un dato fornito da un software DM (usato
correttamente) può essere ritenuto “sicuro” dal
clinico.
DATA AND SYSTEM SECURITY
Garantire che agli operatori siano rese disponibili le risorse informatiche
necessarie e siano fornite le informazioni giuste, al momento giusto, nel
posto giusto e solo a quanto relativamente di competenza.
L’ISO ha definito la sicurezza come l’insieme delle misure atte a garantire la
riservatezza, l’integrità e la disponibilità delle informazioni.
La norma IEC 80001 ha mutuato la definizione ISO di sicurezza (DATA AND SYSTEM
SECURITY: an operational state of a MEDICAL IT-NETWORK in which information assets (data
and systems) are reasonably protected from degradation of confidentiality, integrity, and
availability).
Quindi il nostro OBIETTIVO a garanzia di DATA AND SYSTEM SECURITY (DSS) è
l’ottenimento e il mantenimento nel tempo dei requisiti di RISERVATEZZA,
INTEGRITÀ e DISPONIBILITÀ (RID) delle risorse IT e delle informazioni.
DATA AND SYSTEM SECURITY
Riservatezza
Con il termine riservatezza (confidenzialità) si intende l’insieme
delle regole che limitano l’accesso alle risorse informatiche
ed alle informazioni, alle sole persone autorizzate.
Es.: un medico della Ortopedia non deve avere accesso all’applicativo
verticale di reparto della Radiologia (RIS) ma deve vedere i referti
radiologici e le immagini associate dei suoi pazienti “in percorso di
cura”. Per fare ciò non è necessario che abbia accesso diretto ai server
su cui questi servizi insistono o alle cartelle dove sono salvate le
immagini PACS.
DATA AND SYSTEM SECURITY
Integrità
Per integrità delle risorse informatiche e delle informazioni si
intende la correttezza, l’esattezza e la completezza delle
stesse: garanzia di non modificabilità non autorizzata.
Importante, al fine di garantire l’integrità, è potere stabilire
la paternità (non ripudiabilità), intesa come:
• legare un dato al suo autore (strumento firma
elettronica);
• tracciabilità dell’azione (file di log).
DATA AND SYSTEM SECURITY
Concetti di sicurezza
• La sicurezza è come una catena: l’anello debole definisce la
sicurezza dell’intero sistema.
Nella nostra realtà è sicuramente una maglia a N
dimensioni.
• È una condizione, una qualità di un sistema informatico che si
può ottenere temporaneamente ed è difficile da mantenere.
• La sicurezza è “a tendere”. Non esiste la sicurezza in assoluto, con
risorse finite.
 Quindi bisogna gestire un processo continuo di analisi,
implementazione, monitoraggio e miglioramento al fine di
mantenere il rischio informatico residuo sotto il livello dai
noi fissato come accettabile.
DATA AND SYSTEM SECURITY
Disponibilità
Con il termine disponibilità, si intende il fatto che una
determinata risorsa informatica o un’informazione sia resa
fruibile quando serve (talvolta h24) con le giuste modalità,
con gli strumenti più adeguati e nel luogo giusto.
Rientrano in quest’ambito la businness continuity (continuità
operativa) e il disaster recovery.
NB. L’esigenza di rendere le risorse IT e le informazioni massimamente
disponibili talvolta sembra contrastare con quella di proteggerli
dall’uso non autorizzato (riservatezza). FALSA CREDENZA: È
RISERVATO QUANDO ECCEDENTE E NON PERTINENTE AGLI SCOPI!
FOCUS: obiettivi della
(ri)progettazione di una rete IT
medicale
Focus nel focus
Quando parliamo di Infrastruttura IT bisogna distinguere:
• Infrastruttura di rete (Networking: rete dati o LAN)
- protocolli, disciplina del traffico, QoS, Multicast, VLAN, piani di indirizzamento IP,
DHCP, 802.1x
• Infrastruttura sistemistica (Computer System)
- DHCP, 802.1x, DNS, virtualizzazione server, NAS, backup, DB centralizzati, SSO,
directory service, WSUS, AV, desktop management, SW inventory, assett
management
• Infrastruttura applicativa (Applicativi/Programmi Software)
3 mondi diversi con competenze diverse
• A ciascuno di questi settori afferiscono professionalità differenti e
profondamente specialistiche)
- Amministratori di Rete
- Sistemisti, Amministratori di Dominio
- DB Admin, Software Admin, Programmatori/Sviluppatori
MA INTERCORRELATI
Il progetto di configurazione
della rete dati AOUTS
• Parliamo di Infrastruttura di rete (networking)
• Consideriamo solo Data and System Security per
approcciare al networking: l’obiettivo quindi è garantire
riservatezza, integrità, disponibilità (RID).
NB. Per la parte networking:
– se garantiamo RID (e più in generale DSS), di fatto, anche gli
obbiettivi di efficacia sono assicurati (integrità e disponibilità
= qualità e tempi garantiti) e quindi
– se garantiamo DSS ed efficacia, abbiamo garanzia anche della
safety (per tutto quanto non è sicurezza elettrica)
abbiamo chiuso il cerchio!!! ☺
Obiettivi e vincoli nella progettazione
di una rete IT medicale
In generale:
• Ottemperare agli obblighi di legge definiti a più livelli e sotto vari
punti di vista (crimini informatici e CP, CAD e quadro normativo di
riferimento, privacy e quadro normativo di riferimento), ciò va
perseguito con una logica sistemica e non con interventi a spot.
• Progettazione in un ottica globale e di sistema secondo i principi di
ridondanza, resilienza, continuità operativa, facilità di gestione.
• Centralizzazione dei servizi: traffico disciplinato e sempre dalla
periferia al centro (Data Center).
• Controllo e verifica dei flussi dati (responsabilità in vigilando).
• Aggiornamento degli amministratori (Network Administrator) e
formazione specifica sulle risorse da loro amministrati e su quelle
che in ogni forma interagiscono con tali risorse.
• Formazione e informazione continua degli operatori sulle best e
mal practice.
• Documentazione.
Da cui bisogna definire nel dettaglio le direttrici su cui lavorare…
Obiettivi e vincoli nella progettazione
di una rete IT medicale
In particolare:
• PROTEGGERE gli host insicuri (in molti casi DM);
• PROTEGGERE gli host sicuri da quelli insicuri;
I DM connessi alla rete dati
- possono essere oggetto di attacchi informatici,
- ma anche punti di partenza per azioni della stessa natura
Al riguardo i fabbricanti e distributori
- non danno risposte, o
- danno risposte non competenti oppure
- pongono soluzioni che sono vincoli per lo più non attinenti alle policy IT
dell’Azienda.
In ogni caso vale quanto previsto nelle MDD (direttive DM):
- non devono essere inficiati i requisiti essenziali di sicurezza a causa della
connessione del DM in rete e dell’applicazione di policy di sicurezza IT nel
tempo;
- è il fabbricante che definisce nelle istruzioni per l’uso e nella documentazione
annessa i limiti di impiego e la destinazione d’uso.
Obiettivi e vincoli nella progettazione
di una rete IT medicale
• CONTROLLARE LA RETE
– Limitare la visibilità solo a ciò che è necessario, ovvero
isolare gli oggetti insicuri ed impedire la visibilità
indiscriminata delle risorse
– Limitare le comunicazioni solo alle destinazioni
necessarie, ovvero disciplinare il traffico ed impedire
l’accesso indiscriminato alle risorse
• GARANTIRE la disponibilità di dati e servizi anche
attraverso la ridondanza fisica e funzionale degli
apparati e dei sistemi
Da cui bisogna definire nel dettaglio gli elementi e
strumenti IT necessari agli scopi ...
Introduzione alla progettazione della rete
Nel proseguo, aspetto per aspetto
• Una descrizione degli strumenti a disposizione
del network engineer per ottenere gli obiettivi
citati
• Una descrizione e discussione del loro impiego
in AOUTS
IEC 80001
Sicurezza dei dati e dei sistemi (DSS)
FOCUS: Elementi di
(ri)progettazione e utilizzo degli
strumenti dell’IT
→ Rete Da (Networking)
Progettazione nella particolare ottica di:
→ Autencazione di rete
Chi si connette alla mia rete?
→ Disciplina/Isolamento del traffico di rete
Con chi può comunicare e cosa/come?
NB: In un’azienda sanitaria i maggiori rischi
vengono dall’interno, per le sue peculiarità!
Introduzione alla progettazione
di una rete dati
Elementi di una rete dati:
-Passivi/Fisici
-Cablaggio Strutturato
-Canalizzazioni e cavedii
-Armadi rack
-Locali e vani tecnici (datacenter e locali/vani periferici)
-Intrusione
-Alimentazione elettrica
-Condizionamento
-Antincendio
-Antiallagamento
-Aspetti di efficienza energetica e logistica
Introduzione alla progettazione
di una rete dati
Elementi di una rete dati:
-Attivi
-Apparati di rete
-Hub
-Switch
-Router
-WI-FI (access point, wireless switch)
-Host
-Server (SO che eroga servizi)
-Client (SO che usufruisce di servizi)
-“Device” (no SO)
-Appliance
-Firewall/NGFW/IPS/IDS
-VPN Concentrator
-Proxy/URL filtering
-Sonde di rete
Introduzione alla progettazione
di una rete dati
Nel seguito, ci focalizzeremo su alcuni particolari
ambiti del network design:
• Richiamando per grandi linee basi teoriche e
strumenti a disposizione del network engineer
per ottenere gli obiettivi citati
• Parlando del loro impiego presso AOUTS
Network Design:
Architettura
• WAN/MAN (provider pubblici e privati)
Wide/Metropolitan Area Network
• LAN (privati)
Local Area Network
– Campus
– Building/Edificio
– Floor/Piano-Area-Zona
possono anche non essere presenti tutti…
Network Design:
Architettura
• A good network design is modular and
hierarchical, with a clear separation of
functions:
Campus Network Design - Simple
ISP1
Network Border
– Core: redundancy, resilience, few changes,
few features, high bandwidth, CPU power
– Distribution: redundancy, resilience,
aggregation
– Access: redundancy (?), port density,
affordability (accessibilità), security features,
many adds/moves/changes
Network Design:
Architettura
• In una LAN possiamo avere due
architetture possibili:
– Core, Distribution e Access
– Core e Access
• Inoltre,
– Core è sempre di Campus,
– Distribution può essere di Edificio o di
Piano/Area
– Access può essere di Piano o di Edificio
Core
Distribution
Access
Campus Network Design - Redundant
ISP1
ISP2
Network Border
Core
Distribution
Access
In-Building and Layer 2 (pila ISO/OSI)
• There is usually a correspondence between building
separation and subnet separation
– Switching inside a building (Layer 2)
– Routing between buildings (Layer 3)
• This will depend on the size of the network
– Small networks -> switching between buildings
(CampusCore/BuildingAccess/FloorAccess oppure
CampusCore/FloorAccess)
– Medium networks -> routing between buildings
(CampusCore/BuildingDistribution/FloorAccess)
– Large networks -> routing inside buildings
(CampusCore/FloorDistribution/FloorAccess)
Normativa (leggi) di riferimento
• DIRETTIVA DEL CONSIGLIO del 20 giugno 1990 per il ravvicinamento delle
legislazioni degli Stati membri relative ai dispositivi medici impiantabili attivi
(90/385/CEE)
• DIRETTIVA 93/42/CEE DEL CONSIGLIO del 14 giugno 1993 concernente i
dispositivi medici
• DIRETTIVA 98/79/CE DEL PARLAMENTO EUROPEO E DEL CONSIGLIO
del 27 ottobre 1998 relativa ai dispositivi medico-diagnostici in vitro
2007/47/CE
• ultimamente modificate da DIRETTIVA
DEL PARLAMENTO EUROPEO E DEL
CONSIGLIO del 5 settembre 2007
• Testi coordinati disponibili http://ec.europa.eu/health/medical-devices/documents/index_en.htm
2
Dispositivi medici e DM software
Normativa (leggi) di riferimento
in ITALIA
• Decreto lgs. 14 dicembre 1992, n. 507
• Decreto lgs. 24 febbraio 1997, n. 46
• Decreto lgs. 8 Settembre 2000, n. 332
•
Testi coordinati disponibili in
http://www.salute.gov.it/portale/temi/p2_6.jsp?lingua=italiano&id=1636&area=dispositivimedici&menu=cosasono
Antonio Bartolozzi
Responsabile Medical ICT - Tesan S.p.a.
Responsabile sistemi informativi di gruppo - TBS Group S.p.a.
Venezia 5/4/2014
3
Cosa dicono le leggi?
•
Razionale del gruppo di direttive
•
Costituiscono un impianto ben coordinato di
leggi che regolano l’immissione in commercio
nel mercato comunitario di :
Dispositivi medici
Due «sottoclassi» particolari di dispositivi
medici
• Impiantabili attivi
• Diagnostici in vitro
:
•
•
si legge nei preamboli: a differenza delle
ns leggi (visto… visto…) il preambolo
nelle direttive europee è importante
quanto il testo!
6
4
Cosa dicono le leggi?
Preambolo della 90/385/CEE
(in ordine di importanza):
1. i prodotti dispositivi medici devono poter essere immessi sul mercato comunitario e
circolare liberamente tra paesi (ad es. lo immetto in commercio in Italia e
automaticamente può essere commercializzato in tutta EU e nessuno può opporsi)
•
considerando che in ogni Stato membro i dispositivi medici
impiantabili attivi devono offrire ai pazienti, agli operatori e
ai terzi un elevato livello di sicurezza e raggiungere il livello

prestazioni indicato quando sono impiantati nel corpo
umano;
•
considerando che le disposizioni nazionali volte a garantire
tale livello di sicurezza vanno armonizzate per assicurare la
libera circolazione dei dispositivi medici impiantabili attivi
senza abbassare il livello di sicurezza esistente e
giustificato negli Stati membri;
2. Per essere immessi in commercio:
• i dispositivi devono soddisfare una serie di requisiti essenziali, che ne dovrebbero
garantire un uso sicuro e (in piccola parte) l’efficacia. I requisiti essenziali sono stabiliti
nelle leggi stesse.
• I fabbricanti dei dispositivi devono sottostare ad alcune procedure stabilite nelle leggi
stesse.
3. Alcune norme tecniche (CEN/CENELEC) appositamente selezionate e periodicamente
aggiornate danno presunzione di conformità ad alcuni requisiti essenziali, ovvero
se il fabbricante le segue, il corrispondente requisito essenziale è automaticamente
soddisfatto (ma non è obbligatorio seguire le norme)
5
7
Preambolo della 93/42/CEE
A cosa si applicano le leggi?
• considerando che occorre adottare provvedimenti nel contesto del mercato interno, caratterizzato da uno spazio senza
frontiere interne nel quale sia assicurata la libera circolazione delle merci, delle persone, dei servizi e dei capitali;
• considerando che occorre armonizzare le disposizioni nazionali in materia di sicurezza e protezione della salute dei
pazienti, degli utilizzatori ed eventualmente dei terzi nell'uso dei dispositivi medici in modo da garantire la libera
circolazione dei dispositivi stessi nel mercato interno;
• considerando che i dispositivi medici devono garantire ai pazienti, agli utilizzatori e ai terzi un elevato livello di
protezione e devono fornire le prestazioni previste dal fabbricante; che di conseguenza il mantenimento e il
miglioramento del livello di protezione già raggiunto negli Stati membri costituisce un obiettivo essenziale della presente
direttiva;
• considerando che i requisiti essenziali e gli altri requisiti prescritti dagli allegati della presente direttiva, compresi quelli
volti a «minimizzare» o a «ridurre» i rischi, devono essere interpretati e applicati in modo da tener conto della tecnologia
e delle pratiche esistenti nella fase di progettazione nonché delle considerazioni tecniche ed economiche compatibili con
un elevato livello di protezione della salute e della sicurezza;
• considerando che, in particolare in vista delle procedure di valutazione della conformità, è necessario suddividere i
dispositivi medici in quattro classi di prodotti; che le regole di decisione di classificazione si basano sulla vulnerabilità del
corpo umano e tengono conto dei rischi potenziali connessi con l'elaborazione tecnologica dei dispositivi e con la loro
fabbricazione; che le procedure di valutazione della conformità per i dispositivi delle classe I possono essere svolte, in
linea di massima, sotto la sola responsabilità del fabbricante, dato lo scarso indice di vulnerabilità che possiedono questi
prodotti; che per i dispositivi della classe IIa l'intervento obbligatorio di un organismo notificato deve riguardare la fase di
fabbricazione; che per i dispositivi delle classi IIb e III i quali possiedono un elevato potenziale di rischio, è necessario
un controllo da parte di un organismo notificato sia nella fase di progettazione dei dispositivi che nella fase di
fabbricazione; che nella classe III vanno inseriti i dispositivi critici per i quali l'immissione in commercio presuppone
un'esplicita autorizzazione di conformità preliminare
• Ai DISPOSITIVI MEDICI e ai LORO
ACCESSORI
•
46/97 dispositivo medico: qualunque strumento, apparecchio, impianto, software, sostanza o altro prodotto, utilizzato da solo o in
combinazione, compreso il software destinato dal fabbricante ad essere impiegato specificamente con finalità diagnostiche o terapeutiche e
necessario al corretto funzionamento del dispositivo, destinato dal fabbricante ad essere impiegato sull'uomo a fini di diagnosi,
prevenzione, controllo, terapia o attenuazione di una malattia; di diagnosi, controllo, terapia, attenuazione o compensazione di una ferita o di
un handicap; di studio, sostituzione o modifica dell'anatomia o di un processo fisiologico; di intervento sul concepimento, il quale prodotto
non eserciti l'azione principale, nel o sul corpo umano, cui è destinato, con mezzi farmacologici o immunologici né mediante
processo metabolico ma la cui funzione possa essere coadiuvata da tali mezzi;
•
332/2000 "dispositivo medico: qualsiasi strumento, apparecchio, impianto, sostanza o altro prodotto, utilizzato da solo o in combinazione,
compreso il software informatico impiegato per il loro corretto funzionamento, la cui azione principale voluta nel o sul corpo umano non sia
conseguita con mezzi farmacologici né immunologici né mediante processo metabolico, ma la cui funzione può essere assistita da questi
mezzi, e destinato dal fabbricante ad essere impiegato nell'uomo a scopo di:1) diagnosi, prevenzione, controllo, terapia o attenuazione di una
malattia;2) diagnosi, controllo, terapia, attenuazione o compensazione di un trauma o di un handicap;3) studio, sostituzione o modifica
dell'anatomia o di un processo fisiologico;4) intervento sul concepimento;"
•
507/92 " dispositivo medico: qualunque strumento, apparecchio, impianto, software, sostanza o altro prodotto, utilizzato da solo o in
combinazione, compresi gli accessori tra cui il software destinato dal fabbricante ad essere impiegato specificamente con finalità
diagnostiche o terapeutiche e necessario al corretto funzionamento del dispositivo stesso, destinato dal fabbricante ad essere impiegato
sull'uomo a fini di: 1) diagnosi, prevenzione, controllo, trattamento o attenuazione di malattie; 2) diagnosi, controllo, trattamento,
attenuazione o compensazione di una ferita o di un handicap; 3) studio, sostituzione o modifica dell'anatomia oppure di un processo
fisiologico; 4) controllo del concepimento, che non eserciti nel o sul corpo umano l'azione principale cui è destinato con mezzi
farmacologici, immunologici o mediante processi metabolici, ma la cui funzione possa essere coadiuvata da tali mezzi; "
8
10
Preambolo della 98/79/CE
Accessorio
•
•
•
•
•
•
considerando che occorre adottare misure per il corretto funzionamento del mercato interno; che il mercato
interno è uno spazio senza frontiere interne nel quale è assicurata la libera circolazione delle merci, delle
persone, dei servizi e dei capitali;
considerando che l'armonizzazione delle legislazioni nazionali rappresenta l'unico mezzo per eliminare
questi ostacoli alla libertà di commercio e per impedire la creazione di nuovi ostacoli; che tale obiettivo non
essere conseguito adeguatamente con altri mezzi al livello dei singoli Stati membri; che la presente
direttiva si limita a fissare i requisiti necessari e sufficienti per garantire, nelle migliori condizioni di
sicurezza, la libera circolazione dei dispositivi medico-diagnostici in vitro ai quali essa si applica;
considerando che i dispositivi medico-diagnostici in vitro devono garantire ai pazienti, agli utilizzatori e ai
terzi un livello elevato di protezione sanitaria e devono fornire le prestazioni previste inizialmente dal
fabbricante; che, di conseguenza, uno dei principali obiettivi della presente direttiva è il mantenimento o il
miglioramento del livello di protezione sanitaria raggiunto negli Stati membri;
considerando che gli strumenti, gli apparecchi, le attrezzature, i materiali o altri articoli, compreso il software
informatico, destinati alla ricerca senza obiettivi medici non sono considerati dispositivi destinati alla
valutazione delle prestazioni;
•
•
•
Per gli impiantabili attivi, la definizione di dispositivo comprende gli accessori, quindi in molti casi gli
accessori classificati come il dispositivo
DM: La presente direttiva si applica ai dispositivi medici e ai relativi accessori. Ai fini della presente
direttiva gli accessori sono considerati dispositivi medici a pieno titolo.
IVD: La presente direttiva si applica ai dispositivi medico-diagnostici in vitro ed ai relativi accessori.
Ai fini della presente direttiva gli accessori sono considerati dispositivi medico-diagnostici in vitro a
pieno titolo
DM: accessorio: prodotto che, pur non essendo un dispositivo, sia destinato in modo specifico dal
fabbricante…. (ndr del dispositivo o dell’accessorio?) ad essere utilizzato con un dispositivo
per consentirne l'utilizzazione prevista dal fabbricante stesso (del dispositivo);
•
IVD «accessorio»: prodotto che, pur non essendo un dispositivo medico- diagnostico in vitro, è
destinato in modo specifico dal suo fabbricante ad essere utilizzato con un dispositivo per
consentirne l'utilizzazione conformemente alla sua destinazione.
•
meddev 2.1.6 1994 :The definition of "accessory" requires that the accessory is specifically intended
by the manufacturer of the accessory to be used together with a device. (ma per consentirne
l'utilizzazione prevista dal fabbricante del dispositivo)
9
11
immettere in commercio e in
servizio
•
Il concetto di immissione in commercio e messa in servizio è assai rilevante
-
I dispositivi possono essere immessi in commercio o messi in servizio
unicamente se rispondono ai requisiti prescritti dal presente decreto, sono
correttamente forniti e installati, sono oggetto di un’adeguata manutenzione e
sono utilizzati in conformità della loro destinazione.
-
Ha rilevanza per i dispositivi fabbricati in house
•
This actual placing on the market is defined as a physical act or legal transactionbased handover pursuant to which a device is transferred from the stage of
manufacture with the intention of distribution on the EU market. Per dispositivi
importati fa fede l’uscita dalla dogana.
•
messa in servizio: fase in cui il dispositivo è stato reso disponibile
all'utilizzatore finale in quanto pronto per la prima utilizzazione sul mercato
comunitario secondo la sua destinazione.
•
.
E’ un dispositivo medico o no?
•
•
14
12
immettere in commercio e in
servizio
•
per essere un dispositivo medico e’
NECESSARIO che il suo fabbricante
abbia detto che lo è
se “sembra” un dispositivo medico, ma il
fabbricante non ha detto nulla, NON è
un dispositivo medico
E’ un dispositivo medico o no?
•
INTERPRETATIVE DOCUMENT OF THE
COMMISSION'S SERVICES: PLACING ON THE
MARKET OF MEDICAL DEVICES
• A medical device which a private person acquires in a
third country and then brings it to the EU for his/her own
personal use is not 'placed on the market' and is not
required to conform to the requirements of the medical
devices directives.
•
ma cosa deve aver detto il fabbricante:
che l’oggetto ha delle FINALITA’
mediche (cioè una delle definizioni)
se non lo ha detto, NON LO è, anche se
è usato sull’uomo per il monitoraggio di
parametri fisiologici: vedi caso BioSemi
• If, however, a professional user buys a medical device in a
third country, brings it to the EU and uses this device in
the context of his/her professional activity, he/she puts this
device into service
•
.
13
15
caso Biosemi – il concorrente
E’ un dispositivo medico o no?
•
• Brain Products :BrainAmp Classe IIa
destinazione: l'utilizzazione alla quale è
destinato il dispositivo secondo le
indicazioni fornite dal fabbricante
nell'etichetta, nelle istruzioni per l'uso e
nel materiale
pubblicitario;
19
16
caso Biosemi
caso Biosemi :JUDGMENT OF THE COURT
(Third Chamber) 22 November 2012
• Biosemi ActiveTwo
• This is a system capable of recording electrical signals from the
human body and, more specifically, from the brain (EEG), the
heart (ECG) and the muscles (EMG). Although measurements of
that nature are frequently taken in a healthcare context (using
electrocardiograms, electroencephalograms and so on), the
product in question is not designed for the medical sector and
the related promotional material explicitly states that it is not
designed to be used for diagnosis and/or treatment. The
primary users of ActiveTwo, which is modular and can therefore
be configured to meet the needs of individual customers, are
researchers carrying out investigations, particularly in the
cognitive sciences.”
17
•
•
•
•
•
it must be stated that the wording of Article 1(2)(a) of Directive 93/42 was amended by Article
2 of Directive 2007/47, recital 6 of which states that a software in its own right is a medical
device when specifically intended by the manufacturer to be used for one or more of the
medical purposes set out in the definition of a medical device. That recital adds that software
for general purposes when used in a healthcare setting is not a medical device.
17 As regards software, the legislature thus made unequivocally clear that in order for it to
fall within the scope of Directive 93/42 it is not sufficient that it be used in a medical context,
but that it is also necessary that the intended purpose, defined by the manufacturer, is
specifically medical.
18 Although that amendment only concerns a single type of product, namely software, that
definition in the legislation militates in favour of an interpretation of the third indent of Article
1(2)(a) of Directive 93/42 according to which a device used in humans for the investigation of a
physiological process falls within the scope of Directive 93/42 only if the intended purpose of
that device, defined by its manufacturer, is medical.
19 Furthermore, nothing in Directives 93/42 and 2007/47 indicates that the legislature
intended that a wider scope should apply for ‘non-software devices’ than for ‘software’.
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:62011CJ0219:EN:HTML
20
Crescita del software nei dispositivi
medici
caso Biosemi
nel futuro?
• “‘medical device’ means any instrument, apparatus, appliance,
software, implant, reagent, material or other article, intended by the
manufacturer to be used, alone or in combination, for human beings for one
or more of the specific medical purposes of:
• – diagnosis, prevention, monitoring, treatment or alleviation of disease,
• – diagnosis, monitoring, treatment, alleviation of or compensation for an
injury or disability,
• – investigation, replacement or modification of the anatomy or of
a physiological process or state,
1983-1997
6% of all recalls attributed to SW (14 anni)
1999-2005
11.3% of all recalls
attributed to SW; 49% of all recalled
devices relied on software (up from 24%) (6 anni)
2006
Milestone: Over half of medical devices now involve software
2002-2010
• Proposta Futuro regolamento
• Biosemi->MD!
537 recalls of SW-based devices affecting 1,527,311 devices
22
21
Diffusione del sistemi microcontrollati
Dati sugli incidenti
oggi…..
60 microprocessori un una abitazione media
(e ciascuno esegue il suo codice)
80 microprocessori in una autovettura media
(e ciascuno esegue il suo codice)
e in una sottostruttura ospedaliera???
21
23
Il software nella direttiva DM
Il software nella direttiva IVD
• Nella definizione di DM: il software è un DM, come un qualunque altro prodotto
• Allegato I, requisiti essenziali Requisiti per i dispositivi medici collegati o dotati
di una fonte di energia
• 12.1-bis.
Per i dispositivi che incorporano un software o costituiscono
in sé un software medico, il software è convalidato secondo lo stato dell'arte,
tenendo conto dei principi del ciclo di vita dello sviluppo, della gestione dei
rischi, della validazione e della verifica.
• Allegato IX Criteri di classificazione
• 1.4. Dispositivo medico attivo
• ……Il software indipendente (stand-alone) è considerato un dispositivo
medico attivo.
• 2. Regole di applicazione
• 2.3. Il software destinato a far funzionare un dispositivo o ad influenzarne l'uso
rientra automaticamente nella stessa classe del dispositivo.
• Nella definizione di DM: il software è un DM, come un
qualunque altro prodotto
• Allegato I, requisiti essenziali
• 6.1 . I dispositivi che contengono sistemi elettronici
programmabili, compresi i software, devono essere
progettati in modo tale da garantire la ripetibilità,
l'affidabilità e le prestazioni di questi sistemi in accordo
con l'uso cui sono destinati.
I sw in ospedale garantiscono ripetibilità affidabilità e prestazioni ?
22
Il software nella direttiva DMIA
• Nella definizione di DM: il software è un DM, come un qualunque altro prodotto
• Allegato I, requisiti essenziali
• punto 9: I dispositivi devono essere progettati e fabbricati in modo tale da garantire le caratteristiche
e le prestazioni di cui al punto I "Requisiti generali", con particolare riguardo per:
• ……
• il buon funzionamento dei sistemi di comando, di programmazione e di controllo, compreso il
software. Per i dispositivi che incorporano un software o costituiscono in sé un software
medico, il software è convalidato secondo lo stato dell'arte, tenendo conto dei principi del ciclo di
vita dello sviluppo, della gestione dei rischi, della validazione e della verifica.
• Punto 15: All'atto dell'immissione sul mercato, ogni dispositivo deve essere
accompagnato da istruzioni comprendenti i seguenti elementi:
• ……informazioni atte a consentire al medico di selezionare il dispositivo adeguato, nonché il
software e gli accessori adeguati del dispositivo.
• informazioni che costituiscono le avvertenze per l'uso e consentono al medico ed
eventualmente al paziente di utilizzare correttamente il dispositivo, i suoi accessori e il software,
nonché informazioni relative a natura, portata e intervalli dei controlli e delle prove di
funzionamento ed eventualmente misure di manutenzione;
23
24
•
•
•
•
Classificazione
…. Non è un impiantabile attivo
… può essere un dm
… può al limite essere un IVD
Recital 6 of Directive 2007/47/EC states that "it is necessary to clarify that software in its own right,
when specifically intended by the manufacturer to be used for one or more of the medical purposes set
out in the definition of a medical device, is a medical device.
• Stand alone software must have a medical purpose to be qualified as medical device. It should be
noted that only the intended purpose as described by the manufacturer of the product is relevant for
the qualification and classification of any device and not by virtue of the way it may be called. Stand
alone software that does not meet the definition of a medical device or of an IVD medical
device but is intended by the manufacturer to be an accessory to a medical device, or an IVD
medical device, falls respectively under the scope of Directive 93/42/EEC or Directive 98/79/EC.
It is to be noted that to be qualified as an IVD medical device, stand alone software must first fulfil the
definition of a medical device. Stand alone software fulfilling the definition of medical device and
intended to be used for the purpose of providing information derived from in vitro examination of
a specimen derived from the human body falls under Directive 98/79/EC.
•
• Provided that stand alone software is intended specifically by its manufacturer to be used together with
an IVD medical device to enable that device to be used in accordance with its intended purpose, this
stand alone falls under the scope of the IVD Directive and shall be treated as an IVD device in its own
right.
•
25
Linea Guida
Stand alone software
• For the purpose of this guideline ‘stand
alone software’ means software which is
not incorporated in a medical device at
the time of its placing on the market or
its making available.
Flusso della linea guida
Classificazione
(MEDDEV 2.1/6:2012)
• Un software è un DM?
Rispetto
• A quale direttiva?
26
Step 1 - 2
Decision step 1: if the stand alone
software is a computer program, then it
may be a medical device. If the software is
not a computer program, then it is a digital
document and therefore not a medical
device.
Examples of computer programs are software
applications, macros, scripts, dynamically linked
libraries, batch files, style sheets and any document
containing active formatting or filtering instructions.
Examples of digital documents are image files, DICOM
files, digital ECG recordings, numerical results from
tests and electronic health records (EHR).
Decision step 2: if the software is
incorporated into a medical device rather
than stand alone software, it must be
considered as part of that medical device
in the regulatory process of that device. If
it is stand alone software, proceed to
decision step 3.
Step 3 – Linea guida
if the software does not perform an action on data, or
performs an action limited to storage, archival,
communication, ‘simple search’ or lossless compression
(i.e. using a compression procedure that allows the exact
reconstruction of the original data) it is not a medical device.
Altering the representation of data for embellishment purposes
does not make the software a medical device. In other cases,
including where the software alters the representation of
data for a medical purpose, it could be a medical device.
Se semplicemente trasmetto dati , memorizzo i dati su un db, comprimo dati
senza perdita non si crea necessariamente un dispositivo medico. Cambiare il
protocollo dei dati interpretandone il contenuto potrebbe dar luogo ad «un
dispositivo medico»
Step 4
Passi 3-4
E’ equivalente
ad una linea di
trasmissione
dati ?
Deve esistere
almeno un
paziente che
beneficia
dell’azione del
software
Decision step 4: an example of software for the
benefit of individual patients is software intended to
be used for the evaluation of patient data to
support or influence the medical care provided to
that patient. Examples of software which are not
considered as being for the benefit of individual
patients are those which aggregate population data,
provide generic diagnostic or treatment pathways,
scientific literature, medical atlases, models and
templates as well as software for epidemiologic
Diagnosi or
e percorsi
clinici non correlati ad un paziente
Il software è equivalente ad un «libro
studies
registers.
Gli studi epidemiologici non richiedono il software marcato CE.
Software intended for diagnosis or therapy
Passi 5 - 6
if they are intended to allow direct diagnosis or monitoring of vital
physiological processes, unless they are specifically intended for monitoring
of vital physiological parameters, where the nature of variations is such that it
could result in immediate danger to the patient, for instance variations in
cardiac performance, respiration, activity of CNS in which case they are in
Class IIb.
HR
•
•
Step 5 - 6
Decision step 5: if the manufacturer specifically intends the software to be used for any
of the purposes listed in Article 1(2)a of Directive 93/42/EEC, then the software shall be
qualified as a medical device.
However, if only a non-medical purpose is intended by the manufacturer, such as
invoicing or staff planning, it is not a medical device.
Note: A task such as e-mailing, web or voice messaging, data parsing, word processing,
and back-up is by itself not considered as being a medical purpose, according to
Directive 93/42/EEC.
Decision step 6: if the software is an accessory to a medical device, it is not a medical
device, but it falls under Directive 93/42/EEC. The legal definition of 'putting into service'
requires that a device is made available to the final user/operator as being ready for use
on the Community market. Software made available to the user over the internet
(directly or via download) or via in vitro diagnostic commercial services, which is
qualified as a medical device, is subject to the medical devices directives.
120
bpm
Software for the presentation of the heart rate or other physiological
parameters during routine checkups (Class IIa);
Software for the presentation of the heart rate or other physiological
parameters for intensive care monitoring (Class IIb).
Sistema di monitoraggio di pompe a infusione (MD)
• E’ un dispositivo medico
se inteso come sistema
di sorveglianza dello
stato di cura del
paziente. La presenza di
allarmi lo potrebbe
rendere un
monitoraggio attivo del
paziente (classe IIa/IIb).
Potrebbe anche essere
considerato un
accessorio delle pompe
a infusione.
Sistema di monitoraggio pompe a infusione (No MD)
e il fatto in casa?
Scopo previsto (ipotetico)
Il sistema è inteso per il
monitoraggio dei dispostivi
(pompe ad infusione) allo scopo
di stabilire le quantità di farmaco
consumate e lo stato di
funzionamento degli strumenti. Il
sistema non è inteso per il
monitoraggio dello stato di
cura del paziente e della dose
iniettata allo stesso. Per queste
attività rimane necessaria la
normale prassi di vigilanza
medica/paramedica.
• Svezia:
• Esempio: il caso della cartella clinica elettronica nazionale, che viene dichiarata non DM in
quanto («essendo usata solo ed esclusivamente nei confini nazionali, non può essere considerata
immessa in commercio nella UE»)
• I prodotti fabbricati nel settore sanitario e destinati esclusivamente ad uso proprio del
produttore (?), non sono da considerarsi sul mercato e quindi non coperti dal diritto derivato
dalle direttive. Per assicurarsi che al paziente / utente venga offerto lo stesso tipo di protezione
anche in questa situazione, il governo ha dato, secondo l’art. 4 del decreto (1993:876) sui
dispositivi medici, al National Board of Health and Welfare la possibilità di emanare regolamenti
"sui dispositivi medici fabbricati nella sanità, cure dentistiche e destinati unicamente all'uso
nelle proprie operazioni. "
Il National Board of Health and Welfare, supportato dal requisito regolamento stabilito per i
dispositivi medici "self made" nei loro regolamenti, ha emesso il regolamento SOSFS 2.001,12,
per l'uso e la propria produzione di dispositivi medici nel settore sanitario.
•
35
e il fatto in casa?
e il fatto in casa?
• Users in-house manufacturing (MEDDEV 2.1/1)
• The Directive defines a manufacturer as the natural or legal person
responsible for defined manufacturing activities related to a device with
a view to its being placed on the market under the manufacturers own
name. The reason for this link with the placing on the market is that the
directives aims to subject to its protection requirements the transaction
of a device from the sphere of a manufacturer towards the public. The
directive does not provide any specific provisions for the case
where a device is manufactured by the user (for example, a
hospital) without being transferred to another person. The
decision to which extent such in-house manufacturing activities by
hospitals are subjected to legal requirements, belongs therefore to
the national legislator. This relates however exclusively to such inhouse manufacturing activities where a device remains within the
users, but not to cases where, for example, a hospital produces
orthopaedic devices for use with patients.
34
Irlanda - GB
Devices remaining with one health institution
•
If a device is made by one health institution for use on or by the patients of that
institution there is no placing on the market and the Regulations do not apply. It
makes no difference if the device is transferred between parts of the same
institution under separate management or parts of the institution housed on
different premises. For example, a device developed in a physics laboratory which is
a constituent part of an NHS trust hospital for use on that hospital's patients would
not be placed on the market when passed from the laboratory to another part of the
hospital.
Note: the guidance above is not applicable to commercial (independent) dental
practices, e.g. practices which are not a constituent part of an NHS trust or private
hospital.
Devices transferred between health institutions are placed on the market
36
e il fatto in casa in ITALIA?
•
•
Non c’è una specifica previsione legislativa, il che potrebbe fare intendere che per il fatto in casa
valgono le stesse regole che per i normali fabbricanti
Si ricordi : «I dispositivi possono essere immessi in commercio o messi in servizio
unicamente se rispondono ai requisiti prescritti dal presente decreto»
• immissione in commercio: la prima messa a disposizione a
titolo oneroso o gratuito di dispositivi, esclusi quelli destinati
alle indagini cliniche, in vista della distribuzione e/o
utilizzazione sul mercato comunitario, indipendentemente
dal fatto che si tratti di dispositivi
• nuovi o rimessi a nuovo
• messa in servizio: fase in cui il dispositivo è stato reso
disponibile all'utilizzatore finale in quanto pronto per la
prima utilizzazione sul mercato comunitario secondo la sua
destinazione.
•
•
Ma se io produco un dm in casa e lo uso (in casa) l’ho messo in commercio? NO
L’ho messo in servizio? Dipende……..
37
e il fatto in casa in ITALIA?
E’ messo in servizio?
•
Il software DM è del tutto equivalente al caso dei dispositivi medici classici, quindi
anche se l’ho fatto in caso è messo in servizio. E LO SCOPO PREVISTO ?
•
«If, however, a professional user buys a medical device in a third country,
brings it to the EU and uses this device in the context of his/her professional
activity, he/she puts this device into service»  Quindi anche se l’utente lo
compra all’estero
•
Quindi deve rispettare i requisiti ed infatti, nelle proposte di revisione (nuovo
regolamento) si legge:
IVD
•
« Devices that are manufactured and used within a single health institution
shall be considered as being put into service»
MD
•
«Devices that are manufactured and used within a single health institution
shall be considered as being put into service»
38
dispositivi che vanno installati
meddev 2.1.1
• The concept of "finished device" does not imply that a device when reaching the final
user is already in a state ready for use. Prior to use further preparatory processing,
preparation, configuration, installation, assembling, adaptation or fitting to the needs of the user
or patient may be required. Examples :
•
- sterilisation of medical devices supplied non-sterile
•
- assembling of systems
•
- configuration of electronic equipment
•
- preparation of a dental filling
•
- fitting of contact lenses
•
- adaptation of prosthesis to the needs of the patient.
The aforementioned activities are normally not manufacturers activities if they are carried
out by the final user as part of the use or preparation for use. In this context a distinction
needs to be made between a typical professional activity performed by a healthcare professional
and processing and assembling activities done by a specialist for such processing. In the
latter case relevant activities may become proper manufacturing or assembling activities
relevant within the meaning of articles 11 and 12.
39
BIBLIOGRAFIA ESSENZIALE
I DOCENTI DEL CORSO
Antonio BARTOLOZZI
− Direttiva CEE 93/42
TBS Group
Valeria LAUDICINA
− Direttiva CEE 47/2007
Azienda Ospedaliero-Universitaria Ospedali Riuniti di Trieste
Davide SALUTE
− Interpretative document of the commission’s services: placing on the market
of medical devices
− Guidelines on the qualification and classification of stand alone software
used in healthcare within the regulatory framework of medical devices
Azienda Ospedaliero-Universitaria Ospedali Riuniti di Trieste
GLI AUTORI
− Norma IEC 80001-1:2010
− Protocollo operativo AOU “Ospedali Riuniti” di Trieste
Ing. Maurizio Rizzetto
Responsabile scientifico del Corso
Laureato
in
Ingegneria
Elettronica,
si
specializza
successivamente in ingegneria biomedica ed informatica in
radiologia. Ad oggi dirige la S.C. Ingegneria Biomedicale e Sistema Informatico del
ospedale di Pordenone “S. Maria degli angeli”. E’ socio senior AIIC dall’anno 2010.
AIIC
associazione
italiana
ingegneri clinici
IL SOFTWARE E LE RETI IT-MEDICALI
NEL CONTESTO SANITARIO
IL SOFTWARE E LE RETI IT-MEDICALI
NEL CONTESTO SANITARIO
AIIC
associazione
italiana
ingegneri clinici
Ing. Sergio Gargiulo
Collaboratore AIIC per la stesura del volume
Laureato in ingegneria biomedica presso l’Università degli
studi di Napoli Federico II, già collaboratore dell’Associazione
Italiana Ingegneri Clinici è socio della stessa dall’anno 2012.
Attualmente svolge attività libero professionale come Ingegnere Clinico Junior
principalmente presso l’ASL CN1 di Cuneo.
Ing. Giovanni Poggialini
Responsabile Scientifico generale dei corsi del XIV Congresso
Nazionale AIIC – Venezia 2014
Laureato in Ingegneria Biomedica presso il Politecnico di Milano,
inizia immediatamente a lavorare come ingegnere clinico e
biomedico consulente, ruolo che tutt’ora ricopre per diverse aziende, sanitarie e non.
E’ Iscritto all’Albo degli Ingegneri della Provincia di Biella dall’anno 2005, socio
ordinario AIIC dall’anno 2005, referente regionale AIIC per le regioni Piemonte e
Valle d’Aosta dall’anno 2010, componente della commissione sanità della FIOPA
dall’anno 2012, socio ordinario SIHTA dall’anno 2013.
-
e-mail: [email protected]
-
CV: it.linkedin.com/in/gpoggialini/
-
SKYPE: giovanni.poggialini
-
Twitter: @gpoggialini
AIIC
associazione
italiana
ingegneri clinici
Il Software e le Reti IT-Medicali
nel contesto Sanitario
[email protected]
AIIC
associazione
italiana
ingegneri clinici
www.aiic.it
tel: 333.8060876 - fax: 06.96681277
Twitter: @AIIC_IngClinici