Wyrok KIO 2009/22 z 19 sierpnia 2022

1. umarza postępowanie odwoławcze w zakresie zarzutu naruszenia art. 112 ust. 1 i 2 pkt 4 w zw. z art. 116 ust. 1 w zw. z art. 16 pkt 1-3 ustawy Prawo zamówień publicznych (zarzut nr 1);
2. uwzględnia odwołanie w pozostałej części i nakazuje zamawiającemu Uniwersyteckiemu Centrum Klinicznemu z siedzibą w Gdańsku dokonanie zmiany załącznika nr 4 do SWZ Opisu przedmiotu zamówienia w pkt 3 „Wymogi integracyjne” poprzez:
3. 1. dopuszczenie w pkt 3.1. Opisu przedmiotu zamówienia również innych niż CGM API rozwiązań pozwalających na pobieranie danych z użytkowanego przez zamawiającego systemu CliniNET HIS w trybie odczytu; 2.2. wykreślenie pkt 3.2 i 3.3 Opisu przedmiotu zamówienia;
4. kosztami postępowania obciąża zamawiającego Uniwersyteckie Centrum Kliniczne z siedzibą w Gdańsku i:
5. 1. zalicza na poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr (słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez odwołującego tytułem wpisu od odwołania; 3.2. zasądza od zamawiającego Uniwersyteckiego Centrum Klinicznego z siedzibą w Gdańsku na rzecz odwołującego Transition Technologies-Science Spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie kwotę 18 600 zł 00 gr (słownie: osiemnaście tysięcy sześćset złotych zero groszy) stanowiącą koszty postępowania poniesione przez odwołującego z tytułu wpisu od odwołania oraz wynagrodzenia pełnomocnika.

Stosownie do art. 579 ust. 1 i 580 ust. 1 i 2 ustawy z dnia 11 września 2019 r. - Prawo zamówień publicznych (t.j. Dz. U. z 2022 r. poz. 1710) na niniejszy wyrok - w terminie 14 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie.

Przewodniczący

..............................................

Sygn. akt

KIO 2009/22

Uz as adnienie Zamawiający Uniwersyteckie Centrum Kliniczne z siedzibą w Gdańsku (dalej jako „Zamawiający”) prowadzi postępowanie o udzielenie zamówienia publicznego w trybie przetargu nieograniczonego na zaprojektowanie, wdrożenie, świadczenie serwisu gwarancyjnego i nadzoru oraz wsparcia systemu informatycznego dla Multidyscyplinarnego Centrum Wsparcia Badań Klinicznych (MCWBK) - nr ref. 126/PN/2022. Ogłoszenie o zamówieniu zostało opublikowane w Dzienniki Urzędowym Unii Europejskiej z dnia 20 lipca 2022 r. pod numerem 2022/S 138-394736. Do ww. postępowania o udzielenie zamówienia zastosowanie znajdują przepisy ustawy z dnia 11 września 2019 r. - Prawo zamówień publicznych (t.j. Dz. U. z 2022 r. poz. 1710, dalej „ustawa Pzp”). Wartość szacunkowa zamówienia przekracza progi unijne, o których mowa w art. 3 ustawy Pzp.

W dniu 1 sierpnia 2022 r. wykonawca Transition Technologies-Science Spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie (dalej jako „Odwołujący”) wniósł odwołanie wobec treści dokumentów zamówienia, zarzucając Zamawiającemu naruszenie:

1. art. 112 ust. 1 i 2 pkt 4 w zw. z art. 116 ust. 1 w zw. z art. 16 pkt 13 ustawy Pzp poprzez sformułowanie warunku udziału w postępowaniu w zakresie zdolności technicznej i zawodowej w odniesieniu do doświadczenia wykonawcy w sposób ograniczający uczciwą konkurencję i zasadę równego traktowania, jak również w sposób nieproporcjonalny i nadmierny, tj. Zamawiający wymaga, aby wykonawca wykazał się następującym doświadczeniem: „(...) B) wykonał w co najmniej dwóch wdrożeniach integrację z HIS CliniNET, zrealizowaną w oparciu o CGM API” - pkt VIII ppkt 4 lit B SWZ oraz sekcja 111.1 .3) lit. B Ogłoszenia o zamówieniu;
2. art. 99 ust. 1, 2 i 4 w zw. z art. 16 pkt 1-3 ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób nieuwzględniający wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty oraz oszacowanie kosztów realizacji przedmiotu zamówienia, a także w sposób nieadekwatny do przedmiotu zamówienia oraz naruszający uczciwą konkurencję i zasadę równego traktowania wykonawców oraz zasadę proporcjonalności, w zakresie w jakim Zamawiający (w załączniku nr 4 Opis Przedmiotu Zamówienia pkt 3) wymaga, aby:

„3.1. Dane do Systemu muszą być pobierane z użytkowanego przez . Zamawiającego systemu CliniNET HIS poprzez moduł Connector API mechanizm podłączania systemu do HIS UCK (system CliniNET firmy CGM) za pomocą CGM API w trybie odczytu.

1. 2. Wykonawca jest zobowiązany zamówić licencje modułu API . niezbędnego do integracji w firmie CompuGroup Medical Polska sp. z o.o., z siedzibą w Lublinie.
2. 3. Wszelkie dodatkowe koszty związane z rozbudową (dostosowaniem) modułu API niezbędnego do integracji w ramach niniejszego realizacji zamówienia ponosi Wykonawca.
3. 4. Aplikacja musi zostać zintegrowana z Active Directory. Z aplikacji będą mogli korzystać jedynie użytkownicy przypisani do właściwej grupy użytkowników w Active Directory. Dla użytkowników spoza UCK należy przewidzieć system do logowania (zakładanie i walidacja kont użytkowników)".

Odwołujący wniósł o uwzględnienie odwołania i nakazanie Zamawiającemu modyfikacji treści SWZ, Ogłoszenia o zamówieniu i wzoru umowy przez:

1. Wykreślenia lit. B z pkt VIII ppkt 4 SWZ oraz lit. B z sekcji III. 1 .3) Ogłoszenia o zamówieniu lub nadanie im następującego brzmienia: „B) wykonał w co najmniej dwóch wdrożeniach integrację z HIS CliniNET”
2. Modyfikację w załączniku nr 4 Opis Przedmiotu Zamówienia pkt 3 poprzez nadanie mu następującego brzmienia:

„3.1. Dane do Systemu muszą być pobierane z użytkowanego przez Zamawiającego systemu CtiniNET HIS w sposób umożliwiający ich odczyt.

