Design Validace versus Verifikace: 6 Tipy pro Rozvoj Lékařské Zařízení

Pokud budete vyvíjet produkty — zdravotnické prostředky, zejména — pak jste slyšeli pojmy ověření návrhu a ověřování návrhu (také volal V&V). Zde vysvětlíme, jaké jsou tyto dvě činnosti, rozdíl mezi nimi, plus sdílet tipy, jak co nejlépe využít své úsilí.

Poznámka: K ověření, že tento obsah bude užitečné pro vás, spojili jsme se s Megan Martin, lékařské zařízení V&V Consultant s více než 30 let zkušeností v lékařském zařízení V&V, lékařské zařízení, software, produkty a software kvalita a USA a mezinárodní zařízení regulační podání. Její postřehy a příklady najdete v celém textu!

následujte nebo přeskočte do sekce, kterou hledáte:

  • ověření návrhu vs. ověření návrhu
  • co je ověření návrhu přesně?
  • co je ověření návrhu pro FDA?
  • Ověření vs Ověření Shrnutí
  • Základy Designu Validace
  • Základy Ověření Návrhu Procesu
  • 6 Tipů pro Lepší Validaci & Ověřování
  • Video: Zjednodušení V & V
  • V&V: Slovníček Pojmů

Design Validace vs. Ověření Návrhu: Jaký je Rozdíl?

Jaký je rozdíl mezi validací a ověřování? Jednoduše řečeno, ověření návrhu určuje, zda vytváříte správný produkt. Funguje zařízení tak, jak je určeno koncovým uživatelům? Ověření návrhu určuje, zda stavíte produkt správně. Jsou konstrukční výstupy odpovídající konstrukčním vstupům?

to je jednoduchý rozdíl, jak je jasně znázorněno v grafu níže.

Obraz blogu ověření návrhu grafu
ověření Návrhu: budujete správný produkt? Ověření návrhu: stavíte produkt správně?

ale samozřejmě chcete více podrobností a příkladů. Začneme s ověřením.

co je ověření návrhu přesně?

ověření návrhu je testovací proces, kterým prokážete („validate“), že zařízení, které jste vytvořili, funguje pro koncového uživatele tak, jak bylo zamýšleno.

oficiální slovo FDA (21 CFR 820.3) uvádí, že validace návrhu je “ objektivním důkazem, že specifikace zařízení odpovídají potřebám uživatelů a zamýšlenému použití.“

Ověření Návrhu Příklad:

představme si, že stavíme ventilátor, který udržuje pacienta dýchat, a to, že uživatel chce, aby to fungovalo pacienta během dopravy.

nejprve musíme definovat naše potřeby uživatelů. Uživatel chce přesunout pacienty, zatímco jsou na ventilátoru. Ale o co se vlastně snaží? „Transport“ může zahrnovat přesun pacienta v nemocnici. Nebo může zahrnovat přepravu sanitkou nebo letecky. Například potřeba uživatele může vypadat následovně.

Uživatel

UsNe-0001 ventilátor je vhodný pro použití v nemocnici, přepravu pacientů.

Tento uživatel bude rozdělena do produktu požadavky a specifikace návrhu s cílem navrhnout a vytvořit produkt. (Na ty se podíváme za chvíli pod návrhovým ověřením.)

předtím se podívejme na naši potřebu uživatelů a uvidíme, jaké testovací případy ověření návrhu mohou být vyžadovány. Validační testování potřeb našich uživatelů může vypadat takto.

Uživatel
Potřebujete
Ověřování
Test
UsNe-0001 ventilátor je vhodný pro použití v nemocnici, přepravu pacientů. TCase-0001 validační testovací sada: Test, že ventilátor může být snadno válcován 15 členy personálu nemocniční dopravy.
TCase-0002 validační testovací sada: Otestujte, zda ventilátor pracuje v rámci svých specifikací při válcování po chodbách, přes zaseknutí dveří a přes Prahy výtahu.
TCase-0003 Ověřovací Test Suite: Zkontrolujte, že ventilátor pracuje v rámci specifikace při přechodu mezi AC napájení a provoz na baterie.

