Zijn we nog steeds tevreden met onze huidige paradigma's?

Samenvatting

Tijdens recente MES/IT-leveranciersdemo’s voor een “papierloze” farmaceutische fabriek vielen twee zaken op:

• Niemand bracht de dataflow en datarisico’s end-to-end in kaart of besprak deze, ondanks jarenlange regulatoire focus op datagovernance.

• Iedereen leunde op het GAMP-5 V-model en beloofde lagen van testen, maar had moeite uit te leggen welke nieuwe mate van zekerheid IQ/OQ eigenlijk toevoegt bovenop wat eerder al is getest. Ondertussen moedigt huidige richtlijn risico- en resultaatgerichte assurance aan die gebruikmaakt van leveranciersactiviteiten in plaats van deze te dupliceren.

Het is tijd om routinematige, papier-zware rituelen te vervangen door kritisch denken over data-integriteit, beoogd gebruik en risico—en om validatie in lijn te brengen met wat standaarden daadwerkelijk zeggen, niet met wat we altijd hebben gedaan.

De demo's die deze post inspireerden

Ik heb verschillende professionele presentaties gezien van grote internationale MES/IT-leveranciers. De teams waren kundig en goed voorbereid. Toch vielen twee duidelijke gaten op:

Gap #1: Data als bijzaak

Niemand presenteerde een helder beeld van hoe data (en datarisico’s) door systemen stromen—waar deze wordt gecreëerd, getransformeerd, opgeslagen, beveiligd en beoordeeld; welke controles gelden; en waar een fout een risico vormt voor productkwaliteit, patiëntveiligheid of vrijgiftebeslissingen. Dat blinde vlek is opvallend gezien de langdurige regulatoire nadruk op data-integriteit en governance binnen GxP-omgevingen (besproken sinds midden 2010’s en vastgelegd in PI 041-1 in 2021 en andere richtlijnen).

Gap #2: Een V-model op herhaling

Slide na slide herhaalde GAMP-5 deliverables en een V-modelverhaal, plus veel pre-IQ/OQ-testen. Maar toen ik vroeg wat er nu precies anders gebeurt tijdens IQ/OQ—welke extra zekerheid wordt toegevoegd die eerder nog niet was aangetoond—verschoof het antwoord richting “omdat Annex 11/15; 21CFR11” en klantverwachtingen, in plaats van risico-gebaseerde intentie of meetbare resultaten.

Wat de richtlijnen laten zien

1) Datagovernance en integriteit zijn geen optionele ‘extra’s’

PIC/S PI 041-1 positioneert datamanagement en data-integriteit als een kerntaak voor fabrikanten en distributeurs, inclusief het beoordelen van kwetsbaarheden en implementeren van passende governance—precies het soort end-to-end inzicht dat in veel demo’s ontbrak.

Implicatie: Elk “paperless” programma zou moeten beginnen met een dataflow- en risicokaart (waar data ontstaat, wie het kan wijzigen, hoe het wordt beschermd en hoe het wordt gebruikt bij beslissingen), inclusief controles en monitoring die aan die kaart zijn gekoppeld.

2) GAMP-5 (Second Edition) draait om kritisch denken, niet om afvinklijstjes

De Second Edition behoudt het vertrouwde raamwerk, maar benadrukt expliciet kritisch denken, proportionele inspanning en de rol van leveranciers. Het ondersteunt zowel iteratieve (Agile) als lineaire levenscycli—het V-model is een hulpmiddel, geen dwangbuis.

Implicatie: Maak gebruik van leveranciers-testen en bewijs waar passend; richt eigen testen op beoogd gebruik en risico’s voor patiënt/product/data, niet op het opnieuw uitvoeren van wat al bewezen is.

3) Annex 11 en Annex 15 stellen principes, geen papierquota

Annex 11 (Computerised Systems) en Annex 15 (Qualification & Validation) beschrijven verwachtingen voor controle, geschiktheid voor beoogd gebruik en een lifecycle-benadering. Ze verplichten geen overbodige hertesten wanneer het risico laag is en leveranciersassurance solide is; ze wijzen juist naar wetenschap- en risicogebaseerde kwalificatie en validatie.

4) FDA’s Computer Software Assurance (CSA) stimuleert resultaatgericht bewijs

FDA’s CSA-richtlijn (nu definitief voor productie- en kwaliteitssysteemsoftware) moedigt risico-gebaseerde assurance aan, inclusief unscripted/exploratory testing waar dit waarde toevoegt, en het gebruik van digitale in plaats van papier-zware bewijsstukken—waardoor teams kunnen focussen waar het risico het grootst is.

Waarom het V-model verkeerd gebruikt wordt

Het V-model is een communicatiemiddel—een manier om traceerbaarheid van requirements naar testen te tonen. Problemen ontstaan als het wordt behandeld als een herhaalchecklist:

Over-specificatie en onder-denken. Teams produceren stapels documenten maar kunnen eenvoudige vragen niet beantwoorden zoals: “Welke fout hier kan leiden tot vrijgifte van een slecht product?”

Dubbel werk in IQ/OQ. Als een leverancier solide ontwikkelcontroles en verificatie heeft, verandert het opnieuw uitvoeren van functioneel identieke testen tijdens IQ/OQ zelden het risicobeeld.

Perverse prikkels. Auditors zien graag bekende formulieren; klanten vragen leveranciers om “het te doen zoals we het altijd deden.” Kosten stijgen, kwaliteit niet.

GAMP-5 Second Edition en CSA stimuleren een andere dialoog: Welk bewijs—leverancier of gebruiker—toont het beste de geschiktheid voor beoogd gebruik, gezien het risico?

Hoe je IT/MES leveranciers hoort te beoordelen

1) Start met een data-flow en risico inventarisatie

Identificeer:

• Waar data wordt gegenereerd, getransformeerd, opgeslagen, beoordeeld en vrijgegeven (inclusief interfaces, historians, eDHR/eBR en analytics).

• Classificeer data op impact (patiënt/product/vrijgifte) en map controles (toegangsbeheer, audit trails, reconciliatie, exception handling, backup/restore, retentie).

• Koppel risico’s en controles aan erkende data-integriteitsverwachtingen (bijv. governance, beveiliging, traceerbaarheid).

2) Vraag leveranciers om "assurance by design"

Vraag naar:

• ontwikkel-lifecycle, kwaliteitssysteem en teststrategie (inclusief geautomatiseerde testen en continuous integration).

• bewijs van requirement-traceability en risico-gebaseerde testen; waar doen zij stress-, boundary-, security- en failure-mode tests?

• hoe hun bewijs kan worden hergebruikt in jullie validatie—volgens proportioneel risico en GAMP-5’s nadruk op leveranciers en proportionele inspanning.

3) Het juiste formaat IQ/OQ/PQ

• Definieer wat uniek is aan jullie beoogd gebruik, configuratie en integraties—dat test je.

• Wanneer leveranciersbewijs solide is, hergebruik dit en voeg gerichte, resultaatgerichte gebruikerstesten toe (exploratory/unscripted waar zinvol).

• Houd Annex 11/15 in gedachten, maar laat risico de extra test- en documentatielast bepalen, niet traditie.

4) Meet alleen wat van belang is

Definieer assurance-uitkomsten vooraf, zoals:

• “Geen ongevolgde paden naar vrijgifte”

• “Alle kritieke datawijzigingen zijn auditbaar”

• “Alarm/exception-afhandeling is betrouwbaar onder belasting”

• “Hersteltijden voldoen aan X”

Instrumenteer systemen om digitaal bewijs vast te leggen (logs, audit trails, automatische testoutputs, monitoring)—bewijs dat inspecteurs en QA snel kunnen beoordelen.

Een korte checklist voor vendor-demo's

Gebruik deze vragen om tot de juiste inhoud te komen:

Laat me de dataflow zien. Waar kan data verloren gaan, beschadigd raken of ongemerkt worden gewijzigd? Welke controles zijn er? Hoe worden audit trails beoordeeld? (eenvoudige diagrammen horen hierbij).

Welke eerdere testen kunnen we gebruiken? Welke testen tonen geschiktheid voor ons beoogd gebruik, en welke zouden dubbelop zijn?

Wat verandert er tussen pre-IQ/OQ en IQ/OQ? Welke risico’s worden nieuw afgedekt in IQ/OQ, en waarom? Koppel dit aan risicostatements uit onze map.

Hoe ondersteunt u CSA-stijl bewijs? Welke unscripted/exploratory testen en digitale bewijzen zijn beschikbaar?

Hoe sluit uw aanpak aan op Annex 11/15 zonder over-processing? Geef concrete voorbeelden.

Waar we op zouden moeten focusen

Veel inspectieverwachtingen zijn gevormd in een tijdperk waarin papieren bewijs het enige bewijs was. De huidige richtlijn ondersteunt steeds meer risico- en resultaatgerichte assurance en het gebruik van leveranciersbewijs; de aanstaande herziening van Annex 11 onderstreept opnieuw een modern PQS-perspectief voor geautomatiseerde systemen.

Laten we ons richten op wat controle aantoont, niet op hoe dik de map is.

Conclusie

Als we echte kwaliteit willen uit “papierenloze” productie, moeten we stoppen met reflexmatig handelen en beginnen met nadenken:

• Leid met datarisico en dataflow

• Laat beoogd gebruik en risico het juiste bewijs bepalen

• Gebruik leveranciersassurance waar die sterk is

• Gebruik CSA-stijl testen en digitale bewijzen om controle efficiënt aan te tonen

Begrip is de basis van GMP. Geen begrip, geen GMP.