Progetto in inchiesta pubblica PROGETTO C

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Progetto in inchiesta pubblica PROGETTO C. 1134 31-10-2014"

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) [www.garanteprivacy.it - 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à [www.garanteprivacy.it - 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

explora consulting s.r.l. Via Case Rosse, 35-84131 SALERNO - tel 089 848073 fax 089 384582 www.exploraconsulting.it info@exploraconsulting.

explora consulting s.r.l. Via Case Rosse, 35-84131 SALERNO - tel 089 848073 fax 089 384582 www.exploraconsulting.it info@exploraconsulting. explora consulting s.r.l. Via Case Rosse, 35-84131 SALERNO - tel 089 848073 fax 089 384582 www.exploraconsulting.it info@exploraconsulting.it Procedura di gestione per Laboratori di Analisi Cliniche Pag.

Dettagli

ATTUAZIONE DELLA DIRETTIVA 93/42/CEE CONCERNENTE I DISPOSITIVI MEDICI. (omissis)

ATTUAZIONE DELLA DIRETTIVA 93/42/CEE CONCERNENTE I DISPOSITIVI MEDICI. (omissis) Decreto lgs. 24 febbraio 1997, n. 46 emendato col D. lgs. 25.01.2010, n.37 - Recepimento Direttiva 2007/47/CE ATTUAZIONE DELLA DIRETTIVA 93/42/CEE CONCERNENTE I DISPOSITIVI MEDICI IL PRESIDENTE DELLA REPUBBLICA

Dettagli

GESTIONE DEL RISCHIO NEI DISPOSITIVI MEDICI: DALLA CLASSIFICAZIONE ALLA COMMERCIALIZZAZIONE

GESTIONE DEL RISCHIO NEI DISPOSITIVI MEDICI: DALLA CLASSIFICAZIONE ALLA COMMERCIALIZZAZIONE 1 GESTIONE DEL RISCHIO NEI DISPOSITIVI MEDICI: DALLA CLASSIFICAZIONE ALLA COMMERCIALIZZAZIONE Ing. Enrico Perfler Eudax s.r.l. Milano, 23 Gennaio 2014 Indice 2 Il concetto di rischio nei dispositivi medici

Dettagli

Incontro con ASSOBIOMEDICA Roma, 07 maggio 2012

Incontro con ASSOBIOMEDICA Roma, 07 maggio 2012 Il sistema BD/RDM: integrazione dei Dispositivi medico diagnostici in vitro La rilevazione degli IVD Incontro con ASSOBIOMEDICA Roma, 07 maggio 2012 Agenda Le attuali modalità di notifica per i dispositivi

Dettagli

REGOLAMENTO DI ORGANIZZAZIONE E FUNZIONAMENTO DEL DIPARTIMENTO AD ATTIVITA INTEGRATA (DAI) DI MEDICINA INTERNA

REGOLAMENTO DI ORGANIZZAZIONE E FUNZIONAMENTO DEL DIPARTIMENTO AD ATTIVITA INTEGRATA (DAI) DI MEDICINA INTERNA REGOLAMENTO DI ORGANIZZAZIONE E FUNZIONAMENTO DEL DIPARTIMENTO AD ATTIVITA INTEGRATA (DAI) DI MEDICINA INTERNA Art. 1 Finalità e compiti del Dipartimento ad attività integrata (DAI) di Medicina Interna

Dettagli

Ministero del Lavoro, della Salute e delle Politiche Sociali

Ministero del Lavoro, della Salute e delle Politiche Sociali Ministero del Lavoro, della Salute e delle Politiche Sociali DIPARTIMENTO DELLA QUALITA DIREZIONE GENERALE DELLA PROGRAMMAZIONE SANITARIA E DEI LIVELLI DI ASSISTENZA E DEI PRINCIPI ETICI DI SISTEMA UFFICIO

Dettagli

Decreto 10 ottobre 2008 (G.U. Serie Generale n. 288 del 10 dicembre 2008)

Decreto 10 ottobre 2008 (G.U. Serie Generale n. 288 del 10 dicembre 2008) Decreto 10 ottobre 2008 (G.U. Serie Generale n. 288 del 10 dicembre 2008) Disposizioni atte a regolamentare l'emissione di aldeide formica da pannelli a base di legno e manufatti con essi realizzati in

Dettagli

IT FINANCIAL MANAGEMENT

IT FINANCIAL MANAGEMENT IT FINANCIAL MANAGEMENT L IT Financial Management è una disciplina per la pianificazione e il controllo economico-finanziario, di carattere sia strategico sia operativo, basata su un ampio insieme di metodologie

Dettagli

Relazione sul data warehouse e sul data mining

Relazione sul data warehouse e sul data mining Relazione sul data warehouse e sul data mining INTRODUZIONE Inquadrando il sistema informativo aziendale automatizzato come costituito dall insieme delle risorse messe a disposizione della tecnologia,

Dettagli

Mappa degli standard: stato dell arte ed orientamenti

Mappa degli standard: stato dell arte ed orientamenti Mappa degli standard: stato dell arte ed orientamenti Domenico Natale AB Medica Versione 1 Riunione della Commissione UNINFO Informatica Medica Milano, 30 Settembre 2013 Introduzione La presente nota intende

Dettagli

DAT@GON. Gestione Gare e Offerte

DAT@GON. Gestione Gare e Offerte DAT@GON Gestione Gare e Offerte DAT@GON partecipare e vincere nel settore pubblico La soluzione sviluppata da Revorg per il settore farmaceutico, diagnostico e di strumentazione medicale, copre l intero

Dettagli

V I V E R E L ' E C C E L L E N Z A

V I V E R E L ' E C C E L L E N Z A VIVERE L'ECCELLENZA L'ECCELLENZA PLURIMA Le domande, come le risposte, cambiano. Gli obiettivi restano, quelli dell eccellenza. 1995-2015 Venti anni di successi dal primo contratto sottoscritto con l Istituto

Dettagli

Definizione di Dispositivo Medico

Definizione di Dispositivo Medico Definizione di Dispositivo Medico Vs Cosmetico Vs prodotto farmaceutico Vs Biocida Vs DPI Definizione di dispositivo medico Qualsiasi strumento,apparecchio, impianto, sostanza od altro prodotto, utilizzato

Dettagli

Procedure tecniche da seguire nel caso di sollevamento persone con attrezzature non previste a tal fine

Procedure tecniche da seguire nel caso di sollevamento persone con attrezzature non previste a tal fine Procedure tecniche da seguire nel caso di sollevamento persone con attrezzature non previste a tal fine INDICE 1. Premessa 2. Scopo della procedura e campo di applicazione 3. Definizioni 4. indicazioni

Dettagli

DIRETTIVE COMUNITARIE INTERESSATE DAL REGOLAMENTO

DIRETTIVE COMUNITARIE INTERESSATE DAL REGOLAMENTO DIRETTIVE COMUNITARIE INTERESSATE DAL REGOLAMENTO 1. Direttiva 66/401/CEE: commercializzazione sementi di piante foraggere 2. Direttiva 66/402/CEE: commercializzazione di sementi di cereali 3. Direttiva

Dettagli

Convenzione per la protezione dei diritti dell uomo e la dignità dell essere umano riguardo alle applicazioni della biologia e della medicina

Convenzione per la protezione dei diritti dell uomo e la dignità dell essere umano riguardo alle applicazioni della biologia e della medicina Traduzione 1 Convenzione per la protezione dei diritti dell uomo e la dignità dell essere umano riguardo alle applicazioni della biologia e della medicina (Convenzione sui diritti dell uomo e la biomedicina)

Dettagli

REGOLAMENTO DEI DIPARTIMENTI AD ATTIVITA INTEGRATA (DAI) DELL'AZIENDA OSPEDALIERA - UNIVERSITA' DI PADOVA. Premessa

REGOLAMENTO DEI DIPARTIMENTI AD ATTIVITA INTEGRATA (DAI) DELL'AZIENDA OSPEDALIERA - UNIVERSITA' DI PADOVA. Premessa REGOLAMENTO DEI DIPARTIMENTI AD ATTIVITA INTEGRATA (DAI) DELL'AZIENDA OSPEDALIERA - UNIVERSITA' DI PADOVA Premessa La struttura dipartimentale rappresenta il modello ordinario di gestione operativa delle

Dettagli

COME E FATTA E COME DEVE ESSERE APPOSTA

COME E FATTA E COME DEVE ESSERE APPOSTA COME E FATTA E COME DEVE ESSERE APPOSTA E composta dalla sigla CE e, nel caso un Organismo Notificato debba intervenire nella fase del controllo della produzione, contiene anche il numero d identificazione

Dettagli

Legame fra manutenzione e sicurezza. La PAS 55

Legame fra manutenzione e sicurezza. La PAS 55 Gestione della Manutenzione e compliance con gli standard di sicurezza: evoluzione verso l Asset Management secondo le linee guida della PAS 55, introduzione della normativa ISO 55000 Legame fra manutenzione

Dettagli

LA DOCUMENTAZIONE INFERMIERISTICA. Obiettivi della giornata. Obiettivi del progetto

LA DOCUMENTAZIONE INFERMIERISTICA. Obiettivi della giornata. Obiettivi del progetto LA DOCUMENTAZIONE INFERMIERISTICA Obiettivi della giornata Conoscere i presupposti normativi, professionali e deontologici della documentazione del nursing Conoscere gli strumenti di documentazione infermieristica

Dettagli

Condizioni Generali Parte II - Servizi di Borsa Italiana

Condizioni Generali Parte II - Servizi di Borsa Italiana Condizioni Generali Parte II - Servizi di Borsa Italiana 1. Definizioni 1.1 I termini con la lettera iniziale maiuscola impiegati nelle presenti Condizioni Generali Parte II si intendono usati salvo diversa

Dettagli

STUDI CLINICI 1. Che cosa è uno studio clinico e a cosa serve? 2. Come nasce la sperimentazione clinica e che tipi di studi esistono?

STUDI CLINICI 1. Che cosa è uno studio clinico e a cosa serve? 2. Come nasce la sperimentazione clinica e che tipi di studi esistono? STUDI CLINICI 1. Che cosa è uno studio clinico e a cosa serve? Si definisce sperimentazione clinica, o studio clinico controllato, (in inglese: clinical trial), un esperimento scientifico che genera dati

Dettagli

PROTOCOLLO. Prevenzione, Sorveglianza e Controllo delle Infezioni Correlate all Assistenza: attivazione e funzionamento dei relativi organismi.

PROTOCOLLO. Prevenzione, Sorveglianza e Controllo delle Infezioni Correlate all Assistenza: attivazione e funzionamento dei relativi organismi. Pagina 1 di 14 SOMMARIO Sommario...1 Introduzione...2 1. Scopo...2 2. campo di applicazione...3 3 Riferimenti...3 3.1 Riferimenti esterni...3 3.2 Riferimenti interni...3 4. Abbreviazioni utilizzate...4

Dettagli

FARMACI DI IMPORTAZIONE PARALLELA

FARMACI DI IMPORTAZIONE PARALLELA FARMACI DI IMPORTAZIONE PARALLELA Anna Rosa Marra, Ugo Santonastaso (Ufficio Valutazione e Autorizzazione, Agenzia Italiana del Farmaco) Cosa significa farmaco di importazione parallela Il farmaco, come

Dettagli

Schema Professionista della Security Profilo Senior Security Manager - III Livello

Schema Professionista della Security Profilo Senior Security Manager - III Livello STATO DELLE REVISIONI rev. n SINTESI DELLA MODIFICA DATA 0 05-05-2015 VERIFICA Direttore Qualità & Industrializzazione Maria Anzilotta APPROVAZIONE Direttore Generale Giampiero Belcredi rev. 0 del 2015-05-05

Dettagli

Misurazione e monitoraggio della complessità assistenziale Monitoraggio dei livelli ottimali di staffing Strumenti disponibili e tendenze

Misurazione e monitoraggio della complessità assistenziale Monitoraggio dei livelli ottimali di staffing Strumenti disponibili e tendenze Misurazione e monitoraggio della complessità assistenziale Monitoraggio dei livelli ottimali di staffing Strumenti disponibili e tendenze Filippo Festini Università di Firenze, Dipartimento di Pediatria,

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

Astra Formedic S.r.l. - Via Piero Portaluppi, 15 20138 Milano Tel. 02.580011 Email: info.astraformedic@ademorigroup.it web : www.astraformedic.

Astra Formedic S.r.l. - Via Piero Portaluppi, 15 20138 Milano Tel. 02.580011 Email: info.astraformedic@ademorigroup.it web : www.astraformedic. Astra Formedic S.r.l. - Via Piero Portaluppi, 15 20138 Milano Tel. 02.580011 Email: info.astraformedic@ademorigroup.it web : www.astraformedic.it è un sistema integrato completo di tutti i moduli per eseguire

Dettagli

SERVIZI TRASFUSIONALI REQUISITI MINIMI STRUTTURALI TECNOLOGICI E ORGANIZZATIVI SPECIFICI

SERVIZI TRASFUSIONALI REQUISITI MINIMI STRUTTURALI TECNOLOGICI E ORGANIZZATIVI SPECIFICI Allegato A). Requisiti strutturali, tecnologici e organizzativi minimi per l esercizio delle attività sanitarie dei servizi trasfusionali e delle unità di raccolta del sangue e degli emocomponenti, ai

Dettagli

Guida introduttiva al regolamento CLP

Guida introduttiva al regolamento CLP Guida introduttiva al regolamento CLP Il regolamento CLP è il regolamento (CE) n. 1272/2008 relativo alla classificazione, all etichettatura e all imballaggio delle AVVISO LEGALE Il presente documento

Dettagli

DRG e SDO. Prof. Mistretta

DRG e SDO. Prof. Mistretta DRG e SDO Prof. Mistretta Il sistema è stato creato dal Prof. Fetter dell'università Yale ed introdotto dalla Medicare nel 1983; oggi è diffuso anche in Italia. Il sistema DRG viene applicato a tutte le

Dettagli

Un anno di Open AIFA

Un anno di Open AIFA Il dialogo con i pazienti. Bilancio dell Agenzia Un anno di Open AIFA Un anno di Open AIFA. 85 colloqui, 250 persone incontrate, oltre un centinaio tra documenti e dossier presentati e consultati in undici

Dettagli

LA LEGGE QUADRO 447/95 E I DECRETI ATTUATIVI

LA LEGGE QUADRO 447/95 E I DECRETI ATTUATIVI LA LEGGE QUADRO 447/95 E I DECRETI ATTUATIVI Luca Menini, ARPAV Dipartimento di Vicenza via Spalato, 14-36100 VICENZA e-mail: fisica.arpav.vi@altavista.net 1. INTRODUZIONE La legge 447 del 26/10/95 Legge

Dettagli

Disegnato il percorso di riforma dell'adi per il 2012

Disegnato il percorso di riforma dell'adi per il 2012 Disegnato il percorso di riforma dell'adi per il 2012 martedì, 17 gennaio, 2012 http://www.lombardiasociale.it/2012/01/17/disegnato-il-percorso-di-riforma-delladi-per-il-2012/ L'analisi del Contesto E

Dettagli

La nuova normativa di Farmacovigilanza

La nuova normativa di Farmacovigilanza La nuova normativa di Farmacovigilanza 1 Due nuove disposizioni in materia di farmacovigilanza Pubblicazione sulla Gazzetta ufficiale Europea L 348 del 31 Dic 2010: Regulation (EU) 1235/2010 of the European

Dettagli

Next MMG Semplicità per il mondo della medicina

Next MMG Semplicità per il mondo della medicina 2014 Next MMG Semplicità per il mondo della medicina Documento che illustra le principali caratteristiche di Next MMG EvoluS Srl Corso Unione Sovietica 612/15B 10135 Torino tel: 011.1966 5793/4 info@evolu-s.it

Dettagli

DIRITTI DEI CONSUMATORI

DIRITTI DEI CONSUMATORI DIRITTI DEI CONSUMATORI 1. Quali sono i diritti dei consumatori stabiliti dal Codice del Consumo 2. Qual è la portata della disposizione? 3. Qual è l origine dell elencazione? 4. In che cosa consiste il

Dettagli

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A.

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A. Università di Venezia Corso di Laurea in Informatica Laboratorio di Informatica Applicata Introduzione all IT Governance Lezione 5 Marco Fusaro KPMG S.p.A. 1 CobiT: strumento per la comprensione di una

Dettagli

Il certificato nelle attività fisico-sportive in ambito non agonistico, linee guida della F.I.M.P. ad uso del pediatra convenzionato

Il certificato nelle attività fisico-sportive in ambito non agonistico, linee guida della F.I.M.P. ad uso del pediatra convenzionato F.I.M.P. Federazione Italiana Medici Pediatri Regione Veneto Il certificato nelle attività fisico-sportive in ambito non agonistico, linee guida della F.I.M.P. ad uso del pediatra convenzionato Il Codice

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

IL SETTORE DELL ASSISTENZA E DELL AIUTO DOMICILIARE IN ITALIA

IL SETTORE DELL ASSISTENZA E DELL AIUTO DOMICILIARE IN ITALIA IL SETTORE DELL ASSISTENZA E DELL AIUTO DOMICILIARE IN ITALIA Il settore dell assistenza e dell aiuto domiciliare in Italia L assistenza domiciliare. Che cos è In Italia l assistenza domiciliare (A.D.)

Dettagli

Istruzioni per la compilazione del Piano economico rendicontativo

Istruzioni per la compilazione del Piano economico rendicontativo I MATERIALI FORMATIVI costituiscono un supporto pratico alla rendicontazione dei progetti; la loro funzione principale è quella di mostrare l applicazione delle regole a casi concreti con l ausilio degli

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

Dettagli

Informazione agli impianti di trattamento

Informazione agli impianti di trattamento dell'articolo 11, comma 1, o di conferimento gratuito senza alcun obbligo di acquisto per i RAEE di piccolissime dimensioni ai sensi dell'articolo 11, comma 3; c) gli effetti potenziali sull'ambiente e

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello della Web Application 5 3 Struttura della web Application 6 4 Casi di utilizzo della Web

