domov Računalniki Kaj je validacija projektne dokumentacije? Validacija - kaj je to z enostavnimi besedami

Kaj je validacija projektne dokumentacije? Validacija - kaj je to z enostavnimi besedami

Zanimivo in hkrati prijetno je, da se je tema validacije računalniških sistemov (CS) izkazala za nepričakovano povpraševanje! Prej so bile te informacije v postsovjetskem prostoru verjetno zanimive le za redke ljudi. Vse se je spremenilo, ko se je tehnološka in analitična oprema začela povezovati s takim orodjem za avtomatizacijo, kot je računalnik, specializirani programi pa so nadomestili kalkulatorje za izračune. Verjetno ljudje starejše generacije nimajo pojma o validaciji (v nadaljevanju besedila se lahko namesto izraza preverjanje uporablja izraz preverjanje, menim, da je to dobra in ustrezna ruska zamenjava za tujo besedo, tako da, če v prevodu naletite na ta analog, ga preberite kot preverjanje; o terminologiji lahko razpravljamo v naslednjih razpravah) računalniški sistemi in programska oprema. Pravzaprav se njegova načela ne razlikujejo zelo od klasičnih konceptov, ki se uporabljajo za opremo ali metode analize. Seveda obstaja posebna terminologija, a če vas besede IQ, PQ, OQ in drugi xQ ne prestrašijo, potem mislim, da je smiselno poskusiti razumeti validacijo CS.
Obstajajo različne knjige, GAMP, ISO 17025, priročniki na to temo, meni najljubši pa je priročnik EDQM za njihov OMCL s pripadajočimi dodatki. Po mojem mnenju je preprosto, dostopno in najbližje realnosti. Poleg tega priloge celo zagotavljajo konkretni primeri, na primer v delovnih zvezkih iste baze podatkov Excel ali Access, ki jih OMCL uporablja za razvoj lastnih internih programov.

Skupaj programsko opremo(programska oprema) lahko razdelimo v tri kategorije: komercialna (pripravljena za uporabo), odprtokodna (prav tako pripravljena za uporabo, vendar z razpoložljivimi izvornimi kodami) in lastniška programska oprema. Vsak tip lahko nadalje razdelimo na podtipe, a za zdaj bomo izhajali iz njih. Mimogrede, v priročniku sta samo dve vrsti, 1. in 3. Žal, ustvarjalci tega priročnika so z dogajanji v svetu programske opreme nekoliko zaostali za časom in so očitno popolnoma pozabili na obstoj odprtokodnega programa (da boste razumeli, o čem govorimo, se spomnite brskalnika FireFox, enega izmed tipični predstavniki, morda zdaj berete ta zapis prek njega).

Kot je navedeno zgoraj, dober začetek Vodnik OMCL lahko služi kot referenca. Trenutno sem dokončal prevod osnovnega dokumenta (glej spodaj), postopoma bom dopolnjeval njegove priloge, ki že vsebujejo konkretne primere, do konca prevoda pa mislim, da bom sestavil svoj primer in bo mogoče opisati s pomočjo teh vodnikov. Če brez težav govorite angleško in ste dobro seznanjeni s temo, lahko takoj nadaljujete z branjem izvirnega dokumenta; povezave bodo na koncu. Če z Težave z angleščino ne, ampak v temi "plavanje", potem je vredno prebrati prevod in nato postaviti vprašanje(a) v komentarjih. Ta dokument lahko dobro uporabljajo naši laboratoriji. Prej sem podal prevod, pri čemer moram opozoriti, da je v primerjavi z OMCL še bolj splošen in nejasen.

VALIDACIJA RAČUNALNIŠKIH SISTEMOV - OSNOVNI DOKUMENT

OBSEG UPORABE
Ta priročnik opredeljuje osnovna načela za validacijo računalniških sistemov, ki se uporabljajo v uradnih laboratorijih za kontrolo zdravil (OMCL), s poudarkom na kakovosti rezultatov. Namen te validacije je zagotoviti zaupanje v znanstvene rezultate, pridobljene iz vsakega računalniškega sistema. Preverjen sistem zagotavlja natančne rezultate in zmanjšuje tveganje za okvaro sistema.

Ta dokument zajema interno razvito in komercialno programsko opremo, ki se uporablja za izračune, sisteme za upravljanje podatkovnih baz (DBMS), laboratorijske informacijske sisteme (LIMS), elektronske laboratorijske zvezke (ELR) in računalnike v analitični opremi. ( pribl. v nadaljevanju besedila je mišljena le analitska oprema, saj je dokument namenjen predvsem laboratorijem)

UVOD
Ta vodnik opisuje splošna načela validacija računalniških sistemov OMCL v skladu z ISO/IEC 17025. Smernice določajo splošne zahteve in navajajo tudi minimalne zahtevane elemente za preverjanje različne vrste programsko opremo. Pravzaprav, ker velika raznolikost programske opreme ni mogoče opisati vseh specifičnih elementov preverjanja, uporabljenih v enem dokumentu.
Ta navodila so namenjena uporabi OMCL, ki upravljajo sistem vodenja kakovosti na podlagi ISO/IEC 17025, ki uporabljajo avtomatizirane sisteme za del ali vse postopke, povezane z nadzorom kakovosti zdravil, in niso namenjena proizvajalcem, ki delujejo v skladu z zahtevami GMP. .
Da bi olajšali uporabo tega priročnika, ta dokument vsebuje samo splošne smernice in zahteve za različne vrste avtomatiziranih sistemov. Prav tako je osnovni dokument dopolnjen s sistemsko odvisnimi aplikacijami, ki vsebujejo dodatne zahteve in/oz praktični primeri validacijo dokumentacije, ki jo je treba uporabljati skupaj z splošna priporočila kot je določeno v glavnem dokumentu.
Seznam aplikacij, vključenih v ta dokument, bo posodobljen, ko bodo izdane nove aplikacije.
Ta dokument je treba obravnavati kot smernice za OMCL za načrtovanje, izvajanje in dokumentiranje potrjevanja njihovih računalniških sistemov. Ne bi smeli jemati kot seznam obveznih zahtev. Vsakemu OMCL je dana osebna pravica, da sprejme strokovno odločitev o najprimernejših postopkih, ki jih je treba upoštevati, da zagotovi dokaze, da računalniški sistemi delujejo pravilno in ustrezajo predvidenemu namenu.

