zagotavljanje regulatorne skladnosti … · posledica zahtevnih regulatornih zahtev so lahko zamude...

Magistrsko delo Organizacija in management informacijskih sistemov

ZAGOTAVLJANJE R EGULATORNE SKLADNOSTI RAČUNALNIŠKIH SISTEMOV V

FARMACEVTSKI INDUSTRIJI

Mentor: red. prof. dr. Robert Leskovar Kandidat: Gašper Zupin

Kranj, maj 2016

ZAHVALA Zahvaljujem se mentorju prof. dr. Robertu Leskovarju za pomoč in strokovno usmeritev pri izdelavi magistrske naloge. Prav tako gre zahvala sodelavcu Sergeju za usmeritev in pomoč pri izdelavi naloge.

POVZETEK

Magistrsko delo obravnava zagotavljanje regulatorne skladnosti računalniških sistemov v farmacevtski industriji. Obravnava načine obvladovanja in zagotavljanja skladnosti računalniških sistemov, opiše delovanje in pomen regulatornih organov, ki bedijo nad delovanjem farmacevtske industrije in predstavi ključni regulatorni direktivi za področje računalniških sistemov v reguliranem okolju 21 CFR PART 11 ameriške agencije za hrano in zdravila FDA (ang. Food and Drug Administration) in ANEX 11 evropske agencije za medicino EMA. Na primeru konkretne farmacevtske organizacije predstavi koncept validacije računalniških sistemov v farmacevtski industriji, definira deležnike in njihove odgovornosti, kategorizira sisteme, navaja seznam potrebne validacijske dokumentacije in pripravo končnega validacijskega poročila. Izpostavi pomembnost vzdrževanja regulatorne skladnosti računalniškega sistema skozi življenjski cikel sistema, predstavi zagotavljanje pravilnega delovanja v povezavi z upravljanjem z incidenti, odstopi, spremembami in ostalo varnostno politiko, ki zagotovi, da sistem ostaja primeren za produkcijsko delovanje glede na uporabniške in regulatorne zahteve. V primeru nepravilne implementacije in upravljanja sistema predstavlja odstopanje glavni izziv s katerim se lahko sreča farmacevtsko podjetje. Odstopanja prepoznana s strani zunanje regulatorne organizacije kot je na primer FDA lahko privede do nepredvidenih stroškov, izgube ugleda družbe in v najbolj drastičnih primerih prepoved proizvodnje in distribucije zdravil. V študiji primera je analiziranih zadnjih 50 opozorilnih pisem ameriške agencije FDA s področja računalniških sistemov v farmacevtski industriji glede na frekvenco pojavnosti. Prepoznane kritične tematike in predstavljeni razlogi za pojav, kot so manjkajoči splošni postopki in brisanje izvornih podatkov računalniškega sistema, so lahko farmacevtskemu podjetju v pomoč pri fokusiranju na najbolj aktualna področja zagotavljanja regulatorne skladnost. Zaradi kompleksnosti zagotavljanja skladnosti, posledično velikih naporov in visokih stroškov za podjetje in vse bolj natančnih pregledov inšpektorjev, naloga podaja predloge kako bi podjetje lahko preprečilo pojav nepravilnosti prepoznanih s strani regulatornih organov na inšpekcijskih pregledih. Z analizo opozorilnih pisem je bilo ugotovljeno, da lahko podjetje s pravilnim pristopom, doslednim upoštevanjem regulative in z zadostnim vložkom v ljudi in tehnične rešitve preide v stanje, ki je skladno z regulatornimi zahtevami in pričakovanji zunanjih inšpektorjev. Tako se podjetje v vse bolj konkurenčni farmacevtski industriji lahko osredotoči na svojo primarno poslanstvo: razvoj in proizvodnjo visoko kakovostnih in varnih zdravil za paciente, ki jih potrebujejo.

KLJUČNE BESEDE: - Regulatorna skladnost računalniškega sistema - Regulatorni organ - Validacija - Življenjski cikel - Odstopanje in opozorilno pismo

ABSTRACT The work explains how to ensure regulatory compliance for computerized systems in pharmaceutical industry. It describes different ways of controlling and ensuring computerized systems regulatory compliance, explains how the regulatory agencies operate and present a key regulatory standards for computerized systems – American government agency FDA (Food and drug administration) standard 21 CFR PART 11 and European agency for medicine standard EMA ANEX 11. On the case of concrete pharmaceutical company the thesis describes the concept of validation of computerized systems in pharmaceutical industry, defines stakeholders and their responsibilities, categorizes computerized systems, and lists the necessary validation documentation and preparation of the final validation report. The work outlines the importance of maintaining the regulatory compliance throughout the life cycle of computerized system. Furthermore, it explains, how to maintain proper performance of the system with regards to incidents, deviations, changes and other relevant security politics management, which altogether ensure the system suitability for production according to user and regulatory requirements. If the system is not implemented and managed properly, the deviations can represent a major challenge for pharmaceutical company. Deviations recognized from external regulatory agency, such as FDA can, can lead to unexpected costs, loss of company reputation and in the most drastic cases prohibition to distribute and sale drugs to end customers. This case study analyzes the last 50 FDA warning letters for computerized systems in pharmaceutical industry based on the frequency of their occurrence. The identified critical topics and reasons for receiving warning letters, such as lack of internal procedures or deleting the raw data, could help pharmaceutical company to focus on most current topics of regulatory compliance for computerized systems. Ensuring compliance of the systems is very complex, consequently, great effort and high costs are needed to handle the systems and to deal with more and more detailed inspections. Therefore, the master thesis proposes how company should deal with compliance risks in order to prevent the deviations and their discovery during inspections. Analysis of warning letters showed that with the proper approach, strict compliance with regulations and adequate investment in human reassures and technical solutions, company can move up to the level where they will meet regulatory requirements and, consequently, expectations of inspectors. A company in an increasingly competitive pharmaceutical industry can then focus on their primary mission: to develop and produce high quality and safe medicines for patients who need them.

KEYWORDS: - Computerized system regulatory compliance

- Regulatory agency

- Validation

- Lifecycle management

- Deviation and warning letter

KAZALO

1 UVOD ...................................................................................... 1

1 METODOLOGIJA .......................................................................... 1

1.1 OPREDELITEV PROBLEMA .......................................................... 1

1.2 OPREDELITEV CILJEV .............................................................. 2

1.3 UPORABLJENE METODE DELA ..................................................... 2

2 TEORETIČNE OSNOVE ................................................................... 3

2.1 DEFINICIJE IN OSNOVNI POJMI .................................................... 3

2.2 REGULATORNI ORGANI V FARMACEVTSKI INDUSTRIJI ......................... 5

2.3 REGULATORNE ZAHTEVE ZA RAČUNALNIŠKE SISTEME ......................... 5

3 PROCES ZAGOTAVLJANJA REGULATORNE SKLADNOSTI RAČUNALNIŠKEGA SISTEMA ........................................................................................ 7

3.1 VALIDACIJA RAČUNALNIŠKEGA SISTEMA ........................................ 10

3.1.1 DELEŽNIKI IN ODGOVORNOSTI.............................................. 10

3.1.2 KATEGORIZACIJA IN KROVNA OCENA RIZIKOV ........................... 11

3.1.3 DOKUMENT »UPORABNIŠKE ZAHTEVE« .................................... 13

3.1.4 PLANIRANJE VALIDACIJE .................................................... 14

3.1.5 SPECIFIKACIJE ................................................................ 15

3.1.6 TESTIRANJE RAČUNALNIŠKIH SISTEMOV .................................. 16

3.1.7 VALIDACIJSKO POROČILO ................................................... 17

3.2 VZDRŽEVANJE VALIDIRANEGA STANJA ......................................... 18

3.2.1 ZAGOTAVLJANJE NEMOTENEGA DELOVANJA SISTEMA .................. 19

3.2.2 UPRAVLJANJE Z INCIDENTI ................................................. 20

3.2.3 VARNOST, DOSTOPNOST IN USPOSABLJANJE UPORABNIKOV .......... 22

3.2.4 PERIODIČNI PREGLEDI ....................................................... 23

3.2.5 VARNOSTNO KOPIRANJE IN RESTAVRIRANJE ELEKTRONSKIH ZAPISOV 26

3.2.6 ARHIVIRANJE IN POVRNITEV ELEKTRONSKIH ZAPISOV .................. 26

3.2.7 UPRAVLJANJE S SPREMEMBAMI ............................................. 27

3.2.8 UMIK RAČUNALNIŠKEGA SISTEMA .......................................... 28

3.3 ODSTOPANJE ....................................................................... 29

3.3.1 IZRAZI POVEZANI Z ODSTOPANJI ........................................... 30

3.3.2 KLASIFIKACIJA ODSTOPOV NA PROCESU .................................. 31

3.3.3 KLASIFIKACIJA ODSTOPOV NA NOTRANJI PRESOJI ....................... 32

3.3.4 KLASIFIKACIJA ODSTOPOV NA ZUNANJI PRESOJI ........................ 33

3.4 OBSEG IN VSEBINA VALIDACIJSKE DOKUMENTACIJE TEKOM ŽIVLJENSKEGA CIKLA 34

4 TRENDI PRESOJ FDA ZA PODROČJE RAČUNALNIŠKIH SISTEMOV .................. 35

4.1 ODSTOPANJA S PODROČJA RAČUNALNIŠKIH SISTEMOV ...................... 35

4.2 ANALIZA ODSTOPANJ INŠPEKCIJ FDA NA RAČUNALNIŠKEM PODROČJU .... 36

4.2.1 UVRSTITEV ODSTOPOV V SKUPINE GLEDE NA TEMATIKO ODSTOPANJ 37

4.2.2 RAZLAGA REZULTATOV ANALIZE ........................................... 39

5 PRIPOROČILA ZA POSAMEZNO TEMATIKO OPOZORILNIH PISEM ................... 45

5.1 BRISANJE IN SPREMINJANJE IZVORNIH PODATKOV ........................... 45

5.2 ZGODOVINA DOGODKOV .......................................................... 47

5.3 KONTROLA NAD RECEPTURAMI ALI METODAMI ................................ 47

5.4 ODSTOPANJE, KOREKTIVNI UKREPI IN PREDLOG ZA SPREMEMBO ........... 48

5.5 NEPOOBLAŠČENI DOSTOPI ........................................................ 48

5.6 PRIPOROČILA ZA OSTALE TEMATIKE ............................................ 49

5.7 SKLEPNA ANLIZA TEMATIK OPOZORILNIH PISEM............................... 50

6 ZAKLJUČEK .............................................................................. 52

LITERATURA .................................................................................. 53

KAZALO SLIK .................................................................................. 54

KAZALO TABEL ............................................................................... 54

PRIOLOGA 1 .................................................................................... 1

Univerza v Mariboru – Fakulteta za organizacijske vede Magistrsko delo

Gašper Zupin: Zagotavljanje regulatorne skladnosti računalniških sistemov v farmacevtski industriji

stran 1

1 UVOD Kot v vseh industrijskih panogah je tudi v farmacevtski informacijska tehnologija (IT) vse bolj prisotna pri avtomatizaciji in optimizaciji razvojnih in proizvodnih procesov. Zaradi pomembnosti panoge za zdravje ljudi in posledično visoke zahtevnosti poslovanja morajo računalniški sistemi opravljati in nadzorovati tehnološko zelo kompleksne procese. V farmacevtski industriji poteka uvajanje računalniških sistemov v procese podjetja zaradi strogih regulatornih omejitev vedno z zamudo glede na razpoložljive tehnologije. Razlog je preprost: računalniški sistemi za farmacevtsko industrijo so kompleksni, zaprti in varnostno občutljivi. Pojavnost morebitnih napak v delovanju računalniškega sistema je zato lahko kritično vpliva na kvaliteto zdravila. Posledice morebitnih napak so enormne in imajo lahko vplivajo na potek zdravljenja pacienta. Zato je pravilno delovanje računalniškega sistema ključnega pomena pri proizvodnji ustreznih in posledično varnih zdravil. Čas razvoja računalniškega sistema je daljši kot pri večini drugih industrijskih panogah. Sama implementacija v farmacevtsko okolje zahteva veliko več resursov in birokratskih postopkov, ki so posledica regulatornih zahtev agencij. Te preverjajo proizvodne procese in samo poslovanje podjetij. Razlogi strogega nadzora tičijo v morebitnih manipulacijah in bližnjicah, ki bi jih podjetja lahko uporabljala pri proizvodnji zdravil z namenom znižanja stroškov, višjih dobičkov in posledično ogrožanje varnosti in zdravja pacientov. Kot za vse procese mora biti tudi za računalniške sisteme na voljo dokumentacija, ki dokazuje, da ima podjetje delovanje sistema pod nadzorom in da svoje delo opravlja skladno s pravili regulatornih organov. Posledica zahtevnih regulatornih zahtev so lahko zamude pri implementaciji naprednih računalniških tehnologij v vsakodnevne procese v farmacevtskem podjetju. Zato je zelo pomembno, da podjetje ustrezno reagira in zagotovi zadostne resurse v celotnem življenjskem ciklu računalniškega sistema v farmacevtskem podjetju. Da bi dosegli takšno stanje morajo odgovorni ob čim nižjih stroških implementacije in uporabe zadostiti zahtevam regulatornih organov po skladnosti ter kakovosti končnih proizvodov – zdravil.

1 METODOLOGIJA

1.1 OPREDELITEV PROBLEMA Izzivi zagotavljanja skladnosti računalniških sistemov, na katera mora podjetje paziti v vseh fazah življenjskega cikla so:

- implementacija sistema v okolje podjetja, - kvalifikacija instrumenta in validacija programske opreme in ostalih

procesov povezanih s sistemom, - nadzor nad sistemom in preprečevanje nepravilnosti tekom uporabe, - politika upravljanja sprememb, incidentov in odstopanj, - kontrolirana upokojitev in implementacija novih sistemov, - pripravljenost na inšpekcijske preglede regulativnih organov, - obvladovanje stroškov in resursov za zagotavljanje regulatorne skladnosti

sistemov.



stran 2

Neustrezno zagotavljanje skladnosti in nepravilno obvladovanje računalniškega sistema v vseh fazah življenjskega cikla lahko pripelje do naslednjih problemov:

- neustrezna kakovost razvitih in proizvedenih zdravil, - zamude pri dobavi zdravil pacientom ali prepoved le te, - posledično višji stroški poslovanja in nižja konkurenčnost podjetja, - izguba ugleda podjetja, ki prizadene lastnike, zaposlene, bolnike in širšo

javnost.

1.2 OPREDELITEV CILJEV Cilji magistrske naloge so:

- opisati delovanje regulatornih organov v farmacevtski industriji, - preučiti regulatorne zahteve 21 CFR PART 11 in ANEX 11, - definirati potrebne validacijske korake, ki zagotavljajo regulatorno

skladnost računalniškega sistema v farmacevtski industriji, - opredeliti odstopanja v opozorilnem pismu in navesti razloge take pojave, - analizirati opozorilna pisma ameriške agencije FDA v zadnjem obdobju za

področje računalniških sistemov, - podati priporočila za zagotavljanje regulatorne skladnosti računalniških

sistemov in preprečitev pojava opozorilnega pisma v farmacevtskem podjetju.

1.3 UPORABLJENE METODE DELA V magistrski nalogi so uporabljene naslednje metode dela:

- študij literature o delovanju regulatornih agencij in regulatornih standardih za računalniške sisteme v farmacevtski industriji,

- empirična analiza stanja v konkretnem primeru farmacevtskega podjetja, ki bo obsegala implementacijo regulatornih zahtev za validacijo računalniških sistemov,

- klasifikacija možnih odstopanj računalniških sistemov v farmacevtskem podjetju od regulatornih zahtev,

- vsebinska analiza odstopanj na podlagi opozorilnih pisem FDA za področje računalniških sistemov v obdobju dveh let,

- agregiranje predlogov za preprečitev odstopanj na podlagi stanja, proučenih dobrih praks in lastnih izkušenj.



stran 3

2 TEORETIČNE OSNOVE

2.1 DEFINICIJE IN OSNOVNI POJMI Regulatorni organi varujejo javno zdravstvo z zagotavljanjem, da so zdravila varna, celovita, kakovostna, učinkovita, pravilno pakirana in pravilno distribuirana (FDA, 2015). GAMP 5 (Good Automated Manufacturing Practice) podaja stroškovno učinkovita pravila dobrih praks, ki zagotavljajo, da je računalniški sistem primeren in skladen za uporabo v reguliranem okolju farmacevtskega podjetja. Pravila zagotavljajo kvaliteto proizvoda, integriteto podatkov in tudi večjo stroškovno učinkovitost (GAMP 5, 2007). Zagotavljanje kakovosti je neprestan proces izboljšav in implementacij boljših, varnejših in učinkovitejših rešitev za skupen cilj: varen in kakovosten končni proizvod – zdravilo. Validacija je dokumentiran postopek preizkušanja in potrjevanja, da katerikoli material, proces, postopek, aktivnost, oprema ali mehanizem uporabljen v razvoju ali proizvodnji lahko dosega, dosega in bo dosegal predpisane rezultate. Ko gre za validacijo računalniškega sistema pa je to dokumentiran postopek, ki zagotavlja visoko stopnjo zanesljivosti, da bo določeni računalniški sistem deloval skladno s prej določenimi specifikacijami (Lek, 2013). Kvalifikacija je dokumentiran postopek preverjanja instrumenta, da bo izpolnjeval vse zahtevane standarde in funkcionalnosti predpisane s strani regulatornih organov, proizvajalca in stranke. Regulatorna (GxP) skladnost je zagotavljanje vseh obstoječih farmacevtskih in z njimi povezanih regulatornih zahtev. Dobra proizvodna praksa (ang. GMP – Good Manufacturing Practice) je zagotovilo za kakovostno delo, ki zagotavlja, da je zdravilo proizvedeno na kontroliran način skladen z zahtevami regulatornih standardov predpisanih s strani regulatornih agencij (FDA, 2015). Računalniški sistem je sestavljen (Slika 1) iz strojne opreme, programske opreme, instrumenta in mrežnih komponent skupaj z kontroliranimi funkcijami in procesnim delom (GAMP 5, 2007).



stran 4

Slika 1 Shema računalniškega sistema v operativnem okolju v farmacevtski industriji (PIC/S GUIDANCE, 2007)

Življenjski cikel računalniškega sistema je obdobje po implementaciji sistema v produkcijsko uporabo in do upokojitve sistema. Tekom svojega življenjskega cikla v produkcijske namene mora računalniški sistem slediti aktualnim regulatornim zahtevam in standardom kakovosti, da bi izpolnil zahteve tekom implementacije. Elektronski zapis je vsak zapis, ki nastane tekom procesa uporabe računalniškega sistema (rezultat analize, poročilo, zgodovina dogodkov, ipd.). Elektronski zapisi morajo biti podvrženi visoki ravni kontrole in morajo biti zaščiteni pred namernim in nenamernim spreminjanjem oziroma brisanjem. Elektronski podpis je vsak podpis vmesnega ali končnega rezultata ali poročila, ki nastane tekom procesa uporabe računalniškega sistema. Elektronski podpis mora biti podvržen visoki ravni kontrole in mora biti zaščiten pred namernim in nenamernim spreminjanjem oziroma brisanjem. Validacijska dokumentacija so vsi dokumenti nastali tekom procesa validacije računalniškega sistema s strani zaposlenih ali zunanjih partnerjev ali pooblaščenih dobaviteljev. Dokumentacija mora biti varno hranjena in vedno na voljo za pregled in analizo regulatornih organov ali internih kontrol. Odstop je vsak neplaniran ali nezaželen dogodek, težava oziroma incident, ki predstavlja neskladnost izvedenih procesov, postopkov in dobljenih rezultatov glede na interno predpisane postopke, specifikacije, količine, parametre in



stran 5

veljavno dobro proizvodnjo prakso, kjer je glede na predpisane kriterije zahtevana in potrebna formalna raziskava v aplikaciji za vodenje odstopov v podjetju (Lek d.d., 2015). Opozorilno pismo oblike 483 (ang. Warning letter form 483) je prepoznana večja kršitev oziroma kombinacija več kritičnih odstopov tipa 483 podanih s strani ameriške agencije FDA presojanemu podjetju.