Dettagli

La suite Dental Trey che semplifica il tuo mondo.

La suite Dental Trey che semplifica il tuo mondo. La suite Dental Trey che semplifica il tuo mondo. impostazioni di sistema postazione clinica studio privato sterilizzazione magazzino segreteria amministrazione sala di attesa caratteristiche UNO tiene

Dettagli

Circolare della Funzione Pubblica n. 5 del 21 novembre 2013 sul DL 101/2013

Circolare della Funzione Pubblica n. 5 del 21 novembre 2013 sul DL 101/2013 Circolare della Funzione Pubblica n. 5 del 21 novembre 2013 sul DL 101/2013 La circolare del dipartimento funzione pubblica esplicativa dell articolo 4 del Decreto Legge n. 101 del 31 agosto 2013, convertito

Dettagli

2. Cos è una buona pratica

2. Cos è una buona pratica 2. Cos è una buona pratica Molteplici e differenti sono le accezioni di buona pratica che è possibile ritrovare in letteratura o ricavare da esperienze di osservatori nazionali e internazionali. L eterogeneità

Dettagli

ISTITUTI PROFESSIONALI

ISTITUTI PROFESSIONALI ISTITUTI PROFESSIONALI Settore Industria e Artigianato Indirizzo Manutenzione e assistenza tecnica Nell indirizzo Manutenzione e assistenza tecnica sono confluiti gli indirizzi del previgente ordinamento