DEFINICIJE
Računalniški sistem- komponente računalniške strojne opreme v kombinaciji z nizom programske opreme, ki so skupaj zasnovane za izvajanje določene funkcije ali skupine funkcij.

Računalniški sistem- računalniški sistem in nadzorovana funkcija, ki jo izvaja. Vključuje strojno opremo, programsko opremo, zunanje naprave, osebje in dokumentacijo, kot so priročniki in standardni operativni postopki (SOP).

Komercialna programska oprema (gotova, po meri).- programi po meri, ki jih je mogoče konfigurirati za posebne uporabniške naloge z "izpolnjevanjem praznih mest", ne da bi spremenili glavni program.

Interno razvita programska oprema- poseben sistem, ki ga je razvil uporabnik (ali ga je sklenilo podjetje) za izpolnitev določenega sklopa uporabniških zahtev.

Elektronski laboratorijski dnevnik (ELR)— programska oprema (program), namenjena zamenjavi papirnatih laboratorijskih dnevnikov.

Laboratorijski informacijski sistem (LIS/LIMS)— avtomatiziran laboratorijski sistem, ki zbira in obdeluje (upravlja) podatke. ( pribl. Nekateri precej kategorično, s peno na ustih, delijo LIS in LIMS. Ne ubirajmo terminologije, saj v različnih publikacijah ta dva izraza pogosto označujeta sistem istega razreda.)

1. STROJNA OPREMA
Uporabljena strojna oprema mora ustrezati tehničnim zahtevam, da je dodeljeno delo opravljeno. Take zahteve vključujejo na primer minimalno Sistemske zahteve določi proizvajalec opreme. Te zahteve je treba določiti vnaprej glede na predvideno uporabo.

Komponente strojne opreme mora namestiti usposobljeno osebje (na primer osebje za informacijsko tehnologijo (IT), tehniki proizvajalca strojne opreme ali drugo usposobljeno osebje), njihova funkcionalnost pa mora biti preverjena glede na določene zahteve.

Računalniški sistemi, ki so del analitske opreme, morajo biti jasno označeni.

Za računalniške sisteme, ki so sestavni deli analitske opreme, je treba vzdrževati evidence o konfiguraciji, namestitvi in spremembah opreme. Te zapise je mogoče vključiti v dnevnik analitične opreme.

2. SPLOŠNE PROGRAMSKE ZAHTEVE
register
Na voljo mora biti register ali seznam vseh računalniških sistemov.
V register računalniških sistemov je treba vključiti naslednje minimalne informacije:

edinstven identifikator
aplikacija
preverjanje stanja
fizična ali shranjevalna lokacija (poti diska in datoteke) lokacija programske opreme in povezane dokumentacije
odgovorna ali kontaktna oseba

V primeru lokalne namestitve (delovna postaja) mora imeti vsaka kopija programske opreme svoj edinstven identifikator.

V primeru programske opreme, povezane z znanstveno opremo (na primer HPLC), njen identifikator (na primer številka licence ali serijska številka in številka različice) mora biti čim bolj neodvisen od ID-ja strojne opreme.

Validacija programske opreme
prej običajna uporaba, mora biti programska oprema potrjena.
Pri validaciji gre za potrditev s testiranjem in zagotavljanjem objektivnih dokazov, da specifikacije programske opreme ustrezajo potrebam uporabnikov in predvideni uporabi ter da je mogoče dosledno izpolnjevati posebne zahteve, ki jih izvaja programska oprema.

Nadzor sprememb
Če se programska oprema spremeni, je treba preveriti stanje sistema. Če je potrebna analiza navzkrižnega preverjanja, je treba opraviti ne le za preverjanje posameznih sprememb, ampak tudi za določitev obsega in vpliva te spremembe na celoten računalniški sistem.
Podobno lahko spremembe v okolju strojne opreme vplivajo na delovanje programske opreme. V tem primeru bo morda potrebna ponovna potrditev.
V obeh primerih bo obseg ponovne validacije odvisen od narave sprememb.

Naravo sprememb je treba dokumentirati.

V idealnem primeru bi morale biti samodejne posodobitve pod nadzorom IT oddelka ali sistemskega skrbnika in nameščene ob vnaprej določenih datumih, da se čim bolj zmanjšajo motnje in nepričakovano vedenje sistema. Po namestitvi posodobitev je treba izvesti preverjanje, katerega obseg bo odvisen od obsega posodobitve(-e).
Vsaka posodobitev mora biti dokumentirana.

Opomba: to ne velja nujno za posodobitve storitev za komercialno pisarniško programsko opremo.

Preverjanje programske opreme
(pribl. Ne zamenjujte preverjanja z validacijo. O razliki, ki jo lahko )
Med namestitvijo je treba preveriti komercialno programsko opremo.
Lastniško programsko opremo je treba preverjati ne le med namestitvijo, ampak na splošno redno, da se izognete morebitnim napakam in zagotovite dobre rezultate. Pogostost preverjanja je odvisna od varnosti programske opreme, pogostosti uporabe in možne posledice v primeru okvare.
V obeh primerih mora biti strategija OMCL opisana v postopku.

Zaščita programske opreme
Programsko opremo je treba zaščititi pred kakršnimi koli vdori, ki bi lahko povzročili poškodbe znanstveni rezultati. Eden od načinov zaščite programske opreme ali računalnikov/sistemov je dostop z geslom. Zaščiten mora biti tudi pred zunanjimi posegi, ki bi lahko spremenili podatke in vplivali na končne rezultate.