2.2 REGULATORNI ORGANI V FARMACEVTSKI INDUSTRIJI Zaradi kompleksnosti industrije in pomembnosti zagotavljanja kvalitetne in nadzorovane proizvodnje zdravil za končne uporabnike sodi farmacevtska industrija med najbolj regulirane in zaprte industrije. Da bi zagotovili zadostno raven nadzora nad poslovanjem vse bolj cvetoče farmacevtske panoge so državne institucije ustanovile regulatorne agencije, ki so odgovorne za nadzor in iskanje nepravilnosti v farmacevtski in njej podobnih industrijah. Tako je država Amerika ustanovila agencijo za nadzor nad hrano in zdravili FDA (ang. Food and drug administration), Evropska skupnost je v ta namen ustanovila Evropsko agencijo za zdravila EMA (ang. European Medicines Agency), ki deluje v vseh državah Evropske unije kot posamezne ustanove vodene s strani posameznih članic. Enaki praksi sledi večina razvitih držav sveta, kot je Japonska, ki je ustanovila svojo Agencijo za farmacijo in medicinske naprave (ang. Pharmaceuticals and Medical Devices Agency). Nekatere manjše in manj razvite države sveta so se odločile, da bodo svoje javno zdravje zaupale uveljavljenim inšpekcijam razvitih zahodnih držav, zato se pri uporabi in skladnosti zdravil pogosto zanašajo na mnenje ameriške FDA ali evropske agencije EMA. V magistrski nalogi se osredotočimo na najbolj priznano agencijo ameriško FDA. FDA je po svojem statutu in misiji odgovorna za zaščito javnega zdravja z zagotavljanjem učinkovitih in varnih zdravil, hrane in medicinskih pripomočkov. Agencija je prav tako odgovorna za spodbujanje napredka javnega zdravstva z zagotavljanjem pomoči za nove inovacije, ki bodo naredile zdravila bolj učinkovita, varna in dostopnejša za širše množice (FDA, 2011). Glede na velikost in pomembnost ameriškega trga kot največjega na svetu, se farmacevtska podjetja najbolje pripravijo na obisk inšpektorjev FDA, ki slovijo kot najbolj zahtevni in izobraženi za področje delovanja farmacevtske industrije.

2.3 REGULATORNE ZAHTEVE ZA RAČUNALNIŠKE SISTEME Poplavi regulatornih zahtev za različna področja farmacevtske industrije različnih agencij so se z razvojem računalniške industrije pridružile tudi regulative za področje računalniških sistemov v farmacevtki industriji. Leta 1997 je ameriška agencija FDA pripravila prvo regulativo za področje računalniško podprtih sistemov v industrijah, ki jih pokriva. Pri tako imenovani regulativi 21 CFR PART 11 gre za prvo natančno opredelitev regulatornih zahtev neke agencije za delo z računalniškimi sistemi, ki so vse bolj prevzemali in nadomeščali delo človeka in naprav brez računalnika. Nekaj kasneje je primerljiv aneks za računalniške sisteme izdala tudi evropska agencija EMA.



stran 6

Regulativi se med seboj ne razlikujeta bistveno; obe natančno obravnavata regulatorne zahteve agencije za uporabo elektronskih zapisov in elektronskih podpisov tekom uporabe v procesu dela na računalniško podprtih sistemih v farmacevtskem podjetju. Četrto poglavje naloge prikaže implementacijo zahtev za računalniške sisteme obeh regulativ na praktičnih primerih v realni organizaciji. Kot je razvidno iz Tabele 1 obstaja med FDA in EMA-o nekaj manjših razlik oziroma pomanjkljivosti regulative (GAMP 5, 2007), ki pa niso bistvene za izvedbo validacije ob implementaciji in vzdrževanje računalniškega sistema tekom življenjskem cikla. Gre zgolj za različno interpretacijo podobnih regulativ. Primerjalna tabela namerno ni v celoti prevedena, da ohrani izvorna imena regulatornih zahtev za lažjo interpretacijo podobnosti in razlik med regulativama.

FDA 21 CFR Part 11 poglavje

FDA 21 CFR Part 11 naslov zahteve

EMA Annex 11 primerljiva referenca

Poglavje B—Elektronski zapisi 11.10 Kontrole za zaprte sisteme

11.10(a) Validation 4-Validation

11.10(b) Generate accurate and complete copies 8.1-Printouts

11.10(c)

Protection of records for accurate retrieval

17-Archiving, 12-Security

7-Data Storage

11.10(d)

Limiting system access to authorized individuals

7.1- secured and accessible

10- Change and Configuration

Management

12.1-Security, physical/logical

11.10(e)

Record of operator entries (audit trail)

7.1- secured and accessible

9-Audit Trails

10-Change and Configuration

Management

12.4- data

management/operators entries

14(c)-Electronic Signature

11.10(f) Operational system checks 5-Data, 6- Accuracy Checks

11.10(g)

Authority checks 7.1- secured and accessible

12.1-Security, physical/logical

11.10(h) Device checks 4.8-Validation

11.10(i) Personnel (who develop, users

and maintain systems)

2-Personnel

11.10(j) User accountability for actions

initiated under e-signatures

Ni pokrito



stran 7

11.10(k)

Documentation control

9-Audit Trails

4.2- change control and

deviations

10-Change and Configuration

Management

11- Periodic evaluation

11.30

Controls for open systems Principle (all systems)

5. Data

11.50 Signature manifestations 14-Electronic Signature

11.70 Signature/record linking 14(b)-Electronic Signature

Poglavje C—Elektronski podpisi

11.100 Splošne zahteve

11.100(a) Unique/not reused Ni pokrito

11.100(b) Verify identity Ni pokrito

11.100(c) Certify equivalent to handwritten 14(a) same as hand-written

11.200 Komponente in kontrole elektronskega podpisa

11.200(a) Not based on biometrics 12.1-Security, physical/logical

11.200(b) Based on biometrics 12.1-Security, physical/logical

11.300(a) Unique 12.1-Security, physical/logical

11.300(b)

Periodically checked 11. Periodic Evaluation

12.3-Security- record events

11.300(c) Procedures to deauthorize 12.3-Security, record events

11.300(d) Prevent unauthorized use 12.1-Security

11.300(e) Proper function 11-Periodic evaluation

Tabela 1 Navzkrižna primerjava 21 CFR PART 11 direktive ameriške agencije FDA z direktivo Annex 11 evropske agencije EMA po posameznih poglavjih glede na vsebino in razlike med poglavji (EduQuest, 2015).

Annex 11 vpliva samo na podjetja, ki izvažajo svoja zdravila v EU, tisti, ki bi želeli svoja zdravila prodajati tudi v Ameriki, pa se morajo natančno držati ameriške 21 CFR PART 11 direktive. Iz tabele je razvidno, da je želja obeh agencij imeti varne in validirane računalniške sisteme za proizvodnjo zdravil prisotnih na trgih, ki jih pokrivata. Obe regulativi skupaj tvorita robusten in uporaben vodič osebju v farmacevtskih podjetjih za zagotavljanje regulatorne skladnosti na računalniških sistemih.

3 PROCES ZAGOTAVLJANJA REGULATORNE SKLADNOSTI RAČUNALNIŠKEGA SISTEMA

FDA validacijo računalniškega sistema opredeli kot potrditev s pregledom in zagotovitev objektivnega dokaza (testa), da je specifikacija sistema skladna s potrebami uporabnikov in namenom uporabe ter da je zahteve programske opreme mogoče dosledno izpolniti in uporabljati tekom življenjskega cikla sistema (FDA, 2002). V praksi to pomeni, da so vse uporabniške zahteve, definirane na



stran 8

začetku validacije pravilne in kasneje celovito implementirane, dokumentirano testirane in sledljive. Z validacijo torej potrdimo, da bo računalniški sistem ustrezal predvidenemu namenu tekom svojega življenjskega cikla. Zagotavljanje skladnosti računalniškega sistema lahko uvrstimo v 3 faze življenjskega cikla (Slika 2). V prvi fazi sistem razvijemo oziroma kupimo in ga validiramo (poglavje 4.1), v drugi fazi ga operativno uporabljamo in vzdržujemo v validiranem stanju (poglavje 4.2), v tretji fazi pa sistem upokojimo (poglavje 4.2.8).

Slika 2 Življenjski cikel validiranega sistema (Lek, 2013)

Proces zagotavljanja skladnosti z regulatornimi zahtevami računalniškega sistema v farmacevtski industriji je dolgotrajen in kompleksen proces. Podjetja si zato pomagajo z različnimi smernicami različnih organizacij. Najbolj znana in splošno razširjena je smernica GAMP 5, ki farmacevtskim podjetjem pomaga pri izvedbi validacije in vzdrževanju validiranega stanja računalniških sistemov. Smernica GAMP (verzija 5) želi doseči, da je računalniški sistem ustrezen za redno uporabo in da zadošča aktualnim regulatornim zahtevam z izvedbo aktualne dobre industrijske prakse na učinkovit in ustrezen način (GAMP 5, 2007). Zaradi splošne razširjenosti, uporabnosti in skladnostmi z obstoječimi regulatornimi zahtevami bom smernice GAMP 5 pogosto navajal v svoji nalogi. Pri zahtevah regulatornih organov bom pogosto navedel priporočila, ki izhajajo iz



stran 9

GAMP 5 smernic. Interna dokumentacija podjetja v katerem delam prav tako izvira iz priporočil GAMP 5 in zahtev regulatornih organov trgov na katerih poslujemo. GAMP 5 za smernice oziroma vodnik opredeli pet ključnih konceptov, ki naj se jih uporabnik drži, da doseže zadostno raven skladnosti računalniških sistemov z regulatornimi zahtevami tekom življenjskega cikla (GAMP 5, 2007).

1. Ocena rizikov na podlagi znanosti Ocena rizikov naj temelji na popolnem poznavanju procesov, potencialnem vplivu na pacienta, kvaliteti produkta in integriteti podatkov. Z izbiro pravilnih kontrol lahko znižujemo rizike in jih imamo pod kontrolo. Ocena rizikov računalniškega sistema tirja uskladitev in prenos znanj med oddelki v podjetju. Najpogosteje oceno rizikov pripravijo skrbnik procesa v proizvodnji, skrbnik računalniškega sistema (IT podpora) in predstavnik oddelka upravljanje kakovosti. V primeru potrebe po dodatnih znanjih se lahko vključi tudi ostale eksperte.

2. Razumevanje procesa in produkta Razumevanje procesa in produkta, ki ga podpiramo, je ključno za določitev uporabniških zahtev (poglavje 4.1.3). Razumevanje je osnova za sprejemanje odločitev na znanstveni podlagi in za zmožnost ocene rizika za posamezen sistem, ki ga potrebujemo v svojih procesih. Ocena rizikov (poglavje 4.1.2) naj ima fokus na kvaliteto proizvedenega izdelka in integriteto podatkov. Z razumevanjem procesa in produkta in pravilnim pristopom k oceni rizikov dosežemo, da validiramo samo funkcionalnosti računalniškega sistema, ki so del našega proizvodnega procesa in ne celotnega sistema.

3. Življenjski cikel znotraj sistema upravljanja kakovosti Sistem upravljanja kakovosti znotraj podjetja mora zagotoviti stalne izboljšave (poglavje 4.2.7) in razvoj na podlagi podatkov pridobljenih tekom rednih periodičnih pregledov (poglavje 4.2.4), in vzrokov za napake, ugotovljene tekom reševanja odstopov (poglavje 4.3).

4. Prilagodljivost aktivnosti življenjskega cikla sistema Aktivnosti življenjskega cikla naj bodo prilagojene glede na:

vpliv na pacientovo zdravje, kvaliteto produkta in integriteto podatkov (na podlagi analize tveganj),

kompleksnost sistema (kategorizacija sistemov – poglavje 4.1.2),

izid ocene dobavitelja (zmožnosti dobavitelja, da nam pomaga) in

predhodno klasifikacijo sistema (GAMP 5 klasifikacija – poglavje 4.1.2)

5. Učinki vpletenosti dobavitelja Maksimirajmo vpletenost dobavitelja v vzdrževanje življenjskega cikla sistema, da pridobimo napredna znanja, izkušnje in potrebno dokumentacijo. Za uspešno sodelovanje z dobavitelji je ključen dober nadzor, ki ga zagotovimo z presojami dobaviteljev.



stran 10

3.1 VALIDACIJA RAČUNALNIŠKEGA SISTEMA Računalniški sistem je validiran (Lek d.d., 2013) ko:

je validirana aplikacija,

je kvalificirana infrastruktura,

je kvalificirana uporabljena oprema in orodje,

so vzpostavljeni postopki za delo in administracijo,

so ljudje primerno usposobljeni in

je vzpostavljen in se izvaja nadzor sprememb in konfiguracije sistema. Ko računalniški sistem razvijemo ali kupimo ga moramo pred predajo v produkcijsko okolje ustrezno validirati. Validirano stanje dosežemo z naborom različnih ukrepov in aktivnosti, ki jih ustrezno dokumentiramo. Da se lahko lotimo validacije mora imeti podjetje vzpostavljen sistem kakovosti, skladen z regulatornimi zahtevami, ki skozi splošne postopke, navodila za delo in ostalo dokumentacijo narekuje način pristopa k validaciji računalniškega sistema. 3.1.1 DELEŽNIKI IN ODGOVORNOSTI Pred začetkom validacije računalniškega sistema moramo ustrezno razdeliti vloge in odgovornosti zaposlenih. Regulatorni organi predpisujejo, da moramo vzpostaviti tesno sodelovanje med vsem relavantnim osebjem v organizaciji kot so lastnik procesa, lastnik sistema, kvalificirane osebe za zagotavljanje kakovosti in IT osebje. Vsi našteti morajo imeti ustrezna znanja, urejene dostope glede na potrebno stopnjo in definirane odgovornosti, ki se jih morajo držati glede na dodeljeno nalogo (Annex 11, 2011). Osebje, vključeno v validacijo računalniškega sistema, lahko razdelimo na (povzeto po GAMP 5, 2007):

Lastnik procesa (ang. Process owner) je odgovoren za izvedbo in nadzor nad procesom znotraj podjetja. Ta oseba je najpogosteje ključni raziskovalec ali vodja skupine, ki ima največ procesnih izkušenj. Lastnik procesa je odgovoren, da so računalniški sistem in operacije, ki se izvajajo na njem, skladni z zahtevami uporabnikov sistema, splošnimi postopki, ki opredeljujejo proces in regulatornimi zahtevami. Gre za neke vrste povezovalni člen, ki zagotovi, da so definirani procesi in računalniški sistem skladni z regulativo in zagotovijo optimalno izvajanje procesnih nalog definiranih v splošnih postopkih in navodilih za delo procesa.

Lastnik sistema (ang. System owner) je odgovoren, da zagotovi dosegljivost, nadzor in vzdrževanje sistema. Prav tako mora poskrbeti, da so podatki, ki se generirajo na sistemu, varni pred izgubo ali manipulacijo. Ta oseba je najpogosteje vodja laboratorija ali oddelka kateremu pripada računalniški sistem. Gre za osebo, ki mora zagotoviti vse pogoje, da je sistem ustrezno validiran in, da ga uporabniki lahko nemoteno uporabljajo za svoje dnevne procesne naloge.

Oseba za upravljanje kakovosti (ang. Quality Assurance), v nadaljevanju naloge UK, je oseba, ki je odgovorna za usmerjanje in kontrolo nad validacijo računalniškega sistema. Gre za osebo, ki zagotovi, da validacija in kasnejše validirano stanje ustreza regulatornim zahtevam. UK sprosti sistem v redno uporabo in ga lahko tudi kadarkoli vzame iz uporabe v



stran 11

primeru odstopov ali katerih drugih nepredvidenih težav ali pomanjkljivosti na sistemu.

Ekspert za validacije (ang. Validation manager) je oseba, ki je odgovorna za samo izvedbo validacije in vzdrževanje sistema v validiranem stanju. Ponavadi gre za osebo, ki je IT ekspert in ni nujno neposredno vključena v proces, vendar ima ustrezna znanja, da s pomočjo lastnika procesa in lastnika sistema ustrezno validira računalniški sistem. Gre za neke vrste vezni člen med uporabniki sistema (proces) in UK (regulatorne zahteve). Ekspert za validacije je funkcija, ki je zgolj priporočena, za lažje in kvalitetnejše opravljeno validacijo in vzdrževanje validiranega stanja. V izrednih primerih jo lahko upravlja tudi lastniku procesa.

3.1.2 KATEGORIZACIJA IN KROVNA OCENA RIZIKOV Da bi lahko sistem ustrezno validirali ga moramo ustrezno kategorizirati in oceniti rizike, ki lahko vplivajo na validirano stanje sistema. Najpogosteje uporabljena kategorizacija je kategorizacija po GAMP. Zadnja izdaja GAMP 5 (GAMP 5, 2007) razdeli računalniške sisteme v štiri kategorije:

Kategorija Razlaga Primeri

Kategorija 1: Infrastrukturni program

Krovni programi, ki se uporabljajo za opravljanje računalniškega okolja

Operacijski sistem, programska oprema za baze podatkov, orodja za nadzor nad operacijskimi sistemi, tabele in orodja za programiranje

Kategorija 3: Nekonfigurabilni

Parametri za zagon se lahko vnesejo in zaženejo vendar program ne more biti konfiguriran tako, da bi ga prilagodili poslovnemu procesu.

Osnovna programska oprema na instrumentih kot so ph meter, tehtnica, ipd.

Kategorija 4: Konfigurabilni

Programska oprema, pogosto zelo kompleksna, ki se lahko konfigurira s strani uporabnika, da zadosti specifičnim zahtevam uporabnika glede na poslovni proces. Programska koda se ne spreminja (izdelki s police).

Nadzorno krmilni sistemi in sistemi za nadzor nad laboratorijskimi in proizvodnimi napravami. Torej programska oprema za bolj zahtevne operacije.

Kategorija 5: Po meri Programska oprema razvita in sprogramirana po meri, da ustreza poslovnemu procesu.

Interno ali eksterno razvite aplikacije za laboratorije, proizvodnjo ali proces. Ponavadi specifične aplikacije, ki jih ne moremo kupiti s police.

Tabela 2 Kategorizacija računalniških sistemov po GAMP 5 (GAMP 5, 2007)



stran 12

Regulativa za vsako izmed kategorij predvideva nabor potrebne dokumentacije in vpeljanih kontrol oziroma postopkov, da zadostimo validiranemu stanju računalniškega sistema. V nalogi bo poudarek predvsem na kategoriji 4, ki opredeljuje konfigurabilne sisteme kupljene s police. V današnjih časih so le redke aplikacije razvite s strani dobavitelja in še redkeje interno. Sam nabor dokumentacije in kontrol se med kategorijo 4 in 5 ne razlikuje bistveno. Slika 3 prikazuje validacijo računalniškega sistema kategorije 4 čez najpogosteje uporabljen »V« model validacije. Programsko opremo kupljeno s police najprej načrtujemo skozi specifikacijsko dokumentacijo (leva stran), nato v podjetje dobimo konfigurabilen produkt, ki ga namestimo in konfiguriramo, da ustreza našim procesom. Nato izvedemo verifikacijo s katero dokumentirano potrdimo, da so zahteve s faze načrtovanja uresničene s strani dobavitelja in internih nastavitev računalniškega sistema.

Slika 3 Validacija računalniškega sistema kategorije 4 po "V" modelu (GAMP 5, 2007)

Ko računalniški sistem ustrezno kategoriziramo, moramo oceniti rizike, ki lahko vplivajo na računalniški sistem v fazi implementacije (validacija) in operativni uporabi (vzdrževanje validiranega stanja). V kolikor z oceno rizikov ne prepoznamo ključnih delov procesa, se lahko zgodi, da je napor, vložen v validacijo napačno razporejen glede na posamezne sisteme. Visoki riziki tako niso ustrezno obvladovani, nizkim rizikom pa po nepotrebnem posvečamo preveč svojega časa. Cilj ocene rizikov je prepoznati ključne faze procesa in jih validirati, procese, ki pa jih ne bomo uporabljali pa ne validiramo in tako prihranimo čas in resurse. Zato naj bo ocena rizika računalniškega sistema ključen korak pred začetkom validacijskih aktivnosti na sistemu.



stran 13

