Designvalidering vs. Verifisering: 6 Tips for Utvikling av Medisinsk Utstyr

men du vil selvfølgelig ha flere detaljer og eksempler. Vi begynner med validering.

Hva Er Design Validering Nøyaktig?

design validering Er en testprosess der du beviser («validere») at enheten du har bygget fungerer for sluttbrukeren som tiltenkt.

Offisielt ord FRA FDA (21 CFR 820.3) sier at designvalidering er » etablering av objektive bevis på at enhetsspesifikasjoner er i samsvar med brukerbehov og tiltenkt bruk(er).»

Design Validering Eksempel

la oss tenke oss at vi bygger en ventilator som holder en pasient puste, og at brukeren vil at den skal fungere under pasienttransport.

Først må vi definere våre brukerbehov. Brukeren ønsker å flytte pasienter mens de er på ventilatoren. Men hva er det de egentlig prøver å gjøre? «Transport» kan omfatte å flytte pasienten på sykehuset. Eller kan inkludere transport via ambulanse eller med fly. Et brukerbehov, for eksempel, kan se ut som følgende.

Brukerbehov

UsNe-0001

ventilatoren er egnet for bruk under sykehustransport av pasienter.

denne brukeren trenger vil bli brutt ned i produktkrav og design spesifikasjoner for å designe og bygge produktet. (Vi ser på dem i et øyeblikk under designbekreftelse.)

Før det, la oss undersøke våre brukerbehov og se hva design validering test tilfeller kan være nødvendig. Valideringstesting av brukerbehovet vårt kan se slik ut.

Bruker Trenger		Validering Test		UsNe-0001	ventilatoren er egnet for bruk under sykehustransport av pasienter.	TCase-0001	Valideringstest Suite: Test at ventilatoren lett kan rulles av 15 medlemmer av sykehustransportpersonalet.
TCase-0002	Validering Test Suite: Test at ventilatoren opererer innenfor sine spesifikasjoner mens de rulles ned ganger, over dørstopp og over heis terskler.
TCase-0003	Validering Test Suite: Test at ventilatoren opererer innenfor sine spesifikasjoner mens overgangen MELLOM VEKSELSTRØM og batteridrift.

Valideringstesting vil omfatte testtilfeller, testsuiter, eller til og med kliniske studier designet for å bevise at produktet, som bygget, fungerer i henhold til brukerens forventninger under de forhold hvor de har tenkt å bruke det. Siden disse testene skal kjøres på produksjonsenheter eller produksjonsekvivalenter, er designvalideringstester ofte de siste testene som utføres.

I utgangspunktet, i design validering, må vi vise at produktet oppfyller brukerens behov.

forresten viser tabellen over også sporbarheten mellom brukerbehov og testtilfeller. Denne spormatrisen gir en del av V&V-bevis som FDA krever.

Hva Er Designverifisering FOR FDA?

designbekreftelse er der du tester («verifiser») at designutgangene dine samsvarer med designinngangene dine.

Igjen, IFØLGE FDA, er designbekreftelse » bekreftelse ved undersøkelse og bestemmelse av objektive bevis på at spesifiserte krav er oppfylt.»

Husk at mens det vil innebære testing, er det andre akseptable verifikasjonsaktiviteter.

de kan inkludere tester, inspeksjoner og analyser (for mer om DETTE, sjekk UT FDA Design Control Guidance).

Design Verifisering Eksempel

la oss gå tilbake til vår ventilator eksempel. Vi har identifisert våre brukerbehov; la oss nå identifisere hva enheten må gjøre og hvordan den må gjøre det.

for å oppnå dette må vi definere spesifikke produktkrav. For eksempel:

• hva er maksimal belastning for en pasient? Hvor mye luft trenger ventilatoren å bevege seg?)
• hvor lenge må batteriet vare? Hvor lang tid tar transporten?)
• Hvilke forhold vil de møte under transport? (Dør syltetøy? Heiser?)
• Er det noen regulatoriske standarder som må oppfylles? Sikkerhetsstandarder?)