Rezerva
Zagotovljena mora biti sledljivost podatkov od vhodnih podatkov do rezultatov. Če so vsi ali del spremljanih parametrov, pomembnih za kakovost rezultatov, na voljo samo v v elektronski obliki, potem je treba izvesti postopek varnostnega kopiranja, da se zagotovi, da je sistem mogoče obnoviti po morebitnih napakah, ki ogrožajo njegovo celovitost. Pogostost varnostnih kopij je odvisna od kritičnosti podatkov, količine shranjenih podatkov in pogostosti njihovega ustvarjanja.

OMCL morajo imeti strategijo in vzpostavljene postopke za zagotavljanje integritete varnostne kopije(varna lokacija shranjevanja, zadostna oddaljenost od glavne lokacije shranjevanja itd.) – ti ukrepi so lahko del splošnejšega »načrta za obnovitev po katastrofi«.

Vzpostaviti je treba tudi postopke za redno preizkušanje varnostnih kopij podatkov (preskus obnovitve), da se zagotovi ustrezna celovitost in točnost podatkov.

Arhiv zamenjanih različic programske opreme
Nadomeščene različice programske opreme je treba arhivirati (če je potreben dostop do zgodovinskih podatkov) za najmanj 5 let 1 v elektronski obliki, ki jo je mogoče zlahka pridobiti in prebrati.

Opomba: Ta zahteva ne velja za komercialno pripravljeno pisarniško programsko opremo (vključno s posodobitvami storitev), programsko opremo, ki jo arhivira kvalificirani podizvajalec, ali kjer so pretekli podatki (izvorni podatki in rezultati) dokumentirani v papirni obliki.
1 — Vodnik OMCL “ARHIVIRANJE V OMREŽJU OMCL”

Določanje različice programske opreme
Različica in ime programa morata biti prikazana uporabniku v ustrezni fazi uporabe programske opreme (na primer na zaslonu ob odpiranju aplikacije), prav tako pa se morata odražati v vseh poročilih, ki jih ustvari programska oprema.

Za laboratorijsko programsko opremo na računalnikih, vključenih v analitično opremo, je treba posodobitev programske opreme, vključno s številko različice, odražati v dnevniku opreme.

Pregled računalniških sistemov
Za računalniško podprte sisteme je treba redno izvajati dejavnosti obvladovanja tveganja in/ali revizije.

Usposabljanje operaterja programske opreme
Zagotoviti je treba pravilno delovanje programske opreme. To je mogoče doseči z ustrezno in dokumentirano pripravo ali z zastavitvijo podrobne informacije v ustreznih SOP.

3. POTRDITEV PROGRAMSKE OPREME ZA IZRAČUN
Za izračune in analizo podatkov je mogoče uporabiti komercialno ali lastniško programsko opremo.
Zahtevana dokumentacija/informacije veljajo za obe vrsti programske opreme in so navedene v tabeli I.

a) Komercialna programska oprema
Če je na voljo več vzorcev komercialne programske opreme, lahko laboratorij izbere tistega, ki najbolj ustreza namenu.

V skladu z ISO/IEC 17025 2 se komercialna standardna programska oprema (npr. urejevalniki besedil, baze podatkov in statistični programi) v določenih mejah splošne uporabe lahko šteje za zadostno potrjeno. Vendar je treba konfiguracije/spremembe laboratorijske programske opreme potrditi.
2 — Standard ISO/IEC 17025, poglavji 5.4.7 in 5.5.5.

Postopek preverjanja veljavnosti (teh konfiguracij/modifikacij) je mogoče skrajšati, če so bile vse uporabniške zahteve pregledane, dogovorjene in izpolnjene v dokumentaciji, ki je priložena komercialni programski opremi, pripravljeni za uporabo.

b) Programska oprema lastne zasnove
Če se uporablja lastniška programska oprema, mora biti pod nadzorom glavnega uporabnika (torej tistega, ki jo je razvil in vzdržuje posodobljeno), validirana, preverjena in zaščitena. Za več podrobnosti o validaciji glejte Dodatek 1.

Primarne zahteve
— Pri preglednicah (npr. Excel®) morajo biti iz varnostnih razlogov vse celice, ki vsebujejo izračune, zaklenjene, da se formule ne prepišejo pomotoma. Prost dostop naj bo omogočen le do celic, v katere so vneseni izvirni podatki. Formule morajo biti zaščitene pred nenamernim vnosom napačne podatkovne vrste (na primer besedilo v številsko polje).

— Vsak računski algoritem je treba preizkusiti z drugo programsko opremo (različica programske opreme, uporabljene za izračune, mora biti prikazana v zapisu) ali z uporabo žepnega kalkulatorja in dokumentirana, ali pa je treba rezultate izračuna primerjati z znanimi literaturnimi podatki.

— Za preverjanje programske opreme je treba uporabiti znani niz podatkov, za katerega so znani tudi identificirani in preverjeni rezultati.

Tabela I: Dokumentacija programske opreme

Informacije/dokumentacija, ki bi morala biti na voljo	Komercialna programska oprema	Lastno razvita programska oprema
Ime programske opreme, različica in enolični identifikator	X	X
Originalne datoteke (CD-ROM...) ali shramba za namestitev programske opreme in programske opreme za upravljanje računalniškega okolja	X	X
Datum zagona programske opreme	X	X
Trenutna fizična lokacija, če je potrebno	X	X
Odgovorna oseba za programsko opremo	X	X
Ime proizvajalca, številka licence in serijska številka ali drug edinstven identifikator	X
Pogoji, pod katerimi se program zažene, če je potrebno (strojna oprema, operacijski sistem, ...)	X	X
Potrdilo o potrditvi proizvajalca, če je na voljo	X
Navodila proizvajalca, če so na voljo, ali povezave do njihove lokacije	X
Dokumentacija za preverjanje konfiguracije/spremembe, ki jih je naredil uporabnik in lahko vplivajo na rezultate (glejte dodatke)	X
Polno ime osebe, ki je razvila in validirala programsko opremo, ter datum validacije		X
Izvorna koda, če je na voljo		X
Pravila delovanja, če je potrebno		X
Dokumentacija o rednem preverjanju programske opreme		X
Dokumentacija za preverjanje programske opreme (glejte dodatke)		X
Postopki v primeru napak, vzdrževanje poteka dela, posodabljanje različic in po potrebi upravljanje konfiguracij	X	X

