Udostępnij

Klasyfikacja software’u medycznego w MDR. Reguła 11 nadal kluczowa dla producentów

Klasyfikacja software’u medycznego w MDR i reguła 11
Doctor, hospital and healthcare with futuristic bones in fracture, broken foot or cancer surgery analytics in night planning. Hologram, abstract and future body scan for thinking nurse or woman ideas.

Klasyfikacja software’u medycznego w MDR pozostaje jednym z najważniejszych tematów dla producentów cyfrowych wyrobów medycznych. Izba POLMED wskazuje, że proponowane zmiany w MDR mogą wprowadzić bardziej proporcjonalne podejście do reguły 11, uwzględniające nie tylko obszar medyczny, którego dotyczy oprogramowanie, ale także jego realny wpływ na decyzje kliniczne i dalsze postępowanie z pacjentem.

Izba POLMED opublikowała 13 maja 2026 r. materiał poświęcony klasyfikacji oprogramowania medycznego w MDR i problemom związanym z regułą 11. Tekst powstał w ramach cyklu „Prawo i Wyroby Medyczne – Legislacja w praktyce” i odnosi się do proponowanych zmian w MDR dotyczących software’u medycznego. W rozmowie udział wzięli mec. Oskar Luty z Kancelarii Fairfield oraz Kornel Lukaszczyk, dyrektor jednostki notyfikowanej TÜV NORD Polska.

Reguła 11 od początku obowiązywania MDR była jednym z najbardziej problematycznych obszarów dla producentów oprogramowania medycznego. Jak wskazuje POLMED, nowe przepisy znacznie bardziej rygorystycznie podeszły do klasyfikacji software’u niż wcześniejsze regulacje. W praktyce wiele rozwiązań wspierających decyzje kliniczne, diagnostykę lub analizę danych pacjenta przestawało być traktowanych jako wyroby klasy I i trafiało do klasy IIa, IIb, a nawet III.

To miało bezpośrednie konsekwencje dla producentów. Wyższa klasa ryzyka oznacza udział jednostki notyfikowanej, bardziej rozbudowaną dokumentację techniczną, większy zakres oceny klinicznej, dłuższy czas wejścia na rynek oraz wyższe koszty zgodności. Dla małych i średnich firm rozwijających software medyczny mogło to oznaczać istotną barierę w komercjalizacji produktu.

Według POLMED jednym z głównych problemów obecnej reguły 11 jest jej nieprecyzyjność. Aktualne przepisy koncentrują się przede wszystkim na ciężkości choroby, której dotyczy oprogramowanie, natomiast w mniejszym stopniu uwzględniają to, jak realnie software wpływa na decyzje terapeutyczne i bezpieczeństwo pacjenta. To prowadziło do sporów interpretacyjnych między producentami, jednostkami notyfikowanymi i organami nadzoru.

Problem dobrze widać w praktyce. Oprogramowanie analizujące dane dotyczące ciężkiej choroby może zostać zakwalifikowane do wysokiej klasy ryzyka nawet wtedy, gdy jego rola ogranicza się do wsparcia informacyjnego dla lekarza. Jednocześnie inne rozwiązanie software’owe może realnie wpływać na decyzję o dalszym postępowaniu z pacjentem, np. w triage’u lub kwalifikacji do pilnego leczenia, mimo że technicznie dotyczy podobnego obszaru medycznego. POLMED przywołuje w tym kontekście stanowisko Kornela Lukaszczyka, który zwraca uwagę na brak wystarczającego uwzględnienia rzeczywistego wpływu informacji generowanej przez software na dalsze postępowanie z pacjentem.

Proponowane zmiany w MDR mają wprowadzić bardziej proporcjonalne podejście do klasyfikacji oprogramowania medycznego. Według POLMED nowelizacja zakłada uwzględnienie dodatkowego parametru: wpływu oprogramowania na decyzje kliniczne i dalsze postępowanie z pacjentem. W praktyce mogłoby to pozwolić na lepsze rozróżnienie między software’em wspierającym lekarza w sposób pomocniczy a rozwiązaniami, które mają bezpośredni wpływ na decyzje diagnostyczne lub terapeutyczne.

Dla producentów software’u medycznego to bardzo istotny kierunek. Bardziej proporcjonalna klasyfikacja mogłaby ograniczyć sytuacje, w których produkt o pomocniczej funkcji informacyjnej jest traktowany podobnie jak system mający bezpośredni wpływ na decyzję kliniczną. Jednocześnie nie oznacza to braku obowiązków. Software medyczny nadal wymaga kontroli ryzyka, dokumentacji technicznej, walidacji, nadzoru po wprowadzeniu do obrotu, zarządzania zmianą i cyberbezpieczeństwa.

