Validace počítačového systému ve farmaceutické praxi

Transkript

1 Validace počítačového systému ve farmaceutické praxi Validace počítačových systémů v praxi, seminář CONFORUM, února 2019, Praha 1 Představení přednášejícího Ing. Pavel Říha Analytik v oblasti MES/Validační konzultant >20 let působnosti v MES, >15 let v GxP prostředí Hlavní současné aktivity: Validace počítačových systémů všech kategorií. Posuzování vhodnosti počítačových systémů pro provoz v GxP prostředí. Řízení validovaných projektů. Návrhy a implementace MES/LIMS/QMS řešení. Školení v oblastech validací počítačových systémů a datové integrity. Process Automation Solutions s.r.o., pavel.riha@pa-ats.com, 2 Doc. Vers.: 1 2 1

2 Agenda 1) Co je validace? 2) Příprava validovaného projektu: Specifikace uživatelských požadavků Výběr dodavatele Plánování validovaného projektu 3) Verifikace projektové dokumentace 4) Verifikace/kvalifikace systému založená na hodnocení rizika 5) Souběžná (Concurrent) validace 6) Migrace dat 3 Doc. Vers.: 1 3 Validace počítačového systému: Co to je? Systematický proces zahrnující celý životní cyklus počítačového systému (Koncept, Projekt, Používání, Vyřazení) směřující k tomu, aby systém plnil svůj účel a pracoval bez chyb a v souladu s uživatelskými i regulatorními požadavky (není rizikem pro kvalitu produktu, bezpečnost pacienta a integritu dat). 4 Doc. Vers.: 1 4 2

3 Příprava validovaného projektu 5 Co by se mělo při zahájení projektu zohlednit... Motto: Je-li něco špatné na začátku, bude to špatné i na konci. CO: Specifikace uživatelských požadavků (URS) JAK: Úvodní analýza rizik (System Impact Assessment) Validační plán KDO: Interní tým od počátku začlenit všechny složky (QA, profesionály procesů (SMEs), IT, management,...) Výběr dodavatele hodnocení dodavatelů KDY: Harmonogram s ohledem na provoz firmy (výroba, odstávky, závazky,...) VMP I-RA URS Výběr dodavatele a systému 6 Doc. Vers.: 1 6 3

4 Specifikace uživatelských požadavků 7 URS: User Requirement Specification Základní dokument životního cyklu systému, který specifikuje požadavky na systém, tj. co by měl systém dělat a jak by se měl chovat. Měl by v hrubé podobě existovat již před provedením úvodní analýzy rizik a vypracováním validačního plánu. Dále může být precizován v rámci fáze plánování projektu. Zodpovědnost za vypracování URS má regulovaný subjekt, dokument může nicméně být vypracován i dodavatelem nebo třetí stranou. Na tvorbě URS se musejí podílet lidé se znalostí ovlivněných procesů (SMEs). Je to řízený dokument, tj. podléhá verzování a musí obsahovat historii verzí. 8 Doc. Vers.: 1 8 4

5 URS: User Requirement Specification (pokrač.) Úplné Měl by obsahovat všechny požadavky na systém, nikoliv pouze na funkce (ale také rozhraní, bezpečnost, specifika prostředí, ). Míra detailizace požadavku by měla být úměrná novosti a komplexnosti systému. Srozumitelné Požadavky by měly být psány srozumitelným jazykem, bez zbytečného technického žargonu. Jednoznačné Požadavky by neměly připouštět dvojí výklad, neměly by se duplikovat a pokud možno ani vzájemně překrývat. Strukturované Každý požadavek by měl být jasně identifikovatelný a pokud možno unikátně označený, aby umožnil následnou traceabilitu. Vhodné je označení priority požadavku. Testovatelné Každý požadavek by mělo jít exaktním způsobem otestovat. Zohledňující rizika Již na úrovni URS by měly být identifikovány požadavky s dopadem na GxP procesy - CQA resp. CPP. 9 Doc. Vers.: 1 9 URS: User Requirement Specification (pokrač.) NEPODCEŇUJTE VÝZNAM URS, NENÍ TO JEN FORMALITA PRO AUDITORA! Při přípravě dokumentu si sami utřídíte podobu požadavků, případně zpětně optimalizujete vlastní procesy. Minimalizujete následné konflikty s dodavatelem kvůli: Chybějícím funkcím, Funkcím neodpovídajícím vašim představám, Chybám v produkčním provozu systému kvůli neotestovaným funkcím, Dodatečným nákladům na vícepráce. Nikdy nespoléhejte, že něco je správná praxe, běžná záležitost, že něco očekáváte jako samozřejmost. Vše, co chcete, musíte exaktně požadovat s maximální možnou přesností a následně vyžadovat, aby dodavatel potvrdil, že požadavek chápe a že jej takto provede (správná a úplná dokumentace návrhu a též Design Review viz dále). 10 Doc. Vers.:

