Come convalidare e assicurare la conformit

alle direttive EC e US del software e

dell'hardware di un dispositivo medico

Ernesto Viale
IT Governance & Compliance Manager

Modena, 8 Giugno 2010

 I servizi della Business Unit
IT 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 di Gestione delle Risorse Umane

(People-CMM).

Tutoring e coaching dei Project Manager del Cliente

applicando la metodologia di project management PRINCE2.

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 2

 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's
510(k) and PMA requirements.

Evento
Modena,NI8/6/2010
- Modena 8 Giugno 2010 Skytechnology
Skytechnology Confidential
Confidential 3
3
 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.

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 4

 Norme EC e US applicabili
US 21 CFR Part 820
Quality System
Regulation

US 21 CFR Part 11
ER-ES Management

Guidance for Industry and FDA Staff

General Principles of
Evento NI - Modena 8 Giugno 2010 Software
Skytechnology Validation
Confidential 5
[Fonte IEC 62304]
 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, esteso
con 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.
Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 6
 La norma ISO/IEC 62304

Ai moduli software che implementano misure di controllo dei

rischi deve essere attribuita una delle 3 safety class sulla base
della severit del danno alla salute delle persone o alle cose.
La norma dichiara che la fase di manutenzione (con tutte le
relative 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 configuration
item.
Deve essere implementato un workflow che tracci problemi e
anomalie del software, sia in fase di sviluppo che di
manutenzione.

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 7

 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 del
sw 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 appendici
B.1.1 e C.6 della ISO/IEC 62304).
nella norma RTCA DO-178B citata nella lista dei consensus standard
della guidance General Principles of Software Validation.

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 8

 Punti di attenzione

Il processo pi nuovo tra quelli previsti dalla norma quello

relativo al software risk management.
La norma ISO 14971 definisce nel dettaglio il processo a livello
di 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 non
sono state sviluppate specifiche di dettaglio.
Lanalisi deve essere concentrata sugli eventuali contributi del
software al verificarsi di hazard o alla mitigazione dei rischi.

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 9

 Punti di attenzione
Dimostrare che malfunzionamenti
dei software item non critici non
hanno impatto sul funzionamento
dei software item critici.

Segregare i software item che

implementano requisiti di sicurezza
dagli altri software item.

[Fonte IEC 62304]

Se ladeguamento alla norma

successivo allo sviluppo del software
e sono stati individuati software item
di classe C o B, la segregazione pu
avere costi rilevanti.

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 10

 Punti di attenzione: SOUP

I prodotti Software Of Unknown Provenance devono essere

tracciati:
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.

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 11

 FDA Guidance: General Principles of
Software 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

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 12

- Risk (Hazard) Management Plan
- Configuration Management Plan
- Software Quality Assurance Plan
FDA Guidance: General Principles of
- Software Verification and Validation Plan Software Validation
- Verification and Validation Tasks, and Acceptance Criteria
- Schedule and Resource Allocation (for software verification and validation activities)
- Reporting Requirements
- Formal Design Review Requirements
Typical Tasks Quality Planning
- Other Technical Review Requirements
- Problem Reporting and Resolution Procedures
- Other Support Activities
Typical Tasks Requirements
- Preliminary Risk Analysis
Typical Tasks Design
- Traceability Analysis
- Software Requirements to System Requirements (and vice versa)
Typical Tasks Construction or Coding
- Software Requirements to Risk Analysis
- Description of User Characteristics
- Listing of Characteristics and Limitations of Primary and Secondary Memory
Typical Tasks Testing by the Software Developer
- Software Requirements Evaluation
- Software User Interface Requirements Analysis
Typical Tasks User Site Testing
- 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
Evento NITest PlanGeneration
- Modena 8 Giugno 2010 Skytechnology Confidential 13
- Test Design Generation (module, integration, system, and acceptance)
- Test Planning
- Structural Test Case Identification FDA Guidance: General Principles of
- Functional Test Case Identification
- Traceability Analysis - Testing Software Validation
- Unit (Module) Tests to Detailed Design
- Integration Tests to High Level Design
- System Tests to Software Requirements
Typical Tasks Quality Planning
- Unit (Module) Test Execution
- Integration Test Execution
- Functional Test Execution
Typical Tasks Requirements
- System Test Execution
- Acceptance Test Execution
- TestResults
Typical Tasks Design
Evaluation
- Error Evaluation/Resolution
Test
- Final Typical
Report Tasks Construction or Coding

