Wyrok KIO 1211/14 z 4 lipca 2014

Zamawiający - Samodzielny Publiczny Zakład Opieki Zdrowotnej – Zespół Zakładów w Makowie Mazowieckim - prowadzi w trybie przetargu nieograniczonego postępowanie o udzielenie zamówienia na podstawie przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 9 sierpnia 2013 r. poz. 907 ze zm.), zwanej dalej „ustawą Pzp”, którego przedmiotem jest „przyspieszenie e-rozwoju Mazowsza poprzez informatyzację SPZOZ ZZLOiZ w Makowie Mazowieckim”.

Ogłoszenie o zamówieniu zostało opublikowane w Dzienniku Urzędowym Unii Europejskiej w dniu 4 czerwca 2014 r., nr 2014/S 106-186104.

W dniu 13 czerwca 2014 r. odwołanie do Prezesa Krajowej Izby Odwoławczej wniósł odwołujący Asseco Poland S.A. w Rzeszowie, odwołujący Simple S.A. w Warszawie oraz odwołujący Esaprojekt sp. z o.o. w Chorzowie. Postępowania odwoławcze toczące się na skutek wniesionych odwołań oznaczono odpowiednio: sygn. akt KIO 1211/14, sygn. akt KIO 1221/14, sygn. akt KIO 1222/14.

KIO 1211/14 Odwołujący Asseco wniósł odwołanie wobec:

1. czynności zamawiającego polegającej na opisie przedmiotu zamówienia,
2. czynności zamawiającego polegającej na określeniu kryteriów oceny ofert,
3. czynności zamawiającego polegającej na dokonaniu opisu sposobu dokonywania oceny spełniania warunków udziału w postępowaniu.

Odwołujący Asseco zarzucił zamawiającemu naruszenie:

1. art. 7 ust. 1 i 3 oraz art. 29 ust 1 i 2 ustawy Pzp poprzez zaniechanie podania w opisie przedmiotu zamówienia wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty oraz opisanie przedmiotu zamówienia w sposób niejednoznaczny poprzez następujące wymagania: a) zapewnienie w ofercie ceny na prace dodatkowe zlecone poza pulą roboczogodzin, b) zapewnienie w umowie możliwości podłączenia do systemu nowych urządzeń, które zakupi zamawiający w trakcie trwania opieki serwisowej, c) zapewnienie w umowie integracji z systemami i rejestrami państwowymi, d) wykonania system w powszechnie znanych i stosowanych technologiach informatycznych, dzięki czemu możliwe będzie przejęcie kodów źródłowych przez nowego wykonawcę i utrzymanie tego systemu w przypadku jeżeli dotychczasowy

5 wykonawca będzie miał zbyt wygórowane oczekiwania finansowe w zakresie utrzymania i rozwoju systemu,

1. art. 7 ust. 1 i 3 oraz art. 29 ust. 1 i 2 ustawy Pzp poprzez zaniechanie wskazania zakresu integracji z systemami wskazanymi w SIWZ,
2. art. 7 ust. 1 i 3 oraz art. 29 ust 1 i 2 ustawy Pzp, poprzez wskazanie w kryteriach oceny ofert takich warunków, które forują wyłącznie jednego wykonawcę,
3. art. 7 ust. 1 i 3 ustawy Pzp poprzez wymóg sporządzenia harmonogramu rzeczowo finansowego (HRF) najpóźniej 10 dni przed podpisaniem umowy,
4. art. 7 ust. 1 i 3, art. 22 ust. 4 oraz art. 29 ust 1 i 2 ustawy Pzp poprzez dokonanie opisu sposobu dokonywania oceny spełniania warunków udziału w postępowaniu w zakresie wiedzy i doświadczenia w sposób nieproporcjonalny do przedmiotu zamówienia.

Odwołujący Asseco wniósł o nakazanie zamawiającemu dokonania modyfikacji Specyfikacji Istotnych Warunków Zamówienia w sposób określony w uzasadnieniu odwołania.

Odwołujący przedstawił w odwołaniu argumentację faktyczną i prawną odnoszącą się do wszystkich zarzutów. W uzasadnieniu zarzutu dotyczącego kryteriów oceny ofert, odwołujący Asseco podniósł, że w myśl podkryteriów oceny ofert, jakie zamawiający opisał w SIWZ, wykonawca ma dostać dodatkowe punkty jeżeli „W zakresie całej funkcjonalności części medycznej (HIS) system wykorzystuje motor bazy danych Open Source”. Dodatkowe punkty mają być również przyznawane, jeżeli „W co najmniej dwóch modułach z części administracyjnej (ERP) system wykorzystuje motor bazy danych Open Source”. Wywiódł, że zamawiający wymaga oprogramowania na bazach danych Open Source, choć jego potrzeby mogą być zrealizowane w oparciu o system na bazach komercyjnych, gdyż takie oprogramowanie dostarcza jedyny twórca oprogramowania dla szpitali na bazach Open Source. Co prawda drugie ze wskazanych kryteriów dopuszcza tzw. heterogeniczność środowiska bazodanowego, oznacza to że cześć modułów jest na bazie np. Open Source a cześć na komercyjnej. Jednakże takie rozwiązanie, jest niekorzystne dla zamawiającego.

Heterogeniczność środowiska bazodanowego wpływa niekorzystanie na koszty, efektywność oraz możliwości związane z zarządzaniem, utrzymaniem i rozwojem rozwiązania korzystającego z tego środowiska. Istotne są następujące elementy wymienionych powyżej procesów: - backup środowiska bazodanowego, odzyskiwanie danych po ewentualnej awarii, zbędne skomplikowanie procedur administracyjnych, - replikacja danych do środowisk typu disaster recovery, ponownie zbędne skomplikowanie procedur administracyjnych,

6

• zarządzanie wysoką dostępnością, w wypadku baz danych różnego typu stosowane są inne mechanizmy zabezpieczeń przed ewentualną awarią i niedostępnością podsystemu bazodanowego. Zwiększa to koszt wdrożenia tych mechanizmów, komplikuje architekturę systemu oraz zbędnie komplikuje procedury administracyjne, - skalowanie rozwiązania do większych potrzeb związanych z wydajnością rozwiązania. W przypadku dwóch lub więcej technologii baz danych w jednym rozwiązaniu nie ma możliwości skorzystania z efektu konsolidacji, czyli bardziej efektywnego wykorzystania zasobów sprzętowych dla dwóch lub więcej instancji bazy danych. - zarządzanie danymi w dwóch lub więcej różnych technologicznie repozytoriach danych zmniejsza efektywność procesu zarządzania i utrzymania, w większości przypadków wymusza stosowanie więcej niż jednego narzędzia administracyjnego, - zarządzanie udostępnianiem danych dla nowych rozwiązań w infrastrukturze IT (np. system raportowy, system portalowy). Dostęp do danych w jednolitym technologicznie repozytorium jest znacznie prostszy niż w dostępie do danych rezydujących w dwóch niezależnych i różnych technologicznie repozytoriach.

Odwołujący Asseco wniósł o nakazanie zamawiającemu zmiany kryteriów wyboru oferty poprzez wykreślenie ww. przesłanek wpływających na ocenę złożonej oferty.

KIO 1221/14 Odwołujący Simple wniósł odwołanie wobec:

1. czynności zamawiającego polegającej na opisie przedmiotu zamówienia,
2. czynności zamawiającego polegającej na żądaniu złożenia przez wykonawców wraz z ofertą oświadczeń i dokumentów zbędnych do przeprowadzenia postępowania,
3. czynności zamawiającego polegającej na określeniu kryteriów oceny ofert.

Odwołujący Simple zarzucił zamawiającemu naruszenie:

1. art. 29 ust. 1 i 2 oraz art. 30 ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób niejednoznaczny i niewyczerpujący, za pomocą niedostatecznie dokładnych i zrozumiałych określeń, mogących mieć wpływ na sporządzenie oferty oraz w sposób naruszający uczciwą konkurencję,
2. art. 7 ust. 1, art. 25 ust. 1 oraz art. 29 ust. 2 ustawy Pzp poprzez żądanie dokumentów w postaci oświadczeń producenta,
3. art. 91 ust. 2 i 3 w zw. z art. 7 ust. 1 ustawy Pzp poprzez naruszenie zasad uczciwej konkurencji i równości wykonawców przez ustalenie kryteriów oceny ofert, ich znaczenia i sposobu oceny, które w szczególności nie łączą się z przedmiotem zamówienia i w sposób nieuzasadniony promują jeden konkretny podmiot,

7

1. art. 7 ust. 1 ustawy Pzp poprzez błędną wykładnię i niewłaściwe zastosowanie przepisów skutkujące prowadzeniem postępowania w sposób naruszający podstawowe zasady prawa zamówień publicznych,
2. innych przepisów wymienionych lub wynikających z uzasadnienia odwołania.

Odwołujący Simple wniósł o nakazanie zamawiającemu dokonania modyfikacji Specyfikacji Istotnych Warunków Zamówienia w sposób określony w uzasadnieniu odwołania.

Odwołujący Simple przedstawił w odwołaniu argumentację faktyczną i prawną odnoszącą się do wszystkich zarzutów.

Odwołujący Simple, w uzasadnieniu zarzutu naruszenia art. 29 ust. 1 i 2 ustawy Pzp podniósł, że zamawiający w załączniku nr 1 do SIWZ w pkt 2.1 „Wymagania ogólne” przedstawił następujące wymagania: „Dostęp do funkcji systemu jest realizowany ze stanowiska roboczego bez konieczności instalacji dodatkowych aplikacji lub modułów oprogramowania obsługującego komunikację pośrednią między interfejsem użytkownika na stanowiska roboczym, a systemem na serwerze” oraz „System działa w architekturze trójwarstwowej”. Argumentował, że wymóg trójwarstwowej architektury uzasadnia jedynie fakt, iż zamawiający opisując przedmiot zamówienia wskazał na rozwiązanie, które jest w stanie zaoferować ograniczona liczba wykonawców, w tym w szczególności wykonawcy Impulsy sp. z o.o. lub ewentualnie firma Textus Virtualis, która jest autorem oprogramowania Medicus, czyli oprogramowania oferowanego przez Impulsy sp. z o.o. Opisana przez

