rodzaj: WYROK
data dokumentu: 2022-08-19
rok: 2022
data dokumentu: 2022-08-19
rok: 2022
sygnatury akt.:
KIO 2009/22
KIO 2009/22
po rozpoznaniu na rozprawie w dniu 16 sierpnia 2022 r. w Warszawie
odwołania
wniesioneg
o do Prezesa Krajowej Izby Odwoławczej w dniu 1 sierpnia 2022 r. przez
wykonawcę Transition Technologies-Science Spółka z ograniczoną odpowiedzialnością z
siedzibą w Warszawie w postępowaniu prowadzonym przez zamawiającego Uniwersyteckie
Centrum Kliniczne z
siedzibą w Gdańsku
odwołania
wniesioneg
o do Prezesa Krajowej Izby Odwoławczej w dniu 1 sierpnia 2022 r. przez
wykonawcę Transition Technologies-Science Spółka z ograniczoną odpowiedzialnością z
siedzibą w Warszawie w postępowaniu prowadzonym przez zamawiającego Uniwersyteckie
Centrum Kliniczne z
siedzibą w Gdańsku
orzeka:
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:
2.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;
3.
kosztami postępowania obciąża zamawiającego Uniwersyteckie Centrum Kliniczne
z
siedzibą w Gdańsku i:
3.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
U z a s a d n i e n i e
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 HI
S poprzez moduł Connector API mechanizm podłączania systemu
do HIS UCK (system CliniNET firmy CGM) za
pomocą CGM API w trybie odczytu.
3.2. Wykonawca jest zobowiązany zamówić licencje modułu API niezbędnego do
integracji w firmie CompuGroup Medical Polsk
a 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.
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
sys
temu CtiniNET HIS w sposób umożliwiający ich odczyt.
3.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 niep
roporcjonalny 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 prze
z 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 jakie
jś 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 wi
ele (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 od
czytu 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 c
odziennie 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
opty
malizację 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
dzi
ał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 zost
anie 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-o
nly 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 o
twarte 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. Wymien
iona 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 r
ealizacji 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 przypa
dku 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 p
roducenta (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
dyspozyc
ji 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. Szpit
al 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
upr
zywilejowanie jednego wykonawcy, Zamawiający stwierdził, iż z przedmiotowymi
zarzutami nie sposób się zgodzić.
Po p
rzeprowadzeniu 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 wyko
nawca, 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 d
o 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ż
p
rzedmiotem 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:
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.
3.2.
Wykonaw
ca 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.
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).
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 rea
lizacji 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
standardo
wych 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 www.bykowski.pl – 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 u
stawy Pzp Zamawiający przygotowuje i przeprowadza
postępowanie o udzielenie zamówienia w sposób: 1) zapewniający zachowanie uczciwej
kon
kurencji oraz równe traktowanie wykonawców; 2) przejrzysty; 3) proporcjonalny.
Zgodnie z art. 99 ust. 1 ustawy Pzp prze
dmiot 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
za
spokojenie jego uzasadnionych potrzeb, adekwatnie do wyznaczonego celu, zachowując
jednocześnie obiektywizm i precyzję w formułowaniu tych potrzeb. Naturalnym jest, że
dyktowany uzasa
dnionymi 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
przedm
iotowego 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
wykon
awcó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 t
ylko 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 podsta
wie 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) u
zasadnia 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
po
mocą 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
wsparc
ia 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 gesti
i 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
d
otyczył 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
do
stę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
sys
temami 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 Zama
wiają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.
I
zba 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 Zamaw
iają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 mo
gą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 przed
miocie 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 prawdopodo
bień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: ……………………………….………
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:
2.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;
3.
kosztami postępowania obciąża zamawiającego Uniwersyteckie Centrum Kliniczne
z
siedzibą w Gdańsku i:
3.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
U z a s a d n i e n i e
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 HI
S poprzez moduł Connector API mechanizm podłączania systemu
do HIS UCK (system CliniNET firmy CGM) za
pomocą CGM API w trybie odczytu.
3.2. Wykonawca jest zobowiązany zamówić licencje modułu API niezbędnego do
integracji w firmie CompuGroup Medical Polsk
a 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.
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
sys
temu CtiniNET HIS w sposób umożliwiający ich odczyt.
3.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 niep
roporcjonalny 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 prze
z 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 jakie
jś 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 wi
ele (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 od
czytu 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 c
odziennie 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
opty
malizację 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
dzi
ał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 zost
anie 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-o
nly 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 o
twarte 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. Wymien
iona 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 r
ealizacji 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 przypa
dku 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 p
roducenta (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
dyspozyc
ji 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. Szpit
al 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
upr
zywilejowanie jednego wykonawcy, Zamawiający stwierdził, iż z przedmiotowymi
zarzutami nie sposób się zgodzić.
Po p
rzeprowadzeniu 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 wyko
nawca, 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 d
o 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ż
p
rzedmiotem 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:
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.
3.2.
Wykonaw
ca 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.
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).
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 rea
lizacji 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
standardo
wych 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 www.bykowski.pl – 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 u
stawy Pzp Zamawiający przygotowuje i przeprowadza
postępowanie o udzielenie zamówienia w sposób: 1) zapewniający zachowanie uczciwej
kon
kurencji oraz równe traktowanie wykonawców; 2) przejrzysty; 3) proporcjonalny.
Zgodnie z art. 99 ust. 1 ustawy Pzp prze
dmiot 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
za
spokojenie jego uzasadnionych potrzeb, adekwatnie do wyznaczonego celu, zachowując
jednocześnie obiektywizm i precyzję w formułowaniu tych potrzeb. Naturalnym jest, że
dyktowany uzasa
dnionymi 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
przedm
iotowego 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
wykon
awcó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 t
ylko 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 podsta
wie 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) u
zasadnia 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
po
mocą 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
wsparc
ia 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 gesti
i 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
d
otyczył 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
do
stę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
sys
temami 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 Zama
wiają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.
I
zba 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 Zamaw
iają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 mo
gą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 przed
miocie 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 prawdopodo
bień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: ……………………………….………
Wcześniejsze orzeczenia:
- Sygn. akt KIO 1929/22, KIO 1943/22 z dnia 2022-08-22
- Sygn. akt KIO 1680/22, KIO 1682/22 z dnia 2022-08-12
- Sygn. akt KIO 1965/22 z dnia 2022-08-09
- Sygn. akt KIO 1895/22 z dnia 2022-08-09
- Sygn. akt KIO 1602/22 z dnia 2022-07-07
