Zakres integracji BSL-3/4: co inwestorzy muszą określić przed rozpoczęciem projektowania

Projekt klasy BSL-3/4 nie kończy się niepowodzeniem na etapie uruchomienia z powodu niewystarczającej wydajności sprzętu; proces ten zatrzymuje się już wcześniej, gdy prace projektowe toczą się w zakresie integracji, który nigdy nie został w pełni zamknięty. Właściciele, którzy zakładają, że sama klasyfikacja BSL określa, jakie funkcje musi spełniać obiekt i sprzęt, często odkrywają na późnym etapie projektowania lub podczas testów integracyjnych, że nikt nie został wyznaczony do obsługi przegrody ciśnieniowej, ścieżki transferu lub interfejsu sterowania. Określenie zakresu integracji przed zamrożeniem projektu jest decyzją odrębną od wyboru sprzętu i należy do właściciela oraz zespołu projektowego, zanim będzie można właściwie ocenić oferty dostawców.

Zakres prac zaczyna się od określenia planowanych prac i oceny ryzyka

Punktem wyjścia dla określenia zakresu integracji nie jest oznaczenie poziomu bezpieczeństwa biologicznego, lecz zadania, które laboratorium ma realizować. Oznaczenie BSL-3 lub BSL-4 określa kategorię bezpieczeństwa biologicznego; nie opisuje ono konkretnych patogenów, z którymi się pracuje, wykonywanych procedur, przetwarzanych objętości ani sprzętu, który musi współpracować z pomieszczeniem w celu bezpiecznego prowadzenia tych prac. Dwa laboratoria o tym samym oznaczeniu mogą wymagać istotnie różnych zakresów integracji, ponieważ planowane prace się różnią, a traktowanie oznaczenia jako kompletnego zestawu wymagań pomija etap, który faktycznie określa, co należy zbudować.

Właśnie dlatego ocena ryzyka stanowi punkt wyjścia do określenia zakresu działań, a nie jest jedynie późniejszym etapem zapewniania zgodności. To Podręcznik bezpieczeństwa biologicznego w laboratorium WHO, wydanie 4, określa ocenę ryzyka jako podstawę proporcjonalnych środków kontroli bezpieczeństwa biologicznego, co oznacza, że to wyniki tej oceny — a nie sama klasyfikacja poziomu bezpieczeństwa — powinny stanowić podstawę decyzji dotyczących kaskad ciśnienia, urządzeń transferowych, punktów dekontaminacji oraz punktów monitorowania. W przypadku gdy ocena ryzyka wskazuje konkretne ścieżki przenoszenia, odprowadzania odpadów lub narażenia związane z planowanymi pracami, ścieżki te stają się elementami zakresu, które projekt musi wyraźnie uwzględniać, a nie zakładać, że wynikają one automatycznie z klasyfikacji BSL-3 lub BSL-4.

Praktyczną konsekwencją dla właściciela jest ustalenie kolejności działań. Jeśli planowane prace laboratoryjne i ich ocena ryzyka nie zostaną sfinalizowane lub zostaną sfinalizowane na poziomie zbyt ogólnym, by zidentyfikować konkretne ścieżki i punkty styku, każdy zakres integracji opracowany wyłącznie na podstawie oznaczenia BSL będzie zawierał luki, które ujawnią się później jako nieplanowane zmiany projektowe. Z drugiej strony, jeśli ocena ryzyka jest szczegółowa w odniesieniu do procedur, czynników i trybów awarii, właściciel może ją wykorzystać do sprawdzenia, czy proponowany zakres integracji jest rzeczywiście kompletny, zamiast polegać na kategorii zabezpieczenia jako wskaźniku kompletności. Wytyczne na poziomie WHO stanowią ogólne poparcie dla tej logiki, ale nie zastępują oceny ryzyka specyficznej dla danego obiektu ani obowiązujących krajowych przepisów dotyczących bezpieczeństwa biologicznego, które pozostają podstawą prawną, którą właściciel musi stosować bezpośrednio.