zamawiającego architektura trójwarstwowa systemu wymaga silniejszego sprzętu na serwery aplikacyjne oraz posiada ograniczenia w funkcjonalności interfejsu dla tzw. „cienkiego klienta” oraz wymusza zwiększony ruch sieciowy, jak również może utrudniać implementację nowych komponentów. Odwołujący Simple wskazał także, że oferowany przez niego system jest w głównej części wykonany w architekturze dwuwarstwowej. Przytoczone powyżej dwa zapisy eliminują włączenie warstwy pośredniej poprzez np. Remote Desktop Services (RDS usługi terminalowe). Niedopuszczenie działania poprzez RDS (poprzez brak możliwości zainstalowania dodatkowych apletów do przeglądarki) jest wymogiem dyskryminującym wykonawców oraz naruszającym zasady uczciwej konkurencji, bowiem system w architekturze dwuwarstwowej zapewnia bezpieczeństwo serwera, minimalizuje ruch w sieci, umożliwia przetwarzanie danych bezpośrednio na serwerze, jak równej odciążenie centralnego komputera od obsługi interfejsu użytkownika. Wobec powyższego odwołujący wniósł o usunięcie z załącznika nr 1 do SIWZ w pkt. 2.1 przytoczonych uprzednio punktów, bądź ewentualnie o dopuszczenie systemu dwuwarstwowego z modułami trójwarstwowymi typu portalowego, a tym samym dokonanie modyfikacji SIWZ poprzez wykreślenie wymagania: „Dostęp do funkcji systemu jest realizowany ze stanowiska roboczego bez

8 konieczności instalacji dodatkowych aplikacji lub modułów oprogramowania obsługującego komunikację pośrednią między interfejsem użytkownika na stanowiska roboczym, a systemem na serwerze” oraz zmianę zapisu na: „System działa w architekturze dwuwarstwowej lub trójwarstwowej”.

W dalszej części odwołania, w odniesieniu do zarzutu naruszenia art. 29 ust. 1 i 2 ustawy Pzp, odwołujący Simple wywiódł, że w załączniku nr 1 do SIWZ w punkcie 2.1 „Wymagania ogólne” zamawiający zaznaczył, iż żąda aby: „Dla wszystkich modułów obsługi pacjenta (tj. Ruch chorych, Rehabilitacja, Oddział, Izba przyjęć, Rejestracja, Gabinet, Blok operacyjny, Szpitalny Oddział Ratunkowy, Zlecenia, Zakażenia itp.) oraz Apteki system musi umożliwić pracę z poziomu przeglądarki WWW". Argumentował, że z powyższego opisu wynika, iż zamawiający wskazał, że oczekuje rozwiązania w którym dostarczona aplikacja działa w oparciu o przeglądarkę www w częściowym zakresie systemu HIS (nie dotyczy Elektronicznej Dokumentacji Medycznej) oraz, co może się wydawać niezrozumiałe, bez części „szarej” administracyjnej. W ocenie odwołującego tak sporządzony opis przedmiotu narzuca sposób w jaki skonstruowany jest interfejs aplikacji. Nie realizuje podstawowego postulatu, jakim jest opis przedmiotu zamówienia dokonany za pomocą obiektywnych cech jakościowych i technicznych lub poprzez wskazanie wymagań funkcjonalnych umożliwiających dostarczenie rozwiązania równoważnego. Zamawiający wskazuje na konkretne techniczne rozwiązanie bez żadnej możliwości dopuszczenia rozwiązania równoważnego i jego opisu. Wskazanie, iż system HIS (ERP już nie) ma działać wyłącznie z poziomu przeglądarki internetowej nie niesie ze sobą spełnienia przesłanki co do cechy jakościowej lub technicznej, ponieważ nie realizuje on w swoim zakresie cech, jakimi charakteryzują się systemy informatyczne, np. funkcjonalność (bo dużo lepsza jest z poziomu grubego klienta), zaawansowanie merytoryczne, otwartość, czy łatwość zarządzania (ponieważ taką samą można osiągnąć poprzez zastosowanie odpowiednich mechanizmów zarządzania upgrade’ami w zakresie grubych klientów). Taki opis przedmiotu zamówienia ogranicza konkurencję poprzez jego zawężenie do firm, które swoje aplikacje oparły na interfejsie dostępnym przez przeglądarkę internetową. Interfejs taki z pewnością ma wiele zalet ale ma również wiele wad. Powszechnie wiadome jest, że aplikacje oparte o interfejs www są dużo mniej ekonomiczne i kosztowne w użytkowaniu niż aplikacje desktop.

Również co do bezpieczeństwa danych wiadomo, że przeglądarki nie są w stanie zapewnić wszystkich standardowych w dzisiejszych czasach mechanizmów bezpieczeństwa.

Powyższe wskazuje, że wybór tej technologii prezentacji danych jest znacznie bardziej ryzykowny i nieodpowiedni, niż wybór rozwiązania opartego o aplikację kliencką. Dodatkowo, na stosowanie w tym zakresie praktyk ograniczających konkurencję, zdaniem odwołującego Simple wskazuje fakt, że w odniesieniu do systemu ERP (część „szara” - administracyjna) zamawiający nie wymaga już, aby system ten funkcjonował w oparciu o przeglądarkę www.

9 Odwołujący wniósł o dokonanie zmiany zapisów wskazanych w załączniku nr 1 do SIWZ w punkcie 2.1 Wymagania ogólne, str. 6 na następujące: „Dla wszystkich modułów

obsługi pacjenta (tj. Ruch Chorych, Rehabilitacja, Oddział, Izba Przyjęć, Rejestracja, Gabinet, Blok operacyjny, Szpitalny Oddział Ratunkowy, Zlecenia, Zakażenia itp.) oraz Apteki system musi umożliwić pracę z poziomu przeglądarki WWW lub aplikacji klienckiej zainstalowanej na stacji roboczej”.

Odwołujący Simple, w odniesieniu do zarzutu dotyczącego kryteriów oceny ofert podniósł, że kryteria pozacenowe muszą być związane z przedmiotem zamówienia, nie mogą mieć charakteru podmiotowego, ani pozostawać w sprzeczności z powszechnie obowiązującymi przepisami prawa, a także ograniczać zasad równego traktowania oraz uczciwej konkurencji. Wskazał, że w ramach zasad oceny kryterium „Wymagania Techniczne” - w tabeli dotyczącej wymagań technicznych - na 6 parametrów, które będą badane przez zamawiającego, 2 dotyczą wykorzystywania motoru bazy danych Open Source (pkt 4. „W zakresie całej funkcjonalności części medycznej (HIS) system wykorzystuje motor bazy danych Open Source”; pkt 5. „W co najmniej dwóch modułach z części administracyjnej (ERP) system wykorzystuje motor bazy danych Open Source (...)”).

Oba są najwyżej punktowanymi przez zamawiającego (10 punktów za spełnianie każdego z wymogów). Ocena całokształtu kryteriów określonych wskazuje na to, że taki dobór i kompleksowe zestawienie wymagań jest w stanie spełnić wykonawca Impulsy sp. z o.o. lub ewentualnie firma Textus Virtualis, która jest autorem oprogramowania Medicus (czyli oprogramowania oferowanego przez Impulsy sp. z o.o.). Inni dostawcy nie mają szans zdobycia odpowiedniej ilości punktów w kryterium „wymagania techniczne”, które stanowi aż 40% oceny ogólnej. Świadczy to o faworyzowaniu przez zamawiającego podmiotów, które oferują tego typu rozwiązanie i de facto skutkuje niemożnością zaoferowania oprogramowania komercyjnego. W wielu innych postępowaniach w sprawie udzielenia zamówienia publicznego, gdzie wymogi zostały określone w sposób analogiczny, doszło do wyboru jako najkorzystniejszej oferty firmy Impulsy sp. z o.o. lub ewentualnie firmy Textus Virtualis, która jest autorem oprogramowania Medicus, czyli oferowanego przez Impulsy sp. z o.o. Odwołujący w omawianym zakresie wskazał na następujące postępowania: a) postępowanie prowadzone przez Szpital Wojewódzki im. Mikołaja Kopernika w Koszalinie na „System elektronicznej rejestracji pacjentów w poradniach specjalistycznych Szpitala Wojewódzkiego w Koszalinie”; TP-231/5/PN/49/2009, prowadzone jeszcze w 2009 r.; postawiono wymóg dostarczenia bazy danych Open Source, choć wówczas nie był on przedmiotem oceny w ramach kryterium oceny ofert; poza ofertą firmy Impulsy sp. z o.o. nie wpłynęły wówczas żadne inne i zamawiający dokonał ostatecznie wyboru ww. oferty;

10 dokumentacja postępowania dostępna pod adresem: http://www.swk.med.pl/zamowieniapubliczne/dostawy/system-elektronicznej-rejestracji-pacjentow.html; b) postępowanie prowadzone przez Uniwersytecki Szpital Kliniczny w Olsztynie pn.

