Convalida della progettazione vs. Verifica: 6 suggerimenti per lo sviluppo di dispositivi medici

Se sviluppi prodotti, in particolare dispositivi medici, hai sentito i termini convalida della progettazione e verifica della progettazione (chiamati anche V& V). Qui spiegheremo quali sono le due attività, la differenza tra loro, oltre a condividere suggerimenti per ottenere il massimo dai tuoi sforzi.

Nota: A confermare che questo contenuto possa essere utile a voi, ci siamo collegati con Megan Martin, un dispositivo medico V&V Consulente con oltre 30 anni di esperienza nel dispositivo medico V&V, medical device software, prodotto e della qualità del software, degli stati UNITI e internazionali dispositivo normativo osservazioni. Troverete le sue intuizioni ed esempi in tutto!

Segui o salta alla sezione che stai cercando:

• Convalida del progetto vs. Verifica del progetto
• Cos’è esattamente la convalida del progetto?
• Che cosa è la verifica di progettazione per FDA?
• Convalida vs Verifica di Riepilogo
• Nozioni di base per la Progettazione Processo di Validazione
• Nozioni di base per la Progettazione Processo di Verifica
• 6 Consigli per una Migliore Convalida & Verifica
• Video: Semplificare V & V
• V&V: Glossario dei Termini

la Validazione della Progettazione vs. Verifica della Progettazione: Qual è la Differenza?

Qual è la differenza tra validazione e verifica? In parole povere, la convalida del design determina se si sta costruendo il prodotto giusto. Il dispositivo funziona come previsto per gli utenti finali? La verifica della progettazione determina se stai costruendo il prodotto giusto. Le uscite di progettazione corrispondono agli ingressi di progettazione?

Questa è la semplice differenza chiaramente illustrata nel grafico sottostante.

Ma vuoi maggiori dettagli ed esempi, ovviamente. Inizieremo con la convalida.

Cos’è esattamente la convalida del progetto?

La convalida del progetto è un processo di test mediante il quale si dimostra (“convalida”) che il dispositivo creato funziona per l’utente finale come previsto.

La parola ufficiale della FDA (21 CFR 820.3) afferma che la convalida del progetto sta “stabilendo con prove oggettive che le specifiche del dispositivo sono conformi alle esigenze degli utenti e agli usi previsti.”

Esempio di convalida del progetto

Immaginiamo di costruire un ventilatore che mantenga la respirazione del paziente e che l’utente voglia che funzioni durante il trasporto del paziente.

In primo luogo, dobbiamo definire le nostre esigenze degli utenti. L’utente vuole spostare i pazienti mentre sono sul ventilatore. Ma cosa stanno effettivamente cercando di fare? Il “Trasporto” potrebbe includere lo spostamento del paziente all’interno dell’ospedale. O potrebbe includere il trasporto via ambulanza o per via aerea. Un utente ha bisogno, ad esempio, potrebbe essere simile al seguente.

Necessità dell’utente

UsNe-0001

Il ventilatore è adatto per l’uso durante il trasporto ospedaliero dei pazienti.

Questo bisogno dell’utente sarà suddiviso in requisiti di prodotto e specifiche di progettazione al fine di progettare e costruire il prodotto. (Vedremo quelli in un momento in fase di verifica del design.)

Prima di ciò, esaminiamo le nostre esigenze degli utenti e vediamo quali casi di test di convalida del design potrebbero essere richiesti. Il test di convalida del nostro bisogno utente potrebbe assomigliare a questo.

Utente Necessario		Convalida Prova
UsNe-0001	Il ventilatore è adatto per l’uso durante la degenza il trasporto dei pazienti.	TCase-0001	Validation Test Suite: Verificare che il ventilatore può essere arrotolato facilmente da 15 membri del personale di trasporto ospedaliero.
		TCase-0002	Suite di test di convalida: Verifichi che il ventilatore funzioni all’interno delle sue specifiche mentre è rotolato giù i corridoi, sopra gli inceppamenti della porta e sopra le soglie dell’elevatore.
		TCase-0003	Validation Test Suite: verifica che il ventilatore funzioni entro le sue specifiche durante la transizione tra alimentazione CA e funzionamento a batteria.

