Come convalidare e assicurare la conformità alle direttive EC e US del software e dell'hardware di...

8/9/2019 Come convalidare e assicurare la conformit alle direttive EC e US del software e dell'hardware di un dispositivo medico

1/40

Come convalidare e assicurare la conformit

alle direttive EC e US del software e

dell'hardware di un dispositivo medico

Ernesto VialeIT Governance & Compliance Manager

Modena, 8 Giugno 2010


2/40

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 2

I servizi della Business UnitIT Governance&Compliance

System Assurance (RAMS e V&V).

Assessment e adeguamento dei processi software rispetto alle

best practice CMMI e SPICE.

Formazione e workshop sugli standard di qualit e sicurezza:IEC 61508, ISO/IEC 62304, CENELEC 50128/6/9, ISO 26262,

RTCA DO-178B.

Miglioramento dei processi diGestione delle Risorse Umane

(People-CMM).

Tutoring e coaching dei Project Manager del Cliente

applicando la metodologia di project managementPRINCE2.


3/40

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 3Modena, 8/6/2010 Skytechnology Confidential 3

High Rely: partner di Skytechnology

HighRelys FDA Compliance Engineering & JumpCert 510(k)Services Covers: Software Testing, Quality Assurance, & Validation

Software Development Processes Checklists

SEI CMMI Capability Maturity Model Integration

FDA 510(k) & PMA

21 CFR Part 820 - Quality System Regulation

21 CFR Part 11 - Electronic Records

High Rely Medical Device services comply with the FDA's510(k) and PMA requirements.


4/40


Agenda

Norme applicabili per lo sviluppo e convalida del software.

Punti di attenzione per lapplicazione delle norme, dal punto

di vista del progettista software.

Approccio integrato alla compliance del software.


5/40


Norme EC e US applicabili

US 21 CFR Part 11ER-ES Management

US 21 CFR Part 820Quality System

Regulation

Guidance for Industry and FDA Staff

General Principles of

Software Validation[Fonte IEC 62304]


6/40


La norma ISO/IEC 62304

Definisce i processi (e.g. manutenzione) del sw lifecycle.

Definisce ad alto livello le attivit e deliverable dei processi. Attivit e deliverable sono funzione della safety class

attribuita al software system/software item(s).

La safety class attribuita ai moduli software a valle della

definizione degli hazard e dei rischi di sistema. La norma prevede che lanalisi dei rischi venga eseguita in

accordo al risk management process della ISO 14971, estesocon i requisiti del software risk management process (cap. 7

della IEC 62304). Ai moduli software che possono contribuire al verificarsi

dellhazard deve essere attribuita una delle 3 safety class sulla

base della severit del danno alle persone o alle cose.


7/40


La norma ISO/IEC 62304

Ai moduli software che implementano misure di controllo deirischi deve essere attribuita una delle 3 safety class sulla basedella severit del danno alla salute delle persone o alle cose.

La norma dichiara che la fase di manutenzione (con tutte lerelative modifiche) ha lo stesso livello di importanza delle fasi

di sviluppo.

Nella definizione dei requisiti architetturali del software,devono essere individuati e marcati i SOUP configurationitem.

Deve essere implementato un workflow che tracci problemi eanomalie del software, sia in fase di sviluppo che dimanutenzione.


8/40


Punti di attenzione

La norma non definisce: ruoli e responsabilit dellorganizzazione (e.g. per quali livelli di test

deve essere garantita lindipendenza dallo sviluppo).

i cicli di vita applicabili, le fasi e le attivit di dettaglio dei processi delsw lifecycle.

i deliverable di fase e i relativi contenuti.

Indicazioni e raccomandazioni possono essere trovate: nella linea guida GAMP dellISPE.

negli standard IEEE di software engineering, citati nelle guidance FDA.

nella norma ISO/IEC 12207 (vedere le tabelle di x-ref nelle appendiciB.1.1 e C.6 della ISO/IEC 62304).

nella norma RTCA DO-178B citata nella lista dei consensus standarddella guidance General Principles of Software Validation.


9/40


Punti di attenzione

Il processo pi nuovo tra quelli previsti dalla norma quellorelativo al software risk management.

La norma ISO 14971 definisce nel dettaglio il processo a livellodi sistema.

Lanalisi degli hazard deve iniziare a livello sistema e dalluso

che si prevede verr fatto del sistema (intended use).