Dettagli

Raccordo tra VAS-VIA-VIC (Valutazione ambientale, Valutazione di impatto ambientale, Valutazione di incidenza)

Raccordo tra VAS-VIA-VIC (Valutazione ambientale, Valutazione di impatto ambientale, Valutazione di incidenza) Allegato 2 Raccordo tra VAS-VIA-VIC (Valutazione ambientale, Valutazione di impatto ambientale, Valutazione di incidenza) Sono molto frequenti le situazioni in cui l obbligo di effettuare valutazioni ambientali

Dettagli

Circolare n. 64 del 15 gennaio 2014

Circolare n. 64 del 15 gennaio 2014 Circolare n. 64 del 15 gennaio 2014 Ordinativo informatico locale - Revisione e normalizzazione del protocollo sulle regole tecniche ed obbligatorietà dell utilizzo nei servizi di tesoreria PREMESSA L

Dettagli

LA NORMATIVA DI RIFERIMENTO: ASPETTI DI MAGGIOR RILIEVO E RICADUTE OPERATIVE

LA NORMATIVA DI RIFERIMENTO: ASPETTI DI MAGGIOR RILIEVO E RICADUTE OPERATIVE DATI E INFORMAZIONI DI INTERESSE AMBIENTALE E TERRITORIALE Terza sessione: IL CONTESTO NORMATIVO, L ORGANIZZAZIONE, GLI STRUMENTI LA NORMATIVA DI RIFERIMENTO: ASPETTI DI MAGGIOR RILIEVO E RICADUTE OPERATIVE