Termin ocena rizika temelji na identificiranih tveganjih, analiziranih tveganjih in ovrednotenih tveganjih. Pri identifikaciji rizikov se moramo vprašati kaj so tveganja in kaj gre lahko narobe. Z analizo rizikov iščemo verjetnost, da gre nekaj lahko narobe in se vprašamo po morebitnih posledicah v kolikor bo do njih prišlo. Pri oceni rizikov med seboj primerjamo dobljene kriterije rizikov in jim dodelimo verjetnost, da se zgodijo ter pomembnost (vpliv) v kolikor do njih pride. Za konec se moramo odločiti ali bomo rizike zgolj sprejeli in se jih zavedali ali pa jih bomo poizkušali tudi omejiti. Da jih omejimo moramo sprejeti določene aktivnosti, ki bodo pripeljale do znižane možnosti za pojav rizikov (ECA, 2012). Za analizo rizikov poznamo več stopenj resnosti. Najpogosteje je uporabljena štiristopenjska lestvica: 4 - nesprejemljivo, katastrofalno, 3 - kritično, 2 - sprejemljivo s pregledom in 1 - sprejemljivo. Verjetnost pojava opredelimo s tremi stopnjami: 3 – zelo verjetno, 2 – verjetno, 1 – manj verjetno (ECA, 2012). Rezultat opisane ocene rizikov za računalniški sistem je krovna ocena rizika (ang. High Level Risk Assesment). To je prvi dokument validacijske dokumentacije, ki ga zahtevajo regulatorni organi. V dokumentu klasificiramo sistem (GAMP 5 klasifikacija), definiramo ali bo sistem uporabljen v namene GxP (podpora proizvodnji zdravil), napovemo ali bo sistem uporabljal elektronske zapise in podpise, ocenimo pomembnost sistema in posledične krovne rizike ter ocenimo rizike povezane s pravnimi, finančnimi in ostalimi podpornimi funkcijami. Za pripravo dokumenta je odgovoren lastnik procesa in lastnik sistema. Dokument se potrdi lastnika sistema in enota UK. 3.1.3 DOKUMENT »UPORABNIŠKE ZAHTEVE« Dokument vsebuje opredelitev kaj in zakaj uporabniki potrebujejo oziroma zahtevajo od sistema. Uporabniške zahteve jasno in natančno definirajo kaj želimo, da reguliran sistem dela. S tega razloga gre za najpomembnejši korak pri implementaciji računalniškega sistema, kjer uporabnik poda zahteve za svoj sistem. Zahteve morajo biti povezane in usklajene s poslovnim procesom, ki ga bo računalniški sistem podpiral. Obseg in natančnost zahtev mora biti sorazmerna s kompleksnostjo in riziki, ki jih prinaša obravnavan sistem. Dokument mora biti dovolj natančen, da lahko podpira kasnejšo funkcijsko oceno rizikov in konfiguracijsko specifikacijo in testiranja. Osredotočiti naj se na specifične GxP zahteve, ki so nujne za obvladovanje procesa. Tako dosežemo optimalen obseg validacijske dokumentacije in validiramo samo tisto kar zares potrebujemo za redno delo na računalniškem sistemu (ECA, 2012). Uporabniške zahteve naj bodo (GAMP 5, 2007):

Specific (opredeljene dovolj natančno za testiranje in preverjanje)

Measurable (merljive)

Achivable (uresničljive)

Realistic (realne glede na situacijo in sistem)

Testable (preverljive)



stran 14

Vsebina dokumenta (povzeto po GAMP 5, 2007):

Uvod - ozadje obravnavanega sistema, cilj delovanja, obseg dokumenta.

Operativne zahteve - opis operativnega delovanja sistema z operativnim diagramom. Opis procesa, ki ga bo sistem opravljal tekom uporabe v laboratoriju, proizvodnji, ipd. Operativne zahteve naj bodo jasno povezane s procesnimi koraki procesa, ki ga podpira sistem, in naj imajo jasno oceno pomembnosti posamezne uporabniške zahteve.

Ključni tehnološki parametri – parametri, ki jih uporabnik sistema potrebuje za nemoteno delovanje sistema. Navajamo samo parametre, ki jih potrebujemo tekom proizvodnega procesa. V luči optimizacije parametre, ki niso del našega proizvodnega procesa ne navajamo in jih po potrebi zahtevamo kasneje skozi postopek predloga za spremembo.

Zahteve za podporo elektronskim zapisom in podpisom - regulatorne zahteve specifikacije sistema, da bi lahko računalniški sistem uporabljali v elektronski obliki brez uporabe papirnih izpisov. Sem sodijo zahteve za uporabniške skupine, omejitve na sistemu z vidika varnosti, varnostno kopiranje zapisov, ipd.

Omejitve sistema - omejitve na delovanje in specifikacije sistema, skladnost sistema z ostalimi procesi, potrebna znanja uporabnikov, pričakovan čas delovanja, podpora dobaviteljev in serviserjev, ipd.

Zahteve življenjskega cikla – morebitne specifične zahteve, ki imajo vpliv na dobavitelja, razvoj in vzdrževanje sistema.

Slovar izrazov – razlaga manj znanih izrazov, ki se pojavijo v dokumentu.

Odobritev dokumenta – imensko definiranje avtorjev in odobriteljev dokumenta. Med podpisnike moramo vključiti vsaj lastnika procesa kateremu pripada računalniški sistem, lastnika sistema (vodja oddelka) in predstavnika oddelka UK.

Vsaka zahteva naj bo opremljena s prioriteto kritičnosti in rizika. Uporabniške zahteve naj pišejo osebe znotraj organizacije, ki dobro poznajo procese in potrebe po računalniškem sistemu. Za dokument je odgovoren lastnik procesa in ekspert za validacije. Procesni del je povsem v domeni lastnika sistema, nakar operativno delovanje programske opreme in ostalih komponent ponavadi pokriva ekspert za validacije s pomočjo ostalih ekspertov v organizacij (glede na področje). Dokument potrdi lastnik sistema in enota UK. 3.1.4 PLANIRANJE VALIDACIJE Po zaključeni oceni rizika in opredeljenih uporabniških zahtevah lahko začnemo s planiranjem validacijskih aktivnosti. Krovnemu dokumentu, ki opredeljuje validacijske aktivnosti rečemo Glavni validacijski načrt (ang. Validation master plan), ki obsega načrt validacij za prihodnje obdobje, najpogosteje leto. Dokument, ki opredeli aktivnosti za točno določeno validacijsko aktivnost znotraj posameznega oddelka imenujemo Validacijski načrt ali Validacijski protokol (ang. Validation plan / protocol). Glavni validacijski načrt je najpogosteje specifičen za posamezna področja organizacij (za razvoj, za proizvodnjo, ipd.) in definira validacijski cikel za



stran 15

prihodnje obdobje. Opredeli vloge in odgovornosti, kdo je odgovoren za izvedbo posamezne validacijske aktivnosti, definira morebitne spremembe, ki se bodo zgodile na obstoječih sistemih, definira izvedbo periodičnih pregledov in na splošno planira validacije novih in ohranja validirano stanje obstoječih sistemov v organizaciji (ECA, 2012). Odgovornost za pripravo glavnega validacijskega načrta je na višjem nivoju upravljanja, ki ponavadi pooblasti sodelavce v UK, da pripravijo ta dokument. Oddelek UK je odgovoren, da je predlagani pristop validacij skladen z regulativo in da obsega vse računalniške sisteme, ki morajo biti validirani, da bo podjetje skladno z zahtevami regulatornih organov. Dokument potrdi direktor enote in vodja oddelka, na katerega se dokument nanaša. Validacijski plan je dokument, ki ga pripravimo enkrat za posamezen projekt validacije (za točno določen računalniški sistem oziroma sklop enakih sistemov). Definira odgovornosti za izvedbo validacije s konkretnimi imeni za posamezen dokument oziroma nalogo in časovnicami za izvedbo. Opiše koncept validacije in validacijsko strategijo. Definira nabor dokumentacije s konkretnimi nazivi dokumentov in referencami. V dokumentu navedemo (GAMP 5, 2007):

- že pripravljene dokumente (Krovna ocena rizika in Uporabniške zahteve), - validacijsko strategijo, ki opiše življenjski cikel sistema, posamezne faze

validacije po korakih z naborom kriterijev sprejemljivosti, - vso dokumentacijo, ki jo planiramo v času validacije vključno z referencami

(testi, specifikacije, navodila za delo, splošni postopki), - splošne postopke po katerih bomo sistem validirali in ga nato vzdrževali v

validiranem stanju, - časovnice za izvedbo, - nadzor nad spremembami in - podporne procese, kot so izobraževanja, hramba dokumentacij in

vzdrževanje validiranega stanja tekom življenjskega cikla. Za pripravo dokumenta sta odgovorna lastnik procesa in ekpert za validacije (vodja projekta validacije). Validacijski plan potrdi lastnik sistema in UK. 3.1.5 SPECIFIKACIJE Poznamo naslednje vrste specifikacij:

funkcijska specifikacija,

specifikacija strojne opreme,

specifikacije dizajna in

konfiguracijska specifikacija. Funkcijsko specifikacijo pripravi dobavitelj računalniškega sistema, s katerimi odgovori na posredovane uporabniške zahteve. Dokument definira kaj mora sistem delati. Funkcionalnost se v kasnejši fazi validacije preveri s kvalifikacijo delovanja (OQ, ang. operational qualification). Dokument prepreči morebitne dvoumnosti, podvajanja in nasprotna si mnenja med dobaviteljem in uporabnikom (ECA, 2012).



stran 16

Specifikacije dizajna pripravi dobavitelj. Gre za natančno tehnično razširitev funkcijske specifikacije. Vprašamo se kako bo sistem dosegel posamezno specificirano funkcijo? Dokument lahko vsebuje več različnih specifikacij kot so npr. specifikacija strojne opreme in specifikacija programske opreme (ECA, 2012). Konfiguracijsko dokumentacijo pripravi ekspert za validacijo v sodelovanju z lastnikom procesa in dobaviteljem. V dokument navedemo konfiguracijo sistema, ki jo nato preverimo s kvalifikacijo namestitve sistema (IQ, ang. installation qualification) in z OQ testi. Navajamo verzijo programske opreme, instrument, nastavljive nastavitve programske opreme, nastavitve vmesnikov in povezave med njimi, mesta shranjevanja elektronskih zapisov in varnostne nastavitve (Lek, 2011). 3.1.6 TESTIRANJE RAČUNALNIŠKIH SISTEMOV Ko definiramo uporabniške zahteve, rizike, plan in konfiguracije računalniškega sistema lahko začnemo s testiranji. Testiranje programske opreme naj bo skladno z mednarodnim standardom ISO 29119. Testiranje programske opreme omogoča da (GAMP 5, 2007):

identificiramo napake, da lahko le-te popravimo in odstranimo pred operativno uporabo sistema,

preprečimo napake, ki bi lahko vplivale na zdravje pacienta, kvaliteto produkta ali integriteto podatkov,

imamo dokumentiran dokaz, da sistem deluje kot je bilo načrtovano,

z gotovostjo trdimo, da je sistem primeren za uporabo in

potrdimo zagotavljanje ključnih regulatornih zahtev. Testiranje v osnovi delimo na testne plane, kjer navedemo testne primere, in poročilo testiranja, kjer navedemo rezultate testiranja in morebitne posebnosti ali odstopanja od testnega plana. Testiranja lahko delimo tudi na »white box« (načelo bele skrinjice) in »black box« (načelo črne skrinjice). Pri »white box« se osredotočimo predvsem na kodo in gradnjo programske opreme, pri »black box« testiranju pa se osredotočimo na testiranje funkcij računalniškega sistema. V farmacevtski industriji za testiranje »white box« v večini primerov poskrbi dobavitelj, glavnina testiranja »black box« pa se izvede v organizaciji, v realnem okolju na realnih procesih. Za pripravo testnih planov sta odgovorna lastnik procesa in ekspert za validacije, ki skupaj pripravita testne plane. Testni plan mora natančno opredeliti posamezne teste in definirati pričakovane rezultate. Za izvedbo testiranja se ponavadi imenuje eksperta za validacije, lahko pa je to tudi lastnik procesa oziroma končni uporabnik računalniškega sistema. Pri izvedbi testov moramo navesti rezultat posameznega testa (uspešno, neuspešno, delno uspešno z opažanji), komentar v kolikor je potreben in mesto za datum in podpis izvajalca testa. Potrjevalec dokumenta nikoli ne sme biti oseba, ki je izvajala testiranje. Tako testni plan in poročilo mora potrditi tudi predstavnik UK, ki mora oceniti ali sta plan in izvedba skladna z regulatornimi zahtevami in ali sta dovolj natančna in obsežna, da pokrijeta vse uporabniške zahteve in konfiguracije sistema.



stran 17

Dobra praksa testiranj v farmacevtski industriji narekuje (ECA, 2012):

testni plan naj bo definiran in potrjen,

vsi dokumenti naj bodo podvrženi kontroli verzij,

vsi predpogoji za testiranje morajo biti izpolnjeni in popisani,

izvajalci testov in potrjevalci morajo biti ustrezno usposobljeni za naloge, ki jih izvajajo,

treningi morajo biti dokumentirani,

izvedba testom mora slediti potrjenim testnim planom,

vsi rezultati testov naj bodo dokumentirani, naj si bodo ustrezni ali neustrezni,

za vsak izveden test mora obstajati dokumentiran dokaz,

obstajati morajo povezave med testom, izvedbo in dokumentiranim dokazom in

izvedeni testi in dokazi morajo biti ustrezno podpisani in datirani. Vsa odstopanja od predvidenih rezultatov morajo biti dokumentirana in sledljiva. Vsa odstopanja od pričakovanj morajo biti do konca validacije ustrezno preverjena, ocenjena in razložena, izvedeni morajo biti tudi korektivni ukrepi. Regulatorni organi za testiranja največkrat opažajo, da (ECA, 2012):

kritične faze procesa niso dovolj detajlno testirane,

manjkajo kriteriji, kdaj je test dovolj dober oziroma natančen,

nepravilno pristopamo k testiranju – neusposobljenost, neizkušeni testerji,

slabo dokumentiramo dokaze o testiranju in

neustrezno vodimo odstopanja in spremembe med procesom testiranja. 3.1.7 VALIDACIJSKO POROČILO Planirane aktivnosti validacijskega plana se odražajo v vsebini validacijskega poročila. Dokument povzema vse aktivnosti posameznih faz validacije, vsa odstopanja od validacijskega plana, vse spremembe ali neobičajne akcije in za konec jasno sporočilo – stavek, da je računalniški sistem ustrezen in popolnoma funkcionalen za produkcijsko uporabo (GAMP 5, 2007). Končno validacijsko poročilo (ECA, 2012):

povzema celoten validacijski proces,

potrjuje skladnost s planom,

povzema rezultate testiranj,

potrjuje kontrolo nad odstopanji in spremembami,

do kazuje, da je sistem primeren za GMP uporabo (produkcijo),

predstavlja glavni dokument za komunikacijo z inšpektorjem in

utrjuje zaupanje in samozavest, da je podjetje skladno z regulatornimi zahtevami.

Za pripravo validacijskega poročila je odgovoren ekspert za validacije, ki vodi in usmerja aktivnosti validacije, od dokumenta krovne ocene rizika do validacijskega poročila. Lastnik procesa in lastnik sistema, ki ga validiramo, potrdita dokument,



stran 18

končno potrditev pa ima oseba iz UK. Slednja dovoli, da se sistem sprosti za uporabo v proizvodnji. Validacijsko poročilo je ključen dokument validacijske dokumentacije in opravičuje uporabo sistema v proizvodnji. Zato naj bo jasno, kratko, jedrnato, popolno, natančno, prepričljivo in pozitivno.

3.2 VZDRŽEVANJE VALIDIRANEGA STANJA Sistem v uporabi se s časom stara, programska oprema je vse bolj zastarela, dogajajo se nadgradnje in popravki, prihajajo novi uporabniki, spreminja se lastništvo sistema, okolje okrog sistema se spreminja in regulatorne zahteve so vse bolj zahtevne. Vse to zelo vpliva na validirano stanje računalniškega sistema. Poslabšano stanje računalniških sistemov se kaže kot (ECA, 2013):

izgubljanje znanja zaradi fluktuacije zaposlenih,

posledično manjša učinkovitost,

dolgotrajnejše reševanje težav,

večanje stroškov vzdrževanja sistemov,

zaradi sprememb na procesih uporabnik s časom uporablja samo še del sistema,

uporabnik »izumi« bližnjice pri uporabi sistema,

dokumentacija ni več ustrezna ali skladna z regulatornimi zahtevami in

splošni postopki so pomanjkljivi, saj se procesi spreminjajo in prilagajajo novim zahtevam.

Zato je neizogibno dejstvo, da je potrebno vzpostaviti ustrezne mehanizme vzdrževanja validiranega stanja računalniških sistemov. S časom se namreč skladnost sistemov zgublja v novih, spremenjenih procesih in načinih dela v organizaciji. Da bi se izognili zgoraj naštetim pojavom poslabšanja stanja na računalniških sistemih mora organizacija poskrbeti za (ECA, 2013):

trenutno veljaven inventar programske opreme (ang. Computerized System Inventory),

glavni validacijski načrt (ang. Validation Master Plan),

veljavno validacijsko dokumentacijo (ang. up to date documentation),

nadzor nad spremembami (ang. Change Management),

periodične preglede (ang.Periodic Reviews),

vzpostavljen servis IT podpore in monitoring procesov,

nadzor nad incidenti (ang. Incident management),

varnostno kopiranje in restavriranje podatkov (ang. Backup and Recovery),

plan v primeru neplaniranih težav (ang. Disaster Recovery Plan) in

ustrezen čas hranjenja zapisov in arhiviranje zapisov (Records Retention Periode and Archiving).

Če organizacija ne poskrbi za ustrezno validirano stanje skozi življenjski cikel sistema, tvega integriteto produkta ali varnost pacienta. Prav tako izgubi zaupanje regulatornih organov in podjetja nasploh. To lahko pripelje do prepovedi prodaje izdelkov in posledično slabših poslovnih rezultatov.



stran 19

Lastnik procesa je odgovoren, da sistem in vsa operativa okrog njega v dobri formi in primerna za uporabo glede na splošne postopke v organizaciji. Lastnik sistema (vodja) je odgovoren, da priskrbi osebje za izvajanje nalog in da je sistem vzdrževan in podprt za vse procese glede na splošne postopke v organizaciji. UK mora biti neodvisna vloga, ki potrdi vse splošne postopke, procedure, kriterije, da je sistem ustrezno validiran. Fokus te osebe mora biti zagotavljanje regulatorne skladnosti sistema skozi celoten življenjski cikel. Ekspert za validacije je odgovoren za izvedbo validacijskih aktivnost in aktivnosti življenjskega cikla sistema glede na potrjene plane 3.2.1 ZAGOTAVLJANJE NEMOTENEGA DELOVANJA SISTEMA Spremljanje zmogljivosti (ang. Performance monitoring) je del preventivnega vzdrževanja računalniških sistemov, s katerim pridobimo podatke o delovanju sistema. Ti podatki so uporabni za kasnejšo diagnostiko problemov. Skrbnikom sistema nakazujejo trende, ki bi lahko privedli do težav z delovanjem sistema. Kažejo tudi, da je potrebno nekaj na sistemu spremeniti / obnoviti (nadzor nad spremembami) (ECA, 2013). Na računalniških sistemih spremljamo:

programsko opremo in instrumente (napake, odzivne čase, napake instrumenta, napake povezave z instrumentom),

računalniško omrežje (dosegljivost mrežnih komponent, strežnikov, varnost omrežja, odzivnost),

strojno opremo računalnikov / strežnikov (procesor, zasedenost diskov, RAM) in

tehnološki monitoring (alarmi na nadzornih sistemih, vlažnost prostorov, omrežje tehnologij).

Lastnik sistema je običajno z IT podporo in zunanjimi izvajalci odgovoren za izvajanje nadzora nad sistemom. Lastnik sistema mora poskrbeti, da se zagotovi ustrezen nadzor in, da je delo ustrezno definirano (pogodba). IT podpora je odgovorna za izvajanje nadzora in izdajo poročil glede na dogovor z lastnikom sistema. Lastnik procesa mora glede na poročila in ugotovitve ustrezno ukrepati in predlagati morebitne spremembe. UK je odgovoren za ustreznost pogodb z zunanjimi izvajalci v kolikor oni izvajajo nadzor. Prav tako potrdijo morebitne predlagane spremembe na sistemih. Glede na plan nadzora definiramo procese in aktivnosti, ki jih bomo izvajali v primeru odstopanj od pričakovanih mej. Določimo tudi aktivnosti, ki jih bomo izvajali sami oziroma zunanji pooblaščeni serviserji. Nato periodično pripravimo poročila in se na podlagi rezultatov in kriterijev odločimo za morebitne spremembe na sistemih (ECA, 2013). Spremljanje računalniškega sistema je srce dobre sistemske podpore v organizaciji. Je poceni in učinkovit sistem nadzora nad računalniškimi sistemi, s katerim težavo oziroma odstopanje odpravimo še preden ta vpliva na proces izdelave zdravila in v najslabšem primeru tudi na zdravje pacienta.



stran 20

