Progetto in inchiesta pubblica PROGETTO C

Transcript

1 N O R M A I T A L I A N A C E I 1 Data Scadenza Inchiesta C Data Pubblicazione Classificazione 62-. Titolo Guida alla gestione del software e delle reti IT medicali nel contesto sanitario Parte 1: Gestione del software Title CEI COMITATO ELETTROTECNICO ITALIANO AEIT FEDERAZIONE ITALIANA DI ELETTROTECNICA, ELETTRONICA, AUTOMAZIONE, INFORMATICA E TELECOMUNICAZIONI CNR CONSIGLIO NAZIONALE DELLE RICERCHE PROGETTO

2 INDICE 1 Scopo Avvertenza Applicabilità Documenti di riferimento Legislazione applicabile Guide e norme specifiche di prodotto Guide alla legislazione applicabile Altri documenti internazionali Definizioni Approccio metodologico Identificazione del software Fattori rilevanti nella identificazione del Software Classificazione specifica del Software DISPOSITIVO MEDICO secondo Direttiva 2007/47/CE Processi operativi di gestione del software Istituzione del Fascicolo di prodotto/sistema Verifiche in fase di collaudo o messa in servizio Manutenzione e rivalutazione periodica dei software/sistemi utilizzati nel contesto sanitario Dismissione di un prodotto software Problematiche dei sistemi software: casi particolari Casi particolari: le App Interfacciamento di sistemi Problematiche di dismissione: Gestione dei rischi Sistemi interconnessi: rischi specifici Allegato 1 Esempi di Qualificazione e Classificazione del software

3 1 Scopo Guida alla gestione del software e delle reti IT-medicali nel contesto sanitario Parte 1: Gestione del software Il presente documento vuole essere una guida a supporto delle Organizzazioni Responsabili, per la corretta identificazione, gestione ed utilizzo dei software utilizzati nel contesto sanitario; tale documento si basa sia sulla normativa vigente (relativamente ai decreti legislativi che recepiscono le Direttive Europee, e alle leggi nazionali) che sulle norme tecniche pubblicati dagli Enti di Normazione. Data la grande disponibilità e produzione di documenti regolamentatori e normativi sull argomento, in questa linea guida sono presi come riferimento i documenti elencati al paragrafo 3. Questa guida, nella sua parte prima, si prefigge lo scopo di informare le organizzazioni responsabili in merito ai requisiti che il software DISPOSITIVO MEDICO e il software usato in contesto sanitario dovrebbero avere e che dovrebbero essere richiesti e forniti al/dal fabbricante. Nella parte seconda (oggetto non del presente documento ma di un secondo separato documento) sono considerati gli aspetti inerenti l integrazione di questi software, ed in particolare dei dispositivi medici, nella rete informatica gestita DALL ORGANIZZAZIONE RESPONSABILE. La presente guida analizza i requisiti generali e, per quanto possibile, comuni a tipi diversi di software utilizzati in contesto sanitario prendendo in considerazione sia la grande varietà, in termini di natura, complessità, funzionalità e di rischi associati dei prodotti software oggi disponibili, sia la grande diversità, in termini di dimensione e struttura organizzativa, delle ORGANIZZAZIONI RESPONSABILI cui questa guida è diretta. Dovrebbe essere cura di ciascuna ORGANIZZAZIONE RESPONSABILE elaborare un proprio specifico approccio alla gestione sicura del software nel contesto sanitario, adeguando piani, allocando risorse, apportando le necessarie integrazioni, adattamenti e precisazioni a quanto specificato in questa guida, in funzione della realtà organizzativa esistente e della reale portata del problema affrontato. Il presente documento si propone di delineare un percorso di gestione del software articolato in due fasi: identificazione del software (Capitolo 6) e processi operativi di gestione del software (Capitolo 7). 1.1 Avvertenza Nel contesto di normazione tecnica nel campo dell Information Technology (I.T.) è facile osservare una nutrita proliferazione di termini identificativi. Questa proliferazione, attribuibile anche alla grande diversità culturale dei tanti settori che convergono nell I.T. potrebbe generare delle incertezze, dei conflitti di definizione o sovrapposizioni tra termini definiti in norme diverse. Inoltre il processo di traduzione nelle diverse lingue dei termini identificativi presenti nelle norme può essere assai difficoltoso e generare risultati che potrebbero non essere egualmente condivisibili a seconda del differente contesto culturale e professionale del lettore. 2

4 Un altra possibile fonte di incertezza risiede nel fatto che spesso vengono identificati con un termine unico prodotti in realtà assai diversi: ricadono ad esempio nella comune denominazione di RIS (Radiological Information System) sia prodotti dotati solo di funzionalità molto semplificate di gestione paziente, sia sistemi assai più complessi dotati di funzionalità di supporto alla diagnosi ed alla pianificazione del trattamento. In questi casi non si possono proporre conclusioni valide per tutti i sistemi genericamente denominati RIS, in quanto il termine non è rappresentativo di un archetipo né in nessun modo paradigmatico. Questa eventualità è assai frequente nei prodotti di natura software, dove un sistema può essere facilmente corredato di moduli aggiuntivi o espanso con funzionalità che evolvono nel tempo: si vedano ad esempio sistemi come LIS/WAM (Laboratory Information Systems/Work Area Manager), RIS (Radiological Information System), PACS(Picture archiving and communication system) e EHR (Electronic Health Record). Per questi motivi si raccomanda, nella lettura della presente guida, di porre maggiore attenzione alle caratteristiche degli oggetti che vengono via via descritti piuttosto che al termine specialistico utilizzato per identificarli. 2 Applicabilità La presente guida si applica, per quanto riguarda la sua parte prima, al software utilizzato in contesto sanitario, comprendente Software incorporato in dispositivi medici (vedi Fig. 1 voce D1), Software Stand Alone (vedi Fig. 1 voce D1), Altro Software sanitario (vedi Fig. 1 voce D2-D3-D4) Software non sanitario (vedi Fig. 1 voce C1-C2). Nella parte seconda la guida di applica alla gestione delle connessioni tra dispositivi ed in particolare a: Reti IT Medicali (rete di dati ospedaliera e non), Sistemi di comunicazione tra dispositivi medici anche non forniti da un unico fabbricante 3 Documenti di riferimento 3.1 Legislazione applicabile 1. D.Lgs. 24 febbraio 1997 n. 46 Attuazione della direttiva 93/42/CEE, concernente i dispositivi medici e s.m.i. 2. D.Lgs.14 dicembre 1992 n. 507, Attuazione della direttiva 90/385/CEE concernente il ravvicinamento delle legislazioni degli Stati membri relative ai dispositivi medici impiantabili attivi e s.m.i. 3. D.Lgs. 8 settembre 2000 n. 332, Attuazione della direttiva 98/79/CE relativa ai dispositivi medico-diagnostici in vitro e s.m.i., 4. D.Lgs. 30 giugno 2003, n. 196 "Codice in materia di protezione dei dati personali" e successive modifiche (incluso decreto legislativo 28 maggio 2012, n. 69) [ - doc. web n ] 5. D.Lgs. 21 maggio 2004, n.172 : Attuazione della direttiva n. 2001/95/CE relativa alla sicurezza generale dei prodotti. 6. Direttiva 2007/47/CE del Parlamento Europeo e del Consiglio 3

