Formålet med validering og sporbarhet

Formålet med validering er å sikre at en prosess eller et system er konsekvent og dokumentert. Systemvalidering kreves for regulering av kontorer. For biovitenskapsorganisasjoner inkluderer for eksempel reguleringsbyråene United States Food and Drug Administration (FDA).

FDA definerer validering slik:

Bekreftelse ved undersøkelse og klargjøring av målsettingsbevis om at de bestemte kravene til en bestemt tiltenkt bruk kan oppfylles konsekvent.

Verdens helseorganisasjon (WHO) definerer validering på følgende måte i sin veiledning om kravene for gode produksjonspraksiser:

Etablering av dokumentariske bevis som gir en høy grad av forsikring om at en planlagt prosess vil være enhetlig i henhold til de forventede spesifiserte resultatene.

Disse definisjonene har følgende elementer til felles, i henhold til forventede resultater:

• generering av bevis
• samsvar med forskrifter
• oppfyllelse av krav

Validering av datastyrte systemer er en dokumentert prosess for å sikre at systemet gjør akkurat det det er utformet for å gjøre, på en konsekvent måte som kan reproduseres. Validering sikrer integriteten og sikkerheten for databehandling, produktkvalitet og samsvar med bestemmelser som gjelder for gode {industry}-praksiser (GxP).

Prosessen for validering av et datastyrt system beskrives i standard operasjonsprosedyrer og retningslinjer som opprettes og defineres av den regulerte bransjen, for eksempel biovitenskapsorganisasjoner. For validering av datamaskinsystemer er det nyttig å se implementering av valideringsprosessen som et prosjekt, slik det beskrives i Anbefalt praksis for automatisert produksjon 5: En risikobasert tilnærming til samsvarte GxP-datastyrte systemer fra International Society for Pharmaceutical Engineering (ISPE).

Før du starter implementeringsprosjektet, skal en plan på høyt nivå for den nye løsningen være på plass. Start deretter prosjektet ved å fullføre følgende faser:

• Planlegging: I denne fasen skal kravene og spesifikasjonene være klare nok for en innledende risikovurdering og til slutt for en riktig definisjon av verifiseringstester (protokoller). I denne fasen leverer du valideringsplandokumentet som definerer hele valideringsstrategien og alle leveringene. Strategien bør være i samsvar med kvalitetsstyringssystemet og policyene.
• Spesifikasjon, konfigurasjon og koding: I denne fasen gjøres alle utformingsspesifikasjoner på detaljnivået som kreves av systemtypen og bruken av det. Utviklere velger og bruker utviklingsmetodene og -objektene som passer best for kravene til koding og konfigurasjon, og basert på de godkjente spesifikasjonene. Alle disse aktivitetene utføres i utviklingsmiljøet. I denne fasen er testing mer fokus på kontroll av enhetene eller funksjonene fra et utviklerperspektiv. Eksempler på testaktiviteter omfatter enhetstesting, statistikktesting av kode og integreringstesting. Verktøy kan automatisere disse testaktivitetene.
• Testing: Denne fasen bekrefter at spesifikasjonene er oppfylt gjennom inspeksjoner og testing av systemet. Testaktivitetene utføres i et forberedt og passende testmiljø. Testmiljøet må ligne på produksjonsmiljøet for å sikre at betingelsene er like, og at du ikke trenger å gjenta tester i produksjonsmiljøet. Risikoen bør øke omfanget av testinnsatsen. Risikoanalyse kan hjelpe deg med å forstå potensielle farer som kan ha innvirkning på produktkvaliteten, sikkerhetsfaktoren eller dataintegriteten. Disse potensielle farene må reduseres gjennom kontroller som er på plass og bevis på testing. Hvis det er høy risiko et sted, må du ha riktige testscenarioer for å bevise at løsningsutformingen er uten potensiell feil.
• Rapportering og frigivelse: I denne fasen må systemet godtas for bruk i produksjonsmiljøet i henhold til en dokumentert og kontrollert prosess. Ved prosjektavslutning må du klargjøre en systemvalidering for å oppsummere aktivitetene som ble foretatt, og eventuelle avvik fra valideringsplanen. Valideringen av systemet må fullføres før systemet frigis for bruk.

Illustrasjonen nedenfor viser V-modellen som støttes av GAMP 5, andre utgave. Den gir en god samlet måte å vise prosjektfasene på.

V-modellen kan ikke bare vises som utviklingsaktiviteter og testing av systemet, men også sekvens, sammenhenger og valideringsprosessen for leveringene som gjelder det validerte datastyrte systemet. Du må beholde og vedlikeholde sammenhenger mellom krav, spesifikasjoner og tester. Denne sammenhengen er dokumentert i sporbarhetsmatrisen som brukes i regulerte områder.

Sporbarhetsmatrisen sørger for følgende:

• Kravene oppfylles av løsningsutformingen. Med andre ord spores hvert krav til funksjonene, kontrollene, konfigurasjonene eller utformingselementene.
• Krav testes eller verifiseres for å demonstrere at løsningsutformingen oppfyller kravene etter behov.

Sporbarhetsmatrisen har følgende fordeler:

• Den støtter utformingsgjennomgangen.
• Den bidrar til å definere omfanget av regresjonstestingen.
• Den gir støtte under inspeksjons- eller revisjonsaktiviteter.
• Den gir støtte for potensielle endringer.

Plattformkvalifikasjon

Regulerte bransjer må kvalifisere Microsoft Power Platform som infrastruktur før de implementerer Guides. Plattformkvalifisering krever minst følgende oppgaver:

• første risikovurdering (vurdering av GxP-gyldighet)

• leverandørvurdering (revisjon av en leverandør, kan være virtuelt, fysisk eller via post)

• kvalifikasjonsplan

• teknisk spesifikasjon for plattformutforming

• risikovurdering (f.eks. vurdering av fare for å ha feil versjon av en veiledning tilgjengelig for operatører)

• Testing:

  • installasjonstesting (f.eks. testing av at miljøene er riktig installert)
  • driftstesting (f.eks. testing som viser at de riktige brukerne har riktige tilganger)

• rapport om sammendragskvalifikasjon

• plattform- eller driftshåndbok og opplæringsmateriale

Programvalideringer

Programmer (f.eks. Guides og Power Apps) som støtter forretningsprosesser i regulerte bransjer, må valideres. Derfor må organisasjonen utføre følgende oppgaver:

• første risikovurdering

• valideringsplan

• brukerkrav

• risikovurdering

• teknisk spesifikasjon for programfunksjon eller -konfigurasjon

• Testing (installasjonskvalifisering, driftskvalifisering og brukeraksepttesting):

  • driftstesting (f.eks. verifisering av en funksjon)
  • brukeraksepttesting

• sporbarhetsmatrise

• rapport om sammendragsvalidering

• program- eller driftshåndbok og opplæringsmateriale

Neste trinn

• Vedlikehold av kvalifisert og validert status