Dettagli

Progetto VALUTAZIONE DELLE PERFORMANCE

Progetto VALUTAZIONE DELLE PERFORMANCE Direzione Generale per le Politiche Attive e Passive del Lavoro Progetto VALUTAZIONE DELLE PERFORMANCE Controlli interni e Ciclo della performance alla luce dell art.3 del D.L. 174/2012 Position Paper

Dettagli

CIRCOLARE N. 21/E. Roma, 10 luglio 2014

CIRCOLARE N. 21/E. Roma, 10 luglio 2014 CIRCOLARE N. 21/E Direzione Centrale Normativa Roma, 10 luglio 2014 OGGETTO: Fondi di investimento alternativi. Articoli da 9 a 14 del decreto legislativo 4 marzo 2014, n. 44 emanato in attuazione della

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

REaD REtina and Diabetes

REaD REtina and Diabetes Progetto ECM di formazione scientifico-pratico sulla retinopatia diabetica REaD REtina and Diabetes S.p.A. Via G. Spadolini 7 Iscrizione al Registro delle 20141 Milano - Italia Imprese di Milano n. 2000629

Dettagli

CIRCOLARE N. 1/E. Roma, 9 febbraio 2015

CIRCOLARE N. 1/E. Roma, 9 febbraio 2015 CIRCOLARE N. 1/E Direzione Centrale Normativa Roma, 9 febbraio 2015 OGGETTO: IVA. Ambito soggettivo di applicazione del meccanismo della scissione dei pagamenti Articolo 1, comma 629, lettera b), della

