EUDAMED: kto odpowiada za jakość danych o wyrobie?

Zdjęcie: EUDAMED: kto odpowiada za jakość danych o wyrobie

EUDAMED przestał być projektem IT. Kto w przedsiębiorstwie odpowiada dziś za jakość danych o wyrobie? UDAMED: kto odpowiada za jakość danych o wyrobie? Przez kilka lat EUDAMED można było traktować jako system, który dopiero kiedyś stanie się w pełni obowiązkowym elementem europejskiego rynku wyrobów medycznych. Od 28 maja 2026 r. taka perspektywa jest już nieaktualna. Obowiązkowe stało się korzystanie z czterech pierwszych modułów europejskiej bazy danych o wyrobach medycznych: rejestracji podmiotów, UDI i wyrobów, jednostek notyfikowanych i certyfikatów oraz nadzoru rynku. Dwa pozostałe moduły – dotyczące vigilance i nadzoru po wprowadzeniu do obrotu oraz badań klinicznych i badań działania – są jeszcze rozwijane. Nie zmienia to jednak zasadniczego faktu. EUDAMED przestał być projektem informatycznym przygotowywanym na przyszłość. Stał się elementem infrastruktury regulacyjnej przedsiębiorstwa. I właśnie dlatego najważniejszym pytaniem nie jest już, kto w firmie potrafi obsługiwać system. Znacznie ważniejsze jest inne: kto odpowiada za to, aby informacje znajdujące się w EUDAMED były prawidłowe i zgodne z rzeczywistym stanem produktu? Dane regulacyjne mają wielu właścicieli. Producent wyrobu medycznego posiada ogromną liczbę informacji o produkcie. Część znajduje się w dokumentacji technicznej. Część w systemie jakości. Inne informacje posiada Regulatory Affairs, R&D, produkcja, dział kliniczny, osoby zarządzające UDI, dział IT czy jednostka notyfikowana. Problem polega na tym, iż z perspektywy regulatora nie istnieje kilka różnych wersji tego samego wyrobu. Istnieje jeden produkt. o ile więc jego klasyfikacja, przeznaczenie, dane identyfikacyjne, informacje dotyczące producenta, certyfikatu i dokumentacji zaczynają się różnić w poszczególnych systemach przedsiębiorstwa, powstaje ryzyko regulacyjne. EUDAMED to ryzyko uwidacznia. Baza integruje bowiem informacje, które wcześniej mogły funkcjonować w większym rozproszeniu. UDI nie jest tylko numerem. Dobrym przykładem jest system UDI. MDR i IVDR wprowadziły unikalną identyfikację wyrobów, która ma umożliwiać ich jednoznaczną identyfikację i zwiększać traceability. Od 28 maja 2026 r. moduł UDI/Devices jest obowiązkowy. Producent musi więc zapewnić rejestrację wymaganych informacji dotyczących wyrobów wprowadzanych na rynek UE. Na pierwszy rzut oka można uznać to za zadanie administracyjne: nadać adekwatny identyfikator i wprowadzić dane do systemu. Tyle iż UDI jest powiązany z tożsamością regulacyjną produktu. Zmiana produktu może oznaczać konieczność oceny, czy dotychczasowa identyfikacja pozostaje prawidłowa. Zmiana danych w jednym systemie może wymagać aktualizacji w innym. Informacja umieszczona w EUDAMED musi odpowiadać temu, co wynika z dokumentacji produktu i jego rzeczywistego statusu. Wtedy problem przestaje dotyczyć samego wprowadzania danych. Dotyczy zarządzania zmianą. R&D zmienia produkt, ale kto zmienia jego dane regulacyjne? Wyobraźmy sobie typową sytuację. Zespół R&D wprowadza modyfikację wyrobu. Z perspektywy technologicznej zmiana jest uzasadniona i została prawidłowo wdrożona. Ale zmiana produktu może uruchamiać konsekwencje w kilku miejscach jednocześnie. Trzeba ustalić jej znaczenie regulacyjne, ocenić wpływ na dokumentację techniczną, certyfikację, informacje o produkcie, UDI i dane znajdujące się w EUDAMED. o ile proces zarządzania zmianą nie łączy tych obszarów, firma może mieć prawidłowo zmodyfikowany produkt i jednocześnie nieaktualny obraz tego produktu w systemie regulacyjnym. Dlatego odpowiedzialność za EUDAMED nie powinna zaczynać się w chwili logowania do bazy. Powinna zaczynać się wcześniej – w procedurach change management. Certyfikat tworzy kolejne źródło danych. Podobny problem dotyczy informacji o certyfikatach. Moduł Notified Bodies & Certificates również stał się obowiązkowy 28 maja 2026 r. Jednostki notyfikowane rejestrują w nim informacje dotyczące wydanych certyfikatów, ich zmian, uzupełnień, zawieszenia, przywrócenia, cofnięcia, odmowy wydania czy innych ograniczeń. Informacje te są publicznie dostępne. To oznacza, iż dane producenta nie funkcjonują w izolacji. Mogą być zestawiane z informacjami pochodzącymi od jednostki notyfikowanej. o ile system producenta wskazuje jedno, certyfikat drugie, a EUDAMED trzecie, nie jest to już problem estetyki danych. Powstaje pytanie, który obraz produktu jest prawidłowy. Publiczna baza zmienia znaczenie błędu. EUDAMED ma zwiększać transparentność rynku. Część informacji jest dostępna nie tylko organom, ale również profesjonalistom medycznym, kontrahentom i opinii publicznej. To zmienia konsekwencje błędu. Nieprawidłowa informacja w wewnętrznym arkuszu może zostać zauważona i poprawiona przez pracownika. Nieprawidłowa informacja w europejskiej bazie regulacyjnej może być dostrzeżona przez organ nadzoru, jednostkę notyfikowaną, dystrybutora, szpital albo konkurenta. Jakość danych staje się więc również elementem reputacji regulacyjnej producenta. Kto powinien być właścicielem danych? Najprostsza odpowiedź brzmiałaby: Regulatory Affairs. Byłaby jednak niewystarczająca. RA może odpowiadać za proces regulacyjny i formalne wprowadzenie danych, ale nie jest źródłem wszystkich informacji. R&D wie, co zmieniło się w produkcie. Quality posiada informacje dotyczące systemu jakości i procesów. Dział kliniczny zarządza częścią danych klinicznych. Produkcja zna rzeczywiste parametry procesu. IT utrzymuje systemy, z których dane są pobierane. Zarząd podejmuje decyzje dotyczące portfolio i rynku. Dlatego lepszym modelem nie jest wskazanie jednej osoby, która „odpowiada za EUDAMED”. Potrzebne jest ustalenie właścicieli poszczególnych danych i procesu, który zapewnia ich spójność. Jedna funkcja powinna wiedzieć, kto jest źródłem informacji, kto ją zatwierdza, gdzie jest ona wykorzystywana i jakie inne dane trzeba zmienić, o ile zmienia się informacja źródłowa. To klasyczne data governance – tyle iż dotyczące danych regulacyjnych.„Mamy procedurę” może nie wystarczyćPrzy kontroli problemem może nie być samo istnienie błędu. Znaczenie będzie miało również to, czy przedsiębiorstwo potrafi wykazać, w jaki sposób zarządza jakością informacji. Kto zatwierdził zmianę? Kiedy ustalono, iż wymaga aktualizacji danych? Kto miał obowiązek ją przeprowadzić? Czy aktualizacja została zweryfikowana? Dlaczego rozbieżność nie została wcześniej wykryta? W przedsiębiorstwie posiadającym setki albo tysiące wyrobów odpowiedź nie może zależeć od pamięci jednej osoby. Musi wynikać z systemu. EUDAMED może ujawnić słabość organizacji. I właśnie tu znajduje się najciekawszy aspekt nowej fazy funkcjonowania EUDAMED. Baza nie tworzy wszystkich problemów związanych z danymi. Część z nich istniała wcześniej. EUDAMED powoduje natomiast, iż trudniej je ukryć w rozproszonych systemach, arkuszach i departamentach. o ile przedsiębiorstwo nie ma spójnego master data dla produktów, niewłaściwie zarządza zmianami albo nie określiło właścicieli informacji regulacyjnych, europejska baza może stać się miejscem, w którym te słabości staną się widoczne. Dlatego wdrożenie EUDAMED nie powinno kończyć się szkoleniem użytkowników systemu. Powinno prowadzić do pytania o architekturę odpowiedzialności wewnątrz przedsiębiorstwa. Z sześciu modułów działają obowiązkowo cztery. To dopiero początek. Warto pamiętać, iż EUDAMED składa się z sześciu powiązanych modułów. Obowiązkowe są w tej chwili cztery. Moduły dotyczące vigilance i PMS oraz badań klinicznych i badań działania mają zostać uruchomione później. Oznacza to, iż zakres danych regulacyjnych funkcjonujących w jednym europejskim ekosystemie będzie się zwiększał. Przedsiębiorstwo, które dziś uporządkuje odpowiedzialność za dane wyłącznie na potrzeby aktualnie obowiązkowych