Vad är Datorsystemvalidering, och hur gör jag det rätt?

processen för validering av programvara säkerställer att systemet passar den avsedda användningen och fungerar som det ska. Datorsystemvalidering (CSV) för laboratorieinformatik är avgörande eftersom reglerade företag måste säkerställa säkerheten för sina produkter för konsumenter, och deras laboratorieinformatiksystem (LIMS, ELN, CDS) är en integrerad del av det. Med tanke på dess betydelse tenderar validering att ses som förvirrande och utmanande att utföra korrekt. Det är självklart möjligt att göra det rätt, och CSols har bevis. På nästan 30 år med CSV har vi inte hört talas om någon av våra kunder som får ett FDA 483-formulär.

validering är en del av livscykeln för mjukvaruutveckling. I den här bloggen kommer vi att granska vad det betyder och hur man gör det så att ditt system kommer att vara försvarbart i en regulatorisk revision.

grunderna för validering av datorsystem

ingen diskussion om validering av datorsystem är komplett utan en översikt över lagstiftningen kring den. I USA reglerar Food and Drug Administration (FDA) specifika branscher som direkt påverkar konsumenternas hälsa, inklusive läkemedel, kosmetika och mat och dryck. Dessa branscher har ett extra ansvar för att säkerställa att deras produkter är säkra och deras data är säkra. Den relevanta lagstiftningen som behandlar aspekter av validering av datorsystem i USA kommer från Code of Federal Regulations (CFR), mest specifikt 21 CFR Part 11 (Del 11), som handlar om elektroniska register och signaturer. Liknande myndigheter och regler gäller också i andra länder.

Del 11 föreskriver att kraven för elektroniska register och signaturer ska betraktas som korrekta, tillförlitliga, lätt att hämta och säkra, för att ersätta pappersregister och handskrivna signaturer lagligt. Att validera ditt datorsystem är det primära sättet att bestämma att elektroniska register och signaturer kan användas på detta sätt.

valideringsprocessen

validering kan ta många former under datorsystemets livscykel, beroende på om det är en ny implementering eller en uppgradering till ett befintligt system. För nya system som användaren hoppas kan lösa ett aktuellt problem sker validering från grunden. För ett befintligt system som behöver en uppgradering eller utökar omfattningen av den avsedda användningen är behovet att hålla systemet i ett validerat tillstånd genom att testa de nya funktionerna innan de släpps i produktionsanvändning. Valideringsprocessen avslutas när ett system avslutas och dess data migreras till ett nytt system eller arkiveras. Figuren nedan visar hur validering stöder projektets livscykel.

Valideringsplanen

din valideringsplan guidar dig genom valideringsprocessen och blir en slags check-off-lista för att säkerställa att allt händer som det ska. När du har bedömt systemets As-is-tillstånd omfattar valideringsplanen alla andra steg du tar för att säkerställa att ditt system valideras i sitt nuvarande tillstånd och passar för den avsedda användningen.

valideringsplanen ska redogöra för kravinsamling, en funktionell riskbedömning, en spårmatris, IQ OQ PQ-protokoll och testning och ändra kontrollprocedurer med periodiska granskningar. Varje del av valideringsplanen utförs i en definierad ordning. Dina krav ska vara fullständiga och riskbedömningen görs innan du går vidare till att utveckla spårmatrisen och sedan göra testningen. På så sätt minimerar du risken att behöva gå tillbaka och utveckla nya testfall sent i processen.

förhållandet mellan kravinsamling och Kvalifikationstestning

det är viktigt att se till att dina krav och specifikationer är väl definierade och godkända innan du validerar datorsystemet. Validering V-modellen används ofta för att visualisera förhållandet mellan krav och specifikationer och den testning som utförs på dem (Se diagram nedan). Kvalificeringstestning (längst ner på höger sida av V) är utformad baserat på din avsedda användning och den funktionalitet som krävs för att uppfylla den användningen (representerad längst ner på vänster sida av V).