Tecniche che vengono normalmente utilizzate per lanalisi dei

rischi sono FTA e lFMEA.

Sono difficilmente applicabili al software, tanto pi se nonsono state sviluppate specifiche di dettaglio.

Lanalisi deve essere concentrata sugli eventuali contributi del

software al verificarsi di hazard o alla mitigazione dei rischi.


10/40


Punti di attenzione

Dimostrare che malfunzionamenti

dei software item non critici nonhanno impatto sul funzionamentodei software item critici.

Segregare i software item che

implementano requisiti di sicurezzadagli altri software item.

Se ladeguamento alla norma

successivo allo sviluppo del softwaree sono stati individuati software itemdi classe C o B, la segregazione puavere costi rilevanti.

[Fonte IEC 62304]


11/40


Punti di attenzione: SOUP

I prodotti Software Of Unknown Provenance devono esseretracciati: nei Piani di progetto: configuration management, sw e sw/hw

integration, sw risk management, sw maintenance plans;

nelle Specifiche funzionali e architetturali; nellanalisi dei rischi;

nei test di V&V;

nel change management;

nelle baseline di configurazione;e, una volta acquisiti e integrati diventano di responsabilit

del Manufacturer del dispositivo medico.


12/40


FDA Guidance: General Principles ofSoftware Validation

Typical Tasks Quality Planning

Typical Tasks Requirements

Typical Tasks Design

Typical Tasks Construction or Coding

Typical Tasks Testing by the Software Developer

Typical Tasks User Site Testing


13/40









- Risk (Hazard) Management Plan- Configuration Management Plan- Software Quality Assurance Plan

- Software Verification and Validation Plan- Verification and Validation Tasks, and Acceptance Criteria- Schedule and Resource Allocation (for software verification and validation activities)- Reporting Requirements

- Formal Design Review Requirements- Other Technical Review Requirements

- Problem Reporting and Resolution Procedures- Other Support Activities

- Preliminary Risk Analysis- Traceability Analysis

- Software Requirements to System Requirements (and vice versa)- Software Requirements to Risk Analysis

- Description of User Characteristics- Listing of Characteristics and Limitations of Primary and Secondary Memory- Software Requirements Evaluation- Software User Interface Requirements Analysis- System Test Plan Generation

- Acceptance Test Plan Generation- Ambiguity Review or Analysis

- Updated Software Risk Analysis- Traceability Analysis - Design Specification to Software Requirements (and vice versa)- Software Design Evaluation- Design Communication Link Analysis- Module Test Plan Generation

- Integration Test Plan Generation- Test Design Generation (module, integration, system, and acceptance)

T Pl i


14/40









- Test Planning- Structural Test Case Identification- Functional Test Case Identification- Traceability Analysis - Testing- Unit (Module) Tests to Detailed Design- Integration Tests to High Level Design

- System Tests to Software Requirements- Unit (Module) Test Execution- Integration Test Execution- Functional Test Execution- System Test Execution- Acceptance Test Execution- Test Results Evaluation- Error Evaluation/Resolution- Final Test Report

- Acceptance Test Execution- Test Results Evaluation- Error Evaluation/Resolution- Final Test Report


15/40


COTS software

il Device Manufacturer che ha la responsabilit regolatoriadi stabilire un eventuale effort addizionale per la convalida.

If the vendor can provide information about their systemrequirements, software requirements, validation process, and

the results of their validation, the medical devicemanufacturer can use that information as a beginning pointfor their required validation documentation.

Depending upon; 1) the risk of the device produced, 2) therole of the OTS software in the process, 3) the ability to audit

the vendor, and 4) the sufficiency of vendor-suppliedinformation, the use of OTS software or equipment may ormay not be appropriate, especially if there are suitablealternatives available


16/40


21 CFR Part 11

If a computer system creates or modifies or maintains orarchives or retrieves or distributes a record that is to satisfy anFDA record keeping requirement, then the record isconsidered electronic and subject to Part 11.

An electronic signature is a computer data compilation of anysymbol/s that is executed, adopted, or authorized by anindividual to be the legally binding equivalent of thatindividuals handwritten signature. In most cases this isaccomplished through the combination of the user ID and auser password


17/40


21 CFR Part 11 key requirements

Validation of the computerized system

Protection of records: backups Access control:

protection against unauthorized input, deletion or modification ofdata

records of unathorized signatures attempts

Audit trail: independently created by the system