1. 2. Aplikacja musi zostać zintegrowana z Active Directory. Z aplikacji będą mogli korzystać jedynie użytkownicy przypisani do właściwej grupy użytkowników w Active Directory. Dla użytkowników spoza UCK należy przewidzieć system do logowania (zakładanie i walidacja kont użytkowników)".

Uzasadniając zarzut nr 1 Odwołujący wskazał m.in., iż sformułowany przez Zamawiającego warunek udziału w postępowaniu w zakresie zdolności technicznej i zawodowej jest nieproporcjonalny do przedmiotu zamówienia, a przede wszystkim ograniczający uczciwą konkurencję. Zamawiający sformułował warunek w sposób bardzo szczegółowy oraz ograniczający konkurencję, a wybór wykonawcy zdolnego wykonać zamówienie w ramach niniejszego postępowania nie uzasadnia formułowania tego typu wymagań. W interesie Zamawiającego jest, aby konkurencja była jak najszersza przy zachowaniu proporcjonalnego poziomu warunku. Odwołujący wskazał, iż przedmiotem zamówienia jest przede wszystkim zaprojektowanie i wdrożenie systemu informatycznego, które może przeprowadzić kilka podmiotów na rynku, w związku z czym zasadne i konieczne jest takie ukształtowanie wymagań, które nie ograniczy udziału w postępowaniu wykonawcom, którzy z powodzeniem będą w stanie wykonać zamówienie. Sposób sformułowania warunku udziału w postępowaniu oraz opis przedmiotu zamówienia w sposób nieuzasadniony faworyzują Compugroup Medical Polska sp. z o.o. oraz podmioty współpracujące z tym wykonawcę. Zamawiający bezzasadnie wymaga doświadczenia we wdrożeniach integracji z HIS CliniNET, zrealizowanych w oparciu o CGM API. API to zdefiniowany przez producenta sposób wymiany danych (zarówno odczytu jak i zapisu do bazy danych) - w tym przypadku producentem API jest Compugroup Medical (dalej „CGM”).

Jednakże zakres danych do wykorzystania jest na sztywno zdefiniowany przez API (jeżeli zatem API jakiejś informacji nie wystawia to nie będzie możliwe jej pozyskanie bez modyfikacji tego API przez producenta, co oznacza konieczność zaangażowania CGM).

Jednocześnie wydajność takiego API w przypadku zapytań masowych jest dość ograniczona co powoduje obciążenie systemu, większe zużycie energii, dłuższy czas pozyskania danych, ryzyko zatorów na łączach w szpitalu i nieefektywne wykorzystanie zasobów. Powoduje to, iż zamówień polegających na integracji z HIS CliniNET w oparciu o CGM API nie realizuje się zbyt wiele (Odwołujący nie zna żadnego przypadku, który byłby zrealizowany przez inny podmiot niż CGM). Tym samym kwestionowany warunek udziału w postepowaniu w sposób rażący narusza zasadę równego traktowania wykonawców i uczciwej konkurencji.

Odwołujący wskazał ponadto, iż warunek ten nie jest uzasadniony potrzebami Zamawiającego, gdyż OPZ przewiduje jedynie komunikację z systemem HIS CliniNET w formie odczytu danych, a ta funkcjonalność jest możliwa do osiągnięcia także w inny sposób niż za pośrednictwem CGM API. Nie ma zatem uzasadnienia dla kupowania API u producenta. Są inne metody pozyskiwania danych do odczytu, jak np. widoki bazodanowe, które nie dość że są dużo tańsze w utrzymaniu, to nie wymagają współpracy z producentem (który jest jednocześnie konkurentem Odwołującego i sam również może być zainteresowany udziałem w Postępowaniu). Są one również znacznie wydajniejsze oraz pozwalają na uniknięcie problemów, w sytuacji, gdy okaże się, że Zamawiający chciałby dodać jakieś dane do integracji, których nie przewidział na etapie opracowywania OPZ.

Odwołujący zbudował w ten sposób hurtownie danych w największych ośrodkach onkologicznych w kraju i od lat codziennie je aktualizuje. Hurtownie te mają nierzadko w bazach ponad 1 milion pacjentów. Innymi słowy, Odwołujący, pomimo że nie posiada doświadczenia w integracji z HIS CliniNET w oparciu o CGM API, to jest w stanie zrealizować zamówienie w sposób należyty.