- Acceptance Test Execution
Typical Tasks Testing by the Software
- Test Results Evaluation
Developer
Typical Tasks User Site Testing
- Error Evaluation/Resolution
- Final Test Report

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 14

 COTS software

il Device Manufacturer che ha la responsabilit regolatoria

di stabilire un eventuale effort addizionale per la convalida.
If the vendor can provide information about their system
requirements, software requirements, validation process, and
the results of their validation, the medical device
manufacturer can use that information as a beginning point
for their required validation documentation.
Depending upon; 1) the risk of the device produced, 2) the
role of the OTS software in the process, 3) the ability to audit
the vendor, and 4) the sufficiency of vendor-supplied
information, the use of OTS software or equipment may or
may not be appropriate, especially if there are suitable
alternatives available
Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 15
 21 CFR Part 11

If a computer system creates or modifies or maintains or

archives or retrieves or distributes a record that is to satisfy an
FDA record keeping requirement, then the record is
considered electronic and subject to Part 11.
An electronic signature is a computer data compilation of any
symbol/s that is executed, adopted, or authorized by an
individual to be the legally binding equivalent of that
individuals handwritten signature. In most cases this is
accomplished through the combination of the user ID and a
user password

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 16

 21 CFR Part 11 key requirements
Validation of the computerized system
Protection of records: backups
Access control:
protection against unauthorized input, deletion or modification of
data
records of unathorized signatures attempts
Audit trail:
independently created by the system
record date and time of entries and actions that create, modify or
delete 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
Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 17
 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
Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 18
 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 guidance
FDA General Principles of Software Validation.
Per definire i contenuti dei template dei documenti di
progettazione e di convalida fare riferimento alle linee guida
GAMP e/o alle norme IEEE di software engineering.
Pianificare le attivit di progetto: sviluppo, V&V, gestione
configurazione 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.
Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 19
 Conclusioni
Classificare i moduli software in base alle conseguenze
dellhazard, al verificarsi del quale il software potrebbe
contribuire.
A seconda della classe e in accordo allanalisi dei rischi
disegnare larchitettura del software e sviluppare i deliverable
in 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 della
norma, adeguare il software a partire dallarchitettura (es. per
implementare un audit trail conforme alla norma).
Progettare ed eseguire i test di unit, integrazione sw e
hw/sw, funzionali e di performance e tracciare tutti i problemi
riscontrati e la loro risoluzione, applicando le tecniche e i
metodi previsti dalla guidance FDA e dalla linea guida GAMP.
Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 20
 Backup

Modena, 8 Giugno 2010

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 21

 Medical Devices

Definizione UE
Any instrument, apparatus, appliance, software, material or
other article, whether used alone or in combination, including
the software intended by its manufacturer to be used
specifically for diagnostic and/or therapeutic purposes and
necessary for its proper application, intended by the
manufacturer to be used for human beings.

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 22

 Medical Devices

Definizione USA
An instrument, apparatus, implement, machine, contrivance, implant, in
vitro reagent, or other similar or related article, including a component
part, 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 other
animals, and which does not achieve any of its primary intended purposes
through chemical action within or on the body of man or other animals and
which is not dependent upon being metabolized for the achievement of any of
its primary intended purposes
[Federal Food, Drug, and Cosmetic Act, 21 United States Code [321] (h).]

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 23

 Medical Devices

Classificazione USA
Class 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 to
general controls. General controls cover such issues as manufacturer registration
with the FDA, good manufacturing techniques, proper branding and labelling,
notification of the FDA before marketing the device, and general reporting
procedures
Class II: General Controls with Special Controls
Class II devices are those for which general controls alone are insufficient to assure
safety and effectiveness, and additional existing methods are available to provide
such assurances. Therefore, Class II devices are also subject to special controls in
addition to the general controls of Class I devices. Special controls may include
special labeling requirements, mandatory performance standards, and postmarket
surveillance. Devices in Class II are held to a higher level of assurance than Class I
devices, and are designed to perform as indicated without causing injury or harm
to patient or user
Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 24
 Medical Devices

