Narzędzie AI w EUDAMED: 5 dowodów przed zakupem

Przed zakupem narzędzia AI deklarowanego jako wyrób medyczny nie pytaj tylko: „czy jest w EUDAMED?”. Pytaj: czy rekord dotyczy produktu pokazanego na demo oraz czy dokumenty obejmują wersję, którą placówka ma faktycznie dostać. Jedna zgodna nazwa handlowa to za mało, by podpisać umowę.

Od 28 maja 2026 r. cztery pierwsze moduły EUDAMED są obowiązkowe, ale nadal działają przepisy przejściowe dla części wyrobów i certyfikatów. Dlatego brak rekordu nie zawsze oznacza naruszenie, a obecność rekordu nie jest gwarancją skuteczności klinicznej. Manager musi sprawdzić datę wprowadzenia produktu do obrotu, dokumenty przejściowe i powiązanie identyfikatorów.

Jeśli zespół używa AI do streszczania długich dokumentów, traktowałbym wynik wyłącznie jako mapę do źródeł, nie jako opinię o zgodności. Człowiek weryfikuje każdy dowód w dokumencie pierwotnym, dyrektor medyczny zatwierdza użycie kliniczne, a IOD ocenia przepływ danych. Model nie może sam potwierdzić, że jego własna wersja jest bezpieczna.

Najważniejsze

• EUDAMED identyfikuje i łączy informacje, lecz nie zastępuje oceny zgodności, dowodów klinicznych ani nadzoru po wprowadzeniu produktu do obrotu.
• Basic UDI-DI nie wystarcza do ustalenia wdrożonego buildu; dostawca powinien pokazać cały łańcuch wersja → UDI-PI → UDI-DI → Basic UDI-DI.
• Przeznaczenie wyrobu wyznacza granice użycia. Slajd sprzedażowy nie rozszerza instrukcji używania ani oceny klinicznej producenta.
• SSCP nie jest obowiązkowe dla każdego software’u medycznego; najpierw sprawdź klasę i okres przejściowy, potem żądaj właściwego dokumentu lub wyjaśnienia.
• Zakup nie kończy kontroli. Placówka potrzebuje właściciela monitorowania wersji, incydentów, działań korygujących i zmian dokumentacji.

Ta sama nazwa na slajdzie, inna wersja w gabinecie

Najczęstsza pułapka nie wygląda spektakularnie. W prezentacji jest „MedAI Pro”, w umowie ta sama nazwa, a w dokumentacji Basic UDI-DI dla rodziny produktów. Tymczasem instalowana wersja ma inny algorytm, zmieniony interfejs albo nowe źródło danych. To właśnie zgodność konkretnej wersji trzeba udowodnić przed wdrożeniem.

Basic UDI-DI łączy wyroby o tym samym przeznaczeniu, klasie ryzyka i podstawowych cechach konstrukcyjnych. UDI-DI schodzi niżej — do konkretnego modelu, wariantu lub wersji. Dla oprogramowania dochodzi identyfikacja produkcyjna, czyli UDI-PI. Publiczny rekord nie pokazuje zawsze wartości UDI-PI, więc placówka nie odczyta z niego automatycznie numeru buildu. Potrzebuje pisemnego mapowania od dostawcy.

Jeżeli dopiero ustalasz, czy dane rozwiązanie w ogóle powinno być traktowane jako wyrób, najpierw przeczytaj analizę AI jako wyrób medyczny. Tutaj przyjmujemy już deklarację dostawcy i sprawdzamy coś innego: czy wszystkie dowody opisują ten sam produkt, a nie podobnie nazwaną rodzinę.

Ranking pięciu dowodów: od identyfikacji do nadzoru

To nie jest podium, na którym pierwszy dowód jest ważny, a piąty opcjonalny. Traktuj ranking jak pięć kolejnych bramek: każda odpowiada na inne pytanie i brak jednej zatrzymuje decyzję zakupową do czasu wyjaśnienia. Dopiero komplet pozwala sensownie porównać kandydatów.

1. Basic UDI-DI i producent

Poproś o Basic UDI-DI, nazwę prawną producenta i jego SRN, a następnie otwórz bezpośredni rekord w publicznym EUDAMED. Porównaj klasę ryzyka, nazwę handlową, jednostkę notyfikowaną i powiązane certyfikaty. Materiał przesłany jako zrzut ekranu nie wystarcza — potrzebny jest link, który placówka może sprawdzić ponownie.

