Czy aplikacje zdrowotne to już wyrób medyczny?

Rynek aplikacji mobilnych i webowych z obszaru health & wellness rośnie w błyskawicznym tempie. Programy do monitorowania cyklu, aplikacje liczące kalorie, dzienniczki ciśnienia krwi czy asystenci treningowi goszczą na telefonach milionów użytkowników. Jednocześnie rośnie popularność rozwiązań opartych na algorytmach AI, które analizują parametry życiowe i sugerują wstępne rozpoznania.

Dla twórców takiego oprogramowania – startupów, firm IT oraz inwestorów – kluczowe staje się pytanie: czy aplikacja zdrowotna w świetle prawa stała się już wyrobem medycznym?

Odpowiedź na to pytanie ma fundamentalne znaczenie biznesowe. Kwalifikacja oprogramowania jako wyrobu medycznego (tzw. Software as a Medical Device – SaMD) oznacza konieczność przejścia kosztownego i czasochłonnego procesu certyfikacji, wdrożenia systemu zarządzania jakością (ISO 13485) oraz spełnienia rygorystycznych wymogów prawnych. Pomyłka w tej kwestii i wprowadzanie niecertyfikowanego wyrobu na rynek grozi surowymi sankcjami finansowymi i wstrzymaniem dystrybucji.

1. Przewidziane zastosowanie (Intended Purpose) – co rzeczywiście decyduje o kwalifikacji?

Wbrew obiegowej opinii o tym, czy aplikacja jest wyrobem medycznym, nie decyduje sama technologia, język programowania ani to, czy używa ona sztucznej inteligencji. Kluczowe znaczenie ma deklarowane przez producenta przeznaczenie oprogramowania (tzw. intended purpose).

Głównym aktem prawnym regulującym tę kwestię jest Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2017/745 (MDR). Zgodnie z art. 2 pkt 1 MDR oprogramowanie staje się wyrobem medycznym, jeżeli jest przeznaczone przez producenta do stosowania u ludzi w konkretnych celach medycznych, takich jak:

• diagnozowanie, zapobieganie, monitorowanie, przewidywanie, rokowanie, leczenie lub łagodzenie choroby;
• diagnozowanie, monitorowanie, leczenie, łagodzenie lub kompensowanie urazu lub niepełnosprawności;
• badanie, zastępowanie lub modyfikowanie budowy anatomicznej bądź procesu lub stanu fizjologicznego.

Gdzie leży granica między „wellness” a „medycyną”?

Samo gromadzenie, wyświetlanie lub archiwizowanie danych zdrowotnych (np. krokomierz, dziennik wypitej wody czy wykres wagi) nie czyni aplikacji wyrobem medycznym. Granica zostaje przekroczona w momencie, gdy aplikacja zaczyna przetwarzać, analizować lub interpretować dane pacjenta w celu wygenerowania informacji o charakterze diagnostycznym lub terapeutycznym.

Wskazówka: Jeśli Państwa aplikacja przelicza dane wejściowe i sugeruje użytkownikowi np. zmianę dawki leku, informuje o ryzyku zawału lub stawia wstępną diagnozę – w świetle prawa staje się wyrobem medycznym, niezależnie od tego, czy w regulaminie znajduje się zastrzeżenie: „To nie jest porada medyczna”. Warto przy tym pamiętać, że zgodnie z art. 7 MDR zakazane jest posługiwanie się opisami wprowadzającymi użytkownika w błąd co do przeznaczenia wyrobu – a materiały marketingowe, opis w sklepie z aplikacjami czy komunikacja w mediach społecznościowych współokreślają deklarowane przeznaczenie na równi z regulaminem.

Wytyczne MDCG 2019-11 i tzw. Reguła 11

Aby precyzyjnie ustalić, czy dane oprogramowanie podlega pod MDR, Komisja Europejska wydała oficjalne wytyczne MDCG 2019-11 (Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR i Regulation (EU) 2017/746 – IVDR). Dokument ten zawiera algorytm decyzyjny (tzw. decision tree), który pozwala deweloperom krok po kroku ocenić status prawny aplikacji. W czerwcu 2025 r. opublikowano zrewidowaną wersję wytycznych (MDCG 2019-11 Rev. 1) i to ona stanowi obecnie punkt odniesienia. Rozbudowano dokument, w szczególności obejmując wprost oprogramowanie wykorzystujące sztuczną inteligencję (Medical Device Artificial Intelligence – MDAI), doprecyzowując kwalifikację oprogramowania modułowego oraz regulując styk z systemami elektronicznej dokumentacji medycznej (EHR) na gruncie rozporządzenia o europejskiej przestrzeni danych zdrowotnych (EHDS). Doprecyzowano także, że oprogramowanie jedynie przetwarzające informacje zdrowotne podlega MDR wyłącznie wtedy, gdy służy to bezpośrednio celowi medycznemu. Co więcej, rozporządzenie MDR wprowadziło Regułę 11 (Załącznik VIII do MDR), która zrewolucjonizowała klasyfikację oprogramowania medycznego:

• Oprogramowanie przeznaczone do dostarczania informacji wykorzystywanych do podejmowania decyzji do celów diagnostycznych lub terapeutycznych zakwalifikowane jest co do zasady do klasy IIa wyrobów medycznych.
• Rozporządzenie różnicuje jednak dwa odrębne poziomy skutków: jeżeli decyzja może spowodować śmierć lub nieodwracalne pogorszenie stanu zdrowia – klasa III; jeżeli może spowodować poważne pogorszenie stanu zdrowia lub konieczność interwencji chirurgicznej – klasa IIb.
• Odrębnie uregulowano oprogramowanie przeznaczone do monitorowania procesów fizjologicznych – co do zasady klasa IIa. Jeżeli jednak służy ono monitorowaniu życiowych parametrów fizjologicznych, których zmiany mogą stworzyć bezpośrednie zagrożenie dla pacjenta (np. akcja serca, ciśnienie tętnicze, saturacja) – klasa IIb. To rozróżnienie ma kluczowe znaczenie dla popularnych aplikacji typu dzienniczek ciśnienia czy asystent kardiologiczny.
• Całe pozostałe oprogramowanie będące wyrobem medycznym klasyfikuje się do klasy I. W praktyce jest to jednak wąski margines – stąd wniosek o klasie IIa jako „domyślnej” dla rozwiązań wspierających decyzje kliniczne pozostaje trafny.

W praktyce oznacza to, że zdecydowana większość medycznych aplikacji mobilnych nie może skorzystać z najprostszej, „samoobsługowej” klasy I (gdzie producent sam wystawia deklarację zgodności). Kwalifikacja do klasy IIa lub wyższej nakłada obowiązek zaangażowania jednostki notyfikowanej do oceny zgodności, co wydłuża proces wdrożenia na rynek od kilkunastu do kilkudziesięciu miesięcy.

2. Przykłady z praktyki

Dla lepszego zrozumienia tej granicy warto przeanalizować dwa przypadki z praktyki rynkowej:

•  Przykład 1: Aplikacja do śledzenia cyklu (Natural Cycles)

Szwedzki startup stworzył aplikację, która na podstawie codziennych pomiarów temperatury ciała i analizy algorytmicznej określa dni płodne. Gdyby aplikacja służyła jedynie jako „cyfrowy kalendarzyk”, byłaby zwykłym programem wellness. Ponieważ jednak producent zadeklarował jej przeznaczenie jako naturalną metodę antykoncepcji, aplikacja musiała przejść rygorystyczny proces certyfikacji jako wyrób medyczny klasy IIb z udziałem jednostki notyfikowanej. Pierwsze oznakowanie CE aplikacja uzyskała w lutym 2017 r., a więc jeszcze pod rządami dyrektywy MDD, co oznaczało dla producenta konieczność późniejszego przejścia na nowy reżim MDR. W USA rozwiązanie uzyskało dopuszczenie FDA w sierpniu 2018 r.

• Przykład 2: Diagnoza zmian skórnych (Kwalifikacja AI)

Aplikacja mobilna pozwala użytkownikowi zrobić zdjęcie znamienia na skórze.

1. 1. Wariant A (Wellness): Aplikacja zapisuje zdjęcie w archiwum i przypomina o corocznej wizycie u dermatologa. W takiej sytuacji nie jest to wyrób medyczny.
   2. Wariant B (SaMD / MedTech): Algorytm AI analizuje piksele zdjęcia, porównuje je z bazą przypadków i wyświetla komunikat: „Niskie ryzyko” lub „Wysokie ryzyko czerniaka – skonsultuj się z lekarzem”. W tym przypadku jest to wyrób medyczny. Aplikacja wykonuje aktywną analizę diagnostyczną i podlega pod rygorystyczne przepisy MDR oraz wymogi dla systemów wysokiego ryzyka na gruncie AI Act.

Nakładanie się MDR i AI Act – na co uważać?

Warto podkreślić mechanizm, który w praktyce zaskakuje wielu dostawców. Zgodnie z art. 6 ust. 1 AI Act system AI będący wyrobem medycznym albo związanym z bezpieczeństwem elementem takiego wyrobu, podlegający ocenie zgodności z udziałem jednostki notyfikowanej, jest systemem wysokiego ryzyka z mocy prawa – automatycznie i bez możliwości skorzystania z wyjątków przewidzianych dla systemów z załącznika III. Innymi słowy, kwalifikacja aplikacji jako wyrobu medycznego klasy IIa lub wyższej przesądza jednocześnie o jej statusie na gruncie AI Act. Obowiązki obu reżimów kumulują się. Wymogi AI Act dotyczące zarządzania ryzykiem, jakości danych treningowych, dokumentacji technicznej i nadzoru człowieka nakładają się na obowiązki MDR, choć unijne rozporządzenie dotyczące systemów AI przewiduje mechanizmy ograniczające dublowanie ocen zgodności.