3.2.2 UPRAVLJANJE Z INCIDENTI Da bi računalniški sistemi v organizaciji nemoteno delovali je potrebno vzdrževanje skozi podporo različnih strokovnjakov (IT podpora, zunanji izvajalci – eksperti). Administracija računalniškega sistema zagotavlja proces preverjanja in odpravljanja težav na sistemu, ki prepreči nedosegljivost ali nepravilno delovanje sistema (ECA, 2013). V kolikor je administracija sistema neustrezna oziroma prihaja do nepredvidenih dogodkov, govorimo o incidentu na računalniškem sistemu. Incident je vsak neplaniran dogodek, ki uporabnikom onemogoča izvajanje procesa na računalniškem sistemu. Ko se incident pojavi mora biti eskaliran s strani uporabnika odgovorni osebi za upravljanje z incidenti. V večini primerov gre za IT skrbnike posameznih računalniških sistemov, ki incident zabeležijo v vzpostavljen sistem za upravljanje z incidenti – programska oprema, kamor organizacija vpisuje vse incidente. Pri nastalem incidentu je potrebno ob uporabnikovi prijavi zabeležiti naslednje informacije (Slika 4, koraki 1.02 – 1.04) (ECA, 2013):

unikatna ID oznaka,

datum in ura,

ime in priimek osebe, ki je sporočila incident,

ime in priimek osebe, ki rešuje incident,

računalniški sistem, ki se ga tiče incident,

opis težave, napake in

prioriteta reševanja incidenta in priporočljiv odzivni čas za rešitev. Ko je incident zabeležen, je potrebno poiskati razlog za nastanek in predvsem rešitev, da bi bil računalniški sistem v najkrajšem možnem času sproščen nazaj v uporabo. Reševanje incidenta in iskanje rešitve je lahko v domeni skrbnika računalniškega sistema, v kolikor pa gre za bolj kompleksen incident pa se zadevo eskalira na širšo množico strokovnjakov. V teh primerih lahko pomagajo različne službe znotraj podjetja ali pa zunanji dobavitelji s katerimi je sklenjen sporazum za nudenje podpore v primeru incidenta (Slika 4, korak 1.01). V primeru, da je za rešitev incidenta potrebno opraviti spremembo na računalniškem sistemu, moramo le to voditi preko predloga za spremembo (glej poglavje 4.2.7). Ko najdemo rešitev in incident uspešno zaključimo, moramo zabeležiti (Slika 4, korak 1.09) (ECA, 2013):

vpliv incidenta na produkt in integriteto podatkov,

razlog za pojav incidenta,

razlaga rešitve incidenta,

ocena uspešnosti rešitve / zaključka incidenta in

zaključno obvestilo uporabniku računalniškega sistema o rešitvi. Pogosto je za pomembnejše incidente in ponavljajoče se incidente na zahtevo uporabnika računalniškega sistema ali UK in s potrditvijo UK potrebno izvesti korektivne oziroma preventivne akcije (ang. CAPA – Corrective & Preventive Action). CAPA je proces za raziskovanje, razumevanje in popravljanje diskrepanc na računalniških sistemih, ko želimo preprečiti ponavljajoče se incidente (GAMP 5, 2007).



stran 21

Ko se določi, da je potrebno izvesti CAPA ukrepe se mora le to zavesti v zaznamek korektivnega ukrepa. V sistem za upravljanje z odstopi v podjetju zabeležimo (ECA, 2013):

unikatna ID oznaka,

sistem kateremu pripada CAPA,

kdo je CAPA vnesel v sistem in kdaj,

opis težave,

referenca na analizo izvornega problema,

predlog rešitve problema,

ime osebe, ki bo izvedla popravek,

potrditev CAPA predloga s strani UK,

referenca na morebiten odstop in incident,

razlago kaj smo spremenili in kdaj in

zaključen podpis izvajalca in UK po izvedbi. Odgovornost za izvajanje procesa beleženja incidentov in zahteve po CAPA procesu je na lastniku procesa in lastniku sistema. UK mora biti obveščen o ponavljajočih se incidentih s strani IT podpore ali uporabnika sistema. Na zahtevo lastnika procesa ali UK se s potrditvijo UK izvede CAPA proces za odpravljanje ponavljajočih se napak na sistemu. IT podpora ali strokovnjaki na področju posameznega sistema so odgovorni za reševanje incidentov ter spremembe in popravke v sklopu CAPA procesa.



stran 22

Slika 4 Shema procesa dokumentiranja in reševanja incidenta na računalniškem sistemu (Lek, 2013)

3.2.3 VARNOST, DOSTOPNOST IN USPOSABLJANJE UPORABNIKOV Računalniški sistem v farmacevtski industriji mora biti zaščiten pred namerno ali nenamerno izgubo podatkov, nepooblaščenimi spremembami in poškodbami. Varnost računalniškega sistema je preventiva pred uhajanjem ali izgubo podatkov, ki jo zagotovimo z (ECA, 2013):

zaupnostjo – informacije morajo biti dostopne samo tistim, ki so za to pooblaščeni,

integriteto podatkov – varnost celovitosti in natančnosti informacij in procesov in



stran 23

dosegljivostjo informacij – vsi avtorizirani uporabniki imajo dostop do informacij, ko jih potrebujejo.

Da bi zagotovili ustreznost informacij in integriteto podatkov mora podjetje implementirati procese, ki bodo preprečili nenadzorovan dostop do sistema (GAMP 5, 2007):

vzpostavitev in vzdrževanje uporabniških skupin in odgovornosti (tehniki, raziskovalci, administratorji), politik delovanja sistema, standardov in ostalih kontrol,

izvajanje varnostnega nadzora in periodičnega testiranja, kot so testiranje prijave v računalniški sistem, preverjanje zgodovine dostopov do sistema, avtomatski zaklep uporabnika v primeru neaktivnosti, ipd.,

implementacija korektivnih ukrepov v primeru identificiranih varnostnih pomanjkljivosti in

nadzor in redno posodabljanje seznama oseb, ki imajo dostop do računalniškega sistema.

Raven varnostnega nadzora do računalniškega sistema naj bo določena glede na pomembnost sistema, osveščenosti zaposlenih glede varnosti, ponovljivosti incidentov in napak. Generalno mora organizacija poskrbeti za izdajo smernic za postopanje z varnostjo na računalniških sistemih. Glede na smernice se nato določi kakšno raven varnosti implementirati za posamezni sistem. Odgovornost za ustrezno varnost in dostopnost na računalniških sistemih je na lastniku procesa in lastniku računalniškega sistema, ki mora poskrebeti za implementacijo ustreznih kontrol. Samo implementacijo varnostnih kontrol izvede administrator sistema glede na dogovor z lastnikom sistema. Odgovornost UK je, da zagotovi, da se varnostne zahteve izvajajo. Končni uporabnik računalniškega sistema je odgovoren, da upošteva in izvaja implementirane varnostne zahteve tekom svoje vsakodnevnega dela (GAMP 5, 2007). Da bi zagotovili ustrezno varnost in dostopnost do računalniških sistemov mora organizacija vzpostaviti sistem izobraževanja zaposlenih, da bi svoje naloge opravljali skladno z splošnimi postopki in navodili za delo. Vsak uporabnik računalniškega sistema mora biti izobražen po splošnih postopkih in navodilih za delo za posamezni sistem, do katerega ima dostop. Na podlagi opravljenih izobraževanj mu lastnik sistema dodeli dostop (uporabniški račun). Vsa izobraževanja morajo imeti zapis o izvedbi izobraževanja, ki mora biti podpisan s strani izobraževalca in izobraženega in imeti referenco do dokumenta po katerem se je izobraževalo. Opremljen mora biti tudi z datumi in podpisi in ustrezno hranjen, da je dostopen regulatornim organom (GAMP 5, 2007). 3.2.4 PERIODIČNI PREGLEDI Periodični pregled računalniškega sistema potrdi, da so vse kontrole na sistemu še vedno veljavne in nastavitve enake prvotnim. Izvedeni periodični pregled lahko rezultira v dodatnih izboljšavah na sistemu, ki jih je potrebno voditi skozi predlog za spremembo (glej poglavje 4.2.7). Periodični pregled izvajamo, da sistem ohranjamo v ustreznem validiranem stanju, da so procesi dela na sistemu



stran 24

regulatorno skladni in da je vsa potrebna dokumentacija še naprej zadostna glede na regulatorne zahteve. Na kratko, iščemo potrditev, da je računalniški sistem skozi čas še vedno skladen z regulatornimi zahtevami in zahtevami same organizacije glede izvedbe procesov na njem (ECA, 2013). Periodo izvajanja periodičnih pregledov določimo glede na prepoznane rizike za posamezen sistem. Običajna perioda izvajanja je 1 do 3 leta. Izvedbo oddelek UK planira v letnem krovnem načrtu validacij, izvajalec pregleda pa mora pregled izvesti v vnaprej dogovorjenem roku navedenem v letnem načrtu validacij. Pomanjkljivosti najdene tekom periodičnega pregleda se morajo dokumentirati in navesti se morajo korektivni ukrepi. Dogovorjen korektivni ukrep mora biti usklajen z uporabniki in UK in izveden v roku. Tudi korektivne ukrepe moramo ustrezno dokumentirati (GAMP5, 2007). Tekom priprave na periodični pregled moramo zbrati vse potrebne informacije, ki jih bomo našli v (GAMP5, 2007):

celotni validacijski dokumentaciji,

splošnih postopkih in navodilih za delo,

izvedenih spremembah na sistemu,

incidentih,

seznamih in navodilih za dostopanje do sistema in

validacijskem poročilu. Periodični pregled se izvaja po vnaprej pripravljenem planu (obrazec splošnega postopka za periodične preglede). Izvajalcu periodičnega pregleda morata biti tekom izvedbe dosegljiva lastnik procesa in lastnik sistema, ki mu pomagata pri sami izvedbi z informacijami, ki jih sam ne more pridobiti. Okvirni koraki aktivnosti periodičnega pregleda so opisani na sliki 5.



stran 25

Slika 5 Prikaz aktivnosti periodičnega pregleda glede na posamezne korake (GAMP5, 2007).

Tekom izvedbe periodičnega pregleda se mora na računalniškem sistemu preveriti (GAMP5, 2007):

da je vsa dokumentacija povezana s sistemom ažurna in pravilna glede na trenutne regulatorne zahteve,

vse spremembe, ki so se zgodile na sistemu,

poročila presoj (internih in eksternih),

da so implementirane kontrole še vedno prave in funkcionalne,

delovanje sistema,

operativne procedure vpeljane tekom validacije,

osebje – izobraževanja, izkušnje in zmožnost dela na sistemu,

varnostne kontrole in dostope,

vzdrževanja sistema in seznam incidentov in

delovanje varnostnega kopiranja elektronskih zapisov. Poročilo o periodičnem pregledu mora biti dokumentirano s potrdilom, da je sistem še vedno primeren za nadaljnjo uporabo. Če je potrebno, definiramo korektivne ukrepe, spremembe na sistemu pa ustrezno dokumentiramo. Aktivnosti za korektivne ukrepe identificirane tekom priprave poročila o periodičnem pregledu morajo biti potrjene pred samim zaključkom poročila. Lastnik procesa je odgovoren, da je njegov sistem periodično pregledan skladno z regulatornimi zahtevami ter, da ustrezno odpravi morebitne odkrite



stran 26

pomanjkljivosti. UK je odgovoren, da so periodični pregledi planirani, izvedeni in pravilno dokumentirani. Pregled poročila pregleda mora biti ustrezno potrjen od vseh deležnikov, kot so IT, končni uporabnik, lastnik sistema, inženiring, UK, ipd. 3.2.5 VARNOSTNO KOPIRANJE IN RESTAVRIRANJE ELEKTRONSKIH ZAPISOV Varnostno kopiranje elektronskih zapisov je potrebno zaradi zaščite pred izgubo, pokvarljivostjo, poškodovanjem in neavtoriziranim spreminjanjem. Restavriranje elektronski zapisov je občasna akcija ponovnega restavriranja zapisa, ko je le to potrebno (izguba, poškodovanje prvotne verzije) (GAMP5, 2007). Vpeljane procedure in testiranja le-teh potrjujejo, da se varnostno kopiranje elektronskih zapisov izvaja celovito in brez napak na določeno časovno obdobje (glede na rizike). Vpeljane morajo biti procedure in izvedena testiranja za restavriranje povrnitev zapisov v prvotno stanje. Ciljna infrastruktura kamor se shranjujejo varnostne kopije zapisov mora biti validirana. Hraniti se mora preglede zgodovine varnostnega kopiranja. Delovanje varnostnega kopiranja in restavriranje zapisov je potrebno periodično preverjati (glej poglavje 4.2.4), da bi zagotovili zanesljivost in pravilnost delovanja (GAMP5, 2007). Lastnik procesa je odgovoren za definiranje obsega elektronskih zapisov, ki morajo biti varnostno kopirani in dosegljivost podatkov in časovnice v primeru restavriranja zapisov. Lastnik sistema in UK sta odgovorna, da je proces varnostnega kopiranja in restavriranja ustrezno dokumentiran in skladen s splošnim postopkom oziroma navodili za delo. Za izvedbo in nadzor je odgovoren tehnični kader, najpogosteje IT, ki skrbi za strežniško infrastrukturo za shranjevanje podatkov in orodja za izvedbo varnostnega kopiranja in restavriranja (GAMP5, 2007). 3.2.6 ARHIVIRANJE IN POVRNITEV ELEKTRONSKIH ZAPISOV Predhodno poglavje opisuje varnostno kopiranje elektronskih zapisov, kjer se kopirajo ažurni podatki na določeno časovno obdobje, pri arhiviranju pa elektronske zapise z enkratno akcijo umaknemo s sistema na varno lokacijo (strežnik, medij), pogosto zaradi zaščite pred spremembami in izgubo na računalniških sistemih, ki jih ne bomo več uporabljali oziroma smo jih zamenjali z novimi. Arhivirani podatki morajo biti shranjeni v berljivi obliki in na voljo uporabnikom na njihovo zahtevo za vnaprej določeno obdobje hranjenja. Arhivirani zapisi morajo biti periodično preverjeni, da ohranimo celovitost, dosegljivi, berljivi in popolni. Z arhiviranjem je potrebno zagotoviti, da so zapisi ohranijo pravilno vsebino in pomen (GAMP5, 2007). Za proces arhiviranja je potrebno vzpostaviti splošen postopek, ki predvidi namen uporabe arhiviranja (kdaj arhivirati), za kakšno časovno obdobje in v kakšen formatu (da bo berljivo v prihodnosti). Povrnitev elektronskih zapisov na zahtevo lastnika procesa izvede IT specialist. Povrnjeni zapisi morajo biti berljivi na obstoječih sistemih in celoviti, da zadostijo željam naročnika (ECA, 2013). Lastnik procesa z odobritvijo UK je odgovoren za sprožitev procesa arhiviranja elektronskih zapisov v primeru upokojitve ali zamenjave obstoječega



stran 27

računalniškega sistema. UK je odgovoren tudi za skladnost izvedbe in povrnitve zapisov na zahtevo lastnika procesa. Arhivar, najpogosteje oseba z IT oddelka, je odgovorna za prevzem, arhiviranje in povrnitev elektronskega zapisa glede na zahteve UK in želje lastnika procesa. Lastnik sistema je odgovoren, da se proces pravilno izvaja in da je proces arhiviranja in povrnitve lastnikom procesa vedno na voljo (GAMP5, 2007). 3.2.7 UPRAVLJANJE S SPREMEMBAMI Upravljanje s spremembami je proces kontrole nad spremembami na računalniškem sistemu. Primarni cilj upravljanja s spremembami je udejanjenje spremembe, brez dodatnih kompromisov na reguliranem procesu sistema, brez da bi kakorkoli motili nadaljnje delo na sistemu. Upravljanje s spremembami v farmacevtski industriji se nanaša tako na strojne in programske komponente računalniškega sistema, kot na spremembe splošnih postopkov in procedur, posebej tistih z vplivom na GxP proces (GAMP5, 2007). Ko je proces upravljanja s spremembami vzpostavljen se mora le-ta izvajati vse do upokojitve sistema, prav tako, če se povrnitev elektronskih zapisov izvede po upokojitvi mora le to biti predmet upravljanja s spremembami novega sistema. Vse spremembe, kot je prikazano na Sliki 6, morajo biti (GAMP5, 2007):

preverjene in usklajene,

s prepoznanim vplivom in riziki za spremembo,

avtorizirani s strani lastnika sistema in UK,

testirani,

potrjeni pred implementacijo in

vse aktivnosti dokumentirane. Ko izvedemo spremembo je potrebno navesti vse vplive in posodobiti dokumentacijo na katero sprememba vpliva. Po potrebi moramo ob spremembah na novo izobraziti uporabnike računalniškega sistema oziroma z njimi povezanih procesov. Odgovornost lastnika procesa je, da zagotovi, da je upravljanje s spremembami izpeljano na način kot ga predpisujejo splošni postopki za upravljanje sprememb na računalniški sistemih. Poskrbeti mora tudi za nemoteno podporo ostalim deležnikom vključenim v implementacijo spremembe. Odgovornost UK je, da so spremembe implementirane skladno z regulatornimi zahtevami in splošnimi postopki. Odgovornost vseh preostalih vpletenih (IT, lastnik sistema, ipd.) je, da izvedejo vse aktivnosti in nudijo podporo v vseh fazah upravljanja s spremembo (GAMP 5, 2007).



stran 28

Slika 6 Proces uvajanja spremembe na računalniškem sistemu (GAMP 5, 2007)

3.2.8 UMIK RAČUNALNIŠKEGA SISTEMA Ko se lastnik sistema odloči, da računalniškega sistema bodisi zaradi dotrajanosti, zamenjave ali katerega drugega razloga ne potrebuje več, je potrebo sistem formalno umakniti. Običajen izraz za umik je upokojitev. Postopek upokojitve računalniškega sistema je potrebno dokumentirati. Dokument »Upokojitveni načrt« mora vsebovati (GAMP5, 2007):

- vloge in odgovornosti, - opis procesa, ki ga pokriva računalniški sistem, - pristop k upokojitvi, - izvedba arhiviranja pripadajoči elektronskih zapisov računalniškega sistema, - preverjanje restavriranja elektronskih podatkov in zmožnost ponovne

uporabe v prihodnosti, - preklic podpore in vzdrževanja računalniškega sistema, - odprtje predloga za spremembo, kjer so popisane vse potrebne akcije

upokojitve, - roke za izvedbo,



stran 29

- izvedbo upokojitve in - upokojitev in arhiviranje pripadajoče dokumentacije računalniškega

sistema. Izvajalec upokojitve računalniškega sistema mora pred začetkom upokojitve odpreti predlog za spremembo, kjer navede potrebne aktivnosti, nosilce aktivnosti in roke za izvedbo. Ključni deli izvedbenega dela upokojitve računalniškega sistema so:

- arhiviranje elektronskih zapisov nastalih tekom uporabe računalniškega sistema,

- test restavriranja in preverjanje arhiviranih podatkov za primer kasnejše uporabe elektronskih zapisov za namen dodatnih raziskav in izračunov za obdobje, ko je bil sistem še v uporabi,

- obveščanje uporabnikov o upokojitvi, - odvzem vseh avtorizacij na sistemu in - sprememba statusa uporabe računalniškega sistema v inventarju

računalniških sistemov – status »izven uporabe« oziroma »upokojeno«. Zahteva za izvedbo upokojitve sistema mora izhajati s strani lastnika sistema, ki zahteva upokojitev računalniškega sistema, ki ga ne bo več potreboval v produkcijskem okolju. Izvedbo upokojitve izvede IT podpora s pomočjo lastnika procesa, plan in izvedbo pa odobri UK. Pomoč pri upokojitvi lahko nudijo tudi ostale funkcije v organizaciji, po potrebi na zahtevo izvajalca upokojitve.