Ten identyfikator jest dobrym początkiem, bo łączy certyfikat, deklarację zgodności i dokumentację rodziny wyrobów. Nie dowodzi jednak, który build zostanie zainstalowany ani czy obietnica z prezentacji mieści się w przeznaczeniu. Czerwona flaga pojawia się, gdy dostawca podaje wyłącznie znak CE lub nazwę produktu, ale unika identyfikatora.

2. Łańcuch wersja → UDI-PI → UDI-DI

Drugi dowód to pisemna mapa: numer wersji i buildu oferowanego placówce, sposób identyfikacji UDI-PI, właściwy UDI-DI oraz nadrzędny Basic UDI-DI. Poproś też o regułę, według której producent uznaje zmianę za większą albo mniejszą. W software poprawka bezpieczeństwa może zmienić UDI-PI, a zmiana wpływająca na działanie, bezpieczeństwo, interpretację danych lub przeznaczenie może wymagać nowego UDI-DI.

Ja bym wpisał ten łańcuch do załącznika technicznego umowy. Dzięki temu aktualizacja nie przechodzi po cichu z „6.2” do „6.4”, gdy dokumenty nadal dotyczą starszego wariantu. Niezgodność wersji oznacza pauzę, nie prośbę o późniejsze dosłanie papierów po uruchomieniu.

3. Literalne przewidziane zastosowanie

Trzeci dowód odpowiada na pytanie: do czego producent naprawdę przeznaczył wyrób. Otwórz aktualną instrukcję używania i wypisz użytkownika, populację, wskazania, przeciwwskazania, rodzaj danych wejściowych, znaczenie wyniku oraz rolę człowieka. Następnie zestaw to z procesem planowanym w polskiej przychodni lub klinice.

Jeżeli instrukcja mówi o wsparciu lekarza w ocenie obrazu, prezentacja handlowa nie może po drodze zmienić produktu w autonomiczny triage. Użycie poza przeznaczeniem nie staje się zgodne dlatego, że technicznie działa. Przy decyzjach klinicznych wynik AI pozostaje materiałem pomocniczym, a uprawniony lekarz interpretuje dane i zatwierdza decyzję.

4. Aktualne SS(C)P — jeśli jest wymagane

SSCP, czyli podsumowanie bezpieczeństwa i działania klinicznego, jest wymagane na gruncie MDR dla wyrobów implantowanych i klasy III. Dla wyrobów IVD klas C i D właściwym dokumentem jest SSP. Brak SSCP dla nieimplantowalnego software’u klasy IIa lub IIb nie jest automatycznie błędem; trzeba sprawdzić klasę i poprosić o adekwatne dowody kliniczne, deklarację zgodności oraz dokumenty jednostki notyfikowanej.

W czerwcu 2026 r. MDCG opisała przejściowy sposób publikowania SS(C)P po obowiązkowym starcie pierwszych modułów EUDAMED. Dla nowych certyfikatów i aktualizacji dokument nadal wgrywa jednostka notyfikowana do czasu uruchomienia nowej funkcjonalności, a dla części starszych wyrobów rekord może jeszcze nie mieć certyfikatu lub SS(C)P. Nie akceptuj pustego pola bez wyjaśnienia, ale też nie wydawaj wyroku bez sprawdzenia terminu migracji. Poproś o kopię zatwierdzoną przez jednostkę i wskaż, kto ma uzupełnić rekord.

5. Właściciel monitorowania po wdrożeniu

Piąty dowód nie mieści się w jednym polu EUDAMED. Moduł Vigilance i nadzoru po wprowadzeniu do obrotu nadal jest rozwijany, więc publiczna baza nie daje dziś pełnej historii PMS. Dostawca powinien wskazać właściciela procesu, cykl aktualizacji PMS lub PSUR, ścieżkę zgłaszania incydentów, działania FSCA/CAPA oraz sposób informowania placówki o zmianie wersji i dokumentacji.

Placówka także potrzebuje właściciela: osoby, która raz w miesiącu lub przed każdą aktualizacją sprawdza komunikaty, wersję, certyfikat i nowe ograniczenia. Zakup bez przypisanej odpowiedzialności tworzy martwy rejestr. Wyrób może być poprawnie wybrany w lipcu, a źle używany po październikowej aktualizacji.

