Ocenimy algorytm w oprogramowaniu medycznym
Ustalimy wymagania, dokumenty, role podmiotów i kolejność działań, zanim projekt wejdzie w kosztowny etap wdrożenia lub oceny.
Krótka diagnoza oprogramowania medycznego (MDSW, czyli oprogramowania będącego wyrobem medycznym): kwalifikacja, reguła 11, plan walidacji, cyberbezpieczeństwo, dane kliniczne i lista braków do CE.
Brak dokumentacji MDR
Zespół techniczny potrafi testować aplikację, ale często nie wie, jak powiązać wyniki testów z dokumentacją wymaganą przez jednostkę notyfikowaną.
Klasyfikacja algorytmu
Dane wejściowe, wynik działania i nadzór nad modelem trzeba połączyć z MDR, walidacją i kliniką.
Braki w walidacji
Jednostka nie ocenia deklaracji. Potrzebuje śladu: wymaganie, ryzyko, test, wynik, ograniczenie i decyzja akceptacyjna.
Podział odpowiedzialności
Zakres regulacyjny należy oddzielić od testów technicznych: producent lub partner wykonuje testy, a wyniki są włączane do dokumentacji MDR.
Zakres wstępnej kwalifikacji oprogramowania
W przypadku oprogramowania medycznego pierwszym wynikiem nie powinna być ogólna konsultacja, lecz decyzja regulacyjna: czy aplikacja jest wyrobem medycznym w rozumieniu MDR (MDSW), jaka klasa ryzyka ma znaczenie i które dokumenty trzeba przygotować przed rozmową z jednostką.
Co rozstrzygamy na początku
- Czy funkcja algorytmiczna ma przewidziane zastosowanie medyczne.
- Czy jej wynik wspiera diagnozę, terapię, monitorowanie albo decyzję kliniczną.
- Jaka jest klasa ryzyka MDR według reguły 11 i czy potrzebna będzie jednostka notyfikowana.
- Które wymagania rozporządzenia (UE) 2024/1689 pokryje dokumentacja MDR, a gdzie trzeba dołożyć osobne dowody.
Najczęstsze braki w dokumentacji algorytmu
Dla algorytmu sam opis modelu nie wystarczy. Trzeba udokumentować dane wejściowe, walidację, ograniczenia, monitorowanie działania, zarządzanie zmianą, cyberbezpieczeństwo oraz nadzór po wprowadzeniu do obrotu. Do tego ocena kliniczna, która odnosi się do realnej korzyści dla pacjenta lub użytkownika.
Wynik audytu
Wynikiem audytu jest stanowisko regulacyjne: rozstrzygnięcie, czy produkt jest oprogramowaniem medycznym, jaką ma klasę, której procedurze oceny zgodności podlega i jakich dokumentów brakuje. Wskazujemy również, jak połączyć prace nad dokumentacją MDR z wymaganiami rozporządzenia (UE) 2024/1689, aby uniknąć powielania dowodów.
Źródła regulacyjne
Ocena łączy wymagania MDR z rozporządzeniem (UE) 2024/1689 dotyczącym sztucznej inteligencji. Korzystamy również z aktualnych wytycznych MDCG dla oprogramowania medycznego i nowych technologii.
Najczęstsze pytania
Czy każdy algorytm w aplikacji zdrowotnej jest wyrobem medycznym?
Nie. Decyduje przewidziane zastosowanie. Jeśli algorytm wspiera decyzję diagnostyczną, terapeutyczną, monitorowanie albo ocenę stanu pacjenta, ryzyko objęcia go MDR jest wysokie.
Czy rozporządzenie (UE) 2024/1689 zastępuje MDR?
Nie. Dla oprogramowania medycznego podstawą oceny zgodności wyrobu zostaje MDR. Rozporządzenie (UE) 2024/1689 dokłada wymagania dla systemów wysokiego ryzyka, ale trzeba je prowadzić spójnie, bez dublowania i bez sprzecznej dokumentacji.
Od czego zacząć przy aplikacji algorytmicznej?
Od kwalifikacji: przewidziane zastosowanie, użytkownik, wpływ wyniku na decyzję kliniczną, klasa MDR i lista dowodów. Dopiero potem warto budować pełną dokumentację.
Ocenimy oprogramowanie przed wejściem na rynek UE
Ocena gotowości aplikacji, algorytmu lub platformy cyfrowej do rynku UE: kwalifikacja op…
Zobacz →Przeprowadzimy ocenę kliniczną wyrobu zgodnie z MDR
Ocena kliniczna wyrobu medycznego zgodna z art. 61 i Załącznikiem XIV MDR: CEP, CER, PMC…
Zobacz →Ocenimy zmianę w wyrobie pod kątem MDR
Ocena, czy zmiana wyrobu, oprogramowania, etykiety, dostawcy, materiału lub przewidziane…
Zobacz →Zakres prac i wycena
Wstępna kwalifikacja obejmuje oprogramowanie medyczne, regułę 11, braki w walidacji, cyberbezpieczeństwie i danych klinicznych oraz kolejność potrzebnych prac.