4. VALIDACIJA RAČUNALNIŠKIH SISTEMOV ZA UPRAVLJANJE PODATKOVNIH BAZ
Zbirke podatkov, ki se uporabljajo za shranjevanje in pridobivanje rezultatov testiranja ter pripravo poročil o preskusih, ki so bile razvite v podjetju z uporabo komercialne programske opreme (npr. Access®) v svoji standardni konfiguraciji, veljajo za zadostno potrjene.

Vendar je treba naslednjo minimalno dokumentacijo/informacije posodabljati v ustrezni datoteki za vsako bazo podatkov:

Shematski prikaz baze podatkov.
Spremljati je treba spremembe obrazcev, poizvedb, makrov, vrst polj ali lastnosti, ki lahko vplivajo na kakovost rezultatov.
Vsak uporabnik mora imeti osebno dostopno kodo.
Uporabniške pravice morajo biti definirane.
Pravila delovanja je treba zabeležiti.
Vse spremembe za izboljšanje ali poslabšanje je treba dokumentirati.

5. VALIDACIJA LIMS in ELZ
Za komercialni laboratorij Informacijski sistemi(LIMS) in elektronske laboratorijske evidence (ELR), mora sistem validacije dokazati, da je bila programska oprema v celoti in pravilno testirana. Za več podrobnosti o validaciji glejte Dodatek 2.

Validacija vseh sprememb, konfiguracij ali izračunov, ki lahko vplivajo na rezultate, je odgovornost uporabnika (glejte odstavek 3.a in tabelo 1 za komercialno programsko opremo).

6. VALIDACIJA RAČUNALNIKOV KOT DELA ANALIZNE OPREME.
Nekatere preskusne metode (npr. HPLC, štetje delcev) uporabljajo analitično opremo, ki jo nadzira računalniški sistem. V tem primeru se tudi začetni podatki kot celota ocenijo neposredno preko računalnika. Tako je kakovost takšnih rezultatov v veliki meri odvisna od pravilno uporabo programska oprema in funkcionalnost računalniškega sistema. Za več podrobnosti o validaciji glejte Dodatek 3.

Kot del kvalifikacije opreme je treba računalniški sistem in z njim povezano programsko opremo testirati glede zanesljivosti, točnosti in natančnosti (to lahko zadostuje za kvalifikacijo analitične opreme in programske opreme kot celote).
Ponovna validacija je potrebna, kadar bi spremembe računalniškega sistema (strojne ali programske opreme) lahko vplivale na kakovost rezultatov testa.

Seznam aplikacij (velja za Najnovejša različica):

Pravzaprav je vse enako za biosoftware. Rekel bi celo, da bo postopek enak za vse računske programe. Veliko težje bo preveriti programsko opremo, ki je vključena v kompleksne medicinske naprave, na primer tomografe, naprave umetno dihanje ali na primer industrijske instalacije, kjer obstaja natančno pozicioniranje ali natančna cikličnost in zaporedje operacij. Za takšno programsko opremo so zahtevnejši testi že napisani in večkratni testi se izvajajo "z obremenitvijo".

Formule so vse tam, tudi na internetu. Zahodni matematiki imajo nekoliko drugačen slog pisanja znanih formul kot naši (sovjetski). Zato se že takoj zdi, da »niso tisto, kar potrebujemo«. Ni tako okoren, obstaja le veliko indeksov in spremenljivk, pogosto pa formula vsebuje najenostavnejše operacije: +, -, /, *, koren, stopnja. Včasih naletimo na diferencialne in integralne enačbe.

Tudi žepni kalkulatorji so različni. Tu in v drugih člankih ni bil mišljen Državljan za računovodjo, ampak vsaj preprost inženirski kalkulator. Zdaj, mimogrede, in celo v času Sovjetske zveze (moja elektronika je bila žepna, programabilna) so na voljo programabilni kalkulatorji. S pomočjo katerega lahko rešite na primer linearne enačbe v eni vrstici.

Za BE se uporablja samo eden - model brez predelkov (NCM). Vsi drugi modeli se uporabljajo v kliničnih preskušanjih ali v znanstvena raziskava. O NCM bo ločen članek. Kasneje... ko končam z aplikacijami OMCL.

Vladni oddelek EDQM je res jasno napisal. laboratoriji 8-). Še posebej mi je bila všeč priloga 1. Ilustrativni primeri- redkost v priročnikih...

Pri majhnih programih, napisanih za potrebe laboratorija v Excelu, si ni treba razbijati pameti - varno lahko opravite validacijo po vzorcu, ga shranite v mapo za recenzente.

Pri validaciji programske opreme za izračun bioekvivalence je vse bolj zapleteno.

Iskal sem (da si približno predstavljam, kako to izgleda) formule, ki opisujejo recimo nekakšen model bioekvivalence (no, zdi se, da obstaja splošni linearni model, GLM) - ki jih izračuna Kinetics ali SAS. V nobenem učbeniku ni navedenih primerov. Zdi se, da to ni zaupni podatek, a kje ga iskati - verjetno v kakšnih matematičnih monografijah izpred 60 let 🙄

Nisem našel, vem le, da so te formule tako okorne, da jih ne bo mogoče preračunati s programsko opremo s kalkulatorjem.

Pri validaciji »biosofta« obstaja le ena možnost testiranja - primerjati konvergenco rezultatov z izračuni na »primerjalnem stroju«, ki velja za veljavnega ... Kar je načeloma mogoče storiti le med namestitvijo in samo z prodajalec programske opreme.

V povezavi z dinamičnim razvojem dejavnosti podjetij, diverzifikacijo proizvodnje in storitev se postavlja vprašanje ustreznosti univerzalne programske opreme, ki se uporablja pri delu.

V dobi sodobne tehnologije možno je opraviti natančen pregled, preveriti vse kriterije za delovanje računalniško vodenega sistema. Ta postopek se imenuje validacija. Omogoča vam, da določite sposobnost sistema za izdajo želeni rezultat. Z drugimi besedami, validacija preveri, ali bo končni rezultat tak, kot je bilo pričakovano.