Należy wyznaczyć granice stref izolacji w poszczególnych pomieszczeniach i na sprzęcie

Izolacja nie jest cechą charakterystyczną pojedynczego pomieszczenia; jest to ciągła granica, którą należy wytyczyć przez każde pomieszczenie, korytarz i każdy element wyposażenia stykający się z przestrzenią podlegającą kontroli. Kaskady ciśnienia, trasy przemieszczania personelu i materiałów, ścieżki odprowadzania spalin, ścieżki odprowadzania odpadów płynnych oraz interfejsy sterowania – wszystkie one przekraczają granice fizyczne i sprzętowe, a każdy punkt przecięcia stanowi miejsce, w którym granica może pozostać nieokreślona, jeśli nikt jej celowo nie wyznaczy.

Określenie granic ma znaczenie, ponieważ skuteczność izolacji różni się w zależności od tego, czy granica jest wyznaczona względem urządzeń, czy względem obwiedni pomieszczeń. Na przykład granica ciśnieniowa wyznaczona wyłącznie na poziomie pomieszczenia może nie uwzględniać wymaganych relacji ciśnieniowych w obrębie Laboratorium z modułem BSL-3/BSL-4‘wewnętrznych przejściach lub w obrębie urządzeń, takich jak przepustnice izolacyjne, które są umieszczone na trasie układu wywiewnego lub kanałów wentylacyjnych i mają za zadanie utrzymać kierunkowy przepływ powietrza zarówno w warunkach normalnych, jak i awaryjnych. Tam, gdzie granica jest wyznaczana wyłącznie na poziomie architektonicznym, punkty kontrolne na poziomie urządzeń narażone są na ryzyko potraktowania ich jako problemu kogoś innego; tam, gdzie granica jest wyznaczana wyłącznie na poziomie urządzeń, wkład przegród pomieszczenia w tę samą granicę narażony jest na ryzyko, że zostanie przyjęty za pewnik, zamiast zostać zweryfikowany.

Ta sama zasada dotyczy tras transferu i ścieżek odprowadzania odpadów. Trasa transferu przez śluzę, interfejs transferowy VHP lub ścieżka odprowadzania odpadów płynnych do system odkażania ścieków jest tak bezpieczny, jak jego najsłabsze ogniwo, a tym ogniwem jest często punkt styku zakresu obiektu z zakresem wyposażenia. Ten CDC/NIH Biosafety in Microbiological and Biomedical Laboratories (BMBL), wydanie 6., odróżnia systemy kontroli dostępu i przepływu powietrza dla poziomu BSL-3 od rozwiązań wentylacyjnych, wejściowych i dekontaminacyjnych w obiektach z kombinezonami dla poziomu BSL-4, co przypomina, że wymagane zachowanie granicy izolacji zmienia się w zależności od poziomu izolacji i rodzaju obiektu — oraz że granica prawidłowo odwzorowana dla jednej konfiguracji nie może być bez zmian przeniesiona na inną. BMBL stanowi wytyczne doradcze, które należy stosować w oparciu o własną ocenę ryzyka projektu oraz lokalne wymogi regulacyjne, a nie jako uniwersalną wartość zadaną ciśnienia.

Właściciel musi zdecydować, czy wszystkie granice ciśnieniowe, trasy przesyłu, ścieżki odprowadzania, ścieżki odprowadzania odpadów płynnych oraz interfejsy sterowania zostały narysowane w obu pomieszczeniach i na wszystkich urządzeniach, tak aby żaden odcinek nie pozostał nieokreślony. Nieznakowany odcinek nie jest drobnym przeoczeniem; jest to granica o nieokreślonym zachowaniu, której projekt nie może zamknąć, dopóki ktoś jej nie zdefiniuje.

Funkcje pomocnicze i elementy sterujące wymagają wyznaczenia właścicieli interfejsów