Dettagli

Per IMPRESE/SOCIETA. Presentata dalla Impresa

Per IMPRESE/SOCIETA. Presentata dalla Impresa MARCA DA BOLLO DA 14,62 Per IMPRESE/SOCIETA DOMANDA DI PARTECIPAZIONE ALL AUTORITA PER LA VIGILANZA SUI CONTRATTI PUBBLICI DI LAVORI, SERVIZI E FORNITURE Via di Ripetta, 246 00186 - Roma CIG 03506093B2

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

(Lombardia, BUR 18 novembre 2014, n. 47) LA GIUNTA REGIONALE

(Lombardia, BUR 18 novembre 2014, n. 47) LA GIUNTA REGIONALE Deliberazione Giunta Regionale 14 novembre 2014 n. 10/2637 Determinazioni in ordine a: "Promozione e coordinamento dell'utilizzo del patrimonio mobiliare dismesso dalle strutture sanitarie e sociosanitarie

Dettagli

Ministero della Salute Agenzia Italiana del Farmaco

Ministero della Salute Agenzia Italiana del Farmaco Ministero della Salute Agenzia Italiana del Farmaco Linee guida per la classificazione e conduzione degli studi osservazionali sui farmaci IL DIRETTORE GENERALE VISTO il Decreto del Ministero della Salute

Dettagli

Classificazioni dei sistemi di produzione

Classificazioni dei sistemi di produzione Classificazioni dei sistemi di produzione Sistemi di produzione 1 Premessa Sono possibili diverse modalità di classificazione dei sistemi di produzione. Esse dipendono dallo scopo per cui tale classificazione

Dettagli

MINISTERO DELLA SALUTE

MINISTERO DELLA SALUTE b) unica prova orale su due materie, il cui svolgimento è subordinato al superamento della prova scritta: una prova su deontologia e ordinamento professionale; una prova su una tra le seguenti materie

Dettagli

Tiziano Bettati, Maria Teresa Pacchioli Centro Ricerche Produzioni Animali

Tiziano Bettati, Maria Teresa Pacchioli Centro Ricerche Produzioni Animali Il Divulgatore n.10/2002 Sicurezza alimentare PARTENDO DALLA DOP Tr@ce.pig è un progetto di tracciabilità della filiera del suino pesante utilizzato come materia prima per i Prosciutti di Parma a Denominazione

Dettagli

IL BUDGET DEGLI INVESTIMENTI E IL BUDGET ECONOMICO. dott.ssa Annaluisa Palma 1

IL BUDGET DEGLI INVESTIMENTI E IL BUDGET ECONOMICO. dott.ssa Annaluisa Palma 1 IL BUDGET DEGLI INVESTIMENTI E IL BUDGET ECONOMICO dott.ssa Annaluisa Palma 1 Indice Il budget: documenti amministrativi in cui si estrinseca; Forma e contenuti del budget degli investimenti; Gli scopi

Dettagli

I permessi brevi (art. 20 del CCNL del 6.7.1995 del personale del comparto Regioni e Autonomie locali) Luglio 2013