5 3.2 Guide e norme specifiche di prodotto 1. CEI EN 62304: Software per dispositivi medici - Processi relativi al ciclo di vita del software. 2. CEI EN 62366: Dispositivi medici Applicazione dell ingegneria delle caratteristiche utilizzative ai dispositivi medici. 3. CEI EN : Apparecchi elettromedicali. Parte 1: Norme generali per la sicurezza Norma collaterale: sistemi elettromedicali programmabili. 4. CEI EN : Apparecchi elettromedicali. Parte 1: Prescrizioni generali relative alla sicurezza fondamentale e alle prestazioni essenziali (limitatamente al par. 14). 5. CEI EN : Applicazione della gestione del rischio per reti IT che incorporano dispositivi medicali. Parte 1: Ruoli, responsabilità e attività. 6. ISO/TS 25238: Health informatics -- Classification of safety risks from health software 7. IEC/TR : Medical device software Part 1: Guidance on the application of ISO to medical device software 8. ISO 31000: 2009 Risk management 9. UNI CEN/TS 15260:2006 Informatica sanitaria - Classificazione dei rischi di sicurezza derivanti dai prodotti di informatica sanitaria 10. ISO/TR 17791: Health informatics -- Guidance on standards for enabling safety in health software 11. CEI UNI EN ISO Dispositivi medici. Applicazione della gestione dei rischi ai dispositivi medici. 12. ISO/TR 27809:2007 Health informatics -- Measures for ensuring patient safety of health software 13. IEC/TR : 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 14. IEC/TR : Application of risk management for IT-networks incorporating medical devices Part 2-3: Guidance for wireless networks 15. IEC/TR : Application of risk management for IT-networks incorporating medical devices Part 2-4: Application guidance - General implementation guidance for Healthcare Delivery Organizations 16. IEC/TR : Application of risk management for IT-networks incorporating medical devices Part 2-1: Step by step risk management of medical IT-networks Practical applications and examples 17. ISO/IEC 25010: Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models 3.3 Guide alla legislazione applicabile 1. MEDDEV 2.1/6 (January 2012) MEDICAL DEVICES: Guidance document - Qualification and Classification of standalone software. 2. Prescrizioni del Garante [art. 154, 1 c) del Codice] - 09 novembre 2005: Strutture sanitarie: rispetto della dignità [ - doc. web n ] 4

6 3.4 Altri documenti internazionali 1. Medical Information Systems - guidance for qualification and classification of standalone software with a medical purpose (Lakemedelsverket - Medical Product agency- Svezia) ) NOTA Linea guida svedese nel presente documento 4 Definizioni La presente guida si basa sulle definizioni reperite sia nella legislazione cogente che nelle norme tecniche pertinenti all'informatica in contesto sanitario e ai dispositivi medici. In mancanza di definizioni già pubblicate, la presente guida utilizza definizioni formulate appositamente e valide soltanto nell ambito della guida stessa. Si evidenzia che eventuali discordanze tra definizioni relative allo stesso termine riportate in norme differenti, possono essere dovute ai diversi contesti applicativi a cui si riferiscono le norme o alle diverse interpretazioni del termine stesso; in tali casi è stata adottata la definizione più pertinente ai fini della presente guida, riportando in forma di note le altre. Per ciascuna definizione è stata anche indicata la norma di riferimento, dove la stessa è stata reperita e si sono segnalati gli eventuali adattamenti. 4.1 CONTESTO SANITARIO qualunque luogo, situazione o contesto in cui si svolgono azioni con scopi sanitari diretti o indiretti. Un ospedale (o un locale adibito ad uso medico) è chiaramente un contesto sanitario, ma anche un qualunque luogo (fisico o virtuale) in cui vengano gestiti dati ad uso clinico è un contesto sanitario. 4.2 DISPOSITIVO ATTIVO PER LA DIAGNOSI qualsiasi DISPOSITIVO MEDICO attivo, da solo o in combinazione con altri dispositivi medici, utilizzato per fornire informazioni per il rilevamento, la diagnosi, il monitoraggio o il trattamento di condizioni fisiologiche o stati di salute, malattia o deformazioni congenite. [in MEDDEV 2.1/6 gennaio 2012]. 4.3 DISPOSITIVO MEDICO (DM) qualsiasi strumento, apparato, applicazione, software, materiale o altro articolo, impiegato sia da solo che in combinazione con altri, compreso il software previsto dal fabbricante del dispositivo, per essere utilizzato specificatamente ai fini di diagnosi e/o terapia, e necessario alla sua corretta applicazione, destinato dal costruttore per essere utilizzato su persone, allo scopo di: diagnosi, prevenzione, monitoraggio, trattamento o attenuazione degli effetti di una malattia, diagnosi, monitoraggio, trattamento, riduzione degli effetti o compensazione di una lesione o di un handicap, indagine, sostituzione o modifica dell anatomia o di un processo fisiologico, controllo del concepimento, e che non eserciti la sua azione principale prevista nel o sul corpo umano tramite mezzi farmacologici, immunologici o metabolici, ma che può essere assistito nelle sue funzioni da tali mezzi. [Direttiva 2007/47/CE]. 5

7 NOTA 1 DEFINIZIONE DI DISPOSITIVO MEDICO (in lingua inglese identificato come MEDICAL DEVICE (MD)) fornita nella ISO/PDTR 17791, documento in lavorazione in 62A_859e_DTR, e derivata dal documento Global Harmonization Task Force (GHTF) Study Group 1: 2005: Qualsiasi strumento, apparato, attrezzo, macchina, applicazione, impianto, reagente in vitro o mezzo di calibrazione, software, materiale o altro articolo relativo o similare, previsto dal fabbricante per essere utilizzato, da solo o in combinazione con altri, su persone, per uno o più scopi specifici quali: la diagnosi, la prevenzione, il monitoraggio, il trattamento o l attenuazione degli effetti di una malattia, la diagnosi, il monitoraggio, il trattamento, l attenuazione degli effetti o la compensazione di una lesione, l indagine, la sostituzione, la modifica o il sostegno dell anatomia o di un processo fisiologico, il supporto o il mantenimento in vita, il controllo del concepimento, la disinfezione dei dispositivi medici, fornire informazione a scopi medici o diagnostici attraverso l esame in vitro di campioni prelevati dal corpo umano; e che non esplichi la sua funzione primaria prevista nel o sul corpo umano tramite mezzi farmacologici, immunologici o metabolici, ma che può essere assistita nelle sue funzioni da tali mezzi. NOTA 2 La definizione di un dispositivo per l esame in vitro comprende, per esempio, i reagenti, i mezzi per la calibrazione, la raccolta dei campioni e i dispositivi di immagazzinamento, i materiali di controllo e la strumentazione o gli apparati relativi. Le informazioni fornite da questi dispositivi di diagnostica in vitro possono servire per la diagnosi, il monitoraggio o per la verifica di compatibilità. In alcune giurisdizioni, alcuni dispositivi per la diagnostica in vitro, compresi i reagenti e i prodotti similari, possono essere soggetti a regolamentazione separata. NOTA 3 I prodotti che possono essere considerati dispositivi medici in alcune giurisdizioni, ma per i quali non è stato adottato un approccio armonizzato sono: gli ausili per le persone disabili/portatrici di handicap, i dispositivi per il trattamento/o la diagnosi delle malattie e delle lesioni negli animali, gli accessori per i dispositivi medici (si veda la successiva NOTA 3), le sostanze per la disinfezione e i dispositivi che incorporano tessuti animali ed umani, che possono soddisfare le prescrizioni della definizione di cui sopra, ma che sono soggetti a controlli differenti. NOTA 4: Gli accessori previsti specificatamente dai fabbricanti per essere utilizzati insieme ad un dispositivo base, per permettere a quest ultimo di esplicare il suo scopo previsto, dovrebbero essere sottoposti alle stesse procedure GHTF del DISPOSITIVO MEDICO stesso. Per esempio un accessorio per un DISPOSITIVO MEDICO sarà classificato come DISPOSITIVO MEDICO esso stesso. Questo può comportare che l accessorio abbia una classificazione differente rispetto a quella del dispositivo base. NOTA 5: I componenti dei dispositivi medici sono generalmente controllati dal sistema di gestione della qualità del fabbricante e dalle procedure di valutazione dalla conformità dei dispositivi. In alcune giurisdizioni, i componenti ricadono sotto la definizione di DISPOSITIVO MEDICO. 4.4 DISPOSITIVO MEDICO ATTIVO qualsiasi dispositivo medico il cui funzionamento dipenda da una sorgente di energia elettrica o da una qualsiasi altra sorgente di alimentazione, che non sia generata direttamente dal corpo umano o dalla gravità, e che funziona convertendo tale energia. I dispositivi medici previsti per trasferire energia, sostanze o altri elementi tra il dispositivo medico attivo e il paziente, senza che si verifichi un significativo cambiamento, non sono considerati dispositivi medici attivi. Il software da solo è considerato un dispositivo medico attivo. [Direttiva 93/42/CEE] 4.5 DISPOSITIVO MEDICO IMPIANTABILE ATTIVO qualsiasi dispositivo medico attivo destinato ad essere impiantato interamente o parzialmente mediante intervento chirurgico o medico nel corpo umano o mediante intervento medico in un orifizio naturale e destinato a restarvi dopo l'intervento. (D.Lgs. 14 dicembre 1992, n. 507) 6