i test di Convalida dovrebbe includere casi di test, test suites, o anche studi clinici progettati per dimostrare che il prodotto, in quanto costruito, funziona secondo le aspettative dell’utente nelle condizioni in cui si intende utilizzarlo. Poiché questi test dovrebbero essere eseguiti su unità di produzione o equivalenti alla produzione, i test di convalida del progetto sono spesso gli ultimi test eseguiti.

Fondamentalmente, nella convalida del design, dobbiamo dimostrare che il prodotto soddisfa le esigenze dell’utente.

A proposito, la tabella sopra mostra anche la tracciabilità tra le esigenze degli utenti e i casi di test. Questa matrice di traccia fornisce parte della prova V&V richiesta dalla FDA.

Che cosa è la verifica di progettazione per FDA?

La verifica di progettazione è dove si verifica (“verifica”) che le uscite di progettazione corrispondano agli ingressi di progettazione.

Ancora una volta, secondo la FDA, la verifica del progetto è “conferma mediante esame e fornitura di prove oggettive che i requisiti specificati sono stati soddisfatti.”

Tieni presente che mentre comporterà test, ci sono altre attività di verifica accettabili.

Possono includere test, ispezioni e analisi (per ulteriori informazioni, consulta la guida al controllo del design FDA).

Esempio di verifica del progetto

Torniamo al nostro esempio di ventilatore. Abbiamo identificato le nostre esigenze degli utenti; ora cerchiamo di identificare ciò che il dispositivo deve fare e come deve farlo.

Per raggiungere questo obiettivo, dobbiamo definire i requisiti specifici del prodotto. Ad esempio:

• Qual è il carico massimo per un paziente? (Quanta aria deve muoversi il ventilatore?)
• Quanto tempo la batteria deve durare? (Quanto tempo impiega il trasporto?)
• Quali condizioni incontreranno durante il trasporto? (Porta inceppamenti? Ascensori?)
• Esistono standard normativi che devono essere soddisfatti? (Norme di sicurezza?)

“Requisiti chiari, completi, inequivocabili e verificabili sono un componente chiave in un progetto di sviluppo di successo. Requisiti inadeguati portano a perdite di tempo, errori di progettazione, rielaborazioni estese e prodotti fragili o soggetti a errori.”- Megan Martin, V&V Consultant

Questa è la parte “cosa” della definizione delle caratteristiche del dispositivo. Cosa dovrà fare esattamente il dispositivo? I requisiti del prodotto (spesso inclusi in un documento sui requisiti del prodotto) per le nostre esigenze degli utenti potrebbero apparire come di seguito.

Requisiti del prodotto

PrRq-0001	Il ventilatore deve avere una regolazione massima di 2 litri di volume controllato respiri a 20 respiri al minuto.
PrRq-0002	Il ventilatore deve funzionare a batteria alle impostazioni massime per un minimo di 90 minuti.
PrRq-0003	Il ventilatore deve poter essere montato su un supporto rotante.
PrRq-0004	Il ventilatore e il supporto devono essere in grado di attraversare le soglie tipiche delle porte ospedaliere e degli ascensori.

Infine, abbiamo bisogno di specifiche di progettazione. ” Abbiamo già definito ciò che raggiungeremo e ora dobbiamo definire come lo faremo”, afferma Megan. Ciò può essere realizzato in vari modi, tra cui specifiche scritte, disegni elettrici o meccanici, specifiche di acquisto dei componenti o altri metodi.

Ad esempio, le specifiche di progettazione e i disegni potrebbero mostrare quanto segue.

Specifiche di progetto

DSpec-0001	Una turbina in grado di generare fino a 40 litri di aria al minuto.
DSpec-0002	Un pacco batteria agli ioni di litio valutato per almeno 100 ore di amp.
DSpec-0003	Il supporto per il supporto rotante utilizza un morsetto a leva in acciaio valutato per 22 libbre.
DSpec-0004	La base del supporto è larga 22″ con 5 ruote.
DSpec-0005	Le ruote del supporto hanno un diametro di 4″.