„Świat e-usług dla zdrowia - informatyzacja Uniwersyteckiego Szpitala Klinicznego w Olsztynie”; nr sprawy: 30/2013; postawiono wymóg dostarczenia bazy danych Open Source i kwestia była przedmiotem oceny w ramach kryterium „Wymagania techniczne”, w tym przypadku także była to funkcjonalność najwyżej punktowana; Zamawiający dokonał wyboru jako najkorzystniejszej oferty konsorcjum Textus Virtualis sp. z o.o. oraz Syntektik S.A. (informacja o wyborze z dnia 19 sierpnia 2013 r.); dokumentacja postępowania dostępna pod adresem: http://usk-olsztyn.pl/index.php/2013-03-24-10-45-14/zamowienia-30-2013-swiat-e-uslug-dla-zdrowia- publiczne/zamowienia-od30-000-euro/51 informatyzacia-uniwersyteckiego-szpitala-klinicznego-w-olsztynie; c) postępowanie prowadzone przez Samodzielny Publiczny Zespół Zakładów Opieki Zdrowotnej Szpital w Iłży pn. „środowisko teleinformatyczne SP ZOZ w Iłży dla gromadzenia, przetwarzania i wymiany danych medycznych, dokumentacji medycznej w systemie elektronicznego obiegu dokumentów oraz wytwarzania i udostępniania e-usług dla pacjentów, Nr sprawy: UB/05 /2013; postawiono wymóg dostarczenia bazy danych Open Source i kwestia była przedmiotem oceny w ramach kryterium „Wymagania techniczne”, w tym przypadku także była to funkcjonalność najwyżej punktowana; Zamawiający dokonał wyboru jako najkorzystniejszej oferty konsorcjum Textus Virtualis Sp. z o.o. oraz Syntektik S.A. (kopia informacji o wyborze z dnia 19 sierpnia 2013 r.); poza ofertą firmy Textus Virtualis Sp. z o.o. nie wpłynęły wówczas żadne inne i zamawiający dokonał ostatecznie

wyboru ww. oferty (informacja o wyborze z dnia 7 stycznia 2014 r.); dokumentacja postępowania dostępna pod adresem: http://bip2.szpitalilza.com.pl/index.php?id=113&p=52.

KIO 1222/14 Odwołujący Esaprojekt wniósł odwołanie wobec:

1. czynności zamawiającego polegającej na opisie przedmiotu zamówienia,
2. czynności zamawiającego polegającej na określeniu kryteriów oceny ofert,
3. czynności zamawiającego polegającej na opisaniu próbki systemu, jaką wykonawcy obowiązani będą przedstawić oraz czasu, w jakim należy przystąpić do jej prezentacji,
4. zaniechaniu czynności opisania w SIWZ scenariusza prezentacji i zaniechaniu utrwalania jej przebiegu za pomocą kamery wideo.

Odwołujący Esaprojekt zarzucił zamawiającemu naruszenie:

11

1. art. 29 ust. 1 i 2, 30 ust. 1 i 2 ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób, niejednoznaczny, niewyczerpujący i naruszający uczciwą konkurencję oraz zawężający technologię,
2. art. 7 ust. 1 ustawy w zw. z art. 91 ust. 1, art. 36 ust. 1 pkt 13 ustawy Pzp oraz art. 29 ust 1 i 2 ustawy poprzez dokonanie czynności opisania przedmiotu zamówienia oraz kryteriów oceny ofert w sposób niekonkurencyjny, preferujący określonych wykonawców (posiadane przez nich rozwiązania technologiczne),
3. art. 29 ust 1 i 2 ustawy Pzp i art. 7 ust. 1 ustawy Pzp w zw. z § 6 ust. 1 pkt 1 Rozporządzenia w sprawie w sprawie rodzajów dokumentów, jakich może żądać zamawiający od wykonawcy, oraz form, w jakich te dokumenty mogą być składane, poprzez określenie wymogu, że podczas prezentacji czas na uruchomienie zdeponowanej próbki wraz z rozpoczęciem prezentacji wyniesie max. 20 minut.

Odwołujący Easprojekt wniósł o nakazanie zamawiającemu dokonania modyfikacji Specyfikacji Istotnych Warunków Zamówienia w sposób określony w uzasadnieniu odwołania.

Odwołujący Esaprojekt przedstawił w odwołaniu argumentację faktyczną i prawną odnoszącą się do wszystkich zarzutów.

Odwołujący Esaprojekt, w uzasadnieniu zarzutu dotyczącego kryteriów oceny ofert podniósł, że zamawiający zamierza przyznać łącznie 20 punktów ofercie wykonawcy, który zaoferuje systemy HIS i ERP wykorzystujące w zakresie HIS w całej funkcjonalności a w zakresie ERP tylko w dwóch modułach motor bazy danych Open Source. W ocenie odwołującego Esaprojekt rozwiązanie to jest nieuzasadnione. Jeżeli zamawiającemu zależy na wykorzystywaniu w swojej jednostce oprogramowania typu Open Source, to dlaczego taki wymóg postawił tylko i wyłącznie w stosunku do bazy danych? W zakresie innego oprogramowania np. do wirtualizacji, oprogramowania systemowego serwerów czy oprogramowania będącego przedmiotem zamówienia, takiego wymogu nie określił. Takie kryteria oceny ofert preferują firmę Textus Virtualls w Warszawie oraz Impulsy sp. z o.o. w Warszawie. Podobne zapisy znalazły się w np. w postępowaniu ogłoszonym przez Samodzielny Publiczny Zespół Zakładów Opieki Zdrowotnej Szpital w Iłży na „środowisko teleinformatyczne SP ZOZ w Iłży dla gromadzenia, przetwarzania i wymiany danych medycznych, dokumentach medycznej w systemie elektronicznego obiegu dokumentów oraz wytwarzania i udostępniania e-usług dla pacjentów", numer referencyjny zamawiającego:

UB/05/2013, Publikacja w Dzienniku Wspólnot Europejskich w dniu 12 listopada 2013r. pod nr 2013/S 219-381473. W postępowaniu tym została złożona jedna oferta przez firmę Textus Virtualis sp. z o.o. Odwołujący Esaprojekt wskazał nadto, że żaden z wiodących

12 producentów oprogramowania medycznego i ERP w Polsce nie stosuje do przechowywania tak wrażliwych danych, jak dane medyczne, bazy danych open source. Czołowi producenci oprogramowania korzystają z następujących baz danych:

1. Comarch S.A./Esaprojekt sp. z o.o. Oracle DataBase oraz Microsoft SQL Server,
2. Systemy Informatyczne Alma sp. z o.o. Oracle DataBase,
3. Asseco S.A. Oracle DataBase,
4. CompuGroup Medical Polska sp. z o.o. Oracle DataBase, Sybase,
5. Gabos DB2,
6. Kamsoft S.A. Oracle DataBase.

