Spring til indhold

CSV validering

CSV validering efter GAMP 5: tid, pris og praksis 2026

CSV validering efter GAMP 5 tager 2-4 uger for kat 4 og 1-3 mdr for kat 5. Gap analyse fra ca 25.000 kr. Få praksis for VP, IQ OQ PQ og VRA.

Publiceret

CSV validering efter GAMP 5 tager typisk 2-4 uger for et konfigurerbart kat 4 system og 1-3 måneder for et specialbygget kat 5 system. En gap analyse koster fra ca 25.000 kr, og en risk assessment på 1-2 dage afklarer omfanget før I bruger penge på test. Metoden er risikobaseret: I validerer det der kan ramme patientsikkerhed, produktkvalitet eller dataintegritet, ikke alt med alt.

Hvad er CSV validering efter GAMP 5?

CSV står for Computerized System Validation. Det er dokumenteret bevis for at et computerbaseret system gør det det skal, pålideligt og reproducerbart. I pharma og medico er det et lovkrav for alle systemer der påvirker patientsikkerhed, produktkvalitet eller dataintegritet. Kravene står i EudraLex Vol 4 Annex 11 om computerbaserede systemer, og metoden kommer fra ISPE GAMP 5 2. udgave.

GAMP 5 er branchens de facto standard. Den bygger på et enkelt princip: valideringsomfanget skal stå i forhold til risikoen. Et simpelt standardprodukt kræver mindre dokumentation end et specialbygget system der styrer frigivelse af batch. Derfor starter ethvert fornuftigt projekt med at kategorisere systemet og vurdere GxP risikoen, ikke med at skrive testprotokoller. Vores CSV-validering efter GAMP 5 følger netop den rækkefølge.

Hvad er forskellen på kategori 3, 4 og 5?

GAMP 5 deler software i fem kategorier. For mindre pharma og medico virksomheder er det især kategori 3, 4 og 5 der betyder noget i hverdagen, fordi kategori 1 er infrastruktur og kategori 2 forsvandt i praksis med 2. udgaven.

Kategori 3 er ikke-konfigurerbare standardprodukter. Det er software I bruger som den er, uden opsætning der ændrer GxP funktionalitet. Eksempler er simple firmware styringer, standard laboratorieinstrumenter eller et PDF værktøj der kun arkiverer. Her validerer I leverandørens dokumentation og jeres egen brug af systemet, og I skriver typisk kun krav til den tiltænkte anvendelse plus en kort verifikation af at installationen er korrekt.

Kategori 4 er konfigurerbare standardprodukter. Det er den kategori de fleste mindre virksomheder rammer: LIMS, eQMS, temperaturmonitorering, ERP moduler eller en cloud løsning I konfigurerer med workflows, roller og alarmer uden at ændre kildekoden. Her skal konfigurationen specificeres og testes, fordi det er jeres opsætning der afgør om systemet beskytter dataintegriteten. Leverandørens test kan genbruges som supplement, men jeres konfiguration skal I selv stå på mål for.

Kategori 5 er specialbyggede systemer. Det er software udviklet specifikt til jer, enten fra bunden eller som tung tilpasning af et standardsystem med egen kode. Her er valideringsomfanget størst: fulde designspecifikationer, kodegennemgang efter behov, komplet IQ OQ PQ og en sporbarhedsmatrix der binder det hele sammen. Når vi selv bygger pharma software til kunder, bliver valideringsdokumentationen derfor skrevet som en by-design artefakt undervejs, ikke som et tillæg bagefter.

Hvor lang tid tager CSV validering i praksis?

Tidsforbruget afhænger næsten kun af kategori og systemets GxP kritikalitet. Vores erfaringstal for 2026 ser sådan ud.

Et kategori 4 system tager typisk 2-4 uger fra godkendt valideringsplan til godkendt valideringsrapport. Det forudsætter at kravspecifikationen er på plads, at leverandøren kan levere sin dokumentation, og at jeres nøglebrugere kan afsætte tid til test. Selve testen tager sjældent mere end nogle dage. Det der tager tid, er gennemgang, rettelser og godkendelser.

Et kategori 5 system tager typisk 1-3 måneder. Her skal der skrives funktionelle specifikationer og designspefikationer før der kan testes, og PQ fasen kræver ofte at systemet kører i driftlignende rammer med rigtige data og rigtige brugere. Bygger I nyt, så læg valideringen ind i udviklingsplanen fra dag et. Det skærer måneder af forløbet sammenlignet med at validere et færdigt system baglæns.

Et kategori 3 system kan ofte klares på under to uger, fordi dokumentationspakken er lille. Den store tidsrøver på tværs af alle kategorier er ikke testen selv, men ventetid: manglende leverandørdokumentation, uklare krav og godkendere der ikke har tid. En skarp valideringsplan med navne og datoer fjerner det meste af den ventetid.

Hvad koster en gap analyse og en validering?

