Elektroniczny obieg CAPA u producenta wyrobów medycznych: ISO 13485, FDA i Power Platform

CAPA (od ang. Corrective and Preventive Action) to działania korygujące i zapobiegawcze. Firma ustala w nich przyczynę problemu, usuwa ją i sprawdza, czy problem nie wraca. W normie ISO 13485 opisują je punkty 8.5.2 i 8.5.3.

Weźmy hipotetycznego producenta wyrobów medycznych zatrudniającego 150 osób. Rejestr spraw CAPA prowadzi w Excelu, analizy przyczyn w Wordzie, a ustalenia zapadają w mailach. Przed audytem kierowniczka jakości przez kilka dni zbiera dowody z trzech miejsc i sprawdza, która wersja formularza jest ostateczna.

Taki układ ma trzy słabe punkty. Nie widać, kto i kiedy zmienił zapis. Terminów pilnuje jedna osoba, więc sprawdzenie skuteczności po kilku miesiącach łatwo przepada. A dowody wykonania działań leżą w skrzynkach poszczególnych pracowników.

Wymagania pochodzą z kilku źródeł, które często się myli. W tabeli poniżej zebraliśmy, co każde z nich oznacza dla systemu informatycznego, a nie dla całego systemu jakości.

Dwie rzeczy zmieniły się niedawno lub bywają opisywane błędnie. Od 2 lutego 2026 r. FDA stosuje QMSR, która zastąpiła dawny tekst 21 CFR 820 i przywołuje ISO 13485:2016. Firmy sprzedające w USA i w UE mają więc w sprawie CAPA wspólny punkt odniesienia – normę ISO 13485, choć QMSR dodaje do niej kilka własnych wymagań.

Druga sprawa to okres przechowywania zapisów. ISO 13485 nie podaje sztywnych „5 lat”: zapisy trzeba trzymać przez okres życia wyrobu, nie krócej niż 2 lata od zwolnienia wyrobu przez producenta. W UE nakłada się na to 10 lub 15 lat z MDR, więc system musi przechowywać dane dłużej niż typowe firmowe archiwum.

Niezależnie od narzędzia sprawa CAPA przechodzi przez te same etapy. Dla każdego warto z góry ustalić, kto odpowiada, ile ma czasu i jaki dowód zostawia w systemie:

W firmie, która ma już Microsoft 365, obieg CAPA składa się zwykle z czterech elementów. SharePoint przechowuje dokumenty: raporty z analizy, plany i dowody wykonania. Dataverse, czyli baza danych Power Platform, trzyma same sprawy CAPA z polami takimi jak status, termin, wyrób i przyczyna.

Power Automate wysyła zadania, przypomnienia i przekazuje sprawy dalej po terminie. Power Apps daje formularze dla działu jakości, a Teams – powiadomienia i proste potwierdzenia. Power BI pokazuje zarządowi, ile spraw jest otwartych, jak długo trwają i z jakich źródeł pochodzą.

Trzy ustawienia decydują o tym, czy całość przejdzie audyt. Pierwsze: dziennik zmian w Dataverse trzeba włączyć dla środowiska, tabeli i kolumn – sam się nie włącza. Zapisuje on, kto zmienił pole, kiedy i jaka była poprzednia wartość.

Drugie: uprawnienie do usuwania historii zmian musi mieć bardzo wąskie grono osób, najlepiej nikt z działu jakości. Trzecie: jedno uruchomienie procesu w Power Automate trwa najwyżej 30 dni. Sprawdzenie skuteczności po kilku miesiącach planuj więc jako codzienną kontrolę terminów, a nie jako proces, który czeka.

Wokół podpisu elektronicznego narosło wiele mitów. Przepis 21 CFR 11.200 wymaga dwóch odrębnych elementów identyfikacji, na przykład identyfikatora i hasła. Logowanie wieloskładnikowe, czyli dodatkowy kod z telefonu, jest dobrą praktyką, ale przepis go nie nakazuje.

Do podpisu należy dołączyć imię i nazwisko, datę z godziną oraz znaczenie podpisu, na przykład „zatwierdzam plan działań” (11.50). Podpis musi być trwale powiązany z zapisem, tak by nie dało się go skopiować do innego dokumentu (11.70).

Jest też obowiązek, o którym firmy często nie wiedzą. Przed użyciem podpisów elektronicznych trzeba pisemnie poświadczyć wobec FDA, że są one prawnym odpowiednikiem podpisu odręcznego (11.100). W Microsoft 365 podpis buduje się zwykle w Power Apps: ponowne podanie danych logowania przez Microsoft Entra ID, wpis znaczenia i zapis w Dataverse.

Firmy sprzedające tylko w UE nie podlegają Part 11. MDR nie ma jego odpowiednika, a wymagania wynikają z ISO 13485: zapis musi być czytelny, a każda zmiana – rozpoznawalna. Wiele firm i tak projektuje system według Part 11, żeby nie przebudowywać go przy wejściu na rynek USA.

Walidacja to udokumentowany dowód, że system robi to, czego firma od niego wymaga. ISO 13485 wymaga jej przed pierwszym użyciem oprogramowania w systemie jakości i po każdej istotnej zmianie. Aplikacja zbudowana przez pracownika i używana do spraw CAPA bez walidacji to częsta niezgodność w audycie.

Walidujesz konkretną aplikację, a nie całą platformę. Microsoft publikuje dla Microsoft 365 i Power Platform wytyczne GxP, czyli opis dobrych praktyk dla branż regulowanych, takich jak farmacja i wyroby medyczne. Opisują one zabezpieczenia Microsoft i podział odpowiedzialności z klientem. To pomaga w ocenie dostawcy, ale nie zastępuje testów Twojej aplikacji.

Zakres walidacji powinien wynikać z ryzyka, a nie z przyzwyczajenia do grubych segregatorów. Tak samo ujmują to ISO 13485 i wytyczne FDA o zapewnieniu jakości oprogramowania z września 2025 r. Funkcje wpływające na decyzje o bezpieczeństwie wyrobu testujesz szczegółowo, a raport z liczbą otwartych spraw – lżej.

W praktyce przygotowujesz wymagania użytkownika, ocenę ryzyka funkcji, scenariusze testów i raport z wynikami. Każda późniejsza zmiana w aplikacji przechodzi kontrolę zmian i ocenę, czy wymaga ponownych testów. Dlatego walidację planuje się od początku projektu, razem z działem jakości.

Nie każda firma powinna budować CAPA sama. Gotowe systemy do zarządzania jakością w branży medycznej mają zwalidowane moduły i pakiety dokumentacji walidacyjnej od dostawcy. Kosztują jednak osobne licencje i tworzą kolejne miejsce, do którego trzeba się logować. Porównanie w tabeli poniżej pomoże wybrać kierunek.

Większość problemów w audycie nie wynika z wyboru narzędzia, tylko z pominiętych kroków. Te powtarzają się najczęściej:

Pierwszym krokiem nie jest wybór narzędzia, tylko ocena obecnego procesu. Poniższa kolejność sprawdza się w większości firm: