Automatyzacja CAPA workflow w medtech – ISO 13485 i Power Platform

CAPA (Corrective and Preventive Action) to systematyczny proces identyfikacji, dokumentacji, korekty i zapobiegania niezgodnościom w systemie zarządzania jakością. W medtech jest jednym z głównych procesów wymaganych przez ISO 13485 (sekcja 8.5) oraz FDA 21 CFR Part 820.100. Bez funkcjonującego CAPA – nie ma certyfikacji, nie ma rynku.

W praktyce CAPA wciąż w wielu firmach żyje w trzech narzędziach: Excel (rejestr), Word (formularze), mailbox (komunikacja). Skutkiem jest brak audit trail w pojedynczym systemie, ryzyko utraty zapisów, niespójne wersje formularzy między działami i tygodnie na zamknięcie pojedynczego CAPA. W audycie FDA lub TÜV to obszar najczęściej generujący observations i nonconformities.

Automatyzacja CAPA workflow ma więc dwa wymiary: operacyjny (skrócenie cyklu CAPA z miesięcy do tygodni) i regulacyjny (zgodność z wymaganiami audit trail i e-signature). Bez obu wymiarów inwestycja nie ma uzasadnienia – tylko operacyjny powoduje nieakceptowalność dla audytora, tylko regulacyjny powoduje niechęć zespołów do używania.

Pierwszy etap to identyfikacja i rejestracja źródła CAPA. Źródłami są zwykle: skargi klienta, nonconformity z audytu wewnętrznego, awarie produkcyjne, raporty z post-market surveillance, ryzyka zidentyfikowane przez risk management. Każde źródło musi mieć unikalny identyfikator, datę, opis i klasyfikację wstępną (severity).

Drugi etap to investigation – analiza przyczyn root cause. Wykorzystuje się tutaj narzędzia jak 5 Why, fishbone diagram, FMEA. Wynikiem jest opis przyczyny pierwotnej (root cause) z udokumentowanym uzasadnieniem. Investigator musi być przypisany imiennie, a termin zakończenia investigation – określony.

Trzeci etap to action plan – plan działań korygujących (corrective) i zapobiegawczych (preventive). Każde działanie ma owner, termin, zasoby, kryterium sukcesu. Plan musi być zatwierdzony przez Quality Manager lub odpowiednika.

Czwarty etap to implementation – realizacja planu. Każde działanie jest oznaczane jako ukończone, z dowodem realizacji (dokument, screenshot, podpis). Wszystkie te elementy żyją w audit trail.

Piąty etap to effectiveness check – sprawdzenie po określonym czasie (zwykle 3–6 miesięcy), czy działania CAPA faktycznie wyeliminowały przyczynę. To często najsłabszy etap w klasycznym CAPA, bo bez workflow nikt nie wraca do tematu po 3 miesiącach. Po pozytywnej weryfikacji CAPA jest formalnie zamykane.

ISO 13485 jest podstawowym standardem dla medtech. Wymaga udokumentowanego procesu CAPA, traceability każdej decyzji, retention zapisów przez minimum 5 lat (często więcej, w zależności od produktu), oraz okresowych przeglądów efektywności CAPA przez management.

FDA 21 CFR Part 11 (electronic records, electronic signatures) jest wymagany przy sprzedaży na rynek USA i jest najbardziej rygorystycznym standardem. Wymaga: walidacji systemu (Computer System Validation, CSV), audit trail z timestampem dla każdej zmiany, e-signature z dwuelementową weryfikacją (zwykle login + hasło + kod jednorazowy), nieprzerywalnego linkowania podpisu z dokumentem, retention electronic records przez wymagany okres.

MDR (Medical Device Regulation) w Europie dodaje wymóg post-market surveillance i Periodic Safety Update Reports (PSUR), które są zasilane danymi z CAPA. Workflow musi więc wspierać agregację CAPA per produkt do raportów PSUR.

Inne sektorowe regulacje (IVDR, IEC 62304 dla software jako medical device, GxP dla farmaceutyków) dodają własne wymagania. Wszystkie one mają wspólny mianownik: audit trail + e-signature + traceability + retention. To są te elementy, które workflow musi zapewnić by-design – nie jako add-on.

Standardowa architektura CAPA workflow w ekosystemie Microsoft składa się z czterech warstw: warstwy dokumentu (SharePoint), warstwy danych procesowych (Dataverse), warstwy workflow (Power Automate) i warstwy interfejsu (Power Apps + Teams).

SharePoint przechowuje dokumenty CAPA (raport investigation, action plan, dowody implementacji), z polityką retencji, sensitivity labels, audit trail i wersjonowaniem. Dla zgodności z FDA Part 11 wymagana jest dodatkowa konfiguracja: read-only po podpisie, immutable storage, retention policy 5+ lat.

Dataverse trzyma dane procesowe CAPA – każde CAPA jako record z polami: ID, status, source type, severity, owner, dates, related products, root cause. Dataverse zapewnia natywny audit trail każdej zmiany, RBAC i scalable performance.