I permessi brevi (art. 20 del CCNL del 6.7.1995 del personale del comparto Regioni e Autonomie locali) Luglio 2013 I permessi brevi (art. 20 del CCNL del 6.7.1995 del personale del comparto Regioni e Autonomie locali) Luglio 2013 INDICE Presupposti... 2 Modalità di fruizione... 4 Particolari tipologie di rapporto di

Dettagli

2006 02 09 Sottocomitato per lo schema SCR 2006 02 28 Comitato di Accreditamento COMITATO DI ACCREDITAMENTO. Accreditamento RT-12

2006 02 09 Sottocomitato per lo schema SCR 2006 02 28 Comitato di Accreditamento COMITATO DI ACCREDITAMENTO. Accreditamento RT-12 Via Saccardo, 9 I-20134 MILANO Tel.: + 39 022100961 Fax: + 39 0221009637 Sito Internet: www.sincert.it E-mail: sincert@sincert.it C.F./P.IVA 10540660155 Titolo Sigla RT-12 Revisione 01 Data approvazioni

Dettagli

DECRETO N. 20 del 09.07.2013

DECRETO N. 20 del 09.07.2013 L Assessore DECRETO N. 20 del 09.07.2013 Oggetto: Modifiche al Decreto attuativo del Piano straordinario di eradicazione della Peste Suina Africana. Anni 2012 e 2013. VISTO lo Statuto Speciale della Regione

Dettagli

I N F I N I T Y Z U C C H E T T I WORKFLOW HR

I N F I N I T Y Z U C C H E T T I WORKFLOW HR I N F I N I T Y Z U C C H E T T I WORKFLOW HR WORKFLOW HR Zucchetti, nell ambito delle proprie soluzioni per la gestione del personale, ha realizzato una serie di moduli di Workflow in grado di informatizzare

Dettagli

Il presente documento è conforme all'originale contenuto negli archivi della Banca d'italia

Il presente documento è conforme all'originale contenuto negli archivi della Banca d'italia Il presente documento è conforme all'originale contenuto negli archivi della Banca d'italia Firmato digitalmente da Sede legale Via Nazionale, 91 - Casella Postale 2484-00100 Roma - Capitale versato Euro

Dettagli

(Atti non legislativi) REGOLAMENTI

(Atti non legislativi) REGOLAMENTI 24.12.2013 Gazzetta ufficiale dell Unione europea L 352/1 II (Atti non legislativi) REGOLAMENTI REGOLAMENTO (UE) N. 1407/2013 DELLA COMMISSIONE del 18 dicembre 2013 relativo all applicazione degli articoli

Dettagli

PASSIONE PER L IT PROLAN. network solutions

PASSIONE PER L IT PROLAN. network solutions PASSIONE PER L IT PROLAN network solutions CHI SIAMO Aree di intervento PROFILO AZIENDALE Prolan Network Solutions nasce a Roma nel 2004 dall incontro di professionisti uniti da un valore comune: la passione

Dettagli

Differenze tra le attività di certificazione di prodotto (PRD) e le attività di ispezione (ISP) ed altri schemi di valutazione della conformità

Differenze tra le attività di certificazione di prodotto (PRD) e le attività di ispezione (ISP) ed altri schemi di valutazione della conformità Differenze tra le attività di certificazione di prodotto (PRD) e le attività di ispezione (ISP) ed altri schemi di valutazione della conformità In alcuni casi, le somiglianze apparenti tra le attività

Dettagli

Linea Guida per l Organizzazione di un Sistema Prevenzionale nelle Piccole e Medie Imprese

Linea Guida per l Organizzazione di un Sistema Prevenzionale nelle Piccole e Medie Imprese Linea Guida per l Organizzazione di un Sistema Prevenzionale nelle Piccole e Medie Imprese PRESENTAZIONE Il presente lavoro si propone l obiettivo di fornire un modello organizzativo ispirato ai Sistemi

Dettagli

ELENCO DIRETTIVE DEL NUOVO APPROCCIO CHE PREVEDONO L APPOSIZIONE DELLA MARCATURA CE

ELENCO DIRETTIVE DEL NUOVO APPROCCIO CHE PREVEDONO L APPOSIZIONE DELLA MARCATURA CE ELENCO DIRETTIVE DEL NUOVO APPROCCIO CHE PREVEDONO L APPOSIZIONE DELLA MARCATURA CE PREMESSA La parte IV Titolo I artt. da 102 a 113 del Codice del Consumo costituisce il recepimento nazionale della Direttiva

Dettagli

GESTIONE ATTREZZATURE

GESTIONE ATTREZZATURE SOLUZIONE COMPLETA PER LA GESTIONE DELLE ATTREZZATURE AZIENDALI SWSQ - Solution Web Safety Quality srl Via Mons. Giulio Ratti, 2-26100 Cremona (CR) P. Iva/C.F. 06777700961 - Cap. Soc. 10.000,00 I.V. -

Dettagli

CRITERI PER L ASSEGNAZIONE DI CREDITI ALLE ATTIVITA ECM

CRITERI PER L ASSEGNAZIONE DI CREDITI ALLE ATTIVITA ECM CRITERI PER L ASSEGNAZIONE DI CREDITI ALLE ATTIVITA ECM 1. Introduzione 2. Pianificazione dell attività formativa ECM 3. Criteri per l assegnazione dei crediti nelle diverse tipologie di formazione ECM