Validace by měla zahrnovat testovací případy, testovací sady, nebo dokonce klinické studie navrženy tak, aby prokázat, že výrobek, tak jak je postaven, funguje podle očekávání uživatele za podmínek, kde mají v úmyslu ji použít. Protože tyto testy by měly probíhat na výrobu nebo produkci ekvivalentních jednotek, ověření návrhu testy jsou často poslední provedené zkoušky.

v zásadě musíme při validaci návrhu prokázat, že produkt splňuje potřeby uživatele.

mimochodem, výše uvedená tabulka také ukazuje sledovatelnost mezi potřebami uživatelů a testovacími případy. Tato stopová matice poskytuje část V& v důkaz, který FDA vyžaduje.

co je ověření návrhu pro FDA?

ověření návrhu je místo, kde testujete („ověřte“), že výstupy návrhu odpovídají vstupům návrhu.

Opět platí, že podle FDA je ověření návrhu “ potvrzením zkouškou a poskytnutím objektivního důkazu, že byly splněny stanovené požadavky.“

mějte na paměti, že i když to bude zahrnovat testování, existují i jiné přijatelné ověřovací činnosti.

mohou zahrnovat testy, inspekce a analýzy (více o tom, podívejte se na FDA Design Control Guidance).

příklad ověření návrhu

vraťme se k našemu příkladu ventilátoru. Identifikovali jsme potřeby našich uživatelů; Nyní pojďme zjistit, co zařízení musí udělat a jak to musí udělat.

abychom toho dosáhli, musíme definovat specifické požadavky na produkt. Například:

  • jaká je maximální zátěž pro pacienta? (Kolik vzduchu potřebuje ventilátor k pohybu?)
  • jak dlouho musí baterie vydržet? (Jak dlouho trvá doprava?)
  • s jakými podmínkami se během přepravy setkají? (Zaseknutí dveří? Výtahy?)
  • existují nějaké regulační normy, které je třeba splnit? (Bezpečnostní normy?)

“ jasné, úplné, jednoznačné, testovatelné požadavky jsou klíčovou součástí úspěšného vývojového projektu. Nedostatečné požadavky vedou ke ztrátě času, chybám návrhu, rozsáhlým přepracováním a křehkým výrobkům náchylným k chybám.“- Megan Martin, V& v konzultant

Toto je „jaká“ část definování vlastností zařízení. Co přesně bude zařízení muset udělat? Požadavky na produkt (často obsažené v dokumentu o požadavcích na produkt) pro naši potřebu uživatele mohou vypadat níže.

Požadavky na Výrobek

PrRq-0001

ventilátor musí mít maximální nastavení 2-litrový objem kontrolovaných dechů na 20 dechů za minutu.

PrRq-0002

ventilátor musí běžet na baterie na maximální nastavení pro minimálně 90 minut.

PrRq-0003

ventilátor musí být schopen být namontován na válcování stojan.

PrRq-0004

ventilátor a stojan musí být schopny procházet typickými prahy dveří nemocnice a výtahu.

konečně potřebujeme specifikaci návrhu. „Už jsme definovali, čeho dosáhneme, a teď musíme definovat, jak to uděláme,“ říká Megan. Toho lze dosáhnout různými způsoby, včetně písemných specifikací, elektrických nebo mechanických výkresů, specifikací nákupu součástí nebo jiných metod.

například specifikace návrhu a výkresy mohou zobrazovat následující.

Design Specifikace

DSpec-0001

turbína, která může generovat až 40 litrů vzduchu za minutu.

DSpec-0002

lithium-iontová baterie určená pro alespoň 100 ampérhodin.

DSpec-0003

držák pro válcování stát používá ocelová páka-akce svorky nastavené na 22 kg.

DSpec-0004

základna stojanu je 22 “ široká s 5 koly.

DSpec-0005

stojanová kola mají průměr 4″.