record date and time of entries and actions that create, modify ordelete e-records

record changes must not obscure previous data reliable time stamping of events

Operational checks: enforcing correct sequencing of steps and events

production steps and signing executed in the predefined order


18/40


21 CFR Part 11 key requirements

Authority checks:

only authorized personnel can sign or alter a record access I/O devices

Training of personnel

Signatures: unique to one individual

used only by genuine owners

based on the combination of user ID and password or on biometrics

password expiration

expired password not be reused

user acces revoked after few times a wrong password is entered policies that hold individuals accountable for actions initiated under

their e-signatures

e-sig composed by name of the signer, e-sig date/time, e-sig meaning

linking e-sig to e-rec


19/40


Conclusioni

Per definire le procedure del Sistema Qualit fare riferimento

alle norme ISO 13485 e alla Part 820 del 21 CFR. Per definire la lista dei template dei documenti di

progettazione e di convalida fare riferimento alla guidanceFDA General Principles of Software Validation.

Per definire i contenuti dei template dei documenti diprogettazione e di convalida fare riferimento alle linee guidaGAMP e/o alle norme IEEE di software engineering.

Pianificare le attivit di progetto: sviluppo, V&V, gestioneconfigurazione e le relative responsabilit.

Completare lanalisi dei rischi del dispositivo medico,considerando le funzioni implementate con il software,applicando le norme ISO 14971 e IEC 62304.


20/40


Conclusioni

Classificare i moduli software in base alle conseguenze

dellhazard, al verificarsi del quale il software potrebbecontribuire.

A seconda della classe e in accordo allanalisi dei rischidisegnare larchitettura del software e sviluppare i deliverablein accordo alla tabella contenuta nellappendice A della IEC

62304. Eseguire la gap analysis rispetto alla Part 11, e, nel caso in cui

il dispositivo, con il suo intended use, ricada nello scopo dellanorma, adeguare il software a partire dallarchitettura (es. perimplementare un audit trail conforme alla norma).

Progettare ed eseguire i test di unit, integrazione sw ehw/sw, funzionali e di performance e tracciare tutti i problemiriscontrati e la loro risoluzione, applicando le tecniche e imetodi previsti dalla guidance FDA e dalla linea guida GAMP.


21/40


Backup

Modena, 8 Giugno 2010


22/40


Medical Devices

Definizione UE

Any instrument, apparatus, appliance, software, material orother article, whether used alone or in combination, includingthe software intended by its manufacturer to be usedspecifically for diagnostic and/or therapeutic purposes andnecessary for its proper application, intended by themanufacturer to be used for human beings.


23/40


Medical Devices

Definizione USA An instrument, apparatus, implement, machine, contrivance, implant, invitro reagent, or other similar or related article, including a componentpart, or accessory which is:

recognized in the official National Formulary, or the United States

Pharmacopoeia, or any supplement to them, intended for use in the diagnosis of disease or other conditions, or in the cure,

mitigation, treatment, or prevention of disease, in human or other animals, or

intended to affect the structure or any function of the body of man or otheranimals, and which does not achieve any of its primary intended purposesthrough chemical action within or on the body of man or other animals andwhich is not dependent upon being metabolized for the achievement of any ofits primary intended purposes

[Federal Food, Drug, and Cosmetic Act, 21 United States Code [321] (h).]


24/40


Medical Devices

Classificazione USAClass I: General Controls Class I devices present minimal potential for harm to the user and are often

simpler in design than Class II or Class III devices. These devices are subject only togeneral controls. General controls cover such issues as manufacturer registrationwith the FDA, good manufacturing techniques, proper branding and labelling,notification of the FDA before marketing the device, and general reportingprocedures

Class II: General Controls with Special Controls

Class II devices are those for which general controls alone are insufficient to assuresafety and effectiveness, and additional existing methods are available to provide

such assurances. Therefore, Class II devices are also subject to special controls inaddition to the general controls of Class I devices. Special controls may includespecial labeling requirements, mandatory performance standards, and postmarketsurveillance. Devices in Class II are held to a higher level of assurance than Class Idevices, and are designed to perform as indicated without causing injury or harmto patient or user


25/40


Medical Devices

Classificazione USAClass III: General Controls and Premarket Approval

A Class III device is one for which insufficient information exists to assuresafety and effectiveness solely through the general or special controls