«Klare, komplette, utvetydige, testbare krav er en nøkkelkomponent i et vellykket utviklingsprosjekt. Utilstrekkelige krav fører til bortkastet tid, designfeil, omfattende omarbeiding og skjøre eller feilutsatte produkter.–- Megan Martin,V&V Consultant

Dette er «hva» – delen av å definere enhetsegenskaper. Hva skal enheten gjøre? Produktkrav (ofte inkludert i et produktkrav dokument) for våre brukerbehov kan se ut nedenfor.

Produktkrav

PrRq-0001	ventilatoren skal ha en maksimal innstilling på 2-liters volumstyrte åndedrag ved 20 åndedrag per minutt.
PrRq-0002	ventilatoren skal kjøre på batteristrøm ved maksimale innstillinger i minst 90 minutter.
PrRq-0003	ventilatoren skal kunne monteres på et rullende støttestativ.
PrRq-0004	ventilatoren og stativet skal være i stand til å krysse typiske sykehus dør og heis terskler.

Endelig trenger vi designspesifikasjon. «Vi har allerede definert hva vi skal oppnå, og nå må vi definere hvordan Vi skal gjøre det,» sier Megan. Dette kan gjøres på en rekke måter, inkludert skriftlige spesifikasjoner, elektriske eller mekaniske tegninger, komponentinnkjøpsspesifikasjoner eller andre metoder.

designspesifikasjonene og tegningene kan for eksempel vise følgende.

Designspesifikasjoner

DSpec-0001	en turbin som kan generere opptil 40 liter luft per minutt.
DSpec-0002	en litiumionbatteripakke vurdert for minst 100 Amp Timer.
DSpec-0003	braketten for rullende stativet bruker en stål spak-handling klemme vurdert for 22 lbs.
DSpec-0004	stativbasen er 22 » bred med 5 hjul.
DSpec-0005	stativhjulene har en 4 » diameter.

designbekreftelse gir bevis (testresultater) på at designutgangene (faktisk produkt) oppfyller designinngangene (produktkrav og designspesifikasjoner). Avhengig av varen blir bekreftet, en test sak eller test suite ville bli kjørt, eller en inspeksjon eller analyse gjort for å gi den nødvendige bevis.

tabellene nedenfor illustrerer hvordan det kan se ut. De viser også sporbarheten FDA forventer.

Produktkrav		Verifiseringstest
PrRq-0001		ventilatoren skal ha en maksimal innstilling på 2-liter volumstyrt pust ved 20 puste per minutt.	TCase-0004	Testtilfelle: Bekreft maksimale pusteinnstillinger eller kombinasjoner av pusteinnstillinger.
PrRq-0002	ventilatoren skal kjøre på batteristrøm ved maksimale innstillinger i minst 90 minutter.	TCase-0005	Testpakke: Bekreft kjøretid på maksimale innstillinger med et fulladet nytt batteri.
		TCase-0006	Test suite: Bekreft kjøretid på maksimale innstillinger med et batteri som har vært gjennom 50 ladesykluser.
PrRq-0003	ventilatoren skal kunne monteres på et rullende støttestativ.	TCase-0007	Demonstrasjonstest: Demonstrer at ventilatoren kan festes og løsnes fra rullestativet.
PrRq-0004	ventilatoren og stativet skal kunne krysse typiske sykehusdører og heisterskler.Tcase-0008	Ekstern Test: Test utført av en testtjeneste for å verifisere ventilator og stativ kan rulles over en terskel uten å tippe per Iec 60601-1 Medisinsk Elektrisk Standard.

Verifisering av produktkravene, som ovenfor, viser at produktet gjør det vi sa det ville gjøre.

Verifisering av designspesifikasjonene, som vi viser neste, viser at produktet gjør det slik vi sa det ville gjøre det.