Uzasadniając zarzut nr 2 Odwołujący przywołał treść pkt 3 OPZ, podnosząc, że istnieje techniczna możliwość osiągnięcia rezultatu zamierzonego przez Zamawiającego (tj. podłączania systemu do HIS UCK (system CliniNET firmy CGM) w trybie odczytu, ale w inny sposób niż za pomocą CGM API. Dane z bazy CliniNET mogą być bowiem, np. importowane za pomocą precyzyjnych zapytań SQL uszytych na miarę pod konkretne zapotrzebowanie.

W takim przypadku System nie zaciąga danych nadmiarowych, Zamawiający ma wpływ na optymalizację zapytania. Dane będą synchronizowane wg ustalonego harmonogramu.

Podczas bieżącego użytkowania aplikacji nie będzie możliwości modyfikacji bazy CliniNET, a co zatem idzie, nie będzie to generowało żadnego obciążenia dla bazy CliniNET. Systemy działają wówczas niezależnie. Zdaniem Odwołującego nie ma żadnego uzasadnienia dla konieczności użycia CGM API. Konieczność zakupu API od producenta (który jest bezpośrednim konkurentem Odwołującego w tym postępowaniu) powoduje tak naprawdę, iż o tym kto zostanie wybrany nie decyduje Zamawiający a CGM, który będzie mógł w sposób dowolny narzucać swojej konkurencji cenę za zakres, który trzeba będzie mu powierzyć.

Odwołujący wniósł o usunięcie postanowień wymagających zakupu API i dopuszczenia integracji read-only poprzez własny interfejs lub zdefiniowanie, że mają to być widoki bazodanowe. Jednocześnie, Odwołujący nie ma żadnego wpływu na to, żeby zmusić CGM

do współpracy, albowiem CGM nie ma takiego obowiązku i może w ogóle nie reagować na pytania/prośby Odwołującego (tak, jak robił to już przy podobnym postępowaniu u innego Zamawiającego). Odwołujący wskazał, iż we wszystkich poprzednich postępowaniach dotyczących zakupów systemów dla CWBK, postanowienia związane z integracją z obcymi systemami byty bardziej otwarte i dopuszczały możliwość integracji w sposób wybrany przez wykonawcę, czyli np. widoki, narzędzia własne lub wspomniane API, ale jako opcja.

Podkreślił, że obecnie sformułowane wymagania w zakresie sposobu realizacji zamówienia uniemożliwiają złożenie przez Odwołującego oferty na konkurencyjnych warunkach.

Zamawiający złożył pisemną odpowiedź na odwołanie, w której wskazał, iż uznał za zasadne przychylić się do pierwszego zarzutu, w związku z czym przystał na żądanie Odwołującego i w dniu 10.08.2022r. zmodyfikował treść Specyfikacji Warunków Zamówienia w zakresie warunków udziału w postępowaniu.

Zamawiający nie zgodził się z zarzutem nr 2. Wskazał, iż wymaga wykonania integracji między wytwarzanym systemem MCWBK a systemem HIS Zamawiającego, za pomocą tzw. interfejsu REST API. Wymieniona metoda integracji stała się standardem wymiany danych między systemami różnych producentów, co pokazuje mnogość artykułów w branżowych portalach i została przyjęta w UCK jako domyślna metoda integracji między systemami, które taką integrację oferują. Zamawiający wyjaśnił, iż firma CGM z siedzibą w Lublinie, która jest dostawcą systemu CliniNET HIS (główny system medyczny UCK, najważniejsze źródło danych medycznych z punktu widzenia realizacji przedmiotu zamówienia), stworzyła interfejs REST API jako preferowaną metodę integracji z systemami zewnętrznymi. Zamawiający zwrócił się do CGM o stanowisko odnośnie rekomendowanych metod integracji.

Zamawiający otrzymał odpowiedź, potwierdzającą, że jako domyślną metodę integracji należy stosować REST API. Dla Zamawiającego, wymóg integracji poprzez REST API jest uzasadniony zarówno technicznie jak i ekonomicznie. Zamawiający nie posiada wiedzy o wewnętrznej strukturze bazy danych systemu HIS, który podlega dynamicznym zmianom.

Użycie REST API zapewnia ciągłą i niezakłóconą dostępność danych z HIS do platformy CWBK, bez ponoszenia dodatkowych kosztów modyfikacji interfejsu po każdej aktualizacji któregoś z systemów. W perspektywie długoterminowej jest to rozwiązanie o wiele bardziej korzystne ekonomicznie.

Zamawiający wskazał, iż podany przez Odwołującego przykład wykorzystania innych metod dostępu nie zwolni Odwołującego od pozyskania oferty na tego typu udostępnienie danych od producenta systemu firmy CGM, gdyż UCK ze względów bezpieczeństwa oraz gwarancyjnych nie posiada stosownego dostępu do bazy z możliwością jego udzielania innym podmiotom. Dlatego to rozwiązanie także wymaga współpracy Odwołującego z firmą CGM na zasadach takich jak w przypadku API. Jednocześnie takie rozwiązanie uzależnia Zamawiającego od Odwołującego w zakresie aktualizacji widoków w przypadku aktualizacji systemu CliniNet przez producenta (a takie aktualizacje są częste). Efektem ubocznym aktualizacji będzie możliwość zerwania pozyskiwania danych i każdorazowa konieczność aktualizacji widoków w celu odbudowy zapytań. Jest to niekorzystne ekonomicznie dla Zamawiającego i uzależnia Zamawiającego od współpracy z Odwołującym. Stwarza to także zagrożenia w zakresie obciążenia produkcyjnej bazy danych. Producent systemu CliniNet, poprzez API niweluje te zagrożenia, zapewniając kontrolowany dostęp do danych systemu, co Producent potwierdza w piśmie dotyczącym wykorzystania API. Ustosunkowując się do stwierdzenia Odwołującego, że konieczność pozyskania oferty od firmy CGM na licencję integracyjną API rodzi ryzyko różnicowania cen za licencję różnym potencjalnym Wykonawcom, jak i możliwość wykorzystania swojej uprzywilejowanej pozycji przez samą firmę CGM (koszty integracji są wtedy zerowe) - Zamawiający zwrócił się do firmy CGM o 1. oświadczenie, że firma CGM nie zamierza składać oferty na realizację przedmiotu zamówienia, tzw. „ofertę CGM dla Wykonawców”, czyli gwarancję jednolitej ceny za licencję integracyjną API dla wszystkich potencjalnych Wykonawców, biorących udział w podstępowaniu.

Zamawiający wskazał, iż jest jedynym z największych i najnowocześniejszych szpitali w Polsce. Został utworzony przez Gdański Uniwersytet Medyczny w 1945 roku. Od tego czasu świadczy usługi medyczne, oferując pacjentom kompleksową diagnostykę i leczenie.

Ponadto oddany w 2012 r. do użytku budynek Centrum Medycyny Inwazyjnej (CMI) oraz w 2022r. budynek Centrum Medycyny Nieinwazyjnej (CMN) stanowią jeden z najnowocześniejszych kompleksów medycznych nie tylko w Polsce, lecz także w Europie.

Uniwersyteckie Centrum Kliniczne we współpracy z Gdańskim Uniwersytetem Medycznym zapewnia pacjentom dostęp do najnowocześniejszych technologii, światowej wiedzy medycznej i badań klinicznych. W UCK pracują wybitni specjaliści, którzy do swojej dyspozycji mają nowoczesne zaplecze diagnostyczne i kliniczne. W ofercie szpitala znajduje się pełen zakres usług medycznych: zaawansowana diagnostyka, różnorodne zabiegi chirurgiczne, rehabilitacja, a także opieka paliatywna. Szpital posiada większość specjalności, jakie dostępne są w obszarze świadczeń usług medycznych. Ze względu na wysoką specjalizację, świadczy również szeroki zakres usług pacjentom z pozostałych

części kraju, dla których, w przypadku wielu schorzeń, jest jedynym ośrodkiem referencyjnym. Szpital poza działalnością typowo leczniczą, pełni również funkcję jednostki edukacyjnej oraz badawczej. Poprzez stałą rozbudowę infrastruktury i modernizację wyposażenia, Uniwersyteckie Centrum Kliniczne dokłada wszelkich starań aby usługi świadczone na rzecz pacjentów, były na najwyższym poziomie. Aby tak się stało, niezbędne jest, m. in. aby Zamawiający dysponował najwyższej jakości sprzętem oraz oprogramowaniem zarówno do obsługi urządzeń jak i do prowadzenia badań klinicznych.

Dlatego też, formułując opis przedmiotu zamówienia a także kryteria oceny ofert, miał prawo wymagać, aby zaoferowany przedmiot zamówienia charakteryzował się najwyższą jakością, zadość czynił potrzebom pacjentów, kadry medycznej a także studentów. Zamawiający powołał się na orzecznictwo wskazujące, iż Zamawiający ma prawo opisać swoje potrzeby w taki sposób, aby przedmiot zamówienia spełniał jego wymagania i zaspokajał potrzeby.

Odnosząc się do zarzutu naruszenia zasady naruszenia i ograniczenia konkurencji oraz zasady równego traktowania wykonawców, jak i zarzutu określenia parametrów w sposób nadmierny, bądź określenia ich w sposób utrudniający konkurencję, powodujący uprzywilejowanie jednego wykonawcy, Zamawiający stwierdził, iż z przedmiotowymi zarzutami nie sposób się zgodzić.

Po przeprowadzeniu rozprawy z udziałem Stron postępowania odwoławczego, na podstawie zgromadzonego w sprawie materiału dowodowego, Krajowa Izba Odwoławcza ustaliła i zważyła, co następuje:

Izba ustaliła, iż w ustawowym terminie do postępowania odwoławczego nie zgłosił przystąpienia żaden wykonawca.

Izba stwierdziła, iż nie została wypełniona żadna z przesłanek skutkujących odrzuceniem odwołania w całości na podstawie art. 528 ustawy Pzp.

Zamawiający na posiedzeniu, w odpowiedzi na pytanie Izby, potwierdził, iż uwzględnił odwołanie w zakresie zarzutu nr 1.

Zgodnie z art. 522 ust. 4 ustawy Pzp w przypadku uwzględnienia przez zamawiającego części zarzutów przedstawionych w odwołaniu, Izba może umorzyć postępowanie odwoławcze w części dotyczącej tych zarzutów, pod warunkiem że w postępowaniu odwoławczym po stronie zamawiającego nie przystąpił w terminie żaden wykonawca albo wykonawca, który przystąpił po stronie zamawiającego, nie wniósł sprzeciwu wobec uwzględnienia tych zarzutów. W takim przypadku Izba rozpoznaje pozostałe zarzuty odwołania. Zamawiający wykonuje, powtarza lub unieważnia czynności w postępowaniu o udzielenie zamówienia, zgodnie z żądaniem zawartym w odwołaniu w zakresie uwzględnionych zarzutów.

Biorąc powyższe pod uwagę Izba stwierdziła, iż zachodzi wskazana w art. 522 ust. 4 ustawy Pzp podstawa do umorzenia postępowania odwoławczego w zakresie zarzutu naruszenia art. 112 ust. 1 i 2 pkt 4 w zw. z art. 116 ust. 1 w zw. z art. 16 pkt 13 ustawy Pzp poprzez sformułowanie warunku udziału w postępowaniu w zakresie zdolności technicznej i zawodowej w odniesieniu do doświadczenia wykonawcy w sposób ograniczający uczciwą konkurencję i zasadę równego traktowania, jak również w sposób nieproporcjonalny i nadmierny (zarzut nr 1 odwołania). Postępowanie odwoławcze w zakresie ww. zarzutu zostało zatem umorzone, co znalazło odzwierciedlenie w pkt 1 sentencji orzeczenia.

Zarzut nr 2 odwołania został przez Izbę rozpoznany na rozprawie.

Izba uznała, iż Odwołujący, jako podmiot bezpośrednio zainteresowany złożeniem oferty w przedmiotowym postępowaniu o udzielenie zamówienia, wykazał, iż posiada interes w uzyskaniu zamówienia oraz może ponieść szkodę w wyniku naruszenia przez Zamawiającego przepisów ustawy, czym wypełnił materialnoprawne przesłanki dopuszczalności odwołania, o których mowa w art. 505 ust. 1 ustawy Pzp.

Izba dokonała ustaleń faktycznych w oparciu o dokumentację postępowania o udzielenie zamówienia przekazaną przez Zamawiającego. W szczególności Izba ustaliła, iż przedmiotem zamówienia jest zaprojektowanie, wdrożenie, świadczenie serwisu gwarancyjnego i nadzoru oraz wsparcia systemu informatycznego dla Multidyscyplinarnego Centrum Wsparcia Badań Klinicznych (MCWBK). Szczegółowe warunki wykonania przedmiotu zamówienia zostały określone w załączniku nr 3 do SWZ - Opis przedmiotu zamówienia oraz w załączniku nr 4 do SWZ - Istotne postanowienia umowy. Izba ustaliła, iż zgodnie z numeracją faktycznie nadaną załącznikom do SWZ, Opis przedmiotu zamówienia stanowił załącznik nr 4 do SWZ.

W OPZ w pkt 3 „Wymogi integracyjne” wskazano:

1. 1. Dane do Systemu muszą być pobierane z użytkowanego przez Zamawiającego systemu CliniNET HIS poprzez moduł Connector API - mechanizm podłączania systemu do HIS UCK (system CliniNET firmy CGM) za pomocą CGM API w trybie odczytu.
2. 2. Wykonawca jest zobowiązany zamówić licencje modułu API niezbędnego do integracji w firmie CompuGroup Medical Polska Sp. z o.o., z siedzibą w Lublinie.
3. 3. Wszelkie dodatkowe koszty związane z rozbudową (dostosowaniem) modułu API niezbędnego do integracji w ramach niniejszego realizacji zamówienia ponosi Wykonawca.
4. 4. Aplikacja musi zostać zintegrowana z Active Directory. Z aplikacji będą mogli korzystać jedynie użytkownicy przypisani do właściwej grupy użytkowników w Active Directory. Dla użytkowników spoza UCK należy przewidzieć system do logowania (zakładanie i walidacja kont użytkowników).

Izba dopuściła i przeprowadziła ponadto dowody z dokumentów złożonych przez Strony na posiedzeniu, tj.: - wyciąg ze specyfikacji istotnych warunków zamówienia w postępowaniu prowadzonym

przez Instytut „Pomnik - Centrum Zdrowia Dziecka” na zaprojektowanie, wdrożenie, świadczenie serwisu gwarancyjnego i nadzoru oraz wsparcia systemu do wspomagania procesu Zarządzania Badaniami Klinicznymi (ZP/CZD/0191/20) - dowód nr 1 Odwołującego, - korespondencja z przedstawicielem CompuGroup Medical Polska Sp. z o.o. wraz z ofertą

CGM dotyczącą integracji API systemu HIS na potrzeby ww. postępowania - dowód nr 2 Odwołującego, - wyciąg ze specyfikacji warunków zamówienia na zaprojektowanie, wdrożenie,

świadczenie serwisu gwarancyjnego i nadzoru oraz wsparcia systemu wspomagającego Zarządzanie Badaniami Klinicznymi (SCWBK) w ramach projektu „Centrum Wsparcia Badań Klinicznych Uniwersytetu Medycznego w Łodzi - kompleksowego i systemowego wsparcia realizacji badań klinicznych w modelu usług wspólnych” (ZP/17/2022) - dowód nr 3 Odwołującego, - wyciąg ze specyfikacji warunków zamówienia na dostawę systemu klasy CTMS wraz

z modułem eCRF dla Uniwersyteckiego Szpitala Klinicznego w Białymstoku (26/2021) dowód nr 4 Odwołującego, - wyciąg ze specyfikacji warunków zamówienia na dostawę, instalację i wdrożenie

platformy sprzętowej wraz z systemem do nadzoru nad badaniami klinicznymi dla CWBK.4.WSzKzp SPZOZ we Wrocławiu oraz opracowanie i wdrożenie księgi standardowych procedur operacyjnych (SOP) wraz ze szkoleniem użytkowników i administratorów, świadczeniem usługi serwisu gwarancyjnego, utrzymaniowego oraz opieki powdrożeniowej wraz z nadzorem autorskim przez wskazany okres od oddania systemu - dowód nr 5 Odwołującego, - pismo CompuGroup Medical z dnia 9 sierpnia 2022 r. - dowód nr 1 Zamawiającego,

załączony do odpowiedzi na odwołanie, - wydruk ze strony internetowej - dowód nr 2 Zamawiającego, - oświadczenie CompuGroup Medical z dnia 11 sierpnia 2022 r. - dowód nr 3

Zamawiającego, - oferta cenowa CompuGroup Medical - dowód nr 4 Zamawiającego,

na okoliczności wynikające z ich treści i wskazane przez Strony.

Izba zważyła, co następuje:

Biorąc pod uwagę zgromadzony w sprawie materiał dowodowy, poczynione ustalenia faktyczne oraz orzekając w granicach zarzutów zawartych w odwołaniu, Izba stwierdziła, iż

odwołanie zasługuje na uwzględnienie.

Izba uznała zarzut naruszenia art. 99 ust. 1, 2 i 4 w zw. z art. 16 pkt 1-3 ustawy Pzp za zasadny.

Zgodnie z art. 16 ustawy Pzp Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób: 1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców; 2) przejrzysty; 3) proporcjonalny.

