Doel van validatie en traceerbaarheid
Het doel van validatie is om te waarborgen dat een proces of systeem consistent en gedocumenteerd is. Systeemvalidatie is een vereiste van regulerende instanties. Zo is bijvoorbeeld de Amerikaanse Food and Drug Administration (FDA) een regulerende instantie voor organisaties in de biowetenschappens.
De FDA definieert validatie als volgt:
Bevestiging door onderzoek en het aanleveren van bewijs voor de doelstelling dat op consistent wijze aan de specifieke vereisten voor een specifiek bedoeld gebruik kan worden voldaan.
De World Health Organization (WHO) definieert validatie als volgt in haar richtlijnen voor de vereisten van Good Manufacturing Practices (GMP):
Instellen van documentair bewijs dat een hoge mate van garantie biedt dat een gepland proces uniform zal zijn in overeenstemming met de verwachte gespecificeerde resultaten.
Deze definities hebben de volgende gemeenschappelijke elementen die overeenstemmen met de verwachte resultaten:
- Genereren van bewijs
- Naleving van de voorschriften
- Afhandeling van vereisten
Validatie van geautomatiseerde systemen is een gedocumenteerd proces dat moet garanderen dat het systeem precies doet waarvoor het is ontworpen op een consistente en zichtbare manier. Validatie zorgt voor de integriteit en beveiliging van gegevensverwerking, productkwaliteit en naleving van de regels die op Good {industry} Practice (GxP) van toepassing zijn.
Het proces voor het valideren van een computersysteem wordt beschreven in de standaardbedrijfsprocedures (SOP) en richtlijnen die worden gemaakt en gedefinieerd door de gereguleerde bedrijfstak, zoals organisaties in de biowetenschappens. Voor de validatie van computersystemen is het handig om de implementatie van het proces als een project te bekijken, zoals wordt beschreven in de Good Automated Manufacturing Practice (GAMP) 5: A Risk-Based Approach to Compliant GxP Computerized Systems van de International Society for Pharmaceutical Engineering (ISPE).
Voordat u het implementatieproject start, moet er een plan op hoofdlijnen beschikbaar zijn voor de nieuwe oplossing. Start vervolgens het project door de volgende fasen te voltooien:
- Planning: in deze fase moeten de vereisten en specificaties duidelijk genoeg zijn voor een initiële risicobeoordeling en, uiteindelijk, voor een juiste definitie van verificatietests (protocollen). In deze fase levert u het document met het validatieplan dat de hele validatiestrategie en alle te leveren producten definieert. De strategie moet in overeenstemming zijn met het kwaliteitsbeheersysteem (QMS) en -beleid.
- Specificatie, configuratie en codering: tijdens deze fase worden alle ontwerpspecificaties gemaakt met het detailniveau dat vereist is voor het type systeem en het gebruik ervan. Ontwikkelaars kiezen de ontwikkelingsmethoden en objecten die het meest geschikt zijn voor de coderings- en configuratievereisten en gebruiken deze op basis van de goedgekeurde specificaties. Al deze activiteiten worden uitgevoerd in de ontwikkelomgeving. Tijdens deze fase richt het testen zich meer op de verificatie van de eenheden of functies vanuit het perspectief van de ontwikkelaar. Voorbeelden van de testactiviteiten zijn het testen van eenheden, het statistisch testen van code en het testen van de integratie. Deze testactiviteiten kunnen worden geautomatiseerd met tools.
- Testen: in deze fase wordt bevestigd dat aan de specificaties is voldaan door middel van inspectie en het testen van het systeem. De testactiviteiten worden uitgevoerd in een voorbereide en geschikte testomgeving. De testomgeving moet vergelijkbaar zijn met de productieomgeving om ervoor te zorgen dat de voorwaarden gelijk zijn en de testen niet hoeven te worden herhaald in de productieomgeving. Het risico moet het bereik van de testinzet bepalen. Risicoanalyse helpt om inzicht te krijgen in de mogelijke gevaren die van invloed kunnen zijn op productkwaliteit, patiëntveiligheid of gegevensintegriteit. Deze mogelijke gevaren moeten worden verkleind via beschikbare controles en testbewijzen. Als er ergens een groot risico is, moet u met de juiste testscenario's bewijzen dat het oplossingsontwerp geen potentiële fouten bevat.
- Rapportage en vrijgave: in deze fase moet het systeem acceptabel zijn voor gebruik in de productieomgeving volgens een gedocumenteerd en gecontroleerd proces. Bij de projectafsluiting moet voltooiing van de systeemvalidatie worden voorbereid om een overzicht te bieden van de ondernomen activiteiten en van eventuele afwijkingen van het validatieplan. De validatie van het systeem moet worden voltooid voordat het systeem wordt vrijgegeven voor gebruik.
Hieronder ziet u een voorbeeld van het V-model dat wordt ondersteund door GAMP 5, 2e editie. Het biedt een goede algemene manier om de projectfasen te bekijken.
Het V-model heeft niet alleen betrekking op de ontwikkelingsactiviteiten en het testen van het systeem, maar ook op de volgorde, de onderlinge relaties en het validatieproces van de te leveren producten voor het gevalideerde geautomatiseerde systeem. U moet de relatie tussen vereisten, specificaties en tests behouden en onderhouden. Deze relatie wordt gedocumenteerd in de traceerbaarheidsmatrix die wordt gebruikt in gereguleerde bedrijfstakken.
Met de traceerbaarheidsmatrix wordt het volgende gegarandeerd:
- Het oplossingsontwerp voldoet aan de vereisten. Met andere woorden, elk vereiste wordt gekoppeld aan de functies, besturingselementen, configuraties of ontwerpelementen.
- Vereisten worden getest of geverifieerd om aan te tonen dat het ontwerp van de oplossing voldoet aan de vereisten.
De traceerbaarheidsmatrix biedt de volgende voordelen:
- Het ondersteunt de ontwerpbeoordeling.
- Het helpt bij het definiëren van de scope van de regressietest.
- Het biedt ondersteuning tijdens inspectie- of controleactiviteiten.
- Het biedt ondersteuning voor mogelijke wijzigingen.
Platformkwalificatie
Gereguleerde bedrijfstakken moeten het Microsoft Power Platform als infrastructuur kwalificeren voordat zij Guides implementeren. Voor platformkwalificatie zijn minimaal de volgende taken vereist:
Initiële risicobeoordeling (beoordeling van GxP-toepasbaarheid)
Leveranciersbeoordeling (audit van een leverancier, kan virtueel, fysiek of per post zijn)
Kwalificatieplan
Technische specificatie van platformontwerp
Risicobeoordeling (bijvoorbeeld beoordeling van het risico dat de verkeerde versie van een guide beschikbaar wordt gemaakt voor operators)
Testen:
- Installatietests (bijvoorbeeld het testen of de omgevingen op de juiste manier zijn geïnstalleerd)
- Operationele tests (bijvoorbeeld het testen of de juiste gebruikers de juiste toegang hebben)
Samenvattend kwalificatierapport
Platform- of operationele handleiding en trainingsmateriaal
Validatie van de toepassingen
Toepassingen (zoals Guides en Power Apps) die bedrijfsprocessen in gereguleerde bedrijfstakken ondersteunen, moeten worden gevalideerd. Daarom moet uw organisatie de volgende taken uitvoeren:
Initiële risicobeoordeling
Validatieplan
Gebruikersvereisten
Risicobeoordeling
Functionele specificatie van de toepassing of technische specificatie van de configuratie
Testen (installatiekwalificatie (IQ), operationele kwalificatie (OQ) en gebruikersacceptatietests (UAT)):
- Operationele tests (bijvoorbeeld het verifiëren van een functie)
- UAT
Traceerbaarheidsmatrix
Samenvattend validatierapport
Toepassing of operationele handleiding en trainingsmateriaal