3.3 ODSTOPANJE V 3. poglavju so navedene potrebne aktivnosti za pripravo validacijske dokumentacije in vzdrževanje validiranega stanja računalniško podprtega sistema v farmacevtski organizaciji glede na regulatorne zahteve. Pri pripravi validacijske dokumentacije in tekom vzdrževanja validiranega stanja strmimo k perfekciji in skušamo preprečiti nepravilno delovanja računalniškega sistema. Pogosto se zgodi, da sistem ne deluje po pričakovanjih, takrat govorimo o odstopanju od validiranega stanja oziroma odstopu. S pravilnim pristopom k identifikaciji, reševanju in preprečevanju ponovljivosti, odstopi nimajo vpliva na kakovost izdelka in kasneje bolnike, ki zdravila uživajo. V nadaljevanju magistrskega dela je detajlno opisan izraz odstop, klasifikacija odstopa glede na pojavno obliko (notranja ali zunanja presoja) in vpliv na produkt (zdravilo). Razumevanje izraza odstop nato v zaključnem delu magistrske naloge pripomore k razumevanju in lažjemu preprečevanju zunanjih odstopov naslovljenih s strani regulatornih organov. V kolikor vemo katere odstope lahko pričakujemo in zakaj do njih prihaja se lahko lažje pripravimo na njih in se jim posledično tudi lažje izognemo. V teoretičnem delu poglavja je opis odstopa predstavljen na poljuden in splošen način, v praktičnem delu pa fokus raziskave na preučevanju odstopov s področja računalniških sistemov v farmacevtski industriji z vidika ameriškega regulatornega organa (FDA). V praksi lahko pride do odstopanj in neskladnosti izvedenih postopkov ali dobljenih rezultatov glede na interne postopke, specifikacije, količine, parametre in veljavno dobro proizvodno prakso (Lek d.d., 2015). Vse to privede do odstopa od



stran 30

validiranega stanja na računalniškem sistemu. Odstop v praksi lahko definiramo tudi kot vsak neplaniran ali nezaželen dogodek, težava oziroma incident, ki predstavlja neskladnost izvedenih procesov, postopkov in dobljenih rezultatov glede na interno predpisane postopke, specifikacije, količine, parametre in veljavno dobro proizvodnjo prakso, kjer je glede na predpisane kriterije zahtevana in potrebna formalna raziskava v aplikaciji za vodenje odstopov v podjetju. Gre za dogodke, ki predstavljajo potencialno tveganje za kakovost, identiteto, jakost, čistost, varnost, učinkovitost, zanesljivost in obstojnost izdelkov ter imajo potencialni vpliv na status validacij (Lek d.d., 2015). Dogodek, kjer gre za manjšo neskladnost izvedenih postopkov ali dobljenih rezultatov glede na predpise in dobro proizvodnjo prakso, imenujemo manjši kakovostni incident (MKI). MKI nima vpliva na kakovost serije izdelka, ni vpliva na status validacije in kvalifikacije in ne gre za ponavljajoči se dogodek. Izvedemo formalno raziskavo, ki jo vodimo preko aplikacije za vodenje odstopov (Lek d.d., 2015). Poleg odstopov na procesu znotraj organizacije poznamo še odstop na notranji in zunanji presoji. Namen notranjih presoj v organizaciji sami in zunanjih presoj s strani regulatornih organov in drugih pogodbenih partnerjev je sistematično in neodvisno oceniti ustreznost sistema kakovosti z zahtevami dobre proizvodne prakse (GMP), dobre laboratorijske prakse (GLP), dobre klinične prakse (GCP), predpisanimi in načrtovanim standardom in elementi sistema kakovosti znotraj podjetja. Preverja se ali je sistem učinkovit pri doseganju zastavljenih ciljev z namenom stalnega izboljševanja sistema kakovosti (Lek d.d., 2015). 3.3.1 IZRAZI POVEZANI Z ODSTOPANJI Za lažje razumevanje tematike obvladovanja in preprečevanja vseh vrst odstopanj v farmacevtski industriji moramo poznati naslednje izraze (Lek d.d., 2015): Aktivnost so v aplikaciji za obvladovanje odstopov zapisane akcije, ki izhajajo iz evidentiranega dogodka (npr. odstopa ali MKI) in/ali raziskave le tega. Namen aktivnosti je preprečiti in popraviti napake, izvesti raziskavo dogodka, uvesti ukrepe ali pa oceniti učinkovitost uvedenih korektivnih in/ali preventivnih ukrepov. Aktivnost se dodeli osebi, ki bo aktivnost izvedla oziroma bo za njo odgovorna. Vsaka aktivnost ima vnaprej določen rok za izvedbo, ki se ga mora izvajalec aktivnosti držati. Klasifikacija dogodka pomeni razporeditev ugotovljene neskladnosti v kategorije MKI, odstop ali kritičen odstop glede na kriterije in pretehtano odločitev odgovornih oseb s področji, kjer so neskladnosti ugotovljene. Vzrok (ang. Root cause) je osnovni razlog oziroma vzrok za pojav odstopa. Vsak odstop terja raziskavo vzroka za odstop, ki ga navedemo v raziskavo odstopa. Vzrok lahko terja spremembo (predlog za spremembo), ki bo v prihodnosti preprečevala ponovni odstop. Raziskava dogodka je krovna aktivnost, ki jo opravijo odgovorne osebe za reševanje odstopa. Gre za niz akcij, kjer raziščemo vzrok za pojav odstopa, odstop



stran 31

detajlno razčlenimo, opravimo raziskavo in si predpišemo aktivnosti kot korektivne ukrepe. Takojšnji ukrepi so aktivnosti, izvedene nemudoma ob ugotovitvi nekega dogodka (odstopa), z namenom zmanjšanja vpliva na izdelek, storitev, procese, opremo, sisteme ali varnost, še preden se izvede raziskava dogodka in je znan vzrok za pojav le-tega. Preverjanje ukrepov so predpisane aktivnosti izvedene v prihodnosti po identifikaciji odstopa, ki služijo preverjanju izvedenih ukrepov v praksi in morebitni modifikaciji le teh. 3.3.2 KLASIFIKACIJA ODSTOPOV NA PROCESU V začetni fazi raziskave odstopa se izvede klasifikacija kritičnosti odstopa. Klasifikacija se izvede na osnovi ocen rizikov, definiranih kriterijev, ki izhajajo iz GMP regulative in skladno z navodili splošnih postopkov v podjetju. Odstope delimo na kritične in nekritične, nekritične delimo naprej še na večje in manjše odstope. Kritični odstop je odstop, ki bo z veliko verjetnostjo negativno vplival na kakovost in varnost izdelka, zanesljivost in stabilnost izdelka, ki je bil oziroma še bo sproščen na trg končnemu kupcu. Gre za veliko napako sistema kakovosti in predstavlja kritičen odmik od regulatornih zahtev. Kritičen odstop negativno vpliva na ugled podjetja, saj so lahko potrebni odpoklici izdelka s trga in javno obveščanje o odstopanju od regulatornih zahtev. Večji odstop lahko negativno vpliva na kakovost in varnost izdelka, na identiteto, jakost, čistost, učinkovitost, zanesljivost ali stabilnost izdelka, ki še ni bil sproščen/distribuiran na trg. Večji odstop lahko predstavlja sistemsko napako z omejenim vplivom, ki smo jo odkrili tekom rutinskih pregledov procesa (periodični pregledi, poglavje 4.2.4). Prav tako ogroža varnost in dobro počutje pacientov, ki bi to zdravilo zaužili in tako negativno vpliva na ugled družbe. Manjši odstop, ki ni ne kritičen ne večji, se obravnava kot manjši odstop in ga je prav tako potrebno formalno reševati preko aplikacije za vodenje odstopov. Odgovornosti pri identifikaciji in reševanju odstopov znotraj organizacije so naslednje (Lek d.d., 2015): Enota UK je odgovorna za:

- potrditev ustreznosti raziskave odstopa, načrtovanih in izvedenih korektivnih ukrepov,

- spremljanje poteka raziskave odstopov, primernost in ustreznost izvedenih korektivnih ukrepov,

- evidentiranje vseh vrst odstopov, - odločanje in spremljanje ocene učinkovitosti izvedenih korektivnih ali

preventivnih ukrepov, - takojšnje obveščanje notranjim in zunanjim partnerjem glede na

vključenost le-teh in vpliv odstopa na njih in



stran 32

- končna potrditev vseh aktivnosti in raziskav odstopa v aplikaciji za vodenje odstopov.

Sodelavci oddelkov znotraj podjetja, na katere ima odstop vpliv so odgovorni za:

- pravočasno identifikacijo odstopa, - poročanje enoti UK o odstopu, - sodelovanje pri identifikaciji, raziskavi, korektivnih ukrepih odstopa glede

na soglasje enote UK, - izvedba raziskave odstopa in implementacija korektivnih ali preventivnih

ukrepov, - podajanje mnenj in vodenje aktivnosti reševanja odstopa v povezavi z

enoto UK in - zaključek aktivnosti in raziskave v aplikaciji za vodenje odstopov.

Odgovornosti enote UK in vseh ostalih deležnikov, ki so kakorkoli vključeni v identifikacijo, reševanje in zaključek odstopa je zelo prepleteno. Gre za medsebojno pomoč, ki na koncu odraža ustrezne ukrepe za uspešno rešitve in neponovljivost obravnavanega odstopa. 3.3.3 KLASIFIKACIJA ODSTOPOV NA NOTRANJI PRESOJI Glede na letni plan notranjih presoj (interni presojevalec presoja del organizacije za katero je odgovoren kot UK predstavnik) se določi nosilce za izvedbo in okvirne termine. Za pripravo letnega plana je odgovorna enota UK, ki predlaga ustrezne presojevalce za posamezen del procesa oziroma organizacije, presojevalec pa je odgovoren, da plan presoje ustrezno uskladi z skrbniki procesov in sistemov. Notranje presoje se izvajajo vsaj enkrat letno in so regulatorno zahtevane. Na notranji presoji presojevalec tekom presoje lahko identificira naslednje vrste odstopov (Lek d.d., 2015): Kritični odstop (neustrezno) je signifikanten odstop od veljavnih regulatornih zahtev z možnimi posledicami kot so, varnost in dobro počutje ljudi, kakovost, čistost, učinkovitost ali integriteta zdravila. Če je integriteta regulatornih zahtev postala nezanesljiva in če gre za strokovno zmoto, lahko govorimo o kritičnem odstopu. Kritične odstope, ki vplivajo na centralni sistem kakovosti in posledično na sam produkt poslan na trg je potrebno takoj sporočiti regulatornim organom, ki nato ustrezno predpišejo korektivne ukrepe in nadaljnje aktivnosti. Večji odstop (potrebne izboljšave) je odstop od veljavnih regulatornih zahtev, ki kaže na sistemsko napako kakovosti, ki ne ogroža varnosti, pravic in dobrega počutja ljudi, kakovosti in učinkovitosti zdravil, integriteto in zanesljivost zahtevanih podatkov. Manjši odstop (ustreza) je odstop od veljavnih regulatornih zahtev, ki niso kritične in ne velike. Običajno gre za izolirane ugotovitve z minimalnim vplivom na proces. Priporočilo je opažen proces ali stanje, ki ne predstavlja odstopa od veljavnih regulatornih zahtev, temveč bi njegova izboljšava bistveno vplivala na



stran 33

učinkovitost ali zmogljivost procesa, ter tako preprečila morebiten kasnejši odstop. Večje število neskladji na eni vrsti odstopa lahko tekom presoje dvigne oceno neskladnosti višje. Več manjših odstopov na povezanih se procesih lahko pomeni en večji odstop. 3.3.4 KLASIFIKACIJA ODSTOPOV NA ZUNANJI PRESOJI Poleg internih notranjih presoj znotraj organizacije poznamo še presoje zunanjih regulatornih organizacij, ki presojajo posamezno farmacevtsko organizacijo v imenu države (kontinenta), kjer prodajaš svoj končni izdelek. Gre za državne regulatorne organizacije, ki zagotavljajo varnost na področju zdravil in hrane v državi kateri pripadajo. Za ameriški trg je to FDA, za evropskega EMA, ipd. Povod za obisk regulatornega organa v organizaciji je lahko (Darshit S. Patel, 2012):

- Obisk pred lansiranjem novega proizvoda, ki ga bo podjetje lansiralo na trg od koder prihaja regulatorni organ in za katerega je le-ta odgovoren (npr. FDA za Ameriko). Z obiskom se regulatorni organ prepriča, da je sistem kakovosti v obiskanem obratu na nivoju, da bi lahko varno proizvajal zdravilo in ga lansiralo na trg končnemu uporabniku.

- Obisk po lansiranju novega proizvoda, ki ga je podjetje lansiralo na trg od koder prihaja regulatorni organ in za katerega je le-ta odgovoren. Z obiskom regulatorni organ preveri, če so zaveze, ki so bile dane pri obisku pred lansiranjem proizvoda v celoti uresničene in udejanjene v praksi.

- Rutinska redna inšpekcija. Namen te inšpekcije je, da regulatorni organ ugotovi ali obravnavano podjetje upošteva vse regulatorne zahteve, ki veljajo, da lahko proizvajamo varna in učinkovita zdravila za bolnike. Gre za redno planirano inšpekcijo na 1 – 3 leta, odvisno od kritičnosti procesov in renomeja podjetja pri regulatornih organih pridobljenega v preteklosti.

Klasifikacija odstopov na zunanji presoji regulatornega organa je enaka tisti iz prejšnjega poglavja o klasifikaciji odstopov pri notranji presoji, in sicer kritičen, večji, manjši odstop ter priporočilo. Podjetje, ki s strani regulatornega organa na presoji dobi kritičen odstop ali »waning letter« mora v 15 dneh (velja za FDA, ki kritičen odstop poimenuje »483«) odgovoriti regulatornemu organu z zavezami, da (LabCompliance, 2015):

- popolnoma razume vso vsebino vsakega posameznega odstopa, - da razume vsebino odstopa in, da ga sprejema oziroma se z njim strinja, - v kolikor je kakšen odstop že rešen, pošlje papirni dokaz, - za ostala poslati načrt kdo, kako in kdaj bo odstop rešen, - poslati zavezo, da bodo vsi vpleteni ustrezno izobraženi za spremembe, ki

se bodo uvedle in - navesti kako se bo v prihodnosti preprečilo ponovitev podobnih odstopov.

Za večje in manjše odstope in priporočila velja, da se odda poročilo o odpravi nepravilnosti z vsemi korektivnimi ukrepi in akcijami, ki bodo izvedene (kdo, kdaj, kako).



stran 34

3.4 OBSEG IN VSEBINA VALIDACIJSKE DOKUMENTACIJE TEKOM ŽIVLJENSKEGA CIKLA

V vse bolj reguliranem in nadzorovanem okolju farmacevtske industrije je lahko učinkovita in kvalitetna izvedba validacijskih aktivnosti ključna konkurenčna prednost. V poglavju 4.1 in 4.2 opišem posamezne sklope validacijske dokumentacije in vzdrževanja validiranega stanja zahtevane strani regulatornih organov. Tekom implementacije in vzdrževanja računalniškega sistema lahko z ocene rizikov optimiziramo obseg in vsebino validacijske dokumentacije ter definiramo kritične korake proizvodnega procese izdelka in jih nato validiramo skladno z regulatornimi zahtevami in predpisi. S takšnim pristopom dosežemo, da se pri obsegu validaciji osredotočimo zgolj na procese in aktivnosti, ki so kritične in ne izgubljamo časa, resursov in denarja na sklopih, ki nimajo vpliva na proizvodnjo zdravil ali pa predstavljajo rešitve, ki so bile že ničkolikokrat potrjene s strani uporabnikov. Ključno je prepoznati kritične korake proizvodnega procesa s strani uporabnika (uporabniške zahteve), jih ovrednotiti z oceno rizikov in pripraviti zadosten obseg validacijske dokumentacije skladno z regulatornimi zahtevami. V kolikor vseh rizikov ne moremo obvladovati z računalniškim sistemom se kot alternativa lahko vpelje vnaprej dogovorjene in validirane procedure, ki nadomestijo pomanjkljive funkcionalnosti računalniškega sistema. Ključno je, da si za proces priprave, ocene rizikov in korektivnih ukrepov podjetje vzame zadosti časa in resursov. Le tako lahko prepoznamo kritične dele procesa in prihranimo pri obsegu in vsebini validacije in ohranjanja življenjskega cikla računalniškega sistema. Cilj pri pripravi obsega in vsebine validacijske dokumentacije računalniškega sistema naj bo zato ciljana na:

- natančno definirane uporabniške zahteve, ki naj se fokusirajo na kritične korake obravnavanega procesa,

- oceniti rizike računalniškega sistema z ciljem implementacije robustnejših, enostavnejših procesov in hitrejšega zaznavanja napak,

- pripraviti obseg validacijske dokumentacije skladno z regulatornimi zahtevami, ki se bo osredotočil na validacijo procesov in funkcionalnosti računalniškega sistema, ki so dejansko kritični v procesu proizvodnje zdravil,

- ažurno upravljati življenjski cikel validacijske dokumentacije glede na trenutne zahteve uporabnika računalniškega sistema in regulatorne zahteve.

Vse več podjetji ima težave z zagotavljanjem regulatorne skladnosti na presojah. Zaradi konkurenčnega okolja v farmacevtski industriji je potreben vse bolj ciljno usmerjen pristop k validaciji in vzdrževanju računalniškega sistema. Pristop k validaciji in vzdrževanju računalniškega sistema obravnavan v prvem delu naloge se odraža v uspešnem obvladovanju računalniškega sistema tekom življenjskega cikla in tako ključno prispeva k uspešnim pripravam in izvedbi presoj regulatornih organov obravnavanih v nadaljevanju naloge. V drugem delu naloge navedem dejanske odstope in predlagam ukrepe, ki zmanjšajo tveganje za pojav regulatorne neskladnosti na presojah.



stran 35

4 TRENDI PRESOJ FDA ZA PODROČJE RAČUNALNIŠKIH SISTEMOV

V poglavju se osredotočam na delovanje in zadnje trende ameriškega regulatornega organa FDA na področju skladnosti računalniških sistemov v farmacevtski industriji. Agencijo FDA sem izbral zato, ker gre za najvplivnejši regulatorni organ za zagotavljanje skladnosti razvoja in proizvodnje zdravil na svetu. Gre za največjo regulatorno organizacijo, ki je leta 2011 zaposlovala več kot 11.500 ljudi in operirala z letnim proračunom višjim od 4 miljarde dolarjev. V letu 2011 so v 230 državah sveta pokrivali več kot 300.000 obratov, od tega zgolj 140.000 v Ameriki (FDA, 2011). Veličina teh podatkov pove, da gre za organizacijo, ki ima odločilen vpliv na proizvodnjo zdravil, hrane, ipd. po vsem svetu. FDA je v farmacevtski industriji znana kot organizacija z najbolj dodelanim sistemom kakovosti, ki vseskozi stremi k izboljšavam in bolj strogim pogojem za varno izdelavo izdelkov pod njenim okriljem. Zato FDA presoja v farmacevtskem podjetju velja za najbolj zahteven »preskus« obvladovanja kakovosti na področju razvoja in proizvodnje zdravil. Področje skladnosti računalniških sistemov v farmacevtski industriji je tudi za FDA kot organizacijo z dolgoletno tradicijo (ustanovljena leta 1906) relativno novo področje, ki se v zadnji letih bliskovito razvija. Regulativa FDA za področje skladnosti računalniških sistemov 21 CFR PART 11 je v veljavi od leta 1997 (tako imenovani »legacy« sistemi v uporabi pred tem letom ne zapadejo v regulativo), vendar se je z vidika fokusa presoj in znanja FDA inšpektorjev na lokacijah farmacevtskih podjetji bistveno razvila šele po letu 2010.

4.1 ODSTOPANJA S PODROČJA RAČUNALNIŠKIH SISTEMOV Trendi odkritih odstopanj zadnjega obdobja s področja računalniških sistemov v farmacevtski industriji nakazujejo osredotočenost presoj na delovanje računalniških sistemov in integritete podatkov. Govor Karen Takahashi na letnem sestanku FDA v Las Vegasu leta 2014 potrjuje, kako pomemben in natančen je (bo) fokus FDA presojevalcev na integriteto podatkov in računalniške sisteme v bližnji prihodnosti. Ga. Takahashi je svoj govor začela z dejstvom kako dolgočasno in monotono je lahko zagotavljanje integritete podatkov v farmacevtski industriji. Gre za konstantno dvojno preverjanje in dolgočasno navzkrižno preverjanje. Želja je, da bi to preverjanje in uspešno izpolnjevanje integritete podatkov postalo bolj enostavno in ne tako monotono in dolgočasno. Zato morajo podjetja poskrbeti za ustrezna orodja, da bo integriteta podatkov ustrezna, delovanje računalniških sistemov pa zanesljivo. Le tako bo veličina vloženega truda lahko povrnjena. Ker to velja tako za podjetja, kot tudi FDA, je FDA razvil več načinov kako preverjati avtentičnost podatkov, vključno z elektronskimi in ročnimi metodami. Razlog za to je v tem, da je enostavno vse preveč možnosti za ponarejanje in prirejanje podatkov. Začeli bodo postopoma, zavedajo se, da bo monotono in dolgočasno, vendar morajo začeti. Nato je naštela vse ne-elektronske načine kako lahko v trenutku presojevalec preveri ustreznost zapisov, kot npr. primerjava časov na papirnih in elektronskih zapisih, ustreznost vseh vnosov v dnevnike delovanja sistema s tistimi