8 4.6 DISPOSITIVO MEDICO PER LA DIAGNOSI IN VITRO qualsiasi dispositivo medico che sia un reagente, un prodotto reagente, un mezzo di calibrazione, un materiale di controllo, un equipaggiamento, uno strumento, un apparato, un apparecchiatura o un sistema, quando impiegato in modo indipendente o in combinazione, previsto dal fabbricante per essere utilizzato in vitro per l esame di campioni, inclusi i prelievi di sangue e di tessuti, del corpo umano, esclusivamente o principalmente, allo scopo di fornire informazioni: relative a uno stato fisiologico o patologico, oppure relative ad un anomalia congenita, oppure per determinare la sicurezza e la compatibilità con potenziali destinatari, oppure per il monitoraggio di misure terapeutiche. [in Direttiva 93/42/CEE] 4.7 DISPOSITIVO TERAPEUTICO ATTIVO qualsiasi DISPOSITIVO MEDICO attivo, impiegato sia da solo che in combinazione con altri dispositivi medici, per supportare, modificare, sostituire o ripristinare funzioni o strutture biologiche, allo scopo di trattare o alleviare una malattia, una lesione o un handicap. [in Direttiva 93/42/CEE] 4.8 DOCUMENTAZIONE ANNESSA documento che accompagna un software e che riporta informazioni per l ORGANIZZAZIONE RESPONSABILE e per l operatore in particolare per quanto riguarda la sicurezza fondamentale e le prestazioni essenziali [adattata da CEI def. 3.4] 4.9 FABBRICANTE persona fisica o giuridica che ha la responsabilità del progetto, della fabbricazione, l imballaggio o l etichettatura di un PRODOTTO SOFTWARE, dell assemblaggio di un sistema contenente prodotti software o dell adattamento di un PRODOTTO SOFTWARE, prima che questo venga immesso sul mercato e/o messo in servizio, indipendentemente dal fatto che queste operazioni vengano effettuate da lui direttamente o da terze parti. [da ISO/TR 27809:2007, con sostituzione, per gli scopi della presente guida, di PRODOTTO SOFTWARE SANITARIO con PRODOTTO SOFTWARE ] NOTA Nell ambito dei DISPOSITIVI MEDICI, il Fabbricante viene definito come segue: fabbricante: la persona fisica o giuridica responsabile della progettazione, della fabbricazione, dell'imballaggio e dell'etichettatura di un dispositivo in vista dell'immissione in commercio a proprio nome, indipendentemente dal fatto che queste operazioni siano eseguite da questa stessa persona o da un terzo per suo conto. Gli obblighi del presente decreto che si impongono al fabbricante valgono anche per la persona fisica o giuridica che compone, provvede all'imballaggio, tratta, rimette a nuovo, etichetta uno o più prodotti prefabbricati o assegna loro la destinazione di dispositivo in vista dell'immissione in commercio a proprio nome. I predetti obblighi non si applicano alla persona la quale, senza essere il fabbricante compone o adatta dispositivi già immessi in commercio in funzione della loro destinazione ad un singolo paziente [da D.Lgs. 46/97] 4.10 FASCICOLO DI PRODOTTO/SISTEMA il Fascicolo di prodotto/sistema è una raccolta di documentazione, creata e sistematicamente aggiornata dall ORGANIZZAZIONE RESPONSABILE, riguardante un software o un sistema che è o sarà in esercizio presso l ORGANIZZAZIONE RESPONSABILE. Nel fascicolo vengono registrate le attività inerenti la sicurezza di un prodotto/sistema; e comunque quelle derivanti dagli obblighi ex DPR 14 Gennaio GESTORE DEL RISCHIO DELLA RETE IT MEDICALE persona responsabile della gestione del rischio di una rete IT MEDICALE [nella IEC Ed. 1.0:2010] 7

9 4.12 ORGANIZZAZIONE RESPONSABILE ente responsabile dell uso e della manutenzione di un apparecchio elettromedicale (EM) o di un sistema EM, della rete IT medicale, e del software sanitario. NOTA 1 La definizione è derivata da IEC :Ente responsabile dell uso e della manutenzione di un apparecchio EM o di un sistema EM, e da IEC : Ente responsabile dell uso e della manutenzione della rete IT Medicale NOTA 2 L ORGANIZZAZIONE RESPONSABILE può essere, per esempio, un ospedale, un singolo medico o una persona inesperta. Nelle applicazioni domiciliari, il paziente, l operatore e l ORGANIZZAZIONE RESPONSABILE possono coincidere RETE INFORMATICA (RETE IT) sistema o sistemi costituiti da nodi di comunicazione e collegamenti di trasmissione per permettere la trasmissione attraverso un collegamento fisico o senza fili, tra due o più nodi di comunicazione specificati. [nella IEC :2010] NOTA Lo scopo della rete informatica ai fini della salute è definito dall ORGANIZZAZIONE RESPONSABILE, in funzione di dove il software sanitario è collocato all interno della rete informatica sanitaria e dall uso definito della rete informatica stessa. Essa può contenere un infrastruttura informatica, componenti o sistemi informatici anche per la cura a domicilio per scopi generali e non previsti dal progetto per essere utilizzati in un contesto sanitario RETE IT MEDICALE rete IT che collega almeno un DISPOSITIVO MEDICO. [nella IEC Ed. 1.0:2010] 4.15 SCOPO SANITARIO un azione ha scopo sanitario se viene eseguita al fine di avere, anche in modo indiretto, un effetto o un controllo/monitoraggio sullo stato di salute o più in generale sullo stato fisico, mentale e sociale di uno o più individui. Un prodotto ha scopo sanitario indicato se il Fabbricante ne ha previsto l utilizzo in un azione a scopo sanitario SCOPO MEDICO impiegato sull'uomo specificamente con finalità diagnostiche e/o terapeutiche e destinato 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 (estratta da Direttiva 93/42/CEE) 4.17 SISTEMA struttura composta integrata costituita da uno o più processi, da hardware, software, dispositivi e persone, in grado di soddisfare un bisogno o realizzare un obiettivo dichiarato. [nella IEC 62304:2006 Armonizzata]. NOTA esplicativa : il sistema può essere costituito da un software DISPOSITIVO MEDICO in combinazione con software e hardware OTS (all interno di uno stesso apparato/apparecchiatura) o quando si ha a che fare con un sistema di software e hardware con una combinazione di dispositivi medici e non (le componenti del sistema non sono all interno di un unico apparato/apparecchiatura ma il sistema è costituito da più apparati). Sistemi sono anche tutti i sistemi assemblati e/o comunque creati ad hoc e che possono costituire un pericolo per il paziente. La presenza di un fascicolo di prodotto/sistema è sempre obbligatoria. 8