Odwołujący Esaprojekt podkreślił, że jedynie bazy komercyjne wspomniane powyżej spełniają międzynarodowe standardy bezpieczeństwa. Dowodem na lekkomyślność zamawiającego są oceny, jakie otrzymały dwa komercyjne (czyli nie open source a rozwijane przez podmioty komercyjne) produkty bazujące na rozwiązaniach open source (za https://www.commoncriteriaDortal.oro/Droducts/#DB). Ocena zabezpieczeń przechowywania bazuje na Standardzie ISO/IEC 15408 Common Criteria for Information Security Evaluation (Wspólne kryteria do oceny zabezpieczeń informatycznych) i składa się z trzech części: • ISO/IEC 15408-1 (CC Part 1) zawiera: wprowadzenie, opis modelu zarządzania ryzykiem i kreowania uzasadnionego zaufania oraz struktur podstawowych dokumentów, opracowywanych na potrzeby certyfikacji produktu lub systemu; • ISO/IEC 15408-2 (CC Part 2) zawiera katalog komponentów funkcjonalnych (ang. components) służących do modelowania funkcjonalnych wymagań functional bezpieczeństwa; • ISO/IEC 15408-3 (CC Part 3) zawiera katalog komponentów uzasadniających (ang. assurance components), służących do modelowania wymagań zaufanie uzasadniających zaufanie do funkcji zabezpieczających.

Do produktów tych należą • EnterpriseDB Postgres Plus Advanced Server 8.4 rozwijany przez EnterpriseDB Corporation - ostatnia ewaluacja w 2011 roku, ocena EAL2+ • PostgreSQL Certified Version V 8.1.5 for Linux rozwijany przez NTT Data Corporation - ostatnia ewaluacja w 2007 roku, ocena EAL1 Co ważne, że żaden z produktów open source nigdy nie był nawet oceniany, a te rozwijane komercyjnie, otrzymują bardzo niskie noty, które w sposób znaczący odbiegają od wyników osiąganych przez producentów baz danych takich jak Oracle, IBM, Microsoft czy Sybase.

Odwołujący zwrócił również uwagę, że w punkcie 4.7 zamawiający wymagał, aby przez cały okres trwania gwarancji (to jest przez pięć lat) wykonawca zapewnił wsparcie producenta motoru bazy danych. Wsparcie producenta motoru bazy danych w przypadku rozwiązań

13 komercyjnych stanowi około 110% wartości licencji na oprogramowanie bazy danych w przeciągu dwóch lat. Zestawiając ten wymóg z kryteriami oceny ofert łatwo stwierdzić na czym polega „preferowanie" w/w firm. Nie ponoszą one kosztów licencji ani wsparcia producenta (kosztem bardzo niskiego poziomu bezpieczeństwa, nie mieszczącego się w zakresie żadnych norm europejskich) a dodatkowo są punktowane w wysokości 20 punktów w ramach kryteriów oceny ofert.

Biorąc powyższe pod uwagę odwołujący Esaprojekt wniósł o dokonanie modyfikacji SIWZ polegającej na zmianie kryteriów oceny ofert przez zastąpienie ich punktowaniem w takiej samej liczby punktów w stosunku do wykonawców, którzy w ramach przywołanego europejskiego standardu ocen bezpieczeństwa uzyskali co najmniej noty w wysokości EAL4+ ALC_FLR.3. Wniósł także o wyłączenie z przedmiotu zamówienia dostawy bazy danych i wsparcia dla oprogramowania bazy danych. Postępowanie to można przeprowadzić już po wyłonieniu wykonawcy, dzięki czemu nie będzie to miało wpływu na wynik postępowania.

W odniesieniu do zarzutu dotyczącego opisanego czasu na uruchomienie zdeponowanej próbki systemu, odwołujący Esaprojekt podniósł, że jego zdaniem zamawiający w sposób zupełnie niezrozumiały ogranicza konkurencję, ponieważ wykonawcy, których uruchomienie zdeponowanej próbki przekroczy 20 minut, pomimo tego, że ich system będzie spełniał wszystkie pozostałe wymagania zamawiającego, będą wykluczeni z postępowania z uwagi na niespełnienie tego bezzasadnego warunku.

Odwołujący Esaprojekt wywiódł, że wymóg jest niezwiązany z przedmiotem zamówienia i prowadzi jedynie do niezrozumiałego i bezcelowego ograniczania konkurencji. Zwrócił uwagę, że termin realizacji umowy to 15 grudnia 2014. Ponadto, to wykonawca proponuje brzmienie Harmonogramu Rzeczowo-Finansowego, zatem definiuje, w jakim terminie będzie w stanie uruchomić dostarczone oprogramowanie na sprzęcie zamawiającego. Nadto, zamawiany system jest bardzo złożonym produktem informatycznym, którego uruchomienie

jest dużo bardziej skomplikowane niż uruchomienie np. systemu operacyjnego Windows, który czasem potrafi się uruchamiać nawet 5 minut. Wreszcie, nigdzie w wymogach co do ZSI zamawiający nie wskazał, że oferowany system ma być uruchamiany w ciągu 20 minut.

Odwołujący wniósł o zmianę czasu na uruchomienie próbki i rozpoczęcie prezentacji do 60 minut lub wyeliminowanie tego ograniczenia jako zbędnego.

W odniesieniu do zarzutu dotyczącego warunków, w jakich miała się odbywać prezentacja próbki, odwołujący Esaprojekt podniósł, iż zamawiający na potrzeby uruchomienia systemu, jaki zamawia, w przedmiocie zamówienia określił serwery klasy Enterprise. Aby system działał wydajnie i zgodnie z oczekiwaniami, powinien być

14 przedstawiony na takim samym sprzęcie jaki jest przedmiotem zamówienia, co jest nierealne i wykracza poza cel próbki, zrównując ten etap przetargu z wykonaniem zobowiązania. Po drugie, zamawiający wymaga, aby wykonawcy ubiegający się o udzielenie zamówienia powierzyli mu swoje mienie znacznej wartości, bez jakiegokolwiek uzasadnienia tej okoliczności. Po trzecie, nie są jasne intencje zamawiającego, czy chce on zweryfikować, czy dane oprogramowanie posiada wymagane przez niego funkcjonalności, co można zrobić na inne sposoby, które nie polegają na zajęciu na długi okres sprzętu wykonawcy.

Sposobami takim jest np. złożenie w ofercie dokumentacji wykonanego w ramach próbki zadania próbnego i jego następne - po otwarciu ofert odtworzenie - w czasie rzeczywistym u zamawiającego, przy zachowaniu zgodności złożonej w ofercie dokumentacji (np. zrzutów ekranu) z ekranami pokazanymi w czasie prezentacji lub za pomocą zdalnego dostępu do zdalnego serwera aplikacji. Po czwarte, wszyscy wykonawcy ubiegający się o udzielenie zamówienia powinni mieć wiedzę, w jaki sposób będzie przebiegała prezentacja, dlatego scenariusz prezentacji powinien być załącznikiem do SIWZ i powinien obejmować tylko podstawowe wymagania systemowe. Zamawiany system jest systemem złożonym i spełnienie wymaganych funkcjonalności jest możliwe tylko przez jednego producenta. Jest to ograniczanie konkurencji i taki sposób postępowania powinien być wyeliminowany z praktyki postępowań o udzielenie zamówień publicznych. Odwołujący Esaprojekt wniósł o zmianę punktu 5.1 SIWZ - tabela punkt 14 na następujący:

„Próbka oferowanego ZSI na płycie CD, umożliwiająca weryfikację oferowanych funkcjonalności w sposób wybrany przez Wykonawcę (prezentacja ze zdalnego serwera, system uruchamiany na sprzęcie wykonawcy z płyty CD/DVD, system uruchamiany bezpośrednio ze sprzętu wykonawcy jako próbki) w szczególności w zakresie podlegającym ocenie punktowej w ramach kryterium oceny ofert, w postaci oprogramowania aplikacyjnego (w zakresie HIS - oprócz LIS, RIS, PACS oraz ERP), jako w pełni działającego i skonfigurowanego umożliwiającego weryfikację oferowanej funkcjonalności. Zamawiający wymaga, aby próbka została złożona wraz z ofertą. Próbka jest rozumiana jako dokument zgodnie z Rozporządzeniem Prezesa Rady Ministrów z dnia 30 grudnia 2009 r. w sprawie dokumentów rodzajów dokumentów, jakich może żądać zamawiający od wykonawcy, oraz form, w jakich te dokumenty mogą być składane. Zamawiający wyjaśnia, że zgodnie z art. 97 ust. 2, zwróci próbki Wykonawcom, których oferty nie zostały wybrane, na ich wniosek.

Zamawiający będzie rejestrował przebieg prezentacji na kamerę video. Nagranie video z prezentacji Wykonawcy, który złożył ofertę najkorzystniejszą, Zamawiający, zgodnie z art. 97 ust. 1, przechowuje jako załącznik do protokołu przez okres 4 lat od dnia zakończenia postępowania o udzielenie zamówienia, w sposób gwarantujący jego nienaruszalność.

Zamawiający załącza do SIWZ jako Załącznik nr 15 scenariusz prezentacji obejmujący wybrane, podstawowe funkcjonalności systemu”.

15 W dalszej części odwołania, w odniesieniu do wymogu, iż „dla wszystkich modułów obsługi pacjenta (tj. Ruch chorych, Rehabilitacja, Oddział, Izba przyjęć, Rejestracja, Gabinet, Blok operacyjny, Szpitalny Oddział Ratunkowy, Zlecenia, Zakażenia itp.) oraz Apteki system musi umożliwić pracę z poziomu przeglądarki www”, odwołujący Esaprojekt podniósł, że dostęp do systemu z poziomu przeglądarki www jest cechą techniczną. Oznacza to, że w przedmiotowym postępowaniu brzmienie tego zapisu powinno być opisane w następujący sposób „system musi umożliwić pracę z poziomu przeglądarki www lub w sposób równoważny”. Dodatkowo, zdaniem odwołującego, aby zapewnić pełną zgodność w zakresie

zamawianych systemów zamawiający powinien wymagać, aby również system ERP był dostępny z poziomu przeglądarki www lub w sposób równoważny. Chyba, że preferowana przez zamawiającego firma posiada tylko system HIS dostępny przez www a system ERP nie. Odwołujący Esaprojekt wniósł o dokonanie modyfikacji postanowień SIWZ na następujące: ”Dla wszystkich modułów obsługi pacjenta (tj. Ruch chorych, Rehabilitacja, Oddział, Izba przyjęć, Rejestracja, Gabinet, Blok operacyjny, Szpitalny Oddział Ratunkowy, Zlecenia, Zakażenia itp.) oraz Apteki system musi umożliwić pracę z poziomu przeglądarki WWW lub w sposób równoważny”, „Dla wszystkich modułów systemu ERP system musi umożliwić pracę z poziomu przeglądarki WWW lub w sposób równoważny”, Wniósł także o zmianę kryterium numer 3 oceny ofert na takie, jakie będzie zgodne z powyższą dyspozycją, to znaczy, że wielkość buforowanych danych po stronie klienta nie będzie przekraczała 300 kb.

Do postępowań odwoławczych o sygn. akt KIO 1211/14 i KIO 1221/14 po stronie zamawiającego, zachowując termin ustawowy oraz obowiązek przekazania kopii przystąpień zamawiającemu i odwołującym oraz wskazując interes w uzyskaniu rozstrzygnięcia na korzyść zamawiającego przystąpił przystępujący Atende Medica sp. z o.o.

Do postępowania odwoławczego o sygn. akt KIO 1211/14 i KIO 1221/14 po stronie odwołującego, zachowując termin ustawowy oraz obowiązek przekazania kopii przystąpienia zamawiającemu i odwołującemu oraz wskazując interes w uzyskaniu rozstrzygnięcia na korzyść odwołujących przystąpił przystępujący Esaprojekt sp. z o.o.

Do postępowania odwoławczego o sygn. akt KIO 1222/14 po stronie odwołującego, zachowując termin ustawowy oraz obowiązek przekazania kopii przystąpienia zamawiającemu i odwołującemu oraz wskazując interes w uzyskaniu rozstrzygnięcia na korzyść odwołującego przystąpił przystępujący Asseco Poland.

16 Do postępowania odwoławczego o sygn. akt KIO 1222/14 po stronie odwołującego, zachowując termin ustawowy oraz obowiązek przekazania kopii przystąpienia zamawiającemu i odwołującemu oraz wskazując interes w uzyskaniu rozstrzygnięcia na korzyść odwołującego przystąpił przystępujący CompuGroup Medical Polska.

Zamawiający, w dniu 30 czerwca 2014 r. dokonał modyfikacji postanowień SIWZ, którą zamieścił na swej stronie internetowej.

Zamawiający złożył odpowiedzi na odwołania. W odpowiedziach tych wskazał, że 30 czerwca 2014 r. dokonał modyfikacji postanowień SIWZ, która w znacznej mierze wyczerpuje żądania odwołujących. W zakresie zarzutów nieuwzględnionych, wniósł o oddalenie odwołań, przedstawił uzasadnienie faktyczne i prawne swego stanowiska.

Po zapoznaniu się z treścią modyfikacji i odpowiedzi na odwołanie odwołujący Asseco Poland oświadczył, że modyfikacja postanowień SIWZ w znacznej części wyczerpuje jego żądania i spór pomiędzy stronami w tym zakresie wygasł. Oświadczył także dodatkowo, że cofa odwołanie w zakresie zarzutu dotyczącego harmonogramu rzeczowo-finansowego.

Oświadczył, że w tej sytuacji sporny pomiędzy stronami pozostaje jedynie zarzut dotyczący kryteriów oceny ofert.

Po zapoznaniu się z treścią modyfikacji SIWZ i odpowiedzią na odwołanie odwołujący Simple oświadczył, że podtrzymuje odwołanie wyłącznie w zakresie zarzutów co do których zamawiający wypowiedział się negatywnie w odpowiedzi na odwołanie, tj. zarzutu dotyczącego wymogu zaoferowania systemu w architekturze trójwarstwowej, zarzutu dotyczącego wymagania zapewnienia pracy systemu z poziomu przeglądarki www oraz zarzutu w odniesieniu do kryteriów oceny ofert.

Po zapoznaniu się z treścią modyfikacji SIWZ i odpowiedzią na odwołanie odwołujący Esaprojekt oświadczył, że podtrzymuje zarzut numer 7 dotyczący kryteriów oceny ofert, zarzuty numer 10 i 11 dotyczące próbki oraz jej prezentacji oraz zarzut numer 12 dotyczący wymogu pracy systemu z poziomu przeglądarki www. Pozostałe zarzuty cofa wobec

dokonanej przez zamawiającego modyfikacji.

Uwzględniając całość dokumentacji z przedmiotowego postępowania, w tym w szczególności: protokół postępowania, ogłoszenie o zamówieniu, postanowienia SIWZ, odwołania, zgłoszenia przystąpień do postępowań odwoławczych, odpowiedzi na odwołania, modyfikację postanowień SIWZ, jak również biorąc pod uwagę oświadczenia i stanowiska a także dokumenty stron i uczestników postępowania 17 złożone w trakcie posiedzenia i rozprawy, Krajowa Izba Odwoławcza ustaliła i zważyła, co następuje:

W pierwszej kolejności Krajowa Izba Odwoławcza ustaliła, że odwołania nie zawierają braków formalnych oraz zostały uiszczone od nich wpisy. W dalszej kolejności Izba stwierdziła, że nie została wypełniona żadna z przesłanek skutkujących odrzuceniem któregokolwiek z odwołań na podstawie art. 189 ust. 2 ustawy Pzp.

Zamawiający prowadzi postępowanie o udzielenie zamówienia w trybie przetargu nieograniczonego z zastosowaniem przepisów ustawy Pzp wymaganych przy procedurze, której wartość szacunkowa zamówienia przekracza kwoty określone w przepisach wydanych na podstawie art. 11 ust. 8 ustawy Pzp.

W ocenie Izby, wypełnione zostały przesłanki dla wniesienia odwołań określone w art.

179 ust. 1 ustawy Pzp, tj. posiadanie przez każdego z odwołujących interesu w uzyskaniu danego zamówienia oraz możliwości poniesienia szkody w wyniku naruszenia przez zamawiającego przepisów ustawy. Na etapie dokonywania przez zamawiającego w SIWZ opisu przedmiotu zamówienia, kryteriów oceny ofert sporządzenie tego opisu w taki sposób, który może naruszać uczciwą konkurencję jak również w sposób, który może uniemożliwić wykonawcy złożenie niepodlegającej odrzuceniu oferty prowadzi do powstania szkody po stronie tego wykonawcy w postaci utraty korzyści, z jakimi wiązać się może uzyskanie zamówienia. Powyższe wyczerpuje przesłanki z art. 179 ust. 1 ustawy Pzp.

Krajowa Izba Odwoławcza stwierdziła, że odwołania zasługują na uwzględnienie, choć nie wszystkie zarzuty potwierdziły się w ustalonym przez Izbę stanie faktycznym.

1. Zarzut dotyczący podkryteriów oceny ofert, opisanych w pkt 7. III SIWZ, tabela wiersz 4 i 5 (sygn. akt KIO 1211/14, KIO 1221/14, KIO 1222/14) Zarzut potwierdził się w ustalonym przez Izbę stanie faktycznym.

Ustalono, iż w pkt 7 SIWZ zamawiający określił kryteria oceny ofert. Wskazano, że wybór oferty zostanie dokonany na podstawie kryteriów: cena – 60 % i wymagania techniczne – 40%. W pkt 7.III SIWZ, w tabeli określono następujące zasady przyznawania punktów w kryterium „wymagania techniczne”.

18 Ilość możliwych Wymagania techniczne, za spełnienie których zostaną l.p. do uzyskania przyznane punkty punktów Zastosowanie bazy danych wspólnej dla całego systemu w części tak – 4 1 medycznej HIS i zarządczej ERP nie – 0 Pochodzenie oferowanych systemów w części HIS i ERP od tak – 4 2 jednego producenta nie – 0 Wielkość składników pobieranych do pamięci podręcznej tak – 8 3 przeglądarki WWW max 300Kb RAM w części HIS podczas nie – 0 pierwszego i kolejnego logowania do systemu tak – 10 W zakresie całej funkcjonalności części medycznej (HIS) system 4 nie – 0 wykorzystuje motor bazy danych Open Source

W co najmniej dwóch modułach z części administracyjne (ERP) system wykorzystuje motor bazy danych Open Source. Przyjmuje tak – 10 5 się za moduły : Finanse i Księgowość, Gospodarka Materiałowa, nie – 0 Kadry Płace , Środki Trwałe, Kasa System HIS uruchamia się na stacji roboczej nie dłużej niż 5 sekund zarówno podczas pierwszego jak i kolejnego uruchomienia. Za uruchomienie systemu przyjmuje się poprawne tak – 4 6 zalogowanie do niego przez użytkownika i uzyskanie nie – 0 bezpośredniego dostępu do wszystkich modułów systemu bez konieczności otworzenia kolejnego okna.

Krajowa Izba Odwoławcza zważyła, co następuje.

Sporną pomiędzy stronami była możliwość opisania takiego kryterium oceny ofert, zgodnie z którym dodatkowe punkty przyznawane będą za następujące rozwiązania: a) w zakresie całej funkcjonalności części medycznej (HIS) system wykorzystuje motor bazy danych Open Source (wiersz 4 tabeli), b) w co najmniej dwóch modułach z części administracyjne (ERP) system wykorzystuje motor bazy danych Open Source (wiersz 5 tabeli).