• användarens Kravspecifikation kommer att dokumentera vad användarna behöver systemet för att göra, och PQ-testning verifierar dessa krav.
• den funktionella kravspecifikationen kommer att dokumentera den systemfunktionalitet som krävs för att uppfylla användarens Kravspecifikation, och OQ-testning verifierar dessa specifikationer.
• Designspecifikationerna kommer att dokumentera systemdesignen (t.ex. moduler, enheter etc.), och IQ-testning verifierar att systemets installation uppfyller dessa designkrav.

IQ/OQ/PQ-testning är utan tvekan en viktig del av valideringsprocessen. Framgångsrikt slutförande av testningen kommer att verifiera att ditt system fungerar som avsett och är lämpligt för den avsedda användningen i din miljö. Det är bästa praxis att godkänna dina användarkrav och funktionella specifikationer innan testning för att undvika omfattning kryp och eventuell omprövning.

för att lära dig mer om IQ OQ PQ-testning, titta på vårt webinar.

de personer som skriver och utför din IQ/OQ / PQ-testning bör vara väl förtrogna med ditt labbinformatiksystem (LIMS, ELN, CDS) och din avsedda användning. Om din interna personal inte har bandbredd eller erfarenhet för korrekt testning, bör du arbeta med kvalificerade CSV-konsulter, som CSols, som har den nödvändiga erfarenheten av dina informatiksystem.

ALCOA+ och dataintegritet

betydelsen av laboratorieinformatikdata kan inte underskattas. När du har data i en validerad miljö måste du se till att dina data förblir säkra och pålitliga. Förkortningen ALCOA identifierar de fem grundläggande principerna för dataintegritet: data måste hänföras, läsbar, samtida, Original, och korrekt. På senare tid har ytterligare fyra principer lagts till, så att akronymen nu är ALCOA+. De fyra tilläggen är kompletta, konsekventa, bestående och tillgängliga.

dataintegritet är en integrerad del av alla valideringsaktiviteter. Efter principerna i ALCOA + säkerställer att ditt system fångar, producerar, rapporterar, överför och lagrar data som är säkra, återvinningsbara efter behag och pålitliga.

framtiden för CSV: Computer System Assurance

även om vi fortfarande väntar på FDA att släppa sin förväntade vägledning om computer system assurance (Csa), det kommer. I sin kärna förstärker CSA ett riskbaserat tillvägagångssätt som expanderar på GAMP 5-principerna för produkt-och processförståelse, kvalitetsriskhantering och utnyttjande av leverantörsaktiviteter. Risken bedöms utifrån den stora bilden av den övergripande affärsprocessen. På så sätt läggs större vikt vid testeffektivitet, med fokus på testning som säkerställer att systemet är lämpligt för ändamålet.

Valideringsutmaningar för datorsystem

validering av datorsystem kan innebära utmaningar, inklusive risken för systemfel, restriktiva företagspolicyer och allt strängare lagkrav. En annan viktig fråga är när användarna behöver balansera risk vs. kostnad ekvation efter riskkategorier definieras. Ett riskbaserat tillvägagångssätt för CSV kan bidra till att mildra några av dessa utmaningar.

ytterligare steg du kan vidta för att undvika valideringsproblem inkluderar följande:

• se till att din valideringsplan är komplett och följer branschens bästa praxis och föreskrifter
• definiera datorsystemet (dvs. hårdvara, programvara, personer och processer) som ska valideras
• ger tydliga gränser för dina förväntade resultat, dvs., vad är acceptabelt
• att beskriva och uppfylla grundliga krav och specifikationer för din avsedda användning av programvaran

korrekt genomförande av en datorsystemvalidering är en inblandad process, men du kan göra det när du har rätt expertis. Om du inte är säker på att din egen personal har den nödvändiga CSV-upplevelsen, kontakta oss.