La verifica della progettazione fornisce prove (risultati dei test) che le uscite di progettazione (prodotto reale) soddisfano gli ingressi di progettazione (requisiti del prodotto e specifiche di progettazione). A seconda dell’elemento da verificare, verrà eseguito un test case o una suite di test o un’ispezione o un’analisi per fornire le prove richieste.

Le tabelle seguenti illustrano come potrebbe apparire. Mostrano anche la tracciabilità che la FDA si aspetta.

Requisiti di Prodotto		Verifica
PrRq-0001	Il ventilatore deve avere un massimo di 2 litri di volume-controllato respiri al 20 respiri al minuto.	TCase-0004	Test case: verifica le impostazioni massime del respiro o le combinazioni di impostazioni del respiro.
PrRq-0002	Il ventilatore deve funzionare a batteria alle impostazioni massime per un minimo di 90 minuti.	TCase-0005	Suite di test: Verificare il tempo di esecuzione sulle impostazioni massime con una nuova batteria completamente carica.
		TCase-0006	Test suite: verifica il tempo di esecuzione sulle impostazioni massime con una batteria che ha attraversato 50 cicli di carica.
PrRq-0003	Il ventilatore deve poter essere montato su un supporto di rotolamento.	TCase-0007	Prova dimostrativa: Dimostrare che il ventilatore può essere collegato e staccato dal supporto di rotolamento.
PrRq-0004	Il ventilatore e il supporto devono essere in grado di attraversare le soglie tipiche della porta ospedaliera e dell’ascensore.	TCase-0008	Prova esterna: La prova eseguita da un servizio di prova per verificare che il ventilatore ed il supporto possono essere rotolati sopra una soglia senza capovolgersi secondo la norma elettrica medica di IEC 60601-1.

La verifica dei requisiti del prodotto, come sopra, mostra che il prodotto fa quello che abbiamo detto che avrebbe fatto.

La verifica delle specifiche di progettazione, che mostreremo di seguito, mostra che il prodotto lo fa nel modo in cui abbiamo detto che lo avrebbe fatto.

Specifiche		Verifica
DSpec-0001	Una turbina in grado di generare 40 litri di aria al minuto.	TCase-0009	Test Suite: verificare la generazione di aria dalla turbina a 40 lpm su alimentazione CA o batteria.
DSpec-0002	Un pacco batteria agli ioni di litio valutato per 100 ore Amp.	TCase-0010	Test di ispezione: Verificare l’acquisto della batteria spec mostra tipo è agli ioni di litio.
		TCase-0011	Test di analisi: Raccogliere i dati di test e fare analisi dei dati per dimostrare le prestazioni della batteria per tutta la durata della batteria si incontrano o superare i 100 Amp ore.
DSpec-0003	Il supporto per il supporto rotante utilizza un morsetto a leva in acciaio valutato per 22 libbre.	TCase-0012	Test di ispezione: verificare la specifica della parte è per un morsetto a leva in acciaio valutato per 22 libbre o più.
DSpec-0004	La base del supporto è larga 22″ con 5 ruote.	TCase-0013	Test Case: Misurare il diametro della base; contare le ruote; misurare il diametro della ruota
DSpec-0005	Le ruote del supporto hanno un diametro di 4″.

Essenzialmente, nella verifica del progetto, dobbiamo dimostrare che il prodotto che abbiamo costruito è il prodotto che abbiamo detto che avremmo costruito.

Quando raccolti insieme in un rapporto V&V, la combinazione dei risultati dei test di verifica e validazione, insieme alla tracciabilità in base alle esigenze degli utenti, ai requisiti del prodotto e alle specifiche di progettazione, fornisce parte delle prove richieste dalla FDA al momento della presentazione di un dispositivo medico

Validation vs Verification Summary

Ecco un breve riassunto, anche se leggermente semplificato, delle differenze chiave.