stran 36

na računalniku, prisotnost operaterjev v podjetju v času, ko so bili prijavljeni na računalniški sistem, preverjanje različnih zapisov v dnevnikih in poročilih in jih primerjati z izvedenim procesom, ipd. V kolikor presojevalec nima dovolj časa za detajlno preverjanje integritete podatkov,se osredotoči na logična in pričakovana zaporedja procesa v smislu časa, datuma, naslova aktivnosti, podpisa, ipd in iskanje nepravilnosti v procesu. Z nekaj izkušnjami in kritičnim pristopom lahko na takšen način v kratkem času odkrijejo neskladnosti integritete podatkov pregledanih aktivnosti. Zaključila je z nasvetom prisotnim sodelavcem: »Osredotočite se na laboratorije«. Tam je namreč največ možnosti za odkritje poneverb in nepravilnosti v procesu proizvodnje zdravila. Svetovala je tudi podjetjem, ki so bila in bodo presojana s strani FDA, da naj, v kolikor imajo težave z integriteto podatkov, najamejo tretjo osebo, ki jim bo kot strokovnjak pomagala identificirati probleme, implementiral korektivne ukrepe in akcijske plane ter ustrezno identificiral kritične posameznih in jih odstranil s procesa, ki ogroža integriteto podatkov in ugled celotnega podjetja (povzeto po Takahashi K., 2015). V nadaljevanju poglavja bom na podlagi seznama odstopov povezanih z računalniško podprtimi sistemi v farmacevtski industriji analiziral trenutni fokus ameriške FDA inšpekcije z vidika trenda zadnjih let in skušal napovedati prihodnje trende za boljšo pripravo na prihodnje inšpekcije v farmacevtskih podjetjih. Analiziral bom zadnjih 50 opozorilnih pisem ameriškega organa FDA podjetjem po svetu, javno dostopnih na spletni strani agencije.

4.2 ANALIZA ODSTOPANJ INŠPEKCIJ FDA NA RAČUNALNIŠKEM PODROČJU

FDA izda opozorilno pismo le za kritično kršenje regulatornih zahtev, ki jih zasledi ob inšpekcijskem pregledu organizacije. Z opozorilnim pismom lahko učinkovito dosežejo ureditev in popravke prepoznanih kršitev za posamezno področje prepoznano tekom inšpekcijskega pregleda (FDA, 2015). Področje, na katera se zadnja leta nanaša vse več opozorilnih pisem je področje skladnosti računalniško podprtih sistemov. FDA z leta v leto zaradi vse bolj rigoroznih inšpekcijskih pregledov podjetjem izda vse več opozorilnih pisem, ki se nanašajo (tudi) na neurejeno stanje na področju računalniških sistemov. Dodaten razlog je tudi vse večja avtomatizacija poslovnih procesov v farmacevtski industriji, podjetja pa zato vse težje sledijo regulatornim zahtevam s tega področja. Vsa opozorilna pisma FDA javno objavi na spletni strani agencije in so tako ažurno dostopna splošni javnosti. Na podlagi javnih objav in pomočjo filtrov med opozorilnimi pismi bom izbral tiste, ki se nanašajo na področje obvladovanja računalniških sistemov, jih analiziral, razporedil v 11 tematskih skupin in predlagal ukrepe kako preprečiti, da bi organizacija pridobila opozorilno pismo s strani FDA.



stran 37

4.2.1 UVRSTITEV ODSTOPOV V SKUPINE GLEDE NA TEMATIKO ODSTOPANJ Z raziskavo zadnjih 50 opozorilnih pisem s področja računalniških sistemov v farmacevtski industriji ameriške agencije FDA lahko odstope uvrstim v 11 tematskih skupin, ki izkazujejo izvorni problem za opozorilno pismo. Vsa opozorilna pisma, javno dostopna na spletni strani FDA agencije so natančno opisana s točno podanimi odstopanji. Glede na navedena dejstva v opozorilnih pismih in na podlagi lastnih izkušenj s področja regulatorne skladnosti, opozorilna pisma uvrstim v skupine in jim pripišem pogostost pojava posamezne skupine v zadnjih 50 opozorilnih pismih agencije FDA za področje računalniških sistemov. Opozorilna pisma razdelim v spodaj navedene skupine glede na tematiko odstopanja. Posamezno opozorilno pismo je lahko uvrščeno v več posameznih skupin glede na tematiko prepoznano s strani FDA agencije. Več tematsko različnih kritičnih odstopov poimenovanih »483« pogosto pomeni opozorilno pismo.

1. Brisanje in spreminjanje izvornih podatkov – nekontrolirano brisanje ali spreminjanje elektronskih zapisov na računalniškem sistemu s strani nepooblaščenih oseb (uporabnikov sistema). Posledično manjkajoči podatki o izvedenih analizah, procesih na računalniških sistemih in nezmožnost dokazovanja pravilnosti razvoja in proizvodnje zdravil.

2. Nepooblaščeno dostopi do računalniških sistemov. Uporabniki se

prijavljajo z generičnimi (ne-osebnimi) računi na računalniški sistem ali pa sistem nima implementiranih kontrol za kontrolirano dostopanje uporabnikov do računalniškega sistema. Uporabnik sistema nima dodeljenih ustreznih pravic glede na njegovo vlogo v procesu (npr. operater ima pravice administratorja). Deljenje gesel za posamezni račun med uporabniki – uporabnik se v sistem prijavlja z računom sodelavca.

3. Zgodovina dogodkov – računalniški sistem nima omogočeno beleženje

zgodovine dogodkov na sistemu (prijave, aktivnosti, čas zagona analize, spremembe na sistemu, ipd.). Sistem omogoča brisanje zgodovine dogodkov nepooblaščenim osebam. Ni vpeljanih procedur za ročno vodenje zgodovine dogodkov v kolikor sistem ne omogoča elektronskega. Na sistemu se ne izvaja periodični pregled zgodovine dogodkov.

4. Periodični pregledi ustreznosti sistemov – na sistemu se ne izvajajo redni

periodični pregledi ustreznosti delovanja sistemov skozi čas. Podjetje ne izvaja internih presoj ustreznosti delovanja računalniških sistemov (interna presoja, glej poglavje 4.3.3).

5. Temeljni vzroki za odstopanje, korektivni ukrepi, predlog za

spremembo – v primeru odstopa na računalniškem sistemu ni bil odkrit temeljni vzrok za nastanek odstopa in/ali niso bili ustrezno pripravljeni korektivni ukrepi za preprečitev ponovitve odstopa v prihodnosti. Spremembe na računalniškem sistemu niso bile ustrezno zabeležene in niso bile vodene preko dokumentiranega predloga za spremembe.



stran 38

6. Varnostno kopiranje elektronskih zapisov – na računalniškem sistemu ni poskrbljeno za varnostno kopiranje elektronskih zapisov. Podjetje ni zmožno restavrirati morebitno izgubljene elektronske zapise na računalniškem sistemu.

7. Manjkajoči splošni postopki, validacija sistema – računalniški sistem nima

regulatorno zahtevanih splošnih postopkov (navodil za delo, ostalih postopkov), ki bi opisovali način dela in kontrole na računalniškem sistemu. Sistem nima popolne validacijske dokumentacije, ki bi potrjevala ustrezno delovanje računalniškega sistema glede na zahteve uporabnikov in procesa, ki ga pokriva.

8. Kontrola nad metodami ali recepturami - metoda ali receptura, ki se

uporablja za izvedbo procesa preko računalniškega sistema ni ustrezno validirana in zaščitena pred nenadzorovanimi spremembami. Metoda ali receptura ni ustrezno potrjena in dokumentirana, ne vodi se spremembe in verzije.

9. Kvalifikacija opreme – oprema na kateri se izvajajo ni ustrezno

kvalificirana in tako lahko nepravilno deluje in zato ni primerna za produkcijsko uporabo.

10. Usposabljanje zaposlenih – uporabniki računalniških sistemov niso

ustrezno izobraženi po postopkih za delo s sistemom in/ali po splošnih postopkih za delo v produkcijskem okolju. Manjkajoče formalno izobraževanje po izdanih postopkih v dokumentnih sistemih podjetja.

11. Testne analize, datoteke, mape – uporabniki računalniškega sistema so pri

svojem delu opravljali testne analize in jih ponavljali dokler rezultati le teh niso bili ustrezni. Najdene so bile testne datoteke in mape, ki so vsebovale nenačrtovane in neustrezno hranjene rezultate analiz. Uporabniki niso ustrezno zavedli izvedbe testnih/neuspešnih analiz, ampak so analize ponavljali dokler le-te niso bile uspešne.



stran 39

Kot je razvidno s Priloge 1 eno opozorilno pismo v večini primerov vsebuje več obravnavanih tematik. Po razporeditvi opozorilnih pisem v posamezne tematike pridemo do naslednjih rezultatov:

Mesto: Tematika opozorilnega pisma:

Število pojavov:

1. Manjkajoči splošni postopki, validacija sistema 22

2. Brisanje in spreminjanje izvornih podatkov 18

3. Zgodovina dogodkov 13

4. Kontrola nad metodami ali recepturami 13

5. Temeljni vzroki za odstopanje, korektivni ukrepi, predlog za spremembo 11

6. Nepooblaščeni dostopi 10

7. Trening zaposlenih 9

8. Kvalifikacija opreme 8

9. Periodični pregledi ustreznosti sistemov 5

10. Testne analize, datoteke, mape 3

11. Varnostno kopiranje elektronskih zapisov 2

Tabela 3 Razporeditev pojavnosti posameznih tematik zadnjih 50 opozorilnih pisem agencije FDA na temo računalniških sistemov razvrščeno glede na število pojavov posamezne tematike.

4.2.2 RAZLAGA REZULTATOV ANALIZE Analiza pojavnosti posameznih tematik zadnjih 50 opozorilnih pisem agencije FDA na temo računalniških sistemov razvrščeno glede na število pojavov posamezne tematike pokaže, da se v opozorilnih pismih agencije največkrat pojavi tematika manjkajoči splošni postopki in validacija sistema in sicer kar 22-krat. Da se tematika pojavi najpogosteje ni presenečenje, saj je večina odstopov in nepravilnosti v farmacevtski industriji prepoznanih s strani inšpektorjev povezana z nepopolno ali manjkajočo validacijsko dokumentacijo in splošnimi postopki (kot so krovni postopki za delo z računalniškimi sistemi, navodila za delo, ipd.). Gre za logično posledico nepravilnosti v navezavi z regulatorno skladnostjo računalniških sistemov v podjetjih, ki ne upoštevajo regulatornih zahtev oziroma jih ne izpolnjujejo v celoti. Za primer lahko povzamemo opozorilno pismo WL: 320-15-04 (FDA, 2015), ki navaja kršitve podjetja povezane z manjkajočimi izvornimi podatki na laboratorijskih računalniških sistemih, uporabo generičnih uporabniških računov za prijavo v računalniški sistem, ipd. Do kršitve je prišlo, ker podjetje računalniškega sistema ni ustrezno validiralo in ni pripravilo validacijske dokumentacije, ki bi potrdila ustreznost delovanja računalniškega sistema in splošnih postopkov, ki bi predpisovali pravilno uporabo sistemov. Posledično je prišlo do odkritja nepravilnosti, ki so pripeljale do opozorilnega pisma agencije FDA. Agencija je



stran 40

podjetju naložila, da jim mora v najkrajšem možnem času posredovati validacijski plan za računalniške sisteme, ki bo uredil najdene nepravilnosti (FDA, 2014). Primer manjkajoče validacijske dokumentacije kaže kako pomembna je urejena dokumentacija za računalniški sistem, ki podjetju pomaga urediti delovanje sistema skladno z regulatornimi zahtevami. Splošni postopki so ena izmed zahtev procesa validacije in neposredno pripomorejo k pravilni uporabi sistema tekom življenjskega cikla računalniškega sistema s strani uporabnikov sistema. Brez popolne validacijske dokumentacije in splošnih postopkov bo podjetje hitreje zabredlo v težave, kot se je zgodilo podjetju v opisanem primeru. Ključno je tudi, da kljub vpeljanim kontrolam, zaposleni dosledno upoštevajo postopke, saj so v nasprotnem primeru ti nekoristni in ne služijo svojemu namenu. Da bi zaposleni sledili splošnim postopkom pa morajo biti ti del kakovostne kulture zaposlenih. Implementacija kulture kakovosti je zato ena izmed ključnih nalog višjega vodstva farmacevtskega podjetja. Druga najpogostejša tematika v opozorilnih pismih je brisanje in spreminjanje izvornih podatkov. Gre za tematiko, ki je v računalniškem svetu v kombinaciji s farmacevtsko industrijo najbolj občutljiva s strani regulatornih organov in hkrati težavna za zagotavljanje regulatorne skladnosti s strani farmacevtskih podjetji. Gre za težavo s preprečevanjem katere se ukvarja celotna farmacevtska industrija, v času, ko so regulatornih organi vse bolj opozorjeni na problematiko in ji zato posvečajo vse večjo pozornost. Izvorni problem težave zmožnosti brisanja in spreminjanja tiči v rešitvah okolja Windows podjetja Microsoft, ki je daleč najbolj pogosto okolje računalniških operacijskih sistemov v farmacevtski industriji. Jedro problema se skriva v tem, da je večina aplikacij za krmiljenje računalniško podprtih laboratorijskih in proizvodnih sistemov uporabljenih v farmacevtski industriji pisana za okolje Windows. Če aplikacija za krmiljenje računalniškega sistema uporablja datotečne podatke (izvorni podatki se na računalnik shranijo kot datoteka) v okolju Windows, težko preprečimo brisanje in prepisovanje obstoječih datotek, ker spreminjanje pravic na teh datotekah v večini primerov privede do nedelovanja same aplikacije. Uporabnik ima namreč kot avtor posamezne datoteke tudi možnost kasnejšega manipuliranja podatkov v kolikor le teh predhodno nismo ustrezno zaščitili pred brisanjem in prepisovanjem. Tudi če lahko samo brisanje relativno enostavno onemogočimo, pa je za prepisovanje to skoraj nemogoče brez ustreznih dodatnih kontrol znotraj aplikacije ali okolja Windows. Slika 7 prikazuje kako lahko uporabnik sistema obstoječo datoteko prepiše z novo z enakim imenom in tako prepiše originalni izvorni podatek, ki je v primeru, da podjetje nima dodatnih kontrol, za vedno izgubljen. Pri sistemih, ki podatke shranjujejo v bazo podatkov, načeloma do teh težav ne prihaja, saj se baze podatkov v veliki večini nahajajo na lokaciji, do katere uporabniki nimajo dostopa.



stran 41

Slika 7 Prikaz težave prepisovanja obstoječih datotek v okolju Windows.

V povezavi z navedeno tematiko lahko za primer vzamemo opozorilno pismo WL: [320-15-12] (FDA, 2015). Podjetju je bilo izdano opozorilno pismo zaradi brisanja originalnih izvornih podatkov iz laboratorijskih računalniških sistemov po prenosu relevantnih podatkov v drug program. Regulativa namreč zahteva, da se originalnih izvornih podatkov iz računalniških sistemov nikoli ne briše ali kakorkoli drugače spreminja. Še večja kršitev je bila odkrita na laboratorijskih kromatografskih sistemih iz katerih je imel vsak uporabnik v laboratoriju možnost izbrisati izvorne podatke, ker le ti niso bili ustrezno zaščiteni. Inšpektor je nekaj datotek celo našel v košu za datoteke enega izmed zaposlenih v laboratoriju (FDA, 2015). Gre za zelo hudo kršitev regulatornih zahtev, ki je vse bolj pod drobnogledom FDA inšpektorjev. Z brisanjem in spreminjanjem izvornih podatkov namreč zabrišemo sledi do izvornih podatkov računalniškega sistema in posledično lahko dvomimo v pridobljene rezultate, ki na koncu verige dogodkov lahko pripeljejo do neustrezne kakovosti zdravila. Vse več opozorilnih pisem se torej nanaša na tematiko brisanja in spreminjanja izvornih podatkov, ki je v zadnjem obdobju ena izmed najpogosteje prepoznanih nepravilnosti v farmacevtskih podjetji ob obisku regulatornih organov za področje računalniških sistemov. Kritično je, da inšpektorji pred leti za to področje praktično niso bili specializirani in, da do množičnih odkritji pomanjkljivosti kot je razvidno iz Priloge 1 prihaja v zadnji dveh do treh letih. Torej smo v začetni fazi odkrivanja tovrstnih nepravilnosti, ki se je morajo podjetja lotiti resno in z visoko prioriteto. Tretja najpogostejša tematika v raziskanih zadnjih 50 opozorilnih pismih agencije FDA je zgodovina dogodkov in vse nepravilnosti okrog zagotavljanja sledljivosti



stran 42

dela in sprememb na računalniških sistemih. Kot pri tematiki brisanja in spreminjanja izvornih podatkov gre tudi v tem primeru za relativno novo tematiko, ki jo regulatorni organi v zadnjih letih vse bolj natančno spremljajo in vse pogosteje odkrivajo nepravilnosti. Aplikacije in računalniški sistemi nasploh morajo imeti možnost spremljanja in beleženja zgodovine dogodkov sistema tekom izvedbe analize ali procesa. Vsaka prijava uporabnika, zagon analize, nastavitve parametrov in spremembe znotraj aplikacije morajo biti ustrezno beležene preko funkcionalnosti beleženja zgodovine dogodkov. Tako lahko pridemo do informacije o dogajanju na računalniškem sistemu in zagotavljamo pravilno delovanje le teh. S tem izvajamo nadzor nad delovanjem računalniških sistemov, ki nam služi kot pomoč pri reševanju incidentov in odstopov in zagotavljanju transparentnega delovanja računalniškega sistema nasploh (primer zgodovine dogodkov - Slika 8).

Slika 8 Primer zgodovine dogodkov prijav in sprememb na računalniškem sistemu.

Podjetja v želji po skrivanju nepravilnosti oziroma izogibanju lastnih napak pogosto posegajo po onemogočanju beleženja zgodovine dogodkov ali še hujše po brisanju le-teh (v navezavi z brisanjem izvornih podatkov, kar zgodovina dogodkov ravno tako je). Opozorilno pismo WL: 320-15-05 (FDA, 2015) razkriva, kako je imelo podjetje na kromatografskih laboratorijskih sistemih onemogočeno spremljanje zgodovine dogodkov. Ugotovili so tudi, da na sistemih ni bilo povezav med sistemom kjer je bila analiza izvedena in rezultati shranjenimi na računalniškem sistemu. Tako podjetje ne more dokazati na katerem sistemu je bila izvedena analiza in posledično rezultati na računalniškem sistemu ne morejo biti verodostojni (FDA, 2015). Nekateri drugi primeri kažejo, da je bila zgodovina dogodkov na računalniškem sistemu dostopna vendar naknadno izbrisana, kar pomeni še večjo kršitev regulatornih zahtev in nakazuje na namerno prikrivanje nepravilnosti na računalniškem sistemu. Tematika kontrola nad metodami ali recepturami se kot zgodovina dogodkov v analizi opozorilnih pisem pojavi 13-krat. Gre za relativno visoko ponovljivost opažanj FDA inšpektorjev, ki kaže na nepravilen nadzor nad metodami ali recepturami, ki so ključne za izvedbo del v pravilnem in nadzorovanem vrstnem redu na računalniško podprtem sistemu v farmacevtski industriji. Kontrola nad



stran 43