En gap analyse koster fra ca 25.000 kr. Den tager typisk 2-5 dage og giver jer en prioriteret liste over afvigelser klassificeret efter risiko, så ledelse og QA kan beslutte rækkefølgen. Det er den billigste måde at få svar på hvor I står før en inspektion, og den ligger som fast ydelse under vores GxP-compliance.

Selve valideringen prissættes efter omfang, og omfanget afklares i gap analysen eller i en risk assessment på 1-2 dage. Derfor kender I pris og resultat før arbejdet går i gang. Som tommelfingerregel koster en kategori 4 validering væsentligt mindre end en kategori 5 validering, fordi dokumentationspakken er mindre og leverandørens materiale kan genbruges. Det dyreste projekt er næsten altid det der starter uden kravspecifikation, for så skal kravene skrives samtidig med at der testes.

Hvordan undgår I at validere alt med alt?

Risikobaseret validering er svaret, og det er netop det GAMP 5 foreskriver. Fremgangsmåden har tre trin.

Først kategoriserer I systemet efter GAMP 5. Kategorien afgør hvilke specifikationer der overhovedet skal skrives. Et kategori 4 system kræver konfigurationsspecifikation, ikke designspecifikation på kodeniveau.

Dernæst laver I en GxP risk assessment. For hver funktion spørger I: hvad sker der med patientsikkerhed, produktkvalitet og dataintegritet hvis denne funktion fejler. Funktioner med høj risiko får fuld test med udfordrende testcases. Funktioner med lav risiko får en let verifikation eller dækkes af leverandørens test. Vurderingen dokumenteres, så en inspektør kan følge jeres prioritering.

Til sidst genbruger I det der allerede er testet. Leverandørens udviklingstest, standard testpakker og kvalificerede platforme skal ikke gentages, de skal vurderes og refereres. Jeres egen test fokuserer på det leverandøren ikke kan teste: jeres konfiguration, jeres data, jeres arbejdsgange og jeres integrationer. Det er sådan I undgår at validere alt med alt uden at gå på kompromis med compliance.

Hvilken dokumentation kræver inspektøren: VP, URS, IQ OQ PQ og VRA?

En inspektør fra Lægemiddelstyrelsen forventer en sammenhængende dokumentationskæde. Hvert led har et fast formål, og kæden er kun så stærk som det svageste led.

Valideringsplanen VP åbner forløbet. Den definerer systemets scope, GAMP kategori, roller og ansvar, acceptkriterier og tidsplan. En god VP er kort og beslutningsklar. Den fortæller hvem der godkender hvad, og hvornår systemet er valideret.

Brugerkravspecifikationen URS beskriver hvad systemet skal kunne set fra forretningens side. Den skal være målbar, så hvert krav kan testes. Vage krav som systemet skal være brugervenligt hører ikke hjemme i en URS. Skriv i stedet konkrete krav om roller, rettigheder, audit trail, alarmer og dataflow.

Funktionsspecifikation og designspecifikation FS og DS oversætter kravene til teknisk løsning. For kategori 4 er det konfigurationsspecifikationen der bærer vægten. For kategori 5 skal der fulde designspecifikationer til.

IQ OQ PQ er selve beviset. IQ dokumenterer at systemet er installeret korrekt. OQ dokumenterer at det fungerer som specificeret, inklusiv grænseværdier og fejlscenarier. PQ dokumenterer at det fungerer pålideligt i drift med rigtige brugere og rigtige data. Hver protokol har foruddefinerede acceptkriterier, og afvigelser håndteres med dokumenteret afvigelseshåndtering, ikke med mundtlige forklaringer.

Valideringsrapporten VRA lukker forløbet. Den sammenfatter hvad der blev testet, hvilke afvigelser der opstod, hvordan de blev lukket, og om systemet er frigivet til GxP brug. Sammen med sporbarhedsmatrix og testdokumentation er VRA det første en inspektør beder om.

Hvad er en sporbarhedsmatrix, og hvorfor redder den jeres inspektion?

En sporbarhedsmatrix er en tabel der binder krav til test. Hver række starter med et krav fra URS, peger på den specifikation der implementerer det, og ender i den protokol og det testcase der beviser det. Når den er komplet, kan I svare på inspektørens to favoritspørgsmål på få sekunder: hvor er dette krav testet, og hvad dækker denne test.

Matricen afslører også huller før inspektøren gør det. Et krav uden test er et åbent punkt. En test uden krav er spildt arbejde eller tegn på at et krav mangler. Vi opbygger matricen løbende under projektet, ikke baglæns til sidst, for en baglæns matrix afslører altid at noget blev glemt. Det er et af de steder hvor praktisk erfaring med CSV-validering betaler sig direkte i færre inspektionsfund.

Hvordan validerer man SaaS og cloud systemer med vendor qualification?

