W jednym z prowadzonych przez nas projektów dla klienta z sektora ochrony zdrowia kluczowym wyzwaniem nie było samo przygotowanie opisu przedmiotu zamówienia, lecz prawidłowe podejście do zasady DNSH (Do No Significant Harm), czyli zasady „nie czyń poważnych szkód”.
Był to przypadek bardzo charakterystyczny dla obecnych postępowań współfinansowanych ze środków publicznych i unijnych. Obowiązek poszanowania DNSH został w dokumentacji postępowania wskazany wprost, jednak sam klient nie dysponował na początku jasną odpowiedzią na pytanie, jak tę zasadę realnie zastosować, jak ją opisać oraz jak przygotować się do jej późniejszego wykazania na etapie realizacji zamówienia i odbioru.
W praktyce właśnie na tym etapie pojawia się najwięcej trudności. Zasada DNSH bardzo często funkcjonuje w świadomości zamawiających i wykonawców jako obowiązek formalny, natomiast znacznie rzadziej jest rozumiana jako wymóg, który trzeba przełożyć na spójne uzasadnienie prawne, logiczne i dokumentacyjne. Tymczasem samo ogólne powołanie się na ochronę środowiska nie jest wystarczające. Konieczne jest wykazanie, że sposób realizacji przedsięwzięcia nie powoduje istotnych szkód względem celów środowiskowych właściwych dla danej inwestycji.
Nasza rola w tym projekcie polegała właśnie na tym, aby uporządkować klientowi sposób myślenia o DNSH. Nie przygotowywaliśmy opisu przedmiotu zamówienia jako takiego, lecz przeprowadziliśmy analizę obowiązku z perspektywy prawnej i praktycznej: wyjaśniliśmy, czym ta zasada rzeczywiście jest, jakie ma znaczenie w konkretnym postępowaniu, jakich błędów interpretacyjnych należy unikać oraz w jaki sposób należy zbudować dokumentację, aby obowiązek ten nie pozostał wyłącznie deklaracją.
Najważniejsze było odejście od schematu, w którym DNSH traktuje się jako krótki, ogólny fragment o charakterze wizerunkowym. W takich sprawach problem nie polega bowiem na napisaniu kilku „bezpiecznych” zdań o zrównoważonym rozwoju, lecz na takim sformułowaniu dokumentacji i takiej organizacji toku postępowania, aby w razie potrzeby możliwe było wykazanie, że klient rzeczywiście rozpoznał obowiązek, właściwie go zinterpretował i uwzględnił go na poziomie realizacyjnym.
W tym konkretnym przypadku pracowaliśmy z klientem, który początkowo nie miał pewności:
- jak rozumieć DNSH w odniesieniu do planowanego zamówienia,
- czy obowiązek ten należy traktować wyłącznie deklaratywnie, czy również dowodowo,
- jakie elementy dokumentacji powinny zostać odpowiednio ukształtowane,
- oraz jak uniknąć sytuacji, w której zapis będzie formalnie obecny, ale faktycznie niewystarczający.
Nasze wsparcie polegało więc na przełożeniu języka regulacyjnego na język praktyki postępowania. Pomogliśmy klientowi zrozumieć, że DNSH nie funkcjonuje w oderwaniu od przedmiotu zamówienia, lecz musi być rozpatrywana przez pryzmat konkretnego zakresu rzeczowego, modelu realizacji, przewidywanych skutków oraz późniejszych obowiązków dokumentacyjnych. Innymi słowy: nie wystarczy wskazać, że dana inwestycja „respektuje zasadę DNSH”. Trzeba jeszcze wiedzieć, dlaczego, w jaki sposób i na jakiej podstawie będzie to wykazywane.
Efektem naszej pracy było stworzenie dla klienta prawidłowej, uporządkowanej koncepcji dokumentacyjnej, która pozwoliła osadzić obowiązek DNSH we właściwych ramach. Klient uzyskał nie tylko same zapisy, lecz przede wszystkim zrozumienie mechanizmu: co ma znaczenie z punktu widzenia zgodności, jakie argumenty są relewantne, jakie dokumenty będą potrzebne, gdzie przebiega granica pomiędzy dopuszczalnym uproszczeniem a ryzykiem zbyt powierzchownego potraktowania obowiązku.
W tym projekcie szczególnie istotne było to, że obowiązek DNSH został rozpisany na kilku poziomach dokumentacji. Już na etapie postępowania wykonawcy mieli złożyć oświadczenie o poszanowaniu zasad horyzontalnych, obejmujące nie tylko samą zasadę „nie czyń poważnych szkód”, ale również zasadę równości szans i niedyskryminacji, zasadę równości kobiet i mężczyzn, zasadę zrównoważonego rozwoju, a także obowiązek respektowania Karty Praw Podstawowych Unii Europejskiej i Konwencji ONZ o prawach osób z niepełnosprawnościami. To pokazuje, że DNSH nie zostało tu potraktowane jako luźna wzmianka, lecz jako element szerszej architektury zgodności.
Równocześnie dokumentacja postępowania przewidywała, że samo złożenie oświadczenia nie kończy sprawy. Wykonawca miał bowiem zrealizować zamówienie w sposób nienaruszający zasady DNSH, a przy odbiorze końcowym przedłożyć Raport DNSH wraz z kompletem dowodów i protokołów potwierdzających zgodność. Dopuszczono przy tym dowody równoważne, o ile jednoznacznie potwierdzają spełnienie tej zasady. To był bardzo istotny punkt, ponieważ właśnie tutaj najlepiej widać, że DNSH zostało powiązane nie tylko z fazą ofertową, ale również z wykonaniem umowy i odbiorem końcowym.
Nasza praca polegała więc również na tym, aby pokazać klientowi, jak należy czytać te zapisy razem, a nie osobno. Oświadczenie wykonawcy, postanowienia SWZ, zapisy umowne i raport składany na końcu nie były odrębnymi dokumentami, lecz elementami jednego mechanizmu. Klient potrzebował nie tylko „sformułowania”, ale także logiki, która pozwalała ten mechanizm spiąć.
Bardzo ważne było także prawidłowe odczytanie tych elementów opisu przedmiotu zamówienia, które mogły stanowić materialną podstawę dla uzasadnienia zgodności z DNSH. Nie przygotowywaliśmy OPZ, ale pomagaliśmy klientowi zrozumieć, które rozwiązania już opisane w dokumentacji mogą zostać właściwie wykorzystane jako argumenty i dowody, a które nie powinny być nadmiernie eksponowane.
Przykładem była część dotycząca digitalizacji dokumentacji medycznej. Dokumentacja przewidywała dostawę i wdrożenie systemu służącego do automatycznej digitalizacji dokumentacji, obejmującego m.in. ekrany do podpisu, tablety mobilne, czytniki e-dowodu, skaner, oprogramowanie do podpisów cyfrowych, integrację z systemem HIS oraz przygotowanie dokumentacji formularzowej. Z prawnego punktu widzenia pozwalało to budować argumentację, że przedsięwzięcie wspiera ograniczanie papierowego obiegu dokumentów, porządkowanie procesów oraz zmniejszanie potrzeby dalszego funkcjonowania dokumentacji w tradycyjnej postaci. Nie był to więc argument abstrakcyjny, ale wynikający z samej konstrukcji zamówienia.
Innym przykładem była część dotycząca rozbudowy istniejących rozwiązań informatycznych, w której przewidziano rozbudowę funkcjonującego już środowiska ochrony endpointów, a nie tworzenie całkowicie nowego, oderwanego systemu. Tego rodzaju model można było odczytywać jako rozwiązanie bardziej racjonalne z perspektywy wykorzystania istniejących zasobów i ograniczania zbędnej wymiany infrastruktury. Równie ważne było to, że OPZ przewidywał dokumentację powdrożeniową obejmującą architekturę, polityki, procedury, integracje, raportowanie i plan utrzymania. To z kolei miało znaczenie nie tyle „ekologiczne” w warstwie deklaratywnej, ile porządkujące i dowodowe — wzmacniało możliwość wykazania, że realizacja zamówienia odbywa się według z góry określonych, kontrolowalnych zasad.
Podobnie było w części dotyczącej systemu RIS/PACS, gdzie dokumentacja przewidywała archiwizację danych DICOM w zewnętrznym Data Center, przechowywanie kopii w odrębnych lokalizacjach, określone certyfikacje dla centrów danych oraz model chmurowy/SaaS dla eksploatacji systemu. Tego rodzaju rozwiązania nie mogły oczywiście być prezentowane w sposób uproszczony, ale dawały podstawę do zbudowania uporządkowanej argumentacji, że klient nie powinien traktować DNSH wyłącznie przez pryzmat sprzętu „na miejscu”, lecz także przez pryzmat modelu przechowywania danych, organizacji infrastruktury oraz racjonalności przyjętego rozwiązania.
Szczególne znaczenie miał dla nas również wzór raportu DNSH, który miał zostać przedłożony przy odbiorze końcowym. To właśnie ten dokument pokazywał klientowi, że zgodność nie będzie oceniana ogólnikowo. Jednocześnie miał on jeszcze jedną istotną funkcję: porządkował sytuację po stronie wykonawców i ograniczał stan niepewności co do tego, czego zamawiający będzie oczekiwał na etapie odbioru końcowego. Dzięki temu wymagania dotyczące DNSH nie pozostawały wyłącznie na poziomie ogólnej deklaracji, lecz były od początku osadzone w konkretnym modelu dokumentowania zgodności. Z treści wzoru wynikało, że raport ma mieć charakter uporządkowany, odnosić się do poszczególnych celów środowiskowych i zawierać nie tylko odpowiedzi, ale także uzasadnienia oraz załączniki. Wzór przewidywał możliwość dołączania takich dokumentów jak deklaracje zgodności CE, specyfikacje techniczne, deklaracje producenta dotyczące REACH lub RoHS, certyfikaty środowiskowe czy inne dokumenty wykorzystywane przez wykonawcę dla wykazania zgodności. Raport kończył się formalnym oświadczeniem o zgodności informacji ze stanem faktycznym oraz gotowości przedłożenia dodatkowych dokumentów na żądanie zamawiającego. To w praktyce oznaczało, że już na etapie porządkowania dokumentacji trzeba myśleć nie tylko o samym opisie, ale także o przyszłym materiale dowodowym.
Dla klienta było to jedno z najważniejszych odkryć w całym procesie. Początkowo DNSH było postrzegane bardziej jako obowiązek „do opisania”. Po przeprowadzeniu analizy stało się jasne, że w rzeczywistości jest to obowiązek do wykazania. I właśnie tutaj pojawiła się realna wartość naszej pracy: pomogliśmy klientowi przejść od intuicyjnego, nieuporządkowanego podejścia do konstrukcji, w której każda teza o zgodności mogła zostać powiązana z konkretnym elementem dokumentacji i potencjalnym dowodem.
Znaczenie miały również same postanowienia umowne. Projekt umowy przewidywał, że wykonawca realizuje zamówienie z poszanowaniem zasad horyzontalnych, w tym DNSH, a także że dokumentacja potwierdzająca zgodność ma być przechowywana i udostępniana na żądanie zamawiającego lub podmiotów kontrolujących. Dodatkowo przewidziano obowiązek przedstawienia rozwiązań zamiennych w przypadku stwierdzenia niezgodności. To jeszcze wyraźniej pokazywało, że DNSH nie może zostać potraktowane jako element jednorazowy, lecz jako obowiązek towarzyszący całemu cyklowi realizacji umowy.
Warto dodać, że ten wniosek nie dotyczy wyłącznie postępowań na dostawy systemów czy rozwiązań informatycznych. Ma on charakter znacznie szerszy. W naszej ocenie prawidłowe formułowanie zasady DNSH zawsze wymaga współdziałania dwóch obszarów: prawnego i merytorycznego. W jednych postępowaniach punktem odniesienia będzie dokumentacja techniczna, w innych program funkcjonalno-użytkowy, a w jeszcze innych dokumentacja projektowa, założenia eksploatacyjne lub model realizacji inwestycji. W przypadku zamówień budowlanych oznacza to z reguły konieczność ścisłej współpracy z autorami dokumentacji projektowej albo PFU, ponieważ ocena zgodności z DNSH nie może być prowadzona w oderwaniu od przyjętych rozwiązań materiałowych, technologicznych, funkcjonalnych czy organizacyjnych.
Z tej perspektywy zasady DNSH nie da się skutecznie opisać w sposób abstrakcyjny ani uniwersalny. Nie da się jej oddzielić od przedmiotu zamówienia, tak jak nie da się stworzyć jednego, formalnego zestawu kilku zdań, który spełniałby jej cele w każdym postępowaniu. Każdorazowo konieczne jest bowiem ustalenie, jakiego rodzaju przedsięwzięcia dotyczy zamówienie, jakie skutki może ono wywoływać, jakie rozwiązania przewidziano w dokumentacji i w jaki sposób te rozwiązania mogą zostać ocenione oraz wykazane z punktu widzenia DNSH. Dopiero na takim gruncie możliwe jest zbudowanie dokumentacji, która jest nie tylko formalnie poprawna, ale również rzeczywiście odpowiada charakterowi danego zamówienia.
To właśnie dlatego w sprawach tego rodzaju nie wystarcza ani sama wiedza prawna, ani sama znajomość warstwy technicznej czy projektowej. Potrzebne jest ich połączenie. Dopiero współpraca tych dwóch perspektyw pozwala opracować rozwiązanie, które z jednej strony pozostaje zgodne z wymaganiami dokumentacyjnymi i regulacyjnymi, a z drugiej – jest zakorzenione w realnym przedmiocie zamówienia, a więc możliwe do obrony na etapie realizacji, odbioru i ewentualnej kontroli.
Z perspektywy naszej praktyki ten case dobrze pokazuje, że największą wartością doradztwa nie zawsze jest napisanie dokumentu od początku. Bardzo często jest nią coś ważniejszego: pomoc klientowi w zrozumieniu obowiązku, którego sam nie potrafił jeszcze przełożyć na działanie i dokumentację. Tak było również tutaj. Naszym zadaniem nie było stworzenie OPZ, lecz przeprowadzenie klienta przez wymóg, który istniał już w dokumentacji, ale początkowo nie był dla niego „operacyjny”.
Efektem było stworzenie dokumentacji prawidłowej — nie dlatego, że została rozbudowana o wiele dodatkowych sformułowań, ale dlatego, że została uporządkowana, osadzona we właściwym kontekście i oparta na logicznym związku pomiędzy obowiązkiem, uzasadnieniem i dowodem.
To właśnie w tym sensie był to projekt ważny. Nie „opisaliśmy DNSH”. My pomogliśmy klientowi zrozumieć, jak tę zasadę rzeczywiście stosować, jak ją bezpiecznie osadzić w dokumentacji i jak przygotować się do jej wykazania wtedy, gdy przestaje być hasłem, a staje się realnym obowiązkiem kontraktowym i odbiorowym.
