Kiedy system wspomagania decyzji klinicznych jest wyrobem medycznym? Przewodnik dla szpitali

System wspomagania decyzji klinicznych (CDSS), czyli oprogramowanie, które na podstawie danych pacjenta podpowiada lekarzowi rozpoznanie lub leczenie, jest wyrobem medycznym wtedy, gdy producent przeznacza go do wspierania diagnozy lub leczenia konkretnego pacjenta. O kwalifikacji przesądza przeznaczenie, a ocena pozostaje taka sama niezależnie od technologii i miejsca instalacji systemu. Unijne przepisy obejmują także systemy, których rekomendacje lekarz samodzielnie weryfikuje przed podjęciem decyzji.

Dla szpitala ta zasada ma praktyczne konsekwencje. Wpływa na wybór dostawcy, treść umowy, obowiązki personelu medycznego i odpowiedzialność za zmiany wprowadzane w systemie po zakupie.

O kwalifikacji decyduje przeznaczenie określone przez producenta

Art. 2 pkt 1 rozporządzenia (UE) 2017/745 w sprawie wyrobów medycznych, w skrócie MDR, wymienia cele medyczne, które czynią produkt wyrobem medycznym. Należą do nich między innymi diagnoza, zapobieganie, monitorowanie, przewidywanie, prognozowanie i leczenie choroby. Oprogramowanie, które realizuje jeden z tych celów w odniesieniu do konkretnego pacjenta, jest wyrobem medycznym.

Przeznaczenie wynika z dokumentów producenta. Art. 2 pkt 12 MDR wskazuje etykietę, instrukcję używania, materiały promocyjne i ocenę kliniczną. W praktyce oznacza to, że opis produktu w broszurze, na stronie internetowej i w samym interfejsie ma znaczenie regulacyjne. Ten sam model może porządkować dokumentację medyczną albo wspierać rozpoznanie, a o jego statusie rozstrzyga sposób, w jaki producent opisuje jego zastosowanie.

Wytyczne MDCG 2019-11 Rev.1, które Grupa Koordynacyjna ds. Wyrobów Medycznych przy Komisji Europejskiej wydała w czerwcu 2025 roku, wskazują ponadto, że kwalifikacja zależy wyłącznie od przeznaczenia. Poziom ryzyka wpływa dopiero na klasę wyrobu. Miejsce działania oprogramowania, na przykład aplikacja mobilna, usługa w chmurze lub moduł większego systemu, pozostaje bez znaczenia dla kwalifikacji.

Cztery pytania z wytycznych MDCG pozwalają ocenić każdy system

Wytyczne MDCG 2019-11 opisują drzewo decyzyjne. Szpital może przejść je samodzielnie dla każdego narzędzia, które przetwarza dane pacjentów i przekazuje wyniki lekarzom.

Test kwalifikacji oprogramowania (MDCG 2019-11)

1. 1

   Czy produkt jest oprogramowaniem?

   Nie: wytyczne nie mają zastosowania

2. 2

   Czy przetwarza dane w sposób wykraczający poza przechowywanie, archiwizację, przesyłanie, proste wyszukiwanie i bezstratną kompresję?

   Nie: nie jest wyrobem

3. 3

   Czy działa na rzecz konkretnego pacjenta?

   Nie: nie jest wyrobem (statystyki populacyjne, ogólne ścieżki, literatura)

4. 4

   Czy realizuje cel medyczny z art. 2 pkt 1 MDR?

   Nie: nie jest wyrobem (rozliczenia, grafiki dyżurów, poczta)

Cztery razy „tak”: oprogramowanie jest wyrobem medycznym.

Kolejny krok to klasyfikacja według reguły 11 MDR.

W praktyce rozstrzygające jest zwykle pytanie o konkretnego pacjenta. System prezentujący ogólne wytyczne leczenia nadciśnienia pozostaje narzędziem informacyjnym. System, który analizuje wyniki określonego pacjenta i proponuje zmiany w jego farmakoterapii, jest wyrobem medycznym.

Wersja Rev.1 wytycznych zawiera zapis istotny dla narzędzi opartych na dużych modelach językowych. Wyszukiwanie z wykorzystaniem przetwarzania języka naturalnego (NLP), które służy celowi medycznemu, wykracza poza „proste wyszukiwanie”. Asystent, który przeszukuje dokumentację pacjenta i odpowiada na pytanie kliniczne, przechodzi więc do kolejnych kroków testu. Ogólny czat bez medycznego przeznaczenia pozostaje poza MDR do chwili, w której producent przypisze mu cel medyczny.

Jeden system szpitalny może zawierać moduły regulowane i nieregulowane

Szpitale rzadko kupują system wspomagania decyzji jako odrębny produkt. Częściej jest to nowy moduł systemu, z którego placówka już korzysta. Załącznik I do wytycznych MDCG 2019-11 pokazuje, jak w takich systemach przebiega granica między funkcjami regulowanymi i nieregulowanymi.