Określenie granicy pozwala ustalić, gdzie ona przebiega; nie określa jednak, kto jest odpowiedzialny za jej projekt, wykonanie lub weryfikację. Każdy punkt interfejsu — przyłącze mediów, sygnał sterujący, punkt monitorowania, stan alarmowy — wymaga wyznaczenia właściciela, zanim będzie można go uznać za zamknięty, ponieważ interfejs bez właściciela jest zazwyczaj traktowany przez jedną stronę jako ukończony, a przez drugą jako oczekujący na realizację.

Ma to największe znaczenie tam, gdzie systemy sterowania przechodzą z poziomu zarządzania budynkiem na poziom sterowania urządzeniami, lub tam, gdzie media, takie jak energia elektryczna, sprężone powietrze czy nośnik do odkażania, przechodzą z infrastruktury obiektu do konkretnego urządzenia. Jeśli nikt nie jest odpowiedzialny za interfejs, specyfikacja po jednej stronie granicy może zostać opracowana bez odniesienia do rzeczywistych wymagań po drugiej stronie — na przykład wartość zadana sterowania zdefiniowana przez system budynku bez znajomości rzeczywistych charakterystyk reakcji urządzenia lub zasilanie zaprojektowane na podstawie projektu obiektu bez potwierdzenia rzeczywistego zapotrzebowania urządzenia w warunkach awarii. Ryzyko nie polega na tym, że interfejs jest nieprawidłowy; polega ono na tym, że nikt nie jest w stanie stwierdzić, czy jest on prawidłowy, ponieważ żadna ze stron nie była odpowiedzialna za uzgodnienie obu stron.

Wyznaczenie osoby odpowiedzialnej zmienia charakter nierozstrzygniętej kwestii z wspólnego założenia na ściśle monitorowaną odpowiedzialność. Gdy osobą odpowiedzialną jest zespół projektujący obiekt, rolą dostawcy sprzętu jest dostarczenie danych dotyczących interfejsów na tyle wcześnie, aby zespół projektujący mógł z nich skorzystać. Gdy osobą odpowiedzialną jest dostawca sprzętu, rolą zespołu projektującego obiekt jest potwierdzenie warunków zasilania lub sterowania, od których zależy działanie sprzętu. Każde z tych rozwiązań może się sprawdzić; nie sprawdza się natomiast pozostawianie kwestii odpowiedzialności nierozstrzygniętej, podczas gdy obie strony działają w oparciu o własne założenia dotyczące drugiej strony.

Zadaniem właściciela na tym etapie nie jest osobiste rozwiązywanie wszystkich kwestii związanych z interfejsami, lecz upewnienie się, że każdy zdefiniowany interfejs ma dokładnie jedną wyznaczoną stronę odpowiedzialną za jego zamknięcie oraz że informacje, których każda ze stron potrzebuje od drugiej, zostały określone jako konkretny dokument lub wymiana danych, a nie pozostawione nieformalnej koordynacji.

Zadania dostawców należy oddzielić od obowiązków zakładu

Po przyporządkowaniu interfejsów i ustaleniu ich właścicieli kolejną decyzją jest określenie, która strona jest odpowiedzialna za co. Jest to kwestia odrębna od kwestii własności: właściciel interfejsu określa zamierzenia projektowe interfejsu, natomiast podział odpowiedzialności decyduje o tym, kto tworzy, dostarcza i dokumentuje każdą z jego stron. Usługi komunalne, prace budowlane oraz elementy dostarczane przez dostawców sprzętu to trzy odrębne kategorie zakresu, a projekt, w którym nie zostały one wyraźnie rozdzielone, naraża się na ryzyko ocena wniosku gdy zarówno dostawca, jak i właściciel zakładają, że to druga strona pokrywa koszty danej pozycji.