Obseg validacije

Mnoga podjetja trenutno delujejo z uporabo programskih izdelkov, ki temeljijo na 1C. Med njimi so farmacevtske organizacije, ki morajo strogo upoštevati mednarodne standarde in zahteve (na primer GMP). V zvezi s tem je vredno posvetiti pozornost GAMP 5- metodologija, ki vam omogoča spoštovanje standardov GMP. Ta vodnik vsebuje tudi priporočila in navodila za vodenje validacija računalniških sistemov.

V evropskih državah in Severna Amerika Validacija računalniške strojne opreme se je razširila onkraj farmacevtskih izdelkov in se pogosto uporablja v drugih panogah. Prepričani morate biti, da se bo ta trend preselil tudi v Rusijo in države CIS in ne bo nič manj pomemben in uporaben.

Validacija in verifikacija: podobnosti in temeljne razlike

Oba koncepta sta med seboj povezana s procesi testiranja. Vplivajo tudi na kakovost sistema. Kljub temu so med njima precejšnje razlike. Odnose med temi komponentami je mogoče izslediti na sl. 1.

Slika 1 – Razmerje med procesoma potrjevanja in preverjanja

Dejanja preverjanja so namenjena preverjanju zahtev, izvornih podatkov, programske kode itd. Pozitiven rezultat preverjanje bo skladnost teh komponent z uveljavljenimi pravili, standardi in razvito konfiguracijo programske opreme. Validacija je osredotočena na končni rezultat. Ugotoviti želi, ali bo uporabnik zadovoljen s samim izdelkom.

Z drugimi besedami, za verifikatorja je pomembno, ali sistem deluje pravilno. V zameno mora validator zagotoviti, da sistem daje pravilen rezultat, ki ga potrebuje uporabnik.

Za posvetovanje

Klasifikacija programske opreme po metodologiji GAMP 5

Pri določanju obsega dela v pripravljalni fazi validacije je potrebno določiti kategorije programske opreme, v katere spada naš programski izdelek. Najnovejša izdaja metodologije GAMP opredeljuje 5 kategorij programske opreme, ki jih je treba upoštevati med validacijo. Druga kategorija je bila zaradi zastarelosti umaknjena iz obravnave in ocenjena kot nepomembna (Tabela 1).

št.	ime kategorije	Vzorčna programska oprema	Pojasnila
jaz	Infrastrukturna programska oprema	operacijski sistem; storitve posodabljanja; antivirus itd.	Ni predmet potrjevanja. Posredno preverjena razpoložljivost. Je drugačen visoka stopnja zanesljivost. Ima nizka stopnja tveganje.
II	Vdelana programska oprema	Programska oprema v opremi; mikroprocesor itd.	Ta kategorija velja za zastarelo in se ne uporablja več.
III	Nekonfigurirani programi	paket Adobe; MS Office paket itd.	Komercialno dostopni paketni programi. Celovite validacije ni treba izvajati. Preverite pravilnost različice programske opreme in zaščite. Vredno je pripraviti program za usposabljanje osebja.
IV	Nastavljivi programski paketi (Konfigurirano)	SCADA itd.	Preverjanje konfiguracije in funkcionalnosti. Preverjanje skladnosti programa glede na specifikacijo uporabniških zahtev itd.
V	Individualno izdelane aplikacije (po meri)	programski izdelki, ki temeljijo na 1C; druge individualno razvite aplikacije.	Preverjanje konfiguracije in različice. Analiza programske kode. Preverjanje skladnosti z uporabniškimi specifikacijami. Testiranje programskih modulov. Usposabljanje zaposlenih itd.

Tabela 1 – Klasifikacija programske opreme po metodologiji GAMP5

Priprava na validacijo in njene faze

Postopek validacije računalniškega sistema je sestavljen iz niza zaporednih korakov.

Slika 2 – Diagram delovanja validacije

Pomembna točka pri izvajanju validacije je dokumentiranje vseh testov in rezultatov ter priprava protokolov. Ta dokumentacija zagotavlja dejanske dokaze, da je bila validacija zaključena. Ob koncu postopka se sestavi zaključno poročilo. Če je šlo vse v redu, je označeno, da sistem ustreza standardom in je pripravljen za uporabo.

V pripravah na validacija programske opreme ustvariti morate URS:

določiti, v katero kategorijo spada naša programska oprema, kateri sistemi bodo sodelovali v procesu;
izvesti podrobno specifikacijo potreb in zahtev uporabnikov (vmesnik, varnost, materialni viri);
določiti uradnike, odgovorne za postopek potrjevanja, in določiti roke;
sestaviti glavni načrt validacije.

Ta projekt in zahteve se nato prenesejo na dobavitelja programske opreme.

Dobavitelj izdela funkcionalno zasnovo (FS), ki bo zadovoljila specifikacije uporabniških zahtev(URS). Ta dokument mora ustrezati zahtevam uporabnika v vsakem odstavku. Če dobavitelj ne more ponuditi rešitve za njegovo implementacijo, lahko ponudi implementacijo teh funkcij preko dodatne programske opreme. Stranka pa lahko zavrne in izbere drugega dobavitelja.

Sestavljeno tehnične zahteve sistemu je opisana materialna in programska osnova (DS). Izvaja se tudi analiza tveganja. V obravnavo so posredovane vse morebitne kritične situacije, ki se lahko pojavijo med procesom dela. Identificiramo sistemske funkcije z največjim tveganjem in izvajamo ustrezne metode za njihovo spremljanje in nadzor.

Ko zberemo potrebno dokumentacijo in pripravimo sistem, nadaljujemo neposredno z njegovo kvalifikacijo (IQ). Najprej se ugotovi pravilna namestitev komponent – od materialnih komponent (strežniki, tiskalniki ipd.) do nameščenega operacijskega sistema. Ta stopnja ne more začeti, če ni pripravljena dokumentacija o prejšnjih korakih.