Na podstawie zgromadzonego w sprawie materiału dowodowego ustaliła, że przedmiotem zamówienia jest dostawa systemu informatycznego na rynku oprogramowań dla podmiotów służby zdrowia wraz z jego wdrożeniem. Ww. rozwiązania, za które zamawiający zamierzał przyznawać dodatkowe punkty oferuje na właściwym rynku przystępujący Atende Medica sp. z o.o. oraz w przeszłości oferowała firma UHC sp. z o.o. poprzednik prawny CompuGroup Medical.

19 Zgodnie z ogólnym rozkładem ciężaru dowodu to strona która z danego faktu wywodzi skutki prawne obowiązana jest wykazać sporną okoliczność faktyczną (art. 6 KC w zw. z art.

14 ustawy Pzp). Nadto, postępowanie przez Izbą ma charakter kontradyktoryjny. To strony i uczestnicy są obowiązani wskazywać dowody na potwierdzenie okoliczności faktycznych, z których wywodzą skutki prawne (art. 190 ustawy Pzp). Z treści art. 6 KC wynika, że nie prowadzi się dowodu na okoliczności negatywne. Ciężar dowodu spoczywa bowiem na tym który twierdzi, a nie na tym, który zaprzecza. Stanowisko takie wyraził choćby Sąd Najwyższy w wyroku z 18 lutego 2010 r. sygn. akt II CSK 449/09, w którym wywiedziono z treści art. 6 KC, że „nie można obciążać strony ciężarem dowodzenia wystąpienia okoliczności negatywnych”.

Odwołujący w odwołaniach wywodzili, że sporne rozwiązania techniczne, na rynku właściwym, oferuje wyłącznie firma Impulsy sp. z o.o. lub ewentualnie firma Textus Virtualis, która jest autorem oprogramowania Medicus (czyli oprogramowania oferowanego przez Impulsy sp. z o.o.). Wskazywali, że poza ww. podmiotami, takiego rozwiązania nie oferuje żaden inny podmiot. W tym zakresie Izba ustaliła na podstawie wydruku ze strony internetowej firmy Atende Medica, złożonego przez odwołującego Esaprojekt, że obecnie firma Impulsy sp. z o.o. zmieniła nazwę na Atende Medica sp. z o.o. oraz przejęła firmę Textus Virtualis.

W tej sytuacji, to na zamawiającym i uczestniku postępowania, który popierał jego stanowisko spoczywał ciężar wykazania, że oprócz Atende Medica sporne rozwiązania techniczne oferują również inne firmy. Przystępujący Atende Medica przeprowadził dowód, że w 2010 r. UHC sp. z o.o. była w stanie złożyć ofertę na dostawę systemu informatycznego dla Szpitala Powiatowego w Piszu z rozwiązaniem opartym o środowisko open source. Na tej podstawie Izba ustaliła, że 4 lata temu sporne rozwiązanie oferowała również ww. firma.

Nie zostało natomiast wykazane, wbrew oświadczeniom Atende Medica, że omawiane rozwiązanie oferuje również odwołujący Asseco. Przystępujący Atende powołał się na postępowanie o udzielenie zamówienia publicznego na medyczny system informatyczny prowadzone przez Szpital Wojewódzki w Koszalinie w 2013 r. Złożył SIWZ, jaką przygotował ten zamawiający w swym postępowaniu. Odwołujący Asseco przyznał, że złożył ofertę w tym postępowaniu, jednakże zaprzeczył, jakoby była ona oparta o rozwiązania open source.

Wyjaśnił, że zaniechał uczestnictwa w tym postępowaniu i nie stawił się na prezentację systemu, gdyż uznał, że nie spełnia postawionych wymogów. Przystępujący Atende nie złożył oferty odwołującego Asseco w tym postępowaniu, a zatem Izba nie mogła uznać za ustaloną powoływaną przez przystępującego Atende okoliczność faktyczną. Gołosłowne

pozostały oświadczenia zamawiającego i przystępującego Atende, że sporne rozwiązania