6 URS (příklady) Ukázka 11 Doc. Vers.: 1 Příklad 11 Výběr dodavatele 12 6

7 Hodnocení dodavatelů Cílem formálního hodnocení je ověřit kvalitu a spolehlivost dodavatele (tj. zda je schopen dodat dílo včas a v požadované kvalitě) s cílem snížit riziko vlivu jeho služeb/dodávek na procesy regulovaného subjektu. Způsoby hodnocení: 1) Hodnocení založené na osobních zkušenostech a všeobecně dostupných informacích (reference, reputace, apod.). 2) Korespondenční audit, dotazník 3) Osobní audit (měl by se odvíjet od předem oboustranně odsouhlasené agendy) Příklady hodnocených činností (pro dodavatele SW): Systém jakosti dodavatele Způsob vývoje SW, standardy, pravidla Dokumentace vývoje Interní testování, způsoby a dokumentování testů Změnová řízení Závěry hodnocení mají vliv na: Odborná způsobilost pracovníků (školení, vzdělávání,...) Projektové řízení Využívání subdodavatelů Řešení reklamací Akceptaci dodavatele (bez výhrad, pouze pro určité produkty/služby, po aplikaci CAPA,..., odmítnutí) Průběh validace zavedení opatření na snížení rizika (kontrola činnosti dodavatele, code review, hloubka detailu testování,...) Hodnocení se odvíjí od komplexnosti a novosti systému a dosavadních zkušeností s dodavatelem. 13 Doc. Vers.: 1 13 Validační plán 14 7

8 Validační plán Popisuje validační aktivity související s jedním celkem zařízením, procesem, počítačovým systémem, apod. Měl být vyhotoven co nejdříve, optimálně bezprostředně po URS resp. I-RA. VP společně s URS a I-RA jsou základními vstupními dokumenty pro dodavatele ve fázi přípravy projektu. VP, společně se závěrečným souhrnným reportem, jsou nejdůležitější dokumenty pro dokladování validačního procesu a jako první jsou předkládány auditorům. Zodpovědnost za vypracování VP má regulovaný subjekt, dokument může nicméně být vypracován i třetí stranou. VP by měl být signován zástupcem vrcholového managementu společnosti. 15 Doc. Vers.: 1 15 Validační plán (hlavní body) Popis projektu Popis systému, komponenty, účel použití, záměry Organizační struktura projektu Způsob a mechanismy řízení rizik Validační strategie Kategorizace HW a SW Jaké konkrétní validační činnosti budou provedeny a v jakém rozsahu (model životního cyklu projektu) Jaká dokumentace bude vypracována/vyžadována Další aspekty jištění jakosti Změnová řízení SOP Školení Řízení dokumentů 16 Doc. Vers.: 1 Příklad 16 8

9 Quality&Project Plan Základní řídící dokument validovaného projektu z pohledu dodavatele Měl by navazovat na Validační plán zákazníka Typická struktura dokumentu Popis systému Více detailní a konkrétní, než ve VP Plán jakosti Požadavky na jištění jakosti a jejich naplnění ze strany dodavatele (systém jištění jakosti dodavatele) Koncept validace z pohledu dodavatele (jaké činnosti budou provedeny, způsoby pro jejich dosažení) Složení validačních týmů pro klíčové činnosti Způsob řízení a značení dokumentace Plán řízení projektu Projektové týmy (jména, pozice, kontaktní údaje, odpovědnosti) Harmonogram Způsoby komunikace, organizace kontrolních dnů Změnová řízení 3-strany v projektu odpovědnosti, začlenění do projektu Dle kvality QPP dokumentu lze snadno již na úvod identifikovat zkušenosti dodavatele s validacemi 17 Doc. Vers.: 1 Příklad 17 Traceabilita požadavku a Design review 18 9