Classificazione USA
Class III: General Controls and Premarket Approval
A Class III device is one for which insufficient information exists to assure
safety and effectiveness solely through the general or special controls
sufficient for Class I or Class II devices. Such a device needs premarket
approval, a scientific review to ensure the device's safety and
effectiveness, in addition to the general controls of Class I. Class III devices
are described as those for which "insufficient information exists to
determine that general controls are sufficient to provide reasonable
assurance of its safety and effectiveness or that application of special
controls ... would provide such assurance and if, in addition, the device is
life-supporting or life-sustaining, or for a use which is of substantial
importance in preventing impairment of human health, or if the device
presents a potential unreasonable risk of illness or injury."
Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 25
 Medical Devices

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

Esistono quatto classi, ordinate da quella con minore rischio a

quella con maggiore rischio.

Classe I (che include Is & Im)

Classe IIa
Classe IIb
Classe III

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 26

 Medical Devices

Autorizzazione alla vendita UE (Sintesi)

Lautorizzazione dei dispositivi medici garantita dalla Dichiarazione di
Conformit. Questa dichiarazione emessa dal fabbricante ma per
prodotti di classe Is, Im, IIa, IIb o III deve essere verificata attraverso un
Certificato di Confomit rilasciato da un ente accreditato (Notified Body).
Il Notified Body unorganizzazione pubblica o privata accreditata per
verificare la confomit del dispositivo alle Direttive Europee. I dispositivi di
Classe 1 (con alcune eccezioni) possono essere immessi sul mercato
semplicemente con la Dichiarazione di Conformit (autocertificazione).

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 27

 Medical Devices

Autorizzazione alla vendita USA

Identificazione del Classificazione del
MD MD
PMA

Prove Cliniche
Esente 510K
(Investigational Device
Exemption)

Requisiti Post Requisiti Pre

FDA Clearence
Vendita Vendita

Labeling, registrazione
QS, MDR
dispositivi e siti

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 28

 Riferimenti Normativi FDA per
Dispositivi Medici

Codice Descrizione Campo di Applicazione

Devices Part 820 Quality Fabbricanti di Dispositivi

CFR 21 part 820
System Regulation Medici

CFR 21 part 860 Medical Device Classification Dispositivi Medicali

Tutti i dispositivi ed in
genere i sistemi
Electronic Record
CFR 21 part 11 computerizzati che adottano
Electronic Signature
record elettronici e/o firma
elettronica

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 29

 CFR 21 part 820 overview

Divisa in 15 paragrafi (subpart)

Ciascun paragrafo affronta un argomento specifico relativo al ciclo di

vita del dispositivo medicale

In particolare il paragrafo C, punto normativo 820.30, affronta

largomento relativo al Design Control

La progettazione e sviluppo sw, come parte integrante della maggior

parte dei dispositivi medicali, soggetta alle medesime indicazioni e
regole

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; in

particolare General Principles of Software Validation; Final Guidance for
Industry and FDA Staff, disponibile sul sito www.fda.gov, dedicato alla sw
validation

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 30

 Requisito CFR 820.30 (a)
Design Control: General

Argomento punto normativo Elementi di Compliance

Each manufacturer of any class III or class II
device, and some class I devices shall establish
and maintain procedures to control the design
of the device in order to ensure that specified
design requirements are met.
Il requisito definisce linsieme dei dispositivi
medicali per i quali (tutti i dispositivi di classe 3 e
2, ed alcuni di classe 1) necessario predisporre
una o pi procedure che definiscano lintero
processo di progettazione e sviluppo.
Le procedure saranno ulteriormente richiamate
e puntualizzate nei successivi punti normativi

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 31

 Requisito CFR 820.30 (b)
Design Control: Pianificazione

