▪ Systematický proces posuzování, řízení, komunikace a přezkoumávání rizik.
▪ Ideu „Risk-based Approach...“ zavádí ISPE v roce 2007 a v GAMP 5 (vydaného v r.2008) se mění přístup k validačním procesům z dosavadní plošné rutiny na preferování vědeckého přístupu, zkušeností a zdravého rozumu. Cílem je aplikovat validační postupy pouze na entity a procesy, které toto vyžadují.
▪ Jde o opakovaný proces provázející systém v průběhu jeho celého životního cyklu od návrhu až po vyřazení.
▪ Je to kooperativní týmový proces na němž by se měli podílet jak zástupci regulovaného subjektu, tak i dodavatele. Tým musí obsahovat odborníky na jednotlivé procesy (SMEs) s praktickými zkušenostmi a zástupce IT.
▪ Řízení rizik by mělo být založeno na vědeckém přístupu zahrnujícím znalosti o:
▪ možném vlivu systému na bezpečnost pacienta, kvalitu produktu a integritu dat
▪ okolní byznys procesy
▪ dotčených CQAs a monitorovaných / regulovaných CPPs
▪ Kontrola aplikace a efektivity přijatých opatření.
▪ Řízení rizik na konkrétním subjektu by neměl být jednorázovou záležitostí, nýbrž by měl být aplikován při každé změně okolností. V případě počítačového systému např. při:
▪ Doplnění funkčnosti,
▪ Náhrada komponenty,
▪ Přechod na novou verzi,
▪ Vznik neplánované příhody (fatal error),
▪ Závěry auditu, apod.
Přezkoumání rizik
Posouzení rizik
Zahájení procesu řízení rizik
Identifikace rizik
Analýza rizik
Vyhodnocení rizik
Snížení rizika
Přijetí rizika
Výstup/výsledek procesu řízení rizik
Přezkoumávané události
Kontrola rizik
Ko
mu
nik
ac
e r
izik
Ná
stro
je říz
en
í rizik
nepřijatelné
09.05.2017
8
Nástroje pro QRM
▪ Většinou se využívá standardních metodik v kombinaci s empirickými postupy (pozorování, trendy, apod.)
▪ Analýza možných vad a jejich důsledků (FMEA, Failure Mode Effects Analysis)
▪ Analýza možných vad, jejich důsledků a kritičnosti (FMECA, Failure Mode, Effects and Criticality Analysis)
▪ Analýza stromu poruchových stavů (FTA, Fault Tree Analysis)
▪ Analýza nebezpečí a kritické kontrolní body (HACCP, Hazard Analysis and Critical Control Points)
▪ Analýza ohrožení a provozuschopnosti (HAZOP, Hazard Operability Analysis)
▪ Předběžná analýza nebezpečí (PHA, Preliminary Hazard Analysis)
▪ apod.
▪ Tyto metodiky založeny většinou na kvantitativním posuzování jednotlivých aspektů rizik.
▪ GAMP zavádí praktickou metodiku „Zjednodušená FMEA“, využívající shodné faktory klasifikace rizika, jako FMEA, ale používá kvalitativní hodnocení typu High/Medium/Low
▪ Následuje bezprostředně po URS nebo se řeší souběžně, tj. jedna z nejrannějších činností při zavádění počítačového systému
▪ Účelem je zhodnocení potenciálních dopadů systému na firemní procesy zejména z hlediska kvality a účinnosti produktu a bezpečnosti pacienta. Jde o stanovení tzv. „GxP relevance“ systému, na základě výsledků se následně stanoví přístup k implementaci a validaci:
▪ spravuje data týkající se regulatorních záležitostí či registrace léčivého přípravku
▪ řízení/monitoring CPP v pre-klinické, klinické, vývojové či výrobní léčivého přípravku
▪ řízení/poskytování podkladů pro propouštění léčivého přípravku
▪ řízení/poskytování podkladů pro stahování léčivého přípravku
▪ řízení/poskytování podkladů pro řešení odchylek, reklamací, stížností, apod.
▪ podporuje farmakovigilanci
▪ V případě komplexních systémů (např. ERP) je vhodné na základě URS rozdělit systém na více částí (modulů/komponent) a hodnotit každou zvlášť
▪ I-RA provádí regulovaný subjekt, nejčastěji business/process owner, oddělení jakosti a SMEs (ti, kdo rozumějí procesům a definovali požadavky na systém)
▪ Vychází ze specifikace funkcí v URS/FS a závěrů I-RA (GxP relevance).
▪ Elementární hodnocená entita závisí na novosti a komplexnosti systému - funkce/funkční celek/modul/ teoreticky systém jako celek
▪ Identifikace GxP relevantních funkcí/funkčních celků, optimálně na úrovni FS
▪ Každá GxP relevant funkce/funkční celek se vyhodnocuje z pohledu:
▪ dopadu na související proces v případě jejího selhání
▪ datové integrity
▪ Cílem je minimalizovat dopady případných rizik
▪ Míra detailu F-RA závisí na novosti a komplexnosti systému (např. pro jednoduché či jednoúčelové systémy, u nichž nelze odlišovat GxP a non GxP funkce, lze hodnotit i systém jako celek)
▪ Výstupy F-RA mj. určují přístup k verifikaci (testování) systému – komplexnost testů, míru detailu, apod.
▪ F-RA by se měli účastnit SMEs, F-RA schvaluje regulovaný subjekt.
▪ Veškeré změny ve validovaném systému nebo jeho operačním prostředí musejí být zastřešeny formálním Změnovým řízením, komplexnější změny by měly být řešeny jako validovaný projekt.
▪ Cílem je udržení systému ve validovaném stavu.
▪ Aktualizace systému:
▪ Změna operačního prostředí (např. aktualizace OS, výměna serveru, ...)
▪ Změna konfigurace systému
▪ Funkční rozšíření systému
▪ Oprava chyby
▪ Analýza rizik při aktualizaci systému:
▪ Dopadu změny na GxP relevantní funkce (analogicky, jako při pořizování)/dokumentaci/procesy subjektu
výstupy formují verifikační strategii (IQ/OQ)
▪ Migrace dat (pokud změna vede na změnu datové struktury)
▪ Data jsou klíčovým majetkem společnosti (know-how, závazky vůči regulatorním autoritám)
▪ Migrace dat představuje činnosti při transferu dat z jednoho systému do jiného nebo i pouhý přechod dat z jednoho stavu do jiného (tj. rozsah, složitost a riziko jsou velmi variantní):
▪ úprava struktury dat existujícího systému
▪ konverze dat (např. z jedné databáze do jiné)
▪ migrace v rámci jednoho systému (např. transport databáze při výměně serveru)
▪ migrace při přechodu z jednoho systému na jiný
▪ migrace při slučování dat z více systémů do jednoho
▪ Cílem je vždy zachovat obsah a integritu dat.
▪ Migrace dat by měla vždy být zastřešena Migračním plánem a reportem.
▪ Každý regulovaný subjekt by měl mít v rámci procesů jištění jakosti definovánu obecnou strategii pro migrace dat (např. formou SOP).
▪ Automaticky pomocí vhodných nástrojů nebo skriptů
▪ Nezapomenout na migraci metadat a pomocných dat, jako např. AuditTrail (pokud to není možné, nutno starý Audit Trailarchivovat/vytisknout)
▪ Verifikace:
▪ Obsah verifikace
▪ Přenesla se všechna data
▪ Data se přenesla správně
▪ Migrace nenarušila data již předtím obsažená v cílovém systému
▪ Metody verifikace
▪ Verifikace všech dat – automaticky vhodným SW nástrojem (velmi rizikové) / manuálně (možno při malém množství dat)
▪ Verifikace statisticky reprezentativního vzorku dat
▪ Data Migration Report:
▪ Souhrn aktivit vykonaných během procesu migrace dat
▪ Veškeré odchylky nebo anomálie
▪ Seznam aktivit včetně výstupů (množství dat, charakter dat, ...)
▪ Je-li migrace provedena jako část komplexního projektu, např. aktualizace systému, nemusí být DMR samostatný dokument a výstupy migrace mohou být popsány v VSR.
▪ Rizika je nutno kontinuálně vyhledávat a minimalizovat!
▪ Vždy je třeba vyvinout maximální snahu o snížení rizik na akceptovatelnou úroveň!
▪ Datová integrita představuje principy zachování úplnosti, neměnnosti a přesnosti kvalitativně relevantních dat nikoliv pravidla uložení dat v databázi!
▪ Každá aktualizace (změna) systému by měla být řešena změnovým řízením!
▪ Klíčovou součástí náhrady/aktualizace systému je řízená migrace dat!
