Czy AI używany w diagnostyce musi mieć certyfikat wyrobu medycznego?

Tak, jeśli oprogramowanie AI zostało zaprojektowane i sprzedawane z przeznaczeniem do wspomagania diagnozy, analizy obrazów medycznych lub proponowania leczenia, podlega rozporządzeniu MDR (EU 2017/745) jako Software as Medical Device, czyli SaMD. Dostawca musi posiadać oznaczenie CE z odpowiednią klasą ryzyka, a Ty jako dyrektor lub menedżer placówki powinieneś te dokumenty zobaczyć zanim oprogramowanie trafi do gabinetu lekarskiego. Jeśli AI obsługuje tylko rejestrację pacjentów, grafiki dyżurów albo sprawozdawczość do NFZ, certyfikacja wyrobu medycznego nie jest potrzebna.

Kiedy AI to wyrób medyczny, a kiedy zwykłe oprogramowanie

Granica biegnie przez jedno słowo: przeznaczenie. Producent deklaruje je w dokumencie zwanym Instrukcją Używania (IFU, ang. Instructions for Use). Jeśli z IFU wynika, że oprogramowanie służy do rozpoznawania, monitorowania, leczenia lub zapobiegania chorobie albo urazie, podlega MDR. Bez wyjątków, bez strefy szarej po tej stronie granicy.

W praktyce podział wygląda tak:

• Wymaga certyfikatu MDR: AI analizujące zdjęcia RTG, TK lub MRI, systemy wykrywające migotanie przedsionków w EKG, oprogramowanie do wstępnej triażu w SOR, narzędzia sugerujące dawkowanie leków przy konkretnym rozpoznaniu, systemy oceny ryzyka klinicznego przed zabiegiem.
• Nie wymaga certyfikatu: AI do planowania dyżurów, chatboty rejestracyjne, systemy do rozliczeń z NFZ, narzędzia do analizy obłożenia łóżek, oprogramowanie zarządzające magazynem leków.
• Szara strefa: AI transkrybujące i strukturyzujące wizyty lekarskie. Jeśli system tylko kopiuje tekst i wpisuje go w pola dokumentacji, to narzędzie administracyjne. Jeśli przy okazji interpretuje treść i proponuje rozpoznanie ICD-10 albo kod JGP, to może być SaMD i wymagać certyfikatu.

Typowo wygląda to tak: dostawca oferuje "moduł wspomagania diagnostyki" jako część większego systemu HIS. Sam HIS nie jest wyrobem medycznym, ale ten jeden moduł już tak. Dostawca ma CE tylko na część administracyjną systemu. Taką sytuację odkrywa się dopiero przy analizie IFU, nie przy pierwszym pokazie produktu u dyrektora.

Dodatkowa pułapka: niektórzy dostawcy opisują swoje AI jako "narzędzie informacyjne" lub "system wspomagania decyzji" właśnie po to, żeby uniknąć obowiązku certyfikacji MDR. Jeśli reklamują produkt jako pomocny przy diagnozie, ale w umowie i IFU piszą, że to tylko "prezentacja danych", zapytaj wprost, która wersja jest prawdziwa. Odpowiedź wiele mówi.

Cztery klasy wyrobów medycznych i co oznaczają przy zakupie AI

MDR dzieli wyroby na cztery klasy ryzyka. Klasa I to najniższe ryzyko, klasa III najwyższe. Dla oprogramowania diagnostycznego AI najczęściej trafiamy na klasy IIa i IIb.

• Klasa I: Producent samodzielnie wystawia Deklarację Zgodności, bez udziału zewnętrznej Jednostki Notyfikowanej. Jeśli dostawca AI do analizy obrazów TK pokazuje Ci certyfikat klasy I, zapytaj wprost, dlaczego produkt jest tak nisko sklasyfikowany i na czym opiera tę klasyfikację.
• Klasa IIa: Wymagany przegląd przez Jednostkę Notyfikowaną (Notified Body). Jej numer, czterocyfrowy, pojawia się obok znaku CE, np. CE 0123. Większość oprogramowania diagnostycznego AI trafia właśnie tu.
• Klasa IIb: Podobne wymagania co IIa, ale bardziej szczegółowy audyt dokumentacji technicznej i głębsza weryfikacja walidacji klinicznej przeprowadzonej przez producenta.
• Klasa III: Dla wyrobów bezpośrednio wpływających na podstawowe funkcje życiowe lub wszczepialnych. W kontekście oprogramowania AI to rzadkość, ale kategoria istnieje.

Certyfikat MDR ma datę ważności. Nie jest wystawiony raz na zawsze. Przy przedłużaniu umowy z dostawcą sprawdź, czy certyfikat jest aktualny i kiedy wygasa. Przeterminowany certyfikat oznacza, że produkt technicznie nie ma prawa być w tym czasie sprzedawany jako wyrób medyczny klasy IIa lub wyżej.

Jakie dokumenty sprawdzić przed podpisaniem umowy

Nie musisz rozumieć każdego paragrafu technicznego, żeby zrobić sensowną weryfikację. Poproś dostawcę mailem o cztery konkretne dokumenty przed jakąkolwiek rozmową o cenie czy harmonogramie:

• Deklaracja Zgodności (Declaration of Conformity) z aktualną datą wystawienia, wskazaniem klasy wyrobu i podpisem upoważnionej osoby ze strony producenta.
• Instrukcja Używania (IFU) w języku polskim lub co najmniej angielskim. Przeczytaj sekcję "przeznaczenie" i "ograniczenia". Jeśli dostawca odmawia udostępnienia IFU przed zakupem, to sygnał ostrzegawczy.
• Certyfikat Jednostki Notyfikowanej przy klasie IIa i wyżej, z numerem tej jednostki i datą wygaśnięcia certyfikatu.
• Numer UDI (Unique Device Identification), który pozwala zidentyfikować konkretną wersję oprogramowania i zweryfikować ją w zewnętrznej bazie danych.