SaaS løsninger ændrer ikke på at I har ansvaret for jeres GxP data, men de ændrer på hvordan I dokumenterer det. I kan ikke validere leverandørens datacenter, men I kan kvalificere leverandøren og genbruge hans validering.

Vendor qualification starter med en vurdering af leverandørens kvalitetsmodenhed: har leverandøren et kvalitetssystem, releasenotes med sporbarhed, ændringsstyring I bliver varslet om, backup og disaster recovery, samt adgang til audit eller en troværdig tredjepartscertificering som SOC 2 eller ISO 27001. Resultatet afgør hvor meget af leverandørens testmateriale I tør læne jer op ad.

Dernæst aftaler I ansvarsdelingen skriftligt. Hvem validerer infrastrukturen, hvem tester nye releases, hvor lang tid før en opdatering får I besked, og hvem ejer jeres data ved ophør. Uden den aftale opdager I ændringer i produktion, og så er det for sent at validere.

Til sidst validerer I selv det leverandøren ikke kan: jeres konfiguration, jeres roller og rettigheder, jeres integrationer og jeres arbejdsgange. Ved hver SaaS release laver I en lille impact vurdering i stedet for en fuld revalidering. Rammer ændringen en GxP kritisk funktion, tester I den. Gør den ikke, dokumenterer I vurderingen og går videre. Den model holder både compliance og driftsomkostninger nede, og den er en fast del af vores GxP-compliance arbejde.

Hvornår skal I revalidere?

Revalidering udløses af ændringer, ikke af kalenderen. I skal revurdere valideringsstatus efter større ændring som ny funktionalitet, ny platform, ændret integration eller nye regulatoriske krav. Mindre ændringer håndteres i ændringsstyringen med en begrundet vurdering af om test er nødvendig.

Derudover gennemfører de fleste virksomheder et periodisk review, typisk årligt, hvor de bekræfter at systemet stadig bruges som valideret, at der ikke er åbne afvigelser, og at SOPer og træning stadig matcher. Hvis I ikke kan bevise at systemet stadig er valideret, er det i praksis ikke valideret. Det gælder især legacy systemer der har kørt i årevis uden opdateret dokumentation. Her starter vi som regel med en gap analyse der kortlægger afstanden mellem den dokumentation I har, og den dokumentation Annex 11 kræver.

Hvordan kommer I i gang på 1-2 dage?

Start med en risk assessment på 1-2 dage. Den afklarer systemets GAMP kategori, GxP kritikalitet og det nødvendige dokumentationsomfang, før I forpligter jer til et fuldt projekt. I får en konkret plan med aktiviteter, roller og tidsestimat, som ledelsen kan tage stilling til.

Hvis I står før en inspektion eller har overtaget et system uden papirer, så start med en gap analyse i stedet. Den giver jer den prioriterede fundliste der både styrer valideringsprojektet og viser inspektøren at I har styr på jeres huller. Begge dele kan I booke som et afgrænset forløb med fast pris efter den indledende afklaring.

Kilder: ISPE GAMP 5 A Risk-Based Approach to Compliant GxP Computerized Systems 2. udgave samt EudraLex Volume 4 Annex 11 Computerised Systems. Begge stiller krav om risikobaseret validering, sporbarhed fra krav til test og dokumenteret vendor vurdering for outsourcede aktiviteter.

Hvad spørger mindre pharma virksomheder oftest om?

Skal vi validere vores standardsystem selv om leverandøren siger det er valideret?

Ja, men I skal ikke gentage leverandørens arbejde. Leverandørens validering dækker standardproduktet, ikke jeres konfiguration, jeres data og jeres arbejdsgange. I kvalificerer leverandøren, vurderer hans materiale og tester selv det der er unikt for jer. Det er netop forskellen på kategori 4 og kategori 5 tænkning.

Kan vi nøjes med IQ og springe OQ og PQ over?

Nej, ikke for GxP kritiske funktioner. IQ beviser kun at systemet er installeret korrekt. OQ beviser at det fungerer som specificeret, og PQ beviser at det virker i jeres drift. For ikke kritiske funktioner kan risk assessmenten begrunde reduceret test, men beslutningen skal stå på skrift før testen, ikke bagefter.

Hvad koster en typisk kategori 4 validering?

Det afhænger af antal krav, integrationer og leverandørens materiale, så der findes ingen fast listepris. En gap analyse fra ca 25.000 kr eller en risk assessment på 1-2 dage giver jer et fast tilbud på selve valideringen. Det er billigere end at starte blindt og opdage halvvejs at kravspecifikationen mangler.

Hvor ofte skal SaaS systemet revalideres ved nye releases?

Ved hver release laver I en impact vurdering. Rammer ændringen GxP kritisk funktionalitet, tester I målrettet og dokumenterer resultatet som et tillæg til VRA. Rammer den ikke, dokumenterer I vurderingen uden test. Det kræver at leverandøren varsler ændringer i god tid, hvilket er præcis det vendor qualification aftalen skal sikre.