Producent systemu złożonego z modułów ma obowiązek jasno wskazać, które z nich podlegają MDR, i poinformować o tym użytkowników. Pisemne rozgraniczenie modułów powinno więc stanowić standardowy element dokumentacji przekazywanej szpitalowi.

Podobne rozstrzygnięcie zawiera wyrok Trybunału Sprawiedliwości UE z 7 grudnia 2017 roku w sprawie C-329/16 (Snitem i Philips France). Dotyczy on oprogramowania, które zestawia dane pacjenta z przepisanymi lekami i wykrywa przeciwwskazania, interakcje oraz przedawkowanie. Trybunał kwalifikuje je jako wyrób medyczny w zakresie tej funkcji, mimo że program działa wyłącznie na danych, a nie w ciele pacjenta.

Reguła 11 MDR przypisuje oprogramowaniu wspierającemu decyzje co najmniej klasę IIa

Po zakwalifikowaniu systemu jako wyrobu medycznego producent ustala jego klasę. Dla oprogramowania podstawą jest zwykle reguła 11 z załącznika VIII MDR. Oprogramowanie dostarczające informacji wykorzystywanych do decyzji diagnostycznych lub terapeutycznych należy co najmniej do klasy IIa. Klasa IIb obejmuje przypadki, w których błędna decyzja może spowodować poważne pogorszenie stanu zdrowia lub interwencję chirurgiczną. Klasa III obejmuje przypadki, w których skutkiem może być śmierć lub nieodwracalne pogorszenie stanu zdrowia.

Klasę wyznacza więc skutek błędnej informacji, a nie zastosowana technika. System oparty na uczeniu maszynowym i system oparty na prostych regułach podlegają tej samej ocenie.

Wytyczne MDCG zawierają przykłady klasyfikacji. Ich autorzy zastrzegają, że przykłady mają charakter poglądowy i nie przesądzają o klasie konkretnego produktu.

Ranking opcji leczenia przygotowany dla lekarza, na przykład wybór chemioterapii u nosicielek mutacji BRCA, należy do klasy IIa. Aplikacja, która analizuje rytm serca, wykrywa nieprawidłowości i informuje lekarza, należy do klasy IIb. Do tej samej klasy wytyczne zaliczają oprogramowanie oceniające depresję na podstawie objawów. Analiza obrazów na potrzeby decyzji terapeutycznych w ostrym udarze należy do klasy III.

Przykład aplikacji analizującej rytm serca jest szczególnie istotny dla szpitali. Decyzję podejmuje lekarz, a mimo to oprogramowanie należy do klasy IIb, ponieważ informacja z systemu kieruje postępowaniem klinicznym. Nadzór człowieka może w konkretnym przypadku obniżyć klasę, ale tego nie gwarantuje. Oprogramowanie o celu diagnostycznym lub terapeutycznym rzadko kwalifikuje się do klasy I.

Szpital ma własne obowiązki jako użytkownik, a czasem jako producent

Wyroby klasy IIa i wyższej przechodzą ocenę zgodności z udziałem jednostki notyfikowanej, czyli niezależnej organizacji wyznaczonej przez państwo członkowskie, a jej numer widnieje obok oznakowania CE. Ten obowiązek spoczywa na producencie. Szpital ma jednak trzy powody, aby weryfikować jego spełnienie.

AI Act nakłada obowiązki na szpital jako podmiot stosujący. Zgodnie z art. 6 ust. 1 rozporządzenia (UE) 2024/1689 system sztucznej inteligencji, który jest wyrobem medycznym podlegającym ocenie jednostki notyfikowanej, jest systemem wysokiego ryzyka. Art. 26 zobowiązuje szpital do używania takiego systemu zgodnie z instrukcją, powierzenia nadzoru osobom o odpowiednich kompetencjach, monitorowania działania systemu i przechowywania rejestrów zdarzeń.

Zmiany po zakupie mogą przenieść na szpital obowiązki producenta. Art. 16 MDR stosuje się do każdego podmiotu, który zmienia przeznaczenie wyrobu wprowadzonego już do obrotu lub modyfikuje go w sposób mogący wpłynąć na jego zgodność z wymaganiami. Szpital, który ponownie trenuje model na własnych danych albo stosuje go w innym celu niż wskazany w instrukcji, może w ten sposób przejąć obowiązki producenta.

Własne rozwiązania szpitala podlegają szczególnym warunkom. Art. 5 ust. 5 MDR pozwala placówce opieki zdrowotnej wytwarzać i stosować wyrób na własne potrzeby bez pełnej procedury oceny zgodności. Wyrób pozostaje wówczas w placówce, a szpital prowadzi system zarządzania jakością, uzasadnia, że żaden wyrób dostępny na rynku nie zaspokaja potrzeb jego pacjentów na odpowiednim poziomie, i publikuje deklarację dotyczącą takich wyrobów. Ogólne wymagania bezpieczeństwa i działania z załącznika I MDR obowiązują nadal.

Lista kontrolna przy zakupie systemu wspomagania decyzji