Zgodnie z art. 99 ust. 1 ustawy Pzp przedmiot zamówienia opisuje się w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględniając wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty. Ust. 2 tego przepisu stanowi, że Zamawiający określa w opisie przedmiotu zamówienia wymagane cechy dostaw, usług lub robót budowlanych. Cechy te mogą odnosić się w szczególności do określonego procesu, metody produkcji, realizacji wymaganych dostaw, usług lub robót budowlanych, lub do konkretnego procesu innego etapu ich cyklu życia, nawet jeżeli te czynniki nie są ich istotnym elementem, pod warunkiem że są one związane z przedmiotem zamówienia oraz proporcjonalne do jego wartości i celów. Z kolei w myśl ust. 4 przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję, w szczególności przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli mogłoby to doprowadzić do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów.

Izba nie neguje stanowiska Zamawiającego, iż to Zamawiający jako gospodarz postępowania ma prawo opisać przedmiot zamówienia w taki sposób, który zagwarantuje zaspokojenie jego uzasadnionych potrzeb, adekwatnie do wyznaczonego celu, zachowując jednocześnie obiektywizm i precyzję w formułowaniu tych potrzeb. Naturalnym jest, że dyktowany uzasadnionymi potrzebami Zamawiającego opis przedmiotu zamówienia powodować będzie zawężenie kręgu wykonawców będących w stanie zrealizować zamówienie. Natomiast granicę dozwolonych działań Zamawiającego zakreślają zasady uczciwej konkurencji oraz równego traktowania wykonawców jako nadrzędne zasady systemu zamówień publicznych. Zasady te sprzeciwiają się dokonaniu opisu przedmiotu zamówienia w sposób ograniczający wykonawcom udział w postępowaniu lub prowadzący do uprzywilejowania niektórych wykonawców czy produktów, bez uzasadnienia w obiektywnych potrzebach i interesach zamawiającego.