Warto w tym miejscu dodać link wewnętrzny do tekstu Med Industry o AI Act i wyrobach medycznych z AI, ponieważ oba tematy będą coraz częściej nakładać się na siebie w przypadku cyfrowych wyrobów medycznych, systemów wspomagania decyzji i oprogramowania wykorzystującego dane medyczne.

POLMED wskazuje również, że część problemów pozostaje nierozwiązana. Dotyczy to m.in. aplikacji lifestyle’owych, narzędzi przesiewowych, oprogramowania przekazującego jedynie rekomendację konsultacji lekarskiej oraz granicy między informacją zdrowotną a diagnostyką medyczną. To obszary, w których nadal mogą pojawiać się wątpliwości dotyczące tego, kiedy software staje się wyrobem medycznym oraz jaka klasyfikacja powinna mieć zastosowanie.

Dla firm rozwijających aplikacje, systemy zdalnego monitorowania, narzędzia AI lub platformy wspierające decyzje kliniczne oznacza to konieczność bardzo precyzyjnego określenia przeznaczenia produktu. To właśnie intended purpose, deklaracje producenta, sposób prezentowania wyniku i wpływ na decyzje użytkownika profesjonalnego mogą przesądzać o tym, czy dany produkt zostanie uznany za wyrób medyczny i do jakiej klasy ryzyka trafi.

W praktyce producenci software’u powinni szczególnie uważać na język używany w dokumentacji, materiałach marketingowych i opisie funkcjonalności. Jeżeli aplikacja jest przedstawiana jako narzędzie wspierające diagnostykę, terapię, triage lub monitorowanie pacjenta, może wejść w zakres MDR. Jeśli natomiast ma wyłącznie charakter informacyjny, edukacyjny lub lifestyle’owy, analiza może prowadzić do innych wniosków. Granica nie zawsze jest oczywista, dlatego klasyfikacja powinna być wykonana wcześnie, a nie dopiero na etapie gotowego produktu.

Temat dobrze łączy się z wcześniejszym tekstem Med Industry o traceability dokumentacji wyrobów medycznych i wykorzystaniu AI w dokumentacji. W software medycznym zarządzanie wersjami, opis zmian, walidacja algorytmów i historia decyzji projektowych mają szczególne znaczenie. Link wewnętrzny warto wstawić do artykułu: „Enlil i OVA Solutions wdrażają AI do traceability dokumentacji wyrobów medycznych”.

Dla dostawców technologii to również ważny sygnał. Rynek będzie potrzebował rozwiązań wspierających producentów w zarządzaniu cyklem życia software’u, dokumentacją techniczną, testami, cybersecurity, walidacją, monitoringiem działania po wdrożeniu i przygotowaniem danych dla jednostek notyfikowanych. W przypadku cyfrowych wyrobów medycznych przewaga nie będzie wynikała wyłącznie z funkcjonalności produktu, ale także z tego, czy firma potrafi utrzymać zgodność regulacyjną przez cały cykl życia rozwiązania.

Reguła 11 pozostaje więc jednym z najważniejszych tematów dla europejskiego rynku cyfrowych wyrobów medycznych. Jeżeli proponowane zmiany MDR zostaną przyjęte, mogą uporządkować część obecnych wątpliwości. Nie usuną jednak potrzeby dokładnej analizy przeznaczenia, wpływu na decyzje kliniczne, ryzyka dla pacjenta i obowiązków producenta.


Opracowanie własne na podstawie:
Izba POLMED / Data publikacji: 13 maja 2026 / Materiał „Klasyfikacja oprogramowania w MDR – koniec chaosu w regule 11?” – https://polmed.org.pl/klasyfikacja-oprogramowania-w-mdr-koniec-chaosu-w-regule-11/

Newsletter

Zapisz się do newslettera

i otrzymuj wyselekcjonowane informacje z rynku wyrobów medycznych.

Informacja profesjonalna (MDR)

Portal przeznaczony jest wyłącznie dla profesjonalistów. Zawarte tu treści o charakterze technicznym i regulacyjnym dotyczą Rozwoju, produkcji oraz certyfikacji wyrobów medycznych i są kierowane do producentów oraz dostawców. Materiały nie są przeznaczone dla osób trzecich, nie stanowią porad medycznych ani ofert dla konsumentów. Wejście do serwisu oznacza potwierdzenie statusu profesjonalisty.

Nie jestem profesjonalistą – wychodzę