Dettagli

Rete Oncologica Piemonte Valle d Aosta

Rete Oncologica Piemonte Valle d Aosta Rete Oncologica Piemonte Valle d Aosta Il CAS (Centro Assistenza Servizi): Aspetti organizzativi e criticità Dott. Vittorio Fusco ASO Alessandria La Rete Oncologica: obiettivi Rispondere all incremento

Dettagli

COMMISSIONE AZIENDALE DEL FARMACO PROCEDURA SULLA PRESCRIZIONE DI FARMACI PER INDICAZIONI NON AUTORIZZATE DALL AGENZIA ITALIANA DEL FARMACO

COMMISSIONE AZIENDALE DEL FARMACO PROCEDURA SULLA PRESCRIZIONE DI FARMACI PER INDICAZIONI NON AUTORIZZATE DALL AGENZIA ITALIANA DEL FARMACO COMMISONE AZIENDALE DEL FAMACO POCEDUA SULLA PESCIZIONE DI FAMACI PE INDICAZIONI N AUTOIZZATE DALL AGENZIA ITALIANA DEL FAMACO 1. SCOPO/OBIETTIVO Informare il Personale Medico dell Aziende Sanitarie della

Dettagli

Indicizzazione terza parte e modello booleano

Indicizzazione terza parte e modello booleano Reperimento dell informazione (IR) - aa 2014-2015 Indicizzazione terza parte e modello booleano Gruppo di ricerca su Sistemi di Gestione delle Informazioni (IMS) Dipartimento di Ingegneria dell Informazione

Dettagli

Codice Deontologico degli psicologi italiani

Codice Deontologico degli psicologi italiani Codice Deontologico degli psicologi italiani Testo approvato dal Consiglio Nazionale dell Ordine nell adunanza del 27-28 giugno 1997 Capo I - Principi generali Articolo 1 Le regole del presente Codice

Dettagli

Disposizioni per garantire l'accesso alle cure palliative e alla terapia del dolore

Disposizioni per garantire l'accesso alle cure palliative e alla terapia del dolore Testo aggiornato al 29 novembre 2011 Legge 15 marzo 2010, n. 38 Gazzetta Ufficiale 19 marzo 2010, n. 65 Disposizioni per garantire l'accesso alle cure palliative e alla terapia del dolore La Camera dei

Dettagli

LAMPADE A VAPORI DI MERCURIO AD ALTA PRESSIONE

LAMPADE A VAPORI DI MERCURIO AD ALTA PRESSIONE Pag. 1 di 20 LAMPADE A VAPORI DI MERCURIO AD ALTA PRESSIONE Funzione Responsabile Supporto Tecnico Descrizione delle revisioni 0: Prima emissione FI 00 SU 0002 0 1: Revisione Generale IN 01 SU 0002 1 2:

Dettagli

GLI INDICATORI COME STRUMENTO PER IL MIGLIORAMENTO DELLA QUALITA ASSISTENZIALE

GLI INDICATORI COME STRUMENTO PER IL MIGLIORAMENTO DELLA QUALITA ASSISTENZIALE GLI INDICATORI COME STRUMENTO PER IL MIGLIORAMENTO DELLA QUALITA ASSISTENZIALE D r. C a r l o D e s c o v i c h U.O.C. Governo Clinico Staff Direzione Aziendale AUSL Bologna Bologna 26 Maggio 2010 INDICATORE

Dettagli

GARANZIA LEGALE DEL VENDITORE

