W niniejszym artykule omówię zagadnienie wykorzystania podejścia Agile w tzw. procesach regulowanych na przykładzie branży farmaceutycznej i tzw. środowiska GxP (co to jest – o tym za chwilę).
Dlaczego w ogóle warto o tym pisać? Ponieważ jest to przykład bardzo udanego mariażu podejścia zwinnego, które, co do założeń (i praktyki!), „przedkłada działające oprogramowanie ponad dokumentację”, z wymogami narzuconymi przez Regulatora (w tym przypadku dla branży farmaceutycznej) na oprogramowanie wspierające procesy walidowane – ogólnie określane jako GxP.
Kilka słów o GxP
Cóż to zatem jest to GxP? To akronim od angielskiego Good „x” Practices, gdzie za „x” można podstawić: Clinical, Manufacturing, Distribution, Procurement, Laboratory etc.
Niech nas tylko nie zwiedzie fraza dobre praktyki, która mogłaby sugerować pewną dowolność stosowania się do tych wytycznych. Nic bardziej mylnego! Dla organizacji chcących funkcjonować w branży farmaceutycznej to bezwzględny wymóg. Bardziej trafnym określeniem byłyby zatem wymogi regulacyjne niż dobre praktyki.
Typy systemów w środowisku GxP
W ramach środowiska GxP funkcjonować mogą różnorodne systemy. Żeby uzmysłowić Czytelnikowi, o jakich typach systemów mówimy, pozwolę sobie przywołać – wg informacji z Głównego Inspektoratu Farmaceutycznego – przykład odnoszący się tylko do systemów wykorzystywanych w dystrybucji produktów leczniczych:
- Systemy magazynowo – księgowe wspierające procesy przebiegające w hurtowni (m.in. zamówienia, zakup, sprzedaż, reklamacje, wstrzymania, wycofania, zwroty, utylizacja).
- Urządzenia skanujące dane z opakowań do systemu.
- Systemy wspomagające zarządzanie transportem.
- Systemy zarządzające kontrolą warunków otoczenia podczas przechowywania i transportu:
- zapewnienie warunków przechowywania w całym łańcuchu dystrybucji,
- zbieranie danych,
- przechowywanie i archiwizacja danych.
- Systemy elektronicznego zarządzania dokumentacją: tworzenie, dystrybucja, archiwizacja dokumentacji.
Jak łatwo wywnioskować, w przedsiębiorstwie farmaceutycznym jest wiele systemów, które zgodnie z regulacjami podlegają wymogowi walidacji. A to oznacza, że zastosowanie opisywanego tu modelu ma duży potencjał. Oczywiście – o ile chcemy podążać ścieżką Agile… ?
Jak zatem stosować Agile w procesach regulowanych?
W całym Modelu można wyróżnić trzy „fazy” (purystów językowych z góry przepraszam za pozostawienie nazewnictwa w oryginalnej angielskiej wersji):
Validation Planning
Faza obejmująca:
- Ocenę ryzyka (System GxP and risk assessment), w ramach której szczególny nacisk jest kładziony na identyfikację zagrożeń z perspektywy ich wpływu na końcowego użytkownika, przedsiębiorstwo oraz zgodność z obowiązującymi regulacjami (w tym: GxP).
- Ocenę danych przetwarzanych przez dany system (Data classification assessment) m.in. pod kątem ich zgodności z obowiązującymi regulacjami.
- Ocenę dostawcy oprogramowania (Supplier assessment) – jeżeli kupowane jest oprogramowanie, które następnie będzie użyte przy budowie naszego systemu.
- Plan walidacji (Validation plan), który określa podejście do walidacji i jej zakres.
Zakończenie powyższych prac nad fazą Validation Planning znajduje potwierdzenie w przejściu Bramki akceptacyjnej (Approval gate validation planning).
Design, Build and Test
Ta faza stanowi clue prac rozwojowych. Tutaj również podejście zwinne dochodzi mocno do głosu. Kluczowe jej komponenty to:
- Przygotowanie Product Backlog, zawierającego nawiązania do wymogów regulacyjnych (znowu GxP). Tutaj następuje priorytetyzacja user stories, również pod kątem wymogów regulacyjnych.
- Co ciekawe, product backlog nie musi mieć postaci dedykowanego dokumentu. Może być ujęty w formie zapisów elektronicznych w narzędziu wspierającym niniejszy proces, zwalidowanym do zastosowania w środowisku regulowanym (o tym narzędziu napiszę na końcu tego postu).
- Wykonanie Sprintów (Sprint execution), zgodnie z przyjętą metodyką agile.
- Warto nadmienić, że w każdym sprincie – zgodnie z omawianym modelem – musi uczestniczyć przedstawiciel quality lub compliance lub zespołu walidacyjnego, co ma na celu zapewnienie bieżącego nadzoru nad działaniami o charakterze walidacyjnym.
- W wyniku każdego sprintu powstają zapisy walidacyjne, które muszą być odpowiednio przechowywane, zabezpieczone i dostępne (vide dedykowane narzędzie wspierające). Będą one stanowiły podstawę do przyszłego zezwolenia do produkcyjnego wdrożenia.
- Sformułowanie Sprint Backlog.
- Opracowanie Architektury Systemu (System architecture or system description) – która wynika z technicznych uwarunkowań. Tutaj zostanie określone miejsce wdrażanego systemu w istniejącym w firmie krajobrazie IT (IT landscape), zaadresowane zostaną kwestie infrastruktury, połączeń sieciowych, baz danych, systemów operacyjnych etc.
- Opracowanie szczegółowychUser Stories, czyli doprowadzenie historyjek do stopnia szczegółowości umożliwiającego rozpoczęcie prac przez zespół deweloperski.
- Również tutaj wystarczy, gdy user stories przyjmą formę zapisów elektronicznych w narzędziu wspierającym niniejszy proces (nie ma konieczności przygotowywania dedykowanych dokumentów).
- Jeżeli Plan Walidacji to przewiduje (vide ustalenia z fazy Planowania walidacji) – konieczna jest Ocena ryzyka dla User Stories (User story risk assessment). Głównym obszarem troski jest tutaj bezpieczeństwo pacjentów (przecież docelowo mówimy o produkcji leków), jakość produktów i integralność danych. Wyniki tych działań mogą mieć przełożenie na kształt i formę testów, na wdrożenie punktów kontrolnych o charakterze technicznym, proceduralnym lub związanych z bezpieczeństwem, a także wskazywać na ewentualne szczególne potrzeby szkoleniowe.
- W pewnych przypadkach (np. konieczność przygotowania interfejsu) może zaistnieć potrzeba opracowania Specyfikacji technicznej (Design specification).
- Podobnie jak wcześniej, to opracowanie może przyjąć formę zapisów w narzędziu wspierającym.
- Przygotowanie kodu i przegląd kodu / Testy systemowe (Code review/unit testing) – działania koncentrujące się na weryfikacji i zapewnieniu poprawności kodu od strony czysto technicznej.
- Weryfikacja przygotowanego kodu następuje iteracyjnie w trakcie dedykowanych wydarzeń wynikających z przyjętej metodyki zwinnej: Iterations/Sprint reviews/Daily Standups
- Na etapie Planowania testów (Test planning) wybierane są user stories do najbliższej iteracji testów. Na tym etapie precyzowane jest podejście do testów (odpowiedzialności, obsługa błędów, kryteria akceptacji etc.) – o ile nie jest to zdefiniowane generycznie na wcześniejszym etapie. Tu również może zapaść decyzja o ewentualnych testach regresyjnych.
- Podobnie jak kilkukrotnie wcześniej, również tutaj plan testów – zamiast dedykowanej dokumentacji – może przyjąć formę scenariuszy testowych (referujących do testowanych user stories) umieszczonych w zwalidowanym narzędziu wspomagającym.
- Jeżeli zakres sprintu wymusza zmiany w infrastrukturze, wykonywana jest Ocena infrastruktury (Infrastructure qualification/installation verification).
- Po realizacji wszystkich powyższych (wymaganych) punktów następuje Bramka gotowości do testów dla bieżącego sprintu (Approval gate sprint).
- Po pomyślnym przejściu powyższej bramki wchodzimy w etap Testów, zgodnie z Planem testów (Verification of user stories/regression testing).
- Zwalidowane narzędzie pomocnicze może stanowić tu dużą pomoc przy procesie testowania, w szczególności, przy rejestracji wyników tych testów.
- Po zakończeniu testów mamy już zweryfikowany Pakiet oprogramowania (Shippable software), który – po złożeniu z pozostałymi pakietami – będzie składał się na pierwsze wdrożenie. Ma ono miejsce w trzeciej, ostatniej fazie Modelu:
Validation Reporting
- Zanim nastąpi wdrożenie rozwiązania, konieczny jest przegląd istniejących Procedur operacyjnych i szkolenia (SOPs adaption and training). Aktualizacji mogą wymagać zarówno procedury biznesowe jak i techniczne.
- Przed wdrożeniem wymagany jest również Raport z testów i informacje nt. wdrożenia (Test summary report/release note).
- Tradycyjnie już, takie informacje możemy szybko uzyskać z dedykowanego narzędzia wspierającego.
- Kolejnym krokiem jest właściwe Wdrożenie oprogramowania na środowisko produkcyjne (Deployment) i przekazanie biznesowi do wykorzystania i zespołowi technicznemu do utrzymania.
- Kluczowym z punktu widzenia wymogów regulacyjnych jest Raport z walidacji (Validation report), który prezentuje wynik wykonanych działań walidacyjnych i adresuje ewentualne odchylenia.
- Krokiem zamykającym cały proces jest przejście Bramki decyzyjnej (Approval gate validation reporting) potwierdzającej skuteczność przedmiotowego wdrożenia i jego zgodność z obowiązującymi regulacjami.
Cały Model jest poniżej przedstawiony w formie poniższego schematu:
Dedykowane oprogramowanie
Warto na koniec zauważyć, że powyższy model może, a nawet powinien być wspierany przez Dedykowane oprogramowanie, które umożliwia zastosowanie podejścia zwinnego przy jednoczesnym rygorystycznym spełnieniu wymogów walidacyjnych. Zostało to zresztą kilkukrotnie wskazane w powyższym tekście (wyróżnione turkusową czcionką).
Aby to narzędzie spełniało stawiane przed nim zadania, samo musi zostać poddane walidacji. Co ważne, proces walidacji narzędzia musi być przeprowadzony w organizacji, w której narzędzie ma funkcjonować. Jest to stan specyficzny dla tej organizacji (inna organizacja musi przeprowadzić sobie „swoją” walidację).
Walidacja narzędzia oznacza – jako minimum – możliwość rejestracji danych o zmianach w wybranych zapisach, w tym: rejestrację daty, czasu i autora tychże zmian (tzw. audit trail). I oczywiście przechowywanie ich przez okres wymagany prawem.
Dobrym przykładem takiego narzędzia są produkty firmy Atlassian: Jira & Confluence.
Kilka słów podsumowania
Podsumowując, doświadczenie wielu firm stosujących ten model (lub zbliżony) wskazuje jasno, że dostarczanie zmian w oprogramowaniu w sposób efektywny kosztowo i czasowo nie koliduje z zastosowaniem się do wymogów Regulatora w zakresie walidacji systemów informatycznych. Zastosowanie dedykowanych narzędzi wspierających usprawnia ten proces i czyni go łatwiejszym do zarządzania.
Uwagi końcowe
- Opisany Model może być zastosowane do dowolnego podejścia Agile.
- Proces wdrażania zmian przebiega wg zbliżonych reguł, co implementacja inicjalna systemu opisana powyżej, ale jest nieco prostszy (nie wszystkie elementy mają tu zastosowanie).
- To opracowanie jest jedynie próbą zwięzłego przedstawienia modelu pracy w trybie zwinnym w środowisku regulowanym. Potencjalny Zainteresowany jego wdrożeniem musi oczywiście sięgnąć do źródła.
Źródło
Guidance on the use of Agile in a GxP environment. BioPhorum Operations Group Ltd.
***
A jeśli chcesz poznać inne artykuły naszych Agilowych ekspertów, zachęcamy do lektury: Co nas motywuje i jak motywować innych?, Model fazowy – jak usystematyzować Retrospektywę? oraz Retrospektywa – mój sposób na nudę.
Zostaw komentarz