Stage One Computing. Forfattet af Christian Stage 2010/06. Public information. Author Christian Stage Template None

Transkript

1 IT Compliance RoadMap Et whitepaper om hvad GxP i IT afdelingen er. Validering af basis IT systemer og netværk (ikke IT produktvalidering softwareprodukter/applikationer) Forfattet af Christian Stage 2010/06 Introduktion Generelt er det vigtigt når man betragter IT systemer at tage stilling til om de er kritiske i forhold til GxP eller ej. Omvendt kan man blot betragte GxP som en metode til at sikre at der er styr på virksomhedens proces. I forbindelse med IT systemer kan man derfor ikke 100% frasige sig at indførelse af GxP også kan være en driftmæssig fordel. Det giver god mening at have en bestillingsseddel hver gang man skal have oprettet et nyt IT system, eller hvis man justerer på et eksisterende IT system. Det giver IT eksperten mulighed for at dimensionere og oprette et IT system der både passer ind i virksomheden, og lever op til brugerens krav. Samtidig kan dette også betragtes som en GxP Change Control (ændringssag). I praksis er mange af disse metoder allerede implementeret i virksomheden, og det er således for en stor dels vedkommende blot at kigge på det med GxP øjne, og beskrive hvordan den eksisterende dokumentation, opfølgning, risikovurdering etc. indgår i GxP sammenhæng. Man skal endvidere sørge for at have disse dokumenter direkte tilgængelige. Det hele kan naturligvis laves mere eller mindre kompliceret, men som udgangspunkt er få dokumenter lettere at overskure og forklare end mange, og en ensartet, strømlignet, fordelagtig og operativ struktur er meget lettere at få medarbejderne til at følge, end en ulogisk, teoretisk, besværlig eller hypotetisk fremgangsmåde. Først lidt om GxP Denne forklaring er ikke taget med for at tale ned til folk der i reglen godt ved hvad GxP er. Formålet er at fjerne nogle af de myter der findes omkring GxP som koncept, og derved gøre det mindre farligt end det nogen gange bliver gjort. GxP er et begreb der omfatter laboratorier, kliniske forsøg, produktion, lager, distribution etc. indenfor produktionen af lægemidler, samt udstyr til medicinsk brug. Afhængigt af område skiftes det lille x ud med et bogstav der passer til området (f.eks. M for Manufacturing produktion). GxP er i hovedsagen opstået som følge af skandalesager (f.eks. Thalidomid i 60 erne), manglende kontrol (omkring 1900 tallet skulle man som det eneste bevise at man troede på sin egen medicin - Deraf ordsproget at tage sin egen medicin ) og skrupelløse virksomheder. Myndighederne har stået magtesløse og ikke haft regelsæt at binde producenterne op på. Konceptet går ud på at myndighederne hver gang man møder et problem, laver regler der kan benyttes til at undgå disse problemer i fremtiden. Som virksomhed er man nødsaget til at læse og fortolke myndighedernes regler i forhold til ens egen virksomhed, og de produkter man producerer. At være i kontrol For at sikre GxP drift der benytter IT og infrastruktur, er det vigtigt at det IT backbone man benytter også er i compliance. Udtrykket Compliance er Engelsk og betyder at man kan leve op til GxP kravene. GxP kravene er at man skal være i kontrol, hvilket betyder at IT systemet også skal være i kontrol. Page 1 of 6