metodami in recepturami sicer ni neposredno povezana z delovanjem računalniških sistemov in ni neposredno v domeni IT administratorjev sistema, vendar pa je zelo pomembna z vidika uporabnika, ki metodo ali recepturo uporabi za izvedbo analize ali procesa. Najpogostejša opažanja inšpektorjev glede pomanjkljivosti s področja kontrole nad metodami in recepturami se nanašajo na preveliko odprtost sistemov do uporabljene metode, ki bi jo lahko vsakdo v vsakem trenutku prilagodil za svoje potrebe. To ni dovoljeno, zato je na sistemu potrebno zagotoviti, da so vse metode in recepture ustrezno zaščitene pred nenadzorovanim prilagajanjem posamezniku, kontrola in morebitne spremembe pa morajo biti delegirane ustrezno usposobljenim zaposlenim, ki odgovarjajo za pravilnost uporabljene metode oziroma recepture. Le tako lahko zagotovimo celovitost pridobljenih rezultatov, katerih vir so ustrezno uporabljeni parametri znotraj metod ali receptur. Ostalih sedem tematik opozorilnih pisem se v analizi pojavi redkeje, vendar gre kljub temu za zelo pomembna in kritična odstopanja. Že dejstvo, da je podjetje zaradi pojava ene ali več preostalih tematik dobilo opozorilno pismo priča o pomembnosti teh tematik. Temeljni vzroki za odstopanje, korektivni ukrepi in predlog za spremembo je tematika, ki je ključna za obvladovanje računalniškega sistema tekom njegovega življenjskega cikla. Podjetja imajo pogosto težavo, da ta področja ne obvladujejo dovolj suvereno oziroma se jih lotijo površno. Kot primer lahko vzamemo odstop na enem izmed računalniško podprtih laboratorijskih sistemov. Podjetje ni prepoznalo temeljnega vzroka za nastanek odstopa (kot so, da zaposleni ni bil izobražen za delo s sistemom, sistem nima ustreznih kontrol, ipd.). Posledično si niso predpisali ustreznega korektivnega ukrepa in pripravili dokumentiranega predloga za spremembo, ki bi dejansko implementiral rešitev, s katero bi preprečili ponovitev odstopa v prihodnosti. Inšpektor je odstopanja od regulatornih zahtev opazil tekom preverjanja odstopov, kar je standardni začetni fokus inšpektorjev tekom presoj v podjetju. Nepooblaščeni dostopi so tematika opozorilnih pisem v primeru, ko v sistem kakovosti računalniških sistemov podjetja še vedno niso implementirala unikatnih osebnih uporabniških imen in gesel. Ugotovitve inšpektorjev kažejo, da uporabniki za delo na računalniškem sistemu uporabljajo generična uporabniška imena in gesla, ki niso osebna in so tako neprimerna za uporabo. V nekaterih primerih inšpektorji opažajo, da prihaja do odstopanj zaradi nezavarovanega dostopa do računalniškega sistema, kar v praksi pomeni, da lahko kdorkoli brez predhodne avtentikacije dostopa do sistema in na njen nenadzorovano opravlja naloge. To so vsekakor odstopanja, ki so relativno hitro in enostavno rešljiva in z vidika izrečenega opozorilnega pisma za podjetje povsem nepotrebna. Trening zaposlenih še ena tematika opozorilnih pisem, kjer bi morala podjetja na dokaj enostaven način vzpostaviti sistem, ki prepreči, da do takšnih odstopov prihaja. Gre za tematiko, ki je za samo podjetje sila neprijetna in zahteva veliko vloženega časa, da se jo uredi, pa vendar gre za nezahteven proces ureditve sistema kakovosti, ki ne zahteva posebnih znanj. Podjetja mora imeti za vse procese v podjetju urejene splošne postopke in navodila za delo, torej nabor dokumentov po katerih morajo biti vsi zaposleni, ki delajo z določenim



stran 44

računalniškim sistemov izobraženi, predno lahko delajo s sistemom. V kolikor zaposleni ni izobražen po enem ali več dokumentov to lahko privede do opozorilnega pisma v večini primerov v kombinaciji še z ostalimi odstopanji. Pri kvalifikaciji opreme gre za neustrezno kvalificiranost opreme, ki je del računalniškega sistema kot celote in je v celoti v domeni skrbnika opreme. Ne kvalificiran sistem lahko napačno izvaja meritve oziroma analize in je posledično neprimeren za uporabo v proizvodne namene. V kolikor posamezni del celote ni ustrezno kvalificiran in validiran pomeni, da računalniški sistem s pripadajočo opremo ni regulatorno skladen in se ga posledično ne sme uporabljati v proivodne namene. Periodični pregledi ustreznosti sistemov potrjujejo, da ima podjetje nadzor nad življenjskim ciklom uporabe računalniškega sistema. V kolikor podjetje ne izvaja periodičnih pregledov računalniških sistemov in internih presoj na teh sistemih, potem ni skladno z regulativo in posledično tvega, da sistem ni ustrezno validiran za svoj namen, kar se lahko odraža v nekakovostnem končnem izdelku. Testne analize, datoteke, mape je tematika, ki se je inšpektorji vse bolj zavedajo in vse bolj preverjajo. Regulatorna zahteva pravi, da ni dovoljena večkratna nedokumentirana izvedba analize/procesa z namenom, da pridemo do ustreznih rezultatov. Vse analize izvedene na posameznem računalniškem sistemu morajo biti ustrezno dokumentirane in tretirane enako kot tista, ki velja kot končna potrditev ustreznosti proizvoda. Vsakršno testiranja z namenom prilagajanja končnih rezultatov niso dovoljena in se lahko odražajo v opozorilnem pismu. Varnostno kopiranje elektronskih zapisov je tematika, ki se v analizi pojavi zgolj 2-krat pa vendar ni nič manj pomembna. Gre za tematiko, ki jo inšpektorji vse pogosteje preverjajo in bo v prihodnosti vedno bolj na udaru. Vsak računalniški sistem mora imeti urejeno varnostno kopiranje vseh elektronskih zapisov generiranih na sistemu. V kolikor to ni urejeno ne moremo zagotavljati pregleda podatkov za nazaj. Varnostno kopiranje elektronskih zapisov je regulatorna zahteva za katerega podjetje v primeru neizvajanja najpogosteje v kombinaciji z ostalimi odstopanji pridobi opozorilno pismo. Če matriko rezultatov analize pojavnosti posamezne tematike v opozorilnih pismih (Priloga 1) razdelimo na časovnico, kjer odstop številka 1 pomeni zadnje opozorilno pismo, številka 50 pa prvo obravnavano in tako najbolj oddaljeno v preteklost (okrog leta 2010) lahko zasledimo določene razlike v dinamiki pojavnosti posamezne tematike. Tematika manjkajoči splošni postopki in validacija sistema se pogosteje pojavlja bolj oddaljeno v preteklosti, nasprotno pa se brisanje in spreminjanje izvornih podatkov ter nepooblaščeni dostopi pogosteje pojavljajo bližje sedanjosti.



stran 45

5 PRIPOROČILA ZA POSAMEZNO TEMATIKO OPOZORILNIH PISEM

V poglavju je prikazana analiza 11-tih tematik v opozorilnih pismih FDA. Gre za subjektivno oceno grupiranja tematik in analize le-teh glede na večletne izkušnje s področja obvladovanja regulatorne skladnosti računalniških sistemov v farmacevtski industriji. Z analizo skušam poiskati izvor ranljivosti, ki pripeljejo do odstopanj od regulatornih zahtev in posledično opozorilnega pisma agencije FDA, ki za podjetje do ureditve razmer pomeni začasno prepoved prodaje izdelkov na ameriškem trgu. Za ključne tematike analize podam priporočila s pomočjo katerih podjetje lahko prepreči oziroma omeji možnost pojava odstopanj na inšpekcijskih pregledih regulatornih agencij. Manjkajoči splošni postopki in validacija sistema je najpogostejša tematika, ki se pojavlja v opozorilnih pismih za računalniške sisteme, vendar jo v poglavju priporočil namenoma izpustim. Podjetje mora namreč najprej urediti preostale tematike, da se lahko celovito loti ureditve dokumentacije in splošnih postopkov. Obratno pa ostalih 10 tematik ne more biti skladnih z regulatornimi zahtevami brez urejene dokumentacije oziroma splošnih postopkov. Posledično je tako urejena tudi validacija računalniških sistemov, s katero računalniški sistem postane skladen z regulatornimi zahtevami. V zadnjem času agencija FDA vse bolj opaža, da validacijska dokumentacija ni več pomanjkljiva in jo počasi jemljejo kot samoumevno in že urejeno v farmacevtskih podjetjih. Zato fokus inšpekcij vse večkrat usmerijo v preostalih 10 obravnavanih tematik.

5.1 BRISANJE IN SPREMINJANJE IZVORNIH PODATKOV Eden izmed ključni izzivov sodobnega farmacevtskega podjetja je zagotoviti integriteto in preprečiti manipulacijo elektronskih zapisov na računalniških sistemih. Večino procesov v podjetju je računalniško vodenih, praktično ni zdravila, ki ne bi imel tekom procesa razvoja in proizvodnje vključenih več različnih računalniških sistemov. Zato je za proizvodnjo kakovostnih in varnih zdravil ključno, da so računalniški sistemi regulatorno skladni in zaščiteni pred manipulacijo elektronskih zapisov, ki jih ustvarjajo. Regulatorni organi, kot so ameriška FDA in evropska EMA zadnjih nekaj let posvečajo vse več pozornosti integriteti elektronskih podatkov. Svoje inšpektorje pripravljajo, da tekom obiskov v farmacevtskem podjetju vse bolj natančno in učinkovito iščejo nepravilnosti in posledice za podjetje v primeru najdenih anomalij so lahko začasna ustavitev proizvodnje in prepoved prodaje na ameriške trge. Da bi podjetja preprečila nepravilnosti, naj si bo namerne ali nenamerne, morajo v preprečitev vložiti dovolj resursov in fokusa, ki pa v časih izrazite konkurence na trgu zdravil pomenijo dodatne stroške, ki si jih veliko podjetji ne more privoščiti. Zato vse pogosteje prihaja do odstopanj od regulatornih zadev in posledično do opozorilnih pisem agencije FDA. Za preprečitev nastanka nepravilnosti mora podjetje v svoji organizaciji vzpostaviti sistem kakovosti, ki temelji na IT strokovnjakih za kakovost in implementacijo rešitev na področju računalniških sistemov. To vejo v farmacevtski stroki imenujemo e-skladnost (ang. e-



stran 46

compliance). Služba e-skladnosti mora poskrbeti za regulatorno skladnost, ki zagotavlja varno in nadzorovano upravljanje z elektronskimi zapisi (krajše e-zapisi) znotraj podjetja. Ker informacijska tehnologija vse bolj napreduje in ker je uporaba le-te vse bolj pogosta in pomembna mora biti sistem kakovosti dovolj robusten, da ne pride do izgube ali manipulacije s podatki. Da bi podjetje doseglo ustrezen nadzor in varnost nad e-zapisi predlagam naslednje ukrepe: 1. Validacija vseh računalniško podprtih računalniških sistemov in

pripadajočih procesov znotraj podjetja. Služba za e-skladnost mora glede na uporabniške zahteve uporabnikov (skrbnikov) računalniških sistemov dokumentirati vse procese in jih ustrezno popisati in potestirati. Vsi koraki morajo biti dokumentirani in ustrezno vodeni skozi življenjski cikel računalniškega sistema. Vse spremembe in dopolnila morajo biti zapeljane skozi dokumentirane predloge za spremembe, morebitni incidenti in odstopi od pričakovanega ustrezno dokumentirani in rešeni na način, da se v prihodnosti ne bodo več ponavljali. Procesi in način dela na računalniških sistemih in pripadajočih procesih morajo biti dokumentirani v splošnih postopkih in navodilih za delo. Ljudje morajo biti po njih dokumentirano izobraženi, pri svojem delu pa jih morajo striktno upoštevati. Vsaka sprememba načina dela oziroma pristopa se mora odražati v reviziji obstoječe dokumentacije skozi dokumentiran predlog za spremembo.

2. Implementacija tehničnih omejitev in varnostnih kontrol na računalniškem sistemu. Ker velika večina računalniških sistemov temelji na okolju Windows (enako velja za bolj redko uporabljen operacijski sistem Linux) mora podjetje poskrbeti za tehnične rešitve, da je sistem zaščiten pred namerno in nemarno manipulacijo e-zapisov. Zaradi omejitev okolja Windows in delovanja posameznih aplikacij, ki krmilijo sisteme, je to pogosto pravi izziv. Sistem ne sme omogočati brisanja ali prepisovanja izvornih podatkov in ostalih e-zapisov. To je pogosto težko doseči, ker okolje Windows tega sam ne zagotavlja. V primeru posega v pravice zapisovanja datotek oziroma podatkov na računalnik lahko pride do nepravilnega delovanja aplikacije. Zato je potrebno e-zapise v realnem času, neodvisno od uporabnika sistema, ki z njim opravlja redno delo (proces), odmikati na varno lokacijo oziroma jih zaščititi pred posegi uporabnikov. To lahko zagotovimo z orodji, ki e-zapis po nastanku odmaknejo na lokacijo, kjer so primerni samo za branje (varna mrežna mapa s pravico za branje, baza podatkov, do katere uporabnik nima dostopa, ipd). Ker pa so te rešitve zelo zahtevne in v nekaterih primerih nestabilne in zato neprijazne do uporabnika se je potrebno implementacije lotiti v skupaj z uporabniki sistemov in upoštevati njihovo mnenje in zadržke. Na trgu obstaja nekaj specializiranih podjetji, ki ponujajo rešitve, ki e-zapise po nastanku na računalniškem sistemu pravilno hranijo oziroma jih premaknejo v varno in nadzorovano okolje. Zato predlagam, da podjetje prepozna računalniške sisteme, ki niso ustrezni z vidika regulatornih zahtev shranjevanja in hranjenja e-zapisov in jih že v fazi implementacije prilagodi in pravilno implementira v interno okolje podjetja. To storimo s pomočjo proizvajalca sistemov in zunanjih specialistov, ki ponujajo rešitve, ki e-zapise ustrezno upravljajo in zaščitijo.



stran 47

3. Integracija kulture kakovosti uporabnikom računalniških sistemov, da ustrezno obvladovanja e-zapisov prepoznajo kot ključen del razvoja in proizvodnje varnih in kakovostnih zdravil. Da bi tehnično implementirane kontrole ustrezno funkcionirale se morajo uporabniki računalniških sistemov zavedati pomena varnosti in integritete e-zapisov s katerimi opravljajo tekom razvoja in proizvodnje zdravil. Zato jih moramo periodično izobraževati v smeri, da integriteto e-zapisov integrirajo v svojo kulturo kakovosti in da zavedno in pravilno sledijo vsem navodilom in implementiranim postopkom s strani službe za e-skladnost. Enako velja za višje vodstvo in lastnike, ki morajo delovati kot promotorji kulture kakovosti. Le tako lahko podjetje pride do stopnje, da vsi zaposleni razumejo pomembnost zagotavljanja integritete e-zapisov na računalniških sistemih in jih dosledno upoštevajo.

5.2 ZGODOVINA DOGODKOV Zgodovina dogodkov, ki zagotavlja beleženje vseh sprememb na računalniškem sitemu je poleg preprečitve manipulacije z e-zapisi ključna za zagotavljanje integritete e-zapisov na računalniških sistemih. Evropska agencija EMA zahteva, da se na podlagi ocene rizikov obvezno sistemsko sledi zgodovini dogodkov za vse spremembe, ki se zgodijo na računalniškem sistemu. Zgodovina dogodkov na računalniškem sistemu mora biti vedno na voljo za pregled in redno periodično pregledana (EMA, 2011). Tekom validacije računalniškega sistema je potrebno na sistemih implementirati sledenje zgodovine dogodkov, nastali e-zapisi pa morajo biti ustrezno zaščiteni. Zgodovina dogodkov mora biti s strani odgovornih oseb, v večini primerov gre za skrbnika računalniškega sistema, periodično pregledana za morebitne ponavljajoče se trende, ki nakazujejo nepravilnosti pri delovanju oziroma uporabi sistema. Odkrite nepravilnosti se mora glede na vpliv na proces dokumentirano voditi kot incident ali odstop. Periodični pregled zgodovine dogodkov zna biti zamuden in zahteven proces zato predlagam ustrezen pristop pregleda na podlagi ocene rizikov za posamezen računalniški sistem. Bolj visoko kot so ocenjeni riziki za računalniški sistem (pomembnost za proces, ipd.) bolj obsežen in pogost naj bo periodični pregled zgodovine dogodkov na računalniškem sistemu.

5.3 KONTROLA NAD RECEPTURAMI ALI METODAMI Neustrezna kontrola nad recepturami ali metodami, na podlagi katerih računalniški sistem izvede analizo oziroma proces pomeni tveganje, da izvedba procesa na sistemu ne bo optimalna ali bo celo nepravilna. V kolikor nimamo kontrole nad vhodnimi parametri delovanja računalniško podprtega sistema ne moremo z gotovostjo trditi, da je bila analiza ali proces pravilno izvedena. Zato je ključno, da tekom validacije računalniškega sistema poskrbimo za ustrezno zaščito receptur oziroma metod. Proces dela na računalniškem sistemu moramo definirati tako, da avtor metodo zaklene ali kako drugače zaščiti in z elektronskim podpisom potrdi vsebino metode. V kolikor računalniški sistem ne podpira takšnega nivoja zaščite le-to definiramo preko ustreznih procedur nadzora nad metodami oziroma recepturami, ki bo zagotavljal, da bodo vhodni parametri pravilni in nadzorovani pred in po izvedbi procesa. Tako zagotovimo, da uporabnik računalniškega sistema proces na sistemu kontrolirano izvede in posledično takšna izvedba procesa ali analize zagotavlja zanesljive rezultate katerim je moč zaupati.



stran 48

5.4 ODSTOPANJE, KOREKTIVNI UKREPI IN PREDLOG ZA SPREMEMBO Nadzor nad odstopi, korektivnimi ukrepi in predlogi za spremembo tekom življenjskega cikla so ključni pojmi zagotavljanja skladnosti računalniškega sistema v primeru odstopanj od pričakovanega. Da bi v primeru pojava odstopanj od pričakovanega zagotovili nemoteno delovanje računalniškega sistema oziroma njegovo čim hitrejšo ponovno uporabo moramo vsa odstopanja temeljito preučiti, si predpisati ustrezne korektivne ukrepe in po potrebi pripraviti predlog za spremembo na računalniškem sistemu, ki bi preprečil ponavljajoče se odstope. Vse aktivnosti morajo biti ustrezno dokumentirane, usklajene in potrjene s strani oddelka zagotavljanja kakovosti (e-skladnost). Ko zabeležimo odstop na računalniškem sistemu in/ali na pripadajočem procesu, ga moramo v najkrajšem možnem času dokumentirati, ustrezno ovrednotiti, izvesti takojšne korektivne ukrepe v kolikor je to potrebeno za nadaljne delovanje računalniškega sistema in ugotoviti izvorni problem, ki je pripeljal do odstopa. Ko je odstop dokumentiran lahko začnemo z iskanjem korektivnih ukrepov, ki so nujni za preprečevanje odstopanj v prihodnosti. Za nastali odstop moramo poiskati ustrezno rešitev ali dopolnilo k obstoječemu stanju, ki bo preprečila odstop v prihodnosti. Korektivni ukrep je lahko na primer dodatna kontrola preverjanja parametrov tekom procesa, dodatna zaščita računalniškega sistema, ponovno izobraževanje uporabnikov sistema, ipd. Korektivni ukrep mora biti dokumentiran, usklajen z vsemi deležniki in potrjen s strani osebe odgovorne za kakovost. V primeru, da gre za odstop, ki ima za korektivni ukrep aktivnost, ki jo je potrebno voditi skozi predlog za spremembo, je potrebno z vsemi deležniki pripraviti predlog za spremembo, ki ga referiramo na odstop. Spremembo moramo ustrezno dokumentirati in implementirati. Z implementacijo spremembe se tako zaključijo vse formalne aktivnosti okrog reševanja odstopa. Ključno pri opisanih procesih je, da vse korake ustrezno dokumentiramo v zato namenjeni aplikaciji v podjetju, da so vse aktivnosti usklajene in potrjene s strani vseh deležnikov (uporabnik, skrbnik sistema, IT podpora, kontrola kakovosti, e-skladnost, itd.) in po planu izvedene. Ko se pojavi odstop, ga je potrebno najhitreje prepoznati, dokumentirati, izvesti vse potrebne korektivne ukrepe in po potrebi pripraviti predlog za spremembo. Inšpektorji namreč zelo natančno preverjajo odstope in posledično tudi vse aktivnosti, ki sledijo. Zato naj bo fokus podjetja na dokumentiranju in upravljanju odstopov in aktivnostih, ki sledijo, na vrhu liste prioritet za zagotavljanje skladnosti računalniških sistemov.

5.5 NEPOOBLAŠČENI DOSTOPI Nepooblaščeni dostopi do računalniškega sistema, kot so uporaba generičnih računov skupine uporabnikov, deljenje gesel med uporabniki, izklopljeno preverjanje identitete uporabnika na računalniškem sistemu, niso skladni z regulatornimi zahtevami in so lahko povod za večja odstopanja oziroma opozorilna pisma. Vsak uporabnik mora imeti za dostop do računalniškega sistema edinstveno uporabniško ime in geslo, ki ga sme uporabljati samo on in ga ne sme deliti z ostalimi uporabniki. Uporabniško ime uporabljeno za namen elektronskega podpisa



stran 49