EUDAMED to europejska baza wyrobów medycznych prowadzona przez Komisję Europejską. Wpisujesz numer UDI i widzisz, czy produkt jest zarejestrowany, jaka jest jego klasa i przez którą Jednostkę Notyfikowaną przeszedł. Jeśli produktu nie ma w bazie, a dostawca twierdzi, że posiada CE, poproś o wyjaśnienie na piśmie.

Jeden szczegół przy zakupach przez przetarg: w SIWZ możesz wprost wymagać dołączenia Deklaracji Zgodności i numeru UDI do oferty. To eliminuje oferty produktów bez certyfikacji już na etapie formalnej oceny ofert, zanim w ogóle zaczniesz analizować funkcjonalności.

Kiedy AI Act i MDR obowiązują jednocześnie

Od 2025 roku zaczęły obowiązywać kolejne przepisy unijnego rozporządzenia o sztucznej inteligencji. I tu pojawia się sytuacja, którą warto znać: wiele systemów AI w diagnostyce medycznej podlega jednocześnie MDR i AI Act jako system wysokiego ryzyka.

Dla dyrektora oznacza to obowiązki z dwóch źródeł prawa. Z MDR wynika sprawdzenie certyfikacji wyrobu. Z AI Act wynikają m.in. obowiązek nadzoru nad działaniem systemu, szkolenie personelu używającego AI oraz prowadzenie dokumentacji wdrożenia po stronie placówki jako deployera.

Dobra wiadomość: jeśli system jest jednocześnie wyrobem medycznym, ocena zgodności z AI Act odbywa się w ramach procesu MDR. Jedno postępowanie certyfikacyjne pokrywa oba przepisy po stronie producenta. W umowie z dostawcą warto to zapisać explicite: które dokumenty i których obowiązków AI Act dotyczą, a które MDR, i co dostawca ma Ci jako deployerowi przekazać przy wdrożeniu.

Co zrobić, gdy dostawca nie ma certyfikatu MDR

Zdarza się. Szczególnie przy firmach, które weszły na rynek szybko i certyfikację mają "w toku". Trzy scenariusze i co z nimi zrobić:

• Dostawca twierdzi, że jego AI "nie jest wyrobem medycznym" i dlatego nie potrzebuje CE. Poproś o IFU, przeczytaj sekcję przeznaczenia. Jeśli system jest reklamowany jako wsparcie diagnostyczne, a dokumenty mówią co innego, masz do czynienia z niezgodnością. Uzyskaj stanowisko dostawcy na piśmie i skonsultuj je z radcą prawnym przed podpisaniem.
• Certyfikacja jest w toku, dostawca podaje termin jej ukończenia. Możesz rozmawiać o pilotażu w obszarze czysto administracyjnym do czasu uzyskania certyfikatu. Żadnych decyzji klinicznych bez CE.
• System pochodzi od dostawcy spoza UE i nie posiada europejskiego CE. Producent spoza Unii musi mieć Autoryzowanego Przedstawiciela na terenie UE i przejść pełną procedurę MDR. Brak takiego przedstawiciela to bariera prawna, nie formalność do pominięcia.

Ryzyko jest realne. Jeśli niezertyfikowany system AI przyczyni się do błędu medycznego, placówka jako podmiot wdrażający może być współodpowiedzialna za decyzję o użyciu oprogramowania bez certyfikacji w procesie klinicznym. Ubezpieczyciel placówki może to zakwestionować przy likwidacji szkody, szczególnie jeśli w aktach znajdzie się umowa z dostawcą, który wprost deklaruje brak przeznaczenia medycznego.

Od czego zacząć weryfikację w praktyce

Zanim zaczniesz rozmawiać o cenach i harmonogramie, wyślij dostawcy kilka pytań mailem. Odpowiedzi, lub ich brak, powiedzą Ci więcej niż godzinna prezentacja produktu.

• Jaka jest klasyfikacja MDR Waszego produktu i na jakiej podstawie ją ustaliliście?
• Czy możecie udostępnić Deklarację Zgodności i Instrukcję Używania przed podpisaniem umowy?
• Przez którą Jednostkę Notyfikowaną przeszedł produkt i kiedy wygasa certyfikat?
• Jaki jest numer UDI umożliwiający weryfikację w EUDAMED?
• Czy produkt jest objęty zakresem AI Act jako system wysokiego ryzyka i jaką dokumentację przekazujecie deployerowi przy wdrożeniu?

Przy pierwszym wdrożeniu AI w obszarze klinicznym skonsultuj umowę z radcą prawnym lub inspektorem ochrony danych. Zapisy dotyczące odpowiedzialności za działanie systemu i obowiązków dostawcy przy incydentach, wymaganych przez MDR, bywają lakoniczne i wymagają doprecyzowania, zanim cokolwiek podpiszesz.

Jeśli chcesz przejrzeć dokumentację MDR konkretnego dostawcy przed podjęciem decyzji lub nie wiesz, jak zakwalifikować planowany system, możesz skorzystać z naszego bezpłatnego audytu. Sprawdzamy dokumentację techniczną, klasyfikację MDR i zakres obowiązków z AI Act. Możesz też zobaczyć, jak wygląda to u innych, w realnych wdrożeniach.