10 Traceabilita požadavku a Verifikace návrhu Jedním z významných cílů validace je formální zajištění, že dodavatel správně a úplně pochopil, co zákazník skutečně požaduje: Všechny požadavky byly zahrnuty do realizace systému, Požadavky byly správně pochopeny a funkčnost systému bude adekvátní, Dokumentace návrhu (FS, CS, DS) je kompletní a dostatečně detailní, Požadavky / funkce budou řádně otestovány. Traceabilita požadavků (Requirement traceability) Účelem RT je prokázat, že požadavky specifikované v URS byly příslušně zohledněny v jednotlivých stupních projektové dokumentace FS, DS resp. CS a následně i ve specifikacích testů IQ a OQ. Provádí se nejčastěji formou Requirement Traceability Matrix. Verifikace návrhu (Design Review) Účelem DR je prokázat, že projektová dokumentace systému je úplná, schválená a dostupná. RT/DR by mělo být provedeno ještě před zahájením vývoje/implementace systému, demonstruje připravenost dodavatele na vývoj/implementaci. Zodpovědnost za provedení RT/DR má dodavatel, schvaluje jej regulovaný subjekt. 19 Doc. Vers.: 1 19 Traceability matrix (příklad s číslovanými požadavky) Ukázka Doc. Vers.: 1 Příklad 10

11 Traceability matrix (příklad s citací požadavků) Ukázka 21 Doc. Vers.: 1 Příklad 21 Verifikace (Kvalifikace) 22 11

12 Verifikace / Kvalifikace Účel verifikace: Doklad pro regulatorní autoritu Prokázání, že systém je vhodný pro svůj účel a splňuje uživatelské a regulatorní požadavky Identifikace chyb před uvedením systému do rutinního provozu Typy verifikace: URS Verifikace požadavků Verifikace návrhu (DQ) = Design Review Verifikace instalace (IQ) FS Verifikace funkcí Unit/module a integrační testy Verifikace konfigurace (CQ) CS Verifikace konfigurace Funkční verifikace (OQ) Verifikace požadavků / výkonnosti (PQ) Verifikace návrhu DS Unit testy / Integrační testy 23 Doc. Vers.: 1 23 Verifikace / Kvalifikace (typy) Verifikace návrhu (DQ): Účelem DQ je prokázat, že požadavky zákazníka, týkající se předmětu validace, specifikované v URS, byly dodavatelem příslušně zohledněny v jednotlivých stupních projektové dokumentace FS/CS/DS a následně i ve specifikacích testů IQ a OQ. Verifikace instalace (IQ): Účelem IQ je prokázat, že všechny komponenty předmětu validace jsou nainstalovány správně, ve správných verzích a v souladu s projektovou dokumentací. Referenčním materiálem pro IQ jsou dokumenty DS, alternativně FS (edice AsBuilt) Verifikace funkcí/konfigurace (OQ): Účelem OQ je prokázat, že předmět validace splňuje legislativní požadavky a funguje bezchybně, v souladu s projektovou dokumentací. Referenčním materiálem pro OQ jsou dokumenty FS a DS resp. CS (edice AsBuilt) a legislativní předpisy. Provádí se v testovacím prostředí na testovacích datech. Verifikace požadavků (PQ): Účelem PQ je prokázat, že předmět validace splňuje uživatelské požadavky a je vhodný pro svůj účel. Referenčním materiálem pro PQ je dokument URS. Provádí se v operačním prostředí na provozních datech. V rámci PQ se zpravidla provádí i ověření aplikace nápravných opatření. 24 Doc. Vers.:

13 Verifikace / Kvalifikace (náročnost) Rozsah a tedy i časovou náročnost a cenu verifikací ovlivňuje: Komplexnost a novost systému Důvěryhodnost dodavatele Segregace non GxP relevant komponent v rámci Úvodní risk analýzy Verifikace non GxP relevant systémů je řádově 10-20x méně náročná funkční akceptační testy Zvolená kategorie SW/HW Kat.3: Instalace, Požadavky Kat.4: Instalace, Konfigurace, Funkce, Požadavky Kat.5: Instalace, Code Review, Unit/Module, Integrační, Konfigurace, Funkce, Požadavky Posouzení rizik v rámci Funkční risk analýzy Verifikace funkcí s nízkou či střední prioritou rizika je méně náročná, než těch s prioritou vysokou 25 Doc. Vers.: 1 25 Verifikace / Kvalifikace (postup) Validační strategie Validačního plánu Plán verifikací Specifikace testů Specifikace testů testů Testovací Testovací procedury procedury Testovací procedury Testování Souhrnná zpráva Souhrnná zpráva validace Dílčí zprávy Dílčí zprávy Dílčí zprávy Protokoly testů Protokoly testů Protokoly testů 26 Doc. Vers.:

14 Souběžná (Concurrent) validace 27 Přístup k souběžné validaci (1) Souběžná validace = Validační proces uplatněný na již implementovaném a provozovaném systému. Jednodušší, než u prospektivní, také závisí na komplexnosti systému. Primárně vychází z faktů, že: Systém je již úspěšně nasazen a provozován Systém zasahuje do GxP procesů, tj. je třeba jej validovat (vhodné dokumentovat formálním GxP zhodnocením) Zdrojové kódy resp. dodavatel nemusejí být k dispozici, tj. v systému nemusí být možno provádět změny Rozsah validačních aktivit: Audit systému Realizace nápravných opatření Kvalifikace/verifikace To vše zapouzdřené Validačním plánem a závěrečným Reportem 28 Doc. Vers.:

15 Přístup k souběžné validaci (2) Audit systému: Zhodnocení systému z pohledu: GxP relevance systému/modulů/funkcí (atomizace) Shody s legislativou (Eudralex vol.4, Annex 11 / VYR 32, doplněk 11; 21 CFR Part 11) Shody s požadavky data integrity Funkční analýza rizik (definuje hloubku verifikace funkcí) Kontrola dokumentace (minimálně): Funkční specifikace Dokumentace skutečného stavu (architektura, hardware, konfigurace SW, apod.) Uživatelská dokumentace Realizace nápravných opatření Kvalifikace/verifikace (dle komplexnosti systému): Instalace (jak SW, tak i jednotlivých HW elementů) Funkce (na základě výstupu z F-RA) Ověření, že je systém používán správným způsobem (průkazné doklady: uživatelská dokumentace, záznamy o školení) Ověření realizace nápravných opatření 29 Doc. Vers.: 1 29 Migrace dat 30 15

16 Migrace dat 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). Migrace dat v průběhu životního cyklu systému: Uvedení do provozu (importy) Upgrade systému (změny datových struktur) Ukončení činnosti systému (exporty) 31 Doc. Vers.: 1 31 Životní cyklus migrace dat Plán migrace Zpráva z migrace Verifikace Exekuce 32 Doc. Vers.:

17 Plán migrace a analýza rizik Plán migrace by měl popisovat celý migrační proces: Důvod a cíl migrace/popis systému/role a odpovědnosti Strategii řízení rizik Použité nástroje Postup migrace (kroky, činnosti) Popis mapování dat, transformační pravidla Strategii pro verifikaci dat vč. akceptačních kritérií Rollback strategii Analýza rizik by měla zohledňovat: Dopad potenciálního poškození/zničení dat na byznys procesy (s ohledem na GxP relevanci dat) Nedostupnost dat/systému během migrace Stupeň komplexnosti migrace Migrační nástroje a technologie 33 Doc. Vers.: 1 Příklad RA Příklad plán 33 Exekuce, verifikace a vyhodnocení migrace dat Exekuce: 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 Trail archivovat/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 (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. 34 Doc. Vers.:

18 Shrnutí 35 Shrnutí Je-li něco špatné na začátku, bude to špatné i na konci! Napište si pořádně specifikaci požadavků! Validační plán není harmonogram! Pečlivě vybírejte dodavatele! Nebojte se risk analýzy, zjednoduší vám život! Trasujte, ať na nic nezapomenete! Verifikace není jen o dokumentaci pro auditory! Počítačové systémy lze validovat i zpětně! 36 Doc. Vers.:

19 Otázky...?...a odpovědi! Děkujeme za Vaši pozornost