Czego dowiesz się z tego artykułu?
- Kiedy AI w placówce jest zwykłym narzędziem organizacyjnym, a kiedy może wejść w obszar wyrobu medycznego.
- Jak odczytać intended purpose dostawcy bez języka prawniczego.
- O co zapytać przed zakupem systemu do analizy obrazu, triage, kalkulatora ryzyka albo wsparcia decyzji lekarza.
- Jak ustawić human-in-the-loop przy danych pacjenta i odpowiedzialności klinicznej.
W placówce medycznej pytanie nie brzmi tylko: czy ten chatbot odpowie pacjentowi szybciej. Prawdziwe pytanie brzmi: czy narzędzie zaczyna wpływać na decyzję medyczną, kwalifikację pacjenta, ocenę ryzyka albo interpretację danych klinicznych. To jest zupełnie inna rozmowa niż wybór widgetu do strony internetowej.
Ja bym zaczął od prostego rozróżnienia: AI do organizacji pracy i AI do celu medycznego. Pierwsza kategoria może pomóc rejestracji, porządkować pytania, przypominać o terminach i kierować pacjenta do człowieka. Druga dotyka wyniku klinicznego, a wtedy manager musi pytać o MDR, AI Act, dokumentację dostawcy, certyfikację i odpowiedzialność.
To jest temat z kategorii dane i bezpieczeństwo, ale nie kończy się na RODO. Dobra decyzja zakupowa łączy proces placówki, dane pacjentów, rolę lekarza i jasne granice tego, co system może tylko podpowiedzieć, a co musi zostać zatwierdzone przez człowieka.
Najważniejsze
- Sam napis AI w ofercie nie przesądza, że produkt jest wyrobem medycznym; decyduje przeznaczenie deklarowane przez producenta i realna funkcja systemu.
- Chatbot do godzin otwarcia, cennika i przekierowania do rejestracji to inny poziom ryzyka niż AI analizująca obraz, objawy albo wynik badania.
- Manager placówki powinien żądać od dostawcy jasnego opisu intended purpose, klasyfikacji, statusu CE/MDR oraz dokumentacji nadzoru nad zmianami modelu.
- To ma sens, gdy placówka kupuje narzędzie z czytelną dokumentacją, rolą lekarza i procedurą eskalacji do człowieka.
- To nie ma sensu, gdy dostawca obiecuje wsparcie kliniczne, ale nie potrafi pokazać klasyfikacji, dowodów klinicznych ani granic odpowiedzialności.
Rys. 1. Pierwsze rozróżnienie: organizacja pracy kontra cel medyczny i nadzór lekarza.
Zacznij od celu medycznego, nie od etykiety AI
Najważniejsze pojęcie to intended purpose, czyli przeznaczenie deklarowane przez producenta. W praktyce placówki oznacza to pytanie: do czego dostawca mówi, że system służy? Jeżeli narzędzie ma tylko umawiać wizyty, porządkować wiadomości albo przekazywać pacjenta do rejestracji, zwykle rozmawiamy o automatyzacji organizacyjnej. Jeśli ma wspierać rozpoznanie, przewidywać ryzyko, wskazywać możliwą ścieżkę kliniczną albo interpretować obraz, sprawa robi się regulacyjnie poważniejsza.
Nie patrz wyłącznie na marketingową nazwę produktu. Ten sam interfejs może wyglądać jak chatbot, ale działać zupełnie inaczej pod spodem. Jeden bot odpowiada na pytanie o parking, drugi zbiera objawy i sugeruje pilność konsultacji. Dla pacjenta oba są okienkiem rozmowy. Dla managera i IOD to dwa różne ryzyka.
Sugeruję, żeby w pierwszej rozmowie z dostawcą nie pytać: czy macie AI. Pytaj: czy system ma cel medyczny, czy jest objęty MDR/IVDR, czy był klasyfikowany jako medical device software, kto jest producentem, kto aktualizuje model i co dokładnie trafia do dokumentacji placówki. Ten przewodnik możesz zapisać jako roboczą kartę decyzji: AI jako wyrób medyczny.
Cztery przykłady, które zmieniają rozmowę z dostawcą
Różnica staje się czytelna, gdy przełożymy ją na procesy w przychodni albo klinice. Chatbot organizacyjny odpowiada na pytania, zbiera preferencję terminu i przekazuje sprawę rejestracji. System kliniczny może analizować dane medyczne, tworzyć sugestię ryzyka albo wpływać na kolejność pilności. Tu nie chodzi o straszenie AI, tylko o właściwą półkę decyzyjną.
| Przykład narzędzia | Pytanie managera | Co powinno zapalić lampkę |
|---|---|---|
| Chatbot do cennika i terminów | Czy system tylko informuje i przekierowuje? | Bot zaczyna zbierać objawy i sugerować pilność bez procedury klinicznej |
| Analiza obrazu RTG, USG lub dermatoskopii | Czy produkt ma status wyrobu medycznego i dokumentację oceny klinicznej? | Dostawca mówi o wykrywaniu zmian, ale unika rozmowy o MDR i CE |
| Triage kliniczny przed wizytą | Kto zatwierdza kwalifikację pacjenta i wyjątki? | Wynik AI automatycznie przesuwa pacjenta bez kontroli personelu |
| Kalkulator ryzyka lub predykcja powikłań | Czy wynik jest tylko materiałem pomocniczym dla lekarza? | System sugeruje decyzję terapeutyczną bez jasnej odpowiedzialności lekarza |
W małej placówce ten podział ma bardzo praktyczny skutek: inne pytania w umowie, inne testy przed startem i inne szkolenie zespołu. W sprawach technicznych i zakupowych warto połączyć tę ocenę z kategorią narzędzia i wdrożenia, ale ostateczna decyzja nie może być tylko decyzją zakupową.
Co manager powinien dostać od dostawcy
Dostawca, który sprzedaje narzędzie w obszarze klinicznym, powinien umieć spokojnie wyjaśnić jego status. Nie wystarczy prezentacja sprzedażowa ani ogólne zdanie, że system pomaga lekarzowi. Poproś o dokumentację przeznaczenia, klasyfikacji, ograniczeń użycia, zasad aktualizacji modelu i sposobu zgłaszania incydentów lub błędów działania.
Ja bym poprosił o jedną stronę odpowiedzi przed spotkaniem decyzyjnym. Jeśli dostawca nie potrafi jej przygotować, to jest sygnał, że placówka może zostać z ryzykiem sama. W przypadku danych pacjenta i decyzji klinicznych brak dokumentacji jest decyzją biznesową, tylko podjętą po cichu.
Karta weryfikacji dostawcy AI dla placówki medycznej
1. Jaki jest deklarowany intended purpose systemu?
2. Czy system jest wyrobem medycznym, akcesorium albo oprogramowaniem wpływającym na wyrób medyczny?
3. Jaka jest klasyfikacja według MDR lub IVDR i kto jest producentem?
4. Czy produkt ma oznakowanie CE właściwe dla deklarowanego celu?
5. Jakie dane pacjentów są przetwarzane i gdzie są przechowywane?
6. Kto zatwierdza wynik systemu przed decyzją kliniczną?
7. Jak dokumentowane są błędy, reklamacje, zmiany modelu i aktualizacje?
8. Jak placówka może wyłączyć funkcję lub wrócić do procesu ręcznego?Przykład: krótka checklista do rozmowy zakupowej z dostawcą AI lub SaMD, bez wpisywania danych pacjentów.
Przykład w przychodni: triage bez skrótu przez odpowiedzialność
Przykład modelowy — scenariusz pokazuje sposób myślenia o pilotażu. Liczby ilustrują metryki organizacyjne i nie są gwarancją wyniku wdrożenia.
Przychodnia specjalistyczna chce odciążyć rejestrację, bo pacjenci dzwonią z pytaniami, czy ich objaw wymaga pilnej wizyty. Pierwszy pomysł brzmi: bot zbierze objawy i od razu ustawi priorytet. To jest dokładnie ten moment, w którym trzeba zwolnić. Priorytet kliniczny to nie jest zwykły status w CRM, tylko informacja mogąca wpływać na bezpieczeństwo pacjenta.
Bezpieczniejszy pilotaż wygląda inaczej. Bot zbiera neutralne informacje administracyjne, prosi o kontakt w sytuacjach alarmowych zgodnie z procedurą placówki, a wszystkie przypadki objawowe trafiają do rejestracji lub osoby medycznej. Lekarz albo wyznaczony personel zatwierdza ścieżkę, a AI przygotowuje tylko uporządkowaną kartę rozmowy. Human-in-the-loop jest tu warunkiem procesu, nie ozdobą w prezentacji.
| Metryka pilotażu | Co mierzyć przez 30 dni | Dlaczego to ważne |
|---|---|---|
| Odsetek rozmów przekazanych do człowieka | Liczba spraw eskalowanych z powodu objawów | Pokazuje, czy bot nie przejmuje decyzji klinicznej |
| Kompletność karty kontaktu | Czy rejestracja ma dane kontaktowe i powód sprawy | Ułatwia obsługę bez oceny medycznej przez AI |
| Czas reakcji rejestracji | Mediana od zgłoszenia do kontaktu | Mierzy proces organizacyjny, nie obiecuje efektu klinicznego |
| Liczba ręcznych korekt | Ile razy personel poprawił klasyfikację sprawy | Pokazuje jakość reguł eskalacji |
W takim pilotażu AI może pomóc placówce, ale nie udaje lekarza. To samo myślenie warto przenieść na dokumentację i pracę gabinetu, czyli obszar AI w pracy lekarza: szkic, porządkowanie i przypomnienie są pomocne, ale decyzja medyczna zostaje po stronie osoby uprawnionej.
Granice odpowiedzialności: co zostaje po stronie placówki
Nawet jeśli dostawca ma certyfikację, placówka nadal odpowiada za sposób użycia narzędzia w swoim procesie. Personel musi wiedzieć, kiedy ufać systemowi jako pomocy, kiedy eskalować, a kiedy całkowicie pominąć wynik AI. To wymaga procedury, szkolenia i śladu decyzyjnego, zwłaszcza tam, gdzie przetwarzane są dane dotyczące zdrowia.
W praktyce manager powinien rozdzielić trzy rzeczy: odpowiedzialność producenta za produkt, odpowiedzialność placówki za organizację pracy oraz odpowiedzialność lekarza za decyzję kliniczną. Nie mieszaj tych warstw w jednej umowie licencyjnej, bo później nikt nie wie, kto reaguje na błąd, zmianę modelu albo nietypową sytuację pacjenta.
Dobrą zasadą jest też minimalizacja danych. Jeśli testujesz chatbot organizacyjny, nie wklejaj historii choroby, wyników badań ani danych identyfikujących pacjenta do narzędzia, które tego nie wymaga. Przy rozwiązaniach klinicznych weryfikuj podstawę prawną, powierzenie, lokalizację danych, logi dostępu, retencję i upoważnienia personelu. RODO nie znika dlatego, że produkt ma AI w nazwie.
Pierwszy krok na następny tydzień
Zanim poprosisz o ofertę, zrób krótką mapę procesu. Wybierz jeden przypadek: rejestracja, opis badania, analiza obrazu, triage albo kalkulator ryzyka. Dla każdego zapisz, czy wynik AI ma wpływać na decyzję medyczną. Jeśli tak, temat trafia do rozmowy z lekarzem, IOD i dostawcą jako potencjalny wyrób medyczny lub system wysokiego ryzyka, a nie jako zwykła automatyzacja recepcji.
Mój praktyczny próg jest prosty: jeżeli błąd systemu może zmienić pilność kontaktu, interpretację wyniku, dalsze postępowanie albo poczucie bezpieczeństwa pacjenta, nie wdrażaj tego jako szybkiego eksperymentu marketingowego. Zacznij od dokumentacji, przeznaczenia, ścieżki eskalacji i decyzji, kto zatwierdza wynik. Najtańszy pilotaż to ten, którego zakres od początku jest jasny.
Na koniec zostaw sobie trzy pytania kontrolne. Po pierwsze: czy wiemy, co system robi i czego nie robi. Po drugie: czy człowiek zatwierdza wynik tam, gdzie dotykamy decyzji klinicznej. Po trzecie: czy dostawca potrafi obronić swoje twierdzenia dokumentami, a nie tylko slajdem. Jeśli odpowiedź brzmi nie, wróć do procedury danych i bezpieczeństwa i uporządkuj ryzyko przed zakupem.
Źródła
- Komisja Europejska — MDCG endorsed documents and other guidance — oficjalna lista wytycznych MDR/IVDR, w tym dokumenty klasyfikacyjne aktualizowane w 2026 r.; dostęp: 2026-07-01.
- MDCG 2019-11 rev.1 — Guidance on Qualification and Classification of Software in MDR/IVDR — wyjaśnia kwalifikację oprogramowania medycznego, znaczenie intended purpose i przykłady MDSW; rewizja: czerwiec 2025, dostęp: 2026-07-01.
- MDCG 2025-6 — FAQ on Interplay between MDR/IVDR and AI Act — porządkuje relację MDR/IVDR z AI Act dla Medical Device Artificial Intelligence; publikacja: czerwiec 2025, dostęp: 2026-07-01.
- UODO — Mapa źródeł danych medycznych w Polsce — polski kontekst danych medycznych, ich rozproszenia i znaczenia dla innowacji w ochronie zdrowia; publikacja: 2026-04-10, dostęp: 2026-07-01.
- Ministerstwo Cyfryzacji — pierwsze przepisy AI Act zaczynają obowiązywać — polski komunikat o etapowym stosowaniu AI Act i obowiązku kompetencji AI; publikacja: 2025-01-31, dostęp: 2026-07-01.
- Zdjęcie okładki: Cedric Fauntleroy na Pexels.