10 4.18 SOFTWARE: TERMINI CORRELATI I termini concernenti il software sono raggruppati di seguito per una migliore comprensibilità: CLASSIFICAZIONE DEL SOFTWARE processo volto a raggruppare i prodotti in esame in classi omogenee in funzione di caratteristiche predefinite. Relativamente ai DISPOSITIVI MEDICI, la classificazione (MEDDEV 2.4/1 rev. 9) è il processo che identifica per ciascun DISPOSITIVO MEDICO la classe di appartenenza in funzione del livello di rischio (classi I, IIa, IIb, III come definite nell ambito della Direttiva 93/42/CEE e sue successive modifiche ed integrazioni). Nel contesto della presente guida, si è introdotta una nuova classificazione che è intesa come il processo che identifica il gruppo di appartenenza di un software utilizzato in contesto sanitario in base ad elementi quali la destinazione d uso, il contesto di destinazione, l uso effettivo, il contesto d uso ed i possibili effetti sulla salute. Tali gruppi sono indicati nello schema di Figura 1, capitolo 6 della presente guida. NOTA 1 la definizione si applica soltanto all interno di questa guida NOTA 2 La CLASSIFICAZIONE DEL SOFTWARE IN CONTESTO SANITARIO non dispositivo medico è un processo a cura dell organizzazione responsabile, a differenza di quello effettuato sul software dispositivo medico dove è a cura del fabbricante ELEMENTO SOFTWARE qualsiasi parte identificabile di un programma per computer [nella IEC 62304:2006 Armonizzata, e nella ISO/lEC 90003:2004, definizione 3 14, modificata] NOTA Tre termini identificano la scomposizione del software. Il livello più elevato è il SISTEMA SOFTWARE, quello più basso, che non è possibile scomporre ulteriormente, è L UNITÀ SOFTWARE. Tutti i livelli di composizione, compreso il livello alto e quello basso, possono essere indicati come ELEMENTI SOFTWARE. Un SISTEMA SOFTWARE è quindi costituito da uno o più ELEMENTI SOFTWARE e ciascuno di questi è composto da una o più UNITÀ SOFTWARE o in ELEMENTI SOFTWARE a loro volta scomponibili. Al FABBRICANTE è lasciata la responsabilità di fornire le definizioni e il grado di frazionamento degli ELEMENTI SOFTWARE e delle UNITÀ SOFTWARE INFORMATICA PER APPLICAZIONI SANITARIE punto di incontro tra le pratica clinica, la IM/IT (Information management/information technology) (Gestione delle informazioni/tecnologia delle informazioni) e la pratica gestionale ai fini di un miglioramento della salute. [nella ISO/TR 17791, documento in lavorazione nella 62A_859e_DTR] NOTA L informatica per applicazioni sanitarie coinvolge le l applicazione della tecnologia dell informazione per facilitare la creazione e l uso di dati, informazioni e conoscenze legate agli aspetti della salute. L informatica per applicazioni sanitarie permette e supporta tutti gli aspetti dei servizi sanitari [ISO/TC215 Organization task Force Report (draft) adattata da MODELLO DEL CICLO DI VITA DI SVILUPPO DEL SOFTWARE struttura concettuale che copre l arco di vita del software, dalla definizione dei suoi requisiti sino al suo rilascio per la produzione, che: identifica il processo, le attività e i compiti legati allo sviluppo di un prodotto software, descrive la sequenza e il legame tra le attività e i compiti e identifica i punti fermi in corrispondenza dei quali viene verificato il conseguimento dei risultati. NOTA Presente nella EN 62304: 2006 Armonizzata ai sensi della direttiva 93/42 CEE, e basata sulla ISO/IEC 12207:1995, definizione

11 MODULO (si intende modulo software) parte di un software indipendente che svolge solo un sottoinsieme di applicazioni fornite dal software indipendente. [da MEDDEV 2.1/6 - gennaio 2012] NOTA Alcuni software indipendenti possono essere suddivisi in un numero significativo di applicazioni per l utente, dove ciascuna di queste applicazioni è correlata ad un modulo. Alcuni di questi moduli hanno finalità mediche, altri no PRODOTTO COSTITUITO DA SOLO SOFTWARE O SOFTWARE INDIPENDENTE software non previsto per essere incorporato in un altro prodotto al momento della sua commercializzazione o della sua disponibilità. [nella62a/839/cd, futura IEC Ed. 1.0] NOTA 1 Il software indipendente può essere interfacciato o collegato in rete ad altri prodotti, senza per questo essere incorporato in essi. NOTA 2 Quando per l uso previsto di un prodotto sono necessari altri prodotti interfacciati o collegati in rete, questi altri prodotti sono incorporati in esso. NOTA 3 (dalla Direttiva 2007/47/EC): Un software a sé stante, quando espressamente previsto per essere utilizzato per uno o più scopi medici indicati nella definizione di DISPOSITIVO MEDICO, costituisce un DISPOSITIVO MEDICO esso stesso. Il software indipendente per scopi generali, quando utilizzato in un ambiente sanitario, non costituisce un DISPOSITIVO MEDICO. Il software indipendente è qualificato come DISPOSITIVO MEDICO di diagnosi in vitro (IVD) o come accessorio di un IVD, a condizione che soddisfi la definizione di IVD o di suo accessorio, come indicato nella Direttiva 98/79/EC4. NOTA 4 (dal MEDDEV 2.1/6 - gennaio 2012): Il software indipendente può controllare direttamente un apparato (ad esempio per il trattamento radioterapico), può fornire informazioni che attivano decisioni immediate (ad esempio un misuratore della glicemia) o può fornire un supporto agli operatori sanitari (ad esempio l interpretazione di un ECG). Il software indipendente può anche costituire un accessorio di un DISPOSITIVO MEDICO PRODOTTO INFORMATICO PER APPLICAZIONI SANITARIE software nel settore sanitario previsto per fini medici, escluso il software necessario al corretto funzionamento di un DISPOSITIVO MEDICO. [nella UNI CEN/TS 15260:2006] PRODOTTO (SOFTWARE) l intero pacchetto software offerto ad un utilizzatore, comprese le istruzioni per l uso e, quando applicabile, l addestramento. [nella ISO/TR 27809:2007] NOTA 1 Definizione di PRODOTTO SOFTWARE riportata nella CEN EN 62304:2006 Armonizzata, e nella ISO/lEC 12207:1995 definizione 3.26: Insieme dei programmi per computer, di procedure e della possibile documentazione e dati associati PRODOTTO SOFTWARE SANITARIO prodotto Software utilizzato nel contesto sanitario, che può avere effetti sui processi di assistenza e/o sulla salute PROGRAMMA PER COMPUTER un programma per computer è definito come un unità sintattica, conforme alle regole di un particolare linguaggio di programmazione e che è costituito da dichiarazioni e indicazioni o istruzioni necessarie a svolgere ad una certa funzione, compito o risolvere un problema. [nella ISO/IEC :1993 Information technology - Vocabulary Part 1: Fundamental terms] 10

12 QUALIFICAZIONE DEL SOFTWARE processo a cura del responsabile dell immissione in commercio del software, che identifichi che il software sia o non sia un Dispositivo medico (ai sensi della direttiva 93/42/CEE s.m.i.). Qualora non definita, l organizzazione responsabile. Qualora il Fabbricante non dichiari nulla circa la qualificazione del software, l organizzazione responsabile dovrebbe valutare se il software, nell uso effettivo nello specifico CONTESTO SANITARIO, possa venire utilizzato con funzioni da Dispositivo Medico. NOTA: per gli esempi vedere la tabella al paragrafo SOFTWARE GENERICO software che svolge funzionalità adatte a diversi ambiti applicativi e contesti d uso SISTEMA SOFTWARE accolta integrata di elementi software organizzati per svolgere una funzione o un insieme di funzioni specifiche. [nella IEC 62304:2006, 3.27] SOFTWARE DISPONIBILE SUL MERCATO (COMMERCIAL (COTS) OR NON COMMERCIAL (OTS)OFF-THE- SHELF SOFTWARE) un componente software generalmente disponibile che viene utilizzato dal fabbricante, per il quale quest ultimo non possa rivendicare il completo controllo sul ciclo di vita del software. [adattato da: Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices, September 9, 1999] SOFTWARE PER DISPOSITIVO MEDICO sistema software che è stato sviluppato allo scopo di essere incorporato nel DISPOSITIVO MEDICO in fase di sviluppo o che è inteso per uso come DISPOSITIVO MEDICO esso stesso [da: CEI EN 62304, Ed. Prima+Corr CLC:2008]. NOTA 1. Nell ambito della presente guida, il Software per Dispositivo Medico rappresenta un sottogruppo del Software Sanitario NOTA 2. Nel documento CD IEC Ed 1.0 si riporta la seguente definizione Software previsto per essere specificatamente utilizzato incorporato in un DISPOSITIVO MEDICO fisico.. Tale definizione non si accorda con la definizione fornita nel documento CEI EN 62304, Ed. Prima+Corr CLC:2008, in quanto non include il Software che è esso stesso Dispositivo Medico. Si ritiene corretta la definizione fornita nel documento CEI EN 62304, Ed. Prima+Corr CLC:2008 (ed è pertanto adottata nella presente guida), poiché in accordo con quanto introdotto dalla Direttiva 2007/47/EC SOFTWARE SANITARIO software utilizzato nel contesto sanitario che può avere effetti sui processi di assistenza e/o sulla salute. Il software sanitario non comprende al suo interno alcuna apparecchiatura elettrica come parte del prodotto. NOTA 1 la definizione si applica soltanto all interno di questa guida NOTA 2 il SOFTWARE SANITARIO comprende i DISPOSITIVI MEDICI SOFTWARE NOTA 3 ai fini della presente guida, i software privi di fabbricante e/o di documentazione devono essere considerati e trattati come software generico (ai fini della presente guida, i software per i quali non è possibile risalire al fabbricante e/o reperire documentazione sono considerati e trattati come software generico) NOTA 4 DEFINIZIONE DI SOFTWARE SANITARIO (in lingua inglese identificato come HEALTH SOFTWARE (HS)) fornita in 62A/839/CD, derivata dalla IEC Ed. 1.0: Software previsto per essere utilizzato specificatamente allo scopo di mantenere o migliorare la salute di singole persone o per prestare cure. Esso include i prodotti costituiti esclusivamente da software e che non comprendono al loro interno alcuna apparecchiatura elettrica come parte del prodotto. Questi prodotti sono destinati ad essere utilizzati in sistemi per l elaborazione dati per uso generale e sono stati concepiti dal loro fabbricante allo scopo di aiutare nella diagnosi, il trattamento o il monitoraggio di un paziente o per facilitare la compensazione o alleviare malattie, lesioni o disabilità. Si fa osservare che il documento sorgente non è ancora stato pubblicato e che la precedente Norma armonizzata, la EN 62304:2006, non contiene la sopra indicata definizione. 11

13 NOTA 5 DEFINIZIONE DI SOFTWARE SANITARIO fornita in ISO/PDTR 17791, documento in lavorazione nella 62A_859e_DTR: Software utilizzato nel settore sanitario che può avere effetti sull assistenza e la salute di un soggetto in cura SOFTWARE SPECIALISTICO Software in grado di analizzare le informazioni disponibili per generarne nuove specifiche idonee per il suo impiego. [in MEDDEV 2.1/6 gennaio 2012] SOUP (acronimo per Software of Unknown Provenance, ovvero software di provenienza sconosciuta) elemento software precedentemente sviluppato e comunemente disponibile, che non è stato realizzato allo scopo di essere incorporato nel DISPOSITIVO MEDICO (noto anche come "off-theshelf software" ovvero software commercialmente disponibile) o software precedentemente sviluppato per il quale non siano disponibili le informazioni adeguate relative ai processi di sviluppo. [nella IEC 62304:2006 Armonizzata] RUSP (READY FOR USE SOFTWARE PRODUCT) analogo a SOUP (ISO/IEC 25051:2014) UNITA SOFTWARE elemento software che non è suddiviso in altri sotto elementi [IEC 62304:2006 Armonizzata] NOTA le unità software possono essere utilizzate per la gestione della configurazione del software o per le prove VERSIONE indicazione identificativa di un elemento della configurazione [nella IEC 62304:2006 Armonizzata] NOTA 1 La modifica della versione di un prodotto software, che porti ad una nuova VERSIONE, richiede un intervento nella gestione della configurazione del software. NOTA 2 Basata sulla definizione 3.37 della ISO/IEC 12207: Approccio metodologico Un esigenza molto sentita dai responsabili delle strutture sanitarie è quella di conoscere quali siano le più opportune misure di verifica o controllo da mettere in opera per la gestione di elementi software nell'ambito della loro organizzazione. Questo sia perché la natura stessa del software ne rende a volte sfuggente il suo inquadramento all'interno del contesto normativo di settore, sia perché le funzioni esercitate da questi prodotti sono assai complesse, articolate ed, a volte, difficili da comprendere nella loro profondità. La presenza frequente di caratteristiche borderline, di funzionalità trasversali a più settori, le dinamiche - a volte complesse - di introduzione dei prodotti software in sanità (si pensi al caso dei software accessori ad un prodotto, o quelli che consentono l'interscambio dei dati tra sistemi esistenti) e la proliferazione di norme tecniche di riferimento, concorrono a generare una crescente difficoltà nel disegnare un corretto percorso di accettazione e controllo dei sistemi software all'interno delle strutture sanitarie. 1 NOTA Questa definizione include: i) Il software nella sua forma base, compresi i sistemi, gli elementi e le unità (software) (si veda la IEC 62304:2006); ii) i sistemi di codifica associati, i motori di inferenza, gli archetipi e le ontologie; iii) i documenti associati necessari per l implementazione, l uso e il funzionamento del software; iv) il software utilizzato che fornisce benefici o è applicato a qualsiasi aspetto del settore sanitario, comprese tutte le strutture pubbliche e private o le imprese ed i consumatori; v) il software, sia commercialmente che non commercialmente, disponibile. 12

