Granica między badaniami a produktem

Ten sam kod może występować w dwóch bardzo różnych sytuacjach. W jednej z nich grupa badawcza uruchamia potok segmentacji na danych retrospektywnych i zapisuje pomiary do analizy. W drugiej usługa przedstawia te pomiary klinicystom jako część opieki lub planowania leczenia. Algorytm i wagi modelu mogą być identyczne, ale twierdzenie, użytkownicy, tok pracy, odpowiedzialności i ciężar dowodowy już nie. Pierwsze pytanie na tej granicy nie brzmi więc „jaki to rodzaj modelu?”. Brzmi ono: „co to oprogramowanie ma robić, dla kogo i w kontekście której jurysdykcji?”.

Sekcja wykorzystuje przykład wychodzący od UE, ponieważ jej terminologia uwidacznia to rozróżnienie. Jest to orientacja edukacyjna, a nie porada prawna. Inne jurysdykcje mogą stosować inne definicje i ścieżki, a rzeczywisty projekt wymaga aktualnych oficjalnych źródeł, wiedzy z zakresu prywatności i regulacji oraz oceny konkretnych okoliczności. Nic poniżej nie klasyfikuje rzeczywistego produktu.

Dwa konteksty, identyczny kod

Rozważmy skonstruowany scenariusz przejścia od badań do produktu. Wersja A potoku wyznacza całkowitą objętość nowotworu w kontrolnych badaniach CT retrospektywnej kohorty badawczej; wartości analizuje się w notatniku i nie przedstawia jako instrukcji dotyczących opieki nad pacjentem. Wersja B korzysta z tego samego kodu i wag, ale podczas planowania leczenia wyświetla klinicystom obok obrazów informację „objętość nowotworu: 43.2 cm3, +18% od poprzedniego badania”. Liczby i interfejs w tym przykładzie są ilustracyjne i nie stanowią twierdzenia dotyczącego rzeczywistego produktu.

Różnicy nie ustala format pliku, język programowania, architektura modelu ani nazwa repozytorium. Ustalają ją zamierzone użycie i kontekst, w którym ludzie polegają na wyniku. Etykieta „badawcze” nie może sama odpowiedzieć na pytanie, co się dzieje, gdy strona trzecia przedstawia wynik jako podstawę decyzji klinicznej. Z kolei interfejs wyglądający klinicznie nie ustala sam w sobie konkretnego statusu prawnego. Wskazuje okoliczności, które należy zbadać w ocenie produktu, prywatności, etyki i regulacji.

Kwalifikacja i klasyfikacja wynikają z twierdzenia

W Unii Europejskiej rozporządzenie w sprawie wyrobów medycznych (MDR, rozporządzenie (UE) 2017/745) jest istotnym aktem prawnym dotyczącym wyrobów medycznych, w tym oprogramowania, gdy odpowiednie okoliczności i zamierzone cele medyczne obejmują oprogramowanie jego zakresem. Kluczowe jest przeznaczenie określone przez producenta: twierdzenia na etykiecie, w instrukcji używania, materiałach promocyjnych lub sprzedażowych oraz w ocenie klinicznej mogą mieć znaczenie dla tego, co przedstawia się jako działanie wyrobu. Ten sam plik binarny może zatem być używany w środowisku badawczym i produktowym, choć otaczające go twierdzenie jest inne.

Trzeba oddzielić dwa pytania. Kwalifikacja pyta, czy oprogramowanie wchodzi w ramy dotyczące wyrobów w świetle rozpatrywanego przeznaczenia i okoliczności. Klasyfikacja pyta, jaka kategoria ryzyka i jakie konsekwencje dla oceny zgodności wynikają, jeśli wchodzi. Odpowiedzi nie wyznaczają rozmiar modelu, AUROC, wynik segmentacji ani nazwanie oprogramowania „badawczym”. Ten rozdział nie może też rozstrzygnąć klasyfikacji rzeczywistego systemu. Aktualny tekst prawny i wytyczne, w tym właściwe rozumowanie dotyczące klasyfikacji oprogramowania, mogą się zmieniać i trzeba je sprawdzać w utrzymywanym materiale towarzyszącym przy udziale wiedzy właściwej dla danej jurysdykcji.

Przejście od badań do kontekstu produktowego zmienia również cały pakiet pytań. Projekt może wymagać materiału dowodowego proporcjonalnego do zamierzonych twierdzeń, zarządzania ryzykiem, jakości i kontroli zmian, procesów po wprowadzeniu na rynek lub procesów incydentowych oraz ścieżki oceny zgodności. Użycie badawcze nie jest przez to wolne od obowiązków dotyczących etyki, prywatności, bezpieczeństwa ani zarządzania danymi. Są to odrębne obowiązki z odrębnymi właścicielami decyzji; żadnego nie można zastąpić metryką modelu ani stwierdzeniem zgodności z DICOM.

