URS w MedTech: jak uzasadnić wymagania, ryzyko i koszty?

URS między ryzykiem, regulacjami i kosztem

URS ma opisywać to, czego rzeczywiście potrzebuje użytkownik i proces. Może jednak stać się miejscem, w którym niezweryfikowane założenie zamienia się w twarde wymaganie — a później w kosztowną infrastrukturę, którą trzeba utrzymywać, nadzorować i okresowo testować.

Dlatego przy tworzeniu URS warto pytać nie tylko: „Czy potrafimy spełnić to wymaganie?”, lecz także: „Jakie ryzyko ono ogranicza, z czego wynika i czy jego koszt w całym cyklu życia jest uzasadniony?”.

Wymaganie też trzeba uzasadnić

W środowisku regulowanym łatwo założyć, że skoro firma działa w sektorze medycznym lub farmaceutycznym, każde dodatkowe zabezpieczenie jest automatycznie wymagane. Tymczasem przepisy określają obowiązki i ramy systemu jakości; konkretne rozwiązanie trzeba dobrać do przeznaczenia, procesu, ryzyka, wymagań klienta i właściwych norm.

MDR i IVDR wymagają od producentów ustanowienia oraz utrzymywania systemu zarządzania jakością, ale sam ten obowiązek nie rozstrzyga, że każda infrastruktura musi mieć taki sam poziom redundancji, rezerwowania czy cyklicznych testów. Tę decyzję trzeba uzasadnić dla konkretnego zastosowania. [1][2]

Normy, wytyczne i przykłady branżowe są ważnymi źródłami wiedzy. Pomagają zauważyć ryzyka i rozwiązania, których zespół mógłby nie rozważyć. Nie powinny jednak zastępować oceny, czy dane wymaganie ma zastosowanie w konkretnym procesie. Kopiowanie pełnego pakietu wymagań z innego zakładu może przenieść także jego założenia, skalę i koszty — bez przeniesienia rzeczywistej potrzeby.

Przykład z projektu w Szwajcarii

Kilka lat temu, w jednym z projektów realizowanych w Szwajcarii, uczestniczyłem w eksperckiej ocenie wymagań dotyczących agregatu rezerwowego dużej mocy, przewidzianego dla infrastruktury wspierającej kontrolowane środowisko produkcyjne. Wstępne wymaganie obejmowało utrzymywanie całego rozbudowanego układu.

Analiza nie kończyła się na cenie zakupu. Uwzględniono charakter i klasę wyrobu, rzeczywistą krytyczność procesów, konsekwencje utraty zasilania oraz pełne zobowiązania związane z utrzymaniem rozwiązania: nadzór nad infrastrukturą, serwis, okresowe testy i zasoby potrzebne do ich dokumentowania.

W tym konkretnym przypadku zestawienie ryzyka, wartości produktu i całkowitego kosztu utrzymania nie uzasadniało podtrzymywania całego systemu w pierwotnie rozważanym zakresie. Kluczowa była nie pojedyncza cecha wyrobu, ale ocena całości: co chronimy, przed jakim scenariuszem, jak długo i jakim kosztem.

To nie jest uniwersalny wniosek, że agregaty rezerwowe albo rozbudowane systemy zasilania są zbędne. W innym zakładzie konsekwencje zaniku zasilania, krytyczność instalacji, wymagania klienta lub procesy mogą uzasadniać inne rozwiązanie. Przykład pokazuje natomiast, dlaczego wymaganie warto przeanalizować przed wpisaniem go do URS jako niepodlegającego dyskusji.

CAPEX to dopiero początek kosztu

Przy decyzji inwestycyjnej łatwo porównać ceny urządzeń, a pominąć koszty, które pojawią się później. Dla rozbudowanej infrastruktury mogą to być między innymi:

• przeglądy, serwis, części zamienne i gotowość serwisowa;
• okresowe testy, dokumentowanie wyników i zamykanie odchyleń;
• nadzór techniczny oraz czas pracowników odpowiedzialnych za system;
• zużycie energii, przestrzeń, warunki instalacji i wpływ na inne systemy;
• kwalifikacja początkowa, ocena zmian i ewentualne ponowne testy;
• koszt przestojów lub ograniczeń, gdy infrastruktura nie jest dostępna.