Argomento punto
Elementi di Compliance In Sintesi
normativo
Each manufacturer shall Deve essere presente una Piano delle attivit con Responsabilit
establish and maintain pianificazione dettagliata delle attivit definite
plans that describe or di progetto e sviluppo che dia
reference the design and evidenza delle responsabilit in
development activities relazione alle singole attivit. Il piano
and define responsibility deve essere costantemente
for implementation. The aggiornato in funzione della
plans shall identify and evoluzione del progetto e sottoposto
describe the interfaces a riesame ed approvazione con
with different groups or evidenza delle responsabilit per il
activities that provide, or riesame e lapprovazione.
result in, input to the
design and development Nota: non vengono richiesti particolari
process. The plans shall be metodologie di pianificazione purch
reviewed, updated, and siano rispettati tutti gli elementi della
approved as design and norma
development evolves

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 32


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 test
dei dispositivi
Argomento punto
normativo
Each manufacturer shall establish
and maintain procedures to ensure
that the design requirements
relating to a device are appropriate
and address the intended use of the
device, including the needs of the
user and patient. The procedures
shall include a mechanism for
addressing incomplete, ambiguous,
or conflicting requirements. The
design input requirements shall be
documented and shall be reviewed
and approved by a designated
individual(s). The approval,
including the date and signature of
the individual(s) approving the
requirements, shall be documented.
Evento NI - Modena 8 Giugno 2010
Requisito CFR 820.30 (c)
Design Control: Design Input
Elementi di Compliance In sintesi
Il punto normativo diviso in due parti; la prima parte stabilisce Procedure che trattino di
lesigenza di procedure che permettano di definire in modo requisiti
adeguato allo scopo (Intended use) i requisiti di progetto con Specifica dei Requisiti
attenzione agli utenti finali (operatori e pazienti) e con la capacit Valutazione rispetto a
di individuare requisiti incompleti, ambigui o in conflitto tra loro. completezza, correttezza,
Come elemento di evidenza pu essere predisposto un consistenza, accuratezza,
assessment (con evidenza delle responsabilit per la revisione e chiarezza, testabilit e
lapprovazione) che, per ciascun requisito, evidenzi lo stato tracciabilit
rispetto a completezza, correttezza, consistenza, accuratezza, Risk Assessment / Risk
chiarezza, testabilit e tracciabilit Analysis
La seconda parte descrive lesigenza di un (o pi in caso di
dispositivi complessi) documento di Specifica dei Requisiti che
referenzi e descriva ciascun requisito. Il documento deve essere
aggiornato, riesaminato ed approvato con evidenza di data e firma
di ciascuno
Accanto ai requisiti necessario predisporre un documento di Risk
Analysis (secondo metodologie definite FMEA, FMECA, HAZOP)
che fornisca una valutazione del rischio associato al requisito
Skytechnology Confidential 33

Argomento punto
normativo
Each manufacturer shall establish
and maintain procedures for
defining and documenting design
output in terms that allow an
adequate evaluation of
conformance to design input
requirements. Design output
procedures shall contain or make
reference to acceptance criteria
and shall ensure that those
design outputs that are essential
for the proper functioning of the
device are identified. Design
output shall be documented,
reviewed, and approved before
release. The approval, including
the date and signature of the
individual(s) approving the
output, shall be documented.
Evento NI - Modena 8 Giugno 2010
Requisito CFR 820.30 (d)
Design Control: Design Output
Elementi di Compliance In Sintesi
Anche per questo requisito possono Procedure
individuarsi due parti. La prima, come nel Specifica funzionale
requisito precedente, specifica lesigenza Specifica di dettaglio
di procedure atte a gestire e Specifica Integrazione/Sistema
documentare la fase di output. Specifiche di test (Verifica e
La seconda indica lesigenza di Validazione)
documentazione che dia evidenza della
fase corrispondente.
A questo scopo possono riferirsi i
documenti di Specifica funzionale e
Specifica di dettaglio, Specifica
dintegrazione e/o sistema, Specifiche di
Test. Le specifiche devono tracciare i
corrispondenti requisiti, devono essere
revisionate ed approvate (con data e
firma)
Skytechnology Confidential 34
 Requisito CFR 820.30 (e)
Design Control: Design Review

Argomento punto normativo Elementi di Compliance