Design ověření poskytuje důkazy (výsledky testů), že design výstupy (skutečnému produktu) splnit design vstupy (požadavky na produkt a návrh specifikace). V závislosti na ověřené položce by byl spuštěn testovací případ nebo testovací sada nebo provedena inspekce nebo analýza za účelem poskytnutí požadovaných důkazů.

níže uvedené tabulky ilustrují, jak by to mohlo vypadat. Ukazují také sledovatelnost, kterou FDA očekává.

Produkt, Požadavek Ověřování
PrRq-0001 ventilátor musí mít maximální nastavení 2-litr objemu-řízené dechy na 20 dechů za minutu. TCase-0004 zkušební případ: ověřte maximální nastavení dechu nebo kombinace nastavení dechu.
PrRq-0002 ventilátor musí běžet na baterie na maximální nastavení pro minimálně 90 minut. TCase-0005 testovací sada: Ověřte dobu běhu při maximálním nastavení pomocí plně nabité nové baterie.
TCase-0006 testovací sada: ověřte dobu běhu při maximálním nastavení pomocí baterie, která prošla 50 nabíjecími cykly.
PrRq-0003 ventilátor musí být možné namontovat na valivý opěrný stojan. TCase-0007 Prokazovací Zkouška: Prokázat, že ventilátor může být připojen a odpojen od rolling stát.
PrRq-0004 ventilátor a stojan musí být schopen procházet typické nemocniční dveře a výtah prahy. Tcase-0008 externí Test: Test provedený zkušební službou k ověření ventilátoru a stojanu lze převrátit přes práh bez vyklápění podle lékařské elektrické normy IEC 60601-1.

Ověření požadavků na výrobek, jak je uvedeno výše, ukazuje, že produkt dělá to, co jsme říkal, že to udělá.

ověření konstrukčních specifikací, které ukážeme dále, ukazuje, že produkt to dělá tak, jak jsme řekli, že to udělá.

technické údaje Ověřování
DSpec-0001 turbína, která může generovat 40 litrů vzduchu za minutu. TCase-0009 testovací sada: ověřte výrobu vzduchu turbínou při 40 lpm při napájení střídavým proudem nebo baterií.
DSpec-0002 lithium-iontové baterie, hodnocené na 100 ampérhodin. TCase-0010 inspekční Test: ověřte, zda je typ nákupu baterií lithium-iontový.
TCase-0011 Analýza Testu: Shromažďovat testovací data a provést analýzu dat prokázat baterie výkon v průběhu životnosti baterie bude splňovat nebo překračovat 100 ampérhodin.
DSpec-0003 držák pro válcování stát používá ocelová páka-akce svorky nastavené na 22 kg. TCase-0012 Kontrolní Test: Ověření součástí specifikace je pro ocelová páka-akce svorky nastavené na 22 liber nebo více.
DSpec-0004 základna stojanu je 22 “ široká s 5 koly.

TCase-0013

Testovací Případ: Změřte průměr základny; počet kol; změřte průměr kola
DSpec-0005 stojan kola mají 4″ průměr.

v Podstatě, v ověřování návrhu, musíme prokázat, že produkt, který jsme postavili, je výrobek jsme se, že budeme stavět.

Když shromážděny v V&V. Report, kombinace a ověřování, výsledky zkoušek, spolu s sledovatelnosti zpět na uživatelské potřeby, požadavky na výrobek a design specifikace, poskytuje část důkazů, FDA vyžaduje, aby při předložení lékařské zařízení pro odbavení.

validace vs Verification Summary

zde je stručné, i když mírně zjednodušené shrnutí klíčových rozdílů.

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.

zahrnuje kontroly systému, analýzu a testování.

zahrnuje testování výrobních ekvivalentních jednotek za podmínek reálného použití.

zahrnuje zprávy o provedených testech, výsledcích testů a sledovatelnosti. Zprávy jsou kontrolovány, schváleny a podepsány.