sufficient for Class I or Class II devices. Such a device needs premarketapproval, a scientific review to ensure the device's safety andeffectiveness, in addition to the general controls of Class I. Class III devicesare described as those for which "insufficient information exists todetermine that general controls are sufficient to provide reasonable

assurance of its safety and effectiveness or that application of specialcontrols ... would provide such assurance and if, in addition, the device islife-supporting or life-sustaining, or for a use which is of substantialimportance in preventing impairment of human health, or if the devicepresents a potential unreasonable risk of illness or injury."


26/40


Medical Devices

Classificazione UE

La classificazione dei dispositivi medici nella UE fatta inaccordo allAnnesso IX della Direttiva 93/42/EEC.

Esistono quatto classi, ordinate da quella con minore rischio aquella con maggiore rischio.

Classe I (che include Is & Im) Classe IIa Classe IIb Classe III


27/40


Medical Devices

Autorizzazione alla vendita UE (Sintesi)

Lautorizzazione dei dispositivi medici garantita dalla Dichiarazione diConformit. Questa dichiarazione emessa dal fabbricante ma per

prodotti di classe Is, Im, IIa, IIb o III deve essere verificata attraverso unCertificato di Confomit rilasciato da un ente accreditato (Notified Body).Il Notified Body unorganizzazione pubblica o privata accreditata perverificare la confomit del dispositivo alle Direttive Europee. I dispositivi diClasse 1 (con alcune eccezioni) possono essere immessi sul mercatosemplicemente con la Dichiarazione di Conformit (autocertificazione).


28/40


Medical Devices

Autorizzazione alla vendita USAIdentificazione del

MDClassificazione del

MD

FDA Clearence

Esente

PMA

510KProve Cliniche

(Investigational DeviceExemption)

Requisiti PostVendita

Requisiti PreVendita

Labeling, registrazionedispositivi e siti

QS, MDR


29/40


Riferimenti Normativi FDA perDispositivi Medici

Codice Descrizione Campo di Applicazione

CFR 21 part 820Devices Part 820 Quality

System RegulationFabbricanti di Dispositivi

Medici

CFR 21 part 860 Medical Device Classification Dispositivi Medicali

CFR 21 part 11Electronic RecordElectronic Signature

Tutti i dispositivi ed ingenere i sistemi

computerizzati che adottanorecord elettronici e/o firma

elettronica


30/40


CFR 21 part 820 overview

Divisa in 15 paragrafi (subpart)

Ciascun paragrafo affronta un argomento specifico relativo al ciclo divita del dispositivo medicale

In particolare il paragrafo C, punto normativo 820.30, affrontalargomento relativo al Design Control

La progettazione e sviluppo sw, come parte integrante della maggiorparte dei dispositivi medicali, soggetta alle medesime indicazioni eregole

FDA include tra i sw regolamentati anche quelli utilizzati nella fase di

produzione, progettazione e sviluppo dei dispositivi medicali

FDA rilascia, a corredo delle normative, delle guide esplicative; inparticolare General Principles of Software Validation; Final Guidance forIndustry and FDA Staff, disponibile sul sito www.fda.gov, dedicato alla swvalidation
http://www.fda.gov/http://www.fda.gov/


31/40


Requisito CFR 820.30 (a)Design Control: General

Argomento punto normativo Elementi di Compliance

Each manufacturer of any class III or class IIdevice, and some class I devices shall establish

and maintain procedures to control the designof the device in order to ensure that specifieddesign requirements are met.

Il requisito definisce linsieme dei dispositivimedicali per i quali (tutti i dispositivi di classe 3 e

2, ed alcuni di classe 1) necessario predisporreuna o pi procedure che definiscano linteroprocesso di progettazione e sviluppo.Le procedure saranno ulteriormente richiamatee puntualizzate nei successivi punti normativi


32/40


Requisito CFR 820.30 (b)Design Control: Pianificazione

Argomento puntonormativo

Elementi di Compliance In Sintesi

Each manufacturer shallestablish and maintainplans that describe orreference the design anddevelopment activities

and define responsibilityfor implementation. Theplans shall identify anddescribe the interfaceswith different groups oractivities that provide, orresult in, input to the

design and developmentprocess. The plans shall bereviewed, updated, andapproved as design anddevelopment evolves

Deve essere presente unapianificazione dettagliata delle attivitdi progetto e sviluppo che diaevidenza delle responsabilit inrelazione alle singole attivit. Il piano