• Poproś o przeznaczenie wyrobu w brzmieniu z instrukcji używania i porównaj je z treścią oferty.
• Sprawdź, czy dostawca wskazuje na piśmie, które moduły systemu podlegają MDR.
• Przy klasie IIa i wyższej poproś o deklarację zgodności oraz numer jednostki notyfikowanej.
• Zapytaj, w jaki sposób dostawca wydaje nowe wersje modelu i czy każda wersja otrzymuje nowy identyfikator UDI-DI, czyli kod identyfikujący konkretny model wyrobu w unijnej bazie EUDAMED.
• Wyznacz w szpitalu osoby odpowiedzialne za nadzór nad systemem i za przechowywanie rejestrów zdarzeń.
• Zapisz w umowie, że szpital ponownie trenuje model lub zmienia jego przeznaczenie wyłącznie w uzgodnieniu z producentem.

Sygnały ostrzegawcze w ofertach dostawców

• Dostawca uzasadnia brak statusu wyrobu medycznego tym, że decyzję podejmuje lekarz.
• Materiały promocyjne opisują wsparcie diagnozy, a instrukcja używania mówi wyłącznie o porządkowaniu danych.
• System proponuje leczenie, a przy oznakowaniu CE brakuje numeru jednostki notyfikowanej.
• Dokumentacja nie opisuje, w jaki sposób system przetwarza dane konkretnego pacjenta.
• Dostawca proponuje dostosowanie modelu do danych szpitala bez określenia, kto odpowiada za zmieniony system.

Jak Medalion podchodzi do przeznaczenia narzędzi AI

Medalion rozpoczyna pracę nad każdym narzędziem od określenia jego przeznaczenia, jeszcze przed etapem programowania. Zespół opisuje, jakie dane pacjenta przetwarza narzędzie i komu przekazuje wynik. Modele Medalionu nie są modelami diagnostycznymi. Projekty pilotażowe mogą działać na serwerach szpitala, na jego własnych danych, które pozostają w sieci placówki. Medalion integruje swoje rozwiązania z systemami AMMS i Optimed.

FAQ

Czy każdy system wspomagania decyzji klinicznych jest wyrobem medycznym?

Wyrobem medycznym jest system przeznaczony do wspierania decyzji diagnostycznych lub terapeutycznych dotyczących konkretnego pacjenta. Narzędzia prezentujące ogólne wytyczne, literaturę lub statystyki populacyjne pozostają zwykle poza zakresem MDR.

Czy system wspomagania decyzji przestaje być wyrobem, jeśli decyzję podejmuje lekarz?

Status wyrobu pozostaje bez zmian. Prawo Unii Europejskiej obejmuje także oprogramowanie, którego wynik weryfikuje lekarz. Wytyczne MDCG 2019-11 przypisują klasę IIb aplikacji, która informuje lekarza o nieprawidłowym rytmie serca.

Do jakiej klasy MDR należy oprogramowanie wspomagające decyzje kliniczne?

Zgodnie z regułą 11 co najmniej do klasy IIa. Klasa IIb dotyczy przypadków, w których błędna decyzja może spowodować poważne pogorszenie stanu zdrowia lub interwencję chirurgiczną. Klasa III dotyczy ryzyka śmierci lub nieodwracalnego pogorszenia stanu zdrowia.

Czy asystent oparty na modelu językowym może być wyrobem medycznym?

Tak, jeśli producent przeznacza go do celu medycznego dotyczącego konkretnego pacjenta. Wytyczne MDCG 2019-11 Rev.1 wskazują, że wyszukiwanie z wykorzystaniem NLP, które służy celowi medycznemu, wykracza poza proste wyszukiwanie.

Czy szpital może zbudować własny system wspomagania decyzji bez certyfikacji?

Szpital może skorzystać z art. 5 ust. 5 MDR, jeśli stosuje wyrób wyłącznie we własnej placówce i spełnia warunki tego przepisu. Musi między innymi prowadzić system zarządzania jakością i uzasadnić brak odpowiednika na rynku. Ogólne wymagania bezpieczeństwa i działania obowiązują nadal.

Źródła

• Rozporządzenie (UE) 2017/745 w sprawie wyrobów medycznych (MDR), art. 2 pkt 1 i 12, art. 5 ust. 5, art. 16, załącznik VIII reguła 11: eur-lex.europa.eu
• Grupa Koordynacyjna ds. Wyrobów Medycznych, MDCG 2019-11 Rev.1, Qualification and classification of software, czerwiec 2025: health.ec.europa.eu
• Rozporządzenie (UE) 2024/1689 (AI Act), art. 6 ust. 1 i art. 26: eur-lex.europa.eu
• Grupa Koordynacyjna ds. Wyrobów Medycznych i Rada ds. AI, MDCG 2025-6, interakcja MDR/IVDR i AI Act: health.ec.europa.eu
• Wyrok TSUE z 7 grudnia 2017 r., C-329/16, Snitem i Philips France: curia.europa.eu