Projektowanie wyrobu medycznego nie kończy się na uzyskaniu certyfikacji. W rzeczywistości system PMS musi być zaplanowany i udokumentowany już na etapie składania dokumentacji technicznej do jednostki notyfikowanej. Zgodnie z Medical Device Regulation 2017/745 (MDR), PMS jest integralną częścią systemu zarządzania jakością (QMS) producenta i obejmuje aktywne monitorowanie bezpieczeństwa oraz działania przez cały cykl życia wyrobu. Skuteczne gromadzenie danych eksploatacyjnych, obsługa działań korygujących (CAPA) i zarządzanie ryzykiem wymagają uwzględnienia odpowiednich mechanizmów sprzętowych już na wczesnym etapie R&D architektury systemów wbudowanych.
Co to jest Post-Market Surveillance (PMS)?
Post-Market Surveillance (PMS) to ustrukturyzowany proces proaktywnego gromadzenia i analizowania danych z codziennej eksploatacji wyrobów medycznych, bezpośrednio wymagany przez rozporządzenie MDR oraz pośrednio przez normę ISO 13485: wspiera PMS poprzez wymagania dotyczące feedbacku, analizy danych i nadzoru po wprowadzeniu do obrotu.
Prawidłowo zaprojektowany system wbudowany musi wspierać procedury PMS poprzez generowanie wiarygodnych i integralnych danych. Jako inżynierowie w ICU tech wiemy, że sprzęt musi być przygotowany na:
- Zapis parametrów krytycznych: Ciągłe monitorowanie napięć, temperatur i integralności pamięci w trakcie pracy urządzenia.
- Rejestrowanie błędów: Zapisywanie kodów błędów w nieulotnej pamięci (NVM), aby umożliwić późniejszą diagnostykę serwisową.
- Zarządzanie zużyciem komponentów: Liczniki cykli dla elementów elektromechanicznych (np. przekaźników, zaworów) lub źródeł światła, informujące o konieczności kalibracji lub wymiany.
Autodiagnostykę (BIST – Built-In Self-Test): Wykonywaną przy każdym uruchomieniu, weryfikującą poprawność działania kluczowych układów peryferyjnych.
Czym różni się PMS od PMCF?
PMCF (Post-Market Clinical Follow-up) stanowi uszczegółowioną gałąź systemu PMS, skoncentrowaną wyłącznie na ciągłej weryfikacji długoterminowego bezpieczeństwa i wydajności klinicznej wyrobu w warunkach rzeczywistych.
Podczas gdy PMS dotyczy ogólnego bezpieczeństwa i działania sprzętu (w tym usterek mechanicznych czy elektronicznych), PMCF bada, czy urządzenie faktycznie przynosi zakładany efekt terapeutyczny lub diagnostyczny u pacjenta.
Parametr analizy | Post-Market Surveillance (PMS) | Post-Market Clinical Follow-up (PMCF) |
Główny cel | Identyfikacja awarii, usterek sprzętowych, reklamacji (CAPA). | Potwierdzenie skuteczności klinicznej i braku długoterminowych skutków ubocznych. |
Zakres danych | Logi z mikrokontrolera, raporty serwisowe, analiza uszkodzeń PCBA. | Wyniki badań pacjentów, ankiety od lekarzy, dane z rejestrów medycznych. |
Wymóg R&D | Implementacja Watchdoga, pamięci EEPROM na logi, mechanizmów OTA. | Eksport wiarygodnych danych pomiarowych przez bezpieczne interfejsy (np. BLE, Wi-Fi z szyfrowaniem). |
Klasa wyrobu | Obowiązkowe dla wszystkich klas (I, IIa, IIb, III). | Formalnie wymagane dla klas IIa, IIb i III. Dla klasy I: producent musi sporządzić plan PMCF i pisemnie uzasadnić ewentualny brak działań |
(Uwaga: MDR i ISO 13485 nie narzucają konkretnych rozwiązań sprzętowych — są to rekomendowane praktyki inżynierskie umożliwiające spełnienie wymogów walidacji i zarządzania ryzykiem.)
Raportowanie PMS a klasa wyrobu
MDR różnicuje formę raportowania wyników PMS w zależności od klasy wyrobu. Producenci klasy I zobowiązani są do sporządzenia Post-Market Surveillance Report (PMSR) zgodnie z Art. 85 — dokumentu aktualizowanego w miarę potrzeb i udostępnianego organom nadzoru na żądanie. Producenci klas IIa, IIb i III muszą natomiast przygotowywać Periodic Safety Update Report (PSUR) zgodnie z Art. 86, który podlega przeglądowi jednostki notyfikowanej. Częstotliwość aktualizacji PSUR wynosi co najmniej raz na dwa lata dla klasy IIa oraz co najmniej raz w roku dla klas IIb i III. Ma to bezpośrednie przełożenie na wymagania wobec systemu logowania danych — im wyższa klasa, tym bardziej regularne i ustrukturyzowane muszą być dane zbierane przez elektronikę urządzenia.
Wpływ fazy R&D na logowanie zdarzeń
Projektowanie układów elektronicznych z myślą o PMS wymaga zintegrowania sprzętowych mechanizmów logowania zdarzeń krytycznych oraz systematycznej weryfikacji i walidacji parametrów pracy urządzenia.
Z punktu widzenia inżynierii sprzętowej, proces pozyskiwania danych do analizy ryzyka po wprowadzeniu na rynek opiera się na fizycznej architekturze urządzenia:
- Pamięć nieulotna dla logów: Wydzielona logicznie przestrzeń pamięci (np. zewnętrzne układy SPI/I2C EEPROM lub Flash) musi być zaimplementowana wyłącznie w celu przechowywania dziennika zdarzeń (tzw. logi). Pamięć ta musi posiadać zabezpieczenia przed korupcją danych w przypadku nagłego spadku napięcia zasilania.
- Znacznik czasowy: Każdy wpis w logu zdarzeń musi posiadać jednoznaczny i odtwarzalny znacznik czasu. Wymagany jest mechanizm zapewniający spójne i odtwarzalne znaczniki czasu (np. RTC lub synchronizacja z systemem nadrzędnym).
- Monitorowanie zasilania i temperatur: Dodatkowe sensory temperatury w strefach krytycznych (np. przy układach zasilania) oraz obwody ADC monitorujące linie zasilające. Przegrzanie lub niestabilność zasilania to najczęstsze przyczyny błędnego działania algorytmów.
- Izolacja galwaniczna interfejsów diagnostycznych: Aby odczyt logów przez serwisanta nie stwarzał zagrożenia dla pacjenta lub operatora, porty debugowania i odczytu muszą spełniać normy izolacji dla elektroniki medycznej.
Architektura sprzętowa a obsługa CAPA
Zdalna aktualizacja oprogramowania układowego (OTA – Over-The-Air) to jedno z kluczowych narzędzi technicznych wspierających CAPA, pozwalający na sprawną realizację procedur CAPA bez konieczności kosztownego fizycznego zwrotu urządzeń do serwisu.
Gdy dział jakości zidentyfikuje anomalię w działaniu urządzenia na podstawie danych z PMS, najczęstszym krokiem korygującym jest modyfikacja algorytmów sterujących. Dedykowane systemy wbudowane muszą wspierać ten proces w sposób całkowicie bezpieczny (Safety).
Problem zidentyfikowany w PMS | Rozwiązanie R&D (Architektura / Firmware) | Korzyść w procesie CAPA |
Zawieszanie się urządzenia w specyficznych warunkach (np. zakłócenia EMC). | Zastosowanie niezależnego układu Hardware Watchdog Timer oraz zapis stanu rejestrów przed resetem w strukturze no-init RAM. | Dokładna analiza stanu MCU w momencie awarii; wdrożenie poprawki bez wymiany sprzętu. |
Konieczność pilnej zmiany parametrów dawkowania/pomiaru. | Architektura Dual-Bank Flash. Urządzenie pobiera nowy firmware w tle i przełącza banki tylko po weryfikacji sumy kontrolnej (CRC/SHA). | Eliminacja ryzyka „uceglenia” (brick) urządzenia podczas aktualizacji u klienta. |
Degradacja mechaniczna elementów ruchomych szybciej niż w analizie ryzyka. | Zaimplementowanie w firmware algorytmów Predictive Maintenance bazujących na pomiarze prądu pobieranego przez silniki. | Możliwość wcześniejszej wymiany części serwisowej zanim nastąpi awaria u pacjenta. |
Traceability: Śledzenie partii produkcyjnych
Pełna identyfikowalność komponentów (traceability) na poziomie wynikającym z MDR oraz dobrych praktyk jakościowych (ISO 13485) , pozwalającym na precyzyjne izolowanie wadliwych serii produkcyjnych w przypadku incydentów zgłaszanych w ramach PMS.
Kluczowe praktyki wdrożeniowe, stosowane przez ICU tech, obejmują:
- Grawerowanie laserowe kodów DataMatrix na PCB: Pozwala to powiązać fizyczny prototyp PCB, a następnie produkt seryjny, z cyfrową historią montażu maszyny Pick&Place.
- Rejestrowanie numerów seryjnych w MCU: Wgrywanie unikalnych identyfikatorów urządzenia (UDI) do zabezpieczonego przed zapisem obszaru pamięci mikrokontrolera (np. OTP – One Time Programmable).
- Śledzenie partii komponentów: Utrzymanie ścisłej kontroli nad numerami partii krytycznych układów scalonych, zgodnie z wymogami UDI określonymi w Art. 27 i Annex VI MDR., Pomocne narzędzia procesowe to m.in. standard IPC-1782 oraz wewnętrzne procedury BOM traceability zgodne z ISO 13485..
- Powiązanie logów z numerem rewizji sprzętu: Wymóg, aby system operacyjny (np. RTOS) dodawał do każdego pakietu diagnostycznego informację o dokładnej wersji sprzętowej oraz wersji oprogramowania.
Błędy i ryzyka: Brak myślenia o PMS w projektowaniu
Ignorowanie wymogów monitorowania po wprowadzeniu na rynek w fazie koncepcyjnej prowadzi do strukturalnych deficytów, uniemożliwiających identyfikację przyczyn źródłowych w przypadku awarii.
Case study: Producent urządzenia do infuzji zaprojektował system bez odpowiedniej pamięci nieulotnej dla zdarzeń krytycznych. Gdy szpitale zaczęły zgłaszać losowe błędy dawkowania (reklamacje w ramach PMS), dział inżynieryjny nie miał dostępu do parametrów stanu urządzenia z momentu wystąpienia błędu. Z powodu braku logów z układu ADC mierzącego zasilanie oraz z rejestrów Watchdoga, ustalenie przyczyny źródłowej zajęło 6 miesięcy, wymuszając wstrzymanie sprzedaży i globalną akcję serwisową. Poprawnie zaprojektowana architektura z pamięcią na logi środowiskowe pozwoliłaby na diagnozę w ciągu tygodnia i rozwiązanie problemu przez szybki update firmware’u.
FAQ
Jakie dane mikrokontroler powinien zbierać na potrzeby analizy PMS?
System wbudowany powinien logować kody błędów peryferiów, stany maszyny (State Machine) w momencie resetu, wartości graniczne z czujników (przekroczenia tolerancji temperatury, napięcia), wyniki autotestów (BIST) oraz liczby cykli uruchomieniowych elementów zużywających się.
Czy system logowania do PMS spowalnia pracę RTOS?
Nie, pod warunkiem prawidłowej architektury. Zapisy do pamięci nieulotnej (EEPROM/Flash) powinny być realizowane asynchronicznie lub buforowane, np. w RTOS powinny być realizowane przez zadanie o niskim priorytecie i kolejkowane, aby nie blokować procesów krytycznych czasowo (np. sterowania silnikiem).
Jak przygotować elektronikę do procesu CAPA w warunkach medycznych?
Kluczem jest zapewnienie mechanizmu zdalnej i bezpiecznej aktualizacji oprogramowania (OTA/Bootloader). Wymaga to odpowiedniego doboru mikrokontrolera z podwójnym bankiem pamięci Flash oraz implementacji sprzętowych akceleratorów kryptograficznych do weryfikacji podpisów cyfrowych (RSA/ECC) wgrywanego pliku binarnego.
W jakim stopniu norma ISO 13485 narzuca rozwiązania układowe?
ISO 13485 nie narzuca konkretnych mikrokontrolerów ani topologii schematu, lecz stawia rygorystyczne wymagania dotyczące zarządzania ryzykiem, identyfikowalności i walidacji projektu. Narzuca więc konieczność stosowania takich rozwiązań R&D (jak RTC, pamięci logów), które umożliwią późniejsze udowodnienie bezpieczeństwa i niezawodności wyrobu.
Czy moduły komunikacji bezprzewodowej wpływają na certyfikację wyrobu medycznego?
Tak. Implementacja modułów (np. BLE, Wi-Fi) do przesyłania danych PMS/PMCF wymusza przeprowadzenie zaawansowanych badań pod kątem kompatybilności elektromagnetycznej (zakłócenia EMC) oraz koegzystencji bezprzewodowej, by sygnał radiowy nie zakłócał odczytów czujników medycznych.
Kluczowe wnioski
Zabezpiecz budżet R&D na telemetrię od pierwszego dnia. Implementacja pamięci Flash/EEPROM, układów RTC i stabilnego Bootloadera znacząco obniża koszt obsługi potencjalnych kryzysów jakościowych po wdrożeniu produktu na rynek.
Architektura pod OTA ratuje wskaźniki CAPA. Certyfikacja urządzeń elektronicznych i ich wdrożenie to początek drogi. Posiadanie bezpiecznego i redundantnego systemu aktualizacji oprogramowania (Dual-Bank Flash) jest najszybszą metodą na zamykanie zgłoszeń reklamacyjnych bez konieczności kosztownego ściągania sprzętu (Recall).
Traceability to fundament kontroli nad produktem. Zapewnij pełną kontrolę nad łańcuchem dostaw i procesem produkcji (grawerowanie PCB, wpisywanie identyfikatorów do OTP mikrokontrolera). Brak precyzyjnego śledzenia partii uniemożliwia izolowanie wady do konkretnej serii produkcyjnej, narażając firmę na ryzyko wycofania całego wolumenu rynkowego.