Design Spesifikasjon		Verifiseringstest
DSpec-0001	en turbin som kan generere 40 liter luft per minutt.TCase-0009	Test Suite: Bekreft luftgenerering med turbin ved 40 lpm på ENTEN VEKSELSTRØM eller batteristrøm.
DSpec-0002	en litiumionbatteripakke vurdert for 100 Amp Timer.	TCase-0010	Inspeksjon Test: Bekreft batteri innkjøp spec viser typen er litium ion.TCase-0011	Analysetest: Samle testdata Og gjør dataanalyse for å demonstrere batteriets ytelse over batteriets levetid vil møte eller overstige 100 Amp Timer.
		DSpec-0003	braketten for rullende stativet bruker en stål spak-handling klemme vurdert for 22 lbs.TCase-0012	Inspeksjon Test: Kontroller del spesifikasjon er for en stål spak-handling klemme vurdert for 22 lbs eller mer.
DSpec-0004	stativbasen er 22 » bred med 5 hjul.	tcase-0013	Testtilfelle: Måle basediameter; telle hjul; måle hjuldiameter
DSpec-0005	stativhjulene har en 4″diameter.

I hovedsak, i designbekreftelse, må Vi demonstrere at produktet vi bygget er produktet vi sa vi skulle bygge.

når samlet i En V& V Rapport, kombinasjonen av verifisering og validering testresultater, sammen med sporbarhet tilbake til brukerens behov, produktkrav, og design spesifikasjoner, gir en del av bevisene FDA krever når du sender inn en medisinsk enhet for klarering.

Validering vs Verifikasjonssammendrag

her er en kort, hvis litt forenklet, oppsummering av viktige forskjeller.

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.
Inkluderer systeminspeksjoner, analyse og testing.	Inkluderer testing av produksjonsekvivalente enheter under reelle bruksforhold.
Inkluderer rapporter om testing utført, testresultater og sporbarhet. Rapportene blir gjennomgått, godkjent og signert.	Inkluderer sluttrapport, med testresultater og sporbarhet, klar for regulatorisk gjennomgang. Rapportene blir gjennomgått, godkjent og signert.

Grunnleggende Om Designvalideringsprosessen

designvalideringsprosessen vil i stor grad bestå av å teste enheten. Du kan utføre dette på flere måter, avhengig av omstendighetene. Aktiviteter kan omfatte:

• Sammenligning med lignende utstyr som utfører for lignende formål.
• Simulerer funksjonalitet gjennom matematisk modellering.
• Tester det endelige designet for å bevise at systemet fungerer som definert i brukerens behov.

Testplan, testtilfeller, testutførelsesregistre og testresultater skal dokumenteres og vedlikeholdes som en del av designregistre. Validering, i sin helhet, er ikke resultatet av en enkelt aktivitet, men samlingen av resultater fra alle valideringsaktiviteter.

Grunnleggende Om Designverifikasjonsprosess

Verifisering kan reduseres til en enkel fem-trinns prosess.

Identifisere og Forberede

Identifisere den beste tilnærmingen for å gjennomføre verifisering. Bestem hva du vil måle og hvordan du vil måle det. Du vil også vurdere de nødvendige ressursene, arbeidskraften og verktøyene for vellykket verifisering.

Planlegging

Planlegging for verifisering skjer gjennom hele prosjektets livssyklus. Du vil utvikle testplanen, som fanger kritiske milepæler. Planen må oppdateres når det gjøres endringer i designinngangene.

Utvikling

Produktutvikling begynner! Det utføres ved hjelp av valgmetoden (Scrum, Foss, hybrid, etc.). Denne delen av prosessen inkluderer også skriving, testkjøring og godkjenning av testtilfeller som skal brukes til verifisering.

Utføring

Testprosedyrer utføres som planlagt. Eventuelle ugyldige resultater dokumenteres og gjennomgås, og enten aksepteres eller logges som feil. Feil i produktet løses og frigis, og regresjonstesting utføres. En sporbarhetsmatrise er opprettet for å verifisere at designinnganger identifisert i verifikasjonstestplanen er testet og bestått.

Rapportering

Rapportering utføres på slutten av hver verifikasjonsfase. Detaljerte rapporter inkluderer konfigurasjonsadministrasjon og utgivelsesrapporter, testresultater etter testtype eller produktversjon og problemer som ble funnet under verifikasjonsaktiviteten. En sporbarhetsrapport for designbekreftelse viser testresultater og dekning for kravene. Endelig, vurderinger er fullført og godkjent etter hver design verifikasjon aktivitet.