14 Inoltre, il software utilizzato in contesto sanitario deve essere considerato in una prospettiva di sistema ed il relativo processo di gestione del rischio non può essere condotto con completezza qualora il dispositivo risulti isolato dal contesto nel quale viene utilizzato. Pertanto, prescindendo dalla natura del prodotto software e delle intenzioni del suo fabbricante, solamente i responsabili dell'organizzazione sanitaria che siano contemporaneamente in possesso delle necessarie competenze tecniche e di una conoscenza organica dell'organizzazione stessa sono in grado di analizzare, con sufficiente livello di competenza, quali siano le reali conseguenze, in termini di impatto sull organizzazione e possibile impatto sulla salute, dell'utilizzo di un software nella specifica struttura sanitaria. Per questi motivi si è ritenuto utile effettuare una analisi delle principali norme tecniche esistenti/in corso di pubblicazione e tentare di costruire un percorso di identificazione e gestione del software che sia contemporaneamente tecnicamente robusto e sostenibile applicabile nella pratica reale. Per meglio comprendere il significato dei termini utilizzati nel seguito è necessario chiarire quanto segue: nei documenti in italiano i termini health purposes sono stati tradotti con scopi sanitari ; va ricordato che la definizione corretta di health è stato di benessere fisico, mentale e sociale, che non sta ad indicare solamente un assenza di malattia (fonte: Biology & Medicine Dizionario Enciclopedico di scienze biologiche e mediche. Zanichelli, 1995). In base a tale definizione, con scopi sanitari vanno intesi non solo obiettivi prettamente medici (identificati nella definizione di DISPOSITIVO MEDICO come da Direttiva 2007/47/CE), che intervengono sullo stato di salute psico-fisica dell uomo, ma anche obiettivi più generali che mirano al mantenimento del suo benessere fisico, mentale e sociale senza prestare una vera e propria cura medica così come inteso dalla suddetta direttiva. Pertanto, mentre un DISPOSITIVO MEDICO ha necessariamente uno scopo sanitario (condizione necessaria), non è detto che uno scopo sanitario venga raggiunto utilizzando un azione o un prodotto DISPOSITIVO MEDICO (ovvero: avere uno scopo sanitario non è sufficiente ad includere un prodotto nell insieme dei dispositivi medici) Il metodo proposto nella presente guida prevede due fasi successive: a) Identificazione del Software (Qualificazione e Classificazione) b) Individuazione ed implementazione dei processi di gestione del software 6 Identificazione del software L identificazione del software è un processo assai delicato che inizia con il comprendere se il software sotto esame sia o meno un DISPOSITIVO MEDICO ( qualificazione). Nel caso in cui la risposta sia positiva, l identificazione recepisce la classificazione definita dal Fabbricante (classe I, IIa, IIb, III) secondo quanto prescritto dalla legislazione vigente sui dispositivi medici (DLgs n , DLgs n , D.Lgs. n )(vedi anche par 3.1, punti 1,2,3 e D.1 della tassonomia). Poiché questa linea guida analizza anche SW che non sono dispositivi medici, è necessario introdurre una classificazione secondo i criteri contenuti nella tassonomia definita nel seguito. Lo scopo di questa tassonomia è quello di assegnare ciascun software ad una categoria specifica, sulla base di criteri che tengano conto delle caratteristiche del singolo software e delle sue reali modalità di utilizzo nell ORGANIZZAZIONE RESPONSABILE. Ciascuna categoria di software potrà essere gestita in maniera diversa, con controlli e verifiche più o meno stringenti a seconda delle maggiori o minori potenzialità di costituire un rischio per la salute dei pazienti e/o degli operatori. 13