Izba stwierdziła, iż Zamawiający nałożył na wykonawców w pkt 3 OPZ bezwzględny obowiązek pobierania danych w trybie odczytu z systemu HIS UCK posiadanego przez Zamawiającego (tj. systemu CliniNet) do nowowdrażanego systemu (kupowanego w ramach przedmiotowego zamówienia dla MCWBK - dalej jako „System”) za pomocą narzędzia CGM API. Zamawiający narzucił zatem wykonawcom konkretne narzędzie, z którego mają oni korzystać w procesie integracji systemów - CGM API, będące rozwiązaniem konkretnej firmy - CompuGroup Medical Sp. z o.o. (dalej jako „CGM”), czyli twórcy systemu CliniNet funkcjonującego u Zamawiającego. Zamawiający w pkt 3.2 OPZ nałożył na wykonawców obowiązek zamówienia licencji modułu API od ww. podmiotu, zaś w pkt 3.3 OPZ obciążył dodatkowo wykonawców koniecznością pokrycia wszelkich kosztów związanych z rozbudową (dostosowaniem) modułu API niezbędnego do integracji systemów. Jak wynikało ze stanowisk obu Stron postępowania niezbędna do integracji systemów była odpowiednia parametryzacja modułu API przez producenta tego narzędzia - firmę CGM.

Zamawiający obciążył zatem w pkt 3.3 OPZ wykonawców obowiązkiem poniesienia kosztów związanych z dostosowaniem modułu API przez jego producenta w zakresie niezbędnym do integracji systemów.

Taki sposób opisu przedmiotu zamówienia (a dokładniej jego elementu - wymagań dotyczących integracji systemów), przez wskazanie konkretnego narzędzia (CGM API) charakteryzującego produkty konkretnego producenta (CGM), jest na gruncie art. 99 ust. 4 ustawy Pzp dopuszczalny tylko wtedy, gdy nie wiąże się to z potencjalnym ryzykiem doprowadzenia do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów i jest uzasadnione przedmiotem zamówienia. Warto tu przywołać też art. 99 ust. 5 ustawy Pzp wskazujący na dopuszczalność opisania przedmiotu zamówienia przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeśli nie da się opisać przedmiotu zamówienia w wystarczająco precyzyjny i zrozumiały sposób, ale przy równoczesnym dopuszczeniu możliwości zaoferowania rozwiązań równoważnych.