6 Tips for Bedre Validering & Verifikasjon

her er tips for å sikre at du får mest mulig ut av valideringen & verifiseringsaktiviteter.

Planlegg Fremover (Og Test Tidlig)

Ha en solid plan på forhånd og sløyfe alle inn. Inkluder testingeniører tidlig i utviklingsplanlegging for å sikre at krav og design er klare, komplette og testbare. Sier Megan, » Tidlig utvikling av testmetoder kan kaste lys over teknologiproblemer før de blir store hindringer.»Tidlig testutvikling kan også gi testverktøy. Disse kan deretter brukes til å fremskynde produktutviklingsprosessen, samt gi testbevis under formell testing.

Bruk Delt Nomenklatur

Å få teamet ditt på samme side er avgjørende for vellykket designvalidering & verifisering. En del av å komme på samme side betyr å bruke en delt terminologi. Å bruke de samme begrepene eliminerer forvirring for teammedlemmer(ikke bare nye medlemmer — veteraner også). Se ordliste og vanlige akronymer nedenfor for å bidra til å utvikle grunnlaget for terminologi.

Bruk Verktøy med Ende-Til-Ende Sporbarhet

på sitt enkleste, kan sporbarhet oppnås med word-dokumenter og regneark, men de genererer så mye manuelt arbeid (og er så utsatt for feil) at du vil ønske du startet med et dedikert verktøy.

«en nøyaktig sporingsmatrise er uvurderlig når du gjør regresjonsanalyse for å bestemme hva som skal testes etter en produktendring eller en feilretting.–- Megan Martin, v&V Consultant

Få ende-til-ende sporbarhet nå

Bygg Din Trace Matrix Som Du Går

«Det kan være fristende å sette den av, men ikke vent å bygge din trace matrix!»sier Megan. Bygge din sporbarhet som du går vil holde hull fra å utvikle ubemerket. Få ting er vanskeligere å gjenopprette fra enn å oppdage at du har savnet kritiske krav, risikoreduserende funksjoner eller viktige tester akkurat når du tror utviklingsarbeidet er fullført.Det tar mye mindre vedlikeholdsinnsats for å opprettholde sporbarhet etter hvert som dine krav, design og tester utvikler seg enn det gjør for å lappe kritiske hull i design og utvikling i 11.time. Denne innsatsen kan også hjelpe deg med å identifisere hvor mye arbeid som er igjen, hvor du kanskje må legge til utviklings-eller testpersonale, eller når du skal revurdere leveringsplaner.

Integrere Krav Sporbarhet & Testing med Anomali Sporing

å kunne koble anomalier direkte til et krav forbedrer kommunikasjonen mellom testere og utviklere. Det er svært nyttig. Generere anomalier direkte fra en testprotokollfeil betyr at flere detaljer om problemet er fanget. Som et resultat kan problemer lettere dokumenteres, reproduseres, løses og testes på nytt.

Velg Verktøy du Kan Tilpasse Til Din Metode

» uansett utviklingsmodell du har valgt-Smidig, iterativ, modifisert Foss — du vil velge V&v verktøy som tjener deg ved å tilpasse til prosessen din, i stedet for å tvinge deg til å tilpasse prosessen for å betjene verktøyet,» råder Megan.

utviklingsverktøyene for medisinsk utstyr du velger, bør legge til nøyaktigheten og effektiviteten til arbeidet ditt team gjør, og ikke legge til unødvendig overhead til sine daglige oppgaver. Et godt verktøy gir vaktskinner for å sikre at de viktige tingene alltid gjøres. Det gir teamet fleksibilitet til å produsere ad hoc visninger og rapporter for å bedre bruke (og utforske) dataene du har fanget. Det gir V & v målrettet datafangst og rapportering for å gjøre produksjon av rapporter enkel og repeterbar.

Ta deg tid til å definere hvordan du vil at verktøy skal støtte teamet ditt før du velger. Deretter konfigureres verktøyene til teamets behov.