v procesu uporabe računalniškega sistema je ekvivalentno ročnemu podpisu, zato je zelo pomembno, da imajo vsi uporabniki zavedanje kako pomembna je uporaba edinstvenih uporabniških imen in gesel. Vsakršno zlorabo je relativno lahko odkriti z navzkrižnim preverjanjem dostopov na sistemih s sistemom za beleženje prisotnosti zaposlenega v podjetju ali v posameznem prostoru.

5.6 PRIPOROČILA ZA OSTALE TEMATIKE Kljub temu, da se preostalih pet tematik v opozorilnih pismih agencije FDA pojavi najmanjkrat niso nič manj pomembna in neupoštevanje regulatornih zahtev za ta področja lahko pripelje do opozorilnega pisma. Trening zaposlenih je tesno povezan z tematiko manjkajočih splošnih postopkov, ki se skupaj z validacijo sistema najpogosteje pojavi v opozorilnih pismih. Vsi zaposleni, ki delajo na določenem računalniškem sistemu in procesih povezanih z njimi morajo biti izobraženi po navodilih za delo in splošnih postopkih, ki jih mora podjetje pripraviti tekom implementacije (validacije) procesa dela na računalniškem sistemu. Podjetje mora imeti vzpostavljen interni sistem izobraževanja, ki temelji na bazi dokumentov po katerih morajo biti uporabniki izobraženi, da lahko delajo z določenim sistemom/procesom. Izobraževanja morajo biti dokumentirana, dokazila o njih pa hranjena za inšpekcijske preglede. V kolikor zaposleni ni izobražen po vseh postopkih za delo z računalniškim sistemom ne sme pridobiti avtorizacij za delo z sistemom. Za nadzor sta odgovorna uporabnikov nadrejeni in vsebinski skrbnik sistema. Zaposleni lahko formalno dela s sistemom takrat, ko je dokumentirano izobražen po vseh dokumentih, ki so potrebni za delo z računalniškimi sistemi in povezanimi procesi. Kvalifikacija opreme je potrditev pravilnega delovanja instrumenta v kombinaciji z računalniškim sistemov, najpogosteje s strani uradnega zastopnika oziroma serviserja. Skrbnik posameznega sistema je odgovoren za izvedbo prve in vseh nadaljnjih periodičnih kvalifikacij opreme in hranjenje dokumentacije, ki dokazuje ustreznost opreme za delo v produkcijskem okolju. Kvalificirana oprema je pogoj za izvedbo interne validacije računalniškega sistema, ki ga sestavljata oprema in aplikacija, ter uporabo računalniškega sistema v produkcijske namene. Vsa oprema mora biti pred in med produkcijsko uporabo ustrezno periodično kvalificirana, računalniški sistem v kombinaciji z opremo pa ustrezno validiran. Le v tem primeru lahko sistem uporabimo za produkcijske namene. Periodični pregledi ustreznosti sistemov. Vsi računalniški sistemi v farmacevtski industriji morajo biti periodično pregledani na ena do tri leta, odvisno od kritičnosti in ocene rizika sistema. Pri periodičnem pregledu preverimo vse ključne komponente vzpostavljene tekom validacije računalniškega sistema, izobraženost avtoriziranih uporabnikov za delo s sistemom, delovanje in vsebino zgodovine dogodkov, ipd. Za izvedbo periodičnega pregleda računalniškega sistema je odgovorna IT podpora in skrbnik sistema. Periodični pregled mora biti ustrezno dokumentiran, z dodanimi dokazi o pregledih posameznih komponent in odobren s strani osebe odgovorne za e-skladnost. Neizvajanje ali pomanjkljivo izvajanje periodičnih pregledov lahko pomeni večje tveganje za nepravilno delovanje sistema.



stran 50

Testne analize, datoteke, mape so bližnjice za izvedbo procesa ali analize na računalniškem sistemu in so strogo prepovedane. Da bi uporabnik prišel do željenih rezultatov si na računalniškem sistemu pripravi testne mape ali opravi testne analize, ki jih ne zavede v uradno evidenco analiz. To ni skladno z regulativo in v praksi pomeni goljufanje, da bi do željenega cilja prišel po hitrejši in enostavnejši poti. Da bi preprečili takšno ravnanje moramo sistem tekom validacije računalniškega sistema tehnično zavarovati, da uporabnik nima možnosti kreiranja testnih map in datotek v nenadzorovanem delu sistema in ga ustrezno izobraziti, ter vpeljati procedure za preprečevanje manipulacij. V celoti anomalij nikoli na moremo omejiti z nastavitvami računalniškega sistema, zato je ključno osveščanje in izobraževanje vseh uporabnikov računalniških sistemov kako pomembno je, da se na sistemih vsi procesi in aktivnosti vodijo kontrolirano, brez skrivanja in manipulacij. Takšno ravnanje ima namreč za posledico izgubo službe na strani uporabnika ter odstop od regulatornih zahtev na strani podjetja. Varnostno kopiranje elektronskih zapisov. Z uporabo sistemov na elektronski način kjer so elektronski zapisi edini dokaz opravljenega dela je varnostno kopiranje elektronskih zapisov eden izmed ključnih faktorjev zagotavljanja regulatorne skladnosti na računalniških sistemih. Vsak računalniški sistem oziroma elektronski zapisi morajo biti periodično varnostno kopirani. Perioda varnostnega kopiranja naj bo odvisna od kritičnosti sistema ali ocene rizikov kritičnosti izgube elektronskih podatkov. Za večino sistemov je ta perioda 1x na dan, lahko pa se ustrezno zmanjša za najbolj kritične in vitalne računalniške sisteme v podjetju. Proces varnostnega kopiranja naj bo ob implementaciji in validaciji sistema ustrezno testiran in dokumentiran in nato samo delovanje tudi periodično pregledano v sklopu rednih periodičnih pregledov. Za bolj kritične sisteme se priporoča tudi tekoče spremljanje uspešnosti izvedbe varnostnega kopiranja, ki v primeru nedelovanja hitro in učinkovito prepozna nedelovanje varnostnega kopiranja in ga tako tudi hitreje odpravi.

5.7 SKLEPNA ANLIZA TEMATIK OPOZORILNIH PISEM V prejšnjih poglavjih sem glede na pridobljene izkušnje v realni farmacevtski organizaciji opravil subjektivno analizo 11 tematik, ki so se najpogosteje pojavljale v opozorilnih pismih ameriške agencije FDA. Za vsako tematiko sem na kratko opisal izvor problema in podal predloge in dejstva, ki bi lahko podjetju pomagala pri preprečevanju nepravilnosti in bolj učinkoviti pripravi na inšpekcijske preglede regulatornih organov za področje računalniških sistemov. S tabele v Prilogi 1 lahko razberemo trende pojavnosti posamezne tematike v opozorilnih pismih. V tabeli opozorilno pismo številka 1 pomeni zadnje oziroma najbolj aktualno opozorilno pismo iz leta 2015, številka 50 pa najstarejšega iz leta 2010. Iz kronološke analize tematik opozorilnih pisem agencije FDA podjetjem je razvidna nesorazmerna porazdelitev pojavnosti posamezne tematike glede na čas. Medtem ko se tematika »Manjkajoči splošni postopki, validacija sistema« pojavlja sorazmerno enakomerno skozi celoten čas med letoma 2010 in 2015 se tematika »Brisanje in spreminjanje izvornih podatkov« veliko bolj intenzivno pojavlja v zadnjem obdobju. Enako velja za tematiki »Zgodovina dogodkov« in »Nepooblaščeni dostopi« iz česar lahko sklepamo, da so omenjene tri tematike za inšpektorje večja prioriteta kot so bile pred leti. Vse to nakazuje, da je fokus



stran 51

inšpektorjev vse bolj usmerjen na obvladovanje in varnost elektronskih zapisov, predvsem varno hrambo zapisov in nadzor nad njimi. Bolj in bolj pogosto inšpektorji opazijo nepravilnosti, kot so brisanje podatkov, manipulacija podatkov, manjkajoča zgodovina dogodkov, nepravilnosti s dostopi do računalniških sistemov, ipd. To kaže, da se prioriteta pregledov računalniških sistemov tekom inšpekcijskih pregledov v farmacevtskem podjetju veča. Razlog zato je predvsem v vse večji osveščenosti, izobraženosti in pripravljenosti inšpektorjev za takšne naloge (govor g. Takahashi leta 2015 na zasedanju FDA). To pomeni, da bodo morala podjetja vse več svojih resursov nameniti oddelkom IT podpore in e-skladnosti, ki lahko preprečijo pojav odstopanj pri omenjenih tematikah. Ključno je, da podjetje najde vzvode in rešitve, ki bodo pripeljali do regulatorno skladnih računalniških sistemov:

- zaposlitev zadostnega števila strokovnjakov za področje računalniških sistemov in kontrole kakovosti s področja e-skladnosti,

- najem zunanjih svetovalcev z dolgoletnimi izkušnjami s področja skladnosti računalniških sistemov, ki poznajo problematiko in lahko ponudijo nabor rešitev za regulatorno skladno delovanje sistema,

- celovita kvalifikacija in validacija računalniškega sistema s pripadajočo opremo,

- natančni splošni postopki za delo s sistemom, - tehnična zaščita računalniških sistemov za preprečitev manipulacij,

namernih in nenamernih (zaščita elektronskih zapisov pred brisanjem, zaščiteni dostopi do sistemov z uporabniškimi imeni in gesli, ipd.),

- dokumentirana in periodično pregledana zgodovina dogodkov, ki natančno pokaže kondicijo računalniškega sistema, primerjava ugotovitev z dokumentacijo in splošnimi postopki ter implementacija morebitnih sprememb,

- natančno in dokumentirano vodenje incidentov in odstopov na računalniškem sistemu: vsak incident naj bo dokumentiran in rešen s poudarki na ponavljajočih se incidentih; vsa odstopanja naj imajo ugotovljen izvorni problem, definirane korektivne ukrepe in predloge za spremembe v kolikor so potrebni,

- vsi zaposleni naj bodo ustrezno izobraženi za delo na računalniškem sistemu, proces treninga naj bo ustrezno dokumentiran,

- vse uporabnike naj se redno periodično izobražuje in opozarja na pomembnost kakovostnega ravnanja na vseh področjih njihovega dela, tudi na računalniških sistemih,

- zaveze in predvsem ravnanje vodstva naj bo vzor vsem zaposlenim, da bodo v njihovem ravnanju našli motivacijo za pravilno in kakovostno delo v laboratoriju, proizvodnji, pisarni ali pa direktno na računalniškem sistemu,

- ker vseh rešitev in varovalk na računalniškem sistemu IT strokovnjaki ne morejo zagotoviti s tehničnimi omejitvami in nadzorom, je ključno zavedanje uporabnikov, da je njihovo kakovostno in pravilno rokovanje s procesi in samim računalniškim sistemom ključno za uspešno in regulatorno skladno delo.

Z dosledno implementacijo in upoštevanjem naštetih ukrepov tekom življenjskega cikla uporabe računalniškega sistema se lahko podjetje nadeja, da regulatorni organi ne bodo imeli razloga za dodelitev opozorilnega pisma, ker le-to razume



stran 52

regulatorne zahteve in jih dosledno upošteva v vseh porah organizacije. Takšno podjetje se bo v vse bolj konkurenčni farmacevtski industriji lahko osredotočilo na svojo primarno poslanstvo: razvoj in proizvodnjo visoko kakovostnih in varnih zdravil za paciente, ki jih potrebujejo.

6 ZAKLJUČEK V magistrski nalogi so v prvem teoretskem delu razloženi osnovni pojmi, povezani z zagotavljanjem regulatorne skladnosti računalniških sistemov v farmacevtski industriji. To področje je zelo kompleksno in pomembno za farmacevtsko podjetje. Teoretični del naloge opisuje zagotavljanje skladnosti računalniškega sistema glede na regulatorne zahteve, proces implementacije in validacije računalniškega sistema na primeru realne organizacije in načine za vzdrževanje validiranega stanja. Predstavljeni so vsi potrebni koraki za validacijo in vzdrževanje računalniškega sistema v farmacevtskem podjetju glede na regulatorne zahteve. Razložen je termin odstop oziroma odstopanje v farmacevtski industriji. Odstopanja so lahko prepoznana na notranjih ali zunanjih inšpekcijskih pregledih. Pri validaciji in vzdrževanju računalniškega sistema je poudarjeno obvladovanje podatkov in zagotavljanje njihove integritete (natančni, varnostno kopirani, ipd.), ponovljivost validiranih procesov, ocena rizikov in pomen uporabniških zahtev, ki naj bodo točne in fokusirane na proces. S pristopom opisanim v teoretskem delu naloge dosežemo učinkovitejše priprave in uspešnejšo izvedbo zunanjih presoj s poudarki na najpogosteje obravnavanih tematikah opozorilnih pisem opisanih v praktičnem delu naloge. V praktičnem delu naloge je analiziranih zadnjih 50 opozorilnih pisem agencije FDA s področja računalniških sistemov v farmacevtski industriji. Vsebina opozorilnih pisem je razdeljena na 11 področij, ki se pojavijo v vsaj enem izmed 50 opozorilnih pisem. Pojavnost posameznega področja odstopanja je predstavljena empirično (frekvence), prav tako smo posameznim področjem opredelili pomembnost. Največkrat opažena področja so: »Manjkajoči splošni postopki, validacija sistema« in »Brisanje in spreminjanje izvornih podatkov«. V prvem primeru gre za pomanjkljivo dokumentacijo, ki je težava, s katero se sooča veliko podjetji. V drugem primeru pa gre za ključno težavo brisanja in spreminjanja podatkov, čemur se inšpektorji vse bolj posvečajo. Z analizo področij lahko podjetje dobi smernice, kam naj usmerijo vire za preventivne aktivnosti pred inšpekcijskimi pregledi regulatornih organov. V kolikor podjetje ne uspe urediti kakovosti računalniških sistemov do nivoja, ki ga zahtevajo regulatorni organi, tvega zaznana odstopanja ali, še huje, opozorilna pisma. Posledica slednjih je lahko za podjetje uničujoča z vidika stroškov in ugleda. Zato je zelo pomembno, da se vsi zaposleni, od operaterja v proizvodnji do direktorja uprave zavedajo pomembnosti upravljanja kakovosti, tako računalniških sistemov kot kateregakoli drugega področja v farmacevtskem podjetju. Kakovost se namreč začne pri ljudeh in šele nato odraža na kvalitetnih proizvodih.



stran 53

LITERATURA

- Darshit S. Patel (2012). FDA WARNING LETTER ANALYSIS: A TOOL FOR GMP COMPLIANCE, str. 4592 – 4603, IJPSR.com., 2012.

- ECA (2012). Delovno gradivo s seminarja: ECA - Computer validation – Introduction to Risk Management & The GAMP 5 Approch, Copenhagen, 2012.

- ECA (2013). Delovno gradivo s seminarja: ECA – Computer Validation – Maintaining Control of Operation, Barcelona, 2013.

- EduQuest (2015). Comparison of FDA’s Part 11 and the EU’s Annex 11 dostopno na http://www.eduquest.net/Advisories/Comparison%20of%20FDA%20Part%2011%20and%20EU%20Annex%2011.pdf dne 14.10.2015

- EMA (2011). Annex 11: Computerised Systems, EUROPEAN COMMISSION HEALTH AND CONSUMERS DIRECTORATE-GENERAL, Bruselj, 2011.

- FDA (2002). General Principles of Software Validation; Final Guidance for Industry and FDA Staff issued January 11, 2002 http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm085371.pdf

- FDA (2011). FDA Overview. Amerika, 2011. - FDA (2014). Warning letter WL: 320-15-04 , dostopen na

http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/ucm427976.htm dne 13.9.2015

- FDA (2015). Warning letter WL: 320-15-12, dostopen na http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/2015/ucm455345.htm dne 13.9.2015

- FDA (2015). Warning letter WL: 320-15-05 dostopen na http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/ucm431456.htm dne 13.9.2015

- FDA (2015). What does FDA do? dostopno na http://www.fda.gov/AboutFDA/Transparency/Basics/ucm194877.htm dne 28.9.2015

- Takahashi K. (2015). FDA 2014 Annual meeting in Las Vegas speech, dostopen na https://www.pharmamedtechbi.com , 2015.

- FDA (2015). Warning letters, dostopno na http://www.fda.gov/ICECI/ComplianceManuals/RegulatoryProceduresManual/ucm176870.htm dne 26.8.2015

- GAMP 5 (2007). GAMP5 A Risk-Based Approach to Compliant GxP Computerized Systems, 2007.

- Kovač, S. (2010). Model implementacije direktiv za IT v življenjskem ciklu programske opreme, Magistrsko delo, Fakulteta za organizacijske vede, Kranj, 2010

- LabCompliance (2015). Webinar: Learning from Recent Warning Letters related to Part 11 and Computer Validation, Amerika, 2015.

- LabCompliance (2015), FDA Warning Letters, Form 483 Observations, Establishment Inspection Reports, dostopno na http://www.labcompliance.com/login/usersclub/fda_483_8485we.aspx dne 26.8.2015

- Lek (2011). Interno gradivo: Validacija računalniško podprtih laboratorijskih sistemov, Lek d.d., 2011

http://www.eduquest.net/Advisories/Comparison%20of%20FDA%20Part%2011%20and%20EU%20Annex%2011.pdf

http://www.eduquest.net/Advisories/Comparison%20of%20FDA%20Part%2011%20and%20EU%20Annex%2011.pdf

http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm085371.pdf

http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm085371.pdf

http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/ucm427976.htm

http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/ucm427976.htm

http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/ucm427976.htm%20dne%2013.9.2015






http://www.fda.gov/AboutFDA/Transparency/Basics/ucm194877.htm%20dne%2028.9.2015

http://www.fda.gov/AboutFDA/Transparency/Basics/ucm194877.htm%20dne%2028.9.2015

https://www.pharmamedtechbi.com/

http://www.fda.gov/ICECI/ComplianceManuals/RegulatoryProceduresManual/ucm176870.htm%20dne%2026.8.2015

http://www.fda.gov/ICECI/ComplianceManuals/RegulatoryProceduresManual/ucm176870.htm%20dne%2026.8.2015

http://www.labcompliance.com/login/usersclub/fda_483_8485we.aspx%20dne%2026.8.2015

http://www.labcompliance.com/login/usersclub/fda_483_8485we.aspx%20dne%2026.8.2015



stran 54

- Lek (2013). Interno gradivo: Validacija računalniških sistemov v Lek d.d., Lek d.d., 2013

- Lek (2013). Interno gradivo: Upravljanje z incidenti računalniških sistemov, Lek d.d., 2013

- Lek (2015). Interno gradivo: Obvladovanje odstopov od dobre proizvodne prakse, Lek d.d., 2015

- Lek (2015). Interno gradivo: Zunanja in notranja presoja sistema kakovosti, Lek d.d., 2015

- PIC/S GUIDANCE (2007). GOOD PRACTICES FOR COMPUTERISED SYSTEMS IN REGULATED “GXP” ENVIRONMENTS, stran 8

KAZALO SLIK Slika 1 Shema računalniškega sistema v operativnem okolju v farmacevtski industriji (PIC/S GUIDANCE, 2007) ......................................................... 4 Slika 2 Življenjski cikel validiranega sistema (Lek, 2013)............................... 8 Slika 3 Validacija računalniškega sistema kategorije 4 po "V" modelu (GAMP 5, 2007) ........................................................................................... 12 Slika 4 Shema procesa dokumentiranja in reševanja incidenta na računalniškem sistemu (Lek, 2013) .......................................................................... 22 Slika 5 Prikaz aktivnosti periodičnega pregleda glede na posamezne korake (GAMP5, 2007)................................................................................ 25 Slika 6 Proces uvajanja spremembe na računalniškem sistemu (GAMP 5, 2007) .. 28 Slika 7 Prikaz težave prepisovanja obstoječih datotek v okolju Windows. ......... 41 Slika 8 Primer zgodovine dogodkov prijav in sprememb na računalniškem sistemu. ................................................................................................. 42

KAZALO TABEL

Tabela 1 Navzkrižna primerjava 21 CFR PART 11 direktive ameriške agencije FDA z direktivo Annex 11 evropske agencije EMA po posameznih poglavjih glede na vsebino in razlike med poglavji (EduQuest, 2015). ....................................... 7 Tabela 2 Kategorizacija računalniških sistemov po GAMP 5 (GAMP 5, 2007) ..... 11 Tabela 3 Razporeditev pojavnosti posameznih tematik zadnjih 50 opozorilnih pisem agencije FDA na temo računalniških sistemov razvrščeno glede na število pojavov posamezne tematike. ........................................................................ 39



stran 1

PRIOLOGA 1