Each manufacturer shall establish and maintain
procedures to ensure that formal documented
reviews of the design results are planned and
conducted at appropriate stages of the device's
design development. The procedures shall ensure
that participants at each design review include
representatives of all functions concerned with the
design stage being reviewed and an individual(s)
who does not have direct responsibility for the
design stage being reviewed, as well as any
specialists needed. The results of a design review,
including identification of the design, the date, and
the individual(s) performing the review, shall be
documented in the design history file (the DHF).
Devono essere definite delle procedure che gestiscano la
pianificazione, esecuzione, conduzione e documentazione
delle fasi di Riesame Progetto.
Gli elementi da prendere in esame ed analizzare durante le
design review sono:
il piano delle attivit
i requisiti di progetto
le specifiche di dettaglio
i risultati dei test eseguiti
i risultati della risk analysis
La review un momento di analisi interfunzionale quindi
dovrebbero partecipare i rappresentanti di tutte le funzioni
di progetto, sviluppo e validazione coinvolte
Ogni Design Review deve concludersi con un documento
datato e firmato da tutti i partecipanti che descriva gli
elementi di discussione ed i risultati del riesame

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 35

 Requisito CFR 820.30 (f)
Design Control: Verification

Argomento punto
Elementi di Compliance In Sintesi
normativo
Each manufacturer shall establish Devono essere predisposte delle procedure Code Inspection
and maintain procedures for che definiscano il processo di verifica della Static&Dinamic Analysis
verifying the device design. Design progettazione e sviluppo Unit test
verification shall confirm that the Functional Test
design output meets the design I test di verifica dovrebbero contenere il Integration Test
input requirements. The results of riferimento ai requisiti, i criteri di System Test
the design verification, including accettazione, i metodi di verifica ed i
identification of the design, risultati ottenuti (oltre che le responsabilit
method(s), the date, and the per lesecuzione dei test e lapprovazione
individual(s) performing the dei risultati)
verification, shall be documented in
the DHF Relativamente al software, possono essere
condotte verifiche con tecniche di analisi
statica e dinamica del codice e code
inspection.

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 36

 Requisito CFR 820.30 (g)
Design Control: Validation
Argomento punto normativo Elementi di Compliance In sintesi
Each manufacturer shall establish and Devono essere predisposte Protocolli di validazione con
maintain procedures for validating the delle procedure che metodologia, criterio di
device design. Design validation shall be definiscano il processo di accettazione, esito e
performed under defined operating validazione della progettazione responsabilit
conditions on initial production units, lots, e sviluppo
or batches, or their equivalents. Design
validation shall ensure that devices
conform to defined user needs and I test di validazione
intended uses and shall include testing of dovrebbero contenere il
production units under actual or simulated riferimento ai requisiti, i criteri
use conditions. Design validation shall di accettazione, i metodi di
include software validation and risk validazione ed i risultati
analysis, where appropriate. The results of ottenuti (oltre che le
the design validation, including responsabilit per lesecuzione
identification of the design, method(s), the dei test e lapprovazione dei
date, and the individual(s) performing the risultati)
validation, shall be documented in the DHF

Nota: la verifica focalizzata sul/sui requisiti; la validazione focalizzata

sullintended use del dispositivo
Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 37
 Requisito CFR 820.30 (i)
Design Control: Design Change

Argomento punto normativo Elementi di Compliance

Each manufacturer shall establish and maintain
procedures for the identification, documentation,
validation or where appropriate verification,
review, and approval of design changes before their
implementation
Deve essere definita una procedura sul controllo dei
cambiamenti
Il change control un momento estremamente importante
poich modifiche alla progettazione e/o sviluppo possono
avere impatto sullintero processo di design. Le modifiche
effettuate devono essere tracciate/documentate, valutate
approvate, verificate e validate.
La valutazione pu essere effettuata mediante un
documento di Impact Assessment che descriva tutte le
funzionalit ed i requisiti coinvolti nel cambiamento.
Le verifiche e la validazione devono coinvolgere,
conseguentemente, non solo loggetto della modifica ma
anche tutti gli elementi impattati

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 38

 CFR 21 part 860 overview

Classifica i dispositivi medicali in base alla loro criticit e fornisce una

serie 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 e
lefficacia e che non rientrano nelle categorie di life-supporting o life-
sustaining

Classe II: dispositivi che necessitano di controlli speciali e che

rientrano nelle categorie di life-supporting o life-sustaining

Classe III: dispositivi per i quali, vista la criticit, richiesto una

approvazione pre-market

Evento NI - Modena 8 Giugno 2010 Skytechnology Confidential 39

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