15 La tassonomia comprende sia software classificato come dispositivo medico che software non classificato come tale: Si ricorda al riguardo che l uso improprio di un software NON DISPOSITIVO MEDICO come DISPOSITIVO MEDICO, in quanto rappresenta una potenziale fonte di rischio, dovrebbe essere escluso dal fabbricante in riferimento a quanto previsto dal DECRETO LEGISLATIVO 21 maggio 2004, n.172, attuazione della direttiva n. 2001/95/CE relativa alla sicurezza generale dei prodotti applicando l articolo 3, che cita: Il produttore adotta misure proporzionate in funzione delle caratteristiche del prodotto fornito per consentire al consumatore di essere informato sui rischi connessi al suo uso e per intraprendere le iniziative opportune per evitare tali rischi, compresi il ritiro del prodotto dal mercato, il richiamo e l'informazione appropriata ed efficace dei consumatori. La direttiva sulla sicurezza generale dei prodotti impone parimenti obblighi anche per il distributore nonché regolamenta gli aspetti legati alla responsabilità da prodotti difettosi. In analogia a quanto già previsto dalle normative per apparecchi elettromedicali e per le reti IT-medicali, L ORGANIZZAZIONE RESPONSABILE dovrebbe farsi carico di gestire eventuali rischi che possono derivare dall utilizzo nello specifico contesto del software in esame, rischi che il fabbricante non avrebbe potuto identificare ed opportunamente minimizzare durante le fasi di progetto, sviluppo ed implementazione del prodotto software Sia che il software sia classificato come dispositivo medico, sia che non lo sia, lo scopo dell identificazione è quello di indicare all ORGANIZZAZIONE RESPONSABILE dei percorsi specifici di gestione del software. 6.1 Fattori rilevanti nella identificazione del Software Per qualificare e classificare correttamente il software è necessario prendere in considerazione i seguenti 5 fattori: Destinazione d uso (uso inteso dal Fabbricante) Si tratta delle informazioni rese disponibili dal Fabbricante atte ad identificare lo scopo per il quale un prodotto è fornito. Per i dispositivi medici, ed altre tipologie di prodotti, è obbligo del Fabbricante fornire in maniera esplicita e diretta tale destinazione d uso. Per altri prodotti, se il Fabbricante non ha provveduto ad una esplicita informazione in merito, la destinazione d uso può essere desunta dalle informazioni globali/descrittive fornite dal Fabbricante. Al fine di una corretta qualificazione del software, è importante capire dalla destinazione d uso (o dalle informazioni globali/descrittive fornite dal Fabbricante) se un prodotto abbia uno scopo sanitario indicato, uno scopo generico, o uno scopo che escluda esplicitamente l'utilizzo ai fini sanitari. Per ottenere le informazioni necessarie l OR deve fare riferimento alle norme che obbligano i fornitori a fornire sistemi opportunamente documentati (es. UNI EN ISO 12967) Contesto di destinazione E stabilito dal Fabbricante, che dichiara se il suo prodotto è destinato ad un ambiente particolare (industriale, sanitario, domestico...). In molti casi il contesto di destinazione non è specificato ma si evince dall insieme delle informazioni fornite dal Fabbricante, a partire dallo scopo. Può essere anche specificato in negativo, dichiarando che il prodotto non è destinato a particolari contesti di destinazione. Rilevante è il caso in cui un prodotto sia destinato ad un contesto sanitario, così come il caso in cui il fabbricante abbia escluso l utilizzabilità del suo prodotto nel contesto sanitario. 14