Power Automate orkiestruje workflow – uruchamia powiadomienia, automatyczne eskalacje przy przekroczonych SLA, przypomnienia o effectiveness check, generowanie raportów PSUR, integracje z systemami zewnętrznymi (PLM, ERP, post-market surveillance tools).

Power Apps + Teams to interfejs użytkownika – Power App dla zaawansowanych ekranów (formularze investigation, action plan management, dashboardy Quality Managera), Teams dla powiadomień i lekkich akcji (potwierdzenie ukończenia action item, e-signature). Cały stack opiera się na zasadach z SharePoint governance – bez governance całość się rozjeżdża.

Najtrudniejszy element zgodności z FDA Part 11 to e-signature. Wymaga dwuelementowej weryfikacji tożsamości (zwykle login + hasło + drugi czynnik – kod jednorazowy lub MFA), trwałego linkowania podpisu z dokumentem, niezmieniającej się reprezentacji podpisu (Printed Name + Date + Reason), oraz zabezpieczenia przed odmową podpisu (non-repudiation).

W stack Microsoft realizacja FDA Part 11 e-signature wymaga zwykle: Entra ID z MFA dla wszystkich użytkowników CAPA, integracji z SharePoint sensitivity labels dla immutable storage podpisanego dokumentu, dedicated Power Apps screen do e-signature (z reason, timestamp, IP) lub integracji z third-party narzędziem (DocuSign, Adobe Sign, ValidSign) – każde z nich oferuje validated FDA Part 11 module.

Audit trail jest drugim filarem. Każda zmiana – pole formularza, dodanie komentarza, change status, attachment dokumentu – musi być zarejestrowana z user, timestamp, before/after values, reason for change. Dataverse audit trail jest natywnie wystarczający przy odpowiedniej konfiguracji. SharePoint dodaje audit dokumentów. Razem stanowią immutable log, który audytor może odtworzyć.

Trzeci element to retention. ISO 13485 wymaga 5+ lat, ale wiele firm stosuje 10–15 lat (lub życie produktu + 2 lata). Polityki retencji w Microsoft Purview pozwalają to zautomatyzować z poziomu organizacji.

Computer System Validation (CSV) to obowiązkowy etap dla systemów CAPA stosowanych w branżach regulowanych. Wymóg pochodzi z FDA 21 CFR Part 11 i GAMP 5 (Good Automated Manufacturing Practice). W praktyce CSV ma trzy fazy: IQ (Installation Qualification – weryfikacja, że system jest zainstalowany poprawnie), OQ (Operational Qualification – weryfikacja, że działa zgodnie ze specyfikacją), PQ (Performance Qualification – weryfikacja, że spełnia wymagania użytkownika w środowisku produkcyjnym).

Dla rozwiązań Microsoft Power Platform CSV wymaga: dokumentacji User Requirements (URS), Functional Specification (FS), Design Specification (DS), planu testów, raportów IQ/OQ/PQ, traceability matrix między URS a testami. Cały pakiet dokumentacji często liczy 200–500 stron i jest przechowywany jako część QMS.

Krytyczna decyzja: czy walidujemy całą Power Platform, czy tylko konkretny CAPA workflow? Standardowa praktyka to walidacja konkretnej aplikacji, z traktowaniem Power Platform jako infrastructure (z wymaganiem vendor qualification od Microsoft). Microsoft dostarcza dokumentację GxP attestation, która ułatwia ten proces.

CSV trwa zwykle 3–6 miesięcy i wymaga zaangażowania specjalisty Quality (nie wystarczy zespół IT). Po pierwszym wdrożeniu kolejne aplikacje CAPA są walidowane szybciej (2–4 tygodnie) bazując na first-time framework.

CAPA nie żyje w izolacji – jest częścią szerszego QMS (Quality Management System). Typowe integracje obejmują: complaint management (źródło CAPA), change control (zmiany wynikające z CAPA), document control (procedury i instrukcje), training records (treningi związane z action items), risk management (CAPA jako efekt risk assessment), supplier management (CAPA na bazie reklamacji od dostawców).

W ekosystemie Microsoft typowe integracje: SharePoint Document Library jako document control z linkowaniem do CAPA records w Dataverse. Power BI dla dashboards QMS – trendy CAPA, czas zamknięcia, source breakdown, effectiveness rate. Integracja z dedicated QMS (MasterControl, ETQ, Veeva, Greenlight Guru, Sparta TrackWise) przez REST API – wiele organizacji używa hybrydy: Power Platform dla nowoczesnego UX + dedicated QMS dla regulatory backbone.

Drugi obszar to integracja z post-market surveillance. CAPA z source 'customer complaint' lub 'adverse event' musi być agregowana do raportów PSUR (MDR) lub MDR reports (FDA 21 CFR 803). Power Automate i Power BI razem realizują tę agregację z poziomu Dataverse.