Izba wskazuje ponadto na wytyczne wynikające z motywu 74 preambuły dyrektywy

Parlamentu Europejskiego i Rady 2014/24/UE z dnia 26 lutego 2014 r. w sprawie zamówień publicznych, uchylającej dyrektywę 2004/18/WE (Dz. Urz. UE.L Nr 94, str. 65), gdzie zwrócono uwagę, iż „specyfikacje techniczne sporządzane przez publicznych nabywców muszą umożliwiać otwarcie zamówień publicznych na konkurencję oraz realizację celów w zakresie zrównoważonego rozwoju. W tym celu należy umożliwić składanie ofert odzwierciedlających różnorodność rozwiązań technicznych, norm i specyfikacji technicznych na rynku, w tym ofert opracowanych na podstawie kryteriów wykonania związanych z cyklem życia procesu produkcji robót budowlanych, dostaw i usług oraz ich zgodności z zasadą zrównoważonego rozwoju. W związku z powyższym specyfikacje techniczne powinny być opracowywane w taki sposób, aby uniknąć sztucznego zawężania konkurencji poprzez wymogi, które faworyzują konkretnego wykonawcę, odzwierciedlając kluczowe cechy dostaw, usług lub robót budowlanych oferowanych zwykle przez tego wykonawcę.

Opracowanie specyfikacji technicznych pod względem wymagań wydajnościowych i funkcjonalnych zasadniczo umożliwia optymalne osiągnięcie tego celu. Wymagania funkcjonalne i odnoszące się do wydajności są również odpowiednim środkiem sprzyjającym innowacji w zamówieniach publicznych i powinny być stosowane jak najszerzej (...).”

Zgodnie z art. 42 ust. 2 ww. dyrektywy klasycznej specyfikacje techniczne mają zapewniać równy dostęp wykonawców do postępowania o udzielenie zamówienia i nie tworzyć nieuzasadnionych przeszkód dla otwarcia zamówienia publicznego na konkurencję. Z kolei w myśl ust. 4 ww. przepisu jeżeli nie uzasadnia tego przedmiot zamówienia, specyfikacje techniczne nie zawierają odniesienia do konkretnej marki lub źródła, ani do szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, ani do znaku handlowego, patentu, typu bądź konkretnego pochodzenia lub produkcji, które to odniesienie mogłoby prowadzić do uprzywilejowania lub wyeliminowania pewnych przedsiębiorstw lub produktów. W wyjątkowych przypadkach dopuszcza się stosowanie takich odniesień, jeżeli niemożliwe jest opisanie przedmiotu zamówienia w wystarczająco precyzyjny i zrozumiały sposób zgodnie z ust. 3. Takim odniesieniom towarzyszą słowa "lub równoważne".

W oparciu o powyższe regulacje stwierdzić należy, że Zamawiający powinien przede wszystkim ukształtować opis przedmiotu zamówienia poprzez określenie wymagań funkcjonalnych i wydajnościowych. Co do zasady nie jest dopuszczalne wskazanie w opisie przedmiotu zamówienia (bezpośrednio lub pośrednio) na konkretny produkt, chyba że: a) uzasadnia to przedmiot zamówienia (art. 99 ust. 4), b) nie jest możliwe opisanie przedmiotu zamówienia w wystarczająco precyzyjny i zrozumiały sposób a takim odniesieniom towarzyszą słowa "lub równoważne" (art. 99 ust. 5). W rozpoznawanej sprawie mamy do czynienia z sytuacją, w której w OPZ wskazano na konkretne rozwiązanie technologiczne - interfejs CGM API, którego producentem jest jeden podmiot (CompuGroup Medical Sp. z o.o.), podczas gdy po pierwsze nie wynika to z braku możliwości precyzyjnego opisania przedmiotu zamówienia w inny sposób, a po drugie powstałe w ten sposób ograniczenie konkurencji nie znajduje uzasadnienia w przedmiocie zamówienia. Takie działanie stoi w sprzeczności z przywołanymi przepisami.

Izba stwierdziła, że Zamawiający kształtując OPZ w wyżej omówiony sposób nie był w stanie w postępowaniu odwoławczym udowodnić, aby zachodziła rzeczywista konieczność pobierania danych do nowowdrażanego systemu z systemu CliniNet za pomocą API CGM.

Jak wynika z oświadczenia producenta CGM z dnia 9 sierpnia 2022 r. złożonego jako dowód w sprawie przez Zamawiającego, integracja systemów trzecich z systemem CGM CliniNet poprzez CGM API jest rekomendowana, co nie oznacza, że jest to rozwiązanie bezwzględnie wymagane, a integracja ta nie może zostać dokonana z użyciem innych metod. Oczywistym przy tym jest, że producent „systemu głównego” funkcjonującego u Zamawiającego (CliniNet) będzie zalecał jego integrację z systemami podmiotów trzecich za pomocą własnego narzędzia, co wiązać się będzie chociażby z koniecznością zakupu licencji u tego podmiotu (oraz w tym przypadku także usługi parametryzacji API). Jak jednak podniósł Odwołujący i czemu Zamawiający nie przeczył, u Zamawiający funkcjonują już inne systemy (w tym wdrażane przez Odwołującego), które nie były integrowane z systemem CliniNet z użyciem CGM API. Okoliczność, że możliwe jest zintegrowanie wdrażanych systemów z systemem CGM CliniNet bez użycia CGM API potwierdza też pośrednio złożony przez Odwołującego jako dowód wyciąg z opisu przedmiotu zamówienia w postępowaniu nr ZP/CZD/0191/20 prowadzonym przez Instytut „Pomnik - Centrum Zdrowia Dziecka” na zaprojektowanie, wdrożenie, świadczenie serwisu gwarancyjnego i nadzoru oraz wsparcia systemu do wspomagania procesu Zarządzania Badaniami Klinicznymi (dowód nr 1 Odwołującego). Do wdrażanego wówczas system SZBaK dane miały być dostarczane m.in. z systemu HIS CGM CliniNet, zamawiający zaś wskazał w OPZ, iż „sposób integracji jest w gestii wykonawcy. Zamawiający udostępni kontakt do dostawcy systemu HIS.”

