← Wróć do Insights

CSV (Computer System Validation) w praktyce: walidacja systemów komputerowych medycznych

CSV (Computer System Validation) w realnych systemach medycznych to nie „pełna dokumentacja wszystkiego”, tylko twarde decyzje o granicach systemu, krytyczności i dowodach, które obronią się w audycie.

Materiał jest NDA-safe i oparty na powtarzalnych wzorcach pracy z systemami złożonymi (HW/SW, integracje, dane kliniczne), bez ujawniania klientów ani detali produktu.

TL;DR

• Zakres CSV musi jasno wskazywać granice systemu oraz odpowiedzialność za interfejsy.
• Traceability działa tylko wtedy, gdy testy mają identyfikowalny build, konfigurację i logi.
• Najczęstsze luki audytowe wynikają z nieudokumentowanych integracji i przepływów danych.
• Evidence pack powinien pozwolić QA przejść od wymagania do wyniku testu bez domysłów.
• Złożone systemy HW/SW wymagają jawnych reguł rewalidacji po każdej zmianie.

Zakres CSV w praktyce: gdzie kończy się system

Najtrudniejsze pytania pojawiają się na granicach: czy zewnętrzny LIS jest poza zakresem, ale interfejs nadal weryfikowany? czy narzędzie serwisowe jest elementem systemu? Odpowiedź musi być opisana i uzasadniona w planie walidacji.

Przykładowe decyzje zakresowe dla realnych systemów:

Rozróżnienia regulacyjne, które warto zapisać na początku

• Kwalifikacja wyrobu: decyzja, czy rozwiązanie jest wyrobem medycznym w rozumieniu MDR i jaka jest ścieżka regulacyjna; nie jest to to samo co klasyfikacja ryzyka.
• Walidacja systemu: potwierdzenie, że cały system (HW/SW + procesy + konfiguracja) spełnia zamierzone użycie w środowisku docelowym.
• Walidacja oprogramowania: dowody dla wymagań i ryzyk związanych z samym software (IEC 62304), niezależnie od kwalifikacji wyrobu.

Traceability w praktyce: co pęka na audycie

• Brak jednoznacznego powiązania testu z konkretną wersją builda i konfiguracją.
• Nieaktualny RTM, który nie obejmuje zmian w interfejsach lub danych.
• Testy podpisane, ale bez surowych danych lub logów potwierdzających wynik.
• Zmiany „konfiguracyjne” traktowane jak neutralne, mimo że wpływają na krytyczne ścieżki.
• Brak mapy danych i przepływów, co utrudnia ocenę integralności.

Artefakty i dowody, które realnie ratują audyt

• Plan walidacji z uzasadnieniem zakresu i kryteriów rewalidacji.
• Opis systemu i diagram granic z uwzględnieniem integracji.
• URS/SRS z przypisaniem krytyczności i akceptacji.
• RTM: wymaganie → test → dowód, z linkiem do logu.
• Konfiguracja systemu (wersje OS, bibliotek, firmware, parametrów).
• Raporty z testów integracyjnych i testów danych krytycznych.
• Lista SOUP + ocena dostawców i status podatności.
• Log odchyleń i decyzje o retestach po zmianach.

Przykłady dowodów akceptowanych w praktyce

• Logi protokołu (np. HL7) z identyfikatorem testu i timestampem.
• Zrzuty konfiguracji z podpisem i numerem wersji.
• Raporty z testów automatycznych z pełnym śladem danych wejściowych.
• Podpisane protokoły testów manualnych z surowymi danymi w załączniku.
• Raporty z kontroli integralności danych (hash, checksum, kontrola kompletności).

Checklista gotowości audytowej (evidence-first)

• Czy dla każdej zmiany istnieje formalna analiza wpływu i decyzja o rewalidacji?
• Czy QA potrafi w 2 minuty znaleźć dowód dla losowo wybranego wymagania?
• Czy testy integracyjne są powtarzalne i osadzone w wersjach oprogramowania?
• Czy dane krytyczne mają zdefiniowane kontrole integralności?
• Czy istnieje jawna lista systemów i interfejsów poza zakresem, ale weryfikowanych?

Decyzje trade-off, które muszą być jawne

CSV w praktyce to kompromisy między szerokością zakresu a jakością dowodów. Te decyzje powinny być zapisane, bo to o nie najczęściej pyta audytor.

• Co testujesz automatycznie, a co zostaje jako test manualny z pełnym logiem?
• Które integracje wymagają pełnego testu end-to-end, a gdzie wystarczy test kontraktu danych?
• Jak często aktualizujesz SOUP i jakie dowody akceptujesz od dostawców?
• Jakie zmiany traktujesz jako „konfiguracyjne”, a jakie jako funkcjonalne?

Typowe tryby awarii CSV w systemach złożonych (HW/SW, integracje)

• Rozdzielenie HW i SW w dokumentacji bez opisania ich wspólnych interfejsów.
• Integracje „poza zakresem” bez dowodów kompatybilności.
• Brak planu testów dla aktualizacji i rollbacku.
• Nieudokumentowane parametry konfiguracyjne wpływające na wyniki kliniczne.
• Przejście na nowe biblioteki/SOUP bez aktualizacji śladu ryzyk.

Powiązany kontekst IEC 62304

Jeśli potrzebujesz praktycznego kontekstu zmiany platformy pod IEC 62304, zobacz migration checklist Windows CE → Windows 10 IoT.

Najczęstsze błędy w projektach tego typu

• Zbyt szeroki zakres CSV bez priorytetyzacji krytyczności.
• Traceability zrobione „na koniec”, bez aktualnych wersji testów i logów.
• Niedoszacowanie integracji i przepływów danych w walidacji.
• Brak reguł, kiedy zmiana wymaga pełnej rewalidacji.
• Dowody rozproszone w wielu miejscach bez mapy QA.

Kiedy warto wezwać wsparcie

Jeśli zakres CSV jest niejasny, a dowody są rozproszone lub niepełne, szybki przegląd dojrzałości potrafi oszczędzić tygodnie re-testów. W razie potrzeby skontaktuj się przez stronę kontaktową.

• Przegląd zakresu i granic systemu dla CSV.
• Ocena traceability i gotowości dowodów pod audyt.
• Strategia rewalidacji po zmianach HW/SW.
• Ujednolicenie artefaktów i mapy dowodów dla QA.