Relacja z AI Act jest warunkowa

Akt w sprawie sztucznej inteligencji UE (rozporządzenie (UE) 2024/1689) nakłada się na inne obowiązujące ramy; nie sprawia, że MDR znika. Sposób traktowania systemu zależy od takich okoliczności jak zamierzone użycie, relacja z produktem lub elementem bezpieczeństwa, ustawodawstwo objęte zakresem oraz to, czy ma zastosowanie odpowiedni warunek oceny zgodności przez stronę trzecią. Znaczenie mogą mieć też inne ścieżki i wyjątki. Nie jest więc trafną trwałą regułą stwierdzenie, że każdy system medycznej AI jest automatycznie systemem wysokiego ryzyka.

Na potrzeby tej opatrzonej datą, ograniczonej do UE orientacji materiał źródłowy wskazuje również MDCG 2019-11 rev.1 dotyczące kwalifikacji i klasyfikacji oprogramowania (czerwiec 2025). Dokładne wydania wytycznych, daty przejściowe, tabele klasyfikacji i praktyka wdrożeniowa są zmienne. Należą do towarzyszącej części Web i przed rzeczywistą decyzją trzeba je ponownie sprawdzić w aktualnych materiałach oficjalnych. Rozdział zachowuje tylko trwały wzorzec rozumowania: jedna analiza przeznaczenia może dostarczyć informacji dla kilku pytań prawnych, ale pytania pozostają odrębne, a odpowiedź zależy od okoliczności.

Istotne jest tutaj rozróżnienie względem rozdziału 10. Techniczne mechanizmy poufności DICOM, pseudonimizacja, tożsamość obiektu, transport i przechowywanie opisują właściwości techniczne lub zarządcze. Nie wykazują, że udostępnienie jest prawnie anonimowe, że oprogramowanie ma określone przeznaczenie ani że ma określoną klasyfikację regulacyjną. Wniosek wynikający z DICOM nie może zastępować analizy prawnej właściwej dla danej jurysdykcji.

Gdy sposób użycia zmienia pytanie

Wróćmy do skonstruowanego przykładu z trzema użytkownikami. Laboratorium uniwersyteckie uruchamia potok na danych retrospektywnych. Szpitalny zespół badawczy uruchamia go w ukrytym toku pracy w trybie cieniowym, a wyniki pozostają niedostępne dla klinicystów. Następnie klinicysta zaczyna używać tego samego narzędzia do przygotowywania konturów lub pomiarów wpływających na leczenie. Scenariusze te rodzą różne pytania dotyczące przeznaczenia, nadzoru, przetwarzania danych i odpowiedzialności. Są scenariuszami dydaktycznymi, a nie prawną klasyfikacją rzeczywistego produktu ani twierdzeniem, że wynik rozstrzyga jedna okoliczność.

Ważną reakcją inżynierską jest zauważenie zmiany, zamiast pozwolenia, by badawcza etykieta oprogramowania ją ukryła. Jeśli planowane użycie stało się kliniczne, zespół powinien przestać traktować opis badawczy jako pełną specyfikację produktu i uzyskać odpowiednią ocenę regulacyjną, dotyczącą prywatności, kliniczną i zarządczą. Jeśli zamierzone użycie pozostaje wyłącznie badawcze, granice i ograniczenia powinny być jawne w toku pracy, kontroli dostępu, dokumentacji i komunikacji. Żadnej z tych opcji nie tworzy usunięcie znacznika DICOM ani utrzymywanie repozytorium jako prywatnego.

Nabywca napotyka tę samą granicę od drugiej strony. Twierdzenie takie jak „zwalidowany” lub „z oznakowaniem CE”, jeśli dotyczy rzeczywistego produktu, trzeba porównać z oznaczonym przeznaczeniem, populacją, tokiem pracy, materiałem dowodowym i lokalnym użyciem. Oznakowanie lub certyfikat nie jest uniwersalną gwarancją korzyści dla osoby interpretującej, lokalnej interoperacyjności, bezpieczeństwa pacjentów ani użyteczności klinicznej. Szpital nadal musi zapytać, kto działa na podstawie wyniku, jak kontroluje się aktualizacje, jaki materiał dowodowy wytworzono z udziałem właściwych osób interpretujących oraz kto odpowiada za monitorowanie i incydenty. Są to pytania dotyczące adopcji zebrane w poprzedniej sekcji.

Granica ta celowo dotyczy rozpoznawania, a nie rozstrzygania. Uczy czytelnika zauważać zmianę przeznaczenia, oddzielać twierdzenia techniczne od prawnych i przekazywać rzeczywisty przypadek osobom uprawnionym do podjęcia decyzji. Nie przypisuje produktowi klasy, nie uznaje zastosowania badawczego za zgodne z prawem ani nie zmienia ilustracyjnego omówienia UE w poradę dla innej jurysdykcji.