Istotny jest tu także harmonogram. Zgodnie z uzgodnionym w maju 2026 r. pakietem Digital Omnibus on AI, obowiązki dotyczące systemów wysokiego ryzyka wbudowanych w produkty regulowane – a więc również medyczne – będą stosowane od 2 sierpnia 2028 r. Termin ten warto uwzględnić w planach łącznie z harmonogramem certyfikacji MDR, ponieważ oba te procesy dotyczą w zasadzie tej samej dokumentacji i tych samych danych.

3. Konsekwencje błędnej kwalifikacji – sankcje i ryzyko biznesowe

Zignorowanie przepisów MDR i wprowadzenie na rynek wyrobu medycznego jako „zwykłej aplikacji” wiąże się z ogromnym ryzykiem. W Polsce kwestię sankcji reguluje ustawa z dnia 7 kwietnia 2022 r. o wyrobach medycznych:

• Kary finansowe: Prezes Urzędu Rejestracji Produktów Leczniczych, Wyrobów Medycznych i Produktów Biobójczych (URPL) może nałożyć administracyjne kary pieniężne sięgające do 5 mln zł za wprowadzanie do obrotu lub używania wyrobu niespełniającego wymogów, w tym za naruszenie przepisów o ocenie zgodności.
• Decyzje administracyjne: URPL może nakazać wycofanie wyrobu z obrotu oraz wstrzymać jego dystrybucję i reklamę. W praktyce skuteczne usunięcie aplikacji ze sklepów takich jak App Store czy Google Play wymaga dodatkowo zgłoszenia naruszenia do operatora platformy, ale sama decyzja regulatora stanowi podstawę do takich działań.
• Odpływ inwestorów: To już nie kwestia przepisów, lecz twardej praktyki rynkowej – w toku badania due diligence fundusze VC i inwestorzy szybko wychwytują brak właściwej certyfikacji. Nieuregulowany status SaMD realnie utrudnia, a często blokuje rundy finansowania oraz komercjalizację.

Do tego katalogu należy dodać dwa obszary często pomijane na etapie planowania budżetu. Po pierwsze, reklama wyrobów medycznych podlega w Polsce odrębnemu, rygorystycznemu reżimowi (rozdział 12 ustawy o wyrobach medycznych, obowiązujący od 1 stycznia 2023 r.), a naruszenie zasad reklamy jest zagrożone odrębną karą pieniężną. Dla aplikacji mobilnych, których model dystrybucji opiera się na intensywnym marketingu w mediach społecznościowych i we współpracy z influencerami, jest to realne, a systematycznie niedoszacowane ryzyko.

Po drugie, uzyskanie certyfikatu nie kończy procesów zgodnościowych, lecz w zasadzie je dopiero rozpoczyna. Producent wyrobu medycznego pozostaje zobowiązany do prowadzenia nadzoru po wprowadzeniu do obrotu, obserwacji klinicznej (PMCF), zgłaszania poważnych incydentów oraz rejestracji wyrobu i podmiotu w bazie EUDAMED. W przypadku oprogramowania szczególną uwagę wymaga zarządzanie zmianą: istotna modyfikacja algorytmu, zwłaszcza modelu uczenia maszynowego (ML), może wymagać ponownej oceny zgodności. To bezpośrednio rzutuje na swobodę wdrażania kolejnych wersji produktu.

Podsumowanie: Projektuj legalnie od pierwszej linijki kodu

Klasyfikacja aplikacji zdrowotnej to nie tylko formalność – to strategiczna decyzja biznesowa, która determinuje budżet, czas wdrożenia oraz architekturę całego oprogramowania. Zamiast ryzykować wielomilionowe kary lub kosztowne przerabianie aplikacji tuż przed debiutem na rynku, warto przeprowadzić profesjonalny audyt kwalifikacyjny jeszcze na etapie projektowania funkcji.

Jak możemy pomóc Państwa firmie?

W Kancelarii Barta & Partners wspieramy twórców technologii MedTech, startupy oraz software house’y w bezpiecznym wprowadzaniu innowacji na rynek.

Jeżeli planują Państwo stworzenie lub rozwój aplikacji z obszaru e-health / wellness – zapraszamy do kontaktu z kancelarią. Wspieramy na każdym etapie:

• Przeprowadzamy audyty kwalifikacyjne oprogramowania (ocena czy aplikacja jest wyrobem medycznym wg MDR i wytycznych MDCG);
• Pomagamy w bezpiecznym zaprojektowaniu przeznaczenia (intended purpose) oraz komunikatów marketingowych, aby uniknąć nieumyślnego „wpadnięcia” w rygor MDR;
• Opracowujemy strategię prawną uwzględniającą nakładające się wymogi MDR, RODO oraz AI Act;
• Przygotowujemy umowy wdrożeniowe (SLA, IP, R&D) zabezpieczające prawa do oprogramowania i algorytmów.

Ewa Trybulec

praktykant