Media obiektowe — energia elektryczna, woda, gazy sprężone, systemy wentylacyjne na poziomie budynku i podobne usługi — zazwyczaj pozostają w gestii obiektu do określonego punktu przyłączeniowego, a zakres dostawy dostawcy sprzętu rozpoczyna się właśnie w tym punkcie. Prace budowlane, w tym elementy konstrukcyjne, architektoniczne i ogólnobudowlane, zazwyczaj całkowicie wykraczają poza zakres dostawy dostawcy sprzętu, nawet jeśli te prace mają bezpośredni wpływ na sposób integracji sprzętu z przestrzenią. Zakres dostawy dostawcy sprzętu, po uwzględnieniu go w określonym pakiecie projektowym, obejmuje własną dokumentację oraz wymagania dotyczące danych interfejsowych, które strona obiektu musi uwzględnić w celu opracowania własnego projektu wokół tego sprzętu.

Powodem, dla którego podział ten musi być jasno określony, a nie tylko domniemany, jest fakt, że zarówno luki, jak i nakładanie się zakresów wiążą się z kosztami w postaci czasu poświęconego na koordynację, a każda z tych sytuacji może sprawić, że za dane wymaganie w praktyce nikt nie będzie odpowiedzialny. Jeśli granica nie jest jasna, element funkcji lub interfejsu może znaleźć się w obszarze, w którym każda ze stron zakłada, że to druga strona jest za niego odpowiedzialna, co ujawnia się dopiero wtedy, gdy element ten jest potrzebny, a nie jest dostępny. Jeśli podział odpowiedzialności zostanie ustalony na wczesnym etapie, można to zweryfikować, zanim stanie się to problemem na placu budowy. Jest to rodzaj informacji dotyczących zakresu, specyficznych dla danego projektu, które są uwzględniane podczas przeglądu konfiguracji lub oferty dostawcy: im jaśniejsze są granice i dane dotyczące interfejsów dostarczone przez właściciela, tym dokładniej dostawca może potwierdzić, co wchodzi w skład proponowanego pakietu sprzętowego — na przykład w przypadku laboratorium z modułem BSL-3/BSL-4, klapa izolacyjna w torze odprowadzania spalin lub położenie systemu oczyszczania ścieków względem instalacji technicznych obiektu i konstrukcji budowlanej.

Zanim przystąpi się do projektowania, właściciel musi potwierdzić nie tylko sam podział, ale także dokumenty i dane dotyczące interfejsów, które każda ze stron musi w ramach tego podziału wymienić — specyfikację mediów, którą obiekt musi przekazać dostawcy, oraz dane dotyczące interfejsów, które dostawca musi zwrócić, aby można było sfinalizować projekt obiektu z uwzględnieniem tych informacji.

Wymogi dotyczące dokumentacji muszą obejmować etapy testowania i przekazania

Wymaganie, które zostało zaakceptowane, ale którego ślad nie jest widoczny na etapie projektowania, testowania i przekazania, narażone jest na ryzyko utraty, nawet jeśli nikt nie podejmie decyzji o jego wycofaniu. Określenie zakresu nie jest zakończone w momencie uzgodnienia wymagania; jest ono zakończone dopiero wtedy, gdy wymaganie to pozostaje widoczne wraz z odpowiednimi dowodami na każdym kolejnym etapie projektu.

Mechanizm ten jest prosty: na każdym etapie projektu zabezpieczającego powstaje odrębna dokumentacja, a jeśli dokumentacja ta nie zawiera odniesienia do pierwotnie zaakceptowanego wymagania, nie ma możliwości potwierdzenia, że wymaganie to zostało faktycznie uwzględnione, a nie po cichu pominięte podczas projektowania szczegółowego. Wymaganie zaakceptowane podczas definiowania zakresu musi pojawić się ponownie podczas przeglądu projektu, gdzie dokumentacja projektowa pokazuje, w jaki sposób zostało uwzględnione; ponownie podczas testów zintegrowanych, gdzie wyniki testów pokazują, że zostało ono faktycznie zrealizowane jako część zintegrowanego systemu, a nie tylko założono, że działa, ponieważ poszczególne komponenty przeszły swoje własne testy; oraz ponownie podczas przekazania, gdzie ostateczny pakiet dokumentacji nadal pokazuje powiązanie między pierwotnym wymaganiem a wynikiem testu.