Nie każdy z tych kosztów występuje w każdym projekcie. Sens biznesowy polega właśnie na tym, by je zidentyfikować, oszacować i zestawić z ograniczanym ryzykiem. Niskie prawdopodobieństwo zdarzenia samo w sobie nie wystarcza, by je zignorować; wysoki koszt rozwiązania sam w sobie nie dowodzi, że rozwiązanie jest niepotrzebne.

Klasa wyrobu i jego wartość są kontekstem, nie jedynym kryterium

Klasa wyrobu, jego wartość rynkowa czy koszt jednostkowy mogą wpływać na biznesową ocenę inwestycji, ale nie powinny samodzielnie rozstrzygać o wymaganym poziomie zabezpieczeń. Trzeba uwzględnić także możliwy wpływ na pacjenta, jakość i zgodność produktu, wymagania klienta, ciągłość dostaw, skalę produkcji i możliwość wykrycia niezgodności.

Właściwe pytanie brzmi: czy proponowane rozwiązanie ogranicza określone ryzyko do poziomu akceptowanego przez firmę i jej klienta — oraz czy istnieją inne, skuteczne sposoby osiągnięcia tego celu? Dopiero wtedy można porównać warianty techniczne i koszty ich utrzymania.

Jak oceniać wymaganie w URS?

Przed zatwierdzeniem wymagania warto przejść przez krótką serię pytań:

• Jaka potrzeba procesu lub użytkownika stoi za tym wymaganiem?
• Jaki konkretny scenariusz ryzyka ma ono ograniczyć?
• Czy wymaganie wynika z przepisu, normy, umowy z klientem, czy jest wewnętrznym wyborem projektowym?
• Czy rozwiązanie można osiągnąć w prostszy sposób bez utraty kontroli nad ryzykiem?
• Jaki jest koszt zakupu, kwalifikacji, utrzymania, okresowych testów i obsługi przez cały okres używania?
• Jakie dowody będą wystarczające, aby potwierdzić działanie rozwiązania?
• Kto zaakceptuje wymaganie, jego uzasadnienie oraz późniejsze zmiany?

Odpowiedzi nie muszą prowadzić do obniżenia wymagań. Mogą potwierdzić, że pierwotny zakres jest właściwy. Wartością analizy jest to, że decyzja nie opiera się wyłącznie na przyzwyczajeniu, katalogu dostawcy czy wymaganiach skopiowanych z innego projektu.

Rola QMS: zachować tok decyzji

QMS może pomóc powiązać wymaganie z jego źródłem, oceną ryzyka, rozważanymi wariantami, zatwierdzeniem, testami i późniejszym nadzorem. Jeśli zmienia się proces, produkt lub infrastruktura, kontrola zmian pozwala ponownie ocenić, czy wcześniejsze uzasadnienie nadal obowiązuje.

Dzięki temu system jakości wspiera nie tylko wykazanie, że wymaganie zostało spełnione, lecz także wyjaśnienie, dlaczego przyjęto właśnie taki zakres. Oprogramowanie może uporządkować te powiązania, ale nie zastąpi rozmowy użytkowników, inżynierii, jakości, finansów i eksperta, który rozumie skutki decyzji w praktyce.

Ekspertyza polega również na umiejętności odradzenia

Dobra specyfikacja nie jest najdłuższa ani najbardziej restrykcyjna. Jest wystarczająco kompletna, by chronić produkt i proces, a jednocześnie możliwa do wdrożenia oraz utrzymania. Wymaga znajomości regulacji, ale także doświadczenia w pracy z urządzeniami, infrastrukturą, personelem, testami i kosztami operacyjnymi.

W Ingenes możemy pomagać klientom przejść od wymagania do uzasadnionej decyzji: uporządkować URS, powiązać wymagania z oceną ryzyka i dowodami oraz ocenić, jaki zakres jest właściwy dla konkretnego zastosowania. Celem nie jest maksymalizowanie liczby wymagań. Celem jest rozwiązanie, które odpowiada na realną potrzebę i pozostaje racjonalne w całym cyklu życia.

Źródła do weryfikacji redakcyjnej

[1] Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2017/745 (MDR), art. 10 ust. 9.

[2] Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2017/746 (IVDR), art. 10 ust. 8.

[3] U.S. FDA, Quality Management System Regulation (QMSR), materiały dotyczące oceny opartej na ryzyku i wymagań ISO 13485.

Wsparcie dla Twojej firmy

Wypełnij formularz bezpłatnej mapy priorytetów QMS lub poproś o konsultację z ekspertem, aby omówić swój projekt.

Wszystkie artykuły Med-Tech.