20 techniczne oferuje firma Kamsoft. Nie zostało Izbie również wykazane jakimkolwiek dowodem, że bazy danych open source, w niektórych licencjach oferuje Oracle.

Niezasadne jest stanowisko zamawiającego z odpowiedzi na odwołanie zgodnie z którym każdy z odwołujących ma możliwość stworzenia systemu w oparciu o rozwiązania open source. Podkreślenia wymaga, że przedmiotem zamówienia nie jest stworzenie systemu informatycznego dla podmiotu z sektora ochrony zdrowia od podstaw, lecz dostawa gotowego systemu wraz z jego przystosowaniem do potrzeb zamawiającego i wdrożeniem.

Zatem, jak słusznie wskazywali odwołujący na rozprawie, konkurencyjność podlega badaniu przez Izbę w odniesieniu takiego rynku, jaki dotyczy przedmiotu zamówienia, czyli rynku istniejących systemów informatycznych w systemie ochrony zdrowia. Zasady wiedzy i doświadczenia życiowego podpowiadają również, że stworzenie systemu informatycznego dla zamawiającego opartego o rozwiązania open source niejako od podstaw w ten sposób, aby jego prezentację przeprowadzić w zakreślonym w postępowaniu terminie, jest z przyczyn technicznych niemożliwe.

Izba ustaliła również, na podstawie postanowień SIWZ i rozstrzygnięć innych postępowań o udzielenie zamówienia publicznego, w których zamawiający ci opisywali podobne kryteria oceny ofert, iż postanowienia te mogły wywierać wpływ na ograniczenie konkurencyjności. Na podstawie dowodów złożonych przez odwołujących ustalono bowiem, że jedynym podmiotem, który składał ofertę w powoływanych postępowaniach były firmy Impulsy sp. z o.o. i Textus Virtualis, czyli obecnie Atende Medica sp. z o.o.

Ustalona przez Izbę okoliczność, iż na rynku sporne rozwiązania oferuje Atende Medica, oraz - w przeszłości firma UHC sp. z o.o. - nie oznaczała jednak sama przez się, że zamawiający nie ma prawa punktować takiej cechy systemu. Wymagało to dodatkowo ustalenia, że po stronie zamawiającego nie istnieje uzasadniona potrzeba posiadania takiego rozwiązania. W tym miejscu wyjaśnienia wymaga, że choć zamawiającemu w myśl art. 91 ust. 2 ustawy Pzp pozostawiono pewną dowolność w zakresie formułowania kryteriów oceny ofert odnoszących się do przedmiotu zamówienia, to jednak jego swoboda nie pozostaje nieograniczona. Również w tym zakresie obowiązuje bowiem nakaz takiego przygotowania i przeprowadzenia postępowania o udzielenie zamówienia, które zapewni zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców (art. 7 ust. 1 ustawy Pzp). W ocenie Izby, nie stanowi naruszenia wspomnianej zasady sformułowanie kryterium oceny ofert, które wprawdzie ogranicza szanse niektórych podmiotów w uzyskaniu zamówienia, ale znajduje uzasadnienie w obiektywnych potrzebach zamawiającego. Rolą kryteriów oceny ofert, odnoszących się do przedmiotu zamówienia jest bowiem premiowanie takiego rozwiązania, które z jakichś, określonych i obiektywnych przyczyn jest dla zamawiającego

21 korzystniejsze niż parametry bezwzględnie wymagane. Biorąc powyższe pod uwagę Izba zbadała, czy po stronie zamawiającego istnieje potrzeba posiadania spornego rozwiązania.

Zamawiający w trakcie rozprawy powołał się na argument kosztowy. Wywodził, że w przypadku rozwiązań komercyjnych, po okresie 5 lat, może ponosić dodatkowe koszty ich serwisowania. Izba w tym zakresie stwierdziła, że ustawa Pzp pozwala na formułowanie innych kryteriów oceny ofert odnoszących się do kosztów utrzymania systemu w przyszłości.

Istnieje możliwość skorzystania z instytucji jaką jest prawo opcji i przewidzenia możliwości dokupienia serwisu rozwiązań komercyjnych po okresie 5 letnim. Należy wziąć również pod uwagę, że zamawiający po upływie 5 lat nie ma konieczności kupowania serwisu w odniesieniu do rozwiązania komercyjnego. Wreszcie, jak oświadczył na rozprawie przystępujący Atende, również w przypadku rozwiązań open source, w przypadku niektórych licencji, istnieje możliwość dokupienia serwisu systemu, z czym wiązać się będzie konieczność ponoszenia dodatkowych kosztów. Nadto, w ocenie Izby, rozwiązania typu open source tylko pozornie są darmowe. Wszak takie rozwiązanie musi być dostosowanie do potrzeb zamawiającego. A zatem jedynie bazą, budulcem systemu jest rozwiązanie open source, zaś wszelkie prace związane z rozbudową, modernizacją czy przystosowaniem do potrzeb zamawiającego będą utworem wykonanym przez podmiot dostosowujący, a zatem

także objęte prawami autorskimi, jak rozwiązania komercyjne. Izba wzięła również pod uwagę to, że jeżeli rzeczywiście zamawiającemu przyświecała chęć ograniczenia kosztów serwisowania w dłuższej perspektywie czasowej, to pozostawało to w sprzeczności z postanowieniami SIWZ. W świetle nich zamierzano bowiem przyznawać dodatkowe punkty za rozwiązania open source dotyczące części systemu (tj. dwa moduły i to spośród dowolnie wybranych przez wykonawców modułów z części administracyjnej ERP). Jeżeli faktycznie dla zamawiającego liczyły się korzyści ekonomiczne, to nie wiadomo dlaczego nie zdecydował się punktować dodatkowo jedynie rozwiązania opartego w całości o środowisko open source.

Nie stanowiły również o konieczności posiadania rozwiązania open source przedstawione na rozprawie argumenty dotyczące rzekomej, łatwiejszej możliwości rozbudowy systemu opartego o open source. Jak wskazywano na rozprawie, istnieje możliwość rozbudowy systemów komercyjnych również poprzez ich integrację z innymi rozwiązaniami, w tym open source.

Biorąc powyższe pod uwagę Izba uznała, że nie zostało wykazane, aby opisane kryteria oceny ofert znajdowały oparcie w uzasadnionych potrzebach zamawiającego, a niewątpliwie mogły w sposób znaczący ograniczyć jego konkurencyjność, co stanowi o naruszeniu przez zamawiającego art. 91 ust. 2 w zw. z art. 7 ust. 1 ustawy Pzp. Izba nakazała zatem zamawiającemu modyfikację SIWZ poprzez usunięcie spornych kryteriów oceny ofert.

22 Izba nie przychyliła się do zmodyfikowanego na rozprawie alternatywnego żądania odwołującego Esaprojekt. Odwołujący domagał się zmiany punktu 4 i 5 w zakresie tabeli kryterium oceny ofert poprzez nadanie punktowi 4 brzmienia: „w zakresie całej funkcjonalności części medycznej HIS system wykorzystuje motor bazy danych, który w ramach oceny zgodności z normą ISO/IEC 15408 uzyskał ocenę co najmniej EAL4+ oraz ALC_FLR.3”. Wnioskował ponadto o nadanie pkt 5 brzmienia: „w zakresie oprogramowania ERP system wykorzystuje motor bazy danych, który w ramach oceny zgodności z normą ISO/IEC 15408 uzyskał ocenę co najmniej EAL4+ oraz ALC_FLR.3.”. W tym zakresie Izba uznała, że generalnie pożądane jest aby wdrażane systemy odpowiadały normom bezpieczeństwa. Ale skoro okoliczność ta, w świetle oświadczenia zamawiającego, nie była istotna i nie znajdowała uzasadnienia w jego uzasadnionych potrzebach, a niewątpliwie wpływała na ograniczenie konkurencyjności w postępowaniu, to Izba nie znalazła podstaw aby żądanie odwołującego uwzględnić. Ponadto Izbie nie złożono treści powoływanych norm.

1. Zarzut dotyczący wymogu odnośnie umożliwienia pracy systemu z poziomu przeglądarki www dla wszystkich modułów obsługi klienta (sygn. akt KIO 1221/14, KIO 1222/14) Zarzut potwierdził się w ustalonym przez Izbę stanie faktycznym.

Ustalono, że w załączniku nr 1 do SIWZ, w pkt 2.1., w tiret dziesiątym, zamawiający sformułował następujący wymóg: „Dla wszystkich modułów obsługi pacjenta (tj. Ruch chorych, Rehabilitacja, Oddział, Izba przyjęć, Rejestracja, Gabinet, Blok operacyjny, Szpitalny Oddział Ratunkowy, Zlecenia, Zakażenia itp.) oraz Apteki system musi umożliwić pracę z poziomu przeglądarki www”.

Zgodnie z art. 29 ust. 2 ustawy Pzp, przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję. Izba podziela podnoszone w piśmiennictwie i orzecznictwie stanowisko, że zakazane jest dokonywanie opisu przedmiotu zamówienia nie tylko takiego, który utrudnia uczciwą konkurencję, wskazując na konkretny produkt, ale i takiego, który potencjalnie mógłby wpłynąć na konkurencję na rynku.

Dyspozycją art. 29 ust. 2 ustawy Pzp objęte jest zaistnienie co najmniej możliwości utrudniania uczciwej konkurencji, tak więc spełnienie dyspozycji tego przepisu niekoniecznie musi przybierać charakter bezpośredniego godzenia w uczciwą konkurencję. Z drugiej strony zakaz opisywania przedmiotu zamówienia w sposób, który mógłby utrudniać uczciwą

23 konkurencję nie oznacza konieczności nabycia przez zamawiającego dostaw, usług czy