Nato se določi zmogljivost programske rešitve (OQ). Testiranje se izvaja za odkrivanje napak v sistemu. Vse okvare se zapišejo v protokol, po katerem se pripravi rešitev tega problema za sistem kategorije 5. pravilno delo funkcionalnost, ki izpolnjuje zahteve, se preveri z naslednjimi metodami:

testiranje enot;
integracijsko testiranje;
funkcionalno testiranje.

Poleg teh testov se lahko preverjanje dopolni s testi pred zagonom v proizvodnem sistemu. Po odpravi napak se prepričajo, da program deluje pravilno in preidejo v končno fazo.

Zadnji korak je preverjanje, ali je program pripravljen za delo v produkcijskem okolju z neposrednimi uporabniki (PQ). Izvede se analiza nastajajočih okvar, naravnih sprememb v sistemu in splošne učinkovitosti delovanja. Treba je preveriti uporabnost vseh kritičnih napak, ki so se pojavile na prejšnjih stopnjah kvalifikacije. Uporabniki so usposobljeni za uporabo programske opreme. Po uspešnem testiranju programske rešitve v produkcijskem okolju se šteje, da je sistem pripravljen za uporabo.

9.–10. julija je v Kijevu potekalo usposabljanje o vprašanjih validacije računalniških sistemov v skladu z zahtevami dobre proizvodne prakse, ki je združilo predstavnike vodilnih lokalnih proizvajalcev, kar kaže na pomembnost te teme. Avtor in voditelj usposabljanja, ki ga je organiziralo podjetje "Standards Technologies Development", je bil Zhansen Fabris, specialist na tem področju informacijske tehnologije in validacijo računalniško podprtih sistemov v skladu z zahtevami 21CFR Part 11, Good Automated Manufacturing Practices (GAMP) in metodologijami Information Technology Infrastructure Library (ITIL), z dolgoletnimi izkušnjami v multinacionalnih farmacevtskih podjetjih.

Danes je skladnost z zahtevami domačih in tujih farmacevtskih podjetij predpogoj za promet zdravil v Ukrajini. Od 1. januarja 2011 Civilna služba Ukrajina z zdravila postal član mednarodni sistem sodelovanje farmacevtskih inšpekcij (Pharmaceutical Inspection Cooperation Scheme - PIC/S), ki je omogočilo optimizacijo postopka pridobivanja certifikata o skladnosti z zahtevami GMP.

Validacija: Začnimo! Pozor! marec!

IQ je stopnja, na kateri se preverja popolnost opreme, pravilnost njene namestitve, popolnost in ustreznost prejete dokumentacije, skladnost uporabljene materialne baze z navedeno v TS, skladnost videz in pravilno označevanje opreme.

Cilji IQ so preveriti:

— ali je vsak element napeljave pravilno nameščen;
- ali ustrezajo temu? specifikacije URS, TS in regulativne zahteve;
— dokumentacija dobavitelja;
— ali se upoštevajo postopki;
— ali računalniški sistem ustreza testiranemu računalniškemu sistemu.

Med IQ elementi, kot so materialna baza (strežniki, tiskalniki itd.), računalniški sistemi (Unix, Windows, DOS, sistem za upravljanje računalnikov), pa tudi njihove nastavitve, računalniško okolje (omrežje, podatkovni center, SAN, DRP). ).

Med potrjevanjem nov sistem IQ se izvaja dvakrat - v kvalifikacijskem in proizvodnem okolju.

Če so med preskusi zabeležena odstopanja (napake), jih je treba odpraviti s predhodno razvitimi merili sprejemljivosti sistema. Če odstopanja presežejo sprejemljive meje, je treba sprejeti ukrepe za njihovo odpravo in ponovno izvesti teste, ki jih zagotavlja IQ. Po uspešnem zaključku IQ lahko nadaljujete na naslednjo stopnjo.

OQ zagotavlja dokumentirane dokaze, da funkcije sistema in pripadajoče opreme delujejo pravilno. V tem primeru naj bodo pogoji za izvedbo testov čim bližje pogojem za uporabo sistema v produkcijskem okolju.

Proces OQ preveri, ali sistem deluje v skladu z zahtevami FS, ali deluje brez napak in ali dovoljuje prepovedana dejanja. Hkrati se razvija poseben komplet teste, ki jih izvaja tester v skladu s protokoli, njihovi rezultati pa so ustrezno dokumentirani (na primer natisnjeni so posnetki zaslona). Na podlagi rezultatov opravljenih preizkusov se sestavi poročilo.

Pri izvajanju OQ se zagotovo pojavijo napake - sistem ne more delovati popolno. Poročila o napakah se dokumentirajo, nato pa se na podlagi meril sprejemljivosti sprejme odločitev, da se jih popravi (ali ne popravi). Če napaka ni kritična za pravilno delovanje sistema, potem se ne odpravi. To dejstvo je dokumentirano, dodatna obrazložitev razloga za takšno odločitev pa je obvezna.

Ko so napake odpravljene, se testi ponovno izvedejo, po njihovem uspešnem zaključku in pripravi ustreznih poročil pa lahko nadaljujete na naslednjo stopnjo validacije.

PQ je dokumentarni dokaz, da sistem deluje v skladu z uveljavljenimi zahtevami. PQ je sestavljen iz 2 stopenj - PQ1 (dovoljenje za zagon sistema) in PQ2 (spremljanje procesa delovanja sistema).

Da bi omogočili uporabo sistema v produkcijskem okolju, je treba preveriti, ali so vsi kvalifikacijski koraki opravljeni brez kritičnih napak in ali je organizacija (podjetje/določeni oddelki) pripravljena za uporabo sistema. Nujno je, da je uporabniški dostop do sistema registriran (prijava, geslo itd.); podatki so bili preneseni iz predhodno uporabljenega sistema; uporabniki so bili usposobljeni za delo v sistemu (na voljo je bila ustrezna dokumentacija); Za delo v sistemu so izdelani SOP (standardni operativni postopki) (upravljanje dostopa, spremembe, okvare itd.). Tako se po pregledu dokumentacije sistem zažene.