16 6.1.3 Us o effettivo L'uso effettivo di un prodotto software dipende dal contesto d uso in cui viene inserito, dal modo di utilizzazione scelto dal suo utilizzatore e dalle sue caratteristiche (o capacità). Il concetto di uso effettivo fa quindi riferimento all'uso reale che verrà fatto del prodotto software nella specifica organizzazione, indipendentemente dalla eventuale destinazione d'uso o dalle istruzioni fornite dal fabbricante. La corretta individuazione dell'uso effettivo che sarà fatto del prodotto è assolutamente necessaria, in quanto consente di porre in risalto quali siano i possibili effetti sulla salute, gli eventuali rischi da tenere in considerazione e le relative normative applicabili. L'uso effettivo può quindi essere definito solo dall'organizzazione RESPONSABILE che abbia compreso sia le caratteristiche intrinseche del prodotto, sia le esigenze e le volontà dell'utilizzatore finale. La valutazione dell uso effettivo deve comprendere una analisi mirata a stabilire se il software possa o meno assumere scopi sanitari a causa dell uso che ne viene fatto (indipendentemente, cioè, dalle eventuali dichiarazioni del fabbricante. Nel caso di Dispositivo Medico il rispetto della destinazione d uso è imprescindibile Contesto d uso Come per l'uso effettivo, il contesto d'uso fa riferimento al contesto di utilizzo del prodotto, piuttosto che alla situazione ipotizzata dal fabbricante (contesto di destinazione). Va quindi individuato, assieme all'uso, dall'organizzazione RESPONSABILE sanitaria che valuterà, ad esempio, se il prodotto sarà utilizzato in un contesto sanitario o no Pos sibili effetti sulla salute e/o sulla sicurezza Anche questo fattore deve essere valutato dall'organizzazione RESPONSABILE sanitaria. E' probabilmente il fattore che richiede un maggiore impegno nella sua determinazione: va valutato, sulla base dei quattro fattori precedentemente elencati, se un prodotto (utilizzato nello specifico contesto d'uso, nello scenario di uso delineato dall utente) possa avere la capacità di influire, in modo diretto o indiretto, sulla salute o sulla sicurezza degli individui. Vanno tenuti in considerazione tutti i possibili effetti sulla salute, sia voluti che non voluti. E rilevante notare che i primi due fattori (Destinazione d uso e Contesto di destinazione) possono essere definiti solo dal FABBRICANTE e quindi l ORGANIZZAZIONE RESPONSABILE non dovrà fare altro che prenderne nota (nel caso di Dispositivo Medico sussiste l obbligo per il fabbricante). Gli ultimi tre fattori, invece, possono essere definiti solo dall ORGANIZZAZIONE RESPONSABILE. Una volta identificati e documentati questi fattori sarà possibile qualificare il software. Per ogni software sotto analisi, l ORGANIZZAZIONE RESPONSABILE dovrà identificare e documentare i fattori descritti, utilizzando: Le informazioni rese disponibili dal fabbricante (documentazione di prodotto, presentazioni, documentazione contrattuale) Le informazioni (Uso effettivo, Contesto d uso, esistenza di possibili effetti sulla salute e/o sulla sicurezza) che l organizzazione stessa avrà reperito attraverso una indagine interna. 6.2 Classificazione del Software in contesto sanitario Sulla base dei fattori descritti nel paragrafo precedente, il processo di identificazione del software procede con la Classificazione valutando a quale gruppo, secondo la figura seguente, il software sarà associabile. Grazie a questo raggruppamento l ORGANIZZAZIONE RESPONSABILE potrà distinguere i casi in cui (per natura del software o per via del suo utilizzo) il rapporto rischio/beneficio nell uso dovrà essere integralmente valutato dall organizzazione stessa dai casi in cui, per la valutazione di questo rapporto, ci si possa avvalere anche delle valutazioni già effettuate dal fabbricante (software certificato come DISPOSITIVO MEDICO). 15

17 A B C Software Software, con contesto di destinazione sanitario, con scopi sanitari indicati, non dispositivo medico Software usato in contesto sanitario Software con contesto di destinazione sanitario, che non ha scopi sanitari indicati, e che non assume scopi sanitari o capacità di avere un impatto sulla salute, a causa dell'uso che ne viene fatto C1 Software generico, che non assume scopi sanitari, o capacità di avere un impatto sulla salute, a causa dell'uso che ne viene fatto C2 D D1 D2 Software che non assume scopi sanitari Software che ha/assume scopi sanitari Software Dispositivo Medico (Direttive europee dispositivi medici) Software con contesto di destinazione sanitario, senza scopi sanitari indicati, che assume scopi sanitari o capacità di avere un impatto sulla salute a causa dell'uso che ne viene fatto D3 Software generico che assume scopi sanitari o capacità di avere un impatto sulla salute, a causa dell'uso che ne viene fatto D4 Figura 1 Schema di identificazione del software 16 Aumento livello attenzione

18 La presente guida si occupa del software usato in contesto sanitario (Gruppo B) che è un sottoinsieme del generico mondo software. Come principali sottogruppi, nella figura sono evidenziati i software che non assumono (nell utilizzo reale) scopi sanitari (Gruppo C) ed i software che invece assumono (per via del loro utilizzo reale o per diretta dichiarazione del FABBRICANTE) scopi sanitari (Gruppo D) In linea di principio, qualunque software utilizzato in un contesto sanitario dovrebbe trovare un univoco posizionamento nel diagramma precedente. L ordinamento verticale dei gruppi riflette un livello crescente dell attenzione necessaria da parte dell ORGANIZZAZIONE RESPONSABILE nell utilizzo di un software, come dettagliato nel seguito Gruppo C 1 Fanno parte di questo gruppo quei software esplicitamente realizzati dal FABBRICANTE per un contesto di destinazione sanitario, per i quali il FABBRICANTE stesso non ha dichiarato scopi sanitari (o ha dichiarato scopi esplicitamente non sanitari) e che non assumono scopi sanitari o capacità di avere effetti sulla salute, in base all uso effettivo ed il contesto d uso. Per i software appartenenti a questo gruppo, l ORGANIZZAZIONE RESPONSABILE dovrebbe: 1. Effettuare alcune operazioni comuni per tutti i software (recupero documentazione annessa, istituzione di un fascicolo di prodotto/sistema, censimento nell anagrafica di competenza ) 2. Verificare che l uso effettivo ed il contesto d uso siano coerenti con quanto eventualmente specificato dal FABBRICANTE (destinazione d uso e contesto di destinazione) 3. Verificare che, in base all uso effettivo ed il contesto d uso che si ha (o si avrà) nella propria organizzazione, il software non possa assumere scopi sanitari o avere impatto sulla salute Notare come nel caso in cui l uso effettivo (e/o il contesto d uso) non sia pienamente coerente con quanto specificato dal FABBRICANTE (punto 1), si possano verificare le seguenti situazioni: Uso effettivo espressamente vietato dal FABBRICANTE Uso effettivo non espressamente vietato dal FABBRICANTE Uso effettivo non pienamente coerente con la destinazione d uso Informazioni dal FABBRICANTE insufficienti a chiarire la destinazione d uso In tutti questi casi l ORGANIZZAZIONE RESPONSABILE dovrebbe analizzare la situazione e tenendo presente che in questo caso comunque sono esclusi possibili effetti sulla salute, autorizzare o vietare, sotto la propria responsabilità l utilizzo del software secondo l uso effettivo previsto. Il processo di verifica dell uso effettivo ed il razionale dell eventuale autorizzazione in deroga ai criteri di utilizzo indicati dal FABBRICANTE devono essere documentati (si veda procedure paragrafo 8.3). Possono essere esempi di software ricadenti nel gruppo C1: Software per studio medico: modulo di Stampa su ricettario SSN e Personale, modulo planner per appuntamenti, modulo fatturazione, modulo statistiche sulla spesa farmaceutica e su quella per gli esami Software Archivio farmaceutico o prontuario Software per la pianificazione della manutenzione ordinaria della centrale di sterilizzazione Atlanti Medici Elettronici 17