2 Generelt kan man sige at myndighedernes beskrivelse af det at være i compliance med IT systemer er meget spinkelt beskrevet, og når man taler om IT backbone systemer, er forventningerne endnu mere uldne. Reglerne er også næsten altid generiske (der skal være tilstrækkelig belysning) i stedet for specifikke (der skal være 1500 lumen). Det betyder at stillingtagen er et af nøgleordene for GxP. I dette dokument vil vi dog forsøge at beskrive de forventninger der er til at være i compliance med et IT backbone system. Det er vores råd og opfattelse af virkeligheden. Emner der er vigtige for at være i kontrol Det at være i kontrol er naturligvis op til fortolkning, men en række emner indgår som minimum i det at være i kontrol med hensyn til et IT system, og bør alle overvejes/-kommenteres da disse kommer til at danne grundlag for ens senere beslutninger: Change Control o Ændringsstyring o Konfigurationsstyring o Like-for-like Brugeradministration o Oprettelse o Nedlæggelse o Træning o Eksterne leverandører Audits o Interne audits af compliance o Audits af eksterne leverandører Validering af netværk o Netværk o Firewalls Validering af systemer o Servere o Operatørstationer o Andet udstyr Backup o Backup o Restore o Definition af restore points o Disaster recovery o Tilslutning af et nyt system (klient) til backup systemet o Test af backup/restore/disaster recovery o Mediehåndtering Dataretention o Nødvendighed samt omfang af dataretention o Definition af retentionsperiode o Nedlæggelse af data ved udløb af dataretentionsperiode Ændringer i IT systemer o Standardiseret risikoanalyse o Firmware opgraderinger o Patchning af systemer o Versionsopgradering o Opdatering af antivirus, firewalls etc. o Oprettelse af nye systemer o Nedlæggelse af gamle systemer o Serviceaftale mellem bruger og IT afdelingen Vedligehold af IT systemer o Komprimering af data i databaser o Udvidelse af volumener/ekstra diskvolumener Page 2 of 6

3 o Defragmentering af data/databaser Definition af GxP og Non-Gxp o Hvordan skelnes der mellem GxP og Non-GxP o Oversigt over GxP data og systemer o Hvordan håndteres 2 forskellige sæt procedurer (GxP og Non-Gxp) En væsentlig del af disse emner er uhyre simple at vurdere, men alle emnerne indgår som ingrediens i god compliance. Det er vigtigt at vurdere hvert enkelt ingrediens, og det er helt OK at definere en ingrediens som uinteressant eller ikke benyttet i vriksomheden. De vurderinger og tilhørende rationaler skal skrives ned således at de senere er tilgængelige. Hvis man laver denne vurdering på skrift er man allerede godt på vej imod compliance fordi man ved hvad gælder og baggrunden for at foretage sig det man gør. Man er kort sagt i kontrol. Vaideringsplanen En fornuftig fremgangsmåde der både afspejler og lever op til myndighedernes krav er at starte med en plan for hvordan man opnår compliance. Dette kaldes en valideringsplan og indeholder alt omkring den dokumentation der udarbejdes for systemerne, en beskrivelse af hvordan systemerne testes, samt en forklaring på hvordan man bibeholder det validerede stade. Som udgangspunkt er det fordelagtigt at lave en mere detaljeret beskrivelse på dette sted frem for en mindre detaljeret beskrivelse. Årsagen er at vailderingsplanen er bageopskriften som alle kigger på bagefter. En inspektør vil typisk starte med valideringsplanen, en medarbejder vil søge svar på sine spørgsmål etc.. Hvis alting er afklaret allerede i valideringsplanen, opstår der ikke senere spørgsmål. Valideringsplanen er et værktøj, som skal bruges. Det skal være her man leder efter metoder og finder der overvejelser og beslutninger der ligger til grund for enhver opgave indenfor et specifikt valideringsscope. Valideringsplanen kan endvidere benyttes som værktøj for at sikre mindst mulig indsats for at opnå compliance. Generelt kan man sige at den tid man bruger på valideringsplanen er givet godt ud. Hvis man blot kører derudaf uden en plan ender man oftest med at bruge markant meget mere tid på validerings- og complianceindsatsen, end man ellers ville gøre. Valideringsplanen indeholder typisk følgende emner: Indhold og omfang Projekt- eller systembeskrivelse Roller og ansvarsfordeling Projektdeltagere/roller for systemet (evt. inklusive referencer til træning og CVer) Håndtering af eventuelle leverandører/underleverandører Træning o Forventning til træningsomfang for interne og eksterne projektmedarbejdere o Forventning til træningsomfang for brugere Projektfaser og tidsplan Risikoanalyse (teknisk, tidsmæssig og procesmæssig) Grænseflader og kritikalitet ifht. andre systemer Dokumentation o Beskrivelse af hvilken dokumentation der indgår i valideringssammenhæng o Opdatering af eksisterende dokumentation, herunder SOPer o Nye dokumenter Test o Pre-test aktiviteter o Kvalificerende test Page 3 of 6