Czynnikiem, który sprawia, że nie jest to już tylko kwestia formalności w dokumentacji, ale realne ryzyko, jest złożoność i czas trwania projektu. W przypadku projektu o niewielkiej liczbie interfejsów i krótkim okresie od etapu projektowania do przekazania nieformalne śledzenie może ujawnić pominięte wymaganie, zanim stanie się to istotne. Natomiast gdy projekt obejmuje wiele interfejsów, kilka stron oraz dłuższy harmonogram, wymaganie bez identyfikowalnego zapisu znacznie łatwiej zaginie między etapami, ponieważ żaden pojedynczy dokument nie zawiera pełnej historii tego, dlaczego zostało zaakceptowane i co je spełniło. W tym miejscu istotne staje się również rozróżnienie między testowaniem na poziomie obiektu a testowaniem na poziomie sprzętu: wymóg powiązany z interfejsem między sprzętem dostawcy a systemami obiektu wymaga dowodów pochodzących konkretnie z testów zintegrowanych, a nie tylko z własnych kontroli dostawcy na poziomie fabrycznym, ponieważ to właśnie zintegrowane zachowanie miało faktycznie potwierdzić ten wymóg.

Dla właściciela chodzi o to, czy dokumentacja projektu faktycznie pozwala ustalić w momencie przekazania, które pierwotne wymagania zostały przetestowane w ramach zintegrowanego systemu, a które nie. Jeśli dokumentacja ta jest niekompletna, brak ten nie stanowi jedynie niedogodności związanej z dokumentacją — jest to otwarta kwestia dotycząca tego, czy dane wymaganie zostało w ogóle spełnione.

Zamrożenie projektu zależy od zamkniętych interfejsów i zarejestrowanych wyłączeń

Zamrożenie projektu to moment, w którym projekt zostaje ostatecznie ustalony w konkretnej konfiguracji, a moment ten powinien zależeć od zamknięcia zakresu prac, a nie od terminów kalendarzowych. Zamrożenie projektu w sytuacji, gdy interfejsy pozostają nieprzypisane, media nie zostały wyodrębnione z elementów wyposażenia, a łańcuchy dowodowe nie zostały zweryfikowane, nie powoduje zniknięcia tych luk; przenosi je jedynie do etapu budowy i uruchomienia, gdzie ich usunięcie jest droższe, a ustalenie ich źródła trudniejsze.

Warunkiem decydującym o gotowości do zamrożenia jest to, czy każdy element wymieniony w definicji zakresu osiągnął stan zamknięty, co oznacza, że ma określone granice, wyznaczonego właściciela oraz — w stosownych przypadkach — dokumentację potwierdzającą jego powiązanie z działaniami projektowymi i testowymi. Element, który nadal pozostaje otwarty, powinien pozostać widoczny jako otwarty, a nie być domyślnie traktowany jako rozwiązany tylko dlatego, że prace projektowe go pominęły. Obejmuje to wyraźne wykluczenia: w przypadku, gdy konkretna ścieżka, interfejs lub zakres odpowiedzialności zostały celowo umieszczone poza bieżącym zakresem projektu, wykluczenie to należy odnotować jako decyzję, a nie pozostawiać do późniejszego wywnioskowania na podstawie braku jakiejkolwiek dokumentacji na ten temat. Niedokumentowane wykluczenie jest po fakcie nie do odróżnienia od przeoczonego wymagania.