Wykonawca mógł zatem skorzystać z rozwiązania CGM, ale nie musiał.

Zamawiający nie wykazał również, że po jego stronie istnieją uzasadnione potrzeby, aby nałożyć na wykonawców obowiązek skorzystania z CGM API. Nie kwestionując zawartego w odpowiedzi na odwołanie stanowiska, że Zamawiający formułując opis

przedmiotu zamówienia ma prawo wymagać, aby zaoferowany przedmiot zamówienia charakteryzował się najwyższą jakością, czynił zadość potrzebom pacjentów, kadry medycznej a także studentów, to Zamawiający nie wykazał, że CGM API jest rozwiązaniem lepszym pod względem jakościowym, technologicznym, funkcjonalnym, ekonomicznym czy innym w porównaniu do rozwiązań dostępnych na rynku. Zamawiający przedstawił jako dowód wydruk ze strony internetowej, gdzie opisano czym jest interfejs REST API, co jednak jest irrelewantne dla oceny czy jest to rozwiązanie z perspektywy Zamawiającego lepsze od innych dostępnych na rynku. Dodatkowo wydruk ten dotyczy interfejsu API zgodnego ze specyfikacją REST, Zamawiający jednak nie zdefiniował wymogów w zakresie integracji systemów z powołaniem się na interfejs API REST, czyli określony sposób integracji oprogramowań, lecz na konkretny produkt - interfejs CGM API, czyli API opracowane przez CGM. W zakresie CGM API Zamawiający złożył jedynie oświadczenie CGM z dnia 9 sierpnia 2022 r., w którym rekomendowano użycie API, niemniej jest to oświadczenie podmiotu bezpośrednio zainteresowanego tym, aby skorzystać z oferowanych przez ten podmiot rozwiązań, co czyni jego moc dowodową znikomą. Ponadto pkt 1-5 tego oświadczenia opisują tylko funkcjonalności CGM API, nie ma natomiast dowodu, że inne rozwiązania nie mogą tych funkcjonalności zapewnić. Z kolei twierdzenia dotyczące kosztów integracji czy konieczności modyfikacji interfejsów integracyjnych (pkt 6 i 7) nie zostały niczym poparte ani szerzej wyjaśnione. Zamawiający oparł swoje stanowisko w odpowiedzi na odwołanie na powyższym oświadczeniu CGM, niemniej postawionych tam tez ani nie rozwinął, ani nie wykazał innymi środkami dowodowymi.

Odwołujący z kolei wskazał na inne metody pozyskiwania do Systemu danych do odczytu z systemu CliniNet, z których korzystają duże placówki medyczne w kraju.

Odwołujący złożył także jako dowód wyciągi z postępowań o udzielenie zamówienia, w których jednostki zamawiające (z sektora medycznego) dopuszczały różne sposoby integracji systemów, pozostawiając to do uznania wykonawcy, jak we wspomnianym powyżej postępowaniu, którego dotyczy dowód Odwołującego nr 1 oraz w postępowaniu, którego dotyczył dowód nr 4. W ramach postępowań, których dotyczą dowody Odwołującego nr 3 i 4 wskazywano, że integracja może być realizowana zgodnie ze standardem integracji HL.7.2.3 lub narzędzi własnych wykonawcy przy wykorzystaniu np. użytkownika Read-Only z dostępem do bazy danych. W postepowaniu, którego dotyczy dowód nr 3 wymieniono także API, dodając, że sposób integracji wraz z ewentualnym zapewnieniem API jest w gestii wykonawcy. Na gruncie przedstawionych dowodów można wywieść wniosek, że integracja z systemami HIS może nastąpić z użyciem różnych metod, które co do zasady uznawane są za równoważne. Ponadto dowody te podważają stanowisko Zamawiającego, że używanie interfejsu API jest aktualnie standardem rynkowym. Zamawiający takiej okoliczności nie dowiódł, na rozprawie zaś podnoszono, że API wdrożone jest tylko w dwóch szpitalach i jest wykorzystywane tam gdzie mamy do czynienia z e-usługami, a nie pozyskiwaniem danych tylko do odczytu, jak w przedmiotowym postępowaniu. Oczywiście zgodzić należy się z Zamawiającym, iż to, że interfejs ma być używany tylko do odczytu danych nie dyskwalifikuje API, niemniej bezwzględny wymóg użycia CGM API, w sytuacji gdy dane mają być pobierane tylko do odczytu, może zostać uznany za dyskwalifikujący w sposób nieuzasadniony inne możliwe do zastosowania rozwiązania.

Jakkolwiek skład orzekający zdaje sobie sprawę, że Zamawiający jest dużą jednostką i obsługuję znaczną liczbę badań klinicznych w kraju i nie przeczy, że zasadne jest, aby Zamawiający dysponował najwyższej jakości rozwiązaniami, to jednak Zamawiający powinien był wykazać, że wymaganie zapewnienia dostępu do danych w trybie odczytu za pomocą CGM API jest faktycznie uzasadnione, czego nie dowiódł. Prezentowane przez Zamawiającego podczas rozprawy stanowisko, że API umożliwia ograniczenie dostępu do danych konkretnej grupy pacjentów, co zwiększać ma bezpieczeństwo tych danych (podczas audytu ISO wskazano na zbyt szeroki dostęp do danych pacjentów) nie zmienia oceny Izby.

Po pierwsze powyższe twierdzenie pozostało gołosłowne. Po drugie - co kluczowe Zamawiający nie wskazał, że w przypadku innych sposobów integracji systemów nie jest możliwe zapewnienie ograniczonego dostępu do danych, Odwołujący zaś okoliczności tej przeczył. Po trzecie, zdaniem Izby, jeżeli kwestia ograniczenia dostępu do danych jest dla Zamawiającego tak istotna (czego Izba z góry nie neguje), to Zamawiający jest w stanie zapewnić bezpieczeństwo danych w inny sposób - wprowadzając w tym zakresie odpowiednie postanowienia do opisu przedmiotu zamówienia. W świetle twierdzeń Odwołującego odpowiednie uregulowanie dostępu do danych jest możliwe również przy użyciu innych rozwiązań niż narzędzie API firmy CGM. Zamawiający zamiast zdefiniować ewentualne określone wymagania funkcjonalne dla użytego do integracji narzędzia posłużył się w opisie przedmiotu zamówienia konkretnym produktem, nie mając do tego podstaw i eliminując w sposób nieuzasadniony inne możliwe do zastosowania rozwiązania.

