Hva Er Datasystemvalidering, Og Hvordan Gjør Jeg Det Riktig?

prosessen med programvarevalidering sikrer at systemet passer til tiltenkt bruk og fungerer som det skal. Datasystemvalidering (CSV) for laboratorieinformatikk er viktig fordi regulerte bedrifter må sørge for sikkerheten til sine produkter for forbrukerne, og deres laboratorieinformatikksystemer (LIMS, ELN, CDS) er en integrert del av det. Gitt sin betydning, har validering en tendens til å bli sett på som forvirrende og utfordrende å utføre riktig. Selvfølgelig er det mulig å gjøre det riktig, Og CSols har bevis. I nesten 30 år med Å GJØRE CSV, har vi ikke hørt om noen av våre kunder som mottar ET FDA 483-skjema.

Validering er en del av livssyklusen for programvareutvikling. I denne bloggen vurderer vi hva det betyr og hvordan du gjør det slik at systemet ditt kan forsvares i en regulatorisk revisjon.

Grunnleggende Om Datasystemvalidering

ingen diskusjon om datasystemvalidering er komplett uten en oversikt over lovgivningen rundt den. I Usa regulerer Food And Drug Administration (FDA) spesifikke næringer som direkte påvirker forbrukernes helse, inkludert legemidler, kosmetikk og mat og drikke. Disse næringene har et ekstra ansvar for å sikre at deres produkter er trygge og deres data er sikre. Relevant lovgivning adressering aspekter av datasystemer validering i Usa kommer Fra Code Of Federal Regulations (CFR), mest spesifikt 21 CFR Del 11 (Del 11), arbeider med elektroniske registre og signaturer. Lignende offentlige etater og forskrifter gjelder også i andre land.

Del 11 mandater kravene til elektroniske poster og signaturer for å bli vurdert nøyaktig, pålitelig, lett gjenfinnes, og sikker, å erstatte papir poster og håndskrevne signaturer lovlig. Validere datasystemet er den primære måten å bestemme at elektroniske poster og signaturer kan brukes på denne måten.

Valideringsprosessen

Validering kan ta mange former i løpet av datasystemets livssyklus, avhengig av om det er en ny implementering eller en oppgradering til et eksisterende system. For nye systemer som brukeren håper kan løse et aktuelt problem, skjer validering fra grunnen av. For et eksisterende system som trenger en oppgradering eller utvider omfanget av den tiltenkte bruken, er behovet for å holde systemet i en validert tilstand ved å teste de nye funksjonene før de slippes ut i produksjonsbruk. Valideringsprosessen avsluttes når et system trekkes tilbake og dataene overføres til et nytt system eller arkiveres. Figuren nedenfor viser hvordan validering støtter prosjektets livssyklus.

Valideringsmesterplanen

valideringsmesterplanen veileder deg gjennom valideringsprosessen og blir en slags avkrysningsliste for å sikre at alt skjer som det skal. Når du har vurdert as-Is-tilstanden til systemet ditt, omfatter valideringsmesterplanen alle de andre trinnene du tar for å sikre at systemet ditt er validert i sin nåværende tilstand og passer for den tiltenkte bruken.

hovedplanen for validering skal ta hensyn til kravinnsamling, en funksjonell risikovurdering, en sporingsmatrise, IQ OQ PQ-protokoller og testing, og endre kontrollprosedyrer med periodiske gjennomganger. Hver del av hovedplanen for validering utføres i en definert rekkefølge. Dine krav bør være komplette og risikovurderingen gjort før du går videre til å utvikle spormatrisen og deretter gjøre testingen. På denne måten minimerer du risikoen for å måtte gå tilbake og utvikle nye testtilfeller sent i prosessen.

Forholdet Mellom Kravinnsamling Og Kvalifikasjonstesting

det er viktig å sikre at dine krav og spesifikasjoner er godt definert og godkjent før du validerer datasystemet. Validering V-Modellen brukes ofte til å visualisere forholdet mellom krav og spesifikasjoner og testing utført på dem(se diagram nedenfor). Kvalifikasjonstesting (nede på høyre Side Av V) er utformet basert på din tiltenkte bruk og funksjonaliteten som kreves for å møte den bruken(representert nede på venstre side Av V).