robót budowlanych nieodpowiadających jego potrzebom, zarówno co do jakości, funkcjonalności czy wymaganych parametrów technicznych. Oznacza jedynie, iż zamawiający winien dopuścić konkurencję między wykonawcami mogącymi spełnić postawione wymogi w odniesieniu do przedmiotu zamówienia bez ograniczania dostępu do niego. Stąd bardzo istotną czynnością zamawiającego jest dokonanie opisu przedmiotu zamówienia przez wskazanie tych jego cech, które mają dla zamawiającego kluczowe znaczenie. Jak słusznie zauważył Sąd Okręgowy w Zielonej Górze w wyroku z dnia 15 października 2007 r., V Gaz 90/07, „uprawnieniem zamawiającego jest bowiem prowadzenie postępowania w celu uzyskania takiego przedmiotu, jaki jest mu dogodny ze względu na posiadane warunki oraz potrzeby i który spełni jego oczekiwania funkcjonalne (...)".

Jednocześnie jednak zamawiający swobodę precyzowania swoich wymagań ma ograniczoną, w tym sensie, że jego wymagania muszą mieć uzasadnienie pozwalające na zrównoważenie ograniczenia konkurencji. Sąd Okręgowy w Poznaniu w wyroku z dnia 11 sierpnia 2006 r., IX Ga 137/06, rozpatrując granice swobody opisu przedmiotu zamówienia, podkreślił: „Prawo zamówień publicznych chroni bowiem z jednej strony interes Zamawiającego (interes publiczny), z drugiej nakazuje przestrzegać zasady równego traktowania potencjalnych wykonawców i uczciwej konkurencji. Formułując siwz, Zamawiający musi mieć na uwadze dobra chronione tą ustawą i zachować równowagę pomiędzy rozwiązaniami preferującymi poszczególne interesy". Wydaje się też, że rozpatrując możliwość ograniczenia uczciwej konkurencji przez dokonanie tendencyjnego opisu przedmiotu zamówienia, nie sposób abstrahować od warunków rynku właściwego dla danych dostaw, usług czy robót budowlanych. Dokonywanie opisu przedmiotu zamówienia na podstawie katalogów jednego z producentów, (…) jest działaniem utrudniającym uczciwą konkurencję. Warto też podkreślić, że dokonywanie opisu przedmiotu zamówienia przez wskazanie rygorystycznych wymagań, nieuzasadnionych potrzebami zamawiającego, będzie uprawdopodobniało naruszenie uczciwej konkurencji. (Dzierżanowski Włodzimierz, Jerzykowski Jarosław, Stachowiak Małgorzata, komentarz, LEX 2010, Komentarz do art. 29 ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz.U.10.113.759), [w:] M.

Stachowiak, J. Jerzykowski, W. Dzierżanowski, Prawo zamówień publicznych. Komentarz, LEX, 2010, wyd. IV).

Ponadto Izba wzięła pod uwagę, iż w praktyce zamówień publicznych, za wyjątkiem prostych zamówień, prawie nigdy nie jest możliwe określenie znaczenia warunków udziału w postępowaniu czy to opisanie przedmiotu zamówienia, który w ten czy inny sposób nie uniemożliwia części wykonawców w ogóle złożenie oferty, a niektórych stawia w uprzywilejowanej pozycji. Warunkiem nienaruszania konkurencji jest w takim przypadku brak

24 uniemożliwiania z góry niektórym podmiotom udziału w postępowaniu bez uzasadnienia w obiektywnych potrzebach i interesach zamawiającego oraz brak sytuacji, w której uprzywilejowanie danych wykonawców osiągnie rozmiary faktycznie przekreślające jakąkolwiek konkurencję. Nie oznacza, to jednak wcale, iż zamówienie musi być w równym stopniu "wygodne" wszystkim wykonawcom i dostosowane do profilu ich oferty i rodzaju czy przebiegu działalności (wyrok KIO z dnia 24 czerwca 2010 r., sygn. akt KIO/UZP 1122/10).

Przenosząc powyższe rozważania na grunt przedmiotowej sprawy Izba zbadała, czy potrzeba wymaganej funkcjonalności znajdowała uzasadnienie w obiektywnych potrzebach zamawiającego. Zamawiający w odpowiedzi na odwołanie wskazał, że formułując wymóg kierował się chęcią zapewnienia dostępu do systemu przez 24 godziny na dobę.

Argumentował ponadto, że na zasób sprzętowy i oprogramowanie, jakie znajdują się w jego placówkach składa się szereg urządzeń dysponujących przeglądarkami internetowymi.

Zasób ten w części jest przestarzały. Wywiódł, że wymagane rozwiązanie pozwoli wykorzystać posiadaną infrastrukturę, a jednocześnie uniknie się w ten sposób konieczności instalacji dodatkowego oprogramowania na urządzeniach w celu dostępu systemu. Podniósł na rozprawie, że dzięki zapewnieniu, w zakresie modułów z zakresu obsługi pacjenta, dostępu do systemu przez przeglądarkę www, pojawi się możliwość korzystania z systemu na różnych urządzeń, w tym sprzętu typu tablet, a ponadto także poza terenem placówek.

W ocenie Izby, niewątpliwe zalety dostępu do systemu z poziomu przeglądarki internetowej posiada również inne rozwiązanie, które nie zostało jednak dopuszczone.

Rozwiązanie takie zostało opisane i omówione na rozprawie przez odwołującego Esaprojekt.

Wskazał on, że za pośrednictwem aplikacji terminalowej można skorzystać z systemu, w tym również poza placówkami szpitala, uzyskując dostęp do tych samych funkcjonalności, jak za pośrednictwem przeglądarki internetowej. Rozwiązanie to polega to na tym, że ze strony internetowej pobiera i instaluje się na dowolnym urządzeniu aplikację terminalową. Dzięki tej aplikacji istnieje możliwość dostępu do systemu przez 24h/dobę. Dzięki sieci wirtualnej/bezpiecznej dostęp do systemu jest bezpieczny. Ponadto rozwiązanie to zapewnia możliwość do systemu również poza placówkami zamawiającego.

Biorąc powyższe pod uwagę Izba stwierdziła, że nie znajduje uzasadnienia w potrzebach zamawiającego ograniczenie przedmiotu zamówienia jedynie do takich do systemów, do których dostęp będzie możliwy wyłącznie z poziomu przeglądarki www, z pominięciem opisanego rozwiązania, które zaspokaja wszystkie potrzeby wskazywane przez zamawiającego.

25

1. Zarzuty dotyczący wymogu działania systemu w architekturze trójwarstwowej (sygn. akt KIO 1221/14) Zarzut nie potwierdził się w ustalonym przez Izbę stanie faktycznym.

Ustalono, że w załączniku nr 1 do SIWZ, w pkt 2.1., w tiret pierwsze, zamawiający sformułował następujący wymóg: „Dostęp do funkcji systemu jest realizowany ze stanowiska roboczego bez konieczności instalacji dodatkowych aplikacji lub modułów oprogramowania obsługującego komunikację pośrednią między interfejsem użytkownika na stanowiska roboczym, a systemem na serwerze”. W tym samym punkcie, w tiret trzecie, zamawiający opisał następujące wymaganie: „System działa w architekturze trójwarstwowej”.

W ocenie Izby istnieją takie zalety systemu działającego w architekturze trójwarstwowej, które uprawniały zamawiającego do sformułowania omawianego wymogu, jako odpowiadającego jego uzasadnionym i obiektywnym potrzebom, a które nie charakteryzują systemów w architekturze dwuwarstwowej.

Wyjaśnienia wymaga, że system działający w architekturze trójwarstwowej charakteryzuje się odrębnymi warstwami takimi jak: baza, aplikacja oraz interfejs, natomiast wykonany w architekturze dwuwarstwowej posiada dwie warstwy bazę danych oraz interfejs z aplikacją. Potrzeba posiadania systemu w architekturze trójwarstwowej może być uzasadniona możliwością elastyczniejszego zarządzania systemem, wyrażającą się np. w możliwości aktualizacji systemu do nowych wersji bez konieczności zatrzymania systemu i braku dostępu do niego. Kolejną zaletą jest możliwość aktualizacji i zastępowania modułów niezależnie od siebie. Przykładowo, w razie zmiany systemu operacyjnego, wpłynie to na warstwę interfejsu, ale już nie na warstwę przetwarzania i składowania danych.

Jak przedstawiono to przy omawianiu poprzedniego zarzutu, nie narusza dyspozycji art.

29 ust. 2 ustawy Pzp dokonanie takiego opisu przedmiotu zamówienia, który znajduje oparcie w potrzebach zamawiającego. Nie ma on bowiem obowiązku nabywania systemu, który będzie w równym stopniu odpowiadał wszystkim wykonawcom na rynku, ale systemu, który jest mu niezbędny.

1. Zarzuty dotyczący próbki prezentacji systemu (sygn. akt KIO 1222/14) 26 Zarzut potwierdził się w zakresie dotyczącym zaniechania precyzyjnego opisania scenariusza prezentacji próbki systemu.

Ustalono, że w postanowieniu pkt 5.1 SIWZ, w tabeli, w pkt 14, sformułowano wymaganie zgodnie z którym wykonawcy obowiązani będą złożyć:

Próbkę oferowanego ZSI, umożliwiającą weryfikację oferowanych funkcjonalności, w szczególności w zakresie podlegającym ocenie punktowej w ramach kryterium oceny ofert, w postaci oprogramowania aplikacyjnego (w zakresie HIS - oprócz LIS,RIS, PACS oraz ERP), zainstalowanego na sprzęcie Wykonawcy (np. przenośnym komputerze) jako w pełni działającego i skonfigurowanego umożliwiającego weryfikację oferowanej funkcjonalności.

Zamawiający wymaga, aby próbka została złożona wraz z ofertą. Próbka jest rozumiana jako