RQ2 se izvaja s pomočjo KPI-jev in analizira učinkovitost sistema, pogostost okvar, izvedene spremembe itd. Regulativni organ ZDA priporoča izvajanje PQ2 enkrat mesečno 3 mesece.

Testiranje se izvaja le, če obstajajo odobreni dokumenti, ki urejajo njegovo izvajanje (protokoli, testi). Dobljene rezultate nato primerjamo s pričakovanimi rezultati (v skladu s specifikacijami). Rezultate vsakega preizkusa je treba hraniti, ker zagotavljajo dokaz, da je bil sistem potrjen, in ker jih lahko revizor med presojo zahteva. obstajati posebni programi, ki omogočajo delo s testi in njihovimi rezultati, vendar jih je treba pred uporabo tudi validirati, saj bodo v prihodnje delali z informacijami, ki vplivajo na skladnost z zahtevami GxP.

Rezultate vseh opravljenih testov je treba preveriti. Pomembno je, da tester, ki je opravil test, ne more preveriti njegove izvedbe. To lahko stori zaposleni v oddelku za nadzor kakovosti podjetja.

Po zaključku vseh faz validacije se sestavi končno validacijsko poročilo, ki v primeru uspešnega procesa pokaže, da je sistem pripravljen za uporabo in je skladen s standardi GxP.

Po zaključku procesa validacije pa se delo ne konča – začne se še težja faza – vzdrževanje sistema v validiranem stanju. Za to so predpisani pristopi za obvladovanje sprememb. Razlog za spremembe je lahko napaka (odprava napake) ali administrativna odločitev. Pri uvajanju sprememb validiranega sistema je potrebno oceniti njihov vpliv (nova tveganja), po izvedbi pa opraviti kvalifikacije (IQ ali OQ, po potrebi - PQ) in popraviti dokumente.

Obstaja tudi koncept retrospektivne validacije. Njegova izvedba je predpisana v PIC/S. Izvaja se, če sistemi že delujejo in niso potrjeni. Za to je potrebno napisati specifikacije URS in/ali FS, TS in preveriti skladnost sistema z zahtevami GxP (za to se izvajajo IQ, ОQ, РQ).

Tako podjetje z validacijo pridobi dokumentarne dokaze o pravilnem delovanju informatiziranega sistema, kar bistveno zmanjša tveganje za napake, stroške delovnega časa za njihovo prepoznavanje in odpravljanje ter ustrezne spremembe.

Validacijo računalniških sistemov ureja Priloga 11 Smernic EU GMP. Zlasti je načeloma navedeno, da IT infrastruktura mora biti kvalificiran in vloga mora biti potrjena.

Za rešitev tega problema je pristop, ki temelji na analiza tveganja in ob upoštevanju življenjskega cikla računalniških sistemov. Struktura priloge 11 je poudarjena posebej projektna faza in operativna faza.

Ena najbolj nazornih definicij računalniško podprtega sistema je grafično podana v 6. razdelku PI 011-3 DOBRE PRAKSE ZA RAČUNALNIŠKO PODREJENE SISTEME V UREJENIH OKOLJIH GXP:

riž. 1 Opredelitev računalniškega sistema

Glede na sl. 1 lahko rečemo, da je računalniški sistem sestavljen iz računalniškega (krmilnega) sistema in nadzorovane funkcije ali procesa v definiranem delovnem okolju (omrežno okolje ali posamezni računalniški sistemi, drugi sistemi, mediji za shranjevanje, ljudje, oprema in postopki).

Opredelitev računalniški sistem glede na glosar EU GMP Manual zveni takole: sistem, ki vključuje vnos podatkov, elektronsko obdelavo in izpis informacij za uporabo bodisi kot poročanje bodisi za avtomatiziran nadzor.

Spodaj življenski krog Glosar dodatka 11 zajema vse faze življenjske dobe sistema od začetne zahteve do razgradnje, vključno z njegovo zasnovo, specifikacijo, programiranjem, testiranjem, namestitvijo, delovanjem in vzdrževanjem.

Drug poseben izraz je koncept IT infrastruktura, ki je strojna in sistemska programska oprema (programska oprema, kot je omrežna programska oprema, operacijski sistemi), ki omogoča delovanje aplikacij.

Analiza tveganja nam omogoča prepoznavanje t.i GxP-relevantni računalniški sistemi ali posamezne GxP-relevantne funkcije ali moduli računalniško podprtega sistema. Z vidika GxP so osredotočena na glavna tveganja varnost pacientov, kakovost izdelka in celovitost podatkov v njihovem pogledu. Po identifikaciji računalniških sistemov (funkcij, modulov), pomembnih za GxP, se zdi mogoče prerazporediti vire v zvezi z njimi, ne da bi upoštevali vse računalniške sisteme (funkcije, module) v v celoti, ki vam omogoča razumno optimizacijo postopka potrjevanja računalniških sistemov brez ogrožanja zgoraj omenjenih kategorij GxP.

Če se vrnemo k vidiku življenjskega cikla, je pomembno ugotoviti, na kateri stopnji je določen sistem. Optimalno je, če je nov računalniški sistem šele načrtovan za razvoj in implementacijo. V tem primeru je treba zaporedno iti skozi vse faze faze načrtovanja, začenši z URS (User Requirements Specification) - specifikacijo uporabniških zahtev. Če računalniško podprt sistem že deluje (tako imenovani podedovani sistemi), potem je treba v skladu z odstavkom 16.6 PI 011-3 DOBRE PRAKSE ZA RAČUNALNIŠTVO PODREJENE SISTEME V REGULACIRANEM OKOLJU GXP URS vsaj za nazaj ustvariti (tj. opredeliti formalno računalniško sistemske zahteve), opišite sistem in predložite dokaze, da je bil računalniški sistem preizkušen in izpolnjuje zahteve GxP.

Ker so zahteve vloge splošni značaj, za njihovo podrobnost je uporabna razlaga ISPE GAMP CoP (Community of Practice), ki v glavnem obravnava GAMP 5: Na tveganju temelječ pristop k skladnemu GxP računalniškemu vodniku po sistemih.