4 o Andre testaktiviteter Afleveringsforretning Arkivering End-of-life betragtninger (særdeles vigtige for IT systemer) Maintaining the vaildated state Referencer generelle for hele projektet Ændringslog Procedurer Det næste der skal ske er udarbejdelse af de nødvendige procedurer. Myndighederne forventer skrevne procedurer, og procedurer på skrift gør det let at overlevere opgaver samt at træne medarbejdere og konsulenter. Hvis man vil gøre det let for sig selv, lader man procedurerne beskrive den arbejdsgang der er i virkeligheden, og ikke som man tror de er. Det er ikke fornuftigt at skrive teoretiske procedurer der beskriver en hypotetisk arbejdsgang, fordi det på den måde kan blive ekstremt svært eller demoraliserende at overholde procedurerne. Hvis proceduren beskriver den arbejdsgang der findes i forvejen (eventuelt med små modifikationer hvis eksisterende fremgangsmåde ikke overholder GxP), vil det for eksisterende personale være let og ligetil at overholde proceduren, og for nyt personale være let at sætte sig ind i arbejdsgangen. En god og solid procedure skal typisk skrives af folk der har praktisk erfaring fra det berørte emne. Der er desuden en reel chance for at proceduren/fremgangsmåden overholdes, i modsætning til akademiske/teoretiske procedurer der typisk ikke overholdes. Mængden af procedurer bør typisk omfatte : Drift o Vedligehold o Backup o Restore o Patchning o Opgraderinger o Komprimering og defragmentering o Kontrol og overvågning Ansvaret for udviklingen af procedurerne for IT systemer ligger typisk i IT afdelingen, og godkendes af systemets ejer og af QA. Et godt tip er at skrive procedurerne, og indføre dem i praktisk brug i en (planlagt) periode før de revurderes og tilpasses. Ud over driftrelaterede procedurer findes der også en del valideringsrelevante procedurer. Man bør som udgangspunkt gå ud fra at virksomhedens eksisterende procedurer for validering også dækker området IT. Man skal dog være opmærksom på om dette er tilfældet og sørge for at få det beskrevet præcis hvad der er gældende for området i valideringsplanen. Specifikation Noget af det vigtigste indenfor GxP er specifikationer. De regler man skal leve op til er retningsgivende (f.eks. der skal være en passende temperatur ), og man er nødsaget til at forholde sig til dem med noget konkret (f.eks. temperaturen skal være 20 C ± 3 C ). Dette gøres ved at udarbejde specifikationer. Specifikationerne er virksomhedens tolkning af myndighedernes krav, og benyttes efterfølgende til at teste ud fra. Dette betyder at en specifikation (opsættes typisk som et krav), skal være formuleret entydigt, alment forståeligt og testbart. Page 4 of 6