Designvalidering og verifisering Er viktige komponenter for vellykket utvikling av enheter. Med felles forståelse blant teamet, samt de riktige verktøyene, har du solid rammeverk for å få enheten til markedet.
SE HELE DEMOEN nå >>

Forenkle V&V Med Helix ALM

se hvordan helix alm kan akselerere utviklingen av medisinsk utstyr.

Utforsk Helix ALM

*igjen, takket Være V & v ekspert Megan Martin som ga uvurderlig innsikt til denne bloggen!

V&V: Ordliste

Faktisk Resultat – Hva et system faktisk gjør når en handling utføres.

Anomali – Når et system ikke fungerer som forventet. For eksempel en feil, feil eller testfeil.

Deliverable-et obligatorisk objekt produsert som et resultat av prosjektgjennomføring, vanligvis dokumenter i valideringsarbeid.

Avvik – Når en prosess eller prosedyre ikke kan utføres som definert, og en alternativ metode eller materiale brukes.

Forventet Resultat – Hva et system skal gjøre når en handling utføres.

Integrasjonstest-Testing utført ved hjelp av to eller flere delsystemer for å verifisere interaksjon og gjensidig avhengighet av delsystemene.

Protocol-en samling av testtilfeller som brukes til å dokumentere systemtesting.

Kvalifikasjon-en testprotokoll som angir at et system oppfyller en definert samling av krav.

Kvalitetssikring-Teammedlemmer som har som oppgave å sikre produktkvalitet eller prosessintegritet.

Krav – noe et system må kunne gjøre.

Retrospektiv Validering-Validering av et system som allerede eksisterer.

Spesifikasjon-et dokument som beskriver kravene til et system eller en komponent.

Subsystem Test-Testing utført på et større delsystem eller gruppe av komponenter.

System-saken gjennomgår validering.

Systemeier-personen som er ansvarlig for et system.

Systemtest-Testing utført ved hjelp av systemet som helhet.

Testcase-en dokumentert prosedyre, som brukes til å teste at et system oppfyller et krav eller samling av krav.

Testplan-en testmetodikk etablert for å sikre at et system oppfyller kravene.

Test Trinn-en individuell linje av et testfall. Det bør inneholde instruksjoner, forventet resultat og faktisk resultat.

Sporbarhet – evnen til å sikre at kravene i spesifikasjonene er testet. Ofte fanget i en krav sporbarhet matrise.

Unit Test-Testing utført på en programvare – eller maskinvareenhet eller lavt nivå modul.

Validering-Etablering av objektive bevis på at enhetsspesifikasjoner er i samsvar med brukerbehov og tiltenkt bruk(er).

Valideringspakke – en samling dokumenter produsert under et valideringsprosjekt.

Verifikasjon-bekreftelse ved undersøkelse og bestemmelse av objektivt bevis på at spesifiserte krav er oppfylt.

V& V Plan-en plan som definerer kravene som skal verifiseres og valideres, og arbeidskraft, ansvarlige personer, verktøy, metoder, ressurser og tidsplan for V&v innsats.

Vanlige Design Validering Akronymer

CC – Change Control

CCB – Change Control Board (en gruppe individer som kontrollerer hvilke endringer som gjøres og når)

DS – Design Spesifikasjon

FAT – Factory Acceptance Testing

FS – Functional Specification

FRS – Functional Requirement Specification (Se Functional Specification)

GCP – God Klinisk Praksis (kvalitetsretningslinjer for kliniske operasjoner)

glp – God Laboratoriepraksis (kvalitetsretningslinjer for farmasøytiske laboratorieoperasjoner)

gmp – god produksjon SAD – Programvarearkitektur Dokument Eller Systemarkitektur Dokument

SAT – Site Aksept Testing

SCCB – Programvare Endring Kontrollkort (samme SOM CCB, men for programvare)

SDD – Programvare Detalj Design Dokument

SDS – Programvare Design Spesifikasjon

Spec – Spesifikasjon

SRS – Programvare krav spesifikasjon

tm – sporbarhet matrise

uat – bruker aksept testing

Urs – Brukeren Krav Specification

UUT – Unit Under Test

VMP – Validation Master Plan

VP – Validation Plan

V&V – Verification and Validation