Jeśli planowane prace laboratoryjne i ocena ryzyka znajdują odzwierciedlenie w przyjętych wymaganiach, jeśli granice izolacji zostały wyznaczone zarówno w odniesieniu do pomieszczeń, jak i sprzętu, jeśli każde wyznaczone miejsce styku ma wyznaczonego właściciela, jeśli obowiązki obiektu i dostawcy są rozdzielone, a dane dotyczące punktów styku zostały zidentyfikowane, oraz jeśli łańcuch dowodowy od momentu odbioru aż po testy jest nienaruszony, projekt ma uzasadnioną podstawę do zamrożenia projektu. W przypadku gdy którykolwiek z tych elementów pozostaje nieokreślony, decyzja o zamrożeniu projektu powinna traktować tę konkretną kwestię jako otwartą, zamiast opierać się na założeniu, że zostanie ona rozwiązana w trakcie projektowania szczegółowego lub budowy.

Jest to również etap, na którym zakres związany z wyposażeniem — taki jak poszczególne elementy dostawy dla laboratorium modułowego, klapy izolacyjne na trasach wywiewu lub system odkażania ścieków — powinien już być ujęty w ramach określonego podziału obowiązków wraz z zamkniętymi interfejsami, tak aby koordynacja z dostawcami na etapie projektowania szczegółowego lub dostawy polegała na potwierdzeniu wcześniej uzgodnionego zakresu, a nie na jego renegocjowaniu.

Często zadawane pytania

Q: Czy oznaczenie BSL-3 lub BSL-4 wystarcza do określenia zakresu integracji?
A: Nie. Należy wykorzystać przewidziane prace laboratoryjne oraz ocenę ryzyka dostosowaną do konkretnego obiektu, aby przełożyć kontekst zabezpieczeń na wymagania projektowe, a następnie zweryfikować te wymagania pod kątem obowiązujących przepisów krajowych, zamiast traktować klasyfikację BSL jako kompletną specyfikację.

Q: Co powinien przygotować właściciel, aby można było porównać oferty dostawców na tej samej podstawie?
A: Należy przygotować wspólny pakiet zakresu, który określa granice obszarów i tras, oddziela obowiązki obiektu i budynku od zakresu dostaw dostawców, wskazuje osoby odpowiedzialne za punkty styku, wymienia wymagane wymiany informacji oraz rejestruje wyłączenia. Należy poprosić każdego dostawcę o wskazanie, w jaki sposób jego oferta odnosi się do tego pakietu oraz gdzie pozostają otwarte kwestie dotyczące granic.

Q: Jak należy postępować w przypadku interfejsu, który wykracza poza zakres poszczególnych urządzeń i obiektów?
A: Należy wyznaczyć osobę odpowiedzialną za projekt interfejsu oraz określić, co każda ze stron musi dostarczyć i zwrócić. Na przykład w dokumencie tym należy wskazać odpowiednią granicę sieci lub systemu sterowania, dokumenty i dane dotyczące interfejsu wymagane po obu stronach, a także dowody niezbędne do zamknięcia interfejsu.

Q: Czy projekt można zamrozić, gdy niektóre interfejsy integracyjne pozostają nadal nierozwiązane?
A: Należy pozostawić otwarty zakres, którego to dotyczy, dopóki nie zostaną ustalone granice, odpowiedzialność, wymagana wymiana informacji oraz wyłączenia. Zamrożenie nierozwiązanego interfejsu może spowodować ukrycie pominięcia aż do etapu prac na placu budowy, kiedy to trudniej jest zarządzać odpowiedzialnością i zmianami projektowymi.

Q: W jaki sposób właściciele mogą zapobiec zniknięciu zaakceptowanego wymagania w okresie między projektowaniem a przekazaniem obiektu?
A: Należy przypisać wymaganiu granice zakresu i właściciela, a następnie powiązać je z dokumentacją, której oczekuje się podczas przeglądu projektu, testów integracyjnych i przekazania obiektu. Przed kontynuowaniem prac należy potwierdzić, kto sporządzi każdą dokumentację i w jaki sposób zostanie ona powiązana z zaakceptowanym wymaganiem.