• Brukerkrav Spesifikasjonen vil dokumentere hva brukerne trenger systemet til å gjøre, OG PQ testing verifiserer disse kravene.
• Spesifikasjonen For Funksjonskrav vil dokumentere systemfunksjonaliteten som kreves for Å oppfylle Spesifikasjonen For Brukerkrav, OG OQ-testing verifiserer disse spesifikasjonene.
• Designspesifikasjonene vil dokumentere systemdesign (f.eks. moduler, enheter, etc.), OG IQ-testing bekrefter at systemets installasjon oppfyller disse designkravene.

IQ/OQ / PQ testing er uten tvil en viktig del av valideringsprosessen. Vellykket gjennomføring av testingen vil bekrefte at systemet fungerer som tiltenkt og er egnet for tiltenkt bruk i ditt miljø. Det er best praksis å godkjenne brukerkrav og funksjonelle spesifikasjoner før testing for å unngå omfang krype og mulig re-testing.

for å lære mer OM IQ OQ pq testing, se vårt webinar.

folk som skriver OG utfører DIN IQ / OQ / PQ testing bør være godt kjent med lab informatikk system (LIMS, ELN, CDS) og din tiltenkte bruk. Hvis ditt interne personale ikke har båndbredde eller erfaring for riktig testing, bør du jobbe med kvalifiserte CSV-konsulenter, som CSols, som har den nødvendige erfaringen med informatikksystemene dine.

ALCOA + Og Dataintegritet

betydningen av laboratorieinformatikkdata kan ikke undervurderes. Når du har data i et validert miljø, må du sørge for at dataene dine forblir sikre og pålitelige. Akronymet alcoa identifiserer de fem grunnleggende prinsippene for dataintegritet: data må Være Henførbare, Lesbare, Samtidige, Originale og Nøyaktige. Mer nylig har fire tilleggsprinsipper blitt lagt til, slik at akronymet NÅ ER ALCOA+. De fire tilleggene Er Komplette, Konsekvente, Varige og Tilgjengelige.

dataintegritet er integrert i alle valideringsaktiviteter. VED å følge PRINSIPPENE i ALCOA+ sikrer DU at systemet ditt fanger opp, produserer, rapporterer, overfører og lagrer data som er sikre, gjenfinnbare etter ønske og pålitelige.

Fremtiden FOR CSV: Computer System Assurance

selv om VI fortsatt venter PÅ AT FDA skal frigjøre sin forventede veiledning om computer system assurance (CSA), kommer den. I kjernen styrker CSA en risikobasert tilnærming som utvider GAMP 5-prinsippene for produkt-og prosessforståelse, kvalitetsrisikostyring og utnyttelse av leverandøraktiviteter. Risiko vurderes basert på det store bildet av den samlede forretningsprosessen. Gjør du det legger mer vekt på test effektivitet, med fokus på testing som sikrer at systemet er egnet for formålet.

Utfordringer For Validering Av Datasystemer

Validering av datasystemer kan innebære utfordringer, inkludert risiko for systemfeil, restriktive selskapspolicyer Og stadig strengere regulatoriske krav. Et annet viktig problem er når brukerne må balansere risiko vs kostnad ligning etter risikokategorier er definert. En risikobasert TILNÆRMING TIL CSV kan bidra til å redusere noen av disse utfordringene.

Ytterligere trinn du kan ta for å unngå valideringsproblemer, inkluderer følgende:

• Sikre at valideringsplanen din er fullført og følger bransjens beste praksis og forskrifter
• Definere datasystemet (dvs. maskinvare, programvare, personer og prosesser) som skal valideres
• Og Gir klare grenser for forventede resultater; dvs. , Hva som er akseptabelt
• Å Beskrive og oppfylle grundige krav og spesifikasjoner for din tiltenkte bruk av programvaren

Riktig utførelse av en datasystemvalidering er en involvert prosess, men Du Kan gjøre det når du har riktig kompetanse. Hvis du ikke er sikker på at ditt interne personale har DEN NØDVENDIGE CSV-opplevelsen, ta kontakt med oss.