obsahuje závěrečnou zprávu s výsledky zkoušek a sledovatelností připravenou k regulačnímu přezkumu. Zprávy jsou kontrolovány, schváleny a podepsány.

Základy Designu Validace

ověření návrhu procesu se z velké části skládají z testování zařízení. Můžete to provést několika způsoby, v závislosti na okolnostech. Činnosti mohou zahrnovat:

  • ve srovnání s podobným zařízením prováděným pro podobné účely.
  • Simulace funkčnosti pomocí matematického modelování.
  • testování konečného návrhu, aby se prokázalo, že systém funguje tak, jak je definován v potřebách uživatele.

testovací plán, testovací případy, záznamy o provádění testů a výsledky testů by měly být zdokumentovány a udržovány jako součást konstrukčních záznamů. Validace jako celek není výsledkem jediné činnosti, ale shromažďování výsledků ze všech validačních činností.

základy procesu ověření návrhu

ověření lze redukovat na jednoduchý pětistupňový proces.

identifikace a příprava

určete nejlepší přístup k provádění ověření. Definujte, co budete měřit a jak to budete měřit. Budete také chtít zvážit požadované zdroje, pracovní sílu a nástroje pro úspěšné ověření.

plánování

plánování pro ověření probíhá v průběhu celého životního cyklu projektu. Vypracujete testovací plán, který zachycuje kritické milníky. Plán musí být aktualizován vždy, když jsou provedeny změny v návrhu vstupů.

vývoj

vývoj produktu začíná! Provádí se pomocí metodiky volby (Scrum, Vodopád, hybrid atd.). Tato část procesu zahrnuje také psaní, zkušební jízdu a schvalování zkušebních případů, které budou použity k ověření.

provádění

testovací postupy se provádějí podle plánu. Všechny neplatné výsledky jsou zdokumentovány a zkontrolovány a buď přijaty nebo zaznamenány jako vady. Vady produktu jsou vyřešeny a uvolněny a provádí se regresní testování. Je vytvořena matice sledovatelnosti, která ověřuje, že konstrukční vstupy identifikované v plánu ověřovacích testů byly testovány a předány.

hlášení

hlášení se provádí na konci každé fáze ověření. Podrobné zprávy zahrnují správu konfigurace a zprávy o vydání, výsledky testů podle typu testování nebo verze produktu a problémy zjištěné během ověřovací činnosti. Zpráva o ověření sledovatelnosti návrhu zobrazuje výsledky zkoušek a pokrytí požadavků. Nakonec jsou recenze dokončeny a schváleny po každé ověřovací činnosti návrhu.

6 Tipů pro Lepší Validaci & Ověřování

Zde jsou tipy, aby se ujistil, dostanete nejvíce z vašeho validace & ověřovací činnosti.

Plánujte dopředu (a testujte brzy)

mějte pevný plán předem a smyčku každého. Zahrňte testovací inženýry na začátku plánování vývoje, abyste se ujistili, že požadavky a design jsou jasné, úplné a testovatelné. Říká Megan, „včasný vývoj zkušebních metod může osvětlit technologické problémy dříve, než se stanou hlavními překážkami.“.“Včasný vývoj testů může také poskytnout testovací nástroje. Ty pak mohou být použity k urychlení procesu vývoje produktu a také k poskytnutí zkušebních důkazů během formálního testování.

použijte sdílenou nomenklaturu

získání týmu na stejné stránce je zásadní pro úspěšné ověření návrhu & ověření. Část dostat se na stejnou stránku znamená používat sdílenou terminologii. Používání stejných termínů eliminuje zmatek pro členy týmu (nejen pro nové členy-veterány). Níže naleznete Slovníček pojmů a běžných zkratek, které vám pomohou rozvinout základy terminologie.

Použití Nástroje S End-to-End Sledovatelnost

U jeho nejjednodušší, sledovatelnost může být dosaženo s dokumenty word a tabulky, ale vytvářejí tolik manuální práce (a jsou tak náchylné k chybám), že si budete přát, abyste začali s specializovaný nástroj.