deve essere costantementeaggiornato in funzione dellaevoluzione del progetto e sottopostoa riesame ed approvazione conevidenza delle responsabilit per ilriesame e lapprovazione.

Nota: non vengono richiesti particolarimetodologie di pianificazione purchsiano rispettati tutti gli elementi dellanorma

Piano delle attivit con Responsabilitdefinite


33/40


Requisito CFR 820.30 (c)Design Control: Design Input

Argomento punto

normativoElementi di Compliance In sintesi

Each manufacturer shall establishand maintain procedures to ensure

that the design requirementsrelating to a device are appropriateand address the intended use of thedevice, including the needs of theuser and patient. The proceduresshall include a mechanism foraddressing incomplete, ambiguous,or conflicting requirements. Thedesign input requirements shall be

documented and shall be reviewedand approved by a designatedindividual(s). The approval,including the date and signature ofthe individual(s) approving therequirements, shall be documented.

Il punto normativo diviso in due parti; la prima parte stabiliscelesigenza di procedure che permettano di definire in modo

adeguato allo scopo (Intended use) i requisiti di progetto conattenzione agli utenti finali (operatori e pazienti) e con la capacitdi individuare requisiti incompleti, ambigui o in conflitto tra loro.Come elemento di evidenza pu essere predisposto unassessment (con evidenza delle responsabilit per la revisione elapprovazione) che, per ciascun requisito, evidenzi lo statorispetto a completezza, correttezza, consistenza, accuratezza,chiarezza, testabilit e tracciabilit

La seconda parte descrive lesigenza di un (o pi in caso di

dispositivi complessi) documento di Specifica dei Requisiti chereferenzi e descriva ciascun requisito. Il documento deve essereaggiornato, riesaminato ed approvato con evidenza di data e firmadi ciascunoAccanto ai requisiti necessario predisporre un documento di RiskAnalysis (secondo metodologie definite FMEA, FMECA, HAZOP)che fornisca una valutazione del rischio associato al requisito

Procedure che trattino direquisiti

Specifica dei Requisiti Valutazione rispetto acompletezza, correttezza,consistenza, accuratezza,chiarezza, testabilit etracciabilit Risk Assessment / RiskAnalysis

Nota: a partire dal punto C del requisito normativo 820.30, vengono richieste una serie di

procedure atte a garantire e standardizzare lintero processo di progettazione, sviluppo e testdei dispositivi


34/40


Requisito CFR 820.30 (d)Design Control: Design Output



Each manufacturer shall establishand maintain procedures fordefining and documenting designoutput in terms that allow an

adequate evaluation of conformance to design inputrequirements. Design outputprocedures shall contain or makereference to acceptance criteriaand shall ensure that thosedesign outputs that are essentialfor the proper functioning of the

device are identified. Designoutput shall be documented,reviewed, and approved beforerelease. The approval, includingthe date and signature of theindividual(s) approving theoutput, shall be documented.

Anche per questo requisito possonoindividuarsi due parti. La prima, come nelrequisito precedente, specifica lesigenzadi procedure atte a gestire e

documentare la fase di output.La seconda indica lesigenza didocumentazione che dia evidenza dellafase corrispondente.A questo scopo possono riferirsi idocumenti di Specifica funzionale eSpecifica di dettaglio, Specificadintegrazione e/o sistema, Specifiche di

Test. Le specifiche devono tracciare icorrispondenti requisiti, devono essererevisionate ed approvate (con data efirma)

Procedure Specifica funzionaleSpecifica di dettaglio Specifica Integrazione/Sistema

Specifiche di test (Verifica eValidazione)


35/40


Requisito CFR 820.30 (e)Design Control: Design Review


Each manufacturer shall establish and maintainprocedures to ensure that formal documentedreviews of the design results are planned andconducted at appropriate stages of the device'sdesign development. The procedures shall ensurethat participants at each design review includerepresentatives of all functions concerned with thedesign stage being reviewed and an individual(s)who does not have direct responsibility for thedesign stage being reviewed, as well as anyspecialists needed. The results of a design review,including identification of the design, the date, and

the individual(s) performing the review, shall bedocumented in the design history file (the DHF).

Devono essere definite delle procedure che gestiscano lapianificazione, esecuzione, conduzione e documentazionedelle fasi di Riesame Progetto.Gli elementi da prendere in esame ed analizzare durante ledesign review sono: il piano delle attivit i requisiti di progetto le specifiche di dettaglio i risultati dei test eseguiti i risultati della risk analysisLa review un momento di analisi interfunzionale quindidovrebbero partecipare i rappresentanti di tutte le funzioni