GARANZIA LEGALE DEL VENDITORE GARANZIA LEGALE DEL VENDITORE Tutti i prodotti che compri da Apple, anche quelli non a marchio Apple, sono coperti dalla garanzia legale di due anni del venditore prevista dal Codice del Consumo (Decreto

Dettagli

PRINCIPIO DI REVISIONE INTERNAZIONALE (ISA) N. 210 ACCORDI RELATIVI AI TERMINI DEGLI INCARICHI DI REVISIONE

PRINCIPIO DI REVISIONE INTERNAZIONALE (ISA) N. 210 ACCORDI RELATIVI AI TERMINI DEGLI INCARICHI DI REVISIONE PRINCIPIO DI REVISIONE INTERNAZIONALE (ISA) N. 210 ACCORDI RELATIVI AI TERMINI DEGLI INCARICHI DI REVISIONE (In vigore per le revisioni contabili dei bilanci relativi ai periodi amministrativi che iniziano

Dettagli

Payment Card Industry (PCI) Data Security Standard

Payment Card Industry (PCI) Data Security Standard Payment Card Industry (PCI) Data Security Standard Procedure per la scansione di sicurezza Versione 1.1 Release: settembre 2006 Indice generale Finalità... 1 Introduzione... 1 Ambito di applicazione dei

Dettagli

LISTINO PREZZI ARMADI GESTIONE CHIAVI

LISTINO PREZZI ARMADI GESTIONE CHIAVI LISTI INO PREZZI ARMADI GESTIONE CHIAVI APRILE 2012 APICE Listino Prezzi 04/2012 Indice dei contenuti ARMADI GESTIONE CHIAVI... 3 1. KMS... 4 1.1. ARMADI KMS COMPLETI DI CENTRALINA ELETTRONICA E TOUCH

Dettagli

ORGANIZZAZIONE DEI RIPOSI E DURATA DEL LAVORO NOTTURNO

ORGANIZZAZIONE DEI RIPOSI E DURATA DEL LAVORO NOTTURNO Scheda esplicativa per la trattativa decentrata maggio 2009 ORGANIZZAZIONE DEI RIPOSI E DURATA DEL LAVORO NOTTURNO a cura di Giuseppe Montante e Carlo Palermo componenti la Delegazione trattante nazionale

Dettagli

PROCEDURA DI AUDIT AI TEST CENTER AICA

PROCEDURA DI AUDIT AI TEST CENTER AICA Pag. 1 di 14 PROCEDURA DI AUDIT REVISIONI 1 19/12/2002 Prima revisione 2 07/01/2004 Seconda revisione 3 11/01/2005 Terza revisione 4 12/01/2006 Quarta revisione 5 09/12/2013 Quinta revisione Adeguamenti

Dettagli

B.U. 13 novembre 1998, n. 45, III Suppl. Straord. d.g.r. 2 novembre 1998, n. VI/39305. Adeguamento della V.I.A. Regionale alle Direttive Comunitarie

B.U. 13 novembre 1998, n. 45, III Suppl. Straord. d.g.r. 2 novembre 1998, n. VI/39305. Adeguamento della V.I.A. Regionale alle Direttive Comunitarie B.U. 13 novembre 1998, n. 45, III Suppl. Straord. d.g.r. 2 novembre 1998, n. VI/39305 Adeguamento della V.I.A. Regionale alle Direttive Comunitarie LA GIUNTA REGIONALE Premesso: che con D.P.R. 12 aprile

Dettagli

L idea. 43.252.003.274.489.856.000 combinazioni possibili di cui solo una è quella corretta

L idea. 43.252.003.274.489.856.000 combinazioni possibili di cui solo una è quella corretta Guardare oltre L idea 43.252.003.274.489.856.000 combinazioni possibili di cui solo una è quella corretta I nostri moduli non hanno altrettante combinazioni possibili, ma la soluzione è sempre una, PERSONALIZZATA

Dettagli

ORARI E GIORNI VISITE FISCALI 2014-2015. CAMBIA TUTTO PER I LAVORATORI DIPENDENTI - ECCO COME

ORARI E GIORNI VISITE FISCALI 2014-2015. CAMBIA TUTTO PER I LAVORATORI DIPENDENTI - ECCO COME ORARI E GIORNI VISITE FISCALI 2014-2015. CAMBIA TUTTO PER I LAVORATORI DIPENDENTI - ECCO COME Gli Orari Visite Fiscali 2014 2015 INPS lavoratori assenti per malattia dipendenti pubblici, insegnanti, privati,

Dettagli

Gli Standard hanno lo scopo di:

Gli Standard hanno lo scopo di: STANDARD INTERNAZIONALI PER LA PRATICA PROFESSIONALE DELL INTERNAL AUDITING (STANDARD) Introduzione agli Standard L attività di Internal audit è svolta in contesti giuridici e culturali diversi, all interno

Dettagli

Corretto utilizzo delle soluzioni concentrate di Potassio cloruro. ed altre soluzioni contenenti Potassio

Corretto utilizzo delle soluzioni concentrate di Potassio cloruro. ed altre soluzioni contenenti Potassio cloruro cloruro Data Revisione Redazione Approvazione Autorizzazione N archiviazione 00/00/2010 e Risk management Produzione Qualità e Risk management Direttore Sanitario 1 cloruro INDICE: 1. Premessa

Dettagli

L analisi economico finanziaria dei progetti

L analisi economico finanziaria dei progetti PROVINCIA di FROSINONE CIOCIARIA SVILUPPO S.c.p.a. LABORATORI PER LO SVILUPPO LOCALE L analisi economico finanziaria dei progetti Azione n. 2 Progetti per lo sviluppo locale LA FINANZA DI PROGETTO Frosinone,

Dettagli

RISOLUZIONE N. 13/E. Roma, 20 gennaio 2009

RISOLUZIONE N. 13/E. Roma, 20 gennaio 2009 RISOLUZIONE N. 13/E Roma, 20 gennaio 2009 Direzione Centrale Normativa e Contenzioso OGGETTO: Istanza di interpello Art. 11 Legge 27 luglio 2000, n. 212 Gestore dei Servizi Elettrici, SPA Dpr 26 ottobre

Dettagli

BOARD in Eisai: crescere con il Performance Management

BOARD in Eisai: crescere con il Performance Management BOARD in Eisai: crescere con il Performance Management Gli aspetti maggiormente apprezzabili nell utilizzo di BOARD sono la tempestività nel realizzare ambienti di analisi senza nessun tipo di programmazione

Dettagli

PER IMPRESE/SOCIETA. Presentata dall Impresa

PER IMPRESE/SOCIETA. Presentata dall Impresa PER IMPRESE/SOCIETA DOMANDA DI PARTECIPAZIONE ALL AUTORITÀ NAZIONALE ANTICORRUZIONE Via M.Minghetti 10 00187 Roma CIG 6253408B85 GARA EUROPEA A PROCEDURA APERTA PER L AFFIDAMENTO DEI SERVIZI CONCERNENTI

Dettagli