Design Verification	Design Validation
Design output is as expected.	Final design meets user’s needs.
System, subsystem and unit testing.	System testing.
During development.	After development.
Test individual module or completed system under any conditions.	Test conditions per user needs.
Include ispezioni di sistema, analisi e test.	Include il test di unità equivalenti di produzione in condizioni di utilizzo reale.
Include report di test eseguiti, risultati dei test e tracciabilità. I rapporti vengono esaminati, approvati e firmati.	Include il rapporto finale, con i risultati dei test e la tracciabilità, pronto per la revisione normativa. I rapporti vengono esaminati, approvati e firmati.

Nozioni di base del processo di convalida del progetto

Il processo di convalida del progetto consisterà in gran parte nel testare il dispositivo. Puoi condurlo in alcuni modi, a seconda delle circostanze. Le attività possono includere:

• Confronto con apparecchiature simili che eseguono per scopi simili.
• Simulazione di funzionalità attraverso la modellazione matematica.
• Testare il progetto finale per dimostrare che il sistema funziona come definito nelle esigenze dell’utente.

Il piano di test, i casi di test, i record di esecuzione dei test e i risultati dei test devono essere documentati e mantenuti come parte dei record di progettazione. La convalida, nella sua interezza, non è il risultato di una singola attività, ma la raccolta dei risultati di tutte le attività di convalida.

Nozioni di base del processo di verifica del progetto

La verifica può essere ridotta a un semplice processo in cinque fasi.

Identificare e preparare

Identificare l’approccio migliore per condurre la verifica. Definisci cosa misurerai e come lo misurerai. Ti consigliamo anche di prendere in considerazione le risorse necessarie, manodopera, e gli strumenti per la verifica di successo.

Pianificazione

La pianificazione per la verifica avviene durante tutto il ciclo di vita del progetto. Svilupperai il piano di test, che cattura le pietre miliari critiche. Il piano deve essere aggiornato ogni volta che vengono apportate modifiche agli input di progettazione.

Sviluppo

Inizia lo sviluppo del prodotto! Viene condotto utilizzando la metodologia di scelta (Scrum, Waterfall, hybrid, ecc.). Questa parte del processo include anche la scrittura, la guida di prova e l’approvazione dei casi di test che verranno utilizzati per la verifica.

Esecuzione

Le procedure di test vengono eseguite come previsto. Tutti i risultati non validi sono documentati e esaminati e accettati o registrati come difetti. I difetti nel prodotto vengono risolti e rilasciati e viene eseguito il test di regressione. Viene creata una matrice di tracciabilità per verificare che gli input di progettazione identificati nel piano di test di verifica siano stati testati e superati.

Segnalazione

La segnalazione viene eseguita al termine di ogni fase di verifica. I report dettagliati includono la gestione della configurazione e i report di rilascio, i risultati dei test per tipo di test o versione del prodotto e i problemi riscontrati durante l’attività di verifica. Un rapporto sulla tracciabilità della verifica del progetto mostra i risultati dei test e la copertura per i requisiti. Infine, le revisioni vengono completate e approvate dopo ogni attività di verifica del progetto.

6 suggerimenti per una migliore validazione& Verifica

Ecco alcuni suggerimenti per essere sicuri di ottenere il massimo dalla convalida & attività di verifica.

Pianificare in anticipo (E testare in anticipo)

Avere un piano solido in anticipo e loop tutti in. Includere ingegneri di test nelle prime fasi della pianificazione dello sviluppo per assicurarsi che i requisiti e la progettazione siano chiari, completi e verificabili. Megan afferma: “Lo sviluppo precoce dei metodi di prova può far luce sui problemi tecnologici prima che diventino ostacoli principali.”Lo sviluppo precoce dei test può anche fornire strumenti di test. Questi possono quindi essere utilizzati per accelerare il processo di sviluppo del prodotto e fornire prove di prova durante i test formali.

Usa la nomenclatura condivisa