Poniższe zestawienie nie zastępuje dokumentów. Służy do szybkiego sprawdzenia, czy pięć dowodów tworzy jeden spójny łańcuch, oraz wskazuje moment, w którym manager powinien zatrzymać ocenę.

Karta decyzji zakupowej: pięć pól albo stop

Sugeruję jedną kartę na każdego kandydata. Nie punktuj jakości prezentacji ani liczby funkcji. Wpisz link do dowodu, datę weryfikacji, właściciela i wynik dla pięciu pól:

1. Basic UDI-DI oraz zgodny producent i SRN.
2. Mapa buildu do UDI-PI, UDI-DI i Basic UDI-DI.
3. Przeznaczenie zgodne z planowanym procesem placówki.
4. Właściwe i aktualne SS(C)P albo uzasadniony pakiet dokumentów zastępczych.
5. Właściciel oraz ślad PMS, incydentów, działań korygujących i aktualizacji.

Wynik 5/5 bez sprzeczności oznacza, że kandydat może przejść do kontrolowanego pilotażu — nie że należy go automatycznie kupić. Wynik 4/5 oznacza wstrzymanie, a nie warunkowy podpis. Przy 3/5 lub rozbieżności wersji albo przeznaczenia kończyłbym ocenę do czasu dostarczenia nowych dowodów.

Dwie metryki wystarczą na start: odsetek kandydatów z kompletem zweryfikowanych dowodów oraz czas potrzebny na ponowne sprawdzenie dokumentów po aktualizacji. Jeśli zespół nie umie odtworzyć decyzji bez opiekuna handlowego dostawcy, karta nie spełnia swojej funkcji.

Co robi klinika, gdy dokumenty nie zgadzają się z demo

Przykład modelowy — scenariusz pokazuje sposób myślenia o pilotażu. Liczby ilustrują metryki, nie gwarantują wyniku wdrożenia.

Prywatne centrum diagnostyczne porównuje dwa systemy AI wspierające radiologa w porządkowaniu listy badań. Dostawca A pokazuje build 6.4, lecz przesłany certyfikat i instrukcja wskazują wariant 6.2. Przeznaczenie mówi o wsparciu oceny obrazu przez lekarza, podczas gdy prezentacja obiecuje samodzielne przesuwanie badań w kolejce. To dwie sprzeczności, więc manager zatrzymuje ocenę przed integracją.

Dostawca dosyła mapę wersji, aktualną instrukcję i wyjaśnienie jednostki notyfikowanej. Dopiero wtedy centrum uruchamia ograniczony test w zatwierdzonym środowisku, bez wynoszenia danych pacjentów do publicznego modelu. Radiolog sprawdza każdy wynik AI, a system nie zmienia kolejności ani opisu badania bez jego zatwierdzenia. Manager zapisuje wersję, datę i wynik w karcie decyzji.

Ten przykład pokazuje, po co jest human-in-the-loop. AI może porządkować listę i wskazywać rozbieżności, ale nie rozstrzyga, czy dokument prawny obejmuje konkretny build ani czy wynik kliniczny jest prawidłowy. Odpowiedzialność zostaje po stronie uprawnionych osób w placówce.

Gdzie kończy się rola AI, a zaczyna odpowiedzialność

Model językowy może pomóc znaleźć numery identyfikatorów, zestawić daty i zaznaczyć różnice między dokumentami. To przydatne, o ile pracuje na zatwierdzonych materiałach i każde twierdzenie prowadzi do źródła pierwotnego. Nie powierzaj mu samodzielnej interpretacji MDR, walidacji SSCP ani oceny dowodów klinicznych.

Podział ról powinien być prosty: manager zakupowy pilnuje kompletności, dyrektor medyczny zatwierdza dopasowanie do procesu klinicznego, IOD i bezpieczeństwo informacji oceniają dane oraz środowisko, a dostawca odpowiada za mapę wersji i nadzór produktu. Lekarz pozostaje osobą podejmującą decyzję kliniczną; model przygotowuje kontekst i wskazuje wyjątki.

Nie wklejaj do ogólnego modelu danych pacjentów, raportów z realnymi przypadkami ani dokumentów zawierających niepotrzebne dane osobowe. Due diligence produktu nie wymaga historii choroby ani PESEL-u. Jeżeli test ma używać danych klinicznych, musi odbyć się w zatwierdzonym środowisku, na podstawie udokumentowanej decyzji placówki i z kontrolą człowieka.