di progetto, sviluppo e validazione coinvolte

Ogni Design Review deve concludersi con un documentodatato e firmato da tutti i partecipanti che descriva glielementi di discussione ed i risultati del riesame


36/40


Requisito CFR 820.30 (f)Design Control: Verification



Each manufacturer shall establishand maintain procedures forverifying the device design. Designverification shall confirm that thedesign output meets the designinput requirements. The results ofthe design verification, includingidentification of the design,method(s), the date, and theindividual(s) performing theverification, shall be documented inthe DHF

Devono essere predisposte delle procedureche definiscano il processo di verifica dellaprogettazione e sviluppo

I test di verifica dovrebbero contenere ilriferimento ai requisiti, i criteri diaccettazione, i metodi di verifica ed irisultati ottenuti (oltre che le responsabilitper lesecuzione dei test e lapprovazionedei risultati)

Relativamente al software, possono essere

condotte verifiche con tecniche di analisistatica e dinamica del codice e codeinspection.

Code Inspection Static&Dinamic Analysis Unit test Functional Test Integration Test System Test


37/40


Argomento punto normativo Elementi di Compliance In sintesi

Each manufacturer shall establish andmaintain procedures for validating thedevice design. Design validation shall beperformed under defined operatingconditions on initial production units, lots,or batches, or their equivalents. Designvalidation shall ensure that devices

conform to defined user needs andintended uses and shall include testing ofproduction units under actual or simulateduse conditions. Design validation shallinclude software validation and riskanalysis, where appropriate. The results ofthe design validation, including

identification of the design, method(s), thedate, and the individual(s) performing thevalidation, shall be documented in the DHF

Devono essere predispostedelle procedure chedefiniscano il processo divalidazione della progettazionee sviluppo

I test di validazionedovrebbero contenere ilriferimento ai requisiti, i criteridi accettazione, i metodi divalidazione ed i risultatiottenuti (oltre che leresponsabilit per lesecuzione

dei test e lapprovazione deirisultati)

Protocolli di validazione conmetodologia, criterio diaccettazione, esito eresponsabilit

Requisito CFR 820.30 (g)Design Control: Validation

Nota: la verifica focalizzata sul/sui requisiti; la validazione focalizzatasullintended use del dispositivo


38/40


Requisito CFR 820.30 (i)Design Control: Design Change


Each manufacturer shall establish and maintainprocedures for the identification, documentation,validation or where appropriate verification,review, and approval of design changes before theirimplementation

Deve essere definita una procedura sul controllo deicambiamenti

Il change control un momento estremamente importantepoich modifiche alla progettazione e/o sviluppo possonoavere impatto sullintero processo di design. Le modificheeffettuate devono essere tracciate/documentate, valutateapprovate, verificate e validate.La valutazione pu essere effettuata mediante undocumento di Impact Assessment che descriva tutte lefunzionalit ed i requisiti coinvolti nel cambiamento.Le verifiche e la validazione devono coinvolgere,

conseguentemente, non solo loggetto della modifica maanche tutti gli elementi impattati


39/40


CFR 21 part 860 overview

Classifica i dispositivi medicali in base alla loro criticit e fornisce unaserie di definizioni utilizzate nelle normative

Sono individuate 3 Classi

Classe I: rientrano in tale categoria tutti i dispositivi medicali per i quali

sono sufficienti controlli generali per determinarne la sicurezza elefficacia e che non rientrano nelle categorie di life-supporting o life-sustaining

Classe II: dispositivi che necessitano di controlli speciali e cherientrano nelle categorie di life-supporting o life-sustaining

Classe III: dispositivi per i quali, vista la criticit, richiesto unaapprovazione pre-market


40/40

Via Francesco Gonin, 55

20147 Milano

Tel. +39 02 370511

Fax. +39 02 37051226

Corso Svizzera, 185

10149 Torino

Tel.: +39 011 7715774

Fax: +39 011 7419448

Via Adolfo Rav, 124

00100 Roma

Tel.: +39 06 45439361

Fax: +39 06 45439237

Come convalidare e assicurare la conformità alle direttive EC e US del software e dell'hardware di...

Documents

Transcript of Come convalidare e assicurare la conformità alle direttive EC e US del software e dell'hardware di...