„přesná stopa matice je neocenitelné, když dělá regresní analýzy určit, jaké by měly být znovu testovány po změny výrobku nebo opravy chyb.“–Megan Martin, V&V Poradce,

Pomocí nástroj se silným požadavky-na-test-výsledky trasování schopnosti vám pomůže identifikovat díry v pokrytí a dát včasné varování na křehké nebo nevyzkoušených oblastech v produktu.

Blog ALM Zpráva
Nástroje s end-to-end sledovatelnost zjednodušení vývoje zařízení. Zpráva o trasování je uvedena v Helix ALM.

Získat end-to-end sledovatelnost teď

Sestavte si Svůj Stopa Matice As you Go

„To může být lákavé, aby ho, ale nečekejte, aby budovat své stopy matice!“říká Megan. Budování vaší sledovatelnosti za pochodu zabrání vývoji děr bez povšimnutí. Jen málo věcí je těžší se zotavit, než zjistit, že jste zmeškali kritické požadavky, funkce zmírňující rizika nebo základní testy, když si myslíte, že je vaše vývojová práce dokončena.

zachování sledovatelnosti vyžaduje mnohem menší úsilí při údržbě, protože se vaše požadavky, návrhy a testy vyvíjejí, než oprava kritických děr v návrhu a vývoji v 11. hodině. Toto úsilí vám také může pomoci určit, kolik práce zbývá, kde budete možná muset přidat vývojový nebo testovací personál, nebo kdy byste měli přehodnotit dodací plány.

Blog ALM požadavek na zkušební provoz dokončení
Vyhněte 11 hodin mimořádné události! Zde je stav sledován mezi požadavky & dokončené testy v Helix ALM.

Integrovat Požadavky na Sledovatelnost & Testování S Anomálií Sledování

Být schopen propojit anomálie přímo požadavek, zlepšuje komunikace mezi testery a vývojáři. Je to velmi užitečné. Generování anomálií přímo z selhání testovacího protokolu znamená, že je zachyceno více podrobností o problému. V důsledku toho lze problémy snadněji dokumentovat, reprodukovat, opravovat a znovu testovat.

Blog ALM Anomálie Generace
anomálie vytvořené z neúspěšného testu, jak je znázorněno na Helix ALM.

Zvolte Nástroje Si Můžete Přizpůsobit Svůj Způsob

„Cokoliv vývoje modelu, který jste vybrali — Agilní, iterační, modifikovaný Vodopád — chcete si vybrat V&V nástroje, které vám slouží přizpůsobuje vaší proces, spíše než nutit, abyste přizpůsobit svůj proces sloužit nástroj,“ radí Megan.

lékařské přístroje, nástroje pro vývoj si vyberete by měl přidat na přesnost a efektivitu práce se váš tým dělá, a ne přidat zbytečné režijní náklady na jejich každodenní úkoly. Dobrý nástroj poskytuje ochranné lišty, aby bylo zajištěno, že důležité věci jsou vždy hotové. Poskytuje vašemu týmu flexibilitu při vytváření ad hoc pohledů a sestav pro lepší využití (a prozkoumání) zachycených dat. Poskytuje V& v cílený sběr dat a reporting, aby výroba zpráv jednoduché a opakovatelné.

Udělejte si čas, abyste definovali, jak chcete, aby nástroje podporovaly váš tým, než se rozhodnete. Pak si své nástroje nakonfigurujte podle potřeb vašeho týmu.

Blog ALM Taskboard
Agilní, Vodopád, hybridní? Vyberte nástroje, které odpovídají vašemu procesu. Zde, volitelné sprint desky v Helix ALM.

Přináší To Všechno Dohromady

ověření Návrhu a ověřování jsou nezbytné složky úspěšného vývoje zařízení. Se sdíleným porozuměním mezi týmem a správnými nástroji máte solidní rámec pro uvedení zařízení na trh.
SLEDOVAT CELÝ DEMO >>

Zjednodušení V&V. S Helix ALM

Podívejte se, jak Helix ALM může urychlit rozvoj lékařské zařízení.