Ottenere il tuo team sulla stessa pagina è fondamentale per la convalida del progetto di successo& verifica. Parte di ottenere sulla stessa pagina significa utilizzare una terminologia condivisa. Utilizzando gli stessi termini elimina la confusione per i membri del team (non solo i nuovi membri — veterani, anche). Consulta il glossario dei termini e degli acronimi comuni qui sotto per aiutarti a sviluppare le basi della terminologia.

Usa strumenti con tracciabilità End-to-End

Nella sua forma più semplice, la tracciabilità può essere ottenuta con documenti Word e fogli di calcolo, ma generano così tanto lavoro manuale (e sono così soggetti a errori) che vorrai iniziare con uno strumento dedicato.

“Una matrice di traccia accurata è preziosa quando si esegue l’analisi di regressione per determinare cosa deve essere nuovamente testato dopo una modifica del prodotto o una correzione di bug.”- Megan Martin, V&V Consultant

L’utilizzo di uno strumento con una forte capacità di tracciamento dei requisiti-test-to-results ti aiuterà a identificare i buchi nella copertura e a fornire avvisi precoci su aree fragili o non testate nel prodotto.

Ottieni la tracciabilità end-to-end ora

Costruisci la tua matrice di traccia mentre vai

“Si può essere tentati di rimandarla, ma non aspettare di costruire la tua matrice di traccia!”dice Megan. Costruire la tua tracciabilità man mano che vai manterrà i buchi dallo sviluppo inosservato. Poche cose sono più difficili da recuperare rispetto alla scoperta di aver perso requisiti critici, funzionalità di mitigazione del rischio o test essenziali proprio quando pensi che il tuo lavoro di sviluppo sia completo.

Ci vuole molto meno sforzo di manutenzione per mantenere la tracciabilità come le vostre esigenze, disegni, e test evolvono di quanto non faccia per correggere i buchi critici nella progettazione e sviluppo all’ora 11th. Questo sforzo può anche aiutare a identificare quanto lavoro è rimasto, dove potrebbe essere necessario aggiungere sviluppo o personale di test, o quando si dovrebbe rivalutare i programmi di consegna.

Integra la tracciabilità dei requisiti& Test con tracciamento delle anomalie

La possibilità di collegare le anomalie direttamente a un requisito migliora la comunicazione tra tester e sviluppatori. È estremamente utile. La generazione di anomalie direttamente da un errore del protocollo di test significa che vengono acquisiti maggiori dettagli sul problema. Di conseguenza, i problemi possono essere più facilmente documentati, riprodotti, corretti e riprovati.

Scegliere Strumenti che È Possibile Personalizzare per il Vostro Metodo

“Qualunque sia il modello di sviluppo selezionati, Agile, iterativo, modificato Cascata — se si vuole scegliere V&V strumenti che ti servono, adattando per il vostro processo, piuttosto che costringendola ad adattare il vostro processo di servire lo strumento”, consiglia di Megan.

Gli strumenti di sviluppo di dispositivi medici che scegli dovrebbero aumentare l’accuratezza e l’efficacia del lavoro svolto dal tuo team e non aggiungere inutili spese generali alle loro attività quotidiane. Un buon strumento fornisce guard rail per garantire che le cose importanti siano sempre fatte. Offre al team la flessibilità di produrre viste e report ad hoc per utilizzare meglio (ed esplorare) i dati acquisiti. Fornisce V&V acquisizione e reporting dei dati mirati per rendere la produzione di report semplice e ripetibile.

Prendi tempo per definire come vuoi che gli strumenti supportino il tuo team prima di scegliere. Quindi configura i tuoi strumenti in base alle esigenze del tuo team.

Riunire tutto

La validazione e la verifica della progettazione sono componenti essenziali per il successo dello sviluppo del dispositivo. Con la comprensione condivisa tra il team, così come gli strumenti giusti, si dispone di un quadro solido per ottenere il vostro dispositivo sul mercato.
GUARDA L’INTERA DEMO NOW >>

Semplificare V&V Con Elica ALM

Vedere come Elica ALM può accelerare il dispositivo medico sviluppo.

Esplora Helix ALM

*Ancora una volta, grazie a V& V esperto Megan Martin che ha fornito informazioni preziose per questo blog!