Kiedy iść do pilotażu, a kiedy zakończyć rozmowę

To ma sens, gdy… wszystkie pięć dowodów dotyczy tego samego produktu, wersji i przeznaczenia, a placówka ma właściciela aktualizacji oraz zatwierdzony punkt kontroli lekarza. Wtedy pilot może sprawdzić dopasowanie do procesu, ergonomię i jakość działania bez udawania, że rekord w bazie przewiduje wynik wdrożenia.

To nie ma sensu, gdy… dostawca zasłania się samym znakiem CE, nie mapuje buildu do UDI, rozszerza przeznaczenie w prezentacji albo nie pokazuje, kto monitoruje incydenty i zmiany. Czerwona flaga nie jest zaproszeniem do szybszego pilotażu — jest powodem, by zatrzymać zakup.

W okresie przejściowym dopuszczalna odpowiedź może brzmieć: „rekord lub certyfikat będzie uzupełniony do terminu wynikającego z przepisów”. Musi jednak wskazywać konkretną podstawę, datę i dokument zastępczy. Ogólne „EUDAMED jeszcze nie działa” po 28 maja 2026 r. nie opisuje już poprawnie sytuacji czterech obowiązkowych modułów.

Checklista pierwszej wiadomości do dostawcy

Zacznij od prośby o Basic UDI-DI oraz bezpośredni link do właściwego rekordu i dokumentacji w EUDAMED. W jednej wiadomości zbierz komplet wejść do karty decyzji:

• numer wersji i buildu oferowanego placówce;
• mapę buildu do UDI-PI, UDI-DI i Basic UDI-DI;
• aktualną instrukcję z literalnym przeznaczeniem;
• SS(C)P albo wyjaśnienie, dlaczego dokument nie jest wymagany lub jeszcze nie widnieje w rekordzie;
• rolę właściciela PMS, cykl przeglądu i sposób przekazywania informacji o incydentach, FSCA/CAPA oraz aktualizacjach.

Poproś, aby dostawca odpowiedział linkami i załącznikami źródłowymi, nie własnym streszczeniem. Wyznacz jedną osobę po stronie placówki, która zapisze datę weryfikacji i wynik pięciu bramek. Ja bym nie przechodził do ceny ani integracji, dopóki nie da się odtworzyć tego łańcucha dowodów bez udziału handlowca.

Źródła

• MDCG 2026-4 — Management of SS(C)P in EUDAMED after mandatory use — stanowisko z czerwca 2026 r. wyjaśnia bieżący podział obowiązków przy publikacji SS(C)P, okres przejściowy i powiązanie dokumentu z Basic UDI-DI; opublikowano: 18 czerwca 2026 r.; Sprawdzono: 2026-07-11.
• Komisja Europejska — EUDAMED: stan wdrożenia — oficjalny wykaz czterech modułów obowiązkowych od 28 maja 2026 r. oraz informacja, że Vigilance/PMS i badania kliniczne pozostają w rozwoju; Sprawdzono: 2026-07-11.
• URPL — komunikat o obowiązkach i terminach EUDAMED — polskie źródło urzędowe precyzuje terminy rejestracji wyrobów i certyfikatów oraz wyjątki przejściowe; opublikowano: 6 marca 2026 r.; Sprawdzono: 2026-07-11.
• Komisja Europejska — Basic UDI-DI i UDI-DI — oficjalna infografika rozróżnia klucz rodziny wyrobów od identyfikatora konkretnego modelu, wariantu lub wersji; Sprawdzono: 2026-07-11.
• MDCG 2018-5 — UDI Assignment to Medical Device Software — wytyczne opisują, kiedy zmiana oprogramowania wymaga nowego UDI-DI, a kiedy tylko nowego UDI-PI; opublikowano: październik 2018 r.; Sprawdzono: 2026-07-11.
• Rozporządzenie (UE) 2017/745 — tekst skonsolidowany — pierwotna podstawa definicji przeznaczenia, UDI, SSCP oraz obowiązków nadzoru po wprowadzeniu do obrotu; wersja skonsolidowana: 1 stycznia 2026 r.; Sprawdzono: 2026-07-11.
• Okładka: Gustavo Fring na Pexels