Prozkoumejte Helix ALM

* opět díky v & v expert Megan Martin, který poskytl neocenitelný pohled na tento blog!

V& V: Slovníček pojmů

skutečný výsledek – co systém skutečně dělá, když je provedena akce.

anomálie – pokud systém nepůsobí podle očekávání. Například chyba, chyba nebo selhání testu.

dodání-povinný objekt vytvořený v důsledku realizace projektu, obvykle dokumenty v úsilí o ověření.

odchylka-když proces nebo postup nelze provést podle definice a použije se alternativní metoda nebo materiál.

očekávaný výsledek-co by měl systém dělat, když je provedena akce.

Integration Test-testování prováděné pomocí dvou nebo více subsystémů k ověření interakce a vzájemné závislosti subsystémů.

protokol-soubor testovacích případů používaných k dokumentování testování systému.

kvalifikace-testovací protokol označující, že systém splňuje definovanou sbírku požadavků.

zajištění kvality-členové týmu, kteří mají za úkol zajistit kvalitu produktu nebo integritu procesu.

požadavek-něco, co systém musí být schopen udělat.

retrospektivní validace-validace systému, který již existuje.

SPECIFIKACE-dokument popisující požadavky na systém nebo komponentu.

subsystém Test-testování prováděné na hlavním subsystému nebo skupině komponent.

systém-věc, která prochází validací.

vlastník systému – osoba, která je v konečném důsledku zodpovědná za systém.

System Test-testování prováděné pomocí systému jako celku.

testovací případ-zdokumentovaný postup, který se používá k testování, že systém splňuje požadavek nebo soubor požadavků.

testovací plán-metodika testování vytvořená s cílem zajistit, aby systém splňoval požadavky.

testovací krok-individuální řádek testovacího případu. Měl by obsahovat pokyny, očekávaný výsledek a skutečný výsledek.

sledovatelnost-schopnost zajistit, aby byly testovány požadavky uvedené ve specifikacích. Často zachycen v matici sledovatelnosti požadavků.

Unit Test-testování prováděné na softwarové nebo hardwarové jednotce nebo modulu nízké úrovně.

validace-objektivním důkazem prokázání, že specifikace zařízení odpovídají potřebám uživatele a zamýšlenému použití.

validační balíček – soubor dokumentů vytvořených během validačního projektu.

ověření-potvrzení zkouškou a poskytnutím objektivního důkazu, že byly splněny stanovené požadavky.

V&V Plán – plán, který stanoví požadavky, které musí být ověřeny a schváleny, a lidi, odpovědné osoby, nástroje, metody, zdroje a harmonogram pro V&V úsilí.

Obyčejný Design Ověření Zkratky

CC – Řízení Změn

CCB – Change Control Board (skupina jednotlivců, kteří kontrolují, jaké změny jsou vyrobeny a kdy)

DS – Specifikace Návrhu,

FAT – Factory Přejímací Zkoušky

FS – Funkční Specifikace

FRS – Specifikace Funkčních Požadavků (Viz Funkční Specifikace)

GCP – Good Clinical Practice (kvalita pokyny pro klinické operace)

SLP – správná Laboratorní Praxe (zásady kvality pro farmaceutické laboratorní činnosti)

GMP – Good Manufacturing Praxe (kvalita pokynů pro výrobní zařízení nebo léčiv),

RTM – Požadavek na Sledovatelnost Matrix,

SAD – Software Architecture Document nebo Architektura Systému Dokument,

SAT – Site Přijetí Testování

SCCB – Software Change Control Board (stejné jako CCB, ale pro software)

SDD – Software Detail Design Dokument,

SDS – Software Design Specification

Specifikace – Specifikace

SRS – Požadavky na Software Specifikace

TM – Sledovatelnost Matrix,

UAT – User Acceptance Testing

URS – Uživatel Požadavek Specification

UUT – Unit Under Test

VMP – Validation Master Plan

VP – Validation Plan

V&V – Verification and Validation

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.