V&V: Glossario dei termini

Risultato effettivo: cosa fa effettivamente un sistema quando viene eseguita un’azione.

Anomalia – Quando un sistema non agisce come previsto. Ad esempio, un bug, un errore o un errore di test.

Deliverable – Un oggetto obbligatorio prodotto come risultato dell’esecuzione del progetto, di solito documenti in sforzi di convalida.

Deviazione-Quando un processo o una procedura non può essere eseguita come definito e viene utilizzato un metodo o un materiale alternativo.

Risultato atteso: cosa dovrebbe fare un sistema quando viene eseguita un’azione.

Test di integrazione – Test condotti utilizzando due o più sottosistemi per verificare l’interazione e le interdipendenze dei sottosistemi.

Protocollo-Una raccolta di casi di test utilizzati per documentare i test di sistema.

Qualificazione-Un protocollo di test che indica che un sistema soddisfa una raccolta definita di requisiti.

Quality Assurance – Membri del team incaricati di garantire la qualità del prodotto o l’integrità del processo.

Requisito-Qualcosa che un sistema deve essere in grado di fare.

Convalida retrospettiva-Convalida di un sistema già esistente.

Specifica-Un documento che delinea i requisiti per un sistema o un componente.

Subsystem Test-Test condotti su un importante sottosistema o gruppo di componenti.

Sistema-La cosa in fase di convalida.

Proprietario del sistema-L’individuo che è in ultima analisi responsabile di un sistema.

System Test-Test condotti utilizzando il sistema nel suo complesso.

Test Case-Una procedura documentata, utilizzata per verificare che un sistema soddisfi un requisito o una raccolta di requisiti.

Piano di test-Una metodologia di test stabilita per garantire che un sistema soddisfi i requisiti.

Test Step – Una singola riga di un test case. Dovrebbe includere istruzioni, risultato atteso e risultato effettivo.

Tracciabilità: la capacità di garantire che i requisiti delineati nelle specifiche siano stati testati. Spesso catturato in una matrice di tracciabilità dei requisiti.

Unit Test-Test condotti su un’unità software o hardware o modulo di basso livello.

Convalida-Stabilire con prove oggettive che le specifiche del dispositivo sono conformi alle esigenze dell’utente e agli usi previsti.

Validation Package-Una raccolta di documenti prodotti durante un progetto di convalida.

Verifica-conferma mediante esame e fornitura di prove oggettive che i requisiti specificati sono stati soddisfatti.

V&V Plan – Un piano che definisce i requisiti da verificare e convalidare, e la manodopera, gli individui responsabili, gli strumenti, i metodi, le risorse, e il programma per il V & V sforzo.

Comune di Validazione del progetto Acronimi

CC – Change Control

CCB – Change Control Board (un gruppo di individui che controllano quali cambiamenti sono fatti e quando)

DS – Specifiche di Progettazione

GRASSI – Prove di Accettazione in Fabbrica

FS – Specifica Funzionale

FRS – Funzionali la Specifica dei Requisiti (Vedi Specifiche Funzionali)

GCP – Buona Pratica Clinica (linee guida di qualità per operazioni cliniche)

GLP – Buona Pratica di Laboratorio (linee guida di qualità per il laboratorio farmaceutico operazioni)

GMP – Good Manufacturing Pratica (linee guida per la qualità per la fabbricazione di dispositivi o farmaci)

RTM – Requisito Matrice di Tracciabilità

TRISTE – Architettura del Software di Documento o di una Architettura di Sistema il Documento

SAT – Site Acceptance Test

SCCB – Modifica Software della Scheda di Controllo (come CCB, ma per il software)

SDD – Software di Progettazione di Dettaglio del Documento

SDS – Software Specifiche di Progettazione

specifiche tecniche – Specifiche

SRS – Software requirements Specification

TM – Matrice di Tracciabilità

UAT – User Acceptance Testing

URS – User requirement Specification

UUT – Unit Under Test

VMP – Validation Master Plan

VP – Validation Plan

V&V – Verification and Validation