Izba wskazuje, iż wymóg użycia do integracji systemów wyłącznie interfejsu CGM API oznacza dla wykonawców brak możliwości zastosowania jakichkolwiek innych rozwiązań, konieczność zakupienia licencji modułu API od CGM, a także konieczność zakupienia od ww. podmiotu usługi dostosowania (rozbudowy) modułu API w sposób niezbędny do

integracji systemów. Wykonawcy biorący udział w postępowaniu, na gruncie tak sformułowanych postanowień OPZ nie mają możliwości zaoferowania innego niż preferowany przez Zamawiającego interfejsu do integracji systemów, dodatkowo stają się uzależnieni od konkretnego podmiotu - producenta systemu CliniNet funkcjonującego już u Zamawiającego. Bezsporną okolicznością jest zaś, że firma CGM to podmiot bezpośrednio konkurujący na rynku usług będących przedmiotem zamówienia z Odwołującym i innymi wykonawcami mogącymi ubiegać się o to zamówienie. Powyższe już samo w sobie wskazuje na ryzyko uprzywilejowania lub wyeliminowania niektórych wykonawców z uwagi na narzuconą im konieczność współpracy z określonym podmiotem. Wskazuje to także na faktyczne wyeliminowanie możliwości zaoferowania jakichkolwiek innych produktów niż CGM API. Mamy zatem do czynienia z sytuacją ograniczenia uczciwej konkurencji, które nie znajduje uzasadnienia w przedmiocie zamówienia i potrzebach Zamawiającego. Podkreślić przy tym należy, że w art. 99 ust. 4 ustawy Pzp mowa jest o potencjalnej możliwości utrudniania konkurencji, a zatem dla stwierdzenia naruszenia tego przepisu wystarczające jest wykazanie prawdopodobieństwa wystąpienia naruszenia konkurencji, a nie konieczności wystąpienia tego naruszenia.

Powyższej oceny Izby nie zmieniają przedstawione przez Zamawiającego na posiedzeniu dowody w postaci oświadczenia firmy CGM, iż nie będzie brała udziału w przedmiotowym postępowaniu oraz oferty CGM mającej gwarantować jednolite ceny dla wszystkich wykonawców za dostawę licencji CGM API i parametryzację API. Po pierwsze na moment zamknięcia rozprawy dokumenty te nie stanowiły dokumentów zamówienia załączników do SWZ, podobnie jak dokumentacja CGM API. Nie zostały one udostępnione zainteresowanym wykonawcom, zaś sam zamiar ich opublikowania komunikowany przez Zamawiającego na rozprawie nie konwaliduje nieprawidłowego opisu przedmiotu zamówienia stwierdzonego w oparciu o treść postanowień SWZ ustaloną w toku postępowania. Zgodnie zaś z art. 552 ust. 1 ustawy Pzp wydając wyrok, Izba bierze za podstawę stan rzeczy ustalony w toku postępowania odwoławczego. Nie mogą zatem stanowić podstawy rozstrzygnięcia hipotetyczne działania przyszłe, których zamiar dokonania sygnalizuje Zamawiający. Po drugie, dokumenty te zostały zakwestionowane przez Odwołującego, który podważał zarówno zakres przedmiotowy licencji, jak i liczbę osobodni niezbędnych do dostosowania API do celów integracji przyjętą w ofercie CGM.

Izba zwróciła zaś uwagę, że z zawartych w tej ofercie warunków realizacji wynika, iż w przypadku konieczności wykonania dodatkowych prac niż wskazane w ofercie, zostaną one zrealizowane w oparciu o dodatkowo płatne zamówienie. Na gruncie ustalonej przez Izbę treści opisu przedmiotu zamówienia wykonawcy są obciążani pełnym ryzykiem poniesienia kosztów związanych z narzuconym im przez Zamawiającego obowiązkiem współpracy z ww. podmiotem, podczas gdy dobór podmiotów współpracujących, jak i kalkulacja ceny ofertowej powinny być co do zasady pozostawione w gestii wykonawców, a nie narzucone przez Zamawiającego. Zamawiający doprowadził do sytuacji, w której wykonawcy częściowo pozbawieni zostali swobody w zakresie kalkulacji ceny ofertowej, a także w zakresie doboru podmiotów, z którymi mogliby współpracować przy realizacji umowy. Tak daleka ingerencja Zamawiającego w uprawnienie wykonawców do kształtowania treści oferty i jej ceny, ale i doboru ewentualnych podmiotów współpracujących, nie powinna być co do zasady uznana za dopuszczalną, tym bardziej, że w przedmiotowej sprawie brak jest uzasadnionych podstaw do takiego działania.

Reasumując, Zamawiający - skoro nie zdecydował się sam zapewnić narzędzia CGM API na potrzeby integracji zamawianego Systemu z systemem CliniNet - to powinien dopuścić możliwość zastosowania innych niż CGM API rozwiązań pozwalających na pobieranie danych z systemu CliniNet HIS w trybie odczytu do Systemu będącego przedmiotem niniejszego zamówienia. W takim wypadku obowiązek zakupu licencji API i współpracy z firmą CGM w zakresie rozbudowy/dostosowania API na potrzeby integracji obciążałby jedynie tego wykonawcę, który zamierzałby zastosować to narzędzie, jednak powinność ta wynikałaby z decyzji wykonawcy, nie zaś narzuconej przez Zamawiającego obligatoryjnej współpracy.

Mając na uwadze wszystko powyższe, Izba stwierdziła, że odwołanie podlega uwzględnieniu i na podstawie art. 553 ustawy Pzp orzekła jak w sentencji, nakazując Zamawiającemu dokonanie zmiany załącznika nr 4 do SWZ - Opisu przedmiotu zamówienia w pkt 3 „Wymogi integracyjne” poprzez dopuszczenie w pkt 3.1. Opisu przedmiotu zamówienia również innych niż CGM API rozwiązań pozwalających na pobieranie danych z użytkowanego przez zamawiającego systemu CliniNET HIS w trybie odczytu oraz wykreślenie pkt 3.2 i 3.3 Opisu przedmiotu zamówienia.

O kosztach postępowania odwoławczego orzeczono stosownie do jego wyniku na podstawie art. 557 i 575 ustawy Pzp oraz § 7 ust. 1 pkt 1 w zw. z § 5 pkt 1 i 2 lit. b) Rozporządzenia Prezesa Rady Ministrów w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania z dnia 30 grudnia 2020 r. (Dz. U. z 2020 r. poz. 2437).

Przewodniczący

..............................................

18