V tem priročniku so izčrpno opisani vsi vidiki v zvezi z informatiziranimi sistemi, predvsem pa so podani vsi potrebni organizacijski dokumenti in aktivnosti na strani naročnika (VMP, ocena dobavitelja, analiza tveganja itd.), podrobno je opisana faza načrtovanja (URS, FS, razvoj). , testiranje) in operativna faza.

Pomembno je razumeti, da je validacija računalniških sistemov korak k dokaj dobro razvitim in podrobnim procesom razvoja programske opreme. Validacija računalniških sistemov je lahko precej delovno intenzivna; v zvezi s tem GAMP 5 predlaga razlikovanje med več kategorijami programske opreme za lažjo oceno:

	Opis	Opomba	Primeri
Kategorija 1	Infrastrukturna programska oprema	BY sistemski ravni	OS, DBMS, razvojna okolja, sistemi za nadzor omrežja
Kategorija 2	Tako imenovana firmware je izključena iz GAMP
Kategorija 3	Nekonfigurirana programska oprema	Lahko vključuje nastavljive, vendar s privzetimi nastavitvami	Običajno komercialno dostopna programska oprema, kot je MS Excel
Kategorija 4	Konfigurirana programska oprema	Uporablja standardno funkcionalnost komercialno dostopne programske opreme	Datoteka za izračun LIMS, SCADA, EDMS, HMI, MS Excel z uporabo standardnih funkcij (SUM, AVERAGE VALUE)
Kategorija 5	Programska oprema po meri	Implementirana koda/logika po meri	MS Excel z makri, ERP, avtomatiziran nadzorni sistem

Pri zapletenih računalniško podprtih sistemih lahko pride do zapletene situacije, ko so lahko posamezni moduli razvrščeni v različne kategorije. Ta pristop nam omogoča, da programsko opremo kategorije 5 izpostavimo kot najbolj kritično, saj gre za individualni razvoj popolna odsotnostširoko uporabljenih analogov je tveganje za napake najverjetneje. V tem primeru se je treba obrniti na dejansko prakso testiranja programske opreme, ne glede na farmacevtski vidik.

V praksi QA v IT obstajata dve vrsti testiranja: tako imenovano testiranje. front end in back end oziroma z drugimi besedami zunanji vmesnik in programska koda. V zvezi s tem postane jasno, da brez tesnega sodelovanja z razvijalcem (dobaviteljem/integratorjem/prodajalcem) računalniško podprtega sistema postane dokončanje zadnje naloge skoraj nemogoče (ali izjemno težko). Razlog je preprost - izvorna programska koda je bodisi načeloma nedostopna (na primer, v primeru PLC-ja jo je mogoče preprosto zaščititi z geslom), bodisi, če je na voljo, jo revidiramo brez sodelovanja razvijalca za že delujoč sistem je brez praktičnega pomena. V skladu s priporočili GAMP 5 je treba izvesti revizijo izvorne kode:
a) pravočasno med razvojem sistema;
b) s sodelovanjem razvijalca in vsaj enega neodvisnega strokovnjaka z ustreznim znanjem in izkušnjami.
Navsezadnje, če je ta korak izpuščen (kar pogosto velja za že delujoče računalniško podprte sisteme), je dovolj, da preizkusite funkcije računalniško podprtega sistema, da zagotovite, da izpolnjuje prvotne zahteve. In to je izključna odgovornost stranke (lastnika računalniško podprtega sistema).

Značilnost računalniško podprtega sistema je, da operativna faza nominalno vsebuje večje število zahteve kot faza načrtovanja. To je upravičeno, saj so računalniško podprti sistemi zelo občutljivi na nenehne spremembe v okolju, na primer infrastrukturna programska oprema na sistemski ravni se nenehno posodablja, zmogljivost celo nespremenjenega aplikacijskega programa se lahko spremeni, ko se spremeni strojna oprema ali konfiguracija obstoječega. Lahko se na primer spremeni strežniška oprema ali izvede virtualizacija z uporabo obstoječe strežniške in omrežne opreme lokalno omrežje. Smiselno je, da je taka pozornost namenjena posebej IT vidikom delovanja računalniških sistemov. Zato zahteve iz dodatka 11 (kot tudi priporočila GAMP 5) vključujejo delovna mesta, ki temeljijo na najboljših praksah IT (ITSM, COBIT, ITIL). Posebna pozornost namenjen varnostnemu kopiranju in obnovitvi iz varnostnih kopij, upravljanju sprememb in incidentov, arhiviranju, upravljanju konfiguracije, kontinuiteti poslovnih procesov itd. Od dejanskih zahtev, pomembnih za GxP, je mogoče razlikovati le "dovoljenje za izdajo serije" in, z nekaj napetosti, "elektronske podpise". Zato je druga posledica ta, da je učinkovita skladnost z operativnimi zahtevami iz Priloge 11 nemogoča brez polne vključenosti oddelka IT regulirane družbe. Zlasti je morda priporočljivo opraviti presojo samega IT oddelka glede skladnosti s standardi serije ISO 20k (ITSM, ki ga lahko poenostavimo kot »okrnjeni del ITIL«) ali ISO 27k (ISMS – sistem upravljanja). varnost informacij). Zahteve GxP so popolnoma komplementarne zgornjim IT praksam v kontekstu informatiziranih sistemov, zato so zgrajeni bistveno identični IT procesi, brez katerih je upravljanje informatiziranega sistema nemogoče. S to formulacijo je delovanje farmacevtskih računalniških sistemov poseben primer.

Brez te funkcije ni redko pričati patchwork, izolirano gradnjo poslovnih procesov, ko oddelek za vodenje kakovosti farmacevtskega podjetja gradi svoj sistem, oddelek IT pa svojega, kar ni skladno s prvim.

Podjetje LabPromEngineering nudi celovit pristop k zagotavljanju regulatorne skladnosti v skladu z Dodatkom 11 GMP ob hkratnem pokrivanju aktivnosti samega IT oddelka.