19 6.2.2 Gruppo C 2 Fanno parte di questo gruppo quei software per i quali il FABBRICANTE non ha indicato una specifica destinazione d'uso legata a scopi sanitari diretti o indiretti, né ha indicato un contesto di destinazione sanitario e che non assumono scopi sanitari o capacità di avere effetti sulla salute, in base all uso effettivo ed il contesto d uso. Per i software appartenenti a questo gruppo, l ORGANIZZAZIONE RESPONSABILE dovrebbe: 1. Effettuare alcune operazioni comuni per tutti i software (recupero documentazione annessa, istituzione di un fascicolo di prodotto/sistema, censimento nell anagrafica di competenza ) 2. Verificare che l uso effettivo ed il contesto d uso non siano stati esplicitamente esclusi dal Fabbricante 3. Verificare che, in base all uso effettivo ed il contesto d uso che si ha (o si avrà) nella propria organizzazione, il software non possa assumere scopi sanitari o avere impatto sulla salute L ORGANIZZAZIONE RESPONSABILE dovrebbe analizzare la situazione e tenendo presente che in questo caso comunque sono esclusi possibili effetti sulla salute, vietare o autorizzare, sotto la propria responsabilità l utilizzo del software secondo l uso effettivo previsto, inibendo l utilizzo di quei software per il quali il processo di analisi di cui al punto 2 possa avere dei margini di incertezza non trascurabili (si veda paragrafo 8.3). Il processo di verifica dell uso effettivo ed il razionale dell eventuale autorizzazione (anche in deroga ai criteri di utilizzo indicati dal FABBRICANTE laddove lo stesso abbia esplicitamente escluso l utilizzo in contesto sanitario) debbono essere documentati (si veda paragrafo 8.3). In particolare, nel caso di contesto sanitario esplicitamente escluso dal FABBRICANTE, nel razionale dell autorizzazione in deroga dovrà essere compreso: il razionale dell esclusione da parte del FABBRICANTE, qualora disponibile le motivazioni per cui tale esclusione sia superabile nella specifica situazione in esame. Possono essere esempi di software ricadenti nel gruppo C2: word processor per scrivere e stampare un referto. Se c'è anche l'archiviazione no (C4) l'utilizzo di un foglio di calcolo per il mantenimento della schedulazione dei turni del personale di reparto, o la gestione delle esenzioni utilizzo di un software di elaborazione delle immagini per adattare le foto identificative dei pazienti alle schede della gestione anagrafica, per puri scopi identificativi* utilizzo di un CAD per la mappatura degli ambienti e degli impianti ospedalieri sistema informativo ospedaliero Gruppo D1 Fanno parte di questo gruppo i software dichiarati dal FABBRICANTE come dispositivi medici, o diagnostici in vitro, indipendentemente dalla classe di rischio a cui appartengono secondo la Classificazione stabilita in base alle Direttive di settore (Direttive 93/42/CEE, 98/79/CEE e loro successive modifiche ed integrazioni). Per i prodotti appartenenti a questo gruppo: esiste, ed è ben identificato un FABBRICANTE il fabbricante, in base alle suddette Direttive, ha dichiarato che il software è un dispositivo medico. 18

20 Per i software appartenenti a questo gruppo, l ORGANIZZAZIONE RESPONSABILE dovrebbe 1. Effettuare alcune operazioni comuni per tutti i software (recupero documentazione annessa, istituzione di un fascicolo di prodotto/sistema, censimento nell anagrafica di competenza ) 2. Richiedere la copia della dichiarazione di conformità alla direttiva 93/42 e s.m.i. 3. Verificare che il fabbricante abbia reso disponibile e chiaramente comprensibile la destinazione d uso e che la stessa sia a disposizione dell ORGANIZZAZIONE RESPONSABILE 4. Verificare che l uso effettivo ed il contesto d uso che si ha (o si avrà) nella propria organizzazione siano coerenti con la destinazione d uso 5. Verificare che, in base all uso effettivo ed il contesto d uso che si ha (o si avrà) nella propria organizzazione, il software non venga messo in esercizio in condizioni che il FABBRICANTE possa non aver previsto (o non documentato). Particolare attenzione dovrebbe essere posta alla interazione con altri software. Il processo di verifica dell uso effettivo dovrebbe essere documentato. Nel caso in cui la verifica al punto 3 abbia esito negativo è necessario che, prima della messa in esercizio del software, il FABBRICANTE, congiuntamente con l ORGANIZZAZIONE RESPONSABILE, effettui una analisi del rischio suppletiva che copra le eventuali carenze rilevate, utilizzando anche informazioni fornite dall organizzazione (si veda paragrafo 8.3). Questo processo deve essere documentato. La possibilità di utilizzare o meno il software secondo l uso effettivo previsto dall ORGANIZZAZIONE RESPONSABILE dipenderà dall esito della precedente analisi. In particolare, se il fabbricante non ha previsto né adeguatamente gestito importanti rischi introdotti dall uso effettivo indicato dall ORGANIZZAZIONE RESPONSABILE, la stessa, prima che di mettere in esercizio il software, dovrebbe richiedere al fabbricante di modificare ed aggiornare il proprio fascicolo tecnico (se del caso anche facendo valutare all eventuale Ente Notificato l entità di tali modifiche) secondo la normativa vigente; se ciò non avviene, l ORGANIZZAZIONE RESPONSABILE dovrà tenere conto del fatto che per l uso effettivo ipotizzato il software non è più DISPOSITIVO MEDICO (ed effettuare le valutazioni del paragrafo 8.3). Possono essere esempi di software ricadenti nel gruppo: qualunque software che controlla o è contenuto in un dispositivo medico sistemi di cartelle cliniche elettroniche (qualora non siano un mero sostituto, del tutto equivalente, della cartella clinica cartacea, ma siano dotati di funzionalità che ricadono nell elenco delle funzionalità di un DISPOSITIVO MEDICO) i sistemi PACS (quando dotati di funzionalità che ricadono nell elenco delle funzionalità di un DISPOSITIVO MEDICO) i sistemi LIS (quando dotati di funzionalità che ricadono nell elenco delle funzionalità di un DISPOSITIVO MEDICO) RIS sistemi di telemedicina sistemi web per il monitoraggio dei dati La tabella del paragrafo 6.4 elenca una completa tassonomia di software qualificati come Dispositivi Medici e la loro classificazione in base sia alla MED DEV 2.1/6 che in base alla linea guida svedese. In qualche situazione sono state inserite alcune note esplicative. 19