Trzeci obszar to AI – nowsza warstwa, którą warto zaprojektować z myślą o AI governance. Microsoft Copilot może wspierać quality team w drafting investigation report (z dostępem do podobnych CAPA z przeszłości), analizie root cause patterns przez kwartał, generowaniu draft PSUR reports. Wymaga jednak AI governance dopasowanego do regulacji medtech – nie wszystkie modele AI są właściwe dla danych medical device.

Pierwszy błąd to wdrożenie technologii bez walidacji. Power Apps stworzony przez citizen developer, używany do CAPA records – ale bez IQ/OQ/PQ. W audycie staje się non-compliant, mimo że technicznie działa. Walidacja jest droga (3–6 miesięcy), ale obowiązkowa.

Drugi błąd to brak procesu projektowania CAPA przed automatyzacją. Workflow w Power Platform powiela istniejący chaos z Excel – ten sam workflow, te same braki, tylko szybciej. Najpierw redesign procesu z udziałem Quality, R&D i operacji, potem implementacja workflow.

Trzeci błąd to nieadekwatny e-signature. Implementacja typu 'kliknięcie button-a z reason' nie spełnia FDA Part 11 – nie ma drugiego czynnika, nie ma non-repudiation. Trzeba użyć dedicated solution (DocuSign for Life Sciences, ValidSign) lub zbudować ją na Entra ID MFA z odpowiednią dokumentacją.

Czwarty błąd to brak effectiveness check w workflow. To najczęściej pomijany etap – po 3–6 miesiącach od zamknięcia CAPA workflow powinien automatycznie poprosić ownera o weryfikację skuteczności. Bez tego CAPA jest formalnie zamknięte, ale rzeczywista poprawa nie jest udokumentowana.

Piąty błąd to brak training records. ISO 13485 wymaga, by training na nowych procedurach (wynikających z CAPA) był udokumentowany. Workflow CAPA musi integrować się z training records – inaczej powstaje luka audytowa. Te elementy projektujemy razem z klientami w ramach wdrożeń i rozwoju z udziałem zespołów Quality.

Czy Power Platform jest validated dla GxP? Microsoft dostarcza GxP attestation dla Microsoft 365 i Power Platform jako vendor qualification (dokument Microsoft Trust Center). Validacja konkretnej aplikacji (URS/FS/DS/IQ/OQ/PQ) jest jednak nadal wymagana – validacja platformy nie zastępuje validacji aplikacji.

Czy mogę użyć Power Platform bez dedicated QMS? Tak, dla małych i średnich organizacji to często wystarczająca konfiguracja. Większe organizacje (powyżej kilkudziesięciu CAPA miesięcznie) zwykle używają hybrydy: dedicated QMS dla regulatory backbone + Power Platform dla modernizacji UX i integracji.

Jak długo trwa wdrożenie zgodnego CAPA workflow? Pełen cykl: design procesu (4–8 tygodni) + budowa workflow (6–10 tygodni) + CSV (12–20 tygodni) + szkolenia + go-live = łącznie 9–15 miesięcy. Skala zależy od liczby produktów, regulacji i istniejącego QMS.

Czy FDA 21 CFR Part 11 dotyczy mojej firmy, jeśli sprzedajemy tylko w UE? Bezpośrednio nie. Ale MDR ma podobne wymagania dla electronic records i większość firm sprzedaje też do USA. W praktyce projektowanie zgodnie z FDA Part 11 daje też zgodność z MDR.

Czy CAPA workflow nadaje się dla farma i biotech? Tak, z dodatkową warstwą GxP – ten sam stack Power Platform + SharePoint stosuje się szeroko w farma i biotech, z dedykowanymi adaptacjami pod GMP, GLP, GCP. Wymaga jednak głębszej CSV.

Jak Copilot pomoże w CAPA? W obszarach: drafting investigation report z podobnymi CAPA, analiza patterns w root causes per kwartał, generowanie draft PSUR sections, podsumowania dla management review. Wszystko jednak pod control – z AI governance dopasowanym do branży.

CAPA workflow w medtech łączy w sobie najtrudniejsze elementy enterprise automation: rygorystyczne regulacje, wymagania CSV, audit trail przez 10+ lat, integracje z resztą QMS i (coraz częściej) warstwę AI. Nie jest projektem 'na szybko' – to wdrożenie 9–15 miesięcy z udziałem zespołów Quality, IT, Compliance i operacji.

Power Platform + SharePoint dziś dają najszybszą ścieżkę do nowoczesnego, zgodnego CAPA workflow dla organizacji już używającej Microsoft 365. Wymaga to jednak profesjonalnego projektu architektury, walidacji systemu i dyscypliny ongoing governance. Bez tych elementów inwestycja staje się ryzykiem regulacyjnym.

Najsensowniejszy pierwszy krok to assessment current state CAPA w organizacji: gdzie żyją zapisy, jakie są gaps regulatoryjne, jak wygląda integracja z resztą QMS. Stamtąd reszta układa się jako etapowy program. W AlgorComp wspieramy klientów medtech w pełnym cyklu – od oceny do walidacji i go-live.