5 Det er ofte en god idé at beskrive systemet med tekst, og derefter uddrage de relevante krav fra teksten. Dette giver endvidere brugeren mulighed for at forstå kravene i en sammenhæng. Enkeltstående krav kan ofte virke irrationelle eller uforståelige når de tages ud af sammenhængen. Husk altid at hvis man ikke har skrevet en vurdering ned, findes den ikke i forhold til myndighederne der kontrollerer! Kontrol og test Begrebet validering dækker over kontrol og test. Det er vigtigt at lave test struktureret således at man kan finde en sammenhæng imellem specifikationer og test (dette gøres ofte ved at udarbejde en kravsmatrix, men dette er ikke et krav). For hver enkelt specifikation er det nødvendigt om man overholder denne. For et IT system bør man typisk teste under normalsituation, under Worst case betingelser, samt nødberedskab/nødprocedurer (f.eks. disaster recovery). Kontrollen afsluttes med en rapport der opsummerer om det er gået godt eller skidt. Inspektion Hvad går de efter? Inspektion er metoden til at finde ud af om det er godt nok. Myndighederne og kunder inspicerer producenter, og producenter inspicerer sig selv og underleverandører. Metoderne for inspektion er enkle og gælder IT systemer såvel som produktion, lager o.s.v.. Udgangspunktet for en inspektion er oftest valideringsplanen, hvor inspektøren kan danne sig et overblik, samt en forventning til det aktuelle stade. Næste skridt er specifikationerne. Her kan inspektøren tage stilling til om de gældende krav er vurderet, og om de vurderinger virksomheden har taget er tilstrækkelige. Efter specifikationerne vil der typisk blive kontrolleret om kontrol af om systemerne lever op til specifikationerne er udført på behørig vis. Der er naturligvis en mængde andre emner en inspektør kan tage op Nogle af de mest brugte er træning og dokumentation af træning, virksomhedens inspektion og håndtering af underleverandører, samt definition og opbevaring af data. Vedligeholde det validerede stade Hvad gør man så når først man har opnået Nirvana Det validerede stade hvor procedurerne findes i en godkendt version, og test af systemer og procedurer er overstået? En ting er helt sikkert : Det er ufatteligt dumt blot at lade stå til. Problemet er at hvis man ikke gør noget så forsvinder det validerede stade relativt hurtigt. Den primære metode for at bibeholde det validerede stade er ændringskontrol. En af de vigtigste metoder til at opretholde (og dokumentere) det validerede stade for et IT relateret system er konfigurationsstyring og baselines. Disse benyttes til henholdsvis at registrere systemændringer over tid og til at dokumentere at vi har styr på alle de ændringer der er lavet over tid. De informationer man ønsker i konfigurationsstyring er typisk systemets sammenhæng, hvad systemet kører, samt de kørende versioner. Ved at lave konfigurationsstyring kan man desuden altid dokumentere hvordan ting var på et givent tidspunkt, og derfra behandle eventuelle afvigelser baseret på analyse og risikovurdering. Page 5 of 6

6 Husk nu dokumentationen for risikovurderingen!! Hvor lidt kan vi slippe af sted med? Skal man give et hurtigt svar på dette spørgsmål er svaret : Ret lidt. Først og fremmest er der mange IT systemer der ikke påvirker GxP niveauet i nævneværdig grad. Eksempel Hvis man for eksempel opbevarer alle data on-line på spejlede systemer der ikke er placeret samme fysiske sted, er backup typisk ikke kritisk (i princippet heller ikke set ud fra et rent produktionsteknisk synspunkt). Backup der alene benyttes til at reetablere et system, og udelukkende gælder indtil næste backup foretages (f.eks. efter en uge), er kun kritisk i den periode hvor der er risiko for at bruge den. Herefter er den ikke længere kritisk, og man er ikke nødsaget til at tage stilling til hvordan man kan sikre at der er et system der kan læse og reetablere data efter 5 år. Hvis man derimod overfører gamle data man ikke længere har on-line plads til, til en retrætepost på bånd der bliver placeret på et lager, vil det oftest blive betragtet som kritisk. Det der derfor vigtigt at man foretager sine vurderinger for området, og ud fra disse vurderinger tager rationelle beslutninger der senere kan føres ud i livet. Reklame Stage One Computing har ekspertviden til at hjælpe Jeres virksomhed hen mod IT compliance. Vi har templatedokumenter til en lang række af de dokumenter der indgår i forløbet omkring IT compliance, og stor viden om IT systemer både til kontor- og driftmiljø. Stage One Computing forhandler desuden QAtor s produksuite af complianceprodukter der understøtter de processer man normalt vil møde Konfigurationsstyring, logbøger, ændringskontrol, afvigelsesbehandling, dokumentationsstyring, træningsstyring etc.. Med QAtor suiten kan man komme i kontrol, uden at have et eneste papirbaseret dokument. Stage One Computing A/S Laurentsvej 27 DK-2880 Bagsværd Denmark info@stagone.dk Page 6 of 6