dokument zgodnie z Rozporządzeniem Prezesa Rady Ministrów z dnia 30 grudnia 2009 r. w sprawie dokumentów rodzajów dokumentów, jakich może żądać zamawiający od wykonawcy, oraz form, w jakich te dokumenty mogą być składane. Zamawiający wyjaśnia, że zgodnie z art. 97 ust. 2, zwróci próbki Wykonawcom, których oferty nie zostały wybrane, na ich wniosek. Próbkę Wykonawcy, który złożył ofertę najkorzystniejszą, Zamawiający, zgodnie z art. 97 ust. 1, przechowuje jako załącznik do protokołu przez okres 4 lat od dnia zakończenia postępowania o udzielenie zamówienia, w sposób gwarantujący jego nienaruszalność.

Ustalono nadto, iż w postanowieniu pkt 5.1. ppkt 6 SIWZ zamawiający sprecyzował, iż „Zamawiający zastrzega sobie możliwość zaproszenia Wykonawcy by dokonał prezentacji/demonstracji oferowanego oprogramowania aplikacyjnego, w pełni skonfigurowanego i zainstalowanego na swoim sprzęcie IT, w celu weryfikacji faktycznie oferowanej funkcjonalności ZSI według wcześniej określonego scenariusza. Czas na uruchomienie zdeponowanej próbki wraz z rozpoczęciem prezentacji to max. 20 min . O możliwości prezentacji systemu Wykonawca zostanie powiadomiony przez Zamawiającego z zachowaniem odpowiednich terminów wymaganych w PZP. Scenariusz prezentacji systemu Wykonawca otrzyma od Zamawiającego razem z powiadomieniem o możliwości jej przeprowadzenia.

1. Jeżeli w trakcie prezentacji dojdzie do stwierdzenia jakiejkolwiek niezgodności prezentowanego systemu z deklaracją Wykonawcy zawartą w ofercie co do jego parametrów funkcjonalnych oferta Wykonawcy zostanie odrzucona na podstawie art. 89 ust. 1 pkt. 3 Ustawy w związku z art. 14 Ustawy z dnia 16.04.1993 r. o zwalczaniu nieuczciwej konkurencji.

27

1. Jeżeli Wykonawca nie stawi się w celu dokonania prezentacji w wyznaczonym przez Zamawiającego terminie i czasie, zostanie wykluczony z niniejszego postępowania o udzielenie zamówienia publicznego”.

Izba stwierdziła, że odwołujący Esaprojekt nie wykazał, aby ograniczenie czasu uruchomienia próbki systemu i rozpoczęcia jej prezentacji do 20 minut było nadmierne.

Zwrócić należało uwagę, że w świetle kwestionowanego postanowienia termin dotyczył okresu od momentu rozpoczęcia czynności włączenia systemu do chwili rozpoczęcia jego prezentacji, a zatem najbardziej wstępnego etapu prezentacji próbki. Oczywistym jest przy tym, że do terminu tego nie wlicza przerw będących następstwem obiektywnych przeszkód w inicjalizacji próbki systemu nieleżących po stronie wykonawcy. Podkreślenia wymagał również fakt, że zamawiający nie limitował w żaden sposób czasu na przygotowania do rozpoczęcia uruchamiania próbki systemu. Co istotne, owe 20 minut nie dotyczyło również trwania samej prezentacji próbki systemu. Biorąc powyższe pod uwagę Izba stwierdziła, że kwestionowane postanowienie nie narusza wskazywanych przez odwołującego Esaprojekt przepisów ustawy Pzp i aktów wykonawczych. Na marginesie Izba zwraca uwagę, że zamawiający nie określił w SIWZ skutków, jakie należy wiązać z niezachowaniem przez wykonawcę 20-minutowego terminu. Zapytany na rozprawie nie potrafił również wyjaśnić ewentualnych konsekwencji, jaki łączyć będą się z uchybieniem terminu. W ocenie Izby, jeżeli skutek niedochowania terminu nie zostanie doprecyzowany, to kwestionowane postanowienie może być postrzegane jedynie jako termin instrukcyjny. Przy takiej interpretacji długość terminu uruchomienia próbki systemu nie stanowi treści SIWZ, ale zapis o charakterze formalnym.

Izba podzieliła stanowisko odwołującego Esaprojekt, że zamawiający w niedostateczny sposób określił w SIWZ scenariusz, według którego będzie odbywać się prezentacja próbki systemu. W pierwotnej treści SIWZ zamawiający w ogóle zaniechał opisu scenariusza, wskazując, że wykonawca otrzyma go razem z powiadomieniem o możliwości jej przeprowadzenia. Z uwagi na konieczność odpowiednio wcześniejszego przygotowania próbki, dotyczącej systemu, który ma zostać dostarczony i wdrożony dopiero w wyniku udzielenia zamówienia, zapis ten należało uznać za niedopuszczalny.

Zdaniem Izby, o wykonaniu żądania odwołującego, tj. zamieszczenia takiego scenariusza, nie świadczyła także treść zmodyfikowanego przez zamawiającego w dniu 30 czerwca 2014 r. pkt 5.1. tabeli pkt 14 SIWZ. W zmodyfikowanym postanowieniu wskazano

jedynie, iż celem prezentacji będzie „weryfikacja oferowanych funkcjonalności w odniesieniu

28 do wymagań ogólnych zawartych w pkt 2.1 załącznika nr 1 do SIWZ oraz wymagań technicznych, za spełnienie których zostaną przyznane punkty w ramach kryterium oceny ofert „Wymagania techniczne”, opisanych w poz. 1-6 tabeli w pkt 7 ppkt III SIWZ”. Izba stwierdziła, że z uwagi na doniosłą rolę, jaką może odegrać prezentacja próbki systemu, jej scenariusz wymaga dalszego dookreślenia. Zdaniem Izby, doprecyzowanie to powinno obejmować wskazanie w sposób możliwie szczegółowy i konkretny, jedynie najważniejszych funkcjonalności systemu, wraz z opisaniem efektu, jaki wykonawcy obowiązani będą zaprezentować (osiągnąć).

Za chybione uznano żądanie odwołującego Esaprojekt, aby próbkę ograniczyć jedynie do płyty CD z oprogramowaniem systemowym. W ocenie Izby, zamawiający ma prawo żądać, aby wykonawca zaprezentował funkcjonalności systemu na swoim sprzęcie.

Takie rozwiązanie chroni zamawiającego przed ewentualnymi zarzutami wykonawców co do nieprawidłowego przebiegu prezentacji z powodu np. wad sprzętu zamawiającego, na którym miałaby być uruchomiona płyta CD. Zamawiający ma prawo zbadać działanie próbki systemu w warunkach, za które odpowiadają wykonawcy. Za niezasadny uznano argument odwołującego, jakoby sprzęt wykonawcy, na którym ma być zainstalowana próbka systemu, miał być mieniem znacznej wartości. Koszt nawet nowego laptopa wynosi ok. 2,5 tys. zł, co stanowi relatywnie niewielką wartość wobec wartości całego zamówienia, jakie wykonawca spodziewa się uzyskać. Nie ma przeszkód aby wykonawca posłużył się sprzętem używanym.

Ponadto w myśl art. 97 ust. 2 ustawy Pzp, wykonawcom, których oferty nie zostaną wybrane jako najkorzystniejsze, próbki zostaną zwrócone na ich wniosek. Dysponowanie przez zamawiającego tymi próbkami jest zatem czasowo ograniczone. Jedynie próbkę pochodzącą od wykonawcy wybranego zamawiający obowiązany będzie przechowywać przez okres wskazany w ustawie.

Zdaniem Izby, nie może stanowić przedmiotu skutecznego zarzutu zaniechanie przez zamawiającego utrwalania przebiegu prezentacji za pomocą kamery wideo. Izba zgadza się z odwołującym jedynie w tym, że takie utrwalenie byłoby najbardziej optymalne ze względów dowodowych. Jednakże uszło uwadze odwołującego, że obowiązkiem zamawiającego, w myśl zasady pisemności postępowania, o której mowa w art. 9 ust. 1 ustawy Pzp, jest jedynie utrwalenie przebiegu czynności dokonywanych w postępowaniu w takiej właśnie formie. Zamawiający nie ma obowiązku utrwalania czynności dokonywanych w postępowaniu za pomocą kamery wideo. Zamawiający oświadczył w trakcie rozprawy, że z przebiegu prezentacji próbki systemu sporządzony zostanie protokół, do którego uczestnicy

29 czynności będą mogli zgłaszać uwagi. Zdaniem Izby, jest to dostateczny sposób utrwalenia przebiegu takiej czynności.

Zgodnie z przepisem art. 192 ust. 2 ustawy Pzp, Krajowa Izba Odwoławcza uwzględnia odwołanie w sytuacji, jeżeli stwierdzi naruszenie przepisów ustawy, które miało wpływ lub może mieć istotny wpływ na wynik postępowania o udzielenie zamówienia, co ze wskazanych wyżej względów miało miejsce we wszystkich sprawach. Biorąc powyższe pod uwagę, na podstawie art. 192 ust. 1 oraz art. 192 ust. 3 pkt 1 ustawy Pzp, orzeczono jak w sentencji.

30 O kosztach postępowania orzeczono stosownie do wyniku postępowania - na podstawie art. 192 ust. 9 i 10 ustawy Pzp oraz w oparciu o przepisy § 5 ust. 4 w zw. z § 3 pkt 1 rozporządzenia Prezesa Rady Ministrów z dnia 15 marca 2010r. w sprawie wysokości i sposobu pobierania wpisu od odwołania oraz rodzajów kosztów w postępowaniu odwoławczym i sposobu ich rozliczania (Dz. U. Nr 41 poz. 238).

Izba uwzględniła koszty wynagrodzenia pełnomocników odwołujących w wysokości 3600,00 zł, na podstawie rachunków złożonych do akt sprawy, stosownie do brzmienia § 5 ust. 2 pkt 1 w zw. z § 3 pkt 2 lit. b przywoływanego rozporządzenia Prezesa Rady Ministrów z dnia 15 marca 2010 r., ograniczając wysokość kosztów do kwoty 3.600,00 zł maksymalnie dopuszczalnej w myśl przywołanego przepisu.

Przewodniczący

………………….… Członkowie: ……………………. ……………………..

31